Re: DSA mv88e6xxx_probe

[Andrew Lunn <andrew@lunn.ch>]

> > > > chip->reset = devm_gpiod_get_optional(dev, "reset",
> > > > GPIOD_OUT_LOW);
> > > > if (IS_ERR(chip->reset))
> > > >         goto out;
> > > > 
> > > > if (chip->reset)
> > > >         usleep_range(1000, 2000);
> > > 
> > > So it should wait, but for what?
> > 
> > The current code is designed to take a switch held in reset out of
> > reset. It does not perform an actual reset.
> > 
> How does it then work? I see just a "devm_gpiod_get_optional" which
> just assign an pointer to "chip->reset" and then
> " if (chip->reset) usleep_range(1000, 2000);" which just waits for
> "something" ? Where is the "reset" took out? I don't see any gpio set
> to 0.

https://elixir.bootlin.com/linux/latest/source/include/linux/gpio/consumer.h#L49

	GPIOD_OUT_LOW	= GPIOD_FLAGS_BIT_DIR_SET | GPIOD_FLAGS_BIT_DIR_OUT,

https://elixir.bootlin.com/linux/latest/source/drivers/gpio/gpiolib.c#L4051

	/* Process flags */
	if (dflags & GPIOD_FLAGS_BIT_DIR_OUT)
		ret = gpiod_direction_output(desc,
				!!(dflags & GPIOD_FLAGS_BIT_DIR_VAL));
	else
		ret = gpiod_direction_input(desc);

> > If you need a real reset, you probably need to call
> > mv88e6xxx_hardware_reset(chip), not usleep().
> > 
> > However, a reset can be a slow operation, specially if the EEPROM is
> > full of stuff. So we want to avoid two resets if possible.
> > 
> > The MDIO bus itself has DT descriptions for a GPIO reset. See
> > Documentation/devicetree/bindings/net/mdio.yaml
> This looks promising. So I have to just move the "reset-gpios" DTB
> entry from switch to mdio section. But which driver handles it,
> drivers/net/phy/mdio_bus.c,

Yes.

> > mdio {
> > 	#address-cells = <1>;
> > 	#size-cells = 0>;
> while here is no compatible part... .

It does not need a compatible, because it is part of the FEC, and the
FEC has a compatible. Remember this is device tree, sometimes you need
to go up the tree towards the root to find the actual device with a
compatible.

    Andrew