Re: (4.3.0) r8152: deadlock related to runtime suspend?

[Lu Baolu]

Hi Peter,

Have you ever tried disabling auto-pm? Did things go smoothly if auto-pm is 
disabled?

I always disable usb auto-pm in below way.

# echo on | tee /sys/bus/usb/devices/*/power/control
# echo on > /sys/bus/pci/devices//power/control

Thanks,
Baolu

On 12/05/2015 06:59 PM, Peter Wu wrote:
> Hi,
>
> I rarely use a Realtek USB 3.0 Gigabit Ethernet adapter (vid/pid
> 0bda:8153), but when I did last night, it resulted in a lockup of
> processes doing networking ("ip link", "ping", "ethtool", ...).
>
> A (few) minute(s) before that event, I noticed that there was no network
> connectivity (ping hung) which was somehow solved by invoking "ethtool
> eth1" (triggering runtime pm wakeup?). This same trick did not work at
> the next event. Invoking "ethtool eth1", "ip link", etc. hung completely
> and interrupt (^C) did not work at all.
>
> Since that did not work, I pulled the USB adapter and re-inserted it,
> hoping it would reset things. That did not work at all, there was a
> "usb disconnect" message, but no further driver messages.
>
> Fast forward an hour, and it has become a disaster. I have terminated
> and killed many programs via SysRq but am still unable to get a stable
> system that does not hang on network I/O. Even the suspend process
> fails so in the end I attempted to shutdown the system. After half an
> hour after getting the poweroff message, I issued SysRq + B to reboot
> (since SysRq + O did not shut down either).
>
> Attached are logs with various various backtraces from SysRq and failed
> suspend. Let me know if you need more information!
>
> By the way, often I have to rmmod xhci and re-insert it, otherwise
> plugging it in does not result in a detection. A USB 2.0 port does not
> have this problem (runtime PM is enabled for all devices). This is the
> USB 3.0 port:
>
> 02:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0
> Host Controller [1033:0194] (rev 03)

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

Re: [PATCH] usb: host: iounmap before return

[Lu Baolu]

On 12/06/2015 09:47 PM, Geyslan G. Bem wrote:
> This patch fixes a 'quirk_usb_handoff_xhci()' branch return that was not 
> unmapping correctly.
>
> Coccinelle: scripts/coccinelle/free/iounmap.cocci
>
> Signed-off-by: Geyslan G. Bem 
> ---
>  drivers/usb/host/pci-quirks.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
> index f940056..64150dd 100644
> --- a/drivers/usb/host/pci-quirks.c
> +++ b/drivers/usb/host/pci-quirks.c
> @@ -990,7 +990,7 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
>   /* We're reading garbage from the controller */
>   dev_warn(&pdev->dev,
>"xHCI controller failing to respond");
> - return;
> + goto out;

If "out" is only used here, why not iounmap and return directly here?

>   }
>  
>   if (!ext_cap_offset)
> @@ -1062,6 +1062,7 @@ hc_init:
>XHCI_MAX_HALT_USEC, val);
>   }
>  
> +out:
>   iounmap(base);
>  }
>  

--
To unsubscribe from this list: send the line "unsubscribe 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: (4.3.0) r8152: deadlock related to runtime suspend?

[Peter Wu]

On Mon, Dec 07, 2015 at 05:11:50PM +0800, Lu Baolu wrote:
> Hi Peter,
> 
> Have you ever tried disabling auto-pm? Did things go smoothly if auto-pm is 
> disabled?
> 
> I always disable usb auto-pm in below way.
> 
> # echo on | tee /sys/bus/usb/devices/*/power/control
> # echo on > /sys/bus/pci/devices//power/control
> 
> Thanks,
> Baolu

Hi Baolu,

The deadlock does not seem to occur with auto-PM disabled, but that is a
workaround for the issue. The hang can always be reproduced under this
test:

 - Start a QEMU VM, passing through the USB adapter
 - This VM boots to a busybox shell with no other services running or
   udev magic (to reduce interference).
 - Enable runtime PM for all devices by default (see script below)
 - From the console, invoke "ip link set eth1 up" (eth0 is a virtio
   adapter).

# somewhere in /init after mounting filesystems
echo /sbin/hotplug > /proc/sys/kernel/hotplug
echo auto | tee  /sys/bus/pci/devices/*/power/control \
/sys/bus/usb/devices/*/power/control >/dev/null

#!/bin/sh
# /sbin/hotplug
path="/sys/$DEVPATH/power/control"
[ -e "$path" ] || return
newval=auto
read status < "$path"
if [ "x$status" != "x$newval" ]; then
echo "$DEVPATH: $status -> $newval" >/dev/kmsg
echo $newval > "$path"
fi

With "auto", the ip command hangs (a trace can be found on the bottom of
this mail). With "on", it does not.

If I keep a loop spinning that invokes `ethtool eth1`, the command
returns immediately without issues (presumably because the device is not
suspended through runtime PM).

Under some circumstances I get a lockdep warning (when trying to bring
an interface down if I remember correctly). Its trace can be found on
the bottom of this mail.

I'll keep testing. For the lockdep warning, my initial guess is that
calling schedule_delayed_work_sync under tp->lock is a bad idea because
scheduled work can execute and try to claim tp->lock too.

Maybe there are two different lockup cases here, I'll keep testing.

Kind regards,
Peter

> On 12/05/2015 06:59 PM, Peter Wu wrote:
> > Hi,
> >
> > I rarely use a Realtek USB 3.0 Gigabit Ethernet adapter (vid/pid
> > 0bda:8153), but when I did last night, it resulted in a lockup of
> > processes doing networking ("ip link", "ping", "ethtool", ...).
> >
> > A (few) minute(s) before that event, I noticed that there was no network
> > connectivity (ping hung) which was somehow solved by invoking "ethtool
> > eth1" (triggering runtime pm wakeup?). This same trick did not work at
> > the next event. Invoking "ethtool eth1", "ip link", etc. hung completely
> > and interrupt (^C) did not work at all.
> >
> > Since that did not work, I pulled the USB adapter and re-inserted it,
> > hoping it would reset things. That did not work at all, there was a
> > "usb disconnect" message, but no further driver messages.
> >
> > Fast forward an hour, and it has become a disaster. I have terminated
> > and killed many programs via SysRq but am still unable to get a stable
> > system that does not hang on network I/O. Even the suspend process
> > fails so in the end I attempted to shutdown the system. After half an
> > hour after getting the poweroff message, I issued SysRq + B to reboot
> > (since SysRq + O did not shut down either).
> >
> > Attached are logs with various various backtraces from SysRq and failed
> > suspend. Let me know if you need more information!
> >
> > By the way, often I have to rmmod xhci and re-insert it, otherwise
> > plugging it in does not result in a detection. A USB 2.0 port does not
> > have this problem (runtime PM is enabled for all devices). This is the
> > USB 3.0 port:
> >
> > 02:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0
> > Host Controller [1033:0194] (rev 03)
> 

-- 

lockdep splat from the bare machine:

==
[ INFO: possible circular locking dependency detected ]
4.3.0-custom #1 Tainted: G   O   
---
kworker/0:1/38 is trying to acquire lock:
 (&tp->control){+.+.+.}, at: [] rtl8152_resume+0x24/0x130 
[r8152]

but task is already holding lock:
 ((&(&tp->schedule)->work)){+.+.+.}, at: [] 
process_one_work+0x15c/0x660

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 ((&(&tp->schedule)->work)){+.+.+.}:

[] lock_acquire+0xc3/0x1d0
   [] flush_work+0x3d/0x290
   [] __cancel_work_timer+0xfe/0x1c0
   [] cancel_delayed_work_sync+0x13/0x20
   [] rtl8152_set_speed+0x2a/0x260 [r8152]
   [] rtl8152_open+0x396/0x4f0 [r8152]
   [] __dev_open+0xaf/0x120
   [] __dev_change_flags+0x9d/0x160
   [] dev_change_flags+0x29/0x70
   [] do_setlink+0x5ba/0xb00
   [] rtnl_newlink+0x5a9/0x8a0
   [] rtnetlink_rcv_msg+0x84/0x210
   [] netlink_rcv_skb+0x97/0xb0

Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case

[Gregory CLEMENT]

Hi Felipe,

I am going back on this subject (again :) )
 
 On mar., oct. 20 2015, Gregory CLEMENT  
wrote:

> Hi Felipe,
>  
>  On lun., oct. 05 2015, Felipe Balbi  wrote:
>
>
>>> So after many tests on different devices, 200ms is enough for most of
>>> them, but for one, 2000ms (2s) was needed!
>>>
>>> I see several option:
>>> - adding a sysfs entry to setup the time
>>> - adding a debugs entry entry
>>> - adding configuration option in menuconfig
>>> - using 2000ms and hopping it was enough for everyone
>>>
>>> My preference would go to the first option, what is your opinion?
>>
>> I'm not sure if either of them is good. man 2s is just too large. If the

Well 2s is lon I agree, but currently instead of 2s we have an infinite
wait, which is worse!

>> device isn't following the specification, I'm afraid that device needs
>> to be fixed.

I agree but these devices are for most of them USB stick that we find in
retail. We have no influence on them, so we have to do with them, even
if they do not follow the sepc.

So what about using configfs or sysfs to let the user confgiure this
value if needed?

I go back on this because, your suggestion didn't work. At least, I
didn't manage to make it improve the situation.

Thanks,

