All of lore.kernel.org
 help / color / mirror / Atom feed
From: Randy Dunlap <randy.dunlap@oracle.com>
To: pavan_savoy@ti.com
Cc: gregkh@suse.de, alan@lxorguk.ukuu.org.uk,
	linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org,
	naveen_jain@ti.com
Subject: Re: [PATCH] drivers:staging:ti-st: remove st_get_plat_device
Date: Thu, 19 Aug 2010 10:32:10 -0700	[thread overview]
Message-ID: <4C6D6A9A.3010409@oracle.com> (raw)
In-Reply-To: <1282241331-5178-1-git-send-email-pavan_savoy@ti.com>

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:

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


> ---
>  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)
>  
>  	pr_debug("%s: %d ", __func__, type);
>  
> -	st_kim_ref(&st_gdata);
> +	st_kim_ref(&st_gdata, 0);
>  	if (type < ST_BT || type >= ST_MAX) {
>  		pr_err(" protocol %d not supported", type);
>  		return -EPROTONOSUPPORT;
> @@ -767,7 +766,7 @@ long st_write(struct sk_buff *skb)
>  #endif
>  	long len;
>  
> -	st_kim_ref(&st_gdata);
> +	st_kim_ref(&st_gdata, 0);
>  	if (unlikely(skb == NULL || st_gdata == NULL
>  		|| st_gdata->tty == NULL)) {
>  		pr_err("data/tty unavailable to perform write");
> @@ -818,7 +817,7 @@ static int st_tty_open(struct tty_struct *tty)
>  	struct st_data_s *st_gdata;
>  	pr_info("%s ", __func__);
>  
> -	st_kim_ref(&st_gdata);
> +	st_kim_ref(&st_gdata, 0);
>  	st_gdata->tty = tty;
>  	tty->disc_data = st_gdata;
>  
> diff --git a/drivers/staging/ti-st/st_core.h b/drivers/staging/ti-st/st_core.h
> index e0c32d1..8601320 100644
> --- a/drivers/staging/ti-st/st_core.h
> +++ b/drivers/staging/ti-st/st_core.h
> @@ -117,7 +117,7 @@ int st_core_init(struct st_data_s **);
>  void st_core_exit(struct st_data_s *);
>  
>  /* ask for reference from KIM */
> -void st_kim_ref(struct st_data_s **);
> +void st_kim_ref(struct st_data_s **, int);
>  
>  #define GPS_STUB_TEST
>  #ifdef GPS_STUB_TEST
> diff --git a/drivers/staging/ti-st/st_kim.c b/drivers/staging/ti-st/st_kim.c
> index b4a6c7f..9e99463 100644
> --- a/drivers/staging/ti-st/st_kim.c
> +++ b/drivers/staging/ti-st/st_kim.c
> @@ -72,11 +72,26 @@ const unsigned char *protocol_names[] = {
>  	PROTO_ENTRY(ST_GPS, "GPS"),
>  };
>  
> +#define MAX_ST_DEVICES	3	/* Imagine 1 on each UART for now */
> +struct platform_device *st_kim_devices[MAX_ST_DEVICES];
>  
>  /**********************************************************************/
>  /* internal functions */
>  
>  /**
> + * st_get_plat_device -
> + *	function which returns the reference to the platform device
> + *	requested by id. As of now only 1 such device exists (id=0)
> + *	the context requesting for reference can get the id to be
> + *	requested by a. The protocol driver which is registering or
> + *	b. the tty device which is opened.
> + */
> +static struct platform_device *st_get_plat_device(int id)
> +{
> +	return st_kim_devices[id];
> +}
> +
> +/**
>   * validate_firmware_response -
>   *	function to return whether the firmware response was proper
>   *	in case of error don't complete so that waiting for proper
> @@ -353,7 +368,7 @@ void st_kim_chip_toggle(enum proto_type type, enum kim_gpio_state state)
>  	struct kim_data_s	*kim_gdata;
>  	pr_info(" %s ", __func__);
>  
> -	kim_pdev = st_get_plat_device();
> +	kim_pdev = st_get_plat_device(0);
>  	kim_gdata = dev_get_drvdata(&kim_pdev->dev);
>  
>  	if (kim_gdata->gpios[type] == -1) {
> @@ -574,12 +589,12 @@ static int kim_toggle_radio(void *data, bool blocked)
>   *	This would enable multiple such platform devices to exist
>   *	on a given platform
>   */
> -void st_kim_ref(struct st_data_s **core_data)
> +void st_kim_ref(struct st_data_s **core_data, int id)
>  {
>  	struct platform_device	*pdev;
>  	struct kim_data_s	*kim_gdata;
>  	/* get kim_gdata reference from platform device */
> -	pdev = st_get_plat_device();
> +	pdev = st_get_plat_device(id);
>  	kim_gdata = dev_get_drvdata(&pdev->dev);
>  	*core_data = kim_gdata->core_data;
>  }
> @@ -623,6 +638,7 @@ static int kim_probe(struct platform_device *pdev)
>  	long *gpios = pdev->dev.platform_data;
>  	struct kim_data_s	*kim_gdata;
>  
> +	st_kim_devices[pdev->id] = pdev;
>  	kim_gdata = kzalloc(sizeof(struct kim_data_s), GFP_ATOMIC);
>  	if (!kim_gdata) {
>  		pr_err("no mem to allocate");


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

  reply	other threads:[~2010-08-19 17:32 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 [this message]
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
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=4C6D6A9A.3010409@oracle.com \
    --to=randy.dunlap@oracle.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=naveen_jain@ti.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.