summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-09-10samples: rust: Add debugfs sample driverMatthew Maurer
Adds a new sample driver that demonstrates the debugfs APIs. The driver creates a directory in debugfs and populates it with a few files: - A read-only file that displays a fwnode property. - A read-write file that exposes an atomic counter. - A read-write file that exposes a custom struct. This sample serves as a basic example of how to use the `debugfs::Dir` and `debugfs::File` APIs to create and manage debugfs entries. Signed-off-by: Matthew Maurer <mmaurer@google.com> Tested-by: Dirk Behme <dirk.behme@de.bosch.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250904-debugfs-rust-v11-5-7d12a165685a@google.com [ Change ACPI ID "LNUXDEBF" to "LNUXBEEF". - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-09-10rust: debugfs: Add support for callback-based filesMatthew Maurer
Extends the `debugfs` API to support creating files with content generated and updated by callbacks. This is done via the `read_callback_file`, `write_callback_file`, and `read_write_callback_file` methods. These methods allow for more flexible file definition, either because the type already has a `Writer` or `Reader` method that doesn't do what you'd like, or because you cannot implement it (e.g. because it's a type defined in another crate or a primitive type). Signed-off-by: Matthew Maurer <mmaurer@google.com> Tested-by: Dirk Behme <dirk.behme@de.bosch.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250904-debugfs-rust-v11-4-7d12a165685a@google.com [ Fix up Result<(), Error> -> Result. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-09-10rust: debugfs: Add support for writable filesMatthew Maurer
Extends the `debugfs` API to support creating writable files. This is done via the `Dir::write_only_file` and `Dir::read_write_file` methods, which take a data object that implements the `Reader` trait. Signed-off-by: Matthew Maurer <mmaurer@google.com> Tested-by: Dirk Behme <dirk.behme@de.bosch.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250904-debugfs-rust-v11-3-7d12a165685a@google.com [ Fix up Result<()> -> Result. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-09-10rust: debugfs: Add support for read-only filesMatthew Maurer
Extends the `debugfs` API to support creating read-only files. This is done via the `Dir::read_only_file` method, which takes a data object that implements the `Writer` trait. The file's content is generated by the `Writer` implementation, and the file is automatically removed when the returned `File` handle is dropped. Signed-off-by: Matthew Maurer <mmaurer@google.com> Tested-by: Dirk Behme <dirk.behme@de.bosch.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250904-debugfs-rust-v11-2-7d12a165685a@google.com [ Fixup build failure when CONFIG_DEBUGFS=n. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-09-10rust: debugfs: Add initial support for directoriesMatthew Maurer
Adds a `debugfs::Dir` type that can be used to create and remove DebugFS directories. The `Dir` handle automatically cleans up the directory on `Drop`. Signed-off-by: Matthew Maurer <mmaurer@google.com> Tested-by: Dirk Behme <dirk.behme@de.bosch.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250904-debugfs-rust-v11-1-7d12a165685a@google.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-09-10phy: rockchip: phy-rockchip-inno-csidphy: allow for different reset linesMichael Riesch
The RK3588 MIPI CSI-2 DPHY variant requires two reset lines. Add support for different sets of reset lines to the phy-rockchip-inno-csidphy driver as preparation for the introduction of the RK3588 variant. Signed-off-by: Michael Riesch <michael.riesch@collabora.com> Link: https://lore.kernel.org/r/20250616-rk3588-csi-dphy-v4-5-a4f340a7f0cf@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-09-10phy: rockchip: phy-rockchip-inno-csidphy: allow writes to grf register 0Michael Riesch
The driver for the Rockchip MIPI CSI-2 DPHY uses GRF register offset value 0 to sort out undefined registers. However, the RK3588 CSIDPHY GRF this offset is perfectly fine (in fact, register 0 is the only one in this register file). Introduce a boolean variable to indicate valid registers and allow writes to register 0. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Michael Riesch <michael.riesch@collabora.com> Link: https://lore.kernel.org/r/20250616-rk3588-csi-dphy-v4-4-a4f340a7f0cf@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-09-10dt-bindings: phy: rockchip-inno-csi-dphy: add rk3588 variantMichael Riesch
The Rockchip RK3588 variant of the CSI-2 DPHY features two reset lines. Add the variant and allow for the additional reset. While at it, fix the description of the first reset in order to avoid confusion. Signed-off-by: Michael Riesch <michael.riesch@collabora.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250616-rk3588-csi-dphy-v4-3-a4f340a7f0cf@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-09-10dt-bindings: phy: rockchip-inno-csi-dphy: make power-domains non-requiredMichael Riesch
There are variants of the Rockchip Innosilicon CSI DPHY (e.g., the RK3568 variant) that are powered on by default as they are part of the ALIVE power domain. Remove 'power-domains' from the required properties in order to avoid false positives. Fixes: 22c8e0a69b7f ("dt-bindings: phy: add compatible for rk356x to rockchip-inno-csi-dphy") Cc: stable@kernel.org Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Michael Riesch <michael.riesch@collabora.com> Link: https://lore.kernel.org/r/20250616-rk3588-csi-dphy-v4-2-a4f340a7f0cf@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-09-10phy: cadence: cdns-dphy: Enable lower resolutions in dphyHarikrishna Shenoy
Enable support for data lane rates between 80-160 Mbps cdns dphy as mentioned in TRM [0] by setting the pll_opdiv field to 16. This change enables lower resolutions like 640x480 at 60Hz. [0]: https://www.ti.com/lit/zip/spruil1 (Table 12-552. DPHY_TX_PLL_CTRL Register Field Descriptions) Reviewed-by: Udit Kumar <u-kumar1@ti.com> Reviewed-by: Devarsh Thakkar <devarsht@ti.com> Signed-off-by: Harikrishna Shenoy <h-shenoy@ti.com> Link: https://lore.kernel.org/r/20250807052002.717807-1-h-shenoy@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-09-10arm64: dts: allwinner: t527: avaota-a1: Add ethernet PHY reset settingChen-Yu Tsai
The external Ethernet PHY has a reset pin that is connected to the SoC. It is missing from the original submission. Add it to complete the description. Fixes: c6800f15998b ("arm64: dts: allwinner: t527: add EMAC0 to Avaota-A1 board") Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20250908181059.1785605-9-wens@kernel.org Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2025-09-10arm64: dts: allwinner: a527: cubie-a5e: Add ethernet PHY reset settingChen-Yu Tsai
The external Ethernet PHY has a reset pin that is connected to the SoC. It is missing from the original submission. Add it to complete the description. Fixes: acca163f3f51 ("arm64: dts: allwinner: a527: add EMAC0 to Radxa A5E board") Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20250908181059.1785605-7-wens@kernel.org Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2025-09-10clk: sunxi-ng: mp: Fix dual-divider clock rate readbackChen-Yu Tsai
When dual-divider clock support was introduced, the P divider offset was left out of the .recalc_rate readback function. This causes the clock rate to become bogus or even zero (possibly due to the P divider being 1, leading to a divide-by-zero). Fix this by incorporating the P divider offset into the calculation. Fixes: 45717804b75e ("clk: sunxi-ng: mp: introduce dual-divider clock") Reviewed-by: Andre Przywara <andre.przywara@arm.com> Link: https://patch.msgid.link/20250830170901.1996227-4-wens@kernel.org Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2025-09-10phy: renesas: r8a779f0-ether-serdes: add new step added to latest datasheetMichael Dege
R-Car S4-8 datasheet Rev.1.20 describes some additional register settings at the end of the initialization. Signed-off-by: Michael Dege <michael.dege@renesas.com> Link: https://lore.kernel.org/r/20250703-renesas-serdes-update-v4-2-1db5629cac2b@renesas.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-09-10phy: renesas: r8a779f0-ether-serdes: add USXGMII modeMichael Dege
The initial driver implementation was limited to SGMII and 1GBit/s. The new mode allows speeds up to 2.5GBit/s on R-Car S4-8 SOCs. Signed-off-by: Michael Dege <michael.dege@renesas.com> Link: https://lore.kernel.org/r/20250703-renesas-serdes-update-v4-1-1db5629cac2b@renesas.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-09-10x86/startup/sev: Document the CPUID flow in the boot #VC handlerTom Lendacky
Document the CPUID reading the different SEV guest types do - the SNP one which relies on the presence of a CPUID table and the SEV-ES one, which reads the CPUID supplied by the hypervisor. The intent being to clarify the two back-to-back, similar CPUID invocations. No functional changes. [ bp: Turn into a proper patch. ] Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/fbb24767-0e06-d1d6-36e0-1757d98aca66@amd.com
2025-09-10phy: sophgo: Add USB 2.0 PHY driver for Sophgo CV18XX/SG200XInochi Amaoto
Add USB 2.0 PHY driver for Sophgo CV18XX/SG200X. Currently this driver does not support OTG mode as lack of document. Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Tested-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Link: https://lore.kernel.org/r/20250708063038.497473-3-inochiama@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-09-10dt-bindings: phy: Add Sophgo CV1800 USB phyInochi Amaoto
The USB phy of Sophgo CV18XX series SoC needs to sense a pin called "VBUS_DET" to get the right operation mode. If this pin is not connected, it only supports setting the mode manually. Add USB phy bindings for Sophgo CV18XX/SG200X series SoC. Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20250708063038.497473-2-inochiama@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-09-10printk: kunit: support offstack cpumaskArnd Bergmann
For large values of CONFIG_NR_CPUS, the newly added kunit test fails to build: kernel/printk/printk_ringbuffer_kunit_test.c: In function 'test_readerwriter': kernel/printk/printk_ringbuffer_kunit_test.c:279:1: error: the frame size of 1432 bytes is larger than 1280 bytes [-Werror=frame-larger-than=] Change this to use cpumask_var_t and allocate it dynamically when CONFIG_CPUMASK_OFFSTACK is set. The variable has to be released via a KUnit action wrapper so that it is freed when the test fails and gets aborted. The parameter type is hardcoded to "struct cpumask *" because the macro KUNIT_DEFINE_ACTION_WRAPPER() does not accept an array. But the function does nothing when CONFIG_CPUMASK_OFFSTACK is not set anyway. Fixes: 5ea2bcdfbf46 ("printk: ringbuffer: Add KUnit test") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/all/20250620192554.2234184-1-arnd@kernel.org # v1 [pmladek@suse.com: Correctly handle allocation failures and freeing using KUnit test API.] Link: https://lore.kernel.org/all/20250702095157.110916-3-pmladek@suse.com # v2 Signed-off-by: Petr Mladek <pmladek@suse.com>
2025-09-10phy: cadence: cdns-dphy: Update calibration wait time for startup state machineDevarsh Thakkar
Do read-modify-write so that we re-use the characterized reset value as specified in TRM [1] to program calibration wait time which defines number of cycles to wait for after startup state machine is in bandgap enable state. This fixes PLL lock timeout error faced while using RPi DSI Panel on TI's AM62L and J721E SoC since earlier calibration wait time was getting overwritten to zero value thus failing the PLL to lockup and causing timeout. [1] AM62P TRM (Section 14.8.6.3.2.1.1 DPHY_TX_DPHYTX_CMN0_CMN_DIG_TBIT2): Link: https://www.ti.com/lit/pdf/spruj83 Cc: stable@vger.kernel.org Fixes: 7a343c8bf4b5 ("phy: Add Cadence D-PHY support") Signed-off-by: Devarsh Thakkar <devarsht@ti.com> Tested-by: Harikrishna Shenoy <h-shenoy@ti.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://lore.kernel.org/r/20250704125915.1224738-3-devarsht@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-09-10phy: cadence: cdns-dphy: Fix PLL lock and O_CMN_READY pollingDevarsh Thakkar
PLL lockup and O_CMN_READY assertion can only happen after common state machine gets enabled by programming DPHY_CMN_SSM register, but driver was polling them before the common state machine was enabled which is incorrect. This is as per the DPHY initialization sequence as mentioned in J721E TRM [1] at section "12.7.2.4.1.2.1 Start-up Sequence Timing Diagram". It shows O_CMN_READY polling at the end after common configuration pin setup where the common configuration pin setup step enables state machine as referenced in "Table 12-1533. Common Configuration-Related Setup mentions state machine" To fix this : - Add new function callbacks for polling on PLL lock and O_CMN_READY assertion. - As state machine and clocks get enabled in power_on callback only, move the clock related programming part from configure callback to power_on callback and poll for the PLL lockup and O_CMN_READY assertion after state machine gets enabled. - The configure callback only saves the PLL configuration received from the client driver which will be applied later on in power_on callback. - Add checks to ensure configure is called before power_on and state machine is in disabled state before power_on callback is called. - Disable state machine in power_off so that client driver can re-configure the PLL by following up a power_off, configure, power_on sequence. [1]: https://www.ti.com/lit/zip/spruil1 Cc: stable@vger.kernel.org Fixes: 7a343c8bf4b5 ("phy: Add Cadence D-PHY support") Signed-off-by: Devarsh Thakkar <devarsht@ti.com> Tested-by: Harikrishna Shenoy <h-shenoy@ti.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://lore.kernel.org/r/20250704125915.1224738-2-devarsht@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-09-10can: rcar_can: rcar_can_resume(): fix s2ram with PSCIGeert Uytterhoeven
On R-Car Gen3 using PSCI, s2ram powers down the SoC. After resume, the CAN interface no longer works, until it is brought down and up again. Fix this by calling rcar_can_start() from the PM resume callback, to fully initialize the controller instead of just restarting it. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/699b2f7fcb60b31b6f976a37f08ce99c5ffccb31.1755165227.git.geert+renesas@glider.be Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-10can: xilinx_can: xcan_write_frame(): fix use-after-free of transmitted SKBAnssi Hannula
can_put_echo_skb() takes ownership of the SKB and it may be freed during or after the call. However, xilinx_can xcan_write_frame() keeps using SKB after the call. Fix that by only calling can_put_echo_skb() after the code is done touching the SKB. The tx_lock is held for the entire xcan_write_frame() execution and also on the can_get_echo_skb() side so the order of operations does not matter. An earlier fix commit 3d3c817c3a40 ("can: xilinx_can: Fix usage of skb memory") did not move the can_put_echo_skb() call far enough. Signed-off-by: Anssi Hannula <anssi.hannula@bitwise.fi> Fixes: 1598efe57b3e ("can: xilinx_can: refactor code in preparation for CAN FD support") Link: https://patch.msgid.link/20250822095002.168389-1-anssi.hannula@bitwise.fi [mkl: add "commit" in front of sha1 in patch description] [mkl: fix indention] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-10can: j1939: j1939_local_ecu_get(): undo increment when j1939_local_ecu_get() ↵Tetsuo Handa
fails Since j1939_sk_bind() and j1939_sk_release() call j1939_local_ecu_put() when J1939_SOCK_BOUND was already set, but the error handling path for j1939_sk_bind() will not set J1939_SOCK_BOUND when j1939_local_ecu_get() fails, j1939_local_ecu_get() needs to undo priv->ents[sa].nusers++ when j1939_local_ecu_get() returns an error. Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Tested-by: Oleksij Rempel <o.rempel@pengutronix.de> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://patch.msgid.link/e7f80046-4ff7-4ce2-8ad8-7c3c678a42c9@I-love.SAKURA.ne.jp Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-10can: j1939: j1939_sk_bind(): call j1939_priv_put() immediately when ↵Tetsuo Handa
j1939_local_ecu_get() failed Commit 25fe97cb7620 ("can: j1939: move j1939_priv_put() into sk_destruct callback") expects that a call to j1939_priv_put() can be unconditionally delayed until j1939_sk_sock_destruct() is called. But a refcount leak will happen when j1939_sk_bind() is called again after j1939_local_ecu_get() from previous j1939_sk_bind() call returned an error. We need to call j1939_priv_put() before j1939_sk_bind() returns an error. Fixes: 25fe97cb7620 ("can: j1939: move j1939_priv_put() into sk_destruct callback") Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Tested-by: Oleksij Rempel <o.rempel@pengutronix.de> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://patch.msgid.link/4f49a1bc-a528-42ad-86c0-187268ab6535@I-love.SAKURA.ne.jp Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-10can: j1939: implement NETDEV_UNREGISTER notification handlerTetsuo Handa
syzbot is reporting unregister_netdevice: waiting for vcan0 to become free. Usage count = 2 problem, for j1939 protocol did not have NETDEV_UNREGISTER notification handler for undoing changes made by j1939_sk_bind(). Commit 25fe97cb7620 ("can: j1939: move j1939_priv_put() into sk_destruct callback") expects that a call to j1939_priv_put() can be unconditionally delayed until j1939_sk_sock_destruct() is called. But we need to call j1939_priv_put() against an extra ref held by j1939_sk_bind() call (as a part of undoing changes made by j1939_sk_bind()) as soon as NETDEV_UNREGISTER notification fires (i.e. before j1939_sk_sock_destruct() is called via j1939_sk_release()). Otherwise, the extra ref on "struct j1939_priv" held by j1939_sk_bind() call prevents "struct net_device" from dropping the usage count to 1; making it impossible for unregister_netdevice() to continue. Reported-by: syzbot <syzbot+881d65229ca4f9ae8c84@syzkaller.appspotmail.com> Closes: https://syzkaller.appspot.com/bug?extid=881d65229ca4f9ae8c84 Tested-by: syzbot <syzbot+881d65229ca4f9ae8c84@syzkaller.appspotmail.com> Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Fixes: 25fe97cb7620 ("can: j1939: move j1939_priv_put() into sk_destruct callback") Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Tested-by: Oleksij Rempel <o.rempel@pengutronix.de> Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://patch.msgid.link/ac9db9a4-6c30-416e-8b94-96e6559d55b2@I-love.SAKURA.ne.jp [mkl: remove space in front of label] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-10selftests: can: enable CONFIG_CAN_VCAN as a moduleDavide Caratti
A proper kernel configuration for running kselftest can be obtained with: $ yes | make kselftest-merge Build of 'vcan' driver is currently missing, while the other required knobs are already there because of net/link_netns.py [1]. Add a config file in selftests/net/can to store the minimum set of kconfig needed for CAN selftests. [1] https://patch.msgid.link/20250219125039.18024-14-shaw.leon@gmail.com Fixes: 77442ffa83e8 ("selftests: can: Import tst-filter from can-tests") Reviewed-by: Vincent Mailhol <mailhol@kernel.org> Signed-off-by: Davide Caratti <dcaratti@redhat.com> Link: https://patch.msgid.link/fa4c0ea262ec529f25e5f5aa9269d84764c67321.1757516009.git.dcaratti@redhat.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2025-09-10cxl/acpi: Rename CFMW coherency restrictionsDavidlohr Bueso
ACPICA commit 710745713ad3a2543dbfb70e84764f31f0e46bdc This has been renamed in more recent CXL specs, as type3 (memory expanders) can also use HDM-DB for device coherent memory. Link: https://github.com/acpica/acpica/commit/710745713ad3a2543dbfb70e84764f31f0e46bdc Acked-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Signed-off-by: Davidlohr Bueso <dave@stgolabs.net> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Gregory Price <gourry@gourry.net> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Link: https://patch.msgid.link/20250908160034.86471-1-dave@stgolabs.net Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2025-09-10Merge branch 'for-6.18/cxl-update-access-coordinates' into cxl-for-nextDave Jiang
Update the CXL memory hotplug notifier to update the NUMA node access coordinates directly rather than go through the HMAT memory hotplug notifier.
2025-09-10Documentation/driver-api: Fix typo error in cxlRakuram Eswaran
Fixed the following typo errors intersparsed ==> interspersed in Documentation/driver-api/cxl/platform/bios-and-efi.rst Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Gregory Price <gourry@gourry.net> Link: https://patch.msgid.link/20250818175335.5312-1-rakuram.e96@gmail.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2025-09-10DRM: Add a new 'boot_display' attributeMario Limonciello (AMD)
On systems with multiple GPUs there can be uncertainty which GPU is the primary one used to drive the display at bootup. In some desktop environments this can lead to increased power consumption because secondary GPUs may be used for rendering and never go to a low power state. In order to disambiguate this add a new sysfs attribute 'boot_display' that uses the output of video_is_primary_device() to populate whether the PCI device was used for driving the display. Suggested-by: Manivannan Sadhasivam <mani@kernel.org> Acked-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://gitlab.freedesktop.org/xorg/lib/libpciaccess/-/issues/23 Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20250811162606.587759-5-superm1@kernel.org Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2025-09-10fbcon: Use screen info to find primary deviceMario Limonciello (AMD)
On systems with non VGA GPUs fbcon can't find the primary GPU because video_is_primary_device() only checks the VGA arbiter. Add a screen info check to video_is_primary_device() so that callers can get accurate data on such systems. Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Suggested-by: Thomas Zimmermann <tzimmermann@suse.de> Suggested-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20250811162606.587759-4-superm1@kernel.org Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2025-09-10PCI/VGA: Replace vga_is_firmware_default() with a screen info checkMario Limonciello (AMD)
vga_is_firmware_default() checks firmware resources to find the owner framebuffer resources to find the firmware PCI device. This is an open coded implementation of screen_info_pci_dev(). Switch to using screen_info_pci_dev() instead. Acked-by: Bjorn Helgaas <bhelgaas@google.com> Suggested-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20250811162606.587759-3-superm1@kernel.org Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2025-09-10Fix access to video_is_primary_device() when compiled without CONFIG_VIDEOMario Limonciello (AMD)
When compiled without CONFIG_VIDEO the architecture specific implementations of video_is_primary_device() include prototypes and assume that video-common.c will be linked. Guard against this so that the fallback inline implementation that returns false will be used when compiled without CONFIG_VIDEO. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202506221312.49Fy1aNA-lkp@intel.com/ Link: https://lore.kernel.org/r/20250811162606.587759-2-superm1@kernel.org Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
2025-09-10io_uring: replace use of system_unbound_wq with system_dfl_wqMarco Crivellari
Currently if a user enqueue a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistentcy cannot be addressed without refactoring the API. system_unbound_wq should be the default workqueue so as not to enforce locality constraints for random work whenever it's not required. Adding system_dfl_wq to encourage its use when unbound work should be used. queue_work() / queue_delayed_work() / mod_delayed_work() will now use the new unbound wq: whether the user still use the old wq a warn will be printed along with a wq redirect to the new one. The old system_unbound_wq will be kept for a few release cycles. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-09-10io_uring: replace use of system_wq with system_percpu_wqMarco Crivellari
Currently if a user enqueue a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistentcy cannot be addressed without refactoring the API. system_wq is a per-CPU worqueue, yet nothing in its name tells about that CPU affinity constraint, which is very often not required by users. Make it clear by adding a system_percpu_wq. queue_work() / queue_delayed_work() mod_delayed_work() will now use the new per-cpu wq: whether the user still stick on the old name a warn will be printed along a wq redirect to the new one. This patch add the new system_percpu_wq except for mm, fs and net subsystem, whom are handled in separated patches. The old wq will be kept for a few release cylces. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-09-10arm64: versal-net: Describe L1/L2/L3/LLC cachesMichal Simek
Add missing cache layout description. Signed-off-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/f740bf2d0af1e7e50d76196ec050c0fdbeceb049.1757338426.git.michal.simek@amd.com
2025-09-10arm64: zynqmp: Enable DP in kr260/kv260 revAMichal Simek
Enable DP output in both CC (Carrier Cards). Signed-off-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/3160658ea2c4dd09a1d68918271177cf55437a8f.1756799774.git.michal.simek@amd.com
2025-09-10arm64: zynqmp: Describe ethernet controllers via aliases on SOMMichal Simek
Add ethernet aliases to CC (Carrier card) description to create a connection which is used by U-BOOT (fdt_fixup_ethernet()) for updating local-mac-address in DT. On Kria SOM MAC address is read from i2c eeprom at start and based on it environment variables are created. Without creating aliases U-Boot is not able to inject local-mac-address DT property and OS won't get the same MAC address unless another i2c read is happening in OS. Also aliases are using string not phandle (because of dtso) that's why full path has to be provided but that shouldn't be a big issue because location of ethernet controller is fixed. Signed-off-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/72304150f87fd5e3338e31e2be8cf5d29955cc02.1756799774.git.michal.simek@amd.com
2025-09-10arm64: zynqmp: Revert usb node drive strength and slew rate for zcu106Radhey Shyam Pandey
On a few zcu106 boards USB devices (Dell MS116 USB Optical Mouse, Dell USB Entry Keyboard) are not enumerated on linux boot due to commit 'b8745e7eb488 ("arm64: zynqmp: Fix usb node drive strength and slew rate")'. To fix it as a workaround revert to working version and then investigate at board level why drive strength from 12mA to 4mA and slew from fast to slow is not working. 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/85a70cb014ec1f07972fccb60b875596eeaa6b5c.1756799774.git.michal.simek@amd.com
2025-09-10arm64: zynqmp: Disable coresight by defaultQuanyang Wang
When secure-boot mode of bootloader is enabled, the registers of coresight are not permitted to access that's why disable it by default. Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com> Signed-off-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/7e308b8efe977c4912079b4d1b1ab3d24908559e.1756799774.git.michal.simek@amd.com
2025-09-10tcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate ↵Kuniyuki Iwashima
psock->cork. syzbot reported the splat below. [0] The repro does the following: 1. Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes) 2. Attach the prog to a SOCKMAP 3. Add a socket to the SOCKMAP 4. Activate fault injection 5. Send data less than cork_bytes At 5., the data is carried over to the next sendmsg() as it is smaller than the cork_bytes specified by bpf_msg_cork_bytes(). Then, tcp_bpf_send_verdict() tries to allocate psock->cork to hold the data, but this fails silently due to fault injection + __GFP_NOWARN. If the allocation fails, we need to revert the sk->sk_forward_alloc change done by sk_msg_alloc(). Let's call sk_msg_free() when tcp_bpf_send_verdict fails to allocate psock->cork. The "*copied" also needs to be updated such that a proper error can be returned to the caller, sendmsg. It fails to allocate psock->cork. Nothing has been corked so far, so this patch simply sets "*copied" to 0. [0]: WARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983 Modules linked in: CPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156 Code: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 <0f> 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fc RSP: 0018:ffffc90000a08b48 EFLAGS: 00010246 RAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80 RDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000 RBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4 R10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380 R13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872 FS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0 Call Trace: <IRQ> __sk_destruct+0x86/0x660 net/core/sock.c:2339 rcu_do_batch kernel/rcu/tree.c:2605 [inline] rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861 handle_softirqs+0x286/0x870 kernel/softirq.c:579 __do_softirq kernel/softirq.c:613 [inline] invoke_softirq kernel/softirq.c:453 [inline] __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680 irq_exit_rcu+0x9/0x30 kernel/softirq.c:696 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052 </IRQ> Fixes: 4f738adba30a ("bpf: create tcp_bpf_ulp allowing BPF to monitor socket TX/RX data") Reported-by: syzbot+4cabd1d2fa917a456db8@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/68c0b6b5.050a0220.3c6139.0013.GAE@google.com/ Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org> Link: https://patch.msgid.link/20250909232623.4151337-1-kuniyu@google.com
2025-09-10MAINTAINERS: drm-misc: fix X: entries for nova/nouveauDanilo Krummrich
Nouveau patches usually flow through the drm-misc tree, while nova (and nova-core) are maintained through a dedicated driver tree and soon through drm-rust. Hence, fix up the corresponding X: entries to list nova instead of nouveau. Reported-by: Maxime Ripard <mripard@kernel.org> Closes: https://lore.kernel.org/dri-devel/enuksb2qk5wyrilz3l2vnog45lghgmplrav5to6pd5k5owi36h@pxdq6y5dpgpt/ Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20250902190247.435340-1-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-09-10pinctrl: qcom: Add SDM660 LPASS LPI TLMMRichard Acayan
The Snapdragon 660 has a Low-Power Island (LPI) TLMM for configuring pins related to audio. Add the driver for this. Also, this driver uses predefined pin_offsets for each pin taken from downstream driver, which does not follow the usual 0x1000 distance between pins and uses an array with predefined offsets that do not follow any regular pattern [1]. [1] https://git.codelinaro.org/clo/la/kernel/msm-4.4/-/blob/LA.UM.7.2.c27-07400-sdm660.0/drivers/pinctrl/qcom/pinctrl-lpi.c#L107 Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Richard Acayan <mailingradian@gmail.com> Co-developed-by: Nickolay Goppen <setotau@mainlining.org> Signed-off-by: Nickolay Goppen <setotau@mainlining.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2025-09-10dt-bindings: pinctrl: qcom: Add SDM660 LPI pinctrlNickolay Goppen
Add bindings for pin controller in SDM660 Low Power Audio SubSystem (LPASS). Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Co-developed-by: Richard Acayan <mailingradian@gmail.com> Signed-off-by: Richard Acayan <mailingradian@gmail.com> Signed-off-by: Nickolay Goppen <setotau@mainlining.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2025-09-10pinctrl: qcom: lpass-lpi: Add ability to use custom pin offsetsNickolay Goppen
By default pin_offset is calculated by formula: LPI_TLMM_REG_OFFSET * pin_id. However not all platforms are using this pin_offset formula (e.g. SDM660 LPASS LPI uses a predefined array of offsets [1]), so extend lpi_pingroup struct with pin_offset field, introduce extended LPI_PINGROUP_OFFSET macro with pin_offet field and introduce LPI_FLAG_USE_PREDEFINED_PIN_OFFSET flag. This adds an ability to use predefined offset for pin if it exists. [1] https://git.codelinaro.org/clo/la/kernel/msm-4.4/-/blob/LA.UM.7.2.c27-07400-sdm660.0/drivers/pinctrl/qcom/pinctrl-lpi.c#L107 Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Nickolay Goppen <setotau@mainlining.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2025-09-10media: qcom: camss: Add missing header bitfield.hLoic Poulain
Add the <linux/bitfield.h> header to prevent erros: >> drivers/media/platform/qcom/camss/camss-vfe-340.c:186:21: error: call to undeclared function 'FIELD_PREP'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 186 | if (bus_status & TFE_BUS_IRQ_MASK_RUP_DONE(i)) | ^ drivers/media/platform/qcom/camss/camss-vfe-340.c:36:40: note: expanded from macro 'TFE_BUS_IRQ_MASK_RUP_DONE' 36 | #define TFE_BUS_IRQ_MASK_RUP_DONE(sc) FIELD_PREP(TFE_BUS_IRQ_MASK_RUP_DONE_MASK, BIT(sc)) | ^ drivers/media/platform/qcom/camss/camss-vfe-340.c:191:21: error: call to undeclared function 'FIELD_PREP'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 191 | if (bus_status & TFE_BUS_IRQ_MASK_BUF_DONE(i)) | ^ drivers/media/platform/qcom/camss/camss-vfe-340.c:38:40: note: expanded from macro 'TFE_BUS_IRQ_MASK_BUF_DONE' 38 | #define TFE_BUS_IRQ_MASK_BUF_DONE(sg) FIELD_PREP(TFE_BUS_IRQ_MASK_BUF_DONE_MASK, BIT(sg)) | ^ 2 errors generated. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202509100228.xLeeYzpG-lkp@intel.com/ Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Acked-by: Bryan O'Donoghue <bod@kernel.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2025-09-10MAINTAINERS: Add an entry for Amlogic spifc driverXianwei Zhao
Add Amlogic spi flash controller entry to MAINTAINERS to clarify the maintainers. Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com> Link: https://patch.msgid.link/20250910-spifc-v6-3-1574aa9baebd@amlogic.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-09-10spi: amlogic: add driver for Amlogic SPI Flash ControllerFeng Chen
This driver provides support for the SPI mode of the Amlogic Flash Controller. It supports both SPI NOR flash and SPI NAND flash. For SPI NAND, the Host ECC hardware engine can be enabled. The controller implements the SPI-MEM interface and does not support generic SPI. Signed-off-by: Feng Chen <feng.chen@amlogic.com> Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com> Link: https://patch.msgid.link/20250910-spifc-v6-2-1574aa9baebd@amlogic.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-09-10spi: dt-bindings: add Amlogic A113L2 SFCFeng Chen
The Flash Controller is derived by adding an SPI path to the original raw NAND controller. This controller supports two modes: raw mode and SPI mode. The raw mode has already been implemented in the community, and the SPI mode is described here. Add bindings for Amlogic A113L2 SPI Flash Controller. Signed-off-by: Feng Chen <feng.chen@amlogic.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com> Link: https://patch.msgid.link/20250910-spifc-v6-1-1574aa9baebd@amlogic.com Signed-off-by: Mark Brown <broonie@kernel.org>
generated by cgit v1.3 (git 2.53.0) at 2026-11-14 17:54:25 +0000