> Greg,
>
> On Thu, Aug 19, 2010 at 11:07 PM, Randy Dunlap <randy.dunlap@oracle.com> wrote:
> > On 08/19/10 10:35, Savoy, Pavan wrote:
> >> Randy,
> >>
> >>
> >>> -----Original Message-----
> >>> From: Randy Dunlap [mailto:randy.dunlap@oracle.com]
> >>> Sent: Thursday, August 19, 2010 12:32 PM
> >>> To: Savoy, Pavan
> >>> Cc: gregkh@suse.de; alan@lxorguk.ukuu.org.uk; linux-kernel@vger.kernel.org;
> >>> devel@driverdev.osuosl.org; Jain, Naveen
> >>> Subject: Re: [PATCH] drivers:staging:ti-st: remove st_get_plat_device
> >>>
> >>> On 08/19/10 11:08,
pavan_savoy@ti.com wrote:
> >>>> From: Pavan Savoy <pavan_savoy@ti.com>
> >>>>
> >>>> 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@ti.com>
> >>>
> >>> 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@oracle.com>
>
>
> 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.