From: Simon Horman <horms@kernel.org>
To: jelonek.jonas@gmail.com
Cc: 'Simon Horman' <horms@kernel.org>,
linux@armlinux.org.uk, andrew@lunn.ch, hkallweit1@gmail.com,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, maxime.chevallier@bootlin.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
bjorn@mork.no
Subject: Re: [PATCH net-next v7 1/2] net: sfp: apply I2C adapter quirks to limit block size
Date: Sun, 10 May 2026 17:47:26 +0100 [thread overview]
Message-ID: <20260510164726.1401317-1-horms@kernel.org> (raw)
In-Reply-To: <20260507093301.1144740-2-jelonek.jonas@gmail.com>
From: 'Simon Horman' <horms@kernel.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
net: sfp: apply I2C adapter quirks to limit block size
This commit limits the SFP I2C block size based on the I2C adapter's
max_read_len and max_write_len quirks.
> diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
> --- a/drivers/net/phy/sfp.c
> +++ b/drivers/net/phy/sfp.c
[ ... ]
> @@ -807,21 +807,29 @@ static int sfp_smbus_byte_write(struct sfp *sfp, bool a2, u8 dev_addr,
>
> static int sfp_i2c_configure(struct sfp *sfp, struct i2c_adapter *i2c)
> {
[ ... ]
> + if (i2c->quirks && i2c->quirks->max_read_len)
> + max_block_size = min(max_block_size, i2c->quirks->max_read_len);
> + if (i2c->quirks && i2c->quirks->max_write_len)
> + max_block_size = min(max_block_size, i2c->quirks->max_write_len);
Does applying max_write_len to max_block_size inadvertently throttle reads
and break hardware monitoring?
The max_block_size dictates sfp->i2c_max_block_size, which subsequently sets
sfp->i2c_block_size. This block size is exclusively used by sfp_i2c_read()
to chunk read transfers. The write message in a chunked sfp_i2c_read()
operation is always exactly 1 byte (the register address), irrespective of
the read payload size. Restricting the read chunk size based on
max_write_len appears to cause unintended side effects.
If an adapter has a max_write_len of 1, the i2c_block_size becomes 1. This
forces 1-byte read chunking and explicitly skips hwmon device registration
since sfp_hwmon_probe() requires an i2c_block_size >= 2.
Will this change actually protect writes against the max_write_len quirk?
Looking at sfp_i2c_write(), it ignores sfp->i2c_block_size and does not
implement chunking. It unconditionally allocates 1 + len bytes and submits
a single i2c_msg. Any write where 1 + len > max_write_len will still be
rejected by the I2C core.
> +
> + sfp->i2c_max_block_size = max_block_size;
> return 0;
> }
next prev parent reply other threads:[~2026-05-10 16:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-07 9:32 [PATCH net-next v7 0/2] net: sfp: extend SMBus support Jonas Jelonek
2026-05-07 9:33 ` [PATCH net-next v7 1/2] net: sfp: apply I2C adapter quirks to limit block size Jonas Jelonek
2026-05-10 16:47 ` Simon Horman [this message]
2026-05-14 14:33 ` Jonas Jelonek
2026-05-15 16:42 ` Simon Horman
2026-05-07 9:33 ` [PATCH net-next v7 2/2] net: sfp: extend SMBus support Jonas Jelonek
2026-05-07 20:45 ` Maxime Chevallier
2026-05-10 16:47 ` Simon Horman
2026-05-15 13:55 ` Jonas Jelonek
2026-05-15 16:40 ` Simon Horman
2026-05-15 7:33 ` Maxime Chevallier
2026-05-15 8:00 ` Jonas Jelonek
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=20260510164726.1401317-1-horms@kernel.org \
--to=horms@kernel.org \
--cc=andrew@lunn.ch \
--cc=bjorn@mork.no \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=jelonek.jonas@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=maxime.chevallier@bootlin.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.