Re: [PATCH] usb: check for signals in chaoskey read function
On Mon, 2016-02-15 at 18:49 -0800, Keith Packard wrote: > Call signal_pending before reading a chunk of data from the device so > that long read operations can be interrupted with a signal. Hi, why is this needed? You are doing this right after a mutex_lock_interruptible(). Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/1] USB: core: let USB device know device node
From: Peter Chen
Although most of USB devices are hot-plug's, there are still some devices
are hard wired on the board, eg, for HSIC and SSIC interface USB devices.
If these kinds of USB devices are multiple functions, and they can supply
other interfaces like i2c, gpios for other devices, we may need to
describe these at device tree.
In this commit, it uses "reg" in dts as physical port number to match
the phyiscal port number decided by USB core, if they are the same,
then the device node is for the device we are creating for USB core.
Signed-off-by: Peter Chen
---
Changes for v5:
- Refine the code how to get the device node at usb_alloc_dev according
to Alan's comment.
- Point out "usbVID,PID" is the recommented compatible, and others
compatibles at binding doc could also be used.
Changes for v4:
- The range of "reg" should be 1-31, changing device node address
style as in lower case hexadecimal with leading zeroes suppressed
[binding doc, usb-device.txt]
- Improve the example at binding doc, it describes node from the top
(the controller)
- Delete the struct of_node * within struct usb_device
- Using usb_hcd_find_raw_port_number to get raw port number under root
hub port
Changes for v3:
- typo: s/descirbe/describe/
Changes for v2:
- Fix build error reported by kbuild robot, lack of "static" for
inline usb_of_get_child_node
- Fix typo, "devcie_node" -> "device_node"
- Add kernel-doc for of_node at struct usb_device
Changes from RFC:
- Fix the error address for binding doc, and add compatible for binding doc
- Change get child node API from "usb_of_find_node" to
"usb_of_get_child_node"
- Delete unecessary header files
- One typo
.../devicetree/bindings/usb/usb-device.txt | 26
drivers/usb/core/Makefile | 2 +-
drivers/usb/core/of.c | 47 ++
drivers/usb/core/usb.c | 10 +
include/linux/usb/of.h | 7
5 files changed, 91 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/usb/usb-device.txt
create mode 100644 drivers/usb/core/of.c
diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt
b/Documentation/devicetree/bindings/usb/usb-device.txt
new file mode 100644
index 000..a997a23
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb-device.txt
@@ -0,0 +1,26 @@
+Generic USB Device Properties
+
+Usually, we only use device tree for hard wired USB device.
+The reference binding doc is from:
+http://www.firmware.org/1275/bindings/usb/usb-1_0.ps
+
+Required properties:
+- compatible: usbVID,PID. The other compatible strings from the above
+ standard binding could also be used, but a device adhering to this
+ binding may leave out all except for usbVID,PID.
+- reg: the port number which this device is connecting to, the range
+ is 1-31.
+
+Example:
+
+&usb1 {
+ status = "okay";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hub: genesys@1 {
+ compatible = "usb05e3,0608";
+ reg = <1>;
+ };
+}
diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
index 2f6f932..9780877 100644
--- a/drivers/usb/core/Makefile
+++ b/drivers/usb/core/Makefile
@@ -5,7 +5,7 @@
usbcore-y := usb.o hub.o hcd.o urb.o message.o driver.o
usbcore-y += config.o file.o buffer.o sysfs.o endpoint.o
usbcore-y += devio.o notify.o generic.o quirks.o devices.o
-usbcore-y += port.o
+usbcore-y += port.o of.o
usbcore-$(CONFIG_PCI) += hcd-pci.o
usbcore-$(CONFIG_ACPI) += usb-acpi.o
diff --git a/drivers/usb/core/of.c b/drivers/usb/core/of.c
new file mode 100644
index 000..2289700
--- /dev/null
+++ b/drivers/usb/core/of.c
@@ -0,0 +1,47 @@
+/*
+ * of.cThe helpers for hcd device tree support
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Author: Peter Chen
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see
Re: [PATCH v3 0/2] usbip: vhci number of ports extension
On Mon, 2016-02-15 at 16:43 -0800, Greg KH wrote: > On Tue, Feb 16, 2016 at 12:37:57AM +, fx IWATA NOBUO wrote: > > My requirement is more device can be attached than 31 to connect > > many IoT devices. > > That's an odd requirement to use the USB protocol for, especially when > that is a hard-coded restriction in the USB protocol from what I > recall. No. It depends on the version. For 3.x the limit is 16 (4 bit in the routing string); for 2.x the limit is 255. (bNbrPorts in the hub descriptor) 31 is indeed the hard-coded limit for endpoints. [..] > > This patch: > > Default is 31. Changeable by -DVHCI_NPORTS up to USB_MAXCHILDREN. > > Negative in previous e-mail, so I may change 8. > > To reduce most outstanding overhead - event threads for each port, > > I made patch 2/2. Maybe your problem is that you have a thread for each port? Children of the same hub share resources of the hub and are on the same bus. If the bus is virtual these restrictions don't apply, so do you really want them to appear to be on the same hub? Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: chipidea: fix return value check in ci_hdrc_pci_probe()
On Sat, Feb 06, 2016 at 10:57:06PM +0800, weiyj...@163.com wrote: > From: Wei Yongjun > > In case of error, the function usb_phy_generic_register() > returns ERR_PTR() and never returns NULL. The NULL test in > the return value check should be replaced with IS_ERR(). > > Signed-off-by: Wei Yongjun > --- > drivers/usb/chipidea/ci_hdrc_pci.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/usb/chipidea/ci_hdrc_pci.c > b/drivers/usb/chipidea/ci_hdrc_pci.c > index b59195e..b635ab6 100644 > --- a/drivers/usb/chipidea/ci_hdrc_pci.c > +++ b/drivers/usb/chipidea/ci_hdrc_pci.c > @@ -85,8 +85,8 @@ static int ci_hdrc_pci_probe(struct pci_dev *pdev, > > /* register a nop PHY */ > ci->phy = usb_phy_generic_register(); > - if (!ci->phy) > - return -ENOMEM; > + if (IS_ERR(ci->phy)) > + return PTR_ERR(ci->phy); > > memset(res, 0, sizeof(res)); > res[0].start= pci_resource_start(pdev, 0); > The original code has several issues: First, usb_phy_generic_register returns pointers of platform_device Second, the generic USB PHY driver is related to struct usb_phy, but not struct phy. So, in this code, it needs to use ci->usb_phy to get the pointer of struct usb_phy used at generic USB PHY driver. Would you mind sending the patches to fix them? -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface
Hi, On Mon, Feb 15, 2016 at 04:30:18PM +0100, Oliver Neukum wrote: > On Thu, 2016-02-11 at 15:50 +0200, Heikki Krogerus wrote: > > Because USB Type-C ports (DRP ones) will select the data role randomly > > when you connect (to an other DRP port). USB Type-C spec defines that > > you can "prefer" host mode, but when both ends prefer host mode, it's > > +-0. > > That question has not been answered. It would be awkward for the OS > to find itself in the slave role, which it is ill equipped for. So > the data role should be switched before the new device is announced > to user space. How is that handled? In the class driver, once we add support for preselecting the role, when the connection happens we compare the initial role to the preselected one and execute swap if it differs. Only after that we notify userspace. Thanks, -- heikki -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] usb: gadget: pxa25x_udc: use readl/writel for mmio
Arnd Bergmann writes: > The barriers on a spinlock synchronize between CPUs but not an external > bus, so (on some architectures) a spinlock protecting an MMIO register > does not guarantee that two CPUs doing > > spin_lock(); > __raw_writel(address); > __raw_writel(data); > spin_unlock(); > > would cause pairs of address/data to be seen on the bus. > > Of course this is meaningless on ixp4xx, as there is only one CPU. I still don't get it. If the spinlocks synchronize between CPUs, there can only be one CPU (or core) doing the pair of raw_writel(), so how would it be possible to not get the address/data pair written out? IOW, how is it different from a system with a single CPU? > On powerpc, we have in_le32/in_be32 for SoC-internal register access, > while only PCI devices are allowed to be accessed using readl(). Yeah, this seems like a sane solution. > I would suggest using an ixp4xx specific set of accessors that comes down > to either readl() or ioread32_be(), depending on whether CONFIG_CPU_BIG_ENDIAN > is set. That makes it clear that there is a magic bus involved and that it > works on this platform but not in portable code. Hmm. This is actually the opposite - while there may be some magic (swapping) in readl() and friends, there is absolutely no magic in the __raw_readl() etc. They are essentially equivalent to *(volatile u32 *)ptr. This is constant and doesn't depend on endianess, PCI, anything. -- Krzysztof Halasa Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland -- 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
commit eb6b92ecc0f9412623ab1584ddd8389b371638d4 - disconnect() and poll() don't cooperate
Hi, in this commit you introduce a poll method that bails out if you poll a disconnected device. That is good but a bit insufficient. Poll needs to learn that a device is going away. usbtmc_disconnect() needs to call wakeup_all() on data->waitq Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 2/2] usb:dwc3: pass arch data to xhci-hcd child
Hi, Do you have any feedback on this change? Regards, Thang Q. Nguyen - -Original Message- From: Thang Q. Nguyen [mailto:tqngu...@apm.com] Sent: Monday, January 25, 2016 9:26 PM To: Felipe Balbi; Greg Kroah-Hartman; linux-usb@vger.kernel.org; linux-o...@vger.kernel.org; linux-ker...@vger.kernel.org; linux-...@lists.infradead.org Cc: Thang Nguyen; Phong Vo; Loc Ho; patc...@apm.com Subject: [PATCH v2 2/2] usb:dwc3: pass arch data to xhci-hcd child The xhci-hcd child node needs to inherit archdata attribute to use dma_ops functions and attributes. This patch enables the USB DWC3 driver to pass archdata attributes to its xhci-hcd child node. Signed-off-by: Thang Q. Nguyen --- Changes from v1: - None drivers/usb/dwc3/host.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c index c679f63..661fbae 100644 --- a/drivers/usb/dwc3/host.c +++ b/drivers/usb/dwc3/host.c @@ -37,6 +37,7 @@ int dwc3_host_init(struct dwc3 *dwc) xhci->dev.parent= dwc->dev; xhci->dev.dma_mask = dwc->dev->dma_mask; xhci->dev.dma_parms = dwc->dev->dma_parms; + xhci->dev.archdata = dwc->dev->archdata; dwc->xhci = xhci; -- 2.2.0 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 1/2] usb:dwc3: Enable support for 64-bit system
Hi,
Do you have any more feedback on this patch?
Thanks,
Thang Q. Nguyen -
-Original Message-
From: Thang Q. Nguyen [mailto:tqngu...@apm.com]
Sent: Monday, January 25, 2016 9:26 PM
To: Felipe Balbi; Greg Kroah-Hartman; linux-usb@vger.kernel.org;
linux-o...@vger.kernel.org; linux-ker...@vger.kernel.org;
linux-...@lists.infradead.org
Cc: Thang Nguyen; Phong Vo; Loc Ho; patc...@apm.com
Subject: [PATCH v2 1/2] usb:dwc3: Enable support for 64-bit system
Add 64-bit DMA operation support to the USB DWC3 driver.
First attempt to set the coherent DMA mask for 64-bit DMA.
If that failed, attempt again with 32-bit DMA.
Signed-off-by: Thang Q. Nguyen
---
Changes from v1:
- Remove WARN_ON if dma_mask is NULL
drivers/usb/dwc3/core.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index
de5e01f..2479c24 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -831,6 +831,21 @@ static int dwc3_probe(struct platform_device *pdev)
dwc->mem = mem;
dwc->dev = dev;
+ /* Try to set 64-bit DMA first */
+ if (!pdev->dev.dma_mask)
+ /* Platform did not initialize dma_mask */
+ ret = dma_coerce_mask_and_coherent(&pdev->dev,
+ DMA_BIT_MASK(64));
+ else
+ ret = dma_set_mask_and_coherent(&pdev->dev,
DMA_BIT_MASK(64));
+
+ /* If seting 64-bit DMA mask fails, fall back to 32-bit DMA mask
*/
+ if (ret) {
+ ret = dma_set_mask_and_coherent(&pdev->dev,
DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
+ }
+
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (!res) {
dev_err(dev, "missing IRQ\n");
--
2.2.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
commit 4b61b4f205eabfc9f863f805858aa5b32deb3de5 - usb: add HAS_IOMEM dependency to USB_APPLEDISPLAY
Hi, you make USB_APPLEDISPLAY depend on HAS_IOMEM. I am afraid you got it the wrong way round. There is really no reason for a high level USB driver to access memory. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] usb: gadget: pxa25x_udc: use readl/writel for mmio
On Tuesday 16 February 2016 10:26:14 Krzysztof Hałasa wrote: > Arnd Bergmann writes: > > > The barriers on a spinlock synchronize between CPUs but not an external > > bus, so (on some architectures) a spinlock protecting an MMIO register > > does not guarantee that two CPUs doing > > > > spin_lock(); > > __raw_writel(address); > > __raw_writel(data); > > spin_unlock(); > > > > would cause pairs of address/data to be seen on the bus. > > > > Of course this is meaningless on ixp4xx, as there is only one CPU. > > I still don't get it. If the spinlocks synchronize between CPUs, there > can only be one CPU (or core) doing the pair of raw_writel(), so how > would it be possible to not get the address/data pair written out? > IOW, how is it different from a system with a single CPU? Both writes leave the CPU core within the spinlock but are not serialized with anything else, so there is no ordering between the CPUs when they enter the shared bus, other than having address before data. You'd expect to see address0, data0, address1, data1, but it could also be e.g. address0, address1, data1, data0. > > On powerpc, we have in_le32/in_be32 for SoC-internal register access, > > while only PCI devices are allowed to be accessed using readl(). > > Yeah, this seems like a sane solution. > > > I would suggest using an ixp4xx specific set of accessors that comes down > > to either readl() or ioread32_be(), depending on whether > > CONFIG_CPU_BIG_ENDIAN > > is set. That makes it clear that there is a magic bus involved and that it > > works on this platform but not in portable code. > > Hmm. This is actually the opposite - while there may be some magic > (swapping) in readl() and friends, there is absolutely no magic in the > __raw_readl() etc. They are essentially equivalent to > *(volatile u32 *)ptr. This is constant and doesn't depend on endianess, > PCI, anything. The point is more what the common case is. Almost all machines we support have fixed-endian devices, and the drivers are correct when using readl() or in_le32() but are not endian-safe when using __raw_readl(). Using __raw_readl() has the big danger of someone accidentally "fixing" the driver to work like all the others in order to solve a theoretical endian problem, while it should really be made obvious that the hardware actively swaps its data on the bus. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: commit 4b61b4f205eabfc9f863f805858aa5b32deb3de5 - usb: add HAS_IOMEM dependency to USB_APPLEDISPLAY
On 02/16/2016 12:00 PM, Oliver Neukum wrote: Hi, you make USB_APPLEDISPLAY depend on HAS_IOMEM. I am afraid you got it the wrong way round. There is really no reason for a high level USB driver to access memory. Alright, let's have a look. The warning I was fixing in this patch was: warning: (USB_APPLEDISPLAY) selects BACKLIGHT_LCD_SUPPORT which has unmet direct dependencies (HAS_IOMEM) The problem is that USB_APPLEDISPLAY has 'select BACKLIGHT_LCD_SUPPORT', but BACKLIGHT_LCD_SUPPORT has a dependency on HAS_IOMEM: menu "Graphics support" depends on HAS_IOMEM ... source "drivers/video/backlight/Kconfig" So this means that you are able to enable USB_APPLEDISPLAY even though technically the Kconfig language doesn't support/allow it. Looking at the "Graphics support" dependency on HAS_IOMEM, this was added in the same patch that disabled USB for UML in the first place: commit e25df1205f37c7bff3ab14fdfc8a5249f3c69c82 Author: Martin Schwidefsky Date: Thu May 10 15:45:57 2007 +0200 [S390] Kconfig: menus with depends on HAS_IOMEM. Add "depends on HAS_IOMEM" to a number of menus to make them disappear for s390 which does not have I/O memory. Signed-off-by: Martin Schwidefsky ...in other words, I am inclined to agree with you that adding the dependency for USB_APPLEDISPLAY is wrong and the "Graphics support" menu should not depend on HAS_IOMEM in the first place. That said, until the "Graphics support" dependency gets fixed or the S390 commit gets reverted completely (I don't know if that's an option), I think it's probably better to keep my commit to fix the warning -- without my patch series to enable USB on UML _all_ USB options have an implicit (and incorrect) dependency on HAS_IOMEM. Does that seem fair to you? Vegard -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] usb: core: Allow compilation on platforms where NO_DMA=y
On 02/15/2016 09:38 PM, Vegard Nossum wrote: On 02/15/2016 01:28 PM, Geert Uytterhoeven wrote: On Mon, Feb 15, 2016 at 12:49 PM, Vegard Nossum wrote: On 02/15/2016 12:21 PM, Geert Uytterhoeven wrote: [...] Assuming this still lets the platform actually run USB drivers (which it looks like it does -- I still have to test it), then I'm all for it. You Please give it a try and let me know, as I'm not in a position to test-run this on Sun-3. Hrm, I can't quite get usb-over-ip working, I get this in the UML guest when trying to attach the host device: [...] That said, I haven't tried if it works with my patches either, so it might be something else. Ok, so I managed to get UML to read a USB flash drive plugged into the host machine using USB-over-IP: mconsole (version 2) initialized on /home/vegard/.uml/eaqEV4/mconsole Checking host MADV_REMOVE support...OK UML Audio Relay (host dsp = /dev/sound/dsp, host mixer = /dev/sound/mixer) [...] vhci_hcd vhci_hcd: rhport(0) sockfd(3) devid(65538) speed(3) speed_str(high-speed) usb 2-1: new high-speed USB device number 2 using vhci_hcd usb 2-1: new high-speed USB device number 3 using vhci_hcd usb 2-1: new high-speed USB device number 4 using vhci_hcd usb 2-1: SetAddress Request (4) to port 0 usb 2-1: New USB device found, idVendor=, idProduct= usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 2-1: Product: USB usb 2-1: Manufacturer: SMI Corporation usb 2-1: SerialNumber: AA62708490100298 usb-storage 2-1:1.0: USB Mass Storage device detected scsi host0: usb-storage 2-1:1.0 scsi 0:0:0:0: Direct-Access ST 2GB PQ: 0 ANSI: 0 CCS sd 0:0:0:0: Attached scsi generic sg0 type 0 sd 0:0:0:0: [sda] 3915776 512-byte logical blocks: (2.00 GB/1.87 GiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00 sd 0:0:0:0: [sda] No Caching mode page found sd 0:0:0:0: [sda] Assuming drive cache: write through sda: sda1 sd 0:0:0:0: [sda] Attached SCSI removable disk This is using your patches (on top of the ones Greg already took), so feel free to add Acked-by: Vegard Nossum If you post the new version of your patch I can test that too :-) Thanks, Vegard -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] usb: gadget: pxa25x_udc: use readl/writel for mmio
Arnd Bergmann writes: > Both writes leave the CPU core within the spinlock but are not serialized > with anything else, so there is no ordering between the CPUs when they > enter the shared bus, other than having address before data. You'd > expect to see address0, data0, address1, data1, but it could also > be e.g. address0, address1, data1, data0. Ah, so it's a matter of flushing the write buffers before exiting the spinlock-protected code. > The point is more what the common case is. Almost all machines we support > have fixed-endian devices, and the drivers are correct when using readl() > or in_le32() but are not endian-safe when using __raw_readl(). Sure, e.g. PCI does it this way (eventually swapping the data lanes if needed). > Using __raw_readl() has the big danger of someone accidentally "fixing" > the driver to work like all the others in order to solve a theoretical > endian problem, while it should really be made obvious that the hardware > actively swaps its data on the bus. Sure - if this is the case. On-chip IXP4xx peripherals don't swap data at all (i.e., they match CPU endianess) - accessing their registers is like accessing a normal CPU register. That's why they don't use PCI-style readl() etc. - however a better name than __raw_* would probably help here. Using __raw_* in a PCI driver would be generally wrong. -- Krzysztof Halasa Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface
On Tue, 2016-02-16 at 11:22 +0200, Heikki Krogerus wrote: > > That question has not been answered. It would be awkward for the OS > > to find itself in the slave role, which it is ill equipped for. So > > the data role should be switched before the new device is announced > > to user space. How is that handled? > > In the class driver, once we add support for preselecting the role, > when the connection happens we compare the initial role to the > preselected one and execute swap if it differs. Only after that we > notify userspace. Yes, but we need an API. We can't keep adding to it. So if that is to be supported, it needs to be defined now. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] usb: gadget: pxa25x_udc: use readl/writel for mmio
On Tuesday 16 February 2016 14:24:10 Krzysztof Hałasa wrote: > Arnd Bergmann writes: > > > Both writes leave the CPU core within the spinlock but are not serialized > > with anything else, so there is no ordering between the CPUs when they > > enter the shared bus, other than having address before data. You'd > > expect to see address0, data0, address1, data1, but it could also > > be e.g. address0, address1, data1, data0. > > Ah, so it's a matter of flushing the write buffers before exiting the > spinlock-protected code. Yes, whatever the specific architecture requires. The normal readl() functions are documented to having all the required barriers and flushes, the __raw_* variants may (e.g. on x86) or may not have that. > > The point is more what the common case is. Almost all machines we support > > have fixed-endian devices, and the drivers are correct when using readl() > > or in_le32() but are not endian-safe when using __raw_readl(). > > Sure, e.g. PCI does it this way (eventually swapping the data lanes if > needed). > > > Using __raw_readl() has the big danger of someone accidentally "fixing" > > the driver to work like all the others in order to solve a theoretical > > endian problem, while it should really be made obvious that the hardware > > actively swaps its data on the bus. > > Sure - if this is the case. On-chip IXP4xx peripherals don't swap data > at all (i.e., they match CPU endianess) - accessing their registers is > like accessing a normal CPU register. That's why they don't use > PCI-style readl() etc. - however a better name than __raw_* would > probably help here. > > Using __raw_* in a PCI driver would be generally wrong. I was really talking about built-in devices here. There are other platforms that have an internal byteswap logic on the bus interface and they also use that for PCI, see e.g. arch/sh/include/mach-common/mach/mangle-port.h. ixp4xx is really special in that it performs hardware swapping for internal devices based on CPU endianess but not on PCI devices. I think some Broadcom MIPS systems are in the same category as IXP4xx, but only because they have an extra byteswap on the PCI bus that they can turn on, but very few other systems are. Coming back to the specific pxa25x_udc case: using __raw_* accessors in the driver would possibly end up breaking the PXA25x machines in the (very unlikely) case that someone wants to make it work with big-endian kernels, assuming it does not have the same hardware byteswap logic as ixp4xx. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 02/10] usb: dbc: probe and setup xhci debug capability
Hi
Most of my concerns are due to the early printk restrictions.
As you say in the documentation:
"Keep in mind that things such as interrupt, system memory, DMA memory,
PCI configure space access, etc., are all different from a normal device
driver."
I don't know the details of these subsystems, or if what is done here is
done the "right" way.
DMA capable memory is allocated with static char xpage[PAGE_SIZE] __aligned,
and DMA address is found using __pa()
xdbc_map_pci_mmio() does some pci magic and fixmapping that I don't know the
details of.
writing to ioport 0x80 outb(1, 0x80) is used as 1us delay, sometimes up to
5 million times to get a 5 second timeout
Adding Bjorn Helgaas and Dan Williams in case they have an opinoin about
the DMA and PCI cases.
more comments inline
On 26.01.2016 14:58, Lu Baolu wrote:
xHCI debug capability (DbC) is an optional functionality provided
by an xHCI host controller. Software learns this capability by
walking through the extended capability list in mmio of the host.
This patch introduces the code to probe and initialize the debug
capability hardware during early boot. With hardware initialization
done, the debug target (system under debug which has DbC enabled)
will present a debug device through the debug port. The debug device
is fully compliant with the USB framework and provides the equivalent
of a very high performance (USB3) full-duplex serial link between the
debug host and target.
Signed-off-by: Lu Baolu
---
MAINTAINERS | 7 +
arch/x86/Kconfig.debug | 12 +
drivers/usb/early/Makefile | 1 +
drivers/usb/early/xhci-dbc.c | 774 +++
include/linux/usb/xhci-dbc.h | 187 +++
5 files changed, 981 insertions(+)
create mode 100644 drivers/usb/early/xhci-dbc.c
create mode 100644 include/linux/usb/xhci-dbc.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 30aca4a..e6d7076 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11505,6 +11505,13 @@ S: Supported
F:drivers/usb/host/xhci*
F:drivers/usb/host/pci-quirks*
+USB XHCI DEBUG PORT
+M: Lu Baolu
+L: linux-usb@vger.kernel.org
+S: Supported
+F: drivers/usb/early/xhci-dbc.c
+F: include/linux/usb/xhci-dbc.h
+
USB ZD1201 DRIVER
L:linux-wirel...@vger.kernel.org
W:http://linux-lc100020.sourceforge.net
diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index 9b18ed9..ba60cb1 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -48,6 +48,18 @@ config EARLY_PRINTK_EFI
This is useful for kernel debugging when your machine crashes very
early before the console code is initialized.
+config EARLY_PRINTK_XDBC
+ bool "Early printk via xHCI debug port"
+ depends on EARLY_PRINTK && PCI
+ ---help---
+ Write kernel log output directly into the xHCI debug port.
+
+ This is useful for kernel debugging when your machine crashes very
+ early before the console code is initialized. For normal operation
+ it is not recommended because it looks ugly and doesn't cooperate
+ with klogd/syslogd or the X server. You should normally N here,
+ unless you want to debug such a crash.
+
config X86_PTDUMP_CORE
def_bool n
diff --git a/drivers/usb/early/Makefile b/drivers/usb/early/Makefile
index 24bbe51..2db5906 100644
--- a/drivers/usb/early/Makefile
+++ b/drivers/usb/early/Makefile
@@ -3,3 +3,4 @@
#
obj-$(CONFIG_EARLY_PRINTK_DBGP) += ehci-dbgp.o
+obj-$(CONFIG_EARLY_PRINTK_XDBC) += xhci-dbc.o
diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
new file mode 100644
index 000..254a0a8
--- /dev/null
+++ b/drivers/usb/early/xhci-dbc.c
@@ -0,0 +1,774 @@
+/**
+ * xhci-dbc.c - xHCI debug capability driver
+ *
+ * Copyright (C) 2015 Intel Corporation
+ *
+ * Author: Lu Baolu
+ * Some code shared with EHCI debug port and xHCI driver.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../host/xhci.h"
+
+#defineXDBC_PROTOCOL 1 /* GNU Remote Debug Command Set
*/
+#defineXDBC_VENDOR_ID 0x1d6b /* Linux Foundation 0x1d6b */
+#defineXDBC_PRODUCT_ID 0x0004 /* __le16 idProduct; device
0004 */
+#defineXDBC_DEVICE_REV 0x0010 /* 0.10 */
+
+static struct xdbc_state xdbc_stat;
+static struct xdbc_state *xdbcp = &xdbc_stat;
+
...
+
+#else
+static inline void xdbc_trace(const char *fmt, ...) { }
+static inline void xdbc_dbg_dump_regs(char *str) { }
+static inline void xdbc_dbg_dump_data(char *str) { }
+#endif /* DBC_DEBUG */
+
+/*
+ * FIXME: kernel provided delay interfaces, like usleep, isn't ready yet
+ *at the time DbC gets initial
Re: [PATCH] usb: dwc3: Fix assignment of EP transfer resources
Hi, John Youn writes: > On 2/12/2016 2:05 AM, Felipe Balbi wrote: >> >> Hi, >> >> John Youn writes: >>> On 2/10/2016 1:07 PM, Felipe Balbi wrote: John Youn writes: >>> Basically assign all the resources in advance. >> >> I thought about that, but wouldn't this, essentially, enable all >> endpoints unconditionally ? This could, potentially, increase power >> consumption on some systems, right ? This could also cause "spurious" >> interrupts if a bogus host tries to move data on an endpoint which >> hasn't been enabled yet. > > No, I mean to just assign resources withouth configuring or enabling > the endpoint. I have tested this approach and it works. But I still oh ok. > need to verify that it won't conflict with anything, such as streams. yeah, we would probably have an issue with streams. IIRC, we allocate one transfer resource per stream, right ? >>> >>> Ends up that is not a concern. Streams always use a single resource >>> per endpoint, not stream. >> >> hey, that's great. So what's the idea ? static resource assignment on >> endpoint initialization ? >> > > Yes that's it. I will go ahead and submit this fix. See the commit > message for details. I verified with engineers and did a round of > testing and so far no problems. > > If you prefer to only assign resources as needed, I have a separate > fix that I can submit if you want. > > Also, I think we need to handle backporting separately as neither > patch applies cleanly to 4.3. when backporting, we will receive emails that Greg couldn't apply. All we have to do is reply with the proper backport ;-) -- balbi signature.asc Description: PGP signature
[PATCH v2 0/3] usb: Allow compilation on platforms where NO_DMA=y
Hi Greg,
Some platforms don't have DMA, but we should still be able to build USB
drivers for these platforms. They could still be used through vhci_hcd,
usbip_host, or maybe something like USB passthrough in UML from a
capable host.
This patch series allows to compile USB on platforms where NO_DMA=y.
I've been using it for quite a while to make allmodconfig/allyesconfig
build for m68k/sun3.
Vegard used this on UML to read a USB flash drive plugged into the host
machine using USB-over-IP.
Changes compared to v1:
- Replace remaining #ifdefs by IS_ENABLED() checks,
- Add to patch description that this actually allows using USB on UML,
- Add Acked-by.
Thanks!
Geert Uytterhoeven (3):
usb: core: Allow compilation on platforms where NO_DMA=y
usb: host: Host drivers relying on DMA should depend on HAS_DMA
usb: dwc2: USB_DWC2 should depend on HAS_DMA
drivers/usb/core/buffer.c | 18 --
drivers/usb/core/hcd.c| 16 ++--
drivers/usb/dwc2/Kconfig | 1 +
drivers/usb/host/Kconfig | 5 -
4 files changed, 27 insertions(+), 13 deletions(-)
--
1.9.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] usb: core: Allow compilation on platforms where NO_DMA=y
Some platforms don't have DMA, but we should still be able to build USB
drivers for these platforms. They could still be used through vhci_hcd,
usbip_host, or maybe something like USB passthrough in UML from a
capable host.
If NO_DMA=y:
ERROR: "dma_pool_destroy" [drivers/usb/core/usbcore.ko] undefined!
ERROR: "bad_dma_ops" [drivers/usb/core/usbcore.ko] undefined!
ERROR: "dma_pool_free" [drivers/usb/core/usbcore.ko] undefined!
ERROR: "dma_pool_alloc" [drivers/usb/core/usbcore.ko] undefined!
ERROR: "dma_pool_create" [drivers/usb/core/usbcore.ko] undefined!
Add a few checks for CONFIG_HAS_DMA to fix this.
Signed-off-by: Geert Uytterhoeven
Acked-by: Vegard Nossum
---
v2:
- Replace remaining #ifdefs by IS_ENABLED() checks,
- Add to patch description that this actually allows using USB on UML,
- Add Acked-by.
---
drivers/usb/core/buffer.c | 18 --
drivers/usb/core/hcd.c| 16 ++--
2 files changed, 22 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/core/buffer.c b/drivers/usb/core/buffer.c
index 89f2e7765093955b..2741566ee4f25849 100644
--- a/drivers/usb/core/buffer.c
+++ b/drivers/usb/core/buffer.c
@@ -62,8 +62,9 @@ int hcd_buffer_create(struct usb_hcd *hcd)
charname[16];
int i, size;
- if (!hcd->self.controller->dma_mask &&
- !(hcd->driver->flags & HCD_LOCAL_MEM))
+ if (!IS_ENABLED(CONFIG_HAS_DMA) ||
+ (!hcd->self.controller->dma_mask &&
+!(hcd->driver->flags & HCD_LOCAL_MEM)))
return 0;
for (i = 0; i < HCD_BUFFER_POOLS; i++) {
@@ -93,6 +94,9 @@ void hcd_buffer_destroy(struct usb_hcd *hcd)
{
int i;
+ if (!IS_ENABLED(CONFIG_HAS_DMA))
+ return;
+
for (i = 0; i < HCD_BUFFER_POOLS; i++) {
struct dma_pool *pool = hcd->pool[i];
@@ -119,8 +123,9 @@ void *hcd_buffer_alloc(
int i;
/* some USB hosts just use PIO */
- if (!bus->controller->dma_mask &&
- !(hcd->driver->flags & HCD_LOCAL_MEM)) {
+ if (!IS_ENABLED(CONFIG_HAS_DMA) ||
+ (!bus->controller->dma_mask &&
+!(hcd->driver->flags & HCD_LOCAL_MEM))) {
*dma = ~(dma_addr_t) 0;
return kmalloc(size, mem_flags);
}
@@ -145,8 +150,9 @@ void hcd_buffer_free(
if (!addr)
return;
- if (!bus->controller->dma_mask &&
- !(hcd->driver->flags & HCD_LOCAL_MEM)) {
+ if (!IS_ENABLED(CONFIG_HAS_DMA) ||
+ (!bus->controller->dma_mask &&
+!(hcd->driver->flags & HCD_LOCAL_MEM))) {
kfree(addr);
return;
}
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index df0e3b92533a745f..b277977cada2b382 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1408,7 +1408,8 @@ static void hcd_free_coherent(struct usb_bus *bus,
dma_addr_t *dma_handle,
void usb_hcd_unmap_urb_setup_for_dma(struct usb_hcd *hcd, struct urb *urb)
{
- if (urb->transfer_flags & URB_SETUP_MAP_SINGLE)
+ if (IS_ENABLED(CONFIG_HAS_DMA) &&
+ (urb->transfer_flags & URB_SETUP_MAP_SINGLE))
dma_unmap_single(hcd->self.controller,
urb->setup_dma,
sizeof(struct usb_ctrlrequest),
@@ -1440,17 +1441,20 @@ void usb_hcd_unmap_urb_for_dma(struct usb_hcd *hcd,
struct urb *urb)
usb_hcd_unmap_urb_setup_for_dma(hcd, urb);
dir = usb_urb_dir_in(urb) ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
- if (urb->transfer_flags & URB_DMA_MAP_SG)
+ if (IS_ENABLED(CONFIG_HAS_DMA) &&
+ (urb->transfer_flags & URB_DMA_MAP_SG))
dma_unmap_sg(hcd->self.controller,
urb->sg,
urb->num_sgs,
dir);
- else if (urb->transfer_flags & URB_DMA_MAP_PAGE)
+ else if (IS_ENABLED(CONFIG_HAS_DMA) &&
+(urb->transfer_flags & URB_DMA_MAP_PAGE))
dma_unmap_page(hcd->self.controller,
urb->transfer_dma,
urb->transfer_buffer_length,
dir);
- else if (urb->transfer_flags & URB_DMA_MAP_SINGLE)
+ else if (IS_ENABLED(CONFIG_HAS_DMA) &&
+(urb->transfer_flags & URB_DMA_MAP_SINGLE))
dma_unmap_single(hcd->self.controller,
urb->transfer_dma,
urb->transfer_buffer_length,
@@ -1492,7 +1496,7 @@ int usb_hcd_map_urb_for_dma(struct usb_hcd *hcd, struct
urb *urb,
if (usb_endpoint_xfer_control(&urb->ep->desc)) {
if (hcd->self.uses_pio_for_control)
return ret;
- if (hcd->self.uses_dma) {
+ if (IS_ENABLED(CONFIG_HAS_DMA) && hcd->self.uses_dma) {
[PATCH v2 2/3] usb: host: Host drivers relying on DMA should depend on HAS_DMA
If NO_DMA=y: ERROR: "bad_dma_ops" [drivers/usb/host/xhci-plat-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/xhci-mtk.ko] undefined! ERROR: "dma_pool_destroy" [drivers/usb/host/xhci-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/xhci-hcd.ko] undefined! ERROR: "dma_pool_free" [drivers/usb/host/xhci-hcd.ko] undefined! ERROR: "dma_pool_alloc" [drivers/usb/host/xhci-hcd.ko] undefined! ERROR: "dma_pool_create" [drivers/usb/host/xhci-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/ohci-platform.ko] undefined! ERROR: "dma_pool_destroy" [drivers/usb/host/ohci-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/ohci-hcd.ko] undefined! ERROR: "dma_pool_free" [drivers/usb/host/ohci-hcd.ko] undefined! ERROR: "dma_pool_alloc" [drivers/usb/host/ohci-hcd.ko] undefined! ERROR: "dma_pool_create" [drivers/usb/host/ohci-hcd.ko] undefined! ERROR: "dma_pool_create" [drivers/usb/host/fotg210-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/fotg210-hcd.ko] undefined! ERROR: "dma_pool_destroy" [drivers/usb/host/fotg210-hcd.ko] undefined! ERROR: "dma_pool_alloc" [drivers/usb/host/fotg210-hcd.ko] undefined! ERROR: "dma_pool_free" [drivers/usb/host/fotg210-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/ehci-platform.ko] undefined! ERROR: "dma_pool_destroy" [drivers/usb/host/ehci-hcd.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/host/ehci-hcd.ko] undefined! ERROR: "dma_pool_free" [drivers/usb/host/ehci-hcd.ko] undefined! ERROR: "dma_pool_alloc" [drivers/usb/host/ehci-hcd.ko] undefined! ERROR: "dma_pool_create" [drivers/usb/host/ehci-hcd.ko] undefined! Add dependencies on HAS_DMA to fix this. Signed-off-by: Geert Uytterhoeven --- v2: - Reword one-line summary. --- drivers/usb/host/Kconfig | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 1f117c360ebbba33..573789698474ad8d 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -17,6 +17,7 @@ config USB_C67X00_HCD config USB_XHCI_HCD tristate "xHCI HCD (USB 3.0) support" + depends on HAS_DMA ---help--- The eXtensible Host Controller Interface (xHCI) is standard for USB 3.0 "SuperSpeed" host controller hardware. @@ -70,6 +71,7 @@ endif # USB_XHCI_HCD config USB_EHCI_HCD tristate "EHCI HCD (USB 2.0) support" + depends on HAS_DMA ---help--- The Enhanced Host Controller Interface (EHCI) is standard for USB 2.0 "high speed" (480 Mbit/sec, 60 Mbyte/sec) host controller hardware. @@ -361,7 +363,7 @@ config USB_ISP1362_HCD config USB_FOTG210_HCD tristate "FOTG210 HCD support" - depends on USB + depends on USB && HAS_DMA ---help--- Faraday FOTG210 is an OTG controller which can be configured as an USB2.0 host. It is designed to meet USB2.0 EHCI specification @@ -383,6 +385,7 @@ config USB_MAX3421_HCD config USB_OHCI_HCD tristate "OHCI HCD (USB 1.1) support" + depends on HAS_DMA ---help--- The Open Host Controller Interface (OHCI) is a standard for accessing USB 1.1 host controller hardware. It does more in hardware than Intel's -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] usb: dwc2: USB_DWC2 should depend on HAS_DMA
If NO_DMA=y: ERROR: "usb_gadget_map_request" [drivers/usb/dwc2/dwc2.ko] undefined! ERROR: "usb_gadget_unmap_request" [drivers/usb/dwc2/dwc2.ko] undefined! ERROR: "bad_dma_ops" [drivers/usb/dwc2/dwc2.ko] undefined! Add a dependency on HAS_DMA to fix this. Signed-off-by: Geert Uytterhoeven Acked-by: John Youn --- v2: - Add Acked-by. --- drivers/usb/dwc2/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/dwc2/Kconfig b/drivers/usb/dwc2/Kconfig index fd95ba6ec317fdac..f0decc0d69b5197d 100644 --- a/drivers/usb/dwc2/Kconfig +++ b/drivers/usb/dwc2/Kconfig @@ -1,5 +1,6 @@ config USB_DWC2 tristate "DesignWare USB2 DRD Core Support" + depends on HAS_DMA depends on USB || USB_GADGET help Say Y here if your system has a Dual Role Hi-Speed USB -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: commit 4b61b4f205eabfc9f863f805858aa5b32deb3de5 - usb: add HAS_IOMEM dependency to USB_APPLEDISPLAY
On Tue, 2016-02-16 at 13:12 +0100, Vegard Nossum wrote: > Alright, let's have a look. The warning I was fixing in this patch > was: > > warning: (USB_APPLEDISPLAY) selects BACKLIGHT_LCD_SUPPORT which > has > unmet direct dependencies (HAS_IOMEM) > > The problem is that USB_APPLEDISPLAY has 'select > BACKLIGHT_LCD_SUPPORT', > but BACKLIGHT_LCD_SUPPORT has a dependency on HAS_IOMEM: > > menu "Graphics support" > depends on HAS_IOMEM It seems to me that this particular dependency is clearly wrong. Even an S390 can use USB graphics devices. That suggests an outright reversion of this particular change. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] dt/bindings: Add binding for the DA8xx MUSB driver
Hello Rob, is there any follow-up on this one? Thanks Petr On 12.02.2016 18:24, Petr Kulhavy wrote: On 12.02.2016 17:21, Rob Herring wrote: On Thu, Feb 11, 2016 at 12:01:06PM +0100, Petr Kulhavy wrote: + - mentor,power : Specifies the maximum current in milliamperes the controller can + supply in host mode. Still a no for me. Looks like this just sets hcd->power_budget. This property may not be a regulator, but ultimately the value depends on some regulator supplying Vbus. Also, given this has nothing to do with MUSB h/w, however this is described should be generic. I understand your point that the description should be generic. However the USB 2.0 specification does not define any relation between the bMaxPower provided by the device and the actual power control. As far as I understand the value just serves the purpose to raise a flag to the user if the attached device would draw too much power, and not to enable it at all. Further, the value used by the protocol is not necessarily related to the real current that can be supported. The maximum current supported by the protocol is 510mA. For instance on my development board the real maximum current is limited only by the mains power-supply used. So it cannot even be modelled in the DT as a regulator because the power-supply is not part of the HW and everybody can take a different one. So defining a regulator just to store this arbitrary USB 2.0 value is a bit overkill for me. Regards Petr -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Minor xhci issues (failed to peer) on Dell XPS 13 9350 (Skylake)
I get some warnings at boot on all kernels I've tried. On 4.5-rc4, I see: [0.229429] usbcore: registered new interface driver usbfs [0.229436] usbcore: registered new interface driver hub [0.229451] usbcore: registered new device driver usb [1.057998] xhci_hcd :00:14.0: xHCI Host Controller [1.058640] xhci_hcd :00:14.0: new USB bus registered, assigned bus number 1 [1.059811] xhci_hcd :00:14.0: hcc params 0x200077c1 hci version 0x100 quirks 0x00109810 [1.059818] xhci_hcd :00:14.0: cache line size of 64 is not supported [1.059821] xhci_hcd :00:14.0: supports USB remote wakeup [1.060480] usb usb1: default language 0x0409 [1.060584] usb usb1: udev 1, busnum 1, minor = 0 [1.060587] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [1.060589] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.060590] usb usb1: Product: xHCI Host Controller [1.060592] usb usb1: Manufacturer: Linux 4.5.0-rc4-acpi+ xhci-hcd [1.060593] usb usb1: SerialNumber: :00:14.0 [1.060845] usb usb1: usb_probe_device [1.060848] usb usb1: configuration #1 chosen from 1 choice [1.060914] usb usb1: adding 1-0:1.0 (config #1, interface 0) [1.060937] hub 1-0:1.0: usb_probe_interface [1.060939] hub 1-0:1.0: usb_probe_interface - got id [1.060941] hub 1-0:1.0: USB hub found [1.061028] hub 1-0:1.0: 12 ports detected [1.061030] hub 1-0:1.0: standalone hub [1.061031] hub 1-0:1.0: no power switching (usb 1.0) [1.061032] hub 1-0:1.0: individual port over-current protection [1.061034] hub 1-0:1.0: Single TT [1.061035] hub 1-0:1.0: TT requires at most 8 FS bit times (666 ns) [1.061036] hub 1-0:1.0: power on to power good time: 20ms [1.061109] hub 1-0:1.0: local power source is good [1.084337] usb usb1-port3: DeviceRemovable is changed to 1 according to platform information. [1.084339] usb usb1-port4: DeviceRemovable is changed to 1 according to platform information. [1.084341] usb usb1-port5: DeviceRemovable is changed to 1 according to platform information. [1.084343] hub 1-0:1.0: trying to enable port power on non-switchable hub [1.084438] xhci_hcd :00:14.0: xHCI Host Controller [1.084624] xhci_hcd :00:14.0: new USB bus registered, assigned bus number 2 [1.084628] xhci_hcd :00:14.0: supports USB remote wakeup [1.084671] usb usb2: skipped 1 descriptor after endpoint [1.084679] usb usb2: default language 0x0409 [1.084691] usb usb2: udev 1, busnum 2, minor = 128 [1.084693] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003 [1.084694] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.084695] usb usb2: Product: xHCI Host Controller [1.084697] usb usb2: Manufacturer: Linux 4.5.0-rc4-acpi+ xhci-hcd [1.084698] usb usb2: SerialNumber: :00:14.0 [1.084909] usb usb2: usb_probe_device [1.084914] usb usb2: configuration #1 chosen from 1 choice [1.084926] usb usb2: adding 2-0:1.0 (config #1, interface 0) [1.084948] hub 2-0:1.0: usb_probe_interface [1.084949] hub 2-0:1.0: usb_probe_interface - got id [1.084952] hub 2-0:1.0: USB hub found [1.084966] hub 2-0:1.0: 6 ports detected [1.084968] hub 2-0:1.0: standalone hub [1.084969] hub 2-0:1.0: no power switching (usb 1.0) [1.084971] hub 2-0:1.0: individual port over-current protection [1.084972] hub 2-0:1.0: TT requires at most 8 FS bit times (666 ns) [1.084973] hub 2-0:1.0: power on to power good time: 20ms [1.084978] hub 2-0:1.0: local power source is good [1.085684] usb usb2-port1: peered to usb1-port1 [1.086356] usb usb2-port2: peered to usb1-port2 [1.087004] usb usb2-port3: peered to usb1-port6 [1.087713] usb: failed to peer usb2-port4 and usb1-port6 by location (usb2-port4:none) (usb1-port6:usb2-port3) [1.087715] usb usb2-port4: failed to peer to usb1-port6 (-16) [1.087716] usb: port power management may be unreliable [1.088377] usb: failed to peer usb2-port5 and usb1-port6 by location (usb2-port5:none) (usb1-port6:usb2-port3) [1.088379] usb usb2-port5: failed to peer to usb1-port6 (-16) [1.089017] usb: failed to peer usb2-port6 and usb1-port6 by location (usb2-port6:none) (usb1-port6:usb2-port3) [1.089018] usb usb2-port6: failed to peer to usb1-port6 (-16) [1.089028] hub 2-0:1.0: trying to enable port power on non-switchable hub [1.089164] usbcore: registered new interface driver usbserial [1.089170] usbcore: registered new interface driver usbserial_generic [1.089195] usbserial: USB Serial support registered for generic [1.097055] usbcore: registered new interface driver usbhid [1.097056] usbhid: USB HID core driver [1.184226] usb usb1-port3: status 0101 change 0001 [1.184241] usb usb1-port5: status 0101 change 0001 [1.284270] hub 1-0:1.0: state 7 ports 12 chg 0028 evt [1.284302] usb usb1-port3: status 0101,
Re: [PATCH] documentation: add kernel-dot.emacs.txt
Hello,
2016-02-16 15:10 GMT-03:00 Tiago Natel de Moura :
> Hello folks,
>
> The patch have some problem with the c-mode-hook setup, in the usage of
> c-cleanup-list. On my emacs24 it throw the following error:
>
> "Invalid indentation setting for symbol c-cleanup-list"
>
> After talk with Geyslan, he found the problem and pointed out a solution,
> then everything worked as expected.
Thank you Natel, I'm sending a v2 for this with your review.
>
>
> Thanks!
>
> This patch adds kernel-dot-emacs.txt (elisp) which deliver best
> indentation, comments and white space highlighting functionalities.
>
> This also changes the CodingStyle and 00-INDEX files by referencing
> the new kernel-dot-emacs.
>
> Signed-off-by: Geyslan G. Bem
> ---
>
> Notes:
> This patch was done by suggestion of Jonathan Corbet:
> http://thread.gmane.org/gmane.linux.documentation/35265/focus=35309
>
> Documentation/00-INDEX | 2 +
> Documentation/CodingStyle | 38 +
> Documentation/kernel-dot-emacs.txt | 285
> +
> 3 files changed, 291 insertions(+), 34 deletions(-)
> create mode 100644 Documentation/kernel-dot-emacs.txt
>
> diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
> index cd077ca..d4c48f5 100644
> --- a/Documentation/00-INDEX
> +++ b/Documentation/00-INDEX
> @@ -259,6 +259,8 @@ kernel-doc-nano-HOWTO.txt
> - mini HowTo on generation and location of kernel documentation files.
> kernel-docs.txt
> - listing of various WWW + books that document kernel internals.
> +kernel-dot-emacs.txt
> + - emacs dot file for kernel coding style.
> kernel-parameters.txt
> - summary listing of command line / boot prompt args for the kernel.
> kernel-per-CPU-kthreads.txt
> diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
> index c06f817..4d64b58 100644
> --- a/Documentation/CodingStyle
> +++ b/Documentation/CodingStyle
> @@ -501,40 +501,10 @@ typing - an infinite number of monkeys typing into GNU
> emacs would never
> make a good program).
>
> So, you can either get rid of GNU emacs, or change it to use saner
> -values. To do the latter, you can stick the following in your .emacs file:
> -
> -(defun c-lineup-arglist-tabs-only (ignored)
> - "Line up argument lists by tabs, not spaces"
> - (let* ((anchor (c-langelem-pos c-syntactic-element))
> - (column (c-langelem-2nd-pos c-syntactic-element))
> - (offset (- (1+ column) anchor))
> - (steps (floor offset c-basic-offset)))
> -(* (max steps 1)
> - c-basic-offset)))
> -
> -(add-hook 'c-mode-common-hook
> - (lambda ()
> -;; Add kernel style
> -(c-add-style
> - "linux-tabs-only"
> - '("linux" (c-offsets-alist
> -(arglist-cont-nonempty
> - c-lineup-gcc-asm-reg
> - c-lineup-arglist-tabs-only))
> -
> -(add-hook 'c-mode-hook
> - (lambda ()
> -(let ((filename (buffer-file-name)))
> - ;; Enable kernel mode for the appropriate files
> - (when (and filename
> - (string-match (expand-file-name "~/src/linux-trees")
> - filename))
> -(setq indent-tabs-mode t)
> -(setq show-trailing-whitespace t)
> -(c-set-style "linux-tabs-only")
> -
> -This will make emacs go better with the kernel coding style for C
> -files below ~/src/linux-trees.
> +values. To do the latter, you can stick the elisp code from
> +Documentation/kernel-dot-emacs.txt in your emacs init file. This will make
> +emacs go better with the kernel coding style for C files below
> +~/src/linux-trees.
>
> But even if you fail in getting emacs to do sane formatting, not
> everything is lost: use "indent".
> diff --git a/Documentation/kernel-dot-emacs.txt
> b/Documentation/kernel-dot-emacs.txt
> new file mode 100644
> index 000..b6d6816
> --- /dev/null
> +++ b/Documentation/kernel-dot-emacs.txt
> @@ -0,0 +1,285 @@
> +;; Kernel dot emacs
> +;; Based on the prior elisp from Documentantion/CodingStyle
> +;;
> +;; January, 2016
> +;; Geyslan G. Bem
> +
> +;; This elisp does use of emacs functionalities which deliver to the
> +;; user indentation, comments and white space highlighting.
> +;;
> +;; As known tabs are the higher law and the prior elisp code enforces
> +;; that law for any lineup indentation.
> +;;
> +;; However some trees have specific rules about line continuation
> +;; indentation. Even scripts/checkpatch.pl suggests the TABS+SPACES (lining
> up
> +;; under the open paren) for lineup the sequential lines.
> +;;
> +;; In addition to allowing the automatic setup by tree, this elisp can easily
> +;; be modified for new configurations. Eg.
> +;;
> +;; (when (or (string-match (concat source-path "/net") filename)
> +;; (string-match (concat source-path "/dri
[PATCH] documentation: add kernel-dot.emacs.txt
This patch adds kernel-dot-emacs.txt (elisp) which deliver best
indentation, comments and white space highlighting functionalities.
This also changes the CodingStyle and 00-INDEX files by referencing
the new kernel-dot-emacs.
Signed-off-by: Geyslan G. Bem
Reviewed-by: Tiago Natel de Moura
---
Notes:
This patch was done by suggestion of Jonathan Corbet:
http://thread.gmane.org/gmane.linux.documentation/35265/focus=35309
v2: fix c-cleanup-list scope
Documentation/00-INDEX | 2 +
Documentation/CodingStyle | 38 +
Documentation/kernel-dot-emacs.txt | 285 +
3 files changed, 291 insertions(+), 34 deletions(-)
create mode 100644 Documentation/kernel-dot-emacs.txt
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index cd077ca..d4c48f5 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -259,6 +259,8 @@ kernel-doc-nano-HOWTO.txt
- mini HowTo on generation and location of kernel documentation files.
kernel-docs.txt
- listing of various WWW + books that document kernel internals.
+kernel-dot-emacs.txt
+ - emacs dot file for kernel coding style.
kernel-parameters.txt
- summary listing of command line / boot prompt args for the kernel.
kernel-per-CPU-kthreads.txt
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index c06f817..4d64b58 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -501,40 +501,10 @@ typing - an infinite number of monkeys typing into GNU
emacs would never
make a good program).
So, you can either get rid of GNU emacs, or change it to use saner
-values. To do the latter, you can stick the following in your .emacs file:
-
-(defun c-lineup-arglist-tabs-only (ignored)
- "Line up argument lists by tabs, not spaces"
- (let* ((anchor (c-langelem-pos c-syntactic-element))
- (column (c-langelem-2nd-pos c-syntactic-element))
- (offset (- (1+ column) anchor))
- (steps (floor offset c-basic-offset)))
-(* (max steps 1)
- c-basic-offset)))
-
-(add-hook 'c-mode-common-hook
- (lambda ()
-;; Add kernel style
-(c-add-style
- "linux-tabs-only"
- '("linux" (c-offsets-alist
-(arglist-cont-nonempty
- c-lineup-gcc-asm-reg
- c-lineup-arglist-tabs-only))
-
-(add-hook 'c-mode-hook
- (lambda ()
-(let ((filename (buffer-file-name)))
- ;; Enable kernel mode for the appropriate files
- (when (and filename
- (string-match (expand-file-name "~/src/linux-trees")
- filename))
-(setq indent-tabs-mode t)
-(setq show-trailing-whitespace t)
-(c-set-style "linux-tabs-only")
-
-This will make emacs go better with the kernel coding style for C
-files below ~/src/linux-trees.
+values. To do the latter, you can stick the elisp code from
+Documentation/kernel-dot-emacs.txt in your emacs init file. This will make
+emacs go better with the kernel coding style for C files below
+~/src/linux-trees.
But even if you fail in getting emacs to do sane formatting, not
everything is lost: use "indent".
diff --git a/Documentation/kernel-dot-emacs.txt
b/Documentation/kernel-dot-emacs.txt
new file mode 100644
index 000..55b3090
--- /dev/null
+++ b/Documentation/kernel-dot-emacs.txt
@@ -0,0 +1,285 @@
+;; Kernel dot emacs
+;; Based on the prior elisp from Documentantion/CodingStyle
+;;
+;; January, 2016
+;; Geyslan G. Bem
+
+;; This elisp does use of emacs functionalities which deliver to the
+;; user indentation, comments and white space highlighting.
+;;
+;; As known tabs are the higher law and the prior elisp code enforces
+;; that law for any lineup indentation.
+;;
+;; However some trees have specific rules about line continuation
+;; indentation. Even scripts/checkpatch.pl suggests the TABS+SPACES (lining up
+;; under the open paren) for lineup the sequential lines.
+;;
+;; In addition to allowing the automatic setup by tree, this elisp can easily
+;; be modified for new configurations. Eg.
+;;
+;; (when (or (string-match (concat source-path "/net") filename)
+;; (string-match (concat source-path "/drivers/net")
filename))
+;; (setup-kernel-style 'extra-bottom-line t nil))
+;;
+;; The above model can be used for a new tree just changing the tree path
+;; and parameters of setup-kernel-style function.
+;;
+;; setup-kernel-style function sets the kernel-comment-style,
+;; kernel-lineup-tabs-only and kernel-lineup-maximum-tabs variables. They
+;; are used by the functions kernel-comment-dwim and kernel-lineup-arglist.
+;;
+;; The kernel-lineup-arglist function detects the maximum tabs allowed to
+;; lineup and if it must use tabs and spaces instead of only tabs.
+;;
+;; There are two cleanups
Re: [PATCH] usb: check for signals in chaoskey read function
Oliver Neukum writes: > why is this needed? You are doing this right after a > mutex_lock_interruptible(). When the device isn't contended, this mutex will never block and so mutex_lock_interruptible will never check for a signal. I had mistakenly assumed that usb_bulk_msg would abort when a signal was delivered, but it doesn't. I could be convinced that the driver should be using a different path through the USB stack that would allow a signal to wake up while waiting for the URB to complete, but this patch at least avoids needing to wait for a huge read to finish. The other option would be to eliminate the loop reading multiple URBs from the device, but that would reduce the available bandwidth from the device pretty considerably. -- -keith signature.asc Description: PGP signature
Re: [PATCH 1/5] dt/bindings: Add binding for the DA8xx MUSB driver
On Fri, Feb 12, 2016 at 11:26 AM, Sergei Shtylyov wrote: > Hello. > > > On 02/12/2016 07:21 PM, Rob Herring wrote: > >>> This adds DT support for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver. >>> >>> Signed-off-by: Petr Kulhavy >>> --- >>> .../devicetree/bindings/usb/da8xx-usb.txt | 47 >>> ++ >>> 1 file changed, 47 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/usb/da8xx-usb.txt >>> >>> diff --git a/Documentation/devicetree/bindings/usb/da8xx-usb.txt >>> b/Documentation/devicetree/bindings/usb/da8xx-usb.txt >>> new file mode 100644 >>> index 000..62dcc51 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/usb/da8xx-usb.txt >>> @@ -0,0 +1,47 @@ >>> +TI DA8xx MUSB >>> +~ >>> +For DA830 and DA850 platforms. >>> + >>> +Required properties: >>> + >>> + - compatible : Should be set to "ti,da830-musb". >>> + >>> + - reg: Offset and length of the USB controller register set. >>> + >>> + - interrupts: The USB interrupt number. >>> + >>> + - interrupt-names: Should be set to "mc". >>> + >>> + - dr_mode: The USB operation mode. Should be one of "host", >>> "peripheral" or "otg". >>> + >>> + - mentor,power : Specifies the maximum current in milliamperes the >>> controller can >>> + supply in host mode. >> >> >> Still a no for me. > > >Note that it's been used twice already, for musb_dsps.c and omap2430.c > glues (in the latter case the prop was called just "power"). The > corresponding field is a part of the 'struct musb_hdrc_platform_data'. Copied from platform_data is exactly what is wrong with this binding and you already said those were bad examples. >> Looks like this just sets hcd->power_budget. This >> property may not be a regulator, but ultimately the value depends on >> some regulator supplying Vbus. > > >Yes. > >> Also, given this has nothing to do with MUSB h/w, > > >This regulator is controlled by the DRVVBUS signal from MUSB h/w! How does a single signal control amount of current? What I should say is the max current has nothing to do with the MUSB controller. It is a property of some regulator. >> however this is described should be generic. > > >You mean just "power", w/o the vendor prefix? No. I mean generic in the sense of common for all USB host bindings, not generic as in a meaningless, unclear name. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] dt/bindings: Add binding for the DA8xx MUSB driver
On Fri, Feb 12, 2016 at 11:24 AM, Petr Kulhavy wrote: > > On 12.02.2016 17:21, Rob Herring wrote: >> >> On Thu, Feb 11, 2016 at 12:01:06PM +0100, Petr Kulhavy wrote: >>> >>> + - mentor,power : Specifies the maximum current in milliamperes the >>> controller can >>> + supply in host mode. >> >> Still a no for me. Looks like this just sets hcd->power_budget. This >> property may not be a regulator, but ultimately the value depends on >> some regulator supplying Vbus. Also, given this has nothing to do with >> MUSB h/w, however this is described should be generic. > > > I understand your point that the description should be generic. > However the USB 2.0 specification does not define any relation between the > bMaxPower provided by the device and the actual power control. > As far as I understand the value just serves the purpose to raise a flag to > the user if the attached device would draw too much power, and not to enable > it at all. That won't really work given devices lie. My bus powered USB disk enclosure reports something like 10mA. That's pretty good considering I have a 5W drive in it. > Further, the value used by the protocol is not necessarily related to the > real current that can be supported. The maximum current supported by the > protocol is 510mA. > > For instance on my development board the real maximum current is limited > only by the mains power-supply used. > So it cannot even be modelled in the DT as a regulator because the > power-supply is not part of the HW and > everybody can take a different one. Not part of which h/w? Different for everyone is exactly why Vbus supply should be described in DT. > So defining a regulator just to store this arbitrary USB 2.0 value is a bit > overkill for me. If it is just arbitrary, then put it into the driver. I would do 500mA and be done with it. I'd guess there is nothing real behind the current default of 250mA. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: dwc3: Fix assignment of EP transfer resources
Hi,
John Youn writes:
> The assignement of EP transfer resources was not handled properly in the
> dwc3 driver. Commit aebda6187181 ("usb: dwc3: Reset the transfer
> resource index on SET_INTERFACE") previously fixed one aspect of this
> where resources may be exhausted with multiple calls to SET_INTERFACE.
> However, it introduced an issue where composite devices with multiple
> interfaces can be assigned the same transfer resources for different
> endpoints. This patch solves both issues.
>
> The assignment of transfer resources cannot perfectly follow the data
> book due to the fact that the controller driver does not have all
> knowledge of the configuration in advance. It is given this information
> piecemeal by the composite gadget framework after every
> SET_CONFIGURATION and SET_INTERFACE. Trying to follow the databook
> programming model in this scenario can cause errors. For two reasons:
>
> 1) The databook says to do DEPSTARTCFG for every SET_CONFIGURATION and
> SET_INTERFACE (8.1.5). This is incorrect in the scenario of multiple
> interfaces.
>
> 2) The databook does not mention doing more DEPXFERCFG for new endpoint
> on alt setting (8.1.6).
>
> The following simplified method is used instead:
>
> All hardware endpoints can be assigned a transfer resource and this
> setting will stay persistent until either a core reset or hibernation.
> So whenever we do a DEPSTARTCFG(0) we can go ahead and do DEPXFERCFG for
> every hardware endpoint as well. We are guaranteed that there are as
> many transfer resources as endpoints.
>
> This patch triggers off of the calling dwc3_gadget_start_config() for
> EP0-out, which always happens first, and which should only happen in one
> of the above conditions.
very good commit log. Thank you :-)
> Fixes: aebda6187181 ("usb: dwc3: Reset the transfer resource index on
> SET_INTERFACE")
you missed:
Cc: # v
> Reported-by: Ravi Babu
> Signed-off-by: John Youn
> ---
>
> Hi Ravi,
>
> This is a simplified version of the previous patch. Could you verify
> that it works with your test scenario?
>
> Thanks,
> John
>
> v2:
> * Simplified assignment of resources by doing all endpoints at once.
>
>
> drivers/usb/dwc3/core.h | 1 -
> drivers/usb/dwc3/ep0.c| 5 -
> drivers/usb/dwc3/gadget.c | 38 --
> 3 files changed, 20 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index 2913068..e4f8b90 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -856,7 +856,6 @@ struct dwc3 {
> unsignedpullups_connected:1;
> unsignedresize_fifos:1;
> unsignedsetup_packet_pending:1;
> - unsignedstart_config_issued:1;
> unsignedthree_stage_setup:1;
> unsignedusb3_lpm_capable:1;
>
> diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
> index 3a9354a..8d6b75c 100644
> --- a/drivers/usb/dwc3/ep0.c
> +++ b/drivers/usb/dwc3/ep0.c
> @@ -555,7 +555,6 @@ static int dwc3_ep0_set_config(struct dwc3 *dwc, struct
> usb_ctrlrequest *ctrl)
> int ret;
> u32 reg;
>
> - dwc->start_config_issued = false;
> cfg = le16_to_cpu(ctrl->wValue);
>
> switch (state) {
> @@ -737,10 +736,6 @@ static int dwc3_ep0_std_request(struct dwc3 *dwc, struct
> usb_ctrlrequest *ctrl)
> dwc3_trace(trace_dwc3_ep0, "USB_REQ_SET_ISOCH_DELAY");
> ret = dwc3_ep0_set_isoch_delay(dwc, ctrl);
> break;
> - case USB_REQ_SET_INTERFACE:
> - dwc3_trace(trace_dwc3_ep0, "USB_REQ_SET_INTERFACE");
> - dwc->start_config_issued = false;
> - /* Fall through */
> default:
> dwc3_trace(trace_dwc3_ep0, "Forwarding to gadget driver");
> ret = dwc3_ep0_delegate_req(dwc, ctrl);
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 7d1dd82..ae2e546 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -385,24 +385,34 @@ static void dwc3_free_trb_pool(struct dwc3_ep *dep)
> dep->trb_pool_dma = 0;
> }
>
> +static int dwc3_gadget_set_xfer_resource(struct dwc3 *dwc, struct dwc3_ep
> *dep);
> +
> static int dwc3_gadget_start_config(struct dwc3 *dwc, struct dwc3_ep *dep)
> {
> struct dwc3_gadget_ep_cmd_params params;
> u32 cmd;
> + int i, ret;
I'd prefer if these two variables would be split into their own lines:
int ret;
int i;
> + if (dep->number)
> + return 0;
>
> memset(¶ms, 0x00, sizeof(params));
> + cmd = DWC3_DEPCMD_DEPSTARTCFG;
>
> - if (dep->number != 1) {
> - cmd = DWC3_DEPCMD_DEPSTARTCFG;
> - /* XferRscIdx == 0 for ep0 and 2 for the remaining */
> - if (dep->number > 1) {
> - if
Re: NEC uPD720200 xHCI Controller dies when Runtime PM enabled
On 2016-02-08 15:31, Mathias Nyman wrote: > Hi > > On 06.02.2016 19:08, Mike Murdoch wrote: >> Bug ID: 111251 >> >> Hello, >> >> I have a NEC uPD720200 USB3.0 controller in a Thinkpad W520 laptop on >> kernel 4.4.1-gentoo. >> >> 0e:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host >> Controller (rev 04) (prog-if 30 [XHCI]) >> Subsystem: Lenovo uPD720200 USB 3.0 Host Controller >> >> When runtime power control for this controller is disabled >> (/sys/bus/pci/devices/:0e:00.0/power/control = on), the controller >> works fine and reaches over 120MB/s transfer rates. >> >> When runtime power control for this controller is enabled >> (/sys/bus/pci/devices/:0e:00.0/power/control = auto), two effects >> can be observed: >> >> - Transfer rates are much lower at around 30MB/s >> - During transfers, the controller dies after a couple of seconds: >> >> xhci_hcd :0e:00.0: xHCI host not responding to stop endpoint >> command. >> xhci_hcd :0e:00.0: Assuming host is dying, halting host. >> xhci_hcd :0e:00.0: Host not halted after 16000 microseconds. >> xhci_hcd :0e:00.0: Non-responsive xHCI host is not halting. >> xhci_hcd :0e:00.0: Completing active URBs anyway. >> xhci_hcd :0e:00.0: HC died; cleaning up >> sd 9:0:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_ERROR >> driverbyte=DRIVER_OK >> sd 9:0:0:0: [sdc] tag#0 CDB: Read(10) 28 00 00 19 a9 00 00 00 f0 00 >> blk_update_request: I/O error, dev sdc, sector 1681664 >> xhci_hcd :0e:00.0: Stopped the command ring failed, maybe the host >> is dead >> xhci_hcd :0e:00.0: Host not halted after 16000 microseconds. >> xhci_hcd :0e:00.0: Abort command ring failed >> xhci_hcd :0e:00.0: HC died; cleaning up >> >> At this point, a reboot is required to reactivate the controller, >> unloading and reloading the xhci_* modules does not work. >> > > With 120MB/s I assume it was a USB3 device. > Was there any USB 2 device connected as well? > Does this occur with only a USB2 device connected to xhci? > > xhci handles suspend/resume a bit differently for USB2 and USB3 roothubs. > > Does this happen on older kernels as well? 4.3 or 4.2 based? > > For more xhci debugging, do: > echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control > and check dmesg for more xhci info. > > If reloading the module did not help it is more likely that the > controller is in some > unexpected state. > If however, it would instead be just bad timeout timer handling we > could just return immediately > in the timeout handler, and check if the usb device(s) continue to > work normally. > > This could be done by editing drivers/usb/hosts/xhci-ring.c > > +++ b/drivers/usb/host/xhci-ring.c > @@ -831,6 +831,7 @@ void xhci_stop_endpoint_command_watchdog(unsigned > long arg) > struct xhci_virt_ep *ep; > int ret, i, j; > unsigned long flags; > + return; > > -Mathias > > Hello Mat, thanks for your response. I have experimented with your suggestions. As for your questions: No, there was only one USB3 stick connected to the host controller during the tests. USB2 devices work fine too. Yes, I encountered this problem on a 4.1 series kernel aswell as the 4.4 series. I have enabled the debug controls and attached the results to this mail, along with some commentary. I am hoping this works in the mailing list. I've also tried your suggested modification, and it does seem to work! With it, the controller does not die, but it still sacrifices a lot of speed (as I had mentioned in the first mail of this thread) I hope this is helpful! Cheers, - Mike enabling auto powersave for the host controller Feb 16 20:03:22 xhci_hcd :0e:00.0: xhci_suspend: stopping port polling. Feb 16 20:03:22 xhci_hcd :0e:00.0: // Setting command ring address to 0xe001 inserting usb3 storage device Feb 16 20:03:33 xhci_hcd :0e:00.0: // Setting command ring address to 0xe001 Feb 16 20:03:33 xhci_hcd :0e:00.0: xhci_resume: starting port polling. Feb 16 20:03:33 xhci_hcd :0e:00.0: xhci_hub_status_data: stopping port polling. Feb 16 20:03:33 xhci_hcd :0e:00.0: xhci_suspend: stopping port polling. Feb 16 20:03:33 xhci_hcd :0e:00.0: Port Status Change Event for port 3 Feb 16 20:03:33 xhci_hcd :0e:00.0: resume root hub Feb 16 20:03:33 xhci_hcd :0e:00.0: handle_port_status: starting port polling. Feb 16 20:03:33 xhci_hcd :0e:00.0: // Setting command ring address to 0xe001 Feb 16 20:03:33 xhci_hcd :0e:00.0: // Setting command ring address to 0xe001 Feb 16 20:03:33 xhci_hcd :0e:00.0: xhci_resume: starting port polling. Feb 16 20:03:33 xhci_hcd :0e:00.0: xhci_hub_status_data: stopping port polling. Feb 16 20:03:33 xhci_hcd :0e:00.0: get port status, actual port 0 status = 0x202e1 Feb 16 20:03:33 xhci_hcd :0e:00.0: Get port status returned 0x10101 Feb 16 20:03:33 xhci_hcd :0e:00.0: clear port connect change, actual port 0 status = 0x2e1 Feb 16 20:03:33 xhci_hc
Re: [PATCH v2] usb: dwc3: Fix assignment of EP transfer resources
On 2/16/2016 1:28 PM, Felipe Balbi wrote:
>
> Hi,
>
> John Youn writes:
>> The assignement of EP transfer resources was not handled properly in the
>> dwc3 driver. Commit aebda6187181 ("usb: dwc3: Reset the transfer
>> resource index on SET_INTERFACE") previously fixed one aspect of this
>> where resources may be exhausted with multiple calls to SET_INTERFACE.
>> However, it introduced an issue where composite devices with multiple
>> interfaces can be assigned the same transfer resources for different
>> endpoints. This patch solves both issues.
>>
>> The assignment of transfer resources cannot perfectly follow the data
>> book due to the fact that the controller driver does not have all
>> knowledge of the configuration in advance. It is given this information
>> piecemeal by the composite gadget framework after every
>> SET_CONFIGURATION and SET_INTERFACE. Trying to follow the databook
>> programming model in this scenario can cause errors. For two reasons:
>>
>> 1) The databook says to do DEPSTARTCFG for every SET_CONFIGURATION and
>> SET_INTERFACE (8.1.5). This is incorrect in the scenario of multiple
>> interfaces.
>>
>> 2) The databook does not mention doing more DEPXFERCFG for new endpoint
>> on alt setting (8.1.6).
>>
>> The following simplified method is used instead:
>>
>> All hardware endpoints can be assigned a transfer resource and this
>> setting will stay persistent until either a core reset or hibernation.
>> So whenever we do a DEPSTARTCFG(0) we can go ahead and do DEPXFERCFG for
>> every hardware endpoint as well. We are guaranteed that there are as
>> many transfer resources as endpoints.
>>
>> This patch triggers off of the calling dwc3_gadget_start_config() for
>> EP0-out, which always happens first, and which should only happen in one
>> of the above conditions.
>
> very good commit log. Thank you :-)
>
>> Fixes: aebda6187181 ("usb: dwc3: Reset the transfer resource index on
>> SET_INTERFACE")
>
> you missed:
>
> Cc: # v
>
>> Reported-by: Ravi Babu
>> Signed-off-by: John Youn
>> ---
>>
>> Hi Ravi,
>>
>> This is a simplified version of the previous patch. Could you verify
>> that it works with your test scenario?
>>
>> Thanks,
>> John
>>
>> v2:
>> * Simplified assignment of resources by doing all endpoints at once.
>>
>>
>> drivers/usb/dwc3/core.h | 1 -
>> drivers/usb/dwc3/ep0.c| 5 -
>> drivers/usb/dwc3/gadget.c | 38 --
>> 3 files changed, 20 insertions(+), 24 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
>> index 2913068..e4f8b90 100644
>> --- a/drivers/usb/dwc3/core.h
>> +++ b/drivers/usb/dwc3/core.h
>> @@ -856,7 +856,6 @@ struct dwc3 {
>> unsignedpullups_connected:1;
>> unsignedresize_fifos:1;
>> unsignedsetup_packet_pending:1;
>> -unsignedstart_config_issued:1;
>> unsignedthree_stage_setup:1;
>> unsignedusb3_lpm_capable:1;
>>
>> diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
>> index 3a9354a..8d6b75c 100644
>> --- a/drivers/usb/dwc3/ep0.c
>> +++ b/drivers/usb/dwc3/ep0.c
>> @@ -555,7 +555,6 @@ static int dwc3_ep0_set_config(struct dwc3 *dwc, struct
>> usb_ctrlrequest *ctrl)
>> int ret;
>> u32 reg;
>>
>> -dwc->start_config_issued = false;
>> cfg = le16_to_cpu(ctrl->wValue);
>>
>> switch (state) {
>> @@ -737,10 +736,6 @@ static int dwc3_ep0_std_request(struct dwc3 *dwc,
>> struct usb_ctrlrequest *ctrl)
>> dwc3_trace(trace_dwc3_ep0, "USB_REQ_SET_ISOCH_DELAY");
>> ret = dwc3_ep0_set_isoch_delay(dwc, ctrl);
>> break;
>> -case USB_REQ_SET_INTERFACE:
>> -dwc3_trace(trace_dwc3_ep0, "USB_REQ_SET_INTERFACE");
>> -dwc->start_config_issued = false;
>> -/* Fall through */
>> default:
>> dwc3_trace(trace_dwc3_ep0, "Forwarding to gadget driver");
>> ret = dwc3_ep0_delegate_req(dwc, ctrl);
>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>> index 7d1dd82..ae2e546 100644
>> --- a/drivers/usb/dwc3/gadget.c
>> +++ b/drivers/usb/dwc3/gadget.c
>> @@ -385,24 +385,34 @@ static void dwc3_free_trb_pool(struct dwc3_ep *dep)
>> dep->trb_pool_dma = 0;
>> }
>>
>> +static int dwc3_gadget_set_xfer_resource(struct dwc3 *dwc, struct dwc3_ep
>> *dep);
>> +
>> static int dwc3_gadget_start_config(struct dwc3 *dwc, struct dwc3_ep *dep)
>> {
>> struct dwc3_gadget_ep_cmd_params params;
>> u32 cmd;
>> +int i, ret;
>
> I'd prefer if these two variables would be split into their own lines:
>
> int ret;
> int i;
>
>> +if (dep->number)
>> +return 0;
>>
>> memset(¶ms, 0x00, sizeof(params));
>> +cmd = DWC3_DEPCMD_DEPSTARTCFG;
>>
>> -if (dep->number != 1) {
>> -cmd =
[PATCH 0/2] usb: dwc2: Fix host descriptor DMA issues
This series contains two fixes for the host in Descriptor DMA mode. Tang, Jianqiang (1): usb: dwc2: host: fix the data toggle error in full speed descriptor dma Vardan Mikayelyan (1): usb: dwc2: host: fix logical omissions in dwc2_process_non_isoc_desc drivers/usb/dwc2/hcd_ddma.c | 23 +++ drivers/usb/dwc2/hcd_intr.c | 8 2 files changed, 19 insertions(+), 12 deletions(-) -- 2.6.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] usb: dwc2: host: fix logical omissions in dwc2_process_non_isoc_desc
From: Vardan Mikayelyan
Fixes memory manipulation issues and makes Host DDMA bulk transfers
work.
dwc2_process_non_isoc_desc() must return non zero value ONLY when
failure happens in one of the queued descriptors. After receiving
non zero value the caller must stop processing of remaining
QTDs and their descriptors from chain.
Commit 26a19ea699060fde ("usb: dwc2: host: fix use of qtd after
free in desc dma mode") breaks non_isoc transaction completion logic
in Host DDMA mode. There were bugs before that, but after this patch
dwc2_process_non_isoc_desc() returns fail status even if descriptor
was processed normally. This causes break from loop which is processing
remaining descriptors assigned to QTD, which is not correct for QTDs
containing more than one descriptor.
Current dwc2 driver gathers queued BULK URBs until receiving URB
without URB_NO_INTERRUPT flag. Once getting it, SW creates
descriptor chain, stores it in qh structure and passes start
address to HW. Multiple URB data is contained in that chain.
Hence on getting error on descriptor after its processing by HW,
SW should go out of both loops(qh->qtd, qtd->descs) and report
the failure.
Fixes: 26a19ea699060fde ("usb: dwc2: host: fix use of qtd after free in desc
dma mode")
Cc: Gregory Herrero
Signed-off-by: Vardan Mikayelyan
Signed-off-by: John Youn
---
drivers/usb/dwc2/hcd_ddma.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/dwc2/hcd_ddma.c b/drivers/usb/dwc2/hcd_ddma.c
index 36606fc..89db47a 100644
--- a/drivers/usb/dwc2/hcd_ddma.c
+++ b/drivers/usb/dwc2/hcd_ddma.c
@@ -1174,14 +1174,11 @@ static int dwc2_process_non_isoc_desc(struct dwc2_hsotg
*hsotg,
failed = dwc2_update_non_isoc_urb_state_ddma(hsotg, chan, qtd, dma_desc,
halt_status, n_bytes,
xfer_done);
- if (*xfer_done && urb->status != -EINPROGRESS)
- failed = 1;
-
- if (failed) {
+ if (failed || (*xfer_done && urb->status != -EINPROGRESS)) {
dwc2_host_complete(hsotg, qtd, urb->status);
dwc2_hcd_qtd_unlink_and_free(hsotg, qtd, qh);
- dev_vdbg(hsotg->dev, "failed=%1x xfer_done=%1x status=%08x\n",
-failed, *xfer_done, urb->status);
+ dev_vdbg(hsotg->dev, "failed=%1x xfer_done=%1x\n",
+failed, *xfer_done);
return failed;
}
@@ -1236,21 +1233,23 @@ static void dwc2_complete_non_isoc_xfer_ddma(struct
dwc2_hsotg *hsotg,
list_for_each_safe(qtd_item, qtd_tmp, &qh->qtd_list) {
int i;
+ int qtd_desc_count;
qtd = list_entry(qtd_item, struct dwc2_qtd, qtd_list_entry);
xfer_done = 0;
+ qtd_desc_count = qtd->n_desc;
- for (i = 0; i < qtd->n_desc; i++) {
+ for (i = 0; i < qtd_desc_count; i++) {
if (dwc2_process_non_isoc_desc(hsotg, chan, chnum, qtd,
desc_num, halt_status,
- &xfer_done)) {
- qtd = NULL;
- break;
- }
+ &xfer_done))
+ goto stop_scan;
+
desc_num++;
}
}
+stop_scan:
if (qh->ep_type != USB_ENDPOINT_XFER_CONTROL) {
/*
* Resetting the data toggle for bulk and interrupt endpoints
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] usb: dwc2: host: fix logical omissions in dwc2_process_non_isoc_desc
From: Vardan Mikayelyan
Fixes memory manipulation issues and makes Host DDMA bulk transfers
work.
dwc2_process_non_isoc_desc() must return non zero value ONLY when
failure happens in one of the queued descriptors. After receiving
non zero value the caller must stop processing of remaining
QTDs and their descriptors from chain.
Commit 26a19ea699060fde ("usb: dwc2: host: fix use of qtd after
free in desc dma mode") breaks non_isoc transaction completion logic
in Host DDMA mode. There were bugs before that, but after this patch
dwc2_process_non_isoc_desc() returns fail status even if descriptor
was processed normally. This causes break from loop which is processing
remaining descriptors assigned to QTD, which is not correct for QTDs
containing more than one descriptor.
Current dwc2 driver gathers queued BULK URBs until receiving URB
without URB_NO_INTERRUPT flag. Once getting it, SW creates
descriptor chain, stores it in qh structure and passes start
address to HW. Multiple URB data is contained in that chain.
Hence on getting error on descriptor after its processing by HW,
SW should go out of both loops(qh->qtd, qtd->descs) and report
the failure.
Fixes: 26a19ea699060fde ("usb: dwc2: host: fix use of qtd after free in desc
dma mode")
Cc: Gregory Herrero
Signed-off-by: Vardan Mikayelyan
Signed-off-by: John Youn
---
drivers/usb/dwc2/hcd_ddma.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/dwc2/hcd_ddma.c b/drivers/usb/dwc2/hcd_ddma.c
index 36606fc..89db47a 100644
--- a/drivers/usb/dwc2/hcd_ddma.c
+++ b/drivers/usb/dwc2/hcd_ddma.c
@@ -1174,14 +1174,11 @@ static int dwc2_process_non_isoc_desc(struct dwc2_hsotg
*hsotg,
failed = dwc2_update_non_isoc_urb_state_ddma(hsotg, chan, qtd, dma_desc,
halt_status, n_bytes,
xfer_done);
- if (*xfer_done && urb->status != -EINPROGRESS)
- failed = 1;
-
- if (failed) {
+ if (failed || (*xfer_done && urb->status != -EINPROGRESS)) {
dwc2_host_complete(hsotg, qtd, urb->status);
dwc2_hcd_qtd_unlink_and_free(hsotg, qtd, qh);
- dev_vdbg(hsotg->dev, "failed=%1x xfer_done=%1x status=%08x\n",
-failed, *xfer_done, urb->status);
+ dev_vdbg(hsotg->dev, "failed=%1x xfer_done=%1x\n",
+failed, *xfer_done);
return failed;
}
@@ -1236,21 +1233,23 @@ static void dwc2_complete_non_isoc_xfer_ddma(struct
dwc2_hsotg *hsotg,
list_for_each_safe(qtd_item, qtd_tmp, &qh->qtd_list) {
int i;
+ int qtd_desc_count;
qtd = list_entry(qtd_item, struct dwc2_qtd, qtd_list_entry);
xfer_done = 0;
+ qtd_desc_count = qtd->n_desc;
- for (i = 0; i < qtd->n_desc; i++) {
+ for (i = 0; i < qtd_desc_count; i++) {
if (dwc2_process_non_isoc_desc(hsotg, chan, chnum, qtd,
desc_num, halt_status,
- &xfer_done)) {
- qtd = NULL;
- break;
- }
+ &xfer_done))
+ goto stop_scan;
+
desc_num++;
}
}
+stop_scan:
if (qh->ep_type != USB_ENDPOINT_XFER_CONTROL) {
/*
* Resetting the data toggle for bulk and interrupt endpoints
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] usb: dwc2: host: fix the data toggle error in full speed descriptor dma
From: Tang, Jianqiang
There will be data toggle error happen for full speed buld-out transfer.
The data toggle bit is saved in qh for non-control transfers, it is wrong
to check the qtd for that case.
Also fix one static analysis tool issue after fix the data toggle error.
John Youn:
* Added WARN() to warn on improper usage of the
dwc2_hcd_save_data_toggle() function.
Signed-off-by: Dyson Lee
Signed-off-by: Tang, Jianqiang
Signed-off-by: John Youn
---
drivers/usb/dwc2/hcd_ddma.c | 2 +-
drivers/usb/dwc2/hcd_intr.c | 8
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc2/hcd_ddma.c b/drivers/usb/dwc2/hcd_ddma.c
index 89db47a..a41274a 100644
--- a/drivers/usb/dwc2/hcd_ddma.c
+++ b/drivers/usb/dwc2/hcd_ddma.c
@@ -1257,7 +1257,7 @@ stop_scan:
*/
if (halt_status == DWC2_HC_XFER_STALL)
qh->data_toggle = DWC2_HC_PID_DATA0;
- else if (qtd)
+ else
dwc2_hcd_save_data_toggle(hsotg, chan, chnum, qtd);
}
diff --git a/drivers/usb/dwc2/hcd_intr.c b/drivers/usb/dwc2/hcd_intr.c
index f825380..cadba8b 100644
--- a/drivers/usb/dwc2/hcd_intr.c
+++ b/drivers/usb/dwc2/hcd_intr.c
@@ -525,11 +525,19 @@ void dwc2_hcd_save_data_toggle(struct dwc2_hsotg *hsotg,
u32 pid = (hctsiz & TSIZ_SC_MC_PID_MASK) >> TSIZ_SC_MC_PID_SHIFT;
if (chan->ep_type != USB_ENDPOINT_XFER_CONTROL) {
+ if (WARN(!chan || !chan->qh,
+"chan->qh must be specified for non-control eps\n"))
+ return;
+
if (pid == TSIZ_SC_MC_PID_DATA0)
chan->qh->data_toggle = DWC2_HC_PID_DATA0;
else
chan->qh->data_toggle = DWC2_HC_PID_DATA1;
} else {
+ if (WARN(!qtd,
+"qtd must be specified for control eps\n"))
+ return;
+
if (pid == TSIZ_SC_MC_PID_DATA0)
qtd->data_toggle = DWC2_HC_PID_DATA0;
else
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] usb: dwc2: Fix host descriptor DMA issues
Sorry, messed up the emails. V2 is just a resend with e-mails fixed up. This series contains two fixes for the host in Descriptor DMA mode. v2: * Resend with proper e-mails Tang, Jianqiang (1): usb: dwc2: host: fix the data toggle error in full speed descriptor dma Vardan Mikayelyan (1): usb: dwc2: host: fix logical omissions in dwc2_process_non_isoc_desc drivers/usb/dwc2/hcd_ddma.c | 23 +++ drivers/usb/dwc2/hcd_intr.c | 8 2 files changed, 19 insertions(+), 12 deletions(-) -- 2.6.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: storage: make US_DEBUGPX print with LOGLEVEL_DEBUG
On Sun, Feb 14, 2016 at 05:20:21PM -0800, Greg Kroah-Hartman wrote: > On Wed, Feb 10, 2016 at 04:13:43PM -0800, Victor Dodon wrote: > > The US_DEBUGPX macro uses printk without specifying a kernel log level, so > > the default kernel log level is used, which may not match LOGLEVEL_DEBUG > > used in usb_stor_dbg. Use printk_emit with LOGLEVEL_DEBUG instead. > > > > Signed-off-by: Victor Dodon > > --- > > drivers/usb/storage/debug.h | 10 -- > > 1 file changed, 8 insertions(+), 2 deletions(-) > > Can you just get rid of US_DEBUGPX() entirely please? It shouldn't be > needed anymore, just use usb_stor_dbg() instead. Using usb_stor_dbg() instead of US_DEBUGPX() in usb_stor_show_command() prints one byte per line with the full syslog header, like this: 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876236] Command TEST_UNIT_READY (6 bytes) 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876242] bytes: 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876249] 00 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876255] 00 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876261] 00 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876267] 00 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876273] 00 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876279] 00 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876285] instead of the desired: 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876236] Command TEST_UNIT_READY (6 bytes) 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876242] bytes: 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876249] 00 00 00 00 00 00 this is why I think the US_DEBUGPX() macro is still needed. Regards, Victor Dodon. > > thanks, > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: storage: make US_DEBUGPX print with LOGLEVEL_DEBUG
On Tue, Feb 16, 2016 at 03:45:39PM -0800, Victor Dodon wrote: > On Sun, Feb 14, 2016 at 05:20:21PM -0800, Greg Kroah-Hartman wrote: > > On Wed, Feb 10, 2016 at 04:13:43PM -0800, Victor Dodon wrote: > > > The US_DEBUGPX macro uses printk without specifying a kernel log level, so > > > the default kernel log level is used, which may not match LOGLEVEL_DEBUG > > > used in usb_stor_dbg. Use printk_emit with LOGLEVEL_DEBUG instead. > > > > > > Signed-off-by: Victor Dodon > > > --- > > > drivers/usb/storage/debug.h | 10 -- > > > 1 file changed, 8 insertions(+), 2 deletions(-) > > > > Can you just get rid of US_DEBUGPX() entirely please? It shouldn't be > > needed anymore, just use usb_stor_dbg() instead. > > Using usb_stor_dbg() instead of US_DEBUGPX() in > usb_stor_show_command() prints one byte per line with the full syslog > header, like this: > > 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876236] Command > TEST_UNIT_READY (6 bytes) > 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876242] bytes: > 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876249] 00 > 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876255] 00 > 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876261] 00 > 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876267] 00 > 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876273] 00 > 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876279] 00 > 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876285] > > instead of the desired: > > 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876236] Command > TEST_UNIT_READY (6 bytes) > 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876242] bytes: > 7,0,Feb 16 14:30:41,ubuntu,kernel:,[ 422.876249] 00 00 00 00 00 00 > > this is why I think the US_DEBUGPX() macro is still needed. Nope, fix the call to use the proper printk % modifier instead and you will be fine. No need to keep reinventing the wheel, we have had support for byte streams in messages for probably over a decade now... Nice try though :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net,stable] qmi_wwan: add "4G LTE usb-modem U901"
From: Bjørn Mork Date: Fri, 12 Feb 2016 16:42:14 +0100 > Thomas reports: > > T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 4 Spd=480 MxCh= 0 > D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 > P: Vendor=05c6 ProdID=6001 Rev=00.00 > S: Manufacturer=USB Modem > S: Product=USB Modem > S: SerialNumber=1234567890ABCDEF > C: #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA > I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option > I: If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option > I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option > I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan > I: If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage > > Reported-by: Thomas Schäfer > Signed-off-by: Bjørn Mork Applied and queued up for -stable, thanks. -- 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: Minor xhci issues (failed to peer) on Dell XPS 13 9350 (Skylake)
On Tue, Feb 16, 2016 at 10:01:13AM -0800, Andy Lutomirski wrote: > I get some warnings at boot on all kernels I've tried. On 4.5-rc4, I see: > > [0.229429] usbcore: registered new interface driver usbfs > [0.229436] usbcore: registered new interface driver hub > [0.229451] usbcore: registered new device driver usb > [1.057998] xhci_hcd :00:14.0: xHCI Host Controller > [1.058640] xhci_hcd :00:14.0: new USB bus registered, assigned > bus number 1 > [1.059811] xhci_hcd :00:14.0: hcc params 0x200077c1 hci > version 0x100 quirks 0x00109810 > [1.059818] xhci_hcd :00:14.0: cache line size of 64 is not supported > [1.059821] xhci_hcd :00:14.0: supports USB remote wakeup > [1.060480] usb usb1: default language 0x0409 > [1.060584] usb usb1: udev 1, busnum 1, minor = 0 > [1.060587] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 > [1.060589] usb usb1: New USB device strings: Mfr=3, Product=2, > SerialNumber=1 > [1.060590] usb usb1: Product: xHCI Host Controller > [1.060592] usb usb1: Manufacturer: Linux 4.5.0-rc4-acpi+ xhci-hcd > [1.060593] usb usb1: SerialNumber: :00:14.0 > [1.060845] usb usb1: usb_probe_device > [1.060848] usb usb1: configuration #1 chosen from 1 choice > [1.060914] usb usb1: adding 1-0:1.0 (config #1, interface 0) > [1.060937] hub 1-0:1.0: usb_probe_interface > [1.060939] hub 1-0:1.0: usb_probe_interface - got id > [1.060941] hub 1-0:1.0: USB hub found > [1.061028] hub 1-0:1.0: 12 ports detected > [1.061030] hub 1-0:1.0: standalone hub > [1.061031] hub 1-0:1.0: no power switching (usb 1.0) > [1.061032] hub 1-0:1.0: individual port over-current protection > [1.061034] hub 1-0:1.0: Single TT > [1.061035] hub 1-0:1.0: TT requires at most 8 FS bit times (666 ns) > [1.061036] hub 1-0:1.0: power on to power good time: 20ms > [1.061109] hub 1-0:1.0: local power source is good > [1.084337] usb usb1-port3: DeviceRemovable is changed to 1 > according to platform information. > [1.084339] usb usb1-port4: DeviceRemovable is changed to 1 > according to platform information. > [1.084341] usb usb1-port5: DeviceRemovable is changed to 1 > according to platform information. > [1.084343] hub 1-0:1.0: trying to enable port power on non-switchable hub > [1.084438] xhci_hcd :00:14.0: xHCI Host Controller > [1.084624] xhci_hcd :00:14.0: new USB bus registered, assigned > bus number 2 > [1.084628] xhci_hcd :00:14.0: supports USB remote wakeup > [1.084671] usb usb2: skipped 1 descriptor after endpoint > [1.084679] usb usb2: default language 0x0409 > [1.084691] usb usb2: udev 1, busnum 2, minor = 128 > [1.084693] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003 > [1.084694] usb usb2: New USB device strings: Mfr=3, Product=2, > SerialNumber=1 > [1.084695] usb usb2: Product: xHCI Host Controller > [1.084697] usb usb2: Manufacturer: Linux 4.5.0-rc4-acpi+ xhci-hcd > [1.084698] usb usb2: SerialNumber: :00:14.0 > [1.084909] usb usb2: usb_probe_device > [1.084914] usb usb2: configuration #1 chosen from 1 choice > [1.084926] usb usb2: adding 2-0:1.0 (config #1, interface 0) > [1.084948] hub 2-0:1.0: usb_probe_interface > [1.084949] hub 2-0:1.0: usb_probe_interface - got id > [1.084952] hub 2-0:1.0: USB hub found > [1.084966] hub 2-0:1.0: 6 ports detected > [1.084968] hub 2-0:1.0: standalone hub > [1.084969] hub 2-0:1.0: no power switching (usb 1.0) > [1.084971] hub 2-0:1.0: individual port over-current protection > [1.084972] hub 2-0:1.0: TT requires at most 8 FS bit times (666 ns) > [1.084973] hub 2-0:1.0: power on to power good time: 20ms > [1.084978] hub 2-0:1.0: local power source is good > [1.085684] usb usb2-port1: peered to usb1-port1 > [1.086356] usb usb2-port2: peered to usb1-port2 > [1.087004] usb usb2-port3: peered to usb1-port6 > [1.087713] usb: failed to peer usb2-port4 and usb1-port6 by > location (usb2-port4:none) (usb1-port6:usb2-port3) > [1.087715] usb usb2-port4: failed to peer to usb1-port6 (-16) > [1.087716] usb: port power management may be unreliable > [1.088377] usb: failed to peer usb2-port5 and usb1-port6 by > location (usb2-port5:none) (usb1-port6:usb2-port3) > [1.088379] usb usb2-port5: failed to peer to usb1-port6 (-16) > [1.089017] usb: failed to peer usb2-port6 and usb1-port6 by > location (usb2-port6:none) (usb1-port6:usb2-port3) > [1.089018] usb usb2-port6: failed to peer to usb1-port6 (-16) > [1.089028] hub 2-0:1.0: trying to enable port power on non-switchable hub > [1.089164] usbcore: registered new interface driver usbserial > [1.089170] usbcore: registered new interface driver usbserial_generic > [1.089195] usbserial: USB Serial support registered for generic > [1.097055] usbcore: registered new interface driver usbhid > [1.097056] usbhid:
Re: [PATCH] usb: retry reset if a device times out
On Wed, Feb 10, 2016 at 11:33:18AM +0100, Oliver Neukum wrote: > Some devices I got show an inability to operate right after > power on if they are already connected. They are beyond recovery > if the descriptors are requested multiple times. So in case of > a timeout we rather bail early and reset again. But it must be > done only on the first loop lest we get into a reset/time out > spiral that can be overcome with a retry. > > This patch is a rework of a patch that fell through the cracks. > http://www.spinics.net/lists/linux-usb/msg103263.html > > Signed-off-by: Oliver Neukum > CC: sta...@vger.kernel.org > --- > drivers/usb/core/hub.c | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c > index f912fe6..e4e46f6 100644 > --- a/drivers/usb/core/hub.c > +++ b/drivers/usb/core/hub.c > @@ -4496,7 +4496,13 @@ hub_port_init(struct usb_hub *hub, struct usb_device > *udev, int port1, > r = -EPROTO; > break; > } > - if (r == 0) > + /* > + * Some devices time out if they are powered on > + * when already connected. They need a second > + * reset. But only on the first attempt, > + * lest we get into a time out/reset loop > + */ > + if (r == 0 || (r == -ETIMEDOUT && j == 0)) > break; > } > udev->descriptor.bMaxPacketSize0 = > -- > 2.1.4 > I remembered you agreed with using outer loop counter (i) as the quit condition. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] usb: dwc3: Fix assignment of EP transfer resources
The assignement of EP transfer resources was not handled properly in the
dwc3 driver. Commit aebda6187181 ("usb: dwc3: Reset the transfer
resource index on SET_INTERFACE") previously fixed one aspect of this
where resources may be exhausted with multiple calls to SET_INTERFACE.
However, it introduced an issue where composite devices with multiple
interfaces can be assigned the same transfer resources for different
endpoints. This patch solves both issues.
The assignment of transfer resources cannot perfectly follow the data
book due to the fact that the controller driver does not have all
knowledge of the configuration in advance. It is given this information
piecemeal by the composite gadget framework after every
SET_CONFIGURATION and SET_INTERFACE. Trying to follow the databook
programming model in this scenario can cause errors. For two reasons:
1) The databook says to do DEPSTARTCFG for every SET_CONFIGURATION and
SET_INTERFACE (8.1.5). This is incorrect in the scenario of multiple
interfaces.
2) The databook does not mention doing more DEPXFERCFG for new endpoint
on alt setting (8.1.6).
The following simplified method is used instead:
All hardware endpoints can be assigned a transfer resource and this
setting will stay persistent until either a core reset or hibernation.
So whenever we do a DEPSTARTCFG(0) we can go ahead and do DEPXFERCFG for
every hardware endpoint as well. We are guaranteed that there are as
many transfer resources as endpoints.
This patch triggers off of the calling dwc3_gadget_start_config() for
EP0-out, which always happens first, and which should only happen in one
of the above conditions.
Fixes: aebda6187181 ("usb: dwc3: Reset the transfer resource index on
SET_INTERFACE")
Cc: # v3.2+
Reported-by: Ravi Babu
Signed-off-by: John Youn
---
Hi Ravi,
Could you verify that it works with your test scenario?
Thanks,
John
v3:
* Added comments
* Removed unused variables
* Formatting
v2:
* Simplified assignment of resources by doing all endpoints at once.
drivers/usb/dwc3/core.h | 1 -
drivers/usb/dwc3/ep0.c| 5
drivers/usb/dwc3/gadget.c | 70 +++
3 files changed, 52 insertions(+), 24 deletions(-)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 2913068..e4f8b90 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -856,7 +856,6 @@ struct dwc3 {
unsignedpullups_connected:1;
unsignedresize_fifos:1;
unsignedsetup_packet_pending:1;
- unsignedstart_config_issued:1;
unsignedthree_stage_setup:1;
unsignedusb3_lpm_capable:1;
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 3a9354a..8d6b75c 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -555,7 +555,6 @@ static int dwc3_ep0_set_config(struct dwc3 *dwc, struct
usb_ctrlrequest *ctrl)
int ret;
u32 reg;
- dwc->start_config_issued = false;
cfg = le16_to_cpu(ctrl->wValue);
switch (state) {
@@ -737,10 +736,6 @@ static int dwc3_ep0_std_request(struct dwc3 *dwc, struct
usb_ctrlrequest *ctrl)
dwc3_trace(trace_dwc3_ep0, "USB_REQ_SET_ISOCH_DELAY");
ret = dwc3_ep0_set_isoch_delay(dwc, ctrl);
break;
- case USB_REQ_SET_INTERFACE:
- dwc3_trace(trace_dwc3_ep0, "USB_REQ_SET_INTERFACE");
- dwc->start_config_issued = false;
- /* Fall through */
default:
dwc3_trace(trace_dwc3_ep0, "Forwarding to gadget driver");
ret = dwc3_ep0_delegate_req(dwc, ctrl);
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 7d1dd82..2363bad 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -385,24 +385,66 @@ static void dwc3_free_trb_pool(struct dwc3_ep *dep)
dep->trb_pool_dma = 0;
}
+static int dwc3_gadget_set_xfer_resource(struct dwc3 *dwc, struct dwc3_ep
*dep);
+
+/**
+ * dwc3_gadget_start_config - Configure EP resources
+ * @dwc: pointer to our controller context structure
+ * @dep: endpoint that is being enabled
+ *
+ * The assignment of transfer resources cannot perfectly follow the
+ * data book due to the fact that the controller driver does not have
+ * all knowledge of the configuration in advance. It is given this
+ * information piecemeal by the composite gadget framework after every
+ * SET_CONFIGURATION and SET_INTERFACE. Trying to follow the databook
+ * programming model in this scenario can cause errors. For two
+ * reasons:
+ *
+ * 1) The databook says to do DEPSTARTCFG for every SET_CONFIGURATION
+ * and SET_INTERFACE (8.1.5). This is incorrect in the scenario of
+ * multiple interfaces.
+ *
+ * 2) The databook does not mention doing more DEPXFERCFG for new
+ * endpoint on alt setting (8.1.6).
+ *
+ * The following simplified method is used instead:
Re: Minor xhci issues (failed to peer) on Dell XPS 13 9350 (Skylake)
On Tue, Feb 16, 2016 at 6:33 PM, Greg Kroah-Hartman wrote: > On Tue, Feb 16, 2016 at 10:01:13AM -0800, Andy Lutomirski wrote: >> I get some warnings at boot on all kernels I've tried. On 4.5-rc4, I see: >> >> [0.229429] usbcore: registered new interface driver usbfs >> [0.229436] usbcore: registered new interface driver hub >> [0.229451] usbcore: registered new device driver usb >> [1.057998] xhci_hcd :00:14.0: xHCI Host Controller >> [1.058640] xhci_hcd :00:14.0: new USB bus registered, assigned >> bus number 1 >> [1.059811] xhci_hcd :00:14.0: hcc params 0x200077c1 hci >> version 0x100 quirks 0x00109810 >> [1.059818] xhci_hcd :00:14.0: cache line size of 64 is not supported >> [1.059821] xhci_hcd :00:14.0: supports USB remote wakeup >> [1.060480] usb usb1: default language 0x0409 >> [1.060584] usb usb1: udev 1, busnum 1, minor = 0 >> [1.060587] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 >> [1.060589] usb usb1: New USB device strings: Mfr=3, Product=2, >> SerialNumber=1 >> [1.060590] usb usb1: Product: xHCI Host Controller >> [1.060592] usb usb1: Manufacturer: Linux 4.5.0-rc4-acpi+ xhci-hcd >> [1.060593] usb usb1: SerialNumber: :00:14.0 >> [1.060845] usb usb1: usb_probe_device >> [1.060848] usb usb1: configuration #1 chosen from 1 choice >> [1.060914] usb usb1: adding 1-0:1.0 (config #1, interface 0) >> [1.060937] hub 1-0:1.0: usb_probe_interface >> [1.060939] hub 1-0:1.0: usb_probe_interface - got id >> [1.060941] hub 1-0:1.0: USB hub found >> [1.061028] hub 1-0:1.0: 12 ports detected >> [1.061030] hub 1-0:1.0: standalone hub >> [1.061031] hub 1-0:1.0: no power switching (usb 1.0) >> [1.061032] hub 1-0:1.0: individual port over-current protection >> [1.061034] hub 1-0:1.0: Single TT >> [1.061035] hub 1-0:1.0: TT requires at most 8 FS bit times (666 ns) >> [1.061036] hub 1-0:1.0: power on to power good time: 20ms >> [1.061109] hub 1-0:1.0: local power source is good >> [1.084337] usb usb1-port3: DeviceRemovable is changed to 1 >> according to platform information. >> [1.084339] usb usb1-port4: DeviceRemovable is changed to 1 >> according to platform information. >> [1.084341] usb usb1-port5: DeviceRemovable is changed to 1 >> according to platform information. >> [1.084343] hub 1-0:1.0: trying to enable port power on non-switchable hub >> [1.084438] xhci_hcd :00:14.0: xHCI Host Controller >> [1.084624] xhci_hcd :00:14.0: new USB bus registered, assigned >> bus number 2 >> [1.084628] xhci_hcd :00:14.0: supports USB remote wakeup >> [1.084671] usb usb2: skipped 1 descriptor after endpoint >> [1.084679] usb usb2: default language 0x0409 >> [1.084691] usb usb2: udev 1, busnum 2, minor = 128 >> [1.084693] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003 >> [1.084694] usb usb2: New USB device strings: Mfr=3, Product=2, >> SerialNumber=1 >> [1.084695] usb usb2: Product: xHCI Host Controller >> [1.084697] usb usb2: Manufacturer: Linux 4.5.0-rc4-acpi+ xhci-hcd >> [1.084698] usb usb2: SerialNumber: :00:14.0 >> [1.084909] usb usb2: usb_probe_device >> [1.084914] usb usb2: configuration #1 chosen from 1 choice >> [1.084926] usb usb2: adding 2-0:1.0 (config #1, interface 0) >> [1.084948] hub 2-0:1.0: usb_probe_interface >> [1.084949] hub 2-0:1.0: usb_probe_interface - got id >> [1.084952] hub 2-0:1.0: USB hub found >> [1.084966] hub 2-0:1.0: 6 ports detected >> [1.084968] hub 2-0:1.0: standalone hub >> [1.084969] hub 2-0:1.0: no power switching (usb 1.0) >> [1.084971] hub 2-0:1.0: individual port over-current protection >> [1.084972] hub 2-0:1.0: TT requires at most 8 FS bit times (666 ns) >> [1.084973] hub 2-0:1.0: power on to power good time: 20ms >> [1.084978] hub 2-0:1.0: local power source is good >> [1.085684] usb usb2-port1: peered to usb1-port1 >> [1.086356] usb usb2-port2: peered to usb1-port2 >> [1.087004] usb usb2-port3: peered to usb1-port6 >> [1.087713] usb: failed to peer usb2-port4 and usb1-port6 by >> location (usb2-port4:none) (usb1-port6:usb2-port3) >> [1.087715] usb usb2-port4: failed to peer to usb1-port6 (-16) >> [1.087716] usb: port power management may be unreliable >> [1.088377] usb: failed to peer usb2-port5 and usb1-port6 by >> location (usb2-port5:none) (usb1-port6:usb2-port3) >> [1.088379] usb usb2-port5: failed to peer to usb1-port6 (-16) >> [1.089017] usb: failed to peer usb2-port6 and usb1-port6 by >> location (usb2-port6:none) (usb1-port6:usb2-port3) >> [1.089018] usb usb2-port6: failed to peer to usb1-port6 (-16) >> [1.089028] hub 2-0:1.0: trying to enable port power on non-switchable hub >> [1.089164] usbcore: registered new interface driver usbserial >> [1.089170] usbcore: registered new interface driver usbserial_generic >> [1.08919
TODO List For Linux USB
Hi All, I would like to contribute to Linux USB kernel but i am confused on where to start, If possible can you guys guide me regarding where to find the TODO list, so that I can start on with small patches. Thanking All. -- Regards, Anil Nair -- 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: TODO List For Linux USB
On Wed, Feb 17, 2016 at 11:47:56AM +0530, Anil Nair wrote: > Hi All, > > I would like to contribute to Linux USB kernel but i am confused on > where to start, If you don't know where to start, or what to do, why do you want to contribute? > If possible can you guys guide me regarding where to find the TODO > list, so that I can start on with small patches. Run it, stress it, find problems, and start solving them. Read the mailing list traffic and notice what others have problems with and work on solving them. Sorry, there is no TODO list. best of luck, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TODO List For Linux USB
Hi, On Wed, Feb 17, 2016 at 12:00 PM, Greg KH wrote: > On Wed, Feb 17, 2016 at 11:47:56AM +0530, Anil Nair wrote: >> Hi All, >> >> I would like to contribute to Linux USB kernel but i am confused on >> where to start, > > If you don't know where to start, or what to do, why do you want to > contribute? Because I have been on mailing list for quite a long time, I wanted to contribute something back to the community. >> If possible can you guys guide me regarding where to find the TODO >> list, so that I can start on with small patches. > > Run it, stress it, find problems, and start solving them. Read the > mailing list traffic and notice what others have problems with and work > on solving them. Most issues are beyond my scope it requires more experience at hardware level. Anyways i will observe and learn. > > Sorry, there is no TODO list. Ohh okay. > > best of luck, > Thanks. > greg k-h -- -- Regards, Anil Nair -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface
On Tue, Feb 16, 2016 at 02:39:47PM +0100, Oliver Neukum wrote: > On Tue, 2016-02-16 at 11:22 +0200, Heikki Krogerus wrote: > > > That question has not been answered. It would be awkward for the OS > > > to find itself in the slave role, which it is ill equipped for. So > > > the data role should be switched before the new device is announced > > > to user space. How is that handled? > > > > In the class driver, once we add support for preselecting the role, > > when the connection happens we compare the initial role to the > > preselected one and execute swap if it differs. Only after that we > > notify userspace. > > Yes, but we need an API. We can't keep adding to it. So if that > is to be supported, it needs to be defined now. When you say API, do you mean the API the class provides to the drivers? Or did you mean ABI which would be the sysfs in this case? For the sysfs I would image we can manage with the current files, current_data_role and current_power_role. If somebody writes to them when we are disconnected, we still callback the dr_swap or pr_swap hooks, and make a rule that when disconnected, it means we are setting the "preferred" roles. Would that be OK? Or did I still misunderstood your question? Thanks, -- heikki -- 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
