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: <479bd561-3bc2-44fd-8bab-ecd3e62f9c3e@microchip.com>
Date: Fri, 14 Nov 2025 08:37:08 +0000
From: <Parthiban.Veerasooran@...rochip.com>
To: <andrew@...n.ch>
CC: <piergiorgio.beruto@...il.com>, <hkallweit1@...il.com>,
	<linux@...linux.org.uk>, <davem@...emloft.net>, <edumazet@...gle.com>,
	<kuba@...nel.org>, <pabeni@...hat.com>, <netdev@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next 1/2] net: phy: phy-c45: add SQI and SQI+ support
 for OATC14 10Base-T1S PHYs

Hi Andrew,

On 13/11/25 9:45 pm, Andrew Lunn wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
>> +/**
>> + * genphy_c45_oatc14_get_sqi - Get Signal Quality Indicator (SQI) from an OATC14
>> +                            10Base-T1S PHY
>> + * @phydev: pointer to the PHY device structure
>> + *
>> + * Reads the SQI or SQI+ value from an OATC14-compatible 10Base-T1S PHY. If SQI+
>> + * capability is supported, the function returns the extended SQI+ value;
>> + * otherwise, it returns the basic SQI value.
>> + *
>> + * Return:
>> + * * Positive SQI/SQI+ value on success
>> + * * 0 if SQI update is not available
> 
> I thought 0 represented a very bad link? How is the call supposed to
> know the difference between a bad link, and no new value, try again
> later?
Yes, you are right. A value of 0 represents very poor SQI. Thank you for 
pointing out the need to distinguish between bad SQI and ‘no update’ 
values. Anyway, as per your comment below, this code will be removed 
since there is no need to check the update status.
> 
> I had a very quick look at the standard. All that update seems to
> indicate is that value has been updated since the last poll of that
> bit. There is no indication you cannot read the 'old' SQI value if
> there has not been an update. So i think you should always return an
> SQI value, if it is if 'old'.
Yes, I agree. I will update the code so that the reported SQI value is 
returned regardless of the update status in the next version.
> 
>> +     /* Read SQI capability */
>> +     ret = phy_read_mmd(phydev, MDIO_MMD_VEND2, MDIO_OATC14_ADFCAP);
>> +     if (ret < 0)
>> +             return ret;
> 
> I wounder if this should be cached somewhere. You don't expect it to
> change.
If I understand correctly, do you mean to store the capability details 
in the phydev structure when genphy_c45_oatc14_get_sqi_max() is called, 
and then use them in the genphy_c45_oatc14_get_sqi() function?

In that case, I may need to introduce new parameters in the phydev 
structure. Do you think introducing new parameters in the phydev 
structure is still necessary for this?

Best regards,
Parthiban V
> 
>          Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