Re: USB regression for Android phone and sound card in 4.14

[Nazar Mokrynskyi]

I've tried to bisect kernels from 4.13 to 4.14 and didn't find the reason. Then 
I found that with upstream 4.13 the issue is still present on Ubuntu 18.04, so 
there should be something more than just a kernel.

Eventually, I found that issue is somehow related to USB hub I use for my 
periferals (mouse, keyboard and sound card).

When sound card is connected separately, it is properly initialized as USB 2.0 
device: https://pastebin.com/0rv1aUBz

However, when connected to USB hub, it initializes as USB 1.1 device, in which 
case it disables some of its capabilities, like 5.1 output mode: 
https://pastebin.com/i4qE9JTZ

Can't blame USB hub for this, since when I unplug it with mentioned 3 devices 
and plug back - everything works fine, the issue only happens on system boot.

USB hub I use at the moment (used another before with the same outcome): 
https://pastebin.com/wkA6D9TP

Sincerely, Nazar Mokrynskyi
github.com/nazar-pc

20.04.18 01:58, Nazar Mokrynskyi пише:
> Still an issue as of 4.17-rc1 for sound card.
>
> Sincerely, Nazar Mokrynskyi
> github.com/nazar-pc
>
> 17.03.18 19:04, Nazar Mokrynskyi пише:
>> With kernel 4.16-rc5 it is still happening to USB sound card, Android phone 
>> issue was probably related to something else and is already fixed.
>>
>> Very annoying to unplug sound card after each reboot, any ideas why this 
>> might happen?
>>
>> Sincerely, Nazar Mokrynskyi
>> github.com/nazar-pc
>>
>> 13.02.18 01:26, Nazar Mokrynskyi пише:
>>> Starting from 4.14 and continuing in 4.15 I observe 2 bugs that I think are 
>>> related and didn't exist in 4.13.
>>>
>>> The first would be more difficult to reproduce: USB sound card Creative SB 
>>> Omni Surround 5.1 after system boot only shows 2.0 stereo output option, 
>>> while it also supports 5.1 and PulseAudio configured accordingly. If unplug 
>>> and plug it back in, 5.1 mode appears and I can select between 2.0 and 5.1. 
>>> You can boot with stock Ubuntu 17.10 and 18.04 as of right now and the 
>>> first one will work properly and second one will have mentioned bug.
>>>
>>> Second bug is easier to reproduce: when connecting Nexus 6P via USB cable, 
>>> it appears in file manager devices list (Nemo, Nautilus, etc.), but when it 
>>> is unplugged it doesn't disappear when running kernels 4.14 and 4.15. I 
>>> have 7 Nexus 6P entries already, unplugging and plugging back looks like 
>>> this:
>>>
>>> [200038.821988] usb 3-1: new high-speed USB device number 4 using xhci_hcd
>>> [200039.043611] usb 3-1: New USB device found, idVendor=18d1, idProduct=4ee1
>>> [200039.043612] usb 3-1: New USB device strings: Mfr=1, Product=2, 
>>> SerialNumber=3
>>> [200039.043614] usb 3-1: Product: Nexus 6P
>>> [200039.043614] usb 3-1: Manufacturer: Huawei
>>> [200039.043615] usb 3-1: SerialNumber: 8XV7N1612893
>>> [202243.949672] usb 3-1: USB disconnect, device number 4
>>> [205549.671959] usb 3-1: new high-speed USB device number 5 using xhci_hcd
>>> [205549.893327] usb 3-1: New USB device found, idVendor=18d1, idProduct=4ee1
>>> [205549.893328] usb 3-1: New USB device strings: Mfr=1, Product=2, 
>>> SerialNumber=3
>>> [205549.893329] usb 3-1: Product: Nexus 6P
>>> [205549.893329] usb 3-1: Manufacturer: Huawei
>>> [205549.893330] usb 3-1: SerialNumber: 8XV7N1612893
>>> [205550.602646] usb 3-1: USB disconnect, device number 5
>>> [205553.456007] usb 3-1: new high-speed USB device number 6 using xhci_hcd
>>> [205553.680392] usb 3-1: New USB device found, idVendor=18d1, idProduct=4ee1
>>> [205553.680394] usb 3-1: New USB device strings: Mfr=1, Product=2, 
>>> SerialNumber=3
>>> [205553.680394] usb 3-1: Product: Nexus 6P
>>> [205553.680395] usb 3-1: Manufacturer: Huawei
>>> [205553.680396] usb 3-1: SerialNumber: 8XV7N1612893
>>> [206021.635511] usb 3-1: USB disconnect, device number 6
>>> [206024.169853] usb 3-1: new high-speed USB device number 7 using xhci_hcd
>>> [206024.392921] usb 3-1: New USB device found, idVendor=18d1, idProduct=4ee1
>>> [206024.392923] usb 3-1: New USB device strings: Mfr=1, Product=2, 
>>> SerialNumber=3
>>> [206024.392924] usb 3-1: Product: Nexus 6P
>>> [206024.392925] usb 3-1: Manufacturer: Huawei
>>> [206024.392925] usb 3-1: SerialNumber: 8XV7N1612893
>>> [206034.058208] usb 3-1: USB disconnect, device number 7
>>> [206036.914005] usb 3-1: new high-speed USB device number 8 using xhci_hcd
>>> [206037.136891] usb 3-1: New USB device found, idVendor=18d1, idProduct=4ee1
>>> [206037.136893] usb 3-1: New USB device strings: Mfr=1, Product=2, 
>>> SerialNumber=3
>>> [206037.136894] usb 3-1: Product: Nexus 6P
>>> [206037.136895] usb 3-1: Manufacturer: Huawei
>>> [206037.136895] usb 3-1: SerialNumber: 8XV7N1612893
>>> [206080.923547] usb 3-1: USB disconnect, device number 8
>>> [206083.526585] usb 3-1: new high-speed USB device number 9 using xhci_hcd
>>> [206083.752601] usb 3-1: New USB device found, idVendor=18d1, idProduct=4ee1
>>> [206083.752602] usb 3-1: New USB device strings: Mfr=1, Product=2, 
>>> SerialNumber=3

Re: [PATCH] usb:serial:optrion: fix dwm-158 3g modem interface

[Dan Williams]

On Tue, 2018-04-24 at 09:55 +0700, Lars Melin wrote:
> On 4/23/2018 23:54, Dan Williams wrote:
> 
> > > MI_00 D-Link Mobile Broadband Device  (cdc_ether)
> > > MI_02 D-Link HSPA+DataCard Diagnostics Interface (also ppp m
> > > MI_03 D-Link HSPA+DataCard NMEA Device
> > > MI_04 D-Link HSPA+DataCard Speech Port
> > 
> > Any idea what format this port speaks?  Some Huawei Qualcomm-based
> > devices still use a TTY driver but send/receive 16-bit 8000hz PCM
> > audio
> > frames via a serial port.  If the D-Link does something similar, it
> > may
> > still make sense to drive it via option.
> > 
> > > MI_05 D-Link HSPA+DataCard Debug Port
> > 
> > If it's FCCID KA2WM158B1 then it's a Qualcomm device, and this port
> > may
> > be a DIAG port.  It should also be driven by option if that's the
> > case.
> > 
> > I looked but couldn't find downloadable drivers for the DWM-158 so
> > I
> > couldn't double-check myself.
> > 
> > Dan
> 
> This is a DWM-158D1 or maybe they have versioned it E1, it is
> Mediatek 
> based.

Fair enough, then it certainly won't have DM/DIAG.

Dan

> Most (all?) of new D-Link modems are made by BroadMobi using
> Mediatek 
> chipset and having an additional AT cmdset in the AT+BM form.
> 
> 
> /Lars
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/5] usb: mtu3: avoid TX data length truncated in SS/SSP mode

[Chunfeng Yun]

The variable of 'count' is declared as u8, this will cause an issue
due to value truncated when works in SS or SSP mode and data length
is greater than 255, so change it as u32.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/mtu3/mtu3_gadget_ep0.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/mtu3/mtu3_gadget_ep0.c 
b/drivers/usb/mtu3/mtu3_gadget_ep0.c
index ebdcf7a..d67b540 100644
--- a/drivers/usb/mtu3/mtu3_gadget_ep0.c
+++ b/drivers/usb/mtu3/mtu3_gadget_ep0.c
@@ -546,7 +546,7 @@ static void ep0_tx_state(struct mtu3 *mtu)
struct usb_request *req;
u32 csr;
u8 *src;
-   u8 count;
+   u32 count;
u32 maxp;
 
dev_dbg(mtu->dev, "%s\n", __func__);
-- 
1.9.1

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

Re: [PATCH] usb:serial:optrion: fix dwm-158 3g modem interface

[Lars Melin]

On 4/23/2018 23:54, Dan Williams wrote:


MI_00 D-Link Mobile Broadband Device  (cdc_ether)
MI_02 D-Link HSPA+DataCard Diagnostics Interface (also ppp m
MI_03 D-Link HSPA+DataCard NMEA Device
MI_04 D-Link HSPA+DataCard Speech Port


Any idea what format this port speaks?  Some Huawei Qualcomm-based
devices still use a TTY driver but send/receive 16-bit 8000hz PCM audio
frames via a serial port.  If the D-Link does something similar, it may
still make sense to drive it via option.


MI_05 D-Link HSPA+DataCard Debug Port


If it's FCCID KA2WM158B1 then it's a Qualcomm device, and this port may
be a DIAG port.  It should also be driven by option if that's the case.

I looked but couldn't find downloadable drivers for the DWM-158 so I
couldn't double-check myself.

Dan


This is a DWM-158D1 or maybe they have versioned it E1, it is Mediatek 
based.
Most (all?) of new D-Link modems are made by BroadMobi using Mediatek 
chipset and having an additional AT cmdset in the AT+BM form.



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

[PATCH 3/5] usb: mtu3: fix an unrecognized issue when connected with PC

[Chunfeng Yun]

When boot on the platform with the USB cable connected to Win7,
the Win7 will pop up an error dialog: "USB Device not recognized",
but finally the Win7 can enumerate it successfully.
The root cause is as the following:
When the xHCI driver set PORT_POWER of the OTG port, and if both
IDPIN and VBUS_VALID are high at the same time, the MTU3 controller
will set SESSION and pull up DP, so the Win7 can detect existence
of USB device, but if the mtu3 driver can't switch to device mode
during the debounce time, the Win7 can not enumerate it.
Here to fix it by removing the 1s delayed EXTCON register to speed up
mode switch.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/mtu3/mtu3.h|  4 
 drivers/usb/mtu3/mtu3_dr.c | 25 +++--
 2 files changed, 3 insertions(+), 26 deletions(-)

diff --git a/drivers/usb/mtu3/mtu3.h b/drivers/usb/mtu3/mtu3.h
index 2cd00a2..a56fee0 100644
--- a/drivers/usb/mtu3/mtu3.h
+++ b/drivers/usb/mtu3/mtu3.h
@@ -197,9 +197,6 @@ struct mtu3_gpd_ring {
 * @edev: external connector used to detect vbus and iddig changes
 * @vbus_nb: notifier for vbus detection
 * @vbus_nb: notifier for iddig(idpin) detection
-* @extcon_reg_dwork: delay work for extcon notifier register, waiting for
-*  xHCI driver initialization, it's necessary for system bootup
-*  as device.
 * @is_u3_drd: whether port0 supports usb3.0 dual-role device or not
 * @manual_drd_enabled: it's true when supports dual-role device by debugfs
 *  to switch host/device modes depending on user input.
@@ -209,7 +206,6 @@ struct otg_switch_mtk {
struct extcon_dev *edev;
struct notifier_block vbus_nb;
struct notifier_block id_nb;
-   struct delayed_work extcon_reg_dwork;
bool is_u3_drd;
bool manual_drd_enabled;
 };
diff --git a/drivers/usb/mtu3/mtu3_dr.c b/drivers/usb/mtu3/mtu3_dr.c
index db7562d..80083e0 100644
--- a/drivers/usb/mtu3/mtu3_dr.c
+++ b/drivers/usb/mtu3/mtu3_dr.c
@@ -238,15 +238,6 @@ static int ssusb_extcon_register(struct otg_switch_mtk 
*otg_sx)
return 0;
 }
 
-static void extcon_register_dwork(struct work_struct *work)
-{
-   struct delayed_work *dwork = to_delayed_work(work);
-   struct otg_switch_mtk *otg_sx =
-   container_of(dwork, struct otg_switch_mtk, extcon_reg_dwork);
-
-   ssusb_extcon_register(otg_sx);
-}
-
 /*
  * We provide an interface via debugfs to switch between host and device modes
  * depending on user input.
@@ -407,18 +398,10 @@ int ssusb_otg_switch_init(struct ssusb_mtk *ssusb)
 {
struct otg_switch_mtk *otg_sx = >otg_switch;
 
-   if (otg_sx->manual_drd_enabled) {
+   if (otg_sx->manual_drd_enabled)
ssusb_debugfs_init(ssusb);
-   } else {
-   INIT_DELAYED_WORK(_sx->extcon_reg_dwork,
- extcon_register_dwork);
-
-   /*
-* It is enough to delay 1s for waiting for
-* host initialization
-*/
-   schedule_delayed_work(_sx->extcon_reg_dwork, HZ);
-   }
+   else
+   ssusb_extcon_register(otg_sx);
 
return 0;
 }
@@ -429,6 +412,4 @@ void ssusb_otg_switch_exit(struct ssusb_mtk *ssusb)
 
if (otg_sx->manual_drd_enabled)
ssusb_debugfs_exit(ssusb);
-   else
-   cancel_delayed_work(_sx->extcon_reg_dwork);
 }
-- 
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 5/5] usb: mtu3: make USB_MTU3_DUAL_ROLE depend on EXTCON but not USB_MTU3

[Chunfeng Yun]

In fact the driver depends on EXTCON only when it's configed as
USB_MTU3_DUAL_ROLE, so make USB_MTU3_DUAL_ROLE depend on EXTCON but
not USB_MTU3.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/mtu3/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/mtu3/Kconfig b/drivers/usb/mtu3/Kconfig
index 25cd619..8daf277 100644
--- a/drivers/usb/mtu3/Kconfig
+++ b/drivers/usb/mtu3/Kconfig
@@ -2,7 +2,7 @@
 
 config USB_MTU3
tristate "MediaTek USB3 Dual Role controller"
-   depends on EXTCON && (USB || USB_GADGET) && HAS_DMA
+   depends on (USB || USB_GADGET) && HAS_DMA
depends on ARCH_MEDIATEK || COMPILE_TEST
select USB_XHCI_MTK if USB_SUPPORT && USB_XHCI_HCD
help
@@ -40,6 +40,7 @@ config USB_MTU3_GADGET
 config USB_MTU3_DUAL_ROLE
bool "Dual Role mode"
depends on ((USB=y || USB=USB_MTU3) && (USB_GADGET=y || 
USB_GADGET=USB_MTU3))
+   depends on (EXTCON=y || EXTCON=USB_MTU3)
help
  This is the default mode of working of MTU3 controller where
  both host and gadget features are enabled.
-- 
1.9.1

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

[PATCH 4/5] usb: mtu3: fix operation failure when test TEST_J/K

[Chunfeng Yun]

There is an error dialog popped up in PC when test TEST_J/K
by EHSETT tool, due to not waiting for the completion of
control transfer. Here fix it by entering test mode after
Status Stage finish.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/mtu3/mtu3_gadget_ep0.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/usb/mtu3/mtu3_gadget_ep0.c 
b/drivers/usb/mtu3/mtu3_gadget_ep0.c
index d67b540..0d2b1cf 100644
--- a/drivers/usb/mtu3/mtu3_gadget_ep0.c
+++ b/drivers/usb/mtu3/mtu3_gadget_ep0.c
@@ -7,6 +7,7 @@
  * Author:  Chunfeng.Yun 
  */
 
+#include 
 #include 
 
 #include "mtu3.h"
@@ -263,6 +264,7 @@ static int handle_test_mode(struct mtu3 *mtu, struct 
usb_ctrlrequest *setup)
 {
void __iomem *mbase = mtu->mac_base;
int handled = 1;
+   u32 value;
 
switch (le16_to_cpu(setup->wIndex) >> 8) {
case TEST_J:
@@ -292,6 +294,14 @@ static int handle_test_mode(struct mtu3 *mtu, struct 
usb_ctrlrequest *setup)
if (mtu->test_mode_nr == TEST_PACKET_MODE)
ep0_load_test_packet(mtu);
 
+   /* send status before entering test mode. */
+   value = mtu3_readl(mbase, U3D_EP0CSR) & EP0_W1C_BITS;
+   mtu3_writel(mbase, U3D_EP0CSR, value | EP0_SETUPPKTRDY | EP0_DATAEND);
+
+   /* wait for ACK status sent by host */
+   readl_poll_timeout(mbase + U3D_EP0CSR, value,
+   !(value & EP0_DATAEND), 100, 5000);
+
mtu3_writel(mbase, U3D_USB2_TEST_MODE, mtu->test_mode_nr);
 
mtu->ep0_state = MU3D_EP0_STATE_SETUP;
-- 
1.9.1

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

[PATCH 2/5] usb: mtu3: remove repeated setting of gadget state

[Chunfeng Yun]

The usb_add_gadget_udc() will set the gadget state as
USB_STATE_NOTATTACHED, so we needn't set it again.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/mtu3/mtu3_gadget.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/mtu3/mtu3_gadget.c b/drivers/usb/mtu3/mtu3_gadget.c
index f05f10f..de0de01 100644
--- a/drivers/usb/mtu3/mtu3_gadget.c
+++ b/drivers/usb/mtu3/mtu3_gadget.c
@@ -660,14 +660,10 @@ int mtu3_gadget_setup(struct mtu3 *mtu)
mtu3_gadget_init_eps(mtu);
 
ret = usb_add_gadget_udc(mtu->dev, >g);
-   if (ret) {
+   if (ret)
dev_err(mtu->dev, "failed to register udc\n");
-   return ret;
-   }
 
-   usb_gadget_set_state(>g, USB_STATE_NOTATTACHED);
-
-   return 0;
+   return ret;
 }
 
 void mtu3_gadget_cleanup(struct mtu3 *mtu)
-- 
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/2] usb: dwc2: fix isoc split in transfer with no data

