Re: Problem of Serial_State in cdc-acm.c

[Greg KH]

On Fri, Mar 10, 2017 at 04:49:59AM +, Benson Liou wrote:
> Important Notice: This email message and any attachments thereto are 
> confidential and/or privileged and/or subject to privacy laws and are 
> intended only for use by the addressee(s) named above. If you are not the 
> intended addressee, you are hereby kindly notified that any dissemination, 
> distribution, copying or use of this email and any attachments thereto is 
> strictly prohibited. If you have received this email in error, kindly delete 
> it from your computer system and notify us at the telephone number or email 
> address appearing above. The writer asserts in respect of this message and 
> attachments all rights for confidentiality, privilege or privacy to the 
> fullest extent permitted by law.

Because of a footer like this, no one is allowed to respond to your
email, even I am not supposed to be sending this response :(
--
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 v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Baolin Wang]

On 10 March 2017 at 14:30, Jun Li  wrote:
>> >> >
>> >> > Will generic phy need add extcon as well?
>> >>
>> >> Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which will
>> >> be common code.
>> >>
>> >
>> > I mean the common code need add 'struct extcon_dev' into both 'struct
>> > phy' and 'struct usb_phy', right? as some/new usb phy use that generic phy
>> driver.
>>
>> Ah, you remind me. Seems we need also add one 'struct extcon_dev' into
>> 'struct phy'.
>>
>> >> >
>> >> >> >
>> >> >> >> Secondly, I also agreed with Peter's comments: Not only USB PHY
>> >> >> >> to register an extcon, but also for the drivers which can
>> >> >> >> detect USB charger type, it may be USB controller driver, USB
>> >> >> >> type-c driver, pmic driver, and these drivers may not have an
>> >> >> >> extcon device since the internal part can finish the vbus detect.
>> >> >> >
>> >> >> > Whichever part can detect vbus, the driver for that part must be
>> >> >> > able to find the extcon and trigger a notification.
>> >> >> > Maybe one part can detect VBUS, another can measure the
>> >> >> > resistance on ID and a third can work through the state machine
>> >> >> > to determine if D+ and D- are shorted together.
>> >> >> > Somehow these three need to work together to determine what is
>> >> >> plugged
>> >> >> > in to the external connection port.  Somewhere there much an
>> 'extcon'
>> >> >> > device which represents that port and which the three devices
>> >> >> > can find and can interact with.
>> >> >> > I think it makes sense for the usb_phy to be the connection point.
>> >> >> > Each of the devices can get to the phy, and the phy can get to
>> >> >> > the
>> >> extcon.
>> >> >> > It doesn't matter very much if the usb phy driver creates the
>> >> >> > extcon, or if something else creates the extcon and the phy
>> >> >> > driver performs a lookup to find it (e.g. based on devicetree info).
>> >> >> >
>> >> >> > The point is that there is obviously an external physical
>> >> >> > connection, and so there should be an 'extcon' device that
>> represents it.
>> >> >>
>> >> >> Peter & Jun, is it OK for you every phy has one extcon device to
>> >> >> receive VBUS notification, especially for detecting the charger
>> >> >> type by
>> >> software?
>> >> >>
>> >> >
>> >> > My understanding is phy/usb_phy as the connection point, will send
>> >> > the notification to PMIC driver which actually control the charge
>> >> > current, also this will be done in your common framework, right?
>> >>
>> >> Not in USB charger framework. If we are all agree every usb_phy can
>> >> register one extcon device, can get correct charger type and send out
>> >> correct vbus_draw information, then we don't need USB charger
>> >> framework as Neil suggested. So this will be okay for your case
>> >> (especially for detecting the charger type by software) ?
>> >
>> > In my case, charger detection is done by controller driver and I need
>> > do charger type detection internally, and only pass the current draw
>> > info via phy which will send out, this seems ok for me, but I think it
>> > will be good if you or someone can show us an example user based on the
>> design Neil suggested.
>> > Will you work out that common code if this USB charger framework is not
>> needed?
>>
>> I will add  a 'struct extcon_dev*' in 'struct usb_phy' and struct phy“. 
>> Others
>> are already ready if everyone has no complain about current design, except
>
> Only adding extcon_dev into usb_phy/phy  and all others are ready?
> My understanding you will also do:
> - We need find a central place to send the notification(phy common part).

That will include these implementation when adding extcon_dev.

> - If the extcon_dev is directly added in usb_phy/phy, PMIC needs some API to 
> findup it.

PMIC can find extcon device by phandle.

>
>> my one concern. (I am afraid if it is enough to send out vbus draw
>> information from USB phy driver, for example you will miss super speed
>> (900mA), which need get the speed information from gadget driver.)
>>
>
> Can we handle this in USB(so has super speed information) and just send out
> 900mA directly?

>From Neil's suggestion, we only have one place to send out current
information from usb phy, so I have this concern and doubt if we still
need the USB charger framework.

-- 
Baolin.wang
Best Regards
--
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 v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Jun Li]

> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Thursday, March 09, 2017 7:23 PM
> To: Jun Li 
> Cc: NeilBrown ; Felipe Balbi ; Greg KH
> ; Sebastian Reichel ; Dmitry
> Eremin-Solenikov ; David Woodhouse
> ; r...@kernel.org; Marek Szyprowski
> ; Ruslan Bilovol ;
> Peter Chen ; Alan Stern
> ; grygorii.stras...@ti.com; Yoshihiro Shimoda
> ; Lee Jones ;
> Mark Brown ; John Stultz ;
> Charles Keepax ;
> patc...@opensource.wolfsonmicro.com; Linux PM list  p...@vger.kernel.org>; USB ; device-
> mainlin...@lists.linuxfoundation.org; LKML 
> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
> 
> On 9 March 2017 at 18:34, Jun Li  wrote:
> >
> >
> >> -Original Message-
> >> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> >> Sent: Thursday, March 09, 2017 2:11 PM
> >> To: Jun Li 
> >> Cc: NeilBrown ; Felipe Balbi ; Greg
> >> KH ; Sebastian Reichel ;
> >> Dmitry Eremin-Solenikov ; David Woodhouse
> >> ; r...@kernel.org; Marek Szyprowski
> >> ; Ruslan Bilovol
> >> ; Peter Chen ;
> >> Alan Stern ; grygorii.stras...@ti.com;
> >> Yoshihiro Shimoda ; Lee Jones
> >> ; Mark Brown ; John Stultz
> >> ; Charles Keepax
> >> ;
> >> patc...@opensource.wolfsonmicro.com; Linux PM list  >> p...@vger.kernel.org>; USB ; device-
> >> mainlin...@lists.linuxfoundation.org; LKML
> >> 
> >> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal
> >> with the usb gadget power negotation
> >>
> >> Hi,
> >>
> >> On 9 March 2017 at 09:50, Jun Li  wrote:
> >> > Hi,
> >> >
> >> >> -Original Message-
> >> >> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> >> >> Sent: Tuesday, March 07, 2017 5:39 PM
> >> >> To: NeilBrown 
> >> >> Cc: Felipe Balbi ; Greg KH
> >> >> ; Sebastian Reichel ;
> >> >> Dmitry Eremin-Solenikov ; David
> Woodhouse
> >> >> ; r...@kernel.org; Jun Li ;
> >> >> Marek Szyprowski ; Ruslan Bilovol
> >> >> ; Peter Chen
> ;
> >> >> Alan Stern ; grygorii.stras...@ti.com;
> >> >> Yoshihiro Shimoda ; Lee Jones
> >> >> ; Mark Brown ; John
> >> >> Stultz ; Charles Keepax
> >> >> ;
> >> >> patc...@opensource.wolfsonmicro.com; Linux PM list  >> >> p...@vger.kernel.org>; USB ; device-
> >> >> mainlin...@lists.linuxfoundation.org; LKML
> >> >> 
> >> >> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to
> >> >> deal with the usb gadget power negotation
> >> >>
> >> >> On 3 March 2017 at 10:23, NeilBrown  wrote:
> >> >> > On Mon, Feb 20 2017, Baolin Wang wrote:
> >> >> >
> >> >> >> Currently the Linux kernel does not provide any standard
> >> >> >> integration of this feature that integrates the USB subsystem
> >> >> >> with the system power regulation provided by PMICs meaning that
> >> >> >> either vendors must add this in their kernels or USB gadget
> >> >> >> devices based on Linux (such as mobile phones) may not behave as
> they should.
> >> >> >> Thus provide a
> >> >> standard framework for doing this in kernel.
> >> >> >>
> >> >> >> Now introduce one user with wm831x_power to support and test
> >> >> >> the usb
> >> >> charger.
> >> >> >> Another user introduced to support charger detection by Jun Li:
> >> >> >> https://www.spinics.net/lists/linux-usb/msg139425.html
> >> >> >> Moreover there may be other potential users will use it in future.
> >> >> >>
> >> >> >> 1. Before v19 patchset we've fixed below issues in extcon
> >> >> >> subsystem and usb phy driver, now all were merged. (Thanks for
> >> >> >> Neil's
> >> >> >> suggestion)
> >> >> >> (1) Have fixed the inconsistencies with USB connector types in
> >> >> >> extcon subsystem by following links:
> 

Re: [PATCH] ARM: imx25: set default phy_type and dr_mode for usbotg port

[Shawn Guo]

On Thu, Feb 16, 2017 at 10:18:58PM +0100, Uwe Kleine-König wrote:
> All currently supported i.MX25-based machines use phy_type = "utmi" and
> dr_mode = "otg".  So this seems to be a sensible default.
> 
> This also doesn't hurt out-of-tree machines because up to now they had
> to specify these two properties in the machine.dts which still takes
> precedence by just overwriting the defaults added here.
> 
> Signed-off-by: Uwe Kleine-König 

Applied, thanks.
--
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] usb: musb: dsps: fix iounmap in error and exit paths

[Bin Liu]

Cleanly iounmap the pointer in error and exit paths.

Signed-off-by: Bin Liu 
---

v2: use a meaningful goto label

 drivers/usb/musb/musb_dsps.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 7c047c4a2565..9c7ee26ef388 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -933,7 +933,7 @@ static int dsps_probe(struct platform_device *pdev)
if (usb_get_dr_mode(>dev) == USB_DR_MODE_PERIPHERAL) {
ret = dsps_setup_optional_vbus_irq(pdev, glue);
if (ret)
-   return ret;
+   goto err_iounmap;
}
 
platform_set_drvdata(pdev, glue);
@@ -946,6 +946,8 @@ static int dsps_probe(struct platform_device *pdev)
 
 err:
pm_runtime_disable(>dev);
+err_iounmap:
+   iounmap(glue->usbss_base);
return ret;
 }
 
@@ -956,6 +958,7 @@ static int dsps_remove(struct platform_device *pdev)
platform_device_unregister(glue->musb);
 
pm_runtime_disable(>dev);
+   iounmap(glue->usbss_base);
 
return 0;
 }
-- 
1.9.1

--
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: Problem of Serial_State in cdc-acm.c

[Benson Liou]

Hi,
I have encounter a problem while sending Serial_State packet of CDC-ACM 
from Linux gadget to Linux host .
Here is my question:
The environment is a USB device which runs Linux is using CDC-ACM(f_acm.c) 
to communicate with a Linux host(cdc-acm.c). When device tries to send 
Serial_State packet to host, host always can't get correct data. I look into 
the host driver(cdc-acm.c) and found driver calls get_unaligned_le16 on data 
and this function inverts byte order of data.
Following is the link of cdc-acm.c and f_acm.c
ACM host: 
http://lxr.free-electrons.com/source/drivers/usb/class/cdc-acm.c#L325
ACM gadget:
http://lxr.free-electrons.com/source/drivers/usb/gadget/function/f_acm.c#L493
From the current code, gadget send Serial_State in big-endian but host 
treat it as little-endian.
Is this a problem?

Appreciate for your time
Benson




Important Notice: This email message and any attachments thereto are 
confidential and/or privileged and/or subject to privacy laws and are intended 
only for use by the addressee(s) named above. If you are not the intended 
addressee, you are hereby kindly notified that any dissemination, distribution, 
copying or use of this email and any attachments thereto is strictly 
prohibited. If you have received this email in error, kindly delete it from 
your computer system and notify us at the telephone number or email address 
appearing above. The writer asserts in respect of this message and attachments 
all rights for confidentiality, privilege or privacy to the fullest extent 
permitted by law.
--
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: Neophyte questions about PCIe

[Mason]

On 08/03/2017 16:17, Bjorn Helgaas wrote:
[snip excellent in-depth overview]

I think I'm making progress, in that I now have a better
idea of what I don't understand. So I'm able to ask
(hopefully) less vague questions.

Take the USB3 PCIe adapter I've been testing with. At some
point during init, the XHCI driver request some memory
(via kmalloc?) in order to exchange data with the host, right?

On my SoC, the RAM used by Linux lives at physical range
[0x8000_, 0x8800_[ => 128 MB

How does the XHCI driver make the adapter aware of where
it can scribble data? The XHCI driver has no notion that
the device is behind a bus, does it?

At some point, the physical addresses must be converted
to PCI bus addresses, right? Is it computed subtracting
the offset defined in the DT?

Then suppose the USB3 card wants to write to an address
in RAM. It sends a packet on the PCIe bus, targeting
the PCI bus address of that RAM, right? Is this address
supposed to be in BAR0 of the root complex? I guess not,
since Bjorn said that it was unusual for a RC to have
a BAR at all. So I'll hand-wave, and decree that, by some
protocol magic, the packet arrives at the PCIe controller.
And this controller knows to forward this write request
over the memory bus. Does that look about right?

My problem is that, in the current implementation of the
PCIe controller, the USB device that wants to write to
memory is supposed to target BAR0 of the RC.

Since my mem space is limited to 256 MB, then BAR0 is
limited to 256 MB (or even 128 MB, since I also need
to mapthe device's BAR into the same mem space).

So, if I understand correctly (which, at this point,
is quite unlikely) PCIe will work correctly for me
only if Linux manages 128 MB or less...

How does it work on systems where the RC has no BAR?
I suppose devices are able to access all of RAM...
because the controller forwards everything? (This may
be where an IOMMU comes handy?)

Is there a way to know, at run-time, where and how big
Linux's dynamic memory pool is? Perhaps the memory pool
itself remains smaller than 128 MB?

I realize that I've asked a million questions. Feel free
to ignore most of them, if you can help with just one,
it would be a tremendous help already.

Regards.
--
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] option: add Quectel UC15, UC20, EC21, and EC25 modems

[Balazs Harmath]

If you tell me how to do it, with pleasure. I have an EC21 on hand just not the 
knowledge how to do it.

Thanks,
Bali


> On Mar 9, 2017, at 1:42 PM, Dan Williams  wrote:
> 
> On Thu, 2017-03-09 at 13:14 -0500, Balazs Harmath wrote:
>> So i can expect these to be added soon?
> 
> Are you able to apply and test this patch, and see if it works for your
> device?  That would help.
> 
> Thanks!
> Dan
> 
>> Thanks,
>> Bali
>> 
>> 
>>> On Mar 9, 2017, at 12:32 PM, Dan Williams  wrote:
>>> 
>>> Add Quectel UC15, UC20, EC21, and EC25.  The EC20 is handled by
>>> qcserial due to a USB VID/PID conflict with an existing Acer
>>> device.
>>> 
>>> Signed-off-by: Dan Williams 
>>> ---
>>> NOTE: The UC20, EC21, and EC25 should also get a corresponding
>>> qmi_wwan
>>> patch but I don't have that lying around at this time.
>>> 
>>> diff --git a/drivers/usb/serial/option.c
>>> b/drivers/usb/serial/option.c
>>> index 9894e34..d4f36df 100644
>>> --- a/drivers/usb/serial/option.c
>>> +++ b/drivers/usb/serial/option.c
>>> @@ -233,6 +233,14 @@ static void option_instat_callback(struct urb
>>> *urb);
>>> #define BANDRICH_PRODUCT_1012   0x1012
>>> 
>>> #define QUALCOMM_VENDOR_ID  0x05C6
>>> +/* These Quectel products use Qualcomm's vendor ID */
>>> +#define QUECTEL_PRODUCT_UC15   0x9090
>>> +#define QUECTEL_PRODUCT_UC20   0x9003
>>> +
>>> +#define QUECTEL_VENDOR_ID  0x2c7c
>>> +/* These Quectel products use Quectel's vendor ID */
>>> +#define QUECTEL_PRODUCT_EC21   0x0121
>>> +#define QUECTEL_PRODUCT_EC25   0x0125
>>> 
>>> #define CMOTECH_VENDOR_ID   0x16d8
>>> #define CMOTECH_PRODUCT_60010x6001
>>> @@ -1159,7 +1167,14 @@ static const struct usb_device_id
>>> option_ids[] = {
>>> { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6613)}, /* Onda H600/ZTE
>>> MF330 */
>>> { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x0023)}, /* ONYX 3G device */
>>> { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000)}, /* SIMCom SIM5218 */
>>> -   { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9003), /* Quectel UC20
>>> */
>>> +   /* Quectel products using Qualcomm vendor ID */
>>> +   { USB_DEVICE(QUALCOMM_VENDOR_ID, QUECTEL_PRODUCT_UC15)},
>>> +   { USB_DEVICE(QUALCOMM_VENDOR_ID, QUECTEL_PRODUCT_UC20),
>>> + .driver_info = (kernel_ulong_t)_intf4_blacklist },
>>> +   /* Quectel products using Quectel vendor ID */
>>> +   { USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC21),
>>> + .driver_info = (kernel_ulong_t)_intf4_blacklist },
>>> +   { USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC25),
>>>   .driver_info = (kernel_ulong_t)_intf4_blacklist },
>>> { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) },
>>> { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CMU_300) },
>> 
>> 

--
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] option: add Quectel UC15, UC20, EC21, and EC25 modems

[Dan Williams]

On Thu, 2017-03-09 at 13:14 -0500, Balazs Harmath wrote:
> So i can expect these to be added soon?

Are you able to apply and test this patch, and see if it works for your
device?  That would help.

Thanks!
Dan

> Thanks,
> Bali
> 
> 
> > On Mar 9, 2017, at 12:32 PM, Dan Williams  wrote:
> > 
> > Add Quectel UC15, UC20, EC21, and EC25.  The EC20 is handled by
> > qcserial due to a USB VID/PID conflict with an existing Acer
> > device.
> > 
> > Signed-off-by: Dan Williams 
> > ---
> > NOTE: The UC20, EC21, and EC25 should also get a corresponding
> > qmi_wwan
> > patch but I don't have that lying around at this time.
> > 
> > diff --git a/drivers/usb/serial/option.c
> > b/drivers/usb/serial/option.c
> > index 9894e34..d4f36df 100644
> > --- a/drivers/usb/serial/option.c
> > +++ b/drivers/usb/serial/option.c
> > @@ -233,6 +233,14 @@ static void option_instat_callback(struct urb
> > *urb);
> > #define BANDRICH_PRODUCT_1012   0x1012
> > 
> > #define QUALCOMM_VENDOR_ID  0x05C6
> > +/* These Quectel products use Qualcomm's vendor ID */
> > +#define QUECTEL_PRODUCT_UC15   0x9090
> > +#define QUECTEL_PRODUCT_UC20   0x9003
> > +
> > +#define QUECTEL_VENDOR_ID  0x2c7c
> > +/* These Quectel products use Quectel's vendor ID */
> > +#define QUECTEL_PRODUCT_EC21   0x0121
> > +#define QUECTEL_PRODUCT_EC25   0x0125
> > 
> > #define CMOTECH_VENDOR_ID   0x16d8
> > #define CMOTECH_PRODUCT_60010x6001
> > @@ -1159,7 +1167,14 @@ static const struct usb_device_id
> > option_ids[] = {
> > { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6613)}, /* Onda H600/ZTE
> > MF330 */
> > { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x0023)}, /* ONYX 3G device */
> > { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000)}, /* SIMCom SIM5218 */
> > -   { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9003), /* Quectel UC20
> > */
> > +   /* Quectel products using Qualcomm vendor ID */
> > +   { USB_DEVICE(QUALCOMM_VENDOR_ID, QUECTEL_PRODUCT_UC15)},
> > +   { USB_DEVICE(QUALCOMM_VENDOR_ID, QUECTEL_PRODUCT_UC20),
> > +     .driver_info = (kernel_ulong_t)_intf4_blacklist },
> > +   /* Quectel products using Quectel vendor ID */
> > +   { USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC21),
> > +     .driver_info = (kernel_ulong_t)_intf4_blacklist },
> > +   { USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC25),
> >   .driver_info = (kernel_ulong_t)_intf4_blacklist },
> > { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) },
> > { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CMU_300) },
> 
> 
--
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 v4 1/3] usb: orion-echi: Add support for the Armada 3700

[Alan Stern]

On Thu, 9 Mar 2017, Gregory CLEMENT wrote:

> From: Hua Jing 
> 
> - Add a new compatible string for the Armada 3700 SoCs
> 
> - add sbuscfg support for orion usb controller driver. For the SoCs
>   without hlock, need to program BAWR/BARD/AHBBRST fields in the sbuscfg
>   register to guarantee the AHB master's burst would not overrun or
>   underrun the FIFO.
> 
> - the sbuscfg register has to be set after the usb controller reset,
>   otherwise the value would be overridden to 0. In order to do this, the
>   reset callback is registered.
> 
> [gregory.clem...@free-electrons.com: - reword commit and comments
>- fix error path in ehci_orion_drv_reset()
>- fix checkpatch warning]
> Signed-off-by: Hua Jing 
> Signed-off-by: Gregory CLEMENT 
> Reviewed-by: Andrew Lunn 

Acked-by: Alan Stern 

> ---
>  .../devicetree/bindings/usb/ehci-orion.txt |  4 ++-
>  drivers/usb/host/ehci-orion.c  | 36 
> ++
>  2 files changed, 39 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/ehci-orion.txt 
> b/Documentation/devicetree/bindings/usb/ehci-orion.txt
> index 17c3bc858b86..2855bae79fda 100644
> --- a/Documentation/devicetree/bindings/usb/ehci-orion.txt
> +++ b/Documentation/devicetree/bindings/usb/ehci-orion.txt
> @@ -1,7 +1,9 @@
>  * EHCI controller, Orion Marvell variants
>  
>  Required properties:
> -- compatible: must be "marvell,orion-ehci"
> +- compatible: must be one of the following
> + "marvell,orion-ehci"
> + "marvell,armada-3700-ehci"
>  - reg: physical base address of the controller and length of memory mapped
>region.
>  - interrupts: The EHCI interrupt
> diff --git a/drivers/usb/host/ehci-orion.c b/drivers/usb/host/ehci-orion.c
> index ee8d5faa0194..1aec87ec68df 100644
> --- a/drivers/usb/host/ehci-orion.c
> +++ b/drivers/usb/host/ehci-orion.c
> @@ -47,6 +47,18 @@
>  #define USB_PHY_IVREF_CTRL   0x440
>  #define USB_PHY_TST_GRP_CTRL 0x450
>  
> +#define USB_SBUSCFG  0x90
> +
> +/* BAWR = BARD = 3 : Align read/write bursts packets larger than 128 bytes */
> +#define USB_SBUSCFG_BAWR_ALIGN_128B  (0x3 << 6)
> +#define USB_SBUSCFG_BARD_ALIGN_128B  (0x3 << 3)
> +/* AHBBRST = 3  : Align AHB Burst to INCR16 (64 bytes) */
> +#define USB_SBUSCFG_AHBBRST_INCR16   (0x3 << 0)
> +
> +#define USB_SBUSCFG_DEF_VAL (USB_SBUSCFG_BAWR_ALIGN_128B \
> +  | USB_SBUSCFG_BARD_ALIGN_128B  \
> +  | USB_SBUSCFG_AHBBRST_INCR16)
> +
>  #define DRIVER_DESC "EHCI orion driver"
>  
>  #define hcd_to_orion_priv(h) ((struct orion_ehci_hcd *)hcd_to_ehci(h)->priv)
> @@ -151,8 +163,31 @@ ehci_orion_conf_mbus_windows(struct usb_hcd *hcd,
>   }
>  }
>  
> +static int ehci_orion_drv_reset(struct usb_hcd *hcd)
> +{
> + struct device *dev = hcd->self.controller;
> + int ret;
> +
> + ret = ehci_setup(hcd);
> + if (ret)
> + return ret;
> +
> + /*
> +  * For SoC without hlock, need to program sbuscfg value to guarantee
> +  * AHB master's burst would not overrun or underrun FIFO.
> +  *
> +  * sbuscfg reg has to be set after usb controller reset, otherwise
> +  * the value would be override to 0.
> +  */
> + if (of_device_is_compatible(dev->of_node, "marvell,armada-3700-ehci"))
> + wrl(USB_SBUSCFG, USB_SBUSCFG_DEF_VAL);
> +
> + return ret;
> +}
> +
>  static const struct ehci_driver_overrides orion_overrides __initconst = {
>   .extra_priv_size =  sizeof(struct orion_ehci_hcd),
> + .reset = ehci_orion_drv_reset,
>  };
>  
>  static int ehci_orion_drv_probe(struct platform_device *pdev)
> @@ -310,6 +345,7 @@ static int ehci_orion_drv_remove(struct platform_device 
> *pdev)
>  
>  static const struct of_device_id ehci_orion_dt_ids[] = {
>   { .compatible = "marvell,orion-ehci", },
> + { .compatible = "marvell,armada-3700-ehci", },
>   {},
>  };
>  MODULE_DEVICE_TABLE(of, ehci_orion_dt_ids);
> 

--
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] option: add Quectel UC15, UC20, EC21, and EC25 modems

[Balazs Harmath]

So i can expect these to be added soon?

Thanks,
Bali


> On Mar 9, 2017, at 12:32 PM, Dan Williams  wrote:
> 
> Add Quectel UC15, UC20, EC21, and EC25.  The EC20 is handled by
> qcserial due to a USB VID/PID conflict with an existing Acer
> device.
> 
> Signed-off-by: Dan Williams 
> ---
> NOTE: The UC20, EC21, and EC25 should also get a corresponding qmi_wwan
> patch but I don't have that lying around at this time.
> 
> diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
> index 9894e34..d4f36df 100644
> --- a/drivers/usb/serial/option.c
> +++ b/drivers/usb/serial/option.c
> @@ -233,6 +233,14 @@ static void option_instat_callback(struct urb *urb);
> #define BANDRICH_PRODUCT_1012 0x1012
> 
> #define QUALCOMM_VENDOR_ID0x05C6
> +/* These Quectel products use Qualcomm's vendor ID */
> +#define QUECTEL_PRODUCT_UC15 0x9090
> +#define QUECTEL_PRODUCT_UC20 0x9003
> +
> +#define QUECTEL_VENDOR_ID0x2c7c
> +/* These Quectel products use Quectel's vendor ID */
> +#define QUECTEL_PRODUCT_EC21 0x0121
> +#define QUECTEL_PRODUCT_EC25 0x0125
> 
> #define CMOTECH_VENDOR_ID 0x16d8
> #define CMOTECH_PRODUCT_6001  0x6001
> @@ -1159,7 +1167,14 @@ static const struct usb_device_id option_ids[] = {
>   { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6613)}, /* Onda H600/ZTE MF330 */
>   { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x0023)}, /* ONYX 3G device */
>   { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000)}, /* SIMCom SIM5218 */
> - { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9003), /* Quectel UC20 */
> + /* Quectel products using Qualcomm vendor ID */
> + { USB_DEVICE(QUALCOMM_VENDOR_ID, QUECTEL_PRODUCT_UC15)},
> + { USB_DEVICE(QUALCOMM_VENDOR_ID, QUECTEL_PRODUCT_UC20),
> +   .driver_info = (kernel_ulong_t)_intf4_blacklist },
> + /* Quectel products using Quectel vendor ID */
> + { USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC21),
> +   .driver_info = (kernel_ulong_t)_intf4_blacklist },
> + { USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC25),
> .driver_info = (kernel_ulong_t)_intf4_blacklist },
>   { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) },
>   { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CMU_300) },

--
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 v4 0/3] Add EHCI support for Armada 37xx

[Gregory CLEMENT]

Hi,

The EHCI controller in the Armada 37xx SoCs is the one used on many
other mvebu SoCs such as the orion5x, the kirkwood, or the
armada. However, for Armada 37xx an extra initialization step is
needed: this is the purpose of the first patch.

The second patch allows to build the driver for the ARM64 Armada SoCs.

The last one enables the EHCI in the device tree.

This forth version really takes into account the review from Alan Stern.
Again sorry for the noise.

Thanks,

Gregory

Changelog:
v3-> v4:
- Remove the _SHIFT define and use their value directly, suggested by
  Alan Stern
- Remove unnecessary error message in ehci_orion_drv_reset() ,
  suggested by Alan Stern
- Exit ehci_orion_drv_reset() if ehci_setup() failed, suggested by
  Alan Stern

v2-> v3:
- Add Reviewed-by flag from  Andrew Lunn

v1 -> v2:
- Fix typo in commit log of the patch 1, suggested by Andrew Lunn
- Fix wording in the device tree binding documenation, suggested by
  Andrew Lunn
- Make new define symbol name more clear by adding _SHIFT to the end,
  suggested by Andrew Lunn
- Use a full first name + last name for the Signed-off-by and the
  Authorship i oatch 1, suggested by Thomas Petazzoni.
- Improve the commit log of the patch 2, suggested by Andrew Lunn
- Fix Kconfig logic, suggested by Andrew Lunn

Gregory CLEMENT (2):
  usb: host: Allow to build ehci orion with mvebu SoCs
  ARM64: dts: marvell: armada-37xx: Add USB2 node

Hua Jing (1):
  usb: orion-echi: Add support for the Armada 3700

 .../devicetree/bindings/usb/ehci-orion.txt |  4 ++-
 arch/arm64/boot/dts/marvell/armada-3720-db.dts |  6 
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi   |  7 +
 drivers/usb/host/Kconfig   |  2 +-
 drivers/usb/host/ehci-orion.c  | 36 ++
 5 files changed, 53 insertions(+), 2 deletions(-)

-- 
2.11.0

--
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 v4 1/3] usb: orion-echi: Add support for the Armada 3700

[Gregory CLEMENT]

From: Hua Jing 

- Add a new compatible string for the Armada 3700 SoCs

- add sbuscfg support for orion usb controller driver. For the SoCs
  without hlock, need to program BAWR/BARD/AHBBRST fields in the sbuscfg
  register to guarantee the AHB master's burst would not overrun or
  underrun the FIFO.

- the sbuscfg register has to be set after the usb controller reset,
  otherwise the value would be overridden to 0. In order to do this, the
  reset callback is registered.

[gregory.clem...@free-electrons.com: - reword commit and comments
 - fix error path in ehci_orion_drv_reset()
 - fix checkpatch warning]
Signed-off-by: Hua Jing 
Signed-off-by: Gregory CLEMENT 
Reviewed-by: Andrew Lunn 
---
 .../devicetree/bindings/usb/ehci-orion.txt |  4 ++-
 drivers/usb/host/ehci-orion.c  | 36 ++
 2 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/ehci-orion.txt 
b/Documentation/devicetree/bindings/usb/ehci-orion.txt
index 17c3bc858b86..2855bae79fda 100644
--- a/Documentation/devicetree/bindings/usb/ehci-orion.txt
+++ b/Documentation/devicetree/bindings/usb/ehci-orion.txt
@@ -1,7 +1,9 @@
 * EHCI controller, Orion Marvell variants
 
 Required properties:
-- compatible: must be "marvell,orion-ehci"
+- compatible: must be one of the following
+   "marvell,orion-ehci"
+   "marvell,armada-3700-ehci"
 - reg: physical base address of the controller and length of memory mapped
   region.
 - interrupts: The EHCI interrupt
diff --git a/drivers/usb/host/ehci-orion.c b/drivers/usb/host/ehci-orion.c
index ee8d5faa0194..1aec87ec68df 100644
--- a/drivers/usb/host/ehci-orion.c
+++ b/drivers/usb/host/ehci-orion.c
@@ -47,6 +47,18 @@
 #define USB_PHY_IVREF_CTRL 0x440
 #define USB_PHY_TST_GRP_CTRL   0x450
 
+#define USB_SBUSCFG0x90
+
+/* BAWR = BARD = 3 : Align read/write bursts packets larger than 128 bytes */
+#define USB_SBUSCFG_BAWR_ALIGN_128B(0x3 << 6)
+#define USB_SBUSCFG_BARD_ALIGN_128B(0x3 << 3)
+/* AHBBRST = 3: Align AHB Burst to INCR16 (64 bytes) */
+#define USB_SBUSCFG_AHBBRST_INCR16 (0x3 << 0)
+
+#define USB_SBUSCFG_DEF_VAL (USB_SBUSCFG_BAWR_ALIGN_128B   \
+| USB_SBUSCFG_BARD_ALIGN_128B  \
+| USB_SBUSCFG_AHBBRST_INCR16)
+
 #define DRIVER_DESC "EHCI orion driver"
 
 #define hcd_to_orion_priv(h) ((struct orion_ehci_hcd *)hcd_to_ehci(h)->priv)
@@ -151,8 +163,31 @@ ehci_orion_conf_mbus_windows(struct usb_hcd *hcd,
}
 }
 
+static int ehci_orion_drv_reset(struct usb_hcd *hcd)
+{
+   struct device *dev = hcd->self.controller;
+   int ret;
+
+   ret = ehci_setup(hcd);
+   if (ret)
+   return ret;
+
+   /*
+* For SoC without hlock, need to program sbuscfg value to guarantee
+* AHB master's burst would not overrun or underrun FIFO.
+*
+* sbuscfg reg has to be set after usb controller reset, otherwise
+* the value would be override to 0.
+*/
+   if (of_device_is_compatible(dev->of_node, "marvell,armada-3700-ehci"))
+   wrl(USB_SBUSCFG, USB_SBUSCFG_DEF_VAL);
+
+   return ret;
+}
+
 static const struct ehci_driver_overrides orion_overrides __initconst = {
.extra_priv_size =  sizeof(struct orion_ehci_hcd),
+   .reset = ehci_orion_drv_reset,
 };
 
 static int ehci_orion_drv_probe(struct platform_device *pdev)
