From: Greg KH <gregkh@suse.de>
To: "Savoy, Pavan" <pavan_savoy@ti.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"devel@driverdev.osuosl.org" <devel@driverdev.osuosl.org>
Subject: Re: [PATCH] drivers:staging:ti-st: remove st_get_plat_device
Date: Mon, 30 Aug 2010 21:11:14 -0700 [thread overview]
Message-ID: <20100831041114.GA16009@suse.de> (raw)
In-Reply-To: <19F8576C6E063C45BE387C64729E7394046836CB57@dbde02.ent.ti.com>
On Tue, Aug 31, 2010 at 03:39:00AM +0530, Savoy, Pavan wrote:
> Greg,
>
>
>
> > -----Original Message-----
> > From: Greg KH [mailto:gregkh@suse.de]
> > Sent: Saturday, August 21, 2010 10:33 PM
> > To: Savoy, Pavan
> > Cc: Randy Dunlap; 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 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@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.
> >
> > 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?
Nope, sorry. I got sick and combined with vacation requirements from
the family, and my "real job" and other things lately, I hope to get to
it by the end of this week. If not, kick me, I'll have time on a
trans-continent flight next week that should give me plenty of time to
do this...
thanks,
greg k-h
next prev parent reply other threads:[~2010-08-31 4:11 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-19 18:08 [PATCH] drivers:staging:ti-st: remove st_get_plat_device pavan_savoy
2010-08-19 17:32 ` Randy Dunlap
2010-08-19 17:35 ` Savoy, Pavan
2010-08-19 17:37 ` Randy Dunlap
2010-08-22 1:50 ` Pavan Savoy
2010-08-22 3:32 ` Greg KH
2010-08-30 22:09 ` Savoy, Pavan
2010-08-31 4:11 ` Greg KH [this message]
2010-08-31 22:23 ` Savoy, Pavan
2010-08-31 22:42 ` Greg KH
2010-09-07 21:08 ` Savoy, Pavan
2010-09-08 6:27 ` Anca Emanuel
2010-09-08 14:39 ` Savoy, Pavan
2010-09-08 19:03 ` Anca Emanuel
2010-09-08 19:05 ` Savoy, Pavan
2010-09-21 17:34 ` Anca Emanuel
2010-09-21 17:37 ` Greg KH
2010-09-21 18:06 ` Anca Emanuel
2010-09-21 18:12 ` Greg KH
2010-09-21 18:18 ` Savoy, Pavan
2010-09-21 20:06 ` Greg KH
2010-09-21 18:23 ` Anca Emanuel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100831041114.GA16009@suse.de \
--to=gregkh@suse.de \
--cc=devel@driverdev.osuosl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pavan_savoy@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox