linux-kernel - Re: [PATCH v2 1/2] DT: pinctrl: Add binding documentation for Spreadtrum pin controller

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]

Date:   Tue, 20 Jun 2017 11:31:42 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Linus Walleij <linus.walleij@...aro.org>,
        Mark Rutland <mark.rutland@....com>,
        Rob Herring <robh+dt@...nel.org>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Mark Brown <broonie@...nel.org>,
        Baolin Wang <baolin.wang@...aro.org>
Subject: Re: [PATCH v2 1/2] DT: pinctrl: Add binding documentation for
 Spreadtrum pin controller

On Tue, Jun 13, 2017 at 5:15 AM, Baolin Wang <baolin.wang@...eadtrum.com> wrote:

> I forgot one most important reason why we can not use the "sleep" state. As I explained
> above, the sleep related configuration will bind with the pin's sleep mode. If we set the
> pin's sleep mode as AP_SLEEP, then we can select "sleep" state when AP system goes into
> deep sleep mode by issuing "pinctrl_force_sleep()" in pinctrl suspend function.
>
> But if we set the pin's sleep mode as PUBCP_SLEEP and pubcp system doesn't run linux kernel
> (it run another thread OS), then we can not select "sleep" state since the AP system does
> not go into deep sleep mode (AP system run linux kernel OS).

Allright yes it makes sense, and also there are systems that just go into
"hardware sleep" and just put the pin into some pre-programmed mode.

I'm a bit back-and-forth. I didn't mean that some code would actually
switch the state to "sleep" when we go to sleep, I meant that when
the system configures "default" mode it should also look up and
program the "sleep" mode, but this approach with a special property
is just another way of achieveing the same thing.

But then we should add a whole slew of sleep states.

I was thinking whether we could avoid having a special DT property
by parsing ahead to states we do not currently use and programming
that into the sleep mode registers.

Yours,
Linus Walleij