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>
---
 drivers/staging/ti-st/st.h      |    1 -
 drivers/staging/ti-st/st_core.c |    9 ++++-----
 drivers/staging/ti-st/st_core.h |    2 +-
 drivers/staging/ti-st/st_kim.c  |   22 +++++++++++++++++++---
 4 files changed, 24 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/ti-st/st.h b/drivers/staging/ti-st/st.h
index 9952579..1b3060e 100644
--- a/drivers/staging/ti-st/st.h
+++ b/drivers/staging/ti-st/st.h
@@ -80,5 +80,4 @@ struct st_proto_s {
 extern long st_register(struct st_proto_s *);
 extern long st_unregister(enum proto_type);
 
-extern struct platform_device *st_get_plat_device(void);
 #endif /* ST_H */
diff --git a/drivers/staging/ti-st/st_core.c b/drivers/staging/ti-st/st_core.c
index 063c9b1..b85d8bf 100644
--- a/drivers/staging/ti-st/st_core.c
+++ b/drivers/staging/ti-st/st_core.c
@@ -38,7 +38,6 @@
 #include "st_ll.h"
 #include "st.h"
 
-#define VERBOSE
 /* strings to be used for rfkill entries and by
  * ST Core to be used for sysfs debug entry
  */
@@ -581,7 +580,7 @@ long st_register(struct st_proto_s *new_proto)
 	long err = 0;
 	unsigned long flags = 0;
 
-	st_kim_ref(&st_gdata);
+	st_kim_ref(&st_gdata, 0);
 	pr_info("%s(%d) ", __func__, new_proto->type);
 	if (st_gdata == NULL || new_proto == NULL || new_proto->recv == NULL
 	    || new_proto->reg_complete_cb == NULL) {
@@ -713,7 +712,7 @@ long st_unregister(enum proto_type type)
 
 ...
[ message continues ]

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:

+#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


-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
--

[ message continues ]

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.
--

[ message continues ]

OK, thanks.



-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
--

[ message continues ]

Yes, I will work on it, sorry, been swamped with other work lately.

Don't worry, this patch is in my "to-apply" queue.

thanks,

greg k-h
--

[ message continues ]

Any update on this?
--

[ message continues ]

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
--

[ message continues ]

Gzee Thanks, so since you added the patch now, I guess you will be reviewing
--

[ message continues ]

Yes, I will try to do that.

thanks,

greg k-h
--

[ message continues ]

--

[ message continues ]

Build error (kernel 2.6.36-rc3-git1):


Building modules, stage 2.
  MODPOST 3056 modules
ERROR: "st_get_plat_device" [drivers/staging/ti-st/st_drv.ko] undefined!
--

[ message continues ]

Emanuel,

I've recently posted a patch to solve this problem.
Patch @ http://lkml.org/lkml/2010/8/19/238
 
PS: In fact it is strange that you replied to the same thread which is supposed to solve the problem.

--

[ message continues ]

Linus, this patch is not in your tree.

please fix this.

--

[ message continues ]

I don't think it needs to be for now.
It will get merged upon next update from linux-next.

--

[ message continues ]

> It is currently in linux-next.

Greg,

you send some pull requests to Linus.
Can you compile the kernel without this patch ?

see here:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.36-rc5-maverick/0002-DISABLE-ti-st....

I know you are overburned. Just get 1 or 2 guys to teach them to help you.
--

[ message continues ]

I still don't understand, what does that patch have to do with the
staging tree?

thanks,

greg k-h
--

[ message continues ]

In Ubuntu, the ti-st driver have a problem at the building time.
--

[ message continues ]

Ok, then in Ubuntu, don't enable it in the configuration file, no need
to comment out the whole directory :)

Is there a specific patch that fixes this issue that is not around?  Or
is it already in my staging-next tree and you feel it should be added to
the final .36 release?

If so, which one is it?

thanks,

greg k-h
--

[ message continues ]

This patch on the ti-st/ inside staging/ fixes the problem.
It has made it to the linux-next,
--

[ message continues ]

I'll add it to the queue to go to Linus earlier if I get the chance.  If
not, it's not a big deal we can add it to the .36-stable tree.

thanks,

greg k-h
--

[ message continues ]

for the build problem, include it in 2.6.36
no need for more delay.
--

[ message continues ]