Commit graph

1,323,830 commits

Author SHA1 Message Date
Pablo Sun
4007651c25
arm64: dts: mediatek: mt8188: Fix wrong clock provider in MFG1 power domain
The clock index "CLK_APMIXED_MFGPLL" belongs to the "apmixedsys" provider,
so fix the index.

In addition, add a "mfg1" label so following commits could set
domain-supply for MFG1 power domain.

Fixes: eaf73e4224 ("arm64: dts: mediatek: mt8188: Add support for SoC power domains")
Signed-off-by: Pablo Sun <pablo.sun@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20241002022138.29241-2-pablo.sun@mediatek.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-10-02 11:12:01 +02:00
Jani Nikula
0ca97fcdba drm/i915/soc: stop using IS_GEN9_LP() and IS_GEN9_BC()
Replace IS_GEN9_LP() and IS_GEN9_BC() with direct platform checks. This
lets us remove their compat counterparts, as neither soc/ nor /display
now no longer needs them.

v2: Use !A && !B instead of !(A || B) (Ville)

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> # v1
Link: https://patchwork.freedesktop.org/patch/msgid/20240930124056.3541988-2-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-10-02 12:06:20 +03:00
Jani Nikula
06f4d32843 drm/i915: remove IS_LP()
The .is_lp member of struct intel_device_info and its wrapper IS_LP()
are used to identify just four platforms, VLV/CHV/BXT/GLK. It didn't
become as important as it was perhaps originally planned. Just remove
it, and replace with exact platform identification. In a few places this
becomes slightly verbose, but in many places it improves clarity to
immediately see the exact platforms.

Additionally, this lets us remove the xe compat macro.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240930124056.3541988-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-10-02 12:06:20 +03:00
Adrián Larumbe
6a797bdfde drm/panthor: add sysfs knob for enabling job profiling
This commit introduces a DRM device sysfs attribute that lets UM control
the job accounting status in the device. The knob variable had been brought
in as part of a previous commit, but now we're able to fix it manually.

As sysfs files are part of a driver's uAPI, describe its legitimate input
values and output format in a documentation file.

Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240923230912.2207320-6-adrian.larumbe@collabora.com
2024-10-02 10:55:17 +02:00
Adrián Larumbe
064bb57479 drm/panthor: enable fdinfo for memory stats
Implement drm object's status callback.

Also, we consider a PRIME imported BO to be resident if its matching
dma_buf has an open attachment, which means its backing storage had already
been allocated.

Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240923230912.2207320-5-adrian.larumbe@collabora.com
2024-10-02 10:55:17 +02:00
Adrián Larumbe
e16635d88f drm/panthor: add DRM fdinfo support
Drawing from the FW-calculated values in a previous commit, we can increase
the numbers for an open file by collecting them from finished jobs when
updating their group synchronisation objects.

Display of fdinfo key-value pairs is governed by a bitmask that is by
default unset in the present commit, and supporting manual toggle of it
will be the matter of a later commit.

Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240923230912.2207320-4-adrian.larumbe@collabora.com
2024-10-02 10:55:17 +02:00
Adrián Larumbe
37591ae11f drm/panthor: record current and maximum device clock frequencies
In order to support UM in calculating rates of GPU utilisation, the current
operating and maximum GPU clock frequencies must be recorded during device
initialisation, and also during OPP state transitions.

Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240923230912.2207320-3-adrian.larumbe@collabora.com
2024-10-02 10:55:16 +02:00
Adrián Larumbe
f8ff51a470 drm/panthor: introduce job cycle and timestamp accounting
Enable calculations of job submission times in clock cycles and wall
time. This is done by expanding the boilerplate command stream when running
a job to include instructions that compute said times right before and
after a user CS.

A separate kernel BO is created per queue to store those values. Jobs can
access their sampled data through an index different from that of the
queue's ringbuffer. The reason for this is saving memory on the profiling
information kernel BO, since the amount of simultaneous profiled jobs we
can write into the queue's ringbuffer might be much smaller than for
regular jobs, as the former take more CSF instructions.

This commit is done in preparation for enabling DRM fdinfo support in the
Panthor driver, which depends on the numbers calculated herein.

A profile mode mask has been added that will in a future commit allow UM to
toggle performance metric sampling behaviour, which is disabled by default
to save power. When a ringbuffer CS is constructed, timestamp and cycling
sampling instructions are added depending on the enabled flags in the
profiling mask.

A helper was provided that calculates the number of instructions for a
given set of enablement mask, and these are passed as the number of credits
when initialising a DRM scheduler job.

Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240923230912.2207320-2-adrian.larumbe@collabora.com
2024-10-02 10:55:06 +02:00
Sam Edwards
6d14287746 arm64: dts: rockchip: Enable all 3 USBs on Turing RK1
The Turing RK1 contains 3 different USBs:
- USB0: USB 2.0, OTG
- USB1: USB 3.0, host
- USB2: USB 2.0, host

This patch activates the necessary DT nodes to enable all 3 buses.

Future work will be needed on USB0: it is not USB3-capable, so the USB0
controller needs to be told that there is no USB3 port. Per Jonas's
suggestion, the USBDP0 node is given a `rockchip,dp-lane-mux` property
that tells the USBDP driver that USBDP0 is not involved in USB so that
it can make the necessary configuration changes in hardware.
Technically, this is USB *controller* configuration, not *PHY*
configuration, so the underlying code may be moved in the future to the
USB controller driver instead, freeing up the (software) dependency on
USBDP0. A TODO comment is added to explain this.

Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Suggested-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20240930210652.1232951-1-CFSworks@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-10-02 10:27:30 +02:00
Chris Morgan
de7e071ad5 arm64: dts: rockchip: Add Powkiddy RGB20SX
The Powkiddy RGB20SX is a portable game console extremely similar to
the existing RGB30 console. The key differences from the RGB30 are
as follows:

 - Realtek RTW8723DS WiFi and Bluetooth.
 - UART pads for debug console (UART2).
 - A function button (ADC channel 0).
 - A much larger battery (5000 mAh).

Otherwise, the device is identical to the RGB30, including the
hard-coded value on ADC channel 1 used to identify the device at
runtime.

Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Link: https://lore.kernel.org/r/20241001154016.87386-3-macroalpha82@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-10-02 10:24:41 +02:00
Chris Morgan
fbfff2f646 dt-bindings: arm: rockchip: Add Powkiddy RGB20SX
Add devicetree binding for Powkiddy RGB20SX.

Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20241001154016.87386-2-macroalpha82@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-10-02 10:24:41 +02:00
Daniel Semkowicz
52f21c63ed arm64: dts: rockchip: Add power button for puma-haikou
There is a PWRBTN# input pin exposed on a Q7 connector. The pin
is routed to a GPIO0_A1 through a diode. Q7 specification describes
the PWRBTN# pin as a Power Button signal.
Configure the pin as KEY_POWER, so it can function as power button and
trigger device shutdown.

Signed-off-by: Daniel Semkowicz <dse@thaumatec.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20241001134741.210979-1-dse@thaumatec.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-10-02 10:20:43 +02:00
Ivaylo Ivanov
e6bb057595 soc: samsung: exynos-chipid: add exynos8895 SoC support
Add EXYNOS8895 information to soc_ids tables. This SoC product id
is "0xE8895000".

Signed-off-by: Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
Link: https://lore.kernel.org/r/20240920154508.1618410-4-ivo.ivanov.ivanov1@gmail.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2024-10-02 09:53:05 +02:00
Ivaylo Ivanov
7f6ea7198e dt-bindings: hwinfo: samsung,exynos-chipid: add exynos8895 compatible
Add "samsung,exynos8895-chipid" compatible string to binding document.

Signed-off-by: Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20240920154508.1618410-3-ivo.ivanov.ivanov1@gmail.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2024-10-02 09:52:48 +02:00
Ivaylo Ivanov
296621bfa3 arm64: dts: exynos: Add initial support for Samsung Galaxy S8
Samsung Galaxy S8 (SM-G950F), codenamed dreamlte, is a mobile phone
from 2017. It features 4GB RAM, 64GB UFS 2.1, Exynos 8895 SoC and a
1440x2960 Super AMOLED display.

This initial device tree enables SimpleFB, PSTORE and GPIO keys.

