[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5a23b65bb9209cab5616ea06cbbb9c86dcaad1df.camel@bootlin.com>
Date: Tue, 19 Feb 2019 16:06:57 +0100
From: Paul Kocialkowski <paul.kocialkowski@...tlin.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Florian Fainelli <f.fainelli@...il.com>,
Heiner Kallweit <hkallweit1@...il.com>, netdev@...r.kernel.org,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
Mylène Josserand
<mylene.josserand@...tlin.com>
Subject: Re: Handling an Extra Signal at PHY Reset
Hi Andrew,
On Tue, 2019-02-19 at 14:36 +0100, Andrew Lunn wrote:
> On Tue, Feb 19, 2019 at 10:14:20AM +0100, Paul Kocialkowski wrote:
> > Hi,
> >
> > We are dealing with an Ethernet PHY (Marvell 88E1512) that comes with a
> > CONFIG pin that must be connected to one of the other pins of the PHY
> > to configure the LSB of the PHY address as well as I/O voltages (see
> > section 2.18.1 Hardware Configuration of the datasheet). It must be
> > connected "soon after reset" for the PHY to be correctly configured.
>
> Hi Paul
>
> I assume there are two PHYs on the MDIO bus, and you need to ensure
> they have different addresses? Do we have an Ethernet switch involved
> here, or are they two SoC Ethernet networks with one shared MDIO bus?
Thanks for your answer!
I think the reason why we need to deal with the CONFIG pin is more
about setting the correct I/O voltage than the PHY address (it just
happens that the CONFIG pin configures both at once).
With our setup, we only have a single PHY and no fancy eth switch setup
(although there is a GMII2RGMII converter that is controlled through
the MDIO bus, but there is no risk of address conflict).
> This seems like an odd design. I've normally seen weak pull up/down
> resistors, not a switch, so i'm wondering why it is designed like
> this.
Yes, that's definitely unusual and pretty specific to the PHY. I would
also have expected pull resistors but the way it's done is to connect
one pin to another at reset and disconnect them later on so that both
can be used for the intended function (PTP clock and LED).
I hope this clarifies our situation a bit.
Cheers,
Paul
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
Powered by blists - more mailing lists