Currently, when an adapter defines a max_write_len quirk,
the data will be chunked into data sizes equal to the
max_write_len quirk value. But the payload will be increased by
the size of the register address before transmission. The
resulting value always ends up larger than the limit set
by the quirk.
Avoid this error by setting regmap's max_write to the quirk's
max_write_len minus the number of bytes for the register and
padding. This allows the chunking to work correctly for this
limited case without impacting other use-cases.
Signed-off-by: Jim Wylder <[email protected]>
---
drivers/base/regmap/regmap-i2c.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/base/regmap/regmap-i2c.c b/drivers/base/regmap/regmap-i2c.c
index 3ec611dc0c09..a905e955bbfc 100644
--- a/drivers/base/regmap/regmap-i2c.c
+++ b/drivers/base/regmap/regmap-i2c.c
@@ -350,7 +350,8 @@ static const struct regmap_bus *regmap_get_i2c_bus(struct i2c_client *i2c,
if (quirks->max_write_len &&
(bus->max_raw_write == 0 || bus->max_raw_write > quirks->max_write_len))
- max_write = quirks->max_write_len;
+ max_write = quirks->max_write_len -
+ (config->reg_bits + config->pad_bits) / BITS_PER_BYTE;
if (max_read || max_write) {
ret_bus = kmemdup(bus, sizeof(*bus), GFP_KERNEL);
--
2.45.1.288.g0e0cd299f1-goog
On Thu, May 23, 2024 at 04:14:36PM -0500, Jim Wylder wrote:
> Currently, when an adapter defines a max_write_len quirk,
> the data will be chunked into data sizes equal to the
> max_write_len quirk value. But the payload will be increased by
> the size of the register address before transmission. The
> resulting value always ends up larger than the limit set
> by the quirk.
>
> Avoid this error by setting regmap's max_write to the quirk's
> max_write_len minus the number of bytes for the register and
> padding. This allows the chunking to work correctly for this
> limited case without impacting other use-cases.
>
> Signed-off-by: Jim Wylder <[email protected]>
> ---
> drivers/base/regmap/regmap-i2c.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/base/regmap/regmap-i2c.c b/drivers/base/regmap/regmap-i2c.c
> index 3ec611dc0c09..a905e955bbfc 100644
> --- a/drivers/base/regmap/regmap-i2c.c
> +++ b/drivers/base/regmap/regmap-i2c.c
> @@ -350,7 +350,8 @@ static const struct regmap_bus *regmap_get_i2c_bus(struct i2c_client *i2c,
>
> if (quirks->max_write_len &&
> (bus->max_raw_write == 0 || bus->max_raw_write > quirks->max_write_len))
> - max_write = quirks->max_write_len;
> + max_write = quirks->max_write_len -
> + (config->reg_bits + config->pad_bits) / BITS_PER_BYTE;
>
> if (max_read || max_write) {
> ret_bus = kmemdup(bus, sizeof(*bus), GFP_KERNEL);
> --
> 2.45.1.288.g0e0cd299f1-goog
>
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- This looks like a new version of a previously submitted patch, but you
did not list below the --- line any changes from the previous version.
Please read the section entitled "The canonical patch format" in the
kernel file, Documentation/process/submitting-patches.rst for what
needs to be done here to properly describe this.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
On Thu, 23 May 2024 16:14:36 -0500, Jim Wylder wrote:
> Currently, when an adapter defines a max_write_len quirk,
> the data will be chunked into data sizes equal to the
> max_write_len quirk value. But the payload will be increased by
> the size of the register address before transmission. The
> resulting value always ends up larger than the limit set
> by the quirk.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git for-next
Thanks!
[1/1] regmap-i2c: Subtract reg size from max_write
commit: 611b7eb19d0a305d4de00280e4a71a1b15c507fc
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
Thu, May 23, 2024 at 04:14:36PM -0500, Jim Wylder kirjoitti:
> Currently, when an adapter defines a max_write_len quirk,
> the data will be chunked into data sizes equal to the
> max_write_len quirk value. But the payload will be increased by
> the size of the register address before transmission. The
> resulting value always ends up larger than the limit set
> by the quirk.
>
> Avoid this error by setting regmap's max_write to the quirk's
> max_write_len minus the number of bytes for the register and
> padding. This allows the chunking to work correctly for this
> limited case without impacting other use-cases.
...
> (bus->max_raw_write == 0 || bus->max_raw_write > quirks->max_write_len))
> - max_write = quirks->max_write_len;
> + max_write = quirks->max_write_len -
> + (config->reg_bits + config->pad_bits) / BITS_PER_BYTE;
Interesting. regmap-spi does this slightly differently, i.e. reg/8 + pad/8.
I'm wondering which one is more correct (potential off-by-one I suppose).
--
With Best Regards,
Andy Shevchenko
On Sun, Jun 02, 2024 at 10:29:07AM +0300, Andy Shevchenko wrote:
> > (bus->max_raw_write == 0 || bus->max_raw_write > quirks->max_write_len))
> > - max_write = quirks->max_write_len;
> > + max_write = quirks->max_write_len -
> > + (config->reg_bits + config->pad_bits) / BITS_PER_BYTE;
> Interesting. regmap-spi does this slightly differently, i.e. reg/8 + pad/8.
> I'm wondering which one is more correct (potential off-by-one I suppose).
The above seems more correct if we have less than a full byte of padding.
On Mon, Jun 3, 2024 at 3:08 PM Mark Brown <[email protected]> wrote:
>
> On Sun, Jun 02, 2024 at 10:29:07AM +0300, Andy Shevchenko wrote:
>
> > > (bus->max_raw_write == 0 || bus->max_raw_write > quirks->max_write_len))
> > > - max_write = quirks->max_write_len;
> > > + max_write = quirks->max_write_len -
> > > + (config->reg_bits + config->pad_bits) / BITS_PER_BYTE;
>
> > Interesting. regmap-spi does this slightly differently, i.e. reg/8 + pad/8.
> > I'm wondering which one is more correct (potential off-by-one I suppose).
>
> The above seems more correct if we have less than a full byte of padding.
Hmm... So, if we have
bits pad x/8+y/8 (x+y)/8
4..7 0..3 0 0 // x + y from 4 up to 7
4..7 4..7 0 1 // x + y from 8 up to 11
4..7 8..11 1 1 // x + y from 12 up to 15
8..15 0..7 1 1 // x + y from 8 up to 15
8..15 8..15 2 2 // x + y from 16 up to 23
The only difference AFAICS is the case 2.
Do we need to patch regmap SPI for that?
I think SPI just works since we don't really have devices that use
less than 8 bits per register, and hence we never enter into such a
case (while I2C is naturally using 7-bit addresses).
--
With Best Regards,
Andy Shevchenko
On Tue, Jun 04, 2024 at 12:15:33PM +0300, Andy Shevchenko wrote:
> The only difference AFAICS is the case 2.
> Do we need to patch regmap SPI for that?
> I think SPI just works since we don't really have devices that use
> less than 8 bits per register, and hence we never enter into such a
It's not a practical issue as far as I'm aware, I don't think anyone
actually uses weird padding like that but in principal I think so.
> case (while I2C is naturally using 7-bit addresses).
Realistically not, the 8th bit is a read/write bit.