Signed-off-by: Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
Link: https://lore.kernel.org/r/20240920154508.1618410-11-ivo.ivanov.ivanov1@gmail.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2024-10-02 09:52:38 +02:00
Ivaylo Ivanov
dcabaa8ae4 arm64: dts: exynos: Add initial support for exynos8895 SoC
Exynos 8895 SoC is an ARMv8 mobile SoC found in the Samsung Galaxy
S8 (dreamlte), S8 Plus (dream2lte), Note 8 (greatlte) and the Meizu
15 Plus (m1891). Add minimal support for that SoC, including:

- All 8 cores via PSCI
- ChipID
- Generic ARMV8 Timer
- Enumarate all pinctrl nodes

The devices using this SoC suffer from an issue caused by the stock
Samsung bootloader, as it doesn't configure CNTFRQ_EL0. Hence it's
needed to hardcode the adequate frequency in the timer node,
otherwise the kernel panics.

Further platform support will be added over time.

Signed-off-by: Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
Link: https://lore.kernel.org/r/20240920154508.1618410-9-ivo.ivanov.ivanov1@gmail.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2024-10-02 09:52:37 +02:00
Ivaylo Ivanov
496374c1d0 dt-bindings: soc: samsung: exynos-pmu: Add exynos8895 compatible
Add exynos8895-pmu compatible to the bindings documentation. Since
Samsung, as usual, reuses devices from older designs, use the
samsung,exynos7-pmu compatible.

Signed-off-by: Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20240920154508.1618410-8-ivo.ivanov.ivanov1@gmail.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2024-10-02 09:52:37 +02:00
Ivaylo Ivanov
2caf56f6cf dt-bindings: arm: samsung: Document dreamlte board binding
Add binding for the Samsung Galaxy S8 (SM-G950F) board, which is
based on the Samsung Exynos8895 SoC.

Signed-off-by: Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20240920154508.1618410-10-ivo.ivanov.ivanov1@gmail.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2024-10-02 09:51:39 +02:00
Ivaylo Ivanov
eed2e79221 pinctrl: samsung: Add exynos8895 SoC pinctrl configuration
Add support for the pin-controller found on the Exynos8895 SoC
used in Samsung Galaxy S8 and S8 Plus phones.

It has a newly applied pinctrl register layer for FSYS0 with a
different bank type offset that consists of the following bit
fields:

CON: 4, DAT: 1, PUD: 2, DRV: 3, CONPDN: 2, PUDPDN: 2

Signed-off-by: Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20240920154508.1618410-6-ivo.ivanov.ivanov1@gmail.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2024-10-02 09:47:45 +02:00
Ivaylo Ivanov
e2d58d1e1c dt-bindings: pinctrl: samsung: add exynos8895-wakeup-eint compatible
Add a dedicated compatible for exynos8895.

Signed-off-by: Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20240920154508.1618410-7-ivo.ivanov.ivanov1@gmail.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2024-10-02 09:47:39 +02:00
Ivaylo Ivanov
724d52a3cd dt-bindings: pinctrl: samsung: Add compatible for Exynos8895 SoC
Add compatible for Exynos8895 SoC.

Signed-off-by: Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20240920154508.1618410-5-ivo.ivanov.ivanov1@gmail.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2024-10-02 09:47:24 +02:00
Ivaylo Ivanov
d27c76fcd4 dt-bindings: arm: cpus: Add Samsung Mongoose M2
Add a compatible for the Samsung Mongoose M2, found in exynos8895.

Signed-off-by: Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20240920154508.1618410-2-ivo.ivanov.ivanov1@gmail.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2024-10-02 09:46:43 +02:00
Tudor Ambarus
46b6256a68
mtd: spi-nor: sfdp: Get the 8D-8D-8D byte order from BFPT
Parse BFPT in order to retrieve the byte order in 8D-8D-8D mode.

This info flag will be used as a basis to determine whether
there is byte swapping of data for SPI NOR flash in octal
DTR mode.

The controller driver will check whether byte swapping is supported
to determine whether the corresponding operation are supported,
thus avoiding the generation of unexpected data order.

Merge Tudor's patch and add modifications for suiting newer version
of Linux kernel.

