From: Heiner Kallweit Sent: 2018年12月16日 0:19
> If we detect a MDIO error, it seems to be a little bit too aggressive to stop
> the
> state machine and bring down the PHY completely.
> E.g. when polling and we miss one update, then this has no relevant impact.
> And in phy_stop_interrupts() actual
> After checking the fec history it seems that at the time this
> workaround was added as part of phylib support (8 years ago),
> the MDIO access timeout value was too low and therefore sometimes
> MDIO access failed. Later timeout was set to a higher value and
> driver switched to an event-driven
On 16.12.2018 09:42, Andrew Lunn wrote:
> On Sat, Dec 15, 2018 at 05:18:33PM +0100, Heiner Kallweit wrote:
>> If we detect a MDIO error, it seems to be a little bit too aggressive
>> to stop the state machine and bring down the PHY completely.
>
> Hi Heiner
>
> My assumption is, if we get one MDI
On Sat, Dec 15, 2018 at 05:18:33PM +0100, Heiner Kallweit wrote:
> If we detect a MDIO error, it seems to be a little bit too aggressive
> to stop the state machine and bring down the PHY completely.
Hi Heiner
My assumption is, if we get one MDIO error, we will gets lots more
MDIO errors. This sh
If we detect a MDIO error, it seems to be a little bit too aggressive
to stop the state machine and bring down the PHY completely.
E.g. when polling and we miss one update, then this has no relevant
impact. And in phy_stop_interrupts() actually interrupts should be
disabled already because phy_stop
