Re: [PATCH V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver

2014-04-25 Thread Tushar Behera 
On 04/14/2014 08:07 PM, Sylwester Nawrocki wrote:
> On 08/04/14 16:36, Vivek Gautam wrote:
>> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt 
>> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> index 28f9edb..6d99ba9 100644
>> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> @@ -74,3 +74,45 @@ phy-consumer@1234 {
>>  
>>  Refer to DT bindings documentation of particular PHY consumer devices for 
>> more
>>  information about required PHYs and the way of specification.
>> +
>> +Samsung Exynos5 SoC series USB DRD PHY controller
>> +--
>> +
>> +Required properties:
>> +- compatible : Should be set to one of the following supported values:
>> +- "samsung,exynos5250-usbdrd-phy" - for exynos5250 SoC,
>> +- "samsung,exynos5420-usbdrd-phy" - for exynos5420 SoC.
>> +- reg : Register offset and length of USB DRD PHY register set;
>> +- clocks: Clock IDs array as required by the controller
>> +- clock-names: names of clocks correseponding to IDs in the clock property;
>> +   Required clocks:
>> +- phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock),
>> +   used for register access.
>> +- ref: PHY's reference clock (usually crystal clock), associated by
>> +   phy name, used to determine bit values for clock settings
>> +   register.
>> +Additional clock required for Exynos5420:
>> +- usb30_sclk_100m: Additional special clock used for PHY operation
>> +   depicted as 'sclk_usbphy30' in CMU of Exynos5420.
>> +- samsung,syscon-phandle: phandle for syscon interface, which is used to
>> +  control pmu registers for power isolation.
> 
> Why to append "-phandle" to the property's name ? If this is for PMU
> perhaps make it more explicit and name it: samsung,pmu-syscon or
> samsung,pmureg ?
> 

There are already a couple of nodes (watchdog and sata) using
samsung,syscon-phandle. IMHO, we should keep only property string for
syscon node. Either we keep syscon-phandle here or change sata/watchdog
driver to use the modified property name.

-- 
Tushar Behera
--
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 0/5] xhci: fixes for 3.15-rc usb-linus

2014-04-25 Thread Mathias Nyman 

On 04/24/2014 10:50 PM, Greg KH wrote:

On Tue, Apr 22, 2014 at 03:22:57PM +0300, Mathias Nyman wrote:

Hi Greg

Here are the xhci fixes for 3.15-rc usb-linus.
Most of them are very small fixes that didn't make
it to 3.14, sitting and waiting for 3.15-rc1 to come out.

Only the "Prefer endpoint context.." patch  by Julius has a bit more content.

These patches are picked together with Sarah, they are tested on top of
3.15-rc1, and apply on your current usb-linus branch


Please redo all of these based on my comments.




Will do
Thanks for the feedback

-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 V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver

2014-04-25 Thread Vivek Gautam 
Hi,


On Fri, Apr 25, 2014 at 1:27 PM, Tushar Behera  wrote:
> On 04/14/2014 08:07 PM, Sylwester Nawrocki wrote:
>> On 08/04/14 16:36, Vivek Gautam wrote:
>>> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt 
>>> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>> index 28f9edb..6d99ba9 100644
>>> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>>> @@ -74,3 +74,45 @@ phy-consumer@1234 {
>>>
>>>  Refer to DT bindings documentation of particular PHY consumer devices for 
>>> more
>>>  information about required PHYs and the way of specification.
>>> +
>>> +Samsung Exynos5 SoC series USB DRD PHY controller
>>> +--
>>> +
>>> +Required properties:
>>> +- compatible : Should be set to one of the following supported values:
>>> +- "samsung,exynos5250-usbdrd-phy" - for exynos5250 SoC,
>>> +- "samsung,exynos5420-usbdrd-phy" - for exynos5420 SoC.
>>> +- reg : Register offset and length of USB DRD PHY register set;
>>> +- clocks: Clock IDs array as required by the controller
>>> +- clock-names: names of clocks correseponding to IDs in the clock property;
>>> +   Required clocks:
>>> +- phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock),
>>> +   used for register access.
>>> +- ref: PHY's reference clock (usually crystal clock), associated by
>>> +   phy name, used to determine bit values for clock settings
>>> +   register.
>>> +Additional clock required for Exynos5420:
>>> +- usb30_sclk_100m: Additional special clock used for PHY operation
>>> +   depicted as 'sclk_usbphy30' in CMU of Exynos5420.
>>> +- samsung,syscon-phandle: phandle for syscon interface, which is used to
>>> +  control pmu registers for power isolation.
>>
>> Why to append "-phandle" to the property's name ? If this is for PMU
>> perhaps make it more explicit and name it: samsung,pmu-syscon or
>> samsung,pmureg ?
>>
>
> There are already a couple of nodes (watchdog and sata) using
> samsung,syscon-phandle. IMHO, we should keep only property string for
> syscon node. Either we keep syscon-phandle here or change sata/watchdog
> driver to use the modified property name.

IMHO samsung,pmu-syscon make more sense rather than appending a
'-phandle' to the property name.
This is a 'phandle' and that is in fact understood, isn't it ?
We can change in the watchdog, sata drivers to use use the modified name.
I can send a patch for the same if we are OK with this, so that we
maintain the consistency in the device tree.


-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
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 3/4] dwc3: host: Set xhci lpm support quirk

2014-04-25 Thread Pratyush Anand 
On Tue, Apr 22, 2014 at 10:41:06PM +0800, Felipe Balbi wrote:
> On Tue, Apr 22, 2014 at 10:46:13AM +0530, Pratyush Anand wrote:
> > On Tue, Apr 22, 2014 at 12:43:55PM +0800, Felipe Balbi wrote:
> > > On Tue, Apr 22, 2014 at 09:57:29AM +0530, Pratyush Anand wrote:
> > > > All dwc3 based xhci host controller supports USB3.0 LPM functionality.
> > > > Therefore enable quirk flag to support it for dwc3 xhci host driver.
> > > > 
> > > > Signed-off-by: Pratyush Anand 
> > > > Tested-by: Aymen Bouattay 
> > > > ---
> > > >  drivers/usb/dwc3/host.c | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > > 
> > > > diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
> > > > index a362ed9..b0e4669 100644
> > > > --- a/drivers/usb/dwc3/host.c
> > > > +++ b/drivers/usb/dwc3/host.c
> > > > @@ -86,6 +86,7 @@ int dwc3_host_init(struct dwc3 *dwc)
> > > > hcd = platform_get_drvdata(xhci);
> > > > xhci_dev = hcd_to_xhci(hcd);
> > > > xhci_dev->shared_hcd->phy = dwc->usb3_phy;
> > > > +   xhci_dev->quirks |= XHCI_LPM_SUPPORT;
> > > 
> > > weird... what sort of changes do you have which you didn't send yet ?
> > > dwc3/host.c does not create the xHCI device. dwc3_host_init() is
> > > basically a wrapper to platform_add_device()
> > 
> > There is nothing, and it works.
> > 
> > Adding platform xhci driver in defconfig and selecting dwc3 in DT is 
> > sufficient.
> > Did I get, what you were asking?
> 
> this little hunk below will never apply to dwc3/host.c:
> 
> diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
> index a362ed9..b0e4669 100644
> --- a/drivers/usb/dwc3/host.c
> +++ b/drivers/usb/dwc3/host.c
> @@ -86,6 +86,7 @@ int dwc3_host_init(struct dwc3 *dwc)
>   hcd = platform_get_drvdata(xhci);
>   xhci_dev = hcd_to_xhci(hcd);
>   xhci_dev->shared_hcd->phy = dwc->usb3_phy;
> + xhci_dev->quirks |= XHCI_LPM_SUPPORT;
> 
> 
> here are dwc3/host.c contents as of v3.15-rc2 (removed comments)
> 
> #include 
> 
> #include "core.h"
> 
> int dwc3_host_init(struct dwc3 *dwc)
> {
>   struct platform_device  *xhci;
>   int ret;
> 
>   xhci = platform_device_alloc("xhci-hcd", PLATFORM_DEVID_AUTO);
>   if (!xhci) {
>   dev_err(dwc->dev, "couldn't allocate xHCI device\n");
>   ret = -ENOMEM;
>   goto err0;
>   }
> 
>   dma_set_coherent_mask(&xhci->dev, dwc->dev->coherent_dma_mask);
> 
>   xhci->dev.parent= dwc->dev;
>   xhci->dev.dma_mask  = dwc->dev->dma_mask;
>   xhci->dev.dma_parms = dwc->dev->dma_parms;
> 
>   dwc->xhci = xhci;
> 
>   ret = platform_device_add_resources(xhci, dwc->xhci_resources,
>   DWC3_XHCI_RESOURCES_NUM);
>   if (ret) {
>   dev_err(dwc->dev, "couldn't add resources to xHCI device\n");
>   goto err1;
>   }
> 
>   ret = platform_device_add(xhci);
>   if (ret) {
>   dev_err(dwc->dev, "failed to register xHCI device\n");
>   goto err1;
>   }
> 
>   return 0;
> 
> err1:
>   platform_device_put(xhci);
> 
> err0:
>   return ret;
> }
> 
> void dwc3_host_exit(struct dwc3 *dwc)
> {
>   platform_device_unregister(dwc->xhci);
> }
> 
> as you can see, there is no such thing as xhci_dev variable.

OKI see..
I will rebase it with latest code.

Pratyush

> 
> -- 
> balbi


--
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/4] xhci: A default implementation for Ux timeout calculation and tier policy check

