lkml.org 
[lkml]   [2021]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v3 0/6] RTL8231 GPIO expander support
    On Mon, May 24, 2021 at 2:41 PM Sander Vanheule <sander@svanheule.net> wrote:
    > On Mon, 2021-05-24 at 10:53 +0300, Andy Shevchenko wrote:
    > > On Mon, May 24, 2021 at 4:11 AM Andrew Lunn <andrew@lunn.ch> wrote:

    ...

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

    ...

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

    \
     
     \ /
      Last update: 2021-05-24 14:55    [W:4.201 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and my Meterkast|Read the blog