Messages in this thread | | | Date | Wed, 7 Dec 2022 01:33:17 +0100 | From | Piergiorgio Beruto <> | Subject | Re: [PATCH v4 net-next 5/5] drivers/net/phy: add driver for the onsemi NCN26000 10BASE-T1S PHY |
| |
On Tue, Dec 06, 2022 at 08:12:02PM +0100, Andrew Lunn wrote: > > I was wondering if there is some interface (sysfs / proc / other) to set > > parameters which are very specific to a PHY implementation? > > Please describe what they are, and in what context you need them. Then > we can decide on the correct API. > > In general, the OS is there to abstract over the hardware so they all > look the same. We don't want anything specific to the PHY. That's clear, let me explain.
Enable of enhanced-noise-immunity mode - This trades off CSMA/CD performance for noise immunity. It could be a static setting, but the user may want to conditionally enable it depending on application decisions. E.g. some people may want to enable/disable this when using CSMA/CD as a fallback in case the PLCA coordinator disappears. Of course, there are better ways of doing this, but it is a possible use-case that some people want to use.
Tuning of internal impedance to match the line/MDI - This is really board dependent, so DT seems good to me
Tuning of PMA filters to optimize SNR - same as above?
Tuning of TX voltage levels - I am not 100% sure that is static (DT) but for the time being it could be considered as such. It basically trades-off EMI (immunity) for EME (emissions).
Topology Discovery - This is a special mode to detect the physical distance among nodes on the multi-drop cable. It is also being standardized in the OPEN Alliance, but for the time being, it is proprietary. I think it will require some kernel support as a protocol is also involved (but not standardized, yet).
Multi-putrpose I/Os (LED, GPIO, SFD detect). - I know the kernel already has the infrastructure for those functions (not sure about SFD) so I assume this could be some DT work and some code to configure the MUX to achieve the specific function.
Selection of link status triggers - This is what I was trying to achieve with the module parameter. i.e., the link status can be a simple on/off based on the link_control setting (this is what it is for CSMA/CD as there is no link concept) or it could be masked by PLCA status whrn PLCA is enabled. This is a design choice of the user. In the former case, you don't get a link down if the PHY automatically go back to CSMA/CD as a result of PLCA status being 0. In the latter case you get a link down until PLCA is up & running, preventing the application to send data before time.
Thanks, Piergiorgio
| |