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-next>] [day] [month] [year] [list]
Message-Id: <20230213132812.38646-1-andriy.shevchenko@linux.intel.com>
Date:   Mon, 13 Feb 2023 15:28:12 +0200
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        linux-gpio@...r.kernel.org, linux-acpi@...r.kernel.org,
        linux-kernel@...r.kernel.org
Cc:     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: [PATCH v1 1/1] Documentation: firmware-guide: gpio-properties: Clarify Explicit and Implicit

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
-- 
2.39.1

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