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: <20220830103340.bqgzmcztb57m7jgd@skbuf> Date: Tue, 30 Aug 2022 13:33:40 +0300 From: Vladimir Oltean <olteanv@...il.com> To: Jerry Ray <jerry.ray@...rochip.com> Cc: Andrew Lunn <andrew@...n.ch>, Vivien Didelot <vivien.didelot@...il.com>, Florian Fainelli <f.fainelli@...il.com>, "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, UNGLinuxDriver@...rochip.com Subject: Re: [PATCH 1/2] net: dsa: LAN9303: Add basic support for LAN9354 On Mon, Aug 29, 2022 at 01:00:36PM -0500, Jerry Ray wrote: > Add initial BYTE_ORDER read to sync to improve driver robustness Please don't post 2 different patches with the same commit message. I think here, the first paragraph is what the commit message should actually be. > > The lan9303 expects two mdio read transactions back-to-back to read a 32-bit > register. The first read transaction causes the other half of the 32-bit > register to get latched. The subsequent read returns the latched second half > of the 32-bit read. The BYTE_ORDER register is an exception to this rule. As > it is a constant value, there is no need to latch the second half. We read > this register first in case there were reads during the boot loader process > that might have occurred prior to this driver taking over ownership of > accessing this device. > > This patch has been tested on the SAMA5D3-EDS with a LAN9303 RMII daughter > card. Is this patch fixing a problem for any existing platforms supported by this driver? > > Signed-off-by: Jerry Ray <jerry.ray@...rochip.com> > --- > drivers/net/dsa/lan9303-core.c | 13 +++++++++++-- > 1 file changed, 11 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c > index e03ff1f267bb..17ae02a56bfe 100644 > --- a/drivers/net/dsa/lan9303-core.c > +++ b/drivers/net/dsa/lan9303-core.c > @@ -32,6 +32,7 @@ > #define LAN9303_INT_EN 0x17 > # define LAN9303_INT_EN_PHY_INT2_EN BIT(27) > # define LAN9303_INT_EN_PHY_INT1_EN BIT(26) > +#define LAN9303_BYTE_ORDER 0x19 > #define LAN9303_HW_CFG 0x1D > # define LAN9303_HW_CFG_READY BIT(27) > # define LAN9303_HW_CFG_AMDX_EN_PORT2 BIT(26) > @@ -847,9 +848,10 @@ static int lan9303_check_device(struct lan9303 *chip) > int ret; > u32 reg; > > - ret = lan9303_read(chip->regmap, LAN9303_CHIP_REV, ®); > + // Dummy read to ensure MDIO access is in 32-bit sync. C-style comments /* */ are more typical in the Linux kernel coding style. > + ret = lan9303_read(chip->regmap, LAN9303_BYTE_ORDER, ®); Pretty strange to see the dummy read in lan9303_check_device(). Bootloader leaving things in a messy state is only a problem if we don't have a reset GPIO, right? How about introducing the logic here, right in lan9303_probe(): lan9303_handle_reset(chip); if (!chip->reset_gpio) { /* Dummy read to ensure MDIO access is in 32-bit sync. */ ret = lan9303_read(chip->regmap, LAN9303_BYTE_ORDER, ®); if (ret) { dev_err(chip->dev, "failed to access the device: %pe\n", ERR_PTR(ret)); return ret; } } ret = lan9303_check_device(chip); > if (ret) { > - dev_err(chip->dev, "failed to read chip revision register: %d\n", > + dev_err(chip->dev, "failed to access the device: %d\n", > ret); > if (!chip->reset_gpio) { > dev_dbg(chip->dev, The context here reads: if (!chip->reset_gpio) { dev_dbg(chip->dev, "hint: maybe failed due to missing reset GPIO\n"); } Is the comment still accurate after the change, or do you feel that it can be removed? Looks like you are fixing a known issue. > @@ -858,6 +860,13 @@ static int lan9303_check_device(struct lan9303 *chip) > return ret; > } > > + ret = lan9303_read(chip->regmap, LAN9303_CHIP_REV, ®); > + if (ret) { > + dev_err(chip->dev, "failed to read chip revision register: %d\n", > + ret); > + return ret; > + } > + > if ((reg >> 16) != LAN9303_CHIP_ID) { > dev_err(chip->dev, "expecting LAN9303 chip, but found: %X\n", > reg >> 16); > -- > 2.17.1 >
Powered by blists - more mailing lists