Re: mv88e6xxx: Timeout waiting for EEPROM done

[Andrew Lunn <andrew@lunn.ch>]

> Just checked with a scope here and no, the reset pin is not held in
> reset before the driver loads.
> 
> > aim of this code is not to actually reset the switch, but to ensure it
> > is taken out of reset if it was being held in reset. And if it was
> > being held in reset, i would expect that to be for a long time, at
> > least the current Linux boot time.
> 
> That's a point I am concerned about: why don't we follow the datasheet
> with respect to taking the reset pin out of reset?
> 
> Isn't the sequence I used below better suited as it follows the
> datasheet by guaranteeing the 10ms at a low level?
> 
>        chip->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
>        ....
>        if (chip->reset) {
>                 usleep_range(10000, 20000);
>                 gpiod_set_value(chip->reset, 0);
>                 usleep_range(10000, 20000);
>        }

As i said, we do a hardware reset later. All we are trying to do at
this stage is probe the device, does it exist on the bus, and what ID
value does it have. I want to avoid the overhead of doing a reset now,
and then doing it again later.

So you say your device is not held in reset. So ideally there should
not be a change in the GPIO with devm_gpiod_get_optional(), and the
delay afterwards is pointless in your case.

When the device is held in reset, devm_gpiod_get_optional() should
release it from reset, and then we need a delay because experience has
shown the device will not actually respond on the MDIO bus for a short
while.

	Andrew