[PATCH 4/7] usb: musb: musb_cppi41: Fix cppi41_set_dma_mode() for DA8xx

[Bin Liu]

From: Alexandre Bailon 

The way to configure the DMA mode on DA8xx is different from DSPS.
Add a new function to configure DMA mode on DA8xx and use a callback
to call the right function based on the platform.

Cc: sta...@vger.kernel.org  # v4.12+
Signed-off-by: Alexandre Bailon 
Tested-by: Sekhar Nori 
Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_cppi41.c | 40 +---
 1 file changed, 37 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
index d66416a27146..b2b1306c01cf 100644
--- a/drivers/usb/musb/musb_cppi41.c
+++ b/drivers/usb/musb/musb_cppi41.c
@@ -26,6 +26,7 @@
 
 #define MUSB_DMA_NUM_CHANNELS 15
 
+#define DA8XX_USB_MODE 0x10
 #define DA8XX_USB_AUTOREQ  0x14
 #define DA8XX_USB_TEARDOWN 0x1c
 
@@ -41,6 +42,9 @@ struct cppi41_dma_controller {
 
u32 tdown_reg;
u32 autoreq_reg;
+
+   void (*set_dma_mode)(struct cppi41_dma_channel *cppi41_channel,
+unsigned int mode);
 };
 
 static void save_rx_toggle(struct cppi41_dma_channel *cppi41_channel)
@@ -355,6 +359,32 @@ static void cppi41_set_dma_mode(struct cppi41_dma_channel 
*cppi41_channel,
}
 }
 
