[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aXDMUEepq1sU_kfH@makrotopia.org>
Date: Wed, 21 Jan 2026 12:53:36 +0000
From: Daniel Golle <daniel@...rotopia.org>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>, "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Heiner Kallweit <hkallweit1@...il.com>,
Russell King <linux@...linux.org.uk>,
Simon Horman <horms@...nel.org>, netdev@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
Frank Wunderlich <frankwu@....de>, Chad Monroe <chad@...roe.io>,
Cezary Wilmanski <cezary.wilmanski@...ran.com>,
Avinash Jayaraman <ajayaraman@...linear.com>,
Bing tao Xu <bxu@...linear.com>, Liang Xu <lxu@...linear.com>,
Juraj Povazanec <jpovazanec@...linear.com>,
"Fanni (Fang-Yi) Chan" <fchan@...linear.com>,
"Benny (Ying-Tsan) Weng" <yweng@...linear.com>,
"Livia M. Rosu" <lrosu@...linear.com>,
John Crispin <john@...ozen.org>
Subject: Re: [PATCH net-next v5 4/4] net: dsa: add basic initial driver for
MxL862xx switches
Hi Vladimir,
On Thu, Jan 15, 2026 at 01:22:59AM +0200, Vladimir Oltean wrote:
> On Wed, Jan 14, 2026 at 11:15:40PM +0000, Daniel Golle wrote:
> > [...]
> > In order to avoid the detour via staging, from my perspective there are two
> > ways to go from here:
> >
> > a) Keep nagging MaxLinear to provide a switch firmware with an additional
> > firmware command which flushes the pre-configuration and puts the switch
> > in a well-defined state (all ports isolated, learning disabled) for DSA.
> >
> > b) Extend the patch to cover all the API calls needed to do this
> > manually (more than double of LoC).
> >
> > Obviously a) would be better for me and you, but MaxLinear indicated they
> > prefer not to release an new firmware adding that feature at this point.
> >
> > b) would allow me to proceed right away, but it would burden reviewers
> > with a rather huge patch for initial support for this switch.
> > For the sake of making review more easy I'd prefer to still keep this
> > in a series of not terribly huge patches rather than a single patch
> > which immediately brings in everything (ie. have bridge and bridgeport
> > configuration in one patch, FDB access in the next, ...). Would a
> > series adding everything needed to end up with isolated ports be
> > acceptable?
> >
> > Please let me know what you think.
>
> Do you have the additional work required to isolate user ports prepared
> on some branch that can be pre-reviewed? I'm not sure that I have all
> information to make an informed comment.
I've sent a follow-up version of the series[1] adding support for the
switch which includes basic usage of BRIDGE and BRIDGEPORT firmware API
to make sure ports are always isolated.
The function mxl862xx_isolate_port() introduced for this purpose is
going to be changed quite a lot in upcoming follow-up series, as we do
need to track and free allocated bridges used for port isolation for now
once bridge offloading is going to be implemented.
Please let me know if this is acceptable.
Thank you!
Daniel
[1]: https://patchwork.kernel.org/project/netdevbpf/list/?series=1043728
Powered by blists - more mailing lists