netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
To: Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Heiner Kallweit <hkallweit1@gmail.com>
Cc: netdev@vger.kernel.org,
	"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
	"Mylène Josserand" <mylene.josserand@bootlin.com>
Subject: Handling an Extra Signal at PHY Reset
Date: Tue, 19 Feb 2019 10:14:20 +0100	[thread overview]
Message-ID: <e647050a0fbadb8445cf6a7a5a2ccfbfd0865592.camel@bootlin.com> (raw)

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.

We have a switch for connecting the CONFIG pin to the other pin (LED0),
which needs to be controlled by Linux. The CONFIG pin seems to be used
for a PTP clock the rest of the time.

So we are wondering how to properly represent this case, especially on
the device-tree side.

The trick here is that this step is necessary before the PHY can be
discovered on the MDIO bus (and thus the PHY driver selected) so we
can't rely on the PHY driver to do this. Basically, it looks like we
need to handle this like the reset pin and describe it at the MDIO bus
level.

Here are some ideas for potential solutions:
- Allowing more than a single GPIO to be passed to the MDIO bus' reset-
gpios via device-tree and toggling all the passed GPIOs at once;

- Adding a new optional GPIO for the MDIO bus dedicated to controlling 
switches for such config switching, perhaps called "config-gpios"
(quite a narrow solution);

- Adding a broader power sequence description to the MDIO bus (a bit
like it's done with the mmc pwrseq descriptions) which would allow
specifying the toggle order/delays of various GPIOs (would probably be
the most extensive solution);

- Adding the extra GPIO control to the MAC description and toggling it
through bus->reset (probably the less invasive solution for the core
but not very satisfying from the description perspective, since this is
definitely not MAC-specific).

What do you think about how we could solve this issue?
Do you see other options that I missed here?

Cheers and thanks in advance,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


             reply	other threads:[~2019-02-19  9:14 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-19  9:14 Paul Kocialkowski [this message]
2019-02-19  9:36 ` Handling an Extra Signal at PHY Reset Thomas Petazzoni
2019-02-19 12:53   ` Paul Kocialkowski
2019-02-19 13:36 ` Andrew Lunn
2019-02-19 15:06   ` Paul Kocialkowski
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=e647050a0fbadb8445cf6a7a5a2ccfbfd0865592.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).