From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 89918C43381 for ; Tue, 19 Feb 2019 17:01:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 542142147A for ; Tue, 19 Feb 2019 17:01:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="j65uvP1+" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728867AbfBSRBJ (ORCPT ); Tue, 19 Feb 2019 12:01:09 -0500 Received: from pandora.armlinux.org.uk ([78.32.30.218]:45536 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727149AbfBSRBJ (ORCPT ); Tue, 19 Feb 2019 12:01:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=FCbaXi1u+zmYQmMzmy0vFpt/OigUP+npCgihU7JvnJg=; b=j65uvP1+otnHYl9V7iBnj+IAp SbpjVJcKv/2H9iLSYCXkNqb9EIo89kHKUHshAFZyiK1yqWC8pLpalen7t3cblJRr/tVzCS3YDE77L szqRkuvK89HZsOUiUclGV8QG+h+0nP16FuskIZf0LNcK13f/5cyQ9vKRC3GECHA7/HnoaLt4Xg/sQ tq7B1AP2eHKhxUABa5dJn7oMabLg7EuYXmaO0iLnlJ1FlHqvxAxbFX9n2UgABrDcph0xW2AAnkOTr wCd5/1yncEooabKdho26nFcYsrzdXWhTczfeSbOPiPM1+0gStXVjAkzCjFjKGmszMZOB34kV2am1m 2wrXEhzSQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:51236) by pandora.armlinux.org.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gw8lR-0006rq-5D; Tue, 19 Feb 2019 17:01:01 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.89) (envelope-from ) id 1gw8lP-00089X-D2; Tue, 19 Feb 2019 17:00:59 +0000 Date: Tue, 19 Feb 2019 17:00:59 +0000 From: Russell King - ARM Linux admin To: Vivien Didelot Cc: Andrew Lunn , Florian Fainelli , Heiner Kallweit , "David S. Miller" , netdev@vger.kernel.org Subject: Re: [PATCH net-next v2 2/3] net: dsa: mv88e6xxx: add support for bridge flags Message-ID: <20190219170059.h5j552kuplvdaqol@shell.armlinux.org.uk> References: <20190217163114.yomawlljyxlqy3ob@shell.armlinux.org.uk> <20190219111612.GF27578@t480s.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190219111612.GF27578@t480s.localdomain> User-Agent: NeoMutt/20170113 (1.7.2) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, Feb 19, 2019 at 11:16:12AM -0500, Vivien Didelot wrote: > Hi Russell, > > On Sun, 17 Feb 2019 16:32:34 +0000, Russell King wrote: > > +static int mv88e6xxx_port_bridge_flags(struct dsa_switch *ds, int port, > > + unsigned long flags) > > +{ > > + struct mv88e6xxx_chip *chip = ds->priv; > > + bool unicast, multicast; > > + int ret = -EOPNOTSUPP; > > + > > + unicast = dsa_is_cpu_port(ds, port) || dsa_is_dsa_port(ds, port) || > > + flags & BR_FLOOD; > > + multicast = flags & BR_MCAST_FLOOD; > > + > > + mutex_lock(&chip->reg_lock); > > + if (chip->info->ops->port_set_egress_floods) > > + ret = chip->info->ops->port_set_egress_floods(chip, port, > > + unicast, > > + multicast); > > + mutex_unlock(&chip->reg_lock); > > + > > + return ret; > > +} > > + > > +static unsigned long mv88e6xxx_bridge_flags_support(struct dsa_switch *ds) > > +{ > > + struct mv88e6xxx_chip *chip = ds->priv; > > + unsigned long support = 0; > > + > > + if (chip->info->ops->port_set_egress_floods) > > + support |= BR_FLOOD | BR_MCAST_FLOOD; > > + > > + return support; > > +} > > I think that it isn't necessary to propagate the notion of bridge flags down > to the DSA drivers. It might be just enough to add: > > port_egress_flood(dsa_switch *ds, int port, bool uc, bool mc) > > to dsa_switch_ops and set BR_FLOOD | BR_MCAST_FLOOD from the DSA core, > if the targeted driver has ds->ops->port_set_egress_flood. What do you think? I've just changed my last patch to set these modes from dsa_port_bridge_join() and dsa_port_bridge_leave(), and while testing, I notice this on the ZII rev B board: At boot (without anything connected to any of the switch ports): br0: port 1(lan0) entered blocking state br0: port 1(lan0) entered disabled state device lan0 entered promiscuous mode device eth1 entered promiscuous mode br0: port 2(lan1) entered blocking state br0: port 2(lan1) entered disabled state device lan1 entered promiscuous mode ... I then removed lan0 from the bridge: device lan0 left promiscuous mode br0: port 1(lan0) entered disabled state and then added it back: br0: port 1(lan0) entered blocking state br0: port 1(lan0) entered disabled state device lan0 entered promiscuous mode Now, you'd expect lan0 and lan1 to be configured the same at this point, and the same as it was before lan0 was removed from the bridge? lan0 is port 0, lan1 is port 1 on this switch - and the register debug says: GLOBAL GLOBAL2 SERDES 0 1 2 3 4 5 6 0: c800 0 1140 500f 500f 500f 500f 500f 4e07 4d04 ... 4: 40a8 258 1e0 43c 43d 43d 7c 430 53f 373f Note that port 0 is in disabled state, but port 1 and 2 are in blocking state... but wait, the kernel printed a message saying it was in disabled state! If I do the same for lan1, port 1 above changed from 0x43d to 0x433 as expected, and then returns to 0x43c. It looks like DSA isn't always in sync with bridge as per port state. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up