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: <20230522134823.GA18381@nucnuc.mle> Date: Mon, 22 May 2023 15:48:23 +0200 From: David Epping <david.epping@...singlinkelectronics.com> To: "Russell King (Oracle)" <linux@...linux.org.uk> Cc: Andrew Lunn <andrew@...n.ch>, Heiner Kallweit <hkallweit1@...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 net 3/3] net: phy: mscc: enable VSC8501/2 RGMII RX clock On Sun, May 21, 2023 at 06:59:53PM +0100, Russell King (Oracle) wrote: > On Sat, May 20, 2023 at 06:06:03PM +0200, David Epping wrote: > > +static int vsc85xx_rgmii_enable_rx_clk(struct phy_device *phydev, > > + u32 rgmii_cntl) > > +{ > > + int rc, phy_id; > > + > > + phy_id = phydev->drv->phy_id & phydev->drv->phy_id_mask; > > + if (PHY_ID_VSC8501 != phy_id && PHY_ID_VSC8502 != phy_id) > > + return 0; > > As you are accessing the phy_id in the phy_driver struct, isn't it > already true that this will be initialised to constants such as > PHY_ID_VSC8501 or PHY_ID_VSC8502? In which case, why would you need > to mask it with drv->phy_id_mask ? Yes you are right. I copied the code from the vsc85xx_config_init() function in the same driver, but the extra masking is not necessary. It seems to be the phy_id in the struct phy_device which is read from the MDIO bus and thus needs masking. phy_id in struct phy_driver seems compile time defined and already masked. I'll adjust my patch. > > + > > + mutex_lock(&phydev->lock); > > + > > + rc = phy_modify_paged(phydev, MSCC_PHY_PAGE_EXTENDED_2, rgmii_cntl, > > + VSC8502_RGMII_RX_CLK_DISABLE, 0); > > + > > + mutex_unlock(&phydev->lock); > > What is the purpose of taking this lock? phy_modify_paged() will do its > read-modify-write access and page accesses under the MDIO bus lock, > which should be all that's required to guarantee an atomic update. Yes, I copied this from the vsc85xx_rgmii_set_skews() function in the same driver accessing the same register in the same context. But maybe it is used there because of repeated phydev->interface accesses, which may otherwise change during function execution? I'll remove the locks from my patch. Thanks for your feedback.
Powered by blists - more mailing lists