[William Wu]

If isoc split in transfer with no data (the length of DATA0
packet is 0), we can't simply return immediately. Because the
DATA0 can be the first transaction or the second transaction for
the isoc split in transaction. If the DATA0 packet with on data
is in the first transaction, we can return immediately. But if
the the DATA0 packet with on data is in the second transaction
of isoc split in transaction sequence, we need to increase the
qtd->isoc_frame_index and giveback urb to device driver if needed,
otherwise, the MDATA packet will be lost.

A typical test case is that connect the dwc2 controller with an
usb hs Hub (GL852G-12), and plug an usb fs audio device (Plantronics
headset) into the downstream port of Hub. Then use the usb mic
to record, we can find noise when playback.

In the case, the isoc split in transaction sequence like this:

- SSPLIT IN transaction
- CSPLIT IN transaction
  - MDATA packet (176 bytes)
- CSPLIT IN transaction
  - DATA0 packet (0 byte)

This patch use both the length of DATA0 and qtd->isoc_split_offset
to check if the DATA0 is in the second transaction.

Signed-off-by: William Wu 
---
 drivers/usb/dwc2/hcd_intr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/hcd_intr.c b/drivers/usb/dwc2/hcd_intr.c
index 5e2378f..479f628 100644
--- a/drivers/usb/dwc2/hcd_intr.c
+++ b/drivers/usb/dwc2/hcd_intr.c
@@ -930,7 +930,7 @@ static int dwc2_xfercomp_isoc_split_in(struct dwc2_hsotg 
*hsotg,
frame_desc = >urb->iso_descs[qtd->isoc_frame_index];
len = dwc2_get_actual_xfer_length(hsotg, chan, chnum, qtd,
  DWC2_HC_XFER_COMPLETE, NULL);
-   if (!len) {
+   if (!len && !qtd->isoc_split_offset) {
qtd->complete_split = 0;
qtd->isoc_split_offset = 0;
return 0;
-- 
2.0.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 1/2] usb: dwc2: alloc dma aligned buffer for isoc split in

[William Wu]

The commit 3bc04e28a030 ("usb: dwc2: host: Get aligned DMA in
a more supported way") rips out a lot of code to simply the
allocation of aligned DMA. However, it also introduces a new
issue when use isoc split in transfer.

In my test case, I connect the dwc2 controller with an usb hs
Hub (GL852G-12), and plug an usb fs audio device (Plantronics
headset) into the downstream port of Hub. Then use the usb mic
to record, we can find noise when playback.

It's because that the usb Hub uses an MDATA for the first
transaction and a DATA0 for the second transaction for the isoc
split in transaction. An typical isoc split in transaction sequence
like this:

- SSPLIT IN transaction
- CSPLIT IN transaction
  - MDATA packet
- CSPLIT IN transaction
  - DATA0 packet

The DMA address of MDATA (urb->dma) is always DWORD-aligned, but
the DMA address of DATA0 (urb->dma + qtd->isoc_split_offset) may
not be DWORD-aligned, it depends on the qtd->isoc_split_offset (the
length of MDATA). In my test case, the length of MDATA is usually
unaligned, this casue DATA0 packet transmission error.

This patch base on the old way of aligned DMA allocation in the
dwc2 driver to get aligned DMA for isoc split in.

Signed-off-by: William Wu 
---
 drivers/usb/dwc2/hcd.c   | 63 +---
 drivers/usb/dwc2/hcd.h   | 10 +++
 drivers/usb/dwc2/hcd_intr.c  |  8 ++
 drivers/usb/dwc2/hcd_queue.c |  8 +-
 4 files changed, 85 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 190f959..8c2b35f 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -1562,11 +1562,20 @@ static void dwc2_hc_start_transfer(struct dwc2_hsotg 
*hsotg,
}
 
if (hsotg->params.host_dma) {
-   dwc2_writel((u32)chan->xfer_dma,
-   hsotg->regs + HCDMA(chan->hc_num));
+   dma_addr_t dma_addr;
+
+   if (chan->align_buf) {
+   if (dbg_hc(chan))
+   dev_vdbg(hsotg->dev, "align_buf\n");
+   dma_addr = chan->align_buf;
+   } else {
+   dma_addr = chan->xfer_dma;
+   }
+   dwc2_writel((u32)dma_addr, hsotg->regs + HCDMA(chan->hc_num));
+
if (dbg_hc(chan))
dev_vdbg(hsotg->dev, "Wrote %08lx to HCDMA(%d)\n",
-(unsigned long)chan->xfer_dma, chan->hc_num);
+(unsigned long)dma_addr, chan->hc_num);
}
 
/* Start the split */
@@ -2620,6 +2629,33 @@ static void dwc2_hc_init_xfer(struct dwc2_hsotg *hsotg,
}
 }
 
+static int dwc2_alloc_split_dma_aligned_buf(struct dwc2_hsotg *hsotg,
+   struct dwc2_qh *qh,
+   struct dwc2_host_chan *chan)
+{
+   if (!qh->dw_align_buf) {
+   qh->dw_align_buf = kmalloc(chan->max_packet,
+  GFP_ATOMIC | GFP_DMA);
+   if (!qh->dw_align_buf)
+   return -ENOMEM;
+
+   qh->dw_align_buf_size = chan->max_packet;
+   }
+
+   qh->dw_align_buf_dma = dma_map_single(hsotg->dev, qh->dw_align_buf,
+ qh->dw_align_buf_size,
+ DMA_FROM_DEVICE);
+
+   if (dma_mapping_error(hsotg->dev, qh->dw_align_buf_dma)) {
+   dev_err(hsotg->dev, "can't map align_buf\n");
+   chan->align_buf = 0;
+   return -EINVAL;
+   }
+
+   chan->align_buf = qh->dw_align_buf_dma;
+   return 0;
+}
+
 #define DWC2_USB_DMA_ALIGN 4
 
 struct dma_aligned_buffer {
@@ -2797,6 +2833,27 @@ static int dwc2_assign_and_init_hc(struct dwc2_hsotg 
*hsotg, struct dwc2_qh *qh)
/* Set the transfer attributes */
dwc2_hc_init_xfer(hsotg, chan, qtd);
 
+   /* For non-dword aligned buffers */
+   if (hsotg->params.host_dma > 0 && qh->do_split &&
+   chan->ep_is_in && (chan->xfer_dma & 0x3)) {
+   dev_vdbg(hsotg->dev, "Non-aligned buffer\n");
+   if (dwc2_alloc_split_dma_aligned_buf(hsotg, qh, chan)) {
+   dev_err(hsotg->dev,
+   "%s: Failed to allocate memory to handle 
non-dword aligned buffer\n",
+   __func__);
+   /* Add channel back to free list */
+   chan->align_buf = 0;
+   chan->multi_count = 0;
+   list_add_tail(>hc_list_entry,
+ >free_hc_list);
+   qtd->in_process = 0;
+   qh->channel = NULL;
+   return -ENOMEM;
+   }
+   } else {
+   chan->align_buf = 0;
+   }
+
if (chan->ep_type == 

[PATCH 0/2] usb: dwc2: fix isoc split in transfer issue

[William Wu]

This patch fix dma unaligned problem and data lost problem for
isoc split in transfer.

Test on rk3288 platform, use an usb hs Hub (GL852G-12) and an usb
fs audio device (Plantronics headset) to capture and playback.

William Wu (2):
  usb: dwc2: alloc dma aligned buffer for isoc split in
  usb: dwc2: fix isoc split in transfer with no data

 drivers/usb/dwc2/hcd.c   | 63 +---
 drivers/usb/dwc2/hcd.h   | 10 +++
 drivers/usb/dwc2/hcd_intr.c  | 10 ++-
 drivers/usb/dwc2/hcd_queue.c |  8 +-
 4 files changed, 86 insertions(+), 5 deletions(-)

-- 
2.0.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 v2 0/2] usb: dwc3: support clocks and resets for DWC3 core

[Masahiro Yamada]

2018-04-24 9:11 GMT+09:00 Manu Gautam :
> HI,
>
>
> On 4/19/2018 4:03 AM, Masahiro Yamada wrote:
>> In the current design of DWC3 driver,
>> the DT typically becomes a nested structure like follows:
>>
>>   dwc3-glue {
>>   compatible = "foo,dwc3";
>>   ...
>>
>>   dwc3 {
>>   compatible = "snps,dwc3";
>>   ...
>>   };
>>   }
>>
>> The current DWC3 core (drivers/usb/dwc3/core.c) can not handle
>> clocks / resets at all.
>>
>> The only solution we have now, is to put DWC3 core node under
>> the glue layer node, then add clocks and resets there.
>> Actually, dwc3-of-simple.c exists to handle clocks and resets.
>>
>> As always for digital circuits, DWC3 core IP itself needs clock input.
>> This is specific to this IP.  So, supporting clocks and resets in
>> dwc3/core.c makes sense.
>
> Why can't dwc3-of-simple be used with this IP?
> Adding core/reset handling in both core and glue drivers might
> only add to confusion and I cant think of a reason why having a parent
> node representing dwc3-of-simple glue would be any concern.
> Or are you planning to remove dwc3-of-simple.c driver?


dwc3-of-simple.c can be removed only after at least
all upstream DT files are migrated.
(and give enough time for migration of downstream DT)

At least, new platforms are not required to use this hack.




-- 
Best Regards
Masahiro Yamada
--
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/2] usb: dwc3: support clocks and resets for DWC3 core

[Masahiro Yamada]

2018-04-24 2:44 GMT+09:00 Martin Blumenstingl
:
> Hello,
>
> On Thu, Apr 19, 2018 at 1:03 PM, Masahiro Yamada
>  wrote:
>> Historically, the clocks and resets are handled on the glue layer
>> side instead of the DWC3 core.  For simple cases, dwc3-of-simple.c
>> takes care of arbitrary number of clocks and resets.  The DT node
>> structure typically looks like as follows:
>>
>>   dwc3-glue {
>>   compatible = "foo,dwc3";
>>   clocks = ...;
>>   resets = ...;
>>   ...
>>
>>   dwc3 {
>>   compatible = "snps,dwc3";
>>   ...
>>   };
>>   }
>>
>> By supporting the clocks and the reset in the dwc3/core.c, it will
>> be turned into a single node:
>>
>>   dwc3 {
>>   compatible = "foo,dwc3", "snps,dwc3";
>>   clocks = ...;
>>   resets = ...;
>>   ...
>>   }
>>
>> This commit adds the binding of clocks and resets specific to this IP.
>> The number of clocks should generally be the same across SoCs, it is
>> just some SoCs either tie clocks together or do not provide software
>> control of some of the clocks.
>>
>> I took the clock names from the Synopsys datasheet: "ref" (ref_clk),
>> "bus_early" (bus_clk_early), and "suspend" (suspend_clk).
> looking at the code: this could mean that dwc3-exynos.c can be removed
> mid-term (assuming the PHY and regulator handling can be
> moved/removed/changed)

That is a good news.



> does the datasheet state anything about the clock speeds? from
> Documentation/devicetree/bindings/usb/dwc3-xilinx.txt:
> "bus_clk" Master/Core clock, have to be >= 125 MHz for SS operation
> and >= 60MHz for HS operation


Not sure.
"xlnx,zynqmp-dwc3" is a member of dwc3-of-simple.c
which just enables/disables clocks.

That information is not important.


>> I found only one reset line in the datasheet, hence the reset-names
>> property is omitted.
> does the datasheet state whether this is a level or a pulsed reset line?
> on Amlogic Meson GXL, GXM and AXG SoCs we use a pulsed (and shared)
> reset line (see ff0a632f08759e "usb: dwc3: of-simple: add support for
> shared and pulsed reset lines") because the reset line is shared
> between various components (USB2 PHY, USB3 PHY, dwc3 controller, ...)
> your current approach (having a vendor-specific "foo,dwc3" binding
> along with the generic "snps,dwc3") would allow having
> per-"of_device_id" settings which could indicate whether the reset
> lines are level or pulsed reset if these are "implementation specific"


I guess your commit
ff0a632f08759e31f45b06fee27bc71c826c6b11
is wrong.


About the clocks, Rob Herring pointed out:

  However, this should be specific as to how many clocks and their
  function. This should be readily available to someone with access to
  Synopsys datasheet. The number of clocks should generally be the same
  across SoCs, it is just some SoCs either tie clocks together or don't
  provide s/w control of some of the clocks.



The same applies to the reset control.
The reset policy should be the same across SoCs
since we are using the same IP (i.e. the same delivered RTL).


You are using a pulse reset for DWC3
just because the reset controller in your SoC
is implemented like that.

This is NOT because your DWC3 in your SoC is
specially customized, right?

You put a reset-provider matter to a reset-consumer.





>> Supporting those clocks and resets is the requirement for new platforms.
> just to confirm:
> with this series your goal is to replace the wrapper node which is
> needed due to dwc3-of-simple.c ?


In my _hope_.

But, I cannot do this by myself
since I do not have such boards.

Depends on how people make efforts to covert existing platforms.


> would other drivers which currently create a wrapper node (like
> dwc3-keystone.c) keep their wrapper node or do you have any plans for
> removing it for the other "wrapper" drivers too?


We need to take a close look per driver.

Looking at the dwc3-keystone.c,
it works like an interrupt controller with irq-domain hierarchy.
If it is moved to the irqchip subsystem,
dwc3-keystone.c could be removed.


>> Enforcing the new binding breaks existing platforms since they specify
>> clocks and resets in their glue layer node, but nothing in the core
>> node.  I listed such exceptional cases in the DT binding.  The driver
>> code is loosened up to accept no clock/reset.  This change is based
>> on the discussion [1].
> (snip)
>
> Regards
> Martin



-- 
Best Regards
Masahiro Yamada
--
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 0/2] usb: dwc3: support clocks and resets for DWC3 core

[Manu Gautam]

HI,


On 4/19/2018 4:03 AM, Masahiro Yamada wrote:
> In the current design of DWC3 driver,
> the DT typically becomes a nested structure like follows:
>
>   dwc3-glue {
>   compatible = "foo,dwc3";
>   ...
>
>   dwc3 {
>   compatible = "snps,dwc3";
>   ...
>   };
>   }
>
> The current DWC3 core (drivers/usb/dwc3/core.c) can not handle
> clocks / resets at all.
>
> The only solution we have now, is to put DWC3 core node under
> the glue layer node, then add clocks and resets there.
> Actually, dwc3-of-simple.c exists to handle clocks and resets.
>
> As always for digital circuits, DWC3 core IP itself needs clock input.
> This is specific to this IP.  So, supporting clocks and resets in
> dwc3/core.c makes sense.

Why can't dwc3-of-simple be used with this IP?
Adding core/reset handling in both core and glue drivers might
only add to confusion and I cant think of a reason why having a parent
node representing dwc3-of-simple glue would be any concern.
Or are you planning to remove dwc3-of-simple.c driver?

>
> In this version, the number of clocks (and names) is specific
> to this IP, with clock names taken from Synopsys datasheet.

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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: Request for information how to disable USB bulk endpoint transfer validation

[Alan Stern]

On Mon, 23 Apr 2018, Elvinas wrote:

> Hello,
> 
> I have a somewhat strange request: how to break Linux USB support and disable 
> some 
> validation.
> 
> Recently I have become a "lucky" owner of the badly designed hardware (ZWO 
> 120MM astronomy 
>   camera to be specific) and stumbled upon classic issue: hardware was 
> designed not 
> according to specifications, but to work on Windows. From what I was able to 
> dig on ZWO 
> forums , camera uses bulk transfer mode, but uses incorrect packet size of 
> 1024 bytes. 
> Windows ignores that, Linux - does not. As a result camera does not work in 
> Linux.
> 
> There are repeated messages in kern.log "usb 1-1: reset high-speed USB device 
> number 8 
> using ehci_hcd" and "usb usb1-port1: disabled by hub (EMI?), re-enabling..." 
> each time I 
> attempted to use camera.
> 
> In ZWO forums there was a suggestion to revert USB packet validation by 
> applying a "break" 
> to Linux kernel. With some changes to line locations I have applied the patch 
> below and 
> camera started to work on a desktop with USB 2.0 host.

The patch you wrote isn't ideal; the one below is better.  In fact, the
code should be like this already.  It was an oversight.

> However this patch does not help if 
> camera is attached to a laptop with USB 3.0 host. Each time I try to use 
> camera, I see 
> similar error messages, but now originating from xhci_hcd.
> 
> Question: can anyone point what lines should be commented out to ignore 
> packet sizes for 
> USB 2.0 device, when attached to USB 3.0 host?

As far as I know, there is no way to do this.  USB-3 xHCI host
controllers validate maxpacket sizes in the hardware, not in software,
and there isn't any way to change the hardware's behavior.  But I am
not an expert on xHCI.

Does the camera work when attached to a USB-3 host controller on a 
computer running Windows or Mac OS X?

> As I am not much of C programmer I have not been able to locate those myself 
> and did not 
> want to play "whack a mole" by commenting out some random line, wait ~1 hour 
> to compile 
> kernel and see that nothing good happens.
> 
>  CUT LINE ---
> --- config.c.ORIG   2018-03-14 19:48:11.0 +0200
> +++ config.c   2018-04-16 19:45:24.538599024 +0300
> @@ -374,10 +374,12 @@
>  j = maxpacket_maxes[usb_endpoint_type(>desc)];
> 
>  if (maxp > j) {
> -  dev_warn(ddev, "config %d interface %d altsetting %d endpoint 0x%X has 
> invalid 
> maxpacket %d, setting to %d\n",
> +  dev_warn(ddev, "config %d interface %d altsetting %d endpoint 0x%X has 
> invalid 
> maxpacket %d, setting to %d (IGNORED!)\n",
> cfgno, inum, asnum, d->bEndpointAddress, maxp, j);
> +  #if 0
> maxp = j;
> endpoint->desc.wMaxPacketSize = cpu_to_le16(i | maxp);
> 
>  CUT LINE ---
> 
> PS I know that not the ideal way to solve the problem, but booting customized 
> kernel just 
> for the imaging sessions for me seems to be a good trade off.
> 
> Thank you

Alan Stern



Index: usb-4.x/drivers/usb/core/config.c
===
--- usb-4.x.orig/drivers/usb/core/config.c
+++ usb-4.x/drivers/usb/core/config.c
@@ -191,7 +191,9 @@ static const unsigned short full_speed_m
 static const unsigned short high_speed_maxpacket_maxes[4] = {
[USB_ENDPOINT_XFER_CONTROL] = 64,
[USB_ENDPOINT_XFER_ISOC] = 1024,
-   [USB_ENDPOINT_XFER_BULK] = 512,
+
+   /* Bulk should be 512, but some devices use 1024: we warn below */
+   [USB_ENDPOINT_XFER_BULK] = 1024,
[USB_ENDPOINT_XFER_INT] = 1024,
 };
 static const unsigned short super_speed_maxpacket_maxes[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

Request for information how to disable USB bulk endpoint transfer validation

[Elvinas]

Hello,

I have a somewhat strange request: how to break Linux USB support and disable some 
validation.


Recently I have become a "lucky" owner of the badly designed hardware (ZWO 120MM astronomy 
 camera to be specific) and stumbled upon classic issue: hardware was designed not 
according to specifications, but to work on Windows. From what I was able to dig on ZWO 
forums , camera uses bulk transfer mode, but uses incorrect packet size of 1024 bytes. 
Windows ignores that, Linux - does not. As a result camera does not work in Linux.


There are repeated messages in kern.log "usb 1-1: reset high-speed USB device number 8 
using ehci_hcd" and "usb usb1-port1: disabled by hub (EMI?), re-enabling..." each time I 
attempted to use camera.


In ZWO forums there was a suggestion to revert USB packet validation by applying a "break" 
to Linux kernel. With some changes to line locations I have applied the patch below and 
camera started to work on a desktop with USB 2.0 host. However this patch does not help if 
camera is attached to a laptop with USB 3.0 host. Each time I try to use camera, I see 
similar error messages, but now originating from xhci_hcd.


Question: can anyone point what lines should be commented out to ignore packet sizes for 
USB 2.0 device, when attached to USB 3.0 host?


As I am not much of C programmer I have not been able to locate those myself and did not 
want to play "whack a mole" by commenting out some random line, wait ~1 hour to compile 
kernel and see that nothing good happens.


 CUT LINE ---
--- config.c.ORIG   2018-03-14 19:48:11.0 +0200
+++ config.c   2018-04-16 19:45:24.538599024 +0300
@@ -374,10 +374,12 @@
j = maxpacket_maxes[usb_endpoint_type(>desc)];

if (maxp > j) {
-  dev_warn(ddev, "config %d interface %d altsetting %d endpoint 0x%X has invalid 
maxpacket %d, setting to %d\n",
+  dev_warn(ddev, "config %d interface %d altsetting %d endpoint 0x%X has invalid 
maxpacket %d, setting to %d (IGNORED!)\n",

   cfgno, inum, asnum, d->bEndpointAddress, maxp, j);
+  #if 0
   maxp = j;
   endpoint->desc.wMaxPacketSize = cpu_to_le16(i | maxp);

 CUT LINE ---

PS I know that not the ideal way to solve the problem, but booting customized kernel just 
for the imaging sessions for me seems to be a good trade off.


Thank you

--

Informatikas - diagnozė, o ne specialybė
--
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/2] usb: dwc3: support clocks and resets for DWC3 core

[Martin Blumenstingl]

Hello,

On Thu, Apr 19, 2018 at 1:03 PM, Masahiro Yamada
 wrote:
> Historically, the clocks and resets are handled on the glue layer
> side instead of the DWC3 core.  For simple cases, dwc3-of-simple.c
> takes care of arbitrary number of clocks and resets.  The DT node
> structure typically looks like as follows:
>
>   dwc3-glue {
>   compatible = "foo,dwc3";
>   clocks = ...;
>   resets = ...;
>   ...
>
>   dwc3 {
>   compatible = "snps,dwc3";
>   ...
>   };
>   }
>
> By supporting the clocks and the reset in the dwc3/core.c, it will
> be turned into a single node:
>
>   dwc3 {
>   compatible = "foo,dwc3", "snps,dwc3";
>   clocks = ...;
>   resets = ...;
>   ...
>   }
>
> This commit adds the binding of clocks and resets specific to this IP.
> The number of clocks should generally be the same across SoCs, it is
> just some SoCs either tie clocks together or do not provide software
> control of some of the clocks.
>
> I took the clock names from the Synopsys datasheet: "ref" (ref_clk),
> "bus_early" (bus_clk_early), and "suspend" (suspend_clk).
looking at the code: this could mean that dwc3-exynos.c can be removed
mid-term (assuming the PHY and regulator handling can be
moved/removed/changed)

does the datasheet state anything about the clock speeds? from
Documentation/devicetree/bindings/usb/dwc3-xilinx.txt:
"bus_clk" Master/Core clock, have to be >= 125 MHz for SS operation
and >= 60MHz for HS operation

> I found only one reset line in the datasheet, hence the reset-names
> property is omitted.
does the datasheet state whether this is a level or a pulsed reset line?
on Amlogic Meson GXL, GXM and AXG SoCs we use a pulsed (and shared)
reset line (see ff0a632f08759e "usb: dwc3: of-simple: add support for
shared and pulsed reset lines") because the reset line is shared
between various components (USB2 PHY, USB3 PHY, dwc3 controller, ...)
your current approach (having a vendor-specific "foo,dwc3" binding
along with the generic "snps,dwc3") would allow having
per-"of_device_id" settings which could indicate whether the reset
lines are level or pulsed reset if these are "implementation specific"

> Supporting those clocks and resets is the requirement for new platforms.
just to confirm:
with this series your goal is to replace the wrapper node which is
needed due to dwc3-of-simple.c ?
would other drivers which currently create a wrapper node (like
dwc3-keystone.c) keep their wrapper node or do you have any plans for
removing it for the other "wrapper" drivers too?

> Enforcing the new binding breaks existing platforms since they specify
> clocks and resets in their glue layer node, but nothing in the core
> node.  I listed such exceptional cases in the DT binding.  The driver
> code is loosened up to accept no clock/reset.  This change is based
> on the discussion [1].
(snip)

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

[PATCH 1/3] usb: musb: fix enumeration after resume

[Bin Liu]

From: Andreas Kemnade 

commit 17539f2f4f0b7fa906b508765c8ada07a1e45f52 upstream.

On dm3730 there are enumeration problems after resume.
Investigation led to the cause that the MUSB_POWER_SOFTCONN
bit is not set. If it was set before suspend (because it
was enabled via musb_pullup()), it is set in
musb_restore_context() so the pullup is enabled. But then
musb_start() is called which overwrites MUSB_POWER and
therefore disables MUSB_POWER_SOFTCONN, so no pullup is
enabled and the device is not enumerated.

So let's do a subset of what musb_start() does
in the same way as musb_suspend() does it. Platform-specific
stuff it still called as there might be some phy-related stuff
which needs to be enabled.
Also interrupts are enabled, as it was the original idea
of calling musb_start() in musb_resume() according to
Commit 6fc6f4b87cb3 ("usb: musb: Disable interrupts on suspend,
enable them on resume")

Cc: sta...@vger.kernel.org # v4.9+
Signed-off-by: Andreas Kemnade 
Tested-by: Tony Lindgren 
Signed-off-by: Bin Liu 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/musb/musb_core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 2d9a8067eaca..0736cc27b5e7 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2710,7 +2710,8 @@ static int musb_resume(struct device *dev)
if ((devctl & mask) != (musb->context.devctl & mask))
musb->port1_status = 0;
 
-   musb_start(musb);
+   musb_enable_interrupts(musb);
+   musb_platform_enable(musb);
 
spin_lock_irqsave(>lock, flags);
error = musb_run_resume_work(musb);
-- 
1.9.1

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

[PATCH 3/3] usb: musb: Fix external abort in musb_remove on omap2430

[Bin Liu]

From: Merlijn Wajer 

commit 94e46a4f2d5eb14059e42f313c098d4854847376 upstream.

This fixes an oops on unbind / module unload (on the musb omap2430
platform).

musb_remove function now calls musb_platform_exit before disabling
runtime pm.

Cc: sta...@vger.kernel.org # v4.9+
Signed-off-by: Merlijn Wajer 
Signed-off-by: Bin Liu 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/musb/musb_core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index d4c9e9544ba0..579aa9accafc 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2485,10 +2485,11 @@ static int musb_remove(struct platform_device *pdev)
musb_generic_disable(musb);
spin_unlock_irqrestore(>lock, flags);
musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
+   musb_platform_exit(musb);
+
pm_runtime_dont_use_autosuspend(musb->controller);
pm_runtime_put_sync(musb->controller);
pm_runtime_disable(musb->controller);
-   musb_platform_exit(musb);
musb_phy_callback = NULL;
if (musb->dma_controller)
musb_dma_controller_destroy(musb->dma_controller);
-- 
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 0/3] musb fixes backport to v4.9+

[Bin Liu]

Hi,

Here are several patches backported to v4.9+ to fix runtime PM problems in musb
drivers.

Regards,
-Bin.


Andreas Kemnade (1):
  usb: musb: fix enumeration after resume

Merlijn Wajer (2):
  usb: musb: call pm_runtime_{get,put}_sync before reading vbus registers
  usb: musb: Fix external abort in musb_remove on omap2430

 drivers/usb/musb/musb_core.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

-- 
1.9.1

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

[PATCH 2/3] usb: musb: call pm_runtime_{get,put}_sync before reading vbus registers

[Bin Liu]

From: Merlijn Wajer 

commit df6b074dbe248d8c43a82131e8fd429e401841a5 upstream.

Without pm_runtime_{get,put}_sync calls in place, reading
vbus status via /sys causes the following error:

Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa0ab060
pgd = b333e822
[fa0ab060] *pgd=48011452(bad)

[] (musb_default_readb) from [] (musb_vbus_show+0x58/0xe4)
[] (musb_vbus_show) from [] (dev_attr_show+0x20/0x44)
[] (dev_attr_show) from [] (sysfs_kf_seq_show+0x80/0xdc)
[] (sysfs_kf_seq_show) from [] (seq_read+0x250/0x448)
[] (seq_read) from [] (__vfs_read+0x1c/0x118)
[] (__vfs_read) from [] (vfs_read+0x90/0x144)
[] (vfs_read) from [] (SyS_read+0x3c/0x74)
[] (SyS_read) from [] (ret_fast_syscall+0x0/0x54)

Solution was suggested by Tony Lindgren .

Cc: sta...@vger.kernel.org # v4.9+
Signed-off-by: Merlijn Wajer 
Acked-by: Tony Lindgren 
Signed-off-by: Bin Liu 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/usb/musb/musb_core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 0736cc27b5e7..d4c9e9544ba0 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1774,6 +1774,7 @@ int musb_mailbox(enum musb_vbus_id_status status)
int vbus;
u8  devctl;
 
+   pm_runtime_get_sync(dev);
spin_lock_irqsave(>lock, flags);
val = musb->a_wait_bcon;
vbus = musb_platform_get_vbus_status(musb);
@@ -1787,6 +1788,7 @@ int musb_mailbox(enum musb_vbus_id_status status)
vbus = 0;
}
spin_unlock_irqrestore(>lock, flags);
+   pm_runtime_put_sync(dev);
 
return sprintf(buf, "Vbus %s, timeout %lu msec\n",
vbus ? "on" : "off", val);
-- 
1.9.1

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

Re: [PATCH] usb:serial:optrion: fix dwm-158 3g modem interface

[Dan Williams]

On Mon, 2018-04-23 at 14:14 +0700, Lars Melin wrote:
> On 4/23/2018 14:03, Giuseppe Lippolis wrote:
> > The dwm-158 interface 4 and 5 doesn't answer to the AT commands
> > and doesn't appears a option interface.
> > Tested on openwrt distribution (kernel 4.14 using the old blacklist
> > definitions).
> > 
> > Signed-off-by: Giuseppe Lippolis 
> > ---
> >   drivers/usb/serial/option.c | 3 ++-
> >   1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/usb/serial/option.c
> > b/drivers/usb/serial/option.c
> > index c3f252283ab9..f0c3612467a3 100644
> > --- a/drivers/usb/serial/option.c
> > +++ b/drivers/usb/serial/option.c
> > @@ -1911,7 +1911,8 @@ static const struct usb_device_id
> > option_ids[] = {
> > { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d01, 0xff) },   
> > /* D-Link DWM-156 (variant) */
> > { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d02, 0xff) },
> > { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d03, 0xff) },
> > -   { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d04, 0xff) },   
> > /* D-Link DWM-158 */
> > +   { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d04, 0xff), 
> > /* D-Link DWM-158 */
> > +.driver_info = RSVD(4) | RSVD(5) },
> > { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d0e, 0xff) },   
> > /* D-Link DWM-157 C1 */
> > { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7e19, 0xff), 
> > /* D-Link DWM-221 B1 */
> >   .driver_info = RSVD(4) },
> 
> Blacklisting interface 4 and 5 is correct because:
> 
> MI_00 D-Link Mobile Broadband Device  (cdc_ether)
> MI_02 D-Link HSPA+DataCard Diagnostics Interface (also ppp modem)
> MI_03 D-Link HSPA+DataCard NMEA Device
> MI_04 D-Link HSPA+DataCard Speech Port

Any idea what format this port speaks?  Some Huawei Qualcomm-based
devices still use a TTY driver but send/receive 16-bit 8000hz PCM audio
frames via a serial port.  If the D-Link does something similar, it may
still make sense to drive it via option.

> MI_05 D-Link HSPA+DataCard Debug Port

If it's FCCID KA2WM158B1 then it's a Qualcomm device, and this port may
be a DIAG port.  It should also be driven by option if that's the case.

I looked but couldn't find downloadable drivers for the DWM-158 so I
couldn't double-check myself.

Dan

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

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

[Guenter Roeck]

On Mon, Apr 23, 2018 at 11:03:09AM +0300, Heikki Krogerus wrote:
> On Fri, Apr 20, 2018 at 10:26:08AM -0700, Guenter Roeck wrote:
> > On Wed, Apr 18, 2018 at 03:34:09PM +0300, Heikki Krogerus wrote:
> > > 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;
> > > +
> > 
> > Sanity check ?
> > if (data[0] != len)
> > return -Esomething;
> 
> No. Then we would not even need the len parameter. The idea is to
> allow reading a number of bytes specified by caller, regardless of the
> maximum size of the block.
> 
If I2C_FUNC_I2C is not supported but I2C_FUNC_SMBUS_I2C_BLOCK is, the
regmap core will use i2c_smbus_read_i2c_block_data() and validate the
return length. It will return -EIO if it does not match. That seems
inconsistent. Also, I am not sure how you know that at least the minimum
required number of bytes is returned if the number of bytes requested
is larger than the number of bytes returned by the chip. Am I missing
something ?

Also, I notice that your patch does not touch tps6598x_read16(). Yet,
according to "TPS65981, TPS65982, and TPS65986 Host Interface Technical
Reference Manual", it appears that the 2-byte command used (0x3f) does
support/use block commands. Is that an oversight or on purpose ?

Thanks,
Guenter
--
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: Since Linux 4.13 tlp or powertop usage cause "xHCI host controller not responding, assume dead" on Dell 5855

[Alan Stern]

On Mon, 23 Apr 2018, Mathias Nyman wrote:

