RE: [PATCH 1/2] gianfar: Deal with link state changes during GFAR_RESETTING dev state

From: Claudiu Manoil
Date: Mon Feb 13 2017 - 12:10:35 EST

>-----Original Message-----
>From: Thomas Graziadei [mailto:thomas.graziadei@xxxxxxxxxxxxxxxxx]
>Sent: Monday, February 13, 2017 2:22 PM
>To: claudiu.manoil@xxxxxxxxxxxxx; netdev@xxxxxxxxxxxxxxx; linux-
>Cc: Thomas Graziadei <thomas.graziadei@xxxxxxxxxxxxxxxxx>
>Subject: [PATCH 1/2] gianfar: Deal with link state changes during GFAR_RESETTING
>dev state
>From: Thomas Graziadei <thomas.graziadei@xxxxxxxxxxxxxxxxx>
>The link state is not correctly set in the case that the network driver
>is reconfigured while the link state changes. The phy informs the gianfar
>driver, but gfar_update_link_state just exits and therefore looses the
>change event. The network driver remains in the old state until a new link
>event is sent.
>A trace log from a possible scenario at bootup, when the link state in the
>network driver stays down even though the phy reports an up link. The test
>sends a SIOCSHWTSTAMP ioctl at the right moment (which calls reset_gfar):
> ip-1196 [000] 5.389270: phy_start: state: READY -> UP
>kworker/0:2-1195 [000] 5.389784: phy_start_aneg: state: UP -> AN
>kworker/0:2-1195 [000] 5.389788: phy_state_machine: state: UP -> AN
>kworker/0:2-1195 [000] 6.828064: adjust_link: eth0, link 0 -> 0
>kworker/0:2-1195 [000] 6.828599: phy_state_machine: state: AN -> NOLINK
> test-1470 [000] 7.460422: reset_gfar: before locking GFAR_RESETTING
> test-1470 [000] 7.470806: phy_stop: state: NOLINK -> HALTED
> test-1470 [000] 7.478806: phy_start: state: HALTED -> RESUMING
>kworker/0:2-1195 [000] 7.479478: adjust_link: eth0, link 0 -> 1
>kworker/0:2-1195 [000] 7.479482: phy_state_machine: state: RESUMING ->
> test-1470 [000] 7.479826: reset_gfar: after locking GFAR_RESETTING
>To resolve the issue adjust_link is called after every GFAR_RESETTING lock
>section. Adjust_link itself checks if anything has changed and updates the
>link accordingly.

Interesting findings. I need more time to check the patches. Btw, we don't
use "//" for comments on netdev.