On Wed, May 26, 2010 at 02:37:28PM -0600, Grant Likely wrote:
> 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?
A bool/int should be sufficient.
> 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.
Ok, so I should wrap the OF detection code in CONFIG_OF in my driver,
right? I just quickly browsed through the code, and it seems like it
should be straightforward to use pdata and then fall back on OF data.
Jean, give me a few hours to cook up another patch, now that I have this
information from Grant.
Thanks for the quick reply!
Ira
_______________________________________________
lm-sensors mailing list
lm-sensors@xxxxxxxxxxxxxx
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
