RE: UAC2 gadget not recognized on Windows 10

[Felipe Balbi]

Hi,

Robert Bielik  writes:
>> Indeed, that's also mandated by USB spec. Seems like we need to patch
>> f_uac2.c. Can you check if setting the IN endpoint as implicit feedback
>> data is enough?
>
> Just tried your proposed patches on 4.15.1 (with an RPi Zero) and with
> g_audio, unfortunately there is no change. Device is still not
> recognized, and having the same error code.
>
> So, a real feedback IN endpoint is needed ☹

I'll see if I can reproduce this here. Perhaps someone in the office has
Windows 10, who knows.

-- 
balbi


signature.asc
Description: PGP signature

Goede dag

[Santander Credit Finance®]

Goede dag,

Mijn naam is Ana Botin van Santander Credit Finance. Heb je een lening nodig
Of geld om te investeren? dan is hier de juiste plaats om gefinancierd te 
worden. Onze interesse
tarief is 3%.

Vul de onderstaande gegevens in en stuur deze naar (i...@santandarco.uk).
Voornaam:
Achternaam:
Seks:
Gewenst leenbedrag:
Tijdsduur:

Wij kijken op om zaken met u te doen.
Hoogachtend
Ana Botin
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

USB regression for Android phone and sound card in 4.14

[Nazar Mokrynskyi]

Starting from 4.14 and continuing in 4.15 I observe 2 bugs that I think are 
related and didn't exist in 4.13.

The first would be more difficult to reproduce: USB sound card Creative SB Omni 
Surround 5.1 after system boot only shows 2.0 stereo output option, while it 
also supports 5.1 and PulseAudio configured accordingly. If unplug and plug it 
back in, 5.1 mode appears and I can select between 2.0 and 5.1. You can boot 
with stock Ubuntu 17.10 and 18.04 as of right now and the first one will work 
properly and second one will have mentioned bug.

Second bug is easier to reproduce: when connecting Nexus 6P via USB cable, it 
appears in file manager devices list (Nemo, Nautilus, etc.), but when it is 
unplugged it doesn't disappear when running kernels 4.14 and 4.15. I have 7 
Nexus 6P entries already, unplugging and plugging back looks like this:

[200038.821988] usb 3-1: new high-speed USB device number 4 using xhci_hcd
[200039.043611] usb 3-1: New USB device found, idVendor=18d1, idProduct=4ee1
[200039.043612] usb 3-1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[200039.043614] usb 3-1: Product: Nexus 6P
[200039.043614] usb 3-1: Manufacturer: Huawei
[200039.043615] usb 3-1: SerialNumber: 8XV7N1612893
[202243.949672] usb 3-1: USB disconnect, device number 4
[205549.671959] usb 3-1: new high-speed USB device number 5 using xhci_hcd
[205549.893327] usb 3-1: New USB device found, idVendor=18d1, idProduct=4ee1
[205549.893328] usb 3-1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[205549.893329] usb 3-1: Product: Nexus 6P
[205549.893329] usb 3-1: Manufacturer: Huawei
[205549.893330] usb 3-1: SerialNumber: 8XV7N1612893
[205550.602646] usb 3-1: USB disconnect, device number 5
[205553.456007] usb 3-1: new high-speed USB device number 6 using xhci_hcd
[205553.680392] usb 3-1: New USB device found, idVendor=18d1, idProduct=4ee1
[205553.680394] usb 3-1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[205553.680394] usb 3-1: Product: Nexus 6P
[205553.680395] usb 3-1: Manufacturer: Huawei
[205553.680396] usb 3-1: SerialNumber: 8XV7N1612893
[206021.635511] usb 3-1: USB disconnect, device number 6
[206024.169853] usb 3-1: new high-speed USB device number 7 using xhci_hcd
[206024.392921] usb 3-1: New USB device found, idVendor=18d1, idProduct=4ee1
[206024.392923] usb 3-1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[206024.392924] usb 3-1: Product: Nexus 6P
[206024.392925] usb 3-1: Manufacturer: Huawei
[206024.392925] usb 3-1: SerialNumber: 8XV7N1612893
[206034.058208] usb 3-1: USB disconnect, device number 7
[206036.914005] usb 3-1: new high-speed USB device number 8 using xhci_hcd
[206037.136891] usb 3-1: New USB device found, idVendor=18d1, idProduct=4ee1
[206037.136893] usb 3-1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[206037.136894] usb 3-1: Product: Nexus 6P
[206037.136895] usb 3-1: Manufacturer: Huawei
[206037.136895] usb 3-1: SerialNumber: 8XV7N1612893
[206080.923547] usb 3-1: USB disconnect, device number 8
[206083.526585] usb 3-1: new high-speed USB device number 9 using xhci_hcd
[206083.752601] usb 3-1: New USB device found, idVendor=18d1, idProduct=4ee1
[206083.752602] usb 3-1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[206083.752603] usb 3-1: Product: Nexus 6P
[206083.752604] usb 3-1: Manufacturer: Huawei
[206083.752605] usb 3-1: SerialNumber: 8XV7N1612893

These 2 issues appeared at the same time, so I think they are related.
Let me know if you can't reproduce them and need any additional information and 
CC me on answers as I'm not subscribed to this mailing list.

-- 
Sincerely, Nazar Mokrynskyi
github.com/nazar-pc

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: dwc2: Print error if unable to set DMA coherent mask

[Stefan Wahren]

We better print an error in case probing of dwc2 fails on
setting the DMA coherent mask.

Signed-off-by: Stefan Wahren 
---
 drivers/usb/dwc2/platform.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 4703478..4ddbdbd 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -382,8 +382,10 @@ static int dwc2_driver_probe(struct platform_device *dev)
if (!dev->dev.dma_mask)
dev->dev.dma_mask = >dev.coherent_dma_mask;
retval = dma_set_coherent_mask(>dev, DMA_BIT_MASK(32));
-   if (retval)
+   if (retval) {
+   dev_err(>dev, "can't set coherent DMA mask: %d\n", retval);
return retval;
+   }
 
res = platform_get_resource(dev, IORESOURCE_MEM, 0);
hsotg->regs = devm_ioremap_resource(>dev, res);
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v1 1/1] usb: cdc_acm: prevent race at write to acm while system resumes

[sathyanarayan . kuppuswamy]

From: Dominik Bozek 

ACM driver may accept data to transmit while system is not fully
resumed. In this case ACM driver buffers data and prepare URBs
on usb anchor list.
There is a little chance that two tasks put a char and initiate
acm_tty_flush_chars(). In such a case, driver will put one URB
twice on usb anchor list.
This patch also reset length of data before resue of a buffer.
This not only prevent sending rubbish, but also lower risc of race.

Without this patch we hit following kernel panic in one of our
stabilty/stress tests.

[   46.884442] *list_add double add*: new=9b2ab7289330, 
prev=9b2ab7289330, next=9b2ab81e28e0.
[   46.884476] Modules linked in: hci_uart btbcm bluetooth rfkill_gpio 
igb_avb(O) cfg80211 snd_soc_sst_bxt_tdf8532 snd_soc_skl snd_soc_skl_ipc 
snd_soc_sst_ipc snd_soc_sst_dsp snd_soc_sst_acpi snd_soc_sst_match 
snd_hda_ext_core snd_hda_core trusty_timer trusty_wall trusty_log trusty_virtio 
trusty_ipc trusty_mem trusty_irq trusty virtio_ring virtio intel_ipu4_mmu_bxtB0 
lib2600_mod_bxtB0 intel_ipu4_isys_mod_bxtB0 lib2600psys_mod_bxtB0 
intel_ipu4_psys_mod_bxtB0 intel_ipu4_mod_bxtB0 intel_ipu4_wrapper_bxtB0 
intel_ipu4_acpi videobuf2_dma_contig as3638 dw9714 lm3643 crlmodule smiapp 
smiapp_pll
[   46.884480] CPU: 1 PID: 33 Comm: kworker/u8:1 Tainted: G U  W  O
4.9.56-quilt-2e5dc0ac-g618ed69ced6e-dirty #4
[   46.884489] Workqueue: events_unbound flush_to_ldisc
[   46.884494]  b98ac012bb08 ad3e82e5 b98ac012bb58 

[   46.884497]  b98ac012bb48 ad0a23d1 0024ad6374dd 
9b2ab7289330
[   46.884500]  9b2ab81e28e0 9b2ab7289330 0002 

[   46.884501] Call Trace:
[   46.884507]  [] dump_stack+0x67/0x92
[   46.884511]  [] __warn+0xd1/0xf0
[   46.884513]  [] warn_slowpath_fmt+0x5f/0x80
[   46.884516]  [] __list_add+0xb3/0xc0
[   46.884521]  [] *usb_anchor_urb*+0x4c/0xa0
[   46.884524]  [] *acm_tty_flush_chars*+0x8f/0xb0
[   46.884527]  [] *acm_tty_put_char*+0x41/0x100
[   46.884530]  [] tty_put_char+0x24/0x40
[   46.884533]  [] do_output_char+0xa5/0x200
[   46.884535]  [] __process_echoes+0x148/0x290
[   46.884538]  [] n_tty_receive_buf_common+0x57c/0xb00
[   46.884541]  [] n_tty_receive_buf2+0x14/0x20
[   46.884543]  [] tty_ldisc_receive_buf+0x22/0x50
[   46.884545]  [] flush_to_ldisc+0xc5/0xe0
[   46.884549]  [] process_one_work+0x148/0x440
[   46.884551]  [] worker_thread+0x69/0x4a0
[   46.884554]  [] ? max_active_store+0x80/0x80
[   46.884556]  [] kthread+0x110/0x130
[   46.884559]  [] ? kthread_park+0x60/0x60
[   46.884563]  [] ret_from_fork+0x27/0x40
[   46.884566] ---[ end trace 3bd599058b8a9eb3 ]---

Signed-off-by: Sathyanarayanan Kuppuswamy 
---
 drivers/usb/class/cdc-acm.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 8e0636c963a7..f2b351100b9f 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -174,6 +174,7 @@ static int acm_wb_alloc(struct acm *acm)
