On Wed, Dec 28, 2016 at 02:56:57PM -0800, Stephen Boyd wrote:
> From: Peter Chen
>
> At some situations, the vbus may already be there before starting
> gadget. So we need to check vbus event after switch to gadget in
> order to handle missing vbus event. The typical use cases are plugging
> vbus
The USB core may call reset_resume when it fails to resume asix device.
And USB core can recovery this abnormal resume at low level driver,
the same .resume at asix driver can work too. Add .reset_resume can
avoid disconnecting after backing from system resume, and NFS can
still be mounted after th
On Mon, Jan 02, 2017 at 11:25:14PM +0100, B&A Consultants wrote:
> Hello,
>
> Kernels 4.1.35 and 4.4.39, on Gentoo boxes.
>
> We are trying to set up Yubikey-compatible (made by Plugup) U2F usb keys
> on our systems, and the keys seems to be randomly detected by the usbhid
> driver. Since it's fo
On Mon, 2017-01-02 at 14:45 -0700, Chris Murphy wrote:
> I see these lines in the problem case, which don't occur in the
> working case.
>
> [0.561046] pci_bus :37: busn_res: [bus 37-ff] end is updated
> to 37
> [0.561047] pci_bus :37: busn_res: can not insert [bus 37]
> under doma
On Mon, Jan 02, 2017 at 02:45:00PM -0700, Chris Murphy wrote:
> On Mon, Jan 2, 2017 at 2:28 PM, Alan Stern wrote:
> > Considering that the failed boot log contains no USB messages at all,
> > and no messages referring to PCI bus :37 (the bus associated with
> > the adapter), this certainly loo
On 28 December 2016 at 20:30, Janusz Dziedzic wrote:
> 2016-12-27 13:16 GMT+01:00 Baolin Wang :
>> Hi,
>>
>> On 27 December 2016 at 19:11, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> Baolin Wang writes:
Hi,
On 27 December 2016 at 18:52, Janusz Dziedzic
wrote:
> 2016-12-26 9
DCFG.DEVSPD == 0x3 is not valid and we need to set
DCFG.DEVSPD to 0x1 for full speed mode. Same goes for
DSTS.CONNECTSPD.
Old databooks had 0x3 for full speed in 48MHz mode for
USB1.1 transceivers which was never supported. Newer databooks
don't mention 0x3 at all.
Cc: John Youn
Signed-off-by: R
Hi,
Baolin Wang writes:
> On 28 December 2016 at 20:30, Janusz Dziedzic
> wrote:
>> 2016-12-27 13:16 GMT+01:00 Baolin Wang :
>>> Hi,
>>>
>>> On 27 December 2016 at 19:11, Felipe Balbi wrote:
Hi,
Baolin Wang writes:
> Hi,
>
> On 27 December 2016 at 18:52, Janus
Hi,
David Lechner writes:
> This reverts commit ba1582f22231821c57534e87b077d84adbc15dbd.
>
> I am getting a null pointer dereference when setting up an hid gadget using
> configfs. Reverting this commit fixes the crash.
>
> dmesg:
>
> [ 382.406622] Unable to handle kernel NULL pointer derefere
Mathias & Felipe,
On 17/11/16 17:01, Roger Quadros wrote:
> Hi,
>
> Some XHCI controllers e.g. dwc3 based have a broken Port disable [1].
>
> If the attached high-speed device is misbehaving, the USB stack typically
> disables the port using the PED bit in PORTSC. For the controllers that
> have
Hi,
Roger Quadros writes:
> Mathias & Felipe,
>
> On 17/11/16 17:01, Roger Quadros wrote:
>> Hi,
>>
>> Some XHCI controllers e.g. dwc3 based have a broken Port disable [1].
>>
>> If the attached high-speed device is misbehaving, the USB stack typically
>> disables the port using the PED bit in
Hi Greg,
Here's the first set of fixes for this rc cycle. Let me know if you want
anything to be changed.
cheers
The following changes since commit 0c744ea4f77d72b3dcebb7a8f2684633ec79be88:
Linux 4.10-rc2 (2017-01-01 14:31:53 -0800)
are available in the git repository at:
git://git.kerne
On Tue, Jan 03, 2017 at 02:54:52PM +0200, Felipe Balbi wrote:
>
> Hi Greg,
>
> Here's the first set of fixes for this rc cycle. Let me know if you want
> anything to be changed.
>
> cheers
>
> The following changes since commit 0c744ea4f77d72b3dcebb7a8f2684633ec79be88:
>
> Linux 4.10-rc2 (20
Hello,
I am hitting the following oops with 4.10-rc2 (on an intel edison, so
this is with Andy's patchset[1] which is currently based on 4.10-rc2
and does not seem to touch usb code) with Felipe's fixes-for-v4.10-rc3
merged on top of it.
The oops + kdb traceback:
[ 42.537029] file system regis
On 17-01-02 07:40 PM, Ansis Atteka wrote:
..
> I think that I am getting closer to the root cause of this bug. Also,
> I have a workaround that at least makes r8152 functionally stable in
> my Dell TB15 dock. Mark, would you mind giving a chance to the patch
> that I have in the bottom of this emai
On Tue, 2017-01-03 at 15:49 +0100, Vincent Pelletier wrote:
> Hello,
>
> I am hitting the following oops with 4.10-rc2 (on an intel edison, so
> this is with Andy's patchset[1] which is currently based on 4.10-rc2
> and does not seem to touch usb code) with Felipe's fixes-for-v4.10-rc3
> merged on
From: Jérémy Lefaure
The function bfin_fifo_offset is defined but not used:
drivers/usb/musb/blackfin.c:36:12: warning: ‘bfin_fifo_offset’ defined
but not used [-Wunused-function]
static u32 bfin_fifo_offset(u8 epnum)
^~~~
Adding bfin_fifo_offset to bfin_ops fixes this
During dma teardown for dequque urb, musb might generate bogus rx ep
interrupt even when the rx fifo is flushed. As mentioned in the current
inline comment, clearing ep interrupt in the teardown path avoids the
bogus interrupt.
Before this change, any of the follow log messages could happen when
m
This is for avoiding rx ep bogus interrupt during CPPI channel teardown.
cc: sta...@vger.kernel.org # 4.1+
Signed-off-by: Bin Liu
---
drivers/usb/musb/musb_dsps.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index f
Hi Greg,
These are musb fixes for v4.10-rc3, which fix the bugs in musb core and
some glue layers for some use cases, such as bogus interrupts while musb
in heavy load, WARINING while rmmod omap2430 glue, and a few fixes in PM,
and cleanup as while.
Please let me know if any change is needed.
Th
MUSB driver now has runtime PM support, but the debugfs driver misses
the PM _get/_put() calls, which could cause MUSB register access
failure.
Cc: sta...@vger.kernel.org # 4.9+
Signed-off-by: Bin Liu
Acked-by: Tony Lindgren
---
drivers/usb/musb/musb_debugfs.c | 20 +++-
1 file
From: Pali Rohár
Based on the musb ug, force_host bit is allowed to be set along with
force_hs or force_fs bit.
It could help to implement forced host mode via testmode on Nokia N900.
Signed-off-by: Pali Rohár
Signed-off-by: Bin Liu
---
drivers/usb/musb/musb_debugfs.c | 46 ++
From: Chanwoo Choi
This patch just uses the resource-managed extcon API when registering
the extcon notifier.
Signed-off-by: Chanwoo Choi
Acked-by: Maxime Ripard
[b-...@ti.com: revised subject prefix.]
Signed-off-by: Bin Liu
---
drivers/usb/musb/sunxi.c | 12 +++-
1 file changed, 3 i
The session is cleared in the core whenever musb_platform_disable() is
called, so clearing it in the glue driver *_musb_disable() is redundant.
Signed-off-by: Bin Liu
---
drivers/usb/musb/davinci.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/d
From: Alexandre Bailon
On da8xx, VBUS is not maintained during suspend when musb is in host mode.
On resume, all the connected devices will be disconnected and then will
be enumerated again.
This happens because MUSB_DEVCTL is cleared during suspend.
Use the quirk MUSB_PRESERVE_SESSION to presev
From: Alexandre Bailon
On da8xx, VBUS is not maintained during suspend when musb is in host mode.
On resume, all the connected devices will be disconnected and then will
be enumerated again.
This happens because MUSB_DEVCTL is cleared during suspend.
Add a quirk to not clear MUSB_DEVCTL and then
From: Alexandre Bailon
Implement PM methods specifics for da8xx glue.
The only thing to do is to power off the phy.
As the registers are in retention during suspend,
there is no need to save them.
Signed-off-by: Alexandre Bailon
Signed-off-by: Bin Liu
---
drivers/usb/musb/da8xx.c | 29 +++
The session is cleared in the core whenever musb_platform_disable() is
called, so clearing it in the glue driver *_musb_disable() is redundant.
Signed-off-by: Bin Liu
---
drivers/usb/musb/am35x.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x
The session is cleared in the core whenever musb_platform_disable() is
called, so clearing it in the glue driver *_musb_disable() is redundant.
Signed-off-by: Bin Liu
---
drivers/usb/musb/musb_dsps.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/mu
From: Jérémy Lefaure
The function musb_run_resume_work is called only when CONFIG_PM is
enabled. So this function should not be defined when CONFIG_PM is
disabled. Otherwise the compiler issues a warning:
drivers/usb/musb/musb_core.c:2057:12: error: ‘musb_run_resume_work’ defined but
not used [-
The session is cleared in the core whenever musb_platform_disable() is
called, so clearing it in the glue driver *_musb_disable() is redundant.
Signed-off-by: Bin Liu
---
drivers/usb/musb/da8xx.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx
musb_generic_disable() only has two lines of code. So remove it and let
the callers directly call those two lines.
Signed-off-by: Bin Liu
---
drivers/usb/musb/musb_core.c | 26 ++
1 file changed, 10 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c
From: Tony Lindgren
When unloading omap2430, we can get the following splat:
WARNING: CPU: 1 PID: 295 at kernel/irq/manage.c:1478 __free_irq+0xa8/0x2c8
Trying to free already-free IRQ 4
...
[] (free_irq) from []
(musbhs_dma_controller_destroy+0x28/0xb0 [musb_hdrc])
[] (musbhs_dma_controller_dest
On Tue, Jan 3, 2017 at 3:23 AM, Lukas Wunner wrote:
> On Mon, Jan 02, 2017 at 02:45:00PM -0700, Chris Murphy wrote:
>> On Mon, Jan 2, 2017 at 2:28 PM, Alan Stern wrote:
>> > Considering that the failed boot log contains no USB messages at all,
>> > and no messages referring to PCI bus :37 (th
On Tue, Jan 03, 2017 at 09:15:16AM -0600, Bin Liu wrote:
> From: Alexandre Bailon
>
> Implement PM methods specifics for da8xx glue.
> The only thing to do is to power off the phy.
> As the registers are in retention during suspend,
> there is no need to save them.
>
> Signed-off-by: Alexandre B
On Tue, Jan 03, 2017 at 09:15:08AM -0600, Bin Liu wrote:
> From: Tony Lindgren
>
> When unloading omap2430, we can get the following splat:
>
> WARNING: CPU: 1 PID: 295 at kernel/irq/manage.c:1478 __free_irq+0xa8/0x2c8
> Trying to free already-free IRQ 4
> ...
> [] (free_irq) from []
> (musbhs_d
On Tue, Jan 03, 2017 at 09:15:10AM -0600, Bin Liu wrote:
> The session is cleared in the core whenever musb_platform_disable() is
> called, so clearing it in the glue driver *_musb_disable() is redundant.
redundant is not a regression.
I'm stopping review of this series here, come on now, you kno
On Tue, Jan 03, 2017 at 09:15:09AM -0600, Bin Liu wrote:
> musb_generic_disable() only has two lines of code. So remove it and let
> the callers directly call those two lines.
>
> Signed-off-by: Bin Liu
> ---
> drivers/usb/musb/musb_core.c | 26 ++
> 1 file changed, 10 in
Since commit b69578df7e98 ("USB: usbserial: mos7720: add support for
parallel port on moschip 7715"), the interrupt urb is no longer
submitted at first port open and the endpoint-address initialisation at
port-probe is no longer used.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/mos7720.c
Remove code to manage a write URB that was never allocated.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/mos7840.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/usb/serial/mos7840.c b/drivers/usb/serial/mos7840.c
index bb933c6321e5..c03cd511669a 100644
--- a/drivers/us
The interrupt URB was submitted on probe but never stopped on probe
errors. This can lead to use-after-free issues in the completion
handler when accessing the freed usb-serial struct:
Unable to handle kernel paging request at virtual address 6b6b6be7
...
[] (mos7715_interrupt_callback [mos7720])
The write URB was being killed using the synchronous interface while
holding a spin lock in close().
Simply drop the lock and busy-flag update, something which would have
been taken care of by the completion handler if the URB was in flight.
Fixes: f7a33e608d9a ("USB: serial: add quatech2 usb to
Check for the expected endpoints in attach() and fail loudly if not
present.
Note that failing to do this appears to be benign since da280e348866
("USB: keyspan_pda: clean up write-urb busy handling") which prevents a
NULL-pointer dereference in write() by never marking a non-existent
write-urb as
Do not submit the interrupt URB until after the parport has been
successfully registered to avoid another use-after-free in the
completion handler when accessing the freed parport private data in case
of a racing completion.
Fixes: b69578df7e98 ("USB: usbserial: mos7720: add support for parallel
p
The interrupt URB is killed at final port close since commit
0de9a7024e7a ("USB: overhaul of mos7840 driver").
Fixes: 0de9a7024e7a ("USB: overhaul of mos7840 driver")
Signed-off-by: Johan Hovold
---
drivers/usb/serial/mos7840.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git
A static usb-serial-driver structure that is used to initialise the
interrupt URB was modified during probe depending on the currently
probed device type, something which could break a parallel probe of a
device of a different type.
Fix this up by overriding the default completion callback for MCS
Fix NULL-pointer dereference in write() should the device lack the
expected interrupt-out endpoint:
Unable to handle kernel NULL pointer dereference at virtual address 0054
...
PC is at kobil_write+0x144/0x2a0 [kobil_sct]
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable
Signed-off-by: Joh
Fix NULL-pointer dereferences at open() and disconnect() should the
device lack the expected bulk-out endpoints:
Unable to handle kernel NULL pointer dereference at virtual address 00b4
...
[c0170ff0>] (__lock_acquire) from [] (lock_acquire+0x108/0x264)
[] (lock_acquire) from [] (_raw_spin_loc
Fix NULL-pointer dereference in open() should the device lack the
expected endpoints:
Unable to handle kernel NULL pointer dereference at virtual address 0030
...
PC is at mos7840_open+0x88/0x8dc [mos7840]
Note that we continue to treat the interrupt-in endpoint as optional for
now.
Fixes: 3
Fix NULL-pointer dereference at port open if a device lacks the expected
bulk in and out endpoints.
Unable to handle kernel NULL pointer dereference at virtual address 0030
...
[] (mos7720_open [mos7720]) from []
(serial_port_activate+0x68/0x98 [usbserial])
[] (serial_port_activate [usbserial
Bind to the interface, but do not register any ports, after having
downloaded the firmware. The device will still disconnect and
re-enumerate, but this way we avoid an error messages from being logged
as part of the process:
io_ti: probe of 1-1.3:1.0 failed with error -5
Signed-off-by: Johan Hovo
In case a device is left in "boot-mode" we must not register any port
devices in order to avoid a NULL-pointer dereference on open due to
missing endpoints. This could be used by a malicious device to trigger
an OOPS:
Unable to handle kernel NULL pointer dereference at virtual address 0030
...
Fix NULL-pointer dereference when clearing halt at open should a
malicious device lack the expected endpoints when in download mode.
Unable to handle kernel NULL pointer dereference at virtual address 0030
...
[] (edge_open [io_ti]) from []
(serial_port_activate+0x68/0x98 [usbserial])
[] (ser
Fix NULL-pointer dereference in open() should the device lack the
expected endpoints:
Unable to handle kernel NULL pointer dereference at virtual address 0030
...
PC is at oti6858_open+0x30/0x1d0 [oti6858]
Note that a missing interrupt-in endpoint would have caused open() to
fail.
Fixes: 49c
On Tue, Jan 03, 2017 at 09:15:07AM -0600, Bin Liu wrote:
> This is for avoiding rx ep bogus interrupt during CPPI channel teardown.
This is one of the worse changelog texts ever...
Hint, don't use "This" :)
And the text doesn't seem to describe this very well...
thanks,
greg k-h
--
To unsubscr
Cancel the heartbeat work on driver unbind in order to avoid I/O after
disconnect in case the port is held open.
Note that the cancel in release() is still needed to stop the heartbeat
after late probe errors.
Fixes: 26c78daade0f ("USB: io_ti: Add heartbeat to keep idle EP/416
ports from disconne
This series fixes a number of long-standing issues in various USB-serial
drivers which would lead to crashes should a malicious device lack the
expected endpoints.
Included are also a few related fixes, and a couple of unrelated ones
that were found during my survey (e.g. a memleak and
a sleep-whi
Make sure to free the URB transfer buffer in case submission fails (e.g.
due to a disconnect).
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable
Signed-off-by: Johan Hovold
---
drivers/usb/serial/garmin_gps.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/serial/garmin_gps.c
Fix NULL-pointer dereference in open() should a type-0 or type-1 device
lack the expected endpoints:
Unable to handle kernel NULL pointer dereference at virtual address 0030
...
PC is at pl2303_open+0x38/0xec [pl2303]
Note that a missing interrupt-in endpoint would have caused open() to
fail.
Fix NULL-pointer dereference in open() should a malicious device lack
the expected endpoints:
Unable to handle kernel NULL pointer dereference at virtual address 0030
..
[] (ti_open [ti_usb_3410_5052]) from []
(serial_port_activate+0x68/0x98 [usbserial])
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc
Fix NULL-pointer dereference in open() should the device lack the
expected endpoints:
Unable to handle kernel NULL pointer dereference at virtual address 0030
...
PC is at spcp8x5_open+0x30/0xd0 [spcp8x5]
Fixes: 619a6f1d1423 ("USB: add usb-serial spcp8x5 driver")
Cc: stable
Signed-off-by: Jo
Fix NULL-pointer dereference at open should the device lack a bulk-in or
bulk-out endpoint:
Unable to handle kernel NULL pointer dereference at virtual address 0030
...
PC is at iuu_open+0x78/0x59c [iuu_phoenix]
Fixes: 07c3b1a10016 ("USB: remove broken usb-serial num_endpoints
check")
Cc: sta
Fix NULL-pointer dereference when initialising URBs at open should a
non-EPIC device lack a bulk-in or interrupt-in endpoint.
Unable to handle kernel NULL pointer dereference at virtual address 0028
...
PC is at edge_open+0x24c/0x3e8 [io_edgeport]
Note that the EPIC-device probe path has the
On Tue, Jan 03, 2017 at 09:15:06AM -0600, Bin Liu wrote:
> During dma teardown for dequque urb, musb might generate bogus rx ep
> interrupt even when the rx fifo is flushed. As mentioned in the current
> inline comment, clearing ep interrupt in the teardown path avoids the
> bogus interrupt.
>
> B
On Tue, Jan 03, 2017 at 09:15:05AM -0600, Bin Liu wrote:
> Hi Greg,
>
> These are musb fixes for v4.10-rc3, which fix the bugs in musb core and
> some glue layers for some use cases, such as bogus interrupts while musb
> in heavy load, WARINING while rmmod omap2430 glue, and a few fixes in PM,
> a
On Tue, Jan 3, 2017 at 2:28 AM, Oliver Neukum wrote:
> On Mon, 2017-01-02 at 14:45 -0700, Chris Murphy wrote:
>> I see these lines in the problem case, which don't occur in the
>> working case.
>>
>> [0.561046] pci_bus :37: busn_res: [bus 37-ff] end is updated
>> to 37
>> [0.561047] pc
On Tue, Jan 03, 2017 at 04:34:48PM +0100, Greg KH wrote:
> On Tue, Jan 03, 2017 at 09:15:06AM -0600, Bin Liu wrote:
> > During dma teardown for dequque urb, musb might generate bogus rx ep
> > interrupt even when the rx fifo is flushed. As mentioned in the current
> > inline comment, clearing ep in
On Tue, 2017-01-03 at 17:00 +0200, Andy Shevchenko wrote:
> On Tue, 2017-01-03 at 15:49 +0100, Vincent Pelletier wrote:
> > Hello,
> >
> > I am hitting the following oops with 4.10-rc2 (on an intel edison,
> > so
> > this is with Andy's patchset[1] which is currently based on 4.10-rc2
> > and does
On Tue, Jan 03, 2017 at 04:38:47PM +0100, Greg KH wrote:
> On Tue, Jan 03, 2017 at 09:15:05AM -0600, Bin Liu wrote:
> > Hi Greg,
> >
> > These are musb fixes for v4.10-rc3, which fix the bugs in musb core and
> > some glue layers for some use cases, such as bogus interrupts while musb
> > in heavy
Fix NULL-pointer dereference when clearing halt at open should the device
lack a bulk-out endpoint.
Unable to handle kernel NULL pointer dereference at virtual address 0030
...
PC is at cyberjack_open+0x40/0x9c [cyberjack]
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable
Signed-off-by: Jo
On Tue, Jan 03, 2017 at 04:35:38PM +0100, Greg KH wrote:
> On Tue, Jan 03, 2017 at 09:15:07AM -0600, Bin Liu wrote:
> > This is for avoiding rx ep bogus interrupt during CPPI channel teardown.
>
> This is one of the worse changelog texts ever...
>
> Hint, don't use "This" :)
>
> And the text doe
From: Wan Ahmad Zainie
Intel Apollo Lake also requires XHCI_PME_STUCK_QUIRK.
Adding its PCI ID to quirk.
Cc:
Signed-off-by: Wan Ahmad Zainie
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-pci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhc
From: Baolin Wang
When current command was supposed to be aborted, host will free the command
in handle_cmd_completion() function. But it might be still referenced by
xhci->current_cmd, which need to set NULL.
Cc:
Signed-off-by: Baolin Wang
Signed-off-by: Mathias Nyman
---
drivers/usb/host/x
From: Felipe Balbi
Stop Endpoint command can come at any point and we
have no control of that. We should make sure to
handle COMP_STOP on SETUP phase as well, otherwise
urb->actual_length might be set to negative values
in some occasions such as below:
urb->length = 4;
build_control_transfer_t
the tt_info provided by a HS hub might be in use to by a child device
Make sure we free the devices in the correct order.
This is needed in special cases such as when xhci controller is
reset when resuming from hibernate, and all virt_devices are freed.
Also free the virt_devices starting from ma
Hi Greg
These xhci fixes for usb-linus are mostly related to solving
race issues found when commands time out. i.e. host or device
is behaving baldy and we need to clean things up.
-Mathias
Baolin Wang (1):
usb: host: xhci: Fix possible wild pointer when handling abort command
Felipe Balbi (1
On Tue, Jan 03, 2017 at 04:39:40PM +0100, Johan Hovold wrote:
> Fix NULL-pointer dereference when clearing halt at open should the device
> lack a bulk-out endpoint.
>
> Unable to handle kernel NULL pointer dereference at virtual address 0030
> ...
> PC is at cyberjack_open+0x40/0x9c [cyberjac
On Tue, Jan 03, 2017 at 09:47:47AM -0600, Bin Liu wrote:
> On Tue, Jan 03, 2017 at 04:34:48PM +0100, Greg KH wrote:
> > On Tue, Jan 03, 2017 at 09:15:06AM -0600, Bin Liu wrote:
> > > During dma teardown for dequque urb, musb might generate bogus rx ep
> > > interrupt even when the rx fifo is flushe
On Tue, Jan 03, 2017 at 10:01:43AM -0600, Bin Liu wrote:
> On Tue, Jan 03, 2017 at 04:38:47PM +0100, Greg KH wrote:
> > On Tue, Jan 03, 2017 at 09:15:05AM -0600, Bin Liu wrote:
> > > Hi Greg,
> > >
> > > These are musb fixes for v4.10-rc3, which fix the bugs in musb core and
> > > some glue layers
From: OGAWA Hirofumi
This is preparation to fix abort operation race (See "xhci: Fix race
related to abort operation"). To make timeout sleepable, use
delayed_work instead of timer.
[change a newly added pending timer fix to pending work -Mathias]
Signed-off-by: OGAWA Hirofumi
Signed-off-by: Ma
From: OGAWA Hirofumi
Current abort operation has race.
xhci_handle_command_timeout()
xhci_abort_cmd_ring()
xhci_write_64(CMD_RING_ABORT)
xhci_handshake(5s)
do {
check CMD_RING_RUNNING
udelay(1)
.
From: Lu Baolu
xhci_setup_device() should return failure with correct error number
when xhci host has died, removed or halted.
During usb device enumeration, if usb host is not accessible (died,
removed or halted), the hc_driver->address_device() should return
a corresponding error code to usb c
From: Lu Baolu
handle_cmd_completion() frees a command structure which might be still
referenced by xhci->current_cmd.
This might cause problem when xhci->current_cmd is accessed after that.
A real-life case could be like this. The host takes a very long time to
respond to a command, and the com
From: Pan Bian
In function xhci_mtk_probe(), variable ret takes the return value. Its
value should be negative on failures. However, when the call to function
platform_get_irq() fails, it does not set the error code, and 0 will be
returned. 0 indicates no error. As a result, the callers of functi
From: Lu Baolu
In command timer function, xhci_handle_command_timeout(), xhci->lock
is unlocked before call into xhci_abort_cmd_ring(). This might cause
race between the timer function and the event handler.
The xhci_abort_cmd_ring() function sets the CMD_RING_ABORT bit in the
command register a
If we get a command completion event at the same time as the command
timeout work starts on another cpu we might end up aborting the wrong
command.
If the command completion takes the xhci lock before the timeout work, it
will handle the command, pick the next command, mark it as current_cmd, and
On 03.01.2017 14:53, Felipe Balbi wrote:
Hi,
Roger Quadros writes:
Mathias & Felipe,
On 17/11/16 17:01, Roger Quadros wrote:
Hi,
Some XHCI controllers e.g. dwc3 based have a broken Port disable [1].
If the attached high-speed device is misbehaving, the USB stack typically
disables the por
On Tue, Jan 03, 2017 at 10:16:53AM -0600, Bin Liu wrote:
> On Tue, Jan 03, 2017 at 04:36:44PM +0100, Greg KH wrote:
> > On Tue, Jan 03, 2017 at 09:15:09AM -0600, Bin Liu wrote:
> > > musb_generic_disable() only has two lines of code. So remove it and let
> > > the callers directly call those two li
On Tue, Jan 03, 2017 at 05:27:07PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 03, 2017 at 04:39:40PM +0100, Johan Hovold wrote:
> > Fix NULL-pointer dereference when clearing halt at open should the device
> > lack a bulk-out endpoint.
> >
> > Unable to handle kernel NULL pointer dereference a
On Mon, Jan 02, 2017 at 10:53:55PM +0200, Aaro Koskinen wrote:
> Defer probe if PHY is missing. E.g. on Nokia 770 several modules needs
> to be loaded to get the PHY going and ohci-omap should wait for those.
>
> Signed-off-by: Aaro Koskinen
Is this a new bug? The 770 has been around for foreve
On Tue, Jan 03, 2017 at 10:50:52AM -0600, Bin Liu wrote:
> On Tue, Jan 03, 2017 at 05:27:53PM +0100, Greg KH wrote:
> > On Tue, Jan 03, 2017 at 10:01:43AM -0600, Bin Liu wrote:
> > > On Tue, Jan 03, 2017 at 04:38:47PM +0100, Greg KH wrote:
> > > > On Tue, Jan 03, 2017 at 09:15:05AM -0600, Bin Liu w
On Tue, Jan 03, 2017 at 05:48:05PM +0100, Johan Hovold wrote:
> On Tue, Jan 03, 2017 at 05:27:07PM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Jan 03, 2017 at 04:39:40PM +0100, Johan Hovold wrote:
> > > Fix NULL-pointer dereference when clearing halt at open should the device
> > > lack a bulk-out
On 29.12.2016 13:00, Felipe Balbi wrote:
Stop Endpoint command can come at any point and we
have no control of that. We should make sure to
handle COMP_STOP on SETUP phase as well, otherwise
urb->actual_lenght might be set to negative values
in some occasions such as below:
urb->length = 4;
On Tue, Jan 03, 2017 at 05:28:22PM +0100, Greg KH wrote:
> On Tue, Jan 03, 2017 at 09:47:47AM -0600, Bin Liu wrote:
> > On Tue, Jan 03, 2017 at 04:34:48PM +0100, Greg KH wrote:
> > > On Tue, Jan 03, 2017 at 09:15:06AM -0600, Bin Liu wrote:
> > > > During dma teardown for dequque urb, musb might gen
On Tue, Jan 03, 2017 at 05:57:47PM +0100, Greg KH wrote:
> On Tue, Jan 03, 2017 at 10:50:52AM -0600, Bin Liu wrote:
> > On Tue, Jan 03, 2017 at 05:27:53PM +0100, Greg KH wrote:
> > > On Tue, Jan 03, 2017 at 10:01:43AM -0600, Bin Liu wrote:
> > > > On Tue, Jan 03, 2017 at 04:38:47PM +0100, Greg KH w
Checking more, I think the 3 "do {...} while(--count)" loops in f_fs.c
are wrong: they should be "while(count--){...}" ("git format-patch"
attached, sorry, I'm on a dev-hostile mail client at the moment):
- count covers function-specific endpoint, so it is 0 when no endpoint
is declared, which lead
On Tue, Jan 03, 2017 at 11:07:42AM -0600, Bin Liu wrote:
> On Tue, Jan 03, 2017 at 05:28:22PM +0100, Greg KH wrote:
> > On Tue, Jan 03, 2017 at 09:47:47AM -0600, Bin Liu wrote:
> > > On Tue, Jan 03, 2017 at 04:34:48PM +0100, Greg KH wrote:
> > > > On Tue, Jan 03, 2017 at 09:15:06AM -0600, Bin Liu w
On Tue, Jan 03, 2017 at 11:07:42AM -0600, Bin Liu wrote:
> On Tue, Jan 03, 2017 at 05:28:22PM +0100, Greg KH wrote:
> > On Tue, Jan 03, 2017 at 09:47:47AM -0600, Bin Liu wrote:
> > > On Tue, Jan 03, 2017 at 04:34:48PM +0100, Greg KH wrote:
> > > > On Tue, Jan 03, 2017 at 09:15:06AM -0600, Bin Liu w
Hi Bin,
Bin Liu writes:
> On Tue, Jan 03, 2017 at 05:28:22PM +0100, Greg KH wrote:
>> On Tue, Jan 03, 2017 at 09:47:47AM -0600, Bin Liu wrote:
>> > On Tue, Jan 03, 2017 at 04:34:48PM +0100, Greg KH wrote:
>> > > On Tue, Jan 03, 2017 at 09:15:06AM -0600, Bin Liu wrote:
>> > > > During dma teardow
Hi,
Mathias Nyman writes:
> On 29.12.2016 13:00, Felipe Balbi wrote:
>> Stop Endpoint command can come at any point and we
>> have no control of that. We should make sure to
>> handle COMP_STOP on SETUP phase as well, otherwise
>> urb->actual_lenght might be set to negative values
>> in some occ
1 - 100 of 154 matches
Mail list logo
