Thread (107 messages) 107 messages, 11 authors, 2021-06-05

Re: [PATCH v3 0/6] RTL8231 GPIO expander support

From: Andy Shevchenko <hidden>
Date: 2021-05-24 12:55:00
Also in: linux-devicetree, linux-gpio, lkml

On Mon, May 24, 2021 at 2:41 PM Sander Vanheule [off-list ref] wrote:
On Mon, 2021-05-24 at 10:53 +0300, Andy Shevchenko wrote:
quoted
On Mon, May 24, 2021 at 4:11 AM Andrew Lunn [off-list ref] wrote:
...
quoted
quoted
quoted
Changes since v2:
  - MDIO regmap support was merged, so patch is dropped here
Do you have any idea how this will get merged. It sounds like one of
the Maintainers will need a stable branch of regmap.
This is not a problem if Mark provides an immutable branch to pull from.
Mark has a tag (regmap-mdio) for this patch:
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git/tag/?h=regmap-mdio
Also works but you have to provide this information in the cover letter.

...
quoted
quoted
quoted
  - Introduce GPIO regmap quirks to set output direction first
I thought you had determined it was possible to set output before
direction?
Same thoughts when I saw an updated version of that patch. My
anticipation was to not see it at all.
The two devices I've been trying to test the behaviour on are:
 * Netgear GS110TPP: has an RTL8231 with three LEDs, each driven via a pin
   configured as (active-low) GPIO. The LEDs are easy for a quick visual check.
 * Zyxel GS1900-8: RTL8231 used for the front panel button, and an active-low
   GPIO used to hard reset the main SoC (an RTL8380). I've modified this board
   to change some of the strapping pin values, but testing with the jumpers and
   pull-up/down resistors is a bit more tedious.

On the Netgear, I tested the following with and without the quirk:

   # Set as OUT-LOW twice, to avoid the quirk. Always turns the LED on
   gpioset 1 32=0; gpioset 1 32=0
   # Get value to change to input, turns the LED off (high impedance)
   # Will return 1 due to (weak) internal pull-up
   gpioget 1 32
   # Set as OUT-HIGH, should result in LED off
   # When the quirk is disabled, the LED turns on (i.e. old OUT-LOW value)
   # When the quirk is enabled, the LED remains off (i.e. correct OUT-HIGH value)
   gpioset 1 32=1

Now, what's confusing (to me) is that the inverse doesn't depend on the quirk:

   # Set as OUT-HIGH twice
   gpioset 1 32=1; gpioset 1 32=1
   # Change to high-Z
   gpioget 1 32
   # Set to OUT-LOW, always results in LED on, with or without quirk
   gpioset 1 32=0

Any idea why this would be (or appear) broken on the former case, but not on the
latter?
GPIO tools for the shell are context-less. Can you reproduce this with
the legacy sysfs interface?
I was trying to reproduce this behaviour on the Zyxel, but using the strapping
pins that are also used to configure the device's address. So perhaps the pull-
ups/-downs were confusing the results. Using a separate pin on the Zyxel's
RTL8231, I've now been able to confirm the same behaviour as on the Netgear,
including capturing the resulting glitch (with my simple logic analyser) when
enabling the quirk in the first test case.

I hope this explains why I've still included the quirk in this revision. If not,
please let me know what isn't clear.
Do you possess a schematic of either of the devices and a link to the
RTL datasheet (Btw, if it's publicly available, or you have a link
that will ask for necessary sign-in it would be nice to include the
link to it as a Datasheet: tag)?

-- 
With Best Regards,
Andy Shevchenko
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help