[{"id":1764966,"web_url":"http://patchwork.ozlabs.org/comment/1764966/","msgid":"<20170907214834.GT11248@lunn.ch>","list_archive_url":null,"date":"2017-09-07T21:48:34","subject":"Re: [PATCH RFC 6/6] Modify tag_ksz.c to support other KSZ switch\n\tdrivers","submitter":{"id":13608,"url":"http://patchwork.ozlabs.org/api/people/13608/","name":"Andrew Lunn","email":"andrew@lunn.ch"},"content":"On Thu, Sep 07, 2017 at 09:09:30PM +0000, Tristram.Ha@microchip.com wrote:\n> From: Tristram Ha \n> \n> The KSZ tail tag code can be used by different KSZ switch drivers.\n> \n> Signed-off-by: Tristram Ha \n> ---\n> diff --git a/net/dsa/tag_ksz.c b/net/dsa/tag_ksz.c index 010ca0a..d5faf14 100644\n> --- a/net/dsa/tag_ksz.c\n> +++ b/net/dsa/tag_ksz.c\n> @@ -13,35 +13,21 @@\n> #include \n> #include \n> #include \"dsa_priv.h\"\n> -\n> -/* For Ingress (Host -> KSZ), 2 bytes are added before FCS.\n> - * ---------------------------------------------------------------------------\n> - * DA(6bytes)|SA(6bytes)|....|Data(nbytes)|tag0(1byte)|tag1(1byte)|FCS(4bytes)\n> - * ---------------------------------------------------------------------------\n> - * tag0 : Prioritization (not used now)\n> - * tag1 : each bit represents port (eg, 0x01=port1, 0x02=port2, 0x10=port5)\n> - *\n> - * For Egress (KSZ -> Host), 1 byte is added before FCS.\n> - * ---------------------------------------------------------------------------\n> - * DA(6bytes)|SA(6bytes)|....|Data(nbytes)|tag0(1byte)|FCS(4bytes)\n> - * ---------------------------------------------------------------------------\n> - * tag0 : zero-based value represents port\n> - *\t (eg, 0x00=port1, 0x02=port3, 0x06=port7)\n> - */\n> -\n> -#define\tKSZ_INGRESS_TAG_LEN\t2\n> -#define\tKSZ_EGRESS_TAG_LEN\t1\n> +#include \"../../drivers/net/dsa/microchip/ksz_priv.h\"\n\nNo.\n\nMove the header file to somewhere under include/linux. You can split\nit into private and public parts if you want, and just put the public\nbits in include/linux.\n\n> static struct sk_buff *ksz_xmit(struct sk_buff *skb, struct net_device *dev) {\n> \tstruct dsa_slave_priv *p = netdev_priv(dev);\n> +\tstruct dsa_switch *ds = p->dp->ds;\n> +\tstruct ksz_device *swdev = ds->priv;\n> \tstruct sk_buff *nskb;\n> +\tint len;\n> \tint padlen;\n> -\tu8 *tag;\n> \n> \tpadlen = (skb->len >= ETH_ZLEN) ? 0 : ETH_ZLEN - skb->len;\n> \n> -\tif (skb_tailroom(skb) >= padlen + KSZ_INGRESS_TAG_LEN) {\n> +\tlen = swdev->dev_ops->get_tx_len(swdev);\n\nThis is ugly. We have a clean separation between a switch driver and a\ntag driver. Here you are mixing them together. Don't. Look at the\nmailing lists for what Florian and I suggested to Pavel. It will also\nsolve your include file issue above.\n\n\t 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 3xpDc05GFqz9sBZ\n\tfor ;\n\tFri, 8 Sep 2017 07:48:48 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S932105AbdIGVsh (ORCPT );\n\tThu, 7 Sep 2017 17:48:37 -0400","from vps0.lunn.ch ([178.209.37.122]:60110 \"EHLO vps0.lunn.ch\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1752689AbdIGVsg (ORCPT );\n\tThu, 7 Sep 2017 17:48:36 -0400","from andrew by vps0.lunn.ch with local (Exim 4.84_2)\n\t(envelope-from )\n\tid 1dq4f4-0007kI-61; Thu, 07 Sep 2017 23:48:34 +0200"],"Date":"Thu, 7 Sep 2017 23:48:34 +0200","From":"Andrew Lunn ","To":"Tristram.Ha@microchip.com","Cc":"muvarov@gmail.com, pavel@ucw.cz, nathan.leigh.conrad@gmail.com,\n\tvivien.didelot@savoirfairelinux.com, f.fainelli@gmail.com,\n\tnetdev@vger.kernel.org, linux-kernel@vger.kernel.org,\n\tWoojung.Huh@microchip.com","Subject":"Re: [PATCH RFC 6/6] Modify tag_ksz.c to support other KSZ switch\n\tdrivers","Message-ID":"<20170907214834.GT11248@lunn.ch>","References":"<93AF473E2DA327428DE3D46B72B1E9FD41121901@CHN-SV-EXMX02.mchp-main.com>\n\t<93AF473E2DA327428DE3D46B72B1E9FD41121A22@CHN-SV-EXMX02.mchp-main.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<93AF473E2DA327428DE3D46B72B1E9FD41121A22@CHN-SV-EXMX02.mchp-main.com>","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":1770446,"web_url":"http://patchwork.ozlabs.org/comment/1770446/","msgid":"<93AF473E2DA327428DE3D46B72B1E9FD41124D2E@CHN-SV-EXMX02.mchp-main.com>","list_archive_url":null,"date":"2017-09-18T19:38:03","subject":"RE: [PATCH RFC 6/6] Modify tag_ksz.c to support other KSZ switch\n\tdrivers","submitter":{"id":72262,"url":"http://patchwork.ozlabs.org/api/people/72262/","name":"","email":"Tristram.Ha@microchip.com"},"content":"Sorry for the late response.\n\n> > diff --git a/net/dsa/tag_ksz.c b/net/dsa/tag_ksz.c index 010ca0a..d5faf14\n> 100644\n> > --- a/net/dsa/tag_ksz.c\n> > +++ b/net/dsa/tag_ksz.c\n> > static struct sk_buff *ksz_xmit(struct sk_buff *skb, struct net_device\n> *dev) {\n> > \tstruct dsa_slave_priv *p = netdev_priv(dev);\n> > +\tstruct dsa_switch *ds = p->dp->ds;\n> > +\tstruct ksz_device *swdev = ds->priv;\n> > \tstruct sk_buff *nskb;\n> > +\tint len;\n> > \tint padlen;\n> > -\tu8 *tag;\n> >\n> > \tpadlen = (skb->len >= ETH_ZLEN) ? 0 : ETH_ZLEN - skb->len;\n> >\n> > -\tif (skb_tailroom(skb) >= padlen + KSZ_INGRESS_TAG_LEN) {\n> > +\tlen = swdev->dev_ops->get_tx_len(swdev);\n> \n> This is ugly. We have a clean separation between a switch driver and a\n> tag driver. Here you are mixing them together. Don't. Look at the\n> mailing lists for what Florian and I suggested to Pavel. It will also\n> solve your include file issue above.\n\nIt seems to me all tag_*.c are hard-coded. They do not have access to\nthe switch device and just use the bit definitions defined in the top to\ndo the job.\n\nThis creates a problem for all KSZ switch devices as they have different\ntail tag formats and lengths. There will be potentially 4 additional\nDSA_TAG_PROT_KSZ* just to handle them. Extra files will be added\nwith about the same code.\n\nThe KSZ9477 driver has its own problem as the tail tag length is dynamic\nand not fixed. Right now the function feature that affects this behavior is\nnot turned on and so the problem does not happen.\n\nBut the most important thing is how do we support the offload_fwd_mark\nbit in skb when the only place that has access to skb does not have access to\nthe switch hardware? I thought this bit is important for the new switchdev model.\n\nA little out-of-topic is the MAC driver may have problem receiving the frame if\nthe tail tag length is too big. Most of the MAC drivers have big enough receive\nbuffer or require 64-bytes multiple so there are extra room to accommodate\nthe big tail tag at the end of the frame. Still some MAC drivers use exactly 1500\nMTU and some additional length and may run into this problem. Currently the\nAtmel Cadence MAC driver has this potential problem when certain conditions\nare met.","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 3xwxBL5V2Nz9s81\n\tfor ;\n\tTue, 19 Sep 2017 05:38:18 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751348AbdIRTiH convert rfc822-to-8bit (ORCPT\n\t);\n\tMon, 18 Sep 2017 15:38:07 -0400","from esa5.microchip.iphmx.com ([216.71.150.166]:27890 \"EHLO\n\tesa5.microchip.iphmx.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750714AbdIRTiF (ORCPT\n\t); Mon, 18 Sep 2017 15:38:05 -0400","from smtpout.microchip.com (HELO email.microchip.com)\n\t([198.175.253.82])\n\tby esa5.microchip.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-SHA;\n\t18 Sep 2017 12:38:05 -0700","from CHN-SV-EXMX02.mchp-main.com ([fe80::7dfe:3761:863e:3963]) by\n\tCHN-SV-EXCH06.mchp-main.com ([fe80::5404:4dc9:559:e436%16]) with\n\tmapi id 14.03.0352.000; Mon, 18 Sep 2017 12:38:04 -0700"],"X-IronPort-AV":"E=Sophos;i=\"5.42,414,1500966000\"; d=\"scan'208\";a=\"4801286\"","From":"","To":"","CC":", , ,\n\t, ,\n\t, ,\n\t","Subject":"RE: [PATCH RFC 6/6] Modify tag_ksz.c to support other KSZ switch\n\tdrivers","Thread-Topic":"[PATCH RFC 6/6] Modify tag_ksz.c to support other KSZ switch\n\tdrivers","Thread-Index":"AdMoGgjwWn+O5iRqREClMgoWecPmmwAAub+wABAyfwACFI9x8A==","Date":"Mon, 18 Sep 2017 19:38:03 +0000","Message-ID":"<93AF473E2DA327428DE3D46B72B1E9FD41124D2E@CHN-SV-EXMX02.mchp-main.com>","References":"<93AF473E2DA327428DE3D46B72B1E9FD41121901@CHN-SV-EXMX02.mchp-main.com>\n\t<93AF473E2DA327428DE3D46B72B1E9FD41121A22@CHN-SV-EXMX02.mchp-main.com>\n\t<20170907214834.GT11248@lunn.ch>","In-Reply-To":"<20170907214834.GT11248@lunn.ch>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-originating-ip":"[10.10.215.90]","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"8BIT","MIME-Version":"1.0","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1770457,"web_url":"http://patchwork.ozlabs.org/comment/1770457/","msgid":"<20170918195708.GE15606@lunn.ch>","list_archive_url":null,"date":"2017-09-18T19:57:08","subject":"Re: [PATCH RFC 6/6] Modify tag_ksz.c to support other KSZ switch\n\tdrivers","submitter":{"id":13608,"url":"http://patchwork.ozlabs.org/api/people/13608/","name":"Andrew Lunn","email":"andrew@lunn.ch"},"content":"On Mon, Sep 18, 2017 at 07:38:03PM +0000, Tristram.Ha@microchip.com wrote:\n> Sorry for the late response.\n> \n> > > diff --git a/net/dsa/tag_ksz.c b/net/dsa/tag_ksz.c index 010ca0a..d5faf14\n> > 100644\n> > > --- a/net/dsa/tag_ksz.c\n> > > +++ b/net/dsa/tag_ksz.c\n> > > static struct sk_buff *ksz_xmit(struct sk_buff *skb, struct net_device\n> > *dev) {\n> > > \tstruct dsa_slave_priv *p = netdev_priv(dev);\n> > > +\tstruct dsa_switch *ds = p->dp->ds;\n> > > +\tstruct ksz_device *swdev = ds->priv;\n> > > \tstruct sk_buff *nskb;\n> > > +\tint len;\n> > > \tint padlen;\n> > > -\tu8 *tag;\n> > >\n> > > \tpadlen = (skb->len >= ETH_ZLEN) ? 0 : ETH_ZLEN - skb->len;\n> > >\n> > > -\tif (skb_tailroom(skb) >= padlen + KSZ_INGRESS_TAG_LEN) {\n> > > +\tlen = swdev->dev_ops->get_tx_len(swdev);\n> > \n> > This is ugly. We have a clean separation between a switch driver and a\n> > tag driver. Here you are mixing them together. Don't. Look at the\n> > mailing lists for what Florian and I suggested to Pavel. It will also\n> > solve your include file issue above.\n> \n> It seems to me all tag_*.c are hard-coded. They do not have access to\n> the switch device and just use the bit definitions defined in the top to\n> do the job.\n> \n> This creates a problem for all KSZ switch devices as they have different\n> tail tag formats and lengths. There will be potentially 4 additional\n> DSA_TAG_PROT_KSZ* just to handle them. Extra files will be added\n> with about the same code.\n\nHi Tristram\n\nThink about factoring out the common code into a shared functions.\n\n> But the most important thing is how do we support the offload_fwd_mark\n> bit in skb when the only place that has access to skb does not have access to\n> the switch hardware?\n\nWell, so far, nothing has set offload_fwd_mark. This is about to\nchange, since i need it for IGMP snooping on the brX interface, for\nMarvell at least. Bit i just need to set it to true for all frames.\n\nWhat use cases do you have in mind where you need information from the\nswitch driver to decide on its value?\n\n> A little out-of-topic is the MAC driver may have problem receiving the frame if\n> the tail tag length is too big. Most of the MAC drivers have big enough receive\n> buffer or require 64-bytes multiple so there are extra room to accommodate\n> the big tail tag at the end of the frame. Still some MAC drivers use exactly 1500\n> MTU and some additional length and may run into this problem. Currently the\n> Atmel Cadence MAC driver has this potential problem when certain conditions\n> are met.\n\nThis is a know problem. I just fixed the FEC driver which also\ndiscarded DSA tagged frames when they were bigger than the MTU.\n\nSo far, it has not been too much of an issue, because most boards with\na switch, use an Ethernet interface from the same manufacture. Marvell\nSwitches with a Marvell Ethernet interface. Broadcom switch with a\nBroadcom Interface. Atheros switch with an Atheros interface. And\nnaturally, these combinations just work. But Freescale FEC and Marvell\nhad not been combined before, and it was broken.\n\nSo i would not be surprised if the Cadence MAC driver had an issue.\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 3xwxcQ4QF1z9s7v\n\tfor ;\n\tTue, 19 Sep 2017 05:57:26 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751210AbdIRT5O (ORCPT );\n\tMon, 18 Sep 2017 15:57:14 -0400","from vps0.lunn.ch ([185.16.172.187]:46509 \"EHLO vps0.lunn.ch\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1750772AbdIRT5N (ORCPT );\n\tMon, 18 Sep 2017 15:57:13 -0400","from andrew by vps0.lunn.ch with local (Exim 4.84_2)\n\t(envelope-from )\n\tid 1du2AG-0006BE-2v; Mon, 18 Sep 2017 21:57:08 +0200"],"Date":"Mon, 18 Sep 2017 21:57:08 +0200","From":"Andrew Lunn ","To":"Tristram.Ha@microchip.com","Cc":"muvarov@gmail.com, pavel@ucw.cz, nathan.leigh.conrad@gmail.com,\n\tvivien.didelot@savoirfairelinux.com, f.fainelli@gmail.com,\n\tnetdev@vger.kernel.org, linux-kernel@vger.kernel.org,\n\tWoojung.Huh@microchip.com","Subject":"Re: [PATCH RFC 6/6] Modify tag_ksz.c to support other KSZ switch\n\tdrivers","Message-ID":"<20170918195708.GE15606@lunn.ch>","References":"<93AF473E2DA327428DE3D46B72B1E9FD41121901@CHN-SV-EXMX02.mchp-main.com>\n\t<93AF473E2DA327428DE3D46B72B1E9FD41121A22@CHN-SV-EXMX02.mchp-main.com>\n\t<20170907214834.GT11248@lunn.ch>\n\t<93AF473E2DA327428DE3D46B72B1E9FD41124D2E@CHN-SV-EXMX02.mchp-main.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<93AF473E2DA327428DE3D46B72B1E9FD41124D2E@CHN-SV-EXMX02.mchp-main.com>","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":1770487,"web_url":"http://patchwork.ozlabs.org/comment/1770487/","msgid":"<93AF473E2DA327428DE3D46B72B1E9FD41124D7C@CHN-SV-EXMX02.mchp-main.com>","list_archive_url":null,"date":"2017-09-18T20:55:17","subject":"RE: [PATCH RFC 6/6] Modify tag_ksz.c to support other KSZ switch\n\tdrivers","submitter":{"id":72262,"url":"http://patchwork.ozlabs.org/api/people/72262/","name":"","email":"Tristram.Ha@microchip.com"},"content":"> > > This is ugly. We have a clean separation between a switch driver and a\n> > > tag driver. Here you are mixing them together. Don't. Look at the\n> > > mailing lists for what Florian and I suggested to Pavel. It will also\n> > > solve your include file issue above.\n> >\n> > It seems to me all tag_*.c are hard-coded. They do not have access to\n> > the switch device and just use the bit definitions defined in the top to\n> > do the job.\n> >\n> > This creates a problem for all KSZ switch devices as they have different\n> > tail tag formats and lengths. There will be potentially 4 additional\n> > DSA_TAG_PROT_KSZ* just to handle them. Extra files will be added\n> > with about the same code.\n> \n> Hi Tristram\n> \n> Think about factoring out the common code into a shared functions.\n>\n\nI am a little unsure what you have in mind. Can you elaborate?\n\nLike creating an additional ksz_xmit function and passing a function pointer\nto it to do the job?\n \n> > But the most important thing is how do we support the offload_fwd_mark\n> > bit in skb when the only place that has access to skb does not have access\n> to\n> > the switch hardware?\n> \n> Well, so far, nothing has set offload_fwd_mark. This is about to\n> change, since i need it for IGMP snooping on the brX interface, for\n> Marvell at least. Bit i just need to set it to true for all frames.\n> \n> What use cases do you have in mind where you need information from the\n> switch driver to decide on its value?\n>\n\nIn the old DSA implementation all the ports are partitioned into its own device\nand the bridge joining them will do all the forwarding. This is useful for quick\ntesting with some protocols like RSTP but it is probably useless for real\noperation.\n\nThe new switchdev model tries to use the switch hardware as much as\npossible. This offload_fwd_mark bit means the frame is forwarded by the\nhardware switch, so the software bridge does not need to do it again. Without\nthis bit there will be duplicated multicast frames coming out the ports if internal\nforwarding is enabled.\n\nWhen the DSA device is first created all ports are independent devices. When\na bridge is created and those devices are attached the ports share the same\nmembership so all frames will be forwarded internally.\n\nWhen RSTP is used the port can be put in blocked state and so the forwarding\nwill stop for that port. Currently the switch driver will check that membership\nto decide whether to set that bit.\n\n> > A little out-of-topic is the MAC driver may have problem receiving the\n> frame if\n> > the tail tag length is too big. Most of the MAC drivers have big enough\n> receive\n> > buffer or require 64-bytes multiple so there are extra room to\n> accommodate\n> > the big tail tag at the end of the frame. Still some MAC drivers use exactly\n> 1500\n> > MTU and some additional length and may run into this problem. Currently\n> the\n> > Atmel Cadence MAC driver has this potential problem when certain\n> conditions\n> > are met.\n> \n> This is a know problem. I just fixed the FEC driver which also\n> discarded DSA tagged frames when they were bigger than the MTU.\n> \n> So far, it has not been too much of an issue, because most boards with\n> a switch, use an Ethernet interface from the same manufacture. Marvell\n> Switches with a Marvell Ethernet interface. Broadcom switch with a\n> Broadcom Interface. Atheros switch with an Atheros interface. And\n> naturally, these combinations just work. But Freescale FEC and Marvell\n> had not been combined before, and it was broken.\n> \n> So i would not be surprised if the Cadence MAC driver had an issue.\n\nThe KSZ switches never have a built-in MAC controller, so it is always a support\nissue for us.","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 3xwyvT416rz9s7m\n\tfor ;\n\tTue, 19 Sep 2017 06:55:33 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751001AbdIRUzU convert rfc822-to-8bit (ORCPT\n\t);\n\tMon, 18 Sep 2017 16:55:20 -0400","from esa4.microchip.iphmx.com ([68.232.154.123]:6364 \"EHLO\n\tesa4.microchip.iphmx.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750711AbdIRUzT (ORCPT\n\t); Mon, 18 Sep 2017 16:55:19 -0400","from smtpout.microchip.com (HELO email.microchip.com)\n\t([198.175.253.82])\n\tby esa4.microchip.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-SHA;\n\t18 Sep 2017 13:55:19 -0700","from CHN-SV-EXMX02.mchp-main.com ([fe80::7dfe:3761:863e:3963]) by\n\tCHN-SV-EXCH07.mchp-main.com ([fe80::ad3d:8f75:7e60:e60f%15]) with\n\tmapi id 14.03.0352.000; Mon, 18 Sep 2017 13:55:18 -0700"],"X-IronPort-AV":"E=Sophos;i=\"5.42,414,1500966000\"; d=\"scan'208\";a=\"6916221\"","From":"","To":"","CC":", , ,\n\t, ,\n\t, ,\n\t","Subject":"RE: [PATCH RFC 6/6] Modify tag_ksz.c to support other KSZ switch\n\tdrivers","Thread-Topic":"[PATCH RFC 6/6] Modify tag_ksz.c to support other KSZ switch\n\tdrivers","Thread-Index":"AdMoGgjwWn+O5iRqREClMgoWecPmmwAAub+wABAyfwACFI9x8AAQwOcAAA2JDcA=","Date":"Mon, 18 Sep 2017 20:55:17 +0000","Message-ID":"<93AF473E2DA327428DE3D46B72B1E9FD41124D7C@CHN-SV-EXMX02.mchp-main.com>","References":"<93AF473E2DA327428DE3D46B72B1E9FD41121901@CHN-SV-EXMX02.mchp-main.com>\n\t<93AF473E2DA327428DE3D46B72B1E9FD41121A22@CHN-SV-EXMX02.mchp-main.com>\n\t<20170907214834.GT11248@lunn.ch>\n\t<93AF473E2DA327428DE3D46B72B1E9FD41124D2E@CHN-SV-EXMX02.mchp-main.com>\n\t<20170918195708.GE15606@lunn.ch>","In-Reply-To":"<20170918195708.GE15606@lunn.ch>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-originating-ip":"[10.10.215.90]","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"8BIT","MIME-Version":"1.0","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1770560,"web_url":"http://patchwork.ozlabs.org/comment/1770560/","msgid":"<20170918224236.GB29615@lunn.ch>","list_archive_url":null,"date":"2017-09-18T22:42:36","subject":"Re: [PATCH RFC 6/6] Modify tag_ksz.c to support other KSZ switch\n\tdrivers","submitter":{"id":13608,"url":"http://patchwork.ozlabs.org/api/people/13608/","name":"Andrew Lunn","email":"andrew@lunn.ch"},"content":"On Mon, Sep 18, 2017 at 08:55:17PM +0000, Tristram.Ha@microchip.com wrote:\n> > > > This is ugly. We have a clean separation between a switch driver and a\n> > > > tag driver. Here you are mixing them together. Don't. Look at the\n> > > > mailing lists for what Florian and I suggested to Pavel. It will also\n> > > > solve your include file issue above.\n> > >\n> > > It seems to me all tag_*.c are hard-coded. They do not have access to\n> > > the switch device and just use the bit definitions defined in the top to\n> > > do the job.\n> > >\n> > > This creates a problem for all KSZ switch devices as they have different\n> > > tail tag formats and lengths. There will be potentially 4 additional\n> > > DSA_TAG_PROT_KSZ* just to handle them. Extra files will be added\n> > > with about the same code.\n> > \n> > Hi Tristram\n> > \n> > Think about factoring out the common code into a shared functions.\n> >\n> \n> I am a little unsure what you have in mind. Can you elaborate?\n\nYou say you need 4 DSA_TAG_PROT_KSZ. I guess the code is nearly\nidentical in them all? If i remember correctly, the two tag bytes are\nthe other way around?\n\nstatic int ksz8k_xmit( *skb, struct net_device *dev)\n{\n\tuint8* tag;\n\n\ttag = ksz_xmit(skb, dev)\n\tif (!tag)\n\t return NULL;\n\n\ttag[0] = 1 << p->dp->index;\n\ttag[1] = 0;\n\n\treturn skb;\n}\n\nstatic int ksz9k_xmit( *skb, struct net_device *dev)\n{\n\tuint8* tag;\n\n\ttag = ksz_xmit(skb, dev)\n\tif (!tag)\n\t return NULL;\n\n\ttag[0] = 0;\n\ttag[1] = 1 << p->dp->index;\n\n\treturn skb;\n}\n\nconst struct dsa_device_ops ksz8k_netdev_ops = {\n .xmit = ksz8k_xmit,\n .rcv = ksz8k_rcv,\n};\n\nconst struct dsa_device_ops ksz9k_netdev_ops = {\n .xmit = ksz9k_xmit,\n .rcv = ksz9k_rcv,\n};\n\n\tAndrew","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 3xx1HM44Dgz9s7M\n\tfor ;\n\tTue, 19 Sep 2017 08:42:55 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751340AbdIRWmn (ORCPT );\n\tMon, 18 Sep 2017 18:42:43 -0400","from vps0.lunn.ch ([185.16.172.187]:46748 \"EHLO vps0.lunn.ch\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1750791AbdIRWmm (ORCPT );\n\tMon, 18 Sep 2017 18:42:42 -0400","from andrew by vps0.lunn.ch with local (Exim 4.84_2)\n\t(envelope-from )\n\tid 1du4kO-0007pR-7H; Tue, 19 Sep 2017 00:42:36 +0200"],"Date":"Tue, 19 Sep 2017 00:42:36 +0200","From":"Andrew Lunn ","To":"Tristram.Ha@microchip.com","Cc":"muvarov@gmail.com, pavel@ucw.cz, nathan.leigh.conrad@gmail.com,\n\tvivien.didelot@savoirfairelinux.com, f.fainelli@gmail.com,\n\tnetdev@vger.kernel.org, linux-kernel@vger.kernel.org,\n\tWoojung.Huh@microchip.com","Subject":"Re: [PATCH RFC 6/6] Modify tag_ksz.c to support other KSZ switch\n\tdrivers","Message-ID":"<20170918224236.GB29615@lunn.ch>","References":"<93AF473E2DA327428DE3D46B72B1E9FD41121901@CHN-SV-EXMX02.mchp-main.com>\n\t<93AF473E2DA327428DE3D46B72B1E9FD41121A22@CHN-SV-EXMX02.mchp-main.com>\n\t<20170907214834.GT11248@lunn.ch>\n\t<93AF473E2DA327428DE3D46B72B1E9FD41124D2E@CHN-SV-EXMX02.mchp-main.com>\n\t<20170918195708.GE15606@lunn.ch>\n\t<93AF473E2DA327428DE3D46B72B1E9FD41124D7C@CHN-SV-EXMX02.mchp-main.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<93AF473E2DA327428DE3D46B72B1E9FD41124D7C@CHN-SV-EXMX02.mchp-main.com>","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":1770563,"web_url":"http://patchwork.ozlabs.org/comment/1770563/","msgid":"<20170918225142.GC29615@lunn.ch>","list_archive_url":null,"date":"2017-09-18T22:51:42","subject":"Re: [PATCH RFC 6/6] Modify tag_ksz.c to support other KSZ switch\n\tdrivers","submitter":{"id":13608,"url":"http://patchwork.ozlabs.org/api/people/13608/","name":"Andrew Lunn","email":"andrew@lunn.ch"},"content":"> In the old DSA implementation all the ports are partitioned into its own device\n> and the bridge joining them will do all the forwarding. This is useful for quick\n> testing with some protocols like RSTP but it is probably useless for real\n> operation.\n\nIt is a good minimal driver, to get something into the kernel. You can\nthen add features to it.\n\n> The new switchdev model tries to use the switch hardware as much as\n> possible. This offload_fwd_mark bit means the frame is forwarded by the\n> hardware switch, so the software bridge does not need to do it again. Without\n> this bit there will be duplicated multicast frames coming out the ports if internal\n> forwarding is enabled.\n\nCorrect. Once you switch driver is clever enough, you can enable\noffload_fwd_mark.\n \n> When RSTP is used the port can be put in blocked state and so the forwarding\n> will stop for that port. Currently the switch driver will check that membership\n> to decide whether to set that bit.\n\nThis i don't get. RSTP or STP just break loops. How does RSTP vs STP\nmean you need to set offload_fwd_mark differently?\n\n> The KSZ switches never have a built-in MAC controller, so it is always a support\n> issue for us.\n\nNot quite right. Once your drivers are in mainline, it becomes a\nsupport issue for the community, with you being part of the community.\nI've helped others fix this issue, one of the less well used Marvell\nEthernet drivers had this problem, and i gave somebody pointers how to\nfix it.\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 3xx1V65yTcz9s2G\n\tfor ;\n\tTue, 19 Sep 2017 08:52:14 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1750990AbdIRWvq (ORCPT );\n\tMon, 18 Sep 2017 18:51:46 -0400","from vps0.lunn.ch ([185.16.172.187]:46755 \"EHLO vps0.lunn.ch\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1750862AbdIRWvp (ORCPT );\n\tMon, 18 Sep 2017 18:51:45 -0400","from andrew by vps0.lunn.ch with local (Exim 4.84_2)\n\t(envelope-from )\n\tid 1du4tD-0007rx-0U; Tue, 19 Sep 2017 00:51:43 +0200"],"Date":"Tue, 19 Sep 2017 00:51:42 +0200","From":"Andrew Lunn ","To":"Tristram.Ha@microchip.com","Cc":"muvarov@gmail.com, pavel@ucw.cz, nathan.leigh.conrad@gmail.com,\n\tvivien.didelot@savoirfairelinux.com, f.fainelli@gmail.com,\n\tnetdev@vger.kernel.org, linux-kernel@vger.kernel.org,\n\tWoojung.Huh@microchip.com","Subject":"Re: [PATCH RFC 6/6] Modify tag_ksz.c to support other KSZ switch\n\tdrivers","Message-ID":"<20170918225142.GC29615@lunn.ch>","References":"<93AF473E2DA327428DE3D46B72B1E9FD41121901@CHN-SV-EXMX02.mchp-main.com>\n\t<93AF473E2DA327428DE3D46B72B1E9FD41121A22@CHN-SV-EXMX02.mchp-main.com>\n\t<20170907214834.GT11248@lunn.ch>\n\t<93AF473E2DA327428DE3D46B72B1E9FD41124D2E@CHN-SV-EXMX02.mchp-main.com>\n\t<20170918195708.GE15606@lunn.ch>\n\t<93AF473E2DA327428DE3D46B72B1E9FD41124D7C@CHN-SV-EXMX02.mchp-main.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","In-Reply-To":"<93AF473E2DA327428DE3D46B72B1E9FD41124D7C@CHN-SV-EXMX02.mchp-main.com>","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":1770582,"web_url":"http://patchwork.ozlabs.org/comment/1770582/","msgid":"<93AF473E2DA327428DE3D46B72B1E9FD41124E0C@CHN-SV-EXMX02.mchp-main.com>","list_archive_url":null,"date":"2017-09-18T23:44:42","subject":"RE: [PATCH RFC 6/6] Modify tag_ksz.c to support other KSZ switch\n\tdrivers","submitter":{"id":72262,"url":"http://patchwork.ozlabs.org/api/people/72262/","name":"","email":"Tristram.Ha@microchip.com"},"content":"> > In the old DSA implementation all the ports are partitioned into its own\n> device\n> > and the bridge joining them will do all the forwarding. This is useful for\n> quick\n> > testing with some protocols like RSTP but it is probably useless for real\n> > operation.\n> \n> It is a good minimal driver, to get something into the kernel. You can\n> then add features to it.\n> \n> > The new switchdev model tries to use the switch hardware as much as\n> > possible. This offload_fwd_mark bit means the frame is forwarded by the\n> > hardware switch, so the software bridge does not need to do it again.\n> Without\n> > this bit there will be duplicated multicast frames coming out the ports if\n> internal\n> > forwarding is enabled.\n> \n> Correct. Once you switch driver is clever enough, you can enable\n> offload_fwd_mark.\n> \n> > When RSTP is used the port can be put in blocked state and so the\n> forwarding\n> > will stop for that port. Currently the switch driver will check that\n> membership\n> > to decide whether to set that bit.\n> \n> This i don't get. RSTP or STP just break loops. How does RSTP vs STP\n> mean you need to set offload_fwd_mark differently?\n> \n\nThe logic of the switch driver is if the membership of the port receiving\nthe frame contains other ports--not counting cpu port--the bit\noffload_fwd_mark is set. In RSTP closing the blocked port is generally good\nenough, but there are exceptions, so the port is removed from the\nmembership of other forwarding ports. A disabled port will have its\nmembership completely reset so it cannot receive anything. It does not\nmatter much in RSTP as the software bridge should know whether to forward\nthe frame or not.\n\nWe are back to square one. Is there any plan to add this offload_fwd_mark\nsupport to DSA driver so that it can be reported properly? It can be set all the\ntime, except during port initialization or before bridge creation the forwarding\nstate does not reflect reality.\n\nIf not the port membership can be fixed and there is no internal switch\nforwarding, leaving everything handled by the software bridge.","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 3xx2fx2YlXz9s2G\n\tfor ;\n\tTue, 19 Sep 2017 09:44:57 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751416AbdIRXop convert rfc822-to-8bit (ORCPT\n\t);\n\tMon, 18 Sep 2017 19:44:45 -0400","from esa2.microchip.iphmx.com ([68.232.149.84]:25944 \"EHLO\n\tesa2.microchip.iphmx.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751377AbdIRXoo (ORCPT\n\t); Mon, 18 Sep 2017 19:44:44 -0400","from smtpout.microchip.com (HELO email.microchip.com)\n\t([198.175.253.82])\n\tby esa2.microchip.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-SHA;\n\t18 Sep 2017 16:44:43 -0700","from CHN-SV-EXMX02.mchp-main.com ([fe80::7dfe:3761:863e:3963]) by\n\tCHN-SV-EXCH07.mchp-main.com ([fe80::ad3d:8f75:7e60:e60f%15]) with\n\tmapi id 14.03.0352.000; Mon, 18 Sep 2017 16:44:43 -0700"],"X-IronPort-AV":"E=Sophos;i=\"5.42,415,1500966000\"; d=\"scan'208\";a=\"7091722\"","From":"","To":"","CC":", , ,\n\t, ,\n\t, ,\n\t","Subject":"RE: [PATCH RFC 6/6] Modify tag_ksz.c to support other KSZ switch\n\tdrivers","Thread-Topic":"[PATCH RFC 6/6] Modify tag_ksz.c to support other KSZ switch\n\tdrivers","Thread-Index":"AdMoGgjwWn+O5iRqREClMgoWecPmmwAAub+wABAyfwACFI9x8AAQwOcAAA2JDcD//8R9AIAAb5wg","Date":"Mon, 18 Sep 2017 23:44:42 +0000","Message-ID":"<93AF473E2DA327428DE3D46B72B1E9FD41124E0C@CHN-SV-EXMX02.mchp-main.com>","References":"<93AF473E2DA327428DE3D46B72B1E9FD41121901@CHN-SV-EXMX02.mchp-main.com>\n\t<93AF473E2DA327428DE3D46B72B1E9FD41121A22@CHN-SV-EXMX02.mchp-main.com>\n\t<20170907214834.GT11248@lunn.ch>\n\t<93AF473E2DA327428DE3D46B72B1E9FD41124D2E@CHN-SV-EXMX02.mchp-main.com>\n\t<20170918195708.GE15606@lunn.ch>\n\t<93AF473E2DA327428DE3D46B72B1E9FD41124D7C@CHN-SV-EXMX02.mchp-main.com>\n\t<20170918225142.GC29615@lunn.ch>","In-Reply-To":"<20170918225142.GC29615@lunn.ch>","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-originating-ip":"[10.10.215.90]","Content-Type":"text/plain; charset=\"us-ascii\"","Content-Transfer-Encoding":"8BIT","MIME-Version":"1.0","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1770583,"web_url":"http://patchwork.ozlabs.org/comment/1770583/","msgid":"","list_archive_url":null,"date":"2017-09-18T23:48:56","subject":"Re: [PATCH RFC 6/6] Modify tag_ksz.c to support other KSZ switch\n\tdrivers","submitter":{"id":2800,"url":"http://patchwork.ozlabs.org/api/people/2800/","name":"Florian Fainelli","email":"f.fainelli@gmail.com"},"content":"On 09/18/2017 04:44 PM, Tristram.Ha@microchip.com wrote:\n>>> In the old DSA implementation all the ports are partitioned into its own\n>> device\n>>> and the bridge joining them will do all the forwarding. This is useful for\n>> quick\n>>> testing with some protocols like RSTP but it is probably useless for real\n>>> operation.\n>>\n>> It is a good minimal driver, to get something into the kernel. You can\n>> then add features to it.\n>>\n>>> The new switchdev model tries to use the switch hardware as much as\n>>> possible. This offload_fwd_mark bit means the frame is forwarded by the\n>>> hardware switch, so the software bridge does not need to do it again.\n>> Without\n>>> this bit there will be duplicated multicast frames coming out the ports if\n>> internal\n>>> forwarding is enabled.\n>>\n>> Correct. Once you switch driver is clever enough, you can enable\n>> offload_fwd_mark.\n>>\n>>> When RSTP is used the port can be put in blocked state and so the\n>> forwarding\n>>> will stop for that port. Currently the switch driver will check that\n>> membership\n>>> to decide whether to set that bit.\n>>\n>> This i don't get. RSTP or STP just break loops. How does RSTP vs STP\n>> mean you need to set offload_fwd_mark differently?\n>>\n> \n> The logic of the switch driver is if the membership of the port receiving\n> the frame contains other ports--not counting cpu port--the bit\n> offload_fwd_mark is set. In RSTP closing the blocked port is generally good\n> enough, but there are exceptions, so the port is removed from the\n> membership of other forwarding ports. A disabled port will have its\n> membership completely reset so it cannot receive anything. It does not\n> matter much in RSTP as the software bridge should know whether to forward\n> the frame or not.\n> \n> We are back to square one. Is there any plan to add this offload_fwd_mark\n> support to DSA driver so that it can be reported properly? It can be set all the\n> time, except during port initialization or before bridge creation the forwarding\n> state does not reflect reality.\n> \n> If not the port membership can be fixed and there is no internal switch\n> forwarding, leaving everything handled by the software bridge.\n\nI am not really sure why this is such a concern for you so soon when\nyour driver is not even included yet. You should really aim for baby\nsteps here: get the basic driver(s) included, with a limited set of\nfeatures, and gradually add more features to the driver. When\nfwd_offload_mark and RSTP become a real problem, we can most\ndefinitively find a way to fix those in DSA and depending drivers.","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=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"p8dyioc4\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xx2lw0T49z9ryv\n\tfor ;\n\tTue, 19 Sep 2017 09:49:16 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751457AbdIRXtE (ORCPT );\n\tMon, 18 Sep 2017 19:49:04 -0400","from mail-wr0-f170.google.com ([209.85.128.170]:47888 \"EHLO\n\tmail-wr0-f170.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750714AbdIRXtC (ORCPT\n\t); Mon, 18 Sep 2017 19:49:02 -0400","by mail-wr0-f170.google.com with SMTP id k20so1737389wre.4;\n\tMon, 18 Sep 2017 16:49:01 -0700 (PDT)","from [10.112.156.244] ([192.19.255.250])\n\tby smtp.googlemail.com with ESMTPSA id\n\tw14sm381028wmf.13.2017.09.18.16.48.58\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tMon, 18 Sep 2017 16:49:00 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=subject:to:cc:references:from:message-id:date:user-agent\n\t:mime-version:in-reply-to:content-language:content-transfer-encoding; \n\tbh=zYnyMHRhDE7u7JJANtCWFgTg1pbpSsAHQmI1vZf8Zts=;\n\tb=p8dyioc4J40q09ofd3TqYgSPgG7DEybCbILBU60+x+ITm1RJ7dqrR1vAkRysGPz6lt\n\t/5ApptP+DXOC0fK9SPoOLpSocbvc6xm//bR+ieTofKi+jsyznCrxg7tTY5tHDADJaUZj\n\teRkuLTH+Rsu4eRqB7qELwRkiTpUff/z7qe3yhWW70aegseY9TWFYOatBLntzthmmhXRK\n\tYtQULCAa98jAsc1tRxWJQ8mroPjroeVVcNKh0NuQDzI3dGEFlIrQXLp1/hzmaay7V0Ty\n\tH1i0T5b3A/BzQSiS2Hq9iIFtfSU7rTeLQWLa3rGbCQckf5K/l+1P5NxJGsN5vF5kp0nz\n\taHTg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=zYnyMHRhDE7u7JJANtCWFgTg1pbpSsAHQmI1vZf8Zts=;\n\tb=gRXLaMRjcJ9V9HmBZHwVrZzJYWK3u+IIVlqLAN1K/6yz0mFDbOB+xhJQ0EHTcB+1WT\n\tKyzbob6w93EqELtx51J1zHBxRiWuyFdPRpqwlKR+Ru5hi7eGKI5eXFU/QrE9FElSzd/Z\n\tlnGPF0f8/sN2lpqxTZe0EF8PXeZ58PMpQ3fv6FaxCkX3MGrgBEGtjw7Ph1rrhABlh+Pv\n\tYoeDvpx7DgAM4wOg8fnu45lamMrdWHerYLHsu/m1YfpvCmD1Hc735KWwNO+WJRfI3Gd5\n\tPHzIQgq+Se0R4NIyiljb4PRx6m3pzLqz39288jrffpkHq5Gza7czCbn3gDjm047KKM0v\n\t3LxA==","X-Gm-Message-State":"AHPjjUg6ryNzQYLoZvhEiX2mAzOsV1RYBIov9yaJs0ZBkfS67cNBCPFv\n\tB+9E6yZL7ncVNQ==","X-Google-Smtp-Source":"AOwi7QDw57lSBR0JxnruTmCt64NNWnShft6bXeU1d40yX2gM9Fb2JBi0A/6HEz2z88FKu5yUDaEBrA==","X-Received":"by 10.223.161.152 with SMTP id\n\tu24mr13731488wru.197.1505778540875; \n\tMon, 18 Sep 2017 16:49:00 -0700 (PDT)","Subject":"Re: [PATCH RFC 6/6] Modify tag_ksz.c to support other KSZ switch\n\tdrivers","To":"Tristram.Ha@microchip.com, andrew@lunn.ch","Cc":"muvarov@gmail.com, pavel@ucw.cz, nathan.leigh.conrad@gmail.com,\n\tvivien.didelot@savoirfairelinux.com, netdev@vger.kernel.org,\n\tlinux-kernel@vger.kernel.org, Woojung.Huh@microchip.com","References":"<93AF473E2DA327428DE3D46B72B1E9FD41121901@CHN-SV-EXMX02.mchp-main.com>\n\t<93AF473E2DA327428DE3D46B72B1E9FD41121A22@CHN-SV-EXMX02.mchp-main.com>\n\t<20170907214834.GT11248@lunn.ch>\n\t<93AF473E2DA327428DE3D46B72B1E9FD41124D2E@CHN-SV-EXMX02.mchp-main.com>\n\t<20170918195708.GE15606@lunn.ch>\n\t<93AF473E2DA327428DE3D46B72B1E9FD41124D7C@CHN-SV-EXMX02.mchp-main.com>\n\t<20170918225142.GC29615@lunn.ch>\n\t<93AF473E2DA327428DE3D46B72B1E9FD41124E0C@CHN-SV-EXMX02.mchp-main.com>","From":"Florian Fainelli ","Message-ID":"","Date":"Mon, 18 Sep 2017 16:48:56 -0700","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<93AF473E2DA327428DE3D46B72B1E9FD41124E0C@CHN-SV-EXMX02.mchp-main.com>","Content-Type":"text/plain; charset=utf-8","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":1770599,"web_url":"http://patchwork.ozlabs.org/comment/1770599/","msgid":"<93AF473E2DA327428DE3D46B72B1E9FD41124E47@CHN-SV-EXMX02.mchp-main.com>","list_archive_url":null,"date":"2017-09-19T00:45:41","subject":"RE: [PATCH RFC 6/6] Modify tag_ksz.c to support other KSZ switch\n\tdrivers","submitter":{"id":72262,"url":"http://patchwork.ozlabs.org/api/people/72262/","name":"","email":"Tristram.Ha@microchip.com"},"content":"> I am not really sure why this is such a concern for you so soon when\r\n> your driver is not even included yet. You should really aim for baby\r\n> steps here: get the basic driver(s) included, with a limited set of\r\n> features, and gradually add more features to the driver. When\r\n> fwd_offload_mark and RSTP become a real problem, we can most\r\n> definitively find a way to fix those in DSA and depending drivers.\r\n\r\nI was under the impression that there is a new push of this new switchdev\r\nmodel and so the DSA model was overhauled to support that.\r\n\r\nThe KSZ9477 driver is already in the kernel, and its register access is actually\r\nmuch different from the other older switches. There are not much common\r\ncode to be reused. I always know this tail tag handling is the sticking point.\r\nI will submit a much simplified driver and wait for switch access in the future.","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 3xx41J73mLz9s5L\n\tfor ;\n\tTue, 19 Sep 2017 10:45:56 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751370AbdISApo (ORCPT );\n\tMon, 18 Sep 2017 20:45:44 -0400","from esa6.microchip.iphmx.com ([216.71.154.253]:12862 \"EHLO\n\tesa6.microchip.iphmx.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750883AbdISApn (ORCPT\n\t); Mon, 18 Sep 2017 20:45:43 -0400","from exsmtp02.microchip.com (HELO email.microchip.com)\n\t([198.175.253.38])\n\tby esa6.microchip.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-SHA;\n\t18 Sep 2017 17:45:43 -0700","from CHN-SV-EXMX02.mchp-main.com ([fe80::7dfe:3761:863e:3963]) by\n\tCHN-SV-EXCH02.mchp-main.com ([::1]) with mapi id 14.03.0352.000;\n\tMon, 18 Sep 2017 17:45:42 -0700"],"X-IronPort-AV":"E=Sophos;i=\"5.42,415,1500966000\"; d=\"scan'208\";a=\"4557271\"","From":"","To":"","CC":", , ,\n\t, ,\n\t, ,\n\t","Subject":"RE: [PATCH RFC 6/6] Modify tag_ksz.c to support other KSZ switch\n\tdrivers","Thread-Topic":"[PATCH RFC 6/6] Modify tag_ksz.c to support other KSZ switch\n\tdrivers","Thread-Index":"AdMoGgjwWn+O5iRqREClMgoWecPmmwAAub+wABAyfwACFI9x8AAQwOcAAA2JDcD//8R9AIAAb5wg//+gYgCAAG1NEA==","Date":"Tue, 19 Sep 2017 00:45:41 +0000","Message-ID":"<93AF473E2DA327428DE3D46B72B1E9FD41124E47@CHN-SV-EXMX02.mchp-main.com>","References":"<93AF473E2DA327428DE3D46B72B1E9FD41121901@CHN-SV-EXMX02.mchp-main.com>\n\t<93AF473E2DA327428DE3D46B72B1E9FD41121A22@CHN-SV-EXMX02.mchp-main.com>\n\t<20170907214834.GT11248@lunn.ch>\n\t<93AF473E2DA327428DE3D46B72B1E9FD41124D2E@CHN-SV-EXMX02.mchp-main.com>\n\t<20170918195708.GE15606@lunn.ch>\n\t<93AF473E2DA327428DE3D46B72B1E9FD41124D7C@CHN-SV-EXMX02.mchp-main.com>\n\t<20170918225142.GC29615@lunn.ch>\n\t<93AF473E2DA327428DE3D46B72B1E9FD41124E0C@CHN-SV-EXMX02.mchp-main.com>\n\t","In-Reply-To":"","Accept-Language":"en-US","Content-Language":"en-US","X-MS-Has-Attach":"","X-MS-TNEF-Correlator":"","x-originating-ip":"[10.10.215.90]","Content-Type":"text/plain; charset=\"utf-8\"","Content-Transfer-Encoding":"base64","MIME-Version":"1.0","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}}]