From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753986AbbKQPkk (ORCPT ); Tue, 17 Nov 2015 10:40:40 -0500 Received: from iolanthe.rowland.org ([192.131.102.54]:38398 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1753733AbbKQPkj (ORCPT ); Tue, 17 Nov 2015 10:40:39 -0500 Date: Tue, 17 Nov 2015 10:40:37 -0500 (EST) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Doug Anderson cc: Felipe Balbi , John Youn , Yunzhi Li , =?UTF-8?Q?Heiko_St=C3=BCbner?= , "open list:ARM/Rockchip SoC..." , Julius Werner , "Herrero, Gregory" , "Kaukab, Yousaf" , Dinh Nguyen , John Youn , Greg Kroah-Hartman , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v2 1/2] usb: dwc2: host: Fix missing device insertions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 16 Nov 2015, Doug Anderson wrote: > > Fundamentally there's no difference between a "connect" interrupt and a > > "disconnect" interrupt. They should both do exactly the same things: > > clear the interrupt source, post a "connection change" event, and set > > the driver's connect status based on the hardware's current state. > > The second and third parts can be handled by a shared subroutine. > > Ah, sorry I misunderstood. OK, fair enough. So you're saying that > the problem is that dwc2_hcd_disconnect() has a line that looks like > this: > > hsotg->flags.b.port_connect_status = 0; > > ...and the dwc2_port_intr() has a line that looks like this: > > hsotg->flags.b.port_connect_status = 1; > > ...and both should just query the status. Well, I don't know how the driver uses flags.b.port_connect_status. In principle it could do away with that flag completely and always query the hardware status. > Do you think we should to block landing this patch on cleaning up how > dwc2 handles port_connect_status? I'm not sure what side effects > changing port_connect_status will have, so I'll need to test and dig a > bit... > > I'm currently working on trying to fix the microframe scheduler and > was planning to post the next series of patches there pretty soon. > I'm also planning to keep digging to figure out how to overall > increase compatibility with devices (and compatibility with many > devices plugged in). > > If it were up to me, I'd prefer to land this patch in either 4.4 or > 4.5 since it does seem to work. ...then put seeing what we can do to > cleanup all of the port_connect_status on the todo list. It's up to you guys. All I've been doing here is pointing out that your proposed approach didn't seem like the best. Alan Stern