Re: Clarification on user configurable parameters implementation in PHY driver

[Andrew Lunn <andrew@lunn.ch>]

On Fri, Mar 18, 2022 at 12:30:47PM +0000, Parthiban.Veerasooran@microchip.com wrote:
> Hi All,
> 
> Microchip LAN8670 is a high-performance 10BASE-T1S single-pair Ethernet 
> PHY transceiver for 10 Mbit/s half-duplex networking over a single pair 
> of conductors. The LAN8670 is designed for use in high-reliability cost 
> sensitive industrial, back plane, and building automation 
> sensor/actuator applications.
> 
> Physical Layer Collision Avoidance (PLCA) is one of the features in this 
> PHY which allows for high bandwidth utilization by avoiding collisions 
> on the physical layer and burst mode for transmission of multiple 
> packets for high packet rate latency-sensitive applications. This PLCA 
> feature uses the following user configurable parameters to be configured 
> through PHY driver.
> 
>      1. PLCA node id
>      2. PLCA node count
>      3. PLCA transmit opportunity time
>      4. PLCA max burst count
>      5. PLCA max burst time
>      6. PLCA enable/disable
> 
> In the existing PHY frame work, I don't see any interface to expose the 
> user configurable parameters to user space from PHY driver. I did even 
> refer some PHY drivers in the kernel source and they are hard coded the 
> configurable values in the driver and of course they are not needed to 
> be configured by user.
> 
> But in our case, the above parameters are user configurable for 
> different nodes (Ethernet interfaces) in the network.
> 
> Could you please propose a right approach to implement the above 
> requirement ?

Hi Parthiban

This is part of Clause 148?

Are the parameters you listed part of 148, or are they specific to
your implementation?

Whatever API you define, it needs to be generic to any PHY which
implements clause 148. So ideally you need to look at clause 148, not
what you datasheet says, and define the API around clause 148. It also
sounds like you should be implementing the users space tool, which
might actually be an extension of ethtool. ethtool has been
transitioning to netlink over the last few years, so i would suggest
you define a generic netlink API within the ethtool framework.

    Andrew