netdev - Re: mv88e6xxx: Timeout waiting for EEPROM done

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 14 Sep 2023 16:05:42 -0300
From: Fabio Estevam <festevam@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Vladimir Oltean <olteanv@...il.com>, l00g33k@...il.com, netdev <netdev@...r.kernel.org>, 
	Jakub Kicinski <kuba@...nel.org>, sashal@...nel.org
Subject: Re: mv88e6xxx: Timeout waiting for EEPROM done

On Thu, Sep 14, 2023 at 1:22 PM Fabio Estevam <festevam@...il.com> wrote:
>
> Hi Andrew,
>
> On Thu, Sep 14, 2023 at 12:15 PM Andrew Lunn <andrew@...n.ch> wrote:
>
> > Does this board actually have an EEPROM attached to the switch?
>
> No, there is no EEPROM attached to the switch on this board.
>
> > In mv88e6xxx_g1_wait_eeprom_done() what value is being returned for
> > the read of MV88E6XXX_G1_STS?
>
> [    1.594043] *************** G1_STS is 0xc800
> [    1.600348] *************** G1_STS is 0xc800
> [    1.606648] *************** G1_STS is 0xc800
> [    1.612950] *************** G1_STS is 0xc800
> [    1.619250] *************** G1_STS is 0xc800
> [    1.625547] mv88e6085 30be0000.ethernet-1:00: Timeout waiting for EEPROM done
> [    1.673477] *************** G1_STS is 0xc801

I have the impression that the hardware reset logic is not correctly
implemented.

If I change it like this, I don't get the "Timeout waiting for EEPROM
done" error:

--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -7076,13 +7076,16 @@ static int mv88e6xxx_probe(struct mdio_device *mdiodev)

        chip->info = compat_info;

-       chip->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
+       chip->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
        if (IS_ERR(chip->reset)) {
                err = PTR_ERR(chip->reset);
                goto out;
        }
-       if (chip->reset)
+       if (chip->reset) {
                usleep_range(10000, 20000);
+               gpiod_set_value(chip->reset, 0);
+               usleep_range(10000, 20000);
+       }

In the devicetree I pass:
reset-gpios = <&gpio1 5 GPIO_ACTIVE_LOW>;

Can anyone confirm what is the recommended hardware reset sequence?

Thanks