> On 22.04.2018 09:29, russianneuroman...@ya.ru wrote:
> > Hello!
> > 
> > So far I tested attached patch but didn't tried to revert commit yet,
> > will do next week.
> > 
> > Result of running patched kernel with recommended debug options:
> > https://paste.fedoraproject.org/paste/UpezexD~tDmQthoxV2BFbg
> > 
> 
> Logs show there is a race, controller is suspended, then resumed,
> but no interrupt is pending in xhci_resume so roothubs are not resumed,
> and host starts to suspend again.
> 
> We get the interrupt only after we already started suspending xhci
> controller again.
> 
> My guess is that when we handle the interrupt we queue work to resume the 
> roothub,
> but controller is probably put to D3 suspended state by then,
> returning 0x from some register reads, which driver understands as a 
> dead host.
> 
> I need to look into this a bit more.

In this situation, the HCD_WAKEUP_PENDING(hcd) test in
hcd-pci.c:suspend_common() should prevent the controller from going
back into D3.  The WAKEUP_PENDING bit gets set in
usb_hcd_resume_root_hub() and it doesn't get cleared until
hcd_bus_resume() runs.

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: Since Linux 4.13 tlp or powertop usage cause "xHCI host controller not responding, assume dead" on Dell 5855

[Mathias Nyman]

On 22.04.2018 09:29, russianneuroman...@ya.ru wrote:

Hello!

So far I tested attached patch but didn't tried to revert commit yet,
will do next week.

Result of running patched kernel with recommended debug options:
https://paste.fedoraproject.org/paste/UpezexD~tDmQthoxV2BFbg



Logs show there is a race, controller is suspended, then resumed,
but no interrupt is pending in xhci_resume so roothubs are not resumed,
and host starts to suspend again.

We get the interrupt only after we already started suspending xhci
controller again.

My guess is that when we handle the interrupt we queue work to resume the 
roothub,
but controller is probably put to D3 suspended state by then,
returning 0x from some register reads, which driver understands as a 
dead host.

I need to look into this a bit more.

[  268.144527] xhci_hcd :00:14.0: xhci_suspend: stopping port polling.
[  268.144543] xhci_hcd :00:14.0: // Setting command ring address to 
0x349bd001
[  268.520802] xhci_hcd :00:14.0: // Setting command ring address to 
0x349bd001
[  268.520969] xhci_hcd :00:14.0: xhci_resume: starting port polling.
[  268.520985] xhci_hcd :00:14.0: xhci_hub_status_data: stopping port 
polling.
[  268.521030] xhci_hcd :00:14.0: xhci_suspend: stopping port polling.
[  268.521040] xhci_hcd :00:14.0: // Setting command ring address to 
0x349bd001
[  268.521139] xhci_hcd :00:14.0: Port Status Change Event for port 3
[  268.521149] xhci_hcd :00:14.0: resume root hub
[  268.521163] xhci_hcd :00:14.0: port resume event for port 3
[  268.521168] xhci_hcd :00:14.0: xHC is not running.
[  268.521174] xhci_hcd :00:14.0: handle_port_status: starting port polling.
[  268.596322] xhci_hcd :00:14.0: xhci_hc_died: xHCI host controller not 
responding, assume dead
[  268.596340] xhci_hcd :00:14.0: Killing URBs for slot ID 1, ep index 0

-Mathias


16/04/2018 14:55 +0300, Mathias Nyman:

On 10.04.2018 12:15, russianneuroman...@ya.ru wrote:

Hello!

On Dell Venue 8 Pro 5855 tablet installing tlp or running "powertop
--
auto-tune" cause "xHCI host controller not responding, assume dead"
error, when error happen two integrated USB devices (Bluetooth
adapter
and LTE modem) disappear until reboot. First time this issue was
observer in Linux 4.13 and still present in Linux 4.16.
Blacklisting
both "Linux Foundation 3.0 root hub" from autosuspend in tlp
configuration is workaround for this issue, however on other
devices
tlp works fine without blacklisting usb hub autosuspend, and on
this
tablet there was no such issue before (at least in Linux ~4.8-4.12
range) so I assume there is regression somewhere.

Is there any related commits between 4.12 and 4.13 that I could try
to revert?



In 4.12 there was a added sensitivity to react to hotplug removed
xhc controllers, i.e. if we read 0x from a xhci register
we assume host is removed and start cleaning up.

commit d9f11ba9f107aa335091ab8d7ba5eea714e46e8b
  xhci: Rework how we handle unresponsive or hoptlug removed hosts

You can try to revert that, but as a final solution we should
find the real rootcause


How issue looks like in logs:

[  227.258385] xhci_hcd :00:14.0: xHC is not running.
[  329.671544] xhci_hcd :00:14.0: xHC is not running.
[  416.695796] xhci_hcd :00:14.0: xHC is not running.


The "xHC is not running" is the xhci driver handing a port event
interrupt for a resuming port, but whole host controller is not
running.
We stop the host controller in xhci_suspend(), and start it in
xhci_resume()

Attaching a patch that improves preventing xhci host suspend during
USB2 resume signaling.
Could help, worth a shot.


[  416.695862] xhci_hcd :00:14.0: xHCI host controller not
responding, assume dead


This means xhci_hc_died() was called, many possible places.
Adding the code below could give a hint:

diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-
ring.c
index daa94c3..51fb3d0 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -900,7 +900,8 @@ void xhci_hc_died(struct xhci_hcd *xhci)
  if (xhci->xhc_state & XHCI_STATE_DYING)
  return;
   
