[PATCH v10 0/7] Rust Abstractions for PWM subsystem with TH1520 PWM driver
Michal Wilczynski
m.wilczynski at samsung.com
Thu Jul 10 03:29:59 PDT 2025
On 7/10/25 12:17, Danilo Krummrich wrote:
> On Thu Jul 10, 2025 at 10:42 AM CEST, Michal Wilczynski wrote:
>> I was hoping you could clarify the intended merge path for this series,
>> as it introduces changes to both the Rust and PWM subsystems.
>>
>> Is the expectation that the Rust maintainers will take the abstraction
>> patches into the Rust tree first? Or would Uwe, as the PWM maintainer,
>> pull the entire series? Any guidance on the coordination would be very
>> helpful.
>
> Except for the helpers I only see PWM code, so this is fully on Uwe's purview I
> think.
>
> I see that there is a new MAINTAINERS entry:
>
> PWM SUBSYSTEM BINDINGS [RUST]
> M: Michal Wilczynski <m.wilczynski at samsung.com>
> S: Maintained
> F: rust/helpers/pwm.c
> F: rust/kernel/pwm.rs
>
> I assume this is agreed with Uwe?
>
> In case there's no agreement yet, the typical options are:
>
> 1) Maintain the Rust abstractions as part of the existing MAINTAINERS entry.
> Optionally, the author can be added as another maintainer or reviewer.
>
> 2) Add a separate MAINTAINERS entry; patches / PRs still go through the same
> subsystem tree.
>
> 3) Add a separate MAINTAINERS entry; patches don't go through the subsystem
> tree (e.g. because the subsystem maintainers don't want to deal with it).
>
> I don't recommend (3), since it's really just a fallback.
>
> The above looks like (2). In this case I recommend to also add the C maintainers
> as reviewers, such that they can easily follow along and specifiy the tree (T:).
>
> But, of course, that's up to you and Uwe.
Thanks, it is not agreed yet, I've included a MAINTAINERS entry, since I
would like to help with the maintenance of the code, so I would also
vote for the 2) option, but ultimately it's an Uwe decision so I would
be happy to follow on anything he decides.
>
>> I understand that it may be too late in the development cycle to merge
>> the full series. If that's the case, perhaps patch 2 could be considered
>> on its own, as it hasn't received comments in the last couple of
>> revisions. As another possibility, patch 1 and patch 3 are dependent on
>> each other and could be applied as a pair, depending on your assessment.
>>
>> The RISC-V driver itself would need to wait for the IoMem series merge [1].
>>
>> [1] - https://lore.kernel.org/rust-for-linux/20250704-topics-tyr-platform_iomem-v12-0-1d3d4bd8207d@collabora.com/
>>
>> Best regards,
>
>
Best regards,
--
Michal Wilczynski <m.wilczynski at samsung.com>
More information about the linux-riscv
mailing list