Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 7 Dec 2022 01:33:17 +0100
From:   Piergiorgio Beruto <piergiorgio.beruto@gmail.com>
To:     Andrew Lunn <andrew@lunn.ch>
Cc:     Heiner Kallweit <hkallweit1@gmail.com>,
        Russell King <linux@armlinux.org.uk>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>, linux-kernel@vger.kernel.org,
        netdev@vger.kernel.org, Oleksij Rempel <o.rempel@pengutronix.de>
Subject: Re: [PATCH v4 net-next 5/5] drivers/net/phy: add driver for the
 onsemi NCN26000 10BASE-T1S PHY
Message-ID: <Y4/fTVKJEbTYQxja@gvm01>
References: <cover.1670329232.git.piergiorgio.beruto@gmail.com>
 <1816cb14213fc2050b1a7e97a68be7186340d994.1670329232.git.piergiorgio.beruto@gmail.com>
 <Y49IBR8ByMQH6oVt@lunn.ch>
 <Y49THkXZdLBR6Mxv@gvm01>
 <Y49yxcd6m7K3G3ZA@lunn.ch>
 <Y4+FqsZLBzDzadcC@gvm01>
 <Y4+UAmyS5hJ0+c66@lunn.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Y4+UAmyS5hJ0+c66@lunn.ch>
Precedence: bulk

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