linux-kernel - Re: [PATCH v4 net-next 5/5] drivers/net/phy: add driver for the onsemi NCN26000 10BASE-T1S PHY

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y4/fTVKJEbTYQxja@gvm01>
Date:   Wed, 7 Dec 2022 01:33:17 +0100
From:   Piergiorgio Beruto <piergiorgio.beruto@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org, Oleksij Rempel <o.rempel@...gutronix.de>
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