@@ -310,6 +345,7 @@ static int ehci_orion_drv_remove(struct platform_device 
*pdev)
 
 static const struct of_device_id ehci_orion_dt_ids[] = {
{ .compatible = "marvell,orion-ehci", },
+   { .compatible = "marvell,armada-3700-ehci", },
{},
 };
 MODULE_DEVICE_TABLE(of, ehci_orion_dt_ids);
-- 
2.11.0

--
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 v4 3/3] ARM64: dts: marvell: armada-37xx: Add USB2 node

[Gregory CLEMENT]

Armada 37xx SoC embedded an EHCI controller. This patch adds the device
tree node enabling its support.

Reviewed-by: Andrew Lunn 
Signed-off-by: Gregory CLEMENT 
---
 arch/arm64/boot/dts/marvell/armada-3720-db.dts | 6 ++
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi   | 7 +++
 2 files changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-3720-db.dts 
b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
index 864936acc316..aa39339b6582 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
@@ -134,6 +134,12 @@
status = "okay";
 };
 
+/* CON27 */
+ {
+   status = "okay";
+};
+
+
  {
status = "okay";
phy0: ethernet-phy@0 {
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi 
b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index cf0c2f9ebd7d..7639518d8ee1 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -204,6 +204,13 @@
status = "disabled";
};
 
+   usb2: usb@5e000 {
+   compatible = "marvell,armada-3700-ehci";
+   reg = <0x5e000 0x2000>;
+   interrupts = ;
+   status = "disabled";
+   };
+
xor@60900 {
compatible = "marvell,armada-3700-xor";
reg = <0x60900 0x100
-- 
2.11.0

--
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 v4 2/3] usb: host: Allow to build ehci orion with mvebu SoCs

[Gregory CLEMENT]

The mvebu ARM64 SoCs no longer select PLAT_ORION. However Armada 37xx use
the Orion EHCI controller. This patch allows the Orion EHCI driver to be
built when ARCH_MVEBU is selected.

Reviewed-by: Andrew Lunn 
Signed-off-by: Gregory CLEMENT 
---
 drivers/usb/host/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 407d947b34ea..54bdd76c7f03 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -188,7 +188,7 @@ config USB_EHCI_HCD_OMAP
 
 config USB_EHCI_HCD_ORION
tristate  "Support for Marvell EBU on-chip EHCI USB controller"
-   depends on USB_EHCI_HCD && PLAT_ORION
+   depends on USB_EHCI_HCD && (PLAT_ORION || ARCH_MVEBU)
default y
---help---
  Enables support for the on-chip EHCI controller on Marvell's
-- 
2.11.0

--
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 v3 0/3] Add EHCI support for Armada 37xx

[Gregory CLEMENT]

Hi,

The EHCI controller in the Armada 37xx SoCs is the one used on many
other mvebu SoCs such as the orion5x, the kirkwood, or the
armada. However, for Armada 37xx an extra initialization step is
needed: this is the purpose of the first patch.

The second patch allows to build the driver for the ARM64 Armada SoCs.

The last one enables the EHCI in the device tree.

This third version takes into account the review from Alan Stern.

Thanks,

Gregory

Changelog:
v2-> v3:
- Remove the _SHIFT define and use their value directly, suggested by
  Alan Stern
- Remove unnecessary error message in ehci_orion_drv_reset() ,
  suggested by Alan Stern
- Exit ehci_orion_drv_reset() if ehci_setup() failed, suggested by
  Alan Stern
- Add Reviewed-by flag from  Andrew Lunn

v1 -> v2:
- Fix typo in commit log of the patch 1, suggested by Andrew Lunn
- Fix wording in the device tree binding documenation, suggested by
  Andrew Lunn
- Make new define symbol name more clear by adding _SHIFT to the end,
  suggested by Andrew Lunn
- Use a full first name + last name for the Signed-off-by and the
  Authorship i oatch 1, suggested by Thomas Petazzoni.
- Improve the commit log of the patch 2, suggested by Andrew Lunn
- Fix Kconfig logic, suggested by Andrew Lunn

Gregory CLEMENT (2):
  usb: host: Allow to build ehci orion with mvebu SoCs
  ARM64: dts: marvell: armada-37xx: Add USB2 node

Hua Jing (1):
  usb: orion-echi: Add support for the Armada 3700

 .../devicetree/bindings/usb/ehci-orion.txt |  4 ++-
 arch/arm64/boot/dts/marvell/armada-3720-db.dts |  6 
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi   |  7 
 drivers/usb/host/Kconfig   |  2 +-
 drivers/usb/host/ehci-orion.c  | 39 ++
 5 files changed, 56 insertions(+), 2 deletions(-)

-- 
2.11.0

--
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 v3 3/3] ARM64: dts: marvell: armada-37xx: Add USB2 node

[Gregory CLEMENT]

Armada 37xx SoC embedded an EHCI controller. This patch adds the device
tree node enabling its support.

Reviewed-by: Andrew Lunn 
Signed-off-by: Gregory CLEMENT 
---
 arch/arm64/boot/dts/marvell/armada-3720-db.dts | 6 ++
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi   | 7 +++
 2 files changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-3720-db.dts 
b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
index 864936acc316..aa39339b6582 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
@@ -134,6 +134,12 @@
status = "okay";
 };
 
+/* CON27 */
+ {
+   status = "okay";
+};
+
+
  {
status = "okay";
phy0: ethernet-phy@0 {
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi 
b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index cf0c2f9ebd7d..7639518d8ee1 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -204,6 +204,13 @@
status = "disabled";
};
 
+   usb2: usb@5e000 {
+   compatible = "marvell,armada-3700-ehci";
+   reg = <0x5e000 0x2000>;
+   interrupts = ;
+   status = "disabled";
+   };
+
xor@60900 {
compatible = "marvell,armada-3700-xor";
reg = <0x60900 0x100
-- 
2.11.0

--
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 v3 1/3] usb: orion-echi: Add support for the Armada 3700

[Gregory CLEMENT]

From: Hua Jing 

- Add a new compatible string for the Armada 3700 SoCs

- add sbuscfg support for orion usb controller driver. For the SoCs
  without hlock, need to program BAWR/BARD/AHBBRST fields in the sbuscfg
  register to guarantee the AHB master's burst would not overrun or
  underrun the FIFO.

- the sbuscfg register has to be set after the usb controller reset,
  otherwise the value would be overridden to 0. In order to do this, the
  reset callback is registered.

[gregory.clem...@free-electrons.com: - reword commit and comments
 - fix checkpatch warning]
Signed-off-by: Hua Jing 
Signed-off-by: Gregory CLEMENT 
Reviewed-by: Andrew Lunn 
---
 .../devicetree/bindings/usb/ehci-orion.txt |  4 ++-
 drivers/usb/host/ehci-orion.c  | 39 ++
 2 files changed, 42 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/ehci-orion.txt 
b/Documentation/devicetree/bindings/usb/ehci-orion.txt
index 17c3bc858b86..2855bae79fda 100644
--- a/Documentation/devicetree/bindings/usb/ehci-orion.txt
+++ b/Documentation/devicetree/bindings/usb/ehci-orion.txt
@@ -1,7 +1,9 @@
 * EHCI controller, Orion Marvell variants
 
 Required properties:
-- compatible: must be "marvell,orion-ehci"
+- compatible: must be one of the following
+   "marvell,orion-ehci"
+   "marvell,armada-3700-ehci"
 - reg: physical base address of the controller and length of memory mapped
   region.
 - interrupts: The EHCI interrupt
diff --git a/drivers/usb/host/ehci-orion.c b/drivers/usb/host/ehci-orion.c
index ee8d5faa0194..762bba41e06d 100644
--- a/drivers/usb/host/ehci-orion.c
+++ b/drivers/usb/host/ehci-orion.c
@@ -47,6 +47,21 @@
 #define USB_PHY_IVREF_CTRL 0x440
 #define USB_PHY_TST_GRP_CTRL   0x450
 
+#define USB_SBUSCFG0x90
+#defineUSB_SBUSCFG_BAWR_SHIFT  0x6
+#defineUSB_SBUSCFG_BARD_SHIFT  0x3
+#defineUSB_SBUSCFG_AHBBRST_SHIFT   0x0
+
+/* BAWR = BARD = 3 : Align read/write bursts packets larger than 128 bytes */
+#define USB_SBUSCFG_BAWR_ALIGN_128B(0x3 << USB_SBUSCFG_BAWR_SHIFT)
+#define USB_SBUSCFG_BARD_ALIGN_128B(0x3 << USB_SBUSCFG_BARD_SHIFT)
+/* AHBBRST = 3: Align AHB Burst to INCR16 (64 bytes) */
+#define USB_SBUSCFG_AHBBRST_INCR16 (0x3 << USB_SBUSCFG_AHBBRST_SHIFT)
+
+#define USB_SBUSCFG_DEF_VAL (USB_SBUSCFG_BAWR_ALIGN_128B   \
+| USB_SBUSCFG_BARD_ALIGN_128B  \
+| USB_SBUSCFG_AHBBRST_INCR16)
+
 #define DRIVER_DESC "EHCI orion driver"
 
 #define hcd_to_orion_priv(h) ((struct orion_ehci_hcd *)hcd_to_ehci(h)->priv)
@@ -151,8 +166,31 @@ ehci_orion_conf_mbus_windows(struct usb_hcd *hcd,
}
 }
 
+static int ehci_orion_drv_reset(struct usb_hcd *hcd)
+{
+   struct device *dev = hcd->self.controller;
+   int retval;
+
+   retval = ehci_setup(hcd);
+   if (retval)
+   dev_err(dev, "ehci_setup failed %d\n", retval);
+
+   /*
+* For SoC without hlock, need to program sbuscfg value to guarantee
+* AHB master's burst would not overrun or underrun FIFO.
+*
+* sbuscfg reg has to be set after usb controller reset, otherwise
+* the value would be override to 0.
+*/
+   if (of_device_is_compatible(dev->of_node, "marvell,armada-3700-ehci"))
+   wrl(USB_SBUSCFG, USB_SBUSCFG_DEF_VAL);
+
+   return retval;
+}
+
 static const struct ehci_driver_overrides orion_overrides __initconst = {
.extra_priv_size =  sizeof(struct orion_ehci_hcd),
+   .reset = ehci_orion_drv_reset,
 };
 
 static int ehci_orion_drv_probe(struct platform_device *pdev)
@@ -310,6 +348,7 @@ static int ehci_orion_drv_remove(struct platform_device 
*pdev)
 
 static const struct of_device_id ehci_orion_dt_ids[] = {
{ .compatible = "marvell,orion-ehci", },
+   { .compatible = "marvell,armada-3700-ehci", },
{},
 };
 MODULE_DEVICE_TABLE(of, ehci_orion_dt_ids);
-- 
2.11.0

--
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 v3 2/3] usb: host: Allow to build ehci orion with mvebu SoCs

[Gregory CLEMENT]

The mvebu ARM64 SoCs no longer select PLAT_ORION. However Armada 37xx use
the Orion EHCI controller. This patch allows the Orion EHCI driver to be
built when ARCH_MVEBU is selected.

Reviewed-by: Andrew Lunn 
Signed-off-by: Gregory CLEMENT 
---
 drivers/usb/host/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 407d947b34ea..54bdd76c7f03 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -188,7 +188,7 @@ config USB_EHCI_HCD_OMAP
 
 config USB_EHCI_HCD_ORION
tristate  "Support for Marvell EBU on-chip EHCI USB controller"
-   depends on USB_EHCI_HCD && PLAT_ORION
+   depends on USB_EHCI_HCD && (PLAT_ORION || ARCH_MVEBU)
default y
---help---
  Enables support for the on-chip EHCI controller on Marvell's
-- 
2.11.0

--
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 v3 0/3] Add EHCI support for Armada 37xx

[Gregory CLEMENT]

Hi,
 
 On jeu., mars 09 2017, Gregory CLEMENT  
wrote:

> Hi,
>
> The EHCI controller in the Armada 37xx SoCs is the one used on many
> other mvebu SoCs such as the orion5x, the kirkwood, or the
> armada. However, for Armada 37xx an extra initialization step is
> needed: this is the purpose of the first patch.
>
> The second patch allows to build the driver for the ARM64 Armada SoCs.
>
> The last one enables the EHCI in the device tree.
>
> This third version takes into account the review from Alan Stern.
>
> Thanks,
>
> Gregory
>
> Changelog:
> v2-> v3:
> - Remove the _SHIFT define and use their value directly, suggested by
>   Alan Stern
> - Remove unnecessary error message in ehci_orion_drv_reset() ,
>   suggested by Alan Stern
> - Exit ehci_orion_drv_reset() if ehci_setup() failed, suggested by
>   Alan Stern

All the above changes are not in the series I've just sent. I will send
the correct series in a few minutes

sorry for the noise!

Gregory

> - Add Reviewed-by flag from  Andrew Lunn
>
> v1 -> v2:
> - Fix typo in commit log of the patch 1, suggested by Andrew Lunn
> - Fix wording in the device tree binding documenation, suggested by
>   Andrew Lunn
> - Make new define symbol name more clear by adding _SHIFT to the end,
>   suggested by Andrew Lunn
> - Use a full first name + last name for the Signed-off-by and the
>   Authorship i oatch 1, suggested by Thomas Petazzoni.
> - Improve the commit log of the patch 2, suggested by Andrew Lunn
> - Fix Kconfig logic, suggested by Andrew Lunn
>
> Gregory CLEMENT (2):
>   usb: host: Allow to build ehci orion with mvebu SoCs
>   ARM64: dts: marvell: armada-37xx: Add USB2 node
>
> Hua Jing (1):
>   usb: orion-echi: Add support for the Armada 3700
>
>  .../devicetree/bindings/usb/ehci-orion.txt |  4 ++-
>  arch/arm64/boot/dts/marvell/armada-3720-db.dts |  6 
>  arch/arm64/boot/dts/marvell/armada-37xx.dtsi   |  7 
>  drivers/usb/host/Kconfig   |  2 +-
>  drivers/usb/host/ehci-orion.c  | 39 
> ++
>  5 files changed, 56 insertions(+), 2 deletions(-)
>
> -- 
> 2.11.0
>

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
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] usb: gadget: udc: atmel: Remove an unused local variable

[Romain Izard]

The local variable ept_cfg is not used anymore in usba_ep_enable.
Use ep->ept_cfg in the debug function to remove a warning when building
with dynamic debug enabled.

Signed-off-by: Romain Izard 
Fixes: 741d2558bf0a ("usb: gadget: udc: atmel: Update endpoint allocation 
scheme")
---
 drivers/usb/gadget/udc/atmel_usba_udc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
b/drivers/usb/gadget/udc/atmel_usba_udc.c
index 11bbce28bc23..2035906b8ced 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -610,7 +610,7 @@ usba_ep_enable(struct usb_ep *_ep, const struct 
usb_endpoint_descriptor *desc)
 {
struct usba_ep *ep = to_usba_ep(_ep);
struct usba_udc *udc = ep->udc;
-   unsigned long flags, ept_cfg, maxpacket;
+   unsigned long flags, maxpacket;
unsigned int nr_trans;
 
DBG(DBG_GADGET, "%s: ep_enable: desc=%p\n", ep->ep.name, desc);
@@ -630,7 +630,7 @@ usba_ep_enable(struct usb_ep *_ep, const struct 
usb_endpoint_descriptor *desc)
ep->is_in = 0;
 
DBG(DBG_ERR, "%s: EPT_CFG = 0x%lx (maxpacket = %lu)\n",
-   ep->ep.name, ept_cfg, maxpacket);
+   ep->ep.name, ep->ept_cfg, maxpacket);
 
if (usb_endpoint_dir_in(desc)) {
ep->is_in = 1;
-- 
2.9.3

--
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] option: add Quectel UC15, UC20, EC21, and EC25 modems

[Dan Williams]

Add Quectel UC15, UC20, EC21, and EC25.  The EC20 is handled by
qcserial due to a USB VID/PID conflict with an existing Acer
device.

Signed-off-by: Dan Williams 
---
NOTE: The UC20, EC21, and EC25 should also get a corresponding qmi_wwan
patch but I don't have that lying around at this time.

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 9894e34..d4f36df 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -233,6 +233,14 @@ static void option_instat_callback(struct urb *urb);
 #define BANDRICH_PRODUCT_1012  0x1012
 
 #define QUALCOMM_VENDOR_ID 0x05C6
+/* These Quectel products use Qualcomm's vendor ID */
+#define QUECTEL_PRODUCT_UC15   0x9090
+#define QUECTEL_PRODUCT_UC20   0x9003
+
+#define QUECTEL_VENDOR_ID  0x2c7c
+/* These Quectel products use Quectel's vendor ID */
+#define QUECTEL_PRODUCT_EC21   0x0121
+#define QUECTEL_PRODUCT_EC25   0x0125
 
 #define CMOTECH_VENDOR_ID  0x16d8
 #define CMOTECH_PRODUCT_6001   0x6001
@@ -1159,7 +1167,14 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6613)}, /* Onda H600/ZTE MF330 */
{ USB_DEVICE(QUALCOMM_VENDOR_ID, 0x0023)}, /* ONYX 3G device */
{ USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000)}, /* SIMCom SIM5218 */
-   { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9003), /* Quectel UC20 */
+   /* Quectel products using Qualcomm vendor ID */
+   { USB_DEVICE(QUALCOMM_VENDOR_ID, QUECTEL_PRODUCT_UC15)},
+   { USB_DEVICE(QUALCOMM_VENDOR_ID, QUECTEL_PRODUCT_UC20),
+ .driver_info = (kernel_ulong_t)_intf4_blacklist },
+   /* Quectel products using Quectel vendor ID */
+   { USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC21),
+ .driver_info = (kernel_ulong_t)_intf4_blacklist },
+   { USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC25),
  .driver_info = (kernel_ulong_t)_intf4_blacklist },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CMU_300) },
