[lkml]   [2020]   [Mar]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: user space interface for configuring T1 PHY management mode (master/slave)
On Wed, 25 Mar 2020 10:11:12 +0000
Russell King - ARM Linux admin <> wrote:

> On Wed, Mar 25, 2020 at 09:34:49AM +0100, Oleksij Rempel wrote:
> > Hi all,
> >
> > I'm working on mainlining of NXP1102 PHY (BroadR Reach/802.3bw) support.
> >
> > Basic functionality is working and support with mainline kernel. Now it is
> > time to extend it. According to the specification, each PHY can be master
> > or slave.
> >
> > The HW can be pre configured via bootstrap pins or fuses to have a default
> > configuration. But in some cases we still need to be able to configure the
> > PHY in a different mode:
> > --------------------------------------------------------------------------------
> >
> >
> > 6.1 MASTER-SLAVE configuration resolution
> >
> > All BroadR-Reach PHYs will default to configure as SLAVE upon power up or
> > reset until a management system (for example, processor/microcontroller)
> > configures it to be MASTER. MASTER-SLAVE assignment for each link
> > configuration is necessary for establishing the timing control of each PHY.
> >
> > 6.2 PHY-Initialization
> >
> > Both PHYs sharing a link segment are capable of being MASTER or SLAVE. In
> > IEEE 802.3-2012, MASTER-SLAVE resolution is attained during the
> > Auto-Negotiation process (see IEEE 802.3-2012 Clause 28). However, the
> > latency for this process is not acceptable for automotive application. A
> > forced assignment scheme is employed depending on the physical deployment
> > of the PHY within the car. This process is conducted at the power-up or
> > reset condition. The station management system manually configures the
> > BroadR-Reach PHY to be MASTER (before the link acquisition process starts)
> > while the link partner defaults to SLAVE (un-managed).
> > --------------------------------------------------------------------------------
> >
> > Should phylink be involved in this configuration? What's the proper user
> > space interface to use for this kind of configuration? ethtool or ip
> > comes into mind. Further having a Device Tree property to configure a
> > default mode to overwrite the boot strap pins would be nice to have.
> Well, the first question would be whether this is something that
> userspace needs to alter, or whether static configuration at boot
> time is what is necessary.
> Given what is in the description, it seems that the concern is with
> the latency it takes for the link to come up. I would suggest that
> the lowest latency would be achieved when using static configuration
> rather than waiting for the kernel to fully boot and userspace to
> start before configuring the PHY.

Yes, that would be the fastest, and in many cases the preferred way. But the
lack of auto negotiation is not a choice. It is imposed by the spec. Because
of this, and since the PHY's are configurable in software, there is some need
for configuration in user-space. Of course latency would not be an issue in
such a case, otherwise a fixed strapped configuration was chosen.

Best regards,

David Jander
Protonic Holland.

 \ /
  Last update: 2020-03-25 11:36    [W:0.051 / U:1.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site