netdev - Re: [PATCH net-next v2 07/10] net: phy: add support for C45-over-C22 transfers

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <6288946d020417d9c87236235d5c664f@kernel.org>
Date: Mon, 26 Jun 2023 09:14:46 +0200
From: Michael Walle <mwalle@...nel.org>
To: Andrew Lunn <andrew@...n.ch>
Cc: Heiner Kallweit <hkallweit1@...il.com>, Russell King
 <linux@...linux.org.uk>, "David S. Miller" <davem@...emloft.net>, Eric
 Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
 <pabeni@...hat.com>, Yisen Zhuang <yisen.zhuang@...wei.com>, Salil Mehta
 <salil.mehta@...wei.com>, Florian Fainelli <florian.fainelli@...adcom.com>,
 Broadcom internal kernel review list
 <bcm-kernel-feedback-list@...adcom.com>, Marek Behún
 <kabel@...nel.org>, Xu Liang <lxu@...linear.com>, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v2 07/10] net: phy: add support for C45-over-C22
 transfers

Am 2023-06-24 22:15, schrieb Andrew Lunn:
>>  int __phy_read_mmd(struct phy_device *phydev, int devad, u32 regnum)
>>  {
>> -	int val;
>> +	struct mii_bus *bus = phydev->mdio.bus;
>> +	int phy_addr = phydev->mdio.addr;
>> +	bool check_rc = true;
>> +	int ret;
> 
> Although __phy_read_mmd() is exported as a GPL symbol, it is not in
> fact used outside of this file. I think we can easily change it
> signature.
> 
>> +	switch (phydev->access_mode) {
> 
> Have access_mode passed in as a parameter. It then becomes a generic
> low level helper.

Are you sure? Why is it a generic helper then? You still need the phydev
parameter. E.g. for the bus, the address and more importantly, for the
phydev->drv->read_mmd op. And in this case, you can't use it for my new
phy_probe_mmd_read() because there is no phydev structure at that time.

Also __phy_read_mmd() is just one of a whole block of (unlocked) 
functions
to access the MMDs of a PHY. So, to be consistent you'd have to change 
all
the other ones, too. No?

That being said, what about a true generic helper, without the phydev
parameter, which is then called in __phy_{read,write}_mmd()? Where
would that helper belong to? Without the C45-over-C22 I'd have suggested
to put it into mdio_bus.c but C45-over-C22 being a PHY thing, I guess
it should be in phy-core.c.

> The function which is really exported and expected to by used by PHY
> drivers is:
> 
> int phy_read_mmd(struct phy_device *phydev, int devad, u32 regnum)
> {
> 	int ret;
> 
> 	phy_lock_mdio_bus(phydev);
> 	ret = __phy_read_mmd(phydev, devad, regnum);
> 	phy_unlock_mdio_bus(phydev);
> 
> 	return ret;
> }
> EXPORT_SYMBOL(phy_read_mmd);
> 
> This can easily pass phydev->access_mode as a parameter.
> 
>> +static int phy_probe_mmd_read(struct mii_bus *bus, int prtad, int 
>> devad,
>> +			      u16 regnum, bool c45_over_c22)
>> +{
> 
> What i don't like is this bool c45_over_c22. Why have both the enum
> for the three access modes, and this bool. Pass an access mode.

Ok, but just to be sure, access mode c22 is then a "return -EINVAL".

>> +	int ret;
>> +
>> +	if (!c45_over_c22)
>> +		return mdiobus_c45_read(bus, prtad, devad, regnum);
>> +
>> +	mutex_lock(&bus->mdio_lock);
>> +
>> +	ret = __phy_mmd_indirect(bus, prtad, devad, regnum);
>> +	if (ret)
>> +		goto out;
>> +
>> +	ret = __mdiobus_read(bus, prtad, MII_MMD_DATA);
> 
> And then this just uses the generic low level __phy_read_mmd().

See above, no there is no *phydev.

-michael