Hello Thierry,

On Wed, Sep 30, 2026 at 12:29:42PM +0200, Thierry Reding wrote:
> On Wed, Sep 30, 2026 at 11:54:03AM +0200, Uwe Kleine-König wrote:
> > On Tue, Sep 22, 2026 at 12:07:26PM +0200, Thierry Reding wrote:
> > > On Mon, Sep 21, 2026 at 04:26:03PM +0200, Uwe Kleine-König wrote:
> > > > As long as .apply() also hardcodes TEGRA_PWM_DEPTH, it's IMO fine that
> > > > .get_state() does so, too.
> > > 
> > > Okay, fair enough.
> > 
> > Is that an Ack then?
> 
> I've been thinking about this some more and I don't know if it really
> makes sense to keep hard-coding TEGRA_PWM_DEPTH.

Full ack, ideally this implementation gap would be closed. Compared to
implementing .get_state() I don't feel confident to do that without
testing though. (Though I could make the driver return an error code if
the register setting doesn't match.)

> If only .apply() uses it, then it's mostly fine, I suppose, because we
> don't care what the current (or initial) state is/was. So we either
> don't use the device or we overwrite it with a custom set of values.

I don't agree here. If the TEGRA_PWM_DEPTH setting is different in
hardware than the driver assumes, I'd say .apply() being wrong is worse
than .get_state() being wrong. So I'd either go with .get_state() as it
is now, or rely on someone with hardware to correct the depth setting
first.

Best regards
Uwe