Re: Not enough host controller resources for new device state

[Alan Stern]

On Mon, 23 Nov 2015, Patrick Shirkey wrote:

> >> Is there a method to determine if the system has multiple or single
> >> controllers available?
> >
> > lspci will tell you.
> >
> >> Do you or anyone else here have a link to the sysfs command to unbind
> >> the
> >> controller?
> >
> > If you provide the output from "lspci", I will tell you what command to
> > use.
> >
> 
> Here's the USB info from lspci.
> 
> # lspci
> 
> 00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
> Family USB xHCI (rev 05)
> 00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series
> Chipset Family MEI Controller #1 (rev 04)
> 00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
> Family USB EHCI #2 (rev 05)
> 00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
> Family USB EHCI #1 (rev 05)

The first one is the xHCI controller and the last two are EHCI
controllers.  The command to unbind the xhci-hcd driver from the
controller is this (as root):

echo :00:14.0 >/sys/bus/pci/drivers/xhci_hcd/unbind

To rebind the driver back to the controller, you do:

echo :00:14.0 >/sys/bus/pci/drivers/xhci_hcd/bind


> >> In regards to the last item can you provide some more details on why the
> >> software switch is only set if the kernel module is enable/disabled?
> >>
> >> I assume it has something to do with compiler flags and run time
> >> efficiency?
> >
> > No, it's simpler than that.  If the kernel is built without support for
> > xHCI, it would be foolish to connect devices to the xHCI controller --
> > then the system wouldn't be able to communicate with them!
> >
> > Conversely, if the kernel does have support for xHCI, we assume that
> > the user will prefer xHCI over EHCI if the motherboard has xHCI.
> > Therefore the switch does get set to connect devices to the xHCI
> > controller.
> >
> 
> Obviously the solution above should suffice for my purposes but out of
> interest is it viable to make the switch accessible to run time
> configuration?

I don't know.  Mathias (the Linux xHCI maintainer) is the right person
to ask.

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: dwc2: add support of hi6220

[zhangfei]

On 11/20/2015 11:34 PM, Felipe Balbi wrote:


John Youn  writes:



That's weird. I just sync'd to your testing/next and it seems to
apply fine.

Same with the series from Gregory Herrero.

Any chance it's something to do with your local repo?


odd. Seems like it works if I apply manually with git am, but fails if I
pipe message from emacs to git am. Oh well, let me try again.



Thanks Felipe & John, have verified hi6220 usb on testing/next.

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

Re: [PATCH v2] phy-sun4i-usb: Add support for the host usb-phys found on the H3 SoC

[Kishon Vijay Abraham I]

Hi,

On Sunday 22 November 2015 04:59 PM, Hans de Goede wrote:
> From: Reinder de Haan 
> 
> Note this commit only adds support for phys 1-3, phy 0, the otg phy, is
> not yet (fully) supported after this commit.
> 
> Signed-off-by: Reinder de Haan 
> Signed-off-by: Hans de Goede 
> ---
> Changes in v2:
> -Change break; after dev_err() to return, as intended, fixing a compiler
>  warning (the dev_err case should never be reached).
> ---
>  .../devicetree/bindings/phy/sun4i-usb-phy.txt  |  1 +
>  drivers/phy/phy-sun4i-usb.c| 67 
> +-
>  2 files changed, 53 insertions(+), 15 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt 
> b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> index 0cebf74..95736d7 100644
> --- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> @@ -9,6 +9,7 @@ Required properties:
>* allwinner,sun7i-a20-usb-phy
>* allwinner,sun8i-a23-usb-phy
>* allwinner,sun8i-a33-usb-phy
> +  * allwinner,sun8i-h3-usb-phy
>  - reg : a list of offset + length pairs
>  - reg-names :
>* "phy_ctrl"
> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
> index b12964b..11bc9cd 100644
> --- a/drivers/phy/phy-sun4i-usb.c
> +++ b/drivers/phy/phy-sun4i-usb.c
> @@ -46,6 +46,9 @@
>  #define REG_PHYBIST  0x08
>  #define REG_PHYTUNE  0x0c
>  #define REG_PHYCTL_A33   0x10
> +#define REG_PHY_UNK_H3   0x20
> +
> +#define REG_PMU_UNK_H3   0x10
>  
>  #define PHYCTL_DATA  BIT(7)
>  
> @@ -79,7 +82,7 @@
>  #define PHY_DISCON_TH_SEL0x2a
>  #define PHY_SQUELCH_DETECT   0x3c
>  
> -#define MAX_PHYS 3
> +#define MAX_PHYS 4

Is it 4 only for h3-usb-phy or for others too? If so, can we add it in driver 
data?
>  
>  /*
>   * Note do not raise the debounce time, we must report Vusb high within 100ms
> @@ -88,12 +91,19 @@
>  #define DEBOUNCE_TIMEmsecs_to_jiffies(50)
>  #define POLL_TIMEmsecs_to_jiffies(250)
>  
> +enum sun4i_usb_phy_type {
> + sun4i_a10_phy,
> + sun8i_a33_phy,
> + sun8i_h3_phy
> +};
> +
>  struct sun4i_usb_phy_data {
> + struct device *dev;
>   void __iomem *base;
>   struct mutex mutex;
>   int num_phys;
>   u32 disc_thresh;
> - bool has_a33_phyctl;
> + enum sun4i_usb_phy_type type;
>   struct sun4i_usb_phy {
>   struct phy *phy;
>   void __iomem *pmu;
> @@ -164,12 +174,18 @@ static void sun4i_usb_phy_write(struct sun4i_usb_phy 
> *phy, u32 addr, u32 data,
>  
>   mutex_lock(_data->mutex);
>  
> - if (phy_data->has_a33_phyctl) {
> + switch (phy_data->type) {
> + case sun4i_a10_phy:
> + phyctl = phy_data->base + REG_PHYCTL_A10;
> + break;
> + case sun8i_a33_phy:
>   phyctl = phy_data->base + REG_PHYCTL_A33;
>   /* A33 needs us to set phyctl to 0 explicitly */
>   writel(0, phyctl);
> - } else {
> - phyctl = phy_data->base + REG_PHYCTL_A10;
> + break;
> + case sun8i_h3_phy:
> + dev_err(phy_data->dev, "H3 usb_phy_write is not supported\n");
> + return;
>   }
>  
>   for (i = 0; i < len; i++) {
> @@ -230,6 +246,7 @@ static int sun4i_usb_phy_init(struct phy *_phy)
>   struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
>   struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
>   int ret;
> + u32 val;
>  
>   ret = clk_prepare_enable(phy->clk);
>   if (ret)
> @@ -241,15 +258,26 @@ static int sun4i_usb_phy_init(struct phy *_phy)
>   return ret;
>   }
>  
> - /* Enable USB 45 Ohm resistor calibration */
> - if (phy->index == 0)
> - sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
> + if (data->type == sun8i_h3_phy) {
> + if (phy->index == 0) {
> + val = readl(data->base + REG_PHY_UNK_H3);
> + writel(val & ~1, data->base + REG_PHY_UNK_H3);
> + }
> +
> + val = readl(phy->pmu + REG_PMU_UNK_H3);
> + writel(val & ~2, phy->pmu + REG_PMU_UNK_H3);
> + } else {
> + /* Enable USB 45 Ohm resistor calibration */
> + if (phy->index == 0)
> + sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
>  
> - /* Adjust PHY's magnitude and rate */
> - sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);
> + /* Adjust PHY's magnitude and rate */
> + sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);
>  
> - /* Disconnect threshold adjustment */
> - sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL, data->disc_thresh, 

Re: [PATCH v6 4/4] usb: gadget: udc-core: independent registration of gadgets and gadget drivers

[Peter Chen]

On Fri, Nov 20, 2015 at 11:27:36AM -0500, Alan Stern wrote:
> On Fri, 20 Nov 2015, Marek Szyprowski wrote:
> 
> > From: Ruslan Bilovol 
> > 
> > Change behavior during registration of gadgets and
> > gadget drivers in udc-core. Instead of previous
> > approach when for successful probe of usb gadget driver
> > at least one usb gadget should be already registered
> > use another one where gadget drivers and gadgets
> > can be registered in udc-core independently.
> > 
> > Independent registration of gadgets and gadget drivers
> > is useful for built-in into kernel gadget and gadget
> > driver case - because it's possible that gadget is
> > really probed only on late_init stage (due to deferred
> > probe) whereas gadget driver's probe is silently failed
> > on module_init stage due to no any UDC added.
> > 
> > Also it is useful for modules case - now there is no
> > difference what module to insert first: gadget module
> > or gadget driver one.
> > 
> > Tested-by: Maxime Ripard 
> > Signed-off-by: Ruslan Bilovol 
> > [simplified code as requested by Alan Stern and Felipe Balbi]
> > Signed-off-by: Marek Szyprowski 
> 
> ...
> 
> > @@ -475,9 +492,16 @@ void usb_del_gadget_udc(struct usb_gadget *gadget)
> > list_del(>list);
> > mutex_unlock(_lock);
> >  
> > -   if (udc->driver)
> > +   if (udc->driver) {
> > +   struct usb_gadget_driver *driver = udc->driver;
> > +
> > usb_gadget_remove_driver(udc);
> >  
> > +   mutex_lock(_lock);
> > +   list_add(>pending, _driver_pending_list);
> > +   mutex_unlock(_lock);
> > +   }
> 
> It looks like there is a race here with usb_gadget_unregister_driver().  
> Would it be okay to hold the udc_lock mutex throughout the whole "if"  
> statement?
> 

+1

In fact, only one mutex_lock/mutex_unlock is needed at this function.
-- 

Best Regards,
Peter Chen
--
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: Not enough host controller resources for new device state

[Patrick Shirkey]

