Greg, > -----Original Message----- > From: Greg KH [mailto:gregkh@xxxxxxx] > Sent: Saturday, August 21, 2010 10:33 PM > To: Savoy, Pavan > Cc: Randy Dunlap; alan@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > devel@xxxxxxxxxxxxxxxxxxxx; Jain, Naveen > Subject: Re: [PATCH] drivers:staging:ti-st: remove st_get_plat_device > > On Sun, Aug 22, 2010 at 07:20:00AM +0530, Pavan Savoy wrote: > > Greg, > > > > On Thu, Aug 19, 2010 at 11:07 PM, Randy Dunlap <randy.dunlap@xxxxxxxxxx> > wrote: > > > On 08/19/10 10:35, Savoy, Pavan wrote: > > >> Randy, > > >> > > >> > > >>> -----Original Message----- > > >>> From: Randy Dunlap [mailto:randy.dunlap@xxxxxxxxxx] > > >>> Sent: Thursday, August 19, 2010 12:32 PM > > >>> To: Savoy, Pavan > > >>> Cc: gregkh@xxxxxxx; alan@xxxxxxxxxxxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx; > > >>> devel@xxxxxxxxxxxxxxxxxxxx; Jain, Naveen > > >>> Subject: Re: [PATCH] drivers:staging:ti-st: remove st_get_plat_device > > >>> > > >>> On 08/19/10 11:08, pavan_savoy@xxxxxx wrote: > > >>>> From: Pavan Savoy <pavan_savoy@xxxxxx> > > >>>> > > >>>> In order to support multiple ST platform devices, a new symbol > > >>>> 'st_get_plat_device' earlier needed to be exported by the arch/XX/brd- > XX.c > > >>>> file which intends to add the ST platform device. > > >>>> > > >>>> On removing this dependency, now inside ST driver maintain the array of > > >>>> ST platform devices that would be registered. > > >>>> As of now let id=0, as and when we end up having such platforms > > >>>> where mutliple ST devices can exist, id would come from > > >>>> protocol drivers (BT, FM and GPS) as to on which platform device > > >>>> they want to register to. > > >>>> > > >>>> Signed-off-by: Pavan Savoy <pavan_savoy@xxxxxx> > > >>> > > >>> Thanks, that builds cleanly. ??I'm OK with it if you are comfortable > with a > > >>> hard limit on the fixed number of devices that can be supported: > > >> > > >> Yep, Thanks for pointing out, sort of cleaned up the code. > > >> > > >>> +#define MAX_ST_DEVICES ?? ?? ??3 ?? ?? ?? /* Imagine 1 on each UART for > now */ > > >>> +struct platform_device *st_kim_devices[MAX_ST_DEVICES]; > > >>> > > >>> We usually try not to have such limits nor use arrays like that, > > >>> but if the nature of the device and its platform/environment is like > > >>> that, so be it. > > >>> > > >> > > >> Actually on all platforms that I have seen there's only 1 such device. > > >> The device is basically a connectivity chip (with Bluetooth, FM and GPS > working > > >> on a single UART) > > >> > > >> The number which I mentioned was out of imagination. > > >> I don't think we are ever going to have multiple of them either... > > > > > > OK, thanks. > > > > > > Acked-by: Randy Dunlap <randy.dunlap@xxxxxxxxxx> > > > > > > Can you please merge this patch ? Also please have a look at the driver and > > suggest what needs to be done to move it out of staging. > > Yes, I will work on it, sorry, been swamped with other work lately. > > Don't worry, this patch is in my "to-apply" queue. Any update on this? Apologize for being annoying, but some patch traffic on the driver is calming :) > thanks, > > greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
