[{"id":1772836,"web_url":"http://patchwork.ozlabs.org/comment/1772836/","msgid":"<20170921142127.GB27589@lunn.ch>","list_archive_url":null,"date":"2017-09-21T14:21:27","subject":"Re: [PATCH net-next 2/2] net: dsa: lan9303: Add basic offloading of\n\tunicast traffic","submitter":{"id":13608,"url":"http://patchwork.ozlabs.org/api/people/13608/","name":"Andrew Lunn","email":"andrew@lunn.ch"},"content":"Hi Egil\n\n> +static void lan9303_bridge_ports(struct lan9303 *chip)\n> +{\n> +\t/* ports bridged: remove mirroring */\n> +\tlan9303_write_switch_reg(chip, LAN9303_SWE_PORT_MIRROR, 0);\n> +}\n\nCould you replace the 0 with something symbolic which makes this\neasier to understand.\n\n#define LAN9303_SWE_PORT_MIRROR_DISABLED 0\n\n> +\n> static int lan9303_handle_reset(struct lan9303 *chip)\n> {\n> \tif (!chip->reset_gpio)\n> @@ -844,6 +866,69 @@ static void lan9303_port_disable(struct dsa_switch *ds, int port,\n> \t}\n> }\n> \n> +static int lan9303_port_bridge_join(struct dsa_switch *ds, int port,\n> +\t\t\t\t struct net_device *br)\n> +{\n> +\tstruct lan9303 *chip = ds->priv;\n> +\n> +\tdev_dbg(chip->dev, \"%s(port %d)\\n\", __func__, port);\n> +\tif (ds->ports[1].bridge_dev == ds->ports[2].bridge_dev) {\n> +\t\tlan9303_bridge_ports(chip);\n> +\t\tchip->is_bridged = true; /* unleash stp_state_set() */\n> +\t}\n> +\n> +\treturn 0;\n> +}\n> +\n> +static void lan9303_port_bridge_leave(struct dsa_switch *ds, int port,\n> +\t\t\t\t struct net_device *br)\n> +{\n> +\tstruct lan9303 *chip = ds->priv;\n> +\n> +\tdev_dbg(chip->dev, \"%s(port %d)\\n\", __func__, port);\n> +\tif (chip->is_bridged) {\n> +\t\tlan9303_separate_ports(chip);\n> +\t\tchip->is_bridged = false;\n> +\t}\n> +}\n> +\n> +static void lan9303_port_stp_state_set(struct dsa_switch *ds, int port,\n> +\t\t\t\t u8 state)\n> +{\n> +\tint portmask, portstate;\n> +\tstruct lan9303 *chip = ds->priv;\n> +\n> +\tdev_dbg(chip->dev, \"%s(port %d, state %d)\\n\",\n> +\t\t__func__, port, state);\n> +\tif (!chip->is_bridged)\n> +\t\treturn; /* touching SWE_PORT_STATE will break port separation */\n\nI'm wondering how this is supposed to work. Please add a good comment\nhere, since the hardware is forcing you to do something odd.\n\nMaybe it would be a good idea to save the STP state in chip. And then\nwhen chip->is_bridged is set true, change the state in the hardware to\nthe saved value?\n\nWhat happens when port 0 is added to the bridge, there is then a\nminute pause and then port 1 is added? I would expect that as soon as\nport 0 is added, the STP state machine for port 0 will start and move\ninto listening and then forwarding. Due to hardware limitations it\nlooks like you cannot do this. So what state is the hardware\neffectively in? Blocking? Forwarding?\n\nThen port 1 is added. You can then can respect the states. port 1 will\ndo blocking->listening->forwarding, but what about port 0? The calls\nwon't get repeated? How does it transition to forwarding?\n\n Andrew\n\n> +\n> +\tswitch (state) {\n> +\tcase BR_STATE_DISABLED:\n> +\t\tportstate = LAN9303_SWE_PORT_STATE_DISABLED_PORT0;\n> +\t\tbreak;\n> +\tcase BR_STATE_BLOCKING:\n> +\tcase BR_STATE_LISTENING:\n> +\t\tportstate = LAN9303_SWE_PORT_STATE_BLOCKING_PORT0;\n> +\t\tbreak;\n> +\tcase BR_STATE_LEARNING:\n> +\t\tportstate = LAN9303_SWE_PORT_STATE_LEARNING_PORT0;\n> +\t\tbreak;\n> +\tcase BR_STATE_FORWARDING:\n> +\t\tportstate = LAN9303_SWE_PORT_STATE_FORWARDING_PORT0;\n> +\t\tbreak;\n> +\tdefault:\n> +\t\tportstate = LAN9303_SWE_PORT_STATE_DISABLED_PORT0;\n> +\t\tdev_err(chip->dev, \"unknown stp state: port %d, state %d\\n\",\n> +\t\t\tport, state);\n> +\t}\n> +\n> +\tportmask = 0x3 << (port * 2);\n> +\tportstate <<= (port * 2);\n> +\tlan9303_write_switch_reg_mask(chip, LAN9303_SWE_PORT_STATE,\n> +\t\t\t\t portstate, portmask);\n> +}","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xyf1q5GPLz9s7g\n\tfor ;\n\tFri, 22 Sep 2017 00:21:51 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751979AbdIUOVf (ORCPT );\n\tThu, 21 Sep 2017 10:21:35 -0400","from vps0.lunn.ch ([185.16.172.187]:51313 \"EHLO vps0.lunn.ch\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751966AbdIUOVd (ORCPT );\n\tThu, 21 Sep 2017 10:21:33 -0400","from andrew by vps0.lunn.ch with local (Exim 4.84_2)\n\t(envelope-from )\n\tid 1dv2M3-0007ZW-A4; Thu, 21 Sep 2017 16:21:27 +0200"],"Date":"Thu, 21 Sep 2017 16:21:27 +0200","From":"Andrew Lunn ","To":"Egil Hjelmeland ","Cc":"vivien.didelot@savoirfairelinux.com, f.fainelli@gmail.com,\n\tnetdev@vger.kernel.org, linux-kernel@vger.kernel.org","Subject":"Re: [PATCH net-next 2/2] net: dsa: lan9303: Add basic offloading of\n\tunicast traffic","Message-ID":"<20170921142127.GB27589@lunn.ch>","References":"<20170921094139.4250-1-privat@egil-hjelmeland.no>\n\t<20170921094139.4250-3-privat@egil-hjelmeland.no>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20170921094139.4250-3-privat@egil-hjelmeland.no>","User-Agent":"Mutt/1.5.23 (2014-03-12)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1772850,"web_url":"http://patchwork.ozlabs.org/comment/1772850/","msgid":"<87k20sqg9d.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>","list_archive_url":null,"date":"2017-09-21T14:26:54","subject":"Re: [PATCH net-next 2/2] net: dsa: lan9303: Add basic offloading of\n\tunicast traffic","submitter":{"id":15889,"url":"http://patchwork.ozlabs.org/api/people/15889/","name":"Vivien Didelot","email":"vivien.didelot@savoirfairelinux.com"},"content":"Hi Egil,\n\nEgil Hjelmeland writes:\n\n> When both user ports are joined to the same bridge, the normal\n> HW MAC learning is enabled. This means that unicast traffic is forwarded\n> in HW.\n>\n> If one of the user ports leave the bridge,\n> the ports goes back to the initial separated operation.\n>\n> Port separation relies on disabled HW MAC learning. Hence the condition\n> that both ports must join same bridge.\n>\n> Add brigde methods port_bridge_join, port_bridge_leave and\n> port_stp_state_set.\n>\n> Signed-off-by: Egil Hjelmeland \n\nStyling nitpicks below, other than that, the patch LGTM:\n\nReviewed-by: Vivien Didelot \n\n> #include \n> #include \n> #include \n> +#include \n\nIt's nice to order header inclusions alphabetically.\n\n> \n> #include \"lan9303.h\"\n> \n> @@ -146,6 +147,7 @@\n> # define LAN9303_SWE_PORT_STATE_FORWARDING_PORT0 (0)\n> # define LAN9303_SWE_PORT_STATE_LEARNING_PORT0 BIT(1)\n> # define LAN9303_SWE_PORT_STATE_BLOCKING_PORT0 BIT(0)\n> +# define LAN9303_SWE_PORT_STATE_DISABLED_PORT0 (3)\n> #define LAN9303_SWE_PORT_MIRROR 0x1846\n> # define LAN9303_SWE_PORT_MIRROR_SNIFF_ALL BIT(8)\n> # define LAN9303_SWE_PORT_MIRROR_SNIFFER_PORT2 BIT(7)\n> @@ -431,6 +433,20 @@ static int lan9303_read_switch_reg(struct lan9303 *chip, u16 regnum, u32 *val)\n> \treturn ret;\n> }\n> \n> +static int lan9303_write_switch_reg_mask(\n> +\tstruct lan9303 *chip, u16 regnum, u32 val, u32 mask)\n\nThat is unlikely to respect the Kernel Coding Style. Please fill the\nline as much as possible and align with the opening parenthesis:\n\n static int lan9303_write_switch_reg_mask(struct lan9303 *chip, u16 regnum,\n u32 val, u32 mask)\n\n> +{\n> +\tint ret;\n> +\tu32 reg;\n> +\n> +\tret = lan9303_read_switch_reg(chip, regnum, ®);\n> +\tif (ret)\n> +\t\treturn ret;\n> +\treg = (reg & ~mask) | val;\n> +\n> +\treturn lan9303_write_switch_reg(chip, regnum, reg);\n> +}\n\n...\n\n> +\n> +\tportmask = 0x3 << (port * 2);\n> +\tportstate <<= (port * 2);\n\nUnnecessary alignment, please remove the extra space characters.\n\n> +\tlan9303_write_switch_reg_mask(chip, LAN9303_SWE_PORT_STATE,\n> +\t\t\t\t portstate, portmask);\n> +}\n> +\n> static const struct dsa_switch_ops lan9303_switch_ops = {\n> \t.get_tag_protocol = lan9303_get_tag_protocol,\n> \t.setup = lan9303_setup,\n> @@ -855,6 +940,9 @@ static const struct dsa_switch_ops lan9303_switch_ops = {\n> \t.get_sset_count = lan9303_get_sset_count,\n> \t.port_enable = lan9303_port_enable,\n> \t.port_disable = lan9303_port_disable,\n> +\t.port_bridge_join = lan9303_port_bridge_join,\n> +\t.port_bridge_leave = lan9303_port_bridge_leave,\n> +\t.port_stp_state_set = lan9303_port_stp_state_set,\n\nSame here, alignment unnecessary, especially since the rest of the\nstructure does not do that.\n\n> };\n> \n> static int lan9303_register_switch(struct lan9303 *chip)\n> diff --git a/drivers/net/dsa/lan9303.h b/drivers/net/dsa/lan9303.h\n> index 4d8be555ff4d..5be246f05965 100644\n> --- a/drivers/net/dsa/lan9303.h\n> +++ b/drivers/net/dsa/lan9303.h\n> @@ -21,6 +21,7 @@ struct lan9303 {\n> \tstruct dsa_switch *ds;\n> \tstruct mutex indirect_mutex; /* protect indexed register access */\n> \tconst struct lan9303_phy_ops *ops;\n> +\tbool is_bridged; /* true if port 1 and 2 is bridged */\n> };\n> \n> extern const struct regmap_access_table lan9303_register_set;\n\nPlease use the checkpatch.pl script to ensure your patch respects the\nkernel conventions before submitting, it can spot nice stuffs!\n\nI use a Git alias(*) to check a commit which does basically this:\n\n git format-patch --stdout -1 | ./scripts/checkpatch.pl -\n\n\n(*) in details, especially convenient during interactive rebases:\n\n $ git config alias.checkcommit '!f () { git format-patch --stdout -1 ${1:-HEAD} | ./scripts/checkpatch.pl - ; }; f'\n $ git checkcommit # i.e. current one\n $ git checkcommit HEAD^^\n $ git checkcommit d329ac88eb21\n ...\n\n\nThanks,\n\n Vivien","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xyfDN5w6mz9s7g\n\tfor ;\n\tFri, 22 Sep 2017 00:31:00 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751925AbdIUOaa (ORCPT );\n\tThu, 21 Sep 2017 10:30:30 -0400","from mail.savoirfairelinux.com ([208.88.110.44]:52754 \"EHLO\n\tmail.savoirfairelinux.com\" rhost-flags-OK-OK-OK-OK) by\n\tvger.kernel.org with ESMTP id S1751885AbdIUOa3 (ORCPT\n\t); Thu, 21 Sep 2017 10:30:29 -0400","from localhost (localhost [127.0.0.1])\n\tby mail.savoirfairelinux.com (Postfix) with ESMTP id 9289F9C2A1C;\n\tThu, 21 Sep 2017 10:30:28 -0400 (EDT)","from mail.savoirfairelinux.com ([127.0.0.1])\n\tby localhost (mail.savoirfairelinux.com [127.0.0.1]) (amavisd-new,\n\tport 10032)\n\twith ESMTP id VQHKq_n6vKVO; Thu, 21 Sep 2017 10:30:27 -0400 (EDT)","from localhost (localhost [127.0.0.1])\n\tby mail.savoirfairelinux.com (Postfix) with ESMTP id 737E99C2B22;\n\tThu, 21 Sep 2017 10:30:27 -0400 (EDT)","from mail.savoirfairelinux.com ([127.0.0.1])\n\tby localhost (mail.savoirfairelinux.com [127.0.0.1]) (amavisd-new,\n\tport 10026)\n\twith ESMTP id 4UH86QqpDhwI; Thu, 21 Sep 2017 10:30:27 -0400 (EDT)","from localhost (modemcable249.105-163-184.mc.videotron.ca\n\t[184.163.105.249])\n\tby mail.savoirfairelinux.com (Postfix) with ESMTPSA id 3C7D99C2A1C;\n\tThu, 21 Sep 2017 10:30:27 -0400 (EDT)"],"X-Virus-Scanned":"amavisd-new at mail.savoirfairelinux.com","From":"Vivien Didelot ","To":"Egil Hjelmeland , andrew@lunn.ch,\n\tf.fainelli@gmail.com, netdev@vger.kernel.org,\n\tlinux-kernel@vger.kernel.org","Cc":"Egil Hjelmeland ","Subject":"Re: [PATCH net-next 2/2] net: dsa: lan9303: Add basic offloading of\n\tunicast traffic","In-Reply-To":"<20170921094139.4250-3-privat@egil-hjelmeland.no>","References":"<20170921094139.4250-1-privat@egil-hjelmeland.no>\n\t<20170921094139.4250-3-privat@egil-hjelmeland.no>","Date":"Thu, 21 Sep 2017 10:26:54 -0400","Message-ID":"<87k20sqg9d.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>","MIME-Version":"1.0","Content-Type":"text/plain","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1773310,"web_url":"http://patchwork.ozlabs.org/comment/1773310/","msgid":"","list_archive_url":null,"date":"2017-09-22T07:06:04","subject":"Re: [PATCH net-next 2/2] net: dsa: lan9303: Add basic offloading of\n\tunicast traffic","submitter":{"id":72044,"url":"http://patchwork.ozlabs.org/api/people/72044/","name":"Egil Hjelmeland","email":"privat@egil-hjelmeland.no"},"content":"Den 21. sep. 2017 16:21, skrev Andrew Lunn:\n> Hi Egil\n> \n>> +static void lan9303_bridge_ports(struct lan9303 *chip)\n>> +{\n>> +\t/* ports bridged: remove mirroring */\n>> +\tlan9303_write_switch_reg(chip, LAN9303_SWE_PORT_MIRROR, 0);\n>> +}\n> \n> Could you replace the 0 with something symbolic which makes this\n> easier to understand.\n> \n> #define LAN9303_SWE_PORT_MIRROR_DISABLED 0\n> \n\nOK\n\n>> +\n>> static int lan9303_handle_reset(struct lan9303 *chip)\n>> {\n>> \tif (!chip->reset_gpio)\n>> @@ -844,6 +866,69 @@ static void lan9303_port_disable(struct dsa_switch *ds, int port,\n>> \t}\n>> }\n>> \n>> +static int lan9303_port_bridge_join(struct dsa_switch *ds, int port,\n>> +\t\t\t\t struct net_device *br)\n>> +{\n>> +\tstruct lan9303 *chip = ds->priv;\n>> +\n>> +\tdev_dbg(chip->dev, \"%s(port %d)\\n\", __func__, port);\n>> +\tif (ds->ports[1].bridge_dev == ds->ports[2].bridge_dev) {\n>> +\t\tlan9303_bridge_ports(chip);\n>> +\t\tchip->is_bridged = true; /* unleash stp_state_set() */\n>> +\t}\n>> +\n>> +\treturn 0;\n>> +}\n>> +\n>> +static void lan9303_port_bridge_leave(struct dsa_switch *ds, int port,\n>> +\t\t\t\t struct net_device *br)\n>> +{\n>> +\tstruct lan9303 *chip = ds->priv;\n>> +\n>> +\tdev_dbg(chip->dev, \"%s(port %d)\\n\", __func__, port);\n>> +\tif (chip->is_bridged) {\n>> +\t\tlan9303_separate_ports(chip);\n>> +\t\tchip->is_bridged = false;\n>> +\t}\n>> +}\n>> +\n>> +static void lan9303_port_stp_state_set(struct dsa_switch *ds, int port,\n>> +\t\t\t\t u8 state)\n>> +{\n>> +\tint portmask, portstate;\n>> +\tstruct lan9303 *chip = ds->priv;\n>> +\n>> +\tdev_dbg(chip->dev, \"%s(port %d, state %d)\\n\",\n>> +\t\t__func__, port, state);\n>> +\tif (!chip->is_bridged)\n>> +\t\treturn; /* touching SWE_PORT_STATE will break port separation */\n> \n> I'm wondering how this is supposed to work. Please add a good comment\n> here, since the hardware is forcing you to do something odd.\n> \n> Maybe it would be a good idea to save the STP state in chip. And then\n> when chip->is_bridged is set true, change the state in the hardware to\n> the saved value?\n> \n> What happens when port 0 is added to the bridge, there is then a\n> minute pause and then port 1 is added? I would expect that as soon as\n> port 0 is added, the STP state machine for port 0 will start and move\n> into listening and then forwarding. Due to hardware limitations it\n> looks like you cannot do this. So what state is the hardware\n> effectively in? Blocking? Forwarding?\n> \n> Then port 1 is added. You can then can respect the states. port 1 will\n> do blocking->listening->forwarding, but what about port 0? The calls\n> won't get repeated? How does it transition to forwarding?\n> \n> Andrew\n> \n\nI see your point with the \"minute pause\" argument. Although a bit\ncontrived use case, it is easy to fix by caching the STP state, as\nyou suggest. So I can do that.\n\nThe port separation method is from the original version of the driver,\nnot by me.\n\nI have read through the datasheet to see if there are other ways\nto make port separation, but I could not find anything.\nIf anybody care to read through the 300+ page lan9303.pdf and prove\nme wrong, I am happy to do it differently.\n\nHow does other DSA HW chips handle port separation? Knowing that\ncould perhaps help me know what to look for.\n\nEgil\n'\n\n>> +\n>> +\tswitch (state) {\n>> +\tcase BR_STATE_DISABLED:\n>> +\t\tportstate = LAN9303_SWE_PORT_STATE_DISABLED_PORT0;\n>> +\t\tbreak;\n>> +\tcase BR_STATE_BLOCKING:\n>> +\tcase BR_STATE_LISTENING:\n>> +\t\tportstate = LAN9303_SWE_PORT_STATE_BLOCKING_PORT0;\n>> +\t\tbreak;\n>> +\tcase BR_STATE_LEARNING:\n>> +\t\tportstate = LAN9303_SWE_PORT_STATE_LEARNING_PORT0;\n>> +\t\tbreak;\n>> +\tcase BR_STATE_FORWARDING:\n>> +\t\tportstate = LAN9303_SWE_PORT_STATE_FORWARDING_PORT0;\n>> +\t\tbreak;\n>> +\tdefault:\n>> +\t\tportstate = LAN9303_SWE_PORT_STATE_DISABLED_PORT0;\n>> +\t\tdev_err(chip->dev, \"unknown stp state: port %d, state %d\\n\",\n>> +\t\t\tport, state);\n>> +\t}\n>> +\n>> +\tportmask = 0x3 << (port * 2);\n>> +\tportstate <<= (port * 2);\n>> +\tlan9303_write_switch_reg_mask(chip, LAN9303_SWE_PORT_STATE,\n>> +\t\t\t\t portstate, portmask);\n>> +}\n>","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xz4Kc4Hf3z9sNw\n\tfor ;\n\tFri, 22 Sep 2017 17:07:00 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751862AbdIVHGt (ORCPT );\n\tFri, 22 Sep 2017 03:06:49 -0400","from aibo.runbox.com ([91.220.196.211]:57908 \"EHLO aibo.runbox.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751795AbdIVHGr (ORCPT );\n\tFri, 22 Sep 2017 03:06:47 -0400","from [10.9.9.210] (helo=mailfront10.runbox.com)\n\tby mailtransmit03.runbox with esmtp (Exim 4.86_2)\n\t(envelope-from )\n\tid 1dvI2t-0005wp-Nx; Fri, 22 Sep 2017 09:06:43 +0200","from 93.89.126.26.ip.vitnett.no ([93.89.126.26]\n\thelo=[192.168.202.41])\n\tby mailfront10.runbox.com with esmtpsa (uid:646232 )\n\t(TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82)\n\tid 1dvI2G-0000OK-Hs; Fri, 22 Sep 2017 09:06:04 +0200"],"Subject":"Re: [PATCH net-next 2/2] net: dsa: lan9303: Add basic offloading of\n\tunicast traffic","To":"Andrew Lunn ","Cc":"vivien.didelot@savoirfairelinux.com, f.fainelli@gmail.com,\n\tnetdev@vger.kernel.org, linux-kernel@vger.kernel.org","References":"<20170921094139.4250-1-privat@egil-hjelmeland.no>\n\t<20170921094139.4250-3-privat@egil-hjelmeland.no>\n\t<20170921142127.GB27589@lunn.ch>","From":"Egil Hjelmeland ","Message-ID":"","Date":"Fri, 22 Sep 2017 09:06:04 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20170921142127.GB27589@lunn.ch>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1773316,"web_url":"http://patchwork.ozlabs.org/comment/1773316/","msgid":"<194908d7-20ce-5779-0cb8-be656197d3ec@egil-hjelmeland.no>","list_archive_url":null,"date":"2017-09-22T07:23:39","subject":"Re: [PATCH net-next 2/2] net: dsa: lan9303: Add basic offloading of\n\tunicast traffic","submitter":{"id":72044,"url":"http://patchwork.ozlabs.org/api/people/72044/","name":"Egil Hjelmeland","email":"privat@egil-hjelmeland.no"},"content":"Den 21. sep. 2017 16:26, skrev Vivien Didelot:\n> Hi Egil,\n> \n> Egil Hjelmeland writes:\n> \n>> When both user ports are joined to the same bridge, the normal\n>> HW MAC learning is enabled. This means that unicast traffic is forwarded\n>> in HW.\n>>\n>> If one of the user ports leave the bridge,\n>> the ports goes back to the initial separated operation.\n>>\n>> Port separation relies on disabled HW MAC learning. Hence the condition\n>> that both ports must join same bridge.\n>>\n>> Add brigde methods port_bridge_join, port_bridge_leave and\n>> port_stp_state_set.\n>>\n>> Signed-off-by: Egil Hjelmeland \n> \n> Styling nitpicks below, other than that, the patch LGTM:\n> \n> Reviewed-by: Vivien Didelot \n> \n>> #include \n>> #include \n>> #include \n>> +#include \n> \n> It's nice to order header inclusions alphabetically.\n> \n>> \n>> #include \"lan9303.h\"\n>> \n>> @@ -146,6 +147,7 @@\n>> # define LAN9303_SWE_PORT_STATE_FORWARDING_PORT0 (0)\n>> # define LAN9303_SWE_PORT_STATE_LEARNING_PORT0 BIT(1)\n>> # define LAN9303_SWE_PORT_STATE_BLOCKING_PORT0 BIT(0)\n>> +# define LAN9303_SWE_PORT_STATE_DISABLED_PORT0 (3)\n>> #define LAN9303_SWE_PORT_MIRROR 0x1846\n>> # define LAN9303_SWE_PORT_MIRROR_SNIFF_ALL BIT(8)\n>> # define LAN9303_SWE_PORT_MIRROR_SNIFFER_PORT2 BIT(7)\n>> @@ -431,6 +433,20 @@ static int lan9303_read_switch_reg(struct lan9303 *chip, u16 regnum, u32 *val)\n>> \treturn ret;\n>> }\n>> \n>> +static int lan9303_write_switch_reg_mask(\n>> +\tstruct lan9303 *chip, u16 regnum, u32 val, u32 mask)\n> \n> That is unlikely to respect the Kernel Coding Style. Please fill the\n> line as much as possible and align with the opening parenthesis:\n> \n> static int lan9303_write_switch_reg_mask(struct lan9303 *chip, u16 regnum,\n> u32 val, u32 mask)\n> \nOK. Probably this function will go away in v2 due to Andrews comment.\n\n>> +{\n>> +\tint ret;\n>> +\tu32 reg;\n>> +\n>> +\tret = lan9303_read_switch_reg(chip, regnum, ®);\n>> +\tif (ret)\n>> +\t\treturn ret;\n>> +\treg = (reg & ~mask) | val;\n>> +\n>> +\treturn lan9303_write_switch_reg(chip, regnum, reg);\n>> +}\n> \n> ...\n> \n>> +\n>> +\tportmask = 0x3 << (port * 2);\n>> +\tportstate <<= (port * 2);\n> \n> Unnecessary alignment, please remove the extra space characters.\n> \n\nI think the alignment makes the logic more clear.\n\n\n>> +\tlan9303_write_switch_reg_mask(chip, LAN9303_SWE_PORT_STATE,\n>> +\t\t\t\t portstate, portmask);\n>> +}\n>> +\n>> static const struct dsa_switch_ops lan9303_switch_ops = {\n>> \t.get_tag_protocol = lan9303_get_tag_protocol,\n>> \t.setup = lan9303_setup,\n>> @@ -855,6 +940,9 @@ static const struct dsa_switch_ops lan9303_switch_ops = {\n>> \t.get_sset_count = lan9303_get_sset_count,\n>> \t.port_enable = lan9303_port_enable,\n>> \t.port_disable = lan9303_port_disable,\n>> +\t.port_bridge_join = lan9303_port_bridge_join,\n>> +\t.port_bridge_leave = lan9303_port_bridge_leave,\n>> +\t.port_stp_state_set = lan9303_port_stp_state_set,\n> \n> Same here, alignment unnecessary, especially since the rest of the\n> structure does not do that.\n> \n>> };\n>> \n>> static int lan9303_register_switch(struct lan9303 *chip)\n>> diff --git a/drivers/net/dsa/lan9303.h b/drivers/net/dsa/lan9303.h\n>> index 4d8be555ff4d..5be246f05965 100644\n>> --- a/drivers/net/dsa/lan9303.h\n>> +++ b/drivers/net/dsa/lan9303.h\n>> @@ -21,6 +21,7 @@ struct lan9303 {\n>> \tstruct dsa_switch *ds;\n>> \tstruct mutex indirect_mutex; /* protect indexed register access */\n>> \tconst struct lan9303_phy_ops *ops;\n>> +\tbool is_bridged; /* true if port 1 and 2 is bridged */\n>> };\n>> \n>> extern const struct regmap_access_table lan9303_register_set;\n> \n> Please use the checkpatch.pl script to ensure your patch respects the\n> kernel conventions before submitting, it can spot nice stuffs!\n\nI have checked _every_ patch with checkpatch.pl and weeded all warnings\nbefore I submitted them.\n\n> \n> I use a Git alias(*) to check a commit which does basically this:\n> \n> git format-patch --stdout -1 | ./scripts/checkpatch.pl -\n> \n> \n> (*) in details, especially convenient during interactive rebases:\n> \n> $ git config alias.checkcommit '!f () { git format-patch --stdout -1 ${1:-HEAD} | ./scripts/checkpatch.pl - ; }; f'\n> $ git checkcommit # i.e. current one\n> $ git checkcommit HEAD^^\n> $ git checkcommit d329ac88eb21\n> ...\n> \n> \n> Thanks,\n> \n> Vivien\n>","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xz4jP1zm5z9sNw\n\tfor ;\n\tFri, 22 Sep 2017 17:24:09 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751980AbdIVHX6 (ORCPT );\n\tFri, 22 Sep 2017 03:23:58 -0400","from aibo.runbox.com ([91.220.196.211]:59154 \"EHLO aibo.runbox.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751795AbdIVHXy (ORCPT );\n\tFri, 22 Sep 2017 03:23:54 -0400","from [10.9.9.211] (helo=mailfront11.runbox.com)\n\tby mailtransmit03.runbox with esmtp (Exim 4.86_2)\n\t(envelope-from )\n\tid 1dvIJT-0007IO-Ab; Fri, 22 Sep 2017 09:23:51 +0200","from 93.89.126.26.ip.vitnett.no ([93.89.126.26]\n\thelo=[192.168.202.41])\n\tby mailfront11.runbox.com with esmtpsa (uid:646232 )\n\t(TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82)\n\tid 1dvIJH-0007yH-Lz; Fri, 22 Sep 2017 09:23:39 +0200"],"Subject":"Re: [PATCH net-next 2/2] net: dsa: lan9303: Add basic offloading of\n\tunicast traffic","To":"Vivien Didelot ,\n\tandrew@lunn.ch, f.fainelli@gmail.com, netdev@vger.kernel.org,\n\tlinux-kernel@vger.kernel.org","References":"<20170921094139.4250-1-privat@egil-hjelmeland.no>\n\t<20170921094139.4250-3-privat@egil-hjelmeland.no>\n\t<87k20sqg9d.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>","From":"Egil Hjelmeland ","Message-ID":"<194908d7-20ce-5779-0cb8-be656197d3ec@egil-hjelmeland.no>","Date":"Fri, 22 Sep 2017 09:23:39 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<87k20sqg9d.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1773846,"web_url":"http://patchwork.ozlabs.org/comment/1773846/","msgid":"<20170922200810.GJ3470@lunn.ch>","list_archive_url":null,"date":"2017-09-22T20:08:10","subject":"Re: [PATCH net-next 2/2] net: dsa: lan9303: Add basic offloading of\n\tunicast traffic","submitter":{"id":13608,"url":"http://patchwork.ozlabs.org/api/people/13608/","name":"Andrew Lunn","email":"andrew@lunn.ch"},"content":"> >I'm wondering how this is supposed to work. Please add a good comment\n> >here, since the hardware is forcing you to do something odd.\n> >\n> >Maybe it would be a good idea to save the STP state in chip. And then\n> >when chip->is_bridged is set true, change the state in the hardware to\n> >the saved value?\n> >\n> >What happens when port 0 is added to the bridge, there is then a\n> >minute pause and then port 1 is added? I would expect that as soon as\n> >port 0 is added, the STP state machine for port 0 will start and move\n> >into listening and then forwarding. Due to hardware limitations it\n> >looks like you cannot do this. So what state is the hardware\n> >effectively in? Blocking? Forwarding?\n> >\n> >Then port 1 is added. You can then can respect the states. port 1 will\n> >do blocking->listening->forwarding, but what about port 0? The calls\n> >won't get repeated? How does it transition to forwarding?\n> >\n> > Andrew\n> >\n> \n> I see your point with the \"minute pause\" argument. Although a bit\n> contrived use case, it is easy to fix by caching the STP state, as\n> you suggest. So I can do that.\n\nI don't think it is contrived. I've done bridge configuration by hand\nfor testing purposes. I've also set the forwarding delay to very small\nvalues, so there is a clear race condition here.\n\n> How does other DSA HW chips handle port separation? Knowing that\n> could perhaps help me know what to look for.\n\nThey have better hardware :-)\n\nGenerally each port is totally independent. You can change the STP\nstate per port without restrictions.\n\n Andrew","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xzPgK2vl2z9s82\n\tfor ;\n\tSat, 23 Sep 2017 06:08:29 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752571AbdIVUIQ (ORCPT );\n\tFri, 22 Sep 2017 16:08:16 -0400","from vps0.lunn.ch ([185.16.172.187]:52879 \"EHLO vps0.lunn.ch\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1752416AbdIVUIO (ORCPT );\n\tFri, 22 Sep 2017 16:08:14 -0400","from andrew by vps0.lunn.ch with local (Exim 4.84_2)\n\t(envelope-from )\n\tid 1dvUF8-0002W0-5P; Fri, 22 Sep 2017 22:08:10 +0200"],"Date":"Fri, 22 Sep 2017 22:08:10 +0200","From":"Andrew Lunn ","To":"Egil Hjelmeland ","Cc":"vivien.didelot@savoirfairelinux.com, f.fainelli@gmail.com,\n\tnetdev@vger.kernel.org, linux-kernel@vger.kernel.org","Subject":"Re: [PATCH net-next 2/2] net: dsa: lan9303: Add basic offloading of\n\tunicast traffic","Message-ID":"<20170922200810.GJ3470@lunn.ch>","References":"<20170921094139.4250-1-privat@egil-hjelmeland.no>\n\t<20170921094139.4250-3-privat@egil-hjelmeland.no>\n\t<20170921142127.GB27589@lunn.ch>\n\t","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"","User-Agent":"Mutt/1.5.23 (2014-03-12)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1774010,"web_url":"http://patchwork.ozlabs.org/comment/1774010/","msgid":"<2c5fec6d-18b3-97e9-dd64-85560382d2f7@egil-hjelmeland.no>","list_archive_url":null,"date":"2017-09-23T09:58:01","subject":"Re: [PATCH net-next 2/2] net: dsa: lan9303: Add basic offloading of\n\tunicast traffic","submitter":{"id":72044,"url":"http://patchwork.ozlabs.org/api/people/72044/","name":"Egil Hjelmeland","email":"privat@egil-hjelmeland.no"},"content":"Den 22. sep. 2017 22:08, skrev Andrew Lunn:\n>>> I'm wondering how this is supposed to work. Please add a good comment\n>>> here, since the hardware is forcing you to do something odd.\n>>>\n>>> Maybe it would be a good idea to save the STP state in chip. And then\n>>> when chip->is_bridged is set true, change the state in the hardware to\n>>> the saved value?\n>>>\n>>> What happens when port 0 is added to the bridge, there is then a\n>>> minute pause and then port 1 is added? I would expect that as soon as\n>>> port 0 is added, the STP state machine for port 0 will start and move\n>>> into listening and then forwarding. Due to hardware limitations it\n>>> looks like you cannot do this. So what state is the hardware\n>>> effectively in? Blocking? Forwarding?\n>>>\n>>> Then port 1 is added. You can then can respect the states. port 1 will\n>>> do blocking->listening->forwarding, but what about port 0? The calls\n>>> won't get repeated? How does it transition to forwarding?\n>>>\n>>> Andrew\n>>>\n>>\n>> I see your point with the \"minute pause\" argument. Although a bit\n>> contrived use case, it is easy to fix by caching the STP state, as\n>> you suggest. So I can do that.\n> \n> I don't think it is contrived. I've done bridge configuration by hand\n> for testing purposes. I've also set the forwarding delay to very small\n> values, so there is a clear race condition here.\n> \n>> How does other DSA HW chips handle port separation? Knowing that\n>> could perhaps help me know what to look for.\n> \n> They have better hardware :-)\n> \n> Generally each port is totally independent. You can change the STP\n> state per port without restrictions.\n> \nWe can indeed change the STP state per lan9303 port \"without\nrestrictions\".\n\nThe point is: Once both external ports are in \"forwarding\", I see no way\nto prevent traffic flowing directly between the external ports.\n\n\n> Andrew\n> \n\nEgil","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xzm5F16mWz9tX4\n\tfor ;\n\tSat, 23 Sep 2017 19:58:41 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751149AbdIWJ62 (ORCPT );\n\tSat, 23 Sep 2017 05:58:28 -0400","from aibo.runbox.com ([91.220.196.211]:37738 \"EHLO aibo.runbox.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1750778AbdIWJ60 (ORCPT );\n\tSat, 23 Sep 2017 05:58:26 -0400","from [10.9.9.212] (helo=mailfront12.runbox.com)\n\tby mailtransmit02.runbox with esmtp (Exim 4.86_2)\n\t(envelope-from )\n\tid 1dvhCY-0004PS-5z; Sat, 23 Sep 2017 11:58:22 +0200","from 93.89.126.26.ip.vitnett.no ([93.89.126.26]\n\thelo=[192.168.202.41])\n\tby mailfront12.runbox.com with esmtpsa (uid:646232 )\n\t(TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82)\n\tid 1dvhCE-0000mv-Dr; Sat, 23 Sep 2017 11:58:02 +0200"],"Subject":"Re: [PATCH net-next 2/2] net: dsa: lan9303: Add basic offloading of\n\tunicast traffic","To":"Andrew Lunn ","Cc":"vivien.didelot@savoirfairelinux.com, f.fainelli@gmail.com,\n\tnetdev@vger.kernel.org, linux-kernel@vger.kernel.org","References":"<20170921094139.4250-1-privat@egil-hjelmeland.no>\n\t<20170921094139.4250-3-privat@egil-hjelmeland.no>\n\t<20170921142127.GB27589@lunn.ch>\n\t\n\t<20170922200810.GJ3470@lunn.ch>","From":"Egil Hjelmeland ","Message-ID":"<2c5fec6d-18b3-97e9-dd64-85560382d2f7@egil-hjelmeland.no>","Date":"Sat, 23 Sep 2017 11:58:01 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20170922200810.GJ3470@lunn.ch>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1774026,"web_url":"http://patchwork.ozlabs.org/comment/1774026/","msgid":"<20170923143123.GA21228@lunn.ch>","list_archive_url":null,"date":"2017-09-23T14:31:23","subject":"Re: [PATCH net-next 2/2] net: dsa: lan9303: Add basic offloading of\n\tunicast traffic","submitter":{"id":13608,"url":"http://patchwork.ozlabs.org/api/people/13608/","name":"Andrew Lunn","email":"andrew@lunn.ch"},"content":"> The point is: Once both external ports are in \"forwarding\", I see no way\n> to prevent traffic flowing directly between the external ports.\n\nGenerally, there are port vectors. Port X can send frames only to Port\nY.\n\nIf you don't have that, there are possibilities with VLANs. Each port\nis given a unique VLAN. All incoming untagged traffic is tagged with\nthe VLAN. You just need to keep the VLAN separated and add/remove the\nVLAN tag in the dsa tag driver.\n\n Andrew","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xzt8b5SKBz9tX9\n\tfor ;\n\tSun, 24 Sep 2017 00:31:59 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751030AbdIWObd (ORCPT );\n\tSat, 23 Sep 2017 10:31:33 -0400","from vps0.lunn.ch ([185.16.172.187]:53214 \"EHLO vps0.lunn.ch\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1750766AbdIWObb (ORCPT );\n\tSat, 23 Sep 2017 10:31:31 -0400","from andrew by vps0.lunn.ch with local (Exim 4.84_2)\n\t(envelope-from )\n\tid 1dvlSl-0005Yc-VW; Sat, 23 Sep 2017 16:31:23 +0200"],"Date":"Sat, 23 Sep 2017 16:31:23 +0200","From":"Andrew Lunn ","To":"Egil Hjelmeland ","Cc":"vivien.didelot@savoirfairelinux.com, f.fainelli@gmail.com,\n\tnetdev@vger.kernel.org, linux-kernel@vger.kernel.org","Subject":"Re: [PATCH net-next 2/2] net: dsa: lan9303: Add basic offloading of\n\tunicast traffic","Message-ID":"<20170923143123.GA21228@lunn.ch>","References":"<20170921094139.4250-1-privat@egil-hjelmeland.no>\n\t<20170921094139.4250-3-privat@egil-hjelmeland.no>\n\t<20170921142127.GB27589@lunn.ch>\n\t\n\t<20170922200810.GJ3470@lunn.ch>\n\t<2c5fec6d-18b3-97e9-dd64-85560382d2f7@egil-hjelmeland.no>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<2c5fec6d-18b3-97e9-dd64-85560382d2f7@egil-hjelmeland.no>","User-Agent":"Mutt/1.5.23 (2014-03-12)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1774313,"web_url":"http://patchwork.ozlabs.org/comment/1774313/","msgid":"<1e8ac407-bf63-5ccc-fe23-4af0ea83923d@egil-hjelmeland.no>","list_archive_url":null,"date":"2017-09-24T22:02:06","subject":"Re: [PATCH net-next 2/2] net: dsa: lan9303: Add basic offloading of\n\tunicast traffic","submitter":{"id":72044,"url":"http://patchwork.ozlabs.org/api/people/72044/","name":"Egil Hjelmeland","email":"privat@egil-hjelmeland.no"},"content":"Den 23. sep. 2017 16:31, skrev Andrew Lunn:\n>> The point is: Once both external ports are in \"forwarding\", I see no way\n>> to prevent traffic flowing directly between the external ports.\n> \n> Generally, there are port vectors. Port X can send frames only to Port\n> Y.\n> \n> If you don't have that, there are possibilities with VLANs. Each port\n> is given a unique VLAN. All incoming untagged traffic is tagged with\n> the VLAN. You just need to keep the VLAN separated and add/remove the\n> VLAN tag in the dsa tag driver.\n> \n> Andrew\n> \nThanks. The lan9303 has nothing like \"port vectors\". The port tagging\nscheme is VLAN based, but is does not prevent direct forwarding between\nthe external ports.\n\nIn order to not break the strong port separation in the current driver;\nI will stick to my solution, and only add caching of the STP state\nregister.\n\nEgil","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3y0h5v0x5wz9sRW\n\tfor ;\n\tMon, 25 Sep 2017 08:02:27 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1753239AbdIXWCR (ORCPT );\n\tSun, 24 Sep 2017 18:02:17 -0400","from aibo.runbox.com ([91.220.196.211]:45090 \"EHLO aibo.runbox.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1752992AbdIXWCP (ORCPT );\n\tSun, 24 Sep 2017 18:02:15 -0400","from [10.9.9.211] (helo=mailfront11.runbox.com)\n\tby mailtransmit03.runbox with esmtp (Exim 4.86_2)\n\t(envelope-from )\n\tid 1dwEyX-0002px-Ih; Mon, 25 Sep 2017 00:02:09 +0200","from 93.89.126.26.ip.vitnett.no ([93.89.126.26]\n\thelo=[192.168.202.41])\n\tby mailfront11.runbox.com with esmtpsa (uid:646232 )\n\t(TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82)\n\tid 1dwEyU-00087j-Rw; Mon, 25 Sep 2017 00:02:06 +0200"],"Subject":"Re: [PATCH net-next 2/2] net: dsa: lan9303: Add basic offloading of\n\tunicast traffic","To":"Andrew Lunn ","Cc":"vivien.didelot@savoirfairelinux.com, f.fainelli@gmail.com,\n\tnetdev@vger.kernel.org, linux-kernel@vger.kernel.org","References":"<20170921094139.4250-1-privat@egil-hjelmeland.no>\n\t<20170921094139.4250-3-privat@egil-hjelmeland.no>\n\t<20170921142127.GB27589@lunn.ch>\n\t\n\t<20170922200810.GJ3470@lunn.ch>\n\t<2c5fec6d-18b3-97e9-dd64-85560382d2f7@egil-hjelmeland.no>\n\t<20170923143123.GA21228@lunn.ch>","From":"Egil Hjelmeland ","Message-ID":"<1e8ac407-bf63-5ccc-fe23-4af0ea83923d@egil-hjelmeland.no>","Date":"Mon, 25 Sep 2017 00:02:06 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"<20170923143123.GA21228@lunn.ch>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Language":"en-US","Content-Transfer-Encoding":"7bit","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}}]