Re: [USB] f16443a034: EIP:arch_local_irq_restore
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(&dum->lock); if (reset) usb_gadget_udc_reset(&dum->gadget, dum->driver); else dum->driver->disconnect(&dum->gadget); + spin_lock(&dum->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(&dum->lock); if (dum_hcd->old_active && dum->driver->suspend) dum->driver->suspend(&dum->gadget); - else if (!dum_hcd->old_active && dum->driver->resume) + else if (!dum_hcd->old_active && dum->driver->resume) dum->driver->resume(&dum->gadget); + spin_lock(&dum->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(&dum->lock); - dum->driver = NULL; - spin_unlock_irq(&dum->lock); + /* Wait until no callbacks are running, then unbind the driver */ + for (;;) { + int c; + + spin_lock_irq(&dum->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
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
"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
> 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
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
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
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
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->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->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->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->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 = &pci_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(&dev->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(&dev->power.lock); > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in
Re: [PATCH] usb: typec: include linux/device.h in ucsi.h
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
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
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&m=149842193906284&w=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
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&m=149842193906284&w=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
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
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(&hidg->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
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(&hidg->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
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
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(&hidg->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
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
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
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
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
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
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 = 0, /* filled on rate setup */ }; /* Standard ISO OUT Endpo
[PATCHv2 2/3] usb: gadget: f_uac*: Reduce code duplication
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 = &gadget->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 = &gadget->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(&opts->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
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
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
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
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
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