From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>,
Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Krzysztof Kozlowski <krzk@kernel.org>,
linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel@pengutronix.de
Subject: Re: [PATCH RFC] i2c: Add a void pointer to i2c_device_id
Date: Mon, 29 Apr 2024 11:54:29 +0300 [thread overview]
Message-ID: <Zi9gRVVw7qbKSL5k@smile.fi.intel.com> (raw)
In-Reply-To: <20240426213832.915485-2-u.kleine-koenig@pengutronix.de>
On Fri, Apr 26, 2024 at 11:38:33PM +0200, Uwe Kleine-König wrote:
> Traditionally a struct i2c_device_id has a kernel_ulong_t member to
> store some chip variant data. Some drivers use it to store an enum,
> others to store a pointer. In the latter case there is some ugly(?)
> casting involved. To improve that, add a void pointer in an anonymous
> union together with the integer driver_data.
>
> This way a i2c_device_id requires usage of a designated initializer when
> the driver_data or data member should be initialized, but IMHO that's
> fine and you might even consider that an advantage.
...
> static const struct i2c_device_id wlf_gf_module_id[] = {
> - { "wlf-gf-module", 0 },
> + { "wlf-gf-module", },
In such cases the inner comma is redundant as well.
> { }
> };
...
In general idea might be okay, but I always have the same Q (do we have it
being clarified in the documentation, btw): is an ID table the ABI or not?
In another word, how should we treat the changes there, because ID tables
are being used by the user space tools.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2024-04-29 8:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-26 21:38 [PATCH RFC] i2c: Add a void pointer to i2c_device_id Uwe Kleine-König
2024-04-29 8:54 ` Andy Shevchenko [this message]
2024-04-29 10:21 ` Uwe Kleine-König
2024-04-29 10:28 ` Andy Shevchenko
2024-04-29 13:55 ` Uwe Kleine-König
2024-04-29 15:17 ` Andy Shevchenko
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=Zi9gRVVw7qbKSL5k@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=kernel@pengutronix.de \
--cc=krzk@kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=u.kleine-koenig@pengutronix.de \
--cc=wsa+renesas@sang-engineering.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.