[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <495324a7-cc5e-4658-a4ec-47e3e5ba96f8@redhat.com>
Date: Thu, 25 Sep 2025 10:27:33 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: Daniel Golle <daniel@...rotopia.org>, netdev@...r.kernel.org,
Hauke Mehrtens <hauke@...ke-m.de>, Andrew Lunn <andrew@...n.ch>,
"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>
Subject: Re: [PATCH net 0/2] lantiq_gswip fixes
On 9/25/25 10:14 AM, Vladimir Oltean wrote:
> On Thu, Sep 25, 2025 at 09:35:54AM +0200, Paolo Abeni wrote:
>> On 9/24/25 6:18 AM, Daniel Golle wrote:
>>> On Mon, Sep 22, 2025 at 11:34:52AM -0700, Jakub Kicinski wrote:
>>>> On Mon, 22 Sep 2025 14:07:17 +0300 Vladimir Oltean wrote:
>>>>> - I don't think your local_termination.sh exercises the bug fixed by
>>>>> patch "[1/2] net: dsa: lantiq_gswip: move gswip_add_single_port_br()
>>>>> call to port_setup()". The port has to be initially down before
>>>>> joining a bridge, and be brought up afterwards. This can be tested
>>>>> manually. In local_termination.sh, although bridge_create() runs
>>>>> "ip link set $h2 up" after "ip link set $h2 master br0", $h2 was
>>>>> already up due to "simple_if_init $h2".
>>>>
>>>> Waiting for more testing..
>>>
>>> I've added printk statements to illustrate the function calls to
>>> gswip_port_enable() and gswip_port_setup(), and tested both the current
>>> 'net' without (before.txt) and with (after.txt) patch
>>> "net: dsa: lantiq_gswip: move gswip_add_single_port_br() call to port_setup()"
>>> applied. This makes it obvious that gswip_port_enable() calls
>>> gswip_add_single_port_br() even though the port is at this point
>>> already a member of another bridge.
>>
>> Out of sheer ignorance is not clear to me why gswip_port_enable() is
>> apparently invoked only once while gswip_port_setup() is apparently
>> invoked for each dsa port.
>
> All ports have to be set up during probing, but only the ports in use
> (in the "after" log, these are the CPU port and one user port) need to
> be enabled. The user port has a netdev, so it is enabled on ndo_open().
> The CPU port doesn't have a netdev, it is always enabled.
Understood, thanks!
> So since I got my testing results which I'm now satisfied with, they
> don't actually need reposting. If you can pick them up for the "net"
> pull request and they're merged back into "net-next" later today, it
> should be even better than reposting them for "net-next" - which may
> require some avoidable rework such as dropping the "Fixes" tags.
Side note; generally speaking it's not needed to scrub the fixes tag
when reposting patches for net-next: we can have fixes landing to
net-next (i.e. invasive ones) and we need the correct Fixes: tag there,
as stable teams will still (try to/want to) pick them up at due time.
Some times the fixes tag is removed on net-next repost because it's
agreed that the change in question is more a refactor/improvement than a
fix.
I think patch 1/2 here belongs more to the first category above than the
second.
In any case, given there is consensous for this landing on 'net' I'll
pick it.
Paolo
Powered by blists - more mailing lists