From: wlf <wulf@rock-chips.com>
To: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>,
William Wu <william.wu@rock-chips.com>,
"John.Youn@synopsys.com" <John.Youn@synopsys.com>,
"balbi@kernel.org" <balbi@kernel.org>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
Cc: "heiko@sntech.de" <heiko@sntech.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"linux-rockchip@lists.infradead.org"
<linux-rockchip@lists.infradead.org>,
"frank.wang@rock-chips.com" <frank.wang@rock-chips.com>,
"huangtao@rock-chips.com" <huangtao@rock-chips.com>,
"dianders@google.com" <dianders@google.com>,
"daniel.meng@rock-chips.com" <daniel.meng@rock-chips.com>,
"fml@rock-chips.com" <fml@rock-chips.com>
Subject: Re: [PATCH] usb: dwc2: host: fix isoc urb actual length
Date: Mon, 6 Nov 2017 18:08:05 +0800 [thread overview]
Message-ID: <392af079-7805-a22e-d332-cd7615adf6ba@rock-chips.com> (raw)
In-Reply-To: <410670D7E743164D87FA6160E7907A560113A39F61@am04wembxa.internal.synopsys.com>
Hi Minas,
在 2017年11月06日 17:28, Minas Harutyunyan 写道:
> Hi,
>
> On 11/6/2017 12:46 PM, William Wu wrote:
>> The actual_length in dwc2_hcd_urb structure is used
>> to indicate the total data length transferred so far,
>> but in dwc2_update_isoc_urb_state(), it just updates
>> the actual_length of isoc frame, and don't update the
>> urb actual_length at the same time, this will cause
>> device drivers working error which depend on the urb
>> actual_length.
>>
>> we can easily find this issue if use an USB camera,
>> the userspace use libusb to get USB data from kernel
>> via devio driver.In usb devio driver, processcompl()
>> function will process urb complete and copy data to
>> userspace depending on urb actual_length.
>>
>> Let's update the urb actual_length if the isoc frame
>> is valid.
>>
>> Signed-off-by: William Wu <william.wu@rock-chips.com>
>> ---
>> drivers/usb/dwc2/hcd_intr.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/usb/dwc2/hcd_intr.c b/drivers/usb/dwc2/hcd_intr.c
>> index 28a8210..01b1e13 100644
>> --- a/drivers/usb/dwc2/hcd_intr.c
>> +++ b/drivers/usb/dwc2/hcd_intr.c
>> @@ -580,6 +580,7 @@ static enum dwc2_halt_status dwc2_update_isoc_urb_state(
>> frame_desc->status = 0;
>> frame_desc->actual_length = dwc2_get_actual_xfer_length(hsotg,
>> chan, chnum, qtd, halt_status, NULL);
>> + urb->actual_length += frame_desc->actual_length;
>> break;
>> case DWC2_HC_XFER_FRAME_OVERRUN:
>> urb->error_count++;
>> @@ -599,6 +600,7 @@ static enum dwc2_halt_status dwc2_update_isoc_urb_state(
>> frame_desc->status = -EPROTO;
>> frame_desc->actual_length = dwc2_get_actual_xfer_length(hsotg,
>> chan, chnum, qtd, halt_status, NULL);
>> + urb->actual_length += frame_desc->actual_length;
>>
>> /* Skip whole frame */
>> if (chan->qh->do_split &&
>>
> According urb description in usb.h urb->actual_length used for non-iso
> transfers:
>
> "@actual_length: This is read in non-iso completion functions, and ...
>
> * ISO transfer status is reported in the status and actual_length fields
> * of the iso_frame_desc array, ...."
Yes, urb->actual_length is used for non-iso transfers. And for ISO
transfer, the most
usb class drivers can only use iso frame status and actual_length to
handle usb data,
like: kernel v4.4 drivers/media/usb/uvc/uvc_video.c
But the usb devio driver really need the urb actual_length in the
processcompl() if
handle ISO transfer, just as I mentioned in the commit message.
And I also found the same issue on raspberrypi board:
https://github.com/raspberrypi/linux/issues/903
So do you think we need to fix the usb devio driver, rather than fix dwc2?
I think maybe we can use urb actual length for ISO transfer, it seems that
don't cause any side-effect.
>
> Thanks,
> Minas
>
>
>
>
>
>
--
吴良峰 William.Wu
福建省福州市铜盘路软件大道89号软件园A区21号楼
No.21 Building, A District, No.89,software Boulevard Fuzhou,Fujian, PRC
手机: 13685012275
座机: 0591-83991906-8520
邮件:wulf@rock-chips.com
next prev parent reply other threads:[~2017-11-06 10:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-06 8:45 William Wu
2017-11-06 9:28 ` Minas Harutyunyan
2017-11-06 10:08 ` wlf [this message]
2017-11-06 12:30 ` Minas Harutyunyan
2017-11-06 19:17 ` Alan Stern
2017-11-07 9:58 ` wlf
2017-11-07 15:18 ` Alan Stern
2017-11-08 2:58 ` wlf
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=392af079-7805-a22e-d332-cd7615adf6ba@rock-chips.com \
--to=wulf@rock-chips.com \
--cc=John.Youn@synopsys.com \
--cc=Minas.Harutyunyan@synopsys.com \
--cc=balbi@kernel.org \
--cc=daniel.meng@rock-chips.com \
--cc=dianders@google.com \
--cc=fml@rock-chips.com \
--cc=frank.wang@rock-chips.com \
--cc=gregkh@linuxfoundation.org \
--cc=heiko@sntech.de \
--cc=huangtao@rock-chips.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-usb@vger.kernel.org \
--cc=william.wu@rock-chips.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
all inboxes | Powered by JetHome®