linux-kernel - Re: [PATCH 2/2] pwm: pca9685: fix prescaler initialization

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: <20170125180510.GA9566@archie.localdomain>
Date:   Wed, 25 Jan 2017 19:05:10 +0100
From:   Clemens Gruber <clemens.gruber@...ruber.com>
To:     Thierry Reding <thierry.reding@...il.com>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        linux-pwm@...r.kernel.org, linux-kernel@...r.kernel.org,
        Florian Vaussard <florian.vaussard@...g-vd.ch>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>
Subject: Re: [PATCH 2/2] pwm: pca9685: fix prescaler initialization

On Fri, Jan 20, 2017 at 07:39:07AM +0100, Thierry Reding wrote:
> On Thu, Jan 19, 2017 at 05:52:10PM +0100, Clemens Gruber wrote:
> > Let's go with this one. I'll spin up a v2 where I calculate the
> > period_ns value from the current prescaler value in the probe function.
> 
> This effectively ends up duplicating much of what the atomic API is
> supposed to be doing.
> 
> So generally before the atomic API there is no way for the PWM driver
> (and consequently the PWM users) to know what the current setting is.
> That implies that we either can't care about the settings that were
> programmed by some bootloader or that we force the PWM to a setting
> on ->probe().
> 
> The result is inconsistent behaviour across drivers, and that's just
> fine for many cases. But for some cases it is really not something that
> we can work with.
> 
> So perhaps another possibility would be for this driver to implement the
> atomic API. This should give you the necessary infrastructure to do
> exactly what you want.

Sounds good. I'll work on that.

One oddity remains though:
The chip has one prescaler, so changing the period of one channel
changes the period of all other channels as well.
If somebody configures different periods for each channel, the last one
wins, but the PWM core still stores the period values the user set
initially. Should we update the period in pwm_state of all pwms in the
chip if the period of one pwm is changed?
Then, when the user calls pwm_get_state, the pwm_state would contain the
correct period?

Thanks,
Clemens