--
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: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled

[Diego Viola]

On Thu, Mar 9, 2017 at 11:11 AM, Diego Viola  wrote:
> On Wed, Mar 8, 2017 at 5:40 PM, Diego Viola  wrote:
>> Hi Greg,
>>
>> On Wed, Mar 8, 2017 at 5:15 PM, Greg KH  wrote:
>>> On Wed, Mar 08, 2017 at 03:49:19PM -0300, Diego Viola wrote:
 It hangs on resume from suspend if I have USB 3.0 enabled on the BIOS,
 it works fine with ehci_hcd or USB 2.0.

 The way I reproduce the problem is with this command:

 $ i3lock && systemctl suspend

 This is what I see on the screen when it hangs:

 https://dl.dropboxusercontent.com/u/6005119/dell/IMG_20170308_095000.jpg
 https://dl.dropboxusercontent.com/u/6005119/dell/IMG_20170307_133928.jpg

 Some logs:

 https://dl.dropboxusercontent.com/u/6005119/dell/dmesg1.txt
 https://dl.dropboxusercontent.com/u/6005119/dell/dmesg2.txt

 I'm on Arch Linux x86_64, kernel 4.9.11-1-ARCH.

 I also tried Linux 4.10.1 and I could reproduce this problem there as well.

 Please let me know if I could provide more info.
>>>
>>> Has any previous kernel ever worked properly before?  If so, any chance
>>> you can use 'git bisect' to find the offending commit?
>>
>> I'm not sure, this is my work machine and I've only started using it
>> recently (since about a month ago or so).
>>
>> I will try older kernels and see if I get any different results, I
>> will report back in any case.
>>
>>>
>>> And are you sure you have updated your bios to the latest version?
>>
>> Yes.
>>
>>>
>>> thanks,
>>>
>>> greg k-h
>>
>> Thanks,
>> Diego
>
> I found another workaround, I can suspend/resume fine with `i3lock &&
> systemctl suspend` if I disconnect/unplug all my USB devices
> (keyboard, mouse, etc). This with the default settings in the BIOS
> (both USB 2.0 and 3.0 enabled).
>
> I'm also seeing some messages like this in dmesg:
>
> [   16.172190] usb 2-6: device descriptor read/64, error -110
>
> Would this indicate a hardware/firmware/power issue?
>
> Thanks,
> Diego

OK, I've built Linux 4.4.52 (I did a localmodconfig) and rebooted into
it, I did a suspend/resume and it hanged the first time I tried to
resume, which isn't much different than using the latest kernel.

My dmesg is still being spammed with these messages:

[  260.043673] usb 2-1: Device not responding to setup address.
[  260.246918] usb 2-1: device not accepting address 15, error -71
[  260.633662] usb 2-1: new high-speed USB device number 17 using xhci_hcd
[  261.341340] usb 2-1: USB disconnect, device number 17

I guess it's safe to assume at this point that this is a hardware problem?

Thanks,
Diego
--
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: Requeste to add Quectel EC21 in USB:serial:qcserial

[Dan Williams]

On Thu, 2017-03-09 at 10:28 +0100, Oliver Neukum wrote:
> Am Mittwoch, den 08.03.2017, 17:30 -0500 schrieb Balazs Harmath:
> > Hi guys,
> > 
> > I’w working with a Quectel EC21 modem and i ran into an issue that
> > the qcserial driver is not getting installed for it. 
> > Previously i was working with the Quectel EC20 which was working
> > properly but the cell carrier requested LTE Cat 1 modem so that’s
> > why
> > the switch to EC21.
> > 
> > Can you add the product ID for the Quectel EC21 in the qcserial.c ?
> > 
> > Thanks,
> > Bali
> > 
> > Below info for Quectel EC21
> > 
> > root@raspberrypi:~# uname -a
> > Linux raspberrypi 4.9.13-v7+ #974 SMP Wed Mar 1 20:09:48 GMT 2017
> > armv7l GNU/Linux
> > 
> > 
> > output for dmesg:
> > 
> > [7.575835] usb 1-1.4: new high-speed USB device number 7 using
> > dwc_otg
> > [7.715808] usb 1-1.4: New USB device found, idVendor=2c7c,
> > idProduct=0121
> > [7.715819] usb 1-1.4: New USB device strings: Mfr=1, Product=2,
> > SerialNumber=0
> > [7.715824] usb 1-1.4: Product: Android
> > [7.715827] usb 1-1.4: Manufacturer: Android
> > [7.728580] usbcore: registered new interface driver cdc_wdm
> > [7.735897] qmi_wwan 1-1.4:1.4: cdc-wdm0: USB WDM device
> > [7.737829] qmi_wwan 1-1.4:1.4 wwan0: register 'qmi_wwan' at
> > usb-
> > 3f98.usb-1.4, WWAN/QMI device, ce:db:66:0e:df:26
> > 
> > output for lsusb -t:
> > 
> > root@raspberrypi:~# lsusb -t
> > /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
> > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
> > |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/3p, 480M
> > |__ Port 1: Dev 5, If 0, Class=Vendor Specific Class,
> > Driver=smsc95xx, 480M
> > |__ Port 2: Dev 4, If 0, Class=Vendor Specific Class,
> > Driver=ftdi_sio, 12M
> > |__ Port 3: Dev 6, If 0, Class=Mass Storage, Driver=usb-
> > storage, 480M
> > |__ Port 4: Dev 7, If 1, Class=Vendor Specific Class,
> > Driver=, 480M
> > |__ Port 4: Dev 7, If 4, Class=Vendor Specific Class,
> > Driver=qmi_wwan, 480M
> 
> qmi_wwan is binding to this interface.
> 
> > |__ Port 4: Dev 7, If 2, Class=Vendor Specific Class,
> > Driver=, 480M
> > |__ Port 4: Dev 7, If 0, Class=Vendor Specific Class,
> > Driver=, 480M
> > |__ Port 4: Dev 7, If 3, Class=Vendor Specific Class,
> > Driver=, 480M
> 
> Do you need qcserial for these interfaces?

The only reason the EC20 is part of qcserial is because Quectel didn't
bother getting their own VID/PID for it, instead using an existing
Qualcomm one (05c6:9215) that was previously used by an Acer device. 
Gobi used to be mainly for devices that kept the same Gobi-type layout
(4 interfaces) and G1K/G2K devices that needed initial firmware upload.
 That distinction has been muddled recently though so I'm not sure it
matters much where they go.

Quectel recommends option for the UC15, UC20, EC20, EC25, and EC21.  I
don't think it makes much difference, except that the UC15 is an AT-
only device and should go into 'option'.  Might as well just put them
all there and blacklist the QMI interface (#4).

Dan
--
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 1/3] usb: orion-echi: Add support for the Armada 3700

[Gregory CLEMENT]

Hi Alan,
 
 On jeu., mars 09 2017, Alan Stern  wrote:

>> @@ -47,6 +47,21 @@
>>  #define USB_PHY_IVREF_CTRL  0x440
>>  #define USB_PHY_TST_GRP_CTRL0x450
>>  
>> +#define USB_SBUSCFG 0x90
>> +#define USB_SBUSCFG_BAWR_SHIFT  0x6
>> +#define USB_SBUSCFG_BARD_SHIFT  0x3
>> +#define USB_SBUSCFG_AHBBRST_SHIFT   0x0
>
> Shift amounts are just regular numbers.  Giving them in hex is 
> confusing because it leads people to think the bit pattern has some 
> particular significance, which it doesn't.  Which would you rather see: 
> (0x24 << 0x12) or (0x24 << 18)?

Right

>
>> +
>> +/* BAWR = BARD = 3 : Align read/write bursts packets larger than 128 bytes 
>> */
>> +#define USB_SBUSCFG_BAWR_ALIGN_128B (0x3 << USB_SBUSCFG_BAWR_SHIFT)
>> +#define USB_SBUSCFG_BARD_ALIGN_128B (0x3 << USB_SBUSCFG_BARD_SHIFT)
>> +/* AHBBRST = 3 : Align AHB Burst to INCR16 (64 bytes) */
>> +#define USB_SBUSCFG_AHBBRST_INCR16  (0x3 << USB_SBUSCFG_AHBBRST_SHIFT)
>
> Besides, since these shift amounts are each used only once, it would be
> simpler (and easier to read!) to do:
>
> +#define USB_SBUSCFG_BAWR_ALIGN_128B  (0x3 << 6)
> +#define USB_SBUSCFG_BARD_ALIGN_128B  (0x3 << 3)
> +/* AHBBRST = 3  : Align AHB Burst to INCR16 (64 bytes) */
> +#define USB_SBUSCFG_AHBBRST_INCR16   (0x3 << 0)
>

I think the intent was to document the register layout. But I have no
problem following your advice.

>
>> +
>> +#define USB_SBUSCFG_DEF_VAL (USB_SBUSCFG_BAWR_ALIGN_128B\
>> + | USB_SBUSCFG_BARD_ALIGN_128B  \
>> + | USB_SBUSCFG_AHBBRST_INCR16)
>> +
>>  #define DRIVER_DESC "EHCI orion driver"
>>  
>>  #define hcd_to_orion_priv(h) ((struct orion_ehci_hcd *)hcd_to_ehci(h)->priv)
>> @@ -151,8 +166,31 @@ ehci_orion_conf_mbus_windows(struct usb_hcd *hcd,
>>  }
>>  }
>>  
>> +static int ehci_orion_drv_reset(struct usb_hcd *hcd)
>> +{
>> +struct device *dev = hcd->self.controller;
>> +int retval;
>> +
>> +retval = ehci_setup(hcd);
>> +if (retval)
>> +dev_err(dev, "ehci_setup failed %d\n", retval);
>
> Was lack of this error message in the original driver a source of 
> problems?  If not, I submit that there's no good reason to add it.
>

I will remove the message and replace it by "return retval;" as
suggested below.

Thanks,

Gregory

>> +
>> +/*
>> + * For SoC without hlock, need to program sbuscfg value to guarantee
>> + * AHB master's burst would not overrun or underrun FIFO.
>> + *
>> + * sbuscfg reg has to be set after usb controller reset, otherwise
>> + * the value would be override to 0.
>> + */
>> +if (of_device_is_compatible(dev->of_node, "marvell,armada-3700-ehci"))
>> +wrl(USB_SBUSCFG, USB_SBUSCFG_DEF_VAL);
>
> Do you want to do this even when retval != 0?
>
> Alan Stern

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
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 1/3] usb: orion-echi: Add support for the Armada 3700

[Alan Stern]

On Thu, 9 Mar 2017, Gregory CLEMENT wrote:

> From: Hua Jing 
> 
> - Add a new compatible string for the Armada 3700 SoCs
> 
> - add sbuscfg support for orion usb controller driver. For the SoCs
>   without hlock, need to program BAWR/BARD/AHBBRST fields in the sbuscfg
>   register to guarantee the AHB master's burst would not overrun or
>   underrun the FIFO.
> 
> - the sbuscfg register has to be set after the usb controller reset,
>   otherwise the value would be overridden to 0. In order to do this, the
>   reset callback is registered.
> 
> [gregory.clem...@free-electrons.com: - reword commit and comments
>- fix checkpatch warning]
> Signed-off-by: Hua Jing 
> Signed-off-by: Gregory CLEMENT 
> ---
>  .../devicetree/bindings/usb/ehci-orion.txt |  4 ++-
>  drivers/usb/host/ehci-orion.c  | 39 
> ++
>  2 files changed, 42 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/ehci-orion.txt 
> b/Documentation/devicetree/bindings/usb/ehci-orion.txt
> index 17c3bc858b86..2855bae79fda 100644
> --- a/Documentation/devicetree/bindings/usb/ehci-orion.txt
> +++ b/Documentation/devicetree/bindings/usb/ehci-orion.txt
> @@ -1,7 +1,9 @@
>  * EHCI controller, Orion Marvell variants
>  
>  Required properties:
> -- compatible: must be "marvell,orion-ehci"
> +- compatible: must be one of the following
> + "marvell,orion-ehci"
> + "marvell,armada-3700-ehci"
>  - reg: physical base address of the controller and length of memory mapped
>region.
>  - interrupts: The EHCI interrupt
> diff --git a/drivers/usb/host/ehci-orion.c b/drivers/usb/host/ehci-orion.c
> index ee8d5faa0194..762bba41e06d 100644
> --- a/drivers/usb/host/ehci-orion.c
> +++ b/drivers/usb/host/ehci-orion.c
> @@ -47,6 +47,21 @@
>  #define USB_PHY_IVREF_CTRL   0x440
>  #define USB_PHY_TST_GRP_CTRL 0x450
>  
> +#define USB_SBUSCFG  0x90
> +#define  USB_SBUSCFG_BAWR_SHIFT  0x6
> +#define  USB_SBUSCFG_BARD_SHIFT  0x3
> +#define  USB_SBUSCFG_AHBBRST_SHIFT   0x0

Shift amounts are just regular numbers.  Giving them in hex is 
confusing because it leads people to think the bit pattern has some 
particular significance, which it doesn't.  Which would you rather see: 
(0x24 << 0x12) or (0x24 << 18)?

> +
> +/* BAWR = BARD = 3 : Align read/write bursts packets larger than 128 bytes */
> +#define USB_SBUSCFG_BAWR_ALIGN_128B  (0x3 << USB_SBUSCFG_BAWR_SHIFT)
> +#define USB_SBUSCFG_BARD_ALIGN_128B  (0x3 << USB_SBUSCFG_BARD_SHIFT)
> +/* AHBBRST = 3  : Align AHB Burst to INCR16 (64 bytes) */
> +#define USB_SBUSCFG_AHBBRST_INCR16   (0x3 << USB_SBUSCFG_AHBBRST_SHIFT)

Besides, since these shift amounts are each used only once, it would be
simpler (and easier to read!) to do:

+#define USB_SBUSCFG_BAWR_ALIGN_128B  (0x3 << 6)
+#define USB_SBUSCFG_BARD_ALIGN_128B  (0x3 << 3)
+/* AHBBRST = 3  : Align AHB Burst to INCR16 (64 bytes) */
+#define USB_SBUSCFG_AHBBRST_INCR16   (0x3 << 0)