On Mon, November 23, 2015 1:24 pm, Alan Stern wrote:
> On Mon, 23 Nov 2015, Patrick Shirkey wrote:
>
>> >> Is there a method to determine if the system has multiple or single
>> >> controllers available?
>> >
>> > lspci will tell you.
>> >
>> >> Do you or anyone else here have a link to the sysfs command to unbind
>> >> the
>> >> controller?
>> >
>> > If you provide the output from "lspci", I will tell you what command
>> to
>> > use.
>> >
>>
>> Here's the USB info from lspci.
>>
>> # lspci
>>
>> 00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
>> Family USB xHCI (rev 05)
>> 00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series
>> Chipset Family MEI Controller #1 (rev 04)
>> 00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
>> Family USB EHCI #2 (rev 05)
>> 00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
>> Family USB EHCI #1 (rev 05)
>
> The first one is the xHCI controller and the last two are EHCI
> controllers.  The command to unbind the xhci-hcd driver from the
> controller is this (as root):
>
>   echo :00:14.0 >/sys/bus/pci/drivers/xhci_hcd/unbind
>
> To rebind the driver back to the controller, you do:
>
>   echo :00:14.0 >/sys/bus/pci/drivers/xhci_hcd/bind
>
>

Thanks Alan,

FYI, running these commands exhibits some interesting behavior on my machine.

Unbinding disables all external ports.

[7946053.417529] xhci_hcd :00:14.0: remove, state 4
[7946053.417537] usb usb4: USB disconnect, device number 1
[7946053.418082] xhci_hcd :00:14.0: USB bus 4 deregistered
[7946053.418091] xhci_hcd :00:14.0: remove, state 1
[7946053.418110] usb usb3: USB disconnect, device number 1
[7946053.418112] usb 3-1: USB disconnect, device number 2
[7946053.469171] usb 3-2: USB disconnect, device number 3
[7946053.469643] sd 196:0:0:0: [sdf] Synchronizing SCSI cache
[7946053.469692] sd 196:0:0:0: [sdf] Synchronize Cache(10) failed: Result:
hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
[7946053.503557] usb 3-3: USB disconnect, device number 4
[7946053.531384] usb 3-4: USB disconnect, device number 5
[7946053.531389] usb 3-4.1: USB disconnect, device number 7
[7946053.531392] usb 3-4.1.1: USB disconnect, device number 10
[7946053.531394] usb 3-4.1.1.5: USB disconnect, device number 14
[7946053.532460] usb 3-4.2: USB disconnect, device number 9
[7946053.532465] usb 3-4.2.1: USB disconnect, device number 12
[7946053.532468] usb 3-4.2.1.5: USB disconnect, device number 17
[7946053.533093] usb 3-4.2.2: USB disconnect, device number 15
[7946053.533402] usb 3-4.2.5: USB disconnect, device number 19
[7946053.535962] usb 3-4.3: USB disconnect, device number 11
[7946053.535967] usb 3-4.3.1: USB disconnect, device number 16
[7946053.535970] usb 3-4.3.1.1: USB disconnect, device number 21
[7946053.536309] usb 3-4.3.1.3: USB disconnect, device number 24
[7946053.536559] usb 3-4.3.1.4: USB disconnect, device number 27
[7946053.536659] usb 3-4.3.1.5: USB disconnect, device number 30
[7946053.537003] usb 3-4.3.7: USB disconnect, device number 20
[7946053.539933] usb 3-4.4: USB disconnect, device number 13
[7946053.539938] usb 3-4.4.1: USB disconnect, device number 18
[7946053.539941] usb 3-4.4.1.1: USB disconnect, device number 23
[7946053.539944] usb 3-4.4.1.1.5: USB disconnect, device number 28
[7946053.542235] usb 3-4.4.1.5: USB disconnect, device number 25
[7946053.542711] usb 3-4.4.1.7: USB disconnect, device number 29
[7946053.543885] usb 3-4.4.2: USB disconnect, device number 22
[7946053.543890] usb 3-4.4.2.1: USB disconnect, device number 26
[7946053.546309] usb 3-5: USB disconnect, device number 6
[7946053.546968] usb 3-7: USB disconnect, device number 8
[7946053.613004] xhci_hcd :00:14.0: USB bus 3 deregistered



I see the following with lsusb after unbinding:

# lsusb
Bus 002 Device 002: ID 8087:8000 Intel Corp.
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:8008 Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

- Un/plugging devices appears to have no effect:

- Binding enables all external ports again without un/plugging.

Does this behavior suggest that even if I disable xHCI at BIOS level I may
not be able to use the eHCI controllers stand alone on this machine or is
there something else I can tweak at the system level?



>> >> In regards to the last item can you provide some more details on why
>> the
>> >> software switch is only set if the kernel module is enable/disabled?
>> >>
>> >> I assume it has something to do with compiler flags and run time
>> >> efficiency?
>> >
>> > No, it's simpler than that.  If the kernel is built without support
>> for
>> > xHCI, it would be foolish to connect devices to the xHCI controller --
>> > then the system wouldn't be able to communicate with them!
>> >
>> > Conversely, if the kernel does have support for xHCI, we assume that
>> > the user will prefer xHCI over EHCI if the motherboard has xHCI.

Re: [PATCH v6 4/4] usb: gadget: udc-core: independent registration of gadgets and gadget drivers

[Peter Chen]

On Fri, Nov 20, 2015 at 09:54:12AM +0100, Marek Szyprowski wrote:
> From: Ruslan Bilovol 
> 
> Change behavior during registration of gadgets and
> gadget drivers in udc-core. Instead of previous
> approach when for successful probe of usb gadget driver
> at least one usb gadget should be already registered
> use another one where gadget drivers and gadgets
> can be registered in udc-core independently.
> 
> Independent registration of gadgets and gadget drivers
> is useful for built-in into kernel gadget and gadget
> driver case - because it's possible that gadget is
> really probed only on late_init stage (due to deferred
> probe) whereas gadget driver's probe is silently failed
> on module_init stage due to no any UDC added.
> 
> Also it is useful for modules case - now there is no
> difference what module to insert first: gadget module
> or gadget driver one.
> 
> Tested-by: Maxime Ripard 
> Signed-off-by: Ruslan Bilovol 
> [simplified code as requested by Alan Stern and Felipe Balbi]
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/usb/gadget/udc/udc-core.c | 43 
> +++
>  include/linux/usb/gadget.h|  2 ++
>  2 files changed, 37 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/usb/gadget/udc/udc-core.c 
> b/drivers/usb/gadget/udc/udc-core.c
> index f76ebc8..461b311 100644
> --- a/drivers/usb/gadget/udc/udc-core.c
> +++ b/drivers/usb/gadget/udc/udc-core.c
> @@ -51,8 +51,12 @@ struct usb_udc {
>  
>  static struct class *udc_class;
>  static LIST_HEAD(udc_list);
> +static LIST_HEAD(gadget_driver_pending_list);
>  static DEFINE_MUTEX(udc_lock);
>  
> +static int udc_bind_to_driver(struct usb_udc *udc,
> + struct usb_gadget_driver *driver);
> +
>  /* - 
> */
>  
>  #ifdef   CONFIG_HAS_DMA
> @@ -356,6 +360,7 @@ int usb_add_gadget_udc_release(struct device *parent, 
> struct usb_gadget *gadget,
>   void (*release)(struct device *dev))
>  {
>   struct usb_udc  *udc;
> + struct usb_gadget_driver *driver;
>   int ret = -ENOMEM;
>  
>   udc = kzalloc(sizeof(*udc), GFP_KERNEL);
> @@ -403,6 +408,18 @@ int usb_add_gadget_udc_release(struct device *parent, 
> struct usb_gadget *gadget,
>   usb_gadget_set_state(gadget, USB_STATE_NOTATTACHED);
>   udc->vbus = true;
>  
> + /* pick up one of pending gadget drivers */
> + list_for_each_entry(driver, _driver_pending_list, pending) {
> + if (!driver->udc_name || strcmp(driver->udc_name,
> + dev_name(>dev)) == 0) {
> + ret = udc_bind_to_driver(udc, driver);
> + if (ret)
> + goto err4;
> + list_del(>pending);
> + break;
> + }
> + }
> +
>   mutex_unlock(_lock);
>  
>   return 0;
> @@ -475,9 +492,16 @@ void usb_del_gadget_udc(struct usb_gadget *gadget)
>   list_del(>list);
>   mutex_unlock(_lock);
>  
> - if (udc->driver)
> + if (udc->driver) {
> + struct usb_gadget_driver *driver = udc->driver;
> +
>   usb_gadget_remove_driver(udc);
>  
> + mutex_lock(_lock);
> + list_add(>pending, _driver_pending_list);
> + mutex_unlock(_lock);
> + }
> +
>   kobject_uevent(>dev.kobj, KOBJ_REMOVE);
>   flush_work(>work);
>   device_unregister(>dev);
> @@ -535,11 +559,7 @@ int usb_gadget_probe_driver(struct usb_gadget_driver 
> *driver)
>   if (!ret)
>   break;
>   }
> - if (ret)
> - ret = -ENODEV;
> - else if (udc->driver)
> - ret = -EBUSY;
> - else
> + if (!ret && !udc->driver)
>   goto found;
>   } else {
>   list_for_each_entry(udc, _list, list) {
> @@ -549,9 +569,12 @@ int usb_gadget_probe_driver(struct usb_gadget_driver 
> *driver)
>   }
>   }
>  
> - pr_debug("couldn't find an available UDC\n");
> + list_add_tail(>pending, _driver_pending_list);
> + pr_info("udc-core: couldn't find an available UDC "
> + "- added [%s] to list of pending drivers\n",
> + driver->function);

There is an warning when trying to apply it:

WARNING: quoted string split across lines.

I tested this series, it works ok for both module and build-in function,
it fixed gadget function broken if it is build-in at imx6qdl sabreauto board.

Tested-by: Peter Chen 

-- 

Best Regards,
Peter Chen
--
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  

Re: [PATCH 2/2] usb: phy: msm: fix connect/disconnect bug for dragonboard OTG port

[Peter Chen]

On Fri, Nov 20, 2015 at 06:58:59PM -0600, Felipe Balbi wrote:
> 
> Hi,
> 
> Tim Bird  writes:
> > On 11/16/2015 09:21 AM, Felipe Balbi wrote:
> >> 
> >> Hi,
> >> 
> >> Peter Chen  writes:
> >>> On Wed, Nov 11, 2015 at 09:48:00AM -0800, Tim Bird wrote:
> 
> 
>  On 11/10/2015 07:14 PM, Peter Chen wrote:
> > On Tue, Nov 10, 2015 at 04:46:51PM -0800, Tim Bird wrote:
> >> This fixes a bug where if you disconnect and re-connect the USB cable,
> >> the gadget driver stops working.
> >>
> >> Add support for async_irq to wake up driver from low power mode.
> >> Without this, the power management code never calls resume.
> >> Also, have the phy driver kick the gadget driver (chipidea otg)
> >> by having the chipidea driver register with it, for vbus connect
> >> notifications.
> >>
> >> Signed-off-by: Tim Bird 
> >> ---
> >>  drivers/usb/chipidea/udc.c|  6 ++
> >>  drivers/usb/phy/phy-msm-usb.c | 16 
> >>  include/linux/usb/msm_hsusb.h |  1 +
> >>  3 files changed, 23 insertions(+)
> >> 
> >> I just wanna know how you guys want this to be handled ? Through my tree
> >> or chipidea's ? Or do we break the dependencies between the changes ?
> >
> > I'm fine with splitting it up.  I'm sending a new series with 3 patches
> > right after this message.  Do both trees go to linux-next?
> 
> I have my fixes and next branches both on next. Not sure about chipidea.
> 

Chipidea's fixes and next branches on next too.


-- 

Best Regards,
Peter Chen
--
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: [Linux USB] enable/disable individual ports

[Alan Stern]

On Sun, 22 Nov 2015, Greg KH wrote:

> On Sun, Nov 22, 2015 at 07:26:08PM +0100, Peter Stuge wrote:
> > Alan Stern wrote:
> > > It does print out a message, though not a big one.  Would you like it
> > > to do something more specific?  A more verbose "usage" message,
> > > perhaps?
> > 
> > That's a good idea, and additionally I think it would be important to
> > print (much) more information if the ioctl() fails.
> 
> I agree.

What more is there to print?  If the ioctl fails, all the program gets
back from the kernel is an error code, which it already prints out.  I
wouldn't mind adding something else, if anybody can suggest what it
might be.

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: [Linux USB] enable/disable individual ports

[Peter Stuge]

Alan Stern wrote:
> > > > It does print out a message, though not a big one.  Would you like it
> > > > to do something more specific?  A more verbose "usage" message,
> > > > perhaps?
> > > 
> > > That's a good idea, and additionally I think it would be important to
> > > print (much) more information if the ioctl() fails.
> > 
> > I agree.
> 
> What more is there to print?  If the ioctl fails, all the program gets
> back from the kernel is an error code, which it already prints out.  I
> wouldn't mind adding something else, if anybody can suggest what it
> might be.

Information about possible reasons for failure, in particular
that this operation may simply not be supported by the hardware.

Ideally even have a special case for that, with overly clear text,
if it is indeed possible to determine from the error code that this
is the cause.


//Peter
--
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: Not enough host controller resources for new device state

[Alan Stern]

On Sun, 22 Nov 2015, Peter Stuge wrote:

> Patrick Shirkey wrote:
> > > if the kernel does have support for xHCI, we assume that
> > > the user will prefer xHCI over EHCI if the motherboard has xHCI.
> > 
> > Obviously the solution above should suffice for my purposes but out
> > of interest is it viable to make the switch accessible to run time
> > configuration?
> 
> I don't think it makes sense to expose the port routing to user
> space, but I think it would make sense to route ports to the EHCI HC(s)
> when xhci-hcd is unbound, and vice versa.
> 
> I'm not sure what the best implementation for this would be. Would it
> be possible for ehci-hcd to call into xhci-hcd code, even if xhci-hcd
> is not currently bound anywhere?
> 
> One possibility is to add code to both drivers which gets called on
> unbind and which routes ports to the respective other controller type,
> but that doesn't really seem like a great solution. It would be nicer
> to have a single entry point for the (re)routing.
> 
> Alan, what are your thoughts on that?

In general it's best not to make things too complicated.  Perhaps the
switch could be changed at runtime, say whenever xhci-hcd binds to or
unbinds from the motherboard's controller.  But this could have
undesirable consequences.

For example, if xhci-hcd is a little slow to load (say because it's in
a loadable module that takes some time to install), a USB-3 disk drive
might start out connecting to the EHCI controller and being mounted.  
Then when the switch setting is changed, the disk would be forcibly
disconnected from EHCI, which could mess up any writes that were in
progress, not to mention causing a number of alarming messages to show 
up in the system log.

I'd like to hear what Mathias says before making any definite 
suggestions.

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] phy: add phy-hi6220-usb