wb = >wb[wbn];
if (!wb->use) {
wb->use = 1;
+   wb->len = 0;
return wbn;
}
wbn = (wbn + 1) % ACM_NW;
@@ -805,16 +806,18 @@ static int acm_tty_write(struct tty_struct *tty,
 static void acm_tty_flush_chars(struct tty_struct *tty)
 {
struct acm *acm = tty->driver_data;
-   struct acm_wb *cur = acm->putbuffer;
+   struct acm_wb *cur;
int err;
unsigned long flags;
 
+   spin_lock_irqsave(>write_lock, flags);
+
+   cur = acm->putbuffer;
if (!cur) /* nothing to do */
-   return;
+   goto out;
 
acm->putbuffer = NULL;
err = usb_autopm_get_interface_async(acm->control);
-   spin_lock_irqsave(>write_lock, flags);
if (err < 0) {
cur->use = 0;
acm->putbuffer = cur;
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH usb-next v9 2/8] usb: add a flag to skip PHY initialization to struct usb_hcd

[Alan Stern]

On Mon, 12 Feb 2018, Martin Blumenstingl wrote:

> Hi Alan,
> 
> On Mon, Feb 12, 2018 at 4:15 PM, Alan Stern  wrote:
> > On Sun, 11 Feb 2018, Martin Blumenstingl wrote:
> >
> >> The USB HCD core driver parses the device-tree node for "phys" and
> >> "usb-phys" properties. It also manages the power state of these PHYs
> >> automatically.
> >> However, drivers may opt-out of this behavior by setting "phy" or
> >> "usb_phy" in struct usb_hcd to a non-null value. An example where this
> >> is required is the "Qualcomm USB2 controller", implemented by the
> >> chipidea driver. The hardware requires that the PHY is only powered on
> >> after the "reset completed" event from the controller is received.
> >>
> >> A follow-up patch will allow the USB HCD core driver to manage more than
> >> one PHY. Add a new "bool skip_phy_initialization" field to struct
> >> usb_hcd so drivers can opt-out of any PHY management provided by the USB
> >> HCD core driver. The new field will be used in that patch as well.
> >>
> >> This also updates the existing drivers so they use the new flag if they
> >> want to opt out of the PHY management provided by the USB HCD core
> >> driver. This means that for these drivers the new "multiple PHY"
> >> handling (which will be added in a follow-up patch) will be disabled as
> >> well.
> >>
> >> Signed-off-by: Martin Blumenstingl 
> >> ---
> >
> >> --- a/include/linux/usb/hcd.h
> >> +++ b/include/linux/usb/hcd.h
> >> @@ -98,6 +98,12 @@ struct usb_hcd {
> >>*/
> >>   const struct hc_driver  *driver;/* hw-specific hooks */
> >>
> >> + /*
> >> +  * do not manage the PHY state in the HCD core, instead let the 
> >> driver
> >> +  * handle this (for example if the PHY can only be turned on after a
> >> +  * specific event)
> >> +  */
> >> + bool skip_phy_initialization;
> >
> > Instead of declaring this as a bool at some random location in the
> > structure, it would be better to make this a bitflag along with the
> > other ones that get set at registration.  For example, it could come
> > right after the remove_phy flag.
> I'll move it to the other bitflags as suggested - thanks for pointing this 
> out!
> 
> just to save you from reviewing this over and over again:
> - I'll move the skip_phy_initialization field below remove_phy
> - it's new definition will be "unsigned skip_phy_initialization:1"
> - do you see any issues with the rest of the patch (the "concept" of
> using a flag to skip all kinds of PHY initialization)?

It's okay as far as I can tell.  But I haven't done any PHY
programming, so I'm not a good judge.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH usb-next v9 2/8] usb: add a flag to skip PHY initialization to struct usb_hcd

[Martin Blumenstingl]

Hi Alan,

On Mon, Feb 12, 2018 at 4:15 PM, Alan Stern  wrote:
> On Sun, 11 Feb 2018, Martin Blumenstingl wrote:
>
>> The USB HCD core driver parses the device-tree node for "phys" and
>> "usb-phys" properties. It also manages the power state of these PHYs
>> automatically.
>> However, drivers may opt-out of this behavior by setting "phy" or
>> "usb_phy" in struct usb_hcd to a non-null value. An example where this
>> is required is the "Qualcomm USB2 controller", implemented by the
>> chipidea driver. The hardware requires that the PHY is only powered on
>> after the "reset completed" event from the controller is received.
>>
>> A follow-up patch will allow the USB HCD core driver to manage more than
>> one PHY. Add a new "bool skip_phy_initialization" field to struct
>> usb_hcd so drivers can opt-out of any PHY management provided by the USB
>> HCD core driver. The new field will be used in that patch as well.
>>
>> This also updates the existing drivers so they use the new flag if they
>> want to opt out of the PHY management provided by the USB HCD core
>> driver. This means that for these drivers the new "multiple PHY"
>> handling (which will be added in a follow-up patch) will be disabled as
>> well.
>>
>> Signed-off-by: Martin Blumenstingl 
>> ---
>
>> --- a/include/linux/usb/hcd.h
>> +++ b/include/linux/usb/hcd.h
>> @@ -98,6 +98,12 @@ struct usb_hcd {
>>*/
>>   const struct hc_driver  *driver;/* hw-specific hooks */
>>
>> + /*
>> +  * do not manage the PHY state in the HCD core, instead let the driver
>> +  * handle this (for example if the PHY can only be turned on after a
>> +  * specific event)
>> +  */
>> + bool skip_phy_initialization;
>
> Instead of declaring this as a bool at some random location in the
> structure, it would be better to make this a bitflag along with the
> other ones that get set at registration.  For example, it could come
> right after the remove_phy flag.
I'll move it to the other bitflags as suggested - thanks for pointing this out!

just to save you from reviewing this over and over again:
- I'll move the skip_phy_initialization field below remove_phy
- it's new definition will be "unsigned skip_phy_initialization:1"
- do you see any issues with the rest of the patch (the "concept" of
using a flag to skip all kinds of PHY initialization)?


Regards
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Bug 198731 "USB devices not seen with newest kernel"

[The Real Bev]

On 02/11/2018 09:50 PM, Greg KH wrote:

On Fri, Feb 09, 2018 at 12:25:44PM -0800, The Real Bev wrote:

On 02/09/2018 05:13 AM, Greg KH wrote:
> On Thu, Feb 08, 2018 at 01:00:02PM -0800, The Real Bev wrote:
> > I think I have found a bug in the linux kernel 4.9.79. The problem
> > is in the performance of the driver for the Renesas Technology Corp.
> > uPD720201
> > PCI-e USB host controller.
> >
> > My system has an Intel I7 960 cpu. The USB controller works when accessed
> > using the driver in the 4.8.10 kernel. Within the last few days
> > I compiled the 4.9.79 kernel using the same .config file as for
> > the 4.8.10 kernel except that I accepted the default for all kernel
> > options not already contained in the old config file. In other words,
> > starting with the .config file for the 4.8.10 kernel I did
> > make oldconfig
> > and defaulted on every question.
> >
> > Under the new kernel the system sees the host control via
> > lspci:
> > 09:00.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0 Host
> > Controller (rev 03)
> >
> > However nothing comes up in dmesg when I plug a device into the controller.
>
> Odds are you might have missed a build option for your system.  Can you
> go back to your 4.8.y .config file and look at the new options to be
> sure that there was not one for the Renesas hardware you have?
>
> Also, 4.9 is really old, it's recommended you use something more modern,
> like 4.14 or even better yet, 4.15.

4.9 was the latest kernel when I updated :-(  They're coming thick and fast,
aren't they?


4.9 was released in December of 2016, a long time ago in kernel
development.


I built the 4.15.2 kernel using the .config derived from the 4.8.10 kernel.
I just don't have the energy to respond to every single difference in the
config file
(never had to do that in the past), and just accept the defaults.  The
following lines
appeared while booting the 4.15.2 kernel:


Again, odds are you are missing something you really need here.  Odds
are you are missing something like CONFIG_USB_XHCI_PCI or some other
XHCI build option.

I recommend trying a distro kernel on this machine, and if that works,
running 'make localmodconfig' with that distro kernel running to get a
working configuration file.


Distro kernels are too old.

The XHCI options are already modules.  Here's the appropriate part of 
the config file.  Can you see a problem?


# USB Host Controller Drivers
#
CONFIG_USB_C67X00_HCD=m
CONFIG_USB_XHCI_HCD=m
CONFIG_USB_XHCI_PCI=m
CONFIG_USB_XHCI_PLATFORM=m
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_USB_EHCI_PCI=m
CONFIG_USB_EHCI_HCD_PLATFORM=m
CONFIG_USB_OXU210HP_HCD=m
CONFIG_USB_ISP116X_HCD=m
CONFIG_USB_ISP1362_HCD=m
CONFIG_USB_FOTG210_HCD=m
CONFIG_USB_OHCI_HCD=m
CONFIG_USB_OHCI_HCD_PCI=m
CONFIG_USB_OHCI_HCD_SSB=y
CONFIG_USB_OHCI_HCD_PLATFORM=m
CONFIG_USB_UHCI_HCD=m
CONFIG_USB_U132_HCD=m
CONFIG_USB_SL811_HCD=m
# CONFIG_USB_SL811_HCD_ISO is not set
CONFIG_USB_SL811_CS=m
CONFIG_USB_R8A66597_HCD=m
CONFIG_USB_WHCI_HCD=m
CONFIG_USB_HWA_HCD=m
# CONFIG_USB_HCD_BCMA is not set
CONFIG_USB_HCD_SSB=m
# CONFIG_USB_HCD_TEST_MODE is not set

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: UAC2 gadget not recognized on Windows 10

[Robert Bielik]

Hi Felipe,

> Indeed, that's also mandated by USB spec. Seems like we need to patch
> f_uac2.c. Can you check if setting the IN endpoint as implicit feedback
> data is enough?

Just tried your proposed patches on 4.15.1 (with an RPi Zero) and with g_audio, 
unfortunately there is no change. Device is still not recognized, and having 
the same error code.

So, a real feedback IN endpoint is needed ☹

Regards
/Robert

Re: [PATCH usb-next v9 2/8] usb: add a flag to skip PHY initialization to struct usb_hcd

[Alan Stern]

On Sun, 11 Feb 2018, Martin Blumenstingl wrote:

> The USB HCD core driver parses the device-tree node for "phys" and
> "usb-phys" properties. It also manages the power state of these PHYs
> automatically.
> However, drivers may opt-out of this behavior by setting "phy" or
> "usb_phy" in struct usb_hcd to a non-null value. An example where this
> is required is the "Qualcomm USB2 controller", implemented by the
> chipidea driver. The hardware requires that the PHY is only powered on
> after the "reset completed" event from the controller is received.
> 
> A follow-up patch will allow the USB HCD core driver to manage more than
> one PHY. Add a new "bool skip_phy_initialization" field to struct
> usb_hcd so drivers can opt-out of any PHY management provided by the USB
> HCD core driver. The new field will be used in that patch as well.
> 
> This also updates the existing drivers so they use the new flag if they
> want to opt out of the PHY management provided by the USB HCD core
> driver. This means that for these drivers the new "multiple PHY"
> handling (which will be added in a follow-up patch) will be disabled as
> well.
> 
> Signed-off-by: Martin Blumenstingl 
> ---

> --- a/include/linux/usb/hcd.h
> +++ b/include/linux/usb/hcd.h
> @@ -98,6 +98,12 @@ struct usb_hcd {
>*/
>   const struct hc_driver  *driver;/* hw-specific hooks */
>  
> + /*
> +  * do not manage the PHY state in the HCD core, instead let the driver
> +  * handle this (for example if the PHY can only be turned on after a
> +  * specific event)
> +  */
> + bool skip_phy_initialization;

Instead of declaring this as a bool at some random location in the
structure, it would be better to make this a bitflag along with the
other ones that get set at registration.  For example, it could come
right after the remove_phy flag.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Continuous USB resets on NXP i.MX 6ULL device

[Stefan Agner]

Hi Peter,

Our Colibri iMX6ULL is using NXP i.MX6 ULL in USB host mode. With
4.15-rc3 and 4.16-rc1 I noticed that when a USB Hub is connected to the
USB OTG controller in host mode, Linux continuously resets the USB
device every two seconds:

[0.927567] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI)
Driver
[0.934170] ehci-mxc: Freescale On-Chip EHCI Host driver
[0.992418] ci_hdrc ci_hdrc.0: EHCI Host Controller
[0.997550] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus
number 1
[1.026730] ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00
...
[1.608880] hub 1-1:1.0: USB hub found
[1.616915] hub 1-1:1.0: 4 ports detected
...
[3.458475] usb 1-1: reset high-speed USB device number 2 using
ci_hdrc
...
[5.456678] usb 1-1: reset high-speed USB device number 2 using
ci_hdrc
[7.456684] usb 1-1: reset high-speed USB device number 2 using
ci_hdrc 

This happens when using a USB Hub on our Carrier Board or an external
USB Hub.

# lsusb --tree
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ci_hdrc/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M

It does not happen with the downstream 4.9.11 based kernel.

Any idea?

--
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] SD card reader disappears after suspend

[Mathias Nyman]

On 10.02.2018 02:01, Samuel Sadok wrote:

Thanks Mathias for looking into this.

2018-02-06 18:32 GMT+01:00 Mathias Nyman :


Does reverting
37be6676 usb: hub: Fix auto-remount of safely removed or ejected USB-3
devices
help?


Unfortunately not, the card reader is still missing after resume.

Here's the dmesg and usbmon (as previously, doing one suspend-resume cycle):
https://gist.github.com/anonymous/5aea8eddf97e1b964bffd75ed88793fd

For this log I also increased the usbmon buffer size as suggested by
Alan (to about 2MB). This (seemingly) resolved the issue with the log
gaps.


Ok, one reason reverting didn't help is that it we still don't really
disable and re-enable:

[  100.771564] usb usb2-port4: logical disconnect
...
[ 100.771586] usb usb2-port4: Not disabling port; link state is RxDetect


The reset resume of device "usb 2-4" (the device in question) happens
around [100.77].
In the usbmon log there is no activity at that exact time, only ~50ms
before and after. Can we infer from this that the issue is independent
from the actual device and must stem from some faulty state in the
kernel or USB controller?

Btw I also added/modified some debug lines for my own understanding,
those are tagged with "[CUSTOM LOG]".


* check that root cause for failing USB3 device reset after resume is not
that several
   xhci slots are in Default state at the same time. xHC can't handle this.
   In normal device enumeration usb core has a mutex protecting it, not sure
it works here,
   maybe usb core and xhci are out of sync after xHC reset?


I find this line in particular interesting:
[ 100.771536] xhci_hcd :00:14.0: [CUSTOM LOG] xHCI
xhci_urb_enqueue called with unaddressed device, slot_id = 1
This comes from xhci_check_args(). Since udev->slot_id == 1 is
non-zero this implies that xhci->devs[udev->slot_id] must be NULL for
this particular device (usb 2-4), which I guess is not good. So to me
this does indeed look like the usb core and xhci are out of sync.

However I'm not familiar with the code (for instance what is slot_id
is for, who uses it, should it always be 0 on resume?) but based on
the log and what you wrote I guess this sounds like a good point:


xhci uses slot_id to identify different usb devices connected to it.
xHC hw gives each enabled attached usb device a slot_id.
When usb core asks xhci host to do something to a device xhci driver knows
which device based on udev->slot_id

when xhci controller is reset, all xhci slots are disabled and freed, but
usb core still has udev->slot_id pointers set.

In normal resume case the xHC controller is not reset, but if something goes 
wrong,
or power is cut from xHC during suspend then we recover by resetting xHC at 
resume.

I'll try to write some quick testpatches that:
- removes LPM and LTM disabling from usb_reset_and_verify_device
- zeroes udev->slot_id when slot is disabled and freed in xhci
- forces a disable/enable port after port reset failed a few times.

Thanks
Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 RESEND] usb: dwc3: core: Fix ULPI PHYs and prevent phy_get/ulpi_init during suspend/resume

[Roger Quadros]

In order for ULPI PHYs to work, dwc3_phy_setup() and dwc3_ulpi_init()
must be doene before dwc3_core_get_phy().

commit 541768b08a40 ("usb: dwc3: core: Call dwc3_core_get_phy() before 
initializing phys")
broke this.

The other issue is that dwc3_core_get_phy() and dwc3_ulpi_init() should
be called only once during the life cycle of the driver. However,
as dwc3_core_init() is called during system suspend/resume it will
result in multiple calls to dwc3_core_get_phy() and dwc3_ulpi_init()
which is wrong.

Fix this by moving dwc3_ulpi_init() out of dwc3_phy_setup()
into dwc3_core_ulpi_init(). Use a flag 'ulpi_ready' to ensure that
dwc3_core_ulpi_init() is called only once from dwc3_core_init().

Use another flag 'phys_ready' to call dwc3_core_get_phy() only once from
dwc3_core_init().

Fixes: 541768b08a40 ("usb: dwc3: core: Call dwc3_core_get_phy() before 
initializing phys")
Fixes: f54edb539c11 ("usb: dwc3: core: initialize ULPI before trying to get the 
PHY")
Cc: linux-stable  # >= v4.13
Signed-off-by: Roger Quadros 
---
Rebased on Felipe's testing/fixes branch.

 drivers/usb/dwc3/core.c | 47 ---
 drivers/usb/dwc3/core.h |  5 +
 2 files changed, 41 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 59511f2..f1d838a 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -486,6 +486,22 @@ static void dwc3_cache_hwparams(struct dwc3 *dwc)
parms->hwparams8 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS8);
 }
 
+static int dwc3_core_ulpi_init(struct dwc3 *dwc)
+{
+   int intf;
+   int ret = 0;
+
+   intf = DWC3_GHWPARAMS3_HSPHY_IFC(dwc->hwparams.hwparams3);
+
+   if (intf == DWC3_GHWPARAMS3_HSPHY_IFC_ULPI ||
+   (intf == DWC3_GHWPARAMS3_HSPHY_IFC_UTMI_ULPI &&
+dwc->hsphy_interface &&
+!strncmp(dwc->hsphy_interface, "ulpi", 4)))
+   ret = dwc3_ulpi_init(dwc);
+
+   return ret;
+}
+
 /**
  * dwc3_phy_setup - Configure USB PHY Interface of DWC3 Core
  * @dwc: Pointer to our controller context structure
@@ -497,7 +513,6 @@ static void dwc3_cache_hwparams(struct dwc3 *dwc)
 static int dwc3_phy_setup(struct dwc3 *dwc)
 {
u32 reg;
-   int ret;
 
reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
 
@@ -568,9 +583,6 @@ static int dwc3_phy_setup(struct dwc3 *dwc)
}
/* FALLTHROUGH */
case DWC3_GHWPARAMS3_HSPHY_IFC_ULPI:
-   ret = dwc3_ulpi_init(dwc);
-   if (ret)
-   return ret;
/* FALLTHROUGH */
default:
break;
@@ -727,6 +739,7 @@ static void dwc3_core_setup_global_control(struct dwc3 *dwc)
 }
 
 static int dwc3_core_get_phy(struct dwc3 *dwc);
+static int dwc3_core_ulpi_init(struct dwc3 *dwc);
 
 /**
  * dwc3_core_init - Low-level initialization of DWC3 Core
@@ -758,17 +771,27 @@ static int dwc3_core_init(struct dwc3 *dwc)
dwc->maximum_speed = USB_SPEED_HIGH;
}
 
-   ret = dwc3_core_get_phy(dwc);
+   ret = dwc3_phy_setup(dwc);
if (ret)
goto err0;
 
-   ret = dwc3_core_soft_reset(dwc);
-   if (ret)
-   goto err0;
+   if (!dwc->ulpi_ready) {
+   ret = dwc3_core_ulpi_init(dwc);
+   if (ret)
+   goto err0;
+   dwc->ulpi_ready = true;
+   }
 
-   ret = dwc3_phy_setup(dwc);
+   if (!dwc->phys_ready) {
+   ret = dwc3_core_get_phy(dwc);
+   if (ret)
+   goto err0a;
+   dwc->phys_ready = true;
+   }
+
+   ret = dwc3_core_soft_reset(dwc);
if (ret)
-   goto err0;
+   goto err0a;
 
dwc3_core_setup_global_control(dwc);
dwc3_core_num_eps(dwc);
@@ -841,6 +864,9 @@ static int dwc3_core_init(struct dwc3 *dwc)
phy_exit(dwc->usb2_generic_phy);
phy_exit(dwc->usb3_generic_phy);
 
+err0a:
+   dwc3_ulpi_exit(dwc);
+
 err0:
return ret;
 }
@@ -1235,7 +1261,6 @@ static int dwc3_probe(struct platform_device *pdev)
 
 err3:
dwc3_free_event_buffers(dwc);
-   dwc3_ulpi_exit(dwc);
 
 err2:
pm_runtime_allow(>dev);
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 185b960..860d2bc 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -797,7 +797,9 @@ struct dwc3_scratchpad_array {
  * @usb3_phy: pointer to USB3 PHY
  * @usb2_generic_phy: pointer to USB2 PHY
  * @usb3_generic_phy: pointer to USB3 PHY
+ * @phys_ready: flag to indicate that PHYs are ready
  * @ulpi: pointer to ulpi interface
+ * @ulpi_ready: flag to indicate that ULPI is initialized
  * @u2sel: parameter from Set SEL request.
  * @u2pel: parameter from Set SEL request.
  * @u1sel: parameter from Set SEL request.
@@ -895,7 +897,10 @@ struct dwc3 {
struct phy  

Re: VM Fails to Start When Passing Through PCIe Card

[Mathias Nyman]

On 10.02.2018 01:46, Blake lee wrote:

I tested along with another person from the VFIO community that was
having the same issue. Resolved in both cases.



Thanks, patches sent forward.

-Mathias

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Q: Does mass storage gadget use DMA ?

[Oliver Neukum]

Am Sonntag, den 11.02.2018, 22:17 +0200 schrieb Ran Shalit:
> On Tue, Feb 6, 2018 at 8:55 AM, Felipe Balbi
>  wrote:
> > 
> > 
> > Hi,
> > 
> > Ran Shalit  writes:
> > > 
> > > Hello,
> > > 
> > > I check code in:
> > > https://elixir.free-electrons.com/linux/v3.3/source/drivers/usb/gadget/f_mass_storage.c
> > > but I see no API usage of DMA, yet it is being mentioned as if it is used.
> > 
> > but it is used. It's just managed by the UDC driver (dwc3, musb,
> > chipidea, Renesas, etc)
> > 
> Just to be sure,
> can I assume that other usb gadget drivers are using DMA (including
> gadgetfs for userspace driver) ?
> And it is also correct for host drivers  (such as camera device ) ?

None of these drivers are for hardware. They implement a protocol.
On the host as well as on the gadget side there are driver for the
actual host controllers (EHCI, XHCI, ...) as well as their gadget
equivalents.

Any of these drivers may or may not use DMA. Neither the assumption
that they use DMA or the assumption that they do not use DMA
is valid. In fact they may mix it.
Your code must be ready to cope with either usage.

HTH
Oliver

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/6] xhci: Fix NULL pointer in xhci debugfs

[Mathias Nyman]

From: Zhengjun Xing 

Commit dde634057da7 ("xhci: Fix use-after-free in xhci debugfs") causes a
null pointer dereference while fixing xhci-debugfs usage of ring pointers
that were freed during hibernate.

The fix passed addresses to ring pointers instead, but forgot to do this
change for the xhci_ring_trb_show function.

The address of the ring pointer passed to xhci-debugfs was of a temporary
ring pointer "new_ring" instead of the actual ring "ring" pointer. The
temporary new_ring pointer will be set to NULL later causing the NULL
pointer dereference.

This issue was seen when reading xhci related files in debugfs:

cat /sys/kernel/debug/usb/xhci/*/devices/*/ep*/trbs

[  184.604861] BUG: unable to handle kernel NULL pointer dereference at (null)
[  184.613776] IP: xhci_ring_trb_show+0x3a/0x890
[  184.618733] PGD 264193067 P4D 264193067 PUD 263238067 PMD 0
[  184.625184] Oops:  [#1] SMP
[  184.726410] RIP: 0010:xhci_ring_trb_show+0x3a/0x890
[  184.731944] RSP: 0018:ba8243c0fd90 EFLAGS: 00010246
[  184.737880] RAX:  RBX:  RCX: 000295d6
[  184.746020] RDX: 000295d5 RSI: 0001 RDI: 971a6418d400
[  184.754121] RBP:  R08:  R09: 
[  184.76] R10: 971a64c98a80 R11: 971a62a00e40 R12: 971a62a85500
[  184.770325] R13: 0002 R14: 971a6418d400 R15: 971a6418d400
[  184.778448] FS:  7fe725a79700() GS:971a6ec0() 
knlGS:
[  184.787644] CS:  0010 DS:  ES:  CR0: 80050033
[  184.794168] CR2:  CR3: 00025f365005 CR4: 003606f0
[  184.802318] Call Trace:
[  184.805094]  ? seq_read+0x281/0x3b0
[  184.809068]  seq_read+0xeb/0x3b0
[  184.812735]  full_proxy_read+0x4d/0x70
[  184.817007]  __vfs_read+0x23/0x120
[  184.820870]  vfs_read+0x91/0x130
[  184.824538]  SyS_read+0x42/0x90
[  184.828106]  entry_SYSCALL_64_fastpath+0x1a/0x7d

Fixes: dde634057da7 ("xhci: Fix use-after-free in xhci debugfs")
Cc:  # v4.15
Signed-off-by: Zhengjun Xing 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-debugfs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-debugfs.c b/drivers/usb/host/xhci-debugfs.c
index e26e685..5851052 100644
--- a/drivers/usb/host/xhci-debugfs.c
+++ b/drivers/usb/host/xhci-debugfs.c
@@ -211,7 +211,7 @@ static void xhci_ring_dump_segment(struct seq_file *s,
 static int xhci_ring_trb_show(struct seq_file *s, void *unused)
 {
int i;
-   struct xhci_ring*ring = s->private;
+   struct xhci_ring*ring = *(struct xhci_ring **)s->private;
struct xhci_segment *seg = ring->first_seg;
 
for (i = 0; i < ring->num_segs; i++) {
@@ -387,7 +387,7 @@ void xhci_debugfs_create_endpoint(struct xhci_hcd *xhci,
 
snprintf(epriv->name, sizeof(epriv->name), "ep%02d", ep_index);
epriv->root = xhci_debugfs_create_ring_dir(xhci,
-  >eps[ep_index].new_ring,
+  >eps[ep_index].ring,
   epriv->name,
   spriv->root);
spriv->eps[ep_index] = epriv;
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 6/6] xhci: fix xhci debugfs errors in xhci_stop

[Mathias Nyman]

From: Zhengjun Xing 

In function xhci_stop, xhci_debugfs_exit called before xhci_mem_cleanup.
xhci_debugfs_exit removed the xhci debugfs root nodes, xhci_mem_cleanup
called function xhci_free_virt_devices_depth_first which in turn called
function xhci_debugfs_remove_slot.
Function xhci_debugfs_remove_slot removed the nodes for devices, the nodes
folders are sub folder of xhci debugfs.

It is unreasonable to remove xhci debugfs root folder before
xhci debugfs sub folder. Function xhci_mem_cleanup should be called
before function xhci_debugfs_exit.

Fixes: 02b6fdc2a153 ("usb: xhci: Add debugfs interface for xHCI driver")
Cc:  # v4.15
Signed-off-by: Zhengjun Xing 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 4adb6da..25d4b748 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -646,8 +646,6 @@ static void xhci_stop(struct usb_hcd *hcd)
return;
}
 
-   xhci_debugfs_exit(xhci);
-
xhci_dbc_exit(xhci);
 
spin_lock_irq(>lock);
@@ -680,6 +678,7 @@ static void xhci_stop(struct usb_hcd *hcd)
 
xhci_dbg_trace(xhci, trace_xhci_dbg_init, "cleaning up memory");
xhci_mem_cleanup(xhci);
+   xhci_debugfs_exit(xhci);
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
"xhci_stop completed - status = %x",
readl(>op_regs->status));
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/6] xhci: workaround for AMD Promontory disabled ports wakeup

[Mathias Nyman]

From: Joe Lee 

For AMD Promontory xHCI host, although you can disable USB ports in
BIOS settings, those ports will be enabled anyway after you remove a
device on that port and re-plug it in again. It's a known limitation of
the chip. As a workaround we can clear the PORT_WAKE_BITS.

[commit and code comment rephrasing -Mathias]
Signed-off-by: Joe Lee 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/pci-quirks.c | 109 ++
 drivers/usb/host/pci-quirks.h |   5 ++
 drivers/usb/host/xhci-hub.c   |   7 +++
 drivers/usb/host/xhci-pci.c   |  11 +
 drivers/usb/host/xhci.h   |   2 +-
 5 files changed, 133 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 1615367..67ad4bb 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -66,6 +66,23 @@
 #defineAX_INDXC0x30
 #defineAX_DATAC0x34
 
+#define PT_ADDR_INDX   0xE8
+#define PT_READ_INDX   0xE4
+#define PT_SIG_1_ADDR  0xA520
+#define PT_SIG_2_ADDR  0xA521
+#define PT_SIG_3_ADDR  0xA522
+#define PT_SIG_4_ADDR  0xA523
+#define PT_SIG_1_DATA  0x78
+#define PT_SIG_2_DATA  0x56
+#define PT_SIG_3_DATA  0x34
+#define PT_SIG_4_DATA  0x12
+#define PT4_P1_REG 0xB521
+#define PT4_P2_REG 0xB522
+#define PT2_P1_REG 0xD520
+#define PT2_P2_REG 0xD521
+#define PT1_P1_REG 0xD522
+#define PT1_P2_REG 0xD523
+
 #defineNB_PCIE_INDX_ADDR   0xe0
 #defineNB_PCIE_INDX_DATA   0xe4
 #definePCIE_P_CNTL 0x10040
@@ -513,6 +530,98 @@ void usb_amd_dev_put(void)
 EXPORT_SYMBOL_GPL(usb_amd_dev_put);
 
 /*
+ * Check if port is disabled in BIOS on AMD Promontory host.
+ * BIOS Disabled ports may wake on connect/disconnect and need
+ * driver workaround to keep them disabled.
+ * Returns true if port is marked disabled.
+ */
+bool usb_amd_pt_check_port(struct device *device, int port)
+{
+   unsigned char value, port_shift;
+   struct pci_dev *pdev;
+   u16 reg;
+
+   pdev = to_pci_dev(device);
+   pci_write_config_word(pdev, PT_ADDR_INDX, PT_SIG_1_ADDR);
+
+   pci_read_config_byte(pdev, PT_READ_INDX, );
+   if (value != PT_SIG_1_DATA)
+   return false;
+
+   pci_write_config_word(pdev, PT_ADDR_INDX, PT_SIG_2_ADDR);
+
+   pci_read_config_byte(pdev, PT_READ_INDX, );
+   if (value != PT_SIG_2_DATA)
+   return false;
+
+   pci_write_config_word(pdev, PT_ADDR_INDX, PT_SIG_3_ADDR);
+
+   pci_read_config_byte(pdev, PT_READ_INDX, );
+   if (value != PT_SIG_3_DATA)
+   return false;
+
+   pci_write_config_word(pdev, PT_ADDR_INDX, PT_SIG_4_ADDR);
+
+   pci_read_config_byte(pdev, PT_READ_INDX, );
+   if (value != PT_SIG_4_DATA)
+   return false;
+
+   /* Check disabled port setting, if bit is set port is enabled */
+   switch (pdev->device) {
+   case 0x43b9:
+   case 0x43ba:
+   /*
+* device is AMD_PROMONTORYA_4(0x43b9) or PROMONTORYA_3(0x43ba)
+* PT4_P1_REG bits[7..1] represents USB2.0 ports 6 to 0
+* PT4_P2_REG bits[6..0] represents ports 13 to 7
+*/
+   if (port > 6) {
+   reg = PT4_P2_REG;
+   port_shift = port - 7;
+   } else {
+   reg = PT4_P1_REG;
+   port_shift = port + 1;
+   }
+   break;
+   case 0x43bb:
+   /*
+* device is AMD_PROMONTORYA_2(0x43bb)
+* PT2_P1_REG bits[7..5] represents USB2.0 ports 2 to 0
+* PT2_P2_REG bits[5..0] represents ports 9 to 3
+*/
+   if (port > 2) {
+   reg = PT2_P2_REG;
+   port_shift = port - 3;
+   } else {
+   reg = PT2_P1_REG;
+   port_shift = port + 5;
+   }
+   break;
+   case 0x43bc:
+   /*
+* device is AMD_PROMONTORYA_1(0x43bc)
+* PT1_P1_REG[7..4] represents USB2.0 ports 3 to 0
+* PT1_P2_REG[5..0] represents ports 9 to 4
+*/
+   if (port > 3) {
+   reg = PT1_P2_REG;
+   port_shift = port - 4;
+   } else {
+   reg = PT1_P1_REG;
+   port_shift = port + 4;
+   }
+   break;
+   default:
+   return false;
+   }
+   pci_write_config_word(pdev, PT_ADDR_INDX, reg);
+   pci_read_config_byte(pdev, PT_READ_INDX, );
+
+   return !(value & BIT(port_shift));
+}
+EXPORT_SYMBOL_GPL(usb_amd_pt_check_port);
+
+/*
  * Make sure the controller is completely inactive, unable to
  * generate 

[PATCH 2/6] xhci: Don't print a warning when setting link state for disabled ports

[Mathias Nyman]

When disabling a USB3 port the hub driver will set the port link state to
U3 to prevent "ejected" or "safely removed" devices that are still
physically connected from immediately re-enumerating.

If the device was really unplugged, then error messages were printed
as the hub tries to set the U3 link state for a port that is no longer
enabled.

xhci-hcd ee00.usb: Cannot set link state.
usb usb8-port1: cannot disable (err = -32)

Don't print error message in xhci-hub if hub tries to set port link state
for a disabled port. Return -ENODEV instead which also silences hub driver.

Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-hub.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 1df0c36..72ebbc9 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -1224,17 +1224,17 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, 
u16 wValue,
temp = readl(port_array[wIndex]);
break;
}
-
-   /* Software should not attempt to set
-* port link state above '3' (U3) and the port
-* must be enabled.
-*/
-   if ((temp & PORT_PE) == 0 ||
-   (link_state > USB_SS_PORT_LS_U3)) {
-   xhci_warn(xhci, "Cannot set link state.\n");
+   /* Port must be enabled */
+   if (!(temp & PORT_PE)) {
+   retval = -ENODEV;
+   break;
+   }
+   /* Can't set port link state above '3' (U3) */
+   if (link_state > USB_SS_PORT_LS_U3) {
+   xhci_warn(xhci, "Cannot set port %d link state 
%d\n",
+wIndex, link_state);
goto error;
}
-
if (link_state == USB_SS_PORT_LS_U3) {
slot_id = xhci_find_slot_id_by_port(hcd, xhci,
wIndex + 1);
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/6] xhci: xhci debugfs device nodes weren't removed after device plugged out

[Mathias Nyman]

From: Zhengjun Xing 

There is a bug after plugged out USB device, the device and its ep00
nodes are still kept, we need to remove the nodes in xhci_free_dev when
USB device is plugged out.

Fixes: 052f71e25a7e ("xhci: Fix xhci debugfs NULL pointer dereference in resume 
from hibernate")
Cc:  # v4.15
Signed-off-by: Zhengjun Xing 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index b01bd64..4adb6da 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3545,12 +3545,10 @@ static void xhci_free_dev(struct usb_hcd *hcd, struct 
usb_device *udev)
virt_dev->eps[i].ep_state &= ~EP_STOP_CMD_PENDING;
del_timer_sync(_dev->eps[i].stop_cmd_timer);
}
-
+   xhci_debugfs_remove_slot(xhci, udev->slot_id);
ret = xhci_disable_slot(xhci, udev->slot_id);
-   if (ret) {
-   xhci_debugfs_remove_slot(xhci, udev->slot_id);
+   if (ret)
xhci_free_virt_device(xhci, udev->slot_id);
-   }
 }
 
 int xhci_disable_slot(struct xhci_hcd *xhci, u32 slot_id)
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/6] xhci: Fix xhci debugfs devices node disappearance after hibernation

[Mathias Nyman]

From: Zhengjun Xing 

During system resume from hibernation, xhci host is reset, all the
nodes in devices folder are removed in xhci_mem_cleanup function.
Later nodes in /sys/kernel/debug/usb/xhci/* are created again in
function xhci_run, but the nodes already exist, so the nodes still
keep the old ones, finally device nodes in xhci debugfs folder
/sys/kernel/debug/usb/xhci/*/devices/* are disappeared.

This fix removed xhci debugfs nodes before the nodes are re-created,
so all the nodes in xhci debugfs can be re-created successfully.

Fixes: 02b6fdc2a153 ("usb: xhci: Add debugfs interface for xHCI driver")
Cc:  # v4.15
Signed-off-by: Zhengjun Xing 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 1eeb339..b01bd64 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1014,6 +1014,7 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
 
xhci_dbg(xhci, "cleaning up memory\n");
xhci_mem_cleanup(xhci);
+   xhci_debugfs_exit(xhci);
xhci_dbg(xhci, "xhci_stop completed - status = %x\n",
readl(>op_regs->status));
 
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/6] xhci fixes for usb-linus

[Mathias Nyman]

Hi Greg

This series contain xhci debugfs fixes by Zhengjun, AMD promontory
workaround for keeping BIOS disabled ports disabled, and getting rid
of a extra error message.

Applies on 4.16-rc1

-Mathias

Joe Lee (1):
  xhci: workaround for AMD Promontory disabled ports wakeup

Mathias Nyman (1):
  xhci: Don't print a warning when setting link state for disabled ports

Zhengjun Xing (4):
  xhci: Fix NULL pointer in xhci debugfs
  xhci: Fix xhci debugfs devices node disappearance after hibernation
  xhci: xhci debugfs device nodes weren't removed after device plugged
out
  xhci: fix xhci debugfs errors in xhci_stop

 drivers/usb/host/pci-quirks.c   | 109 
 drivers/usb/host/pci-quirks.h   |   5 ++
 drivers/usb/host/xhci-debugfs.c |   4 +-
 drivers/usb/host/xhci-hub.c |  25 +
 drivers/usb/host/xhci-pci.c |  11 
 drivers/usb/host/xhci.c |  10 ++--
 drivers/usb/host/xhci.h |   2 +-
 7 files changed, 148 insertions(+), 18 deletions(-)

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] usb: dwc3: drd: Fix lock-up on ID change during system suspend/resume

[Roger Quadros]

Felipe,

On 12/02/18 10:54, Felipe Balbi wrote:
> 
> Hi,
> 
> Roger Quadros  writes:
>> Adding/removing host/gadget controller before .pm_complete()
>> causes a lock-up. Let's prevent any dual-role state change
>> between .pm_prepare() and .pm_complete() to fix this.
>>
>> Signed-off-by: Roger Quadros 
>> ---
>>  drivers/usb/dwc3/core.c | 31 +++
>>  drivers/usb/dwc3/core.h |  5 +
>>  drivers/usb/dwc3/drd.c  | 10 ++
>>  3 files changed, 42 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>> index 42379cc..85388dd 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -1414,6 +1414,33 @@ static int dwc3_runtime_idle(struct device *dev)
>>  #endif /* CONFIG_PM */
>>  
>>  #ifdef CONFIG_PM_SLEEP
>> +static int dwc3_prepare(struct device *dev)
>> +{
>> +struct dwc3 *dwc = dev_get_drvdata(dev);
>> +unsigned long   flags;
>> +
>> +if (dwc->dr_mode == USB_DR_MODE_OTG) {
>> +spin_lock_irqsave(>lock, flags);
>> +dwc->dr_keep_role = true;
>> +spin_unlock_irqrestore(>lock, flags);
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +static void dwc3_complete(struct device *dev)
>> +{
>> +struct dwc3 *dwc = dev_get_drvdata(dev);
>> +unsigned long   flags;
>> +
>> +if (dwc->dr_mode == USB_DR_MODE_OTG) {
>> +spin_lock_irqsave(>lock, flags);
>> +dwc->dr_keep_role = false;
>> +spin_unlock_irqrestore(>lock, flags);
>> +dwc3_drd_update(dwc);
>> +}
>> +}
> 
> wouldn't it be far easier to just disable OTG IRQ in prepare? and,
> perhaps, also flush_work_sync() ?
> 

There was some more discussion on this here [1]. Apparently using 
system_freezable_wq
and a patch mentioned at end of [1] is sufficient as well

[1] https://lkml.org/lkml/2018/1/25/384

Could you please share your view there?

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: UAC2 gadget not recognized on Windows 10

[Robert Bielik]

> > Yes, but that isn't the issue AFAIU ? In the USB 2.0 standard related
> > to synchronization
> > (http://sdphca.ucsd.edu/lab_equip_manuals/usb_20.pdf chapter 5.12.4),
> > an isochronous OUT ep with asynchronous synchronization is *required*
> > (at least by Microsoft) to have a feedback IN ep, to be able to report
> > to the host the rate so no under- or overrun condition occurs.
> 
> Indeed, that's also mandated by USB spec. Seems like we need to patch
> f_uac2.c. Can you check if setting the IN endpoint as implicit feedback
> data is enough?

Thanks Felipe, I have all setup so I can try this.

Regards
/Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: UAC2 gadget not recognized on Windows 10

[Felipe Balbi]

Hi,

Robert Bielik  writes:
>> > It seems such a feedback endpoint is now required by the standard:
>> > "The USB 2.0 specification states that if isochronous OUT data
>> > endpoint uses the asynchronous synchronization, an isochronous
>> > feedback endpoint is needed."
>> 
>> We actually have both EP IN and EP OUT on the UAC2 function:
>> 
>> 272:static struct usb_endpoint_descriptor fs_epout_desc = {
>> 282:static struct usb_endpoint_descriptor hs_epout_desc = {
>> 349:static struct usb_endpoint_descriptor fs_epin_desc = {
>> 359:static struct usb_endpoint_descriptor hs_epin_desc = {
>
> Yes, but that isn't the issue AFAIU ? In the USB 2.0 standard related
> to synchronization
> (http://sdphca.ucsd.edu/lab_equip_manuals/usb_20.pdf chapter 5.12.4),
> an isochronous OUT ep with asynchronous synchronization is *required*
> (at least by Microsoft) to have a feedback IN ep, to be able to report
> to the host the rate so no under- or overrun condition occurs.

Indeed, that's also mandated by USB spec. Seems like we need to patch
f_uac2.c. Can you check if setting the IN endpoint as implicit feedback
data is enough?

modified   drivers/usb/gadget/function/f_uac2.c
@@ -351,7 +351,8 @@ static struct usb_endpoint_descriptor fs_epin_desc = {
.bDescriptorType = USB_DT_ENDPOINT,
 
.bEndpointAddress = USB_DIR_IN,
-   .bmAttributes = USB_ENDPOINT_XFER_ISOC | USB_ENDPOINT_SYNC_ASYNC,
+   .bmAttributes = USB_ENDPOINT_XFER_ISOC | USB_ENDPOINT_SYNC_ASYNC |
+   USB_ENDPOINT_USAGE_IMPLICIT_FB,
.wMaxPacketSize = cpu_to_le16(1023),
.bInterval = 1,
 };
@@ -360,7 +361,8 @@ static struct usb_endpoint_descriptor hs_epin_desc = {
.bLength = USB_DT_ENDPOINT_SIZE,
.bDescriptorType = USB_DT_ENDPOINT,
 
-   .bmAttributes = USB_ENDPOINT_XFER_ISOC | USB_ENDPOINT_SYNC_ASYNC,
+   .bmAttributes = USB_ENDPOINT_XFER_ISOC | USB_ENDPOINT_SYNC_ASYNC |
+   USB_ENDPOINT_USAGE_IMPLICIT_FB,
.wMaxPacketSize = cpu_to_le16(1024),
.bInterval = 4,
 };


-- 
balbi


signature.asc
Description: PGP signature

RE: UAC2 gadget not recognized on Windows 10

[Robert Bielik]

> > It seems such a feedback endpoint is now required by the standard:
> > "The USB 2.0 specification states that if isochronous OUT data
> > endpoint uses the asynchronous synchronization, an isochronous
> > feedback endpoint is needed."
> 
> We actually have both EP IN and EP OUT on the UAC2 function:
> 
> 272:static struct usb_endpoint_descriptor fs_epout_desc = {
> 282:static struct usb_endpoint_descriptor hs_epout_desc = {
> 349:static struct usb_endpoint_descriptor fs_epin_desc = {
> 359:static struct usb_endpoint_descriptor hs_epin_desc = {

Yes, but that isn't the issue AFAIU ? In the USB 2.0 standard related to 
synchronization (http://sdphca.ucsd.edu/lab_equip_manuals/usb_20.pdf chapter 
5.12.4), an isochronous OUT ep with asynchronous synchronization is *required* 
(at least by Microsoft) to have a feedback IN ep, to be able to report to the 
host the rate so no under- or overrun condition occurs.

Regards
/Robert

N�r��yb�X��ǧv�^�)޺{.n�+{��^n�r���z���h�&���G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�

RE: UAC2 gadget not recognized on Windows 10

[Felipe Balbi]

Hi,

Robert Bielik  writes:
>> "Wait, never mind – I recognize that failing status code. usbaudio2.sys is
>> complaining that you have an asynchronous data OUT endpoint but it can’t
>> find a corresponding feedback endpoint."
>> 
>> Unfortunately I have no idea what that means. Yet  , but putting it out 
>> there
>> in case someone else does.
>
> https://doc.micrium.com/display/DOC/Audio+Class+Overview#AudioClassOverview-FeedbackEndpoint
>
> It seems such a feedback endpoint is now required by the standard:
> "The USB 2.0 specification states that if isochronous OUT data
> endpoint uses the asynchronous synchronization, an isochronous
> feedback endpoint is needed."

We actually have both EP IN and EP OUT on the UAC2 function:

272:static struct usb_endpoint_descriptor fs_epout_desc = {
282:static struct usb_endpoint_descriptor hs_epout_desc = {
349:static struct usb_endpoint_descriptor fs_epin_desc = {
359:static struct usb_endpoint_descriptor hs_epin_desc = {

Something else may be going bad. Try to get some debugging messages from
your USB controller. I think rPi uses dwc2, so you need to recompile
your kernel with CONFIG_USB_DWC2_DEBUG=y and
CONFIG_USB_DWC2_VERBOSE=y. Then capture all the logs and send it as a
reply here.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 2/2] usb: dwc3: drd: Fix lock-up on ID change during system suspend/resume

[Felipe Balbi]

Hi,

Roger Quadros  writes:
> Adding/removing host/gadget controller before .pm_complete()
> causes a lock-up. Let's prevent any dual-role state change
> between .pm_prepare() and .pm_complete() to fix this.
>
> Signed-off-by: Roger Quadros 
> ---
>  drivers/usb/dwc3/core.c | 31 +++
>  drivers/usb/dwc3/core.h |  5 +
>  drivers/usb/dwc3/drd.c  | 10 ++
>  3 files changed, 42 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 42379cc..85388dd 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -1414,6 +1414,33 @@ static int dwc3_runtime_idle(struct device *dev)
>  #endif /* CONFIG_PM */
>  
>  #ifdef CONFIG_PM_SLEEP
> +static int dwc3_prepare(struct device *dev)
> +{
> + struct dwc3 *dwc = dev_get_drvdata(dev);
> + unsigned long   flags;
> +
> + if (dwc->dr_mode == USB_DR_MODE_OTG) {
> + spin_lock_irqsave(>lock, flags);
> + dwc->dr_keep_role = true;
> + spin_unlock_irqrestore(>lock, flags);
> + }
> +
> + return 0;
> +}
> +
> +static void dwc3_complete(struct device *dev)
> +{
> + struct dwc3 *dwc = dev_get_drvdata(dev);
> + unsigned long   flags;
> +
> + if (dwc->dr_mode == USB_DR_MODE_OTG) {
> + spin_lock_irqsave(>lock, flags);
> + dwc->dr_keep_role = false;
> + spin_unlock_irqrestore(>lock, flags);
> + dwc3_drd_update(dwc);
> + }
> +}

wouldn't it be far easier to just disable OTG IRQ in prepare? and,
perhaps, also flush_work_sync() ?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 0/4] usb: gadget: fotg210-udc: Fixes and cleanup

[Felipe Balbi]

Hi,

Christophe JAILLET  writes:
> This serie aims to fix 2 issues. (path 2 & 4)
>
> The 2nd patch fixes a memory leak. It uses devm_ function a simplify the
> handling of the memory.
>
> The 4th patch fixes a potential invalid pointer dereference.
>
> The 2 other ones, are just clean-ups to remove useless code and add other
> uses of devm_ function to simplify code.
>
> I've left the request_irq/free_irq because I'm unsure of potential side
> effects if some other resources are freed while an IRQ can still be
> triggered. So I've preferred to leave it as-is.
>
> Christophe JAILLET (4):
>   usb: gadget: fotg210-udc: Remove a useless
>   usb: gadget: fotg210-udc: Fix a memory leak
>   usb: gadget: fotg210-udc: Simplify code
>   usb: gadget: fotg210-udc: Fix a potential invalid pointer dereference

you should NEVER make fixes depend on cleanups. It should be the other
way around :-) First fixes, then cleanups. The reason is that fixes can
get accepted during -rc cycle, but cleanups must wait until the next
merge window.

Please fix up your patches, otherwise I'll have to apply the entire
series for v4.17

-- 
balbi


signature.asc
Description: PGP signature

UAC2 audio gadget queries

[Robert Bielik]

Hi all,

I'm trying to get my head around how the UAC2 gadget stuff is supposed to work 
in relation to sample rate conversion etc. etc. From the docs 
(https://www.kernel.org/doc/htmldocs/gadget/structure.html), I surmise that:

1. USB controller driver
2. Gadget Driver
3. Upper Level (u_audio.c) connecting into ALSA subsystem

What I'm not clear about is who is responsible for clocking ? For a more HW 
based gadget, an externally clocked DAC connected via I2S would pull data from 
a buffer, and the OUT endpoint would supply data into that endpoint and 
synchronize the host sending the data via the feedback IN endpoint.

To play audio with the above structure would mean piping data from the UAC2 
Gadget Capture device to the target ALSA output device, which in my case is an 
externally clocked DAC. The problem then arises that the "clock" of the UAC2 
gadget and the output DAC are unrelated and there is no way to feedback the 
clocking to the UAC2 gadget via the ALSA interface (for the feedback endpoint). 
This can of course be handled by sample rate conversion, but it is suboptimal.

A better approach would be IMO to create something like:

1. USB controller driver
2. Gadget driver
3. Upper Level connecting as a JACK client.

In this scenario, JACK would already be setup to use the externally clocked 
DAC. By implementing a JACK client connecting to the gadget driver there would 
now be a direct way to supply the feedback endpoint with the data it needs.

Please let me know if I'm missing something.

All the best,
/Robert

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] usb: dwc3: core: Fix ULPI PHYs and prevent phy_get/ulpi_init during suspend/resume

[Felipe Balbi]

Roger Quadros  writes:

> In order for ULPI PHYs to work, dwc3_phy_setup() and dwc3_ulpi_init()
> must be doene before dwc3_core_get_phy().
>
> commit 541768b08a40 ("usb: dwc3: core: Call dwc3_core_get_phy() before 
> initializing phys")
> broke this.
>
> The other issue is that dwc3_core_get_phy() and dwc3_ulpi_init() should
> be called only once during the life cycle of the driver. However,
> as dwc3_core_init() is called during system suspend/resume it will
> result in multiple calls to dwc3_core_get_phy() and dwc3_ulpi_init()
> which is wrong.
>
> Fix this by moving dwc3_ulpi_init() out of dwc3_phy_setup()
> into dwc3_core_ulpi_init(). Use a flag 'ulpi_ready' to ensure that
> dwc3_core_ulpi_init() is called only once from dwc3_core_init().
>
> Use another flag 'phys_ready' to call dwc3_core_get_phy() only once from
> dwc3_core_init().
>
> Fixes: 541768b08a40 ("usb: dwc3: core: Call dwc3_core_get_phy() before 
> initializing phys")
> Fixes: f54edb539c11 ("usb: dwc3: core: initialize ULPI before trying to get 
> the PHY")
> Cc: linux-stable  # >= v4.13
> Signed-off-by: Roger Quadros 

unfortunately, this doesn't apply anymore. Care to rebase on
testing/fixes? (give me a couple hours though, I'm still applying
patches :-)

cheers

-- 
balbi


signature.asc
Description: PGP signature