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: <7c1dedaf-9a00-5dc2-e0dc-f94b637380bb@ysoft.com>
Date:   Thu, 22 Nov 2018 14:23:22 +0000
From:   Vokáč Michal <Michal.Vokac@...ft.com>
To:     Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>
CC:     Thierry Reding <thierry.reding@...il.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>,
        Lothar Waßmann <LW@...o-electronics.de>,
        Linus Walleij <linus.walleij@...aro.org>,
        viresh kumar <viresh.kumar@...aro.org>
Subject: Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state

Ahoj Uwe,

On 20.11.2018 17:54, Uwe Kleine-König wrote:
> On Tue, Nov 20, 2018 at 01:14:33PM +0000, Vokáč Michal wrote:
>> On 16.11.2018 10:51, 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:
>>> My impression was that he was trying to find concensus. But the way I
>>> read it he was still arguing that the pinctrl solution was still the
>>> most complete, and would therefore still prefer it.
>>
>> It is like you said Thierry. I am only trying to remain open to test
>> Uwe's ideas. After what I have tested so far I still prefer a imx-specific
>> pinctrl solution.
> 
> Is that because you consider it right to be imx-specific or because
> that's what you already have? Is there a flaw in my explanation that
> the problem isn't imx-specific per se and so the solution shouldn't be
> that either?

I consider it right to be imx-specific because of the current state of
awareness and interest in this problem from other SoC's communities.
I spent quite some time looking for a solution and my impression is that
only imx users perceive this problem and are the only one that already
did some attempts to solve it.

I think this is in line with what Thierry said - if other users have
the same problem, they should speak-up. In my eyes as he is the pwm
subsystem maintainer he knows the best if others have the same problem
or not. My understanding of his arguments is such that they do not.

I understand that having a more generic solution may be better. I am not
really sure if it is valid in this case.

> Is the problem with the "tests so far" that it doesn't work yet, or is
> there something conceptually wrong in your eyes?

It does not work yet. And it would not solve all the cases. Namely the
sysfs use-case. And Thierry confirmed sysfs is a supported interface.

I do not dare to speculate whether your idea is conceptually wrong or
not. I only can say that putting the pinctrl of the PWM pin into the
PWM consumer seems very unnatural to me. I have not seen any example
of such usage yet. That does not mean it is wrong of course.

On the other hand, you said that we are inventing new pinctrl names.
But I see quite a lot of usages of non-["init", "default", "sleep"]
pinctrl names in the DTS files. Most of them are actually imx users.

Still, the main problem is it is not possible to turn-off the backlight
or cooling fan or whoever is the PWM consumer if inverted PWM is used.
Not that it is not possible to keep it turned-off until it is turned-on
by the user. So for me, any solution that at least allows that is better
than the current state. The pinctrl solution just solves all at once.

I fully agree the pinctrl solution has drawbacks. It needs to be well
documented and DT authors need to know how to use it and in what cases.

Best regards,
Michal