summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-09-01Merge tag 'for-net-2025-08-29' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: - vhci: Prevent use-after-free by removing debugfs files early - L2CAP: Fix use-after-free in l2cap_sock_cleanup_listen() * tag 'for-net-2025-08-29' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: Bluetooth: Fix use-after-free in l2cap_sock_cleanup_listen() Bluetooth: vhci: Prevent use-after-free by removing debugfs files early ==================== Link: https://patch.msgid.link/20250829191210.1982163-1-luiz.dentz@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-01gpu: nova-core: avoid probing non-display/compute PCI functionsJohn Hubbard
NovaCore has so far been too imprecise about figuring out if .probe() has found a supported PCI PF (Physical Function). By that I mean: .probe() sets up BAR0 (which involves a lot of very careful devres and Device<Bound> details behind the scenes). And then if it is dealing with a non-supported device such as the .1 audio PF on many GPUs, it fails out due to an unexpected BAR0 size. We have been fortunate that the BAR0 sizes are different. Really, we should be filtering on PCI class ID instead. These days I think we can confidently pick out Nova's supported PF's via PCI class ID. And if not, then we'll revisit. The approach here is to filter on "Display VGA" or "Display 3D", which is how PCI class IDs express "this is a modern GPU's PF". Cc: Danilo Krummrich <dakr@kernel.org> Cc: Elle Rhumsaa <elle@weathered-steel.dev> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Link: https://lore.kernel.org/r/20250829223632.144030-5-jhubbard@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-09-01soundwire: Use min() to improve codeQianfeng Rong
Use min() to reduce the code in qcom_swrm_xfer_msg() and improve its readability. Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com> Link: https://lore.kernel.org/r/20250814142428.282639-1-rongqianfeng@vivo.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-09-01soundwire: bus: Drop dev_pm_domain_detach() callClaudiu Beznea
Starting with commit f99508074e78 ("PM: domains: Detach on device_unbind_cleanup()"), there is no longer a need to call dev_pm_domain_detach() in the bus remove function. The device_unbind_cleanup() function now handles this to avoid invoking devres cleanup handlers while the PM domain is powered off, which could otherwise lead to failures as described in the above-mentioned commit. Drop the explicit dev_pm_domain_detach() call and rely instead on the flags passed to dev_pm_domain_attach() to power off the domain. Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20250827101506.927787-1-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-09-01phy: qcom: qmp-pcie: Fix PHY initialization when powered down by firmwareStephan Gerhold
Commit 0cc22f5a861c ("phy: qcom: qmp-pcie: Add PHY register retention support") added support for using the "no_csr" reset to skip configuration of the PHY if the init sequence was already applied by the boot firmware. The expectation is that the PHY is only turned on/off by using the "no_csr" reset, instead of powering it down and re-programming it after a full reset. The boot firmware on X1E does not fully conform to this expectation: If the PCIe3 link fails to come up (e.g. because no PCIe card is inserted), the firmware powers down the PHY using the QPHY_PCS_POWER_DOWN_CONTROL register. The QPHY_START_CTRL register is kept as-is, so the driver assumes the PHY is already initialized and skips the configuration/power up sequence. The PHY won't come up again without clearing the QPHY_PCS_POWER_DOWN_CONTROL, so eventually initialization fails: qcom-qmp-pcie-phy 1be0000.phy: phy initialization timed-out phy phy-1be0000.phy.0: phy poweron failed --> -110 qcom-pcie 1bd0000.pcie: cannot initialize host qcom-pcie 1bd0000.pcie: probe with driver qcom-pcie failed with error -110 This can be reliably reproduced on the X1E CRD, QCP and Devkit when no card is inserted for PCIe3. Fix this by checking the QPHY_PCS_POWER_DOWN_CONTROL register in addition to QPHY_START_CTRL. If the PHY is powered down with the register, it doesn't conform to the expectations for using the "no_csr" reset, so we fully re-initialize with the normal reset sequence. Also check the register more carefully to ensure all of the bits we expect are actually set. A simple !!(readl()) is not enough, because the PHY might be only partially set up with some of the expected bits set. Cc: stable@vger.kernel.org Fixes: 0cc22f5a861c ("phy: qcom: qmp-pcie: Add PHY register retention support") Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250821-phy-qcom-qmp-pcie-nocsr-fix-v3-1-4898db0cc07c@linaro.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-09-01phy: renesas: rcar-gen3-usb2: Fix ID check logic with VBUS validLad Prabhakar
The existing ID detection logic returned false when both IDDIG and VBUSVALID were set, which caused incorrect role determination in some cases. The condition: !(device && !vbus_valid) did not properly reflect the intended relationship between IDDIG and VBUSVALID signals. Update the logic to: return vbus_valid ? device : !device; This ensures that when VBUS is valid, the role follows the IDDIG value, and when VBUS is not valid, the role is inverted, matching the expected OTG behavior. Fixes: b725741f1c21 ("phy: renesas: rcar-gen3-usb2: Add support for RZ/T2H SoC") Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20250821155957.1088337-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-09-01firmware: qcom: scm: Allow QSEECOM on Dell Inspiron 7441 / Latitude 7455Val Packett
Allow these machines to access efivars through qseecom/uefisecapp. Signed-off-by: Val Packett <val@packett.cool> Reviewed-by: Laurentiu Tudor <laurentiu.tudor1@dell.com> Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20250716003139.18543-5-val@packett.cool Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-01phy: ti: gmii-sel: Always write the RGMII ID settingMichael Walle
Some SoCs are just validated with the TX delay enabled. With commit ca13b249f291 ("net: ethernet: ti: am65-cpsw: fixup PHY mode for fixed RGMII TX delay"), the network driver will patch the delay setting on the fly assuming that the TX delay setting is fixed. In reality, the TX delay is configurable and just skipped in the documentation. There are bootloaders, which will disable the TX delay and this will lead to a transmit path which doesn't add any delays at all. Fix that by always writing the RGMII_ID setting and report an error for unsupported RGMII delay modes. This is safe to do and shouldn't break any boards in mainline because the fixed delay is only introduced for gmii-sel compatibles which are used together with the am65-cpsw-nuss driver and also contains the commit above. Fixes: ca13b249f291 ("net: ethernet: ti: am65-cpsw: fixup PHY mode for fixed RGMII TX delay") Signed-off-by: Michael Walle <mwalle@kernel.org> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://lore.kernel.org/r/20250819065622.1019537-1-mwalle@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-09-01firmware: qcom: scm: Allow QSEECOM on Lenovo Thinkbook 16Jens Glathe
Allow particular machine accessing eg. efivars. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz> Link: https://lore.kernel.org/r/20250822-tb16-dt-v12-2-bab6c2986351@oldschoolsolutions.biz Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-01PCI: j721e: Fix module autoloadingSiddharth Vadapalli
Commit a2790bf81f0f ("PCI: j721e: Add support to build as a loadable module") added support to build the driver as a loadable module. However, it did not add MODULE_DEVICE_TABLE() which is required for autoloading the driver based on device table when it is built as a loadable module. Fix it by adding MODULE_DEVICE_TABLE. Fixes: a2790bf81f0f ("PCI: j721e: Add support to build as a loadable module") Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> [mani: reworded description] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250901120359.3410774-1-s-vadapalli@ti.com
2025-09-01intel_idle: Remove unnecessary address-of operatorsKaushlendra Kumar
Remove redundant address-of operators (&) when assigning the intel_idle() function pointer to the .enter field in cpuidle_state structures.in C, the & is not needed for function names. This change improves code consistency and readability by using the more conventional form without the & operator. No functional change intended. Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar@intel.com> Reviewed-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Link: https://patch.msgid.link/20250818085124.3897921-1-kaushlendra.kumar@intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-01hwmon: (ina238) Correctly clamp power limitsGuenter Roeck
ina238_write_power() was attempting to clamp the user input but was throwing away the result. Ensure that we clamp the value to the appropriate range before it is converted into a register value. Fixes: 0d9f596b1fe34 ("hwmon: (ina238) Modify the calculation formula to adapt to different chips") Cc: Wenliang Yan <wenliang202407@163.com> Cc: Chris Packham <chris.packham@alliedtelesis.co.nz> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-09-01hwmon: (ina238) Correctly clamp shunt voltage limitGuenter Roeck
When clamping a register value, the result needs to be masked against the register size. This was missing, resulting in errors when trying to write negative limits. Fix by masking the clamping result against the register size. Fixes: eacb52f010a80 ("hwmon: Driver for Texas Instruments INA238") Cc: Nathan Rossi <nathan.rossi@digi.com> Cc: Chris Packham <chris.packham@alliedtelesis.co.nz> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-09-01brd: use page reference to protect page lifetimeYu Kuai
As discussed [1], hold rcu for copying data from/to page is too heavy, it's better to protect page with rcu around for page lookup and then grab a reference to prevent page to be freed by discard. [1] https://lore.kernel.org/all/eb41cab3-5946-4fe3-a1be-843dd6fca159@kernel.dk/ Signed-off-by: Yu Kuai <yukuai3@huawei.com> Link: https://lore.kernel.org/r/20250811065628.1829339-1-yukuai1@huaweicloud.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2025-09-01mtd: spi-nor: core: avoid odd length/address writes in 8D-8D-8D modePratyush Yadav
On Octal DTR capable flashes like Micron Xcella the writes cannot start or end at an odd address in Octal DTR mode. Extra 0xff bytes need to be appended or prepended to make sure the start address and end address are even. 0xff is used because on NOR flashes a program operation can only flip bits from 1 to 0, not the other way round. 0 to 1 flip needs to happen via erases. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Michael Walle <michael@walle.cc> Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com> Signed-off-by: Pratyush Yadav <pratyush@kernel.org> Link: https://lore.kernel.org/r/20250708091646.292-2-ziniu.wang_1@nxp.com
2025-09-01mtd: spi-nor: core: avoid odd length/address reads on 8D-8D-8D modePratyush Yadav
On Octal DTR capable flashes like Micron Xcella reads cannot start or end at an odd address in Octal DTR mode. Extra bytes need to be read at the start or end to make sure both the start address and length remain even. To avoid allocating too much extra memory, thereby putting unnecessary memory pressure on the system, the temporary buffer containing the extra padding bytes is capped at PAGE_SIZE bytes. The rest of the 2-byte aligned part should be read directly in the main buffer. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Reviewed-by: Michael Walle <michael@walle.cc> Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com> Signed-off-by: Pratyush Yadav <pratyush@kernel.org> Link: https://lore.kernel.org/r/20250708091646.292-1-ziniu.wang_1@nxp.com
2025-09-01drm/ssd130x: Remove the use of dev_err_probe()Liao Yuanhong
Logging messages that show some type of "out of memory" error are generally unnecessary as there is a generic message and a stack dump done by the memory subsystem. These messages generally increase kernel size without much added value[1]. The dev_err_probe() doesn't do anything when error is '-ENOMEM'. Therefore, remove the useless call to dev_err_probe(), and just return the value instead. [1]: https://lore.kernel.org/lkml/1402419340.30479.18.camel@joe-AO725/ Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20250820131416.500048-1-liaoyuanhong@vivo.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2025-09-01drm/st7571-i2c: add support for 2bit grayscale for XRGB8888Marcus Folkesson
Add support for 2bit grayscale and use it for XRGB8888 when grayscale is supported. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com> Link: https://lore.kernel.org/r/20250721-st7571-format-v2-6-159f4134098c@gmail.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2025-09-01drm/format-helper: introduce drm_fb_xrgb8888_to_gray2()Marcus Folkesson
Convert XRGB8888 to 2bit grayscale. It uses drm_fb_xrgb8888_to_gray8() to convert the pixels to gray8 as an intermediate step before converting to gray2. Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20250721-st7571-format-v2-5-159f4134098c@gmail.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2025-09-01drm/st7571-i2c: add support for inverted pixel formatMarcus Folkesson
Depending on which display that is connected to the controller, an "1" means either a black or a white pixel. The supported formats (R1/R2/XRGB8888) expects the pixels to map against (4bit): 00 => Black 01 => Dark Gray 10 => Light Gray 11 => White If this is not what the display map against, make it possible to invert the pixels. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com> Link: https://lore.kernel.org/r/20250721-st7571-format-v2-4-159f4134098c@gmail.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2025-09-01drm/st7571-i2c: correct pixel data format descriptionMarcus Folkesson
The comment describes the pixel data format as stated in the st7571 datasheet, which is not necessary the same as for the connected display. Instead, describe the expected pixel data format which is used for R1/R2/XRGB8888. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com> Link: https://lore.kernel.org/r/20250721-st7571-format-v2-1-159f4134098c@gmail.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2025-09-01gpu: nova-core: vbios: store reference to Device where relevantAlexandre Courbot
Now that the vbios code uses a non-bound `Device` instance, store an `ARef` to it at construction time so we can use it for logging without having to carry an extra argument on every method for that sole purpose. Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20250808-vbios_device-v1-2-834bbbab6471@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-09-01gpu: nova-core: vbios: replace pci::Device with device::DeviceAlexandre Courbot
The passed pci::Device is exclusively used for logging purposes, so it can be replaced by a regular device::Device, which allows us to remove the `as_ref()` indirections at each logging site. Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20250808-vbios_device-v1-1-834bbbab6471@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2025-09-01regulator: scmi: Use int type to store negative error codesQianfeng Rong
Change the 'ret' variable from u32 to int to store negative error codes or zero returned by of_property_read_u32(). Storing the negative error codes in unsigned type, doesn't cause an issue at runtime but it's ugly as pants. Additionally, assigning negative error codes to unsigned type may trigger a GCC warning when the -Wsign-conversion flag is enabled. No effect on runtime. Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Fixes: 0fbeae70ee7c ("regulator: add SCMI driver") Link: https://patch.msgid.link/20250829101411.625214-1-rongqianfeng@vivo.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-09-01mtd: rawnand: s3c2410: Drop S3C2410 supportKrzysztof Kozlowski
Samsung S3C24xx family of SoCs was removed from the Linux kernel in the commit 61b7f8920b17 ("ARM: s3c: remove all s3c24xx support"), in January 2023. There are no in-kernel users of its compatibles and platform IDs. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2025-09-01mtd: rawnand: pl353: Use int type to store negative error codesQianfeng Rong
Change the 'ret' variable from u32 to int in pl35x_nand_probe() to store negative error codes or zero; Storing the negative error codes in unsigned type, doesn't cause an issue at runtime but can be confusing. Additionally, assigning negative error codes to unsigned type may trigger a GCC warning when the -Wsign-conversion flag is enabled. No effect on runtime. Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2025-09-01phy: lynx-28g: check return value when calling lynx_28g_pll_getJosua Mayer
The lynx_28g_pll_get function may return NULL when called with an unsupported submode argument. This function is only called from the lynx_28g_lane_set_{10gbaser,sgmii} functions, and lynx_28g_set_mode checks available modes before setting a protocol. NXP vendor kernel based on v6.6.52 however is missing any checks and connecting a 2.5/5gbase-t ethernet phy can cause null pointer dereference [1]. Check return value at every invocation and abort in the unlikely error case. Further print a warning message the first time lynx_28g_pll_get returns null, to catch this case should it occur after future changes. [1] [ 127.019924] fsl_dpaa2_eth dpni.4 eth5: dpmac_set_protocol(2500base-x) = -ENOTSUPP [ 127.027451] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000014 [ 127.036245] Mem abort info: [ 127.039044] ESR = 0x0000000096000004 [ 127.042794] EC = 0x25: DABT (current EL), IL = 32 bits [ 127.048107] SET = 0, FnV = 0 [ 127.051161] EA = 0, S1PTW = 0 [ 127.054301] FSC = 0x04: level 0 translation fault [ 127.059179] Data abort info: [ 127.062059] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 127.067547] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 127.072596] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 127.077907] user pgtable: 4k pages, 48-bit VAs, pgdp=00000020816c9000 [ 127.084344] [0000000000000014] pgd=0000000000000000, p4d=0000000000000000 [ 127.091133] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 127.097390] Modules linked in: cfg80211 rfkill fsl_jr_uio caam_jr dpaa2_caam caamkeyblob_desc crypto_engine caamhash_desc onboard_usb_hub caamalg_desc crct10dif_ce libdes caam error at24 rtc_ds1307 rtc_fsl_ftm_alarm nvmem_layerscape_sfp layerscape_edac_mod dm_mod nfnetlink ip_tables [ 127.122436] CPU: 5 PID: 96 Comm: kworker/u35:0 Not tainted 6.6.52-g3578ef896722 #10 [ 127.130083] Hardware name: SolidRun LX2162A Clearfog (DT) [ 127.135470] Workqueue: events_power_efficient phylink_resolve [ 127.141219] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 127.148170] pc : lynx_28g_set_lane_mode+0x300/0x818 [ 127.153041] lr : lynx_28g_set_lane_mode+0x2fc/0x818 [ 127.157909] sp : ffff8000806f3b80 [ 127.161212] x29: ffff8000806f3b80 x28: 0000000000000000 x27: 0000000000000000 [ 127.168340] x26: ffff29d6c11f3098 x25: 0000000000000000 x24: 0000000000000000 [ 127.175467] x23: ffff29d6c11f31f0 x22: ffff29d6c11f3080 x21: 0000000000000001 [ 127.182595] x20: ffff29d6c11f4c00 x19: 0000000000000000 x18: 0000000000000006 [ 127.189722] x17: 4f4e452d203d2029 x16: 782d657361623030 x15: 3532286c6f636f74 [ 127.196849] x14: 6f72705f7465735f x13: ffffd7a8ff991cc0 x12: 0000000000000acb [ 127.203976] x11: 0000000000000399 x10: ffffd7a8ff9e9cc0 x9 : 0000000000000000 [ 127.211104] x8 : 0000000000000000 x7 : 0000000000000000 x6 : ffff29d6c11f3080 [ 127.218231] x5 : 0000000000000000 x4 : 0000000040800030 x3 : 000000000000034c [ 127.225358] x2 : ffff29d6c11f3080 x1 : 000000000000034c x0 : 0000000000000000 [ 127.232486] Call trace: [ 127.234921] lynx_28g_set_lane_mode+0x300/0x818 [ 127.239443] lynx_28g_set_mode+0x12c/0x148 [ 127.243529] phy_set_mode_ext+0x5c/0xa8 [ 127.247356] lynx_pcs_config+0x64/0x294 [ 127.251184] phylink_major_config+0x184/0x49c [ 127.255532] phylink_resolve+0x2a0/0x5d8 [ 127.259446] process_one_work+0x138/0x248 [ 127.263448] worker_thread+0x320/0x438 [ 127.267187] kthread+0x114/0x118 [ 127.270406] ret_from_fork+0x10/0x20 [ 127.273973] Code: 2a1303e1 aa0603e0 97fffd3b aa0003e5 (b9401400) [ 127.280055] ---[ end trace 0000000000000000 ]--- Signed-off-by: Josua Mayer <josua@solid-run.com> Link: https://lore.kernel.org/r/20250826-lynx-28g-nullptr-v1-1-e4de0098f822@solid-run.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-09-01phy: qcom: m31-eusb2: Fix the error log while enabling clockPrashanth K
While enabling clock, we incorrectly log 'ref clk' as 'cfg ahb clk' Fix this since the devicetree bindings mentions it as ref clock. Signed-off-by: Prashanth K <prashanth.k@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250826105254.3758803-1-prashanth.k@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-09-01phy: rockchip: usbdp: Remove redundant ternary operatorsLiao Yuanhong
Remove redundant ternary operators to clean up the code. Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com> Link: https://lore.kernel.org/r/20250828122401.17441-4-liaoyuanhong@vivo.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-09-01phy: renesas: rcar-gen3-usb2: Remove redundant ternary operatorsLiao Yuanhong
Remove redundant ternary operators to clean up the code. Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20250828122401.17441-3-liaoyuanhong@vivo.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-09-01phy: hisilicon: Remove redundant ternary operatorsLiao Yuanhong
Remove redundant ternary operators to clean up the code. Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com> Link: https://lore.kernel.org/r/20250828122401.17441-2-liaoyuanhong@vivo.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-09-01spi: cadence-quadspi: Implement refcount to handle unbind during busyKhairul Anuar Romli
driver support indirect read and indirect write operation with assumption no force device removal(unbind) operation. However force device removal(removal) is still available to root superuser. Unbinding driver during operation causes kernel crash. This changes ensure driver able to handle such operation for indirect read and indirect write by implementing refcount to track attached devices to the controller and gracefully wait and until attached devices remove operation completed before proceed with removal operation. Signed-off-by: Khairul Anuar Romli <khairul.anuar.romli@altera.com> Reviewed-by: Matthew Gerlach <matthew.gerlach@altera.com> Reviewed-by: Niravkumar L Rabara <nirav.rabara@altera.com> Link: https://patch.msgid.link/8704fd6bd2ff4d37bba4a0eacf5eba3ba001079e.1756168074.git.khairul.anuar.romli@altera.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-09-01spi: spi-fsl-lpspi: Add compatible for S32GLarisa Grigore
S32G doesn't have the max prescale erratum (default) and it can query the max number of CS from hardware, so add those settings. Signed-off-by: Larisa Grigore <larisa.grigore@nxp.com> Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@nxp.com> Signed-off-by: James Clark <james.clark@linaro.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20250828-james-nxp-lpspi-v2-9-6262b9aa9be4@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2025-09-01spi: spi-fsl-lpspi: Parameterize reading num-cs from hardwareJames Clark
Add query_hw_for_num_cs in devtype to avoid directly checking compatible string "fsl,imx93-spi". No functionality change. Signed-off-by: James Clark <james.clark@linaro.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20250828-james-nxp-lpspi-v2-8-6262b9aa9be4@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2025-09-01spi: spi-fsl-lpspi: Treat prescale_max == 0 as no erratumJames Clark
This erratum only ever results in a max value of 1, otherwise the full 3 bits are available. To avoid repeating the same default prescale value for every new device's devdata, treat 0 as no limit (7) and only set a value when the erratum is present. Change the field to be 3 bits to catch out of range definitions. No functionality change. Signed-off-by: James Clark <james.clark@linaro.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20250828-james-nxp-lpspi-v2-7-6262b9aa9be4@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2025-09-01spi: spi-fsl-lpspi: Constify devtype datasJames Clark
Add const for all devtype_data. Signed-off-by: James Clark <james.clark@linaro.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20250828-james-nxp-lpspi-v2-6-6262b9aa9be4@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2025-09-01spi: spi-fsl-lpspi: Clear status register after disabling the moduleLarisa Grigore
Clear the error flags after disabling the module to avoid the case when a flag is set again between flag clear and module disable. And use SR_CLEAR_MASK to replace hardcoded value for improved readability. Although fsl_lpspi_reset() was only introduced in commit a15dc3d657fa ("spi: lpspi: Fix CLK pin becomes low before one transfer"), the original driver only reset SR in the interrupt handler, making it vulnerable to the same issue. Therefore the fixes commit is set at the introduction of the driver. Fixes: 5314987de5e5 ("spi: imx: add lpspi bus driver") Signed-off-by: Larisa Grigore <larisa.grigore@nxp.com> Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: James Clark <james.clark@linaro.org> Link: https://patch.msgid.link/20250828-james-nxp-lpspi-v2-4-6262b9aa9be4@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2025-09-01spi: spi-fsl-lpspi: Reset FIFO and disable module on transfer abortLarisa Grigore
In DMA mode fsl_lpspi_reset() is always called at the end, even when the transfer is aborted. In PIO mode aborts skip the reset leaving the FIFO filled and the module enabled. Fix it by always calling fsl_lpspi_reset(). Fixes: a15dc3d657fa ("spi: lpspi: Fix CLK pin becomes low before one transfer") Signed-off-by: Larisa Grigore <larisa.grigore@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: James Clark <james.clark@linaro.org> Link: https://patch.msgid.link/20250828-james-nxp-lpspi-v2-3-6262b9aa9be4@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2025-09-01spi: spi-fsl-lpspi: Set correct chip-select polarity bitLarisa Grigore
The driver currently supports multiple chip-selects, but only sets the polarity for the first one (CS 0). Fix it by setting the PCSPOL bit for the desired chip-select. Fixes: 5314987de5e5 ("spi: imx: add lpspi bus driver") Signed-off-by: Larisa Grigore <larisa.grigore@nxp.com> Signed-off-by: James Clark <james.clark@linaro.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20250828-james-nxp-lpspi-v2-2-6262b9aa9be4@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2025-09-01spi: spi-fsl-lpspi: Fix transmissions when using CONTLarisa Grigore
Commit 6a130448498c ("spi: lpspi: Fix wrong transmission when don't use CONT") breaks transmissions when CONT is used. The TDIE interrupt should not be disabled in all cases. If CONT is used and the TX transfer is not yet completed yet, but the interrupt handler is called because there are characters to be received, TDIE is replaced with FCIE. When the transfer is finally completed, SR_TDF is set but the interrupt handler isn't called again. Fixes: 6a130448498c ("spi: lpspi: Fix wrong transmission when don't use CONT") Signed-off-by: Larisa Grigore <larisa.grigore@nxp.com> Signed-off-by: James Clark <james.clark@linaro.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20250828-james-nxp-lpspi-v2-1-6262b9aa9be4@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2025-09-01phy: qcom-qmp-ufs: Add PHY and PLL regulator loadNitin Rawat
Add phy and pll regulator load voting support for all supported platforms by introducing dedicated regulator bulk data arrays with their load values. This ensures stable operation and proper power management for these platforms where regulators are shared between the QMP UFS PHY and other IP blocks by setting appropriate regulator load currents during PHY operations. Signed-off-by: Nitin Rawat <quic_nitirawa@quicinc.com> Acked-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://lore.kernel.org/r/20250830070353.2694-3-nitin.rawat@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-09-01phy: qcom-qmp-ufs: Add regulator load voting for UFS QMP PHYNitin Rawat
On certain SoCs, power regulators are shared between the QMP UFS PHY and other IP blocks. To ensure proper operation, the regulator framework must be informed of the UFS PHY's load requirements. This is essential because the regulator's operating mode—whether Low Power or High Power—depends on the maximum expected load at any given time, which the regulator driver needs to manage accordingly. To support this, replace devm_regulator_bulk_get() with devm_regulator_bulk_get_const() and inline the qmp_ufs_vreg_init() function. additionally replace the array of regulator names with a bulk regulator data structure, and utilize the init_load_uA field provided by the regulator framework. This ensures that regulator_set_load() is automatically invoked before the first enable operation. Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Nitin Rawat <quic_nitirawa@quicinc.com> Link: https://lore.kernel.org/r/20250830070353.2694-2-nitin.rawat@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-09-01dm: fix "writen"->"written"Xichao Zhao
Trivial fix to spelling mistake in comment text. Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2025-09-01dm-pcache: cleanup: fix coding style report by checkpatch.plDongsheng Yang
A patch from a few days ago fixed the division issue on 32-bit machines, but it introduced a coding style problem. WARNING: Missing a blank line after declarations + u32 rem; + div_u64_rem(off >> PCACHE_CACHE_SUBTREE_SIZE_SHIFT, cache->n_ksets, &rem); total: 0 errors, 1 warnings, 634 lines checked Signed-off-by: Dongsheng Yang <dongsheng.yang@linux.dev> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2025-09-01dm-pcache: remove ctrl_lock for pcache_cache_segmentDongsheng Yang
The smatch checker reports a “scheduler in atomic context” problem in the following call chain: miss_read_end_req() -> cache_seg_put() -> cache_seg_invalidate() -> cache_seg_gen_increase() -> mutex_lock(&cache_seg->ctrl_lock); In practice, this `mutex_lock` will not actually schedule, because it is only called when `cache_seg_put()` drops the last reference, which is single-threaded. That is also why the issue never shows up during real testing. However, the code is still buggy. The original purpose of `ctrl_lock` was to prevent read/write conflicts on the cache segment control information. Looking at the current usage, all control information accesses are single-threaded: reads only occur during the init phase, where no conflicts are possible, and writes happen once in the init phase (also single-threaded) and once when `cache_seg_put()` drops the last reference (again single-threaded). Therefore, this patch removes `ctrl_lock` entirely and adds comments in the appropriate places to document this logic. Signed-off-by: Dongsheng Yang <dongsheng.yang@linux.dev> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2025-09-01drm/imagination: Enable PowerVR driver for RISC-VMichal Wilczynski
Several RISC-V boards feature Imagination GPUs that are compatible with the PowerVR driver. An example is the IMG BXM-4-64 GPU on the Lichee Pi 4A board. This commit adjusts the driver's Kconfig dependencies to allow the PowerVR driver to be compiled on the RISC-V architecture. By enabling compilation on RISC-V, we expand support for these GPUs, providing graphics acceleration capabilities and enhancing hardware compatibility on RISC-V platforms. The RISC-V support is restricted to 64-bit systems (RISCV && 64BIT) as the driver currently has an implicit dependency on a 64-bit platform. Add a dependency on MMU to fix a build warning on RISC-V configurations without an MMU. Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com> Link: https://lore.kernel.org/r/20250822-apr_14_for_sending-v13-4-af656f7cc6c3@samsung.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-09-01drm/imagination: Use pwrseq for TH1520 GPU power managementMichal Wilczynski
Update the Imagination PVR DRM driver to leverage the pwrseq framework for managing the complex power sequence of the GPU on the T-HEAD TH1520 SoC. To cleanly separate platform-specific logic from the generic driver, this patch introduces an `init` callback to the `pwr_power_sequence_ops` struct. This allows for different power management strategies to be selected at probe time based on the device's compatible string. A `pvr_device_data` struct, associated with each compatible in the of_device_id table, points to the appropriate ops table (manual or pwrseq). At probe time, the driver now calls the `->init()` op. For pwrseq-based platforms, this callback calls `devm_pwrseq_get("gpu-power")`, deferring probe if the sequencer is not yet available. For other platforms, it falls back to the existing manual clock and reset handling. The runtime PM callbacks continue to call the appropriate functions via the ops table. Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Matt Coster <matt.coster@imgtec.com> Link: https://lore.kernel.org/r/20250822-apr_14_for_sending-v13-1-af656f7cc6c3@samsung.com Signed-off-by: Matt Coster <matt.coster@imgtec.com>
2025-09-01accel/ivpu: Prevent recovery work from being queued during device removalKarol Wachowski
Use disable_work_sync() instead of cancel_work_sync() in ivpu_dev_fini() to ensure that no new recovery work items can be queued after device removal has started. Previously, recovery work could be scheduled even after canceling existing work, potentially leading to use-after-free bugs if recovery accessed freed resources. Rename ivpu_pm_cancel_recovery() to ivpu_pm_disable_recovery() to better reflect its new behavior. Fixes: 58cde80f45a2 ("accel/ivpu: Use dedicated work for job timeout detection") Cc: stable@vger.kernel.org # v6.8+ Signed-off-by: Karol Wachowski <karol.wachowski@intel.com> Reviewed-by: Lizhi Hou <lizhi.hou@amd.com> Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://lore.kernel.org/r/20250808110939.328366-1-jacek.lawrynowicz@linux.intel.com
2025-09-01accel/ivpu: Make function parameter names consistentJacek Lawrynowicz
Make ivpu_hw_btrs_dct_set_status() and ivpu_fw_boot_params_setup() declaration and definition parameter names consistent. Reviewed-by: Lizhi Hou <lizhi.hou@amd.com> Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://lore.kernel.org/r/20250808111014.328607-1-jacek.lawrynowicz@linux.intel.com
2025-09-01accel/ivpu: Remove unused PLL_CONFIG_DEFAULTJacek Lawrynowicz
This change removes the unnecessary condition, makes the code clearer, and silences clang-tidy warning. Reviewed-by: Lizhi Hou <lizhi.hou@amd.com> Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://lore.kernel.org/r/20250808111044.328800-1-jacek.lawrynowicz@linux.intel.com