Re: [PATCH 1/3] pinctrl: Intel: add RX invertion config

[Linus Walleij]

On Wed, Mar 16, 2016 at 2:34 PM, Daniel Vetter  wrote:
> On Wed, Mar 16, 2016 at 01:27:49PM +0100, Linus Walleij wrote:

>> - What is a HPD interrupt?
>
> hotplug interrupt, fires when you plug in a cable.
>
>> - What is a Type-C DP HPD?
>
> usb type C connector can multiplex both DisplayPort and USB, you need to
> renegotiate the lane splitting every time the sink changes, i.e. on each
> hotplug.

OK I understand, thanks a lot!

>> - Again why can't you just use a notifier or function call?
>
> Because windows sucks, hence all that coordination happens through hw
> forwarded interrupts and magic registers. Same horror story on the sound
> side, where the sound driver needs to know what kind of PCM stream the
> monitor can take. It's hilarious. Except when they screw up the design and
> then need to fake parts of it in software.

So the story is something like that these IRQs have been put into
hardware in order to compensate for flaws in Windows device driver
model, I see.

If there are such special registers in some hardware I guess I'm all for
implementing some generic quirk in gpiolib for people who need to
software-trigger GPIO IRQs. Could be good for testing too, as there
are such registers in ARMs PL061 GPIO controller for test, just so as
to simulate a GPIO IRQ.

gpiod_trig_irq() would work with me, I'm happy to support whatever
the GPIO hardware can do usually.

> In sound we've switched over to a proper sw interface, and we tie the
> different parts (drm graphics driver and alsa snd driver) using the
> component.c framework.

Hm is that solution or something similar proper for USB connector
as well I wonder... I was thinking about just adding $random_notifier
but maybe that is a bit ugly :/

>> What is VPG? Now it seems Intel's internal organization is being used as
>> part of the argument to get this change in and that makes me a bit
>> annoyed.
(...)
> There was chat of usb type C support for forever, but I was always
> promised that we don't need any interactions on the sw side and it's all
> magic in hw. There hasn't been any real design discussions in the open
> source group. VPG is the hw/windows group and generally comes up with
> "interesting" designs not suitable for upstream.
>
> Feel free to just nack this stuff, and please cc intel-gfx/dri-devel in
> the future (since I tend to ignore everything that's not cc'ed to mailing
> lists I don't care about, even when I'm on cc personally). I've added them
> all to cc.

Thanks a lot Daniel, I understand better now. I'm not really against
adding this "interesting" workaround if that is how Windows works,
we usually have to go by their standards. From the GPIO point
of view it is OK, just something the GPIO can do. I would be more
worried about what the USB PHY maintainer (Felipe) is going to say
about this.

Yours,
Linus Walleij
--
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: rtl8xxxu 4.4.5(from f23): I get a panic adding a new device to the driver

[Jes Sorensen]

poma  writes:
> On 17.03.2016 19:02, Jes Sorensen wrote:
>> Jes Sorensen  writes:
>>> Xose Vazquez Perez  writes:
 Hi,

 If I do:
 # echo "0bda 8176" > /sys/bus/usb/drivers/rtl8xxxu/new_id
>>>
>>> Hi Xose,
>>>
>>> Yes please don't do that. The rtl8xxxu driver relies on the .driver_info
>>> field in struct use_device_id to carry information for the different
>>> types of devices. If you hot add a device like above, the driver will
>>> fail because that field now contains a NULL pointer.
>>>
>>> I should probably add a check for it in the probe function, but it will
>>> simply be there to spit out a warning that it doesn't work to hot add a
>>> device like this.
>>>
>>> If you build it with CONFIG_RTL8XXXU_UNTESTED the 0bda:8176 should be
>>> included in the device list.
>>>
>>> Cheers,
>>> Jes
>> 
>> Hi Xose,
>> 
>> I added the following patch to my tree to avoid this.
>> 
>> Cheers,
>> Jes
>> 
>> commit 9202f4947aac1d60084ee79c9b5294eb42ba59dc
>> Author: Jes Sorensen 
>> Date:   Thu Mar 17 13:53:48 2016 -0400
>> 
>> rtl8xxxu: Fix OOPS if user tries to add device via /sys
>> 
>> This driver relies on driver_info in struct usb_device_id, hence
>> adding a device via  /sys/bus/usb/drivers/rtl8xxxu/new_id would result
>> in a NULL pointer dereference.
>> 
>> Instead print a message and return -ENODEV
>> 
>> Reported-by: Xose Vazquez Perez 
>> Signed-off-by: Jes Sorensen 
>> 
>> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.c 
>> b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.c
>> index 8d893f4..55fc00e 100644
>> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.c
>> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.c
>> @@ -9671,6 +9671,15 @@ static int rtl8xxxu_probe(struct usb_interface 
>> *interface,
>>  
>>  udev = usb_get_dev(interface_to_usbdev(interface));
>>  
>> +if (!id->driver_info) {
>> +dev_warn(>dev,
>> + "rtl8xxxu relies on driver_info in struct 
>> usb_device_id.\n");
>> +dev_warn(>dev,
>> + "Adding a device via 
>> /sys/bus/usb/drivers/rtl8xxxu/new_id is not supported!\n");
>> +ret = -ENODEV;
>> +goto exit;
>> +}
>> +
>>  switch (id->idVendor) {
>>  case USB_VENDOR_ID_REALTEK:
>>  switch(id->idProduct) {
>
> Dynamic adding and removing a new device IDs to a USB device drivers
> via /sys/bus/usb/drivers/.../[new_id|remove_id]
> https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-bus-usb
>
> is not supported only with rtl8xxxu?

Dynamically adding one will not work. The driver relies on driver_info
in struct usb_device_id() to carry the struct fileops associated with
the device type and you cannot specify this via the USB add operation.

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

[PATCH v2 10/11] usb: musb: da8xx: Use devm in probe

[David Lechner]

Simplify things a bit by using devm functions where possible.

Signed-off-by: David Lechner 
---

v2 changes: This is part of a previous patch that was split. No changes from
previous version.


 drivers/usb/musb/da8xx.c | 28 
 1 file changed, 8 insertions(+), 20 deletions(-)

diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index b03d3b8..50f07a5 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -489,32 +489,27 @@ static int da8xx_probe(struct platform_device *pdev)
struct platform_device  *musb;
struct da8xx_glue   *glue;
struct platform_device_info pinfo;
-   struct clk  *clk;
+   int ret;
 
-   int ret = -ENOMEM;
-
-   glue = kzalloc(sizeof(*glue), GFP_KERNEL);
+   glue = devm_kzalloc(>dev, sizeof(*glue), GFP_KERNEL);
if (!glue) {
dev_err(>dev, "failed to allocate glue context\n");
-   goto err0;
+   return -ENOMEM;
}
 
-   clk = clk_get(>dev, "usb20");
-   if (IS_ERR(clk)) {
+   glue->clk = devm_clk_get(>dev, "usb20");
+   if (IS_ERR(glue->clk)) {
dev_err(>dev, "failed to get clock\n");
-   ret = PTR_ERR(clk);
-   goto err3;
+   return PTR_ERR(glue->clk);
}
 
-   ret = clk_enable(clk);
+   ret = clk_enable(glue->clk);
if (ret) {
dev_err(>dev, "failed to enable clock\n");
goto err4;
}
 
glue->dev   = >dev;
-   glue->clk   = clk;
-
pdata->platform_ops = _ops;
 
glue->phy = usb_phy_generic_register();
@@ -557,15 +552,10 @@ err6:
usb_phy_generic_unregister(glue->phy);
 
 err5:
-   clk_disable(clk);
+   clk_disable(glue->clk);
 
 err4:
-   clk_put(clk);
-
-err3:
-   kfree(glue);
 
-err0:
return ret;
 }
 
@@ -576,8 +566,6 @@ static int da8xx_remove(struct platform_device *pdev)
platform_device_unregister(glue->musb);
usb_phy_generic_unregister(glue->phy);
clk_disable(glue->clk);
-   clk_put(glue->clk);
-   kfree(glue);
 
return 0;
 }
-- 
1.9.1

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

Re: [PATCH v5 6/6] mfd: intel_vuport: Add Intel virtual USB port MFD Driver

[Lu Baolu]

On 03/18/2016 04:09 PM, Lee Jones wrote:
> On Fri, 18 Mar 2016, Lu Baolu wrote:
>
>> Some Intel platforms have an USB port mux controlled by GPIOs.
>> There's a single ACPI platform device that provides both USB ID
>> extcon device and a USB port mux device. This MFD driver will
>> split the 2 devices for their respective drivers.
>>
>> Signed-off-by: Lu Baolu 
>> Suggested-by: David Cohen 
> This should be at the top.
>
> You couldn't have written the patch before it was suggested.

Yes. I will change this.

>
>> Reviewed-by: Felipe Balbi 
>> Signed-off-by: Fengguang Wu 
> What is this sign-off meant to indicate?

Fengguang's sign-off was added due to folding a patch contributed by
his kbuild robot.

https://lkml.org/lkml/2016/3/3/118

I will add this in commit message.

>
>> Reviewed-by: Lee Jones 
> Why is this here?
>
> a) I don't provide "Reviewed-by:" tags #alarmbells
> b) I have never signed this patch off

Sorry about this. I will remove this line.

>
>> ---
>>  MAINTAINERS|  6 
> Seperate patch.

If I make it in a separate patch, checkpatch.pl will give me below warning.

"
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#51:
new file mode 100644
"

Is it forgivable?

Best regards,
Baolu

>
>>  drivers/mfd/Kconfig|  8 +
>>  drivers/mfd/Makefile   |  1 +
>>  drivers/mfd/intel-vuport.c | 74 
>> ++
>>  4 files changed, 89 insertions(+)
>>  create mode 100644 drivers/mfd/intel-vuport.c
> [...]
>

--
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: "reset full-speed USB device number 6 using ehci-pci" with Dell Inspiron 15R 5537

[Daniel Fraga]

On Fri, 18 Mar 2016 12:36:42 -0400 (EDT)
Alan Stern  wrote:

> All right, I have taken Oliver's suggestion.  The patch below refactors 
> the code to consolidate the common activities in a new function, 
> hid_restart_io().
> 
> Daniel, can you please test this patch?

Alan, this patch works perfectly ;) Thanks.

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

[PATCH v7 3/4] gadget: Integrate with the usb gadget supporting for usb charger

[Baolin Wang]

When the usb gadget supporting for usb charger is ready, the usb charger
should get the type by the 'get_charger_type' callback which is implemented
by the usb gadget operations, and get the usb charger pointer from struct
'usb_gadget'.

Signed-off-by: Baolin Wang 
---
 drivers/usb/gadget/charger.c |   43 --
 1 file changed, 41 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/charger.c b/drivers/usb/gadget/charger.c
index 82a9973..76e1a6f 100644
--- a/drivers/usb/gadget/charger.c
+++ b/drivers/usb/gadget/charger.c
@@ -272,7 +272,11 @@ EXPORT_SYMBOL_GPL(usb_charger_unregister_notify);
 enum usb_charger_type
 usb_charger_detect_type(struct usb_charger *uchger)
 {
-   if (uchger->psy) {
+   if (uchger->gadget && uchger->gadget->ops
+   && uchger->gadget->ops->get_charger_type) {
+   uchger->type =
+   uchger->gadget->ops->get_charger_type(uchger->gadget);
+   } else if (uchger->psy) {
union power_supply_propval val;
 
power_supply_get_property(uchger->psy,
@@ -479,6 +483,29 @@ usb_charger_plug_by_extcon(struct notifier_block *nb,
 int usb_charger_plug_by_gadget(struct usb_gadget *gadget,
   unsigned long state)
 {
+   struct usb_charger *uchger = gadget->charger;
+   enum usb_charger_state uchger_state;
+
+   if (!uchger)
+   return -EINVAL;
+
+   /* Report event to power to setting the current limitation
+* for this usb charger when one usb charger state is changed
+* with detecting by usb gadget state.
+*/
+   if (uchger->old_gadget_state != state) {
+   uchger->old_gadget_state = state;
+
+   if (state >= USB_STATE_ATTACHED)
+   uchger_state = USB_CHARGER_PRESENT;
+   else if (state == USB_STATE_NOTATTACHED)
+   uchger_state = USB_CHARGER_REMOVE;
+   else
+   uchger_state = USB_CHARGER_DEFAULT;
+
+   usb_charger_notify_others(uchger, uchger_state);
+   }
+
return 0;
 }
 EXPORT_SYMBOL_GPL(usb_charger_plug_by_gadget);
@@ -635,6 +662,7 @@ int usb_charger_init(struct usb_gadget *ugadget)
 
/* register a notifier on a usb gadget device */
uchger->gadget = ugadget;
+   ugadget->charger = uchger;
uchger->old_gadget_state = ugadget->state;
 
/* register a new usb charger */
@@ -655,7 +683,18 @@ fail:
 
 int usb_charger_exit(struct usb_gadget *ugadget)
 {
-   return 0;
+   struct usb_charger *uchger = ugadget->charger;
+
+   if (!uchger)
+   return -EINVAL;
+
+   if (uchger->extcon_dev)
+   extcon_unregister_notifier(uchger->extcon_dev,
+  EXTCON_USB, >extcon_nb.nb);
+
+   ida_simple_remove(_charger_ida, uchger->id);
+
+   return usb_charger_unregister(uchger);
 }
 
 static int __init usb_charger_sysfs_init(void)
-- 
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: [GIT PULL] USB driver patches for 4.6-rc1

[Linus Torvalds]

On Fri, Mar 18, 2016 at 3:51 PM, Linus Torvalds
 wrote:
>
> The commit that ends up being marked bad is odd, but there it is:
> 69bec7259853 "USB: core: let USB device know device node".

Confirmed. Not only did it bisect to that, reverting it on top of the
current kernel fixes my machine.

So that commit is somehow buggy. I don't see what it does that would
break even with OF disabled, but something does.

I'll just revert it. The way it is done seems bogus anyway.  It looks
at of_node when OF is disabled, but generally that isn't even
initialized as far as I can tell, and we have things like
dev_of_node() helpers to make sure you don't do that.

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

[PATCH v1 2/5] usb: gadget: pch_udc: convert to devres API

[Andy Shevchenko]

devres API allows to make error paths cleaner and less error prone. Convert the
driver to use it.

Signed-off-by: Andy Shevchenko 
---
 drivers/usb/gadget/udc/pch_udc.c | 98 +++-
 1 file changed, 26 insertions(+), 72 deletions(-)

diff --git a/drivers/usb/gadget/udc/pch_udc.c b/drivers/usb/gadget/udc/pch_udc.c
index b751126..49fd97f 100644
--- a/drivers/usb/gadget/udc/pch_udc.c
+++ b/drivers/usb/gadget/udc/pch_udc.c
@@ -325,11 +325,8 @@ struct pch_vbus_gpio_data {
  * @pdev:  reference to the PCI device
  * @ep:array of endpoints
  * @lock:  protects all state
- * @active:enabled the PCI device
  * @stall: stall requested
  * @prot_stall:protcol stall requested
- * @irq_registered:irq registered with system
- * @mem_region:device memory mapped
  * @registered:driver registered with system
  * @suspended: driver in suspended state
  * @connected: gadget driver associated
@@ -339,12 +336,8 @@ struct pch_vbus_gpio_data {
  * @data_requests: DMA pool for data requests
  * @stp_requests:  DMA pool for setup requests
  * @dma_addr:  DMA pool for received
- * @ep0out_buf:Buffer for DMA
  * @setup_data:Received setup data
- * @phys_addr: of device memory
  * @base_addr: for mapped device memory
- * @bar:   Indicates which PCI BAR for USB regs
- * @irq:   IRQ line for the device
  * @cfg_data:  current cfg, intf, and alt in use
  * @vbus_gpio: GPIO informaton for detecting VBUS
  */
@@ -354,11 +347,9 @@ struct pch_udc_dev {
struct pci_dev  *pdev;
struct pch_udc_ep   ep[PCH_UDC_EP_NUM];
spinlock_t  lock; /* protects all state */
-   unsignedactive:1,
+   unsigned
stall:1,
prot_stall:1,
-   irq_registered:1,
-   mem_region:1,
suspended:1,
connected:1,
vbus_session:1,
@@ -367,12 +358,8 @@ struct pch_udc_dev {
struct pci_pool *data_requests;
struct pci_pool *stp_requests;
dma_addr_t  dma_addr;
-   void*ep0out_buf;
struct usb_ctrlrequest  setup_data;
-   unsigned long   phys_addr;
void __iomem*base_addr;
-   unsignedbar;
-   unsignedirq;
struct pch_udc_cfg_data cfg_data;
struct pch_vbus_gpio_data   vbus_gpio;
 };
@@ -2949,6 +2936,7 @@ static int init_dma_pools(struct pch_udc_dev *dev)
 {
struct pch_udc_stp_dma_desc *td_stp;
struct pch_udc_data_dma_desc*td_data;
+   void*ep0out_buf;
 
/* DMA setup */
dev->data_requests = pci_pool_create("data_requests", dev->pdev,
@@ -2991,10 +2979,11 @@ static int init_dma_pools(struct pch_udc_dev *dev)
dev->ep[UDC_EP0IN_IDX].td_data = NULL;
dev->ep[UDC_EP0IN_IDX].td_data_phys = 0;
 
-   dev->ep0out_buf = kzalloc(UDC_EP0OUT_BUFF_SIZE * 4, GFP_KERNEL);
-   if (!dev->ep0out_buf)
+   ep0out_buf = devm_kzalloc(>pdev->dev, UDC_EP0OUT_BUFF_SIZE * 4,
+ GFP_KERNEL);
+   if (!ep0out_buf)
return -ENOMEM;
-   dev->dma_addr = dma_map_single(>pdev->dev, dev->ep0out_buf,
+   dev->dma_addr = dma_map_single(>pdev->dev, ep0out_buf,
   UDC_EP0OUT_BUFF_SIZE * 4,
   DMA_FROM_DEVICE);
return 0;
@@ -3078,22 +3067,10 @@ static void pch_udc_remove(struct pci_dev *pdev)
if (dev->dma_addr)
dma_unmap_single(>pdev->dev, dev->dma_addr,
 UDC_EP0OUT_BUFF_SIZE * 4, DMA_FROM_DEVICE);
-   kfree(dev->ep0out_buf);
 
pch_vbus_gpio_free(dev);
 
pch_udc_exit(dev);
-
-   if (dev->irq_registered)
-   free_irq(pdev->irq, dev);
-   if (dev->base_addr)
-   iounmap(dev->base_addr);
-   if (dev->mem_region)
-   release_mem_region(dev->phys_addr,
-  pci_resource_len(pdev, dev->bar));
-   if (dev->active)
-   pci_disable_device(pdev);
-   kfree(dev);
 }
 
 #ifdef CONFIG_PM_SLEEP
@@ -3122,69 +3099,46 @@ static SIMPLE_DEV_PM_OPS(pch_udc_pm, pch_udc_suspend, 
pch_udc_resume);
 static int pch_udc_probe(struct pci_dev *pdev,
  const struct pci_device_id *id)
 {
-   unsigned long   resource;
-   unsigned long   len;
+   int bar;
int retval;
 

RE: [PATCH 2/3] usb: dwc3: increase maximum number of TRBs per endpoint

[David Laight]

From: Felipe Balbi
> Bin Liu  writes:
> > [ text/plain ]
> > Hi,
> >
> > On Fri, Mar 11, 2016 at 6:54 AM, Felipe Balbi
> >  wrote:
> >> previously we were using a maximum of 32 TRBs per
> >> endpoint. With each TRB being 16 bytes long, we were
> >> using 512 bytes of memory for each endpoint.
> >>
> >> However, SLAB/SLUB will always allocate PAGE_SIZE
> >> chunks. In order to better utilize the memory we
> >> allocate and to allow deeper queues for gadgets
> >> which would benefit from it (g_ether comes to mind),
> >> let's increase the maximum to 256 TRBs which rounds
> >> up to 4096 bytes for each endpoint.
> >
> > Do we want to increase the same for event ring buffers as
> > while, which is allocated by dma_alloc_coherent(), which
> > is also at PAGE_SIZE chunks, right?
> 
> I could, but that's much less important. Currently we have up to 2
> events per endpoint which is very, very unlikely to happen. Plus, in
> that case there's no tangible benefit. $subject, however, I've been
> using on some performance optimization I've been trying to achieve (not
> ready for submission just yet).

Is it worth considering using a single mapped page for the small rings
of multiple devices?

David

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

Re: [GIT PULL] USB driver patches for 4.6-rc1

[Linus Torvalds]

On Wed, Mar 16, 2016 at 5:09 PM, Greg KH  wrote:
>
> USB patches for 4.6-rc1
>
> Here is the big USB patchset for 4.6-rc1.

Something in this - or possibly the tty pull, but that doesn't sound
very likely - has killed my USB keyboard on my desktop.

I'm bisecting right now. Expect a likely revert.

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

ehci and ohci reset number doubt

[Lipengcheng]

Hi,
   In the files of ohci-platform.c and ehci-platform.c, they have only a 
control reset. Can the files have one more controller reset?
   Our usb2 controller using a synopsis, need bus reset, root hub reset, utmi 
reset. The usb controller of reset and clock have the same number.
   Such as:

Thanks very much

Best Regards,

Pengcheng Li
 

[PATCH v4 0/7] usb: add support for Intel dual role port mux

[Lu Baolu]

Intel SOC chips are featured with USB dual role. The host role is
provided by Intel xHCI IP, and the gadget role is provided by IP
from designware. Tablet platform designs always share a single
port for both host and gadget controllers. There is a mux to
switch the port to the right controller according to the cable
type. OS needs to provide the callback to control the mux when
a plug-in event raises. The method to control the mux is platform
dependent. At least three types of implementation can be found
across current devices. 1) GPIO pins; 2) a unit which can be
controlled by memory mapped registers; 3) ACPI ASL code.

This patch series adds supports for Intel dual role port mux.
It includes:
(1) A helper layer on top of extcon for individual mux driver.
It listens to the USB-HOST extcon cable and call the switch
call-back when the cable state changes.
(2) Drivers for GPIO controlled port mux which could be found on
Baytrail devices. A mfd driver is used to split the GPIOs into
USB gpio extcon device and a USB mux device. Driver for USB
gpio extcon device is already in upstream Linux. This patch
series includes a driver for GPIO USB mux.
(3) Drivers for USB port mux controlled through memory mapped
registers and the logic to create the mux device. This type
of dual role port mux could be found in Cherry Trail and
Broxton devices.

Lu Baolu (7):
  extcon: usb-gpio: add device binding for platform device
  extcon: usb-gpio: add support for ACPI gpio interface
  usb: mux: add common code for Intel dual role port mux
  usb: mux: add driver for Intel gpio controlled port mux
  usb: mux: add driver for Intel drcfg controlled port mux
  usb: pci-quirks: add Intel USB drcfg mux device
  mfd: intel_vuport: Add Intel virtual USB port MFD Driver

Change log:
v3->v4:
 - Check all patches with "checkpatch.pl --strict", and fix all
   CHECKs;
 - Change sysfs node from "intel_mux" to "port_mux";
 - Refines below confusing functions:
   intel_usb_mux_register() -> intel_usb_mux_bind_cable()
   intel_usb_mux_unregister() -> intel_usb_mux_unbind_cable();
 - Remove unnecessary struct intel_mux_dev.

v2->v3:
 - uvport mfd driver got reviewed by Lee Jones, the following
   changes were made accordingly.
 - seperate uvport driver from the mux drivers in MAINTAINERS file
 - refine the description in Kconfig
 - refine the mfd_cell structure data

v1->v2:
 - move mux driver from drivers/usb/misc to drivers/usb/mux;
 - replace debugfs with sysfs for user level mux control;
 - remove unnecessary register restore if mux registeration failed;
 - Add "Acked-by: Chanwoo Choi " to extcon changes;
 - Make the file names and exported function names more specific;
 - Remove the usb_mux_get_dev() interface;
 - Move "struct intel_usb_mux" from .h to .c file;
 - Fix various kbuild robot warnings.

 Documentation/ABI/testing/sysfs-bus-platform |  15 +++
 MAINTAINERS  |  15 +++
 drivers/extcon/extcon-usb-gpio.c |  10 +-
 drivers/mfd/Kconfig  |   8 ++
 drivers/mfd/Makefile |   1 +
 drivers/mfd/intel-vuport.c   |  74 +++
 drivers/usb/Kconfig  |   2 +
 drivers/usb/Makefile |   1 +
 drivers/usb/host/pci-quirks.c|  47 ++-
 drivers/usb/host/xhci-ext-caps.h |   2 +
 drivers/usb/mux/Kconfig  |  28 +
 drivers/usb/mux/Makefile |   6 +
 drivers/usb/mux/intel-mux-drcfg.c| 157 +++
 drivers/usb/mux/intel-mux-gpio.c | 120 ++
 drivers/usb/mux/intel-mux.c  | 180 +++
 include/linux/usb/intel-mux.h|  43 +++
 16 files changed, 706 insertions(+), 3 deletions(-)
 create mode 100644 drivers/mfd/intel-vuport.c
 create mode 100644 drivers/usb/mux/Kconfig
 create mode 100644 drivers/usb/mux/Makefile
 create mode 100644 drivers/usb/mux/intel-mux-drcfg.c
 create mode 100644 drivers/usb/mux/intel-mux-gpio.c
 create mode 100644 drivers/usb/mux/intel-mux.c
 create mode 100644 include/linux/usb/intel-mux.h

-- 
2.1.4

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

[PATCH v1 4/5] usb: gadged: pch_udc: get rid of redundant assignments

[Andy Shevchenko]

It seems there are leftovers of some assignments which are not used anymore.
Compiler even warns us about:

drivers/usb/gadget/udc/pch_udc.c:2022:22: warning: variable ‘dev’ set but not 
used [-Wunused-but-set-variable]

drivers/usb/gadget/udc/pch_udc.c:2639:9: warning: variable ‘ret’ set but not 
used [-Wunused-but-set-variable]

Remove them and shut compiler about.

Signed-off-by: Andy Shevchenko 
---
 drivers/usb/gadget/udc/pch_udc.c | 18 --
 1 file changed, 4 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/gadget/udc/pch_udc.c b/drivers/usb/gadget/udc/pch_udc.c
index 7736799..ece7a31 100644
--- a/drivers/usb/gadget/udc/pch_udc.c
+++ b/drivers/usb/gadget/udc/pch_udc.c
@@ -1719,14 +1719,12 @@ static int pch_udc_pcd_ep_enable(struct usb_ep *usbep,
 static int pch_udc_pcd_ep_disable(struct usb_ep *usbep)
 {
struct pch_udc_ep   *ep;
-   struct pch_udc_dev  *dev;
unsigned long   iflags;
 
if (!usbep)
return -EINVAL;
 
ep = container_of(usbep, struct pch_udc_ep, ep);
-   dev = ep->dev;
if ((usbep->name == ep0_string) || !ep->ep.desc)
return -EINVAL;
 
@@ -1757,12 +1755,10 @@ static struct usb_request *pch_udc_alloc_request(struct 
usb_ep *usbep,
struct pch_udc_request  *req;
struct pch_udc_ep   *ep;
struct pch_udc_data_dma_desc*dma_desc;
-   struct pch_udc_dev  *dev;
 
if (!usbep)
return NULL;
ep = container_of(usbep, struct pch_udc_ep, ep);
-   dev = ep->dev;
req = kzalloc(sizeof *req, gfp);
if (!req)
return NULL;
@@ -1935,12 +1931,10 @@ static int pch_udc_pcd_dequeue(struct usb_ep *usbep,
 {
struct pch_udc_ep   *ep;
struct pch_udc_request  *req;
-   struct pch_udc_dev  *dev;
unsigned long   flags;
int ret = -EINVAL;
 
ep = container_of(usbep, struct pch_udc_ep, ep);
-   dev = ep->dev;
if (!usbep || !usbreq || (!ep->ep.desc && ep->num))
return ret;
req = container_of(usbreq, struct pch_udc_request, req);
@@ -1972,14 +1966,12 @@ static int pch_udc_pcd_dequeue(struct usb_ep *usbep,
 static int pch_udc_pcd_set_halt(struct usb_ep *usbep, int halt)
 {
struct pch_udc_ep   *ep;
-   struct pch_udc_dev  *dev;
unsigned long iflags;
int ret;
 
if (!usbep)
return -EINVAL;
ep = container_of(usbep, struct pch_udc_ep, ep);
-   dev = ep->dev;
if (!ep->ep.desc && !ep->num)
return -EINVAL;
if (!ep->dev->driver || (ep->dev->gadget.speed == USB_SPEED_UNKNOWN))
@@ -2017,14 +2009,12 @@ static int pch_udc_pcd_set_halt(struct usb_ep *usbep, 
int halt)
 static int pch_udc_pcd_set_wedge(struct usb_ep *usbep)
 {
struct pch_udc_ep   *ep;
-   struct pch_udc_dev  *dev;
unsigned long iflags;
int ret;
 
if (!usbep)
return -EINVAL;
ep = container_of(usbep, struct pch_udc_ep, ep);
-   dev = ep->dev;
if (!ep->ep.desc && !ep->num)
return -EINVAL;
if (!ep->dev->driver || (ep->dev->gadget.speed == USB_SPEED_UNKNOWN))
@@ -2634,7 +2624,7 @@ static void pch_udc_svc_enum_interrupt(struct pch_udc_dev 
*dev)
 static void pch_udc_svc_intf_interrupt(struct pch_udc_dev *dev)
 {
u32 reg, dev_stat = 0;
-   int i, ret;
+   int i;
 
dev_stat = pch_udc_read_device_status(dev);
dev->cfg_data.cur_intf = (dev_stat & UDC_DEVSTS_INTF_MASK) >>
@@ -2663,7 +2653,7 @@ static void pch_udc_svc_intf_interrupt(struct pch_udc_dev 
*dev)
}
dev->stall = 0;
spin_lock(>lock);
-   ret = dev->driver->setup(>gadget, >setup_data);
+   dev->driver->setup(>gadget, >setup_data);
spin_unlock(>lock);
 }
 
@@ -2674,7 +2664,7 @@ static void pch_udc_svc_intf_interrupt(struct pch_udc_dev 
*dev)
  */
 static void pch_udc_svc_cfg_interrupt(struct pch_udc_dev *dev)
 {
-   int i, ret;
+   int i;
u32 reg, dev_stat = 0;
 
dev_stat = pch_udc_read_device_status(dev);
@@ -2700,7 +2690,7 @@ static void pch_udc_svc_cfg_interrupt(struct pch_udc_dev 
*dev)
 
/* call gadget zero with setup data received */
spin_lock(>lock);
-   ret = dev->driver->setup(>gadget, >setup_data);
+   dev->driver->setup(>gadget, >setup_data);
spin_unlock(>lock);
 }
 
-- 
2.7.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: serial: ftdi_sio: Add support for ICP DAS I-756xU devices

[Johan Hovold]

On Wed, Mar 16, 2016 at 11:55:49AM -0400, Josh Boyer wrote:
> On Thu, Mar 10, 2016 at 9:48 AM, Josh Boyer  wrote:
> > A Fedora user reports that the ftdi_sio driver works properly for the
> > ICP DAS I-7561U device.  Further, the user manual for these devices
> > instructs users to load the driver and add the ids using the sysfs
> > interface.
> >
> > Add support for these in the driver directly so that the devices work
> > out of the box instead of needing manual configuration.
> >
> > Reported-by: 
> > CC: stable 
> > Signed-off-by: Josh Boyer 
> > ---
> 
> Anything further I need to do on this patch?

It looks ok so I don't think so, but I'll take a closer look when
processing my queue after the merge window closes.

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

[PATCH 1/5] usb: xhci: add quirk flag for broken PED bits

[Roger Quadros]

From: Felipe Balbi 

Some devices from Texas Instruments suffer from
a silicon bug where Port Enabled/Disabled bit
should not be used to silence an erroneous device.

The bug is so that if port is disabled with PED
bit, an IRQ for device removal (or attachment)
will never fire.

Just for the sake of completeness, the actual
problem lies with SNPS USB IP and this affects
all known versions up to 3.00a. A separate
patch will be added to dwc3 to enabled this
quirk flag if version is <= 3.00a.

Signed-off-by: Felipe Balbi 
Signed-off-by: Sekhar Nori 
Signed-off-by: Roger Quadros 
---
 drivers/usb/host/xhci-hub.c | 6 ++
 drivers/usb/host/xhci.h | 2 ++
 2 files changed, 8 insertions(+)

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index d61fcc4..1649a21 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -455,6 +455,12 @@ static void xhci_disable_port(struct usb_hcd *hcd, struct 
xhci_hcd *xhci,
return;
}
 
+   if (xhci->quirks & XHCI_BROKEN_PORT_PE) {
+   xhci_dbg(xhci, "Broken Port Enabled/Disabled, ignoring "
+   "port disable request.\n");
+   return;
+   }
+
/* Write 1 to disable the port */
writel(port_status | PORT_PE, addr);
port_status = readl(addr);
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index e293e09..371a64f 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1641,6 +1641,8 @@ struct xhci_hcd {
 #define XHCI_PME_STUCK_QUIRK   (1 << 20)
 #define XHCI_MTK_HOST  (1 << 21)
 #define XHCI_SSIC_PORT_UNUSED  (1 << 22)
+/* For controller with a broken Port Disable implementation */
+#define XHCI_BROKEN_PORT_PE(1 << 23)
unsigned intnum_active_eps;
unsigned intlimit_active_eps;
/* There are two roothubs to keep track of bus suspend info for */
-- 
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

Re: Composite USB device reset /drivers/usb/core/hub.c - binding order problem

[Greg KH]

On Thu, Mar 17, 2016 at 11:09:20AM +0100, Mikolaj Ch wrote:
> Hi,
> 
> I have a composite usb device where order of binding the drivers to
> interfaces matters.

Ugh, really?  That's a horrid device, what is it?

> When the device is plugged in binding is from 0-th till n-th interface
> but in usb_reset_device function in  /drivers/usb/core/hub.c after
> reset binding is done in revers order from n-th till 0.
> Is there a reason for doing so ?
> Can I expect any disadvantages after changing this order to be from 0
> till n-th ?
> 
> I know that the easiest solution is to claim the device driver is
> badly written but I don't have a possibility to change it so I want to
> know if changing this order in usb cored driver is possible without
> affecting other functionality.

What driver is this?  We can always fix it up properly.

thanks,

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

Re: [PATCH] usb: xhci: Fix incomplete PM resume operation due to XHCI commmand timeout

[Mathias Nyman]

On 18.03.2016 09:01, Rajesh Bhagat wrote:

We are facing issue while performing the system resume operation from STR
where XHCI is going to indefinite hang/sleep state due to
wait_for_completion API called in function xhci_alloc_dev for command
TRB_ENABLE_SLOT which never completes.

Now, xhci_handle_command_timeout function is called and prints
"Command timeout" message but never calls complete API for above
TRB_ENABLE_SLOT command as xhci_abort_cmd_ring is successful.

Solution to above problem is:
1. calling xhci_cleanup_command_queue API even if xhci_abort_cmd_ring
is successful or not.
2. checking the status of reset_device in usb core code.



Hi

I think clearing the whole command ring is a bit too much in this case.
It may cause issues for all attached devices when one command times out.

We need to look in more detail why we fail to call completion for that one 
aborted command.

The bigger question is why the timeout happens in the first place?

What kernel version, and what xhci vendor was this triggered on?

It's possible that the timeout is related either to the locking issue found by 
Chris Bainbridge:
http://marc.info/?l=linux-usb=145493945408601=2

or the resume issues in this thread, (see full thread)
http://marc.info/?l=linux-usb=145477850706552=2

Does any of those proposed solutions fix the command timeout for you?

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

Re: [PATCH 0/5] usb: dwc3: xhci: Add quirk for defective Port Enable/disable

[Felipe Balbi]

Mathias,

Roger Quadros  writes:
> Some devices from Texas Instruments suffer from
> a silicon bug where XHCI Port Enabled/Disabled bit
> should not be used to silence an erroneous device.
> 
> The bug is so that if port is disabled with PED
> bit, an IRQ for device removal (or attachment)
> will never fire.
> 
> Just for the sake of completeness, the actual
> problem lies with SNPS DWC3 USB IP and this affects
> all known versions up to 3.00a
>
> We add a BROKEN_PE quirk in xhci.h to deal with this issue
> and add a corresponding bit in xhci platform_data.
>
> I've only updated Felipe's e-mail id in the patches
> and re-based them to v4.5 + balbi/next.
>
> --
> cheers,
> -roger
>
> Felipe Balbi (5):
>   usb: xhci: add quirk flag for broken PED bits
>   usb: dwc3: core: define macros for newest revisions
>   usb: host: xhci: add broken pe quirk flag to pdata
>   usb: host: xhci-plat: enable BROKEN_PE quirk if platform requested
>   usb: dwc3: host: pass BROKEN_PE flag for known broken revisions

this series has changes on both dwc3 and xhci. Let me know how you wanna
handle these.

-- 
balbi


signature.asc
Description: PGP signature

[PATCH] ims-pcu: sanity check against missing interfaces

[Oliver Neukum]

A malicious device missing interface can make the driver oops.
Add sanity checking.

Signed-off-by: Oliver Neukum 
CC: sta...@vger.kernel.org
---
 drivers/input/misc/ims-pcu.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/input/misc/ims-pcu.c b/drivers/input/misc/ims-pcu.c
index ac1fa5f..9c0ea36 100644
--- a/drivers/input/misc/ims-pcu.c
+++ b/drivers/input/misc/ims-pcu.c
@@ -1663,6 +1663,8 @@ static int ims_pcu_parse_cdc_data(struct usb_interface 
*intf, struct ims_pcu *pc
 
pcu->ctrl_intf = usb_ifnum_to_if(pcu->udev,
 union_desc->bMasterInterface0);
+   if (!pcu->ctrl_intf)
+   return -EINVAL;
 
alt = pcu->ctrl_intf->cur_altsetting;
pcu->ep_ctrl = >endpoint[0].desc;
@@ -1670,6 +1672,8 @@ static int ims_pcu_parse_cdc_data(struct usb_interface 
*intf, struct ims_pcu *pc
 
pcu->data_intf = usb_ifnum_to_if(pcu->udev,
 union_desc->bSlaveInterface0);
+   if (!pcu->data_intf)
+   return -EINVAL;
 
alt = pcu->data_intf->cur_altsetting;
if (alt->desc.bNumEndpoints != 2) {
-- 
2.1.4

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

Re: [PATCH 2/5] ARM: davinci: da8xx: add usb phy clocks

[Sergei Shtylyov]

On 03/16/2016 08:58 PM, David Lechner wrote:


+static struct clk usb20_clk = {
+.name= "usb20",
+.parent= _sysclk2,
+.lpsc= DA8XX_LPSC1_USB20,
+.gpsc= 1,
+};


Why move it?


For organization, to keep all of the USB clocks together. I can leave it alone
if that is preferred.


   I'd prefer to minimize the noise...


+
+/* Set the mux depending on the parent clock. */
+if (clk->parent == _aux_clk)
+val |= CFGCHIP2_USB2PHYCLKMUX;
+else if (clk->parent == _ref_clk)
+val &= ~CFGCHIP2_USB2PHYCLKMUX;


Don't we have clk_set_parent()for that?


Yes. clk_set_parent() is already called in a loop for all clocks elsewhere, so
not needed here.


   No, I mean why is not this implemented as a part of clk_set_parent()?

MBR, Sergei

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

Re: [PATCH v2 06/11] phy: da8xx-usb: new driver for DA8XX SoC USB PHY

[Sergei Shtylyov]

On 3/17/2016 5:26 AM, David Lechner wrote:


This is a new phy driver for the SoC USB controllers on the TI DA8XX


   DA8xx, please.


family of microcontrollers. The USB 1.1 PHY is just a simple on/off.
The USB 2.0 PHY also allows overriding the VBUS and ID pins.

Signed-off-by: David Lechner 

[...]


diff --git a/drivers/phy/phy-da8xx-usb.c b/drivers/phy/phy-da8xx-usb.c
new file mode 100644
index 000..93a5f4d
--- /dev/null
+++ b/drivers/phy/phy-da8xx-usb.c
@@ -0,0 +1,295 @@

[...]

+static inline u32 da8xx_usbphy_readl(void __iomem *base)
+{
+   return readl(base);
+}
+
+static inline void da8xx_usbphy_writel(void __iomem *base, u32 value)
+{
+   writel(value, base);


   Why wrap them at all?


+}
+
+static int da8xx_usb11_phy_init(struct phy *phy)
+{
+   struct da8xx_usbphy *d_phy = phy_get_drvdata(phy);
+   int ret;
+   u32 val;
+
+   ret = clk_prepare_enable(d_phy->usb11_clk);
+   if (ret)
+   return ret;
+
+   val = da8xx_usbphy_readl(d_phy->phy_ctrl);
+   val |= USB1SUSPENDM;
+   da8xx_usbphy_writel(d_phy->phy_ctrl, val);


   Hum, I'd think this needs to be done in the power_on() method...


+
+   return 0;
+}
+
+static int da8xx_usb11_phy_shutdown(struct phy *phy)
+{
+   struct da8xx_usbphy *d_phy = phy_get_drvdata(phy);
+   u32 val;
+
+   val = da8xx_usbphy_readl(d_phy->phy_ctrl);
+   val &= ~USB1SUSPENDM;
+   da8xx_usbphy_writel(d_phy->phy_ctrl, val);


   And this in power_off()...


+
+   clk_disable_unprepare(d_phy->usb11_clk);
+
+   return 0;
+}
+
+static const struct phy_ops da8xx_usb11_phy_ops = {
+   .power_on   = da8xx_usb11_phy_init,
+   .power_off  = da8xx_usb11_phy_shutdown,


   Aha, it's just that the names don't match...
   Please call the implementations da8xx_usb11_phy_power_{on|off}().
The same with USB 2.0 PHY.

[...]

   Looks good otherwise on my superficial review. :-)

MBR, Sergei

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

[PATCH 5/5] usb: dwc3: host: pass BROKEN_PE flag for known broken revisions

[Roger Quadros]

From: Felipe Balbi 

Now that we have a broken pe quirk flag, dwc3
can tell XHCI core about it.

Signed-off-by: Felipe Balbi 
Signed-off-by: Sekhar Nori 
Signed-off-by: Roger Quadros 
---
 drivers/usb/dwc3/host.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index c679f63..db9347b 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -51,6 +51,18 @@ int dwc3_host_init(struct dwc3 *dwc)
 
pdata.usb3_lpm_capable = dwc->usb3_lpm_capable;
 
+   /**
+* WORKAROUND: dwc3 revisions <=3.00a have a limitation
+* where Port Disable command doesn't work.
+*
+* The suggested workaround is that we avoid Port Disable
+* completely.
+*
+* This following flag tells XHCI to do just that.
+*/
+   if (dwc->revision <= DWC3_REVISION_300A)
+   pdata.quirk_port_broken_pe = true;
+
ret = platform_device_add_data(xhci, , sizeof(pdata));
if (ret) {
dev_err(dwc->dev, "couldn't add platform data to xHCI 
device\n");
-- 
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

Re: [PATCH v2 05/11] dt-bindings: Add bindings for phy-da8xx-usb

[Rob Herring]

On Wed, Mar 16, 2016 at 09:26:38PM -0500, David Lechner wrote:
> Device tree binding for new phy-da8xx-usb driver.
> 
> Signed-off-by: David Lechner 
> ---
> 
> v2 changes: This is new patch in v2.
> 
> 
>  .../devicetree/bindings/phy/phy-da8xx-usb.txt  | 34 
> ++
>  1 file changed, 34 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/phy-da8xx-usb.txt
> 
> diff --git a/Documentation/devicetree/bindings/phy/phy-da8xx-usb.txt 
> b/Documentation/devicetree/bindings/phy/phy-da8xx-usb.txt
> new file mode 100644
> index 000..ed6b710
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-da8xx-usb.txt
> @@ -0,0 +1,34 @@
> +TI DaVinci DA8XX USB PHY
> +
> +Required properties:
> + - compatible: must be "ti,da830-usbphy".
> + - #phy-cells: must be 1.
> + - reg : Address and length of the CFGCHIP2 register.
> +
> +This device controls the PHY for both the USB 1.1 OHCI and USB 2.0 OTG
> +controllers on DA8XX SoCs. Consumers of this device should use index 1 for

DA8xx

> +the USB 1.1 phy device and index 2 for the USB 2.0 phy device.
> +
> +Example:
> +
> + usbphy: usbphy@1c14184 {

TI has been doing the unit addresses wrong I've recently found. It 
should match the reg property, not be the full physical address. Please 
fix all these in the example.

> + compatible = "ti,da830-usbphy";
> + #phy-cells = <1>;
> + reg = <0x14184 4>;
> + };
> +
> + usb11: usb11@1e25000 {

usb@...

> + compatible = "ti,da830-ohci";
> + reg = <0x225000 0x1000>;
> + interrupts = <59>;
> + phys = < 1>;
> + phy-names = "usbphy";
> + };
> +
> + usb20: usb@1e0 {
> + compatible = "ti,da830-musb";
> + reg = <0x20 0x1000>;
> + interrupts = <58>;
> + phys = < 2>;
> + phy-names = "usbphy";
> + };
> -- 
> 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 09/11] usb: ohci-da8xx: Remove code that references mach

[David Lechner]

Including mach/* is frowned upon in device drivers, so get rid of it.

This replaces usb20_clk and code that pokes CFGCHIP2 with a proper phy
driver.

Signed-off-by: David Lechner 
---

v2 changes: Uses the new phy driver instead of using a second clock.


 drivers/usb/host/ohci-da8xx.c | 90 +--
 1 file changed, 44 insertions(+), 46 deletions(-)

diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
index e5c33bc..c648674 100644
--- a/drivers/usb/host/ohci-da8xx.c
+++ b/drivers/usb/host/ohci-da8xx.c
@@ -15,58 +15,40 @@
 #include 
 #include 
 #include 
-
-#include 
+#include 
 #include 
 
 #ifndef CONFIG_ARCH_DAVINCI_DA8XX
 #error "This file is DA8xx bus glue.  Define CONFIG_ARCH_DAVINCI_DA8XX."
 #endif
 
-#define CFGCHIP2   DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG)
-
 static struct clk *usb11_clk;
-static struct clk *usb20_clk;
+static struct phy *usb11_phy;
 
 /* Over-current indicator change bitmask */
 static volatile u16 ocic_mask;
 
-static void ohci_da8xx_clock(int on)
+static int ohci_da8xx_enable(void)
 {
-   u32 cfgchip2;
-
-   cfgchip2 = __raw_readl(CFGCHIP2);
-   if (on) {
-   clk_enable(usb11_clk);
-
-   /*
-* If USB 1.1 reference clock is sourced from USB 2.0 PHY, we
-* need to enable the USB 2.0 module clocking, start its PHY,
-* and not allow it to stop the clock during USB 2.0 suspend.
-*/
-   if (!(cfgchip2 & CFGCHIP2_USB1PHYCLKMUX)) {
-   clk_enable(usb20_clk);
-
-   cfgchip2 &= ~(CFGCHIP2_RESET | CFGCHIP2_PHYPWRDN);
-   cfgchip2 |= CFGCHIP2_PHY_PLLON;
-   __raw_writel(cfgchip2, CFGCHIP2);
-
-   pr_info("Waiting for USB PHY clock good...\n");
-   while (!(__raw_readl(CFGCHIP2) & CFGCHIP2_PHYCLKGD))
-   cpu_relax();
-   }
+   int ret;
 
-   /* Enable USB 1.1 PHY */
-   cfgchip2 |= CFGCHIP2_USB1SUSPENDM;
-   } else {
-   clk_disable(usb11_clk);
-   if (!(cfgchip2 & CFGCHIP2_USB1PHYCLKMUX))
-   clk_disable(usb20_clk);
+   ret = clk_prepare_enable(usb11_clk);
+   if (ret)
+   return ret;
 
-   /* Disable USB 1.1 PHY */
-   cfgchip2 &= ~CFGCHIP2_USB1SUSPENDM;
+   ret = phy_power_on(usb11_phy);
+   if (ret) {
+   clk_disable_unprepare(usb11_clk);
+   return ret;
}
-   __raw_writel(cfgchip2, CFGCHIP2);
+
+   return 0;
+}
+
+static void ohci_da8xx_disable(void)
+{
+   phy_power_off(usb11_phy);
+   clk_disable_unprepare(usb11_clk);
 }
 
 /*
@@ -92,7 +74,9 @@ static int ohci_da8xx_init(struct usb_hcd *hcd)
 
dev_dbg(dev, "starting USB controller\n");
 
-   ohci_da8xx_clock(1);
+   result = ohci_da8xx_enable();
+   if (result < 0)
+   return result;
 
/*
 * DA8xx only have 1 port connected to the pins but the HC root hub
@@ -101,8 +85,10 @@ static int ohci_da8xx_init(struct usb_hcd *hcd)
ohci->num_ports = 1;
 
result = ohci_init(ohci);
-   if (result < 0)
+   if (result < 0) {
+   ohci_da8xx_disable();
return result;
+   }
 
/*
 * Since we're providing a board-specific root hub port power control
@@ -129,7 +115,7 @@ static int ohci_da8xx_init(struct usb_hcd *hcd)
 static void ohci_da8xx_stop(struct usb_hcd *hcd)
 {
ohci_stop(hcd);
-   ohci_da8xx_clock(0);
+   ohci_da8xx_disable();
 }
 
 static int ohci_da8xx_start(struct usb_hcd *hcd)
@@ -301,12 +287,18 @@ static int usb_hcd_da8xx_probe(const struct hc_driver 
*driver,
return -ENODEV;
 
usb11_clk = devm_clk_get(>dev, "usb11");
-   if (IS_ERR(usb11_clk))
+   if (IS_ERR(usb11_clk)) {
+   if (PTR_ERR(usb11_clk) != -EPROBE_DEFER)
+   dev_err(>dev, "Failed to get clock.\n");
return PTR_ERR(usb11_clk);
+   }
 
-   usb20_clk = devm_clk_get(>dev, "usb20");
-   if (IS_ERR(usb20_clk))
-   return PTR_ERR(usb20_clk);
+   usb11_phy = devm_phy_get(>dev, "usbphy");
+   if (IS_ERR(usb11_phy)) {
+   if (PTR_ERR(usb11_phy) != -EPROBE_DEFER)
+   dev_err(>dev, "Failed to get phy.\n");
+   return PTR_ERR(usb11_phy);
+   }
 
hcd = usb_create_hcd(driver, >dev, dev_name(>dev));
if (!hcd)
@@ -316,6 +308,7 @@ static int usb_hcd_da8xx_probe(const struct hc_driver 
*driver,
hcd->regs = devm_ioremap_resource(>dev, mem);
if (IS_ERR(hcd->regs)) {
error = PTR_ERR(hcd->regs);
+   dev_err(>dev, "failed to map ohci.\n");
goto err;
}
hcd->rsrc_start = mem->start;
@@ -397,7 +390,7 

Re: [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on bcm2835"

[John Youn]

On 3/10/2016 11:14 AM, John Youn wrote:
> On 3/9/2016 11:06 AM, Doug Anderson wrote:
>> Stefan,
>>
>> On Wed, Mar 9, 2016 at 11:01 AM, Stefan Wahren  
>> wrote:
>>>
 Doug Anderson  hat am 7. März 2016 um 22:30
 geschrieben:


 Stefan,

 On Mon, Mar 7, 2016 at 10:40 AM, Stefan Wahren  
 wrote:
> Hi Doug,
>
>> Douglas Anderson  hat am 4. März 2016 um 19:23
>> geschrieben:
>>
>>
>> This reverts commit 192cb07f7928 ("usb: dwc2: Fix probe problem on
>> bcm2835") now that we've found the root cause. See the change
>> titled ("usb: dwc2: Add a 10 ms delay to dwc2_core_reset()").
>
> adding a delay of 10 ms after a core reset might be a idea, but applying
> both
> patches breaks USB support on RPi :-(
>
> I'm getting the wrong register values ...

 Ugh. :(

 Just out of curiosity, if you loop and time long it takes for the
 registers to get to the right state after reset, what do you get?
 AKA, pick:

 https://chromium-review.googlesource.com/331260

 ...and let me know what it prints out.
>>>
>>> On my Raspberry Pi B i get the following:
>>>
>>> [2.084411] dwc2 2098.usb: mapped PA 2098 to VA cc88
>>> [2.084461] dwc2 2098.usb: cannot get otg clock
>>> [2.084549] dwc2 2098.usb: registering common handler for irq33
>>> [2.084713] dwc2 2098.usb: Configuration mismatch. dr_mode forced to 
>>> host
>>> [2.153965] dwc2 2098.usb: Waited 49996 us, 0x00201000 => 0x01001000,
>>> 0x => 0x02002000
>>> [2.174930] dwc2 2098.usb: Forcing mode to host
>>>
>>> So i changed the delay in patch #1 to msleep(50) and then both patches work 
>>> like
>>> a charm.
>>
>> Great news!  :-)
>>
>> John: it's pretty clear that there's something taking almost exactly
>> 10ms on my system and almost exactly 50ms on Stefan's system.  Is
>> there some register we could poll to see when this process is done?
>> ...or can we look at the dwc2 revision number / feature register and
>> detect how long to delay?
>>
> 
> Hi Doug,
> 
> I'll have to ask around to see if anyone knows about this. And I'll
> run some tests on the platforms I have available to me as well.
> 

There's still nothing definitive on our end as to why this is
happening. Also I don't think there is any other way to poll the
reset. Our hardware engineers asked for some more information to look
into it further. Doug, Stefan, Caesar, and anyone else with a related
platform, do you know the answers to the following:

1. What is the AHB Clock frequency? Is the AHB Clock gated during
Reset?

2. Also is the PHY clock stopped during the reset or is the PHY PLL
lock times high in the order of ms?

3. In these cases, is the PHY actually an FS Transceiver and not a
UTMI/ULPI PHY?

4. Which version of the controller is being used in these cases?

Regards,
John
--
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 v10 1/9] dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding

[Stephen Warren]

On 03/04/2016 09:19 AM, Thierry Reding wrote:

From: Thierry Reding 

The NVIDIA Tegra XUSB pad controller provides a set of pads, each with a
set of lanes that are used for PCIe, SATA and USB.



  .../bindings/phy/nvidia,tegra124-xusb-padctl.txt   | 376 +
  .../pinctrl/nvidia,tegra124-xusb-padctl.txt|   5 +


It seems odd to add part of the deprecation notice in this patch and one 
more line in the second/next patch. Did an update get squashed into the 
wrong commit? I'd suggest moving the edit to existing file 
nvidia,tegra124-xusb-padctl.txt entirely into patch 2. Perhaps this 
could happen while/when the patch is applied to avoid having to post 
another version.



diff --git 
a/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt 
b/Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt


...

+Pads will be represented as children of the top-level XUSB pad controller

> +device tree node.

Nit: grand-children, since they're house inside pads{} first. I might 
suggest:


A "pads" node exists to represent all pads contained within the XUSB 
controller. Each pad is represented as a subnode of the pads node.



Each lane exposed by the pad will be represented by its
+own subnode and can be referenced by users of the lane using the standard
+PHY bindings, as described by the phy-bindings.txt file in this directory.


"Each lane exposed by the pad will be represented as a subnode of the 
pad node ..."?


I'd suggest adding a similar paragraph describing the ports node, and 
that ports are child nodes of that. Otherwise, since the documentation 
of the nodes isn't nested in any way, it's not clear from the text 
exactly what nodes are children of what other nodes.



+The Tegra hardware documentation refers to the connection between the XUSB
+pad controller and the XUSB controller as "ports".


I think, being pedantic, that "port" in the TRM refers to the set of 
signals at the edge/interface-to the IO controller, not the connection 
between the IO controller and the XUSB controller. Still, the existing 
wording in this patch is fine; no need to change it.


Still, the examples do clear this up, so perhaps it's not worth another 
version of the series to fix this. Or if you do think it's worth fixing, 
I'd be perfectly happy to see that done in follow-on patches. If you 
want I can write that follow-on patch once this series is applied.


...

+PHY nodes:
+==
+
+Each pad node has one or more children, each representing one of the lanes
+controlled by the pad.
+
+Required properties:
+
+- status: Defines the operation status of the PHY. Valid values are:
+  - "disabled": the PHY is disabled
+  - "okay": the PHY is enabled


Presumably the standard semantics of a missing status property 
implicitly meaning "okay" are also intended? A similar comment applies 
to other places where status is documented. "status" is typically not a 
required property.



+Port nodes:
+===



+USB2 ports:
+---


Should that say "UTMI ports"? ULPI and HSIC below are (or can be) USB2 
ports too.



+Required properties:
+- status: Defines the operation status of the port. Valid values are:
+  - "disabled": the port is disabled
+  - "okay": the port is enabled
+- mode: A string that determines the mode in which to run the port. Valid
+  values are:
+  - "host": for USB host mode
+  - "device": for USB device mode
+  - "otg": for USB OTG mode


How do these properties tie the DT-based port definition to a particular 
PHY/lane/... in HW? I don't see a property that contains any kind of HW 
ID here.


...

+Optional properties:
+- nvidia,internal: A boolean property whose presence determines that a port
+  is internal. In the absence of this property the port is considered to be
+  external.


It's not clear what "internal" and "external" mean. Presumably it's 
on-PCB vs. physical-connector-exposed-to-the-user. It may be worth 
explicitly mentioning that.


Is there no vbus-supply for USB2/UTMI ports? I'm also not sure why 
vbus-supply is optional for ULPI and HSIC. Even if there is no SW 
/control/ over VBUS, there still must be some source of power; IIRC Mark 
Brown typically desires that to be explicitly modelled with an always-on 
regulator if there's no SW control.



+Super-speed USB ports:
+--
+
+Required properties:
+- status: Defines the operation status of the port. Valid values are:
+  - "disabled": the port is disabled
+  - "okay": the port is enabled
+- nvidia,usb2-companion: A single cell that specifies the physical port number
+  to map this super-speed USB port to. The range of valid port numbers varies
+  with the SoC generation:
+  - 0-2: for Tegra124 and Tegra132


How can this be used to look up the corresponding USB2 node in DT? I 
would have expected a phandle here, with the physical (HW) port ID being 
represented in the referenced node. Otherwise, I don't see how to 

Re: [PATCH] qmi_wwan: Added support for Gemalto's Cinterion PHxx WWAN interface

[Bjørn Mork]

Schemmel Hans-Christoph  writes:

> Added support for Gemalto's Cinterion PHxx WWAN interfaces 
> by adding QMI_FIXED_INTF with Cinterion's VID and PID.
>
> PHxx can have:
> 2 RmNet Interfaces (PID 0x0082) or
> 1 RmNet + 1 USB Audio interface (PID 0x0083).
>
> Signed-off-by: Hans-Christoph Schemmel 
> ---
> patch is against linux-4.5
> --- linux/drivers/net/usb/qmi_wwan.c.orig 2016-03-14 12:18:07.153497489 
> +0100
> +++ linux/drivers/net/usb/qmi_wwan.c  2016-03-14 12:21:37.722541644 +0100
> @@ -881,6 +881,9 @@ static const struct usb_device_id produc
>   {QMI_FIXED_INTF(0x0b3c, 0xc00b, 4)},/* Olivetti Olicard 500 */
>   {QMI_FIXED_INTF(0x1e2d, 0x0060, 4)},/* Cinterion PLxx */
>   {QMI_FIXED_INTF(0x1e2d, 0x0053, 4)},/* Cinterion PHxx,PXxx */
> + {QMI_FIXED_INTF(0x1e2d, 0x0082, 4)},/* Cinterion PHxx,PXxx (2 
> RmNet) */
> + {QMI_FIXED_INTF(0x1e2d, 0x0082, 5)},/* Cinterion PHxx,PXxx (2 
> RmNet) */
> + {QMI_FIXED_INTF(0x1e2d, 0x0083, 4)},/* Cinterion PHxx,PXxx (1 RmNet 
> + USB Audio)*/
>   {QMI_FIXED_INTF(0x413c, 0x81a2, 8)},/* Dell Wireless 5806 Gobi(TM) 
> 4G LTE Mobile Broadband Card */
>   {QMI_FIXED_INTF(0x413c, 0x81a3, 8)},/* Dell Wireless 5570 HSPA+ 
> (42Mbps) Mobile Broadband Card */
>   {QMI_FIXED_INTF(0x413c, 0x81a4, 8)},/* Dell Wireless 5570e HSPA+ 
> (42Mbps) Mobile Broadband Card */

Perfect.  Thanks.

Acked-by: Bjørn Mork 
--
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 6/6] mfd: intel_vuport: Add Intel virtual USB port MFD Driver

[Greg Kroah-Hartman]

On Fri, Mar 18, 2016 at 04:43:21PM +0800, Lu Baolu wrote:
> 
> 
> On 03/18/2016 04:09 PM, Lee Jones wrote:
> > On Fri, 18 Mar 2016, Lu Baolu wrote:
> >
> >> Some Intel platforms have an USB port mux controlled by GPIOs.
> >> There's a single ACPI platform device that provides both USB ID
> >> extcon device and a USB port mux device. This MFD driver will
> >> split the 2 devices for their respective drivers.
> >>
> >> Signed-off-by: Lu Baolu 
> >> Suggested-by: David Cohen 
> > This should be at the top.
> >
> > You couldn't have written the patch before it was suggested.
> 
> Yes. I will change this.
> 
> >
> >> Reviewed-by: Felipe Balbi 
> >> Signed-off-by: Fengguang Wu 
> > What is this sign-off meant to indicate?
> 
> Fengguang's sign-off was added due to folding a patch contributed by
> his kbuild robot.

No, you can't do that, he only signed off on his fixup patch, not your
overall larger patch!

I'm going to stop you now and require you to get this properly reviewed,
and signed-off-by some experienced Intel kernel developers before I look
at this at all.  Take advantage of the resources you have, don't force
the community to point out these basic mistakes.

Also, you know I'm not looking at new patches until after -rc1 is out,
so please wait until then before resending.

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

[GIT PULL] USB driver patches for 4.6-rc1

[Greg KH]

The following changes since commit fc77dbd34c5c99bce46d40a2491937c3bcbd10af:

  Linux 4.5-rc6 (2016-02-28 08:41:20 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-4.6-rc1

for you to fetch changes up to ce53bfc4374cada8b645765e2b4ad5831e760932:

  Merge tag 'usb-serial-4.6-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-next 
(2016-03-08 20:28:19 -0800)


USB patches for 4.6-rc1

Here is the big USB patchset for 4.6-rc1.

The normal mess is here, gadget and xhci fixes and updates, and lots of
other driver updates and cleanups as well.  Full details are in the
shortlog.

All have been in linux-next for a while with no reported issues.

Signed-off-by: Greg Kroah-Hartman 


Alan (1):
  chipidea: error on overflow for port_test_write

Alan Stern (5):
  USB: EHCI: store reason for unlinking a QH
  USB: EHCI: improve handling of the ehci->iaa_in_progress flag
  USB: EHCI: add a delay when unlinking an active QH
  USB: EHCI: improvements to unlink_empty_async_suspended()
  USB: EHCI: fix compiler warning introduced by commit 2a40f324541e

Alexey Khoroshilov (1):
  usb: gadget: bdc_udc: fix race condition in bdc_udc_exit()

Amitoj Kaur Chawla (2):
  usb: storage: ene_ub6250: Remove unnecessary cast in kfree
  usb: dwc2: Use kmem_cache_free()

Andrew Goodbody (1):
  usb: usbip: Fix possible deadlocks reported by lockdep

Andy Shevchenko (1):
  usb: core: use kbasename() instead of open-coded variant

Antonio Ospite (1):
  usb/storage: misc fixes to comments in include/linux/usb/storage.h

Antti Seppälä (1):
  usb: dwc2: Add support for Lantiq ARX and XRX SoCs

Arnd Bergmann (14):
  usb: host: unhide suspend/resume declarations
  usb: xhci-mtk: use __maybe_unused to hide pm functions
  usb: ohci-at91: use __maybe_unused to hide pm functions
  usb: ehci-atmel: use __maybe_unused to hide pm functions
  phy: dm816x: use __maybe_unused to hide pm functions
  phy: twl4030: use __maybe_unused to hide pm functions
  usb: gadget: pxa25x_udc: move register definitions from arch
  usb: gadget: pxa25x_udc cleanup
  usb: gadget: pxa25x_udc: use readl/writel for mmio
  usb: fsl: drop USB_FSL_MPH_DR_OF Kconfig symbol
  usb: isp1301-omap: mark power_up as __maybe_unused
  usb: musb: use %pad format string from dma_addr_t
  usb: musb/ux500: remove duplicate check for dma_is_compatible
  usb: gadget: pxa25x_udc: document endianess better

Azriel Samson (1):
  usb: host: ehci-msm: Register usb shutdown function

Bjorn Helgaas (1):
  usb: phy: phy-am335x: remove include of regulator/consumer.h

Chase Metzger (1):
  usb: core: devio.c: Removed unnecessary space

Christian Lamparter (1):
  usbip: move usbip_protocol.txt to Documentation

Dan Carpenter (2):
  USB: cxacru: fix an bounds check warning
  usb: gadget: f_midi: missing unlock on error path

Dave Penkler (6):
  Implement an ioctl to support the USMTMC-USB488 READ_STATUS_BYTE 
operation.
  Add support for USBTMC USB488 SRQ notification with fasync
  Add support for receiving USBTMC USB488 SRQ notifications via poll/select
  Add ioctl to retrieve USBTMC-USB488 capabilities
  Add ioctls to enable and disable local controls on an instrument
  usb: usbtmc: Fix disconnect/poll interaction

Douglas Anderson (21):
  usb: dwc2: rockchip: Make the max_transfer_size automatic
  usb: dwc2: host: Get aligned DMA in a more supported way
  usb: dwc2: host: Set host_rx_fifo_size to 525 for rk3066
  usb: dwc2: host: Avoid use of chan->qh after qh freed
  usb: dwc2: host: Always add to the tail of queues
  usb: dwc2: host: fix split transfer schedule sequence
  usb: dwc2: host: Add scheduler tracing
  usb: dwc2: host: Add a delay before releasing periodic bandwidth
  usb: dwc2: host: Giveback URB in tasklet context
  usb: dwc2: host: Properly set the HFIR
  usb: dwc2: host: There's not really a TT for the root hub
  usb: dwc2: host: Use periodic interrupt even with DMA
  usb: dwc2: host: Rename some fields in struct dwc2_qh
  usb: dwc2: host: Reorder things in hcd_queue.c
  usb: dwc2: host: Split code out to make dwc2_do_reserve()
  usb: dwc2: host: Add scheduler logging for missed SOFs
  usb: dwc2: host: Manage frame nums better in scheduler
  usb: dwc2: host: Add dwc2_hcd_get_future_frame_number() call
  usb: dwc2: host: Properly set even/odd frame
  usb: dwc2: host: Totally redo the microframe scheduler
  usb: dwc2: host: If using uframe scheduler, end splits better

Du, Changbin (1):
  usb: f_fs: avoid race condition with ffs_epfile_io_complete

Emilio López (1):
  usb: musb: sunxi: 

Re: [PATCH v2 04/11] ARM: davinci: da8xx: add usb phy clocks

[Sergei Shtylyov]

On 3/17/2016 5:26 AM, David Lechner wrote:


Up to this point, the USB phy clock configuration was handled manually in
the board files and in the usb drivers. This adds proper clocks so that
the usb drivers can use clk_get and clk_enable and not have to worry about
the details. Also, the related code is removed from the board files.

Signed-off-by: David Lechner 

[...]

diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index 7187e7f..ee942b0 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c

[...]

@@ -346,6 +347,12 @@ static struct clk i2c1_clk = {
.gpsc   = 1,
  };

+static struct clk usb_ref_clk = {
+   .name   = "usb_ref_clk",


   I'd leave out "_clk" for consistency.

[...]

@@ -353,6 +360,139 @@ static struct clk usb11_clk = {

[...]

+static int usb20_phy_clk_set_parent(struct clk *clk, struct clk *parent)
+{
+   u32 __iomem *cfgchip2;
+   u32 val;
+
+   /*
+* Can't use DA8XX_SYSCFG0_VIRT() here since this can be called before
+* da8xx_syscfg0_base is initialized.
+*/
+   cfgchip2 = ioremap(DA8XX_SYSCFG0_BASE + DA8XX_CFGCHIP2_REG, 4);


   You should be able to use IO_ADDRESS(), no?

[...]

@@ -420,7 +560,10 @@ static struct clk_lookup da830_clks[] = {
CLK("davinci_mdio.0",   "fck",  _clk),
CLK(NULL,   "gpio",   _clk),
CLK("i2c_davinci.2",  NULL,   _clk),
+   CLK(NULL,   "usb_ref_clk",_ref_clk),


   I'd leave out "_clk" agai.


CLK(NULL,   "usb11",  _clk),
+   CLK(NULL,   "usb20_phy",  _phy_clk),
+   CLK(NULL,   "usb11_phy",  _phy_clk),
CLK(NULL,   "emif3",  _clk),
CLK(NULL,   "arm",_clk),
CLK(NULL,   "rmii",   _clk),
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 8c8f31e..8089a82 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c


   Same comments on this file...

MBR, Sergei

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

[PATCH v2 03/11] ARM: davinci: da850: use clk->set_parent for async3

[David Lechner]

The da850 family of processors has an async3 clock domain that can be
muxed to either pll0_sysclk2 or pll1_sysclk2. Now that the davinci clocks
have a set_parent callback, we can use this to control the async3 mux
instead of a stand-alone function.

This adds a new async3_clk and sets the appropriate child clocks. The
default is use to pll1_sysclk2 since it is not affected by processor
frequency scaling.

Signed-off-by: David Lechner 
---

v2 changes: This is a new patch in v2.



 arch/arm/mach-davinci/da850.c | 88 ---
 1 file changed, 40 insertions(+), 48 deletions(-)

diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 97d8779..8c8f31e 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -34,9 +34,6 @@
 #include "clock.h"
 #include "mux.h"
 
-/* SoC specific clock flags */
-#define DA850_CLK_ASYNC3   BIT(16)
-
 #define DA850_PLL1_BASE0x01e1a000
 #define DA850_TIMER64P2_BASE   0x01f0c000
 #define DA850_TIMER64P3_BASE   0x01f0d000
@@ -161,6 +158,39 @@ static struct clk pll1_sysclk3 = {
.div_reg= PLLDIV3,
 };
 
+static int da850_async3_set_parent(struct clk *clk, struct clk *parent)
+{
+   u32 __iomem *cfgchip3;
+   u32 val;
+
+   /*
+* Can't use DA8XX_SYSCFG0_VIRT() here since this can be called before
+* da8xx_syscfg0_base is initialized.
+*/
+   cfgchip3 = ioremap(DA8XX_SYSCFG0_BASE + DA8XX_CFGCHIP3_REG, 4);
+   val = readl(cfgchip3);
+
+   /* Set the USB 1.1 PHY clock mux based on the parent clock. */
+   if (parent == _sysclk2)
+   val &= ~CFGCHIP3_ASYNC3_CLKSRC;
+   else if (parent == _sysclk2)
+   val |= CFGCHIP3_ASYNC3_CLKSRC;
+   else {
+   pr_err("Bad parent on async3 clock mux.\n");
+   return -EINVAL;
+   }
+
+   writel(val, cfgchip3);
+
+   return 0;
+}
+
+static struct clk async3_clk = {
+   .name   = "async3",
+   .parent = _sysclk2,
+   .set_parent = da850_async3_set_parent,
+};
+
 static struct clk i2c0_clk = {
.name   = "i2c0",
.parent = _aux_clk,
@@ -234,18 +264,16 @@ static struct clk uart0_clk = {
 
 static struct clk uart1_clk = {
.name   = "uart1",
-   .parent = _sysclk2,
+   .parent = _clk,
.lpsc   = DA8XX_LPSC1_UART1,
.gpsc   = 1,
-   .flags  = DA850_CLK_ASYNC3,
 };
 
 static struct clk uart2_clk = {
.name   = "uart2",
-   .parent = _sysclk2,
+   .parent = _clk,
.lpsc   = DA8XX_LPSC1_UART2,
.gpsc   = 1,
-   .flags  = DA850_CLK_ASYNC3,
 };
 
 static struct clk aintc_clk = {
@@ -300,10 +328,9 @@ static struct clk emac_clk = {
 
 static struct clk mcasp_clk = {
.name   = "mcasp",
-   .parent = _sysclk2,
+   .parent = _clk,
.lpsc   = DA8XX_LPSC1_McASP0,
.gpsc   = 1,
-   .flags  = DA850_CLK_ASYNC3,
 };
 
 static struct clk lcdc_clk = {
@@ -355,10 +382,9 @@ static struct clk spi0_clk = {
 
 static struct clk spi1_clk = {
.name   = "spi1",
-   .parent = _sysclk2,
+   .parent = _clk,
.lpsc   = DA8XX_LPSC1_SPI1,
.gpsc   = 1,
-   .flags  = DA850_CLK_ASYNC3,
 };
 
 static struct clk vpif_clk = {
@@ -386,10 +412,9 @@ static struct clk dsp_clk = {
 
 static struct clk ehrpwm_clk = {
.name   = "ehrpwm",
-   .parent = _sysclk2,
+   .parent = _clk,
.lpsc   = DA8XX_LPSC1_PWM,
.gpsc   = 1,
-   .flags  = DA850_CLK_ASYNC3,
 };
 
 #define DA8XX_EHRPWM_TBCLKSYNC BIT(12)
@@ -421,10 +446,9 @@ static struct clk ehrpwm_tbclk = {
 
 static struct clk ecap_clk = {
.name   = "ecap",
-   .parent = _sysclk2,
+   .parent = _clk,
.lpsc   = DA8XX_LPSC1_ECAP,
.gpsc   = 1,
-   .flags  = DA850_CLK_ASYNC3,
 };
 
 static struct clk_lookup da850_clks[] = {
@@ -442,6 +466,7 @@ static struct clk_lookup da850_clks[] = {
CLK(NULL,   "pll1_aux", _aux_clk),
CLK(NULL,   "pll1_sysclk2", _sysclk2),
CLK(NULL,   "pll1_sysclk3", _sysclk3),
+   CLK(NULL,   "async3",   _clk),
CLK("i2c_davinci.1",NULL,   _clk),
CLK(NULL,   "timer0",   _0_clk),
CLK("davinci-wdt",  NULL,   _1_clk),
@@ -909,30 +934,6 @@ static struct davinci_timer_info da850_timer_info = {
.clocksource_id = T0_TOP,
 };
 
-static void da850_set_async3_src(int pllnum)
-{
-   struct clk *clk, *newparent = pllnum ? _sysclk2 : _sysclk2;
-   struct clk_lookup *c;
-   unsigned int v;
- 

usb: dwc2: Kernel 4.5 and socfpga problem

[Phil Reid]

G'day,

Has anyone successful run the usb dwc2 from kenerl 4.5 on an socfpga.

Inital I've had to remove the phys & phy-names property from the DT for it to 
even probe.
Otherwise it was returning PROBE_DEFERED.
The 4.4 driver seems to be getting the same error but it continued loading 
regardless.

After fixing that and getting it to load its going into overcurrent fault.
Applying Dinh's patch from the Altera 4.4 tree
FogBugz #198256: Fix unnecessary USB overcurrent condition
hasn't help. The driver immediately goes into an overcurrent condition at boot.

Reverting all the driver code to the 4.4 tree results in things working again.


--
Regards
Phil Reid

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

[PATCH 3/5] usb: host: xhci: add broken pe quirk flag to pdata

[Roger Quadros]

From: Felipe Balbi 

Let platform_data users pass broken pe flag to
xhci driver.

Signed-off-by: Felipe Balbi 
Signed-off-by: Sekhar Nori 
Signed-off-by: Roger Quadros 
---
 include/linux/usb/xhci_pdriver.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/usb/xhci_pdriver.h b/include/linux/usb/xhci_pdriver.h
index 376654b..81b15ea 100644
--- a/include/linux/usb/xhci_pdriver.h
+++ b/include/linux/usb/xhci_pdriver.h
@@ -18,10 +18,12 @@
  *
  * @usb3_lpm_capable:  determines if this xhci platform supports USB3
  * LPM capability
+ * @quirk_port_broken_pe: If true, XHCI will not use Port Disable.
  *
  */
 struct usb_xhci_pdata {
unsignedusb3_lpm_capable:1;
+   unsignedquirk_port_broken_pe:1;
 };
 
 #endif /* __USB_CORE_XHCI_PDRIVER_H */
-- 
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

Re: [PATCH] ims-pcu: sanity check against missing interfaces

[Dmitry Torokhov]

On Thu, Mar 17, 2016 at 03:10:47PM +0100, Oliver Neukum wrote:
> A malicious device missing interface can make the driver oops.
> Add sanity checking.
> 
> Signed-off-by: Oliver Neukum 
> CC: sta...@vger.kernel.org

Applied, thank you.

> ---
>  drivers/input/misc/ims-pcu.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/input/misc/ims-pcu.c b/drivers/input/misc/ims-pcu.c
> index ac1fa5f..9c0ea36 100644
> --- a/drivers/input/misc/ims-pcu.c
> +++ b/drivers/input/misc/ims-pcu.c
> @@ -1663,6 +1663,8 @@ static int ims_pcu_parse_cdc_data(struct usb_interface 
> *intf, struct ims_pcu *pc
>  
>   pcu->ctrl_intf = usb_ifnum_to_if(pcu->udev,
>union_desc->bMasterInterface0);
> + if (!pcu->ctrl_intf)
> + return -EINVAL;
>  
>   alt = pcu->ctrl_intf->cur_altsetting;
>   pcu->ep_ctrl = >endpoint[0].desc;
> @@ -1670,6 +1672,8 @@ static int ims_pcu_parse_cdc_data(struct usb_interface 
> *intf, struct ims_pcu *pc
>  
>   pcu->data_intf = usb_ifnum_to_if(pcu->udev,
>union_desc->bSlaveInterface0);
> + if (!pcu->data_intf)
> + return -EINVAL;
>  
>   alt = pcu->data_intf->cur_altsetting;
>   if (alt->desc.bNumEndpoints != 2) {
> -- 
> 2.1.4
> 

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

[PATCH v1 1/5] usb: gadged: pch_udc: PCI core handles power state for us

[Andy Shevchenko]

There is no need to repeat the work that is already done in the PCI
driver core. The patch removes excerpts from suspend and resume
callbacks.

Note that there is no more calls performed to enable or disable a PCI
device during suspend-resume cycle. Nowadays they seems to be
superflous. Someone can read more in [1].

While here, convert PM ops to use modern API.

[1] https://www.kernel.org/doc/ols/2009/ols2009-pages-319-330.pdf

Signed-off-by: Andy Shevchenko 
---
 drivers/usb/gadget/udc/pch_udc.c | 39 ---
 1 file changed, 12 insertions(+), 27 deletions(-)

diff --git a/drivers/usb/gadget/udc/pch_udc.c b/drivers/usb/gadget/udc/pch_udc.c
index 9571ef5..b751126 100644
--- a/drivers/usb/gadget/udc/pch_udc.c
+++ b/drivers/usb/gadget/udc/pch_udc.c
@@ -3096,44 +3096,28 @@ static void pch_udc_remove(struct pci_dev *pdev)
kfree(dev);
 }
 
-#ifdef CONFIG_PM
-static int pch_udc_suspend(struct pci_dev *pdev, pm_message_t state)
+#ifdef CONFIG_PM_SLEEP
+static int pch_udc_suspend(struct device *d)
 {
+   struct pci_dev *pdev = to_pci_dev(d);
struct pch_udc_dev *dev = pci_get_drvdata(pdev);
 
pch_udc_disable_interrupts(dev, UDC_DEVINT_MSK);
pch_udc_disable_ep_interrupts(dev, UDC_EPINT_MSK_DISABLE_ALL);
 
-   pci_disable_device(pdev);
-   pci_enable_wake(pdev, PCI_D3hot, 0);
-
-   if (pci_save_state(pdev)) {
-   dev_err(>dev,
-   "%s: could not save PCI config state\n", __func__);
-   return -ENOMEM;
-   }
-   pci_set_power_state(pdev, pci_choose_state(pdev, state));
return 0;
 }
 
-static int pch_udc_resume(struct pci_dev *pdev)
+static int pch_udc_resume(struct device *d)
 {
-   int ret;
-
-   pci_set_power_state(pdev, PCI_D0);
-   pci_restore_state(pdev);
-   ret = pci_enable_device(pdev);
-   if (ret) {
-   dev_err(>dev, "%s: pci_enable_device failed\n", __func__);
-   return ret;
-   }
-   pci_enable_wake(pdev, PCI_D3hot, 0);
return 0;
 }
+
+static SIMPLE_DEV_PM_OPS(pch_udc_pm, pch_udc_suspend, pch_udc_resume);
+#define PCH_UDC_PM_OPS _udc_pm
 #else
-#define pch_udc_suspendNULL
-#define pch_udc_resume NULL
-#endif /* CONFIG_PM */
+#define PCH_UDC_OPSNULL
+#endif /* CONFIG_PM_SLEEP */
 
 static int pch_udc_probe(struct pci_dev *pdev,
  const struct pci_device_id *id)
@@ -3262,9 +3246,10 @@ static struct pci_driver pch_udc_driver = {
.id_table = pch_udc_pcidev_id,
.probe =pch_udc_probe,
.remove =   pch_udc_remove,
-   .suspend =  pch_udc_suspend,
-   .resume =   pch_udc_resume,
.shutdown = pch_udc_shutdown,
+   .driver = {
+   .pm = PCH_UDC_PM_OPS,
+   },
 };
 
 module_pci_driver(pch_udc_driver);
-- 
2.7.0

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

[PATCH v4 1/7] extcon: usb-gpio: add device binding for platform device

[Lu Baolu]

This is needed to handle the GPIO connected USB ID pin found on
Intel Baytrail devices.

Signed-off-by: Lu Baolu 
Reviewed-by: Felipe Balbi 
Acked-by: Chanwoo Choi 
---
 drivers/extcon/extcon-usb-gpio.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/extcon/extcon-usb-gpio.c b/drivers/extcon/extcon-usb-gpio.c
index 2b2fecf..af9c8b0 100644
--- a/drivers/extcon/extcon-usb-gpio.c
+++ b/drivers/extcon/extcon-usb-gpio.c
@@ -206,6 +206,12 @@ static const struct of_device_id usb_extcon_dt_match[] = {
 };
 MODULE_DEVICE_TABLE(of, usb_extcon_dt_match);
 
+static const struct platform_device_id usb_extcon_platform_ids[] = {
+   { .name = "extcon-usb-gpio", },
+   { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(platform, usb_extcon_platform_ids);
+
 static struct platform_driver usb_extcon_driver = {
.probe  = usb_extcon_probe,
.remove = usb_extcon_remove,
@@ -214,6 +220,7 @@ static struct platform_driver usb_extcon_driver = {
.pm = _extcon_pm_ops,
.of_match_table = usb_extcon_dt_match,
},
+   .id_table = usb_extcon_platform_ids,
 };
 
 module_platform_driver(usb_extcon_driver);
-- 
2.1.4

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

[PATCH v4 2/7] extcon: usb-gpio: add support for ACPI gpio interface

[Lu Baolu]

GPIO resource could be retrieved through APCI as well.

Signed-off-by: Lu Baolu 
Reviewed-by: Felipe Balbi 
Acked-by: Chanwoo Choi 
---
 drivers/extcon/extcon-usb-gpio.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/extcon/extcon-usb-gpio.c b/drivers/extcon/extcon-usb-gpio.c
index af9c8b0..472c431 100644
--- a/drivers/extcon/extcon-usb-gpio.c
+++ b/drivers/extcon/extcon-usb-gpio.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define USB_GPIO_DEBOUNCE_MS   20  /* ms */
 
@@ -91,7 +92,7 @@ static int usb_extcon_probe(struct platform_device *pdev)
struct usb_extcon_info *info;
int ret;
 
-   if (!np)
+   if (!np && !ACPI_HANDLE(dev))
return -EINVAL;
 
info = devm_kzalloc(>dev, sizeof(*info), GFP_KERNEL);
-- 
2.1.4

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

[PATCH v4 7/7] mfd: intel_vuport: Add Intel virtual USB port MFD Driver

[Lu Baolu]

Some Intel platforms have an USB port mux controlled by GPIOs.
There's a single ACPI platform device that provides both USB ID
extcon device and a USB port mux device. This MFD driver will
split the 2 devices for their respective drivers.

Signed-off-by: Lu Baolu 
Suggested-by: David Cohen 
Reviewed-by: Felipe Balbi 
Signed-off-by: Fengguang Wu 
Reviewed-by: Lee Jones 
---
 MAINTAINERS|  6 
 drivers/mfd/Kconfig|  8 +
 drivers/mfd/Makefile   |  1 +
 drivers/mfd/intel-vuport.c | 74 ++
 4 files changed, 89 insertions(+)
 create mode 100644 drivers/mfd/intel-vuport.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 1d0f090..0a932b3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5599,6 +5599,12 @@ L:   linux...@vger.kernel.org
 S: Supported
 F: drivers/cpufreq/intel_pstate.c
 
+INTEL VIRTUAL USB PORT DRIVER
+M: Lu Baolu 
+L: linux-usb@vger.kernel.org
+S: Supported
+F: drivers/mfd/intel-vuport.c
+
 INTEL FRAMEBUFFER DRIVER (excluding 810 and 815)
 M: Maik Broemme 
 L: linux-fb...@vger.kernel.org
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 9ca66de..48933d4 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1534,5 +1534,13 @@ config MFD_VEXPRESS_SYSREG
  System Registers are the platform configuration block
  on the ARM Ltd. Versatile Express board.
 
+config MFD_INTEL_VUPORT
+   tristate "Intel virtual USB port controller"
+   select MFD_CORE
+   depends on X86 && ACPI
+   help
+ Say Y here to enable support for Intel's dual role port mux
+ controlled by GPIOs.
+
 endmenu
 endif
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 0f230a6..0ccd107 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -198,3 +198,4 @@ intel-soc-pmic-objs := intel_soc_pmic_core.o 
intel_soc_pmic_crc.o
 intel-soc-pmic-$(CONFIG_INTEL_PMC_IPC) += intel_soc_pmic_bxtwc.o
 obj-$(CONFIG_INTEL_SOC_PMIC)   += intel-soc-pmic.o
 obj-$(CONFIG_MFD_MT6397)   += mt6397-core.o
+obj-$(CONFIG_MFD_INTEL_VUPORT) += intel-vuport.o
diff --git a/drivers/mfd/intel-vuport.c b/drivers/mfd/intel-vuport.c
new file mode 100644
index 000..a07920f
--- /dev/null
+++ b/drivers/mfd/intel-vuport.c
@@ -0,0 +1,74 @@
+/*
+ * MFD driver for Intel virtual USB port
+ *
+ * Copyright(c) 2016 Intel Corporation.
+ * Author: Lu Baolu 
+ *
+ * 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 
+
+/* ACPI GPIO Mappings */
+static const struct acpi_gpio_params id_gpio = { 0, 0, false };
+static const struct acpi_gpio_params vbus_gpio = { 1, 0, false };
+static const struct acpi_gpio_params mux_gpio = { 2, 0, false };
+static const struct acpi_gpio_mapping acpi_usb_gpios[] = {
+   { "id-gpios", _gpio, 1 },
+   { "vbus_en-gpios", _gpio, 1 },
+   { "usb_mux-gpios", _gpio, 1 },
+   { },
+};
+
+static const struct mfd_cell intel_vuport_mfd_cells[] = {
+   { .name = "extcon-usb-gpio", },
+   { .name = "intel-mux-gpio", },
+};
+
+static int vuport_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   int ret;
+
+   ret = acpi_dev_add_driver_gpios(ACPI_COMPANION(dev), acpi_usb_gpios);
+   if (ret)
+   return ret;
+
+   return mfd_add_devices(>dev, 0, intel_vuport_mfd_cells,
+   ARRAY_SIZE(intel_vuport_mfd_cells), NULL, 0,
+   NULL);
+}
+
+static int vuport_remove(struct platform_device *pdev)
+{
+   mfd_remove_devices(>dev);
+   acpi_dev_remove_driver_gpios(ACPI_COMPANION(>dev));
+
+   return 0;
+}
+
+static struct acpi_device_id vuport_acpi_match[] = {
+   { "INT3496" },
+   { }
+};
+MODULE_DEVICE_TABLE(acpi, vuport_acpi_match);
+
+static struct platform_driver vuport_driver = {
+   .driver = {
+   .name = "intel-vuport",
+   .acpi_match_table = ACPI_PTR(vuport_acpi_match),
+   },
+   .probe = vuport_probe,
+   .remove = vuport_remove,
+};
+
+module_platform_driver(vuport_driver);
+
+MODULE_AUTHOR("Lu Baolu ");
+MODULE_DESCRIPTION("Intel virtual USB port");
+MODULE_LICENSE("GPL v2");
-- 
2.1.4

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

Re: rtl8xxxu 4.4.5(from f23): I get a panic adding a new device to the driver

[poma]

On 17.03.2016 19:02, Jes Sorensen wrote:
> Jes Sorensen  writes:
>> Xose Vazquez Perez  writes:
>>> Hi,
>>>
>>> If I do:
>>> # echo "0bda 8176" > /sys/bus/usb/drivers/rtl8xxxu/new_id
>>
>> Hi Xose,
>>
>> Yes please don't do that. The rtl8xxxu driver relies on the .driver_info
>> field in struct use_device_id to carry information for the different
>> types of devices. If you hot add a device like above, the driver will
>> fail because that field now contains a NULL pointer.
>>
>> I should probably add a check for it in the probe function, but it will
>> simply be there to spit out a warning that it doesn't work to hot add a
>> device like this.
>>
>> If you build it with CONFIG_RTL8XXXU_UNTESTED the 0bda:8176 should be
>> included in the device list.
>>
>> Cheers,
>> Jes
> 
> Hi Xose,
> 
> I added the following patch to my tree to avoid this.
> 
> Cheers,
> Jes
> 
> commit 9202f4947aac1d60084ee79c9b5294eb42ba59dc
> Author: Jes Sorensen 
> Date:   Thu Mar 17 13:53:48 2016 -0400
> 
> rtl8xxxu: Fix OOPS if user tries to add device via /sys
> 
> This driver relies on driver_info in struct usb_device_id, hence
> adding a device via  /sys/bus/usb/drivers/rtl8xxxu/new_id would result
> in a NULL pointer dereference.
> 
> Instead print a message and return -ENODEV
> 
> Reported-by: Xose Vazquez Perez 
> Signed-off-by: Jes Sorensen 
> 
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.c 
> b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.c
> index 8d893f4..55fc00e 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.c
> @@ -9671,6 +9671,15 @@ static int rtl8xxxu_probe(struct usb_interface 
> *interface,
>  
>   udev = usb_get_dev(interface_to_usbdev(interface));
>  
> + if (!id->driver_info) {
> + dev_warn(>dev,
> +  "rtl8xxxu relies on driver_info in struct 
> usb_device_id.\n");
> + dev_warn(>dev,
> +  "Adding a device via 
> /sys/bus/usb/drivers/rtl8xxxu/new_id is not supported!\n");
> + ret = -ENODEV;
> + goto exit;
> + }
> +
>   switch (id->idVendor) {
>   case USB_VENDOR_ID_REALTEK:
>   switch(id->idProduct) {
>


Dynamic adding and removing a new device IDs to a USB device drivers
via /sys/bus/usb/drivers/.../[new_id|remove_id]
https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-bus-usb

is not supported only with rtl8xxxu?


--
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 3/6] usb: mux: add common code for Intel dual role port mux

[Lu Baolu]

Hi Chanwoo,

On 03/18/2016 03:52 PM, Chanwoo Choi wrote:
> Hi Baolu,
>
> On 2016년 03월 18일 15:32, Lu Baolu wrote:
>> Several Intel PCHs and SOCs have an internal mux that is used to
>> share one USB port between device controller and host controller.
>>
>> A usb port mux could be abstracted as the following elements:
>> 1) mux state: HOST or PERIPHERAL;
>> 2) an extcon cable which triggers the change of mux state between
>>HOST and PERIPHERAL;
>> 3) The required action to do the real port switch.
>>
>> This patch adds the common code to handle usb port mux. With this
>> common code, the individual mux driver, which always is platform
>> dependent, could focus on the real operation of mux switch.
>>
>> Signed-off-by: Lu Baolu 
>> Reviewed-by: Heikki Krogerus 
>> Reviewed-by: Felipe Balbi 
> Looks good to me about extcon usage.
>
> For extcon usage,
> Reviewed-by: Chanwoo Choi 

Thank you!

>
> Best Regards,
> Chanwoo Choi
>
>
>> ---
>>  Documentation/ABI/testing/sysfs-bus-platform |  15 +++
>>  MAINTAINERS  |   7 ++
>>  drivers/usb/Kconfig  |   2 +
>>  drivers/usb/Makefile |   1 +
>>  drivers/usb/mux/Kconfig  |  12 ++
>>  drivers/usb/mux/Makefile |   4 +
>>  drivers/usb/mux/intel-mux.c  | 175 
>> +++
>>  include/linux/usb/intel-mux.h|  40 ++
>>  8 files changed, 256 insertions(+)
>>  create mode 100644 drivers/usb/mux/Kconfig
>>  create mode 100644 drivers/usb/mux/Makefile
>>  create mode 100644 drivers/usb/mux/intel-mux.c
>>  create mode 100644 include/linux/usb/intel-mux.h
>>
>> diff --git a/Documentation/ABI/testing/sysfs-bus-platform 
>> b/Documentation/ABI/testing/sysfs-bus-platform
>> index 5172a61..23bf76e 100644
>> --- a/Documentation/ABI/testing/sysfs-bus-platform
>> +++ b/Documentation/ABI/testing/sysfs-bus-platform
>> @@ -18,3 +18,18 @@ Description:
>>  devices to opt-out of driver binding using a driver_override
>>  name such as "none".  Only a single driver may be specified in
>>  the override, there is no support for parsing delimiters.
>> +
>> +What:   /sys/bus/platform/devices/.../port_mux
>> +Date:   Febuary 2016
>> +Contact:Lu Baolu 
>> +Description:
>> +In some platforms, a single USB port is shared between a USB 
>> host
>> +controller and a device controller. A USB mux driver is needed 
>> to
>> +handle the port mux. port_mux attribute shows and stores the mux
>> +state.
>> +For read:
>> +'peripheral' - mux switched to PERIPHERAL controller;
>> +'host'   - mux switched to HOST controller.
>> +For write:
>> +'peripheral' - mux will be switched to PERIPHERAL controller;
>> +'host'   - mux will be switched to HOST controller.
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index da3e4d8..0dbee11 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -11399,6 +11399,13 @@ T:  git 
>> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
>>  S:  Maintained
>>  F:  drivers/usb/phy/
>>  
>> +USB PORT MUX DRIVER
>> +M:  Lu Baolu 
>> +L:  linux-usb@vger.kernel.org
>> +S:  Supported
>> +F:  include/linux/usb/intel-mux.h
>> +F:  drivers/usb/mux/intel-mux.c
>> +
>>  USB PRINTER DRIVER (usblp)
>>  M:  Pete Zaitcev 
>>  L:  linux-usb@vger.kernel.org
>> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
>> index 8ed451d..dbd6620 100644
>> --- a/drivers/usb/Kconfig
>> +++ b/drivers/usb/Kconfig
>> @@ -149,6 +149,8 @@ endif # USB
>>  
>>  source "drivers/usb/phy/Kconfig"
>>  
>> +source "drivers/usb/mux/Kconfig"
>> +
>>  source "drivers/usb/gadget/Kconfig"
>>  
>>  config USB_LED_TRIG
>> diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
>> index d5c57f1..6433f0c 100644
>> --- a/drivers/usb/Makefile
>> +++ b/drivers/usb/Makefile
>> @@ -6,6 +6,7 @@
>>  
>>  obj-$(CONFIG_USB)   += core/
>>  obj-$(CONFIG_USB_SUPPORT)   += phy/
>> +obj-$(CONFIG_USB_SUPPORT)   += mux/
>>  
>>  obj-$(CONFIG_USB_DWC3)  += dwc3/
>>  obj-$(CONFIG_USB_DWC2)  += dwc2/
>> diff --git a/drivers/usb/mux/Kconfig b/drivers/usb/mux/Kconfig
>> new file mode 100644
>> index 000..62e2cc3
>> --- /dev/null
>> +++ b/drivers/usb/mux/Kconfig
>> @@ -0,0 +1,12 @@
>> +#
>> +# USB port mux driver configuration
>> +#
>> +menu "USB Port MUX drivers"
>> +config INTEL_USB_MUX
>> +select EXTCON
>> +def_bool n
>> +help
>> +  Common code for all Intel dual role port mux drivers. All Intel
>> +  usb port mux drivers should select it.
>> +
>> +endmenu
>> diff --git a/drivers/usb/mux/Makefile b/drivers/usb/mux/Makefile
>> new file mode 100644
>> index 

Re: [PATCH 0/5] da8xx USB clocks

[Sergei Shtylyov]

On 3/16/2016 1:35 AM, David Lechner wrote:


I've implemented some proper clocks for the USB PHY clocks on da8xx. For those
not familiar with the architecture, the SoC has one USB 1.1 OHCI port and one
USB 2.O OTG port. The USB 1.1 PHY clock can optionally be supplied by the PLL
in the USB 2.0 PHY.

I have seen some comments in the past that these clock details don't belong in
the USB drivers and I agree with that. So, I have moved the handling of the
clocks out of the USB drivers to the mach code with the rest of the SoC clocks.

This code has been tested on LEGO MINDSTORMS EV3 (AM1808/da850 family). Here is
an output of the davinci clock debug to give you a better idea of how clocks
are related.

 root@ev3dev:~# cat /sys/kernel/debug/davinci_clocks
 ref_clk   users=23  2400 Hz
   pll0users=20 pll 3 Hz
 pll0_aux_clk  users= 4 pll  2400 Hz
   ...
   usb20_phy   users= 2  2400 Hz
 usb11_phy users= 1  2400 Hz
   ...
 usb_ref_clk   users= 0  4800 Hz

usb20_phy and usb11_phy can optionally be children of usb_ref_clk instead.


I'm planning on adding device tree bindings for the ohci driver, but I need to
get some things sorted out with the regulator subsystem first. I see that Petr
has been working on device tree support for the musb driver. This should take
care of some of the concerns related to his changes too, for example, the
ti,usb2-phy-refclock-hz device tree property is no longer needed because it
is now taken care of in the clock code. I've actually included one of Petr's
patchs here since one of my patches depends on it.

I'm also working on device tree bindings for davinci clocks, but it will take
me a while to get there. But that should not hold up the device tree bindings
for da8xx ohci and musb.


   Nice to see that someone still cares about this code. With the ending of 
the MontaVista's efforts, it largely seemed like abandonware...


MBR, Sergei

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

Re: Composite USB device reset /drivers/usb/core/hub.c - binding order problem

[Mikolaj Ch]

Thanks, right I was looking at older version of Linux (3.8) before
https://github.com/torvalds/linux/commit/6aec044cc2f5670cf3b143c151c8be846499bd15.
But the question remains why post_reset method is called in reverse
order for interfaces.
Is there any reason for this ? especially after rebind has been
changed in above mentioned patch from reverse to forward order.

On Thu, Mar 17, 2016 at 6:57 PM, Alan Stern  wrote:
> On Thu, 17 Mar 2016, Mikolaj Ch wrote:
>
>> Hi,
>>
>> I have a composite usb device where order of binding the drivers to
>> interfaces matters.
>> When the device is plugged in binding is from 0-th till n-th interface
>> but in usb_reset_device function in  /drivers/usb/core/hub.c after
>> reset binding is done in revers order from n-th till 0.
>> Is there a reason for doing so ?
>
> You are reading the code wrong.  usb_reset_device() calls the
> post_reset methods of the interface drivers in reverse order, but the
> rebinding is done by rebind_marked_interfaces() in driver.c in forward
> order.
>
> Alan Stern
>
>> Can I expect any disadvantages after changing this order to be from 0
>> till n-th ?
>>
>> I know that the easiest solution is to claim the device driver is
>> badly written but I don't have a possibility to change it so I want to
>> know if changing this order in usb cored driver is possible without
>> affecting other functionality.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5 v10] dt/bindings: Add binding for the DA8xx MUSB driver

[Petr Kulhavy]

On 11.03.2016 19:24, Sergei Shtylyov wrote:

On 03/11/2016 07:21 PM, Petr Kulhavy wrote:


I am having 2nd thought on parsing the clock prop, Sergei's comment
might be better. I will look more on this over this weekend. (DT is not
in my expertise...)

Regards,
-Bin.


I like Sergei's comment as well, but cannot see (yet) how the clock 
input

selection would be done.


   The same way as now, of course. Only getting the clock frequency 
would be different, via clk_get_rate()...


I mean, it makes sense to do the clock abstraction only if it can be 
done

properly and the clock input selection can be covered as well.


   No, this item has never been covered by the clk layer IIRC. That's 
what the device node props are for.



The DA8xx platform is missing the real clock framework and therefore the
different clocks cannot be referenced in DT.


   You mean more than one clock per device?


There is a fake clock framework in arch/arm/mach-davinci/clock.c - I've
already been through that and then gave up.


   I'm not sure why you call it "fake". It's a normal clk 
implementation, just not converted to the common clk framework.




Hi Sergei,

what I mean is that the DA8xx platform does not use the common clock 
framework. It uses its own clock implementation instead which is 
incompatible with the common clock framework, since it uses the same 
function names. So the common clock framework cannot be even compiled 
with this architecture.


With common clock framework the USB 2.0 clock would be modelled as a 
multiplexer between AUXCLK and USB_REFCLKIN.
The AUXCLK would be a phandle to the respective internal clock. 
USB_REFCLKIN then a phandle to either fixed clock or another clock source.
Providing the right parent phandle, internally calling set_parent() 
would do the job and no extra property would be needed.

Or did I miss something?

If the common clock framework is not available for this platform then 
the only option I see is what I did in my patch -  to set the frequency 
via an integer property and control the multiplexer with another 
property. We cannot even do what you suggested as the fixed clock simply 
does not exist due to the lack of the common clock framework.

Or do you see another way?

Regards
Petr
--
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 v5 0/6] usb: add support for Intel dual role port mux

[Lu Baolu]

Intel SOC chips are featured with USB dual role. The host role is
provided by Intel xHCI IP, and the gadget role is provided by IP
from designware. Tablet platform designs always share a single
port for both host and gadget controllers. There is a mux to
switch the port to the right controller according to the cable
type. OS needs to provide the callback to control the mux when
a plug-in event raises. The method to control the mux is platform
dependent. At least three types of implementation can be found
across current devices. 1) GPIO pins; 2) a unit which can be
controlled by memory mapped registers; 3) ACPI ASL code.

This patch series adds supports for Intel dual role port mux.
It includes:
(1) A helper layer on top of extcon for individual mux driver.
It listens to the USB-HOST extcon cable and call the switch
call-back when the cable state changes.
(2) Drivers for GPIO controlled port mux which could be found on
Baytrail devices. A mfd driver is used to split the GPIOs into
USB gpio extcon device and a USB mux device. Driver for USB
gpio extcon device is already in upstream Linux. This patch
series includes a driver for GPIO USB mux.
(3) Drivers for USB port mux controlled through memory mapped
registers and the logic to create the mux device. This type
of dual role port mux could be found in Cherry Trail and
Broxton devices.

Lu Baolu (6):
  extcon: usb-gpio: add device binding for platform device
  extcon: usb-gpio: add support for ACPI gpio interface
  usb: mux: add common code for Intel dual role port mux
  usb: mux: add driver for Intel gpio controlled port mux
  usb: mux: add driver for Intel drcfg controlled port mux
  mfd: intel_vuport: Add Intel virtual USB port MFD Driver

Change log:
v4->v5:
 - Change the extcon interfaces with the new ones suggested by
   2a9de9c0f08d6 (extcon: Use the unique id for external connector
   instead of string)
 - remove patch "usb: pci-quirks: add Intel USB drcfg mux device"
   from this serial due to that it's not driver staff. Will be
   submitted seperately.

v3->v4:
 - Check all patches with "checkpatch.pl --strict", and fix all
   CHECKs;
 - Change sysfs node from "intel_mux" to "port_mux";
 - Refines below confusing functions:
   intel_usb_mux_register() -> intel_usb_mux_bind_cable()
   intel_usb_mux_unregister() -> intel_usb_mux_unbind_cable();
 - Remove unnecessary struct intel_mux_dev.

v2->v3:
 - uvport mfd driver got reviewed by Lee Jones, the following
   changes were made accordingly.
 - seperate uvport driver from the mux drivers in MAINTAINERS file
 - refine the description in Kconfig
 - refine the mfd_cell structure data

v1->v2:
 - move mux driver from drivers/usb/misc to drivers/usb/mux;
 - replace debugfs with sysfs for user level mux control;
 - remove unnecessary register restore if mux registeration failed;
 - Add "Acked-by: Chanwoo Choi " to extcon changes;
 - Make the file names and exported function names more specific;
 - Remove the usb_mux_get_dev() interface;
 - Move "struct intel_usb_mux" from .h to .c file;
 - Fix various kbuild robot warnings.

 Documentation/ABI/testing/sysfs-bus-platform |  15 +++
 MAINTAINERS  |  15 +++
 drivers/extcon/extcon-usb-gpio.c |  10 +-
 drivers/mfd/Kconfig  |   8 ++
 drivers/mfd/Makefile |   1 +
 drivers/mfd/intel-vuport.c   |  74 +++
 drivers/usb/Kconfig  |   2 +
 drivers/usb/Makefile |   1 +
 drivers/usb/mux/Kconfig  |  28 +
 drivers/usb/mux/Makefile |   6 +
 drivers/usb/mux/intel-mux-drcfg.c| 159 
 drivers/usb/mux/intel-mux-gpio.c | 122 +++
 drivers/usb/mux/intel-mux.c  | 175 +++
 include/linux/usb/intel-mux.h|  40 ++
 14 files changed, 655 insertions(+), 1 deletion(-)
 create mode 100644 drivers/mfd/intel-vuport.c
 create mode 100644 drivers/usb/mux/Kconfig
 create mode 100644 drivers/usb/mux/Makefile
 create mode 100644 drivers/usb/mux/intel-mux-drcfg.c
 create mode 100644 drivers/usb/mux/intel-mux-gpio.c
 create mode 100644 drivers/usb/mux/intel-mux.c
 create mode 100644 include/linux/usb/intel-mux.h

-- 
2.1.4

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

Re: [PATCH 3/5] ARM: davinci: da8xx: add cfgchip2 to resources

[Sergei Shtylyov]

On 03/16/2016 09:22 PM, Sergei Shtylyov wrote:


Also, I am not finding any existing data structure to pass the musb
set_mode
function to the phy in either usb_phy or usb_otg. Setting the mode
(host/peripheral/otg) is done in the same PHY register, so it seems
like it
should be implemented in the new phy driver as well.


Perhaps we'd have to sacrifice that functionality...


The device I am working on (LEGO MINDSTORMS EV3) has the port wired as
peripheral only, so I don't think leaving this out is an option. Leaving it in
OTG mode doesn't work because the required electrical connections are just not
there.


The set_mode() method doesn't have anything to do with the predefined
roles. What CFGCHIP2 setting do is to override the ID input (and also the VBUS
level comparator). This is not required for the normal functioning of either
host or peripheral AFAIR.


  Or at least it wasn't when I last looked. Now it does... :-/


[...]


MBR, Sergei

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

Re: [PATCH 3/5] ARM: davinci: da8xx: add cfgchip2 to resources

[Sergei Shtylyov]

On 03/16/2016 09:14 PM, David Lechner wrote:


Also, I am not finding any existing data structure to pass the musb
set_mode
function to the phy in either usb_phy or usb_otg. Setting the mode
(host/peripheral/otg) is done in the same PHY register, so it seems
like it
should be implemented in the new phy driver as well.


Perhaps we'd have to sacrifice that functionality...


The device I am working on (LEGO MINDSTORMS EV3) has the port wired as
peripheral only, so I don't think leaving this out is an option. Leaving it in
OTG mode doesn't work because the required electrical connections are just not
there.


   The set_mode() method doesn't have anything to do with the predefined 
roles. What CFGCHIP2 setting do is to override the ID input (and also the VBUS 
level comparator). This is not required for the normal functioning of either 
host or peripheral AFAIR.


[...]

MBR, Sergei

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

Re: [PATCH v2 11/11] usb: musb: da8xx: Remove mach code

[David Lechner]

On 03/17/2016 08:11 AM, Sergei Shtylyov wrote:

On 3/17/2016 5:26 AM, David Lechner wrote:


  glue->dev= >dev;
  pdata->platform_ops= _ops;

-glue->phy = usb_phy_generic_register();
-if (IS_ERR(glue->phy)) {
-ret = PTR_ERR(glue->phy);
-goto err5;
+glue->usb_phy = usb_phy_generic_register();


Hm, do we still need the USB PHY? It does nothing IIRC...



Unfortunately, yes. It is used in musb_core, etc., mainly for otg->state.

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

Re: [PATCH 2/5] ARM: davinci: da8xx: add usb phy clocks

[David Lechner]

On 03/16/2016 01:04 PM, Sergei Shtylyov wrote:


No, I mean why is not this implemented as a part of clk_set_parent()?



There is not currently any framework for mux clocks in the davinci 
clocks. I am hoping to eventually get the davinci clocks moved to the 
common clock framework, so this was just a hack to get things working 
with what was already existing. I did not want to spend the time fixing 
it twice.


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

Re: [PATCH v2] usb/core: usb_alloc_dev(): fix setting of ->portnum

[Alan Stern]

On Thu, 17 Mar 2016, Nicolai Stange wrote:

> With commit 69bec7259853 ("USB: core: let USB device know device node"),
> the port1 argument of usb_alloc_dev() gets overwritten as follows:
> 
>   ... usb_alloc_dev(..., unsigned port1)
>   {
> ...
> if (!parent->parent) {
>   port1 = usb_hcd_find_raw_port_number(..., port1);
> }
> ...
>   }
> 
> Later on, this now overwritten port1 gets assigned to ->portnum:
> 
>   dev->portnum = port1;
> 
> However, since xhci_find_raw_port_number() isn't idempotent, the
> aforementioned commit causes a number of KASAN splats like the following:

...

> Fix this by not overwriting the port1 argument in usb_alloc_dev(), but
> storing the raw port number as required by OF in an additional variable,
> raw_port.
> 
> Fixes: 69bec7259853 ("USB: core: let USB device know device node")
> Signed-off-by: Nicolai Stange 
> ---
>  Applicable to linux-next-20160317
> 
>  Changes to v1:
>  - Initialize raw_port with port1

Acked-by: 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 v5 3/6] usb: mux: add common code for Intel dual role port mux

[Chanwoo Choi]

Hi Baolu,

On 2016년 03월 18일 15:32, Lu Baolu wrote:
> Several Intel PCHs and SOCs have an internal mux that is used to
> share one USB port between device controller and host controller.
> 
> A usb port mux could be abstracted as the following elements:
> 1) mux state: HOST or PERIPHERAL;
> 2) an extcon cable which triggers the change of mux state between
>HOST and PERIPHERAL;
> 3) The required action to do the real port switch.
> 
> This patch adds the common code to handle usb port mux. With this
> common code, the individual mux driver, which always is platform
> dependent, could focus on the real operation of mux switch.
> 
> Signed-off-by: Lu Baolu 
> Reviewed-by: Heikki Krogerus 
> Reviewed-by: Felipe Balbi 

Looks good to me about extcon usage.

For extcon usage,
Reviewed-by: Chanwoo Choi 

Best Regards,
Chanwoo Choi


> ---
>  Documentation/ABI/testing/sysfs-bus-platform |  15 +++
>  MAINTAINERS  |   7 ++
>  drivers/usb/Kconfig  |   2 +
>  drivers/usb/Makefile |   1 +
>  drivers/usb/mux/Kconfig  |  12 ++
>  drivers/usb/mux/Makefile |   4 +
>  drivers/usb/mux/intel-mux.c  | 175 
> +++
>  include/linux/usb/intel-mux.h|  40 ++
>  8 files changed, 256 insertions(+)
>  create mode 100644 drivers/usb/mux/Kconfig
>  create mode 100644 drivers/usb/mux/Makefile
>  create mode 100644 drivers/usb/mux/intel-mux.c
>  create mode 100644 include/linux/usb/intel-mux.h
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-platform 
> b/Documentation/ABI/testing/sysfs-bus-platform
> index 5172a61..23bf76e 100644
> --- a/Documentation/ABI/testing/sysfs-bus-platform
> +++ b/Documentation/ABI/testing/sysfs-bus-platform
> @@ -18,3 +18,18 @@ Description:
>   devices to opt-out of driver binding using a driver_override
>   name such as "none".  Only a single driver may be specified in
>   the override, there is no support for parsing delimiters.
> +
> +What:/sys/bus/platform/devices/.../port_mux
> +Date:Febuary 2016
> +Contact: Lu Baolu 
> +Description:
> + In some platforms, a single USB port is shared between a USB 
> host
> + controller and a device controller. A USB mux driver is needed 
> to
> + handle the port mux. port_mux attribute shows and stores the mux
> + state.
> + For read:
> + 'peripheral' - mux switched to PERIPHERAL controller;
> + 'host'   - mux switched to HOST controller.
> + For write:
> + 'peripheral' - mux will be switched to PERIPHERAL controller;
> + 'host'   - mux will be switched to HOST controller.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index da3e4d8..0dbee11 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11399,6 +11399,13 @@ T:   git 
> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
>  S:   Maintained
>  F:   drivers/usb/phy/
>  
> +USB PORT MUX DRIVER
> +M:   Lu Baolu 
> +L:   linux-usb@vger.kernel.org
> +S:   Supported
> +F:   include/linux/usb/intel-mux.h
> +F:   drivers/usb/mux/intel-mux.c
> +
>  USB PRINTER DRIVER (usblp)
>  M:   Pete Zaitcev 
>  L:   linux-usb@vger.kernel.org
> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
> index 8ed451d..dbd6620 100644
> --- a/drivers/usb/Kconfig
> +++ b/drivers/usb/Kconfig
> @@ -149,6 +149,8 @@ endif # USB
>  
>  source "drivers/usb/phy/Kconfig"
>  
> +source "drivers/usb/mux/Kconfig"
> +
>  source "drivers/usb/gadget/Kconfig"
>  
>  config USB_LED_TRIG
> diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
> index d5c57f1..6433f0c 100644
> --- a/drivers/usb/Makefile
> +++ b/drivers/usb/Makefile
> @@ -6,6 +6,7 @@
>  
>  obj-$(CONFIG_USB)+= core/
>  obj-$(CONFIG_USB_SUPPORT)+= phy/
> +obj-$(CONFIG_USB_SUPPORT)+= mux/
>  
>  obj-$(CONFIG_USB_DWC3)   += dwc3/
>  obj-$(CONFIG_USB_DWC2)   += dwc2/
> diff --git a/drivers/usb/mux/Kconfig b/drivers/usb/mux/Kconfig
> new file mode 100644
> index 000..62e2cc3
> --- /dev/null
> +++ b/drivers/usb/mux/Kconfig
> @@ -0,0 +1,12 @@
> +#
> +# USB port mux driver configuration
> +#
> +menu "USB Port MUX drivers"
> +config INTEL_USB_MUX
> + select EXTCON
> + def_bool n
> + help
> +   Common code for all Intel dual role port mux drivers. All Intel
> +   usb port mux drivers should select it.
> +
> +endmenu
> diff --git a/drivers/usb/mux/Makefile b/drivers/usb/mux/Makefile
> new file mode 100644
> index 000..84f0ae8
> --- /dev/null
> +++ b/drivers/usb/mux/Makefile
> @@ -0,0 +1,4 @@
> +#
> +# Makefile for USB port mux drivers
> +#
> +obj-$(CONFIG_INTEL_USB_MUX)  

Re: [PATCH] usb: chipidea: Configure DMA properties and ops from DT

[Russell King - ARM Linux]

On Fri, Mar 18, 2016 at 09:54:14AM +0800, Peter Chen wrote:
> Although I don't know what kinds of bugs it may have, it may be
> met before, otherwise, why most of platform drivers need to call
> dma_set_coherent_mask or dma_coerce_mask_and_coherent explicitly

See Documentation/DMA-API.txt, specifically the section starting

  Part Ic - DMA addressing limitations
  

and also Documentation/DMA-API-HOWTO.txt, the section on

  DMA addressing limitations

which provides further information.

Drivers using DMA should be using dma_set_mask_and_coherent() _or_
one of dma_set_mask() and dma_set_coherent_mask() depending on which
types of DMA they wish to perform.  Drivers should not use
dma_coerce_mask_and_coherent() except in exceptional circumstances:
that function is more a marker that they or some bus/platform code
is doing something wrong.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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 v5 6/6] mfd: intel_vuport: Add Intel virtual USB port MFD Driver

[Lu Baolu]

Some Intel platforms have an USB port mux controlled by GPIOs.
There's a single ACPI platform device that provides both USB ID
extcon device and a USB port mux device. This MFD driver will
split the 2 devices for their respective drivers.

Signed-off-by: Lu Baolu 
Suggested-by: David Cohen 
Reviewed-by: Felipe Balbi 
Signed-off-by: Fengguang Wu 
Reviewed-by: Lee Jones 
---
 MAINTAINERS|  6 
 drivers/mfd/Kconfig|  8 +
 drivers/mfd/Makefile   |  1 +
 drivers/mfd/intel-vuport.c | 74 ++
 4 files changed, 89 insertions(+)
 create mode 100644 drivers/mfd/intel-vuport.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 1d0f090..0a932b3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5599,6 +5599,12 @@ L:   linux...@vger.kernel.org
 S: Supported
 F: drivers/cpufreq/intel_pstate.c
 
+INTEL VIRTUAL USB PORT DRIVER
+M: Lu Baolu 
+L: linux-usb@vger.kernel.org
+S: Supported
+F: drivers/mfd/intel-vuport.c
+
 INTEL FRAMEBUFFER DRIVER (excluding 810 and 815)
 M: Maik Broemme 
 L: linux-fb...@vger.kernel.org
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 9ca66de..48933d4 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1534,5 +1534,13 @@ config MFD_VEXPRESS_SYSREG
  System Registers are the platform configuration block
  on the ARM Ltd. Versatile Express board.
 
+config MFD_INTEL_VUPORT
+   tristate "Intel virtual USB port controller"
+   select MFD_CORE
+   depends on X86 && ACPI
+   help
+ Say Y here to enable support for Intel's dual role port mux
+ controlled by GPIOs.
+
 endmenu
 endif
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 0f230a6..0ccd107 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -198,3 +198,4 @@ intel-soc-pmic-objs := intel_soc_pmic_core.o 
intel_soc_pmic_crc.o
 intel-soc-pmic-$(CONFIG_INTEL_PMC_IPC) += intel_soc_pmic_bxtwc.o
 obj-$(CONFIG_INTEL_SOC_PMIC)   += intel-soc-pmic.o
 obj-$(CONFIG_MFD_MT6397)   += mt6397-core.o
+obj-$(CONFIG_MFD_INTEL_VUPORT) += intel-vuport.o
diff --git a/drivers/mfd/intel-vuport.c b/drivers/mfd/intel-vuport.c
new file mode 100644
index 000..a07920f
--- /dev/null
+++ b/drivers/mfd/intel-vuport.c
@@ -0,0 +1,74 @@
+/*
+ * MFD driver for Intel virtual USB port
+ *
+ * Copyright(c) 2016 Intel Corporation.
+ * Author: Lu Baolu 
+ *
+ * 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 
+
+/* ACPI GPIO Mappings */
+static const struct acpi_gpio_params id_gpio = { 0, 0, false };
+static const struct acpi_gpio_params vbus_gpio = { 1, 0, false };
+static const struct acpi_gpio_params mux_gpio = { 2, 0, false };
+static const struct acpi_gpio_mapping acpi_usb_gpios[] = {
+   { "id-gpios", _gpio, 1 },
+   { "vbus_en-gpios", _gpio, 1 },
+   { "usb_mux-gpios", _gpio, 1 },
+   { },
+};
+
+static const struct mfd_cell intel_vuport_mfd_cells[] = {
+   { .name = "extcon-usb-gpio", },
+   { .name = "intel-mux-gpio", },
+};
+
+static int vuport_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   int ret;
+
+   ret = acpi_dev_add_driver_gpios(ACPI_COMPANION(dev), acpi_usb_gpios);
+   if (ret)
+   return ret;
+
+   return mfd_add_devices(>dev, 0, intel_vuport_mfd_cells,
+   ARRAY_SIZE(intel_vuport_mfd_cells), NULL, 0,
+   NULL);
+}
+
+static int vuport_remove(struct platform_device *pdev)
+{
+   mfd_remove_devices(>dev);
+   acpi_dev_remove_driver_gpios(ACPI_COMPANION(>dev));
+
+   return 0;
+}
+
+static struct acpi_device_id vuport_acpi_match[] = {
+   { "INT3496" },
+   { }
+};
+MODULE_DEVICE_TABLE(acpi, vuport_acpi_match);
+
+static struct platform_driver vuport_driver = {
+   .driver = {
+   .name = "intel-vuport",
+   .acpi_match_table = ACPI_PTR(vuport_acpi_match),
+   },
+   .probe = vuport_probe,
+   .remove = vuport_remove,
+};
+
+module_platform_driver(vuport_driver);
+
+MODULE_AUTHOR("Lu Baolu ");
+MODULE_DESCRIPTION("Intel virtual USB port");
+MODULE_LICENSE("GPL v2");
-- 
2.1.4

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

Re: Crash when resuming system (related to USB?) with 4.4

[Greg KH]

On Fri, Mar 18, 2016 at 10:36:07AM +0100, Frederik Himpe wrote:
> Half of the time when resuming my system, it completely hangs. I managed to 
> find this trace in pstore:
> 
> 
> ==./dmesg-efi-145829002001001==
> Oops#1 Part1
> <4>[20505.738344]  [] ? hub_event+0x75d/0x14f0 [usbcore]
> <4>[20505.738413]  [] ? process_one_work+0x157/0x410
> <4>[20505.738474]  [] ? worker_thread+0x4d/0x450
> <4>[20505.738555]  [] ? process_one_work+0x410/0x410
> <4>[20505.738617]  [] ? kthread+0xcd/0xf0
> <4>[20505.738691]  [] ? kthread_create_on_node+0x190/0x190
> <4>[20505.738784]  [] ? ret_from_fork+0x3f/0x70
> <4>[20505.738843]  [] ? kthread_create_on_node+0x190/0x190
> <4>[20505.738932] Code: 89 c2 48 0f 42 15 80 3c 85 00 48 01 ca 48 c1 ea 0c 48 
> c1 e2 06 48 01 fa 48 8b 72 20 4c 8d 46 ff 83 e6 01 49 0f 45 d0 4c 8b 6a 30 
> <4d> 8b 65 00 65 4c 03 25 23 ce e4 7e 83 3d a0 56 94 00 01 7e 2e 
> <1>[20505.739337] RIP  [] kfree+0x91/0x250
> <4>[20505.739402]  RSP 
> <4>[20505.739438] CR2: 
> <4>[20505.756194] ---[ end trace 34cacb43f9f2617d ]---
> ==./dmesg-efi-145829002002001==
> Oops#1 Part2
> <4>[20505.737432] R13:  R14: 0001 R15: 
> 8800b7121218
> <4>[20505.737501] FS:  () GS:88023ea0() 
> knlGS:
> <4>[20505.737588] CS:  0010 DS:  ES:  CR0: 80050033
> <4>[20505.737656] CR2:  CR3: b481b000 CR4: 
> 001406f0
> <4>[20505.737726] Stack:
> <4>[20505.737752]  0001 88023220f9a0 880231ec4000 
> 1bdb7108
> <4>[20505.737836]  880231ec4000 880231ec4000 8800368a2000 
> 880231ec40a0
> <4>[20505.737913]  0001 a00935ad 880231ec4090 
> a0080347
> <4>[20505.737994] Call Trace:
> <4>[20505.738048]  [] ? 
> usb_release_bos_descriptor+0x1d/0x40 [usbcore]
> <4>[20505.738134]  [] ? usb_release_dev+0x27/0x60 [usbcore]
> <4>[20505.738206]  [] ? device_release+0x2d/0x90
> <4>[20505.738270]  [] ? kobject_release+0x75/0x1a0


This looks worrysome, there was a patch sent to the linux-usb mailing
list with the subject:
[PATCH] usb: hub: fix panic caused by NULL bos pointer during reset 
device

can you see if it solves this issue for you or not?

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] uas: Limit qdepth at the scsi-host level

[James Bottomley]

On Sat, 2016-03-19 at 09:59 +0100, Hans de Goede wrote:
> Commit 64d513ac31bd ("scsi: use host wide tags by default") causes
> the scsi-core to queue more cmnds then we can handle on devices with
> multiple LUNs, limit the qdepth at the scsi-host level instead of
> per slave to fix this.

Help me understand this bug a bit more.  Are you saying that the commit
you identify is causing the block layer to queue more commands than
you've set the per-lun limit to?  In which case we have a serious
problem for more than just UAS.  Or are you saying that UAS always had
a global command limit, but it just didn't get set correctly; however,
it mostly worked until the above commit exposed the problem?


James

--
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 10/11] usb: musb: da8xx: Use devm in probe

[Sergei Shtylyov]

Hello.

On 3/17/2016 5:26 AM, David Lechner wrote:


Simplify things a bit by using devm functions where possible.

Signed-off-by: David Lechner 
---

v2 changes: This is part of a previous patch that was split. No changes from
previous version.


  drivers/usb/musb/da8xx.c | 28 
  1 file changed, 8 insertions(+), 20 deletions(-)

diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index b03d3b8..50f07a5 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -489,32 +489,27 @@ static int da8xx_probe(struct platform_device *pdev)
struct platform_device  *musb;
struct da8xx_glue   *glue;
struct platform_device_info pinfo;
-   struct clk  *clk;


   I wouldn't remove this variable to minimize the patch.

[...]

MBR, Sergei

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

Re: [PATCH 2/3] usb: dwc3: increase maximum number of TRBs per endpoint

[Felipe Balbi]

Hi,

Bin Liu  writes:
> [ text/plain ]
> Hi,
>
> On Fri, Mar 11, 2016 at 6:54 AM, Felipe Balbi
>  wrote:
>> previously we were using a maximum of 32 TRBs per
>> endpoint. With each TRB being 16 bytes long, we were
>> using 512 bytes of memory for each endpoint.
>>
>> However, SLAB/SLUB will always allocate PAGE_SIZE
>> chunks. In order to better utilize the memory we
>> allocate and to allow deeper queues for gadgets
>> which would benefit from it (g_ether comes to mind),
>> let's increase the maximum to 256 TRBs which rounds
>> up to 4096 bytes for each endpoint.
>
> Do we want to increase the same for event ring buffers as
> while, which is allocated by dma_alloc_coherent(), which
> is also at PAGE_SIZE chunks, right?

I could, but that's much less important. Currently we have up to 2
events per endpoint which is very, very unlikely to happen. Plus, in
that case there's no tangible benefit. $subject, however, I've been
using on some performance optimization I've been trying to achieve (not
ready for submission just yet).

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v1] usb: xhci: applying XHCI_PME_STUCK_QUIRK to Intel BXT B0 host

[Greg KH]

On Wed, Mar 16, 2016 at 11:41:50AM +0100, Robert Dobrowolski wrote:
> From: Rafal Redzimski 
> 
> Signed-off-by: Rafal Redzimski 

We can't take patches without any changelog entry :(

--
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 v5 5/6] usb: mux: add driver for Intel drcfg controlled port mux

[Lu Baolu]

Several Intel PCHs and SOCs have an internal mux that is used to
share one USB port between device controller and host controller.
The mux is handled through the Dual Role Configuration Register.

Signed-off-by: Heikki Krogerus 
Signed-off-by: Lu Baolu 
Signed-off-by: Wu Hao 
Reviewed-by: Felipe Balbi 
---
 MAINTAINERS   |   1 +
 drivers/usb/mux/Kconfig   |   7 ++
 drivers/usb/mux/Makefile  |   1 +
 drivers/usb/mux/intel-mux-drcfg.c | 159 ++
 4 files changed, 168 insertions(+)
 create mode 100644 drivers/usb/mux/intel-mux-drcfg.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 99bc198..1d0f090 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11406,6 +11406,7 @@ S:  Supported
 F: include/linux/usb/intel-mux.h
 F: drivers/usb/mux/intel-mux.c
 F: drivers/usb/mux/intel-mux-gpio.c
+F: drivers/usb/mux/intel-mux-drcfg.c
 
 USB PRINTER DRIVER (usblp)
 M: Pete Zaitcev 
diff --git a/drivers/usb/mux/Kconfig b/drivers/usb/mux/Kconfig
index 2b197c1..975c5a0 100644
--- a/drivers/usb/mux/Kconfig
+++ b/drivers/usb/mux/Kconfig
@@ -18,4 +18,11 @@ config INTEL_MUX_GPIO
  Say Y here to enable support for Intel dual role port mux
  controlled by GPIOs.
 
+config INTEL_MUX_DRCFG
+   tristate "Intel dual role port mux controlled by register"
+   depends on X86
+   select INTEL_USB_MUX
+   help
+ Say Y here to enable support for Intel dual role port mux
+ controlled by the Dual Role Configuration Register.
 endmenu
diff --git a/drivers/usb/mux/Makefile b/drivers/usb/mux/Makefile
index 66f765c..3179909 100644
--- a/drivers/usb/mux/Makefile
+++ b/drivers/usb/mux/Makefile
@@ -3,3 +3,4 @@
 #
 obj-$(CONFIG_INTEL_USB_MUX)+= intel-mux.o
 obj-$(CONFIG_INTEL_MUX_GPIO)   += intel-mux-gpio.o
+obj-$(CONFIG_INTEL_MUX_DRCFG)  += intel-mux-drcfg.o
diff --git a/drivers/usb/mux/intel-mux-drcfg.c 
b/drivers/usb/mux/intel-mux-drcfg.c
new file mode 100644
index 000..4b6c2d1
--- /dev/null
+++ b/drivers/usb/mux/intel-mux-drcfg.c
@@ -0,0 +1,159 @@
+/**
+ * intel-mux-drcfg.c - Driver for Intel USB mux via register
+ *
+ * Copyright (C) 2016 Intel Corporation
+ * Author: Heikki Krogerus 
+ * Author: Lu Baolu 
+ *
+ * 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 
+
+#define INTEL_MUX_CFG0 0x00
+#define INTEL_MUX_CFG1 0x04
+#define CFG0_SW_IDPIN  BIT(20)
+#define CFG0_SW_IDPIN_EN   BIT(21)
+#define CFG0_SW_VBUS_VALID BIT(24)
+#define CFG1_SW_MODE   BIT(29)
+#define CFG1_POLL_TIMEOUT  1000
+
+struct intel_mux_drcfg {
+   struct device *dev;
+   void __iomem *regs;
+};
+
+static struct intel_mux_drcfg *mux;
+
+static inline int intel_mux_drcfg_switch(struct device *dev, bool host)
+{
+   unsigned long timeout;
+   u32 data;
+
+   /* Check and set mux to SW controlled mode */
+   data = readl(mux->regs + INTEL_MUX_CFG0);
+   if (!(data & CFG0_SW_IDPIN_EN)) {
+   data |= CFG0_SW_IDPIN_EN;
+   writel(data, mux->regs + INTEL_MUX_CFG0);
+   }
+
+   /*
+* Configure CFG0 to switch the mux and VBUS_VALID bit is
+* required for device mode.
+*/
+   data = readl(mux->regs + INTEL_MUX_CFG0);
+   if (host)
+   data &= ~(CFG0_SW_IDPIN | CFG0_SW_VBUS_VALID);
+   else
+   data |= (CFG0_SW_IDPIN | CFG0_SW_VBUS_VALID);
+   writel(data, mux->regs + INTEL_MUX_CFG0);
+
+   /*
+* Polling CFG1 for safety, most case it takes about 600ms
+* to finish mode switching, set TIMEOUT long enough.
+*/
+   timeout = jiffies + msecs_to_jiffies(CFG1_POLL_TIMEOUT);
+
+   /* Polling on CFG1 register to confirm mode switch. */
+   while (!time_after(jiffies, timeout)) {
+   data = readl(mux->regs + INTEL_MUX_CFG1);
+   if (!(host ^ (data & CFG1_SW_MODE)))
+   return 0;
+   /* interval for polling is set to about 5ms */
+   usleep_range(5000, 5100);
+   }
+
+   return -ETIMEDOUT;
+}
+
+static int intel_mux_drcfg_cable_set(struct device *dev)
+{
+   dev_dbg(dev, "drcfg mux switch to HOST\n");
+
+   return intel_mux_drcfg_switch(dev, true);
+}
+
+static int intel_mux_drcfg_cable_unset(struct device *dev)
+{
+   dev_dbg(dev, "drcfg mux switch to DEVICE\n");
+
+   return intel_mux_drcfg_switch(dev, false);
+}
+
+static int intel_mux_drcfg_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   const char *extcon_name;
+   u64 

Re: [PATCH] uas: Limit qdepth at the scsi-host level

[Sergei Shtylyov]

Hello.

On 3/19/2016 11:59 AM, Hans de Goede wrote:


Commit 64d513ac31bd ("scsi: use host wide tags by default") causes
the scsi-core to queue more cmnds then we can handle on devices with


   SCSI core? Commands?


multiple LUNs, limit the qdepth at the scsi-host level instead of


   Queue depth?


per slave to fix this.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1315013
Cc: sta...@vger.kernel.org # 4.4.x and 4.5.x
Signed-off-by: Hans de Goede 
---
  drivers/usb/storage/uas.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index c90a7e4..b5cb7ab 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c

[...]

@@ -932,6 +931,12 @@ static int uas_probe(struct usb_interface *intf, const 
struct usb_device_id *id)
if (result)
goto set_alt0;

+   /*
+* 1 tag is reserved for untagged commands +
+* 1 tag to avoid of by one errors in some bridge firmwares


   Off by one.

[...]

MBR, Sergei

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

Re: [PATCH 1/2] usb: dwc3: core: Introduce dwc3_device_reinit()

[Felipe Balbi]

Hi,

Roger Quadros  writes:
> [ text/plain ]
> We will need this function for a workaround.
> The function issues a softreset only to the device
> controller and performs minimal re-initialization
> so that the device controller can be usable.
>
> As some code is similar to dwc3_core_init() take out
> common code into dwc3_get_gctl_quirks().
>
> We add a new member (prtcap_mode) to struct dwc3 to
> keep track of the current mode in the PRTCAPDIR register.
>
> Signed-off-by: Roger Quadros 

I must say, I don't like this at all :-p There's ONE known silicon which
needs this because of a poor silicon integration which took an IP with a
known erratum where it can't be made to work on lower speeds and STILL
was integrated without a superspeed PHY.

There's a reason why I never tried to push this upstream myself ;-)

I'm really thinking we might be better off adding a quirk flag to skip
the metastability workaround and allow this ONE silicon to set the
controller to lower speed.

John, can you check with your colleagues if we would ever fall into
STAR#9000525659 if we set maximum speed to high speed during driver
probe and never touch it again ? I would assume we don't really fall
into the metastability workaround, right ? We're not doing any sort of
PM for dwc3...

-- 
balbi


signature.asc
Description: PGP signature

[PATCH v2 07/11] ARM: davinci: da8xx: Add USB PHY platform declaration

[David Lechner]

There is now a proper phy driver for the DA8XX SoC USB PHY. This adds the
platform device declarations needed to use it.

Signed-off-by: David Lechner 
---

v2 changes: This is new patch in v2.


 arch/arm/mach-davinci/include/mach/da8xx.h |  1 +
 arch/arm/mach-davinci/usb.c| 24 +++-
 2 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h 
b/arch/arm/mach-davinci/include/mach/da8xx.h
index f9f9713..049d26f 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -88,6 +88,7 @@ int da850_register_edma(struct edma_rsv_info *rsv[2]);
 int da8xx_register_i2c(int instance, struct davinci_i2c_platform_data *pdata);
 int da8xx_register_spi_bus(int instance, unsigned num_chipselect);
 int da8xx_register_watchdog(void);
+int da8xx_register_usbphy(void);
 int da8xx_register_usb20(unsigned mA, unsigned potpgt);
 int da8xx_register_usb11(struct da8xx_ohci_root_hub *pdata);
 int da8xx_register_emac(void);
diff --git a/arch/arm/mach-davinci/usb.c b/arch/arm/mach-davinci/usb.c
index b0a6b52..6a0802e 100644
--- a/arch/arm/mach-davinci/usb.c
+++ b/arch/arm/mach-davinci/usb.c
@@ -4,7 +4,7 @@
 #include 
 #include 
 #include 
-
+#include 
 #include 
 
 #include 
@@ -18,6 +18,28 @@
 #define DA8XX_USB0_BASE0x01e0
 #define DA8XX_USB1_BASE0x01e25000
 
+#ifdef CONFIG_ARCH_DAVINCI_DA8XX
+static struct resource da8xx_usbphy_resources[] = {
+   [0] = {
+   .start  = DA8XX_SYSCFG0_BASE + DA8XX_CFGCHIP2_REG,
+   .end= DA8XX_SYSCFG0_BASE + DA8XX_CFGCHIP2_REG + 4 - 1,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static struct platform_device da8xx_usbphy = {
+   .name   = "da8xx-usbphy",
+   .id = 0,
+   .num_resources  = ARRAY_SIZE(da8xx_usbphy_resources),
+   .resource   = da8xx_usbphy_resources,
+};
+
+int __init da8xx_register_usbphy(void)
+{
+   return platform_device_register(_usbphy);
+}
+#endif /* CONFIG_ARCH_DAVINCI_DA8XX */
+
 #if IS_ENABLED(CONFIG_USB_MUSB_HDRC)
 static struct musb_hdrc_eps_bits musb_eps[] = {
{ "ep1_tx", 8, },
-- 
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 v10 6/9] dt-bindings: usb: Add NVIDIA Tegra XUSB controller binding

[Stephen Warren]

On 03/04/2016 09:19 AM, Thierry Reding wrote:

From: Thierry Reding 

Add device-tree binding documentation for the XUSB controller present
on Tegra124 and later SoCs. This controller supports USB 3.0 via an xHCI
compliant interface.

Based on work by Andrew Bresticker .



diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt 
b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt



+Required properties:



+- nvidia,xusb-padctl: phandle to the XUSB pad controller that is used to
+  configure the USB pads used by the XHCI controller


Is "global" access to the PADCTL DT node/driver required? I rather would 
have expected this binding to reference the port objects in the PADCTL 
node. Perhaps the intent is that drivers can use this property to go and 
read the port information directly from the PADCTL node and interpret it 
themselves without requiring the PADCTL driver to provide an interface 
for ports? I guess that would also explain why this binding references 
only PHYs and not ports:



+Optional properties:
+
+- phys: Must contain an entry for each entry in phy-names.
+  See ../phy/phy-bindings.txt for details.
+- phy-names: Should include an entry for each PHY used by the controller. The
+  following PHYs are available:
+  - Tegra124: usb2-0, usb2-1, usb2-2, hsic-0, hsic-1, usb3-0, usb3-1
+  - Tegra132: usb2-0, usb2-1, usb2-2, hsic-0, hsic-1, usb3-0, usb3-1


If that's how this works (which might be worth mentioning in the binding 
doc), then:

Acked-by: Stephen Warren 

--
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 v10 2/9] dt-bindings: pinctrl: Deprecate Tegra XUSB pad controller binding

[Stephen Warren]

On 03/04/2016 09:19 AM, Thierry Reding wrote:

From: Thierry Reding 

This is an old version of the binding that isn't flexible enough to
describe all aspects of the XUSB pad controller. Specifically with the
addition of XUSB support (for SuperSpeed USB) the existing binding is
no longer suitable.


Assuming the rest of the edits to this file in patch 1/9 get pulled into 
this patch, or perhaps this patch simply gets squashed into path 1/9, 
then this patch,


Acked-by: Stephen Warren 

--
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 3/7] usb: mux: add common code for Intel dual role port mux

[Lu Baolu]

Hi Chanwoo,

On 03/17/2016 02:07 PM, Chanwoo Choi wrote:
> Hi Lu,
>
> To handle extcon (external connector), I implemented the unique id
> for each external connector on patch[1] instead of using the ambiguous string 
> type. 
> [1] 2a9de9c0f08d6 (extcon: Use the unique id for external connector instead 
> of string)
>
> So I recommend that you should use the unique id (ex. EXTCON_USB, 
> EXTCON_USB_HOST)
> with extcon_register_notifier(), extcon_get_cable_state_() and 
> extcon_set_cable_state_().
>
> extcon_register_interest() is deprecated-> extcon_register_notifier()
> extcon_get_cable_state() is deprecated -> extcon_get_cable_state_()
> extcon_set_cable_state() is deprecated -> extcon_set_cable_state_()

Sure. I will use the new interfaces with a refreshed patch serial later.

>
>
> You can refer to usage for new function with unique id on patch[2]
> [2] 5960387a2fb83 (usb: dwc3: omap: Replace deprecated API of extcon)

Thanks. That's helpful.

By the way, is extcon_get_extcon_dev() still available?

>
> I'm sorry for late reply. I add the some comment on below.

Never mind. Thank you for reminding me.

Best regards,
Baolu

>
>
> On 2016년 03월 17일 14:46, Lu Baolu wrote:
>> Several Intel PCHs and SOCs have an internal mux that is used to
>> share one USB port between device controller and host controller.
>>
>> A usb port mux could be abstracted as the following elements:
>> 1) mux state: HOST or PERIPHERAL;
>> 2) an extcon cable which triggers the change of mux state between
>>HOST and PERIPHERAL;
>> 3) The required action to do the real port switch.
>>
>> This patch adds the common code to handle usb port mux. With this
>> common code, the individual mux driver, which always is platform
>> dependent, could focus on the real operation of mux switch.
>>
>> Signed-off-by: Lu Baolu 
>> Reviewed-by: Heikki Krogerus 
>> Reviewed-by: Felipe Balbi 
>> ---
>>  Documentation/ABI/testing/sysfs-bus-platform |  15 +++
>>  MAINTAINERS  |   7 ++
>>  drivers/usb/Kconfig  |   2 +
>>  drivers/usb/Makefile |   1 +
>>  drivers/usb/mux/Kconfig  |  12 ++
>>  drivers/usb/mux/Makefile |   4 +
>>  drivers/usb/mux/intel-mux.c  | 180 
>> +++
>>  include/linux/usb/intel-mux.h|  43 +++
>>  8 files changed, 264 insertions(+)
>>  create mode 100644 drivers/usb/mux/Kconfig
>>  create mode 100644 drivers/usb/mux/Makefile
>>  create mode 100644 drivers/usb/mux/intel-mux.c
>>  create mode 100644 include/linux/usb/intel-mux.h
>>
>> diff --git a/Documentation/ABI/testing/sysfs-bus-platform 
>> b/Documentation/ABI/testing/sysfs-bus-platform
>> index 5172a61..23bf76e 100644
>> --- a/Documentation/ABI/testing/sysfs-bus-platform
>> +++ b/Documentation/ABI/testing/sysfs-bus-platform
>> @@ -18,3 +18,18 @@ Description:
>>  devices to opt-out of driver binding using a driver_override
>>  name such as "none".  Only a single driver may be specified in
>>  the override, there is no support for parsing delimiters.
>> +
>> +What:   /sys/bus/platform/devices/.../port_mux
>> +Date:   Febuary 2016
>> +Contact:Lu Baolu 
>> +Description:
>> +In some platforms, a single USB port is shared between a USB 
>> host
>> +controller and a device controller. A USB mux driver is needed 
>> to
>> +handle the port mux. port_mux attribute shows and stores the mux
>> +state.
>> +For read:
>> +'peripheral' - mux switched to PERIPHERAL controller;
>> +'host'   - mux switched to HOST controller.
>> +For write:
>> +'peripheral' - mux will be switched to PERIPHERAL controller;
>> +'host'   - mux will be switched to HOST controller.
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index da3e4d8..0dbee11 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -11399,6 +11399,13 @@ T:  git 
>> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
>>  S:  Maintained
>>  F:  drivers/usb/phy/
>>  
>> +USB PORT MUX DRIVER
>> +M:  Lu Baolu 
>> +L:  linux-usb@vger.kernel.org
>> +S:  Supported
>> +F:  include/linux/usb/intel-mux.h
>> +F:  drivers/usb/mux/intel-mux.c
>> +
>>  USB PRINTER DRIVER (usblp)
>>  M:  Pete Zaitcev 
>>  L:  linux-usb@vger.kernel.org
>> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
>> index 8ed451d..dbd6620 100644
>> --- a/drivers/usb/Kconfig
>> +++ b/drivers/usb/Kconfig
>> @@ -149,6 +149,8 @@ endif # USB
>>  
>>  source "drivers/usb/phy/Kconfig"
>>  
>> +source "drivers/usb/mux/Kconfig"
>> +
>>  source "drivers/usb/gadget/Kconfig"
>>  
>>  config USB_LED_TRIG
>> diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
>> index 

Re: [RFC PATCH 1/4] usb: chipidea: Do not rely on OTG while using extcon

[Chanwoo Choi]

Hi Sanchayan,

I recommend that you use the unique id (ex. EXTCON_USB, EXTCON_USB_HOST)
when getting/setting the state of external connector with extcon functions
- extcon_get_cable_state() is deprecated -> extcon_get_cable_state_()
- extcon_set_cable_state() is deprecated -> extcon_set_cable_state_()

You can refer to usage for new function with unique id on patch[1]
[1] 5960387a2fb83 (usb: dwc3: omap: Replace deprecated API of extcon)

I'll remove the extcon_[get/set]_cable_state() functions using the string type
to identify the external connector.

On 2016년 03월 15일 17:38, Sanchayan Maity wrote:
> The existing usage of extcon in Chipidea driver relies on OTG
> registers. In case of SoC with dual role device but not a true
> OTG controller, this does not work. Such SoC's should specify
> the existing CI_HDRC_DUAL_ROLE_NOT_OTG flag and do the role
> switch without checking any of the OTG registers.
> 
> This patch almost reverts most of commit "usb: chipidea: Use
> extcon framework for VBUS and ID detect". We do not rely
> anymore on emulating an OTG capable controller by faking OTG
> controller reads.
> 
> Signed-off-by: Sanchayan Maity 
> ---
>  drivers/usb/chipidea/core.c  | 64 
> 
>  drivers/usb/chipidea/otg.c   | 39 +--
>  include/linux/usb/chipidea.h |  2 --
>  3 files changed, 36 insertions(+), 69 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 7404064..d29118d 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -607,14 +607,15 @@ static int ci_vbus_notifier(struct notifier_block *nb, 
> unsigned long event,
>   struct ci_hdrc_cable *vbus = container_of(nb, struct ci_hdrc_cable, nb);
>   struct ci_hdrc *ci = vbus->ci;
>  
> + pm_runtime_get_sync(ci->dev);
> +
>   if (event)
> - vbus->state = true;
> + usb_gadget_vbus_connect(>gadget);
>   else
> - vbus->state = false;
> + usb_gadget_vbus_disconnect(>gadget);
>  
> - vbus->changed = true;
> + pm_runtime_put_sync(ci->dev);
>  
> - ci_irq(ci->irq, ci);
>   return NOTIFY_DONE;
>  }
>  
> @@ -624,14 +625,19 @@ static int ci_id_notifier(struct notifier_block *nb, 
> unsigned long event,
>   struct ci_hdrc_cable *id = container_of(nb, struct ci_hdrc_cable, nb);
>   struct ci_hdrc *ci = id->ci;
>  
> - if (event)
> - id->state = false;
> - else
> - id->state = true;
> + pm_runtime_get_sync(ci->dev);
> +
> + ci_role_stop(ci);
> +
> + hw_wait_phy_stable();
> +
> + if (ci_role_start(ci, event ? CI_ROLE_HOST : CI_ROLE_GADGET))
> + dev_err(ci->dev,
> + "Can't start %s role\n",
> + event ? "host" : "gadget");
>  
> - id->changed = true;
> + pm_runtime_put_sync(ci->dev);
>  
> - ci_irq(ci->irq, ci);
>   return NOTIFY_DONE;
>  }
>  
> @@ -738,25 +744,10 @@ static int ci_get_platdata(struct device *dev,
>   cable->nb.notifier_call = ci_vbus_notifier;
>   cable->edev = ext_vbus;
>  
> - if (!IS_ERR(ext_vbus)) {
> - ret = extcon_get_cable_state_(cable->edev, EXTCON_USB);
> - if (ret)
> - cable->state = true;
> - else
> - cable->state = false;
> - }
> -
>   cable = >id_extcon;
>   cable->nb.notifier_call = ci_id_notifier;
>   cable->edev = ext_id;
>  
> - if (!IS_ERR(ext_id)) {
> - ret = extcon_get_cable_state_(cable->edev, EXTCON_USB_HOST);
> - if (ret)
> - cable->state = false;
> - else
> - cable->state = true;
> - }
>   return 0;
>  }
>  
> @@ -896,6 +887,7 @@ static int ci_hdrc_probe(struct platform_device *pdev)
>   void __iomem*base;
>   int ret;
>   enum usb_dr_mode dr_mode;
> + struct ci_hdrc_cable *cable;
>  
>   if (!dev_get_platdata(dev)) {
>   dev_err(dev, "platform data missing\n");
> @@ -963,6 +955,12 @@ static int ci_hdrc_probe(struct platform_device *pdev)
>  
>   ci_get_otg_capable(ci);
>  
> + ret = ci_extcon_register(ci);
> + if (ret) {
> + dev_err(dev, "extcon registration failed\n");
> + goto deinit_phy;
> + }
> +
>   dr_mode = ci->platdata->dr_mode;
>   /* initialize role(s) before the interrupt is requested */
>   if (dr_mode == USB_DR_MODE_OTG || dr_mode == USB_DR_MODE_HOST) {
> @@ -1003,6 +1001,12 @@ static int ci_hdrc_probe(struct platform_device *pdev)
>* user can switch it through debugfs.
>*/
>   ci->role = CI_ROLE_GADGET;
> + cable = >platdata->id_extcon;
> + if (!IS_ERR(cable->edev)) {
> + if (extcon_get_cable_state(cable->edev,

Use 

Re: [PATCH v4 3/7] usb: mux: add common code for Intel dual role port mux

[Chanwoo Choi]

Hi Lu,

To handle extcon (external connector), I implemented the unique id
for each external connector on patch[1] instead of using the ambiguous string 
type. 
[1] 2a9de9c0f08d6 (extcon: Use the unique id for external connector instead of 
string)

So I recommend that you should use the unique id (ex. EXTCON_USB, 
EXTCON_USB_HOST)
with extcon_register_notifier(), extcon_get_cable_state_() and 
extcon_set_cable_state_().

extcon_register_interest() is deprecated-> extcon_register_notifier()
extcon_get_cable_state() is deprecated -> extcon_get_cable_state_()
extcon_set_cable_state() is deprecated -> extcon_set_cable_state_()


You can refer to usage for new function with unique id on patch[2]
[2] 5960387a2fb83 (usb: dwc3: omap: Replace deprecated API of extcon)

I'm sorry for late reply. I add the some comment on below.


On 2016년 03월 17일 14:46, Lu Baolu wrote:
> Several Intel PCHs and SOCs have an internal mux that is used to
> share one USB port between device controller and host controller.
> 
> A usb port mux could be abstracted as the following elements:
> 1) mux state: HOST or PERIPHERAL;
> 2) an extcon cable which triggers the change of mux state between
>HOST and PERIPHERAL;
> 3) The required action to do the real port switch.
> 
> This patch adds the common code to handle usb port mux. With this
> common code, the individual mux driver, which always is platform
> dependent, could focus on the real operation of mux switch.
> 
> Signed-off-by: Lu Baolu 
> Reviewed-by: Heikki Krogerus 
> Reviewed-by: Felipe Balbi 
> ---
>  Documentation/ABI/testing/sysfs-bus-platform |  15 +++
>  MAINTAINERS  |   7 ++
>  drivers/usb/Kconfig  |   2 +
>  drivers/usb/Makefile |   1 +
>  drivers/usb/mux/Kconfig  |  12 ++
>  drivers/usb/mux/Makefile |   4 +
>  drivers/usb/mux/intel-mux.c  | 180 
> +++
>  include/linux/usb/intel-mux.h|  43 +++
>  8 files changed, 264 insertions(+)
>  create mode 100644 drivers/usb/mux/Kconfig
>  create mode 100644 drivers/usb/mux/Makefile
>  create mode 100644 drivers/usb/mux/intel-mux.c
>  create mode 100644 include/linux/usb/intel-mux.h
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-platform 
> b/Documentation/ABI/testing/sysfs-bus-platform
> index 5172a61..23bf76e 100644
> --- a/Documentation/ABI/testing/sysfs-bus-platform
> +++ b/Documentation/ABI/testing/sysfs-bus-platform
> @@ -18,3 +18,18 @@ Description:
>   devices to opt-out of driver binding using a driver_override
>   name such as "none".  Only a single driver may be specified in
>   the override, there is no support for parsing delimiters.
> +
> +What:/sys/bus/platform/devices/.../port_mux
> +Date:Febuary 2016
> +Contact: Lu Baolu 
> +Description:
> + In some platforms, a single USB port is shared between a USB 
> host
> + controller and a device controller. A USB mux driver is needed 
> to
> + handle the port mux. port_mux attribute shows and stores the mux
> + state.
> + For read:
> + 'peripheral' - mux switched to PERIPHERAL controller;
> + 'host'   - mux switched to HOST controller.
> + For write:
> + 'peripheral' - mux will be switched to PERIPHERAL controller;
> + 'host'   - mux will be switched to HOST controller.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index da3e4d8..0dbee11 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11399,6 +11399,13 @@ T:   git 
> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
>  S:   Maintained
>  F:   drivers/usb/phy/
>  
> +USB PORT MUX DRIVER
> +M:   Lu Baolu 
> +L:   linux-usb@vger.kernel.org
> +S:   Supported
> +F:   include/linux/usb/intel-mux.h
> +F:   drivers/usb/mux/intel-mux.c
> +
>  USB PRINTER DRIVER (usblp)
>  M:   Pete Zaitcev 
>  L:   linux-usb@vger.kernel.org
> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
> index 8ed451d..dbd6620 100644
> --- a/drivers/usb/Kconfig
> +++ b/drivers/usb/Kconfig
> @@ -149,6 +149,8 @@ endif # USB
>  
>  source "drivers/usb/phy/Kconfig"
>  
> +source "drivers/usb/mux/Kconfig"
> +
>  source "drivers/usb/gadget/Kconfig"
>  
>  config USB_LED_TRIG
> diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
> index d5c57f1..6433f0c 100644
> --- a/drivers/usb/Makefile
> +++ b/drivers/usb/Makefile
> @@ -6,6 +6,7 @@
>  
>  obj-$(CONFIG_USB)+= core/
>  obj-$(CONFIG_USB_SUPPORT)+= phy/
> +obj-$(CONFIG_USB_SUPPORT)+= mux/
>  
>  obj-$(CONFIG_USB_DWC3)   += dwc3/
>  obj-$(CONFIG_USB_DWC2)   += dwc2/
> diff --git a/drivers/usb/mux/Kconfig 

[PATCH v5 1/6] extcon: usb-gpio: add device binding for platform device

[Lu Baolu]

This is needed to handle the GPIO connected USB ID pin found on
Intel Baytrail devices.

Signed-off-by: Lu Baolu 
Reviewed-by: Felipe Balbi 
Acked-by: Chanwoo Choi 
---
 drivers/extcon/extcon-usb-gpio.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/extcon/extcon-usb-gpio.c b/drivers/extcon/extcon-usb-gpio.c
index 2b2fecf..af9c8b0 100644
--- a/drivers/extcon/extcon-usb-gpio.c
+++ b/drivers/extcon/extcon-usb-gpio.c
@@ -206,6 +206,12 @@ static const struct of_device_id usb_extcon_dt_match[] = {
 };
 MODULE_DEVICE_TABLE(of, usb_extcon_dt_match);
 
+static const struct platform_device_id usb_extcon_platform_ids[] = {
+   { .name = "extcon-usb-gpio", },
+   { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(platform, usb_extcon_platform_ids);
+
 static struct platform_driver usb_extcon_driver = {
.probe  = usb_extcon_probe,
.remove = usb_extcon_remove,
@@ -214,6 +220,7 @@ static struct platform_driver usb_extcon_driver = {
.pm = _extcon_pm_ops,
.of_match_table = usb_extcon_dt_match,
},
+   .id_table = usb_extcon_platform_ids,
 };
 
 module_platform_driver(usb_extcon_driver);
-- 
2.1.4

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

[PATCH 2/5] usb: dwc3: core: define macros for newest revisions

[Roger Quadros]

From: Felipe Balbi 

dwc3 has released two other versions (2.90a and 3.00a),
this patch just adds revision macros.

Signed-off-by: Felipe Balbi 
Signed-off-by: Sekhar Nori 
Signed-off-by: Roger Quadros 
---
 drivers/usb/dwc3/core.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 6254b2f..640ecde 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -812,6 +812,8 @@ struct dwc3 {
 #define DWC3_REVISION_260A 0x5533260a
 #define DWC3_REVISION_270A 0x5533270a
 #define DWC3_REVISION_280A 0x5533280a
+#define DWC3_REVISION_290A 0x5533290a
+#define DWC3_REVISION_300A 0x5533300a
 
 /*
  * NOTICE: we're using bit 31 as a "is usb 3.1" flag. This is really
-- 
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

Re: [PATCH] cypress_m8: add sanity checking

[Johan Hovold]

On Thu, Mar 17, 2016 at 11:07:31AM +0100, Oliver Neukum wrote:
> An attack using missing endpoints exists.
> CVE-2016-3137
> 
> Signed-off-by: Oliver Neukum 
> CC: sta...@vger.kernel.org
> ---
>  drivers/usb/serial/cypress_m8.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/usb/serial/cypress_m8.c b/drivers/usb/serial/cypress_m8.c
> index 01bf533..8eeff72 100644
> --- a/drivers/usb/serial/cypress_m8.c
> +++ b/drivers/usb/serial/cypress_m8.c
> @@ -447,6 +447,12 @@ static int cypress_generic_port_probe(struct 
> usb_serial_port *port)
>   struct usb_serial *serial = port->serial;
>   struct cypress_private *priv;
>  
> + if (!port->interrupt_out_urb || !port->interrupt_in_urb) {
> + dev_err(>dev,
> + "cypress_m8 is missing a required endpoint");

Trailing '\n' missing.

No need to include the driver name here, it will be added by dev_err.

Also please include a patch revision in the summary when resending (and
a changelog below the cut-off line).

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

[PATCH 0/5] usb: dwc3: xhci: Add quirk for defective Port Enable/disable

[Roger Quadros]

Hi,

Some devices from Texas Instruments suffer from
a silicon bug where XHCI Port Enabled/Disabled bit
should not be used to silence an erroneous device.

The bug is so that if port is disabled with PED
bit, an IRQ for device removal (or attachment)
will never fire.

Just for the sake of completeness, the actual
problem lies with SNPS DWC3 USB IP and this affects
all known versions up to 3.00a

We add a BROKEN_PE quirk in xhci.h to deal with this issue
and add a corresponding bit in xhci platform_data.

I've only updated Felipe's e-mail id in the patches
and re-based them to v4.5 + balbi/next.

--
cheers,
-roger

Felipe Balbi (5):
  usb: xhci: add quirk flag for broken PED bits
  usb: dwc3: core: define macros for newest revisions
  usb: host: xhci: add broken pe quirk flag to pdata
  usb: host: xhci-plat: enable BROKEN_PE quirk if platform requested
  usb: dwc3: host: pass BROKEN_PE flag for known broken revisions

 drivers/usb/dwc3/core.h  |  2 ++
 drivers/usb/dwc3/host.c  | 12 
 drivers/usb/host/xhci-hub.c  |  6 ++
 drivers/usb/host/xhci-plat.c |  3 +++
 drivers/usb/host/xhci.h  |  2 ++
 include/linux/usb/xhci_pdriver.h |  2 ++
 6 files changed, 27 insertions(+)

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

Re: [PATCH 3/5] ARM: davinci: da8xx: add cfgchip2 to resources

[Sergei Shtylyov]

Hello.

On 3/16/2016 6:46 AM, David Lechner wrote:


No, this register is shared b/w MUSB and OHCI. The proper thing to
do is to write the PHY driver and let it control this shared register.



OK. I've started working on this. I am looking at using struct usb_phy,
however, enum usb_phy_type only has USB_PHY_TYPE_UNDEFINED, USB_PHY_TYPE_USB2,
and USB_PHY_TYPE_USB3. Would it be acceptable to use USB_PHY_TYPE_UNDEFINED
for the ohci since it is USB 1.1? Or perhaps I should use the more generic
struct phy for that one?


   No new USB PHY drivers accepted, look at drivers/phy/ instead please.

MBR, Sergei

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

Re: PROBLEM: Osprey 2 Mini sometimes resets every 200ms forever

[Alan Stern]

On Wed, 16 Mar 2016, ais523 wrote:

> One line summary of the problem:
> Connecting an Osprey 2 Mini sometimes causes it to reset every 200ms
> 
> Full description of the problem/report:
> This report is about a hardware compatibility issue related to the
> Osprey 2 Mini, a cellular router that can connect to a computer either
> wirelessly or via USB. I am running Linux 4.5.0-040500, turning the
> device on, then connecting it to the computer via the USB port (it is
> typically also connected to the computer via wifi). When I do this,
> there is around a 20-30% chance that the device is repeatedly reset
> approximately every 200 milliseconds (which is visible on the device as
> one of the LEDs on the device flashes when it resets); on occasion this
> loop (when it happens) ends naturally, either almost immediately or
> after several seconds, but normally, if a loop starts, it continues
> until I disconnect or switch off the device. Similar results are seen
> if I connect the device and then turn it on, although I have tested
> this situation less extensively. The resets seem to be most likely to
> happen on the first attempt I make to connect the device, and to be
> more likely to happen after a disconnection if they happened
> beforehand, but I am not confident that either pattern is anything
> other than chance/confirmation bias.
> 
> While a reset loop is occurring, the line
> 
> usb 1-1.2: reset high-speed USB device number # using ehci-pci
> 
> (where # is a number that stays constant in any given reset loop, but
> becomes higher if I disconnect and reconnect the device) occurs
> repeatedly in the kernel log, at the same intervals as the device
> resetting. Additionally, my userspace desktop environment sometimes
> acts as though I had connected a CD drive containing a (corrupted)
> audio CD.

Please post a usbmon trace showing what happens when you plug in the 
device.  (See Documentation/usb/usbmon.txt for instructions).

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] usb/core: usb_alloc_dev(): fix setting of ->portnum

[Nicolai Stange]

With commit 69bec7259853 ("USB: core: let USB device know device node"),
the port1 argument of usb_alloc_dev() gets overwritten as follows:

  ... usb_alloc_dev(..., unsigned port1)
  {
...
if (!parent->parent) {
  port1 = usb_hcd_find_raw_port_number(..., port1);
}
...
  }

Later on, this now overwritten port1 gets assigned to ->portnum:

  dev->portnum = port1;

However, since xhci_find_raw_port_number() isn't idempotent, the
aforementioned commit causes a number of KASAN splats like the following:

  BUG: KASAN: slab-out-of-bounds in xhci_find_raw_port_number+0x98/0x170
   at addr 8801d9311670
  Read of size 8 by task kworker/2:1/87
  [...]
  Workqueue: usb_hub_wq hub_event
   0188 5814b877 8800cba17588 8191447e
   41b58ab3 82a03209 819143a2 82a252f4
   8801d93115e0 0188 8801d9311628 8800cba17588
  Call Trace:
   [] dump_stack+0xdc/0x15e
   [] ? _atomic_dec_and_lock+0xa2/0xa2
   [] ? print_section+0x61/0xb0
   [] print_trailer+0x179/0x2c0
   [] object_err+0x34/0x40
   [] kasan_report_error+0x2f8/0x8b0
   [] ? __slab_alloc+0x5e/0x90
   [] ? __lock_is_held+0x90/0x130
   [] kasan_report+0x71/0xa0
   [] ? kmem_cache_alloc_trace+0x212/0x560
   [] ? xhci_find_raw_port_number+0x98/0x170
   [] __asan_load8+0x64/0x70
   [] xhci_find_raw_port_number+0x98/0x170
   [] xhci_setup_addressable_virt_dev+0x235/0xa10
   [] xhci_setup_device+0x3c1/0x1430
   [] ? trace_hardirqs_on+0xd/0x10
   [] ? xhci_setup_device+0x1430/0x1430
   [] xhci_address_device+0x13/0x20
   [] hub_port_init+0x55a/0x1550
   [] hub_event+0xef5/0x24d0
   [] ? hub_port_debounce+0x2f0/0x2f0
   [] ? debug_object_deactivate+0x1be/0x270
   [] ? print_rt_rq+0x53/0x2d0
   [] ? trace_hardirqs_off+0xd/0x10
   [] ? _raw_spin_unlock_irqrestore+0x5b/0x60
   [] ? irq_domain_set_hwirq_and_chip+0x30/0xb0
   [] ? debug_lockdep_rcu_enabled+0x39/0x40
   [] ? __lock_is_held+0x90/0x130
   [] process_one_work+0x567/0xec0
  [...]

Afterwards, xhci reports some functional errors:

  xhci_hcd :00:14.0: ERROR: unexpected setup address command completion
code 0x11.
  xhci_hcd :00:14.0: ERROR: unexpected setup address command completion
code 0x11.
  usb 4-3: device not accepting address 2, error -22

Fix this by not overwriting the port1 argument in usb_alloc_dev(), but
storing the raw port number as required by OF in an additional variable,
raw_port.

Fixes: 69bec7259853 ("USB: core: let USB device know device node")
Signed-off-by: Nicolai Stange 
---
 Applicable to linux-next-20160317

 Changes to v1:
 - Initialize raw_port with port1

 drivers/usb/core/usb.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
index ffa5cf1..dcb85e3 100644
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -424,6 +424,7 @@ struct usb_device *usb_alloc_dev(struct usb_device *parent,
struct usb_device *dev;
struct usb_hcd *usb_hcd = bus_to_hcd(bus);
unsigned root_hub = 0;
+   unsigned raw_port = port1;
 
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
if (!dev)
@@ -498,11 +499,11 @@ struct usb_device *usb_alloc_dev(struct usb_device 
*parent,
 
if (!parent->parent) {
/* device under root hub's port */
-   port1 = usb_hcd_find_raw_port_number(usb_hcd,
+   raw_port = usb_hcd_find_raw_port_number(usb_hcd,
port1);
}
dev->dev.of_node = usb_of_get_child_node(parent->dev.of_node,
-   port1);
+   raw_port);
 
/* hub driver sets up TT records */
}
-- 
2.7.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 4/5] usb: ohci-da8xx: Remove clock code that references mach

[David Lechner]

On 03/16/2016 09:50 AM, Alan Stern wrote:


Is it theoretically impossible for a da8xx platform to have more than
one OHCI controller?

If it isn't, you better not use static variables to hold per-device
data.


Yes, it is theoretically impossible, but probably better to not use 
static variables anyway.


--
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: chipidea: Configure DMA properties and ops from DT

[Arnd Bergmann]

On Monday 14 March 2016 18:51:08 Peter Chen wrote:
> On Wed, Mar 09, 2016 at 05:16:50PM -0600, Li Yang wrote:
> > On Tue, Mar 8, 2016 at 9:40 PM, Bjorn Andersson
> >  wrote:
> > > On Tue, Mar 8, 2016 at 11:52 AM, Li Yang  wrote:
> > >> On Wed, Mar 2, 2016 at 4:59 PM, Li Yang  wrote:
> > >>> On Mon, Feb 22, 2016 at 4:07 PM, Bjorn Andersson
> > >>>  wrote:
> >  On Mon 22 Feb 02:03 PST 2016, Srinivas Kandagatla wrote:
> > >
> > > I had the chance to go through this with Arnd and the verdict is that
> > > devices not described in DT should not do DMA (or allocate buffers for
> > > doing DMA).
> > >
> > > So I believe the solution is to fall back on Peter's description; the
> > > chipidea driver is the core driver and the Qualcomm code should just
> > > be a platform layer.
> > >
> > > My suggestion is that we turn the chipidea core into a set of APIs
> > > that can called by the platform specific pieces. That way we will have
> > > the chipidea core be the device described in the DT.
> > 
> > But like I said, this problem is not just existing for chipidea
> > driver.  We already found that the dwc3 driver is also suffering from
> > the same issue.  I don't know how many other drivers are impacted by
> > this change, but I suspect there will be some. A grep of
> > platform_device_add() in driver/ directory returns many possible
> > drivers to be impacted.  As far as I know, the
> > drivers/net/ethernet/freescale/fman/mac.c is registering child
> > ethernet devices that definitely will do dma.   If you want to do this
> > kind of rework to all these drivers, it will be a really big effort.
> > 
> 
> +1
> 
> Yes, I think this DMA things should be covered by driver core too.
> 

I don't think it's a very widespread problem, there are only very few
developers that intentionally use this method, and some use the
platform_device_register_full() call to create a device with a known
mask, which is generally ok for the limited case where the driver
is only ever going to run on a single platform, but not in the
more general case that of_dma_configure is designed to handle.

I think we should fix the drivers to consistently use the device
that was created by the platform (DT or ACPI or board file)
to pass that into the DMA API, anything else will just cause
more subtle bugs.

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

Re: [PATCH 2/2] usb: dwc3: gadget: usb: dwc3: run/stop metastability workaround

[Roger Quadros]

On 16/03/16 15:14, Felipe Balbi wrote:
> Roger Quadros  writes:
> 
>> [ text/plain ]
>> The existing workaround of forcing DEVSPD to SUPER_SPEED
>> for HIGH_SPEED ports is causing another side effect
>> which causes erratic interrupts and delayed gadget
>> enumeration of upto 2 seconds.
>>
>> Work around the run/stop issue by detecting if
>> it happened using debug LTSSM state and issuing
>> soft reset to the device controller when changing RUN_STOP
>> from 0 to 1.
>>
>> We apply the workaround only if PRTCAP is DEVICE mode
>> as we don't yet support this workaround in OTG mode.
>>
>> Use USB RESET event as exit condition for workaround.
>>
>> Signed-off-by: Roger Quadros 
>> ---
>>  drivers/usb/dwc3/core.h   |   1 +
>>  drivers/usb/dwc3/gadget.c | 175 
>> +-
>>  2 files changed, 144 insertions(+), 32 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
>> index 2bea1ac..a724c0d 100644
>> --- a/drivers/usb/dwc3/core.h
>> +++ b/drivers/usb/dwc3/core.h
>> @@ -762,6 +762,7 @@ struct dwc3 {
>>  
>>  struct usb_gadget   gadget;
>>  struct usb_gadget_driver *gadget_driver;
>> +struct completion   reset_event; /* used for run/stop workaround */
> 
> the fact that you needed a struct completion here already points to the
> fact this is really, really bad :-)
> 
>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>> index 3ac170f..03418b8 100644
>> --- a/drivers/usb/dwc3/gadget.c
>> +++ b/drivers/usb/dwc3/gadget.c
>> @@ -35,6 +35,9 @@
>>  #include "gadget.h"
>>  #include "io.h"
>>  
>> +static void dwc3_gadget_disable_irq(struct dwc3 *dwc);
>> +static int dwc3_gadget_restart(struct dwc3 *dwc);
>> +
>>  /**
>>   * dwc3_gadget_set_test_mode - Enables USB2 Test Modes
>>   * @dwc: pointer to our context structure
>> @@ -1570,13 +1573,100 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, 
>> int is_on)
>>  struct dwc3 *dwc = gadget_to_dwc(g);
>>  unsigned long   flags;
>>  int ret;
>> +int trys = 0;
>>  
>>  is_on = !!is_on;
>>  
>> +if (is_on)
>> +reinit_completion(>reset_event);
>> +
>>  spin_lock_irqsave(>lock, flags);
>>  ret = dwc3_gadget_run_stop(dwc, is_on, false);
>>  spin_unlock_irqrestore(>lock, flags);
>>  
>> +try:
>> +/**
>> + * WORKAROUND: DWC3 revision < 2.20a have an issue
>> + * which would cause metastability state on Run/Stop
>> + * bit if we try to force the IP to USB2-only mode.
>> + *
>> + * Because of that, we check if we hit that issue and
>> + * reset core and retry if we did.
>> + *
>> + * We only attempt this workaround if we are in
>> + * DEVICE mode (i.e. not OTG).
>> + *
>> + * Refers to:
>> + *
>> + * STAR#9000525659: Clock Domain Crossing on DCTL in
>> + * USB 2.0 Mode
>> + */
>> +if (is_on && dwc->revision < DWC3_REVISION_220A &&
>> +dwc->prtcap_mode == DWC3_GCTL_PRTCAP_DEVICE) {
>> +u32 devspd, ltssm;
>> +unsigned long t;
>> +
>> +/* only applicable if devspd != SUPERSPEED */
>> +devspd = dwc3_readl(dwc->regs, DWC3_DCFG) & 
>> DWC3_DCFG_SPEED_MASK;
>> +if (devspd == DWC3_DCFG_SUPERSPEED)
>> +goto done;
>> +
>> +/* get link state */
>> +ltssm = dwc3_readl(dwc->regs, DWC3_GDBGLTSSM);
>> +ltssm = (ltssm >> 22) & 0xf;
>> +
>> +/**
>> + * Need to wait for 100ms and check if ltssm != 4 to detect
>> + * metastability issue. If we got a reset event then we are
>> + * safe and can continue.
>> + */
>> +t = wait_for_completion_timeout(>reset_event,
>> +msecs_to_jiffies(100));
>> +if (t)
>> +goto done;
>> +
>> +/**
>> + * If link state != 4 we've hit the metastability issue, soft 
>> reset.
>> + */
>> +if (ltssm == 4)
>> +goto done;
>> +
>> +dwc3_trace(trace_dwc3_gadget,
>> +   "applying metastability workaround\n");
>> +trys++;
>> +if (trys == 2) {
>> +dev_WARN_ONCE(dwc->dev, true,
>> +  "metastability workaround failed!\n");
>> +return -ETIMEDOUT;
>> +}
>> +
>> +spin_lock_irqsave(>lock, flags);
>> +/* stop gadget */
>> +dwc3_gadget_disable_irq(dwc);
>> +__dwc3_gadget_ep_disable(dwc->eps[0]);
>> +__dwc3_gadget_ep_disable(dwc->eps[1]);
>> +
>> +/* soft reset device and restart */
>> +ret = dwc3_device_reinit(dwc);
>> +if (ret) {
>> +dev_err(dwc->dev, "device reinit failed\n");
>> +

[PATCH] usb/core: usb_alloc_dev(): fix setting of ->portnum

[Nicolai Stange]

With commit 69bec7259853 ("USB: core: let USB device know device node"),
the port1 argument of usb_alloc_dev() gets overwritten as follows:

  ... usb_alloc_dev(..., unsigned port1)
  {
...
if (!parent->parent) {
  port1 = usb_hcd_find_raw_port_number(..., port1);
}
...
  }

Later on, this now overwritten port1 gets assigned to ->portnum:

  dev->portnum = port1;

However, since xhci_find_raw_port_number() isn't idempotent, the
aforementioned commit causes a number of KASAN splats like the following:

  BUG: KASAN: slab-out-of-bounds in xhci_find_raw_port_number+0x98/0x170
   at addr 8801d9311670
  Read of size 8 by task kworker/2:1/87
  [...]
  Workqueue: usb_hub_wq hub_event
   0188 5814b877 8800cba17588 8191447e
   41b58ab3 82a03209 819143a2 82a252f4
   8801d93115e0 0188 8801d9311628 8800cba17588
  Call Trace:
   [] dump_stack+0xdc/0x15e
   [] ? _atomic_dec_and_lock+0xa2/0xa2
   [] ? print_section+0x61/0xb0
   [] print_trailer+0x179/0x2c0
   [] object_err+0x34/0x40
   [] kasan_report_error+0x2f8/0x8b0
   [] ? __slab_alloc+0x5e/0x90
   [] ? __lock_is_held+0x90/0x130
   [] kasan_report+0x71/0xa0
   [] ? kmem_cache_alloc_trace+0x212/0x560
   [] ? xhci_find_raw_port_number+0x98/0x170
   [] __asan_load8+0x64/0x70
   [] xhci_find_raw_port_number+0x98/0x170
   [] xhci_setup_addressable_virt_dev+0x235/0xa10
   [] xhci_setup_device+0x3c1/0x1430
   [] ? trace_hardirqs_on+0xd/0x10
   [] ? xhci_setup_device+0x1430/0x1430
   [] xhci_address_device+0x13/0x20
   [] hub_port_init+0x55a/0x1550
   [] hub_event+0xef5/0x24d0
   [] ? hub_port_debounce+0x2f0/0x2f0
   [] ? debug_object_deactivate+0x1be/0x270
   [] ? print_rt_rq+0x53/0x2d0
   [] ? trace_hardirqs_off+0xd/0x10
   [] ? _raw_spin_unlock_irqrestore+0x5b/0x60
   [] ? irq_domain_set_hwirq_and_chip+0x30/0xb0
   [] ? debug_lockdep_rcu_enabled+0x39/0x40
   [] ? __lock_is_held+0x90/0x130
   [] process_one_work+0x567/0xec0
  [...]

Afterwards, xhci reports some functional errors:

  xhci_hcd :00:14.0: ERROR: unexpected setup address command completion
code 0x11.
  xhci_hcd :00:14.0: ERROR: unexpected setup address command completion
code 0x11.
  usb 4-3: device not accepting address 2, error -22

Fix this by not overwriting the port1 argument in usb_alloc_dev(), but
storing the raw port number as required by OF in an additional variable,
raw_port.

Fixes: 69bec7259853 ("USB: core: let USB device know device node")
Signed-off-by: Nicolai Stange 
---
 Applicable to linux-next-20160317

 drivers/usb/core/usb.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
index ffa5cf1..6b4fc16 100644
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -424,6 +424,7 @@ struct usb_device *usb_alloc_dev(struct usb_device *parent,
struct usb_device *dev;
struct usb_hcd *usb_hcd = bus_to_hcd(bus);
unsigned root_hub = 0;
+   unsigned raw_port;
 
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
if (!dev)
@@ -498,11 +499,11 @@ struct usb_device *usb_alloc_dev(struct usb_device 
*parent,
 
if (!parent->parent) {
/* device under root hub's port */
-   port1 = usb_hcd_find_raw_port_number(usb_hcd,
+   raw_port = usb_hcd_find_raw_port_number(usb_hcd,
port1);
}
dev->dev.of_node = usb_of_get_child_node(parent->dev.of_node,
-   port1);
+   raw_port);
 
/* hub driver sets up TT records */
}
-- 
2.7.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 2/5] ARM: davinci: da8xx: add usb phy clocks

[David Lechner]

On 03/16/2016 07:27 AM, Sergei Shtylyov wrote:


+static struct clk usb20_clk = {
+.name= "usb20",
+.parent= _sysclk2,
+.lpsc= DA8XX_LPSC1_USB20,
+.gpsc= 1,
+};


Why move it?


For organization, to keep all of the USB clocks together. I can leave it 
alone if that is preferred.



+
+/* Set the mux depending on the parent clock. */
+if (clk->parent == _aux_clk)
+val |= CFGCHIP2_USB2PHYCLKMUX;
+else if (clk->parent == _ref_clk)
+val &= ~CFGCHIP2_USB2PHYCLKMUX;


Don't we have clk_set_parent()for that?


Yes. clk_set_parent() is already called in a loop for all clocks 
elsewhere, so not needed here.


---

Thank you for the careful review. I will address the other problems you 
pointed out.


--
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 09/11] usb: ohci-da8xx: Remove code that references mach

[Alan Stern]

On Wed, 16 Mar 2016, David Lechner wrote:

> Including mach/* is frowned upon in device drivers, so get rid of it.
> 
> This replaces usb20_clk and code that pokes CFGCHIP2 with a proper phy
> driver.
> 
> Signed-off-by: David Lechner 
> ---
> 
> v2 changes: Uses the new phy driver instead of using a second clock.

Acked-by: 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: ehci and ohci reset number doubt

[gre...@linuxfoundation.org]

On Thu, Mar 17, 2016 at 02:16:56AM +, Lipengcheng wrote:
>  
> 
> Hi,



Please resend in non-html format so that the mailing list does not
reject your messages.

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

[PATCH v3] cypress_m8: add sanity checking

[Oliver Neukum]

An attack using missing endpoints exists.
CVE-2016-3137

Signed-off-by: Oliver Neukum 
CC: sta...@vger.kernel.org

v1 - add sanity check
v2 - add error logging
v3 - correct error message
---
 drivers/usb/serial/cypress_m8.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/serial/cypress_m8.c b/drivers/usb/serial/cypress_m8.c
index 01bf533..5e25443 100644
--- a/drivers/usb/serial/cypress_m8.c
+++ b/drivers/usb/serial/cypress_m8.c
@@ -447,6 +447,11 @@ static int cypress_generic_port_probe(struct 
usb_serial_port *port)
struct usb_serial *serial = port->serial;
struct cypress_private *priv;
 
+   if (!port->interrupt_out_urb || !port->interrupt_in_urb) {
+   dev_err(>dev, "A required endpoint is missing\n");
+   return -ENODEV;
+   }
+
priv = kzalloc(sizeof(struct cypress_private), GFP_KERNEL);
if (!priv)
return -ENOMEM;
@@ -606,12 +611,6 @@ static int cypress_open(struct tty_struct *tty, struct 
usb_serial_port *port)
cypress_set_termios(tty, port, >tmp_termios);
 
/* setup the port and start reading from the device */
-   if (!port->interrupt_in_urb) {
-   dev_err(>dev, "%s - interrupt_in_urb is empty!\n",
-   __func__);
-   return -1;
-   }
-
usb_fill_int_urb(port->interrupt_in_urb, serial->dev,
usb_rcvintpipe(serial->dev, port->interrupt_in_endpointAddress),
port->interrupt_in_urb->transfer_buffer,
-- 
2.1.4

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

Re: [RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on bcm2835"

[Stefan Wahren]

Hi,

> Martin Sperl  hat am 19. März 2016 um 11:10
> geschrieben:
>
>
> > On 19.03.2016, at 10:52, Stefan Wahren  wrote:
> >
> > Hi,
> >
> >> Martin Sperl  hat am 19. März 2016 um 08:44
> >> geschrieben:
> >>
> >>
> >>
> >>> On 19.03.2016, at 03:17, Eric Anholt  wrote:
> >>>
> >>> Stefan Wahren  writes:
> >>>
>  Hi Eric,
>  hi Martin,
> 
> > John Youn  hat am 16. März 2016 um 19:28
> > geschrieben:
> >
> >
> > On 3/10/2016 11:14 AM, John Youn wrote:
> >> On 3/9/2016 11:06 AM, Doug Anderson wrote:
> >>>
> >>> John: it's pretty clear that there's something taking almost exactly
> >>> 10ms on my system and almost exactly 50ms on Stefan's system. Is
> >>> there some register we could poll to see when this process is done?
> >>> ...or can we look at the dwc2 revision number / feature register and
> >>> detect how long to delay?
> >>>
> >>
> >> Maybe this difference is related to overclocking settings in the firmware?
> >>
> >
> > 1. What is the AHB Clock frequency? Is the AHB Clock gated during
> > Reset?
> >>>
> >>> Low confidence here as I'm tracing lines across a ton of modules, but it
> >>> looks like it comes from the USB AXI clock in peri_image, which is a
> >>> gate on the normal 250Mhz APB clock, but nothing should be touching that
> >>> gate register as part of USB reset as far as I know.
> >>>
> >> Isn’t it possible that this clock (probably BCM2835_CLOCK_VPU) is
> >> changed by the firmware due to overclocking settings in /boot/config.txt?
> >
> > i don't use any overclocking settings.
> >
> > Are you able to reproduce the behavior on your Pi?
>
> I did not have any problems with USB recently (using 4.5),
> so I would not have any idea how to reproduce it.
>
> Note that I am using it with an AXIS USB-ethernet dongle plus USB-stick
> all the time on my Compute Module connected via a tiny hub,
> so I wonder if that qualifies as being able to trigger the issue...

the probe problem appears after applying John's patch series (it's not in 4.5):

[RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()
[RFT PATCH 2/2] Revert "usb: dwc2: Fix probe problem on bcm2835"

Please follow the complete discussion here [1].

[1] - http://marc.info/?l=linux-kernel=145711582915801=2

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

[PATCH 1/2] usb: dwc3: core: Introduce dwc3_device_reinit()

[Roger Quadros]

We will need this function for a workaround.
The function issues a softreset only to the device
controller and performs minimal re-initialization
so that the device controller can be usable.

As some code is similar to dwc3_core_init() take out
common code into dwc3_get_gctl_quirks().

We add a new member (prtcap_mode) to struct dwc3 to
keep track of the current mode in the PRTCAPDIR register.

Signed-off-by: Roger Quadros 
---
 drivers/usb/dwc3/core.c | 142 +---
 drivers/usb/dwc3/core.h |   3 +
 2 files changed, 102 insertions(+), 43 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 17fd8144..3b09494 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -58,6 +58,7 @@ void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
reg &= ~(DWC3_GCTL_PRTCAPDIR(DWC3_GCTL_PRTCAP_OTG));
reg |= DWC3_GCTL_PRTCAPDIR(mode);
dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+   dwc->prtcap_mode = mode;
 }
 
 /**
@@ -525,53 +526,16 @@ static int dwc3_phy_setup(struct dwc3 *dwc)
 }
 
 /**
- * dwc3_core_init - Low-level initialization of DWC3 Core
+ * dwc3_get_gctl_quirks - Prepare GCTL register content with quirks
+ * and workarounds.
  * @dwc: Pointer to our controller context structure
  *
- * Returns 0 on success otherwise negative errno.
+ * Returns 32-bit content that must be written into GCTL by caller.
  */
-static int dwc3_core_init(struct dwc3 *dwc)
+static u32 dwc3_get_gctl_quirks(struct dwc3 *dwc)
 {
-   u32 hwparams4 = dwc->hwparams.hwparams4;
-   u32 reg;
-   int ret;
-
-   reg = dwc3_readl(dwc->regs, DWC3_GSNPSID);
-   /* This should read as U3 followed by revision number */
-   if ((reg & DWC3_GSNPSID_MASK) == 0x5533) {
-   /* Detected DWC_usb3 IP */
-   dwc->revision = reg;
-   } else if ((reg & DWC3_GSNPSID_MASK) == 0x3331) {
-   /* Detected DWC_usb31 IP */
-   dwc->revision = dwc3_readl(dwc->regs, DWC3_VER_NUMBER);
-   dwc->revision |= DWC3_REVISION_IS_DWC31;
-   } else {
-   dev_err(dwc->dev, "this is not a DesignWare USB3 DRD Core\n");
-   ret = -ENODEV;
-   goto err0;
-   }
-
-   /*
-* Write Linux Version Code to our GUID register so it's easy to figure
-* out which kernel version a bug was found.
-*/
-   dwc3_writel(dwc->regs, DWC3_GUID, LINUX_VERSION_CODE);
-
-   /* Handle USB2.0-only core configuration */
-   if (DWC3_GHWPARAMS3_SSPHY_IFC(dwc->hwparams.hwparams3) ==
-   DWC3_GHWPARAMS3_SSPHY_IFC_DIS) {
-   if (dwc->maximum_speed == USB_SPEED_SUPER)
-   dwc->maximum_speed = USB_SPEED_HIGH;
-   }
-
-   /* issue device SoftReset too */
-   ret = dwc3_soft_reset(dwc);
-   if (ret)
-   goto err0;
-
-   ret = dwc3_core_soft_reset(dwc);
-   if (ret)
-   goto err0;
+   u32 reg;
+   u32 hwparams4 = dwc->hwparams.hwparams4;
 
reg = dwc3_readl(dwc->regs, DWC3_GCTL);
reg &= ~DWC3_GCTL_SCALEDOWN_MASK;
@@ -639,6 +603,59 @@ static int dwc3_core_init(struct dwc3 *dwc)
if (dwc->revision < DWC3_REVISION_190A)
reg |= DWC3_GCTL_U2RSTECN;
 
+   return reg;
+}
+
+/**
+ * dwc3_core_init - Low-level initialization of DWC3 Core
+ * @dwc: Pointer to our controller context structure
+ *
+ * Returns 0 on success otherwise negative errno.
+ */
+static int dwc3_core_init(struct dwc3 *dwc)
+{
+   u32 reg;
+   int ret;
+
+   reg = dwc3_readl(dwc->regs, DWC3_GSNPSID);
+   /* This should read as U3 followed by revision number */
+   if ((reg & DWC3_GSNPSID_MASK) == 0x5533) {
+   /* Detected DWC_usb3 IP */
+   dwc->revision = reg;
+   } else if ((reg & DWC3_GSNPSID_MASK) == 0x3331) {
+   /* Detected DWC_usb31 IP */
+   dwc->revision = dwc3_readl(dwc->regs, DWC3_VER_NUMBER);
+   dwc->revision |= DWC3_REVISION_IS_DWC31;
+   } else {
+   dev_err(dwc->dev, "this is not a DesignWare USB3 DRD Core\n");
+   ret = -ENODEV;
+   goto err0;
+   }
+
+   /*
+* Write Linux Version Code to our GUID register so it's easy to figure
+* out which kernel version a bug was found.
+*/
+   dwc3_writel(dwc->regs, DWC3_GUID, LINUX_VERSION_CODE);
+
+   /* Handle USB2.0-only core configuration */
+   if (DWC3_GHWPARAMS3_SSPHY_IFC(dwc->hwparams.hwparams3) ==
+   DWC3_GHWPARAMS3_SSPHY_IFC_DIS) {
+   if (dwc->maximum_speed == USB_SPEED_SUPER)
+   dwc->maximum_speed = USB_SPEED_HIGH;
+   }
+
+   /* issue device SoftReset too */
+   ret = dwc3_soft_reset(dwc);
+   if (ret)
+  

RE: USB Ethernet/RNDIS Gadget issue

[Gil Weber]

Hi,

> > I finally bisect the kernel (I didn't known that command, thanks for the 
> > tip)
> > and found that it doesn't work anymore from this commit :
> >
> > b0bac2581c1918cc4ab0aca01977ad69f0bc127a is the first bad commit
> > commit b0bac2581c1918cc4ab0aca01977ad69f0bc127a
> > Author: Robert Baldyga 
> > Date:   Wed Sep 16 12:10:42 2015 +0200
> >
> > usb: gadget: introduce 'enabled' flag in struct usb_ep
> >
> > This patch introduces 'enabled' flag in struct usb_ep, and modifies
> > usb_ep_enable() and usb_ep_disable() functions to encapsulate endpoint
> > enabled/disabled state. It helps to avoid enabling endpoints which are
> > already enabled, and disabling endpoints which are already disables.
> >
> > From now USB functions don't have to remember current endpoint
> > enable/disable state, as this state is now handled automatically which
> > makes this API less bug-prone.
> >
> > Signed-off-by: Robert Baldyga 
> > Signed-off-by: Felipe Balbi 
> >
> >
> > If I comment the test in function usb_ep_enable and usb_ep_disable to avoid
> > enabling or disabling endpoints that already are, it works.
> > But I guess the real issue is that this function is called more than once
> > at some point?
> 
> This is the second bug report involving Robert's series, we really need
> to give some deeper attention to this. Robert, care to comment ?
> 
> So, this means that if you let endpoints be enabled or disabled more
> than once, then it works ? Sounds like a bug in the UDC controller to
> me. Robert's patch just helped trigger the problem. Which controller
> were you using again ? Was it Atmel UDC ?

Yes that's it, and issue occurs when I unplug/plug the cable... On first 
connection it works.
And yes I am using using atmel_usba_udc.c module.

Thanks,
Gil
--
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 v5 3/6] usb: mux: add common code for Intel dual role port mux

[Lu Baolu]

Several Intel PCHs and SOCs have an internal mux that is used to
share one USB port between device controller and host controller.

A usb port mux could be abstracted as the following elements:
1) mux state: HOST or PERIPHERAL;
2) an extcon cable which triggers the change of mux state between
   HOST and PERIPHERAL;
3) The required action to do the real port switch.

This patch adds the common code to handle usb port mux. With this
common code, the individual mux driver, which always is platform
dependent, could focus on the real operation of mux switch.

Signed-off-by: Lu Baolu 
Reviewed-by: Heikki Krogerus 
Reviewed-by: Felipe Balbi 
---
 Documentation/ABI/testing/sysfs-bus-platform |  15 +++
 MAINTAINERS  |   7 ++
 drivers/usb/Kconfig  |   2 +
 drivers/usb/Makefile |   1 +
 drivers/usb/mux/Kconfig  |  12 ++
 drivers/usb/mux/Makefile |   4 +
 drivers/usb/mux/intel-mux.c  | 175 +++
 include/linux/usb/intel-mux.h|  40 ++
 8 files changed, 256 insertions(+)
 create mode 100644 drivers/usb/mux/Kconfig
 create mode 100644 drivers/usb/mux/Makefile
 create mode 100644 drivers/usb/mux/intel-mux.c
 create mode 100644 include/linux/usb/intel-mux.h

diff --git a/Documentation/ABI/testing/sysfs-bus-platform 
b/Documentation/ABI/testing/sysfs-bus-platform
index 5172a61..23bf76e 100644
--- a/Documentation/ABI/testing/sysfs-bus-platform
+++ b/Documentation/ABI/testing/sysfs-bus-platform
@@ -18,3 +18,18 @@ Description:
devices to opt-out of driver binding using a driver_override
name such as "none".  Only a single driver may be specified in
the override, there is no support for parsing delimiters.
+
+What:  /sys/bus/platform/devices/.../port_mux
+Date:  Febuary 2016
+Contact:   Lu Baolu 
+Description:
+   In some platforms, a single USB port is shared between a USB 
host
+   controller and a device controller. A USB mux driver is needed 
to
+   handle the port mux. port_mux attribute shows and stores the mux
+   state.
+   For read:
+   'peripheral' - mux switched to PERIPHERAL controller;
+   'host'   - mux switched to HOST controller.
+   For write:
+   'peripheral' - mux will be switched to PERIPHERAL controller;
+   'host'   - mux will be switched to HOST controller.
diff --git a/MAINTAINERS b/MAINTAINERS
index da3e4d8..0dbee11 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11399,6 +11399,13 @@ T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
 S: Maintained
 F: drivers/usb/phy/
 
+USB PORT MUX DRIVER
+M: Lu Baolu 
+L: linux-usb@vger.kernel.org
+S: Supported
+F: include/linux/usb/intel-mux.h
+F: drivers/usb/mux/intel-mux.c
+
 USB PRINTER DRIVER (usblp)
 M: Pete Zaitcev 
 L: linux-usb@vger.kernel.org
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 8ed451d..dbd6620 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -149,6 +149,8 @@ endif # USB
 
 source "drivers/usb/phy/Kconfig"
 
+source "drivers/usb/mux/Kconfig"
+
 source "drivers/usb/gadget/Kconfig"
 
 config USB_LED_TRIG
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index d5c57f1..6433f0c 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -6,6 +6,7 @@
 
 obj-$(CONFIG_USB)  += core/
 obj-$(CONFIG_USB_SUPPORT)  += phy/
+obj-$(CONFIG_USB_SUPPORT)  += mux/
 
 obj-$(CONFIG_USB_DWC3) += dwc3/
 obj-$(CONFIG_USB_DWC2) += dwc2/
diff --git a/drivers/usb/mux/Kconfig b/drivers/usb/mux/Kconfig
new file mode 100644
index 000..62e2cc3
--- /dev/null
+++ b/drivers/usb/mux/Kconfig
@@ -0,0 +1,12 @@
+#
+# USB port mux driver configuration
+#
+menu "USB Port MUX drivers"
+config INTEL_USB_MUX
+   select EXTCON
+   def_bool n
+   help
+ Common code for all Intel dual role port mux drivers. All Intel
+ usb port mux drivers should select it.
+
+endmenu
diff --git a/drivers/usb/mux/Makefile b/drivers/usb/mux/Makefile
new file mode 100644
index 000..84f0ae8
--- /dev/null
+++ b/drivers/usb/mux/Makefile
@@ -0,0 +1,4 @@
+#
+# Makefile for USB port mux drivers
+#
+obj-$(CONFIG_INTEL_USB_MUX)+= intel-mux.o
diff --git a/drivers/usb/mux/intel-mux.c b/drivers/usb/mux/intel-mux.c
new file mode 100644
index 000..d18b96f
--- /dev/null
+++ b/drivers/usb/mux/intel-mux.c
@@ -0,0 +1,175 @@
+/**
+ * intel_mux.c - USB Port Mux support
+ *
+ * Copyright (C) 2016 Intel Corporation
+ *
+ * Author: Lu Baolu 
+ *
+ * This program is free software; you can redistribute it and/or 

[PATCH] Input: gtco: fix crash on detecting device without endpoints

[Vladis Dronov]

The gtco driver expects at least one valid endpoint. If given
malicious descriptors that specify 0 for the number of endpoints,
it will crash in the probe function. Ensure there is at least
one endpoint on the interface before using it. Fix minor coding
style issue.

The full report of this issue can be found here:
http://seclists.org/bugtraq/2016/Mar/86

Reported-by: Ralf Spenneberg 
Signed-off-by: Vladis Dronov 
---
 drivers/input/tablet/gtco.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/input/tablet/gtco.c b/drivers/input/tablet/gtco.c
index 3a7f3a4..7c18249 100644
--- a/drivers/input/tablet/gtco.c
+++ b/drivers/input/tablet/gtco.c
@@ -858,6 +858,14 @@ static int gtco_probe(struct usb_interface *usbinterface,
goto err_free_buf;
}
 
+   /* Sanity check that a device has an endpoint */
+   if (usbinterface->altsetting[0].desc.bNumEndpoints < 1) {
+   dev_err(>dev,
+   "Invalid number of endpoints\n");
+   error = -EINVAL;
+   goto err_free_urb;
+   }
+
/*
 * The endpoint is always altsetting 0, we know this since we know
 * this device only has one interrupt endpoint
@@ -879,7 +887,7 @@ static int gtco_probe(struct usb_interface *usbinterface,
 * HID report descriptor
 */
if (usb_get_extra_descriptor(usbinterface->cur_altsetting,
-HID_DEVICE_TYPE, _desc) != 0){
+HID_DEVICE_TYPE, _desc) != 0) {
dev_err(>dev,
"Can't retrieve exta USB descriptor to get hid report 
descriptor length\n");
error = -EIO;
-- 
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 v2 11/11] usb: musb: da8xx: Remove mach code

[David Lechner]

Use the new phy-da8xx-usb driver to take the place of the mach code that
pokes CFGCHIP2 in the da8xx musb glue driver.

Signed-off-by: David Lechner 
---

v2 changes: This is part of a previous patch that was split. This version uses
the new phy driver instead of a second clock. It also gets rid of more mach
code.


 drivers/usb/musb/da8xx.c | 126 ---
 1 file changed, 31 insertions(+), 95 deletions(-)

diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index 50f07a5..1d51711 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -30,13 +30,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 
-#include 
-#include 
-
 #include "musb_core.h"
 
 /*
@@ -80,61 +78,15 @@
 
 #define DA8XX_MENTOR_CORE_OFFSET 0x400
 
-#define CFGCHIP2   IO_ADDRESS(DA8XX_SYSCFG0_BASE + DA8XX_CFGCHIP2_REG)
-
 struct da8xx_glue {
struct device   *dev;
struct platform_device  *musb;
-   struct platform_device  *phy;
+   struct platform_device  *usb_phy;
struct clk  *clk;
+   struct phy  *phy;
 };
 
 /*
- * REVISIT (PM): we should be able to keep the PHY in low power mode most
- * of the time (24 MHz oscillator and PLL off, etc.) by setting POWER.D0
- * and, when in host mode, autosuspending idle root ports... PHY_PLLON
- * (overriding SUSPENDM?) then likely needs to stay off.
- */
-
-static inline void phy_on(void)
-{
-   u32 cfgchip2 = __raw_readl(CFGCHIP2);
-
-   /*
-* Start the on-chip PHY and its PLL.
-*/
-   cfgchip2 &= ~(CFGCHIP2_RESET | CFGCHIP2_PHYPWRDN | CFGCHIP2_OTGPWRDN);
-   cfgchip2 |= CFGCHIP2_PHY_PLLON;
-   __raw_writel(cfgchip2, CFGCHIP2);
-
-   pr_info("Waiting for USB PHY clock good...\n");
-   while (!(__raw_readl(CFGCHIP2) & CFGCHIP2_PHYCLKGD))
-   cpu_relax();
-}
-
-static inline void phy_off(void)
-{
-   u32 cfgchip2 = __raw_readl(CFGCHIP2);
-
-   /*
-* Ensure that USB 1.1 reference clock is not being sourced from
-* USB 2.0 PHY.  Otherwise do not power down the PHY.
-*/
-   if (!(cfgchip2 & CFGCHIP2_USB1PHYCLKMUX) &&
-(cfgchip2 & CFGCHIP2_USB1SUSPENDM)) {
-   pr_warning("USB 1.1 clocked from USB 2.0 PHY -- "
-  "can't power it down\n");
-   return;
-   }
-
-   /*
-* Power down the on-chip PHY.
-*/
-   cfgchip2 |= CFGCHIP2_PHYPWRDN | CFGCHIP2_OTGPWRDN;
-   __raw_writel(cfgchip2, CFGCHIP2);
-}
-
-/*
  * Because we don't set CTRL.UINT, it's "important" to:
  * - not read/write INTRUSB/INTRUSBE (except during
  *   initial setup, as a workaround);
@@ -383,31 +335,18 @@ static irqreturn_t da8xx_musb_interrupt(int irq, void 
*hci)
return ret;
 }
 
+extern int da8xx_usb20_phy_set_mode(struct phy *phy, enum musb_mode mode);
+
 static int da8xx_musb_set_mode(struct musb *musb, u8 musb_mode)
 {
-   u32 cfgchip2 = __raw_readl(CFGCHIP2);
+   struct da8xx_glue *glue = dev_get_drvdata(musb->controller->parent);
 
-   cfgchip2 &= ~CFGCHIP2_OTGMODE;
-   switch (musb_mode) {
-   case MUSB_HOST: /* Force VBUS valid, ID = 0 */
-   cfgchip2 |= CFGCHIP2_FORCE_HOST;
-   break;
-   case MUSB_PERIPHERAL:   /* Force VBUS valid, ID = 1 */
-   cfgchip2 |= CFGCHIP2_FORCE_DEVICE;
-   break;
-   case MUSB_OTG:  /* Don't override the VBUS/ID comparators */
-   cfgchip2 |= CFGCHIP2_NO_OVERRIDE;
-   break;
-   default:
-   dev_dbg(musb->controller, "Trying to set unsupported mode 
%u\n", musb_mode);
-   }
-
-   __raw_writel(cfgchip2, CFGCHIP2);
-   return 0;
+   return da8xx_usb20_phy_set_mode(glue->phy, musb_mode);
 }
 
 static int da8xx_musb_init(struct musb *musb)
 {
+   struct da8xx_glue *glue = dev_get_drvdata(musb->controller->parent);
void __iomem *reg_base = musb->ctrl_base;
u32 rev;
int ret = -ENODEV;
@@ -425,19 +364,24 @@ static int da8xx_musb_init(struct musb *musb)
goto fail;
}
 
+   ret = clk_prepare_enable(glue->clk);
+   if (ret) {
+   dev_err(glue->dev, "failed to enable clock\n");
+   goto fail;
+   }
+
setup_timer(_workaround, otg_timer, (unsigned long)musb);
 
/* Reset the controller */
musb_writel(reg_base, DA8XX_USB_CTRL_REG, DA8XX_SOFT_RESET_MASK);
 
/* Start the on-chip PHY and its PLL. */
-   phy_on();
+   phy_power_on(glue->phy);
 
msleep(5);
 
/* NOTE: IRQs are in mixed mode, not bypass to pure MUSB */
-   pr_debug("DA8xx OTG revision %08x, PHY %03x, control %02x\n",
-rev, __raw_readl(CFGCHIP2),
+   pr_debug("DA8xx OTG revision %08x, control %02x\n", rev,
 musb_readb(reg_base, DA8XX_USB_CTRL_REG));
 
 

RE: RE

[Robert]

Please confirm receipt of my previous mail..When can i call you 
--
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] digi_acceleport: do sanity checking for the number of ports

[Oliver Neukum]

On Wed, 2016-03-16 at 10:58 -0400, Johan Hovold wrote:
> Note that this needs to be done for not just the port structure
> (ds_oob_port) by making sure that the serial->num_ports is large
> enough,
> but also that the oob-port has indeed got a write urb allocated (i.e.
> that all expected bulk-out endpoints are available)

How about this version?
We really should have a way to specify that to the generic serial
driver.

Regards
Oliver

From 75c015b7281411abbfc4c148e648786258cffedb Mon Sep 17 00:00:00 2001
From: Oliver Neukum 
Date: Mon, 14 Mar 2016 15:33:15 +0100
Subject: [PATCH] digi_acceleport: do sanity checking for the number of ports

The driver can be crashed with devices that expose crafted
descriptors with too few endpoints.
See:
http://seclists.org/bugtraq/2016/Mar/61

Signed-off-by: Oliver Neukum 
---
 drivers/usb/serial/digi_acceleport.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/serial/digi_acceleport.c b/drivers/usb/serial/digi_acceleport.c
index 12b0e67..40584d5 100644
--- a/drivers/usb/serial/digi_acceleport.c
+++ b/drivers/usb/serial/digi_acceleport.c
@@ -1302,6 +1302,9 @@ static void digi_release(struct usb_serial *serial)
 
 static int digi_port_probe(struct usb_serial_port *port)
 {
+	if (!port->read_urb || !port->write_urb)
+		return -ENODEV;
+
 	return digi_port_init(port, port->port_number);
 }
 
-- 
2.1.4

[PATCH] usb: dwc2: do not override forced dr_mode in gadget setup

[Przemek Rudy]

The host/device mode set with dr_mode should be kept all the time,
not being changed to OTG in gadget setup (by overriding CFGUSB_FORCEDEVMODE
and CFGUSB_FORCEHOSTMODE bits).

Signed-off-by: Przemek Rudy 
---
 drivers/usb/dwc2/gadget.c | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index e9940dd..818f158 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2254,6 +2254,7 @@ void dwc2_hsotg_core_init_disconnected(struct dwc2_hsotg 
*hsotg,
 {
u32 intmsk;
u32 val;
+   u32 usbcfg;
 
/* Kill any ep0 requests as controller will be reinitialized */
kill_all_requests(hsotg, hsotg->eps_out[0], -ECONNRESET);
@@ -2267,10 +2268,16 @@ void dwc2_hsotg_core_init_disconnected(struct 
dwc2_hsotg *hsotg,
 * set configuration.
 */
 
+   /* keep other bits untouched (so e.g. forced modes are not lost) */
+   usbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
+   usbcfg &= ~(GUSBCFG_TOUTCAL_MASK | GUSBCFG_PHYIF16 | GUSBCFG_SRPCAP |
+   GUSBCFG_HNPCAP);
+
/* set the PLL on, remove the HNP/SRP and set the PHY */
val = (hsotg->phyif == GUSBCFG_PHYIF8) ? 9 : 5;
-   dwc2_writel(hsotg->phyif | GUSBCFG_TOUTCAL(7) |
-  (val << GUSBCFG_USBTRDTIM_SHIFT), hsotg->regs + GUSBCFG);
+   usbcfg |= hsotg->phyif | GUSBCFG_TOUTCAL(7) |
+   (val << GUSBCFG_USBTRDTIM_SHIFT);
+   dwc2_writel(usbcfg, hsotg->regs + GUSBCFG);
 
dwc2_hsotg_init_fifo(hsotg);
 
@@ -3031,6 +3038,7 @@ static struct usb_ep_ops dwc2_hsotg_ep_ops = {
 static void dwc2_hsotg_init(struct dwc2_hsotg *hsotg)
 {
u32 trdtim;
+   u32 usbcfg;
/* unmask subset of endpoint interrupts */
 
dwc2_writel(DIEPMSK_TIMEOUTMSK | DIEPMSK_AHBERRMSK |
@@ -3054,11 +3062,16 @@ static void dwc2_hsotg_init(struct dwc2_hsotg *hsotg)
 
dwc2_hsotg_init_fifo(hsotg);
 
+   /* keep other bits untouched (so e.g. forced modes are not lost) */
+   usbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
+   usbcfg &= ~(GUSBCFG_TOUTCAL_MASK | GUSBCFG_PHYIF16 | GUSBCFG_SRPCAP |
+   GUSBCFG_HNPCAP);
+
/* set the PLL on, remove the HNP/SRP and set the PHY */
trdtim = (hsotg->phyif == GUSBCFG_PHYIF8) ? 9 : 5;
-   dwc2_writel(hsotg->phyif | GUSBCFG_TOUTCAL(7) |
-   (trdtim << GUSBCFG_USBTRDTIM_SHIFT),
-   hsotg->regs + GUSBCFG);
+   usbcfg |= hsotg->phyif | GUSBCFG_TOUTCAL(7) |
+   (trdtim << GUSBCFG_USBTRDTIM_SHIFT);
+   dwc2_writel(usbcfg, hsotg->regs + GUSBCFG);
 
if (using_dma(hsotg))
__orr32(hsotg->regs + GAHBCFG, GAHBCFG_DMA_EN);
-- 
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 v2 00/11] da8xx USB clocks

[David Lechner]

OK, ready for round two.

I've added a new callback in the davinci clocks so that they can properly
handle clock muxing. The clock functions are pretty much the same as in the
previous patch set other than clk_set_parent() now works.

The next new thing is a phy driver for the CFGCHIP2 register that controls the
SoC USB PHY (both USB 1.1 and USB 2.0). The ohci and musb drivers have been
updated to use this new phy driver.

David Lechner (10):
  ARM: davinci: add set_parent callback for mux clocks
  ARM: davinci: da850: use clk->set_parent for async3
  ARM: davinci: da8xx: add usb phy clocks
  dt-bindings: Add bindings for phy-da8xx-usb
  phy: da8xx-usb: new driver for DA8XX SoC USB PHY
  ARM: davinci: da8xx: Add USB PHY platform declaration
  ARM: dt: da850: Add usb phy node
  usb: ohci-da8xx: Remove code that references mach
  usb: musb: da8xx: Use devm in probe
  usb: musb: da8xx: Remove mach code

Petr Kulhavy (1):
  ARM: davinci: defined missing CFGCHIP2_REFFREQ_* macros for MUSB PHY

 .../devicetree/bindings/phy/phy-da8xx-usb.txt  |  34 +++
 arch/arm/boot/dts/da850.dtsi   |   6 +
 arch/arm/mach-davinci/board-da830-evm.c|  12 -
 arch/arm/mach-davinci/board-omapl138-hawk.c|   7 -
 arch/arm/mach-davinci/clock.c  |  17 +-
 arch/arm/mach-davinci/clock.h  |   1 +
 arch/arm/mach-davinci/da830.c  | 143 ++
 arch/arm/mach-davinci/da850.c  | 231 
 arch/arm/mach-davinci/include/mach/da8xx.h |   1 +
 arch/arm/mach-davinci/usb.c|  24 +-
 drivers/phy/Kconfig|   9 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-da8xx-usb.c| 295 +
 drivers/usb/host/ohci-da8xx.c  |  90 +++
 drivers/usb/musb/da8xx.c   | 150 +++
 include/linux/platform_data/usb-davinci.h  |   6 +
 16 files changed, 799 insertions(+), 228 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-da8xx-usb.txt
 create mode 100644 drivers/phy/phy-da8xx-usb.c

-- 
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 1/2] usb: dwc3: core: Introduce dwc3_device_reinit()

[Felipe Balbi]

heh, +john

Felipe Balbi  writes:
> [ text/plain ]
>
> Hi,
>
> Roger Quadros  writes:
>> [ text/plain ]
>> We will need this function for a workaround.
>> The function issues a softreset only to the device
>> controller and performs minimal re-initialization
>> so that the device controller can be usable.
>>
>> As some code is similar to dwc3_core_init() take out
>> common code into dwc3_get_gctl_quirks().
>>
>> We add a new member (prtcap_mode) to struct dwc3 to
>> keep track of the current mode in the PRTCAPDIR register.
>>
>> Signed-off-by: Roger Quadros 
>
> I must say, I don't like this at all :-p There's ONE known silicon which
> needs this because of a poor silicon integration which took an IP with a
> known erratum where it can't be made to work on lower speeds and STILL
> was integrated without a superspeed PHY.
>
> There's a reason why I never tried to push this upstream myself ;-)
>
> I'm really thinking we might be better off adding a quirk flag to skip
> the metastability workaround and allow this ONE silicon to set the
> controller to lower speed.
>
> John, can you check with your colleagues if we would ever fall into
> STAR#9000525659 if we set maximum speed to high speed during driver
> probe and never touch it again ? I would assume we don't really fall
> into the metastability workaround, right ? We're not doing any sort of
> PM for dwc3...
>
> -- 
> balbi
> [ signature.asc: application/pgp-signature ]

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] usb_driver_claim_interface: add sanity checking

[Alan Stern]

On Wed, 16 Mar 2016, Oliver Neukum wrote:

> Attacks that trick drivers into passing a NULL pointer
> to usb_driver_claim_interface() using forged descriptors are
> known. This thwarts them by sanity checking.

I'm curious -- how do these attacks carry out their trickery?

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 v7 2/4] gadget: Support for the usb charger framework

[kbuild test robot]

Hi Baolin,

[auto build test WARNING on v4.5-rc7]
[also build test WARNING on next-20160316]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Baolin-Wang/Introduce-usb-charger-framework-to-deal-with-the-usb-gadget-power-negotation/20160316-195102
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   include/linux/usb/gadget.h:228: warning: No description found for parameter 
'claimed'
   include/linux/usb/gadget.h:228: warning: No description found for parameter 
'enabled'
>> include/linux/usb/gadget.h:656: warning: No description found for parameter 
>> 'charger'
   include/linux/usb/gadget.h:656: warning: No description found for parameter 
'quirk_altset_not_supp'
   include/linux/usb/gadget.h:656: warning: No description found for parameter 
'quirk_stall_not_supp'
   include/linux/usb/gadget.h:656: warning: No description found for parameter 
'quirk_zlp_not_supp'
   include/linux/usb/composite.h:501: warning: Excess struct/union/enum/typedef 
member 'setup_pending' description in 'usb_composite_dev'
   include/linux/usb/composite.h:501: warning: Excess struct/union/enum/typedef 
member 'os_desc_pending' description in 'usb_composite_dev'
   drivers/usb/gadget/function/f_acm.c:1: warning: no structured comments found
   drivers/usb/gadget/function/f_ecm.c:1: warning: no structured comments found
   drivers/usb/gadget/function/f_subset.c:1: warning: no structured comments 
found
   drivers/usb/gadget/function/f_obex.c:1: warning: no structured comments found
   drivers/usb/gadget/function/f_serial.c:1: warning: no structured comments 
found

vim +/charger +656 include/linux/usb/gadget.h

77e9162f include/linux/usb/gadget.h Baolin Wang 2016-03-16  640 /* 
negotiate the power with the usb charger */
77e9162f include/linux/usb/gadget.h Baolin Wang 2016-03-16  641 struct 
usb_charger  *charger;
d8318d7f include/linux/usb/gadget.h David Cohen 2013-12-09  642  
898c6086 include/linux/usb/gadget.h Felipe Balbi2011-11-22  643 
unsignedsg_supported:1;
^1da177e include/linux/usb_gadget.h Linus Torvalds  2005-04-16  644 
unsignedis_otg:1;
^1da177e include/linux/usb_gadget.h Linus Torvalds  2005-04-16  645 
unsignedis_a_peripheral:1;
^1da177e include/linux/usb_gadget.h Linus Torvalds  2005-04-16  646 
unsignedb_hnp_enable:1;
^1da177e include/linux/usb_gadget.h Linus Torvalds  2005-04-16  647 
unsigneda_hnp_support:1;
^1da177e include/linux/usb_gadget.h Linus Torvalds  2005-04-16  648 
unsigneda_alt_hnp_support:1;
0b2d2bba include/linux/usb/gadget.h David Cohen 2013-12-09  649 
unsignedquirk_ep_out_aligned_size:1;
ffd9a0fc include/linux/usb/gadget.h Robert Baldyga  2015-07-28  650 
unsignedquirk_altset_not_supp:1;
02ded1b0 include/linux/usb/gadget.h Robert Baldyga  2015-07-28  651 
unsignedquirk_stall_not_supp:1;
ca1023c8 include/linux/usb/gadget.h Robert Baldyga  2015-07-28  652 
unsignedquirk_zlp_not_supp:1;
80b2502c include/linux/usb/gadget.h Peter Chen  2015-01-28  653 
unsignedis_selfpowered:1;
ccdf138f include/linux/usb/gadget.h Robert Baldyga  2015-05-04  654 
unsigneddeactivated:1;
ccdf138f include/linux/usb/gadget.h Robert Baldyga  2015-05-04  655 
unsignedconnected:1;
^1da177e include/linux/usb_gadget.h Linus Torvalds  2005-04-16 @656  };
5702f753 include/linux/usb/gadget.h Felipe Balbi2013-07-17  657  #define 
work_to_gadget(w)  (container_of((w), struct usb_gadget, work))
^1da177e include/linux/usb_gadget.h Linus Torvalds  2005-04-16  658  
^1da177e include/linux/usb_gadget.h Linus Torvalds  2005-04-16  659  static 
inline void set_gadget_data(struct usb_gadget *gadget, void *data)
^1da177e include/linux/usb_gadget.h Linus Torvalds  2005-04-16  660 { 
dev_set_drvdata(>dev, data); }
^1da177e include/linux/usb_gadget.h Linus Torvalds  2005-04-16  661  static 
inline void *get_gadget_data(struct usb_gadget *gadget)
^1da177e include/linux/usb_gadget.h Linus Torvalds  2005-04-16  662 { 
return dev_get_drvdata(>dev); }
f48cf80f include/linux/usb/gadget.h Fabien Chouteau 2010-04-23  663  static 
inline struct usb_gadget *dev_to_usb_gadget(struct device *dev)
f48cf80f include/linux/usb/gadget.h Fabien Chouteau 2010-04-23  664  {

:: The code at line 656 was first introduced by commit
:: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2

:: TO: Linus Torvalds 
:: CC: Linus Torvalds 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all  

Re: problems with cp210x

[Greg KH]

On Thu, Mar 17, 2016 at 05:41:13PM +0100, walter harms wrote:
> 
> 
> Am 29.02.2016 17:10, schrieb Greg KH:
> > On Mon, Feb 29, 2016 at 02:47:45PM +0100, walter harms wrote:
> >> Hello List,
> >>
> >> is someone aware of a problem with DTR in that driver ?
> >>
> >> I use: Linux version 3.4.53-MMI-SW.401_0.1-43
> > 
> > That's a very old and obsolete kernel version.  Please ask for support
> > from the vendor that is forcing you to live with that kernel version,
> > that is what you are paying for.
> > 
> > We can help you here if you try the latest kernel release, can you try
> > 4.4?
> > 
> 
> Hi,
> i would like to give same feedback.
> 
> Using a newer version of linux caused unexpected problems unrelated to the 
> interface
> but we found a possible trouble spot.

What problems did you have?

> the chip cp2105 has a One Time Programmable register to define DTR etc.
> we were not aware of that.
> 
> I would suggest to add an ioctl to get the mode. (I did not see one).
> so someone has a change to find the problem next time.

The mode of what?  The tty line?  Something else?

Please be more specific.

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: usb: dwc2: Kernel 4.5 and socfpga problem

[Phil Reid]

On 18/03/2016 10:41 PM, Dinh Nguyen wrote:

On 03/17/2016 09:35 PM, Phil Reid wrote:

G'day,

Has anyone successful run the usb dwc2 from kenerl 4.5 on an socfpga.



Yes. I just tested on the devkit and USB is working fine:


[0.655761] ffb4.usb supply vusb_d not found, using dummy regulator
[0.662384] ffb4.usb supply vusb_a not found, using dummy regulator
[0.943627] dwc2 ffb4.usb: EPs: 16, dedicated fifos, 8064 entries
in SPRAM
[0.951145] dwc2 ffb4.usb: DWC OTG Controller
[0.955872] dwc2 ffb4.usb: new USB bus registered, assigned bus
number 1
[0.962908] dwc2 ffb4.usb: irq 37, io mem 0x
[0.968877] hub 1-0:1.0: USB hub found
[0.972641] hub 1-0:1.0: 1 port detected

[...]

root@socfpga_cyclone5:~# uname -a
Linux socfpga_cyclone5 4.5.0 #1 SMP Fri Mar 18 09:36:26 CDT 2016 armv7l
GNU/Linux
root@socfpga_cyclone5:~# [ 21.793687] usb 1-1: USB disconnect, device
number 2
[ 24.173612] usb 1-1: new high-speed USB device number 3 using dwc2


Inital I've had to remove the phys & phy-names property from the DT for
it to even probe.
Otherwise it was returning PROBE_DEFERED.
The 4.4 driver seems to be getting the same error but it continued
loading regardless.



What hardware are you using? Sockit, Atlas board, socrates, etc?


After fixing that and getting it to load its going into overcurrent fault.
Applying Dinh's patch from the Altera 4.4 tree
FogBugz #198256: Fix unnecessary USB overcurrent condition
hasn't help. The driver immediately goes into an overcurrent condition
at boot.


I'm still trying to find a way to upstream this patch.



It's our own hardware design. But the USB interface is using the same parts
as the Altera SocKit.
As I said 4.4 worked fine. I see some chatter on about dwc2 reset times on the 
list.
So was wondering if it's related.
I do have a SocKit that I'll try to upgrade the kernel of and see how that goes.


--
Regards
Phil Reid

--
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] qmi_wwan: Added support for Gemalto's Cinterion PHxx WWAN interface

[Schemmel Hans-Christoph]

Added support for Gemalto's Cinterion PHxx WWAN interfaces 
by adding QMI_FIXED_INTF with Cinterion's VID and PID.

PHxx can have:
2 RmNet Interfaces (PID 0x0082) or
1 RmNet + 1 USB Audio interface (PID 0x0083).

Signed-off-by: Hans-Christoph Schemmel 
---
patch is against linux-4.5
--- linux/drivers/net/usb/qmi_wwan.c.orig   2016-03-14 12:18:07.153497489 
+0100
+++ linux/drivers/net/usb/qmi_wwan.c2016-03-14 12:21:37.722541644 +0100
@@ -881,6 +881,9 @@ static const struct usb_device_id produc
{QMI_FIXED_INTF(0x0b3c, 0xc00b, 4)},/* Olivetti Olicard 500 */
{QMI_FIXED_INTF(0x1e2d, 0x0060, 4)},/* Cinterion PLxx */
{QMI_FIXED_INTF(0x1e2d, 0x0053, 4)},/* Cinterion PHxx,PXxx */
+   {QMI_FIXED_INTF(0x1e2d, 0x0082, 4)},/* Cinterion PHxx,PXxx (2 
RmNet) */
+   {QMI_FIXED_INTF(0x1e2d, 0x0082, 5)},/* Cinterion PHxx,PXxx (2 
RmNet) */
+   {QMI_FIXED_INTF(0x1e2d, 0x0083, 4)},/* Cinterion PHxx,PXxx (1 RmNet 
+ USB Audio)*/
{QMI_FIXED_INTF(0x413c, 0x81a2, 8)},/* Dell Wireless 5806 Gobi(TM) 
4G LTE Mobile Broadband Card */
{QMI_FIXED_INTF(0x413c, 0x81a3, 8)},/* Dell Wireless 5570 HSPA+ 
(42Mbps) Mobile Broadband Card */
{QMI_FIXED_INTF(0x413c, 0x81a4, 8)},/* Dell Wireless 5570e HSPA+ 
(42Mbps) Mobile Broadband Card */


smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH] usb: chipidea: Configure DMA properties and ops from DT

[Peter Chen]

On Thu, Mar 17, 2016 at 04:52:55PM +0100, Arnd Bergmann wrote:
> On Monday 14 March 2016 18:51:08 Peter Chen wrote:
> > On Wed, Mar 09, 2016 at 05:16:50PM -0600, Li Yang wrote:
> > > On Tue, Mar 8, 2016 at 9:40 PM, Bjorn Andersson
> > >  wrote:
> > > > On Tue, Mar 8, 2016 at 11:52 AM, Li Yang  wrote:
> > > >> On Wed, Mar 2, 2016 at 4:59 PM, Li Yang  wrote:
> > > >>> On Mon, Feb 22, 2016 at 4:07 PM, Bjorn Andersson
> > > >>>  wrote:
> > >  On Mon 22 Feb 02:03 PST 2016, Srinivas Kandagatla wrote:
> > > >
> > > > I had the chance to go through this with Arnd and the verdict is that
> > > > devices not described in DT should not do DMA (or allocate buffers for
> > > > doing DMA).
> > > >
> > > > So I believe the solution is to fall back on Peter's description; the
> > > > chipidea driver is the core driver and the Qualcomm code should just
> > > > be a platform layer.
> > > >
> > > > My suggestion is that we turn the chipidea core into a set of APIs
> > > > that can called by the platform specific pieces. That way we will have
> > > > the chipidea core be the device described in the DT.
> > > 
> > > But like I said, this problem is not just existing for chipidea
> > > driver.  We already found that the dwc3 driver is also suffering from
> > > the same issue.  I don't know how many other drivers are impacted by
> > > this change, but I suspect there will be some. A grep of
> > > platform_device_add() in driver/ directory returns many possible
> > > drivers to be impacted.  As far as I know, the
> > > drivers/net/ethernet/freescale/fman/mac.c is registering child
> > > ethernet devices that definitely will do dma.   If you want to do this
> > > kind of rework to all these drivers, it will be a really big effort.
> > > 
> > 
> > +1
> > 
> > Yes, I think this DMA things should be covered by driver core too.
> > 
> 
> I don't think it's a very widespread problem, there are only very few
> developers that intentionally use this method, and some use the
> platform_device_register_full() call to create a device with a known
> mask, which is generally ok for the limited case where the driver
> is only ever going to run on a single platform, but not in the
> more general case that of_dma_configure is designed to handle.

Even only for qualcomm platforms, it may be possible have different
DMA masks at ARM64 platforms, so we may can't use a fixed value
at glue layer driver. So, using of_dma_configure is suitable choice
for DT platforms for this case, right?

> 
> I think we should fix the drivers to consistently use the device
> that was created by the platform (DT or ACPI or board file)
> to pass that into the DMA API, anything else will just cause
> more subtle bugs.
> 

Although I don't know what kinds of bugs it may have, it may be
met before, otherwise, why most of platform drivers need to call
dma_set_coherent_mask or dma_coerce_mask_and_coherent explicitly

-- 

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: PROBLEM: Osprey 2 Mini sometimes resets every 200ms forever

[Alan Stern]

On Wed, 16 Mar 2016, ais523 wrote:

> On Wed, 2016-03-16 at 10:07 -0400, Alan Stern wrote:
> > On Wed, 16 Mar 2016, ais523 wrote:
> > > One line summary of the problem:
> > > Connecting an Osprey 2 Mini sometimes causes it to reset every
> > 200ms
> >
> > Please post a usbmon trace showing what happens when you plug in the 
> > device.  (See Documentation/usb/usbmon.txt for instructions).
> 
> Here are two usbmon traces, one in which plugging in the device caused
> a reset loop, one in which it didn't.

In fact both logs show a loop of resets.  I'll focus on just the
first reset.

> No reset loop:
...
> 880118636a80 189630599 S Bo:1:006:1 -115 31 = 55534243 1f00 0200 
> 80010a51  0002  00
> 880118636a80 189630639 C Bo:1:006:1 0 31 >
> 88003f99ea80 189630649 S Bi:1:006:1 -115 2 <
> 88003f99ea80 189635905 C Bi:1:006:1 -75 0
> 880118636a80 189635966 S Bi:1:006:1 -115 13 <
> 880118636a80 189636263 C Bi:1:006:1 0 8 = 55534243 1f00
> 88003f99ea80 189636339 S Co:1:002:0 s 23 03 0004 0002  0
> 88003f99ea80 189636515 C Co:1:002:0 0 0

This shows a READ DISC INFORMATION command, asking the device to send 2
bytes (the first 2 bytes of the response indicate the total information
length).  The device tried to send back more than 2 bytes, violating
the Mass Storage protocol.  This led the computer to do a reset.  
After the reset (200 ms later) the computer tried sending the same
command, and the same thing happened.  That's where your loop comes
from.

There's no question about it -- your problem is caused by a buggy 
device.

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 5/5] usb: musb-da8xx: remove board-specific clock handling

[Sergei Shtylyov]

Hello.

On 3/16/2016 1:37 AM, David Lechner wrote:


This driver should not have to worry about how the clocks are configured
on a system. Added a usb20_phy clock to handle the USB 2.0 PLL clock
externally.

Also changed to using devm_ to simplify code a bit.


   This should preferably be split to another patch. Doing one thing per 
patch is a rule of thumb.



Signed-off-by: David Lechner 

[...]

MBR, Sergei

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