[PATCH] usb: dwc3: Remove DEBUG define from Qualcomm DWC3 glue driver

[Douglas Anderson]

It appears that a "#define DEBUG" was left in on the recent patch
landed for the Qualcomm DWC3 glue driver.  Let's remove it.

Fixes: a4333c3a6ba9 ("usb: dwc3: Add Qualcomm DWC3 glue driver")
Signed-off-by: Douglas Anderson 
---

 drivers/usb/dwc3/dwc3-qcom.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
index 8abb6f31389d..b0e67ab2f98c 100644
--- a/drivers/usb/dwc3/dwc3-qcom.c
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -3,7 +3,6 @@
  *
  * Inspired by dwc3-of-simple.c
  */
-#define DEBUG
 
 #include 
 #include 
-- 
2.17.0.921.gf22659ad46-goog

--
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: host: ohci: fix sfr kernel warning in ohci-at91 driver

[Prasanthi Chellakumar]

The USB Host Controller driver 'ohci-at91.c' reads a Special Function
Register - OHCI Interrupt Configuration Register (AT91_SFR_OHCIICR)
for bits SUSPEND_A/B/C. These bits are defined in sama5d2 alone, so
sfr register mapping is done with compatible string "atmel,sama5d2-sfr".
This gives a kernel warning 'failed to find sfr node' with non sama5d2
cpus which is removed here, thus leaving it up to having a proper DTS.

Signed-off-by: Prasanthi Chellakumar 

---

The AT91_SFR_OHCIIR register is read for USB suspend and wake
up control. The OHCI driver has a sfr register mapping for sama5d2
alone. The USB suspend proceeds only when there is valid sfr regmap.
So SFR access in boards that it is absent is not required. In such
boards, USB suspend control requests is processed by usb_hub_control().
But there is a kernel warning with non sama5d2 cpus. This patch fixes
the kernel warning, changing to debug message(dev_dbg).
---
 drivers/usb/host/ohci-at91.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index af0566d..ce11c47 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -214,7 +214,7 @@ static int usb_hcd_at91_probe(const struct hc_driver 
*driver,
 
ohci_at91->sfr_regmap = at91_dt_syscon_sfr();
if (!ohci_at91->sfr_regmap)
-   dev_warn(dev, "failed to find sfr node\n");
+   dev_dbg(dev, "failed to find sfr node\n");
 
board = hcd->self.controller->platform_data;
ohci = hcd_to_ohci(hcd);
-- 
2.7.4

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

Re: [PATCH v3 2/2] usb: misc: xapea00x: perform platform initialization of TPM

[Ken Goldman]

On 5/10/2018 10:31 AM, David R. Bild wrote:


Could this be implemented as a first priority to daemon. If it turns out
to be bad approach we can reconsider kernel. If we land it to kernel it
is harder to take steps back.


Is the daemon an implementation of the TCG resource manager spec?


The TCG spec does use a daemon approach, similar to tcsd for TPM 1.2.

The Linux TPM driver is currently using a different approach, a 
in-kernel (in the TPM device driver) resource manager.


The advantages I see to putting the resource manager in the device 
driver are:


1 - Kernel uses of the TPM go through the same device driver, so they 
leverage the resource manager.


2 - The TPM device driver offers a standard /dev/tpmrm0 interface,
100% compatible with /dev/tpm0.

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

Re: [PATCH v3 2/2] usb: misc: xapea00x: perform platform initialization of TPM

[Ken Goldman]

On 5/8/2018 11:36 AM, James Bottomley wrote:

On Tue, 2018-05-08 at 10:29 -0500, David R. Bild wrote:

On Tue, May 8, 2018 at 10:25 AM, James Bottomley




I don't see any reason to set an unreachable password for the
platform
hierarchy if the UEFI didn't.  If the desire is to disable the
platform
hierarchy, then it should be disabled, not have a random password
set.


"Set random password and throw away the key" was my way of disabling
the platform hierarchy.  Is there a better way of doing that?


Well, yes, use TPM2_HierarchyControl to set phEnable to CLEAR.


There is a huge difference between the two.

"Set a random password" is the recommended approach.  This just
prohibits using the platform authorization - a good idea.

phEnable CLEAR disables the hierarchy, preventing it from being used
at all.  A basic problem would be that the EK certificates could not be
read.

There are likely to be other issues, like not being able to do a field 
upgrade post-OS,


--
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: core: message: remove extra endianness conversion in usb_set_isoch_delay

[Ruslan Bilovol]

No need to do extra endianness conversion in
usb_set_isoch_delay because it is already done
in usb_control_msg()

Fixes: 886ee36e7205 ("usb: core: add support for USB_REQ_SET_ISOCH_DELAY")
Cc: Dmytro Panchenko 
Cc: Felipe Balbi 
Cc: stable  # v4.16+
Signed-off-by: Ruslan Bilovol 
---
 drivers/usb/core/message.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index 0c11d40..7b13700 100644
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -940,7 +940,7 @@ int usb_set_isoch_delay(struct usb_device *dev)
return usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
USB_REQ_SET_ISOCH_DELAY,
USB_DIR_OUT | USB_TYPE_STANDARD | USB_RECIP_DEVICE,
-   cpu_to_le16(dev->hub_delay), 0, NULL, 0,
+   dev->hub_delay, 0, NULL, 0,
USB_CTRL_SET_TIMEOUT);
 }
 
-- 
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/gadget: aspeed-vhub: add USB_LIBCOMPOSITE dependency

[Arnd Bergmann]

Without that option, we run into a link failure:

drivers/usb/gadget/udc/aspeed-vhub/hub.o: In function 
`ast_vhub_std_hub_request':
hub.c:(.text+0x5b0): undefined reference to `usb_gadget_get_string'

Fixes: 7ecca2a4080c ("usb/gadget: Add driver for Aspeed SoC virtual hub")
Signed-off-by: Arnd Bergmann 
---
 drivers/usb/gadget/udc/aspeed-vhub/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/gadget/udc/aspeed-vhub/Kconfig 
b/drivers/usb/gadget/udc/aspeed-vhub/Kconfig
index f0cdf89b8503..83ba8a2eb6af 100644
--- a/drivers/usb/gadget/udc/aspeed-vhub/Kconfig
+++ b/drivers/usb/gadget/udc/aspeed-vhub/Kconfig
@@ -2,6 +2,7 @@
 config USB_ASPEED_VHUB
tristate "Aspeed vHub UDC driver"
depends on ARCH_ASPEED || COMPILE_TEST
+   depends on USB_LIBCOMPOSITE
help
  USB peripheral controller for the Aspeed AST2500 family
  SoCs supporting the "vHub" functionality and USB2.0
-- 
2.9.0

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

[PATCH] usb: dwc3: qcom: mark PM functions as __maybe_unused

[Arnd Bergmann]

The #ifdef guards around these are wrong, resulting in warnings
in certain configurations:

drivers/usb/dwc3/dwc3-qcom.c:244:12: error: 'dwc3_qcom_resume' defined but not 
used [-Werror=unused-function]
 static int dwc3_qcom_resume(struct dwc3_qcom *qcom)
^~~~
drivers/usb/dwc3/dwc3-qcom.c:223:12: error: 'dwc3_qcom_suspend' defined but not 
used [-Werror=unused-function]
 static int dwc3_qcom_suspend(struct dwc3_qcom *qcom)

This replaces the guards with __maybe_unused annotations to shut up
the warnings and give better compile time coverage.

Fixes: a4333c3a6ba9 ("usb: dwc3: Add Qualcomm DWC3 glue driver")
Signed-off-by: Arnd Bergmann 
---
 drivers/usb/dwc3/dwc3-qcom.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
index 8abb6f31389d..d7a4728b48d5 100644
--- a/drivers/usb/dwc3/dwc3-qcom.c
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -548,8 +548,7 @@ static int dwc3_qcom_remove(struct platform_device *pdev)
return 0;
 }
 
-#ifdef CONFIG_PM_SLEEP
-static int dwc3_qcom_pm_suspend(struct device *dev)
+static int __maybe_unused dwc3_qcom_pm_suspend(struct device *dev)
 {
struct dwc3_qcom *qcom = dev_get_drvdata(dev);
int ret = 0;
@@ -561,7 +560,7 @@ static int dwc3_qcom_pm_suspend(struct device *dev)
return ret;
 }
 
-static int dwc3_qcom_pm_resume(struct device *dev)
+static int __maybe_unused dwc3_qcom_pm_resume(struct device *dev)
 {
struct dwc3_qcom *qcom = dev_get_drvdata(dev);
int ret;
@@ -572,23 +571,20 @@ static int dwc3_qcom_pm_resume(struct device *dev)
 
return ret;
 }
-#endif
 
-#ifdef CONFIG_PM
-static int dwc3_qcom_runtime_suspend(struct device *dev)
+static int __maybe_unused dwc3_qcom_runtime_suspend(struct device *dev)
 {
struct dwc3_qcom *qcom = dev_get_drvdata(dev);
 
return dwc3_qcom_suspend(qcom);
 }
 
-static int dwc3_qcom_runtime_resume(struct device *dev)
+static int __maybe_unused dwc3_qcom_runtime_resume(struct device *dev)
 {
struct dwc3_qcom *qcom = dev_get_drvdata(dev);
 
return dwc3_qcom_resume(qcom);
 }
-#endif
 
 static const struct dev_pm_ops dwc3_qcom_dev_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(dwc3_qcom_pm_suspend, dwc3_qcom_pm_resume)
-- 
2.9.0

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

Re: Serdev: USB device and sysdev probing ala i2c

[Rob Herring]

On Fri, May 25, 2018 at 7:08 AM, Johan Hovold  wrote:
> On Thu, May 24, 2018 at 11:49:24AM -0500, Rob Herring wrote:
>> On Thu, May 24, 2018 at 7:18 AM, Ricardo Ribalda Delgado
>>  wrote:
>> > Hi Johan,
>> >
>> > On Thu, May 24, 2018 at 2:07 PM Johan Hovold  wrote:
>
>> >> Serdev currently only supports device tree and ACPI. Using out-of-tree
>> >> code, you could load a device tree fragment during runtime to describe
>> >> your serial bus (or you just amend the device tree).
>> >
>> >> Using device tree overlays would have the benefit of being able to
>> >> describe associated resources (e.g. reset gpios) which a simple
>> >> compatible string (or equivalent) would not.
>> >
>> >> But there are examples where a simple compatible string would do, for
>> >> example an existing CEC device presenting itself as a generic USB CDC
>> >> device (hopefully with a dedicated VID/PID so that no user-space
>> >> configuration is needed at all).
>
>> The fundamental problem here is you need a parent device node to apply
>> a DT overlay to and a USB device hotplugged has no DT device node. The
>> system you are running on may not even have a DT (like a PC). If you
>> have an overlay of the downstream devices, they have to be a child of
>> something for the overlay to apply to. We could just create virtual
>> device nodes for the purposes of applying overlays to. Another option
>> would be allowing multiple DTs. Then you aren't even using overlays
>> (what's the point of an overlay when a system has no real DT to begin
>> with). That also would mean they are completely independent from any
>> real DT or other instances (you may want to plug in multiple of the
>> same device).
>
> Right, there's more (than just a DT overlay loader) that needs to be in
> place before this could be used for the generic hotplug case (and even
> more than that if this was to be usable for ACPI systems).
>
> I think generating DT nodes during enumeration is preferable to having
> detached trees, if only to deal with the case where a loaded overlay do
> overlap with the "real" static tree.

Generating nodes effectively means we're implementing the full USB
tree as defined for OpenFirmware[1]. I'd prefer to not go there. That
seems a bit pointless as for most of the devices we don't care and
there's really nothing related to USB we care about. We just need to
describe downstream functions. The USB device (or interface) just
happens to be the controller/provider for those functions.

There should only be overlap with a real tree if devices are soldered
onto a board or use a custom connector and you have other sideband
signals.

>
> Another problem is that we need to deregister any tty device and
> essentially reprobe the underlying serial controller whenever user space
> tells us what can be found on the other end of wire in order to register
> a serdev controller and device instead. IIRC this is something we would
> get for free if using DT overlays (i.e. any device with a modified DT
> node would get removed and readded, or at least notified that something
> changed).

I did some experiments in this area. Marcel wanted to make all BT
drivers serdev only and then make the BT ldisc just create serdev
devices. And all this would be transparent to existing BT userspace.
As part of this I modified registration to register both serdev ctrlr
and tty char device and allow adding slave devices later. It's up on
my serdev-ldisc-v2 branch in all its hacky glory.

I don't think we get anything for free with overlays. I think we only
handle platform devices and only new nodes added. There are notifiers
for modifications, but if no one is listening modifications won't have
any effect.

Rob


[1] https://www.devicetree.org/open-firmware/bindings/usb/usb-1_0.ps
--
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 v4] usbip: dynamically allocate idev by nports found in sysfs

[Michael Grzeschik]

As the amount of available ports varies by the kernels build
configuration. To remove the limitation of the fixed 128 ports
we allocate the amount of idevs by using the number we get
from the kernel.

Signed-off-by: Michael Grzeschik 
---
v1 -> v2: - reworked memory allocation into one calloc call
  - added error path on allocation failure
v2 -> v3: - moved check for available nports to beginning of function
v3 -> v4: - changed get_nports to get hc_device via parameter
  - moved calloc after valid get_nports call

 tools/usb/usbip/libsrc/vhci_driver.c | 32 +---
 tools/usb/usbip/libsrc/vhci_driver.h |  3 +--
 2 files changed, 20 insertions(+), 15 deletions(-)

diff --git a/tools/usb/usbip/libsrc/vhci_driver.c 
b/tools/usb/usbip/libsrc/vhci_driver.c
index c9c81614a66ad..4204359c9feef 100644
--- a/tools/usb/usbip/libsrc/vhci_driver.c
+++ b/tools/usb/usbip/libsrc/vhci_driver.c
@@ -135,11 +135,11 @@ static int refresh_imported_device_list(void)
return 0;
 }
 
-static int get_nports(void)
+static int get_nports(struct udev_device *hc_device)
 {
const char *attr_nports;
 
-   attr_nports = udev_device_get_sysattr_value(vhci_driver->hc_device, 
"nports");
+   attr_nports = udev_device_get_sysattr_value(hc_device, "nports");
if (!attr_nports) {
err("udev_device_get_sysattr_value nports failed");
return -1;
@@ -242,35 +242,41 @@ static int read_record(int rhport, char *host, unsigned 
long host_len,
 
 int usbip_vhci_driver_open(void)
 {
+   int nports;
+   struct udev_device *hc_device;
+
udev_context = udev_new();
if (!udev_context) {
err("udev_new failed");
return -1;
}
 
-   vhci_driver = calloc(1, sizeof(struct usbip_vhci_driver));
-
/* will be freed in usbip_driver_close() */
-   vhci_driver->hc_device =
+   hc_device =
udev_device_new_from_subsystem_sysname(udev_context,
   USBIP_VHCI_BUS_TYPE,
   USBIP_VHCI_DEVICE_NAME);
-   if (!vhci_driver->hc_device) {
+   if (!hc_device) {
err("udev_device_new_from_subsystem_sysname failed");
goto err;
}
 
-   vhci_driver->nports = get_nports();
-   dbg("available ports: %d", vhci_driver->nports);
-
-   if (vhci_driver->nports <= 0) {
+   nports = get_nports(hc_device);
+   if (nports <= 0) {
err("no available ports");
goto err;
-   } else if (vhci_driver->nports > MAXNPORT) {
-   err("port number exceeds %d", MAXNPORT);
+   }
+   dbg("available ports: %d", nports);
+
+   vhci_driver = calloc(1, sizeof(struct usbip_vhci_driver) +
+   nports * sizeof(struct usbip_imported_device));
+   if (!vhci_driver) {
+   err("vhci_driver allocation failed");
goto err;
}
 
+   vhci_driver->nports = nports;
+   vhci_driver->hc_device = hc_device;
vhci_driver->ncontrollers = get_ncontrollers();
dbg("available controllers: %d", vhci_driver->ncontrollers);
 
@@ -285,7 +291,7 @@ int usbip_vhci_driver_open(void)
return 0;
 
 err:
-   udev_device_unref(vhci_driver->hc_device);
+   udev_device_unref(hc_device);
 
if (vhci_driver)
free(vhci_driver);
diff --git a/tools/usb/usbip/libsrc/vhci_driver.h 
b/tools/usb/usbip/libsrc/vhci_driver.h
index 418b404d51210..6c9aca2167051 100644
--- a/tools/usb/usbip/libsrc/vhci_driver.h
+++ b/tools/usb/usbip/libsrc/vhci_driver.h
@@ -13,7 +13,6 @@
 
 #define USBIP_VHCI_BUS_TYPE "platform"
 #define USBIP_VHCI_DEVICE_NAME "vhci_hcd.0"
-#define MAXNPORT 128
 
 enum hub_speed {
HUB_SPEED_HIGH = 0,
@@ -41,7 +40,7 @@ struct usbip_vhci_driver {
 
int ncontrollers;
int nports;
-   struct usbip_imported_device idev[MAXNPORT];
+   struct usbip_imported_device idev[];
 };
 
 
-- 
2.17.0

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

[PATCH net-next] qmi_wwan: apply SET_DTR quirk to the SIMCOM shared device ID

[Bjørn Mork]

SIMCOM are reusing a single device ID for many (all of their?)
different modems, based on different chipsets and firmwares. Newer
Qualcomm chipset generations require setting DTR to wake the QMI
function.  The SIM7600E modem is using such a chipset, making it
fail to work with this driver despite the device ID match.

Fix by unconditionally enabling the SET_DTR quirk for all SIMCOM
modems using this specific device ID.  This is similar to what
we already have done for another case of device IDs recycled over
multiple chipset generations: 14cf4a771b30 ("drivers: net: usb:
qmi_wwan: add QMI_QUIRK_SET_DTR for Telit PID 0x1201")

Initial testing on an older SIM7100 modem shows no immediate side
effects.

Reported-by: Sebastian Sjoholm 
Cc: Reinhard Speyerer 
Signed-off-by: Bjørn Mork 
---
I propose this for net-next for now to get some extra testing
exposure before going into stable.  I'll send a separate request
for stable backport as soon as I'm satisfied that there are no
hidden issues with some specific modem.


Bjørn 

 drivers/net/usb/qmi_wwan.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 42565dd33aa6..148e78f8b48c 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1248,7 +1248,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x03f0, 0x4e1d, 8)},/* HP lt4111 LTE/EV-DO/HSPA+ 
Gobi 4G Module */
{QMI_FIXED_INTF(0x03f0, 0x9d1d, 1)},/* HP lt4120 Snapdragon X5 LTE 
*/
{QMI_FIXED_INTF(0x22de, 0x9061, 3)},/* WeTelecom WPD-600N */
-   {QMI_FIXED_INTF(0x1e0e, 0x9001, 5)},/* SIMCom 7230E */
+   {QMI_QUIRK_SET_DTR(0x1e0e, 0x9001, 5)}, /* SIMCom 7100E, 7230E, 7600E 
++ */
{QMI_QUIRK_SET_DTR(0x2c7c, 0x0125, 4)}, /* Quectel EC25, EC20 R2.0  
Mini PCIe */
{QMI_QUIRK_SET_DTR(0x2c7c, 0x0121, 4)}, /* Quectel EC21 Mini PCIe */
{QMI_FIXED_INTF(0x2c7c, 0x0296, 4)},/* Quectel BG96 */
-- 
2.11.0

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

Re: Documentation On Gadget Drivers (g_ffs)

[Krzysztof Opasiak]

On 24.05.2018 07:11, R0b0t1 wrote:
> All that is in tree is ./Documentation/usb/functionfs.txt which I can
> not get the information I need from. I happened to find
> https://events.static.linuxfound.org/sites/events/files/slides/LinuxConNA-Make-your-own-USB-gadget-Andrzej.Pietrasiewicz.pdf,
> but the commands within did not work and I do not know how to
> troubleshoot.
> 

This may be useful for you:

https://archive.fosdem.org/2016/schedule/event/makeyourownusbdevice/

> I am trying to work on getting libusbg or libusbgx on my device. Is
> that the recommended method?

It depends what you would like to do. If legacy gadget is fine for you 
go ahead and use it.
If you would like to use ConfigFS (which is recommended for any new 
usage) libusbgx should help you a lot.

> 
> When using gadget drivers, how is the device-capable port specified if
> there is more than one?
> 

In ConfigFS it's UDC gadget attribute.

Best regards,
-- 
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

[RFC PATCH 2/3] USB: serial: enable serdev support

[Johan Hovold]

Enable serdev support by using the serdev opt-in tty-port registration
helpers.

FIXME: serdev core always allocates and registers a serdev controller
during port registration only to immediately roll back in the common
case when there is no serdev slave defined in firmware

FIXME: serdev does not support hotplugging (e.g. tty port hangups)

Not-signed-off-by: Johan Hovold 
---
 drivers/usb/serial/bus.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/serial/bus.c b/drivers/usb/serial/bus.c
index eb0195cf37dd..5f574a418c52 100644
--- a/drivers/usb/serial/bus.c
+++ b/drivers/usb/serial/bus.c
@@ -60,8 +60,9 @@ static int usb_serial_device_probe(struct device *dev)
}
 
minor = port->minor;
-   tty_dev = tty_port_register_device(>port, usb_serial_tty_driver,
-  minor, dev);
+   tty_dev = tty_port_register_device_serdev(>port,
+   usb_serial_tty_driver,
+   minor, dev);
if (IS_ERR(tty_dev)) {
retval = PTR_ERR(tty_dev);
goto err_port_remove;
@@ -105,7 +106,7 @@ static int usb_serial_device_remove(struct device *dev)
autopm_err = usb_autopm_get_interface(port->serial->interface);
 
minor = port->minor;
-   tty_unregister_device(usb_serial_tty_driver, minor);
+   tty_port_unregister_device(>port, usb_serial_tty_driver, minor);
 
driver = port->serial->type;
if (driver->port_remove)
-- 
2.17.0

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

[RFC PATCH 0/3] USB: serial: add device tree (and serdev) support

[Johan Hovold]

These are some patches I've been using to test out using serdev with USB
serial. Adding device-tree support to USB serial is really a
separate matter and could be merged before the remaining issues related
to hotplug are addressed for serdev.

Note that this has been a low-intensity on-going effort where most
prerequisites are already upstream including USB device tree support
(4.15), device-tree node sharing (4.13), musb device-node propagation
(linux-next) and various fixes along the way (driver core, usb core,
musb).

What left to be decided is how to deal with multi-port devices. This
series uses child nodes to represent each port, which may be a little
counter-intuitive for devices (or rather interfaces) with just a single
port:

_interface {
#address-cells = <1>;
#size-cells = <0>;

serial@0 {
reg = <0>;
};
};

but I still think this it how it needs to be implemented.

Another thing that's currently lacking is binding documentation.

For completeness (and per request), the second patch enables serdev
support and can be used for testing purposes. The third patch can be
used as a base for testing this on a BBB and describes two USB serial
devices attached to an external hub.

Note that this series depends on a couple of patches (for usb-serial and
musb) that are still in linux-next. For convenience, I've prepared a
branch here:


https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git/log/?h=usb-serial-of

Johan


Johan Hovold (3):
  USB: serial: add device-tree support
  USB: serial: enable serdev support
  dbg: ARM: dts: boneblack: add USB topology and serdev nodes

 arch/arm/boot/dts/am335x-boneblack.dts | 57 ++
 drivers/usb/serial/bus.c   |  7 ++--
 drivers/usb/serial/usb-serial.c| 28 -
 3 files changed, 88 insertions(+), 4 deletions(-)

-- 
2.17.0

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

[RFC PATCH 3/3] dbg: ARM: dts: boneblack: add USB topology and serdev nodes

[Johan Hovold]

Add a hub device and two USB devices, of which one has a combined node.

Note that we need to represent the serial ports as well -- consider
devices with multiple ports per interface; which one should serdev
use? Sibling devices can also be described this way (e.g. gpio@0), and
would need to use the same address size.

Also note that serial ports have a standardised node name in ePAPR.

Not-signed-off-by: Johan Hovold 
---
 arch/arm/boot/dts/am335x-boneblack.dts | 57 ++
 1 file changed, 57 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-boneblack.dts 
b/arch/arm/boot/dts/am335x-boneblack.dts
index d154d3133c16..d5f4c78efa53 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -26,3 +26,60 @@
opp-supported-hw = <0x06 0x0100>;
};
 };
+
+ {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   dlink_hub: hub@1 {
+   compatible = "usb2101,8501";
+   reg = <1>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ft232r: device@3 {
+   compatible = "usb403,6001";
+   reg = <3>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   serial@0 {
+   reg = <0>;
+
+   serdev {
+   compatible = "none,serdev-mockup";
+   };
+   };
+   };
+
+   mos7820: device@5 {
+   compatible = "usb9710,7840";
+   reg = <5>;
+
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   interface@0 {
+   compatible = "usbif9710,7840.config1.0";
+   reg = <0 1>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   serial@0 {
+   reg = <0>;
+
+   gnss {
+   compatible = "u-blox,neo-8";
+   };
+   };
+
+   serial@1 {
+   reg = <1>;
+   };
+   };
+   };
+   };
+};
-- 
2.17.0

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

[RFC PATCH 1/3] USB: serial: add device-tree support

[Johan Hovold]

Lookup and associate serial-port device-tree nodes given a parent
USB-interface node during probe.

Note that a serial-port node must be named "serial" and have a "reg"
property so that ports on multi-port interfaces can be distinguished.

_interface {
#address-cells = <1>;
#size-cells = <0>;

serial@0 {
reg = <0>;
};
};

FIXME: binding doc

Not-signed-off-by: Johan Hovold 
---
 drivers/usb/serial/usb-serial.c | 28 +++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c
index 44ecf0e2be9d..5a7ebe1e9fd6 100644
--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial/usb-serial.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define DRIVER_AUTHOR "Greg Kroah-Hartman "
 #define DRIVER_DESC "USB Serial Driver core"
@@ -97,7 +98,6 @@ static int allocate_minors(struct usb_serial *serial, int 
num_ports)
if (minor < 0)
goto error;
port->minor = minor;
-   port->port_number = i;
}
serial->minors_reserved = 1;
mutex_unlock(_lock);
@@ -589,6 +589,7 @@ static void usb_serial_port_release(struct device *dev)
kfifo_free(>write_fifo);
kfree(port->interrupt_in_buffer);
kfree(port->interrupt_out_buffer);
+   of_node_put(dev->of_node);
tty_port_destroy(>port);
kfree(port);
 }
@@ -857,6 +858,29 @@ static int setup_port_interrupt_out(struct usb_serial_port 
*port,
return 0;
 }
 
+/* FIXME: move to separate compilation unit? */
+static struct device_node *find_port_node(struct usb_interface *intf, int port)
+{
+   struct device_node *node;
+   u32 reg;
+
+   for_each_child_of_node(intf->dev.of_node, node) {
+   if (!node->name || of_node_cmp(node->name, "serial") != 0)
+   continue;
+
+   if (of_property_read_u32(node, "reg", ))
+   continue;
+
+   if (reg == port)
+   break;
+   }
+
+   dev_dbg(>dev, "node %pOF, port %d: %pOFP\n", intf->dev.of_node,
+   port, node);
+
+   return node;
+}
+
 static int usb_serial_probe(struct usb_interface *interface,
   const struct usb_device_id *id)
 {
@@ -963,6 +987,7 @@ static int usb_serial_probe(struct usb_interface *interface,
retval = -ENOMEM;
goto err_free_epds;
}
+   port->port_number = i;
tty_port_init(>port);
port->port.ops = _port_ops;
port->serial = serial;
@@ -976,6 +1001,7 @@ static int usb_serial_probe(struct usb_interface 
*interface,
port->dev.bus = _serial_bus_type;
port->dev.release = _serial_port_release;
port->dev.groups = usb_serial_port_groups;
+   port->dev.of_node = find_port_node(interface, 
port->port_number);
device_initialize(>dev);
}
 
-- 
2.17.0

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

Re: [RFT/PATCH 00/38] usb: dwc3: gadget: Rework & Refactoring

[Bin Liu]

Hi laurent,

On Thu, May 24, 2018 at 10:59:18PM +0300, Laurent Pinchart wrote:
> Hi Felipe,
> 
> On Friday, 20 April 2018 13:57:23 EEST Felipe Balbi wrote:
> > Bin Liu  writes:
> > >> Felipe Balbi  writes:
> > > Bin Liu  writes:
> > >> On Mon, Apr 09, 2018 at 02:26:14PM +0300, Felipe Balbi wrote:
> > >>> Hi guys,
> > >>> 
> > >>> I've been working on this series for a while now. I feels like
> > >>> after this series the transfer management code is far easier to
> > >>> read and understand.
> > >>> 
> > >>> Based on my tests, I have no regressions. Tested g_mass_storage
> > >>> and all of testusb's tests (including ISOC).
> > >>> 
> > >>> Patches are also available on dwc3-improve-isoc-endpoints in my
> > >>> k.org tree. Test reports would be VERY, VERY, VERY welcome. Please
> > >>> give this a go so we avoid regressions on v4.18.
> > >> 
> > >> Have you tested g_webcam? I just tested your
> > >> dwc3-improve-isoc-endpoints
> > > 
> > > for isoc I only tested g_zero.
> >  
> >  Then writting down details on what I observed probably won't help you
> >  :(
> > >> 
> > >> I got webcam running here, it sure _is_ helpful to let me know how you
> > > 
> > > Great!
> > > 
> > >> trigger the problem ;-) Also, high-speed or super-speed?
> > > 
> > > Both. Long story short - super-speed doesn't stream the yuv video,
> > > gadget side kernel prints "VS request completed with status -18."
> > > flooding messages.
> > > 
> > > high-speed does stream the video, but stopping the host application
> > > (both yavta and luvcview) causes gadget side kernel prints error message
> > > (I didn't keep the log). Then restart the host application doesn't
> > > stream the video any more.
> 
> What is your test platform ? I'm using a TI AM574x EVM and I can't get video 
> to stream at all in high-speed. Super-speed seems out of question as the only 
> port supporting device mode on that board is connect to a DWC3 instance that 
> is limited to high-speed :-/ I'm testing v4.17-rc5 without this patch series 
> applied, please let me know if I should apply it first.

It worked at the last time I tested it without this patch series, but
don't remember the kernel version I tested.

I will be offline for two weeks. I can test it again once I am back if
you are unable to get it working by then.

Regards,
-Bin.
--
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: Serdev: USB device and sysdev probing ala i2c

[Johan Hovold]

On Thu, May 24, 2018 at 07:38:41PM +0200, Ricardo Ribalda Delgado wrote:

> On Thu, May 24, 2018 at 6:49 PM Rob Herring  wrote:

> > The fundamental problem here is you need a parent device node to apply
> > a DT overlay to and a USB device hotplugged has no DT device node. The
> > system you are running on may not even have a DT (like a PC). If you
> > have an overlay of the downstream devices, they have to be a child of
> > something for the overlay to apply to. We could just create virtual
> > device nodes for the purposes of applying overlays to. Another option
> > would be allowing multiple DTs. Then you aren't even using overlays
> > (what's the point of an overlay when a system has no real DT to begin
> > with). That also would mean they are completely independent from any
> > real DT or other instances (you may want to plug in multiple of the
> > same device).
> 
> In my usecase the DT is way too overkilled. The previously mentioned
> echo tty > /sys/bus/serio/devices/serio0/unregister
> echo hci_nokia > /sys/bus/serio/devices/serio0/new_device
> 
> would be the most convenient way to use/experiment with serio.

Note is serio is something different from serdev (whose bus type is
named "serial").

> I am not taking into consideration hot pluggable devices. I am thinking
> about a use case where the usb2serial is soldered in the board.

For static setups like that, my USB serial device-tree patches would
solve your problem if only you were using device tree. ;)

But there's currently no way to register a serdev client from user
space, and adding support for that is not going to be trivial.

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

Re: Serdev: USB device and sysdev probing ala i2c

[Johan Hovold]

On Thu, May 24, 2018 at 11:49:24AM -0500, Rob Herring wrote:
> On Thu, May 24, 2018 at 7:18 AM, Ricardo Ribalda Delgado
>  wrote:
> > Hi Johan,
> >
> > On Thu, May 24, 2018 at 2:07 PM Johan Hovold  wrote:

> >> Serdev currently only supports device tree and ACPI. Using out-of-tree
> >> code, you could load a device tree fragment during runtime to describe
> >> your serial bus (or you just amend the device tree).
> >
> >> Using device tree overlays would have the benefit of being able to
> >> describe associated resources (e.g. reset gpios) which a simple
> >> compatible string (or equivalent) would not.
> >
> >> But there are examples where a simple compatible string would do, for
> >> example an existing CEC device presenting itself as a generic USB CDC
> >> device (hopefully with a dedicated VID/PID so that no user-space
> >> configuration is needed at all).
 
> The fundamental problem here is you need a parent device node to apply
> a DT overlay to and a USB device hotplugged has no DT device node. The
> system you are running on may not even have a DT (like a PC). If you
> have an overlay of the downstream devices, they have to be a child of
> something for the overlay to apply to. We could just create virtual
> device nodes for the purposes of applying overlays to. Another option
> would be allowing multiple DTs. Then you aren't even using overlays
> (what's the point of an overlay when a system has no real DT to begin
> with). That also would mean they are completely independent from any
> real DT or other instances (you may want to plug in multiple of the
> same device).

Right, there's more (than just a DT overlay loader) that needs to be in
place before this could be used for the generic hotplug case (and even
more than that if this was to be usable for ACPI systems).

I think generating DT nodes during enumeration is preferable to having
detached trees, if only to deal with the case where a loaded overlay do
overlap with the "real" static tree.

Another problem is that we need to deregister any tty device and
essentially reprobe the underlying serial controller whenever user space
tells us what can be found on the other end of wire in order to register
a serdev controller and device instead. IIRC this is something we would
get for free if using DT overlays (i.e. any device with a modified DT
node would get removed and readded, or at least notified that something
changed).

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

Re: Serdev: USB device and sysdev probing ala i2c

[Johan Hovold]

On Thu, May 24, 2018 at 02:18:57PM +0200, Ricardo Ribalda Delgado wrote:
> Hi Johan,
> 
> On Thu, May 24, 2018 at 2:07 PM Johan Hovold  wrote:
> 
> > Hi Ricardo,
> 
> > On Wed, May 23, 2018 at 11:17:20AM +0200, Ricardo Ribalda Delgado wrote:
> > > Hi
> > >
> > > I have a flash controller connected to the main computer via a usb to
> > > serial. My plan is to expose it to the system as a video4linux
> subdevice.
> > >
> > > With the inclusion of serdev I was expecting that it would be as easy as
> > > adding a i2c device, but seems that there are some functionality that
> it is
> > > still not implemented:
> > >
> > > 1) Serdev for usb serial devices.
> 
> > Right, I didn't want to enable serdev for USB serial before we have
> > determined how to handle hotplugging (e.g. in serdev core or by making
> > sure every serdev driver can handle devices going away at any time) in
> > order to avoid having things crash left and right.
> 
> > I have out-of-tree code for USB serial that I use for testing purposes,
> > so it's mostly a matter of finding the time to think this through.
> 
> Could you share those patches? I would love to test them.
> In my setup the system does not support hotplugg and/or power saving.

My serdev patches for USB serial amounts to adding device tree support
to USB serial and relying on the device tree support already in serdev.
So this will probably be of limited use to you who seems to be on an
ACPI system.

I've pushed a branch here nonetheless:


https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git/log/?h=usb-serial-of

in case anyone is interested.

USB serial device tree support is strictly separate from serdev so I
should probably finish that bit up without the final step to enable
serdev. I'll post the patches as an RFC as well, for Rob and others to
comment on.

Note that this has been a low-intensity on-going effort where most
prerequisites are already upstream including USB device tree support
(4.15), device-tree node sharing (4.13), musb device-node propagation
(linux-next) and various fixes along the way (driver core, usb core,
musb).

But again, serdev does not support hotplugging and specifically tty
hangups so you'll get some warnings if you disconnect a device when the
various open counts fails to add up as the port is shut down twice
(hangup + serdev close).

> > > 2) Instatiating via sysfs. Something like
> > > echo hci_nokia > /sys/bus/serio/devices/serio0/new_device
> > > (inspired in: echo eeprom 0x50 > /sys/bus/i2c/devices/i2c-3/new_device)
> 
> > Serdev currently only supports device tree and ACPI. Using out-of-tree
> > code, you could load a device tree fragment during runtime to describe
> > your serial bus (or you just amend the device tree).
> 
> > Using device tree overlays would have the benefit of being able to
> > describe associated resources (e.g. reset gpios) which a simple
> > compatible string (or equivalent) would not.
> 
> > But there are examples where a simple compatible string would do, for
> > example an existing CEC device presenting itself as a generic USB CDC
> > device (hopefully with a dedicated VID/PID so that no user-space
> > configuration is needed at all).
> 
> What about platform devices? Can it be instatiated like that?

Not sure I understand what you are after here.

> > > 3) Support for probing: Like hwmon for i2c
> 
> > What would you probe for (since there is no generic protocol for serial
> > devices)?
> 
> Just write to the device and expect something in return. I know it can be
> dangerous in most cases, but hey, this is how the modems are detected in
> userspace and works fine :).

Yeah, IIRC there's a long-standing open bug against those user space
daemons (ModemManager?) which try to mess with random ports that way.
I really don't think this is something we want to have in the kernel
either way.

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

[usb:usb-next 72/107] drivers/usb/host/xhci-mem.c:2250 xhci_create_rhub_port_array() error: potential null dereference 'rhub->ports'. (kcalloc returns null)

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next
head:   58c38116c6cc5bcb6d952ca72111a7a15d4604a2
commit: bcaa9d5c59005eceed5f2112c13240401f0fb93b [72/107] xhci: Create new 
structures to store xhci port information

New smatch warnings:
drivers/usb/host/xhci-mem.c:2250 xhci_create_rhub_port_array() error: potential 
null dereference 'rhub->ports'.  (kcalloc returns null)

Old smatch warnings:
drivers/usb/host/xhci-mem.c:2280 xhci_setup_port_arrays() error: potential null 
dereference 'xhci->hw_ports'.  (kcalloc returns null)

vim +2250 drivers/usb/host/xhci-mem.c

  2235  
  2236  static void xhci_create_rhub_port_array(struct xhci_hcd *xhci,
  2237  struct xhci_hub *rhub, gfp_t 
flags)
  2238  {
  2239  int port_index = 0;
  2240  int i;
  2241  
  2242  if (!rhub->num_ports)
  2243  return;
  2244  rhub->ports = kcalloc(rhub->num_ports, sizeof(rhub->ports), 
flags);
  2245  for (i = 0; i < HCS_MAX_PORTS(xhci->hcs_params1); i++) {
  2246  if (xhci->hw_ports[i].rhub != rhub ||
  2247  xhci->hw_ports[i].hcd_portnum == DUPLICATE_ENTRY)
  2248  continue;
  2249  xhci->hw_ports[i].hcd_portnum = port_index;
> 2250  rhub->ports[port_index] = >hw_ports[i];
  2251  port_index++;
  2252  if (port_index == rhub->num_ports)
  2253  break;
  2254  }
  2255  }
  2256  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: gadget: composite: fix delayed_status race condition when set_interface

[Chunfeng Yun]

It happens when enable debug log, if set_alt() returns
USB_GADGET_DELAYED_STATUS and usb_composite_setup_continue()
is called before increasing count of @delayed_status,
so fix it by using spinlock of @cdev->lock.

Signed-off-by: Chunfeng Yun 
Tested-by: Jay Hsu 
---
 drivers/usb/gadget/composite.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index f242c2b..d2fa071 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1719,6 +1719,8 @@ static int fill_ext_prop(struct usb_configuration *c, int 
interface, u8 *buf)
 */
if (w_value && !f->get_alt)
break;
+
+   spin_lock(>lock);
value = f->set_alt(f, w_index, w_value);
if (value == USB_GADGET_DELAYED_STATUS) {
DBG(cdev,
@@ -1728,6 +1730,7 @@ static int fill_ext_prop(struct usb_configuration *c, int 
interface, u8 *buf)
DBG(cdev, "delayed_status count %d\n",
cdev->delayed_status);
}
+   spin_unlock(>lock);
break;
case USB_REQ_GET_INTERFACE:
if (ctrl->bRequestType != (USB_DIR_IN|USB_RECIP_INTERFACE))
-- 
1.9.1

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

Re: [PATCH] usb: gadget: dwc2: fix memory leak in gadget_init()

[Minas Harutyunyan]

Acked-by: Minas Harutyunyan 

On 5/24/2018 6:22 PM, Grigor Tovmasyan wrote:
> Freed allocated request for ep0 to prevent memory leak in case when
> dwc2_driver_probe() failed.
> 
> Signed-off-by: Grigor Tovmasyan 
> Cc: Stefan Wahren 
> Cc: Marek Szyprowski 
> ---
>   drivers/usb/dwc2/gadget.c | 7 +--
>   1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index f0d9ccf1d665..7ccf56da1e50 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -4739,9 +4739,11 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg)
>   }
>   
>   ret = usb_add_gadget_udc(dev, >gadget);
> - if (ret)
> + if (ret) {
> + dwc2_hsotg_ep_free_request(>eps_out[0]->ep,
> +hsotg->ctrl_req);
>   return ret;
> -
> + }
>   dwc2_hsotg_dump(hsotg);
>   
>   return 0;
> @@ -4755,6 +4757,7 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg)
>   int dwc2_hsotg_remove(struct dwc2_hsotg *hsotg)
>   {
>   usb_del_gadget_udc(>gadget);
> + dwc2_hsotg_ep_free_request(>eps_out[0]->ep, hsotg->ctrl_req);
>   
>   return 0;
>   }
> 

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

[PATCH v5] usb: gadget: udc: renesas_usb3: Add register of usb role switch

[Yoshihiro Shimoda]

This patch adds role switch support for R-Car SoCs into the USB 3.0
peripheral driver. Some R-Car SoCs (e.g. R-Car H3) have USB 3.0
dual-role device controller which has the USB 3.0 xHCI host and
Renesas USB 3.0 peripheral.

Unfortunately, the mode change register (DRD_CON) contains
the USB 3.0 peripheral controller side only. So, this renesas_usb3
driver manages the DRD_CON now. However, in peripheral mode, the host
should stop. Also the host hardware needs to reinitialize its own
registers when the mode changes from peripheral to host mode.
Otherwise, the host cannot work correctly (e.g. detect a device
as high-speed).

To achieve this reinitialization by a driver, this driver also
registers a role switch driver to manage the DRD_CON and get
a device pointer of usb 3.0 host from "companion" property of OF.
Then, when the usb role is changed, renesas_usb3_role_switch_set()
will attach/release the xhci-plat driver to reinitialize the host
hardware.

Signed-off-by: Yoshihiro Shimoda 
---
This patch set is based on Felipe's usb.git / testing/next branch
(commit id = 47265c067c0d129f3a0e94bc221293a780af9d78).

I remove RFC on this v5 patch because it's simple and acceptable
for upstream, I think :)

Changes from RFC v4:
 - Use "companion" device tree property simply instead of device_connection
   APIs with OF graph.
 - Merge patch 2 and 3 to one.
 - Revise the commit log (I should had revised this on RFC v4 though).

Changes from RFC v3:
 - Rebase latest usb.git / testing/next branch.
 - Add graph parse into device_connection_find_match().
 - Use workqueue to call _usb3_set_mode() in patch 3.
   (I realized renesas_usb3_role_switch_set() cannot run on atomic because
device_attach() might sleep.)

Changes from RFC v2:
 - Add registering usb role switch into drivers/usb/gadget/udc/renesas_usb3
   because hardware resource (a register) is shared and remove individual
   usb role switch driver/dt-bindings for R-Car.
 - Remove "usb_role_switch_get_by_graph" API because the renesas_usb3 driver
   doesn't need such API now.

Changes from RFC:
 - Remove "device-connection-id" and "usb role switch driver" dt-bingings.
 - Remove drivers/of code.
 - Add a new API for find the connection by using graph on devcon.c and roles.c.
 - Use each new API on the rcar usb role switch and renesas_usb3 drivers.
 - Update the dtsi file for r8a7795.

 drivers/usb/gadget/udc/Kconfig|  1 +
 drivers/usb/gadget/udc/renesas_usb3.c | 84 ++-
 2 files changed, 84 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index b838cae..78823cd 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -193,6 +193,7 @@ config USB_RENESAS_USB3
tristate 'Renesas USB3.0 Peripheral controller'
depends on ARCH_RENESAS || COMPILE_TEST
depends on EXTCON && HAS_DMA
+   select USB_ROLE_SWITCH
help
   Renesas USB3.0 Peripheral controller is a USB peripheral controller
   that supports super, high, and full speed USB 3.0 data transfers.
diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
b/drivers/usb/gadget/udc/renesas_usb3.c
index 5caf78b..c1a1824 100644
--- a/drivers/usb/gadget/udc/renesas_usb3.c
+++ b/drivers/usb/gadget/udc/renesas_usb3.c
@@ -23,6 +23,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 /* register definitions */
 #define USB3_AXI_INT_STA   0x008
@@ -335,6 +337,11 @@ struct renesas_usb3 {
struct phy *phy;
struct dentry *dentry;
 
+   struct usb_role_switch *role_sw;
+   struct device *host_dev;
+   struct work_struct role_work;
+   enum usb_role role;
+
struct renesas_usb3_ep *usb3_ep;
int num_usb3_eps;
 
@@ -651,7 +658,15 @@ static void usb3_check_vbus(struct renesas_usb3 *usb3)
}
 }
 
-static void usb3_set_mode(struct renesas_usb3 *usb3, bool host)
+static void renesas_usb3_role_work(struct work_struct *work)
+{
+   struct renesas_usb3 *usb3 = container_of(work, struct renesas_usb3,
+role_work);
+
+   usb_role_switch_set_role(usb3->role_sw, usb3->role);
+}
+
+static void _usb3_set_mode(struct renesas_usb3 *usb3, bool host)
 {
if (host)
usb3_clear_bit(usb3, DRD_CON_PERI_CON, USB3_DRD_CON);
@@ -659,6 +674,16 @@ static void usb3_set_mode(struct renesas_usb3 *usb3, bool 
host)
usb3_set_bit(usb3, DRD_CON_PERI_CON, USB3_DRD_CON);
 }
 
+static void usb3_set_mode(struct renesas_usb3 *usb3, bool host)
+{
+   if (usb3->role_sw) {
+   usb3->role = host ? USB_ROLE_HOST : USB_ROLE_DEVICE;
+   schedule_work(>role_work);
+   } else {
+   _usb3_set_mode(usb3, host);
+   }
+}
+
 static void usb3_vbus_out(struct renesas_usb3 *usb3, bool enable)
 {
if (enable)
@@ -2302,6 +2327,41 @@ static int renesas_usb3_set_selfpowered(struct 

Re: [PATCH] usb: hub: Per-port setting to use old enumeration scheme

[Greg Kroah-Hartman]

On Wed, May 23, 2018 at 10:16:56AM +0800, Nicolas Boichat wrote:
> The "old" enumeration scheme is considerably faster (it takes
> ~294ms instead of ~439ms to get the descriptor).
> 
> It is currently only possible to use the old scheme globally
> (/sys/module/usbcore/parameters/old_scheme_first), which is not
> desirable as the new scheme was introduced to increase compatibility
> with more devices.
> 
> However, in our case, we care about time-to-active for a specific
> USB device (which we make the firmware for), on a specific port
> (that is pogo-pin based: not a standard USB port). This new
> sysfs option makes it possible to use the old scheme on a single
> port only.
> 
> Signed-off-by: Nicolas Boichat 
> ---
> 
> There are other "quirks" that we could add to reduce further
> enumeration time (e.g. reduce USB debounce time, reduce TRSTRCY
> to 10ms instead of 50ms as used currently), but the logic is quite
> similar, so it'd be good to have this reviewed first.
> 
>  drivers/usb/core/hub.c  | 13 +
>  drivers/usb/core/hub.h  |  1 +
>  drivers/usb/core/port.c | 23 +++
>  include/linux/usb.h |  7 +++
>  4 files changed, 40 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index c2d993d3816f0..f900f66a62856 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -2636,7 +2636,7 @@ static unsigned hub_is_wusb(struct usb_hub *hub)
>  #define SET_ADDRESS_TRIES2
>  #define GET_DESCRIPTOR_TRIES 2
>  #define SET_CONFIG_TRIES (2 * (use_both_schemes + 1))
> -#define USE_NEW_SCHEME(i)((i) / 2 == (int)old_scheme_first)
> +#define USE_NEW_SCHEME(i, scheme)((i) / 2 == (int)scheme)
>  
>  #define HUB_ROOT_RESET_TIME  60  /* times are in msec */
>  #define HUB_SHORT_RESET_TIME 10
> @@ -2651,12 +2651,16 @@ static unsigned hub_is_wusb(struct usb_hub *hub)
>   * enumeration failures, so disable this enumeration scheme for USB3
>   * devices.
>   */
> -static bool use_new_scheme(struct usb_device *udev, int retry)
> +static bool use_new_scheme(struct usb_device *udev, int retry,
> +struct usb_port *port_dev)
>  {
> + int old_scheme_first_port =
> + port_dev->quirks & USB_PORT_QUIRK_OLD_SCHEME;
> +
>   if (udev->speed >= USB_SPEED_SUPER)
>   return false;
>  
> - return USE_NEW_SCHEME(retry);
> + return USE_NEW_SCHEME(retry, old_scheme_first_port || old_scheme_first);
>  }
>  
>  /* Is a USB 3.0 port in the Inactive or Compliance Mode state?
> @@ -4392,6 +4396,7 @@ hub_port_init(struct usb_hub *hub, struct usb_device 
> *udev, int port1,
>  {
>   struct usb_device   *hdev = hub->hdev;
>   struct usb_hcd  *hcd = bus_to_hcd(hdev->bus);
> + struct usb_port *port_dev = hub->ports[port1 - 1];
>   int retries, operations, retval, i;
>   unsigneddelay = HUB_SHORT_RESET_TIME;
>   enum usb_device_speed   oldspeed = udev->speed;
> @@ -4513,7 +4518,7 @@ hub_port_init(struct usb_hub *hub, struct usb_device 
> *udev, int port1,
>   for (retries = 0; retries < GET_DESCRIPTOR_TRIES; (++retries, 
> msleep(100))) {
>   bool did_new_scheme = false;
>  
> - if (use_new_scheme(udev, retry_counter)) {
> + if (use_new_scheme(udev, retry_counter, port_dev)) {
>   struct usb_device_descriptor *buf;
>   int r = 0;
>  
> diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
> index 4dc769ee9c740..4accfb63f7dcb 100644
> --- a/drivers/usb/core/hub.h
> +++ b/drivers/usb/core/hub.h
> @@ -98,6 +98,7 @@ struct usb_port {
>   struct mutex status_lock;
>   u32 over_current_count;
>   u8 portnum;
> + u32 quirks;
>   unsigned int is_superspeed:1;
>   unsigned int usb3_lpm_u1_permit:1;
>   unsigned int usb3_lpm_u2_permit:1;
> diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
> index 6979bde87d310..4a21431953953 100644
> --- a/drivers/usb/core/port.c
> +++ b/drivers/usb/core/port.c
> @@ -50,6 +50,28 @@ static ssize_t over_current_count_show(struct device *dev,
>  }
>  static DEVICE_ATTR_RO(over_current_count);
>  
> +static ssize_t quirks_show(struct device *dev,
> +struct device_attribute *attr, char *buf)
> +{
> + struct usb_port *port_dev = to_usb_port(dev);
> +
> + return sprintf(buf, "%08x\n", port_dev->quirks);
> +}
> +
> +static ssize_t quirks_store(struct device *dev, struct device_attribute 
> *attr,
> + const char *buf, size_t count)
> +{
> + struct usb_port *port_dev = to_usb_port(dev);
> + u32 value;
> +
> + if (kstrtou32(buf, 16, ))
> + return -EINVAL;
> +
> + port_dev->quirks = value;
> + return count;
> +}
> +static DEVICE_ATTR_RW(quirks);
> +
>  static ssize_t usb3_lpm_permit_show(struct device *dev,
> struct 

Re: [PATCH] usb: hub: Per-port setting to use old enumeration scheme

[Greg Kroah-Hartman]

On Fri, May 25, 2018 at 06:05:16AM +0800, Nicolas Boichat wrote:
> On Fri, May 25, 2018 at 12:21 AM, Greg Kroah-Hartman
>  wrote:
> > On Thu, May 24, 2018 at 07:42:00AM +0800, Nicolas Boichat wrote:
> >> On Thu, May 24, 2018 at 12:39 AM, Greg Kroah-Hartman
> >>  wrote:
> >> > On Wed, May 23, 2018 at 10:03:55AM -0400, Alan Stern wrote:
> >> >> On Wed, 23 May 2018, Nicolas Boichat wrote:
> >> >>
> >> >> > The "old" enumeration scheme is considerably faster (it takes
> >> >> > ~294ms instead of ~439ms to get the descriptor).
> >> >> >
> >> >> > It is currently only possible to use the old scheme globally
> >> >> > (/sys/module/usbcore/parameters/old_scheme_first), which is not
> >> >> > desirable as the new scheme was introduced to increase compatibility
> >> >> > with more devices.
> >> >> >
> >> >> > However, in our case, we care about time-to-active for a specific
> >> >> > USB device (which we make the firmware for), on a specific port
> >> >> > (that is pogo-pin based: not a standard USB port). This new
> >> >> > sysfs option makes it possible to use the old scheme on a single
> >> >> > port only.
> >> >> >
> >> >> > Signed-off-by: Nicolas Boichat 
> >> >> > ---
> >> >> >
> >> >> > There are other "quirks" that we could add to reduce further
> >> >> > enumeration time (e.g. reduce USB debounce time, reduce TRSTRCY
> >> >> > to 10ms instead of 50ms as used currently), but the logic is quite
> >> >> > similar, so it'd be good to have this reviewed first.
> >> >>
> >> >> I'm not opposed to the idea in principle, although I don't like your
> >> >> implementation because it breaks the original old_scheme_first
> >> >> parameter.
> >>
> >> I don't think it breaks the original parameter? I mean,
> >> /sys/module/usbcore/parameters/old_scheme_first is still a global
> >> default, while bit 0 of /sys/bus/usb/devices/x/y/z/quirks becomes a
> >> port-specific override.
> >>
> >> >> Let's see what some other people think.
> >> >>
> >> >> Yours is a rather special case, because you know exactly what device
> >> >> will be attached to a specific port.  Still, I can see that sort of
> >> >> thing happening in constrained and special-purpose settings.
> >> >>
> >> >> How do you arrange to set the new quirk before the device is
> >> >> discovered?
> >> >
> >> > Yeah, this last question is what I had when looking at this.  Or does it
> >> > not matter at first boot and only matters for wake-up?
> >>
> >> It does not matter on boot, we have plenty of time to enumerate the
> >> device. We use USB (auto-)suspend and remote wake, so no
> >> re-enumeration there either. It only matters on unplug/replug where
> >> the device needs to be re-enumerated.
> >
> > How does this device get unplugged/replugged if it is connected directly
> > to the device?
> 
> It is external. Essentially, this is a tablet with a detachable
> keyboard/touchpad. The interface between tablet and base is USB, over
> pogo pins. The port is non-standard (pogo, not normal USB), and we
> fully control the firmware on the base side as well, which allows us
> to take shortcuts like this: we know exactly what device will be
> connected on that port.

Ah, ok, that makes more sense, thanks for the explanation.  I'll go
queue this up in a bit.

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

Re: [PATCH] usb: gadget: dwc2: fix memory leak in gadget_init()

[Stefan Wahren]

Hi Grigor,

> Grigor Tovmasyan  hat am 24. Mai 2018 um 16:22 
> geschrieben:
> 
> 
> Freed allocated request for ep0 to prevent memory leak in case when
> dwc2_driver_probe() failed.
> 
> Signed-off-by: Grigor Tovmasyan 
> Cc: Stefan Wahren 
> Cc: Marek Szyprowski 

currently i don't much time, but at least my tests with Raspberry Pi Zero W 
were successful.

Tested-by: Stefan Wahren 

It would be nice if you can setup some real testing devices at Synopsys in 
order to identify such regressions faster. kernelci.org only tests the host 
role of the Raspberry Pi.

Thanks
Stefan

> ---
>  drivers/usb/dwc2/gadget.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index f0d9ccf1d665..7ccf56da1e50 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -4739,9 +4739,11 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg)
>   }
>  
>   ret = usb_add_gadget_udc(dev, >gadget);
> - if (ret)
> + if (ret) {
> + dwc2_hsotg_ep_free_request(>eps_out[0]->ep,
> +hsotg->ctrl_req);
>   return ret;
> -
> + }
>   dwc2_hsotg_dump(hsotg);
>  
>   return 0;
> @@ -4755,6 +4757,7 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg)
>  int dwc2_hsotg_remove(struct dwc2_hsotg *hsotg)
>  {
>   usb_del_gadget_udc(>gadget);
> + dwc2_hsotg_ep_free_request(>eps_out[0]->ep, hsotg->ctrl_req);
>  
>   return 0;
>  }
> -- 
> 2.11.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html