public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Lukasz Majewski <lukma@denx.de>
Cc: Marek Vasut <marek.vasut@mailbox.org>,
	u-boot@lists.denx.de, Tom Rini <trini@konsulko.com>,
	Anatolij Gustschin <agust@denx.de>,
	Ramon Fried <rfried.dev@gmail.com>,
	Joe Hershberger <joe.hershberger@ni.com>,
	Marek Vasut <marek.vasut+renesas@mailbox.org>,
	Michal Simek <michal.simek@amd.com>,
	Tim Harvey <tharvey@gateworks.com>
Subject: Re: [PATCH v1 2/6] net: mv88e61xx: Configure PHY ports to also pass packets between them
Date: Thu, 1 Jun 2023 19:46:51 +0300	[thread overview]
Message-ID: <20230601164651.tquily3zoi2hhgwt@skbuf> (raw)
In-Reply-To: <83893eea-7a3e-8fc1-da43-aa50149fa11c@mailbox.org>

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.

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. But again, I'm not
really sure what's the use case.

  reply	other threads:[~2023-06-01 16:47 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-01  9:59 [PATCH v1 0/6] Provide support for mv88e6020 Marvell switch Lukasz Majewski
2023-06-01 10:00 ` [PATCH v1 1/6] net: mv88e61xx: Add support for checking addressing mode Lukasz Majewski
2023-06-01 10:00 ` [PATCH v1 2/6] net: mv88e61xx: Configure PHY ports to also pass packets between them Lukasz Majewski
2023-06-01 10:35   ` Marek Vasut
2023-06-01 11:02     ` Lukasz Majewski
2023-06-01 11:44       ` Marek Vasut
2023-06-01 16:46         ` Vladimir Oltean [this message]
2023-06-02 13:56           ` Lukasz Majewski
2023-06-01 10:00 ` [PATCH v1 3/6] net: mv88e61xx: Clear temporary structs before using them in get_phy_id() Lukasz Majewski
2023-06-01 10:36   ` Marek Vasut
2023-06-01 10:00 ` [PATCH v1 4/6] net: mv88e61xx: Directly access the switch chip Lukasz Majewski
2023-06-01 10:00 ` [PATCH v1 5/6] net: mv88e61xx: Set proper offset when R0_LED/ADDR4 is set on bootstrap Lukasz Majewski
2023-06-01 10:00 ` [PATCH v1 6/6] net: mv88e61xx: Reset switch PHYs when bootstrapped to !NO_CPU Lukasz Majewski
2023-06-01 10:38   ` Marek Vasut
2023-06-01 12:13     ` Lukasz Majewski
2023-06-01 15:16       ` Marek Vasut
  -- strict thread matches above, loose matches on Subject: below --
2021-03-17 14:14 [PATCH v1 0/6] Provide support for mv88e6020 Marvell switch Lukasz Majewski
2021-03-17 14:14 ` [PATCH v1 2/6] net: mv88e61xx: Configure PHY ports to also pass packets between them Lukasz Majewski
2021-05-08  6:25   ` Ramon Fried

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230601164651.tquily3zoi2hhgwt@skbuf \
    --to=olteanv@gmail.com \
    --cc=agust@denx.de \
    --cc=joe.hershberger@ni.com \
    --cc=lukma@denx.de \
    --cc=marek.vasut+renesas@mailbox.org \
    --cc=marek.vasut@mailbox.org \
    --cc=michal.simek@amd.com \
    --cc=rfried.dev@gmail.com \
    --cc=tharvey@gateworks.com \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox