Arnd Bergmann wrote at Thursday, September 01, 2011 5:07 AM: > On Thursday 01 September 2011, Jonathan Cameron wrote: > > On 08/31/11 20:45, Andrew Chew wrote: > > >> Subject: [PATCH 1/3] staging:iio:magnetometer:ak8975 Don't > > >> use irq_to_gpio() > > >> > > >> Tegra doesn't have irq_to_gpio() any more, and ak8975 is included in > > >> tegra_defconfig. This causes a build failure. Solve this with > > >> a heavy-handed > > >> method for now. > > >> > > >> I suspect the long-term solution is to pass both the IRQ and GPIO IDs > > >> to the driver; the GPIO ID coming from either platform data, > > >> or perhaps > > >> enhancing struct i2c_client to add a gpio field alongside irq. > > >> > > >> Signed-off-by: Stephen Warren <swarren@xxxxxxxxxx> > > >> --- > > > > > > The three patches in this set LGTM. > > > > > > Acked-by: Andrew Chew <achew@xxxxxxxxxx> > > > > > > > Hmm.. I'd like to see some means of passing that in. Perhaps as simple as passing > > a pointer to an int in as platform_data. Patch to follow. > > My feeling is that we should just add another field to > struct i2c_client. There are probably more drivers that > need the same thing, making it appropriate to increase > the size of that struct for everything device instead of > adding platform_data to a subset of the devices. That sounds reasonable to me. One question: When we add this field, how do drivers tell whether a value of 0 is an uninitialized field, or a legitimate GPIO value of 0? Should we add a flag to indicate validity, or just work hard to not enable driver- side code to use this value until we've fixed up all places that instantiate the driver to initialize the field to some invalid value like -1? -- nvpublic _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
