[PATCH v1 2/6] net: mv88e61xx: Configure PHY ports to also pass packets between them

[Lukasz Majewski]

Hi Vladimir,

> Hi Lukasz,
> 
> On Thu, Jun 01, 2023 at 01:44:30PM +0200, Marek Vasut wrote:
> > I think after two years, it would be good to drop the RB tags and
> > do another round of reviews.  
> 
> To expand on Marek's point.
> 
> In those past 2 years, Tim Harvey has put in a considerable amount of
> effort to add another driver for mv88e6xxx that uses DM_DSA. I believe
> the current "PHY" driver for the same hardware should be considered
> obsolete until all platforms are converted to DM_DSA, then it can be
> deleted. So, no new features for it.

Ok. Thanks for the clarification.

> 
> Then, there's also the question of the sanity of the proposed change
> itself.
> 
> I believe that we need to be humble enough to recognize that the
> U-Boot network stack is not competent enough to handle the switching
> capabilities of a switch, not even enough for it to be safe. It
> doesn't handle STP (Spanning Tree Protocol), for one thing. So it
> will never be capable of detecting switching loops, such as to block
> one of its ports in order to not kill the network.
> 
> In principle, I would say: as long as there is no plan to handle STP,
> there should be no plan to allow autonomous packet forwarding from
> U-Boot. The U-Boot network stack is there so that you can TFTP a
> kernel and boot it, which is also the only use case behind DM_DSA.
> 
> But you may say: I'm never going to allow packet forwarding from
> U-Boot in a network with loops!
> 
> Okay, but your patch suggests otherwise. Which ports allow forwarding
> is a compile-time option, which... is by definition contrary to any
> runtime network topology determinations.
> 
> Maybe enabling forwarding between switch ports through a CLI command
> that communicates with DM_DSA would be tolerable - assuming that users
> are smart enough to not use it in a network with STP.

No - adding extra command line option is not planned.

> But again, I'm
> not really sure what's the use case.

This is a simple use case - the board on which I do work has two LAN
ports, so the device is "attached" to the single LAN cable.

When booting the device (even in u-boot) - packet's shall be forwarded
between LAN ports to keep the ETH connection.

However, I don't want to add STP for the u-boot network stack.

I've also looked to Tim's patch set [1] (also in mainline), and I do
believe that some extra features for this driver can be added; like
ADDR4 (so the address is 'shifted' to 0x10) and !NO_CPU bootstraps
(so ports need to be reset at power up).

Those features are common for all mv88e6xxx devices.


Links:

[1] -
https://patchwork.ozlabs.org/project/uboot/cover/20221130174251.82087-1-tharvey@gateworks.com/


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma at denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230602/5b0acdb3/attachment.sig>