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  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, 3 Aug 2021 00:33:53 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Prasanna Vengateshan <prasanna.vengateshan@...rochip.com>,
        netdev@...r.kernel.org, robh+dt@...nel.org,
        UNGLinuxDriver@...rochip.com, Woojung.Huh@...rochip.com,
        hkallweit1@...il.com, linux@...linux.org.uk, davem@...emloft.net,
        kuba@...nel.org, linux-kernel@...r.kernel.org,
        vivien.didelot@...il.com, f.fainelli@...il.com,
        devicetree@...r.kernel.org
Subject: Re: [PATCH v3 net-next 05/10] net: dsa: microchip: add DSA support
 for microchip lan937x

On Sun, Aug 01, 2021 at 12:05:16AM +0200, Andrew Lunn wrote:
> > So you support both the cases where an internal PHY is described using
> > OF bindings, and where the internal PHY is implicitly accessed using the
> > slave_mii_bus of the switch, at a PHY address equal to the port number,
> > and with no phy-handle or fixed-link device tree property for that port?
> > 
> > Do you need both alternatives? The first is already more flexible than
> > the second.
> 
> The first is also much more verbose in DT, and the second generally
> just works without any DT. What can be tricky with the second is
> getting PHY interrupts to work, but it is possible, the mv88e6xxx does
> it.

- The explicit phy-handle is more verbose as far as the DT description
  goes for one particular use case of indirect internal PHY access, but
  it also leads to less complex code (more uniform with other usage
  patterns in the kernel). What is tricky with an implicit phy-handle is
  trivial without it. This makes a difference with DM_DSA in U-Boot,
  where I would really like to avoid bloating the code and just support
  2 options for a DSA switch port: either a phy-handle or a fixed-link.
  These two are already "Turing-complete" (they can describe any system)
  so I only see the implicit phy-handle as a helping hand for a few lazy
  DT writers. Since I have been pushing back that we shouldn't bloat
  U-Boot with implicit phy-handle logic when it doesn't give a concrete
  benefit, and have gotten a push back in return that Linux does allow
  it and it would be desirable for one DT binding to cover all, I now
  need to promote the more generic approach for Linux going forward too.

- If the switch has the ability for its internal PHYs to be accessed
  directly over MDIO pins instead of using indirect SPI transfers, using
  a phy-handle is a generic way to handle both cases, while the implicit
  phy-handle does not give you that option.

- If there is complex pinmuxing in the SoC and one port can either be
  connected to an internal 100base-T1 or to a 100base-TX PHY, and this
  is not detectable by software, this cannot be dealt with using an
  implicit phy-handle if the 100base-T1 and 100base-TX PHYs are not at
  the same address.

- In general, if the internal PHYs are not at an MDIO address equal to
  the port number, this cannot be dealt with using the implicit
  phy-handle method.

Powered by blists - more mailing lists