On Wed, Jun 2, 2010 at 06:10, Sonic Zhang wrote:
quoted text
> 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
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/