linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Julius Werner <jwerner@chromium.org>
Cc: "Doug Anderson" <dianders@chromium.org>,
	"Felipe Balbi" <balbi@ti.com>,
	"John Youn" <John.Youn@synopsys.com>,
	"Yunzhi Li" <lyz@rock-chips.com>,
	"Heiko Stübner" <heiko@sntech.de>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.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
Date: Mon, 16 Nov 2015 15:38:29 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.1511161534000.1938-100000@iolanthe.rowland.org> (raw)
In-Reply-To: <CAODwPW-O=ezdEWck1n4358ErK_6O5ksCeGY=KZi==f33_i3B9Q@mail.gmail.com>

On Mon, 16 Nov 2015, Julius Werner wrote:

> Another point to note, which I think is what prevents the flow Alan
> suggested from working, is this little snippet in DWC2's hub_control
> GetPortStatus callback:
> 
>                 if (!hsotg->flags.b.port_connect_status) {
>                         /*
>                          * The port is disconnected, which means the core is
>                          * either in device mode or it soon will be.
> Just
>                          * return 0's for the remainder of the port status
>                          * since the port register can't be read if the core
>                          * is in device mode.
>                          */
>                         *(__le32 *)buf = cpu_to_le32(port_status);
>                         break;
>                 }
> 
> This is before it actually checks the register state of the port. So
> it relies on dwc2_hcd_connect() and dwc2_hcd_disconnect() to be called
> in the right order to give the correct answer for
> USB_PORT_STAT_CONNECTION. This could maybe be improved but I don't
> know what kind of weird interactions with device mode operation made
> that snippet necessary in the first place.

Why does this test hsotg->flags.b.port_connect_status?  What it really 
needs to know is whether the core is in device mode.  It should test 
for that instead.  Then it could accurately report the true connection 
state whenever the core is in host mode, regardless of the order in 
which dwc2_hcd_connect() and dwc2_hcd_disconnect() get called.  No?

My guess would be that using the wrong test was simply a misguided 
attempt at optimization.

Alan Stern


  reply	other threads:[~2015-11-16 20:38 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-03 20:30 [PATCH v2 1/2] usb: dwc2: host: Fix missing device insertions Douglas Anderson
2015-11-03 20:30 ` [PATCH v2 2/2] usb: dwc2: host: Clear interrupts before handling them Douglas Anderson
2015-11-05  3:08   ` John Youn
2015-11-16 16:28   ` Felipe Balbi
2015-11-16 17:22     ` Doug Anderson
2015-11-19  1:43       ` John Youn
2015-11-19 16:37         ` Doug Anderson
2015-11-19 18:19           ` Felipe Balbi
2015-11-19 19:09             ` John Youn
2015-11-05  2:52 ` [PATCH v2 1/2] usb: dwc2: host: Fix missing device insertions John Youn
2015-11-16 17:44 ` Felipe Balbi
2015-11-16 18:13   ` Doug Anderson
2015-11-16 18:22     ` Felipe Balbi
2015-11-16 18:44       ` Doug Anderson
2015-11-16 19:09         ` Felipe Balbi
2015-11-16 19:31         ` Alan Stern
2015-11-16 19:46           ` Doug Anderson
2015-11-16 20:26             ` Julius Werner
2015-11-16 20:38               ` Alan Stern [this message]
2015-11-16 20:31             ` Alan Stern
2015-11-16 23:14               ` Doug Anderson
2015-11-17  1:53                 ` John Youn
2015-11-17  2:37                   ` Doug Anderson
2015-11-17 15:40                 ` Alan Stern
2015-11-17 16:13                   ` Doug Anderson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44L0.1511161534000.1938-100000@iolanthe.rowland.org \
    --to=stern@rowland.harvard.edu \
    --cc=John.Youn@synopsys.com \
    --cc=balbi@ti.com \
    --cc=dianders@chromium.org \
    --cc=dinguyen@opensource.altera.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=gregory.herrero@intel.com \
    --cc=heiko@sntech.de \
    --cc=johnyoun@synopsys.com \
    --cc=jwerner@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=lyz@rock-chips.com \
    --cc=yousaf.kaukab@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).