Reviewed-by: Michael Walle <mwalle@kernel.org>
Signed-off-by: JaimeLiao <jaimeliao@mxic.com.tw>
Signed-off-by: AlvinZhou <alvinzhou@mxic.com.tw>
Link: https://lore.kernel.org/r/20240926141956.2386374-5-alvinzhou.tw@gmail.com
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
2024-10-02 10:28:40 +03:00
Tudor Ambarus
6a42bc97cc
mtd: spi-nor: core: Allow specifying the byte order in Octal DTR mode
Macronix swaps bytes on a 16-bit boundary when configured in Octal DTR.
The byte order of 16-bit words is swapped when read or written in 8D-8D-8D
mode compared to STR modes. Allow operations to specify the byte order in
DTR mode, so that controllers can swap the bytes back at run-time to
address the flash's endianness requirements, if they are capable. If the
controller is not capable of swapping the bytes, the protocol is downgrade
via spi_nor_spimem_adjust_hwcaps(). When available, the swapping of the
bytes is always done regardless if it's a data or register access, so that
it comply with the JESD216 requirements: "Byte order of 16-bit words is
swapped when read in 8D-8D-8D mode compared to 1-1-1".

Merge Tudor's patch and add modifications for suiting newer version
of Linux kernel.

Suggested-by: Michael Walle <mwalle@kernel.org>
Signed-off-by: JaimeLiao <jaimeliao@mxic.com.tw>
Signed-off-by: AlvinZhou <alvinzhou@mxic.com.tw>
Link: https://lore.kernel.org/r/20240926141956.2386374-4-alvinzhou.tw@gmail.com
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
2024-10-02 10:23:56 +03:00
AlvinZhou
ccac858d2b
mtd: spi-nor: add Octal DTR support for Macronix flash
Create Macronix specify method for enable Octal DTR mode and
set 20 dummy cycles to allow running at the maximum supported
frequency for Macronix Octal flash.

Use number of dummy cycles which is parse by SFDP then convert
it to bit pattern and set in CR2 register.
Set CR2 register for enable octal DTR mode.

Use Read ID to confirm that enabling/disabling octal DTR mode
was successful.

Macronix ID format is A-A-B-B-C-C in octal DTR mode.
To ensure the successful enablement of octal DTR mode, confirm
that the 6-byte data is entirely correct.

Co-developed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Signed-off-by: JaimeLiao <jaimeliao@mxic.com.tw>
Signed-off-by: AlvinZhou <alvinzhou@mxic.com.tw>
Link: https://lore.kernel.org/r/20240926141956.2386374-2-alvinzhou.tw@gmail.com
2024-10-02 10:22:49 +03:00
Sean Anderson
d57df7a7b7 arm64: zynqmp: Add thermal zones
Add some thermal trip points. We can't undervolt the CPUs to save power
when we underclock them, so there isn't really a point in throttling
them until we are about to overheat. As such, the passive trip point is
right below the critical trip point.

The critical trip point is the extended/industrial-grade maximum
junction temperature of 100C minus the maximum temperature sensor error
of 3.5C (in the range -55C to 110C). Automotive- and military-grade
parts can go up to 125C, but as far as I can tell there is no way to
detect them at runtime. Userspace can adjust the trip points at runtime,
but this may not be viable when booting above 100C. I think it's
reasonable to ask automotive/military users to edit their device trees
to bump the trip points, but if that proves to be an issue we can
always go with no default temperatures. However, that wouldn't be too
nice for the majority of extended/industrial users.

Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
Link: https://lore.kernel.org/r/20240812215129.3599832-4-sean.anderson@linux.dev
Signed-off-by: Michal Simek <michal.simek@amd.com>
2024-10-02 09:21:26 +02:00
Sean Anderson
e279e4b2fa arm64: zynqmp: Expose AMS to userspace as HWMON
Expose the AMS to userspace, allowing monitoring of internal voltages
and temperatures. For compatibility, we keep the node name the same as
on the SM-K26, and we keep the ZCU100 Rev C. around (since it is named
differently).

Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
Link: https://lore.kernel.org/r/20240812215129.3599832-3-sean.anderson@linux.dev
Signed-off-by: Michal Simek <michal.simek@amd.com>
2024-10-02 09:21:25 +02:00
Sean Anderson
7e1ef5ccb0 arm64: zynqmp: Enable AMS for all boards
The AMS does not rely on external hardware or features, so it can be
enabled unconditionally.

Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
Link: https://lore.kernel.org/r/20240812215129.3599832-2-sean.anderson@linux.dev
Signed-off-by: Michal Simek <michal.simek@amd.com>
2024-10-02 09:21:25 +02:00
Michal Simek
badf752b5e microblaze: Export xmb_manager functions
When TMR_MANAGER is enabled as module there is a need to export functions
which are present in architecture code.

