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

[Miquel Raynal <miquel.raynal@bootlin.com>]

Hi Andrew,

Andrew Lunn <andrew@lunn.ch> wrote on Tue, 22 Jan 2019 14:20:05 +0100:

> > 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.

Thank you very much for this, it is really helpful.

> 
> > 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.

I didn't checked the hw was programmed indeed. Well, I'll try with the
test described above and will propose something.

Thanks,
Miquèl