summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2024-11-12iommufd/selftest: Add container_of helpersNicolin Chen
Use these inline helpers to shorten those container_of lines. Note that one of them goes back and forth between iommu_domain and mock_iommu_domain, which isn't necessary. So drop its container_of. Link: https://patch.msgid.link/r/518ec64dae2e814eb29fd9f170f58a3aad56c81c.1730836219.git.nicolinc@nvidia.com Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2024-11-12iommufd: Allow pt_id to carry viommu_id for IOMMU_HWPT_ALLOCNicolin Chen
Now a vIOMMU holds a shareable nesting parent HWPT. So, it can act like that nesting parent HWPT to allocate a nested HWPT. Support that in the IOMMU_HWPT_ALLOC ioctl handler, and update its kdoc. Also, add an iommufd_viommu_alloc_hwpt_nested helper to allocate a nested HWPT for a vIOMMU object. Since a vIOMMU object holds the parent hwpt's refcount already, increase the refcount of the vIOMMU only. Link: https://patch.msgid.link/r/a0f24f32bfada8b448d17587adcaedeeb50a67ed.1730836219.git.nicolinc@nvidia.com Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2024-11-12iommufd/viommu: Add IOMMU_VIOMMU_ALLOC ioctlNicolin Chen
Add a new ioctl for user space to do a vIOMMU allocation. It must be based on a nesting parent HWPT, so take its refcount. IOMMU driver wanting to support vIOMMUs must define its IOMMU_VIOMMU_TYPE_ in the uAPI header and implement a viommu_alloc op in its iommu_ops. Link: https://patch.msgid.link/r/dc2b8ba9ac935007beff07c1761c31cd097ed780.1730836219.git.nicolinc@nvidia.com Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2024-11-12iommufd: Verify object in iommufd_object_finalize/abort()Nicolin Chen
To support driver-allocated vIOMMU objects, it's required for IOMMU driver to call the provided iommufd_viommu_alloc helper to embed the core struct. However, there is no guarantee that every driver will call it and allocate objects properly. Make the iommufd_object_finalize/abort functions more robust to verify if the xarray slot indexed by the input obj->id is having an XA_ZERO_ENTRY, which is the reserved value stored by xa_alloc via iommufd_object_alloc. Link: https://patch.msgid.link/r/334bd4dde8e0a88eb30fa67eeef61827cdb546f9.1730836219.git.nicolinc@nvidia.com Suggested-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2024-11-12iommufd: Move _iommufd_object_alloc helper to a sharable fileNicolin Chen
The following patch will add a new vIOMMU allocator that will require this _iommufd_object_alloc to be sharable with IOMMU drivers (and iommufd too). Add a new driver.c file that will be built with CONFIG_IOMMUFD_DRIVER_CORE selected by CONFIG_IOMMUFD, and put the CONFIG_DRIVER under that remaining to be selectable for drivers to build the existing iova_bitmap.c file. Link: https://patch.msgid.link/r/2f4f6e116dc49ffb67ff6c5e8a7a8e789ab9e98e.1730836219.git.nicolinc@nvidia.com Suggested-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2024-11-12drivers: perf: Fix wrong put_cpu() placementAlexandre Ghiti
Unfortunately, the wrong patch version was merged which places the put_cpu() after enabling a static key, which is not safe as pointed by Will [1], so move put_cpu() before to avoid this. Fixes: 2840dadf0dde ("drivers: perf: Fix smp_processor_id() use in preemptible code") Reported-by: Atish Patra <atishp@rivosinc.com> Link: https://lore.kernel.org/all/20240827125335.GD4772@willie-the-truck/ [1] Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20241112113422.617954-1-alexghiti@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2024-11-12iommu/tegra241-cmdqv: Fix alignment failure at max_n_shiftNicolin Chen
When configuring a kernel with PAGE_SIZE=4KB, depending on its setting of CONFIG_CMA_ALIGNMENT, VCMDQ_LOG2SIZE_MAX=19 could fail the alignment test and trigger a WARN_ON: WARNING: at drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c:3646 Call trace: arm_smmu_init_one_queue+0x15c/0x210 tegra241_cmdqv_init_structures+0x114/0x338 arm_smmu_device_probe+0xb48/0x1d90 Fix it by capping max_n_shift to CMDQ_MAX_SZ_SHIFT as SMMUv3 CMDQ does. Fixes: 918eb5c856f6 ("iommu/arm-smmu-v3: Add in-kernel support for NVIDIA Tegra241 (Grace) CMDQV") Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Link: https://lore.kernel.org/r/20241111030226.1940737-1-nicolinc@nvidia.com Signed-off-by: Will Deacon <will@kernel.org>
2024-11-12platform: cznic: turris-omnia-mcu: Rename variable holding GPIO line namesMarek Behún
Rename the `omnia_mcu_gpio_templates` variable to `omnia_mcu_gpio_names`. The array contained templates for the names during the development of the driver, but the template prefix `gpio%u.` was dropped before the driver was merged, since this functionality was broken in gpiolib. Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-11-12platform: cznic: turris-omnia-mcu: Document the driver private data structureMarek Behún
Add more comprehensive documentation for the driver private data structure, `struct omnia_mcu`. Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-11-12firmware: turris-mox-rwtm: Document the driver private data structureMarek Behún
Add more comprehensive documentation for the driver private data structure, `struct mox_rwtm`. Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-11-12Merge tag 'ti-driver-soc-for-v6.13' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux into soc/drivers TI SoC driver updates for v6.13 - knav_qmss_queue: Cleanups around request_irq params and redundant code. - ti_sci: Power management ops in preperation for suspend/resume capability. Also includes dependency patch to export dev_pm_qos_read_value (acked by Rafael). * tag 'ti-driver-soc-for-v6.13' of https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux: firmware: ti_sci: Remove use of of_match_ptr() helper firmware: ti_sci: add CPU latency constraint management firmware: ti_sci: Introduce Power Management Ops firmware: ti_sci: Add system suspend and resume call firmware: ti_sci: Add support for querying the firmware caps PM: QoS: Export dev_pm_qos_read_value soc: ti: knav_qmss_queue: Drop redundant continue statement soc: ti: knav_qmss_queue: Use IRQF_NO_AUTOEN flag in request_irq() Link: https://lore.kernel.org/r/20241106121708.rso5wvc7wbhfi6xk@maverick Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-11-12Merge tag 'reset-for-v6.13' of git://git.pengutronix.de/pza/linux into ↵Arnd Bergmann
soc/drivers Reset controller updates for v6.13 * Split the Amlogic reset-meson driver into platform and auxiliary bus drivers. Add support for the reset controller in the G12 and SM1 audio clock controllers. * Replace the list of boolean parameters to the internal reset_control_get functions with an enum reset_flags bitfield, to make the code more self-descriptive. * Add devres helpers to request pre-deasserted (and automatically re-asserting during cleanup) reset controls. This allows reducing boilerplate in drivers that deassert resets for the lifetime of a device. * Use the new auto-deasserting devres helpers in reset-uniphier-glue as an example. * Add support for the LAN966x PCI device in drivers/misc, as a dependency for the following reset-microchip-sparx5 patches. * Add support for being used on the LAN966x PCI device to the reset-microchip-sparx5 driver. Commit 86f134941a4b ("MAINTAINERS: Add the Microchip LAN966x PCI driver entry") introduces a trivial merge conflict with commit 7280f01e79cc ("net: lan969x: add match data for lan969x") from the net-next tree [1]. [1] https://lore.kernel.org/all/20241101122505.3eacd183@canb.auug.org.au/ * tag 'reset-for-v6.13' of git://git.pengutronix.de/pza/linux: (21 commits) misc: lan966x_pci: Fix dtc warn 'Missing interrupt-parent' misc: lan966x_pci: Fix dtc warns 'missing or empty reg/ranges property' reset: mchp: sparx5: set the dev member of the reset controller reset: mchp: sparx5: Allow building as a module reset: mchp: sparx5: Add MCHP_LAN966X_PCI dependency reset: mchp: sparx5: Map cpu-syscon locally in case of LAN966x MAINTAINERS: Add the Microchip LAN966x PCI driver entry misc: Add support for LAN966x PCI device reset: uniphier-glue: Use devm_reset_control_bulk_get_shared_deasserted() reset: Add devres helpers to request pre-deasserted reset controls reset: replace boolean parameters with flags parameter reset: amlogic: Fix small whitespace issue reset: amlogic: add auxiliary reset driver support reset: amlogic: split the device core and platform probe reset: amlogic: move drivers to a dedicated directory reset: amlogic: add reset status support reset: amlogic: use reset number instead of register count reset: amlogic: add driver parameters reset: amlogic: make parameters unsigned reset: amlogic: use generic data matching function ... Link: https://lore.kernel.org/r/20241105105229.3729474-1-p.zabel@pengutronix.de Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-11-12Merge tag 'scmi-updates-6.13' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into soc/drivers Arm SCMI updates for v6.13 Just couple of main additions: 1. Support for variable I/O width within ARM SCMI shared memory area. Some shared memory areas might only support a certain access width, such as 32-bit, which memcpy_{from,to}_io() does not adhere to at least on ARM64 by making both 8-bit and 64-bit accesses to such memory. This support updates the shmem layer to support reading from and writing to such shared memory area using the specified I/O width in the Device Tree. The various transport layers making use of the shmem.c code are updated accordingly to pass the I/O accessors that they store. The device tree bindings are also updated for the same. 2. Extension of SCMI transport bindings to add more properties SCMI transports are characterized by a number of properties. The values assumed by some of them tightly depend on the choices taken at design time and on the overall archiecture of the specific platform: things like timeouts, maximum message size and number of in-flight messages are closely tied to the architecture of the platform like number of SCMI agents on the system, physical memory available to the SCMI platform and so on. Such details are not discoverable as they are outside the scope of the SCMI protocol specification. Currently such properties are simple default values defined at build time, but the increasing number and variety of platforms using SCMI with a wide range of designs has increased the need to have a way to describe such properties across all these platforms. Apart from the above two, there is one NULL pointer dereference fix for very age old SCPI protocol driver which seems to be still in use on few platforms. * tag 'scmi-updates-6.13' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_scpi: Check the DVFS OPP count returned by the firmware firmware: arm_scmi: Relocate atomic_threshold to scmi_desc firmware: arm_scmi: Use max_msg and max_msg_size devicetree properties dt-bindings: firmware: arm,scmi: Introduce more transport properties firmware: arm_scmi: Calculate virtio PDU max size dynamically firmware: arm_scmi: Account for SHMEM memory overhead firmware: arm_scmi: Support 'reg-io-width' property for shared memory dt-bindings: sram: Document reg-io-width property firmware: arm_scmi: Use vendor string in max-rx-timeout-ms dt-bindings: firmware: arm,scmi: Add missing vendor string firmware: arm_scmi: Reject clear channel request on A2P firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier() Link: https://lore.kernel.org/r/20241106110727.4007489-1-sudeep.holla@arm.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-11-12bus: Switch back to struct platform_driver::remove()Uwe Kleine-König
After commit 0edb555a65d1 ("platform: Make platform_driver::remove() return void") .remove() is (again) the right callback to implement for platform drivers. Convert all platform drivers below drivers/bus to use .remove(), with the eventual goal to drop struct platform_driver::remove_new(). As .remove() and .remove_new() have the same prototypes, conversion is done by just changing the structure member name in the driver initializer. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-11-12Revert "RDMA/core: Fix ENODEV error for iWARP test over vlan"Leon Romanovsky
The citied commit in Fixes line caused to regression for udaddy [1] application. It doesn't work over VLANs anymore. Client: ifconfig eth2 1.1.1.1 ip link add link eth2 name p0.3597 type vlan protocol 802.1Q id 3597 ip link set dev p0.3597 up ip addr add 2.2.2.2/16 dev p0.3597 udaddy -S 847 -C 220 -c 2 -t 0 -s 2.2.2.3 -b 2.2.2.2 Server: ifconfig eth2 1.1.1.3 ip link add link eth2 name p0.3597 type vlan protocol 802.1Q id 3597 ip link set dev p0.3597 up ip addr add 2.2.2.3/16 dev p0.3597 udaddy -S 847 -C 220 -c 2 -t 0 -b 2.2.2.3 [1] https://github.com/linux-rdma/rdma-core/blob/master/librdmacm/examples/udaddy.c Fixes: 5069d7e202f6 ("RDMA/core: Fix ENODEV error for iWARP test over vlan") Reported-by: Leon Romanovsky <leonro@nvidia.com> Closes: https://lore.kernel.org/all/20241110130746.GA48891@unreal Link: https://patch.msgid.link/bb9d403419b2b9566da5b8bf0761fa8377927e49.1731401658.git.leon@kernel.org Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
2024-11-12acpi/arm64: remove unnecessary castMin-Hua Chen
DEFINE_RES_IRQ returns struct resource type, so it is unnecessary to cast it to struct resource. Remove the unnecessary cast to fix the following sparse warnings: drivers/acpi/arm64/gtdt.c:355:19: sparse: warning: cast to non-scalar drivers/acpi/arm64/gtdt.c:355:19: sparse: warning: cast from non-scalar No functional changes intended. Signed-off-by: Min-Hua Chen <minhuadotchen@gmail.com> Acked-by: Hanjun Guo <guohanjun@huawei.com> Reviewed-by: Hanjun Guo <guohanjun@huawei.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20240917233827.73167-1-minhuadotchen@gmail.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-11-12TC: Fix the wrong format specifierzhang jiao
The format specifier of "unsigned int" in pr_info() should be "%u", not "%d". Signed-off-by: zhang jiao <zhangjiao2@cmss.chinamobile.com> Acked-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2024-11-12mfd: tqmx86: Add I2C IRQ supportGregor Herburger
The i2c-ocores controller can run in interrupt mode on tqmx86 modules. Add a module parameter to allow configuring the IRQ number, similar to the handling of the GPIO IRQ. The new code and module parameter refer to the I2C controller as "I2C1", as the TQMx86 PLD actually contains a second I2C controller, for which driver support will be added in the future. Signed-off-by: Gregor Herburger <gregor.herburger@tq-group.com> Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Link: https://lore.kernel.org/r/c1b0769e00a8a4e463cffe725e939b0e5c2992c8.1731325758.git.matthias.schiffer@ew.tq-group.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-11-12mfd: tqmx86: Make IRQ setup errors non-fatalMatthias Schiffer
GPIO IRQ setup can fail either because an invalid IRQ was passed as a parameter, or because the GPIO controller does not support interrupts. Neither is severe enough to stop the whole probe; simply disable IRQ support in the GPIO resource when setup fails. The code is made a bit more robust by introduing an enum for the resource list indices instead of assuming that the IRQ is at index 0. Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Link: https://lore.kernel.org/r/2b5522362098d54c6203be6da95bbc545a21fd49.1731325758.git.matthias.schiffer@ew.tq-group.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-11-12mfd: tqmx86: Refactor GPIO IRQ setupMatthias Schiffer
Move IRQ setup into a helper function. The string "GPIO" for error messages is replaced with a label argument to prepare for reusing the function for the I2C IRQ. No functional change intended. Co-developed-by: Gregor Herburger <gregor.herburger@tq-group.com> Signed-off-by: Gregor Herburger <gregor.herburger@tq-group.com> Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Link: https://lore.kernel.org/r/97f481334f480a113b7076e76f994e0e73ee5aa5.1731325758.git.matthias.schiffer@ew.tq-group.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-11-12mfd: tqmx86: Improve gpio_irq module parameter descriptionMatthias Schiffer
Clarify that "7, 9, 12" refers to the valid arguments that can be passed as gpio_irq. Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Link: https://lore.kernel.org/r/3275f436b66f6807c02256bc852d39b03ebd64d5.1731325758.git.matthias.schiffer@ew.tq-group.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-11-12mfd: tqmx86: Add board definitions for TQMx120UC, TQMx130UC and TQMxE41SMatthias Schiffer
This adds support for 3 new TQMx86 COMs: - TQMx120UC/TQMx130UC: COM Express Compact Type 6 modules with 12th and 13th Generation Intel Core CPUs ([1, 2]) - TQMxE41S: SMARC 2.1 module with Intel Atom x7000E and compatible CPUs [3] [1] https://www.tq-group.com/en/products/tq-embedded/x86-architecture/tqmx120uc/ [2] https://www.tq-group.com/en/products/tq-embedded/x86-architecture/tqmx130uc/ [3] https://www.tq-group.com/en/products/tq-embedded/x86-architecture/tqmxe41s/ Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Link: https://lore.kernel.org/r/90ddebda96d29246992b58ae0231a511f6424211.1731325758.git.matthias.schiffer@ew.tq-group.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-11-12mfd: 88pm886: Add the RTC cellKarel Balej
Add a MFD cell for the chip's Real-Time Clock (RTC). Signed-off-by: Karel Balej <balejk@matfyz.cz> Link: https://lore.kernel.org/r/20241012193345.18594-1-balejk@matfyz.cz Signed-off-by: Lee Jones <lee@kernel.org>
2024-11-12leds: ss4200: Fix the wrong format specifier for 'blinking'Zhu Jun
The format specifier of "signed int" in sprintf() should be "%d", not "%u". Signed-off-by: Zhu Jun <zhujun2@cmss.chinamobile.com> Link: https://lore.kernel.org/r/20241111065809.3814-1-zhujun2@cmss.chinamobile.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-11-12rtc: support for the Amlogic on-chip RTCYiting Deng
This is the third amlogic driver. The RTC hardware of A4 SoC is different from the previous one. This RTC hardware includes a timing function and an alarm function. But the existing has only timing function, alarm function is using the system clock to implement a virtual alarm. Add the RTC driver to support it. Signed-off-by: Yiting Deng <yiting.deng@amlogic.com> Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com> Link: https://lore.kernel.org/r/20241112-rtc-v6-2-a71b60d2f354@amlogic.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2024-11-12spi: Delete useless checkszhang jiao
Since "res" will never be null, just delete this check. Signed-off-by: zhang jiao <zhangjiao2@cmss.chinamobile.com> Link: https://patch.msgid.link/20241112081637.40962-1-zhangjiao2@cmss.chinamobile.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-12regulator: Switch back to struct platform_driver::remove()Uwe Kleine-König
After commit 0edb555a65d1 ("platform: Make platform_driver::remove() return void") .remove() is (again) the right callback to implement for platform drivers. Convert all platform drivers below drivers/regulator to use .remove(), with the eventual goal to drop struct platform_driver::remove_new(). As .remove() and .remove_new() have the same prototypes, conversion is done by just changing the structure member name in the driver initializer. A few whitespace changes are done en passant to make indention consistent. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://patch.msgid.link/ab85510f83fa901e44d5d563fe6e768054229bfe.1731398433.git.u.kleine-koenig@baylibre.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-12s390/con3270: Use NULL instead of 0 for pointersHeiko Carstens
Get rid of sparse warnings: CHECK drivers/s390/char/con3270.c drivers/s390/char/con3270.c:531:15: warning: Using plain integer as NULL pointer drivers/s390/char/con3270.c:749:15: warning: Using plain integer as NULL pointer Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2024-11-12gpio: rockchip: support new version GPIOYe Zhang
Support the next version GPIO controller on SoCs like rk3576. Signed-off-by: Ye Zhang <ye.zhang@rock-chips.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20241112015408.3139996-4-ye.zhang@rock-chips.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-12gpio: rockchip: change the GPIO version judgment logicYe Zhang
Have a list of valid IDs and default to -ENODEV. Signed-off-by: Ye Zhang <ye.zhang@rock-chips.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20241112015408.3139996-3-ye.zhang@rock-chips.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-12gpio: rockchip: explan the format of the GPIO version IDYe Zhang
Remove redundant comments and provide a detailed explanation of the GPIO version ID. Signed-off-by: Ye Zhang <ye.zhang@rock-chips.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20241112015408.3139996-2-ye.zhang@rock-chips.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-12mfd: intel_soc_pmic_crc: Add support for non ACPI instantiated i2c_clientHans de Goede
On some x86 Bay Trail tablets which shipped with Android as factory OS, the DSDT is so broken that the PMIC needs to be manually instantiated by the special x86-android-tablets.ko "fixup" driver for cases like this. Add an i2c_device_id table so that the driver can match on manually instantiated i2c_client-s (which lack an ACPI fwnode to match on). Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20241104150655.41402-3-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-11-12mfd: intel_soc_pmic_*: Consistently use filename as driver nameHans de Goede
Currently the intel_soc_pmic_bxtwc, intel_soc_pmic_chtwc and intel_soc_pmic_crc PMIC drivers use more or less free form strings for their driver name. Where as intel_soc_pmic_chtdc_ti and intel_soc_pmic_mrfld use the driver's filename as driver name. Update the 3 others to also use the driver's filename to make the naming consistent. Suggested-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20241104150655.41402-2-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-11-12leds: pwm: Add optional DT property default-brightnessGeorge Stark
When probing if default LED state is on then default brightness will be applied instead of max brightness. Signed-off-by: George Stark <gnstark@salutedevices.com> Link: https://lore.kernel.org/r/20241105185006.1380166-3-gnstark@salutedevices.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-11-12drivers: core: fw_devlink: Fix excess parameter description in docstringAmit Vadhavana
Replace the parameter name 'con' with 'con_handle' in the docstring of __fw_devlink_relax_cycles() to resolve the kernel-doc warning about an excess parameter description. Address the following warning: ./drivers/base/core.c:1994: warning: Excess function parameter 'con' description in '__fw_devlink_relax_cycles' Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/all/20241107223528.3781323e@canb.auug.org.au/ Signed-off-by: Amit Vadhavana <av2082000@gmail.com> Link: https://lore.kernel.org/r/20241111165253.16672-1-av2082000@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-12driver core: class: Correct WARN() message in APIs ↵Zijun Hu
class_(for_each|find)_device() For both API class_for_each_device(const struct class *class, ...) and class_find_device(const struct class *class, ...), their WARN() messages prompt @class was not initialized when suffer class_to_subsys(@class) error, but the error actually means @class was not registered, so these warning messages are not accurate. Fix by replacing term initialized with registered within these messages. Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Link: https://lore.kernel.org/r/20241105-class_fix-v1-2-80866f9994a5@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-12serial: 8250_fintek: Add support for F81216EFilip Brozovic
The F81216E is a LPC/eSPI to 4 UART Super I/O and is mostly compatible with the F81216H, but does not support RS-485 auto-direction delays on any port. Signed-off-by: Filip Brozovic <fbrozovic@gmail.com> Cc: stable <stable@kernel.org> Link: https://lore.kernel.org/r/20241110111703.15494-1-fbrozovic@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-12mei: vsc: Fix typo "maintstepping" -> "mainstepping"Colin Ian King
There is a typo in a dev_err message. Fix it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20241112084507.452776-1-colin.i.king@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-12firmware: Switch back to struct platform_driver::remove()Uwe Kleine-König
After commit 0edb555a65d1 ("platform: Make platform_driver::remove() return void") .remove() is (again) the right callback to implement for platform drivers. Convert all platform drivers below drivers/firmware to use .remove(), with the eventual goal to drop struct platform_driver::remove_new(). As .remove() and .remove_new() have the same prototypes, conversion is done by just changing the structure member name in the driver initializer. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/36974feb6035201d53384557259ec72fe311053b.1731397962.git.u.kleine-koenig@baylibre.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-12misc: isl29020: Fix the wrong format specifierZhu Jun
The format specifier of "unsigned long int" in sprintf() should be "%lu", not "%ld". Signed-off-by: Zhu Jun <zhujun2@cmss.chinamobile.com> Link: https://lore.kernel.org/r/20241111091950.4299-1-zhujun2@cmss.chinamobile.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-12usb: typec: fix potential array underflow in ucsi_ccg_sync_control()Dan Carpenter
The "command" variable can be controlled by the user via debugfs. The worry is that if con_index is zero then "&uc->ucsi->connector[con_index - 1]" would be an array underflow. Fixes: 170a6726d0e2 ("usb: typec: ucsi: add support for separate DP altmode devices") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/c69ef0b3-61b0-4dde-98dd-97b97f81d912@stanley.mountain Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-12usb: misc: ljca: set small runtime autosuspend delayStanislaw Gruszka
On some Lenovo platforms, the patch works around problems with ov2740 sensor initialization, which manifest themself like below: [ 4.540476] ov2740 i2c-INT3474:01: error -EIO: failed to find sensor [ 4.542066] ov2740 i2c-INT3474:01: probe with driver ov2740 failed with error -5 or [ 7.742633] ov2740 i2c-INT3474:01: chip id mismatch: 2740 != 0 [ 7.742638] ov2740 i2c-INT3474:01: error -ENXIO: failed to find sensor and also by random failures of video stream start. Issue can be reproduced by this script: n=0 k=0 while [ $n -lt 50 ] ; do sudo modprobe -r ov2740 sleep `expr $RANDOM % 5` sudo modprobe ov2740 if media-ctl -p | grep -q ov2740 ; then let k++ fi let n++ done echo Success rate $k/$n Without the patch, success rate is approximately 15 or 50 tries. With the patch it does not fail. This problem is some hardware or firmware malfunction, that can not be easy debug and fix. While setting small autosuspend delay is not perfect workaround as user can configure it to any value, it will prevent the failures by default. Additionally setting small autosuspend delay should have positive effect on power consumption as for most ljca workloads device is used for just a few milliseconds flowed by long periods of at least 100ms of inactivity (usually more). Fixes: acd6199f195d ("usb: Add support for Intel LJCA device") Cc: stable@vger.kernel.org Reviewed-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Hans de Goede <hdegoede@redhat.com> # ThinkPad X1 Yoga Gen 8, ov2740 Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Link: https://lore.kernel.org/r/20241112075514.680712-2-stanislaw.gruszka@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-12usb: misc: ljca: move usb_autopm_put_interface() after wait for responseStanislaw Gruszka
Do not mark interface as ready to suspend when we are still waiting for response messages from the device. Fixes: acd6199f195d ("usb: Add support for Intel LJCA device") Cc: stable@vger.kernel.org Reviewed-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Hans de Goede <hdegoede@redhat.com> # ThinkPad X1 Yoga Gen 8, ov2740 Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Link: https://lore.kernel.org/r/20241112075514.680712-1-stanislaw.gruszka@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-12usb: chipidea: imx: add imx8ulp supportXu Yang
The dtbinding have imx7ulp and imx8ulp compatible with imx7d before. And then the dtb follow the dtbinding. However, the driver doesn't add imx8ulp compatible now. To make imx8ulp work well, this will add support for it. Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Acked-by: Peter Chen <peter.chen@kernel.org> Link: https://lore.kernel.org/r/20241111090916.1534047-1-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-12usb: typec: ucsi: Fix a missing bits to bytes conversion in ucsi_init()Heikki Krogerus
The GET_CAPABILITY size is wrong. The definitions for the command sizes are for bitfieds and therefore in bits, not bytes. This fixes an issue that prevents the interface from being registered with UCSI versions older than 2.0 because the command size exceeds the MESSAGE_IN field size. Fixes: 226ff2e681d0 ("usb: typec: ucsi: Convert connector specific commands to bitmaps") Reported-by: Abel Vesa <abel.vesa@linaro.org> Closes: https://lore.kernel.org/linux-usb/Zy864W7sysWZbCTd@linaro.org/ Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Tested-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/20241111100220.1743872-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-12usb: musb: Fix hardware lockup on first Rx endpoint requestHubert Wiśniewski
There is a possibility that a request's callback could be invoked from usb_ep_queue() (call trace below, supplemented with missing calls): req->complete from usb_gadget_giveback_request (drivers/usb/gadget/udc/core.c:999) usb_gadget_giveback_request from musb_g_giveback (drivers/usb/musb/musb_gadget.c:147) musb_g_giveback from rxstate (drivers/usb/musb/musb_gadget.c:784) rxstate from musb_ep_restart (drivers/usb/musb/musb_gadget.c:1169) musb_ep_restart from musb_ep_restart_resume_work (drivers/usb/musb/musb_gadget.c:1176) musb_ep_restart_resume_work from musb_queue_resume_work (drivers/usb/musb/musb_core.c:2279) musb_queue_resume_work from musb_gadget_queue (drivers/usb/musb/musb_gadget.c:1241) musb_gadget_queue from usb_ep_queue (drivers/usb/gadget/udc/core.c:300) According to the docstring of usb_ep_queue(), this should not happen: "Note that @req's ->complete() callback must never be called from within usb_ep_queue() as that can create deadlock situations." In fact, a hardware lockup might occur in the following sequence: 1. The gadget is initialized using musb_gadget_enable(). 2. Meanwhile, a packet arrives, and the RXPKTRDY flag is set, raising an interrupt. 3. If IRQs are enabled, the interrupt is handled, but musb_g_rx() finds an empty queue (next_request() returns NULL). The interrupt flag has already been cleared by the glue layer handler, but the RXPKTRDY flag remains set. 4. The first request is enqueued using usb_ep_queue(), leading to the call of req->complete(), as shown in the call trace above. 5. If the callback enables IRQs and another packet is waiting, step (3) repeats. The request queue is empty because usb_g_giveback() removes the request before invoking the callback. 6. The endpoint remains locked up, as the interrupt triggered by hardware setting the RXPKTRDY flag has been handled, but the flag itself remains set. For this scenario to occur, it is only necessary for IRQs to be enabled at some point during the complete callback. This happens with the USB Ethernet gadget, whose rx_complete() callback calls netif_rx(). If called in the task context, netif_rx() disables the bottom halves (BHs). When the BHs are re-enabled, IRQs are also enabled to allow soft IRQs to be processed. The gadget itself is initialized at module load (or at boot if built-in), but the first request is enqueued when the network interface is brought up, triggering rx_complete() in the task context via ioctl(). If a packet arrives while the interface is down, it can prevent the interface from receiving any further packets from the USB host. The situation is quite complicated with many parties involved. This particular issue can be resolved in several possible ways: 1. Ensure that callbacks never enable IRQs. This would be difficult to enforce, as discovering how netif_rx() interacts with interrupts was already quite challenging and u_ether is not the only function driver. Similar "bugs" could be hidden in other drivers as well. 2. Disable MUSB interrupts in musb_g_giveback() before calling the callback and re-enable them afterwars (by calling musb_{dis,en}able_interrupts(), for example). This would ensure that MUSB interrupts are not handled during the callback, even if IRQs are enabled. In fact, it would allow IRQs to be enabled when releasing the lock. However, this feels like an inelegant hack. 3. Modify the interrupt handler to clear the RXPKTRDY flag if the request queue is empty. While this approach also feels like a hack, it wastes CPU time by attempting to handle incoming packets when the software is not ready to process them. 4. Flush the Rx FIFO instead of calling rxstate() in musb_ep_restart(). This ensures that the hardware can receive packets when there is at least one request in the queue. Once IRQs are enabled, the interrupt handler will be able to correctly process the next incoming packet (eventually calling rxstate()). This approach may cause one or two packets to be dropped (two if double buffering is enabled), but this seems to be a minor issue, as packet loss can occur when the software is not yet ready to process them. Additionally, this solution makes the gadget driver compliant with the rule mentioned in the docstring of usb_ep_queue(). There may be additional solutions, but from these four, the last one has been chosen as it seems to be the most appropriate, as it addresses the "bad" behavior of the driver. Fixes: baebdf48c360 ("net: dev: Makes sure netif_rx() can be invoked in any context.") Cc: stable@vger.kernel.org Signed-off-by: Hubert Wiśniewski <hubert.wisniewski.25632@gmail.com> Link: https://lore.kernel.org/r/4ee1ead4525f78fb5909a8cbf99513ad0082ad21.camel@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-11-12intel-hid: fix volume buttons on Thinkpad X12 Detachable Tablet Gen 1Cole Stowell
Volume buttons on Lenovo Thinkpad X12 Detachable Tablet Gen 1 did not send any input events when pressed. When loading intel-hid with the 5 Button Array explicitly enabled, the buttons functioned normally. Adds the X12 Detachable Tablet Gen 1 to the `button_array_table`. However, the driver is unable to call INTEL_HID_DSM_BTNE_FN and prints the warning "failed to set button capability" when attempting to enable or disable the 5 Button Array. The warning should be harmless and adding more special handling to avoid it is not worth it. Co-developed-by: Mary Strodl <mstrodl@csh.rit.edu> Signed-off-by: Mary Strodl <mstrodl@csh.rit.edu> Signed-off-by: Cole Stowell <cole@stowell.pro> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20241107205908.69279-1-cole@stowell.pro Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-11-12Merge tag 'thunderbolt-for-v6.13-rc1' of ↵Greg Kroah-Hartman
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-next Mika writes: thunderbolt: Changes for v6.13 merge window This includes following USB4/Thunderbolt changes for the v6.13 merge window: - Add Gen 4 receiver lane margining support. - Replace usage of deprecated PCI functions. All these have been in linux-next with no reported issues. * tag 'thunderbolt-for-v6.13-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt: thunderbolt: Replace deprecated PCI functions thunderbolt: debugfs: Implement asymmetric lane margining thunderbolt: debugfs: Don't hardcode margining results size thunderbolt: debugfs: Refactor hardware margining result parsing thunderbolt: debugfs: Replace margining lane numbers with an enum thunderbolt: debugfs: Replace "both lanes" with "all lanes" thunderbolt: debugfs: Implement Gen 4 margining eye selection thunderbolt: debugfs: Add USB4 Gen 4 margining capabilities thunderbolt: Don't hardcode margining capabilities size
2024-11-12platform/x86: asus-wmi: Use platform_profile_cycle()Armin Wolf
Replace throttle_thermal_policy_switch_next() with platform_profile_cycle() to reduce code duplication and avoid a potential race condition with the platform profile handler. Suggested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Armin Wolf <W_Armin@gmx.de> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20241107003811.615574-3-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-11-12platform/x86: asus-wmi: Fix inconsistent use of thermal policiesArmin Wolf
When changing the thermal policy using the platform profile API, a Vivobook thermal policy is stored in throttle_thermal_policy_mode. However everywhere else a normal thermal policy is stored inside this variable, potentially confusing the platform profile. Fix this by always storing normal thermal policy values inside throttle_thermal_policy_mode and only do the conversion when writing the thermal policy to hardware. This also fixes the order in which throttle_thermal_policy_switch_next() steps through the thermal modes on Vivobook machines. Tested-by: Casey G Bowman <casey.g.bowman@intel.com> Fixes: bcbfcebda2cb ("platform/x86: asus-wmi: add support for vivobook fan profiles") Signed-off-by: Armin Wolf <W_Armin@gmx.de> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20241107003811.615574-2-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
generated by cgit (git 2.34.1) at 2025-09-15 14:27:56 +0000