From: Andrew Lunn <andrew@lunn.ch>
To: Egil Hjelmeland <privat@egil-hjelmeland.no>
Cc: vivien.didelot@savoirfairelinux.com, f.fainelli@gmail.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next 2/2] net: dsa: lan9303: Add basic offloading of unicast traffic
Date: Thu, 21 Sep 2017 16:21:27 +0200 [thread overview]
Message-ID: <20170921142127.GB27589@lunn.ch> (raw)
In-Reply-To: <20170921094139.4250-3-privat@egil-hjelmeland.no>
Hi Egil
> +static void lan9303_bridge_ports(struct lan9303 *chip)
> +{
> + /* ports bridged: remove mirroring */
> + lan9303_write_switch_reg(chip, LAN9303_SWE_PORT_MIRROR, 0);
> +}
Could you replace the 0 with something symbolic which makes this
easier to understand.
#define LAN9303_SWE_PORT_MIRROR_DISABLED 0
> +
> static int lan9303_handle_reset(struct lan9303 *chip)
> {
> if (!chip->reset_gpio)
> @@ -844,6 +866,69 @@ static void lan9303_port_disable(struct dsa_switch *ds, int port,
> }
> }
>
> +static int lan9303_port_bridge_join(struct dsa_switch *ds, int port,
> + struct net_device *br)
> +{
> + struct lan9303 *chip = ds->priv;
> +
> + dev_dbg(chip->dev, "%s(port %d)\n", __func__, port);
> + if (ds->ports[1].bridge_dev == ds->ports[2].bridge_dev) {
> + lan9303_bridge_ports(chip);
> + chip->is_bridged = true; /* unleash stp_state_set() */
> + }
> +
> + return 0;
> +}
> +
> +static void lan9303_port_bridge_leave(struct dsa_switch *ds, int port,
> + struct net_device *br)
> +{
> + struct lan9303 *chip = ds->priv;
> +
> + dev_dbg(chip->dev, "%s(port %d)\n", __func__, port);
> + if (chip->is_bridged) {
> + lan9303_separate_ports(chip);
> + chip->is_bridged = false;
> + }
> +}
> +
> +static void lan9303_port_stp_state_set(struct dsa_switch *ds, int port,
> + u8 state)
> +{
> + int portmask, portstate;
> + struct lan9303 *chip = ds->priv;
> +
> + dev_dbg(chip->dev, "%s(port %d, state %d)\n",
> + __func__, port, state);
> + if (!chip->is_bridged)
> + return; /* touching SWE_PORT_STATE will break port separation */
I'm wondering how this is supposed to work. Please add a good comment
here, since the hardware is forcing you to do something odd.
Maybe it would be a good idea to save the STP state in chip. And then
when chip->is_bridged is set true, change the state in the hardware to
the saved value?
What happens when port 0 is added to the bridge, there is then a
minute pause and then port 1 is added? I would expect that as soon as
port 0 is added, the STP state machine for port 0 will start and move
into listening and then forwarding. Due to hardware limitations it
looks like you cannot do this. So what state is the hardware
effectively in? Blocking? Forwarding?
Then port 1 is added. You can then can respect the states. port 1 will
do blocking->listening->forwarding, but what about port 0? The calls
won't get repeated? How does it transition to forwarding?
Andrew
> +
> + switch (state) {
> + case BR_STATE_DISABLED:
> + portstate = LAN9303_SWE_PORT_STATE_DISABLED_PORT0;
> + break;
> + case BR_STATE_BLOCKING:
> + case BR_STATE_LISTENING:
> + portstate = LAN9303_SWE_PORT_STATE_BLOCKING_PORT0;
> + break;
> + case BR_STATE_LEARNING:
> + portstate = LAN9303_SWE_PORT_STATE_LEARNING_PORT0;
> + break;
> + case BR_STATE_FORWARDING:
> + portstate = LAN9303_SWE_PORT_STATE_FORWARDING_PORT0;
> + break;
> + default:
> + portstate = LAN9303_SWE_PORT_STATE_DISABLED_PORT0;
> + dev_err(chip->dev, "unknown stp state: port %d, state %d\n",
> + port, state);
> + }
> +
> + portmask = 0x3 << (port * 2);
> + portstate <<= (port * 2);
> + lan9303_write_switch_reg_mask(chip, LAN9303_SWE_PORT_STATE,
> + portstate, portmask);
> +}
next prev parent reply other threads:[~2017-09-21 14:21 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-21 9:41 [PATCH net-next 0/2] lan9303: Add basic offloading of unicast traffic Egil Hjelmeland
2017-09-21 9:41 ` [PATCH net-next 1/2] net: dsa: lan9303: Move tag setup to new lan9303_setup_tagging Egil Hjelmeland
2017-09-21 14:40 ` Vivien Didelot
2017-09-21 9:41 ` [PATCH net-next 2/2] net: dsa: lan9303: Add basic offloading of unicast traffic Egil Hjelmeland
2017-09-21 14:21 ` Andrew Lunn [this message]
2017-09-22 7:06 ` Egil Hjelmeland
2017-09-22 20:08 ` Andrew Lunn
2017-09-23 9:58 ` Egil Hjelmeland
2017-09-23 14:31 ` Andrew Lunn
2017-09-24 22:02 ` Egil Hjelmeland
2017-09-21 14:26 ` Vivien Didelot
2017-09-22 7:23 ` Egil Hjelmeland
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=20170921142127.GB27589@lunn.ch \
--to=andrew@lunn.ch \
--cc=f.fainelli@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=privat@egil-hjelmeland.no \
--cc=vivien.didelot@savoirfairelinux.com \
/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