2014-04-25 Thread Pratyush Anand 
On Thu, Apr 24, 2014 at 11:01:58PM +0800, Mathias Nyman wrote:
> On 04/22/2014 07:27 AM, Pratyush Anand wrote:
> > As best case, a host controller should support U0 to U1 switching for
> > the devices connected below any tier of hub level supported by usb
> > specification. Therefore xhci_check_tier_policy should always return
> > success as default implementation.
> >
> > A host should be able to issue LGO_Ux after the timeout calculated as
> > per definition of system exit latency defined in C.1.5.2. Therefore
> > xhci_calculate_ux_timeout returns ux_params.sel as the default
> > implementation.
> >
> > Use default calculation in absence of any vendor specific limitations.
> >
> > Signed-off-by: Pratyush Anand 
> > Tested-by: Aymen Bouattay 
> > ---
> >   drivers/usb/host/xhci.c | 66 
> > +++--
> >   1 file changed, 48 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> > index 6cc58fe..f5ac76a 100644
> > --- a/drivers/usb/host/xhci.c
> > +++ b/drivers/usb/host/xhci.c
> > @@ -4140,8 +4140,7 @@ static u16 xhci_get_timeout_no_hub_lpm(struct 
> > usb_device *udev,
> > return USB3_LPM_DISABLED;
> >   }
> >
> > -/* Returns the hub-encoded U1 timeout value.
> > - * The U1 timeout should be the maximum of the following values:
> > +/* The U1 timeout should be the maximum of the following values:
> >*  - For control endpoints, U1 system exit latency (SEL) * 3
> >*  - For bulk endpoints, U1 SEL * 5
> >*  - For interrupt endpoints:
> > @@ -4149,7 +4148,8 @@ static u16 xhci_get_timeout_no_hub_lpm(struct 
> > usb_device *udev,
> >*- Periodic EPs, max(105% of bInterval, U1 SEL * 2)
> >*  - For isochronous endpoints, max(105% of bInterval, U1 SEL * 2)
> >*/
> > -static u16 xhci_calculate_intel_u1_timeout(struct usb_device *udev,
> > +static unsigned long long xhci_calculate_intel_u1_timeout(
> > +   struct usb_device *udev,
> > struct usb_endpoint_descriptor *desc)
> >   {
> > unsigned long long timeout_ns;
> > @@ -4181,11 +4181,28 @@ static u16 xhci_calculate_intel_u1_timeout(struct 
> > usb_device *udev,
> > return 0;
> > }
> >
> > -   /* The U1 timeout is encoded in 1us intervals. */
> > -   timeout_ns = DIV_ROUND_UP_ULL(timeout_ns, 1000);
> > -   /* Don't return a timeout of zero, because that's USB3_LPM_DISABLED. */
> > +   return timeout_ns;
> > +}
> > +
> > +/* Returns the hub-encoded U1 timeout value. */
> > +static u16 xhci_calculate_u1_timeout(struct xhci_hcd *xhci,
> > +   struct usb_device *udev,
> > +   struct usb_endpoint_descriptor *desc)
> > +{
> > +   unsigned long long timeout_ns;
> > +
> > +   if (xhci->quirks & XHCI_INTEL_HOST)
> > +   timeout_ns = xhci_calculate_intel_u1_timeout(udev, desc);
> > +   else
> > +   timeout_ns = udev->u1_params.sel;
> > +
> > +   /* The U1 timeout is encoded in 1us intervals.
> > +* Don't return a timeout of zero, because that's USB3_LPM_DISABLED.
> > +*/
> > if (timeout_ns == USB3_LPM_DISABLED)
> > -   timeout_ns++;
> > +   timeout_ns = 1;
> > +   else
> > +   timeout_ns = DIV_ROUND_UP_ULL(timeout_ns, 1000);
> >
> > /* If the necessary timeout value is bigger than what we can set in the
> >  * USB 3.0 hub, we have to disable hub-initiated U1.
> > @@ -4197,14 +4214,14 @@ static u16 xhci_calculate_intel_u1_timeout(struct 
> > usb_device *udev,
> > return xhci_get_timeout_no_hub_lpm(udev, USB3_LPM_U1);
> >   }
> >
> > -/* Returns the hub-encoded U2 timeout value.
> > - * The U2 timeout should be the maximum of:
> > +/* The U2 timeout should be the maximum of:
> >*  - 10 ms (to avoid the bandwidth impact on the scheduler)
> >*  - largest bInterval of any active periodic endpoint (to avoid going
> >*into lower power link states between intervals).
> >*  - the U2 Exit Latency of the device
> >*/
> > -static u16 xhci_calculate_intel_u2_timeout(struct usb_device *udev,
> > +static unsigned long long xhci_calculate_intel_u2_timeout(
> > +   struct usb_device *udev,
> > struct usb_endpoint_descriptor *desc)
> >   {
> > unsigned long long timeout_ns;
> > @@ -4220,6 +4237,21 @@ static u16 xhci_calculate_intel_u2_timeout(struct 
> > usb_device *udev,
> > if (u2_del_ns > timeout_ns)
> > timeout_ns = u2_del_ns;
> >
> > +   return timeout_ns;
> > +}
> > +
> > +/* Returns the hub-encoded U2 timeout value. */
> > +static u16 xhci_calculate_u2_timeout(struct xhci_hcd *xhci,
> > +   struct usb_device *udev,
> > +   struct usb_endpoint_descriptor *desc)
> > +{
> > +   unsigned long long timeout_ns;
> > +
> > +   if (xhci->quirks & XHCI_INTEL_HOST)
> > +   timeout_ns = xhci_calculate_intel_u2_timeout(udev, desc);
> > +   else
> > +   timeout_ns = udev->u2_params.sel;
> > +
> > /* The U2 timeout is encoded in 256us intervals */
> > timeout_ns =

Re: [PATCH] usb_wwan: some improvement on write and resume

2014-04-25 Thread Johan Hovold 
On Fri, Apr 25, 2014 at 08:57:15AM +0800, xiao jin wrote:
> When enable usb serial for modem data, sometimes the tty is blocked
> in tty_wait_until_sent because portdata->out_busy always is set and
> have no chance to be cleared.
>
> We have found two scenarios lead to portdata->out_busy problem.
> 1. usb_wwan_write set portdata->out_busy firstly, then try autopm
> async with error. No out urb submit and no usb_wwan_outdat_callback
> to this write, portdata->out_busy can't be cleared.
> 2. usb_wwan_resume run play_delayed() and spin_unlock, but
> intfdata->suspended still is not set to zero. At this time
> usb_wwan_write is called and anchor the urb to delay list. Then resume
> keep running but the delayed urb have no chance to be commit until next
> resume. If the time of next resume is far away, tty will be blocked
> in tty_wait_until_sent during time.

First of all, good catch of both of these issues.

They are however two distinct bugs and should be fixed separately. Could
you split the fixes into two patches and resubmit?

Please also include a more descriptive subject line for each patch, for
example:

"USB: usb_wwan: fix urb leak in write error path"
"USB: usb_wwan: fix race between write and resume"

You should probably point out that the write-resume race could also lead
to writes being reordered in the description of that patch.

> The patch make some enhancement on write and resume.
> 1. clear portdata->out_busy if usb_wwan_write try autopm async with
> error.
> 2. put play_Delayed and intfdata->suspended together in the spinlock,
> it's to avoid the write race during resume.

As I mentioned in the cdc-acm PM thread, there are a few more issues
with autosuspend in usb-serial so I'll include your patches in a
series that I'm preparing. Some other stuff got in the way this week,
but hopefully I'll find the time to finish it this week.

Thanks,
Johan
--
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: serial: fix sysfs-attribute removal deadlock

2014-04-25 Thread Johan Hovold 
On Fri, Apr 25, 2014 at 10:16:57AM +0800, Li Zhong wrote:
> On Thu, 2014-04-24 at 16:52 +0200, Johan Hovold wrote:

> > No, this isn't self removal. The driver-attribute (not device-attribute)
> > store operation simply grabs a lock that is also held while the driver
> > is being deregistered at module unload. Taking a reference to the module
> > in this case will prevent deregistration while store is running.
> > 
> > But it seems like this can be solved for usb-serial by simply not
> > holding the lock while deregistering.
> 
> I didn't look carefully about this lock. 
> 
> But I'm not sure whether there are such requirements for driver
> attributes:
> 
> some lock needs be grabbed in the driver attributes store callbacks, and
> the same lock also needs to be grabbed during driver unregister. 
> 
> If we have such requirements currently or in the future, I think they
> could all be solved by breaking active protection after get the module
> reference.

Yes, if we find any such cases, but I don't think it should be done
generally (as in one of your earlier posts).

Active protection is usually exactly what prevents the driver from being
deregistered, and would only need to be broken to avoid any ABBA
deadlocks from being reported by lockdep (the module reference would be
enough to prevent the actual deadlock).

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

Re: [PATCH 2/5] xhci: Use pci_enable_msix_exact() instead of pci_enable_msix()

2014-04-25 Thread Mathias Nyman 

On 04/24/2014 10:49 PM, Greg KH wrote:

On Tue, Apr 22, 2014 at 03:22:59PM +0300, Mathias Nyman wrote:

From: Alexander Gordeev 

As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range()  or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.

Signed-off-by: Alexander Gordeev 
Cc: Sarah Sharp 
Cc: Greg Kroah-Hartman 
Cc: linux-usb@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Mathias Nyman 
---
  drivers/usb/host/xhci.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 988ed5f..b0b8399 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -291,7 +291,7 @@ static int xhci_setup_msix(struct xhci_hcd *xhci)
xhci->msix_entries[i].vector = 0;
}

-   ret = pci_enable_msix(pdev, xhci->msix_entries, xhci->msix_count);
+   ret = pci_enable_msix_exact(pdev, xhci->msix_entries, xhci->msix_count);


Why is this change needed for 3.15-final?



Can't remember why I thought this was needed for 3.15
Looks like other subsystems (like PCI) just queued similar MSI changes 
for 3.16.


I'll move it to the patchseries for usb-next

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

[PATCH v2 1/2] usb: ohci-exynos: Add facility to use phy provided by the generic phy framework

2014-04-25 Thread Vivek Gautam 
Add support to consume phy provided by Generic phy framework.
Keeping the support for older usb-phy intact right now, in order
to prevent any functionality break in absence of relevant
device tree side change for ohci-exynos.
Once we move to new phy in the device nodes for ohci, we can
remove the support for older phys.

Signed-off-by: Vivek Gautam 
Cc: Jingoo Han 
Cc: Alan Stern 
---

Changes from v1:
 - Made two separate routines for exynos_ohci_phyg_on() and
   exynos_ohci_phyg_off().
 - Separated out the phy-get related code from probe() to separate function
   exynos_ehci_get_phy().
 - Using proper error labels in the code.

 .../devicetree/bindings/usb/exynos-usb.txt |   19 +++
 drivers/usb/host/ohci-exynos.c |  123 ++--
 2 files changed, 132 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt 
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index d967ba1..03b7e43 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -38,6 +38,15 @@ Required properties:
  - interrupts: interrupt number to the cpu.
  - clocks: from common clock binding: handle to usb clock.
  - clock-names: from common clock binding: Shall be "usbhost".
+ - port: if in the SoC there are OHCI phys, they should be listed here.
+   One phy per port. Each port should have its 'reg' entry.
+   - reg: port number on OHCI controller, e.g
+  On Exynos5250, port 0 is USB2.0 otg phy
+ port 1 is HSIC phy0
+ port 2 is HSIC phy1
+   - phys: from the *Generic PHY* bindings specifying phy used by port.
+   - phy-names: from the *Generic PHY* bindings specifying name of phy
+used by the port.
 
 Example:
usb@1212 {
@@ -47,6 +56,16 @@ Example:
 
clocks = <&clock 285>;
clock-names = "usbhost";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port@0 {
+   reg = <0>;
+   phys = <&usb2phy 1>;
+   phy-names = "host";
+   status = "disabled";
+   };
+
};
 
 DWC3
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 68588d8..eac47cb 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -33,12 +34,111 @@ static struct hc_driver __read_mostly 
exynos_ohci_hc_driver;
 
 #define to_exynos_ohci(hcd) (struct exynos_ohci_hcd *)(hcd_to_ohci(hcd)->priv)
 
+#define PHY_NUMBER 3
 struct exynos_ohci_hcd {
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
+   struct phy *phy_g[PHY_NUMBER];
 };
 
+static int exynos_ohci_get_phy(struct platform_device *pdev,
+   struct exynos_ohci_hcd *exynos_ohci)
+{
+   struct device_node *child;
+   struct phy *phy;
+   int phy_number;
+   int ret = 0;
+
+   exynos_ohci->phy = devm_usb_get_phy(&pdev->dev, USB_PHY_TYPE_USB2);
+   if (IS_ERR(exynos_ohci->phy)) {
+   ret = PTR_ERR(exynos_ohci->phy);
+   /* This is the case when PHY config is disabled */
+   if (ret == -ENXIO || ret == -ENODEV) {
+   dev_dbg(&pdev->dev, "Failed to get usb2 phy\n");
+   exynos_ohci->phy = NULL;
+   ret = 0;
+   } else if (ret == -EPROBE_DEFER) {
+   goto fail_phy;
+   } else {
+   dev_err(&pdev->dev, "no usb2 phy configured\n");
+   goto fail_phy;
+   }
+   } else {
+   exynos_ohci->otg = exynos_ohci->phy->otg;
+   }
+
+   /* Getting generic phy:
+* We are keeping both types of phys as a part of transiting OHCI
+* to generic phy framework, so that in absence of supporting dts
+* changes the functionality doesn't break.
+* Once we move the ohci dt nodes to use new generic phys,
+* we can remove support for older PHY in this driver.
+*/
+   for_each_available_child_of_node(pdev->dev.of_node, child) {
+   ret = of_property_read_u32(child, "reg", &phy_number);
+   if (ret) {
+   dev_err(&pdev->dev, "Failed to parse device tree\n");
+   of_node_put(child);
+   goto fail_phy;
+   }
+   if (phy_number >= PHY_NUMBER) {
+   dev_err(&pdev->dev, "Invalid number of PHYs\n");
+   of_node_put(child);
+   ret = -EINVAL;
+   goto fail_phy;
+   }
+   phy = devm_of_phy_get(&pdev->dev, child, 0);
+   of_node_put(child);
+

[PATCH v7 2/2] usb: ehci-exynos: Change to use phy provided by the generic phy framework

2014-04-25 Thread Vivek Gautam 
From: Kamil Debski 

Add the phy provider, supplied by new Exynos-usb2phy using
Generic phy framework.
Keeping the support for older USB phy intact right now, in order
to prevent any functionality break in absence of relevant
device tree side change for ehci-exynos.
Once we move to new phy in the device nodes for ohci, we can
remove the support for older phys.

Signed-off-by: Kamil Debski 
[gautam.vi...@samsung.com: Addressed review comments from mailing list]
[gautam.vi...@samsung.com: Kept the code for old usb-phy, and just
added support for new exynos5-usb2phy in generic phy framework]
[gautam.vi...@samsung.com: Edited the commit message]
Signed-off-by: Vivek Gautam 
---

Although the patch-series is named as 'v2' version, but
this patch is named as 'v7' since it is the next version of the patch
sent by Kamil:
[PATCH v6 8/8] usb: ehci-exynos: Change to use phy provided by the generic phy 
framework
https://lkml.org/lkml/2014/1/29/298

Changes from v6:
 - Added documentation for 'port' property including all its fields -
  reg, phys, phy-names.
 - Fixed looping in 'exynos_phys_on()' and renamed this function as
  exynos_ehci_phyg_on()
 - To avoid any regression because of movement from old usb-phy drivers
   to new generic phy framework, keeping the changes for old usb-phy driver
   intact, and just added support for phy provider from generic phy framework.
 - Separated out the phy-get related code from probe() to separate function
   exynos_ehci_get_phy().

 .../devicetree/bindings/usb/exynos-usb.txt |   18 +++
 drivers/usb/host/ehci-exynos.c |  123 ++--
 2 files changed, 131 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt 
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index 03b7e43..4f368b0 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -12,6 +12,15 @@ Required properties:
  - interrupts: interrupt number to the cpu.
  - clocks: from common clock binding: handle to usb clock.
  - clock-names: from common clock binding: Shall be "usbhost".
+ - port: if in the SoC there are EHCI phys, they should be listed here.
+   One phy per port. Each port should have its 'reg' entry.
+   - reg: port number on EHCI controller, e.g
+  On Exynos5250, port 0 is USB2.0 otg phy
+ port 1 is HSIC phy0
+ port 2 is HSIC phy1
+   - phys: from the *Generic PHY* bindings; specifying phy used by port.
+   - phy-names: from the *Generic PHY* bindings; specifying name of phy
+used by the port.
 
 Optional properties:
  - samsung,vbus-gpio:  if present, specifies the GPIO that
@@ -27,6 +36,15 @@ Example:
 
clocks = <&clock 285>;
clock-names = "usbhost";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port@0 {
+   reg = <0>;
+   phys = <&usb2phy 1>;
+   phy-names = "host";
+   status = "disabled";
+   };
};
 
 OHCI
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 7f425ac..fe0509b 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -42,14 +43,78 @@
 static const char hcd_name[] = "ehci-exynos";
 static struct hc_driver __read_mostly exynos_ehci_hc_driver;
 
+#define PHY_NUMBER 3
 struct exynos_ehci_hcd {
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
+   struct phy *phy_g[PHY_NUMBER];
 };
 
 #define to_exynos_ehci(hcd) (struct exynos_ehci_hcd *)(hcd_to_ehci(hcd)->priv)
 
+static int exynos_ehci_get_phy(struct platform_device *pdev,
+   struct exynos_ehci_hcd *exynos_ehci)
+{
+   struct device_node *child;
+   struct phy *phy;
+   int phy_number;
+   int ret = 0;
+
+   exynos_ehci->phy = devm_usb_get_phy(&pdev->dev, USB_PHY_TYPE_USB2);
+   if (IS_ERR(exynos_ehci->phy)) {
+   ret = PTR_ERR(exynos_ehci->phy);
+   /* This is the case when PHY config is disabled */
+   if (ret == -ENXIO || ret == -ENODEV) {
+   dev_dbg(&pdev->dev, "Failed to get usb2 phy\n");
+   exynos_ehci->phy = NULL;
+   ret = 0;
+   } else if (ret == -EPROBE_DEFER) {
+   goto fail_phy;
+   } else {
+   dev_err(&pdev->dev, "no usb2 phy configured\n");
+   goto fail_phy;
+   }
+   } else {
+   exynos_ehci->otg = exynos_ehci->phy->otg;
+   }
+
+   for_each_available_child_of_node(pdev->dev.of_node, child) {
+   ret = of_property_read_u32(child, "reg", &phy_

[PATCH 0/2] usb: ehci/ohci-exynos: Move to generic phy framework

2014-04-25 Thread Vivek Gautam 
Added required support for getting phy-provider from generic phy framework

Based and tested on 'usb-next' branch of Greg's usb tree, with relevant
device tree patches (which i will sending soon).

Patch:
usb: ehci-exynos: Change to use phy provided by the generic phy framework
is the patch from Kamil's usb phy patch-series:
[PATCH v6 8/8] usb: ehci-exynos: Change to use phy provided by the generic phy 
framework
This is reworked for addressing review comments received in mailing list.

Patch:
usb: ohci-exynos: Add facility to use phy provided by the generic phy framework
is also reworked for addressing review comments.

Corresponding changelog for patches mentioned in each patch.

Kamil Debski (1):
  usb: ehci-exynos: Change to use phy provided by the generic phy
framework

Vivek Gautam (1):
  usb: ohci-exynos: Add facility to use phy provided by the generic phy
framework

 .../devicetree/bindings/usb/exynos-usb.txt |   37 ++
 drivers/usb/host/ehci-exynos.c |  123 ++--
 drivers/usb/host/ohci-exynos.c |  123 ++--
 3 files changed, 263 insertions(+), 20 deletions(-)

-- 
1.7.10.4

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

[PATCH v8 2/2] usb: ehci-exynos: Change to use phy provided by the generic phy framework

2014-04-25 Thread Vivek Gautam 
From: Kamil Debski 

Add the phy provider, supplied by new Exynos-usb2phy using
Generic phy framework.
Keeping the support for older USB phy intact right now, in order
to prevent any functionality break in absence of relevant
device tree side change for ehci-exynos.
Once we move to new phy in the device nodes for ehci, we can
remove the support for older phys.

Signed-off-by: Kamil Debski 
[gautam.vi...@samsung.com: Addressed review comments from mailing list]
[gautam.vi...@samsung.com: Kept the code for old usb-phy, and just
added support for new exynos5-usb2phy in generic phy framework]
[gautam.vi...@samsung.com: Edited the commit message]
Signed-off-by: Vivek Gautam 
---

Changes from v7:
just edited in the commit message: s/ohci/ehci

Although the patch-series is named as 'v2' version, but
this patch is named as 'v7' since it is the next version of the patch
sent by Kamil:
[PATCH v6 8/8] usb: ehci-exynos: Change to use phy provided by the generic phy 
framework
https://lkml.org/lkml/2014/1/29/298

Changes from v6:
 - Added documentation for 'port' property including all its fields -
  reg, phys, phy-names.
 - Fixed looping in 'exynos_phys_on()' and renamed this function as
  exynos_ehci_phyg_on()
 - To avoid any regression because of movement from old usb-phy drivers
   to new generic phy framework, keeping the changes for old usb-phy driver
   intact, and just added support for phy provider from generic phy framework.
 - Separated out the phy-get related code from probe() to separate function
   exynos_ehci_get_phy().

 .../devicetree/bindings/usb/exynos-usb.txt |   18 +++
 drivers/usb/host/ehci-exynos.c |  123 ++--
 2 files changed, 131 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt 
b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index 03b7e43..4f368b0 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -12,6 +12,15 @@ Required properties:
  - interrupts: interrupt number to the cpu.
  - clocks: from common clock binding: handle to usb clock.
  - clock-names: from common clock binding: Shall be "usbhost".
+ - port: if in the SoC there are EHCI phys, they should be listed here.
+   One phy per port. Each port should have its 'reg' entry.
+   - reg: port number on EHCI controller, e.g
+  On Exynos5250, port 0 is USB2.0 otg phy
+ port 1 is HSIC phy0
+ port 2 is HSIC phy1
+   - phys: from the *Generic PHY* bindings; specifying phy used by port.
+   - phy-names: from the *Generic PHY* bindings; specifying name of phy
+used by the port.
 
 Optional properties:
  - samsung,vbus-gpio:  if present, specifies the GPIO that
@@ -27,6 +36,15 @@ Example:
 
clocks = <&clock 285>;
clock-names = "usbhost";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port@0 {
+   reg = <0>;
+   phys = <&usb2phy 1>;
+   phy-names = "host";
+   status = "disabled";
+   };
};
 
 OHCI
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 7f425ac..fe0509b 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -42,14 +43,78 @@
 static const char hcd_name[] = "ehci-exynos";
 static struct hc_driver __read_mostly exynos_ehci_hc_driver;
 
+#define PHY_NUMBER 3
 struct exynos_ehci_hcd {
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
+   struct phy *phy_g[PHY_NUMBER];
 };
 
 #define to_exynos_ehci(hcd) (struct exynos_ehci_hcd *)(hcd_to_ehci(hcd)->priv)
 
+static int exynos_ehci_get_phy(struct platform_device *pdev,
+   struct exynos_ehci_hcd *exynos_ehci)
+{
+   struct device_node *child;
+   struct phy *phy;
+   int phy_number;
+   int ret = 0;
+
+   exynos_ehci->phy = devm_usb_get_phy(&pdev->dev, USB_PHY_TYPE_USB2);
+   if (IS_ERR(exynos_ehci->phy)) {
+   ret = PTR_ERR(exynos_ehci->phy);
+   /* This is the case when PHY config is disabled */
+   if (ret == -ENXIO || ret == -ENODEV) {
+   dev_dbg(&pdev->dev, "Failed to get usb2 phy\n");
+   exynos_ehci->phy = NULL;
+   ret = 0;
+   } else if (ret == -EPROBE_DEFER) {
+   goto fail_phy;
+   } else {
+   dev_err(&pdev->dev, "no usb2 phy configured\n");
+   goto fail_phy;
+   }
+   } else {
+   exynos_ehci->otg = exynos_ehci->phy->otg;
+   }
+
+   for_each_available_child_of_node(pdev->dev.of_node, child)

[PATCH v7 0/2] dts: Add usb2phy to Exynos 5250

2014-04-25 Thread Vivek Gautam 
Next version of patch for Kamil's patch:
[PATCH v6 4/8] dts: Add usb2phy to Exynos 5250
https://lkml.org/lkml/2014/1/29/302

Based on 'for-next' branch of Kgene's linux-samsung tree.
Tested with driver side patches:
[PATCH 0/2] usb: ehci/ohci-exynos: Move to generic phy framework
https://www.mail-archive.com/linux-usb@vger.kernel.org/msg41246.html

Changes from v6:
 - Splitted the patch into two:
adding syscon nodes to Exynos5250 and Exynos5420 in first;
and phy entry change in the second.
 - Changed the name of phandle for usb2phy from 'usb2_phy_new'
   to 'usb2_phy_gen' indicating generic phy.
 - Using clock macros in dt entries.

Kamil Debski (1):
  ARM: dts: Add usb2phy to Exynos 5250

Vivek Gautam (1):
  ARM: dts: Add sysreg sytem controller node to exynos5250 and
exynos5420

 arch/arm/boot/dts/exynos5250.dtsi |   31 +++
 arch/arm/boot/dts/exynos5420.dtsi |5 +
 2 files changed, 36 insertions(+)

-- 
1.7.10.4

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

[PATCH v7 2/2] ARM: dts: Add usb2phy to Exynos 5250

2014-04-25 Thread Vivek Gautam 
From: Kamil Debski 

Add support to PHY of USB2 of the Exynos 5250 SoC.

Signed-off-by: Kamil Debski 
[gautam.vi...@samsung.com: Split the usb phy entries from
syscon entries from earlier patch: dts: Add usb2phy to Exynos 5250]
[gautam.vi...@samsung.com: Added phy entry for OHCI also along with EHCI]
Signed-off-by: Vivek Gautam 
---
 arch/arm/boot/dts/exynos5250.dtsi |   26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 70f0cd5..51e554c 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -563,6 +563,14 @@
 
clocks = <&clock CLK_USB2>;
clock-names = "usbhost";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port@0 {
+   reg = <0>;
+   phys = <&usb2_phy_gen 1>;
+   phy-names = "host";
+   status = "ok";
+   };
};
 
usb@1212 {
@@ -572,6 +580,14 @@
 
clocks = <&clock CLK_USB2>;
clock-names = "usbhost";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port@0 {
+   reg = <0>;
+   phys = <&usb2_phy_gen 1>;
+   phy-names = "host";
+   status = "ok";
+   };
};
 
usb2_phy: usbphy@1213 {
@@ -589,6 +605,16 @@
};
};
 
+   usb2_phy_gen: phy@1213 {
+   compatible = "samsung,exynos5250-usb2-phy";
+   reg = <0x1213 0x100>;
+   clocks = <&clock CLK_USB2>, <&clock CLK_FIN_PLL>;
+   clock-names = "phy", "ref";
+   #phy-cells = <1>;
+   samsung,sysreg-phandle = <&sysreg_system_controller>;
+   samsung,pmureg-phandle = <&pmu_system_controller>;
+   };
+
pwm: pwm@12dd {
compatible = "samsung,exynos4210-pwm";
reg = <0x12dd 0x100>;
-- 
1.7.10.4

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

[PATCH v7 1/2] ARM: dts: Add sysreg sytem controller node to exynos5250 and exynos5420

2014-04-25 Thread Vivek Gautam 
This patch adds sysreg-syscon node to exynos5250 and exynos5420 device
tree, to access System Register's registers using syscon driver.

Signed-off-by: Kamil Debski 
[gautam.vi...@samsung.com: Split this syreg-syscon dts entry from
dts: Add usb2phy to Exynos 5250 patch]
[gautam.vi...@samsung.com: added similar syscon entry for exynos5420]
Signed-off-by: Vivek Gautam 
---
 arch/arm/boot/dts/exynos5250.dtsi |5 +
 arch/arm/boot/dts/exynos5420.dtsi |5 +
 2 files changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 3742331..70f0cd5 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -175,6 +175,11 @@
reg = <0x1004 0x5000>;
};
 
+   sysreg_system_controller: syscon@1005 {
+   compatible = "samsung,exynos5250-sys", "syscon";
+   reg = <0x1005 0x5000>;
+   };
+
watchdog@101D {
compatible = "samsung,exynos5250-wdt";
reg = <0x101D 0x100>;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index c3a9a66..cfa3755 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -675,6 +675,11 @@
reg = <0x1004 0x5000>;
};
 
+   sysreg_system_controller: syscon@1005 {
+   compatible = "samsung,exynos5420-sys", "syscon";
+   reg = <0x1005 0x5000>;
+   };
+
tmu_cpu0: tmu@1006 {
compatible = "samsung,exynos5420-tmu";
reg = <0x1006 0x100>;
-- 
1.7.10.4

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

Re: [PATCH v2 01/13] Documentation: add extcon devicetree bindings

2014-04-25 Thread Robert Baldyga 
On 04/22/2014 09:51 PM, Mark Brown wrote:
> On Mon, Apr 14, 2014 at 01:46:12PM +0200, Robert Baldyga wrote:
> 
> That's quite some CC list you've got there, and the mail seems a bit
> corrupted too (it confused my MUA).
> 
>> This patch adds extcon devicetree bindings. Documentation describes in 
>> general
>> client and provider bindings, and contains detailed desctiprion of bindings
>> for each extcon provider.
>>
>> Signed-off-by: Robert Baldyga 
>> ---
>>  .../devicetree/bindings/extcon/extcon-adc-jack.txt |   60 
>> +++
>>  .../devicetree/bindings/extcon/extcon-arizona.txt  |   47 +++
>>  .../devicetree/bindings/extcon/extcon-bindings.txt |   36 +++
>>  .../devicetree/bindings/extcon/extcon-gpio.txt |   63 
>> 
>>  .../devicetree/bindings/extcon/extcon-max14577.txt |   49 +++
>>  .../devicetree/bindings/extcon/extcon-max77693.txt |   56 +
>>  .../devicetree/bindings/extcon/extcon-max8997.txt  |   49 +++
>>  .../devicetree/bindings/extcon/extcon-palmas.txt   |   37 ++--
> 
> This is creating device tree bindings for MFD components as devices when
> those MFD components aren't well isolated from the rest of the device.
> If we need to add extcon bindings the device should have the flexibility
> to decide where to add the properties, and really things should be set
> up so there's less duplication in the documentation.

Those components has their own addresses on i2c bus, so they are,
technically, separate devices, and they can (should?) be described by
separate nodes. And I think it doesn't matter if they are grouped in one
chip.

However, it's easy to change it (give mfd master driver node to extcon),
and we can have extcon device defined without additional node, and then
parent node is an extcon node.

Best regards
Robert Baldyga
Samsung R&D Institute Poland

> 
>> +The following is the list of cables detected by the controller. Each
>> +cable is assigned an identifier and client nodes use this identifies
>> +to specify the cable which they are interested in.
>> +
>> +  Cable ID
>> +  
>> +
>> +  Mechanical0
>> +  Microphone1
>> +  Headphone 2
>> +  Line-out  3
>> +
>> +Example 1: An example of a extcon controller node is listed below.
>> +
>> +extcon: arizona-extcon {
> 
> The above doesn't entirely reflect what the hardware is capable of doing
> - it reflects the default software configuration for the device but it's
> got a wider feature set.
> 


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

[PATCH] USB: io_ti: fix firmware download on big-endian machines

2014-04-25 Thread Johan Hovold 
During firmware download the device expects memory addresses in
big-endian byte order. As the wIndex parameter which hold the address is
sent in little-endian byte order regardless of host byte order, we need
to use swab16 rather than cpu_to_be16.

Also make sure to handle the struct ti_i2c_desc size parameter which is
returned in little-endian byte order.

Reported-by: Ludovic Drolez 
Tested-by: Ludovic Drolez 
Cc: sta...@vger.kernel.org
Signed-off-by: Johan Hovold 
---

Here's another fix for v3.15-final. It has been back-ported and tested by
Ludovic on v3.3 (and v3.2 little-endian).

Thanks,
Johan


 drivers/usb/serial/io_ti.c | 50 ++
 1 file changed, 33 insertions(+), 17 deletions(-)

diff --git a/drivers/usb/serial/io_ti.c b/drivers/usb/serial/io_ti.c
index a2db5be9c305..df90dae53eb9 100644
--- a/drivers/usb/serial/io_ti.c
+++ b/drivers/usb/serial/io_ti.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -280,7 +281,7 @@ static int read_download_mem(struct usb_device *dev, int 
start_address,
 {
int status = 0;
__u8 read_length;
-   __be16 be_start_address;
+   u16 be_start_address;
 
dev_dbg(&dev->dev, "%s - @ %x for %d\n", __func__, start_address, 
length);
 
@@ -296,10 +297,14 @@ static int read_download_mem(struct usb_device *dev, int 
start_address,
if (read_length > 1) {
dev_dbg(&dev->dev, "%s - @ %x for %d\n", __func__, 
start_address, read_length);
}
-   be_start_address = cpu_to_be16(start_address);
+   /*
+* NOTE: Must use swab as wIndex is sent in little-endian
+*   byte order regardless of host byte order.
+*/
+   be_start_address = swab16((u16)start_address);
status = ti_vread_sync(dev, UMPC_MEMORY_READ,
(__u16)address_type,
-   (__force __u16)be_start_address,
+   be_start_address,
buffer, read_length);
 
if (status) {
@@ -394,7 +399,7 @@ static int write_i2c_mem(struct edgeport_serial *serial,
struct device *dev = &serial->serial->dev->dev;
int status = 0;
int write_length;
-   __be16 be_start_address;
+   u16 be_start_address;
 
/* We can only send a maximum of 1 aligned byte page at a time */
 
@@ -409,11 +414,16 @@ static int write_i2c_mem(struct edgeport_serial *serial,
__func__, start_address, write_length);
usb_serial_debug_data(dev, __func__, write_length, buffer);
 
-   /* Write first page */
-   be_start_address = cpu_to_be16(start_address);
+   /*
+* Write first page.
+*
+* NOTE: Must use swab as wIndex is sent in little-endian byte order
+*   regardless of host byte order.
+*/
+   be_start_address = swab16((u16)start_address);
status = ti_vsend_sync(serial->serial->dev,
UMPC_MEMORY_WRITE, (__u16)address_type,
-   (__force __u16)be_start_address,
+   be_start_address,
buffer, write_length);
if (status) {
dev_dbg(dev, "%s - ERROR %d\n", __func__, status);
@@ -436,11 +446,16 @@ static int write_i2c_mem(struct edgeport_serial *serial,
__func__, start_address, write_length);
usb_serial_debug_data(dev, __func__, write_length, buffer);
 
-   /* Write next page */
-   be_start_address = cpu_to_be16(start_address);
+   /*
+* Write next page.
+*
+* NOTE: Must use swab as wIndex is sent in little-endian byte
+*   order regardless of host byte order.
+*/
+   be_start_address = swab16((u16)start_address);
status = ti_vsend_sync(serial->serial->dev, UMPC_MEMORY_WRITE,
(__u16)address_type,
-   (__force __u16)be_start_address,
+   be_start_address,
buffer, write_length);
if (status) {
dev_err(dev, "%s - ERROR %d\n", __func__, status);
@@ -585,8 +600,8 @@ static int get_descriptor_addr(struct edgeport_serial 
*serial,
if (rom_desc->Type == desc_type)
return start_address;
 
-   start_address = start_address + sizeof(struct ti_i2c_desc)
-   + rom_desc->Size;
+   start_address = start_address + sizeof(struct ti_i2c_desc) +
+   le16_to_cpu(rom_desc->Size);
 
} while ((start_a

RE: [PATCH] USB: io_ti: fix firmware download on big-endian machines

2014-04-25 Thread David Laight 
From: Johan Hovold
> During firmware download the device expects memory addresses in
> big-endian byte order. As the wIndex parameter which hold the address is
> sent in little-endian byte order regardless of host byte order, we need
> to use swab16 rather than cpu_to_be16.

That doesn't sound correct.
If the value needs to be little-endian, shouldn't you be using
cpu_to_le16() ?

If there is a second cpu_to_be16() being done later on then
the code might be right, but the comments are misleading.

David



--
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: serial: fix sysfs-attribute removal deadlock

2014-04-25 Thread Alan Stern 
On Fri, 25 Apr 2014, Li Zhong wrote:

> > I don't get why try_module_get() matters here.  We can't call into
> > ->store if the object at hand is already destroyed and the underlying
> > module can't go away if the target device is still alive.
> > try_module_get() doesn't actually protect the object.  Why does that
> > matter?  This is self removal, right?  Can you please take a look at
> > kernfs_remove_self()?
> 
> This is about one process writing something to driver attributes, and
> one process trying to unload this driver. 
> 
> I think try_module_get() could detect whether the driver is being
> unloaded, and if not, prevent it from being unloaded, so it could
> protect the object here by not allow the driver to be unloaded.

That isn't how try_module_get() works.  If the module is being 
unloaded, try_module_get() simply fails.  It does not prevent the 
module from being unloaded -- that's why its name begins with "try".

Alan Stern

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

Re: [PATCH] USB: serial: fix sysfs-attribute removal deadlock

2014-04-25 Thread Alan Stern 
On Fri, 25 Apr 2014, Li Zhong wrote:

> > No, this isn't self removal. The driver-attribute (not device-attribute)
> > store operation simply grabs a lock that is also held while the driver
> > is being deregistered at module unload. Taking a reference to the module
> > in this case will prevent deregistration while store is running.
> > 
> > But it seems like this can be solved for usb-serial by simply not
> > holding the lock while deregistering.
> 
> I didn't look carefully about this lock. 
> 
> But I'm not sure whether there are such requirements for driver
> attributes:
> 
> some lock needs be grabbed in the driver attributes store callbacks, and
> the same lock also needs to be grabbed during driver unregister. 

In this case, the lock does _not_ need to be grabbed during driver 
unregister.  The driver grabs the lock, but it doesn't need to.

> If we have such requirements currently or in the future, I think they
> could all be solved by breaking active protection after get the module
> reference.

No!  That would be very bad.

Unloading modules is quite different from unbinding drivers.  After the
driver is unbound, its attribute callback routines can continue to run.  
But after a driver module has been unloaded, its attribute callback 
routines _cannot_ run because they aren't present in memory any more.

If we allowed a module to be unloaded while one of its callbacks was 
running (because active protection was broken), imagine what would 
happen...

Alan Stern

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

[PATCH v2 00/18] USB support for Armada 38x and Armada 375

2014-04-25 Thread Gregory CLEMENT 
Hello,

This patch set adds the USB support for the Armada 38x Armada
375. These SoCs use an xHCI but still need specific initialization,
mainly to setup the windows memory on the mbus. They also use the same
controller that the other mvebu SoC for EHCI.

Since the 1st version this patch set add xHCI support for Armada 375
but also EHCI support for Armada 375 and Armada 38x. For EHCI it was
mainly a matter of updating the device tree.

The first patch is just a small clean-up

The second patch extend the xhci-plat driver to allow to use the
clocks if they are available.

The third patch add support the Armada 38x by introducing a quirk to
setup the memory windows on the mbus for Armada 38x.

Then the forth patch update the binding documentation.

The 10th patch add support for the Armada 375 using what have been
done for Armada 38x

The 11th  patch update the binding documentation with Armada 375 binding.

This patches 1 to 4 and 10 to 11 should go through the xhci subsystem.

The rest of the series is more platform specific and should go through
the mvebu tree, except the patch 9 that should be taken directly by
the arm-soc maintainer.

Thanks,

Gregory CLEMENT (18):
  usb: host: xhci-plat: Sort the headers in alphabetic order
  usb: host: xhci-plat: Add clocks support
  usb: host: xhci-plat: Add support for the Armada 38x
  xhci-platform: Add a new controller using xhci: Armada 38x
  ARM: mvebu: Add Device Tree description of xHCI hosts on Armada 38x
  ARM: mvebu: Add Device Tree description of EHCI hosts on Armada 38x
  ARM: mvebu: Add USB3 support for Armada 38x
  ARM: configs: Add usb_xhci_mvebu to mvebu_v7_defconfig
  ARM: configs: Add usb_xhci_mvebu to multi_v7_defconfig
  usb: host: xhci-plat: Add support for the Armada 375
  xhci-platform: Add a new controller using xhci: Armada 375
  ARM: mvebu: Add Device Tree description of USB cluster controller on
Armada 375
  dt: binding: Armada 375 USB cluster
  ARM: mvebu: Add support for USB cluster on the Armada 375 SoC
  ARM: mvebu: Add USB3 support for Armada 375
  ARM: mvebu: add USB3 controller Device Tree details for Armada 375
  ARM: mvebu: dts: Enable USB3 in Armada 375 DB
  ARM: mvebu: Add Device Tree description of EHCI hosts on Armada 375

 .../bindings/arm/armada-375-usb-cluster.txt| 17 
 Documentation/devicetree/bindings/usb/usb-xhci.txt |  4 +-
 arch/arm/boot/dts/armada-375-db.dts| 10 ++-
 arch/arm/boot/dts/armada-375.dtsi  | 41 +
 arch/arm/boot/dts/armada-385-db.dts| 12 +++
 arch/arm/boot/dts/armada-385-rd.dts|  4 +
 arch/arm/boot/dts/armada-38x.dtsi  | 25 ++
 arch/arm/configs/multi_v7_defconfig|  1 +
 arch/arm/configs/mvebu_v7_defconfig|  1 +
 arch/arm/mach-mvebu/Kconfig|  2 +
 arch/arm/mach-mvebu/Makefile   |  2 +-
 arch/arm/mach-mvebu/usb-cluster.c  | 96 ++
 drivers/usb/host/Kconfig   |  7 ++
 drivers/usb/host/Makefile  |  1 +
 drivers/usb/host/xhci-mvebu.c  | 71 
 drivers/usb/host/xhci-mvebu.h  | 22 +
 drivers/usb/host/xhci-plat.c   | 67 +--
 17 files changed, 374 insertions(+), 9 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/armada-375-usb-cluster.txt
 create mode 100644 arch/arm/mach-mvebu/usb-cluster.c
 create mode 100644 drivers/usb/host/xhci-mvebu.c
 create mode 100644 drivers/usb/host/xhci-mvebu.h

-- 
1.8.1.2

--
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 06/18] ARM: mvebu: Add Device Tree description of EHCI hosts on Armada 38x

2014-04-25 Thread Gregory CLEMENT 
The Marvell Armada 38x SoCs contain one EHCI host. This commit adds
the Device Tree description of this interface at the SoC level, and
also enables the USB2 port on the Armada 385 DB platform.

Signed-off-by: Gregory CLEMENT 
---
 arch/arm/boot/dts/armada-385-db.dts | 4 
 arch/arm/boot/dts/armada-38x.dtsi   | 8 
 2 files changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/armada-385-db.dts 
b/arch/arm/boot/dts/armada-385-db.dts
index d5db1466da82..91e3e449067f 100644
--- a/arch/arm/boot/dts/armada-385-db.dts
+++ b/arch/arm/boot/dts/armada-385-db.dts
@@ -65,6 +65,10 @@
phy-mode = "rgmii-id";
};
 
+   usb@5 {
+   status = "ok";
+   };
+
ethernet@7 {
status = "okay";
phy = <&phy0>;
diff --git a/arch/arm/boot/dts/armada-38x.dtsi 
b/arch/arm/boot/dts/armada-38x.dtsi
index 5913ce1cc601..11f1f9e28cbc 100644
--- a/arch/arm/boot/dts/armada-38x.dtsi
+++ b/arch/arm/boot/dts/armada-38x.dtsi
@@ -283,6 +283,14 @@
status = "disabled";
};
 
+   usb@5 {
+   compatible = "marvell,orion-ehci";
+   reg = <0x58000 0x500>;
+   interrupts = ;
+   clocks = <&gateclk 18>;
+   status = "disabled";
+   };
+
xor@60800 {
compatible = "marvell,orion-xor";
reg = <0x60800 0x100
-- 
1.8.1.2

--
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 18/18] ARM: mvebu: Add Device Tree description of EHCI hosts on Armada 375

2014-04-25 Thread Gregory CLEMENT 
The Marvell Armada 375 SoC contains one EHCI host. This commit adds
the Device Tree description of this interface at the SoC level.

Signed-off-by: Gregory CLEMENT 
---
 arch/arm/boot/dts/armada-375.dtsi | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/armada-375.dtsi 
b/arch/arm/boot/dts/armada-375.dtsi
index cbe64ba9eb65..349b9635bf3a 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -320,6 +320,24 @@
clocks = <&coreclk 0>;
};
 
+   /*
+* On Armada 375, USB2 host controller and
+* USB3 host controller are incompatible. That
+* means that in the dts of your board, you
+* can either select the USB2 controller:
+* marvell,orion-ehci or the USB3 controller:
+* marvell,armada-375-xhci, but not both. If
+* both controllers are selected, then the
+* kernel will select the USB3 by default.
+*/
+   usb@5 {
+   compatible = "marvell,orion-ehci";
+   reg = <0x5 0x500>;
+   interrupts = ;
+   clocks = <&gateclk 18>;
+   status = "disabled";
+   };
+
usb-cluster@18400 {
compatible = "marvell,armada-375-usb-cluster";
reg = <0x18400 0x4>;
-- 
1.8.1.2

--
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 14/18] ARM: mvebu: Add support for USB cluster on the Armada 375 SoC

2014-04-25 Thread Gregory CLEMENT 
The Armada 375 SoC comes with an USB2 host and device controller and
an USB3 controller. The USB cluster control register allows to manage
common features of both USB controllers.

Signed-off-by: Gregory CLEMENT 
---
 arch/arm/mach-mvebu/Makefile  |  2 +-
 arch/arm/mach-mvebu/usb-cluster.c | 96 +++
 2 files changed, 97 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-mvebu/usb-cluster.c

diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index a63e43b6b451..dec05e7e1802 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -4,7 +4,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := 
-I$(srctree)/$(src)/include \
 AFLAGS_coherency_ll.o  := -Wa,-march=armv7-a
 
 obj-y   += system-controller.o mvebu-soc-id.o
-obj-$(CONFIG_MACH_MVEBU_V7)  += board-v7.o
+obj-$(CONFIG_MACH_MVEBU_V7)  += board-v7.o usb-cluster.o
 obj-$(CONFIG_MACH_DOVE) += dove.o
 obj-$(CONFIG_ARCH_MVEBU)+= coherency.o coherency_ll.o pmsu.o
 obj-$(CONFIG_SMP)+= platsmp.o headsmp.o
diff --git a/arch/arm/mach-mvebu/usb-cluster.c 
b/arch/arm/mach-mvebu/usb-cluster.c
new file mode 100644
index ..4c15d282db23
--- /dev/null
+++ b/arch/arm/mach-mvebu/usb-cluster.c
@@ -0,0 +1,96 @@
+/*
+ * USB cluster support for Armada 375 platform.
+ *
+ * Copyright (C) 2014 Marvell
+ *
+ * Gregory CLEMENT 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ *
+ * Armada 375 comes with an USB2 host and device controller and an
+ * USB3 controller. The USB cluster control register allows to manage
+ * common features of both USB controller.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define USB2_PHY_CONFIG_ENABLE BIT(0) /* active low */
+
+static struct of_device_id of_usb_cluster_table[] = {
+   { .compatible = "marvell,armada-375-usb-cluster", },
+   { /* end of list */ },
+};
+
+static int __init mvebu_usb_cluster_init(void)
+{
+   struct device_node *np;
+
+   np = of_find_matching_node(NULL, of_usb_cluster_table);
+   if (np) {
+   void __iomem *usb_cluster_base;
+   u32 reg;
+   struct device_node *ehci_node, *xhci_node;
+   struct property *ehci_status;
+   bool use_usb3 = false;
+
+   usb_cluster_base = of_iomap(np, 0);
+   BUG_ON(!usb_cluster_base);
+
+   xhci_node = of_find_compatible_node(NULL, NULL,
+   "marvell,armada-375-xhci");
+
+   if (xhci_node && of_device_is_available(xhci_node))
+   use_usb3 = true;
+
+   ehci_node = of_find_compatible_node(NULL, NULL,
+   "marvell,orion-ehci");
+
+   if (ehci_node && of_device_is_available(ehci_node)
+   && use_usb3) {
+   /*
+* We can't use usb2 and usb3 in the same time, so let's
+* disbale usb2 and complain about it to the user askinf
+* to fix the device tree.
+*/
+
+   ehci_status = kzalloc(sizeof(struct property),
+   GFP_KERNEL);
+   WARN_ON(!ehci_status);
+
+   ehci_status->value = kstrdup("disabled", GFP_KERNEL);
+   WARN_ON(!ehci_status->value);
+
+   ehci_status->length = 8;
+   ehci_status->name = kstrdup("status", GFP_KERNEL);
+   WARN_ON(!ehci_status->name);
+
+   of_update_property(ehci_node, ehci_status);
+   pr_err("%s: armada-375-xhci and orion-ehci are 
incompatible for this SoC.\n",
+   __func__);
+   pr_err("Please fix your dts!\n");
+   pr_err("orion-ehci have been disabled by default...\n");
+
+   }
+
+   reg = readl(usb_cluster_base);
+   if (use_usb3)
+   reg |= USB2_PHY_CONFIG_ENABLE;
+   else
+   reg &= ~USB2_PHY_CONFIG_ENABLE;
+   writel(reg, usb_cluster_base);
+
+   of_node_put(ehci_node);
+   of_node_put(xhci_node);
+   of_node_put(np);
+   iounmap(usb_cluster_base);
+   }
+
+   return 0;
+}
+postcore_initcall(mvebu_usb_cluster_init);
-- 
1.8.1.2

--
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 17/18] ARM: mvebu: dts: Enable USB3 in Armada 375 DB

2014-04-25 Thread Gregory CLEMENT 
In order to enable the USB3 host controller on the Armada 375 DB
platform, we need to create a ranges at the soc node level to describe
the special static window for USB3.

Signed-off-by: Gregory CLEMENT 
---
 arch/arm/boot/dts/armada-375-db.dts | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/armada-375-db.dts 
b/arch/arm/boot/dts/armada-375-db.dts
index 9378d3136b41..928de536a0ff 100644
--- a/arch/arm/boot/dts/armada-375-db.dts
+++ b/arch/arm/boot/dts/armada-375-db.dts
@@ -30,8 +30,9 @@
};
 
soc {
-   ranges = ;
+   ranges = ;
 
internal-regs {
spi@10600 {
@@ -126,5 +127,10 @@
status = "okay";
};
};
+
+   usb3-controller {
+   status = "okay";
+   };
+
};
 };
-- 
1.8.1.2

--
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 15/18] ARM: mvebu: Add USB3 support for Armada 375

2014-04-25 Thread Gregory CLEMENT 
This patch add the selection of the config symbol to build the USB3
support for Armada 375.

Signed-off-by: Gregory CLEMENT 
---
 arch/arm/mach-mvebu/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 7960f218702b..95afc7677ee1 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -41,6 +41,7 @@ config MACH_ARMADA_375
select CPU_V7
select MACH_MVEBU_V7
select PINCTRL_ARMADA_375
+   select USB_ARCH_HAS_XHCI
help
  Say 'Y' here if you want your kernel to support boards based
  on the Marvell Armada 375 SoC with device tree.
-- 
1.8.1.2

--
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 16/18] ARM: mvebu: add USB3 controller Device Tree details for Armada 375

2014-04-25 Thread Gregory CLEMENT 
This commit adds the support for the USB3 controller in the Armada 375
SoC. The following things have been taken in consideration:

 - The usb3-controller node has to be *outside* of the internal-regs{}
   node, because this device needs to access special windows.

 - The usb3-controller node has one ranges to describe the special
   window to be created but it must be done at the board level in the
   dts.

 - The usb3-controller node has two entries in the reg property, the
   first for XHCI, the second for the internal registers

Signed-off-by: Gregory CLEMENT 
---
 arch/arm/boot/dts/armada-375.dtsi | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/armada-375.dtsi 
b/arch/arm/boot/dts/armada-375.dtsi
index 0e0036800071..cbe64ba9eb65 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -465,5 +465,23 @@
};
 
};
+
+   /*
+* On Armada 375, USB2 host controller and USB3 host
+* controller are incompatible. That means that in the
+* dts of your board, you can either select the USB2
+* controller: marvell,orion-ehci or the USB3
+* controller: marvell,armada-375-xhci, but not
+* both. If both controllers are selected, then the
+* kernel will select the USB3 by default.
+*/
+   usb3-controller {
+   compatible = "marvell,armada-375-xhci";
+   reg = ,
+   ;
+   interrupts = ;
+   clocks = <&gateclk 16>;
+   status = "disabled";
+   };
};
 };
-- 
1.8.1.2

--
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 11/18] xhci-platform: Add a new controller using xhci: Armada 375

2014-04-25 Thread Gregory CLEMENT 
Extend the compatible string list with armada-375-xhci. It is used to
describe xhci controller which is in the Armada 375 SoC.

Signed-off-by: Gregory CLEMENT 
---
 Documentation/devicetree/bindings/usb/usb-xhci.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt 
b/Documentation/devicetree/bindings/usb/usb-xhci.txt
index cbc91414fd59..87d150ca58cc 100644
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -2,7 +2,8 @@ USB xHCI controllers
 
 Required properties:
   - compatible: should be on of "generic-xhci",
-"marvell,armada-380-xhci" (deprecated: "xhci-platform").
+"marvell,armada-375-xhci", "marvell,armada-380-xhci" (deprecated:
+"xhci-platform").
   - reg: should contain address and length of the standard XHCI
 register set for the device.
   - interrupts: one XHCI interrupt should be described here.
-- 
1.8.1.2

--
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 12/18] ARM: mvebu: Add Device Tree description of USB cluster controller on Armada 375

2014-04-25 Thread Gregory CLEMENT 
On Armada 375, the USB cluster allows to control the cluster composed
of the USB2 and USB3 host controllers.

Signed-off-by: Gregory CLEMENT 
---
 arch/arm/boot/dts/armada-375.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/armada-375.dtsi 
b/arch/arm/boot/dts/armada-375.dtsi
index 3877693fb2d8..0e0036800071 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -320,6 +320,11 @@
clocks = <&coreclk 0>;
};
 
+   usb-cluster@18400 {
+   compatible = "marvell,armada-375-usb-cluster";
+   reg = <0x18400 0x4>;
+   };
+
xor@60800 {
compatible = "marvell,orion-xor";
reg = <0x60800 0x100
-- 
1.8.1.2

--
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 13/18] dt: binding: Armada 375 USB cluster

2014-04-25 Thread Gregory CLEMENT 
Armada 375 comes with an USB2 host and device controller and an USB3
controller. The USB cluster control register allows to manage common
features of both USB controllers.

Signed-off-by: Gregory CLEMENT 
---
 .../devicetree/bindings/arm/armada-375-usb-cluster.txt  | 17 +
 1 file changed, 17 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/armada-375-usb-cluster.txt

diff --git a/Documentation/devicetree/bindings/arm/armada-375-usb-cluster.txt 
b/Documentation/devicetree/bindings/arm/armada-375-usb-cluster.txt
new file mode 100644
index ..71feb8fb4434
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/armada-375-usb-cluster.txt
@@ -0,0 +1,17 @@
+Armada 375 USB cluster
+--
+
+Armada 375 comes with an USB2 host and device controller and an USB3
+controller. The USB cluster control register allows to manage common
+features of both USB controllers.
+
+Required properties:
+
+- compatible: "marvell,armada-375-usb-cluster"
+- reg: Should contain usb cluster register location and length.
+
+Example:
+   usb-cluster@18400 {
+   compatible = "marvell,armada-375-usb-cluster";
+   reg = <0x18400 0x4>;
+   };
-- 
1.8.1.2

--
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 10/18] usb: host: xhci-plat: Add support for the Armada 375

2014-04-25 Thread Gregory CLEMENT 
For the Armada 375 SoC which comes with an xhci controller. Currently
the quirk is the same that the Armada 380/385 one, but by introducing
a new compatible string it will allow to make the driver evolve
seamless.

Signed-off-by: Gregory CLEMENT 
---
 drivers/usb/host/xhci-plat.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index c0e835b49e0d..679b21f30458 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -152,6 +152,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (of_device_is_compatible(pdev->dev.of_node, 
"marvell,armada-380-xhci"))
xhci_mvebu_mbus_init_quirk(pdev);
 
+   if (of_device_is_compatible(pdev->dev.of_node, 
"marvell,armada-375-xhci"))
+   xhci_mvebu_mbus_init_quirk(pdev);
+
/* Initialize dma_mask and coherent_dma_mask to 32-bits */
ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
if (ret)
@@ -284,6 +287,7 @@ static const struct of_device_id usb_xhci_of_match[] = {
{ .compatible = "generic-xhci" },
{ .compatible = "xhci-platform" },
{ .compatible = "marvell,armada-380-xhci"},
+   { .compatible = "marvell,armada-375-xhci"},
{ },
 };
 MODULE_DEVICE_TABLE(of, usb_xhci_of_match);
-- 
1.8.1.2

--
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 01/13] Documentation: add extcon devicetree bindings

2014-04-25 Thread Mark Brown 
On Fri, Apr 25, 2014 at 03:19:59PM +0200, Robert Baldyga wrote:
> On 04/22/2014 09:51 PM, Mark Brown wrote:

> >>  .../devicetree/bindings/extcon/extcon-adc-jack.txt |   60 
> >> +++
> >>  .../devicetree/bindings/extcon/extcon-arizona.txt  |   47 +++
> >>  .../devicetree/bindings/extcon/extcon-bindings.txt |   36 +++
> >>  .../devicetree/bindings/extcon/extcon-gpio.txt |   63 
> >> 
> >>  .../devicetree/bindings/extcon/extcon-max14577.txt |   49 +++
> >>  .../devicetree/bindings/extcon/extcon-max77693.txt |   56 
> >> +
> >>  .../devicetree/bindings/extcon/extcon-max8997.txt  |   49 +++
> >>  .../devicetree/bindings/extcon/extcon-palmas.txt   |   37 ++--

> > This is creating device tree bindings for MFD components as devices when
> > those MFD components aren't well isolated from the rest of the device.
> > If we need to add extcon bindings the device should have the flexibility
> > to decide where to add the properties, and really things should be set
> > up so there's less duplication in the documentation.

> Those components has their own addresses on i2c bus, so they are,
> technically, separate devices, and they can (should?) be described by
> separate nodes. And I think it doesn't matter if they are grouped in one
> chip.

That's definitely not true for the arizona devices, I haven't
specifically checked for any of the others.  It's all one device and the
isolation isn't particularly solid.


signature.asc
Description: Digital signature

[PATCH v2 09/18] ARM: configs: Add usb_xhci_mvebu to multi_v7_defconfig

2014-04-25 Thread Gregory CLEMENT 
The Marvell Armada 38x platform needs the xhci_mvebu driver enabled
for the xHCI USB hosts, so this commit enables the corresponding
Kconfig option in multi_v7_defconfig.

Signed-off-by: Gregory CLEMENT 
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index d4e8a47a2f7c..820cc35d40cf 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -254,6 +254,7 @@ CONFIG_SND_SOC_TEGRA_ALC5632=y
 CONFIG_SND_SOC_TEGRA_MAX98090=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_MVEBU=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_TEGRA=y
 CONFIG_USB_EHCI_HCD_PLATFORM=y
-- 
1.8.1.2

--
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 02/18] usb: host: xhci-plat: Add clocks support

2014-04-25 Thread Thomas Petazzoni 
Dear Gregory CLEMENT,

On Fri, 25 Apr 2014 16:07:00 +0200, Gregory CLEMENT wrote:
> Some platform (such as the Armada 38x ones) can gate the clock of
> their USB controller. This patch add the support for the clock, by
> enabling them during probe and disabling them on remove.
> 
> As not all platforms have clock support then enabling and disabling
> the clocks have been placed in separate functions. Then if the clocks
> are not supported we still can use the same calls, and there is no
> 
> Signed-off-by: Gregory CLEMENT 
> ---
>  drivers/usb/host/xhci-plat.c | 52 
> ++--
>  1 file changed, 50 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index f5351af4b2c5..bb5d563f729c 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -11,6 +11,7 @@
>   * version 2 as published by the Free Software Foundation.
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -85,6 +86,42 @@ static const struct hc_driver xhci_plat_xhci_driver = {
>   .bus_resume =   xhci_bus_resume,
>  };
>  
> +#if defined(CONFIG_HAVE_CLK)
> +static int try_enable_clk(struct platform_device *pdev)
> +{
> + struct clk *clk = devm_clk_get(&pdev->dev, NULL);
> +
> + /* Not all platforms have a clk so it is not an error if the clock
> +does not exists. */
> + if (!IS_ERR(clk))

Instead, do:

if (IS_ERR(clk))
return 0;

return clk_prepare_enable(clk);

> + if (clk_prepare_enable(clk))
> + return  -ENODEV;
> + return 0;
> +}
> +
> +static int try_disable_clk(struct platform_device *pdev)
> +{
> + struct clk *clk = devm_clk_get(&pdev->dev, NULL);

No, this isn't correct: you shouldn't be getting the clock to
disable/unprepare it, otherwise you have an unbalanced number of
get()/put() calls on the clocks.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
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 v2 07/18] ARM: mvebu: Add USB3 support for Armada 38x

2014-04-25 Thread Gregory CLEMENT 
This patch add the selection of the config symbol to build the USB3
support for Armada 38x.

Signed-off-by: Gregory CLEMENT 
---
 arch/arm/mach-mvebu/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 3f73eecbcfb0..7960f218702b 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -54,6 +54,7 @@ config MACH_ARMADA_38X
select CPU_V7
select MACH_MVEBU_V7
select PINCTRL_ARMADA_38X
+   select USB_ARCH_HAS_XHCI
help
  Say 'Y' here if you want your kernel to support boards based
  on the Marvell Armada 380/385 SoC with device tree.
-- 
1.8.1.2

--
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 08/18] ARM: configs: Add usb_xhci_mvebu to mvebu_v7_defconfig

2014-04-25 Thread Gregory CLEMENT 
The Marvell Armada 38x platform needs the xhci_mvebu driver enabled
for the xHCI USB hosts, so this commit enables the corresponding
Kconfig option in mvebu_v7_defconfig.

Signed-off-by: Gregory CLEMENT 
---
 arch/arm/configs/mvebu_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/mvebu_v7_defconfig 
b/arch/arm/configs/mvebu_v7_defconfig
index a34713d8db9f..e8811066b8e4 100644
--- a/arch/arm/configs/mvebu_v7_defconfig
+++ b/arch/arm/configs/mvebu_v7_defconfig
@@ -78,6 +78,7 @@ CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_ROOT_HUB_TT=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_MVEBU=y
 CONFIG_MMC=y
 CONFIG_MMC_MVSDIO=y
 CONFIG_NEW_LEDS=y
-- 
1.8.1.2

--
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 02/18] usb: host: xhci-plat: Add clocks support

2014-04-25 Thread Gregory CLEMENT 
Some platform (such as the Armada 38x ones) can gate the clock of
their USB controller. This patch add the support for the clock, by
enabling them during probe and disabling them on remove.

As not all platforms have clock support then enabling and disabling
the clocks have been placed in separate functions. Then if the clocks
are not supported we still can use the same calls, and there is no

Signed-off-by: Gregory CLEMENT 
---
 drivers/usb/host/xhci-plat.c | 52 ++--
 1 file changed, 50 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index f5351af4b2c5..bb5d563f729c 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -11,6 +11,7 @@
  * version 2 as published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -85,6 +86,42 @@ static const struct hc_driver xhci_plat_xhci_driver = {
.bus_resume =   xhci_bus_resume,
 };
 
+#if defined(CONFIG_HAVE_CLK)
+static int try_enable_clk(struct platform_device *pdev)
+{
+   struct clk *clk = devm_clk_get(&pdev->dev, NULL);
+
+   /* Not all platforms have a clk so it is not an error if the clock
+  does not exists. */
+   if (!IS_ERR(clk))
+   if (clk_prepare_enable(clk))
+   return  -ENODEV;
+   return 0;
+}
+
+static int try_disable_clk(struct platform_device *pdev)
+{
+   struct clk *clk = devm_clk_get(&pdev->dev, NULL);
+
+   /* Not all platforms have a clk so it is not an error if the clock
+  does not exists. */
+   if (!IS_ERR(clk))
+   clk_disable_unprepare(clk);
+
+   return 0;
+}
+#else
+static inline int try_enable_clk(struct platform_device *pdev)
+{
+   return 0;
+}
+
+static inline int try_disable_clk(struct platform_device *pdev)
+{
+   return 0;
+}
+#endif
+
 static int xhci_plat_probe(struct platform_device *pdev)
 {
const struct hc_driver  *driver;
@@ -107,6 +144,10 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (!res)
return -ENODEV;
 
+   ret = try_enable_clk(pdev);
+   if (ret)
+   return ret;
+
/* Initialize dma_mask and coherent_dma_mask to 32-bits */
ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
if (ret)
@@ -117,8 +158,10 @@ static int xhci_plat_probe(struct platform_device *pdev)
dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
 
hcd = usb_create_hcd(driver, &pdev->dev, dev_name(&pdev->dev));
-   if (!hcd)
-   return -ENOMEM;
+   if (!hcd) {
+   ret = -ENOMEM;
+   goto disable_clk;
+   }
 
hcd->rsrc_start = res->start;
hcd->rsrc_len = resource_size(res);
@@ -182,6 +225,9 @@ release_mem_region:
 put_hcd:
usb_put_hcd(hcd);
 
+disable_clk:
+   try_disable_clk(pdev);
+
return ret;
 }
 
@@ -199,6 +245,8 @@ static int xhci_plat_remove(struct platform_device *dev)
usb_put_hcd(hcd);
kfree(xhci);
 
+   try_disable_clk(dev);
+
return 0;
 }
 
-- 
1.8.1.2

--
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 05/18] ARM: mvebu: Add Device Tree description of xHCI hosts on Armada 38x

2014-04-25 Thread Gregory CLEMENT 
The Marvell Armada 38x SoCs contain two xHCI host. This commit adds
the Device Tree description of those interfaces at the SoC level, and
also enables the two USB3 ports on the Armada 385 DB platform and one
USB3 port on the Armada 385 RD platforms.

Signed-off-by: Gregory CLEMENT 
---
 arch/arm/boot/dts/armada-385-db.dts |  8 
 arch/arm/boot/dts/armada-385-rd.dts |  4 
 arch/arm/boot/dts/armada-38x.dtsi   | 17 +
 3 files changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/armada-385-db.dts 
b/arch/arm/boot/dts/armada-385-db.dts
index 6828d77696a6..d5db1466da82 100644
--- a/arch/arm/boot/dts/armada-385-db.dts
+++ b/arch/arm/boot/dts/armada-385-db.dts
@@ -101,6 +101,14 @@
reg = <0x100 0x3f00>;
};
};
+
+   usb3@f {
+   status = "okay";
+   };
+
+   usb3@f8000 {
+   status = "okay";
+   };
};
 
pcie-controller {
diff --git a/arch/arm/boot/dts/armada-385-rd.dts 
b/arch/arm/boot/dts/armada-385-rd.dts
index 45250c88814b..a505fe94ff37 100644
--- a/arch/arm/boot/dts/armada-385-rd.dts
+++ b/arch/arm/boot/dts/armada-385-rd.dts
@@ -77,6 +77,10 @@
reg = <1>;
};
};
+
+   usb3@f {
+   status = "okay";
+   };
};
 
pcie-controller {
diff --git a/arch/arm/boot/dts/armada-38x.dtsi 
b/arch/arm/boot/dts/armada-38x.dtsi
index a064f59da02d..5913ce1cc601 100644
--- a/arch/arm/boot/dts/armada-38x.dtsi
+++ b/arch/arm/boot/dts/armada-38x.dtsi
@@ -355,6 +355,23 @@
clocks = <&coredivclk 0>;
status = "disabled";
};
+
+   usb3@f {
+   compatible = "marvell,armada-380-xhci";
+   reg = <0xf 0x3fff>,<0xf4000 0x3fff>;
+   interrupts = ;
+   clocks = <&gateclk 9>;
+   status = "disabled";
+   };
+
+   usb3@f8000 {
+   compatible = "marvell,armada-380-xhci";
+   reg = <0xf8000 0x3fff>,<0xfc000 0x3fff>;
+   interrupts = ;
+   clocks = <&gateclk 10>;
+   status = "disabled";
+   };
+
};
};
 
-- 
1.8.1.2

--
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 03/18] usb: host: xhci-plat: Add support for the Armada 38x

2014-04-25 Thread Thomas Petazzoni 
Dear Gregory CLEMENT,

On Fri, 25 Apr 2014 16:07:01 +0200, Gregory CLEMENT wrote:

> +#define USB3_MAX_WINDOWS 4
> +#define USB3_WIN_CTRL(w) (0x0 + ((w) * 8))
> +#define USB3_WIN_BASE(w) (0x4 + ((w) * 8))
> +
> +static void __init mv_usb3_conf_mbus_windows(void __iomem *base,
> + const struct mbus_dram_target_info *dram)

That's a nitpick, but the name of this function looks like it was
copy/pasted from the Marvell LSP, and isn't very consistent with the
other function name. What about:

xhci_mvebu_mbus_config()

instead, or something like that?

> +int xhci_mvebu_mbus_init_quirk(struct platform_device *pdev)

I believe this should give you a warning about section mismatch: you
have a non-init function calling an __init function, no?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
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 v2 04/18] xhci-platform: Add a new controller using xhci: Armada 38x

2014-04-25 Thread Gregory CLEMENT 
Extend the compatible string list with armada-380-xhci. It is used to
describe xhci controller which is in the Armada 38x SoCs.

Signed-off-by: Gregory CLEMENT 
---
 Documentation/devicetree/bindings/usb/usb-xhci.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt 
b/Documentation/devicetree/bindings/usb/usb-xhci.txt
index 90f8f607d125..cbc91414fd59 100644
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -1,7 +1,8 @@
 USB xHCI controllers
 
 Required properties:
-  - compatible: should be "generic-xhci" (deprecated: "xhci-platform").
+  - compatible: should be on of "generic-xhci",
+"marvell,armada-380-xhci" (deprecated: "xhci-platform").
   - reg: should contain address and length of the standard XHCI
 register set for the device.
   - interrupts: one XHCI interrupt should be described here.
-- 
1.8.1.2

--
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 02/18] usb: host: xhci-plat: Add clocks support

2014-04-25 Thread Russell King - ARM Linux 
On Fri, Apr 25, 2014 at 04:07:00PM +0200, Gregory CLEMENT wrote:
> +#if defined(CONFIG_HAVE_CLK)
> +static int try_enable_clk(struct platform_device *pdev)
> +{
> + struct clk *clk = devm_clk_get(&pdev->dev, NULL);
> +
> + /* Not all platforms have a clk so it is not an error if the clock
> +does not exists. */
> + if (!IS_ERR(clk))
> + if (clk_prepare_enable(clk))
> + return  -ENODEV;
> + return 0;
> +}
> +
> +static int try_disable_clk(struct platform_device *pdev)
> +{
> + struct clk *clk = devm_clk_get(&pdev->dev, NULL);
> +
> + /* Not all platforms have a clk so it is not an error if the clock
> +does not exists. */
> + if (!IS_ERR(clk))
> + clk_disable_unprepare(clk);
> +
> + return 0;
> +}

OMG.

You do realise that clk_get() ref-counts against the module which
provided the clock, so this is akin to an explicit leaking module
ref-counts.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
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 03/18] usb: host: xhci-plat: Add support for the Armada 38x

2014-04-25 Thread Gregory CLEMENT 
For the Armada 38x SoCs which come with an xhci controller, specific
initialization must be done during probe related to the MBus windows
configuration. This patch adds the support of this quirk.

Signed-off-by: Gregory CLEMENT 
---
 drivers/usb/host/Kconfig  |  7 +
 drivers/usb/host/Makefile |  1 +
 drivers/usb/host/xhci-mvebu.c | 71 +++
 drivers/usb/host/xhci-mvebu.h | 22 ++
 drivers/usb/host/xhci-plat.c  |  5 +++
 5 files changed, 106 insertions(+)
 create mode 100644 drivers/usb/host/xhci-mvebu.c
 create mode 100644 drivers/usb/host/xhci-mvebu.h

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 3d9e54062d62..e70943fac4a1 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -29,6 +29,13 @@ if USB_XHCI_HCD
 config USB_XHCI_PLATFORM