It has been found by running:
make W=1 C=1 allmodconfig
sed -i -e 's/WERROR=y/WERROR=n/g' .config
make C=1 W=1

which errors out like this:
ERROR: modpost: "xmb_manager_register" [drivers/misc/xilinx_tmr_manager.ko] undefined!
ERROR: modpost: "xmb_inject_err" [drivers/misc/xilinx_tmr_inject.ko] undefined!

Fixes: a5e3aaa654 ("microblaze: Add xmb_manager_register function")
Reported-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/e322dbbbde0feef83f44304ea13249d365d1dc5f.1718799090.git.michal.simek@amd.com
2024-10-02 09:18:54 +02:00
Ronak Jain
f33d6099ed firmware: xilinx: use u32 for reset ID in reset APIs
Refactors the reset handling mechanisms by replacing the reset ID's
enum type with a u32. This update improves flexibility, allowing the
reset ID to accommodate a broader range of values, including those
that may not fit into predefined enum values.

The use of u32 for reset ID enhances extensibility, especially for
hardware platforms or features where more granular control of reset
operations is required. By shifting to a general integer type, this
change reduces constraints and simplifies integration with other
system components that rely on non-enum-based reset IDs.

Signed-off-by: Ronak Jain <ronak.jain@amd.com>
Link: https://lore.kernel.org/r/20240830100042.3163511-1-ronak.jain@amd.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
2024-10-02 09:15:30 +02:00
Ronak Jain
848f2bbb36 firmware: xilinx: Add missing debug firmware interfaces
Add missing PM EEMI APIs interface in debug firmware driver.

The debugfs firmware driver interface is intended for testing and
debugging the EEMI APIs only. This interface does not contain any
checking regarding improper usage, and the number, type and valid
ranges of the arguments. This interface must be used with a lot of
care. In fact, accessing this interface during normal PM operation
will very likely cause unexpected problems.

The debugfs interface shouldn't be used in the production system and
hence it is disabled by default in defconfig.

Signed-off-by: Ronak Jain <ronak.jain@amd.com>
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/20240730084342.1683231-1-ronak.jain@amd.com
2024-10-02 09:15:30 +02:00
Gaosheng Cui
44ed4f90a9 drivers: soc: xilinx: add the missing kfree in xlnx_add_cb_for_suspend()
If we fail to allocate memory for cb_data by kmalloc, the memory
allocation for eve_data is never freed, add the missing kfree()
in the error handling path.

Fixes: 05e5ba40ea ("driver: soc: xilinx: Add support of multiple callbacks for same event in event management driver")
Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
Link: https://lore.kernel.org/r/20240706065155.452764-1-cuigaosheng1@huawei.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
2024-10-02 09:15:29 +02:00
Gaosheng Cui
4972111505 ARM: zynq: Remove unused zynq_slcr_init() declaration
The zynq_slcr_init() has been removed since
commit 3329659df0 ("ARM: zynq: Simplify SLCR initialization"),
so remove it.

Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
Link: https://lore.kernel.org/r/20240813103556.1138061-1-cuigaosheng1@huawei.com
Signed-off-by: Michal Simek <michal.simek@amd.com>
2024-10-02 09:13:08 +02:00
Masahiro Yamada
984ed20ece kconfig: qconf: fix buffer overflow in debug links
If you enable "Option -> Show Debug Info" and click a link, the program
terminates with the following error:

    *** buffer overflow detected ***: terminated

The buffer overflow is caused by the following line:

    strcat(data, "$");

The buffer needs one more byte to accommodate the additional character.

