[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1a44a737-2b81-625b-8edf-d1c3dfcdd619@cogentembedded.com>
Date: Fri, 13 May 2016 23:56:12 +0300
From: Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Roger Quadros <rogerq@...com>,
Uwe Kleine-König <u.kleine-koenig@...gutronix.de>,
grant.likely@...aro.org, robh+dt@...nel.org,
devicetree@...r.kernel.org, f.fainelli@...il.com,
netdev@...r.kernel.org, frowand.list@...il.com, pawel.moll@....com,
mark.rutland@....com, ijc+devicetree@...lion.org.uk,
galak@...eaurora.org, linux-kernel@...r.kernel.org,
Linus Walleij <linus.walleij@...aro.org>
Subject: 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 resets only.
>
> This actually needs to be addresses a layer above. What you have is a
> bus reset, not a device reset.
No.
There's simply no such thing as a bus reset for the xMII/MDIO busses,
there's simply no reset signaling on them. Every device has its own reset
signal and its own timing requirements.
> So the gpio line is associated to the mdio bus, not a PHY.
No.
> Either your MDIO driver needs to handle the gpio
> line, or in __mdio_register(),
__mdiobus_register(), you mean?
> before it starts looking at the
> children.
It's basically the same thing.
The MDIO bus reset is a misconception.
>
> Andrew
MBR, Sergei
Powered by blists - more mailing lists