linux-kernel - Re: [PATCH v2 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] [day] [month] [year] [list]

Message-ID: <CAJZ5v0gTy2UVcoByRdk9LOxyYhAHncHxbeiwHnxGJTLE1Hh=OA@mail.gmail.com>
Date:   Tue, 14 Feb 2023 15:51:47 +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>
Subject: Re: [PATCH v2 1/1] Documentation: firmware-guide: gpio-properties:
 Clarify Explicit and Implicit

On Mon, Feb 13, 2023 at 9:39 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>
> ---
> v2: fixed formatting issues
>  .../firmware-guide/acpi/gpio-properties.rst   | 35 +++++++++++++------
>  1 file changed, 24 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/firmware-guide/acpi/gpio-properties.rst b/Documentation/firmware-guide/acpi/gpio-properties.rst
> index eaec732cc77c..db0c0b1f3700 100644
> --- a/Documentation/firmware-guide/acpi/gpio-properties.rst
> +++ b/Documentation/firmware-guide/acpi/gpio-properties.rst
> @@ -67,17 +67,30 @@ 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                                                                  |
> ++-------------+-------------+-----------------------------------------------+
> +| **Default** | x           | AS IS (assumed firmware configured it for us) |
> ++-------------+-------------+-----------------------------------------------+
> +| Explicit                                                                  |
> ++-------------+-------------+-----------------------------------------------+
> +| **None**    | x           | AS IS (assumed firmware configured it for us) |
> +|             |             | with no Pull Bias                             |
> ++-------------+-------------+-----------------------------------------------+
> +| **Up**      | x (no _DSD) |                                               |
> +|             +-------------+ as high, assuming non-active                  |
> +|             | Low         |                                               |
> +|             +-------------+-----------------------------------------------+
> +|             | High        | as high, assuming active                      |
> ++-------------+-------------+-----------------------------------------------+
> +| **Down**    | x (no _DSD) |                                               |
> +|             +-------------+ as low, assuming non-active                   |
> +|             | High        |                                               |
> +|             +-------------+-----------------------------------------------+
> +|             | Low         | as low, 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!