Fixes: c4f7398bee ("kconfig: qconf: make debug links work again")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-10-02 16:02:40 +09:00
AlvinZhou
50cb86f21e
spi: mxic: Add support for swapping byte
Some SPI-NOR flash swap the bytes on a 16-bit boundary when
configured in Octal DTR mode. It means data format D0 D1 D2 D3
would be swapped to D1 D0 D3 D2. So that whether controller
support swapping bytes should be checked before enable Octal
DTR mode. Add swap byte support on a 16-bit boundary when
configured in Octal DTR mode for Macronix xSPI host controller
driver.

According dtr_swab in operation to enable/disable Macronix
xSPI host controller swap byte feature.

To make sure swap byte feature is working well, program data in
1S-1S-1S mode then read back and compare read data in 8D-8D-8D
mode.

This feature have been validated on byte-swap flash and
non-byte-swap flash.

Macronix xSPI host controller bit "HC_CFG_DATA_PASS" determine
the byte swap feature disabled/enabled and swap byte feature is
working on 8D-8D-8D mode only.

Suggested-by: Michael Walle <mwalle@kernel.org>
Signed-off-by: JaimeLiao <jaimeliao@mxic.com.tw>
Signed-off-by: AlvinZhou <alvinzhou@mxic.com.tw>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20240926141956.2386374-6-alvinzhou.tw@gmail.com
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
2024-10-02 09:44:57 +03:00
Tudor Ambarus
030ace430a
spi: spi-mem: Allow specifying the byte order in Octal DTR mode
There are NOR flashes (Macronix) that swap the bytes on a 16-bit
boundary when configured in Octal DTR mode. The byte order of
16-bit words is swapped when read or written in Octal Double
Transfer Rate (DTR) mode compared to Single Transfer Rate (STR)
modes. If one writes D0 D1 D2 D3 bytes using 1-1-1 mode, and uses
8D-8D-8D SPI mode for reading, it will read back D1 D0 D3 D2.
Swapping the bytes may introduce some endianness problems. It can
affect the boot sequence if the entire boot sequence is not handled
in either 8D-8D-8D mode or 1-1-1 mode. Therefore, it is necessary
to swap the bytes back to ensure the same byte order as in STR modes.
Fortunately there are controllers that could swap the bytes back at
runtime, addressing the flash's endianness requirements. Provide a
way for the upper layers to specify the byte order in Octal DTR mode.

Merge Tudor's patch and add modifications for suiting newer version
of Linux kernel.

Suggested-by: Michael Walle <mwalle@kernel.org>
Signed-off-by: JaimeLiao <jaimeliao@mxic.com.tw>
Signed-off-by: AlvinZhou <alvinzhou@mxic.com.tw>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20240926141956.2386374-3-alvinzhou.tw@gmail.com
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
2024-10-02 09:44:56 +03:00
Abhishek Tamboli
d75dba4974 ALSA: hda/realtek: Add a quirk for HP Pavilion 15z-ec200
Add the quirk for HP Pavilion Gaming laptop 15z-ec200 for
enabling the mute led. The fix apply the ALC285_FIXUP_HP_MUTE_LED
quirk for this model.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=219303
Signed-off-by: Abhishek Tamboli <abhishektamboli9@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://patch.msgid.link/20240930145300.4604-1-abhishektamboli9@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-10-02 08:15:54 +02:00
Takashi Iwai
864773f9e7 ALSA: hda/generic: Drop obsoleted obey_preferred_dacs flag
Now we evaluate directly with preferred_dacs table, the flag is no
longer used and merely a placeholder.
Let's drop the definition and its users.

Link: https://patch.msgid.link/20241001121439.26060-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-10-02 08:13:47 +02:00
Takashi Iwai
1c801e7f77 ALSA: hda/generic: Unconditionally prefer preferred_dacs pairs
Some time ago, we introduced the obey_preferred_dacs flag for choosing
the DAC/pin pairs specified by the driver instead of parsing the
paths.  This works as expected, per se, but there have been a few
cases where we forgot to set this flag while preferred_dacs table is
already set up.  It ended up with incorrect wiring and made us
wondering why it doesn't work.

