On Fri, Jan 31, 2014 at 11:48:37PM -0700, Stephen Warren wrote:
> On 01/31/2014 11:12 AM, Andre Heider wrote:
> > On Mon, Jan 13, 2014 at 01:50:09PM -0800, Paul Zimmerman wrote:
> >> The DWC2 driver should now be in good enough shape to move out of
> >> staging. I have stress tested it overnight on
On 14-02-01 02:54 AM, Ming Lei wrote:
..
> With SG enabled, for the iperf client test case, the average urb size
> for transmission will be increased from ~1500 to ~20K bytes in my
> test case:
>
>iperf -c $SRV -t 30 -P 4 -w 128K
>
> So I am wondering you guys do not care the improvement ..
On Sat, Feb 1, 2014 at 9:30 PM, Mark Lord wrote:
> On 14-02-01 02:54 AM, Ming Lei wrote:
> ..
>> With SG enabled, for the iperf client test case, the average urb size
>> for transmission will be increased from ~1500 to ~20K bytes in my
>> test case:
>>
>>iperf -c $SRV -t 30 -P 4 -w 128K
>>
>>
Hi
It seems that when sending SCSI commands over USB, the kernel doesn't
necessary build a sense response. For instance, when sending REQUEST
SENSE over ehci, the scsi_cmnd->sense_buffer is left NULL; if I run the
same REQUEST SENSE command over a direct SCSI connect, the kernel builds
the sc
Hi there -
finally I prepared a patch for the famous ftdi_sio usb serial driver.
Adding two Tagsys RFID readers I am using.
After having asked Bill Ryder he suggested adressing the
linux-usb-devel mailing list. (what?)
Sorry for the mess below - I am not doing this frequently - being
rather a lee
On Sat, 1 Feb 2014, Steph Nguyen wrote:
> Hi
>
> It seems that when sending SCSI commands over USB, the kernel doesn't
> necessary build a sense response. For instance, when sending REQUEST
> SENSE over ehci, the scsi_cmnd->sense_buffer is left NULL; if I run the
> same REQUEST SENSE command o
On Fri, 31 Jan 2014, Stephen Warren wrote:
> This is due to the following code:
>
> static void _dwc2_hcd_endpoint_reset(struct usb_hcd *hcd,
>struct usb_host_endpoint *ep)
> {
> struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
> ...
> struct usb_
On Sat, 1 Feb 2014, Steph Nguyen wrote:
Hi
It seems that when sending SCSI commands over USB, the kernel doesn't
necessary build a sense response. For instance, when sending REQUEST
SENSE over ehci, the scsi_cmnd->sense_buffer is left NULL; if I run the
same REQUEST SENSE command over a direct
On Sat, 1 Feb 2014, Steph Nguyen wrote:
> > On Sat, 1 Feb 2014, Steph Nguyen wrote:
> >
> >> Hi
> >>
> >> It seems that when sending SCSI commands over USB, the kernel doesn't
> >> necessary build a sense response. For instance, when sending REQUEST
> >> SENSE over ehci, the scsi_cmnd->sense_buffe
On Sat, 1 Feb 2014, Steph Nguyen wrote:
On Sat, 1 Feb 2014, Steph Nguyen wrote:
Hi
It seems that when sending SCSI commands over USB, the kernel doesn't
necessary build a sense response. For instance, when sending REQUEST
SENSE over ehci, the scsi_cmnd->sense_buffer is left NULL; if I run the
On Sat, 1 Feb 2014, Steph Nguyen wrote:
> To be clear, here's what I meant by "build" - I'm just pasting the
> relevant bits of the code:
>
> static void cypress_atacb_passthrough(struct scsi_cmnd *srb, struct
> us_data *us) {
> ...
> unsigned char *sb = srb->sense_buffer;
> .
Hello,
I am a total newbie in Linux kernel development (but not in C
programming), and I started to write a USB driver for the DualShock 4
(and also others controllers/equipments for the PlayStation 3/4 while
I'm at it).
My objective is to sanitize what is reported to the userspace (most
games do
On Fri, 31 Jan 2014, Dan Williams wrote:
> Toggling port power currently leads to three unintended disconnect
> scenarios that are addressed by this rework of port power recovery and
> usb device resume:
>
> 1/ Superspeed devices downgrade to their hispeed connection: fix this by
>preventing
On Sat, Feb 1, 2014 at 10:44 AM, Alan Stern wrote:
> On Fri, 31 Jan 2014, Dan Williams wrote:
>
>> Toggling port power currently leads to three unintended disconnect
>> scenarios that are addressed by this rework of port power recovery and
>> usb device resume:
>>
>> 1/ Superspeed devices downgrad
On 14-02-01 09:18 AM, Ming Lei wrote:
>
> Even real regressions are easily/often introduced, and we are discussing
> how to fix that. I suggest to unset the flag only for the known buggy
> controllers.
It is not the controllers that are particularly "buggy" here.
But rather the drivers and design
On Sat, 1 Feb 2014, Dan Williams wrote:
> Unfortunate that what goes for net/, or drivers/md/ doesn't go for
> drivers/usb/... sounds like checkpatch needs subsystem specific style
> rules to avoid this thrash.
Yeah, this is all stuff that checkpatch ignores.
> If it's just the style I'll put t
On Sat, 2014-02-01 at 15:39 -0500, Alan Stern wrote:
> On Sat, 1 Feb 2014, Dan Williams wrote:
>
> > Unfortunate that what goes for net/, or drivers/md/ doesn't go for
> > drivers/usb/... sounds like checkpatch needs subsystem specific style
> > rules to avoid this thrash.
>
> Yeah, this is all
Hello,
I applied these along with the reverting :
xhci: Set scatter-gather limit to avoid failed block writes.
usb: xhci: Link TRB must not occur within a USB payload burst
to Linus' tree.
The excellent news is that my system no longer hard freezes with an
ax88179_178a connected via a VIA
From: Shaibal Dutta
Allow the scheduler to select the best CPU to handle hub initalization
and LED blinking work. This extends idle residency times on idle CPUs
and conserves power.
This functionality is enabled when CONFIG_WQ_POWER_EFFICIENT is selected.
Cc: Greg Kroah-Hartman
Cc: Alan Stern
On 02/01/2014 03:00 AM, Andre Heider wrote:
> On Fri, Jan 31, 2014 at 11:48:37PM -0700, Stephen Warren wrote:
>> On 01/31/2014 11:12 AM, Andre Heider wrote:
>>> On Mon, Jan 13, 2014 at 01:50:09PM -0800, Paul Zimmerman wrote:
The DWC2 driver should now be in good enough shape to move out of
>>>
20 matches
Mail list logo
