summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
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-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-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-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>
2024-11-12platform/x86: hp: hp-bioscfg: remove redundant if statementColin Ian King
The if statement performs the same action if the strcmp result is true or false since there is identical code on both branches. The if statement is redundant and can be replaced with just one call to sysfs_remove_group. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20241107113543.17137-1-colin.i.king@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2024-11-12HID: hyperv: streamline driver probe to avoid devres issuesVitaly Kuznetsov
It was found that unloading 'hid_hyperv' module results in a devres complaint: ... hv_vmbus: unregistering driver hid_hyperv ------------[ cut here ]------------ WARNING: CPU: 2 PID: 3983 at drivers/base/devres.c:691 devres_release_group+0x1f2/0x2c0 ... Call Trace: <TASK> ? devres_release_group+0x1f2/0x2c0 ? __warn+0xd1/0x1c0 ? devres_release_group+0x1f2/0x2c0 ? report_bug+0x32a/0x3c0 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? devres_release_group+0x1f2/0x2c0 ? devres_release_group+0x90/0x2c0 ? rcu_is_watching+0x15/0xb0 ? __pfx_devres_release_group+0x10/0x10 hid_device_remove+0xf5/0x220 device_release_driver_internal+0x371/0x540 ? klist_put+0xf3/0x170 bus_remove_device+0x1f1/0x3f0 device_del+0x33f/0x8c0 ? __pfx_device_del+0x10/0x10 ? cleanup_srcu_struct+0x337/0x500 hid_destroy_device+0xc8/0x130 mousevsc_remove+0xd2/0x1d0 [hid_hyperv] device_release_driver_internal+0x371/0x540 driver_detach+0xc5/0x180 bus_remove_driver+0x11e/0x2a0 ? __mutex_unlock_slowpath+0x160/0x5e0 vmbus_driver_unregister+0x62/0x2b0 [hv_vmbus] ... And the issue seems to be that the corresponding devres group is not allocated. Normally, devres_open_group() is called from __hid_device_probe() but Hyper-V HID driver overrides 'hid_dev->driver' with 'mousevsc_hid_driver' stub and basically re-implements __hid_device_probe() by calling hid_parse() and hid_hw_start() but not devres_open_group(). hid_device_probe() does not call __hid_device_probe() for it. Later, when the driver is removed, hid_device_remove() calls devres_release_group() as it doesn't check whether hdev->driver was initially overridden or not. The issue seems to be related to the commit 62c68e7cee33 ("HID: ensure timely release of driver-allocated resources") but the commit itself seems to be correct. Fix the issue by dropping the 'hid_dev->driver' override and using hid_register_driver()/hid_unregister_driver() instead. Alternatively, it would have been possible to rely on the default handling but HID_CONNECT_DEFAULT implies HID_CONNECT_HIDRAW and it doesn't seem to work for mousevsc as-is. Fixes: 62c68e7cee33 ("HID: ensure timely release of driver-allocated resources") Suggested-by: Michael Kelley <mhklinux@outlook.com> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Reviewed-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Saurabh Sengar <ssengar@linux.microsoft.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
2024-11-12drm/i915: Grab intel_display from the encoder to avoid potential oopsiesVille Syrjälä
Grab the intel_display from 'encoder' rather than 'state' in the encoder hooks to avoid the massive footgun that is intel_sanitize_encoder(), which passes NULL as the 'state' argument to encoder .disable() and .post_disable(). TODO: figure out how to actually fix intel_sanitize_encoder()... Fixes: ab0b0eb5c85c ("drm/i915/tv: convert to struct intel_display") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241107161123.16269-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit dc3806d9eb66d0105f8d55d462d4ef681d9eac59) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2024-11-12gpiolib: cdev: use !mem_is_zero() instead of memchr_inv(s, 0, n)Andy Shevchenko
Use the mem_is_zero() helper where possible. Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20241110201706.16614-1-andy.shevchenko@gmail.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2024-11-12mtd: spi-nor: core: replace dummy buswidth from addr to dataCheng Ming Lin
The default dummy cycle for Macronix SPI NOR flash in Octal Output Read Mode(1-1-8) is 20. Currently, the dummy buswidth is set according to the address bus width. In the 1-1-8 mode, this means the dummy buswidth is 1. When converting dummy cycles to bytes, this results in 20 x 1 / 8 = 2 bytes, causing the host to read data 4 cycles too early. Since the protocol data buswidth is always greater than or equal to the address buswidth. Setting the dummy buswidth to match the data buswidth increases the likelihood that the dummy cycle-to-byte conversion will be divisible, preventing the host from reading data prematurely. Fixes: 0e30f47232ab ("mtd: spi-nor: add support for DTR protocol") Cc: stable@vger.kernel.org Reviewed-by: Pratyush Yadav <pratyush@kernel.org> Signed-off-by: Cheng Ming Lin <chengminglin@mxic.com.tw> Link: https://lore.kernel.org/r/20241112075242.174010-2-linchengming884@gmail.com Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
2024-11-12RDMA/bnxt_re: Add set_func_resources support for P5/P7 adaptersKalesh AP
Enable set_func_resources for P5 and P7 adapters to handle VF resource distribution. Remove setting max resources per VF during PF initialization. This change is required for firmwares which does not support RoCE VF resource management by NIC driver. The code is same for all adapters now. Reviewed-by: Stephen Shi <stephen.shi@broadcom.com> Reviewed-by: Rukhsana Ansari <rukhsana.ansari@broadcom.com> Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com> Link: https://patch.msgid.link/1730882676-24434-4-git-send-email-selvin.xavier@broadcom.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2024-11-12RDMA/bnxt_re: Enhance RoCE SRIOV resource configuration designBhargava Chenna Marreddy
Refine RoCE SRIOV resource configuration design, using the INITIALIZE_FW's flag as an indication for the new design to the firmware. RoCE driver does not have to provision resources to VF when firmware advertises support for RoCE resource management by NIC driver. Signed-off-by: Bhargava Chenna Marreddy <bhargava.marreddy@broadcom.com> Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Reviewed-by: Vikas Gupta <vikas.gupta@broadcom.com> Reviewed-by: Selvin Xavier <selvin.xavier@broadcom.com> CC: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com> Link: https://patch.msgid.link/1730882676-24434-3-git-send-email-selvin.xavier@broadcom.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2024-11-12bnxt_en: Add support for RoCE sriov configurationVikas Gupta
During driver load, PF RDMA driver provisions resources to the RDMA VFs. This logic takes into consideration of the total number of VFs supported on the PF while allocating resources. Firmware now advertises a capability where NIC driver can allocate resources for RDMA VFs when the user actually creates a VF. So this resource distribution can be based on the number of active VFs. This patch adds the support to check for the firmware capability and follow the new RDMA VF resource allocation strategy. The current logic in the RDMA driver will be removed for the newer Firmware versions in a subsequent patch in this series. Signed-off-by: Vikas Gupta <vikas.gupta@broadcom.com> Reviewed-by: Selvin Xavier <selvin.xavier@broadcom.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com> Link: https://patch.msgid.link/1730882676-24434-2-git-send-email-selvin.xavier@broadcom.com Signed-off-by: Leon Romanovsky <leon@kernel.org>
2024-11-12drm/i915/gsc: ARL-H and ARL-U need a newer GSC FW.Daniele Ceraolo Spurio
All MTL and ARL SKUs share the same GSC FW, but the newer platforms are only supported in newer blobs. In particular, ARL-S is supported starting from 102.0.10.1878 (which is already the minimum required version for ARL in the code), while ARL-H and ARL-U are supported from 102.1.15.1926. Therefore, the driver needs to check which specific ARL subplatform its running on when verifying that the GSC FW is new enough for it. Fixes: 2955ae8186c8 ("drm/i915: ARL requires a newer GSC firmware") Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241028233132.149745-1-daniele.ceraolospurio@intel.com (cherry picked from commit 3c1d5ced18db8a67251c8436cf9bdc061f972bdb) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2024-11-11soc: qcom: ice: Remove the device_link field in qcom_iceJoe Hattori
The struct device_link *link field in struct qcom_ice is only used to store the result of a device_link_add call with the DL_FLAG_AUTOREMOVE_SUPPLIER flag. With this flag, the resulting value can only be used to check whether the link is present or not, as per the device_link_add description, hence this commit removes the field. Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp> Link: https://lore.kernel.org/r/20241030025046.303342-1-joe@pf.is.s.u-tokyo.ac.jp Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-11-11clk: qcom: remove unused data from gcc-ipq5424.cArnd Bergmann
The newly added driver causes a warnings when enabling -Wunused-const-variables: drivers/clk/qcom/gcc-ipq5424.c:1064:30: error: 'ftbl_gcc_q6_axi_clk_src' defined but not used [-Werror=unused-const-variable=] 1064 | static const struct freq_tbl ftbl_gcc_q6_axi_clk_src[] = { | ^~~~~~~~~~~~~~~~~~~~~~~ drivers/clk/qcom/gcc-ipq5424.c:957:30: error: 'ftbl_gcc_qpic_clk_src' defined but not used [-Werror=unused-const-variable=] 957 | static const struct freq_tbl ftbl_gcc_qpic_clk_src[] = { | ^~~~~~~~~~~~~~~~~~~~~ drivers/clk/qcom/gcc-ipq5424.c:497:30: error: 'ftbl_gcc_qupv3_2x_core_clk_src' defined but not used [-Werror=unused-const-variable=] 497 | static const struct freq_tbl ftbl_gcc_qupv3_2x_core_clk_src[] = { | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In order to hopefully enable this warning by default in the future, remove the data for now. If it gets used in the future, it can trivially get added back. Fixes: 21b5d5a4a311 ("clk: qcom: add Global Clock controller (GCC) driver for IPQ5424 SoC") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20241111103258.3336183-1-arnd@kernel.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-11-11net/mlx5e: SHAMPO, Rework header allocation loopDragos Tatulea
The current loop code was based on the assumption that there can be page leftovers from previous function calls. This patch changes the allocation loop to make it clearer how pages get allocated every MLX5E_SHAMPO_WQ_HEADER_PER_PAGE headers. This change has no functional implications. Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20241107194357.683732-13-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-11net/mlx5e: SHAMPO, Drop info arrayDragos Tatulea
The info array is used to store a pointer to the dma address of the header and to the frag page. However, this array is not really required: - The frag page can be calculated from the header index frag page index = header index / headers per page. - The dma address can be calculated through a formula: dma page address + header offset. This series gets rid of the info array and uses the above formulas instead. The current_page_index was used in conjunction with the info array to store page fragment indices. This variable is dropped as well. There was no performance regression observed. Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20241107194357.683732-12-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-11net/mlx5e: SHAMPO, Change frag page setup order during allocationDragos Tatulea
Now that the UMR allocation has been simplified, it is no longer possible to have a leftover page from a previous call to mlx5e_build_shampo_hd_umr(). This patch simplifies the code by switching the order of operations: first take the frag page and then increment the index. This is more straightforward and it also paves the way for dropping the info array. Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20241107194357.683732-11-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-11net/mlx5e: SHAMPO, Fix page_index calculation inconsistencyDragos Tatulea
When calculating the index for the next frag page slot, the divisor is incorrect: it should be the number of pages per queue not the number of headers per queue. This is currently harmless because frag pages are not used directly, but they are intermediated through the info array. But it needs to be fixed as an upcoming patch will get rid of the info array. This patch introduces a new pages per queue variable and plugs it in the formula. Now that this variable exists, additional code can be simplified in the SHAMPO initialization code. Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20241107194357.683732-10-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-11net/mlx5e: SHAMPO, Simplify UMR allocation for headersDragos Tatulea
Allocating page fragments for header data split is currently more complicated than it should be. That's because the number of KSM entries allocated is not aligned to the number of headers per page. This leads to having leftovers in the next allocation which require additional accounting and needlessly complicated code. This patch aligns (down) the number of KSM entries in the UMR WQE to the number of headers per page by: 1) Aligning the max number of entries allocated per UMR WQE (max_ksm_entries) to MLX5E_SHAMPO_WQ_HEADER_PER_PAGE. 2) Aligning the total number of free headers to MLX5E_SHAMPO_WQ_HEADER_PER_PAGE. ... and then it drops the extra accounting code from mlx5e_build_shampo_hd_umr(). Although the number of entries allocated per UMR WQE is slightly smaller due to aligning down, no performance impact was observed. Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20241107194357.683732-9-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-11net/mlx5: Make vport QoS enablement more flexible for future extensionsCarolina Jubran
Refactor esw_qos_vport_enable to support more generic configurations, allowing it to be reused for new vport node types in future patches. This refactor includes a new way to change the vport parent node by disabling the current setup and re-enabling it with the new parent. This change sets the foundation for adapting configuration based on the parent type in future patches. Signed-off-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20241107194357.683732-8-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-11net/mlx5: Integrate esw_qos_vport_enable logic into rate operationsCarolina Jubran
Fold the esw_qos_vport_enable function into operations for configuring maximum and minimum rates, simplifying QoS logic. This change consolidates enabling and updating the scheduling element configuration, streamlining how vport QoS is initialized and adjusted. Signed-off-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20241107194357.683732-7-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-14 08:37:44 +0000