tristate
 
+config USB_XHCI_MVEBU
+   tristate "xHCI support for Marvell Armada 38x"
+   select USB_XHCI_PLATFORM
+   ---help---
+ Say 'Y' to enable the support for the xHCI host controller
+ found in Marvell Armada 38x ARM SOCs.
+
 endif # USB_XHCI_HCD
 
 config USB_EHCI_HCD
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 7530468c9a4f..7a8db7f7dc01 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -19,6 +19,7 @@ xhci-hcd-$(CONFIG_PCI)+= xhci-pci.o
 
 ifneq ($(CONFIG_USB_XHCI_PLATFORM), )
xhci-hcd-y  += xhci-plat.o
+   xhci-hcd-$(CONFIG_USB_XHCI_MVEBU)   += xhci-mvebu.o
 endif
 
 obj-$(CONFIG_USB_WHCI_HCD) += whci/
diff --git a/drivers/usb/host/xhci-mvebu.c b/drivers/usb/host/xhci-mvebu.c
new file mode 100644
index ..09cf437499fb
--- /dev/null
+++ b/drivers/usb/host/xhci-mvebu.c
@@ -0,0 +1,71 @@
+/*
+ * Copyright (C) 2014 Marvell
+ * Author: Gregory CLEMENT 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#define USB3_MAX_WINDOWS   4
+#define USB3_WIN_CTRL(w)   (0x0 + ((w) * 8))
+#define USB3_WIN_BASE(w)   (0x4 + ((w) * 8))
+
+static void __init mv_usb3_conf_mbus_windows(void __iomem *base,
+   const struct mbus_dram_target_info *dram)
+{
+   int win;
+
+   /* Clear all existing windows */
+   for (win = 0; win < USB3_MAX_WINDOWS; win++) {
+   writel(0, base + USB3_WIN_CTRL(win));
+   writel(0, base + USB3_WIN_BASE(win));
+   }
+
+   /* Program each DRAM CS in a seperate window */
+   for (win = 0; win < dram->num_cs; win++) {
+   const struct mbus_dram_window *cs = dram->cs + win;
+
+   writel(((cs->size - 1) & 0x) | (cs->mbus_attr << 8) |
+  (dram->mbus_dram_target_id << 4) | 1,
+  base + USB3_WIN_CTRL(win));
+
+   writel((cs->base & 0x), base + USB3_WIN_BASE(win));
+   }
+}
+
+int xhci_mvebu_mbus_init_quirk(struct platform_device *pdev)
+{
+   struct resource *res;
+   void __iomem*base;
+   const struct mbus_dram_target_info *dram;
+   int ret = 0;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+   if (!res)
+   return -ENODEV;
+
+   /*
+* We don't use devm_ioremap() because this mapping should
+* only exists for the duration of this probe function.
+*/
+   base = ioremap(res->start, resource_size(res));
+   if (!base)
+   return -ENODEV;
+
+   dram = mv_mbus_dram_info();
+   mv_usb3_conf_mbus_windows(base, dram);
+
+   /*
+* This memory area was only needed to configure the MBus
+* windows, and is therefore no longer useful.
+*/
+   iounmap(base);
+
+   return ret;
+}
diff --git a/drivers/usb/host/xhci-mvebu.h b/drivers/usb/host/xhci-mvebu.h
new file mode 100644
index ..5d7e647b3d27
--- /dev/null
+++ b/drivers/usb/host/xhci-mvebu.h
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2014 Marvell
+ *
+ * Gregory Clement 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef __LINUX_XHCI_MVEBU_H
+#define __LINUX_XHCI_MVEBU_H
+
+#ifdef CONFIG_USB_XHCI_MVEBU
+int xhci_mvebu_mbus_init_quirk(struct platform_device *pdev);
+#else
+static inline int xhci_mvebu_mbus_init_quirk(struct device dev)
+{
+   return 0;
+}
+#endif
+#endif /* __LINUX_XHCI_MVEBU_H */
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index bb5d563f729c..c0e835b49e0d 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -19,6 +19,7 @@
 #include 
 
 #include "xhci.h"
+#include "xhci-mvebu.h"
 
 static void xhci_plat_quirks(struct device *dev, struct xhci_hc

[PATCH v2 01/18] usb: host: xhci-plat: Sort the headers in alphabetic order

2014-04-25 Thread Gregory CLEMENT 
Sorting the headers in alphabetic order will help to reduce the conflict
when adding new headers later.

Signed-off-by: Gregory CLEMENT 
---
 drivers/usb/host/xhci-plat.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 151901ce1ba9..f5351af4b2c5 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -11,11 +11,11 @@
  * version 2 as published by the Free Software Foundation.
  */
 
-#include 
+#include 
 #include 
-#include 
 #include 
-#include 
+#include 
+#include 
 
 #include "xhci.h"
 
-- 
1.8.1.2

--
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 v8 2/2] usb: ehci-exynos: Change to use phy provided by the generic phy framework

2014-04-25 Thread Alan Stern 
On Fri, 25 Apr 2014, Vivek Gautam wrote:

> From: Kamil Debski 
> 
> Add the phy provider, supplied by new Exynos-usb2phy using
> Generic phy framework.
> Keeping the support for older USB phy intact right now, in order
> to prevent any functionality break in absence of relevant
> device tree side change for ehci-exynos.
> Once we move to new phy in the device nodes for ehci, we can
> remove the support for older phys.
> 
> Signed-off-by: Kamil Debski 
> [gautam.vi...@samsung.com: Addressed review comments from mailing list]
> [gautam.vi...@samsung.com: Kept the code for old usb-phy, and just
> added support for new exynos5-usb2phy in generic phy framework]
> [gautam.vi...@samsung.com: Edited the commit message]
> Signed-off-by: Vivek Gautam 

> +static int exynos_ehci_phyg_off(struct phy *phy[])
> +{
> + int i;
> + int ret = 0;
> +
> + for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
> + if (phy[i])
> + ret = phy_power_off(phy[i]);
> +
> + return ret;
> +}

Same comment as in the OHCI driver about ret.

> @@ -175,6 +269,7 @@ skip_phy:
>  fail_add_hcd:
>   if (exynos_ehci->phy)
>   usb_phy_shutdown(exynos_ehci->phy);
> + exynos_ehci_phyg_off(exynos_ehci->phy_g);
>  fail_io:
>   clk_disable_unprepare(exynos_ehci->clk);
>  fail_clk:
> @@ -195,6 +290,8 @@ static int exynos_ehci_remove(struct platform_device 
> *pdev)
>   if (exynos_ehci->phy)
>   usb_phy_shutdown(exynos_ehci->phy);
>  
> + exynos_ehci_phyg_off(exynos_ehci->phy_g);
> +

In both these places, you need to test exynos_ehci->phyg before calling 
exynos_ehci_phyg_off().

Maybe it would help to add exynos_ehci_phy_enable/disable routines, 
like in the OHCI driver.

Alan Stern

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

Line Discipline Kernel BUG when using usb-serial and mos7840 in v3.11

2014-04-25 Thread Coleman Brumley 
I'm working with a line discipline in v3.11.10.5 in Ubuntu 12.04 LTS.
The kernel has been modified to use a HZ of 1000. CONFIG_HZ_1000=y and
CONFIG_HZ=1000 in .config.

I have a B&B USOPTL4 RS485 to USB converter connected, I have
usb-serial loaded and mos7840 loaded (CONFIG_USB_SERIAL=m and
CONFIG_USB_MOS7840=m) . The converter is identified and shows in dmesg
output and is attached to /dev/ttyUSB0.

This ldisc works correctly in older kernels, but this seems to fail in
v3.x kernels. I know for certain this happens in v3.2 and v3.11, both
on Ubuntu 12.04 LTS. To be honest, though, I don't recall using this
with a USB converter as all of those machines (mostly embedded) had
physical serial ports.

My line discipline loads correctly (I'm using O_RDWR|O_NONBLOCK) but
when the TIOCSETD ioctl is called, the kernel generates the following
bug report.

Is this an issue in the usb serial driver, the way my code calls
TIOCSETD, or something else?

Now that I think of it, my ldisc open function using printk to state
that it's open

printk(MY_MSG "Device %s set to my_ldisc at %d",my_ldisc_tty->name, baud);

where baud comes from tty_get_baud_rate. But it seems that message
isn't in dmesg output. So, is it possible that the call to open is
delayed and failing upon calling tty_get_baud_rate?

 1916.989339] [ cut here ]
[ 1916.989344] kernel BUG at drivers/tty/tty_ioctl.c:990!
[ 1916.989375] invalid opcode:  [#1] SMP
[ 1916.989379] Modules linked in: my_ldisc(OF) mos7840(F) ftdi_sio(F)
usbserial(F) joydev(F) hid_generic(F) btusb(F) snd_ens1371(F)
gameport(F) snd_ac97_codec(F) ac97_bus(F) snd_pcm(F) vmw_balloon(F)
snd_seq_midi(F) snd_rawmidi(F) psmouse(F) serio_raw(F)
snd_seq_midi_event(F) snd_seq(F) usbhid(F) hid(F) snd_timer(F)
snd_seq_device(F) snd(F) soundcore(F) snd_page_alloc(F) mac_hid(F)
vmwgfx(F) ttm(F) vmw_vmci(F) bnep(F) drm(F) rfcomm(F) i2c_piix4(F)
shpchp(F) bluetooth(F) parport_pc(F) ppdev(F) lp(F) parport(F)
floppy(F) pcnet32(F) mii(F) mptspi(F) mptscsih(F) mptbase(F)
vmw_pvscsi(F) vmxnet3(F)
[ 1916.989418] CPU: 0 PID: 2955 Comm: fref_linux Tainted: GF
O 3.11.10.5-polarsoft #1
[ 1916.989420] Hardware name: VMware, Inc. VMware Virtual
Platform/440BX Desktop Reference Platform, BIOS 6.00 06/02/2011
[ 1916.989422] task: f5cf4060 ti: e2e68000 task.ti: e2e68000
[ 1916.989425] EIP: 0060:[] EFLAGS: 00010246 CPU: 0
[ 1916.989450] EIP is at tty_mode_ioctl+0x4fd/0x500
[ 1916.989452] EAX: f5093600 EBX:  ECX: 802c542a EDX: 
[ 1916.989453] ESI: e2e69db0 EDI: e2e69db0 EBP: e2e69d84 ESP: e2e69d38
[ 1916.989454]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 1916.989456] CR0: 80050033 CR2: b4a9d000 CR3: 22f08000 CR4: 000407f0
[ 1916.989523] Stack:
[ 1916.989525]  0002 f4ba9000 f7a95500 f5c01980 e2e69db0 c165d88f
c14b5eb9 
[ 1916.989529]  1388  00060303 0001 004b735a 
f4ba8000 518961af
[ 1916.989533]  f5093600 f47266a0 e2e69db0 e2e69d9c c13d2011 e2e69db0
f5093600 f47266a0
[ 1916.989536] Call Trace:
[ 1916.989562]  [] ? __slab_free+0x18c/0x268
[ 1916.989583]  [] ? usb_alloc_urb+0x19/0x40
[ 1916.989587]  [] n_tty_ioctl_helper+0x31/0x100
[ 1916.989591]  [] my_ldisc_open+0x180/0x1d0 [my_ldisc]
[ 1916.989611]  [] ? kfree+0xe7/0x110
[ 1916.989614]  [] ? n_tty_close+0x40/0x60
[ 1916.989616]  [] ? n_tty_close+0x47/0x60
[ 1916.989618]  [] ? n_tty_close+0x47/0x60
[ 1916.989620]  [] tty_ldisc_open.isra.2+0x33/0x60
[ 1916.989622]  [] tty_set_ldisc+0x1a0/0x6c0
[ 1916.989625]  [] ? _raw_spin_lock_irqsave+0x2d/0x40
[ 1916.989630]  [] ? serial_wait_until_sent+0x5f/0xc0 [usbserial]
[ 1916.989633]  [] ? serial_chars_in_buffer+0x3d/0x70 [usbserial]
[ 1916.989635]  [] ? tty_wait_until_sent+0xd3/0x100
[ 1916.989668]  [] ? ptrace_stop+0x16a/0x220
[ 1916.989671]  [] tty_ioctl+0x4cd/0xa30
[ 1916.989674]  [] ? send_signal+0x43/0x80
[ 1916.989704]  [] ? do_signal+0x3a/0x8d0
[ 1916.989723]  [] ? send_sigtrap+0x78/0x90
[ 1916.989726]  [] ? no_tty+0x30/0x30
[ 1916.989729]  [] do_vfs_ioctl+0x7c/0x580
[ 1916.989731]  [] SyS_ioctl+0x97/0xa0
[ 1916.989734]  [] sysenter_do_call+0x12/0x28
[ 1916.989735] Code: ea f8 ff ff e9 0d fc ff ff b9 07 00 00 00 89 f2
89 d8 e8 d7 f8 ff ff e9 fa fb ff ff e8 cd 32 c8 ff b8 ea ff ff ff e9
eb fb ff ff <0f> 0b 90 55 89 e5 83 ec 10 89 5d f4 89 75 f8 89 7d fc 66
66 66
[ 1916.989765] EIP: [] tty_mode_ioctl+0x4fd/0x500 SS:ESP 0068:e2e69d38
[ 1916.989853] ---[ end trace 20fe81540ae67627 ]---

uname -r output:
Linux ubuntu 3.11.10.5-coleman #1 SMP Thu Apr 24 11:10:31 PDT 2014
i686 i686 i386 GNU/Linux

dmesg output when the USOPTL4 is attached and my ldisc is installed:
[ 1055.255235] usbcore: registered new interface driver mos7840
[ 1055.255996] usbserial: USB Serial support registered for Moschip
7840/7820 USB Serial Driver
[ 1060.564983] usb 2-2.2: new full-speed USB device number 6 using uhci_hcd
[ 1060.681890] usb 2-2.2: New USB device found, idVendor=0856, idProduct=ac11
[ 1060.681895] usb 2-2.2: New USB device strings: Mfr=1, Product=2,
Seria

Re: [PATCH v2 02/18] usb: host: xhci-plat: Add clocks support

2014-04-25 Thread Gregory CLEMENT 
On 25/04/2014 16:15, Thomas Petazzoni wrote:
> Dear Gregory CLEMENT,
> 
> On Fri, 25 Apr 2014 16:07:00 +0200, Gregory CLEMENT wrote:
>> Some platform (such as the Armada 38x ones) can gate the clock of
>> their USB controller. This patch add the support for the clock, by
>> enabling them during probe and disabling them on remove.
>>
>> As not all platforms have clock support then enabling and disabling
>> the clocks have been placed in separate functions. Then if the clocks
>> are not supported we still can use the same calls, and there is no
>>
>> Signed-off-by: Gregory CLEMENT 
>> ---
>>  drivers/usb/host/xhci-plat.c | 52 
>> ++--
>>  1 file changed, 50 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
>> index f5351af4b2c5..bb5d563f729c 100644
>> --- a/drivers/usb/host/xhci-plat.c
>> +++ b/drivers/usb/host/xhci-plat.c
>> @@ -11,6 +11,7 @@
>>   * version 2 as published by the Free Software Foundation.
>>   */
>>  
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -85,6 +86,42 @@ static const struct hc_driver xhci_plat_xhci_driver = {
>>  .bus_resume =   xhci_bus_resume,
>>  };
>>  
>> +#if defined(CONFIG_HAVE_CLK)
>> +static int try_enable_clk(struct platform_device *pdev)
>> +{
>> +struct clk *clk = devm_clk_get(&pdev->dev, NULL);
>> +
>> +/* Not all platforms have a clk so it is not an error if the clock
>> +   does not exists. */
>> +if (!IS_ERR(clk))
> 
> Instead, do:
> 
>   if (IS_ERR(clk))
>   return 0;

As explained in the comment: Not all platforms have a clk so it is not an
error if the clock does not exists.

> 
>   return clk_prepare_enable(clk);
> 
>> +if (clk_prepare_enable(clk))
>> +return  -ENODEV;
>> +return 0;
>> +}
>> +
>> +static int try_disable_clk(struct platform_device *pdev)
>> +{
>> +struct clk *clk = devm_clk_get(&pdev->dev, NULL);
> 
> No, this isn't correct: you shouldn't be getting the clock to
> disable/unprepare it, otherwise you have an unbalanced number of
> get()/put() calls on the clocks.
> 
> Thomas
> 


-- 
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/2] usb: ohci-exynos: Add facility to use phy provided by the generic phy framework

2014-04-25 Thread Alan Stern 
On Fri, 25 Apr 2014, Vivek Gautam wrote:

> Add support to consume phy provided by Generic phy framework.
> Keeping the support for older usb-phy intact right now, in order
> to prevent any functionality break in absence of relevant
> device tree side change for ohci-exynos.
> Once we move to new phy in the device nodes for ohci, we can
> remove the support for older phys.
> 
> Signed-off-by: Vivek Gautam 
> Cc: Jingoo Han 
> Cc: Alan Stern 


> +static int exynos_ohci_phyg_on(struct phy *phy[])
> +{
> + int i;
> + int ret = 0;
> +
> + for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
> + if (phy[i])
> + ret = phy_power_on(phy[i]);
> + if (ret)
> + for (i--; i >= 0; i--)
> + if (phy[i])
> + phy_power_off(phy[i]);
> +
> + return ret;
> +}
> +
> +static int exynos_ohci_phyg_off(struct phy *phy[])
> +{
> + int i;
> + int ret = 0;
> +
> + for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
> + if (phy[i])
> + ret = phy_power_off(phy[i]);
> +
> + return ret;
> +}

You probably shouldn't break out of this loop if ret is nonzero; you
should continue to power off the remaining phys.

I'd be inclined to put these two routines directly into 
exynos_ohci_phy_enable() and exynos_ohci_phy_disable(), since they 
aren't used anywhere else.

> @@ -151,6 +253,7 @@ skip_phy:
>  
>  fail_add_hcd:
>   exynos_ohci_phy_disable(pdev);
> + exynos_ohci_phyg_off(exynos_ohci->phy_g);

Why did you add this line?  It doesn't do anything useful, because 
exynos_ohci_phy_disable() already calls exynos_ohci_phyg_off().

Alan Stern

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

Re: [PATCH v2 02/18] usb: host: xhci-plat: Add clocks support

2014-04-25 Thread Gregory CLEMENT 
On 25/04/2014 16:44, Gregory CLEMENT wrote:
> On 25/04/2014 16:15, Thomas Petazzoni wrote:
>> Dear Gregory CLEMENT,
>>
>> On Fri, 25 Apr 2014 16:07:00 +0200, Gregory CLEMENT wrote:
>>> Some platform (such as the Armada 38x ones) can gate the clock of
>>> their USB controller. This patch add the support for the clock, by
>>> enabling them during probe and disabling them on remove.
>>>
>>> As not all platforms have clock support then enabling and disabling
>>> the clocks have been placed in separate functions. Then if the clocks
>>> are not supported we still can use the same calls, and there is no
>>>
>>> Signed-off-by: Gregory CLEMENT 
>>> ---
>>>  drivers/usb/host/xhci-plat.c | 52 
>>> ++--
>>>  1 file changed, 50 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
>>> index f5351af4b2c5..bb5d563f729c 100644
>>> --- a/drivers/usb/host/xhci-plat.c
>>> +++ b/drivers/usb/host/xhci-plat.c
>>> @@ -11,6 +11,7 @@
>>>   * version 2 as published by the Free Software Foundation.
>>>   */
>>>  
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -85,6 +86,42 @@ static const struct hc_driver xhci_plat_xhci_driver = {
>>> .bus_resume =   xhci_bus_resume,
>>>  };
>>>  
>>> +#if defined(CONFIG_HAVE_CLK)
>>> +static int try_enable_clk(struct platform_device *pdev)
>>> +{
>>> +   struct clk *clk = devm_clk_get(&pdev->dev, NULL);
>>> +
>>> +   /* Not all platforms have a clk so it is not an error if the clock
>>> +  does not exists. */
>>> +   if (!IS_ERR(clk))
>>
>> Instead, do:
>>
>>  if (IS_ERR(clk))
>>  return 0;
> 
> As explained in the comment: Not all platforms have a clk so it is not an
> error if the clock does not exists.

Sorry you were right with the return 0. I misread the value

> 
>>
>>  return clk_prepare_enable(clk);
>>
>>> +   if (clk_prepare_enable(clk))
>>> +   return  -ENODEV;
>>> +   return 0;
>>> +}
>>> +
>>> +static int try_disable_clk(struct platform_device *pdev)
>>> +{
>>> +   struct clk *clk = devm_clk_get(&pdev->dev, NULL);
>>
>> No, this isn't correct: you shouldn't be getting the clock to
>> disable/unprepare it, otherwise you have an unbalanced number of
>> get()/put() calls on the clocks.
>>
>> Thomas
>>
> 
> 


-- 
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 01/18] usb: host: xhci-plat: Sort the headers in alphabetic order

2014-04-25 Thread Felipe Balbi 
On Fri, Apr 25, 2014 at 04:06:59PM +0200, Gregory CLEMENT wrote:
> Sorting the headers in alphabetic order will help to reduce the conflict
> when adding new headers later.
> 
> Signed-off-by: Gregory CLEMENT 
> ---

Acked-by: Felipe Balbi 

>  drivers/usb/host/xhci-plat.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 151901ce1ba9..f5351af4b2c5 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -11,11 +11,11 @@
>   * version 2 as published by the Free Software Foundation.
>   */
>  
> -#include 
> +#include 
>  #include 
> -#include 
>  #include 
> -#include 
> +#include 
> +#include 
>  
>  #include "xhci.h"
>  
> -- 
> 1.8.1.2
> 

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2 02/18] usb: host: xhci-plat: Add clocks support

2014-04-25 Thread Felipe Balbi 
Hi,

On Fri, Apr 25, 2014 at 04:07:00PM +0200, Gregory CLEMENT wrote:
> Some platform (such as the Armada 38x ones) can gate the clock of
> their USB controller. This patch add the support for the clock, by
> enabling them during probe and disabling them on remove.
> 
> As not all platforms have clock support then enabling and disabling
> the clocks have been placed in separate functions. Then if the clocks
> are not supported we still can use the same calls, and there is no
> 
> Signed-off-by: Gregory CLEMENT 
> ---
>  drivers/usb/host/xhci-plat.c | 52 
> ++--
>  1 file changed, 50 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index f5351af4b2c5..bb5d563f729c 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -11,6 +11,7 @@
>   * version 2 as published by the Free Software Foundation.
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -85,6 +86,42 @@ static const struct hc_driver xhci_plat_xhci_driver = {
>   .bus_resume =   xhci_bus_resume,
>  };
>  
> +#if defined(CONFIG_HAVE_CLK)

I don't think this ifdef is necessary, clk api provides stubs.

> +static int try_enable_clk(struct platform_device *pdev)

prepend this with xhci_plat_ as all other definitions here.

> +{
> + struct clk *clk = devm_clk_get(&pdev->dev, NULL);

you need to create a private xhci_plat structure and save a clock
pointer there.

> +
> + /* Not all platforms have a clk so it is not an error if the clock
> +does not exists. */

comment style is wrong.

> + if (!IS_ERR(clk))

even though some don't like it, the clk API is safe against NULL
pointers, one trick you could use is to set the clk pointer to NULL when
you fail to get it, then you'll have a single place where you check for
IS_ERR().

> + if (clk_prepare_enable(clk))
> + return  -ENODEV;
> + return 0;

these three lines could be rewritten as:

return clk_prepare_enable(clk);

> +}
> +
> +static int try_disable_clk(struct platform_device *pdev)
> +{
> + struct clk *clk = devm_clk_get(&pdev->dev, NULL);
> +
> + /* Not all platforms have a clk so it is not an error if the clock
> +does not exists. */
> + if (!IS_ERR(clk))
> + clk_disable_unprepare(clk);

similar comments to previous function.

>  static int xhci_plat_probe(struct platform_device *pdev)
>  {
>   const struct hc_driver  *driver;
> @@ -107,6 +144,10 @@ static int xhci_plat_probe(struct platform_device *pdev)
>   if (!res)
>   return -ENODEV;
>  
> + ret = try_enable_clk(pdev);
> + if (ret)
> + return ret;
> +
>   /* Initialize dma_mask and coherent_dma_mask to 32-bits */
>   ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
>   if (ret)
> @@ -117,8 +158,10 @@ static int xhci_plat_probe(struct platform_device *pdev)
>   dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
>  
>   hcd = usb_create_hcd(driver, &pdev->dev, dev_name(&pdev->dev));
> - if (!hcd)
> - return -ENOMEM;
> + if (!hcd) {
> + ret = -ENOMEM;
> + goto disable_clk;
> + }
>  
>   hcd->rsrc_start = res->start;
>   hcd->rsrc_len = resource_size(res);
> @@ -182,6 +225,9 @@ release_mem_region:
>  put_hcd:
>   usb_put_hcd(hcd);
>  
> +disable_clk:
> + try_disable_clk(pdev);
> +
>   return ret;
>  }
>  
> @@ -199,6 +245,8 @@ static int xhci_plat_remove(struct platform_device *dev)
>   usb_put_hcd(hcd);
>   kfree(xhci);
>  
> + try_disable_clk(dev);

you never call clk_put(). what gives ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v2 03/18] usb: host: xhci-plat: Add support for the Armada 38x

