linux-kernel - Re: [PATCH RFC 1/4] i2c: start migrating to a pointer in i2c_device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ZNuf6UpcyVGjxZ2F@smile.fi.intel.com>
Date:   Tue, 15 Aug 2023 18:55:21 +0300
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:     Wolfram Sang <wsa@...nel.org>, Andi Shyti <andi.shyti@...nel.org>,
        Biju Das <biju.das.jz@...renesas.com>,
        Jonathan Cameron <jic23@...nel.org>,
        Michael Hennerich <michael.hennerich@...log.com>,
        Peter Rosin <peda@...ntia.se>, linux-i2c@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 1/4] i2c: start migrating to a pointer in
 i2c_device_id

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