linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Walleij <linus.walleij@linaro.org>
To: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: Andrew Lunn <andrew@lunn.ch>, netdev <netdev@vger.kernel.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	"open list:ARM/Amlogic Meson..."
	<linux-amlogic@lists.infradead.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Giuseppe CAVALLARO <peppe.cavallaro@st.com>,
	Alexandre TORGUE <alexandre.torgue@st.com>,
	Jose Abreu <joabreu@synopsys.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	Neil Armstrong <narmstrong@baylibre.com>,
	Kevin Hilman <khilman@baylibre.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC next v1 2/5] gpio: of: parse stmmac PHY reset line specific active-low property
Date: Sun, 9 Jun 2019 23:29:08 +0200	[thread overview]
Message-ID: <CACRpkdZ4n+nCip-uoqbDvQeT0ZpJUfHVnp-D8qCSKfgJEapM7w@mail.gmail.com> (raw)
In-Reply-To: <CAFBinCA1xp5+77DhYMFjX31D3DsaU7d9EqFkWbn+UFFx5LSqEw@mail.gmail.com>

On Sun, Jun 9, 2019 at 11:21 PM Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:

> my understanding that of_gpio_flags_quirks (which I'm touching with
> this patch) is supposed to manage similar quirks to what we have in
> stmmac (it also contains some regulator and MMC quirks too).
> however, that's exactly the reason why I decided to mark this as RFC -
> so I'm eager to hear Linus comments on this

The idea with the quirks in gpiolib-of.c is to make device drivers simpler,
and phase them over to ignoring quirks for mistakes done in the early
days of DT standardization. This feature of the gpiolib API is supposed
to make it "narrow and deep": make the generic case simple
and handle any hardware description languages (DT or ACPI or
board files) and quirks (mostly historical) under the hood. Especially
drivers should not need to worry about polarity inversion instead just
grab a GPIO descriptor and play away with it, asserting it as
1 and deasserting it as 0 whether that is the right polarity or not,
the gpiolib should keep track of polarity no matter how that is described,
even with historical weird bools like "snps,active-low" etc.

So I think you are probably doing the right thing here.
This patch is:
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

  reply	other threads:[~2019-06-09 21:29 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-09 18:06 [RFC next v1 0/5] stmmac: honor the GPIO flags for the PHY reset GPIO Martin Blumenstingl
2019-06-09 18:06 ` [RFC next v1 1/5] net: stmmac: drop redundant check in stmmac_mdio_reset Martin Blumenstingl
2019-06-09 18:06 ` [RFC next v1 2/5] gpio: of: parse stmmac PHY reset line specific active-low property Martin Blumenstingl
2019-06-09 20:38   ` Andrew Lunn
2019-06-09 21:21     ` Martin Blumenstingl
2019-06-09 21:29       ` Linus Walleij [this message]
2019-06-09 18:06 ` [RFC next v1 3/5] net: stmmac: use GPIO descriptors in stmmac_mdio_reset Martin Blumenstingl
2019-06-09 20:52   ` Andrew Lunn
2019-06-09 21:50   ` Linus Walleij
2019-06-09 18:06 ` [RFC next v1 4/5] net: stmmac: use device_property_read_u32_array to read the reset delays Martin Blumenstingl
2019-06-09 18:06 ` [RFC next v1 5/5] arm64: dts: meson: g12a: x96-max: fix the Ethernet PHY reset line Martin Blumenstingl
2019-06-09 21:17   ` Linus Walleij
2019-06-09 21:36     ` Martin Blumenstingl
2019-06-09 22:06       ` Linus Walleij
2019-06-09 22:28         ` Martin Blumenstingl
2019-06-09 20:45 ` [RFC next v1 0/5] stmmac: honor the GPIO flags for the PHY reset GPIO Andrew Lunn
2019-06-09 21:52   ` Linus Walleij
2019-06-09 22:32   ` Martin Blumenstingl
2019-06-10 11:47   ` Maxime Ripard
2019-06-10 12:31     ` Martin Blumenstingl
2019-06-10 13:25       ` Andrew Lunn
2019-06-10 15:52         ` Martin Blumenstingl
2019-06-10 13:51       ` Maxime Ripard
2019-06-10 15:51         ` Martin Blumenstingl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACRpkdZ4n+nCip-uoqbDvQeT0ZpJUfHVnp-D8qCSKfgJEapM7w@mail.gmail.com \
    --to=linus.walleij@linaro.org \
    --cc=alexandre.torgue@st.com \
    --cc=andrew@lunn.ch \
    --cc=bgolaszewski@baylibre.com \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=joabreu@synopsys.com \
    --cc=khilman@baylibre.com \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.blumenstingl@googlemail.com \
    --cc=narmstrong@baylibre.com \
    --cc=netdev@vger.kernel.org \
    --cc=peppe.cavallaro@st.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).