2014-04-25 Thread Felipe Balbi 
On Fri, Apr 25, 2014 at 04:07:01PM +0200, Gregory CLEMENT wrote:
> For the Armada 38x SoCs which come with an xhci controller, specific
> initialization must be done during probe related to the MBus windows
> configuration. This patch adds the support of this quirk.
> 
> Signed-off-by: Gregory CLEMENT 
> ---
>  drivers/usb/host/Kconfig  |  7 +
>  drivers/usb/host/Makefile |  1 +
>  drivers/usb/host/xhci-mvebu.c | 71 
> +++
>  drivers/usb/host/xhci-mvebu.h | 22 ++
>  drivers/usb/host/xhci-plat.c  |  5 +++
>  5 files changed, 106 insertions(+)
>  create mode 100644 drivers/usb/host/xhci-mvebu.c
>  create mode 100644 drivers/usb/host/xhci-mvebu.h
> 
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index 3d9e54062d62..e70943fac4a1 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -29,6 +29,13 @@ if USB_XHCI_HCD
>  config USB_XHCI_PLATFORM
>   tristate
>  
> +config USB_XHCI_MVEBU
> + tristate "xHCI support for Marvell Armada 38x"
> + select USB_XHCI_PLATFORM
> + ---help---
> +   Say 'Y' to enable the support for the xHCI host controller
> +   found in Marvell Armada 38x ARM SOCs.
> +
>  endif # USB_XHCI_HCD
>  
>  config USB_EHCI_HCD
> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
> index 7530468c9a4f..7a8db7f7dc01 100644
> --- a/drivers/usb/host/Makefile
> +++ b/drivers/usb/host/Makefile
> @@ -19,6 +19,7 @@ xhci-hcd-$(CONFIG_PCI)  += xhci-pci.o
>  
>  ifneq ($(CONFIG_USB_XHCI_PLATFORM), )
>   xhci-hcd-y  += xhci-plat.o
> + xhci-hcd-$(CONFIG_USB_XHCI_MVEBU)   += xhci-mvebu.o
>  endif
>  
>  obj-$(CONFIG_USB_WHCI_HCD)   += whci/
> diff --git a/drivers/usb/host/xhci-mvebu.c b/drivers/usb/host/xhci-mvebu.c
> new file mode 100644
> index ..09cf437499fb
> --- /dev/null
> +++ b/drivers/usb/host/xhci-mvebu.c
> @@ -0,0 +1,71 @@
> +/*
> + * Copyright (C) 2014 Marvell
> + * Author: Gregory CLEMENT 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define USB3_MAX_WINDOWS 4
> +#define USB3_WIN_CTRL(w) (0x0 + ((w) * 8))
> +#define USB3_WIN_BASE(w) (0x4 + ((w) * 8))
> +
> +static void __init mv_usb3_conf_mbus_windows(void __iomem *base,
> + const struct mbus_dram_target_info *dram)
> +{
> + int win;
> +
> + /* Clear all existing windows */
> + for (win = 0; win < USB3_MAX_WINDOWS; win++) {
> + writel(0, base + USB3_WIN_CTRL(win));
> + writel(0, base + USB3_WIN_BASE(win));
> + }
> +
> + /* Program each DRAM CS in a seperate window */
> + for (win = 0; win < dram->num_cs; win++) {
> + const struct mbus_dram_window *cs = dram->cs + win;
> +
> + writel(((cs->size - 1) & 0x) | (cs->mbus_attr << 8) |
> +(dram->mbus_dram_target_id << 4) | 1,
> +base + USB3_WIN_CTRL(win));
> +
> + writel((cs->base & 0x), base + USB3_WIN_BASE(win));
> + }
> +}
> +
> +int xhci_mvebu_mbus_init_quirk(struct platform_device *pdev)
> +{
> + struct resource *res;
> + void __iomem*base;
> + const struct mbus_dram_target_info *dram;
> + int ret = 0;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + if (!res)
> + return -ENODEV;
> +
> + /*
> +  * We don't use devm_ioremap() because this mapping should
> +  * only exists for the duration of this probe function.
> +  */
> + base = ioremap(res->start, resource_size(res));
> + if (!base)
> + return -ENODEV;
> +
> + dram = mv_mbus_dram_info();
> + mv_usb3_conf_mbus_windows(base, dram);
> +
> + /*
> +  * This memory area was only needed to configure the MBus
> +  * windows, and is therefore no longer useful.
> +  */
> + iounmap(base);
> +
> + return ret;
> +}
> diff --git a/drivers/usb/host/xhci-mvebu.h b/drivers/usb/host/xhci-mvebu.h
> new file mode 100644
> index ..5d7e647b3d27
> --- /dev/null
> +++ b/drivers/usb/host/xhci-mvebu.h
> @@ -0,0 +1,22 @@
> +/*
> + * Copyright (C) 2014 Marvell
> + *
> + * Gregory Clement 
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#ifndef __LINUX_XHCI_MVEBU_H
> +#define __LINUX_XHCI_MVEBU_H
> +
> +#ifdef CONFIG_USB_XHCI_MVEBU

this is a tristate symbol, you're not treating the case where this is a
module. Have you really build-tested this patch ? It would give you
redefinition errors. Switch over to:

#if IS_ENABLED(CONFIG_USB_XHCI_MVEBU)

> +int xhci_mvebu_mbus_init_quirk(struct platform_device

Re: [PATCH] USB: io_ti: fix firmware download on big-endian machines

2014-04-25 Thread 'Johan Hovold' 
On Fri, Apr 25, 2014 at 01:36:25PM +, David Laight wrote:
> From: Johan Hovold
> > During firmware download the device expects memory addresses in
> > big-endian byte order. As the wIndex parameter which hold the address is
> > sent in little-endian byte order regardless of host byte order, we need
> > to use swab16 rather than cpu_to_be16.
> 
> That doesn't sound correct.
> If the value needs to be little-endian, shouldn't you be using
> cpu_to_le16() ?

It needs to be *big-endian*, otherwise you got it right.

> If there is a second cpu_to_be16() being done later on then
> the code might be right, but the comments are misleading.

There's a second *cpu_to_le16* in usb_ctrl_msg which makes sure that the
wIndex parameter is sent little-endian.

So in order to transfer a big-endian address using wIndex, we must
use swab16 rather than cpu_to_be16 on the address (as the latter is a
noop on a big-endian system).

Johan
--
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: serial: fix sysfs-attribute removal deadlock

2014-04-25 Thread Johan Hovold 
On Fri, Apr 25, 2014 at 09:54:33AM -0400, Alan Stern wrote:
> On Fri, 25 Apr 2014, Li Zhong wrote:
> 
> > > I don't get why try_module_get() matters here.  We can't call into
> > > ->store if the object at hand is already destroyed and the underlying
> > > module can't go away if the target device is still alive.
> > > try_module_get() doesn't actually protect the object.  Why does that
> > > matter?  This is self removal, right?  Can you please take a look at
> > > kernfs_remove_self()?
> > 
> > This is about one process writing something to driver attributes, and
> > one process trying to unload this driver. 
> > 
> > I think try_module_get() could detect whether the driver is being
> > unloaded, and if not, prevent it from being unloaded, so it could
> > protect the object here by not allow the driver to be unloaded.
> 
> That isn't how try_module_get() works.  If the module is being 
> unloaded, try_module_get() simply fails.  It does not prevent the 
> module from being unloaded -- that's why its name begins with "try".

Well, to be fair, if the try_module_get() *succeeds* it will prevent the
module from being unloaded (and otherwise the sysfs operation bails
out).

Johan
--
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/2] uwb: add error messages when reservation establish fails

2014-04-25 Thread Thomas Pugliese 
Add better error messages during the channel change/reservation establish 
process.

Signed-off-by: Thomas Pugliese 
---
 drivers/uwb/beacon.c |  4 +++-
 drivers/uwb/rsv.c| 14 --
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/uwb/beacon.c b/drivers/uwb/beacon.c
index 57b5ff6..b476187 100644
--- a/drivers/uwb/beacon.c
+++ b/drivers/uwb/beacon.c
@@ -125,8 +125,10 @@ int uwb_rc_beacon(struct uwb_rc *rc, int channel, unsigned 
bpst_offset)
else {
/* channel >= 0...dah */
result = uwb_rc_start_beacon(rc, bpst_offset, channel);
-   if (result < 0)
+   if (result < 0) {
+   dev_err(dev, "Cannot start beaconing: %d\n", result);
return result;
+   }
if (le16_to_cpu(rc->ies->wIELength) > 0) {
result = uwb_rc_set_ie(rc, rc->ies);
if (result < 0) {
diff --git a/drivers/uwb/rsv.c b/drivers/uwb/rsv.c
index 4026f1a..0887ae9 100644
--- a/drivers/uwb/rsv.c
+++ b/drivers/uwb/rsv.c
@@ -163,8 +163,10 @@ static int uwb_rsv_get_stream(struct uwb_rsv *rsv)
}
 
stream = find_first_zero_bit(streams_bm, UWB_NUM_STREAMS);
-   if (stream >= UWB_NUM_STREAMS)
+   if (stream >= UWB_NUM_STREAMS) {
+   dev_err(dev, "%s: no available stream found\n", __func__);
return -EBUSY;
+   }
 
rsv->stream = stream;
set_bit(stream, streams_bm);
@@ -555,12 +557,16 @@ int uwb_rsv_establish(struct uwb_rsv *rsv)
 {
struct uwb_rc *rc = rsv->rc;
struct uwb_mas_bm available;
+   struct device *dev = &rc->uwb_dev.dev;
int ret;
 
mutex_lock(&rc->rsvs_mutex);
ret = uwb_rsv_get_stream(rsv);
-   if (ret)
+   if (ret) {
+   dev_err(dev, "%s: uwb_rsv_get_stream failed: %d\n",
+   __func__, ret);
goto out;
+   }
 
rsv->tiebreaker = prandom_u32() & 1;
/* get available mas bitmap */
@@ -570,12 +576,16 @@ int uwb_rsv_establish(struct uwb_rsv *rsv)
if (ret == UWB_RSV_ALLOC_NOT_FOUND) {
ret = -EBUSY;
uwb_rsv_put_stream(rsv);
+   dev_err(dev, "%s: uwb_rsv_find_best_allocation failed: %d\n",
+   __func__, ret);
goto out;
}
 
ret = uwb_drp_avail_reserve_pending(rc, &rsv->mas);
if (ret != 0) {
uwb_rsv_put_stream(rsv);
+   dev_err(dev, "%s: uwb_drp_avail_reserve_pending failed: %d\n",
+   __func__, ret);
goto out;
}
 
-- 
1.8.3.2

--
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/2] uwb: fix channel change failure

2014-04-25 Thread Thomas Pugliese 
Make the transition to the UWB_RSV_STATE_NONE state synchronous so that 
there is not a race between uwb_rsv_terminate and uwb_rsv_establish. 
uwb_rsv_terminate would set the rsv->state to UWB_RSV_STATE_NONE but did 
not release the stream resource until a 320ms timeout had expired.  If a 
user called uwb_rsv_establish during that time, it could fail to 
establish the reservation because no stream resources were available. 
This patch removes the timer from the uwb_rsv_terminate process since it 
is not needed when transitioning to UWB_RSV_STATE_NONE.

Signed-off-by: Thomas Pugliese 
---
 drivers/uwb/rsv.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/uwb/rsv.c b/drivers/uwb/rsv.c
index 3fe6119..4026f1a 100644
--- a/drivers/uwb/rsv.c
+++ b/drivers/uwb/rsv.c
@@ -249,7 +249,9 @@ static void uwb_rsv_stroke_timer(struct uwb_rsv *rsv)
 * super frame and should not be terminated if no response is
 * received.
 */
-   if (rsv->is_multicast) {
+   if (rsv->state == UWB_RSV_STATE_NONE) {
+   sframes = 0;
+   } else if (rsv->is_multicast) {
if (rsv->state == UWB_RSV_STATE_O_INITIATED
|| rsv->state == UWB_RSV_STATE_O_MOVE_EXPANDING
|| rsv->state == UWB_RSV_STATE_O_MOVE_COMBINING
@@ -322,6 +324,7 @@ void uwb_rsv_set_state(struct uwb_rsv *rsv, enum 
uwb_rsv_state new_state)
switch (new_state) {
case UWB_RSV_STATE_NONE:
uwb_rsv_state_update(rsv, UWB_RSV_STATE_NONE);
+   uwb_rsv_remove(rsv);
uwb_rsv_callback(rsv);
break;
case UWB_RSV_STATE_O_INITIATED:
@@ -442,6 +445,8 @@ static void uwb_rsv_handle_timeout_work(struct work_struct 
*work)
uwb_rsv_set_state(rsv, UWB_RSV_STATE_T_ACCEPTED);
uwb_drp_avail_release(rsv->rc, &rsv->mv.companion_mas);
goto unlock;
+   case UWB_RSV_STATE_NONE:
+   goto unlock;
default:
break;
}
-- 
1.8.3.2

--
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/2] fix channel change failure

2014-04-25 Thread Thomas Pugliese 
Fix an intermittent failure when changing channels and report better 
errors during the channel change process.

Thomas Pugliese (2):
  uwb: fix channel change failure
  uwb: add error messages when reservation establish fails

 drivers/uwb/beacon.c |  4 +++-
 drivers/uwb/rsv.c| 21 ++---
 2 files changed, 21 insertions(+), 4 deletions(-)

-- 
1.8.3.2

--
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 14/18] ARM: mvebu: Add support for USB cluster on the Armada 375 SoC

2014-04-25 Thread Ezequiel Garcia 
On Apr 25, Gregory CLEMENT wrote:
> The Armada 375 SoC comes with an USB2 host and device controller and
> an USB3 controller. The USB cluster control register allows to manage
> common features of both USB controllers.
> 
> Signed-off-by: Gregory CLEMENT 
> ---
>  arch/arm/mach-mvebu/Makefile  |  2 +-
>  arch/arm/mach-mvebu/usb-cluster.c | 96 
> +++
>  2 files changed, 97 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/mach-mvebu/usb-cluster.c
> 
> diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
> index a63e43b6b451..dec05e7e1802 100644
> --- a/arch/arm/mach-mvebu/Makefile
> +++ b/arch/arm/mach-mvebu/Makefile
> @@ -4,7 +4,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := 
> -I$(srctree)/$(src)/include \
>  AFLAGS_coherency_ll.o:= -Wa,-march=armv7-a
>  
>  obj-y += system-controller.o mvebu-soc-id.o
> -obj-$(CONFIG_MACH_MVEBU_V7)  += board-v7.o
> +obj-$(CONFIG_MACH_MVEBU_V7)  += board-v7.o usb-cluster.o
>  obj-$(CONFIG_MACH_DOVE)   += dove.o
>  obj-$(CONFIG_ARCH_MVEBU)  += coherency.o coherency_ll.o pmsu.o
>  obj-$(CONFIG_SMP)+= platsmp.o headsmp.o
> diff --git a/arch/arm/mach-mvebu/usb-cluster.c 
> b/arch/arm/mach-mvebu/usb-cluster.c
> new file mode 100644
> index ..4c15d282db23
> --- /dev/null
> +++ b/arch/arm/mach-mvebu/usb-cluster.c
> @@ -0,0 +1,96 @@
> +/*
> + * USB cluster support for Armada 375 platform.
> + *
> + * Copyright (C) 2014 Marvell
> + *
> + * Gregory CLEMENT 
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + *
> + * Armada 375 comes with an USB2 host and device controller and an
> + * USB3 controller. The USB cluster control register allows to manage
> + * common features of both USB controller.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define USB2_PHY_CONFIG_ENABLE BIT(0) /* active low */
> +

If it's active low, maybe you can simply call this USB2_PHY_DISABLE?

> +static struct of_device_id of_usb_cluster_table[] = {
> + { .compatible = "marvell,armada-375-usb-cluster", },
> + { /* end of list */ },
> +};
> +
> +static int __init mvebu_usb_cluster_init(void)
> +{
> + struct device_node *np;
> +
> + np = of_find_matching_node(NULL, of_usb_cluster_table);
> + if (np) {

I think that writing:

if (!np)
return 0;

Will allow to write the rest with less indentation, which is usually cleaner.

> + void __iomem *usb_cluster_base;
> + u32 reg;
> + struct device_node *ehci_node, *xhci_node;
> + struct property *ehci_status;
> + bool use_usb3 = false;
> +
> + usb_cluster_base = of_iomap(np, 0);
> + BUG_ON(!usb_cluster_base);
> +
> + xhci_node = of_find_compatible_node(NULL, NULL,
> + "marvell,armada-375-xhci");
> +
> + if (xhci_node && of_device_is_available(xhci_node))
> + use_usb3 = true;
> +
> + ehci_node = of_find_compatible_node(NULL, NULL,
> + "marvell,orion-ehci");
> +
> + if (ehci_node && of_device_is_available(ehci_node)
> + && use_usb3) {
> + /*
> +  * We can't use usb2 and usb3 in the same time, so let's
> +  * disbale usb2 and complain about it to the user askinf

typos: disable, asking

> +  * to fix the device tree.
> +  */
> +
> + ehci_status = kzalloc(sizeof(struct property),
> + GFP_KERNEL);
> + WARN_ON(!ehci_status);
> +
> + ehci_status->value = kstrdup("disabled", GFP_KERNEL);

Unless I'm missing something, warning about allocation error but then still
using the pointer will cause very nasty problems. Maybe you can simply
bail out?

> + WARN_ON(!ehci_status->value);
> +
> + ehci_status->length = 8;
> + ehci_status->name = kstrdup("status", GFP_KERNEL);
> + WARN_ON(!ehci_status->name);
> +
> + of_update_property(ehci_node, ehci_status);
> + pr_err("%s: armada-375-xhci and orion-ehci are 
> incompatible for this SoC.\n",
> + __func__);
> + pr_err("Please fix your dts!\n");
> + pr_err("orion-ehci have been disabled by default...\n");
> +

We've been using a WARN(1, FW_BUG "") to notify the user of a broken DT.
Arnd suggested to use WARN() to really catch the user's attention.

> + }
> +
> + reg = readl(usb_cluster_bas

Re: [PATCH v2 02/18] usb: host: xhci-plat: Add clocks support

2014-04-25 Thread Andrew Lunn 
On Fri, Apr 25, 2014 at 04:07:00PM +0200, Gregory CLEMENT wrote:
> Some platform (such as the Armada 38x ones) can gate the clock of
> their USB controller. This patch add the support for the clock, by
> enabling them during probe and disabling them on remove.
> 
> As not all platforms have clock support then enabling and disabling
> the clocks have been placed in separate functions. Then if the clocks
> are not supported we still can use the same calls, and there is no
> 
> Signed-off-by: Gregory CLEMENT 
> ---
>  drivers/usb/host/xhci-plat.c | 52 
> ++--
>  1 file changed, 50 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index f5351af4b2c5..bb5d563f729c 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -11,6 +11,7 @@
>   * version 2 as published by the Free Software Foundation.
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -85,6 +86,42 @@ static const struct hc_driver xhci_plat_xhci_driver = {
>   .bus_resume =   xhci_bus_resume,
>  };
>  
> +#if defined(CONFIG_HAVE_CLK)

Hi Gregory

You probably don't need to do this conditional on CONFIG_HAVE_CLK.
There are stub functions in clk.h for when CONFIG_HAVE_CLK is not
defined. So the compiler knows devm_clk_get() will return NULL, it can
evaluate IS_ERR is false, clk_prepare() returns 0 and so the whole
function collapses to "return 0;"

> +static int try_enable_clk(struct platform_device *pdev)
> +{
> + struct clk *clk = devm_clk_get(&pdev->dev, NULL);
> +
> + /* Not all platforms have a clk so it is not an error if the clock
> +does not exists. */
> + if (!IS_ERR(clk))
> + if (clk_prepare_enable(clk))
> + return  -ENODEV;

Is ENODEV the correct error code? It would probably be better to
return the return value of clk_prepare_enable()

> + return 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 v2 14/18] ARM: mvebu: Add support for USB cluster on the Armada 375 SoC

2014-04-25 Thread Andrew Lunn 
> > +* We can't use usb2 and usb3 in the same time, so let's
> > +* disbale usb2 and complain about it to the user askinf
> 
> typos: disable, asking

And it should be "at the same time", not in.

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: [PATCH v2 05/18] ARM: mvebu: Add Device Tree description of xHCI hosts on Armada 38x

2014-04-25 Thread Andrew Lunn 
On Fri, Apr 25, 2014 at 04:07:03PM +0200, Gregory CLEMENT wrote:
> The Marvell Armada 38x SoCs contain two xHCI host. This commit adds
> the Device Tree description of those interfaces at the SoC level, and
> also enables the two USB3 ports on the Armada 385 DB platform and one
> USB3 port on the Armada 385 RD platforms.
> 
> Signed-off-by: Gregory CLEMENT 
> ---
>  arch/arm/boot/dts/armada-385-db.dts |  8 
>  arch/arm/boot/dts/armada-385-rd.dts |  4 
>  arch/arm/boot/dts/armada-38x.dtsi   | 17 +
>  3 files changed, 29 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/armada-385-db.dts 
> b/arch/arm/boot/dts/armada-385-db.dts
> index 6828d77696a6..d5db1466da82 100644
> --- a/arch/arm/boot/dts/armada-385-db.dts
> +++ b/arch/arm/boot/dts/armada-385-db.dts
> @@ -101,6 +101,14 @@
>   reg = <0x100 0x3f00>;
>   };
>   };
> +
> + usb3@f {
> + status = "okay";
> + };
> +
> + usb3@f8000 {
> + status = "okay";
> + };
>   };
>  
>   pcie-controller {
> diff --git a/arch/arm/boot/dts/armada-385-rd.dts 
> b/arch/arm/boot/dts/armada-385-rd.dts
> index 45250c88814b..a505fe94ff37 100644
> --- a/arch/arm/boot/dts/armada-385-rd.dts
> +++ b/arch/arm/boot/dts/armada-385-rd.dts
> @@ -77,6 +77,10 @@
>   reg = <1>;
>   };
>   };
> +
> + usb3@f {
> + status = "okay";
> + };
>   };
>  
>   pcie-controller {
> diff --git a/arch/arm/boot/dts/armada-38x.dtsi 
> b/arch/arm/boot/dts/armada-38x.dtsi
> index a064f59da02d..5913ce1cc601 100644
> --- a/arch/arm/boot/dts/armada-38x.dtsi
> +++ b/arch/arm/boot/dts/armada-38x.dtsi
> @@ -355,6 +355,23 @@
>   clocks = <&coredivclk 0>;
>   status = "disabled";
>   };
> +
> + usb3@f {
> + compatible = "marvell,armada-380-xhci";
> + reg = <0xf 0x3fff>,<0xf4000 0x3fff>;

s/0x3fff/0x4000/g  ?

Andrew 

> + interrupts = ;
> + clocks = <&gateclk 9>;
> + status = "disabled";
> + };
> +
> + usb3@f8000 {
> + compatible = "marvell,armada-380-xhci";
> + reg = <0xf8000 0x3fff>,<0xfc000 0x3fff>;
> + interrupts = ;
> + clocks = <&gateclk 10>;
> + status = "disabled";
> + };
> +
>   };
>   };
>  
> -- 
> 1.8.1.2
> 
--
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 4/4] usb/xhci: fix compilation warning when !CONFIG_PCI && !CONFIG_PM

2014-04-25 Thread Mathias Nyman 
From: David Cohen 

When CONFIG_PCI and CONFIG_PM are not selected, xhci.c gets this
warning:
drivers/usb/host/xhci.c:409:13: warning: ‘xhci_msix_sync_irqs’ defined
but not used [-Wunused-function]

Instead of creating nested #ifdefs, this patch fixes it by defining the
xHCI PCI stubs as inline.

This warning has been in since 3.2 kernel and was
caused by commit 421aa841a134f6a743111cf44d0c6d3b45e3cf8c
"usb/xhci: hide MSI code behind PCI bars", but wasn't noticed
until 3.13 when a configuration with these options was tried

Signed-off-by: David Cohen 
Cc: sta...@vger.kernel.org # 3.2
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 988ed5f..3008369 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -408,16 +408,16 @@ static int xhci_try_enable_msi(struct usb_hcd *hcd)
 
 #else
 
-static int xhci_try_enable_msi(struct usb_hcd *hcd)
+static inline int xhci_try_enable_msi(struct usb_hcd *hcd)
 {
return 0;
 }
 
-static void xhci_cleanup_msix(struct xhci_hcd *xhci)
+static inline void xhci_cleanup_msix(struct xhci_hcd *xhci)
 {
 }
 
-static void xhci_msix_sync_irqs(struct xhci_hcd *xhci)
+static inline void xhci_msix_sync_irqs(struct xhci_hcd *xhci)
 {
 }
 
-- 
1.8.3.2

--
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 14/18] ARM: mvebu: Add support for USB cluster on the Armada 375 SoC

2014-04-25 Thread Felipe Balbi 
On Fri, Apr 25, 2014 at 06:07:05PM +0200, Andrew Lunn wrote:
> On Fri, Apr 25, 2014 at 04:07:12PM +0200, Gregory CLEMENT wrote:
> > The Armada 375 SoC comes with an USB2 host and device controller and
> > an USB3 controller. The USB cluster control register allows to manage
> > common features of both USB controllers.
> > 
> > Signed-off-by: Gregory CLEMENT 
> > ---
> >  arch/arm/mach-mvebu/Makefile  |  2 +-
> >  arch/arm/mach-mvebu/usb-cluster.c | 96 
> > +++
> >  2 files changed, 97 insertions(+), 1 deletion(-)
> >  create mode 100644 arch/arm/mach-mvebu/usb-cluster.c
> > 
> > diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
> > index a63e43b6b451..dec05e7e1802 100644
> > --- a/arch/arm/mach-mvebu/Makefile
> > +++ b/arch/arm/mach-mvebu/Makefile
> > @@ -4,7 +4,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := 
> > -I$(srctree)/$(src)/include \
> >  AFLAGS_coherency_ll.o  := -Wa,-march=armv7-a
> >  
> >  obj-y   += system-controller.o mvebu-soc-id.o
> > -obj-$(CONFIG_MACH_MVEBU_V7)  += board-v7.o
> > +obj-$(CONFIG_MACH_MVEBU_V7)  += board-v7.o usb-cluster.o
> >  obj-$(CONFIG_MACH_DOVE) += dove.o
> >  obj-$(CONFIG_ARCH_MVEBU)+= coherency.o coherency_ll.o pmsu.o
> >  obj-$(CONFIG_SMP)+= platsmp.o headsmp.o
> > diff --git a/arch/arm/mach-mvebu/usb-cluster.c 
> > b/arch/arm/mach-mvebu/usb-cluster.c
> > new file mode 100644
> > index ..4c15d282db23
> > --- /dev/null
> > +++ b/arch/arm/mach-mvebu/usb-cluster.c
> > @@ -0,0 +1,96 @@
> > +/*
> > + * USB cluster support for Armada 375 platform.
> > + *
> > + * Copyright (C) 2014 Marvell
> > + *
> > + * Gregory CLEMENT 
> > + *
> > + * This file is licensed under the terms of the GNU General Public
> > + * License version 2.  This program is licensed "as is" without any
> > + * warranty of any kind, whether express or implied.
> > + *
> > + * Armada 375 comes with an USB2 host and device controller and an
> > + * USB3 controller. The USB cluster control register allows to manage
> > + * common features of both USB controller.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define USB2_PHY_CONFIG_ENABLE BIT(0) /* active low */
> > +
> > +static struct of_device_id of_usb_cluster_table[] = {
> > +   { .compatible = "marvell,armada-375-usb-cluster", },
> > +   { /* end of list */ },
> > +};
> > +
> > +static int __init mvebu_usb_cluster_init(void)
> > +{
> > +   struct device_node *np;
> > +
> > +   np = of_find_matching_node(NULL, of_usb_cluster_table);
> > +   if (np) {
> > +   void __iomem *usb_cluster_base;
> > +   u32 reg;
> > +   struct device_node *ehci_node, *xhci_node;
> > +   struct property *ehci_status;
> > +   bool use_usb3 = false;
> > +
> > +   usb_cluster_base = of_iomap(np, 0);
> > +   BUG_ON(!usb_cluster_base);
> > +
> > +   xhci_node = of_find_compatible_node(NULL, NULL,
> > +   "marvell,armada-375-xhci");
> > +
> > +   if (xhci_node && of_device_is_available(xhci_node))
> > +   use_usb3 = true;
> > +
> > +   ehci_node = of_find_compatible_node(NULL, NULL,
> > +   "marvell,orion-ehci");
> > +
> > +   if (ehci_node && of_device_is_available(ehci_node)
> > +   && use_usb3) {
> > +   /*
> > +* We can't use usb2 and usb3 in the same time, so let's
> > +* disbale usb2 and complain about it to the user askinf
> > +* to fix the device tree.
> > +*/
> > +
> > +   ehci_status = kzalloc(sizeof(struct property),
> > +   GFP_KERNEL);
> > +   WARN_ON(!ehci_status);
> > +
> > +   ehci_status->value = kstrdup("disabled", GFP_KERNEL);
> > +   WARN_ON(!ehci_status->value);
> > +
> > +   ehci_status->length = 8;
> > +   ehci_status->name = kstrdup("status", GFP_KERNEL);
> > +   WARN_ON(!ehci_status->name);
> > +
> > +   of_update_property(ehci_node, ehci_status);
> > +   pr_err("%s: armada-375-xhci and orion-ehci are 
> > incompatible for this SoC.\n",
> > +   __func__);
> > +   pr_err("Please fix your dts!\n");
> > +   pr_err("orion-ehci have been disabled by default...\n");
> > +
> > +   }
> > +
> > +   reg = readl(usb_cluster_base);
> > +   if (use_usb3)
> > +   reg |= USB2_PHY_CONFIG_ENABLE;
> > +   else
> > +   reg &= ~USB2_PHY_CONFIG_ENABLE;
> > +   writel(reg, usb_cluster_base);
> 
> Am i right in saying this in the end is about enabling the USB2 phy or
> a USB3 why? So wh

[PATCH v2 3/4] xhci: extend quirk for Renesas cards

2014-04-25 Thread Mathias Nyman 
From: Igor Gnatenko 

After suspend another Renesas PCI-X USB 3.0 card doesn't work.
[root@fedora-20 ~]# lspci -vmnnd 1912:
Device: 03:00.0
Class:  USB controller [0c03]
Vendor: Renesas Technology Corp. [1912]
Device: uPD720202 USB 3.0 Host Controller [0015]
SVendor:Renesas Technology Corp. [1912]
SDevice:uPD720202 USB 3.0 Host Controller [0015]
Rev:02
ProgIf: 30

This patch should be applied to stable kernel 3.14 that contain
the commit 1aa9578c1a9450fb21501c4f549f5b1edb557e6d
"xhci: Fix resume issues on Renesas chips in Samsung laptops"

Reported-and-tested-by: Anatoly Kharchenko 
Reference: http://redmine.russianfedora.pro/issues/1315
Signed-off-by: Igor Gnatenko 
Cc: sta...@vger.kernel.org # 3.14
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-pci.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 1715063..35d4477 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -145,9 +145,7 @@ static void xhci_pci_quirks(struct device *dev, struct 
xhci_hcd *xhci)
xhci->quirks |= XHCI_TRUST_TX_LENGTH;
}
if (pdev->vendor == PCI_VENDOR_ID_RENESAS &&
-   pdev->device == 0x0015 &&
-   pdev->subsystem_vendor == PCI_VENDOR_ID_SAMSUNG &&
-   pdev->subsystem_device == 0xc0cd)
+   pdev->device == 0x0015)
xhci->quirks |= XHCI_RESET_ON_RESUME;
if (pdev->vendor == PCI_VENDOR_ID_VIA)
xhci->quirks |= XHCI_RESET_ON_RESUME;
-- 
1.8.3.2

--
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: Deadlock v3.10.35 with FTD_SIO usb-serial adapter

2014-04-25 Thread Alan Stern 
On Thu, 24 Apr 2014, Matteo Fortini wrote:

> After some time, we finally had another hangup on kernel 3.14.
> 
> @Alan: Here's the info we got in the files you mentioned. At any rate, 
> we're keeping the board in the same state so that we can run/produce any 
> other needed info.
> 
> http://pastebin.com/DZPAqjcd

To find out exactly what's going wrong, I need more information.  Below 
is a patch you can apply that will add more data to the "registers" 
file in the /sys/kernel/debug/usb/ohci/* directory.

Run with the patched kernel, and the next time you get a similar hang,
see what's in the "registers" file.  In fact, since the contents change
over time, make two copies of the file, a few seconds apart.

Alan Stern



Index: usb-3.14/drivers/usb/host/ohci-dbg.c
===
--- usb-3.14.orig/drivers/usb/host/ohci-dbg.c
+++ usb-3.14/drivers/usb/host/ohci-dbg.c
@@ -108,6 +108,9 @@ ohci_dump_status (struct ohci_hcd *contr
0x03 & (temp >> 4), (temp & 0x0f),
(temp & 0x0100) ? "with" : "NO",
rh_state_string(controller));
+   ohci_dbg_sw(controller, next, size,
+   "WDH count %u  SF count %u\n",
+   controller->wdh_count, controller->sf_count);
 
temp = ohci_readl (controller, ®s->control);
ohci_dbg_sw (controller, next, size,
@@ -354,6 +357,48 @@ ohci_dump_ed (const struct ohci_hcd *ohc
}
 }
 
+static void ohci_dump_ed_rm_list(struct ohci_hcd *ohci,
+   char **next, unsigned *size)
+{
+   unsignedtemp;
+   struct ed   *ed;
+   struct td   *td, *td2;
+   unsignedtdptr, tdptr2;
+   unsignedtddma, tddma2;
+   unsignedinfo;
+
+   temp = scnprintf(*next, *size, "ed_rm_list:\n");
+   *size -= temp;
+   *next += temp;
+
+   for (ed = ohci->ed_rm_list; ed; ed = ed->ed_next) {
+   info = hc32_to_cpu(ohci, ed->hwINFO);
+   tdptr = tdptr2 = 0;
+   tddma = tddma2 = 0;
+   if (!list_empty(&ed->td_list)) {
+   td = list_first_entry(&ed->td_list, struct td, td_list);
+   tdptr = hc32_to_cpu(ohci, ed->hwHeadP) & TD_MASK;
+   tddma = (unsigned) td->td_dma;
+
+   if (list_is_last(&td->td_list, &ed->td_list))
+   td2 = ed->dummy;
+   else
+   td2 = list_first_entry(&td->td_list,
+   struct td, td_list);
+   tdptr2 = hc32_to_cpu(ohci, td->hwNextTD) & TD_MASK;
+   tddma2 = (unsigned) td2->td_dma;
+   }
+
+   temp = scnprintf(*next, *size,
+   "  ED dev %d ep %x(%d) tick %04x td1 %x %x td2 
%x %x\n",
+   info & 0x7f, (info >> 7) & 0xf,
+   (info >> 11) & 0x3,
+   ed->tick, tddma, tdptr, tddma2, tdptr2);
+   *size -= temp;
+   *next += temp;
+   }
+}
+
 /*-*/
 
 static int debug_async_open(struct inode *, struct file *);
@@ -652,6 +697,8 @@ static ssize_t fill_registers_buffer(str
/* roothub */
ohci_dump_roothub (ohci, 1, &next, &size);
 
+   ohci_dump_ed_rm_list(ohci, &next, &size);
+
 done:
spin_unlock_irqrestore (&ohci->lock, flags);
 
Index: usb-3.14/drivers/usb/host/ohci-hcd.c
===
--- usb-3.14.orig/drivers/usb/host/ohci-hcd.c
+++ usb-3.14/drivers/usb/host/ohci-hcd.c
@@ -866,6 +866,7 @@ static irqreturn_t ohci_irq (struct usb_
if (ints & OHCI_INTR_WDH) {
spin_lock (&ohci->lock);
dl_done_list (ohci);
+   ++ohci->wdh_count;
spin_unlock (&ohci->lock);
}
 
@@ -902,6 +903,8 @@ static irqreturn_t ohci_irq (struct usb_
spin_lock (&ohci->lock);
if (ohci->ed_rm_list)
finish_unlinks (ohci, ohci_frame_no(ohci));
+   if (ints & OHCI_INTR_SF)
+   ++ohci->sf_count;
if ((ints & OHCI_INTR_SF) != 0
&& !ohci->ed_rm_list
&& !ohci->ed_to_check
Index: usb-3.14/drivers/usb/host/ohci.h
===
--- usb-3.14.orig/drivers/usb/host/ohci.h
+++ usb-3.14/drivers/usb/host/ohci.h
@@ -415,6 +415,8 @@ struct ohci_hcd {
struct ed   *ed_to_check;
unsignedzf_delay;
 
+   unsignedsf_count, wdh_count;
+
struct dentry   *debug_dir;
struct dentry   *debug_async;
struct dentry   *debug_periodic;

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the bo

Re: [PATCH v2 14/18] ARM: mvebu: Add support for USB cluster on the Armada 375 SoC

2014-04-25 Thread Andrew Lunn 
On Fri, Apr 25, 2014 at 04:07:12PM +0200, Gregory CLEMENT wrote:
> The Armada 375 SoC comes with an USB2 host and device controller and
> an USB3 controller. The USB cluster control register allows to manage
> common features of both USB controllers.
> 
> Signed-off-by: Gregory CLEMENT 
> ---
>  arch/arm/mach-mvebu/Makefile  |  2 +-
>  arch/arm/mach-mvebu/usb-cluster.c | 96 
> +++
>  2 files changed, 97 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/mach-mvebu/usb-cluster.c
> 
> diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
> index a63e43b6b451..dec05e7e1802 100644
> --- a/arch/arm/mach-mvebu/Makefile
> +++ b/arch/arm/mach-mvebu/Makefile
> @@ -4,7 +4,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := 
> -I$(srctree)/$(src)/include \
>  AFLAGS_coherency_ll.o:= -Wa,-march=armv7-a
>  
>  obj-y += system-controller.o mvebu-soc-id.o
> -obj-$(CONFIG_MACH_MVEBU_V7)  += board-v7.o
> +obj-$(CONFIG_MACH_MVEBU_V7)  += board-v7.o usb-cluster.o
>  obj-$(CONFIG_MACH_DOVE)   += dove.o
>  obj-$(CONFIG_ARCH_MVEBU)  += coherency.o coherency_ll.o pmsu.o
>  obj-$(CONFIG_SMP)+= platsmp.o headsmp.o
> diff --git a/arch/arm/mach-mvebu/usb-cluster.c 
> b/arch/arm/mach-mvebu/usb-cluster.c
> new file mode 100644
> index ..4c15d282db23
> --- /dev/null
> +++ b/arch/arm/mach-mvebu/usb-cluster.c
> @@ -0,0 +1,96 @@
> +/*
> + * USB cluster support for Armada 375 platform.
> + *
> + * Copyright (C) 2014 Marvell
> + *
> + * Gregory CLEMENT 
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2.  This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + *
> + * Armada 375 comes with an USB2 host and device controller and an
> + * USB3 controller. The USB cluster control register allows to manage
> + * common features of both USB controller.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define USB2_PHY_CONFIG_ENABLE BIT(0) /* active low */
> +
> +static struct of_device_id of_usb_cluster_table[] = {
> + { .compatible = "marvell,armada-375-usb-cluster", },
> + { /* end of list */ },
> +};
> +
> +static int __init mvebu_usb_cluster_init(void)
> +{
> + struct device_node *np;
> +
> + np = of_find_matching_node(NULL, of_usb_cluster_table);
> + if (np) {
> + void __iomem *usb_cluster_base;
> + u32 reg;
> + struct device_node *ehci_node, *xhci_node;
> + struct property *ehci_status;
> + bool use_usb3 = false;
> +
> + usb_cluster_base = of_iomap(np, 0);
> + BUG_ON(!usb_cluster_base);
> +
> + xhci_node = of_find_compatible_node(NULL, NULL,
> + "marvell,armada-375-xhci");
> +
> + if (xhci_node && of_device_is_available(xhci_node))
> + use_usb3 = true;
> +
> + ehci_node = of_find_compatible_node(NULL, NULL,
> + "marvell,orion-ehci");
> +
> + if (ehci_node && of_device_is_available(ehci_node)
> + && use_usb3) {
> + /*
> +  * We can't use usb2 and usb3 in the same time, so let's
> +  * disbale usb2 and complain about it to the user askinf
> +  * to fix the device tree.
> +  */
> +
> + ehci_status = kzalloc(sizeof(struct property),
> + GFP_KERNEL);
> + WARN_ON(!ehci_status);
> +
> + ehci_status->value = kstrdup("disabled", GFP_KERNEL);
> + WARN_ON(!ehci_status->value);
> +
> + ehci_status->length = 8;
> + ehci_status->name = kstrdup("status", GFP_KERNEL);
> + WARN_ON(!ehci_status->name);
> +
> + of_update_property(ehci_node, ehci_status);
> + pr_err("%s: armada-375-xhci and orion-ehci are 
> incompatible for this SoC.\n",
> + __func__);
> + pr_err("Please fix your dts!\n");
> + pr_err("orion-ehci have been disabled by default...\n");
> +
> + }
> +
> + reg = readl(usb_cluster_base);
> + if (use_usb3)
> + reg |= USB2_PHY_CONFIG_ENABLE;
> + else
> + reg &= ~USB2_PHY_CONFIG_ENABLE;
> + writel(reg, usb_cluster_base);

Am i right in saying this in the end is about enabling the USB2 phy or
a USB3 why? So why not just implement a phy driver?

  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.kern

[PATCH v2 2/4] xhci: Switch Intel Lynx Point ports to EHCI on shutdown.

2014-04-25 Thread Mathias Nyman 
From: Denis Turischev 

The same issue like with Panther Point chipsets. If the USB ports are
switched to xHCI on shutdown, the xHCI host will send a spurious interrupt,
which will wake the system. Some BIOS have work around for this, but not all.
One example is Compulab's mini-desktop, the Intense-PC2.

The bug can be avoided if the USB ports are switched back to EHCI on
shutdown.

This patch should be backported to stable kernels as old as 3.12,
that contain the commit 638298dc66ea36623dbc2757a24fc2c4ab41b016
"xhci: Fix spurious wakeups after S5 on Haswell"

Signed-off-by: Denis Turischev 
Cc: sta...@vger.kernel.org
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-pci.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 47390e3..1715063 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -134,6 +134,8 @@ static void xhci_pci_quirks(struct device *dev, struct 
xhci_hcd *xhci)
 */
if (pdev->subsystem_vendor == PCI_VENDOR_ID_HP)
xhci->quirks |= XHCI_SPURIOUS_WAKEUP;
+
+   xhci->quirks |= XHCI_SPURIOUS_REBOOT;
}
if (pdev->vendor == PCI_VENDOR_ID_ETRON &&
pdev->device == PCI_DEVICE_ID_ASROCK_P67) {
-- 
1.8.3.2

--
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/4] usb: xhci: Prefer endpoint context dequeue pointer over stopped_trb

2014-04-25 Thread Mathias Nyman 
From: Julius Werner 

We have observed a rare cycle state desync bug after Set TR Dequeue
Pointer commands on Intel LynxPoint xHCs (resulting in an endpoint that
doesn't fetch new TRBs and thus an unresponsive USB device). It always
triggers when a previous Set TR Dequeue Pointer command has set the
pointer to the final Link TRB of a segment, and then another URB gets
enqueued and cancelled again before it can be completed. Further
investigation showed that the xHC had returned the Link TRB in the TRB
Pointer field of the Transfer Event (CC == Stopped -- Length Invalid),
but when xhci_find_new_dequeue_state() later accesses the Endpoint
Context's TR Dequeue Pointer field it is set to the first TRB of the
next segment.

The driver expects those two values to be the same in this situation,
and uses the cycle state of the latter together with the address of the
former. This should be fine according to the XHCI specification, since
the endpoint ring should be stopped when returning the Transfer Event
and thus should not advance over the Link TRB before it gets restarted.
However, real-world XHCI implementations apparently don't really care
that much about these details, so the driver should follow a more
defensive approach to try to work around HC spec violations.

This patch removes the stopped_trb variable that had been used to store
the TRB Pointer from the last Transfer Event of a stopped TRB. Instead,
xhci_find_new_dequeue_state() now relies only on the Endpoint Context,
requiring a small amount of additional processing to find the virtual
address corresponding to the TR Dequeue Pointer. Some other parts of the
function were slightly rearranged to better fit into this model.

This patch should be backported to kernels as old as 2.6.31 that contain
the commit ae636747146ea97efa18e04576acd3416e2514f5 "USB: xhci: URB
cancellation support."

Signed-off-by: Julius Werner 
Cc: sta...@vger.kernel.org
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-ring.c | 67 
 drivers/usb/host/xhci.c  |  1 -
 drivers/usb/host/xhci.h  |  2 --
 3 files changed, 31 insertions(+), 39 deletions(-)

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 5f926be..7a0e3c7 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -550,6 +550,7 @@ void xhci_find_new_dequeue_state(struct xhci_hcd *xhci,
struct xhci_ring *ep_ring;
struct xhci_generic_trb *trb;
dma_addr_t addr;
+   u64 hw_dequeue;
 
ep_ring = xhci_triad_to_transfer_ring(xhci, slot_id,
ep_index, stream_id);
@@ -559,16 +560,6 @@ void xhci_find_new_dequeue_state(struct xhci_hcd *xhci,
stream_id);
return;
}
-   state->new_cycle_state = 0;
-   xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
-   "Finding segment containing stopped TRB.");
-   state->new_deq_seg = find_trb_seg(cur_td->start_seg,
-   dev->eps[ep_index].stopped_trb,
-   &state->new_cycle_state);
-   if (!state->new_deq_seg) {
-   WARN_ON(1);
-   return;
-   }
 
/* Dig out the cycle state saved by the xHC during the stop ep cmd */
xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
@@ -577,46 +568,57 @@ void xhci_find_new_dequeue_state(struct xhci_hcd *xhci,
if (ep->ep_state & EP_HAS_STREAMS) {
struct xhci_stream_ctx *ctx =
&ep->stream_info->stream_ctx_array[stream_id];
-   state->new_cycle_state = 0x1 & le64_to_cpu(ctx->stream_ring);
+   hw_dequeue = le64_to_cpu(ctx->stream_ring);
} else {
struct xhci_ep_ctx *ep_ctx
= xhci_get_ep_ctx(xhci, dev->out_ctx, ep_index);
-   state->new_cycle_state = 0x1 & le64_to_cpu(ep_ctx->deq);
+   hw_dequeue = le64_to_cpu(ep_ctx->deq);
}
 
+   /* Find virtual address and segment of hardware dequeue pointer */
+   state->new_deq_seg = ep_ring->deq_seg;
+   state->new_deq_ptr = ep_ring->dequeue;
+   while (xhci_trb_virt_to_dma(state->new_deq_seg, state->new_deq_ptr)
+   != (dma_addr_t)(hw_dequeue & ~0xf)) {
+   next_trb(xhci, ep_ring, &state->new_deq_seg,
+   &state->new_deq_ptr);
+   if (state->new_deq_ptr == ep_ring->dequeue) {
+   WARN_ON(1);
+   return;
+   }
+   }
+   /*
+* Find cycle state for last_trb, starting at old cycle state of
+* hw_dequeue. If there is only one segment ring, find_trb_seg() will
+* return immediately and cannot toggle the cycle state if this search
+* wraps around, so add one more toggle manually in that case.
+*/
+   state->new_cycle_state = hw_dequeue & 0x1;
+   if (ep_ring-

Re: [PATCH v2 0/4] xhci: fixes for 3.15-rc usb-linus

2014-04-25 Thread Greg KH 
On Fri, Apr 25, 2014 at 07:20:12PM +0300, Mathias Nyman wrote:
> Hi Greg   
>  
>   
>  
> Second try at this xhci fixes series for 3.15-rc usb-linus.   
>   
> Most of them are very small fixes that didn't make
>  
> it to 3.14, sitting and waiting for 3.15-rc1 to come out. 
>  
>   
>  
> Only the "Prefer endpoint context.." patch  by Julius has a bit more content. 
>  
>   
>  
> These patches are picked together with Sarah, they are tested on top of   
>  
> 3.15-rc1, and apply on your current usb-linus branch  
>  

Much better, all now applied.

What's with all that trailing whitespace in your email text?

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

[PATCH v2 0/4] xhci: fixes for 3.15-rc usb-linus

2014-04-25 Thread Mathias Nyman 
Hi Greg 
   

   
Second try at this xhci fixes series for 3.15-rc usb-linus. 

Most of them are very small fixes that didn't make  
   
it to 3.14, sitting and waiting for 3.15-rc1 to come out.   
   

   
Only the "Prefer endpoint context.." patch  by Julius has a bit more content.   
   

   
These patches are picked together with Sarah, they are tested on top of 
   
3.15-rc1, and apply on your current usb-linus branch
   

changes since v1:

Drop "xhci: Use pci_enable_msix_exact() instead of pci_enable_msix()"
from this fixes series, and move to for-usb-next (3.16) instead

Add proper stable tags and information to commit messages

-Mathias   


David Cohen (1):
  usb/xhci: fix compilation warning when !CONFIG_PCI && !CONFIG_PM

Denis Turischev (1):
  xhci: Switch Intel Lynx Point ports to EHCI on shutdown.

Igor Gnatenko (1):
  xhci: extend quirk for Renesas cards

Julius Werner (1):
  usb: xhci: Prefer endpoint context dequeue pointer over stopped_trb

 drivers/usb/host/xhci-pci.c  |  6 ++--
 drivers/usb/host/xhci-ring.c | 67 
 drivers/usb/host/xhci.c  |  7 ++---
 drivers/usb/host/xhci.h  |  2 --
 4 files changed, 37 insertions(+), 45 deletions(-)

-- 
1.8.3.2

--
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-linus 1/6] usb: qcserial: add Sierra Wireless EM7355

2014-04-25 Thread Bjørn Mork 
>From Lenovo Windows driver.

Cc: 
Signed-off-by: Bjørn Mork 
---
 drivers/usb/serial/qcserial.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index 968a40201e5f..662235240f3f 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -139,6 +139,9 @@ static const struct usb_device_id id_table[] = {
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901c, 0)},   /* Sierra 
Wireless EM7700 Device Management */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901c, 2)},   /* Sierra 
Wireless EM7700 NMEA */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901c, 3)},   /* Sierra 
Wireless EM7700 Modem */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901f, 0)},   /* Sierra 
Wireless EM7355 Device Management */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901f, 2)},   /* Sierra 
Wireless EM7355 NMEA */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901f, 3)},   /* Sierra 
Wireless EM7355 Modem */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9051, 0)},   /* Netgear 
AirCard 340U Device Management */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9051, 2)},   /* Netgear 
AirCard 340U NMEA */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9051, 3)},   /* Netgear 
AirCard 340U Modem */
-- 
2.0.0.rc0

--
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-linus 3/6] usb: qcserial: add Sierra Wireless MC7305/MC7355

2014-04-25 Thread Bjørn Mork 
>From https://bug726613.bugzilla-attachments.gnome.org/attachment.cgi?id=272246

Cc: 
Signed-off-by: Bjørn Mork 
---
 drivers/usb/serial/qcserial.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index 1d1bc9b41337..7ed681a714a5 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -145,6 +145,9 @@ static const struct usb_device_id id_table[] = {
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901f, 0)},   /* Sierra 
Wireless EM7355 Device Management */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901f, 2)},   /* Sierra 
Wireless EM7355 NMEA */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901f, 3)},   /* Sierra 
Wireless EM7355 Modem */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9041, 0)},   /* Sierra 
Wireless MC7305/MC7355 Device Management */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9041, 2)},   /* Sierra 
Wireless MC7305/MC7355 NMEA */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9041, 3)},   /* Sierra 
Wireless MC7305/MC7355 Modem */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9051, 0)},   /* Netgear 
AirCard 340U Device Management */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9051, 2)},   /* Netgear 
AirCard 340U NMEA */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9051, 3)},   /* Netgear 
AirCard 340U Modem */
-- 
2.0.0.rc0

--
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-linus 5/6] usb: option: add Alcatel L800MA

2014-04-25 Thread Bjørn Mork 
Device interface layout:
0: ff/ff/ff - serial
1: ff/00/00 - serial AT+PPP
2: ff/ff/ff - QMI/wwan
3: 08/06/50 - storage

Cc: 
Signed-off-by: Bjørn Mork 
---
 drivers/usb/serial/option.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 6335222cb892..776c86f3c091 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -287,6 +287,7 @@ static void option_instat_callback(struct urb *urb);
 #define ALCATEL_PRODUCT_X060S_X200 0x
 #define ALCATEL_PRODUCT_X220_X500D 0x0017
 #define ALCATEL_PRODUCT_L100V  0x011e
+#define ALCATEL_PRODUCT_L800MA 0x0203
 
 #define PIRELLI_VENDOR_ID  0x1266
 #define PIRELLI_PRODUCT_C100_1 0x1002
@@ -1501,6 +1502,8 @@ static const struct usb_device_id option_ids[] = {
  .driver_info = (kernel_ulong_t)&net_intf5_blacklist },
{ USB_DEVICE(ALCATEL_VENDOR_ID, ALCATEL_PRODUCT_L100V),
  .driver_info = (kernel_ulong_t)&net_intf4_blacklist },
+   { USB_DEVICE(ALCATEL_VENDOR_ID, ALCATEL_PRODUCT_L800MA),
+ .driver_info = (kernel_ulong_t)&net_intf2_blacklist },
{ USB_DEVICE(AIRPLUS_VENDOR_ID, AIRPLUS_PRODUCT_MCD650) },
{ USB_DEVICE(TLAYTECH_VENDOR_ID, TLAYTECH_PRODUCT_TEU800) },
{ USB_DEVICE(LONGCHEER_VENDOR_ID, FOUR_G_SYSTEMS_PRODUCT_W14),
-- 
2.0.0.rc0

--
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-linus 0/6] serial support for a few Qualcomm based devices

2014-04-25 Thread Bjørn Mork 
Adding some new and some old Qualcomm based devices.  All these also
support QMI and a similar series for qmi_wwan will be posted as well.

Bjørn Mork (6):
  usb: qcserial: add Sierra Wireless EM7355
  usb: qcserial: add Sierra Wireless MC73xx
  usb: qcserial: add Sierra Wireless MC7305/MC7355
  usb: option: add Olivetti Olicard 500
  usb: option: add Alcatel L800MA
  usb: option: add and update a number of CMOTech devices

 drivers/usb/serial/option.c   | 81 ---
 drivers/usb/serial/qcserial.c |  9 +
 2 files changed, 86 insertions(+), 4 deletions(-)

-- 
2.0.0.rc0

--
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-linus 2/6] usb: qcserial: add Sierra Wireless MC73xx

2014-04-25 Thread Bjørn Mork 
>From Sierra Wireless' "USB Driver Developer's Guide"

Cc: 
Signed-off-by: Bjørn Mork 
---
 drivers/usb/serial/qcserial.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index 662235240f3f..1d1bc9b41337 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -136,6 +136,9 @@ static const struct usb_device_id id_table[] = {
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x68a2, 0)},   /* Sierra 
Wireless MC7710 Device Management */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x68a2, 2)},   /* Sierra 
Wireless MC7710 NMEA */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x68a2, 3)},   /* Sierra 
Wireless MC7710 Modem */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x68c0, 0)},   /* Sierra 
Wireless MC73xx Device Management */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x68c0, 2)},   /* Sierra 
Wireless MC73xx NMEA */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x68c0, 3)},   /* Sierra 
Wireless MC73xx Modem */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901c, 0)},   /* Sierra 
Wireless EM7700 Device Management */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901c, 2)},   /* Sierra 
Wireless EM7700 NMEA */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901c, 3)},   /* Sierra 
Wireless EM7700 Modem */
-- 
2.0.0.rc0

--
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-linus 4/6] usb: option: add Olivetti Olicard 500

2014-04-25 Thread Bjørn Mork 
Device interface layout:
0: ff/ff/ff - serial
1: ff/ff/ff - serial AT+PPP
2: 08/06/50 - storage
3: ff/ff/ff - serial
4: ff/ff/ff - QMI/wwan

