All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfram Sang <wsa@kernel.org>
To: daniel.stodden@gmail.com
Cc: linux-i2c@vger.kernel.org, jdelvare@suse.de,
	Daniel Stodden <dns@arista.com>
Subject: Re: [RFC PATCH] i2c: Support Smbus 3.0 block sizes up to 255 bytes.
Date: Tue, 28 Jul 2020 11:40:37 +0200	[thread overview]
Message-ID: <20200728094037.GA980@ninjato> (raw)
In-Reply-To: <20200728004708.4430-1-daniel.stodden@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]

Hi Daniel,

wow, that was fast! Thanks for the prototype.

>  * I suggest to just settle on '3' for new macro and type names
>    (I2C_SMBUS3_*, i2c_smbus3_*)

Yes, I agree.

> 
>  * Block size definitions maintain I2C_SMBUS_BLOCK_MAX (32). Only adds
>    I2C_SMBUS3_BLOCK_MAX (255)
> 
>    - Means that drivers in drivers/i2c/busses/ default to their safe
>      32B block limit without refactoring.

This is totally fine for this patch. However, I still think I will do
the renaming to I2C_SMBUS2_BLOCK_MAX in kernel space later. Just so
people will understand by looking at the code that this is an old limit
which can be removed if there is interest.

> -	__u8 block[I2C_SMBUS_BLOCK_MAX + 2]; /* block[0] is used for length */
> +	__u8 block[I2C_SMBUS3_BLOCK_MAX + 2]; /* block[0] is used for length */
>  			       /* and one more for user-space compatibility */

I thought about this, too, and wondered if this isn't a size regression
in userspace with every i2c_smbus_data getting 8 times the size? But
maybe it is worth if backwards compatibility is maintained in an
otherwise not so intrusive manner? Jean, what do you think?

Happy hacking everyone,

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2020-07-28  9:40 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-28  0:47 [RFC PATCH] i2c: Support Smbus 3.0 block sizes up to 255 bytes daniel.stodden
2020-07-28  9:40 ` Wolfram Sang [this message]
2020-07-28 10:18   ` Daniel Stodden
2020-07-28 10:36     ` Wolfram Sang
2020-07-28 11:27       ` Daniel Stodden
2020-07-28 17:04   ` Jean Delvare
2020-07-28 21:16     ` Daniel Stodden
2020-07-29 10:51       ` Wolfram Sang
2020-07-28 11:16 ` Wolfram Sang
2020-07-28 11:40   ` Daniel Stodden
2020-07-28 12:46     ` Daniel Stodden

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=20200728094037.GA980@ninjato \
    --to=wsa@kernel.org \
    --cc=daniel.stodden@gmail.com \
    --cc=dns@arista.com \
    --cc=jdelvare@suse.de \
    --cc=linux-i2c@vger.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 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.