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: <22d3ed94-2c8b-4d7d-9c19-1ab13ee2c4a4@lunn.ch>
Date: Mon, 13 Nov 2023 23:23:27 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: Fabio Estevam <festevam@...il.com>, kuba@...nel.org,
	davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com,
	robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
	conor+dt@...nel.org, netdev@...r.kernel.org,
	devicetree@...r.kernel.org, Fabio Estevam <festevam@...x.de>
Subject: Re: [PATCH net-next] dt-bindings: net: snps,dwmac: Do not make
 'phy-mode' required

On Mon, Nov 13, 2023 at 02:03:00PM -0800, Florian Fainelli wrote:
> On 11/13/23 13:51, Andrew Lunn wrote:
> > On Mon, Nov 13, 2023 at 05:40:52PM -0300, Fabio Estevam wrote:
> > > From: Fabio Estevam <festevam@...x.de>
> > > 
> > > The property 'phy-connection-type' can also be used to describe
> > > the interface type between the Ethernet device and the Ethernet PHY
> > > device.
> > > 
> > > Mark 'phy-mode' as a non required property.
> > 
> > Hi Fabio
> > 
> > What does the driver actually require? Will it error out if neither is
> > provided?
> > 
> > Maybe we should be changing the condition that one or the other is
> > required?

Hi Florian

 
> 'phy-connection-type' is the deprecated version of 'phy-mode'

I thought that too, but
Documentation/devicetree/bindings/net/ethernet-controller.yaml does
not mark it deprecated.

The original .txt file has a different wording:

- phy-mode: string, operation mode of the PHY interface. This is now a de-facto
  standard property; supported values are:
  * "internal" (Internal means there is not a standard bus between the MAC and
     the PHY, something proprietary is being used to embed the PHY in the MAC.)
  * "mii"
  * "gmii"

- phy-connection-type: the same as "phy-mode" property but described in the
  Devicetree Specification;

So it could technically be we cannot deprecate phy-connection-type
because it is part of the standard, and we need to accept it.

> which
> of_get_phy_mode() will fall back to if 'phy-mode' is not provided. It does
> not appear that stmmac attempts to use anything other than of_get_phy_mode()
> therefore would not it be acceptable to update the relevant .dts file such
> that it uses 'phy-mode'?

Using phy-mode would be more consistent, since its used > 10x more
than phy-connection-type.

     Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