linux-kernel - Re: [PATCH v5 2/7] pwm: pca9685: Support hardware readout

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHp75VfedZyFF46koLOg13t_TzMbwj5zBYU2zBA52vRRtb202g@mail.gmail.com>
Date:   Mon, 22 Mar 2021 13:40:57 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>
Cc:     Thierry Reding <thierry.reding@...il.com>,
        Clemens Gruber <clemens.gruber@...ruber.com>,
        Sven Van Asbroeck <thesven73@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "linux-pwm@...r.kernel.org" <linux-pwm@...r.kernel.org>
Subject: Re: [PATCH v5 2/7] pwm: pca9685: Support hardware readout

On Mon, Mar 22, 2021 at 1:22 PM Uwe Kleine-König
<u.kleine-koenig@...gutronix.de> wrote:
> On Mon, Mar 22, 2021 at 11:38:40AM +0200, Andy Shevchenko wrote:
> > On Monday, March 22, 2021, Thierry Reding <thierry.reding@...il.com> wrote:
> > > On Fri, Jan 29, 2021 at 09:37:47PM +0100, Clemens Gruber wrote:
> > > > Thierry: Would you accept it if we continue to reset the registers in
> > > > .probe?
> > >
> > > Yes, I think it's fine to continue to reset the registers since that's
> > > basically what the driver already does. It'd be great if you could
> > > follow up with a patch that removes the reset and leaves the hardware in
> > > whatever state the bootloader has set up. Then we can take that patch
> > > for a ride and see if there are any complains about it breaking. If
> > > there are we can always try to fix them, but as a last resort we can
> > > also revert, which then may be something we have to live with. But I
> > > think we should at least try to make this consistent with how other
> > > drivers do this so that people don't stumble over this particular
> > > driver's
> >
> > I guess we may miss (a PCB / silicon design flaw or warm boot case) when
> > boot loader left device completely untouched and device either in wrong
> > state because if failed reset (saw this on PCA9555 which has a
> > corresponding errata), or simply we have done a warm reset of the system.
> > So, we also have to understand how to properly exit.
>
> I don't think that not resetting is a real problem. My argumentation
> goes as follows:
>
> When the PWM driver is loaded and the PWM configuration is invalid, it
> was already invalid for the time between power up (or warm start) and
> PWM driver load time. Then it doesn't really hurt to keep the PWM
> in this invalid state for a little moment longer until the consumer of
> the PWM becomes active.

But this won't work in the cases when we have a chip with a shared
settings for period and/or duty cycle. You will never have a user come
due to -EBUSY.

> Together with the use cases where not resetting is the right thing to
> do, I'm convinced not resetting is the better strategy.

I'm on the opposite side, although I know the cases that resetting
maybe harmful (to some extent).
We definitely need a hint if we may or may not touch 1 or more
channels of a given PWM.

> > Another point, CCF has a bit “is critical”, and u guess PWM may get the
> > same and make the all assumptions much easier.
>
> So I think complicating the PWM framework for this isn't the right thing
> to do.

Again, I'm on opposite side here b/c see above.

-- 
With Best Regards,
Andy Shevchenko