[Zhangfei Gao]

Support hi6220 use phy for HiKey board

Acked-by: Rob Herring 
Signed-off-by: Zhangfei Gao 
---
Rebase to  Linux 4.4-rc1
 
 .../devicetree/bindings/phy/phy-hi6220-usb.txt |  16 ++
 drivers/phy/Kconfig|   9 ++
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-hi6220-usb.c   | 168 +
 4 files changed, 194 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-hi6220-usb.txt
 create mode 100644 drivers/phy/phy-hi6220-usb.c

diff --git a/Documentation/devicetree/bindings/phy/phy-hi6220-usb.txt 
b/Documentation/devicetree/bindings/phy/phy-hi6220-usb.txt
new file mode 100644
index ..f17a56e2152f
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-hi6220-usb.txt
@@ -0,0 +1,16 @@
+Hisilicon hi6220 usb PHY
+---
+
+Required properties:
+- compatible: should be "hisilicon,hi6220-usb-phy"
+- #phy-cells: must be 0
+- hisilicon,peripheral-syscon: phandle of syscon used to control phy.
+Refer to phy/phy-bindings.txt for the generic PHY binding properties
+
+Example:
+   usb_phy: usbphy {
+   compatible = "hisilicon,hi6220-usb-phy";
+   #phy-cells = <0>;
+   phy-supply = <_5v_hub>;
+   hisilicon,peripheral-syscon = <_ctrl>;
+   };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 7eb5859dd035..e1090507f2cd 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -215,6 +215,15 @@ config PHY_MT65XX_USB3
  for mt65xx SoCs. it supports two usb2.0 ports and
  one usb3.0 port.
 
+config PHY_HI6220_USB
+   tristate "hi6220 USB PHY support"
+   select GENERIC_PHY
+   select MFD_SYSCON
+   help
+ Enable this to support the HISILICON HI6220 USB PHY.
+
+ To compile this driver as a module, choose M here.
+
 config PHY_SUN4I_USB
tristate "Allwinner sunxi SoC USB PHY driver"
depends on ARCH_SUNXI && HAS_IOMEM && OF
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 075db1a81aa5..faccda1f237f 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_TI_PIPE3)+= 
phy-ti-pipe3.o
 obj-$(CONFIG_TWL4030_USB)  += phy-twl4030-usb.o
 obj-$(CONFIG_PHY_EXYNOS5250_SATA)  += phy-exynos5250-sata.o
 obj-$(CONFIG_PHY_HIX5HD2_SATA) += phy-hix5hd2-sata.o
+obj-$(CONFIG_PHY_HI6220_USB)   += phy-hi6220-usb.o
 obj-$(CONFIG_PHY_MT65XX_USB3)  += phy-mt65xx-usb3.o
 obj-$(CONFIG_PHY_SUN4I_USB)+= phy-sun4i-usb.o
 obj-$(CONFIG_PHY_SUN9I_USB)+= phy-sun9i-usb.o
diff --git a/drivers/phy/phy-hi6220-usb.c b/drivers/phy/phy-hi6220-usb.c
new file mode 100644
index ..b2141cbd4cf6
--- /dev/null
+++ b/drivers/phy/phy-hi6220-usb.c
@@ -0,0 +1,168 @@
+/*
+ * Copyright (c) 2015 Linaro Ltd.
+ * Copyright (c) 2015 Hisilicon Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SC_PERIPH_CTRL40x00c
+
+#define CTRL4_PICO_SIDDQ   BIT(6)
+#define CTRL4_PICO_OGDISABLE   BIT(8)
+#define CTRL4_PICO_VBUSVLDEXT  BIT(10)
+#define CTRL4_PICO_VBUSVLDEXTSEL   BIT(11)
+#define CTRL4_OTG_PHY_SEL  BIT(21)
+
+#define SC_PERIPH_CTRL50x010
+
+#define CTRL5_USBOTG_RES_SEL   BIT(3)
+#define CTRL5_PICOPHY_ACAENB   BIT(4)
+#define CTRL5_PICOPHY_BC_MODE  BIT(5)
+#define CTRL5_PICOPHY_CHRGSEL  BIT(6)
+#define CTRL5_PICOPHY_VDATSRCEND   BIT(7)
+#define CTRL5_PICOPHY_VDATDETENB   BIT(8)
+#define CTRL5_PICOPHY_DCDENB   BIT(9)
+#define CTRL5_PICOPHY_IDDIGBIT(10)
+
+#define SC_PERIPH_CTRL80x018
+#define SC_PERIPH_RSTEN0   0x300
+#define SC_PERIPH_RSTDIS0  0x304
+
+#define RST0_USBOTG_BUSBIT(4)
+#define RST0_POR_PICOPHY   BIT(5)
+#define RST0_USBOTGBIT(6)
+#define RST0_USBOTG_32KBIT(7)
+
+#define EYE_PATTERN_PARA   0x7053348c
+
+struct hi6220_priv {
+   struct regmap *reg;
+   struct device *dev;
+};
+
+static void hi6220_phy_init(struct hi6220_priv *priv)
+{
+   struct regmap *reg = priv->reg;
+   u32 val, mask;
+
+   val = RST0_USBOTG_BUS | RST0_POR_PICOPHY |
+ RST0_USBOTG | RST0_USBOTG_32K;
+   mask = val;
+   regmap_update_bits(reg, SC_PERIPH_RSTEN0, mask, val);
+   regmap_update_bits(reg, SC_PERIPH_RSTDIS0, mask, val);
+}
+
+static int hi6220_phy_setup(struct hi6220_priv *priv, bool on)
+{
+   struct 

Re: [PATCH v5 5/5] Add ioctls to enable and disable local controls on an instrument

[Dave Penkler]

On Wed, Nov 18, 2015 at 11:41:30AM +0200, Andy Shevchenko wrote:
> On Wed, Nov 18, 2015 at 10:38 AM, Dave Penkler  wrote:
> > These ioctls provide support for the USBTMC-USB488 control requests
> > for REN_CONTROL, GO_TO_LOCAL and LOCAL_LOCKOUT
> 
> Couple of comments below.
> 
> > diff --git a/drivers/usb/class/usbtmc.c b/drivers/usb/class/usbtmc.c
> > index 2358991..d416a5f 100644
> > --- a/drivers/usb/class/usbtmc.c
> > +++ b/drivers/usb/class/usbtmc.c
> > @@ -476,6 +476,62 @@ static int usbtmc488_ioctl_read_stb(struct 
> > usbtmc_device_data *data,

snip

> 
> > +   if (rv < 0) {
> > +   dev_err(dev, "simple usb_control_msg failed %d\n", rv);
> > +   goto exit;
> > +   } else if (rv != 1) {
> > +   dev_warn(dev, "simple usb_control_msg returned %d\n", rv);
> 
> Actually here what king of results could be? 0? 2+? In all cases of
> error you have to provide an error code.
> 

We seem to be going round in circles here, last time you suggested to
propagate the return value. The non-negative return is the number of bytes
transferred which should be 1 unless there is some usb implementation
flakiness happening. So I will go back to returning -EIO.

> > +   goto exit;
> > +   }
> > +
> > +   if (buffer[0] != USBTMC_STATUS_SUCCESS) {
> > +   dev_err(dev, "simple control status returned %x\n", 
> > buffer[0]);
> > +   rv = -EIO;
> > +   goto exit;
> > +   }
> > +   rv = 0;
> > +
> > + exit:
> > +   kfree(buffer);
> > +   return rv;
> > +}
> > +
> 
> -- 
> With Best Regards,
> Andy Shevchenko
cheers,
-Dave
--
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: Not enough host controller resources for new device state

[Alan Stern]

On Sun, 22 Nov 2015, Patrick Shirkey wrote:

> > It _is_ possible to disable xHCI at the system level.  By sending the
> > proper command to the appropriate sysfs file, you can unbind the
> > xhci-hcd driver from the xHCI controller.  This will disable the
> > controller, and so all further USB communications will run no faster
> > than High Speed.  (Or if your computer doesn't have an EHCI controller,
> > you won't get any further USB communications at all.)
> >
> 
> Is there a method to determine if the system has multiple or single
> controllers available?

lspci will tell you.

> Do you or anyone else here have a link to the sysfs command to unbind the
> controller?

If you provide the output from "lspci", I will tell you what command to 
use.

> > Actually it's a little more complicated than that.  Some systems have a
> > software-settable switch that determines whether devices will connect
> > to the xHCI or the EHCI controller.  On such systems, Linux sets the
> > switch to use xHCI, unless the kernel was built without xHCI support.
> > Therefore, although it is possible to force the use of EHCI on such
> > systems, in order to do so you have to rebuild the kernel.
> >
> 
> 
> In regards to the last item can you provide some more details on why the
> software switch is only set if the kernel module is enable/disabled?
> 
> I assume it has something to do with compiler flags and run time efficiency?

No, it's simpler than that.  If the kernel is built without support for 
xHCI, it would be foolish to connect devices to the xHCI controller -- 
then the system wouldn't be able to communicate with them!

Conversely, if the kernel does have support for xHCI, we assume that
the user will prefer xHCI over EHCI if the motherboard has xHCI.  
Therefore the switch does get set to connect devices to the xHCI
controller.

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: Not enough host controller resources for new device state

[Patrick Shirkey]

On Mon, November 23, 2015 2:43 am, Alan Stern wrote:
> On Sun, 22 Nov 2015, Patrick Shirkey wrote:
>
>> > It _is_ possible to disable xHCI at the system level.  By sending the
>> > proper command to the appropriate sysfs file, you can unbind the
>> > xhci-hcd driver from the xHCI controller.  This will disable the
>> > controller, and so all further USB communications will run no faster
>> > than High Speed.  (Or if your computer doesn't have an EHCI
>> controller,
>> > you won't get any further USB communications at all.)
>> >
>>
>> Is there a method to determine if the system has multiple or single
>> controllers available?
>
> lspci will tell you.
>
>> Do you or anyone else here have a link to the sysfs command to unbind
>> the
>> controller?
>
> If you provide the output from "lspci", I will tell you what command to
> use.
>

Here's the USB info from lspci.

# lspci

00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
Family USB xHCI (rev 05)
00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series
Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
Family USB EHCI #2 (rev 05)
00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
Family USB EHCI #1 (rev 05)



>> > Actually it's a little more complicated than that.  Some systems have
>> a
>> > software-settable switch that determines whether devices will connect
>> > to the xHCI or the EHCI controller.  On such systems, Linux sets the
>> > switch to use xHCI, unless the kernel was built without xHCI support.
>> > Therefore, although it is possible to force the use of EHCI on such
>> > systems, in order to do so you have to rebuild the kernel.
>> >
>>
>>
>> In regards to the last item can you provide some more details on why the
>> software switch is only set if the kernel module is enable/disabled?
>>
>> I assume it has something to do with compiler flags and run time
>> efficiency?
>
> No, it's simpler than that.  If the kernel is built without support for
> xHCI, it would be foolish to connect devices to the xHCI controller --
> then the system wouldn't be able to communicate with them!
>
> Conversely, if the kernel does have support for xHCI, we assume that
> the user will prefer xHCI over EHCI if the motherboard has xHCI.
> Therefore the switch does get set to connect devices to the xHCI
> controller.
>

Obviously the solution above should suffice for my purposes but out of
interest is it viable to make the switch accessible to run time
configuration?





--
Patrick Shirkey
Boost Hardware Ltd
--
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: [Linux USB] enable/disable individual ports

[Alan Stern]

On Sat, 21 Nov 2015, Greg KH wrote:

> > I saved a copy when you first posted it and have used it on quite a few
> > occasions.  Maybe the tool should be added to the usbutils collection so
> > it could reach a somewhat wider audience?  Yes, I know the usecases are
> > all weird, but that still doesn't mean than everyone with a usecase will
> > read this list :)
> 
> I've considered it in the past, but didn't want to deal with all of the
> "this doesn't work on my hardware" emails.  Maybe if the code prints out
> a big message when it's run it might help...

It does print out a message, though not a big one.  Would you like it
to do something more specific?  A more verbose "usage" message,
perhaps?

For convenience, the source code is included below.

Alan Stern



/* usbreset -- send a USB port reset to a USB device */
/* To build:  gcc -o usbreset usbreset.c */

#include 
#include 
#include 
#include 
#include 

#include 


int main(int argc, char **argv)
{
const char *filename;
int fd;
int rc;

if (argc != 2) {
fprintf(stderr, "Usage: usbreset device-filename\n");
return 1;
}
filename = argv[1];

fd = open(filename, O_WRONLY);
if (fd < 0) {
perror("Error opening output file");
return 1;
}

printf("Resetting USB device %s\n", filename);
rc = ioctl(fd, USBDEVFS_RESET, 0);
if (rc < 0) {
perror("Error in ioctl");
return 1;
}
printf("Reset successful\n");

close(fd);
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] usb-storage: Fix scsi-sd failure "Invalid field in cdb" for USB adapter JMicron

[Alan Stern]

On Sat, 21 Nov 2015, Dmitry Katsubo wrote:

> On 20/11/2015 17:08, Alan Stern wrote:
> > On Fri, 20 Nov 2015, Dmitry Katsubo wrote:
> > 
> >> From: Dmitry Katsubo 
> >>
> >> The patch extends the family of SATA-to-USB JMicron adapters that need
> >> FUA to be disabled and applies the same policy for uas driver.
> >> See details in http://unix.stackexchange.com/questions/237204/
> >>
> >> Signed-off-by: Dmitry Katsubo 
> >> Tested-by: Dmitry Katsubo 
> >> ---
> >> The change is trivial, however it spans also to JMicron adapter with
> >> bcdDevice 1.15, which I haven't tested. Nevertheless it is very likely
> >> that it is buggy as well. Patch was applied and tested on Debian Jessie
> >> 4.2.5-1~bpo8+1. There is a checkpatch warning, but it is caused by original
> >> source code formatting.
> > 
> > Acked-by: Alan Stern 
> > 
> > Greg, please apply this.
> > 
> > Dmitry, do you want this be applied to the -stable kernels too?
> 
> That is not necessary. I have working kernel which I am happy with -- many 
> thanks
> for your guidance.

Maybe you're happy with your working kernel, but what about other 
people who have the same type of device?

> What is the next lowest kernel version it will be applied to?

That's up to Greg.  He'll probably include it in the upcoming 4.4
kernel release.

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: Not enough host controller resources for new device state

[Patrick Shirkey]

On Sun, November 22, 2015 5:41 am, Alan Stern wrote:
> On Sat, 21 Nov 2015, Patrick Shirkey wrote:
>
>> On Sat, November 21, 2015 9:35 am, Peter Stuge wrote:
>> > Patrick Shirkey wrote:
>> >> > You essentially have to educate yourself on silicon level (ie. what
>> >> > hardware IP is being used in which consumer products) to sustain a
>> >> > dependency on 127 possible devices per bus.
>> >> >
>> >> > I guess you'll find that there are only very few xHCI IPs out
>> there,
>> >> > probably just three or four. I wouldn't be surprised if they all
>> have
>> >> > the same, or similar, limitations.
>> >>
>> >> Is there anything I can do at the system level to avoid disabling
>> xHCI
>> >> at
>> >> the BIOS level?
>> >
>> > Unfortunately not. The number of supported devices is now very much
>> > hardwired in the host controller hardware. Each connected device
>> > requires its own set of registers in xHCI, so when there is a limit
>> > it is a hard limit.
>> >
>> >
>>
>> That's a bit of a let down as it seems to make it even more difficult to
>> rely on USB for my specific use case in the future.
>>
>> In case anyone else comes across this thread do you mind giving a little
>> more detail on why xHCI overrides EHCI and why it is not possible to
>> disable or work around xHCI at the system level?
>
> xHCI is the controller technology that supports SuperSpeed (5 Gb/s), as
> used by many USB-3 devices.  EHCI is the controller technology that
> supports High Speed (480 Mb/s), used by many USB-2 devices.  (Note that
> xHCI also supports High Speed, as well as Full Speed (12 Mb/s) and Low
> Speed (1.5 Mb/s) which date back to USB-1.1.)
>
> If you disable your xHCI controller, USB connections will not be able
> to run at SuperSpeed.  Depending on how the motherboard is designed,
> they may fall back to High Speed (using an on-board EHCI controller) or
> they may not work at all (if the motherboard doesn't have any other USB
> controllers).
>
> This should explain why xHCI overrides EHCI.  If you have a
> SuperSpeed-capable device, you generally want it to run as fast as
> possible, which means it should connect to the xHCI controller and not
> to the EHCI controller.
>


Thank you again for this details response. It all makes perfect sense now.


> It _is_ possible to disable xHCI at the system level.  By sending the
> proper command to the appropriate sysfs file, you can unbind the
> xhci-hcd driver from the xHCI controller.  This will disable the
> controller, and so all further USB communications will run no faster
> than High Speed.  (Or if your computer doesn't have an EHCI controller,
> you won't get any further USB communications at all.)
>

Is there a method to determine if the system has multiple or single
controllers available?

Do you or anyone else here have a link to the sysfs command to unbind the
controller?

> Actually it's a little more complicated than that.  Some systems have a
> software-settable switch that determines whether devices will connect
> to the xHCI or the EHCI controller.  On such systems, Linux sets the
> switch to use xHCI, unless the kernel was built without xHCI support.
> Therefore, although it is possible to force the use of EHCI on such
> systems, in order to do so you have to rebuild the kernel.
>


In regards to the last item can you provide some more details on why the
software switch is only set if the kernel module is enable/disabled?

I assume it has something to do with compiler flags and run time efficiency?




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

Re: [PATCH v5 5/5] Add ioctls to enable and disable local controls on an instrument

[Andy Shevchenko]

On Sun, Nov 22, 2015 at 10:51 AM, Dave Penkler  wrote:
> On Wed, Nov 18, 2015 at 11:41:30AM +0200, Andy Shevchenko wrote:
>> On Wed, Nov 18, 2015 at 10:38 AM, Dave Penkler  wrote:


>> > +   if (rv < 0) {
>> > +   dev_err(dev, "simple usb_control_msg failed %d\n", rv);
>> > +   goto exit;
>> > +   } else if (rv != 1) {
>> > +   dev_warn(dev, "simple usb_control_msg returned %d\n", rv);
>>
>> Actually here what king of results could be? 0? 2+? In all cases of
>> error you have to provide an error code.
>>
>
> We seem to be going round in circles here, last time you suggested to
> propagate the return value.

You didn't pay much attention to where I put my comment. You have few
branches depending on return value

1) negative, apparently an error code, should be propagated if nothing
specific to framework;
2) zero, what does it means?
3) one, seems the expected result when success, so, error code should be 0;
4) two, three, … non-negative numbers,see 2).

For my understanding 2) and 4) have to return what you initially had -EIO.

> The non-negative return is the number of bytes
> transferred which should be 1 unless there is some usb implementation
> flakiness happening. So I will go back to returning -EIO.

Yes, in *this* branch.

>
>> > +   goto exit;
>> > +   }
>> > +
>> > +   if (buffer[0] != USBTMC_STATUS_SUCCESS) {
>> > +   dev_err(dev, "simple control status returned %x\n", 
>> > buffer[0]);
>> > +   rv = -EIO;
>> > +   goto exit;
>> > +   }
>> > +   rv = 0;
>> > +
>> > + exit:
>> > +   kfree(buffer);
>> > +   return rv;
>> > +}

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

[PATCH v3 2/2] USB: serial: Another Infineon flash loader USB ID

[Jonas Jonsson]

The flash loader has been seen on a Telit UE910 modem. The flash loader
is a bit special, it presents both an ACM and CDC Data interface but
only the latter is useful. Unless a magic string is sent to the device
it will disappear and the regular modem device appears instead.

Signed-off-by: Jonas Jonsson 
Tested-by: Daniele Palmas 
---
 drivers/usb/serial/usb-serial-simple.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/serial/usb-serial-simple.c 
b/drivers/usb/serial/usb-serial-simple.c
index 3658662..6783cf8 100644
--- a/drivers/usb/serial/usb-serial-simple.c
+++ b/drivers/usb/serial/usb-serial-simple.c
@@ -53,7 +53,9 @@ DEVICE(funsoft, FUNSOFT_IDS);
 
 /* Infineon Flashloader driver */
 #define FLASHLOADER_IDS()  \
-   { USB_DEVICE(0x8087, 0x0716) }
+   { USB_DEVICE(0x8087, 0x0716) }, \
+   { USB_DEVICE_INTERFACE_CLASS(0x058b, 0x0041, USB_CLASS_CDC_DATA) }
+
 DEVICE(flashloader, FLASHLOADER_IDS);
 
 /* Google Serial USB SubClass */
-- 
2.5.0

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

[PATCH v3 1/2] cdc_acm: Ignore Infineon Flash Loader utility

[Jonas Jonsson]

Some modems, such as the Telit UE910, are using an Infineon Flash Loader
utility. It has two interfaces, 2/2/0 (Abstract Modem) and 10/0/0 (CDC
Data). The latter can be used as a serial interface to upgrade the
firmware of the modem. However, that isn't possible when the cdc-acm
driver takes control of the device.

The following is an explanation of the behaviour by Daniele Palmas during
discussion on linux-usb.

"This is what happens when the device is turned on (without modifying
the drivers):

[155492.352031] usb 1-3: new high-speed USB device number 27 using ehci-pci
[155492.485429] usb 1-3: config 1 interface 0 altsetting 0 endpoint 0x81 has an 
invalid bInterval 255, changing to 11
[155492.485436] usb 1-3: New USB device found, idVendor=058b, idProduct=0041
[155492.485439] usb 1-3: New USB device strings: Mfr=0, Product=0, 
SerialNumber=0
[155492.485952] cdc_acm 1-3:1.0: ttyACM0: USB ACM device

This is the flashing device that is caught by the cdc-acm driver. Once
the ttyACM appears, the application starts sending a magic string
(simple write on the file descriptor) to keep the device in flashing
mode. If this magic string is not properly received in a certain time
interval, the modem goes on in normal operative mode:

[155493.748094] usb 1-3: USB disconnect, device number 27
[155494.916025] usb 1-3: new high-speed USB device number 28 using ehci-pci
[155495.059978] usb 1-3: New USB device found, idVendor=1bc7, idProduct=0021
[155495.059983] usb 1-3: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[155495.059986] usb 1-3: Product: 6 CDC-ACM + 1 CDC-ECM
[155495.059989] usb 1-3: Manufacturer: Telit
[155495.059992] usb 1-3: SerialNumber: 359658044004697
[155495.138958] cdc_acm 1-3:1.0: ttyACM0: USB ACM device
[155495.140832] cdc_acm 1-3:1.2: ttyACM1: USB ACM device
[155495.142827] cdc_acm 1-3:1.4: ttyACM2: USB ACM device
[155495.144462] cdc_acm 1-3:1.6: ttyACM3: USB ACM device
[155495.145967] cdc_acm 1-3:1.8: ttyACM4: USB ACM device
[155495.147588] cdc_acm 1-3:1.10: ttyACM5: USB ACM device
[155495.154322] cdc_ether 1-3:1.12 wwan0: register 'cdc_ether' at 
usb-:00:1a.7-3, Mobile Broadband Network Device, 00:00:11:12:13:14

Using the cdc-acm driver, the string, though being sent in the same way
than using the usb-serial-simple driver (I can confirm that the data is
passing properly since I used an hw usb sniffer), does not make the
device to stay in flashing mode."

Signed-off-by: Jonas Jonsson 
Tested-by: Daniele Palmas 
---
 drivers/usb/class/cdc-acm.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index b30e742..26ca4f9 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -1838,6 +1838,11 @@ static const struct usb_device_id acm_ids[] = {
},
 #endif
 
+   /* Exclude Infineon Flash Loader utility */
+   { USB_DEVICE(0x058b, 0x0041),
+   .driver_info = IGNORE_DEVICE,
+   },
+
/* control interfaces without any protocol set */
{ USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_ACM,
USB_CDC_PROTO_NONE) },
-- 
2.5.0

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

[PATCH v3 0/2] cdc_acm: Ignore Infineon Flash Loader utility

[Jonas Jonsson]

In v3:
 - Better explanation of the device behaviour in the commit message.
 - Use USB_CLASS_CDC_DATA instead of 0x0a.

In v2:
 - Include Tested-by: Daniele Palmas .

--
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: [linux-sunxi] [PATCH 2/5] phy-sun4i-usb: Add support for the host usb-phys found on the H3 SoC

[Hans de Goede]

Hi,

On 11/20/2015 08:49 PM, Priit Laes wrote:

On Sun, 2015-11-15 at 20:46 +0100, Hans de Goede wrote:

From: Reinder de Haan 

Note this commit only adds support for phys 1-3, phy 0, the otg phy,
is
not yet (fully) supported after this commit.



This patch seems to be causing following compile warning:

In file included from include/linux/io.h:25:0,
  from drivers/phy/phy-sun4i-usb.c:28:
