From: "Clément Léger" <clement.leger@bootlin.com>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: "Andrew Lunn" <andrew@lunn.ch>,
"Vivien Didelot" <vivien.didelot@gmail.com>,
"Florian Fainelli" <f.fainelli@gmail.com>,
"David S . Miller" <davem@davemloft.net>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Rob Herring" <robh+dt@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Geert Uytterhoeven" <geert+renesas@glider.be>,
"Magnus Damm" <magnus.damm@gmail.com>,
"Heiner Kallweit" <hkallweit1@gmail.com>,
"Russell King" <linux@armlinux.org.uk>,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
"Herve Codina" <herve.codina@bootlin.com>,
"Miquèl Raynal" <miquel.raynal@bootlin.com>,
"Milan Stevanovic" <milan.stevanovic@se.com>,
"Jimmy Lalande" <jimmy.lalande@se.com>,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, netdev@vger.kernel.org,
"Jean-Pierre Geslin" <jean-pierre.geslin@non.se.com>,
"Phil Edworthy" <phil.edworthy@renesas.com>
Subject: Re: [PATCH net-next 06/12] net: dsa: rzn1-a5psw: add Renesas RZ/N1 advanced 5 port switch driver
Date: Fri, 15 Apr 2022 14:28:57 +0200 [thread overview]
Message-ID: <20220415142857.525ccd2d@fixe.home> (raw)
In-Reply-To: <20220415105503.ztl4zhoyua2qzelt@skbuf>
Le Fri, 15 Apr 2022 13:55:03 +0300,
Vladimir Oltean <olteanv@gmail.com> a écrit :
> On Fri, Apr 15, 2022 at 11:34:53AM +0200, Clément Léger wrote:
> > Le Thu, 14 Apr 2022 17:47:09 +0300,
> > Vladimir Oltean <olteanv@gmail.com> a écrit :
> > > > later (vlan, etc).
> > > >
> > > > Suggested-by: Laurent Gonzales <laurent.gonzales@non.se.com>
> > > > Suggested-by: Jean-Pierre Geslin <jean-pierre.geslin@non.se.com>
> > > > Suggested-by: Phil Edworthy <phil.edworthy@renesas.com>
> > >
> > > Suggested? What did they suggest? "You should write a driver"?
> > > We have a Co-developed-by: tag, maybe it's more appropriate here?
> >
> > This driver was written from scratch but some ideas (port isolation
> > using pattern matcher) was inspired from a previous driver. I thought it
> > would be nice to give them credit for that.
> >
> > [...]
>
> Ok, in that case I don't really know how to mark sources of inspiration
> in the commit message, maybe your approach is fine.
>
> > > > obj-y += hirschmann/
> > > > obj-y += microchip/
> > > > diff --git a/drivers/net/dsa/rzn1_a5psw.c b/drivers/net/dsa/rzn1_a5psw.c
> > > > new file mode 100644
> > > > index 000000000000..5bee999f7050
> > > > --- /dev/null
> > > > +++ b/drivers/net/dsa/rzn1_a5psw.c
> > > > @@ -0,0 +1,676 @@
> > > > +// SPDX-License-Identifier: GPL-2.0-only
> > > > +/*
> > > > + * Copyright (C) 2022 Schneider-Electric
> > > > + *
> > > > + * Clément Léger <clement.leger@bootlin.com>
> > > > + */
> > > > +
> > > > +#include <linux/clk.h>
> > > > +#include <linux/etherdevice.h>
> > > > +#include <linux/kernel.h>
> > > > +#include <linux/module.h>
> > > > +#include <linux/of.h>
> > > > +#include <linux/of_mdio.h>
> > > > +#include <net/dsa.h>
> > > > +#include <uapi/linux/if_bridge.h>
> > >
> > > Why do you need to include this header?
> >
> > It defines BR_STATE_* but I guess linux/if_bridge.h does include it.
>
> Yes.
>
> > > > +static void a5psw_port_pattern_set(struct a5psw *a5psw, int port, int pattern,
> > > > + bool enable)
> > > > +{
> > > > + u32 rx_match = 0;
> > > > +
> > > > + if (enable)
> > > > + rx_match |= A5PSW_RXMATCH_CONFIG_PATTERN(pattern);
> > > > +
> > > > + a5psw_reg_rmw(a5psw, A5PSW_RXMATCH_CONFIG(port),
> > > > + A5PSW_RXMATCH_CONFIG_PATTERN(pattern), rx_match);
> > > > +}
> > > > +
> > > > +static void a5psw_port_mgmtfwd_set(struct a5psw *a5psw, int port, bool enable)
> > >
> > > Some explanation on what "management forward" means/does?
> >
> > I'll probably rename that cpu_port_forward to match the dsa naming.
> > It'll actually isolate the port from other ports by only forwarding the
> > packets to the CPU port.
>
> You could probably do without a rename by just adding a comment that
> says that it enables forwarding only towards the management port.
>
> > > Please implement .shutdown too, it's non-optional.
> >
> > Hum, platform_shutdown does seems to check for the .shutdown callback:
> >
> > static void platform_shutdown(struct device *_dev)
> > {
> > struct platform_device *dev = to_platform_device(_dev);
> > struct platform_driver *drv;
> >
> > if (!_dev->driver)
> > return;
> >
> > drv = to_platform_driver(_dev->driver);
> > if (drv->shutdown)
> > drv->shutdown(dev);
> > }
> >
> > Is there some documentation specifying that this is mandatory ?
> > If so, should I just set it to point to an empty shutdown function then
> > ?
>
> I meant that for a DSA switch driver is mandatory to call dsa_switch_shutdown()
> from your ->shutdown method, otherwise subtle things break, sorry for being unclear.
>
> Please blindly copy-paste the odd pattern that all other DSA drivers use
> in ->shutdown and ->remove (with the platform_set_drvdata(dev, NULL) calls),
> like a normal person :)
>
> > > > + * @reg_lock: Lock for register read-modify-write operation
> > >
> > > Interesting concept. Generally we see higher-level locking schemes
> > > (i.e. a rmw lock won't really ensure much in terms of consistency of
> > > settings if that's the only thing that serializes concurrent thread
> > > accesses to some register).
> >
> > Agreed, this does not guarantee consistency of settings but guarantees
> > that rmw modifications are atomic between devices. I wasn't sure about
> > the locking guarantee that I could have. After looking at other
> > drivers, I guess I will switch to something more common such as using
> > a global mutex for register accesses.
>
> LOL, that isn't better...
>
> Ideally locking would be done per functionality that the hardware can
> perform independently (like lookup table access, VLAN table access,
> forwarding domain control, PTP block, link state control, etc).
> You don't want to artificially serialize unrelated stuff.
> A "read-modify-write" lock would similarly artificially serialize
> unrelated stuff for you, even if you intend it to only serialize
> something entirely different.
>
> Most things as seen by a DSA switch driver are implicitly serialized by
> the rtnl_mutex anyway.
Is there a list of the functions that are protected by the RTNL lock
without having to deep dive in the whole stacks ? That would be really
useful to remove useless locking from my driver. But I guess I'll have
to look at other drivers to see that.
> Some things aren't (->port_fdb_add, ->port_fdb_del).
Ok, looks like for them a mutex is often used which also seems more
appropriate in my case since the operation on the learn table can take
some times.
> There is a point to be made about adding locks for stuff that is
> implicitly serialized by the rtnl_mutex, since you can't really test
> their effectiveness. This makes it more difficult for the driver writer
> to make the right decision about locking, since in some cases, the
> serialization given by the rtnl_mutex isn't something fundamental and
> may be removed, to reduce contention on that lock. In that case, it is
> always a nice surprise to find a backup locking scheme in converted
> drivers. With the mention that said backup locking scheme was never
> really tested, so it may be that it needs further work anyway.
Ok understood.
>
> > > The selftests don't cover nearly enough, but just to make sure that they
> > > pass for your switch, when you use 2 switch ports as h1 and h2 (hosts),
> > > and 2 ports as swp1 and swp2? There's surprisingly little that you do on
> > > .port_bridge_join, I need to study the code more.
> >
> > Port isolation is handled by using a pattern matcher which is enabled
> > for each port at setup. If set, the port packet will only be forwarded
> > to the CPU port. When bridging is needed, the pattern matching is
> > disabled and thus, the packets are forwarded between all the ports that
> > are enabled in the bridge.
>
> Is there some public documentation for this pattern matcher?
Yes, the manual is public [1]. See the Advanced 5 Ports Switch section.
[1]
https://www.renesas.com/us/en/document/mah/rzn1d-group-rzn1s-group-rzn1l-group-users-manual-r-engine-and-ethernet-peripherals
--
Clément Léger,
Embedded Linux and Kernel engineer at Bootlin
https://bootlin.com
next prev parent reply other threads:[~2022-04-15 12:31 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-14 12:22 [PATCH net-next 00/12] add support for Renesas RZ/N1 ethernet subsystem devices Clément Léger
2022-04-14 12:22 ` [PATCH net-next 01/12] net: dsa: add support for Renesas RZ/N1 A5PSW switch tag code Clément Léger
2022-04-14 13:44 ` Vladimir Oltean
2022-04-14 12:22 ` [PATCH net-next 02/12] net: dsa: add Renesas RZ/N1 switch tag driver Clément Léger
2022-04-14 14:22 ` Vladimir Oltean
2022-04-14 14:35 ` Clément Léger
2022-04-14 15:11 ` Vladimir Oltean
2022-04-14 16:18 ` Clément Léger
2022-04-14 16:23 ` Russell King (Oracle)
2022-04-15 7:23 ` Clément Léger
2022-04-14 22:50 ` Andrew Lunn
2022-04-14 12:22 ` [PATCH net-next 03/12] dt-bindings: net: pcs: add bindings for Renesas RZ/N1 MII converter Clément Léger
2022-04-14 18:59 ` Rob Herring
2022-04-19 13:43 ` Rob Herring
2022-04-19 15:00 ` Clément Léger
2022-04-20 20:11 ` Rob Herring
2022-04-21 7:35 ` Clément Léger
2022-04-14 12:22 ` [PATCH net-next 04/12] net: pcs: add Renesas MII converter driver Clément Léger
2022-04-14 12:49 ` Russell King (Oracle)
2022-04-14 15:14 ` Clément Léger
2022-04-20 13:25 ` Geert Uytterhoeven
2022-04-14 12:22 ` [PATCH net-next 05/12] dt-bindings: net: dsa: add bindings for Renesas RZ/N1 Advanced 5 port switch Clément Léger
2022-04-14 18:59 ` Rob Herring
2022-04-27 12:20 ` Geert Uytterhoeven
2022-04-27 12:56 ` Clément Léger
2022-04-14 12:22 ` [PATCH net-next 06/12] net: dsa: rzn1-a5psw: add Renesas RZ/N1 advanced 5 port switch driver Clément Léger
2022-04-14 13:02 ` Russell King (Oracle)
2022-04-15 8:40 ` Clément Léger
2022-04-15 8:52 ` Russell King (Oracle)
2022-04-14 14:47 ` Vladimir Oltean
2022-04-14 17:51 ` Andrew Lunn
2022-04-15 9:34 ` Clément Léger
2022-04-15 10:55 ` Vladimir Oltean
2022-04-15 11:02 ` Russell King (Oracle)
2022-04-15 11:14 ` Vladimir Oltean
2022-04-15 11:23 ` Russell King (Oracle)
2022-04-15 12:01 ` Vladimir Oltean
2022-04-15 11:05 ` Vladimir Oltean
2022-04-15 12:31 ` Clément Léger
2022-04-15 12:28 ` Clément Léger [this message]
2022-04-15 12:41 ` Vladimir Oltean
2022-04-14 17:55 ` Andrew Lunn
2022-04-15 12:33 ` Clément Léger
2022-04-14 12:22 ` [PATCH net-next 07/12] net: dsa: rzn1-a5psw: add statistics support Clément Léger
2022-04-14 17:34 ` Vladimir Oltean
2022-04-15 12:42 ` Clément Léger
2022-04-14 23:16 ` Andrew Lunn
2022-04-15 12:04 ` Clément Léger
2022-04-15 13:37 ` Andrew Lunn
2022-04-15 13:44 ` Clément Léger
2022-04-14 12:22 ` [PATCH net-next 08/12] net: dsa: rzn1-a5psw: add FDB support Clément Léger
2022-04-14 17:51 ` Vladimir Oltean
2022-04-20 8:16 ` Clément Léger
2022-04-20 19:52 ` Vladimir Oltean
2022-04-21 7:38 ` Clément Léger
2022-04-14 12:22 ` [PATCH net-next 09/12] ARM: dts: r9a06g032: describe MII converter Clément Léger
2022-04-14 23:22 ` Andrew Lunn
2022-04-15 8:24 ` Clément Léger
2022-04-15 14:16 ` Andrew Lunn
2022-04-15 14:38 ` Clément Léger
2022-04-15 15:12 ` Andrew Lunn
2022-04-15 15:29 ` Clément Léger
2022-04-15 16:19 ` Andrew Lunn
2022-04-15 16:45 ` Clément Léger
2022-04-16 13:48 ` Andrew Lunn
2022-04-19 9:03 ` Clément Léger
2022-04-19 12:57 ` Andrew Lunn
2022-04-20 20:16 ` Rob Herring
2022-04-14 12:22 ` [PATCH net-next 10/12] ARM: dts: r9a06g032: describe GMAC2 Clément Léger
2022-04-21 9:31 ` Geert Uytterhoeven
2022-04-14 12:22 ` [PATCH net-next 11/12] ARM: dts: r9a06g032: describe switch Clément Léger
2022-04-21 9:34 ` Geert Uytterhoeven
2022-04-14 12:22 ` [PATCH net-next 12/12] MAINTAINERS: add Renesas RZ/N1 switch related driver entry Clément Léger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220415142857.525ccd2d@fixe.home \
--to=clement.leger@bootlin.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=f.fainelli@gmail.com \
--cc=geert+renesas@glider.be \
--cc=herve.codina@bootlin.com \
--cc=hkallweit1@gmail.com \
--cc=jean-pierre.geslin@non.se.com \
--cc=jimmy.lalande@se.com \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=magnus.damm@gmail.com \
--cc=milan.stevanovic@se.com \
--cc=miquel.raynal@bootlin.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=phil.edworthy@renesas.com \
--cc=robh+dt@kernel.org \
--cc=thomas.petazzoni@bootlin.com \
--cc=vivien.didelot@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).