Fixes gcc '-Wunused-but-set-variable' warning:
drivers/usb/gadget/udc/lpc32xx_udc.c: In function ‘udc_protocol_cmd_r’:
drivers/usb/gadget/udc/lpc32xx_udc.c:744:6: warning: variable ‘tmp’ set but not
used [-Wunused-but-set-variable]
drivers/usb/gadget/udc/lpc32xx_udc.c: In function ‘udc_handle_dma
On Wed, 21 Aug 2019, Alan Stern wrote:
> The syzbot fuzzer has reported a pair of problems in the
> hidraw_ioctl() function: slab-out-of-bounds read and use-after-free
> read. An example of the first:
>
> BUG: KASAN: slab-out-of-bounds in strlen+0x79/0x90 lib/string.c:525
> Read of size 1 at add
On Tue, 20 Aug 2019, Alan Stern wrote:
> The syzbot fuzzer found a general protection fault in the HID subsystem:
Applied, thanks a lot Alan.
--
Jiri Kosina
SUSE Labs
Am Mittwoch, den 21.08.2019, 23:35 + schrieb
charles.h...@dellteam.com:
>
> >
> > This is a VERY cdc-net-specific function. It is not a "generic" USB
> > function at all. Why does it belong in the USB core? Shouldn't it live
> > in the code that handles the other cdc-net-specific logic?
>
On Wed, Aug 21, 2019 at 04:13:29PM -0700, Christoph Hellwig wrote:
On Wed, Aug 21, 2019 at 12:49:25PM +0100, Matthias Maennich wrote:
Modules using these symbols are required to explicitly import the
namespace. This patch was generated with the following steps and serves
as a reference to use th
On Thu, Aug 08, 2019 at 03:07:22PM +0530, Nagarjuna Kristam wrote:
> Add device-tree binding documentation for the XUSB device mode controller
> present on Tegra210 SoC. This controller supports the USB 3.0
> specification.
>
> Signed-off-by: Nagarjuna Kristam
> Reviewed-by: JC Kuo
> ---
> .../
On Thu, Aug 08, 2019 at 03:07:21PM +0530, Nagarjuna Kristam wrote:
> Tegra XUSB device control driver needs to control vbus override
> during its operations, add API for the support.
>
> Signed-off-by: Nagarjuna Kristam
> ---
> drivers/phy/tegra/xusb-tegra210.c | 57
> ++
On Thu, Aug 08, 2019 at 03:07:18PM +0530, Nagarjuna Kristam wrote:
> This is the sixth version of series "Tegra XUSB gadget driver support"
>
> Patches 1-3 are phy driver changes to add support for device
> mode.
> Patches 4-7 are changes related to XUSB device mode
> controller driver.
> Patch 8
On Thu, Aug 08, 2019 at 03:07:25PM +0530, Nagarjuna Kristam wrote:
> This patch adds UDC driver for tegra XUSB 3.0 device mode controller.
> XUSB device mode controller supports SS, HS and FS modes
>
> Based on work by:
> Mark Kuo
> Hui Fu
> Andrew Bresticker
>
> Signed-off-by: Nagarjuna
The optical sensor of the mouse gets turned off when it's runtime
suspended, so moving the mouse can't wake the mouse up, despite that
USB remote wakeup is successfully set.
Introduce a new quirk to prevent the mouse from getting runtime
suspended.
Signed-off-by: Kai-Heng Feng
---
drivers/hid/h
Hi all,
I started back with the issue and now trying with latest kernel 5.2.7
and still seeing same error "Unhandled fault: imprecise external abort
(0x1406) at xxx"; though this time it happens in different
conditions as mentioned below (with logs):
If I load the xhci-pci.ko driver, which th
On Thu, Aug 15, 2019 at 03:50:38PM +0200, Markus Elfring wrote:
+generate_deps_for_ns() {
+$SPATCH --very-quiet --in-place --sp-file \
+ $srctree/scripts/coccinelle/misc/add_namespace.cocci -D ns=$1 $2
+}
* Where will the variable “srctree” be set for the file “scripts/nsdeps”?
>
> Have a question that: Can I disable PCIe power management completely
> using some kernel CONFIG option OR boot parameter? If yes then how?
>
> Thanks
>
See CONFIG_PM and what it depends on.
BR
Carsten
Am Donnerstag, den 22.08.2019, 17:17 +0800 schrieb Kai-Heng Feng:
> The optical sensor of the mouse gets turned off when it's runtime
> suspended, so moving the mouse can't wake the mouse up, despite that
> USB remote wakeup is successfully set.
>
> Introduce a new quirk to prevent the mouse from
Hi Oliver,
at 17:45, Oliver Neukum wrote:
Am Donnerstag, den 22.08.2019, 17:17 +0800 schrieb Kai-Heng Feng:
The optical sensor of the mouse gets turned off when it's runtime
suspended, so moving the mouse can't wake the mouse up, despite that
USB remote wakeup is successfully set.
Introduce
On 09-08-2019 17:33, Felipe Balbi wrote:
>
> Hi,
>
> Nagarjuna Kristam writes:
>> This patch adds UDC driver for tegra XUSB 3.0 device mode controller.
>> XUSB device mode controller supports SS, HS and FS modes
>>
>> Based on work by:
>> Mark Kuo
>> Hui Fu
>> Andrew Bresticker
>>
>>
On 22-08-2019 14:42, Thierry Reding wrote:
> On Thu, Aug 08, 2019 at 03:07:25PM +0530, Nagarjuna Kristam wrote:
>> This patch adds UDC driver for tegra XUSB 3.0 device mode controller.
>> XUSB device mode controller supports SS, HS and FS modes
>>
>> Based on work by:
>> Mark Kuo
>> Hui Fu
Am Donnerstag, den 22.08.2019, 18:04 +0800 schrieb Kai-Heng Feng:
> Hi Oliver,
>
> at 17:45, Oliver Neukum wrote:
>
> > Am Donnerstag, den 22.08.2019, 17:17 +0800 schrieb Kai-Heng Feng:
> > > The optical sensor of the mouse gets turned off when it's runtime
> > > suspended, so moving the mouse c
Hi Carsten,
Thanks for your reply. I though CONFIG_PM covers CPU only (but now I
am compiling kernel with PM completely).
Occasionally we see crash at boot too without even reaching stage of
loading xhci-pci.ko driver.
Log is below. Is this can be because of again uPD connected on PCIe
bus (thro
>
> Occasionally we see crash at boot too without even reaching stage of
> loading xhci-pci.ko driver.
>
> Log is below. Is this can be because of again uPD connected on PCIe
> bus (through PCIe switch)?
>
> [8.263117] Unhandled fault: imprecise external abort (0x1406) at
> 0xfaf06a5b
Look
> $srctree is defined by kbuild in the toplevel Makefile.
How is this variable passed to the file “scripts/nsdeps”?
>> * Would you like to support a separate build directory for desired
>> adjustments?
>
> No, as the purpose of this script is to directly patch the kernel
> sources where applica
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 Tue, Aug 20, 2019 at 10:00 PM Alan Stern wrote:
>
> The syzbot fuzzer found a general protection fault in the HID subsystem:
>
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault: [#1] SMP KASAN
> CPU: 0 PID:
--
Dear,
With due respect this is not spam or Scam mail, because I have
contacted you before and there was no response from you,I apologise if
the contents of this mail are contrary to your moral ethics, which I
feel may be of great disturbance to your person, but please treat this
with absolute c
On Wed, Aug 7, 2019 at 4:03 PM Andrey Konovalov wrote:
>
> On Fri, Apr 12, 2019 at 1:32 PM Andrey Konovalov
> wrote:
> >
> > On Fri, Apr 12, 2019 at 1:29 AM syzbot
> > wrote:
> > >
> > > syzbot has found a reproducer for the following crash on:
> > >
> > > HEAD commit:9a33b369 usb-fuzzer: m
at 18:38, Oliver Neukum wrote:
Am Donnerstag, den 22.08.2019, 18:04 +0800 schrieb Kai-Heng Feng:
Hi Oliver,
at 17:45, Oliver Neukum wrote:
Am Donnerstag, den 22.08.2019, 17:17 +0800 schrieb Kai-Heng Feng:
The optical sensor of the mouse gets turned off when it's runtime
suspended, so movi
Am Donnerstag, den 22.08.2019, 21:23 +0800 schrieb Kai-Heng Feng:
> at 18:38, Oliver Neukum wrote:
> > Well, sort of. The USB spec merely states how to enter and exit
> > a suspended state and that device state must not be lost.
> > It does not tell you what a suspended device must be able to do.
On 21/08/2019 17:30, Alan Stern wrote:
> On Wed, 21 Aug 2019, Roger Quadros wrote:
>
>> If binding a pending gadget driver fails we should not
>> remove it from the pending driver list, otherwise it
>> will cause a segmentation fault later when the gadget driver is
>> unloaded.
>
>> Signed-off
If a gadget driver is in the pending drivers list, a UDC
becomes available and udc_bind_to_driver() fails, then it
gets deleted from the pending list.
i.e. list_del(&driver->pending) in check_pending_gadget_drivers().
Then if that gadget driver is unregistered,
usb_gadget_unregister_driver() does
From: Colin Ian King
There appears to be a typo in the comparison of pdo_max_voltage[i]
with the previous value, currently it is checking against the
array pdo_min_voltage rather than pdo_max_voltage. I believe this
is a typo. Fix this.
Addresses-Coverity: ("Copy-paste error")
Fixes: 5007e1b5db7
On Thu, Aug 22, 2019 at 02:52:12PM +0100, Colin King wrote:
> From: Colin Ian King
>
> There appears to be a typo in the comparison of pdo_max_voltage[i]
> with the previous value, currently it is checking against the
> array pdo_min_voltage rather than pdo_max_voltage. I believe this
> is a typo
Am Mittwoch, den 07.08.2019, 16:03 +0200 schrieb Andrey Konovalov:
I may offer a preliminary analysis.
Regards
Oliver
> On Fri, Apr 12, 2019 at 1:32 PM Andrey Konovalov
> wrote:
> >
> > On Fri, Apr 12, 2019 at 1:29 AM syzbot
> > wrote:
> > >
> > > syzbot has found a
Hello,
syzbot found the following crash on:
HEAD commit:eea39f24 usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=163ae01260
kernel config: https://syzkaller.appspot.com/x/.
Am Donnerstag, den 22.08.2019, 07:28 -0700 schrieb syzbot:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:eea39f24 usb-fuzzer: main usb gadget fuzzer driver
> git tree: https://github.com/google/kasan.git usb-fuzzer
> console output: https://syzkaller.appspot.com/x/lo
On Thu, 22 Aug 2019, Roger Quadros wrote:
> If a gadget driver is in the pending drivers list, a UDC
> becomes available and udc_bind_to_driver() fails, then it
> gets deleted from the pending list.
> i.e. list_del(&driver->pending) in check_pending_gadget_drivers().
>
> Then if that gadget drive
On Thu, 22 Aug 2019, Kai-Heng Feng wrote:
> at 18:38, Oliver Neukum wrote:
>
> > Am Donnerstag, den 22.08.2019, 18:04 +0800 schrieb Kai-Heng Feng:
> >> Hi Oliver,
> >>
> >> at 17:45, Oliver Neukum wrote:
> >>
> >>> Am Donnerstag, den 22.08.2019, 17:17 +0800 schrieb Kai-Heng Feng:
> The opt
Hello,
syzbot has tested the proposed patch but the reproducer still triggered
crash:
KASAN: use-after-free Read in device_release_driver_internal
==
BUG: KASAN: use-after-free in __mutex_lock_common
kernel/locking/mutex.c:912
On Thu, Aug 22, 2019 at 3:07 PM Andrey Konovalov wrote:
>
> On Wed, Aug 7, 2019 at 4:03 PM Andrey Konovalov wrote:
> >
> > On Fri, Apr 12, 2019 at 1:32 PM Andrey Konovalov
> > wrote:
> > >
> > > On Fri, Apr 12, 2019 at 1:29 AM syzbot
> > > wrote:
> > > >
> > > > syzbot has found a reproducer f
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
Hi,
On 22-08-19 17:23, Mathias Nyman wrote:
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-cap
On Thu, Aug 22, 2019 at 02:52:12PM +0100, Colin King wrote:
> From: Colin Ian King
>
> There appears to be a typo in the comparison of pdo_max_voltage[i]
> with the previous value, currently it is checking against the
> array pdo_min_voltage rather than pdo_max_voltage. I believe this
> is a typo
> On 22-08-19 17:23, Mathias Nyman wrote:
> > 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 o
I'm having issues on a Firefly rk3288 board when trying to use USB
gadget ethernet on macOS. The dr_mode is set to "otg" and it works fine
with my Linux desktop.
If I set the dr_mode to "peripheral" macOS will work, but still takes
around 10 seconds to enumerate the device which makes me think it'
On Fri, Aug 09, 2019 at 12:54:34AM +0900, Suwan Kim wrote:
> vhci doesn’t do DMA for remote device. Actually, the real DMA
> operation is done by network card driver. vhci just passes virtual
> address of the buffer to the network stack, so vhci doesn’t use and
> need dma address of the buffer of t
On Fri, Aug 16, 2019 at 08:24:29AM +0200, Christoph Hellwig wrote:
> Hi all,
>
> this is another attempt to make sure the dma_mask pointer is always
> initialized for platform devices. Not doing so lead to lots of
> boilerplate code, and makes platform devices different from all our
> major busse
On Thu, 22 Aug 2019, Andrey Konovalov wrote:
> Hi Alan,
>
> I've ran the fuzzer with your patches applied overnight and noticed
> another fallout of similar bugs. I think they are caused by a similar
> issue in the sony HID driver. There's no hid_hw_stop() call in the "if
> (!(hdev->claimed & HID
> >
> > >
> > > This is a VERY cdc-net-specific function. It is not a "generic" USB
> > > function at all. Why does it belong in the USB core? Shouldn't it
> > > live in the code that handles the other cdc-net-specific logic?
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> >
> > Thank you for th
On Thu, 22 Aug 2019, Benjamin Herrenschmidt wrote:
> On Thu, 2019-08-22 at 14:58 +1000, Benjamin Herrenschmidt wrote:
> >
> > Ah lovely ... the 338x fails in EP autoconf with f_tcm, digging...
> >
> > While digging I found this gem:
> >
> > /* USB3380: use same address for usb and hardware
On Thu, Aug 22, 2019 at 7:11 PM Alan Stern wrote:
>
> On Thu, 22 Aug 2019, Andrey Konovalov wrote:
>
> > Hi Alan,
> >
> > I've ran the fuzzer with your patches applied overnight and noticed
> > another fallout of similar bugs. I think they are caused by a similar
> > issue in the sony HID driver.
On Thu, Aug 22, 2019 at 11:18:44AM +0200, Fawad Lateef wrote:
> In all crash cases (when loading/unloading the driver); system stays
> response, so I can look into any possible device status using PCIe
> registers of PEX8605 switch or iMX6 PCIe root hub. Please suggest if
> something I can check t
Hi,
On 22-08-19 17:48, Schmid, Carsten wrote:
On 22-08-19 17:23, Mathias Nyman wrote:
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
On Thu, 22 Aug 2019, Andrey Konovalov wrote:
> On Thu, Aug 22, 2019 at 7:11 PM Alan Stern wrote:
> >
> > On Thu, 22 Aug 2019, Andrey Konovalov wrote:
> >
> > > Hi Alan,
> > >
> > > I've ran the fuzzer with your patches applied overnight and noticed
> > > another fallout of similar bugs. I think t
There are bugs on vhci with usb 3.0 storage device. In USB, each SG
list entry buffer should be divisible by the bulk max packet size.
But with native SG support, this problem doesn't matter because the
SG buffer is treated as contiguous buffer. But without native SG
support, USB storage driver bre
On Thu, Aug 22, 2019 at 09:40:11AM -0700, Greg KH wrote:
> On Fri, Aug 09, 2019 at 12:54:34AM +0900, Suwan Kim wrote:
> > vhci doesn’t do DMA for remote device. Actually, the real DMA
> > operation is done by network card driver. vhci just passes virtual
> > address of the buffer to the network sta
From: Markus Elfring
Date: Wed, 21 Aug 2019 22:24:16 +0200
> From: Markus Elfring
> Date: Wed, 21 Aug 2019 22:16:02 +0200
>
> The dev_kfree_skb() function performs also input parameter validation.
> Thus the test around the shown calls is not needed.
>
> This issue was detected by using the Co
On Thu, 2019-08-22 at 13:30 -0400, Alan Stern wrote:
> On Thu, 22 Aug 2019, Benjamin Herrenschmidt wrote:
>
> > On Thu, 2019-08-22 at 14:58 +1000, Benjamin Herrenschmidt wrote:
> > >
> > > Ah lovely ... the 338x fails in EP autoconf with f_tcm, digging...
> > >
> > > While digging I found this g
On 19-08-22 14:08:26, Mathias Nyman wrote:
> 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
HI Peter, Mathias,
Sorry for the late review.
On Friday, August 23, 2019 09:02, Peter Chen wrote:
>
> On 19-08-22 14:08:26, Mathias Nyman wrote:
> > 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 split into multiple structures of the "ll" register bank is
impractical. It makes it hard to add ll_lfps_timers_2 which is
at offset 0x794, which is outside of the existing "lfps" structure
and would require us to add yet another one.
Instead, move all the "ll" registers into a single usb338x_
The split into multiple structures of the "ll" register bank is
impractical. It makes it hard to add ll_lfps_timers_2 which is
at offset 0x794, which is outside of the existing "lfps" structure
and would require us to add yet another one.
Instead, move all the "ll" registers into a single usb338x_
The errata description is:
Workaround for Default Duration of LFPS Handshake Signaling for
Device-Initiated U1 Exit is too short.
The default duration of the LFPS handshake generated by USB3380 for a
device-initiated U1-exit may not be
long enough for certain SuperSpeed downstream ports (SuperSp
On 19-08-23 01:59:24, Ran Wang wrote:
> HI Peter, Mathias,
>
> Sorry for the late review.
>
> On Friday, August 23, 2019 09:02, Peter Chen wrote:
> >
> > On 19-08-22 14:08:26, Mathias Nyman wrote:
> > > On 21.8.2019 6.18, Peter Chen wrote:
> > > > According to xHCI 1.1 CH4.19.4 Port Power:
> > >
Hi Peter,
On Friday, August 23, 2019 11:34, Peter Chen wrote:
>
> On 19-08-23 01:59:24, Ran Wang wrote:
> > HI Peter, Mathias,
> >
> > Sorry for the late review.
> >
> > On Friday, August 23, 2019 09:02, Peter Chen wrote:
> > >
> > > On 19-08-22 14:08:26, Mathias Nyman wrote:
> > > > On 21.8.2019
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
---
v2 no changes
---
drivers/usb/host/xhci-mtk.c | 13 +
drivers/usb/host/xhci-mtk.h | 1 +
2 files changed, 14 insertions(+)
diff --git
Add a new optional clock xhci_ck
Signed-off-by: Chunfeng Yun
---
v2 changes:
1. add the new clock at the end, suggested by Rob
---
Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindi
65 matches
Mail list logo
