linux-kernel - Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state

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: <20181118113034.pguv66idde5idinb@pengutronix.de>
Date:   Sun, 18 Nov 2018 12:30:34 +0100
From:   Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>
To:     Lothar Waßmann <LW@...O-electronics.de>
Cc:     Thierry Reding <thierry.reding@...il.com>,
        Vokáč Michal <Michal.Vokac@...ft.com>,
        Mark Rutland <mark.rutland@....com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-pwm@...r.kernel.org" <linux-pwm@...r.kernel.org>,
        Lukasz Majewski <l.majewski@...ess.pl>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Rob Herring <robh+dt@...nel.org>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        Fabio Estevam <fabio.estevam@....com>,
        Linus Walleij <linus.walleij@...aro.org>
Subject: Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in
 disabled state

Hello Lothar,

On Fri, Nov 16, 2018 at 12:56:33PM +0100, Lothar Waßmann wrote:
> Uwe Kleine-König <u.kleine-koenig@...gutronix.de> wrote:
> > On Fri, Nov 16, 2018 at 10:51:24AM +0100, Thierry Reding wrote:
> > > On Thu, Nov 15, 2018 at 09:37:33PM +0100, Uwe Kleine-König wrote:  
> > > > On Thu, Nov 15, 2018 at 04:25:45PM +0100, Thierry Reding wrote:  
> [...]
> > > But why? The backlight doesn't care about the specific pinmuxing of the
> > > PWM pin. All it cares about is the PWM signal. That's the level of
> > > abstraction that the PWM consumer expects, anything lower level belongs
> > > in the PWM driver.  
> > 
> > The backlight driver cares about the PWM pin muxing because if it's
> > wrongly muxed the backlight doesn't work as intended.
>
> With this argumentation you would also have to define the clocks needed
> for the PWM in the backlight (or whatever pwm consumer) driver, because
> if the clocks are not set up correctly the backlight won't work as
> expected...

The reason why I think it is sensible to put the PWM pin into the
consumer's pinctrl is that only after the consumer grabbed the PWM it is
fixed (in software) what the idle level is. So the pwm alone isn't
complete and it's not clear what to do with this pin. High-Z is probably
a good choice for most setups, but this relies on a PU or PD into the
right direction that isn't always present. (I'm currently working with
such a machine, where such a PD/PU is missing. Not entirely sure this is
a problem because maybe the display unit has a pull. Didn't take the
time yet to verify.) Also this needs some care because the PWM might
already running on purpose (e.g. to show a splash screen) then switching
to High-Z should be avoided.

So IMHO it is sensible to delay setting up the pinmux until the boundary
conditions are fixed. This is also the general idea with the involvement
of pinctrl stuff, but given that even without handling pinctrl specially
it already works just fine when the pwm is only muxed as part of the
consumer.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |