Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756437AbbFCO4b (ORCPT ); Wed, 3 Jun 2015 10:56:31 -0400 Received: from mail.savoirfairelinux.com ([209.172.62.77]:64591 "EHLO mail.savoirfairelinux.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932747AbbFCO4V (ORCPT ); Wed, 3 Jun 2015 10:56:21 -0400 Date: Wed, 3 Jun 2015 10:56:18 -0400 (EDT) From: Vivien Didelot To: Guenter Roeck Cc: netdev , David , Florian Fainelli , Andrew Lunn , Scott Feldman , Jiri Pirko , =?utf-8?Q?J=C3=A9rome?= Oufella , linux-kernel , kernel , Chris Healy Message-ID: <1116609866.252533.1433343378543.JavaMail.zimbra@savoirfairelinux.com> In-Reply-To: <20150603021714.GA932@roeck-us.net> References: <1433208470-25338-1-git-send-email-vivien.didelot@savoirfairelinux.com> <1433208470-25338-4-git-send-email-vivien.didelot@savoirfairelinux.com> <556D522E.90607@roeck-us.net> <1561034247.953427.1433295590494.JavaMail.zimbra@savoirfairelinux.com> <20150603021714.GA932@roeck-us.net> Subject: Re: [RFC 3/9] net: dsa: mv88e6xxx: add support for VTU ops MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.6.0_GA_1153 (ZimbraWebClient - FF38 (Linux)/8.6.0_GA_1153) Thread-Topic: mv88e6xxx: add support for VTU ops Thread-Index: NybdA4EafsirezHGhctQVmp90GzVvg== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2115 Lines: 56 Hi Guenter, On Jun 2, 2015, at 10:17 PM, Guenter Roeck linux@roeck-us.net wrote: > On Tue, Jun 02, 2015 at 09:39:50PM -0400, Vivien Didelot wrote: >> Guenter, >> >> On Jun 2, 2015, at 2:50 AM, Guenter Roeck linux@roeck-us.net wrote: >> > On 06/01/2015 06:27 PM, Vivien Didelot wrote: >> >> + /* Bringing an interface up adds it to the VLAN 0. Ignore this. */ >> >> + if (!vid) >> >> + return 0; >> >> + >> > >> > Me puzzled ;-). I brought this and the fid question up before. >> > No idea if my e-mail got lost or what happened. >> > >> > Can you explain why we don't need a configuration for vlan 0 ? >> >> Sorry for late reply. Initially, when issuing "ip link set up dev swp0", >> ndo_vlan_rx_add_vid was called to add the interface in the VLAN 0. >> > Loading the 802.1q module has the same effect. > > I think this may be on purpose; it is telling the switch to accept > packets with vid==0 (and untagged packets). > >> 2 things happen here: >> >> * this is inconsistent with the "bridge vlan" output which doesn't seem to >> know about a VID 0; >> * VID 0 seems special for this switch: if an ingressing frame has VID 0, the >> tagged port will override the VID bits with the port default VID at egress. >> > As far as I can see, the switch treats packets with vid==0 and untaged packets > as unknown if VLAN support is enabled. I am not sure about the untagged frames. But for tagged frames, the documentation says that frames with vid 0 will be overridden with the port's default VID. > Anyway, sounds odd. Sure this isn't a configuration problem somethere ? If I'm not mistaken, other drivers do that. e.g. Rocker deals with VID >= 1: for (vid = 1; vid < VLAN_N_VID; vid++) Maybe this VID overriding feature is what we want? But it doesn't look right to me, even more since it is not exposed to the user. Thanks, -v -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/