On 7/9/26 01:04, Andrew Lunn wrote:

quoted

quoted

Lets take a step back.

What sort of reset are we talking about? Software or hardware?

	Andrew

It is doing a hardware reset using a GPIO line.

When linked down the phy gets put into reset using a hardware GPIO line,
during link up the phy initializes the hardware using phy_init_hw(),
which de-asserts that reset GPIO. Then trivial setup is done before
the driver specific config_init().

When we are doing the marvell m88e1510_config_init() the first page
write is not applying so it ends up writing configuration to the wrong
registers. When testing fixes adding a 15us sleep before changing the
page also meant the page was updated correctly.

   reset-gpios:
     maxItems: 1
     description:
       The GPIO phandle and specifier for the PHY reset signal.

   reset-assert-us:
     description:
       Delay after the reset was asserted in microseconds. If this
       property is missing the delay will be skipped.

   reset-deassert-us:
     description:
       Delay after the reset was deasserted in microseconds. If
       this property is missing the delay will be skipped.


What delays are you using?

      Andrew

We were not using any of those delays as I didn't see those options.
Adding a delay fixes our issue, so this patch is not needed.

Thank you for your time,
Ben