> +
> +#define USB_SBUSCFG_DEF_VAL (USB_SBUSCFG_BAWR_ALIGN_128B \
> +  | USB_SBUSCFG_BARD_ALIGN_128B  \
> +  | USB_SBUSCFG_AHBBRST_INCR16)
> +
>  #define DRIVER_DESC "EHCI orion driver"
>  
>  #define hcd_to_orion_priv(h) ((struct orion_ehci_hcd *)hcd_to_ehci(h)->priv)
> @@ -151,8 +166,31 @@ ehci_orion_conf_mbus_windows(struct usb_hcd *hcd,
>   }
>  }
>  
> +static int ehci_orion_drv_reset(struct usb_hcd *hcd)
> +{
> + struct device *dev = hcd->self.controller;
> + int retval;
> +
> + retval = ehci_setup(hcd);
> + if (retval)
> + dev_err(dev, "ehci_setup failed %d\n", retval);

Was lack of this error message in the original driver a source of 
problems?  If not, I submit that there's no good reason to add it.

> +
> + /*
> +  * For SoC without hlock, need to program sbuscfg value to guarantee
> +  * AHB master's burst would not overrun or underrun FIFO.
> +  *
> +  * sbuscfg reg has to be set after usb controller reset, otherwise
> +  * the value would be override to 0.
> +  */
> + if (of_device_is_compatible(dev->of_node, "marvell,armada-3700-ehci"))
> + wrl(USB_SBUSCFG, USB_SBUSCFG_DEF_VAL);

Do you want to do this even when retval != 0?

Alan Stern

> +
> + return retval;
> +}
> +
>  static const struct ehci_driver_overrides orion_overrides __initconst = {
>   .extra_priv_size =  sizeof(struct orion_ehci_hcd),
> + .reset = ehci_orion_drv_reset,
>  };
>  
>  static int ehci_orion_drv_probe(struct platform_device *pdev)
> @@ -310,6 +348,7 @@ static int ehci_orion_drv_remove(struct platform_device 
> *pdev)
>  
>  static const struct of_device_id ehci_orion_dt_ids[] = {
>   { .compatible = "marvell,orion-ehci", },
> + { .compatible = "marvell,armada-3700-ehci", },
>   {},
>  

Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled

[Diego Viola]

On Wed, Mar 8, 2017 at 5:40 PM, Diego Viola  wrote:
> Hi Greg,
>
> On Wed, Mar 8, 2017 at 5:15 PM, Greg KH  wrote:
>> On Wed, Mar 08, 2017 at 03:49:19PM -0300, Diego Viola wrote:
>>> It hangs on resume from suspend if I have USB 3.0 enabled on the BIOS,
>>> it works fine with ehci_hcd or USB 2.0.
>>>
>>> The way I reproduce the problem is with this command:
>>>
>>> $ i3lock && systemctl suspend
>>>
>>> This is what I see on the screen when it hangs:
>>>
>>> https://dl.dropboxusercontent.com/u/6005119/dell/IMG_20170308_095000.jpg
>>> https://dl.dropboxusercontent.com/u/6005119/dell/IMG_20170307_133928.jpg
>>>
>>> Some logs:
>>>
>>> https://dl.dropboxusercontent.com/u/6005119/dell/dmesg1.txt
>>> https://dl.dropboxusercontent.com/u/6005119/dell/dmesg2.txt
>>>
>>> I'm on Arch Linux x86_64, kernel 4.9.11-1-ARCH.
>>>
>>> I also tried Linux 4.10.1 and I could reproduce this problem there as well.
>>>
>>> Please let me know if I could provide more info.
>>
>> Has any previous kernel ever worked properly before?  If so, any chance
>> you can use 'git bisect' to find the offending commit?
>
> I'm not sure, this is my work machine and I've only started using it
> recently (since about a month ago or so).
>
> I will try older kernels and see if I get any different results, I
> will report back in any case.
>
>>
>> And are you sure you have updated your bios to the latest version?
>
> Yes.
>
>>
>> thanks,
>>
>> greg k-h
>
> Thanks,
> Diego

I found another workaround, I can suspend/resume fine with `i3lock &&
systemctl suspend` if I disconnect/unplug all my USB devices
(keyboard, mouse, etc). This with the default settings in the BIOS
(both USB 2.0 and 3.0 enabled).

I'm also seeing some messages like this in dmesg:

[   16.172190] usb 2-6: device descriptor read/64, error -110

Would this indicate a hardware/firmware/power issue?

Thanks,
Diego
--
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] usb: gadget: legacy gadgets are optional

[Romain Izard]

With commit "usb: gadget: don't couple configfs to legacy gadgets"
it is possible to build a modular kernel with both built-in configfs
support and modular legacy gadget drivers.

But when building a kernel without modules, it is also necessary to be
able to build with configfs but without any legacy gadget driver.

Mark the choice for legacy gadget drivers as optional.

Fixes: bc49d1d17dcf ("usb: gadget: don't couple configfs to legacy gadgets")
Cc:  # 4.9+
Signed-off-by: Romain Izard 
---
changes in v2:
 - Reword description

 drivers/usb/gadget/Kconfig | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 8ad203296079..e157e9aa4f3d 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -212,7 +212,7 @@ config USB_F_TCM
 # this first set of drivers all depend on bulk-capable hardware.
 
 config USB_CONFIGFS
-   tristate "USB functions configurable through configfs"
+   tristate "USB Gadget functions configurable through configfs"
select USB_LIBCOMPOSITE
help
  A Linux USB "gadget" can be set up through configfs.
@@ -458,8 +458,9 @@ config USB_CONFIGFS_F_TCM
  UAS utilizes the USB 3.0 feature called streams support.
 
 choice
-   tristate "USB Gadget Drivers"
+   tristate "USB Gadget precomposed configurations"
default USB_ETH
+   optional
help
  A Linux "Gadget Driver" talks to the USB Peripheral Controller
  driver through the abstract "gadget" API.  Some other operating
@@ -476,6 +477,12 @@ choice
  not be able work with that controller, or might need to implement
  a less common variant of a device class protocol.
 
+ The available choices each represent a single precomposed USB
+ gadget configuration. In the device model, each option contains
+ both the device instanciation as a child for a USB gadget
+ controller, and the relevant drivers for each function declared
+ by the device.
+
 source "drivers/usb/gadget/legacy/Kconfig"
 
 endchoice
-- 
2.9.3

--
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/4] usb: host: xhci-plat: Fix timeout on removal of hot pluggable xhci controllers

[Mathias Nyman]

From: Guenter Roeck 

Upstream commit 98d74f9ceaef ("xhci: fix 10 second timeout on removal of
PCI hotpluggable xhci controllers") fixes a problem with hot pluggable PCI
xhci controllers which can result in excessive timeouts, to the point where
the system reports a deadlock.

The same problem is seen with hot pluggable xhci controllers using the
xhci-plat driver, such as the driver used for Type-C ports on rk3399.
Similar to hot-pluggable PCI controllers, the driver for this chip
removes the xhci controller from the system when the Type-C cable is
disconnected.

The solution for PCI devices works just as well for non-PCI devices
and avoids the problem.

Signed-off-by: Guenter Roeck 
Cc: stable 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-plat.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 6d33b42..bd02a6c 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -286,6 +286,8 @@ static int xhci_plat_remove(struct platform_device *dev)
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct clk *clk = xhci->clk;
 
+   xhci->xhc_state |= XHCI_STATE_REMOVING;
+
usb_remove_hcd(xhci->shared_hcd);
usb_phy_shutdown(hcd->usb_phy);
 
-- 
1.9.1

--
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/4] usb: host: xhci-dbg: HCIVERSION should be a binary number

[Mathias Nyman]

From: Peter Chen 

According to xHCI spec, HCIVERSION containing a BCD encoding
of the xHCI specification revision number, 0100h corresponds
to xHCI version 1.0. Change "100" as "0x100".

Cc: Lu Baolu 
Cc: stable 
Fixes: 04abb6de2825 ("xhci: Read and parse new xhci
1.1 capability register")
Signed-off-by: Peter Chen 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-dbg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c
index 363d125..2b4a00f 100644
--- a/drivers/usb/host/xhci-dbg.c
+++ b/drivers/usb/host/xhci-dbg.c
@@ -109,7 +109,7 @@ static void xhci_print_cap_regs(struct xhci_hcd *xhci)
xhci_dbg(xhci, "RTSOFF 0x%x:\n", temp & RTSOFF_MASK);
 
/* xhci 1.1 controllers have the HCCPARAMS2 register */
-   if (hci_version > 100) {
+   if (hci_version > 0x100) {
temp = readl(>cap_regs->hcc_params2);
xhci_dbg(xhci, "HCC PARAMS2 0x%x:\n", (unsigned int) temp);
xhci_dbg(xhci, "  HC %s Force save context capability",
-- 
1.9.1

--
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/4] xhci fixes for usb-linus

[Mathias Nyman]

Hi Greg

A few small xhci fixes usb-linus 4.11-rc

-Mathias

Chunfeng Yun (2):
  usb: xhci-mtk: check hcc_params after adding primary hcd
  usb: xhci: remove dummy extra_priv_size for size of xhci_hcd struct

Guenter Roeck (1):
  usb: host: xhci-plat: Fix timeout on removal of hot pluggable xhci
controllers

Peter Chen (1):
  usb: host: xhci-dbg: HCIVERSION should be a binary number

 drivers/usb/host/xhci-dbg.c   | 2 +-
 drivers/usb/host/xhci-mtk.c   | 7 +++
 drivers/usb/host/xhci-plat.c  | 2 ++
 drivers/usb/host/xhci-tegra.c | 1 -
 4 files changed, 6 insertions(+), 6 deletions(-)

-- 
1.9.1

--
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 2/4] usb: xhci: remove dummy extra_priv_size for size of xhci_hcd struct

[Mathias Nyman]

From: Chunfeng Yun 

because hcd_priv_size is already size of xhci_hcd struct,
extra_priv_size is not needed anymore for MTK and tegra drivers.

Signed-off-by: Chunfeng Yun 
Tested-by: Thierry Reding 
Acked-by: Thierry Reding 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-mtk.c   | 1 -
 drivers/usb/host/xhci-tegra.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index 6ac73a6..67d5dc7 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -382,7 +382,6 @@ static int usb_wakeup_of_property_parse(struct xhci_hcd_mtk 
*mtk,
 
 static int xhci_mtk_setup(struct usb_hcd *hcd);
 static const struct xhci_driver_overrides xhci_mtk_overrides __initconst = {
-   .extra_priv_size = sizeof(struct xhci_hcd),
.reset = xhci_mtk_setup,
 };
 
diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
index a59fafb..74436f8 100644
--- a/drivers/usb/host/xhci-tegra.c
+++ b/drivers/usb/host/xhci-tegra.c
@@ -1308,7 +1308,6 @@ static int tegra_xhci_setup(struct usb_hcd *hcd)
 }
 
 static const struct xhci_driver_overrides tegra_xhci_overrides __initconst = {
-   .extra_priv_size = sizeof(struct xhci_hcd),
.reset = tegra_xhci_setup,
 };
 
-- 
1.9.1

--
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/4] usb: xhci-mtk: check hcc_params after adding primary hcd

[Mathias Nyman]

From: Chunfeng Yun 

hcc_params is set in xhci_gen_setup() called from usb_add_hcd(),
so checks the Maximum Primary Stream Array Size in the hcc_params
register after adding primary hcd.

Signed-off-by: Chunfeng Yun 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-mtk.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index 9066ec9..6ac73a6 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -678,13 +678,13 @@ static int xhci_mtk_probe(struct platform_device *pdev)
goto power_off_phys;
}
 
-   if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
-   xhci->shared_hcd->can_do_streams = 1;
-
ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (ret)
goto put_usb3_hcd;
 
+   if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
+   xhci->shared_hcd->can_do_streams = 1;
+
ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
if (ret)
goto dealloc_usb2_hcd;
-- 
1.9.1

--
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: hub: Fix crash after failure to read BOS descriptor

[Mathias Nyman]

On 08.03.2017 20:19, Guenter Roeck wrote:

If usb_get_bos_descriptor() returns an error, usb->bos will be NULL.
Nevertheless, it is dereferenced unconditionally in
hub_set_initial_usb2_lpm_policy() if usb2_hw_lpm_capable is set.
This results in a crash.

usb 5-1: unable to get BOS descriptor
...
Unable to handle kernel NULL pointer dereference at virtual address 0008
pgd = ffc00165f000
[0008] *pgd=0174f003, *pud=0174f003,
*pmd=01750003, *pte=00e801751713
Internal error: Oops: 9605 [#1] PREEMPT SMP
Modules linked in: uinput uvcvideo videobuf2_vmalloc cmac [ ... ]
CPU: 5 PID: 3353 Comm: kworker/5:3 Tainted: GB 4.4.52 #480
Hardware name: Google Kevin (DT)
Workqueue: events driver_set_config_work
task: ffc0c369 ti: ffc0ae9a8000 task.ti: ffc0ae9a8000
PC is at hub_port_init+0xc3c/0xd10
LR is at hub_port_init+0xc3c/0xd10
...
Call trace:
[] hub_port_init+0xc3c/0xd10
[] usb_reset_and_verify_device+0x15c/0x82c
[] usb_reset_device+0xe4/0x298
[] rtl8152_probe+0x84/0x9b0 [r8152]
[] usb_probe_interface+0x244/0x2f8
[] driver_probe_device+0x180/0x3b4
[] __device_attach_driver+0xb4/0xe0
[] bus_for_each_drv+0xb4/0xe4
[] __device_attach+0xd0/0x158
[] device_initial_probe+0x24/0x30
[] bus_probe_device+0x50/0xe4
[] device_add+0x414/0x738
[] usb_set_configuration+0x89c/0x914
[] driver_set_config_work+0xc0/0xf0
[] process_one_work+0x390/0x6b8
[] worker_thread+0x480/0x610
[] kthread+0x164/0x178
[] ret_from_fork+0x10/0x40

Since we don't know anything about LPM capabilities without BOS descriptor,
don't attempt to enable LPM if it is not available.

Fixes: 890dae886721 ("xhci: Enable LPM support only for hardwired ...")
Cc: Mathias Nyman 
Signed-off-by: Guenter Roeck 
---


Acked-by: Mathias Nyman 


--
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 0/3] Add EHCI support for Armada 37xx

[Andrew Lunn]

On Thu, Mar 09, 2017 at 12:04:21PM +0100, Gregory CLEMENT wrote:
> Hi,
> 
> The EHCI controller in the Armada 37xx SoCs is the one used on many
> other mvebu SoCs such as the orion5x, the kirkwood, or the
> armada. However, for Armada 37xx an extra initialization step is
> needed: this is the purpose of the first patch.
> 
> The second patch allows to build the driver for the ARM64 Armada SoCs.
> 
> The last one enables the EHCI in the device tree.
> 
> This second version takes into account the review from Andrew Lunn and
> Thomas Petazzoni.

Hi Gregory

Thanks for making the changes.

Reviewed-by: Andrew Lunn 

Andrew
--
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: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[Ajay Kaher]

From febeb10887d5026a489658fd9e911656e76038ac Mon Sep 17 00:00:00 2001
From: Ajay Kaher 
Date: Thu, 9 Mar 2017 16:07:54 +0530
Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when two
 USB class drivers try to call init_usb_class simultaneously

There is race condition when two USB class drivers try to call
init_usb_class at the same time and leads to crash.
code path: probe->usb_register_dev->init_usb_class
 
To solve this, mutex locking has been added in init_usb_class() and 
destroy_usb_class().

As pointed by Alan, removed "if (usb_class)" test from destroy_usb_class()
because usb_class can never be NULL there.

Signed-off-by: Ajay Kaher 
Acked-by: Alan Stern 
---
 drivers/usb/core/file.c |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/core/file.c b/drivers/usb/core/file.c
index 822ced9..422ce7b 100644
--- a/drivers/usb/core/file.c
+++ b/drivers/usb/core/file.c
@@ -27,6 +27,7 @@
 #define MAX_USB_MINORS 256
 static const struct file_operations *usb_minors[MAX_USB_MINORS];
 static DECLARE_RWSEM(minor_rwsem);
