Re: [PATCH 0/2] Allow xhci-plat using a second clock

[Mathias Nyman]

On 18.04.2018 17:20, Gregory CLEMENT wrote:

Hi Mathias,
  
  On mer., févr. 14 2018, Gregory CLEMENT  wrote:



Hello,

The purpose of this series is to allow xhci-plat using a second
clock. It is needed on the Armada 7K/8K but could be used by other
SoCs.

The first patch is just a fix found while I was working on this
feature.


I've just realized that this series sent 2 months ago was not merged in
v4.17. The issue is that now the USB support on the Armada 7K/8K is
broken, because the clock support part was already merged.

You already had a look on this series one month ago. The issue you had
was about getting an approval for the extension of the binding [1]. I
pinged Rob about it [2] one month ago but we didn't get any
feedback. However, Rob already approved the similar changes I introduced
in an other for mv_xor_v2: [3].

So would it be possible to apply this series on v4.17-rc ?


Patch 2/2 no longer applies due to clk suspend/resume changes in:

commit d56e57ca030c8b4296944a2ae61ac167bf979c07
usb: host: xhci-plat: revert "usb: host: xhci-plat: enable clk in resume 
timing"

Not sure how that change affects Armada 7K/8K
Can you rebase and resend the series?

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

[RESEND v8 1/2] usb/gadget: Constify usb_gadget_get_string "table" argument

[Benjamin Herrenschmidt]

The table is never modified by the function. This allows us
to use it on a statically defined table that is marked const.

Signed-off-by: Benjamin Herrenschmidt 
---
 drivers/usb/gadget/usbstring.c | 2 +-
 include/linux/usb/gadget.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/usbstring.c b/drivers/usb/gadget/usbstring.c
index 566ab261e8b7..7c24d1ce1088 100644
--- a/drivers/usb/gadget/usbstring.c
+++ b/drivers/usb/gadget/usbstring.c
@@ -33,7 +33,7 @@
  * characters (which are also widely used in C strings).
  */
 int
-usb_gadget_get_string (struct usb_gadget_strings *table, int id, u8 *buf)
+usb_gadget_get_string (const struct usb_gadget_strings *table, int id, u8 *buf)
 {
struct usb_string   *s;
int len;
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index e3424234b23a..64e7c159d534 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -763,7 +763,7 @@ struct usb_gadget_string_container {
 };
 
 /* put descriptor for string with that id into buf (buflen >= 256) */
-int usb_gadget_get_string(struct usb_gadget_strings *table, int id, u8 *buf);
+int usb_gadget_get_string(const struct usb_gadget_strings *table, int id, u8 
*buf);
 
 /*-*/
 
-- 
2.14.3

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

[RESEND v8 2/2] usb/gadget: Add driver for Aspeed SoC virtual hub

[Benjamin Herrenschmidt]

The Aspeed BMC SoCs support a "virtual hub" function. It provides some
HW support for a top-level USB2 hub behind which sit 5 gadget "ports".

This driver adds support for the full functionality, emulating the
hub standard requests and exposing 5 UDC gadget drivers corresponding
to the ports.

The hub itself has HW provided dedicated EP0 and EP1 (the latter for
hub interrupts). It also has dedicated EP0s for each function. For
other endpoints, there's a pool of 15 "generic" endpoints that are
shared among the ports.

The driver relies on my previous patch adding a "dispose" EP op to
handle EP allocation between ports. EPs are allocated from the shared
pool in the UDC "match_ep" callback and assigned to the UDC instance
(added to the gadget ep_list).

When the composite driver gets unbound, the new hook will allow the UDC
to clean things up and return those EPs to the shared pool.

Signed-off-by: Benjamin Herrenschmidt 
---
v8. - Rework ast_vhub_rep_desc() to avoid incorrect built error
  when fortify is enabled
- Rework ast_vhub_rep_string() to use usb_gadget_get_string()
  instead of a local copy of ascii2desc
- Whitespace fixes

v7. - Fix OF match list
- Remove unused variable in hub code

v6. - Fix bug with 0-length packets on IN endpoints in desc mode

v5. - Remove #ifdef's and hard coded values
- Remove module parameters
- Honor maximum speed device-tree property
- Remove useless list_empty test
- Cosmetic/spaces fixes
- Add SPDX licence identifiers

v4. - Fix missing unlock ast_vhub_udc_wakeup() error path
- Make "irq" signed to deal with error from platform_get_irq
- Fix Makefile for module builds
- Fix a missing endian conversion

v3. - Rebased
- Add clk stuff

v2. - Cosmetic fixes
- Properly "allocate" device addresses instead of using a never
  reset counter
- Move .dtsi updates to a different patch
---
 drivers/usb/gadget/udc/Kconfig  |   2 +
 drivers/usb/gadget/udc/Makefile |   1 +
 drivers/usb/gadget/udc/aspeed-vhub/Kconfig  |   7 +
 drivers/usb/gadget/udc/aspeed-vhub/Makefile |   4 +
 drivers/usb/gadget/udc/aspeed-vhub/core.c   | 422 ++
 drivers/usb/gadget/udc/aspeed-vhub/dev.c| 580 +++
 drivers/usb/gadget/udc/aspeed-vhub/ep0.c| 478 
 drivers/usb/gadget/udc/aspeed-vhub/epn.c| 843 
 drivers/usb/gadget/udc/aspeed-vhub/hub.c| 819 +++
 drivers/usb/gadget/udc/aspeed-vhub/vhub.h   | 514 +
 10 files changed, 3670 insertions(+)
 create mode 100644 drivers/usb/gadget/udc/aspeed-vhub/Kconfig
 create mode 100644 drivers/usb/gadget/udc/aspeed-vhub/Makefile
 create mode 100644 drivers/usb/gadget/udc/aspeed-vhub/core.c
 create mode 100644 drivers/usb/gadget/udc/aspeed-vhub/dev.c
 create mode 100644 drivers/usb/gadget/udc/aspeed-vhub/ep0.c
 create mode 100644 drivers/usb/gadget/udc/aspeed-vhub/epn.c
 create mode 100644 drivers/usb/gadget/udc/aspeed-vhub/hub.c
 create mode 100644 drivers/usb/gadget/udc/aspeed-vhub/vhub.h

diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index 0875d38476ee..b838cae1 100644
--- a/drivers/usb/gadget/udc/Kconfig
+++ b/drivers/usb/gadget/udc/Kconfig
@@ -438,6 +438,8 @@ config USB_GADGET_XILINX
  dynamically linked module called "udc-xilinx" and force all
  gadget drivers to also be dynamically linked.
 
+source "drivers/usb/gadget/udc/aspeed-vhub/Kconfig"
+
 #
 # LAST -- dummy/emulated controller
 #
diff --git a/drivers/usb/gadget/udc/Makefile b/drivers/usb/gadget/udc/Makefile
index ce865b129fd6..897f648f3cf1 100644
--- a/drivers/usb/gadget/udc/Makefile
+++ b/drivers/usb/gadget/udc/Makefile
@@ -39,4 +39,5 @@ obj-$(CONFIG_USB_MV_U3D)  += mv_u3d_core.o
 obj-$(CONFIG_USB_GR_UDC)   += gr_udc.o
 obj-$(CONFIG_USB_GADGET_XILINX)+= udc-xilinx.o
 obj-$(CONFIG_USB_SNP_UDC_PLAT) += snps_udc_plat.o
+obj-$(CONFIG_USB_ASPEED_VHUB)  += aspeed-vhub/
 obj-$(CONFIG_USB_BDC_UDC)  += bdc/
diff --git a/drivers/usb/gadget/udc/aspeed-vhub/Kconfig 
b/drivers/usb/gadget/udc/aspeed-vhub/Kconfig
new file mode 100644
index ..f0cdf89b8503
--- /dev/null
+++ b/drivers/usb/gadget/udc/aspeed-vhub/Kconfig
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0+
+config USB_ASPEED_VHUB
+   tristate "Aspeed vHub UDC driver"
+   depends on ARCH_ASPEED || COMPILE_TEST
+   help
+ USB peripheral controller for the Aspeed AST2500 family
+ SoCs supporting the "vHub" functionality and USB2.0
diff --git a/drivers/usb/gadget/udc/aspeed-vhub/Makefile 
b/drivers/usb/gadget/udc/aspeed-vhub/Makefile
new file mode 100644
index ..9f3add605f8e
--- /dev/null
+++ b/drivers/usb/gadget/udc/aspeed-vhub/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0+
+obj-$(CONFIG_USB_ASPEED_VHUB)  += aspeed-vhub.o
+aspeed-vhub-y  := core.o ep0.o epn.o dev.o hub.o
+
diff --git 

[PATCH] USB: Increment wakeup count on remote wakeup.

[Ravi Chandra Sadineni]

On chromebooks we depend on wakeup count to identify the wakeup source.
But currently USB devices do not increment the wakeup count when they
trigger the remote wake. This patch addresses the same.

Resume condition is reported differently on USB 2.0 and USB 3.0 devices.

On USB 2.0 devices, a wake capable device, if wake enabled, drives
resume signal to indicate a remote wake (USB 2.0 spec section 7.1.7.7).
The upstream facing port then sets C_PORT_SUSPEND bit and reports a
port change event (USB 2.0 spec section 11.24.2.7.2.3). Thus if a port
has resumed before driving the resume signal from the host and
C_PORT_SUSPEND is set, then the device attached to the given port might
be the reason for the last system wakeup. Increment the wakeup count for
the same.

On USB 3.0 devices, a function may signal that it wants to exit from device
suspend by sending a Function Wake Device Notification to the host (USB3.0
spec section 8.5.6.4) Thus on receiving the Function Wake, increment the
wakeup count.

Signed-off-by: ravisadin...@chromium.org
---
 drivers/usb/core/hcd.c |  1 +
 drivers/usb/core/hub.c | 12 ++--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 777036ae63674..79f95a878fb6e 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2375,6 +2375,7 @@ void usb_hcd_resume_root_hub (struct usb_hcd *hcd)
 {
unsigned long flags;
 
+   pm_wakeup_event(dev, 0);
spin_lock_irqsave (_root_hub_lock, flags);
if (hcd->rh_registered) {
set_bit(HCD_FLAG_WAKEUP_PENDING, >flags);
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index f6ea16e9f6bb9..6abc5be1bcbf5 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -653,12 +653,17 @@ void usb_wakeup_notification(struct usb_device *hdev,
unsigned int portnum)
 {
struct usb_hub *hub;
+   struct usb_port *port_dev;
 
if (!hdev)
return;
 
hub = usb_hub_to_struct_hub(hdev);
if (hub) {
+   port_dev = hub->ports[portnum - 1];
+   if (port_dev && port_dev->child)
+   pm_wakeup_event(_dev->child->dev, 0);
+
set_bit(portnum, hub->wakeup_bits);
kick_hub_wq(hub);
}
@@ -3432,10 +3437,13 @@ int usb_port_resume(struct usb_device *udev, 
pm_message_t msg)
 
usb_lock_port(port_dev);
 
-   /* Skip the initial Clear-Suspend step for a remote wakeup */
status = hub_port_status(hub, port1, , );
-   if (status == 0 && !port_is_suspended(hub, portstatus))
+   /* Skip the initial Clear-Suspend step for a remote wakeup */
+   if (status == 0 && !port_is_suspended(hub, portstatus)) {
+   if (portchange & USB_PORT_STAT_C_SUSPEND)
+   pm_wakeup_event(>dev, 0);
goto SuspendCleared;
+   }
 
/* see 7.1.7.7; affects power usage, but not budgeting */
if (hub_is_superspeed(hub->hdev))
-- 
2.13.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

[PATCH 3/3] usb: musb: host: fix potential NULL pointer dereference

[Bin Liu]

musb_start_urb() doesn't check the 3rd pass-in parameter if it is NULL.
But in musb_bulk_nak_timeout() the parameter passed to musb_start_urb()
is returned from first_qh(), which could be NULL.

So wrap the musb_start_urb() call here with a if condition check to
avoid the potential NULL pointer dereference.

Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_host.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index e50438ae241e..218aadef5bbf 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -990,7 +990,9 @@ static void musb_bulk_nak_timeout(struct musb *musb, struct 
musb_hw_ep *ep,
/* set tx_reinit and schedule the next qh */
ep->tx_reinit = 1;
}
-   musb_start_urb(musb, is_in, next_qh);
+
+   if (next_qh)
+   musb_start_urb(musb, is_in, next_qh);
}
 }
 
-- 
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/3] usb: musb: gadget: fix to_musb_request() to not return NULL

[Bin Liu]

The gadget function drivers should ensure the usb_request parameter
passed in is not NULL. UDC core doesn't check if it is NULL, so MUSB
driver shouldn't have to check it either.

Convert to_musb_request() to a simple macro to not directly return NULL
to avoid warnings from code static analysis tools.

Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_gadget.h | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/usb/musb/musb_gadget.h b/drivers/usb/musb/musb_gadget.h
index 9c34aca06db6..466877b471ef 100644
--- a/drivers/usb/musb/musb_gadget.h
+++ b/drivers/usb/musb/musb_gadget.h
@@ -60,10 +60,7 @@ struct musb_request {
enum buffer_map_state map_state;
 };
 
-static inline struct musb_request *to_musb_request(struct usb_request *req)
-{
-   return req ? container_of(req, struct musb_request, request) : NULL;
-}
+#define to_musb_request(r) (container_of(r, struct musb_request, request))
 
 extern struct usb_request *
 musb_alloc_request(struct usb_ep *ep, gfp_t 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 2/3] usb: musb: gadget: fix to_musb_ep() to not return NULL

[Bin Liu]

UDC core ensures the usb_ep parameter passed in is not NULL, so
checking if (ep != NULL) is pointless.

Convert to_musb_ep() to a simple macro to not directly return NULL to
avoid warnings from code static analysis tools.

Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_gadget.h | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/usb/musb/musb_gadget.h b/drivers/usb/musb/musb_gadget.h
index 466877b471ef..aaae24bb3c10 100644
--- a/drivers/usb/musb/musb_gadget.h
+++ b/drivers/usb/musb/musb_gadget.h
@@ -96,10 +96,7 @@ struct musb_ep {
u8  hb_mult;
 };
 
-static inline struct musb_ep *to_musb_ep(struct usb_ep *ep)
-{
-   return ep ? container_of(ep, struct musb_ep, end_point) : NULL;
-}
+#define to_musb_ep(ep) (container_of(ep, struct musb_ep, end_point))
 
 static inline struct musb_request *next_request(struct musb_ep *ep)
 {
-- 
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 v6 0/6] usb/core/phy fixes for v4.17

[Martin Blumenstingl]

This is a follow-up to my previous series "initialize (multiple) PHYs
for a HCD": [0].

Roger Quadros reported [1] that it "is breaking low power cases on TI
SoCs when USB is in host mode". He further explains that "Not doing the
phy_exit() here [when entering suspend] leaves the clocks enabled on
our SoC and we're no longer able to reach low power states on system
suspend."
Chunfeng Yun from Mediatek noted [2] that we cannot unconditionally call
phy_exit while entering system suspend, because this would "disconnect
plugged devices on MTK platforms, due to re-initialize u2 phys when
resume"

In the discussion (which followed Roger's bug report: [1]) Roger,
Chunfeng and me came to the conclusion that we can fix suspend on the
TI SoCs without breaking it on the Mediatek SoCs by extending the
suspend and resume code in usb/core/phy.c by checking whether the USB
controller can wake up the system (which is the case for the Mediatek
MTU3 controller, but now for the dwc3 controller used on the TI SoCs):
- if the controller can wake up the system (Mediatek MTU3 use-case) we
  only call usb_phy_roothub_power_off (which calls phy_power_off) when
  entering system suspend
- if the controller however cannot wake up the system (dwc3 on TI SoCs)
  we additionally call usb_phy_roothub_exit (which calls phy_exit) when
  entering system suspend
- (we undo the previous steps during system resume)

The goal of this series is to fix the issue reported by Roger without
breaking suspend/resume on the Mediatek SoCs.
Since I neither have a TI nor a Mediatek device I am sending this as
RFC. I have tested it on an Amlogic Meson GXM board (Khadas VIM2) which
does NOT support suspend/resume yet.

Additionally Stefan Wahren reported [7] that booting on a Raspberry Pi
with CONFIG_GENERIC_PHY being disabled (which is the case for
bcm2835_defconfig) breaks USB. A fix for this is also included.


changes since v5 at [9]
- rebased on top of v4.17-rc1
- added Keerthy's Tested-by to the first three patches (thank you!)
- fixed a checkpatch warning (which was introduced in v4.17-rc1's
  checkpatch.pl) in patch #6 by using "/* SPDX-License-Identifier"
  instead of "// SPDX-License-Identifier"

changes since v4 at [8]
- updated series title since it now includes fixes for other
  functionality than suspend
- rebased on top of f8cf2f16a7c95a from Linus' tree -> I will re-send
  an updated version once v4.17-rc1 is out, I just sent it early to
  get some feedback early!
- included patch [3] "usb: core: phy: fix return value of
  usb_phy_roothub_exit()" in this series
- fix the logic if CONFIG_GENERIC_PHY is disabled (as reported by
  Stefan Wahren, new patch #4)
- two minor coding style fixes as suggested by Masahiro Yamada (new
  patches #4 and #5)

changes since RFC v3 at [6]:
- added Chunfeng Yun's Tested-by and Roger Quadros' Reviewed-by (thank
  you!)
- dropped RFC prefix

changes since RFC v2 at [5]:
- add missing INIT_LIST_HEAD call in usb_phy_roothub_add_phy (affects
  patch #1 - spotted by Roger Quadros, thank you!)
- fixed swapped conditions using device_may_wakeup() in
  usb_phy_roothub_resume because we need to call usb_phy_roothub_init
  if the controller cannot wake up the device (affects patch #2, spotted
  by Chunfeng Yun, thank you!)
- simplified the error condition to "undo" usb_phy_roothub_init if
  usb_phy_roothub_power_on failed in usb_phy_roothub_resume (suggested
  by Chunfeng Yun)
- updated the commit message (using Roger's wording) because (quote from
  Roger "it doesn't prevent the system from entering suspend but just
  prevents the system from reaching lowest power levels in the suspend
  state."

Changes since RFC v1 (blob attachments) at [4]:
- use device_may_wakeup instead of device_can_wakeup as suggested by
  Roger Quadros
- use the controller device from hcd->self.controller as suggested by
  Chunfeng Yun
- compile time fixes thanks to Roger Quadros
- if usb_phy_roothub_power_on in usb_phy_roothub_resume failes then
  we now call usb_phy_roothub_exit to keep the PHYs in the correct
  state if usb_phy_roothub_resume partially failed


[0] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006599.html
[1] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006737.html
[2] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006758.html
[3] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006819.html
[4] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006794.html
[5] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006820.html
[6] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006847.html
[7] https://www.spinics.net/lists/linux-usb/msg167472.html
[8] http://lists.infradead.org/pipermail/linux-amlogic/2018-March/006882.html
[9] http://lists.infradead.org/pipermail/linux-amlogic/2018-April/007009.html

Martin Blumenstingl (6):
  usb: core: phy: fix return value of usb_phy_roothub_exit()
  usb: core: split usb_phy_roothub_{init,alloc}

[PATCH usb v6 6/6] usb: core: phy: add the SPDX-License-Identifier and include guard

[Martin Blumenstingl]

This clarifies the license of the code. While here also add an include
guard to the header file.

Fixes: 07dbff0ddbd86c ("usb: core: add a wrapper for the USB PHYs on the HCD")
Suggested-by: Masahiro Yamada 
Signed-off-by: Martin Blumenstingl 
---
 drivers/usb/core/phy.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/usb/core/phy.h b/drivers/usb/core/phy.h
index bbc969383074..88a3c037e9df 100644
--- a/drivers/usb/core/phy.h
+++ b/drivers/usb/core/phy.h
@@ -1,3 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * USB roothub wrapper
+ *
+ * Copyright (C) 2018 Martin Blumenstingl 
+ */
+
+#ifndef __USB_CORE_PHY_H_
+#define __USB_CORE_PHY_H_
+
 struct device;
 struct usb_phy_roothub;
 
@@ -13,3 +23,5 @@ int usb_phy_roothub_suspend(struct device *controller_dev,
struct usb_phy_roothub *phy_roothub);
 int usb_phy_roothub_resume(struct device *controller_dev,
   struct usb_phy_roothub *phy_roothub);
+
+#endif /* __USB_CORE_PHY_H_ */
-- 
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 usb v6 4/6] usb: core: phy: make it a no-op if CONFIG_GENERIC_PHY is disabled

[Martin Blumenstingl]

If the generic PHY support is disabled the stub of devm_of_phy_get_by_index
returns ENOSYS. This corner case isn't handled properly by
usb_phy_roothub_add_phy and at least breaks USB support on Raspberry Pi
(bcm2835_defconfig):

dwc2 2098.usb: dwc2_hcd_init() FAILED, returning -38
dwc2: probe of 2098.usb failed with error -38

Let usb_phy_roothub_alloc() return in case CONFIG_GENERIC_PHY is
disabled to fix this issue (compilers might even be smart enough to
optimize away most of the code within usb_phy_roothub_alloc and
usb_phy_roothub_add_phy if CONFIG_GENERIC_PHY is disabled). All
existing usb_phy_roothub_* functions are already NULL-safe, so no
special handling is required there.

Fixes: 07dbff0ddbd8 ("usb: core: add a wrapper for the USB PHYs on the HCD")
Reported-by: Stefan Wahren 
Signed-off-by: Martin Blumenstingl 
---
 drivers/usb/core/phy.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/core/phy.c b/drivers/usb/core/phy.c
index a39d9bb26a4f..9879767452a2 100644
--- a/drivers/usb/core/phy.c
+++ b/drivers/usb/core/phy.c
@@ -50,6 +50,9 @@ struct usb_phy_roothub *usb_phy_roothub_alloc(struct device 
*dev)
struct usb_phy_roothub *phy_roothub;
int i, num_phys, err;
 
+   if (!IS_ENABLED(CONFIG_GENERIC_PHY))
+   return NULL;
+
num_phys = of_count_phandle_with_args(dev->of_node, "phys",
  "#phy-cells");
if (num_phys <= 0)
-- 
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 usb v6 3/6] usb: core: use phy_exit during suspend if wake up is not supported

[Martin Blumenstingl]

If the USB controller can wake up the system (which is the case for
example with the Mediatek USB3 IP) then we must not call phy_exit during
suspend to ensure that the USB controller doesn't have to re-enumerate
the devices during resume.
However, if the USB controller cannot wake up the system (which is the
case for example on various TI platforms using a dwc3 controller) then
we must call phy_exit during suspend. Otherwise the PHY driver keeps the
clocks enabled, which prevents the system from reaching the lowest power
levels in the suspend state.

Solve this by introducing two new functions in the PHY wrapper which are
dedicated to the suspend and resume handling.
If the controller can wake up the system the new usb_phy_roothub_suspend
function will simply call usb_phy_roothub_power_off. However, if wake up
is not supported by the controller it will also call
usb_phy_roothub_exit.
The also new usb_phy_roothub_resume function takes care of calling
usb_phy_roothub_init (if the controller can't wake up the system) in
addition to usb_phy_roothub_power_on.

Fixes: 07dbff0ddbd86c ("usb: core: add a wrapper for the USB PHYs on the HCD")
Fixes: 178a0bce05cbc1 ("usb: core: hcd: integrate the PHY wrapper into the HCD 
core")
Reported-by: Roger Quadros 
Suggested-by: Roger Quadros 
Suggested-by: Chunfeng Yun 
Signed-off-by: Martin Blumenstingl 
Tested-by: Chunfeng Yun 
Reviewed-by: Roger Quadros 
Tested-by: Keerthy 
---
 drivers/usb/core/hcd.c |  8 +---
 drivers/usb/core/phy.c | 35 +++
 drivers/usb/core/phy.h |  5 +
 3 files changed, 45 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 15b0418e3b6a..78bae4ecd68b 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2262,7 +2262,8 @@ int hcd_bus_suspend(struct usb_device *rhdev, 
pm_message_t msg)
hcd->state = HC_STATE_SUSPENDED;
 
if (!PMSG_IS_AUTO(msg))
-   usb_phy_roothub_power_off(hcd->phy_roothub);
+   usb_phy_roothub_suspend(hcd->self.sysdev,
+   hcd->phy_roothub);
 
/* Did we race with a root-hub wakeup event? */
if (rhdev->do_remote_wakeup) {
@@ -2302,7 +2303,8 @@ int hcd_bus_resume(struct usb_device *rhdev, pm_message_t 
msg)
}
 
if (!PMSG_IS_AUTO(msg)) {
-   status = usb_phy_roothub_power_on(hcd->phy_roothub);
+   status = usb_phy_roothub_resume(hcd->self.sysdev,
+   hcd->phy_roothub);
if (status)
return status;
}
@@ -2344,7 +2346,7 @@ int hcd_bus_resume(struct usb_device *rhdev, pm_message_t 
msg)
}
} else {
hcd->state = old_state;
-   usb_phy_roothub_power_off(hcd->phy_roothub);
+   usb_phy_roothub_suspend(hcd->self.sysdev, hcd->phy_roothub);
dev_dbg(>dev, "bus %s fail, err %d\n",
"resume", status);
if (status != -ESHUTDOWN)
diff --git a/drivers/usb/core/phy.c b/drivers/usb/core/phy.c
index 44f008cda7a8..a39d9bb26a4f 100644
--- a/drivers/usb/core/phy.c
+++ b/drivers/usb/core/phy.c
@@ -157,3 +157,38 @@ void usb_phy_roothub_power_off(struct usb_phy_roothub 
*phy_roothub)
phy_power_off(roothub_entry->phy);
 }
 EXPORT_SYMBOL_GPL(usb_phy_roothub_power_off);
+
+int usb_phy_roothub_suspend(struct device *controller_dev,
+   struct usb_phy_roothub *phy_roothub)
+{
+   usb_phy_roothub_power_off(phy_roothub);
+
+   /* keep the PHYs initialized so the device can wake up the system */
+   if (device_may_wakeup(controller_dev))
+   return 0;
+
+   return usb_phy_roothub_exit(phy_roothub);
+}
+EXPORT_SYMBOL_GPL(usb_phy_roothub_suspend);
+
+int usb_phy_roothub_resume(struct device *controller_dev,
+  struct usb_phy_roothub *phy_roothub)
+{
+   int err;
+
+   /* if the device can't wake up the system _exit was called */
+   if (!device_may_wakeup(controller_dev)) {
+   err = usb_phy_roothub_init(phy_roothub);
+   if (err)
+   return err;
+   }
+
+   err = usb_phy_roothub_power_on(phy_roothub);
+
+   /* undo _init if _power_on failed */
+   if (err && !device_may_wakeup(controller_dev))
+   usb_phy_roothub_exit(phy_roothub);
+
+   return err;
+}
+EXPORT_SYMBOL_GPL(usb_phy_roothub_resume);
diff --git a/drivers/usb/core/phy.h b/drivers/usb/core/phy.h
index eb31253201ad..60901d44 100644
--- a/drivers/usb/core/phy.h
+++ b/drivers/usb/core/phy.h
@@ -7,3 +7,8 @@ int usb_phy_roothub_exit(struct usb_phy_roothub *phy_roothub);
 
 int 

[PATCH usb v6 5/6] usb: core: phy: add missing forward declaration for "struct device"

[Martin Blumenstingl]

Currently hcd.c is the only consumer of the usb_phy_roothub logic. This
already includes the required header files so struct device is known.
However, future consumers might not know about struct device.
Add a forward declaration for struct device to fix potential future
consumers which don't include any of the struct device API headers.

Fixes: 07dbff0ddbd86c ("usb: core: add a wrapper for the USB PHYs on the HCD")
Suggested-by: Masahiro Yamada 
Signed-off-by: Martin Blumenstingl 
---
 drivers/usb/core/phy.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/core/phy.h b/drivers/usb/core/phy.h
index 60901d44..bbc969383074 100644
--- a/drivers/usb/core/phy.h
+++ b/drivers/usb/core/phy.h
@@ -1,3 +1,4 @@
+struct device;
 struct usb_phy_roothub;
 
 struct usb_phy_roothub *usb_phy_roothub_alloc(struct device *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

[PATCH usb v6 2/6] usb: core: split usb_phy_roothub_{init,alloc}

[Martin Blumenstingl]

Before this patch usb_phy_roothub_init served two purposes (from a
caller's point of view - like hcd.c):
- parsing the PHYs and allocating the list entries
- calling phy_init on each list entry

While this worked so far it has one disadvantage: if we need to call
phy_init for each PHY instance then the existing code cannot be re-used.
Solve this by splitting off usb_phy_roothub_alloc which only parses the
PHYs and allocates the list entries.
usb_phy_roothub_init then gets a struct usb_phy_roothub and only calls
phy_init on each PHY instance (along with the corresponding cleanup if
that failed somewhere).

This is a preparation step for adding proper suspend support for some
hardware that requires phy_exit to be called during suspend and phy_init
to be called during resume.

Signed-off-by: Martin Blumenstingl 
Tested-by: Chunfeng Yun 
Reviewed-by: Roger Quadros 
Tested-by: Keerthy 
---
 drivers/usb/core/hcd.c | 10 +---
 drivers/usb/core/phy.c | 53 +-
 drivers/usb/core/phy.h |  4 +++-
 3 files changed, 37 insertions(+), 30 deletions(-)

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 777036ae6367..15b0418e3b6a 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2758,12 +2758,16 @@ int usb_add_hcd(struct usb_hcd *hcd,
}
 
if (!hcd->skip_phy_initialization && usb_hcd_is_primary_hcd(hcd)) {
-   hcd->phy_roothub = usb_phy_roothub_init(hcd->self.sysdev);
+   hcd->phy_roothub = usb_phy_roothub_alloc(hcd->self.sysdev);
if (IS_ERR(hcd->phy_roothub)) {
retval = PTR_ERR(hcd->phy_roothub);
-   goto err_phy_roothub_init;
+   goto err_phy_roothub_alloc;
}
 
+   retval = usb_phy_roothub_init(hcd->phy_roothub);
+   if (retval)
+   goto err_phy_roothub_alloc;
+
retval = usb_phy_roothub_power_on(hcd->phy_roothub);
if (retval)
goto err_usb_phy_roothub_power_on;
@@ -2936,7 +2940,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
usb_phy_roothub_power_off(hcd->phy_roothub);
 err_usb_phy_roothub_power_on:
usb_phy_roothub_exit(hcd->phy_roothub);
-err_phy_roothub_init:
+err_phy_roothub_alloc:
if (hcd->remove_phy && hcd->usb_phy) {
usb_phy_shutdown(hcd->usb_phy);
usb_put_phy(hcd->usb_phy);
diff --git a/drivers/usb/core/phy.c b/drivers/usb/core/phy.c
index f19aaa3c899c..44f008cda7a8 100644
--- a/drivers/usb/core/phy.c
+++ b/drivers/usb/core/phy.c
@@ -19,19 +19,6 @@ struct usb_phy_roothub {
struct list_headlist;
 };
 
-static struct usb_phy_roothub *usb_phy_roothub_alloc(struct device *dev)
-{
-   struct usb_phy_roothub *roothub_entry;
-
-   roothub_entry = devm_kzalloc(dev, sizeof(*roothub_entry), GFP_KERNEL);
-   if (!roothub_entry)
-   return ERR_PTR(-ENOMEM);
-
-   INIT_LIST_HEAD(_entry->list);
-
-   return roothub_entry;
-}
-
 static int usb_phy_roothub_add_phy(struct device *dev, int index,
   struct list_head *list)
 {
@@ -45,9 +32,11 @@ static int usb_phy_roothub_add_phy(struct device *dev, int 
index,
return PTR_ERR(phy);
}
 
-   roothub_entry = usb_phy_roothub_alloc(dev);
-   if (IS_ERR(roothub_entry))
-   return PTR_ERR(roothub_entry);
+   roothub_entry = devm_kzalloc(dev, sizeof(*roothub_entry), GFP_KERNEL);
+   if (!roothub_entry)
+   return -ENOMEM;
+
+   INIT_LIST_HEAD(_entry->list);
 
roothub_entry->phy = phy;
 
@@ -56,11 +45,9 @@ static int usb_phy_roothub_add_phy(struct device *dev, int 
index,
return 0;
 }
 
-struct usb_phy_roothub *usb_phy_roothub_init(struct device *dev)
+struct usb_phy_roothub *usb_phy_roothub_alloc(struct device *dev)
 {
struct usb_phy_roothub *phy_roothub;
-   struct usb_phy_roothub *roothub_entry;
-   struct list_head *head;
int i, num_phys, err;
 
num_phys = of_count_phandle_with_args(dev->of_node, "phys",
@@ -68,16 +55,31 @@ struct usb_phy_roothub *usb_phy_roothub_init(struct device 
*dev)
if (num_phys <= 0)
return NULL;
 
-   phy_roothub = usb_phy_roothub_alloc(dev);
-   if (IS_ERR(phy_roothub))
-   return phy_roothub;
+   phy_roothub = devm_kzalloc(dev, sizeof(*phy_roothub), GFP_KERNEL);
+   if (!phy_roothub)
+   return ERR_PTR(-ENOMEM);
+
+   INIT_LIST_HEAD(_roothub->list);
 
for (i = 0; i < num_phys; i++) {
err = usb_phy_roothub_add_phy(dev, i, _roothub->list);
if (err)
-   goto err_out;
+   return ERR_PTR(err);
}
 
+   return phy_roothub;
+}

[PATCH usb v6 1/6] usb: core: phy: fix return value of usb_phy_roothub_exit()

[Martin Blumenstingl]

usb_phy_roothub_exit() should return the error code from the phy_exit()
call if exiting the PHY failed.
However, since a wrong variable is used usb_phy_roothub_exit() currently
always returns 0, even if one of the phy_exit calls returned an error.
Clang also reports this bug:
kernel/drivers/usb/core/phy.c:114:8: warning: explicitly assigning value of
variable of type 'int' to itself [-Wself-assign] error, forbidden
warning: phy.c:114

Fix this by assigning the error code from phy_exit() to the "ret"
variable to propagate the error correctly.

Fixes: 07dbff0ddbd86c ("usb: core: add a wrapper for the USB PHYs on the HCD")
Signed-off-by: Martin Blumenstingl 
Signed-off-by: Rishabh Bhatnagar 
Tested-by: Keerthy 
---
 drivers/usb/core/phy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/core/phy.c b/drivers/usb/core/phy.c
index 09b7c43c0ea4..f19aaa3c899c 100644
--- a/drivers/usb/core/phy.c
+++ b/drivers/usb/core/phy.c
@@ -111,7 +111,7 @@ int usb_phy_roothub_exit(struct usb_phy_roothub 
*phy_roothub)
list_for_each_entry(roothub_entry, head, list) {
err = phy_exit(roothub_entry->phy);
if (err)
-   ret = ret;
+   ret = err;
}
 
return ret;
-- 
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: [PATCH 0/3] USB: musb: dsps: phy fix and DT-topology support

[Martin Blumenstingl]

Hi Johan,

On Fri, Apr 13, 2018 at 5:15 PM, Johan Hovold  wrote:
> I've been carrying a patch out-of-tree since my work on improving the
> USB device-tree support which is needed to be able to describe USB
> topologies for musb based controllers.
>
> This patch, which associates the platform controller device with the
> glue device device-tree node, did not play well with the recent changes
> which added generic phy support to USB core however.
I'm the one who added this

> Like the recent dwc2 regression fixed by Arnd after the device-tree
> #phy-cell changes, the generic phy code in USB core can now also fail
> indefinitly with -EPROBE_DEFER when the controller uses a legacy USB
> phy.
>
> The second patch addresses this for musb, which handles its own (legacy
> and generic) phys, but something more may possibly now be needed for
> other platforms with legacy phys.
I'm not sure if I understand the problem yet - could you please
explain with your words what "legacy PHYs" are and how the "conflict"
with the PHY handling in USB core?

I am aware of two PHY subsystems:
- drivers/phy
-- also called "generic PHY framework"
-- uses a "phys" property
- drivers/usb/phy
-- also called "USB PHY framework"
-- AFAIK this should not be used for new drivers
-- uses an "usb-phy" property

the new PHY handling in USB core only parses the "phys" property and
thus should not conflict with "usb-phy" (the legacy property)

however, I probably missed something so I'd appreciate an explanation
how things can break

> In the process of debugging this, I stumbled over another issue which
> caused the dsps legacy phy init two be called twice on every probe and
> which is fixed by the first patch.
>
> Johan
>
>
> Johan Hovold (3):
>   USB: musb: dsps: drop duplicate phy initialisation
>   USB: musb: host: prevent core phy initialisation
>   USB: musb: dsps: propagate device-tree node
>
>  drivers/usb/musb/musb_dsps.c | 3 +--
>  drivers/usb/musb/musb_host.c | 1 +
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> --
> 2.17.0
>

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

Re: [PATCH 0/3] USB: musb: dsps: phy fix and DT-topology support

[Bin Liu]

On Wed, Apr 18, 2018 at 08:46:40PM +0200, Johan Hovold wrote:
> On Wed, Apr 18, 2018 at 11:20:15AM -0500, Bin Liu wrote:
> > Johan,
> > 
> > On Fri, Apr 13, 2018 at 05:15:02PM +0200, Johan Hovold wrote:
> > > I've been carrying a patch out-of-tree since my work on improving the
> > > USB device-tree support which is needed to be able to describe USB
> > > topologies for musb based controllers.
> > > 
> > > This patch, which associates the platform controller device with the
> > > glue device device-tree node, did not play well with the recent changes
> > > which added generic phy support to USB core however.
> > > 
> > > Like the recent dwc2 regression fixed by Arnd after the device-tree
> > > #phy-cell changes, the generic phy code in USB core can now also fail
> > > indefinitly with -EPROBE_DEFER when the controller uses a legacy USB
> > > phy.
> > > 
> > > The second patch addresses this for musb, which handles its own (legacy
> > > and generic) phys, but something more may possibly now be needed for
> > > other platforms with legacy phys.
> > > 
> > > In the process of debugging this, I stumbled over another issue which
> > > caused the dsps legacy phy init two be called twice on every probe and
> > > which is fixed by the first patch.
> > > 
> > > Johan
> > > 
> > > 
> > > Johan Hovold (3):
> > >   USB: musb: dsps: drop duplicate phy initialisation
> > >   USB: musb: host: prevent core phy initialisation
> > 
> > Are the two bugs only affecting you with your out-of-tree patch? It
> > seems don't have any functional impact for me. I need to make a decision
> > if these two patches need to go to the stable trees...
> 
> The first bug is independent of the third patch (the "out-of-tree"
> patch), but as Uwe also noted it seems to be mostly benign since it took
> two years for it to be discovered. For that reason, and to minimise the
> risk of any stable regressions, I did not mark it for stable.
> 
> The second fix is really only needed with the third of_node patch since
> I don't think any of the glue drivers propagates the device-tree node in
> this way currently. Hence it could also wait for 3.18, and it is in any
> case not stable material as the generic-phy support in USB core is new
> in 3.17.

Great, thanks for confirming. I will not send them for stable trees.

> 
> Note that other host controllers may have a device-tree node with
> associated legacy-phys however and that this could now lead to similar
> problems starting with 3.17.

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: [PATCH 0/3] USB: musb: dsps: phy fix and DT-topology support

[Johan Hovold]

On Wed, Apr 18, 2018 at 11:20:15AM -0500, Bin Liu wrote:
> Johan,
> 
> On Fri, Apr 13, 2018 at 05:15:02PM +0200, Johan Hovold wrote:
> > I've been carrying a patch out-of-tree since my work on improving the
> > USB device-tree support which is needed to be able to describe USB
> > topologies for musb based controllers.
> > 
> > This patch, which associates the platform controller device with the
> > glue device device-tree node, did not play well with the recent changes
> > which added generic phy support to USB core however.
> > 
> > Like the recent dwc2 regression fixed by Arnd after the device-tree
> > #phy-cell changes, the generic phy code in USB core can now also fail
> > indefinitly with -EPROBE_DEFER when the controller uses a legacy USB
> > phy.
> > 
> > The second patch addresses this for musb, which handles its own (legacy
> > and generic) phys, but something more may possibly now be needed for
> > other platforms with legacy phys.
> > 
> > In the process of debugging this, I stumbled over another issue which
> > caused the dsps legacy phy init two be called twice on every probe and
> > which is fixed by the first patch.
> > 
> > Johan
> > 
> > 
> > Johan Hovold (3):
> >   USB: musb: dsps: drop duplicate phy initialisation
> >   USB: musb: host: prevent core phy initialisation
> 
> Are the two bugs only affecting you with your out-of-tree patch? It
> seems don't have any functional impact for me. I need to make a decision
> if these two patches need to go to the stable trees...

The first bug is independent of the third patch (the "out-of-tree"
patch), but as Uwe also noted it seems to be mostly benign since it took
two years for it to be discovered. For that reason, and to minimise the
risk of any stable regressions, I did not mark it for stable.

The second fix is really only needed with the third of_node patch since
I don't think any of the glue drivers propagates the device-tree node in
this way currently. Hence it could also wait for 3.18, and it is in any
case not stable material as the generic-phy support in USB core is new
in 3.17.

Note that other host controllers may have a device-tree node with
associated legacy-phys however and that this could now lead to similar
problems starting with 3.17.

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

NULL pointer dereference in xhci_suspend

[Nazar Mokrynskyi]

Hi everyone, I'm running a VM using libvirt on kernel 4.15 (Ubuntu 18.04).

ASMedia USB 3.1 Gen 2 controller is assigned to VM like this:

    
  
    
  
  
  
    

Occasionally VM start fails with following error and I'm unable to start a VM 
anymore until reboot:

[40061.976095] BUG: unable to handle kernel NULL pointer dereference at 
0228
[40061.976107] IP: xhci_suspend+0x3a/0x490
[40061.976109] PGD 0 P4D 0
[40061.976115] Oops:  [#1] SMP PTI
[40061.976118] Modules linked in: cpuid vhost_net vhost tap vfio_pci 
vfio_virqfd vfio_iommu_type1 vfio xt_CHECKSUM iptable_mangle ipt_MASQUERADE 
nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 
nf_defrag_ipv4 xt_conntrack nf_conntrack libcrc32c ipt_REJECT nf_reject_ipv4 
xt_tcpudp bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables 
devlink iptable_filter binfmt_misc snd_hda_codec_hdmi intel_rapl 
x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass 
intel_cstate nls_iso8859_1 mxm_wmi snd_hda_intel snd_usb_audio snd_hda_codec 
snd_usbmidi_lib snd_hda_core snd_rawmidi snd_hwdep snd_seq_device joydev 
input_leds intel_rapl_perf snd_pcm cdc_acm snd_timer snd mei_me soundcore mei 
shpchp wmi nvidia_uvm(POE) acpi_pad mac_hid sch_fq_codel lp parport bfq 
ip_tables
[40061.976185]  x_tables autofs4 btrfs xor zstd_compress raid6_pq 
algif_skcipher af_alg dm_crypt hid_generic usbhid hid uas usb_storage 
crct10dif_pclmul crc32_pclmul nvidia_drm(POE) ghash_clmulni_intel 
nvidia_modeset(POE) pcbc i915 nvidia(POE) aesni_intel aes_x86_64 crypto_simd 
i2c_algo_bit glue_helper cryptd drm_kms_helper e1000e syscopyarea sysfillrect 
sysimgblt fb_sys_fops ptp nvme pps_core drm nvme_core ahci ipmi_devintf libahci 
ipmi_msghandler video
[40061.976230] CPU: 7 PID: 29745 Comm: kworker/7:0 Tainted: P   OE    
4.15.0-17-generic #18-Ubuntu
[40061.976232] Hardware name: Micro-Star International Co., Ltd. MS-7B45/Z370 
GAMING PRO CARBON (MS-7B45), BIOS A.51 03/29/2018
[40061.976239] Workqueue: pm pm_runtime_work
[40061.976245] RIP: 0010:xhci_suspend+0x3a/0x490
[40061.976248] RSP: 0018:a5dca0747c40 EFLAGS: 00010246
[40061.976252] RAX: ffea RBX: 913dc3106000 RCX: 
[40061.976254] RDX:  RSI: 0001 RDI: 913dc3106230
[40061.976257] RBP: a5dca0747c78 R08:  R09: a5dca0747db8
[40061.976259] R10:  R11: 01cc R12: 913dc3106000
[40061.976262] R13: 913dc3106000 R14: 913dc3106230 R15: b86efaa0
[40061.976265] FS:  () GS:913e2e7c() 
knlGS:
[40061.976268] CS:  0010 DS:  ES:  CR0: 80050033
[40061.976271] CR2: 0228 CR3: 00031460a003 CR4: 003606e0
[40061.976274] DR0:  DR1:  DR2: 
[40061.976276] DR3:  DR6: fffe0ff0 DR7: 0400
[40061.976278] Call Trace:
[40061.976286]  ? pci_pm_runtime_resume+0xa0/0xa0
[40061.976292]  xhci_pci_suspend+0x5a/0xd0
[40061.976297]  suspend_common+0x85/0x160
[40061.976302]  hcd_pci_runtime_suspend+0x1b/0x50
[40061.976306]  pci_pm_runtime_suspend+0x64/0x180
[40061.976311]  ? pci_pm_runtime_resume+0xa0/0xa0
[40061.976315]  __rpm_callback+0xca/0x210
[40061.976320]  ? __switch_to_asm+0x34/0x70
[40061.976324]  ? __switch_to_asm+0x40/0x70
[40061.976329]  rpm_callback+0x24/0x80
[40061.976333]  ? pci_pm_runtime_resume+0xa0/0xa0
[40061.976338]  rpm_suspend+0x137/0x640
[40061.976343]  rpm_idle+0x58/0x2a0
[40061.976348]  pm_runtime_work+0x92/0xa0
[40061.976353]  process_one_work+0x1de/0x410
[40061.976357]  worker_thread+0x32/0x410
[40061.976362]  kthread+0x121/0x140
[40061.976366]  ? process_one_work+0x410/0x410
[40061.976371]  ? kthread_create_worker_on_cpu+0x70/0x70
[40061.976376]  ? do_syscall_64+0x73/0x130
[40061.976380]  ? SyS_exit_group+0x14/0x20
[40061.976383]  ret_from_fork+0x35/0x40
[40061.976387] Code: 41 54 53 48 83 ec 10 4c 8b 2f 41 8b 85 28 02 00 00 85 c0 
0f 84 d1 01 00 00 83 f8 04 0f 85 51 04 00 00 48 8b 57 08 b8 ea ff ff ff <83> ba 
28 02 00 00 04 0f 85 04 01 00 00 41 89 f6 49 89 fc e8 9e
[40061.976443] RIP: xhci_suspend+0x3a/0x490 RSP: a5dca0747c40
[40061.976445] CR2: 0228
[40061.976449] ---[ end trace 5f17622537522ef8 ]---

Nothing was attached to this controller when error happened.

-- 
Sincerely, Nazar Mokrynskyi
github.com/nazar-pc

--
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] usbip: vhc_hcd: prevent module being removed while device are attached

[Sasha Levin]

On Thu, Apr 05, 2018 at 09:11:02PM +0200, Greg KH wrote:
>On Thu, Apr 05, 2018 at 04:42:46PM +, Sasha Levin wrote:
>> Hi.
>>
>> [This is an automated email]
>
>Why are you running this against patches that are not yet in Linus's
>tree?  That feels odd.  Only about 1/3 of the patches posted end up
>being merged (at best), so don't do extra work by running this on
>patches that might not even be merged at all.

Sorry for late response, this got flagged as spam :/

I was testing out a different approach, that attempts to address the
following issues:

 - When we send a review request for a patch, it usually happens weeks
   after the patch went upstream. At that point developers have moved
   on, and we're less likely to get a helpful response.

 - Some patches are tagged for particular stable trees, but don't end up
   applying/failing build on them. Usually when you send your rejection
   mails for these patches, we see no response. This might mean that
   kernels that need a particular bugfix get missed because of things
   like trivial dependencies.

 - I was planning to integrate a larger set of testing to be done for
   these patches both on mainline, and on stable kernels. Like the XFS
   example, we could run xfstests for any given patch both on mainline
   and on any older stable trees this patch applied to, This would both
   help mainline development, and would encourage devs to address any
   issues it causes on stable kernels as well.--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] USB: musb: dsps: phy fix and DT-topology support

[Bin Liu]

Johan,

On Fri, Apr 13, 2018 at 05:15:02PM +0200, Johan Hovold wrote:
> I've been carrying a patch out-of-tree since my work on improving the
> USB device-tree support which is needed to be able to describe USB
> topologies for musb based controllers.
> 
> This patch, which associates the platform controller device with the
> glue device device-tree node, did not play well with the recent changes
> which added generic phy support to USB core however.
> 
> Like the recent dwc2 regression fixed by Arnd after the device-tree
> #phy-cell changes, the generic phy code in USB core can now also fail
> indefinitly with -EPROBE_DEFER when the controller uses a legacy USB
> phy.
> 
> The second patch addresses this for musb, which handles its own (legacy
> and generic) phys, but something more may possibly now be needed for
> other platforms with legacy phys.
> 
> In the process of debugging this, I stumbled over another issue which
> caused the dsps legacy phy init two be called twice on every probe and
> which is fixed by the first patch.
> 
> Johan
> 
> 
> Johan Hovold (3):
>   USB: musb: dsps: drop duplicate phy initialisation
>   USB: musb: host: prevent core phy initialisation

Are the two bugs only affecting you with your out-of-tree patch? It
seems don't have any functional impact for me. I need to make a decision
if these two patches need to go to the stable trees...

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: [PATCH v2 2/3] lan78xx: Read LED states from Device Tree

[Andrew Lunn]

On Wed, Apr 18, 2018 at 04:45:22PM +0100, Phil Elwell wrote:
> Add support for DT property "microchip,led-modes", a vector of zero
> to four cells (u32s) in the range 0-15, each of which sets the mode
> for one of the LEDs. Some possible values are:
> 
> 0=link/activity  1=link1000/activity
> 2=link100/activity   3=link10/activity
> 4=link100/1000/activity  5=link10/1000/activity
> 6=link10/100/activity14=off15=on
> 
> These values are given symbolic constants in a dt-bindings header.
> 
> Also use the presence of the DT property to indicate that the
> LEDs should be enabled - necessary in the event that no valid OTP
> or EEPROM is available.

Hi Phil

As i said last week, these are PHY properties, so should be in the PHY
node in device tree. It should be the PHY driver which parses these
properties and configures the LEDs, not the MAC.

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

[PATCH v2 2/3] lan78xx: Read LED states from Device Tree

[Phil Elwell]

Add support for DT property "microchip,led-modes", a vector of zero
to four cells (u32s) in the range 0-15, each of which sets the mode
for one of the LEDs. Some possible values are:

0=link/activity  1=link1000/activity
2=link100/activity   3=link10/activity
4=link100/1000/activity  5=link10/1000/activity
6=link10/100/activity14=off15=on

These values are given symbolic constants in a dt-bindings header.

Also use the presence of the DT property to indicate that the
LEDs should be enabled - necessary in the event that no valid OTP
or EEPROM is available.

Signed-off-by: Phil Elwell 
---
 MAINTAINERS  |  1 +
 drivers/net/usb/lan78xx.c| 35 
 include/dt-bindings/net/microchip-78xx.h | 21 +++
 3 files changed, 57 insertions(+)
 create mode 100644 include/dt-bindings/net/microchip-78xx.h

diff --git a/MAINTAINERS b/MAINTAINERS
index b60179d..9c9bc63 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14573,6 +14573,7 @@ M:  Microchip Linux Driver Support 

 L: net...@vger.kernel.org
 S: Maintained
 F: drivers/net/usb/lan78xx.*
+F: include/dt-bindings/net/microchip-78xx.h
 
 USB MASS STORAGE DRIVER
 M: Alan Stern 
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index a823f01..f47ffea 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "lan78xx.h"
 
 #define DRIVER_AUTHOR  "WOOJUNG HUH "
@@ -74,6 +75,9 @@
 #define LAN78XX_EEPROM_MAGIC   (0x78A5)
 #define LAN78XX_OTP_MAGIC  (0x78F3)
 
+/* This register is specific to the LAN7800 and LAN7850 embedded PHYs */
+#define LAN78XX_PHY_LED_MODE_SELECT29
+
 #defineMII_READ1
 #defineMII_WRITE   0
 
@@ -2005,6 +2009,8 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
 {
int ret;
u32 mii_adv;
+   u32 led_modes[4];
+   int len;
struct phy_device *phydev;
 
phydev = phy_find_first(dev->mdiobus);
@@ -2077,6 +2083,35 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
mii_adv = (u32)mii_advertise_flowctrl(dev->fc_request_control);
phydev->advertising |= mii_adv_to_ethtool_adv_t(mii_adv);
 
+   len = of_property_read_variable_u32_array(dev->udev->dev.of_node,
+ "microchip,led-modes",
+ led_modes,
+ 0,
+ ARRAY_SIZE(led_modes));
+   if (len >= 0) {
+   u32 reg = 0;
+   int i;
+
+   for (i = 0; i < len; i++) {
+   if (led_modes[i] > 15) {
+   ret = -EINVAL;
+   goto error;
+   }
+   reg |= led_modes[i] << (i * 4);
+   }
+   for (; i < ARRAY_SIZE(led_modes); i++)
+   reg |= LAN78XX_FORCE_LED_OFF << (i * 4);
+   (void)phy_write(phydev, LAN78XX_PHY_LED_MODE_SELECT, reg);
+
+   /* Ensure the LEDs are enabled */
+   lan78xx_read_reg(dev, HW_CFG, );
+   reg |= HW_CFG_LED0_EN_ | HW_CFG_LED1_EN_;
+   lan78xx_write_reg(dev, HW_CFG, reg);
+   } else if (len == -EOVERFLOW) {
+   ret = -EINVAL;
+   goto error;
+   }
+
genphy_config_aneg(phydev);
 
dev->fc_autoneg = phydev->autoneg;
diff --git a/include/dt-bindings/net/microchip-78xx.h 
b/include/dt-bindings/net/microchip-78xx.h
new file mode 100644
index 000..dcf4a43
--- /dev/null
+++ b/include/dt-bindings/net/microchip-78xx.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _DT_BINDINGS_MICROCHIP_LAN78XX_H
+#define _DT_BINDINGS_MICROCHIP_LAN78XX_H
+
+/* LED modes */
+
+#define LAN78XX_LINK_ACTIVITY   0
+#define LAN78XX_LINK_1000_ACTIVITY  1
+#define LAN78XX_LINK_100_ACTIVITY   2
+#define LAN78XX_LINK_10_ACTIVITY3
+#define LAN78XX_LINK_100_1000_ACTIVITY  4
+#define LAN78XX_LINK_10_1000_ACTIVITY   5
+#define LAN78XX_LINK_10_100_ACTIVITY6
+#define LAN78XX_DUPLEX_COLLISION8
+#define LAN78XX_COLLISION   9
+#define LAN78XX_ACTIVITY10
+#define LAN78XX_AUTONEG_FAULT   12
+#define LAN78XX_FORCE_LED_OFF   14
+#define LAN78XX_FORCE_LED_ON15
+
+#endif
-- 
2.7.4

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

[PATCH v2 3/3] dt-bindings: Document the DT bindings for lan78xx

[Phil Elwell]

The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or programmed OTP.

Document the supported properties in a bindings file.

Signed-off-by: Phil Elwell 
---
 .../devicetree/bindings/net/microchip,lan78xx.txt  | 44 ++
 MAINTAINERS|  1 +
 2 files changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/microchip,lan78xx.txt

diff --git a/Documentation/devicetree/bindings/net/microchip,lan78xx.txt 
b/Documentation/devicetree/bindings/net/microchip,lan78xx.txt
new file mode 100644
index 000..fa68f9b
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/microchip,lan78xx.txt
@@ -0,0 +1,44 @@
+Microchip LAN78xx Gigabit Ethernet controller
+
+The LAN78XX devices are usually configured by programming their OTP or with
+an external EEPROM, but some platforms (e.g. Raspberry Pi 3 B+) have neither.
+The Device Tree properties, if present, override the OTP and EEPROM.
+
+Required properties:
+- compatible: Should be one of "usb424,7800", "usb424,7801" or "usb424,7850".
+
+Optional properties:
+- local-mac-address:   see ethernet.txt
+- mac-address: see ethernet.txt
+- microchip,led-modes: a 0..4 element vector, with each element configuring
+  the operating mode of an LED. Omitted LEDs are turned off. Allowed values
+  are defined in "include/dt-bindings/net/microchip-78xx.h".
+
+Example:
+
+/* Standard configuration for a Raspberry Pi 3 B+ */
+ {
+   usb1@1 {
+   compatible = "usb424,2514";
+   reg = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   usb1_1@1 {
+   compatible = "usb424,2514";
+   reg = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ethernet: usbether@1 {
+   compatible = "usb424,7800";
+   reg = <1>;
+   local-mac-address = [ 00 11 22 33 44 55 ];
+   microchip,led-modes = <
+   LAN78XX_LINK_1000_ACTIVITY
+   LAN78XX_LINK_10_100_ACTIVITY
+   >;
+   };
+   };
+   };
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 9c9bc63..5352bbb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14572,6 +14572,7 @@ M:  Woojung Huh 
 M: Microchip Linux Driver Support 
 L: net...@vger.kernel.org
 S: Maintained
+F: Documentation/devicetree/bindings/net/microchip,lan78xx.txt
 F: drivers/net/usb/lan78xx.*
 F: include/dt-bindings/net/microchip-78xx.h
 
-- 
2.7.4

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

[PATCH v2 1/3] lan78xx: Read MAC address from DT if present

[Phil Elwell]

There is a standard mechanism for locating and using a MAC address from
the Device Tree. Use this facility in the lan78xx driver to support
applications without programmed EEPROM or OTP. At the same time,
regularise the handling of the different address sources.

Signed-off-by: Phil Elwell 
---
 drivers/net/usb/lan78xx.c | 42 --
 1 file changed, 20 insertions(+), 22 deletions(-)

diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index 0867f72..a823f01 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "lan78xx.h"
 
 #define DRIVER_AUTHOR  "WOOJUNG HUH "
@@ -1652,34 +1653,31 @@ static void lan78xx_init_mac_address(struct lan78xx_net 
*dev)
addr[5] = (addr_hi >> 8) & 0xFF;
 
if (!is_valid_ether_addr(addr)) {
-   /* reading mac address from EEPROM or OTP */
-   if ((lan78xx_read_eeprom(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
-addr) == 0) ||
-   (lan78xx_read_otp(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
- addr) == 0)) {
-   if (is_valid_ether_addr(addr)) {
-   /* eeprom values are valid so use them */
-   netif_dbg(dev, ifup, dev->net,
- "MAC address read from EEPROM");
-   } else {
-   /* generate random MAC */
-   random_ether_addr(addr);
-   netif_dbg(dev, ifup, dev->net,
- "MAC address set to random addr");
-   }
-
-   addr_lo = addr[0] | (addr[1] << 8) |
- (addr[2] << 16) | (addr[3] << 24);
-   addr_hi = addr[4] | (addr[5] << 8);
-
-   ret = lan78xx_write_reg(dev, RX_ADDRL, addr_lo);
-   ret = lan78xx_write_reg(dev, RX_ADDRH, addr_hi);
+   if (!eth_platform_get_mac_address(>udev->dev, addr)) {
+   /* valid address present in Device Tree */
+   netif_dbg(dev, ifup, dev->net,
+ "MAC address read from Device Tree");
+   } else if (((lan78xx_read_eeprom(dev, EEPROM_MAC_OFFSET,
+ETH_ALEN, addr) == 0) ||
+   (lan78xx_read_otp(dev, EEPROM_MAC_OFFSET,
+ ETH_ALEN, addr) == 0)) &&
+  is_valid_ether_addr(addr)) {
+   /* eeprom values are valid so use them */
+   netif_dbg(dev, ifup, dev->net,
+ "MAC address read from EEPROM");
} else {
/* generate random MAC */
random_ether_addr(addr);
netif_dbg(dev, ifup, dev->net,
  "MAC address set to random addr");
}
+
+   addr_lo = addr[0] | (addr[1] << 8) |
+ (addr[2] << 16) | (addr[3] << 24);
+   addr_hi = addr[4] | (addr[5] << 8);
+
+   ret = lan78xx_write_reg(dev, RX_ADDRL, addr_lo);
+   ret = lan78xx_write_reg(dev, RX_ADDRH, addr_hi);
}
 
ret = lan78xx_write_reg(dev, MAF_LO(0), addr_lo);
-- 
2.7.4

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

[PATCH v2 0/3] lan78xx: Read configuration from Device Tree

[Phil Elwell]

The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or programmed OTP.

This patch set adds support for reading the MAC address and LED modes from
Device Tree.

v2:
- Use eth_platform_get_mac_address.
- Support up to 4 LEDs, and move LED mode constants into dt-bindings header.
- Improve bindings document.
- Remove EEE support.

Phil Elwell (3):
  lan78xx: Read MAC address from DT if present
  lan78xx: Read LED states from Device Tree
  dt-bindings: Document the DT bindings for lan78xx

 .../devicetree/bindings/net/microchip,lan78xx.txt  | 43 +++
 MAINTAINERS|  2 +
 drivers/net/usb/lan78xx.c  | 62 ++
 include/dt-bindings/net/microchip-78xx.h   | 40 ++
 4 files changed, 125 insertions(+), 22 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/microchip,lan78xx.txt
 create mode 100644 include/dt-bindings/net/microchip-78xx.h

-- 
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: Bluetooth controller falling off USB bus after an hour of continuous BT headset usage

[Dominik 'Rathann' Mierzejewski]

On Thursday, 15 March 2018 at 16:53, Dominik 'Rathann' Mierzejewski wrote:
[...]
> Could you give me any pointers for debugging this? I cannot trigger
> this on-demand, but when I'm in a conference call, it occurs within
> an hour or two of continuous usage of my BT headset in HFP mode.
> 
> I originally reported it against the Bluetooth stack here:
> https://bugzilla.kernel.org/show_bug.cgi?id=198803
> but I'm not sure if it's an issue with Bluetooth stack or the USB stack.
> You can find dmesg and lsusb output attached there.

Anyone?

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
--
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] net: qmi_wwan: add Wistron Neweb D19Q1

[Bjørn Mork]

Pawel Dembicki  writes:

> This modem is embedded on dlink dwr-960 router.
> The oem configuration states:
>
> T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0
> D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
> P: Vendor=1435 ProdID=d191 Rev=ff.ff
> S: Manufacturer=Android
> S: Product=Android
> S: SerialNumber=0123456789ABCDEF
> C:* #Ifs= 6 Cfg#= 1 Atr=80 MxPwr=500mA
> I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
> E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
> E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
> E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
> E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
> E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
> E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
> E: Ad=88(I) Atr=03(Int.) MxPS= 8 Ivl=32ms
> E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> I:* If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
> E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=125us
>
> Tested on openwrt distribution
>
> Signed-off-by: Pawel Dembicki 

Acked-by: Bjørn Mork 
--
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 09/11] usb: musb: break the huge isr musb_stage0_irq() into small functions

[Bin Liu]

On Wed, Apr 18, 2018 at 05:14:05PM +0300, Dan Carpenter wrote:
> On Wed, Apr 18, 2018 at 08:33:52AM -0500, Bin Liu wrote:
> > Hi Dan,
> > 
> > I appreciate you scaning  the patches and reporting the issues.

The report is valuable!

> > 
> 
> These are kbuild stuff so I basically just forward them.  It's no
> effort.
> 
> > On Wed, Apr 18, 2018 at 10:25:34AM +0300, Dan Carpenter wrote:
> > > Hi Bin,
> > > 
> > > I love your patch! Perhaps something to improve:
> > > 
> > > [auto build test WARNING on balbi-usb/next]
> > > [also build test WARNING on v4.17-rc1 next-20180417]
> > > [if your patch is applied to the wrong git tree, please drop us a note to 
> > > help improve the system]
> > > 
> > > url:
> > > https://github.com/0day-ci/linux/commits/Bin-Liu/usb-musb-cleanup/20180417-133633
> > > base:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
> > > 
> > > smatch warnings:
> > > drivers/usb/musb/musb_core.c:797 musb_handle_intr_connect() error: we 
> > > previously assumed 'musb->hcd' could be null (see line 783)
> > 
> > It appears the condition check was introduced back in 2013 in an attempt
> > to separate host-only and gadget-only configurations for musb [1], but it
> > seems the work is not complete, because the musb->hcd allocation is
> > unconditional. So in the current code, musb->hcd won't be NULL. 
> > 
> > But I am now hesitated to remove this 'if(musb->hcd)' check to solve
> > this smatch warning, because I am still debating on either continue the
> > work to separate the two configurations or clean up the uncompleted code
> > left by the attempt to not separate them.
> > 
> > So I want to leave the patch as is for now, is it reasonable?
> > 
> 
> Fine by me.  Right now it's sort of hard for Smatch to parse the code
> well enough for it to know that ->hcd is always non-NULL but I'm
> hopeful that maybe in a couple years that will be possible...

To me, the report is good enough :) In this case, it tells the driver
requires some work, which is valid.

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: [PATCH 0/2] Allow xhci-plat using a second clock

[Gregory CLEMENT]

Hi Mathias,
 
 On mer., févr. 14 2018, Gregory CLEMENT  wrote:

> Hello,
>
> The purpose of this series is to allow xhci-plat using a second
> clock. It is needed on the Armada 7K/8K but could be used by other
> SoCs.
>
> The first patch is just a fix found while I was working on this
> feature.

I've just realized that this series sent 2 months ago was not merged in
v4.17. The issue is that now the USB support on the Armada 7K/8K is
broken, because the clock support part was already merged.

You already had a look on this series one month ago. The issue you had
was about getting an approval for the extension of the binding [1]. I
pinged Rob about it [2] one month ago but we didn't get any
feedback. However, Rob already approved the similar changes I introduced
in an other for mv_xor_v2: [3].

So would it be possible to apply this series on v4.17-rc ?

Thanks,

Gregory

[1]:
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-February/562739.html

[2]:
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-March/566076.html

[3]:
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-March/564594.html




>
> Thanks,
>
> Gregory
>
>
> Gregory CLEMENT (2):
>   usb: host: xhci-plat: Remove useless test before clk_disable_unprepare
>   usb: host: xhci-plat: Fix clock resource by adding a register clock
>
>  Documentation/devicetree/bindings/usb/usb-xhci.txt |  5 ++-
>  drivers/usb/host/xhci-plat.c   | 39 
> --
>  drivers/usb/host/xhci.h|  3 +-
>  3 files changed, 35 insertions(+), 12 deletions(-)
>
> -- 
> 2.15.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Gregory Clement, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: sr 6:0:0:0: [sr0] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE

[Alan Stern]

On Wed, 18 Apr 2018, Cristian wrote:

> Hello,
> 
> Open bug in launchpad.net
> https://bugs.launchpad.net/bugs/1765043
> 
> 
> dmesg:
> [ 4228.290628] sr 6:0:0:0: [sr0] tag#0 FAILED Result: hostbyte=DID_OK
> driverbyte=DRIVER_SENSE
> [ 4228.290638] sr 6:0:0:0: [sr0] tag#0 Sense Key : Illegal Request [current]
> [ 4228.290645] sr 6:0:0:0: [sr0] tag#0 Add. Sense: Illegal mode for this track
> [ 4228.290652] sr 6:0:0:0: [sr0] tag#0 CDB: Read(10) 28 00 00 01 58 96
> 00 00 02 00 00 00
> [ 4228.290657] print_req_error: I/O error, dev sr0, sector 352856
> [ 4228.290707] attempt to access beyond end of device
> [ 4228.290717] unknown-block(11,0): rw=0, want=352860, limit=352856
> [ 4228.290723] Buffer I/O error on dev sr0, logical block 88214, async page 
> read
> [ 4228.290733] attempt to access beyond end of device
> [ 4228.290738] unknown-block(11,0): rw=0, want=352864, limit=352856
> [ 4228.290741] Buffer I/O error on dev sr0, logical block 88215, async page 
> read
> [ 4230.210353] ISO 9660 Extensions: Microsoft Joliet Level 3
> [ 4230.216636] ISO 9660 Extensions: IEEE_1282
> [ 4291.030676] VFS: busy inodes on changed media or resized disk sr0

sr is the SCSI cdrom/dvd driver.  Why was this reported to the USB 
mailing list instead of the SCSI mailing list?

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: [PATCH 09/11] usb: musb: break the huge isr musb_stage0_irq() into small functions

[Dan Carpenter]

On Wed, Apr 18, 2018 at 08:33:52AM -0500, Bin Liu wrote:
> Hi Dan,
> 
> I appreciate you scaning  the patches and reporting the issues.
> 

These are kbuild stuff so I basically just forward them.  It's no
effort.

> On Wed, Apr 18, 2018 at 10:25:34AM +0300, Dan Carpenter wrote:
> > Hi Bin,
> > 
> > I love your patch! Perhaps something to improve:
> > 
> > [auto build test WARNING on balbi-usb/next]
> > [also build test WARNING on v4.17-rc1 next-20180417]
> > [if your patch is applied to the wrong git tree, please drop us a note to 
> > help improve the system]
> > 
> > url:
> > https://github.com/0day-ci/linux/commits/Bin-Liu/usb-musb-cleanup/20180417-133633
> > base:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
> > 
> > smatch warnings:
> > drivers/usb/musb/musb_core.c:797 musb_handle_intr_connect() error: we 
> > previously assumed 'musb->hcd' could be null (see line 783)
> 
> It appears the condition check was introduced back in 2013 in an attempt
> to separate host-only and gadget-only configurations for musb [1], but it
> seems the work is not complete, because the musb->hcd allocation is
> unconditional. So in the current code, musb->hcd won't be NULL. 
> 
> But I am now hesitated to remove this 'if(musb->hcd)' check to solve
> this smatch warning, because I am still debating on either continue the
> work to separate the two configurations or clean up the uncompleted code
> left by the attempt to not separate them.
> 
> So I want to leave the patch as is for now, is it reasonable?
> 

Fine by me.  Right now it's sort of hard for Smatch to parse the code
well enough for it to know that ->hcd is always non-NULL but I'm
hopeful that maybe in a couple years that will be possible...

regards,
dan carpenter

--
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]

On Wed, Apr 18, 2018 at 08:20:28AM +0300, Felipe Balbi wrote:
> 
> Hi Bin,
> 
> 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 :(

> > branch on TI VAYU evm, it has issues in both high-speed and super-speed
> > connections. It works fine with v4.17-rc1.
> >
> > If it suppose to work with g-webcam, please let me know if you want
> > the details of the problems I see - the log is very long in super-speed
> > failure.
> 
> Sure, give me some details of what's going on. Some bisection would be
> great too, then I'll know which patch to blame and where to focus fixes.

Roger has a copy of your previous work here:

g...@github.com:rogerq/linux.git, branch balbi-dwc3-improve-isoc-endpoints

I just tested it and it works fine with g_webcam.

Do you think this information will help you? If so it saves me time on
bisect ;)

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

[PATCH] net: qmi_wwan: add Wistron Neweb D19Q1

[Pawel Dembicki]

This modem is embedded on dlink dwr-960 router.
The oem configuration states:

T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1435 ProdID=d191 Rev=ff.ff
S: Manufacturer=Android
S: Product=Android
S: SerialNumber=0123456789ABCDEF
C:* #Ifs= 6 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
E: Ad=88(I) Atr=03(Int.) MxPS= 8 Ivl=32ms
E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=125us

Tested on openwrt distribution

Signed-off-by: Pawel Dembicki 
---
 drivers/net/usb/qmi_wwan.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index ca066b7..c853e74 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1107,6 +1107,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x1435, 0xd181, 3)},/* Wistron NeWeb D18Q1 */
{QMI_FIXED_INTF(0x1435, 0xd181, 4)},/* Wistron NeWeb D18Q1 */
{QMI_FIXED_INTF(0x1435, 0xd181, 5)},/* Wistron NeWeb D18Q1 */
+   {QMI_FIXED_INTF(0x1435, 0xd191, 4)},/* Wistron NeWeb D19Q1 */
{QMI_FIXED_INTF(0x16d8, 0x6003, 0)},/* CMOTech 6003 */
{QMI_FIXED_INTF(0x16d8, 0x6007, 0)},/* CMOTech CHE-628S */
{QMI_FIXED_INTF(0x16d8, 0x6008, 0)},/* CMOTech CMU-301 */
-- 
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

sr 6:0:0:0: [sr0] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE

[Cristian]

Hello,

Open bug in launchpad.net
https://bugs.launchpad.net/bugs/1765043


dmesg:
[ 4228.290628] sr 6:0:0:0: [sr0] tag#0 FAILED Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE
[ 4228.290638] sr 6:0:0:0: [sr0] tag#0 Sense Key : Illegal Request [current]
[ 4228.290645] sr 6:0:0:0: [sr0] tag#0 Add. Sense: Illegal mode for this track
[ 4228.290652] sr 6:0:0:0: [sr0] tag#0 CDB: Read(10) 28 00 00 01 58 96
00 00 02 00 00 00
[ 4228.290657] print_req_error: I/O error, dev sr0, sector 352856
[ 4228.290707] attempt to access beyond end of device
[ 4228.290717] unknown-block(11,0): rw=0, want=352860, limit=352856
[ 4228.290723] Buffer I/O error on dev sr0, logical block 88214, async page read
[ 4228.290733] attempt to access beyond end of device
[ 4228.290738] unknown-block(11,0): rw=0, want=352864, limit=352856
[ 4228.290741] Buffer I/O error on dev sr0, logical block 88215, async page read
[ 4230.210353] ISO 9660 Extensions: Microsoft Joliet Level 3
[ 4230.216636] ISO 9660 Extensions: IEEE_1282
[ 4291.030676] VFS: busy inodes on changed media or resized disk sr0

Regards,
--
Cristian Aravena Romero (caravena)
--
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 09/11] usb: musb: break the huge isr musb_stage0_irq() into small functions

[Bin Liu]

Hi Dan,

I appreciate you scaning  the patches and reporting the issues.

On Wed, Apr 18, 2018 at 10:25:34AM +0300, Dan Carpenter wrote:
> Hi Bin,
> 
> I love your patch! Perhaps something to improve:
> 
> [auto build test WARNING on balbi-usb/next]
> [also build test WARNING on v4.17-rc1 next-20180417]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Bin-Liu/usb-musb-cleanup/20180417-133633
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
> 
> smatch warnings:
> drivers/usb/musb/musb_core.c:797 musb_handle_intr_connect() error: we 
> previously assumed 'musb->hcd' could be null (see line 783)

It appears the condition check was introduced back in 2013 in an attempt
to separate host-only and gadget-only configurations for musb [1], but it
seems the work is not complete, because the musb->hcd allocation is
unconditional. So in the current code, musb->hcd won't be NULL. 

But I am now hesitated to remove this 'if(musb->hcd)' check to solve
this smatch warning, because I am still debating on either continue the
work to separate the two configurations or clean up the uncompleted code
left by the attempt to not separate them.

So I want to leave the patch as is for now, is it reasonable?

[1] commit 74c2e93600581("usb: musb: factor out hcd initalization")

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

[PATCH 1/2] usb: typec: tps6598x: handle block reads separately with plain-I2C adapters

[Heikki Krogerus]

If the I2C adapter that the PD controller is attached to
does not support SMBus protocol, the driver needs to handle
block reads separately. The first byte returned in block
read protocol will show the total number of bytes. It needs
to be stripped away.

This is handled separately in the driver only because right
now we have no way of requesting the used protocol with
regmap-i2c. This is in practice a workaround for what is
really a problem in regmap-i2c. The other option would have
been to register custom regmap, or not use regmap at all,
however, since the solution is very simple, I choose to use
it in this case for convenience. It is easy to remove once
we figure out how to handle this kind of cases in
regmap-i2c.

Fixes: 0a4c005bd171 ("usb: typec: driver for TI TPS6598x USB Power Delivery 
controllers")
Signed-off-by: Heikki Krogerus 
---
 drivers/usb/typec/tps6598x.c | 42 ++--
 1 file changed, 35 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/typec/tps6598x.c b/drivers/usb/typec/tps6598x.c
index 8b8406867c02..82f09cd9792d 100644
--- a/drivers/usb/typec/tps6598x.c
+++ b/drivers/usb/typec/tps6598x.c
@@ -73,6 +73,7 @@ struct tps6598x {
struct device *dev;
struct regmap *regmap;
struct mutex lock; /* device lock */
+   u8 i2c_protocol:1;
 
struct typec_port *port;
struct typec_partner *partner;
@@ -80,6 +81,23 @@ struct tps6598x {
struct typec_capability typec_cap;
 };
 
+static int
+tps6598x_block_read(struct tps6598x *tps, u8 reg, void *val, ssize_t len)
+{
+   u8 data[len + 1];
+   int ret;
+
+   if (!tps->i2c_protocol)
+   return regmap_raw_read(tps->regmap, reg, val, len);
+
+   ret = regmap_raw_read(tps->regmap, reg, data, sizeof(data));
+   if (ret)
+   return ret;
+
+   memcpy(val, [1], len);
+   return 0;
+}
+
 static inline int tps6598x_read16(struct tps6598x *tps, u8 reg, u16 *val)
 {
return regmap_raw_read(tps->regmap, reg, val, sizeof(u16));
@@ -87,12 +105,12 @@ static inline int tps6598x_read16(struct tps6598x *tps, u8 
reg, u16 *val)
 
 static inline int tps6598x_read32(struct tps6598x *tps, u8 reg, u32 *val)
 {
-   return regmap_raw_read(tps->regmap, reg, val, sizeof(u32));
+   return tps6598x_block_read(tps, reg, val, sizeof(u32));
 }
 
 static inline int tps6598x_read64(struct tps6598x *tps, u8 reg, u64 *val)
 {
-   return regmap_raw_read(tps->regmap, reg, val, sizeof(u64));
+   return tps6598x_block_read(tps, reg, val, sizeof(u64));
 }
 
 static inline int tps6598x_write16(struct tps6598x *tps, u8 reg, u16 val)
@@ -121,8 +139,8 @@ static int tps6598x_read_partner_identity(struct tps6598x 
*tps)
struct tps6598x_rx_identity_reg id;
int ret;
 
-   ret = regmap_raw_read(tps->regmap, TPS_REG_RX_IDENTITY_SOP,
- , sizeof(id));
+   ret = tps6598x_block_read(tps, TPS_REG_RX_IDENTITY_SOP,
+ , sizeof(id));
if (ret)
return ret;
 
@@ -224,13 +242,13 @@ static int tps6598x_exec_cmd(struct tps6598x *tps, const 
char *cmd,
} while (val);
 
if (out_len) {
-   ret = regmap_raw_read(tps->regmap, TPS_REG_DATA1,
- out_data, out_len);
+   ret = tps6598x_block_read(tps, TPS_REG_DATA1,
+ out_data, out_len);
if (ret)
return ret;
val = out_data[0];
} else {
-   ret = regmap_read(tps->regmap, TPS_REG_DATA1, );
+   ret = tps6598x_block_read(tps, TPS_REG_DATA1, , sizeof(u8));
if (ret)
return ret;
}
@@ -385,6 +403,16 @@ static int tps6598x_probe(struct i2c_client *client)
if (!vid)
return -ENODEV;
 
+   /*
+* Checking can the adapter handle SMBus protocol. If if can not, the
+* driver needs to take care of block reads separately.
+*
+* FIXME: Testing with I2C_FUNC_I2C. regmap-i2c uses I2C protocol
+* unconditionally if the adapter has I2C_FUNC_I2C set.
+*/
+   if (i2c_check_functionality(client->adapter, I2C_FUNC_I2C))
+   tps->i2c_protocol = true;
+
ret = tps6598x_read32(tps, TPS_REG_STATUS, );
if (ret < 0)
return ret;
-- 
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 0/2] usb: typec: fixes

[Heikki Krogerus]

Hi,

I got two separate fixes here. First one will fix an issue with ucsi where the
driver may timeout if EC is under heavy load, and the second an issue with
tps6598x when used with plain I2C adapters.


Thanks,


Heikki Krogerus (2):
  usb: typec: tps6598x: handle block reads separately with plain-I2C
adapters
  usb: typec: ucsi: Increase command completion timeout value

 drivers/usb/typec/tps6598x.c  | 42 +--
 drivers/usb/typec/ucsi/ucsi.c |  2 +-
 2 files changed, 36 insertions(+), 8 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

[PATCH 2/2] usb: typec: ucsi: Increase command completion timeout value

[Heikki Krogerus]

On some boards, under heavy load, the EC firmware is
unable to complete commands even in one second. Increasing
the command completion timeout value to five seconds.

Reported-by: Quanxian Wang 
Fixes: c1b0bc2dabfa ("usb: typec: Add support for UCSI interface")
Cc: 
Signed-off-by: Heikki Krogerus 
---
 drivers/usb/typec/ucsi/ucsi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c
index bf0977fbd100..bd5cca5632b3 100644
--- a/drivers/usb/typec/ucsi/ucsi.c
+++ b/drivers/usb/typec/ucsi/ucsi.c
@@ -28,7 +28,7 @@
  * difficult to estimate the time it takes for the system to process the 
command
  * before it is actually passed to the PPM.
  */
-#define UCSI_TIMEOUT_MS1000
+#define UCSI_TIMEOUT_MS5000
 
 /*
  * UCSI_SWAP_TIMEOUT_MS - Timeout for role swap requests
-- 
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: [PATCH RFC] usb: typec: tcpm: remove operating_snk_mw for rdo

[Hans de Goede]

Hi,

On 17-04-18 08:01, Li Jun wrote:

This patch is a further update for rdo based on [1], which
removed max_snk_ma/mv/mw but kept operating_snk_mw.
operating_snk_mw is only used to judge capability mismatch,
per PD spec, we can achieve this via compare the selected
source PDO and matching sink PDO, also after patch [1], we
don't limit the PDO matching between the same type, so the
rdo operating and max current/power calculation should be
updated accordingly.


I do not believe that this is correct, lets take a device
with a fusb302 tcpc with the following PDO-s:

PDO_FIXED(5000, 400, PDO_FIXED_FLAGS)
PDO_VAR(5000, 12000, 3000);

And an operating_snk_mw of 2500mW then according to your
new code a charger which supplies 12V 2A will now get
the mismatch bit set even though it is delivering 24W.

I really don't see any way to fix this and I believe we
should just keep the operating_snk_mw field.

Regards

Hans




[1]https://patchwork.kernel.org/patch/10342299/

Signed-off-by: Li Jun 
---
  drivers/usb/typec/tcpm.c | 52 ++--
  1 file changed, 33 insertions(+), 19 deletions(-)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 27192083..0be04b3 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -1854,28 +1854,42 @@ static int tcpm_pd_build_request(struct tcpm_port 
*port, u32 *rdo)
else
mv = pdo_min_voltage(pdo);
  
-	/* Select maximum available current within the sink pdo's limit */

-   if (type == PDO_TYPE_BATT) {
-   mw = min_power(pdo, matching_snk_pdo);
-   ma = 1000 * mw / mv;
-   } else {
-   ma = min_current(pdo, matching_snk_pdo);
-   mw = ma * mv / 1000;
-   }
-
flags = RDO_USB_COMM | RDO_NO_SUSPEND;
  
-	/* Set mismatch bit if offered power is less than operating power */

-   max_ma = ma;
-   max_mw = mw;
-   if (mw < port->operating_snk_mw) {
-   flags |= RDO_CAP_MISMATCH;
-   if (type == PDO_TYPE_BATT &&
-   (pdo_max_power(matching_snk_pdo) > pdo_max_power(pdo)))
-   max_mw = pdo_max_power(matching_snk_pdo);
-   else if (pdo_max_current(matching_snk_pdo) >
-pdo_max_current(pdo))
+   switch (type) {
+   case PDO_TYPE_FIXED:
+   case PDO_TYPE_VAR:
+   if (pdo_type(matching_snk_pdo) == PDO_TYPE_BATT)
+   max_ma = pdo_max_power(matching_snk_pdo) * 1000 / mv;
+   else
max_ma = pdo_max_current(matching_snk_pdo);
+
+   if (max_ma > pdo_max_current(pdo)) {
+   flags |= RDO_CAP_MISMATCH;
+   ma = pdo_max_current(pdo);
+   } else {
+   ma = max_ma;
+   }
+   break;
+   case PDO_TYPE_BATT:
+   if (pdo_type(matching_snk_pdo) == PDO_TYPE_BATT)
+   max_mw = pdo_max_power(matching_snk_pdo);
+   else
+   max_mw = pdo_max_current(matching_snk_pdo) *
+pdo_min_voltage(matching_snk_pdo) /
+1000;
+
+   if (max_mw > pdo_max_power(pdo)) {
+   flags |= RDO_CAP_MISMATCH;
+   mw = pdo_max_power(pdo);
+   } else {
+   mw = max_mw;
+   }
+
+   ma = mw * 1000 / mv;
+   break;
+   default:
+   break;
}
  
  	tcpm_log(port, "cc=%d cc1=%d cc2=%d vbus=%d vconn=%s polarity=%d",



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

[PATCH v2 4/6] USB: musb: omap2430: drop non-DT support

[Johan Hovold]

Drop support for non-DT systems, which hasn't been used by a mainline
kernel since commit 9080b8dc761a ("ARM: OMAP2+: Remove legacy usb-host.c
platform init code"). Specifically, since that commit usb_get_phy_dev()
have always returned -ENODEV when looking up a legacy phy, something
which in turn would have led to the init callback returning
-EPROBE_DEFER indefinitely.

Signed-off-by: Johan Hovold 
---
 drivers/usb/musb/omap2430.c | 95 ++---
 1 file changed, 45 insertions(+), 50 deletions(-)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 5d705930ef47..3dd6e1c5e04f 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -239,21 +239,15 @@ static int omap2430_musb_init(struct musb *musb)
 * up through ULPI.  TWL4030-family PMICs include one,
 * which needs a driver, drivers aren't always needed.
 */
-   if (dev->parent->of_node) {
-   musb->phy = devm_phy_get(dev->parent, "usb2-phy");
-
-   /* We can't totally remove musb->xceiv as of now because
-* musb core uses xceiv.state and xceiv.otg. Once we have
-* a separate state machine to handle otg, these can be moved
-* out of xceiv and then we can start using the generic PHY
-* framework
-*/
-   musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent,
-   "usb-phy", 0);
-   } else {
-   musb->xceiv = devm_usb_get_phy_dev(dev, 0);
-   musb->phy = devm_phy_get(dev, "usb");
-   }
+   musb->phy = devm_phy_get(dev->parent, "usb2-phy");
+
+   /* We can't totally remove musb->xceiv as of now because
+* musb core uses xceiv.state and xceiv.otg. Once we have
+* a separate state machine to handle otg, these can be moved
+* out of xceiv and then we can start using the generic PHY
+* framework
+*/
+   musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent, "usb-phy", 0);
 
if (IS_ERR(musb->xceiv)) {
status = PTR_ERR(musb->xceiv);
@@ -391,8 +385,13 @@ static int omap2430_probe(struct platform_device *pdev)
struct omap2430_glue*glue;
struct device_node  *np = pdev->dev.of_node;
struct musb_hdrc_config *config;
+   struct device_node  *control_node;
+   struct platform_device  *control_pdev;
int ret = -ENOMEM, val;
 
+   if (!np)
+   return -ENODEV;
+
glue = devm_kzalloc(>dev, sizeof(*glue), GFP_KERNEL);
if (!glue)
goto err0;
@@ -412,47 +411,43 @@ static int omap2430_probe(struct platform_device *pdev)
glue->status= MUSB_UNKNOWN;
glue->control_otghs = ERR_PTR(-ENODEV);
 
-   if (np) {
-   struct device_node *control_node;
-   struct platform_device *control_pdev;
+   pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   goto err2;
 
-   pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
-   if (!pdata)
-   goto err2;
+   data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
+   if (!data)
+   goto err2;
 
-   data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
-   if (!data)
-   goto err2;
+   config = devm_kzalloc(>dev, sizeof(*config), GFP_KERNEL);
+   if (!config)
+   goto err2;
 
-   config = devm_kzalloc(>dev, sizeof(*config), GFP_KERNEL);
-   if (!config)
+   of_property_read_u32(np, "mode", (u32 *)>mode);
+   of_property_read_u32(np, "interface-type",
+   (u32 *)>interface_type);
+   of_property_read_u32(np, "num-eps", (u32 *)>num_eps);
+   of_property_read_u32(np, "ram-bits", (u32 *)>ram_bits);
+   of_property_read_u32(np, "power", (u32 *)>power);
+
+   ret = of_property_read_u32(np, "multipoint", );
+   if (!ret && val)
+   config->multipoint = true;
+
+   pdata->board_data   = data;
+   pdata->config   = config;
+
+   control_node = of_parse_phandle(np, "ctrl-module", 0);
+   if (control_node) {
+   control_pdev = of_find_device_by_node(control_node);
+   if (!control_pdev) {
+   dev_err(>dev, "Failed to get control device\n");
+   ret = -EINVAL;
goto err2;
-
-   of_property_read_u32(np, "mode", (u32 *)>mode);
-   of_property_read_u32(np, "interface-type",
-   (u32 *)>interface_type);
-   of_property_read_u32(np, "num-eps", (u32 *)>num_eps);
-   of_property_read_u32(np, "ram-bits", (u32 *)>ram_bits);
-   

[PATCH v2 0/6] USB: legacy-phy spring cleaning

[Johan Hovold]

When investigating an issue related to the recent addition of
generic-phy support to USB core, I happened to take a closer look at the
legacy-phy support in usb_add_hcd() as well.

Turns out this code hasn't been used since 2016 when OMAP dropped
support for non-DT boot. Specifically, the interface for associating
controllers with phys in board files and platform code has since been
unused and consequently all legacy phy lookups using usb_get_phy_dev()
has also been failing with -ENODEV on mainline kernels.

This series rips it all out.

Johan


Changes in v2
 - Reword the commit message for renesas_usbhs in order to highlight
   that the legacy API is still being used in gadget mode as noted by
   Yoshihiro Shimoda (whose ack is also added).


Johan Hovold (6):
  USB: phy: drop unused legacy controller-phy bind helper
  USB: core: hcd: drop support for legacy phys
  USB: ehci-omap: drop unused legacy phy support
  USB: musb: omap2430: drop non-DT support
  USB: renesas_usbhs: drop unused legacy-phy support
  USB: phy: drop legacy board-file support

 drivers/usb/core/hcd.c |  38 +
 drivers/usb/host/ehci-omap.c   |   5 +-
 drivers/usb/musb/omap2430.c|  95 ++---
 drivers/usb/phy/phy.c  | 133 +
 drivers/usb/renesas_usbhs/common.h |   1 -
 drivers/usb/renesas_usbhs/rcar2.c  |  29 ---
 include/linux/usb/hcd.h|   1 -
 include/linux/usb/phy.h|  36 
 8 files changed, 51 insertions(+), 287 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

[PATCH v2 2/6] USB: core: hcd: drop support for legacy phys

[Johan Hovold]

Drop support for looking up and initialising legacy phys in USB core,
something which hasn't been used by a mainline kernel since commit
9080b8dc761a ("ARM: OMAP2+: Remove legacy usb-host.c platform init
code"). Specifically, since that commit usb_get_phy_dev() have always
returned -ENODEV and consequently this code has not been used.

Signed-off-by: Johan Hovold 
---
 drivers/usb/core/hcd.c  | 38 +++---
 include/linux/usb/hcd.h |  1 -
 2 files changed, 3 insertions(+), 36 deletions(-)

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 777036ae6367..6241d32c5ba7 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -33,7 +33,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include "usb.h"
@@ -2739,30 +2738,10 @@ int usb_add_hcd(struct usb_hcd *hcd,
int retval;
struct usb_device *rhdev;
 
-   if (IS_ENABLED(CONFIG_USB_PHY) && !hcd->skip_phy_initialization) {
-   struct usb_phy *phy = usb_get_phy_dev(hcd->self.sysdev, 0);
-
-   if (IS_ERR(phy)) {
-   retval = PTR_ERR(phy);
-   if (retval == -EPROBE_DEFER)
-   return retval;
-   } else {
-   retval = usb_phy_init(phy);
-   if (retval) {
-   usb_put_phy(phy);
-   return retval;
-   }
-   hcd->usb_phy = phy;
-   hcd->remove_phy = 1;
-   }
-   }
-
if (!hcd->skip_phy_initialization && usb_hcd_is_primary_hcd(hcd)) {
hcd->phy_roothub = usb_phy_roothub_init(hcd->self.sysdev);
-   if (IS_ERR(hcd->phy_roothub)) {
-   retval = PTR_ERR(hcd->phy_roothub);
-   goto err_phy_roothub_init;
-   }
+   if (IS_ERR(hcd->phy_roothub))
+   return PTR_ERR(hcd->phy_roothub);
 
retval = usb_phy_roothub_power_on(hcd->phy_roothub);
if (retval)
@@ -2936,12 +2915,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
usb_phy_roothub_power_off(hcd->phy_roothub);
 err_usb_phy_roothub_power_on:
usb_phy_roothub_exit(hcd->phy_roothub);
-err_phy_roothub_init:
-   if (hcd->remove_phy && hcd->usb_phy) {
-   usb_phy_shutdown(hcd->usb_phy);
-   usb_put_phy(hcd->usb_phy);
-   hcd->usb_phy = NULL;
-   }
+
return retval;
 }
 EXPORT_SYMBOL_GPL(usb_add_hcd);
@@ -3017,12 +2991,6 @@ void usb_remove_hcd(struct usb_hcd *hcd)
usb_phy_roothub_power_off(hcd->phy_roothub);
usb_phy_roothub_exit(hcd->phy_roothub);
 
-   if (hcd->remove_phy && hcd->usb_phy) {
-   usb_phy_shutdown(hcd->usb_phy);
-   usb_put_phy(hcd->usb_phy);
-   hcd->usb_phy = NULL;
-   }
-
usb_put_invalidate_rhdev(hcd);
hcd->flags = 0;
 }
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index aef50cb2ed1b..e33009c77840 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -150,7 +150,6 @@ struct usb_hcd {
unsignedrh_pollable:1;  /* may we poll the root hub? */
unsignedmsix_enabled:1; /* driver has MSI-X enabled? */
unsignedmsi_enabled:1;  /* driver has MSI enabled? */
-   unsignedremove_phy:1;   /* auto-remove USB phy */
/*
 * do not manage the PHY state in the HCD core, instead let the driver
 * handle this (for example if the PHY can only be turned on after a
-- 
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 v2 3/6] USB: ehci-omap: drop unused legacy phy support

[Johan Hovold]

Drop support for looking up legacy phys defined by board files,
something which hasn't been used by a mainline kernel since commit
9080b8dc761a ("ARM: OMAP2+: Remove legacy usb-host.c platform init
code"). Specifically, since that commit usb_get_phy_dev() have always
returned -ENODEV and consequently this code has not been used.

Signed-off-by: Johan Hovold 
---
 drivers/usb/host/ehci-omap.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 8d8bafc70c1f..7e4c13346a1e 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -157,10 +157,7 @@ static int ehci_hcd_omap_probe(struct platform_device 
*pdev)
struct usb_phy *phy;
 
/* get the PHY device */
-   if (dev->of_node)
-   phy = devm_usb_get_phy_by_phandle(dev, "phys", i);
-   else
-   phy = devm_usb_get_phy_dev(dev, i);
+   phy = devm_usb_get_phy_by_phandle(dev, "phys", i);
if (IS_ERR(phy)) {
/* Don't bail out if PHY is not absolutely necessary */
if (pdata->port_mode[i] != OMAP_EHCI_PORT_MODE_PHY)
-- 
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 v2 5/6] USB: renesas_usbhs: drop unused legacy-phy support

[Johan Hovold]

Drop support for legacy phys for rcar2 which hasn't been used with a
mainline kernel since commit 9080b8dc761a ("ARM: OMAP2+: Remove legacy
usb-host.c platform init code"). Specifically, since that commit
usb_get_phy_dev() have always returned -ENODEV and consequently this
code has not been used.

Note that the legacy-phy API is still being used in gadget mode to bind
the peripheral controller.

Acked-by: Yoshihiro Shimoda 
Signed-off-by: Johan Hovold 
---
 drivers/usb/renesas_usbhs/common.h |  1 -
 drivers/usb/renesas_usbhs/rcar2.c  | 29 -
 2 files changed, 30 deletions(-)

diff --git a/drivers/usb/renesas_usbhs/common.h 
b/drivers/usb/renesas_usbhs/common.h
index f619afeae2b8..6137f7942c05 100644
--- a/drivers/usb/renesas_usbhs/common.h
+++ b/drivers/usb/renesas_usbhs/common.h
@@ -276,7 +276,6 @@ struct usbhs_priv {
 */
struct usbhs_fifo_info fifo_info;
 
-   struct usb_phy *usb_phy;
struct phy *phy;
 };
 
diff --git a/drivers/usb/renesas_usbhs/rcar2.c 
b/drivers/usb/renesas_usbhs/rcar2.c
index 85a0e0933917..0027092b1118 100644
--- a/drivers/usb/renesas_usbhs/rcar2.c
+++ b/drivers/usb/renesas_usbhs/rcar2.c
@@ -8,7 +8,6 @@
 #include 
 #include 
 #include 
-#include 
 #include "common.h"
 #include "rcar2.h"
 
@@ -26,16 +25,6 @@ static int usbhs_rcar2_hardware_init(struct platform_device 
*pdev)
return 0;
}
 
-   if (IS_ENABLED(CONFIG_USB_PHY)) {
-   struct usb_phy *usb_phy = usb_get_phy_dev(>dev, 0);
-
-   if (IS_ERR(usb_phy))
-   return PTR_ERR(usb_phy);
-
-   priv->usb_phy = usb_phy;
-   return 0;
-   }
-
return -ENXIO;
 }
 
@@ -48,11 +37,6 @@ static int usbhs_rcar2_hardware_exit(struct platform_device 
*pdev)
priv->phy = NULL;
}
 
-   if (priv->usb_phy) {
-   usb_put_phy(priv->usb_phy);
-   priv->usb_phy = NULL;
-   }
-
return 0;
 }
 
@@ -75,19 +59,6 @@ static int usbhs_rcar2_power_ctrl(struct platform_device 
*pdev,
}
}
 
-   if (priv->usb_phy) {
-   if (enable) {
-   retval = usb_phy_init(priv->usb_phy);
-
-   if (!retval)
-   retval = usb_phy_set_suspend(priv->usb_phy, 0);
-   } else {
-   usb_phy_set_suspend(priv->usb_phy, 1);
-   usb_phy_shutdown(priv->usb_phy);
-   retval = 0;
-   }
-   }
-
return retval;
 }
 
-- 
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 v2 1/6] USB: phy: drop unused legacy controller-phy bind helper

[Johan Hovold]

Drop the unused legacy usb_bind_phy() helper whose last user was removed
in 2016 when OMAP moved to device-tree boot (9080b8dc761a ("ARM: OMAP2+:
Remove legacy usb-host.c platform init code")).

Note that this means that for the last couple of years the phy_bind_list
has been empty (when using mainline kernels) and that consequently all
phy lookups using the usb_get_phy_dev() interface have failed with
-ENODEV. This helper along with its current users will be removed by
follow-on patches.

Signed-off-by: Johan Hovold 
---
 drivers/usb/phy/phy.c   | 34 --
 include/linux/usb/phy.h |  8 
 2 files changed, 42 deletions(-)

diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index bceb2c9988dd..833547b00383 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -795,40 +795,6 @@ void usb_remove_phy(struct usb_phy *x)
 }
 EXPORT_SYMBOL_GPL(usb_remove_phy);
 
-/**
- * usb_bind_phy - bind the phy and the controller that uses the phy
- * @dev_name: the device name of the device that will bind to the phy
- * @index: index to specify the port number
- * @phy_dev_name: the device name of the phy
- *
- * Fills the phy_bind structure with the dev_name and phy_dev_name. This will
- * be used when the phy driver registers the phy and when the controller
- * requests this phy.
- *
- * To be used by platform specific initialization code.
- */
-int usb_bind_phy(const char *dev_name, u8 index,
-   const char *phy_dev_name)
-{
-   struct usb_phy_bind *phy_bind;
-   unsigned long flags;
-
-   phy_bind = kzalloc(sizeof(*phy_bind), GFP_KERNEL);
-   if (!phy_bind)
-   return -ENOMEM;
-
-   phy_bind->dev_name = dev_name;
-   phy_bind->phy_dev_name = phy_dev_name;
-   phy_bind->index = index;
-
-   spin_lock_irqsave(_lock, flags);
-   list_add_tail(_bind->list, _bind_list);
-   spin_unlock_irqrestore(_lock, flags);
-
-   return 0;
-}
-EXPORT_SYMBOL_GPL(usb_bind_phy);
-
 /**
  * usb_phy_set_event - set event to phy event
  * @x: the phy returned by usb_get_phy();
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index b7a2625947f5..ac5a079161e1 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -242,8 +242,6 @@ extern struct usb_phy *devm_usb_get_phy_by_node(struct 
device *dev,
struct device_node *node, struct notifier_block *nb);
 extern void usb_put_phy(struct usb_phy *);
 extern void devm_usb_put_phy(struct device *dev, struct usb_phy *x);
-extern int usb_bind_phy(const char *dev_name, u8 index,
-   const char *phy_dev_name);
 extern void usb_phy_set_event(struct usb_phy *x, unsigned long event);
 extern void usb_phy_set_charger_current(struct usb_phy *usb_phy,
unsigned int mA);
@@ -293,12 +291,6 @@ static inline void devm_usb_put_phy(struct device *dev, 
struct usb_phy *x)
 {
 }
 
-static inline int usb_bind_phy(const char *dev_name, u8 index,
-   const char *phy_dev_name)
-{
-   return -EOPNOTSUPP;
-}
-
 static inline void usb_phy_set_event(struct usb_phy *x, unsigned long event)
 {
 }
-- 
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 v2 6/6] USB: phy: drop legacy board-file support

[Johan Hovold]

The legacy interface for associating controllers with phys from board
files and platform code has been unused since commit 9080b8dc761a ("ARM:
OMAP2+: Remove legacy usb-host.c platform init code"). Since then, all
calls to usb_get_phy_dev() and its devres version have been returning
-ENODEV.

Now that the final calls to these functions have been removed, we can
drop this legacy lookup interface altogether.

Signed-off-by: Johan Hovold 
---
 drivers/usb/phy/phy.c   | 99 +
 include/linux/usb/phy.h | 28 
 2 files changed, 2 insertions(+), 125 deletions(-)

diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index 833547b00383..0277f62739a2 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -27,7 +27,6 @@
 #define DEFAULT_ACA_CUR_MAX5000
 
 static LIST_HEAD(phy_list);
-static LIST_HEAD(phy_bind_list);
 static DEFINE_SPINLOCK(phy_lock);
 
 struct phy_devm {
@@ -50,24 +49,6 @@ static struct usb_phy *__usb_find_phy(struct list_head *list,
return ERR_PTR(-ENODEV);
 }
 
-static struct usb_phy *__usb_find_phy_dev(struct device *dev,
-   struct list_head *list, u8 index)
-{
-   struct usb_phy_bind *phy_bind = NULL;
-
-   list_for_each_entry(phy_bind, list, list) {
-   if (!(strcmp(phy_bind->dev_name, dev_name(dev))) &&
-   phy_bind->index == index) {
-   if (phy_bind->phy)
-   return phy_bind->phy;
-   else
-   return ERR_PTR(-EPROBE_DEFER);
-   }
-   }
-
-   return ERR_PTR(-ENODEV);
-}
-
 static struct usb_phy *__of_usb_find_phy(struct device_node *node)
 {
struct usb_phy  *phy;
@@ -584,72 +565,6 @@ struct usb_phy *devm_usb_get_phy_by_phandle(struct device 
*dev,
 }
 EXPORT_SYMBOL_GPL(devm_usb_get_phy_by_phandle);
 
-/**
- * usb_get_phy_dev - find the USB PHY
- * @dev - device that requests this phy
- * @index - the index of the phy
- *
- * Returns the phy driver, after getting a refcount to it; or
- * -ENODEV if there is no such phy.  The caller is responsible for
- * calling usb_put_phy() to release that count.
- *
- * For use by USB host and peripheral drivers.
- */
-struct usb_phy *usb_get_phy_dev(struct device *dev, u8 index)
-{
-   struct usb_phy  *phy = NULL;
-   unsigned long   flags;
-
-   spin_lock_irqsave(_lock, flags);
-
-   phy = __usb_find_phy_dev(dev, _bind_list, index);
-   if (IS_ERR(phy) || !try_module_get(phy->dev->driver->owner)) {
-   dev_dbg(dev, "unable to find transceiver\n");
-   if (!IS_ERR(phy))
-   phy = ERR_PTR(-ENODEV);
-
-   goto err0;
-   }
-
-   get_device(phy->dev);
-
-err0:
-   spin_unlock_irqrestore(_lock, flags);
-
-   return phy;
-}
-EXPORT_SYMBOL_GPL(usb_get_phy_dev);
-
-/**
- * devm_usb_get_phy_dev - find the USB PHY using device ptr and index
- * @dev - device that requests this phy
- * @index - the index of the phy
- *
- * Gets the phy using usb_get_phy_dev(), and associates a device with it using
- * devres. On driver detach, release function is invoked on the devres data,
- * then, devres data is freed.
- *
- * For use by USB host and peripheral drivers.
- */
-struct usb_phy *devm_usb_get_phy_dev(struct device *dev, u8 index)
-{
-   struct usb_phy **ptr, *phy;
-
-   ptr = devres_alloc(devm_usb_phy_release, sizeof(*ptr), GFP_KERNEL);
-   if (!ptr)
-   return NULL;
-
-   phy = usb_get_phy_dev(dev, index);
-   if (!IS_ERR(phy)) {
-   *ptr = phy;
-   devres_add(dev, ptr);
-   } else
-   devres_free(ptr);
-
-   return phy;
-}
-EXPORT_SYMBOL_GPL(devm_usb_get_phy_dev);
-
 /**
  * devm_usb_put_phy - release the USB PHY
  * @dev - device that wants to release this phy
@@ -745,7 +660,6 @@ EXPORT_SYMBOL_GPL(usb_add_phy);
  */
 int usb_add_phy_dev(struct usb_phy *x)
 {
-   struct usb_phy_bind *phy_bind;
unsigned long flags;
int ret;
 
@@ -762,13 +676,9 @@ int usb_add_phy_dev(struct usb_phy *x)
ATOMIC_INIT_NOTIFIER_HEAD(>notifier);
 
spin_lock_irqsave(_lock, flags);
-   list_for_each_entry(phy_bind, _bind_list, list)
-   if (!(strcmp(phy_bind->phy_dev_name, dev_name(x->dev
-   phy_bind->phy = x;
-
list_add_tail(>head, _list);
-
spin_unlock_irqrestore(_lock, flags);
+
return 0;
 }
 EXPORT_SYMBOL_GPL(usb_add_phy_dev);
@@ -782,15 +692,10 @@ EXPORT_SYMBOL_GPL(usb_add_phy_dev);
 void usb_remove_phy(struct usb_phy *x)
 {
unsigned long   flags;
-   struct usb_phy_bind *phy_bind;
 
spin_lock_irqsave(_lock, flags);
-   if (x) {
-   list_for_each_entry(phy_bind, _bind_list, list)
-   if (phy_bind->phy == x)
-   phy_bind->phy = NULL;
+   if (x)

Re: [PATCH 5/6] USB: renesas_usbhs: drop support for legacy phys

[Johan Hovold]

On Wed, Apr 18, 2018 at 08:50:10AM +, Yoshihiro Shimoda wrote:
> Hi,
> 
> > From: Johan Hovold, Sent: Wednesday, April 18, 2018 5:42 PM

> > How about
> > 
> > USB: renesas_usbhs: drop unused legacy-phy support
> > 
> > and then I amend the commit message with a note about the legacy API
> > still being used in gadget mode to bind the peripheral controller?
> 
> It sounds good to me.
> When you submit v2 patch, would you add my Acked-by?
> 
> Acked-by: Yoshihiro Shimoda 

Will do. Thanks again!

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

RE: [PATCH 5/6] USB: renesas_usbhs: drop support for legacy phys

[Yoshihiro Shimoda]

Hi,

> From: Johan Hovold, Sent: Wednesday, April 18, 2018 5:42 PM
> 
> On Wed, Apr 18, 2018 at 04:22:31AM +, Yoshihiro Shimoda wrote:
> > Hi,
> >
> > > From: Johan Hovold, Sent: Saturday, April 14, 2018 10:06 PM
> > >
> > > Drop support for legacy phys which hasn't been used with a mainline
> > > kernel since commit 9080b8dc761a ("ARM: OMAP2+: Remove legacy usb-host.c
> > > platform init code"). Specifically, since that commit usb_get_phy_dev()
> > > have always returned -ENODEV and consequently this code has not been
> > > used.
> > >
> > > Signed-off-by: Johan Hovold 
> > > ---
> > >  drivers/usb/renesas_usbhs/common.h |  1 -
> > >  drivers/usb/renesas_usbhs/rcar2.c  | 29 -
> > >  2 files changed, 30 deletions(-)
> >
> > Thank you for the patch!
> > The drivers/usb/renesas_usbhs/mod_gadget.c still uses the legacy phy
> > API (usb_get_phy()).
> > Also this patch set doesn't drop the API. So, I think this subject
> > should be changed.
> > What do you think?
> 
> Good point, I'll try to rephrase it.
> 
> How about
> 
>   USB: renesas_usbhs: drop unused legacy-phy support
> 
> and then I amend the commit message with a note about the legacy API
> still being used in gadget mode to bind the peripheral controller?

It sounds good to me.
When you submit v2 patch, would you add my Acked-by?

Acked-by: Yoshihiro Shimoda 

Best regards,
Yoshihiro Shimoda

> > Dropping usb_get_phy_dev() from this driver is good to me.
> 
> Thanks,
> Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC 08/11] usb: role: rcar-usb3-role-switch: add support for R-Car SoCs

[Geert Uytterhoeven]

Hi Shimoda-san,

On Wed, Apr 18, 2018 at 10:10 AM, Yoshihiro Shimoda
 wrote:
> This patch adds role switch support for R-Car SoCs. 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 contains the USB 3.0 peripheral
> controller side only. So, the USB 3.0 peripheral driver (renesas_usb3)
> manages this register. 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 by a driver, this role switch driver manages
> the mode change register and attach/release the xhci-plat driver.
> The renesas_usb3 udc driver should call devm_of_platform_populate()
> to probe this driver.
>
> Signed-off-by: Yoshihiro Shimoda 

Thanks for your patch!

> --- a/drivers/usb/roles/Kconfig
> +++ b/drivers/usb/roles/Kconfig
> @@ -11,4 +11,16 @@ config USB_ROLES_INTEL_XHCI
>   To compile the driver as a module, choose M here: the module will
>   be called intel-xhci-usb-role-switch.
>
> +config USB_ROLES_RCAR_USB3
> +   tristate "Renesas R-Car USB3.0 Role Switch"
> +   depends on ARCH_RENESAS && OF

ARCH_RENESAS implies OF.

Perhaps you intended:

depends on OF
depends on ARCH_RENESAS || COMPILE_TEST

?

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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 5/6] USB: renesas_usbhs: drop support for legacy phys

[Johan Hovold]

On Wed, Apr 18, 2018 at 04:22:31AM +, Yoshihiro Shimoda wrote:
> Hi,
> 
> > From: Johan Hovold, Sent: Saturday, April 14, 2018 10:06 PM
> > 
> > Drop support for legacy phys which hasn't been used with a mainline
> > kernel since commit 9080b8dc761a ("ARM: OMAP2+: Remove legacy usb-host.c
> > platform init code"). Specifically, since that commit usb_get_phy_dev()
> > have always returned -ENODEV and consequently this code has not been
> > used.
> > 
> > Signed-off-by: Johan Hovold 
> > ---
> >  drivers/usb/renesas_usbhs/common.h |  1 -
> >  drivers/usb/renesas_usbhs/rcar2.c  | 29 -
> >  2 files changed, 30 deletions(-)
> 
> Thank you for the patch!
> The drivers/usb/renesas_usbhs/mod_gadget.c still uses the legacy phy
> API (usb_get_phy()).
> Also this patch set doesn't drop the API. So, I think this subject
> should be changed.
> What do you think?

Good point, I'll try to rephrase it.

How about

USB: renesas_usbhs: drop unused legacy-phy support

and then I amend the commit message with a note about the legacy API
still being used in gadget mode to bind the peripheral controller?

> Dropping usb_get_phy_dev() from this driver is good to me.

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

[PATCH/RFC 03/11] dt-bindings: usb: add Renesas R-Car USB 3.0 role switch driver

[Yoshihiro Shimoda]

This patch adds a new documentation for Renesas R-Car USB 3.0 role
switch driver.

Signed-off-by: Yoshihiro Shimoda 
---
 .../bindings/usb/renesas,rcar-usb3-role-sw.txt | 56 ++
 1 file changed, 56 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/usb/renesas,rcar-usb3-role-sw.txt

diff --git 
a/Documentation/devicetree/bindings/usb/renesas,rcar-usb3-role-sw.txt 
b/Documentation/devicetree/bindings/usb/renesas,rcar-usb3-role-sw.txt
new file mode 100644
index 000..ed60f66
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/renesas,rcar-usb3-role-sw.txt
@@ -0,0 +1,56 @@
+Renesas Electronics R-Car USB 3.0 role switch driver
+
+A renesas_usb3's node can contain this node.
+
+Required properties:
+ - compatible: Must contain "renesas,rcar-usb3-role-switch".
+
+Required nodes:
+
+The connection to a USB connector node and USB role switch node need by
+using OF graph bindings. Please refer to the usb-role-switch.txt about
+port number of the OF graph. Note that port@3 is connected to
+the usb-connector.
+
+
+Example of R-Car H3 ES2.0:
+   usb3_peri0: usb@ee02 {
+   compatible = "renesas,r8a7795-usb3-peri",
+"renesas,rcar-gen3-usb3-peri";
+   reg = <0 0xee02 0 0x400>;
+   interrupts = ;
+   clocks = < CPG_MOD 328>;
+   power-domains = < R8A7795_PD_ALWAYS_ON>;
+   resets = < 328>;
+
+   usb3-role-sw {
+   compatible = "renesas,rcar-usb3-role-switch";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   reg = <1>;
+
+   usb3_host_sw0: endpoint {
+   remote-endpoint = 
<_host_ep0>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+   usb3_peri_sw0: endpoint {
+   remote-endpoint = 
<_peri_ep0>;
+   device-connection-id = 
"usb-role-switch";
+   };
+   };
+
+   port@3 {
+   reg = <3>;
+   usb3_role_sw0_ep: endpoint {
+   };
+   };
+   };
+   };
+   };
-- 
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/RFC 02/11] dt-bindings: usb: add usb role switch driver

[Yoshihiro Shimoda]

This patch adds a new documentation for a usb role switch driver.
The usb role switch framework will parse this to get each device
pointer by using each remote-endpoint.

Signed-off-by: Yoshihiro Shimoda 
---
 .../devicetree/bindings/usb/usb-role-switch.txt| 42 ++
 1 file changed, 42 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/usb-role-switch.txt

diff --git a/Documentation/devicetree/bindings/usb/usb-role-switch.txt 
b/Documentation/devicetree/bindings/usb/usb-role-switch.txt
new file mode 100644
index 000..941d582
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb-role-switch.txt
@@ -0,0 +1,42 @@
+USB role switch driver
+
+Optional nodes:
+- If a role switch driver has OF graph ports, the usb role switch framework
+  will parse the remote-endpoints in usb_role_switch_register(). The OF graph
+  port number as follows:
+0: USB 2.0 host port
+1: USB 3.0 host port
+2: UDC port
+
+For example:
+   usb-role-sw {
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   usb2_host_sw0: endpoint {
+   remote-endpoint = <_host_ep0>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   usb3_host_sw0: endpoint {
+   remote-endpoint = <_host_ep0>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+
+   udc_sw0: endpoint {
+   remote-endpoint = <_ep0>;
+   };
+   };
+   };
+   };
-- 
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/RFC 08/11] usb: role: rcar-usb3-role-switch: add support for R-Car SoCs

[Yoshihiro Shimoda]

This patch adds role switch support for R-Car SoCs. 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 contains the USB 3.0 peripheral
controller side only. So, the USB 3.0 peripheral driver (renesas_usb3)
manages this register. 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 by a driver, this role switch driver manages
the mode change register and attach/release the xhci-plat driver.
The renesas_usb3 udc driver should call devm_of_platform_populate()
to probe this driver.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/roles/Kconfig |  12 ++
 drivers/usb/roles/Makefile|   1 +
 drivers/usb/roles/rcar-usb3-role-switch.c | 179 ++
 3 files changed, 192 insertions(+)
 create mode 100644 drivers/usb/roles/rcar-usb3-role-switch.c

diff --git a/drivers/usb/roles/Kconfig b/drivers/usb/roles/Kconfig
index f5a5e6f..429d784 100644
--- a/drivers/usb/roles/Kconfig
+++ b/drivers/usb/roles/Kconfig
@@ -11,4 +11,16 @@ config USB_ROLES_INTEL_XHCI
  To compile the driver as a module, choose M here: the module will
  be called intel-xhci-usb-role-switch.
 
+config USB_ROLES_RCAR_USB3
+   tristate "Renesas R-Car USB3.0 Role Switch"
+   depends on ARCH_RENESAS && OF
+   help
+ Driver for the internal USB role switch for switching the USB data
+ lines between the xHCI host controller and the Renesas gadget
+ controller (by using renesas_usb3 driver) found on various Renesas
+ R-Car SoCs.
+
+ To compile the driver as a module, choose M here: the module will
+ be called rcar-usb3-role-switch.
+
 endif # USB_ROLE_SWITCH
diff --git a/drivers/usb/roles/Makefile b/drivers/usb/roles/Makefile
index e44b179..7ce3be3 100644
--- a/drivers/usb/roles/Makefile
+++ b/drivers/usb/roles/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_USB_ROLES_INTEL_XHCI) += intel-xhci-usb-role-switch.o
+obj-$(CONFIG_USB_ROLES_RCAR_USB3) += rcar-usb3-role-switch.o
diff --git a/drivers/usb/roles/rcar-usb3-role-switch.c 
b/drivers/usb/roles/rcar-usb3-role-switch.c
new file mode 100644
index 000..9b56945
--- /dev/null
+++ b/drivers/usb/roles/rcar-usb3-role-switch.c
@@ -0,0 +1,179 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Renesas R-Car USB 3.0 role switch driver
+ *
+ * Copyright (C) 2018  Renesas Electronics Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define USB3_DRD_CON   0x218
+#define DRD_CON_PERI_CON   BIT(24)
+
+struct rcar_usb3_role_switch {
+   struct usb_role_switch *role_sw;
+   void __iomem *reg;
+   enum usb_role save_role;/* for suspend/resume */
+};
+
+static enum usb_role
+rcar_usb3_role_switch_get_mode(struct rcar_usb3_role_switch *rcar_sw)
+{
+   u32 val = readl(rcar_sw->reg + USB3_DRD_CON);
+
+   if (val & DRD_CON_PERI_CON)
+   return USB_ROLE_DEVICE;
+
+   return USB_ROLE_HOST;
+}
+
+static void
+rcar_usb3_role_switch_set_mode(struct rcar_usb3_role_switch *rcar_sw,
+  bool host)
+{
+   void __iomem *drd_con = rcar_sw->reg + USB3_DRD_CON;
+
+   if (host)
+   writel(readl(drd_con) & ~DRD_CON_PERI_CON, drd_con);
+   else
+   writel(readl(drd_con) | DRD_CON_PERI_CON, drd_con);
+}
+
+static int rcar_usb3_role_switch_set_role(struct device *dev,
+ enum usb_role role)
+{
+   struct rcar_usb3_role_switch *rcar_sw = dev_get_drvdata(dev);
+   struct device *host = usb_role_switch_get_usb3_port(rcar_sw->role_sw);
+   enum usb_role cur_role;
+
+   pm_runtime_get_sync(dev->parent);
+
+   cur_role = rcar_usb3_role_switch_get_mode(rcar_sw);
+   if (cur_role == USB_ROLE_HOST && role == USB_ROLE_DEVICE) {
+   device_release_driver(host);
+   rcar_usb3_role_switch_set_mode(rcar_sw, false);
+   } else if (cur_role == USB_ROLE_DEVICE && role == USB_ROLE_HOST) {
+   /* Must set the mode before device_attach of the host */
+   rcar_usb3_role_switch_set_mode(rcar_sw, true);
+   if (device_attach(host) < 0)
+   dev_err(dev, "device_attach(usb3_port) failed\n");
+   }
+
+   pm_runtime_put(dev->parent);
+
+   return 0;
+}
+
+static enum usb_role rcar_usb3_role_switch_get_role(struct device *dev)
+{
+   struct rcar_usb3_role_switch *rcar_sw = dev_get_drvdata(dev);
+   enum usb_role cur_role;
+
+   pm_runtime_get(dev->parent);
+   cur_role = rcar_usb3_role_switch_get_mode(rcar_sw);
+   pm_runtime_put(dev->parent);
+
+   

[PATCH/RFC 05/11] usb: common: roles: add fwnode graph parsing

[Yoshihiro Shimoda]

This patch adds fwnode graph parsing to set usb[23]_port and udc
into the usb_role_switch structure by usb_role_switch_register().

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/common/roles.c | 40 +++-
 1 file changed, 39 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/common/roles.c b/drivers/usb/common/roles.c
index 15cc76e..cc1c55a 100644
--- a/drivers/usb/common/roles.c
+++ b/drivers/usb/common/roles.c
@@ -11,6 +11,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 static struct class *role_class;
@@ -219,6 +221,42 @@ static void usb_role_switch_release(struct device *dev)
.release = usb_role_switch_release,
 };
 
+static void usb_role_parse_fwnode_graph(struct usb_role_switch *sw)
+{
+   struct fwnode_handle *parent = sw->dev.parent->fwnode;
+   struct fwnode_handle *child_ep, *child_port;
+   struct fwnode_handle *remote;
+   /* This order comes from DT bindings */
+   struct device **dev[] = {
+   >usb2_port,
+   >usb3_port,
+   >udc,
+   };
+   u32 port;
+
+   fwnode_graph_for_each_endpoint(parent, child_ep) {
+   child_port = fwnode_get_parent(child_ep);
+   if (!child_port)
+   continue;
+
+   if (fwnode_property_read_u32(child_port, "reg", ) < 0)
+   continue;
+
+   if (port >= ARRAY_SIZE(dev))
+   break;
+
+   remote = fwnode_graph_get_remote_port_parent(child_ep);
+   if (remote) {
+   struct device_node *remote_np = to_of_node(remote);
+   struct platform_device *pdev;
+
+   pdev = of_find_device_by_node(remote_np);
+   if (pdev)
+   *dev[port] = >dev;
+   }
+   };
+}
+
 /**
  * usb_role_switch_register - Register USB Role Switch
  * @parent: Parent device for the switch
@@ -267,7 +305,7 @@ struct usb_role_switch *
return ERR_PTR(ret);
}
 
-   /* TODO: Symlinks for the host port and the device controller. */
+   usb_role_parse_fwnode_graph(sw);
 
return sw;
 }
-- 
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/RFC 11/11] arm64: dts: renesas: r8a7795: salvator-xs: add OF graph for usb role switch

[Yoshihiro Shimoda]

This patch adds OF graph properties for usb role switch.

TODO:
 - Each node should be in salvator-common.dtsi.

Signed-off-by: Yoshihiro Shimoda 
---
 .../arm64/boot/dts/renesas/r8a7795-salvator-xs.dts | 28 ++
 1 file changed, 28 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts 
b/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
index 8b50ceb..c815fca 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
@@ -36,6 +36,24 @@
device_type = "memory";
reg = <0x7 0x 0x0 0x4000>;
};
+
+   /* TODO: should be into salvator-common.dtsi */
+   usb3 {
+   compatible = "usb-a-connector";
+   label = "USB3_0";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   reg = <1>;
+   usb3_connector0: endpoint {
+   remote-endpoint = <_role_sw0_ep>;
+   };
+   };
+   };
+   };
 };
 
  {
@@ -107,3 +125,13 @@
 
status = "okay";
 };
+
+   _role_sw0 {
+   ports {
+   port@3 {
+   usb3_role_sw0_ep: endpoint {
+   remote-endpoint = <_connector0>;
+   };
+   };
+   };
+   };
-- 
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/RFC 00/11] add support for R-Car USB3.0 role switch

[Yoshihiro Shimoda]

This patch set is based on v4.17-rc1.

In last week, I submitted a patch as v1 [1]. But, the v1 patch
doesn't use graphs to get usb host device pointer. So, I modified
some frameworks for it.
Since the patch 4 "of: platform: add device connection parsing"
has TODOs, I marked this patch set as "RFC". Before I resolve them,
I would like to know whether this way is good or not.

[1] https://patchwork.kernel.org/patch/10332865/


Yoshihiro Shimoda (11):
  Documentation: of: Add device-connection-id property
  dt-bindings: usb: add usb role switch driver
  dt-bindings: usb: add Renesas R-Car USB 3.0 role switch driver
  of: platform: add device connection parsing
  usb: common: roles: add fwnode graph parsing
  usb: common: roles: Allow if the parent dev_name matches
  usb: common: roles: add getting device pointer APIs
  usb: role: rcar-usb3-role-switch: add support for R-Car SoCs
  usb: gadget: udc: renesas_usb3: add support for a usb role switch
  arm64: dts: renesas: r8a7795: add OF graph for usb role switch
  arm64: dts: renesas: r8a7795: salvator-xs: add OF graph for usb role
switch

 Documentation/devicetree/bindings/graph.txt|   2 +-
 .../bindings/usb/renesas,rcar-usb3-role-sw.txt |  56 +++
 .../devicetree/bindings/usb/usb-role-switch.txt|  42 +
 .../arm64/boot/dts/renesas/r8a7795-salvator-xs.dts |  28 
 arch/arm64/boot/dts/renesas/r8a7795.dtsi   |  44 +
 drivers/of/platform.c  |  66 
 drivers/usb/common/roles.c |  84 +-
 drivers/usb/gadget/udc/Kconfig |   1 +
 drivers/usb/gadget/udc/renesas_usb3.c  |  34 +++-
 drivers/usb/roles/Kconfig  |  12 ++
 drivers/usb/roles/Makefile |   1 +
 drivers/usb/roles/rcar-usb3-role-switch.c  | 179 +
 include/linux/of.h |   1 +
 include/linux/usb/role.h   |   4 +
 14 files changed, 545 insertions(+), 9 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/usb/renesas,rcar-usb3-role-sw.txt
 create mode 100644 Documentation/devicetree/bindings/usb/usb-role-switch.txt
 create mode 100644 drivers/usb/roles/rcar-usb3-role-switch.c

-- 
1.9.1

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

[PATCH/RFC 09/11] usb: gadget: udc: renesas_usb3: add support for a usb role switch

[Yoshihiro Shimoda]

This patch adds support for a usb role switch driver. And then,
this driver uses the usb role switch APIs instead of hardware
access to initialize usb host side at specific timings.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/gadget/udc/Kconfig|  1 +
 drivers/usb/gadget/udc/renesas_usb3.c | 34 --
 2 files changed, 29 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig
index 0875d38..7e4a5dd 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 409cde4..38dd759 100644
--- a/drivers/usb/gadget/udc/renesas_usb3.c
+++ b/drivers/usb/gadget/udc/renesas_usb3.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* register definitions */
 #define USB3_AXI_INT_STA   0x008
@@ -330,6 +331,7 @@ struct renesas_usb3 {
 
struct usb_gadget gadget;
struct usb_gadget_driver *driver;
+   struct usb_role_switch *role_sw;/* Optional */
struct extcon_dev *extcon;
struct work_struct extcon_work;
struct phy *phy;
@@ -454,7 +456,11 @@ static void usb3_disable_pipe_irq(struct renesas_usb3 
*usb3, int num)
 
 static bool usb3_is_host(struct renesas_usb3 *usb3)
 {
-   return !(usb3_read(usb3, USB3_DRD_CON) & DRD_CON_PERI_CON);
+   if (usb3->role_sw)
+   return usb_role_switch_get_role(usb3->role_sw) ==
+   USB_ROLE_HOST ? true : false;
+   else
+   return !(usb3_read(usb3, USB3_DRD_CON) & DRD_CON_PERI_CON);
 }
 
 static void usb3_init_axi_bridge(struct renesas_usb3 *usb3)
@@ -645,10 +651,16 @@ static void usb3_check_vbus(struct renesas_usb3 *usb3)
 
 static void usb3_set_mode(struct renesas_usb3 *usb3, bool host)
 {
-   if (host)
-   usb3_clear_bit(usb3, DRD_CON_PERI_CON, USB3_DRD_CON);
-   else
-   usb3_set_bit(usb3, DRD_CON_PERI_CON, USB3_DRD_CON);
+   if (usb3->role_sw) {
+   enum usb_role role = host ? USB_ROLE_HOST : USB_ROLE_DEVICE;
+
+   usb_role_switch_set_role(usb3->role_sw, role);
+   } else {
+   if (host)
+   usb3_clear_bit(usb3, DRD_CON_PERI_CON, USB3_DRD_CON);
+   else
+   usb3_set_bit(usb3, DRD_CON_PERI_CON, USB3_DRD_CON);
+   }
 }
 
 static void usb3_vbus_out(struct renesas_usb3 *usb3, bool enable)
@@ -663,8 +675,8 @@ static void usb3_mode_config(struct renesas_usb3 *usb3, 
bool host, bool a_dev)
 {
unsigned long flags;
 
-   spin_lock_irqsave(>lock, flags);
usb3_set_mode(usb3, host);
+   spin_lock_irqsave(>lock, flags);
usb3_vbus_out(usb3, a_dev);
/* for A-Peripheral or forced B-device mode */
if ((!host && a_dev) ||
@@ -2238,6 +2250,10 @@ static int renesas_usb3_start(struct usb_gadget *gadget,
/* hook up the driver */
usb3->driver = driver;
 
+   usb3->role_sw = usb_role_switch_get(usb3_to_dev(usb3));
+   if (IS_ERR_OR_NULL(usb3->role_sw))
+   usb3->role_sw = NULL;
+
if (usb3->phy)
phy_init(usb3->phy);
 
@@ -2260,6 +2276,8 @@ static int renesas_usb3_stop(struct usb_gadget *gadget)
if (usb3->phy)
phy_exit(usb3->phy);
 
+   usb_role_switch_put(usb3->role_sw);
+
pm_runtime_put(usb3_to_dev(usb3));
 
return 0;
@@ -2632,6 +2650,10 @@ static int renesas_usb3_probe(struct platform_device 
*pdev)
if (ret < 0)
goto err_add_udc;
 
+   ret = devm_of_platform_populate(>dev);
+   if (ret < 0)
+   goto err_dev_create;
+
ret = device_create_file(>dev, _attr_role);
if (ret < 0)
goto err_dev_create;
-- 
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/RFC 07/11] usb: common: roles: add getting device pointer APIs

[Yoshihiro Shimoda]

This patch adds APIs that a role switch driver can get device pointer
of USB 2.0/3.0 and udc.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/common/roles.c | 36 
 include/linux/usb/role.h   |  4 
 2 files changed, 40 insertions(+)

diff --git a/drivers/usb/common/roles.c b/drivers/usb/common/roles.c
index 381259c..5fd14b2 100644
--- a/drivers/usb/common/roles.c
+++ b/drivers/usb/common/roles.c
@@ -34,6 +34,42 @@ struct usb_role_switch {
 #define to_role_switch(d)  container_of(d, struct usb_role_switch, dev)
 
 /**
+ * usb_role_switch_get_usb2_port - Get device of a USB 2.0 host
+ * @sw: USB role switch
+ *
+ * Returns USB 2.0 host device pointer.
+ */
+struct device *usb_role_switch_get_usb2_port(struct usb_role_switch *sw)
+{
+   return sw->usb2_port;
+}
+EXPORT_SYMBOL(usb_role_switch_get_usb2_port);
+
+/**
+ * usb_role_switch_get_usb3_port - Get device of a USB 3.0 host
+ * @sw: USB role switch
+ *
+ * Returns USB 3.0 host device pointer.
+ */
+struct device *usb_role_switch_get_usb3_port(struct usb_role_switch *sw)
+{
+   return sw->usb3_port;
+}
+EXPORT_SYMBOL(usb_role_switch_get_usb3_port);
+
+/**
+ * usb_role_switch_get_udc - Get device of a udc
+ * @sw: USB role switch
+ *
+ * Returns udc device pointer.
+ */
+struct device *usb_role_switch_get_udc(struct usb_role_switch *sw)
+{
+   return sw->udc;
+}
+EXPORT_SYMBOL(usb_role_switch_get_udc);
+
+/**
  * usb_role_switch_set_role - Set USB role for a switch
  * @sw: USB role switch
  * @role: USB role to be switched to
diff --git a/include/linux/usb/role.h b/include/linux/usb/role.h
index edc51be..c7eb73b 100644
--- a/include/linux/usb/role.h
+++ b/include/linux/usb/role.h
@@ -40,6 +40,10 @@ struct usb_role_switch_desc {
bool allow_userspace_control;
 };
 
+struct device *usb_role_switch_get_usb2_port(struct usb_role_switch *sw);
+struct device *usb_role_switch_get_usb3_port(struct usb_role_switch *sw);
+struct device *usb_role_switch_get_udc(struct usb_role_switch *sw);
+
 int usb_role_switch_set_role(struct usb_role_switch *sw, enum usb_role role);
 enum usb_role usb_role_switch_get_role(struct usb_role_switch *sw);
 struct usb_role_switch *usb_role_switch_get(struct device *dev);
-- 
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/RFC 04/11] of: platform: add device connection parsing

[Yoshihiro Shimoda]

This patch adds device connection parsing in of_platform_populate().

TODO:
 - How to free the devcon memories?
 - How to remove the devcon instances?

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/of/platform.c | 66 +++
 include/linux/of.h|  1 +
 2 files changed, 67 insertions(+)

diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index c00d81d..41c018d 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -326,6 +327,63 @@ static const struct of_dev_auxdata *of_dev_lookup(const 
struct of_dev_auxdata *l
return NULL;
 }
 
+static int of_parse_device_connection(struct device_node *np)
+{
+   struct device_node *child_ep, *parent, *remote_parent;
+   struct platform_device *pdev, *remote_pdev;
+   struct device_connection *devcon = NULL;
+   const char *id;
+
+   if (of_node_check_flag(np, OF_DEVICE_CONNECTED)) {
+   pr_debug("%s() - skipping %pOF, already device connected\n",
+   __func__, np);
+   return 0;
+   }
+
+   of_node_set_flag(np, OF_DEVICE_CONNECTED);
+
+   for_each_endpoint_of_node(np, child_ep) {
+   if (of_property_read_string(child_ep, "device-connection-id",
+   ) < 0)
+   continue;
+
+   remote_parent = of_graph_get_remote_port_parent(child_ep);
+   if (!remote_parent)
+   return 0;
+
+   parent = of_graph_get_port_parent(child_ep);
+   if (!parent)
+   return 0;
+
+   pdev = of_find_device_by_node(parent);
+   if (!pdev)
+   return 0;
+
+   /*
+* WARN_ON in really_probe() may happen if devm_kzalloc is
+* used. TODO: How to free this?
+*/
+   devcon = kzalloc(sizeof(*devcon), GFP_KERNEL);
+   if (!devcon)
+   return -ENOMEM;
+
+   devcon->id = id;
+   remote_pdev = of_find_device_by_node(remote_parent);
+   if (!remote_pdev) {
+   kfree(devcon);
+   return 0;
+   }
+
+   devcon->endpoint[0] = dev_name(>dev);
+   devcon->endpoint[1] = dev_name(_pdev->dev);
+
+   /* TODO: How to remove the connection? */
+   device_connection_add(devcon);
+   }
+
+   return 0;
+}
+
 /**
  * of_platform_bus_create() - Create a device for a node and its children.
  * @bus: device node of the bus to instantiate
@@ -477,6 +535,14 @@ int of_platform_populate(struct device_node *root,
}
of_node_set_flag(root, OF_POPULATED_BUS);
 
+   for_each_child_of_node(root, child) {
+   rc = of_parse_device_connection(child);
+   if (rc) {
+   of_node_put(child);
+   break;
+   }
+   }
+
of_node_put(root);
return rc;
 }
diff --git a/include/linux/of.h b/include/linux/of.h
index 4d25e4f..30aa103 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -143,6 +143,7 @@ static inline void of_node_put(struct device_node *node) { }
 #define OF_DETACHED2 /* node has been detached from the device tree */
 #define OF_POPULATED   3 /* device already created for the node */
 #define OF_POPULATED_BUS   4 /* of_platform_populate recursed to children 
of this node */
+#define OF_DEVICE_CONNECTED5 /* checked devcon on of_platform_populate */
 
 #define OF_BAD_ADDR((u64)-1)
 
-- 
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/RFC 01/11] Documentation: of: Add device-connection-id property

[Yoshihiro Shimoda]

This patch adds a new property for device connection framework.

Signed-off-by: Yoshihiro Shimoda 
---
 Documentation/devicetree/bindings/graph.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/graph.txt 
b/Documentation/devicetree/bindings/graph.txt
index 0415e2c..fca0030 100644
--- a/Documentation/devicetree/bindings/graph.txt
+++ b/Documentation/devicetree/bindings/graph.txt
@@ -125,4 +125,4 @@ Optional endpoint properties
 
 
 - remote-endpoint: phandle to an 'endpoint' subnode of a remote device node.
-
+- device-connection-id: string for device connection.
-- 
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/RFC 10/11] arm64: dts: renesas: r8a7795: add OF graph for usb role switch

[Yoshihiro Shimoda]

This patch adds OF graph properties for usb role switch in r8a7795.

Signed-off-by: Yoshihiro Shimoda 
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 44 
 1 file changed, 44 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 1d5e3ac..61c1fa0 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -1746,6 +1746,12 @@
power-domains = < R8A7795_PD_ALWAYS_ON>;
resets = < 328>;
status = "disabled";
+
+   port {
+   usb3_host_ep0: endpoint {
+   remote-endpoint = <_host_ep0>;
+   };
+   };
};
 
usb3_peri0: usb@ee02 {
@@ -1757,6 +1763,44 @@
power-domains = < R8A7795_PD_ALWAYS_ON>;
resets = < 328>;
status = "disabled";
+
+   port {
+   usb3_peri_ep0: endpoint {
+   remote-endpoint = <_peri_sw0>;
+   };
+   };
+
+   usb3_role_sw0: usb3-role-sw {
+   compatible = "renesas,rcar-usb3-role-switch";
+   renesas,host = <>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   reg = <1>;
+
+   usb3_host_sw0: endpoint {
+   remote-endpoint = 
<_host_ep0>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+   usb3_peri_sw0: endpoint {
+   remote-endpoint = 
<_peri_ep0>;
+   device-connection-id = 
"usb-role-switch";
+   };
+   };
+
+   port@3 {
+   reg = <3>;
+   usb3_role_sw0_ep: endpoint {
+   };
+   };
+   };
+   };
};
 
usb_dmac0: dma-controller@e65a {
-- 
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/RFC 06/11] usb: common: roles: Allow if the parent dev_name matches

[Yoshihiro Shimoda]

THis patch adds a condition in __switch_match() to allow if
the parent dev_name matches. Otherwise, OF environment cannot match
the usb role switch devices because the usb role switch framework
adds the names of a new child device as the parent dev_name with
"-role-switch".

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/common/roles.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/common/roles.c b/drivers/usb/common/roles.c
index cc1c55a..381259c 100644
--- a/drivers/usb/common/roles.c
+++ b/drivers/usb/common/roles.c
@@ -88,7 +88,13 @@ enum usb_role usb_role_switch_get_role(struct 
usb_role_switch *sw)
 
 static int __switch_match(struct device *dev, const void *name)
 {
-   return !strcmp((const char *)name, dev_name(dev));
+   int ret = !strcmp((const char *)name, dev_name(dev));
+
+   /* If doesn't match, this also checks the parent dev_name */
+   if (!ret && dev->parent)
+   ret = !strcmp((const char *)name, dev_name(dev->parent));
+
+   return ret;
 }
 
 static void *usb_role_switch_match(struct device_connection *con, int ep,
-- 
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 09/11] usb: musb: break the huge isr musb_stage0_irq() into small functions

[Dan Carpenter]

Hi Bin,

I love your patch! Perhaps something to improve:

[auto build test WARNING on balbi-usb/next]
[also build test WARNING on v4.17-rc1 next-20180417]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Bin-Liu/usb-musb-cleanup/20180417-133633
base:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next

smatch warnings:
drivers/usb/musb/musb_core.c:797 musb_handle_intr_connect() error: we 
previously assumed 'musb->hcd' could be null (see line 783)

# 
https://github.com/0day-ci/linux/commit/92be75b4fb79173759af42e50a81d0020e945c1e
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 92be75b4fb79173759af42e50a81d0020e945c1e
vim +797 drivers/usb/musb/musb_core.c

1c25fda4a Arnaud Mandy  2009-12-28  745  
92be75b4f Bin Liu   2018-04-16  746  static void 
musb_handle_intr_connect(struct musb *musb, u8 devctl, u8 int_usb)
92be75b4f Bin Liu   2018-04-16  747  {
8b125df5b Daniel Mack   2013-04-10  748 struct usb_hcd *hcd = 
musb->hcd;
550a7375f Felipe Balbi  2008-07-24  749  
550a7375f Felipe Balbi  2008-07-24  750 musb->is_active = 1;
550a7375f Felipe Balbi  2008-07-24  751 musb->ep0_stage = 
MUSB_EP0_START;
550a7375f Felipe Balbi  2008-07-24  752  
b18d26f6a Sebastian Andrzej Siewior 2012-10-30  753 musb->intrtxe = 
musb->epmask;
b18d26f6a Sebastian Andrzej Siewior 2012-10-30  754 
musb_writew(musb->mregs, MUSB_INTRTXE, musb->intrtxe);
af5ec14d4 Sebastian Andrzej Siewior 2012-10-30  755 musb->intrrxe = 
musb->epmask & 0xfffe;
af5ec14d4 Sebastian Andrzej Siewior 2012-10-30  756 
musb_writew(musb->mregs, MUSB_INTRRXE, musb->intrrxe);
d709d22ee Ajay Kumar Gupta  2010-07-08  757 
musb_writeb(musb->mregs, MUSB_INTRUSBE, 0xf7);
550a7375f Felipe Balbi  2008-07-24  758 musb->port1_status &= 
~(USB_PORT_STAT_LOW_SPEED
550a7375f Felipe Balbi  2008-07-24  759 
|USB_PORT_STAT_HIGH_SPEED
550a7375f Felipe Balbi  2008-07-24  760 
|USB_PORT_STAT_ENABLE
550a7375f Felipe Balbi  2008-07-24  761 
);
550a7375f Felipe Balbi  2008-07-24  762 musb->port1_status |= 
USB_PORT_STAT_CONNECTION
550a7375f Felipe Balbi  2008-07-24  763 
|(USB_PORT_STAT_C_CONNECTION << 16);
550a7375f Felipe Balbi  2008-07-24  764  
550a7375f Felipe Balbi  2008-07-24  765 /* high vs full speed 
is just a guess until after reset */
550a7375f Felipe Balbi  2008-07-24  766 if (devctl & 
MUSB_DEVCTL_LSDEV)
550a7375f Felipe Balbi  2008-07-24  767 
musb->port1_status |= USB_PORT_STAT_LOW_SPEED;
550a7375f Felipe Balbi  2008-07-24  768  
550a7375f Felipe Balbi  2008-07-24  769 /* indicate new 
connection to OTG machine */
e47d92545 Antoine Tenart2014-10-30  770 switch 
(musb->xceiv->otg->state) {
550a7375f Felipe Balbi  2008-07-24  771 case 
OTG_STATE_B_PERIPHERAL:
550a7375f Felipe Balbi  2008-07-24  772 if (int_usb & 
MUSB_INTR_SUSPEND) {
b99d3659b Bin Liu   2016-06-30  773 
musb_dbg(musb, "HNP: SUSPEND+CONNECT, now b_host");
550a7375f Felipe Balbi  2008-07-24  774 int_usb 
&= ~MUSB_INTR_SUSPEND;
1de00dae8 David Brownell2009-04-02  775 goto 
b_host;
550a7375f Felipe Balbi  2008-07-24  776 } else
b99d3659b Bin Liu   2016-06-30  777 
musb_dbg(musb, "CONNECT as b_peripheral???");
550a7375f Felipe Balbi  2008-07-24  778 break;
550a7375f Felipe Balbi  2008-07-24  779 case 
OTG_STATE_B_WAIT_ACON:
b99d3659b Bin Liu   2016-06-30  780 musb_dbg(musb, 
"HNP: CONNECT, now b_host");
1de00dae8 David Brownell2009-04-02  781  b_host:
e47d92545 Antoine Tenart2014-10-30  782 
musb->xceiv->otg->state = OTG_STATE_B_HOST;
74c2e9360 Daniel Mack   2013-04-10 @783 if (musb->hcd)
74c2e9360 Daniel Mack   2013-04-10  784 
musb->hcd->self.is_b_host = 1;
1de00dae8 David Brownell2009-04-02  785 
del_timer(>otg_timer);
550a7375f Felipe Balbi  2008-07-24  786 break;
550a7375f Felipe Balbi  2008-07-24  787 default:
550a7375f Felipe Balbi  2008-07-24  788 if ((devctl & 
MUSB_DEVCTL_VBUS)
550a7375f Felipe Balbi  2008-07-24  789 
== (3 << MUSB_DEVCTL_VBUS_SHIFT)) {
e47d92545 Antoine Tenart2014-10-30  

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

[Tushar Nimkar]

On 2018-04-17 12:03, Tushar Nimkar wrote:

On 2018-04-16 20:03, Oliver Neukum wrote:

Am Montag, den 16.04.2018, 10:23 -0400 schrieb Alan Stern:

> > > > [57246.701096] sd 1:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1
> > > > inflight: CMD IN
> > > > [57246.701130] sd 1:0:0:0: tag#0 CDB: opcode=0x1a 1a 00 3f 00 04 00
>
> URB is canceled, maybe that URB never finished?

No doubt.  Perhaps the device doesn't support this particular 
command.


Then we should expect the enumeration to always fail.
Possibly the lower layers swallow the transfer.


Note not every time abort with 0x1a command ..sometimes it is with
0x9e, 0x12, 0xa0.
As my observation issue is observed during read_capacity_16/REPORT_LUN
or INQUIRY.

Regards
Oliver



Oliver,

I have doubt that sequential scan(scsi_sequential_lun_scan) work well 
for uas device(SCSI>3)..
Why? As I have seen in most cases failed to enumerate during REPORT_LUN 
command...and there is older way to scan disk is also present,

so I was thinking to try that.. did following things

starget->no_report_luns = 1  ---> for my target while uas_target_alloc 
(for try)


Found it is doing sequential scan but popuating 256 entries in cat 
proc/partiction

for one disk
root@OpenWrt:/# cat proc/partitions
major minor  #blocks  name

   80  488386584 sda
   81  488384032 sda1
   8   48  488386584 sdd
   8   49  488384032 sdd1
   8   64  488386584 sde
   8   65  488384032 sde1
   8   80  488386584 sdf
   8   81  488384032 sdf1
   8   96  488386584 sdg
   8   97  488384032 sdg1
   8  112  488386584 sdh
   8  113  488384032 sdh1
  256 total.

...though it is SCSI>3 device ,it should support both sequential as well 
as REPORT_LUN?


refering bellow commit ..no idea how this Seagate device is using 
Sequential scan

commit 1363074667a6b7d0507527742ccd7bbed5e3ceaa
Author: Hans de Goede 
Date:   Tue Apr 12 12:27:09 2016 +0200

USB: uas: Add a new NO_REPORT_LUNS quirk

Add a new NO_REPORT_LUNS quirk and set it for Seagate drives with
an usb-id of: 0bc2:331a, as these will fail to respond to a
REPORT_LUNS command.

Cc: sta...@vger.kernel.org
Reported-and-tested-by: David Webb 
Signed-off-by: Hans de Goede 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman 

Do not know weather this is the cause for the issue or not ...but if so 
need to think on this too :)




--
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


--
Best Regards,
Tushar R Nimkar

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member of Code Aurora Forum, hosted by The Linux Foundation


--
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: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

[Tushar Nimkar]

On 2018-04-17 18:04, Mathias Nyman wrote:

On 17.04.2018 09:23, Tushar Nimkar wrote:

On 2018-04-16 18:46, Mathias Nyman wrote:

On 16.04.2018 13:20, Tushar Nimkar wrote:

On 2018-04-05 11:31, Felipe Balbi wrote:

Hi,

it would help if you would Cc XHCI's maintainer :-)

tnim...@codeaurora.org writes:


On 2018-04-04 19:28, Greg KH wrote:
On Wed, Apr 04, 2018 at 06:41:41PM +0530, tnim...@codeaurora.org 
wrote:

On 2018-04-04 18:07, Greg KH wrote:
> On Wed, Apr 04, 2018 at 05:14:50PM +0530, tnim...@codeaurora.org wrote:
> > Hi Oliver/Greg,
> >
> > I am able to duplicated the UAS issue on 4.16 as well.
> > The behavior is same new usb device detects and reset after aprox 30
> > sec(SD_TIMEOUT)
> > Logs are already shared below.
> >
> > We are using Synopsys dwc3 as host controller, May I know have
> > tested it
> > with dwc3?
> > I have tried it on Linux PC (x86 Ubuntu machine) I could not see the
> > issue.
> > It enumerates well.
>
> Great, stick with an x86 platform!  :)
>
> Looks like a dwc3 host controller issue, try enabling tracing and
> debugging in that driver when this happens to see what is going on.

Oh if so let me enable the trace for that. I will respond you on 
this.


I did not get much clue, Greg.  sometime this device enumerates 
well,

attached both working and non working case logs.
following is not working case
root@OpenWrt:/# dmesg


...

[57214.172683] xhci-hcd xhci-hcd.0.auto: ep 0x83 - asked for 112 
bytes,

96 bytes untransferred
[57214.172809] xhci-hcd xhci-hcd.0.auto: ep 0x83 - asked for 112 
bytes,

96 bytes untransferred
[57214.172840] sd 1:0:0:0: [sdb] 976773168 512-byte logical 
blocks: (500

GB/466 GiB)
[57214.172843] xhci-hcd xhci-hcd.0.auto: ep 0x81 - asked for 4096 
bytes,

4080 bytes untransferred
[57214.172851] xhci-hcd xhci-hcd.0.auto: ep 0x83 - asked for 112 
bytes,

96 bytes untransferred
[57214.253085] xhci-hcd xhci-hcd.0.auto: xhci_hub_status_data: 
stopping

port polling.


Huge gap before uas_eh_abort_eh_handler is called.


SD_TIMEOUT of 30 sec ...



[57246.701096] sd 1:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1
inflight: CMD IN
[57246.701130] sd 1:0:0:0: tag#0 CDB: opcode=0x1a 1a 00 3f 00 04 
00


URB is canceled, maybe that URB never finished?

[57246.707583] xhci-hcd xhci-hcd.0.auto: Cancel URB 
07b523f0,

dev 1, ep 0x81, starting at offset 0
[57246.707594] xhci-hcd xhci-hcd.0.auto: // Ding dong!
[57246.707616] xhci-hcd xhci-hcd.0.auto: Stopped on No-op or Link 
TRB

for slot 1 ep 2
[57246.707625] xhci-hcd xhci-hcd.0.auto: Removing canceled TD 
starting

at 0x7f0cd0a0 (dma).
[57246.707630] xhci-hcd xhci-hcd.0.auto: Finding endpoint context
[57246.707634] xhci-hcd xhci-hcd.0.auto: Cycle state = 0x1
[57246.707637] xhci-hcd xhci-hcd.0.auto: New dequeue segment =
890c7dc4 (virtual)
[57246.707641] xhci-hcd xhci-hcd.0.auto: New dequeue pointer =
0x7f0cd0b0 (DMA)
[57246.707646] xhci-hcd xhci-hcd.0.auto: Set TR Deq Ptr cmd, new 
deq seg
= 890c7dc4 (0x7f0cd000 dmeq ptr = 0ce7faa0 
(0x7f0cd0b0

dma), new cycle = 1
[57246.707651] xhci-hcd xhci-hcd.0.auto: // Ding dong!
[57246.707671] xhci-hcd xhci-hcd.0.auto: Successful Set TR Deq Ptr 
cmd,

deq = @7f0cd0b0
[57246.721090] scsi host1: uas_eh_device_reset_handler start
[57246.721114] xhci-hcd xhci-hcd.0.auto: Cancel URB 
279f06a2,

dev 1, ep 0x83, starting at offset 0
[57246.721120] xhci-hcd xhci-hcd.0.auto: // Ding dong!
[57246.721135] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event for
unknown stream ring slot 1 ep 6
[57246.725463] xhci-hcd xhci-hcd.0.auto: @7f044780 


 1b00 01078001


Stop -Length invalid transfer event. That is normal when canceling a 
URB,

but it should point to the TRB xhc was working on when stopped.
Here it just points to 0. That part looks like some issue with this 
specific

controller.

Some other errors may return 0 as their TRB pointer, but not this 
event.
 But this is not the cause, just a detail while handling the real 
cause.
Nothing in this log shows why the URB was canceled in the first 
place.


usbmon and xhci traces could help, xhci traces:

mount -t debugfs none /sys/kernel/debug
echo 81920 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable

then send /sys/kernel/debug/tracing/trace after issue triggered.

-Mathias


Mathias, here is usbmon and trace ..let us know on your observation 
which will help to learn more on xhci level :-)

(same is attached)



The xhci traces show that a ep1in bulk URB is queued on Stream 1, but
never completes.
Similar URBs queued on the same stream ring before this one work and
complete fine.

xhci driver never gets a short or success completion transfer event for 
the URB.

No error messages, nothing special going on either.

To me it looks like the URB was queued correctly, but after the stream
protocol chose
to transfer and finish stream 2 it never went back to transfer what
was queued for stream 1.


yea, but stream 1 will 

Re: refine xhci-plat-Fix-xhci_plat-shutdown-sequence

[Greg KH]

On Wed, Apr 18, 2018 at 01:41:45PM +0800, lei...@codeaurora.org wrote:
> On 2018-04-17 18:32, Greg KH wrote:
> > On Tue, Apr 17, 2018 at 11:32:42AM +0800, lei...@codeaurora.org wrote:
> > > 
> > > xhci-plat Shutdown callback should check HCD_FLAG_HW_ACCESSIBLE
> > > before accessing any register. This should avoid hung with access
> > > controllers which support runtime suspend
> > > 
> > > This can fix for issue of https://patchwork.kernel.org/patch/10339317/
> > > corresponding upload in CAF:
> > > https://source.codeaurora.org/quic/la/kernel/msm-4.4/commit/?h=LV.HB.1.1.5-03810-8x96.0=a7a5307ee04ad349d365ad50f304605a9cd9bd0a
> > > 
> > > full patch refer attachment.
> > > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> > > index 9b27798..bdf914d 100644
> > > --- a/drivers/usb/host/xhci.c
> > > +++ b/drivers/usb/host/xhci.c
> > > @@ -702,6 +702,10 @@ static void xhci_shutdown(struct usb_hcd *hcd)
> > > usb_disable_xhci_ports(to_pci_dev(hcd->self.sysdev));
> > > 
> > > spin_lock_irq(>lock);
> > > +   if (!HCD_HW_ACCESSIBLE(hcd)) {
> > > +   spin_unlock_irq(>lock);
> > > +   return;
> > > +   }
> > > xhci_halt(xhci);
> > 
> > A blank line after the if statement?
> > > [lei]I checked other code in this file, seems we do not neeed a
> > > blank line after if here.
> > 
> > What about all of the other places in this driver that you should also
> > check for this?  Look at the other host controllers, shouldn't you
> > mirror what they are doing?
> > > [lei] The issue here is when shutdown called, xhci-host driver will
> > > try to access
> > > usb register which may be in runtime suspend state, this lead to a
> > > hang up.
> > > Similar as what xhci-host suspend workflow has done, we need check
> > > HW_ACCESS.
> > And this needs a Fixes: tag, along with a cc: stable so as to properly
> > get backported as this is broken in some stable kernels right now.
> > > [lei] Added Cc and Fixes part in commit message
> > 
> > thanks,
> > 
> > greg k-h
> 
> 
> From c03697fa259ab38d1002598ec2ccfac37607ca0b Mon Sep 17 00:00:00 2001
> From: Lei wang 
> Date: Tue, 17 Apr 2018 10:55:35 +0800
> Subject: [PATCH v2] xhci: plat: Fix xhci_plat shutdown hung
> 
> xhci-plat Shutdown callback should check HCD_FLAG_HW_ACCESSIBLE
> before accessing any register. This should avoid hung with access
> controllers which support runtime suspend
> 
> Fixes: b07c12517f2a ("xhci: plat: Register shutdown for xhci_plat")
> Cc: 
> Signed-off-by: Lei wang 
> ---
>  drivers/usb/host/xhci.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index 9b27798..bdf914d 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -702,6 +702,10 @@ static void xhci_shutdown(struct usb_hcd *hcd)
> usb_disable_xhci_ports(to_pci_dev(hcd->self.sysdev));
> 
> spin_lock_irq(>lock);
> +   if (!HCD_HW_ACCESSIBLE(hcd)) {
> +   spin_unlock_irq(>lock);
> +   return;
> +   }
> xhci_halt(xhci);
> /* Workaround for spurious wakeups at shutdown with HSW */
> if (xhci->quirks & XHCI_SPURIOUS_WAKEUP)
> --
> 1.9.1

Please step back, go find someone at Qualcomm that knows how to submit
patches upstream, and have them read this email and point out what you
did incorrectly.

Also, you did not address any of the patch review comments I made on the
first version for some unknown reason, making it less likely that anyone
wants to review this patch again as it's obviously not correct...

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] usb: always build usb/common/ targets; fixes extcon-axp288 build error

[Randy Dunlap]

On 04/17/18 02:01, Hans de Goede wrote:
> Hi,
> 
> On 17-04-18 07:14, Randy Dunlap wrote:
>> From: Randy Dunlap 
>>
>> The extcon-axp288 driver selects USB_ROLE_SWITCH, but the USB
>> Makefile does not currently build drivers/usb/common/ (where
>> USB_ROLE_SWITCH code is) unless USB_COMMON is set, so modify
>> the USB Makefile to always descend into drivers/usb/common/
>> to build its configured targets.
>>
>> Fixes these build errors:
>>
>> ERROR: "usb_role_switch_get" [drivers/extcon/extcon-axp288.ko] undefined!
>> ERROR: "usb_role_switch_set_role" [drivers/extcon/extcon-axp288.ko] 
>> undefined!
>> ERROR: "usb_role_switch_get_role" [drivers/extcon/extcon-axp288.ko] 
>> undefined!
>> ERROR: "usb_role_switch_put" [drivers/extcon/extcon-axp288.ko] undefined!
>>
>> An alternative patch would be to select USB_COMMON in the EXTCON_AXP288
>> driver Kconfig entry, but this would build more code in
>> drivers/usb/common/ than is necessary.
> 
> Ah, that variant of fixing this got posted yesterday and I acked that,
> but I agree that this version is better.

That was my first patch version, but I didn't like it.

However, I missed that patch. If I had seen it, I wouldn't have posted
this patch.


> Greg, what is your take on this fix?
> 
> Chanwoo Choi, please wait with merging the fix from yesterday until
> we've a decision which fix to use.
> 
> Regards,
> 
> Hans
> 
> 
> 
>>
>> Reported-by: Fengguang Wu 
>> Signed-off-by: Randy Dunlap 
>> Cc: MyungJoo Ham 
>> Cc: Chanwoo Choi 
>> Cc: Hans de Goede 
>> Cc: Greg Kroah-Hartman 
>> Cc: Andy Shevchenko 
>> Cc: Heikki Krogerus 
>> Cc: linux-usb@vger.kernel.org
>> ---
>>   drivers/usb/Makefile |    2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> --- lnx-417-rc1.orig/drivers/usb/Makefile
>> +++ lnx-417-rc1/drivers/usb/Makefile
>> @@ -60,7 +60,7 @@ obj-$(CONFIG_USB_CHIPIDEA)    += chipidea/
>>   obj-$(CONFIG_USB_RENESAS_USBHS)    += renesas_usbhs/
>>   obj-$(CONFIG_USB_GADGET)    += gadget/
>>   -obj-$(CONFIG_USB_COMMON)    += common/
>> +obj-y    += common/
>>     obj-$(CONFIG_USBIP_CORE)    += usbip/
>>  
>>
> 


-- 
~Randy
--
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