>>
>> I think the real issue here is the lack of a disconnect IRQ from AM335x
>> devices. But here's something I've been meaning to test but never had
>> time. If you look into AM335x address space, there's a bit in the
>> wrapper which tells it to use the standard MUSB registers for IRQ,
>> instead of the TI-specific thing. Can you see if we get a disconnect IRQ
>> with that ?
>>
>> TRM is at [1], see page 2566. Basically, if you set bit 3 in register
>> offset 0x1014, then it should use Mentor IRQ registers. If that works,
>> quite a few problems will actually vanish :-p
>
> So I tried it with the following patch:
>
> -
> diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
> index c791ba5..c714500 100644
> --- a/drivers/usb/musb/musb_dsps.c
> +++ b/drivers/usb/musb/musb_dsps.c
> @@ -470,6 +470,7 @@ static int dsps_musb_init(struct musb *musb)
>  
> /* Reset the musb */
> dsps_writel(reg_base, wrp->control, (1 << wrp->reset));
> +   dsps_writel(musb->ctrl_base, wrp->control, BIT(3));
>  
> musb->isr = dsps_interrupt;
>  
> @@ -625,6 +626,7 @@ static int dsps_musb_reset(struct musb *musb)
> if (session_restart || !glue->sw_babble_enabled) {
> dev_info(musb->controller, "Restarting MUSB to recover from 
> Babble\n");
> dsps_writel(musb->ctrl_base, wrp->control, (1 << wrp->reset));
> +   dsps_writel(musb->ctrl_base, wrp->control, BIT(3));
> usleep_range(100, 200);
> usb_phy_shutdown(musb->xceiv);
> usleep_range(100, 200);
> 
>
> I am not very familiar with that driver but my understanding was that
> the Mentor IRQ registeres are managed by the musb_interrupt() function
> which is called from the dsps_interrupt() interrupt handler.
>
> Am I right?
>
> if it is the case then it didn't fix the issue I had.
>
> I activated the following debug line:
>
> [musb_hdrc]musb_interrupt =_ "** IRQ %s usb%04x tx%04x rx%04x\012"
> [musb_dsps]dsps_interrupt =p "usbintr (%x) epintr(%x)\012"
>
> But I didn't get any interrupt while disconnecting the cable without any
> device connected on it (whereas I got an interrupt when I connected it).
>
> Note that I applied this patch instead of the "usb: musb: dsps: handle
> the otg_state_a_wait_vrise_timeout case", is what you had in mind ?
>
> Gregory
>
>>
>> [1] http://www.ti.com/lit/ug/spruh73l/spruh73l.pdf
>>
>> -- 
>> balbi
>
> -- 
> Gregory Clement, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] usb: xhci: replace dma_pool_alloc and memset with dma_pool_zalloc

[Peter Senna Tschudin]

On Wed, Dec 2, 2015 at 9:43 PM, Geyslan G. Bem  wrote:
> Replace dma_pool_alloc and memset with a single call to dma_pool_zalloc.
>
> Caught by coccinelle.
I would mention which script was used, but other than that:
Acked-by: Peter Senna Tschudin 

>
> Signed-off-by: Geyslan G. Bem 
> ---
>  drivers/usb/host/xhci-mem.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
> index c48cbe7..d034f92 100644
> --- a/drivers/usb/host/xhci-mem.c
> +++ b/drivers/usb/host/xhci-mem.c
> @@ -47,13 +47,12 @@ static struct xhci_segment *xhci_segment_alloc(struct 
> xhci_hcd *xhci,
> if (!seg)
> return NULL;
>
> -   seg->trbs = dma_pool_alloc(xhci->segment_pool, flags, &dma);
> +   seg->trbs = dma_pool_zalloc(xhci->segment_pool, flags, &dma);
> if (!seg->trbs) {
> kfree(seg);
> return NULL;
> }
>
> -   memset(seg->trbs, 0, TRB_SEGMENT_SIZE);
> /* If the cycle state is 0, set the cycle bit to 1 for all the TRBs */
> if (cycle_state == 0) {
> for (i = 0; i < TRBS_PER_SEGMENT; i++)
> @@ -517,12 +516,12 @@ static struct xhci_container_ctx 
> *xhci_alloc_container_ctx(struct xhci_hcd *xhci
> if (type == XHCI_CTX_TYPE_INPUT)
> ctx->size += CTX_SIZE(xhci->hcc_params);
>
> -   ctx->bytes = dma_pool_alloc(xhci->device_pool, flags, &ctx->dma);
> +   ctx->bytes = dma_pool_zalloc(xhci->device_pool, flags, &ctx->dma);
> if (!ctx->bytes) {
> kfree(ctx);
> return NULL;
> }
> -   memset(ctx->bytes, 0, ctx->size);
> +
> return ctx;
>  }
>
> --
> 2.6.2
>



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

Re: [PATCH] usb: whci: fhci: remove comparison to bool

[Peter Senna Tschudin]

On Wed, Dec 2, 2015 at 10:45 PM, Geyslan G. Bem  wrote:
> Get rid of bool explicit comparisons.
>
> Caught by Coccinelle.
I would mention the path to the .cocci script, but other than that:
Acked-by: Peter Senna Tschudin 

>
> Signed-off-by: Geyslan G. Bem 
> ---
>  drivers/usb/host/fhci-tds.c  | 2 +-
>  drivers/usb/host/whci/qset.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/host/fhci-tds.c b/drivers/usb/host/fhci-tds.c
> index 1498061..f82ad5d 100644
> --- a/drivers/usb/host/fhci-tds.c
> +++ b/drivers/usb/host/fhci-tds.c
> @@ -85,7 +85,7 @@ static struct usb_td __iomem *next_bd(struct usb_td __iomem 
> *base,
>
>  void fhci_push_dummy_bd(struct endpoint *ep)
>  {
> -   if (ep->already_pushed_dummy_bd == false) {
> +   if (!ep->already_pushed_dummy_bd) {
> u16 td_status = in_be16(&ep->empty_td->status);
>
> out_be32(&ep->empty_td->buf_ptr, DUMMY_BD_BUFFER);
> diff --git a/drivers/usb/host/whci/qset.c b/drivers/usb/host/whci/qset.c
> index 3297473..5e48a60 100644
> --- a/drivers/usb/host/whci/qset.c
> +++ b/drivers/usb/host/whci/qset.c
> @@ -395,7 +395,7 @@ static void urb_dequeue_work(struct work_struct *work)
> struct whc *whc = qset->whc;
> unsigned long flags;
>
> -   if (wurb->is_async == true)
> +   if (wurb->is_async)
> asl_update(whc, WUSBCMD_ASYNC_UPDATED
>| WUSBCMD_ASYNC_SYNCED_DB
>| WUSBCMD_ASYNC_QSET_RM);
> --
> 2.6.3
>



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

Re: [PATCH] usb: use BUG_ON() instead of BUG()

[Peter Senna Tschudin]

On Wed, Dec 2, 2015 at 11:18 PM, Geyslan G. Bem  wrote:
> Replace BUG() with BUG_ON().
>
> Caught by coccinelle.
I would mention the path to the .cocci script, but other than that:
Acked-by: Peter Senna Tschudin 

>
> Signed-off-by: Geyslan G. Bem 
> ---
>  drivers/usb/host/oxu210hp-hcd.c | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/host/oxu210hp-hcd.c b/drivers/usb/host/oxu210hp-hcd.c
> index 1f139d8..bc74aca 100644
> --- a/drivers/usb/host/oxu210hp-hcd.c
> +++ b/drivers/usb/host/oxu210hp-hcd.c
> @@ -394,8 +394,7 @@ static void ehci_quiesce(struct oxu_hcd *oxu)
> u32 temp;
>
>  #ifdef DEBUG
> -   if (!HC_IS_RUNNING(oxu_to_hcd(oxu)->state))
> -   BUG();
> +   BUG_ON(!HC_IS_RUNNING(oxu_to_hcd(oxu)->state));
>  #endif
>
> /* wait for any schedule enables/disables to take effect */
> @@ -1709,9 +1708,8 @@ static void start_unlink_async(struct oxu_hcd *oxu, 
> struct ehci_qh *qh)
>
>  #ifdef DEBUG
> assert_spin_locked(&oxu->lock);
> -   if (oxu->reclaim || (qh->qh_state != QH_STATE_LINKED
> -   && qh->qh_state != QH_STATE_UNLINK_WAIT))
> -   BUG();
> +   BUG_ON(oxu->reclaim || (qh->qh_state != QH_STATE_LINKED
> +   && qh->qh_state != QH_STATE_UNLINK_WAIT));
>  #endif
>
> /* stop async schedule right now? */
> --
> 2.6.3
>



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

Re: [PATCH] usb: ehci: ohci: fix bool assignments

[Peter Senna Tschudin]

On Thu, Dec 3, 2015 at 12:25 AM, Geyslan G. Bem  wrote:
> When assigning bool use true instead of 1. If declaring it as static and
> it's false there's no need to initialize it, since static variables are
> zeroed by default.
>
> Caught by coccinelle.
>
> Signed-off-by: Geyslan G. Bem 
Acked-by: Peter Senna Tschudin 

> ---
>  drivers/usb/host/ehci-hcd.c | 2 +-
>  drivers/usb/host/ohci-hcd.c | 4 ++--
>  drivers/usb/host/u132-hcd.c | 2 +-
>  3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
> index 48c92bf..1b01967 100644
> --- a/drivers/usb/host/ehci-hcd.c
> +++ b/drivers/usb/host/ehci-hcd.c
> @@ -98,7 +98,7 @@ module_param (park, uint, S_IRUGO);
>  MODULE_PARM_DESC (park, "park setting; 1-3 back-to-back async packets");
>
>  /* for flakey hardware, ignore overcurrent indicators */
> -static bool ignore_oc = 0;
> +static bool ignore_oc;
>  module_param (ignore_oc, bool, S_IRUGO);
>  MODULE_PARM_DESC (ignore_oc, "ignore bogus hardware overcurrent 
> indications");
>
> diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
> index 760cb57..5547dbf 100644
> --- a/drivers/usb/host/ohci-hcd.c
> +++ b/drivers/usb/host/ohci-hcd.c
> @@ -99,13 +99,13 @@ static void io_watchdog_func(unsigned long _ohci);
>
>
>  /* Some boards misreport power switching/overcurrent */
> -static bool distrust_firmware = 1;
> +static bool distrust_firmware = true;
>  module_param (distrust_firmware, bool, 0);
>  MODULE_PARM_DESC (distrust_firmware,
> "true to distrust firmware power/overcurrent setup");
>
>  /* Some boards leave IR set wrongly, since they fail BIOS/SMM handshakes */
> -static bool no_handshake = 0;
> +static bool no_handshake;
>  module_param (no_handshake, bool, 0);
>  MODULE_PARM_DESC (no_handshake, "true (not default) disables BIOS 
> handshake");
>
> diff --git a/drivers/usb/host/u132-hcd.c b/drivers/usb/host/u132-hcd.c
> index 692ccc6..05c85c7 100644
> --- a/drivers/usb/host/u132-hcd.c
> +++ b/drivers/usb/host/u132-hcd.c
> @@ -73,7 +73,7 @@ MODULE_LICENSE("GPL");
>  #define INT_MODULE_PARM(n, v) static int n = v;module_param(n, int, 0444)
>  INT_MODULE_PARM(testing, 0);
>  /* Some boards misreport power switching/overcurrent*/
> -static bool distrust_firmware = 1;
> +static bool distrust_firmware = true;
>  module_param(distrust_firmware, bool, 0);
>  MODULE_PARM_DESC(distrust_firmware, "true to distrust firmware 
> power/overcurren"
> "t setup");
> --
> 2.6.3
>



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

Re: [PATCH] usb: host: iounmap before return

[Geyslan G. Bem]

2015-12-07 6:30 GMT-03:00 Lu Baolu :
>
>
> On 12/06/2015 09:47 PM, Geyslan G. Bem wrote:
>> This patch fixes a 'quirk_usb_handoff_xhci()' branch return that was not 
>> unmapping correctly.
>>
>> Coccinelle: scripts/coccinelle/free/iounmap.cocci
>>
>> Signed-off-by: Geyslan G. Bem 
>> ---
>>  drivers/usb/host/pci-quirks.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
>> index f940056..64150dd 100644
>> --- a/drivers/usb/host/pci-quirks.c
>> +++ b/drivers/usb/host/pci-quirks.c
>> @@ -990,7 +990,7 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
>>   /* We're reading garbage from the controller */
>>   dev_warn(&pdev->dev,
>>"xHCI controller failing to respond");
>> - return;
>> + goto out;
>
> If "out" is only used here, why not iounmap and return directly here?
Could be directly. I just think that code recurrence can make things
complicated in future. What do you think?

Ah, seems that this patch is not aligned with linux-next. I'll make a
new one soon.

>
>>   }
>>
>>   if (!ext_cap_offset)
>> @@ -1062,6 +1062,7 @@ hc_init:
>>XHCI_MAX_HALT_USEC, val);
>>   }
>>
>> +out:
>>   iounmap(base);
>>  }
>>
>



-- 
Regards,

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

[PATCH] usb: dwc2: gadget: don't overwrite DCTL register on NAKEFF interrupts

[Gregory Herrero]

When receiving GINTSTS_GINNAKEFF or GINTSTS_GOUTNAKEFF interrupt,
DCTL will be overwritten with DCTL_CGOUTNAK or DCTL_CGNPINNAK values.
Instead of overwriting it, write only needed bits.

It could cause an issue if GINTSTS_GINNAKEFF or GINTSTS_GOUTNAKEFF
interrupt is received after dwc2 disabled pullup by writing
DCTL_SFTDISCON bit.
Pullup will then be re-enabled whereas it should not.

Signed-off-by: Gregory Herrero 
---
 drivers/usb/dwc2/gadget.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 0abf73c..311ce49 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2585,7 +2585,7 @@ irq_retry:
if (gintsts & GINTSTS_GOUTNAKEFF) {
dev_info(hsotg->dev, "GOUTNakEff triggered\n");
 
-   dwc2_writel(DCTL_CGOUTNAK, hsotg->regs + DCTL);
+   __orr32(hsotg->regs + DCTL, DCTL_CGOUTNAK);
 
dwc2_hsotg_dump(hsotg);
}
@@ -2593,7 +2593,7 @@ irq_retry:
if (gintsts & GINTSTS_GINNAKEFF) {
dev_info(hsotg->dev, "GINNakEff triggered\n");
 
-   dwc2_writel(DCTL_CGNPINNAK, hsotg->regs + DCTL);
+   __orr32(hsotg->regs + DCTL, DCTL_CGNPINNAK);
 
dwc2_hsotg_dump(hsotg);
}
-- 
2.6.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: (4.3.0) r8152: deadlock related to runtime suspend?

[Lu Baolu]

On 12/07/2015 05:37 PM, Peter Wu wrote:
> On Mon, Dec 07, 2015 at 05:11:50PM +0800, Lu Baolu wrote:
>> Hi Peter,
>>
>> Have you ever tried disabling auto-pm? Did things go smoothly if auto-pm is 
>> disabled?
>>
>> I always disable usb auto-pm in below way.
>>
>> # echo on | tee /sys/bus/usb/devices/*/power/control
>> # echo on > /sys/bus/pci/devices//power/control
>>
>> Thanks,
>> Baolu
> Hi Baolu,
>
> The deadlock does not seem to occur with auto-PM disabled, but that is a
> workaround for the issue. The hang can always be reproduced under this
> test:
>
>  - Start a QEMU VM, passing through the USB adapter

I would suggest you to start with bare metal.

When you pass through the host controller to a guest VM, you
probably use IOMMU unit to let hardware access the memory
directly, but things like pci configure space access, interrupt and
IO port access still rely on QEMU. This introduces a lot of complexities.

Thanks,
Baolu

>  - This VM boots to a busybox shell with no other services running or
>udev magic (to reduce interference).
>  - Enable runtime PM for all devices by default (see script below)
>  - From the console, invoke "ip link set eth1 up" (eth0 is a virtio
>adapter).
>
> # somewhere in /init after mounting filesystems
> echo /sbin/hotplug > /proc/sys/kernel/hotplug
> echo auto | tee  /sys/bus/pci/devices/*/power/control \
> /sys/bus/usb/devices/*/power/control >/dev/null
>
> #!/bin/sh
> # /sbin/hotplug
> path="/sys/$DEVPATH/power/control"
> [ -e "$path" ] || return
> newval=auto
> read status < "$path"
> if [ "x$status" != "x$newval" ]; then
> echo "$DEVPATH: $status -> $newval" >/dev/kmsg
> echo $newval > "$path"
> fi
>
> With "auto", the ip command hangs (a trace can be found on the bottom of
> this mail). With "on", it does not.
>
> If I keep a loop spinning that invokes `ethtool eth1`, the command
> returns immediately without issues (presumably because the device is not
> suspended through runtime PM).
>
> Under some circumstances I get a lockdep warning (when trying to bring
> an interface down if I remember correctly). Its trace can be found on
> the bottom of this mail.
>
> I'll keep testing. For the lockdep warning, my initial guess is that
> calling schedule_delayed_work_sync under tp->lock is a bad idea because
> scheduled work can execute and try to claim tp->lock too.
>
> Maybe there are two different lockup cases here, I'll keep testing.
>
> Kind regards,
> Peter
>
>> On 12/05/2015 06:59 PM, Peter Wu wrote:
>>> Hi,
>>>
>>> I rarely use a Realtek USB 3.0 Gigabit Ethernet adapter (vid/pid
>>> 0bda:8153), but when I did last night, it resulted in a lockup of
>>> processes doing networking ("ip link", "ping", "ethtool", ...).
>>>
>>> A (few) minute(s) before that event, I noticed that there was no network
>>> connectivity (ping hung) which was somehow solved by invoking "ethtool
>>> eth1" (triggering runtime pm wakeup?). This same trick did not work at
>>> the next event. Invoking "ethtool eth1", "ip link", etc. hung completely
>>> and interrupt (^C) did not work at all.
>>>
>>> Since that did not work, I pulled the USB adapter and re-inserted it,
>>> hoping it would reset things. That did not work at all, there was a
>>> "usb disconnect" message, but no further driver messages.
>>>
>>> Fast forward an hour, and it has become a disaster. I have terminated
>>> and killed many programs via SysRq but am still unable to get a stable
>>> system that does not hang on network I/O. Even the suspend process
>>> fails so in the end I attempted to shutdown the system. After half an
>>> hour after getting the poweroff message, I issued SysRq + B to reboot
>>> (since SysRq + O did not shut down either).
>>>
>>> Attached are logs with various various backtraces from SysRq and failed
>>> suspend. Let me know if you need more information!
>>>
>>> By the way, often I have to rmmod xhci and re-insert it, otherwise
>>> plugging it in does not result in a detection. A USB 2.0 port does not
>>> have this problem (runtime PM is enabled for all devices). This is the
>>> USB 3.0 port:
>>>
>>> 02:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0
>>> Host Controller [1033:0194] (rev 03)

--
To unsubscribe from this list: send the line "unsubscribe 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: (4.3.0) r8152: deadlock related to runtime suspend?

[Peter Wu]

On Mon, Dec 07, 2015 at 07:08:50PM +0800, Lu Baolu wrote:
> 
> 
> On 12/07/2015 05:37 PM, Peter Wu wrote:
> > On Mon, Dec 07, 2015 at 05:11:50PM +0800, Lu Baolu wrote:
> >> Hi Peter,
> >>
> >> Have you ever tried disabling auto-pm? Did things go smoothly if auto-pm 
> >> is disabled?
> >>
> >> I always disable usb auto-pm in below way.
> >>
> >> # echo on | tee /sys/bus/usb/devices/*/power/control
> >> # echo on > /sys/bus/pci/devices//power/control
> >>
> >> Thanks,
> >> Baolu
> > Hi Baolu,
> >
> > The deadlock does not seem to occur with auto-PM disabled, but that is a
> > workaround for the issue. The hang can always be reproduced under this
> > test:
> >
> >  - Start a QEMU VM, passing through the USB adapter
> 
> I would suggest you to start with bare metal.
> 
> When you pass through the host controller to a guest VM, you
> probably use IOMMU unit to let hardware access the memory
> directly, but things like pci configure space access, interrupt and
> IO port access still rely on QEMU. This introduces a lot of complexities.

It is a USB device, not a PCI device, so such issues do not apply here
I think.

I have found a possible reason for this lockup. The resume code may
execute napi_disable while napi_enable was not called before. This
autoresume thing happens in the open function which explains why all
other rtnl users are blocked.

Is this a sane analysis?

Kind regards,
Peter

> Thanks,
> Baolu
> 
> >  - This VM boots to a busybox shell with no other services running or
> >udev magic (to reduce interference).
> >  - Enable runtime PM for all devices by default (see script below)
> >  - From the console, invoke "ip link set eth1 up" (eth0 is a virtio
> >adapter).
> >
> > # somewhere in /init after mounting filesystems
> > echo /sbin/hotplug > /proc/sys/kernel/hotplug
> > echo auto | tee  /sys/bus/pci/devices/*/power/control \
> > /sys/bus/usb/devices/*/power/control >/dev/null
> >
> > #!/bin/sh
> > # /sbin/hotplug
> > path="/sys/$DEVPATH/power/control"
> > [ -e "$path" ] || return
> > newval=auto
> > read status < "$path"
> > if [ "x$status" != "x$newval" ]; then
> > echo "$DEVPATH: $status -> $newval" >/dev/kmsg
> > echo $newval > "$path"
> > fi
> >
> > With "auto", the ip command hangs (a trace can be found on the bottom of
> > this mail). With "on", it does not.
> >
> > If I keep a loop spinning that invokes `ethtool eth1`, the command
> > returns immediately without issues (presumably because the device is not
> > suspended through runtime PM).
> >
> > Under some circumstances I get a lockdep warning (when trying to bring
> > an interface down if I remember correctly). Its trace can be found on
> > the bottom of this mail.
> >
> > I'll keep testing. For the lockdep warning, my initial guess is that
> > calling schedule_delayed_work_sync under tp->lock is a bad idea because
> > scheduled work can execute and try to claim tp->lock too.
> >
> > Maybe there are two different lockup cases here, I'll keep testing.
> >
> > Kind regards,
> > Peter
> >
> >> On 12/05/2015 06:59 PM, Peter Wu wrote:
> >>> Hi,
> >>>
> >>> I rarely use a Realtek USB 3.0 Gigabit Ethernet adapter (vid/pid
> >>> 0bda:8153), but when I did last night, it resulted in a lockup of
> >>> processes doing networking ("ip link", "ping", "ethtool", ...).
> >>>
> >>> A (few) minute(s) before that event, I noticed that there was no network
> >>> connectivity (ping hung) which was somehow solved by invoking "ethtool
> >>> eth1" (triggering runtime pm wakeup?). This same trick did not work at
> >>> the next event. Invoking "ethtool eth1", "ip link", etc. hung completely
> >>> and interrupt (^C) did not work at all.
> >>>
> >>> Since that did not work, I pulled the USB adapter and re-inserted it,
> >>> hoping it would reset things. That did not work at all, there was a
> >>> "usb disconnect" message, but no further driver messages.
> >>>
> >>> Fast forward an hour, and it has become a disaster. I have terminated
> >>> and killed many programs via SysRq but am still unable to get a stable
> >>> system that does not hang on network I/O. Even the suspend process
> >>> fails so in the end I attempted to shutdown the system. After half an
> >>> hour after getting the poweroff message, I issued SysRq + B to reboot
> >>> (since SysRq + O did not shut down either).
> >>>
> >>> Attached are logs with various various backtraces from SysRq and failed
> >>> suspend. Let me know if you need more information!
> >>>
> >>> By the way, often I have to rmmod xhci and re-insert it, otherwise
> >>> plugging it in does not result in a detection. A USB 2.0 port does not
> >>> have this problem (runtime PM is enabled for all devices). This is the
> >>> USB 3.0 port:
> >>>
> >>> 02:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0
> >>> Host Controller [1033:0194] (rev 03)
> 

-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
--
To unsubscribe from this list: send the li

Re: [PATCH] usb: host: iounmap before return

[Sergei Shtylyov]

Hello.

On 12/07/2015 12:30 PM, Lu Baolu wrote:


This patch fixes a 'quirk_usb_handoff_xhci()' branch return that was not 
unmapping correctly.

Coccinelle: scripts/coccinelle/free/iounmap.cocci

Signed-off-by: Geyslan G. Bem 
---
  drivers/usb/host/pci-quirks.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index f940056..64150dd 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -990,7 +990,7 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
/* We're reading garbage from the controller */
dev_warn(&pdev->dev,
 "xHCI controller failing to respond");
-   return;
+   goto out;


If "out" is only used here, why not iounmap and return directly here?


   Why repeat the code? Nah, bad idea.


}

if (!ext_cap_offset)
@@ -1062,6 +1062,7 @@ hc_init:
 XHCI_MAX_HALT_USEC, val);
}

+out:
iounmap(base);
  }



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: [PATCHv2 1/2] extcon: add driver for Intel USB mux

[Heikki Krogerus]

Hi,

On Mon, Dec 07, 2015 at 10:24:22AM +0900, Chanwoo Choi wrote:
> Hi,
> 
> On 2015년 12월 04일 17:51, Heikki Krogerus wrote:
> > Hi,
> > 
> >> I do never want to add some specific funtcion for only this driver.
> >> I think is not appropriate way.
> >> - intel_usb_mux_unregister
> >> - intel_usb_mux_register
> >>
> >> The client driver using extcon driver should use the standard extcon API
> >> for code consistency. Also, I'll do the more detailed review for this 
> >> patch.
> > 
> > The internal mux we are controlling here is physically separate
> > device. Ideally we could populate child device for it, but since that
> > is not possible because of the resource conflict, we use the library
> > approach, which is really not that uncommon.
> 
> New added functions for only specific device driver is not library. 
> 
> The all device drivers which is included in some framework should
> connect to the other device driver through only framework API as following:
>     
>   | EXTCON framework |<>| USB framework |
>     - 
>   ||
>   ||
>   extcon-intel-usb.c pci-quirks.c
> 
> But, in this case, added funticon is just direct call function
> without any standard API. The below case is never appropriate implementation.
> 
>     
>   | EXTCON framework |  | USB framework |
>     - 
>   ||
>   ||
>   extcon-intel-usb.c <  pci-quirks.c

Man.. Cal it what you want, but like I said, exposing driver specific
API is not ideal, but it is acceptable in special cases like this
where we simply are not able to populate child device. If nothing
else, then at least the fact that the code for the mux would otherwise
need to be duplicated, is enough to justify it.

> > I don't think I agree with your point even at general level. The
> > control required to handle this mux, even though simple, is enough to
> > deserve to be separated from xHCI code. xHCI should not need to care
> > about anything else expect does it have the mux, i.e. does it need to
> > register it or not. It should not need to care about how it needs to
> > be controlled or even what it is. We may decide to create something
> > else out of it instead of an extcon device later.
> > 
> > But in any case, the mux is available on all new Intel platforms, but
> > it needs to be controlled by OS only in few "special" cases. We can
> > not force xHCI (or pci-quirks.c to be more precise) to be aware of
> > these "special" cases. The only way to make it work like that would
> > bet by using ifdefs, and we really really don't want that.
> > 
> > And please also note that, though for now we only expect the mux
> > control registers to be part of xHCI MMIO, that is not always the
> > case. The control registers are part of the device controller MMIO on
> > some platforms. We do not want to duplicate the whole control of the
> > mux if/when we need the OS to be in control of it on a platform that
> > has those control registers mapped somewhere else then xHCI MMIO,
> > 
> > So I would say that we have pretty good justification for separating
> > the mux control, which means unfortunately custom API in this case.
> > 
> > But if you would prefer that we put the files somewhere else then
> > drivers/extcon/ and include/linux/extcon/ I'm fine with that. If you
> > like, we can put it to drivers/usb/host/ as that is where
> > pci-quirks.c is. That way I think we can also put the header to
> > include/usb/.
> 
> There are the two type of extcon drivers as following:
> - provider extcon driver which use the devm_extcon_dev_register() and 
> extcon_set_cable_state().
> - client extcon driver which use the extcon_register_notifier() and 
> extcon_set_cable_state() usually.
> The drivers/extcon directory only includes the provider extcon driver.
> 
> You make the extcon-intel-usb.c as provider extcon driver.
> At the same time, this driver is used for client extcon driver
> by using the extcon_register_notifier(). If you want to recevie
> the notification from extcon_register_notifier(), the extcon device
> should update the state of external connector throught 
> extcon_set_cable_state().
> But, this driver don' use the extcon_set_cable_state().
> 
> I think that you should divide it according to role.
> 
> Again, the usage case of extcon have to consist of both provider extcon driver
> and client extcon driver. If there is no provider extcon driver,
> client extcon driver don't receive the any notification of external connector
> from provider extcon driver.

What you are saying is that it is OK for both "client" and "provider"
to change the state, but only client is allowed to react t

[PATCH v2 7/7] usb: xhci: plat: add vbus regulator control

[Jisheng Zhang]

The Marvell BG4CT STB board has board level vbus control through gpio.
This patch adds the vbus regulator control to support this board.

Signed-off-by: Jisheng Zhang 
---
 drivers/usb/host/xhci-plat.c | 39 ++-
 drivers/usb/host/xhci.h  |  2 ++
 2 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index bb972a6..c03e8d5 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -116,6 +117,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
struct clk  *clk;
struct usb_phy  *usb_phy;
struct phy  *phy;
+   struct regulator*vbus;
int ret;
int irq;
 
@@ -179,14 +181,31 @@ static int xhci_plat_probe(struct platform_device *pdev)
 
device_wakeup_enable(hcd->self.controller);
 
+   vbus = devm_regulator_get(&pdev->dev, "vbus");
+   if (PTR_ERR(vbus) == -ENODEV) {
+   vbus = NULL;
+   } else if (IS_ERR(vbus)) {
+   ret = PTR_ERR(vbus);
+   goto disable_clk;
+   } else if (vbus) {
+   ret = regulator_enable(vbus);
+   if (ret) {
+   dev_err(&pdev->dev,
+   "failed to enable usb vbus regulator: %d\n",
+   ret);
+   goto disable_clk;
+   }
+   }
+
xhci = hcd_to_xhci(hcd);
xhci->clk = clk;
+   xhci->vbus = vbus;
xhci->main_hcd = hcd;
xhci->shared_hcd = usb_create_shared_hcd(driver, &pdev->dev,
dev_name(&pdev->dev), hcd);
if (!xhci->shared_hcd) {
ret = -ENOMEM;
-   goto disable_clk;
+   goto disable_vbus;
}
 
if ((node && of_property_read_bool(node, "usb3-lpm-capable")) ||
@@ -254,6 +273,10 @@ disable_usb2_phy:
 put_usb3_hcd:
usb_put_hcd(xhci->shared_hcd);
 
+disable_vbus:
+   if (vbus)
+   regulator_disable(vbus);
+
 disable_clk:
clk_disable_unprepare(clk);
 
@@ -268,6 +291,7 @@ static int xhci_plat_remove(struct platform_device *dev)
struct usb_hcd  *hcd = platform_get_drvdata(dev);
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct clk *clk = xhci->clk;
+   struct regulator *vbus = xhci->vbus;
 
usb_remove_hcd(xhci->shared_hcd);
xhci_plat_phy_exit(xhci->shared_hcd);
@@ -278,6 +302,9 @@ static int xhci_plat_remove(struct platform_device *dev)
clk_disable_unprepare(clk);
usb_put_hcd(hcd);
 
+   if (vbus)
+   regulator_disable(vbus);
+
return 0;
 }
 
@@ -287,6 +314,7 @@ static int xhci_plat_suspend(struct device *dev)
int ret;
struct usb_hcd  *hcd = dev_get_drvdata(dev);
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+   struct regulator *vbus = xhci->vbus;
 
/*
 * xhci_suspend() needs `do_wakeup` to know whether host is allowed
@@ -303,6 +331,8 @@ static int xhci_plat_suspend(struct device *dev)
xhci_plat_phy_exit(xhci->shared_hcd);
xhci_plat_phy_exit(hcd);
clk_disable_unprepare(xhci->clk);
+   if (vbus)
+   ret = regulator_disable(vbus);
 
return ret;
 }
@@ -312,11 +342,18 @@ static int xhci_plat_resume(struct device *dev)
int ret;
struct usb_hcd  *hcd = dev_get_drvdata(dev);
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+   struct regulator *vbus = xhci->vbus;
 
ret = clk_prepare_enable(xhci->clk);
if (ret)
return ret;
 
+   if (vbus) {
+   ret = regulator_enable(vbus);
+   if (ret)
+   return ret;
+   }
+
ret = xhci_plat_phy_init(hcd);
if (ret)
return ret;
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 0b94512..1355d2a 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1541,6 +1541,8 @@ struct xhci_hcd {
struct msix_entry   *msix_entries;
/* optional clock */
struct clk  *clk;
+   /* optional regulator */
+   struct regulator*vbus;
/* data structures */
struct xhci_device_context_array *dcbaa;
struct xhci_ring*cmd_ring;
-- 
2.6.2

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

[PATCH v2 0/7] usb: xhci-plat: support generic PHY and vbus regulator

[Jisheng Zhang]

The Marvell BG4CT has xhci controller. This controller has two phys:
one for usb2 and another for usb3. BG4CT boards have board level vbus
control through gpio.

I plan to add the xhci support in two steps: first of all, add generic
PHY and vbus regulator control support to the xhci-plat driver. Then
add the usb2 and usb3 phy drivers, after that, we add the phy and xhci
nodes in the dtsi.

This series takes the first step. The first three patches are bug fix.
Then two clean up patches. The last two patches add generic PHY and
vbus regulator control support.

Since v1:
 - fix NULL pointer dereference in [PATCH 7/7]

Jisheng Zhang (7):
  usb: xhci: plat: Fix suspend/resume when the optional clk exists
  usb: xhci: plat: attach the usb_phy to the correct hcd
  usb: xhci: plat: Fix suspend/resume when the optional usb_phy exists
  usb: xhci: plat: sort the headers in alphabetic order
  usb: xhci: plat: Remove checks for optional clock in error/remove path
  usb: xhci: plat: add generic PHY support
  usb: xhci: plat: add vbus regulator control

 drivers/usb/host/xhci-plat.c | 159 +--
 drivers/usb/host/xhci.h  |   2 +
 2 files changed, 140 insertions(+), 21 deletions(-)

-- 
2.6.2

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

[PATCH v2 2/7] usb: xhci: plat: attach the usb_phy to the correct hcd

[Jisheng Zhang]

Commit 7b8ef22ea547 ("usb: xhci: plat: Add USB phy support") adds the
usb_phy for usb3, but it attached the usb_phy to incorrect hcd. The
xhci->shared_hcd is the hcd for usb3, this patch fixes this issue
by attach the usb_phy to the xhci->shared_hcd.

Signed-off-by: Jisheng Zhang 
---
 drivers/usb/host/xhci-plat.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index b566304..a8c465a 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -82,6 +82,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
struct resource *res;
struct usb_hcd  *hcd;
struct clk  *clk;
+   struct usb_phy  *usb_phy;
int ret;
int irq;
 
@@ -162,17 +163,18 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
xhci->shared_hcd->can_do_streams = 1;
 
-   hcd->usb_phy = devm_usb_get_phy_by_phandle(&pdev->dev, "usb-phy", 0);
-   if (IS_ERR(hcd->usb_phy)) {
-   ret = PTR_ERR(hcd->usb_phy);
+   usb_phy = devm_usb_get_phy_by_phandle(&pdev->dev, "usb-phy", 0);
+   if (IS_ERR(usb_phy)) {
+   ret = PTR_ERR(usb_phy);
if (ret == -EPROBE_DEFER)
goto put_usb3_hcd;
-   hcd->usb_phy = NULL;
+   usb_phy = NULL;
} else {
-   ret = usb_phy_init(hcd->usb_phy);
+   ret = usb_phy_init(usb_phy);
if (ret)
goto put_usb3_hcd;
}
+   xhci->shared_hcd->usb_phy = usb_phy;
 
ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (ret)
@@ -189,7 +191,7 @@ dealloc_usb2_hcd:
usb_remove_hcd(hcd);
 
 disable_usb_phy:
-   usb_phy_shutdown(hcd->usb_phy);
+   usb_phy_shutdown(usb_phy);
 
 put_usb3_hcd:
usb_put_hcd(xhci->shared_hcd);
@@ -211,7 +213,7 @@ static int xhci_plat_remove(struct platform_device *dev)
struct clk *clk = xhci->clk;
 
usb_remove_hcd(xhci->shared_hcd);
-   usb_phy_shutdown(hcd->usb_phy);
+   usb_phy_shutdown(xhci->shared_hcd->usb_phy);
 
usb_remove_hcd(hcd);
usb_put_hcd(xhci->shared_hcd);
-- 
2.6.2

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

[PATCH v2 1/7] usb: xhci: plat: Fix suspend/resume when the optional clk exists

[Jisheng Zhang]

Commit 4718c1774051 ("usb: host: xhci-plat: add clock support") adds
optional clk support, but it forgets to prepare/disable and
enable/unprepare the clk in the resume/suspend path. This path fixes
this issue by adding missing clk related calls.

Signed-off-by: Jisheng Zhang 
Fixes: 4718c1774051 ("usb: host: xhci-plat: add clock support")
---
 drivers/usb/host/xhci-plat.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 05647e6..b566304 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -226,6 +226,7 @@ static int xhci_plat_remove(struct platform_device *dev)
 #ifdef CONFIG_PM_SLEEP
 static int xhci_plat_suspend(struct device *dev)
 {
+   int ret;
struct usb_hcd  *hcd = dev_get_drvdata(dev);
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
 
@@ -237,14 +238,25 @@ static int xhci_plat_suspend(struct device *dev)
 * reconsider this when xhci_plat_suspend enlarges its scope, e.g.,
 * also applies to runtime suspend.
 */
-   return xhci_suspend(xhci, device_may_wakeup(dev));
+   ret = xhci_suspend(xhci, device_may_wakeup(dev));
+   if (ret)
+   return ret;
+
+   clk_disable_unprepare(xhci->clk);
+
+   return ret;
 }
 
 static int xhci_plat_resume(struct device *dev)
 {
+   int ret;
struct usb_hcd  *hcd = dev_get_drvdata(dev);
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
 
+   ret = clk_prepare_enable(xhci->clk);
+   if (ret)
+   return ret;
+
return xhci_resume(xhci, 0);
 }
 
-- 
2.6.2

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

[PATCH v2 6/7] usb: xhci: plat: add generic PHY support

[Jisheng Zhang]

Marvell BG4CT SoC needs two phy: one for usb2 and another for usb3. Add
the calls to retrieve generic PHY to xhci plat in order to support this.

Signed-off-by: Jisheng Zhang 
---
 drivers/usb/host/xhci-plat.c | 87 ++--
 1 file changed, 75 insertions(+), 12 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 62f02e5..bb972a6 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -73,6 +74,37 @@ static int xhci_plat_start(struct usb_hcd *hcd)
return xhci_run(hcd);
 }
 
+static int xhci_plat_phy_init(struct usb_hcd *hcd)
+{
+   int ret;
+
+   if (hcd->phy) {
+   ret = phy_init(hcd->phy);
+   if (ret)
+   return ret;
+
+   ret = phy_power_on(hcd->phy);
+   if (ret) {
+   phy_exit(hcd->phy);
+   return ret;
+   }
+   } else {
+   ret = usb_phy_init(hcd->usb_phy);
+   }
+
+   return ret;
+}
+
+static void xhci_plat_phy_exit(struct usb_hcd *hcd)
+{
+   if (hcd->phy) {
+   phy_power_off(hcd->phy);
+   phy_exit(hcd->phy);
+   } else {
+   usb_phy_shutdown(hcd->usb_phy);
+   }
+}
+
 static int xhci_plat_probe(struct platform_device *pdev)
 {
struct device_node  *node = pdev->dev.of_node;
@@ -83,6 +115,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
struct usb_hcd  *hcd;
struct clk  *clk;
struct usb_phy  *usb_phy;
+   struct phy  *phy;
int ret;
int irq;
 
@@ -163,22 +196,44 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
xhci->shared_hcd->can_do_streams = 1;
 
+   hcd->phy = devm_phy_get(&pdev->dev, "usb2-phy");
+   if (IS_ERR(hcd->phy)) {
+   ret = PTR_ERR(hcd->phy);
+   if (ret == -EPROBE_DEFER)
+   goto put_usb3_hcd;
+   hcd->phy = NULL;
+   }
+
+   phy = devm_phy_get(&pdev->dev, "usb-phy");
+   if (IS_ERR(phy)) {
+   ret = PTR_ERR(phy);
+   if (ret == -EPROBE_DEFER)
+   goto put_usb3_hcd;
+   phy = NULL;
+   }
+
usb_phy = devm_usb_get_phy_by_phandle(&pdev->dev, "usb-phy", 0);
if (IS_ERR(usb_phy)) {
ret = PTR_ERR(usb_phy);
if (ret == -EPROBE_DEFER)
goto put_usb3_hcd;
usb_phy = NULL;
-   } else {
-   ret = usb_phy_init(usb_phy);
-   if (ret)
-   goto put_usb3_hcd;
}
+
xhci->shared_hcd->usb_phy = usb_phy;
+   xhci->shared_hcd->phy = phy;
+
+   ret = xhci_plat_phy_init(hcd);
+   if (ret)
+   goto put_usb3_hcd;
+
+   ret = xhci_plat_phy_init(xhci->shared_hcd);
+   if (ret)
+   goto disable_usb2_phy;
 
ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (ret)
-   goto disable_usb_phy;
+   goto disable_usb3_phy;
 
ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
if (ret)
@@ -190,8 +245,11 @@ static int xhci_plat_probe(struct platform_device *pdev)
 dealloc_usb2_hcd:
usb_remove_hcd(hcd);
 
-disable_usb_phy:
-   usb_phy_shutdown(usb_phy);
+disable_usb3_phy:
+   xhci_plat_phy_exit(xhci->shared_hcd);
+
+disable_usb2_phy:
+   xhci_plat_phy_exit(hcd);
 
 put_usb3_hcd:
usb_put_hcd(xhci->shared_hcd);
@@ -212,11 +270,11 @@ static int xhci_plat_remove(struct platform_device *dev)
struct clk *clk = xhci->clk;
 
usb_remove_hcd(xhci->shared_hcd);
-   usb_phy_shutdown(xhci->shared_hcd->usb_phy);
-
-   usb_remove_hcd(hcd);
+   xhci_plat_phy_exit(xhci->shared_hcd);
usb_put_hcd(xhci->shared_hcd);
 
+   usb_remove_hcd(hcd);
+   xhci_plat_phy_exit(hcd);
clk_disable_unprepare(clk);
usb_put_hcd(hcd);
 
@@ -242,7 +300,8 @@ static int xhci_plat_suspend(struct device *dev)
if (ret)
return ret;
 
-   usb_phy_shutdown(xhci->shared_hcd->usb_phy);
+   xhci_plat_phy_exit(xhci->shared_hcd);
+   xhci_plat_phy_exit(hcd);
clk_disable_unprepare(xhci->clk);
 
return ret;
@@ -258,7 +317,11 @@ static int xhci_plat_resume(struct device *dev)
if (ret)
return ret;
 
-   ret = usb_phy_init(xhci->shared_hcd->usb_phy);
+   ret = xhci_plat_phy_init(hcd);
+   if (ret)
+   return ret;
+
+   ret = xhci_plat_phy_init(xhci->shared_hcd);
if (ret)
return ret;
 
-- 
2.6.2

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

[PATCH v2 5/7] usb: xhci: plat: Remove checks for optional clock in error/remove path

[Jisheng Zhang]

Commit 63589e92c2d9 ("clk: Ignore error and NULL pointers passed to
clk_{unprepare, disable}()") allows NULL or error pointer to be passed
unconditionally.

This patch is to simplify probe error and remove code paths.

Signed-off-by: Jisheng Zhang 
---
 drivers/usb/host/xhci-plat.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index d990135..62f02e5 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -197,8 +197,7 @@ put_usb3_hcd:
usb_put_hcd(xhci->shared_hcd);
 
 disable_clk:
-   if (!IS_ERR(clk))
-   clk_disable_unprepare(clk);
+   clk_disable_unprepare(clk);
 
 put_hcd:
usb_put_hcd(hcd);
@@ -218,8 +217,7 @@ static int xhci_plat_remove(struct platform_device *dev)
usb_remove_hcd(hcd);
usb_put_hcd(xhci->shared_hcd);
 
-   if (!IS_ERR(clk))
-   clk_disable_unprepare(clk);
+   clk_disable_unprepare(clk);
usb_put_hcd(hcd);
 
return 0;
-- 
2.6.2

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

[PATCH v2 3/7] usb: xhci: plat: Fix suspend/resume when the optional usb_phy exists

[Jisheng Zhang]

Commit 7b8ef22ea547 ("usb: xhci: plat: Add USB phy support") adds the
usb_phy for usb3, but it forgets to shutdown/init the usb_phy in the
suspend/resume path. This patch fixes this issue by adding missing
usb_phy related calls.

Signed-off-by: Jisheng Zhang 
---
 drivers/usb/host/xhci-plat.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index a8c465a..cd49ae5 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -244,6 +244,7 @@ static int xhci_plat_suspend(struct device *dev)
if (ret)
return ret;
 
+   usb_phy_shutdown(xhci->shared_hcd->usb_phy);
clk_disable_unprepare(xhci->clk);
 
return ret;
@@ -259,6 +260,10 @@ static int xhci_plat_resume(struct device *dev)
if (ret)
return ret;
 
+   ret = usb_phy_init(xhci->shared_hcd->usb_phy);
+   if (ret)
+   return ret;
+
return xhci_resume(xhci, 0);
 }
 
-- 
2.6.2

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

[PATCH v2 4/7] usb: xhci: plat: sort the headers in alphabetic order

[Jisheng Zhang]

Sorting the headers in alphabetic order will help to reduce the conflict
when adding new headers later.

Signed-off-by: Jisheng Zhang 
---
 drivers/usb/host/xhci-plat.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index cd49ae5..d990135 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -11,15 +11,15 @@
  * version 2 as published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
+#include 
 #include 
-#include 
 
 #include "xhci.h"
 #include "xhci-mvebu.h"
-- 
2.6.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: reading data at 500Hz

[Jose Colmenares]

Hi,

Well the amount of data is very small, about 16 floats plus a header in the 
message. Lets round it up to 128 bytes. That means 128000 bytes per second for 
a 1000Hz frequency (which the device can give). 128000 bytes per second is a 
lot less than the 480 Mbps that USB 2 gives. That's what's killing me. That in 
theory I should be able to do it, but the data arrives in bursts. 

PD: I had hit "reply" instead of "reply to all" by mistake before. Sorry for 
the repeated messages.

Jose Colmenares.
Software Engineer.
Dynamic Legged Systems, Advanced Robotics.
Italian Institute of Technology.
+39 010 717 818 18

From: Greg KH [g...@kroah.com]
Sent: Sunday, December 06, 2015 6:39 AM
To: Jose Colmenares
Cc: USB list
Subject: Re: reading data at 500Hz

On Fri, Dec 04, 2015 at 12:46:14PM +, Jose Colmenares wrote:
> Hi,
>
> I'm using a USB Inertial Measurement Unit that theoretically produces
> data at 500Hz. According to the timestamps on the data, indeed the
> data is being produced at 500Hz. But I'm getting it in burst, with an
> "efective" sampling rate of 6ms instead of 2ms. That is, 166Hz instead
> of 500hz.
>
> I'm running ubuntu 14.04. I tried modifying the priority of the
> thread, but nothing changed.

What thread?

> The data is being read in polling mode. Every 2ms I try to read data
> from /dev/ttyACM0. A previous implementation was using the ioctl
> library to get the available data size, and after reaching a certain
> value the data was read. That code was going at 10Hz...
>
> I'm been trying to get my head around the polling rate of the usb
> driver, but all I find is related to USB's mouse polling rate. So I'm
> not sure how to apply that in my case. But it encourage me look
> further because it means that there may be a default usb polling rate
> somewhere!

The USB device will tell the host how often it wants to have the data
pulled from it in it's USB descriptors.  You can't increase this faster
than what the device itself is asking for.

> We are using USB 2.0 (if it matters), ubuntu 14.04, I'm reading at
> 166Hz using a standard file descriptor. But I need to get the data
> faster. 500Hz would be amazing. 250Hz ( 4ms polling rate) would be
> enough.

Are you sure that your device really can provide the data this fast over
a USB connection?  I don't think the math really adds up, look at the
speed of the USB link then take half of that for the "real" data that
can be sent from the device, and I think that's not fast enough for what
you are expecting here.

> The computer that will use the device (but I don't have access to all
> the time) has xenomai. Meaning very close to real time. But usually IO
> operations break the real time so this runs on a separate thread. I
> say this just in case is help full.

USB is anything but real-time, sorry.  If you need real-time data rates,
use something that has a chance to be deterministic, USB is not that
protocol, it's almost impossible to do due to the hardware involved.

sorry,

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: reading data at 500Hz

[Greg KH]

On Mon, Dec 07, 2015 at 01:50:37PM +, Jose Colmenares wrote:
> Hi,
> 
> Well the amount of data is very small, about 16 floats plus a header in the 
> message. Lets round it up to 128 bytes. That means 128000 bytes per second 
> for a 1000Hz frequency (which the device can give). 128000 bytes per second 
> is a lot less than the 480 Mbps that USB 2 gives. That's what's killing me. 
> That in theory I should be able to do it, but the data arrives in bursts. 

USB data comes in "bursts", sending small packets of data is just about
the worst thing you can do on USB, sorry.

You are also trying to abuse the cdc-acm driver for something it was not
designed to do, why not use libusb and drive your device from userspace
directly to get the data as fast as possible and avoid the tty layer
(which isn't causing you problems, but would be good to get out of the
way...)

You can see the data on the "wire" as far as the kernel thinks it is
coming in if you use usbmon, theres's documentation for it in the
Documentation/usb/ directory of the kernel.  That might help you see how
bad your device really is in sending data at the rates you are expecting
:)

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: Linux as a USB hub?

[Krzysztof Opasiak]

On 12/02/2015 07:14 PM, Rogan Dawes wrote:

On Wed, Dec 02, 2015 at 06:00:21PM +0100, Krzysztof Opasiak wrote:



On 12/02/2015 01:29 PM, Rogan Dawes wrote:

As mentioned originally, I'm trying to come up with an IP KVM, as inexpensively 
as possible. Realising that the approach that I am following will not allow me 
to interact with any layers prior to a successfully booted operating system, 
what I am hoping to do is, at a minimum, be able to observe the DisplayLink 
traffic flowing from an external computer (i.e. not a VM) over the USB.



If I understood your idea correctly you would like to do something
like rdp over USB, am I right?

If yes then I'm currently running a project with students from
Warsaw University of Technology and they are doing exactly this:)

What we would like to do:
- Use FunctionFS to emulate DisplayLink device
- Use f_hid to pass input events
- Maybe use f_ecm to share clipboard, file copy etc.

Unfortunately currently we have only some very basic proof of
concept. We have ffs daemon and ConfigFS config to setup and act
like a display link with 640x480 monitor. So on a host side we see
another monitor and on the device side we have an window in which we
can see image from host.

There are several problems. The most important one is display link
host driver and protocol documentation. We have implemented our
function based on open source display link driver (udl).
Unfortunately the performance is very poor 1280x1024 is absolutely
max what we can get if we don't want to have a slide show. udl
driver itself has also some problems and NULL ptr dereferences.
Moreover, Linux driver implements only very limited set of encodings
while Windows driver has much more of them and it's very easy to see
when you compare usb bandwidth used by widnows and linux driver.

That's why we will try to improve udl driver. Currently we try to
setup machine at university which will run linux and then windows in
virtual machine. We would like to connect dl to this computer, pass
it to virtual machine and then use usbmon + wireshark and try to
figure out new encodings used by windows driver and add them to udl
driver but probably it will take a lot of time...

Best regards,


Hi,

Yes, this is exactly what I am trying to implement. To be honest, I'd be quite 
happy with a single frame per second, but it sounds like you are way ahead of 
where I am.

Is there any chance in getting a look at your code?



Sorry for my late response but I was on a sickness leave and didn't have 
access to my company email.


Yah, sure. I have just pushed the code to github:

https://github.com/kopasiak/f_dl_ffs

please remember that it is only proof of concept. It has been written by 
our intern so I don't guarantee the code quality and it's a little bit 
hackish as it use opencv to show 30 images/s instead of doing live 
updates when receiving commands from host as we had some performance 
issues on odroid u3 board.


Cheers,
--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux as a USB hub?

[Rogan Dawes]

On Mon, Dec 07, 2015 at 04:12:22PM +0100, Krzysztof Opasiak wrote:
> >
> >Is there any chance in getting a look at your code?
> >
> 
> Sorry for my late response but I was on a sickness leave and didn't
> have access to my company email.
> 
> Yah, sure. I have just pushed the code to github:
> 
> https://github.com/kopasiak/f_dl_ffs
> 
> please remember that it is only proof of concept. It has been
> written by our intern so I don't guarantee the code quality and it's
> a little bit hackish as it use opencv to show 30 images/s instead of
> doing live updates when receiving commands from host as we had some
> performance issues on odroid u3 board.
> 
> Cheers,

Thank you! I look forward to testing your code on a BeagleBone Black.

Rogan

--
To unsubscribe from this list: send the line "unsubscribe 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: Infrastructure for zerocopy I/O

[Alan Stern]

On Sun, 6 Dec 2015, Steinar H. Gunderson wrote:

> On Sun, Dec 06, 2015 at 01:06:08AM +0100, Steinar H. Gunderson wrote:
> > I'll try to update your patch with the other suggestions tomorrow. Thanks!
> 
> Here we are. Lightly tested, I believe all comments should be addressed.

This looks quite good.  I have only a couple of comments.

> /* Steinar */
> 
> From 73833276a4f359c35edffc2a741dba57f2e82a12 Mon Sep 17 00:00:00 2001
> From: "Steinar H. Gunderson" 
> Date: Thu, 26 Nov 2015 01:19:13 +0100
> Subject: [PATCH] Add support for usbfs zerocopy.
> 
> Add a new interface for userspace to preallocate memory that can be
> used with usbfs. This gives two primary benefits:
> 
>  - Zerocopy; data no longer needs to be copied between the userspace
>and the kernel, but can instead be read directly by the driver from
>userspace's buffers. This works for both bulk and isochronous transfers;
>isochronous also no longer need to memset() the buffer to zero to avoid
>leaking kernel data.

Actually it now works for control and interrupt too, although there's
not much point using it for them.

