Messages in this thread | | | From | Mike Frysinger <> | Date | Wed, 2 Jun 2010 06:18:57 -0400 | 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |