On Tue, Aug 14, 2018 at 12:07:15PM +0300, Dan Carpenter wrote:
> A malicious USB device could set port_number to -3 and we would
> underflow the edge_serial->serial->port[] array.
Good catch!
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/usb/
Similarly to a recently reported bug in io_ti, a malicious USB device
could set port_number to -3 and we would underflow the port array in the
interrupt completion handler.
As these devices only have one or two ports, fix this by making sure we
only consider the seventh bit when determining the po
As reported by Dan Carpenter, a malicious USB device could set
port_number to -3 and we would underflow the port array in the interrupt
completion handler.
As these devices only have one or two ports, fix this by making sure we
only consider the seventh bit when determining the port number (and
ig
On 20/08/2018 04:15, Yoshihiro Shimoda wrote:
Hi John, Felipe,
From: John Garry, Sent: Wednesday, August 15, 2018 9:55 PM
On 10/08/2018 07:24, Felipe Balbi wrote:
Hi Yoshihiro,
I see Arnd is fixing it here:
https://lore.kernel.org/patchwork/patch/974025/
I am not on that thread, so will
The ChipIdea IRQ is disabled before scheduling the otg work and
re-enabled on otg work completion. However if the job is already
scheduled we have to undo the effect of disable_irq int order to
balance the IRQ disable-depth value.
Fixes: be6b0c1bd0be ("usb: chipidea: using one inline function to c
At OTG work running time, it's possible that several events need to be
addressed (e.g. ID and VBUS events). The current implementation handles
only one event at a time which leads to ignoring the other one. Fix it.
Signed-off-by: Loic Poulain
---
drivers/usb/chipidea/otg.c | 9 ++---
1 file
Some hardware implementations require to configure pins differently
according to the USB role (host/device), this can be an update of the
pins routing or a simple GPIO value change.
This patch introduces new optional "host" and "device" pinctrls.
If these pinctrls are defined by the device, they a
Phy power on/off cycle can happen several times during device life.
We then need to balance the extcon notifier registration accordingly.
Fixes: f0b5c2c96370 ("phy: qcom-usb-hs: Replace the extcon API")
Signed-off-by: Loic Poulain
---
drivers/phy/qualcomm/phy-qcom-usb-hs.c | 6 ++
1 file cha
Add compatibility for extcon-usb-gpio which can handle more
than one cable per instance, allowing coherency of USB cable
states (USB/USB-HOST). These states can be generated from ID
or/and VBUS pins.
In case only one extcon device is associated to the USB device,
and this device supports USB and U
The Dragonboard-410c is able to act either as USB Host or Device.
The role can be determined at runtime via the USB_HS_ID pin which is
derived from the micro-usb port VBUS pin.
In Host role, SoC USB D+/D- are routed to the onboard USB 2.0 HUB.
In Device role, SoC USB D+/D- are routed to the USB 2.
On Tue, Aug 21, 2018 at 8:56 AM Loic Poulain wrote:
>
> The Dragonboard-410c is able to act either as USB Host or Device.
> The role can be determined at runtime via the USB_HS_ID pin which is
> derived from the micro-usb port VBUS pin.
>
> In Host role, SoC USB D+/D- are routed to the onboard USB
TI AM335x CPPI41 module uses a single register bit for CPPI interrupts in
both musb controllers. So disabling the CPPI irq in one musb driver breaks
the other musb module.
Since musb is already disabled before tearing down dma controller in
musb_remove(), it is safe to not disable CPPI irq in
musb
Hi,
> From: John Garry, Sent: Tuesday, August 21, 2018 7:30 PM
>
> On 20/08/2018 04:15, Yoshihiro Shimoda wrote:
> > Hi John, Felipe,
> >
> >> From: John Garry, Sent: Wednesday, August 15, 2018 9:55 PM
> >>
> >> On 10/08/2018 07:24, Felipe Balbi wrote:
> >>>
> >>> Hi Yoshihiro,
> >>>
> >>
> >> I
13 matches
Mail list logo
