[PATCH] usb: misc: usb3503: Use i2c_add_driver helper macro

[Andrew F. Davis]

Use i2c_add_driver as it will add THIS_MODULE for us.

Signed-off-by: Andrew F. Davis 
---
 drivers/usb/misc/usb3503.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
index 64ff5b9..b45cb77 100644
--- a/drivers/usb/misc/usb3503.c
+++ b/drivers/usb/misc/usb3503.c
@@ -410,7 +410,7 @@ static int __init usb3503_init(void)
 {
int err;
 
-   err = i2c_register_driver(THIS_MODULE, _i2c_driver);
+   err = i2c_add_driver(_i2c_driver);
if (err != 0)
pr_err("usb3503: Failed to register I2C driver: %d\n", err);
 
-- 
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 v3] USB: serial: add Moxa UPORT 11x0 driver

[Mathieu OTHACEHE]

Add a driver which supports :

- UPort 1110  : 1 port RS-232 USB to Serial Hub.
- UPort 1130  : 1 port RS-422/485 USB to Serial Hub.
- UPort 1130I : 1 port RS-422/485 USB to Serial Hub with Isolation.
- UPort 1150  : 1 port RS-232/422/485 USB to Serial Hub.
- UPort 1150I : 1 port RS-232/422/485 USB to Serial Hub with Isolation.

This driver is based on GPL MOXA driver written by Hen Huang and available
on MOXA website. The original driver was based on io_ti serial driver.

Signed-off-by: Mathieu OTHACEHE 
---
Hi,

Sorry for late reply, here is the third version of the driver.

Thank you,

Mathieu

 drivers/usb/serial/Kconfig   |   16 +
 drivers/usb/serial/Makefile  |1 +
 drivers/usb/serial/mxu11x0.c | 1100 ++
 3 files changed, 1117 insertions(+)
 create mode 100644 drivers/usb/serial/mxu11x0.c

diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig
index 56ecb8b..f612dda 100644
--- a/drivers/usb/serial/Kconfig
+++ b/drivers/usb/serial/Kconfig
@@ -475,6 +475,22 @@ config USB_SERIAL_MOS7840
  To compile this driver as a module, choose M here: the
  module will be called mos7840.  If unsure, choose N.
 
+config USB_SERIAL_MXUPORT11
+   tristate "USB Moxa UPORT 11x0 Serial Driver"
+   ---help---
+ Say Y here if you want to use a MOXA UPort 11x0 Serial hub.
+
+ This driver supports:
+
+ - UPort 1110  : 1 port RS-232 USB to Serial Hub.
+ - UPort 1130  : 1 port RS-422/485 USB to Serial Hub.
+ - UPort 1130I : 1 port RS-422/485 USB to Serial Hub with Isolation.
+ - UPort 1150  : 1 port RS-232/422/485 USB to Serial Hub.
+ - UPort 1150I : 1 port RS-232/422/485 USB to Serial Hub with 
Isolation.
+
+ To compile this driver as a module, choose M here: the
+ module will be called mxu11x0.
+
 config USB_SERIAL_MXUPORT
tristate "USB Moxa UPORT Serial Driver"
---help---
diff --git a/drivers/usb/serial/Makefile b/drivers/usb/serial/Makefile
index 349d9df..f3fa5e5 100644
--- a/drivers/usb/serial/Makefile
+++ b/drivers/usb/serial/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_USB_SERIAL_METRO)+= 
metro-usb.o
 obj-$(CONFIG_USB_SERIAL_MOS7720)   += mos7720.o
 obj-$(CONFIG_USB_SERIAL_MOS7840)   += mos7840.o
 obj-$(CONFIG_USB_SERIAL_MXUPORT)   += mxuport.o
+obj-$(CONFIG_USB_SERIAL_MXUPORT11) += mxu11x0.o
 obj-$(CONFIG_USB_SERIAL_NAVMAN)+= navman.o
 obj-$(CONFIG_USB_SERIAL_OMNINET)   += omninet.o
 obj-$(CONFIG_USB_SERIAL_OPTICON)   += opticon.o
diff --git a/drivers/usb/serial/mxu11x0.c b/drivers/usb/serial/mxu11x0.c
new file mode 100644
index 000..6ffe38d
--- /dev/null
+++ b/drivers/usb/serial/mxu11x0.c
@@ -0,0 +1,1100 @@
+/*
+ *
+ * USB Moxa UPORT 11x0 Serial Driver
+ *
+ * Copyright (C) 2007 MOXA Technologies Co., Ltd.
+ * Copyright (C) 2015 Mathieu Othacehe 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ *
+ * Supports the following Moxa USB to serial converters:
+ *  UPort 1110,  1 port RS-232 USB to Serial Hub.
+ *  UPort 1130,  1 port RS-422/485 USB to Serial Hub.
+ *  UPort 1130I, 1 port RS-422/485 USB to Serial Hub with isolation
+ *protection.
+ *  UPort 1150,  1 port RS-232/422/485 USB to Serial Hub.
+ *  UPort 1150I, 1 port RS-232/422/485 USB to Serial Hub with isolation
+ *  protection.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Vendor and product ids */
+#define MXU1_VENDOR_ID 0x110a
+#define MXU1_1110_PRODUCT_ID   0x1110
+#define MXU1_1130_PRODUCT_ID   0x1130
+#define MXU1_1150_PRODUCT_ID   0x1150
+#define MXU1_1151_PRODUCT_ID   0x1151
+#define MXU1_1131_PRODUCT_ID   0x1131
+
+/* Commands */
+#define MXU1_GET_VERSION   0x01
+#define MXU1_GET_PORT_STATUS   0x02
+#define MXU1_GET_PORT_DEV_INFO 0x03
+#define MXU1_GET_CONFIG0x04
+#define MXU1_SET_CONFIG0x05
+#define MXU1_OPEN_PORT 0x06
+#define MXU1_CLOSE_PORT0x07
+#define MXU1_START_PORT0x08
+#define MXU1_STOP_PORT 0x09
+#define MXU1_TEST_PORT 0x0A
+#define MXU1_PURGE_PORT0x0B
+#define MXU1_RESET_EXT_DEVICE  0x0C
+#define MXU1_GET_OUTQUEUE  0x0D
+#define MXU1_WRITE_DATA  

Re: Resetting USB modems and USB to serial converters increases ttyUSBXX counter

[Dan Williams]

On Thu, 2015-10-22 at 10:39 +0200, Erwin Van de Velde wrote:
> Hi all,
> 
> Thank you for your helpful answers! I have investigated it further,
> stopping potential culprits in userspace and I have found the issue:
> it is modemmanager that seems to keep the devices open somewhere and
> thus causes the ttyUSB numbers to go up. So now I will redirect the
> issue to their developers :-)

There was a bug between ModemManager 1.2 and 1.4.2 that could have
triggered this, which was fixed in commit
009af02f6d06d5020e397455354b9ccc56557b02.  So make sure you have 1.4.2
(released on 13-Jan-2015) or later.

Dan

> I do not care about the device node name per se, I use symlinks anyway
> to have consistent naming, but since there is a limit of max. 512
> ttyUSB devices and each modem consists of 3 of those, the system hits
> the limit rather quickly.
> 
> Thanks a lot!
> Erwin
> 
> 
> On Wed, Oct 21, 2015 at 4:37 PM, Greg K-H  wrote:
> > On Wed, Oct 21, 2015 at 11:39:04AM +0200, Erwin Van de Velde wrote:
> >> Hi all,
> >>
> >> As advised, I retried with a more recent kernel (4.2.0), but I get a
> >> similar result:
> >>
> >> I tested via 'echo 1 > /sys/bus/pci/ehci-pci/\:00\:1a.0/remove'
> >> and 'echo 1 > /sys/bus/pci/rescan'.
> >
> > Why did you remove the PCI device?  Do you have a PCI hotplug system
> > that recan will work for?
> >
> > You are removing the whole USB host controller here, not just the USB
> > device itself, it's a "fake" hotplug, which is odd, and your PCI device
> > might not work correctly when you add it back...
> >
> >> There are two possible results: no
> >> errors when removing the device and then the devices are reinserted
> >> with the same ttyUSB number or, with an error:
> >> 'usb_wwan_indat_callback: resubmit read urb failed. (-19)' (as shown
> >> in the dmesg copied below) and then the numbers increase, even though
> >> the ttyUSB devices with the previously used numbers have been removed
> >> from /dev. On following attempts the numbers only remain the same or
> >> increase, never reusing the freed ttyUSB numbers. Can someone please
> >> tell me how I can prevent the error or circumvent the issue otherwise?
> >> Sometimes the devices get stuck and resetting them via removal seems
> >> to be the only option.
> >>
> >> Thanks in advance!
> >> Erwin
> >>
> >> [  623.366025] ehci-pci :00:1a.0: remove, state 1
> >> [  623.366042] usb usb1: USB disconnect, device number 1
> >> [  623.366047] usb 1-1: USB disconnect, device number 2
> >> [  623.366051] usb 1-1.1: USB disconnect, device number 4
> >> [  623.366270] option1 ttyUSB6: GSM modem (1-port) converter now
> >> disconnected from ttyUSB6
> >> [  623.366294] option 1-1.1:1.0: device disconnected
> >> [  623.368715] option1 ttyUSB9: usb_wwan_indat_callback: resubmit read
> >> urb failed. (-19)
> >> [  623.369327] option1 ttyUSB9: usb_wwan_indat_callback: resubmit read
> >> urb failed. (-19)
> >> [  623.369863] option1 ttyUSB9: usb_wwan_indat_callback: resubmit read
> >> urb failed. (-19)
> >> [  623.370398] option1 ttyUSB9: usb_wwan_indat_callback: resubmit read
> >> urb failed. (-19)
> >
> > Those are normal, the device is being removed.
> >
> >> [  623.371083] option1 ttyUSB9: GSM modem (1-port) converter now
> >> disconnected from ttyUSB9
> >> [  623.371097] option 1-1.1:1.2: device disconnected
> >> [  623.371315] option1 ttyUSB14: GSM modem (1-port) converter now
> >> disconnected from ttyUSB14
> >
> >
> > Have you also shut down the userspace program that had these device
> > nodes open?  That's the issue here, what program has the device nodes
> > open, if they don't close them, no matter what you do, the device nodes
> > will not be recycled within the kernel.  This isn't a kernel issue, it's
> > a userspace issue to properly shut them down in order for the numbers to
> > be reused.
> >
> > But even if they aren't reused, it's not a big deal, userspace should
> > not care about the device node names at all, this isn't a problem, they
> > will be recycled once userspace closes the device node, eventually.
> >
> > So focus on your userspace programs if you are really worried about the
> > device numbers here.
> >
> > hope this helps,
> >
> > 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


--
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: MUSB peripheral DMA regression caused by driver core runtime PM change

[Tony Lindgren]

* Tony Lindgren  [151021 16:44]:
> Hi all,
> 
> I noticed a regresssino in v4.3-rc series to day with MUSB gadgets
> and DMA. Doing a git bisect between v4.2..v4.3-rc1 on it pointed to:
> 
> ddef08dd00f5 ("Driver core: wakeup the parent device before trying probe")
> 
> With the commit above reverted things work fine with DMA and USB gadgets.
> 
> This is on omap3 with CONFIG_USB_INVENTRA_DMA selected. Selecting
> CONFIG_MUSB_PIO_ONLY still works even without reverting ddef08dd00f5.
> 
> Anybody got ideas what might be wrong? Some wrong runtime PM usage
> under drivers/usb/musb?

Here's some more debug info on where things are different initializing
the USB gadgets. I added some printks and diffed the dmesg output. The
added calls from commit ddef08dd00f5 start with dd:


+dd __device_attach pm_runtime_put parent 480ab000.usb_otg_hs
+dd driver_probe_device pm_runtime_get_sync parent 0-0048
 twl4030_usb 4807.i2c:twl@48:twl4030-usb: Initialized TWL4030 USB module
+dd driver_probe_device pm_runtime_put parent 0-0048
+dd __device_attach pm_runtime_get_sync parent 480ab000.usb_otg_hs
+dd driver_probe_device pm_runtime_get_sync parent 480ab000.usb_otg_hs
 musb musb-hdrc.0.auto _pm_runtime_get_sync
 musb musb-hdrc.0.auto _pm_runtime_get_sync
 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, 
HB-ISO Rx, HB-ISO Tx, SoftConn)
@@ -273,11 +695,24 @@
 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
 usb usb1: Product: MUSB HDRC host driver
-usb usb1: Manufacturer: Linux 4.3.0-rc6-5-gb037ac9 musb-hcd
+usb usb1: Manufacturer: Linux 4.3.0-rc6-5-g24b084c musb-hcd
 usb usb1: SerialNumber: musb-hdrc.0.auto
+dd __device_attach pm_runtime_get_sync parent musb-hdrc.0.auto
+dd driver_probe_device pm_runtime_get_sync parent musb-hdrc.0.auto
+dd __device_attach pm_runtime_get_sync parent usb1
+dd driver_probe_device pm_runtime_get_sync parent usb1
 hub 1-0:1.0: USB hub found
 hub 1-0:1.0: 1 port detected
+dd driver_probe_device pm_runtime_put parent usb1
+dd __device_attach pm_runtime_put parent usb1
+dd driver_probe_device pm_runtime_put parent musb-hdrc.0.auto
+dd __device_attach pm_runtime_put parent musb-hdrc.0.auto
 musb musb-hdrc.0.auto _pm_runtime_put
+dd driver_probe_device pm_runtime_put parent 480ab000.usb_otg_hs
+dd __device_attach pm_runtime_put parent 480ab000.usb_otg_hs
 modprobe: module 'usb_core' not found
 userial_init: registered 4 ttyGS* devices
 Mass Storage Function, version: 2009/09/11

The musb driver is using autosuspend like Felipe pointed out offline,
so maybe that's where things go wrong with commit ddef08dd00f5?

Regards,

Tony
--
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: [GIT PULL] On-demand device probing

[Frank Rowand]

On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
> 
> 
> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
>> But that's moot currently because Greg believes that the time spent
>> probing devices at boot time could be reduced enough so that the order
>> in which devices are probed becomes irrelevant. IME that would have to
>> be under 200ms so that the user doesn't notice and that's unicorn-far
>> from any bootlog I have ever seen.
> 
> But as no one has actually produced a bootlog, how do you know that?
> Where exactly is your time being spent?  What driver is causing long
> delays?  Why is the long-delay-drivers not being done in their own
> thread?  And most importantly, why are you ignoring the work that people
> did back in 2008 to solve the issue on other hardware platforms?
> 
>> Given that downstreams are already carrying as many hacks as they
>> could think of to speed total boot up, I think this is effectively
>> telling them to go away.
> 
> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
> solve-the-random-issue-i'm-having type patch by putting random calls in
> semi-random subsystems all over the kernel.
> 
> And when I ask for real data, you respond with the fact that you aren't
> trying to speed up boot time here at all, so what am I supposed to think

I also had the understanding that this patch series was about improving
boot time.  But I was kindly corrected that the behavior change was
getting the panel displaying stuff at an earlier point in the boot sequence,
_not_ completing the entire boot faster. 

The claim for the current series, in patch 0 in v7 is:

   With this series I get the kernel to output to the panel in 0.5s,
   instead of 2.8s.

Just to get side-tracked, one other approach at ordering to reduce
deferrals reported a modest boot time reduction for four boards and a
very slight boot time increase for one other board.) The report of boot
times with that approach was in:

  http://article.gmane.org/gmane.linux.drivers.devicetree/133010

from Alexander Holler.

I have not searched further to see if there is more data of boot time
reductions from any of the other attempts to change driver binding
order to move dependencies before use of a resource.  But whether
there is a performance improvement or not, there continues to be
a stream of developers creatively impacting the binding order for
their specific driver(s) or board.  So it seems that maybe there
is an underlying problem, or we don't have adequate documentation
explaining how to avoid a need to order bindings, or the
documentation exists and is not being read.

I have been defaulting to the position that has been asserted by
the device tree maintainters, that probe deferrals work just fine
for at least the majority of cases (and is the message I have been
sharing in my conference presentations about device tree).  But I
suspect that there is at least a small minority of cases that are not
well served by probe deferral.  (Not to be read as an endorsement of
this specific patch series, just a generic observation.)

-Frank

> other than that you don't care enough to do the real work and are trying
> to hack the driver core up instead.
> 
>> Sorry for the rant,
> 
> No apologies needed, it's cathartic at times :)
> 
> thanks,
> 
> greg k-h
> .
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Resetting USB modems and USB to serial converters increases ttyUSBXX counter

[Bjørn Mork]

Dan Williams  writes:
> On Thu, 2015-10-22 at 10:39 +0200, Erwin Van de Velde wrote:
>> Hi all,
>> 
>> Thank you for your helpful answers! I have investigated it further,
>> stopping potential culprits in userspace and I have found the issue:
>> it is modemmanager that seems to keep the devices open somewhere and
>> thus causes the ttyUSB numbers to go up. So now I will redirect the
>> issue to their developers :-)
>
> There was a bug between ModemManager 1.2 and 1.4.2 that could have
> triggered this, which was fixed in commit
> 009af02f6d06d5020e397455354b9ccc56557b02.  So make sure you have 1.4.2
> (released on 13-Jan-2015) or later.

Yes, unfortunately that includes the current Debian stable version:

nemi:/home/bjorn# apt-cache policy modemmanager
modemmanager:
  Installed: 1.4.0-1
  Candidate: 1.4.0-1
  Version table:
 1.4.12-1 0
600 http://ftp.no.debian.org/debian/ sid/main amd64 Packages
 *** 1.4.0-1 0
700 http://ftp.no.debian.org/debian/ jessie/main amd64 Packages
100 /var/lib/dpkg/status


nemi:/home/bjorn# lsof -p8191|grep /dev
ModemMana 8191 root0u  CHR 136,14  0t0   17 
/dev/pts/14
ModemMana 8191 root1u  CHR 136,14  0t0   17 
/dev/pts/14
ModemMana 8191 root2u  CHR 136,14  0t0   17 
/dev/pts/14
ModemMana 8191 root9u  CHR  180,0  0t0  1091872 
/dev/cdc-wdm0
ModemMana 8191 root   10u  CHR  166,0  0t0 9804 
/dev/ttyACM0 (deleted)
ModemMana 8191 root   11u  CHR  166,1  0t0   397155 
/dev/ttyACM1 (deleted)
ModemMana 8191 root   12u  CHR  166,2  0t0   448536 
/dev/ttyACM2 (deleted)
ModemMana 8191 root   13u  CHR  166,3  0t0   507569 
/dev/ttyACM3 (deleted)
ModemMana 8191 root   14u  CHR  166,4  0t0   673258 
/dev/ttyACM4 (deleted)
ModemMana 8191 root   15u  CHR  166,5  0t0   922024 
/dev/ttyACM5 (deleted)


I must admit that I have known about this, but have been too lazy to
report it against the Debian package.  It doesn't cause any real
problems for me, even if I sometimes do large numbers of modem
plug/unplug cycles. I just restart ModemManager if I find the device
numbers too high :)



Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: dwc2: host: Fix remote wakeup when not in DWC2_L2

[Douglas Anderson]

In commit 734643dfbdde ("usb: dwc2: host: add flag to reflect bus
state") we changed dwc2_port_suspend() not to set the lx_state
anymore (instead it sets the new bus_suspended variable).  This
introduced a bug where we would fail to detect device insertions if:

1. Plug empty hub into dwc2
2. Plug USB flash drive into the empty hub.
3. Wait a few seconds
4. Unplug USB flash drive
5. Less than 2 seconds after step 4, plug the USB flash drive in again.

The dwc2_hcd_rem_wakeup() function should have been changed to look at
the new bus_suspended variable.

Let's fix it.  Since commit b46146d59fda ("usb: dwc2: host: resume root
hub on remote wakeup") talks about needing the root hub resumed if the
bus was suspended, we'll include it in our test.

It appears that the "port_l1_change" should only be set to 1 if we were
in DWC2_L1 (the driver currently never sets this), so we'll update the
former "else" case based on this test.

Fixes: 734643dfbdde ("usb: dwc2: host: add flag to reflect bus state")
Signed-off-by: Douglas Anderson 
---
 drivers/usb/dwc2/hcd.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index e79baf73c234..571c21727ff9 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -324,12 +324,13 @@ void dwc2_hcd_disconnect(struct dwc2_hsotg *hsotg)
  */
 static void dwc2_hcd_rem_wakeup(struct dwc2_hsotg *hsotg)
 {
-   if (hsotg->lx_state == DWC2_L2) {
+   if (hsotg->bus_suspended) {
hsotg->flags.b.port_suspend_change = 1;
usb_hcd_resume_root_hub(hsotg->priv);
-   } else {
-   hsotg->flags.b.port_l1_change = 1;
}
+
+   if (hsotg->lx_state == DWC2_L1)
+   hsotg->flags.b.port_l1_change = 1;
 }
 
 /**
@@ -1428,8 +1429,8 @@ static void dwc2_wakeup_detected(unsigned long data)
dev_dbg(hsotg->dev, "Clear Resume: HPRT0=%0x\n",
dwc2_readl(hsotg->regs + HPRT0));
 
-   hsotg->bus_suspended = 0;
dwc2_hcd_rem_wakeup(hsotg);
+   hsotg->bus_suspended = 0;
 
/* Change to L0 state */
hsotg->lx_state = DWC2_L0;
-- 
2.6.0.rc2.230.g3dd15c0

--
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: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

On Thu, Oct 22, 2015 at 11:53:31AM -0700, Frank Rowand wrote:
> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
> > 
> > 
> > On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> >> But that's moot currently because Greg believes that the time spent
> >> probing devices at boot time could be reduced enough so that the order
> >> in which devices are probed becomes irrelevant. IME that would have to
> >> be under 200ms so that the user doesn't notice and that's unicorn-far
> >> from any bootlog I have ever seen.
> > 
> > But as no one has actually produced a bootlog, how do you know that?
> > Where exactly is your time being spent?  What driver is causing long
> > delays?  Why is the long-delay-drivers not being done in their own
> > thread?  And most importantly, why are you ignoring the work that people
> > did back in 2008 to solve the issue on other hardware platforms?
> > 
> >> Given that downstreams are already carrying as many hacks as they
> >> could think of to speed total boot up, I think this is effectively
> >> telling them to go away.
> > 
> > No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
> > solve-the-random-issue-i'm-having type patch by putting random calls in
> > semi-random subsystems all over the kernel.
> > 
> > And when I ask for real data, you respond with the fact that you aren't
> > trying to speed up boot time here at all, so what am I supposed to think
> 
> I also had the understanding that this patch series was about improving
> boot time.  But I was kindly corrected that the behavior change was
> getting the panel displaying stuff at an earlier point in the boot sequence,
> _not_ completing the entire boot faster. 
> 
> The claim for the current series, in patch 0 in v7 is:
> 
>With this series I get the kernel to output to the panel in 0.5s,
>instead of 2.8s.
> 
> Just to get side-tracked, one other approach at ordering to reduce
> deferrals reported a modest boot time reduction for four boards and a
> very slight boot time increase for one other board.) The report of boot
> times with that approach was in:
> 
>   http://article.gmane.org/gmane.linux.drivers.devicetree/133010
> 
> from Alexander Holler.
> 
> I have not searched further to see if there is more data of boot time
> reductions from any of the other attempts to change driver binding
> order to move dependencies before use of a resource.  But whether
> there is a performance improvement or not, there continues to be
> a stream of developers creatively impacting the binding order for
> their specific driver(s) or board.  So it seems that maybe there
> is an underlying problem, or we don't have adequate documentation
> explaining how to avoid a need to order bindings, or the
> documentation exists and is not being read.
> 
> I have been defaulting to the position that has been asserted by
> the device tree maintainters, that probe deferrals work just fine
> for at least the majority of cases (and is the message I have been
> sharing in my conference presentations about device tree).  But I
> suspect that there is at least a small minority of cases that are not
> well served by probe deferral.  (Not to be read as an endorsement of
> this specific patch series, just a generic observation.)

I agree, there might be some small numbers that this is a problem for,
and if so, great, show us the boot logs where things are taking up all
of the time, and we can work on resolving those issues.

But without hard numbers / details, this all is just random hand-waving,
and I don't like making core kernel changes on that basis.  And no one
else should ever want us to do that either.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB 2.0 device has 8ms latency

[John Tapsell]

On 22 October 2015 at 18:00, Greg KH  wrote:
> On Thu, Oct 22, 2015 at 05:15:50PM +0100, John Tapsell wrote:
>> On 15 October 2015 at 15:37, Alan Stern  wrote:
>> > On Thu, 15 Oct 2015, John Tapsell wrote:
>> >
>> >> I did have one wacky idea.  I'm sure it's stupid, but here it is:  Is
>> >> it at all possible that there's a bug in the linux usb code where a
>> >> bInterval value of 1ms is being converted into microframes (8
>> >> microframes)  but then because it's a full speed device it's then
>> >> incorrectly read as an 8ms delay?  I did have a look into the code,
>> >> but got thoroughly lost.  Any pointers on how I could check my wacky
>> >> theory?
>> >
>> > There is no such bug.  Such a thing would have been spotted long, long
>> > ago.
>> >
>> >> I'm just wondering where this 8ms delay comes from.
>> >
>> > Multiple places: time to submit the request, time to reserve
>> > bandwidth for the previously unused interrupt endpoint, time to
>> > complete the transfer, all multiplied by 2.
>> >
>> > You can get more information from usbmon (see
>> > Documentation/usb/usbmon.txt in the kernel source).  But Greg is right;
>> > the protocol you described is terrible.  There's no need for a multiple
>> > ping-pong interchange like that; all you should need to do is wait for
>> > the device to send the next bit (or whatever) of data as soon as it
>> > becomes available.
>> >
>> > Alan Stern
>>
>>
>> I had a look at the windows driver, and found that it is implemented
>> in pretty much exactly the same way as the linux driver, but it
>> operates at twice the speed.  And that's for a user-space USB driver.
>>
>> Any ideas why?
>
> "pretty much"?  What exactly is the difference?

Well, just that one uses the windows API and one uses the linux API :-)

>  And you should be able
> to try out a userspace driver in Linux as well, libusb works on Windows
> and Linux so you can do a good comparison.

Interesting - I'll give it a try, thanks.

John
--
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 2.0 device has 8ms latency

[Alan Stern]

On Thu, 22 Oct 2015, John Tapsell wrote:

> I had a look at the windows driver, and found that it is implemented
> in pretty much exactly the same way as the linux driver, but it
> operates at twice the speed.  And that's for a user-space USB driver.
> 
> Any ideas why?

Windows and Linux allocate bandwidth for interrupt endpoints at 
different times.  The scheme Windows uses involves less overhead, but 
it also makes less total bandwidth available.

I don't know if that's the reason for the difference, but it might be.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Resetting USB modems and USB to serial converters increases ttyUSBXX counter

[Erwin Van de Velde]

Hi all,

Thank you for your helpful answers! I have investigated it further,
stopping potential culprits in userspace and I have found the issue:
it is modemmanager that seems to keep the devices open somewhere and
thus causes the ttyUSB numbers to go up. So now I will redirect the
issue to their developers :-)

I do not care about the device node name per se, I use symlinks anyway
to have consistent naming, but since there is a limit of max. 512
ttyUSB devices and each modem consists of 3 of those, the system hits
the limit rather quickly.

Thanks a lot!
Erwin


On Wed, Oct 21, 2015 at 4:37 PM, Greg K-H  wrote:
> On Wed, Oct 21, 2015 at 11:39:04AM +0200, Erwin Van de Velde wrote:
>> Hi all,
>>
>> As advised, I retried with a more recent kernel (4.2.0), but I get a
>> similar result:
>>
>> I tested via 'echo 1 > /sys/bus/pci/ehci-pci/\:00\:1a.0/remove'
>> and 'echo 1 > /sys/bus/pci/rescan'.
>
> Why did you remove the PCI device?  Do you have a PCI hotplug system
> that recan will work for?
>
> You are removing the whole USB host controller here, not just the USB
> device itself, it's a "fake" hotplug, which is odd, and your PCI device
> might not work correctly when you add it back...
>
>> There are two possible results: no
>> errors when removing the device and then the devices are reinserted
>> with the same ttyUSB number or, with an error:
>> 'usb_wwan_indat_callback: resubmit read urb failed. (-19)' (as shown
>> in the dmesg copied below) and then the numbers increase, even though
>> the ttyUSB devices with the previously used numbers have been removed
>> from /dev. On following attempts the numbers only remain the same or
>> increase, never reusing the freed ttyUSB numbers. Can someone please
>> tell me how I can prevent the error or circumvent the issue otherwise?
>> Sometimes the devices get stuck and resetting them via removal seems
>> to be the only option.
>>
>> Thanks in advance!
>> Erwin
>>
>> [  623.366025] ehci-pci :00:1a.0: remove, state 1
>> [  623.366042] usb usb1: USB disconnect, device number 1
>> [  623.366047] usb 1-1: USB disconnect, device number 2
>> [  623.366051] usb 1-1.1: USB disconnect, device number 4
>> [  623.366270] option1 ttyUSB6: GSM modem (1-port) converter now
>> disconnected from ttyUSB6
>> [  623.366294] option 1-1.1:1.0: device disconnected
>> [  623.368715] option1 ttyUSB9: usb_wwan_indat_callback: resubmit read
>> urb failed. (-19)
>> [  623.369327] option1 ttyUSB9: usb_wwan_indat_callback: resubmit read
>> urb failed. (-19)
>> [  623.369863] option1 ttyUSB9: usb_wwan_indat_callback: resubmit read
>> urb failed. (-19)
>> [  623.370398] option1 ttyUSB9: usb_wwan_indat_callback: resubmit read
>> urb failed. (-19)
>
> Those are normal, the device is being removed.
>
>> [  623.371083] option1 ttyUSB9: GSM modem (1-port) converter now
>> disconnected from ttyUSB9
>> [  623.371097] option 1-1.1:1.2: device disconnected
>> [  623.371315] option1 ttyUSB14: GSM modem (1-port) converter now
>> disconnected from ttyUSB14
>
>
> Have you also shut down the userspace program that had these device
> nodes open?  That's the issue here, what program has the device nodes
> open, if they don't close them, no matter what you do, the device nodes
> will not be recycled within the kernel.  This isn't a kernel issue, it's
> a userspace issue to properly shut them down in order for the numbers to
> be reused.
>
> But even if they aren't reused, it's not a big deal, userspace should
> not care about the device node names at all, this isn't a problem, they
> will be recycled once userspace closes the device node, eventually.
>
> So focus on your userspace programs if you are really worried about the
> device numbers here.
>
> hope this helps,
>
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 22 October 2015 at 02:54, Rafael J. Wysocki  wrote:
> On Tuesday, October 20, 2015 06:21:55 PM Tomeu Vizoso wrote:
>> On 20 October 2015 at 18:04, Alan Stern  wrote:
>> > On Tue, 20 Oct 2015, Mark Brown wrote:
>> >
>> >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
>> >>
>> >> > Furthermore, that applies only to devices that use synchronous suspend.
>> >> > Async suspend is becoming common, and there the only restrictions are
>> >> > parent-child relations plus whatever explicit requirements that drivers
>> >> > impose by calling device_pm_wait_for_dev().
>> >>
>> >> Hrm, this is the first I'd noticed that feature though I see the initial
>> >> commit dates from January.
>> >
>> > Async suspend and device_pm_wait_for_dev() were added in January 2010,
>> > not 2015!
>> >
>> >>  It looks like most of the users are PCs at
>> >> the minute but we should be using it more widely for embedded things,
>> >> there's definitely some cases I'm aware of where it will allow us to
>> >> remove some open coding.
>> >>
>> >> It does seem like we want to be feeding dependency information we
>> >> discover for probing way into the suspend dependencies...
>> >
>> > Rafael has been thinking about a way to do this systematically.
>> > Nothing concrete has emerged yet.
>>
>> This iteration of the series would make this quite easy, as
>> dependencies are calculated before probes are attempted:
>>
>> https://lkml.org/lkml/2015/6/17/311
>
> Well, if you know how to represent "links" between devices, the mechanism
> introduced here doesn't really add much value, because in that case the
> core knows what the dependencies are in the first place and can only
> defer the probes that have to be deferred.

By "here" you mean what you are proposing for ordering device
suspends, or on-demand probing?

If you meant that probing on-demand is unneeded if we already have
dependency information, I agree with you and that's why I only pushed
forward on-demand, as the approach linked above introduced some
duplication when inferring the dependencies. Maybe that could be
avoided without too much refactoring.

In any case, Thierry mentioned the other day in #tegra that one could
also collect dependency information as a follow up to the on-demand
series by calling device_depend() or such instead of
of_device_probe().

Regards,

Tomeu

> Thanks,
> Rafael
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2 1/6] usb: host: xhci: add a platform-private pointer field

[Yoshihiro Shimoda]

Hi Greg,

> From: Yoshihiro Shimoda
> Sent: Monday, October 19, 2015 6:11 PM
> 
> Hi Greg,
> 
> > Sent: Saturday, October 17, 2015 3:38 PM
> >
> > On Wed, Oct 07, 2015 at 08:38:53PM +0900, Yoshihiro Shimoda wrote:
> > > This patch adds an xhci->priv field for storing the of_device_id.data
> > > pointer. This will simplify the code to match platform specific
> > > variables (e.g. platform type and firmware name).
> > >
> > > Signed-off-by: Yoshihiro Shimoda 
> > > ---
> > >  drivers/usb/host/xhci.h | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
> > > index 51093df..da227ba 100644
> > > --- a/drivers/usb/host/xhci.h
> > > +++ b/drivers/usb/host/xhci.h
> > > @@ -1653,6 +1653,9 @@ struct xhci_hcd {
> > >   u32 port_status_u0;
> > >  /* Compliance Mode Timer Triggered every 2 seconds */
> > >  #define COMP_MODE_RCVRY_MSECS 2000
> > > +
> > > + /* Store of_device_id.data pointer as xhci-plat private data */
> > > + const void  *priv;
> > >  };
> >
> > Why can't we do what we do with the other *_hcd structures and pad out
> > the end of the structure as needed with the following:
> > /* platform-specific data -- must come last */
> > unsigned long   priv[0] __aligned(sizeof(s64));
> >
> > and then ask for the requested amount of space depending on the platform
> > being used?
> 
> Since I found the following comment from Thomas before I submitted,
> I didn't add such the other *_hcd structures to avoid complicate.
> http://thread.gmane.org/gmane.linux.kernel/1697250/focus=73028
> (This comment was written in last year though...)
> 
> The current code has "extra_priv_size" like the following patch.
> So, can we add "priv" to xhci_hcd like the other *_hcd structures?
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cd33a32157e42483ffea31e32b1cee4f11ff9592
> 
> Anyway, I will investigate this "extra_priv_size".

I investgated this topic.
I found that the current code can add such the other *_hcd structures using the 
"extra_priv_size".
(In other words, the comment from Thomas in last year is not fit with the 
current xhci driver code.)

However, the current implementation is strange to me:
 - The hcd_priv_size in xhci.c is sizeof(struct xhci_hcd *).
 - The extra_priv_size in xhci-plat.c and xhci-pci are sizeof(struct xhci_hcd).

In this means, actual hcd_priv_size in the xhci driver is:
 sizeof(struct xhci_hcd) + sizeof(struct xhci_hcd *)

I don't think that the "+ sizeof(struct xhci_hcd *)" is needed.
Is my understanding correct? If so, I will fix this and add such a patch into 
my v3 patch set.

Best regards,
Yoshihiro Shimoda

> Best regards,
> Yoshihiro Shimoda
> 
> > 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 net,stable] qmi_wwan: add Sierra Wireless MC74xx/EM74xx

[Bjørn Mork]

New device IDs shamelessly lifted from the vendor driver.

Signed-off-by: Bjørn Mork 
---
 drivers/net/usb/qmi_wwan.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 355842b85ee9..2a7c1be23c4f 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -765,6 +765,10 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x1199, 0x9056, 8)},/* Sierra Wireless Modem */
{QMI_FIXED_INTF(0x1199, 0x9057, 8)},
{QMI_FIXED_INTF(0x1199, 0x9061, 8)},/* Sierra Wireless Modem */
+   {QMI_FIXED_INTF(0x1199, 0x9070, 8)},/* Sierra Wireless 
MC74xx/EM74xx */
+   {QMI_FIXED_INTF(0x1199, 0x9070, 10)},   /* Sierra Wireless 
MC74xx/EM74xx */
+   {QMI_FIXED_INTF(0x1199, 0x9071, 8)},/* Sierra Wireless 
MC74xx/EM74xx */
+   {QMI_FIXED_INTF(0x1199, 0x9071, 10)},   /* Sierra Wireless 
MC74xx/EM74xx */
{QMI_FIXED_INTF(0x1bbb, 0x011e, 4)},/* Telekom Speedstick LTE II 
(Alcatel One Touch L100V LTE) */
{QMI_FIXED_INTF(0x1bbb, 0x0203, 2)},/* Alcatel L800MA */
{QMI_FIXED_INTF(0x2357, 0x0201, 4)},/* TP-LINK HSUPA Modem MA180 */
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] USB: serial: cp210x: Workaround cp2108 Tx queue bug

[Konstantin Shkolnyy]

Occasionally, writing data and immediately closing the port makes cp2108
stop responding. The device has to be unplugged to clear the error.
The failure is induced by shutting down the device while its Tx queue
still has unsent data. This condition is avoided by issuing PURGE command
from the close() callback.

This change is applied to all cp210x devices. Clearing internal queues on
close is generally good.

Signed-off-by: Konstantin Shkolnyy 
---
 drivers/usb/serial/cp210x.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index eac7cca..8ba1005 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -301,6 +301,14 @@ static struct usb_serial_driver * const serial_drivers[] = 
{
 #define CONTROL_WRITE_RTS  0x0200
 
 /*
+ * CP210X_PURGE - 16 bits passed in wValue of USB request.
+ * SiLabs app note AN571 gives a strange description of the 4 bits:
+ * bit 0 or bit 2 clears the transmit queue and 1 or 3 receive.
+ * writing 1 to all, however, purges cp2108 well enough to avoid the hang.
+ */
+#define PURGE_ALL  0x000f
+
+/*
  * cp210x_get_config
  * Reads from the CP210x configuration registers
  * 'size' is specified in bytes.
@@ -475,7 +483,14 @@ static int cp210x_open(struct tty_struct *tty, struct 
usb_serial_port *port)
 
 static void cp210x_close(struct usb_serial_port *port)
 {
+   unsigned int purge_ctl;
+
usb_serial_generic_close(port);
+
+   /* Clear both queues; cp2108 needs this to avoid an occasional hang */
+   purge_ctl = PURGE_ALL;
+   cp210x_set_config(port, CP210X_PURGE, _ctl, 2);
+
cp210x_set_config_single(port, CP210X_IFC_ENABLE, UART_DISABLE);
 }
 
-- 
1.8.4.5

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] extcon: add MAX3355 driver

[Sergei Shtylyov]

Hello.

On 10/21/2015 05:57 AM, Chanwoo Choi wrote:


I think this patch is too much delay. I recommend you better to develop
this driver based on latest extcon-next branch[1].
[1] 
https://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/log/?h=extcon-next


   I would really appreciate if you answer my questions, I think most of them 
are still valid...


MBR, 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 3/3] USB: serial: cp210x: Workaround cp2108 GET_LINE_CTL bug

[Konstantin Shkolnyy]

cp2108 GET_LINE_CTL returns the 16-bit value with the 2 bytes swapped.
However, SET_LINE_CTL functions properly. When the driver tries to modify
the register, it reads it, modifies some bits and writes back. Because the
read bytes were swapped, this often results in an invalid value to be
written. In turn, this causes cp2108 respond with a stall. The stall
sometimes doesn't clear properly and cp2108 starts responding to following
valid commands also with stalls, effectively failing.

Signed-off-by: Konstantin Shkolnyy 
---
 drivers/usb/serial/cp210x.c | 73 ++---
 1 file changed, 69 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index 352fe63..eb02184 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -199,6 +199,7 @@ MODULE_DEVICE_TABLE(usb, id_table);
 
 struct cp210x_port_private {
__u8bInterfaceNumber;
+   bool  cp2108_with_get_line_ctl_swap;
 };
 
 static struct usb_serial_driver cp210x_device = {
@@ -419,6 +420,63 @@ static inline int cp210x_set_config_single(struct 
usb_serial_port *port,
 }
 
 /*
+ * Detect CP2108 GET_LINE_CTL bug and activate workaround.
+ * Write a known good value 0x800, read it back.
+ * If it comes back swapped the bug is detected.
+ * Preserve the original register value.
+ */
+static int cp210x_activate_workarounds(struct usb_serial_port *port)
+{
+   struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
+   unsigned int line_ctl_save;
+   unsigned int line_ctl_test;
+   int err;
+
+   port_priv->cp2108_with_get_line_ctl_swap = false;
+
+   err = cp210x_get_config(port, CP210X_GET_LINE_CTL, _ctl_save, 2);
+   if (err)
+   return err;
+
+   line_ctl_test = 0x800;
+   err = cp210x_set_config(port, CP210X_SET_LINE_CTL, _ctl_test, 2);
+   if (err)
+   return err;
+
+   err = cp210x_get_config(port, CP210X_GET_LINE_CTL, _ctl_test, 2);
+   if (err)
+   return err;
+
+   if (line_ctl_test == 8) {
+   port_priv->cp2108_with_get_line_ctl_swap = true;
+   swab16s((u16 *)(_ctl_save));
+   }
+
+   return cp210x_set_config(port, CP210X_SET_LINE_CTL, _ctl_save, 2);
+}
+
+/*
+ * Must always be called instead of cp210x_get_config(CP210X_GET_LINE_CTL)
+ * to workaround cp2108 bug and get correct value.
+ */
+static int cp210x_get_line_ctl(struct usb_serial_port *port,
+   unsigned int *pctrl)
+{
+   struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
+   int err;
+
+   err = cp210x_get_config(port, CP210X_GET_LINE_CTL, pctrl, 2);
+   if (err)
+   return err;
+
+   /* Workaround swapped bytes in 16-bit value from CP210X_GET_LINE_CTL */
+   if (port_priv->cp2108_with_get_line_ctl_swap)
+   swab16s((u16 *) pctrl);
+
+   return 0;
+}
+
+/*
  * cp210x_quantise_baudrate
  * Quantises the baud rate as per AN205 Table 1
  */
@@ -535,7 +593,7 @@ static void cp210x_get_termios_port(struct usb_serial_port 
*port,
 
cflag = *cflagp;
 
-   cp210x_get_config(port, CP210X_GET_LINE_CTL, , 2);
+   cp210x_get_line_ctl(port, );
cflag &= ~CSIZE;
switch (bits & BITS_DATA_MASK) {
case BITS_DATA_5:
@@ -703,7 +761,7 @@ static void cp210x_set_termios(struct tty_struct *tty,
 
/* If the number of data bits is to be updated */
if ((cflag & CSIZE) != (old_cflag & CSIZE)) {
-   cp210x_get_config(port, CP210X_GET_LINE_CTL, , 2);
+   cp210x_get_line_ctl(port, );
bits &= ~BITS_DATA_MASK;
switch (cflag & CSIZE) {
case CS5:
@@ -737,7 +795,7 @@ static void cp210x_set_termios(struct tty_struct *tty,
 
if ((cflag & (PARENB|PARODD|CMSPAR)) !=
(old_cflag & (PARENB|PARODD|CMSPAR))) {
-   cp210x_get_config(port, CP210X_GET_LINE_CTL, , 2);
+   cp210x_get_line_ctl(port, );
bits &= ~BITS_PARITY_MASK;
if (cflag & PARENB) {
if (cflag & CMSPAR) {
@@ -763,7 +821,7 @@ static void cp210x_set_termios(struct tty_struct *tty,
}
 
if ((cflag & CSTOPB) != (old_cflag & CSTOPB)) {
-   cp210x_get_config(port, CP210X_GET_LINE_CTL, , 2);
+   cp210x_get_line_ctl(port, );
bits &= ~BITS_STOP_MASK;
if (cflag & CSTOPB) {
bits |= BITS_STOP_2;
@@ -883,16 +941,23 @@ static int cp210x_port_probe(struct usb_serial_port *port)
struct usb_serial *serial = port->serial;
struct usb_host_interface *cur_altsetting;
struct cp210x_port_private *port_priv;
+   int err;
 
port_priv = kzalloc(sizeof(*port_priv), GFP_KERNEL);
if (!port_priv)
return -ENOMEM;
 
+   /* register access 

[PATCH 2/3] USB: serial: cp210x: Relocated private data from USB interface to port

[Konstantin Shkolnyy]

This change is preparation for implementing a cp2108 bug workaround.
The workaround requires storing some private data. Right now the data is
attached to the USB interface and allocated in the attach() callback.
The bug detection requires USB I/O which is done easier from port_probe()
callback rather than attach(). Since the USB access functions take port
as a parameter, and since the private data is used exclusively by these
functions, it can be allocated in port_probe(). Also, all cp210x devices
have exactly 1 port per USB iterface, so moving private data from the USB
interface to port is trivial.

Signed-off-by: Konstantin Shkolnyy 
---
 drivers/usb/serial/cp210x.c | 43 +++
 1 file changed, 23 insertions(+), 20 deletions(-)

diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index 8ba1005..352fe63 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -43,8 +43,8 @@ static int cp210x_tiocmset(struct tty_struct *, unsigned int, 
unsigned int);
 static int cp210x_tiocmset_port(struct usb_serial_port *port,
unsigned int, unsigned int);
 static void cp210x_break_ctl(struct tty_struct *, int);
-static int cp210x_startup(struct usb_serial *);
-static void cp210x_release(struct usb_serial *);
+static int cp210x_port_probe(struct usb_serial_port *);
+static int cp210x_port_remove(struct usb_serial_port *);
 static void cp210x_dtr_rts(struct usb_serial_port *p, int on);
 
 static const struct usb_device_id id_table[] = {
@@ -197,7 +197,7 @@ static const struct usb_device_id id_table[] = {
 
 MODULE_DEVICE_TABLE(usb, id_table);
 
-struct cp210x_serial_private {
+struct cp210x_port_private {
__u8bInterfaceNumber;
 };
 
@@ -216,8 +216,8 @@ static struct usb_serial_driver cp210x_device = {
.set_termios= cp210x_set_termios,
.tiocmget   = cp210x_tiocmget,
.tiocmset   = cp210x_tiocmset,
-   .attach = cp210x_startup,
-   .release= cp210x_release,
+   .port_probe = cp210x_port_probe,
+   .port_remove= cp210x_port_remove,
.dtr_rts= cp210x_dtr_rts
 };
 
@@ -319,7 +319,7 @@ static int cp210x_get_config(struct usb_serial_port *port, 
u8 request,
unsigned int *data, int size)
 {
struct usb_serial *serial = port->serial;
-   struct cp210x_serial_private *spriv = usb_get_serial_data(serial);
+   struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
__le32 *buf;
int result, i, length;
 
@@ -333,7 +333,7 @@ static int cp210x_get_config(struct usb_serial_port *port, 
u8 request,
/* Issue the request, attempting to read 'size' bytes */
result = usb_control_msg(serial->dev, usb_rcvctrlpipe(serial->dev, 0),
request, REQTYPE_INTERFACE_TO_HOST, 0x,
-   spriv->bInterfaceNumber, buf, size,
+   port_priv->bInterfaceNumber, buf, size,
USB_CTRL_GET_TIMEOUT);
 
/* Convert data into an array of integers */
@@ -364,7 +364,7 @@ static int cp210x_set_config(struct usb_serial_port *port, 
u8 request,
unsigned int *data, int size)
 {
struct usb_serial *serial = port->serial;
-   struct cp210x_serial_private *spriv = usb_get_serial_data(serial);
+   struct cp210x_port_private *port_priv = usb_get_serial_port_data(port);
__le32 *buf;
int result, i, length;
 
@@ -383,13 +383,13 @@ static int cp210x_set_config(struct usb_serial_port 
*port, u8 request,
result = usb_control_msg(serial->dev,
usb_sndctrlpipe(serial->dev, 0),
request, REQTYPE_HOST_TO_INTERFACE, 0x,
-   spriv->bInterfaceNumber, buf, size,
+   port_priv->bInterfaceNumber, buf, size,
USB_CTRL_SET_TIMEOUT);
} else {
result = usb_control_msg(serial->dev,
usb_sndctrlpipe(serial->dev, 0),
request, REQTYPE_HOST_TO_INTERFACE, data[0],
-   spriv->bInterfaceNumber, NULL, 0,
+   port_priv->bInterfaceNumber, NULL, 0,
USB_CTRL_SET_TIMEOUT);
}
 
@@ -878,29 +878,32 @@ static void cp210x_break_ctl(struct tty_struct *tty, int 
break_state)
cp210x_set_config(port, CP210X_SET_BREAK, , 2);
 }
 
-static int cp210x_startup(struct usb_serial *serial)
+static int cp210x_port_probe(struct usb_serial_port *port)
 {
+   struct usb_serial *serial = port->serial;
struct usb_host_interface *cur_altsetting;
-   struct cp210x_serial_private *spriv;
+   struct cp210x_port_private 

Re: Help needed for EHCI problem: removing an active bulk-in QH

[Alan Stern]

[Resend with Hans's correct email address this time...]

On Thu, 22 Oct 2015, Alan Stern wrote:

> Hans and everyone else:
> 
> This continues the discussion of a problem originally posted to the 
> libusb-devel mailing list
> (see  if 
> you're curious).
> 
> The EHCI controller in question is an AMD/ATI SB7x0/SB8x0/SB9x0, as 
> found on the RX780/RX790 motherboard.  I haven't seen this problem 
> occur with Intel hardware.
> 
> The problem arises when an active bulk-in QH is removed from the async
> schedule.  The current qTD is cancelled, and it is the last qTD on the
> QH's queue.  At the time the QH is removed from the async list, the
> overlay region shows that only a fraction of the qTD has been completed
> (maybe 4 KB transferred out of 16 KB total).
> 
> 10 ms later, four new qTDs are added to the QH and it gets added back
> to the async schedule.  Although I don't know this for certain, I
> believe the second of these qTDs is stored at the same address as the
> one that was cancelled.  That's what naturally would happen if the
> memory pool satisfies an allocation from the most recently freed area.
> 
> Anyway, a short time later, it sometimes happen that the controller
> gets stuck.  The Active bit in the QH's overlay region is clear, and
> the Current and Next qTD pointers both point to the second qTD in the
> queue, which obviously is why the controller is not making any forward
> progress.  The first qTD's Active bit is still set and its Bytes To
> Transfer is still set to 16 KB.  The second qTD's Active bit is off and
> its Bytes To Transfer is 0.  In spite of this, neither qTD's data
> buffer has been overwritten.
> 
> Although it's hard to tell exactly what went wrong, my guess is that
> the after the QH was removed from the async schedule, the controller
> continued to process it until all 16 KB had been transferred.  (This
> would have taken no more than 0.5 ms.)  Then at some point, the QH
> overlay and the now-completed qTD were written back -- that would
> explain why the second qTD in the queue shows up as not Active and with
> no bytes remaining to transfer.
> 
> On the other hand, that qTD wasn't reused until 10 ms after the QH was
> removed from the schedule, and it was completely reinitialized before
> reuse.  The write-back must have occurred later than this; I have no
> idea why.  I also don't know why the write-back of the QH's overlay
> region didn't overwrite the Next qTD pointer.
> 
> 
> This is clearly a complicated problem.  It's possible that we're simply
> dealing with defective hardware, but I tend to doubt it.  It seems more
> likely that the problem is caused by improperly removing the active QH
> from the async schedule.  The driver does not follow the instructions
> given in section 4.8.2 of the EHCI spec, which says that software
> should not remove active QHs.
> 
> [In practice it's not feasible to wait for an active QH to become
> inactive before removing it, for several reasons.  For one, the QH may
> _never_ become inactive (if the endpoint NAKs indefinitely).  For
> another, the procedure given in the spec (deactivate the qTDs on the
> queue) is racy, since the controller can perform a new overlay or
> writeback at any time.]
> 
> In an attempt to cope with potential problems, the Linux EHCI driver
> goes through _two_ Interrupt on Async Advance (IAA) cycles after taking
> a QH off the async list before considering it to be fully gone from the
> schedule.  (I have observed situations where the QH overlay region was
> written back _after_ the first IAA interrupt.)  But it seems that this
> isn't enough.
> 
> As far as I can see, the only alternative is to stop the async schedule
> whenever an active QH has to be removed.  But that would impose a
> significant penalty on any other async transfers, so I really don't
> want to do it.
> 
> Hans, can you describe how the BSD EHCI driver handles this issue?  
> 
> Any ideas for fixing this or suggestions for additional debugging would 
> be welcome.
> 
> 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

Help needed for EHCI problem: removing an active bulk-in QH

[Alan Stern]

Hans and everyone else:

This continues the discussion of a problem originally posted to the 
libusb-devel mailing list
(see  if 
you're curious).

The EHCI controller in question is an AMD/ATI SB7x0/SB8x0/SB9x0, as 
found on the RX780/RX790 motherboard.  I haven't seen this problem 
occur with Intel hardware.

The problem arises when an active bulk-in QH is removed from the async
schedule.  The current qTD is cancelled, and it is the last qTD on the
QH's queue.  At the time the QH is removed from the async list, the
overlay region shows that only a fraction of the qTD has been completed
(maybe 4 KB transferred out of 16 KB total).

10 ms later, four new qTDs are added to the QH and it gets added back
to the async schedule.  Although I don't know this for certain, I
believe the second of these qTDs is stored at the same address as the
one that was cancelled.  That's what naturally would happen if the
memory pool satisfies an allocation from the most recently freed area.

Anyway, a short time later, it sometimes happen that the controller
gets stuck.  The Active bit in the QH's overlay region is clear, and
the Current and Next qTD pointers both point to the second qTD in the
queue, which obviously is why the controller is not making any forward
progress.  The first qTD's Active bit is still set and its Bytes To
Transfer is still set to 16 KB.  The second qTD's Active bit is off and
its Bytes To Transfer is 0.  In spite of this, neither qTD's data
buffer has been overwritten.

Although it's hard to tell exactly what went wrong, my guess is that
the after the QH was removed from the async schedule, the controller
continued to process it until all 16 KB had been transferred.  (This
would have taken no more than 0.5 ms.)  Then at some point, the QH
overlay and the now-completed qTD were written back -- that would
explain why the second qTD in the queue shows up as not Active and with
no bytes remaining to transfer.

On the other hand, that qTD wasn't reused until 10 ms after the QH was
removed from the schedule, and it was completely reinitialized before
reuse.  The write-back must have occurred later than this; I have no
idea why.  I also don't know why the write-back of the QH's overlay
region didn't overwrite the Next qTD pointer.


This is clearly a complicated problem.  It's possible that we're simply
dealing with defective hardware, but I tend to doubt it.  It seems more
likely that the problem is caused by improperly removing the active QH
from the async schedule.  The driver does not follow the instructions
given in section 4.8.2 of the EHCI spec, which says that software
should not remove active QHs.

[In practice it's not feasible to wait for an active QH to become
inactive before removing it, for several reasons.  For one, the QH may
_never_ become inactive (if the endpoint NAKs indefinitely).  For
another, the procedure given in the spec (deactivate the qTDs on the
queue) is racy, since the controller can perform a new overlay or
writeback at any time.]

In an attempt to cope with potential problems, the Linux EHCI driver
goes through _two_ Interrupt on Async Advance (IAA) cycles after taking
a QH off the async list before considering it to be fully gone from the
schedule.  (I have observed situations where the QH overlay region was
written back _after_ the first IAA interrupt.)  But it seems that this
isn't enough.

As far as I can see, the only alternative is to stop the async schedule
whenever an active QH has to be removed.  But that would impose a
significant penalty on any other async transfers, so I really don't
want to do it.

Hans, can you describe how the BSD EHCI driver handles this issue?  

Any ideas for fixing this or suggestions for additional debugging would 
be welcome.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 07/21] usb/gadget: Remove set-but-not-used variables

[Bart Van Assche]

Avoid that building with W=1 triggers compiler warnings about
set-but-not-used variables.

Signed-off-by: Bart Van Assche 
Acked-by: Felipe Balbi 
Reviewed-by: Andy Grover 
Cc: Christoph Hellwig 
Cc: Hannes Reinecke 
---
 drivers/usb/gadget/legacy/tcm_usb_gadget.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/drivers/usb/gadget/legacy/tcm_usb_gadget.c 
b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
index 33833fe..ddef0c5 100644
--- a/drivers/usb/gadget/legacy/tcm_usb_gadget.c
+++ b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
@@ -71,18 +71,9 @@ static void bot_enqueue_sense_code(struct f_uas *fu, struct 
usbg_cmd *cmd)
 {
struct bulk_cs_wrap *csw = >bot_status.csw;
int ret;
-   u8 *sense;
unsigned int csw_stat;
 
csw_stat = cmd->csw_code;
-
-   /*
-* We can't send SENSE as a response. So we take ASC & ASCQ from our
-* sense buffer and queue it and hope the host sends a REQUEST_SENSE
-* command where it learns why we failed.
-*/
-   sense = cmd->sense_iu.sense;
-
csw->Tag = cmd->bot_tag;
csw->Status = csw_stat;
fu->bot_status.req->context = cmd;
@@ -1078,7 +1069,6 @@ static int usbg_submit_command(struct f_uas *fu,
struct command_iu *cmd_iu = cmdbuf;
struct usbg_cmd *cmd;
struct usbg_tpg *tpg;
-   struct se_cmd *se_cmd;
struct tcm_usbg_nexus *tv_nexus;
u32 cmd_len;
int ret;
@@ -1142,7 +1132,6 @@ static int usbg_submit_command(struct f_uas *fu,
break;
}
 
-   se_cmd = >se_cmd;
cmd->unpacked_lun = scsilun_to_int(_iu->lun);
 
INIT_WORK(>work, usbg_cmd_work);
@@ -1195,7 +1184,6 @@ static int bot_submit_command(struct f_uas *fu,
struct bulk_cb_wrap *cbw = cmdbuf;
struct usbg_cmd *cmd;
struct usbg_tpg *tpg;
-   struct se_cmd *se_cmd;
struct tcm_usbg_nexus *tv_nexus;
u32 cmd_len;
int ret;
@@ -1236,7 +1224,6 @@ static int bot_submit_command(struct f_uas *fu,
}
 
cmd->prio_attr = TCM_SIMPLE_TAG;
-   se_cmd = >se_cmd;
cmd->unpacked_lun = cbw->Lun;
cmd->is_read = cbw->Flags & US_BULK_FLAG_IN ? 1 : 0;
cmd->data_len = le32_to_cpu(cbw->DataTransferLength);
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Alternative approach to solve the deferred probe (was: [GIT PULL] On-demand device probing)

[Mark Brown]

On Tue, Oct 20, 2015 at 04:46:56PM +0100, Russell King - ARM Linux wrote:

> Something like this.  I haven't put a lot of effort into it to change all
> the places which return an -EPROBE_DEFER, and it also looks like we need
> some helpers to report when we have only an device_node (or should that
> be fwnode?)  See the commented out of_warn_deferred() in
> drivers/gpio/gpiolib-of.c.  Adding this stuff in the subsystems searching
> for resources should make debugging why things are getting deferred easier.

Yeah, plus I'd expect it to also result in better error reporting
overall if the subsystems are able to report when they fail to get
something rather than just returning an error to the driver.

> +/**
> + * dev_warn_deferred() - report why a probe has been deferred
> + */
> +void dev_warn_deferred(struct device *dev, const char *fmt, ...)
> +{
> + if (driver_deferred_probe_report) {
> + struct va_format vaf;
> + va_list ap;
> +
> + va_start(ap, fmt);
> + vaf.fmt = fmt;
> + vaf.va = 
> +
> + dev_warn(dev, "deferring probe: %pV", );
> + va_end(ap);
> + }
> +}
> +EXPORT_SYMBOL_GPL(dev_warn_deferred);

I'm not currently able to think of a nice way of writing this but I think
what I'd really like to see from a driver point of view is something
which decays into dev_err() if it's a non-deferral error.  That way
drivers can have minimal log and return error handling code and we will
still get the output sensibly.  The best I can think of is something
like

   void dev_warn_deferred(struct device *dev, int err, const char *fmt, ...)

which requires the caller to pass in err twice to get it logged.  That's
not a thing of beauty but it gets the job done...  but perhaps your
original interface is better, it's a bit cleaner.


signature.asc
Description: PGP signature

Re: [PATCH] USB: qcserial: add Sierra Wireless MC74xx/EM74xx

[Greg Kroah-Hartman]

On Thu, Oct 22, 2015 at 03:36:34PM +0200, Johan Hovold wrote:
> On Thu, Oct 22, 2015 at 02:24:24PM +0200, Bjørn Mork wrote:
> > New device IDs shamelessly lifted from the vendor driver.
> > 
> > Cc: 
> > Signed-off-by: Bjørn Mork 
> 
> Acked-by: Johan Hovold 
> 
> Greg, can you pick this one directly for 4.4-rc1? Applies cleanly on top
> of my latest pull-request.

Yes, will do so, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] USB chipidea driver fixes for 4.3-rc6

[Greg KH]

On Wed, Oct 21, 2015 at 04:25:58PM +0800, Peter Chen wrote:
> The following changes since commit fd7cd061adcf5f7503515ba52b6a724642a839c8:
> 
>   xhci: Add spurious wakeup quirk for LynxPoint-LP controllers (2015-10-17 
> 00:04:18 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git/ 
> tags/usb-ci-v4.3-rc6
> 
> for you to fetch changes up to 89286bb4f3f92311f4945197157a0d259f9b06fc:
> 
>   usb: chipidea: otg: gadget module load and unload support (2015-10-21 
> 15:36:02 +0800)
> 
> 
> There are below fixes for this set:
> - imx27 usb crash issue
> - Load and unload gadget module can't be supported at
>   OTG FSM mode issue
> - Other small issues
> 
> 
> Felipe F. Tonello (1):
>   usb: chipidea: udc: _ep_queue and _hw_queue cleanup
> 
> Li Jun (2):
>   usb: chipidea: debug: disable usb irq while role switch
>   usb: chipidea: otg: gadget module load and unload support
> 
> Peter Chen (2):
>   usb: chipidea: imx: refine clock operations to adapt for all platforms
>   ARM: dts: imx27.dtsi: change the clock information for usb
> 
>  arch/arm/boot/dts/imx27.dtsi   |  16 +++--
>  drivers/usb/chipidea/ci_hdrc_imx.c | 131 
> -
>  drivers/usb/chipidea/debug.c   |   2 +
>  drivers/usb/chipidea/udc.c |  25 ++-
>  4 files changed, 150 insertions(+), 24 deletions(-)

It's really late in the -rc cycle, can you send all of these as
individual patches so I can review them first?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] USB patches for v4.4 merge window

[Greg KH]

On Tue, Oct 20, 2015 at 01:44:05PM -0500, Felipe Balbi wrote:
> Hi Greg,
> 
> Here's the large gadget pull request for v4.4. All patches have been
> in next for a while and should be safe to apply.
> 
> Let me know if you want any changes to this pull request.
> 
> cheers
> 
> The following changes since commit 9ffecb10283508260936b96022d4ee43a7798b4c:
> 
>   Linux 4.3-rc3 (2015-09-27 07:50:08 -0400)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
> tags/usb-for-v4.4

Pulled and pushed out, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] On-demand device probing

[Mark Brown]

On Thu, Oct 22, 2015 at 04:02:13PM +0100, Russell King - ARM Linux wrote:

> If it was such a problem, then in the _eight_ days that this has been
> discussed so far, _someone_ would have sent some data showing the
> problem.  I think the fact is, there is no data.

> Someone prove me wrong.  Someone post the verifiable data showing that
> there is a problem to be solved here.

> Someone show what the specific failure cases are that are hampering
> vendors moving forwards.  Someone show the long boot times by way of
> kernel message log.  Someone show some evidence of the problems that
> have been alluded to.

> If no one can show some evidence, there isn't a problem here. :)

Yeah, I'm not convinced the timing is *such* a big deal either - I do
think that the log spam is a real problem but I think something much
less invasive like the interface you proposed is good for addressing
that.


signature.asc
Description: PGP signature

Re: [GIT PULL] USB-serial updates for v4.4-rc1

[Greg Kroah-Hartman]

On Wed, Oct 21, 2015 at 11:05:58AM +0200, Johan Hovold wrote:
> Hi Greg,
> 
> Here are my updates for 4.4. All have been in linux-next for some time.
> 
> Thanks,
> Johan
> 
> 
> The following changes since commit 049e6dde7e57f0054fdc49102e7ef4830c698b46:
> 
>   Linux 4.3-rc4 (2015-10-04 16:57:17 +0100)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git 
> tags/usb-serial-4.4-rc1

Pulled and pushed out, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] USB Chipidea updates for v4.4-rc1

[Greg Kroah-Hartman]

On Thu, Oct 22, 2015 at 10:02:45AM +0800, Peter Chen wrote:
> Hi Greg,
> 
> Below are my updates for v4.4-rc1, thanks.
> 
> Peter
> 
> The following changes since commit ffa236f06ce1df3296d106d90e0c2e0cd6b7:
> 
>   usb/host/fotg210: Remove return statement inside if (2015-10-17 20:49:50 
> -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git/ 
> tags/usb-ci-v4.4-rc1

Pulled and pushed out, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MUSB peripheral DMA regression caused by driver core runtime PM change

[Tony Lindgren]

* Tony Lindgren  [151022 11:03]:
> * Tony Lindgren  [151021 16:44]:
> > Hi all,
> > 
> > I noticed a regresssino in v4.3-rc series to day with MUSB gadgets
> > and DMA. Doing a git bisect between v4.2..v4.3-rc1 on it pointed to:
> > 
> > ddef08dd00f5 ("Driver core: wakeup the parent device before trying probe")
> > 
> > With the commit above reverted things work fine with DMA and USB gadgets.
> > 
> > This is on omap3 with CONFIG_USB_INVENTRA_DMA selected. Selecting
> > CONFIG_MUSB_PIO_ONLY still works even without reverting ddef08dd00f5.
> > 
> > Anybody got ideas what might be wrong? Some wrong runtime PM usage
> > under drivers/usb/musb?
> 
> Here's some more debug info on where things are different initializing
> the USB gadgets. I added some printks and diffed the dmesg output. The
> added calls from commit ddef08dd00f5 start with dd:

Well turns out the problem actually happens earlier. We end up calling
omap2430_runtime_resume with NULL struct musb while EPROBE_DEFER
probing.

No ideas yet how it should be fixed though.

Regards,

Tony
--
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: [GIT PULL] On-demand device probing

[Tomeu Vizoso]

On 21 October 2015 at 23:50, Frank Rowand  wrote:
> On 10/21/2015 2:12 PM, Rob Herring wrote:
>> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand  wrote:
>>> On 10/21/2015 9:27 AM, Mark Brown wrote:
 On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:

>> To be clear, I was saying that this series should NOT affect total
>> boot times much.

> I'm confused.  If I understood correctly, improving boot time was
> the key justification for accepting this patch set.  For example,
> from "[PATCH v7 0/20] On-demand device probing":
>
>I have a problem with the panel on my Tegra Chromebook taking longer
>than expected to be ready during boot (Stéphane Marchesin reported what
>is basically the same issue in [0]), and have looked into ordered
>probing as a better way of solving this than moving nodes around in the
>DT or playing with initcall levels and linking order.
>
>...
>
>With this series I get the kernel to output to the panel in 0.5s,
>instead of 2.8s.

 Overall boot time and time to get some individual built in component up
 and running aren't the same thing - what this'll do is get things up
 more in the link order of the leaf consumers rather than deferring those
 leaf consumers when their dependencies aren't ready yet.
>>>
>>> Thanks!  I read too much into what was being improved.
>>>
>>> So this patch series, which on other merits may be a good idea, is as
>>> a by product solving a specific ordering issue, moving successful panel
>>> initialization to an earlier point in the boot sequence, if I now
>>> understand more correctly.
>>>
>>> In that context, this seems like yet another ad hoc way of causing the
>>> probe order to change in a way to solves one specific issue?  Could
>>> it just as likely move the boot order of some other driver on some
>>> other board later, to the detriment of somebody else?
>>
>> Time to display on is important for many products. Having the console
>> up as early as possible is another case. CAN bus is another. This is a
>> real problem that is not just bad drivers.
>
> Yes, I agree.
>
> What I am seeing is that there continues to be a need for the ability
> to explicitly order at least some driver initialization (at some
> granularity), despite the push back against explicit ordering that
> has been present in the past.

The important point that I have struggled to explain is that right now
for downstreams to influence the order in which devices are probed,
they have to carry a substantial amount of patches that cannot be ever
upstreamed. This fiddling with initcall levels and link order means
changing files that are very frequently changing, increasing the
amount of work when rebasing and increasing the probability of
regressions after a rebase.

This just adds up to other shortcomings of mainline and ends up with
the net result of vendors getting stuck with 3.4 kernels on SoCs that
start production in 2015. Another consequence is that vendors don't
have a chance to upstream their stuff even if they cared. The
overarching goal of the project I'm in is to reduce those shortcomings
that downstreams have to workaround, to facilitate their involvement
upstream.

With this series, the order in which devices are probed becomes the
order in which they were registered, which is the order in which the
devices appear in the FW description of the hw or in the board files
(much more predictable, which makes for a more robust process). For DT
and board files, which cover a good part of the consumer devices
shipped today with Linux, the downstream could just change the order
of device nodes and get their display or whatever to probe before any
other devices.

And even if downstream's hw has a SoC .dtsi that exists in mainline,
they could add a step to their build process that automatically
reorders the nodes to avoid carrying changes to that DT fragment.

But that's moot currently because Greg believes that the time spent
probing devices at boot time could be reduced enough so that the order
in which devices are probed becomes irrelevant. IME that would have to
be under 200ms so that the user doesn't notice and that's unicorn-far
from any bootlog I have ever seen.

Given that downstreams are already carrying as many hacks as they
could think of to speed total boot up, I think this is effectively
telling them to go away.

Sorry for the rant,

Tomeu

>> I don't think it is completely ad hoc. Given all devices are
>> registered after drivers, drivers will still probe first in initcall
>> level order and then link order AFAIK. We may not take (more) initcall
>> level tweak hacks, but that is a much more simple change for
>> downstream. Don't get me wrong, I'd really like to see a way to
>> control order independent of initcall level.
>>
>> Rob
>
> Yep, it is 

Re: [PATCH net,stable] qmi_wwan: add Sierra Wireless MC74xx/EM74xx

[David Miller]

From: Bjørn Mork 
Date: Thu, 22 Oct 2015 14:15:58 +0200

> New device IDs shamelessly lifted from the vendor driver.
> 
> Signed-off-by: Bjørn Mork 

Applied, thank you.
--
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: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> On 21 October 2015 at 23:50, Frank Rowand  wrote:
> > On 10/21/2015 2:12 PM, Rob Herring wrote:
> >> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand  
> >> wrote:
> >>> On 10/21/2015 9:27 AM, Mark Brown wrote:
>  On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
> > On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
> 
> >> To be clear, I was saying that this series should NOT affect total
> >> boot times much.
> 
> > I'm confused.  If I understood correctly, improving boot time was
> > the key justification for accepting this patch set.  For example,
> > from "[PATCH v7 0/20] On-demand device probing":
> >
> >I have a problem with the panel on my Tegra Chromebook taking longer
> >than expected to be ready during boot (Stéphane Marchesin reported 
> > what
> >is basically the same issue in [0]), and have looked into ordered
> >probing as a better way of solving this than moving nodes around in 
> > the
> >DT or playing with initcall levels and linking order.
> >
> >...
> >
> >With this series I get the kernel to output to the panel in 0.5s,
> >instead of 2.8s.
> 
>  Overall boot time and time to get some individual built in component up
>  and running aren't the same thing - what this'll do is get things up
>  more in the link order of the leaf consumers rather than deferring those
>  leaf consumers when their dependencies aren't ready yet.
> >>>
> >>> Thanks!  I read too much into what was being improved.
> >>>
> >>> So this patch series, which on other merits may be a good idea, is as
> >>> a by product solving a specific ordering issue, moving successful panel
> >>> initialization to an earlier point in the boot sequence, if I now
> >>> understand more correctly.
> >>>
> >>> In that context, this seems like yet another ad hoc way of causing the
> >>> probe order to change in a way to solves one specific issue?  Could
> >>> it just as likely move the boot order of some other driver on some
> >>> other board later, to the detriment of somebody else?
> >>
> >> Time to display on is important for many products. Having the console
> >> up as early as possible is another case. CAN bus is another. This is a
> >> real problem that is not just bad drivers.
> >
> > Yes, I agree.
> >
> > What I am seeing is that there continues to be a need for the ability
> > to explicitly order at least some driver initialization (at some
> > granularity), despite the push back against explicit ordering that
> > has been present in the past.
> 
> The important point that I have struggled to explain is that right now
> for downstreams to influence the order in which devices are probed,
> they have to carry a substantial amount of patches that cannot be ever
> upstreamed. This fiddling with initcall levels and link order means
> changing files that are very frequently changing, increasing the
> amount of work when rebasing and increasing the probability of
> regressions after a rebase.
> 
> This just adds up to other shortcomings of mainline and ends up with
> the net result of vendors getting stuck with 3.4 kernels on SoCs that
> start production in 2015. Another consequence is that vendors don't
> have a chance to upstream their stuff even if they cared. The
> overarching goal of the project I'm in is to reduce those shortcomings
> that downstreams have to workaround, to facilitate their involvement
> upstream.

The init order of drivers has no influence at all on the ability for
companies to have their individual drivers merged upstream, please don't
be so dramatic about this.

Worst case, a vendor keeps a single patch to drivers/Makefile in their
tree that reorders things, yes it will get conflicts on every release,
but really, it's trivial to maintain if they wish to keep doing this
type of thing.

Again, it is _not_ the reason that we are living with 2million+ lines of
code in vendor kernels.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/15] fs: configfs: Add unlocked version of configfs_depend_item()

[Krzysztof Opasiak]

On 10/22/2015 03:16 PM, Christoph Hellwig wrote:

On Tue, Oct 20, 2015 at 02:32:32PM +0200, Andrzej Pietrasiewicz wrote:

From: Krzysztof Opasiak 

This change is necessary for the SCSI target usb gadget composed with
configfs. In this case configfs will be used for two different purposes:
to compose a usb gadget and to configure the target part. If an instance
of tcm function is created in $CONFIGFS_ROOT/usb_gadget//functions
a tpg can be created in $CONFIGFS_ROOT/target/usb_gadget//, but after
a tpg is created the tcm function must not be removed until its
corresponding tpg is gone. While the configfs_depend/undepend_item() are
meant exactly for creating this kind of dependencies, they are not suitable
if the other kernel subsystem happens to be another subsystem in configfs,
so this patch adds unlocked versions meant for configfs callbacks.


configfs_depend_item is a lot of deep magic (which I haven't even tried
to fully understand yet).  Can you explain why your versions is safe
without all that?  Can also please document the precoditions required
for the function in comments, or wherever possible asserts?

Also needs a kerneldoc comment explaining the exact semantics.



Could you please take a look onto v2 version? This patch has been 
updated due to Joel's remarks and when I was writing this I didn't mean 
this to be used from other configfs subsystem. Now it is updated and 
should work fine in all configfs callbacks



+void configfs_undepend_item_unlocked(struct config_item *target)
+{
+   configfs_undepend_item(NULL, target);
+}
+EXPORT_SYMBOL(configfs_undepend_item_unlocked);


And given that configfs_undepend_item ignores the subsys argument this
wrapper clearl isn't needed.  Just send a separate patch to drop the
subsys argument to configfs_undepend_item instead.



Well, here I would not agree. In my opinion subsys argument has been 
left to make this API symmetric and I think that's a good idea.


Thanks,
--
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics
--
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: [GIT PULL] On-demand device probing

[Greg Kroah-Hartman]

On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> But that's moot currently because Greg believes that the time spent
> probing devices at boot time could be reduced enough so that the order
> in which devices are probed becomes irrelevant. IME that would have to
> be under 200ms so that the user doesn't notice and that's unicorn-far
> from any bootlog I have ever seen.

But as no one has actually produced a bootlog, how do you know that?
Where exactly is your time being spent?  What driver is causing long
delays?  Why is the long-delay-drivers not being done in their own
thread?  And most importantly, why are you ignoring the work that people
did back in 2008 to solve the issue on other hardware platforms?

> Given that downstreams are already carrying as many hacks as they
> could think of to speed total boot up, I think this is effectively
> telling them to go away.

No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
solve-the-random-issue-i'm-having type patch by putting random calls in
semi-random subsystems all over the kernel.

And when I ask for real data, you respond with the fact that you aren't
trying to speed up boot time here at all, so what am I supposed to think
other than that you don't care enough to do the real work and are trying
to hack the driver core up instead.

> Sorry for the rant,

No apologies needed, it's cathartic at times :)

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 4/5] usb: chipidea: debug: disable usb irq while role switch

[Peter Chen]

From: Li Jun 

Since the ci->role will be set after the host role start is complete, there
will be nobody cared irq during start host if usb irq enabled. This error
can be reproduced on i.mx6 sololite EVK board by:
1. disable otg id irq(IDIE) and disable all real otg properties of usbotg1
   in dts.
2. boot up the board with ID cable and usb device connected.
3. echo gadget > /sys/kernel/debug/ci_hdrc.0/role
4. echo host > /sys/kernel/debug/ci_hdrc.0/role
5. irq 212: nobody cared.

Cc:  # v3.10+
Signed-off-by: Li Jun 
Signed-off-by: Peter Chen 
---
 drivers/usb/chipidea/debug.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/chipidea/debug.c b/drivers/usb/chipidea/debug.c
index 080b7be..58c8485 100644
--- a/drivers/usb/chipidea/debug.c
+++ b/drivers/usb/chipidea/debug.c
@@ -322,8 +322,10 @@ static ssize_t ci_role_write(struct file *file, const char 
__user *ubuf,
return -EINVAL;
 
pm_runtime_get_sync(ci->dev);
+   disable_irq(ci->irq);
ci_role_stop(ci);
ret = ci_role_start(ci, role);
+   enable_irq(ci->irq);
pm_runtime_put_sync(ci->dev);
 
return ret ? ret : count;
-- 
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 1/5] usb: chipidea: udc: _ep_queue and _hw_queue cleanup

[Peter Chen]

On Thu, Oct 22, 2015 at 08:08:21PM -0700, Greg KH wrote:
> On Fri, Oct 23, 2015 at 09:52:50AM +0800, Peter Chen wrote:
> > From: "Felipe F. Tonello" 
> > 
> > Update comments to reflect current state of functions.
> > 
> > Signed-off-by: Felipe F. Tonello 
> > Signed-off-by: Peter Chen 
> > ---
> >  drivers/usb/chipidea/udc.c | 8 ++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> This isn't a late -rc patch :(

Oh, sorry, it is just a cleanup. 

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/5] usb: chipidea: otg: gadget module load and unload support

[Peter Chen]

From: Li Jun 

This patch is to support load and unload gadget driver in full OTG mode.

Signed-off-by: Li Jun 
Signed-off-by: Peter Chen 
Tested-by: Jiada Wang 
Cc:  #v4.0+
---
 drivers/usb/chipidea/udc.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index e19d8b8..67cfa04 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1755,6 +1755,22 @@ static int ci_udc_start(struct usb_gadget *gadget,
return retval;
 }
 
+static void ci_udc_stop_for_otg_fsm(struct ci_hdrc *ci)
+{
+   if (!ci_otg_is_fsm_mode(ci))
+   return;
+
+   mutex_lock(>fsm.lock);
+   if (ci->fsm.otg->state == OTG_STATE_A_PERIPHERAL) {
+   ci->fsm.a_bidl_adis_tmout = 1;
+   ci_hdrc_otg_fsm_start(ci);
+   } else if (ci->fsm.otg->state == OTG_STATE_B_PERIPHERAL) {
+   ci->fsm.protocol = PROTO_UNDEF;
+   ci->fsm.otg->state = OTG_STATE_UNDEFINED;
+   }
+   mutex_unlock(>fsm.lock);
+}
+
 /**
  * ci_udc_stop: unregister a gadget driver
  */
@@ -1779,6 +1795,7 @@ static int ci_udc_stop(struct usb_gadget *gadget)
ci->driver = NULL;
spin_unlock_irqrestore(>lock, flags);
 
+   ci_udc_stop_for_otg_fsm(ci);
return 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

[PATCH 2/5] usb: chipidea: imx: refine clock operations to adapt for all platforms

[Peter Chen]

Some i.mx platforms need three clocks to let controller work, but
others only need one, refine clock operation to adapt for all
platforms, it fixes a regression found at i.mx27.

Signed-off-by: Peter Chen 
Tested-by: Fabio Estevam 
Cc:  #v4.1+
---
 drivers/usb/chipidea/ci_hdrc_imx.c | 131 -
 1 file changed, 113 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
b/drivers/usb/chipidea/ci_hdrc_imx.c
index dcc50c87..ad53aed 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -73,6 +73,12 @@ struct ci_hdrc_imx_data {
struct imx_usbmisc_data *usbmisc_data;
bool supports_runtime_pm;
bool in_lpm;
+   /* SoC before i.mx6 (except imx23/imx28) needs three clks */
+   bool need_three_clks;
+   struct clk *clk_ipg;
+   struct clk *clk_ahb;
+   struct clk *clk_per;
+   /* - */
 };
 
 /* Common functions shared by usbmisc drivers */
@@ -124,6 +130,102 @@ static struct imx_usbmisc_data 
*usbmisc_get_init_data(struct device *dev)
 }
 
 /* End of common functions shared by usbmisc drivers*/
+static int imx_get_clks(struct device *dev)
+{
+   struct ci_hdrc_imx_data *data = dev_get_drvdata(dev);
+   int ret = 0;
+
+   data->clk_ipg = devm_clk_get(dev, "ipg");
+   if (IS_ERR(data->clk_ipg)) {
+   /* If the platform only needs one clocks */
+   data->clk = devm_clk_get(dev, NULL);
+   if (IS_ERR(data->clk)) {
+   ret = PTR_ERR(data->clk);
+   dev_err(dev,
+   "Failed to get clks, err=%ld,%ld\n",
+   PTR_ERR(data->clk), PTR_ERR(data->clk_ipg));
+   return ret;
+   }
+   return ret;
+   }
+
+   data->clk_ahb = devm_clk_get(dev, "ahb");
+   if (IS_ERR(data->clk_ahb)) {
+   ret = PTR_ERR(data->clk_ahb);
+   dev_err(dev,
+   "Failed to get ahb clock, err=%d\n", ret);
+   return ret;
+   }
+
+   data->clk_per = devm_clk_get(dev, "per");
+   if (IS_ERR(data->clk_per)) {
+   ret = PTR_ERR(data->clk_per);
+   dev_err(dev,
+   "Failed to get per clock, err=%d\n", ret);
+   return ret;
+   }
+
+   data->need_three_clks = true;
+   return ret;
+}
+
+static int imx_prepare_enable_clks(struct device *dev)
+{
+   struct ci_hdrc_imx_data *data = dev_get_drvdata(dev);
+   int ret = 0;
+
+   if (data->need_three_clks) {
+   ret = clk_prepare_enable(data->clk_ipg);
+   if (ret) {
+   dev_err(dev,
+   "Failed to prepare/enable ipg clk, err=%d\n",
+   ret);
+   return ret;
+   }
+
+   ret = clk_prepare_enable(data->clk_ahb);
+   if (ret) {
+   dev_err(dev,
+   "Failed to prepare/enable ahb clk, err=%d\n",
+   ret);
+   clk_disable_unprepare(data->clk_ipg);
+   return ret;
+   }
+
+   ret = clk_prepare_enable(data->clk_per);
+   if (ret) {
+   dev_err(dev,
+   "Failed to prepare/enable per clk, err=%d\n",
+   ret);
+   clk_disable_unprepare(data->clk_ahb);
+   clk_disable_unprepare(data->clk_ipg);
+   return ret;
+   }
+   } else {
+   ret = clk_prepare_enable(data->clk);
+   if (ret) {
+   dev_err(dev,
+   "Failed to prepare/enable clk, err=%d\n",
+   ret);
+   return ret;
+   }
+   }
+
+   return ret;
+}
+
+static void imx_disable_unprepare_clks(struct device *dev)
+{
+   struct ci_hdrc_imx_data *data = dev_get_drvdata(dev);
+
+   if (data->need_three_clks) {
+   clk_disable_unprepare(data->clk_per);
+   clk_disable_unprepare(data->clk_ahb);
+   clk_disable_unprepare(data->clk_ipg);
+   } else {
+   clk_disable_unprepare(data->clk);
+   }
+}
 
 static int ci_hdrc_imx_probe(struct platform_device *pdev)
 {
@@ -142,23 +244,18 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
if (!data)
return -ENOMEM;
 
+   platform_set_drvdata(pdev, data);
data->usbmisc_data = usbmisc_get_init_data(>dev);
if (IS_ERR(data->usbmisc_data))
return PTR_ERR(data->usbmisc_data);
 
-   data->clk = devm_clk_get(>dev, NULL);
-   if 

[PATCH 0/5] USB Chipidea fixes

[Peter Chen]

Hi Greg,

These five fixes are too late for v4.3 rc, it is based on your
usb-linus tree, would you please review it first? I will send
them as v4.4 bug fixes after v4.4-rc1 is out, thanks.

Felipe F. Tonello (1):
  usb: chipidea: udc: _ep_queue and _hw_queue cleanup

Li Jun (2):
  usb: chipidea: debug: disable usb irq while role switch
  usb: chipidea: otg: gadget module load and unload support

Peter Chen (2):
  usb: chipidea: imx: refine clock operations to adapt for all platforms
  ARM: dts: imx27.dtsi: change the clock information for usb

 arch/arm/boot/dts/imx27.dtsi   |  16 +++--
 drivers/usb/chipidea/ci_hdrc_imx.c | 131 -
 drivers/usb/chipidea/debug.c   |   2 +
 drivers/usb/chipidea/udc.c |  25 ++-
 4 files changed, 150 insertions(+), 24 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 1/5] usb: chipidea: udc: _ep_queue and _hw_queue cleanup

[Peter Chen]

From: "Felipe F. Tonello" 

Update comments to reflect current state of functions.

Signed-off-by: Felipe F. Tonello 
Signed-off-by: Peter Chen 
---
 drivers/usb/chipidea/udc.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 8223fe7..e19d8b8 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -404,9 +404,9 @@ static inline u8 _usb_addr(struct ci_hw_ep *ep)
 }
 
 /**
- * _hardware_queue: configures a request at hardware level
- * @gadget: gadget
+ * _hardware_enqueue: configures a request at hardware level
  * @hwep:   endpoint
+ * @hwreq:  request
  *
  * This function returns an error code
  */
@@ -788,8 +788,12 @@ static void isr_get_status_complete(struct usb_ep *ep, 
struct usb_request *req)
 
 /**
  * _ep_queue: queues (submits) an I/O request to an endpoint
+ * @ep:endpoint
+ * @req:   request
+ * @gfp_flags: GFP flags (not used)
  *
  * Caller must hold lock
+ * This function returns an error code
  */
 static int _ep_queue(struct usb_ep *ep, struct usb_request *req,
gfp_t __maybe_unused gfp_flags)
-- 
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/5] ARM: dts: imx27.dtsi: change the clock information for usb

[Peter Chen]

For imx27, it needs three clocks to let the controller work,
the old code is wrong, and usbmisc has not included clock handling
code any more. Without this patch, it will cause below data
abort when accessing usbmisc registers.

usbcore: registered new interface driver usb-storage
Unhandled fault: external abort on non-linefetch (0x008) at 0xf4424600
pgd = c0004000
[f4424600] *pgd=1452(bad)
Internal error: : 8 [#1] PREEMPT ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.1.0-next-20150701-dirty #3089
Hardware name: Freescale i.MX27 (Device Tree Support)
task: c7832b60 ti: c783e000 task.ti: c783e000
PC is at usbmisc_imx27_init+0x4c/0xbc
LR is at usbmisc_imx27_init+0x40/0xbc
pc : []lr : []psr: 6093
sp : c783fe08  ip :   fp : 
r10: c0576434  r9 : 009c  r8 : c7a773a0
r7 : 0100  r6 : 6013  r5 : c7a776f0  r4 : c7a773f0
r3 : f4424600  r2 :   r1 : 0001  r0 : 0001
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 0005317f  Table: a0004000  DAC: 0017
Process swapper (pid: 1, stack limit = 0xc783e190)
Stack: (0xc783fe08 to 0xc784)

Signed-off-by: Peter Chen 
Reported-by: Fabio Estevam 
Tested-by: Fabio Estevam 
Cc:  #v4.1+
Acked-by: Shawn Guo 
---
 arch/arm/boot/dts/imx27.dtsi | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
index feb9d34..f818ea4 100644
--- a/arch/arm/boot/dts/imx27.dtsi
+++ b/arch/arm/boot/dts/imx27.dtsi
@@ -486,7 +486,10 @@
compatible = "fsl,imx27-usb";
reg = <0x10024000 0x200>;
interrupts = <56>;
-   clocks = < IMX27_CLK_USB_IPG_GATE>;
+   clocks = < IMX27_CLK_USB_IPG_GATE>,
+   < IMX27_CLK_USB_AHB_GATE>,
+   < IMX27_CLK_USB_DIV>;
+   clock-names = "ipg", "ahb", "per";
fsl,usbmisc = < 0>;
status = "disabled";
};
@@ -495,7 +498,10 @@
compatible = "fsl,imx27-usb";
reg = <0x10024200 0x200>;
interrupts = <54>;
-   clocks = < IMX27_CLK_USB_IPG_GATE>;
+   clocks = < IMX27_CLK_USB_IPG_GATE>,
+   < IMX27_CLK_USB_AHB_GATE>,
+   < IMX27_CLK_USB_DIV>;
+   clock-names = "ipg", "ahb", "per";
fsl,usbmisc = < 1>;
dr_mode = "host";
status = "disabled";
@@ -505,7 +511,10 @@
compatible = "fsl,imx27-usb";
reg = <0x10024400 0x200>;
interrupts = <55>;
-   clocks = < IMX27_CLK_USB_IPG_GATE>;
+   clocks = < IMX27_CLK_USB_IPG_GATE>,
+   < IMX27_CLK_USB_AHB_GATE>,
+   < IMX27_CLK_USB_DIV>;
+   clock-names = "ipg", "ahb", "per";
fsl,usbmisc = < 2>;
dr_mode = "host";
status = "disabled";
@@ -515,7 +524,6 @@
#index-cells = <1>;
compatible = "fsl,imx27-usbmisc";
reg = <0x10024600 0x200>;
-   clocks = < IMX27_CLK_USB_AHB_GATE>;
};
 
sahara2: sahara@10025000 {
-- 
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] usb: isp1760: add description for two config

[roy . qing . li]

From: Li RongQing  

add the description for USB_ISP1760_HCD and USB_ISP1761_UDC, otherwise
a use can not enable them

Signed-off-by: Li RongQing 
---
 drivers/usb/isp1760/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/isp1760/Kconfig b/drivers/usb/isp1760/Kconfig
index c94b7d9..71d6117 100644
--- a/drivers/usb/isp1760/Kconfig
+++ b/drivers/usb/isp1760/Kconfig
@@ -15,10 +15,10 @@ config USB_ISP1760
  module will be called isp1760.
 
 config USB_ISP1760_HCD
-   bool
+   bool "ISP1760 HCD support"
 
 config USB_ISP1761_UDC
-   bool
+   bool "ISP1761 UDC support"
 
 if USB_ISP1760
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] usb: chipidea: support debugfs without CONFIG_USB_CHIPIDEA_DEBUG

[Peter Chen]

On Thu, Oct 22, 2015 at 08:06:31PM -0700, Greg KH wrote:
> On Fri, Oct 23, 2015 at 10:43:46AM +0800, Peter Chen wrote:
> > Since we need to mount debugfs to show/store the things we
> > want to debug, it is duplicated to add another configuration
> > to enable it. Meanwhile, with CONFIG_USB_CHIPIDEA_DEBUG,
> > we can't support chipidea debugfs at runtime.
> 
> Why not also delete the config option?  Why do you still need it with
> dynamic debug these days?
> 

Maybe the CONFIG_DYNAMIC_DEBUG is not enabled for most of platforms by
default [1], adding CONFIG_DYNAMIC_DEBUG needs to rebuild all kernel
source and wait more time.

But you are right, we have dynamic debug already, why not using it
for all code? I will try to see if chipidea and usb gadget can use
it well.

[1]
b29397@shlinux2:~/work/projects/usb$ grep -rn CONFIG_DYNAMIC_DEBUG 
arch/arm/configs/*
arch/arm/configs/bcm2835_defconfig:124:CONFIG_DYNAMIC_DEBUG=y
arch/arm/configs/mmp2_defconfig:91:#
CONFIG_DYNAMIC_DEBUG is not set
arch/arm/configs/qcom_defconfig:171:CONFIG_DYNAMIC_DEBUG=y
arch/arm/configs/zx_defconfig:124:CONFIG_DYNAMIC_DEBUG=y

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] USB chipidea driver fixes for 4.3-rc6

[Peter Chen]

On Thu, Oct 22, 2015 at 06:24:13PM -0700, Greg KH wrote:
> On Wed, Oct 21, 2015 at 04:25:58PM +0800, Peter Chen wrote:
> > The following changes since commit fd7cd061adcf5f7503515ba52b6a724642a839c8:
> > 
> >   xhci: Add spurious wakeup quirk for LynxPoint-LP controllers (2015-10-17 
> > 00:04:18 -0700)
> > 
> > are available in the git repository at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git/ 
> > tags/usb-ci-v4.3-rc6
> > 
> > for you to fetch changes up to 89286bb4f3f92311f4945197157a0d259f9b06fc:
> > 
> >   usb: chipidea: otg: gadget module load and unload support (2015-10-21 
> > 15:36:02 +0800)
> > 
> > 
> > There are below fixes for this set:
> > - imx27 usb crash issue
> > - Load and unload gadget module can't be supported at
> >   OTG FSM mode issue
> > - Other small issues
> > 
> > 
> > Felipe F. Tonello (1):
> >   usb: chipidea: udc: _ep_queue and _hw_queue cleanup
> > 
> > Li Jun (2):
> >   usb: chipidea: debug: disable usb irq while role switch
> >   usb: chipidea: otg: gadget module load and unload support
> > 
> > Peter Chen (2):
> >   usb: chipidea: imx: refine clock operations to adapt for all platforms
> >   ARM: dts: imx27.dtsi: change the clock information for usb
> > 
> >  arch/arm/boot/dts/imx27.dtsi   |  16 +++--
> >  drivers/usb/chipidea/ci_hdrc_imx.c | 131 
> > -
> >  drivers/usb/chipidea/debug.c   |   2 +
> >  drivers/usb/chipidea/udc.c |  25 ++-
> >  4 files changed, 150 insertions(+), 24 deletions(-)
> 
> It's really late in the -rc cycle, can you send all of these as
> individual patches so I can review them first?
> 

Thanks, will send soon.

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] usb: chipidea: support debugfs without CONFIG_USB_CHIPIDEA_DEBUG

[Peter Chen]

Since we need to mount debugfs to show/store the things we
want to debug, it is duplicated to add another configuration
to enable it. Meanwhile, with CONFIG_USB_CHIPIDEA_DEBUG,
we can't support chipidea debugfs at runtime.

Signed-off-by: Peter Chen 
Cc: Jun Li 
---
 drivers/usb/chipidea/Makefile |  3 +--
 drivers/usb/chipidea/ci.h |  3 +++
 drivers/usb/chipidea/core.c   |  1 -
 drivers/usb/chipidea/debug.c  |  1 -
 drivers/usb/chipidea/debug.h  | 30 --
 drivers/usb/chipidea/udc.c|  1 -
 6 files changed, 4 insertions(+), 35 deletions(-)
 delete mode 100644 drivers/usb/chipidea/debug.h

diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
index 4decb12..c437d5f 100644
--- a/drivers/usb/chipidea/Makefile
+++ b/drivers/usb/chipidea/Makefile
@@ -2,10 +2,9 @@ ccflags-$(CONFIG_USB_CHIPIDEA_DEBUG) := -DDEBUG
 
 obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc.o
 
-ci_hdrc-y  := core.o otg.o
+ci_hdrc-y  := core.o otg.o debug.o
 ci_hdrc-$(CONFIG_USB_CHIPIDEA_UDC) += udc.o
 ci_hdrc-$(CONFIG_USB_CHIPIDEA_HOST)+= host.o
-ci_hdrc-$(CONFIG_USB_CHIPIDEA_DEBUG)   += debug.o
 ci_hdrc-$(CONFIG_USB_OTG_FSM)  += otg_fsm.o
 
 # Glue/Bridge layers go here
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index 41d7cf6..cd41455 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -433,4 +433,7 @@ int hw_wait_reg(struct ci_hdrc *ci, enum ci_hw_regs reg, 
u32 mask,
 
 void ci_platform_configure(struct ci_hdrc *ci);
 
+int dbg_create_files(struct ci_hdrc *ci);
+
+void dbg_remove_files(struct ci_hdrc *ci);
 #endif /* __DRIVERS_USB_CHIPIDEA_CI_H */
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 965d0e2..18e77e0 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -71,7 +71,6 @@
 #include "udc.h"
 #include "bits.h"
 #include "host.h"
-#include "debug.h"
 #include "otg.h"
 #include "otg_fsm.h"
 
diff --git a/drivers/usb/chipidea/debug.c b/drivers/usb/chipidea/debug.c
index 58c8485..a4f7db2 100644
--- a/drivers/usb/chipidea/debug.c
+++ b/drivers/usb/chipidea/debug.c
@@ -15,7 +15,6 @@
 #include "ci.h"
 #include "udc.h"
 #include "bits.h"
-#include "debug.h"
 #include "otg.h"
 
 /**
diff --git a/drivers/usb/chipidea/debug.h b/drivers/usb/chipidea/debug.h
deleted file mode 100644
index e16478c..000
--- a/drivers/usb/chipidea/debug.h
+++ /dev/null
@@ -1,30 +0,0 @@
-/*
- * debug.h - ChipIdea USB driver debug interfaces
- *
- * Copyright (C) 2008 Chipidea - MIPS Technologies, Inc. All rights reserved.
- *
- * Author: David Lopo
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#ifndef __DRIVERS_USB_CHIPIDEA_DEBUG_H
-#define __DRIVERS_USB_CHIPIDEA_DEBUG_H
-
-#ifdef CONFIG_USB_CHIPIDEA_DEBUG
-int dbg_create_files(struct ci_hdrc *ci);
-void dbg_remove_files(struct ci_hdrc *ci);
-#else
-static inline int dbg_create_files(struct ci_hdrc *ci)
-{
-   return 0;
-}
-
-static inline void dbg_remove_files(struct ci_hdrc *ci)
-{
-}
-#endif
-
-#endif /* __DRIVERS_USB_CHIPIDEA_DEBUG_H */
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 67cfa04..acd368f 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -26,7 +26,6 @@
 #include "ci.h"
 #include "udc.h"
 #include "bits.h"
-#include "debug.h"
 #include "otg.h"
 #include "otg_fsm.h"
 
-- 
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 1/1] usb: chipidea: support debugfs without CONFIG_USB_CHIPIDEA_DEBUG

[Greg KH]

On Fri, Oct 23, 2015 at 10:43:46AM +0800, Peter Chen wrote:
> Since we need to mount debugfs to show/store the things we
> want to debug, it is duplicated to add another configuration
> to enable it. Meanwhile, with CONFIG_USB_CHIPIDEA_DEBUG,
> we can't support chipidea debugfs at runtime.

Why not also delete the config option?  Why do you still need it with
dynamic debug these days?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] usb: chipidea: udc: _ep_queue and _hw_queue cleanup

[Greg KH]

On Fri, Oct 23, 2015 at 09:52:50AM +0800, Peter Chen wrote:
> From: "Felipe F. Tonello" 
> 
> Update comments to reflect current state of functions.
> 
> Signed-off-by: Felipe F. Tonello 
> Signed-off-by: Peter Chen 
> ---
>  drivers/usb/chipidea/udc.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)

This isn't a late -rc patch :(
--
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: qcserial: add Sierra Wireless MC74xx/EM74xx

[Johan Hovold]

On Thu, Oct 22, 2015 at 02:24:24PM +0200, Bjørn Mork wrote:
> New device IDs shamelessly lifted from the vendor driver.
> 
> Cc: 
> Signed-off-by: Bjørn Mork 

Acked-by: Johan Hovold 

Greg, can you pick this one directly for 4.4-rc1? Applies cleanly on top
of my latest pull-request.

Thanks,
Johan

> ---
>  drivers/usb/serial/qcserial.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
> index ebcec8cda858..f49d262e926b 100644
> --- a/drivers/usb/serial/qcserial.c
> +++ b/drivers/usb/serial/qcserial.c
> @@ -153,6 +153,8 @@ static const struct usb_device_id id_table[] = {
>   {DEVICE_SWI(0x1199, 0x9056)},   /* Sierra Wireless Modem */
>   {DEVICE_SWI(0x1199, 0x9060)},   /* Sierra Wireless Modem */
>   {DEVICE_SWI(0x1199, 0x9061)},   /* Sierra Wireless Modem */
> + {DEVICE_SWI(0x1199, 0x9070)},   /* Sierra Wireless MC74xx/EM74xx */
> + {DEVICE_SWI(0x1199, 0x9071)},   /* Sierra Wireless MC74xx/EM74xx */
>   {DEVICE_SWI(0x413c, 0x81a2)},   /* Dell Wireless 5806 Gobi(TM) 4G LTE 
> Mobile Broadband Card */
>   {DEVICE_SWI(0x413c, 0x81a3)},   /* Dell Wireless 5570 HSPA+ (42Mbps) 
> Mobile Broadband Card */
>   {DEVICE_SWI(0x413c, 0x81a4)},   /* Dell Wireless 5570e HSPA+ (42Mbps) 
> Mobile Broadband Card */
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] USB: qcserial: add Sierra Wireless MC74xx/EM74xx

[Bjørn Mork]

New device IDs shamelessly lifted from the vendor driver.

Cc: 
Signed-off-by: Bjørn Mork 
---
 drivers/usb/serial/qcserial.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index ebcec8cda858..f49d262e926b 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -153,6 +153,8 @@ static const struct usb_device_id id_table[] = {
{DEVICE_SWI(0x1199, 0x9056)},   /* Sierra Wireless Modem */
{DEVICE_SWI(0x1199, 0x9060)},   /* Sierra Wireless Modem */
{DEVICE_SWI(0x1199, 0x9061)},   /* Sierra Wireless Modem */
+   {DEVICE_SWI(0x1199, 0x9070)},   /* Sierra Wireless MC74xx/EM74xx */
+   {DEVICE_SWI(0x1199, 0x9071)},   /* Sierra Wireless MC74xx/EM74xx */
{DEVICE_SWI(0x413c, 0x81a2)},   /* Dell Wireless 5806 Gobi(TM) 4G LTE 
Mobile Broadband Card */
{DEVICE_SWI(0x413c, 0x81a3)},   /* Dell Wireless 5570 HSPA+ (42Mbps) 
Mobile Broadband Card */
{DEVICE_SWI(0x413c, 0x81a4)},   /* Dell Wireless 5570e HSPA+ (42Mbps) 
Mobile Broadband Card */
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/15] fs: configfs: Add unlocked version of configfs_depend_item()

[Christoph Hellwig]

On Tue, Oct 20, 2015 at 02:32:32PM +0200, Andrzej Pietrasiewicz wrote:
> From: Krzysztof Opasiak 
> 
> This change is necessary for the SCSI target usb gadget composed with
> configfs. In this case configfs will be used for two different purposes:
> to compose a usb gadget and to configure the target part. If an instance
> of tcm function is created in $CONFIGFS_ROOT/usb_gadget//functions
> a tpg can be created in $CONFIGFS_ROOT/target/usb_gadget//, but after
> a tpg is created the tcm function must not be removed until its
> corresponding tpg is gone. While the configfs_depend/undepend_item() are
> meant exactly for creating this kind of dependencies, they are not suitable
> if the other kernel subsystem happens to be another subsystem in configfs,
> so this patch adds unlocked versions meant for configfs callbacks.

configfs_depend_item is a lot of deep magic (which I haven't even tried
to fully understand yet).  Can you explain why your versions is safe
without all that?  Can also please document the precoditions required
for the function in comments, or wherever possible asserts?

Also needs a kerneldoc comment explaining the exact semantics.

> +void configfs_undepend_item_unlocked(struct config_item *target)
> +{
> + configfs_undepend_item(NULL, target);
> +}
> +EXPORT_SYMBOL(configfs_undepend_item_unlocked);

And given that configfs_undepend_item ignores the subsys argument this
wrapper clearl isn't needed.  Just send a separate patch to drop the
subsys argument to configfs_undepend_item instead.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: gadget: Add the console support for usb-to-serial port

[Baolin Wang]

It dose not work when we want to use the usb-to-serial port based
on one usb gadget as a console. Thus this patch adds the console
initialization to support this request.

Signed-off-by: Baolin Wang 
---
 drivers/usb/gadget/Kconfig |6 +
 drivers/usb/gadget/function/u_serial.c |  239 
 2 files changed, 245 insertions(+)

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 33834aa..be5aab9 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -127,6 +127,12 @@ config USB_GADGET_STORAGE_NUM_BUFFERS
   a module parameter as well.
   If unsure, say 2.
 
+config U_SERIAL_CONSOLE
+   bool "Serial gadget console support"
+   depends on USB_G_SERIAL
+   help
+  It supports the serial gadget can be used as a console.
+
 source "drivers/usb/gadget/udc/Kconfig"
 
 #
diff --git a/drivers/usb/gadget/function/u_serial.c 
b/drivers/usb/gadget/function/u_serial.c
index 9cc6a13..343d530 100644
--- a/drivers/usb/gadget/function/u_serial.c
+++ b/drivers/usb/gadget/function/u_serial.c
@@ -27,6 +27,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "u_serial.h"
 
@@ -79,6 +81,16 @@
  */
 #define QUEUE_SIZE 16
 #define WRITE_BUF_SIZE 8192/* TX only */
+#define GS_BUFFER_SIZE (4096)
+#define GS_CONSOLE_BUF_SIZE(2 * GS_BUFFER_SIZE)
+
+struct gscons_info {
+   struct gs_port  *port;
+   struct tty_driver   *tty_driver;
+   struct work_struct  work;
+   int buf_tail;
+   charbuf[GS_CONSOLE_BUF_SIZE];
+};
 
 /* circular buffer */
 struct gs_buf {
@@ -117,6 +129,7 @@ struct gs_port {
 
/* REVISIT this state ... */
struct usb_cdc_line_coding port_line_coding;/* 8-N-1 etc */
+   struct usb_request  *console_req;
 };
 
 static struct portmaster {
@@ -1052,6 +1065,7 @@ gs_port_alloc(unsigned port_num, struct 
usb_cdc_line_coding *coding)
 
port->port_num = port_num;
port->port_line_coding = *coding;
+   port->console_req = NULL;
 
ports[port_num].port = port;
 out:
@@ -1141,6 +1155,227 @@ err:
 }
 EXPORT_SYMBOL_GPL(gserial_alloc_line);
 
+#ifdef CONFIG_U_SERIAL_CONSOLE
+
+static struct usb_request *gs_request_new(struct usb_ep *ep, int buffer_size)
+{
+   struct usb_request *req = usb_ep_alloc_request(ep, GFP_ATOMIC);
+
+   if (!req)
+   return NULL;
+
+   /* now allocate buffers for the requests */
+   req->buf = kmalloc(buffer_size, GFP_ATOMIC);
+   if (!req->buf) {
+   usb_ep_free_request(ep, req);
+   return NULL;
+   }
+
+   return req;
+}
+
+static void gs_request_free(struct usb_request *req, struct usb_ep *ep)
+{
+   if (req) {
+   kfree(req->buf);
+   usb_ep_free_request(ep, req);
+   }
+}
+
+static void gs_complete_out(struct usb_ep *ep, struct usb_request *req)
+{
+   if (req->status != 0 && req->status != -ECONNRESET)
+   return;
+}
+
+static struct console gserial_cons;
+static int gs_console_connect(void)
+{
+   struct gscons_info *info = gserial_cons.data;
+   int port_num = gserial_cons.index;
+   struct usb_request *req;
+   struct gs_port *port;
+   struct usb_ep *ep;
+
+   if (port_num >= MAX_U_SERIAL_PORTS || port_num < 0) {
+   pr_err("%s: port num [%d] exceeds the range.\n",
+  __func__, port_num);
+   return -ENXIO;
+   }
+
+   port = ports[port_num].port;
+   if (!port) {
+   pr_err("%s: serial line [%d] not allocated.\n",
+  __func__, port_num);
+   return -ENODEV;
+   }
+
+   if (!port->port_usb) {
+   pr_err("%s: no port usb.\n", __func__);
+   return -ENODEV;
+   }
+
+   ep = port->port_usb->in;
+   if (!ep) {
+   pr_err("%s: no usb endpoint.\n", __func__);
+   return -ENXIO;
+   }
+
+   req = port->console_req;
+   if (!req) {
+   req = gs_request_new(ep, GS_BUFFER_SIZE);
+   if (!req) {
+   pr_err("%s: request fail.\n", __func__);
+   return -ENOMEM;
+   }
+   req->complete = gs_complete_out;
+   }
+
+   info->port = port;
+
+   pr_debug("%s: port[%d] console connect!\n", __func__, port_num);
+   return 0;
+}
+
+static void gs_console_work(struct work_struct *work)
+{
+   struct gscons_info *info = container_of(work, struct gscons_info, work);
+   struct gs_port *port = info->port;
+   struct usb_request *req;
+   struct usb_ep *ep;
+   int xfer, ret, count;
+   char *p;
+
+   if (!port || !port->port_usb)
+   return;
+
+   req = port->console_req;
+   ep = port->port_usb->in;
+   if (!req || !ep)
+

Re: [PATCH 07/21] usb/gadget: Remove set-but-not-used variables

[Christoph Hellwig]

On Thu, Oct 22, 2015 at 03:55:45PM -0700, Bart Van Assche wrote:
> Avoid that building with W=1 triggers compiler warnings about
> set-but-not-used variables.

Looks good,

Reviewed-by: Christoph Hellwig 
--
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] extcon: add MAX3355 driver

[Chanwoo Choi]

On 2015년 10월 21일 03:20, Sergei Shtylyov wrote:
> Hello.
> 
> On 12/18/2014 12:58 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
>>
>> Would be Maxim enough? Or perhaps I should use Maxim Integrated 
>> [Products]?
> 
>You haven't replied to my questions.
> 
 +
 +
 +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 = < 4 GPIO_ACTIVE_LOW>;
 +maxim,id-gpio = < 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 = < 4 GPIO_ACTIVE_LOW>, < 31 GPIO_ACTIVE_HIGH>;
>>
>> OK, though Documentation/devicetree/bindings/gpio/gpio.txt does not seem
>> to insist on using this one...
> 
>Moreover, it now says "gpios" isn't allowed for the new bindings. So I 
> have to strongly disagree here...

OK. But, I recommend you use the 'gpiod' with devm_gpiod_get
instead of using devm_gpio_request_one() directly as following:
You can refer drivers/extcon/extcon-usb-gpio.c about using gpiod.

For example,
data->shdn_gpiod = devm_gpiod_get(dev, "maxim,shdn", GPIOD_IN);
data->id_gpiod = devm_gpiod_get(dev, "maxim,id", GPIOD_IN);

> 
> [...]
> 
 +static irqreturn_t max3355_id_irq(int irq, void *dev_id)
 +{
 +struct max3355_data *data = dev_id;
 +int id = gpio_get_value(data->id_gpio);
 +
 +extcon_set_cable_state(data->edev, "USB-HOST", !id);
>>
>>> You have to get the gpio flag in the devicetree by using of_get_gpio_flags()
>>> function
>>> and then you would set the cable state according to gpio state and flag.
>>
>> I'm sorry but I just don't see why I have to do it. This is not a generic
>> GPIO driver, and the polarities of the GPIOs are determined solely by the
>> MAX3355 specs.
> 
>Again, got not reply...

OK. you don't need to consider the gpio flag from devicetree.

> 
>> [...]
 +static int max3355_probe(struct platform_device *pdev)
 +{
 +struct device_node *np = pdev->dev.of_node;
 +struct max3355_data *data;
 +int gpio, irq, ret;
 +
 +data = devm_kzalloc(>dev, sizeof(struct max3355_data),
 +GFP_KERNEL);
 +if (!data)
 +return -ENOMEM;
 +
 +data->edev = devm_extcon_dev_allocate(>dev, max3355_cable);
 +if (IS_ERR(data->edev)) {
 +dev_err(>dev, "failed to allocate extcon device\n");
 +  

[PATCHv2 10/15] usb: gadget: f_tcm: convert to new function interface with backward compatibility

[Andrzej Pietrasiewicz]

Converting tcm to the new function interface requires converting
USB tcm's function code and its users.

This patch converts the f_tcm.c to the new function interface.

The file can be now compiled into a separate module usb_f_tcm.ko.

The old function interface is provided by means of preprocessor conditional
directives. After all users are converted, the old interface can be
removed.

Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/usb/gadget/Kconfig |   3 +
 drivers/usb/gadget/function/Makefile   |   2 +
 drivers/usb/gadget/function/f_tcm.c| 287 -
 drivers/usb/gadget/function/tcm.h  |   2 +
 drivers/usb/gadget/function/u_tcm.h|  50 +
 drivers/usb/gadget/legacy/tcm_usb_gadget.c |   1 +
 6 files changed, 340 insertions(+), 5 deletions(-)
 create mode 100644 drivers/usb/gadget/function/u_tcm.h

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index bcf83c0..1e97d8e 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -199,6 +199,9 @@ config USB_F_HID
 config USB_F_PRINTER
tristate
 
+config USB_F_TCM
+   tristate
+
 choice
tristate "USB Gadget Drivers"
default USB_ETH
diff --git a/drivers/usb/gadget/function/Makefile 
b/drivers/usb/gadget/function/Makefile
index bd7def5..cb8c225 100644
--- a/drivers/usb/gadget/function/Makefile
+++ b/drivers/usb/gadget/function/Makefile
@@ -44,3 +44,5 @@ usb_f_hid-y   := f_hid.o
 obj-$(CONFIG_USB_F_HID)+= usb_f_hid.o
 usb_f_printer-y:= f_printer.o
 obj-$(CONFIG_USB_F_PRINTER)+= usb_f_printer.o
+usb_f_tcm-y:= f_tcm.o
+obj-$(CONFIG_USB_F_TCM)+= usb_f_tcm.o
diff --git a/drivers/usb/gadget/function/f_tcm.c 
b/drivers/usb/gadget/function/f_tcm.c
index d1b602a..910f9a7 100644
--- a/drivers/usb/gadget/function/f_tcm.c
+++ b/drivers/usb/gadget/function/f_tcm.c
@@ -22,6 +22,21 @@
 #include 
 
 #include "tcm.h"
+#include "u_tcm.h"
+
+#ifndef USBF_TCM_INCLUDED
+
+#define TPG_INSTANCES  1
+
+struct tpg_instance {
+   struct usb_function_instance*func_inst;
+   struct usbg_tpg *tpg;
+};
+
+static struct tpg_instance tpg_instances[TPG_INSTANCES];
+
+static DEFINE_MUTEX(tpg_instances_lock);
+#endif
 
 static inline struct f_uas *to_f_uas(struct usb_function *f)
 {
@@ -1377,6 +1392,10 @@ static struct se_portal_group *usbg_make_tpg(
struct usbg_tpg *tpg;
unsigned long tpgt;
int ret;
+#ifndef USBF_TCM_INCLUDED
+   struct f_tcm_opts *opts;
+   unsigned i;
+#endif
 
if (strstr(name, "tpgt_") != name)
return ERR_PTR(-EINVAL);
@@ -1387,14 +1406,40 @@ static struct se_portal_group *usbg_make_tpg(
pr_err("gadgets, you can't do this here.\n");
return ERR_PTR(-EBUSY);
}
+#ifndef USBF_TCM_INCLUDED
+   ret = -ENODEV;
+   mutex_lock(_instances_lock);
+   for (i = 0; i < TPG_INSTANCES; ++i)
+   if (tpg_instances[i].func_inst && !tpg_instances[i].tpg)
+   break;
+   if (i == TPG_INSTANCES)
+   goto unlock_inst;
+
+   opts = container_of(tpg_instances[i].func_inst, struct f_tcm_opts,
+   func_inst);
+   mutex_lock(>dep_lock);
+   if (!opts->ready)
+   goto unlock_dep;
+
+   if (opts->has_dep && !try_module_get(opts->dependent))
+   goto unlock_dep;
+#endif
 
tpg = kzalloc(sizeof(struct usbg_tpg), GFP_KERNEL);
+   ret = -ENOMEM;
if (!tpg)
+#ifdef USBF_TCM_INCLUDED
return ERR_PTR(-ENOMEM);
+#else
+   goto unref_dep;
+#endif
mutex_init(>tpg_mutex);
atomic_set(>tpg_port_count, 0);
tpg->workqueue = alloc_workqueue("tcm_usb_gadget", 0, 1);
if (!tpg->workqueue) {
+#ifndef USBF_TCM_INCLUDED
+   goto free_tpg;
+#endif
kfree(tpg);
return NULL;
}
@@ -1408,12 +1453,35 @@ static struct se_portal_group *usbg_make_tpg(
 */
ret = core_tpg_register(wwn, >se_tpg, SCSI_PROTOCOL_SAS);
if (ret < 0) {
+#ifndef USBF_TCM_INCLUDED
+   goto free_workqueue;
+#endif
destroy_workqueue(tpg->workqueue);
kfree(tpg);
return NULL;
}
+#ifndef USBF_TCM_INCLUDED
+   tpg_instances[i].tpg = tpg;
+   tpg->fi = tpg_instances[i].func_inst;
+   mutex_unlock(>dep_lock);
+   mutex_unlock(_instances_lock);
+#endif
the_only_tpg_I_currently_have = tpg;
return >se_tpg;
+#ifndef USBF_TCM_INCLUDED
+free_workqueue:
+   destroy_workqueue(tpg->workqueue);
+free_tpg:
+   kfree(tpg);
+unref_dep:
+   module_put(opts->dependent);
+unlock_dep:
+   mutex_unlock(>dep_lock);
+unlock_inst:
+   mutex_unlock(_instances_lock);
+
+   return ERR_PTR(ret);
+#endif
 }
 
 static int 

[PATCHv2 14/15] usb: gadget: f_tcm: use usb_gstrings_attach

[Andrzej Pietrasiewicz]

Do not directly use file static strings definitions in instances of f_tcm.
Instead use usb_gstrings_attach.

Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/usb/gadget/function/f_tcm.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/gadget/function/f_tcm.c 
b/drivers/usb/gadget/function/f_tcm.c
index 40c6563..96bae2c 100644
--- a/drivers/usb/gadget/function/f_tcm.c
+++ b/drivers/usb/gadget/function/f_tcm.c
@@ -2043,6 +2043,7 @@ static void give_back_ep(struct usb_ep **pep)
 static int tcm_bind(struct usb_configuration *c, struct usb_function *f)
 {
struct f_uas*fu = to_f_uas(f);
+   struct usb_string   *us;
struct usb_gadget   *gadget = c->cdev->gadget;
struct usb_ep   *ep;
struct f_tcm_opts   *opts;
@@ -2057,16 +2058,12 @@ static int tcm_bind(struct usb_configuration *c, struct 
usb_function *f)
return -ENODEV;
}
mutex_unlock(>dep_lock);
-
-   if (tcm_us_strings[0].id == 0) {
-   ret = usb_string_ids_tab(c->cdev, tcm_us_strings);
-   if (ret < 0)
-   return ret;
-
-   bot_intf_desc.iInterface = tcm_us_strings[USB_G_STR_INT_BBB].id;
-   uasp_intf_desc.iInterface =
-   tcm_us_strings[USB_G_STR_INT_UAS].id;
-   }
+   us = usb_gstrings_attach(c->cdev, tcm_strings,
+   ARRAY_SIZE(tcm_us_strings));
+   if (IS_ERR(us))
+   return PTR_ERR(us);
+   bot_intf_desc.iInterface = us[USB_G_STR_INT_BBB].id;
+   uasp_intf_desc.iInterface = us[USB_G_STR_INT_UAS].id;
 
iface = usb_interface_id(c, f);
if (iface < 0)
@@ -2324,7 +2321,6 @@ static struct usb_function *tcm_alloc(struct 
usb_function_instance *fi)
fu->function.set_alt = tcm_set_alt;
fu->function.setup = tcm_setup;
fu->function.disable = tcm_disable;
-   fu->function.strings = tcm_strings;
fu->function.free_func = tcm_free;
fu->tpg = tpg_instances[i].tpg;
mutex_unlock(_instances_lock);
-- 
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

[PATCHv2 15/15] usb: gadget: f_tcm: add configfs support

[Andrzej Pietrasiewicz]

Allow using the tcm function as a component of a gadget composed with
ConfigFS.

Signed-off-by: Andrzej Pietrasiewicz 
[adapt to new prototype of configfs_(un)depend_item())]
Signed-off-by: Krzysztof Opasiak 
---
 Documentation/ABI/testing/configfs-usb-gadget-tcm |  6 ++
 drivers/usb/gadget/Kconfig| 14 +
 drivers/usb/gadget/function/f_tcm.c   | 76 +--
 3 files changed, 92 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/ABI/testing/configfs-usb-gadget-tcm

diff --git a/Documentation/ABI/testing/configfs-usb-gadget-tcm 
b/Documentation/ABI/testing/configfs-usb-gadget-tcm
new file mode 100644
index 000..a29ed2d
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-usb-gadget-tcm
@@ -0,0 +1,6 @@
+What:  /config/usb-gadget/gadget/functions/tcm.name
+Date:  Dec 2015
+KernelVersion: 4.5
+Description:
+   There are no attributes because all the configuration
+   is performed in the "target" subsystem of configfs.
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 1e97d8e..81bf660 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -454,6 +454,20 @@ config USB_CONFIGFS_F_PRINTER
  For more information, see Documentation/usb/gadget_printer.txt
  which includes sample code for accessing the device file.
 
+config USB_CONFIGFS_F_TCM
+   bool "USB Gadget Target Fabric"
+   depends on TARGET_CORE
+   depends on USB_CONFIGFS
+   select USB_LIBCOMPOSITE
+   select USB_F_TCM
+   help
+ This fabric is a USB gadget component. Two USB protocols are
+ supported that is BBB or BOT (Bulk Only Transport) and UAS
+ (USB Attached SCSI). BOT is advertised on alternative
+ interface 0 (primary) and UAS is on alternative interface 1.
+ Both protocols can work on USB2.0 and USB3.0.
+ UAS utilizes the USB 3.0 feature called streams support.
+
 source "drivers/usb/gadget/legacy/Kconfig"
 
 endchoice
diff --git a/drivers/usb/gadget/function/f_tcm.c 
b/drivers/usb/gadget/function/f_tcm.c
index 96bae2c..f2df812 100644
--- a/drivers/usb/gadget/function/f_tcm.c
+++ b/drivers/usb/gadget/function/f_tcm.c
@@ -23,6 +23,7 @@
 
 #include "tcm.h"
 #include "u_tcm.h"
+#include "configfs.h"
 
 #define TPG_INSTANCES  1
 
@@ -1408,8 +1409,16 @@ static struct se_portal_group *usbg_make_tpg(
if (!opts->ready)
goto unlock_dep;
 
-   if (opts->has_dep && !try_module_get(opts->dependent))
-   goto unlock_dep;
+   if (opts->has_dep) {
+   if (!try_module_get(opts->dependent))
+   goto unlock_dep;
+   } else {
+   ret = configfs_depend_item_unlocked(
+   group->cg_subsys,
+   >func_inst.group.cg_item);
+   if (ret)
+   goto unlock_dep;
+   }
 
tpg = kzalloc(sizeof(struct usbg_tpg), GFP_KERNEL);
ret = -ENOMEM;
@@ -1443,7 +1452,12 @@ free_workqueue:
 free_tpg:
kfree(tpg);
 unref_dep:
-   module_put(opts->dependent);
+   if (opts->has_dep)
+   module_put(opts->dependent);
+   else
+   configfs_undepend_item_unlocked(
+   group->cg_subsys,
+   >func_inst.group.cg_item);
 unlock_dep:
mutex_unlock(>dep_lock);
 unlock_inst:
@@ -1474,7 +1488,12 @@ static void usbg_drop_tpg(struct se_portal_group *se_tpg)
opts = container_of(tpg_instances[i].func_inst,
struct f_tcm_opts, func_inst);
mutex_lock(>dep_lock);
-   module_put(opts->dependent);
+   if (opts->has_dep)
+   module_put(opts->dependent);
+   else
+   configfs_undepend_item_unlocked(
+   se_tpg->tpg_group.cg_subsys,
+   >func_inst.group.cg_item);
mutex_unlock(>dep_lock);
mutex_unlock(_instances_lock);
 
@@ -2198,6 +2217,28 @@ static int tcm_setup(struct usb_function *f,
return usbg_bot_setup(f, ctrl);
 }
 
+static inline struct f_tcm_opts *to_f_tcm_opts(struct config_item *item)
+{
+   return container_of(to_config_group(item), struct f_tcm_opts,
+   func_inst.group);
+}
+
+static void tcm_attr_release(struct config_item *item)
+{
+   struct f_tcm_opts *opts = to_f_tcm_opts(item);
+
+   usb_put_function_instance(>func_inst);
+}
+
+static struct configfs_item_operations tcm_item_ops = {
+   .release= tcm_attr_release,
+};
+
+static struct config_item_type tcm_func_type = {
+   .ct_item_ops= _item_ops,
+   .ct_owner   = THIS_MODULE,
+};
+
 static void tcm_free_inst(struct usb_function_instance *f)
 {
struct f_tcm_opts *opts;
@@ -2216,6 +2257,28 @@ static void tcm_free_inst(struct usb_function_instance 
*f)
kfree(opts);
 }
 
+static int 

[PATCHv2 00/15] Equivalent of tcm_usb_gadget with configfs

[Andrzej Pietrasiewicz]

Dear All,

This series adds support to tcm usb gadget for composing it with configfs.

@target-devel folks: You might be wondering why add configfs for something
which already supports configfs. In tcm_usb_gadget configfs has beeen
used for configuring the SCSI target part, but the usb gadget part
is considered a legacy gadget. A legacy gadget is a composite usb gadget
whose composition is defined statically at compilation time.
Composite gadgets can consist of a number of "functions" and configurations.
In legacy gadgets the selection is hardcoded in a dedicated kernel
module. But with configfs the selection can be made at runtime without
writing any kernel code. The conversion process started almost three
years ago.

The series aims at integrating configfs into tcm, the way it has been
done with 19 of 20 usb functions. In other words this concludes the
process of conversion to configfs in usb gadgets.

The series depends on the series from Chrisoph:
http://www.spinics.net/lists/target-devel/msg10730.html

@Nicholas: In order to use the series from Christoph (simplifying
configfs attributes) I rebased my series on top of your for-next,
which happens not to contain your patches which strip off nexus
WWPN prefix, fix nexus leak and fix enabled attribute failure.
I re-post them here. I have split one of them to separate
unrelated changes.

@Joel: I resend the patch which adds unlocked versions of
configfs_(un)depend_item(). The purpose of configfs_(un)depend_item()
is to allow other kernel subsystems to prohibit deletion of a config
item until they can live without it. This is exactly the case with
tcm usb gadget, but the other kernel subsystem happens to be another
subsystem in configfs: the user must create an instance of the tcm
function in usb_gadget subsystem in order to be able to create
a tpg in target subsystem. But once a tpg goes live its corresponding
tcm function must not be removed until the tpg is deleted.
Even though these are two distinct configfs subsystems the
configfs_(un)depend_item() will not work from a configfs callback.
That is why there is a need to provide the "unlocked" variant.

v1..v2:
- added missing comments
- used the next version of configfs_(un)depend_item_unlocked()
- fixed bug: THIS_MODULE is NULL if a module is compiled-in, so we cannot
rely on opts->dependent being non-NULL if a dependent module is present
- added passing configfs subsystem to configfs_(un)depend_item_unlocked()

BACKWARD COMPATIBILITY
==

Please note that the old tcm_usb_gadget.ko is still available and works.

USING THE NEW "GADGET"
==

Please refer to this post:

http://www.spinics.net/lists/linux-usb/msg76388.html

for general information from Sebastian on how to use configfs-based
gadgets (*).

With configfs the procedure is as follows, compared to the information
mentioned above (*):

instead of mkdir functions/acm.ttyS1 do

mkdir functions/tcm.

e.g. mkdir functions/tcm.usb0.

In the tcm.usb0 directory there are no attributes, because all the
configuration is performed with the target subsystem in configfs.

Below is a script which creates a tcm gadget on a board with dwc3:

# mount -t configfs none /sys/kernel/config
# modprobe usb_f_tcm
# cd /sys/kernel/config/usb_gadget
# mkdir tcm
# cd tcm
# mkdir functions/tcm.0
# cd /sys/kernel/config/target/
# mkdir usb_gadget
# cd usb_gadget
# mkdir naa.0123456789abcdef
# cd naa.0123456789abcdef
# mkdir tpgt_1
# cd tpgt_1
# echo naa.01234567890abcdef > nexus
# echo 1 > enable
# cd /sys/kernel/config/usb_gadget/tcm
# mkdir configs/c.1
# ln -s functions/tcm.0 configs/c.1
# echo $VENDOR_ID > idVendor
# echo $PRODUCT_ID > idProduct
# echo 1240.dwc3 > UDC

TESTING THE FUNCTION


The most basic testing

device: run the script above

host: see the gadget enumerated

Andrzej Pietrasiewicz (11):
  usb: gadget: tcm: split string definitions into function and device
  usb: gadget: tcm: follow naming conventions
  usb: gadget: tcm: use strtobool for a boolean value
  usb: gadget: tcm: simplify attribute store function
  usb: gadget: tcm: factor out f_tcm
  usb: gadget: f_tcm: convert to new function interface with backward
compatibility
  usb: gadget: tcm: convert to use new function registration interface
  usb: gadget: f_tcm: remove compatibility layer
  usb: gadget: f_tcm: remove redundant singleton
  usb: gadget: f_tcm: use usb_gstrings_attach
  usb: gadget: f_tcm: add configfs support

Krzysztof Opasiak (1):
  fs: configfs: Add unlocked version of configfs_depend_item()

Nicholas Bellinger (3):
  tcm_usb_gadget: Don't strip off nexus WWPN prefix
  tcm_usb_gadget: Fix nexus leak
  tcm_usb_gadget: Fix enabled attribute failure

 Documentation/ABI/testing/configfs-usb-gadget-tcm |6 +
 drivers/usb/gadget/Kconfig|   17 +
 drivers/usb/gadget/function/Makefile  |2 +
 drivers/usb/gadget/function/f_tcm.c   | 2425 +
 

[PATCHv2 06/15] usb: gadget: tcm: follow naming conventions

[Andrzej Pietrasiewicz]

Prepare for splitting tcm_usb_gadget into legacy gadget proper and f_tcm.

Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/usb/gadget/legacy/tcm_usb_gadget.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/gadget/legacy/tcm_usb_gadget.c 
b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
index 556decf..a60ef8f 100644
--- a/drivers/usb/gadget/legacy/tcm_usb_gadget.c
+++ b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
@@ -2045,7 +2045,7 @@ static void give_back_ep(struct usb_ep **pep)
ep->driver_data = NULL;
 }
 
-static int usbg_bind(struct usb_configuration *c, struct usb_function *f)
+static int tcm_bind(struct usb_configuration *c, struct usb_function *f)
 {
struct f_uas*fu = to_f_uas(f);
struct usb_gadget   *gadget = c->cdev->gadget;
@@ -2118,7 +2118,7 @@ ep_fail:
return -ENOTSUPP;
 }
 
-static void usbg_unbind(struct usb_configuration *c, struct usb_function *f)
+static void tcm_unbind(struct usb_configuration *c, struct usb_function *f)
 {
struct f_uas *fu = to_f_uas(f);
 
@@ -2132,7 +2132,7 @@ struct guas_setup_wq {
unsigned int alt;
 };
 
-static void usbg_delayed_set_alt(struct work_struct *wq)
+static void tcm_delayed_set_alt(struct work_struct *wq)
 {
struct guas_setup_wq *work = container_of(wq, struct guas_setup_wq,
work);
@@ -2153,7 +2153,7 @@ static void usbg_delayed_set_alt(struct work_struct *wq)
usb_composite_setup_continue(fu->function.config->cdev);
 }
 
-static int usbg_set_alt(struct usb_function *f, unsigned intf, unsigned alt)
+static int tcm_set_alt(struct usb_function *f, unsigned intf, unsigned alt)
 {
struct f_uas *fu = to_f_uas(f);
 
@@ -2163,7 +2163,7 @@ static int usbg_set_alt(struct usb_function *f, unsigned 
intf, unsigned alt)
work = kmalloc(sizeof(*work), GFP_ATOMIC);
if (!work)
return -ENOMEM;
-   INIT_WORK(>work, usbg_delayed_set_alt);
+   INIT_WORK(>work, tcm_delayed_set_alt);
work->fu = fu;
work->alt = alt;
schedule_work(>work);
@@ -2172,7 +2172,7 @@ static int usbg_set_alt(struct usb_function *f, unsigned 
intf, unsigned alt)
return -EOPNOTSUPP;
 }
 
-static void usbg_disable(struct usb_function *f)
+static void tcm_disable(struct usb_function *f)
 {
struct f_uas *fu = to_f_uas(f);
 
@@ -2183,7 +2183,7 @@ static void usbg_disable(struct usb_function *f)
fu->flags = 0;
 }
 
-static int usbg_setup(struct usb_function *f,
+static int tcm_setup(struct usb_function *f,
const struct usb_ctrlrequest *ctrl)
 {
struct f_uas *fu = to_f_uas(f);
@@ -2194,7 +2194,7 @@ static int usbg_setup(struct usb_function *f,
return usbg_bot_setup(f, ctrl);
 }
 
-static int usbg_cfg_bind(struct usb_configuration *c)
+static int tcm_bind_config(struct usb_configuration *c)
 {
struct f_uas *fu;
int ret;
@@ -2203,11 +2203,11 @@ static int usbg_cfg_bind(struct usb_configuration *c)
if (!fu)
return -ENOMEM;
fu->function.name = "Target Function";
-   fu->function.bind = usbg_bind;
-   fu->function.unbind = usbg_unbind;
-   fu->function.set_alt = usbg_set_alt;
-   fu->function.setup = usbg_setup;
-   fu->function.disable = usbg_disable;
+   fu->function.bind = tcm_bind;
+   fu->function.unbind = tcm_unbind;
+   fu->function.set_alt = tcm_set_alt;
+   fu->function.setup = tcm_setup;
+   fu->function.disable = tcm_disable;
fu->function.strings = tcm_strings;
fu->tpg = the_only_tpg_I_currently_have;
 
@@ -2241,7 +2241,7 @@ static int usb_target_bind(struct usb_composite_dev *cdev)
usbg_us_strings[USB_G_STR_CONFIG].id;
 
ret = usb_add_config(cdev, _config_driver,
-   usbg_cfg_bind);
+   tcm_bind_config);
if (ret)
return ret;
usb_composite_overwrite_options(cdev, );
-- 
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: [PATCHv2 01/15] fs: configfs: Add unlocked version of configfs_depend_item()

[Christoph Hellwig]

Hi Andrzej,

please find a way to share code between the two depend function.  And
also drop the duplicate undepend version and just stop passing the
unused subsystem argument.  Not only do we not keep unused argument in
Linux in general, but in this case it's also really useful for the new
API.
--
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: [GIT PULL] On-demand device probing

[Russell King - ARM Linux]

On Thu, Oct 22, 2015 at 07:44:05AM -0700, Greg Kroah-Hartman wrote:
> 
> 
> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> > Given that downstreams are already carrying as many hacks as they
> > could think of to speed total boot up, I think this is effectively
> > telling them to go away.
> 
> No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to
> solve-the-random-issue-i'm-having type patch by putting random calls in
> semi-random subsystems all over the kernel.

+1000, fully agree.

There's too much verbal diarrhoea going on in this thread and no facts.
I've been waiting for real data too, and there's not one shred of it, or
even a hint that it might appear.  So, the conclusion I'm coming to is
that there isn't any data to back up the claims made in this thread.

If it was such a problem, then in the _eight_ days that this has been
discussed so far, _someone_ would have sent some data showing the
problem.  I think the fact is, there is no data.

Someone prove me wrong.  Someone post the verifiable data showing that
there is a problem to be solved here.

Someone show what the specific failure cases are that are hampering
vendors moving forwards.  Someone show the long boot times by way of
kernel message log.  Someone show some evidence of the problems that
have been alluded to.

If no one can show some evidence, there isn't a problem here. :)

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 07/15] usb: gadget: tcm: use strtobool for a boolean value

[Andrzej Pietrasiewicz]

Simplify the function.

Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/usb/gadget/legacy/tcm_usb_gadget.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/gadget/legacy/tcm_usb_gadget.c 
b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
index a60ef8f..62b1217 100644
--- a/drivers/usb/gadget/legacy/tcm_usb_gadget.c
+++ b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
@@ -1496,14 +1496,12 @@ static ssize_t tcm_usbg_tpg_enable_store(struct 
config_item *item,
 {
struct se_portal_group *se_tpg = to_tpg(item);
struct usbg_tpg  *tpg = container_of(se_tpg, struct usbg_tpg, se_tpg);
-   unsigned long op;
+   bool op;
ssize_t ret;
 
-   ret = kstrtoul(page, 0, );
-   if (ret < 0)
-   return -EINVAL;
-   if (op > 1)
-   return -EINVAL;
+   ret = strtobool(page, );
+   if (ret)
+   return ret;
 
if (op && tpg->gadget_connect) {
ret = -EINVAL;
-- 
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

[PATCHv2 08/15] usb: gadget: tcm: simplify attribute store function

[Andrzej Pietrasiewicz]

Simplify function code.

Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/usb/gadget/legacy/tcm_usb_gadget.c | 22 +++---
 1 file changed, 7 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/gadget/legacy/tcm_usb_gadget.c 
b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
index 62b1217..522acaf 100644
--- a/drivers/usb/gadget/legacy/tcm_usb_gadget.c
+++ b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
@@ -1503,27 +1503,19 @@ static ssize_t tcm_usbg_tpg_enable_store(struct 
config_item *item,
if (ret)
return ret;
 
-   if (op && tpg->gadget_connect) {
-   ret = -EINVAL;
-   goto out;
-   }
-   if (!op && !tpg->gadget_connect) {
-   ret = -EINVAL;
-   goto out;
-   }
+   if ((op && tpg->gadget_connect) || (!op && !tpg->gadget_connect))
+   return -EINVAL;
 
-   if (op) {
+   if (op)
ret = usbg_attach(tpg);
-   if (ret)
-   goto out;
-   } else {
+   else
usbg_detach(tpg);
-   }
+   if (ret)
+   return ret;
+
tpg->gadget_connect = op;
 
return count;
-out:
-   return ret;
 }
 
 static ssize_t tcm_usbg_tpg_nexus_show(struct config_item *item, char *page)
-- 
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

[PATCHv2 01/15] fs: configfs: Add unlocked version of configfs_depend_item()

[Andrzej Pietrasiewicz]

From: Krzysztof Opasiak 

This change is necessary for the SCSI target usb gadget composed with
configfs. In this case configfs will be used for two different purposes:
to compose a usb gadget and to configure the target part. If an instance
of tcm function is created in $CONFIGFS_ROOT/usb_gadget//functions
a tpg can be created in $CONFIGFS_ROOT/target/usb_gadget//, but after
a tpg is created the tcm function must not be removed until its
corresponding tpg is gone. While the configfs_depend/undepend_item() are
meant exactly for creating this kind of dependencies, they are not suitable
if the other kernel subsystem happens to be another subsystem in configfs,
so this patch adds unlocked versions meant for configfs callbacks.

In configfs_depend_item() we have to consider two possible cases:

1) When we are called to depend another item in the same subsystem as
caller: In this case we should skip locking configfs root as we know that
configfs is in valid state and our subsystem will not be unregistered
during this call.

2) When we are called to depend item in different subsystem than our caller
In this case we are also sure that configfs is in valid state but   we have
to lock root of configfs to avoid unregistration of target's subsystem.
As it is other than caller's subsystem, there may be nothing what protects
us against unregistration of that subsystem.

Signed-off-by: Krzysztof Opasiak 
Signed-off-by: Andrzej Pietrasiewicz 
---
 fs/configfs/dir.c| 97 
 include/linux/configfs.h | 12 ++
 2 files changed, 109 insertions(+)

diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c
index c81ce7f..2578ac0 100644
--- a/fs/configfs/dir.c
+++ b/fs/configfs/dir.c
@@ -1152,6 +1152,103 @@ void configfs_undepend_item(struct configfs_subsystem 
*subsys,
 }
 EXPORT_SYMBOL(configfs_undepend_item);
 
+/*
+ * caller_subsys is a caller's subsystem not target's. This is used to
+ * determine if we should lock root and check subsys or not. When we are
+ * in the same subsystem as our target there is no need to do locking as
+ * we know that subsys is valid and is not unregistered during this function
+ * as we are called from callback of one of his children and VFS holds a lock
+ * on some inode. Otherwise we have to lock our root to  ensure that target's
+ * subsystem it is not unregistered during this function.
+ */
+int configfs_depend_item_unlocked(struct configfs_subsystem *caller_subsys,
+ struct config_item *target)
+{
+   struct configfs_subsystem *target_subsys;
+   struct config_group *root, *parent;
+   struct configfs_dirent *sd, *subsys_sd = NULL;
+   int ret = -ENOENT;
+
+   /* Disallow this function for configfs root */
+   if (configfs_is_root(target))
+   return -EINVAL;
+
+   parent = target->ci_group;
+   /*
+* This may happen when someone is trying to depend root
+* directory of some subsystem
+*/
+   if (configfs_is_root(>cg_item)) {
+   target_subsys = to_configfs_subsystem(to_config_group(target));
+   root = parent;
+   } else {
+   target_subsys = parent->cg_subsys;
+   /* Find a cofnigfs root as we may need it for locking */
+   for (root = parent; !configfs_is_root(>cg_item);
+root = root->cg_item.ci_group)
+   ;
+   }
+
+   if (target_subsys != caller_subsys) {
+   struct configfs_dirent *p, *root_sd;
+   /*
+* We are in other configfs subsystem, so we have to do
+* additional locking to prevent other subsystem from being
+* unregistered
+*/
+   mutex_lock(_inode(root->cg_item.ci_dentry)->i_mutex);
+
+   /*
+* As we are trying to depend item from other subsystem
+* we have to check if this subsystem is still registered
+*/
+   root_sd = root->cg_item.ci_dentry->d_fsdata;
+   list_for_each_entry(p, _sd->s_children, s_sibling) {
+   if (p->s_type & CONFIGFS_DIR &&
+   _subsys->su_group.cg_item == p->s_element) {
+   subsys_sd = p;
+   break;
+   }
+   }
+
+   if (!subsys_sd)
+   goto out_root_unlock;
+   } else {
+   subsys_sd = target_subsys->su_group.cg_item.ci_dentry->d_fsdata;
+   }
+
+   spin_lock(_dirent_lock);
+   ret = configfs_depend_prep(subsys_sd->s_dentry, target);
+   if (ret)
+   goto out_unlock;
+
+   sd = target->ci_dentry->d_fsdata;
+   sd->s_dependent_count += 1;
+
+   ret = 0;
+
+out_unlock:
+   spin_unlock(_dirent_lock);
+
+   if 

[PATCHv2 13/15] usb: gadget: f_tcm: remove redundant singleton

[Andrzej Pietrasiewicz]

The only instance is guaranteed with TPG_INSTANCES defined to 1.

Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/usb/gadget/function/f_tcm.c | 9 -
 drivers/usb/gadget/function/tcm.h   | 2 --
 2 files changed, 11 deletions(-)

diff --git a/drivers/usb/gadget/function/f_tcm.c 
b/drivers/usb/gadget/function/f_tcm.c
index c2193c4..40c6563 100644
--- a/drivers/usb/gadget/function/f_tcm.c
+++ b/drivers/usb/gadget/function/f_tcm.c
@@ -1377,8 +1377,6 @@ static int usbg_init_nodeacl(struct se_node_acl *se_nacl, 
const char *name)
return 0;
 }
 
-struct usbg_tpg *the_only_tpg_I_currently_have;
-
 static struct se_portal_group *usbg_make_tpg(
struct se_wwn *wwn,
struct config_group *group,
@@ -1396,11 +1394,6 @@ static struct se_portal_group *usbg_make_tpg(
return ERR_PTR(-EINVAL);
if (kstrtoul(name + 5, 0, ) || tpgt > UINT_MAX)
return ERR_PTR(-EINVAL);
-   if (the_only_tpg_I_currently_have) {
-   pr_err("Until the gadget framework can't handle multiple\n");
-   pr_err("gadgets, you can't do this here.\n");
-   return ERR_PTR(-EBUSY);
-   }
ret = -ENODEV;
mutex_lock(_instances_lock);
for (i = 0; i < TPG_INSTANCES; ++i)
@@ -1443,7 +1436,6 @@ static struct se_portal_group *usbg_make_tpg(
tpg->fi = tpg_instances[i].func_inst;
mutex_unlock(>dep_lock);
mutex_unlock(_instances_lock);
-   the_only_tpg_I_currently_have = tpg;
return >se_tpg;
 
 free_workqueue:
@@ -1487,7 +1479,6 @@ static void usbg_drop_tpg(struct se_portal_group *se_tpg)
mutex_unlock(_instances_lock);
 
kfree(tpg);
-   the_only_tpg_I_currently_have = NULL;
 }
 
 static struct se_wwn *usbg_make_tport(
diff --git a/drivers/usb/gadget/function/tcm.h 
b/drivers/usb/gadget/function/tcm.h
index 0b8ff6d..b75c6f3 100644
--- a/drivers/usb/gadget/function/tcm.h
+++ b/drivers/usb/gadget/function/tcm.h
@@ -129,6 +129,4 @@ struct f_uas {
struct usb_request  *bot_req_out;
 };
 
-extern struct usbg_tpg *the_only_tpg_I_currently_have;
-
 #endif /* __TARGET_USB_GADGET_H__ */
-- 
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

[PATCHv2 09/15] usb: gadget: tcm: factor out f_tcm

[Andrzej Pietrasiewicz]

Prepare for converting tcm to new function registration interface.

Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/usb/gadget/function/f_tcm.c| 2168 
 drivers/usb/gadget/function/tcm.h  |  132 ++
 drivers/usb/gadget/legacy/tcm_usb_gadget.c | 2150 +--
 drivers/usb/gadget/legacy/tcm_usb_gadget.h |  132 --
 4 files changed, 2303 insertions(+), 2279 deletions(-)
 create mode 100644 drivers/usb/gadget/function/f_tcm.c
 create mode 100644 drivers/usb/gadget/function/tcm.h
 delete mode 100644 drivers/usb/gadget/legacy/tcm_usb_gadget.h

diff --git a/drivers/usb/gadget/function/f_tcm.c 
b/drivers/usb/gadget/function/f_tcm.c
new file mode 100644
index 000..d1b602a
--- /dev/null
+++ b/drivers/usb/gadget/function/f_tcm.c
@@ -0,0 +1,2168 @@
+/* Target based USB-Gadget
+ *
+ * UAS protocol handling, target callbacks, configfs handling,
+ * BBB (USB Mass Storage Class Bulk-Only (BBB) and Transport protocol handling.
+ *
+ * Author: Sebastian Andrzej Siewior 
+ * License: GPLv2 as published by FSF.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "tcm.h"
+
+static inline struct f_uas *to_f_uas(struct usb_function *f)
+{
+   return container_of(f, struct f_uas, function);
+}
+
+static void usbg_cmd_release(struct kref *);
+
+static inline void usbg_cleanup_cmd(struct usbg_cmd *cmd)
+{
+   kref_put(>ref, usbg_cmd_release);
+}
+
+/* Start bot.c code */
+
+static int bot_enqueue_cmd_cbw(struct f_uas *fu)
+{
+   int ret;
+
+   if (fu->flags & USBG_BOT_CMD_PEND)
+   return 0;
+
+   ret = usb_ep_queue(fu->ep_out, fu->cmd.req, GFP_ATOMIC);
+   if (!ret)
+   fu->flags |= USBG_BOT_CMD_PEND;
+   return ret;
+}
+
+static void bot_status_complete(struct usb_ep *ep, struct usb_request *req)
+{
+   struct usbg_cmd *cmd = req->context;
+   struct f_uas *fu = cmd->fu;
+
+   usbg_cleanup_cmd(cmd);
+   if (req->status < 0) {
+   pr_err("ERR %s(%d)\n", __func__, __LINE__);
+   return;
+   }
+
+   /* CSW completed, wait for next CBW */
+   bot_enqueue_cmd_cbw(fu);
+}
+
+static void bot_enqueue_sense_code(struct f_uas *fu, struct usbg_cmd *cmd)
+{
+   struct bulk_cs_wrap *csw = >bot_status.csw;
+   int ret;
+   u8 *sense;
+   unsigned int csw_stat;
+
+   csw_stat = cmd->csw_code;
+
+   /*
+* We can't send SENSE as a response. So we take ASC & ASCQ from our
+* sense buffer and queue it and hope the host sends a REQUEST_SENSE
+* command where it learns why we failed.
+*/
+   sense = cmd->sense_iu.sense;
+
+   csw->Tag = cmd->bot_tag;
+   csw->Status = csw_stat;
+   fu->bot_status.req->context = cmd;
+   ret = usb_ep_queue(fu->ep_in, fu->bot_status.req, GFP_ATOMIC);
+   if (ret)
+   pr_err("%s(%d) ERR: %d\n", __func__, __LINE__, ret);
+}
+
+static void bot_err_compl(struct usb_ep *ep, struct usb_request *req)
+{
+   struct usbg_cmd *cmd = req->context;
+   struct f_uas *fu = cmd->fu;
+
+   if (req->status < 0)
+   pr_err("ERR %s(%d)\n", __func__, __LINE__);
+
+   if (cmd->data_len) {
+   if (cmd->data_len > ep->maxpacket) {
+   req->length = ep->maxpacket;
+   cmd->data_len -= ep->maxpacket;
+   } else {
+   req->length = cmd->data_len;
+   cmd->data_len = 0;
+   }
+
+   usb_ep_queue(ep, req, GFP_ATOMIC);
+   return;
+   }
+   bot_enqueue_sense_code(fu, cmd);
+}
+
+static void bot_send_bad_status(struct usbg_cmd *cmd)
+{
+   struct f_uas *fu = cmd->fu;
+   struct bulk_cs_wrap *csw = >bot_status.csw;
+   struct usb_request *req;
+   struct usb_ep *ep;
+
+   csw->Residue = cpu_to_le32(cmd->data_len);
+
+   if (cmd->data_len) {
+   if (cmd->is_read) {
+   ep = fu->ep_in;
+   req = fu->bot_req_in;
+   } else {
+   ep = fu->ep_out;
+   req = fu->bot_req_out;
+   }
+
+   if (cmd->data_len > fu->ep_in->maxpacket) {
+   req->length = ep->maxpacket;
+   cmd->data_len -= ep->maxpacket;
+   } else {
+   req->length = cmd->data_len;
+   cmd->data_len = 0;
+   }
+   req->complete = bot_err_compl;
+   req->context = cmd;
+   req->buf = fu->cmd.buf;
+   usb_ep_queue(ep, req, GFP_KERNEL);
+   } else {
+   bot_enqueue_sense_code(fu, cmd);
+   }
+}
+
+static int bot_send_status(struct usbg_cmd *cmd, bool moved_data)
+{
+   struct f_uas *fu = cmd->fu;
+   

[PATCHv2 11/15] usb: gadget: tcm: convert to use new function registration interface

[Andrzej Pietrasiewicz]

Convert the only user of old tcm function interface so that the old
interface can be removed.

Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/usb/gadget/legacy/Kconfig  |  1 +
 drivers/usb/gadget/legacy/tcm_usb_gadget.c | 62 +-
 2 files changed, 53 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/gadget/legacy/Kconfig 
b/drivers/usb/gadget/legacy/Kconfig
index 4d682ad..a23d1b9 100644
--- a/drivers/usb/gadget/legacy/Kconfig
+++ b/drivers/usb/gadget/legacy/Kconfig
@@ -250,6 +250,7 @@ config USB_GADGET_TARGET
tristate "USB Gadget Target Fabric Module"
depends on TARGET_CORE
select USB_LIBCOMPOSITE
+   select USB_F_TCM
help
  This fabric is an USB gadget. Two USB protocols are supported that is
  BBB or BOT (Bulk Only Transport) and UAS (USB Attached SCSI). BOT is
diff --git a/drivers/usb/gadget/legacy/tcm_usb_gadget.c 
b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
index f042df4..c209148 100644
--- a/drivers/usb/gadget/legacy/tcm_usb_gadget.c
+++ b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
@@ -21,11 +21,9 @@
 #include 
 #include 
 
-USB_GADGET_COMPOSITE_OPTIONS();
+#include "u_tcm.h"
 
-/* #include to be removed when new function registration interface is used  */
-#define USBF_TCM_INCLUDED
-#include "../function/f_tcm.c"
+USB_GADGET_COMPOSITE_OPTIONS();
 
 #define UAS_VENDOR_ID  0x0525  /* NetChip */
 #define UAS_PRODUCT_ID 0xa4a5  /* Linux-USB File-backed Storage Gadget */
@@ -60,8 +58,31 @@ static struct usb_gadget_strings *usbg_strings[] = {
NULL,
 };
 
+static struct usb_function_instance *fi_tcm;
+static struct usb_function *f_tcm;
+
 static int guas_unbind(struct usb_composite_dev *cdev)
 {
+   if (!IS_ERR_OR_NULL(f_tcm))
+   usb_put_function(f_tcm);
+
+   return 0;
+}
+
+static int tcm_do_config(struct usb_configuration *c)
+{
+   int status;
+
+   f_tcm = usb_get_function(fi_tcm);
+   if (IS_ERR(f_tcm))
+   return PTR_ERR(f_tcm);
+
+   status = usb_add_function(c, f_tcm);
+   if (status < 0) {
+   usb_put_function(f_tcm);
+   return status;
+   }
+
return 0;
 }
 
@@ -71,6 +92,9 @@ static struct usb_configuration usbg_config_driver = {
.bmAttributes   = USB_CONFIG_ATT_SELFPOWER,
 };
 
+static int usbg_attach(struct usb_function_instance *f);
+static void usbg_detach(struct usb_function_instance *f);
+
 static int usb_target_bind(struct usb_composite_dev *cdev)
 {
int ret;
@@ -87,8 +111,7 @@ static int usb_target_bind(struct usb_composite_dev *cdev)
usbg_config_driver.iConfiguration =
usbg_us_strings[USB_G_STR_CONFIG].id;
 
-   ret = usb_add_config(cdev, _config_driver,
-   tcm_bind_config);
+   ret = usb_add_config(cdev, _config_driver, tcm_do_config);
if (ret)
return ret;
usb_composite_overwrite_options(cdev, );
@@ -104,25 +127,44 @@ static struct usb_composite_driver usbg_driver = {
.unbind = guas_unbind,
 };
 
-static int usbg_attach(struct usbg_tpg *tpg)
+static int usbg_attach(struct usb_function_instance *f)
 {
return usb_composite_probe(_driver);
 }
 
-static void usbg_detach(struct usbg_tpg *tpg)
+static void usbg_detach(struct usb_function_instance *f)
 {
usb_composite_unregister(_driver);
 }
 
 static int __init usb_target_gadget_init(void)
 {
-   return target_register_template(_ops);
+   struct f_tcm_opts *tcm_opts;
+
+   fi_tcm = usb_get_function_instance("tcm");
+   if (IS_ERR(fi_tcm))
+   return PTR_ERR(fi_tcm);
+
+   tcm_opts = container_of(fi_tcm, struct f_tcm_opts, func_inst);
+   mutex_lock(_opts->dep_lock);
+   tcm_opts->tcm_register_callback = usbg_attach;
+   tcm_opts->tcm_unregister_callback = usbg_detach;
+   tcm_opts->dependent = THIS_MODULE;
+   tcm_opts->can_attach = true;
+   tcm_opts->has_dep = true;
+   mutex_unlock(_opts->dep_lock);
+
+   fi_tcm->set_inst_name(fi_tcm, "tcm-legacy");
+
+   return 0;
 }
 module_init(usb_target_gadget_init);
 
 static void __exit usb_target_gadget_exit(void)
 {
-   target_unregister_template(_ops);
+   if (!IS_ERR_OR_NULL(fi_tcm))
+   usb_put_function_instance(fi_tcm);
+
 }
 module_exit(usb_target_gadget_exit);
 
-- 
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

[PATCHv2 04/15] tcm_usb_gadget: Fix enabled attribute failure

[Andrzej Pietrasiewicz]

From: Nicholas Bellinger 

Fix up tcm_usbg_tpg_store_enable() return value to propagate
usbg_attach() failure up to user-space if no HDC is found.

Reported-by: Andrzej Pietrasiewicz 
Cc: Andrzej Pietrasiewicz 
Cc: Sebastian Andrzej Siewior 
Signed-off-by: Nicholas Bellinger 
[split unrelated changes into separate patches]
Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/usb/gadget/legacy/tcm_usb_gadget.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/legacy/tcm_usb_gadget.c 
b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
index dcc9b1a..cbba4b9 100644
--- a/drivers/usb/gadget/legacy/tcm_usb_gadget.c
+++ b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
@@ -1505,10 +1505,14 @@ static ssize_t tcm_usbg_tpg_enable_store(struct 
config_item *item,
if (op > 1)
return -EINVAL;
 
-   if (op && tpg->gadget_connect)
+   if (op && tpg->gadget_connect) {
+   ret = -EINVAL;
goto out;
-   if (!op && !tpg->gadget_connect)
+   }
+   if (!op && !tpg->gadget_connect) {
+   ret = -EINVAL;
goto out;
+   }
 
if (op) {
ret = usbg_attach(tpg);
@@ -1518,8 +1522,10 @@ static ssize_t tcm_usbg_tpg_enable_store(struct 
config_item *item,
usbg_detach(tpg);
}
tpg->gadget_connect = op;
-out:
+
return count;
+out:
+   return ret;
 }
 
 static ssize_t tcm_usbg_tpg_nexus_show(struct config_item *item, char *page)
-- 
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

[PATCHv2 05/15] usb: gadget: tcm: split string definitions into function and device

[Andrzej Pietrasiewicz]

Prepare for factoring out f_tcm from a legacy gadget.

Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/usb/gadget/legacy/tcm_usb_gadget.c | 25 +
 drivers/usb/gadget/legacy/tcm_usb_gadget.h |  3 +--
 2 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/gadget/legacy/tcm_usb_gadget.c 
b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
index cbba4b9..556decf 100644
--- a/drivers/usb/gadget/legacy/tcm_usb_gadget.c
+++ b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
@@ -1990,13 +1990,13 @@ static struct usb_device_descriptor usbg_device_desc = {
.bNumConfigurations =   1,
 };
 
+#define USB_G_STR_CONFIG USB_GADGET_FIRST_AVAIL_IDX
+
 static struct usb_string   usbg_us_strings[] = {
[USB_GADGET_MANUFACTURER_IDX].s = "Target Manufactor",
[USB_GADGET_PRODUCT_IDX].s  = "Target Product",
[USB_GADGET_SERIAL_IDX].s   = "0001",
[USB_G_STR_CONFIG].s= "default config",
-   [USB_G_STR_INT_UAS].s   = "USB Attached SCSI",
-   [USB_G_STR_INT_BBB].s   = "Bulk Only Transport",
{ },
 };
 
@@ -2010,6 +2010,22 @@ static struct usb_gadget_strings *usbg_strings[] = {
NULL,
 };
 
+static struct usb_string   tcm_us_strings[] = {
+   [USB_G_STR_INT_UAS].s   = "USB Attached SCSI",
+   [USB_G_STR_INT_BBB].s   = "Bulk Only Transport",
+   { },
+};
+
+static struct usb_gadget_strings tcm_stringtab = {
+   .language = 0x0409,
+   .strings = tcm_us_strings,
+};
+
+static struct usb_gadget_strings *tcm_strings[] = {
+   _stringtab,
+   NULL,
+};
+
 static int guas_unbind(struct usb_composite_dev *cdev)
 {
return 0;
@@ -2192,10 +2208,11 @@ static int usbg_cfg_bind(struct usb_configuration *c)
fu->function.set_alt = usbg_set_alt;
fu->function.setup = usbg_setup;
fu->function.disable = usbg_disable;
+   fu->function.strings = tcm_strings;
fu->tpg = the_only_tpg_I_currently_have;
 
-   bot_intf_desc.iInterface = usbg_us_strings[USB_G_STR_INT_BBB].id;
-   uasp_intf_desc.iInterface = usbg_us_strings[USB_G_STR_INT_UAS].id;
+   bot_intf_desc.iInterface = tcm_us_strings[USB_G_STR_INT_BBB].id;
+   uasp_intf_desc.iInterface = tcm_us_strings[USB_G_STR_INT_UAS].id;
 
ret = usb_add_function(c, >function);
if (ret)
diff --git a/drivers/usb/gadget/legacy/tcm_usb_gadget.h 
b/drivers/usb/gadget/legacy/tcm_usb_gadget.h
index 0b749e1..f1b69e2 100644
--- a/drivers/usb/gadget/legacy/tcm_usb_gadget.h
+++ b/drivers/usb/gadget/legacy/tcm_usb_gadget.h
@@ -16,8 +16,7 @@
 #define UASP_SS_EP_COMP_NUM_STREAMS (1 << UASP_SS_EP_COMP_LOG_STREAMS)
 
 enum {
-   USB_G_STR_CONFIG = USB_GADGET_FIRST_AVAIL_IDX,
-   USB_G_STR_INT_UAS,
+   USB_G_STR_INT_UAS = 0,
USB_G_STR_INT_BBB,
 };
 
-- 
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

[PATCHv2 02/15] tcm_usb_gadget: Don't strip off nexus WWPN prefix

[Andrzej Pietrasiewicz]

From: Nicholas Bellinger 

Avoid stripping off the 'naa.' I_T nexus prefix from configfs
attribute store input, so that user-space will get back what
it originaly wrote into ../usb_gadget/$WWPN/$TPGT/nexus.

Note the SCSI initiator WWPN is purely symbolic for UAS + BOT,
so it will not effect host side code.

Reported-by: Andrzej Pietrasiewicz 
Cc: Andrzej Pietrasiewicz 
Cc: Sebastian Andrzej Siewior 
Signed-off-by: Nicholas Bellinger 
---
 drivers/usb/gadget/legacy/tcm_usb_gadget.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/legacy/tcm_usb_gadget.c 
b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
index 33833fe..d22e188 100644
--- a/drivers/usb/gadget/legacy/tcm_usb_gadget.c
+++ b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
@@ -1657,7 +1657,7 @@ static ssize_t tcm_usbg_tpg_nexus_store(struct 
config_item *item,
if (i_port[strlen(i_port) - 1] == '\n')
i_port[strlen(i_port) - 1] = '\0';
 
-   ret = tcm_usbg_make_nexus(tpg, _port[4]);
+   ret = tcm_usbg_make_nexus(tpg, _port[0]);
if (ret < 0)
return ret;
return count;
-- 
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: Alternative approach to solve the deferred probe

[Grygorii Strashko]

Hi Russell,

On 10/21/2015 09:28 PM, Russell King - ARM Linux wrote:
> On Wed, Oct 21, 2015 at 09:13:48PM +0300, Grygorii Strashko wrote:
>> But I worry a bit (and that my main point) about these few additional
>> rounds of deferred device probing which I have right now and which allows
>> some of drivers to finish, finally, their probes successfully.
>> With proposed change I'll get more messages in boot log, but some of
>> them will belong to drivers which have been probed successfully and so,
>> they will be not really useful.
> 
> Then you haven't properly understood my proposal.
> 
> I want to get rid of all the "X deferred its probing" messages up until
> the point that we set the "please report deferred probes" flag.
> 
> That _should_ mean that all the deferred probing that goes on becomes
> _totally_ silent and becomes hidden (unless you really want to see it,
> in which case we can make a debug option which turns it on) up until
> we're at the point where we want to enter userspace.
> 
> At that point, we then report into the kernel log which devices are
> still deferring and, via appropriately placed dev_warn_deferred(),
> the reasons why the devices are being deferred.
> 
> So, gone will be all the messages earlier in the log about device X
> not having a GPIO/clock/whatever because the device providing the
> GPIO/clock/whatever hasn't been probed.
> 
> If everything is satisfied by the time we run this last round (again,
> I'm not using a three line sentence to describe exactly what I mean,
> I'm sure you know by now... oops, I just did) then the kernel will
> report nothing about any deferrals.  That's _got_ to be an improvement.

Sorry Master, but you really don't need to spend so much time typing the
same things three times  - I understand what are you trying to do :(

I did my comments with assumption that it's not officially prohibited/deprecated
to register drivers (and execute probes) from late_initcall() layer
(just recommended) and there are still bunch of drivers which are doing this.
Now I see that it's not a recommendation any more, and deferred_probe_initcall()
might be a good place to activate driver_deferred_probe_report if goal is to
identify and fix such drivers.

Sorry for your time.

> 
>>
>> As result, I think, the most important thing is to identify (or create)
>> some point during kernel boot when it will be possible to say that all
>> built-in drivers (at least) finish their probes 100% (done or defer).
>>
>> Might be do_initcalls() can be updated (smth like this):
>> static void __init do_initcalls(void)
>> {
>>  int level;
>>
>>  for (level = 0; level < ARRAY_SIZE(initcall_levels) - 1; level++)
>>  do_initcall_level(level);
>>
>> +wait_for_device_probe();
>> +/* Now one final round, reporting any devices that remain deferred */
>> +driver_deferred_probe_report = true;
>> +driver_deferred_probe_trigger();
>> +wait_for_device_probe();
>> }
>>
>> Also, in my opinion, it will be useful if this debugging feature will be
>> optional.
> 
> I wonder why you want it optional... so I'm going to guess and cover
> both cases I can think of below to head off another round of reply on
> this point (sorry if this sucks eggs.)
> 
> I don't see it as being optional, because it's going to be cheap to run
> in the case of a system which has very few or no errors - which is what
> you should have for production systems, right?
> 

Also, I've spend some time today testing your proposal - hope you'll find 
results
useful.

I've applied truncated version of your patch (diff below) on TI's 4.1 kernel and
run few tests (log is below) on dra7-evm/am43xx-gpevm - K4.1 is not far away 
from LKML,
so I assume this test is valid. Overall boot process consists from two stages:
kernel boot and modules loading. 

My Changes:
 - only really_probe() modified to show deferred device/drivers 

>From the log I can see additional messages in log when modules are loading,
because driver_deferred_probe_report is still true - dwc3 probes were deferred,
but then finally succeeded.

So, as you've mentioned, it seems a good thing to deactivate 
driver_deferred_probe_report and
provide user with ability to turn it on again (and probably re-trigger deferred
device probing).

I've found no issues during Kernel boot (built-in) time, new messages are 
displayed only
if probe is failed for some drivers:
[3.219700] == deferred_probe_initcalll
[3.226820] platform omapdrm.0: Driver omapdrm requests probe deferral
[3.233378] platform omapdrm.0: deferring probe:  Driver omapdrm 
requests probe deferral
[3.242084] dra7evm-tpd12s015 encoder@1: failed to parse CT CP HPD gpio
[3.248737] platform encoder@1: Driver dra7evm-tpd12s015 requests probe 
deferral
[3.256168] platform encoder@1: deferring probe:  Driver 
dra7evm-tpd12s015 requests probe deferral
[3.265763] connector-hdmi connector@1: failed to find video source

[PATCHv2 12/15] usb: gadget: f_tcm: remove compatibility layer

[Andrzej Pietrasiewicz]

There are no old function interface users left.

Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/usb/gadget/function/f_tcm.c | 87 +++--
 1 file changed, 6 insertions(+), 81 deletions(-)

diff --git a/drivers/usb/gadget/function/f_tcm.c 
b/drivers/usb/gadget/function/f_tcm.c
index 910f9a7..c2193c4 100644
--- a/drivers/usb/gadget/function/f_tcm.c
+++ b/drivers/usb/gadget/function/f_tcm.c
@@ -24,8 +24,6 @@
 #include "tcm.h"
 #include "u_tcm.h"
 
-#ifndef USBF_TCM_INCLUDED
-
 #define TPG_INSTANCES  1
 
 struct tpg_instance {
@@ -36,7 +34,6 @@ struct tpg_instance {
 static struct tpg_instance tpg_instances[TPG_INSTANCES];
 
 static DEFINE_MUTEX(tpg_instances_lock);
-#endif
 
 static inline struct f_uas *to_f_uas(struct usb_function *f)
 {
@@ -1392,10 +1389,8 @@ static struct se_portal_group *usbg_make_tpg(
struct usbg_tpg *tpg;
unsigned long tpgt;
int ret;
-#ifndef USBF_TCM_INCLUDED
struct f_tcm_opts *opts;
unsigned i;
-#endif
 
if (strstr(name, "tpgt_") != name)
return ERR_PTR(-EINVAL);
@@ -1406,7 +1401,6 @@ static struct se_portal_group *usbg_make_tpg(
pr_err("gadgets, you can't do this here.\n");
return ERR_PTR(-EBUSY);
}
-#ifndef USBF_TCM_INCLUDED
ret = -ENODEV;
mutex_lock(_instances_lock);
for (i = 0; i < TPG_INSTANCES; ++i)
@@ -1423,26 +1417,16 @@ static struct se_portal_group *usbg_make_tpg(
 
if (opts->has_dep && !try_module_get(opts->dependent))
goto unlock_dep;
-#endif
 
tpg = kzalloc(sizeof(struct usbg_tpg), GFP_KERNEL);
ret = -ENOMEM;
if (!tpg)
-#ifdef USBF_TCM_INCLUDED
-   return ERR_PTR(-ENOMEM);
-#else
goto unref_dep;
-#endif
mutex_init(>tpg_mutex);
atomic_set(>tpg_port_count, 0);
tpg->workqueue = alloc_workqueue("tcm_usb_gadget", 0, 1);
-   if (!tpg->workqueue) {
-#ifndef USBF_TCM_INCLUDED
+   if (!tpg->workqueue)
goto free_tpg;
-#endif
-   kfree(tpg);
-   return NULL;
-   }
 
tpg->tport = tport;
tpg->tport_tpgt = tpgt;
@@ -1452,23 +1436,16 @@ static struct se_portal_group *usbg_make_tpg(
 * pretend to be SAS..
 */
ret = core_tpg_register(wwn, >se_tpg, SCSI_PROTOCOL_SAS);
-   if (ret < 0) {
-#ifndef USBF_TCM_INCLUDED
+   if (ret < 0)
goto free_workqueue;
-#endif
-   destroy_workqueue(tpg->workqueue);
-   kfree(tpg);
-   return NULL;
-   }
-#ifndef USBF_TCM_INCLUDED
+
tpg_instances[i].tpg = tpg;
tpg->fi = tpg_instances[i].func_inst;
mutex_unlock(>dep_lock);
mutex_unlock(_instances_lock);
-#endif
the_only_tpg_I_currently_have = tpg;
return >se_tpg;
-#ifndef USBF_TCM_INCLUDED
+
 free_workqueue:
destroy_workqueue(tpg->workqueue);
 free_tpg:
@@ -1481,7 +1458,6 @@ unlock_inst:
mutex_unlock(_instances_lock);
 
return ERR_PTR(ret);
-#endif
 }
 
 static int tcm_usbg_drop_nexus(struct usbg_tpg *);
@@ -1490,16 +1466,13 @@ static void usbg_drop_tpg(struct se_portal_group 
*se_tpg)
 {
struct usbg_tpg *tpg = container_of(se_tpg,
struct usbg_tpg, se_tpg);
-#ifndef USBF_TCM_INCLUDED
unsigned i;
struct f_tcm_opts *opts;
-#endif
 
tcm_usbg_drop_nexus(tpg);
core_tpg_deregister(se_tpg);
destroy_workqueue(tpg->workqueue);
 
-#ifndef USBF_TCM_INCLUDED
mutex_lock(_instances_lock);
for (i = 0; i < TPG_INSTANCES; ++i)
if (tpg_instances[i].tpg == tpg)
@@ -1512,7 +1485,7 @@ static void usbg_drop_tpg(struct se_portal_group *se_tpg)
module_put(opts->dependent);
mutex_unlock(>dep_lock);
mutex_unlock(_instances_lock);
-#endif
+
kfree(tpg);
the_only_tpg_I_currently_have = NULL;
 }
@@ -2081,13 +2054,10 @@ static int tcm_bind(struct usb_configuration *c, struct 
usb_function *f)
struct f_uas*fu = to_f_uas(f);
struct usb_gadget   *gadget = c->cdev->gadget;
struct usb_ep   *ep;
-#ifndef USBF_TCM_INCLUDED
struct f_tcm_opts   *opts;
-#endif
int iface;
int ret;
 
-#ifndef USBF_TCM_INCLUDED
opts = container_of(f->fi, struct f_tcm_opts, func_inst);
 
mutex_lock(>dep_lock);
@@ -2096,7 +2066,7 @@ static int tcm_bind(struct usb_configuration *c, struct 
usb_function *f)
return -ENODEV;
}
mutex_unlock(>dep_lock);
-#endif
+
if (tcm_us_strings[0].id == 0) {
ret = usb_string_ids_tab(c->cdev, tcm_us_strings);
if (ret < 0)
@@ -2172,18 +2142,6 @@ ep_fail:
return -ENOTSUPP;
 }
 
-#ifdef USBF_TCM_INCLUDED
-
-static void tcm_old_unbind(struct usb_configuration *c, struct 

[PATCHv2 03/15] tcm_usb_gadget: Fix nexus leak

[Andrzej Pietrasiewicz]

From: Nicholas Bellinger 

This patch adds the missing tcm_usbg_drop_nexus() to properly
release tcm_usbg_nexus memory during typical ->fabric_drop_tpg()
callback shutdown.

Reported-by: Andrzej Pietrasiewicz 
Cc: Andrzej Pietrasiewicz 
Cc: Sebastian Andrzej Siewior 
Signed-off-by: Nicholas Bellinger 
[split unrelated changes into separate patches]
Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/usb/gadget/legacy/tcm_usb_gadget.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/gadget/legacy/tcm_usb_gadget.c 
b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
index d22e188..dcc9b1a 100644
--- a/drivers/usb/gadget/legacy/tcm_usb_gadget.c
+++ b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
@@ -1423,11 +1423,14 @@ static struct se_portal_group *usbg_make_tpg(
return >se_tpg;
 }
 
+static int tcm_usbg_drop_nexus(struct usbg_tpg *);
+
 static void usbg_drop_tpg(struct se_portal_group *se_tpg)
 {
struct usbg_tpg *tpg = container_of(se_tpg,
struct usbg_tpg, se_tpg);
 
+   tcm_usbg_drop_nexus(tpg);
core_tpg_deregister(se_tpg);
destroy_workqueue(tpg->workqueue);
kfree(tpg);
-- 
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 2.0 device has 8ms latency

[John Tapsell]

On 15 October 2015 at 15:37, Alan Stern  wrote:
> On Thu, 15 Oct 2015, John Tapsell wrote:
>
>> I did have one wacky idea.  I'm sure it's stupid, but here it is:  Is
>> it at all possible that there's a bug in the linux usb code where a
>> bInterval value of 1ms is being converted into microframes (8
>> microframes)  but then because it's a full speed device it's then
>> incorrectly read as an 8ms delay?  I did have a look into the code,
>> but got thoroughly lost.  Any pointers on how I could check my wacky
>> theory?
>
> There is no such bug.  Such a thing would have been spotted long, long
> ago.
>
>> I'm just wondering where this 8ms delay comes from.
>
> Multiple places: time to submit the request, time to reserve
> bandwidth for the previously unused interrupt endpoint, time to
> complete the transfer, all multiplied by 2.
>
> You can get more information from usbmon (see
> Documentation/usb/usbmon.txt in the kernel source).  But Greg is right;
> the protocol you described is terrible.  There's no need for a multiple
> ping-pong interchange like that; all you should need to do is wait for
> the device to send the next bit (or whatever) of data as soon as it
> becomes available.
>
> Alan Stern


I had a look at the windows driver, and found that it is implemented
in pretty much exactly the same way as the linux driver, but it
operates at twice the speed.  And that's for a user-space USB driver.

Any ideas why?

Thanks,

John Tapsell
--
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 2.0 device has 8ms latency

[Greg KH]

On Thu, Oct 22, 2015 at 05:15:50PM +0100, John Tapsell wrote:
> On 15 October 2015 at 15:37, Alan Stern  wrote:
> > On Thu, 15 Oct 2015, John Tapsell wrote:
> >
> >> I did have one wacky idea.  I'm sure it's stupid, but here it is:  Is
> >> it at all possible that there's a bug in the linux usb code where a
> >> bInterval value of 1ms is being converted into microframes (8
> >> microframes)  but then because it's a full speed device it's then
> >> incorrectly read as an 8ms delay?  I did have a look into the code,
> >> but got thoroughly lost.  Any pointers on how I could check my wacky
> >> theory?
> >
> > There is no such bug.  Such a thing would have been spotted long, long
> > ago.
> >
> >> I'm just wondering where this 8ms delay comes from.
> >
> > Multiple places: time to submit the request, time to reserve
> > bandwidth for the previously unused interrupt endpoint, time to
> > complete the transfer, all multiplied by 2.
> >
> > You can get more information from usbmon (see
> > Documentation/usb/usbmon.txt in the kernel source).  But Greg is right;
> > the protocol you described is terrible.  There's no need for a multiple
> > ping-pong interchange like that; all you should need to do is wait for
> > the device to send the next bit (or whatever) of data as soon as it
> > becomes available.
> >
> > Alan Stern
> 
> 
> I had a look at the windows driver, and found that it is implemented
> in pretty much exactly the same way as the linux driver, but it
> operates at twice the speed.  And that's for a user-space USB driver.
> 
> Any ideas why?

"pretty much"?  What exactly is the difference?  And you should be able
to try out a userspace driver in Linux as well, libusb works on Windows
and Linux so you can do a good comparison.

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