From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: Florian Fainelli <f.fainelli@gmail.com>,
Geert Uytterhoeven <geert+renesas@glider.be>,
"David S . Miller" <davem@davemloft.net>,
Andrew Lunn <andrew@lunn.ch>, Simon Horman <horms@verge.net.au>,
Magnus Damm <magnus.damm@gmail.com>
Cc: Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Nicolas Ferre <nicolas.ferre@microchip.com>,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/4] phylib: Add device reset GPIO support
Date: Sat, 21 Oct 2017 13:03:14 +0300 [thread overview]
Message-ID: <44bc181e-6fd2-4868-3c8d-64e66d9c8d6b@cogentembedded.com> (raw)
In-Reply-To: <2dacbfaf-ce5e-f113-9ae8-641441d99bbc@gmail.com>
Hello!
On 10/20/2017 9:11 PM, Florian Fainelli wrote:
>> From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>
>> The PHY devices sometimes do have their reset signal (maybe even power
>> supply?) tied to some GPIO and sometimes it also does happen that a boot
>> loader does not leave it deasserted. So far this issue has been attacked
>> from (as I believe) a wrong angle: by teaching the MAC driver to manipulate
>> the GPIO in question; that solution, when applied to the device trees, led
>> to adding the PHY reset GPIO properties to the MAC device node, with one
>> exception: Cadence MACB driver which could handle the "reset-gpios" prop
>> in a PHY device subnode. I believe that the correct approach is to teach
>> the 'phylib' to get the MDIO device reset GPIO from the device tree node
>> corresponding to this device -- which this patch is doing...
>>
>> Note that I had to modify the AT803x PHY driver as it would stop working
>> otherwise -- it made use of the reset GPIO for its own purposes...
>>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>> Acked-by: Rob Herring <robh@kernel.org>
>> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
>
> This is a new patch as far as PHYLIB is concerned, so not quite accurate
No, it is not new. No changes in logic since v2.
> anymore. Thanks for picking that up, this looks good, with a few minor
> things here and there.
>> [geert: Propagate actual errors from fwnode_get_named_gpiod()]
>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
[...]
>> diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
>> index 5f93e6add56394f2..15b4560aeb5de759 100644
>> --- a/drivers/net/phy/at803x.c
>> +++ b/drivers/net/phy/at803x.c
>
> You most certainly want to make the conversion of the at803x.c driver as
> a separate patch, there is no reason why it should be folded within the
No, it can't be a separate patch, otherwise I would have posted it
separately. We cannot request the same GPIO 2 times.
> patch teaching PHYLIB about PHY reset through GPIOs. More on that below.
>
[...]
>> @@ -254,22 +253,11 @@ static int at803x_probe(struct phy_device *phydev)
>> {
>> struct device *dev = &phydev->mdio.dev;
>> struct at803x_priv *priv;
>> - struct gpio_desc *gpiod_reset;
>>
>> priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
>> if (!priv)
>> return -ENOMEM;
>>
>> - if (phydev->drv->phy_id != ATH8030_PHY_ID)
>> - goto does_not_require_reset_workaround;
>
> We have lost that bit now, see below.
Hm... I'm still seeing this in net-next.
>> -
>> - gpiod_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
>> - if (IS_ERR(gpiod_reset))
>> - return PTR_ERR(gpiod_reset);
>> -
>> - priv->gpiod_reset = gpiod_reset;
>> -
>> -does_not_require_reset_workaround:
>> phydev->priv = priv;
>>
>> return 0;
>> @@ -343,14 +331,14 @@ static void at803x_link_change_notify(struct phy_device *phydev)
>> * cannot recover from by software.
>> */
>> if (phydev->state == PHY_NOLINK) {
>> - if (priv->gpiod_reset && !priv->phy_reset) {
>> + if (phydev->mdio.reset && !priv->phy_reset) {
>
> and phydev->drv->phy_id == ATH8030_PHY_ID, the workaround is not
> applicable to all PHY devices.
You are clearly looking at an outdated tree -- this check was removed,
This method is populated only for 8030 instead.
[...]
>> diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
>> index 98258583abb0b405..3d044119c032d176 100644
>> --- a/drivers/of/of_mdio.c
>> +++ b/drivers/of/of_mdio.c
[...]
>> @@ -55,10 +56,22 @@ static int of_mdiobus_register_phy(struct mii_bus *mdio,
>> is_c45 = of_device_is_compatible(child,
>> "ethernet-phy-ieee802.3-c45");
>>
>> + /* Deassert the optional reset signal */
>> + gpiod = fwnode_get_named_gpiod(&child->fwnode, "reset-gpios", 0,
>> + GPIOD_OUT_LOW, "PHY reset");
>> + if (PTR_ERR(gpiod) == -ENOENT)
>> + gpiod = NULL;
>> + else if (IS_ERR(gpiod))
>> + return PTR_ERR(gpiod);
>> +
>> if (!is_c45 && !of_get_phy_id(child, &phy_id))
>> phy = phy_device_create(mdio, addr, phy_id, 0, NULL);
>> else
>> phy = get_phy_device(mdio, addr, is_c45);
>> +
>> + /* Assert the reset signal again */
>> + gpiod_set_value(gpiod, 1);
>
> You have a phy_device reference now, so why not call phy_device_reset()
> directly here?
Symmetry, perhaps? (There was a gpiod_set_value(gpiod, 0) call above it...
[...]
>> @@ -112,6 +127,14 @@ static int of_mdiobus_register_device(struct mii_bus *mdio,
>> of_node_get(child);
>> mdiodev->dev.of_node = child;
>>
>> + gpiod = fwnode_get_named_gpiod(&child->fwnode, "reset-gpios", 0,
>> + GPIOD_ASIS, "PHY reset");
>> + if (PTR_ERR(gpiod) == -ENOENT)
>> + gpiod = NULL;
>> + else if (IS_ERR(gpiod))
>> + return PTR_ERR(gpiod);
>> + mdiodev->reset = gpiod;
>
> There is some obvious and non desireable duplication of code between
> "pure" mdio_device and phy_device paths here, can you factor this such
> that there is a common function storing gpiod into a mdio_device's reset
> member in both cases?
>
> Also, there is some asymetry being exposed here, the GPIO descriptor is
> acquired from OF specific code, but is released in the generic MDIO
> device layer, can we find a way to make that symmetrical?
Finally move of_mdio.c into drivers/net/phy/? ;-)
MBR, Sergei
next prev parent reply other threads:[~2017-10-21 10:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-20 8:14 [PATCH v3 0/4] Teach phylib hard-resetting devices Geert Uytterhoeven
2017-10-20 8:14 ` [PATCH v3 1/4] phylib: Add device reset GPIO support Geert Uytterhoeven
2017-10-20 10:56 ` Sergei Shtylyov
2017-10-20 18:11 ` Florian Fainelli
2017-10-21 10:03 ` Sergei Shtylyov [this message]
2017-10-21 10:08 ` Geert Uytterhoeven
2017-10-20 8:14 ` [PATCH v3 2/4] macb: Kill PHY reset code Geert Uytterhoeven
2017-10-20 18:04 ` Florian Fainelli
2017-10-20 8:14 ` [PATCH v3 3/4] arm64: dts: renesas: salvator-common: Add EthernetAVB PHY reset Geert Uytterhoeven
2017-10-20 8:14 ` [PATCH v3 4/4] arm64: dts: renesas: ulcb: " Geert Uytterhoeven
2017-10-20 9:05 ` [PATCH v3 0/4] Teach phylib hard-resetting devices Simon Horman
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=44bc181e-6fd2-4868-3c8d-64e66d9c8d6b@cogentembedded.com \
--to=sergei.shtylyov@cogentembedded.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=f.fainelli@gmail.com \
--cc=geert+renesas@glider.be \
--cc=horms@verge.net.au \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=mark.rutland@arm.com \
--cc=netdev@vger.kernel.org \
--cc=nicolas.ferre@microchip.com \
--cc=robh+dt@kernel.org \
/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
all inboxes | Powered by JetHome®