public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Maxime Ripard <maxime.ripard@bootlin.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: devicetree@vger.kernel.org, alexandre.torgue@st.com,
	linux-gpio@vger.kernel.org,
	Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
	netdev@vger.kernel.org, linus.walleij@linaro.org,
	narmstrong@baylibre.com, linux-kernel@vger.kernel.org,
	bgolaszewski@baylibre.com, joabreu@synopsys.com,
	khilman@baylibre.com, peppe.cavallaro@st.com,
	linux-amlogic@lists.infradead.org, davem@davemloft.net,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC next v1 0/5] stmmac: honor the GPIO flags for the PHY reset GPIO
Date: Mon, 10 Jun 2019 13:47:00 +0200	[thread overview]
Message-ID: <20190610114700.tymqzzax334ahtz4@flea> (raw)
In-Reply-To: <20190609204510.GB8247@lunn.ch>


[-- Attachment #1.1: Type: text/plain, Size: 1057 bytes --]

Hi Andrew,

On Sun, Jun 09, 2019 at 10:45:10PM +0200, Andrew Lunn wrote:
> > Patch #1 and #4 are minor cleanups which follow the boyscout rule:
> > "Always leave the campground cleaner than you found it."
>
> > I
> > am also looking for suggestions how to handle these cross-tree changes
> > (patch #2 belongs to the linux-gpio tree, patches #1, 3 and #4 should
> > go through the net-next tree. I will re-send patch #5 separately as
> > this should go through Kevin's linux-amlogic tree).
>
> Patches 1 and 4 don't seem to have and dependencies. So i would
> suggest splitting them out and submitting them to netdev for merging
> independent of the rest.

Jumping on the occasion of that series. These properties have been
defined to deal with phy reset, while it seems that the PHY core can
now handle that pretty easily through generic properties.

Wouldn't it make more sense to just move to that generic properties
that already deals with the flags properly?

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2019-06-10 11:48 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
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 [this message]
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=20190610114700.tymqzzax334ahtz4@flea \
    --to=maxime.ripard@bootlin.com \
    --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=linus.walleij@linaro.org \
    --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