On Wed, Oct 28, 2015 at 09:51:26AM +0100, Johan Hovold wrote:
> On Tue, Oct 27, 2015 at 04:53:34PM -0500, Konstantin Shkolnyy wrote:
> > cp2108 GET_LINE_CTL returns the 16-bit value with the 2 bytes swapped.
> > However, SET_LINE_CTL functions properly. When the driver tries to modify
> > the regis
Hello Stephen,
On Wed, Oct 28, 2015 at 09:55:05PM -0600, Stephen Warren wrote:
> On 10/27/2015 12:18 PM, Uwe Kleine-König wrote:
> > Hello,
> >
> > On Tue, Oct 27, 2015 at 09:08:27AM -0600, Stephen Warren wrote:
> >> On 10/27/2015 01:41 AM, Uwe Kleine-König wrote:
> >>> Hello,
> >>>
> >>> On Mon,
Dne 29.10.2015 v 07:34 Peter Chen napsal(a):
> On Wed, Oct 28, 2015 at 02:25:41PM +0100, Michal Marek wrote:
>> From: Michal Marek
>>
>> This allows to write
>>
>> drm-$(CONFIG_AGP) += drm_agpsupport.o
>>
>> without having to handle CONFIG_AGP=y vs. CONFIG_AGP=m. Only support
>> this syntax for
On Thu, Oct 29, 2015 at 09:05:55AM +0100, Michal Marek wrote:
> Dne 29.10.2015 v 07:34 Peter Chen napsal(a):
> > On Wed, Oct 28, 2015 at 02:25:41PM +0100, Michal Marek wrote:
> >> From: Michal Marek
> >>
> >> This allows to write
> >>
> >> drm-$(CONFIG_AGP) += drm_agpsupport.o
> >>
> >> without
On Wed, Oct 28, 2015 at 08:41:41AM -0500, Nathan Sullivan wrote:
> The USB OTG support currently depends on power management
> (CONFIG_PM) being enabled, but does not actually need it enabled.
> Remove this dependency.
>
> Remove the unneeded "default n" from USB_OTG as well, the default is
> alre
On Thu, Oct 22, 2015 at 05:14:41PM -0400, Alan Stern wrote:
> [Resend with Hans's correct email address this time...]
>
> On Thu, 22 Oct 2015, Alan Stern wrote:
>
> > Hans and everyone else:
> >
> > This continues the discussion of a problem originally posted to the
> > libusb-devel mailing lis
Hi,
It is due to try to allocate memory with GFP_KERNEL at ISR, below change
can fix it, if not better solution, I can submit a patch.
diff --git a/drivers/usb/gadget/function/f_loopback.c
b/drivers/usb/gadget/function/f_loopback.c
index 6b2102b..d2524a1 100644
--- a/drivers/usb/gadget/function/
Hello.
On 10/29/2015 5:46 AM, Lu Baolu wrote:
Function ep_ring_is_processing() checks the dequeue pointer
in endpoint context to know whether an endpoint is busy with
processing TRBs. This is not correct since dequeue pointer
field in an endpoint context is only valid when the endpoint
is in Ha
On 10/29/2015 08:51 PM, Sergei Shtylyov wrote:
Hello.
On 10/29/2015 5:46 AM, Lu Baolu wrote:
Function ep_ring_is_processing() checks the dequeue pointer
in endpoint context to know whether an endpoint is busy with
processing TRBs. This is not correct since dequeue pointer
field in an endpoin
I tested it on cp2102, cp2105 and cp2108.
I'm a little worried about that extra PURGE command, so I did several
manual tests on each with a standard PC serial port on the other end
of the cable.
- run several open/write/close iteration (the test that used to break
cp2108), observe data on the other
The USB OTG support currently depends on power management
(CONFIG_PM) being enabled, but does not actually need it enabled.
Remove this dependency.
Tested on Bay Trail hardware with dwc3 USB.
Signed-off-by: Nathan Sullivan
---
drivers/usb/core/Kconfig |1 -
1 file changed, 1 deletion(-)
di
On 10/29/2015 10:36 AM, Peter Chen wrote:
Hi,
It is due to try to allocate memory with GFP_KERNEL at ISR, below change
can fix it, if not better solution, I can submit a patch.
diff --git a/drivers/usb/gadget/function/f_loopback.c
b/drivers/usb/gadget/function/f_loopback.c
index 6b2102b..d25
On 29.10.2015 14:58, Lu, Baolu wrote:
On 10/29/2015 08:51 PM, Sergei Shtylyov wrote:
Hello.
On 10/29/2015 5:46 AM, Lu Baolu wrote:
Function ep_ring_is_processing() checks the dequeue pointer
in endpoint context to know whether an endpoint is busy with
processing TRBs. This is not correct si
Function ep_ring_is_processing() checks the dequeue pointer
in endpoint context to know whether an endpoint is busy with
processing TRBs. This is not correct since dequeue pointer
field in an endpoint context is only valid when the endpoint
is in Halted or Stopped states. This buggy code causes aud
On 10/29/2015 10:08 PM, Mathias Nyman wrote:
On 29.10.2015 14:58, Lu, Baolu wrote:
On 10/29/2015 08:51 PM, Sergei Shtylyov wrote:
Hello.
On 10/29/2015 5:46 AM, Lu Baolu wrote:
Function ep_ring_is_processing() checks the dequeue pointer
in endpoint context to know whether an endpoint is b
On Thu, 29 Oct 2015, Peter Chen wrote:
> > > [In practice it's not feasible to wait for an active QH to become
> > > inactive before removing it, for several reasons. For one, the QH may
> > > _never_ become inactive (if the endpoint NAKs indefinitely). For
> > > another, the procedure given in
John,
On Thu, Oct 22, 2015 at 1:05 PM, Douglas Anderson wrote:
> In commit 734643dfbdde ("usb: dwc2: host: add flag to reflect bus
> state") we changed dwc2_port_suspend() not to set the lx_state
> anymore (instead it sets the new bus_suspended variable). This
> introduced a bug where we would f
Instead of using only 120K for transfer size, let's
increase it to 1024K. This has a very noticeable
impact on USB3 storage devices.
The following measurements were done with v4.2 on
the host side and latest linux-next available at the
time (20151022). Following are results with default
and modifi
On Thu, 29 Oct 2015, Matthew Dharm wrote:
> Uhh... I think this is a bad idea. The 120K limit was chosen based on
> seeing a lot of devices which broke if you tried to transfer more. At
> least, that's my memory. Otherwise, it's a really goofy number.
>
> I certainly wouldn't mind you increasi
Hi,
Matthew Dharm writes:
> Uhh... I think this is a bad idea. The 120K limit was chosen based on
> seeing a lot of devices which broke if you tried to transfer more. At
> least, that's my memory. Otherwise, it's a really goofy number.
okay, if somebody has some link pointing to that, I'd be
(Resend, as I forgot to switch to plain-text for linux-usb@vger rules).
Uhh... I think this is a bad idea. The 120K limit was chosen based on
seeing a lot of devices which broke if you tried to transfer more. At
least, that's my memory. Otherwise, it's a really goofy number.
I certainly wouldn
Hi,
Alan Stern writes:
> On Thu, 29 Oct 2015, Matthew Dharm wrote:
>
>> Uhh... I think this is a bad idea. The 120K limit was chosen based on
>> seeing a lot of devices which broke if you tried to transfer more. At
>> least, that's my memory. Otherwise, it's a really goofy number.
>>
>> I ce
Hi Felipe,
[auto build test ERROR on usb/usb-next -- if it's inappropriate base, please
suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/Felipe-Balbi/usb-storage-scsiglue-increase-transfer-size-limit/20151030-042306
config: i386-randconfig-x00
Hi,
kbuild test robot writes:
> Hi Felipe,
>
> [auto build test ERROR on usb/usb-next -- if it's inappropriate base, please
> suggest rules for selecting the more suitable base]
>
> url:
> https://github.com/0day-ci/linux/commits/Felipe-Balbi/usb-storage-scsiglue-increase-transfer-size-limi
IIRC, the sysfs attribute doesn't exist until after the device is
probed, and the SCSI probing might fail (can't read partition tables,
leading to errors, catastrophic failure) if the max-sectors is too
high during probing.
While I agree 20-25% performance gain is significant, a high
failure-rate
On Thu, 29 Oct 2015, Felipe Balbi wrote:
> Hi,
>
> Alan Stern writes:
> > On Thu, 29 Oct 2015, Matthew Dharm wrote:
> >
> >> Uhh... I think this is a bad idea. The 120K limit was chosen based on
> >> seeing a lot of devices which broke if you tried to transfer more. At
> >> least, that's my me
On Thu, Oct 29, 2015 at 02:00:57PM -0700, Matthew Dharm wrote:
> IIRC, the sysfs attribute doesn't exist until after the device is
> probed, and the SCSI probing might fail (can't read partition tables,
> leading to errors, catastrophic failure) if the max-sectors is too
> high during probing.
>
>
Am Donnerstag, 22. Oktober 2015, 13:05:03 schrieb Douglas Anderson:
> In commit 734643dfbdde ("usb: dwc2: host: add flag to reflect bus
> state") we changed dwc2_port_suspend() not to set the lx_state
> anymore (instead it sets the new bus_suspended variable). This
> introduced a bug where we woul
Hi,
Alan Stern writes:
>> Alan Stern writes:
>> > On Thu, 29 Oct 2015, Matthew Dharm wrote:
>> >
>> >> Uhh... I think this is a bad idea. The 120K limit was chosen based on
>> >> seeing a lot of devices which broke if you tried to transfer more. At
>> >> least, that's my memory. Otherwise, i
On Thu, Oct 29, 2015 at 4:25 PM, Felipe Balbi wrote:
>
> Fair enough. Linus, do you have any recollection of which device you
> found to be quirky ? Your original commit limitting to 240 sectors
> doesn't make that clear at all ;-)
>
> [1] http://marc.info/?l=git-commits-head&m=106945975115131&w=2
Hi,
On Thu, Oct 29, 2015 at 3:49 PM, Heiko Stuebner wrote:
> Am Donnerstag, 22. Oktober 2015, 13:05:03 schrieb Douglas Anderson:
>> In commit 734643dfbdde ("usb: dwc2: host: add flag to reflect bus
>> state") we changed dwc2_port_suspend() not to set the lx_state
>> anymore (instead it sets the n
On Thu, Oct 29, 2015 at 4:44 PM, Linus Torvalds
wrote:
>
> That said, I'm pretty sure it's just that there were (and probably
> still are) tons of bad USB sticks with cheap controllers with 8-bit
> sector counts, and you're better off picking something that causes
> fairly even sizes than picking
On 10/29/2015 9:43 AM, Doug Anderson wrote:
> John,
>
> On Thu, Oct 22, 2015 at 1:05 PM, Douglas Anderson
> wrote:
>> In commit 734643dfbdde ("usb: dwc2: host: add flag to reflect bus
>> state") we changed dwc2_port_suspend() not to set the lx_state
>> anymore (instead it sets the new bus_suspen
struct mon_bin_hdr allows for a 64-bit seconds timestamp. The code
currently uses 'struct timeval' to populate the timestamp in mon_bin_hdr,
which has a 32-bit seconds field and will overflow in year 2038 and beyond.
This patch replaces 'struct timeval' with 'struct timespec64' which is
y2038 safe.
struct timeval' uses 32-bits for its seconds field and will overflow in
the year 2038 and beyond. This patch replaces the usage of 'struct timeval'
in mon_get_timestamp() with timespec64 which uses a 64-bit seconds field
and is y2038-safe. mon_get_timestamp() truncates the timestamp at 4096 seconds
On Thu, Oct 29, 2015 at 10:37:28AM -0400, Alan Stern wrote:
>
After reading spec at 4.8.2:
Software must not remove an active queue head from the schedule.
Software should first deactivate all active qTDs, wait for the
queue head to go inactive, then remove the queue head from the
asynchronous l
On Thu, Oct 29, 2015 at 02:53:46PM +0100, Krzysztof Opasiak wrote:
>
>
> On 10/29/2015 10:36 AM, Peter Chen wrote:
> >Hi,
> >
> >It is due to try to allocate memory with GFP_KERNEL at ISR, below change
> >can fix it, if not better solution, I can submit a patch.
> >
> >diff --git a/drivers/usb/ga
37 matches
Mail list logo
