Messages in this thread | | | Date | Wed, 2 Mar 2011 15:31:08 +0100 | From | Samuel Ortiz <> | Subject | Re: [PATCH] MFD: ab8500: New ab8500_gpadc APIs and reentrance |
| |
Hi Linus,
On Wed, Mar 02, 2011 at 03:12:31PM +0100, Linus Walleij wrote: > 2011/3/2 Samuel Ortiz <sameo@linux.intel.com>: > > >> +/** > >> + * ab8500_gpadc_get() - returns a reference to the primary AB8500 GPADC > >> + * (i.e. the first GPADC in the instance list) > >> + */ > >> +struct ab8500_gpadc *ab8500_gpadc_get(void) > >> +{ > >> + struct ab8500_gpadc *gpadc; > >> + gpadc = list_first_entry(&ab8500_gpadc_list, struct ab8500_gpadc, node); > >> + > >> + return gpadc; > >> +} > > > This seems really arbitrary. We argued with Mattias about it, and giving > > drivers access to your ADCs means they should somehow have a pointer back to > > the right ADC. That's not the case here, and while it will just work fine > > whenever you have one ADC on your board, you'll probably be relying on some > > sort of device probe order otherwise. > > I guess the solution is to rewrite that function to take a parameter > then, such as: > > struct ab8500_gpadc *ab8500_gpadc_get(char *name) > > If name is then just a strcmpm(dev_name(gpadc->dev), name) > the client use will be something like: > > struct ab8500_gpadc *gpadc = ab8500_gpadc_get("ab8500-gpadc.0"); > > For the first GPDC in the system (unless .init_name is specified > by the ab8500-core when creating the device). > > Fair enough? That's an original solution. It really is hacking around the device model, but at least it's nicer than the original proposal. So, fair enough, yes.
Cheers, Samuel.
-- Intel Open Source Technology Centre http://oss.intel.com/ -- 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/
| |