-   xhci_err(xhci, "xHCI host controller not responding, assume

dead\n");
+   xhci_err(xhci, "%ps: xHCI host controller not responding,
assume dead\n",
+__builtin_return_address(0));
  xhci->xhc_state |= XHCI_STATE_DYING;
   
  xhci_cleanup_command_queue(xhci);



[  416.695900] xhci_hcd :00:14.0: HC died; cleaning up
[  416.696052] usb 1-3: USB disconnect, device number 2
[  416.815610] cdc_mbim 1-3:1.12 wwp0s20u3i12: unregister
'cdc_mbim'
usb-:00:14.0-3, CDC MBIM
[  416.847934] usb 1-4: USB disconnect, device number 3

After that Bluetooth adapter and LTE modem disappear from lsusb
output,
while xHCI controller itself remain visible.


we stop the host activity in xhci_hc_died(), no usb devices under
this host will work.


Complete dmesg: 

[PATCH v2 1/1] drivers: usb: Introduce FSL_USB2_PHY_UTMI_DUAL for usb gadget

[Tiago Brusamarello]

Introduce FSL_USB2_PHY_UTMI_DUAL in gadget driver for setting
phy in SOCs with utmi dual phy

Signed-off-by: Nikhil Badola 
Tested-by: Tiago Brusamarello 
---

Changes since v1:
 * Removed Freescale internal information from commit message

 drivers/usb/gadget/udc/fsl_udc_core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c
b/drivers/usb/gadget/udc/fsl_udc_core.c
index 56b517a..a3c092b 100644
--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -253,6 +253,7 @@ static int dr_controller_setup(struct fsl_udc *udc)
 portctrl |= PORTSCX_PTW_16BIT;
 /* fall through */
 case FSL_USB2_PHY_UTMI:
+case FSL_USB2_PHY_UTMI_DUAL:
 if (udc->pdata->have_sysif_regs) {
 if (udc->pdata->controller_ver) {
 /* controller version 1.6 or above */
--
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/1] usb: gadget: udc: fsl: Introduce FSL_USB2_PHY_UTMI_DUAL

[Tiago Brusamarello]

Initialization for SoCs with dual role phy is being bypassed since
FSL_USB2_PHY_UTMI_DUAL macro is not being evaluated in the FSL gadget
driver. In this state a controller configured in peripheral mode will
not work as a gadget. This patch addresses this issue.

Tested on 4.14.32 using a hardware with the T1024 SoC.

Nikhil Badola (1):
  drivers: usb: Introduce FSL_USB2_PHY_UTMI_DUAL for usb gadget

 drivers/usb/gadget/udc/fsl_udc_core.c | 1 +
 1 file changed, 1 insertion(+)
--
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 v8 1/6] typec: tcpm: Add core support for sink side PPS

[Adam Thomson]

This commit adds code to handle requesting of PPS APDOs. Switching
between standard PDOs and APDOs, and re-requesting an APDO to
modify operating voltage/current will be triggered by an
external call into TCPM.

Signed-off-by: Adam Thomson 
Acked-by: Heikki Krogerus 
Reviewed-by: Guenter Roeck 
---
 drivers/usb/typec/tcpm.c | 569 +--
 include/linux/usb/pd.h   |   4 +-
 include/linux/usb/tcpm.h |   1 +
 3 files changed, 558 insertions(+), 16 deletions(-)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 27192083..b160da3 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -48,6 +48,7 @@
S(SNK_DISCOVERY_DEBOUNCE_DONE), \
S(SNK_WAIT_CAPABILITIES),   \
S(SNK_NEGOTIATE_CAPABILITIES),  \
+   S(SNK_NEGOTIATE_PPS_CAPABILITIES),  \
S(SNK_TRANSITION_SINK), \
S(SNK_TRANSITION_SINK_VBUS),\
S(SNK_READY),   \
@@ -167,6 +168,16 @@ struct pd_mode_data {
struct typec_altmode_desc altmode_desc[SVID_DISCOVERY_MAX];
 };
 
+struct pd_pps_data {
+   u32 min_volt;
+   u32 max_volt;
+   u32 max_curr;
+   u32 out_volt;
+   u32 op_curr;
+   bool supported;
+   bool active;
+};
+
 struct tcpm_port {
struct device *dev;
 
@@ -235,6 +246,7 @@ struct tcpm_port {
struct completion swap_complete;
int swap_status;
 
+   unsigned int negotiated_rev;
unsigned int message_id;
unsigned int caps_count;
unsigned int hard_reset_count;
@@ -258,6 +270,7 @@ struct tcpm_port {
unsigned int nr_snk_vdo;
 
unsigned int operating_snk_mw;
+   bool update_sink_caps;
 
/* Requested current / voltage */
u32 current_limit;
@@ -274,8 +287,13 @@ struct tcpm_port {
/* VDO to retry if UFP responder replied busy */
u32 vdo_retry;
 
-   /* Alternate mode data */
+   /* PPS */
+   struct pd_pps_data pps_data;
+   struct completion pps_complete;
+   bool pps_pending;
+   int pps_status;
 
+   /* Alternate mode data */
struct pd_mode_data mode_data;
struct typec_altmode *partner_altmode[SVID_DISCOVERY_MAX];
struct typec_altmode *port_altmode[SVID_DISCOVERY_MAX];
@@ -493,6 +511,16 @@ static void tcpm_log_source_caps(struct tcpm_port *port)
  pdo_max_voltage(pdo),
  pdo_max_power(pdo));
break;
+   case PDO_TYPE_APDO:
+   if (pdo_apdo_type(pdo) == APDO_TYPE_PPS)
+   scnprintf(msg, sizeof(msg),
+ "%u-%u mV, %u mA",
+ pdo_pps_apdo_min_voltage(pdo),
+ pdo_pps_apdo_max_voltage(pdo),
+ pdo_pps_apdo_max_current(pdo));
+   else
+   strcpy(msg, "undefined APDO");
+   break;
default:
strcpy(msg, "undefined");
break;
@@ -790,11 +818,13 @@ static int tcpm_pd_send_source_caps(struct tcpm_port 
*port)
msg.header = PD_HEADER_LE(PD_CTRL_REJECT,
  port->pwr_role,
  port->data_role,
+ port->negotiated_rev,
  port->message_id, 0);
} else {
msg.header = PD_HEADER_LE(PD_DATA_SOURCE_CAP,
  port->pwr_role,
  port->data_role,
+ port->negotiated_rev,
  port->message_id,
  port->nr_src_pdo);
}
@@ -815,11 +845,13 @@ static int tcpm_pd_send_sink_caps(struct tcpm_port *port)
msg.header = PD_HEADER_LE(PD_CTRL_REJECT,
  port->pwr_role,
  port->data_role,
+ port->negotiated_rev,
  port->message_id, 0);
} else {
msg.header = PD_HEADER_LE(PD_DATA_SINK_CAP,
  port->pwr_role,
  port->data_role,
+ port->negotiated_rev,
  port->message_id,
  port->nr_snk_pdo);
}
@@ -1186,6 +1218,7 @@ static void vdm_run_state_machine(struct tcpm_port *port)
msg.header = 

[PATCH v8 2/6] Documentation: power: Initial effort to document power_supply ABI

[Adam Thomson]

This commit adds generic ABI information regarding power_supply
properties. This is an initial attempt to try and align the usage
of these properties between drivers. As part of this commit,
common Battery and USB related properties have been listed.

Signed-off-by: Adam Thomson 
---
 Documentation/ABI/testing/sysfs-class-power | 443 
 MAINTAINERS |   1 +
 2 files changed, 444 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-class-power 
b/Documentation/ABI/testing/sysfs-class-power
index f85ce9e..e046566 100644
--- a/Documentation/ABI/testing/sysfs-class-power
+++ b/Documentation/ABI/testing/sysfs-class-power
@@ -1,3 +1,446 @@
+= General Properties =
+
+What:  /sys/class/power_supply//manufacturer
+Date:  May 2007
+Contact:   linux...@vger.kernel.org
+Description:
+   Reports the name of the device manufacturer.
+
+   Access: Read
+   Valid values: Represented as string
+
+What:  /sys/class/power_supply//model_name
+Date:  May 2007
+Contact:   linux...@vger.kernel.org
+Description:
+   Reports the name of the device model.
+
+   Access: Read
+   Valid values: Represented as string
+
+What:  /sys/class/power_supply//serial_number
+Date:  January 2008
+Contact:   linux...@vger.kernel.org
+Description:
+   Reports the serial number of the device.
+
+   Access: Read
+   Valid values: Represented as string
+
+What:  /sys/class/power_supply//type
+Date:  May 2010
+Contact:   linux...@vger.kernel.org
+Description:
+   Describes the main type of the supply.
+
+   Access: Read
+   Valid values: "Battery", "UPS", "Mains", "USB"
+
+= Battery Properties =
+
+What:  /sys/class/power_supply//capacity
+Date:  May 2007
+Contact:   linux...@vger.kernel.org
+Description:
+   Fine grain representation of battery capacity.
+   Access: Read
+   Valid values: 0 - 100 (percent)
+
+What:  /sys/class/power_supply//capacity_alert_max
+Date:  July 2012
+Contact:   linux...@vger.kernel.org
+Description:
+   Maximum battery capacity trip-wire value where the supply will
+   notify user-space of the event. This is normally used for the
+   battery discharging scenario where user-space needs to know the
+   battery has dropped to an upper level so it can take
+   appropriate action (e.g. warning user that battery level is
+   low).
+
+   Access: Read, Write
+   Valid values: 0 - 100 (percent)
+
+What:  /sys/class/power_supply//capacity_alert_min
+Date:  July 2012
+Contact:   linux...@vger.kernel.org
+Description:
+   Minimum battery capacity trip-wire value where the supply will
+   notify user-space of the event. This is normally used for the
+   battery discharging scenario where user-space needs to know the
+   battery has dropped to a lower level so it can take
+   appropriate action (e.g. warning user that battery level is
+   critically low).
+
+   Access: Read, Write
+   Valid values: 0 - 100 (percent)
+
+What:  /sys/class/power_supply//capacity_level
+Date:  June 2009
+Contact:   linux...@vger.kernel.org
+Description:
+   Coarse representation of battery capacity.
+
+   Access: Read
+   Valid values: "Unknown", "Critical", "Low", "Normal", "High",
+ "Full"
+
+What:  /sys/class/power_supply//current_avg
+Date:  May 2007
+Contact:   linux...@vger.kernel.org
+Description:
+   Reports an average IBAT current reading for the battery, over a
+   fixed period. Normally devices will provide a fixed interval in
+   which they average readings to smooth out the reported value.
+
+   Access: Read
+   Valid values: Represented in microamps
+
+What:  /sys/class/power_supply//current_max
+Date:  October 2010
+Contact:   linux...@vger.kernel.org
+Description:
+   Reports the maximum IBAT current allowed into the battery.
+
+   Access: Read
+   Valid values: Represented in microamps
+
+What:  /sys/class/power_supply//current_now
+Date:  May 2007
+Contact:   linux...@vger.kernel.org
+Description:
+   Reports an instant, single IBAT current reading for the battery.
+   This value is not averaged/smoothed.
+
+   Access: Read
+   Valid values: Represented in microamps
+
+What:  /sys/class/power_supply//charge_type
+Date:  

[PATCH v8 0/6] typec: tcpm: Add sink side support for PPS

[Adam Thomson]

This patch set adds sink side support for the PPS feature introduced in the
USB PD 3.0 specification.

The source PPS supply is represented using the Power Supply framework to provide
access and control APIs for dealing with it's operating voltage and current,
and switching between a standard PDO and PPS APDO operation. During standard PDO
operation the voltage and current is read-only, but for APDO PPS these are
writable as well to allow for control.

It should be noted that the keepalive for PPS is not handled within TCPM. The
expectation is that the external user will be required to ensure re-requests
occur regularly to ensure PPS remains and the source does not hard reset.


Changes in v8:
 - Rebase onto latest 'usb-next' commit
   (b462e2e0d62a716f7a1b7a7ecea966edc3de45d7) in Greg's USB repo. This picks
   up Jun Li's changes to how PDOs are chosen.
 - Use of '__maybe_unused' in patch 01 (core support), for new APIs that are not
   used until patch 05 (power_supply interface), to avoid warnings
   (-Wunused-function) when applying that patch in isolation. '__maybe_unused'
   usage is removed in patch 05 as it's no longer necessary.

Changes in v7:
 - Further tidy up with bracket usage and unwanted initialisation.
 - Stop using else if statement after break.
 - Added NULL checking of psy_name after devm_kzalloc().
 - Reinstate PD_ROLE_SWAP_TIMEOUT and revert role swap functions to use this.
 - Add PD_PPS_CTRL_TIMEOUT for PPS related control functions.

Changes in v6:
 - Remove unnecessary use of 'data' variable and associated kzalloc/kfree call
   for extended message handling.
 - Add patch for error checking psy_desc struct in psy register code.
 - Add error checking of usb_type property in psy register code.
 - Cosmetic () and initialisation changes as requested by Guenter.
 - Removed Acked-by and Reviewed-by, from Heikki and Sebastian respectively, on
   patch 04 as there have been changes to error handling with regards to
   usb_type, so didn't feel appropriate to keep them.

Changes in v5:
 - Rebase on branch with 'Revert "typec: tcpm: Only request matching pdos"' and
   header changes already included.
 - Update power_supply registration to make power_supply names unique per port,
   to avoid errors creating duplicate psy instances. New name uses port
   dev name as a suffix.
 - Renamed 'connected_type' psy property to 'usb_type', as requested by
   maintainer.
 - Added initial attempt at generic ABI documentation for common psy class
   properties for Battery and USB type supplies.
 - Small update to PPS APDO selection code to limit maximum current requested
   based on sink maximum allowed current. Have left Heikki's 'Acked-by' tag as
   it's a minor change, but can remove if that's not deemed appropriate.

Changes in v4:
 - For PD 3.0 definitions patch, make it benign with regards to existing TCPM
   code so build isn't broken if this one patch is applied, as suggested by
   kbuild robot. Update for dynamic revision is moved to be part of sink side
   PPS support patch.
 - Use PTR_ERR_OR_ZERO macro to simplify return of devm_tcpm_psy_register()
   function, as suggested by kbuild robot.
 - Make devm_tcpm_psy_register() static as not used outside this file.

Changes in v3:
 - Drop 'RFC' from patch series titles
 - Rename PPS related defines to be PPS specific rather than generic APDO titles
 - Update source caps logging to only print PPS APDOs, and for others report as
   undefined.
 - Add ABI documentation for tcpm-source-psy sysfs properties
 - Rebase PDO selection on top of 'typec: tcpm: Only request matching pdos'
   patch.
 - Update capabilities validation introduced in
   'typec: tcpm: Validate source and sink caps' to support PPS APDOs.
 - Dropped power_supply 'type' property update for PPS addition
 - Added 'connected_type' property to power_supply framework, to support
   supplies which can report multiple connected types (e.g. USB), as discussed
   with Heikki.

Changes in v2:
 - Use USB_PD and usb_pd prefixes for macros and inline functions in headers.
 - Negotiate spec revision of PD headers during initial contract agreement.
 - New headers now use SPDX tags for referencing correct license.

Adam Thomson (6):
  typec: tcpm: Add core support for sink side PPS
  Documentation: power: Initial effort to document power_supply ABI
  power: supply: Add error checking of psy desc during registration
  power: supply: Add 'usb_type' property and supporting code
  typec: tcpm: Represent source supply through power_supply
  typec: tcpm: Add support for sink PPS related messages

 Documentation/ABI/testing/sysfs-class-power | 455 +
 MAINTAINERS |   1 +
 drivers/power/supply/power_supply_core.c|  11 +-
 drivers/power/supply/power_supply_sysfs.c   |  45 ++
 drivers/usb/typec/Kconfig   |   1 +
 drivers/usb/typec/fusb302/Kconfig   |   2 +-
 drivers/usb/typec/fusb302/fusb302.c |  63 +-
 drivers/usb/typec/tcpm.c   

[PATCH v8 3/6] power: supply: Add error checking of psy desc during registration

[Adam Thomson]

Currently there's no error checking of this parameter in the
registration function and it's blindly added to psy class and
subsequently used as is. For example if this is NULL the call
to psy_register_thermal() will try to dereference the pointer
thus causing a kernel dump.

This commit updates the registration code to add some basic
checks on the desc pointer validity, name, and presence of
properties.

Signed-off-by: Adam Thomson 
---
 drivers/power/supply/power_supply_core.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/power/supply/power_supply_core.c 
b/drivers/power/supply/power_supply_core.c
index feac7b0..a7984af 100644
--- a/drivers/power/supply/power_supply_core.c
+++ b/drivers/power/supply/power_supply_core.c
@@ -849,6 +849,9 @@ static void psy_unregister_cooler(struct power_supply *psy)
pr_warn("%s: Expected proper parent device for '%s'\n",
__func__, desc->name);
 
+   if (!desc || !desc->name || !desc->properties || !desc->num_properties)
+   return ERR_PTR(-EINVAL);
+
psy = kzalloc(sizeof(*psy), GFP_KERNEL);
if (!psy)
return ERR_PTR(-ENOMEM);
-- 
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 v8 6/6] typec: tcpm: Add support for sink PPS related messages

[Adam Thomson]

This commit adds sink side support for Get_Status, Status,
Get_PPS_Status and PPS_Status handling. As there's the
potential for a partner to respond with Not_Supported,
handling of this message is also added. Sending of
Not_Supported is added to handle messagescreceived but not
yet handled.

Signed-off-by: Adam Thomson 
Acked-by: Heikki Krogerus 
Reviewed-by: Guenter Roeck 
---
 drivers/usb/typec/tcpm.c | 143 ---
 1 file changed, 134 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 7547097..4483dc4 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -19,7 +19,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -114,6 +116,11 @@
S(SNK_TRYWAIT_VBUS),\
S(BIST_RX), \
\
+   S(GET_STATUS_SEND), \
+   S(GET_STATUS_SEND_TIMEOUT), \
+   S(GET_PPS_STATUS_SEND), \
+   S(GET_PPS_STATUS_SEND_TIMEOUT), \
+   \
S(ERROR_RECOVERY),  \
S(PORT_RESET),  \
S(PORT_RESET_WAIT_OFF)
@@ -144,6 +151,7 @@ enum pd_msg_request {
PD_MSG_NONE = 0,
PD_MSG_CTRL_REJECT,
PD_MSG_CTRL_WAIT,
+   PD_MSG_CTRL_NOT_SUPP,
PD_MSG_DATA_SINK_CAP,
PD_MSG_DATA_SOURCE_CAP,
 };
@@ -1411,10 +1419,42 @@ static int tcpm_validate_caps(struct tcpm_port *port, 
const u32 *pdo,
 /*
  * PD (data, control) command handling functions
  */
+static inline enum tcpm_state ready_state(struct tcpm_port *port)
+{
+   if (port->pwr_role == TYPEC_SOURCE)
+   return SRC_READY;
+   else
+   return SNK_READY;
+}
 
 static int tcpm_pd_send_control(struct tcpm_port *port,
enum pd_ctrl_msg_type type);
 
+static void tcpm_handle_alert(struct tcpm_port *port, const __le32 *payload,
+ int cnt)
+{
+   u32 p0 = le32_to_cpu(payload[0]);
+   unsigned int type = usb_pd_ado_type(p0);
+
+   if (!type) {
+   tcpm_log(port, "Alert message received with no type");
+   return;
+   }
+
+   /* Just handling non-battery alerts for now */
+   if (!(type & USB_PD_ADO_TYPE_BATT_STATUS_CHANGE)) {
+   switch (port->state) {
+   case SRC_READY:
+   case SNK_READY:
+   tcpm_set_state(port, GET_STATUS_SEND, 0);
+   break;
+   default:
+   tcpm_queue_message(port, PD_MSG_CTRL_WAIT);
+   break;
+   }
+   }
+}
+
 static void tcpm_pd_data_request(struct tcpm_port *port,
 const struct pd_message *msg)
 {
@@ -1502,6 +1542,14 @@ static void tcpm_pd_data_request(struct tcpm_port *port,
tcpm_set_state(port, BIST_RX, 0);
}
break;
+   case PD_DATA_ALERT:
+   tcpm_handle_alert(port, msg->payload, cnt);
+   break;
+   case PD_DATA_BATT_STATUS:
+   case PD_DATA_GET_COUNTRY_INFO:
+   /* Currently unsupported */
+   tcpm_queue_message(port, PD_MSG_CTRL_NOT_SUPP);
+   break;
default:
tcpm_log(port, "Unhandled data message type %#x", type);
break;
@@ -1584,6 +1632,7 @@ static void tcpm_pd_ctrl_request(struct tcpm_port *port,
break;
case PD_CTRL_REJECT:
case PD_CTRL_WAIT:
+   case PD_CTRL_NOT_SUPP:
switch (port->state) {
case SNK_NEGOTIATE_CAPABILITIES:
/* USB PD specification, Figure 8-43 */
@@ -1703,12 +1752,75 @@ static void tcpm_pd_ctrl_request(struct tcpm_port *port,
break;
}
break;
+   case PD_CTRL_GET_SOURCE_CAP_EXT:
+   case PD_CTRL_GET_STATUS:
+   case PD_CTRL_FR_SWAP:
+   case PD_CTRL_GET_PPS_STATUS:
+   case PD_CTRL_GET_COUNTRY_CODES:
+   /* Currently not supported */
+   tcpm_queue_message(port, PD_MSG_CTRL_NOT_SUPP);
+   break;
default:
tcpm_log(port, "Unhandled ctrl message type %#x", type);
break;
}
 }
 
+static void tcpm_pd_ext_msg_request(struct tcpm_port *port,
+   const struct pd_message *msg)
+{
+   enum pd_ext_msg_type type = pd_header_type_le(msg->header);
+   unsigned int data_size = 
pd_ext_header_data_size_le(msg->ext_msg.header);
+
+   if (!(msg->ext_msg.header && PD_EXT_HDR_CHUNKED)) {
+   tcpm_log(port, "Unchunked extended 

[PATCH v8 4/6] power: supply: Add 'usb_type' property and supporting code

[Adam Thomson]

This commit adds the 'usb_type' property to represent USB supplies
which can report a number of different types based on a connection
event.

Examples of this already exist in drivers whereby the existing 'type'
property is updated, based on an event, to represent what was
connected (e.g. USB, USB_DCP, USB_ACA, ...). Current implementations
however don't show all supported connectable types, so this knowledge
has to be exlicitly known for each driver that supports this.

The 'usb_type' property is intended to fill this void and show users
all possible USB types supported by a driver. The property, when read,
shows all available types for the driver, and the one currently chosen
is highlighted/bracketed. It is expected that the 'type' property
would then just show the top-level type 'USB', and this would be
static.

Currently the 'usb_type' enum contains all of the USB variant types
that exist for the 'type' enum at this time, and in addition has
SDP and PPS types. The mirroring is intentional so as to not impact
existing usage of the 'type' property.

Signed-off-by: Adam Thomson 
---
 Documentation/ABI/testing/sysfs-class-power | 12 
 drivers/power/supply/power_supply_core.c|  8 -
 drivers/power/supply/power_supply_sysfs.c   | 45 +
 include/linux/power_supply.h| 16 ++
 4 files changed, 80 insertions(+), 1 deletion(-)

diff --git a/Documentation/ABI/testing/sysfs-class-power 
b/Documentation/ABI/testing/sysfs-class-power
index e046566..5e23e22 100644
--- a/Documentation/ABI/testing/sysfs-class-power
+++ b/Documentation/ABI/testing/sysfs-class-power
@@ -409,6 +409,18 @@ Description:
Access: Read
Valid values: Represented in 1/10 Degrees Celsius
 
+What:  /sys/class/power_supply//usb_type
+Date:  March 2018
+Contact:   linux...@vger.kernel.org
+Description:
+   Reports what type of USB connection is currently active for
+   the supply, for example it can show if USB-PD capable source
+   is attached.
+
+   Access: Read-Only
+   Valid values: "Unknown", "SDP", "DCP", "CDP", "ACA", "C", "PD",
+ "PD_DRP", "PD_PPS", "BrickID"
+
 What:  /sys/class/power_supply//voltage_max
 Date:  January 2008
 Contact:   linux...@vger.kernel.org
diff --git a/drivers/power/supply/power_supply_core.c 
b/drivers/power/supply/power_supply_core.c
index a7984af..ecd68c2 100644
--- a/drivers/power/supply/power_supply_core.c
+++ b/drivers/power/supply/power_supply_core.c
@@ -843,7 +843,7 @@ static void psy_unregister_cooler(struct power_supply *psy)
 {
struct device *dev;
struct power_supply *psy;
-   int rc;
+   int i, rc;
 
if (!parent)
pr_warn("%s: Expected proper parent device for '%s'\n",
@@ -852,6 +852,12 @@ static void psy_unregister_cooler(struct power_supply *psy)
if (!desc || !desc->name || !desc->properties || !desc->num_properties)
return ERR_PTR(-EINVAL);
 
+   for (i = 0; i < desc->num_properties; ++i) {
+   if ((desc->properties[i] == POWER_SUPPLY_PROP_USB_TYPE) &&
+   (!desc->usb_types || !desc->num_usb_types))
+   return ERR_PTR(-EINVAL);
+   }
+
psy = kzalloc(sizeof(*psy), GFP_KERNEL);
if (!psy)
return ERR_PTR(-ENOMEM);
diff --git a/drivers/power/supply/power_supply_sysfs.c 
b/drivers/power/supply/power_supply_sysfs.c
index 5204f11..1350068 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -46,6 +46,11 @@
"USB_PD", "USB_PD_DRP", "BrickID"
 };
 
+static const char * const power_supply_usb_type_text[] = {
+   "Unknown", "SDP", "DCP", "CDP", "ACA", "C",
+   "PD", "PD_DRP", "PD_PPS", "BrickID"
+};
+
 static const char * const power_supply_status_text[] = {
"Unknown", "Charging", "Discharging", "Not charging", "Full"
 };
@@ -73,6 +78,41 @@
"Unknown", "System", "Device"
 };
 
+static ssize_t power_supply_show_usb_type(struct device *dev,
+ enum power_supply_usb_type *usb_types,
+ ssize_t num_usb_types,
+ union power_supply_propval *value,
+ char *buf)
+{
+   enum power_supply_usb_type usb_type;
+   ssize_t count = 0;
+   bool match = false;
+   int i;
+
+   for (i = 0; i < num_usb_types; ++i) {
+   usb_type = usb_types[i];
+
+   if (value->intval == usb_type) {
+   count += sprintf(buf + count, "[%s] ",
+power_supply_usb_type_text[usb_type]);
+   match = true;
+   } else {
+   count += sprintf(buf + count, "%s 

[PATCH v8 5/6] typec: tcpm: Represent source supply through power_supply

[Adam Thomson]

This commit adds a power_supply class instance to represent a
PD source's voltage and current properties. This provides an
interface for reading these properties from user-space or other
drivers.

For PPS enabled Sources, this also provides write access to set
the current and voltage and allows for swapping between standard
PDO and PPS APDO.

As this represents a superset of the information provided in the
fusb302 driver, the power_supply instance in that code is removed
as part of this change, so reverting the commit titled
'typec: tcpm: Represent source supply through power_supply class'

Signed-off-by: Adam Thomson 
Reviewed-by: Guenter Roeck 
---
 drivers/usb/typec/Kconfig   |   1 +
 drivers/usb/typec/fusb302/Kconfig   |   2 +-
 drivers/usb/typec/fusb302/fusb302.c |  63 +
 drivers/usb/typec/tcpm.c| 251 +++-
 4 files changed, 251 insertions(+), 66 deletions(-)

diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index 030f88c..2c8eab1 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -49,6 +49,7 @@ config TYPEC_TCPM
tristate "USB Type-C Port Controller Manager"
depends on USB
select USB_ROLE_SWITCH
+   select POWER_SUPPLY
help
  The Type-C Port Controller Manager provides a USB PD and USB Type-C
  state machine for use with Type-C Port Controllers.
diff --git a/drivers/usb/typec/fusb302/Kconfig 
b/drivers/usb/typec/fusb302/Kconfig
index 48a4f2f..fce099f 100644
--- a/drivers/usb/typec/fusb302/Kconfig
+++ b/drivers/usb/typec/fusb302/Kconfig
@@ -1,6 +1,6 @@
 config TYPEC_FUSB302
tristate "Fairchild FUSB302 Type-C chip driver"
-   depends on I2C && POWER_SUPPLY
+   depends on I2C
help
  The Fairchild FUSB302 Type-C chip driver that works with
  Type-C Port Controller Manager to provide USB PD and USB
diff --git a/drivers/usb/typec/fusb302/fusb302.c 
b/drivers/usb/typec/fusb302/fusb302.c
index 664463d..eba6bb8 100644
--- a/drivers/usb/typec/fusb302/fusb302.c
+++ b/drivers/usb/typec/fusb302/fusb302.c
@@ -18,7 +18,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -99,11 +98,6 @@ struct fusb302_chip {
/* lock for sharing chip states */
struct mutex lock;
 
-   /* psy + psy status */
-   struct power_supply *psy;
-   u32 current_limit;
-   u32 supply_voltage;
-
/* chip status */
enum toggling_mode toggling_mode;
enum src_current_status src_current_status;
@@ -862,13 +856,11 @@ static int tcpm_set_vbus(struct tcpc_dev *dev, bool on, 
bool charge)
chip->vbus_on = on;
fusb302_log(chip, "vbus := %s", on ? "On" : "Off");
}
-   if (chip->charge_on == charge) {
+   if (chip->charge_on == charge)
fusb302_log(chip, "charge is already %s",
charge ? "On" : "Off");
-   } else {
+   else
chip->charge_on = charge;
-   power_supply_changed(chip->psy);
-   }
 
 done:
mutex_unlock(>lock);
@@ -884,11 +876,6 @@ static int tcpm_set_current_limit(struct tcpc_dev *dev, 
u32 max_ma, u32 mv)
fusb302_log(chip, "current limit: %d ma, %d mv (not implemented)",
max_ma, mv);
 
-   chip->supply_voltage = mv;
-   chip->current_limit = max_ma;
-
-   power_supply_changed(chip->psy);
-
return 0;
 }
 
@@ -1682,43 +1669,6 @@ static irqreturn_t fusb302_irq_intn(int irq, void 
*dev_id)
return IRQ_HANDLED;
 }
 
-static int fusb302_psy_get_property(struct power_supply *psy,
-   enum power_supply_property psp,
-   union power_supply_propval *val)
-{
-   struct fusb302_chip *chip = power_supply_get_drvdata(psy);
-
-   switch (psp) {
-   case POWER_SUPPLY_PROP_ONLINE:
-   val->intval = chip->charge_on;
-   break;
-   case POWER_SUPPLY_PROP_VOLTAGE_NOW:
-   val->intval = chip->supply_voltage * 1000; /* mV -> µV */
-   break;
-   case POWER_SUPPLY_PROP_CURRENT_MAX:
-   val->intval = chip->current_limit * 1000; /* mA -> µA */
-   break;
-   default:
-   return -ENODATA;
-   }
-
-   return 0;
-}
-
-static enum power_supply_property fusb302_psy_properties[] = {
-   POWER_SUPPLY_PROP_ONLINE,
-   POWER_SUPPLY_PROP_VOLTAGE_NOW,
-   POWER_SUPPLY_PROP_CURRENT_MAX,
-};
-
-static const struct power_supply_desc fusb302_psy_desc = {
-   .name   = "fusb302-typec-source",
-   .type   = POWER_SUPPLY_TYPE_USB_TYPE_C,
-   .properties = fusb302_psy_properties,
-   .num_properties = ARRAY_SIZE(fusb302_psy_properties),
-   .get_property   = fusb302_psy_get_property,
-};
-
 static int init_gpio(struct fusb302_chip *chip)
 

Re: howto debug xhci driver?

[Bin Liu]

On Mon, Apr 23, 2018 at 07:21:12PM +0530, Tushar Nimkar wrote:
> Hi,
> 
> On 2018-04-23 18:58, Bin Liu wrote:
> >On Mon, Apr 23, 2018 at 11:14:55AM +0530, Tushar Nimkar wrote:
> >>On 2018-04-21 00:03, Bin Liu wrote:
> >>>Hi,
> >>>
> >>>On Tue, Mar 20, 2018 at 02:28:00PM -0700, Paul Zimmerman wrote:
> Forgot to CC linux-usb.
> 
> 
>  Forwarded Message 
> Subject: Re: howto debug xhci driver?
> Date: Tue, 20 Mar 2018 13:56:21 -0700
> From: Paul Zimmerman 
> To: Bin Liu 
> CC: Felipe Balbi 
> 
> Hi,
> 
> Bin Liu  writes:
> >>Bin Liu  writes:
> BTY, the issue I am trying to debug is when reading
> bulk IN data from a USB2.0 device, if the device
> doesn't have data to transmit and NAKs the IN packet,
> after 4 pairs of IN-NAK transactions, xhci stops
> sending further IN tokens until the next SOF, which
> leaves ~90us gape on the bus.
> 
> But when reading data from a USB2.0 thumb drive, this
> issue doesn't happen, even if the device NAKs the IN
> tokens, xhci still keeps sending IN tokens, which is
> way more than 4 pairs of IN-NAK transactions.
> >>>
> >>>Thumb drive has Bulk endpoints, what is the other
> >>>device's transfer type?
> >>
> >>It is bulk too. I asked for device descriptors. This is a
> >>remote debug effort for me, I don't have that device...
> >>
> >>>
> Any one has a clue on what causes xhci to stop sending
> IN tokens after the device NAK'd 4 times?
> >
> >By accident, I reproduced the issue if addng a hub in the
> >middle... any comments about why a hub changes this xhci
> >behavior is appreciated.
> 
> none off the top of my head. Maybe Mathias can suggest
> something.
> >>>
> >>>The issue seems to be not related to how many bulk IN-NAK pairs
> >>>before host stops sending IN token, but the host stops IN token
> >>>if 1) the device ever NAK'd an bulk IN token, and 2) there is
> >>>about 90~100us left to the next SOF. Then all the rest of
> >>>bandwidth is wasted.
> >>>
> >>>Is it about xhci bandwidth schduling? /me started reading...
> >>
> >>is this AM4 or AM5? Perhaps go after Synopsys' known errata list?
> >
> >I see the issue on both AM4 & AM5. I don't have access to the
> >errata list, I guess I should talk to TI internal for the list?
> 
> I have a hazy recollection of something like this being a "feature" of
> the Synopsys core, to cut down on the excessive number of IN-NAK
> transactions you can sometimes get on the USB bus. So yep, you
> should talk to your Synopsys guy about this.
> >>>
> >>>Thanks for the information. We have been talking to Synopsis for this
> >>>issue, the progress is slow, one of the reasons is that the DWC3
> >>>version
> >>>is very old :(
> >>Bin, What is the version no? I have seen similar thing but on USB3.0
> >
> >On multiple versions: from 2.02a to 2.60a.
> suggest you to check errata list if not.

Yeah, stuck at here right now - too slow to get a copy of the errata :(

> >
> >>with dwc3 3.00a
> >
> >Do you mean you only see the problem in super-speed but not high-speed
> >with 3.00a?
> yes so far..
> >
> >>May I know how you confirmed/debug missing IN-ACK?
> >
> >Using bus protocol analyzer to capture bus traces. However my
> >issue is not
> >about missing IN-ACK, but IN-NAK - the host stops sending IN tokens too
> >early if the device NAK'd previous IN packets.
> >
> >Please confirm you mean IN-NAK instead in your case?
> it is IN-ACK, ss device send ERDY there should be IN-ACK saying NumP
> > 0 from host :)

Sounds like we face two different issues then :)

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

Re: howto debug xhci driver?

[Tushar Nimkar]

Hi,

On 2018-04-23 18:58, Bin Liu wrote:

On Mon, Apr 23, 2018 at 11:14:55AM +0530, Tushar Nimkar wrote:

On 2018-04-21 00:03, Bin Liu wrote:
>Hi,
>
>On Tue, Mar 20, 2018 at 02:28:00PM -0700, Paul Zimmerman wrote:
>>Forgot to CC linux-usb.
>>
>>
>> Forwarded Message 
>>Subject: Re: howto debug xhci driver?
>>Date: Tue, 20 Mar 2018 13:56:21 -0700
>>From: Paul Zimmerman 
>>To: Bin Liu 
>>CC: Felipe Balbi 
>>
>>Hi,
>>
>>Bin Liu  writes:
Bin Liu  writes:
>>BTY, the issue I am trying to debug is when reading
>>bulk IN data from a USB2.0 device, if the device
>>doesn't have data to transmit and NAKs the IN packet,
>>after 4 pairs of IN-NAK transactions, xhci stops
>>sending further IN tokens until the next SOF, which
>>leaves ~90us gape on the bus.
>>
>>But when reading data from a USB2.0 thumb drive, this
>>issue doesn't happen, even if the device NAKs the IN
>>tokens, xhci still keeps sending IN tokens, which is
>>way more than 4 pairs of IN-NAK transactions.
>
>Thumb drive has Bulk endpoints, what is the other
>device's transfer type?

It is bulk too. I asked for device descriptors. This is a
remote debug effort for me, I don't have that device...

>
>>Any one has a clue on what causes xhci to stop sending
>>IN tokens after the device NAK'd 4 times?
>>>
>>>By accident, I reproduced the issue if addng a hub in the
>>>middle... any comments about why a hub changes this xhci
>>>behavior is appreciated.
>>
>>none off the top of my head. Maybe Mathias can suggest
>>something.
>
>The issue seems to be not related to how many bulk IN-NAK pairs
>before host stops sending IN token, but the host stops IN token
>if 1) the device ever NAK'd an bulk IN token, and 2) there is
>about 90~100us left to the next SOF. Then all the rest of
>bandwidth is wasted.
>
>Is it about xhci bandwidth schduling? /me started reading...

is this AM4 or AM5? Perhaps go after Synopsys' known errata list?
>>>
>>>I see the issue on both AM4 & AM5. I don't have access to the
>>>errata list, I guess I should talk to TI internal for the list?
>>
>>I have a hazy recollection of something like this being a "feature" of
>>the Synopsys core, to cut down on the excessive number of IN-NAK
>>transactions you can sometimes get on the USB bus. So yep, you
>>should talk to your Synopsys guy about this.
>
>Thanks for the information. We have been talking to Synopsis for this
>issue, the progress is slow, one of the reasons is that the DWC3
>version
>is very old :(
Bin, What is the version no? I have seen similar thing but on USB3.0


On multiple versions: from 2.02a to 2.60a.

suggest you to check errata list if not.



with dwc3 3.00a


Do you mean you only see the problem in super-speed but not high-speed
with 3.00a?

yes so far..



May I know how you confirmed/debug missing IN-ACK?


Using bus protocol analyzer to capture bus traces. However my issue is 
not

about missing IN-ACK, but IN-NAK - the host stops sending IN tokens too
early if the device NAK'd previous IN packets.

Please confirm you mean IN-NAK instead in your case?
it is IN-ACK, ss device send ERDY there should be IN-ACK saying NumP > 0 
from host :)


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


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

[PATCH 2/2] USB: musb: host: prevent core phy initialisation

[Bin Liu]

From: Johan Hovold 

Set the new HCD flag which prevents USB core from trying to manage our
phys.

This is needed to be able to associate the controller platform device
with the glue device device-tree node on the BBB which uses legacy USB
phys. Otherwise, the generic phy lookup in usb_phy_roothub_init() and
thus HCD registration fails repeatedly with -EPROBE_DEFER (see commit
178a0bce05cb ("usb: core: hcd: integrate the PHY wrapper into the HCD
core")).

Note that a related phy-lookup issue was recently worked around in the
phy core by commit b7563e2796f8 ("phy: work around 'phys' references to
usb-nop-xceiv devices"). Something similar may now be needed for other
USB phys, and in particular if we eventually want to let USB core manage
musb generic phys.

Cc: Arnd Bergmann 
Cc: Martin Blumenstingl 
Signed-off-by: Johan Hovold 
Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_host.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 3a8451a15f7f..4fa372c845e1 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2754,6 +2754,7 @@ int musb_host_setup(struct musb *musb, int power_budget)
hcd->self.otg_port = 1;
musb->xceiv->otg->host = >self;
hcd->power_budget = 2 * (power_budget ? : 250);
+   hcd->skip_phy_initialization = 1;
 
ret = usb_add_hcd(hcd, 0, 0);
if (ret < 0)
-- 
1.9.1

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

[PATCH 1/2] USB: musb: dsps: drop duplicate phy initialisation

[Bin Liu]

From: Johan Hovold 

Since commit 39cee200c23e ("usb: musb: core: call init and shutdown for
the usb phy") the musb USB phy is initialised by musb_core, but the
original initialisation in the dsps-glue init callback was left in
place resulting in two calls to phy init during probe (and similarly,
two shutdowns on remove).

Drop the duplicate phy init and shutdown calls from the dsps glue in
favour of the ones in musb core, which other glue drivers rely on.

Note however that any generic phy is still initialised in the glue init
callback (just as for the other drivers).

Cc: Uwe Kleine-König 
Signed-off-by: Johan Hovold 
Acked-by: Uwe Kleine-König 
Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_dsps.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 05a679d5e3a2..6a60bc0490c5 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -451,7 +451,6 @@ static int dsps_musb_init(struct musb *musb)
if (!rev)
return -ENODEV;
 
-   usb_phy_init(musb->xceiv);
if (IS_ERR(musb->phy))  {
musb->phy = NULL;
} else {
@@ -501,7 +500,6 @@ static int dsps_musb_exit(struct musb *musb)
struct dsps_glue *glue = dev_get_drvdata(dev->parent);
 
del_timer_sync(>dev_timer);
-   usb_phy_shutdown(musb->xceiv);
phy_power_off(musb->phy);
phy_exit(musb->phy);
debugfs_remove_recursive(glue->dbgfs_root);
-- 
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 0/2] musb fixes for v4.17-rc3

[Bin Liu]

Hi Greg,

Here are musb fixes for v4.17-rc3, which fix two bugs in phy handling. Please
let me know if any change is needed.

Regards,
-Bin.


Johan Hovold (2):
  USB: musb: dsps: drop duplicate phy initialisation
  USB: musb: host: prevent core phy initialisation

 drivers/usb/musb/musb_dsps.c | 2 --
 drivers/usb/musb/musb_host.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

-- 
1.9.1

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

Re: howto debug xhci driver?

[Bin Liu]

On Mon, Apr 23, 2018 at 11:14:55AM +0530, Tushar Nimkar wrote:
> On 2018-04-21 00:03, Bin Liu wrote:
> >Hi,
> >
> >On Tue, Mar 20, 2018 at 02:28:00PM -0700, Paul Zimmerman wrote:
> >>Forgot to CC linux-usb.
> >>
> >>
> >> Forwarded Message 
> >>Subject: Re: howto debug xhci driver?
> >>Date: Tue, 20 Mar 2018 13:56:21 -0700
> >>From: Paul Zimmerman 
> >>To: Bin Liu 
> >>CC: Felipe Balbi 
> >>
> >>Hi,
> >>
> >>Bin Liu  writes:
> Bin Liu  writes:
> >>BTY, the issue I am trying to debug is when reading
> >>bulk IN data from a USB2.0 device, if the device
> >>doesn't have data to transmit and NAKs the IN packet,
> >>after 4 pairs of IN-NAK transactions, xhci stops
> >>sending further IN tokens until the next SOF, which
> >>leaves ~90us gape on the bus.
> >>
> >>But when reading data from a USB2.0 thumb drive, this
> >>issue doesn't happen, even if the device NAKs the IN
> >>tokens, xhci still keeps sending IN tokens, which is
> >>way more than 4 pairs of IN-NAK transactions.
> >
> >Thumb drive has Bulk endpoints, what is the other
> >device's transfer type?
> 
> It is bulk too. I asked for device descriptors. This is a
> remote debug effort for me, I don't have that device...
> 
> >
> >>Any one has a clue on what causes xhci to stop sending
> >>IN tokens after the device NAK'd 4 times?
> >>>
> >>>By accident, I reproduced the issue if addng a hub in the
> >>>middle... any comments about why a hub changes this xhci
> >>>behavior is appreciated.
> >>
> >>none off the top of my head. Maybe Mathias can suggest
> >>something.
> >
> >The issue seems to be not related to how many bulk IN-NAK pairs
> >before host stops sending IN token, but the host stops IN token
> >if 1) the device ever NAK'd an bulk IN token, and 2) there is
> >about 90~100us left to the next SOF. Then all the rest of
> >bandwidth is wasted.
> >
> >Is it about xhci bandwidth schduling? /me started reading...
> 
> is this AM4 or AM5? Perhaps go after Synopsys' known errata list?
> >>>
> >>>I see the issue on both AM4 & AM5. I don't have access to the
> >>>errata list, I guess I should talk to TI internal for the list?
> >>
> >>I have a hazy recollection of something like this being a "feature" of
> >>the Synopsys core, to cut down on the excessive number of IN-NAK
> >>transactions you can sometimes get on the USB bus. So yep, you
> >>should talk to your Synopsys guy about this.
> >
> >Thanks for the information. We have been talking to Synopsis for this
> >issue, the progress is slow, one of the reasons is that the DWC3
> >version
> >is very old :(
> Bin, What is the version no? I have seen similar thing but on USB3.0

On multiple versions: from 2.02a to 2.60a.

> with dwc3 3.00a

Do you mean you only see the problem in super-speed but not high-speed
with 3.00a?

> May I know how you confirmed/debug missing IN-ACK?

Using bus protocol analyzer to capture bus traces. However my issue is not
about missing IN-ACK, but IN-NAK - the host stops sending IN tokens too
early if the device NAK'd previous IN packets.

Please confirm you mean IN-NAK instead in your case?

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 v4] usb: dwc2: dwc2_vbus_supply_init: fix error check

[Tomeu Vizoso]

Hi,

could this patch be picked up, please? Or if for some reason it cannot
be, could the commit that introduced the regression be reverted?

It's causing some tests in KernelCI to fail:

https://storage.kernelci.org/next/master/next-20180423/arm/multi_v7_defconfig/lab-collabora/sleep-rk3288-veyron-jaq.html

Thanks,

Tomeu


On 11 April 2018 at 08:50, Minas Harutyunyan
<minas.harutyun...@synopsys.com> wrote:
> Hi Heiko,
>
> On 4/10/2018 7:37 PM, Heiko Stübner wrote:
>> Am Dienstag, 10. April 2018, 15:52:25 CEST schrieb Minas Harutyunyan:
>>> Hi Heiko,
>>>
>>> On 4/10/2018 4:28 PM, Heiko Stuebner wrote:
>>>> Am Montag, 26. März 2018, 11:00:01 CEST schrieb Tomeu Vizoso:
>>>>> devm_regulator_get_optional returns -ENODEV if the regulator isn't
>>>>> there, so if that's the case we have to make sure not to leave -ENODEV
>>>>> in the regulator pointer.
>>>>>
>>>>> Also, make sure we return 0 in that case, but correctly propagate any
>>>>> other errors. Also propagate the error from _dwc2_hcd_start.
>>>>>
>>>>> Fixes: 531ef5ebea96 ("usb: dwc2: add support for host mode external vbus
>>>>> supply") Cc: Amelie Delaunay <amelie.delau...@st.com>
>>>>> Signed-off-by: Tomeu Vizoso <tomeu.viz...@collabora.com>
>>>>
>>>> The patch that gets fixed here also breaks display-output on dwc2-based
>>>> Rockchip devices (likely even more), probably due to making the regulator
>>>> framework hickup.
>>>
>>> Could you please elaborate what mean "breaks display-output".
>>> On which Kernel version you apply this patch?
>>
>> I think I may have written that poorly. _Without_ this patch I get
>> display breakage on the most recent torvalds/master (merge-window)
>> where "usb: dwc2: add support for host mode external vbus supply" is
>> applied and this patch fixes the issue.
>>
>> "breaks display output" means both hdmi + edp output are missing
>> also including the backlight staying off.
>>
>> The patch we're fixing here, causes a null-pointer dereference in the
>> regulator framework, which seems to also cause issues when other
>> regulators are enabled, which I think is what I'm seeing here.
>>
>>
> Thank you for clarification. Earlier you added "reviewed" tag, this
> feedback can assumed as "tested" tag.
>
> Thanks,
> Minas
>
>> Heiko
>>
>>>
>>> Thanks,
>>> Minas
>>>
>>>> With this patch applied, apart from not seeing the NULL-ptr, I also get
>>>> display output on my rk3288-veycron Chromebook again, so
>>>>
>>>> Tested-by: Heiko Stuebner <he...@sntech.de>
>>>>
>>>>> v2: Only overwrite the error in the pointer after checking it (Heiko
>>>>>
>>>>>   Stübner <he...@sntech.de>)
>>>>>
>>>>> v3: Remove hunks that shouldn't be in this patch
>>>>> v4: Don't overwrite the error code before returning it (kbuild test
>>>>>
>>>>>   robot <l...@intel.com>)
>>>>>
>>>>> ---
>>>>>
>>>>>drivers/usb/dwc2/hcd.c | 13 -
>>>>>1 file changed, 8 insertions(+), 5 deletions(-)
>>>>>
>>>>> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
>>>>> index 190f95964000..c51b73b3e048 100644
>>>>> --- a/drivers/usb/dwc2/hcd.c
>>>>> +++ b/drivers/usb/dwc2/hcd.c
>>>>> @@ -358,9 +358,14 @@ static void dwc2_gusbcfg_init(struct dwc2_hsotg
>>>>> *hsotg)>>
>>>>>static int dwc2_vbus_supply_init(struct dwc2_hsotg *hsotg)
>>>>>{
>>>>>
>>>>> +  int ret;
>>>>> +
>>>>>
>>>>>hsotg->vbus_supply = devm_regulator_get_optional(hsotg->dev, 
>>>>> "vbus");
>>>>>
>>>>> -  if (IS_ERR(hsotg->vbus_supply))
>>>>> -  return 0;
>>>>> +  if (IS_ERR(hsotg->vbus_supply)) {
>>>>> +  ret = PTR_ERR(hsotg->vbus_supply);
>>>>> +  hsotg->vbus_supply = NULL;
>>>>> +  return ret == -ENODEV ? 0 : ret;
>>>>> +  }
>>>>>
>>>>>return regulator_enable(hsotg->vbus_supply);
>>>>>
>>>>>}
>>>>>
>>>>> @@ -4342,9 +4347,7 @@ static int _dwc2_hcd_start(struct usb_hcd *hcd)
>>>>>
>>>>>spin_unlock_irqrestore(>lock, flags);
>>>>>
>>>>> -  dwc2_vbus_supply_init(hsotg);
>>>>> -
>>>>> -  return 0;
>>>>> +  return dwc2_vbus_supply_init(hsotg);
>>>>>
>>>>>}
>>>>>
>>>>>/*
>>
>>
>>
>
--
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 v7 1/6] typec: tcpm: Add core support for sink side PPS

[Greg Kroah-Hartman]

On Mon, Apr 23, 2018 at 12:47:47PM +, Adam Thomson wrote:
> On 23 April 2018 12:28, Greg Kroah-Hartman wrote:
> 
> > On Mon, Apr 23, 2018 at 11:06:25AM +, Adam Thomson wrote:
> > > On 23 April 2018 09:25, Greg Kroah-Hartman wrote:
> > >
> > > > On Mon, Apr 23, 2018 at 07:49:38AM +, Adam Thomson wrote:
> > > > > On 22 April 2018 21:58, Adam Thomson wrote:
> > > > >
> > > > > > On 22 April 2018 15:05, Greg Kroah-Hartman wrote:
> > > > > >
> > > > > > > On Fri, Mar 23, 2018 at 10:12:20AM +, Adam Thomson wrote:
> > > > > > > > This commit adds code to handle requesting of PPS APDOs. 
> > > > > > > > Switching
> > > > > > > > between standard PDOs and APDOs, and re-requesting an APDO to
> > > > > > > > modify operating voltage/current will be triggered by an
> > > > > > > > external call into TCPM.
> > > > > > > >
> > > > > > > > Signed-off-by: Adam Thomson
> > 
> > > > > > > > Acked-by: Heikki Krogerus 
> > > > > > > > Reviewed-by: Guenter Roeck 
> > > > > > > > ---
> > > > > > > >  drivers/usb/typec/tcpm.c | 517
> > > > > > > ++-
> > > > > > > >  include/linux/usb/pd.h   |   4 +-
> > > > > > > >  include/linux/usb/tcpm.h |   1 +
> > > > > > > >  3 files changed, 509 insertions(+), 13 deletions(-)
> > > > > > >
> > > > > > > This patch adds build warnings to the tree, so I can't take it, 
> > > > > > > sorry.
> > > > > > > Please fix up and resend.
> > > > > >
> > > > > > No problem. Sorry for that. Will take a look and resolve the 
> > > > > > warnings.
> > > > >
> > > > > Sadly this is going to be a bit more than 'resolve the warnings' task 
> > > > > now as Jun
> > > > > Li's patch set has now made it in before me which means I need to 
> > > > > rebase PDO
> > > > > Selection because of his changes. :(
> > > >
> > > > Someone was going to have to do that, sorry :(
> > >
> > > Just as an FYI, this patch will produce warnings until the associated
> > > power_supply interface patch (number 5 in the series previously sent) is
> > > included as that makes use of the new API. Not sure how I can get around 
> > > that
> > > so I guess we have to wait on Sebastian to give the nod for the rest of 
> > > the
> > > power_supply patches before this can make it through.
> > 
> > That's not good.  There has to be a way to prevent a build warning from
> > happening...
> 
> If we're ok with '__maybe_unused' then I can add that. Wasn't sure if 
> something
> like that would be acceptable for this scenario.

I don't remember what the warning was, or what the code was either,
sorry...
--
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]

hi,

On 2018-04-23 18:20, Oliver Neukum wrote:

Am Donnerstag, den 19.04.2018, 20:18 +0530 schrieb Tushar Nimkar:

On 2018-04-19 14:15, Oliver Neukum wrote:
> Am Mittwoch, den 18.04.2018, 12:44 +0530 schrieb Tushar Nimkar:
> > On 2018-04-17 12:03, Tushar Nimkar wrote:
>
> Hi,
>
> > 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)
>
> In general the spec is one thing and reality is another thing.
> You can depend really only on what recent versions of Windows do.

did not get you!


Devices often implement the spec only to the extent they need to
in order to work with Windows.


oh, so no backward old way of scanning(sequential)?


No. But for testing we don't need to. Can you confirm that
the problem is triggered by specific commands?


Observed with REPORT_LUN or READ_CAP16 or INQUIRY command.

Are you planning to test it with dwc3?


Regards
Oliver

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

[PATCH] usb: core: hcd: mark expected switch fall-through

[Gustavo A. R. Silva]

In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Addresses-Coverity-ID: 1468266 ("Missing break in switch")
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/usb/core/hcd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 66cd3f9..1c21955 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2819,6 +2819,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
case HCD_USB32:
rhdev->rx_lanes = 2;
rhdev->tx_lanes = 2;
+   /* fall through */
case HCD_USB31:
rhdev->speed = USB_SPEED_SUPER_PLUS;
break;
-- 
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: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

[Oliver Neukum]

Am Donnerstag, den 19.04.2018, 20:18 +0530 schrieb Tushar Nimkar:
> On 2018-04-19 14:15, Oliver Neukum wrote:
> > Am Mittwoch, den 18.04.2018, 12:44 +0530 schrieb Tushar Nimkar:
> > > On 2018-04-17 12:03, Tushar Nimkar wrote:
> > 
> > Hi,
> > 
> > > 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)
> > 
> > In general the spec is one thing and reality is another thing.
> > You can depend really only on what recent versions of Windows do.
> 
> did not get you!

Devices often implement the spec only to the extent they need to
in order to work with Windows.

> oh, so no backward old way of scanning(sequential)?

No. But for testing we don't need to. Can you confirm that
the problem is triggered by specific commands?

Regards
Oliver

--
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 v7 1/6] typec: tcpm: Add core support for sink side PPS

[Adam Thomson]

On 23 April 2018 12:28, Greg Kroah-Hartman wrote:

> On Mon, Apr 23, 2018 at 11:06:25AM +, Adam Thomson wrote:
> > On 23 April 2018 09:25, Greg Kroah-Hartman wrote:
> >
> > > On Mon, Apr 23, 2018 at 07:49:38AM +, Adam Thomson wrote:
> > > > On 22 April 2018 21:58, Adam Thomson wrote:
> > > >
> > > > > On 22 April 2018 15:05, Greg Kroah-Hartman wrote:
> > > > >
> > > > > > On Fri, Mar 23, 2018 at 10:12:20AM +, Adam Thomson wrote:
> > > > > > > This commit adds code to handle requesting of PPS APDOs. Switching
> > > > > > > between standard PDOs and APDOs, and re-requesting an APDO to
> > > > > > > modify operating voltage/current will be triggered by an
> > > > > > > external call into TCPM.
> > > > > > >
> > > > > > > Signed-off-by: Adam Thomson
> 
> > > > > > > Acked-by: Heikki Krogerus 
> > > > > > > Reviewed-by: Guenter Roeck 
> > > > > > > ---
> > > > > > >  drivers/usb/typec/tcpm.c | 517
> > > > > > ++-
> > > > > > >  include/linux/usb/pd.h   |   4 +-
> > > > > > >  include/linux/usb/tcpm.h |   1 +
> > > > > > >  3 files changed, 509 insertions(+), 13 deletions(-)
> > > > > >
> > > > > > This patch adds build warnings to the tree, so I can't take it, 
> > > > > > sorry.
> > > > > > Please fix up and resend.
> > > > >
> > > > > No problem. Sorry for that. Will take a look and resolve the warnings.
> > > >
> > > > Sadly this is going to be a bit more than 'resolve the warnings' task 
> > > > now as Jun
> > > > Li's patch set has now made it in before me which means I need to 
> > > > rebase PDO
> > > > Selection because of his changes. :(
> > >
> > > Someone was going to have to do that, sorry :(
> >
> > Just as an FYI, this patch will produce warnings until the associated
> > power_supply interface patch (number 5 in the series previously sent) is
> > included as that makes use of the new API. Not sure how I can get around 
> > that
> > so I guess we have to wait on Sebastian to give the nod for the rest of the
> > power_supply patches before this can make it through.
> 
> That's not good.  There has to be a way to prevent a build warning from
> happening...

If we're ok with '__maybe_unused' then I can add that. Wasn't sure if something
like that would be acceptable for this scenario.
--
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

NEC/Renesas PCI USB3 Cards

[Stefan Kalis]

OK.
I own a Renesas PCI-Card that offers 4 USB3-Ports and that worked well
with Linux-Kernels up to 4.8. Beginning with kernel 4.9 it was not
correctly initialized anymore and the problem still persists with
kernel 4.16.2 that I have recently tested.

After a failed start the PCI-situation looks like this:

lspci -vv:

08:00.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0
Host Controller (rev ff) (prog-if ff)
!!! Unknown header type 7f
Kernel modules: xhci_pci

While after a correct start with kernel 4.1.43 it looks like this:


08:00.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0
Host Controller (rev 03) (prog-if 30 [XHCI])
Subsystem: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR- http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 1/6] typec: tcpm: Add core support for sink side PPS

[Greg Kroah-Hartman]

On Mon, Apr 23, 2018 at 11:06:25AM +, Adam Thomson wrote:
> On 23 April 2018 09:25, Greg Kroah-Hartman wrote:
> 
> > On Mon, Apr 23, 2018 at 07:49:38AM +, Adam Thomson wrote:
> > > On 22 April 2018 21:58, Adam Thomson wrote:
> > >
> > > > On 22 April 2018 15:05, Greg Kroah-Hartman wrote:
> > > >
> > > > > On Fri, Mar 23, 2018 at 10:12:20AM +, Adam Thomson wrote:
> > > > > > This commit adds code to handle requesting of PPS APDOs. Switching
> > > > > > between standard PDOs and APDOs, and re-requesting an APDO to
> > > > > > modify operating voltage/current will be triggered by an
> > > > > > external call into TCPM.
> > > > > >
> > > > > > Signed-off-by: Adam Thomson 
> > > > > > Acked-by: Heikki Krogerus 
> > > > > > Reviewed-by: Guenter Roeck 
> > > > > > ---
> > > > > >  drivers/usb/typec/tcpm.c | 517
> > > > > ++-
> > > > > >  include/linux/usb/pd.h   |   4 +-
> > > > > >  include/linux/usb/tcpm.h |   1 +
> > > > > >  3 files changed, 509 insertions(+), 13 deletions(-)
> > > > >
> > > > > This patch adds build warnings to the tree, so I can't take it, sorry.
> > > > > Please fix up and resend.
> > > >
> > > > No problem. Sorry for that. Will take a look and resolve the warnings.
> > >
> > > Sadly this is going to be a bit more than 'resolve the warnings' task now 
> > > as Jun
> > > Li's patch set has now made it in before me which means I need to rebase 
> > > PDO
> > > Selection because of his changes. :(
> > 
> > Someone was going to have to do that, sorry :(
> 
> Just as an FYI, this patch will produce warnings until the associated
> power_supply interface patch (number 5 in the series previously sent) is
> included as that makes use of the new API. Not sure how I can get around that
> so I guess we have to wait on Sebastian to give the nod for the rest of the
> power_supply patches before this can make it through.

That's not good.  There has to be a way to prevent a build warning from
happening...

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 v7 1/6] typec: tcpm: Add core support for sink side PPS

[Adam Thomson]

On 23 April 2018 09:25, Greg Kroah-Hartman wrote:

> On Mon, Apr 23, 2018 at 07:49:38AM +, Adam Thomson wrote:
> > On 22 April 2018 21:58, Adam Thomson wrote:
> >
> > > On 22 April 2018 15:05, Greg Kroah-Hartman wrote:
> > >
> > > > On Fri, Mar 23, 2018 at 10:12:20AM +, Adam Thomson wrote:
> > > > > This commit adds code to handle requesting of PPS APDOs. Switching
> > > > > between standard PDOs and APDOs, and re-requesting an APDO to
> > > > > modify operating voltage/current will be triggered by an
> > > > > external call into TCPM.
> > > > >
> > > > > Signed-off-by: Adam Thomson 
> > > > > Acked-by: Heikki Krogerus 
> > > > > Reviewed-by: Guenter Roeck 
> > > > > ---
> > > > >  drivers/usb/typec/tcpm.c | 517
> > > > ++-
> > > > >  include/linux/usb/pd.h   |   4 +-
> > > > >  include/linux/usb/tcpm.h |   1 +
> > > > >  3 files changed, 509 insertions(+), 13 deletions(-)
> > > >
> > > > This patch adds build warnings to the tree, so I can't take it, sorry.
> > > > Please fix up and resend.
> > >
> > > No problem. Sorry for that. Will take a look and resolve the warnings.
> >
> > Sadly this is going to be a bit more than 'resolve the warnings' task now 
> > as Jun
> > Li's patch set has now made it in before me which means I need to rebase PDO
> > Selection because of his changes. :(
> 
> Someone was going to have to do that, sorry :(

Just as an FYI, this patch will produce warnings until the associated
power_supply interface patch (number 5 in the series previously sent) is
included as that makes use of the new API. Not sure how I can get around that
so I guess we have to wait on Sebastian to give the nod for the rest of the
power_supply patches before this can make it through.

Anyway, will rebase and resend, and will further highlight this reliance in the
cover letter.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problem with NEC/Renasas Cards PCI USB3

[Greg KH]

On Mon, Apr 23, 2018 at 12:08:21PM +0200, Stefan Kalis wrote:
> Hello,
> 
> I would like to inform you about a bug that Gentoo bug-wranglers can't handle:
> 
> bugs(dot)gentoo(dot)org(slash)612704

That's really hard, if not impossible, to follow.

Please just post the needed information here, don't make us have to dig
something out of a random web site, yet alone have to figure out how to
decode it just to type it in...

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

Problem with NEC/Renasas Cards PCI USB3

[Stefan Kalis]

Hello,

I would like to inform you about a bug that Gentoo bug-wranglers can't handle:

bugs(dot)gentoo(dot)org(slash)612704

Sincerely,

Stefan Kalis

PS
It's possible that I could be of service in solving the issue because
I got the respective hardware.
--
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]

hi,

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.

> Also look at all of the recent dwc3 patches that were just sent to Linus
> for 4.17-rc1 to verify if that solves the issue.
>
I do not have idea how I can get those patches. Could you please tell 
me?


Look at the git tree listed in the MAINTAINERS file.


Is there any mailing list/link for this ?


Yes, this one (linux-usb@vger).  Also, all of the patches are in
the linux-next tree.


Greg/Oliver, Switched to 4.17.0-rc1.. issues is observed too. :(

[ 5518.577155] usb 2-1: new SuperSpeed USB device number 5 using 
xhci-hcd

[ 5518.605780] scsi host1: uas
[ 5518.606435] scsi 1:0:0:0: Direct-Access Samsung  Portable SSD T3  
0PQ: 0 ANSI: 6
[ 5549.037127] sd 1:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1 
inflight: CMD IN

[ 5549.037160] sd 1:0:0:0: tag#0 CDB: opcode=0x12 12 01 b0 00 40 00
[ 5549.057118] scsi host1: uas_eh_device_reset_handler start
[ 5549.057159] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event for 
unknown stream ring slot 1 ep 6
[ 5549.061491] xhci-hcd xhci-hcd.0.auto: @7f044f20  
 1b00 01078000
[ 5549.197272] usb 2-1: reset SuperSpeed USB device number 5 using 
xhci-hcd

[ 5549.219833] scsi host1: uas_eh_device_reset_handler success
[ 5549.225472] sd 1:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 
GB/466 GiB)

[ 5549.225626] sd 1:0:0:0: [sdb] Write Protect is off
[ 5549.232118] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: 
enabled, doesn't support DPO or FUA
[ 5549.236739] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event for 
unknown stream ring slot 1 ep 2
[ 5549.24] xhci-hcd xhci-hcd.0.auto: @7f044280  
 1b00 01038001

[ 5549.257868]  sdb: sdb1
[ 5549.263899] sd 1:0:0:0: [sdb] Attached SCSI disk




thanks,

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


--
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: [PATCH] usb:serial:optrion: fix dwm-158 3g modem interface

[Johan Hovold]

On Mon, Apr 23, 2018 at 11:58:18AM +0300, Sergei Shtylyov wrote:
> Hello!
> 
> s/optrion/option/ in the subject. And please add spaces after each colon.

Yeah, I fixed that up myself before applying this time.

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] usb:serial:optrion: fix dwm-158 3g modem interface

[Sergei Shtylyov]

Hello!

   s/optrion/option/ in the subject. And please add spaces after each colon.

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

Re: [PATCH] usb: dwc2: gadget: Fix memory leak in dwc2_gadget_init()

[Stefan Wahren]

Am 23.04.2018 um 09:05 schrieb Grigor Tovmasyan:

Hi Stefan,

On 4/18/2018 1:11 AM, Stefan Wahren wrote:

Hi Grigor,


Grigor Tovmasyan  hat am 16. April 2018 um 12:16 
geschrieben:


In dwc2_gadget_init() we allocate EP0 request via
dwc2_hsotg_ep_alloc_request(). After that there are
usb_add_gadget_udc() call and if it failed, then
ctrl_req will not be freed and will cause memory leak.

Reordered function calls in gadget_init: moved up usb_add_gadget_udc()
before dwc2_hsotg_ep_alloc_request().

i'm not sure, but doesn't this change introduce a race condition before EP0 
request has been allocated?

As far as I know the firt request to EP0 coming when the function driver
first bind() to the device, which happens after dwc2 probe.
So, in my opinion this patch is safe.

okay fine


Grigor

Stefan


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

Re: [PATCH] usb:serial:optrion: fix dwm-158 3g modem interface

[Johan Hovold]

On Mon, Apr 23, 2018 at 02:14:01PM +0700, Lars Melin wrote:
> On 4/23/2018 14:03, Giuseppe Lippolis wrote:
> > The dwm-158 interface 4 and 5 doesn't answer to the AT commands
> > and doesn't appears a option interface.
> > Tested on openwrt distribution (kernel 4.14 using the old blacklist
> > definitions).
> > 
> > Signed-off-by: Giuseppe Lippolis 
> > ---
> >   drivers/usb/serial/option.c | 3 ++-
> >   1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
> > index c3f252283ab9..f0c3612467a3 100644
> > --- a/drivers/usb/serial/option.c
> > +++ b/drivers/usb/serial/option.c
> > @@ -1911,7 +1911,8 @@ static const struct usb_device_id option_ids[] = {
> > { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d01, 0xff) },   
> > /* D-Link DWM-156 (variant) */
> > { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d02, 0xff) },
> > { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d03, 0xff) },
> > -   { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d04, 0xff) },   
> > /* D-Link DWM-158 */
> > +   { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d04, 0xff), 
> > /* D-Link DWM-158 */
> > +.driver_info = RSVD(4) | RSVD(5) },
> > { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d0e, 0xff) },   
> > /* D-Link DWM-157 C1 */
> > { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7e19, 0xff), 
> > /* D-Link DWM-221 B1 */
> >   .driver_info = RSVD(4) },
> 
> Blacklisting interface 4 and 5 is correct because:
> 
> MI_00 D-Link Mobile Broadband Device  (cdc_ether)
> MI_02 D-Link HSPA+DataCard Diagnostics Interface (also ppp modem)
> MI_03 D-Link HSPA+DataCard NMEA Device
> MI_04 D-Link HSPA+DataCard Speech Port
> MI_05 D-Link HSPA+DataCard Debug Port
> MI_06 USB Mass Storage Device

Thanks to both of you. I added Lars's comment to the commit message
before applying.

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 v7 1/6] typec: tcpm: Add core support for sink side PPS

[Greg Kroah-Hartman]

On Mon, Apr 23, 2018 at 07:49:38AM +, Adam Thomson wrote:
> On 22 April 2018 21:58, Adam Thomson wrote:
> 
> > On 22 April 2018 15:05, Greg Kroah-Hartman wrote:
> > 
> > > On Fri, Mar 23, 2018 at 10:12:20AM +, Adam Thomson wrote:
> > > > This commit adds code to handle requesting of PPS APDOs. Switching
> > > > between standard PDOs and APDOs, and re-requesting an APDO to
> > > > modify operating voltage/current will be triggered by an
> > > > external call into TCPM.
> > > >
> > > > Signed-off-by: Adam Thomson 
> > > > Acked-by: Heikki Krogerus 
> > > > Reviewed-by: Guenter Roeck 
> > > > ---
> > > >  drivers/usb/typec/tcpm.c | 517
> > > ++-
> > > >  include/linux/usb/pd.h   |   4 +-
> > > >  include/linux/usb/tcpm.h |   1 +
> > > >  3 files changed, 509 insertions(+), 13 deletions(-)
> > >
> > > This patch adds build warnings to the tree, so I can't take it, sorry.
> > > Please fix up and resend.
> > 
> > No problem. Sorry for that. Will take a look and resolve the warnings.
> 
> Sadly this is going to be a bit more than 'resolve the warnings' task now as 
> Jun
> Li's patch set has now made it in before me which means I need to rebase PDO
> Selection because of his changes. :(

Someone was going to have to do that, sorry :(
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Heikki Krogerus]

On Fri, Apr 20, 2018 at 10:26:08AM -0700, Guenter Roeck wrote:
> On Wed, Apr 18, 2018 at 03:34:09PM +0300, Heikki Krogerus wrote:
> > 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;
> > +
> 
> Sanity check ?
>   if (data[0] != len)
>   return -Esomething;

No. Then we would not even need the len parameter. The idea is to
allow reading a number of bytes specified by caller, regardless of the
maximum size of the block.


Thanks,

-- 
heikki
--
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 v7 1/6] typec: tcpm: Add core support for sink side PPS

[Adam Thomson]

On 22 April 2018 21:58, Adam Thomson wrote:

> On 22 April 2018 15:05, Greg Kroah-Hartman wrote:
> 
> > On Fri, Mar 23, 2018 at 10:12:20AM +, Adam Thomson wrote:
> > > This commit adds code to handle requesting of PPS APDOs. Switching
> > > between standard PDOs and APDOs, and re-requesting an APDO to
> > > modify operating voltage/current will be triggered by an
> > > external call into TCPM.
> > >
> > > Signed-off-by: Adam Thomson 
> > > Acked-by: Heikki Krogerus 
> > > Reviewed-by: Guenter Roeck 
> > > ---
> > >  drivers/usb/typec/tcpm.c | 517
> > ++-
> > >  include/linux/usb/pd.h   |   4 +-
> > >  include/linux/usb/tcpm.h |   1 +
> > >  3 files changed, 509 insertions(+), 13 deletions(-)
> >
> > This patch adds build warnings to the tree, so I can't take it, sorry.
> > Please fix up and resend.
> 
> No problem. Sorry for that. Will take a look and resolve the warnings.

Sadly this is going to be a bit more than 'resolve the warnings' task now as Jun
Li's patch set has now made it in before me which means I need to rebase PDO
Selection because of his changes. :(
--
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 v6 6/6] usb: core: phy: add the SPDX-License-Identifier and include guard

[Greg KH]

On Sun, Apr 22, 2018 at 09:41:56PM +0200, Martin Blumenstingl wrote:
> Hi Greg,
> 
> On Sun, Apr 22, 2018 at 3:01 PM, Greg KH  wrote:
> > On Wed, Apr 18, 2018 at 09:39:51PM +0200, Martin Blumenstingl wrote:
> >> 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+ */
> >
> > Do you _really_ mean GPLv2 or anything later?
> drivers/usb/core/hcd.c uses the same license identifier
> that code is much more "valuable" than my few lines which manage a
> list of PHYs - so I'm fine with "GPLv2 or anything later"
> 
> > I have to ask...
> if you see any problems with this (for example that phy.h couldn't be
> used from some special module with another license, ...) then please
> let me know

Nope, that's fine, thanks for the quick response, I'll go apply this
now.

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 resend] usb: chipidea: Don't select EXTCON

[Jisheng Zhang]

On Fri, 20 Apr 2018 09:35:54 + Peter Chen wrote:

>  
> > >
> > > Sorry to reply late, are you really care 2KB code side? Since many
> > > users use EXTCON to handle vbus and id, it is hard just delete it. I
> > > could accept patch for your specific platforms, like:
> > >
> > > + select EXTCON if !ARCH_  
> > 
> > The patch doesn't remove extcon support from chipidea driver.
> > I just want to not select EXTCON unconditionally, but let the users choose. 
> > If the
> > users need extcon, they could enable EXTCON themselves
> > 
> > I just searched all the dts in arch/arm/boot/dts and arch/arm64/boot/dts 
> > only the four
> > dts give extcon phandle to chipidea host, other users don't make use of it:
> > 
> > arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> > 
> > arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
> > 
> > arch/arm/boot/dts/qcom-msm8974-fairphone-fp2.dts
> > 
> > arch/arm/boot/dts/qcom-msm8974-sony-xperia-castor.dts
> >   
> 
> I see, but I do not want to break msm platforms. You may try to create Glue 
> driver Kconfig
> entry for chipidea like dwc3, and let msm depends on EXTCON.

Got your points. Since multi_v7_defconfig has selected EXTCON, and
EXTCON_USB_GPIO(which depends on EXTCON) is enabled in arm64 defconfig, so
what about:

enable EXTCON explicitly in arm64 defconfig?
then add this patch?

Is it acceptable?

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

Re: [PATCH] usb:serial:optrion: fix dwm-158 3g modem interface

[Lars Melin]

On 4/23/2018 14:03, Giuseppe Lippolis wrote:

The dwm-158 interface 4 and 5 doesn't answer to the AT commands
and doesn't appears a option interface.
Tested on openwrt distribution (kernel 4.14 using the old blacklist
definitions).

Signed-off-by: Giuseppe Lippolis 
---
  drivers/usb/serial/option.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index c3f252283ab9..f0c3612467a3 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -1911,7 +1911,8 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d01, 0xff) },   
/* D-Link DWM-156 (variant) */
{ USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d02, 0xff) },
{ USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d03, 0xff) },
-   { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d04, 0xff) },   
/* D-Link DWM-158 */
+   { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d04, 0xff), 
/* D-Link DWM-158 */
+.driver_info = RSVD(4) | RSVD(5) },
{ USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d0e, 0xff) },   
/* D-Link DWM-157 C1 */
{ USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7e19, 0xff), 
/* D-Link DWM-221 B1 */
  .driver_info = RSVD(4) },


Blacklisting interface 4 and 5 is correct because:

MI_00 D-Link Mobile Broadband Device  (cdc_ether)
MI_02 D-Link HSPA+DataCard Diagnostics Interface (also ppp modem)
MI_03 D-Link HSPA+DataCard NMEA Device
MI_04 D-Link HSPA+DataCard Speech Port
MI_05 D-Link HSPA+DataCard Debug Port
MI_06 USB Mass Storage Device


