Re: user space interface for configuring T1 PHY management mode (master/slave)

[Russell King - ARM Linux admin]

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: 
> --------------------------------------------------------------------------------
> http://www.ieee802.org/3/1TPCESG/public/BroadR_Reach_Automotive_Spec_V3.0.pdf
> 
> 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.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up