[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdYYiHXfUwLnJoANoXLjKdoSbY_YkCQ7Shu5S1JkSNHH7w@mail.gmail.com>
Date: Tue, 2 May 2023 15:50:11 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Michael Walle <michael@...le.cc>
Cc: okan.sahin@...log.com, brgl@...ev.pl, devicetree@...r.kernel.org,
krzysztof.kozlowski+dt@...aro.org, linux-gpio@...r.kernel.org,
linux-kernel@...r.kernel.org, robh+dt@...nel.org
Subject: Re: [PATCH v2 2/2] gpio: ds4520: Add ADI DS4520 GPIO Expander Support
On Tue, May 2, 2023 at 10:44 AM Michael Walle <michael@...le.cc> wrote:
> I'm not sure about the direction though. Technically speaking there is
> no direction register. I'm not familiar with how open drain output are
> modeled in linux. I'd expect the above is enough. Bartosz/Linus/Andy?
Linux has no special concept of open drain/source, it just sees the
.set(), .set_multiple() callbacks in gpio_chip to set the output value(s).
How that happens physically is an electrical question, Linux just expects
it to happen.
.get_direction() is however partly a software concept here, so you might
need to maintain a state in the driver for this. Linux will emulate open
drain when requested by simply putting the line into input (high-impedance)
mode for a high output, but only actively drive it low, which in most cases
is physically the same as open drain.
I imagine the direction would be unknown at probe() and only go into
a definitive input/output state after .set_direction() is called so some
tri-state enum?
.set_config() can be called with the special parameter
PIN_CONFIG_DRIVE_OPEN_DRAIN if the driver on the line can be
put explicitly into open drain state. If the hardware is permanently like
that, there is not much point in implementing it.
Yours,
Linus Walleij
Powered by blists - more mailing lists