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] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 2 Jun 2010 06:18:57 -0400
From:	Mike Frysinger <vapier.adi@...il.com>
To:	Sonic Zhang <sonic.adi@...il.com>
Cc:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Liam Girdwood <lrg@...mlogic.co.uk>,
	uclinux-dist-devel <uclinux-dist-devel@...ckfin.uclinux.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [Uclinux-dist-devel] [PATCH v2] regulator: new drivers for AD5398 
	and AD5821

On Wed, Jun 2, 2010 at 06:10, Sonic Zhang wrote:
> On Wed, Jun 2, 2010 at 5:36 PM, Mike Frysinger wrote:
>> On Wed, Jun 2, 2010 at 05:29, Sonic Zhang wrote:
>>> On Wed, Jun 2, 2010 at 5:02 PM, Mike Frysinger wrote:
>>>> On Wed, Jun 2, 2010 at 04:51, sonic zhang wrote:
>>>>> +static const struct ad5398_current_data_format ad5398_df = {10, 4};
>>>>> +static const struct ad5398_current_data_format ad5821_df = {10, 4};
>>>>> +
>>>>> +static const struct i2c_device_id ad5398_id[] = {
>>>>> +       { "ad5398", (kernel_ulong_t)&ad5398_df },
>>>>> +       { "ad5821", (kernel_ulong_t)&ad5821_df },
>>>>> +       { }
>>>>> +};
>>>>
>>>> do you really need sep storage for these _df vars ?
>>>
>>> Yes, this makes probe code simpler.
>>
>> how does it make any difference to the probe code what each id is
>> pointing to ?  it isnt comparing the private data pointers to any
>> other storage pointers.
>>
>> from what i can see, this should give the same exact behavior:
>> static const struct ad5398_current_data_format df_10_4 = {10, 4};
>> static const struct i2c_device_id ad5398_id[] = {
>>       { "ad5398", (kernel_ulong_t)&df_10_4 },
>>       { "ad5821", (kernel_ulong_t)&df_10_4 },
>
> Yes, the behavior is the same for ad5398 and ad5821. But, if more
> chips are enabled in this driver, they may differ.
> This line is used as an example for future chips.

seems like a weak reason for otherwise useless overhead.  especially
considering my simpler example should also be pretty obvious to extend
for future drivers should the need arise.  you're a smart guy and dont
need things spelled out explicitly.
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