Message-ID: <63081142960215d2d7c0d2de0b1d33e31f8c5e0d.camel@bootlin.com>
Date:   Thu, 21 Feb 2019 10:05:12 +0100
From:   Paul Kocialkowski <paul.kocialkowski@...tlin.com>
To:     Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>
Cc:     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 Florian,

On Tue, 2019-02-19 at 08:07 -0800, Florian Fainelli wrote:
> 
> On February 19, 2019 1:14:20 AM PST, Paul Kocialkowski <paul.kocialkowski@...tlin.com> 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.
> 
> Even voltage? What guarantees do you have that you are not reducing
> the lifetime of your pads if e.g.: you are configured for 3.3V while
> the other end is 1.8/2.5V? Is there some kind of embedded voltage
> comparator that can be used to help making the right decision?

I'm really not sure about that. We know from the hardware design that
we need 1.8V/2.5V.

Unlike what I stated previously, the two pins are actually connected
when the controlling GPIO is open-drain and what we really need to do
is to disconnect them after reset so that both pins can be used for
their individual functions. But we can't be sure that they were not
already disconnected before by e.g. U-Boot, so we should also make sure
they are connected before issuing reset.

> > 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;
> 
> That would be a mis-representstion of the HW though, since the reset
> line is tied to the PHY package. Making use of the current
> implementation details to put a second reset line does not sound
> great.

Agreed, this is quite a far-fetched solution and in the end, what we
are controlling is not a reset line.

> > - 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);
> 
> Indeed, and still has the same design flaw as 1) outline above.
> 
> > - 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);
> 
> That one looks the most compelling and future proof although I do
> wonder how many people would make use of that.

About that one, it turns out that what we need to do has little to do
with power sequencing and more to do with configuration at reset time,
so it doesn't feel like a great fit either.

> > - 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?
> 
> You could explore having the MDIO bus layer scan its children nodes
> (PHY nodes) and handle properties in there before registering
> devices, so for insurance your PHY DT nodes can have an arbitrary
> number of reset lines, power sequencing properties etc. and the MDIO
> bus layer knowing it's internal implementation does make sure that it
> makes use of these properties in order to make PHY devices
> functional.
> 
> Does that make sense? One possible caveat is that the CONFIG pin also
> dictates the address on the bus, so what do we do with the PHY's
> "reg" property, is it it's actual address or is it the desired one
> that we should configure through reset?

That sounds like a good option to me as it would allow keeping the
property on the PHY node. I think having a "config-gpios" property on
the PHY node would work. Then the MDIO core can just walk the children
nodes, set this GPIO before reset, issue PHY reset and then unset the
GPIO.

Maybe we could also allow having the reset-gpios property on the PHY
node? As far as I understand, this property on the MDIO bus was
described as a bus-wide reset, but it seems to be used for PHY reset
instead most of the time (which is not really an accurate description
of the hardware).

I think we should keep the PHY's configured address in the description,
since the PHY will not change its address, but use the one set by the
CONFIG pin from reset.

Cheers,

Paul

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

Powered by blists - more mailing lists