summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2025-05-14phy: freescale: imx8m-pcie: Simplify with dev_err_probe()Alexander Stein1-12/+9
Error handling in probe() can be a bit simpler with dev_err_probe(). Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Link: https://lore.kernel.org/r/20250429090152.1094243-1-alexander.stein@ew.tq-group.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-05-14phy: exynos5-usbdrd: s/FIELD_PREP_CONST/FIELD_PREP where appropriateAndré Draszik1-34/+28
Commit 9b6662a0f715 ("phy: exynos5-usbdrd: use GENMASK and FIELD_PREP for Exynos5 PHY registers") added FIELD_PREP_CONST() in many cases where FIELD_PREP() would have been more appropriate. It also switched existing uses of FIELD_PREP() to FIELD_PREP_CONST(). FIELD_PREP() is the preferred macro to use whenever possible while FIELD_PREP_CONST() is meant to be used in constant initialisers. Switch (back) to FIELD_PREP(). Fixes: 7e6c2ffe6c22 ("phy: exynos5-usbdrd: convert some FIELD_PREP_CONST() to FIELD_PREP()") Signed-off-by: André Draszik <andre.draszik@linaro.org> Link: https://lore.kernel.org/r/20250429-exynos5-phy-field-prep-v1-2-39eb279a3e0e@linaro.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-05-14phy: exynos5-usbdrd: fix setting LINKSYSTEM_FLADJ on exynos7870André Draszik1-0/+1
The code here is trying to set the FLADJ field to 0x20, so it should clear any previous value in that field before or'ing-in the new value. Fixes: 588d5d20ca8d ("phy: exynos5-usbdrd: add exynos7870 USBDRD support") Signed-off-by: André Draszik <andre.draszik@linaro.org> Link: https://lore.kernel.org/r/20250429-exynos5-phy-field-prep-v1-1-39eb279a3e0e@linaro.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-05-14phy: qcom: qmp-pcie: drop bogus x1e80100 qref supplyJohan Hovold1-2/+2
The PCIe PHYs on x1e80100 do not a have a qref supply so stop requesting one. This also avoids the follow warning at boot: qcom-qmp-pcie-phy 1be0000.phy: supply vdda-qref not found, using dummy regulator Fixes: e961ec81a39b ("phy: qcom: qmp: Add phy register and clk setting for x1e80100 PCIe3") Cc: Qiang Yu <quic_qianyu@quicinc.com> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/20250429075440.19901-1-johan+linaro@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-05-14spi: spi-qpic-snand: validate user/chip specific ECC propertiesGabor Juhos1-5/+37
The driver only supports 512 bytes ECC step size and 4 bit ECC strength at the moment, however it does not reject unsupported step/strength configurations. Due to this, whenever the driver is used with a flash chip which needs stronger ECC protection, the following warning is shown in the kernel log: [ 0.574648] spi-nand spi0.0: GigaDevice SPI NAND was found. [ 0.635748] spi-nand spi0.0: 256 MiB, block size: 128 KiB, page size: 2048, OOB size: 128 [ 0.649079] nand: WARNING: (null): the ECC used on your system is too weak compared to the one required by the NAND chip Although the message indicates that something is wrong, but it often gets unnoticed, which can cause serious problems. For example when the user writes something into the flash chip despite the warning, the written data may won't be readable by the bootloader or by the boot ROM. In the worst case, when the attached SPI NAND chip is the boot device, the board may not be able to boot anymore. Also, it is not even possible to create a backup of the flash, because reading its content results in bogus data. For example, dumping the first page of the flash gives this: # hexdump -C -n 2048 /dev/mtd0 00000000 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 00000040 0f 0f 0f 0f 0f 0f 0f 0d 0f 0f 0f 0f 0f 0f 0f 0f |................| 00000050 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 000001c0 0f 0f 0f 0f ff 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| 000001d0 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 00000200 0f 0f 0f 0f f5 5b ff ff 0f 0f 0f 0f 0f 0f 0f 0f |.....[..........| 00000210 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 000002f0 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 1f 0f 0f |................| 00000300 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 000003c0 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f ff 0f 0f 0f |................| 000003d0 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 00000400 0f 0f 0f 0f 0f 0f 0f 0f e9 74 c9 06 f5 5b ff ff |.........t...[..| 00000410 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 000005d0 0f 0f 0f 0f ff 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| 000005e0 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 00000600 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f c6 be 0f c3 |................| 00000610 e9 74 c9 06 f5 5b ff ff 0f 0f 0f 0f 0f 0f 0f 0f |.t...[..........| 00000620 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 00000770 0f 0f 0f 0f 8f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| 00000780 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 00000800 # Doing the same by using the downstream kernel results in different output: # hexdump -C -n 2048 /dev/mtd0 00000000 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f |................| * 00000800 # This patch adds some sanity checks to the code to prevent using the driver with unsupported ECC step/strength configurations. After the change, probing of the driver fails in such cases: [ 0.655038] spi-nand spi0.0: GigaDevice SPI NAND was found. [ 0.659159] spi-nand spi0.0: 256 MiB, block size: 128 KiB, page size: 2048, OOB size: 128 [ 0.669138] qcom_snand 79b0000.spi: only 4 bits ECC strength is supported [ 0.677476] nand: No suitable ECC configuration [ 0.689909] spi-nand spi0.0: probe with driver spi-nand failed with error -95 This helps to avoid the aforementioned hassles until support for 8 bit ECC strength gets implemented. Fixes: 7304d1909080 ("spi: spi-qpic: add driver for QCOM SPI NAND flash Interface") Signed-off-by: Gabor Juhos <j4g8y7@gmail.com> Link: https://patch.msgid.link/20250501-qpic-snand-validate-ecc-v1-1-532776581a66@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-14spi: spi-sun4i: fix early activationAlessandro Grassi1-1/+4
The SPI interface is activated before the CPOL setting is applied. In that moment, the clock idles high and CS goes low. After a short delay, CPOL and other settings are applied, which may cause the clock to change state and idle low. This transition is not part of a clock cycle, and it can confuse the receiving device. To prevent this unexpected transition, activate the interface while CPOL and the other settings are being applied. Signed-off-by: Alessandro Grassi <alessandro.grassi@mailbox.org> Link: https://patch.msgid.link/20250502095520.13825-1-alessandro.grassi@mailbox.org Signed-off-by: Mark Brown <broonie@kernel.org>
2025-05-14phy: phy-rockchip-samsung-hdptx: Fix PHY PLL output 50.25MHz errorAlgea Cao1-0/+2
When using HDMI PLL frequency division coefficient at 50.25MHz that is calculated by rk_hdptx_phy_clk_pll_calc(), it fails to get PHY LANE lock. Although the calculated values are within the allowable range of PHY PLL configuration. In order to fix the PHY LANE lock error and provide the expected 50.25MHz output, manually compute the required PHY PLL frequency division coefficient and add it to ropll_tmds_cfg configuration table. Signed-off-by: Algea Cao <algea.cao@rock-chips.com> Reviewed-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Acked-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250427095124.3354439-1-algea.cao@rock-chips.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-05-14net: enetc: fix implicit declaration of function FIELD_PREPWei Fang1-0/+1
The kernel test robot reported the following error: drivers/net/ethernet/freescale/enetc/ntmp.c: In function 'ntmp_fill_request_hdr': drivers/net/ethernet/freescale/enetc/ntmp.c:203:38: error: implicit declaration of function 'FIELD_PREP' [-Wimplicit-function-declaration] 203 | cbd->req_hdr.access_method = FIELD_PREP(NTMP_ACCESS_METHOD, | ^~~~~~~~~~ Therefore, add "bitfield.h" to ntmp_private.h to fix this issue. Fixes: 4701073c3deb ("net: enetc: add initial netc-lib driver to support NTMP") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202505101047.NTMcerZE-lkp@intel.com/ Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2025-05-14phy-zynqmp: Postpone getting clock rate until actually neededMike Looijmans1-33/+37
At probe time the driver would display the following error and abort: xilinx-psgtr fd400000.phy: Invalid rate 0 for reference clock 0 At probe time, the associated GTR driver (e.g. SATA or PCIe) hasn't initialized the clock yet, so clk_get_rate() likely returns 0 if the clock is programmable. So this driver only works if the clock is fixed. The PHY driver doesn't need to know the clock frequency at probe yet, so wait until the associated driver initializes the lane before requesting the clock rate setting. In addition to allowing the driver to be used with programmable clocks, this also reduces the driver's runtime memory footprint by removing an array of pointers from struct xpsgtr_phy. Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl> Acked-by: Michal Simek <michal.simek@amd.com> Link: https://lore.kernel.org/r/20250428063648.22034-1-mike.looijmans@topic.nl Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-05-14net: wangxun: Correct clerical errors in commentsJiawen Wu2-2/+2
There are wrong "#endif" comments in .h files need to be corrected. Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2025-05-14phy: starfive: jh7110-usb: Fix USB 2.0 host occasional detection failureHal Feng1-0/+7
JH7110 USB 2.0 host fails to detect USB 2.0 devices occasionally. With a long time of debugging and testing, we found that setting Rx clock gating control signal to normal power consumption mode can solve this problem. Signed-off-by: Hal Feng <hal.feng@starfivetech.com> Link: https://lore.kernel.org/r/20250422101244.51686-1-hal.feng@starfivetech.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-05-14phy: rockchip: samsung-hdptx: Remove unneeded semicolonChen Ni1-1/+1
Remove unnecessary semicolons reported by Coccinelle/coccicheck and the semantic patch at scripts/coccinelle/misc/semicolon.cocci. Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Link: https://lore.kernel.org/r/20250415081200.349939-1-nichen@iscas.ac.cn Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-05-14phy: qcom-qmp-usb: Fix an NULL vs IS_ERR() bugChenyuan Yang1-1/+5
The qmp_usb_iomap() helper function currently returns the raw result of devm_ioremap() for non-exclusive mappings. Since devm_ioremap() may return a NULL pointer and the caller only checks error pointers with IS_ERR(), NULL could bypass the check and lead to an invalid dereference. Fix the issue by checking if devm_ioremap() returns NULL. When it does, qmp_usb_iomap() now returns an error pointer via IOMEM_ERR_PTR(-ENOMEM), ensuring safe and consistent error handling. Signed-off-by: Chenyuan Yang <chenyuan0y@gmail.com> Fixes: a5d6b1ac56cb ("phy: qcom-qmp-usb: fix memleak on probe deferral") CC: Johan Hovold <johan@kernel.org> CC: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414125050.2118619-1-chenyuan0y@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-05-14leds: flash: Add support for flash/strobe durationRichard Leitner1-0/+15
Add support for the new V4L2_CID_FLASH_DURATION control to the LEDs driver. Signed-off-by: Richard Leitner <richard.leitner@linux.dev> Link: https://lore.kernel.org/r/20250507-ov9282-flash-strobe-v4-2-72b299c1b7c9@linux.dev Signed-off-by: Lee Jones <lee@kernel.org>
2025-05-14leds: rgb: leds-mt6370-rgb: Improve definition of some struct linear_rangeChristophe JAILLET1-8/+8
Use LINEAR_RANGE() instead of hand-writing it. It is more robust, should the layout of the structure change one day. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/1ce4245107e0a51dce502a007a69899bda018d5f.1746197460.git.christophe.jaillet@wanadoo.fr Signed-off-by: Lee Jones <lee@kernel.org>
2025-05-14leds: led-test: Provide tests for the lookup and get infrastructureLee Jones1-0/+29
This API allows providers to offer an specific LED to be looked-up by a consumer. Consumers are then able to describe the aforementioned LED and take a reference on it. For convenience, we're testing both sides of the API in just one test function here. In reality, both the provider and the consumer would be logistically orthogonal. CMD: tools/testing/kunit/kunit.py run --kunitconfig drivers/leds RESULTS: [16:38:57] Configuring KUnit Kernel ... [16:38:57] Building KUnit Kernel ... Populating config with: $ make ARCH=um O=.kunit olddefconfig Building with: $ make all compile_commands.json scripts_gdb ARCH=um O=.kunit --jobs=20 [16:39:02] Starting KUnit Kernel (1/1)... [16:39:02] ============================================================ Running tests with: $ .kunit/linux kunit.enable=1 mem=1G console=tty kunit_shutdown=halt [16:39:03] ===================== led (2 subtests) ===================== [16:39:03] [PASSED] led_test_class_register [16:39:03] [PASSED] led_test_class_add_lookup_and_get [16:39:03] ======================= [PASSED] led ======================= [16:39:03] ============================================================ [16:39:03] Testing complete. Ran 2 tests: passed: 2 [16:39:03] Elapsed time: 6.255s total, 0.001s configuring, 5.131s building, 1.106s running Link: https://lore.kernel.org/r/20250501081918.3621432-3-lee@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
2025-05-14leds: led-test: Fill out the registration test to cover more test casesLee Jones1-1/+30
Upon successful LED class device registration, it is expected that certain attributes are filled out in pre-defined ways. For instance, if provided, the .brightness_get() call-back should be called to populate the class device 'brightness' attribute, 'max_brightness' should be initialised as LED_FULL (at least until we can rid these pesky enums) and the sysfs group should be created with the class device name supplied by the caller. If subsequent registrations take place that would result in name conflicts, various outcomes are expected depending on which flags are set. If LED_REJECT_NAME_CONFLICT is disabled, registration should succeed resulting in an iteration on the provided name. Conversely, if it's enabled, then registration is expected to fail outright. We test for all of these scenarios here. Link: https://lore.kernel.org/r/20250501081918.3621432-2-lee@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
2025-05-14leds: led-test: Remove standard error checking after KUNIT_ASSERT_*()Lee Jones1-2/+0
If a KUNIT_ASSERT_*() call ends up in an assertion, the test is marked as a failure and the subsequent error checking is never executed, making it superfluous. Remove it for simplicity and to avoid confusion. Link: https://lore.kernel.org/r/20250501081918.3621432-1-lee@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
2025-05-14leds: pca995x: Fix typo in pca995x_of_match's of_device_id entryJesse Karjalainen1-1/+1
Remove the stray space between the '.' and the 'data' field name in the PCA995x device-tree match table. Signed-off-by: Jesse Karjalainen <jesse@ponkila.com> Link: https://lore.kernel.org/r/20250426020454.47059-1-jesse@ponkila.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-05-14leds: Provide skeleton KUnit testing for the LEDs frameworkLee Jones4-0/+88
Apply a very basic implementation of KUnit LED testing. More tests / use-cases will be added steadily over time. CMD: tools/testing/kunit/kunit.py run --kunitconfig drivers/leds OUTPUT: [15:34:19] Configuring KUnit Kernel ... [15:34:19] Building KUnit Kernel ... Populating config with: $ make ARCH=um O=.kunit olddefconfig Building with: $ make all compile_commands.json scripts_gdb ARCH=um O=.kunit --jobs=20 [15:34:22] Starting KUnit Kernel (1/1)... [15:34:22] ============================================================ Running tests with: $ .kunit/linux kunit.enable=1 mem=1G console=tty kunit_shutdown=halt [15:34:23] ===================== led (1 subtest) ====================== [15:34:23] [PASSED] led_test_class_register [15:34:23] ======================= [PASSED] led ======================= [15:34:23] ============================================================ [15:34:23] Testing complete. Ran 1 tests: passed: 1 [15:34:23] Elapsed time: 4.268s total, 0.001s configuring, 3.048s building, 1.214s running Link: https://lore.kernel.org/r/20250424144544.1438584-1-lee@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
2025-05-14leds: tca6507: Use new GPIO line value setter callbacksBartosz Golaszewski1-5/+6
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250423-gpiochip-set-rv-leds-v1-4-2f42d8fbb525@linaro.org Signed-off-by: Lee Jones <lee@kernel.org>
2025-05-14leds: pca9532: Use new GPIO line value setter callbacksBartosz Golaszewski1-5/+6
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250423-gpiochip-set-rv-leds-v1-3-2f42d8fbb525@linaro.org Signed-off-by: Lee Jones <lee@kernel.org>
2025-05-14leds: pca955x: Use new GPIO line value setter callbacksBartosz Golaszewski1-4/+4
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250423-gpiochip-set-rv-leds-v1-2-2f42d8fbb525@linaro.org Signed-off-by: Lee Jones <lee@kernel.org>
2025-05-14leds: lgm-sso: Use new GPIO line value setter callbacksBartosz Golaszewski1-2/+4
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250423-gpiochip-set-rv-leds-v1-1-2f42d8fbb525@linaro.org Signed-off-by: Lee Jones <lee@kernel.org>
2025-05-14leds: Do not enable by default during compile testingKrzysztof Kozlowski1-2/+2
Enabling the compile test should not cause automatic enabling of all drivers, but only allow to choose to compile them. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250417074656.81626-1-krzysztof.kozlowski@linaro.org Signed-off-by: Lee Jones <lee@kernel.org>
2025-05-14leds: turris-omnia: Drop commas in the terminator entriesMarek Behún1-2/+2
Drop commas in terminator entries of `struct attribute` array and `struct of_device_id` array. Signed-off-by: Marek Behún <kabel@kernel.org> Link: https://lore.kernel.org/r/20250417070507.24929-1-kabel@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
2025-05-14leds: lp8860: Disable GPIO with devm actionAndrew Davis1-25/+13
This helps prevent mistakes like disable out of order in cleanup functions and forgetting to free on error paths (as was done here). This was the last thing the .remove() function did, so remove that too. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20250407183555.409687-6-afd@ti.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-05-14leds: lp8860: Only unlock in lp8860_unlock_eeprom()Andrew Davis1-30/+18
Locking is a single register write, so no need to have the unlock function also lock. This removes the need to pass in the option and reduces the nesting level in the function. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20250407183555.409687-5-afd@ti.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-05-14leds: lp8860: Enable regulator using enable_optional helperAndrew Davis1-28/+4
This allows the regulator to be optional which is the same as done here with all the checks for NULL. This also disables on remove for us, so remove the manual disabling. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20250407183555.409687-4-afd@ti.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-05-14leds: lp8860: Remove default regs when not cachingAndrew Davis1-52/+0
If we are not using regmap caches, then the value will be read in every time, having a default value does not change anything in that case. Remove the unused defaults. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20250407183555.409687-3-afd@ti.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-05-14leds: lp8860: Use new mutex guards to cleanup function exitsAndrew Davis1-16/+11
Use scoped mutex guards to simplify return paths. While here use devm_mutex_init() to register the muxex so it also is cleaned up automatically. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20250407183555.409687-2-afd@ti.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-05-14leds: lp8860: Use regmap_multi_reg_write for EEPROM writesAndrew Davis1-15/+6
This helper does the same thing as manual looping, use it instead. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20250407183555.409687-1-afd@ti.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-05-14leds: pca955x: Avoid potential overflow when filling default_labelAndy Shevchenko1-11/+9
GCC compiler (Debian 14.2.0-17) is not happy about printing into a too short buffer (when build with `make W=1`): drivers/leds/leds-pca955x.c:554:33: note: ‘snprintf’ output between 2 and 12 bytes into a destination of size 8 Indeed, the buffer size is chosen based on some assumptions, while in general the assigned value might not fit (GCC can't prove it does). Fix this by changing the bits field in the struct pca955x_chipdef to u8, with a positive side effect of the better memory footprint, and convert loop iterator to be unsigned. With that done, update format specifiers accordingly. In one case join back string literal as it improves the grepping over the code based on the message and remove duplicating information (the driver name is printed as pert of the dev_*() output [1]) as we touch the same line anyway. Link: https://lore.kernel.org/r/4ac527f2-c59e-70a2-efd4-da52370ea557@dave.eu/ [1] Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20250407151441.706378-1-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-05-14leds: multicolor: Fix intensity setting while SW blinkingSven Schwermer1-1/+2
When writing to the multi_intensity file, don't unconditionally call led_set_brightness. By only doing this if blinking is inactive we prevent blinking from stopping if the blinking is in its off phase while the file is written. Instead, if blinking is active, the changed intensity values are applied upon the next blink. This is consistent with changing the brightness on monochrome LEDs with active blinking. Suggested-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Reviewed-by: Tobias Deiminger <tobias.deiminger@linutronix.de> Tested-by: Sven Schuchmann <schuchmann@schleissheimer.de> Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com> Link: https://lore.kernel.org/r/20250404184043.227116-1-sven@svenschwermer.de Signed-off-by: Lee Jones <lee@kernel.org>
2025-05-14phy: mediatek: xsphy: support type switch by pericfgDaniel Golle1-1/+84
Patch from Sam Shih <sam.shih@mediatek.com> found in MediaTek SDK released under GPL. Get syscon and use it to set the PHY type. Extend support to PCIe and SGMII mode in addition to USB2 and USB3. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Signed-off-by: Frank Wunderlich <frank-w@public-files.de> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20250422132438.15735-7-linux@fw-web.de Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-05-14pwm: Tidyup PWM menu for RenesasKuninori Morimoto2-25/+25
Because current PWM Kconfig is sorting by symbol name, it looks strange ordering in menuconfig. => [ ] Renesas R-Car PWM support => [ ] Renesas TPU PWM support [ ] Rockchip PWM support => [ ] Renesas RZ/G2L General PWM Timer support => [ ] Renesas RZ/G2L MTU3a PWM Timer support Let's use common CONFIG_PWM_RENESAS_xxx symbol name for Renesas, and sort it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/877c2mxrrr.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-05-14Merge tag 'renesas-arm-defconfig-for-v6.16-tag2' of ↵Uwe Kleine-König1-0/+42
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into pwm/for-next Renesas ARM defconfig updates for v6.16 (take two) - Enable modular support for the Renesas RZ/G2L GPT and MSIOF sound in the ARM64 defconfig, - Enable more support for RZN1D-DB/EB in shmobile_defconfig. It is merged into the pwm tree due to the next patch renaming PWM_RZG2L_GPT which has a use added in the arm64 defconfig.
2025-05-14memory: stm32_omm: Fix error handling in stm32_omm_disable_child()Patrice Chotard1-1/+1
Fix stm32_omm_toggle_child_clock() return value test, we should exit only on non zero value. Fixes: 8181d061dcff ("memory: Add STM32 Octo Memory Manager driver") Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Link: https://lore.kernel.org/r/20250513-stm32_omm_fix_typo-v1-1-5b90ec8b52e7@foss.st.com Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/all/aB29hOrv0nU73RCn@stanley.mountain/ Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2025-05-14nvme: multipath: enable BLK_FEAT_ATOMIC_WRITES for multipathingAlan Adamson1-1/+2
A change to QEMU resulted in all nvme controllers (single and multi-controller subsystems) to have its CMIC.MCTRS bit set which indicates the subsystem supports multiple controllers and it is possible a namespace can be shared between those multiple controllers in a multipath configuration. When a namespace of a CMIC.MCTRS enabled subsystem is allocated, a multipath node is created. The queue limits for this node are inherited from the namespace being allocated. When inheriting queue limits, the features being inherited need to be specified. The atomic write feature (BLK_FEAT_ATOMIC_WRITES) was not specified so the atomic queue limits were not inherited by the multipath disk node which resulted in the sysfs atomic write attributes being zeroed. The fix is to include BLK_FEAT_ATOMIC_WRITES in the list of features to be inherited. Signed-off-by: Alan Adamson <alan.adamson@oracle.com> Reviewed-by: John Garry <john.g.garry@oracle.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
2025-05-14w1: ds2406: use crc16() instead of crc16_byte() loopEric Biggers1-10/+2
Instead of looping through each byte and calling crc16_byte(), instead just call crc16() on the whole buffer. No functional change. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Ard Biesheuvel <ardb@kernel.org> Link: https://lore.kernel.org/r/20250513022115.39109-2-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@google.com>
2025-05-14qlcnic: fix memory leak in qlcnic_sriov_channel_cfg_cmd()Abdun Nihaal1-2/+5
In one of the error paths in qlcnic_sriov_channel_cfg_cmd(), the memory allocated in qlcnic_sriov_alloc_bc_mbx_args() for mailbox arguments is not freed. Fix that by jumping to the error path that frees them, by calling qlcnic_free_mbx_args(). This was found using static analysis. Fixes: f197a7aa6288 ("qlcnic: VF-PF communication channel implementation") Signed-off-by: Abdun Nihaal <abdun.nihaal@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250512044829.36400-1-abdun.nihaal@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-14net: mlxsw: convert to ndo_hwtstamp_get() and ndo_hwtstamp_set()Vladimir Oltean4-72/+48
New timestamping API was introduced in commit 66f7223039c0 ("net: add NDOs for configuring hardware timestamping") from kernel v6.6. It is time to convert the mlxsw driver to the new API, so that the ndo_eth_ioctl() path can be removed completely. The UAPI is still ioctl-only, but it's best to remove the "ioctl" mentions from the driver in case a netlink variant appears. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20250512154411.848614-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-14net: ipa: Make the SMEM item ID constantKonrad Dybcio11-21/+11
It can't vary, stop storing the same magic number everywhere. Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Alex Elder <elder@kernel.org> Link: https://patch.msgid.link/20250512-topic-ipa_smem-v1-1-302679514a0d@oss.qualcomm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-14net: enetc: convert to ndo_hwtstamp_get() and ndo_hwtstamp_set()Vladimir Oltean4-26/+31
New timestamping API was introduced in commit 66f7223039c0 ("net: add NDOs for configuring hardware timestamping") from kernel v6.6. It is time to convert the ENETC driver to the new API, so that the ndo_eth_ioctl() path can be removed completely. Move the enetc_hwtstamp_get() and enetc_hwtstamp_set() calls away from enetc_ioctl() to dedicated net_device_ops for the LS1028A PF and VF (NETC v4 does not yet implement enetc_ioctl()), adapt the prototypes and export these symbols (enetc_ioctl() is also exported). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20250512112402.4100618-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-14net: txgbe: Fix pending interruptJiawen Wu1-6/+1
For unknown reasons, sometimes the value of MISC interrupt is 0 in the IRQ handle function. In this case, wx_intr_enable() is also should be invoked to clear the interrupt. Otherwise, the next interrupt would never be reported. Fixes: a9843689e2de ("net: txgbe: add sriov function support") Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/F4F708403CE7090B+20250512100652.139510-1-jiawenwu@trustnetic.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-14net/mlx5e: Disable MACsec offload for uplink representor profileCarolina Jubran1-0/+4
MACsec offload is not supported in switchdev mode for uplink representors. When switching to the uplink representor profile, the MACsec offload feature must be cleared from the netdevice's features. If left enabled, attempts to add offloads result in a null pointer dereference, as the uplink representor does not support MACsec offload even though the feature bit remains set. Clear NETIF_F_HW_MACSEC in mlx5e_fix_uplink_rep_features(). Kernel log: Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f] CPU: 29 UID: 0 PID: 4714 Comm: ip Not tainted 6.14.0-rc4_for_upstream_debug_2025_03_02_17_35 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__mutex_lock+0x128/0x1dd0 Code: d0 7c 08 84 d2 0f 85 ad 15 00 00 8b 35 91 5c fe 03 85 f6 75 29 49 8d 7e 60 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 a6 15 00 00 4d 3b 76 60 0f 85 fd 0b 00 00 65 ff RSP: 0018:ffff888147a4f160 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000001 RDX: 000000000000000f RSI: 0000000000000000 RDI: 0000000000000078 RBP: ffff888147a4f2e0 R08: ffffffffa05d2c19 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: dffffc0000000000 R14: 0000000000000018 R15: ffff888152de0000 FS: 00007f855e27d800(0000) GS:ffff88881ee80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000004e5768 CR3: 000000013ae7c005 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 Call Trace: <TASK> ? die_addr+0x3d/0xa0 ? exc_general_protection+0x144/0x220 ? asm_exc_general_protection+0x22/0x30 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? __mutex_lock+0x128/0x1dd0 ? lockdep_set_lock_cmp_fn+0x190/0x190 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? mutex_lock_io_nested+0x1ae0/0x1ae0 ? lock_acquire+0x1c2/0x530 ? macsec_upd_offload+0x145/0x380 ? lockdep_hardirqs_on_prepare+0x400/0x400 ? kasan_save_stack+0x30/0x40 ? kasan_save_stack+0x20/0x40 ? kasan_save_track+0x10/0x30 ? __kasan_kmalloc+0x77/0x90 ? __kmalloc_noprof+0x249/0x6b0 ? genl_family_rcv_msg_attrs_parse.constprop.0+0xb5/0x240 ? mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] mlx5e_macsec_add_secy+0xf9/0x700 [mlx5_core] ? mlx5e_macsec_add_rxsa+0x11a0/0x11a0 [mlx5_core] macsec_update_offload+0x26c/0x820 ? macsec_set_mac_address+0x4b0/0x4b0 ? lockdep_hardirqs_on_prepare+0x284/0x400 ? _raw_spin_unlock_irqrestore+0x47/0x50 macsec_upd_offload+0x2c8/0x380 ? macsec_update_offload+0x820/0x820 ? __nla_parse+0x22/0x30 ? genl_family_rcv_msg_attrs_parse.constprop.0+0x15e/0x240 genl_family_rcv_msg_doit+0x1cc/0x2a0 ? genl_family_rcv_msg_attrs_parse.constprop.0+0x240/0x240 ? cap_capable+0xd4/0x330 genl_rcv_msg+0x3ea/0x670 ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0 ? lockdep_set_lock_cmp_fn+0x190/0x190 ? macsec_update_offload+0x820/0x820 netlink_rcv_skb+0x12b/0x390 ? genl_family_rcv_msg_dumpit+0x2a0/0x2a0 ? netlink_ack+0xd80/0xd80 ? rwsem_down_read_slowpath+0xf90/0xf90 ? netlink_deliver_tap+0xcd/0xac0 ? netlink_deliver_tap+0x155/0xac0 ? _copy_from_iter+0x1bb/0x12c0 genl_rcv+0x24/0x40 netlink_unicast+0x440/0x700 ? netlink_attachskb+0x760/0x760 ? lock_acquire+0x1c2/0x530 ? __might_fault+0xbb/0x170 netlink_sendmsg+0x749/0xc10 ? netlink_unicast+0x700/0x700 ? __might_fault+0xbb/0x170 ? netlink_unicast+0x700/0x700 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x53f/0x760 ? import_iovec+0x7/0x10 ? kernel_sendmsg+0x30/0x30 ? __copy_msghdr+0x3c0/0x3c0 ? filter_irq_stacks+0x90/0x90 ? stack_depot_save_flags+0x28/0xa30 ___sys_sendmsg+0xeb/0x170 ? kasan_save_stack+0x30/0x40 ? copy_msghdr_from_user+0x110/0x110 ? do_syscall_64+0x6d/0x140 ? lock_acquire+0x1c2/0x530 ? __virt_addr_valid+0x116/0x3b0 ? __virt_addr_valid+0x1da/0x3b0 ? lock_downgrade+0x680/0x680 ? __delete_object+0x21/0x50 __sys_sendmsg+0xf7/0x180 ? __sys_sendmsg_sock+0x20/0x20 ? kmem_cache_free+0x14c/0x4e0 ? __x64_sys_close+0x78/0xd0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f855e113367 Code: 0e 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10 RSP: 002b:00007ffd15e90c88 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f855e113367 RDX: 0000000000000000 RSI: 00007ffd15e90cf0 RDI: 0000000000000004 RBP: 00007ffd15e90dbc R08: 0000000000000028 R09: 000000000045d100 R10: 00007f855e011dd8 R11: 0000000000000246 R12: 0000000000000019 R13: 0000000067c6b785 R14: 00000000004a1e80 R15: 0000000000000000 </TASK> Modules linked in: 8021q garp mrp sch_ingress openvswitch nsh mlx5_ib mlx5_fwctl mlx5_dpll mlx5_core rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay zram zsmalloc fuse [last unloaded: mlx5_core] ---[ end trace 0000000000000000 ]--- Fixes: 8ff0ac5be144 ("net/mlx5: Add MACsec offload Tx command support") Signed-off-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Shahar Shitrit <shshitrit@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/1746958552-561295-1-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-14net/mlx5: HWS, dump bad completion detailsYevgeny Kliteynik2-3/+120
Failing to insert/delete a rule should not happen. If it does happen, it would be good to know at which stage it happened and what was the failure. This patch adds printing of bad CQE details. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Vlad Dogaru <vdogaru@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1746992290-568936-11-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-14net/mlx5: HWS, rework rehash loopYevgeny Kliteynik1-75/+52
Reworking the rehash loop - simplifying the code and making it less error prone: - Instead of doing round-robin on all the queues with batch of rules in each cycle, just go over all the queues and move all the rules that belong to this queue. - If at some stage of moving the rule we get a failure (which should not happen), this can't be rolled back. So instead of aborting rehash and leaving the matcher in a broken state, allow the loop to continue: attempt to move the rest of the rules and delete the old matcher. A rule that failed to move to a new matcher will loose its match STE once the rehash is completed and the old matcher is deleted, so the rule won't match any traffic any more. This rule's packets will fall back to the steering pipeline w/o HW offload. Rehash procedure will return an error, which will cause the rule insertion to fail for the rule that started this whole rehash. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Vlad Dogaru <vdogaru@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1746992290-568936-10-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-14net/mlx5: HWS, fix redundant extension of action templatesYevgeny Kliteynik1-51/+54
When a rule is inserted into a matcher, we search for the suitable action template. If such template is not found, action template array is extended with the new template. However, when several threads are performing this in parallel, there is a race - we can end up with extending the action templates array with the same template. This patch is doing the following: - refactor the code to find action template index in rule create and update, have the common code in an auxiliary function - after locking all the queues, check again if the action template array still needs to be extended Signed-off-by: Vlad Dogaru <vdogaru@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1746992290-568936-9-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-14net/mlx5: HWS, fix counting of rules in the matcherYevgeny Kliteynik1-5/+5
Currently the counter that counts number of rules in a matcher is increased only when rule insertion is completed. In a multi-threaded usecase this can lead to a scenario that many rules can be in process of insertion in the same matcher, while none of them has completed the insertion and the rule counter is not updated. This results in a rule insertion failure for many of them at first attempt, which leads to all of them requiring rehash and requiring locking of all the queue locks. This patch fixes the case by increasing the rule counter in the beginning of insertion process and decreasing in case of any failure. Signed-off-by: Vlad Dogaru <vdogaru@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/1746992290-568936-8-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-18 08:07:02 +0300