From: Andrew Lunn <andrew@lunn.ch>
To: David Yang <mmyangfl@gmail.com>
Cc: netdev@vger.kernel.org, Vladimir Oltean <olteanv@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Simon Horman <horms@kernel.org>,
Russell King <linux@armlinux.org.uk>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v7 3/3] net: dsa: yt921x: Add support for Motorcomm YT921x
Date: Mon, 8 Sep 2025 15:00:15 +0200 [thread overview]
Message-ID: <4ef60411-a3f8-4bb6-b1d9-ab61576f0baf@lunn.ch> (raw)
In-Reply-To: <20250905181728.3169479-4-mmyangfl@gmail.com>
> +/* 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
next prev parent reply other threads:[~2025-09-08 13:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-05 18:17 [PATCH net-next v7 0/3] " David Yang
2025-09-05 18:17 ` [PATCH net-next v7 1/3] dt-bindings: net: dsa: yt921x: Add Motorcomm YT921x switch support David Yang
2025-09-06 19:17 ` Rob Herring
2025-09-08 12:34 ` Andrew Lunn
2025-09-05 18:17 ` [PATCH net-next v7 2/3] net: dsa: tag_yt921x: add support for Motorcomm YT921x tags David Yang
2025-09-05 18:17 ` [PATCH net-next v7 3/3] net: dsa: yt921x: Add support for Motorcomm YT921x David Yang
2025-09-06 8:19 ` kernel test robot
2025-09-08 13:00 ` Andrew Lunn [this message]
2025-09-08 13:10 ` Yangfl
2025-09-08 13:30 ` Andrew Lunn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4ef60411-a3f8-4bb6-b1d9-ab61576f0baf@lunn.ch \
--to=andrew@lunn.ch \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mmyangfl@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®