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 S1752084AbbKPTbS (ORCPT <rfc822;w@1wt.eu>);
	Mon, 16 Nov 2015 14:31:18 -0500
Received: from iolanthe.rowland.org ([192.131.102.54]:39456 "HELO
	iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with SMTP id S1751216AbbKPTbO (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 16 Nov 2015 14:31:14 -0500
Date: Mon, 16 Nov 2015 14:31:13 -0500 (EST)
From: Alan Stern <stern@rowland.harvard.edu>
X-X-Sender: stern@iolanthe.rowland.org
To: Doug Anderson <dianders@chromium.org>
cc: Felipe Balbi <balbi@ti.com>, John Youn <John.Youn@synopsys.com>,
        Yunzhi Li <lyz@rock-chips.com>,
        =?UTF-8?Q?Heiko_St=C3=BCbner?= <heiko@sntech.de>,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@lists.infradead.org>,
        Julius Werner <jwerner@chromium.org>,
        "Herrero, Gregory" <gregory.herrero@intel.com>,
        "Kaukab, Yousaf" <yousaf.kaukab@intel.com>,
        Dinh Nguyen <dinguyen@opensource.altera.com>,
        John Youn <johnyoun@synopsys.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 1/2] usb: dwc2: host: Fix missing device insertions
In-Reply-To: <CAD=FV=XOO1XsHWSgqcvEAPAqhB2Ud5zcydc13k-pJ23L0rTW0Q@mail.gmail.com>
Message-ID: <Pine.LNX.4.44L0.1511161425540.1938-100000@iolanthe.rowland.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, 16 Nov 2015, Doug Anderson wrote:

> ---
> 
> usb: dwc2: host: Fix missing device insertions
> 
> If you've got your interrupt signals bouncing a bit as you insert your
> USB device, you might end up in a state when the device is connected but
> the driver doesn't know it.
> 
> Specifically, the observed order is:
>  1. hardware sees connect
>  2. hardware sees disconnect
>  3. hardware sees connect
>  4. dwc2_port_intr() - clears connect interrupt
>  5. dwc2_handle_common_intr() - calls dwc2_hcd_disconnect()
> 
> Now you'll be stuck with the cable plugged in and no further interrupts
> coming in but the driver will think we're disconnected.
> 
> We'll fix this by checking for the missing connect interrupt and
> re-connecting after the disconnect is posted.  We don't skip the
> disconnect because if there is a transitory disconnect we really want to
> de-enumerate and re-enumerate.

Why do you need to do anything special here?  Normally a driver's
interrupt handler should query the hardware status after clearing the
interrupt source.  That way no transitions ever get missed.

In your example, at step 5 the dwc2 driver would check the port status
and see that it currently is connected.  Therefore the driver would
pass a "connect status changed" event to the USB core and set the port
status to "connected".  No extra checking is needed, and transitory
connects or disconnects get handled correctly.

Alan Stern