Cc: 
Reported-by: Julio Araujo 
Signed-off-by: Bjørn Mork 
---
 drivers/usb/serial/option.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 367c7f08b27c..6335222cb892 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -349,6 +349,7 @@ static void option_instat_callback(struct urb *urb);
 #define OLIVETTI_PRODUCT_OLICARD1000xc000
 #define OLIVETTI_PRODUCT_OLICARD1450xc003
 #define OLIVETTI_PRODUCT_OLICARD2000xc005
+#define OLIVETTI_PRODUCT_OLICARD5000xc00b
 
 /* Celot products */
 #define CELOT_VENDOR_ID0x211f
@@ -1545,6 +1546,9 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD200),
.driver_info = (kernel_ulong_t)&net_intf6_blacklist
},
+   { USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD500),
+   .driver_info = (kernel_ulong_t)&net_intf4_blacklist
+   },
{ USB_DEVICE(CELOT_VENDOR_ID, CELOT_PRODUCT_CT680M) }, /* CT-650 CDMA 
450 1xEVDO modem */
{ USB_DEVICE_AND_INTERFACE_INFO(SAMSUNG_VENDOR_ID, 
SAMSUNG_PRODUCT_GT_B3730, USB_CLASS_CDC_DATA, 0x00, 0x00) }, /* Samsung 
GT-B3730 LTE USB modem.*/
{ USB_DEVICE(YUGA_VENDOR_ID, YUGA_PRODUCT_CEM600) },
-- 
2.0.0.rc0

--
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-linus 6/6] usb: option: add and update a number of CMOTech devices

2014-04-25 Thread Bjørn Mork 
A number of older CMOTech modems are based on Qualcomm
chips.  The blacklisted interfaces are QMI/wwan.

Reported-by: Lars Melin 
Cc: 
Signed-off-by: Bjørn Mork 
---
 drivers/usb/serial/option.c | 74 ++---
 1 file changed, 70 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 776c86f3c091..f213ee978516 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -234,8 +234,31 @@ static void option_instat_callback(struct urb *urb);
 #define QUALCOMM_VENDOR_ID 0x05C6
 
 #define CMOTECH_VENDOR_ID  0x16d8
-#define CMOTECH_PRODUCT_6008   0x6008
-#define CMOTECH_PRODUCT_6280   0x6280
+#define CMOTECH_PRODUCT_6001   0x6001
+#define CMOTECH_PRODUCT_CMU_3000x6002
+#define CMOTECH_PRODUCT_6003   0x6003
+#define CMOTECH_PRODUCT_6004   0x6004
+#define CMOTECH_PRODUCT_6005   0x6005
+#define CMOTECH_PRODUCT_CGU_628A   0x6006
+#define CMOTECH_PRODUCT_CHE_628S   0x6007
+#define CMOTECH_PRODUCT_CMU_3010x6008
+#define CMOTECH_PRODUCT_CHU_6280x6280
+#define CMOTECH_PRODUCT_CHU_628S   0x6281
+#define CMOTECH_PRODUCT_CDU_6800x6803
+#define CMOTECH_PRODUCT_CDU_685A   0x6804
+#define CMOTECH_PRODUCT_CHU_720S   0x7001
+#define CMOTECH_PRODUCT_7002   0x7002
+#define CMOTECH_PRODUCT_CHU_629K   0x7003
+#define CMOTECH_PRODUCT_7004   0x7004
+#define CMOTECH_PRODUCT_7005   0x7005
+#define CMOTECH_PRODUCT_CGU_6290x7006
+#define CMOTECH_PRODUCT_CHU_629S   0x700a
+#define CMOTECH_PRODUCT_CHU_720I   0x7211
+#define CMOTECH_PRODUCT_7212   0x7212
+#define CMOTECH_PRODUCT_7213   0x7213
+#define CMOTECH_PRODUCT_7251   0x7251
+#define CMOTECH_PRODUCT_7252   0x7252
+#define CMOTECH_PRODUCT_7253   0x7253
 
 #define TELIT_VENDOR_ID0x1bc7
 #define TELIT_PRODUCT_UC864E   0x1003
@@ -504,6 +527,10 @@ static const struct option_blacklist_info 
huawei_cdc12_blacklist = {
.reserved = BIT(1) | BIT(2),
 };
 
+static const struct option_blacklist_info net_intf0_blacklist = {
+   .reserved = BIT(0),
+};
+
 static const struct option_blacklist_info net_intf1_blacklist = {
.reserved = BIT(1),
 };
@@ -1037,8 +1064,47 @@ 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(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6280) }, /* BP3-USB & 
BP3-EXT HSDPA */
-   { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6008) },
+   { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) },
+   { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CMU_300) },
+   { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6003),
+ .driver_info = (kernel_ulong_t)&net_intf0_blacklist },
+   { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6004) },
+   { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6005) },
+   { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CGU_628A) },
+   { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CHE_628S),
+ .driver_info = (kernel_ulong_t)&net_intf0_blacklist },
+   { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CMU_301),
+ .driver_info = (kernel_ulong_t)&net_intf0_blacklist },
+   { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CHU_628),
+ .driver_info = (kernel_ulong_t)&net_intf0_blacklist },
+   { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CHU_628S) },
+   { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CDU_680) },
+   { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CDU_685A) },
+   { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CHU_720S),
+ .driver_info = (kernel_ulong_t)&net_intf0_blacklist },
+   { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_7002),
+ .driver_info = (kernel_ulong_t)&net_intf0_blacklist },
+   { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CHU_629K),
+ .driver_info = (kernel_ulong_t)&net_intf4_blacklist },
+   { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_7004),
+ .driver_info = (kernel_ulong_t)&net_intf3_blacklist },
+   { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_7005) },
+   { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CGU_629),
+ .driver_info = (kernel_ulong_t)&net_intf5_blacklist },
+   { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CHU_629S),
+ .driver_info = (kernel_ulong_t)&net_intf4_blackli

[PATCH net,stable 4/7] net: qmi_wwan: add Olivetti Olicard 500

2014-04-25 Thread Bjørn Mork 
Device interface layout:
0: ff/ff/ff - serial
1: ff/ff/ff - serial AT+PPP
2: 08/06/50 - storage
3: ff/ff/ff - serial
4: ff/ff/ff - QMI/wwan

Reported-by: Julio Araujo 
Signed-off-by: Bjørn Mork 
---
 drivers/net/usb/qmi_wwan.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 336b5375b00b..127b745d2e15 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -743,6 +743,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x1bc7, 0x1200, 5)},/* Telit LE920 */
{QMI_FIXED_INTF(0x1bc7, 0x1201, 2)},/* Telit LE920 */
{QMI_FIXED_INTF(0x0b3c, 0xc005, 6)},/* Olivetti Olicard 200 */
+   {QMI_FIXED_INTF(0x0b3c, 0xc00b, 4)},/* Olivetti Olicard 500 */
{QMI_FIXED_INTF(0x1e2d, 0x0060, 4)},/* Cinterion PLxx */
{QMI_FIXED_INTF(0x1e2d, 0x0053, 4)},/* Cinterion PHxx,PXxx */
 
-- 
2.0.0.rc0

--
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 net,stable 5/7] net: qmi_wwan: add Alcatel L800MA

2014-04-25 Thread Bjørn Mork 
Device interface layout:
0: ff/ff/ff - serial
1: ff/00/00 - serial AT+PPP
2: ff/ff/ff - QMI/wwan
3: 08/06/50 - storage

Signed-off-by: Bjørn Mork 
---
 drivers/net/usb/qmi_wwan.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 127b745d2e15..46937c1b8181 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -738,6 +738,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x1199, 0x9041, 8)},/* Sierra Wireless 
MC7305/MC7355 */
{QMI_FIXED_INTF(0x1199, 0x9051, 8)},/* Netgear AirCard 340U */
{QMI_FIXED_INTF(0x1bbb, 0x011e, 4)},/* Telekom Speedstick LTE II 
(Alcatel One Touch L100V LTE) */
+   {QMI_FIXED_INTF(0x1bbb, 0x0203, 2)},/* Alcatel L800MA */
{QMI_FIXED_INTF(0x2357, 0x0201, 4)},/* TP-LINK HSUPA Modem MA180 */
{QMI_FIXED_INTF(0x2357, 0x9000, 4)},/* TP-LINK MA260 */
{QMI_FIXED_INTF(0x1bc7, 0x1200, 5)},/* Telit LE920 */
-- 
2.0.0.rc0

--
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 net,stable 6/7] net: qmi_wwan: add a number of CMOTech devices

2014-04-25 Thread Bjørn Mork 
A number of older CMOTech modems are based on Qualcomm
chips and exporting a QMI/wwan function.

Reported-by: Lars Melin 
Signed-off-by: Bjørn Mork 
---
 drivers/net/usb/qmi_wwan.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 46937c1b8181..ac1ad189f0c1 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -669,6 +669,22 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x05c6, 0x920d, 5)},
{QMI_FIXED_INTF(0x12d1, 0x140c, 1)},/* Huawei E173 */
{QMI_FIXED_INTF(0x12d1, 0x14ac, 1)},/* Huawei E1820 */
+   {QMI_FIXED_INTF(0x16d8, 0x6003, 0)},/* CMOTech 6003 */
+   {QMI_FIXED_INTF(0x16d8, 0x6007, 0)},/* CMOTech CHE-628S */
+   {QMI_FIXED_INTF(0x16d8, 0x6008, 0)},/* CMOTech CMU-301 */
+   {QMI_FIXED_INTF(0x16d8, 0x6280, 0)},/* CMOTech CHU-628 */
+   {QMI_FIXED_INTF(0x16d8, 0x7001, 0)},/* CMOTech CHU-720S */
+   {QMI_FIXED_INTF(0x16d8, 0x7002, 0)},/* CMOTech 7002 */
+   {QMI_FIXED_INTF(0x16d8, 0x7003, 4)},/* CMOTech CHU-629K */
+   {QMI_FIXED_INTF(0x16d8, 0x7004, 3)},/* CMOTech 7004 */
+   {QMI_FIXED_INTF(0x16d8, 0x7006, 5)},/* CMOTech CGU-629 */
+   {QMI_FIXED_INTF(0x16d8, 0x700a, 4)},/* CMOTech CHU-629S */
+   {QMI_FIXED_INTF(0x16d8, 0x7211, 0)},/* CMOTech CHU-720I */
+   {QMI_FIXED_INTF(0x16d8, 0x7212, 0)},/* CMOTech 7212 */
+   {QMI_FIXED_INTF(0x16d8, 0x7213, 0)},/* CMOTech 7213 */
+   {QMI_FIXED_INTF(0x16d8, 0x7251, 1)},/* CMOTech 7251 */
+   {QMI_FIXED_INTF(0x16d8, 0x7252, 1)},/* CMOTech 7252 */
+   {QMI_FIXED_INTF(0x16d8, 0x7253, 1)},/* CMOTech 7253 */
{QMI_FIXED_INTF(0x19d2, 0x0002, 1)},
{QMI_FIXED_INTF(0x19d2, 0x0012, 1)},
{QMI_FIXED_INTF(0x19d2, 0x0017, 3)},
-- 
2.0.0.rc0

--
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 net,stable 3/7] net: qmi_wwan: add Sierra Wireless MC7305/MC7355

2014-04-25 Thread Bjørn Mork 
>From https://bug726613.bugzilla-attachments.gnome.org/attachment.cgi?id=272246

Signed-off-by: Bjørn Mork 
---
 drivers/net/usb/qmi_wwan.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 60a95ab243d6..336b5375b00b 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -735,6 +735,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x1199, 0x68c0, 11)},   /* Sierra Wireless MC73xx */
{QMI_FIXED_INTF(0x1199, 0x901c, 8)},/* Sierra Wireless EM7700 */
{QMI_FIXED_INTF(0x1199, 0x901f, 8)},/* Sierra Wireless EM7355 */
+   {QMI_FIXED_INTF(0x1199, 0x9041, 8)},/* Sierra Wireless 
MC7305/MC7355 */
{QMI_FIXED_INTF(0x1199, 0x9051, 8)},/* Netgear AirCard 340U */
{QMI_FIXED_INTF(0x1bbb, 0x011e, 4)},/* Telekom Speedstick LTE II 
(Alcatel One Touch L100V LTE) */
{QMI_FIXED_INTF(0x2357, 0x0201, 4)},/* TP-LINK HSUPA Modem MA180 */
-- 
2.0.0.rc0

--
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 net,stable 2/7] net: qmi_wwan: add Sierra Wireless MC73xx

2014-04-25 Thread Bjørn Mork 
>From Sierra Wireless' "USB Driver Developer's Guide"

Signed-off-by: Bjørn Mork 
---
 drivers/net/usb/qmi_wwan.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index f4c9290aa117..60a95ab243d6 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -730,6 +730,9 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x114f, 0x68a2, 8)},/* Sierra Wireless MC7750 */
{QMI_FIXED_INTF(0x1199, 0x68a2, 8)},/* Sierra Wireless MC7710 in 
QMI mode */
{QMI_FIXED_INTF(0x1199, 0x68a2, 19)},   /* Sierra Wireless MC7710 in 
QMI mode */
+   {QMI_FIXED_INTF(0x1199, 0x68c0, 8)},/* Sierra Wireless MC73xx */
+   {QMI_FIXED_INTF(0x1199, 0x68c0, 10)},   /* Sierra Wireless MC73xx */
+   {QMI_FIXED_INTF(0x1199, 0x68c0, 11)},   /* Sierra Wireless MC73xx */
{QMI_FIXED_INTF(0x1199, 0x901c, 8)},/* Sierra Wireless EM7700 */
{QMI_FIXED_INTF(0x1199, 0x901f, 8)},/* Sierra Wireless EM7355 */
{QMI_FIXED_INTF(0x1199, 0x9051, 8)},/* Netgear AirCard 340U */
-- 
2.0.0.rc0

--
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 net,stable 1/7] net: qmi_wwan: add Sierra Wireless EM7355

2014-04-25 Thread Bjørn Mork 
>From Lenovo Windows driver.

Signed-off-by: Bjørn Mork 
---
 drivers/net/usb/qmi_wwan.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index e3458e3c44f1..f4c9290aa117 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -731,6 +731,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x1199, 0x68a2, 8)},/* Sierra Wireless MC7710 in 
QMI mode */
{QMI_FIXED_INTF(0x1199, 0x68a2, 19)},   /* Sierra Wireless MC7710 in 
QMI mode */
{QMI_FIXED_INTF(0x1199, 0x901c, 8)},/* Sierra Wireless EM7700 */
+   {QMI_FIXED_INTF(0x1199, 0x901f, 8)},/* Sierra Wireless EM7355 */
{QMI_FIXED_INTF(0x1199, 0x9051, 8)},/* Netgear AirCard 340U */
{QMI_FIXED_INTF(0x1bbb, 0x011e, 4)},/* Telekom Speedstick LTE II 
(Alcatel One Touch L100V LTE) */
{QMI_FIXED_INTF(0x2357, 0x0201, 4)},/* TP-LINK HSUPA Modem MA180 */
-- 
2.0.0.rc0

--
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 net,stable 0/7] qmi_wwan: adding a few new devices

2014-04-25 Thread Bjørn Mork 
Adding some new and some old QMI devices.  A similar series for
usb-serial support will be posted as well.

These new device ID patches should also go to all maintained stable kernels
where they apply. I believe that should be stable-3.10 and newer.


Bjørn Mork (7):
  net: qmi_wwan: add Sierra Wireless EM7355
  net: qmi_wwan: add Sierra Wireless MC73xx
  net: qmi_wwan: add Sierra Wireless MC7305/MC7355
  net: qmi_wwan: add Olivetti Olicard 500
  net: qmi_wwan: add Alcatel L800MA
  net: qmi_wwan: add a number of CMOTech devices
  net: qmi_wwan: add a number of Dell devices

 drivers/net/usb/qmi_wwan.c | 28 
 1 file changed, 28 insertions(+)

-- 
2.0.0.rc0

--
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 net,stable 7/7] net: qmi_wwan: add a number of Dell devices

2014-04-25 Thread Bjørn Mork 
Dan writes:

"The Dell drivers use the same configuration for PIDs:

81A2: Dell Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card
81A3: Dell Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card
81A4: Dell Wireless 5570e HSPA+ (42Mbps) Mobile Broadband Card
81A8: Dell Wireless 5808 Gobi(TM) 4G LTE Mobile Broadband Card
81A9: Dell Wireless 5808e Gobi(TM) 4G LTE Mobile Broadband Card

These devices are all clearly Sierra devices, but are also definitely
Gobi-based.  The A8 might be the MC7700/7710 and A9 is likely a MC7750.

>From DellGobi5kSetup.exe from the Dell drivers:

usbif0: serial/firmware loader?
usbif2: nmea
usbif3: modem/ppp
usbif8: net/QMI"

Reported-by: AceLan Kao 
Reported-by: Dan Williams 
Signed-off-by: Bjørn Mork 
---
 drivers/net/usb/qmi_wwan.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index ac1ad189f0c1..83208d4fdc59 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -763,6 +763,11 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x0b3c, 0xc00b, 4)},/* Olivetti Olicard 500 */
{QMI_FIXED_INTF(0x1e2d, 0x0060, 4)},/* Cinterion PLxx */
{QMI_FIXED_INTF(0x1e2d, 0x0053, 4)},/* Cinterion PHxx,PXxx */
+   {QMI_FIXED_INTF(0x413c, 0x81a2, 8)},/* Dell Wireless 5806 Gobi(TM) 
4G LTE Mobile Broadband Card */
+   {QMI_FIXED_INTF(0x413c, 0x81a3, 8)},/* Dell Wireless 5570 HSPA+ 
(42Mbps) Mobile Broadband Card */
+   {QMI_FIXED_INTF(0x413c, 0x81a4, 8)},/* Dell Wireless 5570e HSPA+ 
(42Mbps) Mobile Broadband Card */
+   {QMI_FIXED_INTF(0x413c, 0x81a8, 8)},/* Dell Wireless 5808 Gobi(TM) 
4G LTE Mobile Broadband Card */
+   {QMI_FIXED_INTF(0x413c, 0x81a9, 8)},/* Dell Wireless 5808e Gobi(TM) 
4G LTE Mobile Broadband Card */
 
/* 4. Gobi 1000 devices */
{QMI_GOBI1K_DEVICE(0x05c6, 0x9212)},/* Acer Gobi Modem Device */
-- 
2.0.0.rc0

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

2014-04-25 Thread Sarah Sharp 
On Fri, Apr 25, 2014 at 09:35:05AM -0700, Greg KH wrote:
> On Fri, Apr 25, 2014 at 07:20:12PM +0300, Mathias Nyman wrote:
> > Hi Greg 
> >
> > 
> >
> > Second try at this xhci fixes series for 3.15-rc usb-linus. 
> > 
> > Most of them are very small fixes that didn't make  
> >
> > it to 3.14, sitting and waiting for 3.15-rc1 to come out.   
> >
> > 
> >
> > Only the "Prefer endpoint context.." patch  by Julius has a bit more 
> > content.  
> > 
> >
> > These patches are picked together with Sarah, they are tested on top of 
> >
> > 3.15-rc1, and apply on your current usb-linus branch
> >
> 
> Much better, all now applied.
> 
> What's with all that trailing whitespace in your email text?

I use the following lines in my .vimrc to highlight trailing whitespace:

hi link localWhitespaceError Error
au Syntax * syn match localWhitespaceError /\(\zs\%#\|\s\)\+$/ display
au Syntax * syn match localWhitespaceError / \+\ze\t/ display

I also have a macro to add stable tags and which commit IDs introduced
the issue the bug fixes:

iab backporthis
\Fixes: commitID ("commitDescription")
\Cc: sta...@vger.kernel.org # kernelVersion

Then when I'm amending someone's commit to add my Signed-off-by line, I
type backporthis, and vim expands it to the longer version.  (I've
deliberately misspelled it here, so it doesn't get expanded.) Sometimes
it takes a couple of round of `git blame` to figure out when the bug was
introduced.

Sarah Sharp
--
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 04/18] xhci-platform: Add a new controller using xhci: Armada 38x

2014-04-25 Thread Sergei Shtylyov 

Hello.

On 04/25/2014 06:07 PM, Gregory CLEMENT wrote:


Extend the compatible string list with armada-380-xhci. It is used to
describe xhci controller which is in the Armada 38x SoCs.



Signed-off-by: Gregory CLEMENT 
---
  Documentation/devicetree/bindings/usb/usb-xhci.txt | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)



diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt 
b/Documentation/devicetree/bindings/usb/usb-xhci.txt
index 90f8f607d125..cbc91414fd59 100644
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -1,7 +1,8 @@
  USB xHCI controllers

  Required properties:
-  - compatible: should be "generic-xhci" (deprecated: "xhci-platform").
+  - compatible: should be on of "generic-xhci",


   s/on/one/


+"marvell,armada-380-xhci" (deprecated: "xhci-platform").


   What's the difference of "marvell,armada-380-xhci" to "generic-xhci"?

WBR, 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: [PATCH 3/4] dwc3: host: Set xhci lpm support quirk

2014-04-25 Thread Felipe Balbi 
On Fri, Apr 25, 2014 at 02:27:11PM +0530, Pratyush Anand wrote:
> On Tue, Apr 22, 2014 at 10:41:06PM +0800, Felipe Balbi wrote:
> > On Tue, Apr 22, 2014 at 10:46:13AM +0530, Pratyush Anand wrote:
> > > On Tue, Apr 22, 2014 at 12:43:55PM +0800, Felipe Balbi wrote:
> > > > On Tue, Apr 22, 2014 at 09:57:29AM +0530, Pratyush Anand wrote:
> > > > > All dwc3 based xhci host controller supports USB3.0 LPM functionality.
> > > > > Therefore enable quirk flag to support it for dwc3 xhci host driver.
> > > > > 
> > > > > Signed-off-by: Pratyush Anand 
> > > > > Tested-by: Aymen Bouattay 
> > > > > ---
> > > > >  drivers/usb/dwc3/host.c | 1 +
> > > > >  1 file changed, 1 insertion(+)
> > > > > 
> > > > > diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
> > > > > index a362ed9..b0e4669 100644
> > > > > --- a/drivers/usb/dwc3/host.c
> > > > > +++ b/drivers/usb/dwc3/host.c
> > > > > @@ -86,6 +86,7 @@ int dwc3_host_init(struct dwc3 *dwc)
> > > > >   hcd = platform_get_drvdata(xhci);
> > > > >   xhci_dev = hcd_to_xhci(hcd);
> > > > >   xhci_dev->shared_hcd->phy = dwc->usb3_phy;
> > > > > + xhci_dev->quirks |= XHCI_LPM_SUPPORT;
> > > > 
> > > > weird... what sort of changes do you have which you didn't send yet ?
> > > > dwc3/host.c does not create the xHCI device. dwc3_host_init() is
> > > > basically a wrapper to platform_add_device()
> > > 
> > > There is nothing, and it works.
> > > 
> > > Adding platform xhci driver in defconfig and selecting dwc3 in DT is 
> > > sufficient.
> > > Did I get, what you were asking?
> > 
> > this little hunk below will never apply to dwc3/host.c:
> > 
> > diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
> > index a362ed9..b0e4669 100644
> > --- a/drivers/usb/dwc3/host.c
> > +++ b/drivers/usb/dwc3/host.c
> > @@ -86,6 +86,7 @@ int dwc3_host_init(struct dwc3 *dwc)
> > hcd = platform_get_drvdata(xhci);
> > xhci_dev = hcd_to_xhci(hcd);
> > xhci_dev->shared_hcd->phy = dwc->usb3_phy;
> > +   xhci_dev->quirks |= XHCI_LPM_SUPPORT;
> > 
> > 
> > here are dwc3/host.c contents as of v3.15-rc2 (removed comments)
> > 
> > #include 
> > 
> > #include "core.h"
> > 
> > int dwc3_host_init(struct dwc3 *dwc)
> > {
> > struct platform_device  *xhci;
> > int ret;
> > 
> > xhci = platform_device_alloc("xhci-hcd", PLATFORM_DEVID_AUTO);
> > if (!xhci) {
> > dev_err(dwc->dev, "couldn't allocate xHCI device\n");
> > ret = -ENOMEM;
> > goto err0;
> > }
> > 
> > dma_set_coherent_mask(&xhci->dev, dwc->dev->coherent_dma_mask);
> > 
> > xhci->dev.parent= dwc->dev;
> > xhci->dev.dma_mask  = dwc->dev->dma_mask;
> > xhci->dev.dma_parms = dwc->dev->dma_parms;
> > 
> > dwc->xhci = xhci;
> > 
> > ret = platform_device_add_resources(xhci, dwc->xhci_resources,
> > DWC3_XHCI_RESOURCES_NUM);
> > if (ret) {
> > dev_err(dwc->dev, "couldn't add resources to xHCI device\n");
> > goto err1;
> > }
> > 
> > ret = platform_device_add(xhci);
> > if (ret) {
> > dev_err(dwc->dev, "failed to register xHCI device\n");
> > goto err1;
> > }
> > 
> > return 0;
> > 
> > err1:
> > platform_device_put(xhci);
> > 
> > err0:
> > return ret;
> > }
> > 
> > void dwc3_host_exit(struct dwc3 *dwc)
> > {
> > platform_device_unregister(dwc->xhci);
> > }
> > 
> > as you can see, there is no such thing as xhci_dev variable.
> 
> OKI see..
> I will rebase it with latest code.

please do and show me test results. considering that hunk was *never*
part of dwc3-host I'm assuming you're taking patches from internal
vendor kernel and not even testing anything in mainline. I need to see
some test results before I can take your patches. Sorry

cheers

-- 
balbi


signature.asc
Description: Digital signature

[PATCH usb-linus 4/4] usb: qcserial: add a number of Dell devices

2014-04-25 Thread Bjørn Mork 
Dan writes:

"The Dell drivers use the same configuration for PIDs:

81A2: Dell Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card
81A3: Dell Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card
81A4: Dell Wireless 5570e HSPA+ (42Mbps) Mobile Broadband Card
81A8: Dell Wireless 5808 Gobi(TM) 4G LTE Mobile Broadband Card
81A9: Dell Wireless 5808e Gobi(TM) 4G LTE Mobile Broadband Card

These devices are all clearly Sierra devices, but are also definitely
Gobi-based.  The A8 might be the MC7700/7710 and A9 is likely a MC7750.

>From DellGobi5kSetup.exe from the Dell drivers:

usbif0: serial/firmware loader?
usbif2: nmea
usbif3: modem/ppp
usbif8: net/QMI"

So these devices all use the standard Sierra Wireless layout
supported by this driver.

Reported-by: AceLan Kao 
Reported-by: Dan Williams 
Signed-off-by: Bjørn Mork 
---
 drivers/usb/serial/qcserial.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index 7fbaf4c4f20e..3dfc5c799b01 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -141,6 +141,11 @@ static const struct usb_device_id id_table[] = {
{DEVICE_SWI(0x1199, 0x68a2)},   /* Sierra Wireless MC7710 */
{DEVICE_SWI(0x1199, 0x901c)},   /* Sierra Wireless EM7700 */
{DEVICE_SWI(0x1199, 0x9051)},   /* Netgear AirCard 340U */
+   {DEVICE_SWI(0x413c, 0x81a2)},   /* Dell Wireless 5806 Gobi(TM) 4G LTE 
Mobile Broadband Card */
+   {DEVICE_SWI(0x413c, 0x81a3)},   /* Dell Wireless 5570 HSPA+ (42Mbps) 
Mobile Broadband Card */
+   {DEVICE_SWI(0x413c, 0x81a4)},   /* Dell Wireless 5570e HSPA+ (42Mbps) 
Mobile Broadband Card */
+   {DEVICE_SWI(0x413c, 0x81a8)},   /* Dell Wireless 5808 Gobi(TM) 4G LTE 
Mobile Broadband Card */
+   {DEVICE_SWI(0x413c, 0x81a9)},   /* Dell Wireless 5808e Gobi(TM) 4G LTE 
Mobile Broadband Card */
 
{ } /* Terminating entry */
 };
