netdev - Re: [PATCH 2/4] dt-bindings: net: dsa: document internal MDIO bus

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: <ZQNLkiAt4jOjojRf@shell.armlinux.org.uk>
Date: Thu, 14 Sep 2023 19:06:10 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Arınç ÜNAL <arinc.unal@...nc9.com>,
	Andrew Lunn <andrew@...n.ch>,
	Florian Fainelli <f.fainelli@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Rob Herring <robh+dt@...nel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Woojung Huh <woojung.huh@...rochip.com>,
	UNGLinuxDriver@...rochip.com,
	Linus Walleij <linus.walleij@...aro.org>,
	Alvin Šipraga <alsi@...g-olufsen.dk>,
	Daniel Golle <daniel@...rotopia.org>,
	Landen Chao <Landen.Chao@...iatek.com>,
	DENG Qingfang <dqfext@...il.com>,
	Sean Wang <sean.wang@...iatek.com>,
	Matthias Brugger <matthias.bgg@...il.com>,
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
	mithat.guner@...ont.com, erkin.bozoglu@...ont.com,
	netdev@...r.kernel.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH 2/4] dt-bindings: net: dsa: document internal MDIO bus

On Wed, Sep 13, 2023 at 04:59:19PM +0100, Russell King (Oracle) wrote:
> On Wed, Sep 13, 2023 at 10:42:31AM +0300, Vladimir Oltean wrote:
> > On Wed, Sep 13, 2023 at 08:52:37AM +0300, Arınç ÜNAL wrote:
> > > On 12.09.2023 22:34, Vladimir Oltean wrote:
> > > > On Tue, Sep 12, 2023 at 10:23:51PM +0300, Arınç ÜNAL wrote:
> > > > > The phylink bindings for user ports I ended up making by looking up the
> > > > > existing devicetrees are different than the phylink bindings for the shared
> > > > > (CPU and DSA) ports currently enforced on all switches.
> > > > > 
> > > > > My phylink bindings for user ports:
> > > > > 
> > > > >              allOf:
> > > > >                - anyOf:
> > > > >                    - required: [ fixed-link ]
> > > > >                    - required: [ phy-handle ]
> > > > >                    - required: [ managed ]
> > > > > 
> > > > >                - if:
> > > > >                    required: [ fixed-link ]
> > > > >                  then:
> > > > >                    not:
> > > > >                      required: [ managed ]
> > > > 
> > > > Right, it should have been anyOf and not oneOf.. my mistake. It is a bug
> > > > which should be fixed. It's the same phylink that gets used in both cases,
> > > > user ports and shared ports :)
> > > 
> > > One more thing, I don't recall phy-mode being required to be defined for
> > > user ports as it will default to GMII. I don't believe this is the same
> > > case for shared ports so phy-mode is required only for them?
> > 
> > phy-mode is not strictly required, but I think there is a strong
> > preference to set it. IIRC, when looking at the DSA device trees, there
> > was no case where phy-mode would be absent on CPU/DSA ports if the other
> > link properties were also present, so we required it too. There were no
> > complaints in 1 year since dsa_shared_port_validate_of() is there. The
> > requirement can be relaxed to just a warning and no error in the kernel,
> > and the removal of "required" in the schema, if it helps making it
> > common with user ports.
> 
> However, phylink pretty much requires phy-mode to be specified to be
> something sane for shared ports, so I wouldn't be in favour of relaxing
> the checkinng in dsa_shared_port_validate_of()... not unless you're
> now going to accept the approach I originally proposed to have DSA
> drivers tell the core (and thus phylink) what phy-mode and other link
> parameters should be used when they are missing from DT.

You mean the approach that I picked up using software nodes that got
thrown out by the software node people? That approach that I picked
up from you and tried to get merged?

No, that's not going to happen, and it's not a question of whether
_I_ am going to accept that approach or not. So don't throw that
back on me, please.

If this is something that we want to solve, we need to stop being so
devisive (your language above is so) and try to come up with a
solution that is acceptable to everyone... the swnode approach
doesn't seem to be it.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!