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
| ||
|
Message-ID: <CAOMZO5DJXsbgEDAZSjWJXBesHad1oWR9ht3a3Xjf=Q-faHm1rg@mail.gmail.com> 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
Powered by blists - more mailing lists