drivers/phy/phy-sun4i-usb.c: In function 'sun4i_usb_phy_write': 
./arch/arm/include/asm/io.h:94:2: warning: 'phyctl' may be used uninitialized 
in this function [-Wmaybe-uni
nitialized]
   asm volatile("strb %1, %0"
   ^
drivers/phy/phy-sun4i-usb.c:172:8: note: 'phyctl' was declared here
   void *phyctl;


Good catch, thanks the "break;" after the dev_err for the h3 case should be a 
return (this is a dead code path,
the dev_err is there to avoid people trying to actually use 
sun4i_usb_phy_write() with the h3 in
the future).

v2 of this patch fixing this is on its way.

Regards,

Hans






Signed-off-by: Reinder de Haan 
Signed-off-by: Hans de Goede 
---
  .../devicetree/bindings/phy/sun4i-usb-phy.txt  |  1 +
  drivers/phy/phy-sun4i-usb.c| 67
+-
  2 files changed, 53 insertions(+), 15 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
index 0cebf74..95736d7 100644
--- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
+++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
@@ -9,6 +9,7 @@ Required properties:
* allwinner,sun7i-a20-usb-phy
* allwinner,sun8i-a23-usb-phy
* allwinner,sun8i-a33-usb-phy
+  * allwinner,sun8i-h3-usb-phy
  - reg : a list of offset + length pairs
  - reg-names :
* "phy_ctrl"
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-
usb.c
index b12964b..17f97ab 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -46,6 +46,9 @@
  #define REG_PHYBIST   0x08
  #define REG_PHYTUNE   0x0c
  #define REG_PHYCTL_A330x10
+#define REG_PHY_UNK_H3 0x20
+
+#define REG_PMU_UNK_H3 0x10

  #define PHYCTL_DATA   BIT(7)

@@ -79,7 +82,7 @@
  #define PHY_DISCON_TH_SEL 0x2a
  #define PHY_SQUELCH_DETECT0x3c

-#define MAX_PHYS   3
+#define MAX_PHYS   4

  /*
   * Note do not raise the debounce time, we must report Vusb high
within 100ms
@@ -88,12 +91,19 @@
  #define DEBOUNCE_TIME msecs_to_jiffies(50)
  #define POLL_TIME msecs_to_jiffies(250)

+enum sun4i_usb_phy_type {
+   sun4i_a10_phy,
+   sun8i_a33_phy,
+   sun8i_h3_phy
+};
+
  struct sun4i_usb_phy_data {
+   struct device *dev;
void __iomem *base;
struct mutex mutex;
int num_phys;
u32 disc_thresh;
-   bool has_a33_phyctl;
+   enum sun4i_usb_phy_type type;
struct sun4i_usb_phy {
struct phy *phy;
void __iomem *pmu;
@@ -164,12 +174,18 @@ static void sun4i_usb_phy_write(struct
sun4i_usb_phy *phy, u32 addr, u32 data,

mutex_lock(_data->mutex);

-   if (phy_data->has_a33_phyctl) {
+   switch (phy_data->type) {
+   case sun4i_a10_phy:
+   phyctl = phy_data->base + REG_PHYCTL_A10;
+   break;
+   case sun8i_a33_phy:
phyctl = phy_data->base + REG_PHYCTL_A33;
/* A33 needs us to set phyctl to 0 explicitly */
writel(0, phyctl);
-   } else {
-   phyctl = phy_data->base + REG_PHYCTL_A10;
+   break;
+   case sun8i_h3_phy:
+   dev_err(phy_data->dev, "H3 usb_phy_write is not
supported\n");
+   break;
}

for (i = 0; i < len; i++) {
@@ -230,6 +246,7 @@ static int sun4i_usb_phy_init(struct phy *_phy)
struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
struct sun4i_usb_phy_data *data =
to_sun4i_usb_phy_data(phy);
int ret;
+   u32 val;

ret = clk_prepare_enable(phy->clk);
if (ret)
@@ -241,15 +258,26 @@ static int sun4i_usb_phy_init(struct phy *_phy)
return ret;
}

-   /* Enable USB 45 Ohm resistor calibration */
-   if (phy->index == 0)
-   sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
+   if (data->type == sun8i_h3_phy) {
+   if (phy->index == 0) {
+   val = readl(data->base + REG_PHY_UNK_H3);
+   writel(val & ~1, data->base +
REG_PHY_UNK_H3);
+   }
+
+   val = readl(phy->pmu + REG_PMU_UNK_H3);
+   writel(val & ~2, phy->pmu + REG_PMU_UNK_H3);
+   } else {
+   /* Enable USB 45 Ohm resistor calibration */
+   if (phy->index == 0)
+  

[PATCH v2] phy-sun4i-usb: Add support for the host usb-phys found on the H3 SoC

[Hans de Goede]

From: Reinder de Haan 

Note this commit only adds support for phys 1-3, phy 0, the otg phy, is
not yet (fully) supported after this commit.

Signed-off-by: Reinder de Haan 
Signed-off-by: Hans de Goede 
---
Changes in v2:
-Change break; after dev_err() to return, as intended, fixing a compiler
 warning (the dev_err case should never be reached).
---
 .../devicetree/bindings/phy/sun4i-usb-phy.txt  |  1 +
 drivers/phy/phy-sun4i-usb.c| 67 +-
 2 files changed, 53 insertions(+), 15 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt 
b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
index 0cebf74..95736d7 100644
--- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
+++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
@@ -9,6 +9,7 @@ Required properties:
   * allwinner,sun7i-a20-usb-phy
   * allwinner,sun8i-a23-usb-phy
   * allwinner,sun8i-a33-usb-phy
+  * allwinner,sun8i-h3-usb-phy
 - reg : a list of offset + length pairs
 - reg-names :
   * "phy_ctrl"
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index b12964b..11bc9cd 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -46,6 +46,9 @@
 #define REG_PHYBIST0x08
 #define REG_PHYTUNE0x0c
 #define REG_PHYCTL_A33 0x10
+#define REG_PHY_UNK_H3 0x20
+
+#define REG_PMU_UNK_H3 0x10
 
 #define PHYCTL_DATABIT(7)
 
@@ -79,7 +82,7 @@
 #define PHY_DISCON_TH_SEL  0x2a
 #define PHY_SQUELCH_DETECT 0x3c
 
-#define MAX_PHYS   3
+#define MAX_PHYS   4
 
 /*
  * Note do not raise the debounce time, we must report Vusb high within 100ms
@@ -88,12 +91,19 @@
 #define DEBOUNCE_TIME  msecs_to_jiffies(50)
 #define POLL_TIME  msecs_to_jiffies(250)
 
+enum sun4i_usb_phy_type {
+   sun4i_a10_phy,
+   sun8i_a33_phy,
+   sun8i_h3_phy
+};
+
 struct sun4i_usb_phy_data {
+   struct device *dev;
void __iomem *base;
struct mutex mutex;
int num_phys;
u32 disc_thresh;
-   bool has_a33_phyctl;
+   enum sun4i_usb_phy_type type;
struct sun4i_usb_phy {
struct phy *phy;
void __iomem *pmu;
@@ -164,12 +174,18 @@ static void sun4i_usb_phy_write(struct sun4i_usb_phy 
*phy, u32 addr, u32 data,
 
mutex_lock(_data->mutex);
 
-   if (phy_data->has_a33_phyctl) {
+   switch (phy_data->type) {
+   case sun4i_a10_phy:
+   phyctl = phy_data->base + REG_PHYCTL_A10;
+   break;
+   case sun8i_a33_phy:
phyctl = phy_data->base + REG_PHYCTL_A33;
/* A33 needs us to set phyctl to 0 explicitly */
writel(0, phyctl);
-   } else {
-   phyctl = phy_data->base + REG_PHYCTL_A10;
+   break;
+   case sun8i_h3_phy:
+   dev_err(phy_data->dev, "H3 usb_phy_write is not supported\n");
+   return;
}
 
for (i = 0; i < len; i++) {
@@ -230,6 +246,7 @@ static int sun4i_usb_phy_init(struct phy *_phy)
struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
int ret;
+   u32 val;
 
ret = clk_prepare_enable(phy->clk);
if (ret)
@@ -241,15 +258,26 @@ static int sun4i_usb_phy_init(struct phy *_phy)
return ret;
}
 
-   /* Enable USB 45 Ohm resistor calibration */
-   if (phy->index == 0)
-   sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
+   if (data->type == sun8i_h3_phy) {
+   if (phy->index == 0) {
+   val = readl(data->base + REG_PHY_UNK_H3);
+   writel(val & ~1, data->base + REG_PHY_UNK_H3);
+   }
+
+   val = readl(phy->pmu + REG_PMU_UNK_H3);
+   writel(val & ~2, phy->pmu + REG_PMU_UNK_H3);
+   } else {
+   /* Enable USB 45 Ohm resistor calibration */
+   if (phy->index == 0)
+   sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
 
-   /* Adjust PHY's magnitude and rate */
-   sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);
+   /* Adjust PHY's magnitude and rate */
+   sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);
 
-   /* Disconnect threshold adjustment */
-   sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL, data->disc_thresh, 2);
+   /* Disconnect threshold adjustment */
+   sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL,
+   data->disc_thresh, 2);
+   }
 
sun4i_usb_phy_passby(phy, 1);
 
@@ -522,11 +550,14 @@ static int sun4i_usb_phy_probe(struct 

Re: [4.3] kworker busy in pm_runtime_work

[Daniel J Blueman]

On 16 November 2015 at 23:22, Alan Stern  wrote:
> On Mon, 16 Nov 2015, Daniel J Blueman wrote:
>
>> Tuning USB suspend [1] in 4.3 on a Dell XPS 15 9553 (Skylake), I see a
>> kworker thread spinning in rpm_suspend [2].
>>
>> What is the most useful debug to get here beyond the immediate [3]?
>
> You can try doing:
>
> echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control

kworker and ksoftirqd spinning occurs when I echo 'auto' to all the
USB control entries. Using Alan's excellent tip, we see this being
logged repeatedly at a high rate:
[  353.245180] usb usb1-port4: status 0107 change 
[  353.245194] usb usb1-port12: status 0507 change 
[  353.245202] hub 1-0:1.0: state 7 ports 16 chg  evt 
[  353.245203] hub 1-0:1.0: hub_suspend
[  353.245205] usb usb1: bus auto-suspend, wakeup 1
[  353.245206] usb usb1: bus suspend fail, err -16
[  353.245207] hub 1-0:1.0: hub_resume
...

So, EBUSY. Both the webcam is not open, and the bluetooth interface
[1] is rfkill'd; the situation occurs even if I unload all related
modules.

What further debug would be useful?

Thanks!
  Daniel

-- [1]

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 0a5c:6410 Broadcom Corp.
Bus 001 Device 003: ID 1bcf:2b95 Sunplus Innovation Technology Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
-- 
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/5] Implement an ioctl to support the USMTMC-USB488 READ_STATUS_BYTE operation.

[Dave Penkler]

