Hi,
On Fri, Jun 28, 2013 at 10:06:01PM +0200, Michael Grzeschik wrote:
right, but in DT you will define both instances and each
instance will
have a seaparate snps,maximum_speed attribute :-)
I'm now considering if we should make maximum_speed a generic
Separate the OHCI NXP host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM.
Many place function name and struct name started with usb,
current scenario replaced usb with ohci for proper
On Sun, Jun 30, 2013 at 2:35 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Sat, 29 Jun 2013, Ming Lei wrote:
The ehci_endpoint_disable() routine can be improved. In the
QH_STATE_LINNKED or QH_STATE_COMPLETING case, we now need to handle
interrupt QHs -- the comment about periodic qh
On Sun, 30 Jun 2013, Ming Lei wrote:
Come to think of it, we never should see an endpoint being disabled
while there are active URBs. It might be a better idea to put a
Right.
WARN_ON there and simply return, without unlinking anything. If this
ever triggers, it means there's a bug
Clement and Laurent:
The two of you seem to be the people who make the most use of
isochronous USB transfers. Since the ehci-hcd driver is being changed
to use a tasklet for URB completion callbacks, it looks like I will
need to reconsider how isochronous underruns get handled.
The basic prolem
On Sun, Jun 30, 2013 at 10:05 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Sun, 30 Jun 2013, Ming Lei wrote:
Come to think of it, we never should see an endpoint being disabled
while there are active URBs. It might be a better idea to put a
Right.
WARN_ON there and simply return,
On Mon, 1 Jul 2013, Ming Lei wrote:
So I think we should unlink here to speed up the procedure as suggested
in your previous email.
You are right. If the QH's qtd_list isn't empty then we should WARN_ON
and return without doing anything -- just leak the QH. Otherwise,
Yes, we can
Fix race in LED handling introduced by commit 0eafe4de (USB: serial:
mos7840: add support for MCS7810 devices) which reused the port control
urb for manipulating the LED without making sure that the urb is not
already in use. This could lead to the control urb being manipulated
while in flight.
Fix race in mos7840_get_reg which unconditionally manipulated the
control urb (which may already be in use) by adding a control-urb busy
flag.
Cc: sta...@vger.kernel.org
Signed-off-by: Johan Hovold jhov...@gmail.com
---
drivers/usb/serial/mos7840.c | 18 --
1 file changed, 16
These patches fix three (related) races in mos7840. Driver's a bit of
mess...
Tested using a mos7820 (and by faking a mos7810 with LED).
Johan
Johan Hovold (3):
USB: mos7840: fix race in register handling
USB: mos7840: fix device-type detection
USB: mos7840: fix race in led handling
Fix race in device-type detection introduced by commit 0eafe4de (USB:
serial: mos7840: add support for MCS7810 devices) which used a static
variable to hold the device type.
Move type detection to probe and use serial data to store the device
type.
Cc: sta...@vger.kernel.org
Signed-off-by: Johan
3.9.8 brought a tiny improvement!
scanimage -L now succesfully reports the scanner, but then hangs.
I still can not scan with xsane however (no scanner device found)
$ scanimage -L
device `plustek:libusb:001:004' is a Canon CanoScan N670U/N676U/LiDE20
flatbed scanner
(hang, but eventually
On Wed, Jun 26, 2013 at 09:53:34AM -0700, Sarah Sharp wrote:
On Wed, Jun 26, 2013 at 02:28:57PM +0530, George Cherian wrote:
Synopsis xhci controllers with hci_version 0.96 gives spurious success
events on short packet completion. During webcam capture the
ERROR Transfer event TRB DMA ptr
On Mon, Jun 24, 2013 at 09:24:28AM -0700, Reilly Grant wrote:
On Mon, Jun 24, 2013 at 08:59AM -0700, Sarah Sharp wrote:
On Tue, Jun 18, 2013 at 02:09:13PM -0700, Reilly Grant wrote:
So, no, I can't accept this patch. If this fixes a real problem in
some hardware, we'll add a quirk for
CONFIG_USB_XHCI_HCD_DEBUGGING option is used to enable
verbose debugging output for the xHCI host controller
driver.
In the current version of the xhci-hcd driver, this
option must be turned on, in order for the debugging
log messages to be displayed, and users may need to
recompile the linux
On Mon, Jul 01, 2013 at 12:23:18AM +0300, Xenia Ragiadakou wrote:
CONFIG_USB_XHCI_HCD_DEBUGGING option is used to enable
verbose debugging output for the xHCI host controller
driver.
In the current version of the xhci-hcd driver, this
option must be turned on, in order for the debugging
On Sun, Jun 30, 2013 at 09:35:59PM +0200, Martin van Es wrote:
3.9.8 brought a tiny improvement!
scanimage -L now succesfully reports the scanner, but then hangs.
I still can not scan with xsane however (no scanner device found)
$ scanimage -L
device `plustek:libusb:001:004' is a Canon
On Wed, Jun 26, 2013 at 01:20:53AM +0300, Xenia Ragiadakou wrote:
On 06/26/2013 12:16 AM, Sarah Sharp wrote:
I'm a little bit confused by this patch, so I'm CC-ing the list.
On Tue, Jun 25, 2013 at 08:52:49AM +0300, Xenia Ragiadakou wrote:
This patch initializes the dma_mask pointer to point
Hi!
I'm trying to investigate on the Huawei E3131 wwan interface - like the E398,
this device ignores the at^ndisdup command.
I wanted to verify if my device was running a jungo firmware or not, since I
found contraddictory informations on the network.
To this end, I patched the cdc_ncm driver
On 06/28/2013 10:22 PM, Alan Stern wrote:
On Fri, 28 Jun 2013, Li, Zhen-Hua (USL-China) wrote:
There was a problem, the warning Controller not stopped yet.
And your last patch for this problem does a wrong thing:
It prevents all HP uhci devices from auto-stop, which make HP uhci
devices waste
On Sun, Jun 30, 2013 at 02:54:26PM -0700, Greg KH wrote:
On Mon, Jul 01, 2013 at 12:23:18AM +0300, Xenia Ragiadakou wrote:
CONFIG_USB_XHCI_HCD_DEBUGGING option is used to enable
verbose debugging output for the xHCI host controller
driver.
In the current version of the xhci-hcd driver,
On 07/01/2013 04:24 AM, Sarah Sharp wrote:
On Sun, Jun 30, 2013 at 02:54:26PM -0700, Greg KH wrote:
On Mon, Jul 01, 2013 at 12:23:18AM +0300, Xenia Ragiadakou wrote:
CONFIG_USB_XHCI_HCD_DEBUGGING option is used to enable
verbose debugging output for the xHCI host controller
driver.
In the
On 07/01/2013 01:29 AM, Sarah Sharp wrote:
On Wed, Jun 26, 2013 at 01:20:53AM +0300, Xenia Ragiadakou wrote:
On 06/26/2013 12:16 AM, Sarah Sharp wrote:
I'm a little bit confused by this patch, so I'm CC-ing the list.
On Tue, Jun 25, 2013 at 08:52:49AM +0300, Xenia Ragiadakou wrote:
This
You should see the voltage of vbus pin is less than 0.8v when
nothing is connected, we use B_SESSION_VALID (0.8v) to judge
it is connected or not.
You get 2.25 all the time or it is discharged very slowly?
On my mx28evk it discharges very very slowly. Any hints about it?
Due to
On Mon, Jul 1, 2013 at 1:35 AM, Alan Stern st...@rowland.harvard.edu wrote:
On Mon, 1 Jul 2013, Ming Lei wrote:
So I think we should unlink here to speed up the procedure as suggested
in your previous email.
You are right. If the QH's qtd_list isn't empty then we should WARN_ON
and
On Sun, Jun 30, 2013 at 11:02 PM, Alan Stern st...@rowland.harvard.edu wrote:
Clement and Laurent:
The two of you seem to be the people who make the most use of
isochronous USB transfers. Since the ehci-hcd driver is being changed
to use a tasklet for URB completion callbacks, it looks like
Xhci controllers with hci_version 0.96 gives spurious success
events on short packet completion. During webcam capture the
ERROR Transfer event TRB DMA ptr not part of current TD was observed.
The same application works fine with synopsis controllers hci_version 0.96.
The same Issue is seen with
27 matches
Mail list logo
