Netdev List
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: jelonek.jonas@gmail.com
Cc: Jakub Kicinski <kuba@kernel.org>,
	linux@armlinux.org.uk, andrew@lunn.ch, hkallweit1@gmail.com,
	davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
	maxime.chevallier@bootlin.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, bjorn@mork.no, horms@kernel.org
Subject: Re: [PATCH net-next v8 1/2] net: sfp: apply I2C adapter quirks to limit block size
Date: Wed, 20 May 2026 16:42:04 -0700	[thread overview]
Message-ID: <20260520234204.565333-1-kuba@kernel.org> (raw)
In-Reply-To: <20260516135442.2234729-2-jelonek.jonas@gmail.com>

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
net: sfp: apply I2C adapter quirks to limit block size

This patch modifies the SFP driver to respect I2C adapter quirks when
configuring the I2C block size. It restricts the maximum block size
based on the adapter's max_read_len and max_write_len fields.

> diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
> index bd970f753beb6..e58e29a1e8d27 100644
> --- 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)
>  {

[ ... ]

>  	} else {
>  		sfp->i2c = NULL;
>  		return -EINVAL;
>  	}
>  
> +	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 this limit the read block size incorrectly based on the write limit?

The write portion of an I2C read transfer is always 1 byte for the EEPROM
offset, regardless of the read block size.

If an adapter has a max_write_len of 1, max_block_size will drop to 1.
Since sfp_hwmon_probe() checks if sfp->i2c_max_block_size < 2 to ensure
atomic 16-bit reads, does this inadvertently disable hardware monitoring for
adapters that have a small write limit but sufficient read capabilities?

Also, for actual write transfers, sfp_i2c_write() prepends a 1-byte register
address to the payload. If max_block_size is set exactly to max_write_len,
won't the resulting message length be 1 + max_write_len, which still exceeds
the adapter's quirk limit?

Additionally, looking at sfp_i2c_write(), it does not appear to loop or
chunk the buffer using sfp->i2c_max_block_size. Does this mean the new
limit will be ignored during writes, and the function will still attempt
to transfer the entire buffer in a single operation?

> +
> +	sfp->i2c_max_block_size = max_block_size;
>  	return 0;
>  }
-- 
pw-bot: cr

  reply	other threads:[~2026-05-20 23:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-16 13:54 [PATCH net-next v8 0/2] net: sfp: extend SMBus support Jonas Jelonek
2026-05-16 13:54 ` [PATCH net-next v8 1/2] net: sfp: apply I2C adapter quirks to limit block size Jonas Jelonek
2026-05-20 23:42   ` Jakub Kicinski [this message]
2026-05-16 13:54 ` [PATCH net-next v8 2/2] net: sfp: extend SMBus support Jonas Jelonek
2026-05-19  8:05   ` Maxime Chevallier
2026-05-20 23:42   ` Jakub Kicinski

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=20260520234204.565333-1-kuba@kernel.org \
    --to=kuba@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=bjorn@mork.no \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=horms@kernel.org \
    --cc=jelonek.jonas@gmail.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox