date:20160712

Re: [PATCH v6 RESEND] r8152: Add support for setting pass through MAC address on RTL8153-AD

2016-07-12 Thread Michał Pecio

> From: Mario Limonciello 
> Date: Mon, 11 Jul 2016 19:58:04 -0500
> 
> > The RTL8153-AD supports a persistent system specific MAC address.
> > This means a device plugged into two different systems with host
> > side support will show different (but persistent) MAC addresses.
> > 
> > This information for the system's persistent MAC address is burned
> > in when the system HW is built and available under \_SB.AMAC in the
> > DSDT at runtime.
> > 
> > This technology is currently implemented in the Dell TB15 and WD15
> > Type-C docks.  More information is available here:
> > http://www.dell.com/support/article/us/en/04/SLN301147
> > 
> > Signed-off-by: Mario Limonciello   
> 
> Applied.

Hi,

Isn't it possible that the same ACPI name could be used for other
vendor-specific extensions on other laptops and that r8152 will now
wreak havoc there?

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

Re: Problem getting USB DAC to work

2016-07-12 Thread John Westwood

Thanks Alan, I will do that :-)



--
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: usb-serial remembers termios settings between device replugs

2016-07-12 Thread Jan Kundrát


On Tuesday, 12 July 2016 01:50:59 CEST, Greg KH wrote:

There is, as far as I can tell, no set of "default" termios values for
any type of serial port, so the "last" set of them is as good as any,
right?


Each driver specifies an initial value 
(usb_serial_tty_driver->init_termios), and this value is not applied in 
this case.



So this should be the same for any type of serial port you can
remove/add from the system, right?


It seems so -- as long as the driver itself is not unloaded. That comes as 
a surprise to me. If it's a feature that these settings are supposed to be 
persistent, then IMHO they should be really saved somewhere across reboots. 
Right now, a module reload throws them away which suggests that the 
persistency spanning a device disconnect is only a side-effect of the 
intended persistency over open()/close() cycle.


Cheers,
Jan
--
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] scsi: introduce a quirk for false cache reporting

2016-07-12 Thread Oliver Neukum

Some SATA to USB bridges fail to cooperate with some
drives resulting in no cache being present being reported
to the host. That causes the host to skip sending
a command to synchronize caches. That causes data loss
when the drive is powered down.

Signed-off-by: Oliver Neukum 
---
 Documentation/kernel-parameters.txt | 2 ++
 drivers/scsi/sd.c   | 6 +++---
 drivers/usb/storage/scsiglue.c  | 4 
 drivers/usb/storage/usb.c   | 6 +-
 include/linux/usb_usual.h   | 2 ++
 include/scsi/scsi_device.h  | 1 +
 6 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 82b42c9..c8c682e 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -4182,6 +4182,8 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
