linux-kernel - Re: [PATCH v1 1/1] Documentation: firmware-guide: gpio-properties: Clarify Explicit and Implicit

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:   Mon, 13 Feb 2023 19:39:10 +0100
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     linux-gpio@...r.kernel.org, linux-acpi@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Len Brown <lenb@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <brgl@...ev.pl>
Subject: Re: [PATCH v1 1/1] Documentation: firmware-guide: gpio-properties:
 Clarify Explicit and Implicit

On Mon, Feb 13, 2023 at 2:27 PM Andy Shevchenko
<andriy.shevchenko@...ux.intel.com> wrote:
>
> Clarify the Explicit and Implicit meanings in the table of Pull Bias.
>
> While at it, distinguish pull bias keywords used in ACPI by using bold
> font in the table of the respective terms.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
> ---
>  .../firmware-guide/acpi/gpio-properties.rst   | 25 +++++++++++--------
>  1 file changed, 14 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/firmware-guide/acpi/gpio-properties.rst b/Documentation/firmware-guide/acpi/gpio-properties.rst
> index eaec732cc77c..ae87aa64cb7b 100644
> --- a/Documentation/firmware-guide/acpi/gpio-properties.rst
> +++ b/Documentation/firmware-guide/acpi/gpio-properties.rst
> @@ -67,17 +67,20 @@ state of the output pin which driver should use during its initialization.
>  Linux tries to use common sense here and derives the state from the bias
>  and polarity settings. The table below shows the expectations:
>
> -=========  =============  ==============
> -Pull Bias     Polarity     Requested...
> -=========  =============  ==============
> -Implicit     x            AS IS (assumed firmware configured for us)
> -Explicit     x (no _DSD)  as Pull Bias (Up == High, Down == Low),
> -                          assuming non-active (Polarity = !Pull Bias)
> -Down         Low          as low, assuming active
> -Down         High         as low, assuming non-active
> -Up           Low          as high, assuming non-active
> -Up           High         as high, assuming active
> -=========  =============  ==============
> +=========          =============  ==============
> +Pull Bias             Polarity     Requested...
> +=========          =============  ==============
> +Implicit             x            AS IS (assumed firmware configured it for us)
> +(**Default**)
> +Explicit             x (no _DSD)  as Pull Bias (**Up** == high, **Down** == low),
> +(**Up**, **Down**,                assuming non-active (Polarity = !Pull Bias);
> + **None**)                        or AS IS (assumed firmware configured it for us)
> +                                  with no Pull Bias
> +**Down**             Low          as low, assuming active
> +**Down**             High         as low, assuming non-active
> +**Up**               Low          as high, assuming non-active
> +**Up**               High         as high, assuming active
> +=========          =============  ==============
>
>  That said, for our above example the both GPIOs, since the bias setting
>  is explicit and _DSD is present, will be treated as active with a high
> --

Applied as 6.3 material, thanks!