Fwd: Question about USB hotplug
Forward to USB mail alias for the USB question. Original post Subject: Question about USB hotplug Date: Sat, 14 Jun 2014 09:59:45 +0800 Sender: Simon Guo Receiver: kernelnewb...@kernelnewbies.org, wei.guo.si...@gmail.com Hi, dear list, I want to be clear about the USB hotplug procedure. I read "Linux Device Driver" and "Documentation/usb/hotplug.txt", and google much. Per my understanding, the USB hotplug works as following: 1) Insertion of physical U-disk will trigger a hardware interrupt. And interrupt handler (installed by USB bus driver?) will create kobj at /sys. 2) According to Linux device model, the creation of kobj will raise hotplug event (implemented in USB bus driver). 3) user space hotplug helper is invoked to handle hotplug event. Hotplug helper will read "modules.usbmaps" and decide to load which USB driver. If there are many drivers matching the device, they will all be loaded? 4) udev will create approparite dev under /dev according to rules defined. Please correct me if I am wrong in the above. I am using Ubuntu 11, and with my own build kernel version 3.15.0. Currently a new plugged USB disk can be recognized by my Ubuntu. But I didn't see "modules.usbmaps" file under /lib/modules/`uname -r` root@thunderCat:/mnt/data# ls /lib/modules/`uname -r` build modules.alias modules.builtin modules.dep modules.devname modules.softdep modules.symbols.bin kernel modules.alias.bin modules.builtin.bin modules.dep.bin modules.ordermodules.symbols source And there is no /proc/sys/kernel/hotplug root@thunderCat:/mnt/data# cat /proc/sys/kernel/hotplug root@thunderCat:/mnt/data# file /sbin/hotplug /sbin/hotplug: ERROR: cannot open `/sbin/hotplug' (No such file or directory) My Question is: 1) How can my Ubuntu hotplug work without "modules.usbmaps" and "/sbin/hotplug"? 2) Is there any tech I can use to "trace" the kernel/driver behavior of the USB hotplug procedure? (for example, kernel functions traversed) Thanks, Simon The config should have enabled HOTPLUG: root@thunderCat:/mnt/data# grep CONFIG_HOTPLUG /boot/config-`uname -r` CONFIG_HOTPLUG_CPU=y CONFIG_HOTPLUG_PCI_PCIE=y CONFIG_HOTPLUG_PCI=y # CONFIG_HOTPLUG_PCI_COMPAQ is not set # CONFIG_HOTPLUG_PCI_IBM is not set # CONFIG_HOTPLUG_PCI_ACPI is not set CONFIG_HOTPLUG_PCI_CPCI=y # CONFIG_HOTPLUG_PCI_CPCI_ZT5550 is not set # CONFIG_HOTPLUG_PCI_CPCI_GENERIC is not set # CONFIG_HOTPLUG_PCI_SHPC is not set -- 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
Greetings From Sivia
Greetings From Sivia Dear how are you today? and how is things moving with you? hope fine and you are in good health.My name is Sivia, I am looking for a very nice person of love, caring, sincere, easy going, matured, and understanding, i came across your Email today and decided to be in touch with you, so i will like you to write me via my email address which is as follow( siviab...@yahoo.com )so that i will give you my picture for further discussion, because i am really looking forward for a serious friendship with you, Yours New Sivia ( siviab...@yahoo.com ) -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/7] ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss
Hi Roger, On Mon, 5 May 2014, Roger Quadros wrote: > Add the sysconfig class bits for the Super Speed USB > controllers > > CC: Paul Walmsley > Signed-off-by: Roger Quadros As with the previous DRA7 hwmod patch, I'd like to get a Reviewed-by: and a Tested-by: before merging this one. - Paul -- 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
Announce libusb-1.0.19
Hi All, I'm happy to announce the libusb-1.0.19 final release. The big feature of this release is support for bulk-streams on Mac OS X and Linux (using the new usbfs API for this from 3.15). Changelog: * Add support for USB bulk streams on Linux and Mac OS X (#11) * Windows: Add AMD and Intel USB-3.0 root hub support * Windows: Fix USB 3.0 speed detection on Windows 8 or later (#10) * Added Russian translation for libusb_strerror strings * All: Various small fixes and cleanups The (#xx) numbers are libusb issue numbers, see ie: https://github.com/libusb/libusb/issues/11 nsfer caught by Coverity Go and grab it here: http://downloads.sourceforge.net/libusb/libusb-1.0.19.tar.bz2 Enjoy, Hans -- 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: [Dell Precision M3800] DisplayLink USB Graphics adapter not working
On Fri, Jun 13, 2014 at 08:30:53AM +0200, Bernhard Cygan wrote: > lsusb output: > > Bus 002 Device 002: ID 8087:8000 Intel Corp. > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 001 Device 002: ID 8087:8008 Intel Corp. > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > --- > Bus 004 Device 005: ID 17e9:4318 DisplayLink > --- > Bus 004 Device 004: ID 05e3:0612 Genesys Logic, Inc. > Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub > Bus 003 Device 005: ID 8087:07dc Intel Corp. > Bus 003 Device 004: ID 06cb:0ac3 Synaptics, Inc. > Bus 003 Device 016: ID 046a:0106 Cherry GmbH R-300 Wireless Mouse Receiver > Bus 003 Device 015: ID 1532:0013 Razer USA, Ltd Orochi mouse > Bus 003 Device 014: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub > Bus 003 Device 013: ID 05e3:0610 Genesys Logic, Inc. 4-port hub > Bus 003 Device 012: ID 05e3:0610 Genesys Logic, Inc. 4-port hub > Bus 003 Device 006: ID 0bda:573c Realtek Semiconductor Corp. > Bus 003 Device 002: ID 0424:7500 Standard Microsystems Corp. LAN7500 Ethernet > 10/100/1000 Adapter > Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > > The device providing the DisplayLink is a Dell USB 3.0 Docking Station, Model > D3000 Mfg ACP075EU Ah, yeah, that doesn't work with Linux, sorry :( > I already had a look at the displaylink.org and displaylink.com > websites. The information regarding Linux seems to be out of date. Is > there any documentation available that is relevant to Linux kernel >= > 3.13 ? Try asking displaylink, there's nothing we can do here without the specs for the devices. 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: ftdi_sio: add GPIO support
On Fri, Jun 13, 2014 at 09:25:07AM +0200, Linus Walleij wrote: > On Mon, Jun 9, 2014 at 3:21 PM, Sascha Silbe wrote: > > > The chips can operate either in regular or in bitbang mode. Care was > > taken to prevent using GPIOs if the serial device is in use and vice > > versa. > > Very interesting patch! I've seen USB-based GPIO things before > but never a dual-mode thing. > > There was already a comment to move the implementation to a > separate file, which I won't repeat. > > But I also want to bring the device model into question: normally > when a mother device spawns children across different subsystems > we model them as MFD devices (drivers/mfd) that instantiate > children for the different subsystems. So you could spawn a > serial and a GPIO device from a USB-based hub device there. > > I do not know if that is really apropriate in this case. It seems the > device is first and foremost FTDI. > > But it could still spawn a child platform device for the GPIO stuff > so that this can live as a separate driver under drivers/gpio/gpio-ftdi.c > or similar. > > You could then use something like: > > struct platform_device *gdev; Ick, no, it's a USB device, do not abuse the platform_device code any more than it currently is (note, I HATE the platform device code, someday I'll delete it entirely... Well, I can dream...) 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] usb: gadget: u_ether: synchronize with transmit when stopping queue
From: Jeff Westfahl When disconnecting, it's possible that another thread has already made it into eth_start_xmit before we call netif_stop_queue. This can lead to a crash as eth_start_xmit tries to use resources that gether_disconnect is freeing. Use netif_tx_lock/unlock around netif_stop_queue to ensure no threads are executing during the remainder of gether_disconnect. Signed-off-by: Jeff Westfahl Tested-by: Jaeden Amero --- drivers/usb/gadget/u_ether.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/gadget/u_ether.c b/drivers/usb/gadget/u_ether.c index b7d4f82..085a76e 100644 --- a/drivers/usb/gadget/u_ether.c +++ b/drivers/usb/gadget/u_ether.c @@ -1120,7 +1120,10 @@ void gether_disconnect(struct gether *link) DBG(dev, "%s\n", __func__); + netif_tx_lock(dev->net); netif_stop_queue(dev->net); + netif_tx_unlock(dev->net); + netif_carrier_off(dev->net); /* disable endpoints, forcing (synchronous) completion -- 1.7.9.5 -- 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 v6 1/1] usb: host: xhci-plat: add support for the R-Car H2 and M2 xHCI controllers
On 13/06/14 15:25, Felipe Balbi wrote:
> Hi,
>
>> + +#define FIRMWARE_NAME "r8a779x_usb3_v1.dlmem"
>> +MODULE_FIRMWARE(FIRMWARE_NAME);
Where can we get this from, it would be nice to test this.
>> +/*** Register Offset ***/ +#define RCAR_USB3_INT_ENA0x224 /*
>> Interrupt Enable */ +#define RCAR_USB3_DL_CTRL 0x250 /* FW
>> Download Control & Status */ +#define RCAR_USB3_FW_DATA0 0x258
>> /* FW Data0 */ + +#define RCAR_USB3_LCLK 0xa44 /* LCLK Select
>> */
>> +#define RCAR_USB3_CONF10xa48 /* USB3.0 Configuration1 */
>> +#define RCAR_USB3_CONF2 0xa5c /* USB3.0 Configuration2 */
>> +#define RCAR_USB3_CONF3 0xaa8 /* USB3.0 Configuration3 */
>> +#define RCAR_USB3_RX_POL0xab0 /* USB3.0 RX Polarity */
>> +#define RCAR_USB3_TX_POL0xab8 /* USB3.0 TX Polarity */ + +/***
>> Register Settings ***/ +/* Interrupt Enable */ +#define
>> RCAR_USB3_INT_XHC_ENA0x0001 +#define RCAR_USB3_INT_PME_ENA
>> 0x0002 +#define RCAR_USB3_INT_HSE_ENA0x0004 +#define
>> RCAR_USB3_INT_ENA_VAL(RCAR_USB3_INT_XHC_ENA | \ +
>> RCAR_USB3_INT_PME_ENA | RCAR_USB3_INT_HSE_ENA) + +/* FW Download
>> Control & Status */ +#define RCAR_USB3_DL_CTRL_ENABLE0x0001
>> +#define RCAR_USB3_DL_CTRL_FW_SUCCESS 0x0010 +#define
>> RCAR_USB3_DL_CTRL_FW_SET_DATA0 0x0100 + +/* LCLK Select */
>> +#define RCAR_USB3_LCLK_ENA_VAL 0x01030001 + +/* USB3.0
>> Configuration */ +#define RCAR_USB3_CONF1_VAL0x00030204
>> +#define RCAR_USB3_CONF2_VAL 0x00030300 +#define
>> RCAR_USB3_CONF3_VAL 0x13802007 + +/* USB3.0 Polarity */ +#define
>> RCAR_USB3_RX_POL_VAL BIT(21) +#define RCAR_USB3_TX_POL_VAL BIT(4)
>> + +void xhci_rcar_start(struct usb_hcd *hcd) +{ +u32 temp; + +
>> if (hcd->regs != NULL) { + /* Interrupt Enable */ +
>> temp =
>> readl(hcd->regs + RCAR_USB3_INT_ENA); + temp |=
>> RCAR_USB3_INT_ENA_VAL; + writel(temp, hcd->regs +
>> RCAR_USB3_INT_ENA); +/* LCLK Select */ +
>> writel(RCAR_USB3_LCLK_ENA_VAL, hcd->regs + RCAR_USB3_LCLK); +
>> /* USB3.0 Configuration */ + writel(RCAR_USB3_CONF1_VAL,
>> hcd->regs + RCAR_USB3_CONF1); + writel(RCAR_USB3_CONF2_VAL,
>> hcd->regs + RCAR_USB3_CONF2); + writel(RCAR_USB3_CONF3_VAL,
>> hcd->regs + RCAR_USB3_CONF3); + /* USB3.0 Polarity */ +
>> writel(RCAR_USB3_RX_POL_VAL, hcd->regs + RCAR_USB3_RX_POL); +
>> writel(RCAR_USB3_TX_POL_VAL, hcd->regs + RCAR_USB3_TX_POL); +}
>> +} + +static int xhci_rcar_download_firmware(struct device *dev,
>> void __iomem *regs) +{ + const struct firmware *fw; +int
>> retval, index, j, time; +int timeout = 1; + u32 data, val,
>> temp; + + /* request R-Car USB3.0 firmware */ + retval =
>> request_firmware(&fw, FIRMWARE_NAME, dev); + if (retval) + return
>> retval; + + /* download R-Car USB3.0 firmware */ + temp =
>> readl(regs + RCAR_USB3_DL_CTRL); + temp |=
>> RCAR_USB3_DL_CTRL_ENABLE; + writel(temp, regs +
>> RCAR_USB3_DL_CTRL); + + for (index = 0; index < fw->size; index
>> += 4) { +/* to avoid reading beyond the end of the buffer */ +
>> for (data = 0, j = 3; j >= 0; j--) { + if ((j + index)
>> <
>> fw->size) + data |= fw->data[index + j] << (8 * j);
>> + } +
>> writel(data, regs + RCAR_USB3_FW_DATA0); + temp = readl(regs +
>> RCAR_USB3_DL_CTRL); +temp |= RCAR_USB3_DL_CTRL_FW_SET_DATA0;
>> +
>> writel(temp, regs + RCAR_USB3_DL_CTRL); + + for (time = 0; time
>> < timeout; time++) { + val = readl(regs +
>> RCAR_USB3_DL_CTRL);
>> + if ((val & RCAR_USB3_DL_CTRL_FW_SET_DATA0) == 0) +
>> break; +
>> udelay(1); + } + if (time == timeout) { +
>> retval =
>> -ETIMEDOUT; +break; +} + } + +
>> temp = readl(regs +
>> RCAR_USB3_DL_CTRL); +temp &= ~RCAR_USB3_DL_CTRL_ENABLE; +
>> writel(temp, regs + RCAR_USB3_DL_CTRL); + + for (time = 0; time
>> < timeout; time++) { + val = readl(regs + RCAR_USB3_DL_CTRL);
>> +
>> if (val & RCAR_USB3_DL_CTRL_FW_SUCCESS) { + retval = 0; +
>> break; + } + udelay(1); +} + if (time ==
>> timeout) + retval =
>> -ETIMEDOUT; + + release_firmware(fw); + + return retval; +} +
>> +/* This function needs to initialize a "phy" of usb before */
>
> initializing a PHY looks like something that the PHY layer should
> do. Why don't you write a PHY driver and teach xhci-core about
> PHYs ? Then, more people would benefit.
The rcar phy code should already do this, so I agree.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer C
Re: [PATCH v5] leds: USB: HID: Add support for MSI GT683R led panels
> Ok, so you decided to continue setting mode on every LED brightness > update. That should be fine, but you never answered my question about > whether it is necessary? I decided to do it that way because official driver did it as well. I can check if it is necessary. > You're almost done. One last update? :) Yeah, I hope so :) -- 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 v3] USB:gadget: Fix a warning while loading g_mass_storage
On Fri, Jun 13 2014, Alan Stern wrote: > On Fri, 13 Jun 2014, Michal Nazarewicz wrote: > >> > The root cause is that the existing code fails to take into >> > account the possibility that common->new_fsg can change while >> > do_set_interface() is running, because the spinlock isn't held >> > at this point. >> >> common->new_fsg is not protected by common->lock so this justification >> is not valid. > > That's true. A better justification would be that the same value of > new_fsg should be used in do_set_interface() and in the test that > follows. > >> > @@ -2421,6 +2422,7 @@ static void handle_exception(struct fsg_common >> > *common) >> >} >> >common->state = FSG_STATE_IDLE; >> >} >> > + new_fsg = common->new_fsg; >> >> Also, because common->new_fsg is not protected by common->lock, doing >> this under a lock is kinda pointless. > > Yes, but it doesn't hurt. > >> >spin_unlock_irq(&common->lock); >> > >> >/* Carry out any extra actions required for the exception */ >> > @@ -2460,8 +2462,8 @@ static void handle_exception(struct fsg_common >> > *common) >> >break; >> > >> >case FSG_STATE_CONFIG_CHANGE: >> > - do_set_interface(common, common->new_fsg); >> > - if (common->new_fsg) >> > + do_set_interface(common, new_fsg); >> > + if (new_fsg) >> >usb_composite_setup_continue(common->cdev); >> >> As far as I can tell, it's safe to move the assignment to new_fsg here, >> e.g.: >> >> new_fsg = common->new_fsg; >> do_set_interface(common, new_fsg); >> if (new_fsg) >> usb_composite_setup_continue(common->cdev); > > That would be equally correct. I don't see any strong reason for > preferring one over the other. Doing the read under the lock may give an impression that the value is indeed protected by the lock. Doing it outside of the lock creates no such confusion. Therefore, I would prefer having the read outside. But no strong feelings. >> >break; >> >> But perhaps new_fsg should be protected by the lock. I think valid fix >> (which I did not test in *any* way) will be this: > No, I think this change is both too big and unnecessary. > common->new_fsg does not need protection; in a sense it is "owned" by > the composite driver. No strong feelings on my side. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +--ooO--(_)--Ooo-- -- 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 v6 1/1] usb: host: xhci-plat: add support for the R-Car H2 and M2 xHCI controllers
Hi,
On Fri, Jun 13, 2014 at 09:20:31PM +0900, Yoshihiro Shimoda wrote:
> The R-Car H2 and M2 SoCs come with an xHCI controller that requires
> some specific initializations related to the firmware downloading and
> some specific registers. This patch adds the support for this special
> configuration as an xHCI quirk executed during probe and start.
>
> Signed-off-by: Yoshihiro Shimoda
> ---
> drivers/usb/host/Kconfig |8 +++
> drivers/usb/host/Makefile|3 +
> drivers/usb/host/xhci-plat.c | 19 ++
> drivers/usb/host/xhci-rcar.c | 148
> ++
> drivers/usb/host/xhci-rcar.h | 27
> 5 files changed, 205 insertions(+)
> create mode 100644 drivers/usb/host/xhci-rcar.c
> create mode 100644 drivers/usb/host/xhci-rcar.h
>
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index 61b7817..537d9e1 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -37,6 +37,14 @@ config USB_XHCI_MVEBU
> Say 'Y' to enable the support for the xHCI host controller
> found in Marvell Armada 375/38x ARM SOCs.
>
> +config USB_XHCI_RCAR
> + tristate "xHCI support for Renesas R-Car SoCs"
> + select USB_XHCI_PLATFORM
> + depends on ARCH_SHMOBILE || COMPILE_TEST
> + ---help---
> + Say 'Y' to enable the support for the xHCI host controller
> + found in Renesas R-Car ARM SoCs.
> +
> endif # USB_XHCI_HCD
>
> config USB_EHCI_HCD
> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
> index af89a90..144c038 100644
> --- a/drivers/usb/host/Makefile
> +++ b/drivers/usb/host/Makefile
> @@ -22,6 +22,9 @@ ifneq ($(CONFIG_USB_XHCI_PLATFORM), )
> ifneq ($(CONFIG_USB_XHCI_MVEBU), )
> xhci-hcd-y += xhci-mvebu.o
> endif
> +ifneq ($(CONFIG_USB_XHCI_RCAR), )
> + xhci-hcd-y += xhci-rcar.o
> +endif
> endif
>
> obj-$(CONFIG_USB_WHCI_HCD) += whci/
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 29d8adb..b6f2b6b 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -20,6 +20,7 @@
>
> #include "xhci.h"
> #include "xhci-mvebu.h"
> +#include "xhci-rcar.h"
>
> static void xhci_plat_quirks(struct device *dev, struct xhci_hcd *xhci)
> {
> @@ -34,11 +35,27 @@ static void xhci_plat_quirks(struct device *dev, struct
> xhci_hcd *xhci)
> /* called during probe() after chip reset completes */
> static int xhci_plat_setup(struct usb_hcd *hcd)
> {
> + struct device_node *of_node = hcd->self.controller->of_node;
> + int ret;
> +
> + if (of_device_is_compatible(of_node, "renesas,xhci-r8a7790") ||
> + of_device_is_compatible(of_node, "renesas,xhci-r8a7791")) {
> + ret = xhci_rcar_init_quirk(hcd);
> + if (ret)
> + return ret;
> + }
> +
> return xhci_gen_setup(hcd, xhci_plat_quirks);
> }
>
> static int xhci_plat_start(struct usb_hcd *hcd)
> {
> + struct device_node *of_node = hcd->self.controller->of_node;
> +
> + if (of_device_is_compatible(of_node, "renesas,xhci-r8a7790") ||
> + of_device_is_compatible(of_node, "renesas,xhci-r8a7791"))
> + xhci_rcar_start(hcd);
> +
> return xhci_run(hcd);
> }
>
> @@ -270,6 +287,8 @@ static const struct of_device_id usb_xhci_of_match[] = {
> { .compatible = "xhci-platform" },
> { .compatible = "marvell,armada-375-xhci"},
> { .compatible = "marvell,armada-380-xhci"},
> + { .compatible = "renesas,xhci-r8a7790"},
> + { .compatible = "renesas,xhci-r8a7791"},
> { },
> };
> MODULE_DEVICE_TABLE(of, usb_xhci_of_match);
> diff --git a/drivers/usb/host/xhci-rcar.c b/drivers/usb/host/xhci-rcar.c
> new file mode 100644
> index 000..ff0d1b4
> --- /dev/null
> +++ b/drivers/usb/host/xhci-rcar.c
> @@ -0,0 +1,148 @@
> +/*
> + * xHCI host controller driver for R-Car SoCs
> + *
> + * Copyright (C) 2014 Renesas Electronics Corporation
> + *
> + * 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 "xhci.h"
> +#include "xhci-rcar.h"
> +
> +#define FIRMWARE_NAME"r8a779x_usb3_v1.dlmem"
> +MODULE_FIRMWARE(FIRMWARE_NAME);
> +
> +/*** Register Offset ***/
> +#define RCAR_USB3_INT_ENA0x224 /* Interrupt Enable */
> +#define RCAR_USB3_DL_CTRL0x250 /* FW Download Control & Status */
> +#define RCAR_USB3_FW_DATA0 0x258 /* FW Data0 */
> +
> +#define RCAR_USB3_LCLK 0xa44 /* LCLK Select */
> +#define RCAR_USB3_CONF1 0xa48 /* USB3.0 Configuration1 */
> +#define RCAR_USB3_CONF2 0xa5c /* USB3.0 Configuration2 */
> +#define RCAR_USB3_CONF3 0xaa8 /* USB3.0 Configuration3 */
> +#define RCAR_USB3_RX_POL 0xab0 /* USB3.0 RX Polarit
Re: [PATCHv4 6/6] usb: gadget: f_mass_storage: Fix a warning while loading g_mass_storage
On Fri, 13 Jun 2014, Michal Nazarewicz wrote: > While loading g_mass_storage module, the following warning can > trigger: > > WARNING: at drivers/usb/gadget/composite.c: > usb_composite_setup_continue: Unexpected call > Modules linked in: fat vfat minix nls_cp437 nls_iso8859_1 g_mass_storage > [<800179cc>] (unwind_backtrace+0x0/0x104) from [<80619608>] > (dump_stack+0x20/0x24) > [<80619608>] (dump_stack+0x20/0x24) from [<80025100>] > (warn_slowpath_common+0x64/0x74) > [<80025100>] (warn_slowpath_common+0x64/0x74) from [<800251cc>] > (warn_slowpath_fmt+0x40/0x48) > [<800251cc>] (warn_slowpath_fmt+0x40/0x48) from [<7f047774>] > (usb_composite_setup_continue+0xb4/0xbc [g_mass_storage]) > [<7f047774>] (usb_composite_setup_continue+0xb4/0xbc [g_mass_storage]) from > [<7f047ad4>] (handle_exception+0x358/0x3e4 [g_mass_storage]) > [<7f047ad4>] (handle_exception+0x358/0x3e4 [g_mass_storage]) from > [<7f048080>] (fsg_main_thread+0x520/0x157c [g_mass_storage]) > [<7f048080>] (fsg_main_thread+0x520/0x157c [g_mass_storage]) from > [<8004bc90>] (kthread+0x98/0x9c) > [<8004bc90>] (kthread+0x98/0x9c) from [<8000faec>] > (kernel_thread_exit+0x0/0x8) > > The root cause is that the existing code fails to take into account > the possibility that common->new_fsg can change while > do_set_interface() is running, because the spinlock does not protect > it. > > Change the code so that the common->new_fsg field is protected by the > common->lock spin lock. NAK. common->new_fsg does not need to be protected. Wei's patch is much simpler and will work well. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Disable bus's drivers_autoprobe before rootfs has mounted
On Fri, 13 Jun 2014, Peter Chen wrote:
> OK, we can keep our g_xxx gadget driver just support the basic feature. But
> the bug that causes gadget driver load fail due to udc is probed deferral
> should
> be fixed, do you think so, we can't wait until configfs has total been ready.
That problem has always existed. There never has been a time when a
gadget driver could be loaded before the UDC driver was ready. Does it
really need to be fixed now?
If you do want to fix the problem, there's a much easier way than what
you posted. See below.
Alan Stern
Index: usb-3.15/include/linux/usb/gadget.h
===
--- usb-3.15.orig/include/linux/usb/gadget.h
+++ usb-3.15/include/linux/usb/gadget.h
@@ -821,6 +821,7 @@ static inline int usb_gadget_disconnect(
* @suspend: Invoked on USB suspend. May be called in_interrupt.
* @resume: Invoked on USB resume. May be called in_interrupt.
* @driver: Driver model state for this driver.
+ * @probe_list: List of drivers waiting to be probed.
*
* Devices are disabled till a gadget driver successfully bind()s, which
* means the driver will handle setup() requests needed to enumerate (and
@@ -881,6 +882,7 @@ struct usb_gadget_driver {
/* FIXME support safe rmmod */
struct device_driverdriver;
+ struct list_headprobe_list;
};
Index: usb-3.15/drivers/usb/gadget/udc-core.c
===
--- usb-3.15.orig/drivers/usb/gadget/udc-core.c
+++ usb-3.15/drivers/usb/gadget/udc-core.c
@@ -47,8 +47,12 @@ struct usb_udc {
static struct class *udc_class;
static LIST_HEAD(udc_list);
+static LIST_HEAD(pending_drivers);
static DEFINE_MUTEX(udc_lock);
+static int udc_bind_to_driver(struct usb_udc *udc,
+ struct usb_gadget_driver *driver);
+
/* - */
#ifdef CONFIG_HAS_DMA
@@ -242,6 +246,15 @@ int usb_add_gadget_udc_release(struct de
usb_gadget_set_state(gadget, USB_STATE_NOTATTACHED);
+ while (!list_empty(&pending_drivers)) {
+ struct usb_gadget_driver *driver;
+
+ driver = list_first_entry(&pending_drivers,
+ struct usb_gadget_driver, probe_list);
+ if (udc_bind_to_driver(udc, driver) == 0)
+ break;
+ }
+
mutex_unlock(&udc_lock);
return 0;
@@ -338,6 +351,7 @@ static int udc_bind_to_driver(struct usb
dev_dbg(&udc->dev, "registering UDC driver [%s]\n",
driver->function);
+ list_del_init(&driver->probe_list);
udc->driver = driver;
udc->dev.driver = &driver->driver;
@@ -400,6 +414,7 @@ int usb_gadget_probe_driver(struct usb_g
return -EINVAL;
mutex_lock(&udc_lock);
+ INIT_LIST_HEAD(&driver->probe_list);
list_for_each_entry(udc, &udc_list, list) {
/* For now we take the first one */
if (!udc->driver)
@@ -407,8 +422,9 @@ int usb_gadget_probe_driver(struct usb_g
}
pr_debug("couldn't find an available UDC\n");
+ list_add_tail(&driver->probe_list, &pending_drivers);
mutex_unlock(&udc_lock);
- return -ENODEV;
+ return 0;
found:
ret = udc_bind_to_driver(udc, driver);
mutex_unlock(&udc_lock);
@@ -425,6 +441,7 @@ int usb_gadget_unregister_driver(struct
return -EINVAL;
mutex_lock(&udc_lock);
+ list_del(&driver->probe_list);
list_for_each_entry(udc, &udc_list, list)
if (udc->driver == driver) {
usb_gadget_remove_driver(udc);
--
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 v3] USB:gadget: Fix a warning while loading g_mass_storage
On Fri, 13 Jun 2014, Michal Nazarewicz wrote: > > The root cause is that the existing code fails to take into > > account the possibility that common->new_fsg can change while > > do_set_interface() is running, because the spinlock isn't held > > at this point. > > common->new_fsg is not protected by common->lock so this justification > is not valid. That's true. A better justification would be that the same value of new_fsg should be used in do_set_interface() and in the test that follows. > > @@ -2421,6 +2422,7 @@ static void handle_exception(struct fsg_common > > *common) > > } > > common->state = FSG_STATE_IDLE; > > } > > + new_fsg = common->new_fsg; > > Also, because common->new_fsg is not protected by common->lock, doing > this under a lock is kinda pointless. Yes, but it doesn't hurt. > > spin_unlock_irq(&common->lock); > > > > /* Carry out any extra actions required for the exception */ > > @@ -2460,8 +2462,8 @@ static void handle_exception(struct fsg_common > > *common) > > break; > > > > case FSG_STATE_CONFIG_CHANGE: > > - do_set_interface(common, common->new_fsg); > > - if (common->new_fsg) > > + do_set_interface(common, new_fsg); > > + if (new_fsg) > > usb_composite_setup_continue(common->cdev); > > As far as I can tell, it's safe to move the assignment to new_fsg here, > e.g.: > > new_fsg = common->new_fsg; > do_set_interface(common, new_fsg); > if (new_fsg) > usb_composite_setup_continue(common->cdev); That would be equally correct. I don't see any strong reason for preferring one over the other. > > break; > > But perhaps new_fsg should be protected by the lock. I think valid fix > (which I did not test in *any* way) will be this: No, I think this change is both too big and unnecessary. common->new_fsg does not need protection; in a sense it is "owned" by the composite driver. 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
[PATCHv4 4/6] tools: ffs-test: convert to new descriptor format
Since commit [ac8dde11: “Add flags to descriptors block”] functionfs
supports a new, more powerful and extensible, descriptor format.
Since ffs-test is probably the first thing users of the functionfs
interface see when they start writing functionfs user space daemons,
convert it to use the new format thus promoting it.
Signed-off-by: Michal Nazarewicz
---
include/uapi/linux/usb/functionfs.h | 2 +-
tools/usb/ffs-test.c| 14 +-
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/include/uapi/linux/usb/functionfs.h
b/include/uapi/linux/usb/functionfs.h
index 2592d86..1dc473a 100644
--- a/include/uapi/linux/usb/functionfs.h
+++ b/include/uapi/linux/usb/functionfs.h
@@ -70,7 +70,7 @@ struct usb_functionfs_descs_head {
* structure. Any flags that are not recognised cause the whole block to be
* rejected with -ENOSYS.
*
- * Legacy descriptors format:
+ * Legacy descriptors format (deprecated as of 3.14):
*
* | off | name | type | description |
* |-+---+--+--|
diff --git a/tools/usb/ffs-test.c b/tools/usb/ffs-test.c
index a87e99f..708d317 100644
--- a/tools/usb/ffs-test.c
+++ b/tools/usb/ffs-test.c
@@ -1,5 +1,5 @@
/*
- * ffs-test.c.c -- user mode filesystem api for usb composite function
+ * ffs-test.c -- user mode filesystem api for usb composite function
*
* Copyright (C) 2010 Samsung Electronics
*Author: Michal Nazarewicz
@@ -106,7 +106,9 @@ static void _msg(unsigned level, const char *fmt, ...)
/ Descriptors and Strings ***/
static const struct {
- struct usb_functionfs_descs_head header;
+ struct usb_functionfs_descs_head_v2 header;
+ __le32 fs_count;
+ __le32 hs_count;
struct {
struct usb_interface_descriptor intf;
struct usb_endpoint_descriptor_no_audio sink;
@@ -114,11 +116,12 @@ static const struct {
} __attribute__((packed)) fs_descs, hs_descs;
} __attribute__((packed)) descriptors = {
.header = {
- .magic = cpu_to_le32(FUNCTIONFS_DESCRIPTORS_MAGIC),
+ .magic = cpu_to_le32(FUNCTIONFS_DESCRIPTORS_MAGIC_V2),
+ .flags = cpu_to_le32(FUNCTIONFS_HAS_FS_DESC |
+FUNCTIONFS_HAS_HS_DESC),
.length = cpu_to_le32(sizeof descriptors),
- .fs_count = cpu_to_le32(3),
- .hs_count = cpu_to_le32(3),
},
+ .fs_count = cpu_to_le32(3),
.fs_descs = {
.intf = {
.bLength = sizeof descriptors.fs_descs.intf,
@@ -142,6 +145,7 @@ static const struct {
/* .wMaxPacketSize = autoconfiguration (kernel) */
},
},
+ .hs_count = cpu_to_le32(3),
.hs_descs = {
.intf = {
.bLength = sizeof descriptors.fs_descs.intf,
--
2.0.0.526.g5318336
--
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
[PATCHv4 3/6] usb: gadget: f_fs: add usb_functionfs_descs_head_v2 structure
The structure can be used with user space tools that use the new
functionfs description format, for example as follows:
static const struct {
struct usb_functionfs_descs_head_v2 header;
__le32 fs_count;
__le32 hs_count;
struct {
…
} fs_desc;
struct {
…
} hs_desc;
} descriptors = {
.header = {
.magic = cpu_to_le32(FUNCTIONFS_DESCRIPTORS_MAGIC_V2),
.length = cpu_to_le32(sizeof(descriptors)),
.flags = cpu_to_le32(FUNCTIONFS_HAS_FS_DESC |
FUNCTIONFS_HAS_HS_DESC)
},
.fs_count = cpu_to_le32(X),
.fs_desc = {
…
},
.hs_count = cpu_to_le32(Y),
.hs_desc = {
…
}
};
Signed-off-by: Michal Nazarewicz
---
include/uapi/linux/usb/functionfs.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/uapi/linux/usb/functionfs.h
b/include/uapi/linux/usb/functionfs.h
index 24b68c5..2592d86 100644
--- a/include/uapi/linux/usb/functionfs.h
+++ b/include/uapi/linux/usb/functionfs.h
@@ -33,6 +33,16 @@ struct usb_endpoint_descriptor_no_audio {
__u8 bInterval;
} __attribute__((packed));
+struct usb_functionfs_descs_head_v2 {
+ __le32 magic;
+ __le32 length;
+ __le32 flags;
+ /*
+* __le32 fs_count, hs_count, fs_count; must be included manually in
+* the structure taking flags into consideration.
+*/
+} __attribute__((packed));
+
/* Legacy format, deprecated as of 3.14. */
struct usb_functionfs_descs_head {
__le32 magic;
--
2.0.0.526.g5318336
--
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
[PATCHv4 6/6] usb: gadget: f_mass_storage: Fix a warning while loading g_mass_storage
While loading g_mass_storage module, the following warning can
trigger:
WARNING: at drivers/usb/gadget/composite.c:
usb_composite_setup_continue: Unexpected call
Modules linked in: fat vfat minix nls_cp437 nls_iso8859_1 g_mass_storage
[<800179cc>] (unwind_backtrace+0x0/0x104) from [<80619608>]
(dump_stack+0x20/0x24)
[<80619608>] (dump_stack+0x20/0x24) from [<80025100>]
(warn_slowpath_common+0x64/0x74)
[<80025100>] (warn_slowpath_common+0x64/0x74) from [<800251cc>]
(warn_slowpath_fmt+0x40/0x48)
[<800251cc>] (warn_slowpath_fmt+0x40/0x48) from [<7f047774>]
(usb_composite_setup_continue+0xb4/0xbc [g_mass_storage])
[<7f047774>] (usb_composite_setup_continue+0xb4/0xbc [g_mass_storage]) from
[<7f047ad4>] (handle_exception+0x358/0x3e4 [g_mass_storage])
[<7f047ad4>] (handle_exception+0x358/0x3e4 [g_mass_storage]) from [<7f048080>]
(fsg_main_thread+0x520/0x157c [g_mass_storage])
[<7f048080>] (fsg_main_thread+0x520/0x157c [g_mass_storage]) from [<8004bc90>]
(kthread+0x98/0x9c)
[<8004bc90>] (kthread+0x98/0x9c) from [<8000faec>] (kernel_thread_exit+0x0/0x8)
The root cause is that the existing code fails to take into account
the possibility that common->new_fsg can change while
do_set_interface() is running, because the spinlock does not protect
it.
Change the code so that the common->new_fsg field is protected by the
common->lock spin lock.
Reported-by: Yang Wei
Signed-off-by: Michal Nazarewicz
---
drivers/usb/gadget/f_mass_storage.c | 54 +++--
1 file changed, 34 insertions(+), 20 deletions(-)
diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_mass_storage.c
index b963939..bd663c2 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -264,7 +264,7 @@ struct fsg_common {
/* filesem protects: backing files in use */
struct rw_semaphore filesem;
- /* lock protects: state, all the req_busy's */
+ /* lock protects: state, all the req_busy's, and new_fsg */
spinlock_t lock;
struct usb_ep *ep0; /* Copy of gadget->ep0 */
@@ -407,23 +407,39 @@ static void wakeup_thread(struct fsg_common *common)
wake_up_process(common->thread_task);
}
-static void raise_exception(struct fsg_common *common, enum fsg_state
new_state)
+static void __raise_exception(struct fsg_common *common,
+ enum fsg_state new_state)
{
- unsigned long flags;
-
/*
* Do nothing if a higher-priority exception is already in progress.
* If a lower-or-equal priority exception is in progress, preempt it
* and notify the main thread by sending it a signal.
*/
+ if (common->state > new_state)
+ return;
+
+ common->exception_req_tag = common->ep0_req_tag;
+ common->state = new_state;
+ if (common->thread_task)
+ send_sig_info(SIGUSR1, SEND_SIG_FORCED, common->thread_task);
+}
+
+static void raise_exception(struct fsg_common *common, enum fsg_state
new_state)
+{
+ unsigned long flags;
spin_lock_irqsave(&common->lock, flags);
- if (common->state <= new_state) {
- common->exception_req_tag = common->ep0_req_tag;
- common->state = new_state;
- if (common->thread_task)
- send_sig_info(SIGUSR1, SEND_SIG_FORCED,
- common->thread_task);
- }
+ __raise_exception(common, new_state);
+ spin_unlock_irqrestore(&common->lock, flags);
+}
+
+static void raise_config_change_exception(struct fsg_common *common,
+ struct fsg_dev *new_fsg)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&common->lock, flags);
+ common->new_fsg = new_fsg;
+ __raise_exception(common, FSG_STATE_CONFIG_CHANGE);
spin_unlock_irqrestore(&common->lock, flags);
}
@@ -2320,16 +2336,14 @@ reset:
static int fsg_set_alt(struct usb_function *f, unsigned intf, unsigned alt)
{
struct fsg_dev *fsg = fsg_from_func(f);
- fsg->common->new_fsg = fsg;
- raise_exception(fsg->common, FSG_STATE_CONFIG_CHANGE);
+ raise_config_change_exception(fsg->common, fsg);
return USB_GADGET_DELAYED_STATUS;
}
static void fsg_disable(struct usb_function *f)
{
struct fsg_dev *fsg = fsg_from_func(f);
- fsg->common->new_fsg = NULL;
- raise_exception(fsg->common, FSG_STATE_CONFIG_CHANGE);
+ raise_config_change_exception(fsg->common, NULL);
}
@@ -2342,6 +2356,7 @@ static void handle_exception(struct fsg_common *common)
struct fsg_buffhd *bh;
enum fsg_state old_state;
struct fsg_lun *curlun;
+ struct fsg_dev *new_fsg;
unsigned intexception_req_tag;
/*
@@ -2405,6 +2420,7 @@ static void handle_exception(struct fsg_c
[PATCHv4 5/6] tools: ffs-test: add compatibility code for old kernels
If ffs-test is used with a kernel prior to 3.14, which do not
support the new descriptors format, it will fail when trying to
write the descriptors. Add a function that converts the new
descriptors to the legacy ones and use it to retry writing the
descriptors using the legacy format.
Also add “-l” flag to ffs-test which will cause the tool to
never try the new format and instead immediatelly try the
legacy one. This should be useful to test whether parsing
of the old format still works on given 3.14+ kernel.
Signed-off-by: Michal Nazarewicz
---
tools/usb/ffs-test.c | 110 ---
1 file changed, 105 insertions(+), 5 deletions(-)
diff --git a/tools/usb/ffs-test.c b/tools/usb/ffs-test.c
index 708d317..88d5e71 100644
--- a/tools/usb/ffs-test.c
+++ b/tools/usb/ffs-test.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -172,6 +173,89 @@ static const struct {
},
};
+static size_t descs_to_legacy(void **legacy, const void *descriptors_v2)
+{
+ const unsigned char *descs_end, *descs_start;
+ __u32 length, fs_count = 0, hs_count = 0, count;
+
+ /* Read v2 header */
+ {
+ const struct {
+ const struct usb_functionfs_descs_head_v2 header;
+ const __le32 counts[];
+ } __attribute__((packed)) *const in = descriptors_v2;
+ const __le32 *counts = in->counts;
+ __u32 flags;
+
+ if (le32_to_cpu(in->header.magic) !=
+ FUNCTIONFS_DESCRIPTORS_MAGIC_V2)
+ return 0;
+ length = le32_to_cpu(in->header.length);
+ if (length <= sizeof in->header)
+ return 0;
+ length -= sizeof in->header;
+ flags = le32_to_cpu(in->header.flags);
+ if (flags & ~(FUNCTIONFS_HAS_FS_DESC | FUNCTIONFS_HAS_HS_DESC |
+ FUNCTIONFS_HAS_SS_DESC))
+ return 0;
+
+#define GET_NEXT_COUNT_IF_FLAG(ret, flg) do { \
+ if (!(flags & (flg))) \
+ break; \
+ if (length < 4) \
+ return 0; \
+ ret = le32_to_cpu(*counts); \
+ length -= 4;\
+ ++counts; \
+ } while (0)
+
+ GET_NEXT_COUNT_IF_FLAG(fs_count, FUNCTIONFS_HAS_FS_DESC);
+ GET_NEXT_COUNT_IF_FLAG(hs_count, FUNCTIONFS_HAS_HS_DESC);
+ GET_NEXT_COUNT_IF_FLAG(count, FUNCTIONFS_HAS_SS_DESC);
+
+ count = fs_count + hs_count;
+ if (!count)
+ return 0;
+ descs_start = (const void *)counts;
+
+#undef GET_NEXT_COUNT_IF_FLAG
+ }
+
+ /*
+* Find the end of FS and HS USB descriptors. SS descriptors
+* are ignored since legacy format does not support them.
+*/
+ descs_end = descs_start;
+ do {
+ if (length < *descs_end)
+ return 0;
+ length -= *descs_end;
+ descs_end += *descs_end;
+ } while (--count);
+
+ /* Allocate legacy descriptors and copy the data. */
+ {
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
+ struct {
+ struct usb_functionfs_descs_head header;
+ __u8 descriptors[];
+ } __attribute__((packed)) *out;
+#pragma GCC diagnostic pop
+
+ length = sizeof out->header + (descs_end - descs_start);
+ out = malloc(length);
+ out->header.magic = cpu_to_le32(FUNCTIONFS_DESCRIPTORS_MAGIC);
+ out->header.length = cpu_to_le32(length);
+ out->header.fs_count = cpu_to_le32(fs_count);
+ out->header.hs_count = cpu_to_le32(hs_count);
+ memcpy(out->descriptors, descs_start, descs_end - descs_start);
+ *legacy = out;
+ }
+
+ return length;
+}
+
#define STR_INTERFACE_ "Source/Sink"
@@ -491,12 +575,29 @@ ep0_consume(struct thread *ignore, const void *buf,
size_t nbytes)
return nbytes;
}
-static void ep0_init(struct thread *t)
+static void ep0_init(struct thread *t, bool legacy_descriptors)
{
+ void *legacy;
ssize_t ret;
+ size_t len;
+
+ if (legacy_descriptors) {
+ info("%s: writing descriptors\n", t->filename);
+ goto legacy;
+ }
- info("%s: writing descriptors\n", t->filename);
+ info("%s: writing descriptors (in v2 format)\n", t->filename);
ret = write(t->fd, &descriptors, sizeof descriptors);
+
+ if (ret < 0 && errno == EINVAL) {
+ warn("%
Re: [PATCH v3] USB:gadget: Fix a warning while loading g_mass_storage
On Fri, 13 Jun 2014, Yang,Wei wrote: > On 06/09/2014 02:19 PM, wei.y...@windriver.com wrote: > > From: Yang Wei > > > > While loading g_mass_storage module, the following warning > > is triggered. > > > > WARNING: at drivers/usb/gadget/composite.c: > > usb_composite_setup_continue: Unexpected call > > Modules linked in: fat vfat minix nls_cp437 nls_iso8859_1 g_mass_storage > > [<800179cc>] (unwind_backtrace+0x0/0x104) from [<80619608>] > > (dump_stack+0x20/0x24) > > [<80619608>] (dump_stack+0x20/0x24) from [<80025100>] > > (warn_slowpath_common+0x64/0x74) > > [<80025100>] (warn_slowpath_common+0x64/0x74) from [<800251cc>] > > (warn_slowpath_fmt+0x40/0x48) > > [<800251cc>] (warn_slowpath_fmt+0x40/0x48) from [<7f047774>] > > (usb_composite_setup_continue+0xb4/0xbc [g_mass_storage]) > > [<7f047774>] (usb_composite_setup_continue+0xb4/0xbc [g_mass_storage]) from > > [<7f047ad4>] (handle_exception+0x358/0x3e4 [g_mass_storage]) > > [<7f047ad4>] (handle_exception+0x358/0x3e4 [g_mass_storage]) from > > [<7f048080>] (fsg_main_thread+0x520/0x157c [g_mass_storage]) > > [<7f048080>] (fsg_main_thread+0x520/0x157c [g_mass_storage]) from > > [<8004bc90>] (kthread+0x98/0x9c) > > [<8004bc90>] (kthread+0x98/0x9c) from [<8000faec>] > > (kernel_thread_exit+0x0/0x8) > > > > The root cause is that the existing code fails to take into > > account the possibility that common->new_fsg can change while > > do_set_interface() is running, because the spinlock isn't held > > at this point. > > > > Signed-off-by: Yang Wei > > Signed-off-by: Alan Stern > > --- > > drivers/usb/gadget/f_mass_storage.c |6 -- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > Hi Alan, > > > > Thanks for your review, there are a few changes in v3: > > > > 1) Fix a coding style issue. > > 2) Refine the commit log > > > > Regards > > Wei > > Ping, Alan, What do you think of it? You should not have added my "Signed-off-by:"; I did not give you permission to do that. Michal's comment about common->new_fsg not being protected by the lock is a good one. It would be better for the patch description to say: The value of common->new_fsg that gets tested after do_set_interface() returns needs to be the same as the value used by do_set_interface(). With that change, you may add Acked-by: Alan Stern 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
[PATCHv4 0/6] Various small USB fixes
Michal Nazarewicz (6): usb: gadget: f_fs: resurect usb_functionfs_descs_head structure tools: ffs-test: fix header values endianess usb: gadget: f_fs: add usb_functionfs_descs_head_v2 structure tools: ffs-test: convert to new descriptor format tools: ffs-test: add compatibility code for old kernels usb: gadget: f_mass_storage: Fix a warning while loading g_mass_storage drivers/usb/gadget/f_mass_storage.c | 54 ++-- include/uapi/linux/usb/functionfs.h | 19 +- tools/usb/ffs-test.c| 124 +--- 3 files changed, 166 insertions(+), 31 deletions(-) -- 2.0.0.526.g5318336 -- 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
[PATCHv4 2/6] tools: ffs-test: fix header values endianess
It appears that no one ever run ffs-test on a big-endian machine,
since it used cpu-endianess for fs_count and hs_count fields which
should be in little-endian format. Fix by wrapping the numbers in
cpu_to_le32.
Cc: sta...@vger.kernel.org
Signed-off-by: Michal Nazarewicz
---
tools/usb/ffs-test.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/usb/ffs-test.c b/tools/usb/ffs-test.c
index fe1e66b..a87e99f 100644
--- a/tools/usb/ffs-test.c
+++ b/tools/usb/ffs-test.c
@@ -116,8 +116,8 @@ static const struct {
.header = {
.magic = cpu_to_le32(FUNCTIONFS_DESCRIPTORS_MAGIC),
.length = cpu_to_le32(sizeof descriptors),
- .fs_count = 3,
- .hs_count = 3,
+ .fs_count = cpu_to_le32(3),
+ .hs_count = cpu_to_le32(3),
},
.fs_descs = {
.intf = {
--
2.0.0.526.g5318336
--
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
[PATCHv4 1/6] usb: gadget: f_fs: resurect usb_functionfs_descs_head structure
Even though usb_functionfs_descs_head structure is now deprecated,
it has been used by some user space tools. Its removel in commit
[ac8dde1: “Add flags to descriptors block”] was an oversight
leading to build breakage for such tools.
Bring it back so that old user space tools can still be build
without problems on newer kernel versions.
Cc: # 3.14
Reported-by: Lad, Prabhakar
Reported-by: Krzysztof Opasiak
Signed-off-by: Michal Nazarewicz
---
include/uapi/linux/usb/functionfs.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/uapi/linux/usb/functionfs.h
b/include/uapi/linux/usb/functionfs.h
index 2a4b4a7..24b68c5 100644
--- a/include/uapi/linux/usb/functionfs.h
+++ b/include/uapi/linux/usb/functionfs.h
@@ -33,6 +33,13 @@ struct usb_endpoint_descriptor_no_audio {
__u8 bInterval;
} __attribute__((packed));
+/* Legacy format, deprecated as of 3.14. */
+struct usb_functionfs_descs_head {
+ __le32 magic;
+ __le32 length;
+ __le32 fs_count;
+ __le32 hs_count;
+} __attribute__((packed, deprecated));
/*
* Descriptors format:
--
2.0.0.526.g5318336
--
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 v6 1/1] usb: host: xhci-plat: add support for the R-Car H2 and M2 xHCI controllers
The R-Car H2 and M2 SoCs come with an xHCI controller that requires
some specific initializations related to the firmware downloading and
some specific registers. This patch adds the support for this special
configuration as an xHCI quirk executed during probe and start.
Signed-off-by: Yoshihiro Shimoda
---
drivers/usb/host/Kconfig |8 +++
drivers/usb/host/Makefile|3 +
drivers/usb/host/xhci-plat.c | 19 ++
drivers/usb/host/xhci-rcar.c | 148 ++
drivers/usb/host/xhci-rcar.h | 27
5 files changed, 205 insertions(+)
create mode 100644 drivers/usb/host/xhci-rcar.c
create mode 100644 drivers/usb/host/xhci-rcar.h
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 61b7817..537d9e1 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -37,6 +37,14 @@ config USB_XHCI_MVEBU
Say 'Y' to enable the support for the xHCI host controller
found in Marvell Armada 375/38x ARM SOCs.
+config USB_XHCI_RCAR
+ tristate "xHCI support for Renesas R-Car SoCs"
+ select USB_XHCI_PLATFORM
+ depends on ARCH_SHMOBILE || COMPILE_TEST
+ ---help---
+ Say 'Y' to enable the support for the xHCI host controller
+ found in Renesas R-Car ARM SoCs.
+
endif # USB_XHCI_HCD
config USB_EHCI_HCD
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index af89a90..144c038 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -22,6 +22,9 @@ ifneq ($(CONFIG_USB_XHCI_PLATFORM), )
ifneq ($(CONFIG_USB_XHCI_MVEBU), )
xhci-hcd-y += xhci-mvebu.o
endif
+ifneq ($(CONFIG_USB_XHCI_RCAR), )
+ xhci-hcd-y += xhci-rcar.o
+endif
endif
obj-$(CONFIG_USB_WHCI_HCD) += whci/
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 29d8adb..b6f2b6b 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -20,6 +20,7 @@
#include "xhci.h"
#include "xhci-mvebu.h"
+#include "xhci-rcar.h"
static void xhci_plat_quirks(struct device *dev, struct xhci_hcd *xhci)
{
@@ -34,11 +35,27 @@ static void xhci_plat_quirks(struct device *dev, struct
xhci_hcd *xhci)
/* called during probe() after chip reset completes */
static int xhci_plat_setup(struct usb_hcd *hcd)
{
+ struct device_node *of_node = hcd->self.controller->of_node;
+ int ret;
+
+ if (of_device_is_compatible(of_node, "renesas,xhci-r8a7790") ||
+ of_device_is_compatible(of_node, "renesas,xhci-r8a7791")) {
+ ret = xhci_rcar_init_quirk(hcd);
+ if (ret)
+ return ret;
+ }
+
return xhci_gen_setup(hcd, xhci_plat_quirks);
}
static int xhci_plat_start(struct usb_hcd *hcd)
{
+ struct device_node *of_node = hcd->self.controller->of_node;
+
+ if (of_device_is_compatible(of_node, "renesas,xhci-r8a7790") ||
+ of_device_is_compatible(of_node, "renesas,xhci-r8a7791"))
+ xhci_rcar_start(hcd);
+
return xhci_run(hcd);
}
@@ -270,6 +287,8 @@ static const struct of_device_id usb_xhci_of_match[] = {
{ .compatible = "xhci-platform" },
{ .compatible = "marvell,armada-375-xhci"},
{ .compatible = "marvell,armada-380-xhci"},
+ { .compatible = "renesas,xhci-r8a7790"},
+ { .compatible = "renesas,xhci-r8a7791"},
{ },
};
MODULE_DEVICE_TABLE(of, usb_xhci_of_match);
diff --git a/drivers/usb/host/xhci-rcar.c b/drivers/usb/host/xhci-rcar.c
new file mode 100644
index 000..ff0d1b4
--- /dev/null
+++ b/drivers/usb/host/xhci-rcar.c
@@ -0,0 +1,148 @@
+/*
+ * xHCI host controller driver for R-Car SoCs
+ *
+ * Copyright (C) 2014 Renesas Electronics Corporation
+ *
+ * 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 "xhci.h"
+#include "xhci-rcar.h"
+
+#define FIRMWARE_NAME "r8a779x_usb3_v1.dlmem"
+MODULE_FIRMWARE(FIRMWARE_NAME);
+
+/*** Register Offset ***/
+#define RCAR_USB3_INT_ENA 0x224 /* Interrupt Enable */
+#define RCAR_USB3_DL_CTRL 0x250 /* FW Download Control & Status */
+#define RCAR_USB3_FW_DATA0 0x258 /* FW Data0 */
+
+#define RCAR_USB3_LCLK 0xa44 /* LCLK Select */
+#define RCAR_USB3_CONF10xa48 /* USB3.0 Configuration1 */
+#define RCAR_USB3_CONF20xa5c /* USB3.0 Configuration2 */
+#define RCAR_USB3_CONF30xaa8 /* USB3.0 Configuration3 */
+#define RCAR_USB3_RX_POL 0xab0 /* USB3.0 RX Polarity */
+#define RCAR_USB3_TX_POL 0xab8 /* USB3.0 TX Polarity */
+
+/*** Register Settings ***/
+/* Interrupt Enable */
+#define RCAR_USB3_INT_XHC_ENA 0x0001
+#define RCAR_USB3_INT_PME_ENA 0x0002
+#define RCAR_USB3_INT_HSE_ENA 0x0004
+#define RCAR_USB3_INT_ENA_VA
[PATCH v6 0/1] add support for the R-Car H2 and M2 xHCI controllers
This patch adds the USB xHCI support for the R-Car H2 and M2 SoCs. These SoCs use an xHCI but still need specific initialization, mainly to setup the firmware downloading and the specific registers. This patch set is based on the usb-next branch of Greg usb.git tree. (commit id = 4a95b1fce97756d0333f8232eb7ed6974e93b054) Changes since v5: - Fix the RCAR_USB3_RX_POL_VAL value in patch 1. - Also modify the RCAR_USB3_TX_POL_VAL value using the BIT macro. Changes since v4: - Rebase the latest usb-next branch Changes since v3: - Remove a general phy driver calling in xhci-plat.c - Change xhci_rcar_init_quirk() calling into xhci_plat_setup(). Because of usb_add_hcd() will call a generic phy driver calling. - Modify xhci_rcar_init_quirk() Changes since v2: - Fix goto direction in patch 1. - Remove some unnecessary checks in patch 1. - Add MODULE_FIRMWARE() in patch 2. - Add a comment about xhci_rcar_init_quirk() in patch 2. Changes since v1 (about patch 2 only because patch 1 and 3 ware applied): - Fix some typos in patch 2. - Remove duplicated #define in patch 2. - Remove usb_phy framework calling in patch 2. - Change prototype of xhci_rcar_start() in patch 2. - Change compatible strings from "renesas,r8a779[01]-xhci" to "renesas,xhci-r8a779[01]" in patch 2. Because of Renesas SoC maintainer's comment: http://marc.info/?l=linux-sh&m=140109049002958&w=2 - Rewrite the custom get_unaligned_le32() and add comment about it in patch 2. *** BLURB HERE *** Yoshihiro Shimoda (1): usb: host: xhci-plat: add support for the R-Car H2 and M2 xHCI controllers drivers/usb/host/Kconfig |8 +++ drivers/usb/host/Makefile|3 + drivers/usb/host/xhci-plat.c | 19 ++ drivers/usb/host/xhci-rcar.c | 148 ++ drivers/usb/host/xhci-rcar.h | 27 5 files changed, 205 insertions(+) create mode 100644 drivers/usb/host/xhci-rcar.c create mode 100644 drivers/usb/host/xhci-rcar.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] usb: gadget: composite: unlock spinlock before usb_gadget_disconnect()
From: Robert Baldyga
> usb_gadget_disconnect() shouldn't be called under spinlock to avoid
> spinlock recursion. Function usb_gadget_disconnect() calls pullup(),
> which is callback from UDC driver, usually calling composite_disconnect().
> This function wants to lock spinlock used in usb_function_deactivate()
> causing spinlock recursion.
...
> +++ b/drivers/usb/gadget/composite.c
> @@ -260,8 +260,11 @@ int usb_function_deactivate(struct usb_function
> *function)
>
> spin_lock_irqsave(&cdev->lock, flags);
>
> - if (cdev->deactivations == 0)
> + if (cdev->deactivations == 0) {
> + spin_unlock_irqrestore(&cdev->lock, flags);
> status = usb_gadget_disconnect(cdev->gadget);
> + spin_lock_irqsave(&cdev->lock, flags);
> + }
> if (status == 0)
> cdev->deactivations++;
That sort of change rings big alarm bells.
You've effectively isolated the usb_gadget_disconnect() call
from the check that cdev->deactivations == 0.
And then you increment cdev->deactivations below.
Looks like it will be racy to me.
David
--
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: ehci-exynos: Make provision for vdd regulators
Hi,
On Wed, Jun 11, 2014 at 9:09 PM, Alan Stern wrote:
> On Fri, 6 Jun 2014, Vivek Gautam wrote:
>
>> Facilitate getting required 3.3V and 1.0V VDD supply for
>> EHCI controller on Exynos.
>>
>> With patches for regulators' nodes merged in 3.15:
>> c8c253f ARM: dts: Add regulator entries to smdk5420
>> 275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
>>
>> certain perripherals will now need to ensure that,
>> they request VDD regulators in their drivers, and enable
>> them so as to make them working.
>
> "Certain peripherals"? Don't you mean "certain controllers"?
Right, 'certain controllers'.
>
> Does this mean some controllers don't need to use the VDD regulators?
Actually until the two patches got merged, the USB controllers were
depending on bootloader
for the VDD supply, wherein it was enabled, which ofcourse was bad.
And by 'certain' i meant that above mentioned dt patches enable only the minimum
number of regulators for the system, however leaves other for the
drivers to enable.
Anyways, i will re-do this commit message.
>
>> @@ -193,7 +196,31 @@ static int exynos_ehci_probe(struct platform_device
>> *pdev)
>>
>> err = exynos_ehci_get_phy(&pdev->dev, exynos_ehci);
>> if (err)
>> - goto fail_clk;
>> + goto fail_regulator1;
>> +
>> + exynos_ehci->vdd33 = devm_regulator_get(&pdev->dev, "vdd33");
>> + if (!IS_ERR(exynos_ehci->vdd33)) {
>> + err = regulator_enable(exynos_ehci->vdd33);
>> + if (err) {
>> + dev_err(&pdev->dev,
>> + "Failed to enable 3.3V Vdd supply\n");
>> + goto fail_regulator1;
>> + }
>> + } else {
>> + dev_warn(&pdev->dev, "Regulator 3.3V Vdd supply not found\n");
>> + }
>
> What if this is one of the controllers that don't need to use a VDD
> regulator? Do you really want to print out a warning in that case?
> Should you call devm_regulator_get_optional() instead?
Right, better to use devm_regulator_get_optional(). Thanks for
pointing this out.
--
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: gadget: composite: unlock spinlock before usb_gadget_disconnect()
usb_gadget_disconnect() shouldn't be called under spinlock to avoid
spinlock recursion. Function usb_gadget_disconnect() calls pullup(),
which is callback from UDC driver, usually calling composite_disconnect().
This function wants to lock spinlock used in usb_function_deactivate()
causing spinlock recursion.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/composite.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index d41103e..77cae4b 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -260,8 +260,11 @@ int usb_function_deactivate(struct usb_function *function)
spin_lock_irqsave(&cdev->lock, flags);
- if (cdev->deactivations == 0)
+ if (cdev->deactivations == 0) {
+ spin_unlock_irqrestore(&cdev->lock, flags);
status = usb_gadget_disconnect(cdev->gadget);
+ spin_lock_irqsave(&cdev->lock, flags);
+ }
if (status == 0)
cdev->deactivations++;
--
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
[no subject]
Although you might be nervous about my e-mail as we have not met before. My name is Mrs Teresa Au, I work with HSBC Hong Kong; there is a sum of USD$23,200,000.00 business proposal I want to share with you. It is absolutely risk free; if you are interested send me a reply to my private e-mail below : mrs_t...@126.com Best Regards, Email: mrs_t...@126.com Mrs Teresa Au. Provincia di Treviso - http://www.provincia.treviso.it -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Disable bus's drivers_autoprobe before rootfs has mounted
> > > > Peter, correct me if this is wrong. It sounds like you want to have > > > a way for the user to control which gadget driver gets bound to > > > which UDC driver when everything is compiled into the kernel, > > > nothing is built as a separate module. Is that the basic idea? > > > > Yes, I know it can be done by gadget-configfs, but how about the user > > chooses other gadgets, eg: g_webcam, g_audio? > > > > I forget to introduce the background of this topic, I have this issue > > when I implement gadget bus patch set. > > (http://www.spinics.net/lists/linux-usb/msg107797.html) > > The current behaviour for other gadgets is auto-binding, so I want to > > keep auto-binding at my gadget bus implementation, but manual-binding > > is also a feature we need to support for other gadgets, so I want > > auto-binding is the default binding way, and the user can switch the > > two binding ways, eg, module parameters or sys entry. > > > > But if both udc driver and gadget driver are built in, the user can't > > let manual-binding work during the boot since the device-model will do > > probe, and do auto-binding. > > > > My v1 patch set [3/4] do a tricky way to work around it, I would like > > to know if it can be supported by device model framework? > > I think we can keep everything a lot simpler. Let's agree that the old > non-composite gadget drivers (like g_ether, g_mass_storage, and so on) > should only be used one at a time. That is, there should never be more > than one of them compiled into the kernel or loaded as a module, and they > shouldn't be used if there is more than one unbound UDC. > > If a user wants to work with more than one UDC or more than one gadget > driver then he should use function drivers with the configfs interface > (or functionfs or gadgetfs or whatever). > > Does that seem reasonable? It doesn't solve your problem so much as > declare it an unsupported case, but I don't think there is any reasonable > way to solve the problem without using something like configfs. > OK, we can keep our g_xxx gadget driver just support the basic feature. But the bug that causes gadget driver load fail due to udc is probed deferral should be fixed, do you think so, we can't wait until configfs has total been ready. Peter -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] USB:gadget: Fix a warning while loading g_mass_storage
On Mon, Jun 09 2014, wei.y...@windriver.com wrote: > From: Yang Wei > > While loading g_mass_storage module, the following warning > is triggered. > > WARNING: at drivers/usb/gadget/composite.c: > usb_composite_setup_continue: Unexpected call > Modules linked in: fat vfat minix nls_cp437 nls_iso8859_1 g_mass_storage > [<800179cc>] (unwind_backtrace+0x0/0x104) from [<80619608>] > (dump_stack+0x20/0x24) > [<80619608>] (dump_stack+0x20/0x24) from [<80025100>] > (warn_slowpath_common+0x64/0x74) > [<80025100>] (warn_slowpath_common+0x64/0x74) from [<800251cc>] > (warn_slowpath_fmt+0x40/0x48) > [<800251cc>] (warn_slowpath_fmt+0x40/0x48) from [<7f047774>] > (usb_composite_setup_continue+0xb4/0xbc [g_mass_storage]) > [<7f047774>] (usb_composite_setup_continue+0xb4/0xbc [g_mass_storage]) from > [<7f047ad4>] (handle_exception+0x358/0x3e4 [g_mass_storage]) > [<7f047ad4>] (handle_exception+0x358/0x3e4 [g_mass_storage]) from > [<7f048080>] (fsg_main_thread+0x520/0x157c [g_mass_storage]) > [<7f048080>] (fsg_main_thread+0x520/0x157c [g_mass_storage]) from > [<8004bc90>] (kthread+0x98/0x9c) > [<8004bc90>] (kthread+0x98/0x9c) from [<8000faec>] > (kernel_thread_exit+0x0/0x8) > > The root cause is that the existing code fails to take into > account the possibility that common->new_fsg can change while > do_set_interface() is running, because the spinlock isn't held > at this point. common->new_fsg is not protected by common->lock so this justification is not valid. > > Signed-off-by: Yang Wei > Signed-off-by: Alan Stern > --- > drivers/usb/gadget/f_mass_storage.c |6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > Hi Alan, > > Thanks for your review, there are a few changes in v3: > > 1) Fix a coding style issue. > 2) Refine the commit log > > Regards > Wei > > diff --git a/drivers/usb/gadget/f_mass_storage.c > b/drivers/usb/gadget/f_mass_storage.c > index b963939..0cd8f21 100644 > --- a/drivers/usb/gadget/f_mass_storage.c > +++ b/drivers/usb/gadget/f_mass_storage.c > @@ -2342,6 +2342,7 @@ static void handle_exception(struct fsg_common *common) > struct fsg_buffhd *bh; > enum fsg_state old_state; > struct fsg_lun *curlun; > + struct fsg_dev *new_fsg; > unsigned intexception_req_tag; > > /* > @@ -2421,6 +2422,7 @@ static void handle_exception(struct fsg_common *common) > } > common->state = FSG_STATE_IDLE; > } > + new_fsg = common->new_fsg; Also, because common->new_fsg is not protected by common->lock, doing this under a lock is kinda pointless. > spin_unlock_irq(&common->lock); > > /* Carry out any extra actions required for the exception */ > @@ -2460,8 +2462,8 @@ static void handle_exception(struct fsg_common *common) > break; > > case FSG_STATE_CONFIG_CHANGE: > - do_set_interface(common, common->new_fsg); > - if (common->new_fsg) > + do_set_interface(common, new_fsg); > + if (new_fsg) > usb_composite_setup_continue(common->cdev); As far as I can tell, it's safe to move the assignment to new_fsg here, e.g.: new_fsg = common->new_fsg; do_set_interface(common, new_fsg); if (new_fsg) usb_composite_setup_continue(common->cdev); > break; But perhaps new_fsg should be protected by the lock. I think valid fix (which I did not test in *any* way) will be this: -- >8 >From 1d0b638fab05489dfb52a96556b73e2670ab52ee Mon Sep 17 00:00:00 2001 From: Michal Nazarewicz Date: Fri, 13 Jun 2014 11:40:45 +0200 Subject: [PATCH] usb: gadget: f_mass_storage: Fix a warning while loading g_mass_storage While loading g_mass_storage module, the following warning can trigger: WARNING: at drivers/usb/gadget/composite.c: usb_composite_setup_continue: Unexpected call Modules linked in: fat vfat minix nls_cp437 nls_iso8859_1 g_mass_storage [<800179cc>] (unwind_backtrace+0x0/0x104) from [<80619608>] (dump_stack+0x20/0x24) [<80619608>] (dump_stack+0x20/0x24) from [<80025100>] (warn_slowpath_common+0x64/0x74) [<80025100>] (warn_slowpath_common+0x64/0x74) from [<800251cc>] (warn_slowpath_fmt+0x40/0x48) [<800251cc>] (warn_slowpath_fmt+0x40/0x48) from [<7f047774>] (usb_composite_setup_continue+0xb4/0xbc [g_mass_storage]) [<7f047774>] (usb_composite_setup_continue+0xb4/0xbc [g_mass_storage]) from [<7f047ad4>] (handle_exception+0x358/0x3e4 [g_mass_storage]) [<7f047ad4>] (handle_exception+0x358/0x3e4 [g_mass_storage]) from [<7f048080>] (fsg_main_thread+0x520/0x157c [g_mass_storage]) [<7f048080>] (fsg_main_thread+0x520/0x157c [g_mass_storage]) from [<8004bc90>] (kthread+0x98/0x9c) [<8004bc90>] (kthread+0x98/0x9c) from [<8000faec>] (kernel_thread_exit+0x0/0x8) The root cause is that the existing code fails to take into account the possib
[PATCH] staging: usbip: fixed a coding-style warning
This fixes the following warning:
- WARNING: __constant_cpu_to_le32 should be cpu_to_le32
Signed-off-by: Alexey Tulia
---
drivers/staging/usbip/vhci_hcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/usbip/vhci_hcd.c b/drivers/staging/usbip/vhci_hcd.c
index 0007d30..e21c1b4 100644
--- a/drivers/staging/usbip/vhci_hcd.c
+++ b/drivers/staging/usbip/vhci_hcd.c
@@ -304,7 +304,7 @@ static int vhci_hub_control(struct usb_hcd *hcd, u16
typeReq, u16 wValue,
break;
case GetHubStatus:
usbip_dbg_vhci_rh(" GetHubStatus\n");
- *(__le32 *) buf = __constant_cpu_to_le32(0);
+ *(__le32 *) buf = cpu_to_le32(0);
break;
case GetPortStatus:
usbip_dbg_vhci_rh(" GetPortStatus port %x\n", wIndex);
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] leds: USB: HID: Add support for MSI GT683R led panels
On Thu, Jun 12, 2014 at 11:34:12PM +0300, Janne Kanniainen wrote:
> This driver adds support for USB controlled led panels that exists in
> MSI GT683R laptop
>
> Signed-off-by: Janne Kanniainen
> ---
> Changes in v2:
> - sorted headers to alphabetic order
> - using devm_kzalloc
> - using BIT(n)
> - using usb_control_msg instead of usb_submit_urb
> - removing unneeded code
>
> Changes in v3:
> - implemented as HID device
> - some cleanups and bug fixes
>
> Changes in v4:
> - more cleanups
> - support for selecting leds
> - suppport for selecting status
>
> Changes in v5:
> - mode attribute documented under Documentation/ABI
> - made array for led_classdev
> - led devices uses now recommended naming scheme
>
> .../ABI/testing/sysfs-class-hid-driver-gt683r | 10 +
> drivers/hid/Kconfig| 11 +
> drivers/hid/Makefile | 1 +
> drivers/hid/hid-core.c | 1 +
> drivers/hid/hid-gt683r.c | 294
> +
> drivers/hid/hid-ids.h | 2 +-
> drivers/hid/usbhid/hid-quirks.c| 2 +-
> 7 files changed, 319 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
> create mode 100644 drivers/hid/hid-gt683r.c
>
> diff --git a/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
> b/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
> new file mode 100644
> index 000..c4d604e
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-class-hid-driver-gt683r
> @@ -0,0 +1,10 @@
> +What:/sys/class/hidraw//device/state
You should probably stick to "mode" (rather than "state") throughout (it
seems you just forgot to update a few uses).
> +Date:Jun 2014
> +KernelVersion: 3.15
This should be 3.17.
> +Contact: Janne Kanniainen
> +Description:
> + Set the mode of LEDs
> +
> + 0 - normal
> + 1 - audio
> + 2 - breathing
Perhaps expand this with a short paragraph describing the different
modes.
> diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> index 7af9d0b..d93e0ae 100644
> --- a/drivers/hid/Kconfig
> +++ b/drivers/hid/Kconfig
> @@ -261,6 +261,17 @@ config HOLTEK_FF
> Say Y here if you have a Holtek On Line Grip based game controller
> and want to have force feedback support for it.
>
> +config HID_GT683R
> + tristate "MSI GT68xR LED support"
> + depends on LEDS_CLASS && USB_HID
> + ---help---
> + Say Y here if you want to enable support for the MSI GT68xR LEDS
> +
> + This driver support following states normal, breathing and audio.
You could also use "modes" and expand this with the same description.
> + You can also select which leds you want to enable.
> + Currently the following devices are know to be supported:
> + - MSI GT683R
> +
> config HID_HUION
> tristate "Huion tablets"
> depends on USB_HID
> diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
> index fc712dd..7129311 100644
> --- a/drivers/hid/Makefile
> +++ b/drivers/hid/Makefile
> @@ -48,6 +48,7 @@ obj-$(CONFIG_HID_EMS_FF)+= hid-emsff.o
> obj-$(CONFIG_HID_ELECOM) += hid-elecom.o
> obj-$(CONFIG_HID_ELO)+= hid-elo.o
> obj-$(CONFIG_HID_EZKEY) += hid-ezkey.o
> +obj-$(CONFIG_HID_GT683R) += hid-gt683r.o
> obj-$(CONFIG_HID_GYRATION) += hid-gyration.o
> obj-$(CONFIG_HID_HOLTEK) += hid-holtek-kbd.o
> obj-$(CONFIG_HID_HOLTEK) += hid-holtek-mouse.o
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index da52279..ec88fdb 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -1827,6 +1827,7 @@ static const struct hid_device_id
> hid_have_special_driver[] = {
> { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT,
> USB_DEVICE_ID_WIRELESS_OPTICAL_DESKTOP_3_0) },
> { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_OFFICE_KB) },
> { HID_USB_DEVICE(USB_VENDOR_ID_MONTEREY, USB_DEVICE_ID_GENIUS_KB29E) },
> + { HID_USB_DEVICE(USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GT683R_LED_PANEL)
> },
> { HID_USB_DEVICE(USB_VENDOR_ID_NTRIG, USB_DEVICE_ID_NTRIG_TOUCH_SCREEN)
> },
> { HID_USB_DEVICE(USB_VENDOR_ID_NTRIG,
> USB_DEVICE_ID_NTRIG_TOUCH_SCREEN_1) },
> { HID_USB_DEVICE(USB_VENDOR_ID_NTRIG,
> USB_DEVICE_ID_NTRIG_TOUCH_SCREEN_2) },
> diff --git a/drivers/hid/hid-gt683r.c b/drivers/hid/hid-gt683r.c
> new file mode 100644
> index 000..6dffb76
> --- /dev/null
> +++ b/drivers/hid/hid-gt683r.c
> @@ -0,0 +1,294 @@
> +/*
> + * MSI GT683R led driver
> + *
> + * Copyright (c) 2014 Janne Kanniainen
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * publis
RE: Disable bus's drivers_autoprobe before rootfs has mounted
> > > > I am just worried if we change the behaviour of using gadget > > > > driver, can it be accepted by user? If you think it can be > > > > accepted if we can have some docs, we can implement manually > > > > binding for gadget driver from now on. > > > > > > user shouldn't have to deal with direct module insertion/removal > > > (unless he's a developer and actually *wants* to do that). Docs are > > > already in tree. The entire configfs interface has been documented, > > > it's based on those documents that Matt started writing libusbg. > > > > > > -- > > > balbi > > > > Yes, gadget-configfs is a good direction. > > > > I would like to know your plan for other gadget drivers > > (g_mass_storage, g_webcam, etc) > > they can be built dynamically too. We only provided a version of > g_mass_storage in order to avoid regressions. We can't simply remove that > driver from the kernel. > > > All functions will be supported by configfs in future, and current > > driver will be deleted? > > I don't think we will be able to delete legacy drivers, but they're all > supported through configfs. I guess only webcam is missing. > > > - If yes, how to cover the user who still use the old file system? > > - If no, which binding way for udc and gadget driver will be used? > > going forward, we want to stick with configfs. > ok, then, what's the plan for current bug for legacy gadget driver (eg, we can't load gadget driver before udc is ready)? I know this bug is existed from 3.10, we may need to at least 1 year for switch to configfs, it includes lots of user habit problems. The user will complaint this problem for more than 2 years. If you think we should fix this bug before we totally switch to configfs, I will continue to enhancement my gadget bus implementation, and let it support configfs and legacy gadget driver well. Peter -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: ftdi_sio: add GPIO support
On Mon, Jun 9, 2014 at 3:21 PM, Sascha Silbe wrote:
> The chips can operate either in regular or in bitbang mode. Care was
> taken to prevent using GPIOs if the serial device is in use and vice
> versa.
Very interesting patch! I've seen USB-based GPIO things before
but never a dual-mode thing.
There was already a comment to move the implementation to a
separate file, which I won't repeat.
But I also want to bring the device model into question: normally
when a mother device spawns children across different subsystems
we model them as MFD devices (drivers/mfd) that instantiate
children for the different subsystems. So you could spawn a
serial and a GPIO device from a USB-based hub device there.
I do not know if that is really apropriate in this case. It seems the
device is first and foremost FTDI.
But it could still spawn a child platform device for the GPIO stuff
so that this can live as a separate driver under drivers/gpio/gpio-ftdi.c
or similar.
You could then use something like:
struct platform_device *gdev;
gdev = platform_device_alloc("gpio-ftdi", PLATFORM_DEVID_AUTO);
/* pdata contains communication cookie for callbacks etc */
ret = platform_device_add_data(gdev, pdata, sizeof(*pdata));
ret = platform_device_add(gdev);
Then we can probe that device normally in the GPIO subsystem
like any other driver, just that it needs some
header or similar to define the function
calls to communicate with the FTDI driver.
However Greg is device core maintainer and may have better
ideas about this!
Yours,
Linus Walleij
--
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