-- 
2.0.0.rc0

--
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-linus 3/4] usb: qcserial: remove interface number matching

2014-04-25 Thread Bjørn Mork 
Matching on interface numbers was not such a good idea
for multi-function serial devices after all. It is much
better do create well defined device layouts, allowing
a single match entry per device.

Remove this now unused code.

Signed-off-by: Bjørn Mork 
---
 drivers/usb/serial/qcserial.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index 5c138445c352..7fbaf4c4f20e 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -182,13 +182,6 @@ static int qcprobe(struct usb_serial *serial, const struct 
usb_device_id *id)
 
}
 
-   /* allow any number of interfaces when doing direct interface match */
-   if (id->match_flags & USB_DEVICE_ID_MATCH_INT_NUMBER) {
-   dev_dbg(dev, "Generic Qualcomm serial interface found\n");
-   altsetting = 0;
-   goto done;
-   }
-
/* default to enabling interface */
altsetting = 0;
 
-- 
2.0.0.rc0

--
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-linus 0/4] qcserial: refactoring support for Sierra Wireless devices

2014-04-25 Thread Bjørn Mork 
I just have to admit that using the per-interface number matching
here wasn't such a good idea after all. It just does not scale
well when adding new devices, and I think we should break now
before we have added even more redundant match entries.

This series refactors the device layout selecting code to simplify
adding more layouts, and then define a Sierra Wireless specific 
layout.  This layout is applied to the existing entries, and to
a number of yet unsupported Sierra made Dell devices.

The old support for single interface number matching is no longer
necessary after this, and is therefore removed.

Comments are appreciated.  I realize that this will complicate
stuff a bit for stable backports while both schemes are in use,
but I do believe it represents a necessary simplification in the
long run.


Bjørn Mork (4):
  usb: qcserial: refactor device layout selection
  usb: qcserial: define and use Sierra Wireless layout
  usb: qcserial: remove interface number matching
  usb: qcserial: add a number of Dell devices

 drivers/usb/serial/qcserial.c | 99 ---
 1 file changed, 65 insertions(+), 34 deletions(-)

-- 
2.0.0.rc0

--
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-linus 2/4] usb: qcserial: define and use Sierra Wireless layout

2014-04-25 Thread Bjørn Mork 
All the "non Gobi" Qualcomm based devices handled by this
driver share a common standard Sierra Wireless specific
layout. Adding code specifically for this layout allow
us to reduce the number of match entries per device from
three to one.

This change will result in a penalty wrt stable backports,
but simplifies new Sierra device addtitions in the long
term.

Signed-off-by: Bjørn Mork 
---
 drivers/usb/serial/qcserial.c | 65 +--
 1 file changed, 44 insertions(+), 21 deletions(-)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index ebe3c999e5c3..5c138445c352 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -26,10 +26,13 @@
 enum qcserial_layouts {
QCSERIAL_G2K = 0,   /* Gobi 2000 */
QCSERIAL_G1K = 1,   /* Gobi 1000 */
+   QCSERIAL_SWI = 2,   /* Sierra Wireless */
 };
 
 #define DEVICE_G1K(v, p) \
USB_DEVICE(v, p), .driver_info = QCSERIAL_G1K
+#define DEVICE_SWI(v, p) \
+   USB_DEVICE(v, p), .driver_info = QCSERIAL_SWI
 
 static const struct usb_device_id id_table[] = {
/* Gobi 1000 devices */
@@ -132,22 +135,12 @@ static const struct usb_device_id id_table[] = {
{USB_DEVICE(0x12D1, 0x14F1)},   /* Sony Gobi 3000 Composite */
{USB_DEVICE(0x0AF0, 0x8120)},   /* Option GTM681W */
 
-   /* non Gobi Qualcomm serial devices */
-   {USB_DEVICE_INTERFACE_NUMBER(0x0f3d, 0x68a2, 0)},   /* Sierra 
Wireless MC7700 Device Management */
-   {USB_DEVICE_INTERFACE_NUMBER(0x0f3d, 0x68a2, 2)},   /* Sierra 
Wireless MC7700 NMEA */
-   {USB_DEVICE_INTERFACE_NUMBER(0x0f3d, 0x68a2, 3)},   /* Sierra 
Wireless MC7700 Modem */
-   {USB_DEVICE_INTERFACE_NUMBER(0x114f, 0x68a2, 0)},   /* Sierra 
Wireless MC7750 Device Management */
-   {USB_DEVICE_INTERFACE_NUMBER(0x114f, 0x68a2, 2)},   /* Sierra 
Wireless MC7750 NMEA */
-   {USB_DEVICE_INTERFACE_NUMBER(0x114f, 0x68a2, 3)},   /* Sierra 
Wireless MC7750 Modem */
-   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x68a2, 0)},   /* Sierra 
Wireless MC7710 Device Management */
-   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x68a2, 2)},   /* Sierra 
Wireless MC7710 NMEA */
-   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x68a2, 3)},   /* Sierra 
Wireless MC7710 Modem */
-   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901c, 0)},   /* Sierra 
Wireless EM7700 Device Management */
-   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901c, 2)},   /* Sierra 
Wireless EM7700 NMEA */
-   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901c, 3)},   /* Sierra 
Wireless EM7700 Modem */
-   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9051, 0)},   /* Netgear 
AirCard 340U Device Management */
-   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9051, 2)},   /* Netgear 
AirCard 340U NMEA */
-   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9051, 3)},   /* Netgear 
AirCard 340U Modem */
+   /* non-Gobi Sierra Wireless devices */
+   {DEVICE_SWI(0x0f3d, 0x68a2)},   /* Sierra Wireless MC7700 */
+   {DEVICE_SWI(0x114f, 0x68a2)},   /* Sierra Wireless MC7750 */
+   {DEVICE_SWI(0x1199, 0x68a2)},   /* Sierra Wireless MC7710 */
+   {DEVICE_SWI(0x1199, 0x901c)},   /* Sierra Wireless EM7700 */
+   {DEVICE_SWI(0x1199, 0x9051)},   /* Netgear AirCard 340U */
 
{ } /* Terminating entry */
 };
@@ -196,11 +189,6 @@ static int qcprobe(struct usb_serial *serial, const struct 
usb_device_id *id)
goto done;
}
 
-   if (nintf < 3 || nintf > 4) {
-   dev_err(dev, "unknown number of interfaces: %d\n", nintf);
-   goto done;
-   }
-
/* default to enabling interface */
altsetting = 0;
 
@@ -216,6 +204,12 @@ static int qcprobe(struct usb_serial *serial, const struct 
usb_device_id *id)
 * 2: AT-capable modem port
 * 3: QMI/net
 */
+   if (nintf < 3 || nintf > 4) {
+   dev_err(dev, "unknown number of interfaces: %d\n", 
nintf);
+   altsetting = -1;
+   goto done;
+   }
+
if (ifnum == 0) {
dev_dbg(dev, "Gobi 1K DM/DIAG interface found\n");
altsetting = 1;
@@ -231,6 +225,12 @@ static int qcprobe(struct usb_serial *serial, const struct 
usb_device_id *id)
 * 2: AT-capable modem port
 * 3: NMEA
 */
+   if (nintf < 3 || nintf > 4) {
+   dev_err(dev, "unknown number of interfaces: %d\n", 
nintf);
+   altsetting = -1;
+   goto done;
+   }
+
switch (ifnum) {
case 0:
/* Don't claim the QMI/net interface */
@@ -252,6 +252,29 @@ static int qcprobe(struct usb_serial *serial, const struct 
usb_device_id *id)

[PATCH usb-linus 1/4] usb: qcserial: refactor device layout selection

2014-04-25 Thread Bjørn Mork 
Preparing for more supported standard device layouts. Keeping
the matching macros unchanged to avoid breaking stable
backporting of new device additions.

Signed-off-by: Bjørn Mork 
---
 drivers/usb/serial/qcserial.c | 22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index 968a40201e5f..ebe3c999e5c3 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -22,8 +22,14 @@
 #define DRIVER_AUTHOR "Qualcomm Inc"
 #define DRIVER_DESC "Qualcomm USB Serial driver"
 
+/* standard device layouts supported by this driver */
+enum qcserial_layouts {
+   QCSERIAL_G2K = 0,   /* Gobi 2000 */
+   QCSERIAL_G1K = 1,   /* Gobi 1000 */
+};
+
 #define DEVICE_G1K(v, p) \
-   USB_DEVICE(v, p), .driver_info = 1
+   USB_DEVICE(v, p), .driver_info = QCSERIAL_G1K
 
 static const struct usb_device_id id_table[] = {
/* Gobi 1000 devices */
@@ -154,11 +160,8 @@ static int qcprobe(struct usb_serial *serial, const struct 
usb_device_id *id)
int retval = -ENODEV;
__u8 nintf;
__u8 ifnum;
-   bool is_gobi1k = id->driver_info ? true : false;
int altsetting = -1;
 
-   dev_dbg(dev, "Is Gobi 1000 = %d\n", is_gobi1k);
-
nintf = serial->dev->actconfig->desc.bNumInterfaces;
dev_dbg(dev, "Num Interfaces = %d\n", nintf);
ifnum = intf->desc.bInterfaceNumber;
@@ -205,7 +208,8 @@ static int qcprobe(struct usb_serial *serial, const struct 
usb_device_id *id)
 * gets handled by other drivers.
 */
 
-   if (is_gobi1k) {
+   switch (id->driver_info) {
+   case QCSERIAL_G1K:
/* Gobi 1K USB layout:
 * 0: DM/DIAG (use libqcdm from ModemManager for communication)
 * 1: serial port (doesn't respond)
@@ -219,7 +223,8 @@ static int qcprobe(struct usb_serial *serial, const struct 
usb_device_id *id)
dev_dbg(dev, "Modem port found\n");
else
altsetting = -1;
-   } else {
+   break;
+   case QCSERIAL_G2K:
/* Gobi 2K+ USB layout:
 * 0: QMI/net
 * 1: DM/DIAG (use libqcdm from ModemManager for communication)
@@ -246,6 +251,11 @@ static int qcprobe(struct usb_serial *serial, const struct 
usb_device_id *id)
dev_dbg(dev, "Gobi 2K+ NMEA GPS interface found\n");
break;
}
+   break;
+   default:
+   dev_err(dev, "unsupported device layout type: %lu\n",
+   id->driver_info);
+   break;
}
 
 done:
-- 
2.0.0.rc0

--
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/3] usb: dwc3: gadget: pretty print link states

2014-04-25 Thread Felipe Balbi 
this makes it slightly easier to read link state
change interrupt logs.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/gadget.c | 44 +---
 1 file changed, 41 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index f5adf3f..2406a82 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -302,6 +302,42 @@ static const char *dwc3_gadget_ep_cmd_string(u8 cmd)
}
 }
 
+static const char *dwc3_gadget_link_string(enum dwc3_link_state link_state)
+{
+   switch (link_state) {
+   case DWC3_LINK_STATE_U0:
+   return "U0";
+   case DWC3_LINK_STATE_U1:
+   return "U1";
+   case DWC3_LINK_STATE_U2:
+   return "U2";
+   case DWC3_LINK_STATE_U3:
+   return "U3";
+   case DWC3_LINK_STATE_SS_DIS:
+   return "SS.Disabled";
+   case DWC3_LINK_STATE_RX_DET:
+   return "RX.Detect";
+   case DWC3_LINK_STATE_SS_INACT:
+   return "SS.Inactive";
+   case DWC3_LINK_STATE_POLL:
+   return "Polling";
+   case DWC3_LINK_STATE_RECOV:
+   return "Recovery";
+   case DWC3_LINK_STATE_HRESET:
+   return "Hot Reset";
+   case DWC3_LINK_STATE_CMPLY:
+   return "Compliance";
+   case DWC3_LINK_STATE_LPBK:
+   return "Loopback";
+   case DWC3_LINK_STATE_RESET:
+   return "Reset";
+   case DWC3_LINK_STATE_RESUME:
+   return "Resume";
+   default:
+   return "UNKNOWN link state\n";
+   }
+}
+
 int dwc3_send_gadget_generic_command(struct dwc3 *dwc, int cmd, u32 param)
 {
u32 timeout = 500;
@@ -2449,8 +2485,6 @@ static void dwc3_gadget_linksts_change_interrupt(struct 
dwc3 *dwc,
}
}
 
-   dwc->link_state = next;
-
switch (next) {
case DWC3_LINK_STATE_U1:
if (dwc->speed == USB_SPEED_SUPER)
@@ -2468,7 +2502,11 @@ static void dwc3_gadget_linksts_change_interrupt(struct 
dwc3 *dwc,
break;
}
 
-   dev_vdbg(dwc->dev, "%s link %d\n", __func__, dwc->link_state);
+   dev_vdbg(dwc->dev, "link change: %s [%d] -> %s [%d]\n", __func__,
+   dwc3_gadget_link_string(dwc->link_state),
+   dwc->link_state, dwc3_gadget_link_string(next), next);
+
+   dwc->link_state = next;
 }
 
 static void dwc3_gadget_hibernation_interrupt(struct dwc3 *dwc,
-- 
1.9.2.459.g68773ac

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

Re: [PATCH 2/3] usb: dwc3: gadget: pretty print link states

2014-04-25 Thread Felipe Balbi 
On Fri, Apr 25, 2014 at 02:15:29PM -0500, Felipe Balbi wrote:
> this makes it slightly easier to read link state
> change interrupt logs.
> 
> Signed-off-by: Felipe Balbi 
> ---
>  drivers/usb/dwc3/gadget.c | 44 +---
>  1 file changed, 41 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index f5adf3f..2406a82 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -302,6 +302,42 @@ static const char *dwc3_gadget_ep_cmd_string(u8 cmd)
>   }
>  }
>  
> +static const char *dwc3_gadget_link_string(enum dwc3_link_state link_state)
> +{
> + switch (link_state) {
> + case DWC3_LINK_STATE_U0:
> + return "U0";
> + case DWC3_LINK_STATE_U1:
> + return "U1";
> + case DWC3_LINK_STATE_U2:
> + return "U2";
> + case DWC3_LINK_STATE_U3:
> + return "U3";
> + case DWC3_LINK_STATE_SS_DIS:
> + return "SS.Disabled";
> + case DWC3_LINK_STATE_RX_DET:
> + return "RX.Detect";
> + case DWC3_LINK_STATE_SS_INACT:
> + return "SS.Inactive";
> + case DWC3_LINK_STATE_POLL:
> + return "Polling";
> + case DWC3_LINK_STATE_RECOV:
> + return "Recovery";
> + case DWC3_LINK_STATE_HRESET:
> + return "Hot Reset";
> + case DWC3_LINK_STATE_CMPLY:
> + return "Compliance";
> + case DWC3_LINK_STATE_LPBK:
> + return "Loopback";
> + case DWC3_LINK_STATE_RESET:
> + return "Reset";
> + case DWC3_LINK_STATE_RESUME:
> + return "Resume";
> + default:
> + return "UNKNOWN link state\n";
> + }
> +}
> +
>  int dwc3_send_gadget_generic_command(struct dwc3 *dwc, int cmd, u32 param)
>  {
>   u32 timeout = 500;
> @@ -2449,8 +2485,6 @@ static void dwc3_gadget_linksts_change_interrupt(struct 
> dwc3 *dwc,
>   }
>   }
>  
> - dwc->link_state = next;
> -
>   switch (next) {
>   case DWC3_LINK_STATE_U1:
>   if (dwc->speed == USB_SPEED_SUPER)
> @@ -2468,7 +2502,11 @@ static void 
> dwc3_gadget_linksts_change_interrupt(struct dwc3 *dwc,
>   break;
>   }
>  
> - dev_vdbg(dwc->dev, "%s link %d\n", __func__, dwc->link_state);
> + dev_vdbg(dwc->dev, "link change: %s [%d] -> %s [%d]\n", __func__,

don't you hate when you think you've committed something but in reality
you didn't ? gr

8<

From e57ebc1db6ef796124b69abca044a373b9110a47 Mon Sep 17 00:00:00 2001
From: Felipe Balbi 
Date: Tue, 22 Apr 2014 13:20:12 -0500
Subject: [PATCH] usb: dwc3: gadget: pretty print link states

this makes it slightly easier to read link state
change interrupt logs.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/gadget.c | 44 +---
 1 file changed, 41 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index f5adf3f..9a8ae39 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -302,6 +302,42 @@ static const char *dwc3_gadget_ep_cmd_string(u8 cmd)
}
 }
 
+static const char *dwc3_gadget_link_string(enum dwc3_link_state link_state)
+{
+   switch (link_state) {
+   case DWC3_LINK_STATE_U0:
+   return "U0";
+   case DWC3_LINK_STATE_U1:
+   return "U1";
+   case DWC3_LINK_STATE_U2:
+   return "U2";
+   case DWC3_LINK_STATE_U3:
+   return "U3";
+   case DWC3_LINK_STATE_SS_DIS:
+   return "SS.Disabled";
+   case DWC3_LINK_STATE_RX_DET:
+   return "RX.Detect";
+   case DWC3_LINK_STATE_SS_INACT:
+   return "SS.Inactive";
+   case DWC3_LINK_STATE_POLL:
+   return "Polling";
+   case DWC3_LINK_STATE_RECOV:
+   return "Recovery";
+   case DWC3_LINK_STATE_HRESET:
+   return "Hot Reset";
+   case DWC3_LINK_STATE_CMPLY:
+   return "Compliance";
+   case DWC3_LINK_STATE_LPBK:
+   return "Loopback";
+   case DWC3_LINK_STATE_RESET:
+   return "Reset";
+   case DWC3_LINK_STATE_RESUME:
+   return "Resume";
+   default:
+   return "UNKNOWN link state\n";
+   }
+}
+
 int dwc3_send_gadget_generic_command(struct dwc3 *dwc, int cmd, u32 param)
 {
u32 timeout = 500;
@@ -2449,8 +2485,6 @@ static void dwc3_gadget_linksts_change_interrupt(struct 
dwc3 *dwc,
}
}
 
-   dwc->link_state = next;
-
switch (next) {
case DWC3_LINK_STATE_U1:
if (dwc->speed == USB_SPEED_SUPER)
@@ -2468,7 +2502,11 @@ static void dwc3_gadget_linksts_change_interrupt(struct 
dwc3 *dwc,
break;
}
 
-   dev_vdbg(dwc->dev, "%s link %d\n", __func__, dwc->link_state);
+

Re: [PATCH usb-linus 0/4] qcserial: refactoring support for Sierra Wireless devices

2014-04-25 Thread Bjørn Mork 
Ouch... This didn't apply on top of the other series I just sent.  Sorry
about that. New version coming up in a second.


Bjørn (writing too much too fast with only one usable arm - yes, I have
my excuses :-)
--
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/3] usb: dwc3: gadget: print both cmd string and number

2014-04-25 Thread Felipe Balbi 
That way it's easy for humans looking at dmesg
and humans(?) looking at Databooks.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/gadget.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index f0dc0ee..f5adf3f 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -336,9 +336,9 @@ int dwc3_send_gadget_ep_cmd(struct dwc3 *dwc, unsigned ep,
u32 timeout = 500;
u32 reg;
 
-   dev_vdbg(dwc->dev, "%s: cmd '%s' params %08x %08x %08x\n",
+   dev_vdbg(dwc->dev, "%s: cmd '%s' [%d] params %08x %08x %08x\n",
dep->name,
-   dwc3_gadget_ep_cmd_string(cmd), params->param0,
+   dwc3_gadget_ep_cmd_string(cmd), cmd, params->param0,
params->param1, params->param2);
 
dwc3_writel(dwc->regs, DWC3_DEPCMDPAR0(ep), params->param0);
-- 
1.9.2.459.g68773ac

--
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/3] usb: dwc3: gadget: pretty print Generic CMDs

2014-04-25 Thread Felipe Balbi 
this makes it slightly easier to read generic CMD
logs. It also helps make sure we're sending proper
parameters for each command.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/dwc3/gadget.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 2406a82..c37c8ff 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -302,6 +302,32 @@ static const char *dwc3_gadget_ep_cmd_string(u8 cmd)
}
 }
 
+static const char *dwc3_gadget_generic_cmd_string(u8 cmd)
+{
+   switch (cmd) {
+   case DWC3_DGCMD_SET_LMP:
+   return "Set LMP";
+   case DWC3_DGCMD_SET_PERIODIC_PAR:
+   return "Set Periodic Parameters";
+   case DWC3_DGCMD_XMIT_FUNCTION:
+   return "Transmit Function Wake Device Notification";
+   case DWC3_DGCMD_SET_SCRATCHPAD_ADDR_LO:
+   return "Set Scratchpad Buffer Array Address Lo";
+   case DWC3_DGCMD_SET_SCRATCHPAD_ADDR_HI:
+   return "Set Scratchpad Buffer Array Address Hi";
+   case DWC3_DGCMD_SELECTED_FIFO_FLUSH:
+   return "Selected FIFO Flush";
+   case DWC3_DGCMD_ALL_FIFO_FLUSH:
+   return "All FIFO Flush";
+   case DWC3_DGCMD_SET_ENDPOINT_NRDY:
+   return "Set Endpoint NRDY";
+   case DWC3_DGCMD_RUN_SOC_BUS_LOOPBACK:
+   return "Run SoC Bus Loopback Test";
+   default:
+   return "UNKNOWN";
+   }
+}
+
 static const char *dwc3_gadget_link_string(enum dwc3_link_state link_state)
 {
switch (link_state) {
@@ -343,6 +369,9 @@ int dwc3_send_gadget_generic_command(struct dwc3 *dwc, int 
cmd, u32 param)
u32 timeout = 500;
u32 reg;
 
+   dev_vdbg(dwc->dev, "generic cmd '%s' [%d] param %08x\n",
+   dwc3_gadget_generic_cmd_string(cmd), cmd, param);
+
dwc3_writel(dwc->regs, DWC3_DGCMDPAR, param);
dwc3_writel(dwc->regs, DWC3_DGCMD, cmd | DWC3_DGCMD_CMDACT);
 
-- 
1.9.2.459.g68773ac

--
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-linus v2 3/4] usb: qcserial: remove interface number matching

2014-04-25 Thread Bjørn Mork 
Matching on interface numbers was not such a good idea
for multi-function serial devices after all. It is much
better do create well defined device layouts, allowing
a single match entry per device.

Remove this now unused code.

Signed-off-by: Bjørn Mork 
---
 drivers/usb/serial/qcserial.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index 42c246acec20..e6673946680d 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -185,13 +185,6 @@ static int qcprobe(struct usb_serial *serial, const struct 
usb_device_id *id)
 
}
 
-   /* allow any number of interfaces when doing direct interface match */
-   if (id->match_flags & USB_DEVICE_ID_MATCH_INT_NUMBER) {
-   dev_dbg(dev, "Generic Qualcomm serial interface found\n");
-   altsetting = 0;
-   goto done;
-   }
-
/* default to enabling interface */
altsetting = 0;
 
-- 
2.0.0.rc0

--
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-linus v2 1/4] usb: qcserial: refactor device layout selection

2014-04-25 Thread Bjørn Mork 
Preparing for more supported standard device layouts. Keeping
the matching macros unchanged to avoid breaking stable
backporting of new device additions.

Signed-off-by: Bjørn Mork 
---
 drivers/usb/serial/qcserial.c | 22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index 7ed681a714a5..23cc274727bc 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -22,8 +22,14 @@
 #define DRIVER_AUTHOR "Qualcomm Inc"
 #define DRIVER_DESC "Qualcomm USB Serial driver"
 
+/* standard device layouts supported by this driver */
+enum qcserial_layouts {
+   QCSERIAL_G2K = 0,   /* Gobi 2000 */
+   QCSERIAL_G1K = 1,   /* Gobi 1000 */
+};
+
 #define DEVICE_G1K(v, p) \
-   USB_DEVICE(v, p), .driver_info = 1
+   USB_DEVICE(v, p), .driver_info = QCSERIAL_G1K
 
 static const struct usb_device_id id_table[] = {
/* Gobi 1000 devices */
@@ -163,11 +169,8 @@ static int qcprobe(struct usb_serial *serial, const struct 
usb_device_id *id)
int retval = -ENODEV;
__u8 nintf;
__u8 ifnum;
-   bool is_gobi1k = id->driver_info ? true : false;
int altsetting = -1;
 
-   dev_dbg(dev, "Is Gobi 1000 = %d\n", is_gobi1k);
-
nintf = serial->dev->actconfig->desc.bNumInterfaces;
dev_dbg(dev, "Num Interfaces = %d\n", nintf);
ifnum = intf->desc.bInterfaceNumber;
@@ -214,7 +217,8 @@ static int qcprobe(struct usb_serial *serial, const struct 
usb_device_id *id)
 * gets handled by other drivers.
 */
 
-   if (is_gobi1k) {
+   switch (id->driver_info) {
+   case QCSERIAL_G1K:
/* Gobi 1K USB layout:
 * 0: DM/DIAG (use libqcdm from ModemManager for communication)
 * 1: serial port (doesn't respond)
@@ -228,7 +232,8 @@ static int qcprobe(struct usb_serial *serial, const struct 
usb_device_id *id)
dev_dbg(dev, "Modem port found\n");
else
altsetting = -1;
-   } else {
+   break;
+   case QCSERIAL_G2K:
/* Gobi 2K+ USB layout:
 * 0: QMI/net
 * 1: DM/DIAG (use libqcdm from ModemManager for communication)
@@ -255,6 +260,11 @@ static int qcprobe(struct usb_serial *serial, const struct 
usb_device_id *id)
dev_dbg(dev, "Gobi 2K+ NMEA GPS interface found\n");
break;
}
+   break;
+   default:
+   dev_err(dev, "unsupported device layout type: %lu\n",
+   id->driver_info);
+   break;
}
 
 done:
-- 
2.0.0.rc0

--
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-linus v2 0/4] qcserial: refactoring support for Sierra Wireless devices

2014-04-25 Thread Bjørn Mork 
I just have to admit that using the per-interface number matching
here wasn't such a good idea after all. It just does not scale
well when adding new devices, and I think we should break now
before we have added even more redundant match entries.

This series refactors the device layout selecting code to simplify
adding more layouts, and then define a Sierra Wireless specific 
layout.  This layout is applied to the existing entries, and to
a number of yet unsupported Sierra made Dell devices.

The old support for single interface number matching is no longer
necessary after this, and is therefore removed.

Comments are appreciated.  I realize that this will complicate
stuff a bit for stable backports while both schemes are in use,
but I do believe it represents a necessary simplification in the
long run.

v2: rebased on top of recent qcserial device additions


Bjørn Mork (4):
  usb: qcserial: refactor device layout selection
  usb: qcserial: define and use Sierra Wireless layout
  usb: qcserial: remove interface number matching
  usb: qcserial: add a number of Dell devices

 drivers/usb/serial/qcserial.c | 111 ++
 1 file changed, 68 insertions(+), 43 deletions(-)

-- 
2.0.0.rc0

--
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

  1   2   >