Re: [USB] f16443a034: EIP:arch_local_irq_restore

[Alan Stern]

On Thu, 29 Jun 2017, Alan Stern wrote:

> Felipe:
> 
> On Thu, 29 Jun 2017, kernel test robot wrote:
> 
> > FYI, we noticed the following commit:
> > 
> > commit: f16443a034c7aa359ddf6f0f9bc40d01ca31faea ("USB: gadgetfs, 
> > dummy-hcd, net2280: fix locking for callbacks")
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> > 
> > in testcase: trinity
> > with following parameters:
> > 
> > runtime: 300s
> > 
> > test-description: Trinity is a linux system call fuzz tester.
> > test-url: http://codemonkey.org.uk/projects/trinity/
> > 
> > 
> > on test machine: qemu-system-x86_64 -enable-kvm -m 420M
> > 
> > caused below changes (please refer to attached dmesg/kmsg for entire 
> > log/backtrace):
> ...
> 
> I won't include the entire report.  The gist is that we have a problem 
> with lock ordering.  The report is about dummy-hcd, but this could 
> affect any UDC driver.
> 
>  1. When a SETUP request arrives, composite_setup() acquires
>   cdev->lock before calling the function driver's callback.
>   When that callback submits a reply, it causes the UDC driver
>   to acquire its private lock.
> 
>  2. When a bus reset occurs, the UDC's interrupt handler acquires
>   its private lock before calling usb_gadget_udc_reset(), which
>   calls composite_disconnect(), which acquires cdev->lock.
> 
> So there's an ABBA ordering problem between the UDC's private lock and 
> the composite core's cdev->lock.
> 
> Use of the UDC's private lock in 1 seems unavoidable.  Perhaps it can 
> be avoided in 2, but wouldn't that leave us open to a race between 
> reset handling and gadget driver unregistration?  In fact, that was the 
> very reason for creating the commit cited at the top of this bug 
> report.
> 
> I don't know enough of the details of the composite core to say whether 
> its lock usage can be reduced.
> 
> Do you have any suggestions?

Actually, I had an idea this morning.

The UDC driver certainly cannot retain its private lock across ->setup 
callbacks, because the handler will submit a response request which 
will cause the UDC driver to reacquire the lock.  Therefore the setup 
callback is already subject to a race with unregistration.

This strongly suggests that the UDC driver should not keep its private 
lock during the other callbacks either.  Which means we need some way 
to prevent the race from occurring.  To be more explicit, the UDC 
driver's udc_stop routine needs to wait until no callbacks are running.

Here's a sample patch for dummy-hcd to illustrate the idea:

--- usb-4.x.orig/drivers/usb/gadget/udc/dummy_hcd.c
+++ usb-4.x/drivers/usb/gadget/udc/dummy_hcd.c
@@ -253,6 +253,7 @@ struct dummy {
 */
struct dummy_ep ep[DUMMY_ENDPOINTS];
int address;
+   int active_callbacks;
struct usb_gadget   gadget;
struct usb_gadget_driver*driver;
struct dummy_requestfifo_req;
@@ -442,16 +443,24 @@ static void set_link_state(struct dummy_
/* Report reset and disconnect events to the driver */
if (dum->driver && (disconnect || reset)) {
stop_activity(dum);
+   ++dum->active_callbacks;
+   spin_unlock(>lock);
if (reset)
usb_gadget_udc_reset(>gadget, dum->driver);
else
dum->driver->disconnect(>gadget);
+   spin_lock(>lock);
+   --dum->active_callbacks;
}
-   } else if (dum_hcd->active != dum_hcd->old_active) {
+   } else if (dum->driver && dum_hcd->active != dum_hcd->old_active) {
+   ++dum->active_callbacks;
+   spin_unlock(>lock);
if (dum_hcd->old_active && dum->driver->suspend)
dum->driver->suspend(>gadget);
-   else if (!dum_hcd->old_active &&  dum->driver->resume)
+   else if (!dum_hcd->old_active && dum->driver->resume)
dum->driver->resume(>gadget);
+   spin_lock(>lock);
+   --dum->active_callbacks;
}
 
dum_hcd->old_status = dum_hcd->port_status;
@@ -976,10 +985,22 @@ static int dummy_udc_stop(struct usb_gad
struct dummy_hcd*dum_hcd = gadget_to_dummy_hcd(g);
struct dummy*dum = dum_hcd->dum;
 
-   spin_lock_irq(>lock);
-   dum->driver = NULL;
-   spin_unlock_irq(>lock);
+   /* Wait until no callbacks are running, then unbind the driver */
+   for (;;) {
+   int c;
+
+   spin_lock_irq(>lock);
+   c = dum->active_callbacks;
+   if (c == 0) {
+   dum->driver = NULL;
+   stop_activity(dum);
+   }
+   

Re: [linux-next][PATCH] usb: dwc3: omap: remove IRQ_NOAUTOEN used with shared irq

[Grygorii Strashko]

On 06/29/2017 01:03 AM, Tony Lindgren wrote:
> * Vignesh R  [170628 21:21]:
>>
>>
>> On Thursday 29 June 2017 05:01 AM, Strashko, Grygorii wrote:
>>> IRQ_NOAUTOEN can't be used with shared IRQs and Kernel now will triggers
>>> warning if it happns, since commit 04c848d39879 ("genirq: Warn when
>>> IRQ_NOAUTOEN is used with shared interrupts"). And this is the case for
>>> OMAP DWC 3 driver.
>>>
>>> Hence, remove IRQ_NOAUTOEN flag and instead call disable_irq() before
>>> disabling PM runtime in probe error path handling.
>>
>> Or, how about requesting the irq at the end of probe after extcon
>> registration?
> 
> Hmm yeah, what prevents the issue that we tried to fix with commit
> 12a7f17fac5b ("usb: dwc3: omap: fix race of pm runtime with irq handler
> in probe")?

No, I think. There should be the disable_irq() call any way
before pm_runtime_put_sync(dev);| pm_runtime_disable(dev); -
once IRQ is requested driver can't know if IRQ handler is running now or not
unless it will call disable_irq()/free_irq().

But, I've also thought about moving request_irq() down (seems
it can be moved even after of_platform_populate()).
looks like it can be separate patch.


>>> Fixes: 12a7f17fac5b ("usb: dwc3: omap: fix race of pm runtime with...")
>>> Signed-off-by: Grygorii Strashko 
>>> ---
>>>   drivers/usb/dwc3/dwc3-omap.c | 3 +--
>>>   1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
>>> index 9892650..cd9bef5 100644
>>> --- a/drivers/usb/dwc3/dwc3-omap.c
>>> +++ b/drivers/usb/dwc3/dwc3-omap.c
>>> @@ -512,7 +512,6 @@ static int dwc3_omap_probe(struct platform_device *pdev)
>>>   
>>> /* check the DMA Status */
>>> reg = dwc3_omap_readl(omap->base, USBOTGSS_SYSCONFIG);
>>> -   irq_set_status_flags(omap->irq, IRQ_NOAUTOEN);
>>> ret = devm_request_threaded_irq(dev, omap->irq, dwc3_omap_interrupt,
>>> dwc3_omap_interrupt_thread, IRQF_SHARED,
>>> "dwc3-omap", omap);
>>> @@ -533,10 +532,10 @@ static int dwc3_omap_probe(struct platform_device 
>>> *pdev)
>>> }
>>>   
>>> dwc3_omap_enable_irqs(omap);
>>> -   enable_irq(omap->irq);
>>> return 0;
>>>   
>>>   err1:
>>> +   disable_irq(omap->irq);
>>> pm_runtime_put_sync(dev);
>>> pm_runtime_disable(dev);
>>>   

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

Re: [PATCH V2 1/1] net: cdc_ncm: Reduce memory use when kernel memory low

[Bjørn Mork]

"Baxter, Jim"  writes:

> I tested this with printk's to show when the low memory code was triggered
> and the value of ctx->tx_low_mem_val and ctx->tx_low_mem_max_cnt.
> I created a workqueue that slowly used up the atomic memory until the
> code is triggered.
>
> I could add debug prints, though I have noticed that cdc_ncm_fill_tx_frame()
> does not currently have any debug prints do you think this is because it can 
> be
> called in an atomic context and I think debug messages if enabled could cause
> too great a delay?

Yes, I guess you're right.  Maybe count the number of failed allocations
and export it along with the other driver private counters?  Or export
the tx_curr_size as a sysfs attribute? Or both?

Just an idea...  I don't expect to see this code ever being hit on my
systems :-)



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

Re: [PATCH V2 1/1] net: cdc_ncm: Reduce memory use when kernel memory low

[Baxter, Jim]

> Jim Baxter  writes:
> 
>> The CDC-NCM driver can require large amounts of memory to create
>> skb's and this can be a problem when the memory becomes fragmented.
>>
>> This especially affects embedded systems that have constrained
>> resources but wish to maximise the throughput of CDC-NCM with 16KiB
>> NTB's.
>>
>> The issue is after running for a while the kernel memory can become
>> fragmented and it needs compacting.
>> If the NTB allocation is needed before the memory has been compacted
>> the atomic allocation can fail which can cause increased latency,
>> large re-transmissions or disconnections depending upon the data
>> being transmitted at the time.
>> This situation occurs for less than a second until the kernel has
>> compacted the memory but the failed devices can take a lot longer to
>> recover from the failed TX packets.
>>
>> To ease this temporary situation I modified the CDC-NCM TX path to
>> temporarily switch into a reduced memory mode which allocates an NTB
>> that will fit into a USB_CDC_NCM_NTB_MIN_OUT_SIZE (default 2048 Bytes)
>> sized memory block and only transmit NTB's with a single network frame
>> until the memory situation is resolved.
>> Each time this issue occurs we wait for an increasing number of
>> reduced size allocations before requesting a full size one to not
>> put additional pressure on a low memory system.
>>
>> Once the memory is compacted the CDC-NCM data can resume transmitting
>> at the normal tx_max rate once again.
>>
>> Signed-off-by: Jim Baxter 
> 
> This looks good to me.
> 
> I would still be happier if we didn't need something like this, but I
> understand that we do.  And this patch looks as clean as it can get.  I
> haven't tested the patch under any sort of memory pressure, but I did a
> basic runtime test on a single MBIM device.  As expected, I did not
> notice any changes with this patch applied.
> 
> But regarding noticable effects: The patch adds no printks, counters or
> sysfs attributes which could tell the user that the initial buffer
> allocation has failed.  Maybe add some sort of debug helper(s) in a
> followup patch? How did you verify the patch operation while testing it?
> 
> Anyway, that's no show stopper of course.  So FWIW:
> 
> Reviewed-by: Bjørn Mork 
> 

Hello Bjørn,

I tested this with printk's to show when the low memory code was triggered
and the value of ctx->tx_low_mem_val and ctx->tx_low_mem_max_cnt.
I created a workqueue that slowly used up the atomic memory until the
code is triggered.

I could add debug prints, though I have noticed that cdc_ncm_fill_tx_frame()
does not currently have any debug prints do you think this is because it can be
called in an atomic context and I think debug messages if enabled could cause
too great a delay?

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

Re: [PATCH V2 1/1] net: cdc_ncm: Reduce memory use when kernel memory low

[Bjørn Mork]

Jim Baxter  writes:

> The CDC-NCM driver can require large amounts of memory to create
> skb's and this can be a problem when the memory becomes fragmented.
>
> This especially affects embedded systems that have constrained
> resources but wish to maximise the throughput of CDC-NCM with 16KiB
> NTB's.
>
> The issue is after running for a while the kernel memory can become
> fragmented and it needs compacting.
> If the NTB allocation is needed before the memory has been compacted
> the atomic allocation can fail which can cause increased latency,
> large re-transmissions or disconnections depending upon the data
> being transmitted at the time.
> This situation occurs for less than a second until the kernel has
> compacted the memory but the failed devices can take a lot longer to
> recover from the failed TX packets.
>
> To ease this temporary situation I modified the CDC-NCM TX path to
> temporarily switch into a reduced memory mode which allocates an NTB
> that will fit into a USB_CDC_NCM_NTB_MIN_OUT_SIZE (default 2048 Bytes)
> sized memory block and only transmit NTB's with a single network frame
> until the memory situation is resolved.
> Each time this issue occurs we wait for an increasing number of
> reduced size allocations before requesting a full size one to not
> put additional pressure on a low memory system.
>
> Once the memory is compacted the CDC-NCM data can resume transmitting
> at the normal tx_max rate once again.
>
> Signed-off-by: Jim Baxter 

This looks good to me.

I would still be happier if we didn't need something like this, but I
understand that we do.  And this patch looks as clean as it can get.  I
haven't tested the patch under any sort of memory pressure, but I did a
basic runtime test on a single MBIM device.  As expected, I did not
notice any changes with this patch applied.

But regarding noticable effects: The patch adds no printks, counters or
sysfs attributes which could tell the user that the initial buffer
allocation has failed.  Maybe add some sort of debug helper(s) in a
followup patch? How did you verify the patch operation while testing it?

Anyway, that's no show stopper of course.  So FWIW:

Reviewed-by: Bjørn Mork 

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

Re: [PATCH V2 1/1] net: cdc_ncm: Reduce memory use when kernel memory low

[Baxter, Jim]

From: David S. Miller (da...@davemloft.net)
Sent: Fri, 30 Jun 2017 12:59:53 -0400
To: jim_bax...@mentor.com
Cc: linux-usb@vger.kernel.org, net...@vger.kernel.org, 
linux-ker...@vger.kernel.org, oli...@neukum.org, bj...@mork.no, 
david.lai...@aculab.com
Subject: Re: [PATCH V2 1/1] net: cdc_ncm: Reduce memory use when kernel memory 
low

 


> From: Jim Baxter 
> Date: Wed, 28 Jun 2017 21:35:29 +0100
> 
>> The CDC-NCM driver can require large amounts of memory to create
>> skb's and this can be a problem when the memory becomes fragmented.
>>
>> This especially affects embedded systems that have constrained
>> resources but wish to maximise the throughput of CDC-NCM with 16KiB
>> NTB's.
>>
>> The issue is after running for a while the kernel memory can become
>> fragmented and it needs compacting.
>> If the NTB allocation is needed before the memory has been compacted
>> the atomic allocation can fail which can cause increased latency,
>> large re-transmissions or disconnections depending upon the data
>> being transmitted at the time.
>> This situation occurs for less than a second until the kernel has
>> compacted the memory but the failed devices can take a lot longer to
>> recover from the failed TX packets.
>>
>> To ease this temporary situation I modified the CDC-NCM TX path to
>> temporarily switch into a reduced memory mode which allocates an NTB
>> that will fit into a USB_CDC_NCM_NTB_MIN_OUT_SIZE (default 2048 Bytes)
>> sized memory block and only transmit NTB's with a single network frame
>> until the memory situation is resolved.
>> Each time this issue occurs we wait for an increasing number of
>> reduced size allocations before requesting a full size one to not
>> put additional pressure on a low memory system.
>>
>> Once the memory is compacted the CDC-NCM data can resume transmitting
>> at the normal tx_max rate once again.
>>
>> Signed-off-by: Jim Baxter 
> 
> If someone could review this patch, I remember this issue being discussed
> a while ago, I would really appreciate it.
> 

Hello,

For reference this replaces the original discussion in
http://patchwork.ozlabs.org/patch/763100/ and
http://patchwork.ozlabs.org/patch/766181/

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

Re: [PATCH V2 1/1] net: cdc_ncm: Reduce memory use when kernel memory low

[David Miller]

From: Jim Baxter 
Date: Wed, 28 Jun 2017 21:35:29 +0100

> The CDC-NCM driver can require large amounts of memory to create
> skb's and this can be a problem when the memory becomes fragmented.
> 
> This especially affects embedded systems that have constrained
> resources but wish to maximise the throughput of CDC-NCM with 16KiB
> NTB's.
> 
> The issue is after running for a while the kernel memory can become
> fragmented and it needs compacting.
> If the NTB allocation is needed before the memory has been compacted
> the atomic allocation can fail which can cause increased latency,
> large re-transmissions or disconnections depending upon the data
> being transmitted at the time.
> This situation occurs for less than a second until the kernel has
> compacted the memory but the failed devices can take a lot longer to
> recover from the failed TX packets.
> 
> To ease this temporary situation I modified the CDC-NCM TX path to
> temporarily switch into a reduced memory mode which allocates an NTB
> that will fit into a USB_CDC_NCM_NTB_MIN_OUT_SIZE (default 2048 Bytes)
> sized memory block and only transmit NTB's with a single network frame
> until the memory situation is resolved.
> Each time this issue occurs we wait for an increasing number of
> reduced size allocations before requesting a full size one to not
> put additional pressure on a low memory system.
> 
> Once the memory is compacted the CDC-NCM data can resume transmitting
> at the normal tx_max rate once again.
> 
> Signed-off-by: Jim Baxter 

If someone could review this patch, I remember this issue being discussed
a while ago, I would really appreciate it.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] PCI / PM: Avoid using device_may_wakeup() for runtime PM

[Bjorn Helgaas]

On Fri, Jun 23, 2017 at 02:58:11PM +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> pci_target_state() calls device_may_wakeup() which checks whether
> or not the device may wake up the system from sleep states, but
> pci_target_state() is used for runtime PM too.
> 
> Since runtime PM is expected to always enable remote wakeup if
> possible, modify pci_target_state() to take additional argument
> indicating whether or not it should look for a state from which
> the device can signal wakeup and pass either the return value
> of device_can_wakeup(), or "false" (if the device itself is not
> wakeup-capable) to it from the code related to runtime PM.
> 
> While at it, fix the comment in pci_dev_run_wake() which is not
> about sleep states.
> 
> Signed-off-by: Rafael J. Wysocki 

Applied with Mika's reviewed-by to pci/pm for v4.13, thanks!

> ---
> 
> -> v2:
> 
> Passing "true" as the second argument to pci_target_state() for runtime PM
> might trigger suboptimal state choices to be made, so pass the return value
> of device_can_wakeup() to it instead and pass "false" to it in 
> pci_dev_run_wake(),
> because that assumes device_can_wakeup() to return "false" already.
> 
> ---
>  drivers/pci/pci.c |   22 +-
>  1 file changed, 13 insertions(+), 9 deletions(-)
> 
> Index: linux-pm/drivers/pci/pci.c
> ===
> --- linux-pm.orig/drivers/pci/pci.c
> +++ linux-pm/drivers/pci/pci.c
> @@ -1982,12 +1982,13 @@ EXPORT_SYMBOL(pci_wake_from_d3);
>  /**
>   * pci_target_state - find an appropriate low power state for a given PCI dev
>   * @dev: PCI device
> + * @wakeup: Whether or not wakeup functionality will be enabled for the 
> device.
>   *
>   * Use underlying platform code to find a supported low power state for @dev.
>   * If the platform can't manage @dev, return the deepest state from which it
>   * can generate wake events, based on any available PME info.
>   */
> -static pci_power_t pci_target_state(struct pci_dev *dev)
> +static pci_power_t pci_target_state(struct pci_dev *dev, bool wakeup)
>  {
>   pci_power_t target_state = PCI_D3hot;
>  
> @@ -2024,7 +2025,7 @@ static pci_power_t pci_target_state(stru
>   if (dev->current_state == PCI_D3cold)
>   target_state = PCI_D3cold;
>  
> - if (device_may_wakeup(>dev)) {
> + if (wakeup) {
>   /*
>* Find the deepest state from which the device can generate
>* wake-up events, make it the target state and enable device
> @@ -2050,13 +2051,14 @@ static pci_power_t pci_target_state(stru
>   */
>  int pci_prepare_to_sleep(struct pci_dev *dev)
>  {
> - pci_power_t target_state = pci_target_state(dev);
> + bool wakeup = device_may_wakeup(>dev);
> + pci_power_t target_state = pci_target_state(dev, wakeup);
>   int error;
>  
>   if (target_state == PCI_POWER_ERROR)
>   return -EIO;
>  
> - pci_enable_wake(dev, target_state, device_may_wakeup(>dev));
> + pci_enable_wake(dev, target_state, wakeup);
>  
>   error = pci_set_power_state(dev, target_state);
>  
> @@ -2089,9 +2091,10 @@ EXPORT_SYMBOL(pci_back_from_sleep);
>   */
>  int pci_finish_runtime_suspend(struct pci_dev *dev)
>  {
> - pci_power_t target_state = pci_target_state(dev);
> + pci_power_t target_state;
>   int error;
>  
> + target_state = pci_target_state(dev, device_can_wakeup(>dev));
>   if (target_state == PCI_POWER_ERROR)
>   return -EIO;
>  
> @@ -2127,8 +2130,8 @@ bool pci_dev_run_wake(struct pci_dev *de
>   if (!dev->pme_support)
>   return false;
>  
> - /* PME-capable in principle, but not from the intended sleep state */
> - if (!pci_pme_capable(dev, pci_target_state(dev)))
> + /* PME-capable in principle, but not from the target power state */
> + if (!pci_pme_capable(dev, pci_target_state(dev, false)))
>   return false;
>  
>   while (bus->parent) {
> @@ -2163,9 +2166,10 @@ EXPORT_SYMBOL_GPL(pci_dev_run_wake);
>  bool pci_dev_keep_suspended(struct pci_dev *pci_dev)
>  {
>   struct device *dev = _dev->dev;
> + bool wakeup = device_may_wakeup(dev);
>  
>   if (!pm_runtime_suspended(dev)
> - || pci_target_state(pci_dev) != pci_dev->current_state
> + || pci_target_state(pci_dev, wakeup) != pci_dev->current_state
>   || platform_pci_need_resume(pci_dev)
>   || (pci_dev->dev_flags & PCI_DEV_FLAGS_NEEDS_RESUME))
>   return false;
> @@ -2183,7 +2187,7 @@ bool pci_dev_keep_suspended(struct pci_d
>   spin_lock_irq(>power.lock);
>  
>   if (pm_runtime_suspended(dev) && pci_dev->current_state < PCI_D3cold &&
> - !device_may_wakeup(dev))
> + !wakeup)
>   __pci_pme_active(pci_dev, false);
>  
>   spin_unlock_irq(>power.lock);
> 
--
To unsubscribe from this list: send the line 

Re: [PATCH] usb: typec: include linux/device.h in ucsi.h

[Guenter Roeck]

On 06/30/2017 08:46 AM, Arnd Bergmann wrote:

The new driver causes a build failure in some configurations:

In file included from /git/arm-soc/drivers/usb/typec/ucsi/trace.h:9:0,
  from /git/arm-soc/drivers/usb/typec/ucsi/trace.c:2:
drivers/usb/typec/ucsi/ucsi.h:331:39: error: 'struct device' declared inside 
parameter list will not be visible outside of this definition or declaration 
[-Werror]

This includes the required header file.

Fixes: c1b0bc2dabfa ("usb: typec: Add support for UCSI interface")
Signed-off-by: Arnd Bergmann 


Reviewed-by: Guenter Roeck 


---
  drivers/usb/typec/ucsi/ucsi.h | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/usb/typec/ucsi/ucsi.h b/drivers/usb/typec/ucsi/ucsi.h
index 6b0d2f0918c6..8a88f45822e3 100644
--- a/drivers/usb/typec/ucsi/ucsi.h
+++ b/drivers/usb/typec/ucsi/ucsi.h
@@ -3,6 +3,7 @@
  #define __DRIVER_USB_TYPEC_UCSI_H
  
  #include 

+#include 
  #include 
  
  /* -- */




--
To unsubscribe from this list: send the line "unsubscribe 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: typec: include linux/device.h in ucsi.h

[Arnd Bergmann]

The new driver causes a build failure in some configurations:

In file included from /git/arm-soc/drivers/usb/typec/ucsi/trace.h:9:0,
 from /git/arm-soc/drivers/usb/typec/ucsi/trace.c:2:
drivers/usb/typec/ucsi/ucsi.h:331:39: error: 'struct device' declared inside 
parameter list will not be visible outside of this definition or declaration 
[-Werror]

This includes the required header file.

Fixes: c1b0bc2dabfa ("usb: typec: Add support for UCSI interface")
Signed-off-by: Arnd Bergmann 
---
 drivers/usb/typec/ucsi/ucsi.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/typec/ucsi/ucsi.h b/drivers/usb/typec/ucsi/ucsi.h
index 6b0d2f0918c6..8a88f45822e3 100644
--- a/drivers/usb/typec/ucsi/ucsi.h
+++ b/drivers/usb/typec/ucsi/ucsi.h
@@ -3,6 +3,7 @@
 #define __DRIVER_USB_TYPEC_UCSI_H
 
 #include 
+#include 
 #include 
 
 /* -- 
*/
-- 
2.9.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: Attaching multiple USB gadget devices per peripheral controller

[Josh Litherland]

Thanks very much for the response.

My application requires being able to present a very specific list of
devices to a host system I don't fully control, so providing one
device with multiple functions doesn't work in this specific case.
I'll investigate that Aspeed BMC solution.

Thanks again!

On Fri, Jun 30, 2017 at 10:43 AM, Alan Stern  wrote:
> On Thu, 29 Jun 2017, Josh Litherland wrote:
>
>> I've been tinkering with developing a USB touchscreen gadget device on
>> a board using a Mentor USB peripheral controller (driver musb-hdrc).
>> The gadget I'm developing runs in userspace via gadgetfs.  From what
>> I've been able to tell, there's no way to run multiple gadget devices
>> simultaneously using this controller, do I have that correct?  Is
>> there a peripheral controller out there that allows attachment of
>> multiple gadgets (and is supported in Linux)?
>
> It depends on exactly what you mean.  Most USB device controllers allow
> a single gadget driver to provide multiple functions.  For example, you
> might have one gadget with both a serial port function and a
> mass-storage function.  Is that as good as having multiple gadgets?
>
> There are almost no device controllers that allow for multiple devices.
> The only one I have ever heard of is the Aspeed BMC SoC, which includes
> a built-in virtual hub with facilities for 5 gadget drivers beneath it:
>
> http://marc.info/?l=linux-usb=149842193906284=2
>
> But since that controller is only available on that particular SoC, it
> probably isn't what you're looking for.
>
> Bear in mind that there's nothing to prevent you hooking up multiple
> device controllers in a single system.
>
> Alan Stern
>



-- 
Josh Litherland (j...@temp123.org)
--
To unsubscribe from this list: send the line "unsubscribe 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: Attaching multiple USB gadget devices per peripheral controller

[Alan Stern]

On Thu, 29 Jun 2017, Josh Litherland wrote:

> I've been tinkering with developing a USB touchscreen gadget device on
> a board using a Mentor USB peripheral controller (driver musb-hdrc).
> The gadget I'm developing runs in userspace via gadgetfs.  From what
> I've been able to tell, there's no way to run multiple gadget devices
> simultaneously using this controller, do I have that correct?  Is
> there a peripheral controller out there that allows attachment of
> multiple gadgets (and is supported in Linux)?

It depends on exactly what you mean.  Most USB device controllers allow 
a single gadget driver to provide multiple functions.  For example, you 
might have one gadget with both a serial port function and a 
mass-storage function.  Is that as good as having multiple gadgets?

There are almost no device controllers that allow for multiple devices.  
The only one I have ever heard of is the Aspeed BMC SoC, which includes
a built-in virtual hub with facilities for 5 gadget drivers beneath it:

http://marc.info/?l=linux-usb=149842193906284=2

But since that controller is only available on that particular SoC, it 
probably isn't what you're looking for.

Bear in mind that there's nothing to prevent you hooking up multiple 
device controllers in a single system.

Alan Stern

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

[PATCH v2] usb:gadget:hid: {GET,SET} Protocol support

[Abdulhadi Mohamed]

The current HID function driver doesn't support GET_PROCOTOL and
SET_PROCOTOL commands, which are required to operate the HID gadgets in
BOOT mode. This change implements this feature for devices that have
the same implementation for REPORT and BOOT mode

Signed-off-by: Abdulhadi Mohamed 
---
 drivers/usb/gadget/function/f_hid.c | 17 -
 include/linux/hid.h |  6 ++
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/function/f_hid.c 
b/drivers/usb/gadget/function/f_hid.c
index 5eea448..c60b882 100644
--- a/drivers/usb/gadget/function/f_hid.c
+++ b/drivers/usb/gadget/function/f_hid.c
@@ -44,6 +44,7 @@ struct f_hidg {
/* configuration */
unsigned char   bInterfaceSubClass;
unsigned char   bInterfaceProtocol;
+   unsigned char   protocol;
unsigned short  report_desc_length;
char*report_desc;
unsigned short  report_length;
@@ -527,7 +528,9 @@ static int hidg_setup(struct usb_function *f,
case ((USB_DIR_IN | USB_TYPE_CLASS | USB_RECIP_INTERFACE) << 8
  | HID_REQ_GET_PROTOCOL):
VDBG(cdev, "get_protocol\n");
-   goto stall;
+   length = min_t(unsigned, length, 1);
+   ((u8 *) req->buf)[0] = hidg->protocol;
+   goto respond;
break;

case ((USB_DIR_OUT | USB_TYPE_CLASS | USB_RECIP_INTERFACE) << 8
@@ -539,6 +542,17 @@ static int hidg_setup(struct usb_function *f,
case ((USB_DIR_OUT | USB_TYPE_CLASS | USB_RECIP_INTERFACE) << 8
  | HID_REQ_SET_PROTOCOL):
VDBG(cdev, "set_protocol\n");
+   if (value > HID_REPORT_PROTOCOL)
+   goto stall;
+   length = 0;
+   /*
+* We assume that programs implementing the Boot protocol
+* are also compatible with the Report Protocol
+*/
+   if(hidg->bInterfaceSubClass == USB_INTERFACE_SUBCLASS_BOOT) {
+   hidg->protocol = value;
+   goto respond;
+   }
goto stall;
break;

@@ -768,6 +782,7 @@ static int hidg_bind(struct usb_configuration *c, struct 
usb_function *f)
/* set descriptor dynamic values */
hidg_interface_desc.bInterfaceSubClass = hidg->bInterfaceSubClass;
hidg_interface_desc.bInterfaceProtocol = hidg->bInterfaceProtocol;
+   hidg->protocol = HID_REPORT_PROTOCOL;
hidg_ss_in_ep_desc.wMaxPacketSize = cpu_to_le16(hidg->report_length);
hidg_ss_in_comp_desc.wBytesPerInterval =
cpu_to_le16(hidg->report_length);
diff --git a/include/linux/hid.h b/include/linux/hid.h
index b2ec827..29d06c8 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -347,6 +347,12 @@ struct hid_item {
 #define HID_GROUP_LOGITECH_DJ_DEVICE   0x0102

 /*
+ * HID protocol status
+ */
+#define HID_REPORT_PROTOCOL1
+#define HID_BOOT_PROTOCOL  0
+
+/*
  * This is the global environment of the parser. This information is
  * persistent for main-items. The global environment can be saved and
  * restored with PUSH/POP statements.
--
2.9.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

[PATCH v2] usb:gadget:hid: Remote wakeup support

[Abdulhadi Mohamed]

Currently linux HID gadgets do not support remote wakeup (the ability
to wake up a host from suspend). This is an important feature for
gadgets that want to properly emulate the normal operation of a mouse
and keyboard. Ultimately, This feature has to be enabled/supported by
the underlying UDC driver to have any impact.


Signed-off-by: Abdulhadi Mohamed 
---
 drivers/usb/gadget/function/f_hid.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/gadget/function/f_hid.c 
b/drivers/usb/gadget/function/f_hid.c
index c60b882..eeb01bd 100644
--- a/drivers/usb/gadget/function/f_hid.c
+++ b/drivers/usb/gadget/function/f_hid.c
@@ -339,6 +339,7 @@ static ssize_t f_hidg_write(struct file *file, const char 
__user *buffer,
size_t count, loff_t *offp)
 {
struct f_hidg *hidg  = file->private_data;
+   struct usb_composite_dev *cdev = hidg->func.config->cdev;
struct usb_request *req;
unsigned long flags;
ssize_t status = -ENOMEM;
@@ -346,6 +347,7 @@ static ssize_t f_hidg_write(struct file *file, const char 
__user *buffer,
if (!access_ok(VERIFY_READ, buffer, count))
return -EFAULT;

+   usb_gadget_wakeup(cdev->gadget);
spin_lock_irqsave(>write_spinlock, flags);

 #define WRITE_COND (!hidg->write_pending)
--
2.9.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:gadget:hid: Remote wakeup support

[Frans Klaver]

On Fri, Jun 30, 2017 at 2:48 PM, Abdulhadi Mohamed
 wrote:
> Currently linux HID gadgets do not support remote wakeup (the ability
> to wake up a host from suspend). This is an important feature for
> gadgets that want to properly emulate the normal operation of a mouse
> and keyboard. Ultimately, This feature has to be enabled/supported by
> the underlying UDC driver to have any impact.

Is this a new version of a patch? Is it a resend? There is no version number :-/


> Signed-off-by: Abdulhadi Mohamed 
> ---
>  drivers/usb/gadget/function/f_hid.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/usb/gadget/function/f_hid.c 
> b/drivers/usb/gadget/function/f_hid.c
> index c60b882..eeb01bd 100644
> --- a/drivers/usb/gadget/function/f_hid.c
> +++ b/drivers/usb/gadget/function/f_hid.c
> @@ -339,6 +339,7 @@ static ssize_t f_hidg_write(struct file *file, const char 
> __user *buffer,
> size_t count, loff_t *offp)
>  {
> struct f_hidg *hidg  = file->private_data;
> +   struct usb_composite_dev *cdev = hidg->func.config->cdev;
> struct usb_request *req;
> unsigned long flags;
> ssize_t status = -ENOMEM;
> @@ -346,6 +347,7 @@ static ssize_t f_hidg_write(struct file *file, const char 
> __user *buffer,
> if (!access_ok(VERIFY_READ, buffer, count))
> return -EFAULT;
>
> +   usb_gadget_wakeup(cdev->gadget);
> spin_lock_irqsave(>write_spinlock, flags);
>
>  #define WRITE_COND (!hidg->write_pending)
> --
> 2.9.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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] usb: serial: Add support for Qivicon USB ZigBee dongle

[Frans Klaver]

On Fri, Jun 30, 2017 at 2:44 PM, Stefan Triller  wrote:
> The German Telekom offers a ZigBee USB Stick under the brand name Qivicon
> for their SmartHome Home Base in its 1. Generation. The productId is not
> known by the according kernel module, this patch adds support for it.
>
> Signed-off-by: Stefan Triller 

Reviewed-by: Frans Klaver 

> ---
>  drivers/usb/serial/cp210x.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
> index 0c55e7f64269..d37e9d4d617b 100644
> --- a/drivers/usb/serial/cp210x.c
> +++ b/drivers/usb/serial/cp210x.c
> @@ -141,6 +141,7 @@ static const struct usb_device_id id_table[] = {
> { USB_DEVICE(0x10C4, 0x8977) }, /* CEL MeshWorks DevKit Device */
> { USB_DEVICE(0x10C4, 0x8998) }, /* KCF Technologies PRN */
> { USB_DEVICE(0x10C4, 0x8A2A) }, /* HubZ dual ZigBee and Z-Wave dongle 
> */
> +   { USB_DEVICE(0x10C4, 0x8B34) }, /* Qivicon ZigBee USB Radio Stick  */
> { USB_DEVICE(0x10C4, 0xEA60) }, /* Silicon Labs factory default */
> { USB_DEVICE(0x10C4, 0xEA61) }, /* Silicon Labs factory default */
> { USB_DEVICE(0x10C4, 0xEA70) }, /* Silicon Labs factory default */
> --
> 2.13.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
--
To unsubscribe from this list: send the line "unsubscribe 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:hid: Remote wakeup support

[Abdulhadi Mohamed]

Currently linux HID gadgets do not support remote wakeup (the ability
to wake up a host from suspend). This is an important feature for 
gadgets that want to properly emulate the normal operation of a mouse 
and keyboard. Ultimately, This feature has to be enabled/supported by 
the underlying UDC driver to have any impact.


Signed-off-by: Abdulhadi Mohamed 
---
 drivers/usb/gadget/function/f_hid.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/gadget/function/f_hid.c 
b/drivers/usb/gadget/function/f_hid.c
index c60b882..eeb01bd 100644
--- a/drivers/usb/gadget/function/f_hid.c
+++ b/drivers/usb/gadget/function/f_hid.c
@@ -339,6 +339,7 @@ static ssize_t f_hidg_write(struct file *file, const char 
__user *buffer,
size_t count, loff_t *offp)
 {
struct f_hidg *hidg  = file->private_data;
+   struct usb_composite_dev *cdev = hidg->func.config->cdev;
struct usb_request *req;
unsigned long flags;
ssize_t status = -ENOMEM;
@@ -346,6 +347,7 @@ static ssize_t f_hidg_write(struct file *file, const char 
__user *buffer,
if (!access_ok(VERIFY_READ, buffer, count))
return -EFAULT;

+   usb_gadget_wakeup(cdev->gadget);
spin_lock_irqsave(>write_spinlock, flags);

 #define WRITE_COND (!hidg->write_pending)
--
2.9.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

[PATCH v2] usb: serial: Add support for Qivicon USB ZigBee dongle

[Stefan Triller]

The German Telekom offers a ZigBee USB Stick under the brand name Qivicon
for their SmartHome Home Base in its 1. Generation. The productId is not
known by the according kernel module, this patch adds support for it.

Signed-off-by: Stefan Triller 
---
 drivers/usb/serial/cp210x.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index 0c55e7f64269..d37e9d4d617b 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -141,6 +141,7 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x10C4, 0x8977) }, /* CEL MeshWorks DevKit Device */
{ USB_DEVICE(0x10C4, 0x8998) }, /* KCF Technologies PRN */
{ USB_DEVICE(0x10C4, 0x8A2A) }, /* HubZ dual ZigBee and Z-Wave dongle */
+   { USB_DEVICE(0x10C4, 0x8B34) }, /* Qivicon ZigBee USB Radio Stick  */
{ USB_DEVICE(0x10C4, 0xEA60) }, /* Silicon Labs factory default */
{ USB_DEVICE(0x10C4, 0xEA61) }, /* Silicon Labs factory default */
{ USB_DEVICE(0x10C4, 0xEA70) }, /* Silicon Labs factory default */
-- 
2.13.1

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

Re: [PATCH 1/1] Add support for Qivicon USB ZigBee dongle

[Frans Klaver]

Hi,

You should probably mention the relevant subsystem in your subject.

On Fri, Jun 30, 2017 at 11:43 AM, Stefan Triller
 wrote:
> The german Telekom offers a ZigBee USB Stick under the brand name Qivicon for 
> their SmartHome Home Base in its 1. Generation. The productId is not known by 
> the according kernel module, this patch adds support for it.

Please wrap your commit messages at 75 characters. See
Documentation/process/submitting-patches.rst.

> You can buy the stick here: 
> https://www.smarthome.de/geraete/telekom-smart-home-erweiterung-zigbee

Is this a commercial? :-P

Frans
--
To unsubscribe from this list: send the line "unsubscribe 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:gadget:hid: [PATCH] Remote Wakeup Support

[Frans Klaver]

Hi,

On Tue, Jun 27, 2017 at 11:04 PM, Abdulhadi Mohamed
 wrote:
> Currently linux HID gadgets do not support remote wakeup (the ability
> to wake up a host from suspend). This is an important feature for gadgets
> that want to properly emulate the normal operation of a mouse and keyboard.
> This feature has to be enabled/supported by the underlying UDC driver
> to have any impact.

"[PATCH]" goes before the subsystems in your subject.
--
To unsubscribe from this list: send the line "unsubscribe 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] {GET,SET} PROCOTOL Support

[Frans Klaver]

On Fri, Jun 23, 2017 at 4:55 PM, Abdulhadi Mohamed
 wrote:
> the current HID function dirver doesn't support GET_PROCOTOL and
> SET_PROCOTOL commands, which are required to operate the HID gadget in
> BOOT mode. This change implements this feature for devices that have
> the same implementation for REPORT and BOOT mode

Your subject should contain the subsystems involved, and you should
provide a version number with your new version so it is clear which
one is the one to take.

Subject: [PATCH v2] usb: gadget: hid: Add support for {GET,SET}_PROTOCOL

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

[PATCHv2 0/3] USB Audio Gadget: Support multiple sampling rates

[Julian Scheel]

Sending v2 of this patch series, including fixes for build regressions
introduced with the original series. I missed the usage of f_uac* in the
legacy modules and did not test that. Fixed now, see patches changelog for
details.

This patch series adds support for exposing multiple supported sampling rates
from UAC1 and UAC2 USB gadgets to the connected host. It is currently limited
to up to ten discrete sampling frequencies. The USB specification does not
actually limit this, but to avoid complex list handling I am using a static
array for now.
As the configfs bindings for f_uac1 and f_uac2 have been identical already, I
decided to move the shared code for this out of the functions first. This
avoids code duplication and simplifies the addition of the list parsing for
sampling rates.
The host can configure active sampling rate and the function adapts it's
internal active rate automatically. On playback/capture start the rate is
checked, so that the user recognizes rate mismatches. Furthermore the active
rate is exposed as an amixer control with change notifications, so that
users can check current rate upfront and get notified about updates.

Julian Scheel (3):
  usb: gadget: f_uac1: Fix endpoint reading
  usb: gadget: f_uac*: Reduce code duplication
  usb: gadget: f_uac*: Support multiple sampling rates

 Documentation/ABI/testing/configfs-usb-gadget-uac1 |   4 +-
 Documentation/usb/gadget-testing.txt   |   8 +-
 drivers/usb/gadget/function/f_uac1.c   | 258 +-
 drivers/usb/gadget/function/f_uac2.c   | 297 ++---
 drivers/usb/gadget/function/u_audio.c  | 118 +++-
 drivers/usb/gadget/function/u_audio.h  |   9 +-
 drivers/usb/gadget/function/u_uac.h| 180 +
 drivers/usb/gadget/function/u_uac1.h   |  41 ---
 drivers/usb/gadget/function/u_uac2.h   |  44 ---
 drivers/usb/gadget/legacy/audio.c  |  91 ++-
 10 files changed, 608 insertions(+), 442 deletions(-)
 create mode 100644 drivers/usb/gadget/function/u_uac.h
 delete mode 100644 drivers/usb/gadget/function/u_uac1.h
 delete mode 100644 drivers/usb/gadget/function/u_uac2.h

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

[PATCHv2 3/3] usb: gadget: f_uac*: Support multiple sampling rates

[Julian Scheel]

Implement support for multiple sampling rates in the USB Audio gadgets.
A list of sampling rates can be specified via configfs. All enabled
sampling rates are sent to the USB host on request. When the host
selects a sampling rate the internal active rate is updated. The
currently configured rates are exposed through amixer controls. Also on
pcm open from userspace the requested rated is checked against the
currently configured rate of the host.

Signed-off-by: Julian Scheel 
---
 Documentation/ABI/testing/configfs-usb-gadget-uac1 |   4 +-
 Documentation/usb/gadget-testing.txt   |   8 +-
 drivers/usb/gadget/function/f_uac1.c   | 120 +
 drivers/usb/gadget/function/f_uac2.c   | 146 +++--
 drivers/usb/gadget/function/u_audio.c  | 119 -
 drivers/usb/gadget/function/u_audio.h  |   9 +-
 drivers/usb/gadget/function/u_uac.h|  68 +-
 7 files changed, 396 insertions(+), 78 deletions(-)

diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uac1 
b/Documentation/ABI/testing/configfs-usb-gadget-uac1
index abfe447c848f..ad2fa4a00918 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget-uac1
+++ b/Documentation/ABI/testing/configfs-usb-gadget-uac1
@@ -5,10 +5,10 @@ Description:
The attributes:
 
c_chmask - capture channel mask
-   c_srate - capture sampling rate
+   c_srate - list of capture sampling rates (comma-separataed)
c_ssize - capture sample size (bytes)
p_chmask - playback channel mask
-   p_srate - playback sampling rate
+   p_srate - list of playback sampling rates (comma-separated)
p_ssize - playback sample size (bytes)
req_number - the number of pre-allocated request
for both capture and playback
diff --git a/Documentation/usb/gadget-testing.txt 
b/Documentation/usb/gadget-testing.txt
index fbc397d17e98..85878880 100644
--- a/Documentation/usb/gadget-testing.txt
+++ b/Documentation/usb/gadget-testing.txt
@@ -629,10 +629,10 @@ The function name to use when creating the function 
directory is "uac2".
 The uac2 function provides these attributes in its function directory:
 
c_chmask - capture channel mask
-   c_srate - capture sampling rate
+   c_srate - list of capture sampling rates (comma-separated)
c_ssize - capture sample size (bytes)
p_chmask - playback channel mask
-   p_srate - playback sampling rate
+   p_srate - list of playback sampling rates (comma-separated)
p_ssize - playback sample size (bytes)
req_number - the number of pre-allocated request for both capture
 and playback
@@ -790,10 +790,10 @@ The function name to use when creating the function 
directory is "uac1".
 The uac1 function provides these attributes in its function directory:
 
c_chmask - capture channel mask
-   c_srate - capture sampling rate
+   c_srate - list of capture sampling rates (comma-separated)
c_ssize - capture sample size (bytes)
p_chmask - playback channel mask
-   p_srate - playback sampling rate
+   p_srate - list of playback sampling rates (comma-separated)
p_ssize - playback sample size (bytes)
req_number - the number of pre-allocated request for both capture
 and playback
diff --git a/drivers/usb/gadget/function/f_uac1.c 
b/drivers/usb/gadget/function/f_uac1.c
index 6e86e4f704e1..d14777973b9f 100644
--- a/drivers/usb/gadget/function/f_uac1.c
+++ b/drivers/usb/gadget/function/f_uac1.c
@@ -2,6 +2,7 @@
  * f_uac1.c -- USB Audio Class 1.0 Function (using u_audio API)
  *
  * Copyright (C) 2016 Ruslan Bilovol 
+ * Copyright (C) 2017 Julian Scheel 
  *
  * This driver doesn't expect any real Audio codec to be present
  * on the device - the audio streams are simply sinked to and
@@ -175,16 +176,18 @@ static struct uac1_as_header_descriptor as_in_header_desc 
= {
.wFormatTag =   UAC_FORMAT_TYPE_I_PCM,
 };
 
-DECLARE_UAC_FORMAT_TYPE_I_DISCRETE_DESC(1);
+DECLARE_UAC_FORMAT_TYPE_I_DISCRETE_DESC(UAC_MAX_RATES);
+#define uac_format_type_i_discrete_descriptor \
+   uac_format_type_i_discrete_descriptor_##UAC_MAX_RATES
 
-static struct uac_format_type_i_discrete_descriptor_1 as_out_type_i_desc = {
-   .bLength =  UAC_FORMAT_TYPE_I_DISCRETE_DESC_SIZE(1),
+static struct uac_format_type_i_discrete_descriptor as_out_type_i_desc = {
+   .bLength =  0, /* filled on rate setup */
.bDescriptorType =  USB_DT_CS_INTERFACE,
.bDescriptorSubtype =   UAC_FORMAT_TYPE,
.bFormatType =  UAC_FORMAT_TYPE_I,
.bSubframeSize =2,
.bBitResolution =   16,
-   .bSamFreqType = 1,
+   .bSamFreqType = 

[PATCHv2 2/3] usb: gadget: f_uac*: Reduce code duplication

[Julian Scheel]

This replaces the dedicated headers for uac1 and uac2 functions with a
shared header for both of them. Apart from unifying the struct names,
further duplicated code for configfs setup is moved out of the function
files into the shared header.

Signed-off-by: Julian Scheel 
---
Changes in v2:
- Fix build as module
- Fix build of legacy/audio module in f_uac1/f_uac2 mode

 drivers/usb/gadget/function/f_uac1.c  | 142 --
 drivers/usb/gadget/function/f_uac2.c  | 161 ++
 drivers/usb/gadget/function/u_audio.c |   1 -
 drivers/usb/gadget/function/u_uac.h   | 116 
 drivers/usb/gadget/function/u_uac1.h  |  41 -
 drivers/usb/gadget/function/u_uac2.h  |  44 --
 drivers/usb/gadget/legacy/audio.c |  91 +--
 7 files changed, 222 insertions(+), 374 deletions(-)
 create mode 100644 drivers/usb/gadget/function/u_uac.h
 delete mode 100644 drivers/usb/gadget/function/u_uac1.h
 delete mode 100644 drivers/usb/gadget/function/u_uac2.h

diff --git a/drivers/usb/gadget/function/f_uac1.c 
b/drivers/usb/gadget/function/f_uac1.c
index b955913bd7ea..6e86e4f704e1 100644
--- a/drivers/usb/gadget/function/f_uac1.c
+++ b/drivers/usb/gadget/function/f_uac1.c
@@ -21,18 +21,7 @@
 #include 
 
 #include "u_audio.h"
-#include "u_uac1.h"
-
-struct f_uac1 {
-   struct g_audio g_audio;
-   u8 ac_intf, as_in_intf, as_out_intf;
-   u8 ac_alt, as_in_alt, as_out_alt;   /* needed for get_alt() */
-};
-
-static inline struct f_uac1 *func_to_uac1(struct usb_function *f)
-{
-   return container_of(f, struct f_uac1, g_audio.func);
-}
+#include "u_uac.h"
 
 /*
  * DESCRIPTORS ... most are static, but strings and full
@@ -435,7 +424,7 @@ static int f_audio_set_alt(struct usb_function *f, unsigned 
intf, unsigned alt)
struct usb_composite_dev *cdev = f->config->cdev;
struct usb_gadget *gadget = cdev->gadget;
struct device *dev = >dev;
-   struct f_uac1 *uac1 = func_to_uac1(f);
+   struct f_uac *uac1 = func_to_uac(f);
int ret = 0;
 
/* No i/f has more than 2 alt settings */
@@ -480,7 +469,7 @@ static int f_audio_get_alt(struct usb_function *f, unsigned 
intf)
struct usb_composite_dev *cdev = f->config->cdev;
struct usb_gadget *gadget = cdev->gadget;
struct device *dev = >dev;
-   struct f_uac1 *uac1 = func_to_uac1(f);
+   struct f_uac *uac1 = func_to_uac(f);
 
if (intf == uac1->ac_intf)
return uac1->ac_alt;
@@ -498,7 +487,7 @@ static int f_audio_get_alt(struct usb_function *f, unsigned 
intf)
 
 static void f_audio_disable(struct usb_function *f)
 {
-   struct f_uac1 *uac1 = func_to_uac1(f);
+   struct f_uac *uac1 = func_to_uac(f);
 
uac1->as_out_alt = 0;
uac1->as_in_alt = 0;
@@ -513,16 +502,16 @@ static int f_audio_bind(struct usb_configuration *c, 
struct usb_function *f)
 {
struct usb_composite_dev*cdev = c->cdev;
struct usb_gadget   *gadget = cdev->gadget;
-   struct f_uac1   *uac1 = func_to_uac1(f);
+   struct f_uac*uac1 = func_to_uac(f);
struct g_audio  *audio = func_to_g_audio(f);
-   struct f_uac1_opts  *audio_opts;
+   struct f_uac_opts   *audio_opts;
struct usb_ep   *ep = NULL;
struct usb_string   *us;
u8  *sam_freq;
int rate;
int status;
 
-   audio_opts = container_of(f->fi, struct f_uac1_opts, func_inst);
+   audio_opts = container_of(f->fi, struct f_uac_opts, func_inst);
 
us = usb_gstrings_attach(cdev, uac1_strings, ARRAY_SIZE(strings_uac1));
if (IS_ERR(us))
@@ -630,82 +619,27 @@ static int f_audio_bind(struct usb_configuration *c, 
struct usb_function *f)
 
 /*-*/
 
-static inline struct f_uac1_opts *to_f_uac1_opts(struct config_item *item)
-{
-   return container_of(to_config_group(item), struct f_uac1_opts,
-   func_inst.group);
-}
-
-static void f_uac1_attr_release(struct config_item *item)
-{
-   struct f_uac1_opts *opts = to_f_uac1_opts(item);
-
-   usb_put_function_instance(>func_inst);
-}
-
 static struct configfs_item_operations f_uac1_item_ops = {
-   .release= f_uac1_attr_release,
+   .release= f_uac_attr_release,
 };
 
-#define UAC1_ATTRIBUTE(name)   \
-static ssize_t f_uac1_opts_##name##_show(  \
- struct config_item *item, \
- char *page)   \
-{  \
-   struct f_uac1_opts *opts = 

[PATCHv2 1/3] usb: gadget: f_uac1: Fix endpoint reading

[Julian Scheel]

The endpoint is stored in the lower byte of wIndex, according to USB
Audio 1.0 specification, section 5.2.1.1.

Signed-off-by: Julian Scheel 
---
 drivers/usb/gadget/function/f_uac1.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/function/f_uac1.c 
b/drivers/usb/gadget/function/f_uac1.c
index 8656f84e17d9..b955913bd7ea 100644
--- a/drivers/usb/gadget/function/f_uac1.c
+++ b/drivers/usb/gadget/function/f_uac1.c
@@ -327,7 +327,7 @@ static int audio_set_endpoint_req(struct usb_function *f,
 {
struct usb_composite_dev *cdev = f->config->cdev;
int value = -EOPNOTSUPP;
-   u16 ep = le16_to_cpu(ctrl->wIndex);
+   u8  ep = le16_to_cpu(ctrl->wIndex) & 0xff;
u16 len = le16_to_cpu(ctrl->wLength);
u16 w_value = le16_to_cpu(ctrl->wValue);
 
@@ -363,7 +363,7 @@ static int audio_get_endpoint_req(struct usb_function *f,
 {
struct usb_composite_dev *cdev = f->config->cdev;
int value = -EOPNOTSUPP;
-   u8 ep = ((le16_to_cpu(ctrl->wIndex) >> 8) & 0xFF);
+   u8 ep = le16_to_cpu(ctrl->wIndex) & 0xff;
u16 len = le16_to_cpu(ctrl->wLength);
u16 w_value = le16_to_cpu(ctrl->wValue);
 
-- 
2.13.2

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

[PATCH] usb: dwc2: Add safety check in setting of descriptor chain pointers

[Minas Harutyunyan]

In some MSC CV tests device sending ZLP IN on non EP0 which
reassigning EP0 OUT descriptor pointer to that EP.
Dedicated for EP0 OUT descriptor multiple time re-used by
other EP while that descriptor already in use by EP0 OUT
for SETUP transaction. As result when SETUP packet received
BNA interrupt asserting.

In dwc2_hsotg_program_zlp() function dwc2_gadget_set_ep0_desc_chain()
must be called only for EP0.

Signed-off-by: Minas Harutyunyan 
---
 drivers/usb/dwc2/gadget.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 98a4a79e7f6e..3dc08f6847df 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -1943,7 +1943,9 @@ static void dwc2_hsotg_program_zlp(struct dwc2_hsotg 
*hsotg,
/* Not specific buffer needed for ep0 ZLP */
dma_addr_t dma = hs_ep->desc_list_dma;
 
-   dwc2_gadget_set_ep0_desc_chain(hsotg, hs_ep);
+   if (!index)
+   dwc2_gadget_set_ep0_desc_chain(hsotg, hs_ep);
+
dwc2_gadget_config_nonisoc_xfer_ddma(hs_ep, dma, 0);
} else {
dwc2_writel(DXEPTSIZ_MC(1) | DXEPTSIZ_PKTCNT(1) |
-- 
2.11.0

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

[PATCH 1/1] Add support for Qivicon USB ZigBee dongle

[Stefan Triller]

The german Telekom offers a ZigBee USB Stick under the brand name Qivicon for 
their SmartHome Home Base in its 1. Generation. The productId is not known by 
the according kernel module, this patch adds support for it.

You can buy the stick here: 
https://www.smarthome.de/geraete/telekom-smart-home-erweiterung-zigbee

Signed-off-by: Stefan Triller 
---
 drivers/usb/serial/cp210x.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index 0c55e7f64269..d37e9d4d617b 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -141,6 +141,7 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x10C4, 0x8977) }, /* CEL MeshWorks DevKit Device */
{ USB_DEVICE(0x10C4, 0x8998) }, /* KCF Technologies PRN */
{ USB_DEVICE(0x10C4, 0x8A2A) }, /* HubZ dual ZigBee and Z-Wave dongle */
+   { USB_DEVICE(0x10C4, 0x8B34) }, /* Qivicon ZigBee USB Radio Stick  */
{ USB_DEVICE(0x10C4, 0xEA60) }, /* Silicon Labs factory default */
{ USB_DEVICE(0x10C4, 0xEA61) }, /* Silicon Labs factory default */
{ USB_DEVICE(0x10C4, 0xEA70) }, /* Silicon Labs factory default */
-- 
2.13.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

Add support for Qivicon USB ZigBee dongle

[Stefan Triller]

This patch adds support for the Qivicon ZigBee USB dongle. Qivicon
is a brand by the german Telekom and they sell this stick for use
with their SmartHome Home Base 1. In order to use this rather 
famous stick on regular Linux PCs this patch is neccessary. 

You can buy it here:
https://www.smarthome.de/geraete/telekom-smart-home-erweiterung-zigbee

Kind Regards,

Stefan Triller
--
To unsubscribe from this list: send the line "unsubscribe 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] PCI / PM: Avoid using device_may_wakeup() for runtime PM

[Mika Westerberg]

On Fri, Jun 30, 2017 at 12:37:00AM +0200, Rafael J. Wysocki wrote:
> On Friday, June 23, 2017 02:58:11 PM Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki 
> > 
> > pci_target_state() calls device_may_wakeup() which checks whether
> > or not the device may wake up the system from sleep states, but
> > pci_target_state() is used for runtime PM too.
> > 
> > Since runtime PM is expected to always enable remote wakeup if
> > possible, modify pci_target_state() to take additional argument
> > indicating whether or not it should look for a state from which
> > the device can signal wakeup and pass either the return value
> > of device_can_wakeup(), or "false" (if the device itself is not
> > wakeup-capable) to it from the code related to runtime PM.
> > 
> > While at it, fix the comment in pci_dev_run_wake() which is not
> > about sleep states.
> > 
> > Signed-off-by: Rafael J. Wysocki 
> > ---
> > 
> > -> v2:
> > 
> > Passing "true" as the second argument to pci_target_state() for runtime PM
> > might trigger suboptimal state choices to be made, so pass the return value
> > of device_can_wakeup() to it instead and pass "false" to it in 
> > pci_dev_run_wake(),
> > because that assumes device_can_wakeup() to return "false" already.
> 
> This was sent a week ago without any response so far.
> 
> Any concerns?

No concerns from me.

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