On Wed, May 26, 2010 at 1:39 PM, Ira W. Snyder <iws@xxxxxxxxxxxxxxxx> wrote:
> On Wed, May 26, 2010 at 08:42:22PM +0200, Jean Delvare wrote:
>> On Wed, 26 May 2010 10:22:44 -0700, Ira W. Snyder wrote:
>> > On Wed, May 26, 2010 at 06:36:59PM +0200, Jean Delvare wrote:
>> > > Sorry for not being clear. I wasn't objecting to the stub's existence,
>> > > but to the fact that it was doing something. I expected it to do
>> > > nothing at all, and ltc4245_show_voltage() would be used for in9.
>> >
>> > Oh, ok. The ltc4245_show_voltage() function reads the voltage register
>> > values directly from data->vregs[]. When the extra GPIO inputs are
>> > enabled, I have two choices:
>> >
>> > 1) store them in the new data->gpios[] array
>> > 2) store them in data->vregs[]
>> >
>> > For #1, ltc4245_show_voltage() doesn't work anymore, since it reads
>> > voltage register values from data->vregs[].
>> >
>> > For #2, I would have to re-expand data->vregs[] to include all of the
>> > GPIO inputs, like it was before. Also, I would need to make
>> > ltc4245_get_voltage() handle the -EAGAIN error code.
>> >
>> > I think the code is easier to understand if all the GPIOs are treated in
>> > the same way, and not completely special for GPIOADC1 vs GPIOADC[23].
>> > That's why I chose #1.
>> >
>> > If I do a hybrid approach (store GPIOADC1 in data->vregs[] and
>> > GPIOADC[23] in data->gpios[]), then I have to make ltc4245_get_voltage()
>> > robust against errors too. Is this what you're suggesting?
>>
>> No. But let's wait and see if you move to OF platform data, the whole
>> question will be moot. If you keep the config option approach, I'll
>> propose an iterative patch and we can discuss it then.
>>
>> > (...)
>> > Any thoughts about the kernel config option vs. platform data, and how
>> > it relates to the OF bindings?
>>
>> I would prefer platform-data-based. But I fear I don't know anything
>> about OF bindings. Better ask the embedded folks (e.g. Grant Likely),
>> they will know.
>>
>
> Grant, you're listed in MAINTAINERS as the OF bindings maintainer. Is it
> currently possible for the i2c OF binding to pass platform_data to hwmon
> drivers that are probed via the device tree? If so, can you point me to
> an example. If not, can you suggest what I should do?
>
> Here is a short example from my device tree (a lightly modified 834x_mds
> device tree):
>
> i2c@3100 {
> #address-cells = <1>;
> #size-cells = <0>;
> cell-index = <1>;
> compatible = "fsl-i2c";
> reg = <0x3100 0x100>;
> interrupts = <15 0x8>;
> interrupt-parent = <&ipic>;
> clock-frequency = <400000>;
>
> ltc4245@XX {
> compatible = "LLTC,ltc4245";
> reg = <0>; // from bootloader
> };
> };
>
> I'd like to be able to send platform data to the drivers/hwmon/ltc4245.c
> driver. On my platform, this is probed automatically using the device
> tree snippet above.
What is in the platform data? As of the .35 merge window, the device
node pointer lives in struct device, so it is available to all Linux
device drivers if CONFIG_OF is set. If it is simply data that needs
to be passed, then the driver itself can extract it from the tree in
the absence of pdata. If you need to pass function pointers or the
like, then probably the best thing to do is to register a bus notifier
in the platform code before registering devices. That way the
platform code can intercept the device and register pdata before the
device is bound to a driver.
g.
_______________________________________________
lm-sensors mailing list
lm-sensors@xxxxxxxxxxxxxx
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
