> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: Wednesday, December 30, 2015 7:34 PM
> To: ba...@ti.com
> Cc: Peter Chen ; stefan.wah...@i2se.com; linux-
> u...@vger.kernel.org; Fabio Estevam
> Subject: [PATCH] usb: phy: mxs: Suggest passing "usbcore.autosu
rm *rc1*dmesgAfter switching from 4.3 to 4.4rc-s plugging device ID 1076:8002
GCT Semiconductor, Inc. LU150 LTE Modem [Yota LU150] causes kernel Oops.
The Oops is always reproducible when this device is plugged or system is booted
with it.
Oops reproduced with debian's 4.4.rc6 and vanilla 4.4rcs
This ensures that at any point on the function if a goto to setup_fail is
made, it will unlock the mutex.
Signed-off-by: Felipe F. Tonello
---
drivers/usb/gadget/function/f_midi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/function/f_midi.c
b/driver
Patch 1:
The main improvement is the refactor of the state machine MIDI parser.
It is better to read and handles states properly, even weird ones.
Patch 3:
Fix a race condition.
Patches 3-4:
Miscelaneous fixes.
Felipe F. Tonello (4):
usb: gadget: f_midi: refactor state machine
usb: g
Signed-off-by: Felipe F. Tonello
---
drivers/usb/gadget/function/f_midi.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/usb/gadget/function/f_midi.c
b/drivers/usb/gadget/function/f_midi.c
index bbff20697f76..b7d3f5a10bf0 100644
--- a/drivers/usb/gadget/function/f_midi.c
+++ b/driv
This refactor results in a cleaner state machine code and as a result fixed a
bug when packaging a MIDI-USB packet right after a non-conformant MIDI byte
stream.
Signed-off-by: Felipe F. Tonello
---
drivers/usb/gadget/function/f_midi.c | 204 ++-
1 file changed,
Since f_midi_transmit is called by both ALSA and USB frameworks, it can
potentially cause a race condition between both calls. This is bad because the
way f_midi_transmit is implemented can't handle concurrent calls. This is due
to the fact that the usb request fifo looks for the next element and o
While copying a disk with the dd command from inside a live-CD-boot-system
the following single error has been printed:
xhci_hcd ERROR Transfer event for disabled endpoint or incorrect stream ring
@000212409100 0a00 02088001
Does anybody know what these numbers mean?
B
Hi list,
I originally posted this on libusb-devel [1], but got a friendly
redirect here by Alan Stern, hope this is the right place!
Let me describe my problem from a "user" standpoint before diving into
the technical details: USB 3.0 does not work on my PC flat out.
Sometimes USB 3.0 ports work
From: Fabio Estevam
On a mx28 board with a USB hub the following error is observed:
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 2 ports detected
usb 1-1: USB disconnect, device number 2
usb usb1-port1: cannot reset (err = -32)
usb usb1-port1: cannot reset (err = -32)
usb usb1-port1: cannot reset (er
PTR_ERR should access the value just tested by IS_ERR
Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci
CC: Nobuo Iwata
Signed-off-by: Fengguang Wu
Signed-off-by: Julia Lawall
---
I haven't checked the complete context, but the code looks suspicious.
usbip_ux.c |2 +-
1 file chan
Hello Greg,
This patch is not yet merged, its already been reviewed and acked by Alan.
Thanks
Rahul
On Thu, Dec 10, 2015 at 09:40:33PM -0800, Rahul Pathak wrote:
> From: Rahul Pathak
>
> Fixing coccicheck warning which recommends to use memdup_user instead
> to reimplement its code, using memd
-over-WebSocket/20151230-150013
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
usb-testing
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
include
13 matches
Mail list logo