Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux
Hi Peter, On 06/04/2016 10:28 AM, Peter Chen wrote: > On Sat, Jun 04, 2016 at 12:06:06AM +0800, Lu Baolu wrote: >>> from my point,it is a dual-role switch >>> driver too, >> No, it's not a dual-role switch driver, but a driver for USB port >> multiplexing. >> >> One example of port multiplexing can be found in several Intel SOC and PCH >> chips, inside of which, there are two independent USB controllers: host and >> device. They might share a single port and this port could be configured to >> route the line to one of these two controllers. This patch introduced a >> generic >> framework for port mux drivers. It aids the drivers to handle port mux by >> providing interfaces to 1) register/unregister a mux device; 2) lookup the >> mux device; and 3) switch the port. >> > For this case, I can't see it is different with dual-role switch. Port mux is part of dual role switch, but not the whole thing. Dual role switch includes at least below things: - ID or type-C event detection - port mux - VBUS management - start/stop host/device controllers An OTG/Dual-role framework can be used to keep all these things run together with an internal state machine. But it's not duplicated with a generic framework for port mux and the port mux drivers. > Your > case is just like Renesas case, which uses two different drivers between > peripheral and host[1]. In my case, the port mux devices are physical devices and they can be controlled through GPIO pins or device registers. They are independent of both peripheral and host controllers. >> Port multiplexing isn't equal to USB dual role. There are other cases in >> today's >> systems. In several Intel PCH chips, there equips two USB host controllers: >> ehci >> and xhci. The xhci USB2 ports are multiplexed with ehci. This guarantees all >> USB ports work even running an old version of OS which lacks of USB3 support. >> In theory, we can create a driver for the port mux and switch the ports >> between >> xhci and ehci, but that's silly, isn't it? Why not always USB3?:-) >> >> Another case is xHCI debug capability. The xHCI host controller might equip >> a unit for system debugging (refer to 7.6 of xHCI spec). The debugging unit >> is >> independent of xhci host controller. But it shares its port with xhci. >> Software >> could switch the port between xhci and the debugging unit through the >> registers >> defined in xHCI spec. >> > Yes, above two are different with dual role switch. But in your code and > Kconfig, it seems this framework is dedicated for dual-role. Eg: > > +menuconfig USB_PORTMUX > + bool "USB dual role port MUX support" > + help > + Generic USB dual role port mux support. Above two cases are examples for port multiplexing, but I don't think we need drivers for them. At this moment, this framework is only for dual role port mux devices. > > I think a general dual role port mux is necessary, it can be used to > manage different dual-role switch method, eg Yes, I agree. > - ID pin > - External connector through GPIO > - SoC register > - sysfs > - type-C events ID pin and type-C events are the *reasons* which trigger the port mux switch. Currently, on our platforms, gpio, registers and sysfs are methods to control the mux. > > But this code is better co-work with OTG/Dual-role framework, we'd > better have only interface that the user can know which role for the > current port. OTG/Dual-role framework and portmux framework are not overlapped. The sysfs interface shouldn't be overlapped as well. Say, I have a port mux device and I have a driver for it. I am able to read the status of my port mux device through sysfs. This is not part of OTG/Dual-role as far as I can see. Best regards, Lu Baolu -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/4] usb: gadget: fix unused-but-set-variale warnings
Hi, [auto build test ERROR on balbi-usb/next] [also build test ERROR on v4.7-rc1 next-20160603] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Michal-Nazarewicz/usb-gadget-fix-unused-but-set-variale-warnings/20160531-202120 base: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next config: x86_64-randconfig-h0-06050347 (attached as .config) compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): In file included from include/linux/seqlock.h:35:0, from include/linux/time.h:5, from include/linux/stat.h:18, from include/linux/module.h:10, from drivers/usb/gadget/udc/pch_udc.c:10: drivers/usb/gadget/udc/pch_udc.c: In function 'pch_udc_pcd_ep_disable': >> drivers/usb/gadget/udc/pch_udc.c:1733:21: error: 'dev' undeclared (first use >> in this function) spin_lock_irqsave(&dev->lock, iflags); ^ include/linux/spinlock.h:208:34: note: in definition of macro 'raw_spin_lock_irqsave' flags = _raw_spin_lock_irqsave(lock); \ ^~~~ drivers/usb/gadget/udc/pch_udc.c:1733:2: note: in expansion of macro 'spin_lock_irqsave' spin_lock_irqsave(&dev->lock, iflags); ^ drivers/usb/gadget/udc/pch_udc.c:1733:21: note: each undeclared identifier is reported only once for each function it appears in spin_lock_irqsave(&dev->lock, iflags); ^ include/linux/spinlock.h:208:34: note: in definition of macro 'raw_spin_lock_irqsave' flags = _raw_spin_lock_irqsave(lock); \ ^~~~ drivers/usb/gadget/udc/pch_udc.c:1733:2: note: in expansion of macro 'spin_lock_irqsave' spin_lock_irqsave(&dev->lock, iflags); ^ drivers/usb/gadget/udc/pch_udc.c: In function 'pch_udc_alloc_request': drivers/usb/gadget/udc/pch_udc.c:1770:7: error: 'dev' undeclared (first use in this function) if (!dev->dma_addr) ^~~ In file included from include/linux/seqlock.h:35:0, from include/linux/time.h:5, from include/linux/stat.h:18, from include/linux/module.h:10, from drivers/usb/gadget/udc/pch_udc.c:10: drivers/usb/gadget/udc/pch_udc.c: In function 'pch_udc_pcd_dequeue': drivers/usb/gadget/udc/pch_udc.c:1943:21: error: 'dev' undeclared (first use in this function) spin_lock_irqsave(&dev->lock, flags); ^ include/linux/spinlock.h:208:34: note: in definition of macro 'raw_spin_lock_irqsave' flags = _raw_spin_lock_irqsave(lock); \ ^~~~ drivers/usb/gadget/udc/pch_udc.c:1943:2: note: in expansion of macro 'spin_lock_irqsave' spin_lock_irqsave(&dev->lock, flags); ^ drivers/usb/gadget/udc/pch_udc.c: In function 'pch_udc_pcd_set_halt': drivers/usb/gadget/udc/pch_udc.c:1979:7: error: 'dev' undeclared (first use in this function) if (!dev->driver || (dev->gadget.speed == USB_SPEED_UNKNOWN)) ^~~ drivers/usb/gadget/udc/pch_udc.c: In function 'pch_udc_pcd_set_wedge': drivers/usb/gadget/udc/pch_udc.c:2021:7: error: 'dev' undeclared (first use in this function) if (!dev->driver || (dev->gadget.speed == USB_SPEED_UNKNOWN)) ^~~ vim +/dev +1733 drivers/usb/gadget/udc/pch_udc.c 1727 return -EINVAL; 1728 1729 ep = container_of(usbep, struct pch_udc_ep, ep); 1730 if ((usbep->name == ep0_string) || !ep->ep.desc) 1731 return -EINVAL; 1732 > 1733 spin_lock_irqsave(&dev->lock, iflags); 1734 empty_req_queue(ep); 1735 ep->halted = 1; 1736 pch_udc_ep_disable(ep); --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
Re: [PATCH 1/2] usb: configfs: allow UDC binding rule configured as binding to *any* UDC
On Tue 2016-05-03 11:04:24, changbin...@intel.com wrote: > From: "Du, Changbin" > > On most platforms, there is only one device controller available. > In this case, we desn't care the UDC's name. So let's ignore the > name by setting 'UDC' to 'any'. And also we can change UDC name > at any time if it is not binded (no need set to "" first). making "any" special does not look like a good idea. What if it really is "any"? Return nothing instead, not even \n? > Signed-off-by: Du, Changbin > Signed-off-by: Du, Changbin I don't think this is how you should sign it off. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: EHCI fails to schedule large full-speed isochronous transfers
On Sat, Jun 04, 2016 at 08:32:43PM +0200, Michał Pecio wrote: > Hi, > > Why high-bandwidth USB 1.1 isochronous devices don't work on 2.0 hosts? > > I have an ADSL modem of this kind which I would like to use on a > companion-less 2.0 host in my router, but I can't because it fails with > ENOSPC errors. Same thing happens on my PC when connected through a 2.0 > hub, but it works perfectly on 1.1 and 3.0 hosts, with or without hubs. > > This seems to be an old and widely known issue, but the only "solution" > I found so far is "well, just don't use hubs and let the companion take > it over", which obviously doesn't solve the case of pure-EHCI SoCs. > > (Well, another solutions applicable to those particular modems is to > switch them to bulk mode, but it's slower.) > > Is this some limitation of the USB 2.0 spec or just a Linux issue? > > Any possible fixes or hackarounds? Don't use a 2.0 hub, or connect it directly as you have, or use a 3.0 controller :) Seriously, handling 1.1 transactions through a 2.0 hub is hard, and messy. It's been a known issue for decades, and given that 3.0 pretty much resolved most of these issues, no one is working to resolve them anymore, it's just so much simpler to change hardware. sorry, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unable to safely detach external HDD on USB 3.0
On 31/05/2016 16:34, Alan Stern wrote: On Tue, 31 May 2016, Mathias Nyman wrote: xhci specs say that port will move from Disconnected (PLS = RX_DETECT) to Polling if "SuperSpeed far-end receiver terminations are detected" From power-off state (PP=0) the connect status changes are only reported if OCA is set so it seems that is not an option. I'm looking at the capture log and if I understand it correcty, in frame 49 SET FEATURE, PLS = ss.disabled (xhci will write PORT_PED bit) 59 SET FEATURE, PLS = RxDetect (xhci will set pls=RxDetect) .. get_port_status, nothing set, no changes reported (several of these) 73 SET FEATURE -> Port remote wake mask .. get_port status reports Connected, enabled and port status change event Could it be that setting the port remote wake mask somehow triggers the connect status change event? It's the first time we write to PORTSC for this port after setting link state to rx.detect It's possible, but I doubt it. More likely it just takes a few hundred ms for the RxDetect link training to realize there is a connection. Marco, you can check whether this is true by doing (as root): echo on >/sys/bus/usb/devices/usb4/power/control before starting your test. Alan Stern Hi, Sorry for my late reply but I've been very busy this week. You can find the new captures in the same directory. Or just use the following direct links: https://drive.google.com/open?id=0B2tgr9hETOtgTEU1Qmc2eWNIYlE https://drive.google.com/open?id=0B2tgr9hETOtgZUV2TkZRRGJjMWs I could not notice any difference though. Anyway I'm happy to test patches if you want to try changes. Thank you, Marco -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
EHCI fails to schedule large full-speed isochronous transfers
Hi, Why high-bandwidth USB 1.1 isochronous devices don't work on 2.0 hosts? I have an ADSL modem of this kind which I would like to use on a companion-less 2.0 host in my router, but I can't because it fails with ENOSPC errors. Same thing happens on my PC when connected through a 2.0 hub, but it works perfectly on 1.1 and 3.0 hosts, with or without hubs. This seems to be an old and widely known issue, but the only "solution" I found so far is "well, just don't use hubs and let the companion take it over", which obviously doesn't solve the case of pure-EHCI SoCs. (Well, another solutions applicable to those particular modems is to switch them to bulk mode, but it's slower.) Is this some limitation of the USB 2.0 spec or just a Linux issue? Any possible fixes or hackarounds? Regards, MP -- 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: OHCI: NULL or LIST_POISON dereference on ueagle-atm disconnection
On Sat, Jun 04, 2016 at 10:05:27AM +0200, Michał Pecio wrote: > > Hi, I think I have a bug in the OHCI driver. > > > > Kernel version: 4.4.11 (some old 3.14 seems fine, didn't try others) > > 3.18.34 and 4.7-rc1 are affected too. > > The bug seems to have been introduced by "add I/O watchdog for orphan > TDs" (81e38333). I couldn't run bisect because those old kernels don't > build with gcc5+, but I started reverting commits to ohci-hcd.c and > ohci-q.hcd on top of 3.18.34 and got things to work at this point: > > commit 0831cb21003464f0764581fed26de83ac097d799 > Author: Michal Pecio > Date: Sat Jun 4 09:55:25 2016 +0200 > > Revert "USB: OHCI: add I/O watchdog for orphan TDs" > > This reverts commit 81e38333513cec155c720432226dabe9f9f76a77. > > commit cce8b2ec8e97a7c01fda1275e2a5732a1d0a1d88 > Author: Michal Pecio > Date: Sat Jun 4 09:53:58 2016 +0200 > > Revert "USB: OHCI: add check for stopped frame counter" > > This reverts commit 499b3803d3e2f062f73bf22372b38393369ffcbf. Alan, any ideas here? Michał, please always cc: the people who wrote the patches that you found problems with, makes things much easier :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] musb: sunxi: Remove bogus "Frees glue" comment
The comment is wrong, glue is devm_kzalloc-ed mem attached to the "allwinner,sun4i-a10-musb" compatible platform-dev. Where as glue->musb_pdev is a newly created "musb-hdrc" platform-dev. Signed-off-by: Hans de Goede --- drivers/usb/musb/sunxi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c index 4c2cbd0..a17eb2a 100644 --- a/drivers/usb/musb/sunxi.c +++ b/drivers/usb/musb/sunxi.c @@ -736,7 +736,7 @@ static int sunxi_musb_remove(struct platform_device *pdev) struct sunxi_glue *glue = platform_get_drvdata(pdev); struct platform_device *usb_phy = glue->usb_phy; - platform_device_unregister(glue->musb_pdev); /* Frees glue ! */ + platform_device_unregister(glue->musb_pdev); usb_phy_generic_unregister(usb_phy); return 0; -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] musb: sunxi: Fix NULL ptr deref when gadget is registered before musb
Stop using the return value of platform_device_register_full() to get to
the struct musb in sunxi_musb_work(). If a gadget has been registered
(insmod-ed) before the musb driver, then musb_start will get called
from the musb_core probe function and sunxi_musb_work() may run before
platform_device_register_full() has returned.
Instead store a pointer to struct musb in struct sunxi_glue when
sunxi_musb_enable gets called. Note that sunxi_musb_enable always gets
called before sunxi_musb_work() can run.
Signed-off-by: Hans de Goede
---
drivers/usb/musb/sunxi.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
index b88a2f6..4c2cbd0 100644
--- a/drivers/usb/musb/sunxi.c
+++ b/drivers/usb/musb/sunxi.c
@@ -80,7 +80,8 @@ static struct musb *sunxi_musb;
struct sunxi_glue {
struct device *dev;
- struct platform_device *musb;
+ struct musb *musb;
+ struct platform_device *musb_pdev;
struct clk *clk;
struct reset_control*rst;
struct phy *phy;
@@ -102,7 +103,7 @@ static void sunxi_musb_work(struct work_struct *work)
return;
if (test_and_clear_bit(SUNXI_MUSB_FL_HOSTMODE_PEND, &glue->flags)) {
- struct musb *musb = platform_get_drvdata(glue->musb);
+ struct musb *musb = glue->musb;
unsigned long flags;
u8 devctl;
@@ -314,6 +315,8 @@ static void sunxi_musb_enable(struct musb *musb)
{
struct sunxi_glue *glue = dev_get_drvdata(musb->controller->parent);
+ glue->musb = musb;
+
/* musb_core does not call us in a balanced manner */
if (test_and_set_bit(SUNXI_MUSB_FL_ENABLED, &glue->flags))
return;
@@ -714,9 +717,9 @@ static int sunxi_musb_probe(struct platform_device *pdev)
pinfo.data = &pdata;
pinfo.size_data = sizeof(pdata);
- glue->musb = platform_device_register_full(&pinfo);
- if (IS_ERR(glue->musb)) {
- ret = PTR_ERR(glue->musb);
+ glue->musb_pdev = platform_device_register_full(&pinfo);
+ if (IS_ERR(glue->musb_pdev)) {
+ ret = PTR_ERR(glue->musb_pdev);
dev_err(&pdev->dev, "Error registering musb dev: %d\n", ret);
goto err_unregister_usb_phy;
}
@@ -733,7 +736,7 @@ static int sunxi_musb_remove(struct platform_device *pdev)
struct sunxi_glue *glue = platform_get_drvdata(pdev);
struct platform_device *usb_phy = glue->usb_phy;
- platform_device_unregister(glue->musb); /* Frees glue ! */
+ platform_device_unregister(glue->musb_pdev); /* Frees glue ! */
usb_phy_generic_unregister(usb_phy);
return 0;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: EHCI: elide I/O watchdog on AMD parts
On Fri, 3 Jun 2016, Lucas Stach wrote:
> This removes 10 timer wakeups per second. I'm running this patch for
> a while now and haven't spotted any adverse effects.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/usb/host/ehci-pci.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
> index 3b3649d..0cec9f9 100644
> --- a/drivers/usb/host/ehci-pci.c
> +++ b/drivers/usb/host/ehci-pci.c
> @@ -263,6 +263,9 @@ static int ehci_pci_setup(struct usb_hcd *hcd)
> case PCI_VENDOR_ID_INTEL:
> ehci->need_io_watchdog = 0;
> break;
> + case PCI_VENDOR_ID_AMD:
> + ehci->need_io_watchdog = 0;
> + break;
> case PCI_VENDOR_ID_NVIDIA:
> switch (pdev->device) {
> /* MCP89 chips on the MacBookAir3,1 give EPROTO when
Please merge the PCI_VENDOR_ID_AMD case with the PCI_VENDOR_ID_INTEL
case.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
dwc2: Using internal phy (fs mode) for STM32F4x9 platform
Hello all, I'm bringing the linux kernel for the STM32F4 MCU (mmu-less). This MCU has two DWC2 cores on it:one for USB OTG HS and one for USB OTG FS. I was able to make the DWC2 driver to work in FS mode using a internal phy in both cores (HS and FS), but I had to patch it (in a bad way, see bellow). Basically STM32 uses a GGPIO register to control the POWER state of the internal phy as it describes in the reference manual: OTG general core configuration register (OTG_GCCFG) Address offset: 0x038 Reset value: 0x Powerdown -> BIT(16) Used to activate the transceiver in transmission/reception 0: Power down active 1: Power down deactivated (“Transceiver active”) So far what I did was in the dwc2_core_init + /* Program the GGPIO register */ + usbgpio = dwc2_readl(hsotg->regs + GGPIO); + usbgpio |= GGPIO_PWRDWN; + dwc2_writel(usbgpio, hsotg->regs + GGPIO); So I would like to check what would be you recommendation to implement in it in the right way. As it is a internal USB core register I could not find a way to implement a phy that access it. Syscon is also not the case (I guess) for the same reason. One way I thought would be to create a new property like: - snps,ggpio-reg: the value of GGPIO register for specific SoC/Vendor in my STM32 case could be something like that: snps,ggpio-reg = <0x10> The problem with this approach is that it could not be toggled "logicaly" from let say some phy on/off code. please share you thoughts on this. br., Bruno -- 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: OHCI: NULL or LIST_POISON dereference on ueagle-atm disconnection
> Hi, I think I have a bug in the OHCI driver. > > Kernel version: 4.4.11 (some old 3.14 seems fine, didn't try others) 3.18.34 and 4.7-rc1 are affected too. The bug seems to have been introduced by "add I/O watchdog for orphan TDs" (81e38333). I couldn't run bisect because those old kernels don't build with gcc5+, but I started reverting commits to ohci-hcd.c and ohci-q.hcd on top of 3.18.34 and got things to work at this point: commit 0831cb21003464f0764581fed26de83ac097d799 Author: Michal Pecio Date: Sat Jun 4 09:55:25 2016 +0200 Revert "USB: OHCI: add I/O watchdog for orphan TDs" This reverts commit 81e38333513cec155c720432226dabe9f9f76a77. commit cce8b2ec8e97a7c01fda1275e2a5732a1d0a1d88 Author: Michal Pecio Date: Sat Jun 4 09:53:58 2016 +0200 Revert "USB: OHCI: add check for stopped frame counter" This reverts commit 499b3803d3e2f062f73bf22372b38393369ffcbf. commit 3b6aa07b936b09d38c1bfcee1e06845b968df475 Author: Sasha Levin Date: Fri May 20 21:48:04 2016 -0400 Linux 3.18.34 Signed-off-by: Sasha Levin -- 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
