Re: [PATCH net-next] net: dsa: mv88e6xxx: Add suspend/resume callbacks

[Andrew Lunn]

> I am not sure to understand what is lost. On my setup ethtool shows
> that everything is fine after resume but maybe I fall into a "default"
> working case.

Hi Miquèl

Is the power removed from the switch? If so, you need to restore the
full switch configuration. The current code might be sufficient for
runtime suspend, where the switch is put into a low power mode, but it
is kept powered. It is not sufficient for a full power cycle.

> When I compare with the two drivers pointed out by Andrew:
> * qca8k resume callback:
> 	* enable ports,
> 	* call dsa_switch_resume().
> * bcm_sf2 resume callback:
> 	* call dsa_switch_resume(),
> 	* reset the switch,
> 	* refresh rules (Not applicable?),
> 	* enable the PHYs,
> 	* setup the ports,
> 	* configure vlan (Not applicable?),
> * mv88e6xxx resume callback:
> 	* reset the switch,
> 	* enable the PHYs,
> 	* setup the ports,
> 	* enable IRQs,
> 	* call dsa_switch_resume().
 
Here are some commands to try before you suspend:

ip link add name br0 type bridge
ip link set br0 up
ip link set lan1 up
ip link set lan1 master br0
ip link set lan2 up
ip link set lan2 master br0

At this point, you should be able to pass traffic between lan1 and
lan2.

bridge fdb add 00:42:42:42:42:42 lan1
bridge fdb add 00:24:24:24:24:24 lan2

That adds two static forwarding database entries. You can show these using

bridge fdb show

There are likely to be additional dynamic FDB entries. It is O.K. to
loose the dynamic entries over a suspend/resume cycle, but the static
ones must remain.

> This looks pretty similar. Maybe the ports setup are set to default
> values while I should save some parameters at suspend? I changed a
> few parameters (like the MTU or the queue length) but they seem to be
> correct across suspend cycles.

MTU and queue length have nothing to do with the actual switch. Your
tests need to actually program the hardware.

    Andrew