All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@ti.com>
To: Jon Hunter <jon-hunter@ti.com>
Cc: linux-omap <linux-omap@vger.kernel.org>,
	linux-arm <linux-arm-kernel@lists.infradead.org>,
	Grant Likely <grant.likely@secretlab.ca>,
	Linus Walleij <linus.walleij@stericsson.com>,
	Tarun Kanti DebBarma <tarun.kanti@ti.com>,
	Franky Lin <frankyl@broadcom.com>, NeilBrown <neilb@suse.de>
Subject: Re: [PATCH] gpio/omap: fix invalid context restore of gpio bank-0
Date: Mon, 02 Jul 2012 11:07:44 -0700	[thread overview]
Message-ID: <87mx3i595b.fsf@ti.com> (raw)
In-Reply-To: <1340990551-19426-1-git-send-email-jon-hunter@ti.com> (Jon Hunter's message of "Fri, 29 Jun 2012 12:22:31 -0500")

+ Neil Brown

Hi Jon,

Jon Hunter <jon-hunter@ti.com> writes:

> Currently the gpio _runtime_resume/suspend functions are calling the
> get_context_loss_count() platform function if the function is populated for
> a gpio bank. This function is used to determine if the gpio bank logic state
> needs to be restored due to a power transition. This function will be populated
> for all banks, but it should only be called for banks that have the
> "loses_context" variable set. It is pointless to call this if loses_context is
> false as we know the context will never be lost and will not need restoring.
>
> For all OMAP2+ devices gpio bank-0 is in an always-on power domain and so will
> never lose context. We found that the get_context_loss_count() was being called
> for bank-0 during the probe and returning 1 instead of 0 indicating that the
> context had been lost. This was causing the context restore function to be
> called at probe time for this bank and because the context had never been saved,
> was restoring an invalid state. This ultimately resulted in a crash [1].
>
> There are multiple bugs here that need to be addressed ...
>
> 1. Why the always-on power domain returns a context loss count of 1? This needs
>    to be fixed in the power domain code. However, the gpio driver should not
>    assume the loss count is 0 to begin with.
> 2. The omap gpio driver should never be calling get_context_loss_count for a
>    gpio bank in a always-on domain. This is pointless and adds unneccessary
>    overhead.
> 3. The OMAP gpio driver assumes that the initial power domain context loss count
>    will be 0 at the time the gpio driver is probed. However, it could be
>    possible that this is not the case and an invalid context restore could be
>    performed during the probe. To avoid this otherwise only populated the

The 'To avoid this...' sentence here doesn't read well.  Looks like you
need to:

s/otherwise//
s/populated/populate/

?

>    get_context_loss_count() function pointer after the initial call to
>    pm_runtime_get() has occurred. This will ensure that the first
>    pm_runtime_put() initialised the loss count correctly.
>
> This patch addresses issues 2 and 3 above.
> [1] http://marc.info/?l=linux-omap&m=134065775323775&w=2
>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Linus Walleij <linus.walleij@stericsson.com>
> Cc: Kevin Hilman <khilman@ti.com>
> Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
> Cc: Franky Lin <frankyl@broadcom.com>
>
> Reported-by: Franky Lin <frankyl@broadcom.com>
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>

Thanks for digging inot this bug Jon.  The same bug was brought up by
Neil Brown (Cc'd) in a different thread.

Neil, it looks to me that this fix will address the problems you were
seeing as well.  Care to test, and respond with your ack/tested-by if it
works for you?  Thanks.

Kevin

> ---
>  drivers/gpio/gpio-omap.c |    4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index c4ed172..f13fc9c 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -1081,7 +1081,6 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
>  	bank->is_mpuio = pdata->is_mpuio;
>  	bank->non_wakeup_gpios = pdata->non_wakeup_gpios;
>  	bank->loses_context = pdata->loses_context;
> -	bank->get_context_loss_count = pdata->get_context_loss_count;
>  	bank->regs = pdata->regs;
>  #ifdef CONFIG_OF_GPIO
>  	bank->chip.of_node = of_node_get(node);
> @@ -1135,6 +1134,9 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
>  	omap_gpio_chip_init(bank);
>  	omap_gpio_show_rev(bank);
>  
> +	if (bank->loses_context)
> +		bank->get_context_loss_count = pdata->get_context_loss_count;
> +
>  	pm_runtime_put(bank->dev);
>  
>  	list_add_tail(&bank->node, &omap_gpio_list);

WARNING: multiple messages have this Message-ID (diff)
From: khilman@ti.com (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] gpio/omap: fix invalid context restore of gpio bank-0
Date: Mon, 02 Jul 2012 11:07:44 -0700	[thread overview]
Message-ID: <87mx3i595b.fsf@ti.com> (raw)
In-Reply-To: <1340990551-19426-1-git-send-email-jon-hunter@ti.com> (Jon Hunter's message of "Fri, 29 Jun 2012 12:22:31 -0500")

+ Neil Brown

Hi Jon,

Jon Hunter <jon-hunter@ti.com> writes:

> Currently the gpio _runtime_resume/suspend functions are calling the
> get_context_loss_count() platform function if the function is populated for
> a gpio bank. This function is used to determine if the gpio bank logic state
> needs to be restored due to a power transition. This function will be populated
> for all banks, but it should only be called for banks that have the
> "loses_context" variable set. It is pointless to call this if loses_context is
> false as we know the context will never be lost and will not need restoring.
>
> For all OMAP2+ devices gpio bank-0 is in an always-on power domain and so will
> never lose context. We found that the get_context_loss_count() was being called
> for bank-0 during the probe and returning 1 instead of 0 indicating that the
> context had been lost. This was causing the context restore function to be
> called at probe time for this bank and because the context had never been saved,
> was restoring an invalid state. This ultimately resulted in a crash [1].
>
> There are multiple bugs here that need to be addressed ...
>
> 1. Why the always-on power domain returns a context loss count of 1? This needs
>    to be fixed in the power domain code. However, the gpio driver should not
>    assume the loss count is 0 to begin with.
> 2. The omap gpio driver should never be calling get_context_loss_count for a
>    gpio bank in a always-on domain. This is pointless and adds unneccessary
>    overhead.
> 3. The OMAP gpio driver assumes that the initial power domain context loss count
>    will be 0 at the time the gpio driver is probed. However, it could be
>    possible that this is not the case and an invalid context restore could be
>    performed during the probe. To avoid this otherwise only populated the

The 'To avoid this...' sentence here doesn't read well.  Looks like you
need to:

s/otherwise//
s/populated/populate/

?

>    get_context_loss_count() function pointer after the initial call to
>    pm_runtime_get() has occurred. This will ensure that the first
>    pm_runtime_put() initialised the loss count correctly.
>
> This patch addresses issues 2 and 3 above.
> [1] http://marc.info/?l=linux-omap&m=134065775323775&w=2
>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Linus Walleij <linus.walleij@stericsson.com>
> Cc: Kevin Hilman <khilman@ti.com>
> Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
> Cc: Franky Lin <frankyl@broadcom.com>
>
> Reported-by: Franky Lin <frankyl@broadcom.com>
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>

Thanks for digging inot this bug Jon.  The same bug was brought up by
Neil Brown (Cc'd) in a different thread.

Neil, it looks to me that this fix will address the problems you were
seeing as well.  Care to test, and respond with your ack/tested-by if it
works for you?  Thanks.

Kevin

> ---
>  drivers/gpio/gpio-omap.c |    4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index c4ed172..f13fc9c 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -1081,7 +1081,6 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
>  	bank->is_mpuio = pdata->is_mpuio;
>  	bank->non_wakeup_gpios = pdata->non_wakeup_gpios;
>  	bank->loses_context = pdata->loses_context;
> -	bank->get_context_loss_count = pdata->get_context_loss_count;
>  	bank->regs = pdata->regs;
>  #ifdef CONFIG_OF_GPIO
>  	bank->chip.of_node = of_node_get(node);
> @@ -1135,6 +1134,9 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev)
>  	omap_gpio_chip_init(bank);
>  	omap_gpio_show_rev(bank);
>  
> +	if (bank->loses_context)
> +		bank->get_context_loss_count = pdata->get_context_loss_count;
> +
>  	pm_runtime_put(bank->dev);
>  
>  	list_add_tail(&bank->node, &omap_gpio_list);

  parent reply	other threads:[~2012-07-02 18:07 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-29 17:22 [PATCH] gpio/omap: fix invalid context restore of gpio bank-0 Jon Hunter
2012-06-29 17:22 ` Jon Hunter
2012-06-29 20:27 ` Franky Lin
2012-06-29 20:27   ` Franky Lin
2012-06-30  4:18 ` Shilimkar, Santosh
2012-06-30  4:18   ` Shilimkar, Santosh
2012-07-01  8:45   ` Tony Lindgren
2012-07-01  8:45     ` Tony Lindgren
2012-07-02 18:22     ` Jon Hunter
2012-07-02 18:22       ` Jon Hunter
2012-07-02 18:07 ` Kevin Hilman [this message]
2012-07-02 18:07   ` Kevin Hilman
2012-07-02 18:26   ` Jon Hunter
2012-07-02 18:26     ` Jon Hunter
2012-07-02 23:34     ` NeilBrown
2012-07-02 23:34       ` NeilBrown
2012-07-03  0:05       ` Kevin Hilman
2012-07-03  0:05         ` Kevin Hilman
2012-07-03  0:20         ` Jon Hunter
2012-07-03  0:20           ` Jon Hunter

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=87mx3i595b.fsf@ti.com \
    --to=khilman@ti.com \
    --cc=frankyl@broadcom.com \
    --cc=grant.likely@secretlab.ca \
    --cc=jon-hunter@ti.com \
    --cc=linus.walleij@stericsson.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=tarun.kanti@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.