+static void da8xx_set_dma_mode(struct cppi41_dma_channel *cppi41_channel,
+   unsigned int mode)
+{
+   struct cppi41_dma_controller *controller = cppi41_channel->controller;
+   struct musb *musb = controller->controller.musb;
+   unsigned int shift;
+   u32 port;
+   u32 new_mode;
+   u32 old_mode;
+
+   old_mode = controller->tx_mode;
+   port = cppi41_channel->port_num;
+
+   shift = (port - 1) * 4;
+   if (!cppi41_channel->is_tx)
+   shift += 16;
+   new_mode = old_mode & ~(3 << shift);
+   new_mode |= mode << shift;
+
+   if (new_mode == old_mode)
+   return;
+   controller->tx_mode = new_mode;
+   musb_writel(musb->ctrl_base, DA8XX_USB_MODE, new_mode);
+}
+
+
 static void cppi41_set_autoreq_mode(struct cppi41_dma_channel *cppi41_channel,
unsigned mode)
 {
@@ -379,6 +409,7 @@ static bool cppi41_configure_channel(struct dma_channel 
*channel,
dma_addr_t dma_addr, u32 len)
 {
struct cppi41_dma_channel *cppi41_channel = channel->private_data;
+   struct cppi41_dma_controller *controller = cppi41_channel->controller;
struct dma_chan *dc = cppi41_channel->dc;
struct dma_async_tx_descriptor *dma_desc;
enum dma_transfer_direction direction;
@@ -404,7 +435,7 @@ static bool cppi41_configure_channel(struct dma_channel 
*channel,
musb_writel(musb->ctrl_base,
RNDIS_REG(cppi41_channel->port_num), len);
/* gen rndis */
-   cppi41_set_dma_mode(cppi41_channel,
+   controller->set_dma_mode(cppi41_channel,
EP_MODE_DMA_GEN_RNDIS);
 
/* auto req */
@@ -413,14 +444,15 @@ static bool cppi41_configure_channel(struct dma_channel 
*channel,
} else {
musb_writel(musb->ctrl_base,
RNDIS_REG(cppi41_channel->port_num), 0);
-   cppi41_set_dma_mode(cppi41_channel,
+   controller->set_dma_mode(cppi41_channel,
EP_MODE_DMA_TRANSPARENT);
cppi41_set_autoreq_mode(cppi41_channel,
EP_MODE_AUTOREQ_NONE);
}
} else {
/* fallback mode */
-   cppi41_set_dma_mode(cppi41_channel, EP_MODE_DMA_TRANSPARENT);
+   controller->set_dma_mode(cppi41_channel,
+   EP_MODE_DMA_TRANSPARENT);
cppi41_set_autoreq_mode(cppi41_channel, EP_MODE_AUTOREQ_NONE);
len = min_t(u32, packet_sz, len);
}
@@ -737,9 +769,11 @@ struct dma_controller *
if (musb->io.quirks & MUSB_DA8XX) {
controller->tdown_reg = DA8XX_USB_TEARDOWN;
controller->autoreq_reg = DA8XX_USB_AUTOREQ;
+   controller->set_dma_mode = da8xx_set_dma_mode;
} else {
controller->tdown_reg = USB_TDOWN;
controller->autoreq_reg = USB_CTRL_AUTOREQ;
+   controller->set_dma_mode = cppi41_set_dma_mode;
}
 
ret = cppi41_dma_controller_start(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 3/7] usb: musb: musb_cppi41: Fix the address of teardown and autoreq registers

[Bin Liu]

From: Alexandre Bailon 

The DA8xx and DSPS platforms don't use the same address for few registers.
On Da8xx, this is causing some issues (e.g. teardown that doesn't work).
Configure the address of the register during the init and use them instead
of constants.

Cc: sta...@vger.kernel.org  # v4.12+
Reported-by: nsek...@ti.com
Signed-off-by: Alexandre Bailon 
Tested-by: Sekhar Nori 
Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_cppi41.c | 23 +++
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
index ba255280a624..d66416a27146 100644
--- a/drivers/usb/musb/musb_cppi41.c
+++ b/drivers/usb/musb/musb_cppi41.c
@@ -26,6 +26,9 @@
 
 #define MUSB_DMA_NUM_CHANNELS 15
 
+#define DA8XX_USB_AUTOREQ  0x14
+#define DA8XX_USB_TEARDOWN 0x1c
+
 struct cppi41_dma_controller {
struct dma_controller controller;
struct cppi41_dma_channel rx_channel[MUSB_DMA_NUM_CHANNELS];
@@ -35,6 +38,9 @@ struct cppi41_dma_controller {
u32 rx_mode;
u32 tx_mode;
u32 auto_req;
+
+   u32 tdown_reg;
+   u32 autoreq_reg;
 };
 
 static void save_rx_toggle(struct cppi41_dma_channel *cppi41_channel)
@@ -364,8 +370,8 @@ static void cppi41_set_autoreq_mode(struct 
cppi41_dma_channel *cppi41_channel,
if (new_mode == old_mode)
return;
controller->auto_req = new_mode;
-   musb_writel(controller->controller.musb->ctrl_base, USB_CTRL_AUTOREQ,
-   new_mode);
+   musb_writel(controller->controller.musb->ctrl_base,
+   controller->autoreq_reg, new_mode);
 }
 
 static bool cppi41_configure_channel(struct dma_channel *channel,
@@ -581,12 +587,13 @@ static int cppi41_dma_channel_abort(struct dma_channel 
*channel)
 
do {
if (is_tx)
-   musb_writel(musb->ctrl_base, USB_TDOWN, tdbit);
+   musb_writel(musb->ctrl_base, controller->tdown_reg,
+   tdbit);
ret = dmaengine_terminate_all(cppi41_channel->dc);
} while (ret == -EAGAIN);
 
if (is_tx) {
-   musb_writel(musb->ctrl_base, USB_TDOWN, tdbit);
+   musb_writel(musb->ctrl_base, controller->tdown_reg, tdbit);
 
csr = musb_readw(epio, MUSB_TXCSR);
if (csr & MUSB_TXCSR_TXPKTRDY) {
@@ -727,6 +734,14 @@ struct dma_controller *
controller->controller.is_compatible = cppi41_is_compatible;
controller->controller.musb = musb;
 
+   if (musb->io.quirks & MUSB_DA8XX) {
+   controller->tdown_reg = DA8XX_USB_TEARDOWN;
+   controller->autoreq_reg = DA8XX_USB_AUTOREQ;
+   } else {
+   controller->tdown_reg = USB_TDOWN;
+   controller->autoreq_reg = USB_CTRL_AUTOREQ;
+   }
+
ret = cppi41_dma_controller_start(controller);
if (ret)
goto plat_get_fail;
-- 
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 7/7] usb: musb: sunxi: Explicitly release USB PHY on exit

[Bin Liu]

From: Jonathan Liu 

This fixes a kernel oops when unloading the driver due to usb_put_phy
being called after usb_phy_generic_unregister when the device is
detached. Calling usb_phy_generic_unregister causes x->dev->driver to
be NULL in usb_put_phy and results in a NULL pointer dereference.

Cc: sta...@vger.kernel.org # v4.3+
Signed-off-by: Jonathan Liu 
Signed-off-by: Bin Liu 
---
 drivers/usb/musb/sunxi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
index c9a09b5bb6e5..dc353e24d53c 100644
--- a/drivers/usb/musb/sunxi.c
+++ b/drivers/usb/musb/sunxi.c
@@ -297,6 +297,8 @@ static int sunxi_musb_exit(struct musb *musb)
if (test_bit(SUNXI_MUSB_FL_HAS_SRAM, >flags))
sunxi_sram_release(musb->controller->parent);
 
+   devm_usb_put_phy(glue->dev, glue->xceiv);
+
return 0;
 }
 
-- 
1.9.1

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

[PATCH 5/7] usb: musb: musb_cppi41: Configure the number of channels for DA8xx

[Bin Liu]

From: Alexandre Bailon 

Currently, the number of channels is set to 15 but in the case of DA8xx,
the number of channels is 4.
Update the driver to configure the number of channels at runtime.

Cc: sta...@vger.kernel.org  # v4.12+
Signed-off-by: Alexandre Bailon 
Tested-by: Sekhar Nori 
Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_cppi41.c | 31 ++-
 1 file changed, 26 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
index b2b1306c01cf..1ec0a4947b6b 100644
--- a/drivers/usb/musb/musb_cppi41.c
+++ b/drivers/usb/musb/musb_cppi41.c
@@ -30,10 +30,12 @@
 #define DA8XX_USB_AUTOREQ  0x14
 #define DA8XX_USB_TEARDOWN 0x1c
 
+#define DA8XX_DMA_NUM_CHANNELS 4
+
 struct cppi41_dma_controller {
struct dma_controller controller;
-   struct cppi41_dma_channel rx_channel[MUSB_DMA_NUM_CHANNELS];
-   struct cppi41_dma_channel tx_channel[MUSB_DMA_NUM_CHANNELS];
+   struct cppi41_dma_channel *rx_channel;
+   struct cppi41_dma_channel *tx_channel;
struct hrtimer early_tx;
struct list_head early_tx_list;
u32 rx_mode;
@@ -45,6 +47,7 @@ struct cppi41_dma_controller {
 
void (*set_dma_mode)(struct cppi41_dma_channel *cppi41_channel,
 unsigned int mode);
+   u8 num_channels;
 };
 
 static void save_rx_toggle(struct cppi41_dma_channel *cppi41_channel)
@@ -483,7 +486,7 @@ static struct dma_channel 
*cppi41_dma_channel_allocate(struct dma_controller *c,
struct cppi41_dma_channel *cppi41_channel = NULL;
u8 ch_num = hw_ep->epnum - 1;
 
-   if (ch_num >= MUSB_DMA_NUM_CHANNELS)
+   if (ch_num >= controller->num_channels)
return NULL;
 
if (is_tx)
@@ -643,7 +646,7 @@ static void cppi41_release_all_dma_chans(struct 
cppi41_dma_controller *ctrl)
struct dma_chan *dc;
int i;
 
-   for (i = 0; i < MUSB_DMA_NUM_CHANNELS; i++) {
+   for (i = 0; i < ctrl->num_channels; i++) {
dc = ctrl->tx_channel[i].dc;
if (dc)
dma_release_channel(dc);
@@ -695,7 +698,7 @@ static int cppi41_dma_controller_start(struct 
cppi41_dma_controller *controller)
goto err;
 
ret = -EINVAL;
-   if (port > MUSB_DMA_NUM_CHANNELS || !port)
+   if (port > controller->num_channels || !port)
goto err;
if (is_tx)
cppi41_channel = >tx_channel[port - 1];
@@ -736,6 +739,8 @@ void cppi41_dma_controller_destroy(struct dma_controller *c)
 
hrtimer_cancel(>early_tx);
cppi41_dma_controller_stop(controller);
+   kfree(controller->rx_channel);
+   kfree(controller->tx_channel);
kfree(controller);
 }
 EXPORT_SYMBOL_GPL(cppi41_dma_controller_destroy);
@@ -744,6 +749,7 @@ struct dma_controller *
 cppi41_dma_controller_create(struct musb *musb, void __iomem *base)
 {
struct cppi41_dma_controller *controller;
+   int channel_size;
int ret = 0;
 
if (!musb->controller->parent->of_node) {
@@ -770,18 +776,33 @@ struct dma_controller *
controller->tdown_reg = DA8XX_USB_TEARDOWN;
controller->autoreq_reg = DA8XX_USB_AUTOREQ;
controller->set_dma_mode = da8xx_set_dma_mode;
+   controller->num_channels = DA8XX_DMA_NUM_CHANNELS;
} else {
controller->tdown_reg = USB_TDOWN;
controller->autoreq_reg = USB_CTRL_AUTOREQ;
controller->set_dma_mode = cppi41_set_dma_mode;
+   controller->num_channels = MUSB_DMA_NUM_CHANNELS;
}
 
+   channel_size = controller->num_channels *
+   sizeof(struct cppi41_dma_channel);
+   controller->rx_channel = kzalloc(channel_size, GFP_KERNEL);
+   if (!controller->rx_channel)
+   goto rx_channel_alloc_fail;
+   controller->tx_channel = kzalloc(channel_size, GFP_KERNEL);
+   if (!controller->tx_channel)
+   goto tx_channel_alloc_fail;
+
ret = cppi41_dma_controller_start(controller);
if (ret)
goto plat_get_fail;
return >controller;
 
 plat_get_fail:
+   kfree(controller->tx_channel);
+tx_channel_alloc_fail:
+   kfree(controller->rx_channel);
+rx_channel_alloc_fail:
kfree(controller);
 kzalloc_fail:
if (ret == -EPROBE_DEFER)
-- 
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 6/7] usb: musb: Check for host-mode using is_host_active() on reset interrupt

[Bin Liu]

From: Jonathan Liu 

The sunxi musb has a bug where sometimes it will generate a babble
error on device disconnect instead of a disconnect IRQ. When this
happens the musb controller switches from host mode to device mode
(it clears MUSB_DEVCTL_HM/MUSB_DEVCTL_SESSION and sets
MUSB_DEVCTL_BDEVICE) and gets stuck in this state.

The babble error is misdetected as a bus reset because MUSB_DEVCTL_HM
was cleared.

To fix this, use is_host_active() rather than (devctl & MUSB_DEVCTL_HM)
to detect babble error so that sunxi musb babble recovery can handle it
by restoring the mode. This information is provided by the driver logic
and does not rely on register contents.

Cc: sta...@vger.kernel.org # v4.1+
Signed-off-by: Jonathan Liu 
Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_core.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 1ced3af75b05..ff5a1a8989d5 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -906,7 +906,7 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8 
int_usb,
 */
if (int_usb & MUSB_INTR_RESET) {
handled = IRQ_HANDLED;
-   if (devctl & MUSB_DEVCTL_HM) {
+   if (is_host_active(musb)) {
/*
 * When BABBLE happens what we can depends on which
 * platform MUSB is running, because some platforms
@@ -916,9 +916,7 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8 
int_usb,
 * drop the session.
 */
dev_err(musb->controller, "Babble\n");
-
-   if (is_host_active(musb))
-   musb_recover_from_babble(musb);
+   musb_recover_from_babble(musb);
} else {
musb_dbg(musb, "BUS RESET as %s",
usb_otg_state_string(musb->xceiv->otg->state));
-- 
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/7] USB: musb: fix session-bit runtime-PM quirk

[Bin Liu]

From: Johan Hovold 

The current session-bit quirk implementation does not prevent the retry
counter from underflowing, something which could break runtime PM and
keep the device active for a very long time (about 2^32 seconds) after a
disconnect.

This notably breaks the B-device timeout case, but could potentially
cause problems also when the controller is operating as an A-device.

Fixes: 2bff3916fda9 ("usb: musb: Fix PM for hub disconnect")
Cc: stable  # 4.9
Cc: Tony Lindgren 
Signed-off-by: Johan Hovold 
Tested-by: Tony Lindgren 
Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_core.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 029692053dd3..07b8c7152e3d 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1861,22 +1861,22 @@ static void musb_pm_runtime_check_session(struct musb 
*musb)
MUSB_DEVCTL_HR;
switch (devctl & ~s) {
case MUSB_QUIRK_B_INVALID_VBUS_91:
-   if (musb->quirk_retries--) {
+   if (musb->quirk_retries) {
musb_dbg(musb,
 "Poll devctl on invalid vbus, assume no 
session");
schedule_delayed_work(>irq_work,
  msecs_to_jiffies(1000));
-
+   musb->quirk_retries--;
return;
}
/* fall through */
case MUSB_QUIRK_A_DISCONNECT_19:
-   if (musb->quirk_retries--) {
+   if (musb->quirk_retries) {
musb_dbg(musb,
 "Poll devctl on possible host mode 
disconnect");
schedule_delayed_work(>irq_work,
  msecs_to_jiffies(1000));
-
+   musb->quirk_retries--;
return;
}
if (!musb->session)
-- 
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/7] USB: musb: fix late external abort on suspend

[Bin Liu]

From: Johan Hovold 

The musb delayed irq work was never flushed on suspend, something which
since 4.9 can lead to an external abort if the work is scheduled after
the grandparent's clock has been disabled:

PM: Suspending system (mem)
PM: suspend of devices complete after 125.224 msecs
PM: suspend devices took 0.132 seconds
PM: late suspend of devices complete after 7.423 msecs
PM: noirq suspend of devices complete after 7.083 msecs
suspend debug: Waiting for 5 second(s).
Unhandled fault: external abort on non-linefetch (0x1008) at 0xd0262c60
...
[] (musb_default_readb) from [] (musb_irq_work+0x48/0x220)
[] (musb_irq_work) from [] (process_one_work+0x1f4/0x758)
[] (process_one_work) from [] (worker_thread+0x54/0x514)
[] (worker_thread) from [] (kthread+0x128/0x158)
[] (kthread) from [] (ret_from_fork+0x14/0x24)

Commit 2bff3916fda9 ("usb: musb: Fix PM for hub disconnect") started
scheduling musb_irq_work with a delay of up to a second and with
retries thereby making this easy to trigger, for example, by suspending
shortly after a disconnect.

Note that we set a flag to prevent the irq work from rescheduling itself
during suspend and instead process a disconnect immediately. This takes
care of the case where we are disconnected shortly before suspending.

However, when in host mode, a disconnect while suspended will still
go unnoticed and thus prevent the controller from runtime suspending
upon resume as the session bit is always set. This will need to be
addressed separately.

Fixes: 550a7375fe72 ("USB: Add MUSB and TUSB support")
Fixes: 467d5c980709 ("usb: musb: Implement session bit based runtime PM for 
musb-core")
Fixes: 2bff3916fda9 ("usb: musb: Fix PM for hub disconnect")
Cc: stable  # 4.9
Cc: Felipe Balbi 
Cc: Tony Lindgren 
Signed-off-by: Johan Hovold 
Tested-by: Tony Lindgren 
Signed-off-by: Bin Liu 
---
 drivers/usb/musb/musb_core.c | 11 +--
 drivers/usb/musb/musb_core.h |  2 ++
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 07b8c7152e3d..1ced3af75b05 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1861,7 +1861,7 @@ static void musb_pm_runtime_check_session(struct musb 
*musb)
MUSB_DEVCTL_HR;
switch (devctl & ~s) {
case MUSB_QUIRK_B_INVALID_VBUS_91:
-   if (musb->quirk_retries) {
+   if (musb->quirk_retries && !musb->flush_irq_work) {
musb_dbg(musb,
 "Poll devctl on invalid vbus, assume no 
session");
schedule_delayed_work(>irq_work,
@@ -1871,7 +1871,7 @@ static void musb_pm_runtime_check_session(struct musb 
*musb)
}
/* fall through */
case MUSB_QUIRK_A_DISCONNECT_19:
-   if (musb->quirk_retries) {
+   if (musb->quirk_retries && !musb->flush_irq_work) {
musb_dbg(musb,
 "Poll devctl on possible host mode 
disconnect");
schedule_delayed_work(>irq_work,
@@ -2681,8 +2681,15 @@ static int musb_suspend(struct device *dev)
 
musb_platform_disable(musb);
musb_disable_interrupts(musb);
+
+   musb->flush_irq_work = true;
+   while (flush_delayed_work(>irq_work))
+   ;
+   musb->flush_irq_work = false;
+
if (!(musb->io.quirks & MUSB_PRESERVE_SESSION))
musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
+
WARN_ON(!list_empty(>pending_list));
 
spin_lock_irqsave(>lock, flags);
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index c748f4ac1154..20f4614178d9 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -428,6 +428,8 @@ struct musb {
unsignedtest_mode:1;
unsignedsoftconnect:1;
 
+   unsignedflush_irq_work:1;
+
u8  address;
u8  test_mode_nr;
u16 ackpend;/* ep0 */
-- 
1.9.1

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

[PATCH 0/7] musb-fixes for v4.14 -rc

[Bin Liu]

Hi Greg,

Here is the first patch set for musb bug fixes for v4.14 -rc cycles. It fixes a
couple bugs in the musb runtime power management, corrects a few register
offsets for DA8xx, and a couple couple issues on SUNXI platform as while.
Please let me know if any change is needed.

Regards,
-Bin.
---

Alexandre Bailon (3):
  usb: musb: musb_cppi41: Fix the address of teardown and autoreq registers
  usb: musb: musb_cppi41: Fix cppi41_set_dma_mode() for DA8xx
  usb: musb: musb_cppi41: Configure the number of channels for DA8xx

Johan Hovold (2):
  USB: musb: fix session-bit runtime-PM quirk
  USB: musb: fix late external abort on suspend

Jonathan Liu (2):
  usb: musb: Check for host-mode using is_host_active() on reset interrupt
  usb: musb: sunxi: Explicitly release USB PHY on exit

 drivers/usb/musb/musb_core.c   | 21 ++
 drivers/usb/musb/musb_core.h   |  2 +
 drivers/usb/musb/musb_cppi41.c | 94 --
 drivers/usb/musb/sunxi.c   |  2 +
 4 files changed, 99 insertions(+), 20 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: [PATCH v2] usb: musb: sunxi: Explicitly release USB PHY on exit

[Bin Liu]

On Tue, Oct 10, 2017 at 01:45:25PM +1100, Jonathan Liu wrote:
> This fixes a kernel oops when unloading the driver due to usb_put_phy
> being called after usb_phy_generic_unregister when the device is
> detached. Calling usb_phy_generic_unregister causes x->dev->driver to
> be NULL in usb_put_phy and results in a NULL pointer dereference.
> 
> Cc: sta...@vger.kernel.org # v4.3+
> Signed-off-by: Jonathan Liu 
> ---
> Changes for v2:
>  - Use devm_usb_put_phy instead of usb_put_phy
> 
>  drivers/usb/musb/sunxi.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
> index c9a09b5bb6e5..dc353e24d53c 100644
> --- a/drivers/usb/musb/sunxi.c
> +++ b/drivers/usb/musb/sunxi.c
> @@ -297,6 +297,8 @@ static int sunxi_musb_exit(struct musb *musb)
>   if (test_bit(SUNXI_MUSB_FL_HAS_SRAM, >flags))
>   sunxi_sram_release(musb->controller->parent);
>  
> + devm_usb_put_phy(glue->dev, glue->xceiv);
> +
>   return 0;
>  }


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

[PATCH v2] usb: musb: sunxi: Explicitly release USB PHY on exit

[Jonathan Liu]

This fixes a kernel oops when unloading the driver due to usb_put_phy
being called after usb_phy_generic_unregister when the device is
detached. Calling usb_phy_generic_unregister causes x->dev->driver to
be NULL in usb_put_phy and results in a NULL pointer dereference.

Cc: sta...@vger.kernel.org # v4.3+
Signed-off-by: Jonathan Liu 
---
Changes for v2:
 - Use devm_usb_put_phy instead of usb_put_phy

 drivers/usb/musb/sunxi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
index c9a09b5bb6e5..dc353e24d53c 100644
--- a/drivers/usb/musb/sunxi.c
+++ b/drivers/usb/musb/sunxi.c
@@ -297,6 +297,8 @@ static int sunxi_musb_exit(struct musb *musb)
if (test_bit(SUNXI_MUSB_FL_HAS_SRAM, >flags))
sunxi_sram_release(musb->controller->parent);
 
+   devm_usb_put_phy(glue->dev, glue->xceiv);
+
return 0;
 }
 
-- 
2.14.2

--
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: musb: sunxi: Explicitly release USB PHY on exit

[Jonathan Liu]

Hi,

On 10 October 2017 at 13:14, Bin Liu  wrote:
> On Tue, Oct 10, 2017 at 08:17:34AM +1100, Jonathan Liu wrote:
>> Hi,
>>
>> On 10 October 2017 at 01:23, Bin Liu  wrote:
>> > Hi,
>> >
>> > On Tue, Sep 26, 2017 at 09:39:23PM +1000, Jonathan Liu wrote:
>> >> This fixes a kernel oops when unloading the driver due to usb_put_phy
>> >> being called after usb_phy_generic_unregister when the device is
>> >> detached. Calling usb_phy_generic_unregister causes x->dev->driver to
>> >> be NULL in usb_put_phy and results in a NULL pointer dereference.
>> >>
>> >> As we are now explicitly managing the lifetime of usb_phy,
>> >> devm_usb_get_phy is changed to usb_get_phy and we call usb_put_phy in
>> >> the probe error path.
>> >>
>> >> Cc: sta...@vger.kernel.org # v4.3+
>> >> Signed-off-by: Jonathan Liu 
>> >> ---
>> >>  drivers/usb/musb/sunxi.c | 8 ++--
>> >>  1 file changed, 6 insertions(+), 2 deletions(-)
>> >>
>> >> diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
>> >> index c9a09b5bb6e5..8eed61042103 100644
>> >> --- a/drivers/usb/musb/sunxi.c
>> >> +++ b/drivers/usb/musb/sunxi.c
>> >> @@ -297,6 +297,8 @@ static int sunxi_musb_exit(struct musb *musb)
>> >>   if (test_bit(SUNXI_MUSB_FL_HAS_SRAM, >flags))
>> >>   sunxi_sram_release(musb->controller->parent);
>> >>
>> >> + usb_put_phy(glue->xceiv);
>> >
>> > Will devm_usb_put_phy() solve the issue too? Then you don't need the
>> > changes in sunxi_musb_probe() below.
>> >
>>
>> devm_usb_put_phy does solve the issue without changes in
>> sunxi_musb_probe but I think it is clearer that the lifetime is
>> explicitly managed if we don't mix implicit and explicit freeing of
>> resources.
>
> Then what is the purpose of the devm_* API?
>
> The original bug was that devm_usb_get_phy() is called in _probe, but
> devm_usb_put_phy() was never called, which caused the device ref count
> unbalanced. It is not related to implicit/explicit resource management.
>
> devm_* is recommended whenever applicable.
>

Ok. Will use devm_usb_put_phy in v2 patch.

> Regards,
> -Bin.
>

Regards,
Jonathan
--
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: musb: sunxi: Explicitly release USB PHY on exit

[Bin Liu]

On Tue, Oct 10, 2017 at 08:17:34AM +1100, Jonathan Liu wrote:
> Hi,
> 
> On 10 October 2017 at 01:23, Bin Liu  wrote:
> > Hi,
> >
> > On Tue, Sep 26, 2017 at 09:39:23PM +1000, Jonathan Liu wrote:
> >> This fixes a kernel oops when unloading the driver due to usb_put_phy
> >> being called after usb_phy_generic_unregister when the device is
> >> detached. Calling usb_phy_generic_unregister causes x->dev->driver to
> >> be NULL in usb_put_phy and results in a NULL pointer dereference.
> >>
> >> As we are now explicitly managing the lifetime of usb_phy,
> >> devm_usb_get_phy is changed to usb_get_phy and we call usb_put_phy in
> >> the probe error path.
> >>
> >> Cc: sta...@vger.kernel.org # v4.3+
> >> Signed-off-by: Jonathan Liu 
> >> ---
> >>  drivers/usb/musb/sunxi.c | 8 ++--
> >>  1 file changed, 6 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
> >> index c9a09b5bb6e5..8eed61042103 100644
> >> --- a/drivers/usb/musb/sunxi.c
> >> +++ b/drivers/usb/musb/sunxi.c
> >> @@ -297,6 +297,8 @@ static int sunxi_musb_exit(struct musb *musb)
> >>   if (test_bit(SUNXI_MUSB_FL_HAS_SRAM, >flags))
> >>   sunxi_sram_release(musb->controller->parent);
> >>
> >> + usb_put_phy(glue->xceiv);
> >
> > Will devm_usb_put_phy() solve the issue too? Then you don't need the
> > changes in sunxi_musb_probe() below.
> >
> 
> devm_usb_put_phy does solve the issue without changes in
> sunxi_musb_probe but I think it is clearer that the lifetime is
> explicitly managed if we don't mix implicit and explicit freeing of
> resources.

Then what is the purpose of the devm_* API?

The original bug was that devm_usb_get_phy() is called in _probe, but
devm_usb_put_phy() was never called, which caused the device ref count
unbalanced. It is not related to implicit/explicit resource management.

devm_* is recommended whenever applicable.

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: [bugzilla-dae...@bugzilla.kernel.org: [Bug 197159] New: Xhci host controller not responding starting kernel 4.13]

[Bjorn Helgaas]

On Mon, Oct 09, 2017 at 10:45:39PM +0200, Mason wrote:
> On 09/10/2017 19:01, Bjorn Helgaas wrote:
> ...

> > In that thread, Mason reported a regression that looks similar, but as
> > far as I can tell, we never identified a root cause.
> > 
> >   1) The problem Mason reported was on a Tango platform, which has a
> >  known hardware issue that corrupts data when simultaneous config
> >  and MMIO accesses occur.  You're seeing the problem on a
> >  different platform, which is very helpful.
> 
> As mentioned here:
> https://www.mail-archive.com/linux-usb@vger.kernel.org/msg94020.html
> 
> When I disable the AER driver, not a single config space access
> occurs when a USB drive is unplugged. So I'm 99.99% sure that
> the issue is NOT caused by tango's bad design. (I got the vibe
> that nobody cared about tango's issue because it was assumed
> that the design flaw was responsible for it.)

I agree; I don't think this is Tango's fault.

Can you test fe190ed0d602 and d9f11ba9f107 to determine whether
d9f11ba9f107 is the culprit?  If it is the culprit, can you try reverting
it on a current kernel to see if that fixes it?

If d9f11ba9f107 is not the culprit, can you bisect to discover exactly
where it broke?

> >   2) Mathias suggested d9f11ba9f107 ("xhci: Rework how we handle
> >  unresponsive or hoptlug removed hosts"), which appeared in
> >  v4.12-rc1, as a possible culprit, but I don't see a bisection
> >  that definitively identifies this commit.
> > 
> >  Is it possible for you to test both fe190ed0d602 ("xhci: Do not
> >  halt the host until both HCD have disconnected their devices.")
> >  and d9f11ba9f107 ("xhci: Rework how we handle unresponsive or
> >  hoptlug removed hosts") so we can tell for sure whether
> >  d9f11ba9f107 broke it?
--
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] cdc_ether: flag the u-blox TOBY-L2 and SARA-U2 as wwan

[David Miller]

From: Aleksander Morgado 
Date: Mon,  9 Oct 2017 14:05:12 +0200

> The u-blox TOBY-L2 is a LTE Cat 4 module with HSPA+ and 2G fallback.
> This module allows switching to different USB profiles with the
> 'AT+UUSBCONF' command, and provides a ECM network interface when the
> 'AT+UUSBCONF=2' profile is selected.
> 
> The u-blox SARA-U2 is a HSPA module with 2G fallback. The default USB
> configuration includes a ECM network interface.
> 
> Both these modules are controlled via AT commands through one of the
> TTYs exposed. Connecting these modules may be done just by activating
> the desired PDP context with 'AT+CGACT=1,' and then running DHCP
> on the ECM interface.
> 
> Signed-off-by: Aleksander Morgado 

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

[PATCH 2/2 v2] typec: tcpm: Only request matching pdos

[Badhri Jagan Sridharan]

At present, TCPM code assumes that local device supports
variable/batt pdos and always selects the pdo with highest
possible power within the board limit. This assumption
might not hold good for all devices. To overcome this,
this patch makes TCPM only accept a source_pdo when there is
a matching sink pdo.

For Fixed pdos: The voltage should match between the
incoming source_cap and the registered snk_pdo
For Variable/Batt pdos: The incoming source_cap voltage
range should fall within the registered snk_pdo's voltage
range.

Also, when the cap_mismatch bit is set, the max_power/current
should be set to the max_current/power of the sink_pdo.
This is according to:

"If the Capability Mismatch bit is set to one
The Maximum Operating Current/Power field may contain a value
larger than the maximum current/power offered in the Source
Capabilities message’s PDO as referenced by the Object position field.
This enables the Sink to indicate that it requires more current/power
than is being offered. If the Sink requires a different voltage this
will be indicated by its Sink Capabilities message.

Signed-off-by: Badhri Jagan Sridharan 
---
Changelog since v1:
- rebased on top drivers/usb/typec/tcpm.c as suggested by
  gre...@linuxfoundation.org
- renamed nr_snk_*_pdo as suggested by dan.carpen...@oracle.com
- removed stale comment as suggested by li...@roeck-us.net
- removed the tests for nr_snk_*_pdo as suggested by
  dan.carpen...@oracle.com
- Fixed sytling as suggested by dan.carpen...@oracle.com
- renamed tcpm_get_nr_type_pdos to nr_type_pdos as suggested by
  dan.carpen...@oracle.com
- fixed nr_type_pdos as suggested by dan.carpen...@oracle.com
- tcpm_pd_select_pdo now checks for all matching variable/batt pdos
  instead of the first matching one.

 drivers/usb/typec/tcpm.c | 155 ---
 1 file changed, 120 insertions(+), 35 deletions(-)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 75deac3ee58d..62d6fad8602f 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -261,6 +261,9 @@ struct tcpm_port {
unsigned int nr_src_pdo;
u32 snk_pdo[PDO_MAX_OBJECTS];
unsigned int nr_snk_pdo;
+   unsigned int nr_fixed; /* number of fixed sink PDOs */
+   unsigned int nr_var; /* number of variable sink PDOs */
+   unsigned int nr_batt; /* number of battery sink PDOs */
u32 snk_vdo[VDO_MAX_OBJECTS];
unsigned int nr_snk_vdo;
 
@@ -1758,39 +1761,92 @@ static int tcpm_pd_check_request(struct tcpm_port *port)
return 0;
 }
 
-static int tcpm_pd_select_pdo(struct tcpm_port *port)
+static void tcpm_pd_evaluate_pdo(struct tcpm_port *port, int src_pdo_index,
+int snk_pdo_index, int *max_mw, int *max_mv,
+int *selected_src_pdo,
+int *matching_snk_pdo)
 {
-   unsigned int i, max_mw = 0, max_mv = 0;
+   unsigned int mv = 0, ma = 0, mw = 0;
+   u32 src_pdo = port->source_caps[src_pdo_index];
+   u32 snk_pdo = port->snk_pdo[snk_pdo_index];
+   enum pd_pdo_type type = pdo_type(src_pdo);
+
+   mv = (type == PDO_TYPE_FIXED) ? pdo_fixed_voltage(src_pdo) :
+   pdo_min_voltage(src_pdo);
+
+   if (type == PDO_TYPE_BATT) {
+   mw = min(pdo_max_power(src_pdo), pdo_max_power(snk_pdo));
+   } else {
+   ma = min(pdo_max_current(src_pdo), pdo_max_current(snk_pdo));
+   mw = ma * mv / 1000;
+   }
+
+   /* Perfer higher voltages if available */
+   if (mw > *max_mw || (mw == *max_mw && mv > *max_mv)) {
+   *selected_src_pdo = src_pdo_index;
+   *matching_snk_pdo = snk_pdo_index;
+   *max_mw = mw;
+   *max_mv = mv;
+   }
+}
+
+static int tcpm_pd_select_pdo(struct tcpm_port *port, int *sink_pdo)
+{
+   unsigned int i, j, max_mw = 0, max_mv = 0;
int ret = -EINVAL;
 
/*
-* Select the source PDO providing the most power while staying within
-* the board's voltage limits. Prefer PDO providing exp
+* Select the source PDO providing the most power which has a
+* matchig sink cap.
 */
for (i = 0; i < port->nr_source_caps; i++) {
u32 pdo = port->source_caps[i];
enum pd_pdo_type type = pdo_type(pdo);
-   unsigned int mv, ma, mw;
-
-   if (type == PDO_TYPE_FIXED)
-   mv = pdo_fixed_voltage(pdo);
-   else
-   mv = pdo_min_voltage(pdo);
-
-   if (type == PDO_TYPE_BATT) {
-   mw = pdo_max_power(pdo);
-   } else {
-   ma = min(pdo_max_current(pdo),
-port->max_snk_ma);
-   mw = ma * mv / 1000;
-   }
 
-   /* Perfer higher voltages if available 

[PATCH 1/2 v2] typec: tcpm: Validate source and sink caps

[Badhri Jagan Sridharan]

The source and sink caps should follow the following rules.
This patch validates whether the src_caps/snk_caps adheres
to it.

6.4.1 Capabilities Message
A Capabilities message (Source Capabilities message or Sink
Capabilities message) shall have at least one Power
Data Object for vSafe5V. The Capabilities message shall also
contain the sending Port’s information followed by up to
6 additional Power Data Objects. Power Data Objects in a
Capabilities message shall be sent in the following order:

1. The vSafe5V Fixed Supply Object shall always be the first object.
2. The remaining Fixed Supply Objects, if present, shall be sent
   in voltage order; lowest to highest.
3. The Battery Supply Objects, if present shall be sent in Minimum
   Voltage order; lowest to highest.
4. The Variable Supply (non-battery) Objects, if present, shall be
   sent in Minimum Voltage order; lowest to highest.

Errors in source/sink_caps of the local port will prevent
the port registration. Whereas, errors in source caps of partner
device would only log them.

Signed-off-by: Badhri Jagan Sridharan 
---
Changelog since v1:
- Rebased the patch on top of drivers/usb/type/tcpm.c
- Added duplicate pdo check for variable/batt pdo.
- Fixed tabs as suggested by dan.carpen...@oracle.com

 drivers/usb/typec/tcpm.c | 114 +++
 include/linux/usb/pd.h   |   2 +
 include/linux/usb/tcpm.h |   4 +-
 3 files changed, 109 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 8483d3e33853..75deac3ee58d 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -1256,6 +1256,82 @@ static void vdm_state_machine_work(struct work_struct 
*work)
mutex_unlock(>lock);
 }
 
+static int tcpm_validate_caps(struct tcpm_port *port, const u32 *pdo,
+ unsigned int nr_pdo)
+{
+   unsigned int i;
+
+   /* Should at least contain vSafe5v */
+   if (nr_pdo < 1) {
+   tcpm_log_force(port,
+  " err: source/sink caps should atleast have 
vSafe5V");
+   return -EINVAL;
+   }
+
+   /* The vSafe5V Fixed Supply Object Shall always be the first object */
+   if (pdo_type(pdo[0]) != PDO_TYPE_FIXED ||
+   pdo_fixed_voltage(pdo[0]) != VSAFE5V) {
+   tcpm_log_force(port,
+  " err: vSafe5V Fixed Supply Object Shall always 
be the first object");
+   return -EINVAL;
+   }
+
+   for (i = 1; i < nr_pdo; i++) {
+   if (pdo_type(pdo[i]) < pdo_type(pdo[i - 1])) {
+   tcpm_log_force(port,
+  " err:PDOs should be in the following 
order: Fixed; Battery; Variable. pdo index:%u"
+  , i);
+   return -EINVAL;
+   } else if (pdo_type(pdo[i]) == pdo_type(pdo[i - 1])) {
+   enum pd_pdo_type type = pdo_type(pdo[i]);
+
+   switch (type) {
+   /*
+* The remaining Fixed Supply Objects, if
+* present, shall be sent in voltage order;
+* lowest to highest.
+*/
+   case PDO_TYPE_FIXED:
+   if (pdo_fixed_voltage(pdo[i]) <=
+   pdo_fixed_voltage(pdo[i - 1])) {
+   tcpm_log_force(port,
+  " err: Fixed supply pdos 
should be in increasing order, pdo index:%u"
+  , i);
+   return -EINVAL;
+   }
+   break;
+   /*
+* The Battery Supply Objects and Variable
+* supply, if present shall be sent in Minimum
+* Voltage order; lowest to highest.
+*/
+   case PDO_TYPE_VAR:
+   case PDO_TYPE_BATT:
+   if (pdo_min_voltage(pdo[i]) <
+   pdo_min_voltage(pdo[i - 1])) {
+   tcpm_log_force(port,
+  " err: Variable supply 
pdos should be in increasing order, pdo index:%u"
+  , i);
+   return -EINVAL;
+   } else if ((pdo_min_voltage(pdo[i]) ==
+   pdo_min_voltage(pdo[i - 1])) &&
+  (pdo_max_voltage(pdo[i]) ==
+   pdo_min_voltage(pdo[i - 1]))) {
+   tcpm_log_force(port,

Re: [RESEND x2][PATCH 0/3] dwc2 fixes for edge cases on hikey

[John Stultz]

On Tue, Oct 3, 2017 at 2:58 AM, Minas Harutyunyan
 wrote:
>
> Could you please apply patch from Vardan Mikayelyan "usb: dwc2: Fix
> dwc2_hsotg_core_init_disconnected()" submitted at 02/25/2017
> (https://marc.info/?l=linux-usb=148801589931039=2) instead of your
> "usb: dwc2: Improve gadget state disconnection handling" and test again
> failing scenario.

I may be misunderstanding htings, but I don't believe that patch
addresses the same issue I'm trying to fix (I've tested with it, and
it doesn't cause any trouble for me, but it also doesn't seem to
address the corner-cases I'm hitting).

My "Improve gadget state disconnection handling" patch handles the
fact that when we switch from B/gadget mode to A/Host mode, we don't
always go through a gadget disconnect path.

So instead of calling the dwc2_hsotg_disconnect() path initially when
switching to gadget mode (to avoid the state complaining that we set
it up twice), we should instead be calling dwc2_hsotg_disconnect()
when we are setting up the A/host mode.

So for example, the follow-on fix to the UDC state won't properly work
without my "Improve gadget state disconnection handling" patch, and
"cat /sys/class/udc/f72c.usb/state" will always return configured
(assuming gadget mode was used once) regardless of the gadget state,
since we don't actually call dwc2_hsotg_disconnect when the otg plug
is removed.

> Other 2 patches from series "[PATCH 0/3] dwc2 fixes for edge cases on
> hikey" are Ok.

Thanks for the review/feedback!

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

Re: [PATCH] usb: musb: sunxi: Explicitly release USB PHY on exit

[Jonathan Liu]

Hi,

On 10 October 2017 at 01:23, Bin Liu  wrote:
> Hi,
>
> On Tue, Sep 26, 2017 at 09:39:23PM +1000, Jonathan Liu wrote:
>> This fixes a kernel oops when unloading the driver due to usb_put_phy
>> being called after usb_phy_generic_unregister when the device is
>> detached. Calling usb_phy_generic_unregister causes x->dev->driver to
>> be NULL in usb_put_phy and results in a NULL pointer dereference.
>>
>> As we are now explicitly managing the lifetime of usb_phy,
>> devm_usb_get_phy is changed to usb_get_phy and we call usb_put_phy in
>> the probe error path.
>>
>> Cc: sta...@vger.kernel.org # v4.3+
>> Signed-off-by: Jonathan Liu 
>> ---
>>  drivers/usb/musb/sunxi.c | 8 ++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
>> index c9a09b5bb6e5..8eed61042103 100644
>> --- a/drivers/usb/musb/sunxi.c
>> +++ b/drivers/usb/musb/sunxi.c
>> @@ -297,6 +297,8 @@ static int sunxi_musb_exit(struct musb *musb)
>>   if (test_bit(SUNXI_MUSB_FL_HAS_SRAM, >flags))
>>   sunxi_sram_release(musb->controller->parent);
>>
>> + usb_put_phy(glue->xceiv);
>
> Will devm_usb_put_phy() solve the issue too? Then you don't need the
> changes in sunxi_musb_probe() below.
>

devm_usb_put_phy does solve the issue without changes in
sunxi_musb_probe but I think it is clearer that the lifetime is
explicitly managed if we don't mix implicit and explicit freeing of
resources.

>> +
>>   return 0;
>>  }
>>
>> @@ -781,7 +783,7 @@ static int sunxi_musb_probe(struct platform_device *pdev)
>>   return PTR_ERR(glue->usb_phy);
>>   }
>>
>> - glue->xceiv = devm_usb_get_phy(>dev, USB_PHY_TYPE_USB2);
>> + glue->xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
>>   if (IS_ERR(glue->xceiv)) {
>>   ret = PTR_ERR(glue->xceiv);
>>   dev_err(>dev, "Error getting usb-phy %d\n", ret);
>> @@ -803,11 +805,13 @@ static int sunxi_musb_probe(struct platform_device 
>> *pdev)
>>   if (IS_ERR(glue->musb_pdev)) {
>>   ret = PTR_ERR(glue->musb_pdev);
>>   dev_err(>dev, "Error registering musb dev: %d\n", ret);
>> - goto err_unregister_usb_phy;
>> + goto err_put_usb_phy;
>>   }
>>
>>   return 0;
>>
>> +err_put_usb_phy:
>> + usb_put_phy(glue->xceiv);
>>  err_unregister_usb_phy:
>>   usb_phy_generic_unregister(glue->usb_phy);
>>   return ret;
>> --
>> 2.13.2
>
> Regards,
> -Bin.

Regards,
Jonathan
--
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: [bugzilla-dae...@bugzilla.kernel.org: [Bug 197159] New: Xhci host controller not responding starting kernel 4.13]

[Mason]

On 09/10/2017 19:01, Bjorn Helgaas wrote:

> [+cc linux-pci, linux-usb, Mason, Mathias, Lukas, Greg, Felipe, Alan]
> 
> - Forwarded message from bugzilla-dae...@bugzilla.kernel.org -
>>
>> Date: Sun, 08 Oct 2017 13:28:13 +
>> From: bugzilla-dae...@bugzilla.kernel.org
>> To: bugzilla@gmail.com
>> Subject: [Bug 197159] New: Xhci host controller not responding starting 
>> kernel 4.13
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=197159
>>
>> Bug ID: 197159
>>Summary: Xhci host controller not responding starting kernel
>> 4.13
>>Product: Drivers
>>Version: 2.5
>> Kernel Version: 4.13
>>   Hardware: Intel
>> OS: Linux
>>   Tree: Mainline
>> Status: NEW
>>   Severity: blocking
>>   Priority: P1
>>  Component: PCI
>>   Assignee: drivers_...@kernel-bugs.osdl.org
>>   Reporter: nik...@vividvisions.se
>> Regression: No
>>
>> When booting with a Expresscard USB 3.0 adapter (NEC UPD720202 Chip), the
>> following error is generated:
>>
>> "xhci_hcd :05:00.0: xHCI host controller not responding, assumed dead"
>>
>> This card still works fine with kernel 4.9.
> 
> Thanks very much for the bug report, and sorry for the regression.
> 
> Can you please collect the complete dmesg log and "lspci -vv" output
> and attach them to the bugzilla?
> 
>> Additionally, for some reason this also interferes with LUKS on an LVM
>> partition; password does not work and computer becomes stuck at this point.
>> This works as normal if card is removed and computer is rebooted.
>>
>> Can we please have Expresscard USB 3.0 functionality back in the kernel?
>>
>> This problem has been described elsewhere, but couldn't find any kernel bug
>> report for it. See this link for further information:
>>
>> http://patchwork.ozlabs.org/patch/804867/

Alternate links:
https://www.spinics.net/lists/linux-pci/msg64202.html
https://www.mail-archive.com/linux-usb@vger.kernel.org/msg93821.html

> In that thread, Mason reported a regression that looks similar, but as
> far as I can tell, we never identified a root cause.
> 
>   1) The problem Mason reported was on a Tango platform, which has a
>  known hardware issue that corrupts data when simultaneous config
>  and MMIO accesses occur.  You're seeing the problem on a
>  different platform, which is very helpful.

As mentioned here:
https://www.mail-archive.com/linux-usb@vger.kernel.org/msg94020.html

When I disable the AER driver, not a single config space access
occurs when a USB drive is unplugged. So I'm 99.99% sure that
the issue is NOT caused by tango's bad design. (I got the vibe
that nobody cared about tango's issue because it was assumed
that the design flaw was responsible for it.)

>   2) Mathias suggested d9f11ba9f107 ("xhci: Rework how we handle
>  unresponsive or hoptlug removed hosts"), which appeared in
>  v4.12-rc1, as a possible culprit, but I don't see a bisection
>  that definitively identifies this commit.
> 
>  Is it possible for you to test both fe190ed0d602 ("xhci: Do not
>  halt the host until both HCD have disconnected their devices.")
>  and d9f11ba9f107 ("xhci: Rework how we handle unresponsive or
>  hoptlug removed hosts") so we can tell for sure whether
>  d9f11ba9f107 broke it?
> 
>   3) Mason did report:
>v4.11.12 OK
>v4.12-rc1 KO
>  I assume "KO" means broken (unless that's a typo for "OK"?).  If
>  it means "broken", he did at least confirm that the problem first
>  appeared in v4.12-rc1.

Yes, KO (as in boxing knockout) means "broken", "double-plus-ungood".
It might be unfortunate to use OK and KO, as you point out.

Regards.
--
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: VL805 xHCI DMA read faults

[Robin Murphy]

On 09/10/17 16:49, Robin Murphy wrote:
> On 09/10/17 10:22, Mathias Nyman wrote:
>> On 08.10.2017 17:03, Hao Wei Tee wrote:
>>> Hi,
>>>
>>> I've been having DMA read faults with my VL805 xHCI controller when
>>> the Intel IOMMU
>>> is turned on:
>>>
>>>  xhci_hcd :03:00.0: xHCI Host Controller
>>>  xhci_hcd :03:00.0: new USB bus registered, assigned bus number 2
>>>  DMAR: DRHD: handling fault status reg 3
>>>  DMAR: [DMA Read] Request device [03:00.0] fault addr de28a000
>>> [fault reason 01] Present bit in root entry is clear
>>>  
>>>  xhci_hcd :03:00.0: can't setup: -110
>>>  xhci_hcd :03:00.0: USB bus 2 deregistered
>>>  xhci_hcd :03:00.0: init :03:00.0 fail, -110
>>>  xhci_hcd: probe of :03:00.0 failed with error -110
>>>
>>> The controller works fine, as far as I can tell, when the IOMMU is off.
>>>
>>> I've tracked it down to where CMD_RESET is sent to the controller in
>>> xhci_reset,
>>> [1] called from xhci_gen_setup in xhci.c. It seems that when the
>>> command register
>>> is being polled in the xhci_handshake after that, the controller tries
>>> to do a
>>> DMA read from an address that is apparently invalid (?). Eventually
>>> xhci_handshake
>>> times out.
>>>
>>> I've tried setting the XHCI_NO_64BIT_SUPPORT quirks flag as someone
>>> suggested in
>>> an earlier thread here [2] about a similar/the same(?) device, but
>>> that doesn't
>>> seem to have worked.
>>>
>>> Help, please. I have no idea how to debug this further.
>>>
>>
>> Could it maybe be related to a iommu/vt-d: Fix scatterlist offset
>> handling fix:
>> https://lists.linuxfoundation.org/pipermail/iommu/2017-September/024371.html
>>
>>
>> Can you check if that patch is included?
>>
>> The author Robin Murphy (CC) Also had some recent issues with a VIA
>> VL805 controller
>>
>> https://marc.info/?l=linux-usb=150730678304383=2
> 
> I'm pretty confident this is unrelated to the intel-iommu issue that
> my patch above addresses. On my arm64 test system, the VL805 is
> consistently playing up even *without* an IOMMU - dd'ing from a USB3
> mass storage device throws up a series of block layer errors like this:
> 
> [  138.658733] sd 2:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 
> driverbyte=0x00
> [  138.666853] sd 2:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 00 00 00 a8 00 
> 01 80 00
> [  138.674369] print_req_error: I/O error, dev sdb, sector 168
> 
> 
> Brain dump so far:
> 
>  - I can reliably produce these errors using dd with a block size of
>128K or greater; more generally they seem correlated with
>dma_map_sg() calls where the scatterlist is 32 or more entries long.
> 
>  - without the IOMMU, block sizes >=128K all settle down into a
>suspiciously-periodic error every 2048 sectors.
> 
>  - with the IOMMU, the faulting write address is always the first byte
>of a page immediately following a valid XHCI DMA mapping; I'm no USB
>expert, but having now generated the debug log below, this might
>actually just be a symptom of the queue getting out of whack earlier.
> 
>  - FWIW, neither XHCI_NO_64BIT_SUPPORT as mentioned in the other thread,
>nor XHCI_BROKEN_STREAMS per the other VIA quirk, makes any visible
>difference.
> 
>  - The same device works quite happily in USB 2.0 ports on the same
>system (via on-SoC EHCI), and with a different USB 3.0 PCIe card
>based on a Renesas uPD720201.

Actually, I tell a lie there - I was getting confused with the results
from the USB3-ethernet adapter. With the Renesas card, dd'ing from the
USB3-SATA adapter *does* still generate the same periodic error every
2048 sectors with block sizes >= 128K, but it recovers an awful lot
quicker each time, and never triggers IOMMU faults. The USB 2.0 host
has no issues.

Robin.

--->8---

lsusb -v output for this cheap no-name adapter plugged into the
Renesas card, complete with 100% reproducible stall in the process:


Bus 004 Device 003: ID 13fd:3940 Initio Corporation 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   3.00
  bDeviceClass0 
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize0 9
  idVendor   0x13fd Initio Corporation
  idProduct  0x3940 
  bcdDevice3.09
  iManufacturer   1 TS1GSDOM
  iProduct2 22V 
  iSerial 3 32303131313230313030303041303030
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   44
bNumInterfaces  1
bConfigurationValue 1
iCo[ 1014.305508] xhci_hcd :04:00.0: Stalled endpoint for slot 1 ep 0
[ 1014.314281] xhci_hcd :04:00.0: Cleaning up stalled endpoint ring
[ 1014.320574] xhci_hcd :04:00.0: Finding endpoint context
[ 1014.326094] xhci_hcd :04:00.0: Cycle state = 0x1
[ 1014.331010] xhci_hcd :04:00.0: New dequeue 

Re: Documentation for USB device interface for power consumption

[Alan Stern]

On Mon, 9 Oct 2017, Kai Hendry wrote:

> Hi there,
> 
> Can't see the /{proc,sys} interface documented in places I expect to be
> like https://github.com/torvalds/linux/tree/master/drivers/usb
> 
> And the mailing list search is pretty awful:
> https://marc.info/?l=linux-usb=2=1=power+measure=b
> 
> My use case is to examine the power draw from my USB port of my iPhone:
> lsusb | grep iPhone
> Bus 001 Device 009: ID 05ac:12a8 Apple, Inc. iPhone5/5C/5S/6
> 
> First problem is to identify the USB port! Currently I am `find
> /sys/devices | grep usb` & wondering how on earth it maps to "Bus 001
> Device 009: ID 05ac:12a8".

The mapping goes the other way.  Given the bus and port you can find
the device number by reading the /sys/bus/usb/devices/B-P/devnum file,
where B is the bus number and P is the port number (or path if the
device is plugged into a hub).

> Next I am hoping the see the power consumption my mA or something like
> that?

Have you tried running lsusb with the -v flag?  Or reading the 
/sys/bus/usb/devices/B-P/bMaxPower file?

> I did eventually find https://unix.stackexchange.com/a/81615/27433 but
> why isn't the a /proc like interface to this?

There is, but it's under /sys rather than /proc.

> Is there a way to see the
> negotiation somehow since my iPhone doesn't seem to like 500mA.

What negotation are you referring to?

If your iPhone doesn't like 500 mA, it doesn't have to use that much.  
The amount of current drawn by a USB device is determined almost
entirely by the device; the host won't do anything about it other than
to shut off the port if the device tries to take too much current.

In general, it's possible to see all USB traffic by using usbmon or 
wireshark.

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: [RFC usb-next v5 3/3] usb: core: hcd: integrate the PHY roothub wrapper

[Alan Stern]

On Sun, 8 Oct 2017, Martin Blumenstingl wrote:

> This integrates the PHY roothub wrapper into the core hcd
> infrastructure. Multiple PHYs which are part of the roothub devicetree
> node (which is a sub-node of the sysdev's node) are now managed
> (= powered on/off when needed), by the new usb_phy_roothub code.
> 
> One example where this is required is the Amlogic GXL and GXM SoCs:
> They are using a dwc3 USB controller with up to three ports enabled on
> the internal roothub. Using only the top-level "phy" properties does not
> work here since one can only specify one "usb2-phy" and one "usb3-phy",
> while actually at least two "usb2-phy" have to be specified.
> 
> Signed-off-by: Martin Blumenstingl 
> ---
>  drivers/usb/core/hcd.c  | 30 +-
>  include/linux/usb/hcd.h |  1 +
>  2 files changed, 30 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
> index 67aa3d039b9b..56704dd10c15 100644
> --- a/drivers/usb/core/hcd.c
> +++ b/drivers/usb/core/hcd.c
> @@ -50,6 +50,7 @@
>  #include 
>  
>  #include "usb.h"
> +#include "phy.h"
>  
>  
>  /*-*/
> @@ -2292,7 +2293,11 @@ int hcd_bus_suspend(struct usb_device *rhdev, 
> pm_message_t msg)
>   dev_dbg(>dev, "bus %s fail, err %d\n",
>   "suspend", status);
>   }
> - return status;
> +
> + if (status == 0)
> + return usb_phy_roothub_power_off(hcd->phy_roothub);

Is this really the right thing to do?  If usb_phy_roothub_power_off() 
fails, what condition does this leave the bus in?  And what condition 
does the kernel _think_ the bus is in?

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: [RFC usb-next v5 2/3] usb: core: add a wrapper for the USB PHYs on the root-hub

[Alan Stern]

On Sun, 8 Oct 2017, Martin Blumenstingl wrote:

> Many SoC platforms have separate devices for the USB PHY which are
> registered through the generic PHY framework. These PHYs have to be
> enabled to make the USB controller actually work. They also have to be
> disabled again on shutdown/suspend.

...

> --- /dev/null
> +++ b/drivers/usb/core/phy.h
> @@ -0,0 +1,7 @@
> +struct usb_phy_roothub;
> +
> +struct usb_phy_roothub *usb_phy_roothub_init(struct device *dev);
> +int usb_phy_roothub_exit(struct usb_phy_roothub *phy_roothub);
> +
> +int usb_phy_roothub_power_on(struct usb_phy_roothub *phy_roothub);
> +int usb_phy_roothub_power_off(struct usb_phy_roothub *phy_roothub);

Have you considered the possibility that a phy might need three power
states, for on, off, and suspended?

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

[bugzilla-dae...@bugzilla.kernel.org: [Bug 197159] New: Xhci host controller not responding starting kernel 4.13]

[Bjorn Helgaas]

[+cc linux-pci, linux-usb, Mason, Mathias, Lukas, Greg, Felipe, Alan]

- Forwarded message from bugzilla-dae...@bugzilla.kernel.org -
> 
> Date: Sun, 08 Oct 2017 13:28:13 +
> From: bugzilla-dae...@bugzilla.kernel.org
> To: bugzilla@gmail.com
> Subject: [Bug 197159] New: Xhci host controller not responding starting kernel
>   4.13
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=197159
> 
> Bug ID: 197159
>Summary: Xhci host controller not responding starting kernel
> 4.13
>Product: Drivers
>Version: 2.5
> Kernel Version: 4.13
>   Hardware: Intel
> OS: Linux
>   Tree: Mainline
> Status: NEW
>   Severity: blocking
>   Priority: P1
>  Component: PCI
>   Assignee: drivers_...@kernel-bugs.osdl.org
>   Reporter: nik...@vividvisions.se
> Regression: No
> 
> When booting with a Expresscard USB 3.0 adapter (NEC UPD720202 Chip), the
> following error is generated:
> 
> "xhci_hcd :05:00.0: xHCI host controller not responding, assumed dead"
> 
> This card still works fine with kernel 4.9.

Thanks very much for the bug report, and sorry for the regression.

Can you please collect the complete dmesg log and "lspci -vv" output
and attach them to the bugzilla?

> Additionally, for some reason this also interferes with LUKS on an LVM
> partition; password does not work and computer becomes stuck at this point.
> This works as normal if card is removed and computer is rebooted.
> 
> Can we please have Expresscard USB 3.0 functionality back in the kernel?
> 
> This problem has been described elsewhere, but couldn't find any kernel bug
> report for it. See this link for further information:
> 
> http://patchwork.ozlabs.org/patch/804867/

In that thread, Mason reported a regression that looks similar, but as
far as I can tell, we never identified a root cause.

  1) The problem Mason reported was on a Tango platform, which has a
 known hardware issue that corrupts data when simultaneous config
 and MMIO accesses occur.  You're seeing the problem on a
 different platform, which is very helpful.

  2) Mathias suggested d9f11ba9f107 ("xhci: Rework how we handle
 unresponsive or hoptlug removed hosts"), which appeared in
 v4.12-rc1, as a possible culprit, but I don't see a bisection
 that definitively identifies this commit.

 Is it possible for you to test both fe190ed0d602 ("xhci: Do not
 halt the host until both HCD have disconnected their devices.")
 and d9f11ba9f107 ("xhci: Rework how we handle unresponsive or
 hoptlug removed hosts") so we can tell for sure whether
 d9f11ba9f107 broke it?

  3) Mason did report:
   v4.11.12 OK
   v4.12-rc1 KO
 I assume "KO" means broken (unless that's a typo for "OK"?).  If
 it means "broken", he did at least confirm that the problem first
 appeared in v4.12-rc1.

Bjorn

> Tested with Antergos (Arch) on a Thinkpad T420. The card works with the LTS
> kernel which is at 4.9.52-1 but not the latest which is 4.13.3-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: musb: Check for host-mode using is_host_active() on reset interrupt

[Bin Liu]

Hi,

On Wed, Sep 27, 2017 at 08:35:22PM +1000, Jonathan Liu wrote:
> The sunxi musb has a bug where sometimes it will generate a babble
> error on device disconnect instead of a disconnect IRQ. When this
> happens the musb controller switches from host mode to device mode
> (it clears MUSB_DEVCTL_HM/MUSB_DEVCTL_SESSION and sets
> MUSB_DEVCTL_BDEVICE) and gets stuck in this state.
> 
> The babble error is misdetected as a bus reset because MUSB_DEVCTL_HM
> was cleared.
> 
> To fix this, use is_host_active() rather than (devctl & MUSB_DEVCTL_HM)
> to detect babble error so that sunxi musb babble recovery can handle it
> by restoring the mode. This information is provided by the driver logic
> and does not rely on register contents.
> 
> Cc: sta...@vger.kernel.org # v4.1+
> Signed-off-by: Jonathan Liu 

Applied. Thanks.
-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: VL805 xHCI DMA read faults

[Robin Murphy]

On 09/10/17 10:22, Mathias Nyman wrote:
> On 08.10.2017 17:03, Hao Wei Tee wrote:
>> Hi,
>>
>> I've been having DMA read faults with my VL805 xHCI controller when
>> the Intel IOMMU
>> is turned on:
>>
>>  xhci_hcd :03:00.0: xHCI Host Controller
>>  xhci_hcd :03:00.0: new USB bus registered, assigned bus number 2
>>  DMAR: DRHD: handling fault status reg 3
>>  DMAR: [DMA Read] Request device [03:00.0] fault addr de28a000
>> [fault reason 01] Present bit in root entry is clear
>>  
>>  xhci_hcd :03:00.0: can't setup: -110
>>  xhci_hcd :03:00.0: USB bus 2 deregistered
>>  xhci_hcd :03:00.0: init :03:00.0 fail, -110
>>  xhci_hcd: probe of :03:00.0 failed with error -110
>>
>> The controller works fine, as far as I can tell, when the IOMMU is off.
>>
>> I've tracked it down to where CMD_RESET is sent to the controller in
>> xhci_reset,
>> [1] called from xhci_gen_setup in xhci.c. It seems that when the
>> command register
>> is being polled in the xhci_handshake after that, the controller tries
>> to do a
>> DMA read from an address that is apparently invalid (?). Eventually
>> xhci_handshake
>> times out.
>>
>> I've tried setting the XHCI_NO_64BIT_SUPPORT quirks flag as someone
>> suggested in
>> an earlier thread here [2] about a similar/the same(?) device, but
>> that doesn't
>> seem to have worked.
>>
>> Help, please. I have no idea how to debug this further.
>>
> 
> Could it maybe be related to a iommu/vt-d: Fix scatterlist offset
> handling fix:
> https://lists.linuxfoundation.org/pipermail/iommu/2017-September/024371.html
> 
> 
> Can you check if that patch is included?
> 
> The author Robin Murphy (CC) Also had some recent issues with a VIA
> VL805 controller
> 
> https://marc.info/?l=linux-usb=150730678304383=2

I'm pretty confident this is unrelated to the intel-iommu issue that
my patch above addresses. On my arm64 test system, the VL805 is
consistently playing up even *without* an IOMMU - dd'ing from a USB3
mass storage device throws up a series of block layer errors like this:

[  138.658733] sd 2:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 
driverbyte=0x00
[  138.666853] sd 2:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 00 00 00 a8 00 01 
80 00
[  138.674369] print_req_error: I/O error, dev sdb, sector 168


Brain dump so far:

 - I can reliably produce these errors using dd with a block size of
   128K or greater; more generally they seem correlated with
   dma_map_sg() calls where the scatterlist is 32 or more entries long.

 - without the IOMMU, block sizes >=128K all settle down into a
   suspiciously-periodic error every 2048 sectors.

 - with the IOMMU, the faulting write address is always the first byte
   of a page immediately following a valid XHCI DMA mapping; I'm no USB
   expert, but having now generated the debug log below, this might
   actually just be a symptom of the queue getting out of whack earlier.

 - FWIW, neither XHCI_NO_64BIT_SUPPORT as mentioned in the other thread,
   nor XHCI_BROKEN_STREAMS per the other VIA quirk, makes any visible
   difference.

 - The same device works quite happily in USB 2.0 ports on the same
   system (via on-SoC EHCI), and with a different USB 3.0 PCIe card
   based on a Renesas uPD720201.

Robin.


--->8---
This is the IOMMU-enabled version of everything from the point of
plugging in my USB3/SATA adapter to the out-of-bounds write that
triggers a fault (from which the host controller then never really
recovers):

[  425.195232] xhci_hcd :04:00.0: Port Status Change Event for port 1
[  425.201708] xhci_hcd :04:00.0: resume root hub
[  425.206459] xhci_hcd :04:00.0: port resume event for port 1
[  425.212324] xhci_hcd :04:00.0: resume HS port 1
[  425.217158] xhci_hcd :04:00.0: handle_port_status: starting port polling.
[  425.224299] xhci_hcd :04:00.0: get port status, actual port 0 status  = 
0x4fe3
[  425.232140] xhci_hcd :04:00.0: Get port status returned 0x507
[  425.238285] xhci_hcd :04:00.0: suspend failed because a port is resuming
[  425.245299] xhci_hcd :04:00.0: Resume USB2 port 1
[  425.250723] xhci_hcd :04:00.0: Port Status Change Event for port 1
[  425.257243] xhci_hcd :04:00.0: get port status, actual port 0 status  = 
0x4fe3
[  425.265084] xhci_hcd :04:00.0: Get port status returned 0x40503
[  425.271351] xhci_hcd :04:00.0: get port status, actual port 0 status  = 
0x40400e03
[  425.279192] xhci_hcd :04:00.0: Get port status returned 0x40503
[  425.285469] xhci_hcd :04:00.0: clear port suspend/resume change, actual 
port 0 status  = 0x4e03
[  425.312450] xhci_hcd :04:00.0: get port status, actual port 0 status  = 
0x4e03
[  425.320292] xhci_hcd :04:00.0: Get port status returned 0x503
[  425.356419] xhci_hcd :04:00.0: xhci_hub_status_data: stopping port 
polling.
[  425.436469] xhci_hcd :04:00.0: get port status, actual port 0 status  = 
0x4e03
[  425.444311] 

Re: VL805 xHCI DMA read faults

[Hao Wei Tee]

On 09/10/2017 17:22, Mathias Nyman wrote:
> On 08.10.2017 17:03, Hao Wei Tee wrote:
>> Hi,
>>
>> I've been having DMA read faults with my VL805 xHCI controller when the 
>> Intel IOMMU
>> is turned on:
>>
>>  xhci_hcd :03:00.0: xHCI Host Controller
>>  xhci_hcd :03:00.0: new USB bus registered, assigned bus number 2
>>  DMAR: DRHD: handling fault status reg 3
>>  DMAR: [DMA Read] Request device [03:00.0] fault addr de28a000 [fault 
>> reason 01] Present bit in root entry is clear
>>  
>>  xhci_hcd :03:00.0: can't setup: -110
>>  xhci_hcd :03:00.0: USB bus 2 deregistered
>>  xhci_hcd :03:00.0: init :03:00.0 fail, -110
>>  xhci_hcd: probe of :03:00.0 failed with error -110
>>
>> The controller works fine, as far as I can tell, when the IOMMU is off.
>>
>> I've tracked it down to where CMD_RESET is sent to the controller in 
>> xhci_reset,
>> [1] called from xhci_gen_setup in xhci.c. It seems that when the command 
>> register
>> is being polled in the xhci_handshake after that, the controller tries to do 
>> a
>> DMA read from an address that is apparently invalid (?). Eventually 
>> xhci_handshake
>> times out.
>>
>> I've tried setting the XHCI_NO_64BIT_SUPPORT quirks flag as someone 
>> suggested in
>> an earlier thread here [2] about a similar/the same(?) device, but that 
>> doesn't
>> seem to have worked.
>>
>> Help, please. I have no idea how to debug this further.
>>
> 
> Could it maybe be related to a iommu/vt-d: Fix scatterlist offset handling 
> fix:
> https://lists.linuxfoundation.org/pipermail/iommu/2017-September/024371.html
> 
> Can you check if that patch is included?

I applied that patch on top of current stable (v4.13.5) and mainline (v4.14-rc4)
but it doesn't appear to have changed anything. Hmm.

Further searching shows that this probably isn't an IOMMU bug but rather some
quirk of the controller itself, probably (?). This bug on Red Hat's bugtracker
shows AMD IOMMU faults with the VL805 too.

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1409098 

> The author Robin Murphy (CC) Also had some recent issues with a VIA VL805 
> controller
> 
> https://marc.info/?l=linux-usb=150730678304383=2

Yeah, that looks like the same thing.. Robin, any luck with your VL805 card?

Thanks.

> -Mathias
-- 
Hao Wei
--
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: musb: sunxi: Explicitly release USB PHY on exit

[Bin Liu]

Hi,

On Tue, Sep 26, 2017 at 09:39:23PM +1000, Jonathan Liu wrote:
> This fixes a kernel oops when unloading the driver due to usb_put_phy
> being called after usb_phy_generic_unregister when the device is
> detached. Calling usb_phy_generic_unregister causes x->dev->driver to
> be NULL in usb_put_phy and results in a NULL pointer dereference.
> 
> As we are now explicitly managing the lifetime of usb_phy,
> devm_usb_get_phy is changed to usb_get_phy and we call usb_put_phy in
> the probe error path.
> 
> Cc: sta...@vger.kernel.org # v4.3+
> Signed-off-by: Jonathan Liu 
> ---
>  drivers/usb/musb/sunxi.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
> index c9a09b5bb6e5..8eed61042103 100644
> --- a/drivers/usb/musb/sunxi.c
> +++ b/drivers/usb/musb/sunxi.c
> @@ -297,6 +297,8 @@ static int sunxi_musb_exit(struct musb *musb)
>   if (test_bit(SUNXI_MUSB_FL_HAS_SRAM, >flags))
>   sunxi_sram_release(musb->controller->parent);
>  
> + usb_put_phy(glue->xceiv);

Will devm_usb_put_phy() solve the issue too? Then you don't need the
changes in sunxi_musb_probe() below.

> +
>   return 0;
>  }
>  
> @@ -781,7 +783,7 @@ static int sunxi_musb_probe(struct platform_device *pdev)
>   return PTR_ERR(glue->usb_phy);
>   }
>  
> - glue->xceiv = devm_usb_get_phy(>dev, USB_PHY_TYPE_USB2);
> + glue->xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
>   if (IS_ERR(glue->xceiv)) {
>   ret = PTR_ERR(glue->xceiv);
>   dev_err(>dev, "Error getting usb-phy %d\n", ret);
> @@ -803,11 +805,13 @@ static int sunxi_musb_probe(struct platform_device 
> *pdev)
>   if (IS_ERR(glue->musb_pdev)) {
>   ret = PTR_ERR(glue->musb_pdev);
>   dev_err(>dev, "Error registering musb dev: %d\n", ret);
> - goto err_unregister_usb_phy;
> + goto err_put_usb_phy;
>   }
>  
>   return 0;
>  
> +err_put_usb_phy:
> + usb_put_phy(glue->xceiv);
>  err_unregister_usb_phy:
>   usb_phy_generic_unregister(glue->usb_phy);
>   return ret;
> -- 
> 2.13.2

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: dwc2 - ChHltd set, but reason is unknown

[Minas Harutyunyan]

Hi Anders,

On 10/9/2017 5:15 PM, Anders Montonen wrote:
> Hi,
>
> We have a custom Altera Cyclone V SoCFPGA board, where connecting a
> particular brand of USB memory sticks produces and enless stream of
> console errors messages until it is removed from the system.
>
> On the board, the SoC has a fixed connection to a Microchip LAN9152
> Ethernet/hub device with two downstream ports. Apart from this issue,
> every other device we have connected appears to work fine.
>
> The sticks are "Intenso Rainbow Line"-branded generic memory sticks using
> an Alcor Micro controller with VID/PID 0x058f/0x6387. The device
> descriptor has a bcdDevice field of 1.ff, but otherwise look valid. The
> sticks work fine on every other host I've tried, both Windows and desktop
> and embedded Linux (none with the dwc2 controller though). The stick also
> works with our board if I add another USB hub in between.
>
> I've reproduced this with kernels 4.9.39 and 4.13.5. The controller is
> configured as host-only. Any suggestions on how to proceed? I noticed that
> unusual_devs.h contained an entry for another device with the same VID/PID
> pair, but adding the same quirks for this device did not help.
>
> Regards,
> Anders Montonen
>
> usb 1-1.2: new high-speed USB device number 4 using dwc2
> dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 13 - ChHltd set, but
> reason is unknown
> dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
> dwc2 ffb4.usb: dwc2_update_urb_state_abn(): trimming xfer length
> dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 5 - ChHltd set, but
> reason is unknown
> dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
> dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 11 - ChHltd set, but
> reason is unknown
> dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
> dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 7 - ChHltd set, but
> reason is unknown
> dwc2 ffb4.usb: hcint 0x0002, intsts 0x04600029
> usb 1-1.2: New USB device found, idVendor=058f, idProduct=6387
> usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> usb 1-1.2: Product: Intenso Rainbow Line
> usb 1-1.2: Manufacturer: 6989
> usb 1-1.2: SerialNumber: 194D3F5F
> usb-storage 1-1.2:1.0: USB Mass Storage device detected
> scsi host0: usb-storage 1-1.2:1.0
> dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 5 - ChHltd set, but
> reason is unknown
> dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
> dwc2 ffb4.usb: dwc2_update_urb_state_abn(): trimming xfer length
> dwc2 ffb4.usb: dwc2_update_urb_state(): trimming xfer length
> dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 11 - ChHltd set, but
> reason is unknown
> dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
> dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 12 - ChHltd set, but
> reason is unknown
> dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
> dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 1 - ChHltd set, but
> reason is unknown
> dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
> dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 15 - ChHltd set, but
> reason is unknown
> dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
> dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 14 - ChHltd set, but
> reason is unknown
> dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
> dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 11 - ChHltd set, but
> reason is unknown
> dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
> dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 0 - ChHltd set, but
> reason is unknown
> dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
> dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 8 - ChHltd set, but
> reason is unknown
> dwc2 ffb4.usb: hcint 0x0002, intsts 0x06600029
> dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 11 - ChHltd set, but
> reason is unknown
> dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
> dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 8 - ChHltd set, but
> reason is unknown
> dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
> dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 8 - ChHltd set, but
> reason is unknown
> dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
> dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 7 - ChHltd set, but
> reason is unknown
> dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
> dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 7 - ChHltd set, but
> reason is unknown
> dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
> dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 5 - ChHltd set, but
> reason is unknown
> dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
> dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 2 - ChHltd set, but
> reason is unknown
> dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
> dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 10 - ChHltd set, but
> reason is unknown
> dwc2 ffb4.usb: hcint 

Re: [PATCH v4 2/3] usb: host: add a generic platform USB roothub driver

[Mathias Nyman]

On 07.10.2017 20:08, Martin Blumenstingl wrote:

Hi Mathias,

thank you for taking the time to go through my patch

On Wed, Oct 4, 2017 at 3:05 PM, Mathias Nyman
 wrote:

On 04.09.2017 00:38, Martin Blumenstingl wrote:


Many SoC platforms have separate devices for the USB PHY which are
registered through the generic PHY framework. These PHYs have to be
enabled to make the USB controller actually work. They also have to be
disabled again on shutdown/suspend.

Currently (at least) the following HCI platform drivers are using custom
code to obtain all PHYs via devicetree for the roothub/controller and
disable/enable them when required:
- ehci-platform.c has ehci_platform_power_{on,off}
- xhci-mtk.c has xhci_mtk_phy_{init,exit,power_on,power_off}
- ohci-platform.c has ohci_platform_power_{on,off}

These drivers are not using the generic devicetree USB device bindings
yet which were only introduced recently (documentation is available in
devicetree/bindings/usb/usb-device.txt).
With this new driver the usb2-phy and usb3-phy can be specified directly
in the child-node of the corresponding port of the roothub via
devicetree. This can be extended by not just parsing PHYs (some of the
other drivers listed above are for example also parsing a list of clocks
as well) when required.



usb_add_hcd() in usb/core/hcd.c is already finding, initializing and turning
on a phy, would it make sense to expand that one to support several phys
instead?

xhci will add two hcd's one for USB2 and one for USB3

that is a great suggestion - thank you for bringing this up!
as a benefit we would add multiple PHY support for all the other
use-cases I found (at least: ehci-platform.c, xhci-mtk.c,
ohci-platform.c) - instead of just handling this in xhci-plat.c

I have one quick question regarding usb/core/hcd.c:
are hcd_bus_suspend() and hcd_bus_resume() the right places to
power_{off,on} the PHYs during suspend?
(currently usb/core/hcd.c doesn't touch the PHY during suspend/resume
- xhci-mtk.c on the other hand seems to require it during a
suspend/resume cycle)


I'm not sure what would be the correct place, hcd_bus_suspend() will be called
twice for xhci, oce for each hcd, so then we need to make sure we only turn off
phys related to that hcd. Host controller can still be running when bus is 
suspended.

xhci-mtk turns off phy when host controller is suspended and stopped.




So if the first 10 ports have the same phy, and 11th and 12th have an other
one, won't we end up
with a phy list with 12 entries for 2 phys, and initialize and turn on the
same first phy 10 times?

indeed, we would call phy_init() and phy_power_on() multiple times on
the same PHY.
however, this is not an issue since the PHY framework is doing
ref-counting for us (see [0] and [1] - the PHY driver's .init() and
.power_on() callbacks will only be called once for each PHY in your
scenario)


Ok


do you see any other issues with this?



Not really, fine by me.


I'm also not sure I understand the reason for having the "usb3-phy" and
"usb2-phy" phy-names
for the ports if we anyways just add everything to one list.

the PHY devicetree bindings state that the "phy-names" property is
mandatory: [2]

when moving the whole multiple PHY logic to usb_add_hcd() then it even
makes sense to look for specific PHYs (imho):
- let's assume we have a XHCI controller with two ports
- both ports have a USB2 PHY, but only one has a USB3 PHY
- (this basically describes the situation on the Amlogic Meson GXL
SoCs, Mediatek uses similar designs)

this would result in the following flow:
1. usb_add_hcd is called for the high-speed HCD
2. we would parse the PHYs for the high-speed HCD
3. usb_add_hcd is called for the super-speed HCD
4. we would parse the PHYs for the super-speed HCD
depending on how we parse the PHYs (mapping the controller-type to
phy-name "usb2-phy" or "usb3-phy") we either end up with:
- 3 PHY handles (2x USB2, 1x USB3) if we take the
controller-type/phy-name into account
- 6 PHY handles (doubling the amount from the use-case above) if we don't

please let me know if there is an easier solution - I prefer simple
code myself, so I don't want to add complexity where it's not needed.


Ah, ok, I'm used to the ACPI tables way of listing ports where a physical USB3 
connector
(HS & SS) is actually described as two separate ports. one HS and one SS.
With this layout one port can have only one PHY.

The Amlogic Meson GXL with two physical USB connectors (USB2&3 and USB2 only)
would look something like this in ACPI:

Device (RHUB) {
...
Device (HS01) {...}
Device (HS02) {...}
Device (SS01) {...}

xhci register layout is similar.
Each port has its own port status/control register.
Depending on if a USB2 or USB3 device is connected to a physical connector it 
will trigger
different port status registers.

Not sure which way is better.

-Mathias

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 

dwc2 - ChHltd set, but reason is unknown

[Anders Montonen]

Hi,

We have a custom Altera Cyclone V SoCFPGA board, where connecting a 
particular brand of USB memory sticks produces and enless stream of 
console errors messages until it is removed from the system.


On the board, the SoC has a fixed connection to a Microchip LAN9152 
Ethernet/hub device with two downstream ports. Apart from this issue, 
every other device we have connected appears to work fine.


The sticks are "Intenso Rainbow Line"-branded generic memory sticks using 
an Alcor Micro controller with VID/PID 0x058f/0x6387. The device 
descriptor has a bcdDevice field of 1.ff, but otherwise look valid. The 
sticks work fine on every other host I've tried, both Windows and desktop 
and embedded Linux (none with the dwc2 controller though). The stick also 
works with our board if I add another USB hub in between.


I've reproduced this with kernels 4.9.39 and 4.13.5. The controller is 
configured as host-only. Any suggestions on how to proceed? I noticed that 
unusual_devs.h contained an entry for another device with the same VID/PID 
pair, but adding the same quirks for this device did not help.


Regards,
Anders Montonen

usb 1-1.2: new high-speed USB device number 4 using dwc2
dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 13 - ChHltd set, but 
reason is unknown

dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
dwc2 ffb4.usb: dwc2_update_urb_state_abn(): trimming xfer length
dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 5 - ChHltd set, but 
reason is unknown

dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 11 - ChHltd set, but 
reason is unknown

dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 7 - ChHltd set, but 
reason is unknown

dwc2 ffb4.usb: hcint 0x0002, intsts 0x04600029
usb 1-1.2: New USB device found, idVendor=058f, idProduct=6387
usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1.2: Product: Intenso Rainbow Line
usb 1-1.2: Manufacturer: 6989
usb 1-1.2: SerialNumber: 194D3F5F
usb-storage 1-1.2:1.0: USB Mass Storage device detected
scsi host0: usb-storage 1-1.2:1.0
dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 5 - ChHltd set, but 
reason is unknown

dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
dwc2 ffb4.usb: dwc2_update_urb_state_abn(): trimming xfer length
dwc2 ffb4.usb: dwc2_update_urb_state(): trimming xfer length
dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 11 - ChHltd set, but 
reason is unknown

dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 12 - ChHltd set, but 
reason is unknown

dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 1 - ChHltd set, but 
reason is unknown

dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 15 - ChHltd set, but 
reason is unknown

dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 14 - ChHltd set, but 
reason is unknown

dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 11 - ChHltd set, but 
reason is unknown

dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 0 - ChHltd set, but 
reason is unknown

dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 8 - ChHltd set, but 
reason is unknown

dwc2 ffb4.usb: hcint 0x0002, intsts 0x06600029
dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 11 - ChHltd set, but 
reason is unknown

dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 8 - ChHltd set, but 
reason is unknown

dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 8 - ChHltd set, but 
reason is unknown

dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 7 - ChHltd set, but 
reason is unknown

dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 7 - ChHltd set, but 
reason is unknown

dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 5 - ChHltd set, but 
reason is unknown

dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 2 - ChHltd set, but 
reason is unknown

dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 10 - ChHltd set, but 
reason is unknown

dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
dwc2 ffb4.usb: dwc2_hc_chhltd_intr_dma: Channel 2 - ChHltd set, but 
reason is unknown

dwc2 ffb4.usb: hcint 0x0002, intsts 0x0469
dwc2 ffb4.usb: 

Re: [PATCH resend 02/12] usb: typec: add basic typec properties

[Rob Herring]

On Mon, Oct 9, 2017 at 6:21 AM, Jun Li  wrote:
> Hi Rob,
>
>> -Original Message-
>> From: Rob Herring [mailto:r...@kernel.org]
>> Sent: Friday, October 06, 2017 4:44 AM
>> To: Jun Li 
>> Cc: gre...@linuxfoundation.org; li...@roeck-us.net; mark.rutl...@arm.com;
>> heikki.kroge...@linux.intel.com; yue...@google.com; o_leve...@orange.fr;
>> Peter Chen ; A.s. Dong ; linux-
>> u...@vger.kernel.org; devicet...@vger.kernel.org
>> Subject: Re: [PATCH resend 02/12] usb: typec: add basic typec properties
>>
>> On Tue, Sep 26, 2017 at 12:05:13PM +0800, Li Jun wrote:
>> > port-type is required for any typec port; default-role is only
>> > required for drp; power source capable needs src-pdos; power sink
>> > capable needs snk-pdos, max-snk-mv, max-snk-ma, op-snk-mw.
>>
>> "dt-bindings: usb: ..." for the subject prefix.
>>
>
> Will update in next version.
>
>> >
>> > Signed-off-by: Li Jun 
>> > ---
>> >  Documentation/devicetree/bindings/usb/typec.txt | 46
>> > +
>> >  1 file changed, 46 insertions(+)
>> >
>> > diff --git a/Documentation/devicetree/bindings/usb/typec.txt
>> > b/Documentation/devicetree/bindings/usb/typec.txt
>> > new file mode 100644
>> > index 000..36d4467
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/usb/typec.txt
>> > @@ -0,0 +1,46 @@
>> > +Generic typec and power delivery properties
>> > +---
>>
>> What node do these apply to? A type C connector node? The PD microcontroller?
>>
>
> My initial thinking is those are general type-c properties, which can be 
> applied to
> type-C connector or used by PD microcontroller directly (my example),  I want
> to get inputs on how this can be handled properly, so do you think a separated
> node(e.g. type-c connector) is required to describe all the capability of the 
> type-c
> port has, then a type-c related driver get the phandle of it?
>
>> I'm reluctant to accept just a random list of properties without a more 
>> complete
>> Type-C binding which I'd expect to have a connector node, OF graph ports to
>> connect to video outputs, connection to USB controller, and connection to the
>> PD controller.
>>
>
> As type-C with PD has many properties to complete the description for diff 
> usage,
> so this is just a first step to have the basic power related bindings.

We need something more complete, not something that just evolves. At
least the basic relationships between connectors, PD controller,
alternate modes, and USB controllers needs to be defined.

Andrzej started on defining USB connectors[1]. That's where we need to
start for Type-C bindings. Work together on this.

Rob

>> > +Required properties:
>> > +- port-type:should be one of "source", "sink" or "dual".
>> > +- default-role: preferred power role if drp, should be "sink" or "source".
>> > +- src-pdos: An array of u32 with each entry providing supported power
>> > +source data object(PDO), the detailed bit definitions of
>> > +PDO can be found in "Universal Serial Bus Power Delivery
>> > +Specification" chapter 6.4.1.2 Source_Capabilities 
>> > Message,
>> > +the order of each entry(PDO) should follow the PD spec 
>> > chapter
>> > +6.4.1. Required only for power source and power dual role 
>> > with
>> > +power delivery support.
>> > +- snk-pdos: An array of u32 with each entry providing supported power
>> > +sink data object(PDO), the detailed bit definitions of PDO
>> > +can be found in "Universal Serial Bus Power Delivery
>> > +Specification" chapter 6.4.1.3 Sink Capabilities Message,
>> > +the order of each entry(PDO) should follow the PD spec 
>> > chapter
>> > +6.4.1. Required only for power sink and power dual role 
>> > with
>> > +power delivery support.
>>
>> > +- max-snk-mv:   The max voltage the sink can support in millivoltage, 
>> > required
>> > +only for power sink and power dual role with power 
>> > delivery
>> > +support.
>> > +- max-snk-ma:   The max current the sink can support in milliampere, 
>> > required
>> > +only for power sink and power dual role with power 
>> > delivery
>> > +support.
>> > +- op-snk-mw:Sink required operating power in milliwatts, if source 
>> > offered
>> > +power is less then it, Capability Mismatch is set, 
>> > required
>> > +only for power sink and power dual role with power 
>> > delivery
>> > +support.
>>
>> Use the standard unit suffixes as defined in property-units.txt
>>
>
> Thanks, will update in next version.
>
> Li Jun
>> > +
>> > +Example:
>> > +
>> > +ptn5110@50 {
>> > +   compatible = "usb,tcpci";
>> > +   reg = <0x50>;
>> > +   

[PATCH] cdc_ether: flag the u-blox TOBY-L2 and SARA-U2 as wwan

[Aleksander Morgado]

The u-blox TOBY-L2 is a LTE Cat 4 module with HSPA+ and 2G fallback.
This module allows switching to different USB profiles with the
'AT+UUSBCONF' command, and provides a ECM network interface when the
'AT+UUSBCONF=2' profile is selected.

The u-blox SARA-U2 is a HSPA module with 2G fallback. The default USB
configuration includes a ECM network interface.

Both these modules are controlled via AT commands through one of the
TTYs exposed. Connecting these modules may be done just by activating
the desired PDP context with 'AT+CGACT=1,' and then running DHCP
on the ECM interface.

Signed-off-by: Aleksander Morgado 
---
 drivers/net/usb/cdc_ether.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 29c7e2ec0dcb..52ea80bcd639 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -560,6 +560,7 @@ static const struct driver_info wwan_info = {
 #define NVIDIA_VENDOR_ID   0x0955
 #define HP_VENDOR_ID   0x03f0
 #define MICROSOFT_VENDOR_ID0x045e
+#define UBLOX_VENDOR_ID0x1546
 
 static const struct usb_device_id  products[] = {
 /* BLACKLIST !!
@@ -868,6 +869,18 @@ static const struct usb_device_id  products[] = {
  USB_CDC_SUBCLASS_ETHERNET,
  USB_CDC_PROTO_NONE),
.driver_info = (unsigned long)_cdc_info,
+}, {
+   /* U-blox TOBY-L2 */
+   USB_DEVICE_AND_INTERFACE_INFO(UBLOX_VENDOR_ID, 0x1143, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET,
+ USB_CDC_PROTO_NONE),
+   .driver_info = (unsigned long)_info,
+}, {
+   /* U-blox SARA-U2 */
+   USB_DEVICE_AND_INTERFACE_INFO(UBLOX_VENDOR_ID, 0x1104, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_ETHERNET,
+ USB_CDC_PROTO_NONE),
+   .driver_info = (unsigned long)_info,
 }, {
USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_ETHERNET,
USB_CDC_PROTO_NONE),
-- 
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

[PATCHv4 0/2] dwc3 on XU3

[Andrzej Pietrasiewicz]

Hi all,

This is the fourth version of patches in this thread.

The series fixes problems with enumerating of SuperSpeed devices
on an Odroid XU3. There was a patch series from Vivek Gautam in
circulation, but it got lost somehow. Please see:

https://lkml.org/lkml/2014/9/2/166
https://lkml.org/lkml/2015/2/2/257

I adapted his patch so that it does not use a hacky solution to force
additional initialization in order for calibration to happen.
With this patch enumeration happens correctly and a super speed device
is recognized as such.

Changes since v3:

- improved the commit message in phy_calibrate() commit
  (as suggested by Kishon)
- rebased onto v4.14-rc4

Changes since v2:

- exported the "calibrate_phy" symbol

Changes since v1:

- added calibrate() callback to phy
- used calibrate() instead of reset() to trigger the calibration

Andrzej Pietrasiewicz (1):
  drivers: phy: add calibrate method

Vivek Gautam (1):
  phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

 drivers/phy/phy-core.c   |  15 +++
 drivers/phy/samsung/phy-exynos5-usbdrd.c | 183 +++
 drivers/usb/dwc3/core.c  |   7 +-
 include/linux/phy/phy.h  |  10 ++
 4 files changed, 213 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

[PATCHv4 1/2] drivers: phy: add calibrate method

[Andrzej Pietrasiewicz]

Some quirky UDCs (like dwc3 on Exynos) need to have their phys calibrated e.g.
for using super speed. This patch adds a new phy_calibrate() method.
When the calibration should be used is dependent on actual chip.

In case of dwc3 on Exynos the calibration must happen after usb_add_hcd()
(while in host mode), because certain phy parameters like Tx LOS levels
and boost levels need to be calibrated further post initialization of xHCI
controller, to get SuperSpeed operations working. But an hcd must be
prepared first in order to pass it to usb_add_hcd(), so, in particular, dwc3
registers must be available first, and in order for the latter to happen
the phys must be initialized. This poses a chicken and egg problem if
the calibration were to be performed in phy_init(). To break the circular
dependency a separate method is added which can be called at a desired
moment after phy intialization.

Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/phy/phy-core.c  | 15 +++
 include/linux/phy/phy.h | 10 ++
 2 files changed, 25 insertions(+)

diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index a268f4d..b4964b0 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -372,6 +372,21 @@ int phy_reset(struct phy *phy)
 }
 EXPORT_SYMBOL_GPL(phy_reset);
 
+int phy_calibrate(struct phy *phy)
+{
+   int ret;
+
+   if (!phy || !phy->ops->calibrate)
+   return 0;
+
+   mutex_lock(>mutex);
+   ret = phy->ops->calibrate(phy);
+   mutex_unlock(>mutex);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(phy_calibrate);
+
 /**
  * _of_phy_get() - lookup and obtain a reference to a phy by phandle
  * @np: device_node for which to get the phy
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index e694d40..87580c8 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -39,6 +39,7 @@ enum phy_mode {
  * @power_off: powering off the phy
  * @set_mode: set the mode of the phy
  * @reset: resetting the phy
+ * @calibrate: calibrate the phy
  * @owner: the module owner containing the ops
  */
 struct phy_ops {
@@ -48,6 +49,7 @@ struct phy_ops {
int (*power_off)(struct phy *phy);
int (*set_mode)(struct phy *phy, enum phy_mode mode);
int (*reset)(struct phy *phy);
+   int (*calibrate)(struct phy *phy);
struct module *owner;
 };
 
@@ -141,6 +143,7 @@ static inline void *phy_get_drvdata(struct phy *phy)
 int phy_power_off(struct phy *phy);
 int phy_set_mode(struct phy *phy, enum phy_mode mode);
 int phy_reset(struct phy *phy);
+int phy_calibrate(struct phy *phy);
 static inline int phy_get_bus_width(struct phy *phy)
 {
return phy->attrs.bus_width;
@@ -262,6 +265,13 @@ static inline int phy_reset(struct phy *phy)
return -ENOSYS;
 }
 
+static inline int phy_calibrate(struct phy *phy)
+{
+   if (!phy)
+   return 0;
+   return -ENOSYS;
+}
+
 static inline int phy_get_bus_width(struct phy *phy)
 {
return -ENOSYS;
-- 
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

[PATCHv4 2/2] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800

[Andrzej Pietrasiewicz]

From: Vivek Gautam 

Adding phy calibration sequence for USB 3.0 DRD PHY present on
Exynos5420/5800 systems.
This calibration facilitates setting certain PHY parameters viz.
the Loss-of-Signal (LOS) Detector Threshold Level, as well as
Tx-Vboost-Level for Super-Speed operations.
Additionally we also set proper time to wait for RxDetect measurement,
for desired PHY reference clock, so as to solve issue with enumeration
of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive
on the controller.

We are using CR_port for this purpose to send required data
to override the LOS values.

On testing with USB 3.0 devices on USB 3.0 port present on
SMDK5420, and peach-pit boards should see following message:
usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd

and without this patch, should see below shown message:
usb 1-1: new high-speed USB device number 2 using xhci-hcd

[Also removed unnecessary extra lines in the register macro definitions]

Signed-off-by: Vivek Gautam 
[adapted to use phy_calibrate as entry point]
Signed-off-by: Andrzej Pietrasiewicz 
---
 drivers/phy/samsung/phy-exynos5-usbdrd.c | 183 +++
 drivers/usb/dwc3/core.c  |   7 +-
 2 files changed, 188 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/samsung/phy-exynos5-usbdrd.c 
b/drivers/phy/samsung/phy-exynos5-usbdrd.c
index 22c68f5..9e83c15 100644
--- a/drivers/phy/samsung/phy-exynos5-usbdrd.c
+++ b/drivers/phy/samsung/phy-exynos5-usbdrd.c
@@ -90,7 +90,17 @@
 #define PHYCLKRST_COMMONONNBIT(0)
 
 #define EXYNOS5_DRD_PHYREG00x14
+#define PHYREG0_SSC_REF_CLK_SELBIT(21)
+#define PHYREG0_SSC_RANGE  BIT(20)
+#define PHYREG0_CR_WRITE   BIT(19)
+#define PHYREG0_CR_READBIT(18)
+#define PHYREG0_CR_DATA_IN(_x) ((_x) << 2)
+#define PHYREG0_CR_CAP_DATABIT(1)
+#define PHYREG0_CR_CAP_ADDRBIT(0)
+
 #define EXYNOS5_DRD_PHYREG10x18
+#define PHYREG1_CR_DATA_OUT(_x)((_x) << 1)
+#define PHYREG1_CR_ACK BIT(0)
 
 #define EXYNOS5_DRD_PHYPARAM0  0x1c
 
@@ -119,6 +129,25 @@
 #define EXYNOS5_DRD_PHYRESUME  0x34
 #define EXYNOS5_DRD_LINKPORT   0x44
 
+/* USB 3.0 DRD PHY SS Function Control Reg; accessed by CR_PORT */
+#define EXYNOS5_DRD_PHYSS_LOSLEVEL_OVRD_IN (0x15)
+#define LOSLEVEL_OVRD_IN_LOS_BIAS_5420 (0x5 << 13)
+#define LOSLEVEL_OVRD_IN_LOS_BIAS_DEFAULT  (0x0 << 13)
+#define LOSLEVEL_OVRD_IN_EN(0x1 << 10)
+#define LOSLEVEL_OVRD_IN_LOS_LEVEL_DEFAULT (0x9 << 0)
+
+#define EXYNOS5_DRD_PHYSS_TX_VBOOSTLEVEL_OVRD_IN   (0x12)
+#define TX_VBOOSTLEVEL_OVRD_IN_VBOOST_5420 (0x5 << 13)
+#define TX_VBOOSTLEVEL_OVRD_IN_VBOOST_DEFAULT  (0x4 << 13)
+
+#define EXYNOS5_DRD_PHYSS_LANE0_TX_DEBUG   (0x1010)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_19M2_20M(0x4 << 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_24M (0x8 << 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_25M_26M (0x8 << 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_48M_50M_52M (0x20 << 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_62M5(0x20 << 4)
+#define LANE0_TX_DEBUG_RXDET_MEAS_TIME_96M_100M(0x40 << 4)
+
 #define KHZ1000
 #define MHZ(KHZ * KHZ)
 
@@ -527,6 +556,151 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
return 0;
 }
 
+static int crport_handshake(struct exynos5_usbdrd_phy *phy_drd,
+   u32 val, u32 cmd)
+{
+   u32 usec = 100;
+   unsigned int result;
+
+   writel(val | cmd, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
+
+   do {
+   result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
+   if (result & PHYREG1_CR_ACK)
+   break;
+
+   udelay(1);
+   } while (usec-- > 0);
+
+   if (!usec) {
+   dev_err(phy_drd->dev,
+   "CRPORT handshake timeout1 (0x%08x)\n", val);
+   return -ETIME;
+   }
+
+   usec = 100;
+
+   writel(val, phy_drd->reg_phy + EXYNOS5_DRD_PHYREG0);
+
+   do {
+   result = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYREG1);
+   if (!(result & PHYREG1_CR_ACK))
+   break;
+
+   udelay(1);
+   } while (usec-- > 0);
+
+   if (!usec) {
+   dev_err(phy_drd->dev,
+   "CRPORT handshake timeout2 (0x%08x)\n", val);
+   return -ETIME;
+   }
+
+   return 0;
+}
+
+static int crport_ctrl_write(struct exynos5_usbdrd_phy *phy_drd,
+   u32 addr, u32 

Re: [GIT PULL] USB-serial fixes for v4.14-rc5

[Johan Hovold]

On Mon, Oct 09, 2017 at 01:21:14PM +0200, Greg Kroah-Hartman wrote:
> On Mon, Oct 09, 2017 at 12:40:00PM +0200, Johan Hovold wrote:
> > The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e:
> > 
> >   Linux 4.14-rc1 (2017-09-16 15:47:51 -0700)
> > 
> > are available in the git repository at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git 
> > tags/usb-serial-4.14-rc5
> > 
> > for you to fetch changes up to 299d7572e46f98534033a9e65973f13ad1ce9047:
> > 
> >   USB: serial: console: fix use-after-free after failed setup (2017-10-09 
> > 12:33:31 +0200)
> > 
> > 
> > USB-serial fixes for v4.14-rc5
> > 
> > Here's a fix for a cp210x regression that prevented a class of devices
> > from being successfully probed. Two use-after-free bugs in the console
> > code are also fixed.
> > 
> > Included are also some new device ids.
> > 
> > All but the last three commits have been in linux-next with no reported
> > issues.
> 
> Note, there is no linux-next for all of October, so it would be hard to
> any failed reports :)

Yeah, I saw the notice. But all but the last three commits were applied
in September and have actually gotten some testing there.

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 resend 02/12] usb: typec: add basic typec properties

[Jun Li]

Hi Rob,

> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Friday, October 06, 2017 4:44 AM
> To: Jun Li 
> Cc: gre...@linuxfoundation.org; li...@roeck-us.net; mark.rutl...@arm.com;
> heikki.kroge...@linux.intel.com; yue...@google.com; o_leve...@orange.fr;
> Peter Chen ; A.s. Dong ; linux-
> u...@vger.kernel.org; devicet...@vger.kernel.org
> Subject: Re: [PATCH resend 02/12] usb: typec: add basic typec properties
> 
> On Tue, Sep 26, 2017 at 12:05:13PM +0800, Li Jun wrote:
> > port-type is required for any typec port; default-role is only
> > required for drp; power source capable needs src-pdos; power sink
> > capable needs snk-pdos, max-snk-mv, max-snk-ma, op-snk-mw.
> 
> "dt-bindings: usb: ..." for the subject prefix.
> 

Will update in next version.

> >
> > Signed-off-by: Li Jun 
> > ---
> >  Documentation/devicetree/bindings/usb/typec.txt | 46
> > +
> >  1 file changed, 46 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/usb/typec.txt
> > b/Documentation/devicetree/bindings/usb/typec.txt
> > new file mode 100644
> > index 000..36d4467
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/usb/typec.txt
> > @@ -0,0 +1,46 @@
> > +Generic typec and power delivery properties
> > +---
> 
> What node do these apply to? A type C connector node? The PD microcontroller?
> 

My initial thinking is those are general type-c properties, which can be 
applied to
type-C connector or used by PD microcontroller directly (my example),  I want
to get inputs on how this can be handled properly, so do you think a separated
node(e.g. type-c connector) is required to describe all the capability of the 
type-c
port has, then a type-c related driver get the phandle of it? 

> I'm reluctant to accept just a random list of properties without a more 
> complete
> Type-C binding which I'd expect to have a connector node, OF graph ports to
> connect to video outputs, connection to USB controller, and connection to the
> PD controller.
> 

As type-C with PD has many properties to complete the description for diff 
usage,
so this is just a first step to have the basic power related bindings.

> > +
> > +Required properties:
> > +- port-type:should be one of "source", "sink" or "dual".
> > +- default-role: preferred power role if drp, should be "sink" or "source".
> > +- src-pdos: An array of u32 with each entry providing supported power
> > +source data object(PDO), the detailed bit definitions of
> > +PDO can be found in "Universal Serial Bus Power Delivery
> > +Specification" chapter 6.4.1.2 Source_Capabilities Message,
> > +the order of each entry(PDO) should follow the PD spec 
> > chapter
> > +6.4.1. Required only for power source and power dual role 
> > with
> > +power delivery support.
> > +- snk-pdos: An array of u32 with each entry providing supported power
> > +sink data object(PDO), the detailed bit definitions of PDO
> > +can be found in "Universal Serial Bus Power Delivery
> > +Specification" chapter 6.4.1.3 Sink Capabilities Message,
> > +the order of each entry(PDO) should follow the PD spec 
> > chapter
> > +6.4.1. Required only for power sink and power dual role 
> > with
> > +power delivery support.
> 
> > +- max-snk-mv:   The max voltage the sink can support in millivoltage, 
> > required
> > +only for power sink and power dual role with power delivery
> > +support.
> > +- max-snk-ma:   The max current the sink can support in milliampere, 
> > required
> > +only for power sink and power dual role with power delivery
> > +support.
> > +- op-snk-mw:Sink required operating power in milliwatts, if source 
> > offered
> > +power is less then it, Capability Mismatch is set, required
> > +only for power sink and power dual role with power delivery
> > +support.
> 
> Use the standard unit suffixes as defined in property-units.txt
> 

Thanks, will update in next version.

Li Jun
> > +
> > +Example:
> > +
> > +ptn5110@50 {
> > +   compatible = "usb,tcpci";
> > +   reg = <0x50>;
> > +   interrupt-parent = <>;
> > +   interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
> > +   port-type = "dual";
> > +   default-role = "sink";
> > +   src-pdos = <0x380190c8>;
> > +   snk-pdos = <0x380190c8 0x3802d0c8>;
> > +   max-snk-mv = <9000>;
> > +   max-snk-ma = <1000>;
> > +   op-snk-mw = <9000>;
> > +};
> > --
> > 2.6.6
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree"
> > in the body of a message to majord...@vger.kernel.org More majordomo
> > info at  http://vger.kernel.org/majordomo-info.html
--
To 

Re: [GIT PULL] USB-serial fixes for v4.14-rc5

[Greg Kroah-Hartman]

On Mon, Oct 09, 2017 at 12:40:00PM +0200, Johan Hovold wrote:
> The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e:
> 
>   Linux 4.14-rc1 (2017-09-16 15:47:51 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git 
> tags/usb-serial-4.14-rc5
> 
> for you to fetch changes up to 299d7572e46f98534033a9e65973f13ad1ce9047:
> 
>   USB: serial: console: fix use-after-free after failed setup (2017-10-09 
> 12:33:31 +0200)
> 
> 
> USB-serial fixes for v4.14-rc5
> 
> Here's a fix for a cp210x regression that prevented a class of devices
> from being successfully probed. Two use-after-free bugs in the console
> code are also fixed.
> 
> Included are also some new device ids.
> 
> All but the last three commits have been in linux-next with no reported
> issues.

Note, there is no linux-next for all of October, so it would be hard to
any failed reports :)

Now pulled and pushed out, thanks.

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

Re: [PATCH 1/2] USB: serial: console: fix use-after-free on disconnect

[Johan Hovold]

On Mon, Oct 09, 2017 at 01:05:30PM +0200, Andrey Konovalov wrote:
> On Wed, Oct 4, 2017 at 11:01 AM, Johan Hovold  wrote:
> > A clean-up patch removing removing two redundant NULL-checks from the
> > console disconnect handler inadvertently also removed a third check.
> > This could lead to the struct usb_serial being prematurely freed by the
> > console code when a driver accepts but does not register any ports for
> > an interface which also lacks endpoint descriptors.
> >
> > Fixes: 0e517c93dc02 ("USB: serial: console: clean up sanity checks")
> > Cc: stable  # 4.11
> > Reported-by: Andrey Konovalov 
> 
> Tested-by: Andrey Konovalov 
> 
> This fixes the crash.

I just forwarded this one in a pull-request to Greg, but thanks for
testing nonetheless.

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 1/2] USB: serial: console: fix use-after-free on disconnect

[Andrey Konovalov]

On Wed, Oct 4, 2017 at 11:01 AM, Johan Hovold  wrote:
> A clean-up patch removing removing two redundant NULL-checks from the
> console disconnect handler inadvertently also removed a third check.
> This could lead to the struct usb_serial being prematurely freed by the
> console code when a driver accepts but does not register any ports for
> an interface which also lacks endpoint descriptors.
>
> Fixes: 0e517c93dc02 ("USB: serial: console: clean up sanity checks")
> Cc: stable  # 4.11
> Reported-by: Andrey Konovalov 

Tested-by: Andrey Konovalov 

This fixes the crash.

Thanks!

> Signed-off-by: Johan Hovold 
> ---
>  drivers/usb/serial/console.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/serial/console.c b/drivers/usb/serial/console.c
> index fdf89800ebc3..ed8ba3ef5c79 100644
> --- a/drivers/usb/serial/console.c
> +++ b/drivers/usb/serial/console.c
> @@ -265,7 +265,7 @@ static struct console usbcons = {
>
>  void usb_serial_console_disconnect(struct usb_serial *serial)
>  {
> -   if (serial->port[0] == usbcons_info.port) {
> +   if (serial->port[0] && serial->port[0] == usbcons_info.port) {
> usb_serial_console_exit();
> usb_serial_put(serial);
> }
> --
> 2.14.2
>
--
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: serial: console: fix use-after-free on disconnect

[Johan Hovold]

On Sat, Oct 07, 2017 at 05:56:17PM +0900, Jaejoong Kim wrote:
> Hi
> 
> 2017-10-04 18:01 GMT+09:00 Johan Hovold :
> > A clean-up patch removing removing two redundant NULL-checks from the
>^^
> The word 'removing' was written twice. :)

Thanks for noticing, now fixed up.

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

[GIT PULL] USB-serial fixes for v4.14-rc5

[Johan Hovold]

The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e:

  Linux 4.14-rc1 (2017-09-16 15:47:51 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git 
tags/usb-serial-4.14-rc5

for you to fetch changes up to 299d7572e46f98534033a9e65973f13ad1ce9047:

  USB: serial: console: fix use-after-free after failed setup (2017-10-09 
12:33:31 +0200)


USB-serial fixes for v4.14-rc5

Here's a fix for a cp210x regression that prevented a class of devices
from being successfully probed. Two use-after-free bugs in the console
code are also fixed.

Included are also some new device ids.

All but the last three commits have been in linux-next with no reported
issues.


Andreas Engel (1):
  USB: serial: cp210x: add support for ELV TFD500

Henryk Heisig (1):
  USB: serial: option: add support for TP-Link LTE module

Jeffrey Chu (1):
  USB: serial: ftdi_sio: add id for Cypress WICED dev board

Johan Hovold (2):
  USB: serial: console: fix use-after-free on disconnect
  USB: serial: console: fix use-after-free after failed setup

Sebastian Frei (1):
  USB: serial: cp210x: fix partnum regression

Shrirang Bagul (1):
  USB: serial: qcserial: add Dell DW5818, DW5819

 drivers/usb/serial/console.c  |  3 ++-
 drivers/usb/serial/cp210x.c   | 13 +++--
 drivers/usb/serial/ftdi_sio.c |  2 ++
 drivers/usb/serial/ftdi_sio_ids.h |  7 +++
 drivers/usb/serial/option.c   |  2 ++
 drivers/usb/serial/qcserial.c |  4 
 6 files changed, 24 insertions(+), 7 deletions(-)
--
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: [RFC usb-next v5 1/3] dt-bindings: usb: add the documentation for USB root-hub

[Arnd Bergmann]

On Sun, Oct 8, 2017 at 11:17 PM, Martin Blumenstingl
 wrote:
> A USB root-hub may have several PHYs which need to be configured before
> the root-hub starts working.
> This adds the documentation for such a USB root-hub as well as a hint
> regarding the child-nodes on XHCI controllers which can include the
> roothub.
>
> Signed-off-by: Martin Blumenstingl 
> Acked-by: Rob Herring 

Have you checked that this still works with DT properties on a USB device
that is listed in the DT? A common use-case is to provide the MAC address
of a soldered-down USB-ethernet that lacks its own eeprom, and it seems
you are changing the way the parent devices of that get represented,
so the dev->of_node pointer in the USB device might no longer refer
to the correct device.

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

Re: [PATCHv3 1/2] drivers: phy: add calibrate method

[Kishon Vijay Abraham I]

Hi,

On Thursday 05 October 2017 05:41 PM, Andrzej Pietrasiewicz wrote:
> Some quirky UDCs (like dwc3 on exynos) need to have heir phys calibrated

%s/heir/their
> e.g. for using super speed.

The commit log should also include when phy calibrate should be used and why
existing API's is not sufficient for initializing/calibrating the phy.

Thanks
Kishon
> 
> Signed-off-by: Andrzej Pietrasiewicz 
> ---
>  drivers/phy/phy-core.c  | 15 +++
>  include/linux/phy/phy.h | 10 ++
>  2 files changed, 25 insertions(+)
> 
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index a268f4d..b4964b0 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -372,6 +372,21 @@ int phy_reset(struct phy *phy)
>  }
>  EXPORT_SYMBOL_GPL(phy_reset);
>  
> +int phy_calibrate(struct phy *phy)
> +{
> + int ret;
> +
> + if (!phy || !phy->ops->calibrate)
> + return 0;
> +
> + mutex_lock(>mutex);
> + ret = phy->ops->calibrate(phy);
> + mutex_unlock(>mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(phy_calibrate);
> +
>  /**
>   * _of_phy_get() - lookup and obtain a reference to a phy by phandle
>   * @np: device_node for which to get the phy
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index e694d40..87580c8 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -39,6 +39,7 @@ enum phy_mode {
>   * @power_off: powering off the phy
>   * @set_mode: set the mode of the phy
>   * @reset: resetting the phy
> + * @calibrate: calibrate the phy
>   * @owner: the module owner containing the ops
>   */
>  struct phy_ops {
> @@ -48,6 +49,7 @@ struct phy_ops {
>   int (*power_off)(struct phy *phy);
>   int (*set_mode)(struct phy *phy, enum phy_mode mode);
>   int (*reset)(struct phy *phy);
> + int (*calibrate)(struct phy *phy);
>   struct module *owner;
>  };
>  
> @@ -141,6 +143,7 @@ static inline void *phy_get_drvdata(struct phy *phy)
>  int phy_power_off(struct phy *phy);
>  int phy_set_mode(struct phy *phy, enum phy_mode mode);
>  int phy_reset(struct phy *phy);
> +int phy_calibrate(struct phy *phy);
>  static inline int phy_get_bus_width(struct phy *phy)
>  {
>   return phy->attrs.bus_width;
> @@ -262,6 +265,13 @@ static inline int phy_reset(struct phy *phy)
>   return -ENOSYS;
>  }
>  
> +static inline int phy_calibrate(struct phy *phy)
> +{
> + if (!phy)
> + return 0;
> + return -ENOSYS;
> +}
> +
>  static inline int phy_get_bus_width(struct phy *phy)
>  {
>   return -ENOSYS;
> 
--
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] usb: phy: tegra: Fix phy suspend for UDC

[Jon Hunter]

Felipe,

On 02/10/17 12:52, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> On Mon, Oct 02, 2017 at 12:22:53PM +0100, Jon Hunter wrote:
>> Commit dfebb5f43a78 ("usb: chipidea: Add support for Tegra20/30/114/124")
>> added UDC support for Tegra but with UDC support enabled, is was found
>> that Tegra30, Tegra114 and Tegra124 would hang on entry to suspend.
>>
>> The hang occurred during the suspend of the USB PHY when the Tegra PHY
>> driver attempted to disable the PHY clock. The problem is that before
>> the Tegra PHY driver is suspended, the chipidea driver already disabled
>> the PHY clock and when the Tegra PHY driver suspended, it could not read
>> DEVLC register and caused the device to hang.
>>
>> The Tegra USB PHY driver is used by both the Tegra EHCI driver and now
>> the chipidea UDC driver and so simply removing the disabling of the PHY
>> clock from the USB PHY driver would not work for the Tegra EHCI driver.
>> Fortunately, the status of the USB PHY clock can be read from the
>> USB_SUSP_CTRL register and therefore, to workaround this issue, simply
>> poll the register prior to disabling the clock in USB PHY driver to see
>> if clock gating has already been initiated. Please note that it can take
>> a few uS for the clock to disable and so simply reading this status
>> register once on entry is not sufficient.
>>
>> Similarly when turning on the PHY clock, it is possible that the clock
>> is already enabled or in the process of being enabled, and so check for
>> this when enabling the PHY.
>>
>> Please note that no issues are seen with Tegra20 because it has a slightly
>> different PHY to Tegra30/114/124.
>>
>> Fixes: dfebb5f43a78 ("usb: chipidea: Add support for Tegra20/30/114/124")
>>
>> Signed-off-by: Jon Hunter 
>> ---
>> Changes since V1:
>> - Added fixes tag
>> - Added test in PHY enable to see if clock is already on before enabling
>>
>>  drivers/usb/phy/phy-tegra-usb.c | 17 +
>>  1 file changed, 17 insertions(+)
> 
> Acked-by: Thierry Reding 
This fix is needed for v4.14, if you are ok with the change, can you
pick this up so we can get this merged?

Cheers
Jon

-- 
nvpublic
--
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: VL805 xHCI DMA read faults

[Mathias Nyman]

On 08.10.2017 17:03, Hao Wei Tee wrote:

Hi,

I've been having DMA read faults with my VL805 xHCI controller when the Intel 
IOMMU
is turned on:

 xhci_hcd :03:00.0: xHCI Host Controller
 xhci_hcd :03:00.0: new USB bus registered, assigned bus number 2
 DMAR: DRHD: handling fault status reg 3
 DMAR: [DMA Read] Request device [03:00.0] fault addr de28a000 [fault 
reason 01] Present bit in root entry is clear
 
 xhci_hcd :03:00.0: can't setup: -110
 xhci_hcd :03:00.0: USB bus 2 deregistered
 xhci_hcd :03:00.0: init :03:00.0 fail, -110
 xhci_hcd: probe of :03:00.0 failed with error -110

The controller works fine, as far as I can tell, when the IOMMU is off.

I've tracked it down to where CMD_RESET is sent to the controller in xhci_reset,
[1] called from xhci_gen_setup in xhci.c. It seems that when the command 
register
is being polled in the xhci_handshake after that, the controller tries to do a
DMA read from an address that is apparently invalid (?). Eventually 
xhci_handshake
times out.

I've tried setting the XHCI_NO_64BIT_SUPPORT quirks flag as someone suggested in
an earlier thread here [2] about a similar/the same(?) device, but that doesn't
seem to have worked.

Help, please. I have no idea how to debug this further.



Could it maybe be related to a iommu/vt-d: Fix scatterlist offset handling fix:
https://lists.linuxfoundation.org/pipermail/iommu/2017-September/024371.html

Can you check if that patch is included?

The author Robin Murphy (CC) Also had some recent issues with a VIA VL805 
controller

https://marc.info/?l=linux-usb=150730678304383=2

-Mathias


Some information about the device in question:

 03:00.0 USB controller [0c03]: VIA Technologies, Inc. VL805 USB 3.0 Host 
Controller [1106:3483] (rev 01) (prog-if 30 [XHCI])
 Subsystem: Gigabyte Technology Co., Ltd VL805 USB 3.0 Host Controller 
[1458:5007]
 Flags: fast devsel, IRQ 17
 Memory at f710 (64-bit, non-prefetchable) [size=4K]
 Capabilities: [80] Power Management version 3
 Capabilities: [90] MSI: Enable- Count=1/4 Maskable- 64bit+
 Capabilities: [c4] Express Endpoint, MSI 00
 Capabilities: [100] Advanced Error Reporting
 Kernel modules: xhci_pci

Thanks.

N.B. I sent a message here a while ago mentioning changes in 4.13 that might be
the cause, but that is not the case. My distro just turned on the IOMMU by 
default
when they updated to 4.13. Oops.

[1]: 
https://elixir.free-electrons.com/linux/v4.13.5/source/drivers/usb/host/xhci.c#L184
[2]: https://www.spinics.net/lists/linux-usb/msg146591.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



--
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: [RFC PATCH 1/4] dt-bindings: add bindings for USB physical connector

[Andrzej Hajda]

On 06.10.2017 19:23, Rob Herring wrote:
> On Fri, Oct 6, 2017 at 6:10 AM, Andrzej Hajda  wrote:
>> Hi Rob,
>>
>> Thanks for review.
>>
>> On 06.10.2017 01:12, Rob Herring wrote:
>>> On Thu, Sep 28, 2017 at 03:07:27PM +0200, Andrzej Hajda wrote:
 These bindings allows to describe most known standard USB connectors
 and it should be possible to extend it if necessary.
 USB connectors, beside USB can be used to route other protocols,
 for example UART, Audio, MHL. In such case every device passing data
 through the connector should have appropriate graph bindings.
>>> Yay!
>>>
 Signed-off-by: Andrzej Hajda 
 ---
 There are few things for discussion (IMO):
 1. vendor specific connectors, I have added them here, but maybe better is
to place them in separate files.
>>> I'd worry about the standard connectors first, but probably good to have
>>> an idea of how vendor connectors need to be extended.
>>>
 2. physical connector description - I have split it to three properties:
type(a,b,ab,c), max-mode(ls,fs,hs,ss,ss+), size(mini,micro,powered).
This tripled is able to describe all USB-standard connectors, but there
are also impossible combinations, for example(c, *, micro). Maybe better
would be to just enumerate all possible connectors in include file.
>>> We did "type" for hdmi-connector, but I think I'd really prefer
>>> compatible be used to distinguish as least where it may matter to s/w.
>>> In the HDMI case, they all are pretty much the same, just different
>>> physical size.
>> I guess that from S/W point of view only matters:
>> - which IP is connected to which part of the connector, and this can be
>> handled by port node(s),
>> - Type: A, B, C
>> - probably maximal supported speed of the connector - for example SS+
>> connectors have the same wires but different electrical characteristics
>> than SS as I understand,
>>
>> With this in mind maybe we can drop 'type' and introduce following
>> compatibles:
>> - usb-a-connector,
>> - usb-b-connector,
>> - usb-c-connector.
>> Encoding other properties in compatible would explode their number, so I
>> would prefer to avoid it.
>> I would leave other props:
>> max-speed: hs, ss, ss+,
>> (optional)size: micro, mini
>>
>> I would drop also unpopular/obsolete variants: type-ab, powered, they
>> can be added later if necessary.
>>
>> Just for reference, list of connectors defined by USB (>= 2) specifications:
>> 1. USB 2.0 (with later amendments):
>> - Standard-A plug and receptacle
>> - Standard-B plug and receptacle
>> - Mini-B plug and receptacle
>> - Micro-B plug and receptacle
>> - Micro-AB receptacle
>> - Micro-A plug
>> 2. USB 3.0:
>> - USB 3.0 Standard-A plug and receptacle
>> - USB 3.0 Standard-B plug and receptacle
>> - USB 3.0 Powered-B plug and receptacle
>> - USB 3.0 Micro-B plug and receptacle
>> - USB 3.0 Micro-A plug
>> - USB 3.0 Micro-AB receptacle
>> 3. USB 3.1:
>> - Enhanced SuperSpeed Standard-A plug and receptacle
>> - Enhanced SuperSpeed Standard-B plug and receptacle
>> - Enhanced SuperSpeed Micro-B plug and receptacle
>> - Enhanced SuperSpeed Micro-A plug
>> - Enhanced SuperSpeed Micro-AB receptacle
>> 4. USB-C (release 1.3):
>> - USB Full-Featured Type-C receptacle
>> - USB 2.0 Type-C receptacle
>> - USB Full-Featured Type-C plug
>> - USB 2.0 Type-C plug
>> - USB Type-C Power-Only plug
>>
 3. Numbering of port/remote nodes, currently only 0 is assigned for 
 Interface
Controller. Maybe other functions should be also assigned:
HS, SS, CC, SBU, ... whatever. Maybe functions should be described
as an additional property of remote node?
>>> child of the controller is also an option. There's already prec
>> Shall we support both solutions or just make one mandatory?
> Oops, I was just going to say for display, there's already precedent
> that ports are used. So that means at least SS should just be
> described with ports. Then HS probably should be a port too just to be
> symmetrical.
>
> The connector being a child of the USB-PD (or other controller chip)
> is probably the only thing that makes sense. I guess the question is
> whether there are cases where that doesn't make sense.
>
 ---
  .../bindings/connector/usb-connector.txt   | 49 
 ++
  1 file changed, 49 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/connector/usb-connector.txt

 diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
 b/Documentation/devicetree/bindings/connector/usb-connector.txt
 new file mode 100644
 index ..f3a4e85122d5
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
 @@ -0,0 +1,49 @@
 +USB Connector
 +=
 +
 +Required properties:
 +- compatible: "usb-connector"
 +  connectors with vendor specific 

Re: [PATCH v2 0/2] USB: musb: PM fixes

[Johan Hovold]

On Fri, Oct 06, 2017 at 11:27:56AM -0500, Bin Liu wrote:
> On Thu, Oct 05, 2017 at 05:14:24PM +0200, Johan Hovold wrote:
> > On Thu, Oct 05, 2017 at 08:11:55AM -0700, Tony Lindgren wrote:
> > > * Johan Hovold  [171005 02:15]:

> > > > Bin and Tony, any comments to this series?
> > > 
> > > Oops sorry I forgot to test these after two recent conferences. I just 
> > > gave
> > > these a try and they both behave for me. Nice fixes, for both:
> > > 
> > > Tested-by: Tony Lindgren 
> > 
> > Great, thanks for testing!
> 
> Tony, thanks for testing them.
> 
> Johan, I recently have been over loaded with a non-usb work, and it
> probably will last for another month or two. But I will try my best to
> get these patches and others accumulated recently into upstream in next
> week.
> 
> Sorry for the delay.

No worries, thanks for letting me know.

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 v2 14/17] phy: qcom-qusb2: Set vbus sw-override signal in device mode

[Manu Gautam]

Hi Kishon

On 10/5/2017 2:38 PM, Manu Gautam wrote:
> Hi Jack,
>
> On 9/28/2017 10:23 PM, Jack Pham wrote:
>>
>> +static int qusb2_phy_set_mode(struct phy *phy, enum phy_mode mode)
>> +{
>> +struct qusb2_phy *qphy = phy_get_drvdata(phy);
>> +
>> +qphy->mode = mode;
>> +
>> +/* Update VBUS override in qscratch register */
>> +if (qphy->qscratch_base) {
>> +if (mode == PHY_MODE_USB_DEVICE)
>> +qusb2_setbits(qphy->qscratch_base, 
>> QSCRATCH_HS_PHY_CTRL,
>> +  UTMI_OTG_VBUS_VALID | 
>> SW_SESSVLD_SEL);
>> +else
>> +qusb2_clrbits(qphy->qscratch_base, 
>> QSCRATCH_HS_PHY_CTRL,
>> +  UTMI_OTG_VBUS_VALID | 
>> SW_SESSVLD_SEL);
> Wouldn't this be better off handled in the controller glue driver? Two
> reasons I think this patch is unattractive:
>
> - qscratch_base is part of the controller's register space. Your later
>   patch 16/17 ("phy: qcom-qmp: Override lane0_power_present signal in
>   device mode") does a similar thing and hence both drivers have to
>   ioremap() the same register resource while at the same time avoiding
>   request_mem_region() (called by devm_ioremap_resource) to allow it to
>   be mapped in both places.
>>> Right. There is one more reason why qusb2 driver needs qscratch:
>>> - During runtime suspend, it has to check linestate to set correct  
>>> polarity for dp/dm
>>>   wakeup interrupt in order to detect disconnect/resume ion LS and FS/HS 
>>> modes.
>> Ugh, oh yeah. The way I understand we did it in our downstream driver
>> is still to have the controller driver read the linestate but then pass
>> the information via additional set_mode() flags which the PHY driver
>> could use to correctly arm the interrupt trigger polarity.
>>
>> An alternative would be to access a couple of the debug QUSB2PHY
>> registers that also provide a reading of the current UTMI linestate. The
>> HPG mentions them vaguely, and I can't remember if we tested that
>> interface or not. Assuming it works, would that be preferable to reading
>> a non-PHY register here?
> it looks like newer QUSB2 PHY doesn't have a register to read linestate.
> QSCRATCH is the only option.
> However, setting dp/dm wakeup interrupt polarity based on current linestate
> isn't perfect either. It could race with any change in linestate while it was 
> being
> read, resulting in missed wakeup interrupt.
> Same is the case with QMP PHY when trying to check for RX terminations on
> suspend.
> IMO PHY driver should get this info from platform glue or controller driver.
> E.g. current speed -> SS, HS/FS, LS or NONE (if not in session).
>
> Kishon,
> What would you suggest here?
> Should we add new calls e.g. phy_get/set_current_speed like::
>
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index 78bb0d7..41d9ec2 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -29,6 +29,14 @@ enum phy_mode {
>     PHY_MODE_USB_OTG,
>  };
>
> +enum phy_speed {
> +   PHY_SPEED_INVALID,
> +   PHY_SPEED_USB_LS,
> +   PHY_SPEED_USB_FS_HS,
> +   PHY_SPEED_USB_SS,
> +};
> +
>  /**
>   * struct phy_ops - set of function pointers for performing phy operations
>   * @init: operation to be performed for initializing phy
> @@ -45,6 +53,7 @@ struct phy_ops {
>     int (*power_on)(struct phy *phy);
>     int (*power_off)(struct phy *phy);
>     int (*set_mode)(struct phy *phy, enum phy_mode mode);
> +   int (*set_speed)(struct phy *phy, enum phy_speed speed);
>     int (*reset)(struct phy *phy);
>     struct module *owner;
>  };
>

@Kishon,
Let me know if we can add set_speed to phy_ops. We need this for glue
driver to notify PHY of current connection speed to enable appropriate
wakeup interrupts.


-- 
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: [PATCH v2] usb: renesas_usbhs: Add compatible string for r8a7743/5

[Geert Uytterhoeven]

Hi Simon,

On Mon, Oct 9, 2017 at 7:59 AM, Simon Horman  wrote:
> On Fri, Oct 06, 2017 at 05:49:34PM +0100, Biju Das wrote:
>> This patch adds support for r8a7743/5 SoCs. The Renesas RZ/G1[ME]
>> (R8A7743/5) usbhs is identical to the R-Car Gen2 family.
>>
>> No driver change is needed due to the fallback compatible value
>> "renesas,rcar-gen2-usbhs".
>> Adding the SoC-specific compatible values here has two purposes:
>>   1. Document which SoCs have this hardware module,
>>   2. Allow checkpatch to validate compatible values.
>
> 3. Allow the driver to support SoC specific implementations in future
>as necessary.

Thanks for amending!

Gr{oetje,eeting}s,

Geert

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

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] usb: renesas_usbhs: Add compatible string for r8a7743/5

[Simon Horman]

On Fri, Oct 06, 2017 at 05:49:34PM +0100, Biju Das wrote:
> This patch adds support for r8a7743/5 SoCs. The Renesas RZ/G1[ME]
> (R8A7743/5) usbhs is identical to the R-Car Gen2 family.
> 
> No driver change is needed due to the fallback compatible value
> "renesas,rcar-gen2-usbhs".
> Adding the SoC-specific compatible values here has two purposes:
>   1. Document which SoCs have this hardware module,
>   2. Allow checkpatch to validate compatible values.

3. Allow the driver to support SoC specific implementations in future
   as necessary.

Acked-by: Simon Horman 

> Signed-off-by: Biju Das 
> Signed-off-by: Chris Paterson 
> Reviewed-by: Yoshihiro Shimoda 
> Reviewed-by: Geert Uytterhoeven 
> ---
> v1-->v2
>* Modified the patch description
>* Rebased on the below R-Car D3 patch
>  https://patchwork.kernel.org/patch/9982267/
> 
> This patch is tested against Linux next tag next-20170929 +
>   https://patchwork.kernel.org/patch/9982267/
> 
>  Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt 
> b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> index e79f6e4..47394ab 100644
> --- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> +++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
> @@ -3,6 +3,8 @@ Renesas Electronics USBHS driver
>  Required properties:
>- compatible: Must contain one or more of the following:
>  
> + - "renesas,usbhs-r8a7743" for r8a7743 (RZ/G1M) compatible device
> + - "renesas,usbhs-r8a7745" for r8a7745 (RZ/G1E) compatible device
>   - "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device
>   - "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device
>   - "renesas,usbhs-r8a7792" for r8a7792 (R-Car V2H) compatible device
> @@ -11,7 +13,7 @@ Required properties:
>   - "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device
>   - "renesas,usbhs-r8a7796" for r8a7796 (R-Car M3-W) compatible device
>   - "renesas,usbhs-r8a77995" for r8a77995 (R-Car D3) compatible device
> - - "renesas,rcar-gen2-usbhs" for R-Car Gen2 compatible device
> + - "renesas,rcar-gen2-usbhs" for R-Car Gen2 or RZ/G1 compatible devices
>   - "renesas,rcar-gen3-usbhs" for R-Car Gen3 compatible device
>  
>   When compatible with the generic version, nodes must list the
> -- 
> 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