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
| ||
|
Message-ID: <ZQNL0Vy3kMbWlNFl@shell.armlinux.org.uk> Date: Thu, 14 Sep 2023 19:07:13 +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 Thu, Sep 14, 2023 at 07:06:11PM +0100, Russell King (Oracle) wrote: > 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. Oh dear. I must be going mad! -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
Powered by blists - more mailing lists