summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2025-07-07wifi: mwifiex: discard erroneous disassoc frames on STA interfaceVitor Soares1-1/+3
When operating in concurrent STA/AP mode with host MLME enabled, the firmware incorrectly sends disassociation frames to the STA interface when clients disconnect from the AP interface. This causes kernel warnings as the STA interface processes disconnect events that don't apply to it: [ 1303.240540] WARNING: CPU: 0 PID: 513 at net/wireless/mlme.c:141 cfg80211_process_disassoc+0x78/0xec [cfg80211] [ 1303.250861] Modules linked in: 8021q garp stp mrp llc rfcomm bnep btnxpuart nls_iso8859_1 nls_cp437 onboard_us [ 1303.327651] CPU: 0 UID: 0 PID: 513 Comm: kworker/u9:2 Not tainted 6.16.0-rc1+ #3 PREEMPT [ 1303.335937] Hardware name: Toradex Verdin AM62 WB on Verdin Development Board (DT) [ 1303.343588] Workqueue: MWIFIEX_RX_WORK_QUEUE mwifiex_rx_work_queue [mwifiex] [ 1303.350856] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1303.357904] pc : cfg80211_process_disassoc+0x78/0xec [cfg80211] [ 1303.364065] lr : cfg80211_process_disassoc+0x70/0xec [cfg80211] [ 1303.370221] sp : ffff800083053be0 [ 1303.373590] x29: ffff800083053be0 x28: 0000000000000000 x27: 0000000000000000 [ 1303.380855] x26: 0000000000000000 x25: 00000000ffffffff x24: ffff000002c5b8ae [ 1303.388120] x23: ffff000002c5b884 x22: 0000000000000001 x21: 0000000000000008 [ 1303.395382] x20: ffff000002c5b8ae x19: ffff0000064dd408 x18: 0000000000000006 [ 1303.402646] x17: 3a36333a61623a30 x16: 32206d6f72662063 x15: ffff800080bfe048 [ 1303.409910] x14: ffff000003625300 x13: 0000000000000001 x12: 0000000000000000 [ 1303.417173] x11: 0000000000000002 x10: ffff000003958600 x9 : ffff000003625300 [ 1303.424434] x8 : ffff00003fd9ef40 x7 : ffff0000039fc280 x6 : 0000000000000002 [ 1303.431695] x5 : ffff0000038976d4 x4 : 0000000000000000 x3 : 0000000000003186 [ 1303.438956] x2 : 000000004836ba20 x1 : 0000000000006986 x0 : 00000000d00479de [ 1303.446221] Call trace: [ 1303.448722] cfg80211_process_disassoc+0x78/0xec [cfg80211] (P) [ 1303.454894] cfg80211_rx_mlme_mgmt+0x64/0xf8 [cfg80211] [ 1303.460362] mwifiex_process_mgmt_packet+0x1ec/0x460 [mwifiex] [ 1303.466380] mwifiex_process_sta_rx_packet+0x1bc/0x2a0 [mwifiex] [ 1303.472573] mwifiex_handle_rx_packet+0xb4/0x13c [mwifiex] [ 1303.478243] mwifiex_rx_work_queue+0x158/0x198 [mwifiex] [ 1303.483734] process_one_work+0x14c/0x28c [ 1303.487845] worker_thread+0x2cc/0x3d4 [ 1303.491680] kthread+0x12c/0x208 [ 1303.495014] ret_from_fork+0x10/0x20 Add validation in the STA receive path to verify that disassoc/deauth frames originate from the connected AP. Frames that fail this check are discarded early, preventing them from reaching the MLME layer and triggering WARN_ON(). This filtering logic is similar with that used in the ieee80211_rx_mgmt_disassoc() function in mac80211, which drops disassoc frames that don't match the current BSSID (!ether_addr_equal(mgmt->bssid, sdata->vif.cfg.ap_addr)), ensuring only relevant frames are processed. Tested on: - 8997 with FW 16.68.1.p197 Fixes: 36995892c271 ("wifi: mwifiex: add host mlme for client mode") Cc: stable@vger.kernel.org Signed-off-by: Vitor Soares <vitor.soares@toradex.com> Reviewed-by: Jeff Chen <jeff.chen_1@nxp.con> Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Link: https://patch.msgid.link/20250701142643.658990-1-ivitro@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-07-07Merge tag 'pm-runtime-6.17-rc1' of ↵Bartosz Golaszewski143-527/+667
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm into gpio/for-next Runtime PM updates related to autosuspend for 6.17 Make several autosuspend functions mark last busy stamp and update the documentation accordingly (Sakari Ailus).
2025-07-07PCI: dwc: Make dw_pcie_ptm_ops staticManivannan Sadhasivam1-1/+1
dw_pcie_ptm_ops is not used outside of this file, so make it static. This also fixes the sparse warning: drivers/pci/controller/dwc/pcie-designware-debugfs.c:868:27: warning: symbol 'dw_pcie_ptm_ops' was not declared. Should it be static? Fixes: 852a1fdd34a8 ("PCI: dwc: Add debugfs support for PTM context") Reported-by: Bjorn Helgaas <helgaas@kernel.org> Closes: https://lore.kernel.org/linux-pci/20250617231210.GA1172093@bhelgaas Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20250701120856.15839-1-mani@kernel.org
2025-07-07gpio: tps6586x: use new GPIO line value setter callbacksBartosz Golaszewski1-6/+9
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Link: https://lore.kernel.org/r/20250702-gpiochip-set-rv-gpio-round3-v1-12-0d23be74f71d@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-07gpio: tps65219: use new GPIO line value setter callbacksBartosz Golaszewski1-5/+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. Link: https://lore.kernel.org/r/20250702-gpiochip-set-rv-gpio-round3-v1-11-0d23be74f71d@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-07gpio: tps65218: use new GPIO line value setter callbacksBartosz Golaszewski1-13/+12
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Link: https://lore.kernel.org/r/20250702-gpiochip-set-rv-gpio-round3-v1-10-0d23be74f71d@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-07gpio: tps65218: remove unneeded callbacksBartosz Golaszewski1-6/+0
GPIO core can handle output-only chips that don't implement the get() and direction_input() callbacks. There's no need to provide dummy implementation of the latter in the driver so drop it. Link: https://lore.kernel.org/r/20250702-gpiochip-set-rv-gpio-round3-v1-9-0d23be74f71d@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-07gpio: tps65086: use new GPIO line value setter callbacksBartosz Golaszewski1-9/+7
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Link: https://lore.kernel.org/r/20250702-gpiochip-set-rv-gpio-round3-v1-8-0d23be74f71d@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-07gpio: tpic2810: use new GPIO line value setter callbacksBartosz Golaszewski1-8/+11
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Link: https://lore.kernel.org/r/20250702-gpiochip-set-rv-gpio-round3-v1-7-0d23be74f71d@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-07gpio: tpic2810: remove unneeded callbacksBartosz Golaszewski1-8/+0
GPIO core can handle output-only chips that don't implement the get() and direction_input() callbacks. There's no need to provide dummy implementation of the latter in the driver so drop it. Link: https://lore.kernel.org/r/20250702-gpiochip-set-rv-gpio-round3-v1-6-0d23be74f71d@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-07gpio: timberdale: use new GPIO line value setter callbacksBartosz Golaszewski1-4/+3
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Link: https://lore.kernel.org/r/20250702-gpiochip-set-rv-gpio-round3-v1-5-0d23be74f71d@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-07gpio: thunderx: use new GPIO line value setter callbacksBartosz Golaszewski1-7/+11
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Link: https://lore.kernel.org/r/20250702-gpiochip-set-rv-gpio-round3-v1-4-0d23be74f71d@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-07gpio: tegra: use new GPIO line value setter callbacksBartosz Golaszewski1-3/+5
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Link: https://lore.kernel.org/r/20250702-gpiochip-set-rv-gpio-round3-v1-3-0d23be74f71d@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-07gpio: tegra186: use new GPIO line value setter callbacksBartosz Golaszewski1-5/+10
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Link: https://lore.kernel.org/r/20250702-gpiochip-set-rv-gpio-round3-v1-2-0d23be74f71d@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-07gpio: tegra186: don't call the set() callback directlyBartosz Golaszewski1-21/+21
Drivers should not dereference GPIO chip callbacks directly. Move the module's set() function higher to make it available to the direction_output() callback and call it instead. Link: https://lore.kernel.org/r/20250702-gpiochip-set-rv-gpio-round3-v1-1-0d23be74f71d@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-07gpio: en7523: use new generic GPIO chip APIBartosz Golaszewski1-18/+18
Convert the driver to using the new generic GPIO chip interfaces from linux/gpio/generic.h. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250702-gpio-mmio-rework-v2-8-6b77aab684d8@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-07gpio: 74xx-mmio: use new generic GPIO chip APIBartosz Golaszewski1-15/+17
Convert the driver to using the new generic GPIO chip interfaces from linux/gpio/generic.h. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250702-gpio-mmio-rework-v2-7-6b77aab684d8@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-07gpio: cadence: use new generic GPIO chip APIBartosz Golaszewski1-21/+25
Convert the driver to using the new generic GPIO chip interfaces from linux/gpio/generic.h. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250702-gpio-mmio-rework-v2-6-6b77aab684d8@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-07gpio: cadence: use lock guardsBartosz Golaszewski1-14/+6
Simplify the code by using lock guards for the bgpio_lock. While at it: move the gpio/driver.h include into its correct place alphabetically. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250702-gpio-mmio-rework-v2-5-6b77aab684d8@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-07gpio: clps711x: use new generic GPIO chip APIBartosz Golaszewski1-11/+16
Convert the driver to using the new generic GPIO chip interfaces from linux/gpio/generic.h. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250702-gpio-mmio-rework-v2-4-6b77aab684d8@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-07gpio: mxc: use new generic GPIO chip APIBartosz Golaszewski1-17/+24
Convert the driver to using the new generic GPIO chip interfaces from linux/gpio/generic.h. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250702-gpio-mmio-rework-v2-3-6b77aab684d8@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-07gpio: mxc: use lock guards for the generic GPIO chip lockBartosz Golaszewski1-27/+21
Simplify the code by using lock guards for the bgpio_lock. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250702-gpio-mmio-rework-v2-2-6b77aab684d8@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-07Merge tag 'gpio-mmio-remove-bgpio-pdata-for-v6.17-rc1' into gpio/for-nextBartosz Golaszewski2-60/+47
Immutable branch between GPIO, MFD and ARM-SoC for v6.17-rc1 Remove struct bgpio_pdata after converting its users to generic device properties.
2025-07-07gpio: mmio: remove struct bgpio_pdataBartosz Golaszewski1-54/+19
With no more users, we can now remove struct bgpio_pdata. Move the relevant bits from bgpio_parse_fw() into bgpio_pdev_probe() while maintaining the logical ordering (get flags before calling bgpio_init()). Link: https://lore.kernel.org/r/20250701-gpio-mmio-pdata-v2-6-ebf34d273497@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-07mfd: vexpress-sysreg: set-up software nodes for gpio-mmioBartosz Golaszewski1-18/+28
Replace struct bgpio_pdata - that we plan to remove - with software nodes containing properties encoding the same values thatr can now be parsed by gpio-mmio. Acked-by: Lee Jones <lee@kernel.org> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250701-gpio-mmio-pdata-v2-3-ebf34d273497@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-07gpio: mmio: get chip label and GPIO base from device propertiesBartosz Golaszewski1-0/+15
Ahead of removing struct bgpio_pdata support from the gpio-mmio generic module, let's add support for getting the relevant values from generic device properties. "label" is a semi-standardized property in some GPIO drivers so let's go with it. There's no standard "base" property, so let's use the name "gpio-mmio,base" to tie it to this driver specifically. The number of GPIOs will be retrieved using gpiochip_get_ngpios() so there's no need to look it up in the software node. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250701-gpio-mmio-pdata-v2-2-ebf34d273497@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-07gpio: mmio: drop the big-endian platform device variantBartosz Golaszewski1-3/+0
There are no more users of the "basic-mmio-gpio-be" platform device ID in the kernel. We can safely drop it. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20250701-gpio-mmio-pdata-v2-1-ebf34d273497@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-07gpio: reg: use new GPIO line value setter callbacksBartosz Golaszewski1-6/+10
struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the legacy generic gpio-reg module to using them. We have to update the two legacy ARM platforms that use it at the same time as they call the set_multiple() callbacks directly (they shouldn't but it's old technical debt I suppose). Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20250623-gpiochip-set-rv-gpio-v3-1-90f0e170a846@linaro.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-07pwm: Expose PWM_WFHWSIZE in public headerMichal Wilczynski1-14/+12
The WFHWSIZE constant defines the maximum size for the hardware-specific waveform representation buffer. It is currently local to drivers/pwm/core.c, which makes it inaccessible to external tools like bindgen. Move the constant to include/linux/pwm.h to make it part of the public API. As part of this change, rename it to PWM_WFHWSIZE to follow standard kernel conventions for namespacing macros in public headers. This allows bindgen to automatically generate a corresponding constant for the Rust PWM abstractions, ensuring the value remains synchronized between the C core and Rust code and preventing future maintenance issues. Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com> Link: https://lore.kernel.org/r/20250702-rust-next-pwm-working-fan-for-sending-v7-1-67ef39ff1d29@samsung.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: twl-led: Drop driver local lockingUwe Kleine-König1-42/+7
The pwm core already serializes .apply(). twl6030's .request() and .free() are also already serialized against .apply() because there is only a single PWM. So the mutex doesn't add any additional protection and can be dropped. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/c1c7f646190f7cb2fe43b10959aa8dade80cb79e.1750788649.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: sun4i: Drop driver local lockingUwe Kleine-König1-10/+0
The pwm core serializes calls to .apply(), so the driver lock doesn't add any protection and can safely be dropped. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/87b71c46b82b787959f0cea314d3010f16a50a29.1750788649.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: sti: Drop driver local lockingUwe Kleine-König1-17/+6
The pwm core already serializes calls to .apply(), so the driver local mutex adds no protection and can be dropped. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/7ad150e40b45d6cb16fee633dcd6390a49a327a1.1750788649.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: microchip-core: Drop driver local lockingUwe Kleine-König1-16/+1
The pwm core already serializes .apply() and .get_state(), so the driver local lock is always free and adds no protection. Drop it. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/6d6ef0376ea0058b040eec3b257e324493a083f1.1750788649.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: lpc18xx-sct: Drop driver local lockingUwe Kleine-König1-14/+0
Both mutexes are only used in one function each. These functions are only called by the .apply() callback. As the .apply() calls are serialized by the core since commit 1cc2e1faafb3 ("pwm: Add more locking") the mutexes have no effect apart from runtime overhead. Drop them. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Reviewed-by: Vladimir Zapolskiy <vz@mleia.com> Link: https://lore.kernel.org/r/4f7a2da37adbfe4743564245119045826d86eca6.1750788649.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: fsl-ftm: Drop driver local lockingUwe Kleine-König1-21/+7
The pwm core serializes calls to .apply(), so the driver local lock isn't needed for that. It only has the effect to serialize .apply() with .request() and .free() for a different PWM, and .request() and .free against each other. But given that .request and .free() only do a single regmap operation under the lock and regmap itself serializes register accesses, it might happen without the lock that the calls are interleaved now, but affecting different PWMs, so nothing bad can happen. So the mutex has no effect and can be dropped. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/6b72104e5e1823170c7c9664189cc0f2ca5c2347.1750788649.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: clps711x: Drop driver local lockingUwe Kleine-König1-8/+0
The pwm core serializes calls to .apply(), so the spinlock adds no additional protection. Disabling the irq is also irrelevant as the driver isn't an atomic one and so the callbacks cannot be called from atomic context. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/d4931dc0c0d657d80722cfe7d97cb4fb4ccec90e.1750788649.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: atmel: Drop driver local lockingUwe Kleine-König1-12/+0
The two functions making use of the lock are only called transitively from .apply(). Calls to .apply() are already serialized by the pwm core so the lock in the driver has no effect and can safely be dropped. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/5ad3417aecd4dc6eca9699e21691e3725ea0bb87.1750788649.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: argon-fan-hat: Add Argon40 Fan HAT supportMarek Vasut3-0/+119
Add trivial PWM driver for Argon40 Fan HAT, which is a RaspberryPi blower fan hat which can be controlled over I2C. Model this device as a PWM, so the pwm-fan can be attached to it and handle thermal zones and RPM management in a generic manner. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Link: https://lore.kernel.org/r/20250629220757.936212-3-marek.vasut+renesas@mailbox.org Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: pwm-mediatek: Add support for PWM IP V3.0.2 in MT6991/MT8196AngeloGioacchino Del Regno1-0/+14
Add support for the PWM IP version 3.0.2, found in MediaTek's Dimensity 9400 MT6991 and in the MT8196 Chromebook SoC: this needs a new register offset array and also a different offset for the PWM_CK_26M_SEL register. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20250623120118.109170-4-angelogioacchino.delregno@collabora.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: pwm-mediatek: Pass PWM_CK_26M_SEL from platform dataAngeloGioacchino Del Regno1-15/+9
In preparation for adding support for new SoCs, remove variable has_ck_26m_sel from pwm_mediatek_of_data and replace it with a u16 pwm_ck_26m_sel_reg, meant to hold the register offset for PWM_CK_26M_SEL. Also, since the reg offset is guaranteed to never be zero, the logic to check for "has_ck_26m_sel" is changed to check if the register offset in pwm_ck_26m_sel_reg is more than zero. Analogously, when writing, use the register offset from platform data instead of using the PWM_CK_26M_SEL definition. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20250623120118.109170-3-angelogioacchino.delregno@collabora.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: rockchip: Round period/duty down on apply, up on getNicolas Frattaroli1-13/+20
With CONFIG_PWM_DEBUG=y, the rockchip PWM driver produces warnings like this: rockchip-pwm fd8b0010.pwm: .apply is supposed to round down duty_cycle (requested: 23529/50000, applied: 23542/50000) This is because the driver chooses ROUND_CLOSEST for purported idempotency reasons. However, it's possible to keep idempotency while always rounding down in .apply(). Do this by making .get_state() always round up, and making .apply() always round down. This is done with u64 maths, and setting both period and duty to U32_MAX (the biggest the hardware can support) if they would exceed their 32 bits confines. Fixes: 12f9ce4a5198 ("pwm: rockchip: Fix period and duty cycle approximation") Fixes: 1ebb74cf3537 ("pwm: rockchip: Add support for hardware readout") Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Link: https://lore.kernel.org/r/20250616-rockchip-pwm-rounding-fix-v2-1-a9c65acad7b6@collabora.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: stm32: add support for stm32mp25Fabrice Gasnier1-7/+35
Add support for STM32MP25 SoC. Use newly introduced compatible to handle new features along with registers and bits diversity. The MFD part of the driver fills in ipidr, so it is used to check the hardware configuration register, when available to gather the number of PWM channels and complementary outputs. Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Link: https://lore.kernel.org/r/20250110091922.980627-5-fabrice.gasnier@foss.st.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: sophgo-sg2042: Add support for SG2044Longbin Li1-2/+87
Add PWM controller for SG2044 on base of SG2042. Reviewed-by: Chen Wang <unicorn_wang@outlook.com> Tested-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Longbin Li <looong.bin@gmail.com> Link: https://lore.kernel.org/r/20250528101139.28702-4-looong.bin@gmail.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: sophgo-sg2042: Reorganize the code structureLongbin Li1-15/+37
As the driver logic can be used in both SG2042 and SG2044, it will be better to reorganize the code structure. Reviewed-by: Chen Wang <unicorn_wang@outlook.com> Tested-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Longbin Li <looong.bin@gmail.com> Link: https://lore.kernel.org/r/20250528101139.28702-3-looong.bin@gmail.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: sifive: Fix rounding and idempotency issues in apply and get_stateNylon Chen1-6/+9
This fix ensures consistent rounding and avoids mismatches between applied and reported PWM values that could trigger false idempotency failures in debug checks This change ensures: - real_period is now calculated using DIV_ROUND_UP_ULL() to avoid underestimation. - duty_cycle is rounded up to match the fractional computation in apply() - apply() truncates the result to compensate for get_state's rounding up logic These fixes resolve issues like: .apply is supposed to round down duty_cycle (requested: 360/504000, applied: 361/504124) .apply is not idempotent (ena=1 pol=0 1739692/4032985) -> (ena=1 pol=0 1739630/4032985) Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202505080303.dBfU5YMS-lkp@intel.com/ Co-developed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Zong Li <zong.li@sifive.com> Signed-off-by: Nylon Chen <nylon.chen@sifive.com> Link: https://lore.kernel.org/r/20250529035341.51736-4-nylon.chen@sifive.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: sifive: Fix PWM algorithm and clarify inverted compare behaviorNylon Chen1-8/+31
The `frac` variable represents the pulse inactive time, and the result of this algorithm is the pulse active time. Therefore, we must reverse the result. Although the SiFive Reference Manual states "pwms >= pwmcmpX -> HIGH", the hardware behavior is inverted due to a fixed XNOR with 0. As a result, the pwmcmp register actually defines the low (inactive) portion of the pulse. The reference is SiFive FU740-C000 Manual[0] Link: https://sifive.cdn.prismic.io/sifive/1a82e600-1f93-4f41-b2d8-86ed8b16acba_fu740-c000-manual-v1p6.pdf [0] Co-developed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Zong Li <zong.li@sifive.com> Co-developed-by: Vincent Chen <vincent.chen@sifive.com> Signed-off-by: Vincent Chen <vincent.chen@sifive.com> Signed-off-by: Nylon Chen <nylon.chen@sifive.com> Link: https://lore.kernel.org/r/20250529035341.51736-3-nylon.chen@sifive.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: pxa: Allow to enable for SpacemiT K1 SoCGuodong Xu1-1/+1
The SpacemiT K1 SoC uses devices similar to the ones on PXA SoCs. Add ARCH_SPACEMIT as one of the possible architectures this driver can be enabled for. Signed-off-by: Guodong Xu <guodong@riscstar.com> Link: https://lore.kernel.org/r/20250429085048.1310409-6-guodong@riscstar.com [ukleinek: reword commit log] Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: pxa: Add optional reset controlGuodong Xu1-0/+6
Support optional reset control for the PWM PXA driver. During probe, it acquires the reset controller using devm_reset_control_get_optional_exclusive_deasserted() to get and deassert the reset controller to enable the PWM channel. Signed-off-by: Guodong Xu <guodong@riscstar.com> Link: https://lore.kernel.org/r/20250429085048.1310409-3-guodong@riscstar.com [ukleinek: Fix conflict with commit df08fff8add2 ("pwm: pxa: Improve using dev_err_probe()")] Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: Add support for pwmchip devices for faster and easier userspace accessUwe Kleine-König1-15/+307
With this change each pwmchip defining the new-style waveform callbacks can be accessed from userspace via a character device. Compared to the sysfs-API this is faster and allows to pass the whole configuration in a single ioctl allowing atomic application and thus reducing glitches. On an STM32MP13 I see: root@DistroKit:~ time pwmtestperf real 0m 1.27s user 0m 0.02s sys 0m 1.21s root@DistroKit:~ rm /dev/pwmchip0 root@DistroKit:~ time pwmtestperf real 0m 3.61s user 0m 0.27s sys 0m 3.26s pwmtestperf does essentially: for i in 0 .. 50000: pwm_set_waveform(duty_length_ns=i, period_length_ns=50000, duty_offset_ns=0) and in the presence of /dev/pwmchip0 is uses the ioctls introduced here, without that device it uses /sys/class/pwm/pwmchip0. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/ad4a4e49ae3f8ea81e23cac1ac12b338c3bf5c5b.1746010245.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
2025-07-07pwm: mediatek: Ensure to disable clocks in error pathUwe Kleine-König1-5/+8
After enabling the clocks each error path must disable the clocks again. One of them failed to do so. Unify the error paths to use goto to make it harder for future changes to add a similar bug. Fixes: 7ca59947b5fc ("pwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config()") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/20250704172728.626815-2-u.kleine-koenig@baylibre.com Cc: stable@vger.kernel.org Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-05-28 10:29:18 +0300