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]
Date:   Tue, 31 Mar 2020 11:09:32 +0200
From:   Matthias Schiffer <matthias.schiffer@...tq-group.com>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        andrew@...n.ch, vivien.didelot@...il.com, davem@...emloft.net,
        kuba@...nel.org
Subject: Re: (EXT) Re: [PATCH net-next 1/4] net: dsa: allow switch drivers
 to override default slave PHY addresses

On Mon, 2020-03-30 at 20:04 -0700, Florian Fainelli wrote:
> 
> On 3/30/2020 6:53 AM, Matthias Schiffer wrote:
> > Avoid having to define a PHY for every physical port when PHY
> > addresses
> > are fixed, but port index != PHY address.
> > 
> > Signed-off-by: Matthias Schiffer <matthias.schiffer@...tq-group.com
> > >
> 
> You could do this much more elegantly by doing this with Device Tree
> and
> specifying the built-in PHYs to be hanging off the switch's internal
> MDIO bus and specifying the port to PHY address mapping, you would
> only
> patch #4 then.

This does work indeed, but it seems we have different ideas on
elegance.

I'm not happy about the fact that an implementor needs to study the
switch manual in great detail to find out about things like the PHY
address offsets when the driver could just to the right thing by
default. Requiring this only for some switch configurations, while
others work fine with the defaults, doesn't make this any less
confusing (I'd even argue that it would be better if there weren't any
default PHY and IRQ mappings for the switch ports, but I also
understand that this can't easily be removed at this point...)

In particular when PHY IRQ support is desired (not implemented on the
PHY driver side for this switch yet; not sure if my current project
will require it), indices are easy to get wrong - which might not be
noticed as long as there is no PHY driver with IRQ support for the port
PHYs, potentially breaking existing Device Trees with future kernel
updates. For this reason, I think at least patch #2 should be
considered even if #1 and #3 are rejected.

Kind regards,
Matthias

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