On Wed, Nov 18, 2015 at 11:55:27AM +0200, Andy Shevchenko wrote:
> On Wed, Nov 18, 2015 at 10:37 AM, Dave Penkler  wrote:
> > Background:
> > When performing a read on an instrument that is executing a function
> > that runs longer than the USB timeout the instrument may hang and
> > require a device reset to recover. The READ_STATUS_BYTE operation
> > always returns even when the instrument is busy permitting to poll
> > for the appropriate condition. This capability is referred to in
> > instrument application notes on synchronizing acquisitions for other
> > platforms.
> >
> 
> First of all, please be patient and do not send patches immediately
> when you answered to someone's review. It increases redundant noise
> and burden on reviewer. Wait at least for 24h especially if there are
> topics still to discuss.
> 

OK, apologies.

snip

> > +
> > +   switch (status) {
> > +   case 0: /* SUCCESS */
> > +   if (data->iin_buffer[0] & 0x80) {
> > +   /* check for valid STB notification */
> > +   if ((data->iin_buffer[0] & 0x7f) > 1) {
> 
> Despite your answer to my comment code is quite understandable even with & 
> 0x7e.
> You already put comment line about this, you may add that you validate
> the value to be 127 >= value >= 2.
> 

Yes it is quite understandable but it is less clear. I repeat my comment here:
When reading the spec and the code it is more obvious that here
we are testing for the value in bits D6..D0 to be a valid iin_bTag return.
(See Table 7 in the USBTMC-USB488 spec.)

What is your motivation for

 if (data->iin_buffer[0] & 0x7e)

?

> > +   data->bNotify1 = data->iin_buffer[0];
> > +   data->bNotify2 = data->iin_buffer[1];
> > +   atomic_set(>iin_data_valid, 1);
> > +   wake_up_interruptible(>waitq);
> > +   goto exit;
> > +   }
> > +   }

snip

> > +   /* urb terminated, clean up */
> > +   dev_dbg(>intf->dev,
> > +   "%s - urb terminated, status: %d\n",
> > +   __func__, status);
> 
> No need to print function here explicitly. Check Dynamic Debug framework.

I am not using dynamic debug but when I enable static debug I get:

[ 1438.562458] usbtmc 1-1:1.0: Enter ioctl_read_stb iin_ep_present: 1

on the console log for
 
dev_dbg(dev, "Enter ioctl_read_stb iin_ep_present: %d\n",
data->iin_ep_present);

So if I don't print the function it does not appear on the log.

> 
> > +   return;
> > +   default:
> > +   dev_err(>intf->dev,
> > +   "%s - unknown status received: %d\n",
> > +   __func__, status);
> > +   }
> > +exit:
> > +   rv = usb_submit_urb(urb, GFP_ATOMIC);
> > +   if (rv) {
> > +   dev_err(>intf->dev, "%s - usb_submit_urb failed: 
> > %d\n",
> > +   __func__, rv);
> > +   }
> > +}

snip

> > +
> > +   /* fill interrupt urb */
> > +   usb_fill_int_urb(data->iin_urb, data->usb_dev,
> > +   usb_rcvintpipe(data->usb_dev, data->iin_ep),
> > +   data->iin_buffer, data->iin_wMaxPacketSize,
> > +   usbtmc_interrupt,
> > +   data, data->iin_interval);
> > +
> > +   if (usb_submit_urb(data->iin_urb, GFP_KERNEL)) {
> 
> Does it return a proper error code?
> 

Yes, will propagate it.

> > +   retcode = -EIO;
> > +   dev_err(>dev, "Failed to submit iin_urb\n");
> > +   goto error_register;
> > +   }
> > +   }
> > +
> 
> > retcode = sysfs_create_group(>dev.kobj, _attr_grp);
> >
> > retcode = usb_register_dev(intf, _class);
> 
> Hmm??? Unrelated to this patch, but notice that retcode is overridden here.
> 
> 
> > @@ -1185,6 +1395,7 @@ static int usbtmc_probe(struct usb_interface *intf,
> >  error_register:
> > sysfs_remove_group(>dev.kobj, _attr_grp);
> > sysfs_remove_group(>dev.kobj, _attr_grp);
> > +   usbtmc_free_int(data);
> > kref_put(>kref, usbtmc_delete);
> > return retcode;
> >  }
> 
> 
> -- 
> With Best Regards,
> Andy Shevchenko
cheers,
-Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/5] Implement an ioctl to support the USMTMC-USB488 READ_STATUS_BYTE operation.

[Andy Shevchenko]

On Sun, Nov 22, 2015 at 11:19 AM, Dave Penkler  wrote:
> On Wed, Nov 18, 2015 at 11:55:27AM +0200, Andy Shevchenko wrote:
>> On Wed, Nov 18, 2015 at 10:37 AM, Dave Penkler  wrote:

