On 14.10.2019 13.16, Johan Hovold wrote:
On Fri, Oct 11, 2019 at 03:58:42PM +0300, Mathias Nyman wrote:
commit ef513be0a905 ("usb: xhci: Add Clear_TT_Buffer") schedules work
to clear TT buffer, but causes a use-after-free regression at the same time
Make sure hub_tt_work finis
On 3.10.2019 18.13, Bernhard Gebetsberger wrote:
I sent the instructions to one of the users in the bug tracker.
Here is the download link for his logs: https://www.sendspace.com/file/413hlj
Thanks.
Traces show driver handles the Transaction error normally by issuing a endpoint
reset,
which i
("usb: xhci: Add Clear_TT_Buffer")
Cc: # v5.3
Reported-by: Johan Hovold
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci.c | 43 +++
1 file changed, 43 insertions(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 5cfbf9a
On 8.10.2019 11.15, Mathias Nyman wrote:
On 7.10.2019 17.02, Johan Hovold wrote:
I didn't have time to look into this myself last week, or comment on the
patch before Greg picked it up, but this clearly isn't the right fix.
As your comment suggests, ep->hcpriv may indeed be NUL
On 7.10.2019 17.02, Johan Hovold wrote:
[ +CC: Alan ]
On Fri, Oct 04, 2019 at 02:59:33PM +0300, Mathias Nyman wrote:
udev stored in ep->hcpriv might be NULL if tt buffer is cleared
due to a halted control endpoint during device enumeration
xhci_clear_tt_buffer_complete is called
ncorrect when doing the comparison.
The patch which added this false warning was backported to 4.8+ kernels
so this should be backported as far as well.
Cc: # v4.8+
Fixes: 597c56e372da ("xhci: update bounce buffer with correct sg num")
Signed-off-by: Mathias Nyman
---
drivers/usb/host/
;xhci: Clear the host side toggle manually when
endpoint is soft reset")
Cc: # v4.17+
Cc: Torez Smith
Signed-off-by: Bill Kuzeja
Signed-off-by: Torez Smith
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
prevent the use of multiple USB3 cameras that should be able to work.
Cc:
Signed-off-by: Jan Schmidt
Tested-by: Philipp Zabel
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers
xhci_get_timeout_no_hub_lpm() returns anything else than USB3_LPM_DISABLED
While at it fix the split line error message
Tested-by: Jan Schmidt
Cc:
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers
ai-Heng Feng
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 8c068d0cc7c1..00f3804f7aa7 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1
attempt.
Fixes: ef513be0a905 ("usb: xhci: Add Clear_TT_Buffer")
Cc: # v5.3
Reported-by: Johan Hovold
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 00f3804f
instead of 0x10.
Detect the USB 3.1 capability correctly for these hosts as well
Fixes: ddd57980a0fd ("xhci: detect USB 3.2 capable host controllers correctly")
Cc: # v4.18+
Cc: Loïc Yhuel
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci.c | 15 +++
1 file c
From: Rick Tseng
NVIDIA 3.1 xHCI card would lose power when moving power state into D3Cold.
Thus we need to wait for CNR bit to clear in xhci resume, just as in
xhci init.
[Minor changes to comment and commit message -Mathias]
Cc:
Signed-off-by: Rick Tseng
Signed-off-by: Mathias Nyman
: Prevent deadlock when xhci adapter breaks during init
Jan Schmidt (1):
xhci: Check all endpoints for LPM timeout
Kai-Heng Feng (1):
xhci: Increase STS_SAVE timeout in xhci_suspend()
Mathias Nyman (4):
xhci: Fix false warning message about wrong bounce buffer write length
xhci: Prevent device
On 2.10.2019 15.28, Bernhard Gebetsberger wrote:
Hi,
There has been a regression in the xhci driver since kernel version 4.20, on
some systems some usb devices won't work until the system gets rebooted.
The error message in dmesg is "WARN Set TR Deq Ptr cmd failed due to incorrect slot
or ep s
On 30.9.2019 13.31, Johan Hovold wrote:
Hi Mathias,
I hit this NULL-deref in xhci_clear_tt_buffer_complete() with usb-next
after an external HS hub with a connected FS device got into some weird
state this morning:
[ 66.833702] usb 2-2.4: USB disconnect, device number 5
[ 66.834756] usblcd
On 29.9.2019 9.07, Peter Chen wrote:
On some situations, the software handles TRB events slower
than adding TRBs, then xhci_handle_event can't return zero
long time, the xHC will consider the event ring is full,
and trigger "Event Ring Full" error, but in fact, the software
has already finished l
On 27.9.2019 10.03, Peter Chen wrote:
On 19-09-26 13:25:39, Mathias Nyman wrote:
On 24.9.2019 11.35, Peter Chen wrote:
On some situations, the software handles TRB events slower
than adding TRBs, then xhci_handle_event can't return zero
long time, the xHC will consider the event ring is
On 24.9.2019 11.35, Peter Chen wrote:
On some situations, the software handles TRB events slower
than adding TRBs, then xhci_handle_event can't return zero
long time, the xHC will consider the event ring is full,
and trigger "Event Ring Full" error, but in fact, the software
has already finished
On 26.9.2019 8.45, Felipe Balbi wrote:
Hi,
David Laight writes:
From: Mathias Nyman
Sent: 25 September 2019 15:48
On 24.9.2019 17.45, alex zheng wrote:
Hi Mathias,
...
Logs show your transfer ring has four segments, but hardware fails to
jump from the last segment back to first)
Last
On 24.9.2019 17.45, alex zheng wrote:
Hi Mathias,
I try to ignore the DMA errors, then the transfer continues but it
complete with data lost, it seems like these ERROR Transfer event
should be right and must not be ignore.
test app show:
"did not get enough data, received size:14410176/1500
On 16.9.2019 23.53, Loïc Yhuel wrote:
Le lun. 16 sept. 2019 à 17:19, Loïc Yhuel a écrit :
Most reliable way of checking the current actual port speed is reading protocol
speed id
from the ports PORTSC register port-speed field.
Use debugfs: (with your correct pci address and port number)
Cu
On 18.9.2019 12.41, Rick Tseng wrote:
NVIDIA 3.1 xHCI card would lose power when moving power state into D3Cold.
Thus we need to wait CNR bit to clear when xhci resmue as xhci init.
Signed-off-by: Rick Tseng
Thanks, added to queue.
Did minor changes to commit message and comment
-Mathias
249461b504 ("xhci: Clear the host side toggle manually when
endpoint is soft reset")
Cc: Mathias Nyman
Cc: Torez Smith
Signed-off-by: Bill Kuzeja
Signed-off-by: Torez Smith
---
Thanks, adding to queue
-Mathias
On 23.9.2019 14.19, Mathias Nyman wrote:
On 19.9.2019 16.59, Suwan Kim wrote:
On Thu, Sep 19, 2019 at 05:54:25PM +0800, Peter Chen wrote:
On 17.9.2019 12.55, Peter Chen wrote:
I met "event ring full error" like below, this error is met when
I do iozone test on UAS storage at v4.19
On 19.9.2019 16.59, Suwan Kim wrote:
On Thu, Sep 19, 2019 at 05:54:25PM +0800, Peter Chen wrote:
On 17.9.2019 12.55, Peter Chen wrote:
I met "event ring full error" like below, this error is met when
I do iozone test on UAS storage at v4.19.35 kernel, but not meet
this error at linux-next tree
On 23.9.2019 10.08, alex zheng wrote:
Hi, balbi,
Thank you for your reply~
Felipe Balbi 于2019年9月23日周一 下午1:36写道：
Hi,
(it helps when you Cc correct maintainers ;-)
alex zheng writes:
Hi all,
I am a user of dwc3 USB host controller, I found there are some
confused behavior of trb event o
On 17.9.2019 12.55, Peter Chen wrote:
I met "event ring full error" like below, this error is met when
I do iozone test on UAS storage at v4.19.35 kernel, but not meet
this error at linux-next tree (08/24). The same host and test
UAS storage device are used. This issue is due to xhci_handle_even
On 17.9.2019 18.56, Jan Schmidt wrote:
On 18/9/19 12:53 am, Mathias Nyman wrote:
If host/hub initiated link pm is prevented by a driver flag we still must
ensure that periodic endpoints have longer service intervals than link pm
exit latency before allowing device initiated link pm.
Fix this
xhci_get_timeout_no_hub_lpm() returns anything else than USB3_LPM_DISABLED
While at it fix the split line error message
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index
On 16.9.2019 12.41, Peter Chen wrote:
Hi Mathias,
I met "event ring full error" like below, this error is met when
I do iozone test on UAS storage at v4.19.35 kernel, but not meet
this error at linux-next tree (08/24). The same host and test
UAS storage device are used. This issue is due to xhci
On 16.9.2019 5.41, Loïc Yhuel wrote:
Hello,
I'm trying to get Gen 2 working on this controller.
It drives 2 USB ports on the back panel of an ASUS Prime X399-A (latest BIOS).
ASM2142 FW is 170308_70_02_00 (seen with ASM2142A_MPTool on Windows).
On Windows 10 it uses the Microsoft xhci driver, an
On 12.9.2019 17.49, Jan Schmidt wrote:
If an endpoint is encountered that returns USB3_LPM_DEVICE_INITIATED, keep
checking further endpoints, as there might be periodic endpoints later
that return USB3_LPM_DISABLED due to shorter service intervals.
Without this, the code can set too high a maxim
On 6.9.2019 8.36, Rick Tseng wrote:
NVIDIA 3.1 xHCI card would lose power when moving power state into D3Cold.
Thus we need to wait CNR bit to clear when xhci resmue as xhci init.
Signed-off-by: Rick Tseng
---
drivers/usb/host/xhci.c | 9 +
1 file changed, 9 insertions(+)
diff --git
: dbc: Simplify error handling in 'xhci_dbc_alloc_requests()'
usb: xhci: dbc: Use GFP_KERNEL instead of GFP_ATOMIC in
'xhci_dbc_alloc_requests()'
Ikjoon Jang (1):
xhci: fix possible memleak on setup address fails.
Mathias Nyman (1):
xhci: add TSP bitflag to TRB tracin
xhci_debugfs_free_dev() from
xhci_free_dev() to xhci_disable_slot().
[added "possible" to header as this is about failure codepath -Mathias]
Signed-off-by: Ikjoon Jang
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
di
From: Christophe JAILLET
There is no need to use GFP_ATOMIC to allocate 'req'. GFP_KERNEL should be
enough and is already used for another allocation juste a few lines below.
Signed-off-by: Christophe JAILLET
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-dbgtty.c | 2
re equivalent here because:
static void xhci_dbc_free_req(struct dbc_ep *dep, struct dbc_request *req)
{
kfree(req->buf);
dbc_free_request(dep, req);
}
and 'req->buf' is known to be NULL at this point
Signed-off-by: Christophe JAILLET
Signed-off-by: Mathias Nyman
---
Software can set a Transfer State Preserve (TSP) flag to maintain
data toggle and sequence number when issuing a reset endpoint
command.
xhci driver is using TSP for soft retry, we want to show TSP usage
in tracing as well
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci.h | 3 ++-
1
On 27.8.2019 19.35, Theodore Y. Ts'o wrote:
On Tue, Aug 27, 2019 at 08:00:14AM +0200, Harald Dunkel wrote:
FYI: "fsck -y" on an external USB drive (USB-C, ext4) gave
me a ton of messages
:
[ 191.261939] xhci_hcd :05:00.0: WARN Wrong bounce buffer write length:
1024 != 0
[ 191.263743] xhc
On 26.8.2019 12.29, Rafael J. Wysocki wrote:
On Mon, Aug 26, 2019 at 11:11 AM Daniel Drake wrote:
Hi,
Working with a new consumer laptop based on AMD Ryzen 7 3700U, all USB
functionality goes dead upon suspend/resume (s2idle). Reproduced on
linus master from today.
I wonder if you can repro
irty.
And now as you accept the patch for upstream i can replace the dirty hack
by the official patch for next SOP.
Thanks for fixing this, it solves a real upstream xhci related issue since 4.19.
Fix is outside xhci so accepting this is no longer up to me, but for Greg:
Reviewed-by: Mathias Nyman
On 25.8.2019 11.29, Greg KH wrote:
On Fri, Aug 23, 2019 at 02:11:28PM +, Schmid, Carsten wrote:
Using managed device resources in usb_hcd_pci_probe() allows devm usage for
resource subranges, such as the mmio resource for the platform device
created to control host/device mode mux, which is
On 23.8.2019 13.06, Schmid, Carsten wrote:
On driver removal, the platform_device_unregister call
attached through devm_add_action_or_reset was executed
after usb_hcd_pci_remove.
This lead to a use-after-free for the iomem resource of
the xhci-ext-caps driver in the platform removal
because the p
On 23.8.2019 9.40, Chunfeng Yun wrote:
Some SoCs may have an optional clock xhci_ck (125M or 200M), it
usually uses the same PLL as sys_ck, so support it.
Signed-off-by: Chunfeng Yun
Acked-by: Mathias Nyman
On 16.8.2019 12.03, Schmid, Carsten wrote:
On driver removal, the platform_device_unregister call
attached through devm_add_action_or_reset was executed
after usb_hcd_pci_remove.
This lead to a use-after-free for the iomem resource of
the xhci-ext-caps driver in the platform removal
because the p
On 21.8.2019 6.18, Peter Chen wrote:
According to xHCI 1.1 CH4.19.4 Port Power:
While Chip Hardware Reset or HCRST is asserted,
the value of PP is undefined. If the xHC supports
power switches (PPC = ‘1’) then VBus may be deasserted
during t
On 11.8.2019 11.22, Ikjoon Jang wrote:
Xhci re-enables a slot on transaction error in set_address using
xhci_disable_slot() + xhci_alloc_dev().
But in this case, xhci_alloc_dev() creates debugfs entries upon an
existing device without cleaning up old entries, thus memory leaks.
So this patch si
On 13.8.2019 9.50, Kai-Heng Feng wrote:
Hi Mathias,
at 21:24, Kai-Heng Feng wrote:
at 22:45, Mathias Nyman wrote:
[snipped]
Yes, disabling runtime PM can workaround this issue.
What’s next step here? Is it a firmware bug?
Can't say.
From xhci driver point of view the 39:00.
Hi,
Rick Tseng writes:
Hi Mathias,
Thanks for suggestion.
The reason I do not use xhci_handshake() is we get build fail when configuring
below as module:
USB_XHCI_HCD = m
USB_XHCI_PCI = m
Fail message as below:
ERROR: "xhci_handshake" [drivers/usb/host/xhci-pci.ko] undefined!
So I write my
On 12.8.2019 11.19, Oliver Neukum wrote:
Am Montag, den 12.08.2019, 15:24 +0800 schrieb Rick Tseng:
From: Rick
NVIDIA 3.1 xHCI card would lose power when moving power state into D3Cold.
Thus we need to wait CNR bit to clear when xhci resmue as xhci init.
Should any controller have CNR set? W
On 7.8.2019 7.25, Rob Weber wrote:
Hi Everyone,
(Pinging Mathias regarding xHCI support of the USB 2.0 test modes)
On Mon, Aug 05, 2019 at 02:07:23PM +0800, Peter Chen wrote:
On Sun, Aug 4, 2019 at 10:45 AM Evan Gates wrote:
I'm trying to get my device to pass the EHSET tests. I found the
On 31.7.2019 15.51, Christophe JAILLET wrote:
Christophe JAILLET (2):
usb: xhci: dbc: Simplify error handling in 'xhci_dbc_alloc_requests()'
usb: xhci: dbc: Use GFP_KERNEL instead of GFP_ATOMIC in
'xhci_dbc_alloc_requests()'
drivers/usb/host/xhci-dbgtty.c | 4 ++--
1 file changed
properly reenabled.
Reported-by: Bob Gleitsmann
Reported-by: Enric Balletbo Serra
Fixes: ef513be0a905 ("usb: xhci: Add Clear_TT_Buffer")
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/usb/host/xhci.c
On 31.7.2019 19.31, Enric Balletbo Serra wrote:
Missatge de Mathias Nyman del dia dc.,
31 de jul. 2019 a les 16:16:
On 31.7.2019 12.18, Enric Balletbo Serra wrote:
Hi Mathias,
Thanks to look into this.
Missatge de Mathias Nyman del dia dt.,
30 de jul. 2019 a les 21:39:
On 27.7.2019
On 31.7.2019 12.18, Enric Balletbo Serra wrote:
Hi Mathias,
Thanks to look into this.
Missatge de Mathias Nyman del dia dt.,
30 de jul. 2019 a les 21:39:
On 27.7.2019 23.43, Bob Gleitsmann wrote:
OK, here's the result of the bisection:
ef513be0a9057cc6baf5d29566aaaefa214ba344 is the
sb_hub_clear_tt_buffer() to send Clear_TT_Buffer
?? request to the hub of the device for the following Set_Interface
?? requests to the device to get ACK successfully.
??
?? Signed-off-by: Jim Lin
?? Acked-by: Mathias Nyman
?? Signed-off-by: Greg Kroah-Hartman
??drivers/usb/hos
uffer() to send Clear_TT_Buffer
?? request to the hub of the device for the following Set_Interface
?? requests to the device to get ACK successfully.
??
?? Signed-off-by: Jim Lin
?? Acked-by: Mathias Nyman
?? Signed-off-by: Greg Kroah-Hartman
??drivers/usb/host/x
On 24.7.2019 22.09, Daniele Palmas wrote:
Hello all,
I've a system with kernel 4.14.127 that is showing unexpected xhci-hcd
(ASM1042A) errors with a Qualcomm based modem, when running the
following test:
- signal strength qmi requests looping every few seconds on
/dev/cdc-wdm (driver qmi_wwan)
fer list is used.
Fixes: 33e39350ebd2 ("usb: xhci: add Immediate Data Transfer support")
Cc: # v5.2
Reported-by: Maik Stohn
Tested-by: Maik Stohn
CC: Nicolas Saenz Julienne
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
On 24.7.2019 19.29, Maik Stohn wrote:
Am 24.07.2019 um 18:03 schrieb Mathias Nyman :
On 24.7.2019 17.34, Maik Stohn wrote:
Am 24.07.2019 um 16:20 schrieb Greg KH :
On Wed, Jul 24, 2019 at 03:27:51PM +0200, Maik Stohn wrote:
KERNEL CRASH when using XHCI devices (affects any architecture
On 24.7.2019 17.34, Maik Stohn wrote:
Am 24.07.2019 um 16:20 schrieb Greg KH :
On Wed, Jul 24, 2019 at 03:27:51PM +0200, Maik Stohn wrote:
KERNEL CRASH when using XHCI devices (affects any architecture, any USB device)
This was already reported as a kernel bug in bugzilla
(https://bugzilla.k
On 22.7.2019 12.44, Kai-Heng Feng wrote:
Hi Mika and Mathias,
I’ve filed a bug [1] which renders docking station unusable.
I am not sure it's a bug in PCI, Thunderbolt or xHCI so raise the issue
to
you both.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=203885
Kai-Heng
I upgraded the sy
On 24.6.2019 21.11, Alan Stern wrote:
On Sun, 23 Jun 2019, Harutyun Khachatryan wrote:
Dear Alan Stern,
I thought that I should wait Mathias's response. I am terribly sorry for
that. I am sending dmesg log and trace content as you asked. I tried the
procedure on kernel 5.1.12-050112-generic si
Hi
On 19.6.2019 22.03, Rob Weber wrote:
Hi Mathias,
I am working on running our custom USB dual-role product through some
compliance testing. It seems that the SoC and host controller are
not responding to the LFPS signaling and timeout that is supposed to
automatically begin the compliance tes
ling
This patch should be added to stable kernels since 4.13 where LPM was
kept enabled during suspend/resume
Cc: # v4.13+
Signed-off-by: Lee, Chiasheng
Signed-off-by: Mathias Nyman
---
drivers/usb/core/hub.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/
On 19.6.2019 9.33, Felipe Balbi wrote:
@Mathias, can you drop the previous fix? I'll try to come up with a
better version of this.
Dropped
-Mathias
le that is driven by Events and Doorbell accesses"
Same appears to be true for slot state.
set a flag to the corresponding slot if a USB3 roothub port link goes
inactive to prevent both queueing new URBs and resetting endpoints.
Reported-by: Rapolu Chiranjeevi
Tested-by: Rapolu Chiranjeevi
Cc
extra whitespace printed out when announcing regular
SuperSpeed hosts.
Cc: # v4.18+
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 78a2a93
Hi Greg
A couple of fixes for usb-linus, one to detect usb 3.2 xhci hosts,
another to resolve a rare host hang at resume issue.
-Mathias
Mathias Nyman (2):
usb: xhci: Don't try to recover an endpoint if port is in error state.
xhci: detect USB 3.2 capable host controllers corr
On 11.6.2019 20.24, Felipe Balbi wrote:
If we happen to have two XHCI controllers with DbC capability, then
there's no hope this will ever work as the global pointer will be
overwritten by the controller that probes last.
Avoid this problem by keeping the tty_driver struct pointer inside
struct
ints where? To send data where? This is very
confusing and does not make any sense to me...
[don't dynamically allocate tiny space for name only -Mathias]
Signed-off-by: Rajaram Regupathy
Signed-off-by: Prabhat Chand Pandey
Signed-off-by: Abhilash K V
Acked-by: Mathias Nyman
---
...
type 'size_t {aka unsigned int}' [-Wformat=]
Use %zu for printing size_t type in order to fix the warnings.
Fixes: 597c56e372da ("xhci: update bounce buffer with correct sg num")
Reported-by: kbuild test robot
Signed-off-by: Fabio Estevam
---
Thanks for writing this follow-up patch
Acked-by: Mathias Nyman
a 5 second timeout can easily take over 15 seconds which will
trigger the watchdog and reboot the system.
[Add info about patch fixing a bug to commit message -Mathias]
Signed-off-by: Andrey Smirnov
Tested-by: Raul E Rangel
Reviewed-by: Raul E Rangel
Cc:
Signed-off-by: Mathias Nyman
LPM. So it is sufficient to avoid
access to udev->bos by moving the instruction into the "enable" clause.
Cc: Stable
Signed-off-by: Carsten Schmid
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/ho
ded in
xhci_debugfs_create_endpoint().
This bug is found by a runtime fuzzing tool named FIZZER written by us.
[subjet line change change, add potential -Mathais]
Signed-off-by: Jia-Ju Bai
Reviewed-by: Greg Kroah-Hartman
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-debugfs.c | 3 +++
ing data to sg list can avoid cache issue.
Fixes: f9c589e142d0 ("xhci: TD-fragment, align the unsplittable case with a
bounce buffer")
Cc: # v4.8+
Signed-off-by: Henry Lin
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-ring.c | 17 +
1 file changed, 13 ins
Lin (1):
xhci: update bounce buffer with correct sg num
Jia-Ju Bai (1):
usb: xhci: Fix a potential null pointer dereference in
xhci_debugfs_create_endpoint()
Mathias Nyman (1):
xhci: Fix immediate data transfer if buffer is already DMA mapped
drivers/usb/host/xhci-debugfs.c | 3
ma as temporary storage.
Fixes: 33e39350ebd2 ("usb: xhci: add Immediate Data Transfer support")
Reported-by: Marek Szyprowski
Tested-by: Marek Szyprowski
CC: Nicolas Saenz Julienne
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-ring.c | 9 ++---
drivers/usb/host/xhc
On 16.5.2019 17.40, Jim Lin wrote:
USB 2.0 specification chapter 11.17.5 says "as part of endpoint halt
processing for full-/low-speed endpoints connected via a TT, the host
software must use the Clear_TT_Buffer request to the TT to ensure
that the buffer is not in the busy state".
In our case,
On 16.5.2019 16.56, Johan Hovold wrote:
On Thu, May 16, 2019 at 03:35:42PM +0200, starost...@gmail.com wrote:
Hello,
when I try to read EEPROM memory from FT232R chip (USB to serial
converter), system crash after a seconds.
You should mention that you're using libusb and the vendor's ftdi
libr
On 10.5.2019 9.28, Marek Szyprowski wrote:
Hi Mathias,
On 2019-05-09 17:10, Mathias Nyman wrote:
On 9.5.2019 14.51, Nicolas Saenz Julienne wrote:
On Thu, 2019-05-09 at 14:40 +0300, Mathias Nyman wrote:
On 9.5.2019 13.32, Marek Szyprowski wrote:
Dear All,
On 2019-04-26 15:23, Mathias Nyman
On 9.5.2019 18.38, Nicolas Saenz Julienne wrote:
Hi Mathias, thanks for spending the time debugging this :)
On Thu, 2019-05-09 at 18:10 +0300, Mathias Nyman wrote:
Got the logs off list, thanks
The "Buffer" data in Control transfer Data stage look suspicious.
First guess would
On 9.5.2019 14.51, Nicolas Saenz Julienne wrote:
On Thu, 2019-05-09 at 14:40 +0300, Mathias Nyman wrote:
On 9.5.2019 13.32, Marek Szyprowski wrote:
Dear All,
On 2019-04-26 15:23, Mathias Nyman wrote:
From: Nicolas Saenz Julienne
Immediate data transfers (IDT) allow the HCD to copy small
On 9.5.2019 13.32, Marek Szyprowski wrote:
Dear All,
On 2019-04-26 15:23, Mathias Nyman wrote:
From: Nicolas Saenz Julienne
Immediate data transfers (IDT) allow the HCD to copy small chunks of
data (up to 8bytes) directly into its output transfer TRBs. This avoids
the somewhat expensive DMA
On 7.5.2019 11.15, Schmid, Carsten wrote:
Hi,
two weeks ago i sent this mail to the linux-usb mailing list but got no answer.
Maybe this has fallen through your filters?
So resending it and adding Mathias in CC.
Thanks, I notice them better when I'm added as To or CC.
Adding patch to queue
W
Hi Greg
A few features for usb next, mostly tracing and debugging features, but
also support for Immediate Data Transfer for small (up to 8 bytes)
data transfers
-Mathias
Mathias Nyman (3):
xhci: add port and bus number to port dynamic debugging
xhci: Add tracing for input control context
The configure endpoint command configures all the endpoints that were
flagged to be added or dropped.
To know the content of each of the added endpoints we need to add tracing
to the .add_endpoint() callback, just after initializing all the context
values.
Signed-off-by: Mathias Nyman
RB will never cross a 64KB boundary.
Signed-off-by: Nicolas Saenz Julienne
Reviewed-by: Felipe Balbi
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-ring.c | 12
drivers/usb/host/xhci.c | 16
drivers/usb/host/xhci.h | 17 +
3 fi
Add tracing for the add and drop bits in the input control context
used in Address device, configure endpoint, evaluate context commands.
The add and drop bits tell xHC which enpoints are added and dropped.
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-trace.h | 25
On 25.4.2019 13.43, Henry Lin wrote:
This change fixes a data corruption issue occurred on USB hard disk for
the case that bounce buffer is used during transferring data.
While updating data between sg list and bounce buffer, current
implementation passes mapped sg number (urb->num_mapped_sgs) t
On 12.4.2019 22.48, Georg Chini wrote:
On 08.04.19 08:46, Georg Chini wrote:
On 02.04.19 16:52, Mathias Nyman wrote:
On 28.3.2019 15.41, Mathias Nyman wrote:
The issue happens when only a single hub and a single device is connected to the
USB subsystem. On my previous board, I had two USB
I've found that the problem is caused by this commit:
commit f8f80be501aa2f10669585c3e328fad079d8cb3a
Author: Mathias Nyman mailto:mathias.ny...@linux.intel.com>>
Date: Thu Sep 20 19:13:37 2018 +0300
xhci: Use soft retry to recover faster from transaction errors
It looks like it o
On 28.3.2019 15.41, Mathias Nyman wrote:
The issue happens when only a single hub and a single device is connected to the
USB subsystem. On my previous board, I had two USB dongles and two sound
devices connected to the same hub and it worked without issues. So I guess it
is not a real
On 27.3.2019 16.00, Sasha Levin wrote:
Hi,
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.0.4, v4.19.31, v4.14.108, v4.9.165,
v4.
The issue happens when only a single hub and a single device is connected to the
USB subsystem. On my previous board, I had two USB dongles and two sound
devices connected to the same hub and it worked without issues. So I guess it
is not a real bandwidth limit. Somehow the hub seems to eat the
Hi
link went to U3. Why would xhci put the link to U3 now? We're still
working fine.
This looks like a pretty crazy set of transitions. I'm unfamiliar with
LPM. Is this sequence of events normal for a transition to U3?
See figure 7-14 on USB 3.1 spec. This shows that from U2 we had LFPS
time
bus suspend if a port connect change
or polling state is detected")
Cc: sta...@vger.kernel.org
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-hub.c | 19 ---
drivers/usb/host/xhci.h | 8
2 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/d
Hi Greg
A few patches for usb-linus fixing mostly suspend and resume related
issues.
Solving one regression that prevented second suspend on some MacBooks,
and a resume issue seen with devices that quickly enter link power
management states after system resume.
-Mathias
Mathias Nyman (3
The xhci debug capability (DbC) feature did its memory cleanup with
spinlock held. dma_free_coherent() warns if called with interrupts
disabled
move the memory cleanup outside the spinlock
Cc: stable
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-dbgcap.c | 5 +++--
1 file changed, 3
1 - 100 of 1968 matches
Mail list logo
