Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On Thu, May 26, 2016 at 9:00 PM, Uwe Kleine-König wrote: > On Thu, May 26, 2016 at 11:00:55AM +0200, Linus Walleij wrote: >> On Thu, May 12, 2016 at 8:42 PM, Uwe Kleine-König >> wrote: >> >> > [added Linus Walleij to Cc, there is a

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On Thu, May 26, 2016 at 9:00 PM, Uwe Kleine-König wrote: > On Thu, May 26, 2016 at 11:00:55AM +0200, Linus Walleij wrote: >> On Thu, May 12, 2016 at 8:42 PM, Uwe Kleine-König >> wrote: >> >> > [added Linus Walleij to Cc, there is a question for you/him below] >> (...) >> >> +void

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On Thu, May 26, 2016 at 11:00:55AM +0200, Linus Walleij wrote: > On Thu, May 12, 2016 at 8:42 PM, Uwe Kleine-König > wrote: > > > [added Linus Walleij to Cc, there is a question for you/him below] > (...) > >> +void mdio_device_reset(struct mdio_device *mdiodev,

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On Thu, May 26, 2016 at 11:00:55AM +0200, Linus Walleij wrote: > On Thu, May 12, 2016 at 8:42 PM, Uwe Kleine-König > wrote: > > > [added Linus Walleij to Cc, there is a question for you/him below] > (...) > >> +void mdio_device_reset(struct mdio_device *mdiodev, int value) > >> +{ > >> + if

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On Thu, May 12, 2016 at 8:42 PM, Uwe Kleine-König wrote: > [added Linus Walleij to Cc, there is a question for you/him below] (...) >> +void mdio_device_reset(struct mdio_device *mdiodev, int value) >> +{ >> + if (mdiodev->reset) >> +

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On Thu, May 12, 2016 at 8:42 PM, Uwe Kleine-König wrote: > [added Linus Walleij to Cc, there is a question for you/him below] (...) >> +void mdio_device_reset(struct mdio_device *mdiodev, int value) >> +{ >> + if (mdiodev->reset) >> + gpiod_set_value(mdiodev->reset, value); > >

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello. On 5/15/2016 6:23 PM, Andrew Lunn wrote: I think there could be similar code one layer above to handle one gpio line for multiple phys. Ah, you want me to recognize some MAC/MDIO bound prop (e.g. "mdio-reset-gpios") in of_mdiobus_register()? I'll think about it now that my patch

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello. On 5/15/2016 6:23 PM, Andrew Lunn wrote: I think there could be similar code one layer above to handle one gpio line for multiple phys. Ah, you want me to recognize some MAC/MDIO bound prop (e.g. "mdio-reset-gpios") in of_mdiobus_register()? I'll think about it now that my patch

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On 13/05/16 22:36, Sergei Shtylyov wrote: > Hello. > > On 05/13/2016 12:07 PM, Roger Quadros wrote: > > [...] > +} +EXPORT_SYMBOL(mdio_device_reset); + /** * mdio_probe - probe an MDIO device * @dev: device to probe @@ -117,9 +126,16 @@ static int

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On 13/05/16 22:36, Sergei Shtylyov wrote: > Hello. > > On 05/13/2016 12:07 PM, Roger Quadros wrote: > > [...] > +} +EXPORT_SYMBOL(mdio_device_reset); + /** * mdio_probe - probe an MDIO device * @dev: device to probe @@ -117,9 +126,16 @@ static int

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

> >I think there could be similar code one layer above to handle one gpio > >line for multiple phys. > >Ah, you want me to recognize some MAC/MDIO bound prop (e.g. > "mdio-reset-gpios") in of_mdiobus_register()? I'll think about it > now that my patch needs fixing anyway... Hi Sergi It does

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

> >I think there could be similar code one layer above to handle one gpio > >line for multiple phys. > >Ah, you want me to recognize some MAC/MDIO bound prop (e.g. > "mdio-reset-gpios") in of_mdiobus_register()? I'll think about it > now that my patch needs fixing anyway... Hi Sergi It does

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello. On 05/14/2016 10:50 PM, Andrew Lunn wrote: Another issue is that on some boards we have one reset line tied to multiple PHYs.How do we prevent multiple resets being taking place when each of the PHYs are registered? My patch just doesn't address this case -- it's about the individual

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello. On 05/14/2016 10:50 PM, Andrew Lunn wrote: Another issue is that on some boards we have one reset line tied to multiple PHYs.How do we prevent multiple resets being taking place when each of the PHYs are registered? My patch just doesn't address this case -- it's about the individual

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello. On 05/13/2016 10:18 PM, Sergei Shtylyov wrote: [we already talked about this patch in #armlinux, I'm now just forwarding my comments on the list. Background was that I sent an easier and less complete patch with the same idea. See http://patchwork.ozlabs.org/patch/621418/] [added Linus

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello. On 05/13/2016 10:18 PM, Sergei Shtylyov wrote: [we already talked about this patch in #armlinux, I'm now just forwarding my comments on the list. Background was that I sent an easier and less complete patch with the same idea. See http://patchwork.ozlabs.org/patch/621418/] [added Linus

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On Sat, May 14, 2016 at 10:36:38PM +0300, Sergei Shtylyov wrote: > Hello. > > On 05/14/2016 02:44 AM, Andrew Lunn wrote: > > >Another issue is that on some boards we have one reset line tied to > >multiple PHYs.How do we prevent multiple resets being taking place when > >each of >

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On Sat, May 14, 2016 at 10:36:38PM +0300, Sergei Shtylyov wrote: > Hello. > > On 05/14/2016 02:44 AM, Andrew Lunn wrote: > > >Another issue is that on some boards we have one reset line tied to > >multiple PHYs.How do we prevent multiple resets being taking place when > >each of >

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello. On 05/14/2016 02:44 AM, Andrew Lunn wrote: Another issue is that on some boards we have one reset line tied to multiple PHYs.How do we prevent multiple resets being taking place when each of the PHYs are registered? My patch just doesn't address this case -- it's about the

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello. On 05/14/2016 02:44 AM, Andrew Lunn wrote: Another issue is that on some boards we have one reset line tied to multiple PHYs.How do we prevent multiple resets being taking place when each of the PHYs are registered? My patch just doesn't address this case -- it's about the

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On Fri, May 13, 2016 at 11:56:12PM +0300, Sergei Shtylyov wrote: > On 05/13/2016 11:44 PM, Andrew Lunn wrote: > > >>>Another issue is that on some boards we have one reset line tied to > >>>multiple PHYs.How do we prevent multiple resets being taking place when > >>>each of > >>>the PHYs are

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On Fri, May 13, 2016 at 11:56:12PM +0300, Sergei Shtylyov wrote: > On 05/13/2016 11:44 PM, Andrew Lunn wrote: > > >>>Another issue is that on some boards we have one reset line tied to > >>>multiple PHYs.How do we prevent multiple resets being taking place when > >>>each of > >>>the PHYs are

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello. On 05/13/2016 10:06 AM, Uwe Kleine-König wrote: [...] Index: net-next/drivers/of/of_mdio.c === --- net-next.orig/drivers/of/of_mdio.c +++ net-next/drivers/of/of_mdio.c @@ -44,6 +44,7 @@ static int of_get_phy_id(struct

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello. On 05/13/2016 10:06 AM, Uwe Kleine-König wrote: [...] Index: net-next/drivers/of/of_mdio.c === --- net-next.orig/drivers/of/of_mdio.c +++ net-next/drivers/of/of_mdio.c @@ -44,6 +44,7 @@ static int of_get_phy_id(struct

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello. On 05/13/2016 07:06 AM, Andrew Lunn wrote: + gpiod = fwnode_get_named_gpiod(>fwnode, "reset-gpios"); + /* Deassert the reset signal */ + if (!IS_ERR(gpiod)) + gpiod_direction_output(gpiod, 0); This is wrong I think. You must only ignore -ENODEV, all

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello. On 05/13/2016 07:06 AM, Andrew Lunn wrote: + gpiod = fwnode_get_named_gpiod(>fwnode, "reset-gpios"); + /* Deassert the reset signal */ + if (!IS_ERR(gpiod)) + gpiod_direction_output(gpiod, 0); This is wrong I think. You must only ignore -ENODEV, all

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On 05/13/2016 11:44 PM, Andrew Lunn wrote: Another issue is that on some boards we have one reset line tied to multiple PHYs.How do we prevent multiple resets being taking place when each of the PHYs are registered? My patch just doesn't address this case -- it's about the individual

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On 05/13/2016 11:44 PM, Andrew Lunn wrote: Another issue is that on some boards we have one reset line tied to multiple PHYs.How do we prevent multiple resets being taking place when each of the PHYs are registered? My patch just doesn't address this case -- it's about the individual

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

> >Another issue is that on some boards we have one reset line tied to > >multiple PHYs.How do we prevent multiple resets being taking place when each > >of > >the PHYs are registered? > >My patch just doesn't address this case -- it's about the > individual resets only. This actually needs

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

> >Another issue is that on some boards we have one reset line tied to > >multiple PHYs.How do we prevent multiple resets being taking place when each > >of > >the PHYs are registered? > >My patch just doesn't address this case -- it's about the > individual resets only. This actually needs

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello. On 05/13/2016 12:07 PM, Roger Quadros wrote: [...] +} +EXPORT_SYMBOL(mdio_device_reset); + /** * mdio_probe - probe an MDIO device * @dev: device to probe @@ -117,9 +126,16 @@ static int mdio_probe(struct device *dev struct mdio_driver *mdiodrv = to_mdio_driver(drv);

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello. On 05/13/2016 12:07 PM, Roger Quadros wrote: [...] +} +EXPORT_SYMBOL(mdio_device_reset); + /** * mdio_probe - probe an MDIO device * @dev: device to probe @@ -117,9 +126,16 @@ static int mdio_probe(struct device *dev struct mdio_driver *mdiodrv = to_mdio_driver(drv);

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello. On 05/13/2016 12:35 AM, Sergei Shtylyov wrote: [we already talked about this patch in #armlinux, I'm now just forwarding my comments on the list. Background was that I sent an easier and less complete patch with the same idea. See http://patchwork.ozlabs.org/patch/621418/] [added Linus

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello. On 05/13/2016 12:35 AM, Sergei Shtylyov wrote: [we already talked about this patch in #armlinux, I'm now just forwarding my comments on the list. Background was that I sent an easier and less complete patch with the same idea. See http://patchwork.ozlabs.org/patch/621418/] [added Linus

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hi Sergei, On 12/05/16 21:42, Uwe Kleine-König wrote: > Hello Sergei, > > [we already talked about this patch in #armlinux, I'm now just > forwarding my comments on the list. Background was that I sent an easier > and less complete patch with the same idea. See >

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hi Sergei, On 12/05/16 21:42, Uwe Kleine-König wrote: > Hello Sergei, > > [we already talked about this patch in #armlinux, I'm now just > forwarding my comments on the list. Background was that I sent an easier > and less complete patch with the same idea. See >

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello Sergei, On Fri, May 13, 2016 at 12:35:50AM +0300, Sergei Shtylyov wrote: > On 05/12/2016 09:42 PM, Uwe Kleine-König wrote: > >>Index: net-next/drivers/net/phy/mdio_device.c > >>=== > >>---

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello Sergei, On Fri, May 13, 2016 at 12:35:50AM +0300, Sergei Shtylyov wrote: > On 05/12/2016 09:42 PM, Uwe Kleine-König wrote: > >>Index: net-next/drivers/net/phy/mdio_device.c > >>=== > >>---

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

> >>+ gpiod = fwnode_get_named_gpiod(>fwnode, "reset-gpios"); > >>+ /* Deassert the reset signal */ > >>+ if (!IS_ERR(gpiod)) > >>+ gpiod_direction_output(gpiod, 0); > > > >This is wrong I think. You must only ignore -ENODEV, all other error > >At least -ENOSYS should also be

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

> >>+ gpiod = fwnode_get_named_gpiod(>fwnode, "reset-gpios"); > >>+ /* Deassert the reset signal */ > >>+ if (!IS_ERR(gpiod)) > >>+ gpiod_direction_output(gpiod, 0); > > > >This is wrong I think. You must only ignore -ENODEV, all other error > >At least -ENOSYS should also be

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello. On 05/12/2016 09:42 PM, Uwe Kleine-König wrote: [we already talked about this patch in #armlinux, I'm now just forwarding my comments on the list. Background was that I sent an easier and less complete patch with the same idea. See http://patchwork.ozlabs.org/patch/621418/] [added

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello. On 05/12/2016 09:42 PM, Uwe Kleine-König wrote: [we already talked about this patch in #armlinux, I'm now just forwarding my comments on the list. Background was that I sent an easier and less complete patch with the same idea. See http://patchwork.ozlabs.org/patch/621418/] [added

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello Sergei, [we already talked about this patch in #armlinux, I'm now just forwarding my comments on the list. Background was that I sent an easier and less complete patch with the same idea. See http://patchwork.ozlabs.org/patch/621418/] [added Linus Walleij to Cc, there is a question for

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello Sergei, [we already talked about this patch in #armlinux, I'm now just forwarding my comments on the list. Background was that I sent an easier and less complete patch with the same idea. See http://patchwork.ozlabs.org/patch/621418/] [added Linus Walleij to Cc, there is a question for

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On 05/10/2016 12:11 PM, Sergei Shtylyov wrote: > Hello. > > On 05/10/2016 09:32 PM, Florian Fainelli wrote: > >>> 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

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On 05/10/2016 12:11 PM, Sergei Shtylyov wrote: > Hello. > > On 05/10/2016 09:32 PM, Florian Fainelli wrote: > >>> 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

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello. On 05/10/2016 09:32 PM, Florian Fainelli wrote: 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

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

Hello. On 05/10/2016 09:32 PM, Florian Fainelli wrote: 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

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On 04/28/2016 03:12 PM, Sergei Shtylyov wrote: > 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

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On 04/28/2016 03:12 PM, Sergei Shtylyov wrote: > 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

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On Fri, Apr 29, 2016 at 01:12:54AM +0300, Sergei Shtylyov wrote: > 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

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On Fri, Apr 29, 2016 at 01:12:54AM +0300, Sergei Shtylyov wrote: > 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

[PATCH RFT 1/2] phylib: add device reset GPIO support

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

[PATCH RFT 1/2] phylib: add device reset GPIO support

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

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On Mon, Apr 11, 2016 at 2:28 PM, Sergei Shtylyov wrote: > On 04/11/2016 10:25 PM, Rob Herring wrote: > >>> 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 >>>

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On Mon, Apr 11, 2016 at 2:28 PM, Sergei Shtylyov wrote: > On 04/11/2016 10:25 PM, Rob Herring wrote: > >>> 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.

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On 04/11/2016 10:25 PM, Rob Herring wrote: 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:

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On 04/11/2016 10:25 PM, Rob Herring wrote: 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:

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On Sat, Apr 09, 2016 at 01:22:47AM +0300, Sergei Shtylyov wrote: > 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

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On Sat, Apr 09, 2016 at 01:22:47AM +0300, Sergei Shtylyov wrote: > 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

[PATCH RFT 1/2] phylib: add device reset GPIO support

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

[PATCH RFT 1/2] phylib: add device reset GPIO support

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