Hi Andrew, Andrew Lunn <and...@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
