On Tue, Oct 01, 2019 at 06:22:36AM -0700, Guenter Roeck wrote:
> On 10/1/19 2:48 AM, Heikki Krogerus wrote:
> > Introducing struct typec_operations which has the same
> > callbacks as struct typec_capability. The old callbacks are
> > kept for now, but after all users have been converted, they
> >
On Tue, Oct 01, 2019 at 06:30:42AM -0700, Guenter Roeck wrote:
> > @@ -4082,10 +4074,9 @@ static int tcpm_pr_set(const struct typec_capability
> > *cap,
> > return ret;
> > }
> > -static int tcpm_vconn_set(const struct typec_capability *cap,
> > - enum typec_role role)
>
On Tue, Oct 01, 2019 at 06:35:59AM -0700, Guenter Roeck wrote:
> On 10/1/19 2:48 AM, Heikki Krogerus wrote:
> > Supplying the operation callbacks as part of a struct
> > typec_operations instead of as part of struct
> > typec_capability during port registration. After this there
> > is not need to
On Thu, Oct 03, 2019 at 03:49:58PM +0200, Johan Hovold wrote:
> Fix NULL-pointer dereferences on open() and write() which can be
> triggered by a malicious USB device.
>
> The current URB allocation helper would fail to initialise the newly
> allocated URB if the device has unexpected endpoint des
The "run_isr" flag is used for preventing the driver from
calling the interrupt service routine in its runtime resume
callback when the driver is expecting completion to a
command, but what that basically does is that it hides the
real problem. The real problem is that the controller is
allowed to
Hi Greg,
Here are two fixes for the ucsi drivers. The first patch removes a
potential deadlock from ucsi_ccg.c, and the second fixes
ucsi_displayport_enter() function so that it does not return error if
the mode has already been entered by the time the function is called.
Let me know if you want
Making sure that ucsi_displayport_enter() function does not
return an error if the displayport alternate mode has
already been entered. It's normal that the firmware (or
controller) has already entered the alternate mode by the
time the operating system is notified about the device.
Fixes: af8622f
Hi,
thank you for the feedback! I hope this time everything is in order.
However, the correct error description is somewhat difficult for me.
Here is the third version:
>From 58634d035508b621025da1d866179b59ed0ae37a Mon Sep 17 00:00:00 2001
From: David Heinzelmann
Date: Fri, 4 Oct 2019 12:28:36
Hi Greg
A set of xhci fixes for usb-linus, for exaple fix a NULL pointer
dereference, remove a false warning, resolve a couple link power management
related bandwidth issues, and correctly detect USB 3.1 capability on hosts
based on early xHCI 1.1 specs.
-Mathias
Bill Kuzeja (1):
xhci: Prevent
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
---
dr
Early xHCI 1.1 spec did not mention USB 3.1 capable hosts should set
sbrn to 0x31, or that the minor revision is a two digit BCD
containing minor and sub-minor numbers.
This was later clarified in xHCI 1.2.
Some USB 3.1 capable hosts therefore have sbrn set to 0x30, or minor
revision set to 0x1 in
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 by hub_tt_work() once it's
scheduled, and by then usb core might have freed and allocated a
new udev for the next enumeration attempt.
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 by continue walking and checking endpoint service interval if
xhci_get_timeout_no_hub_
From: Kai-Heng Feng
After commit f7fac17ca925 ("xhci: Convert xhci_handshake() to use
readl_poll_timeout_atomic()"), ASMedia xHCI may fail to suspend.
Although the algorithms are essentially the same, the old max timeout is
(usec + usec * time of doing readl()), and the new max timeout is just
u
The check printing out the "WARN Wrong bounce buffer write length:"
uses incorrect values when comparing bytes written from scatterlist
to bounce buffer. Actual copied lengths are fine.
The used seg->bounce_len will be set to equal new_buf_len a few lines later
in the code, but is incorrect when d
From: Bill Kuzeja
The system can hit a deadlock if an xhci adapter breaks while initializing.
The deadlock is between two threads: thread 1 is tearing down the
adapter and is stuck in usb_unlocked_disable_lpm waiting to lock the
hcd->handwidth_mutex. Thread 2 is holding this mutex (while still tr
From: Jan Schmidt
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 maximum-exit-latency and
p
On Wed, Oct 02, 2019 at 11:09:13PM +0530, aliasgar.surti...@gmail.com wrote:
> From: Aliasgar Surti
>
> Status variable is initialized and returned without updating it's value.
> Removed status variable and returned value directly.
>
> Signed-off-by: Aliasgar Surti
> ---
> drivers/usb/musb/mus
The following changes since commit 54ecb8f7028c5eb3d740bb82b0f1d90f2df63c5c:
Linux 5.4-rc1 (2019-09-30 10:35:40 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git
tags/usb-serial-5.4-rc2
for you to fetch changes up to 7d7e21f
On Fri, Oct 04, 2019 at 03:52:19PM +0200, Johan Hovold wrote:
> The following changes since commit 54ecb8f7028c5eb3d740bb82b0f1d90f2df63c5c:
>
> Linux 5.4-rc1 (2019-09-30 10:35:40 -0700)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb
On Fri, 4 Oct 2019, David Heinzelmann wrote:
> Hi,
>
> thank you for the feedback! I hope this time everything is in order.
> However, the correct error description is somewhat difficult for me.
You should follow the advice I gave you last time: Explain what the
problem is and how the patch fix
Supplying the operation callbacks as part of a struct
typec_operations instead of as part of struct
typec_capability during port registration.
Signed-off-by: Heikki Krogerus
---
drivers/usb/typec/tcpm/tcpm.c | 45 ---
1 file changed, 20 insertions(+), 25 deletions
Supplying the operation callbacks as part of a struct
typec_operations instead of as part of struct
typec_capability during port registration.
Signed-off-by: Heikki Krogerus
Reviewed-by: Guenter Roeck
---
drivers/usb/typec/ucsi/ucsi.c | 22 +++---
1 file changed, 11 insertions(+
Copying everything from struct typec_capability to struct
typec_port during port registration. This will make sure
that under no circumstances the driver can change the values
in the struct typec_capability that the port uses.
Signed-off-by: Heikki Krogerus
---
drivers/usb/typec/class.c | 15 +++
There are no more users for them.
Signed-off-by: Heikki Krogerus
---
drivers/usb/typec/class.c | 38 ++
include/linux/usb/typec.h | 17 -
2 files changed, 10 insertions(+), 45 deletions(-)
diff --git a/drivers/usb/typec/class.c b/drivers/usb/t
Hi guys,
In this version there should be no more semantic changes.
The original cover letter:
This series moves the callback members from struct typec_capabilities
to a new struct typec_operations. That removes the need for the
drivers to keep a copy of the struct typec_capabilites if they don't
Introducing struct typec_operations which has the same
callbacks as struct typec_capability. The old callbacks are
kept for now, but after all users have been converted, they
will be removed.
Signed-off-by: Heikki Krogerus
---
drivers/usb/typec/class.c | 39 +-
Supplying the operation callbacks as part of a struct
typec_operations instead of as part of struct
typec_capability during port registration. After this there
is not need to keep the capabilities stored anywhere in the
driver.
Signed-off-by: Heikki Krogerus
Reviewed-by: Guenter Roeck
---
drive
Leaving the private driver_data pointer of the port device
to the port drivers.
Signed-off-by: Heikki Krogerus
---
drivers/usb/typec/class.c | 11 +++
include/linux/usb/typec.h | 4
2 files changed, 15 insertions(+)
diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.
On Fri, Oct 04, 2019 at 06:08:13PM +0300, Heikki Krogerus wrote:
> @@ -1103,7 +1113,8 @@ port_type_store(struct device *dev, struct
> device_attribute *attr,
> int ret;
> enum typec_port_type type;
>
> - if (!port->cap->port_type_set || port->cap->type != TYPEC_PORT_DRP) {
> +
On Thu, Oct 3, 2019 at 2:54 PM Alan Stern wrote:
>
> The syzbot fuzzer found a slab-out-of-bounds write bug in the hid-gaff
> driver. The problem is caused by the driver's assumption that the
> device must have an input report. While this will be true for all
> normal HID input devices, a suitab
31 matches
Mail list logo
