[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cae18a4a-0085-493d-93a1-1e3127a0bd64@ti.com>
Date: Fri, 12 Apr 2024 13:31:44 +0530
From: "Anwar, Md Danish" <a0501179@...com>
To: Andrew Lunn <andrew@...n.ch>, MD Danish Anwar <danishanwar@...com>
CC: Diogo Ivo <diogo.ivo@...mens.com>, Rob Herring <robh@...nel.org>,
Dan
Carpenter <dan.carpenter@...aro.org>,
Jan Kiszka <jan.kiszka@...mens.com>, Simon Horman <horms@...nel.org>,
Wolfram Sang
<wsa+renesas@...g-engineering.com>,
Arnd Bergmann <arnd@...db.de>, Vignesh
Raghavendra <vigneshr@...com>,
Vladimir Oltean <vladimir.oltean@....com>,
Roger Quadros <rogerq@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Jakub
Kicinski <kuba@...nel.org>, Eric Dumazet <edumazet@...gle.com>,
"David S.
Miller" <davem@...emloft.net>,
<linux-arm-kernel@...ts.infradead.org>, <netdev@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <srk@...com>, <r-gunasekaran@...com>
Subject: Re: [PATCH net-next v3 3/3] net: ti: icssg-prueth: Add support for
ICSSG switch firmware
On 4/10/2024 6:12 PM, Andrew Lunn wrote:
>> I have been working on this and have found a way to change firmwares
>> without bringing the interfaces up / down.
>>
>> By default the interfaces are in MAC mode and the ICSSG EMAC firmwares
>> are running on pru cores. To enable switch mode we will need to stop the
>> cores and reload them with the ICSSG Switch firmwares. We can do this
>> without bringing the interfaces up / down.
>>
>> When first interface is added to bridge it will still run emac
>> firmwares. The moment second interface gets added to bridge, we will
>> disable the ports and stop the pru cores. Load the switch firmwares on
>> to the cores, start the cores and enable the ports. All of this is done
>> from the driver.
>>
>> The user need not to bring the interfaces up / down. Loading / Reloading
>> of firmwares will be handled inside the driver only. But we do need to
>> stop the cores for changing firmwares. For stopping the cores we will
>> change the port state to disable by sending r30 command to firmware.
>>
>> As we are not restarting the interfaces, the DRAM, SMEM and MSMC RAM
>> doesn't get cleared. As a result with this approach all configurations
>> will be saved.
>>
>> Please let me know if this approach looks ok to you.
>>
>> Below will be the commands to enable switch mode now,
>>
>> ip link add name br0 type bridge
>> ip link set dev eth1 master br0
>> ip link set dev eth2 master br0 (At this point we will stop the
>> cores, reload switch firmware, start the cores)
>> ip link set dev br0 up
>> bridge vlan add dev br0 vid 1 pvid untagged
>
> This sounds a lot better.
>
> Note that the bridge interface br0 might already be up when the
> interfaces are added. So that is a different order to what you showed
> here.
>
Hi Andrew, I have tested with that sequence as well and forwarding
works. Even if the second interface is added to bridge after bridge is
up, the forwarding works fine.
> There will be some packet losses when you swap firmware, but it
> probably is not that bad. When interfaces are added to a bridge
> packets are dropped anywhere while spanning tree determines the
> network topology. It will just appear your device is slow at doing
> that.
>
Yes there will be packet losses for a slight amount of time but that's
something we can't avoid.
I will post the next revision with these changes soon. Thanks for the
review.
> Andrew
--
Thanks and Regards,
Md Danish Anwar
Powered by blists - more mailing lists