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  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]
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

Powered by blists - more mailing lists