linux-kernel - Re: [PATCH net-next v7 3/3] net: dsa: yt921x: Add support for Motorcomm YT921x

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: <4ef60411-a3f8-4bb6-b1d9-ab61576f0baf@lunn.ch>
Date: Mon, 8 Sep 2025 15:00:15 +0200
From: Andrew Lunn <andrew@...n.ch>
To: David Yang <mmyangfl@...il.com>
Cc: netdev@...r.kernel.org, Vladimir Oltean <olteanv@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, Simon Horman <horms@...nel.org>,
	Russell King <linux@...linux.org.uk>, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v7 3/3] net: dsa: yt921x: Add support for
 Motorcomm YT921x

> +/* Prepare for read/write operations. Not a lock primitive despite underlying
> + * implementations may perform a lock (could be a no-op if the bus supports
> + * native atomic operations on internal ASIC registers).

It is more than atomic operations. Look at how long you hold the
lock. It is not a simple read/modify/write, you hold it over multiple
reads and writes. If the ASIC provided some sort of locking, it would
be available for MDIO, I2C, and SPI, and probably mean additional bus
transactions.

> + *
> + * To serialize register operations, use yt921x_lock() instead.
> + */
> +static void yt921x_reg_acquire(struct yt921x_priv *priv)
> +{
> +	if (priv->smi_ops->acquire)
> +		priv->smi_ops->acquire(priv->smi_ctx);
> +}

So, as i said in my review to previous versions, skip the if and just
take the mutex. KISS. I would not even call mutex_lock(priv->lock);
Don't over engineer the solution, this will probably work for I2C and
SPI as well.

> +/* You should manage the bus ownership yourself and use yt921x_reg_read()
> + * directly, except for register polling with read_poll_timeout(); see examples
> + * below.
> + */
> +static int yt921x_reg_read_managed(struct yt921x_priv *priv, u32 reg, u32 *valp)
> +{
> +	int res;
> +
> +	yt921x_reg_acquire(priv);
> +	res = yt921x_reg_read(priv, reg, valp);
> +	yt921x_reg_release(priv);
> +
> +	return res;
> +}

Sorry, i missed your reply to my comment to the previous version. You
said:

> The driver itself does not need an explicit lock (so long as dsa
> framework does not call two conflicting methods on the same port),

The DSA framework makes no such guarantees. The DSA framework is also
not the only entry point into the driver, phylink will directly call
into the driver, and if you implement things like LEDs, they will have
direct access to the driver.

So i suggest only having a high level lock, acquired on entry,
released on exit, e.g. as mv88e6xxx does. KISS.

    Andrew

---
pw-bot: cr