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
| ||
|
Date: Sat, 12 Jun 2021 18:13:30 +0300 From: Vladimir Oltean <olteanv@...il.com> To: Oleksij Rempel <o.rempel@...gutronix.de> Cc: Woojung Huh <woojung.huh@...rochip.com>, Andrew Lunn <andrew@...n.ch>, Florian Fainelli <f.fainelli@...il.com>, Russell King <linux@...linux.org.uk>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, Vivien Didelot <vivien.didelot@...il.com>, Michael Grzeschik <m.grzeschik@...gutronix.de>, kernel@...gutronix.de, Jakub Kicinski <kuba@...nel.org>, UNGLinuxDriver@...rochip.com, "David S. Miller" <davem@...emloft.net> Subject: Re: [PATCH net-next v4 4/9] net: phy: micrel: apply resume errata workaround for ksz8873 and ksz8863 On Sat, Jun 12, 2021 at 06:26:39AM +0200, Oleksij Rempel wrote: > On Fri, Jun 11, 2021 at 10:20:10PM +0300, Vladimir Oltean wrote: > > On Fri, Jun 11, 2021 at 09:15:22AM +0200, Oleksij Rempel wrote: > > > The ksz8873 and ksz8863 switches are affected by following errata: > > > > > > | "Receiver error in 100BASE-TX mode following Soft Power Down" > > > | > > > | Some KSZ8873 devices may exhibit receiver errors after transitioning > > > | from Soft Power Down mode to Normal mode, as controlled by register 195 > > > | (0xC3) bits [1:0]. When exiting Soft Power Down mode, the receiver > > > | blocks may not start up properly, causing the PHY to miss data and > > > | exhibit erratic behavior. The problem may appear on either port 1 or > > > | port 2, or both ports. The problem occurs only for 100BASE-TX, not > > > | 10BASE-T. > > > | > > > | END USER IMPLICATIONS > > > | When the failure occurs, the following symptoms are seen on the affected > > > | port(s): > > > | - The port is able to link > > > | - LED0 blinks, even when there is no traffic > > > | - The MIB counters indicate receive errors (Rx Fragments, Rx Symbol > > > | Errors, Rx CRC Errors, Rx Alignment Errors) > > > | - Only a small fraction of packets is correctly received and forwarded > > > | through the switch. Most packets are dropped due to receive errors. > > > | > > > | The failing condition cannot be corrected by the following: > > > | - Removing and reconnecting the cable > > > | - Hardware reset > > > | - Software Reset and PCS Reset bits in register 67 (0x43) > > > | > > > | Work around: > > > | The problem can be corrected by setting and then clearing the Port Power > > > | Down bits (registers 29 (0x1D) and 45 (0x2D), bit 3). This must be done > > > | separately for each affected port after returning from Soft Power Down > > > | Mode to Normal Mode. The following procedure will ensure no further > > > | issues due to this erratum. To enter Soft Power Down Mode, set register > > > | 195 (0xC3), bits [1:0] = 10. > > > | > > > | To exit Soft Power Down Mode, follow these steps: > > > | 1. Set register 195 (0xC3), bits [1:0] = 00 // Exit soft power down mode > > > | 2. Wait 1ms minimum > > > | 3. Set register 29 (0x1D), bit [3] = 1 // Enter PHY port 1 power down mode > > > | 4. Set register 29 (0x1D), bit [3] = 0 // Exit PHY port 1 power down mode > > > | 5. Set register 45 (0x2D), bit [3] = 1 // Enter PHY port 2 power down mode > > > | 6. Set register 45 (0x2D), bit [3] = 0 // Exit PHY port 2 power down mode > > > > > > This patch implements steps 2...6 of the suggested workaround. During > > > (initial) switch power up, step 1 is executed by the dsa/ksz8795 > > > driver's probe function. > > > > > > Note: In this workaround we toggle the MII_BMCR register's BMCR_PDOWN > > > bit, this is translated to the actual register and bit (as mentioned in > > > the arratum) by the ksz8_r_phy()/ksz8_w_phy() functions. > > > > s/arratum/erratum/ > > > > Also, the commit message is still missing this piece of information you > > gave in the previous thread: > > > > | this issue was seen at some early point of development (back in 2019) > > | reproducible on system start. Where switch was in some default state or > > | on a state configured by the bootloader. I didn't tried to reproduce it > > | now. > > > > Years from now, some poor souls might struggle to understand why this > > patch was done this way. If it is indeed the case that the issue is only > > seen during the handover between bootloader and kernel, there is really > > no reason to implement the ERR workaround in phy_resume instead of doing > > it once at probe time. > > Ok, i'll drop this patch for now. I mean, you don't have to drop it, you just have to provide a competent explanation for how the patch addresses the ERR as described by Microchip. Do you still have a board with this switch?
Powered by blists - more mailing lists