>-----Original Message----- >From: Thomas Graziadei [mailto:thomas.grazia...@omicronenergy.com] >Sent: Monday, February 13, 2017 2:22 PM >To: claudiu.man...@freescale.com; netdev@vger.kernel.org; linux- >ker...@vger.kernel.org >Cc: Thomas Graziadei <thomas.grazia...@omicronenergy.com> >Subject: [PATCH 1/2] gianfar: Deal with link state changes during >GFAR_RESETTING >dev state > >From: Thomas Graziadei <thomas.grazia...@omicronenergy.com> >
[...] > >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. > Calling adjust_link() from the ethernet driver, even if only following device reset / reconfig sections, is racy - the phylib state machine may run adjust_link() at the same time or the phydev state may be inconsistent - and may end up in more subtle link state issues. It also defeats the purpose of the adjust link hook, which is to be called by the phylib state machine. I had a look at this, and I don't think there is an easy fix in the driver for your case. However, the workaround should be straight forward: wait for the link to stabilize to the requested parameters before applying other device configuration changes that require device reset (like rx timestamping). Given that the PHYLIB state machine changed its behavior since adjust_link() in gianfar was last modified (i.e. it used to be called periodically before, from RUNNING<->CHANGELINK states) and given that there is a good part of legacy code in the current adjust_link() implementation, I think that driver part needs considerable rework to correctly cover this usecase as well. Thanks. Claudiu
