Re: [PATCH] sdhci-s3c: fix incorrect spinlock usage after merge

2010-09-20 Thread Chris Ball 
Hi Ben,

On Mon, Sep 20, 2010 at 03:03:42PM +0200, Marek Szyprowski wrote:
> In the commit f522886e202a34a2191dd5d471b3c4d46410a9a0 a merge conflict
> in the sdhci-s3c driver been fixed. However the fix used incorrect
> spinlock operation - it cause a race with sdhci interrupt service. The
> correct way to solve it is to use spin_lock_irqsave/irqrestore() calls.
> 
> Signed-off-by: Marek Szyprowski 
> Signed-off-by: Kyungmin Park 
> ---
>  drivers/mmc/host/sdhci-s3c.c |6 --
>  1 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
> index 71ad416..735d431 100644
> --- a/drivers/mmc/host/sdhci-s3c.c
> +++ b/drivers/mmc/host/sdhci-s3c.c
> @@ -241,8 +241,10 @@ static struct sdhci_ops sdhci_s3c_ops = {
>  static void sdhci_s3c_notify_change(struct platform_device *dev, int state)
>  {
>   struct sdhci_host *host = platform_get_drvdata(dev);
> + unsigned long flags;
> +
>   if (host) {
> - spin_lock(&host->lock);
> + spin_lock_irqsave(&host->lock, flags);
>   if (state) {
>   dev_dbg(&dev->dev, "card inserted.\n");
>   host->flags &= ~SDHCI_DEVICE_DEAD;
> @@ -253,7 +255,7 @@ static void sdhci_s3c_notify_change(struct 
> platform_device *dev, int state)
>   host->quirks &= ~SDHCI_QUIRK_BROKEN_CARD_DETECTION;
>   }
>   tasklet_schedule(&host->card_tasklet);
> - spin_unlock(&host->lock);
> + spin_unlock_irqrestore(&host->lock, flags);
>   }
>  }
>  

Could I have your ACK on this before I send it to Linus, please?

Thanks,

-- 
Chris Ball  
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] sdhci-s3c: fix incorrect spinlock usage after merge

2010-09-20 Thread Andrew Morton 
On Tue, 21 Sep 2010 02:17:11 +0100 Chris Ball  wrote:

> On Mon, Sep 20, 2010 at 03:03:42PM +0200, Marek Szyprowski wrote:
> > In the commit f522886e202a34a2191dd5d471b3c4d46410a9a0 a merge conflict
> > in the sdhci-s3c driver been fixed. However the fix used incorrect
> > spinlock operation - it cause a race with sdhci interrupt service. The
> > correct way to solve it is to use spin_lock_irqsave/irqrestore() calls.
> 
> Thanks, applied to mmc-next with:
> Signed-off-by: Chris Ball 
> 
> Andrew, not sure how best to get this upstream -- do you want to send
> this up to Linus (for -rc5) via your queue in -mm?

Ordinarily I'd expect you to send it to Linus.

I tend to merge important-looking bugfixes in my tree in case
maintainers lose them (happens regularly).  I'll then start spamming
the maintainer with the patch.  If the maintainer remains dead then I
might merge it myself, or I might tag it for -stable backporting and
try again in the next kernel.  

If the maintainer can't be bothered setting up a pull request then he
can just send an acked-by and explicitly ask me to merge it up and
I'll then add it to my next approximately-weekly Linus patchbombing.

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] sdhci-s3c: fix incorrect spinlock usage after merge

2010-09-20 Thread Chris Ball 
On Mon, Sep 20, 2010 at 03:03:42PM +0200, Marek Szyprowski wrote:
> In the commit f522886e202a34a2191dd5d471b3c4d46410a9a0 a merge conflict
> in the sdhci-s3c driver been fixed. However the fix used incorrect
> spinlock operation - it cause a race with sdhci interrupt service. The
> correct way to solve it is to use spin_lock_irqsave/irqrestore() calls.

Thanks, applied to mmc-next with:
Signed-off-by: Chris Ball 

Andrew, not sure how best to get this upstream -- do you want to send
this up to Linus (for -rc5) via your queue in -mm?

-- 
Chris Ball  
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html