+static DEFINE_MUTEX(init_usb_class_mutex);

 static int usb_open(struct inode *inode, struct file *file)
 {
@@ -109,8 +110,9 @@ static void release_usb_class(struct kref *kref)

 static void destroy_usb_class(void)
 {
- if (usb_class)
-  kref_put(_class->kref, release_usb_class);
+ mutex_lock(_usb_class_mutex);
+ kref_put(_class->kref, release_usb_class);
+ mutex_unlock(_usb_class_mutex);
 }

 int usb_major_init(void)
@@ -171,7 +173,10 @@ int usb_register_dev(struct usb_interface *intf,
  if (intf->minor >= 0)
   return -EADDRINUSE;

+ mutex_lock(_usb_class_mutex);
  retval = init_usb_class();
+ mutex_unlock(_usb_class_mutex);
+
  if (retval)
   return retval;

--
1.7.9.5

Re: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[gre...@linuxfoundation.org]

On Thu, Mar 09, 2017 at 11:34:25AM +, Ajay Kaher wrote:
> From febeb10887d5026a489658fd9e911656e76038ac Mon Sep 17 00:00:00 2001
> From: Ajay Kaher 
> Date: Thu, 9 Mar 2017 16:07:54 +0530
> Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when 
> two
>  USB class drivers try to call init_usb_class simultaneously

Why is your subject line have the word "subject" in it?

Please fix your email client so you don't have the whole git commit
header in the body of the email like you do here.

Also, no need to say "Core:" or "BugFix:"

> 
> There is race condition when two USB class drivers try to call
> init_usb_class at the same time and leads to crash.
> code path: probe->usb_register_dev->init_usb_class
>  
> To solve this, mutex locking has been added in init_usb_class() and 
> destroy_usb_class().
> 
> As pointed by Alan, removed "if (usb_class)" test from destroy_usb_class()
> because usb_class can never be NULL there.
> 
> Signed-off-by: Ajay Kaher 
> Acked-by: Alan Stern 
> ---
>  drivers/usb/core/file.c |9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/core/file.c b/drivers/usb/core/file.c
> index 822ced9..422ce7b 100644
> --- a/drivers/usb/core/file.c
> +++ b/drivers/usb/core/file.c
> @@ -27,6 +27,7 @@
>  #define MAX_USB_MINORS 256
>  static const struct file_operations *usb_minors[MAX_USB_MINORS];
>  static DECLARE_RWSEM(minor_rwsem);
> +static DEFINE_MUTEX(init_usb_class_mutex);
> 
>  static int usb_open(struct inode *inode, struct file *file)
>  {
> @@ -109,8 +110,9 @@ static void release_usb_class(struct kref *kref)
> 
>  static void destroy_usb_class(void)
>  {
> - if (usb_class)
> -  kref_put(_class->kref, release_usb_class);
> + mutex_lock(_usb_class_mutex);
> + kref_put(_class->kref, release_usb_class);
> + mutex_unlock(_usb_class_mutex);
>  }
> 
>  int usb_major_init(void)
> @@ -171,7 +173,10 @@ int usb_register_dev(struct usb_interface *intf,
>   if (intf->minor >= 0)
>return -EADDRINUSE;
> 
> + mutex_lock(_usb_class_mutex);
>   retval = init_usb_class();
> + mutex_unlock(_usb_class_mutex);
> +
>   if (retval)
>return retval;
> 

All tabs were turned into spaces and this patch can not be applied :(

Please fix up and try again.  Send a patch to yourself first to see if
it works properly before sending it to us.

greg k-h
--
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 v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Baolin Wang]

On 9 March 2017 at 18:34, Jun Li  wrote:
>
>
>> -Original Message-
>> From: Baolin Wang [mailto:baolin.w...@linaro.org]
>> Sent: Thursday, March 09, 2017 2:11 PM
>> To: Jun Li 
>> Cc: NeilBrown ; Felipe Balbi ; Greg KH
>> ; Sebastian Reichel ; Dmitry
>> Eremin-Solenikov ; David Woodhouse
>> ; r...@kernel.org; Marek Szyprowski
>> ; Ruslan Bilovol ;
>> Peter Chen ; Alan Stern
>> ; grygorii.stras...@ti.com; Yoshihiro Shimoda
>> ; Lee Jones ;
>> Mark Brown ; John Stultz ;
>> Charles Keepax ;
>> patc...@opensource.wolfsonmicro.com; Linux PM list > p...@vger.kernel.org>; USB ; device-
>> mainlin...@lists.linuxfoundation.org; LKML 
>> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
>> the usb gadget power negotation
>>
>> Hi,
>>
>> On 9 March 2017 at 09:50, Jun Li  wrote:
>> > Hi,
>> >
>> >> -Original Message-
>> >> From: Baolin Wang [mailto:baolin.w...@linaro.org]
>> >> Sent: Tuesday, March 07, 2017 5:39 PM
>> >> To: NeilBrown 
>> >> Cc: Felipe Balbi ; Greg KH
>> >> ; Sebastian Reichel ;
>> >> Dmitry Eremin-Solenikov ; David Woodhouse
>> >> ; r...@kernel.org; Jun Li ;
>> >> Marek Szyprowski ; Ruslan Bilovol
>> >> ; Peter Chen ;
>> >> Alan Stern ; grygorii.stras...@ti.com;
>> >> Yoshihiro Shimoda ; Lee Jones
>> >> ; Mark Brown ; John Stultz
>> >> ; Charles Keepax
>> >> ;
>> >> patc...@opensource.wolfsonmicro.com; Linux PM list > >> p...@vger.kernel.org>; USB ; device-
>> >> mainlin...@lists.linuxfoundation.org; LKML
>> >> 
>> >> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal
>> >> with the usb gadget power negotation
>> >>
>> >> On 3 March 2017 at 10:23, NeilBrown  wrote:
>> >> > On Mon, Feb 20 2017, Baolin Wang wrote:
>> >> >
>> >> >> Currently the Linux kernel does not provide any standard
>> >> >> integration of this feature that integrates the USB subsystem with
>> >> >> the system power regulation provided by PMICs meaning that either
>> >> >> vendors must add this in their kernels or USB gadget devices based
>> >> >> on Linux (such as mobile phones) may not behave as they should.
>> >> >> Thus provide a
>> >> standard framework for doing this in kernel.
>> >> >>
>> >> >> Now introduce one user with wm831x_power to support and test the
>> >> >> usb
>> >> charger.
>> >> >> Another user introduced to support charger detection by Jun Li:
>> >> >> https://www.spinics.net/lists/linux-usb/msg139425.html
>> >> >> Moreover there may be other potential users will use it in future.
>> >> >>
>> >> >> 1. Before v19 patchset we've fixed below issues in extcon
>> >> >> subsystem and usb phy driver, now all were merged. (Thanks for
>> >> >> Neil's
>> >> >> suggestion)
>> >> >> (1) Have fixed the inconsistencies with USB connector types in
>> >> >> extcon subsystem by following links:
>> >> >> https://lkml.org/lkml/2016/12/21/13
>> >> >> https://lkml.org/lkml/2016/12/21/15
>> >> >> https://lkml.org/lkml/2016/12/21/79
>> >> >> https://lkml.org/lkml/2017/1/3/13
>> >> >>
>> >> >> (2) Instead of using 'set_power' callback in phy drivers, we will
>> >> >> introduce USB charger to set PMIC current drawn from USB
>> >> >> configuration, moreover some 'set_power' callbacks did not
>> >> >> implement anything to set PMIC current, thus remove them by
>> following links:
>> >> >> https://lkml.org/lkml/2017/1/18/436
>> >> >> https://lkml.org/lkml/2017/1/18/439
>> >> >> https://lkml.org/lkml/2017/1/18/438
>> >> >> Now only two phy drivers (phy-isp1301-omap.c and
>> >> >> phy-gpio-vbus-usb.c) still used 'set_power' callback to set
>> >> >> current, we can remove them in future. (I have no platform with
>> >> >> enabling these two phy drivers, so I can not test them if I
>> >> >> converted 'set_power' callback to USB
>> >> >> charger.)
>> >> >>
>> >> >> 2. Some issues pointed by Neil Brown were sill kept in this v19
>> >> >> patchset, and I expalined each issue and may be need discuss again:
>> >> >> (1) Change all usb phys to register an extcon and to send
>> >> >> appropriate
>> >> notifications.
>> >> >> Firstly, now only 3 USB phy drivers (phy-qcom-8x16-usb.c,
>> >> 

[PATCH v2 2/3] usb: host: Allow to build ehci orion with mvebu SoCs

[Gregory CLEMENT]

The mvebu ARM64 SoCs no longer select PLAT_ORION. However Armada 37xx use
the Orion EHCI controller. This patch allows the Orion EHCI driver to be
built when ARCH_MVEBU is selected.

Signed-off-by: Gregory CLEMENT 
---
 drivers/usb/host/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 407d947b34ea..54bdd76c7f03 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -188,7 +188,7 @@ config USB_EHCI_HCD_OMAP
 
 config USB_EHCI_HCD_ORION
tristate  "Support for Marvell EBU on-chip EHCI USB controller"
-   depends on USB_EHCI_HCD && PLAT_ORION
+   depends on USB_EHCI_HCD && (PLAT_ORION || ARCH_MVEBU)
default y
---help---
  Enables support for the on-chip EHCI controller on Marvell's
-- 
2.11.0

--
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 1/3] usb: orion-echi: Add support for the Armada 3700

[Gregory CLEMENT]

From: Hua Jing 

- Add a new compatible string for the Armada 3700 SoCs

- add sbuscfg support for orion usb controller driver. For the SoCs
  without hlock, need to program BAWR/BARD/AHBBRST fields in the sbuscfg
  register to guarantee the AHB master's burst would not overrun or
  underrun the FIFO.

- the sbuscfg register has to be set after the usb controller reset,
  otherwise the value would be overridden to 0. In order to do this, the
  reset callback is registered.

[gregory.clem...@free-electrons.com: - reword commit and comments
 - fix checkpatch warning]
Signed-off-by: Hua Jing 
Signed-off-by: Gregory CLEMENT 
---
 .../devicetree/bindings/usb/ehci-orion.txt |  4 ++-
 drivers/usb/host/ehci-orion.c  | 39 ++
 2 files changed, 42 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/ehci-orion.txt 
b/Documentation/devicetree/bindings/usb/ehci-orion.txt
index 17c3bc858b86..2855bae79fda 100644
--- a/Documentation/devicetree/bindings/usb/ehci-orion.txt
+++ b/Documentation/devicetree/bindings/usb/ehci-orion.txt
@@ -1,7 +1,9 @@
 * EHCI controller, Orion Marvell variants
 
 Required properties:
-- compatible: must be "marvell,orion-ehci"
+- compatible: must be one of the following
+   "marvell,orion-ehci"
+   "marvell,armada-3700-ehci"
 - reg: physical base address of the controller and length of memory mapped
   region.
 - interrupts: The EHCI interrupt
diff --git a/drivers/usb/host/ehci-orion.c b/drivers/usb/host/ehci-orion.c
index ee8d5faa0194..762bba41e06d 100644
--- a/drivers/usb/host/ehci-orion.c
+++ b/drivers/usb/host/ehci-orion.c
@@ -47,6 +47,21 @@
 #define USB_PHY_IVREF_CTRL 0x440
 #define USB_PHY_TST_GRP_CTRL   0x450
 
+#define USB_SBUSCFG0x90
+#defineUSB_SBUSCFG_BAWR_SHIFT  0x6
+#defineUSB_SBUSCFG_BARD_SHIFT  0x3
+#defineUSB_SBUSCFG_AHBBRST_SHIFT   0x0
+
+/* BAWR = BARD = 3 : Align read/write bursts packets larger than 128 bytes */
+#define USB_SBUSCFG_BAWR_ALIGN_128B(0x3 << USB_SBUSCFG_BAWR_SHIFT)
+#define USB_SBUSCFG_BARD_ALIGN_128B(0x3 << USB_SBUSCFG_BARD_SHIFT)
+/* AHBBRST = 3: Align AHB Burst to INCR16 (64 bytes) */
+#define USB_SBUSCFG_AHBBRST_INCR16 (0x3 << USB_SBUSCFG_AHBBRST_SHIFT)
+
+#define USB_SBUSCFG_DEF_VAL (USB_SBUSCFG_BAWR_ALIGN_128B   \
+| USB_SBUSCFG_BARD_ALIGN_128B  \
+| USB_SBUSCFG_AHBBRST_INCR16)
+
 #define DRIVER_DESC "EHCI orion driver"
 
 #define hcd_to_orion_priv(h) ((struct orion_ehci_hcd *)hcd_to_ehci(h)->priv)
@@ -151,8 +166,31 @@ ehci_orion_conf_mbus_windows(struct usb_hcd *hcd,
}
 }
 
+static int ehci_orion_drv_reset(struct usb_hcd *hcd)
+{
+   struct device *dev = hcd->self.controller;
+   int retval;
+
+   retval = ehci_setup(hcd);
+   if (retval)
+   dev_err(dev, "ehci_setup failed %d\n", retval);
+
+   /*
+* For SoC without hlock, need to program sbuscfg value to guarantee
+* AHB master's burst would not overrun or underrun FIFO.
+*
+* sbuscfg reg has to be set after usb controller reset, otherwise
+* the value would be override to 0.
+*/
+   if (of_device_is_compatible(dev->of_node, "marvell,armada-3700-ehci"))
+   wrl(USB_SBUSCFG, USB_SBUSCFG_DEF_VAL);
+
+   return retval;
+}
+
 static const struct ehci_driver_overrides orion_overrides __initconst = {
.extra_priv_size =  sizeof(struct orion_ehci_hcd),
+   .reset = ehci_orion_drv_reset,
 };
 
 static int ehci_orion_drv_probe(struct platform_device *pdev)
@@ -310,6 +348,7 @@ static int ehci_orion_drv_remove(struct platform_device 
*pdev)
 
 static const struct of_device_id ehci_orion_dt_ids[] = {
{ .compatible = "marvell,orion-ehci", },
+   { .compatible = "marvell,armada-3700-ehci", },
{},
 };
 MODULE_DEVICE_TABLE(of, ehci_orion_dt_ids);
-- 
2.11.0

--
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 0/3] Add EHCI support for Armada 37xx

[Gregory CLEMENT]

Hi,

The EHCI controller in the Armada 37xx SoCs is the one used on many
other mvebu SoCs such as the orion5x, the kirkwood, or the
armada. However, for Armada 37xx an extra initialization step is
needed: this is the purpose of the first patch.

The second patch allows to build the driver for the ARM64 Armada SoCs.

The last one enables the EHCI in the device tree.

This second version takes into account the review from Andrew Lunn and
Thomas Petazzoni.

Thanks,

Gregory

Changelog:
v1 -> v2:
- Fix typo in commit log of the patch 1, suggested by Andrew Lunn
- Fix wording in the device tree binding documenation, suggested by
  Andrew Lunn
- Make new define symbol name more clear by adding _SHIFT to the end,
  suggested by Andrew Lunn
- Use a full first name + last name for the Signed-off-by and the
  Authorship i oatch 1, suggested by Thomas Petazzoni.
- Improve the commit log of the patch 2, suggested by Andrew Lunn
- Fix Kconfig logic, suggested by Andrew Lunn

Gregory CLEMENT (2):
  usb: host: Allow to build ehci orion with mvebu SoCs
  ARM64: dts: marvell: armada-37xx: Add USB2 node

Hua Jing (1):
  usb: orion-echi: Add support for the Armada 3700

 .../devicetree/bindings/usb/ehci-orion.txt |  4 ++-
 arch/arm64/boot/dts/marvell/armada-3720-db.dts |  6 
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi   |  7 
 drivers/usb/host/Kconfig   |  2 +-
 drivers/usb/host/ehci-orion.c  | 39 ++
 5 files changed, 56 insertions(+), 2 deletions(-)

-- 
2.11.0

--
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 3/3] ARM64: dts: marvell: armada-37xx: Add USB2 node

[Gregory CLEMENT]

Armada 37xx SoC embedded an EHCI controller. This patch adds the device
tree node enabling its support.

Signed-off-by: Gregory CLEMENT 
---
 arch/arm64/boot/dts/marvell/armada-3720-db.dts | 6 ++
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi   | 7 +++
 2 files changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-3720-db.dts 
b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
index 864936acc316..aa39339b6582 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
@@ -134,6 +134,12 @@
status = "okay";
 };
 
