RE: [PATCH] drivers:staging:ti-st: remove st_get_plat_device

[Savoy, Pavan]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/