Basically, when the preferred_dacs table is provided, it means that
the driver really wants to wire up to follow that.  That is, the
presence of the preferred_dacs table itself is already a "do-it"
flag.

In this patch, we simply replace the evaluation of obey_preferred_dacs
flag with the presence of preferred_dacs table for fixing the
misbehavior.  Another patch to drop of the obsoleted flag will
follow.

Fixes: 242d990c15 ("ALSA: hda/generic: Add option to enforce preferred_dacs pairs")
Link: https://bugzilla.suse.com/show_bug.cgi?id=1219803
Link: https://patch.msgid.link/20241001121439.26060-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2024-10-02 08:13:34 +02:00
Hongbo Li
05fba0a115
fs: support relative paths with FSCONFIG_SET_STRING
The fs_lookup_param did not consider the relative path for block device.
When we mount ext4 with journal_path option using relative path,
param->dirfd was not set which will cause mounting error.

This can be reproduced easily like this:

mke2fs -F -O journal_dev $JOURNAL_DEV -b 4096 100M
mkfs.ext4 -F -J device=$JOURNAL_DEV -b 4096 $FS_DEV
cd /dev; mount -t ext4 -o journal_path=`basename $JOURNAL_DEV` $FS_DEV $MNT

Fixes: 461c3af045 ("ext4: Change handle_mount_opt() to use fs_parameter")
Suggested-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Hongbo Li <lihongbo22@huawei.com>
Link: https://lore.kernel.org/r/20240925015624.3817878-1-lihongbo22@huawei.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-10-02 07:52:33 +02:00
Trond Myklebust
9d926f10b7
filemap: filemap_read() should check that the offset is positive or zero
We do check that the read offset is less than the filesystem limit,
however for good measure we should also check that it is positive or
zero, and return EINVAL if that is not the case.

Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Link: https://lore.kernel.org/r/482ee0b8a30b62324adb9f7c551a99926f037393.1726257832.git.trond.myklebust@hammerspace.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-10-02 07:52:12 +02:00
Christian Brauner
2b2b1a20db
Merge patch series "Introduce tracepoint for hugetlbfs"
Hongbo Li <lihongbo22@huawei.com> says:

Add some basic tracepoints for debugging hugetlbfs: {alloc, free,
evict}_inode, setattr and fallocate.

* patches from https://lore.kernel.org/r/20240829064110.67884-1-lihongbo22@huawei.com:
  hugetlbfs: use tracepoints in hugetlbfs functions.
  hugetlbfs: support tracepoint

Link: https://lore.kernel.org/r/20240829064110.67884-1-lihongbo22@huawei.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-10-02 07:52:11 +02:00
Christian Brauner
09ee2a670d
Merge patch series "Fixup NLM and kNFSD file lock callbacks"
Benjamin Coddington <bcodding@redhat.com> says:

Last year both GFS2 and OCFS2 had some work done to make their locking more
robust when exported over NFS.  Unfortunately, part of that work caused both
NLM (for NFS v3 exports) and kNFSD (for NFSv4.1+ exports) to no longer send
lock notifications to clients.

This in itself is not a huge problem because most NFS clients will still
poll the server in order to acquire a conflicted lock, but now that I've
noticed it I can't help but try to fix it because there are big advantages
for setups that might depend on timely lock notifications, and we've
supported that as a feature for a long time.

Its important for NLM and kNFSD that they do not block their kernel threads
inside filesystem's file_lock implementations because that can produce
deadlocks.  We used to make sure of this by only trusting that
posix_lock_file() can correctly handle blocking lock calls asynchronously,
so the lock managers would only setup their file_lock requests for async
callbacks if the filesystem did not define its own lock() file operation.

However, when GFS2 and OCFS2 grew the capability to correctly
handle blocking lock requests asynchronously, they started signalling this
behavior with EXPORT_OP_ASYNC_LOCK, and the check for also trusting
posix_lock_file() was inadvertently dropped, so now most filesystems no
longer produce lock notifications when exported over NFS.

I tried to fix this by simply including the old check for lock(), but the
resulting include mess and layering violations was more than I could accept.
There's a much cleaner way presented here using an fop_flag, which while
potentially flag-greedy, greatly simplifies the problem and grooms the
way for future uses by both filesystems and lock managers alike.

