Greg,
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Wednesday, July 28, 2010 10:24 AM
> To: Savoy, Pavan; [email protected]
> Subject: patch "Staging: ti-st: update ABI and TODO" added to staging-next tree
Is it good enough to be moved out of staging?
I mean the multi-device thingy would be more or less a nice to have feature than being a bug, isn't it?
The ease for me would be once out of staging, I can cleanup the platform device mess too, since our L-O tree needs to be have some patches in the arch/arm/board-XX.c sort of files...
>
> This is a note to let you know that I've just added the patch titled
>
> Staging: ti-st: update ABI and TODO
>
> to my staging-next git tree which can be found at
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-next-2.6.git
> in the staging-next branch.
>
> The patch will show up in the next release of the linux-next tree
> (usually sometime within the next 24 hours during the week.)
>
> The patch will also will be merged in the next major kernel release
> during the merge window.
>
> If you have any questions about this process, please let me know.
>
>
> From 9f912212cd005f9a0a514ae982de915ff94bd765 Mon Sep 17 00:00:00 2001
> From: Pavan Savoy <[email protected]>
> Date: Wed, 28 Jul 2010 02:26:00 -0500
> Subject: Staging: ti-st: update ABI and TODO
>
> update TODO to reflect the items taken care of,
> update ABI to reflect the new debugfs entries exposed.
>
> Signed-off-by: Pavan Savoy <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/staging/ti-st/TODO | 10 +++-------
> drivers/staging/ti-st/sysfs-uim | 12 ++++++++++++
> 2 files changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/staging/ti-st/TODO b/drivers/staging/ti-st/TODO
> index 3f68ea1..6a105ed 100644
> --- a/drivers/staging/ti-st/TODO
> +++ b/drivers/staging/ti-st/TODO
> @@ -11,16 +11,12 @@ a st_register() would know whether the registration from BT/FM or GPS was intend
> 2. Improve upon the way requirement of line discipline is communicated to
> user-space, The current user-space application which open/installs ldisc
> as and when required can be found at,
> -
> http://git.omapzoom.org/?p?atform/hardware/ti/omap3.git;a?ob;f?_st/uim/uim.c;h a16c2c2b5085eb54a1bbc7096d779
> d7594eb11;hb?lair
> +http://dev.omapzoom.org/pub/scm/jsistla/L23-btfm.git
> +branch: UIM
>
> 3. Re-view/Re-work on the locking.
>
> -4. Re-structure to make the ldisc driver more generic for chipsets which mux
> -multiple connectivity (BT, FM, GPS) upon 1 TTY port.
> -
> -5. Remove global references by providing a context which can be moved around the driver like the other
> ldisc drivers. (ldiscs tend to use tty's disc_data and platform devices use the device's driver data)
> -
> -6. Step up and maintain this driver to ensure that it continues
> +4. Step up and maintain this driver to ensure that it continues
> to work. Having the hardware for this is pretty much a
> requirement. If this does not happen, the will be removed in
> the 2.6.35 kernel release.
> diff --git a/drivers/staging/ti-st/sysfs-uim b/drivers/staging/ti-st/sysfs-uim
> index 10311af..626bda5 100644
> --- a/drivers/staging/ti-st/sysfs-uim
> +++ b/drivers/staging/ti-st/sysfs-uim
> @@ -14,3 +14,15 @@ Description:
> uninstallation would be ppolling on this device and listening
> on events which would suggest either to install or un-install
> line discipline
> +
> +What: /sys/kernel/debug/ti-st/version
> +Contact: Pavan Savoy <[email protected]>
> +Description:
> + WiLink chip's ROM version exposed to user-space for some
> + proprietary protocol stacks to make use of.
> +
> +What: /sys/kernel/debug/ti-st/protocols
> +Contact: Pavan Savoy <[email protected]>
> +Description:
> + The reason for chip being ON, the list of protocols registered.
> +
> --
> 1.7.1
>
On Thu, Jul 29, 2010 at 12:49:59PM +0530, Savoy, Pavan wrote:
> Greg,
>
>
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]
> > Sent: Wednesday, July 28, 2010 10:24 AM
> > To: Savoy, Pavan; [email protected]
> > Subject: patch "Staging: ti-st: update ABI and TODO" added to staging-next tree
>
> Is it good enough to be moved out of staging?
I don't know, I haven't reviewed it. Do you want me to do so? It looks
like you still have a number of things on your TODO list, why not
resolve those first?
> I mean the multi-device thingy would be more or less a nice to have
> feature than being a bug, isn't it?
I don't think Alan thinks so.
> The ease for me would be once out of staging, I can cleanup the
> platform device mess too, since our L-O tree needs to be have some
> patches in the arch/arm/board-XX.c sort of files...
Promises to clean up code after it leaves staging is generally not a
good idea :)
thanks,
greg k-h
> > I mean the multi-device thingy would be more or less a nice to have
> > feature than being a bug, isn't it?
>
> I don't think Alan thinks so.
Having the infrastructure that makes it trivial to do right is important.
Actually doing the final bits to make it happen may not make sense -
especially if it can't be tested currently.
Alan
> -----Original Message-----
> From: Greg KH [mailto:[email protected]]
> Sent: Thursday, July 29, 2010 9:53 AM
> To: Savoy, Pavan
> Cc: [email protected]
> Subject: Re: patch "Staging: ti-st: update ABI and TODO" added to staging-next tree
>
> On Thu, Jul 29, 2010 at 12:49:59PM +0530, Savoy, Pavan wrote:
> > Greg,
> >
> >
> > > -----Original Message-----
> > > From: [email protected] [mailto:[email protected]]
> > > Sent: Wednesday, July 28, 2010 10:24 AM
> > > To: Savoy, Pavan; [email protected]
> > > Subject: patch "Staging: ti-st: update ABI and TODO" added to staging-next tree
> >
> > Is it good enough to be moved out of staging?
>
> I don't know, I haven't reviewed it. Do you want me to do so? It looks
> like you still have a number of things on your TODO list, why not
> resolve those first?
The major thing on the TODO list was this multiple device support.
The rest is taken care, I will send out a patch to update the TODO itself!!
So, Please review and provide comment as to what should be done to move it out of staging into may be drivers/misc? or mfd/ suggest a suitable place holder too.
> > I mean the multi-device thingy would be more or less a nice to have
> > feature than being a bug, isn't it?
>
> I don't think Alan thinks so.
As Alan mentioned this is currently un-testable since we don't have such platforms with multiple of these connectivity chipsets.
> > The ease for me would be once out of staging, I can cleanup the
> > platform device mess too, since our L-O tree needs to be have some
> > patches in the arch/arm/board-XX.c sort of files...
>
> Promises to clean up code after it leaves staging is generally not a
> good idea :)
Not a clean up as such but pending patches such as addition of the platform device into the arch/arm/mach-omap2/board-4430sdp.c file or board-zoom2.c file.
Or the V4L2 FM drivers for the FM core on chip, which makes use of this ldisc..
This is to make sure that any Linux release built for such boards have this driver up and running for the device.
I have cleaned-up all I can, I suppose :)
> thanks,
>
> greg k-h