linux-kernel - Re: [PATCH v2 net-next] net: phy: micrel: Adding SQI support for lan8814 phy

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: <YxX1I6wBFjzID2Ls@lunn.ch>
Date:   Mon, 5 Sep 2022 15:09:55 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Divya Koppera <Divya.Koppera@...rochip.com>
Cc:     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,
        UNGLinuxDriver@...rochip.com
Subject: Re: [PATCH v2 net-next] net: phy: micrel: Adding SQI support for
 lan8814 phy

On Mon, Sep 05, 2022 at 03:47:30PM +0530, Divya Koppera wrote:
> Supports SQI(Signal Quality Index) for lan8814 phy, where
> it has SQI index of 0-7 values and this indicator can be used
> for cable integrity diagnostic and investigating other noise
> sources. It is not supported for 10Mbps speed
> 
> Signed-off-by: Divya Koppera <Divya.Koppera@...rochip.com>
> ---
> v1 -> v2
> - Given SQI support for all pairs of wires in 1000/100 base-T phy's
>   uAPI may run through all instances in future. At present returning
>   only first instance as uAPI supports for only 1 pair.
> - SQI is not supported for 10Mbps speed, handled accordingly.

I would prefer you solve the problem of returning all pairs.

I'm not sure how useful the current implementation is, especially at
100Mbps, where pair 0 could actually be the transmit pair. Does it
give a sensible value in that case?

> +static int lan8814_get_sqi(struct phy_device *phydev)
> +{
> +	int ret, val, pair;
> +	int sqi_val[4];
> +
> +	if (phydev->speed == SPEED_10)
> +		return -EOPNOTSUPP;
> +
> +	for (pair = 0; pair < 4; pair++) {
> +		val = lanphy_read_page_reg(phydev, 1, LAN8814_DCQ_CTRL);
> +		if (val < 0)
> +			return val;
> +
> +		val &= ~LAN8814_DCQ_CTRL_CHANNEL_MASK;
> +		val |= pair;
> +		val |= LAN8814_DCQ_CTRL_READ_CAPTURE_;
> +		ret = lanphy_write_page_reg(phydev, 1, LAN8814_DCQ_CTRL, val);
> +		if (ret < 0)
> +			return ret;
> +
> +		ret = lanphy_read_page_reg(phydev, 1, LAN8814_DCQ_SQI);
> +		if (ret < 0)
> +			return ret;
> +
> +		sqi_val[pair] = FIELD_GET(LAN8814_DCQ_SQI_VAL_MASK, ret);
> +	}
> +
> +	return *sqi_val;

How is this going to work in the future? sqi_val is on the stack. You
cannot return a pointer to it. So this function is going to need
modifications.

If you really want to prepare for a future implementation which could
return all four, i would probably make this a helper which takes a
pair number. And then have a function call it once for pair 0.

     Andrew