u = IGNORE_UAS (don't bind to the uas driver);
w = NO_WP_DETECT (don't test whether the
medium is write-protected).
+   y = ALWAYS_SYNC (issue a SYNCHRONIZE_CACHE
+   even if the device claims no cache)
Example: quirks=0419:aaf5:rl,0421:0433:rc
 
user_debug= [KNL,ARM]
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 60bff78..3e8a6f1 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -139,7 +139,7 @@ static void sd_set_flush_flag(struct scsi_disk *sdkp)
 {
bool wc = false, fua = false;
 
-   if (sdkp->WCE) {
+   if (sdkp->WCE || sdkp->device->always_sync) {
wc = true;
if (sdkp->DPOFUA)
fua = true;
@@ -3228,7 +3228,7 @@ static void sd_shutdown(struct device *dev)
if (pm_runtime_suspended(dev))
return;
 
-   if (sdkp->WCE && sdkp->media_present) {
+   if ((sdkp->WCE || sdkp->device->always_sync) && sdkp->media_present)  {
sd_printk(KERN_NOTICE, sdkp, "Synchronizing SCSI cache\n");
sd_sync_cache(sdkp);
}
@@ -3247,7 +3247,7 @@ static int sd_suspend_common(struct device *dev, bool 
ignore_stop_errors)
if (!sdkp)  /* E.g.: runtime suspend following sd_remove() */
return 0;
 
-   if (sdkp->WCE && sdkp->media_present) {
+   if ((sdkp->WCE || sdkp->device->always_sync) && sdkp->media_present) {
sd_printk(KERN_NOTICE, sdkp, "Synchronizing SCSI cache\n");
ret = sd_sync_cache(sdkp);
if (ret) {
diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
index 33eb923..43e76ae 100644
--- a/drivers/usb/storage/scsiglue.c
+++ b/drivers/usb/storage/scsiglue.c
@@ -296,6 +296,10 @@ static int slave_configure(struct scsi_device *sdev)
if (us->fflags & US_FL_BROKEN_FUA)
sdev->broken_fua = 1;
 
+   /* Some even totally fail to indicate a cache */
+   if (us->fflags & US_FL_ALWAYS_SYNC)
+   sdev->always_sync = 1;
+
} else {
 
/*
diff --git a/drivers/usb/storage/usb.c b/drivers/usb/storage/usb.c
index ef2d8cd..19255f1 100644
--- a/drivers/usb/storage/usb.c
+++ b/drivers/usb/storage/usb.c
@@ -498,7 +498,8 @@ void usb_stor_adjust_quirks(struct usb_device *udev, 
unsigned long *fflags)
US_FL_NO_READ_DISC_INFO | US_FL_NO_READ_CAPACITY_16 |
US_FL_INITIAL_READ10 | US_FL_WRITE_CACHE |
US_FL_NO_ATA_1X | US_FL_NO_REPORT_OPCODES |
-   US_FL_MAX_SECTORS_240 | US_FL_NO_REPORT_LUNS);
+   US_FL_MAX_SECTORS_240 | US_FL_NO_REPORT_LUNS |
+   US_FL_ALWAYS_SYNC);
 
p = quirks;
while (*p) {
@@ -581,6 +582,9 @@ void usb_stor_adjust_quirks(struct usb_device *udev, 
unsigned long *fflags)
case 'w':
f |= US_FL_NO_WP_DETECT;
break;
+   case 'y':
+   f |= US_FL_ALWAYS_SYNC;
+   break;
/* Ignore unrecognized flag characters */
}
}
diff --git a/include/linux/usb_usual.h b/include/linux/usb_usual.h
index 245f57d..0aae1b2 100644
--- a/include/linux/usb_usual.h
+++ b/include/linux/usb_usual.h
@@ -81,6 +81,8 @@
/* Sets max_sectors to 240 */   \
US_FLAG(NO_REPORT_LUNS, 0x1000) \
/* Cannot handle REPORT_LUNS */ \
+   US_FLAG(ALWAYS_SYNC, 0x2000)\
+   /* lies about caching, so always sync */\
 
 #define US_FLAG(name, value)   US_FL_##name = value ,
 enum { US_DO_ALL_FLAGS };
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index a6c346d..392d166 100644
--

RE: [PATCH v2 1/5] drivers: usb: chipidea: Add qoriq platform driver

2016-07-12 Thread Rajesh Bhagat



> -Original Message-
> From: Peter Chen [mailto:hzpeterc...@gmail.com]
> Sent: Monday, July 11, 2016 12:14 PM
> To: Rajesh Bhagat 
> Cc: linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org;
> devicet...@vger.kernel.org; Peter Chen ;
> gre...@linuxfoundation.org; kis...@ti.com; robh...@kernel.org;
> shawn...@kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH v2 1/5] drivers: usb: chipidea: Add qoriq platform driver
> 
> On Sat, Jul 09, 2016 at 10:00:52AM +0530, Rajesh Bhagat wrote:
> > Adds qoriq platform driver for chipidea controller, verfied on LS1021A
> > and LS1012A platforms.
> >
> > Signed-off-by: Rajesh Bhagat 
> > ---
> > Changes in v2:
> >  - Replaced Freescale with QorIQ in comments section
> >  - Added macros to remove hardcoding while programming registers
> >  - Changed the compatible string to fsl,ci-qoriq-usb2 and added
> > version
> >  - Removed calls to devm free/release calls
> >
> >  drivers/usb/chipidea/Makefile|   2 +
> >  drivers/usb/chipidea/ci_hdrc_qoriq.c | 237
> > +++
> >  drivers/usb/chipidea/ci_hdrc_qoriq.h |  65 ++
> >  3 files changed, 304 insertions(+)
> >  create mode 100644 drivers/usb/chipidea/ci_hdrc_qoriq.c
> >  create mode 100644 drivers/usb/chipidea/ci_hdrc_qoriq.h
> >
> > diff --git a/drivers/usb/chipidea/Makefile
> > b/drivers/usb/chipidea/Makefile index 518e445..3122b86b 100644
> > --- a/drivers/usb/chipidea/Makefile
> > +++ b/drivers/usb/chipidea/Makefile
> > @@ -14,3 +14,5 @@ obj-$(CONFIG_USB_CHIPIDEA)+= ci_hdrc_zevio.o
> >  obj-$(CONFIG_USB_CHIPIDEA_PCI) += ci_hdrc_pci.o
> >
> >  obj-$(CONFIG_USB_CHIPIDEA_OF)  += usbmisc_imx.o ci_hdrc_imx.o
> > +
> > +obj-$(CONFIG_USB_CHIPIDEA)  += ci_hdrc_qoriq.o
> > diff --git a/drivers/usb/chipidea/ci_hdrc_qoriq.c
> > b/drivers/usb/chipidea/ci_hdrc_qoriq.c
> > new file mode 100644
> > index 000..3f478c6
> > --- /dev/null
> > +++ b/drivers/usb/chipidea/ci_hdrc_qoriq.c
> > @@ -0,0 +1,237 @@
> > +/*
> > + * QorIQ SoC USB 2.0 Controller driver
> > + *
> > + * Copyright 2016 Freescale Semiconductor, Inc.
> > + * Author: Rajesh Bhagat 
> > + *
> > + * 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 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "ci.h"
> > +#include "ci_hdrc_qoriq.h"
> > +
> > +struct ci_hdrc_qoriq_data {
> > +   struct phy *phy;
> > +   struct clk *clk;
> > +   void __iomem *qoriq_regs;
> > +   struct platform_device *ci_pdev;
> > +   enum usb_phy_interface phy_mode;
> > +};
> > +
> > +/*
> > + * clock helper functions
> > + */
> > +static int ci_hdrc_qoriq_get_clks(struct platform_device *pdev) {
> > +   int ret;
> > +   struct device *dev = &pdev->dev;
> > +   struct ci_hdrc_qoriq_data *data = platform_get_drvdata(pdev);
> > +
> > +   data->clk = devm_clk_get(dev, "usb2-clock");
> > +   if (IS_ERR(data->clk)) {
> > +   dev_err(dev, "failed to get clk, err=%ld\n",
> > +   PTR_ERR(data->clk));
> > +   return ret;

Hello Peter, 

> 
> return PTR_ERR(data->clk), and delete ret.
> 

Will take care in v3. 

> > +   }
> > +   return 0;
> > +}
> > +
> > +static int ci_hdrc_qoriq_prepare_enable_clks(struct platform_device
> > +*pdev) {
> > +   int ret;
> > +   struct device *dev = &pdev->dev;
> > +   struct ci_hdrc_qoriq_data *data = platform_get_drvdata(pdev);
> > +
> > +   ret = clk_prepare_enable(data->clk);
> > +   if (ret) {
> > +   dev_err(dev, "failed to prepare/enable clk, err=%d\n", ret);
> > +   return ret;
> > +   }
> > +   return 0;
> > +}
> > +
> > +static void ci_hdrc_qoriq_disable_unprepare_clks(struct
> > +platform_device *pdev) {
> > +   struct ci_hdrc_qoriq_data *data = platform_get_drvdata(pdev);
> > +
> > +   clk_disable_unprepare(data->clk);
> > +}
> > +
> > +static int ci_hdrc_qoriq_usb_setup(struct platform_device *pdev) {
> > +   u32 reg;
> > +   struct resource *res;
> > +   struct device *dev = &pdev->dev;
> > +   struct ci_hdrc_qoriq_data *data = platform_get_drvdata(pdev);
> > +
> > +   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +   if (!res) {
> > +   dev_err(dev, "failed to get I/O memory\n");
> > +   return -ENOENT;
> > +   }
> > +
> > +   dev_dbg(dev, "res->start %llx, resource_size(res) %llx\n", res->start,
> > +   resource_size(res));
> 
> Delete above debug message please.
> 

Will take care in v3. 

> > +   data->qoriq_regs = devm_ioremap(dev, res->start, resource_size(res));
> > +   if (IS_ERR(data->qoriq_regs)) {
> > +   dev_err(dev, "failed to remap I/O memory\n");
> > +   return -ENOMEM;
> > +   }
> > +
> 
> This mapping will be freed soon, using ioremap instead.
> 

Correct. It is no

[PATCH 1/2] doc: usb: usbmisc-imx: add imx7d compatible string

2016-07-12 Thread Li Jun

Add compatible string for imx7d-usbmisc.

Signed-off-by: Li Jun 
---
 Documentation/devicetree/bindings/usb/usbmisc-imx.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/usb/usbmisc-imx.txt 
b/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
index 3539d4e..f1e27fa 100644
--- a/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
+++ b/Documentation/devicetree/bindings/usb/usbmisc-imx.txt
@@ -6,6 +6,7 @@ Required properties:
"fsl,imx6q-usbmisc" for imx6q
"fsl,vf610-usbmisc" for Vybrid vf610
"fsl,imx6sx-usbmisc" for imx6sx
+   "fsl,imx7d-usbmisc" for imx7d
 - reg: Should contain registers location and length
 
 Examples:
-- 
2.6.6

--
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] usb: gadget: f_midi: Add checking if it need align buffer's size to an ep's maxpacketsize

2016-07-12 Thread Baolin Wang

Some gadget device (such as dwc3 gadget) requires quirk_ep_out_aligned_size
attribute, which means it need to align the request buffer's size to an ep's
maxpacketsize.

Thus we add usb_ep_align_maybe() function to check if it is need to align
the request buffer's size to an ep's maxpacketsize.

Signed-off-by: Baolin Wang 
Acked-by: Michal Nazarewicz 
---
Changelog:
v2:
 - Simplify the method to get buffer length.
v1:
 - Remove the in_ep modification.
 - Remove max_t() function.

 drivers/usb/gadget/function/f_midi.c |   11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/gadget/function/f_midi.c 
b/drivers/usb/gadget/function/f_midi.c
index 58fc199..3486941 100644
--- a/drivers/usb/gadget/function/f_midi.c
+++ b/drivers/usb/gadget/function/f_midi.c
@@ -359,10 +359,13 @@ static int f_midi_set_alt(struct usb_function *f, 
unsigned intf, unsigned alt)
 
/* allocate a bunch of read buffers and queue them all at once. */
for (i = 0; i < midi->qlen && err == 0; i++) {
-   struct usb_request *req =
-   midi_alloc_ep_req(midi->out_ep,
-   max_t(unsigned, midi->buflen,
-   bulk_out_desc.wMaxPacketSize));
+   struct usb_request *req;
+   unsigned length;
+
+   length = usb_ep_align_maybe(midi->gadget, midi->out_ep,
+   midi->buflen);
+
+   req = midi_alloc_ep_req(midi->out_ep, length);
if (req == NULL)
return -ENOMEM;
 
-- 
1.7.9.5

--
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] usb: chipidea: usbmisc: set over current polarity for imx6 and imx7

2016-07-12 Thread Li Jun

As all usb power supply use low active for over current flag on imx6
imx7 boards, and the default register setting(0) is for high active,
this patch is to correct it.

Signed-off-by: Li Jun 
---
 drivers/usb/chipidea/usbmisc_imx.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/chipidea/usbmisc_imx.c 
b/drivers/usb/chipidea/usbmisc_imx.c
index ab8b027..16e834b 100644
--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b/drivers/usb/chipidea/usbmisc_imx.c
@@ -56,6 +56,7 @@
 
 #define MX6_BM_NON_BURST_SETTING   BIT(1)
 #define MX6_BM_OVER_CUR_DISBIT(7)
+#define MX6_BM_OVER_CUR_POLARITY   BIT(8)
 #define MX6_BM_WAKEUP_ENABLE   BIT(10)
 #define MX6_BM_ID_WAKEUP   BIT(16)
 #define MX6_BM_VBUS_WAKEUP BIT(17)
@@ -266,10 +267,15 @@ static int usbmisc_imx6q_init(struct imx_usbmisc_data 
*data)
 
spin_lock_irqsave(&usbmisc->lock, flags);
 
+   reg = readl(usbmisc->base + data->index * 4);
if (data->disable_oc) {
-   reg = readl(usbmisc->base + data->index * 4);
writel(reg | MX6_BM_OVER_CUR_DIS,
usbmisc->base + data->index * 4);
+   } else {
+   reg &= ~MX6_BM_OVER_CUR_DIS;
+   /* OC flag is active low */
+   writel(reg | MX6_BM_OVER_CUR_POLARITY,
+   usbmisc->base + data->index * 4);
}
 
/* SoC non-burst setting */
@@ -365,9 +371,13 @@ static int usbmisc_imx7d_init(struct imx_usbmisc_data 
*data)
return -EINVAL;
 
spin_lock_irqsave(&usbmisc->lock, flags);
+   reg = readl(usbmisc->base);
if (data->disable_oc) {
-   reg = readl(usbmisc->base);
writel(reg | MX6_BM_OVER_CUR_DIS, usbmisc->base);
+   } else {
+   reg &= ~MX6_BM_OVER_CUR_DIS;
+   /* OC flag is active low */
+   writel(reg | MX6_BM_OVER_CUR_POLARITY, usbmisc->base);
}
 
reg = readl(usbmisc->base + MX7D_USBNC_USB_CTRL2);
@@ -492,6 +502,10 @@ static const struct of_device_id usbmisc_imx_dt_ids[] = {
.compatible = "fsl,imx6ul-usbmisc",
.data = &imx6sx_usbmisc_ops,
},
+   {
+   .compatible = "fsl,imx7d-usbmisc",
+   .data = &imx7d_usbmisc_ops,
+   },
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, usbmisc_imx_dt_ids);
-- 
2.6.6

--
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:solve resume usb device identification problem

2016-07-12 Thread Lipengcheng



> -Original Message-
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Tuesday, July 12, 2016 10:24 AM
> To: Lipengcheng; gre...@linuxfoundation.org; st...@rowland.harvard.edu; 
> chasemetzge...@gmail.com; mathias.ny...@linux.intel.com;
> oneu...@suse.com; jun...@freescale.com
> Cc: linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: Re: [PATCH] usb:solve resume usb device identification problem
> 
> Hi,
> 
> On 07/12/2016 09:48 AM, Lipengcheng wrote:
> > Hi,
> >
> >> -Original Message-
> >> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> >> Sent: Tuesday, July 12, 2016 8:42 AM
> >> To: Lipengcheng; gre...@linuxfoundation.org;
> >> st...@rowland.harvard.edu; chasemetzge...@gmail.com;
> >> mathias.ny...@linux.intel.com; oneu...@suse.com; jun...@freescale.com
> >> Cc: linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org
> >> Subject: Re: [PATCH] usb:solve resume usb device identification
> >> problem
> >>
> >> Hi,
> >>
> >> On 07/11/2016 08:57 PM, Pengcheng Li wrote:
> >>> A usb device in the connection state. Then host is suspend and resume.
> >>> But the usb device could not be at the right speed. We should be
> >>> reset the reset.
> >> Have you tried applying XHCI_RESET_ON_RESUME quirk to your host controller 
> >> driver? Is your usb device self powered?
> >>
> > I do not apply XHCI_RESET_ON_RESUME quir to my host controller driver. I 
> > select no pci platform. Our usb device is not self powered.
> 
> This quirk is not pci specific.
> 
I'm sorry. I will try to it.
> >> Best regards,
> >> Lu  Baolu
> >>
> >>> Signed-off-by: Pengcheng Li 
> >>> ---
> >>>  drivers/usb/core/hub.c | 6 +-
> >>>  1 file changed, 5 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index
> >>> bee1351..cd71bb3 100644
> >>> --- a/drivers/usb/core/hub.c
> >>> +++ b/drivers/usb/core/hub.c
> >>> @@ -3455,7 +3455,7 @@ int usb_port_resume(struct usb_device *udev, 
> >>> pm_message_t msg)
> >>>   struct usb_hub  *hub = usb_hub_to_struct_hub(udev->parent);
> >>>   struct usb_port *port_dev = hub->ports[udev->portnum  - 1];
> >>>   int port1 = udev->portnum;
> >>> - int status;
> >>> + int status, retval;
> >>>   u16 portchange, portstatus;
> >>>
> >>>   if (!test_and_set_bit(port1, hub->child_usage_bits)) { @@ -3512,6
> >>> +3512,10 @@ int usb_port_resume(struct usb_device *udev,
> >>> +pm_message_t msg)
> >>>   }
> >>>   }
> >>>
> >>> + retval = hub_port_reset(hub, port1, udev, HUB_ROOT_RESET_TIME, false);
> >>> + if (retval < 0)
> >>> + hub_port_disable(hub, port1, 0);
> >>> +
> 
> If I understand it right, this is a "host + device" specific issue. This line 
> of code might solve your issue, but it impacts all other hosts and devices
> which don't have such problem.
> 
Yes. You are right. This line of code can solve my issue. But I suspect this is 
a common issue. At normal enumeration, the device has a reset operation. The 
resume
should have the same operation. In USB3.0 spec, superspeed device is at the 
wrong statue(u2 statue), and we should be reset the device.
> Best regards,
> Lu Baolu

Best regards,
Pengcheng Li

[PATCH 0/2] usb: add HCD providers

2016-07-12 Thread Rafał Miłecki

Hi,

I was working on an "usbport" LED trigger driver and specifying its
default state in DT. I realized I can't really determine numbering of
USB ports on any device as it depends on compiled drivers and the
loading orders.

It means that my physical USB port can be e.g. 1-1 or 2-1 depending on
my current config/setup. I needed a way to specify a particular HCD in
DT and then hardcode port number (as this part doesn't change).

These 2 patches add providers to usb core subsystem. I successfully
tested it with "usbport" trigger and generic-ohci, generic-ehci &
generic-xhci.

The last (third) patch is not supposed to be applied, it's used only as
a proof and example of how providers can be used.

If there is anything wrong with this idea/implementation, please let me
know.

Rafał Miłecki (2):
  usb: core: add support for HCD providers
  ohci-platform: register HCD provider

 drivers/usb/core/Makefile|  1 +
 drivers/usb/core/provider.c  | 79 
 drivers/usb/host/ohci-platform.c |  9 +
 include/linux/usb/provider.h | 39 
 4 files changed, 128 insertions(+)
 create mode 100644 drivers/usb/core/provider.c
 create mode 100644 include/linux/usb/provider.h

-- 
1.8.4.5

--
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 PROOF OF CONCEPT 3/2] trigger: ledtrig-usbport: read initial state from DT

2016-07-12 Thread Rafał Miłecki

This allows specifying USB ports that should be observed by a trigger
right after activating it. Example:

usb {
gpios = <&gpio 0 GPIO_ACTIVE_HIGH>;
linux,default-trigger = "usbport";
usb-controllers = <&ohci>, <&ehci>, <&xhci>;
usb-ports = "1", "1", "1";
};

Signed-off-by: Rafał Miłecki 
---
 drivers/leds/trigger/ledtrig-usbport.c | 72 ++
 1 file changed, 72 insertions(+)

diff --git a/drivers/leds/trigger/ledtrig-usbport.c 
b/drivers/leds/trigger/ledtrig-usbport.c
index eb20a8f..5724f63 100644
--- a/drivers/leds/trigger/ledtrig-usbport.c
+++ b/drivers/leds/trigger/ledtrig-usbport.c
@@ -12,8 +12,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include "../leds.h"
 
 struct usbport_trig_port {
@@ -94,6 +96,75 @@ static bool usbport_trig_match(struct usbport_trig_data 
*usbport_data,
return false;
 }
 
+static int usbport_trig_new_port(struct usbport_trig_data *usbport_data,
+int busnum, const char *suffix)
+{
+   struct usbport_trig_port *port;
+   size_t len;
+   int tmp;
+
+   tmp = busnum;
+   len = 1;
+   while (tmp >= 10) {
+   tmp /= 10;
+   len++;
+   }
+   len++; /* '-' */
+   len += strlen(suffix);
+   len++; /* '\0' */
+
+   port = kzalloc(sizeof(*port), GFP_KERNEL);
+   if (!port)
+   return -ENOMEM;
+
+   port->name = kzalloc(len, GFP_KERNEL);
+   if (!port->name) {
+   kfree(port);
+   return -ENOMEM;
+   }
+   snprintf(port->name, len, "%d-%s", busnum, suffix);
+
+   list_add_tail(&port->list, &usbport_data->ports);
+
+   return 0;
+}
+
+static int usbport_trig_fill(struct usbport_trig_data *usbport_data)
+{
+   struct device_node *np = usbport_data->led_cdev->dev->of_node;
+   struct of_phandle_args args;
+   int count, i;
+   int err = 0;
+
+   if (!np)
+   return -ENOENT;
+
+   count = of_property_count_strings(np, "usb-ports");
+   if (count < 0)
+   return count;
+
+   for (i = 0; i < count; i++) {
+   const char *port;
+   struct usb_hcd *hcd;
+
+   err = of_property_read_string_index(np, "usb-ports", i, &port);
+   if (err)
+   continue;
+
+   err = of_parse_phandle_with_args(np, "usb-controllers", 
"#usb-cells", i, &args);
+   if (err)
+   continue;
+
+   hcd = of_hcd_get_from_provider(&args);
+   if (!IS_ERR(hcd))
+   usbport_trig_new_port(usbport_data, hcd->self.busnum, 
port);
+
+   of_node_put(args.np);
+   }
+
+   return err;
+}
+
 static int usbport_trig_notify(struct notifier_block *nb, unsigned long action,
   void *data)
 {
@@ -129,6 +200,7 @@ static void usbport_trig_activate(struct led_classdev 
*led_cdev)
return;
usbport_data->led_cdev = led_cdev;
INIT_LIST_HEAD(&usbport_data->ports);
+   usbport_trig_fill(usbport_data);
usbport_data->nb.notifier_call = usbport_trig_notify,
led_cdev->trigger_data = usbport_data;
 
-- 
1.8.4.5

--
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] ohci-platform: register HCD provider

2016-07-12 Thread Rafał Miłecki

This allows platforms using e.g. "generic-ohci" to reference HCD using
recently introduced providers mechanism

Signed-off-by: Rafał Miłecki 
---
 drivers/usb/host/ohci-platform.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index 898b740..57be81c 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "ohci.h"
 
@@ -40,6 +41,7 @@ struct ohci_platform_priv {
struct clk *clks[OHCI_MAX_CLKS];
struct reset_control *resets[OHCI_MAX_RESETS];
struct phy **phys;
+   struct hcd_provider *hcd_provider;
int num_phys;
 };
 
@@ -258,6 +260,11 @@ static int ohci_platform_probe(struct platform_device *dev)
if (err)
goto err_power;
 
+   if (dev->dev.of_node)
+   priv->hcd_provider = of_hcd_provider_register(dev->dev.of_node,
+ 
of_hcd_xlate_simple,
+ hcd);
+
device_wakeup_enable(hcd->self.controller);
 
platform_set_drvdata(dev, hcd);
@@ -289,6 +296,8 @@ static int ohci_platform_remove(struct platform_device *dev)
struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
int clk, rst;
 
+   of_hcd_provider_unregister(priv->hcd_provider);
+
usb_remove_hcd(hcd);
 
if (pdata->power_off)
-- 
1.8.4.5

--
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] usb: core: add support for HCD providers

2016-07-12 Thread Rafał Miłecki

When working with Device Tree we may need to reference controllers
(their nodes) and query for HCDs. This is useful for getting some
runtime info about host controllers like e.g. assigned bus number.

Signed-off-by: Rafał Miłecki 
---
 drivers/usb/core/Makefile|  1 +
 drivers/usb/core/provider.c  | 79 
 include/linux/usb/provider.h | 39 ++
 3 files changed, 119 insertions(+)
 create mode 100644 drivers/usb/core/provider.c
 create mode 100644 include/linux/usb/provider.h

diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
index 9780877..20b91d1 100644
--- a/drivers/usb/core/Makefile
+++ b/drivers/usb/core/Makefile
@@ -9,5 +9,6 @@ usbcore-y += port.o of.o
 
 usbcore-$(CONFIG_PCI)  += hcd-pci.o
 usbcore-$(CONFIG_ACPI) += usb-acpi.o
+usbcore-$(CONFIG_OF)   += provider.o
 
 obj-$(CONFIG_USB)  += usbcore.o
diff --git a/drivers/usb/core/provider.c b/drivers/usb/core/provider.c
new file mode 100644
index 000..4b9165a
--- /dev/null
+++ b/drivers/usb/core/provider.c
@@ -0,0 +1,79 @@
+#include 
+#include 
+
+static DEFINE_MUTEX(hcd_provider_mutex);
+static LIST_HEAD(hcd_provider_list);
+
+struct hcd_provider {
+   struct device_node *np;
+   struct usb_hcd *(*of_xlate)(struct of_phandle_args *args, void *data);
+   void *data;
+   struct list_head list;
+};
+
+struct hcd_provider *of_hcd_provider_register(struct device_node *np,
+ struct usb_hcd 
*(*of_xlate)(struct of_phandle_args *args, void *data),
+ void *data)
+{
+   struct hcd_provider *hcd_provider;
+
+   if (!np)
+   return ERR_PTR(-EINVAL);
+
+   hcd_provider = kzalloc(sizeof(*hcd_provider), GFP_KERNEL);
+   if (!hcd_provider)
+   return ERR_PTR(-ENOMEM);
+
+   hcd_provider->np = np;
+   hcd_provider->of_xlate = of_xlate;
+   hcd_provider->data = data;
+
+   mutex_lock(&hcd_provider_mutex);
+   list_add_tail(&hcd_provider->list, &hcd_provider_list);
+   mutex_unlock(&hcd_provider_mutex);
+
+   return hcd_provider;
+}
+EXPORT_SYMBOL_GPL(of_hcd_provider_register);
+
+void of_hcd_provider_unregister(struct hcd_provider *hcd_provider)
+{
+   if (IS_ERR(hcd_provider))
+   return;
+
+   mutex_lock(&hcd_provider_mutex);
+   list_del(&hcd_provider->list);
+   mutex_unlock(&hcd_provider_mutex);
+
+   kfree(hcd_provider);
+}
+EXPORT_SYMBOL_GPL(of_hcd_provider_unregister);
+
+struct usb_hcd *of_hcd_xlate_simple(struct of_phandle_args *args, void *data)
+{
+   if (args->args_count != 0)
+   return ERR_PTR(-EINVAL);
+   return data;
+}
+EXPORT_SYMBOL_GPL(of_hcd_xlate_simple);
+
+struct usb_hcd *of_hcd_get_from_provider(struct of_phandle_args *args)
+{
+   struct usb_hcd *hcd = ERR_PTR(-ENOENT);
+   struct hcd_provider *provider;
+
+   if (!args)
+   return ERR_PTR(-EINVAL);
+
+   mutex_lock(&hcd_provider_mutex);
+   list_for_each_entry(provider, &hcd_provider_list, list) {
+   if (provider->np == args->np) {
+   hcd = provider->of_xlate(args, provider->data);
+   break;
+   }
+   }
+   mutex_unlock(&hcd_provider_mutex);
+
+   return hcd;
+}
+EXPORT_SYMBOL_GPL(of_hcd_get_from_provider);
diff --git a/include/linux/usb/provider.h b/include/linux/usb/provider.h
new file mode 100644
index 000..c66e006
--- /dev/null
+++ b/include/linux/usb/provider.h
@@ -0,0 +1,39 @@
+#ifndef __USB_CORE_PROVIDER_H
+#define __USB_CORE_PROVIDER_H
+
+#include 
+#include 
+#include 
+
+struct hcd_provider;
+
+#ifdef CONFIG_OF
+struct hcd_provider *of_hcd_provider_register(struct device_node *np,
+ struct usb_hcd 
*(*of_xlate)(struct of_phandle_args *args, void *data),
+ void *data);
+void of_hcd_provider_unregister(struct hcd_provider *hcd_provider);
+struct usb_hcd *of_hcd_xlate_simple(struct of_phandle_args *args, void *data);
+struct usb_hcd *of_hcd_get_from_provider(struct of_phandle_args *args);
+#else
+static inline
+struct hcd_provider *of_hcd_provider_register(struct device_node *np,
+ struct usb_hcd 
*(*of_xlate)(struct of_phandle_args *args, void *data),
+ void *data)
+{
+   return ERR_PTR(-ENOSYS);
+}
+static inline void of_hcd_provider_unregister(struct hcd_provider 
*hcd_provider)
+{
+}
+static inline struct usb_hcd *of_hcd_xlate_simple(struct of_phandle_args *args,
+ void *data)
+{
+   return ERR_PTR(-ENOSYS);
+}
+static inline struct usb_hcd *of_hcd_get_from_provider(struct of_phandle_args 
*args)
+{
+   return NULL;
+}
+#endif
+
+#endif /* __USB_CORE_PROVIDER_H */
-- 
1.8.4.5

--
To unsubscribe from

RE: [PATCH v6 RESEND] r8152: Add support for setting pass through MAC address on RTL8153-AD

2016-07-12 Thread Mario_Limonciello

> -Original Message-
> From: Michał Pecio [mailto:michal.pe...@gmail.com]
> Sent: Tuesday, July 12, 2016 2:03 AM
> To: David Miller 
> Cc: Limonciello, Mario ; linux-
> ker...@vger.kernel.org; net...@vger.kernel.org; linux-
> u...@vger.kernel.org; anthony.w...@canonical.com
> Subject: Re: [PATCH v6 RESEND] r8152: Add support for setting pass through
> MAC address on RTL8153-AD
> 
> > From: Mario Limonciello 
> > Date: Mon, 11 Jul 2016 19:58:04 -0500
> >
> > > The RTL8153-AD supports a persistent system specific MAC address.
> > > This means a device plugged into two different systems with host
> > > side support will show different (but persistent) MAC addresses.
> > >
> > > This information for the system's persistent MAC address is burned
> > > in when the system HW is built and available under \_SB.AMAC in the
> > > DSDT at runtime.
> > >
> > > This technology is currently implemented in the Dell TB15 and WD15
> > > Type-C docks.  More information is available here:
> > > http://www.dell.com/support/article/us/en/04/SLN301147
> > >
> > > Signed-off-by: Mario Limonciello 
> >
> > Applied.
> 
> Hi,
> 
> Isn't it possible that the same ACPI name could be used for other
> vendor-specific extensions on other laptops and that r8152 will now
> wreak havoc there?
> 
> Regards,
> MP

This has been discussed a bit previously in earlier submissions.

In short, this is an extreme corner case.  Some changes were made 
to diminish potential impact. The ACPI code is resolved only when 
the specific variant of RTL8135 (-AD) has a bit set on the efuse.

The patch also explicitly checks the return type and contents of the
ACPI object and won't proceed if it's invalid.

The Type-C devices that provide this are currently only sold by Dell.  
This of course may change one day if other OEM's add this
feature, but it just shows that device scope is limited.

For now the way this is implemented if Realtek does choose to 
work with another OEM on this feature, there should be no
kernel code change necessary for interoperability of peripherals
on other OEM machines.

So in order to hit this hypothetical corner case today you would 
need to be using a real world type-C device something such as a 
Dell WD15 on another OEM's machine that has type-C and the exact
same ACPI object name that does $BADSTUFF other than return a
buffer.

If that situation arises please alert me and I'll send a follow up
patch that whitelists this to match DMI vendor of only Dell 
systems.


--
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: mceusb xhci issue?

2016-07-12 Thread Alan Stern

On Sat, 9 Jul 2016, Mauro Carvalho Chehab wrote:

> C/C linux-usb Mailing list:
> 
> 
> Em Wed, 18 May 2016 08:52:28 -0600
> Wade Berrier  escreveu:

...

> > > That message above links to some other threads describing the issue.
> > > Here's a post with a patch that supposedly works:
> > > 
> > > http://www.gossamer-threads.com/lists/mythtv/users/587930
> > > 
> > > No idea if that's the "correct" way to fix this.
> > > 
> > > I'll be trying that out and then report back...  
> > 
> > Indeed, this patch does fix the issue:
> > 
> > --
> > 
> > diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
> > index 31ccdcc..03321d4 100644
> > --- a/drivers/usb/core/config.c
> > +++ b/drivers/usb/core/config.c
> > @@ -247,7 +247,7 @@ static int usb_parse_endpoint(struct device *ddev, int 
> > cfgno, int inum,
> > /* For low-speed, 10 ms is the official minimum.
> >  * But some "overclocked" devices might want faster
> >  * polling so we'll allow it. */
> > -   n = 32;
> > +   n = 10;
> > break;
> > }
> > } else if (usb_endpoint_xfer_isoc(d)) {
> > 
> > 
> > --
> > 
> > Is this change appropriate to be pushed upstream?  Where to go from
> > here?
> 
> This issue is at the USB core. So, it should be reported to the
> linux-usb mailing list. 
> 
> The people there should help about how to proceed to get this
> fixed upstream.

Here's a proper version of that patch.  If this is okay, it can be 
merged.

Alan Stern



Index: usb-4.x/drivers/usb/core/config.c
===
--- usb-4.x.orig/drivers/usb/core/config.c
+++ usb-4.x/drivers/usb/core/config.c
@@ -213,8 +213,10 @@ static int usb_parse_endpoint(struct dev
memcpy(&endpoint->desc, d, n);
INIT_LIST_HEAD(&endpoint->urb_list);
 
-   /* Fix up bInterval values outside the legal range. Use 32 ms if no
-* proper value can be guessed. */
+   /*
+* Fix up bInterval values outside the legal range.
+* Use 10 or 8 ms if no proper value can be guessed.
+*/
i = 0;  /* i = min, j = max, n = default */
j = 255;
if (usb_endpoint_xfer_int(d)) {
@@ -223,13 +225,15 @@ static int usb_parse_endpoint(struct dev
case USB_SPEED_SUPER_PLUS:
case USB_SPEED_SUPER:
case USB_SPEED_HIGH:
-   /* Many device manufacturers are using full-speed
+   /*
+* Many device manufacturers are using full-speed
 * bInterval values in high-speed interrupt endpoint
 * descriptors. Try to fix those and fall back to a
-* 32 ms default value otherwise. */
+* 8 ms default value otherwise.
+*/
n = fls(d->bInterval*8);
if (n == 0)
-   n = 9;  /* 32 ms = 2^(9-1) uframes */
+   n = 7;  /* 8 ms = 2^(7-1) uframes */
j = 16;
 
/*
@@ -247,7 +251,7 @@ static int usb_parse_endpoint(struct dev
/* For low-speed, 10 ms is the official minimum.
 * But some "overclocked" devices might want faster
 * polling so we'll allow it. */
-   n = 32;
+   n = 10;
break;
}
} else if (usb_endpoint_xfer_isoc(d)) {
@@ -255,10 +259,10 @@ static int usb_parse_endpoint(struct dev
j = 16;
switch (to_usb_device(ddev)->speed) {
case USB_SPEED_HIGH:
-   n = 9;  /* 32 ms = 2^(9-1) uframes */
+   n = 7;  /* 8 ms = 2^(7-1) uframes */
break;
default:/* USB_SPEED_FULL */
-   n = 6;  /* 32 ms = 2^(6-1) frames */
+   n = 4;  /* 8 ms = 2^(4-1) frames */
break;
}
}

--
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 5/6] usb: chipidea: let chipidea core device of_node equal's glue layer device of_node

2016-07-12 Thread Peter Chen

From: Peter Chen 

At device tree, we have no device node for chipidea core,
the glue layer's node is the parent node for host and udc
device. But in related driver, the parent device is chipidea
core. So, in order to let the common driver get parent's node,
we let the core's device node equals glue layer device node.

Signed-off-by: Peter Chen 
Tested-by: Maciej S. Szmigiero 
---
 drivers/usb/chipidea/core.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 69426e6..0d05812 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -914,6 +914,16 @@ static int ci_hdrc_probe(struct platform_device *pdev)
if (!ci)
return -ENOMEM;
 
+   /*
+* At device tree, we have no device node for chipidea core,
+* the glue layer's node is the parent node for host and udc
+* device. But in related driver, the parent device is chipidea
+* core. So, in order to let the common driver get parent's node,
+* we let the core's device node equals glue layer's node.
+*/
+   if (dev->parent && dev->parent->of_node)
+   dev->of_node = dev->parent->of_node;
+
ci->dev = dev;
ci->platdata = dev_get_platdata(dev);
ci->imx28_write_fix = !!(ci->platdata->flags &
-- 
1.9.1

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

[PATCH v2 6/6] ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property

2016-07-12 Thread Peter Chen

From: Peter Chen 

The current dts describes USB HUB's property at USB controller's
entry, it is improper. The USB HUB should be the child node
under USB controller, and power sequence properties are under
it.

Signed-off-by: Peter Chen 
Signed-off-by: Maciej S. Szmigiero 
---
 arch/arm/boot/dts/imx6qdl-udoo.dtsi | 27 ++-
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-udoo.dtsi 
b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
index 3bee2f9..492fc5d 100644
--- a/arch/arm/boot/dts/imx6qdl-udoo.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
@@ -9,6 +9,8 @@
  *
  */
 
+#include 
+
 / {
aliases {
backlight = &backlight;
@@ -58,17 +60,6 @@
#address-cells = <1>;
#size-cells = <0>;
 
-   reg_usb_h1_vbus: regulator@0 {
-   compatible = "regulator-fixed";
-   reg = <0>;
-   regulator-name = "usb_h1_vbus";
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   enable-active-high;
-   startup-delay-us = <2>; /* USB2415 requires a POR of 1 
us minimum */
-   gpio = <&gpio7 12 0>;
-   };
-
reg_panel: regulator@1 {
compatible = "regulator-fixed";
reg = <1>;
@@ -259,9 +250,19 @@
 &usbh1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usbh>;
-   vbus-supply = <®_usb_h1_vbus>;
-   clocks = <&clks IMX6QDL_CLK_CKO>;
status = "okay";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   hub: usb2415@1 {
+   compatible = "usb424,2514";
+   reg = <1>;
+
+   power-sequence;
+   clocks = <&clks IMX6QDL_CLK_CKO>;
+   reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
+   reset-duration-us = <3000>;
+   };
 };
 
 &usdhc3 {
-- 
1.9.1

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

[PATCH v2 3/6] binding-doc: usb: usb-device: add optional properties for power sequence

2016-07-12 Thread Peter Chen

Add optional properties for power sequence.

Signed-off-by: Peter Chen 
---
 Documentation/devicetree/bindings/usb/usb-device.txt | 9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt 
b/Documentation/devicetree/bindings/usb/usb-device.txt
index 1c35e7b..0ccaadf 100644
--- a/Documentation/devicetree/bindings/usb/usb-device.txt
+++ b/Documentation/devicetree/bindings/usb/usb-device.txt
@@ -13,6 +13,10 @@ Required properties:
 - reg: the port number which this device is connecting to, the range
   is 1-31.
 
+Optional properties:
+power sequence properties, see
+Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt for detail
+
 Example:
 
 &usb1 {
@@ -24,5 +28,10 @@ Example:
hub: genesys@1 {
compatible = "usb5e3,608";
reg = <1>;
+
+   power-sequence;
+   clocks = <&clks IMX6SX_CLK_CKO>;
+   reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
+   reset-duration-us = <10>;
};
 }
-- 
1.9.1

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

[PATCH v2 1/6] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library

2016-07-12 Thread Peter Chen

Add binding doc for generic power sequence library.

Signed-off-by: Peter Chen 
---
 .../bindings/power/pwrseq/pwrseq-generic.txt   | 53 ++
 1 file changed, 53 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt

diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt 
b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
new file mode 100644
index 000..186c58c
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
@@ -0,0 +1,53 @@
+The generic power sequence library
+
+Some hard-wired USB/MMC devices need to do power sequence to let the
+device work normally, the typical power sequence like: enable USB
+PHY clock, toggle reset pin, etc. But current Linux USB driver
+lacks of such code to do it, it may cause some hard-wired USB devices
+works abnormal or can't be recognized by controller at all. The
+power sequence will be done before this device can be found at USB
+bus.
+
+The power sequence properties is under the device node.
+
+Required properties:
+- power-sequence: this device needs to do power sequence before enumeration
+
+Optional properties:
+- clocks: the input clock for device.
+- reset-gpios: Should specify the GPIO for reset.
+- reset-duration-us: the duration in microsecond for assert reset signal.
+
+Below is the example of USB power sequence properties on USB device
+nodes which have two level USB hubs.
+
+&usbotg1 {
+   vbus-supply = <®_usb_otg1_vbus>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_usb_otg1_id>;
+   status = "okay";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   hub: genesys@1 {
+   compatible = "usb5e3,608";
+   reg = <1>;
+
+   power-sequence;
+   clocks = <&clks IMX6SX_CLK_CKO>;
+   reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
+   reset-duration-us = <10>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   ethernet: asix@1 {
+   compatible = "usbb95,1708";
+   reg = <1>;
+
+   power-sequence;
+   clocks = <&clks IMX6SX_CLK_IPG>;
+   reset-gpios = <&gpio4 6 GPIO_ACTIVE_LOW>; /* 
ethernet_rst */
+   reset-duration-us = <15>;
+   };
+   };
+};
-- 
1.9.1

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

[PATCH v2 2/6] power: add power sequence library

2016-07-12 Thread Peter Chen

We have an well-known problem that the device needs to do some power
sequence before it can be recognized by related host, the typical
example like hard-wired mmc devices and usb devices.

This power sequence is hard to be described at device tree and handled by
related host driver, so we have created a common power sequence
library to cover this requirement. The core code has supplied
some common helpers for host driver, and individual power sequence
libraries handle kinds of power sequence for devices.

pwrseq_generic is intended for general purpose of power sequence, which
handles gpios and clocks currently, and can cover regulator and pinctrl
in future. The host driver calls pwrseq_alloc_generic to create
an generic pwrseq instance.

Signed-off-by: Peter Chen 
---
 drivers/power/Kconfig |   1 +
 drivers/power/Makefile|   1 +
 drivers/power/pwrseq/Kconfig  |  20 +
 drivers/power/pwrseq/Makefile |   2 +
 drivers/power/pwrseq/core.c   |  79 
 drivers/power/pwrseq/pwrseq_generic.c | 134 ++
 include/linux/power/pwrseq.h  |  55 ++
 7 files changed, 292 insertions(+)
 create mode 100644 drivers/power/pwrseq/Kconfig
 create mode 100644 drivers/power/pwrseq/Makefile
 create mode 100644 drivers/power/pwrseq/core.c
 create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
 create mode 100644 include/linux/power/pwrseq.h

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index acd4a15..f6aa4fd 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -515,3 +515,4 @@ endif # POWER_SUPPLY
 
 source "drivers/power/reset/Kconfig"
 source "drivers/power/avs/Kconfig"
+source "drivers/power/pwrseq/Kconfig"
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index e46b75d..4ed2e12 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -74,3 +74,4 @@ obj-$(CONFIG_CHARGER_TPS65217)+= tps65217_charger.o
 obj-$(CONFIG_POWER_RESET)  += reset/
 obj-$(CONFIG_AXP288_FUEL_GAUGE) += axp288_fuel_gauge.o
 obj-$(CONFIG_AXP288_CHARGER)   += axp288_charger.o
+obj-$(CONFIG_POWER_SEQUENCE)   += pwrseq/
diff --git a/drivers/power/pwrseq/Kconfig b/drivers/power/pwrseq/Kconfig
new file mode 100644
index 000..188729e
--- /dev/null
+++ b/drivers/power/pwrseq/Kconfig
@@ -0,0 +1,20 @@
+#
+# Power Sequence library
+#
+
+config POWER_SEQUENCE
+   bool
+
+menu "Power Sequence Support"
+
+config PWRSEQ_GENERIC
+   bool "Generic power sequence control"
+   depends on OF
+   select POWER_SEQUENCE
+   help
+ It is used for drivers which needs to do power sequence
+ (eg, turn on clock, toggle reset gpio) before the related
+ devices can be found by hardware. This generic one can be
+ used for common power sequence control.
+
+endmenu
diff --git a/drivers/power/pwrseq/Makefile b/drivers/power/pwrseq/Makefile
new file mode 100644
index 000..ad82389
--- /dev/null
+++ b/drivers/power/pwrseq/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_POWER_SEQUENCE) += core.o
+obj-$(CONFIG_PWRSEQ_GENERIC) += pwrseq_generic.o
diff --git a/drivers/power/pwrseq/core.c b/drivers/power/pwrseq/core.c
new file mode 100644
index 000..e40315c
--- /dev/null
+++ b/drivers/power/pwrseq/core.c
@@ -0,0 +1,79 @@
+/*
+ * core.c  power sequence core file
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Author: Peter Chen 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+
+static DEFINE_MUTEX(pwrseq_list_mutex);
+static LIST_HEAD(pwrseq_list);
+
+int pwrseq_get(struct device_node *np, struct pwrseq *p)
+{
+   if (p && p->get)
+   return p->get(np, p);
+
+   return -ENOTSUPP;
+}
+
+int pwrseq_on(struct device_node *np, struct pwrseq *p)
+{
+   if (p && p->on)
+   return p->on(np, p);
+
+   return -ENOTSUPP;
+}
+
+void pwrseq_off(struct pwrseq *p)
+{
+   if (p && p->off)
+   p->off(p);
+}
+
+void pwrseq_put(struct pwrseq *p)
+{
+   if (p && p->put)
+   p->put(p);
+}
+
+void pwrseq_free(struct pwrseq *p)
+{
+   if (p && p->free)
+   p->free(p);
+}
+
+void pwrseq_register(struct pwrseq *pwrseq)
+{
+   mutex_lock(&pwrseq_list_mutex);
+   list_add(&pwrseq->node, &pwrseq_list);
+   mutex_unlock(&pwrseq_list_mutex);
+}
+
+void pwrseq_unregister(struct pwrseq *pwrseq)
+{
+

[PATCH v2 4/6] usb: core: add power sequence handling for USB devices

2016-07-12 Thread Peter Chen

Some hard-wired USB devices need to do power sequence to let the
device work normally, the typical power sequence like: enable USB
PHY clock, toggle reset pin, etc. But current Linux USB driver
lacks of such code to do it, it may cause some hard-wired USB devices
works abnormal or can't be recognized by controller at all.

In this patch, it calls power sequence library APIs to finish
the power sequence events. At first, it calls pwrseq_alloc_generic
to create a generic power sequence instance, then it will do power
on sequence at hub's probe for all devices under this hub
(includes root hub) if this device is described at dts and there
is a property "power-sequence" for it.

At hub_disconnect, it will do power off sequence which is at powered
on list.

Signed-off-by: Peter Chen 
---
 drivers/usb/core/Makefile |   1 +
 drivers/usb/core/hub.c|  12 --
 drivers/usb/core/hub.h|  12 ++
 drivers/usb/core/pwrseq.c | 102 ++
 4 files changed, 124 insertions(+), 3 deletions(-)
 create mode 100644 drivers/usb/core/pwrseq.c

diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
index 9780877..39f2149 100644
--- a/drivers/usb/core/Makefile
+++ b/drivers/usb/core/Makefile
@@ -9,5 +9,6 @@ usbcore-y += port.o of.o
 
 usbcore-$(CONFIG_PCI)  += hcd-pci.o
 usbcore-$(CONFIG_ACPI) += usb-acpi.o
+usbcore-$(CONFIG_PWRSEQ_GENERIC) += pwrseq.o
 
 obj-$(CONFIG_USB)  += usbcore.o
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index bee1351..a346a8b 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1700,6 +1700,7 @@ static void hub_disconnect(struct usb_interface *intf)
hub->error = 0;
hub_quiesce(hub, HUB_DISCONNECT);
 
+   hub_pwrseq_off(hub);
mutex_lock(&usb_port_peer_mutex);
 
/* Avoid races with recursively_mark_NOTATTACHED() */
@@ -1733,6 +1734,7 @@ static int hub_probe(struct usb_interface *intf, const 
struct usb_device_id *id)
struct usb_endpoint_descriptor *endpoint;
struct usb_device *hdev;
struct usb_hub *hub;
+   int ret = -ENODEV;
 
desc = intf->cur_altsetting;
hdev = interface_to_usbdev(intf);
@@ -1839,6 +1841,7 @@ descriptor_error:
INIT_DELAYED_WORK(&hub->leds, led_work);
INIT_DELAYED_WORK(&hub->init_work, NULL);
INIT_WORK(&hub->events, hub_event);
+   INIT_LIST_HEAD(&hub->pwrseq_on_list);
usb_get_intf(intf);
usb_get_dev(hdev);
 
@@ -1852,11 +1855,14 @@ descriptor_error:
if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND)
hub->quirk_check_port_auto_suspend = 1;
 
-   if (hub_configure(hub, endpoint) >= 0)
-   return 0;
+   if (hub_configure(hub, endpoint) >= 0) {
+   ret = hub_pwrseq_on(hub);
+   if (!ret)
+   return 0;
+   }
 
hub_disconnect(intf);
-   return -ENODEV;
+   return ret;
 }
 
 static int
diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
index 34c1a7e..9473f6f 100644
--- a/drivers/usb/core/hub.h
+++ b/drivers/usb/core/hub.h
@@ -78,6 +78,7 @@ struct usb_hub {
struct delayed_work init_work;
struct work_struct  events;
struct usb_port **ports;
+   struct list_headpwrseq_on_list; /* powered pwrseq node list */
 };
 
 /**
@@ -166,3 +167,14 @@ static inline int hub_port_debounce_be_stable(struct 
usb_hub *hub,
 {
return hub_port_debounce(hub, port1, false);
 }
+
+#if IS_ENABLED(CONFIG_PWRSEQ_GENERIC)
+int hub_pwrseq_on(struct usb_hub *hub);
+void hub_pwrseq_off(struct usb_hub *hub);
+#else
+static inline int hub_pwrseq_on(struct usb_hub *hub)
+{
+   return 0;
+}
+static inline void hub_pwrseq_off(struct usb_hub *hub) {}
+#endif /* CONFIG_PWRSEQ_GENERIC */
diff --git a/drivers/usb/core/pwrseq.c b/drivers/usb/core/pwrseq.c
new file mode 100644
index 000..df171ed
--- /dev/null
+++ b/drivers/usb/core/pwrseq.c
@@ -0,0 +1,102 @@
+/*
+ * pwrseq.cUSB device power sequence management
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Author: Peter Chen 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "hub.h"
+
+struct usb_pwrseq_node {
+   struct pwrseq *pwrseq;
+   struct list_head list;
+};
+
+static int hub_of_pwrseq_on

[PATCH v2 0/6] power: add power sequence library

2016-07-12 Thread Peter Chen

Hi all,

This is a follow-up for my last power sequence framework patch set [1].
According to Rob Herring and Ulf Hansson's comments[2], I use a generic
power sequence library for parsing the power sequence elements on DT,
and implement generic power sequence on library. The host driver
can allocate power sequence instance, and calls pwrseq APIs accordingly.

In future, if there are special power sequence requirements, the special
power sequence library can be created.

This patch set is tested on i.mx6 sabresx evk using a dts change, I use
two hot-plug devices to simulate this use case, the related binding
change is updated at patch[1/6], The udoo board changes were tested
using my last power sequence patch set.[3]

Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
need to power on itself before it can be found by ULPI bus.

[1] http://www.spinics.net/lists/linux-usb/msg142755.html
[2] http://www.spinics.net/lists/linux-usb/msg143106.html
[3] http://www.spinics.net/lists/linux-usb/msg142815.html

Changes for v2:
- Delete "pwrseq" prefix and clock-names for properties at dt binding
- Should use structure not but its pointer for kzalloc
- Since chipidea core has no of_node, let core's of_node equals glue
  layer's at core's probe


Peter Chen (6):
  binding-doc: power: pwrseq-generic: add binding doc for generic power
sequence library
  power: add power sequence library
  binding-doc: usb: usb-device: add optional properties for power
sequence
  usb: core: add power sequence handling for USB devices
  usb: chipidea: let chipidea core device of_node equal's glue layer
device of_node
  ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property

 .../bindings/power/pwrseq/pwrseq-generic.txt   |  53 
 .../devicetree/bindings/usb/usb-device.txt |   9 ++
 arch/arm/boot/dts/imx6qdl-udoo.dtsi|  27 +++--
 drivers/power/Kconfig  |   1 +
 drivers/power/Makefile |   1 +
 drivers/power/pwrseq/Kconfig   |  20 +++
 drivers/power/pwrseq/Makefile  |   2 +
 drivers/power/pwrseq/core.c|  79 
 drivers/power/pwrseq/pwrseq_generic.c  | 134 +
 drivers/usb/chipidea/core.c|  10 ++
 drivers/usb/core/Makefile  |   1 +
 drivers/usb/core/hub.c |  12 +-
 drivers/usb/core/hub.h |  12 ++
 drivers/usb/core/pwrseq.c  | 102 
 include/linux/power/pwrseq.h   |  55 +
 15 files changed, 502 insertions(+), 16 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
 create mode 100644 drivers/power/pwrseq/Kconfig
 create mode 100644 drivers/power/pwrseq/Makefile
 create mode 100644 drivers/power/pwrseq/core.c
 create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
 create mode 100644 drivers/usb/core/pwrseq.c
 create mode 100644 include/linux/power/pwrseq.h

-- 
1.9.1

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

Re: [PATCH v6 3/5] usb: dwc3: add phyif_utmi_quirk

2016-07-12 Thread William.wu


Dear Heiko,


On 2016/7/10 7:47, Heiko Stuebner wrote:

Am Samstag, 9. Juli 2016, 11:38:00 schrieb William.wu:

Dear Heiko & Balbi，

On 2016/7/8 21:29, Felipe Balbi wrote:

Hi,

Heiko Stuebner  writes:

Am Donnerstag, 7. Juli 2016, 10:54:24 schrieb William Wu:

Add a quirk to configure the core to support the
UTMI+ PHY with an 8- or 16-bit interface. UTMI+ PHY
interface is hardware property, and it's platform
dependent. Normall, the PHYIf can be configured
during coreconsultant. But for some specific usb
cores(e.g. rk3399 soc dwc3), the default PHYIf
configuration value is fault, so we need to
reconfigure it by software.

And refer to the dwc3 databook, the GUSB2PHYCFG.USBTRDTIM
must be set to the corresponding value according to
the UTMI+ PHY interface.

Signed-off-by: William Wu 
---

[...]


diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt index
020b0e9..8d7317d
100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt

@@ -42,6 +42,10 @@ Optional properties:
- snps,dis-u2-freeclk-exists-quirk: when set, clear the

u2_freeclk_exists in GUSB2PHYCFG, specify that USB2 PHY doesn't
provide

a free-running PHY clock.

+ - snps,phyif-utmi-quirk: when set core will set phyif UTMI+
interface.
+ - snps,phyif-utmi: the value to configure the core to support a
UTMI+
PHY +   with an 8- or 16-bit interface. Value 0

select 8-bit

+   interface, value 1 select 16-bit interface.

maybe

snps,phyif-utmi-width = <8> or <16>;

devicetree is about describing the hardware, not the things that get
written to registers :-) . The conversion from the described width to
the register value can easily be done in the driver.

Thanks for your suggestion:-)
Yes， “snps,phyif-utmi-width = <8> or <16>” is much clearer and easier to
understand.
And I have considered the same dts property for phyif-utmi, but I have
no good idea about
the conversion from described width to the registers value for the time
being.

About phyif utmi width configuration， we need to set two places in
GUSB2PHYCFG register，
according to DWC3 USB3.0 controller databook version3.00a，6.3.46
GUSB2PHYCFG

--
 Bits   |  Name | Description
--
 13:10  |   USBTRDTIM   | Sets the turnaround
time in PHY clocks.
  || 4'h5: When the MAC

interface is 16-bit UTMI+

  || 4'h9: When the MAC

interface is 8-bit UTMI+/ULPI.
--
 3|   PHYIF|If UTMI+ is
selected, the application uses this bit to configure

  ||core to support a UTMI+

PHY with an 8- or 16-bit interface.

  ||1'b0: 8 bits
  ||1'b1: 16 bits

--


And I think maybe I can try to do this:
change it in dts:
  snps,phyif-utmi-width = <8> or <16>;

Then convert to register value like this：
 device_property_read_u8(dev, "snps,phyif-utmi-width",
   &phyif_utmi_width);

 dwc->phyif_utmi = phyif_utmi_width >> 4;

   Ater the conversion， dwc->phyif_utmi value 0 means 8 bits, value 1
means 16 bits,
   and it's easier for us to config GUSB2PHYCFG.

Is it OK?

or you could just store the actual width value read from the dts and make
the core handle accordingly, making everything a bit more explicit.

I guess personally I'd do something like:

make dwc->phyif_utmi a regular unsigned int

in probe:
ret = device_property_read_u8(dev, "snps,phyif-utmi-width",
   &dwc->phyif_utmi);
if (ret < 0) {
dwc->phyif_utmi = 0;
else if (dwc->phyif_utmi != 16 && dwc->phyif_utmi != 8) {
dev_err(dev, "unsupported utmi interface width %d\n",
dwc->phyif_utmi);
return -EINVAL;
}


when setting your GUSB2PHYCFG register:

if (dwc->phyif_utmi > 0) {
reg &= ~(DWC3_GUSB2PHYCFG_PHYIF_MASK |
   DWC3_GUSB2PHYCFG_USBTRDTIM_MASK);
usbtrdtim = (dwc->phyif_utmi == 16) ? USBTRDTIM_UTMI_16_BIT :
USBTRDTIM_UTMI_8_BIT;
phyif = (dwc->phyif_utmi == 16) ? 1 : 0;
reg |= DWC3_GUSB2PHYCFG_PHYIF(phyif) |
   DWC3_GUSB2PHYCFG_USBTRDTIM(usbtrdtim) |
}


Ah yes， it seems very good to me, very explicit.
I'l

Re: pl2303_read_int_callback - usb_submit_urb failed with result -19

2016-07-12 Thread Malith Yapa

The reason for the random disconnects is apparently EMI related.

Mar  1 07:09:09 localhost kernel: [265922.921985] hub 5-0:1.0: port 1
disabled by hub (EMI?), re-enabling...

This is very much a possibility because the box is in a high current
industrial control panel. That is not an issue because the device
automatically reconnects.
But after a few day's operation it stops reconnecting and i finally
managed to capture the syslog.

Mar  1 07:09:09 localhost kernel: [265922.934119] usb 5-1: USB
disconnect, device number 83
Mar  1 07:09:10 localhost kernel: [265923.245580] usb 5-1: new
full-speed USB device number 84 using sw-ohci
Mar  1 07:09:10 localhost kernel: [265923.451746] pl2303 5-1:1.0:
pl2303 converter detected
Mar  1 07:09:10 localhost kernel: [265923.486633] pl2303 5-1:1.0: No
more free serial devices
Mar  1 07:09:10 localhost kernel: [265923.496483] pl2303: probe of
5-1:1.0 failed with error -5
Mar  1 07:09:10 localhost mtp-probe: checking bus 5, device 84:
"/sys/devices/platform/sw-ohci.2/usb5/5-1"
Mar  1 07:09:10 localhost mtp-probe: bus: 5, device: 84 was not an MTP device

The driver issues "No more free serial devices".

The two reasons i can see for this are either if the malloc fails (but
there's no "out of memory" error) or if minor numbers have exceeded
the limit. But the minor is only 84!

Any pointers for a solution?

Thanks,
Malith

On Wed, Jul 6, 2016 at 4:38 PM, Malith Yapa  wrote:
> On Wed, Jul 6, 2016 at 3:42 PM, Johan Hovold  wrote:
>> [ +CC: linux-usb, for real this time ;) ]
>>
>> On Wed, Jul 06, 2016 at 02:40:25PM +0530, Malith Yapa wrote:
>>> On Wed, Jul 6, 2016 at 2:13 PM, Johan Hovold  wrote:
>>> > [ Please avoid top-posing. ]
>>> >
>>> > On Wed, Jul 06, 2016 at 03:49:15AM +, Malith Yapa wrote:
>>> >> I'm polling a couple of input bits as well as 16 bit memory registers 
>>> >> from
>>> >> a PLC (xinje) using libmodbus.
>>> >
>>> > Ah, so just normal tty use.
>>> >
>>> >> Feb 23 09:59:34 localhost kernel: [16960.073287] usb 5-1: USB disconnect,
>>> >> device number 11
>>> >> Feb 23 09:59:34 localhost kernel: [16960.080069] usb 5-1:
>>> >> pl2303_read_int_callback - usb_submit_urb failed with result -19
>>> >
>>> > You're getting these -ENODEV (-19) error because the pl2303 device has
>>> > already given up (crashed) and been disconnected.
>>> >
>>> >> Feb 23 09:59:35 localhost kernel: [16960.426637] usb 5-1: new full-speed
>>> >> USB device number 12 using sw-ohci
>>> >> Feb 23 09:59:35 localhost kernel: [16960.649900] usb 5-1: pl2303 
>>> >> converter
>>> >> now attached to ttyUSB10
>>> >
>>> >> Any pointers for a workaround at the driver level? I could see that 
>>> >> ENODEV
>>> >> results with the wrong device status. could that status be device 'busy'?
>>> >> will it help if i reduce my polling rate?
>>> >
>>> > I don't think there's anything to be done at the driver level I'm
>>> > afraid. If I understand you correctly, you're just using the normal tty
>>> > interface (e.g. through libmodbus) to access some external entity (and
>>> > its registers).
>>> >
>>> > Something is causing the pl2303 device to be reset. Perhaps an
>>> > electrical issue.
>>> >
>>> >> On Tue, Jul 5, 2016 at 6:09 PM Johan Hovold  wrote:
>>> >>
>>> >> > On Mon, Jul 04, 2016 at 10:22:04PM +0530, Malith Yapa wrote:
>>> >> > > Continuously polling registers with the PL2303 usb serial adapter
>>> >> > > eventually results in usb_subimit_urb failed with result -19 (ENODEV)
>>> >> > > but reconnects immediately.
>>> >> > > occurrences are random.
>>> >> > > tried with two different PL2303 devices with the same result.
>>> >> >
>>> >> > Sounds like a firmware issue, so not sure there's much we can do.
>>> >> >
>>> >> > Can you tell from the syslogs that the device is being disconnected and
>>> >> > re-enumerated? What registers are you polling?
>>>
>>> Ok. Thats fine with me as long as it reconnects. However since the
>>> device number keeps incrementing, I'm worried that it will fail
>>> sometime in the future. It failed a couple of times before (I think
>>> after reaching 255). I'm waiting for it to happen again to capture the
>>> syslog. Is there anyway i can force it to reconnect with the same
>>> id?(or come back to 0 after some time) what would be the maximum it
>>> can go upto?
>>
>> That would be 512 these days.
>>
>> The minor numbers are not reused until your application (or libmodbus)
>> releases them. The application should detect that the tty has been hung
>> up and close the tty device.
>>
>> Another thing you can try (to avoid the disconnect) is to verify that
>> you get the same behaviour using a different host controller (e.g. PC).
>> Try without any intermediate external hubs too.
>>
>> Good luck,
>> Johan
>
> Ok that makes sense. I think I've forgotten to close my modbus connection.
> On the disconnect issue, i don't have any external hubs. I'll try a
> different host, but if the minor numbers are reused my problem is
> largely solved :)
>
> Thanks a lot!
> Malith
--
To unsubsc

Re: [PATCH v6 3/5] usb: dwc3: add phyif_utmi_quirk

2016-07-12 Thread William.wu


Dear Rob,


On 2016/7/11 22:54, Rob Herring wrote:

On Fri, Jul 08, 2016 at 02:33:09PM +0200, Heiko Stuebner wrote:

Hi William,

Am Donnerstag, 7. Juli 2016, 10:54:24 schrieb William Wu:

Add a quirk to configure the core to support the
UTMI+ PHY with an 8- or 16-bit interface. UTMI+ PHY
interface is hardware property, and it's platform
dependent. Normall, the PHYIf can be configured
during coreconsultant. But for some specific usb
cores(e.g. rk3399 soc dwc3), the default PHYIf
configuration value is fault, so we need to
reconfigure it by software.

And refer to the dwc3 databook, the GUSB2PHYCFG.USBTRDTIM
must be set to the corresponding value according to
the UTMI+ PHY interface.

Signed-off-by: William Wu 
---

[...]

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt index 020b0e9..8d7317d
100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -42,6 +42,10 @@ Optional properties:
   - snps,dis-u2-freeclk-exists-quirk: when set, clear the
u2_freeclk_exists in GUSB2PHYCFG, specify that USB2 PHY doesn't provide
a free-running PHY clock.
+ - snps,phyif-utmi-quirk: when set core will set phyif UTMI+ interface.
+ - snps,phyif-utmi: the value to configure the core to support a UTMI+
PHY +   with an 8- or 16-bit interface. Value 0 select 8-bit
+   interface, value 1 select 16-bit interface.

maybe
snps,phyif-utmi-width = <8> or <16>;

Seems like this could be common. Any other bindings have something
similar already? If not "utmi-width" is fine.


It seems that there's not any dwc3 binding similar to this.
So I prefer to use “utmi-width”. :-)




devicetree is about describing the hardware, not the things that get written
to registers :-) . The conversion from the described width to the register
value can easily be done in the driver.


Also I don't think you need two properties for this. If the snps,phyif-utmi
property is specified it indicates that you want to manually set the width
and if it is absent you want to use the IC default. All functions reading
property-values indicate if the property is missing.

Agreed.

Rob






--
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 v6 5/5] usb: dwc3: rockchip: add devicetree bindings documentation

2016-07-12 Thread William.wu


Dear Rob,


On 2016/7/11 23:13, Rob Herring wrote:

On Thu, Jul 07, 2016 at 10:58:44AM +0800, William Wu wrote:

This patch adds the devicetree documentation required for Rockchip
USB3.0 core wrapper consisting of USB3.0 IP from Synopsys.

It supports DRD mode, and could operate in device mode (SS, HS, FS)
and host mode (SS, HS, FS, LS).

Signed-off-by: William Wu 
---
Changes in v6:
- rename bus_clk, and add usbdrd3_1 node as an example (Heiko)

Changes in v5:
- rename clock-names, and remove unnecessary clocks (Heiko)

Changes in v4:
- modify commit log, and add phy documentation location (Sergei)

Changes in v3:
- add dwc3 address (balbi)

Changes in v2:
- add rockchip,dwc3.txt to Documentation/devicetree/bindings/ (balbi, Brian)

  .../devicetree/bindings/usb/rockchip,dwc3.txt  | 59 ++
  1 file changed, 59 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/usb/rockchip,dwc3.txt

Acked-by: Rob Herring 


Thanks a lot. I'll add Acked-by next patch.








--
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 v6 3/5] usb: dwc3: add phyif_utmi_quirk

2016-07-12 Thread William.wu


Dear Rob,


On 2016/7/11 22:58, Rob Herring wrote:

On Thu, Jul 07, 2016 at 10:54:24AM +0800, William Wu wrote:

Add a quirk to configure the core to support the
UTMI+ PHY with an 8- or 16-bit interface. UTMI+ PHY
interface is hardware property, and it's platform
dependent. Normall, the PHYIf can be configured

s/Normall/Normally/

Yeah，I'll fix it.:-)

s/PHYIf/PHYIF/

Refer to DWC3 controller databook, "PHY Interface" called "PHYIf",
so I describe "PHYIf" here. However， "PHYIF”seems more the norm,
I'll fix it.:-)



during coreconsultant. But for some specific usb

s/usb/USB/


Thanks, I'll fix it.:-)




cores(e.g. rk3399 soc dwc3), the default PHYIf
configuration value is fault, so we need to
reconfigure it by software.

And refer to the dwc3 databook, the GUSB2PHYCFG.USBTRDTIM

s/dwc3/DWC3/

Thanks, I'll fix it too.



must be set to the corresponding value according to
the UTMI+ PHY interface.

And wrap your lines at 70-74 characters.


Thanks for your suggestion, I'll pay attention to this problem next 
patch.:-)


Best Regards，
William Wu


Rob






--
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: pl2303_read_int_callback - usb_submit_urb failed with result -19

2016-07-12 Thread Greg KH

On Wed, Jul 13, 2016 at 08:58:48AM +0530, Malith Yapa wrote:
> The reason for the random disconnects is apparently EMI related.
> 
> Mar  1 07:09:09 localhost kernel: [265922.921985] hub 5-0:1.0: port 1
> disabled by hub (EMI?), re-enabling...
> 
> This is very much a possibility because the box is in a high current
> industrial control panel. That is not an issue because the device
> automatically reconnects.
> But after a few day's operation it stops reconnecting and i finally
> managed to capture the syslog.
> 
> Mar  1 07:09:09 localhost kernel: [265922.934119] usb 5-1: USB
> disconnect, device number 83
> Mar  1 07:09:10 localhost kernel: [265923.245580] usb 5-1: new
> full-speed USB device number 84 using sw-ohci
> Mar  1 07:09:10 localhost kernel: [265923.451746] pl2303 5-1:1.0:
> pl2303 converter detected
> Mar  1 07:09:10 localhost kernel: [265923.486633] pl2303 5-1:1.0: No
> more free serial devices
> Mar  1 07:09:10 localhost kernel: [265923.496483] pl2303: probe of
> 5-1:1.0 failed with error -5
> Mar  1 07:09:10 localhost mtp-probe: checking bus 5, device 84:
> "/sys/devices/platform/sw-ohci.2/usb5/5-1"
> Mar  1 07:09:10 localhost mtp-probe: bus: 5, device: 84 was not an MTP device
> 
> The driver issues "No more free serial devices".
> 
> The two reasons i can see for this are either if the malloc fails (but
> there's no "out of memory" error) or if minor numbers have exceeded
> the limit. But the minor is only 84!
> 
> Any pointers for a solution?

Are you sure you are properly closing up the device node when the
disconnect happens?  That looks to be the problem here.

thanks,

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

Re: [PATCH 0/2] usb: add HCD providers

2016-07-12 Thread Peter Chen

On Tue, Jul 12, 2016 at 02:35:18PM +0200, Rafał Miłecki wrote:
> Hi,
> 
> I was working on an "usbport" LED trigger driver and specifying its
> default state in DT. I realized I can't really determine numbering of
> USB ports on any device as it depends on compiled drivers and the
> loading orders.
> 
> It means that my physical USB port can be e.g. 1-1 or 2-1 depending on
> my current config/setup. I needed a way to specify a particular HCD in
> DT and then hardcode port number (as this part doesn't change).
> 

I have a question:

What does your "usbport" LED trigger for? What kinds of information
you would like to show on LED?

Peter

> These 2 patches add providers to usb core subsystem. I successfully
> tested it with "usbport" trigger and generic-ohci, generic-ehci &
> generic-xhci.
> 
> The last (third) patch is not supposed to be applied, it's used only as
> a proof and example of how providers can be used.
> 
> If there is anything wrong with this idea/implementation, please let me
> know.
> 
> Rafał Miłecki (2):
>   usb: core: add support for HCD providers
>   ohci-platform: register HCD provider
> 
>  drivers/usb/core/Makefile|  1 +
>  drivers/usb/core/provider.c  | 79 
> 
>  drivers/usb/host/ohci-platform.c |  9 +
>  include/linux/usb/provider.h | 39 
>  4 files changed, 128 insertions(+)
>  create mode 100644 drivers/usb/core/provider.c
>  create mode 100644 include/linux/usb/provider.h
> 
> -- 
> 1.8.4.5
> 
> --
> 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

-- 

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: [PATCH 0/2] usb: add HCD providers

2016-07-12 Thread Rafał Miłecki

On 13 July 2016 at 06:51, Peter Chen  wrote:
> On Tue, Jul 12, 2016 at 02:35:18PM +0200, Rafał Miłecki wrote:
>> I was working on an "usbport" LED trigger driver and specifying its
>> default state in DT. I realized I can't really determine numbering of
>> USB ports on any device as it depends on compiled drivers and the
>> loading orders.
>>
>> It means that my physical USB port can be e.g. 1-1 or 2-1 depending on
>> my current config/setup. I needed a way to specify a particular HCD in
>> DT and then hardcode port number (as this part doesn't change).
>>
>
> I have a question:
>
> What does your "usbport" LED trigger for? What kinds of information
> you would like to show on LED?

It's a trigger that turns on LED whenever USB device appears at
specified USB port. There are plenty of home routers that have USB
labeled LED(s). To support them nicely, first of all we need a trigger
that will watch for USB subsystem events. Secondly we need a way to
setup its initial state correctly as most users don't want to play
with sysfs on their own.

I sent usbport trigger in:
[PATCH] leds: trigger: Introduce an USB port trigger
<1468239883-22695-1-git-send-email-zaj...@gmail.com>
https://lkml.org/lkml/2016/7/11/305
You may read commit message and ledtrig-usbport.txt for more details.

-- 
Rafał
--
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: pl2303_read_int_callback - usb_submit_urb failed with result -19

2016-07-12 Thread Malith Yapa

I think i am.

int readDword(int addr) {

uint16_t reg[1];// will store read registers values

int num = modbus_read_registers(ctx, addr, 1, reg); //16386 = X2

usleep(5);

if (num != 1) {
fprintf(stderr, "Failed(%i) to read: %s\n", num,
modbus_strerror(errno));
modbus_close(ctx);
modbus_free(ctx);
sleep(5);
int wait = 1;
while(initModbus()) {
cerr << "Waiting for PLC.. SLEEP[" << wait*20 << "]" << endl;
sleep(wait*20);
wait++;
}
}

return reg[0];
}

according to modbus documentation, "The modbus_close() function shall
close the connection established with the backend set in the context."

Even if not. Shouldn't the minor number's go upto 512 (as Johan
pointed out) before giving up?

The system is an Olimex A20-micro,
Linux version 3.4.90+ (gcc version 4.7.1 (Debian 4.7.1-7) )

Thanks,
Malith

On Wed, Jul 13, 2016 at 10:17 AM, Greg KH  wrote:
> On Wed, Jul 13, 2016 at 08:58:48AM +0530, Malith Yapa wrote:
>> The reason for the random disconnects is apparently EMI related.
>>
>> Mar  1 07:09:09 localhost kernel: [265922.921985] hub 5-0:1.0: port 1
>> disabled by hub (EMI?), re-enabling...
>>
>> This is very much a possibility because the box is in a high current
>> industrial control panel. That is not an issue because the device
>> automatically reconnects.
>> But after a few day's operation it stops reconnecting and i finally
>> managed to capture the syslog.
>>
>> Mar  1 07:09:09 localhost kernel: [265922.934119] usb 5-1: USB
>> disconnect, device number 83
>> Mar  1 07:09:10 localhost kernel: [265923.245580] usb 5-1: new
>> full-speed USB device number 84 using sw-ohci
>> Mar  1 07:09:10 localhost kernel: [265923.451746] pl2303 5-1:1.0:
>> pl2303 converter detected
>> Mar  1 07:09:10 localhost kernel: [265923.486633] pl2303 5-1:1.0: No
>> more free serial devices
>> Mar  1 07:09:10 localhost kernel: [265923.496483] pl2303: probe of
>> 5-1:1.0 failed with error -5
>> Mar  1 07:09:10 localhost mtp-probe: checking bus 5, device 84:
>> "/sys/devices/platform/sw-ohci.2/usb5/5-1"
>> Mar  1 07:09:10 localhost mtp-probe: bus: 5, device: 84 was not an MTP device
>>
>> The driver issues "No more free serial devices".
>>
>> The two reasons i can see for this are either if the malloc fails (but
>> there's no "out of memory" error) or if minor numbers have exceeded
>> the limit. But the minor is only 84!
>>
>> Any pointers for a solution?
>
> Are you sure you are properly closing up the device node when the
> disconnect happens?  That looks to be the problem here.
>
> thanks,
>
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Add MediaTek USB3 DRD Driver

2016-07-12 Thread chunfeng yun

Hi Felipe:

Could you please give me some suggestions if you have already reviewed
some codes.

Thanks a lot.


On Wed, 2016-06-15 at 11:07 +0800, Chunfeng Yun wrote:
> From 48552e96e4e33f8830cb6a59154fe148425532fd Mon Sep 17 00:00:00 2001
> From: Chunfeng Yun 
> Date: Wed, 15 Jun 2016 10:58:10 +0800
> Subject: [PATCH v4,0/5] Add MediaTek USB3 DRD Driver
> 
> These patches introduce the MediaTek USB3 dual-role controller
> driver.
> 
> The driver can be configured as Dual-Role Device (DRD),
> Peripheral Only and Host Only (xHCI) modes. It works well
> with Mass Storage, RNDIS and g_zero on FS/HS and SS. And it is
> tested on MT8173 platform which only contains USB2.0 device IP,
> and on MT6290 platform which contains USB3.0 device IP.
> 
> Change in v4:
> 1. fix build errors on non-mediatek platforms
> 2. provide manual dual-role switch via debugfs instead of sysfs
> 

> --
> 1.7.9.5
> 
> 


--
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 v6 RESEND] r8152: Add support for setting pass through MAC address on RTL8153-AD

2016-07-12 Thread Michał Pecio

> So in order to hit this hypothetical corner case today you would 
> need to be using a real world type-C device something such as a 
> Dell WD15 on another OEM's machine that has type-C and the exact
> same ACPI object name that does $BADSTUFF other than return a
> buffer.
Exactly what I meant.
 
> If that situation arises please alert me and I'll send a follow up
> patch that whitelists this to match DMI vendor of only Dell 
> systems.
I'm not sure if it's the most responsible way to approach this problem.
There were cases of laptops bricking (as in - they would never power on
ever again) just because Linux made some bad BIOS/ACPI calls. Also, see
the famous Samsung UEFI NVRAM fiasco or the recent pains with EFIVARS.

Regards,
MP
--
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 v6 RESEND] r8152: Add support for setting pass through MAC address on RTL8153-AD

Re: Problem getting USB DAC to work

Re: usb-serial remembers termios settings between device replugs

[PATCH] scsi: introduce a quirk for false cache reporting

RE: [PATCH v2 1/5] drivers: usb: chipidea: Add qoriq platform driver

[PATCH 1/2] doc: usb: usbmisc-imx: add imx7d compatible string

[PATCH v3] usb: gadget: f_midi: Add checking if it need align buffer's size to an ep's maxpacketsize

[PATCH 2/2] usb: chipidea: usbmisc: set over current polarity for imx6 and imx7

RE: [PATCH] usb:solve resume usb device identification problem

[PATCH 0/2] usb: add HCD providers

[PATCH PROOF OF CONCEPT 3/2] trigger: ledtrig-usbport: read initial state from DT

[PATCH 2/2] ohci-platform: register HCD provider

[PATCH 1/2] usb: core: add support for HCD providers

RE: [PATCH v6 RESEND] r8152: Add support for setting pass through MAC address on RTL8153-AD

Re: mceusb xhci issue?

[PATCH v2 5/6] usb: chipidea: let chipidea core device of_node equal's glue layer device of_node

[PATCH v2 6/6] ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property

[PATCH v2 3/6] binding-doc: usb: usb-device: add optional properties for power sequence

[PATCH v2 1/6] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library

[PATCH v2 2/6] power: add power sequence library

[PATCH v2 4/6] usb: core: add power sequence handling for USB devices

[PATCH v2 0/6] power: add power sequence library

Re: [PATCH v6 3/5] usb: dwc3: add phyif_utmi_quirk

Re: pl2303_read_int_callback - usb_submit_urb failed with result -19

Re: [PATCH v6 3/5] usb: dwc3: add phyif_utmi_quirk

Re: [PATCH v6 5/5] usb: dwc3: rockchip: add devicetree bindings documentation

Re: [PATCH v6 3/5] usb: dwc3: add phyif_utmi_quirk

Re: pl2303_read_int_callback - usb_submit_urb failed with result -19

Re: [PATCH 0/2] usb: add HCD providers

Re: [PATCH 0/2] usb: add HCD providers

Re: pl2303_read_int_callback - usb_submit_urb failed with result -19

Re: Add MediaTek USB3 DRD Driver

Re: [PATCH v6 RESEND] r8152: Add support for setting pass through MAC address on RTL8153-AD

33 matches

Site Navigation

Mail list logo

Footer information