rgds
/Lars
--
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: dwc2: gadget: Fix memory leak in dwc2_gadget_init()

[Grigor Tovmasyan]

Hi Stefan,

On 4/18/2018 1:11 AM, Stefan Wahren wrote:
> Hi Grigor,
> 
>> Grigor Tovmasyan  hat am 16. April 2018 um 
>> 12:16 geschrieben:
>>
>>
>> In dwc2_gadget_init() we allocate EP0 request via
>> dwc2_hsotg_ep_alloc_request(). After that there are
>> usb_add_gadget_udc() call and if it failed, then
>> ctrl_req will not be freed and will cause memory leak.
>>
>> Reordered function calls in gadget_init: moved up usb_add_gadget_udc()
>> before dwc2_hsotg_ep_alloc_request().
> 
> i'm not sure, but doesn't this change introduce a race condition before EP0 
> request has been allocated?
As far as I know the firt request to EP0 coming when the function driver 
first bind() to the device, which happens after dwc2 probe.
So, in my opinion this patch is safe.

Grigor
> 
> Stefan
> 

--
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:serial:optrion: fix dwm-158 3g modem interface

[Giuseppe Lippolis]

The dwm-158 interface 4 and 5 doesn't answer to the AT commands
and doesn't appears a option interface.
Tested on openwrt distribution (kernel 4.14 using the old blacklist
definitions).

Signed-off-by: Giuseppe Lippolis 
---
 drivers/usb/serial/option.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index c3f252283ab9..f0c3612467a3 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -1911,7 +1911,8 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d01, 0xff) },   
/* D-Link DWM-156 (variant) */
{ USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d02, 0xff) },
{ USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d03, 0xff) },
-   { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d04, 0xff) },   
/* D-Link DWM-158 */
+   { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d04, 0xff), 
/* D-Link DWM-158 */
+.driver_info = RSVD(4) | RSVD(5) },
{ USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d0e, 0xff) },   
/* D-Link DWM-157 C1 */
{ USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7e19, 0xff), 
/* D-Link DWM-221 B1 */
  .driver_info = RSVD(4) },
-- 
2.14.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:serial:optrion: fix dwm-158 3g modem interface

[Giuseppe Lippolis]

The dwm-158 interface 4 and 5 doesn't answer to the AT commands
and doesn't appears a option interface.
Tested on openwrt distribution (kernel 4.14 using the old blacklist
definitions).

Signed-off-by: Giuseppe Lippolis 
---
 drivers/usb/serial/option.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index c3f252283ab9..f0c3612467a3 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -1911,7 +1911,8 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d01, 0xff) },   
/* D-Link DWM-156 (variant) */
{ USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d02, 0xff) },
{ USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d03, 0xff) },
-   { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d04, 0xff) },   
/* D-Link DWM-158 */
+   { USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d04, 0xff), 
/* D-Link DWM-158 */
+.driver_info = RSVD(4) | RSVD(5) },
{ USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7d0e, 0xff) },   
/* D-Link DWM-157 C1 */
{ USB_DEVICE_INTERFACE_CLASS(0x2001, 0x7e19, 0xff), 
/* D-Link DWM-221 B1 */
  .driver_info = RSVD(4) },
-- 
2.14.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