[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=FV=XMAjPBpVX5VB+mNrbOgcsJP+cqESep9aJXH7rxA-r5-w@mail.gmail.com>
Date: Tue, 17 Nov 2015 08:13:36 -0800
From: Doug Anderson <dianders@...omium.org>
To: Alan Stern <stern@...land.harvard.edu>
Cc: Felipe Balbi <balbi@...com>, John Youn <John.Youn@...opsys.com>,
Yunzhi Li <lyz@...k-chips.com>,
Heiko Stübner <heiko@...ech.de>,
"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
Julius Werner <jwerner@...omium.org>,
"Herrero, Gregory" <gregory.herrero@...el.com>,
"Kaukab, Yousaf" <yousaf.kaukab@...el.com>,
Dinh Nguyen <dinguyen@...nsource.altera.com>,
John Youn <johnyoun@...opsys.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/2] usb: dwc2: host: Fix missing device insertions
Alan,
On Tue, Nov 17, 2015 at 7:40 AM, Alan Stern <stern@...land.harvard.edu> wrote:
> 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.
Thanks! Just wanted to make sure you know that I'm very very
appreciative of your reviews and suggestions here. Having someone
intimately familiar with how other USB host drivers work that's
willing to point out how dwc2 can do things better will be very
helpful in helping dwc2 grow.
-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists