Re: [PATCH v2 1/4] gpio: dln2: fix issue when an IRQ is unmasked then enabled
On Wed, Dec 17, 2014 at 12:57 AM, Octavian Purdila wrote: > As noticed during suspend/resume operations, the IRQ can be unmasked > then disabled in suspend and eventually enabled in resume, but without > being unmasked. > > The current implementation does not take into account interactions > between mask/unmask and enable/disable interrupts, and thus in the > above scenarios the IRQs remain unactive. > > To fix this we removed the enable/disable operations as they fallback > to mask/unmask anyway. > > We also remove the pending bitmaks as it is already done in irq_data > (i.e. IRQS_PENDING). > > Signed-off-by: Octavian Purdila > --- > drivers/gpio/gpio-dln2.c | 53 > +++- > 1 file changed, 7 insertions(+), 46 deletions(-) Yum, less code! Acked-by: Alexandre Courbot -- 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: Query regarding USB gadget driver
> On 12/17/2014 05:46 AM, Peter Chen wrote: > > On Tue, Dec 16, 2014 at 04:15:08PM +0530, Sanchayan Maity wrote: > >> On 12/16/2014 02:15 PM, Peter Chen wrote: > >>> On Tue, Dec 16, 2014 at 10:50:59AM +0530, Sanchayan Maity wrote: > On 12/16/2014 06:16 AM, Peter Chen wrote: > > On Mon, Dec 15, 2014 at 02:59:31PM +0530, Sanchayan Maity wrote: > >> Hello, > >> > >> On 12/15/2014 07:42 AM, Peter Chen wrote: > >>> On Fri, Dec 12, 2014 at 06:55:36PM +0530, Sanchayan Maity wrote: > Hello, > > On 12/12/2014 07:21 AM, Peter Chen wrote: > > On Thu, Dec 11, 2014 at 08:34:45AM -0600, Felipe Balbi wrote: > >> Hi, > >> > >> On Thu, Dec 11, 2014 at 04:08:43PM +0530, Sanchayan Maity > wrote: > >>> Hello, > >>> > >>> I am working on a Freescale Cortex-A5 Vybrid Processor. The > >>> chip core is clocked at 500MHz and the USB IP core for this > >>> is by Chip-idea. I am running a 3.18-rc5 kernel on it and > >>> trying to use the USB gadget functionality. To be more > >>> specific the CDC ECM class. Currently, I cannot use this > >>> properly. If I use just "ping" to check, it works fine, but, > >>> after running iperf, even one transaction doesn't complete > >>> or completes rarely. Checking the CDC Ether interface with > >>> Wireshark shows, TCP Dup Ack messages and checking the USB > >>> bus with Wireshark, shows packets with USB Protocol Error > >>> -71 at one point and after that packets with USB connection > >>> Reset -104 error. If it's of any significance, I have Arch > >>> Linux with the 3.18 kernel running on my laptop with which > >>> the Vybrid connects. On the host side, the only error dmesg > >>> shows is "kevent 12 may have been dropped". I guess this is > connected to the "TCP Previous Segment not captured" and "TCP Dup ACK" > messages. > >>> > >>> My script for the gadget configuration is as below: > >>> > >>> /bin/mount none /mnt -t configfs /bin/mkdir > >>> /mnt/usb_gadget/g1 cd /mnt/usb_gadget/g1 /bin/mkdir > >>> configs/c.1 /bin/mkdir functions/ecm.0 /bin/mkdir > >>> strings/0x409 /bin/mkdir configs/c.1/strings/0x409 echo > >>> 0xa4a2 > idProduct echo 0x0525 > idVendor echo Freescale123 > >>> > strings/0x409/serialnumber echo Freescale > > >>> strings/0x409/manufacturer echo "USB Serial Gadget" > > >>> strings/0x409/product echo "Conf 1" > > >>> configs/c.1/strings/0x409/configuration > >>> echo 200 > configs/c.1/MaxPower ln -s functions/ecm.0 > >>> configs/c.1 echo ci_hdrc.0 > UDC /sbin/ifconfig usb0 up > >>> /sbin/ifconfig usb0 192.168.1.10 > >>> > >>> I have debug prints in the udc.c and u_ether.c using > >>> pr_debug and > >> > >> just a little hint, use any of the dev_*() macros next time, > >> they'll print the device name which helps figuring out which UDC > you're using. > >> > >> Based on ci_hdrc.0 above, I suppose it's chipidea and Peter > >> Chen maintains that one, it really helps adding maintainers to Cc > list. > >> > >>> enable them when required using dynamic debug. Without > >>> running iperf, using ping gives me a sequence of prints as below: > >>> > >>> [ 277.434409] In eth_start_xmit [ 277.434517] In UDC irq [ > >>> 277.434553] In usb_gadget_giveback_request [ 277.434567] In > >>> tx_complete [ 277.435443] In UDC irq [ 277.435477] In > >>> usb_gadget_giveback_request [ 277.435491] In rx_complete [ > >>> 277.435517] In rx_submit [ 277.435601] In eth_start_xmit [ > >>> 277.436441] In UDC irq [ 277.436465] In > >>> usb_gadget_giveback_request [ 277.436478] In rx_complete [ > >>> 277.436493] In rx_submit [ 277.436520] In > >>> usb_gadget_giveback_request [ 277.436533] In tx_complete [ > >>> 278.434865] In eth_start_xmit [ 278.434959] In UDC irq [ > >>> 278.434993] In usb_gadget_giveback_request [ 278.435006] In > >>> tx_complete [ 278.435881] In UDC irq [ 278.435910] In > >>> usb_gadget_giveback_request [ 278.435923] In rx_complete [ > >>> 278.435946] In rx_submit > >>> > >>> After running iperf without debug prints and then enabling > >>> before using ping gives me a sequence of prints as below > >>> [ 81.989827] In UDC irq > >>> [ 81.989871] In usb_gadget_giveback_request > >>> [ 81.989886] In rx_complete > >>> [ 81.989905] In rx_submit > >>> [ 82.989892] In UDC irq > >>> [ 82.989951] In usb_gadget_giveback_request > >>> [ 82.989967] In rx_complete > >>> [ 82.989992] In rx_submit > >>> [ 83.990064] In UDC irq >
Re: Query regarding USB gadget driver
On 12/17/2014 05:46 AM, Peter Chen wrote: > On Tue, Dec 16, 2014 at 04:15:08PM +0530, Sanchayan Maity wrote: >> On 12/16/2014 02:15 PM, Peter Chen wrote: >>> On Tue, Dec 16, 2014 at 10:50:59AM +0530, Sanchayan Maity wrote: On 12/16/2014 06:16 AM, Peter Chen wrote: > On Mon, Dec 15, 2014 at 02:59:31PM +0530, Sanchayan Maity wrote: >> Hello, >> >> On 12/15/2014 07:42 AM, Peter Chen wrote: >>> On Fri, Dec 12, 2014 at 06:55:36PM +0530, Sanchayan Maity wrote: Hello, On 12/12/2014 07:21 AM, Peter Chen wrote: > On Thu, Dec 11, 2014 at 08:34:45AM -0600, Felipe Balbi wrote: >> Hi, >> >> On Thu, Dec 11, 2014 at 04:08:43PM +0530, Sanchayan Maity wrote: >>> Hello, >>> >>> I am working on a Freescale Cortex-A5 Vybrid Processor. The chip >>> core >>> is clocked at 500MHz and the USB IP core for this is by Chip-idea. I >>> am running a 3.18-rc5 kernel on it and trying to use the USB gadget >>> functionality. To be more specific the CDC ECM class. Currently, I >>> cannot use this properly. If I use just "ping" to check, it works >>> fine, but, after running iperf, even one transaction doesn't >>> complete >>> or completes rarely. Checking the CDC Ether interface with Wireshark >>> shows, TCP Dup Ack messages and checking the USB bus with Wireshark, >>> shows packets with USB Protocol Error -71 at one point and after >>> that >>> packets with USB connection Reset -104 error. If it's of any >>> significance, I have Arch Linux with the 3.18 kernel running on my >>> laptop with which the Vybrid connects. On the host side, the only >>> error dmesg shows is "kevent 12 may have been dropped". I guess this >>> is connected to the "TCP Previous Segment not captured" and "TCP Dup >>> ACK" messages. >>> >>> My script for the gadget configuration is as below: >>> >>> /bin/mount none /mnt -t configfs >>> /bin/mkdir /mnt/usb_gadget/g1 >>> cd /mnt/usb_gadget/g1 >>> /bin/mkdir configs/c.1 >>> /bin/mkdir functions/ecm.0 >>> /bin/mkdir strings/0x409 >>> /bin/mkdir configs/c.1/strings/0x409 >>> echo 0xa4a2 > idProduct >>> echo 0x0525 > idVendor >>> echo Freescale123 > strings/0x409/serialnumber >>> echo Freescale > strings/0x409/manufacturer >>> echo "USB Serial Gadget" > strings/0x409/product >>> echo "Conf 1" > configs/c.1/strings/0x409/configuration >>> echo 200 > configs/c.1/MaxPower >>> ln -s functions/ecm.0 configs/c.1 >>> echo ci_hdrc.0 > UDC >>> /sbin/ifconfig usb0 up >>> /sbin/ifconfig usb0 192.168.1.10 >>> >>> I have debug prints in the udc.c and u_ether.c using pr_debug and >> >> just a little hint, use any of the dev_*() macros next time, they'll >> print the device name which helps figuring out which UDC you're >> using. >> >> Based on ci_hdrc.0 above, I suppose it's chipidea and Peter Chen >> maintains that one, it really helps adding maintainers to Cc list. >> >>> enable them when required using dynamic debug. Without running >>> iperf, >>> using ping gives me a sequence of prints as below: >>> >>> [ 277.434409] In eth_start_xmit >>> [ 277.434517] In UDC irq >>> [ 277.434553] In usb_gadget_giveback_request >>> [ 277.434567] In tx_complete >>> [ 277.435443] In UDC irq >>> [ 277.435477] In usb_gadget_giveback_request >>> [ 277.435491] In rx_complete >>> [ 277.435517] In rx_submit >>> [ 277.435601] In eth_start_xmit >>> [ 277.436441] In UDC irq >>> [ 277.436465] In usb_gadget_giveback_request >>> [ 277.436478] In rx_complete >>> [ 277.436493] In rx_submit >>> [ 277.436520] In usb_gadget_giveback_request >>> [ 277.436533] In tx_complete >>> [ 278.434865] In eth_start_xmit >>> [ 278.434959] In UDC irq >>> [ 278.434993] In usb_gadget_giveback_request >>> [ 278.435006] In tx_complete >>> [ 278.435881] In UDC irq >>> [ 278.435910] In usb_gadget_giveback_request >>> [ 278.435923] In rx_complete >>> [ 278.435946] In rx_submit >>> >>> After running iperf without debug prints and then enabling before >>> using ping gives me a sequence of prints as below >>> [ 81.989827] In UDC irq >>> [ 81.989871] In usb_gadget_giveback_request >>> [ 81.989886] In rx_complete >>> [ 81.989905] In rx_submit >>> [ 82.989892] In UDC irq >>> [ 82.989951] In usb_gadget_giveback_request >>> [ 82.989967] In rx_complete >>> [ 82.989992] In
RE: PROBLEM: USB isochronous urb leak on EHCI driver
> > My configuration: > - > > Host: Freescale i.MX512 with ARM Cortex A8 (USB 2.0 host controller) Linux > kernel: 2.6.31, using EHCI USB driver > Hub: 4-PORT USB 1.1 HUB (Texas Instruments PN: tusb2046b) > Devices: 4 USB 1.1 audio codecs (Texas Instruments PN: pcm2901) > > Note: each codec is being used in R/W access, so with 4 codecs, I have > 4 playback and 4 capture streams. > > My problem: > --- > > I have usb urb leaks when connecting more than 1 codec to the USB 1.1 Hub. > (the result is that some of the audio data is not transferred, part of the > sound is > simply missing) No problem when using only 1 of the 4 codecs connected to the > hub; When I connect a second codec, the sound quality starts to degrade. With > 3 codecs, we just cannot recognize a speach. > > Tests and observations: > --- > > Since I have 3 usb ports available on the i.MX512, I tried to connect > 3 codecs directly on USB ports: the sound is perfect on each of the three > ports. > > I bought a consumer USB 2.0 Hub: no problem when using 3 codecs connected > to that Hub, however, the audio will completly stop on all channels when > connecting the 4th codec. > > I checked the communication between the Hub (USB 1.1) and the Host > controller (USB 2.0) with a scope and concluded that the communication speed > is 1.5 MBytes/s has expected (so the communication is downgraded to USB 1.1, > since codecs and hub are USB > 1.1 devices). > > Also, I know that there is physically enough bandwidth to transfer the data > for > two reasons: > 1) I have an older CPU with a USB 1.1 host controller (using the OHCI driver), > using the same hub and the same codecs: works like a champ, using less than > 50% of the available bandwidth (observed with a > scope) > 2) 1 audio stream is 32khz-mono, 16 bits = 64 kB/s, > 4 codecs = 8 streams(R/W) x 64 kB/s = 512 kB/s (out of 1.5MB/s) > > I noticed that my sound problem starts happening with only 2 codecs > (4 streams, 256 kB/s). I first thought that it was a bandwidth limitation, so > I > decided to connect only 1 codec using more bandwidth. > I configured it to 48khz-stereo (16-bits), using 384 kB/s for both read and > write > streams: no problem. With that configuration, the scope shows about 30% of > total bandwidth usage (300us used out of 1ms periods). Then, I added a second > codec (48khz-stereo-16bits): very strange, now the total bandwidth usage felt > down to about 200us, which seems to keep the same, whatever the number of > codec I add (I also tried 3 and 4...). So it looks like the scheduler is not > able to > properly allocate Isochronous time slots when more than one device is > connected to the hub. However, without the hub, it works perfectly. > I am wonder if it is similar problem I met when using multiple interrupt transfers, when you find you lose the data, try to run 'top' to show cpu utilization, if it is close to 100%, it means the ehci can't queue request in time, so the host can't send IN token in time. Using a USB bus analyzer can also verify it. Peter > Another interresting fact is that at application level, the Read and Write > operations are returning the good amount of bytes read/written. > This is not the case at kernel level: I noticed that function "usb_submit_urb" > (from /drivers/usb/core/urb.c) will only tranfer part of the "urbs" when the > sound is degraded. I tried to figure out where the leak comes from without > success. Also, there are no error messages from kernel so everything appears > to work well, excepted that part of the sound is missing! > > I can't change my hardware (this is in the hand of customers), so the only > possible solution for me is to correct the software. > > I tried to change my ehci driver with the one from kernel 2.6.39.4 but did not > work, same problem. > > Question: > - > > Before attempting to upgrade to an earlier kernel driver (this is a fairly big > amount of work), I would really like to know if this problem would still be > in the > 3.x kernels. Has anyone seen that issue in 3.x kernels? > > I am pretty new to USB driver debugging, so any ideas of where/how to find > solutions will be appreciated. Thank you very much in advance for the support. > Also don't hesitate to redirect me if I'm not at the right place to ask these > questions. I can also provide some code if someone need it to help. > > Attached is a dump of my "dmesg" after startup. > > Michael Tessier > > > > > > -- 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: hcd: add OTG ID signal sensing
>
> On the Renesas R8A7791 SoC based boards there's MAX3355 USB OTG chip and
> mini-AB USB connector corresponding to USB port 0 driven either by EHCI/OHCI
> or Renesas USBHS gadget controller. And we'd like the host/gadget drivers to
> work based on the cable type connected. An 'extcon' driver for MAX3355 has
> been written, so we only need to bind to it via device tree which I'm doing
> in
> this patch.
>
> I wasn't able to find a solution better than checking the cable type at the
> host
> driver probe time and refusing to drive a host if B-cable is connected.
>
You may need a dual-role/otg driver to do it, which can enable host/device
function
according to ID pin.
Peter
> Signed-off-by: Sergei Shtylyov
>
> ---
> The patch is against the 'usb-next' branch of Greg KH's 'usb.git' repo.
> It needs the recent 'extcon' core in order to properly handle probe deferral.
>
> drivers/usb/core/hcd.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> Index: usb/drivers/usb/core/hcd.c
>
> ===
> --- usb.orig/drivers/usb/core/hcd.c
> +++ usb/drivers/usb/core/hcd.c
> @@ -42,6 +42,7 @@
> #include
> #include
>
> +#include
> #include
> #include
> #include
> @@ -2632,6 +2633,23 @@ int usb_add_hcd(struct usb_hcd *hcd,
> int retval;
> struct usb_device *rhdev;
>
> + if (IS_ENABLED(CONFIG_EXTCON) &&
> + of_property_read_bool(hcd->self.controller->of_node, "extcon")) {
> + struct extcon_dev *edev;
> +
> + edev = extcon_get_edev_by_phandle(hcd->self.controller, 0);
> + if (IS_ERR(edev))
> + return PTR_ERR(edev);
> +
> + retval = extcon_get_cable_state(edev, "USB-HOST");
> + if (!retval) {
> + dev_err(hcd->self.controller,
> + "OTG B-cable plugged in, host driver won't
> load\n");
> + return -EINVAL;
> + } else if (retval < 0)
> + return retval;
> + }
> +
> if (IS_ENABLED(CONFIG_USB_PHY) && !hcd->usb_phy) {
> struct usb_phy *phy = usb_get_phy_dev(hcd->self.controller,
> 0);
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in the
> body
> of a message to majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
--
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: Query regarding USB gadget driver
On Tue, Dec 16, 2014 at 04:15:08PM +0530, Sanchayan Maity wrote: > On 12/16/2014 02:15 PM, Peter Chen wrote: > > On Tue, Dec 16, 2014 at 10:50:59AM +0530, Sanchayan Maity wrote: > >> On 12/16/2014 06:16 AM, Peter Chen wrote: > >>> On Mon, Dec 15, 2014 at 02:59:31PM +0530, Sanchayan Maity wrote: > Hello, > > On 12/15/2014 07:42 AM, Peter Chen wrote: > > On Fri, Dec 12, 2014 at 06:55:36PM +0530, Sanchayan Maity wrote: > >> Hello, > >> > >> On 12/12/2014 07:21 AM, Peter Chen wrote: > >>> On Thu, Dec 11, 2014 at 08:34:45AM -0600, Felipe Balbi wrote: > Hi, > > On Thu, Dec 11, 2014 at 04:08:43PM +0530, Sanchayan Maity wrote: > > Hello, > > > > I am working on a Freescale Cortex-A5 Vybrid Processor. The chip > > core > > is clocked at 500MHz and the USB IP core for this is by Chip-idea. I > > am running a 3.18-rc5 kernel on it and trying to use the USB gadget > > functionality. To be more specific the CDC ECM class. Currently, I > > cannot use this properly. If I use just "ping" to check, it works > > fine, but, after running iperf, even one transaction doesn't > > complete > > or completes rarely. Checking the CDC Ether interface with Wireshark > > shows, TCP Dup Ack messages and checking the USB bus with Wireshark, > > shows packets with USB Protocol Error -71 at one point and after > > that > > packets with USB connection Reset -104 error. If it's of any > > significance, I have Arch Linux with the 3.18 kernel running on my > > laptop with which the Vybrid connects. On the host side, the only > > error dmesg shows is "kevent 12 may have been dropped". I guess this > > is connected to the "TCP Previous Segment not captured" and "TCP Dup > > ACK" messages. > > > > My script for the gadget configuration is as below: > > > > /bin/mount none /mnt -t configfs > > /bin/mkdir /mnt/usb_gadget/g1 > > cd /mnt/usb_gadget/g1 > > /bin/mkdir configs/c.1 > > /bin/mkdir functions/ecm.0 > > /bin/mkdir strings/0x409 > > /bin/mkdir configs/c.1/strings/0x409 > > echo 0xa4a2 > idProduct > > echo 0x0525 > idVendor > > echo Freescale123 > strings/0x409/serialnumber > > echo Freescale > strings/0x409/manufacturer > > echo "USB Serial Gadget" > strings/0x409/product > > echo "Conf 1" > configs/c.1/strings/0x409/configuration > > echo 200 > configs/c.1/MaxPower > > ln -s functions/ecm.0 configs/c.1 > > echo ci_hdrc.0 > UDC > > /sbin/ifconfig usb0 up > > /sbin/ifconfig usb0 192.168.1.10 > > > > I have debug prints in the udc.c and u_ether.c using pr_debug and > > just a little hint, use any of the dev_*() macros next time, they'll > print the device name which helps figuring out which UDC you're > using. > > Based on ci_hdrc.0 above, I suppose it's chipidea and Peter Chen > maintains that one, it really helps adding maintainers to Cc list. > > > enable them when required using dynamic debug. Without running > > iperf, > > using ping gives me a sequence of prints as below: > > > > [ 277.434409] In eth_start_xmit > > [ 277.434517] In UDC irq > > [ 277.434553] In usb_gadget_giveback_request > > [ 277.434567] In tx_complete > > [ 277.435443] In UDC irq > > [ 277.435477] In usb_gadget_giveback_request > > [ 277.435491] In rx_complete > > [ 277.435517] In rx_submit > > [ 277.435601] In eth_start_xmit > > [ 277.436441] In UDC irq > > [ 277.436465] In usb_gadget_giveback_request > > [ 277.436478] In rx_complete > > [ 277.436493] In rx_submit > > [ 277.436520] In usb_gadget_giveback_request > > [ 277.436533] In tx_complete > > [ 278.434865] In eth_start_xmit > > [ 278.434959] In UDC irq > > [ 278.434993] In usb_gadget_giveback_request > > [ 278.435006] In tx_complete > > [ 278.435881] In UDC irq > > [ 278.435910] In usb_gadget_giveback_request > > [ 278.435923] In rx_complete > > [ 278.435946] In rx_submit > > > > After running iperf without debug prints and then enabling before > > using ping gives me a sequence of prints as below > > [ 81.989827] In UDC irq > > [ 81.989871] In usb_gadget_giveback_request > > [ 81.989886] In rx_complete > > [ 81.989905] In rx_submit > > [ 82.989892] In UDC irq > > [ 82.989951] In usb_gadget_giveback_request > > [ 82.989967] In rx_complete > > [ 82.989992] In rx_submit > > [ 83.990064] In UDC
Re: [PATCH] extcon: add MAX3355 driver
On 12/11/2014 08:28 AM, Sergei Shtylyov wrote:
> MAX3355E chip integrates a charge pump and comparators to enable a system with
> an integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
> device. In addition to sensing/controlling Vbus, the chip also passes thru the
> ID signal from the USB OTG connector. On some Renesas boards, this signal is
> just fed into the SoC thru a GPIO pin -- there's no real OTG controller, only
> host and gadget USB controllers sharing the same USB bus; however, we'd like
> to allow host or gadget drivers to be loaded depending on the cable type,
> hence
> the need for the MAX3355 extcon driver. The Vbus status signals are also wired
> to GPIOs (however, we're not currently intested in them), the OFFVBUS# signal
> is controlled by the host controllers, there's also the SHDN# signal wired to
> GPIO, which should be high for normal operation.
>
> Signed-off-by: Sergei Shtylyov
>
> ---
> The patch is against the 'extcon-next' branch of the 'extcon.git' repo.
>
> Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 ++
> drivers/extcon/Kconfig |6
> drivers/extcon/Makefile |1
> drivers/extcon/extcon-max3355.c | 122
>
> 4 files changed, 150 insertions(+)
>
> Index: extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
> ===
> --- /dev/null
> +++ extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
> @@ -0,0 +1,21 @@
> +MAX3355 USB OTG chip
Need manufactor information as following :
-> Maxim MAX3355
> +
> +
> +MAX3355 integrates a charge pump and comparators to enable a system with an
> +integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
> +device.
> +
> +Required properties:
> +- compatible: should be "maxim,max3355";
> +- maxim,shdn-gpio: should contain a phandle and GPIO specifier for the GPIO
> pin
> + connected to the MAX3355's SHDN# pin;
> +- maxim,id-gpio: should contain a phandle and GPIO specifier for the GPIO pin
> + connected to the MAX3355's ID_OUT pin.
> +
> +Example (Koelsch board):
> +
> + usb-otg {
> + compatible = "maxim,max3355";
> + maxim,shdn-gpio = <&gpio2 4 GPIO_ACTIVE_LOW>;
> + maxim,id-gpio = <&gpio5 31 GPIO_ACTIVE_HIGH>;
Kernel already supported the gpio helper function to get gpio from devicetree.
I prefer use follwoing style by using of_get_gpio()/of_get_gpio_flags() in
include/linux/of_gpio.h.
gpios = <&gpio2 4 GPIO_ACTIVE_LOW>, <&gpio5 31
GPIO_ACTIVE_HIGH>;
> + };
> Index: extcon/drivers/extcon/Kconfig
> ===
> --- extcon.orig/drivers/extcon/Kconfig
> +++ extcon/drivers/extcon/Kconfig
> @@ -45,6 +45,12 @@ config EXTCON_MAX14577
> Maxim MAX14577/77836. The MAX14577/77836 MUIC is a USB port accessory
> detector and switch.
>
> +config EXTCON_MAX3355
> + tristate "MAX3355 USB OTG EXTCON Support"
> + help
> + Say Y here to enable support for the USB host detection by MAX3355
> + OTG USB chip.
> +
> config EXTCON_MAX77693
> tristate "MAX77693 EXTCON Support"
> depends on MFD_MAX77693 && INPUT
> Index: extcon/drivers/extcon/Makefile
> ===
> --- extcon.orig/drivers/extcon/Makefile
> +++ extcon/drivers/extcon/Makefile
> @@ -7,6 +7,7 @@ obj-$(CONFIG_EXTCON_ADC_JACK) += extcon-
> obj-$(CONFIG_EXTCON_ARIZONA) += extcon-arizona.o
> obj-$(CONFIG_EXTCON_GPIO)+= extcon-gpio.o
> obj-$(CONFIG_EXTCON_MAX14577)+= extcon-max14577.o
> +obj-$(CONFIG_EXTCON_MAX3355) += extcon-max3355.o
> obj-$(CONFIG_EXTCON_MAX77693)+= extcon-max77693.o
> obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
> obj-$(CONFIG_EXTCON_PALMAS) += extcon-palmas.o
> Index: extcon/drivers/extcon/extcon-max3355.c
> ===
> --- /dev/null
> +++ extcon/drivers/extcon/extcon-max3355.c
> @@ -0,0 +1,122 @@
> +/*
> + * MAX3355 USB OTG chip extcon driver
ditto.
> + *
> + * Copyright (C) 2014 Cogent Embedded, Inc.
> + * Author: Sergei Shtylyov
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct max3355_data {
> + struct extcon_dev *edev;
> + int id_gpio;
> +};
> +
> +static const char *max3355_cable[] = {
> + [0] = "USB-HOST",
> + NULL,
> +};
> +
> +static irqreturn_t max3355_id_irq(int irq, void *dev_id)
> +{
> + struct max3355_data *
[PATCH] usb: hcd: add OTG ID signal sensing
On the Renesas R8A7791 SoC based boards there's MAX3355 USB OTG chip and mini-AB
USB connector corresponding to USB port 0 driven either by EHCI/OHCI or Renesas
USBHS gadget controller. And we'd like the host/gadget drivers to work based on
the cable type connected. An 'extcon' driver for MAX3355 has been written, so we
only need to bind to it via device tree which I'm doing in this patch.
I wasn't able to find a solution better than checking the cable type at the host
driver probe time and refusing to drive a host if B-cable is connected.
Signed-off-by: Sergei Shtylyov
---
The patch is against the 'usb-next' branch of Greg KH's 'usb.git' repo.
It needs the recent 'extcon' core in order to properly handle probe deferral.
drivers/usb/core/hcd.c | 18 ++
1 file changed, 18 insertions(+)
Index: usb/drivers/usb/core/hcd.c
===
--- usb.orig/drivers/usb/core/hcd.c
+++ usb/drivers/usb/core/hcd.c
@@ -42,6 +42,7 @@
#include
#include
+#include
#include
#include
#include
@@ -2632,6 +2633,23 @@ int usb_add_hcd(struct usb_hcd *hcd,
int retval;
struct usb_device *rhdev;
+ if (IS_ENABLED(CONFIG_EXTCON) &&
+ of_property_read_bool(hcd->self.controller->of_node, "extcon")) {
+ struct extcon_dev *edev;
+
+ edev = extcon_get_edev_by_phandle(hcd->self.controller, 0);
+ if (IS_ERR(edev))
+ return PTR_ERR(edev);
+
+ retval = extcon_get_cable_state(edev, "USB-HOST");
+ if (!retval) {
+ dev_err(hcd->self.controller,
+ "OTG B-cable plugged in, host driver won't
load\n");
+ return -EINVAL;
+ } else if (retval < 0)
+ return retval;
+ }
+
if (IS_ENABLED(CONFIG_USB_PHY) && !hcd->usb_phy) {
struct usb_phy *phy = usb_get_phy_dev(hcd->self.controller, 0);
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [xhci_hcd] USB3 device unplug breaks system suspend
Alan Stern wrote: > How about providing some information (system logs, etc.)? > > Alan Stern Hello, I've just added dmesg and lsusb output. If you need anything else, please let me know! With best wishes, Tobias -- 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: [xhci_hcd] USB3 device unplug breaks system suspend
On Tue, 16 Dec 2014, Tobias Jakobi wrote: > Hello, > > gregkh asked me to post this on the ml, so here it is: > https://bugzilla.kernel.org/show_bug.cgi?id=89801 How about providing some information (system logs, etc.)? 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
[xhci_hcd] USB3 device unplug breaks system suspend
Hello, gregkh asked me to post this on the ml, so here it is: https://bugzilla.kernel.org/show_bug.cgi?id=89801 With best wishes, Tobias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ACPICA: take ACPI_MTX_INTERPRETER in acpi_unload_table_id
On Tue, Dec 16, 2014 at 8:14 PM, Sergei Shtylyov
wrote:
> Hello.
>
> On 12/16/2014 07:12 PM, Octavian Purdila wrote:
>
>> acpi_tb_delete_namespace_by_owner expects ACPI_MTX_INTERPRETER to be
>> taken. This fixes the following issue:
>
>
>> ACPI Error: Mutex [0x0] is not acquired, cannot release
>> (20141107/utmutex-322)
>> Call Trace:
>>[] dump_stack+0x4f/0x7b
>>[] acpi_ut_release_mutex+0x47/0x67
>>[] acpi_tb_delete_namespace_by_owner+0x57/0x8d
>>[] acpi_unload_table_id+0x3a/0x5e
>
>
>> Signed-off-by: Octavian Purdila
>> ---
>> drivers/acpi/acpica/tbxface.c | 7 +++
>> 1 file changed, 7 insertions(+)
>
>
>> diff --git a/drivers/acpi/acpica/tbxface.c b/drivers/acpi/acpica/tbxface.c
>> index 6482b0d..9520ae1 100644
>> --- a/drivers/acpi/acpica/tbxface.c
>> +++ b/drivers/acpi/acpica/tbxface.c
>> @@ -281,6 +281,11 @@ acpi_status acpi_unload_table_id(acpi_owner_id id)
>>
>> ACPI_FUNCTION_TRACE(acpi_unload_table_id);
>>
>> + status = acpi_ut_acquire_mutex(ACPI_MTX_INTERPRETER);
>> + if (ACPI_FAILURE(status)) {
>> + return_ACPI_STATUS(status);
>> + }
>
>
>{} not needed here. Please run your patches thru scripts/checkpatch.pl,
> it should complain in this case.
>
I always run checkpatch. It does not complain.
>> +
>> /* Find table in the global table list */
>> for (i = 0; i < acpi_gbl_root_table_list.current_table_count; ++i)
>> {
>> if (id != acpi_gbl_root_table_list.tables[i].owner_id) {
>> @@ -297,6 +302,8 @@ acpi_status acpi_unload_table_id(acpi_owner_id id)
>> acpi_tb_set_table_loaded_flag(i, FALSE);
>> break;
>> }
>> +
>> + (void)acpi_ut_release_mutex(ACPI_MTX_INTERPRETER);
>
>
>Cast to *void* not necessary either.
>
AFAICS ACPICA has a slight different coding style than the rest of the
kernel and I kept using it in these patches. Rafael, please let me
know if I am wrong.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ACPICA: take ACPI_MTX_INTERPRETER in acpi_unload_table_id
Hello.
On 12/16/2014 07:12 PM, Octavian Purdila wrote:
acpi_tb_delete_namespace_by_owner expects ACPI_MTX_INTERPRETER to be
taken. This fixes the following issue:
ACPI Error: Mutex [0x0] is not acquired, cannot release (20141107/utmutex-322)
Call Trace:
[] dump_stack+0x4f/0x7b
[] acpi_ut_release_mutex+0x47/0x67
[] acpi_tb_delete_namespace_by_owner+0x57/0x8d
[] acpi_unload_table_id+0x3a/0x5e
Signed-off-by: Octavian Purdila
---
drivers/acpi/acpica/tbxface.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/acpi/acpica/tbxface.c b/drivers/acpi/acpica/tbxface.c
index 6482b0d..9520ae1 100644
--- a/drivers/acpi/acpica/tbxface.c
+++ b/drivers/acpi/acpica/tbxface.c
@@ -281,6 +281,11 @@ acpi_status acpi_unload_table_id(acpi_owner_id id)
ACPI_FUNCTION_TRACE(acpi_unload_table_id);
+ status = acpi_ut_acquire_mutex(ACPI_MTX_INTERPRETER);
+ if (ACPI_FAILURE(status)) {
+ return_ACPI_STATUS(status);
+ }
{} not needed here. Please run your patches thru scripts/checkpatch.pl, it
should complain in this case.
+
/* Find table in the global table list */
for (i = 0; i < acpi_gbl_root_table_list.current_table_count; ++i) {
if (id != acpi_gbl_root_table_list.tables[i].owner_id) {
@@ -297,6 +302,8 @@ acpi_status acpi_unload_table_id(acpi_owner_id id)
acpi_tb_set_table_loaded_flag(i, FALSE);
break;
}
+
+ (void)acpi_ut_release_mutex(ACPI_MTX_INTERPRETER);
Cast to *void* not necessary either.
[...]
WBR, Sergei
--
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 0/4] dln2: add support for ACPI
This patch sets adds support for ACPI enumeration for devices connected to the DLN2 bridge via a custom ACPI table. The first two patches fix a couple of issues with the ACPI load/unload table APIs. The 3rd patch adds ACPI support to the MFD driver and the last patch configures pull-up/pull-down on GPIO pins based on the APCI configuration. Octavian Purdila (4): ACPICA: take ACPI_MTX_INTERPRETER in acpi_unload_table_id ACPICA: don't release ACPI_MTX_TABLES in acpi_tb_install_standard_table mfd: dln2: add support for ACPI gpio: dln2: add support for ACPI pin configuration Documentation/acpi/dln2-acpi.txt | 62 ++ drivers/acpi/acpica/tbinstal.c | 1 - drivers/acpi/acpica/tbxface.c| 7 ++ drivers/gpio/gpio-dln2.c | 76 ++ drivers/mfd/dln2.c | 134 +++ 5 files changed, 279 insertions(+), 1 deletion(-) create mode 100644 Documentation/acpi/dln2-acpi.txt -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] mfd: dln2: add support for ACPI
This patch adds support to load a custom ACPI table that describes
devices connected via the DLN2 USB to I2C/SPI/GPIO bridge.
The ACPI table can be loaded either externally (from QEMU or with
CONFIG_ACPI_CUSTOM_DSDT) or it can be loaded as firmware file with the
name dln2.aml. The driver looks for an ACPI device entry with _HID set
to "DLN2" and makes it the ACPI companion for DLN2 USB
sub-drivers.
Signed-off-by: Octavian Purdila
---
Documentation/acpi/dln2-acpi.txt | 62 ++
drivers/mfd/dln2.c | 134 +++
2 files changed, 196 insertions(+)
create mode 100644 Documentation/acpi/dln2-acpi.txt
diff --git a/Documentation/acpi/dln2-acpi.txt b/Documentation/acpi/dln2-acpi.txt
new file mode 100644
index 000..d76605f
--- /dev/null
+++ b/Documentation/acpi/dln2-acpi.txt
@@ -0,0 +1,62 @@
+Diolan DLN2 custom APCI table
+
+The Diolan DLN2 is an USB to I2C/SPI/GPIO bridge and as such it can be used to
+connect to various I2C or SPI devices. Because these busses lack an enumeration
+protocol, the driver obtains various information about the device (such as I2C
+address and GPIO pins) from either ACPI or device tree.
+
+To allow enumerating devices and their properties via ACPI, the Diolan
+driver looks for an ACPI tree with the root _HID set to "DLN2". If
+it finds such an ACPI object it will set the ACPI companion to the
+DLN2 MFD driver and from their it will be propagated to all its
+sub-devices (I2C, GPIO, SPI).
+
+The user can either load the custom DSDT table with three methods:
+
+1. Via QEMU (see -acpitable)
+
+2. Via the CONFIG_ACPI_CUSTOM_DSDT kernel config option (see
+Documentation/acpi/dsdt-override.txt)
+
+3. By placing the custom DSDT in the firmware paths in a file name
+dln2.aml.
+
+Here is an example ACPI table that enumerates a BMC150 accelerometer
+and defines its I2C address and GPIO pin used as an interrupt source:
+
+DefinitionBlock ("ssdt.aml", "SSDT", 1, "INTEL ", "CpuDptf", 0x0003)
+{
+ Device (DLN0)
+ {
+ Name (_ADR, Zero)
+ Name (_HID, "DLN2000")
+
+ Device (STAC)
+ {
+ Name (_ADR, Zero)
+ Name (_HID, "BMC150A")
+ Name (_CID, "INTACCL")
+ Name (_UID, One)
+
+ Method (_CRS, 0, Serialized)
+ {
+ Name (RBUF, ResourceTemplate ()
+ {
+ I2cSerialBus (0x0010,
ControllerInitiated, 0x00061A80,
+ AddressingMode7Bit,
"\\DLN0",
+ 0x00, ResourceConsumer, ,)
+
+ GpioInt (Level, ActiveHigh, Exclusive,
PullDown, 0x,
+"\\DLN0", 0x00,
ResourceConsumer, , )
+ { // Pin list
+ 0
+ }
+ })
+ Return (RBUF)
+ }
+ }
+ }
+}
+
+The resources defined in the devices under the DLN0 are those
+supported by the I2C, GPIO and SPI sub-systems.
diff --git a/drivers/mfd/dln2.c b/drivers/mfd/dln2.c
index f9c4a0b..93f6d1d 100644
--- a/drivers/mfd/dln2.c
+++ b/drivers/mfd/dln2.c
@@ -23,6 +23,8 @@
#include
#include
#include
+#include
+#include
struct dln2_header {
__le16 size;
@@ -714,6 +716,134 @@ static void dln2_stop(struct dln2_dev *dln2)
dln2_stop_rx_urbs(dln2);
}
+
+#if IS_ENABLED(CONFIG_ACPI)
+
+static struct dln2_acpi_info {
+ const struct firmware *fw;
+ acpi_owner_id table_id;
+ struct acpi_device *dev;
+ int users;
+} dln2_acpi_info;
+
+static DEFINE_MUTEX(dln2_acpi_lock);
+
+static acpi_status dln2_find_acpi_handle(acpi_handle handle, u32 level,
+void *ctxt, void **retv)
+{
+ acpi_handle *dln2_handle = (acpi_handle *)retv;
+
+ *dln2_handle = handle;
+
+ return AE_CTRL_TERMINATE;
+}
+
+static void dln2_probe_acpi(struct dln2_dev *dln2)
+{
+ struct device *dev = &dln2->interface->dev;
+ struct dln2_acpi_info *ai = &dln2_acpi_info;
+ acpi_handle h = NULL;
+ int ret;
+ bool fw_loaded = false;
+
+ mutex_lock(&dln2_acpi_lock);
+
+ if (ai->dev)
+ goto out_success;
+
+ /*
+* Look for the DLN2000 HID in case the ACPI table was loaded
+* externally (e.g. from qemu).
+*/
+ acpi_get_devices("DLN2", dln2_find_acpi_handle, NULL, &h);
+ if (!h) {
+ /* Try to load the ACPI table via a firmware file */
+ ret = request_firmware(&ai->fw, "dln2.aml", NULL);
+ if (ret)
+ goto o
[PATCH 1/4] ACPICA: take ACPI_MTX_INTERPRETER in acpi_unload_table_id
acpi_tb_delete_namespace_by_owner expects ACPI_MTX_INTERPRETER to be
taken. This fixes the following issue:
ACPI Error: Mutex [0x0] is not acquired, cannot release (20141107/utmutex-322)
Call Trace:
[] dump_stack+0x4f/0x7b
[] acpi_ut_release_mutex+0x47/0x67
[] acpi_tb_delete_namespace_by_owner+0x57/0x8d
[] acpi_unload_table_id+0x3a/0x5e
Signed-off-by: Octavian Purdila
---
drivers/acpi/acpica/tbxface.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/acpi/acpica/tbxface.c b/drivers/acpi/acpica/tbxface.c
index 6482b0d..9520ae1 100644
--- a/drivers/acpi/acpica/tbxface.c
+++ b/drivers/acpi/acpica/tbxface.c
@@ -281,6 +281,11 @@ acpi_status acpi_unload_table_id(acpi_owner_id id)
ACPI_FUNCTION_TRACE(acpi_unload_table_id);
+ status = acpi_ut_acquire_mutex(ACPI_MTX_INTERPRETER);
+ if (ACPI_FAILURE(status)) {
+ return_ACPI_STATUS(status);
+ }
+
/* Find table in the global table list */
for (i = 0; i < acpi_gbl_root_table_list.current_table_count; ++i) {
if (id != acpi_gbl_root_table_list.tables[i].owner_id) {
@@ -297,6 +302,8 @@ acpi_status acpi_unload_table_id(acpi_owner_id id)
acpi_tb_set_table_loaded_flag(i, FALSE);
break;
}
+
+ (void)acpi_ut_release_mutex(ACPI_MTX_INTERPRETER);
return_ACPI_STATUS(status);
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] ACPICA: don't release ACPI_MTX_TABLES in acpi_tb_install_standard_table
ACPI_MTX_TABLES is taken and released by the callers of acpi_tb_install_standard_table so releasing it in the function itself is causing the following error if the table is reloaded: ACPI Error: Mutex [0x2] is not acquired, cannot release (20141107/utmutex-321) Call Trace: [] dump_stack+0x4f/0x7b [] acpi_ut_release_mutex+0x47/0x67 [] acpi_load_table+0x73/0xcb Signed-off-by: Octavian Purdila --- drivers/acpi/acpica/tbinstal.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/acpi/acpica/tbinstal.c b/drivers/acpi/acpica/tbinstal.c index 755b90c..c0b39f3 100644 --- a/drivers/acpi/acpica/tbinstal.c +++ b/drivers/acpi/acpica/tbinstal.c @@ -346,7 +346,6 @@ acpi_tb_install_standard_table(acpi_physical_address address, */ acpi_tb_uninstall_table(&new_table_desc); *table_index = i; - (void)acpi_ut_release_mutex(ACPI_MTX_TABLES); return_ACPI_STATUS(AE_OK); } } -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] gpio: dln2: add support for ACPI pin configuration
This patch configures the pull-up/pull-down properties based on the
ACPI configuration. It scans the children of the DLN2 root entry and
looks for GPIO resources and applies the pull-up/pull-down
configurations on the pins.
Signed-off-by: Octavian Purdila
---
drivers/gpio/gpio-dln2.c | 76
1 file changed, 76 insertions(+)
diff --git a/drivers/gpio/gpio-dln2.c b/drivers/gpio/gpio-dln2.c
index 2fdb138..98189d5 100644
--- a/drivers/gpio/gpio-dln2.c
+++ b/drivers/gpio/gpio-dln2.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#define DLN2_GPIO_ID 0x01
@@ -36,6 +37,10 @@
#define DLN2_GPIO_PIN_GET_DIRECTIONDLN2_CMD(0x14, DLN2_GPIO_ID)
#define DLN2_GPIO_PIN_SET_EVENT_CFGDLN2_CMD(0x1E, DLN2_GPIO_ID)
#define DLN2_GPIO_PIN_GET_EVENT_CFGDLN2_CMD(0x1F, DLN2_GPIO_ID)
+#define CMD_GPIO_PIN_PULLUP_ENABLE DLN2_CMD(0x18, DLN2_GPIO_ID)
+#define CMD_GPIO_PIN_PULLUP_DISABLEDLN2_CMD(0x19, DLN2_GPIO_ID)
+#define CMD_GPIO_PIN_PULLDOWN_ENABLE DLN2_CMD(0x20, DLN2_GPIO_ID)
+#define CMD_GPIO_PIN_PULLDOWN_DISABLE DLN2_CMD(0x21, DLN2_GPIO_ID)
#define DLN2_GPIO_EVENT_NONE 0
#define DLN2_GPIO_EVENT_CHANGE 1
@@ -428,6 +433,75 @@ static void dln2_gpio_event(struct platform_device *pdev,
u16 echo,
}
}
+#if IS_ENABLED(CONFIG_ACPI)
+static int dln2_gpio_do_acpi_setup(struct acpi_resource *ares, void *data)
+{
+ int i;
+ u16 cmd[2];
+ const char *info;
+ struct dln2_gpio *dln2 = data;
+ const struct acpi_resource_gpio *agpio = &ares->data.gpio;
+
+ if (ares->type != ACPI_RESOURCE_TYPE_GPIO)
+ return 1;
+
+ switch (agpio->pin_config) {
+ case ACPI_PIN_CONFIG_PULLUP:
+ info = "pullup";
+ cmd[0] = CMD_GPIO_PIN_PULLDOWN_DISABLE;
+ cmd[1] = CMD_GPIO_PIN_PULLUP_ENABLE;
+ break;
+ case ACPI_PIN_CONFIG_PULLDOWN:
+ info = "pulldown";
+ cmd[0] = CMD_GPIO_PIN_PULLDOWN_ENABLE;
+ cmd[1] = CMD_GPIO_PIN_PULLUP_DISABLE;
+ break;
+ case ACPI_PIN_CONFIG_NOPULL:
+ info = "nopull";
+ cmd[0] = CMD_GPIO_PIN_PULLDOWN_DISABLE;
+ cmd[1] = CMD_GPIO_PIN_PULLUP_DISABLE;
+ break;
+ default:
+ return 1;
+ }
+
+ for (i = 0; i < agpio->pin_table_length; i++) {
+ int pin = agpio->pin_table[i];
+
+ dev_info(dln2->gpio.dev, "setting %s on pin %d\n", info, pin);
+ dln2_gpio_pin_cmd(dln2, cmd[0], pin);
+ dln2_gpio_pin_cmd(dln2, cmd[1], pin);
+ }
+
+ return 1;
+}
+
+static void dln2_gpio_acpi_setup(struct dln2_gpio *dln2)
+{
+ struct acpi_device *adev, *child;
+ acpi_handle handle;
+
+ handle = ACPI_HANDLE(dln2->gpio.dev);
+ if (!handle || acpi_bus_get_device(handle, &adev))
+ return;
+
+ list_for_each_entry(child, &adev->children, node) {
+ LIST_HEAD(res);
+ int ret;
+
+ ret = acpi_dev_get_resources(child, &res,
+dln2_gpio_do_acpi_setup, dln2);
+ if (ret < 0)
+ continue;
+ acpi_dev_free_resource_list(&res);
+ }
+}
+#else
+static void dln2_gpio_acpi_setup(struct dln2_gpio *dln2)
+{
+}
+#endif
+
static int dln2_gpio_probe(struct platform_device *pdev)
{
struct dln2_gpio *dln2;
@@ -492,6 +566,8 @@ static int dln2_gpio_probe(struct platform_device *pdev)
goto out_gpiochip_remove;
}
+ dln2_gpio_acpi_setup(dln2);
+
return 0;
out_gpiochip_remove:
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XHCI fails on high-speed data transfer
On Tue, Dec 16, 2014 at 10:12:18AM +0100, Stephan Alz wrote: > Hello > > I have a new Thinkpad T440p running debian with custom kernel 3.14.19. When I > connect an external 2TB USB3 hdd, after 50-60Gb data written > XHCI drops the usb device (just like I would pull the plug on it) then it > comes back: Any chance you can use a newer kernel like 3.18? Lots of xhci changes have happened since 3.14 was released, especially for the UAS driver which you probably are using for this disk. 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 v2 2/4] gpio: dln2: use bus_sync_unlock instead of scheduling work
Use the irq_chip bus_sync_unlock method to update hardware registers
instead of scheduling work from the mask/unmask methods. This simplifies
a bit the driver and make it more uniform with the other GPIO IRQ
drivers.
Signed-off-by: Octavian Purdila
---
drivers/gpio/gpio-dln2.c | 92 +++-
1 file changed, 51 insertions(+), 41 deletions(-)
diff --git a/drivers/gpio/gpio-dln2.c b/drivers/gpio/gpio-dln2.c
index 28a62c4..2fdb138 100644
--- a/drivers/gpio/gpio-dln2.c
+++ b/drivers/gpio/gpio-dln2.c
@@ -47,13 +47,6 @@
#define DLN2_GPIO_MAX_PINS 32
-struct dln2_irq_work {
- struct work_struct work;
- struct dln2_gpio *dln2;
- int pin;
- int type;
-};
-
struct dln2_gpio {
struct platform_device *pdev;
struct gpio_chip gpio;
@@ -66,7 +59,10 @@ struct dln2_gpio {
/* active IRQs - not synced to hardware */
DECLARE_BITMAP(unmasked_irqs, DLN2_GPIO_MAX_PINS);
- struct dln2_irq_work *irq_work;
+ /* active IRQS - synced to hardware */
+ DECLARE_BITMAP(enabled_irqs, DLN2_GPIO_MAX_PINS);
+ int irq_type[DLN2_GPIO_MAX_PINS];
+ struct mutex irq_lock;
};
struct dln2_gpio_pin {
@@ -296,18 +292,6 @@ static int dln2_gpio_set_event_cfg(struct dln2_gpio *dln2,
unsigned pin,
&req, sizeof(req));
}
-static void dln2_irq_work(struct work_struct *w)
-{
- struct dln2_irq_work *iw = container_of(w, struct dln2_irq_work, work);
- struct dln2_gpio *dln2 = iw->dln2;
- u8 type = iw->type & DLN2_GPIO_EVENT_MASK;
-
- if (test_bit(iw->pin, dln2->unmasked_irqs))
- dln2_gpio_set_event_cfg(dln2, iw->pin, type, 0);
- else
- dln2_gpio_set_event_cfg(dln2, iw->pin, DLN2_GPIO_EVENT_NONE, 0);
-}
-
static void dln2_irq_unmask(struct irq_data *irqd)
{
struct gpio_chip *gc = irq_data_get_irq_chip_data(irqd);
@@ -315,7 +299,6 @@ static void dln2_irq_unmask(struct irq_data *irqd)
int pin = irqd_to_hwirq(irqd);
set_bit(pin, dln2->unmasked_irqs);
- schedule_work(&dln2->irq_work[pin].work);
}
static void dln2_irq_mask(struct irq_data *irqd)
@@ -325,7 +308,6 @@ static void dln2_irq_mask(struct irq_data *irqd)
int pin = irqd_to_hwirq(irqd);
clear_bit(pin, dln2->unmasked_irqs);
- schedule_work(&dln2->irq_work[pin].work);
}
static int dln2_irq_set_type(struct irq_data *irqd, unsigned type)
@@ -336,19 +318,19 @@ static int dln2_irq_set_type(struct irq_data *irqd,
unsigned type)
switch (type) {
case IRQ_TYPE_LEVEL_HIGH:
- dln2->irq_work[pin].type = DLN2_GPIO_EVENT_LVL_HIGH;
+ dln2->irq_type[pin] = DLN2_GPIO_EVENT_LVL_HIGH;
break;
case IRQ_TYPE_LEVEL_LOW:
- dln2->irq_work[pin].type = DLN2_GPIO_EVENT_LVL_LOW;
+ dln2->irq_type[pin] = DLN2_GPIO_EVENT_LVL_LOW;
break;
case IRQ_TYPE_EDGE_BOTH:
- dln2->irq_work[pin].type = DLN2_GPIO_EVENT_CHANGE;
+ dln2->irq_type[pin] = DLN2_GPIO_EVENT_CHANGE;
break;
case IRQ_TYPE_EDGE_RISING:
- dln2->irq_work[pin].type = DLN2_GPIO_EVENT_CHANGE_RISING;
+ dln2->irq_type[pin] = DLN2_GPIO_EVENT_CHANGE_RISING;
break;
case IRQ_TYPE_EDGE_FALLING:
- dln2->irq_work[pin].type = DLN2_GPIO_EVENT_CHANGE_FALLING;
+ dln2->irq_type[pin] = DLN2_GPIO_EVENT_CHANGE_FALLING;
break;
default:
return -EINVAL;
@@ -357,11 +339,50 @@ static int dln2_irq_set_type(struct irq_data *irqd,
unsigned type)
return 0;
}
+static void dln2_irq_bus_lock(struct irq_data *irqd)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(irqd);
+ struct dln2_gpio *dln2 = container_of(gc, struct dln2_gpio, gpio);
+
+ mutex_lock(&dln2->irq_lock);
+}
+
+static void dln2_irq_bus_unlock(struct irq_data *irqd)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(irqd);
+ struct dln2_gpio *dln2 = container_of(gc, struct dln2_gpio, gpio);
+ int pin = irqd_to_hwirq(irqd);
+ int enabled, unmasked;
+ unsigned type;
+ int ret;
+
+ enabled = test_bit(pin, dln2->enabled_irqs);
+ unmasked = test_bit(pin, dln2->unmasked_irqs);
+
+ if (enabled != unmasked) {
+ if (unmasked) {
+ type = dln2->irq_type[pin] & DLN2_GPIO_EVENT_MASK;
+ set_bit(pin, dln2->enabled_irqs);
+ } else {
+ type = DLN2_GPIO_EVENT_NONE;
+ clear_bit(pin, dln2->enabled_irqs);
+ }
+
+ ret = dln2_gpio_set_event_cfg(dln2, pin, type, 0);
+ if (ret)
+ dev_err(dln2->gpio.dev, "failed to set event\n");
+ }
+
+ mutex_unlock(&dln2->irq_lock);
+}
+
static struct irq_chip dln2_gpio_irqchip
[PATCH v2 0/4] DLN2 fixes related to suspend/resume
This 2nd patch set addresses Johan review comments: * Fix an issue introduced by v1 where we can get a use after free in the error path of probe * Add start/stop RX URBs helpers * move the suspend/resume routines above the module device table * used GFP_NOIO in resume Octavian Purdila (4): gpio: dln2: fix issue when an IRQ is unmasked then enabled gpio: dln2: use bus_sync_unlock instead of scheduling work mfd: dln2: add start/stop RX URBs helpers mfd: dln2: add suspend/resume functionality drivers/gpio/gpio-dln2.c | 141 +++ drivers/mfd/dln2.c | 71 2 files changed, 117 insertions(+), 95 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] gpio: dln2: fix issue when an IRQ is unmasked then enabled
As noticed during suspend/resume operations, the IRQ can be unmasked
then disabled in suspend and eventually enabled in resume, but without
being unmasked.
The current implementation does not take into account interactions
between mask/unmask and enable/disable interrupts, and thus in the
above scenarios the IRQs remain unactive.
To fix this we removed the enable/disable operations as they fallback
to mask/unmask anyway.
We also remove the pending bitmaks as it is already done in irq_data
(i.e. IRQS_PENDING).
Signed-off-by: Octavian Purdila
---
drivers/gpio/gpio-dln2.c | 53 +++-
1 file changed, 7 insertions(+), 46 deletions(-)
diff --git a/drivers/gpio/gpio-dln2.c b/drivers/gpio/gpio-dln2.c
index 978b51e..28a62c4 100644
--- a/drivers/gpio/gpio-dln2.c
+++ b/drivers/gpio/gpio-dln2.c
@@ -64,9 +64,8 @@ struct dln2_gpio {
*/
DECLARE_BITMAP(output_enabled, DLN2_GPIO_MAX_PINS);
- DECLARE_BITMAP(irqs_masked, DLN2_GPIO_MAX_PINS);
- DECLARE_BITMAP(irqs_enabled, DLN2_GPIO_MAX_PINS);
- DECLARE_BITMAP(irqs_pending, DLN2_GPIO_MAX_PINS);
+ /* active IRQs - not synced to hardware */
+ DECLARE_BITMAP(unmasked_irqs, DLN2_GPIO_MAX_PINS);
struct dln2_irq_work *irq_work;
};
@@ -303,29 +302,19 @@ static void dln2_irq_work(struct work_struct *w)
struct dln2_gpio *dln2 = iw->dln2;
u8 type = iw->type & DLN2_GPIO_EVENT_MASK;
- if (test_bit(iw->pin, dln2->irqs_enabled))
+ if (test_bit(iw->pin, dln2->unmasked_irqs))
dln2_gpio_set_event_cfg(dln2, iw->pin, type, 0);
else
dln2_gpio_set_event_cfg(dln2, iw->pin, DLN2_GPIO_EVENT_NONE, 0);
}
-static void dln2_irq_enable(struct irq_data *irqd)
-{
- struct gpio_chip *gc = irq_data_get_irq_chip_data(irqd);
- struct dln2_gpio *dln2 = container_of(gc, struct dln2_gpio, gpio);
- int pin = irqd_to_hwirq(irqd);
-
- set_bit(pin, dln2->irqs_enabled);
- schedule_work(&dln2->irq_work[pin].work);
-}
-
-static void dln2_irq_disable(struct irq_data *irqd)
+static void dln2_irq_unmask(struct irq_data *irqd)
{
struct gpio_chip *gc = irq_data_get_irq_chip_data(irqd);
struct dln2_gpio *dln2 = container_of(gc, struct dln2_gpio, gpio);
int pin = irqd_to_hwirq(irqd);
- clear_bit(pin, dln2->irqs_enabled);
+ set_bit(pin, dln2->unmasked_irqs);
schedule_work(&dln2->irq_work[pin].work);
}
@@ -335,27 +324,8 @@ static void dln2_irq_mask(struct irq_data *irqd)
struct dln2_gpio *dln2 = container_of(gc, struct dln2_gpio, gpio);
int pin = irqd_to_hwirq(irqd);
- set_bit(pin, dln2->irqs_masked);
-}
-
-static void dln2_irq_unmask(struct irq_data *irqd)
-{
- struct gpio_chip *gc = irq_data_get_irq_chip_data(irqd);
- struct dln2_gpio *dln2 = container_of(gc, struct dln2_gpio, gpio);
- struct device *dev = dln2->gpio.dev;
- int pin = irqd_to_hwirq(irqd);
-
- if (test_and_clear_bit(pin, dln2->irqs_pending)) {
- int irq;
-
- irq = irq_find_mapping(dln2->gpio.irqdomain, pin);
- if (!irq) {
- dev_err(dev, "pin %d not mapped to IRQ\n", pin);
- return;
- }
-
- generic_handle_irq(irq);
- }
+ clear_bit(pin, dln2->unmasked_irqs);
+ schedule_work(&dln2->irq_work[pin].work);
}
static int dln2_irq_set_type(struct irq_data *irqd, unsigned type)
@@ -389,8 +359,6 @@ static int dln2_irq_set_type(struct irq_data *irqd,
unsigned type)
static struct irq_chip dln2_gpio_irqchip = {
.name = "dln2-irq",
- .irq_enable = dln2_irq_enable,
- .irq_disable = dln2_irq_disable,
.irq_mask = dln2_irq_mask,
.irq_unmask = dln2_irq_unmask,
.irq_set_type = dln2_irq_set_type,
@@ -425,13 +393,6 @@ static void dln2_gpio_event(struct platform_device *pdev,
u16 echo,
return;
}
- if (!test_bit(pin, dln2->irqs_enabled))
- return;
- if (test_bit(pin, dln2->irqs_masked)) {
- set_bit(pin, dln2->irqs_pending);
- return;
- }
-
switch (dln2->irq_work[pin].type) {
case DLN2_GPIO_EVENT_CHANGE_RISING:
if (event->value)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/4] mfd: dln2: add start/stop RX URBs helpers
This is in preparation for adding suspend / resume support.
Signed-off-by: Octavian Purdila
---
drivers/mfd/dln2.c | 51 +--
1 file changed, 41 insertions(+), 10 deletions(-)
diff --git a/drivers/mfd/dln2.c b/drivers/mfd/dln2.c
index 6d49685..75358d2 100644
--- a/drivers/mfd/dln2.c
+++ b/drivers/mfd/dln2.c
@@ -587,12 +587,19 @@ static void dln2_free_rx_urbs(struct dln2_dev *dln2)
int i;
for (i = 0; i < DLN2_MAX_URBS; i++) {
- usb_kill_urb(dln2->rx_urb[i]);
usb_free_urb(dln2->rx_urb[i]);
kfree(dln2->rx_buf[i]);
}
}
+static void dln2_stop_rx_urbs(struct dln2_dev *dln2)
+{
+ int i;
+
+ for (i = 0; i < DLN2_MAX_URBS; i++)
+ usb_kill_urb(dln2->rx_urb[i]);
+}
+
static void dln2_free(struct dln2_dev *dln2)
{
dln2_free_rx_urbs(dln2);
@@ -604,9 +611,7 @@ static int dln2_setup_rx_urbs(struct dln2_dev *dln2,
struct usb_host_interface *hostif)
{
int i;
- int ret;
const int rx_max_size = DLN2_RX_BUF_SIZE;
- struct device *dev = &dln2->interface->dev;
for (i = 0; i < DLN2_MAX_URBS; i++) {
dln2->rx_buf[i] = kmalloc(rx_max_size, GFP_KERNEL);
@@ -621,7 +626,19 @@ static int dln2_setup_rx_urbs(struct dln2_dev *dln2,
usb_rcvbulkpipe(dln2->usb_dev, dln2->ep_in),
dln2->rx_buf[i], rx_max_size, dln2_rx, dln2);
- ret = usb_submit_urb(dln2->rx_urb[i], GFP_KERNEL);
+ }
+
+ return 0;
+}
+
+static int dln2_start_rx_urbs(struct dln2_dev *dln2, gfp_t gfp)
+{
+ struct device *dev = &dln2->interface->dev;
+ int ret;
+ int i;
+
+ for (i = 0; i < DLN2_MAX_URBS; i++) {
+ ret = usb_submit_urb(dln2->rx_urb[i], gfp);
if (ret < 0) {
dev_err(dev, "failed to submit RX URB: %d\n", ret);
return ret;
@@ -665,9 +682,8 @@ static const struct mfd_cell dln2_devs[] = {
},
};
-static void dln2_disconnect(struct usb_interface *interface)
+static void dln2_stop(struct dln2_dev *dln2)
{
- struct dln2_dev *dln2 = usb_get_intfdata(interface);
int i, j;
/* don't allow starting new transfers */
@@ -696,6 +712,14 @@ static void dln2_disconnect(struct usb_interface
*interface)
/* wait for transfers to end */
wait_event(dln2->disconnect_wq, !dln2->active_transfers);
+ dln2_stop_rx_urbs(dln2);
+}
+static void dln2_disconnect(struct usb_interface *interface)
+{
+ struct dln2_dev *dln2 = usb_get_intfdata(interface);
+
+ dln2_stop(dln2);
+
mfd_remove_devices(&interface->dev);
dln2_free(dln2);
@@ -738,23 +762,30 @@ static int dln2_probe(struct usb_interface *interface,
ret = dln2_setup_rx_urbs(dln2, hostif);
if (ret)
- goto out_cleanup;
+ goto out_free;
+
+ ret = dln2_start_rx_urbs(dln2, GFP_KERNEL);
+ if (ret)
+ goto out_stop_rx;
ret = dln2_hw_init(dln2);
if (ret < 0) {
dev_err(dev, "failed to initialize hardware\n");
- goto out_cleanup;
+ goto out_stop_rx;
}
ret = mfd_add_hotplug_devices(dev, dln2_devs, ARRAY_SIZE(dln2_devs));
if (ret != 0) {
dev_err(dev, "failed to add mfd devices to core\n");
- goto out_cleanup;
+ goto out_stop_rx;
}
return 0;
-out_cleanup:
+out_stop_rx:
+ dln2_stop_rx_urbs(dln2);
+
+out_free:
dln2_free(dln2);
return ret;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/4] mfd: dln2: add suspend/resume functionality
Without suspend/resume functionality in the USB driver the USB core
will disconnect and reconnect the DLN2 port and because the GPIO
framework does not yet support removal of an in-use controller a
suspend/resume operation will result in a crash.
This patch provides suspend and resume functions for the DLN2 driver
so that the above scenario is avoided.
Signed-off-by: Octavian Purdila
---
drivers/mfd/dln2.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/mfd/dln2.c b/drivers/mfd/dln2.c
index 75358d2..f9c4a0b 100644
--- a/drivers/mfd/dln2.c
+++ b/drivers/mfd/dln2.c
@@ -791,6 +791,24 @@ out_free:
return ret;
}
+static int dln2_suspend(struct usb_interface *iface, pm_message_t message)
+{
+ struct dln2_dev *dln2 = usb_get_intfdata(iface);
+
+ dln2_stop(dln2);
+
+ return 0;
+}
+
+static int dln2_resume(struct usb_interface *iface)
+{
+ struct dln2_dev *dln2 = usb_get_intfdata(iface);
+
+ dln2->disconnect = false;
+
+ return dln2_start_rx_urbs(dln2, GFP_NOIO);
+}
+
static const struct usb_device_id dln2_table[] = {
{ USB_DEVICE(0xa257, 0x2013) },
{ }
@@ -803,6 +821,8 @@ static struct usb_driver dln2_driver = {
.probe = dln2_probe,
.disconnect = dln2_disconnect,
.id_table = dln2_table,
+ .suspend = dln2_suspend,
+ .resume = dln2_resume,
};
module_usb_driver(dln2_driver);
--
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
[PATCHv3 11/19] Documentation: usb: NCM function testing
Summary of how to test NCM function of USB gadget. Signed-off-by: Andrzej Pietrasiewicz --- Documentation/usb/gadget-testing.txt | 34 ++ 1 file changed, 34 insertions(+) diff --git a/Documentation/usb/gadget-testing.txt b/Documentation/usb/gadget-testing.txt index c2f148d..493f79b 100644 --- a/Documentation/usb/gadget-testing.txt +++ b/Documentation/usb/gadget-testing.txt @@ -10,6 +10,7 @@ provided by gadgets. 7. LOOPBACK function 8. MASS STORAGE function 9. MIDI function +10. NCM function 1. ACM function @@ -366,3 +367,36 @@ $ aconnect 24:0 128:0 # try it on the host After the gadget's MIDI port is connected to timidity's MIDI port, whatever is played at the gadget side with aplaymidi -l is audible in host's speakers/headphones. + +10. NCM function + + +The function is provided by usb_f_ncm.ko module. + +Function-specific configfs interface + + +The function name to use when creating the function directory is "ncm". +The NCM function provides these attributes in its function directory: + + ifname - network device interface name associated with this + function instance + qmult - queue length multiplier for high and super speed + host_addr - MAC address of host's end of this + Ethernet over USB link + dev_addr- MAC address of device's end of this + Ethernet over USB link + +and after creating the functions/ncm. they contain default +values: qmult is 5, dev_addr and host_addr are randomly selected. +Except for ifname they can be written to until the function is linked to a +configuration. The ifname is read-only and contains the name of the interface +which was assigned by the net core, e. g. usb0. + +Testing the NCM function + + +Configure IP addresses of the device and the host. Then: + +On the device: ping +On the host: ping -- 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
[PATCHv3 04/19] Documentation: usb: ECM subset function testing
Summary of how to test ECM subset function of USB gadget. Signed-off-by: Andrzej Pietrasiewicz --- Documentation/usb/gadget-testing.txt | 34 ++ 1 file changed, 34 insertions(+) diff --git a/Documentation/usb/gadget-testing.txt b/Documentation/usb/gadget-testing.txt index 7df8785..b40db75 100644 --- a/Documentation/usb/gadget-testing.txt +++ b/Documentation/usb/gadget-testing.txt @@ -3,6 +3,7 @@ provided by gadgets. 1. ACM function 2. ECM function +3. ECM subset function 1. ACM function @@ -66,3 +67,36 @@ Configure IP addresses of the device and the host. Then: On the device: ping On the host: ping + +3. ECM subset function +== + +The function is provided by usb_f_ecm_subset.ko module. + +Function-specific configfs interface + + +The function name to use when creating the function directory is "geth". +The ECM subset function provides these attributes in its function directory: + + ifname - network device interface name associated with this + function instance + qmult - queue length multiplier for high and super speed + host_addr - MAC address of host's end of this + Ethernet over USB link + dev_addr- MAC address of device's end of this + Ethernet over USB link + +and after creating the functions/ecm. they contain default +values: qmult is 5, dev_addr and host_addr are randomly selected. +Except for ifname they can be written to until the function is linked to a +configuration. The ifname is read-only and contains the name of the interface +which was assigned by the net core, e. g. usb0. + +Testing the ECM subset function +--- + +Configure IP addresses of the device and the host. Then: + +On the device: ping +On the host: ping -- 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
[PATCHv3 17/19] Documentation: usb: UAC1 function testing
Summary of how to test UAC1 function of USB gadget. Signed-off-by: Andrzej Pietrasiewicz --- Documentation/usb/gadget-testing.txt | 27 +++ 1 file changed, 27 insertions(+) diff --git a/Documentation/usb/gadget-testing.txt b/Documentation/usb/gadget-testing.txt index 73a5b0c..40d22d8 100644 --- a/Documentation/usb/gadget-testing.txt +++ b/Documentation/usb/gadget-testing.txt @@ -16,6 +16,7 @@ provided by gadgets. 13. RNDIS function 14. SERIAL function 15. SOURCESINK function +16. UAC1 function 1. ACM function @@ -587,3 +588,29 @@ device: run the gadget host: test-usb http://www.linux-usb.org/usbtest/testusb.c + +16. UAC1 function += + +The function is provided by usb_f_uac1.ko module. + +Function-specific configfs interface + + +The function name to use when creating the function directory is "uac1". +The uac1 function provides these attributes in its function directory: + + audio_buf_size - audio buffer size + fn_cap - capture pcm device file name + fn_cntl - control device file name + fn_play - playback pcm device file name + req_buf_size - ISO OUT endpoint request buffer size + req_count - ISO OUT endpoint request count + +The attributes have sane default values. + +Testing the UAC1 function +- + +device: run the gadget +host: aplay -l # should list our USB Audio Gadget -- 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
[PATCHv3 10/19] Documentation: usb: MIDI function testing
Summary of how to test MIDI function of USB gadget. Signed-off-by: Andrzej Pietrasiewicz --- Documentation/usb/gadget-testing.txt | 84 1 file changed, 84 insertions(+) diff --git a/Documentation/usb/gadget-testing.txt b/Documentation/usb/gadget-testing.txt index 01b9ffe..c2f148d 100644 --- a/Documentation/usb/gadget-testing.txt +++ b/Documentation/usb/gadget-testing.txt @@ -9,6 +9,7 @@ provided by gadgets. 6. HID function 7. LOOPBACK function 8. MASS STORAGE function +9. MIDI function 1. ACM function @@ -282,3 +283,86 @@ Testing the MASS STORAGE function device: connect the gadget, enable it host: dmesg, see the USB drives appear (if system configured to automatically mount) + +9. MIDI function + + +The function is provided by usb_f_midi.ko module. + +Function-specific configfs interface + + +The function name to use when creating the function directory is "midi". +The MIDI function provides these attributes in its function directory: + + buflen - MIDI buffer length + id - ID string for the USB MIDI adapter + in_ports- number of MIDI input ports + index - index value for the USB MIDI adapter + out_ports - number of MIDI output ports + qlen- USB read request queue length + +Testing the MIDI function +- + +There are two cases: playing a mid from the gadget to +the host and playing a mid from the host to the gadget. + +1) Playing a mid from the gadget to the host +host) + +$ arecordmidi -l + PortClient name Port name + 14:0Midi Through Midi Through Port-0 + 24:0MIDI Gadget MIDI Gadget MIDI 1 +$ arecordmidi -p 24:0 from_gadget.mid + +gadget) + +$ aplaymidi -l + PortClient name Port name + 20:0f_midi f_midi + +$ aplaymidi -p 20:0 to_host.mid + +2) Playing a mid from the host to the gadget +gadget) + +$ arecordmidi -l + PortClient name Port name + 20:0f_midi f_midi + +$ arecordmidi -p 20:0 from_host.mid + +host) + +$ aplaymidi -l + PortClient name Port name + 14:0Midi Through Midi Through Port-0 + 24:0MIDI Gadget MIDI Gadget MIDI 1 + +$ aplaymidi -p24:0 to_gadget.mid + +The from_gadget.mid should sound identical to the to_host.mid. +The from_host.id should sound identical to the to_gadget.mid. + +MIDI files can be played to speakers/headphones with e.g. timidity installed + +$ aplaymidi -l + PortClient name Port name + 14:0Midi Through Midi Through Port-0 + 24:0MIDI Gadget MIDI Gadget MIDI 1 +128:0TiMidity TiMidity port 0 +128:1TiMidity TiMidity port 1 +128:2TiMidity TiMidity port 2 +128:3TiMidity TiMidity port 3 + +$ aplaymidi -p 128:0 file.mid + +MIDI ports can be logically connected using the aconnect utility, e.g.: + +$ aconnect 24:0 128:0 # try it on the host + +After the gadget's MIDI port is connected to timidity's MIDI port, +whatever is played at the gadget side with aplaymidi -l is audible +in host's speakers/headphones. -- 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
[PATCHv3 08/19] Documentation: usb: LOOPBACK function testing
Summary of how to test LOOPBACK function of USB gadget. Signed-off-by: Andrzej Pietrasiewicz --- Documentation/usb/gadget-testing.txt | 23 +++ 1 file changed, 23 insertions(+) diff --git a/Documentation/usb/gadget-testing.txt b/Documentation/usb/gadget-testing.txt index f117e5c..b13491d 100644 --- a/Documentation/usb/gadget-testing.txt +++ b/Documentation/usb/gadget-testing.txt @@ -7,6 +7,7 @@ provided by gadgets. 4. EEM function 5. FFS function 6. HID function +7. LOOPBACK function 1. ACM function @@ -205,3 +206,25 @@ $ ./hid_gadget_test /dev/hidg0 keyboard Host: - observe the keystrokes from the gadget + +7. LOOPBACK function + + +The function is provided by usb_f_ss_lb.ko module. + +Function-specific configfs interface + + +The function name to use when creating the function directory is "Loopback". +The LOOPBACK function provides these attributes in its function directory: + + qlen- depth of loopback queue + bulk_buflen - buffer length + +Testing the LOOPBACK function +- + +device: run the gadget +host: test-usb + +http://www.linux-usb.org/usbtest/testusb.c -- 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
[PATCHv3 12/19] Documentation: usb: OBEX function testing
Summary of how to test OBEX function of USB gadget. Signed-off-by: Andrzej Pietrasiewicz --- Documentation/usb/gadget-testing.txt | 29 + 1 file changed, 29 insertions(+) diff --git a/Documentation/usb/gadget-testing.txt b/Documentation/usb/gadget-testing.txt index 493f79b..c8ae540 100644 --- a/Documentation/usb/gadget-testing.txt +++ b/Documentation/usb/gadget-testing.txt @@ -11,6 +11,7 @@ provided by gadgets. 8. MASS STORAGE function 9. MIDI function 10. NCM function +11. OBEX function 1. ACM function @@ -400,3 +401,31 @@ Configure IP addresses of the device and the host. Then: On the device: ping On the host: ping + +11. OBEX function += + +The function is provided by usb_f_obex.ko module. + +Function-specific configfs interface + + +The function name to use when creating the function directory is "obex". +The OBEX function provides just one attribute in its function directory: + + port_num + +The attribute is read-only. + +There can be at most 4 ACM/generic serial/OBEX ports in the system. + +Testing the OBEX function +- + +On device: seriald -f /dev/ttyGS -s 1024 +On host: serialc -v -p -i -a1 -s1024 \ + -t -r + +where seriald and serialc are Felipe's utilities found here: + +https://git.gitorious.org/usb/usb-tools.git master -- 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
[PATCHv3 05/19] Documentation: usb: EEM function testing
Summary of how to test EEM function of USB gadget. Signed-off-by: Andrzej Pietrasiewicz --- Documentation/usb/gadget-testing.txt | 34 ++ 1 file changed, 34 insertions(+) diff --git a/Documentation/usb/gadget-testing.txt b/Documentation/usb/gadget-testing.txt index b40db75..50b0a6c 100644 --- a/Documentation/usb/gadget-testing.txt +++ b/Documentation/usb/gadget-testing.txt @@ -4,6 +4,7 @@ provided by gadgets. 1. ACM function 2. ECM function 3. ECM subset function +4. EEM function 1. ACM function @@ -100,3 +101,36 @@ Configure IP addresses of the device and the host. Then: On the device: ping On the host: ping + +4. EEM function +=== + +The function is provided by usb_f_eem.ko module. + +Function-specific configfs interface + + +The function name to use when creating the function directory is "eem". +The EEM function provides these attributes in its function directory: + + ifname - network device interface name associated with this + function instance + qmult - queue length multiplier for high and super speed + host_addr - MAC address of host's end of this + Ethernet over USB link + dev_addr- MAC address of device's end of this + Ethernet over USB link + +and after creating the functions/eem. they contain default +values: qmult is 5, dev_addr and host_addr are randomly selected. +Except for ifname they can be written to until the function is linked to a +configuration. The ifname is read-only and contains the name of the interface +which was assigned by the net core, e. g. usb0. + +Testing the EEM function + + +Configure IP addresses of the device and the host. Then: + +On the device: ping +On the host: ping -- 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
[PATCHv3 13/19] Documentation: usb: PHONET function testing
Summary of how to test PHONET function of USB gadget. Signed-off-by: Andrzej Pietrasiewicz --- Documentation/usb/gadget-testing.txt | 64 1 file changed, 64 insertions(+) diff --git a/Documentation/usb/gadget-testing.txt b/Documentation/usb/gadget-testing.txt index c8ae540..02d4366 100644 --- a/Documentation/usb/gadget-testing.txt +++ b/Documentation/usb/gadget-testing.txt @@ -12,6 +12,7 @@ provided by gadgets. 9. MIDI function 10. NCM function 11. OBEX function +12. PHONET function 1. ACM function @@ -429,3 +430,66 @@ On host: serialc -v -p -i -a1 -s1024 \ where seriald and serialc are Felipe's utilities found here: https://git.gitorious.org/usb/usb-tools.git master + +12. PHONET function +=== + +The function is provided by usb_f_phonet.ko module. + +Function-specific configfs interface + + +The function name to use when creating the function directory is "phonet". +The PHONET function provides just one attribute in its function directory: + + ifname - network device interface name associated with this + function instance + +Testing the PHONET function +--- + +It is not possible to test the SOCK_STREAM protocol without a specific piece +of hardware, so only SOCK_DGRAM has been tested. For the latter to work, +in the past I had to apply the patch mentioned here: + +http://www.spinics.net/lists/linux-usb/msg85689.html + +These tools are required: + +git://git.gitorious.org/meego-cellular/phonet-utils.git + +On the host: + +$ ./phonet -a 0x10 -i usbpn0 +$ ./pnroute add 0x6c usbpn0 +$./pnroute add 0x10 usbpn0 +$ ifconfig usbpn0 up + +On the device: + +$ ./phonet -a 0x6c -i upnlink0 +$ ./pnroute add 0x10 upnlink0 +$ ifconfig upnlink0 up + +Then a test program can be used: + +http://www.spinics.net/lists/linux-usb/msg85690.html + +On the device: + +$ ./pnxmit -a 0x6c -r + +On the host: + +$ ./pnxmit -a 0x10 -s 0x6c + +As a result some data should be sent from host to device. +Then the other way round: + +On the host: + +$ ./pnxmit -a 0x10 -r + +On the device: + +$ ./pnxmit -a 0x6c -s 0x10 -- 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
[PATCHv3 01/19] Documentation: usb: gadget_serial: update generic serial setup instruction
Using module parameters to specify accepted Vendor ID, Product ID is considered legacy now. Update the documentation to reflect it. Signed-off-by: Andrzej Pietrasiewicz --- Documentation/usb/gadget_serial.txt | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/Documentation/usb/gadget_serial.txt b/Documentation/usb/gadget_serial.txt index 61e67f6..6b4a88a 100644 --- a/Documentation/usb/gadget_serial.txt +++ b/Documentation/usb/gadget_serial.txt @@ -236,8 +236,12 @@ I: If#= 0 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=serial E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms -You must explicitly load the usbserial driver with parameters to -configure it to recognize the gadget serial device, like this: +You must load the usbserial driver and explicitly set its parameters +to configure it to recognize the gadget serial device, like this: + + echo 0x0525 0xA4A6 >/sys/bus/usb-serial/drivers/generic/new_id + +The legacy way is to use module parameters: modprobe usbserial vendor=0x0525 product=0xA4A6 -- 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
[PATCHv3 18/19] Documentation: usb: UAC2 function testing
Summary of how to test UAC2 function of USB gadget. Signed-off-by: Andrzej Pietrasiewicz --- Documentation/usb/gadget-testing.txt | 39 1 file changed, 39 insertions(+) diff --git a/Documentation/usb/gadget-testing.txt b/Documentation/usb/gadget-testing.txt index 40d22d8..5ac9dc7 100644 --- a/Documentation/usb/gadget-testing.txt +++ b/Documentation/usb/gadget-testing.txt @@ -17,6 +17,7 @@ provided by gadgets. 14. SERIAL function 15. SOURCESINK function 16. UAC1 function +17. UAC2 function 1. ACM function @@ -614,3 +615,41 @@ Testing the UAC1 function device: run the gadget host: aplay -l # should list our USB Audio Gadget + +17. UAC2 function += + +The function is provided by usb_f_uac2.ko module. + +Function-specific configfs interface + + +The function name to use when creating the function directory is "uac2". +The uac2 function provides these attributes in its function directory: + + chmask - capture channel mask + c_srate - capture sampling rate + c_ssize - capture sample size (bytes) + p_chmask - playback channel mask + p_srate - playback sampling rate + p_ssize - playback sample size (bytes) + +The attributes have sane default values. + +Testing the UAC2 function +- + +device: run the gadget +host: aplay -l # should list our USB Audio Gadget + +This function does not require real hardware support, it just +sends a stream of audio data to/from the host. In order to +actually hear something at the device side, a command similar +to this must be used at the device side: + +$ arecord -f dat -t wav -D hw:2,0 | aplay -D hw:0,0 & + +e.g.: + +$ arecord -f dat -t wav -D hw:CARD=UAC2Gadget,DEV=0 | \ +aplay -D default:CARD=OdroidU3 -- 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
[PATCHv3 19/19] Documentation: usb: UVC function testing
Summary of how to test UVC function of USB gadget. Signed-off-by: Andrzej Pietrasiewicz --- Documentation/usb/gadget-testing.txt | 73 1 file changed, 73 insertions(+) diff --git a/Documentation/usb/gadget-testing.txt b/Documentation/usb/gadget-testing.txt index 5ac9dc7..076ac7b 100644 --- a/Documentation/usb/gadget-testing.txt +++ b/Documentation/usb/gadget-testing.txt @@ -18,6 +18,7 @@ provided by gadgets. 15. SOURCESINK function 16. UAC1 function 17. UAC2 function +18. UVC function 1. ACM function @@ -653,3 +654,75 @@ e.g.: $ arecord -f dat -t wav -D hw:CARD=UAC2Gadget,DEV=0 | \ aplay -D default:CARD=OdroidU3 + +18. UVC function + + +The function is provided by usb_f_uvc.ko module. + +Function-specific configfs interface + + +The function name to use when creating the function directory is "uvc". +The uvc function provides these attributes in its function directory: + + streaming_interval - interval for polling endpoint for data transfers + streaming_maxburst - bMaxBurst for super speed companion descriptor + streaming_maxpacket - maximum packet size this endpoint is capable of + sending or receiving when this configuration is + selected + +There are also "control" and "streaming" subdirectories, each of which contain +a number of their subdirectories. There are some sane defaults provided, but +the user must provide the following: + + control header - create in control/header, link from control/class/fs + and/or control/class/ss + streaming header - create in streaming/header, link from + streaming/class/fs and/or streaming/class/hs and/or + streaming/class/ss + format description - create in streaming/mjpeg and/or + streaming/uncompressed + frame description - create in streaming/mjpeg/ and/or in + streaming/uncompressed/ + +Each frame description contains frame interval specification, and each +such specification consists of a number of lines with an inverval value +in each line. The rules stated above are best illustrated with an example: + +# mkdir functions/uvc.usb0/control/header/h +# cd functions/uvc.usb0/control/header/h +# ln -s header/h class/fs +# ln -s header/h class/ss +# mkdir -p functions/uvc.usb0/streaming/uncompressed/u/360p +# cat < functions/uvc.usb0/streaming/uncompressed/u/360p/dwFrameInterval +66 +100 +500 +EOF +# cd $GADGET_CONFIGFS_ROOT +# mkdir functions/uvc.usb0/streaming/header/h +# cd functions/uvc.usb0/streaming/header/h +# ln -s ../../uncompressed/u +# cd ../../class/fs +# ln -s ../../header/h +# cd ../../class/hs +# ln -s ../../header/h +# cd ../../class/ss +# ln -s ../../header/h + + +Testing the UVC function + + +device: run the gadget, modprobe vivid + +# uvc-gadget -u /dev/video -v /dev/video + +where uvc-gadget is this program: +http://git.ideasonboard.org/uvc-gadget.git + +with these patches: +http://www.spinics.net/lists/linux-usb/msg99220.html + +host: luvcview -f yuv -- 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
[PATCHv3 02/19] Documentation: usb: ACM function testing
The newly added file will be used to provide descriptions of how to test the functions of USB gadgets. Signed-off-by: Andrzej Pietrasiewicz --- Documentation/usb/gadget-testing.txt | 34 ++ 1 file changed, 34 insertions(+) create mode 100644 Documentation/usb/gadget-testing.txt diff --git a/Documentation/usb/gadget-testing.txt b/Documentation/usb/gadget-testing.txt new file mode 100644 index 000..2a448f8 --- /dev/null +++ b/Documentation/usb/gadget-testing.txt @@ -0,0 +1,34 @@ +This file summarizes information on basic testing of USB functions +provided by gadgets. + +1. ACM function + + +1. ACM function +=== + +The function is provided by usb_f_acm.ko module. + +Function-specific configfs interface + + +The function name to use when creating the function directory is "acm". +The ACM function provides just one attribute in its function directory: + + port_num + +The attribute is read-only. + +There can be at most 4 ACM/generic serial/OBEX ports in the system. + + +Testing the ACM function + + +On the host: cat > /dev/ttyACM +On the device : cat /dev/ttyGS + +then the other way round + +On the device: cat > /dev/ttyGS +On the host: cat /dev/ttyACM -- 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
[PATCHv3 15/19] Documentation: usb: SERIAL function testing
Summary of how to test SERIAL function of USB gadget. Signed-off-by: Andrzej Pietrasiewicz --- Documentation/usb/gadget-testing.txt | 31 +++ 1 file changed, 31 insertions(+) diff --git a/Documentation/usb/gadget-testing.txt b/Documentation/usb/gadget-testing.txt index 61bc5f5..bc57c65 100644 --- a/Documentation/usb/gadget-testing.txt +++ b/Documentation/usb/gadget-testing.txt @@ -14,6 +14,7 @@ provided by gadgets. 11. OBEX function 12. PHONET function 13. RNDIS function +14. SERIAL function 1. ACM function @@ -529,3 +530,33 @@ Configure IP addresses of the device and the host. Then: On the device: ping On the host: ping + +14. SERIAL function +=== + +The function is provided by usb_f_gser.ko module. + +Function-specific configfs interface + + +The function name to use when creating the function directory is "gser". +The SERIAL function provides just one attribute in its function directory: + + port_num + +The attribute is read-only. + +There can be at most 4 ACM/generic serial/OBEX ports in the system. + +Testing the SERIAL function +--- + +On host: insmod usbserial +echo VID PID >/sys/bus/usb-serial/drivers/generic/new_id +On host: cat > /dev/ttyUSB +On target: cat /dev/ttyGS + +then the other way round + +On target: cat > /dev/ttyGS +On host: cat /dev/ttyUSB -- 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
[PATCHv3 16/19] Documentation: usb: SOURCESINK function testing
Summary of how to test SOURCESINK function of USB gadget. Signed-off-by: Andrzej Pietrasiewicz --- Documentation/usb/gadget-testing.txt | 27 +++ 1 file changed, 27 insertions(+) diff --git a/Documentation/usb/gadget-testing.txt b/Documentation/usb/gadget-testing.txt index bc57c65..73a5b0c 100644 --- a/Documentation/usb/gadget-testing.txt +++ b/Documentation/usb/gadget-testing.txt @@ -15,6 +15,7 @@ provided by gadgets. 12. PHONET function 13. RNDIS function 14. SERIAL function +15. SOURCESINK function 1. ACM function @@ -560,3 +561,29 @@ then the other way round On target: cat > /dev/ttyGS On host: cat /dev/ttyUSB + +15. SOURCESINK function +=== + +The function is provided by usb_f_ss_lb.ko module. + +Function-specific configfs interface + + +The function name to use when creating the function directory is "SourceSink". +The SOURCESINK function provides these attributes in its function directory: + + pattern - 0 (all zeros), 1 (mod63), 2 (none) + isoc_interval - 1..16 + isoc_maxpacket - 0 - 1023 (fs), 0 - 1024 (hs/ss) + isoc_mult - 0..2 (hs/ss only) + isoc_maxburst - 0..15 (ss only) + bulk_buflen - buffer length + +Testing the SOURCESINK function +--- + +device: run the gadget +host: test-usb + +http://www.linux-usb.org/usbtest/testusb.c -- 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
[PATCHv3 09/19] Documentation: usb: MASS STORAGE function testing
Summary of how to test MASS STORAGE function of USB gadget. Signed-off-by: Andrzej Pietrasiewicz --- Documentation/usb/gadget-testing.txt | 54 1 file changed, 54 insertions(+) diff --git a/Documentation/usb/gadget-testing.txt b/Documentation/usb/gadget-testing.txt index b13491d..01b9ffe 100644 --- a/Documentation/usb/gadget-testing.txt +++ b/Documentation/usb/gadget-testing.txt @@ -8,6 +8,7 @@ provided by gadgets. 5. FFS function 6. HID function 7. LOOPBACK function +8. MASS STORAGE function 1. ACM function @@ -228,3 +229,56 @@ device: run the gadget host: test-usb http://www.linux-usb.org/usbtest/testusb.c + +8. MASS STORAGE function + + +The function is provided by usb_f_mass_storage.ko module. + +Function-specific configfs interface + + +The function name to use when creating the function directory is "mass_storage". +The MASS STORAGE function provides these attributes in its directory: +files: + + stall - Set to permit function to halt bulk endpoints. + Disabled on some USB devices known not to work + correctly. You should set it to true. + num_buffers - Number of pipeline buffers. Valid numbers + are 2..4. Available only if + CONFIG_USB_GADGET_DEBUG_FILES is set. + +and a default lun.0 directory corresponding to SCSI LUN #0. + +A new lun can be added with mkdir: + +$ mkdir functions/mass_storage.0/partition.5 + +Lun numbering does not have to be continuous, except for lun #0 which is +created by default. A maximum of 8 luns can be specified and they all must be +named following the . scheme. The numbers can be 0..8. +Probably a good convention is to name the luns "lun.", +although it is not mandatory. + +In each lun directory there are the following attribute files: + + file- The path to the backing file for the LUN. + Required if LUN is not marked as removable. + ro - Flag specifying access to the LUN shall be + read-only. This is implied if CD-ROM emulation + is enabled as well as when it was impossible + to open "filename" in R/W mode. + removable - Flag specifying that LUN shall be indicated as + being removable. + cdrom - Flag specifying that LUN shall be reported as + being a CD-ROM. + nofua - Flag specifying that FUA flag + in SCSI WRITE(10,12) + +Testing the MASS STORAGE function +- + +device: connect the gadget, enable it +host: dmesg, see the USB drives appear (if system configured to automatically +mount) -- 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
[PATCHv3 07/19] Documentation: usb: HID function testing
Summary of how to test HID function of USB gadget. Signed-off-by: Andrzej Pietrasiewicz --- Documentation/usb/gadget-testing.txt | 47 1 file changed, 47 insertions(+) diff --git a/Documentation/usb/gadget-testing.txt b/Documentation/usb/gadget-testing.txt index 141a1d0..f117e5c 100644 --- a/Documentation/usb/gadget-testing.txt +++ b/Documentation/usb/gadget-testing.txt @@ -6,6 +6,7 @@ provided by gadgets. 3. ECM subset function 4. EEM function 5. FFS function +6. HID function 1. ACM function @@ -158,3 +159,49 @@ Testing the FFS function On the device: start the function's userspace daemon, enable the gadget On the host: use the USB function provided by the device + +6. HID function +=== + +The function is provided by usb_f_hid.ko module. + +Function-specific configfs interface + + +The function name to use when creating the function directory is "hid". +The HID function provides these attributes in its function directory: + + protocol- HID protocol to use + report_desc - data to be used in HID reports, except data + passed with /dev/hidg + report_length - HID report length + subclass- HID subclass to use + +For a keyboard the protocol and the subclass are 1, the report_length is 8, +while the report_desc is: + +$ hd my_report_desc + 05 01 09 06 a1 01 05 07 19 e0 29 e7 15 00 25 01 |..)...%.| +0010 75 01 95 08 81 02 95 01 75 08 81 03 95 05 75 01 |u...u.u.| +0020 05 08 19 01 29 05 91 02 95 01 75 03 91 03 95 06 |).u.| +0030 75 08 15 00 25 65 05 07 19 00 29 65 81 00 c0 |u...%e)e...| +003f + +Such a sequence of bytes can be stored to the attribute with echo: + +$ echo -ne \\x05\\x01\\x09\\x06\\xa1. + +Testing the HID function + + +Device: +- create the gadget +- connect the gadget to a host, preferably not the one used +to control the gadget +- run a program which writes to /dev/hidg, e.g. +a userspace program found in Documentation/usb/gadget_hid.txt: + +$ ./hid_gadget_test /dev/hidg0 keyboard + +Host: +- observe the keystrokes from the gadget -- 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
[PATCHv3 06/19] Documentation: usb: FFS function testing
Summary of how to test FFS (FunctionFS) function of USB gadget. Signed-off-by: Andrzej Pietrasiewicz --- Documentation/usb/gadget-testing.txt | 24 1 file changed, 24 insertions(+) diff --git a/Documentation/usb/gadget-testing.txt b/Documentation/usb/gadget-testing.txt index 50b0a6c..141a1d0 100644 --- a/Documentation/usb/gadget-testing.txt +++ b/Documentation/usb/gadget-testing.txt @@ -5,6 +5,7 @@ provided by gadgets. 2. ECM function 3. ECM subset function 4. EEM function +5. FFS function 1. ACM function @@ -134,3 +135,26 @@ Configure IP addresses of the device and the host. Then: On the device: ping On the host: ping + +5. FFS function +=== + +The function is provided by usb_f_fs.ko module. + +Function-specific configfs interface + + +The function name to use when creating the function directory is "ffs". +The function directory is intentionally empty and not modifiable. + +After creating the directory there is a new instance (a "device") of FunctionFS +available in the system. Once a "device" is available, the user should follow +the standard procedure for using FunctionFS (mount it, run the userspace +process which implements the function proper). The gadget should be enabled +by writing a suitable string to usb_gadget//UDC. + +Testing the FFS function + + +On the device: start the function's userspace daemon, enable the gadget +On the host: use the USB function provided by the device -- 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
[PATCHv3 14/19] Documentation: usb: RNDIS function testing
Summary of how to test RNDIS function of USB gadget. Signed-off-by: Andrzej Pietrasiewicz --- Documentation/usb/gadget-testing.txt | 36 1 file changed, 36 insertions(+) diff --git a/Documentation/usb/gadget-testing.txt b/Documentation/usb/gadget-testing.txt index 02d4366..61bc5f5 100644 --- a/Documentation/usb/gadget-testing.txt +++ b/Documentation/usb/gadget-testing.txt @@ -13,6 +13,7 @@ provided by gadgets. 10. NCM function 11. OBEX function 12. PHONET function +13. RNDIS function 1. ACM function @@ -493,3 +494,38 @@ $ ./pnxmit -a 0x10 -r On the device: $ ./pnxmit -a 0x6c -s 0x10 + +13. RNDIS function +== + +The function is provided by usb_f_rndis.ko module. + +Function-specific configfs interface + + +The function name to use when creating the function directory is "rndis". +The RNDIS function provides these attributes in its function directory: + + ifname - network device interface name associated with this + function instance + qmult - queue length multiplier for high and super speed + host_addr - MAC address of host's end of this + Ethernet over USB link + dev_addr- MAC address of device's end of this + Ethernet over USB link + +and after creating the functions/rndis. they contain default +values: qmult is 5, dev_addr and host_addr are randomly selected. +Except for ifname they can be written to until the function is linked to a +configuration. The ifname is read-only and contains the name of the interface +which was assigned by the net core, e. g. usb0. + +By default there can be only 1 RNDIS interface in the system. + +Testing the RNDIS function +-- + +Configure IP addresses of the device and the host. Then: + +On the device: ping +On the host: ping -- 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
[PATCHv3 03/19] Documentation: usb: ECM function testing
Summary of how to test ECM function of USB gadget. Signed-off-by: Andrzej Pietrasiewicz --- Documentation/usb/gadget-testing.txt | 34 ++ 1 file changed, 34 insertions(+) diff --git a/Documentation/usb/gadget-testing.txt b/Documentation/usb/gadget-testing.txt index 2a448f8..7df8785 100644 --- a/Documentation/usb/gadget-testing.txt +++ b/Documentation/usb/gadget-testing.txt @@ -2,6 +2,7 @@ This file summarizes information on basic testing of USB functions provided by gadgets. 1. ACM function +2. ECM function 1. ACM function @@ -32,3 +33,36 @@ then the other way round On the device: cat > /dev/ttyGS On the host: cat /dev/ttyACM + +2. ECM function +=== + +The function is provided by usb_f_ecm.ko module. + +Function-specific configfs interface + + +The function name to use when creating the function directory is "ecm". +The ECM function provides these attributes in its function directory: + + ifname - network device interface name associated with this + function instance + qmult - queue length multiplier for high and super speed + host_addr - MAC address of host's end of this + Ethernet over USB link + dev_addr- MAC address of device's end of this + Ethernet over USB link + +and after creating the functions/ecm. they contain default +values: qmult is 5, dev_addr and host_addr are randomly selected. +Except for ifname they can be written to until the function is linked to a +configuration. The ifname is read-only and contains the name of the interface +which was assigned by the net core, e. g. usb0. + +Testing the ECM function + + +Configure IP addresses of the device and the host. Then: + +On the device: ping +On the host: ping -- 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
[PATCHv3 00/19] USB gadget functions testing
This series adds a documentation file whith a summary of how to do basic testing of functions provided by USB gadgets. It does not add any code. It documents what is already in the kernel tree. It is mostly a compilation of information from my cover letters sent together with all series which convert functions and gadgets to configfs. I think it could be useful to anyone whishing to use the gadgets. v1..v2: - corrected a typo found by Jeremiah - updated the instruction on how to configure usbserial for generic serial after Johan's help - patched gadget_serial.txt documentation to reflect the above v2..v3: - extended uac2 testing as suggested by Peter - added uvc testing after Laurent's ACK for adding configfs support Andrzej Pietrasiewicz (19): Documentation: usb: gadget_serial: update generic serial setup instruction Documentation: usb: ACM function testing Documentation: usb: ECM function testing Documentation: usb: ECM subset function testing Documentation: usb: EEM function testing Documentation: usb: FFS function testing Documentation: usb: HID function testing Documentation: usb: LOOPBACK function testing Documentation: usb: MASS STORAGE function testing Documentation: usb: MIDI function testing Documentation: usb: NCM function testing Documentation: usb: OBEX function testing Documentation: usb: PHONET function testing Documentation: usb: RNDIS function testing Documentation: usb: SERIAL function testing Documentation: usb: SOURCESINK function testing Documentation: usb: UAC1 function testing Documentation: usb: UAC2 function testing Documentation: usb: UVC function testing Documentation/usb/gadget-testing.txt | 728 +++ Documentation/usb/gadget_serial.txt | 8 +- 2 files changed, 734 insertions(+), 2 deletions(-) create mode 100644 Documentation/usb/gadget-testing.txt -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: serial: add nt124 usb to serial driver
On Mon, Dec 15, 2014 at 10:09:22AM -0600, George McCollister wrote: > On Mon, Dec 15, 2014 at 3:52 AM, Johan Hovold wrote: > > On Sun, Dec 14, 2014 at 11:51:11AM -0600, George McCollister wrote: > >> Johan, > >> > >> While working on the tx_empty changes you suggested it occurred to me > >> that it might not be obvious to others that the firmware doesn't send > >> a packet with the NT124_CTRL_TXEMPTY flag cleared when it begins > >> transmitting. The practical implication is that if the driver sets > >> tx_empty = true when it sees NT124_CTRL_TXEMPTY, tx_empty must be > >> reset to false somewhere when more data is transmitted. Perhaps I > >> could add prepare_write_buffer and do it in there before calling > >> usb_serial_generic_prepare_write_buffer(). Does that sound acceptable? > > > > Hmm. There's no way to query that flag? And the status is sent (as bulk > > in data) periodically or only when data has been received? And not when > > the actual status changes? > > The bulk in packets are not sent periodically only on TXEMPTY, other > line change or received data. There's no way to query the flag, though > we're still at the stage we can make modifications to the firmware if > there's justification. One of the design goals is to minimize > unnecessary USB traffic so if there's a place to clear the flag in the > driver without querying it would be preferable. > > > A potential problem with using prepare_write_buffer would be on failures > > to submit the write urb, in which case this flag might never be cleared. > > Yes, this could be a problem though I wonder how many (if any) > recoverable situations this would happen in that didn't eventually > lead to a transmission. Adding a timer with a long timeout that set > tx_empty = true crossed my mind but that doesn't really seem any less > error prone than the original issue. I could of course duplicate a > bunch of code from generic.c and make a few minor changes to set > tx_empty = true but that obviously isn't desirable either. > > If none of the above solutions sound acceptable, let me know I and I > guess I'll change the firmware to allow polling of TXEMPTY with a > control message and remove it from the bulk in packet. I think it would be best if you could add a way to query the driver. It seems like that is the only way to avoid having write race with the tx_empty bulk-in status reports. Thanks, Johan -- 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: problem with ELAN touchscreen
On Tue, Mar 04, 2014 at 11:27:02PM -0500, D. Hugh Redelmeier wrote:
> I have a Lenovo Yoga 2 pro with an ELAN touchscreen.
> I am running Fedora 20 with Fedora's 3.13.5-200.fc20.x86_64 kernel.
>
> During initialization, there is a lot of delay and noise detecting the
> touchscreen.
>
> I'm not the first to report this problem but I don't know what can or
> should be done. But there doesn't seem to be a solution so far.
> Can we figure one out?
I just stumbled across this message from March.
The problem with your touchscreen should have been fixed in v3.18 by commits:
2a159389bf5d ("USB: core: add device-qualifier quirk")
0b750b3baa2d ("HID: usbhid: add always-poll quirk")
and
d749947561af ("USB: quirks: enable device-qualifier quirk for yet
another Elan touchscreen")
1af39588f84c ("HID: usbhid: enable always-poll quirk for Elan
Touchscreen 016f")
They have also been backported to at least the v3.17 (.3+) stable kernels.
Have you tried any of these kernels?
> My uneducated theories:
>
> - The touchscreen is slow to initialize and talking to it before it is
> read starts it initializing again. This seems unlikely: the
> USB system poked my touchscreen over 72 seconds before a good
> outcome happened.
>
> - the touchscreen needs the Windows enumeration method (see below).
>
> - there is a firmware bug that could be fixed (but probably only if it
> shows up in Windows, and I don't think that it does).
>
> - something else
>
> What can I do to help move this forward?
>
> Here are the old reports. My information is at the end.
>
>
>
> (2013 September)
>
> Sarah Sharp suggested that this might be a hardware bug and asked if
> the device were still under warranty.
>
> A number of instances of this behaviour can be found by googling.
> This suggests that any bug in the hardware is in many (all?)
> of these touchscreens. That's the kind of problem that
> manufacturers resist dealing with.
>
>
>
> (Later in the same thread)
>
> Sarah suggests that the device might need to be enumberated using
> the "Windows" scheme. She also wondered if the problematic device
> was actually the ELAN touchscreen (but the numbering suggests so to
> me).
>
> Has anyone tried that enumeration method?
>
> The thread ended here.
>
>
>
> (2013 December)
>
> Apparently the same problem. ASUS N550JV-DB72T with ELAN
> touchscreen.
>
> Sarah suggests that there might be electrical issues with the
> internally connected touchscreen. (I doubt that since there
> are so many independant reports.)
>
> Alan Stern suggests intermittent hardware problems.
>
>
> (2013 Oct)
>
> Richard Ryniker reports the same problem with a Samsung Book 9 plus
> with an ELAN touchscreen.
>
>
>
> (2013 October)
>
> Kevin Fenzi-2 reports the same problem with a Lenovo Yoga 2 pro with
> an ELAN touchscreen.
>
> Was first thought to be a regression. Instead, it seemed to be
> affected by debugging code. My guess: timing.
>
>
>
> (2014 January)
>
> In the same thread, another victim (Eric) showed up.
>
>
>
> (2013 November)
>
> andretti reports the same problem with a Samsung Ativ Book 9 plus
> and an ELAN touchscreen.
>
> A suggestion was the make the xhci driver a module. Not results
> were reported.
>
>
>
> (2013 November)
>
> eweber reports teh same problem with a Lenovo Yoga 2 pro.
>
>
>
> (2013 November)
>
> KeithCU mentions briefly that:
>
> My logfile fills up with USB (and other) error messages.
>
> usb 2-7: unable to read config index 0 descriptor/start -71
>
>
>
> (2014 February)
>
> A new Debian user hits this. Unknown computer with ELAN touchpad.
>
>
> Here are selected sequences of dmesg output from one boot on my system.
> Notice that this process adds over a minute to booting time!
>
> I think that the relevant status numbers are:
>
> #define EPROTO 71 /* Protocol error */
>
> #define ETIMEDOUT 110 /* Connection timed out */
>
> [4.210824] usb 2-7: unable to read config index 0 descriptor/start: -71
> [4.210830] usb 2-7: can't read configurations, error -71
> [4.363159] usb 2-7: new full-speed USB device number 5 using xhci_hcd
> [6.511501] usb 2-7: unable to read config index 0 descriptor/start: -71
> [6.511507] usb 2-7: can't read configurations, error -71
> [6.714942] usb 2-8: new high-spee
Re: [PATCH 2/2] usb: serial: handle -ENODEV quietly in generic_submit_read_urb
On Thu, Dec 11, 2014 at 03:29:54PM -0800, Jeremiah Mahler wrote: > If a USB serial device (e.g. /dev/ttyUSB0) with an active program is > unplugged, an -ENODEV (19) error will be produced after it gives up > trying to resubmit a read. > > usb_serial_generic_submit_read_urb - usb_submit_urb failed: -19 > > Add -ENODEV as one of the permanent errors along with -EPERM that > usb_serial_generic_submit_read_urb() handles quietly without an error. > > Signed-off-by: Jeremiah Mahler I'll apply this one once v3.19-rc1 is out. Thanks, Johan -- 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 0/2] usb: serial: handle -ENODEV and -EPROTO quietly
On Mon, Dec 15, 2014 at 11:10:37PM -0800, Jeremiah Mahler wrote: > Perhaps something at a lower level could return a more apt error number > such as -ENODEV. Then there would be no conflict with -EPROTO. I'm afraid it's not possible to differentiate between a disconnected and malfunctioning device in that short window before the disconnect is reported and processes by the hub driver. > I will look in to it again and re-submit the patches. Let's see what comes out of this discussion first. Thanks, Johan -- 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 0/2] usb: serial: handle -ENODEV and -EPROTO quietly
On Mon, Dec 15, 2014 at 08:38:01AM -0800, Greg Kroah-Hartman wrote: > On Mon, Dec 15, 2014 at 04:53:05AM -0800, Jeremiah Mahler wrote: > > Johan, > > > > On Mon, Dec 15, 2014 at 11:23:21AM +0100, Johan Hovold wrote: > > > On Thu, Dec 11, 2014 at 03:29:52PM -0800, Jeremiah Mahler wrote: > > > > If a USB serial device (e.g. /dev/ttyUSB0) with an active program is > > > > unplugged, a bunch of -ENODEV and -EPROTO errors will be produced in the > > > > logs. This patch set quiets these messages without changing the > > > > original behavior. > > > > > > Don't unplug devices that are in use then. ;) > > > > > I knew someone was going to say that :-) > > > > > > This change is beneficial when using daemons such as slcand, which is > > > > similar to pppd or slip, that cannot determine whether they should exit > > > > until after the USB serial device is unplugged. Producing these error > > > > messages for a normal use case is not helpful. > > > > > > Your patches would hide these errors when they occur during normal use > > > (e.g. EPROTO). > > > > > > Receiving an error message when unplugging an active device should not > > > surprise anyone. And at least you know where it came from (and it's > > > right there in the logs as well). > > > > > > Johan > > > > Hmm. Yes, I can see why quieting -EPROTO would be bad because it would > > hide protocol errors which we want to know about. > > Do you really want to "know about" them? What can a user do with them? > Nothing, so just resubmit and you should be fine. Knowing that a device is flakey (and should be replaced) might be of some worth? And wouldn't silencing such errors mean that we could be quietly dropping data? > > I need to re-think this patch. > > Nack. > > I like this patch, putting crud in the kernel log that no one can do > anything with for a "normal" operation like yanking a USB device out > while it is open should not happen. The problem is that several errors may be returned from the host-controller driver as a consequence of disconnect (before the hub driver can process the disconnect). At least -EPROTO, -EILSEQ, -ETIME are -EPIPE explicitly listed in Documentation/usb/error-codes.txt for this, and of those, -EPROTO, -EILSEQ could also indicate hardware problems. I don't see how we can get around the trade-off between having a few error messages in the log in the short window prior to a processed (and also logged) disconnect, and not reporting potential hardware issues. Thanks, Johan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB 3.0 and xHCI Host-Controller
Ahh, good tip, I'll try it, and let you know the output. Thanks. On Tue, Dec 16, 2014 at 8:49 AM, Mathias Nyman wrote: > Hi > > On 16.12.2014 00:53, Gustavo Duarte wrote: >> Hi Guys, >> >> >> I'm having troubles for communication between a NXT - Lego Brick >> device (http://www.lego.com/) and a Notebook with USB 3.0. >> >> kernel version: >> >> $ uname -r >> 3.13.0-36-generic >> $lspci -vvv >> >> 00:14.0 USB controller: Intel Corporation ValleyView USB xHCI Host >> * >> Questions >> * >> >> 1) Do you think this issue could be caused by kernel/xhci_hcd module ? >> > > It's possible Can you upgrade to a more recent kernel and see if it helps? > There are a lot of xhci changes since 3.13. Current is 3.18 > >> 2) I know that without the brick device, replicate this tests for you >> isn't possible. >> >> So i would like to ask you, a guide to debug this problem, what kind >> of things I can do to try find out, the problem. >> > > what does dmesg say? any xhci related errors? > > You can enable more verbose xhci debugging with: > echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control > > then start communicating with your device, and show the output of dmesg. > > Requires dynamic debug support and debugfs mounted, I think many > distributions have them as default. > > -Mathias > -- 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] drivers: usb: dwc2: remove 'force' parameter from kill_all_requests()
This patch fixes in simpler way the bug described in [1] and [2]. It
looks like DWC2 is the only UDC driver that doesn't force usb requests
to complete in ep_disable() function. This causes described problem,
because we have no guarantee that all requests will be completed before
unbind of usb function.
To fix this problem we force all requests of disabled endpoint to complete.
Also currently running request is not handled. This allowed to simplify
code of kill_all_requests() function, because 'force' parameter is always
set to true, so we don't need it anymore.
In s3c_hsotg_rx_data() we change function used to print message when active
request is NULL from dev_warn() to dev_dbg(), because such situation is
harmless for driver and now it can take place during normal endpoint
disabling.
[1] https://lkml.org/lkml/2014/12/9/283
[2] https://lkml.org/lkml/2014/12/12/360
Signed-off-by: Robert Baldyga
---
drivers/usb/dwc2/gadget.c | 23 ---
1 file changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 200168e..fee0ad5 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -1305,7 +1305,7 @@ static void s3c_hsotg_rx_data(struct dwc2_hsotg *hsotg,
int ep_idx, int size)
u32 epctl = readl(hsotg->regs + DOEPCTL(ep_idx));
int ptr;
- dev_warn(hsotg->dev,
+ dev_dbg(hsotg->dev,
"%s: FIFO %d bytes on ep%d but no req
(DXEPCTl=0x%08x)\n",
__func__, size, ep_idx, epctl);
@@ -1988,30 +1988,23 @@ static void s3c_hsotg_irq_enumdone(struct dwc2_hsotg
*hsotg)
* @hsotg: The device state.
* @ep: The endpoint the requests may be on.
* @result: The result code to use.
- * @force: Force removal of any current requests
*
* Go through the requests on the given endpoint and mark them
* completed with the given result code.
*/
static void kill_all_requests(struct dwc2_hsotg *hsotg,
struct s3c_hsotg_ep *ep,
- int result, bool force)
+ int result)
{
struct s3c_hsotg_req *req, *treq;
unsigned size;
- list_for_each_entry_safe(req, treq, &ep->queue, queue) {
- /*
-* currently, we can't do much about an already
-* running request on an in endpoint
-*/
-
- if (ep->req == req && ep->dir_in && !force)
- continue;
+ ep->req = NULL;
+ list_for_each_entry_safe(req, treq, &ep->queue, queue)
s3c_hsotg_complete_request(hsotg, ep, req,
result);
- }
+
if (!hsotg->dedicated_fifos)
return;
size = (readl(hsotg->regs + DTXFSTS(ep->index)) & 0x) * 4;
@@ -2036,7 +2029,7 @@ void s3c_hsotg_disconnect(struct dwc2_hsotg *hsotg)
hsotg->connected = 0;
for (ep = 0; ep < hsotg->num_of_eps; ep++)
- kill_all_requests(hsotg, &hsotg->eps[ep], -ESHUTDOWN, true);
+ kill_all_requests(hsotg, &hsotg->eps[ep], -ESHUTDOWN);
call_gadget(hsotg, disconnect);
}
@@ -2334,7 +2327,7 @@ irq_retry:
msecs_to_jiffies(200))) {
kill_all_requests(hsotg, &hsotg->eps[0],
- -ECONNRESET, true);
+ -ECONNRESET);
s3c_hsotg_core_init_disconnected(hsotg);
s3c_hsotg_core_connect(hsotg);
@@ -2588,7 +2581,7 @@ static int s3c_hsotg_ep_disable(struct usb_ep *ep)
spin_lock_irqsave(&hsotg->lock, flags);
/* terminate all requests with shutdown */
- kill_all_requests(hsotg, hs_ep, -ESHUTDOWN, false);
+ kill_all_requests(hsotg, hs_ep, -ESHUTDOWN);
hsotg->fifo_map &= ~(1fifo_index = 0;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB 3.0 and xHCI Host-Controller
Hi On 16.12.2014 00:53, Gustavo Duarte wrote: > Hi Guys, > > > I'm having troubles for communication between a NXT - Lego Brick > device (http://www.lego.com/) and a Notebook with USB 3.0. > > kernel version: > > $ uname -r > 3.13.0-36-generic > $lspci -vvv > > 00:14.0 USB controller: Intel Corporation ValleyView USB xHCI Host > * > Questions > * > > 1) Do you think this issue could be caused by kernel/xhci_hcd module ? > It's possible Can you upgrade to a more recent kernel and see if it helps? There are a lot of xhci changes since 3.13. Current is 3.18 > 2) I know that without the brick device, replicate this tests for you > isn't possible. > > So i would like to ask you, a guide to debug this problem, what kind > of things I can do to try find out, the problem. > what does dmesg say? any xhci related errors? You can enable more verbose xhci debugging with: echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control then start communicating with your device, and show the output of dmesg. Requires dynamic debug support and debugfs mounted, I think many distributions have them as default. -Mathias -- 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: Query regarding USB gadget driver
On 12/16/2014 02:15 PM, Peter Chen wrote: > On Tue, Dec 16, 2014 at 10:50:59AM +0530, Sanchayan Maity wrote: >> On 12/16/2014 06:16 AM, Peter Chen wrote: >>> On Mon, Dec 15, 2014 at 02:59:31PM +0530, Sanchayan Maity wrote: Hello, On 12/15/2014 07:42 AM, Peter Chen wrote: > On Fri, Dec 12, 2014 at 06:55:36PM +0530, Sanchayan Maity wrote: >> Hello, >> >> On 12/12/2014 07:21 AM, Peter Chen wrote: >>> On Thu, Dec 11, 2014 at 08:34:45AM -0600, Felipe Balbi wrote: Hi, On Thu, Dec 11, 2014 at 04:08:43PM +0530, Sanchayan Maity wrote: > Hello, > > I am working on a Freescale Cortex-A5 Vybrid Processor. The chip core > is clocked at 500MHz and the USB IP core for this is by Chip-idea. I > am running a 3.18-rc5 kernel on it and trying to use the USB gadget > functionality. To be more specific the CDC ECM class. Currently, I > cannot use this properly. If I use just "ping" to check, it works > fine, but, after running iperf, even one transaction doesn't complete > or completes rarely. Checking the CDC Ether interface with Wireshark > shows, TCP Dup Ack messages and checking the USB bus with Wireshark, > shows packets with USB Protocol Error -71 at one point and after that > packets with USB connection Reset -104 error. If it's of any > significance, I have Arch Linux with the 3.18 kernel running on my > laptop with which the Vybrid connects. On the host side, the only > error dmesg shows is "kevent 12 may have been dropped". I guess this > is connected to the "TCP Previous Segment not captured" and "TCP Dup > ACK" messages. > > My script for the gadget configuration is as below: > > /bin/mount none /mnt -t configfs > /bin/mkdir /mnt/usb_gadget/g1 > cd /mnt/usb_gadget/g1 > /bin/mkdir configs/c.1 > /bin/mkdir functions/ecm.0 > /bin/mkdir strings/0x409 > /bin/mkdir configs/c.1/strings/0x409 > echo 0xa4a2 > idProduct > echo 0x0525 > idVendor > echo Freescale123 > strings/0x409/serialnumber > echo Freescale > strings/0x409/manufacturer > echo "USB Serial Gadget" > strings/0x409/product > echo "Conf 1" > configs/c.1/strings/0x409/configuration > echo 200 > configs/c.1/MaxPower > ln -s functions/ecm.0 configs/c.1 > echo ci_hdrc.0 > UDC > /sbin/ifconfig usb0 up > /sbin/ifconfig usb0 192.168.1.10 > > I have debug prints in the udc.c and u_ether.c using pr_debug and just a little hint, use any of the dev_*() macros next time, they'll print the device name which helps figuring out which UDC you're using. Based on ci_hdrc.0 above, I suppose it's chipidea and Peter Chen maintains that one, it really helps adding maintainers to Cc list. > enable them when required using dynamic debug. Without running iperf, > using ping gives me a sequence of prints as below: > > [ 277.434409] In eth_start_xmit > [ 277.434517] In UDC irq > [ 277.434553] In usb_gadget_giveback_request > [ 277.434567] In tx_complete > [ 277.435443] In UDC irq > [ 277.435477] In usb_gadget_giveback_request > [ 277.435491] In rx_complete > [ 277.435517] In rx_submit > [ 277.435601] In eth_start_xmit > [ 277.436441] In UDC irq > [ 277.436465] In usb_gadget_giveback_request > [ 277.436478] In rx_complete > [ 277.436493] In rx_submit > [ 277.436520] In usb_gadget_giveback_request > [ 277.436533] In tx_complete > [ 278.434865] In eth_start_xmit > [ 278.434959] In UDC irq > [ 278.434993] In usb_gadget_giveback_request > [ 278.435006] In tx_complete > [ 278.435881] In UDC irq > [ 278.435910] In usb_gadget_giveback_request > [ 278.435923] In rx_complete > [ 278.435946] In rx_submit > > After running iperf without debug prints and then enabling before > using ping gives me a sequence of prints as below > [ 81.989827] In UDC irq > [ 81.989871] In usb_gadget_giveback_request > [ 81.989886] In rx_complete > [ 81.989905] In rx_submit > [ 82.989892] In UDC irq > [ 82.989951] In usb_gadget_giveback_request > [ 82.989967] In rx_complete > [ 82.989992] In rx_submit > [ 83.990064] In UDC irq > [ 83.990126] In usb_gadget_giveback_request > [ 83.990142] In rx_complete > [ 83.990167] In rx_submit > [ 84.990007] In UDC irq > [ 84.990049] In usb_gadget_giveback_request > [ 84.990064] In rx_complete > [ 84.990083] In rx_submit > [ 85.9900
Re: Query regarding USB gadget driver
On Tue, Dec 16, 2014 at 10:50:59AM +0530, Sanchayan Maity wrote: > On 12/16/2014 06:16 AM, Peter Chen wrote: > > On Mon, Dec 15, 2014 at 02:59:31PM +0530, Sanchayan Maity wrote: > >> Hello, > >> > >> On 12/15/2014 07:42 AM, Peter Chen wrote: > >>> On Fri, Dec 12, 2014 at 06:55:36PM +0530, Sanchayan Maity wrote: > Hello, > > On 12/12/2014 07:21 AM, Peter Chen wrote: > > On Thu, Dec 11, 2014 at 08:34:45AM -0600, Felipe Balbi wrote: > >> Hi, > >> > >> On Thu, Dec 11, 2014 at 04:08:43PM +0530, Sanchayan Maity wrote: > >>> Hello, > >>> > >>> I am working on a Freescale Cortex-A5 Vybrid Processor. The chip core > >>> is clocked at 500MHz and the USB IP core for this is by Chip-idea. I > >>> am running a 3.18-rc5 kernel on it and trying to use the USB gadget > >>> functionality. To be more specific the CDC ECM class. Currently, I > >>> cannot use this properly. If I use just "ping" to check, it works > >>> fine, but, after running iperf, even one transaction doesn't complete > >>> or completes rarely. Checking the CDC Ether interface with Wireshark > >>> shows, TCP Dup Ack messages and checking the USB bus with Wireshark, > >>> shows packets with USB Protocol Error -71 at one point and after that > >>> packets with USB connection Reset -104 error. If it's of any > >>> significance, I have Arch Linux with the 3.18 kernel running on my > >>> laptop with which the Vybrid connects. On the host side, the only > >>> error dmesg shows is "kevent 12 may have been dropped". I guess this > >>> is connected to the "TCP Previous Segment not captured" and "TCP Dup > >>> ACK" messages. > >>> > >>> My script for the gadget configuration is as below: > >>> > >>> /bin/mount none /mnt -t configfs > >>> /bin/mkdir /mnt/usb_gadget/g1 > >>> cd /mnt/usb_gadget/g1 > >>> /bin/mkdir configs/c.1 > >>> /bin/mkdir functions/ecm.0 > >>> /bin/mkdir strings/0x409 > >>> /bin/mkdir configs/c.1/strings/0x409 > >>> echo 0xa4a2 > idProduct > >>> echo 0x0525 > idVendor > >>> echo Freescale123 > strings/0x409/serialnumber > >>> echo Freescale > strings/0x409/manufacturer > >>> echo "USB Serial Gadget" > strings/0x409/product > >>> echo "Conf 1" > configs/c.1/strings/0x409/configuration > >>> echo 200 > configs/c.1/MaxPower > >>> ln -s functions/ecm.0 configs/c.1 > >>> echo ci_hdrc.0 > UDC > >>> /sbin/ifconfig usb0 up > >>> /sbin/ifconfig usb0 192.168.1.10 > >>> > >>> I have debug prints in the udc.c and u_ether.c using pr_debug and > >> > >> just a little hint, use any of the dev_*() macros next time, they'll > >> print the device name which helps figuring out which UDC you're using. > >> > >> Based on ci_hdrc.0 above, I suppose it's chipidea and Peter Chen > >> maintains that one, it really helps adding maintainers to Cc list. > >> > >>> enable them when required using dynamic debug. Without running iperf, > >>> using ping gives me a sequence of prints as below: > >>> > >>> [ 277.434409] In eth_start_xmit > >>> [ 277.434517] In UDC irq > >>> [ 277.434553] In usb_gadget_giveback_request > >>> [ 277.434567] In tx_complete > >>> [ 277.435443] In UDC irq > >>> [ 277.435477] In usb_gadget_giveback_request > >>> [ 277.435491] In rx_complete > >>> [ 277.435517] In rx_submit > >>> [ 277.435601] In eth_start_xmit > >>> [ 277.436441] In UDC irq > >>> [ 277.436465] In usb_gadget_giveback_request > >>> [ 277.436478] In rx_complete > >>> [ 277.436493] In rx_submit > >>> [ 277.436520] In usb_gadget_giveback_request > >>> [ 277.436533] In tx_complete > >>> [ 278.434865] In eth_start_xmit > >>> [ 278.434959] In UDC irq > >>> [ 278.434993] In usb_gadget_giveback_request > >>> [ 278.435006] In tx_complete > >>> [ 278.435881] In UDC irq > >>> [ 278.435910] In usb_gadget_giveback_request > >>> [ 278.435923] In rx_complete > >>> [ 278.435946] In rx_submit > >>> > >>> After running iperf without debug prints and then enabling before > >>> using ping gives me a sequence of prints as below > >>> [ 81.989827] In UDC irq > >>> [ 81.989871] In usb_gadget_giveback_request > >>> [ 81.989886] In rx_complete > >>> [ 81.989905] In rx_submit > >>> [ 82.989892] In UDC irq > >>> [ 82.989951] In usb_gadget_giveback_request > >>> [ 82.989967] In rx_complete > >>> [ 82.989992] In rx_submit > >>> [ 83.990064] In UDC irq > >>> [ 83.990126] In usb_gadget_giveback_request > >>> [ 83.990142] In rx_complete > >>> [ 83.990167] In rx_submit > >>> [ 84.990007] In UDC irq > >>> [ 84.990049] In usb_gadget_giveback_request > >>> [ 84.990064] In rx_complete > >>> [ 84.990083] In rx_submit > >>> [ 85.990085] In UDC irq > >>> [ 85.990147] In us
Re: Query regarding USB gadget driver
On 12/16/2014 12:02 PM, Peter Chen wrote: > On Tue, Dec 16, 2014 at 10:50:59AM +0530, Sanchayan Maity wrote: >> On 12/16/2014 06:16 AM, Peter Chen wrote: >>> On Mon, Dec 15, 2014 at 02:59:31PM +0530, Sanchayan Maity wrote: Hello, On 12/15/2014 07:42 AM, Peter Chen wrote: > On Fri, Dec 12, 2014 at 06:55:36PM +0530, Sanchayan Maity wrote: >> Hello, >> >> On 12/12/2014 07:21 AM, Peter Chen wrote: >>> On Thu, Dec 11, 2014 at 08:34:45AM -0600, Felipe Balbi wrote: Hi, On Thu, Dec 11, 2014 at 04:08:43PM +0530, Sanchayan Maity wrote: > Hello, > > I am working on a Freescale Cortex-A5 Vybrid Processor. The chip core > is clocked at 500MHz and the USB IP core for this is by Chip-idea. I > am running a 3.18-rc5 kernel on it and trying to use the USB gadget > functionality. To be more specific the CDC ECM class. Currently, I > cannot use this properly. If I use just "ping" to check, it works > fine, but, after running iperf, even one transaction doesn't complete > or completes rarely. Checking the CDC Ether interface with Wireshark > shows, TCP Dup Ack messages and checking the USB bus with Wireshark, > shows packets with USB Protocol Error -71 at one point and after that > packets with USB connection Reset -104 error. If it's of any > significance, I have Arch Linux with the 3.18 kernel running on my > laptop with which the Vybrid connects. On the host side, the only > error dmesg shows is "kevent 12 may have been dropped". I guess this > is connected to the "TCP Previous Segment not captured" and "TCP Dup > ACK" messages. > > My script for the gadget configuration is as below: > > /bin/mount none /mnt -t configfs > /bin/mkdir /mnt/usb_gadget/g1 > cd /mnt/usb_gadget/g1 > /bin/mkdir configs/c.1 > /bin/mkdir functions/ecm.0 > /bin/mkdir strings/0x409 > /bin/mkdir configs/c.1/strings/0x409 > echo 0xa4a2 > idProduct > echo 0x0525 > idVendor > echo Freescale123 > strings/0x409/serialnumber > echo Freescale > strings/0x409/manufacturer > echo "USB Serial Gadget" > strings/0x409/product > echo "Conf 1" > configs/c.1/strings/0x409/configuration > echo 200 > configs/c.1/MaxPower > ln -s functions/ecm.0 configs/c.1 > echo ci_hdrc.0 > UDC > /sbin/ifconfig usb0 up > /sbin/ifconfig usb0 192.168.1.10 > > I have debug prints in the udc.c and u_ether.c using pr_debug and just a little hint, use any of the dev_*() macros next time, they'll print the device name which helps figuring out which UDC you're using. Based on ci_hdrc.0 above, I suppose it's chipidea and Peter Chen maintains that one, it really helps adding maintainers to Cc list. > enable them when required using dynamic debug. Without running iperf, > using ping gives me a sequence of prints as below: > > [ 277.434409] In eth_start_xmit > [ 277.434517] In UDC irq > [ 277.434553] In usb_gadget_giveback_request > [ 277.434567] In tx_complete > [ 277.435443] In UDC irq > [ 277.435477] In usb_gadget_giveback_request > [ 277.435491] In rx_complete > [ 277.435517] In rx_submit > [ 277.435601] In eth_start_xmit > [ 277.436441] In UDC irq > [ 277.436465] In usb_gadget_giveback_request > [ 277.436478] In rx_complete > [ 277.436493] In rx_submit > [ 277.436520] In usb_gadget_giveback_request > [ 277.436533] In tx_complete > [ 278.434865] In eth_start_xmit > [ 278.434959] In UDC irq > [ 278.434993] In usb_gadget_giveback_request > [ 278.435006] In tx_complete > [ 278.435881] In UDC irq > [ 278.435910] In usb_gadget_giveback_request > [ 278.435923] In rx_complete > [ 278.435946] In rx_submit > > After running iperf without debug prints and then enabling before > using ping gives me a sequence of prints as below > [ 81.989827] In UDC irq > [ 81.989871] In usb_gadget_giveback_request > [ 81.989886] In rx_complete > [ 81.989905] In rx_submit > [ 82.989892] In UDC irq > [ 82.989951] In usb_gadget_giveback_request > [ 82.989967] In rx_complete > [ 82.989992] In rx_submit > [ 83.990064] In UDC irq > [ 83.990126] In usb_gadget_giveback_request > [ 83.990142] In rx_complete > [ 83.990167] In rx_submit > [ 84.990007] In UDC irq > [ 84.990049] In usb_gadget_giveback_request > [ 84.990064] In rx_complete > [ 84.990083] In rx_submit > [ 85.9900
XHCI fails on high-speed data transfer
Hello I have a new Thinkpad T440p running debian with custom kernel 3.14.19. When I connect an external 2TB USB3 hdd, after 50-60Gb data written XHCI drops the usb device (just like I would pull the plug on it) then it comes back: I'm 100% that this is not a hardware issue because the drive works flawlessly from Windows7/8 on the same laptop. I did extended speedtests, surface tests with HD Sentinel and copied a lot of data on it on ~110 MB/s speed. It also only occurs with the high speed USB3 driver. If I use an USB2 only port where it negotiates a speed around ~ 25MB/s that's fine. I attach the log, lspci, lsusb outputs. Should I ran even more recent kernel than the 3.14? Were there any major improvements made in the XHCI driver? If so which kernel version is recommended? I want to use BTRFS as well, so need a version which performs well with that. Thank you! Dec 6 21:21:12 debian kernel: [ 226.902247] scsi 8:0:0:0: Direct-Access Seagate BUP Slim BK 0143 PQ: 0 ANSI: 6 Dec 6 21:21:12 debian kernel: [ 226.902567] sd 8:0:0:0: Attached scsi generic sg2 type 0 Dec 6 21:21:12 debian kernel: [ 226.903491] sd 8:0:0:0: [sdb] Spinning up disk... Dec 6 21:21:16 debian kernel: [ 230.981013] .ready Dec 6 21:21:16 debian kernel: [ 230.981344] sd 8:0:0:0: [sdb] 3907029167 512-byte logical blocks: (2.00 TB/1.81 TiB) Dec 6 21:21:16 debian kernel: [ 230.981945] sd 8:0:0:0: [sdb] Write Protect is off Dec 6 21:21:16 debian kernel: [ 230.981953] sd 8:0:0:0: [sdb] Mode Sense: 2b 00 10 08 Dec 6 21:21:16 debian kernel: [ 230.982529] sd 8:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA Dec 6 21:21:16 debian kernel: [ 231.030139] sdb: sdb1 Dec 6 21:21:16 debian kernel: [ 231.032056] sd 8:0:0:0: [sdb] Attached SCSI disk Dec 6 21:22:13 debian kernel: [ 287.807249] usb 3-1: USB disconnect, device number 7 Dec 6 21:22:13 debian kernel: [ 287.809252] sd 8:0:0:0: [sdb] Synchronizing SCSI cache Dec 6 21:22:13 debian kernel: [ 287.809389] sd 8:0:0:0: [sdb] Dec 6 21:22:13 debian kernel: [ 287.809396] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK Dec 6 21:22:26 debian kernel: [ 301.149154] hub 4-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? Dec 6 21:22:30 debian kernel: [ 305.074412] hub 4-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? Dec 6 21:22:34 debian kernel: [ 308.999672] hub 4-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? Dec 6 21:22:38 debian kernel: [ 312.924957] hub 4-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? Dec 6 21:22:38 debian kernel: [ 312.924999] hub 4-0:1.0: unable to enumerate USB device on port 1 Dec 6 21:22:38 debian kernel: [ 313.027365] usb 4-2: new SuperSpeed USB device number 8 using xhci_hcd Dec 6 21:22:38 debian kernel: [ 313.041566] usb 4-2: New USB device found, idVendor=0bc2, idProduct=ab21 Dec 6 21:22:38 debian kernel: [ 313.041575] usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Dec 6 21:22:38 debian kernel: [ 313.041580] usb 4-2: Product: BUP Slim BK Dec 6 21:22:38 debian kernel: [ 313.055318] usb-storage 4-2:1.0: USB Mass Storage device detected Dec 6 21:22:38 debian kernel: [ 313.055570] scsi9 : usb-storage 4-2:1.0 Dec 6 21:22:38 debian mtp-probe: checking bus 4, device 8: "/sys/devices/pci:00/:00:14.0/usb4/4-2" Dec 6 21:22:38 debian mtp-probe: bus: 4, device: 8 was not an MTP device 00:00.0 Host bridge: Intel Corporation Haswell DRAM Controller (rev 06) 00:01.0 PCI bridge: Intel Corporation Haswell PCI Express x16 Controller (rev 06) 00:01.1 PCI bridge: Intel Corporation Haswell PCI Express x8 Controller (rev 06) 00:02.0 VGA compatible controller: Intel Corporation Haswell Integrated Graphics Controller (rev 06) 00:03.0 Audio device: Intel Corporation Haswell HD Audio Controller (rev 06) 00:14.0 USB controller: Intel Corporation Lynx Point USB xHCI Host Controller (rev 04) 00:16.0 Communication controller: Intel Corporation Lynx Point MEI Controller #1 (rev 04) 00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I217-LM (rev 04) 00:1a.0 USB controller: Intel Corporation Lynx Point USB Enhanced Host Controller #2 (rev 04) 00:1b.0 Audio device: Intel Corporation Lynx Point High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation Lynx Point PCI Express Root Port #1 (rev d4) 00:1c.1 PCI bridge: Intel Corporation Lynx Point PCI Express Root Port #2 (rev d4) 00:1d.0 USB controller: Intel Corporation Lynx Point USB Enhanced Host Controller #1 (rev 04) 00:1f.0 ISA bridge: Intel Corporation Lynx Point LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation Lynx Point 6-port SATA Controller 1 [AHCI mode] (rev 04) 00:1f.3 SMBus: Intel Corporation Lynx Point SMBus Controller (rev 04) 02:00.0 VGA compatible controller: NVIDIA Corporation Device 1290 (rev a1) 03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. Device 5227 (rev 01) 04
Re: [PATCH 1/3] usb: host: f_usb20ho: add support for Fujitsu ehci/ohci USB 2.0 host controller
On Tuesday 16 December 2014 10:10:26 Sneeker Yeh wrote:
> This patch adds support for EHCI compliant Host controller found
> on Fujitsu Socs.
>
> Signed-off-by: Sneeker Yeh
> ---
> .../devicetree/bindings/usb/fujitsu-ehci.txt | 22 ++
> drivers/usb/host/Kconfig | 11 +
> drivers/usb/host/Makefile |1 +
> drivers/usb/host/f_usb20ho_hcd.c | 306
>
> drivers/usb/host/f_usb20ho_hcd.h | 35 +++
> 5 files changed, 375 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/fujitsu-ehci.txt
> create mode 100644 drivers/usb/host/f_usb20ho_hcd.c
> create mode 100644 drivers/usb/host/f_usb20ho_hcd.h
>
> diff --git a/Documentation/devicetree/bindings/usb/fujitsu-ehci.txt
> b/Documentation/devicetree/bindings/usb/fujitsu-ehci.txt
> new file mode 100644
> index 000..e180860
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/fujitsu-ehci.txt
> @@ -0,0 +1,22 @@
> +FUJITSU GLUE COMPONENTS
> +
> +MB86S7x EHCI GLUE
> + - compatible : Should be "fujitsu,f_usb20ho_hcd"
Please try to use the binding from
Documentation/devicetree/bindings/usb/usb-ehci.txt and the respective
ohci binding first, and use two separate devic enodes.
> + - reg : Address and length of the register set for the device.
> + - interrupts : The irq number of this device that is used to interrupt the
> + CPU
> + - clocks: from common clock binding, handle to usb clock.
> + - clock-names: from common clock binding.
You should always document the specific strings for a named property.
> + - #stream-id-cells : handle to use "arm,mmu-400" ARM IOMMU driver
Don't use that binding, we are trying to kill that off. Instead, use
an 'iommus' property.
> + hci_res[0].start = ohci ? resource->start + F_OHCI_OFFSET :
> + resource->start + F_EHCI_OFFSET;
> + hci_res[0].end = ohci ?
> + resource->start + F_OHCI_OFFSET + F_OHCI_SIZE - 1 :
> + resource->start + F_EHCI_OFFSET + F_EHCI_SIZE - 1;
> + hci_res[0].flags = IORESOURCE_MEM;
> +
> + hci_res[1].start = irq;
> + hci_res[1].flags = IORESOURCE_IRQ;
> +
> + hci_dev = platform_device_alloc(ohci ? "ohci-platform" :
> + "ehci-platform", 0);
> + if (!hci_dev) {
> + dev_err(&pdev->dev, "platform_device_alloc() failed\n");
> + ret = -ENODEV;
> + goto err_res;
> + }
No need for playing games with child devices, just see how the other
drivers do it.
> + ret = platform_device_add(hci_dev);
> + if (ret) {
> + dev_err(&pdev->dev, "platform_device_add() failed\n");
> + goto err_alloc;
> + }
> +
> + return hci_dev;
> +
> +err_alloc:
> + platform_device_put(hci_dev);
> +err_res:
> + return ERR_PTR(ret);
> +}
> +
> +static u64 f_usb20ho_dma_mask = DMA_BIT_MASK(32);
The dma mask should come from the dma-ranges property of the parent bus,
as of_platform_populate now does.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
