linux-kernel - Re: [PATCH v2 2/7] pwm: Add Rust driver for T-HEAD TH1520 SoC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <b1c7c305-fad9-4161-b627-b5c1db9cb0ee@samsung.com>
Date: Tue, 17 Jun 2025 13:55:55 +0200
From: Michal Wilczynski <m.wilczynski@...sung.com>
To: Uwe Kleine-König <ukleinek@...nel.org>
Cc: Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>,
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, Andreas
	Hindborg <a.hindborg@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>, Trevor
	Gross <tmgross@...ch.edu>, Danilo Krummrich <dakr@...nel.org>, Drew Fustini
	<drew@...7.com>, Guo Ren <guoren@...nel.org>, Fu Wei <wefu@...hat.com>, Rob
	Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor
	Dooley <conor+dt@...nel.org>, Paul Walmsley <paul.walmsley@...ive.com>,
	Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>,
	Alexandre Ghiti <alex@...ti.fr>, Marek Szyprowski
	<m.szyprowski@...sung.com>, Benno Lossin <lossin@...nel.org>, Michael
	Turquette <mturquette@...libre.com>, Stephen Boyd <sboyd@...nel.org>,
	linux-kernel@...r.kernel.org, linux-pwm@...r.kernel.org,
	rust-for-linux@...r.kernel.org, linux-riscv@...ts.infradead.org,
	devicetree@...r.kernel.org, linux-clk@...r.kernel.org
Subject: Re: [PATCH v2 2/7] pwm: Add Rust driver for T-HEAD TH1520 SoC



On 6/12/25 22:36, Uwe Kleine-König wrote:
> Hello Michael,
> 
> On Thu, Jun 12, 2025 at 10:14:13AM +0200, Michal Wilczynski wrote:
>> On 6/11/25 08:58, Uwe Kleine-König wrote:
>>> Huh, if you do the newstyle stuff, .get_state() is wrong. It's either
>>> .round_waveform_tohw() + .round_waveform_fromhw() + .read_waveform() +
>>> .write_waveform() or .apply() + .get_state(), but don't mix these.
>>
>> In the process of implementing the full "newstyle" waveform API as you
>> suggested, I discovered a hardware limitation. After writing new values
>> to the period and duty cycle registers, reading them back does not
>> return the programmed values, which makes it impossible to reliably
>> report the current hardware state.
>>
>> This appears to be a known quirk of the hardware, as the reference C
>> driver from T-HEAD [1] also omits the .get_state callback, likely for
>> the same reason.
> 
> Do you read complete non-sense or e.g. the old configuration until
> the current period ends?
> 
> I guess would be that .get_state wasn't implemented because this is an
> oldoldstyle driver and it works also without that function.

Hi Uwe,

My apologies for the confusion. After further testing, it appears I was
mistaken, and the hardware reads are working correctly. I must have made
an error when testing via sysfs.

I'll be submitting a v3 that implements the full round_waveform_tohw(),
round_waveform_fromhw(), read_waveform(), and write_waveform()
combination as you initially suggested.

> 
>> Given this, would it be acceptable to provide a write-only driver? My
>> proposed solution would be to omit the .read_waveform() and
>> .round_waveform_fromhw() implementations from my PwmOps trait. This
> 
> Please don't skip .round_waveform_fromhw(), that one is needed for
> pwm_round_waveform_might_sleep().
> 
> I don't like it, but given that the hardware doesn't play along there is
> no alternative.
> 
>> would mean the driver can correctly set the PWM state, but attempting to
>> read it back via sysfs would fail (e.g., with -EOPNOTSUPP), reflecting
>> the hardware's capability.
> 
> I think there might be another patch opportunity then to make PWM_DEBUG
> work with that.
> 
> Best regards
> Uwe

Best regards,
-- 
Michal Wilczynski <m.wilczynski@...sung.com>