+/* CON27 */
+ {
+   status = "okay";
+};
+
+
  {
status = "okay";
phy0: ethernet-phy@0 {
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi 
b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index cf0c2f9ebd7d..7639518d8ee1 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -204,6 +204,13 @@
status = "disabled";
};
 
+   usb2: usb@5e000 {
+   compatible = "marvell,armada-3700-ehci";
+   reg = <0x5e000 0x2000>;
+   interrupts = ;
+   status = "disabled";
+   };
+
xor@60900 {
compatible = "marvell,armada-3700-xor";
reg = <0x60900 0x100
-- 
2.11.0

--
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 v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Jun Li]

> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Thursday, March 09, 2017 2:11 PM
> To: Jun Li 
> Cc: NeilBrown ; Felipe Balbi ; Greg KH
> ; Sebastian Reichel ; Dmitry
> Eremin-Solenikov ; David Woodhouse
> ; r...@kernel.org; Marek Szyprowski
> ; Ruslan Bilovol ;
> Peter Chen ; Alan Stern
> ; grygorii.stras...@ti.com; Yoshihiro Shimoda
> ; Lee Jones ;
> Mark Brown ; John Stultz ;
> Charles Keepax ;
> patc...@opensource.wolfsonmicro.com; Linux PM list  p...@vger.kernel.org>; USB ; device-
> mainlin...@lists.linuxfoundation.org; LKML 
> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
> 
> Hi,
> 
> On 9 March 2017 at 09:50, Jun Li  wrote:
> > Hi,
> >
> >> -Original Message-
> >> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> >> Sent: Tuesday, March 07, 2017 5:39 PM
> >> To: NeilBrown 
> >> Cc: Felipe Balbi ; Greg KH
> >> ; Sebastian Reichel ;
> >> Dmitry Eremin-Solenikov ; David Woodhouse
> >> ; r...@kernel.org; Jun Li ;
> >> Marek Szyprowski ; Ruslan Bilovol
> >> ; Peter Chen ;
> >> Alan Stern ; grygorii.stras...@ti.com;
> >> Yoshihiro Shimoda ; Lee Jones
> >> ; Mark Brown ; John Stultz
> >> ; Charles Keepax
> >> ;
> >> patc...@opensource.wolfsonmicro.com; Linux PM list  >> p...@vger.kernel.org>; USB ; device-
> >> mainlin...@lists.linuxfoundation.org; LKML
> >> 
> >> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal
> >> with the usb gadget power negotation
> >>
> >> On 3 March 2017 at 10:23, NeilBrown  wrote:
> >> > On Mon, Feb 20 2017, Baolin Wang wrote:
> >> >
> >> >> Currently the Linux kernel does not provide any standard
> >> >> integration of this feature that integrates the USB subsystem with
> >> >> the system power regulation provided by PMICs meaning that either
> >> >> vendors must add this in their kernels or USB gadget devices based
> >> >> on Linux (such as mobile phones) may not behave as they should.
> >> >> Thus provide a
> >> standard framework for doing this in kernel.
> >> >>
> >> >> Now introduce one user with wm831x_power to support and test the
> >> >> usb
> >> charger.
> >> >> Another user introduced to support charger detection by Jun Li:
> >> >> https://www.spinics.net/lists/linux-usb/msg139425.html
> >> >> Moreover there may be other potential users will use it in future.
> >> >>
> >> >> 1. Before v19 patchset we've fixed below issues in extcon
> >> >> subsystem and usb phy driver, now all were merged. (Thanks for
> >> >> Neil's
> >> >> suggestion)
> >> >> (1) Have fixed the inconsistencies with USB connector types in
> >> >> extcon subsystem by following links:
> >> >> https://lkml.org/lkml/2016/12/21/13
> >> >> https://lkml.org/lkml/2016/12/21/15
> >> >> https://lkml.org/lkml/2016/12/21/79
> >> >> https://lkml.org/lkml/2017/1/3/13
> >> >>
> >> >> (2) Instead of using 'set_power' callback in phy drivers, we will
> >> >> introduce USB charger to set PMIC current drawn from USB
> >> >> configuration, moreover some 'set_power' callbacks did not
> >> >> implement anything to set PMIC current, thus remove them by
> following links:
> >> >> https://lkml.org/lkml/2017/1/18/436
> >> >> https://lkml.org/lkml/2017/1/18/439
> >> >> https://lkml.org/lkml/2017/1/18/438
> >> >> Now only two phy drivers (phy-isp1301-omap.c and
> >> >> phy-gpio-vbus-usb.c) still used 'set_power' callback to set
> >> >> current, we can remove them in future. (I have no platform with
> >> >> enabling these two phy drivers, so I can not test them if I
> >> >> converted 'set_power' callback to USB
> >> >> charger.)
> >> >>
> >> >> 2. Some issues pointed by Neil Brown were sill kept in this v19
> >> >> patchset, and I expalined each issue and may be need discuss again:
> >> >> (1) Change all usb phys to register an extcon and to send
> >> >> appropriate
> >> notifications.
> >> >> Firstly, now only 3 USB phy drivers (phy-qcom-8x16-usb.c,
> >> >> phy-omap-otg.c and
> >> >> phy-msm-usb.c) had registered an extcon, mostly did not. I can not
> >> >> change all usb phys to register an extcon, since 

[GIT PULL] USB-serial fixes for v4.11-rc2

[Johan Hovold]

The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:

  Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git 
tags/usb-serial-4.11-rc2

for you to fetch changes up to 8c76d7cd520ebffc1ea9ea0850d87a224a50c7f2:

  USB: serial: safe_serial: fix information leak in completion handler 
(2017-03-08 16:14:42 +0100)


USB-serial fixes for v4.11-rc2

Here's a fix for a digi_acceleport regression in -rc1, and some fixes
for long-standing issues in three other drivers, including a
NULL-pointer dereference and a couple of information leaks that could be
triggered by a malicious device.

Signed-off-by: Johan Hovold 


Johan Hovold (6):
  USB: serial: digi_acceleport: fix OOB-event processing
  USB: serial: io_ti: fix NULL-deref in interrupt callback
  USB: serial: omninet: fix reference leaks at open
  USB: serial: omninet: drop open callback
  USB: serial: io_ti: fix information leak in completion handler
  USB: serial: safe_serial: fix information leak in completion handler

 drivers/usb/serial/digi_acceleport.c |  2 +-
 drivers/usb/serial/io_ti.c   |  8 +++-
 drivers/usb/serial/omninet.c | 13 -
 drivers/usb/serial/safe_serial.c |  5 +
 4 files changed, 13 insertions(+), 15 deletions(-)
--
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: [GIT PULL] USB-serial fixes for v4.11-rc2

[Greg Kroah-Hartman]

On Thu, Mar 09, 2017 at 11:08:41AM +0100, Johan Hovold wrote:
> The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
> 
>   Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git 
> tags/usb-serial-4.11-rc2

Pulled and pushed out, thanks.

greg k-h
--
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: storage: e-mail update in drivers/usb/storage/unusual_devs.h

[Phillip Potter]

Dear Greg,

Apologies, I sent the patch from my Windows box, using Thunderbird. Entirely 
possible
I used the wrong settings. I will do as you suggest.

Regards,
Phil

On 09/03/2017 09:25, Greg KH wrote:

On Wed, Mar 08, 2017 at 10:49:26PM +, Phillip Potter wrote:

Updates the e-mail address of Phillip Potter, updater of the Nokia 6288
entry in drivers/usb/storage/unusual_devs.h

Signed-off-by: Phillip Potter 
---
--- a/drivers/usb/storage/unusual_devs.h2017-03-08 21:47:45.878007300 
+
+++ b/drivers/usb/storage/unusual_devs.h2017-03-08 22:05:53.659147400 
+
@@ -176,7 +176,7 @@ UNUSUAL_DEV(  0x0420, 0x0001, 0x0100, 0x

 /*
  * Reported by Andrew Nayenko 
- * Updated for new firmware by Phillip Potter 
+ * Updated for new firmware by Phillip Potter 
  */
 UNUSUAL_DEV(  0x0421, 0x0019, 0x0592, 0x0610,
"Nokia",


The whitespace is all messed up here and the patch can not be applied :(

please fix up, and also change the subject to be something like what I
did here.

thanks,

greg k-h


--
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 v5 04/19] net: e100: Replace PCI pool old API

[Romain Perier]

Hello,


Le 09/03/2017 à 08:01, Peter Senna Tschudin a écrit :
> On Wed, Mar 08, 2017 at 02:40:25PM -0800, Jeff Kirsher wrote:
>> On Wed, 2017-03-08 at 17:19 +0100, Romain Perier wrote:
>>> The PCI pool API is deprecated. This commit replaces the PCI pool old
>>> API by the appropriate function with the DMA pool API.
>>>
>>> Signed-off-by: Romain Perier 
>>> Acked-by: Peter Senna Tschudin 
>>> Tested-by: Peter Senna Tschudin 
>>> ---
>>>  drivers/net/ethernet/intel/e100.c | 12 ++--
>>>  1 file changed, 6 insertions(+), 6 deletions(-)
>> Acked-by: Jeff Kirsher 
>>
>> My only concern is:
>> - what hardware did this get tested with?  Since this affects all e100
>> parts, it would be hard to believe that all the affected hardware was
>> used in testing.
> This was tested by compilation only(See
> https://lkml.org/lkml/2017/2/8/661). However this series removes macro
> definitions of the old pci_pool interface and replace call sites by what
> the macra was calling.
>
> Here are the macros that this series removes from include/pci.h:
>
> #define pci_pool dma_pool
> #define pci_pool_create(name, pdev, size, align, allocation) \
>   dma_pool_create(name, >dev, size, align, allocation)
> #define pci_pool_destroy(pool) dma_pool_destroy(pool)
> #define pci_pool_alloc(pool, flags, handle) dma_pool_alloc(pool, flags, 
> handle)
> #define pci_pool_zalloc(pool, flags, handle) \
>   dma_pool_zalloc(pool, flags, handle)
> #define pci_pool_free(pool, vaddr, addr) dma_pool_free(pool, vaddr, add
>
> So this should not affect run time.
We cannot test a patch like this one on all affected platforms/drivers
(at runtime). Simply because we have not the hw. As Peter said, we
tested this by compilation only for now via make allyesconfig. That's up
to the maintainer of the subsystem to test and ack this, imho.
I agree with Peter, this should not affect runtime (as semantically it's
compatible and have been validated statically and semantically by your
compiler)

Regards,
Romain
--
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: xhci: bInterval quirk for TI TUSB73x0

[Sergei Shtylyov]

Hello!

On 3/9/2017 11:47 AM, Roger Quadros wrote:


As per [1] issue #4,
"The periodic EP scheduler always tries to schedule the EPs
that have large intervals (interval equal to or greater than
128 microframes) into different microframes. So it maintains
an internal counter and increments for each large interval
EP added. When the counter is greater than 128, the scheduler
rejects the new EP. So when the hub re-enumerated 128 times,
it trigged this condition."


   Triggered.


This results in Bandwidth error when devices with periodic
endpoints (ISO/INT) having bInterval > 7 are plugged an
unplugged several times on a TUSB73x0 xhci host.

Workaround this issue by limiting the bInterval to 7
(i.e. interval to 6) for High-speed or faster periodic endpoints.

[1] - http://www.ti.com/lit/er/sllz076/sllz076.pdf

Signed-off-by: Roger Quadros 

[...]

MBR, Sergei

--
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: Requeste to add Quectel EC21 in USB:serial:qcserial

[Oliver Neukum]

Am Mittwoch, den 08.03.2017, 17:30 -0500 schrieb Balazs Harmath:
> Hi guys,
> 
> I’w working with a Quectel EC21 modem and i ran into an issue that
> the qcserial driver is not getting installed for it. 
> Previously i was working with the Quectel EC20 which was working
> properly but the cell carrier requested LTE Cat 1 modem so that’s why
> the switch to EC21.
> 
> Can you add the product ID for the Quectel EC21 in the qcserial.c ?
> 
> Thanks,
> Bali
> 
> Below info for Quectel EC21
> 
> root@raspberrypi:~# uname -a
> Linux raspberrypi 4.9.13-v7+ #974 SMP Wed Mar 1 20:09:48 GMT 2017
> armv7l GNU/Linux
> 
> 
> output for dmesg:
> 
> [7.575835] usb 1-1.4: new high-speed USB device number 7 using
> dwc_otg
> [7.715808] usb 1-1.4: New USB device found, idVendor=2c7c,
> idProduct=0121
> [7.715819] usb 1-1.4: New USB device strings: Mfr=1, Product=2,
> SerialNumber=0
> [7.715824] usb 1-1.4: Product: Android
> [7.715827] usb 1-1.4: Manufacturer: Android
> [7.728580] usbcore: registered new interface driver cdc_wdm
> [7.735897] qmi_wwan 1-1.4:1.4: cdc-wdm0: USB WDM device
> [7.737829] qmi_wwan 1-1.4:1.4 wwan0: register 'qmi_wwan' at usb-
> 3f98.usb-1.4, WWAN/QMI device, ce:db:66:0e:df:26
> 
> output for lsusb -t:
> 
> root@raspberrypi:~# lsusb -t
> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
> |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
> |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/3p, 480M
> |__ Port 1: Dev 5, If 0, Class=Vendor Specific Class,
> Driver=smsc95xx, 480M
> |__ Port 2: Dev 4, If 0, Class=Vendor Specific Class,
> Driver=ftdi_sio, 12M
> |__ Port 3: Dev 6, If 0, Class=Mass Storage, Driver=usb-
> storage, 480M
> |__ Port 4: Dev 7, If 1, Class=Vendor Specific Class,
> Driver=, 480M
> |__ Port 4: Dev 7, If 4, Class=Vendor Specific Class,
> Driver=qmi_wwan, 480M

qmi_wwan is binding to this interface.

> |__ Port 4: Dev 7, If 2, Class=Vendor Specific Class,
> Driver=, 480M
> |__ Port 4: Dev 7, If 0, Class=Vendor Specific Class,
> Driver=, 480M
> |__ Port 4: Dev 7, If 3, Class=Vendor Specific Class,
> Driver=, 480M

Do you need qcserial for these interfaces?

Regards
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

Re: [PATCH 1/2] usb: gadget: f_uvc: Fix SuperSpeed companion descriptor's wBytesPerInterval

[Roger Quadros]

Felipe,

On 08/03/17 16:05, Roger Quadros wrote:
> The streaming_maxburst module parameter is 0 offset (0..15)
> so we must add 1 while using it for wBytesPerInterval
> calculation for the SuperSpeed companion descriptor.
> 
> Without this host uvcvideo driver will always see the wrong
> wBytesPerInterval for SuperSpeed uvc gadget and may not find
> a suitable video interface endpoint.
> e.g. for streaming_maxburst = 0 case it will always
> fail as wBytePerInterval was evaluating to 0.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Roger Quadros 

Please pick this one for v4.11-rc with Laurent's Reviewed-by. Thanks.

> ---
>  drivers/usb/gadget/function/f_uvc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/gadget/function/f_uvc.c 
> b/drivers/usb/gadget/function/f_uvc.c
> index 29b41b5..c7689d0 100644
> --- a/drivers/usb/gadget/function/f_uvc.c
> +++ b/drivers/usb/gadget/function/f_uvc.c
> @@ -625,7 +625,7 @@ uvc_function_bind(struct usb_configuration *c, struct 
> usb_function *f)
>   uvc_ss_streaming_comp.bMaxBurst = opts->streaming_maxburst;
>   uvc_ss_streaming_comp.wBytesPerInterval =
>   cpu_to_le16(max_packet_size * max_packet_mult *
> - opts->streaming_maxburst);
> + (opts->streaming_maxburst + 1));
>  
>   /* Allocate endpoints. */
>   ep = usb_ep_autoconfig(cdev->gadget, _control_ep);
> 

-- 
cheers,
-roger
--
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] lvs: fix race condition in disconnect handling

[Oliver Neukum]

Am Donnerstag, den 09.03.2017, 06:42 +0100 schrieb Greg KH:
> On Mon, Feb 20, 2017 at 03:38:42PM +0100, Oliver Neukum wrote:
> > 
> > There is a small window during which the an URB may
> > remain active after disconnect has returned. If in that case
> > already freed memory may be accessed and executed.
> > 
> > The fix is to poison the URB befotre the work is flushed.
> > 
> > Signed-off-by: Oliver Neukum 
> > ---
> >  drivers/usb/misc/lvstest.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/usb/misc/lvstest.c
> > b/drivers/usb/misc/lvstest.c
> > index 7717651..e5d2500 100644
> > --- a/drivers/usb/misc/lvstest.c
> > +++ b/drivers/usb/misc/lvstest.c
> > @@ -429,6 +429,8 @@ static void lvs_rh_disconnect(struct
> > usb_interface *intf)
> >     struct lvs_rh *lvs = usb_get_intfdata(intf);
> >  
> >     sysfs_remove_group(>dev.kobj, _attr_group);
> > +   usb_poison_urb(lvs->urb); /* used in scheduled work */
> > +   (lvs->urb);
> 
> Is that second line really needed?
> 
> 
Hi,

no it isn't something went wrong. I am respinning.

Thanks
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

Re: [PATCH 22/29] drivers, scsi: convert iscsi_task.refcount from atomic_t to refcount_t

[Johannes Thumshirn]

On 03/09/2017 10:26 AM, Reshetova, Elena wrote:
> 
>> On 03/09/2017 08:18 AM, Reshetova, Elena wrote:
 On Mon, Mar 06, 2017 at 04:21:09PM +0200, Elena Reshetova wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
>
> Signed-off-by: Elena Reshetova 
> Signed-off-by: Hans Liljestrand 
> Signed-off-by: Kees Cook 
> Signed-off-by: David Windsor 

 This looks OK to me.

 Acked-by: Chris Leech 
>>>
>>> Thank you for review! Do you have a tree that can take this change?
>>
>> Hi Elena,
>>
>> iscsi like fcoe should go via the SCSI tree.
> 
> Thanks Johannes! Should I resend with "Acked-by" added in order for it to be 
> picked up? 

Yes I think this would be a good way to go.

Byte,
Johannes
-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
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 22/29] drivers, scsi: convert iscsi_task.refcount from atomic_t to refcount_t

[Reshetova, Elena]

> On 03/09/2017 08:18 AM, Reshetova, Elena wrote:
> >> On Mon, Mar 06, 2017 at 04:21:09PM +0200, Elena Reshetova wrote:
> >>> refcount_t type and corresponding API should be
> >>> used instead of atomic_t when the variable is used as
> >>> a reference counter. This allows to avoid accidental
> >>> refcounter overflows that might lead to use-after-free
> >>> situations.
> >>>
> >>> Signed-off-by: Elena Reshetova 
> >>> Signed-off-by: Hans Liljestrand 
> >>> Signed-off-by: Kees Cook 
> >>> Signed-off-by: David Windsor 
> >>
> >> This looks OK to me.
> >>
> >> Acked-by: Chris Leech 
> >
> > Thank you for review! Do you have a tree that can take this change?
> 
> Hi Elena,
> 
> iscsi like fcoe should go via the SCSI tree.

Thanks Johannes! Should I resend with "Acked-by" added in order for it to be 
picked up? 

Best Regards,
Elena.


> 
> Byte,
>   Johannes
> 
> --
> Johannes Thumshirn  Storage
> jthumsh...@suse.de+49 911 74053 689
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)
> Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
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: host: xhci-plat: Fix timeout on removal of hot pluggable xhci controllers

[Mathias Nyman]

On 08.03.2017 21:49, Guenter Roeck wrote:

