On Mon, Jan 30, 2012 at 10:22 PM, Mark Brown
<broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> On Mon, Jan 30, 2012 at 08:26:10PM +0000, Jonathan Cameron wrote:
>> On 01/30/2012 07:33 PM, Mark Brown wrote:
>> > On Sun, Jan 29, 2012 at 11:46:54AM +0000, Jonathan Cameron wrote:
>
>> >> +static struct iio_map max1363_consumer_map[] = { + { +
>> >> .adc_channel_label = "AIN1", + .consumer_dev =
>> >> &iio_hwmon_test.dev, + .consumer_channel = "testchan1",
>
>> > I do think it's better to use dev_name here rather than a struct
>> > device pointer - for several of the buses it's not actually
>> > possible to get a struct device until a device has been
>> > instantiated which isn't helpful for setting up the mappings.
>
>> We allow both. In cases like this where the dev pointer is explicitly
>> available what gain do we get from not using it?
>
> You avoid user confusion from having two ways of doing the same thing
> and you save a little complexity in the implementation. The user
> confusion does happen in practice.
The clockdev API is stricter and only allows for names I noticed.
So I guess this pattern comes from the regulator framework
struct regulator_consumer_supply design pattern initially.
We allow both struct device * in regulators and pin muxes.
So, not having it for ADCs could be confusing as well.
But we should then try to rid it from the kernel at large, no big deal,
I have only one in-kernel user of this ATM I think so I can kill it off from
the pin control API if you think you can kill it from regulators.
I just want to make sure that this is the direction we want to go...
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
