Re: [PATCH 0/4] musb host improvments mostly for omap2430 glue

2019-09-03 Thread Pavel Machek
Hi! On Mon 2019-09-02 09:06:51, Tony Lindgren wrote: > * Pavel Machek [190902 09:44]: > > On Mon 2019-09-02 11:23:44, Pavel Machek wrote: > > Hmm. I guess CONFIG_USB_MUSB_DUAL_ROLE=y might be useful. > > > > And now... if I unplug/replug the usb after the boot, USB hub and > > mouse are recogniz

Re: [PATCH] HID: USB: Fix general protection fault caused by Logitech driver

2019-09-03 Thread Andrey Konovalov
On Sat, Aug 24, 2019 at 2:41 AM wrote: > > On Thu, 22 Aug 2019, Alan Stern wrote: > > > > > > > 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 drive

Re: Adding "UAS" protocol line to usb.ids file?

2019-09-03 Thread Greg KH
On Sat, Aug 17, 2019 at 06:01:45PM -0400, Nathan Stratton Treadway wrote: > I noticed that when I use "lsusb -v" on a UAS-enabled drive enclosure, > the bInterfaceProtocol line for #80/0x50 has a "protocol name" label but the > one for #98/0x62 does not: > > > > # lsusb -v -s2:15 | grep

Re: [PATCH RESEND] xhci: Prevent deadlock when xhci adapter breaks during init

2019-09-03 Thread Greg KH
On Thu, Aug 29, 2019 at 02:12:15PM -0400, Bill Kuzeja wrote: > The system can hit a deadlock if 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_mute

Re: [PATCH] xhci: tegra: Parameterize mailbox register addresses

2019-09-03 Thread Greg KH
On Mon, Sep 02, 2019 at 04:21:27PM +0800, JC Kuo wrote: > Tegra194 XUSB host controller has rearranged mailbox registers. This > commit makes mailbox registers address a part of "soc" data so that > xhci-tegra driver can be used for Tegra194. > > Signed-off-by: JC Kuo > --- > drivers/usb/host/xh

[PATCH -next] usb: cdns3: Remove redundant dev_err call in cdns3_probe()

2019-09-03 Thread Wei Yongjun
There is a error message within devm_ioremap_resource already, so remove the dev_err call to avoid redundant error message. Signed-off-by: Wei Yongjun --- drivers/usb/cdns3/core.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/

Re: Adding "UAS" protocol line to usb.ids file?

2019-09-03 Thread Nathan Stratton Treadway
On Tue, Sep 03, 2019 at 15:39:33 +0200, Greg KH wrote: > On Sat, Aug 17, 2019 at 06:01:45PM -0400, Nathan Stratton Treadway wrote: > > I noticed that when I use "lsusb -v" on a UAS-enabled drive enclosure, > > the bInterfaceProtocol line for #80/0x50 has a "protocol name" label but the > > one for

RE: [PATCH 1/3] net: cdc_ncm: add get/set ethernet address functions

2019-09-03 Thread Charles.Hyde
> > This patch adds support for pushing a MAC address out to USB based > > ethernet controllers driven by cdc_ncm. With this change, ifconfig > > can now set the device's MAC address. For example, the Dell Universal > > Dock > > D6000 is driven by cdc_ncm. The D6000 can now have its MAC address

RE: [PATCH 3/3] net: cdc_ncm: Add ACPI MAC address pass through functionality

2019-09-03 Thread Charles.Hyde
> > This change adds support to cdc_ncm for ACPI MAC address pass through > > functionality that also exists in the Realtek r8152 driver. This is > > in support of Dell's Universal Dock D6000, to give it the same feature > > capability as is currently available in Windows and advertized on > > Del

RE: [PATCH 3/3] net: cdc_ncm: Add ACPI MAC address pass through functionality

2019-09-03 Thread Mario.Limonciello
> -Original Message- > From: Hyde, Charles - Dell Team > Sent: Tuesday, September 3, 2019 12:50 PM > To: Oliver Neukum; l...@kernel.org; r...@rjwysocki.net > Cc: Limonciello, Mario; nic_s...@realtek.com; linux-a...@vger.kernel.org; > linux- > u...@vger.kernel.org > Subject: RE: [PATCH 3/3]

Re: [PATCH] USB: rio500: Fix lockdep violation

2019-09-03 Thread Greg KH
On Thu, Aug 15, 2019 at 10:47:45AM -0400, Alan Stern wrote: > On Thu, 15 Aug 2019, Greg KH wrote: > > > On Thu, Aug 08, 2019 at 02:23:00PM -0400, Alan Stern wrote: > > > On Thu, 8 Aug 2019, Greg KH wrote: > > > > > > > On Thu, Aug 08, 2019 at 01:34:08PM -0400, Alan Stern wrote: > > > > > The syzb

RE: [PATCH] HID: USB: Fix general protection fault caused by Logitech driver

2019-09-03 Thread Roderick.Colenbrander
> From: Andrey Konovalov [andreyk...@google.com] > Sent: Tuesday, September 03, 2019 3:46 AM > To: Colenbrander, Roderick > Cc: Jiri Kosina; Alan Stern; Gustavo A. R. Silva; Hillf Danton; > syzkaller-bugs; linux-in...@vger.kernel.org; USB list > Subject: Re: [PATCH] HID: USB: Fix general protectio

Re: [PATCH] xhci: tegra: Parameterize mailbox register addresses

2019-09-03 Thread JC Kuo
On 9/3/19 9:58 PM, Greg KH wrote: > On Mon, Sep 02, 2019 at 04:21:27PM +0800, JC Kuo wrote: >> Tegra194 XUSB host controller has rearranged mailbox registers. This >> commit makes mailbox registers address a part of "soc" data so that >> xhci-tegra driver can be used for Tegra194. >> >> Signed-off-

Re: [PATCH] xhci: tegra: Parameterize mailbox register addresses

2019-09-03 Thread Greg KH
On Wed, Sep 04, 2019 at 09:43:08AM +0800, JC Kuo wrote: > On 9/3/19 9:58 PM, Greg KH wrote: > > On Mon, Sep 02, 2019 at 04:21:27PM +0800, JC Kuo wrote: > >> Tegra194 XUSB host controller has rearranged mailbox registers. This > >> commit makes mailbox registers address a part of "soc" data so that

Re: [PATCH] xhci: tegra: Parameterize mailbox register addresses

2019-09-03 Thread JC Kuo
On 9/4/19 1:21 PM, Greg KH wrote: > On Wed, Sep 04, 2019 at 09:43:08AM +0800, JC Kuo wrote: >> On 9/3/19 9:58 PM, Greg KH wrote: >>> On Mon, Sep 02, 2019 at 04:21:27PM +0800, JC Kuo wrote: Tegra194 XUSB host controller has rearranged mailbox registers. This commit makes mailbox registers

[PATCH AUTOSEL 5.2 17/23] usb: chipidea: imx: fix EPROBE_DEFER support during driver probe

2019-09-03 Thread Sasha Levin
From: André Draszik If driver probe needs to be deferred, e.g. because ci_hdrc_add_device() isn't ready yet, this driver currently misbehaves badly: a) success is still reported to the driver core (meaning a 2nd probe attempt will never be done), leaving the driver in a dysfunct