From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Wolfram Sang <wsa@kernel.org>, Andi Shyti <andi.shyti@kernel.org>,
Biju Das <biju.das.jz@bp.renesas.com>,
Jonathan Cameron <jic23@kernel.org>,
Michael Hennerich <michael.hennerich@analog.com>,
Peter Rosin <peda@axentia.se>,
linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC 1/4] i2c: start migrating to a pointer in i2c_device_id
Date: Tue, 15 Aug 2023 18:55:21 +0300 [thread overview]
Message-ID: <ZNuf6UpcyVGjxZ2F@smile.fi.intel.com> (raw)
In-Reply-To: <20230814-i2c-id-rework-v1-1-3e5bc71c49ee@gmail.com>
On Mon, Aug 14, 2023 at 02:52:49PM -0700, Dmitry Torokhov wrote:
> The of_device_id structure uses a void pointer to associate additional
> driver-private data with device id, most commonly used to refer to a
> structure containing additional characteristics of a particular chip.
> However i2c_device_id uses an unsigned long. While it can easily be
> converted to a pointer, several drivers use it to store a scalar (and it
> is possible to use a pointer in of_device_id to store a scalar value as
> well). The worst case comes when OF part of a driver uses pointers,
> while legacy part is using scalars, causing constructs like:
>
> data = device_get_match_data(...);
> if (!data)
> data = &some_array[i2c_match_id(...)->data];
> ...
>
> To avoid this introduce a const void "data" pointer to i2c_device_id as
> well, so that we can convert drivers one by one, and drop driver_data
> member in the end.
>
> The end goal is to clean up all helpers and make device_get_match_data()
> work universally for all ACPI, DT, and legacy variants.
So, we have in the parallel the activity to make buses to have a callback,
why do we need this one? Looks to me as yet another 1000+ churn for not
much value. What the good outcome of this is constification, but maybe
we can find the way on how to prove const to stay over the kernel_ulong_t
transformations for all device ID tables?
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2023-08-15 15:56 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-14 21:52 [PATCH RFC 0/4] Start unification of of_device_id and i2c_device_id Dmitry Torokhov
2023-08-14 21:52 ` [PATCH RFC 1/4] i2c: start migrating to a pointer in i2c_device_id Dmitry Torokhov
2023-08-15 15:55 ` Andy Shevchenko [this message]
2023-08-14 21:52 ` [PATCH RFC 2/4] i2c: mux: ltc4306: convert to using " Dmitry Torokhov
2023-08-15 15:50 ` Andy Shevchenko
2023-08-14 21:52 ` [PATCH RFC 3/4] i2c: mux: pca954x: " Dmitry Torokhov
2023-08-15 15:51 ` Andy Shevchenko
2023-08-14 21:52 ` [PATCH RFC 4/4] i2c: slave-eeprom: " Dmitry Torokhov
2023-08-15 15:53 ` 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=ZNuf6UpcyVGjxZ2F@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=andi.shyti@kernel.org \
--cc=biju.das.jz@bp.renesas.com \
--cc=dmitry.torokhov@gmail.com \
--cc=jic23@kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.hennerich@analog.com \
--cc=peda@axentia.se \
--cc=wsa@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox