From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: "Florian Fainelli" <f.fainelli@gmail.com>,
"Heiner Kallweit" <hkallweit1@gmail.com>,
netdev@vger.kernel.org,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
"Mylène Josserand" <mylene.josserand@bootlin.com>
Subject: Re: Handling an Extra Signal at PHY Reset
Date: Tue, 19 Feb 2019 16:06:57 +0100 [thread overview]
Message-ID: <5a23b65bb9209cab5616ea06cbbb9c86dcaad1df.camel@bootlin.com> (raw)
In-Reply-To: <20190219133629.GN14879@lunn.ch>
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
next prev parent reply other threads:[~2019-02-19 15:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-19 9:14 Handling an Extra Signal at PHY Reset Paul Kocialkowski
2019-02-19 9:36 ` Thomas Petazzoni
2019-02-19 12:53 ` Paul Kocialkowski
2019-02-19 13:36 ` Andrew Lunn
2019-02-19 15:06 ` Paul Kocialkowski [this message]
2019-02-19 15:40 ` Andrew Lunn
2019-02-20 8:06 ` Thomas Petazzoni
2019-02-19 16:07 ` Florian Fainelli
2019-02-21 9:05 ` Paul Kocialkowski
2019-02-21 1:49 ` Andrew Lunn
2019-02-21 8:50 ` Paul Kocialkowski
2019-02-21 14:04 ` Andrew Lunn
2019-02-27 8:19 ` Paul Kocialkowski
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=5a23b65bb9209cab5616ea06cbbb9c86dcaad1df.camel@bootlin.com \
--to=paul.kocialkowski@bootlin.com \
--cc=andrew@lunn.ch \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=mylene.josserand@bootlin.com \
--cc=netdev@vger.kernel.org \
--cc=thomas.petazzoni@bootlin.com \
/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;
as well as URLs for NNTP newsgroup(s).