.../devicetree/bindings/pwm/thead,th1520-pwm.yaml | 48 ++ MAINTAINERS | 8 + arch/riscv/boot/dts/thead/th1520-lichee-pi-4a.dts | 67 ++ arch/riscv/boot/dts/thead/th1520.dtsi | 18 + drivers/clk/thead/clk-th1520-ap.c | 5 +- drivers/pwm/Kconfig | 23 + drivers/pwm/Makefile | 1 + drivers/pwm/pwm_th1520.rs | 287 +++++++ rust/bindings/bindings_helper.h | 1 + rust/helpers/helpers.c | 1 + rust/helpers/pwm.c | 20 + rust/kernel/lib.rs | 2 + rust/kernel/pwm.rs | 864 +++++++++++++++++++++ 13 files changed, 1343 insertions(+), 2 deletions(-)
This patch series introduces Rust support for the T-HEAD TH1520 PWM controller and demonstrates its use for fan control on the Sipeed Lichee Pi 4A board. The primary goal of this patch series is to introduce a basic set of Rust abstractions for the Linux PWM subsystem. As a first user and practical demonstration of these abstractions, the series also provides a functional PWM driver for the T-HEAD TH1520 SoC. This allows control of its PWM channels and ultimately enables temperature controlled fan support for the Lichee Pi 4A board. This work aims to explore the use of Rust for PWM drivers and lay a foundation for potential future Rust based PWM drivers. The core of this series is a new rust/kernel/pwm.rs module that provides abstractions for writing PWM chip provider drivers in Rust. This has been significantly reworked from v1 based on extensive feedback. The key features of the new abstraction layer include: - Ownership and Lifetime Management: The pwm::Chip wrapper is managed by ARef, correctly tying its lifetime to its embedded struct device reference counter. Chip registration is handled by a pwm::Registration RAII guard, which guarantees that pwmchip_add is always paired with pwmchip_remove, preventing resource leaks. - Modern and Safe API: The PwmOps trait is now based on the modern waveform API (round_waveform_tohw, write_waveform, etc.) as recommended by the subsystem maintainer. It is generic over a driver's hardware specific data structure, moving all unsafe serialization logic into the abstraction layer and allowing drivers to be written in 100% safe Rust. - Ergonomics: The API provides safe, idiomatic wrappers for other PWM types (State, Args, Device, etc.) and uses standard kernel error handling patterns. The series is structured as follows: - Rust PWM Abstractions: The new safe abstraction layer. - TH1520 PWM Driver: A new Rust driver for the TH1520 SoC, built on top of the new abstractions. - Clock Fix: A necessary fix to the TH1520 clock driver to ensure bus clocks remain enabled. - Device Tree Bindings & Nodes: The remaining patches add the necessary DT bindings and nodes for the TH1520 PWM controller, a thermal sensor, and the PWM fan configuration for the Lichee Pi 4A board. Testing: Tested on the TH1520 SoC. The fan works correctly. The duty/period calculaties are correct. Fan starts slow when the chip is not hot and gradually increases the speed when PVT reports higher temperatures. The patches are based on mainline, with some dependencies which are not merged yet - platform Io support [1] and math wrapper [2]. Reference repository with all the patches together can be found on github [3]. [1] - https://lore.kernel.org/rust-for-linux/20250509-topics-tyr-platform_iomem-v8-0-e9f1725a40da@collabora.com/ [2] - https://lore.kernel.org/all/20250609-math-rust-v1-v1-1-285fac00031f@samsung.com/ [3] - https://github.com/mwilczy/linux/commits/rust-next-pwm-working-fan-for-sending-v4 --- Changes in v2: - Reworked the PWM abstraction layer based on extensive feedback. - Replaced initial devm allocation with a proper ARef<Chip> lifetime model using AlwaysRefCounted. - Implemented a Registration RAII guard to ensure safe chip add/remove. - Migrated the PwmOps trait from the legacy .apply callback to the modern waveform API. - Refactored the TH1520 driver to use the new, safer abstractions. - Added a patch to mark essential bus clocks as CLK_IGNORE_UNUSED to fix boot hangs when the PWM and thermal sensors are enabled. - Link to v1: https://lore.kernel.org/r/20250524-rust-next-pwm-working-fan-for-sending-v1-0-bdd2d5094ff7@samsung.com --- Michal Wilczynski (7): rust: Add basic PWM abstractions pwm: Add Rust driver for T-HEAD TH1520 SoC clk: thead: Mark essential bus clocks as CLK_IGNORE_UNUSED dt-bindings: pwm: thead: Add T-HEAD TH1520 PWM controller riscv: dts: thead: Add PWM controller node riscv: dts: thead: Add PVT node riscv: dts: thead: Add PWM fan and thermal control .../devicetree/bindings/pwm/thead,th1520-pwm.yaml | 48 ++ MAINTAINERS | 8 + arch/riscv/boot/dts/thead/th1520-lichee-pi-4a.dts | 67 ++ arch/riscv/boot/dts/thead/th1520.dtsi | 18 + drivers/clk/thead/clk-th1520-ap.c | 5 +- drivers/pwm/Kconfig | 23 + drivers/pwm/Makefile | 1 + drivers/pwm/pwm_th1520.rs | 287 +++++++ rust/bindings/bindings_helper.h | 1 + rust/helpers/helpers.c | 1 + rust/helpers/pwm.c | 20 + rust/kernel/lib.rs | 2 + rust/kernel/pwm.rs | 864 +++++++++++++++++++++ 13 files changed, 1343 insertions(+), 2 deletions(-) --- base-commit: f153d0d0221f9d3d31872c934800d271ae8a3767 change-id: 20250524-rust-next-pwm-working-fan-for-sending-552ad2d1b193 Best regards, -- Michal Wilczynski <m.wilczynski@samsung.com>
On Tue, Jun 10, 2025 at 02:52:48PM +0200, Michal Wilczynski wrote: > This patch series introduces Rust support for the T-HEAD TH1520 PWM > controller and demonstrates its use for fan control on the Sipeed Lichee > Pi 4A board. > > The primary goal of this patch series is to introduce a basic set of > Rust abstractions for the Linux PWM subsystem. As a first user and > practical demonstration of these abstractions, the series also provides > a functional PWM driver for the T-HEAD TH1520 SoC. This allows control > of its PWM channels and ultimately enables temperature controlled fan > support for the Lichee Pi 4A board. This work aims to explore the use of > Rust for PWM drivers and lay a foundation for potential future > Rust based PWM drivers. > > The core of this series is a new rust/kernel/pwm.rs module that provides > abstractions for writing PWM chip provider drivers in Rust. This has > been significantly reworked from v1 based on extensive feedback. The key > features of the new abstraction layer include: > > - Ownership and Lifetime Management: The pwm::Chip wrapper is managed > by ARef, correctly tying its lifetime to its embedded struct device > reference counter. Chip registration is handled by a pwm::Registration > RAII guard, which guarantees that pwmchip_add is always paired with > pwmchip_remove, preventing resource leaks. > > - Modern and Safe API: The PwmOps trait is now based on the modern > waveform API (round_waveform_tohw, write_waveform, etc.) as recommended > by the subsystem maintainer. It is generic over a driver's > hardware specific data structure, moving all unsafe serialization logic > into the abstraction layer and allowing drivers to be written in 100% > safe Rust. > > - Ergonomics: The API provides safe, idiomatic wrappers for other PWM > types (State, Args, Device, etc.) and uses standard kernel error > handling patterns. > > The series is structured as follows: > - Rust PWM Abstractions: The new safe abstraction layer. > - TH1520 PWM Driver: A new Rust driver for the TH1520 SoC, built on > top of the new abstractions. > - Clock Fix: A necessary fix to the TH1520 clock driver to ensure bus > clocks remain enabled. > - Device Tree Bindings & Nodes: The remaining patches add the necessary > DT bindings and nodes for the TH1520 PWM controller, a thermal > sensor, and the PWM fan configuration for the Lichee Pi 4A board. > > Testing: > Tested on the TH1520 SoC. The fan works correctly. The duty/period > calculaties are correct. Fan starts slow when the chip is not hot and > gradually increases the speed when PVT reports higher temperatures. > > The patches are based on mainline, with some dependencies which are not > merged yet - platform Io support [1] and math wrapper [2]. > > Reference repository with all the patches together can be found on > github [3]. I'm trying to build your rust-next-pwm-working-fan-for-sending-v4 branch but I get this error: $ make W=1 LLVM=1 ARCH=riscv -j16 CALL scripts/checksyscalls.sh .pylintrc: warning: ignored by one of the .gitignore files UPD include/generated/utsversion.h CC init/version-timestamp.o KSYMS .tmp_vmlinux0.kallsyms.S AS .tmp_vmlinux0.kallsyms.o LD .tmp_vmlinux1 ld.lld: error: undefined symbol: rust_build_error referenced by pwm_th1520.4789668fc0b4e501-cgu.0 drivers/pwm/pwm_th1520.o:(<pwm_th1520::Th1520PwmDriverData as kernel::pwm::PwmOps>::get_state) in archive vmlinux.a referenced by pwm_th1520.4789668fc0b4e501-cgu.0 drivers/pwm/pwm_th1520.o:(<pwm_th1520::Th1520PwmDriverData as kernel::pwm::PwmOps>::write_waveform) in archive vmlinux.a referenced by pwm_th1520.4789668fc0b4e501-cgu.0 drivers/pwm/pwm_th1520.o:(<pwm_th1520::Th1520PwmDriverData as kernel::pwm::PwmOps>::write_waveform) in archive vmlinux.a make[2]: *** [scripts/Makefile.vmlinux:91: vmlinux] Error 1 make[1]: *** [/home/pdp7/linux/Makefile:1241: vmlinux] Error 2 make: *** [Makefile:248: __sub-make] Error 2 I've uploaded the config to: https://gist.github.com/pdp7/e2c34dd7e4349a54bd67b53254bd3a22 Thanks, Drew
On 6/10/25 23:10, Drew Fustini wrote: > On Tue, Jun 10, 2025 at 02:52:48PM +0200, Michal Wilczynski wrote: >> This patch series introduces Rust support for the T-HEAD TH1520 PWM >> controller and demonstrates its use for fan control on the Sipeed Lichee >> Pi 4A board. >> >> The primary goal of this patch series is to introduce a basic set of >> Rust abstractions for the Linux PWM subsystem. As a first user and >> practical demonstration of these abstractions, the series also provides >> a functional PWM driver for the T-HEAD TH1520 SoC. This allows control >> of its PWM channels and ultimately enables temperature controlled fan >> support for the Lichee Pi 4A board. This work aims to explore the use of >> Rust for PWM drivers and lay a foundation for potential future >> Rust based PWM drivers. >> >> The core of this series is a new rust/kernel/pwm.rs module that provides >> abstractions for writing PWM chip provider drivers in Rust. This has >> been significantly reworked from v1 based on extensive feedback. The key >> features of the new abstraction layer include: >> >> - Ownership and Lifetime Management: The pwm::Chip wrapper is managed >> by ARef, correctly tying its lifetime to its embedded struct device >> reference counter. Chip registration is handled by a pwm::Registration >> RAII guard, which guarantees that pwmchip_add is always paired with >> pwmchip_remove, preventing resource leaks. >> >> - Modern and Safe API: The PwmOps trait is now based on the modern >> waveform API (round_waveform_tohw, write_waveform, etc.) as recommended >> by the subsystem maintainer. It is generic over a driver's >> hardware specific data structure, moving all unsafe serialization logic >> into the abstraction layer and allowing drivers to be written in 100% >> safe Rust. >> >> - Ergonomics: The API provides safe, idiomatic wrappers for other PWM >> types (State, Args, Device, etc.) and uses standard kernel error >> handling patterns. >> >> The series is structured as follows: >> - Rust PWM Abstractions: The new safe abstraction layer. >> - TH1520 PWM Driver: A new Rust driver for the TH1520 SoC, built on >> top of the new abstractions. >> - Clock Fix: A necessary fix to the TH1520 clock driver to ensure bus >> clocks remain enabled. >> - Device Tree Bindings & Nodes: The remaining patches add the necessary >> DT bindings and nodes for the TH1520 PWM controller, a thermal >> sensor, and the PWM fan configuration for the Lichee Pi 4A board. >> >> Testing: >> Tested on the TH1520 SoC. The fan works correctly. The duty/period >> calculaties are correct. Fan starts slow when the chip is not hot and >> gradually increases the speed when PVT reports higher temperatures. >> >> The patches are based on mainline, with some dependencies which are not >> merged yet - platform Io support [1] and math wrapper [2]. >> >> Reference repository with all the patches together can be found on >> github [3]. > > I'm trying to build your rust-next-pwm-working-fan-for-sending-v4 branch > but I get this error: > > $ make W=1 LLVM=1 ARCH=riscv -j16 > CALL scripts/checksyscalls.sh > .pylintrc: warning: ignored by one of the .gitignore files > UPD include/generated/utsversion.h > CC init/version-timestamp.o > KSYMS .tmp_vmlinux0.kallsyms.S > AS .tmp_vmlinux0.kallsyms.o > LD .tmp_vmlinux1 > ld.lld: error: undefined symbol: rust_build_error > referenced by pwm_th1520.4789668fc0b4e501-cgu.0 > drivers/pwm/pwm_th1520.o:(<pwm_th1520::Th1520PwmDriverData as kernel::pwm::PwmOps>::get_state) in archive vmlinux.a > referenced by pwm_th1520.4789668fc0b4e501-cgu.0 > drivers/pwm/pwm_th1520.o:(<pwm_th1520::Th1520PwmDriverData as kernel::pwm::PwmOps>::write_waveform) in archive vmlinux.a > referenced by pwm_th1520.4789668fc0b4e501-cgu.0 > drivers/pwm/pwm_th1520.o:(<pwm_th1520::Th1520PwmDriverData as kernel::pwm::PwmOps>::write_waveform) in archive vmlinux.a > make[2]: *** [scripts/Makefile.vmlinux:91: vmlinux] Error 1 > make[1]: *** [/home/pdp7/linux/Makefile:1241: vmlinux] Error 2 > make: *** [Makefile:248: __sub-make] Error 2 Hi, Thanks for testing ! I can reproduce the issue with your config. The root of the problem was a failing compile time assertion (build_assert!) in the underlying Rust abstracions, I think IoMem since get_state and write_waveform functions are impacted. My development configuration was accidentally hiding this issue, but your configuration correctly exposed it. The kernel config option that is different on my setup is: CONFIG_RUST_BUILD_ASSERT_ALLOW=y Now I have to take a look at the IoMem abstractions, I think there is a new revision [1]. Will apply it and check why exactly compile assertions are triggering. [1] - https://lore.kernel.org/all/20250603-topics-tyr-platform_iomem-v9-0-a27e04157e3e@collabora.com/ > > I've uploaded the config to: > https://protect2.fireeye.com/v1/url?k=0cc1a518-535a9c14-0cc02e57-000babff3563-8df2dfc535042c2a&q=1&e=eaf92127-0b5a-4559-9796-3264da753ae3&u=https%3A%2F%2Fgist.github.com%2Fpdp7%2Fe2c34dd7e4349a54bd67b53254bd3a22 > > Thanks, > Drew > Best regards, -- Michal Wilczynski <m.wilczynski@samsung.com>
On Wed, Jun 11, 2025 at 05:14:40PM +0200, Michal Wilczynski wrote: > > > On 6/10/25 23:10, Drew Fustini wrote: > > On Tue, Jun 10, 2025 at 02:52:48PM +0200, Michal Wilczynski wrote: > >> This patch series introduces Rust support for the T-HEAD TH1520 PWM > >> controller and demonstrates its use for fan control on the Sipeed Lichee > >> Pi 4A board. > >> > >> The primary goal of this patch series is to introduce a basic set of > >> Rust abstractions for the Linux PWM subsystem. As a first user and > >> practical demonstration of these abstractions, the series also provides > >> a functional PWM driver for the T-HEAD TH1520 SoC. This allows control > >> of its PWM channels and ultimately enables temperature controlled fan > >> support for the Lichee Pi 4A board. This work aims to explore the use of > >> Rust for PWM drivers and lay a foundation for potential future > >> Rust based PWM drivers. > >> > >> The core of this series is a new rust/kernel/pwm.rs module that provides > >> abstractions for writing PWM chip provider drivers in Rust. This has > >> been significantly reworked from v1 based on extensive feedback. The key > >> features of the new abstraction layer include: > >> > >> - Ownership and Lifetime Management: The pwm::Chip wrapper is managed > >> by ARef, correctly tying its lifetime to its embedded struct device > >> reference counter. Chip registration is handled by a pwm::Registration > >> RAII guard, which guarantees that pwmchip_add is always paired with > >> pwmchip_remove, preventing resource leaks. > >> > >> - Modern and Safe API: The PwmOps trait is now based on the modern > >> waveform API (round_waveform_tohw, write_waveform, etc.) as recommended > >> by the subsystem maintainer. It is generic over a driver's > >> hardware specific data structure, moving all unsafe serialization logic > >> into the abstraction layer and allowing drivers to be written in 100% > >> safe Rust. > >> > >> - Ergonomics: The API provides safe, idiomatic wrappers for other PWM > >> types (State, Args, Device, etc.) and uses standard kernel error > >> handling patterns. > >> > >> The series is structured as follows: > >> - Rust PWM Abstractions: The new safe abstraction layer. > >> - TH1520 PWM Driver: A new Rust driver for the TH1520 SoC, built on > >> top of the new abstractions. > >> - Clock Fix: A necessary fix to the TH1520 clock driver to ensure bus > >> clocks remain enabled. > >> - Device Tree Bindings & Nodes: The remaining patches add the necessary > >> DT bindings and nodes for the TH1520 PWM controller, a thermal > >> sensor, and the PWM fan configuration for the Lichee Pi 4A board. > >> > >> Testing: > >> Tested on the TH1520 SoC. The fan works correctly. The duty/period > >> calculaties are correct. Fan starts slow when the chip is not hot and > >> gradually increases the speed when PVT reports higher temperatures. > >> > >> The patches are based on mainline, with some dependencies which are not > >> merged yet - platform Io support [1] and math wrapper [2]. > >> > >> Reference repository with all the patches together can be found on > >> github [3]. > > > > I'm trying to build your rust-next-pwm-working-fan-for-sending-v4 branch > > but I get this error: > > > > $ make W=1 LLVM=1 ARCH=riscv -j16 > > CALL scripts/checksyscalls.sh > > .pylintrc: warning: ignored by one of the .gitignore files > > UPD include/generated/utsversion.h > > CC init/version-timestamp.o > > KSYMS .tmp_vmlinux0.kallsyms.S > > AS .tmp_vmlinux0.kallsyms.o > > LD .tmp_vmlinux1 > > ld.lld: error: undefined symbol: rust_build_error > > referenced by pwm_th1520.4789668fc0b4e501-cgu.0 > > drivers/pwm/pwm_th1520.o:(<pwm_th1520::Th1520PwmDriverData as kernel::pwm::PwmOps>::get_state) in archive vmlinux.a > > referenced by pwm_th1520.4789668fc0b4e501-cgu.0 > > drivers/pwm/pwm_th1520.o:(<pwm_th1520::Th1520PwmDriverData as kernel::pwm::PwmOps>::write_waveform) in archive vmlinux.a > > referenced by pwm_th1520.4789668fc0b4e501-cgu.0 > > drivers/pwm/pwm_th1520.o:(<pwm_th1520::Th1520PwmDriverData as kernel::pwm::PwmOps>::write_waveform) in archive vmlinux.a > > make[2]: *** [scripts/Makefile.vmlinux:91: vmlinux] Error 1 > > make[1]: *** [/home/pdp7/linux/Makefile:1241: vmlinux] Error 2 > > make: *** [Makefile:248: __sub-make] Error 2 > > Hi, > > Thanks for testing ! > I can reproduce the issue with your config. > > The root of the problem was a failing compile time assertion > (build_assert!) in the underlying Rust abstracions, I think IoMem since > get_state and write_waveform functions are impacted. My development > configuration was accidentally hiding this issue, but your configuration > correctly exposed it. > > The kernel config option that is different on my setup is: > CONFIG_RUST_BUILD_ASSERT_ALLOW=y Thanks for the explanation. I wanted to see how far I could get so I also have set CONFIG_RUST_BUILD_ASSERT_ALLOW=y for now. I also enabled the pwm fan driver. However, there is a probe failure: [ 1.250921] pwm-fan pwm-fan: Failed to configure PWM: -524 [ 1.256546] pwm-fan pwm-fan: probe with driver pwm-fan failed with error -524 This seems to be the result `set_pwm(ctx, initial_pwm)` failing. It seems like the TH1520 PWM driver loaded okay: # cat /sys/class/pwm/pwmchip0/npwm 6 # ls -l /sys/class/pwm/pwmchip0/device lrwxrwxrwx 1 root root 0 Jun 12 07:37 /sys/class/pwm/pwmchip0/device -> ../../../ffec01c000.pwm # ls -l /sys/class/pwm/pwmchip0/device/driver lrwxrwxrwx 1 root root 0 Feb 28 2023 /sys/class/pwm/pwmchip0/device/driver -> ../../../../bus/platform/drivers/pwm-th1520 I'm using your mwilczy/rust-next-pwm-working-fan-for-sending-v4 branch: 7ec07c93dbac riscv: dts: thead: Add PWM fan and thermal control c8a6138b2a13 riscv: dts: thead: Add PVT node 14e2f1bfd26b riscv: dts: thead: Add PWM controller node afe06057030e dt-bindings: pwm: thead: Add T-HEAD TH1520 PWM controller fe75d1ab60c9 clk: thead: Mark essential bus clocks as CLK_IGNORE_UNUSED 47dc6a551376 pwm: Add Rust driver for T-HEAD TH1520 SoC 9370bdd31cdc rust: Add basic PWM abstractions f077d5bf0be8 Rust Abstractions for PWM subsystem with TH1520 PWM driver f153d0d0221f rust: math: Add KernelMathExt trait with a mul_div helper 51c4a2e7d48a Fix for Device<Bound> 4847fa4f7ac8 rust: platform: allow ioremap of platform resources 929c56df82e5 rust: io: mem: add a generic iomem abstraction 09dfabb4677c rust: io: add resource abstraction I uploaded the kconfig [1] and boot log [2]. Any ideas? Thanks, Drew [1] https://gist.github.com/pdp7/58ca1f543898daeb281c013facb79aed [2] https://gist.github.com/pdp7/e263b1b928a17d499f94fa5be7b3a7f8
Hello Drew, On Wed, Jun 11, 2025 at 04:52:22PM -0700, Drew Fustini wrote: > I also enabled the pwm fan driver. However, there is a probe failure: > > [ 1.250921] pwm-fan pwm-fan: Failed to configure PWM: -524 > [ 1.256546] pwm-fan pwm-fan: probe with driver pwm-fan failed with error -524 524 = ENOTSUPP, so it seems the request had duty_offset > 0. Does your fan use PWM_POLARITY_INVERTED? If so, try without that flag. If your fan really needs an inverted PWM this of course makes fan control buggy. With the next revision it should work fine (as a duty_offset > 0 should get rounded down to 0). Best regards Uwe
On 6/12/25 07:01, Uwe Kleine-König wrote: > Hello Drew, > > On Wed, Jun 11, 2025 at 04:52:22PM -0700, Drew Fustini wrote: >> I also enabled the pwm fan driver. However, there is a probe failure: >> >> [ 1.250921] pwm-fan pwm-fan: Failed to configure PWM: -524 >> [ 1.256546] pwm-fan pwm-fan: probe with driver pwm-fan failed with error -524 > > 524 = ENOTSUPP, so it seems the request had duty_offset > 0. Does your > fan use PWM_POLARITY_INVERTED? If so, try without that flag. If your fan > really needs an inverted PWM this of course makes fan control buggy. > With the next revision it should work fine (as a duty_offset > 0 should > get rounded down to 0). Since we're running the same DT, the polarity shouldn't be inverted. I see you have CONFIG_PWM_DEBUG=y enabled, which is most likely the reason the probe fails. With that option, the following check is performed in __pwm_apply: if (IS_ENABLED(CONFIG_PWM_DEBUG)) { struct pwm_waveform wf_rounded; err = __pwm_round_waveform_fromhw(chip, pwm, &wfhw, &wf_rounded); if (err) return err; In this revision of the driver, I have not implemented the read-waveform callbacks, so the Rust PWM abstractions correctly return -ENOTSUPP. Uwe, this poses a problem, as reading from the duty and period registers on the TH1520 SoC's PWM controller appears to be broken. > > Best regards > Uwe Best regards, -- Michal Wilczynski <m.wilczynski@samsung.com>
On Thu, Jun 12, 2025 at 03:27:09PM +0200, Michal Wilczynski wrote: > > > On 6/12/25 07:01, Uwe Kleine-König wrote: > > Hello Drew, > > > > On Wed, Jun 11, 2025 at 04:52:22PM -0700, Drew Fustini wrote: > >> I also enabled the pwm fan driver. However, there is a probe failure: > >> > >> [ 1.250921] pwm-fan pwm-fan: Failed to configure PWM: -524 > >> [ 1.256546] pwm-fan pwm-fan: probe with driver pwm-fan failed with error -524 > > > > 524 = ENOTSUPP, so it seems the request had duty_offset > 0. Does your > > fan use PWM_POLARITY_INVERTED? If so, try without that flag. If your fan > > really needs an inverted PWM this of course makes fan control buggy. > > With the next revision it should work fine (as a duty_offset > 0 should > > get rounded down to 0). > > Since we're running the same DT, the polarity shouldn't be inverted. I > see you have CONFIG_PWM_DEBUG=y enabled, which is most likely the reason > the probe fails. Thanks, I've disabled that options and the probe completes okay. The fan is now spinning :) Drew
On Wed, Jun 11, 2025 at 5:14 PM Michal Wilczynski <m.wilczynski@samsung.com> wrote: > > The kernel config option that is different on my setup is: > CONFIG_RUST_BUILD_ASSERT_ALLOW=y Yeah, code must work with `CONFIG_RUST_BUILD_ASSERT_ALLOW=n` -- the config is an escape hatch just in case a user toolchain cannot build the code for some reason. In other words, if a `build_assert!` is triggered, then that is a bug (likely in new callers misusing an API, but it could also be in the callees, of course). We may eventually remove it, or perhaps invert its meaning so that `allmodconfig` doesn't enable it, which is how I guess you ended up with it, right? I hope that helps. Cheers, Miguel
© 2016 - 2025 Red Hat, Inc.