>  - Once the buffers are allocated, USB transfers can no longer fail due to
>memory fragmentation; previously, long-running programs could run into
>problems finding a large enough contiguous memory chunk, especially on
>embedded systems or at high rates.
> @@ -1439,6 +1592,19 @@ static int proc_do_submiturb(struct usb_dev_state *ps, 
> struct usbdevfs_urb *uurb
>   goto error;
>   }
>  
> + as->usbm = find_memory_area(ps, uurb);
> + if (IS_ERR(as->usbm)) {
> + ret = PTR_ERR(as->usbm);
> + goto error;

Hmmm, and then what will happen when the error-handling code does this:

+   if (as && as->usbm)
+   dec_usb_memory_use_count(as->usbm, &as->usbm->urb_use_count);

?

> + }
> +
> + /* do not use SG buffers when memory mapped segments
> +  * are in use
> +  */
> + if (!as->usbm) {

You mean "if (as->usbm)".

> + num_sgs = 0;
> + }

Braces aren't needed.

> +
>   u += sizeof(struct async) + sizeof(struct urb) + uurb->buffer_length +
>num_sgs * sizeof(struct scatterlist);
>   ret = usbfs_increase_memory_usage(u);
> @@ -1476,14 +1642,23 @@ static int proc_do_submiturb(struct usb_dev_state 
> *ps, struct usbdevfs_urb *uurb
>   totlen -= u;
>   }
>   } else if (uurb->buffer_length > 0) {
> - as->urb->transfer_buffer = kmalloc(uurb->buffer_length,
> - GFP_KERNEL);
> - if (!as->urb->transfer_buffer) {
> - ret = -ENOMEM;
> - goto error;
> + if (as->usbm) {
> + unsigned long uurb_start = (unsigned long)uurb->buffer;
> +
> + as->urb->transfer_buffer = as->usbm->mem +
> + (uurb_start - as->usbm->vm_start);
> + } else {
> + as->urb->transfer_buffer = kmalloc(uurb->buffer_length,
> + GFP_KERNEL);
> + if (!as->urb->transfer_buffer) {
> + ret = -ENOMEM;
> + goto error;
> + }
>   }
>  
> - if (!is_in) {
> + if (as->usbm) {
> + ;   /* Transfer buffer is okay as it is */
> + } else if (!is_in) {
>   if (copy_from_user(as->urb->transfer_buffer,
>  uurb->buffer,
>  uurb->buffer_length)) {

It looks odd repeating the "if (as->usbm)" test like this.  You can merge
the stuff here into the "else" clause of the preceding code.

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 1/2] usb: musb: core: Fix handling of the phy notifications

[Tony Lindgren]

* Kishon Vijay Abraham I  [151206 23:03]:
> On Tuesday 01 December 2015 11:07 AM, Tony Lindgren wrote:
> > We currently can't unload omap2430 MUSB platform glue driver module and
> > this cause issues for fixing the MUSB code further. The reason we can't
> > remove omap2430 is because it uses the PHY functions and also exports the
> > omap_musb_mailbox function that some PHY drivers are using.
> > 
> > Let's fix the issue by exporting a more generic musb_mailbox function
> > from the MUSB core and allow platform glue layers to register phy_callback
> > function as needed.
> > 
> > And now we can now also get rid of the include/linux/musb-omap.h.
> > 
> > Cc: Bin Liu 
> > Cc: Felipe Balbi 
> > Cc: Kishon Vijay Abraham I 
> > Cc: NeilBrown 
> > Signed-off-by: Tony Lindgren 
> 
> Reviewed-by: Kishon Vijay Abraham I 
> > 
> > Probably best that Felipe merges this patch via the USB tree after
> > comments if that works for Kishon? I have another two fixes for the
> 
> That should be okay.

OK thanks!

Tony
--
To unsubscribe from this list: send the line "unsubscribe 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] r8152: fix lockup when runtime PM is enabled

[Peter Wu]

When an interface is brought up which was previously suspended (via
runtime PM), it would hang. This happens because napi_disable is called
before napi_enable.

Solve this by avoiding napi_disable before the device is fully up.

While at it, remove WORK_ENABLE check from rtl8152_open (introduced with
the original change) because it cannot happen:

 - After this patch, runtime resume will not set it during rtl8152_open.
 - When link is up, rtl8152_open is not called.
 - When link is down during system/auto suspend/resume, it is not set.

Fixes: 41cec84cf285 ("r8152: don't enable napi before rx ready")
Link: https://lkml.kernel.org/r/20151205105912.GA1766@al
Signed-off-by: Peter Wu 
---
 drivers/net/usb/r8152.c | 23 +++
 1 file changed, 7 insertions(+), 16 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index d9427ca..b8b083e 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3067,17 +3067,6 @@ static int rtl8152_open(struct net_device *netdev)
 
mutex_lock(&tp->control);
 
-   /* The WORK_ENABLE may be set when autoresume occurs */
-   if (test_bit(WORK_ENABLE, &tp->flags)) {
-   clear_bit(WORK_ENABLE, &tp->flags);
-   usb_kill_urb(tp->intr_urb);
-   cancel_delayed_work_sync(&tp->schedule);
-
-   /* disable the tx/rx, if the workqueue has enabled them. */
-   if (netif_carrier_ok(netdev))
-   tp->rtl_ops.disable(tp);
-   }
-
tp->rtl_ops.up(tp);
 
rtl8152_set_speed(tp, AUTONEG_ENABLE,
@@ -3516,11 +3505,13 @@ static int rtl8152_resume(struct usb_interface *intf)
if (test_bit(SELECTIVE_SUSPEND, &tp->flags)) {
rtl_runtime_suspend_enable(tp, false);
clear_bit(SELECTIVE_SUSPEND, &tp->flags);
-   napi_disable(&tp->napi);
-   set_bit(WORK_ENABLE, &tp->flags);
-   if (netif_carrier_ok(tp->netdev))
-   rtl_start_rx(tp);
-   napi_enable(&tp->napi);
+   if (tp->netdev->flags & IFF_UP) {
+   napi_disable(&tp->napi);
+   set_bit(WORK_ENABLE, &tp->flags);
+   if (netif_carrier_ok(tp->netdev))
+   rtl_start_rx(tp);
+   napi_enable(&tp->napi);
+   }
} else {
tp->rtl_ops.up(tp);
rtl8152_set_speed(tp, AUTONEG_ENABLE,
-- 
2.6.3

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

Re: Help needed for EHCI problem: removing an active bulk-in QH

[Alan Stern]

Michael:

Here at last is the final version of the patch, or something very close 
to it.  This should be applied on top of the other EHCI patches, but 
not the quick-and-dirty fix, which it replaces.

Please test it and let me know the results.

Alan Stern



Index: usb-4.3/drivers/usb/host/ehci.h
===
--- usb-4.3.orig/drivers/usb/host/ehci.h
+++ usb-4.3/drivers/usb/host/ehci.h
@@ -110,6 +110,7 @@ enum ehci_hrtimer_event {
EHCI_HRTIMER_POLL_DEAD, /* Wait for dead controller to stop */
EHCI_HRTIMER_UNLINK_INTR,   /* Wait for interrupt QH unlink */
EHCI_HRTIMER_FREE_ITDS, /* Wait for unused iTDs and siTDs */
+   EHCI_HRTIMER_ACTIVE_UNLINK, /* Wait while unlinking an active QH */
EHCI_HRTIMER_START_UNLINK_INTR, /* Unlink empty interrupt QHs */
EHCI_HRTIMER_ASYNC_UNLINKS, /* Unlink empty async QHs */
EHCI_HRTIMER_IAA_WATCHDOG,  /* Handle lost IAA interrupts */
@@ -156,6 +157,8 @@ struct ehci_hcd {   /* one per controlle
struct list_headasync_idle;
unsignedasync_unlink_cycle;
unsignedasync_count;/* async activity count */
+   __hc32  old_current;/* Test for QH becoming */
+   __hc32  old_token;  /*  inactive during unlink */
 
/* periodic schedule support */
 #defineDEFAULT_I_TDPS  1024/* some HCs can do less 
*/
@@ -432,13 +435,19 @@ struct ehci_qh {
u8  xacterrs;   /* XactErr retry counter */
 #defineQH_XACTERR_MAX  32  /* XactErr retry limit 
*/
 
+   u8  unlink_reason;
+#define QH_UNLINK_HALTED   0x01/* Halt flag is set */
+#define QH_UNLINK_SHORT_READ   0x02/* Recover from a short read */
+#define QH_UNLINK_DUMMY_OVERLAY0x04/* QH overlayed the 
dummy TD */
+#define QH_UNLINK_SHUTDOWN 0x08/* The HC isn't running */
+#define QH_UNLINK_END_OF_QUEUE 0x10/* Reached end of the queue */
+#define QH_UNLINK_REQUESTED0x20/* Disable, reset, or dequeue */
+
u8  gap_uf; /* uframes split/csplit gap */
 
unsignedis_out:1;   /* bulk or intr OUT */
unsignedclearing_tt:1;  /* Clear-TT-Buf in progress */
unsigneddequeue_during_giveback:1;
-   unsignedexception:1;/* got a fault, or an unlink
-  was requested */
unsignedshould_be_inactive:1;
 };
 
Index: usb-4.3/drivers/usb/host/ehci-hcd.c
===
--- usb-4.3.orig/drivers/usb/host/ehci-hcd.c
+++ usb-4.3/drivers/usb/host/ehci-hcd.c
@@ -306,6 +306,7 @@ static void ehci_quiesce (struct ehci_hc
 
 /*-*/
 
+static void end_iaa_cycle(struct ehci_hcd *ehci);
 static void end_unlink_async(struct ehci_hcd *ehci);
 static void unlink_empty_async(struct ehci_hcd *ehci);
 static void unlink_empty_async_suspended(struct ehci_hcd *ehci);
@@ -565,6 +566,9 @@ static int ehci_init(struct usb_hcd *hcd
/* Accept arbitrarily long scatter-gather lists */
if (!(hcd->driver->flags & HCD_LOCAL_MEM))
hcd->self.sg_tablesize = ~0;
+
+   /* Prepare for unlinking active QHs */
+   ehci->old_current = ~0;
return 0;
 }
 
@@ -758,7 +762,7 @@ static irqreturn_t ehci_irq (struct usb_
ehci_dbg(ehci, "IAA with IAAD still set?\n");
if (ehci->iaa_in_progress)
COUNT(ehci->stats.iaa);
-   end_unlink_async(ehci);
+   end_iaa_cycle(ehci);
}
 
/* remote wakeup [4.3.1] */
@@ -911,7 +915,7 @@ static int ehci_urb_dequeue(struct usb_h
 */
} else {
qh = (struct ehci_qh *) urb->hcpriv;
-   qh->exception = 1;
+   qh->unlink_reason |= QH_UNLINK_REQUESTED;
switch (qh->qh_state) {
case QH_STATE_LINKED:
if (usb_pipetype(urb->pipe) == PIPE_INTERRUPT)
@@ -972,7 +976,7 @@ rescan:
goto done;
}
 
-   qh->exception = 1;
+   qh->unlink_reason |= QH_UNLINK_REQUESTED;
switch (qh->qh_state) {
case QH_STATE_LINKED:
WARN_ON(!list_empty(&qh->qtd_list));
@@ -1042,7 +1046,7 @@ ehci_endpoint_reset(struct usb_hcd *hcd,
 * re-linking will call qh_refresh().
 */
usb_settoggle(qh->ps.udev, epnum, is_out, 0);
-   qh->exception = 1;
+   qh->unlink_reason |= QH_UNLINK_REQUESTED;
  

Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case

[Felipe Balbi]

Hi,

Gregory CLEMENT  writes:
> Hi Felipe,
>
> I am going back on this subject (again :) )
>  
>  On mar., oct. 20 2015, Gregory CLEMENT  
> wrote:
>
>> Hi Felipe,
>>  
>>  On lun., oct. 05 2015, Felipe Balbi  wrote:
>>
>>
 So after many tests on different devices, 200ms is enough for most of
 them, but for one, 2000ms (2s) was needed!

 I see several option:
 - adding a sysfs entry to setup the time
 - adding a debugs entry entry
 - adding configuration option in menuconfig
 - using 2000ms and hopping it was enough for everyone

 My preference would go to the first option, what is your opinion?
>>>
>>> I'm not sure if either of them is good. man 2s is just too large. If the
>
> Well 2s is lon I agree, but currently instead of 2s we have an infinite
> wait, which is worse!
>
>>> device isn't following the specification, I'm afraid that device needs
>>> to be fixed.
>
> I agree but these devices are for most of them USB stick that we find in
> retail. We have no influence on them, so we have to do with them, even
> if they do not follow the sepc.
>
> So what about using configfs or sysfs to let the user confgiure this
> value if needed?

iff we have to; I'm still not 100% convinced.

> I go back on this because, your suggestion didn't work. At least, I
> didn't manage to make it improve the situation.
>
> Thanks,
>
>>>
>>> I think the real issue here is the lack of a disconnect IRQ from AM335x
>>> devices. But here's something I've been meaning to test but never had
>>> time. If you look into AM335x address space, there's a bit in the
>>> wrapper which tells it to use the standard MUSB registers for IRQ,
>>> instead of the TI-specific thing. Can you see if we get a disconnect IRQ
>>> with that ?
>>>
>>> TRM is at [1], see page 2566. Basically, if you set bit 3 in register
>>> offset 0x1014, then it should use Mentor IRQ registers. If that works,
>>> quite a few problems will actually vanish :-p
>>
>> So I tried it with the following patch:
>>
>> -
>> diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
>> index c791ba5..c714500 100644
>> --- a/drivers/usb/musb/musb_dsps.c
>> +++ b/drivers/usb/musb/musb_dsps.c
>> @@ -470,6 +470,7 @@ static int dsps_musb_init(struct musb *musb)
>>  
>> /* Reset the musb */
>> dsps_writel(reg_base, wrp->control, (1 << wrp->reset));
>> +   dsps_writel(musb->ctrl_base, wrp->control, BIT(3));

overwritting reset.

>> musb->isr = dsps_interrupt;
>>  
>> @@ -625,6 +626,7 @@ static int dsps_musb_reset(struct musb *musb)
>> if (session_restart || !glue->sw_babble_enabled) {
>> dev_info(musb->controller, "Restarting MUSB to recover from 
>> Babble\n");
>> dsps_writel(musb->ctrl_base, wrp->control, (1 << 
>> wrp->reset));
>> +   dsps_writel(musb->ctrl_base, wrp->control, BIT(3));

here too. No wonder it won't work, right :-)

>> I am not very familiar with that driver but my understanding was that
>> the Mentor IRQ registeres are managed by the musb_interrupt() function
>> which is called from the dsps_interrupt() interrupt handler.
>>
>> Am I right?

yeah, however the way IRQs are reported is a different thing. AM335x
introduced its own IRQ reporting scheme which, basically, reads MUSB
generic IRQ status registers and reports on an AM335x specific
register. No idea why TI did that for AM335x devices.

>> if it is the case then it didn't fix the issue I had.
>>
>> I activated the following debug line:
>>
>> [musb_hdrc]musb_interrupt =_ "** IRQ %s usb%04x tx%04x rx%04x\012"
>> [musb_dsps]dsps_interrupt =p "usbintr (%x) epintr(%x)\012"
>>
>> But I didn't get any interrupt while disconnecting the cable without any
>> device connected on it (whereas I got an interrupt when I connected it).
>>
>> Note that I applied this patch instead of the "usb: musb: dsps: handle
>> the otg_state_a_wait_vrise_timeout case", is what you had in mind ?

yeah, that's what I had in mind. But your patch seems wrong :-)

I tried writing a more correct version here and found 2 issues:

a) bit 3 doesn't do anything :-p I cannot read IRQs from mentor's
registers

b) when setting RESET_ISOLATION bit, reads of CTRL register hang. Note
that according to TRM, RESET_ISOLATION _must_ be set prior to a soft
reset and cleared afterwards. But right after setting RESET_ISOLATION,
if I try a read of CTRL, it'll hang forever.

Bin, do you know about these problems ? They both seem rather alarming
to me.

-- 
balbi


signature.asc
Description: PGP signature

USB TrackPoint mouse non-functional with dock; works if direct

[Josh Triplett]

I have a USB Lenovo ThinkPad Keyboard with TrackPoint (vendor:product
17ef:6009), and a ThinkPad Yoga 12 (Broadwell version) with OneLink Pro
dock. If I plug the keyboard/mouse directly into the laptop,
it works fine. If I plug it into the dock, the keyboard works fine;
however, the mouse works for a fraction of a second and then stops
working.  (Both the TrackPoint and its mouse buttons do not work through
the dock.)

The dock shows up as four of:
2109:0812 VIA Labs, Inc. VL812 Hub

At first, I wondered if USB autosuspend might have something to do with
this.  However, I confirmed that the keyboard/mouse itself didn't have
autosuspend turned on in the first place, and while the hubs did,
turning off autosuspend for *all* USB devices did not fix the problem.

Looking at the sysfs path for the input device as shown in dmesg,
/sys/devices/pci\:00/\:00\:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2\:1.1/supports_autosuspend
did say "1".  However, the device didn't actually appear to have
autosuspend *enabled*.

I'd appreciate any suggestions for how to debug this issue.

- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe 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 TrackPoint mouse non-functional with dock; works if direct

[Felipe Balbi]

Hi,

Josh Triplett  writes:
> I have a USB Lenovo ThinkPad Keyboard with TrackPoint (vendor:product
> 17ef:6009), and a ThinkPad Yoga 12 (Broadwell version) with OneLink Pro
> dock. If I plug the keyboard/mouse directly into the laptop,
> it works fine. If I plug it into the dock, the keyboard works fine;
> however, the mouse works for a fraction of a second and then stops
> working.  (Both the TrackPoint and its mouse buttons do not work through
> the dock.)
>
> The dock shows up as four of:
> 2109:0812 VIA Labs, Inc. VL812 Hub

this dock probably doesn't like autosuspend. Can you disable autosuspend
for it and see if it sorts it out ?

> At first, I wondered if USB autosuspend might have something to do with
> this.  However, I confirmed that the keyboard/mouse itself didn't have
> autosuspend turned on in the first place, and while the hubs did,
> turning off autosuspend for *all* USB devices did not fix the problem.
>
> Looking at the sysfs path for the input device as shown in dmesg,
> /sys/devices/pci\:00/\:00\:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2\:1.1/supports_autosuspend
> did say "1".  However, the device didn't actually appear to have
> autosuspend *enabled*.
>
> I'd appreciate any suggestions for how to debug this issue.

what does 'control' on the power directory show ?

-- 
balbi


signature.asc
Description: PGP signature

Re: USB TrackPoint mouse non-functional with dock; works if direct

[Josh Triplett]

On Mon, Dec 07, 2015 at 02:29:39PM -0600, Felipe Balbi wrote:
> 
> Hi,
> 
> Josh Triplett  writes:
> > I have a USB Lenovo ThinkPad Keyboard with TrackPoint (vendor:product
> > 17ef:6009), and a ThinkPad Yoga 12 (Broadwell version) with OneLink Pro
> > dock. If I plug the keyboard/mouse directly into the laptop,
> > it works fine. If I plug it into the dock, the keyboard works fine;
> > however, the mouse works for a fraction of a second and then stops
> > working.  (Both the TrackPoint and its mouse buttons do not work through
> > the dock.)
> >
> > The dock shows up as four of:
> > 2109:0812 VIA Labs, Inc. VL812 Hub
> 
> this dock probably doesn't like autosuspend. Can you disable autosuspend
> for it and see if it sorts it out ?

I tried doing so, and that did not help:

> > At first, I wondered if USB autosuspend might have something to do with
> > this.  However, I confirmed that the keyboard/mouse itself didn't have
> > autosuspend turned on in the first place, and while the hubs did,
> > turning off autosuspend for *all* USB devices did not fix the problem.

Note that after disabling autosuspend on all devices, I then unplugged and
replugged the keyboard/mouse device, and the problem remained: the mouse only
works for a fraction of a second before stopping.

> > Looking at the sysfs path for the input device as shown in dmesg,
> > /sys/devices/pci\:00/\:00\:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2\:1.1/supports_autosuspend
> > did say "1".  However, the device didn't actually appear to have
> > autosuspend *enabled*.
> >
> > I'd appreciate any suggestions for how to debug this issue.
> 
> what does 'control' on the power directory show ?

I don't have a file "control" in the power directory when plugged in through
the dock.  The contents of all the files under power when plugged in via dock:

~$ head 
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/*
==> 
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/async
 <==
enabledd 
/sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.002D/power/*
==> 
/sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.002D/power/async
 <==
disabled

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.002D/power/autosuspend_delay_ms
 <==
head: error reading 
‘/sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.002D/power/autosuspend_delay_ms’:
 Input/output error

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.002D/power/control
 <==
auto

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.002D/power/runtime_active_kids
 <==
0

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.002D/power/runtime_active_time
 <==
0

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.002D/power/runtime_enabled
 <==
disabled

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.002D/power/runtime_status
 <==
unsupported

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.002D/power/runtime_suspended_time
 <==
0

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.002D/power/runtime_usage
 <==
0


==> 
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/runtime_active_kids
 <==
0

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/runtime_enabled
 <==
enabled

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/runtime_status
 <==
suspended

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/runtime_usage
 <==
0


Suspend does look like the problem here.  If I run a continuous loop
looking at
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/runtime_status
, and then plug the device into the same port on the dock, that file
goes from "No such file or directory" to "active" and then almost
immediately to "suspended".


By contrast, if I plug the device into my laptop directly, the
corresponding power directory has quite different contents, and more
files:

~$ head 
/sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.002D/power/*
==> 
/sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.002D/power/async
 <==
disabled

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.002D/power/autosuspend_delay_ms
 <==
head: error reading 
‘/sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.002D/power/autosuspend_delay_ms’:
 Input/output error

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.002D/power/control
 <==
auto

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.002D/power/runtime_active_kids
 <==
0

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.002D/power/runtime_active_time
 <==
0

==> 
/sys/devices/pci:00/

Re: USB TrackPoint mouse non-functional with dock; works if direct

[Felipe Balbi]

Hi,

Josh Triplett  writes:
>> > Looking at the sysfs path for the input device as shown in dmesg,
>> > /sys/devices/pci\:00/\:00\:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2\:1.1/supports_autosuspend
>> > did say "1".  However, the device didn't actually appear to have
>> > autosuspend *enabled*.
>> >
>> > I'd appreciate any suggestions for how to debug this issue.
>> 
>> what does 'control' on the power directory show ?
> I don't have a file "control" in the power directory when plugged in through
> the dock.  The contents of all the files under power when plugged in via dock:

huh ???

> ==> 
> /sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.002D/power/control
>  <==
> auto

here's one enabling autosuspend

> ==> 
> /sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.002D/power/control
>  <==
> auto

and another, also enabling runtime pm. Change both of these from 'auto'
to 'on' and see if that helps.

-- 
balbi


signature.asc
Description: PGP signature

Re: USB TrackPoint mouse non-functional with dock; works if direct

[Josh Triplett]

On Mon, Dec 07, 2015 at 03:03:40PM -0600, Felipe Balbi wrote:
> Josh Triplett  writes:
> >> > Looking at the sysfs path for the input device as shown in dmesg,
> >> > /sys/devices/pci\:00/\:00\:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2\:1.1/supports_autosuspend
> >> > did say "1".  However, the device didn't actually appear to have
> >> > autosuspend *enabled*.
> >> >
> >> > I'd appreciate any suggestions for how to debug this issue.
> >> 
> >> what does 'control' on the power directory show ?
> > I don't have a file "control" in the power directory when plugged in through
> > the dock.  The contents of all the files under power when plugged in via 
> > dock:
> 
> huh ???
> 
> > ==> 
> > /sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.002D/power/control
> >  <==
> > auto
> 
> here's one enabling autosuspend
> 
> > ==> 
> > /sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.002D/power/control
> >  <==
> > auto
> 
> and another, also enabling runtime pm. Change both of these from 'auto'
> to 'on' and see if that helps.

Copy/paste error; notice that both of those have the same path.

The following files appear under the power directory when plugged in via
the dock:

~$ head 
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/*
==> 
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/async
 <==
enabled

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/runtime_active_kids
 <==
0

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/runtime_enabled
 <==
enabled

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/runtime_status
 <==
suspended

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/runtime_usage
 <==
0


Notice that no file named "control" exists.

By contrast, the following files appear under the power directory when
plugged in directly:

~$ head 
/sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.0032/power/*
==> 
/sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.0032/power/async
 <==
disabled

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.0032/power/autosuspend_delay_ms
 <==
head: error reading 
‘/sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.0032/power/autosuspend_delay_ms’:
 Input/output error

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.0032/power/control
 <==
auto

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.0032/power/runtime_active_kids
 <==
0

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.0032/power/runtime_active_time
 <==
0

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.0032/power/runtime_enabled
 <==
disabled

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.0032/power/runtime_status
 <==
unsupported

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.0032/power/runtime_suspended_time
 <==
0

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.0032/power/runtime_usage
 <==
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: USB TrackPoint mouse non-functional with dock; works if direct

[Felipe Balbi]

Hi,

Josh Triplett  writes:
> On Mon, Dec 07, 2015 at 03:03:40PM -0600, Felipe Balbi wrote:
>> Josh Triplett  writes:
>> >> > Looking at the sysfs path for the input device as shown in dmesg,
>> >> > /sys/devices/pci\:00/\:00\:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2\:1.1/supports_autosuspend
>> >> > did say "1".  However, the device didn't actually appear to have
>> >> > autosuspend *enabled*.
>> >> >
>> >> > I'd appreciate any suggestions for how to debug this issue.
>> >> 
>> >> what does 'control' on the power directory show ?
>> > I don't have a file "control" in the power directory when plugged in 
>> > through
>> > the dock.  The contents of all the files under power when plugged in via 
>> > dock:
>> 
>> huh ???
>> 
>> > ==> 
>> > /sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.002D/power/control
>> >  <==
>> > auto
>> 
>> here's one enabling autosuspend
>> 
>> > ==> 
>> > /sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.002D/power/control
>> >  <==
>> > auto
>> 
>> and another, also enabling runtime pm. Change both of these from 'auto'
>> to 'on' and see if that helps.
>
> Copy/paste error; notice that both of those have the same path.

okay.

> The following files appear under the power directory when plugged in via
> the dock:

if those are not enabled, then the device doesn't have pm_runtime
callbacks, see:

int dpm_sysfs_add(struct device *dev)
{
int rc;

rc = sysfs_create_group(&dev->kobj, &pm_attr_group);
if (rc)
return rc;

if (pm_runtime_callbacks_present(dev)) {
rc = sysfs_merge_group(&dev->kobj, &pm_runtime_attr_group);
if (rc)
goto err_out;
}
if (device_can_wakeup(dev)) {
rc = sysfs_merge_group(&dev->kobj, &pm_wakeup_attr_group);
if (rc)
goto err_runtime;
}
if (dev->power.set_latency_tolerance) {
rc = sysfs_merge_group(&dev->kobj,
   &pm_qos_latency_tolerance_attr_group);
if (rc)
goto err_wakeup;
}
return 0;

 err_wakeup:
sysfs_unmerge_group(&dev->kobj, &pm_wakeup_attr_group);
 err_runtime:
sysfs_unmerge_group(&dev->kobj, &pm_runtime_attr_group);
 err_out:
sysfs_remove_group(&dev->kobj, &pm_attr_group);
return rc;
}

It seems like usbcore always calls pm_runtime_no_callbacks() (which
makes pm_runtime_callbacks_present() above fail) for all interfaces, but
I can't seem to find where that's undone. Alan, any hints ?

> ~$ head 
> /sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/*
> ==> 
> /sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/async
>  <==
> enabled

enabled

> ==> 
> /sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/runtime_active_kids
>  <==
> 0
>
> ==> 
> /sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/runtime_enabled
>  <==
> enabled
>
> ==> 
> /sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/runtime_status
>  <==
> suspended
>
> ==> 
> /sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/runtime_usage
>  <==
> 0
>
>
> Notice that no file named "control" exists.
>
> By contrast, the following files appear under the power directory when
> plugged in directly:
>
> ~$ head 
> /sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.0032/power/*
> ==> 
> /sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.0032/power/async
>  <==
> disabled

disabled :-)

see if setting the other case to disabled changes anything.

-- 
balbi


signature.asc
Description: PGP signature

Re: USB TrackPoint mouse non-functional with dock; works if direct

[Alan Stern]

On Mon, 7 Dec 2015, Josh Triplett wrote:

> The following files appear under the power directory when plugged in via
> the dock:
> 
> ~$ head 
> /sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/*
> ==> 
> /sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/async
>  <==
> enabled
> 
> ==> 
> /sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/runtime_active_kids
>  <==
> 0
> 
> ==> 
> /sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/runtime_enabled
>  <==
> enabled
> 
> ==> 
> /sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/runtime_status
>  <==
> suspended
> 
> ==> 
> /sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/runtime_usage
>  <==
> 0

You're looking at the wrong files.  The files to monitor are the ones
in /sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/power
(assuming that this device really is the mouse and not something else).  
Handy shortcut link: /sys/bus/usb/devices/2-3.1.2/power.

For more information on what's happening, try collecting a usbmon trace 
for bus 2 (see Documentation/usb/usbmon.txt).

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: USB TrackPoint mouse non-functional with dock; works if direct

[Alan Stern]

On Mon, 7 Dec 2015, Felipe Balbi wrote:

> if those are not enabled, then the device doesn't have pm_runtime
> callbacks, see:
> 
> int dpm_sysfs_add(struct device *dev)
> {
>   int rc;
> 
>   rc = sysfs_create_group(&dev->kobj, &pm_attr_group);
>   if (rc)
>   return rc;
> 
>   if (pm_runtime_callbacks_present(dev)) {
>   rc = sysfs_merge_group(&dev->kobj, &pm_runtime_attr_group);
>   if (rc)
>   goto err_out;
>   }
>   if (device_can_wakeup(dev)) {
>   rc = sysfs_merge_group(&dev->kobj, &pm_wakeup_attr_group);
>   if (rc)
>   goto err_runtime;
>   }
>   if (dev->power.set_latency_tolerance) {
>   rc = sysfs_merge_group(&dev->kobj,
>  &pm_qos_latency_tolerance_attr_group);
>   if (rc)
>   goto err_wakeup;
>   }
>   return 0;
> 
>  err_wakeup:
>   sysfs_unmerge_group(&dev->kobj, &pm_wakeup_attr_group);
>  err_runtime:
>   sysfs_unmerge_group(&dev->kobj, &pm_runtime_attr_group);
>  err_out:
>   sysfs_remove_group(&dev->kobj, &pm_attr_group);
>   return rc;
> }
> 
> It seems like usbcore always calls pm_runtime_no_callbacks() (which
> makes pm_runtime_callbacks_present() above fail) for all interfaces, but
> I can't seem to find where that's undone. Alan, any hints ?

The USB subsystem treats runtime PM of interfaces differently from 
runtime PM of devices.  Josh should be monitoring the device, not the 
interface.

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: USB TrackPoint mouse non-functional with dock; works if direct

[Josh Triplett]

On Mon, Dec 07, 2015 at 03:45:23PM -0600, Felipe Balbi wrote:
> 
> Hi,
> 
> Josh Triplett  writes:
> > On Mon, Dec 07, 2015 at 03:03:40PM -0600, Felipe Balbi wrote:
> >> Josh Triplett  writes:
> >> >> > Looking at the sysfs path for the input device as shown in dmesg,
> >> >> > /sys/devices/pci\:00/\:00\:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2\:1.1/supports_autosuspend
> >> >> > did say "1".  However, the device didn't actually appear to have
> >> >> > autosuspend *enabled*.
> >> >> >
> >> >> > I'd appreciate any suggestions for how to debug this issue.
> >> >> 
> >> >> what does 'control' on the power directory show ?
> >> > I don't have a file "control" in the power directory when plugged in 
> >> > through
> >> > the dock.  The contents of all the files under power when plugged in via 
> >> > dock:
> >> 
> >> huh ???
> >> 
> >> > ==> 
> >> > /sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.002D/power/control
> >> >  <==
> >> > auto
> >> 
> >> here's one enabling autosuspend
> >> 
> >> > ==> 
> >> > /sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.002D/power/control
> >> >  <==
> >> > auto
> >> 
> >> and another, also enabling runtime pm. Change both of these from 'auto'
> >> to 'on' and see if that helps.
> >
> > Copy/paste error; notice that both of those have the same path.
> 
> okay.
> 
> > The following files appear under the power directory when plugged in via
> > the dock:
> 
> if those are not enabled, then the device doesn't have pm_runtime
> callbacks, see:
> 
> int dpm_sysfs_add(struct device *dev)
> {
>   int rc;
> 
>   rc = sysfs_create_group(&dev->kobj, &pm_attr_group);
>   if (rc)
>   return rc;
> 
>   if (pm_runtime_callbacks_present(dev)) {
>   rc = sysfs_merge_group(&dev->kobj, &pm_runtime_attr_group);
>   if (rc)
>   goto err_out;
>   }
>   if (device_can_wakeup(dev)) {
>   rc = sysfs_merge_group(&dev->kobj, &pm_wakeup_attr_group);
>   if (rc)
>   goto err_runtime;
>   }
>   if (dev->power.set_latency_tolerance) {
>   rc = sysfs_merge_group(&dev->kobj,
>  &pm_qos_latency_tolerance_attr_group);
>   if (rc)
>   goto err_wakeup;
>   }
>   return 0;
> 
>  err_wakeup:
>   sysfs_unmerge_group(&dev->kobj, &pm_wakeup_attr_group);
>  err_runtime:
>   sysfs_unmerge_group(&dev->kobj, &pm_runtime_attr_group);
>  err_out:
>   sysfs_remove_group(&dev->kobj, &pm_attr_group);
>   return rc;
> }
> 
> It seems like usbcore always calls pm_runtime_no_callbacks() (which
> makes pm_runtime_callbacks_present() above fail) for all interfaces, but
> I can't seem to find where that's undone. Alan, any hints ?

So, for some reason, the device has pm_runtime callbacks when plugged in
directly, but not when plugged into the dock?

> > ~$ head 
> > /sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/*
> > ==> 
> > /sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/async
> >  <==
> > enabled
> 
> enabled
> 
> > ==> 
> > /sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/runtime_active_kids
> >  <==
> > 0
> >
> > ==> 
> > /sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/runtime_enabled
> >  <==
> > enabled
> >
> > ==> 
> > /sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/runtime_status
> >  <==
> > suspended
> >
> > ==> 
> > /sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/runtime_usage
> >  <==
> > 0
> >
> >
> > Notice that no file named "control" exists.
> >
> > By contrast, the following files appear under the power directory when
> > plugged in directly:
> >
> > ~$ head 
> > /sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.0032/power/*
> > ==> 
> > /sys/devices/pci:00/:00:14.0/usb2/2-2/2-2:1.1/0003:17EF:6009.0032/power/async
> >  <==
> > disabled
> 
> disabled :-)
> 
> see if setting the other case to disabled changes anything.

It does not, no.

- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe 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 TrackPoint mouse non-functional with dock; works if direct

[Josh Triplett]

On Mon, Dec 07, 2015 at 05:02:34PM -0500, Alan Stern wrote:
> On Mon, 7 Dec 2015, Josh Triplett wrote:
> 
> > The following files appear under the power directory when plugged in via
> > the dock:
> > 
> > ~$ head 
> > /sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/*
> > ==> 
> > /sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/async
> >  <==
> > enabled
> > 
> > ==> 
> > /sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/runtime_active_kids
> >  <==
> > 0
> > 
> > ==> 
> > /sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/runtime_enabled
> >  <==
> > enabled
> > 
> > ==> 
> > /sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/runtime_status
> >  <==
> > suspended
> > 
> > ==> 
> > /sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/2-3.1.2:1.1/power/runtime_usage
> >  <==
> > 0
> 
> You're looking at the wrong files.  The files to monitor are the ones
> in /sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/power
> (assuming that this device really is the mouse and not something else).  
> Handy shortcut link: /sys/bus/usb/devices/2-3.1.2/power.

Based on the idVendor and idProduct in that directory, that device is
the keyboard/mouse combo device, yes.

That power directory has many more files, but nothing obvious:

~$ head /sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/power/*
==> 
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/power/active_duration
 <==
235320

==> /sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/power/async <==
enabled

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/power/autosuspend 
<==
2

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/power/autosuspend_delay_ms
 <==
2000

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/power/connected_duration
 <==
235320

==> /sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/power/control 
<==
on

==> /sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/power/level <==
on

==> /sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/power/persist 
<==
1

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/power/runtime_active_kids
 <==
0

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/power/runtime_active_time
 <==
235136

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/power/runtime_enabled
 <==
forbidden

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/power/runtime_status
 <==
active

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/power/runtime_suspended_time
 <==
0

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/power/runtime_usage 
<==
1

==> /sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/power/wakeup <==
enabled

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/power/wakeup_abort_count
 <==
0

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/power/wakeup_active 
<==
0

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/power/wakeup_active_count
 <==
0

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/power/wakeup_count 
<==
0

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/power/wakeup_expire_count
 <==
0

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/power/wakeup_last_time_ms
 <==
21662182

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/power/wakeup_max_time_ms
 <==
0

==> 
/sys/devices/pci:00/:00:14.0/usb2/2-3/2-3.1/2-3.1.2/power/wakeup_total_time_ms
 <==
0

> For more information on what's happening, try collecting a usbmon trace 
> for bus 2 (see Documentation/usb/usbmon.txt).

Done.  I started a trace, plugged in the device, moved the mouse a
little (which moved the pointer for a moment and then stopped
producing any result), typed a couple of keys (which did work), moved
the mouse a bit more (which didn't), and unplugged the device.

Trace attached.


usbmon.pcapng.gz
Description: application/gzip

[PATCH v2 1/2] usb: xhci: plat: fix adding usb3-lpm-capable quirk

[Hauke Mehrtens]

The xhci->quirks member is overwritten in xhci_gen_setup() with the
quirks given through the module load parameter. Without this patch the
usb3-lpm-capable quirk will be over written before it gets used. This
patch moves the quirks code to the xhci_plat_quirks() callback function
which gets called directly after the quirks member variable is
overwritten with the module load parameter.

I do not have any hardware which is using usb3-lpm-capabls so I can not
test this on real hardware.

Signed-off-by: Hauke Mehrtens 
---
 drivers/usb/host/xhci-plat.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 770b6b0..4fb295b 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -39,12 +39,20 @@ static const struct xhci_driver_overrides 
xhci_plat_overrides __initconst = {
 
 static void xhci_plat_quirks(struct device *dev, struct xhci_hcd *xhci)
 {
+   struct platform_device  *pdev = to_platform_device(dev);
+   struct device_node  *node = pdev->dev.of_node;
+   struct usb_xhci_pdata   *pdata = dev_get_platdata(&pdev->dev);
+
/*
 * As of now platform drivers don't provide MSI support so we ensure
 * here that the generic code does not try to make a pci_dev from our
 * dev struct in order to setup MSI
 */
xhci->quirks |= XHCI_PLAT;
+
+   if ((node && of_property_read_bool(node, "usb3-lpm-capable")) ||
+   (pdata && pdata->usb3_lpm_capable))
+   xhci->quirks |= XHCI_LPM_SUPPORT;
 }
 
 /* called during probe() after chip reset completes */
@@ -118,7 +126,6 @@ MODULE_DEVICE_TABLE(of, usb_xhci_of_match);
 static int xhci_plat_probe(struct platform_device *pdev)
 {
struct device_node  *node = pdev->dev.of_node;
-   struct usb_xhci_pdata   *pdata = dev_get_platdata(&pdev->dev);
const struct of_device_id *match;
const struct hc_driver  *driver;
struct xhci_hcd *xhci;
@@ -204,10 +211,6 @@ static int xhci_plat_probe(struct platform_device *pdev)
goto disable_clk;
}
 
-   if ((node && of_property_read_bool(node, "usb3-lpm-capable")) ||
-   (pdata && pdata->usb3_lpm_capable))
-   xhci->quirks |= XHCI_LPM_SUPPORT;
-
if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
xhci->shared_hcd->can_do_streams = 1;
 
-- 
2.6.2

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

[PATCH 0/2] xhci: fix platform quirks and add fake doorbell

[Hauke Mehrtens]

These patches are needed to make the Broadcom XHCI controller work. We
will submit support for the controller later.

changes sinve v1:
 * I removed the bcma-hcd specific patches for now.

Hauke Mehrtens (1):
  usb: xhci: plat: fix adding usb3-lpm-capable quirk

Rafał Miłecki (1):
  usb: xhci: add Broadcom specific fake doorbell

 drivers/usb/host/xhci-plat.c | 16 +++
 drivers/usb/host/xhci.c  | 57 +---
 drivers/usb/host/xhci.h  |  1 +
 include/linux/usb/xhci_pdriver.h |  1 +
 4 files changed, 67 insertions(+), 8 deletions(-)

-- 
2.6.2

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

[PATCH v2 2/2] usb: xhci: add Broadcom specific fake doorbell

[Hauke Mehrtens]

From: Rafał Miłecki 

This fixes problem with controller seeing devices only in some small
percentage of cold boots.
This quirk is also added to the platform data so we can activate it
when we register our platform driver.

Signed-off-by: Rafał Miłecki 
Signed-off-by: Hauke Mehrtens 
---
 drivers/usb/host/xhci-plat.c |  3 +++
 drivers/usb/host/xhci.c  | 57 +---
 drivers/usb/host/xhci.h  |  1 +
 include/linux/usb/xhci_pdriver.h |  1 +
 4 files changed, 59 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 4fb295b..7cd274b 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -53,6 +53,9 @@ static void xhci_plat_quirks(struct device *dev, struct 
xhci_hcd *xhci)
if ((node && of_property_read_bool(node, "usb3-lpm-capable")) ||
(pdata && pdata->usb3_lpm_capable))
xhci->quirks |= XHCI_LPM_SUPPORT;
+
+   if (pdata && pdata->usb3_fake_doorbell)
+   xhci->quirks |= XHCI_FAKE_DOORBELL;
 }
 
 /* called during probe() after chip reset completes */
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 643d312..d49be9b 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -122,6 +122,39 @@ int xhci_halt(struct xhci_hcd *xhci)
return ret;
 }
 
+static int xhci_fake_doorbell(struct xhci_hcd *xhci, int slot_id)
+{
+   u32 temp;
+
+   /* alloc a virt device for slot */
+   if (!xhci_alloc_virt_device(xhci, slot_id, NULL, GFP_NOIO)) {
+   xhci_warn(xhci, "Could not allocate xHCI USB device data 
structures\n");
+   return -ENOMEM;
+   }
+
+   /* ring fake doorbell for slot_id ep 0 */
+   xhci_ring_ep_doorbell(xhci, slot_id, 0, 0);
+   usleep_range(1000, 1500);
+
+   /* read the status register to check if HSE is set or not? */
+   temp = readl(&xhci->op_regs->status);
+
+   /* clear HSE if set */
+   if (temp & STS_FATAL) {
+   xhci_dbg(xhci, "HSE problem detected, status: 0x%x\n", temp);
+   temp &= ~(0x1fff);
+   temp |= STS_FATAL;
+   writel(temp, &xhci->op_regs->status);
+   usleep_range(1000, 1500);
+   readl(&xhci->op_regs->status);
+   }
+
+   /* Free virt device */
+   xhci_free_virt_device(xhci, slot_id);
+
+   return 0;
+}
+
 /*
  * Set the run bit and wait for the host to be running.
  */
@@ -568,10 +601,25 @@ int xhci_init(struct usb_hcd *hcd)
 
 static int xhci_run_finished(struct xhci_hcd *xhci)
 {
-   if (xhci_start(xhci)) {
-   xhci_halt(xhci);
-   return -ENODEV;
+   int err;
+
+   err = xhci_start(xhci);
+   if (err) {
+   err = -ENODEV;
+   goto out_err;
+   }
+   if (xhci->quirks & XHCI_FAKE_DOORBELL) {
+   err = xhci_fake_doorbell(xhci, 1);
+   if (err)
+   goto out_err;
+
+   err = xhci_start(xhci);
+   if (err) {
+   err = -ENODEV;
+   goto out_err;
+   }
}
+
xhci->shared_hcd->state = HC_STATE_RUNNING;
xhci->cmd_ring_state = CMD_RING_STATE_RUNNING;
 
@@ -581,6 +629,9 @@ static int xhci_run_finished(struct xhci_hcd *xhci)
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
"Finished xhci_run for USB3 roothub");
return 0;
+out_err:
+   xhci_halt(xhci);
+   return err;
 }
 
 /*
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 9be7348..8c1faf4 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1631,6 +1631,7 @@ struct xhci_hcd {
 #define XHCI_BROKEN_STREAMS(1 << 19)
 #define XHCI_PME_STUCK_QUIRK   (1 << 20)
 #define XHCI_MTK_HOST  (1 << 21)
+#define XHCI_FAKE_DOORBELL (1 << 22)
unsigned intnum_active_eps;
unsigned intlimit_active_eps;
/* There are two roothubs to keep track of bus suspend info for */
diff --git a/include/linux/usb/xhci_pdriver.h b/include/linux/usb/xhci_pdriver.h
index 376654b..2b4ea5b 100644
--- a/include/linux/usb/xhci_pdriver.h
+++ b/include/linux/usb/xhci_pdriver.h
@@ -22,6 +22,7 @@
  */
 struct usb_xhci_pdata {
unsignedusb3_lpm_capable:1;
+   unsignedusb3_fake_doorbell:1;
 };
 
 #endif /* __USB_CORE_XHCI_PDRIVER_H */
-- 
2.6.2

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

Re: [PATCH v2 2/2] usb: xhci: add Broadcom specific fake doorbell

[Felipe Balbi]

Hi,

Hauke Mehrtens  writes:
> From: Rafał Miłecki 
>
> This fixes problem with controller seeing devices only in some small
> percentage of cold boots.
> This quirk is also added to the platform data so we can activate it
> when we register our platform driver.

it would've been nicer if you could add an erratum ID number for future
reference together with a more verbose discussion of the problem. You're
not describing what the problem is and that's important.

> Signed-off-by: Rafał Miłecki 
> Signed-off-by: Hauke Mehrtens 
> ---
>  drivers/usb/host/xhci-plat.c |  3 +++
>  drivers/usb/host/xhci.c  | 57 
> +---
>  drivers/usb/host/xhci.h  |  1 +
>  include/linux/usb/xhci_pdriver.h |  1 +
>  4 files changed, 59 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 4fb295b..7cd274b 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -53,6 +53,9 @@ static void xhci_plat_quirks(struct device *dev, struct 
> xhci_hcd *xhci)
>   if ((node && of_property_read_bool(node, "usb3-lpm-capable")) ||
>   (pdata && pdata->usb3_lpm_capable))
>   xhci->quirks |= XHCI_LPM_SUPPORT;
> +
> + if (pdata && pdata->usb3_fake_doorbell)
> + xhci->quirks |= XHCI_FAKE_DOORBELL;

whenever you add something via pdata, you _must_ make a similar DT change.

> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index 643d312..d49be9b 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -122,6 +122,39 @@ int xhci_halt(struct xhci_hcd *xhci)
>   return ret;
>  }
>  
> +static int xhci_fake_doorbell(struct xhci_hcd *xhci, int slot_id)
> +{
> + u32 temp;
> +
> + /* alloc a virt device for slot */
> + if (!xhci_alloc_virt_device(xhci, slot_id, NULL, GFP_NOIO)) {
> + xhci_warn(xhci, "Could not allocate xHCI USB device data 
> structures\n");
> + return -ENOMEM;
> + }
> +
> + /* ring fake doorbell for slot_id ep 0 */
> + xhci_ring_ep_doorbell(xhci, slot_id, 0, 0);
> + usleep_range(1000, 1500);
> +
> + /* read the status register to check if HSE is set or not? */
> + temp = readl(&xhci->op_regs->status);
> +
> + /* clear HSE if set */
> + if (temp & STS_FATAL) {
> + xhci_dbg(xhci, "HSE problem detected, status: 0x%x\n", temp);
> + temp &= ~(0x1fff);
> + temp |= STS_FATAL;
> + writel(temp, &xhci->op_regs->status);
> + usleep_range(1000, 1500);
> + readl(&xhci->op_regs->status);
> + }
> +
> + /* Free virt device */
> + xhci_free_virt_device(xhci, slot_id);
> +
> + return 0;
> +}
> +
>  /*
>   * Set the run bit and wait for the host to be running.
>   */
> @@ -568,10 +601,25 @@ int xhci_init(struct usb_hcd *hcd)
>  
>  static int xhci_run_finished(struct xhci_hcd *xhci)
>  {
> - if (xhci_start(xhci)) {
> - xhci_halt(xhci);
> - return -ENODEV;
> + int err;
> +
> + err = xhci_start(xhci);
> + if (err) {
> + err = -ENODEV;
> + goto out_err;
> + }

add a blank line here

> + if (xhci->quirks & XHCI_FAKE_DOORBELL) {
> + err = xhci_fake_doorbell(xhci, 1);
> + if (err)
> + goto out_err;
> +
> + err = xhci_start(xhci);
> + if (err) {
> + err = -ENODEV;
> + goto out_err;
> + }
>   }
> +
>   xhci->shared_hcd->state = HC_STATE_RUNNING;
>   xhci->cmd_ring_state = CMD_RING_STATE_RUNNING;
>  
> @@ -581,6 +629,9 @@ static int xhci_run_finished(struct xhci_hcd *xhci)
>   xhci_dbg_trace(xhci, trace_xhci_dbg_init,
>   "Finished xhci_run for USB3 roothub");
>   return 0;

and another one here.

> +out_err:
> + xhci_halt(xhci);
> + return err;
>  }
>  
>  /*
> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
> index 9be7348..8c1faf4 100644
> --- a/drivers/usb/host/xhci.h
> +++ b/drivers/usb/host/xhci.h
> @@ -1631,6 +1631,7 @@ struct xhci_hcd {
>  #define XHCI_BROKEN_STREAMS  (1 << 19)
>  #define XHCI_PME_STUCK_QUIRK (1 << 20)
>  #define XHCI_MTK_HOST(1 << 21)
> +#define XHCI_FAKE_DOORBELL   (1 << 22)
>   unsigned intnum_active_eps;
>   unsigned intlimit_active_eps;
>   /* There are two roothubs to keep track of bus suspend info for */
> diff --git a/include/linux/usb/xhci_pdriver.h 
> b/include/linux/usb/xhci_pdriver.h
> index 376654b..2b4ea5b 100644
> --- a/include/linux/usb/xhci_pdriver.h
> +++ b/include/linux/usb/xhci_pdriver.h
> @@ -22,6 +22,7 @@
>   */
>  struct usb_xhci_pdata {
>   unsignedusb3_lpm_capable:1;
> + unsignedusb3_fake_doorbell:1;

missing kernel doc for this new quirk.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v2 1/2] usb: xhci: plat: fix adding usb3-lpm-capable quirk

[kbuild test robot]

Hi Hauke,

[auto build test WARNING on usb/usb-testing]
[also build test WARNING on next-20151207]
[cannot apply to v4.4-rc4]

url:
https://github.com/0day-ci/linux/commits/Hauke-Mehrtens/usb-xhci-plat-fix-adding-usb3-lpm-capable-quirk/20151208-063433
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
usb-testing
config: i386-randconfig-x009-12070758 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/usb/host/xhci-plat.c: In function 'xhci_plat_probe':
>> drivers/usb/host/xhci-plat.c:128:22: warning: unused variable 'node' 
>> [-Wunused-variable]
 struct device_node *node = pdev->dev.of_node;
 ^

vim +/node +128 drivers/usb/host/xhci-plat.c

4efb2f69 Yoshihiro Shimoda 2015-11-24  112  .compatible = 
"renesas,xhci-r8a7791",
4efb2f69 Yoshihiro Shimoda 2015-11-24  113  .data = 
&xhci_plat_renesas_rcar_gen2,
4efb2f69 Yoshihiro Shimoda 2015-11-24  114  }, {
82487b71 Yoshihiro Shimoda 2015-11-24  115  .compatible = 
"renesas,xhci-r8a7793",
82487b71 Yoshihiro Shimoda 2015-11-24  116  .data = 
&xhci_plat_renesas_rcar_gen2,
82487b71 Yoshihiro Shimoda 2015-11-24  117  }, {
526a240f Yoshihiro Shimoda 2015-11-24  118  .compatible = 
"renesas,xhci-r8a7795",
526a240f Yoshihiro Shimoda 2015-11-24  119  .data = 
&xhci_plat_renesas_rcar_gen3,
526a240f Yoshihiro Shimoda 2015-11-24  120  }, {
4efb2f69 Yoshihiro Shimoda 2015-11-24  121  },
4efb2f69 Yoshihiro Shimoda 2015-11-24  122  };
4efb2f69 Yoshihiro Shimoda 2015-11-24  123  MODULE_DEVICE_TABLE(of, 
usb_xhci_of_match);
4efb2f69 Yoshihiro Shimoda 2015-11-24  124  #endif
4efb2f69 Yoshihiro Shimoda 2015-11-24  125  
3429e91a Sebastian Andrzej Siewior 2012-03-13  126  static int 
xhci_plat_probe(struct platform_device *pdev)
3429e91a Sebastian Andrzej Siewior 2012-03-13  127  {
20f6fdd0 Pratyush Anand2014-07-04 @128  struct device_node  
*node = pdev->dev.of_node;
4efb2f69 Yoshihiro Shimoda 2015-11-24  129  const struct 
of_device_id *match;
3429e91a Sebastian Andrzej Siewior 2012-03-13  130  const struct hc_driver  
*driver;
3429e91a Sebastian Andrzej Siewior 2012-03-13  131  struct xhci_hcd 
*xhci;
3429e91a Sebastian Andrzej Siewior 2012-03-13  132  struct resource 
*res;
3429e91a Sebastian Andrzej Siewior 2012-03-13  133  struct usb_hcd  
*hcd;
4718c177 Gregory CLEMENT   2014-05-15  134  struct clk  
*clk;
3429e91a Sebastian Andrzej Siewior 2012-03-13  135  int 
ret;
3429e91a Sebastian Andrzej Siewior 2012-03-13  136  int 
irq;

:: The code at line 128 was first introduced by commit
:: 20f6fdd01c2c0de9cc1109083222edded24c5350 xhci: Platform: Set xhci lpm 
support quirk based on platform data

:: TO: Pratyush Anand 
:: CC: Greg Kroah-Hartman 

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


.config.gz
Description: Binary data

Re: [PATCH v2 2/2] usb: xhci: add Broadcom specific fake doorbell

[Hauke Mehrtens]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/07/2015 11:39 PM, Felipe Balbi wrote:
> 
> Hi,
> 
> Hauke Mehrtens  writes:
>> From: Rafał Miłecki 
>> 
>> This fixes problem with controller seeing devices only in some
>> small percentage of cold boots. This quirk is also added to the
>> platform data so we can activate it when we register our platform
>> driver.
> 
> it would've been nicer if you could add an erratum ID number for
> future reference together with a more verbose discussion of the
> problem. You're not describing what the problem is and that's
> important.

I do not have access to the documentation for this SOC, I hope the
people from Broadcom with access to such documentation can help out here
.

>> Signed-off-by: Rafał Miłecki  Signed-off-by:
>> Hauke Mehrtens  --- 
>> drivers/usb/host/xhci-plat.c |  3 +++ drivers/usb/host/xhci.c
>> | 57 +--- 
>> drivers/usb/host/xhci.h  |  1 + 
>> include/linux/usb/xhci_pdriver.h |  1 + 4 files changed, 59
>> insertions(+), 3 deletions(-)
>> 
>> diff --git a/drivers/usb/host/xhci-plat.c
>> b/drivers/usb/host/xhci-plat.c index 4fb295b..7cd274b 100644 ---
>> a/drivers/usb/host/xhci-plat.c +++
>> b/drivers/usb/host/xhci-plat.c @@ -53,6 +53,9 @@ static void
>> xhci_plat_quirks(struct device *dev, struct xhci_hcd *xhci) if
>> ((node && of_property_read_bool(node, "usb3-lpm-capable")) || 
>> (pdata && pdata->usb3_lpm_capable)) xhci->quirks |=
>> XHCI_LPM_SUPPORT; + +if (pdata && pdata->usb3_fake_doorbell) +
>> xhci->quirks |= XHCI_FAKE_DOORBELL;
> 
> whenever you add something via pdata, you _must_ make a similar DT
> change.

Ok, will do so.

>> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c 
>> index 643d312..d49be9b 100644 --- a/drivers/usb/host/xhci.c +++
>> b/drivers/usb/host/xhci.c @@ -122,6 +122,39 @@ int
>> xhci_halt(struct xhci_hcd *xhci) return ret; }
>> 
>> +static int xhci_fake_doorbell(struct xhci_hcd *xhci, int
>> slot_id) +{ +u32 temp; + +   /* alloc a virt device for slot */ +
>> if (!xhci_alloc_virt_device(xhci, slot_id, NULL, GFP_NOIO)) { +
>> xhci_warn(xhci, "Could not allocate xHCI USB device data
>> structures\n"); +return -ENOMEM; +   } + +   /* ring fake 
>> doorbell
>> for slot_id ep 0 */ +xhci_ring_ep_doorbell(xhci, slot_id, 0,
>> 0); +usleep_range(1000, 1500); + +   /* read the status register
>> to check if HSE is set or not? */ +  temp =
>> readl(&xhci->op_regs->status); + +   /* clear HSE if set */ +if
>> (temp & STS_FATAL) { +   xhci_dbg(xhci, "HSE problem detected,
>> status: 0x%x\n", temp); +temp &= ~(0x1fff); +temp |=
>> STS_FATAL; + writel(temp, &xhci->op_regs->status); +
>> usleep_range(1000, 1500); +  readl(&xhci->op_regs->status); +
>> } 
>> + +  /* Free virt device */ +xhci_free_virt_device(xhci,
>> slot_id); + +return 0; +} + /* * Set the run bit and wait for
>> the host to be running. */ @@ -568,10 +601,25 @@ int
>> xhci_init(struct usb_hcd *hcd)
>> 
>> static int xhci_run_finished(struct xhci_hcd *xhci) { -  if
>> (xhci_start(xhci)) { -   xhci_halt(xhci); -  return 
>> -ENODEV; +   int
>> err; + + err = xhci_start(xhci); +   if (err) { +err = 
>> -ENODEV; +
>> goto out_err; +  }
> 
> add a blank line here

Ok, will do so.

>> +if (xhci->quirks & XHCI_FAKE_DOORBELL) { +  err =
>> xhci_fake_doorbell(xhci, 1); +   if (err) +  
>> goto out_err; + +
>> err = xhci_start(xhci); +if (err) { +err = 
>> -ENODEV; +goto
>> out_err; +   } } + xhci->shared_hcd->state = HC_STATE_RUNNING; 
>> xhci->cmd_ring_state = CMD_RING_STATE_RUNNING;
>> 
>> @@ -581,6 +629,9 @@ static int xhci_run_finished(struct xhci_hcd
>> *xhci) xhci_dbg_trace(xhci, trace_xhci_dbg_init, "Finished
>> xhci_run for USB3 roothub"); return 0;
> 
> and another one here.

Ok, will do so.

>> +out_err: +  xhci_halt(xhci); +  return err; }
>> 
>> /* diff --git a/drivers/usb/host/xhci.h
>> b/drivers/usb/host/xhci.h index 9be7348..8c1faf4 100644 ---
>> a/drivers/usb/host/xhci.h +++ b/drivers/usb/host/xhci.h @@
>> -1631,6 +1631,7 @@ struct xhci_hcd { #define XHCI_BROKEN_STREAMS
>> (1 << 19) #define XHCI_PME_STUCK_QUIRK   (1 << 20) #define
>> XHCI_MTK_HOST(1 << 21) +#define XHCI_FAKE_DOORBELL   (1 << 
>> 22) 
>> unsigned int num_active_eps; unsigned int
>> limit_active_eps; /*
>> There are two roothubs to keep track of bus suspend info for */ 
>> diff --git a/include/linux/usb/xhci_pdriver.h
>> b/include/linux/usb/xhci_pdriver.h index 376654b..2b4ea5b 100644 
>> --- a/include/linux/usb/xhci_pdriver.h +++
>> b/include/linux/usb/xhci_pdriver.h @@ -22,6 +22,7 @@ */ struct
>> usb_xhci_pdata { unsignedusb3_lpm_capable:1; +   unsigned
>> usb3_fake_doorbell:1;
> 
> missin

Re: [PATCH v2 1/2] usb: xhci: plat: fix adding usb3-lpm-capable quirk

[Hauke Mehrtens]

On 12/07/2015 11:43 PM, kbuild test robot wrote:
> Hi Hauke,
> 
> [auto build test WARNING on usb/usb-testing]
> [also build test WARNING on next-20151207]
> [cannot apply to v4.4-rc4]
> 
> url:
> https://github.com/0day-ci/linux/commits/Hauke-Mehrtens/usb-xhci-plat-fix-adding-usb3-lpm-capable-quirk/20151208-063433
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
> usb-testing
> config: i386-randconfig-x009-12070758 (attached as .config)
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386 
> 
> All warnings (new ones prefixed by >>):
> 
>drivers/usb/host/xhci-plat.c: In function 'xhci_plat_probe':
>>> drivers/usb/host/xhci-plat.c:128:22: warning: unused variable 'node' 
>>> [-Wunused-variable]
>  struct device_node *node = pdev->dev.of_node;
>  ^
> 

This is based on usb-next and not v4.4-rc4. Should I base it on top of
v4.4-rc4 instead?

Hauke

--
To unsubscribe from this list: send the line "unsubscribe 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: Infrastructure for zerocopy I/O

[Steinar H. Gunderson]

On Mon, Dec 07, 2015 at 10:45:55AM -0500, Alan Stern wrote:
>> Here we are. Lightly tested, I believe all comments should be addressed.
> This looks quite good.  I have only a couple of comments.

Excellent. I'm sorry we've needed so many rounds; this is what happens when
you pick up someone else's patch against a code base you've never touched
before. :-)

>>  - Zerocopy; data no longer needs to be copied between the userspace
>>and the kernel, but can instead be read directly by the driver from
>>userspace's buffers. This works for both bulk and isochronous transfers;
>>isochronous also no longer need to memset() the buffer to zero to avoid
>>leaking kernel data.
> Actually it now works for control and interrupt too, although there's
> not much point using it for them.

Updated description.

>> +as->usbm = find_memory_area(ps, uurb);
>> +if (IS_ERR(as->usbm)) {
>> +ret = PTR_ERR(as->usbm);
>> +goto error;
> Hmmm, and then what will happen when the error-handling code does this:

Urg, you pointed this out earlier and I didn't fix it. I'm setting it to
NULL in the error path now.

>> +}
>> +
>> +/* do not use SG buffers when memory mapped segments
>> + * are in use
>> + */
>> +if (!as->usbm) {
> You mean "if (as->usbm)".

Yes. Test now inverted.

>> +num_sgs = 0;
>> +}
> Braces aren't needed.

Went to the dentist to take them off.

> It looks odd repeating the "if (as->usbm)" test like this.  You can merge
> the stuff here into the "else" clause of the preceding code.

Merged. Updated patch below.

/* Steinar */

>From ec536f8abc16d9a920a0891db3bc9b6c05c2c43f Mon Sep 17 00:00:00 2001
From: "Steinar H. Gunderson" 
Date: Thu, 26 Nov 2015 01:19:13 +0100
Subject: [PATCH] Add support for usbfs zerocopy.

Add a new interface for userspace to preallocate memory that can be
used with usbfs. This gives two primary benefits:

 - Zerocopy; data no longer needs to be copied between the userspace
   and the kernel, but can instead be read directly by the driver from
   userspace's buffers. This works for all kinds of transfers (even if
   nonsensical for control and interrupt transfers); isochronous also
   no longer need to memset() the buffer to zero to avoid leaking kernel data.

 - Once the buffers are allocated, USB transfers can no longer fail due to
   memory fragmentation; previously, long-running programs could run into
   problems finding a large enough contiguous memory chunk, especially on
   embedded systems or at high rates.

Memory is allocated by using mmap() against the usbfs file descriptor,
and similarly deallocated by munmap(). Once memory has been allocated,
using it as pointers to a bulk or isochronous operation means you will
automatically get zerocopy behavior. Note that this also means you cannot
modify outgoing data until the transfer is complete. The same holds for
data on the same cache lines as incoming data; DMA modifying them at the
same time could lead to your changes being overwritten.

Largely based on a patch by Markus Rechberger with some updates. The original
patch can be found at:

  http://sundtek.de/support/devio_mmap_v0.4.diff

Signed-off-by: Steinar H. Gunderson 
Signed-off-by: Markus Rechberger 
---
 drivers/usb/core/devio.c | 227 ++-
 1 file changed, 203 insertions(+), 24 deletions(-)

diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 38ae877c..5faf1a0 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -50,6 +50,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -69,6 +70,7 @@ struct usb_dev_state {
spinlock_t lock;/* protects the async urb lists */
struct list_head async_pending;
struct list_head async_completed;
+   struct list_head memory_list;
wait_queue_head_t wait; /* wake up if a request completed */
unsigned int discsignr;
struct pid *disc_pid;
@@ -79,6 +81,17 @@ struct usb_dev_state {
u32 disabled_bulk_eps;
 };
 
+struct usb_memory {
+   struct list_head memlist;
+   int vma_use_count;
+   int urb_use_count;
+   u32 size;
+   void *mem;
+   dma_addr_t dma_handle;
+   unsigned long vm_start;
+   struct usb_dev_state *ps;
+};
+
 struct async {
struct list_head asynclist;
struct usb_dev_state *ps;
@@ -89,6 +102,7 @@ struct async {
void __user *userbuffer;
void __user *userurb;
struct urb *urb;
+   struct usb_memory *usbm;
unsigned int mem_usage;
int status;
u32 secid;
@@ -157,6 +171,107 @@ static int connected(struct usb_dev_state *ps)
ps->dev->state != USB_STATE_NOTATTACHED);
 }
 
+static void dec_usb_memory_use_count(struct usb_memory *usbm, int *count)
+{
+   struct usb_dev_state *ps = usbm->ps;
+   unsigned long flags;
+
+   spin_lock_irqsave(&ps->lock, flags);
+

Re: [PATCH v2 2/2] usb: xhci: add Broadcom specific fake doorbell

[Felipe Balbi]

Hi,

Hauke Mehrtens  writes:
>> it would've been nicer if you could add an erratum ID number for
>> future reference together with a more verbose discussion of the
>> problem. You're not describing what the problem is and that's
>> important.
>
> I do not have access to the documentation for this SOC, I hope the
> people from Broadcom with access to such documentation can help out
> here.

oh, that's a shame. Yeah, let's hope broadcom can give more details
about the need for this erratum workaround.

thanks

-- 
balbi


signature.asc
Description: PGP signature

[PATCH v2] usb: host: iounmap before return

[Geyslan G. Bem]

This patch fixes a 'quirk_usb_handoff_xhci()' branch return that
was not unmapping correctly.

Coccinelle: scripts/coccinelle/free/iounmap.cocci

Signed-off-by: Geyslan G. Bem 
---
 drivers/usb/host/pci-quirks.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 26cb8c8..ee4426b 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -992,7 +992,7 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
if ((ext_cap_offset + sizeof(val)) > len) {
/* We're reading garbage from the controller */
dev_warn(&pdev->dev, "xHCI controller failing to respond");
-   return;
+   goto out;
}
val = readl(base + ext_cap_offset);
 
@@ -1055,6 +1055,7 @@ hc_init:
 XHCI_MAX_HALT_USEC, val);
}
 
+ out:
iounmap(base);
 }
 
-- 
2.6.3

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

Re: [PATCH] usb: host: iounmap before return

[Geyslan G. Bem]

2015-12-07 8:37 GMT-03:00 Sergei Shtylyov :
> Hello.
>
> On 12/07/2015 12:30 PM, Lu Baolu wrote:
>
>>> This patch fixes a 'quirk_usb_handoff_xhci()' branch return that was not
>>> unmapping correctly.
>>>
>>> Coccinelle: scripts/coccinelle/free/iounmap.cocci
>>>
>>> Signed-off-by: Geyslan G. Bem 
>>> ---
>>>   drivers/usb/host/pci-quirks.c | 3 ++-
>>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/host/pci-quirks.c
>>> b/drivers/usb/host/pci-quirks.c
>>> index f940056..64150dd 100644
>>> --- a/drivers/usb/host/pci-quirks.c
>>> +++ b/drivers/usb/host/pci-quirks.c
>>> @@ -990,7 +990,7 @@ static void quirk_usb_handoff_xhci(struct pci_dev
>>> *pdev)
>>> /* We're reading garbage from the controller */
>>> dev_warn(&pdev->dev,
>>>  "xHCI controller failing to respond");
>>> -   return;
>>> +   goto out;
>>
>>
>> If "out" is only used here, why not iounmap and return directly here?
>
>
>Why repeat the code? Nah, bad idea.
>
>>> }
>>>
>>> if (!ext_cap_offset)
>>> @@ -1062,6 +1062,7 @@ hc_init:
>>>  XHCI_MAX_HALT_USEC, val);
>>> }
>>>
>>> +out:
>>> iounmap(base);
>>>   }
>>>
>
> MBR, Sergei
>

Look for:
[PATCH v2] usb: host: iounmap before return


-- 
Regards,

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

[PATCH] usb: gadget: lpc32xxx_udc: clean up and sort include directives out

[Vladimir Zapolskiy]

Remove mach/irq.h from the list of included headers, there is no
compilation dependency on this include file, and the change is needed
to prevent a compilation failure, when mach/irq.h is removed.

Additionally remove other unneeded includes and sort out their order.

Signed-off-by: Vladimir Zapolskiy 
---
 drivers/usb/gadget/udc/lpc32xx_udc.c | 35 +++
 1 file changed, 11 insertions(+), 24 deletions(-)

diff --git a/drivers/usb/gadget/udc/lpc32xx_udc.c 
b/drivers/usb/gadget/udc/lpc32xx_udc.c
index 00b5006..79fe6b7 100644
--- a/drivers/usb/gadget/udc/lpc32xx_udc.c
+++ b/drivers/usb/gadget/udc/lpc32xx_udc.c
@@ -28,42 +28,29 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 
-#include 
-#include 
-#include 
+#include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
+#include 
+#include 
+#include 
 #include 
+#include 
+#include 
+#include 
 #include 
-#include 
+#include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-#include 
 #ifdef CONFIG_USB_GADGET_DEBUG_FILES
 #include 
 #include 
 #endif
 
+#include 
+#include 
+
 /*
  * USB device configuration structure
  */
-- 
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] usb: ohci: nxp: clean up included header files

[Vladimir Zapolskiy]

Remove mach/irq.h from the list of included headers, there is no
compilation dependency on this include file, the change is needed
to prevent a compilation failure, when mach/irq.h is removed.

Additionally remove other unneeded includes.

Signed-off-by: Vladimir Zapolskiy 
---
 drivers/usb/host/ohci-nxp.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/usb/host/ohci-nxp.c b/drivers/usb/host/ohci-nxp.c
index cfa9427..ebacf97 100644
--- a/drivers/usb/host/ohci-nxp.c
+++ b/drivers/usb/host/ohci-nxp.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -32,13 +31,7 @@
 
 #include "ohci.h"
 
-
 #include 
-#include 
-#include 
-
-#include 
-#include 
 
 #define USB_CONFIG_BASE0x3102
 #define PWRMAN_BASE0x40004000
-- 
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: [PATCHv2 1/2] extcon: add driver for Intel USB mux

[Chanwoo Choi]

Hi,

On 2015년 12월 07일 21:52, Heikki Krogerus wrote:
> Hi,
> 
> On Mon, Dec 07, 2015 at 10:24:22AM +0900, Chanwoo Choi wrote:
>> Hi,
>>
>> On 2015년 12월 04일 17:51, Heikki Krogerus wrote:
>>> Hi,
>>>
 I do never want to add some specific funtcion for only this driver.
 I think is not appropriate way.
 - intel_usb_mux_unregister
 - intel_usb_mux_register

 The client driver using extcon driver should use the standard extcon API
 for code consistency. Also, I'll do the more detailed review for this 
 patch.
>>>
>>> The internal mux we are controlling here is physically separate
>>> device. Ideally we could populate child device for it, but since that
>>> is not possible because of the resource conflict, we use the library
>>> approach, which is really not that uncommon.
>>
>> New added functions for only specific device driver is not library. 
>>
>> The all device drivers which is included in some framework should
>> connect to the other device driver through only framework API as following:
>>    
>>  | EXTCON framework |<>| USB framework |
>>    - 
>>  ||
>>  ||
>>  extcon-intel-usb.c pci-quirks.c
>>
>> But, in this case, added funticon is just direct call function
>> without any standard API. The below case is never appropriate implementation.
>>
>>    
>>  | EXTCON framework |  | USB framework |
>>    - 
>>  ||
>>  ||
>>  extcon-intel-usb.c <  pci-quirks.c
> 
> Man.. Cal it what you want, but like I said, exposing driver specific
> API is not ideal, but it is acceptable in special cases like this
> where we simply are not able to populate child device. If nothing
> else, then at least the fact that the code for the mux would otherwise
> need to be duplicated, is enough to justify it.
> 
>>> I don't think I agree with your point even at general level. The
>>> control required to handle this mux, even though simple, is enough to
>>> deserve to be separated from xHCI code. xHCI should not need to care
>>> about anything else expect does it have the mux, i.e. does it need to
>>> register it or not. It should not need to care about how it needs to
>>> be controlled or even what it is. We may decide to create something
>>> else out of it instead of an extcon device later.
>>>
>>> But in any case, the mux is available on all new Intel platforms, but
>>> it needs to be controlled by OS only in few "special" cases. We can
>>> not force xHCI (or pci-quirks.c to be more precise) to be aware of
>>> these "special" cases. The only way to make it work like that would
>>> bet by using ifdefs, and we really really don't want that.
>>>
>>> And please also note that, though for now we only expect the mux
>>> control registers to be part of xHCI MMIO, that is not always the
>>> case. The control registers are part of the device controller MMIO on
>>> some platforms. We do not want to duplicate the whole control of the
>>> mux if/when we need the OS to be in control of it on a platform that
>>> has those control registers mapped somewhere else then xHCI MMIO,
>>>
>>> So I would say that we have pretty good justification for separating
>>> the mux control, which means unfortunately custom API in this case.
>>>
>>> But if you would prefer that we put the files somewhere else then
>>> drivers/extcon/ and include/linux/extcon/ I'm fine with that. If you
>>> like, we can put it to drivers/usb/host/ as that is where
>>> pci-quirks.c is. That way I think we can also put the header to
>>> include/usb/.
>>
>> There are the two type of extcon drivers as following:
>> - provider extcon driver which use the devm_extcon_dev_register() and 
>> extcon_set_cable_state().
>> - client extcon driver which use the extcon_register_notifier() and 
>> extcon_set_cable_state() usually.
>> The drivers/extcon directory only includes the provider extcon driver.
>>
>> You make the extcon-intel-usb.c as provider extcon driver.
>> At the same time, this driver is used for client extcon driver
>> by using the extcon_register_notifier(). If you want to recevie
>> the notification from extcon_register_notifier(), the extcon device
>> should update the state of external connector throught 
>> extcon_set_cable_state().
>> But, this driver don' use the extcon_set_cable_state().
>>
>> I think that you should divide it according to role.
>>
>> Again, the usage case of extcon have to consist of both provider extcon 
>> driver
>> and client extcon driver. If there is no provider extcon driver,
>> client extcon driver don't receive the any notification of external connector
>> from provider extcon driver.
> 
> What you are saying is that i

[PATCH 0/3] USB: add generic onboard USB HUB driver

[Peter Chen]

Hi all,

There is a known issue that the USB code can't handle USB HUB's
external pins well, in that case, it may cause some onboard
USB HUBs can't work since their PHY's clock or reset pin needs to
operate.

The user reported this issue at below:
http://www.spinics.net/lists/linux-usb/msg131502.html

In this patch set, I add a generic onboard USB HUB driver to
handle this problem, the external signals will be configured
before usb controller's initialization, it much likes we did
it at board code before.

The user needs to add this generic hub node at dts or add releted
platform data to support it.

The udoo users, help to test please.

Peter Chen (3):
  usb: misc: generic_onboard_hub: add generic onboard USB HUB driver
  doc: dt-binding: generic onboard USB HUB
  ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property

 .../bindings/usb/generic-onboard-hub.txt   |  28 
 MAINTAINERS|   7 +
 arch/arm/boot/dts/imx6qdl-udoo.dtsi|  25 +---
 drivers/usb/misc/Kconfig   |   9 ++
 drivers/usb/misc/Makefile  |   1 +
 drivers/usb/misc/generic_onboard_hub.c | 162 +
 include/linux/usb/generic_onboard_hub.h|  11 ++
 7 files changed, 224 insertions(+), 19 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/usb/generic-onboard-hub.txt
 create mode 100644 drivers/usb/misc/generic_onboard_hub.c
 create mode 100644 include/linux/usb/generic_onboard_hub.h

-- 
1.9.1

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

[PATCH 1/3] usb: misc: generic_onboard_hub: add generic onboard USB HUB driver

[Peter Chen]

Current USB HUB driver lacks of platform interfaces to configure
external signal on HUB chip, eg, the PHY input clock and gpio reset
pin for HUB, these kinds of HUBs are usually soldered at the board,
and they are not hot-plug USB devices.

With this patch, the user can configure the HUB's pins at platform
part (through dts or platform), and these configuration will be
effective before the USB bus can be used, we use subsys_initcall
for this driver.

Signed-off-by: Peter Chen 
---
 MAINTAINERS |   7 ++
 drivers/usb/misc/Kconfig|   9 ++
 drivers/usb/misc/Makefile   |   1 +
 drivers/usb/misc/generic_onboard_hub.c  | 162 
 include/linux/usb/generic_onboard_hub.h |  11 +++
 5 files changed, 190 insertions(+)
 create mode 100644 drivers/usb/misc/generic_onboard_hub.c
 create mode 100644 include/linux/usb/generic_onboard_hub.h

diff --git a/MAINTAINERS b/MAINTAINERS
index e9caa4b..cc1981e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11121,6 +11121,13 @@ S: Maintained
 F: Documentation/usb/ohci.txt
 F: drivers/usb/host/ohci*
 
+USB Generic Onboard HUB Driver
+M: Peter Chen 
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git
+L: linux-usb@vger.kernel.org
+S: Maintained
+F: drivers/usb/misc/generic_onboard_hub.c
+
 USB OTG FSM (Finite State Machine)
 M: Peter Chen 
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git
diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index f7a7fc2..8921cae 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -268,3 +268,12 @@ config USB_CHAOSKEY
 
  To compile this driver as a module, choose M here: the
  module will be called chaoskey.
+
+config USB_ONBOARD_HUB
+   tristate "Generic USB Onboard HUB"
+   help
+ Say Y here if your board has an onboard HUB, and this hub needs
+ to control its PHY clock and reset pin through external signals.
+ If you are not sure, say N.
+
+ To compile this driver as a module, choose M here.
diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
index 45fd4ac..da52e9a 100644
--- a/drivers/usb/misc/Makefile
+++ b/drivers/usb/misc/Makefile
@@ -29,3 +29,4 @@ obj-$(CONFIG_USB_CHAOSKEY)+= chaoskey.o
 
 obj-$(CONFIG_USB_SISUSBVGA)+= sisusbvga/
 obj-$(CONFIG_USB_LINK_LAYER_TEST)  += lvstest.o
+obj-$(CONFIG_USB_ONBOARD_HUB)  += generic_onboard_hub.o
diff --git a/drivers/usb/misc/generic_onboard_hub.c 
b/drivers/usb/misc/generic_onboard_hub.c
new file mode 100644
index 000..df722a0
--- /dev/null
+++ b/drivers/usb/misc/generic_onboard_hub.c
@@ -0,0 +1,162 @@
+/*
+ * usb_hub_generic.c   The generic onboard USB HUB driver
+ *
+ * Copyright (C) 2015 Freescale Semiconductor, Inc.
+ * Author: Peter Chen 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+/*
+ * This driver is only for the USB HUB devices which need to control
+ * their external pins(clock, reset, etc), and these USB HUB devices
+ * are soldered at the board.
+ */
+
+#define DEBUG
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct usb_hub_generic_data {
+   struct clk *clk;
+};
+
+static int usb_hub_generic_probe(struct platform_device *pdev)
+{
+   struct device *dev = &pdev->dev;
+   struct usb_hub_generic_platform_data *pdata = dev->platform_data;
+   struct usb_hub_generic_data *hub_data;
+   int reset_pol = 0, duration_us = 50, ret = 0;
+   struct gpio_desc *gpiod_reset = NULL;
+
+   hub_data = devm_kzalloc(dev, sizeof(*hub_data), GFP_KERNEL);
+   if (!hub_data)
+   return -ENOMEM;
+
+   if (dev->of_node) {
+   struct device_node *node = dev->of_node;
+
+   hub_data->clk = devm_clk_get(dev, "external_clk");
+   if (IS_ERR(hub_data->clk)) {
+   dev_dbg(dev, "Can't get external clock: %ld\n",
+   PTR_ERR(hub_data->clk));
+   }
+
+   /*
+* Try to get the information for HUB reset, the
+* default setting like below:
+*
+* - Reset state is low
+* - The duration is 50us
+*/
+   if (of_find_property(no

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

[Peter Chen]

The current dts describes USB HUB's property at USB controller's
entry, it is improper. Fix it by using a generic USB HUB entry.

Signed-off-by: Peter Chen 
---
 arch/arm/boot/dts/imx6qdl-udoo.dtsi | 25 ++---
 1 file changed, 6 insertions(+), 19 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-udoo.dtsi 
b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
index 1211da8..9416d75 100644
--- a/arch/arm/boot/dts/imx6qdl-udoo.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
@@ -18,21 +18,12 @@
reg = <0x1000 0x4000>;
};
 
-   regulators {
-   compatible = "simple-bus";
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   reg_usb_h1_vbus: regulator@0 {
-   compatible = "regulator-fixed";
-   reg = <0>;
-   regulator-name = "usb_h1_vbus";
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   enable-active-high;
-   startup-delay-us = <2>; /* USB2415 requires a POR of 1 
us minimum */
-   gpio = <&gpio7 12 0>;
-   };
+   usb_hub1 {
+   compatible = "generic-onboard-hub";
+   clocks = <&clks IMX6QDL_CLK_CKO>;
+   clock-names = "external_clk";
+   hub-reset-gpios = <&gpio7 12 0>;
+   hub-reset-duration-us = <2>;
};
 };
 
@@ -119,10 +110,6 @@
 };
 
 &usbh1 {
-   pinctrl-names = "default";
-   pinctrl-0 = <&pinctrl_usbh>;
-   vbus-supply = <®_usb_h1_vbus>;
-   clocks = <&clks 201>;
status = "okay";
 };
 
-- 
1.9.1

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

[PATCH 2/3] doc: dt-binding: generic onboard USB HUB

[Peter Chen]

Add dt-binding documentation for generic onboard USB HUB.

Signed-off-by: Peter Chen 
---
 .../bindings/usb/generic-onboard-hub.txt   | 28 ++
 1 file changed, 28 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/usb/generic-onboard-hub.txt

diff --git a/Documentation/devicetree/bindings/usb/generic-onboard-hub.txt 
b/Documentation/devicetree/bindings/usb/generic-onboard-hub.txt
new file mode 100644
index 000..ea92205
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/generic-onboard-hub.txt
@@ -0,0 +1,28 @@
+Generic Onboard USB HUB
+
+Required properties:
+- compatible: should be "generic-onboard-hub"
+
+Optional properties:
+- clocks: the input clock for HUB.
+
+- clock-names: Should be "external_clk"
+
+- hub-reset-gpios: Should specify the GPIO for reset.
+
+- hub-reset-active-high: the active reset signal is high, if this property is
+  not set, the active reset signal is low.
+
+- hub-reset-duration-us: the duration for assert reset signal, the time unit
+  is microsecond.
+
+Example:
+
+   usb_hub1 {
+   compatible = "generic-onboard-hub";
+   clocks = <&clks IMX6QDL_CLK_CKO>;
+   clock-names = "external_clk";
+   hub-reset-gpios = <&gpio7 12 0>;
+   hub-reset-active-high;
+   hub-reset-duration-us = <2>;
+   };
-- 
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 2/3] doc: dt-binding: generic onboard USB HUB

[Fabio Estevam]

On Mon, Dec 7, 2015 at 11:37 PM, Peter Chen  wrote:
> Add dt-binding documentation for generic onboard USB HUB.
>
> Signed-off-by: Peter Chen 
> ---
>  .../bindings/usb/generic-onboard-hub.txt   | 28 
> ++
>  1 file changed, 28 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/usb/generic-onboard-hub.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/generic-onboard-hub.txt 
> b/Documentation/devicetree/bindings/usb/generic-onboard-hub.txt
> new file mode 100644
> index 000..ea92205
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/generic-onboard-hub.txt
> @@ -0,0 +1,28 @@
> +Generic Onboard USB HUB
> +
> +Required properties:
> +- compatible: should be "generic-onboard-hub"
> +
> +Optional properties:
> +- clocks: the input clock for HUB.
> +
> +- clock-names: Should be "external_clk"
> +
> +- hub-reset-gpios: Should specify the GPIO for reset.
> +
> +- hub-reset-active-high: the active reset signal is high, if this property is
> +  not set, the active reset signal is low.
> +
> +- hub-reset-duration-us: the duration for assert reset signal, the time unit
> +  is microsecond.
> +
> +Example:
> +
> +   usb_hub1 {
> +   compatible = "generic-onboard-hub";
> +   clocks = <&clks IMX6QDL_CLK_CKO>;
> +   clock-names = "external_clk";
> +   hub-reset-gpios = <&gpio7 12 0>;
> +   hub-reset-active-high;

I think you could drop the 'hub-reset-active-high' property and do
like this instead:

hub-reset-gpios = <&gpio7 12 GPIO_ACTIVE_HIGH>;

or

hub-reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
--
To unsubscribe from this list: send the line "unsubscribe 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/3] usb: misc: generic_onboard_hub: add generic onboard USB HUB driver

[Felipe Balbi]

Hi,

Peter Chen  writes:
> diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
> index 45fd4ac..da52e9a 100644
> --- a/drivers/usb/misc/Makefile
> +++ b/drivers/usb/misc/Makefile
> @@ -29,3 +29,4 @@ obj-$(CONFIG_USB_CHAOSKEY)  += chaoskey.o
>  
>  obj-$(CONFIG_USB_SISUSBVGA)  += sisusbvga/
>  obj-$(CONFIG_USB_LINK_LAYER_TEST)+= lvstest.o
> +obj-$(CONFIG_USB_ONBOARD_HUB)+= generic_onboard_hub.o
> diff --git a/drivers/usb/misc/generic_onboard_hub.c 
> b/drivers/usb/misc/generic_onboard_hub.c
> new file mode 100644
> index 000..df722a0
> --- /dev/null
> +++ b/drivers/usb/misc/generic_onboard_hub.c
> @@ -0,0 +1,162 @@
> +/*
> + * usb_hub_generic.c The generic onboard USB HUB driver
> + *
> + * Copyright (C) 2015 Freescale Semiconductor, Inc.
> + * Author: Peter Chen 
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2  of
> + * the License as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + */
> +
> +/*
> + * This driver is only for the USB HUB devices which need to control
> + * their external pins(clock, reset, etc), and these USB HUB devices
> + * are soldered at the board.
> + */
> +
> +#define DEBUG

nope

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

 ?

> +struct usb_hub_generic_data {
> + struct clk *clk;

seriously ? Is this really all ? What about that reset line below ?

In fact, that reset line should be using a generic reset-gpio.c instead
of a raw gpio.

> +static int usb_hub_generic_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct usb_hub_generic_platform_data *pdata = dev->platform_data;
> + struct usb_hub_generic_data *hub_data;
> + int reset_pol = 0, duration_us = 50, ret = 0;
> + struct gpio_desc *gpiod_reset = NULL;
> +
> + hub_data = devm_kzalloc(dev, sizeof(*hub_data), GFP_KERNEL);
> + if (!hub_data)
> + return -ENOMEM;
> +
> + if (dev->of_node) {
> + struct device_node *node = dev->of_node;
> +
> + hub_data->clk = devm_clk_get(dev, "external_clk");
> + if (IS_ERR(hub_data->clk)) {
> + dev_dbg(dev, "Can't get external clock: %ld\n",
> + PTR_ERR(hub_data->clk));

how about setting clock to NULL to here ? then you don't need IS_ERR()
checks anywhere else.

> + }

braces shouldn't be used here, if you add NULL trick above,
however... then you can keep them.

> + /*
> +  * Try to get the information for HUB reset, the
> +  * default setting like below:
> +  *
> +  * - Reset state is low
> +  * - The duration is 50us
> +  */
> + if (of_find_property(node, "hub-reset-active-high", NULL))
> + reset_pol = 1;

you see, this is definitely *not* generic. You should write a generic
reset-gpio.c reset controller and describe the polarity on the gpio
binding. This driver *always* uses reset_assert(); reset_deassert(); and
reset-gpio implements though by gpiod_set_value() correctly.

Polarity _must_ be described elsewhere in DT.

> + of_property_read_u32(node, "hub-reset-duration-us",
> + &duration_us);

likewise, this should be described as a debounce time for the GPIO.

> + gpiod_reset = devm_gpiod_get_optional(dev, "hub-reset",
> + reset_pol ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW);
> + ret = PTR_ERR_OR_ZERO(gpiod_reset);
> + if (ret) {
> + dev_err(dev, "Failed to get reset gpio, err = %d\n",
> + ret);
> + return ret;
> + }
> + } else if (pdata) {
> + hub_data->clk = pdata->ext_clk;
> + duration_us = pdata->gpio_reset_duration_us;
> + reset_pol = pdata->gpio_reset_polarity;
> +
> + if (gpio_is_valid(pdata->gpio_reset)) {
> + ret = devm_gpio_request_one(
> + dev, pdata->gpio_reset, reset_pol
> + ? GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW,
> + dev_name(dev));
> + if (!ret)
> + gpiod_reset = gpio_to_desc(pdata->gpio_reset);
> + }
> + }
> +
> + if (!IS_ERR(hub_data->clk)) {
> + 

Re: [PATCH 1/3] usb: misc: generic_onboard_hub: add generic onboard USB HUB driver

[kbuild test robot]

Hi Peter,

[auto build test ERROR on usb/usb-testing]
[also build test ERROR on v4.4-rc4 next-20151207]

url:
https://github.com/0day-ci/linux/commits/Peter-Chen/USB-add-generic-onboard-USB-HUB-driver/20151208-094428
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
usb-testing
config: tile-allmodconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=tile 

All error/warnings (new ones prefixed by >>):

   drivers/usb/misc/generic_onboard_hub.c: In function 'usb_hub_generic_probe':
>> drivers/usb/misc/generic_onboard_hub.c:76:3: error: implicit declaration of 
>> function 'devm_gpiod_get_optional'
>> drivers/usb/misc/generic_onboard_hub.c:77:16: error: 'GPIOD_OUT_HIGH' 
>> undeclared (first use in this function)
   drivers/usb/misc/generic_onboard_hub.c:77:16: note: each undeclared 
identifier is reported only once for each function it appears in
>> drivers/usb/misc/generic_onboard_hub.c:77:33: error: 'GPIOD_OUT_LOW' 
>> undeclared (first use in this function)
>> drivers/usb/misc/generic_onboard_hub.c:95:5: error: implicit declaration of 
>> function 'gpio_to_desc'
>> drivers/usb/misc/generic_onboard_hub.c:95:17: warning: assignment makes 
>> pointer from integer without a cast [enabled by default]
>> drivers/usb/misc/generic_onboard_hub.c:114:3: error: implicit declaration of 
>> function 'gpiod_set_value'
   cc1: some warnings being treated as errors

vim +/devm_gpiod_get_optional +76 drivers/usb/misc/generic_onboard_hub.c

70  if (of_find_property(node, "hub-reset-active-high", 
NULL))
71  reset_pol = 1;
72  
73  of_property_read_u32(node, "hub-reset-duration-us",
74  &duration_us);
75  
  > 76  gpiod_reset = devm_gpiod_get_optional(dev, "hub-reset",
  > 77  reset_pol ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW);
78  ret = PTR_ERR_OR_ZERO(gpiod_reset);
79  if (ret) {
80  dev_err(dev, "Failed to get reset gpio, err = 
%d\n",
81  ret);
82  return ret;
83  }
84  } else if (pdata) {
85  hub_data->clk = pdata->ext_clk;
86  duration_us = pdata->gpio_reset_duration_us;
87  reset_pol = pdata->gpio_reset_polarity;
88  
89  if (gpio_is_valid(pdata->gpio_reset)) {
90  ret = devm_gpio_request_one(
91  dev, pdata->gpio_reset, reset_pol
92  ? GPIOF_OUT_INIT_HIGH : 
GPIOF_OUT_INIT_LOW,
93  dev_name(dev));
94  if (!ret)
  > 95  gpiod_reset = 
gpio_to_desc(pdata->gpio_reset);
96  }
97  }
98  
99  if (!IS_ERR(hub_data->clk)) {
   100  ret = clk_prepare_enable(hub_data->clk);
   101  if (ret) {
   102  dev_err(dev,
   103  "Can't enable external clock: %d\n",
   104  ret);
   105  return ret;
   106  }
   107  }
   108  
   109  if (gpiod_reset) {
   110  /* Sanity check */
   111  if (duration_us > 100)
   112  duration_us = 50;
   113  usleep_range(duration_us, duration_us + 100);
 > 114  gpiod_set_value(gpiod_reset, reset_pol ? 0 : 1);
   115  }
   116  
   117  dev_set_drvdata(dev, hub_data);

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


.config.gz
Description: Binary data

RE: [PATCH] r8152: fix lockup when runtime PM is enabled

[Hayes Wang]

Peter Wu [mailto:pe...@lekensteyn.nl]
> Sent: Tuesday, December 08, 2015 12:59 AM
[...]
> + if (tp->netdev->flags & IFF_UP) {

Maybe you could just replace the checking of netif_running(tp->netdev) with 
this.

Excuse me. I have a question. Before the open() is finished, the 
netif_running() would
be true, but the IFF_UP wouldn't be set. Is it right?

Best Regards,
Hayes

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

[PATCH] usb: musb: core: Fix pm runtime for deferred probe

[Tony Lindgren]

If musb_init_controller fails at musb_platform_init, we have already
called pm_runtime_irq_safe for musb and that causes the pm runtime count
to be enabled for parent before the parent has completed initialization.
This causes pm to stop working as on unload nothing gets idled.

This issue can be reproduced at least with:

# modprobe omap2430
HS USB OTG: no transceiver configured
musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517
# modprobe phy-twl4030-usb
# rmmod omap2430

And after the steps above omap2430 will block deeper idle states on
omap3.

To fix this, let's not enable pm runtime until we need to and the
parent has been initialized. Note that this does not fix the issue of
PM being broken for musb during runtime.

Signed-off-by: Tony Lindgren 
---
 drivers/usb/musb/musb_core.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2034,7 +2034,6 @@ musb_init_controller(struct device *dev, int nIrq, void 
__iomem *ctrl)
/* We need musb_read/write functions initialized for PM */
pm_runtime_use_autosuspend(musb->controller);
pm_runtime_set_autosuspend_delay(musb->controller, 200);
-   pm_runtime_irq_safe(musb->controller);
pm_runtime_enable(musb->controller);
 
/* The musb_platform_init() call:
@@ -2238,6 +2237,12 @@ musb_init_controller(struct device *dev, int nIrq, void 
__iomem *ctrl)
 
pm_runtime_put(musb->controller);
 
+   /*
+* For why this is currently needed, see commit 3e43a0725637
+* ("usb: musb: core: add pm_runtime_irq_safe()")
+*/
+   pm_runtime_irq_safe(musb->controller);
+
return 0;
 
 fail5:
-- 
2.6.2

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

[PATCH 0/2] usb: renesas_usbhs: More compat strings

[Simon Horman]

Hi,

this short series adds generic, and soc-specific r8a7792 and r8a7793 compat
strings to the Renesas USBHS driver. The intention is to provide a complete
set of compat strings for known R-Car SoCs.

Simon Horman (2):
  usb: renesas_usbhs: add fallback compatibility string
  usb: renesas_usbhs: add device tree support for r8a779[23]

 Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 14 --
 drivers/usb/renesas_usbhs/common.c  |  4 
 2 files changed, 12 insertions(+), 6 deletions(-)

-- 
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 1/2] usb: renesas_usbhs: add fallback compatibility string

[Simon Horman]

Add fallback compatibility string.
This is in keeping with the fallback scheme being adopted wherever
appropriate for drivers for Renesas SoCs.

Signed-off-by: Simon Horman 
---
 Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 4 ++--
 drivers/usb/renesas_usbhs/common.c  | 4 
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt 
b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
index 7d48f63db44e..8c50df8441c9 100644
--- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
+++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
@@ -1,7 +1,7 @@
 Renesas Electronics USBHS driver
 
 Required properties:
-  - compatible: Must contain one of the following:
+  - compatible: "renesas,usbhs-", "renesas,rcar-usbhs" as fallback.
- "renesas,usbhs-r8a7790"
- "renesas,usbhs-r8a7791"
- "renesas,usbhs-r8a7794"
@@ -22,7 +22,7 @@ Optional properties:
 
 Example:
usbhs: usb@e659 {
-   compatible = "renesas,usbhs-r8a7790";
+   compatible = "renesas,usbhs-r8a7790", "renesas,rcar-usbhs";
reg = <0 0xe659 0 0x100>;
interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp7_clks R8A7790_CLK_HSUSB>;
diff --git a/drivers/usb/renesas_usbhs/common.c 
b/drivers/usb/renesas_usbhs/common.c
index d82fa36c3465..2a9d4f405f30 100644
--- a/drivers/usb/renesas_usbhs/common.c
+++ b/drivers/usb/renesas_usbhs/common.c
@@ -481,6 +481,10 @@ static const struct of_device_id usbhs_of_match[] = {
.compatible = "renesas,usbhs-r8a7795",
.data = (void *)USBHS_TYPE_RCAR_GEN2,
},
+   {
+   .compatible = "renesas,usbhs",
+   .data = (void *)USBHS_TYPE_RCAR_GEN2,
+   },
{ },
 };
 MODULE_DEVICE_TABLE(of, usbhs_of_match);
-- 
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/2] usb: renesas_usbhs: add device tree support for r8a779[23]

[Simon Horman]

Simply document new compatibility string.
As a previous patch adds a generic R-Car Gen2 compatibility string
there appears to be no need for a driver updates.

Also add names for SoCs.

Signed-off-by: Simon Horman 
---
 Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt 
b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
index 8c50df8441c9..b31f036d2171 100644
--- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
+++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
@@ -2,10 +2,12 @@ Renesas Electronics USBHS driver
 
 Required properties:
   - compatible: "renesas,usbhs-", "renesas,rcar-usbhs" as fallback.
-   - "renesas,usbhs-r8a7790"
-   - "renesas,usbhs-r8a7791"
-   - "renesas,usbhs-r8a7794"
-   - "renesas,usbhs-r8a7795"
+   - "renesas,usbhs-r8a7790" (R-Car H2)
+   - "renesas,usbhs-r8a7791" (R-Car M2-W)
+   - "renesas,usbhs-r8a7792" (R-Car V2H)
+   - "renesas,usbhs-r8a7793" (R-Car M2-N)
+   - "renesas,usbhs-r8a7794" (R-Car E2)
+   - "renesas,usbhs-r8a7795" (R-Car H3)
   - reg: Base address and length of the register for the USBHS
   - interrupts: Interrupt specifier for the USBHS
   - clocks: A list of phandle + clock specifier pairs
-- 
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: reading data at 500Hz

[Peter Stuge]

Jose Colmenares wrote:
> 128000 bytes per second for a 1000Hz frequency (which the device
> can give). 128000 bytes per second is a lot less than the 480 Mbps
> that USB 2 gives. That's what's killing me.

I don't think you have written that you have a particular latency
requirement, but Greg seems to assume that you want to approach zero
latency, which indeed USB is not at all capable of.

USB is a high throughput and (relatively) high latency bus.

Exactly how high throughput and how high latency depends completely
on what protocol the USB device implements. USB offers a wide range
of communications building blocks, and each device implements some
particular protocol with a combination of them.

Many devices unfortunately implement very inefficient protocols.

Greg's advice to drive this device from userspace is very good - take
a look at libserialport for a good start:

http://sigrok.org/wiki/Libserialport
https://github.com/martinling/libserialport


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

Re: [PATCH 1/2] usb: renesas_usbhs: add fallback compatibility string

[Kuninori Morimoto]

Hi Simon

> Add fallback compatibility string.
> This is in keeping with the fallback scheme being adopted wherever
> appropriate for drivers for Renesas SoCs.
> 
> Signed-off-by: Simon Horman 
> ---
(snip)
> + {
> + .compatible = "renesas,usbhs",
> + .data = (void *)USBHS_TYPE_RCAR_GEN2,
> + },
>   { },
>  };

I think this is too much. This driver is used not only from R-Car Gen2.
It will work as normal mode if .data was 0.
see usbhs_parse_dt()
--
To unsubscribe from this list: send the line "unsubscribe 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/3] usb: misc: generic_onboard_hub: add generic onboard USB HUB driver

[Sascha Hauer]

On Tue, Dec 08, 2015 at 09:37:48AM +0800, Peter Chen wrote:
> Current USB HUB driver lacks of platform interfaces to configure
> external signal on HUB chip, eg, the PHY input clock and gpio reset
> pin for HUB, these kinds of HUBs are usually soldered at the board,
> and they are not hot-plug USB devices.
> 
> With this patch, the user can configure the HUB's pins at platform
> part (through dts or platform), and these configuration will be
> effective before the USB bus can be used, we use subsys_initcall
> for this driver.
> 
> Signed-off-by: Peter Chen 
> ---
>  MAINTAINERS |   7 ++
>  drivers/usb/misc/Kconfig|   9 ++
>  drivers/usb/misc/Makefile   |   1 +
>  drivers/usb/misc/generic_onboard_hub.c  | 162 
> 
>  include/linux/usb/generic_onboard_hub.h |  11 +++
>  5 files changed, 190 insertions(+)
>  create mode 100644 drivers/usb/misc/generic_onboard_hub.c
>  create mode 100644 include/linux/usb/generic_onboard_hub.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e9caa4b..cc1981e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11121,6 +11121,13 @@ S:   Maintained
>  F:   Documentation/usb/ohci.txt
>  F:   drivers/usb/host/ohci*
>  
> +USB Generic Onboard HUB Driver
> +M:   Peter Chen 
> +T:   git git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git
> +L:   linux-usb@vger.kernel.org
> +S:   Maintained
> +F:   drivers/usb/misc/generic_onboard_hub.c
> +
>  USB OTG FSM (Finite State Machine)
>  M:   Peter Chen 
>  T:   git git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git
> diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
> index f7a7fc2..8921cae 100644
> --- a/drivers/usb/misc/Kconfig
> +++ b/drivers/usb/misc/Kconfig
> @@ -268,3 +268,12 @@ config USB_CHAOSKEY
>  
> To compile this driver as a module, choose M here: the
> module will be called chaoskey.
> +
> +config USB_ONBOARD_HUB
> + tristate "Generic USB Onboard HUB"
> + help
> +   Say Y here if your board has an onboard HUB, and this hub needs
> +   to control its PHY clock and reset pin through external signals.
> +   If you are not sure, say N.
> +
> +   To compile this driver as a module, choose M here.
> diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
> index 45fd4ac..da52e9a 100644
> --- a/drivers/usb/misc/Makefile
> +++ b/drivers/usb/misc/Makefile
> @@ -29,3 +29,4 @@ obj-$(CONFIG_USB_CHAOSKEY)  += chaoskey.o
>  
>  obj-$(CONFIG_USB_SISUSBVGA)  += sisusbvga/
>  obj-$(CONFIG_USB_LINK_LAYER_TEST)+= lvstest.o
> +obj-$(CONFIG_USB_ONBOARD_HUB)+= generic_onboard_hub.o
> diff --git a/drivers/usb/misc/generic_onboard_hub.c 
> b/drivers/usb/misc/generic_onboard_hub.c
> new file mode 100644
> index 000..df722a0
> --- /dev/null
> +++ b/drivers/usb/misc/generic_onboard_hub.c
> @@ -0,0 +1,162 @@
> +/*
> + * usb_hub_generic.c The generic onboard USB HUB driver
> + *
> + * Copyright (C) 2015 Freescale Semiconductor, Inc.
> + * Author: Peter Chen 
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2  of
> + * the License as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + */
> +
> +/*
> + * This driver is only for the USB HUB devices which need to control
> + * their external pins(clock, reset, etc), and these USB HUB devices
> + * are soldered at the board.
> + */
> +
> +#define DEBUG
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct usb_hub_generic_data {
> + struct clk *clk;
> +};
> +
> +static int usb_hub_generic_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct usb_hub_generic_platform_data *pdata = dev->platform_data;
> + struct usb_hub_generic_data *hub_data;
> + int reset_pol = 0, duration_us = 50, ret = 0;
> + struct gpio_desc *gpiod_reset = NULL;
> +
> + hub_data = devm_kzalloc(dev, sizeof(*hub_data), GFP_KERNEL);
> + if (!hub_data)
> + return -ENOMEM;
> +
> + if (dev->of_node) {
> + struct device_node *node = dev->of_node;
> +
> + hub_data->clk = devm_clk_get(dev, "external_clk");

Please drop such _clk suffixes. The context already makes it clear that
it's a clock.

> + if (IS_ERR(hub_data->clk)) {
> + dev_dbg(dev, "Can't get external clock: %ld\n",
> +  

Re: [PATCH 1/2] usb: renesas_usbhs: add fallback compatibility string

[Simon Horman]

On Tue, Dec 08, 2015 at 06:05:51AM +, Kuninori Morimoto wrote:
> 
> Hi Simon
> 
> > Add fallback compatibility string.
> > This is in keeping with the fallback scheme being adopted wherever
> > appropriate for drivers for Renesas SoCs.
> > 
> > Signed-off-by: Simon Horman 
> > ---
> (snip)
> > +   {
> > +   .compatible = "renesas,usbhs",
> > +   .data = (void *)USBHS_TYPE_RCAR_GEN2,
> > +   },
> > { },
> >  };
> 
> I think this is too much. This driver is used not only from R-Car Gen2.
> It will work as normal mode if .data was 0.
> see usbhs_parse_dt()

Are you suggesting that we remove USBHS_TYPE_RCAR_GEN2 from the driver?
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html