>> > +   switch (status) {
>> > +   case 0: /* SUCCESS */
>> > +   if (data->iin_buffer[0] & 0x80) {
>> > +   /* check for valid STB notification */
>> > +   if ((data->iin_buffer[0] & 0x7f) > 1) {
>>
>> Despite your answer to my comment code is quite understandable even with & 
>> 0x7e.
>> You already put comment line about this, you may add that you validate
>> the value to be 127 >= value >= 2.
>>
>
> Yes it is quite understandable but it is less clear. I repeat my comment here:
> When reading the spec and the code it is more obvious that here
> we are testing for the value in bits D6..D0 to be a valid iin_bTag return.
> (See Table 7 in the USBTMC-USB488 spec.)
>
> What is your motivation for
>
>  if (data->iin_buffer[0] & 0x7e)
>
> ?

In non-optimized variant it will certainly generate less code. You may
have check assembly code with -O2 and compare. I don't know if
compiler is clever enough to do the same by itself.

>> > +   /* urb terminated, clean up */
>> > +   dev_dbg(>intf->dev,
>> > +   "%s - urb terminated, status: %d\n",
>> > +   __func__, status);
>>
>> No need to print function here explicitly. Check Dynamic Debug framework.
>
> I am not using dynamic debug but when I enable static debug I get:
>
> [ 1438.562458] usbtmc 1-1:1.0: Enter ioctl_read_stb iin_ep_present: 1
>
> on the console log for
>
> dev_dbg(dev, "Enter ioctl_read_stb iin_ep_present: %d\n",
> data->iin_ep_present);
>
> So if I don't print the function it does not appear on the log.

Whatever maintainers prefer, though I think there are quite rare cases
in USB when someone needs static debug. I'm pretty sure most of the
developers all in favour of dynamic debug.

>> > retcode = sysfs_create_group(>dev.kobj, _attr_grp);
>> >
>> > retcode = usb_register_dev(intf, _class);
>>
>> Hmm??? Unrelated to this patch, but notice that retcode is overridden here.



-- 
With Best Regards,
Andy Shevchenko
--
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: [Linux USB] enable/disable individual ports

[Peter Stuge]

Alan Stern wrote:
> It does print out a message, though not a big one.  Would you like it
> to do something more specific?  A more verbose "usage" message,
> perhaps?

That's a good idea, and additionally I think it would be important to
print (much) more information if the ioctl() fails.


> For convenience, the source code is included below.

Please keep in mind that the rest of usbutils is generally quite
portable while this new utility is not, so if it is included it
should probably not be built unless for Linux host systems.


//Peter
--
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: Not enough host controller resources for new device state

[Peter Stuge]

Patrick Shirkey wrote:
> > if the kernel does have support for xHCI, we assume that
> > the user will prefer xHCI over EHCI if the motherboard has xHCI.
> 
> Obviously the solution above should suffice for my purposes but out
> of interest is it viable to make the switch accessible to run time
> configuration?

I don't think it makes sense to expose the port routing to user
space, but I think it would make sense to route ports to the EHCI HC(s)
when xhci-hcd is unbound, and vice versa.

I'm not sure what the best implementation for this would be. Would it
be possible for ehci-hcd to call into xhci-hcd code, even if xhci-hcd
is not currently bound anywhere?

One possibility is to add code to both drivers which gets called on
unbind and which routes ports to the respective other controller type,
but that doesn't really seem like a great solution. It would be nicer
to have a single entry point for the (re)routing.

Alan, what are your thoughts on that?


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

[GIT PULL] USB driver fixes for 4.4-rc2

[Greg KH]

The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:

  Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-4.4-rc2

for you to fetch changes up to 19cd80a214821f4b558560ebd76bfb2c38b4f3d8:

  usblp: do not set TASK_INTERRUPTIBLE before lock (2015-11-19 16:31:42 -0800)


USB fixes for 4.4-rc2

Here are a number of USB fixes and new device ids for 4.4-rc2.  All have
been in linux-next and the details are in the shortlog.

Signed-off-by: Greg Kroah-Hartman 


Aaro Koskinen (1):
  usb: phy: omap-otg: fix uninitialized pointer

Aleksander Morgado (1):
  USB: serial: option: add support for Novatel MiFi USB620L

Ben McCauley (1):
  usb: dwc3: gadget: let us set lower max_speed

Bin Liu (2):
  usb: musb: fix tx fifo flush handling
  usb: musb: enable usb_dma parameter

Bjørn Mork (2):
  USB: qcserial: Fix support for HP lt4112 LTE/HSPA+ Gobi 4G Modem
  USB: option: add XS Stick W100-2 from 4G Systems

David Woodhouse (1):
  USB: ti_usb_3410_5052: Add Honeywell HGI80 ID

Douglas Anderson (2):
  usb: dwc2: host: Fix ahbcfg for rk3066
  usb: dwc2: host: Fix remote wakeup when not in DWC2_L2

Douglas Gilbert (1):
  usb: gadget: atmel_usba_udc: Expose correct device speed

Greg Kroah-Hartman (3):
  Merge tag 'fixes-for-v4.4-rc2' of git://git.kernel.org/.../balbi/usb into 
usb-linus
  Merge tag 'usb-ci-v4.4-rc2' of git://git.kernel.org/.../peter.chen/usb 
into usb-linus
  Merge tag 'usb-serial-4.4-rc2' of 
git://git.kernel.org/.../johan/usb-serial into usb-linus

Heikki Krogerus (1):
  usb: dwc3: pci: add support for Intel Broxton SOC

Jiri Slaby (1):
  usblp: do not set TASK_INTERRUPTIBLE before lock

LABBE Corentin (3):
  usb: phy: phy-mxs-usb: fix a possible NULL dereference
  usb: chipidea: usbmisc_imx: fix a possible NULL dereference
  usb: chipidea: imx: fix a possible NULL dereference

Li Jun (2):
  usb: chipidea: debug: disable usb irq while role switch
  usb: chipidea: otg: gadget module load and unload support

Lu Baolu (1):
  usb: xhci: fix checking ep busy for CFC

Mathias Nyman (1):
  xhci: Fix a race in usb2 LPM resume, blocking U3 for usb2 devices

Peter Chen (4):
  usb: gadget: f_loopback: fix the warning during the enumeration
  usb: chipidea: imx: refine clock operations to adapt for all platforms
  ARM: dts: imx27.dtsi: change the clock information for usb
  usb: kconfig: fix warning of select USB_OTG

Petr Štetiar (1):
  USB: qcserial: Add support for Quectel EC20 Mini PCIe module

Rajmohan Mani (1):
  xhci: Workaround to get Intel xHCI reset working more reliably

Simon Arlott (1):
  USB: MAINTAINERS: cxacru

Uwe Kleine-König (1):
  usb: musb: core: fix order of arguments to ulpi write callback

 MAINTAINERS  |   3 +-
 arch/arm/boot/dts/imx27.dtsi |  16 +++-
 drivers/usb/chipidea/ci_hdrc_imx.c   | 142 ++-
 drivers/usb/chipidea/debug.c |   2 +
 drivers/usb/chipidea/udc.c   |  17 
 drivers/usb/chipidea/usbmisc_imx.c   |  10 ++-
 drivers/usb/class/usblp.c|   2 +-
 drivers/usb/core/Kconfig |   3 +-
 drivers/usb/dwc2/hcd.c   |   9 +-
 drivers/usb/dwc2/platform.c  |   3 +-
 drivers/usb/dwc3/dwc3-pci.c  |   4 +
 drivers/usb/dwc3/gadget.c|  24 +-
 drivers/usb/gadget/function/f_loopback.c |   2 +-
 drivers/usb/gadget/udc/atmel_usba_udc.c  |   2 +-
 drivers/usb/host/xhci-hub.c  |  15 ++--
 drivers/usb/host/xhci-ring.c |  32 ++-
 drivers/usb/host/xhci.c  |  10 +++
 drivers/usb/musb/musb_core.c |  12 +--
 drivers/usb/musb/musb_host.c |  22 +++--
 drivers/usb/phy/Kconfig  |   4 +-
 drivers/usb/phy/phy-mxs-usb.c|   7 +-
 drivers/usb/phy/phy-omap-otg.c   |   2 +-
 drivers/usb/serial/option.c  |  11 +++
 drivers/usb/serial/qcserial.c|  94 +++-
 drivers/usb/serial/ti_usb_3410_5052.c|   2 +
 drivers/usb/serial/ti_usb_3410_5052.h|   4 +
 26 files changed, 342 insertions(+), 112 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Linux USB] enable/disable individual ports

[Greg KH]

On Sun, Nov 22, 2015 at 07:26:08PM +0100, Peter Stuge wrote:
> Alan Stern wrote:
> > It does print out a message, though not a big one.  Would you like it
> > to do something more specific?  A more verbose "usage" message,
> > perhaps?
> 
> That's a good idea, and additionally I think it would be important to
> print (much) more information if the ioctl() fails.

I agree.

> > For convenience, the source code is included below.
> 
> Please keep in mind that the rest of usbutils is generally quite
> portable while this new utility is not, so if it is included it
> should probably not be built unless for Linux host systems.

That's up to those who wish to repackage usbutils for other operating
systems, not "upstream" :)

thanks,

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

Re: [PATCH v4 1/3] Documentation: dt-bindings: add async_irq to msm_hsusb

[Rob Herring]

On Fri, Nov 20, 2015 at 03:47:18PM -0800, Tim Bird wrote:
> Add optional async_irq to msm_hsusb binding doc.
> 
> Signed-off-by: Tim Bird 

Acked-by: Rob Herring 

> ---
>  Documentation/devicetree/bindings/usb/msm-hsusb.txt | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/msm-hsusb.txt 
> b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
> index 8654a3e..2d13c1c 100644
> --- a/Documentation/devicetree/bindings/usb/msm-hsusb.txt
> +++ b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
> @@ -23,7 +23,12 @@ Required properties:
>"qcom,usb-otg-snps" for chipsets with Synopsys 28nm PHY
>  
>  - regs: Offset and length of the register set in the memory map
> -- interrupts:   interrupt-specifier for the OTG interrupt.
> +- interrupts:   interrupt-specifier for the OTG interrupts
> +
> +- interrupt-names: Should contain the following:
> +  "core"USB core interrupt
> +  "async"   Asynchronous interrupt to wake up from low power mode
> +(optional)
>  
>  - clocks:   A list of phandle + clock-specifier pairs for the
>  clocks listed in clock-names
> @@ -89,7 +94,8 @@ Example HSUSB OTG controller device node:
>  usb@f9a55000 {
>  compatible = "qcom,usb-otg-snps";
>  reg = <0xf9a55000 0x400>;
> -interrupts = <0 134 0>;
> +interrupts = <0 134 0>, <0 140 0>;
> +interrupt-names = "core", "async";
>  dr_mode = "peripheral";
>  
>  clocks = < GCC_XO_CLK>, < GCC_USB_HS_SYSTEM_CLK>,
> -- 
> 1.8.2.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] phy-sun4i-usb: Add support for the host usb-phys found on the H3 SoC

[Rob Herring]

On Sun, Nov 22, 2015 at 12:29:24PM +0100, Hans de Goede wrote:
> From: Reinder de Haan 
> 
> Note this commit only adds support for phys 1-3, phy 0, the otg phy, is
> not yet (fully) supported after this commit.
> 
> Signed-off-by: Reinder de Haan 
> Signed-off-by: Hans de Goede 
> ---
> Changes in v2:
> -Change break; after dev_err() to return, as intended, fixing a compiler
>  warning (the dev_err case should never be reached).
> ---
>  .../devicetree/bindings/phy/sun4i-usb-phy.txt  |  1 +

For the binding:

Acked-by: Rob Herring 

>  drivers/phy/phy-sun4i-usb.c| 67 
> +-
>  2 files changed, 53 insertions(+), 15 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt 
> b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> index 0cebf74..95736d7 100644
> --- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> @@ -9,6 +9,7 @@ Required properties:
>* allwinner,sun7i-a20-usb-phy
>* allwinner,sun8i-a23-usb-phy
>* allwinner,sun8i-a33-usb-phy
> +  * allwinner,sun8i-h3-usb-phy
>  - reg : a list of offset + length pairs
>  - reg-names :
>* "phy_ctrl"
> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
> index b12964b..11bc9cd 100644
> --- a/drivers/phy/phy-sun4i-usb.c
> +++ b/drivers/phy/phy-sun4i-usb.c
> @@ -46,6 +46,9 @@
>  #define REG_PHYBIST  0x08
>  #define REG_PHYTUNE  0x0c
>  #define REG_PHYCTL_A33   0x10
> +#define REG_PHY_UNK_H3   0x20
> +
> +#define REG_PMU_UNK_H3   0x10
>  
>  #define PHYCTL_DATA  BIT(7)
>  
> @@ -79,7 +82,7 @@
>  #define PHY_DISCON_TH_SEL0x2a
>  #define PHY_SQUELCH_DETECT   0x3c
>  
> -#define MAX_PHYS 3
> +#define MAX_PHYS 4
>  
>  /*
>   * Note do not raise the debounce time, we must report Vusb high within 100ms
> @@ -88,12 +91,19 @@
>  #define DEBOUNCE_TIMEmsecs_to_jiffies(50)
>  #define POLL_TIMEmsecs_to_jiffies(250)
>  
> +enum sun4i_usb_phy_type {
> + sun4i_a10_phy,
> + sun8i_a33_phy,
> + sun8i_h3_phy
> +};
> +
>  struct sun4i_usb_phy_data {
> + struct device *dev;
>   void __iomem *base;
>   struct mutex mutex;
>   int num_phys;
>   u32 disc_thresh;
> - bool has_a33_phyctl;
> + enum sun4i_usb_phy_type type;
>   struct sun4i_usb_phy {
>   struct phy *phy;
>   void __iomem *pmu;
> @@ -164,12 +174,18 @@ static void sun4i_usb_phy_write(struct sun4i_usb_phy 
> *phy, u32 addr, u32 data,
>  
>   mutex_lock(_data->mutex);
>  
> - if (phy_data->has_a33_phyctl) {
> + switch (phy_data->type) {
> + case sun4i_a10_phy:
> + phyctl = phy_data->base + REG_PHYCTL_A10;
> + break;
> + case sun8i_a33_phy:
>   phyctl = phy_data->base + REG_PHYCTL_A33;
>   /* A33 needs us to set phyctl to 0 explicitly */
>   writel(0, phyctl);
> - } else {
> - phyctl = phy_data->base + REG_PHYCTL_A10;
> + break;
> + case sun8i_h3_phy:
> + dev_err(phy_data->dev, "H3 usb_phy_write is not supported\n");
> + return;
>   }
>  
>   for (i = 0; i < len; i++) {
> @@ -230,6 +246,7 @@ static int sun4i_usb_phy_init(struct phy *_phy)
>   struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
>   struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
>   int ret;
> + u32 val;
>  
>   ret = clk_prepare_enable(phy->clk);
>   if (ret)
> @@ -241,15 +258,26 @@ static int sun4i_usb_phy_init(struct phy *_phy)
>   return ret;
>   }
>  
> - /* Enable USB 45 Ohm resistor calibration */
> - if (phy->index == 0)
> - sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
> + if (data->type == sun8i_h3_phy) {
> + if (phy->index == 0) {
> + val = readl(data->base + REG_PHY_UNK_H3);
> + writel(val & ~1, data->base + REG_PHY_UNK_H3);
> + }
> +
> + val = readl(phy->pmu + REG_PMU_UNK_H3);
> + writel(val & ~2, phy->pmu + REG_PMU_UNK_H3);
> + } else {
> + /* Enable USB 45 Ohm resistor calibration */
> + if (phy->index == 0)
> + sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
>  
> - /* Adjust PHY's magnitude and rate */
> - sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);
> + /* Adjust PHY's magnitude and rate */
> + sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);
>  
> - /* Disconnect threshold adjustment */
> - sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL, data->disc_thresh, 2);
> + /*