* patches from https://lore.kernel.org/r/cover.1726083391.git.bcodding@redhat.com:
  exportfs: Remove EXPORT_OP_ASYNC_LOCK
  NLM/NFSD: Fix lock notifications for async-capable filesystems
  gfs2/ocfs2: set FOP_ASYNC_LOCK
  fs: Introduce FOP_ASYNC_LOCK
  NFS: trace: show TIMEDOUT instead of 0x6e
  nfsd: use system_unbound_wq for nfsd_file_gc_worker()
  nfsd: count nfsd_file allocations
  nfsd: fix refcount leak when file is unhashed after being found
  nfsd: remove unneeded EEXIST error check in nfsd_do_file_acquire
  nfsd: add list_head nf_gc to struct nfsd_file

Link: https://lore.kernel.org/r/cover.1726083391.git.bcodding@redhat.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-10-02 07:52:07 +02:00
Al Viro
0d0b8646a6 ufs_rename(): fix bogus argument of folio_release_kmap()
new_dir does *NOT* point into dir_folio - it's an inode, not a pointer
to ufs directory entry.

Fixes: 516b97cf03 "ufs: Convert directory handling to kmap_local"
Acked-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2024-10-02 00:05:09 -04:00
Al Viro
134d988208 parisc: get rid of private asm/unaligned.h
Declarations local to arch/*/kernel/*.c are better off *not* in a public
header - arch/parisc/kernel/unaligned.h is just fine for those
bits.

With that done parisc asm/unaligned.h is reduced to include
of asm-generic/unaligned.h and can be removed - unaligned.h is in
mandatory-y in include/asm-generic/Kbuild.

Acked-by: Helge Deller <deller@gmx.de>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2024-10-01 23:20:41 -04:00
wangrong
a421e3fe0e smb: client: use actual path when queryfs
Due to server permission control, the client does not have access to
the shared root directory, but can access subdirectories normally, so
users usually mount the shared subdirectories directly. In this case,
queryfs should use the actual path instead of the root directory to
avoid the call returning an error (EACCES).

Signed-off-by: wangrong <wangrong@uniontech.com>
Reviewed-by: Paulo Alcantara (Red Hat) <pc@manguebit.com>
Cc: stable@vger.kernel.org
Signed-off-by: Steve French <stfrench@microsoft.com>
2024-10-01 21:47:16 -05:00
Rob Herring (Arm)
44dae95e61 ARM: dts: socfpga: Fix at24 EEPROM node names
at24.yaml defines the node name for at24 EEPROMs as 'eeprom'.

Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2024-10-01 21:35:49 -05:00
Rob Herring (Arm)
a6fa1f9e32 dt-bindings: Fix array property constraints
Schemas for array properties should only have 1 level of array
constraints (e.g. items, maxItems, minItems). Sometimes the old
encoding of all properties into a matrix leaked into the schema, and
didn't matter for validation. Now the inner constraints are just
silently ignored as json-schema array keywords are ignored on scalar
values.

Generally, keep the inner constraints and drop the outer "items". With
gicv3 "mbi-alias" property, it is more appropriately a uint32 or uint64
as it is an address and size depends on "#address-cells".

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20240925232409.2208515-1-robh@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-10-01 21:17:00 -05:00
Rob Herring (Arm)
b70ea87819 dt-bindings: interrupt-controller: fsl,mu-msi: Drop "interrupt-controller" property
The Freescale MU-MSI is an MSI provider, not an interrupt provider, so
drop the "interrupt-controller" property. This fixes dtc "interrupt_provider"
warning.

Reviewed-by: Frank Li <Frank.Li@nxp.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20240925173438.1906339-1-robh@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-10-01 21:16:29 -05:00
Rob Herring (Arm)
c5f02e0218 dt-bindings: interrupt-controller: ti,sci-inta: Add missing "#interrupt-cells" to example
Enabling dtc interrupt_provider check reveals the example is missing
the "#interrupt-cells" property as it is a dependency of
"interrupt-controller".

Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20240925173432.1906168-1-robh@kernel.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2024-10-01 21:16:12 -05:00