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 mdio_device_rese
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 (
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);
>
> Be
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 nee
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 mdio_pro
> >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
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
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
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
> >>
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
individual
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 regi
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 device
Hello.
On 05/13/2016 07:06 AM, Andrew Lunn wrote:
+ gpiod = fwnode_get_named_gpiod(&child->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, a
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 resets
> >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
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);
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
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
> http://patchwork.ozlabs.org/patch
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
> >>===
> >>--- net-next.orig/drivers/net/phy/mdio_devi
> >>+ gpiod = fwnode_get_named_gpiod(&child->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 al
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 Linus
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 you/
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 deasse
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 w
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 wrong
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
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 GP
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. S
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:
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 (as
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 G
31 matches
Mail list logo