Upstream commit 98d74f9ceaef ("xhci: fix 10 second timeout on removal of
PCI hotpluggable xhci controllers") fixes a problem with hot pluggable PCI
xhci controllers which can result in excessive timeouts, to the point where
the system reports a deadlock.

The same problem is seen with hot pluggable xhci controllers using the
xhci-plat driver, such as the driver used for Type-C ports on rk3399.
Similar to hot-pluggable PCI controllers, the driver for this chip
removes the xhci controller from the system when the Type-C cable is
disconnected.

The solution for PCI devices works just as well for non-PCI devices
and avoids the problem.

Signed-off-by: Guenter Roeck 
---



Thanks, adding to queue

-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: [PATCH] USB: storage: e-mail update in drivers/usb/storage/unusual_devs.h

[Greg KH]

On Wed, Mar 08, 2017 at 10:49:26PM +, Phillip Potter wrote:
> Updates the e-mail address of Phillip Potter, updater of the Nokia 6288
> entry in drivers/usb/storage/unusual_devs.h
> 
> Signed-off-by: Phillip Potter 
> ---
> --- a/drivers/usb/storage/unusual_devs.h  2017-03-08 21:47:45.878007300 
> +
> +++ b/drivers/usb/storage/unusual_devs.h  2017-03-08 22:05:53.659147400 
> +
> @@ -176,7 +176,7 @@ UNUSUAL_DEV(  0x0420, 0x0001, 0x0100, 0x
> 
>  /*
>   * Reported by Andrew Nayenko 
> - * Updated for new firmware by Phillip Potter 
> + * Updated for new firmware by Phillip Potter 
>   */
>  UNUSUAL_DEV(  0x0421, 0x0019, 0x0592, 0x0610,
> "Nokia",

The whitespace is all messed up here and the patch can not be applied :(

please fix up, and also change the subject to be something like what I
did here.

thanks,

greg k-h
--
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: [GIT PULL] USB fixes for v4.11-rc2

[Greg Kroah-Hartman]

On Thu, Mar 09, 2017 at 11:05:57AM +0200, Felipe Balbi wrote:
> 
> Hi Greg,
> 
> Here's my first set of fixes for this -rc cycle. Let me know if you want
> anything to be changed ;-)

Pulled and pushed out, thanks.

greg k-h
--
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

[GIT PULL] USB fixes for v4.11-rc2

[Felipe Balbi]

Hi Greg,

Here's my first set of fixes for this -rc cycle. Let me know if you want
anything to be changed ;-)

Cheers

The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:

  Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
tags/fixes-for-v4.11-rc2

for you to fetch changes up to 35b2719e72d375f3e32c819858165668d948d5f2:

  usb: dwc3: gadget: make to increment req->remaining in all cases (2017-03-08 
13:56:37 +0200)


usb: fixes for v4.11-rc2

dwc3 got a few fixes this time around:

Fixed an old bug where a broken endpoint descriptor passed in via
userspace through f_fs could prevent dwc3 from working because when
calculating max bursts, we could overwrite top 16 bits of a register.

Also fixed a bug on dwc3's ep_dequeue implementation which wasn't
properly incrementing our TRB dequeue pointer.

dwc3 on omap got two fixes: one for system suspend/resume and another
added a missing break statement on dwc3_omap_set_mailbox().

Apart from these, we have a set of smaller fixes including memory leak
in configfs, build warning fix in atmel udc and a revert of a broken
patch that went in during the merge window


Arnd Bergmann (1):
  usb: gadget: udc: atmel: fix debug output

Christophe JAILLET (1):
  USB: gadgetfs: Fix a potential memory leak in 'dev_config()'

Felipe Balbi (4):
  usb: dwc3: gadget: make Set Endpoint Configuration macros safe
  usb: gadget: function: f_fs: pass companion descriptor along
  usb: dwc3: gadget: properly increment dequeue pointer on ep_dequeue
  usb: dwc3: gadget: make to increment req->remaining in all cases

Franck Demathieu (1):
  usb: dwc3: Fix incorrect type for utmi mode

Janusz Dziedzic (1):
  Revert "usb: gadget: f_fs: Fix ExtCompat descriptor validation"

John Keeping (1):
  usb: gadget: configs: plug memory leak

Peter Chen (1):
  usb: gadget: dummy_hcd: clear usb_gadget region before registration

Petr Cvek (1):
  usb: gadget: pxa27x: Test for a valid argument pointer

Raz Manor (1):
  usb: gadget: udc: net2280: Fix tmp reusage in net2280 driver

Roger Quadros (3):
  Revert "usb: gadget: uvc: Add missing call for additional setup data"
  usb: dwc3: gadget: Fix system suspend/resume on TI platforms
  usb: dwc3-omap: Fix missing break in dwc3_omap_set_mailbox()

 drivers/usb/dwc3/dwc3-omap.c|  3 +-
 drivers/usb/dwc3/gadget.c   | 76 +
 drivers/usb/dwc3/gadget.h   | 14 +++---
 drivers/usb/gadget/configfs.c   |  1 +
 drivers/usb/gadget/function/f_fs.c  | 17 ++--
 drivers/usb/gadget/function/f_uvc.c |  7 ---
 drivers/usb/gadget/legacy/inode.c   |  4 +-
 drivers/usb/gadget/udc/atmel_usba_udc.c |  4 +-
 drivers/usb/gadget/udc/dummy_hcd.c  |  2 +
 drivers/usb/gadget/udc/net2280.c| 25 +--
 drivers/usb/gadget/udc/pxa27x_udc.c |  5 ++-
 11 files changed, 114 insertions(+), 44 deletions(-)


-- 
balbi


signature.asc
Description: PGP signature

Re: Question: Does usbip support USB 3.0?

[Yuyang Du]

Hi Krzysztof,

On Wed, Mar 08, 2017 at 10:00:55AM +0100, Krzysztof Opasiak wrote:
> 
> Descriptors says that it's bulk so now question is if it uses
> streams or not. Check your driver or USB traffic.
> 

I just grep'ed usb_alloc_streams in the driver, nothing appeared. So it should 
be just bulk, correct me if I'm wrong. I'm studying the dummy_hcd patch, 
overwhelmed...

And by USB traffic, I tried usbmon. It'd be good if it has an additional "bulk 
streams" urb type.

Thanks,
Yuyang
--
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 22/29] drivers, scsi: convert iscsi_task.refcount from atomic_t to refcount_t

[Johannes Thumshirn]

On 03/09/2017 08:18 AM, Reshetova, Elena wrote:
>> On Mon, Mar 06, 2017 at 04:21:09PM +0200, Elena Reshetova wrote:
>>> refcount_t type and corresponding API should be
>>> used instead of atomic_t when the variable is used as
>>> a reference counter. This allows to avoid accidental
>>> refcounter overflows that might lead to use-after-free
>>> situations.
>>>
>>> Signed-off-by: Elena Reshetova 
>>> Signed-off-by: Hans Liljestrand 
>>> Signed-off-by: Kees Cook 
>>> Signed-off-by: David Windsor 
>>
>> This looks OK to me.
>>
>> Acked-by: Chris Leech 
> 
> Thank you for review! Do you have a tree that can take this change? 

Hi Elena,

iscsi like fcoe should go via the SCSI tree.

Byte,
Johannes

-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
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: xhci: bInterval quirk for TI TUSB73x0

[Roger Quadros]

As per [1] issue #4,
"The periodic EP scheduler always tries to schedule the EPs
that have large intervals (interval equal to or greater than
128 microframes) into different microframes. So it maintains
an internal counter and increments for each large interval
EP added. When the counter is greater than 128, the scheduler
rejects the new EP. So when the hub re-enumerated 128 times,
it trigged this condition."

This results in Bandwidth error when devices with periodic
endpoints (ISO/INT) having bInterval > 7 are plugged an
unplugged several times on a TUSB73x0 xhci host.

Workaround this issue by limiting the bInterval to 7
(i.e. interval to 6) for High-speed or faster periodic endpoints.

[1] - http://www.ti.com/lit/er/sllz076/sllz076.pdf

Signed-off-by: Roger Quadros 
---
 drivers/usb/host/xhci-mem.c | 11 +++
 drivers/usb/host/xhci-pci.c |  3 +++
 drivers/usb/host/xhci.h |  1 +
 3 files changed, 15 insertions(+)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index ba1853f4..05fb3f6 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1502,6 +1502,17 @@ int xhci_endpoint_init(struct xhci_hcd *xhci,
 */
max_esit_payload = xhci_get_max_esit_payload(udev, ep);
interval = xhci_get_endpoint_interval(udev, ep);
+
+   /* Periodic endpoint bInterval limit quirk */
+   if (usb_endpoint_xfer_int(>desc) ||
+   usb_endpoint_xfer_isoc(>desc)) {
+   if ((xhci->quirks & XHCI_LIMIT_ENDPOINT_INTERVAL_7) &&
+   udev->speed >= USB_SPEED_HIGH &&
+   interval >= 7) {
+   interval = 6;
+   }
+   }
+
mult = xhci_get_endpoint_mult(udev, ep);
max_packet = usb_endpoint_maxp(>desc);
max_burst = xhci_get_endpoint_max_burst(udev, ep);
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index fc99f51..7b86508 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -199,6 +199,9 @@ static void xhci_pci_quirks(struct device *dev, struct 
xhci_hcd *xhci)
pdev->device == 0x1042)
xhci->quirks |= XHCI_BROKEN_STREAMS;
 
+   if (pdev->vendor == PCI_VENDOR_ID_TI && pdev->device == 0x8241)
+   xhci->quirks |= XHCI_LIMIT_ENDPOINT_INTERVAL_7;
+
if (xhci->quirks & XHCI_RESET_ON_RESUME)
xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
"QUIRK: Resetting on resume");
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index da3eb69..2496bd6 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1818,6 +1818,7 @@ struct xhci_hcd {
 #define XHCI_MISSING_CAS   (1 << 24)
 /* For controller with a broken Port Disable implementation */
 #define XHCI_BROKEN_PORT_PED   (1 << 25)
+#define XHCI_LIMIT_ENDPOINT_INTERVAL_7 (1 << 26)
 
unsigned intnum_active_eps;
unsigned intlimit_active_eps;
-- 
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: [RESEND PATCH v3 4/8] phy: phy-mt65xx-usb3: move clock from phy node into port nodes

[Chunfeng Yun]

On Thu, 2017-03-09 at 13:51 +0530, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Monday 06 March 2017 07:19 PM, Chunfeng Yun wrote:
> > the reference clock of HighSpeed port is 48M which comes from PLL;
> > the reference clock of SuperSpeed port is 26M which usually comes
> > from 26M oscillator directly, but some SoCs are not, add it for
> > compatibility, and put them into port node for flexibility.
> 
> Won't this break the old dt compatiblity? Making change in dt is fine as long
> as older dtb's are still supported.
Ok, I'll keep it compatible in next version

Thanks a lot
> 
> Thanks
> Kishon
> > 
> > Signed-off-by: Chunfeng Yun 
> > ---
> >  drivers/phy/phy-mt65xx-usb3.c |   21 +++--
> >  1 file changed, 11 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
> > index 7fff482..f4a3505 100644
> > --- a/drivers/phy/phy-mt65xx-usb3.c
> > +++ b/drivers/phy/phy-mt65xx-usb3.c
> > @@ -153,6 +153,7 @@ struct mt65xx_phy_pdata {
> >  struct mt65xx_phy_instance {
> > struct phy *phy;
> > void __iomem *port_base;
> > +   struct clk *ref_clk;/* reference clock of anolog phy */
> > u32 index;
> > u8 type;
> >  };
> > @@ -160,7 +161,6 @@ struct mt65xx_phy_instance {
> >  struct mt65xx_u3phy {
> > struct device *dev;
> > void __iomem *sif_base; /* only shared sif */
> > -   struct clk *u3phya_ref; /* reference clock of usb3 anolog phy */
> > const struct mt65xx_phy_pdata *pdata;
> > struct mt65xx_phy_instance **phys;
> > int nphys;
> > @@ -449,9 +449,9 @@ static int mt65xx_phy_init(struct phy *phy)
> > struct mt65xx_u3phy *u3phy = dev_get_drvdata(phy->dev.parent);
> > int ret;
> >  
> > -   ret = clk_prepare_enable(u3phy->u3phya_ref);
> > +   ret = clk_prepare_enable(instance->ref_clk);
> > if (ret) {
> > -   dev_err(u3phy->dev, "failed to enable u3phya_ref\n");
> > +   dev_err(u3phy->dev, "failed to enable ref_clk\n");
> > return ret;
> > }
> >  
> > @@ -494,7 +494,7 @@ static int mt65xx_phy_exit(struct phy *phy)
> > if (instance->type == PHY_TYPE_USB2)
> > phy_instance_exit(u3phy, instance);
> >  
> > -   clk_disable_unprepare(u3phy->u3phya_ref);
> > +   clk_disable_unprepare(instance->ref_clk);
> > return 0;
> >  }
> >  
> > @@ -594,12 +594,6 @@ static int mt65xx_u3phy_probe(struct platform_device 
> > *pdev)
> > return PTR_ERR(u3phy->sif_base);
> > }
> >  
> > -   u3phy->u3phya_ref = devm_clk_get(dev, "u3phya_ref");
> > -   if (IS_ERR(u3phy->u3phya_ref)) {
> > -   dev_err(dev, "error to get u3phya_ref\n");
> > -   return PTR_ERR(u3phy->u3phya_ref);
> > -   }
> > -
> > port = 0;
> > for_each_child_of_node(np, child_np) {
> > struct mt65xx_phy_instance *instance;
> > @@ -634,6 +628,13 @@ static int mt65xx_u3phy_probe(struct platform_device 
> > *pdev)
> > goto put_child;
> > }
> >  
> > +   instance->ref_clk = devm_clk_get(>dev, "ref");
> > +   if (IS_ERR(instance->ref_clk)) {
> > +   dev_err(dev, "failed to get ref_clk(id-%d)\n", port);
> > +   retval = PTR_ERR(instance->ref_clk);
> > +   goto put_child;
> > +   }
> > +
> > instance->phy = phy;
> > instance->index = port;
> > phy_set_drvdata(phy, instance);
> > 


--
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: [RESEND PATCH v3 4/8] phy: phy-mt65xx-usb3: move clock from phy node into port nodes

[Kishon Vijay Abraham I]

Hi,

On Monday 06 March 2017 07:19 PM, Chunfeng Yun wrote:
> the reference clock of HighSpeed port is 48M which comes from PLL;
> the reference clock of SuperSpeed port is 26M which usually comes
> from 26M oscillator directly, but some SoCs are not, add it for
> compatibility, and put them into port node for flexibility.

Won't this break the old dt compatiblity? Making change in dt is fine as long
as older dtb's are still supported.

Thanks
Kishon
> 
> Signed-off-by: Chunfeng Yun 
> ---
>  drivers/phy/phy-mt65xx-usb3.c |   21 +++--
>  1 file changed, 11 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
> index 7fff482..f4a3505 100644
> --- a/drivers/phy/phy-mt65xx-usb3.c
> +++ b/drivers/phy/phy-mt65xx-usb3.c
> @@ -153,6 +153,7 @@ struct mt65xx_phy_pdata {
>  struct mt65xx_phy_instance {
>   struct phy *phy;
>   void __iomem *port_base;
> + struct clk *ref_clk;/* reference clock of anolog phy */
>   u32 index;
>   u8 type;
>  };
> @@ -160,7 +161,6 @@ struct mt65xx_phy_instance {
>  struct mt65xx_u3phy {
>   struct device *dev;
>   void __iomem *sif_base; /* only shared sif */
> - struct clk *u3phya_ref; /* reference clock of usb3 anolog phy */
>   const struct mt65xx_phy_pdata *pdata;
>   struct mt65xx_phy_instance **phys;
>   int nphys;
> @@ -449,9 +449,9 @@ static int mt65xx_phy_init(struct phy *phy)
>   struct mt65xx_u3phy *u3phy = dev_get_drvdata(phy->dev.parent);
>   int ret;
>  
> - ret = clk_prepare_enable(u3phy->u3phya_ref);
> + ret = clk_prepare_enable(instance->ref_clk);
>   if (ret) {
> - dev_err(u3phy->dev, "failed to enable u3phya_ref\n");
> + dev_err(u3phy->dev, "failed to enable ref_clk\n");
>   return ret;
>   }
>  
> @@ -494,7 +494,7 @@ static int mt65xx_phy_exit(struct phy *phy)
>   if (instance->type == PHY_TYPE_USB2)
>   phy_instance_exit(u3phy, instance);
>  
> - clk_disable_unprepare(u3phy->u3phya_ref);
> + clk_disable_unprepare(instance->ref_clk);
>   return 0;
>  }
>  
> @@ -594,12 +594,6 @@ static int mt65xx_u3phy_probe(struct platform_device 
> *pdev)
>   return PTR_ERR(u3phy->sif_base);
>   }
>  
> - u3phy->u3phya_ref = devm_clk_get(dev, "u3phya_ref");
> - if (IS_ERR(u3phy->u3phya_ref)) {
> - dev_err(dev, "error to get u3phya_ref\n");
> - return PTR_ERR(u3phy->u3phya_ref);
> - }
> -
>   port = 0;
>   for_each_child_of_node(np, child_np) {
>   struct mt65xx_phy_instance *instance;
> @@ -634,6 +628,13 @@ static int mt65xx_u3phy_probe(struct platform_device 
> *pdev)
>   goto put_child;
>   }
>  
> + instance->ref_clk = devm_clk_get(>dev, "ref");
> + if (IS_ERR(instance->ref_clk)) {
> + dev_err(dev, "failed to get ref_clk(id-%d)\n", port);
> + retval = PTR_ERR(instance->ref_clk);
> + goto put_child;
> + }
> +
>   instance->phy = phy;
>   instance->index = port;
>   phy_set_drvdata(phy, instance);
> 
--
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