From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754778AbbIOOqo (ORCPT <rfc822;w@1wt.eu>);
	Tue, 15 Sep 2015 10:46:44 -0400
Received: from comal.ext.ti.com ([198.47.26.152]:53751 "EHLO comal.ext.ti.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751694AbbIOOqi (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 15 Sep 2015 10:46:38 -0400
Subject: Re: [PATCH v4 5/9] usb: dwc3: core: make dual-role work with OTG irq
To: Peter Chen <peter.chen@freescale.com>, Felipe Balbi <balbi@ti.com>
References: <1441203864-15786-1-git-send-email-rogerq@ti.com>
 <1441203864-15786-6-git-send-email-rogerq@ti.com>
 <20150902144338.GG8299@saruman.tx.rr.com> <20150906022040.GC4914@shlinux2>
CC: <tony@atomide.com>, <Joao.Pinto@synopsys.com>,
        <sergei.shtylyov@cogentembedded.com>, <jun.li@freescale.com>,
        <linux-usb@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <linux-omap@vger.kernel.org>
From: Roger Quadros <rogerq@ti.com>
Message-ID: <55F82F42.3030401@ti.com>
Date: Tue, 15 Sep 2015 17:46:26 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <20150906022040.GC4914@shlinux2>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 06/09/15 05:20, Peter Chen wrote:
> On Wed, Sep 02, 2015 at 09:43:38AM -0500, Felipe Balbi wrote:
>> Hi,
>>
>>> +
>>> +static irqreturn_t dwc3_otg_irq(int irq, void *_dwc)
>>> +{
>>> +	struct dwc3 *dwc = _dwc;
>>> +	irqreturn_t ret = IRQ_NONE;
>>> +	u32 reg;
>>> +
>>> +	spin_lock(&dwc->lock);
>>
>> this seems unnecessary, we're already in hardirq with IRQs disabled.
>> What sort of race could we have ? (in fact, this also needs change in
>> dwc3/gadget.c).
>>
> 
> Is it possible the kernel process is accessing the content you will 
> access?
> 
When kernel process accesses the data we'll never reach here
as we're protecting it with spinlock_irqsave(), spinunlock_irqrestore().

cheers,
-roger