All of lore.kernel.org
 help / color / mirror / Atom feed
* Clarification on user configurable parameters implementation in PHY driver
@ 2022-03-18 12:30 Parthiban.Veerasooran
  2022-03-19  0:54 ` Andrew Lunn
  2022-03-19 15:33 ` Andrew Lunn
  0 siblings, 2 replies; 3+ messages in thread
From: Parthiban.Veerasooran @ 2022-03-18 12:30 UTC (permalink / raw)
  To: netdev; +Cc: Jan.Huber, Thorsten.Kummermehr

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 ?

Thanks & Regards,
Parthiban V
Microchip Technology Inc.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Clarification on user configurable parameters implementation in PHY driver
  2022-03-18 12:30 Clarification on user configurable parameters implementation in PHY driver Parthiban.Veerasooran
@ 2022-03-19  0:54 ` Andrew Lunn
  2022-03-19 15:33 ` Andrew Lunn
  1 sibling, 0 replies; 3+ messages in thread
From: Andrew Lunn @ 2022-03-19  0:54 UTC (permalink / raw)
  To: Parthiban.Veerasooran; +Cc: netdev, Jan.Huber, Thorsten.Kummermehr

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Clarification on user configurable parameters implementation in PHY driver
  2022-03-18 12:30 Clarification on user configurable parameters implementation in PHY driver Parthiban.Veerasooran
  2022-03-19  0:54 ` Andrew Lunn
@ 2022-03-19 15:33 ` Andrew Lunn
  1 sibling, 0 replies; 3+ messages in thread
From: Andrew Lunn @ 2022-03-19 15:33 UTC (permalink / raw)
  To: Parthiban.Veerasooran; +Cc: netdev, Jan.Huber, Thorsten.Kummermehr

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

Hi Parthiban

I just had a quick read of 802.3cg.

As far as i see, it does not define the registers used to control
PLCA. So i guess each vendor will define there own registers in the
vendor section of clause 45? This also means there will not be a
shared implementation in linux, so the API you define needs to go all
the way down into the PHY driver.

What is defined are the management objects. Table 30-11, PLCA
capabilities defines:

aPLCAAdminState ATTRIBUTE GET
aPLCAStatus ATTRIBUTE GET
aPLCABurstTimer ATTRIBUTE GET-SET
aPLCALocalNodeID ATTRIBUTE GET-SET
aPLCAMaxBurstCount ATTRIBUTE GET-SET
aPLCANodeCount ATTRIBUTE GET-SET
aPLCATransmitOpportunityTimer ATTRIBUTE GET-SET

This is basically what you listed above. 

So i suggest you define a netlink API around these, as part of the
Ethtool API. You can reference the standard when defining the API, so
making it clear what the netlink attributes mean, what unit they use
etc.

	Andrew

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-03-19 15:33 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-18 12:30 Clarification on user configurable parameters implementation in PHY driver Parthiban.Veerasooran
2022-03-19  0:54 ` Andrew Lunn
2022-03-19 15:33 ` Andrew Lunn

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.