On Mon, 24 Jun 2013, Konstantin Filatov wrote:
> On 06/23/2013 07:05 PM, Alan Stern wrote:
> >>> That's why, if the check is checked, I feel it should be added to each
> >>> HCD driver separately. Maybe I'm wrong. But before doing anything,
> >>> you should check with Thomas Pugliese. He recent
On Mon, Jun 24, 2013 at 6:10 PM, Konstantin Filatov
wrote:
> On 06/23/2013 07:05 PM, Alan Stern wrote:
That's why, if the check is checked, I feel it should be added to each
HCD driver separately. Maybe I'm wrong. But before doing anything,
you should check with Thomas Puglie
On 06/23/2013 07:05 PM, Alan Stern wrote:
That's why, if the check is checked, I feel it should be added to each
HCD driver separately. Maybe I'm wrong. But before doing anything,
you should check with Thomas Pugliese. He recently added SG support to
the wireless USB driver.
Suppose wireless
On Sun, 23 Jun 2013, Ming Lei wrote:
> >> Since you mentioned it doesn't make sense to generate short packet
> >> in the middle of transfer, also it may not be what the driver/device
> >> expected,
> >> I suggest to add a check in usb_submit_urb() for this case and returns
> >> failure on it simp
Sorry for missing CC
On Sun, Jun 23, 2013 at 9:42 AM, Ming Lei wrote:
> On Sun, Jun 23, 2013 at 2:58 AM, Alan Stern wrote:
>> On Sat, 22 Jun 2013, Ming Lei wrote:
>>
>>> > Nonsense. Transfers do not have short packets in the middle, only at
>>> > the end. If the driver wants to have 1512 bytes
On Sun, Jun 23, 2013 at 2:58 AM, Alan Stern wrote:
> On Sat, 22 Jun 2013, Ming Lei wrote:
>
>> > Nonsense. Transfers do not have short packets in the middle, only at
>> > the end. If the driver wants to have 1512 bytes in a single transfer
>> > then there must be 23 packets of length 64 followed
On Sat, 22 Jun 2013, Ming Lei wrote:
> > Nonsense. Transfers do not have short packets in the middle, only at
> > the end. If the driver wants to have 1512 bytes in a single transfer
> > then there must be 23 packets of length 64 followed one packet of
> > length 40.
> >
> > If the driver wants
On Sat, Jun 22, 2013 at 1:42 AM, Alan Stern wrote:
> On Sat, 22 Jun 2013, Ming Lei wrote:
>
>> On Sat, Jun 22, 2013 at 12:45 AM, Alan Stern
>> wrote:
>> >> Sorry, could you explain why that won't work? I understand the URBs
>> >> with maxp-unaligned length still can be completed.
>> >
>> > Suppo
On Sat, 22 Jun 2013, Ming Lei wrote:
> On Sat, Jun 22, 2013 at 12:45 AM, Alan Stern
> wrote:
> >> Sorry, could you explain why that won't work? I understand the URBs
> >> with maxp-unaligned length still can be completed.
> >
> > Suppose the SG list has two elements, where the first element's le
On Fri, 21 Jun 2013, Denis V. Lunev wrote:
> Alan,
>
> simple stupid question. Does [v2] patch description is good or I should
> re-write it like
>689d6eac (USB: UHCI: add native scatter-gather support(v1))
It would be better to change the patch title. The problem isn't
related to alignmen
On Sat, Jun 22, 2013 at 12:45 AM, Alan Stern wrote:
>> Sorry, could you explain why that won't work? I understand the URBs
>> with maxp-unaligned length still can be completed.
>
> Suppose the SG list has two elements, where the first element's length
> is 1000 (not a multiple of 64) and the secon
On 6/21/13 7:19 PM, Alan Stern wrote:
On Fri, 21 Jun 2013, Konstantin Filatov wrote:
Your patch skips a chunk of data to transfer. This is a corruption of
data. It's unacceptable. We can return an error code if we treat the
request as malformed, but we can't transfer data selectively.
I agree
On Sat, Jun 22, 2013 at 12:36 AM, Alan Stern wrote:
>
> No, they won't. pktsze gets reinitialized each time through the loop.
You are right, the pktsze will get reinitialized, then there is a short packet
in the middle of transfer, so it violates the above description of USB spec
which only allo
On Sat, 22 Jun 2013, Ming Lei wrote:
> On Sat, Jun 22, 2013 at 12:13 AM, Alan Stern
> wrote:
> > On Fri, 21 Jun 2013, Ming Lei wrote:
> >
> > I'm not sure what you mean. Do you mean that usb_sg_init() should fail
> > if the SG element length isn't a multiple of the maxpacket size? That
> > pro
On Sat, 22 Jun 2013, Ming Lei wrote:
> On Sat, Jun 22, 2013 at 12:08 AM, Alan Stern
> wrote:
> > On Fri, 21 Jun 2013, Ming Lei wrote:
> >> But the patch violates USB spec, doesn't it?
> >
> > No, the client driver violates the kernel's requirements by submitting
> > an SG transfer that can't be
On Sat, Jun 22, 2013 at 12:13 AM, Alan Stern wrote:
> On Fri, 21 Jun 2013, Ming Lei wrote:
>
> I'm not sure what you mean. Do you mean that usb_sg_init() should fail
> if the SG element length isn't a multiple of the maxpacket size? That
> probably will break wireless USB.
>
> Do you mean that u
On Sat, Jun 22, 2013 at 12:08 AM, Alan Stern wrote:
> On Fri, 21 Jun 2013, Ming Lei wrote:
>> But the patch violates USB spec, doesn't it?
>
> No, the client driver violates the kernel's requirements by submitting
> an SG transfer that can't be carried out. Although it probably isn't
> documented
On Fri, 21 Jun 2013, Ming Lei wrote:
> On Fri, Jun 21, 2013 at 11:19 PM, Alan Stern
> wrote:
> > On Fri, 21 Jun 2013, Konstantin Filatov wrote:
> >
> >> > --- a/drivers/usb/host/uhci-q.c
> >> > +++ b/drivers/usb/host/uhci-q.c
> >> > @@ -977,6 +977,9 @@ static int uhci_submit_common(struct uhci_h
On Fri, 21 Jun 2013, Ming Lei wrote:
> On Fri, Jun 21, 2013 at 11:19 PM, Alan Stern
> wrote:
> > On Fri, 21 Jun 2013, Konstantin Filatov wrote:
> >
> >> > --- a/drivers/usb/host/uhci-q.c
> >> > +++ b/drivers/usb/host/uhci-q.c
> >> > @@ -977,6 +977,9 @@ static int uhci_submit_common(struct uhci_h
On Fri, Jun 21, 2013 at 11:19 PM, Alan Stern wrote:
> On Fri, 21 Jun 2013, Konstantin Filatov wrote:
>
>> > --- a/drivers/usb/host/uhci-q.c
>> > +++ b/drivers/usb/host/uhci-q.c
>> > @@ -977,6 +977,9 @@ static int uhci_submit_common(struct uhci_hcd *uhci,
>> > struct urb *urb,
>> > for (;
On Fri, Jun 21, 2013 at 11:19 PM, Alan Stern wrote:
> On Fri, 21 Jun 2013, Konstantin Filatov wrote:
>
>> > --- a/drivers/usb/host/uhci-q.c
>> > +++ b/drivers/usb/host/uhci-q.c
>> > @@ -977,6 +977,9 @@ static int uhci_submit_common(struct uhci_hcd *uhci,
>> > struct urb *urb,
>> > for (;
On Fri, Jun 21, 2013 at 10:23 PM, Konstantin Filatov
wrote:
> On 06/21/2013 05:47 PM, Ming Lei wrote:
>>
>> The bug can be easily reproduced with Gadget Zero in full_speed mode
>> connected to a host with UHCI controller by the standard test from
>> tools/usb/ with command line
>>testusb -a -t
On Fri, 21 Jun 2013, Konstantin Filatov wrote:
> > --- a/drivers/usb/host/uhci-q.c
> > +++ b/drivers/usb/host/uhci-q.c
> > @@ -977,6 +977,9 @@ static int uhci_submit_common(struct uhci_hcd *uhci,
> > struct urb *urb,
> > for (;;) { /* Allow zero length packets */
> >
On 06/21/2013 05:47 PM, Ming Lei wrote:
The bug can be easily reproduced with Gadget Zero in full_speed mode
connected to a host with UHCI controller by the standard test from
tools/usb/ with command line
testusb -a -t 7 -c 2000 -s 4096 -v 41
I am wondering if it is a valid test, since the bui
On Fri, Jun 21, 2013 at 8:35 PM, Denis V. Lunev wrote:
> From: "Denis V. Lunev"
>
> From: Konstantin Filatov
>
> The following commit
> commit 689d6eacd1b7c3677bfe6ee367766f21c3c80e26
> Author: Ming Lei
> Date: Thu Sep 30 20:32:44 2010 +0800
>
> USB: UHCI: add native scatter-gather
25 matches
Mail list logo
