Re: [PATCH 1/9] staging: sm750fb: fix line length coding style issue in ddk750_chip.c

[Greg KH]

On Mon, Aug 29, 2016 at 11:50:01PM +0300, Moshe Green wrote:
> Fix a line length warning found by the checkpatch.pl tool in
> ddk750_chip.c.
> 
> Signed-off-by: Moshe Green 
> ---
>  drivers/staging/sm750fb/ddk750_chip.c | 2 +-

What does this file have to do with the linux-usb mailing list?  And
where are the other 8 patches in this series?

confused,

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: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422

[Anand Moon]

Hi All

Adding Vivek Gautam.

On 29 August 2016 at 16:35, Michael Niewöhner  wrote:
> Hi Mathias,
> On Mo, 2016-08-29 at 13:59 +0300, Mathias Nyman wrote:
>> On 29.08.2016 10:28, Felipe Balbi wrote:
>> >
>> >
>> > Hi,
>> >
>> > Michael Niewöhner  writes:
>> > >
>> > > [1.] One line summary of the problem:
>> > > DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
>> > >
>> > > [2.] Full description of the problem/report:
>> > > No usb 3.0 devices are being detected when attached while USB 2.0
>> > > devices work on the same port.
>> > > USB 3.0 works after applying patches [9.1] and [9.2], but seems
>> > > to be
>> > > buggy. The usb hub is redetected every time an usb device is
>> > > attached.
>> >
>> > dwc3 is host, which means it's actually XHCI :-)
>> >
>> > Adding Mathias
>> >
>> > >
>> > > dmesg:
>> > > [  192.287080] usb 3-1.2: USB disconnect, device number 7
>> > > [  210.370699] hub 3-1:1.0: hub_ext_port_status failed (err =
>> > > -71)
>>
>> Looks like the hub GetPortStatus request fails with protocol error.
>>
>> Reading xhci root hub port status is mostly just register reads and
>> writes. It
>> shouldn't include any actual transfers that could return -EPROTO
>>
>> So this is not the root hub? but a external or integrated on your
>> board, right?
>>
>> The protocol error -71 is returned at transfer errors or if device
>> stalled.
>>
>> Adding more xhci debugging options could show something:
>> echo -n 'module xhci_hcd =p' >
>> /sys/kernel/debug/dynamic_debug/control
>>
>> >
>> > >
>> > > [9.] Other notes, patches, fixes, workarounds:
>> > > [9.1] https://lkml.org/lkml/2014/4/28/234
>> > > [9.2] https://lkml.org/lkml/2015/2/2/259
>>
>> The additional patches that makes things somehow work involve tuning
>> the PHY,
>> this is an area I'm not familiar with
>>
>> -Mathias
>>
>
>
> I'm sorry, I should have said that this is the dmesg output with the
> patches applied. Without them there is no output at all when I attach
> an usb 3.0 device.
>
> Michael

There are two dwc3 ports in the SoC : one for Gbit Ethernet another
one for on-board GL3521 USB 3.0 hub controller.

3.10.x kernel
odroid@odroid:~$ lsusb -t
/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=s5p-ehci/3p, 480M

4.x kernel
odroid@odroid:~$ lsusb -t
/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 480M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 5000M
|__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
|__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=exynos-ehci/3p, 480M

I fell that Ethernet driver r8152 is not getting registered to
xhci-hcd to bus port 06
which lead to other ports to miss configure, some time the Ethernet
port get register to bus port 04

Their is also a possibility that all the port are not getting proper
power from the S2MPS11 PMIC
and possible some reset of the phy is needed to reconfigure the exynos
USB HSIC controller.

Best Regards
-Anand Moon
--
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/9] staging: sm750fb: fix line length coding style issue in ddk750_chip.c

[Moshe Green]

Fix a line length warning found by the checkpatch.pl tool in
ddk750_chip.c.

Signed-off-by: Moshe Green 
---
 drivers/staging/sm750fb/ddk750_chip.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/sm750fb/ddk750_chip.c 
b/drivers/staging/sm750fb/ddk750_chip.c
index c1356bb..fb27eb4 100644
--- a/drivers/staging/sm750fb/ddk750_chip.c
+++ b/drivers/staging/sm750fb/ddk750_chip.c
@@ -71,7 +71,7 @@ static void setChipClock(unsigned int frequency)
pll.clockType = MXCLK_PLL;
 
/*
-   * Call calcPllValue() to fill up the other fields for PLL 
structure.
+   * Call calcPllValue() to fill the other fields of PLL structure.
* Sometime, the chip cannot set up the exact clock required by 
User.
* Return value from calcPllValue() gives the actual possible 
clock.
*/
-- 
2.7.4

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

[PATCH 0/6] usb: dwc2: gadget: Fix TX FIFO handling

[John Youn]

Hi,

This is a resend of a patch series originally submitted by Robert
Baldyga back in February.

Somehow I missed it back then. Sorry about that.

It should fix some FIFO programming related issues on RPi and maybe
other platforms.

Also, this series makes the g-tx-fifo-size DT property obsolete. I've
added a patch at the end of the series to document that.

Regards,
John

John Youn (1):
  Documentation: devicetree: dwc2: Deprecate g-tx-fifo-size

Robert Baldyga (5):
  usb: dwc2: gadget: use ep->fifo_index in context of FIFO registers
  usb: dwc2: gadget: fix TX FIFO size and address initialization
  usb: dwc2: gadget: change variable name to more meaningful
  usb: dwc2: gadget: remove dead code from dwc2_hsotg_ep_enable()
  usb: dwc2: gadget: free TX FIFO after killing requests

 Documentation/devicetree/bindings/usb/dwc2.txt |  5 +-
 drivers/usb/dwc2/core.h|  7 ---
 drivers/usb/dwc2/gadget.c  | 79 +++---
 3 files changed, 23 insertions(+), 68 deletions(-)

-- 
2.9.0

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

[PATCH 3/6] usb: dwc2: gadget: change variable name to more meaningful

[John Youn]

From: Robert Baldyga 

Since we handle FIFOs and endpoint separately, using variable named 'ep'
in context of FIFO is misleading, hence we rename it to 'fifo'.

Signed-off-by: Robert Baldyga 
Signed-off-by: John Youn 
---
 drivers/usb/dwc2/gadget.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 5c24c85..ac267fd 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -186,7 +186,7 @@ static void dwc2_hsotg_ctrl_epint(struct dwc2_hsotg *hsotg,
  */
 static void dwc2_hsotg_init_fifo(struct dwc2_hsotg *hsotg)
 {
-   unsigned int ep;
+   unsigned int fifo;
unsigned int addr;
int timeout;
u32 dptxfsizn;
@@ -217,8 +217,8 @@ static void dwc2_hsotg_init_fifo(struct dwc2_hsotg *hsotg)
 * them to endpoints dynamically according to maxpacket size value of
 * given endpoint.
 */
-   for (ep = 1; ep < MAX_EPS_CHANNELS; ep++) {
-   dptxfsizn = dwc2_readl(hsotg->regs + DPTXFSIZN(ep));
+   for (fifo = 1; fifo < MAX_EPS_CHANNELS; fifo++) {
+   dptxfsizn = dwc2_readl(hsotg->regs + DPTXFSIZN(fifo));
 
val = (dptxfsizn & FIFOSIZE_DEPTH_MASK) | addr;
addr += dptxfsizn >> FIFOSIZE_DEPTH_SHIFT;
@@ -226,7 +226,7 @@ static void dwc2_hsotg_init_fifo(struct dwc2_hsotg *hsotg)
if (addr > hsotg->fifo_mem)
break;
 
-   dwc2_writel(val, hsotg->regs + DPTXFSIZN(ep));
+   dwc2_writel(val, hsotg->regs + DPTXFSIZN(fifo));
}
 
/*
-- 
2.9.0

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

[PATCH 2/6] usb: dwc2: gadget: fix TX FIFO size and address initialization

[John Youn]

From: Robert Baldyga 

According to DWC2 documentation, DPTxFSize field of DPTXFSIZn register
is read only, which means that software cannot change FIFO size.

Register description says:
"The value of this register is the Largest Device Mode Periodic Tx Data
FIFO Depth (parameter OTG_TX_DPERIO_DFIFO_DEPTH_n), as specified during
coreConsultant configuration."

That means, that we have to setup only FIFO start addresses (DPTxFStAddr),
taking into account reset values of DPTxFSize.

Initialize FIFO start addresses properly and remove unneeded core related
to incorrect FIFO size initialization.

Signed-off-by: Robert Baldyga 
Signed-off-by: John Youn 
---
 drivers/usb/dwc2/core.h   |  7 ---
 drivers/usb/dwc2/gadget.c | 47 ---
 2 files changed, 8 insertions(+), 46 deletions(-)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 9fae029..78526ee 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -259,13 +259,6 @@ enum dwc2_lx_state {
DWC2_L3,/* Off state */
 };
 
-/*
- * Gadget periodic tx fifo sizes as used by legacy driver
- * EP0 is not included
- */
-#define DWC2_G_P_LEGACY_TX_FIFO_SIZE {256, 256, 256, 256, 768, 768, 768, \
-  768, 0, 0, 0, 0, 0, 0, 0}
-
 /* Gadget ep0 states */
 enum dwc2_ep0_state {
DWC2_EP0_SETUP,
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index f6086d6..5c24c85 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -189,6 +189,7 @@ static void dwc2_hsotg_init_fifo(struct dwc2_hsotg *hsotg)
unsigned int ep;
unsigned int addr;
int timeout;
+   u32 dptxfsizn;
u32 val;
 
/* Reset fifo map if not correctly cleared during previous session */
@@ -217,13 +218,13 @@ static void dwc2_hsotg_init_fifo(struct dwc2_hsotg *hsotg)
 * given endpoint.
 */
for (ep = 1; ep < MAX_EPS_CHANNELS; ep++) {
-   if (!hsotg->g_tx_fifo_sz[ep])
-   continue;
-   val = addr;
-   val |= hsotg->g_tx_fifo_sz[ep] << FIFOSIZE_DEPTH_SHIFT;
-   WARN_ONCE(addr + hsotg->g_tx_fifo_sz[ep] > hsotg->fifo_mem,
- "insufficient fifo memory");
-   addr += hsotg->g_tx_fifo_sz[ep];
+   dptxfsizn = dwc2_readl(hsotg->regs + DPTXFSIZN(ep));
+
+   val = (dptxfsizn & FIFOSIZE_DEPTH_MASK) | addr;
+   addr += dptxfsizn >> FIFOSIZE_DEPTH_SHIFT;
+
+   if (addr > hsotg->fifo_mem)
+   break;
 
dwc2_writel(val, hsotg->regs + DPTXFSIZN(ep));
}
@@ -3814,36 +3815,10 @@ static void dwc2_hsotg_dump(struct dwc2_hsotg *hsotg)
 static void dwc2_hsotg_of_probe(struct dwc2_hsotg *hsotg)
 {
struct device_node *np = hsotg->dev->of_node;
-   u32 len = 0;
-   u32 i = 0;
 
/* Enable dma if requested in device tree */
hsotg->g_using_dma = of_property_read_bool(np, "g-use-dma");
 
-   /*
-   * Register TX periodic fifo size per endpoint.
-   * EP0 is excluded since it has no fifo configuration.
-   */
-   if (!of_find_property(np, "g-tx-fifo-size", ))
-   goto rx_fifo;
-
-   len /= sizeof(u32);
-
-   /* Read tx fifo sizes other than ep0 */
-   if (of_property_read_u32_array(np, "g-tx-fifo-size",
-   >g_tx_fifo_sz[1], len))
-   goto rx_fifo;
-
-   /* Add ep0 */
-   len++;
-
-   /* Make remaining TX fifos unavailable */
-   if (len < MAX_EPS_CHANNELS) {
-   for (i = len; i < MAX_EPS_CHANNELS; i++)
-   hsotg->g_tx_fifo_sz[i] = 0;
-   }
-
-rx_fifo:
/* Register RX fifo size */
of_property_read_u32(np, "g-rx-fifo-size", >g_rx_fifo_sz);
 
@@ -3865,13 +3840,10 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq)
struct device *dev = hsotg->dev;
int epnum;
int ret;
-   int i;
-   u32 p_tx_fifo[] = DWC2_G_P_LEGACY_TX_FIFO_SIZE;
 
/* Initialize to legacy fifo configuration values */
hsotg->g_rx_fifo_sz = 2048;
hsotg->g_np_g_tx_fifo_sz = 1024;
-   memcpy(>g_tx_fifo_sz[1], p_tx_fifo, sizeof(p_tx_fifo));
/* Device tree specific probe */
dwc2_hsotg_of_probe(hsotg);
 
@@ -3889,9 +3861,6 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq)
dev_dbg(dev, "NonPeriodic TXFIFO size: %d\n",
hsotg->g_np_g_tx_fifo_sz);
dev_dbg(dev, "RXFIFO size: %d\n", hsotg->g_rx_fifo_sz);
-   for (i = 0; i < MAX_EPS_CHANNELS; i++)
-   dev_dbg(dev, "Periodic TXFIFO%2d size: %d\n", i,
-   hsotg->g_tx_fifo_sz[i]);
 
hsotg->gadget.max_speed = USB_SPEED_HIGH;

[PATCH 1/6] usb: dwc2: gadget: use ep->fifo_index in context of FIFO registers

[John Youn]

From: Robert Baldyga 

In context of FIFO registers we use ep->fifo_index instead of ep->index.

Signed-off-by: Robert Baldyga 
Signed-off-by: John Youn 
---
 drivers/usb/dwc2/gadget.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index af46adf..f6086d6 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -388,7 +388,8 @@ static int dwc2_hsotg_write_fifo(struct dwc2_hsotg *hsotg,
return -ENOSPC;
}
} else if (hsotg->dedicated_fifos && hs_ep->index != 0) {
-   can_write = dwc2_readl(hsotg->regs + DTXFSTS(hs_ep->index));
+   can_write = dwc2_readl(hsotg->regs +
+   DTXFSTS(hs_ep->fifo_index));
 
can_write &= 0x;
can_write *= 4;
@@ -2432,7 +2433,7 @@ static void kill_all_requests(struct dwc2_hsotg *hsotg,
 
if (!hsotg->dedicated_fifos)
return;
-   size = (dwc2_readl(hsotg->regs + DTXFSTS(ep->index)) & 0x) * 4;
+   size = (dwc2_readl(hsotg->regs + DTXFSTS(ep->fifo_index)) & 0x) * 4;
if (size < ep->fifo_size)
dwc2_hsotg_txfifo_flush(hsotg, ep->fifo_index);
 }
-- 
2.9.0

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

[PATCH 4/6] usb: dwc2: gadget: remove dead code from dwc2_hsotg_ep_enable()

[John Youn]

From: Robert Baldyga 

Since FIFO is always freed in dwc2_hsotg_ep_disable(), ep->fifo_index
is always 0 in dwc2_hsotg_ep_enable(), hence code inside if() block is
never executed.

Signed-off-by: Robert Baldyga 
Signed-off-by: John Youn 
---
 drivers/usb/dwc2/gadget.c | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index ac267fd..c8a182c 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3043,22 +3043,11 @@ static int dwc2_hsotg_ep_enable(struct usb_ep *ep,
break;
}
 
-   /* If fifo is already allocated for this ep */
-   if (hs_ep->fifo_index) {
-   size =  hs_ep->ep.maxpacket * hs_ep->mc;
-   /* If bigger fifo is required deallocate current one */
-   if (size > hs_ep->fifo_size) {
-   hsotg->fifo_map &= ~(1 << hs_ep->fifo_index);
-   hs_ep->fifo_index = 0;
-   hs_ep->fifo_size = 0;
-   }
-   }
-
/*
 * if the hardware has dedicated fifos, we must give each IN EP
 * a unique tx-fifo even if it is non-periodic.
 */
-   if (dir_in && hsotg->dedicated_fifos && !hs_ep->fifo_index) {
+   if (dir_in && hsotg->dedicated_fifos) {
u32 fifo_index = 0;
u32 fifo_size = UINT_MAX;
size = hs_ep->ep.maxpacket*hs_ep->mc;
-- 
2.9.0

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

[PATCH 6/6] Documentation: devicetree: dwc2: Deprecate g-tx-fifo-size

[John Youn]

This property is not needed because the periodic fifos are not
configurable. So it was incorrect to add this property in the first
place.

Signed-off-by: John Youn 
---
 Documentation/devicetree/bindings/usb/dwc2.txt | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt 
b/Documentation/devicetree/bindings/usb/dwc2.txt
index 20a68bf..7d16ebf 100644
--- a/Documentation/devicetree/bindings/usb/dwc2.txt
+++ b/Documentation/devicetree/bindings/usb/dwc2.txt
@@ -26,7 +26,10 @@ Refer to phy/phy-bindings.txt for generic phy consumer 
properties
 - g-use-dma: enable dma usage in gadget driver.
 - g-rx-fifo-size: size of rx fifo size in gadget mode.
 - g-np-tx-fifo-size: size of non-periodic tx fifo size in gadget mode.
-- g-tx-fifo-size: size of periodic tx fifo per endpoint (except ep0) in gadget 
mode.
+
+Deprecated properties:
+- g-tx-fifo-size: size of periodic tx fifo per endpoint (except ep0)
+  in gadget mode.
 
 Example:
 
-- 
2.9.0

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

[PATCH 5/6] usb: dwc2: gadget: free TX FIFO after killing requests

[John Youn]

From: Robert Baldyga 

As kill_all_requests() potentially flushes TX FIFO, we should should
free FIFO after calling it. Otherwise FIFO could stay unflushed properly.

Signed-off-by: Robert Baldyga 
Signed-off-by: John Youn 
---
 drivers/usb/dwc2/gadget.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index c8a182c..4d84c32 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3120,10 +3120,6 @@ static int dwc2_hsotg_ep_disable(struct usb_ep *ep)
 
spin_lock_irqsave(>lock, flags);
 
-   hsotg->fifo_map &= ~(1fifo_index = 0;
-   hs_ep->fifo_size = 0;
-
ctrl = dwc2_readl(hsotg->regs + epctrl_reg);
ctrl &= ~DXEPCTL_EPENA;
ctrl &= ~DXEPCTL_USBACTEP;
@@ -3138,6 +3134,10 @@ static int dwc2_hsotg_ep_disable(struct usb_ep *ep)
/* terminate all requests with shutdown */
kill_all_requests(hsotg, hs_ep, -ESHUTDOWN);
 
+   hsotg->fifo_map &= ~(1 << hs_ep->fifo_index);
+   hs_ep->fifo_index = 0;
+   hs_ep->fifo_size = 0;
+
spin_unlock_irqrestore(>lock, flags);
return 0;
 }
-- 
2.9.0

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

Re: [PATCHv6 1/3] usb: USB Type-C connector class

[Guenter Roeck]

Hello Heikki,

On Mon, Aug 29, 2016 at 05:07:39PM +0300, Heikki Krogerus wrote:
> Hi Guenter,
> 
> > > Overall this is quite vague and, especially for chargers, most of the time
> > > misses the point.
> > > 
> > > I would really prefer if we could stay closer to the specification in this
> > > case, and not try to merge multiple orthogonal attributes into one.
> > 
> > OK. So what would you propose?
> 
> I'm actually only conserned about the accessory case, as there we are
> really not a source/sink/DRP, nor are we DPF/UFP/DRD. Should we use
> this attribute to only express if the type of the partner is "normal"
> or an accessory?
> 

We currently have three attributes to cover accessory modes.

supported_accessory_modes
Lists the Accessory Modes, defined in the USB Type-C
specification, the port supports.

[ This is a bit vague. I think we should list the actual strings.
  The modes are called "Audio Adapter Accessory Mode" and "Debug
  Accessory Mode", yet the reported text is "Audio" and "Debug".
  Also, "Digital Audio" isn't supported as of specification revision
  1.2. So the strings doesn't exactly follow the specification. ]

accessory
Shows the name of the Accessory Mode. The Accessory Modes are
defined in USB Type-C Specification.

type
Shows the type of the partner.

One of the possible accessory modes is TYPEC_ACCESSORY_NONE.

If you are only interested in accessory mode support, maybe we don't need
the 'type' attribute at all. We could make the 'accessory' attribute always
visible and display one of "none", "Audio", "Debug", or "Digital Audio".
It might also make sense to rename the attribute to "accessory_mode".

On a side note, while looking into this, I noticed the following:

+   if (port->cap->accessory)
+   for (accessory = port->cap->accessory, i = 0;
+i < port->cap->num_accessory; accessory++, i++)
+   ret += sprintf(buf, "%s\n",
+  typec_accessory_modes[*accessory]);

This means the list of supported accessories always starts with ", ".

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

Re: UAS and f_tcm -- is anyone using it?

[John Youn]

On 8/29/2016 12:33 AM, Felipe Balbi wrote:
> 
> Hi,
> 
> John Youn  writes:
>> On 8/26/2016 12:48 AM, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> John Youn  writes:
 I was wondering if anyone is using the f_tcm function? Specifically
 for UAS in superspeed with streams? Any idea if it is being using in
 production for this anywhere?

 I've been trying to get the tcm gadget running without success. It
 seems I need to configure the target system via configfs and somehow
 interface it to this gadget. But I have not found any documentation or
 examples on how to get it working. Anyone have ideas or pointers?
>>>
>>> Sebastian has posted his scripts here several times, it's in the
>>> archives :-)
>>
>> I found some scripts before but none of them resulted in a working
>> system. Though I did manage to get something semi-working
>> eventually. It would still be nice to have some documentation about
>> this part especially as I have no knowledge of the target side and no
>> idea what those scripts are doing.
> 
> What do you mean by "semi-working"? How far did you get? Can you capture
> tracepoints so we figure out what's wrong?
> 
> # mkdir -p /t
> # mount -t tracefs none /t
> # echo 8192 > /t/buffer_size_kb
> # echo 1 > /t/events/dwc3/enable
> 
> (trigger issue)
> 
> # cp /t/trace ~/trace.txt
> 
> Send me trace.txt ;-)
> 
>>> There's also a TCM python tool somewhere which helps with this. I
>>> haven't used f_tcm in a long while, but Sebastian and I used it long
>>> back to test streams with dwc3.
>>
>> Have you tried it recently? Or do you know of anyone who has?
> 
> Sebastian is the only one I know who has used this in the past.
> 
 Just from the code it seems there will be some fundamental issues with
 it, such as the value of maxpacket size and some alt-interface
 stuff. At least when used with DWC3.
>>>
>>> such as?
>>
>> I'll see if I can write up the exact issues later. I have to go back
>> to my notes to remind myself.
>>
>> But just in trying to get it to work, these issues make me suspect no
>> one is using this driver in superspeed, or at least regularly testing
>> it, let alone using it in production.
> 
> that's probably true, but it's not enough argument to have a duplicate
> implementation of it :-) Rather, we should be figuring out what's broken
> and fixing it. I have a ton of other stuff to be done, but I'll add this
> to my queue, no issues.
> 

Ok thanks. I'll see if I can get back to you on the exact issues I
found later this week.

Regards,
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: [RESEND PATCH 3/4] usb: dwc2: assert phy reset when waking up in rk3288 platform

[John Youn]

On 8/29/2016 12:51 AM, Felipe Balbi wrote:
> 
> Hi,
> 
> John Youn  writes:
> 
> [...]
> 
> +  */
> + if (of_device_is_compatible(np, "rockchip,rk3288-usb"))
> + hsotg->phy->ops->reset(hsotg->phy);
> +

 You should probably check for NULL before calling the reset()
 callback.
>>> Sure.

 Also, I'd rather see a generic quirk property that you set for your
 platform.

 Something like "phy_reset_on_wakeup_quirk".
>>> But Rob Herring want me to implied by the SoC specific compatible 
>>> string. I agree with him. It is certainly bug in RK3288 platform.
>>> It is no found no the other platform.
>>
>> Ok, I missed that before.
>>
>> Based on the drivers I'm familiar with (like dwc3), you would
>> typically add a "quirk" anyways.
>>
>> Felipe,
>>
>> Do you have some policy or preference on this?
> 
> if it's not a dwc2-generic feature, then let's do it via compatible
> flag, sure. What we don't want is for things like:
> 
> if (is_compatible('synopsys') || is_compatible('rockchip') ||
>   is_compatible('foobar') ... )
> 
> For that, we'd be better of adding a generic quirk flag which several
> can use.
> 

Alright sounds reasonable.

Randy, could you respin with the other feedback? There's no need to
add a quirk.

Regards,
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: pl2303_read_int_callback - usb_submit_urb failed with result -19

[Alan Stern]

On Mon, 29 Aug 2016, Greg KH wrote:

> > >> I have since compiled 4.8.0_rc1. And just as you guys suggested a part
> > >> of problem is solved. The minor number now definitely goes up to 512
> > >> before giving no more free serial devices. But it still doesn't reuse
> > >> the minors after disconnecting.
> > >>
> > >> In my code I'm calling modbus_close and modbus_free which in turn call
> > >> close() and free() on the file descriptor. Shouldn't this make the
> > >> minor reusable?

Yes, it should.

> > >> >From what i understand minor numbers are allocated and freed by the
> > >> driver. So how does the driver know to release the minor number after
> > >> the file descriptor is closed?
> > >
> > > The USB serial driver core code handles this for you automatically after
> > > the last reference goes away.  Are you sure that userspace is properly
> > > releasing the device properly?
> > >
> > > thanks,
> > >
> > > greg k-h
> > 
> > >From my understanding it is, but let me double check. If i compile the
> > kernel with some print statements in usb-serial.c, will i get the
> > output in stdout?
> 
> You can use dynamic debugging on the usb_serial.ko kernel module to see
> the open/close messages in the kernel log, along with when minors are
> allocated.  Read about how to turn that on in the Documentation/
> directory (search for dynamic debugging).

The command is:

echo module usbserial =p >/sys/kernel/debug/dynamic_debug/control

(note that you need to mount a debugfs filesystem on /sys/kernel/debug 
first).

> > In the userspace is it sufficient to just call close() on the file
> > descriptor in /dev ?
> 
> Yes.
> 
> > Is it possible that udev has already replaced /dev/ttyUSBx with
> > /dev/ttyUSBx+1 by the time the program calls close() on it?
> 
> Yes, if it is open.  And udev does not create the device node, the
> kernel is doing so.
> 
> If your program/device does the following:
>   - userspace open ttyUSB0
>   - device disconnect
>   - device connect (ttyUSB1)
>   - userspace close ttyUSB0
>   - kernel removes ttyUSB0
> 
> that could be what is happening here, you are racing and loosing :(

But even in this case, the kernel would re-use the old minor numbers
once the ttyUSB files had been closed.

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: pl2303_read_int_callback - usb_submit_urb failed with result -19

[Greg KH]

On Mon, Aug 29, 2016 at 10:22:43PM +0530, Malith Yapa wrote:
> On Mon, Aug 29, 2016 at 4:46 PM, Greg KH  wrote:
> > On Mon, Aug 29, 2016 at 02:49:23PM +0530, Malith Yapa wrote:
> >> On Thu, Jul 14, 2016 at 9:14 AM, Malith Yapa  wrote:
> >> > On Thu, Jul 14, 2016 at 2:14 AM, Greg KH  
> >> > wrote:
> >> >> On Wed, Jul 13, 2016 at 10:59:10AM +0530, Malith Yapa wrote:
> >> >>> I think i am.
> >> >>>
> >> >>> int readDword(int addr) {
> >> >>>
> >> >>> uint16_t reg[1];// will store read registers values
> >> >>>
> >> >>> int num = modbus_read_registers(ctx, addr, 1, reg); //16386 = 
> >> >>> X2
> >> >>>
> >> >>> usleep(5);
> >> >>>
> >> >>> if (num != 1) {
> >> >>> fprintf(stderr, "Failed(%i) to read: %s\n", num,
> >> >>> modbus_strerror(errno));
> >> >>> modbus_close(ctx);
> >> >>> modbus_free(ctx);
> >> >>> sleep(5);
> >> >>> int wait = 1;
> >> >>> while(initModbus()) {
> >> >>> cerr << "Waiting for PLC.. SLEEP[" << wait*20 << "]" << 
> >> >>> endl;
> >> >>> sleep(wait*20);
> >> >>> wait++;
> >> >>> }
> >> >>> }
> >> >>>
> >> >>> return reg[0];
> >> >>> }
> >> >>>
> >> >>> according to modbus documentation, "The modbus_close() function shall
> >> >>> close the connection established with the backend set in the context."
> >> >>>
> >> >>> Even if not. Shouldn't the minor number's go upto 512 (as Johan
> >> >>> pointed out) before giving up?
> >> >>
> >> >> Yes it should.
> >> >>
> >> >>> The system is an Olimex A20-micro,
> >> >>> Linux version 3.4.90+ (gcc version 4.7.1 (Debian 4.7.1-7) )
> >> >>
> >> >> Ugh, 3.4 is a very old, and obsolete kernel version.  Please get support
> >> >> for it from the vendor that is forcing you to use such a thing, as you
> >> >> are already paying for it from them.
> >> >>
> >> >> We can help you out if you can reproduce this on 4.6, have you tried
> >> >> that?
> >> >>
> >> >> thanks,
> >> >>
> >> >> greg k-h
> >> >
> >> > Looks like sunxi only provides a 3.4 kernel. I lack the expertise to
> >> > try to build 4.6 for this board so I'll try reporting it to them.
> >> >
> >> > Thanks,
> >> > Malith
> >>
> >> Hope it's ok to reply on the old thread.
> >>
> >> I have since compiled 4.8.0_rc1. And just as you guys suggested a part
> >> of problem is solved. The minor number now definitely goes up to 512
> >> before giving no more free serial devices. But it still doesn't reuse
> >> the minors after disconnecting.
> >>
> >> In my code I'm calling modbus_close and modbus_free which in turn call
> >> close() and free() on the file descriptor. Shouldn't this make the
> >> minor reusable?
> >>
> >> >From what i understand minor numbers are allocated and freed by the
> >> driver. So how does the driver know to release the minor number after
> >> the file descriptor is closed?
> >
> > The USB serial driver core code handles this for you automatically after
> > the last reference goes away.  Are you sure that userspace is properly
> > releasing the device properly?
> >
> > thanks,
> >
> > greg k-h
> 
> >From my understanding it is, but let me double check. If i compile the
> kernel with some print statements in usb-serial.c, will i get the
> output in stdout?

You can use dynamic debugging on the usb_serial.ko kernel module to see
the open/close messages in the kernel log, along with when minors are
allocated.  Read about how to turn that on in the Documentation/
directory (search for dynamic debugging).

> In the userspace is it sufficient to just call close() on the file
> descriptor in /dev ?

Yes.

> Is it possible that udev has already replaced /dev/ttyUSBx with
> /dev/ttyUSBx+1 by the time the program calls close() on it?

Yes, if it is open.  And udev does not create the device node, the
kernel is doing so.

If your program/device does the following:
- userspace open ttyUSB0
- device disconnect
- device connect (ttyUSB1)
- userspace close ttyUSB0
- kernel removes ttyUSB0

that could be what is happening here, you are racing and loosing :(

Hope that helps,

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

Re: pl2303_read_int_callback - usb_submit_urb failed with result -19

[Malith Yapa]

On Mon, Aug 29, 2016 at 4:46 PM, Greg KH  wrote:
> On Mon, Aug 29, 2016 at 02:49:23PM +0530, Malith Yapa wrote:
>> On Thu, Jul 14, 2016 at 9:14 AM, Malith Yapa  wrote:
>> > On Thu, Jul 14, 2016 at 2:14 AM, Greg KH  
>> > wrote:
>> >> On Wed, Jul 13, 2016 at 10:59:10AM +0530, Malith Yapa wrote:
>> >>> I think i am.
>> >>>
>> >>> int readDword(int addr) {
>> >>>
>> >>> uint16_t reg[1];// will store read registers values
>> >>>
>> >>> int num = modbus_read_registers(ctx, addr, 1, reg); //16386 = X2
>> >>>
>> >>> usleep(5);
>> >>>
>> >>> if (num != 1) {
>> >>> fprintf(stderr, "Failed(%i) to read: %s\n", num,
>> >>> modbus_strerror(errno));
>> >>> modbus_close(ctx);
>> >>> modbus_free(ctx);
>> >>> sleep(5);
>> >>> int wait = 1;
>> >>> while(initModbus()) {
>> >>> cerr << "Waiting for PLC.. SLEEP[" << wait*20 << "]" << endl;
>> >>> sleep(wait*20);
>> >>> wait++;
>> >>> }
>> >>> }
>> >>>
>> >>> return reg[0];
>> >>> }
>> >>>
>> >>> according to modbus documentation, "The modbus_close() function shall
>> >>> close the connection established with the backend set in the context."
>> >>>
>> >>> Even if not. Shouldn't the minor number's go upto 512 (as Johan
>> >>> pointed out) before giving up?
>> >>
>> >> Yes it should.
>> >>
>> >>> The system is an Olimex A20-micro,
>> >>> Linux version 3.4.90+ (gcc version 4.7.1 (Debian 4.7.1-7) )
>> >>
>> >> Ugh, 3.4 is a very old, and obsolete kernel version.  Please get support
>> >> for it from the vendor that is forcing you to use such a thing, as you
>> >> are already paying for it from them.
>> >>
>> >> We can help you out if you can reproduce this on 4.6, have you tried
>> >> that?
>> >>
>> >> thanks,
>> >>
>> >> greg k-h
>> >
>> > Looks like sunxi only provides a 3.4 kernel. I lack the expertise to
>> > try to build 4.6 for this board so I'll try reporting it to them.
>> >
>> > Thanks,
>> > Malith
>>
>> Hope it's ok to reply on the old thread.
>>
>> I have since compiled 4.8.0_rc1. And just as you guys suggested a part
>> of problem is solved. The minor number now definitely goes up to 512
>> before giving no more free serial devices. But it still doesn't reuse
>> the minors after disconnecting.
>>
>> In my code I'm calling modbus_close and modbus_free which in turn call
>> close() and free() on the file descriptor. Shouldn't this make the
>> minor reusable?
>>
>> >From what i understand minor numbers are allocated and freed by the
>> driver. So how does the driver know to release the minor number after
>> the file descriptor is closed?
>
> The USB serial driver core code handles this for you automatically after
> the last reference goes away.  Are you sure that userspace is properly
> releasing the device properly?
>
> thanks,
>
> greg k-h

>From my understanding it is, but let me double check. If i compile the
kernel with some print statements in usb-serial.c, will i get the
output in stdout?
In the userspace is it sufficient to just call close() on the file
descriptor in /dev ? Is it possible that udev has already replaced
/dev/ttyUSBx with /dev/ttyUSBx+1 by the time the program calls close()
on it?
It's very likely that i'm making a silly mistake somewhere. Please
bare with me :/
Would appreciate any pointers you can give to help me understand the
usb serial core better.

Thanks!
Malith
--
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: [PATCHv6 1/3] usb: USB Type-C connector class

[Heikki Krogerus]

Hi Guenter,

> > Overall this is quite vague and, especially for chargers, most of the time
> > misses the point.
> > 
> > I would really prefer if we could stay closer to the specification in this
> > case, and not try to merge multiple orthogonal attributes into one.
> 
> OK. So what would you propose?

I'm actually only conserned about the accessory case, as there we are
really not a source/sink/DRP, nor are we DPF/UFP/DRD. Should we use
this attribute to only express if the type of the partner is "normal"
or an accessory?


Thanks,

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

Re: [PATCHv6 0/3] USB Type-C Connector class

[Heikki Krogerus]

On Mon, Aug 29, 2016 at 06:06:39AM -0700, Guenter Roeck wrote:
> On 08/29/2016 05:36 AM, Heikki Krogerus wrote:
> > The USB Type-C class is meant to provide unified interface to the
> > userspace to present the USB Type-C ports in a system.
> > 
> The subject says "v6".

True. I used the wrong reroll-count when formatting. I'm sorry about
that.

Thanks,

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

[PATCH v3 3/5] net: asix: Fix AX88772x resume failures

[robert . foss]

From: Robert Foss 

From: Allan Chou 

The change fixes AX88772x resume failure by
- Restore incorrect AX88772A PHY registers when resetting
- Need to stop MAC operation when suspending
- Need to restart MII when restoring PHY

Signed-off-by: Allan Chou 
Signed-off-by: Robert Foss 
Tested-by: Robert Foss 
---
 drivers/net/usb/asix_devices.c | 47 ++-
 1 file changed, 46 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index ebeb730..083dc2e 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -35,6 +35,15 @@
 
 #definePHY_MODE_RTL8211CL  0x000C
 
+#define AX88772A_PHY14H0x14
+#define AX88772A_PHY14H_DEFAULT 0x442C
+
+#define AX88772A_PHY15H0x15
+#define AX88772A_PHY15H_DEFAULT 0x03C8
+
+#define AX88772A_PHY16H0x16
+#define AX88772A_PHY16H_DEFAULT 0x4044
+
 struct ax88172_int_data {
__le16 res1;
u8 link;
@@ -424,7 +433,7 @@ static int ax88772a_hw_reset(struct usbnet *dev, int in_pm)
 {
struct asix_data *data = (struct asix_data *)>data;
int ret, embd_phy;
-   u16 rx_ctl;
+   u16 rx_ctl, phy14h, phy15h, phy16h;
u8 chipcode = 0;
 
ret = asix_write_gpio(dev, AX_GPIO_RSE, 5, in_pm);
@@ -482,6 +491,32 @@ static int ax88772a_hw_reset(struct usbnet *dev, int in_pm)
   ret);
goto out;
}
+   } else if ((chipcode & AX_CHIPCODE_MASK) == AX_AX88772A_CHIPCODE) {
+   /* Check if the PHY registers have default settings */
+   phy14h = asix_mdio_read_nopm(dev->net, dev->mii.phy_id,
+AX88772A_PHY14H);
+   phy15h = asix_mdio_read_nopm(dev->net, dev->mii.phy_id,
+AX88772A_PHY15H);
+   phy16h = asix_mdio_read_nopm(dev->net, dev->mii.phy_id,
+AX88772A_PHY16H);
+
+   netdev_dbg(dev->net,
+  "772a_hw_reset: MR20=0x%x MR21=0x%x MR22=0x%x\n",
+  phy14h, phy15h, phy16h);
+
+   /* Restore PHY registers default setting if not */
+   if (phy14h != AX88772A_PHY14H_DEFAULT)
+   asix_mdio_write_nopm(dev->net, dev->mii.phy_id,
+AX88772A_PHY14H,
+AX88772A_PHY14H_DEFAULT);
+   if (phy15h != AX88772A_PHY15H_DEFAULT)
+   asix_mdio_write_nopm(dev->net, dev->mii.phy_id,
+AX88772A_PHY15H,
+AX88772A_PHY15H_DEFAULT);
+   if (phy16h != AX88772A_PHY16H_DEFAULT)
+   asix_mdio_write_nopm(dev->net, dev->mii.phy_id,
+AX88772A_PHY16H,
+AX88772A_PHY16H_DEFAULT);
}
 
ret = asix_write_cmd(dev, AX_CMD_WRITE_IPG0,
@@ -543,6 +578,15 @@ static const struct net_device_ops ax88772_netdev_ops = {
 static void ax88772_suspend(struct usbnet *dev)
 {
struct asix_common_private *priv = dev->driver_priv;
+   u16 medium;
+
+   /* Stop MAC operation */
+   medium = asix_read_medium_status(dev, 0);
+   medium &= ~AX_MEDIUM_RE;
+   asix_write_medium_mode(dev, medium, 0);
+
+   netdev_dbg(dev->net, "ax88772_suspend: medium=0x%04x\n",
+  asix_read_medium_status(dev, 0));
 
/* Preserve BMCR for restoring */
priv->presvd_phy_bmcr =
@@ -577,6 +621,7 @@ static void ax88772_restore_phy(struct usbnet *dev)
asix_mdio_write_nopm(dev->net, dev->mii.phy_id, MII_BMCR,
 priv->presvd_phy_bmcr);
 
+   mii_nway_restart(>mii);
priv->presvd_phy_advertise = 0;
priv->presvd_phy_bmcr = 0;
}
-- 
git-series 0.8.10
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/5] net: asix: Avoid looping when the device is disconnected

[robert . foss]

From: Vincent Palatin 

Check the answers from the USB stack and avoid re-sending multiple times
the request if the device has disappeared.

Signed-off-by: Vincent Palatin 
Signed-off-by: Robert Foss 
Tested-by: Robert Foss 
---
 drivers/net/usb/asix_common.c  | 56 +-
 drivers/net/usb/asix_devices.c |  2 ++
 2 files changed, 46 insertions(+), 12 deletions(-)

diff --git a/drivers/net/usb/asix_common.c b/drivers/net/usb/asix_common.c
index 25609ee..f79eb12 100644
--- a/drivers/net/usb/asix_common.c
+++ b/drivers/net/usb/asix_common.c
@@ -428,13 +428,21 @@ int asix_mdio_read(struct net_device *netdev, int phy_id, 
int loc)
__le16 res;
u8 smsr;
int i = 0;
+   int ret;
 
mutex_lock(>phy_mutex);
do {
-   asix_set_sw_mii(dev, 0);
+   ret = asix_set_sw_mii(dev, 0);
+   if (ret == -ENODEV)
+   break;
usleep_range(1000, 1100);
-   asix_read_cmd(dev, AX_CMD_STATMNGSTS_REG, 0, 0, 1, , 0);
-   } while (!(smsr & AX_HOST_EN) && (i++ < 30));
+   ret = asix_read_cmd(dev, AX_CMD_STATMNGSTS_REG,
+   0, 0, 1, , 0);
+   } while (!(smsr & AX_HOST_EN) && (i++ < 30) && (ret != -ENODEV));
+   if (ret == -ENODEV) {
+   mutex_unlock(>phy_mutex);
+   return ret;
+   }
 
asix_read_cmd(dev, AX_CMD_READ_MII_REG, phy_id,
(__u16)loc, 2, , 0);
@@ -453,16 +461,24 @@ void asix_mdio_write(struct net_device *netdev, int 
phy_id, int loc, int val)
__le16 res = cpu_to_le16(val);
u8 smsr;
int i = 0;
+   int ret;
 
netdev_dbg(dev->net, "asix_mdio_write() phy_id=0x%02x, loc=0x%02x, 
val=0x%04x\n",
phy_id, loc, val);
 
mutex_lock(>phy_mutex);
do {
-   asix_set_sw_mii(dev, 0);
+   ret = asix_set_sw_mii(dev, 0);
+   if (ret == -ENODEV)
+   break;
usleep_range(1000, 1100);
-   asix_read_cmd(dev, AX_CMD_STATMNGSTS_REG, 0, 0, 1, , 0);
-   } while (!(smsr & AX_HOST_EN) && (i++ < 30));
+   ret = asix_read_cmd(dev, AX_CMD_STATMNGSTS_REG,
+   0, 0, 1, , 0);
+   } while (!(smsr & AX_HOST_EN) && (i++ < 30) && (ret != -ENODEV));
+   if (ret == -ENODEV) {
+   mutex_unlock(>phy_mutex);
+   return;
+   }
 
asix_write_cmd(dev, AX_CMD_WRITE_MII_REG, phy_id,
   (__u16)loc, 2, , 0);
@@ -476,13 +492,21 @@ int asix_mdio_read_nopm(struct net_device *netdev, int 
phy_id, int loc)
__le16 res;
u8 smsr;
int i = 0;
+   int ret;
 
mutex_lock(>phy_mutex);
do {
-   asix_set_sw_mii(dev, 1);
+   ret = asix_set_sw_mii(dev, 1);
+   if (ret == -ENODEV)
+   break;
usleep_range(1000, 1100);
-   asix_read_cmd(dev, AX_CMD_STATMNGSTS_REG, 0, 0, 1, , 1);
-   } while (!(smsr & AX_HOST_EN) && (i++ < 30));
+   ret = asix_read_cmd(dev, AX_CMD_STATMNGSTS_REG,
+   0, 0, 1, , 1);
+   } while (!(smsr & AX_HOST_EN) && (i++ < 30) && (ret != -ENODEV));
+   if (ret == -ENODEV) {
+   mutex_unlock(>phy_mutex);
+   return ret;
+   }
 
asix_read_cmd(dev, AX_CMD_READ_MII_REG, phy_id,
  (__u16)loc, 2, , 1);
@@ -502,16 +526,24 @@ asix_mdio_write_nopm(struct net_device *netdev, int 
phy_id, int loc, int val)
__le16 res = cpu_to_le16(val);
u8 smsr;
int i = 0;
+   int ret;
 
netdev_dbg(dev->net, "asix_mdio_write() phy_id=0x%02x, loc=0x%02x, 
val=0x%04x\n",
phy_id, loc, val);
 
mutex_lock(>phy_mutex);
do {
-   asix_set_sw_mii(dev, 1);
+   ret = asix_set_sw_mii(dev, 1);
+   if (ret == -ENODEV)
+   break;
usleep_range(1000, 1100);
-   asix_read_cmd(dev, AX_CMD_STATMNGSTS_REG, 0, 0, 1, , 1);
-   } while (!(smsr & AX_HOST_EN) && (i++ < 30));
+   ret = asix_read_cmd(dev, AX_CMD_STATMNGSTS_REG,
+   0, 0, 1, , 1);
+   } while (!(smsr & AX_HOST_EN) && (i++ < 30) && (ret != -ENODEV));
+   if (ret == -ENODEV) {
+   mutex_unlock(>phy_mutex);
+   return;
+   }
 
asix_write_cmd(dev, AX_CMD_WRITE_MII_REG, phy_id,
   (__u16)loc, 2, , 1);
diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index aaa4290..ebeb730 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -79,6 +79,8 @@ static u32 asix_get_phyid(struct usbnet 

Re: [PATCHv6 1/3] usb: USB Type-C connector class

[Heikki Krogerus]

On Mon, Aug 29, 2016 at 06:04:52AM -0700, Guenter Roeck wrote:
> Heikki,
> 
> On 08/26/2016 07:07 AM, Heikki Krogerus wrote:
> > 
> > > > > > +What:  /sys/class/typec/-partner/type
> > > > > > +Date:  June 2016
> > > > > > +Contact:   Heikki Krogerus 
> > > > > > +Description:
> > > > > > +   Shows the type of the partner. Can be one of the 
> > > > > > following:
> > > > > > +   - USB - When the partner is normal USB 
> > > > > > host/peripheral.
> > > > > > +   - Charger - When the partner has been identified as 
> > > > > > dedicated
> > > > > > +   charger.
> > > > > > +   - Alternate Mode - When the partner supports 
> > > > > > Alternate Modes.
> > > > > > +   - Accessory - When the partner is one of the 
> > > > > > accessories with
> > > > > > + specific Accessory Mode defined in 
> > > > > > USB Type-C
> > > > > > + specification.
> > > > > 
> > > > > 
> > > > > where a dock would be classified ?
> > > > 
> > > > A dock is just USB PD capable device with a bunch of alternate modes
> > > > that is attached to the port. There is no specific identifier for a
> > > > "dock".
> > > 
> > > My remark was a bit too stern,
> > > I meant a dock might be 'USB' 'Charger' 'Alternate Mode' , all at the
> > > same time or alternately depending what you plug in.
> > > I don't really see those types as mutually exclusive.
> > 
> > So USB type means the partner does not have alternate modes (I'll
> > clear that in the documentation), Charger is a dedicated charger and
> > therefore can not be anything else (no USB, no alternate modes).
> > 
> 
> This is probably the most difficult attribute to support.
> 
> Many PD capable chargers support alternate modes (for firmware upgrades).
> As I mentioned earlier, it is difficult to match reported Type-C partner
> types (or really anything reported in the SVDM Identity command)
> to the above types.
> 
> Does it really make sense to deviate that much from the Type-C specification ?
> I can understand why you hesitate to use DFP / UFP, as those terms are
> really hard to understand for the non-initiated. However, here it is really
> difficult to even determine which value to set. The best I can come up with is
> 
> - Not PD capable. Report USB (obviously includes non-PD capable chargers)
> - PD capable, supports alternate modes. Report as Alternate Mode (including
>   PD chargers supporting alternate modes)
> - PD capable, does not support alternate modes. Report as Accessory if
>   connected as accessory, as charger if we the port is connected as sink,
>   USB otherwise
> 
> Overall this is quite vague and, especially for chargers, most of the time
> misses the point.
> 
> I would really prefer if we could stay closer to the specification in this
> case, and not try to merge multiple orthogonal attributes into one.

OK. So what would you propose?


Thanks,

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

[PATCH v3 0/5] net/usb: asix driver improvements

[robert . foss]

From: Robert Foss 

This is a resubmission of v3, since the netdev
mailinlist was not sent the previous submission.

This series improves power management of the asix driver.

 - Suspend/resume support is improved to save needed registers.
 - Device disconnection is improved.
 - Fixes AX88772x resume failures
 - Implementes IEEE 802.3 spec section "22.2.4.1.1 Reset" correctly
 - Fixes AX_CMD_WRITE_MEDIUM_MODE being set incorrectly

Changes since v1:
- Added proper metadata tags to series.
- Added two more patches to series.

Changes since v2:
- Added coverletter
- Tested patches on AX88772A/AX88772B/AX88178/AX88179 hardware

Allan Chou (1):
  net: asix: Fix AX88772x resume failures

Freddy Xin (1):
  net: asix: Add in_pm parameter

Grant Grundler (2):
  net: asix: see 802.3 spec for phy reset
  net: asix: autoneg will set WRITE_MEDIUM reg

Vincent Palatin (1):
  net: asix: Avoid looping when the device is disconnected

 drivers/net/usb/asix.h |  40 ++-
 drivers/net/usb/asix_common.c  | 212 
 drivers/net/usb/asix_devices.c | 450 +++---
 drivers/net/usb/ax88172a.c |  29 +-
 4 files changed, 575 insertions(+), 156 deletions(-)

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

[PATCH v3 5/5] net: asix: autoneg will set WRITE_MEDIUM reg

[robert . foss]

From: Grant Grundler 

The miii_nway_restart() causes a PHY link change activity and
ax88772_link_reset will be called. link_reset will set
AX_CMD_WRITE_MEDIUM_MODE register correctly.

The asix_write_medium_mode in reset() fills in a default value to the register
which may be different from the negotiation result. So do this first.

Ignore the ret value since it's ignored in XXX_link_reset() functions.

Signed-off-by: Grant Grundler 
Signed-off-by: Robert Foss 
Tested-by: Robert Foss 
---
 drivers/net/usb/asix_devices.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index dbcdda2..cce2495 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -928,12 +928,9 @@ static int ax88178_reset(struct usbnet *dev)
asix_mdio_write(dev->net, dev->mii.phy_id, MII_CTRL1000,
ADVERTISE_1000FULL);
 
+   asix_write_medium_mode(dev, AX88178_MEDIUM_DEFAULT, 0);
mii_nway_restart(>mii);
 
-   ret = asix_write_medium_mode(dev, AX88178_MEDIUM_DEFAULT, 0);
-   if (ret < 0)
-   return ret;
-
/* Rewrite MAC address */
memcpy(data->mac_addr, dev->net->dev_addr, ETH_ALEN);
ret = asix_write_cmd(dev, AX_CMD_WRITE_NODE_ID, 0, 0, ETH_ALEN,
-- 
2.7.4

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

[PATCH v3 3/5] net: asix: Fix AX88772x resume failures

[robert . foss]

From: Allan Chou 

The change fixes AX88772x resume failure by
- Restore incorrect AX88772A PHY registers when resetting
- Need to stop MAC operation when suspending
- Need to restart MII when restoring PHY

Signed-off-by: Allan Chou 
Signed-off-by: Robert Foss 
Tested-by: Robert Foss 
---
 drivers/net/usb/asix_devices.c | 47 +-
 1 file changed, 46 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index ebeb730..083dc2e 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -35,6 +35,15 @@
 
 #definePHY_MODE_RTL8211CL  0x000C
 
+#define AX88772A_PHY14H0x14
+#define AX88772A_PHY14H_DEFAULT 0x442C
+
+#define AX88772A_PHY15H0x15
+#define AX88772A_PHY15H_DEFAULT 0x03C8
+
+#define AX88772A_PHY16H0x16
+#define AX88772A_PHY16H_DEFAULT 0x4044
+
 struct ax88172_int_data {
__le16 res1;
u8 link;
@@ -424,7 +433,7 @@ static int ax88772a_hw_reset(struct usbnet *dev, int in_pm)
 {
struct asix_data *data = (struct asix_data *)>data;
int ret, embd_phy;
-   u16 rx_ctl;
+   u16 rx_ctl, phy14h, phy15h, phy16h;
u8 chipcode = 0;
 
ret = asix_write_gpio(dev, AX_GPIO_RSE, 5, in_pm);
@@ -482,6 +491,32 @@ static int ax88772a_hw_reset(struct usbnet *dev, int in_pm)
   ret);
goto out;
}
+   } else if ((chipcode & AX_CHIPCODE_MASK) == AX_AX88772A_CHIPCODE) {
+   /* Check if the PHY registers have default settings */
+   phy14h = asix_mdio_read_nopm(dev->net, dev->mii.phy_id,
+AX88772A_PHY14H);
+   phy15h = asix_mdio_read_nopm(dev->net, dev->mii.phy_id,
+AX88772A_PHY15H);
+   phy16h = asix_mdio_read_nopm(dev->net, dev->mii.phy_id,
+AX88772A_PHY16H);
+
+   netdev_dbg(dev->net,
+  "772a_hw_reset: MR20=0x%x MR21=0x%x MR22=0x%x\n",
+  phy14h, phy15h, phy16h);
+
+   /* Restore PHY registers default setting if not */
+   if (phy14h != AX88772A_PHY14H_DEFAULT)
+   asix_mdio_write_nopm(dev->net, dev->mii.phy_id,
+AX88772A_PHY14H,
+AX88772A_PHY14H_DEFAULT);
+   if (phy15h != AX88772A_PHY15H_DEFAULT)
+   asix_mdio_write_nopm(dev->net, dev->mii.phy_id,
+AX88772A_PHY15H,
+AX88772A_PHY15H_DEFAULT);
+   if (phy16h != AX88772A_PHY16H_DEFAULT)
+   asix_mdio_write_nopm(dev->net, dev->mii.phy_id,
+AX88772A_PHY16H,
+AX88772A_PHY16H_DEFAULT);
}
 
ret = asix_write_cmd(dev, AX_CMD_WRITE_IPG0,
@@ -543,6 +578,15 @@ static const struct net_device_ops ax88772_netdev_ops = {
 static void ax88772_suspend(struct usbnet *dev)
 {
struct asix_common_private *priv = dev->driver_priv;
+   u16 medium;
+
+   /* Stop MAC operation */
+   medium = asix_read_medium_status(dev, 0);
+   medium &= ~AX_MEDIUM_RE;
+   asix_write_medium_mode(dev, medium, 0);
+
+   netdev_dbg(dev->net, "ax88772_suspend: medium=0x%04x\n",
+  asix_read_medium_status(dev, 0));
 
/* Preserve BMCR for restoring */
priv->presvd_phy_bmcr =
@@ -577,6 +621,7 @@ static void ax88772_restore_phy(struct usbnet *dev)
asix_mdio_write_nopm(dev->net, dev->mii.phy_id, MII_BMCR,
 priv->presvd_phy_bmcr);
 
+   mii_nway_restart(>mii);
priv->presvd_phy_advertise = 0;
priv->presvd_phy_bmcr = 0;
}
-- 
2.7.4

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

[PATCH v3 5/5] net: asix: autoneg will set WRITE_MEDIUM reg

[robert . foss]

From: Robert Foss 

From: Grant Grundler 

The miii_nway_restart() causes a PHY link change activity and
ax88772_link_reset will be called. link_reset will set
AX_CMD_WRITE_MEDIUM_MODE register correctly.

The asix_write_medium_mode in reset() fills in a default value to the register
which may be different from the negotiation result. So do this first.

Ignore the ret value since it's ignored in XXX_link_reset() functions.

Signed-off-by: Grant Grundler 
Signed-off-by: Robert Foss 
Tested-by: Robert Foss 
---
 drivers/net/usb/asix_devices.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index dbcdda2..cce2495 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -928,12 +928,9 @@ static int ax88178_reset(struct usbnet *dev)
asix_mdio_write(dev->net, dev->mii.phy_id, MII_CTRL1000,
ADVERTISE_1000FULL);
 
+   asix_write_medium_mode(dev, AX88178_MEDIUM_DEFAULT, 0);
mii_nway_restart(>mii);
 
-   ret = asix_write_medium_mode(dev, AX88178_MEDIUM_DEFAULT, 0);
-   if (ret < 0)
-   return ret;
-
/* Rewrite MAC address */
memcpy(data->mac_addr, dev->net->dev_addr, ETH_ALEN);
ret = asix_write_cmd(dev, AX_CMD_WRITE_NODE_ID, 0, 0, ETH_ALEN,
-- 
git-series 0.8.10
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 4/5] net: asix: see 802.3 spec for phy reset

[robert . foss]

From: Grant Grundler 

https://lkml.org/lkml/2014/11/11/947

Ben Hutchings is correct. IEEE 802.3 spec section "22.2.4.1.1 Reset" requires
up to 500ms delay. Mitigate the "max" delay by polling the phy until BCM_RESET
bit is clear.

Signed-off-by: Grant Grundler 
Signed-off-by: Robert Foss 
Tested-by: Robert Foss 
---
 drivers/net/usb/asix_devices.c | 27 ---
 1 file changed, 24 insertions(+), 3 deletions(-)

diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index 083dc2e..dbcdda2 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -212,6 +212,28 @@ static const struct net_device_ops ax88172_netdev_ops = {
.ndo_set_rx_mode= ax88172_set_multicast,
 };
 
+static void asix_phy_reset(struct usbnet *dev, unsigned int reset_bits)
+{
+   unsigned int timeout = 5000;
+
+   asix_mdio_write(dev->net, dev->mii.phy_id, MII_BMCR, reset_bits);
+
+   /* give phy_id a chance to process reset */
+   udelay(500);
+
+   /* See IEEE 802.3 "22.2.4.1.1 Reset": 500ms max */
+   while (timeout--) {
+   if (asix_mdio_read(dev->net, dev->mii.phy_id, MII_BMCR)
+   & BMCR_RESET)
+   udelay(100);
+   else
+   return;
+   }
+
+   netdev_err(dev->net, "BMCR_RESET timeout on phy_id %d\n",
+  dev->mii.phy_id);
+}
+
 static int ax88172_bind(struct usbnet *dev, struct usb_interface *intf)
 {
int ret = 0;
@@ -258,7 +280,7 @@ static int ax88172_bind(struct usbnet *dev, struct 
usb_interface *intf)
dev->net->needed_headroom = 4; /* cf asix_tx_fixup() */
dev->net->needed_tailroom = 4; /* cf asix_tx_fixup() */
 
-   asix_mdio_write(dev->net, dev->mii.phy_id, MII_BMCR, BMCR_RESET);
+   asix_phy_reset(dev, BMCR_RESET);
asix_mdio_write(dev->net, dev->mii.phy_id, MII_ADVERTISE,
ADVERTISE_ALL | ADVERTISE_CSMA | ADVERTISE_PAUSE_CAP);
mii_nway_restart(>mii);
@@ -900,8 +922,7 @@ static int ax88178_reset(struct usbnet *dev)
} else if (data->phymode == PHY_MODE_RTL8211CL)
rtl8211cl_phy_init(dev);
 
-   asix_mdio_write(dev->net, dev->mii.phy_id, MII_BMCR,
-   BMCR_RESET | BMCR_ANENABLE);
+   asix_phy_reset(dev, BMCR_RESET | BMCR_ANENABLE);
asix_mdio_write(dev->net, dev->mii.phy_id, MII_ADVERTISE,
ADVERTISE_ALL | ADVERTISE_CSMA | ADVERTISE_PAUSE_CAP);
asix_mdio_write(dev->net, dev->mii.phy_id, MII_CTRL1000,
-- 
2.7.4

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

[PATCH v3 1/5] net: asix: Add in_pm parameter

[robert . foss]

From: Freddy Xin 

In order to R/W registers in suspend/resume functions, in_pm flags are
added to some functions to determine whether the nopm version of usb
functions is called.

Save BMCR and ANAR PHY registers in suspend function and restore them
in resume function.

Reset HW in resume function to ensure the PHY works correctly.

Signed-off-by: Freddy Xin 
Signed-off-by: Robert Foss 
Tested-by: Robert Foss 
---
 drivers/net/usb/asix.h |  40 +++--
 drivers/net/usb/asix_common.c  | 180 +++-
 drivers/net/usb/asix_devices.c | 373 -
 drivers/net/usb/ax88172a.c |  29 ++--
 4 files changed, 472 insertions(+), 150 deletions(-)

diff --git a/drivers/net/usb/asix.h b/drivers/net/usb/asix.h
index a2d3ea6..d109242 100644
--- a/drivers/net/usb/asix.h
+++ b/drivers/net/usb/asix.h
@@ -46,6 +46,7 @@
 #define AX_CMD_SET_SW_MII  0x06
 #define AX_CMD_READ_MII_REG0x07
 #define AX_CMD_WRITE_MII_REG   0x08
+#define AX_CMD_STATMNGSTS_REG  0x09
 #define AX_CMD_SET_HW_MII  0x0a
 #define AX_CMD_READ_EEPROM 0x0b
 #define AX_CMD_WRITE_EEPROM0x0c
@@ -71,6 +72,17 @@
 #define AX_CMD_SW_RESET0x20
 #define AX_CMD_SW_PHY_STATUS   0x21
 #define AX_CMD_SW_PHY_SELECT   0x22
+#define AX_QCTCTRL 0x2A
+
+#define AX_CHIPCODE_MASK   0x70
+#define AX_AX88772_CHIPCODE0x00
+#define AX_AX88772A_CHIPCODE   0x10
+#define AX_AX88772B_CHIPCODE   0x20
+#define AX_HOST_EN 0x01
+
+#define AX_PHYSEL_PSEL 0x01
+#define AX_PHYSEL_SSMII0
+#define AX_PHYSEL_SSEN 0x10
 
 #define AX_PHY_SELECT_MASK (BIT(3) | BIT(2))
 #define AX_PHY_SELECT_INTERNAL 0
@@ -173,6 +185,10 @@ struct asix_rx_fixup_info {
 };
 
 struct asix_common_private {
+   void (*resume)(struct usbnet *dev);
+   void (*suspend)(struct usbnet *dev);
+   u16 presvd_phy_advertise;
+   u16 presvd_phy_bmcr;
struct asix_rx_fixup_info rx_fixup_info;
 };
 
@@ -182,10 +198,10 @@ extern const struct driver_info ax88172a_info;
 #define FLAG_EEPROM_MAC(1UL << 0)  /* init device MAC from 
eeprom */
 
 int asix_read_cmd(struct usbnet *dev, u8 cmd, u16 value, u16 index,
- u16 size, void *data);
+ u16 size, void *data, int in_pm);
 
 int asix_write_cmd(struct usbnet *dev, u8 cmd, u16 value, u16 index,
-  u16 size, void *data);
+  u16 size, void *data, int in_pm);
 
 void asix_write_cmd_async(struct usbnet *dev, u8 cmd, u16 value,
  u16 index, u16 size, void *data);
@@ -197,27 +213,31 @@ int asix_rx_fixup_common(struct usbnet *dev, struct 
sk_buff *skb);
 struct sk_buff *asix_tx_fixup(struct usbnet *dev, struct sk_buff *skb,
  gfp_t flags);
 
-int asix_set_sw_mii(struct usbnet *dev);
-int asix_set_hw_mii(struct usbnet *dev);
+int asix_set_sw_mii(struct usbnet *dev, int in_pm);
+int asix_set_hw_mii(struct usbnet *dev, int in_pm);
 
 int asix_read_phy_addr(struct usbnet *dev, int internal);
 int asix_get_phy_addr(struct usbnet *dev);
 
-int asix_sw_reset(struct usbnet *dev, u8 flags);
+int asix_sw_reset(struct usbnet *dev, u8 flags, int in_pm);
 
-u16 asix_read_rx_ctl(struct usbnet *dev);
-int asix_write_rx_ctl(struct usbnet *dev, u16 mode);
+u16 asix_read_rx_ctl(struct usbnet *dev, int in_pm);
+int asix_write_rx_ctl(struct usbnet *dev, u16 mode, int in_pm);
 
-u16 asix_read_medium_status(struct usbnet *dev);
-int asix_write_medium_mode(struct usbnet *dev, u16 mode);
+u16 asix_read_medium_status(struct usbnet *dev, int in_pm);
+int asix_write_medium_mode(struct usbnet *dev, u16 mode, int in_pm);
 
-int asix_write_gpio(struct usbnet *dev, u16 value, int sleep);
+int asix_write_gpio(struct usbnet *dev, u16 value, int sleep, int in_pm);
 
 void asix_set_multicast(struct net_device *net);
 
 int asix_mdio_read(struct net_device *netdev, int phy_id, int loc);
 void asix_mdio_write(struct net_device *netdev, int phy_id, int loc, int val);
 
+int asix_mdio_read_nopm(struct net_device *netdev, int phy_id, int loc);
+void asix_mdio_write_nopm(struct net_device *netdev, int phy_id, int loc,
+ int val);
+
 void asix_get_wol(struct net_device *net, struct ethtool_wolinfo *wolinfo);
 int asix_set_wol(struct net_device *net, struct ethtool_wolinfo *wolinfo);
 
diff --git a/drivers/net/usb/asix_common.c b/drivers/net/usb/asix_common.c
index 7de5ab5..25609ee 100644
--- a/drivers/net/usb/asix_common.c
+++ b/drivers/net/usb/asix_common.c
@@ -22,24 +22,49 @@
 #include "asix.h"
 
 int asix_read_cmd(struct usbnet *dev, u8 cmd, u16 value, u16 index,
- u16 size, void *data)
+ u16 size, void *data, int 

[PATCH v3 4/5] net: asix: see 802.3 spec for phy reset

[robert . foss]

From: Robert Foss 

From: Grant Grundler 

https://lkml.org/lkml/2014/11/11/947

Ben Hutchings is correct. IEEE 802.3 spec section "22.2.4.1.1 Reset" requires
up to 500ms delay. Mitigate the "max" delay by polling the phy until BCM_RESET
bit is clear.

Signed-off-by: Grant Grundler 
Signed-off-by: Robert Foss 
Tested-by: Robert Foss 
---
 drivers/net/usb/asix_devices.c | 27 ---
 1 file changed, 24 insertions(+), 3 deletions(-)

diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index 083dc2e..dbcdda2 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -212,6 +212,28 @@ static const struct net_device_ops ax88172_netdev_ops = {
.ndo_set_rx_mode= ax88172_set_multicast,
 };
 
+static void asix_phy_reset(struct usbnet *dev, unsigned int reset_bits)
+{
+   unsigned int timeout = 5000;
+
+   asix_mdio_write(dev->net, dev->mii.phy_id, MII_BMCR, reset_bits);
+
+   /* give phy_id a chance to process reset */
+   udelay(500);
+
+   /* See IEEE 802.3 "22.2.4.1.1 Reset": 500ms max */
+   while (timeout--) {
+   if (asix_mdio_read(dev->net, dev->mii.phy_id, MII_BMCR)
+   & BMCR_RESET)
+   udelay(100);
+   else
+   return;
+   }
+
+   netdev_err(dev->net, "BMCR_RESET timeout on phy_id %d\n",
+  dev->mii.phy_id);
+}
+
 static int ax88172_bind(struct usbnet *dev, struct usb_interface *intf)
 {
int ret = 0;
@@ -258,7 +280,7 @@ static int ax88172_bind(struct usbnet *dev, struct 
usb_interface *intf)
dev->net->needed_headroom = 4; /* cf asix_tx_fixup() */
dev->net->needed_tailroom = 4; /* cf asix_tx_fixup() */
 
-   asix_mdio_write(dev->net, dev->mii.phy_id, MII_BMCR, BMCR_RESET);
+   asix_phy_reset(dev, BMCR_RESET);
asix_mdio_write(dev->net, dev->mii.phy_id, MII_ADVERTISE,
ADVERTISE_ALL | ADVERTISE_CSMA | ADVERTISE_PAUSE_CAP);
mii_nway_restart(>mii);
@@ -900,8 +922,7 @@ static int ax88178_reset(struct usbnet *dev)
} else if (data->phymode == PHY_MODE_RTL8211CL)
rtl8211cl_phy_init(dev);
 
-   asix_mdio_write(dev->net, dev->mii.phy_id, MII_BMCR,
-   BMCR_RESET | BMCR_ANENABLE);
+   asix_phy_reset(dev, BMCR_RESET | BMCR_ANENABLE);
asix_mdio_write(dev->net, dev->mii.phy_id, MII_ADVERTISE,
ADVERTISE_ALL | ADVERTISE_CSMA | ADVERTISE_PAUSE_CAP);
asix_mdio_write(dev->net, dev->mii.phy_id, MII_CTRL1000,
-- 
git-series 0.8.10
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/5] net: asix: Avoid looping when the device is disconnected

[robert . foss]

From: Robert Foss 

From: Vincent Palatin 

Check the answers from the USB stack and avoid re-sending multiple times
the request if the device has disappeared.

Signed-off-by: Vincent Palatin 
Signed-off-by: Robert Foss 
Tested-by: Robert Foss 
---
 drivers/net/usb/asix_common.c  | 56 +++
 drivers/net/usb/asix_devices.c |  2 +-
 2 files changed, 46 insertions(+), 12 deletions(-)

diff --git a/drivers/net/usb/asix_common.c b/drivers/net/usb/asix_common.c
index 25609ee..f79eb12 100644
--- a/drivers/net/usb/asix_common.c
+++ b/drivers/net/usb/asix_common.c
@@ -428,13 +428,21 @@ int asix_mdio_read(struct net_device *netdev, int phy_id, 
int loc)
__le16 res;
u8 smsr;
int i = 0;
+   int ret;
 
mutex_lock(>phy_mutex);
do {
-   asix_set_sw_mii(dev, 0);
+   ret = asix_set_sw_mii(dev, 0);
+   if (ret == -ENODEV)
+   break;
usleep_range(1000, 1100);
-   asix_read_cmd(dev, AX_CMD_STATMNGSTS_REG, 0, 0, 1, , 0);
-   } while (!(smsr & AX_HOST_EN) && (i++ < 30));
+   ret = asix_read_cmd(dev, AX_CMD_STATMNGSTS_REG,
+   0, 0, 1, , 0);
+   } while (!(smsr & AX_HOST_EN) && (i++ < 30) && (ret != -ENODEV));
+   if (ret == -ENODEV) {
+   mutex_unlock(>phy_mutex);
+   return ret;
+   }
 
asix_read_cmd(dev, AX_CMD_READ_MII_REG, phy_id,
(__u16)loc, 2, , 0);
@@ -453,16 +461,24 @@ void asix_mdio_write(struct net_device *netdev, int 
phy_id, int loc, int val)
__le16 res = cpu_to_le16(val);
u8 smsr;
int i = 0;
+   int ret;
 
netdev_dbg(dev->net, "asix_mdio_write() phy_id=0x%02x, loc=0x%02x, 
val=0x%04x\n",
phy_id, loc, val);
 
mutex_lock(>phy_mutex);
do {
-   asix_set_sw_mii(dev, 0);
+   ret = asix_set_sw_mii(dev, 0);
+   if (ret == -ENODEV)
+   break;
usleep_range(1000, 1100);
-   asix_read_cmd(dev, AX_CMD_STATMNGSTS_REG, 0, 0, 1, , 0);
-   } while (!(smsr & AX_HOST_EN) && (i++ < 30));
+   ret = asix_read_cmd(dev, AX_CMD_STATMNGSTS_REG,
+   0, 0, 1, , 0);
+   } while (!(smsr & AX_HOST_EN) && (i++ < 30) && (ret != -ENODEV));
+   if (ret == -ENODEV) {
+   mutex_unlock(>phy_mutex);
+   return;
+   }
 
asix_write_cmd(dev, AX_CMD_WRITE_MII_REG, phy_id,
   (__u16)loc, 2, , 0);
@@ -476,13 +492,21 @@ int asix_mdio_read_nopm(struct net_device *netdev, int 
phy_id, int loc)
__le16 res;
u8 smsr;
int i = 0;
+   int ret;
 
mutex_lock(>phy_mutex);
do {
-   asix_set_sw_mii(dev, 1);
+   ret = asix_set_sw_mii(dev, 1);
+   if (ret == -ENODEV)
+   break;
usleep_range(1000, 1100);
-   asix_read_cmd(dev, AX_CMD_STATMNGSTS_REG, 0, 0, 1, , 1);
-   } while (!(smsr & AX_HOST_EN) && (i++ < 30));
+   ret = asix_read_cmd(dev, AX_CMD_STATMNGSTS_REG,
+   0, 0, 1, , 1);
+   } while (!(smsr & AX_HOST_EN) && (i++ < 30) && (ret != -ENODEV));
+   if (ret == -ENODEV) {
+   mutex_unlock(>phy_mutex);
+   return ret;
+   }
 
asix_read_cmd(dev, AX_CMD_READ_MII_REG, phy_id,
  (__u16)loc, 2, , 1);
@@ -502,16 +526,24 @@ asix_mdio_write_nopm(struct net_device *netdev, int 
phy_id, int loc, int val)
__le16 res = cpu_to_le16(val);
u8 smsr;
int i = 0;
+   int ret;
 
netdev_dbg(dev->net, "asix_mdio_write() phy_id=0x%02x, loc=0x%02x, 
val=0x%04x\n",
phy_id, loc, val);
 
mutex_lock(>phy_mutex);
do {
-   asix_set_sw_mii(dev, 1);
+   ret = asix_set_sw_mii(dev, 1);
+   if (ret == -ENODEV)
+   break;
usleep_range(1000, 1100);
-   asix_read_cmd(dev, AX_CMD_STATMNGSTS_REG, 0, 0, 1, , 1);
-   } while (!(smsr & AX_HOST_EN) && (i++ < 30));
+   ret = asix_read_cmd(dev, AX_CMD_STATMNGSTS_REG,
+   0, 0, 1, , 1);
+   } while (!(smsr & AX_HOST_EN) && (i++ < 30) && (ret != -ENODEV));
+   if (ret == -ENODEV) {
+   mutex_unlock(>phy_mutex);
+   return;
+   }
 
asix_write_cmd(dev, AX_CMD_WRITE_MII_REG, phy_id,
   (__u16)loc, 2, , 1);
diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index aaa4290..ebeb730 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -79,6 +79,8 @@ 

Re: [PATCHv6 1/3] usb: USB Type-C connector class

[Vincent Palatin]

On Mon, Aug 29, 2016 at 2:36 PM, Heikki Krogerus
 wrote:
> The purpose of USB Type-C connector class is to provide
> unified interface for the user space to get the status and
> basic information about USB Type-C connectors on a system,
> control over data role swapping, and when the port supports
> USB Power Delivery, also control over power role swapping
> and Alternate Modes.
>
> Signed-off-by: Heikki Krogerus 


Acked-by: Vincent Palatin 


> ---
>  Documentation/ABI/testing/sysfs-class-typec |  205 +
>  Documentation/usb/typec.txt |  103 +++
>  MAINTAINERS |9 +
>  drivers/usb/Kconfig |2 +
>  drivers/usb/Makefile|2 +
>  drivers/usb/typec/Kconfig   |7 +
>  drivers/usb/typec/Makefile  |1 +
>  drivers/usb/typec/typec.c   | 1091 
> +++
>  include/linux/usb/typec.h   |  260 +++
>  9 files changed, 1680 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-class-typec
>  create mode 100644 Documentation/usb/typec.txt
>  create mode 100644 drivers/usb/typec/Kconfig
>  create mode 100644 drivers/usb/typec/Makefile
>  create mode 100644 drivers/usb/typec/typec.c
>  create mode 100644 include/linux/usb/typec.h
>
> diff --git a/Documentation/ABI/testing/sysfs-class-typec 
> b/Documentation/ABI/testing/sysfs-class-typec
> new file mode 100644
> index 000..53fdd11
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-class-typec
> @@ -0,0 +1,205 @@
> +USB Type-C port devices (eg. /sys/class/typec/usbc0/)
> +
> +What:  /sys/class/typec//current_data_role
> +Date:  June 2016
> +Contact:   Heikki Krogerus 
> +Description:
> +   The current USB data role the port is operating in. This
> +   attribute can be used for requesting data role swapping on the
> +   port. Swapping is only supported as an asynchronous operation
> +   and requires polling of the attribute in order to know the
> +   result, so successful write operation does not mean successful
> +   swap.
> +
> +   Valid values:
> +   - host
> +   - device
> +
> +What:  /sys/class/typec//current_power_role
> +Date:  June 2016
> +Contact:   Heikki Krogerus 
> +Description:
> +   The current power role of the port. This attribute can be used
> +   to request power role swap on the port when the port supports
> +   USB Power Delivery. Swapping is only supported as an
> +   asynchronous operation and requires polling of the attribute 
> in
> +   order to know the result, so successful write operation does 
> not
> +   mean successful swap.
> +
> +   Valid values:
> +   - source
> +   - sink
> +
> +What:  /sys/class/typec//vconn_source
> +Date:  June 2016
> +Contact:   Heikki Krogerus 
> +Description:
> +   Shows is the port VCONN Source. This attribute can be used to
> +   request VCONN swap to change the VCONN Source during 
> connection
> +   when both the port and the partner support USB Power Delivery.
> +
> +   Valid values are:
> +   - 0 when the port is not the VCONN Source
> +   - 1 when the port is the VCONN Source
> +
> +What:  /sys/class/typec//power_operation_mode
> +Date:  June 2016
> +Contact:   Heikki Krogerus 
> +Description:
> +   Shows the current power operational mode the port is in.
> +
> +   Valid values:
> +   - USB - Normal power levels defined in USB specifications
> +   - BC1.2 - Power levels defined in Battery Charging 
> Specification
> + v1.2
> +   - USB Type-C 1.5A - Higher 1.5A current defined in USB Type-C
> +   specification.
> +   - USB Type-C 3.0A - Higher 3A current defined in USB Type-C
> +   specification.
> +- USB Power Delivery - The voltages and currents defined in 
> USB
> +  Power Delivery specification
> +
> +What:  /sys/class/typec//preferred_role
> +Date:  June 2016
> +Contact:   Heikki Krogerus 
> +Description:
> +   The user space can notify the driver about the preferred role.
> +   It should be handled as enabling of Try.SRC or Try.SNK, as
> +   defined in USB Type-C specification, in the port drivers. By
> +

Re: [PATCHv6 0/3] USB Type-C Connector class

[Guenter Roeck]

On 08/29/2016 05:36 AM, Heikki Krogerus wrote:

The USB Type-C class is meant to provide unified interface to the
userspace to present the USB Type-C ports in a system.


The subject says "v6".

Guenter



Changes since v6:
- current_vconn_role attr renamed to vconn_source (no API changes)
- Small documentation improvements proposed by Vincent Palatin

Changes since v5:
- Only updating the roles based on driver notifications
- Added MODULE_ALIAS for the WhiskeyCove module
- Including the patch that creates the actual platform device for the
  WhiskeyCove Type-C PHY in this series.

Changes since v4:
- Remove the port lock completely

Changes since v3:
- Documentation cleanup as proposed by Roger Quadros
- Setting partner altmodes member to NULL on removal and fixing a
  warning, as proposed by Guenter Roeck
- Added the following attributes for partners and cables:
  * supports_usb_power_delivery
  * id_header_vdo
- "id_header_vdo" is visible only when the partner or cable supports
  USB Power Delivery communication.
- Partner attribute "accessory" is hidden when the partner type is not
  "Accessory".

Changes since v2:
- Notification on role and alternate mode changes
- cleanups

Changes since v1:
- Completely rewrote alternate mode support
- Patners, cables and cable plugs presented as devices.


Heikki Krogerus (3):
  usb: USB Type-C connector class
  usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY
  mfd: intel_soc_pmic_bxtwc: add support for USB Type-C PHY on
WhiskeyCove

 Documentation/ABI/testing/sysfs-class-typec |  205 +
 Documentation/usb/typec.txt |  103 +++
 MAINTAINERS |9 +
 drivers/mfd/intel_soc_pmic_bxtwc.c  |   11 +
 drivers/usb/Kconfig |2 +
 drivers/usb/Makefile|2 +
 drivers/usb/typec/Kconfig   |   21 +
 drivers/usb/typec/Makefile  |2 +
 drivers/usb/typec/typec.c   | 1091 +++
 drivers/usb/typec/typec_wcove.c |  372 +
 include/linux/usb/typec.h   |  260 +++
 11 files changed, 2078 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-typec
 create mode 100644 Documentation/usb/typec.txt
 create mode 100644 drivers/usb/typec/Kconfig
 create mode 100644 drivers/usb/typec/Makefile
 create mode 100644 drivers/usb/typec/typec.c
 create mode 100644 drivers/usb/typec/typec_wcove.c
 create mode 100644 include/linux/usb/typec.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: [PATCHv6 1/3] usb: USB Type-C connector class

[Guenter Roeck]

Heikki,

On 08/26/2016 07:07 AM, Heikki Krogerus wrote:



+What:  /sys/class/typec/-partner/type
+Date:  June 2016
+Contact:   Heikki Krogerus 
+Description:
+   Shows the type of the partner. Can be one of the following:
+   - USB - When the partner is normal USB host/peripheral.
+   - Charger - When the partner has been identified as dedicated
+   charger.
+   - Alternate Mode - When the partner supports Alternate Modes.
+   - Accessory - When the partner is one of the accessories with
+ specific Accessory Mode defined in USB Type-C
+ specification.



where a dock would be classified ?


A dock is just USB PD capable device with a bunch of alternate modes
that is attached to the port. There is no specific identifier for a
"dock".


My remark was a bit too stern,
I meant a dock might be 'USB' 'Charger' 'Alternate Mode' , all at the
same time or alternately depending what you plug in.
I don't really see those types as mutually exclusive.


So USB type means the partner does not have alternate modes (I'll
clear that in the documentation), Charger is a dedicated charger and
therefore can not be anything else (no USB, no alternate modes).



This is probably the most difficult attribute to support.

Many PD capable chargers support alternate modes (for firmware upgrades).
As I mentioned earlier, it is difficult to match reported Type-C partner
types (or really anything reported in the SVDM Identity command)
to the above types.

Does it really make sense to deviate that much from the Type-C specification ?
I can understand why you hesitate to use DFP / UFP, as those terms are
really hard to understand for the non-initiated. However, here it is really
difficult to even determine which value to set. The best I can come up with is

- Not PD capable. Report USB (obviously includes non-PD capable chargers)
- PD capable, supports alternate modes. Report as Alternate Mode (including
  PD chargers supporting alternate modes)
- PD capable, does not support alternate modes. Report as Accessory if
  connected as accessory, as charger if we the port is connected as sink,
  USB otherwise

Overall this is quite vague and, especially for chargers, most of the time
misses the point.

I would really prefer if we could stay closer to the specification in this
case, and not try to merge multiple orthogonal attributes into one.

Thanks,
Guenter

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

Re: Queries regrading USB-driver software-architecture

[Ajay Garg]

Thanks Felipe and Greg for the replies.

There is no one forcing us to use this kernel.
Would 
http://releases.ubuntu.com/16.04.1/ubuntu-16.04.1-desktop-i386.iso.torrent?_ga=1.67231377.145502248.1467027188
be good enough to install?

On Mon, Aug 29, 2016 at 6:19 PM, Greg KH  wrote:
> On Mon, Aug 29, 2016 at 05:56:03PM +0530, Ajay Garg wrote:
>> Hi All.
>>
>> We have a PC-in-a-box unit, with 2 COM-ports, 2 USB 2.0 ports and 1
>> USB 3.0 port.
>> We are testing the COM-ports (COM1 and COM2) and the USB-ports.
>>
>> We proceeded as follows ::
>>
>> a)
>> In the setup
>>
>> User-App <=> COM1 <=> RS232-data <=> RS232-to-RS485 converter <=>
>> RS485-data <=> Modbus-Device
>>
>> when we send a modbus-command from user-app ==> modbus-device, we
>> receive the modbus-response fine. (Of course, RS232 is enabled for
>> COM1 in BIOS).
>>
>>
>> b)
>> If we modify the setup just a bit as
>>
>> User-App <=> USB-Port <=> USB-Serial-to-RS232 converter <=> Rs232-data
>> <=> RS232-RS485 converter <=> RS485-data <=> Modbus-Device
>>
>> and then send a modbus-command from user-app ==> modbus-device, we DO
>> NOT receive even a single byte as response.
>>
>> Very surprisingly, if we use the above setup in a USB-port of my
>> personal laptop, we get the response fine (thereby signifying that
>> that all elements from USB-Serial-to-RS232 converter <=> Rs232-data
>> <=> RS232-RS485 converter <=> RS485-data <=> Modbus-Device are fine).
>>
>>
>> Some more facts ::
>>
>> 1)
>> uname -a gives identical output for my-laptop and the pc-in-a-box unit ::
>>
>> uname -a
>> Linux blah-blah-login 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan
>> 15 17:45:15 UTC 2015 i686 i686 i686 GNU/Linux
>
> First off, I suggest you get support from the distro you are using, as
> they are the only ones that can give you that.  This is a very old
> kernel release and nothing that the community can help you out with,
> sorry.
>
>> *So, now my question is that given the OS is identical and all
>> "OS-drivers" same, what could be the difference in behaviour on
>> pc-in-a-box and my-laptop?
>> Are some usb-drivers present at hardware/motherboard level too, thus
>> making the "difference in hardware" the root-cause (rather than
>> "difference in software")?*
>
> If you are comparing the default use of a usb to serial converter to a
> serial port on a motherboard, yes, they do sometimes work differently.
> I would suggest checking your hardware flow control settings, lots of
> usb-serial devices default to them enabled, while a "uart on a
> motherboard" defaults to them disabled.  Make sure you really are
> setting everything up identically.
>
> If so, try a newer kernel release.  Again, 3.16 is really old and
> obsolete, we can help you out here if you use a 4.7 or newer kernel.
>
> thanks,
>
> greg k-h



-- 
Regards,
Ajay
--
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: Queries regrading USB-driver software-architecture

[Greg KH]

On Mon, Aug 29, 2016 at 05:56:03PM +0530, Ajay Garg wrote:
> Hi All.
> 
> We have a PC-in-a-box unit, with 2 COM-ports, 2 USB 2.0 ports and 1
> USB 3.0 port.
> We are testing the COM-ports (COM1 and COM2) and the USB-ports.
> 
> We proceeded as follows ::
> 
> a)
> In the setup
> 
> User-App <=> COM1 <=> RS232-data <=> RS232-to-RS485 converter <=>
> RS485-data <=> Modbus-Device
> 
> when we send a modbus-command from user-app ==> modbus-device, we
> receive the modbus-response fine. (Of course, RS232 is enabled for
> COM1 in BIOS).
> 
> 
> b)
> If we modify the setup just a bit as
> 
> User-App <=> USB-Port <=> USB-Serial-to-RS232 converter <=> Rs232-data
> <=> RS232-RS485 converter <=> RS485-data <=> Modbus-Device
> 
> and then send a modbus-command from user-app ==> modbus-device, we DO
> NOT receive even a single byte as response.
> 
> Very surprisingly, if we use the above setup in a USB-port of my
> personal laptop, we get the response fine (thereby signifying that
> that all elements from USB-Serial-to-RS232 converter <=> Rs232-data
> <=> RS232-RS485 converter <=> RS485-data <=> Modbus-Device are fine).
> 
> 
> Some more facts ::
> 
> 1)
> uname -a gives identical output for my-laptop and the pc-in-a-box unit ::
> 
> uname -a
> Linux blah-blah-login 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan
> 15 17:45:15 UTC 2015 i686 i686 i686 GNU/Linux

First off, I suggest you get support from the distro you are using, as
they are the only ones that can give you that.  This is a very old
kernel release and nothing that the community can help you out with,
sorry.

> *So, now my question is that given the OS is identical and all
> "OS-drivers" same, what could be the difference in behaviour on
> pc-in-a-box and my-laptop?
> Are some usb-drivers present at hardware/motherboard level too, thus
> making the "difference in hardware" the root-cause (rather than
> "difference in software")?*

If you are comparing the default use of a usb to serial converter to a
serial port on a motherboard, yes, they do sometimes work differently.
I would suggest checking your hardware flow control settings, lots of
usb-serial devices default to them enabled, while a "uart on a
motherboard" defaults to them disabled.  Make sure you really are
setting everything up identically.

If so, try a newer kernel release.  Again, 3.16 is really old and
obsolete, we can help you out here if you use a 4.7 or newer kernel.

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: Queries regrading USB-driver software-architecture

[Felipe Balbi]

Hi,

Ajay Garg  writes:
> Hi All.
>
> We have a PC-in-a-box unit, with 2 COM-ports, 2 USB 2.0 ports and 1
> USB 3.0 port.
> We are testing the COM-ports (COM1 and COM2) and the USB-ports.
>
> We proceeded as follows ::
>
> a)
> In the setup
>
> User-App <=> COM1 <=> RS232-data <=> RS232-to-RS485 converter <=>
> RS485-data <=> Modbus-Device
>
> when we send a modbus-command from user-app ==> modbus-device, we
> receive the modbus-response fine. (Of course, RS232 is enabled for
> COM1 in BIOS).
>
>
> b)
> If we modify the setup just a bit as
>
> User-App <=> USB-Port <=> USB-Serial-to-RS232 converter <=> Rs232-data
> <=> RS232-RS485 converter <=> RS485-data <=> Modbus-Device
>
> and then send a modbus-command from user-app ==> modbus-device, we DO
> NOT receive even a single byte as response.

which kernel is running on this PC-in-a-box unit?

> Very surprisingly, if we use the above setup in a USB-port of my
> personal laptop, we get the response fine (thereby signifying that
> that all elements from USB-Serial-to-RS232 converter <=> Rs232-data
> <=> RS232-RS485 converter <=> RS485-data <=> Modbus-Device are fine).
>
>
> Some more facts ::
>
> 1)
> uname -a gives identical output for my-laptop and the pc-in-a-box unit ::
>
> uname -a
> Linux blah-blah-login 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan
> 15 17:45:15 UTC 2015 i686 i686 i686 GNU/Linux
>
> 2)
> On the pc-in-a-box-unit, following are some diagnostics that I could think of 
> ::
>
> lsmod | grep usb
> usbnet 37829  1 qmi_wwan
> mii13654  1 usbnet
> usb_wwan   19306  1 qcserial
> usbhid 47035  0
> hid95946  3 i2c_hid,hid_generic,usbhid
> usbserial  38972  8 qcserial,pl2303,usb_wwan
>
> lsmod | grep pl2303
> pl2303 18516  0
> usbserial  38972  8 qcserial,pl2303,usb_wwan
>
> 3)
> The USB-Serial-to-RS232 converter information ::
>
> lsusb
> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 001 Device 007: ID 1199:68a2 Sierra Wireless, Inc.
> Bus 001 Device 005: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
> Bus 001 Device 004: ID 413c:2107 Dell Computer Corp.
> Bus 001 Device 003: ID 046d:c05a Logitech, Inc. M90/M100 Optical Mouse
> *Bus 001 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial 
> Port*
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
>
> 4)
> The checksums of the following drivers are identical on the
> pc-in-a-box unit and my-laptop ::
>
> cksum /lib/modules/3.16.0-30-generic/kernel/drivers/usb/serial/usbserial.ko
> 425603799 59904
> /lib/modules/3.16.0-30-generic/kernel/drivers/usb/serial/usbserial.ko

This kernel is over 2 years old. You need to ask for suport from
whoever's forcing you to use this kernel.

-- 
balbi


signature.asc
Description: PGP signature

[PATCHv6 1/3] usb: USB Type-C connector class

[Heikki Krogerus]

The purpose of USB Type-C connector class is to provide
unified interface for the user space to get the status and
basic information about USB Type-C connectors on a system,
control over data role swapping, and when the port supports
USB Power Delivery, also control over power role swapping
and Alternate Modes.

Signed-off-by: Heikki Krogerus 
---
 Documentation/ABI/testing/sysfs-class-typec |  205 +
 Documentation/usb/typec.txt |  103 +++
 MAINTAINERS |9 +
 drivers/usb/Kconfig |2 +
 drivers/usb/Makefile|2 +
 drivers/usb/typec/Kconfig   |7 +
 drivers/usb/typec/Makefile  |1 +
 drivers/usb/typec/typec.c   | 1091 +++
 include/linux/usb/typec.h   |  260 +++
 9 files changed, 1680 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-typec
 create mode 100644 Documentation/usb/typec.txt
 create mode 100644 drivers/usb/typec/Kconfig
 create mode 100644 drivers/usb/typec/Makefile
 create mode 100644 drivers/usb/typec/typec.c
 create mode 100644 include/linux/usb/typec.h

diff --git a/Documentation/ABI/testing/sysfs-class-typec 
b/Documentation/ABI/testing/sysfs-class-typec
new file mode 100644
index 000..53fdd11
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-typec
@@ -0,0 +1,205 @@
+USB Type-C port devices (eg. /sys/class/typec/usbc0/)
+
+What:  /sys/class/typec//current_data_role
+Date:  June 2016
+Contact:   Heikki Krogerus 
+Description:
+   The current USB data role the port is operating in. This
+   attribute can be used for requesting data role swapping on the
+   port. Swapping is only supported as an asynchronous operation
+   and requires polling of the attribute in order to know the
+   result, so successful write operation does not mean successful
+   swap.
+
+   Valid values:
+   - host
+   - device
+
+What:  /sys/class/typec//current_power_role
+Date:  June 2016
+Contact:   Heikki Krogerus 
+Description:
+   The current power role of the port. This attribute can be used
+   to request power role swap on the port when the port supports
+   USB Power Delivery. Swapping is only supported as an
+   asynchronous operation and requires polling of the attribute in
+   order to know the result, so successful write operation does not
+   mean successful swap.
+
+   Valid values:
+   - source
+   - sink
+
+What:  /sys/class/typec//vconn_source
+Date:  June 2016
+Contact:   Heikki Krogerus 
+Description:
+   Shows is the port VCONN Source. This attribute can be used to
+   request VCONN swap to change the VCONN Source during connection
+   when both the port and the partner support USB Power Delivery.
+
+   Valid values are:
+   - 0 when the port is not the VCONN Source
+   - 1 when the port is the VCONN Source
+
+What:  /sys/class/typec//power_operation_mode
+Date:  June 2016
+Contact:   Heikki Krogerus 
+Description:
+   Shows the current power operational mode the port is in.
+
+   Valid values:
+   - USB - Normal power levels defined in USB specifications
+   - BC1.2 - Power levels defined in Battery Charging Specification
+ v1.2
+   - USB Type-C 1.5A - Higher 1.5A current defined in USB Type-C
+   specification.
+   - USB Type-C 3.0A - Higher 3A current defined in USB Type-C
+   specification.
+- USB Power Delivery - The voltages and currents defined in USB
+  Power Delivery specification
+
+What:  /sys/class/typec//preferred_role
+Date:  June 2016
+Contact:   Heikki Krogerus 
+Description:
+   The user space can notify the driver about the preferred role.
+   It should be handled as enabling of Try.SRC or Try.SNK, as
+   defined in USB Type-C specification, in the port drivers. By
+   default there is no preferred role.
+
+   Valid values:
+   - host
+   - device
+   - For example "none" to remove preference (anything else except
+ "host" or "device")
+
+What:  /sys/class/typec//supported_accessory_modes
+Date:  June 2016
+Contact:   Heikki Krogerus 

[PATCHv6 0/3] USB Type-C Connector class

[Heikki Krogerus]

The USB Type-C class is meant to provide unified interface to the
userspace to present the USB Type-C ports in a system.


Changes since v6:
- current_vconn_role attr renamed to vconn_source (no API changes)
- Small documentation improvements proposed by Vincent Palatin

Changes since v5:
- Only updating the roles based on driver notifications
- Added MODULE_ALIAS for the WhiskeyCove module
- Including the patch that creates the actual platform device for the
  WhiskeyCove Type-C PHY in this series.

Changes since v4:
- Remove the port lock completely

Changes since v3:
- Documentation cleanup as proposed by Roger Quadros
- Setting partner altmodes member to NULL on removal and fixing a
  warning, as proposed by Guenter Roeck
- Added the following attributes for partners and cables:
  * supports_usb_power_delivery
  * id_header_vdo
- "id_header_vdo" is visible only when the partner or cable supports
  USB Power Delivery communication.
- Partner attribute "accessory" is hidden when the partner type is not
  "Accessory".

Changes since v2:
- Notification on role and alternate mode changes
- cleanups

Changes since v1:
- Completely rewrote alternate mode support
- Patners, cables and cable plugs presented as devices.


Heikki Krogerus (3):
  usb: USB Type-C connector class
  usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY
  mfd: intel_soc_pmic_bxtwc: add support for USB Type-C PHY on
WhiskeyCove

 Documentation/ABI/testing/sysfs-class-typec |  205 +
 Documentation/usb/typec.txt |  103 +++
 MAINTAINERS |9 +
 drivers/mfd/intel_soc_pmic_bxtwc.c  |   11 +
 drivers/usb/Kconfig |2 +
 drivers/usb/Makefile|2 +
 drivers/usb/typec/Kconfig   |   21 +
 drivers/usb/typec/Makefile  |2 +
 drivers/usb/typec/typec.c   | 1091 +++
 drivers/usb/typec/typec_wcove.c |  372 +
 include/linux/usb/typec.h   |  260 +++
 11 files changed, 2078 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-typec
 create mode 100644 Documentation/usb/typec.txt
 create mode 100644 drivers/usb/typec/Kconfig
 create mode 100644 drivers/usb/typec/Makefile
 create mode 100644 drivers/usb/typec/typec.c
 create mode 100644 drivers/usb/typec/typec_wcove.c
 create mode 100644 include/linux/usb/typec.h

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

[PATCHv6 2/3] usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY

[Heikki Krogerus]

This adds driver for the USB Type-C PHY on Intel WhiskeyCove
PMIC which is available on some of the Intel Broxton SoC
based platforms.

Signed-off-by: Heikki Krogerus 
---
 drivers/usb/typec/Kconfig   |  14 ++
 drivers/usb/typec/Makefile  |   1 +
 drivers/usb/typec/typec_wcove.c | 372 
 3 files changed, 387 insertions(+)
 create mode 100644 drivers/usb/typec/typec_wcove.c

diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index b229fb9..7a345a4 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -4,4 +4,18 @@ menu "USB PD and Type-C drivers"
 config TYPEC
tristate
 
+config TYPEC_WCOVE
+   tristate "Intel WhiskeyCove PMIC USB Type-C PHY driver"
+   depends on ACPI
+   depends on INTEL_SOC_PMIC
+   depends on INTEL_PMC_IPC
+   select TYPEC
+   help
+ This driver adds support for USB Type-C detection on Intel Broxton
+ platforms that have Intel Whiskey Cove PMIC. The driver can detect the
+ role and cable orientation.
+
+ To compile this driver as module, choose M here: the module will be
+ called typec_wcove
+
 endmenu
diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
index 1012a8b..b9cb862 100644
--- a/drivers/usb/typec/Makefile
+++ b/drivers/usb/typec/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_TYPEC)+= typec.o
+obj-$(CONFIG_TYPEC_WCOVE)  += typec_wcove.o
diff --git a/drivers/usb/typec/typec_wcove.c b/drivers/usb/typec/typec_wcove.c
new file mode 100644
index 000..7116491
--- /dev/null
+++ b/drivers/usb/typec/typec_wcove.c
@@ -0,0 +1,372 @@
+/**
+ * typec_wcove.c - WhiskeyCove PMIC USB Type-C PHY driver
+ *
+ * Copyright (C) 2016 Intel Corporation
+ * Author: Heikki Krogerus 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Register offsets */
+#define WCOVE_CHGRIRQ0 0x4e09
+#define WCOVE_PHYCTRL  0x5e07
+
+#define USBC_CONTROL1  0x7001
+#define USBC_CONTROL2  0x7002
+#define USBC_CONTROL3  0x7003
+#define USBC_CC1_CTRL  0x7004
+#define USBC_CC2_CTRL  0x7005
+#define USBC_STATUS1   0x7007
+#define USBC_STATUS2   0x7008
+#define USBC_STATUS3   0x7009
+#define USBC_IRQ1  0x7015
+#define USBC_IRQ2  0x7016
+#define USBC_IRQMASK1  0x7017
+#define USBC_IRQMASK2  0x7018
+
+/* Register bits */
+
+#define USBC_CONTROL1_MODE_DRP(r)  ((r & ~0x7) | 4)
+
+#define USBC_CONTROL2_UNATT_SNKBIT(0)
+#define USBC_CONTROL2_UNATT_SRCBIT(1)
+#define USBC_CONTROL2_DIS_ST   BIT(2)
+
+#define USBC_CONTROL3_PD_DIS   BIT(1)
+
+#define USBC_CC_CTRL_VCONN_EN  BIT(1)
+
+#define USBC_STATUS1_DET_ONGOING   BIT(6)
+#define USBC_STATUS1_RSLT(r)   (r & 0xf)
+#define USBC_RSLT_NOTHING  0
+#define USBC_RSLT_SRC_DEFAULT  1
+#define USBC_RSLT_SRC_1_5A 2
+#define USBC_RSLT_SRC_3_0A 3
+#define USBC_RSLT_SNK  4
+#define USBC_RSLT_DEBUG_ACC5
+#define USBC_RSLT_AUDIO_ACC6
+#define USBC_RSLT_UNDEF15
+#define USBC_STATUS1_ORIENT(r) ((r >> 4) & 0x3)
+#define USBC_ORIENT_NORMAL 1
+#define USBC_ORIENT_REVERSE2
+
+#define USBC_STATUS2_VBUS_REQ  BIT(5)
+
+#define USBC_IRQ1_ADCDONE1 BIT(2)
+#define USBC_IRQ1_OVERTEMP BIT(1)
+#define USBC_IRQ1_SHORTBIT(0)
+
+#define USBC_IRQ2_CC_CHANGEBIT(7)
+#define USBC_IRQ2_RX_PDBIT(6)
+#define USBC_IRQ2_RX_HRBIT(5)
+#define USBC_IRQ2_RX_CRBIT(4)
+#define USBC_IRQ2_TX_SUCCESS   BIT(3)
+#define USBC_IRQ2_TX_FAIL  BIT(2)
+
+#define USBC_IRQMASK1_ALL  (USBC_IRQ1_ADCDONE1 | USBC_IRQ1_OVERTEMP | \
+USBC_IRQ1_SHORT)
+
+#define USBC_IRQMASK2_ALL  (USBC_IRQ2_CC_CHANGE | USBC_IRQ2_RX_PD | \
+USBC_IRQ2_RX_HR | USBC_IRQ2_RX_CR | \
+USBC_IRQ2_TX_SUCCESS | USBC_IRQ2_TX_FAIL)
+
+struct wcove_typec {
+   struct mutex lock; /* device lock */
+   struct device *dev;
+   struct regmap *regmap;
+   struct typec_port *port;
+   struct typec_capability cap;
+   struct typec_connection con;
+   struct typec_partner partner;
+};
+
+enum wcove_typec_func {
+   WCOVE_FUNC_DRIVE_VBUS = 1,
+   WCOVE_FUNC_ORIENTATION,
+   WCOVE_FUNC_ROLE,
+   WCOVE_FUNC_DRIVE_VCONN,
+};
+
+enum wcove_typec_orientation {
+   WCOVE_ORIENTATION_NORMAL,
+   

[PATCHv6 3/3] mfd: intel_soc_pmic_bxtwc: add support for USB Type-C PHY on WhiskeyCove

[Heikki Krogerus]

Intel WhiskeyCove PMIC has also a USB Type-C PHY, so let's
create a device for it.

Signed-off-by: Heikki Krogerus 
Cc: Lee Jones 
---
 drivers/mfd/intel_soc_pmic_bxtwc.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/mfd/intel_soc_pmic_bxtwc.c 
b/drivers/mfd/intel_soc_pmic_bxtwc.c
index b942876..0e61dde 100644
--- a/drivers/mfd/intel_soc_pmic_bxtwc.c
+++ b/drivers/mfd/intel_soc_pmic_bxtwc.c
@@ -84,6 +84,7 @@ enum bxtwc_irqs_level2 {
BXTWC_THRM2_IRQ,
BXTWC_BCU_IRQ,
BXTWC_ADC_IRQ,
+   BXTWC_USBC_IRQ,
BXTWC_CHGR0_IRQ,
BXTWC_CHGR1_IRQ,
BXTWC_GPIO0_IRQ,
@@ -109,6 +110,7 @@ static const struct regmap_irq bxtwc_regmap_irqs_level2[] = 
{
REGMAP_IRQ_REG(BXTWC_THRM2_IRQ, 2, 0xff),
REGMAP_IRQ_REG(BXTWC_BCU_IRQ, 3, 0x1f),
REGMAP_IRQ_REG(BXTWC_ADC_IRQ, 4, 0xff),
+   REGMAP_IRQ_REG(BXTWC_USBC_IRQ, 5, BIT(5)),
REGMAP_IRQ_REG(BXTWC_CHGR0_IRQ, 5, 0x1f),
REGMAP_IRQ_REG(BXTWC_CHGR1_IRQ, 6, 0x1f),
REGMAP_IRQ_REG(BXTWC_GPIO0_IRQ, 7, 0xff),
@@ -143,6 +145,10 @@ static struct resource adc_resources[] = {
DEFINE_RES_IRQ_NAMED(BXTWC_ADC_IRQ, "ADC"),
 };
 
+static struct resource usbc_resources[] = {
+   DEFINE_RES_IRQ(BXTWC_USBC_IRQ),
+};
+
 static struct resource charger_resources[] = {
DEFINE_RES_IRQ_NAMED(BXTWC_CHGR0_IRQ, "CHARGER"),
DEFINE_RES_IRQ_NAMED(BXTWC_CHGR1_IRQ, "CHARGER1"),
@@ -170,6 +176,11 @@ static struct mfd_cell bxt_wc_dev[] = {
.resources = thermal_resources,
},
{
+   .name = "bxt_wcove_usbc",
+   .num_resources = ARRAY_SIZE(usbc_resources),
+   .resources = usbc_resources,
+   },
+   {
.name = "bxt_wcove_ext_charger",
.num_resources = ARRAY_SIZE(charger_resources),
.resources = charger_resources,
-- 
2.8.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

Queries regrading USB-driver software-architecture

[Ajay Garg]

Hi All.

We have a PC-in-a-box unit, with 2 COM-ports, 2 USB 2.0 ports and 1
USB 3.0 port.
We are testing the COM-ports (COM1 and COM2) and the USB-ports.

We proceeded as follows ::

a)
In the setup

User-App <=> COM1 <=> RS232-data <=> RS232-to-RS485 converter <=>
RS485-data <=> Modbus-Device

when we send a modbus-command from user-app ==> modbus-device, we
receive the modbus-response fine. (Of course, RS232 is enabled for
COM1 in BIOS).


b)
If we modify the setup just a bit as

User-App <=> USB-Port <=> USB-Serial-to-RS232 converter <=> Rs232-data
<=> RS232-RS485 converter <=> RS485-data <=> Modbus-Device

and then send a modbus-command from user-app ==> modbus-device, we DO
NOT receive even a single byte as response.

Very surprisingly, if we use the above setup in a USB-port of my
personal laptop, we get the response fine (thereby signifying that
that all elements from USB-Serial-to-RS232 converter <=> Rs232-data
<=> RS232-RS485 converter <=> RS485-data <=> Modbus-Device are fine).


Some more facts ::

1)
uname -a gives identical output for my-laptop and the pc-in-a-box unit ::

uname -a
Linux blah-blah-login 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan
15 17:45:15 UTC 2015 i686 i686 i686 GNU/Linux

2)
On the pc-in-a-box-unit, following are some diagnostics that I could think of ::

lsmod | grep usb
usbnet 37829  1 qmi_wwan
mii13654  1 usbnet
usb_wwan   19306  1 qcserial
usbhid 47035  0
hid95946  3 i2c_hid,hid_generic,usbhid
usbserial  38972  8 qcserial,pl2303,usb_wwan

lsmod | grep pl2303
pl2303 18516  0
usbserial  38972  8 qcserial,pl2303,usb_wwan

3)
The USB-Serial-to-RS232 converter information ::

lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 007: ID 1199:68a2 Sierra Wireless, Inc.
Bus 001 Device 005: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 001 Device 004: ID 413c:2107 Dell Computer Corp.
Bus 001 Device 003: ID 046d:c05a Logitech, Inc. M90/M100 Optical Mouse
*Bus 001 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port*
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


4)
The checksums of the following drivers are identical on the
pc-in-a-box unit and my-laptop ::

cksum /lib/modules/3.16.0-30-generic/kernel/drivers/usb/serial/usbserial.ko
425603799 59904
/lib/modules/3.16.0-30-generic/kernel/drivers/usb/serial/usbserial.ko

cksum /lib/modules/3.16.0-30-generic/kernel/drivers/usb/serial/pl2303.ko
1987618250 25036
/lib/modules/3.16.0-30-generic/kernel/drivers/usb/serial/pl2303.ko


Behaviour remains same if I disable all USB 3.0 support in pc-in-a-box
unit via ::

USB3.0 Support  [Disable]
XHCI Hand-Off[Disable]
EHCI Hand-Off[Enabled]

XHCI Mode [Disable]
USB 2.0(EHCI) Support  [Enabled]


*So, now my question is that given the OS is identical and all
"OS-drivers" same, what could be the difference in behaviour on
pc-in-a-box and my-laptop?
Are some usb-drivers present at hardware/motherboard level too, thus
making the "difference in hardware" the root-cause (rather than
"difference in software")?*

I have witheld pc-in-a-box unit details, kindly ask me if specifying
the brand would make any difference.

Will be thankful for any architectural pointers.


Thanks and Regards,
Ajay
--
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: [PATCHv7 1/3] usb: USB Type-C connector class

[Heikki Krogerus]

> > +   Valid values:
> > +   - source
> > +   - sink
> > +
> > +What:  /sys/class/typec//current_vconn_role
> 
> Isn't the cover letter saying you have changed this ?

I have accidentally send the patches I prepared originally that did
not include this change (only you other suggestions). I'm sorry about
that. I'll resend.


Thanks,

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

Re: [PATCHv7 1/3] usb: USB Type-C connector class

[Vincent Palatin]

On Mon, Aug 29, 2016 at 12:23 PM, Heikki Krogerus
 wrote:
>
> The purpose of USB Type-C connector class is to provide
> unified interface for the user space to get the status and
> basic information about USB Type-C connectors on a system,
> control over data role swapping, and when the port supports
> USB Power Delivery, also control over power role swapping
> and Alternate Modes.
>
> Signed-off-by: Heikki Krogerus 
> ---
>  Documentation/ABI/testing/sysfs-class-typec |  202 +
>  Documentation/usb/typec.txt |  103 +++
>  MAINTAINERS |9 +
>  drivers/usb/Kconfig |2 +
>  drivers/usb/Makefile|2 +
>  drivers/usb/typec/Kconfig   |7 +
>  drivers/usb/typec/Makefile  |1 +
>  drivers/usb/typec/typec.c   | 1090 
> +++
>  include/linux/usb/typec.h   |  260 +++
>  9 files changed, 1676 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-class-typec
>  create mode 100644 Documentation/usb/typec.txt
>  create mode 100644 drivers/usb/typec/Kconfig
>  create mode 100644 drivers/usb/typec/Makefile
>  create mode 100644 drivers/usb/typec/typec.c
>  create mode 100644 include/linux/usb/typec.h
>
> diff --git a/Documentation/ABI/testing/sysfs-class-typec 
> b/Documentation/ABI/testing/sysfs-class-typec
> new file mode 100644
> index 000..c09a559
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-class-typec
> @@ -0,0 +1,202 @@
> +USB Type-C port devices (eg. /sys/class/typec/usbc0/)
> +
> +What:  /sys/class/typec//current_data_role
> +Date:  June 2016
> +Contact:   Heikki Krogerus 
> +Description:
> +   The current USB data role the port is operating in. This
> +   attribute can be used for requesting data role swapping on the
> +   port. Swapping is only supported as an asynchronous operation
> +   and requires polling of the attribute in order to know the
> +   result, so successful write operation does not mean successful
> +   swap.
> +
> +   Valid values:
> +   - host
> +   - device
> +
> +What:  /sys/class/typec//current_power_role
> +Date:  June 2016
> +Contact:   Heikki Krogerus 
> +Description:
> +   The current power role of the port. This attribute can be used
> +   to request power role swap on the port when the port supports
> +   USB Power Delivery.



I would put the same wording about asynchronous swapping as the data role.


>
> +
> +   Valid values:
> +   - source
> +   - sink
> +
> +What:  /sys/class/typec//current_vconn_role



Isn't the cover letter saying you have changed this ?



>
> +Date:  June 2016
> +Contact:   Heikki Krogerus 
> +Description:
> +   Shows the current VCONN role of the port. This attribute can 
> be
> +   used to request VCONN role swap on the port when the port
> +   supports USB Power Delivery.
> +
> +   Valid values are:
> +   - source
> +   - sink
> +
> +What:  /sys/class/typec//power_operation_mode
> +Date:  June 2016
> +Contact:   Heikki Krogerus 
> +Description:
> +   Shows the current power operational mode the port is in.
> +
> +   Valid values:
> +   - USB - Normal power levels defined in USB specifications
> +   - BC1.2 - Power levels defined in Battery Charging 
> Specification
> + v1.2
> +   - USB Type-C 1.5A - Higher 1.5A current defined in USB Type-C
> +   specification.
> +   - USB Type-C 3.0A - Higher 3A current defined in USB Type-C
> +   specification.
> +- USB Power Delivery - The voltages and currents defined in 
> USB
> +  Power Delivery specification
> +
> +What:  /sys/class/typec//preferred_role
> +Date:  June 2016
> +Contact:   Heikki Krogerus 
> +Description:
> +   The user space can notify the driver about the preferred role.
> +   It should be handled as enabling of Try.SRC or Try.SNK, as
> +   defined in USB Type-C specification, in the port drivers. By
> +   default there is no preferred role.
> +
> +   Valid values:
> +   - host
> +   - device
> +   - For example "none" to remove preference (anything else 
> except
> + "host" or 

Re: pl2303_read_int_callback - usb_submit_urb failed with result -19

[Greg KH]

On Mon, Aug 29, 2016 at 02:49:23PM +0530, Malith Yapa wrote:
> On Thu, Jul 14, 2016 at 9:14 AM, Malith Yapa  wrote:
> > On Thu, Jul 14, 2016 at 2:14 AM, Greg KH  wrote:
> >> On Wed, Jul 13, 2016 at 10:59:10AM +0530, Malith Yapa wrote:
> >>> I think i am.
> >>>
> >>> int readDword(int addr) {
> >>>
> >>> uint16_t reg[1];// will store read registers values
> >>>
> >>> int num = modbus_read_registers(ctx, addr, 1, reg); //16386 = X2
> >>>
> >>> usleep(5);
> >>>
> >>> if (num != 1) {
> >>> fprintf(stderr, "Failed(%i) to read: %s\n", num,
> >>> modbus_strerror(errno));
> >>> modbus_close(ctx);
> >>> modbus_free(ctx);
> >>> sleep(5);
> >>> int wait = 1;
> >>> while(initModbus()) {
> >>> cerr << "Waiting for PLC.. SLEEP[" << wait*20 << "]" << endl;
> >>> sleep(wait*20);
> >>> wait++;
> >>> }
> >>> }
> >>>
> >>> return reg[0];
> >>> }
> >>>
> >>> according to modbus documentation, "The modbus_close() function shall
> >>> close the connection established with the backend set in the context."
> >>>
> >>> Even if not. Shouldn't the minor number's go upto 512 (as Johan
> >>> pointed out) before giving up?
> >>
> >> Yes it should.
> >>
> >>> The system is an Olimex A20-micro,
> >>> Linux version 3.4.90+ (gcc version 4.7.1 (Debian 4.7.1-7) )
> >>
> >> Ugh, 3.4 is a very old, and obsolete kernel version.  Please get support
> >> for it from the vendor that is forcing you to use such a thing, as you
> >> are already paying for it from them.
> >>
> >> We can help you out if you can reproduce this on 4.6, have you tried
> >> that?
> >>
> >> thanks,
> >>
> >> greg k-h
> >
> > Looks like sunxi only provides a 3.4 kernel. I lack the expertise to
> > try to build 4.6 for this board so I'll try reporting it to them.
> >
> > Thanks,
> > Malith
> 
> Hope it's ok to reply on the old thread.
> 
> I have since compiled 4.8.0_rc1. And just as you guys suggested a part
> of problem is solved. The minor number now definitely goes up to 512
> before giving no more free serial devices. But it still doesn't reuse
> the minors after disconnecting.
> 
> In my code I'm calling modbus_close and modbus_free which in turn call
> close() and free() on the file descriptor. Shouldn't this make the
> minor reusable?
> 
> >From what i understand minor numbers are allocated and freed by the
> driver. So how does the driver know to release the minor number after
> the file descriptor is closed?

The USB serial driver core code handles this for you automatically after
the last reference goes away.  Are you sure that userspace is properly
releasing the device properly?

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 v3 0/8] usb: ulpi: remove "dev" field from struct ulpi_ops

[Greg KH]

On Mon, Aug 29, 2016 at 10:58:25AM +0300, Felipe Balbi wrote:
> 
> Hi folks,
> 
> Tal Shorer  writes:
> > struct ulpi_ops is defined as follows:
> >
> > struct ulpi_ops {
> > struct device *dev;
> > int (*read)(struct ulpi_ops *ops, u8 addr);
> > int (*write)(struct ulpi_ops *ops, u8 addr, u8 val);
> > };
> >
> > Upon calling ulpi_register_interface(), the struct device argument is
> > put inside the struct ulpi_ops argument's dev field. Later, when
> > calling the actual read()/write() operations, the struct ulpi_ops is
> > passed to them and they use the stored device to access whatever
> > private data they need.
> >
> > This means that if one wishes to reuse the same oprations for multiple
> > interfaces (e.g if we have multiple instances of the same controller),
> > any but the last interface registered will not operate properly (and
> > the one that does work will be at the mercy of the others to not mess
> > it up).
> >
> > I understand that barely any driver uses this bus right now, but I
> > suppose it's there to be used at some point. We might as well fix the
> > design here before we hit this bug.
> >
> > This series fixes this by passing the given struct device directly to
> > the operation functions via ulpi->dev.parent in ulpi_read() and
> > ulpi_write(). It also changes the operations struct to be constant
> > since now nobody has a reason to modify it.
> >
> > Changes from v1:
> >  * Split the actual api change into multiple patch as per Felipe Balbi's
> >suggestion. The series now first adds the new api, then migrates
> >everything to use and only then removes the old api.
> >
> > Changes from v2:
> >  * Merge patches 2 and 3 (now patch 2)
> >  * Merge patches 5 and 6 (now patch 4)
> >  * Remove comment documenting the removed dev field in struct ulpi_ops
> >
> > Tal Shorer (8):
> >   usb: ulpi: move setting of ulpi->dev parent up in ulpi_register()
> >   usb: ulpi: add new api functions, {read|write}_dev()
> >   usb: dwc3: ulpi: use new api
> >   usb: ulpi: remove calls to old api callbacks
> >   usb: ulpi: rename operations {read|write}_dev to simply {read|write}
> >   usb: ulpi: remove "dev" field from struct ulpi_ops
> >   usb: ulpi: make ops struct constant
> >   usb: dwc3: ulpi: make dwc3_ulpi_ops constant
> 
> I have no idea how to apply these :-) Many of the patches touch dwc3,
> but some touch common ulpi. Greg, is it okay if I take the entire series
> and send it to you during my for-next pull request?

Sure, that works for me.

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: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422

[Michael Niewöhner]

Hi Mathias,
On Mo, 2016-08-29 at 13:59 +0300, Mathias Nyman wrote:
> On 29.08.2016 10:28, Felipe Balbi wrote:
> > 
> > 
> > Hi,
> > 
> > Michael Niewöhner  writes:
> > > 
> > > [1.] One line summary of the problem:
> > > DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
> > > 
> > > [2.] Full description of the problem/report:
> > > No usb 3.0 devices are being detected when attached while USB 2.0
> > > devices work on the same port.
> > > USB 3.0 works after applying patches [9.1] and [9.2], but seems
> > > to be
> > > buggy. The usb hub is redetected every time an usb device is
> > > attached.
> > 
> > dwc3 is host, which means it's actually XHCI :-)
> > 
> > Adding Mathias
> > 
> > > 
> > > dmesg:
> > > [  192.287080] usb 3-1.2: USB disconnect, device number 7
> > > [  210.370699] hub 3-1:1.0: hub_ext_port_status failed (err =
> > > -71)
> 
> Looks like the hub GetPortStatus request fails with protocol error.
> 
> Reading xhci root hub port status is mostly just register reads and
> writes. It
> shouldn't include any actual transfers that could return -EPROTO
> 
> So this is not the root hub? but a external or integrated on your
> board, right?
> 
> The protocol error -71 is returned at transfer errors or if device
> stalled.
> 
> Adding more xhci debugging options could show something:
> echo -n 'module xhci_hcd =p' >
> /sys/kernel/debug/dynamic_debug/control
> 
> > 
> > > 
> > > [9.] Other notes, patches, fixes, workarounds:
> > > [9.1] https://lkml.org/lkml/2014/4/28/234
> > > [9.2] https://lkml.org/lkml/2015/2/2/259
> 
> The additional patches that makes things somehow work involve tuning
> the PHY,
> this is an area I'm not familiar with
> 
> -Mathias
> 


I'm sorry, I should have said that this is the dmesg output with the
patches applied. Without them there is no output at all when I attach
an usb 3.0 device.

Michael

signature.asc
Description: This is a digitally signed message part

Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422

[Mathias Nyman]

On 29.08.2016 10:28, Felipe Balbi wrote:


Hi,

Michael Niewöhner  writes:

[1.] One line summary of the problem:
DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422

[2.] Full description of the problem/report:
No usb 3.0 devices are being detected when attached while USB 2.0
devices work on the same port.
USB 3.0 works after applying patches [9.1] and [9.2], but seems to be
buggy. The usb hub is redetected every time an usb device is attached.


dwc3 is host, which means it's actually XHCI :-)

Adding Mathias


dmesg:
[  192.287080] usb 3-1.2: USB disconnect, device number 7
[  210.370699] hub 3-1:1.0: hub_ext_port_status failed (err = -71)


Looks like the hub GetPortStatus request fails with protocol error.

Reading xhci root hub port status is mostly just register reads and writes. It
shouldn't include any actual transfers that could return -EPROTO

So this is not the root hub? but a external or integrated on your board, right?

The protocol error -71 is returned at transfer errors or if device stalled.

Adding more xhci debugging options could show something:
echo -n 'module xhci_hcd =p' > /sys/kernel/debug/dynamic_debug/control


[9.] Other notes, patches, fixes, workarounds:
[9.1] https://lkml.org/lkml/2014/4/28/234
[9.2] https://lkml.org/lkml/2015/2/2/259


The additional patches that makes things somehow work involve tuning the PHY,
this is an area I'm not familiar with

-Mathias

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

[PATCHv7 1/3] usb: USB Type-C connector class

[Heikki Krogerus]

The purpose of USB Type-C connector class is to provide
unified interface for the user space to get the status and
basic information about USB Type-C connectors on a system,
control over data role swapping, and when the port supports
USB Power Delivery, also control over power role swapping
and Alternate Modes.

Signed-off-by: Heikki Krogerus 
---
 Documentation/ABI/testing/sysfs-class-typec |  202 +
 Documentation/usb/typec.txt |  103 +++
 MAINTAINERS |9 +
 drivers/usb/Kconfig |2 +
 drivers/usb/Makefile|2 +
 drivers/usb/typec/Kconfig   |7 +
 drivers/usb/typec/Makefile  |1 +
 drivers/usb/typec/typec.c   | 1090 +++
 include/linux/usb/typec.h   |  260 +++
 9 files changed, 1676 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-typec
 create mode 100644 Documentation/usb/typec.txt
 create mode 100644 drivers/usb/typec/Kconfig
 create mode 100644 drivers/usb/typec/Makefile
 create mode 100644 drivers/usb/typec/typec.c
 create mode 100644 include/linux/usb/typec.h

diff --git a/Documentation/ABI/testing/sysfs-class-typec 
b/Documentation/ABI/testing/sysfs-class-typec
new file mode 100644
index 000..c09a559
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-typec
@@ -0,0 +1,202 @@
+USB Type-C port devices (eg. /sys/class/typec/usbc0/)
+
+What:  /sys/class/typec//current_data_role
+Date:  June 2016
+Contact:   Heikki Krogerus 
+Description:
+   The current USB data role the port is operating in. This
+   attribute can be used for requesting data role swapping on the
+   port. Swapping is only supported as an asynchronous operation
+   and requires polling of the attribute in order to know the
+   result, so successful write operation does not mean successful
+   swap.
+
+   Valid values:
+   - host
+   - device
+
+What:  /sys/class/typec//current_power_role
+Date:  June 2016
+Contact:   Heikki Krogerus 
+Description:
+   The current power role of the port. This attribute can be used
+   to request power role swap on the port when the port supports
+   USB Power Delivery.
+
+   Valid values:
+   - source
+   - sink
+
+What:  /sys/class/typec//current_vconn_role
+Date:  June 2016
+Contact:   Heikki Krogerus 
+Description:
+   Shows the current VCONN role of the port. This attribute can be
+   used to request VCONN role swap on the port when the port
+   supports USB Power Delivery.
+
+   Valid values are:
+   - source
+   - sink
+
+What:  /sys/class/typec//power_operation_mode
+Date:  June 2016
+Contact:   Heikki Krogerus 
+Description:
+   Shows the current power operational mode the port is in.
+
+   Valid values:
+   - USB - Normal power levels defined in USB specifications
+   - BC1.2 - Power levels defined in Battery Charging Specification
+ v1.2
+   - USB Type-C 1.5A - Higher 1.5A current defined in USB Type-C
+   specification.
+   - USB Type-C 3.0A - Higher 3A current defined in USB Type-C
+   specification.
+- USB Power Delivery - The voltages and currents defined in USB
+  Power Delivery specification
+
+What:  /sys/class/typec//preferred_role
+Date:  June 2016
+Contact:   Heikki Krogerus 
+Description:
+   The user space can notify the driver about the preferred role.
+   It should be handled as enabling of Try.SRC or Try.SNK, as
+   defined in USB Type-C specification, in the port drivers. By
+   default there is no preferred role.
+
+   Valid values:
+   - host
+   - device
+   - For example "none" to remove preference (anything else except
+ "host" or "device")
+
+What:  /sys/class/typec//supported_accessory_modes
+Date:  June 2016
+Contact:   Heikki Krogerus 
+Description:
+   Lists the Accessory Modes, defined in the USB Type-C
+   specification, the port supports.
+
+What:  /sys/class/typec//supported_data_roles
+Date:  June 2016
+Contact:   Heikki Krogerus 
+Description:

[PATCHv7 3/3] mfd: intel_soc_pmic_bxtwc: add support for USB Type-C PHY on WhiskeyCove

[Heikki Krogerus]

Intel WhiskeyCove PMIC has also a USB Type-C PHY, so let's
create a device for it.

Signed-off-by: Heikki Krogerus 
Cc: Lee Jones 
---
 drivers/mfd/intel_soc_pmic_bxtwc.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/mfd/intel_soc_pmic_bxtwc.c 
b/drivers/mfd/intel_soc_pmic_bxtwc.c
index b942876..0e61dde 100644
--- a/drivers/mfd/intel_soc_pmic_bxtwc.c
+++ b/drivers/mfd/intel_soc_pmic_bxtwc.c
@@ -84,6 +84,7 @@ enum bxtwc_irqs_level2 {
BXTWC_THRM2_IRQ,
BXTWC_BCU_IRQ,
BXTWC_ADC_IRQ,
+   BXTWC_USBC_IRQ,
BXTWC_CHGR0_IRQ,
BXTWC_CHGR1_IRQ,
BXTWC_GPIO0_IRQ,
@@ -109,6 +110,7 @@ static const struct regmap_irq bxtwc_regmap_irqs_level2[] = 
{
REGMAP_IRQ_REG(BXTWC_THRM2_IRQ, 2, 0xff),
REGMAP_IRQ_REG(BXTWC_BCU_IRQ, 3, 0x1f),
REGMAP_IRQ_REG(BXTWC_ADC_IRQ, 4, 0xff),
+   REGMAP_IRQ_REG(BXTWC_USBC_IRQ, 5, BIT(5)),
REGMAP_IRQ_REG(BXTWC_CHGR0_IRQ, 5, 0x1f),
REGMAP_IRQ_REG(BXTWC_CHGR1_IRQ, 6, 0x1f),
REGMAP_IRQ_REG(BXTWC_GPIO0_IRQ, 7, 0xff),
@@ -143,6 +145,10 @@ static struct resource adc_resources[] = {
DEFINE_RES_IRQ_NAMED(BXTWC_ADC_IRQ, "ADC"),
 };
 
+static struct resource usbc_resources[] = {
+   DEFINE_RES_IRQ(BXTWC_USBC_IRQ),
+};
+
 static struct resource charger_resources[] = {
DEFINE_RES_IRQ_NAMED(BXTWC_CHGR0_IRQ, "CHARGER"),
DEFINE_RES_IRQ_NAMED(BXTWC_CHGR1_IRQ, "CHARGER1"),
@@ -170,6 +176,11 @@ static struct mfd_cell bxt_wc_dev[] = {
.resources = thermal_resources,
},
{
+   .name = "bxt_wcove_usbc",
+   .num_resources = ARRAY_SIZE(usbc_resources),
+   .resources = usbc_resources,
+   },
+   {
.name = "bxt_wcove_ext_charger",
.num_resources = ARRAY_SIZE(charger_resources),
.resources = charger_resources,
-- 
2.8.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

[PATCHv7 0/3] USB Type-C Connector class

[Heikki Krogerus]

The USB Type-C class is meant to provide unified interface to the
userspace to present the USB Type-C ports in a system.


Changes since v6:
- current_vconn_role attr renamed to vconn_source (no API changes)
- Small documentation improvements proposed by Vincent Palatin

Changes since v5:
- Only updating the roles based on driver notifications
- Added MODULE_ALIAS for the WhiskeyCove module
- Including the patch that creates the actual platform device for the
  WhiskeyCove Type-C PHY in this series.

Changes since v4:
- Remove the port lock completely

Changes since v3:
- Documentation cleanup as proposed by Roger Quadros
- Setting partner altmodes member to NULL on removal and fixing a
  warning, as proposed by Guenter Roeck
- Added the following attributes for partners and cables:
  * supports_usb_power_delivery
  * id_header_vdo
- "id_header_vdo" is visible only when the partner or cable supports
  USB Power Delivery communication.
- Partner attribute "accessory" is hidden when the partner type is not
  "Accessory".

Changes since v2:
- Notification on role and alternate mode changes
- cleanups

Changes since v1:
- Completely rewrote alternate mode support
- Patners, cables and cable plugs presented as devices.


Heikki Krogerus (3):
  usb: USB Type-C connector class
  usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY
  mfd: intel_soc_pmic_bxtwc: add support for USB Type-C PHY on
WhiskeyCove

 Documentation/ABI/testing/sysfs-class-typec |  202 +
 Documentation/usb/typec.txt |  103 +++
 MAINTAINERS |9 +
 drivers/mfd/intel_soc_pmic_bxtwc.c  |   11 +
 drivers/usb/Kconfig |2 +
 drivers/usb/Makefile|2 +
 drivers/usb/typec/Kconfig   |   21 +
 drivers/usb/typec/Makefile  |2 +
 drivers/usb/typec/typec.c   | 1090 +++
 drivers/usb/typec/typec_wcove.c |  372 +
 include/linux/usb/typec.h   |  260 +++
 11 files changed, 2074 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-typec
 create mode 100644 Documentation/usb/typec.txt
 create mode 100644 drivers/usb/typec/Kconfig
 create mode 100644 drivers/usb/typec/Makefile
 create mode 100644 drivers/usb/typec/typec.c
 create mode 100644 drivers/usb/typec/typec_wcove.c
 create mode 100644 include/linux/usb/typec.h

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

[PATCHv7 2/3] usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY

[Heikki Krogerus]

This adds driver for the USB Type-C PHY on Intel WhiskeyCove
PMIC which is available on some of the Intel Broxton SoC
based platforms.

Signed-off-by: Heikki Krogerus 
---
 drivers/usb/typec/Kconfig   |  14 ++
 drivers/usb/typec/Makefile  |   1 +
 drivers/usb/typec/typec_wcove.c | 372 
 3 files changed, 387 insertions(+)
 create mode 100644 drivers/usb/typec/typec_wcove.c

diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index b229fb9..7a345a4 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -4,4 +4,18 @@ menu "USB PD and Type-C drivers"
 config TYPEC
tristate
 
+config TYPEC_WCOVE
+   tristate "Intel WhiskeyCove PMIC USB Type-C PHY driver"
+   depends on ACPI
+   depends on INTEL_SOC_PMIC
+   depends on INTEL_PMC_IPC
+   select TYPEC
+   help
+ This driver adds support for USB Type-C detection on Intel Broxton
+ platforms that have Intel Whiskey Cove PMIC. The driver can detect the
+ role and cable orientation.
+
+ To compile this driver as module, choose M here: the module will be
+ called typec_wcove
+
 endmenu
diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
index 1012a8b..b9cb862 100644
--- a/drivers/usb/typec/Makefile
+++ b/drivers/usb/typec/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_TYPEC)+= typec.o
+obj-$(CONFIG_TYPEC_WCOVE)  += typec_wcove.o
diff --git a/drivers/usb/typec/typec_wcove.c b/drivers/usb/typec/typec_wcove.c
new file mode 100644
index 000..7116491
--- /dev/null
+++ b/drivers/usb/typec/typec_wcove.c
@@ -0,0 +1,372 @@
+/**
+ * typec_wcove.c - WhiskeyCove PMIC USB Type-C PHY driver
+ *
+ * Copyright (C) 2016 Intel Corporation
+ * Author: Heikki Krogerus 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Register offsets */
+#define WCOVE_CHGRIRQ0 0x4e09
+#define WCOVE_PHYCTRL  0x5e07
+
+#define USBC_CONTROL1  0x7001
+#define USBC_CONTROL2  0x7002
+#define USBC_CONTROL3  0x7003
+#define USBC_CC1_CTRL  0x7004
+#define USBC_CC2_CTRL  0x7005
+#define USBC_STATUS1   0x7007
+#define USBC_STATUS2   0x7008
+#define USBC_STATUS3   0x7009
+#define USBC_IRQ1  0x7015
+#define USBC_IRQ2  0x7016
+#define USBC_IRQMASK1  0x7017
+#define USBC_IRQMASK2  0x7018
+
+/* Register bits */
+
+#define USBC_CONTROL1_MODE_DRP(r)  ((r & ~0x7) | 4)
+
+#define USBC_CONTROL2_UNATT_SNKBIT(0)
+#define USBC_CONTROL2_UNATT_SRCBIT(1)
+#define USBC_CONTROL2_DIS_ST   BIT(2)
+
+#define USBC_CONTROL3_PD_DIS   BIT(1)
+
+#define USBC_CC_CTRL_VCONN_EN  BIT(1)
+
+#define USBC_STATUS1_DET_ONGOING   BIT(6)
+#define USBC_STATUS1_RSLT(r)   (r & 0xf)
+#define USBC_RSLT_NOTHING  0
+#define USBC_RSLT_SRC_DEFAULT  1
+#define USBC_RSLT_SRC_1_5A 2
+#define USBC_RSLT_SRC_3_0A 3
+#define USBC_RSLT_SNK  4
+#define USBC_RSLT_DEBUG_ACC5
+#define USBC_RSLT_AUDIO_ACC6
+#define USBC_RSLT_UNDEF15
+#define USBC_STATUS1_ORIENT(r) ((r >> 4) & 0x3)
+#define USBC_ORIENT_NORMAL 1
+#define USBC_ORIENT_REVERSE2
+
+#define USBC_STATUS2_VBUS_REQ  BIT(5)
+
+#define USBC_IRQ1_ADCDONE1 BIT(2)
+#define USBC_IRQ1_OVERTEMP BIT(1)
+#define USBC_IRQ1_SHORTBIT(0)
+
+#define USBC_IRQ2_CC_CHANGEBIT(7)
+#define USBC_IRQ2_RX_PDBIT(6)
+#define USBC_IRQ2_RX_HRBIT(5)
+#define USBC_IRQ2_RX_CRBIT(4)
+#define USBC_IRQ2_TX_SUCCESS   BIT(3)
+#define USBC_IRQ2_TX_FAIL  BIT(2)
+
+#define USBC_IRQMASK1_ALL  (USBC_IRQ1_ADCDONE1 | USBC_IRQ1_OVERTEMP | \
+USBC_IRQ1_SHORT)
+
+#define USBC_IRQMASK2_ALL  (USBC_IRQ2_CC_CHANGE | USBC_IRQ2_RX_PD | \
+USBC_IRQ2_RX_HR | USBC_IRQ2_RX_CR | \
+USBC_IRQ2_TX_SUCCESS | USBC_IRQ2_TX_FAIL)
+
+struct wcove_typec {
+   struct mutex lock; /* device lock */
+   struct device *dev;
+   struct regmap *regmap;
+   struct typec_port *port;
+   struct typec_capability cap;
+   struct typec_connection con;
+   struct typec_partner partner;
+};
+
+enum wcove_typec_func {
+   WCOVE_FUNC_DRIVE_VBUS = 1,
+   WCOVE_FUNC_ORIENTATION,
+   WCOVE_FUNC_ROLE,
+   WCOVE_FUNC_DRIVE_VCONN,
+};
+
+enum wcove_typec_orientation {
+   WCOVE_ORIENTATION_NORMAL,
+   

Re: [PATCH 2/4] phy: rockchip-usb: use rockchip_usb_phy_reset to reset phy during wakeup

[Kishon Vijay Abraham I]

Hi,

On Monday 22 August 2016 06:30 PM, Heiko Stübner wrote:
> Am Montag, 22. August 2016, 17:17:41 schrieb Kishon Vijay Abraham I:
>> Hi,
>>
>> On Sunday 21 August 2016 02:02 AM, Randy Li wrote:
>>> It is a hardware bug in RK3288, the only way to solve it is to
>>> reset the phy.
>>>
>>> Signed-off-by: Randy Li 
>>> ---
>>>
>>>  drivers/phy/phy-rockchip-usb.c | 20 
>>>  1 file changed, 20 insertions(+)
>>>
>>> diff --git a/drivers/phy/phy-rockchip-usb.c
>>> b/drivers/phy/phy-rockchip-usb.c index 2a7381f..734987f 100644
>>> --- a/drivers/phy/phy-rockchip-usb.c
>>> +++ b/drivers/phy/phy-rockchip-usb.c
>>> @@ -29,6 +29,7 @@
>>>
>>>  #include 
>>>  #include 
>>>  #include 
>>>
>>> +#include 
>>>
>>>  static int enable_usb_uart;
>>>
>>> @@ -64,6 +65,7 @@ struct rockchip_usb_phy {
>>>
>>> struct clk_hw   clk480m_hw;
>>> struct phy  *phy;
>>> booluart_enabled;
>>>
>>> +   struct reset_control *reset;
>>>
>>>  };
>>>  
>>>  static int rockchip_usb_phy_power(struct rockchip_usb_phy *phy,
>>>
>>> @@ -144,9 +146,23 @@ static int rockchip_usb_phy_power_on(struct phy
>>> *_phy)
>>>
>>> return clk_prepare_enable(phy->clk480m);
>>>  
>>>  }
>>>
>>> +static int rockchip_usb_phy_reset(struct phy *_phy)
>>> +{
>>> +   struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
>>> +
>>> +   if (phy->reset) {
>>> +   reset_control_assert(phy->reset);
>>> +   udelay(10);
>>> +   reset_control_deassert(phy->reset);
>>> +   }
>>> +
>>> +   return 0;
>>> +}
>>> +
>>>
>>>  static const struct phy_ops ops = {
>>>  
>>> .power_on   = rockchip_usb_phy_power_on,
>>> .power_off  = rockchip_usb_phy_power_off,
>>>
>>> +   .reset  = rockchip_usb_phy_reset,
>>
>> why not just reuse the .init ops? reset can be done during initialization
>> right?
> 
> The naming of power_on + power_off and init + exit probably suggests that 
> they 
> are supposed to be used in pairs. (aka module_init + module_exit and probably 
> more)
> 
> But in fact I've seen different combinations so far (phy_init + phy_power_on 
> ... phy_power_off + phy_exit but also phy_power_on + phy_init ... phy_exit + 
> phy_power_off), so I guess the semantics are not that strictly defined.

yeah, it got difficult to maintain the semantics once the number of phy users
increased. Thought it was better than bloating the framework with platform
specific callbacks.

Thanks
Kishon
--
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: pl2303_read_int_callback - usb_submit_urb failed with result -19

[Malith Yapa]

On Thu, Jul 14, 2016 at 9:14 AM, Malith Yapa  wrote:
> On Thu, Jul 14, 2016 at 2:14 AM, Greg KH  wrote:
>> On Wed, Jul 13, 2016 at 10:59:10AM +0530, Malith Yapa wrote:
>>> I think i am.
>>>
>>> int readDword(int addr) {
>>>
>>> uint16_t reg[1];// will store read registers values
>>>
>>> int num = modbus_read_registers(ctx, addr, 1, reg); //16386 = X2
>>>
>>> usleep(5);
>>>
>>> if (num != 1) {
>>> fprintf(stderr, "Failed(%i) to read: %s\n", num,
>>> modbus_strerror(errno));
>>> modbus_close(ctx);
>>> modbus_free(ctx);
>>> sleep(5);
>>> int wait = 1;
>>> while(initModbus()) {
>>> cerr << "Waiting for PLC.. SLEEP[" << wait*20 << "]" << endl;
>>> sleep(wait*20);
>>> wait++;
>>> }
>>> }
>>>
>>> return reg[0];
>>> }
>>>
>>> according to modbus documentation, "The modbus_close() function shall
>>> close the connection established with the backend set in the context."
>>>
>>> Even if not. Shouldn't the minor number's go upto 512 (as Johan
>>> pointed out) before giving up?
>>
>> Yes it should.
>>
>>> The system is an Olimex A20-micro,
>>> Linux version 3.4.90+ (gcc version 4.7.1 (Debian 4.7.1-7) )
>>
>> Ugh, 3.4 is a very old, and obsolete kernel version.  Please get support
>> for it from the vendor that is forcing you to use such a thing, as you
>> are already paying for it from them.
>>
>> We can help you out if you can reproduce this on 4.6, have you tried
>> that?
>>
>> thanks,
>>
>> greg k-h
>
> Looks like sunxi only provides a 3.4 kernel. I lack the expertise to
> try to build 4.6 for this board so I'll try reporting it to them.
>
> Thanks,
> Malith

Hope it's ok to reply on the old thread.

I have since compiled 4.8.0_rc1. And just as you guys suggested a part
of problem is solved. The minor number now definitely goes up to 512
before giving no more free serial devices. But it still doesn't reuse
the minors after disconnecting.

In my code I'm calling modbus_close and modbus_free which in turn call
close() and free() on the file descriptor. Shouldn't this make the
minor reusable?

>From what i understand minor numbers are allocated and freed by the
driver. So how does the driver know to release the minor number after
the file descriptor is closed?

Thanks,
Malith
--
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: gadget: configfs: log function unbinding as debug

[Romain Izard]

Disabling USB gadget functions configured through configfs is something
that can happen in normal use cases. Keep the existing log for this type
of event, but only as debug, not as an error.

Signed-off-by: Romain Izard 
---
v1 -> v2:
- use dev_dbg instead of dev_info

 drivers/usb/gadget/configfs.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index f9237fe2be05..3984787f8e97 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -1211,8 +1211,9 @@ static void purge_configs_funcs(struct gadget_info *gi)
 
list_move_tail(>list, >func_list);
if (f->unbind) {
-   dev_err(>cdev.gadget->dev, "unbind function"
-   " '%s'/%p\n", f->name, f);
+   dev_dbg(>cdev.gadget->dev,
+"unbind function '%s'/%p\n",
+f->name, f);
f->unbind(c, f);
}
}
-- 
2.7.4

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

Re: [PATCH v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Baolin Wang]

Hi Felipe,

On 11 August 2016 at 11:14, Baolin Wang  wrote:
> Hi Felipe,
>
> On 1 August 2016 at 15:09, Baolin Wang  wrote:
>> Currently the Linux kernel does not provide any standard integration of this
>> feature that integrates the USB subsystem with the system power regulation
>> provided by PMICs meaning that either vendors must add this in their kernels
>> or USB gadget devices based on Linux (such as mobile phones) may not behave
>> as they should. Thus provide a standard framework for doing this in kernel.
>>
>> Now introduce one user with wm831x_power to support and test the usb charger,
>> which is pending testing. Moreover there may be other potential users will 
>> use
>> it in future.
>
> Could you please apply this patchset into your 'next' branch if you
> have no comments about it? Thank you.

Since there are no other comments about this patchset for a long time,
could you please apply this patchset? Thanks.

>
>>
>> CHanges since v15:
>>  - Add charger state checking to avoid sending out duplicate notifies to 
>> users.
>>  - Add one work to notify power users the current has been changed.
>>
>> Changes since v14:
>>  - Add kernel documentation for struct usb_cahrger.
>>  - Remove some redundant WARN() functions.
>>
>> Changes since v13:
>>  - Remove the charger checking in usb_gadget_vbus_draw() function.
>>  - Rename some functions in charger.c file.
>>  - Rebase on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
>> tags/usb-for-v4.8
>>
>> Changes since v12:
>>  - Remove the class and device things.
>>  - Link usb charger to udc-core.ko.
>>  - Create one "charger" subdirectory which holds all charger-related 
>> attributes.
>>
>> Changes since v11:
>>  - Reviewed and tested by Li Jun.
>>
>> Changes since v10:
>>  - Introduce usb_charger_get_state() function to check charger state.
>>  - Remove the mutex lock in usb_charger_set_cur_limit_by_type() function
>>  in case will be issued in atomic context.
>>
>> Baolin Wang (4):
>>   usb: gadget: Introduce the usb charger framework
>>   usb: gadget: Support for the usb charger framework
>>   usb: gadget: Integrate with the usb gadget supporting for usb charger
>>   power: wm831x_power: Support USB charger current limit management
>>
>>  drivers/power/wm831x_power.c |   69 
>>  drivers/usb/gadget/Kconfig   |8 +
>>  drivers/usb/gadget/udc/Makefile  |1 +
>>  drivers/usb/gadget/udc/charger.c |  780 
>> ++
>>  drivers/usb/gadget/udc/core.c|   17 +
>>  include/linux/mfd/wm831x/pdata.h |3 +
>>  include/linux/usb/charger.h  |  186 +
>>  include/linux/usb/gadget.h   |3 +
>>  include/uapi/linux/usb/charger.h |   31 ++
>>  9 files changed, 1098 insertions(+)
>>  create mode 100644 drivers/usb/gadget/udc/charger.c
>>  create mode 100644 include/linux/usb/charger.h
>>  create mode 100644 include/uapi/linux/usb/charger.h
>>
>> --
>> 1.7.9.5
>>
>
>
>
> --
> Baolin.wang
> Best Regards



-- 
Baolin.wang
Best 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

[PATCH] usb: renesas_usbhs: fix clearing the {BRDY,BEMP}STS condition

[Yoshihiro Shimoda]

The previous driver is possible to stop the transfer wrongly.
For example:
 1) An interrupt happens, but not BRDY interruption.
 2) Read INTSTS0. And than state->intsts0 is not set to BRDY.
 3) BRDY is set to 1 here.
 4) Read BRDYSTS.
 5) Clear the BRDYSTS. And then. the BRDY is cleared wrongly.

Remarks:
 - The INTSTS0.BRDY is read only.
  - If any bits of BRDYSTS are set to 1, the BRDY is set to 1.
  - If BRDYSTS is 0, the BRDY is set to 0.

So, this patch adds condition to avoid such situation. (And about
NRDYSTS, this is not used for now. But, avoiding any side effects,
this patch doesn't touch it.)

Fixes: d5c6a1e024dd ("usb: renesas_usbhs: fixup interrupt status clear method")
Cc:  # v3.8+
Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/renesas_usbhs/mod.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/renesas_usbhs/mod.c b/drivers/usb/renesas_usbhs/mod.c
index d4be5d5..28965ef 100644
--- a/drivers/usb/renesas_usbhs/mod.c
+++ b/drivers/usb/renesas_usbhs/mod.c
@@ -282,9 +282,16 @@ static irqreturn_t usbhs_interrupt(int irq, void *data)
if (usbhs_mod_is_host(priv))
usbhs_write(priv, INTSTS1, ~irq_state.intsts1 & INTSTS1_MAGIC);
 
-   usbhs_write(priv, BRDYSTS, ~irq_state.brdysts);
+   /*
+* The driver should not clear the xxxSTS after the line of
+* "call irq callback functions" because each "if" statement is
+* possible to call the callback function for avoiding any side effects.
+*/
+   if (irq_state.intsts0 & BRDY)
+   usbhs_write(priv, BRDYSTS, ~irq_state.brdysts);
usbhs_write(priv, NRDYSTS, ~irq_state.nrdysts);
-   usbhs_write(priv, BEMPSTS, ~irq_state.bempsts);
+   if (irq_state.intsts0 & BEMP)
+   usbhs_write(priv, BEMPSTS, ~irq_state.bempsts);
 
/*
 * call irq callback functions
-- 
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 RFC V3.5] leds: trigger: Introduce an USB port trigger

[Rafał Miłecki]

On 29 August 2016 at 10:41, Pavel Machek  wrote:
> On Mon 2016-08-29 10:21:48, Rafał Miłecki wrote:
>> On 29 August 2016 at 10:05, Pavel Machek  wrote:
>> >> >2) Having "ports" subdir with RW files, one per each existing physical 
>> >> >port
>> >> >In this situation we don't need "new_port" or "remove_port". If we
>> >> >want port to be observable we just do:
>> >> >echo 1 > 1-1
>> >> >Implementing this solution needs reading more details from USB subsystem.
>> >>
>> >> The situation here is clear IMO - the number of USB ports in the system
>> >> can change dynamically. I'm not sure if this can be handled easily with
>> >> sysfs, where we usually expose an interface for known set of settings.
>> >> struct attribute arrays are usually defined statically at the compile
>> >> time and filled with the variables, that are created with DEVICE_ATTR
>> >> macro.
>> >
>> > sysfs already exposes current view of all usb devices. Just use it.
>>
>> We're talking about USB ports not devices, but this is still true. You
>> can find them in
>> /sys/bus/usb/devices/*/*-port*
>>
>> I can't see how we could use them. How could I develop sysfs interface
>> in /sys/class/leds/*/ to allow userspace assigning USB ports to the
>> LED trigger?
>
> Create /sys/bus/usb/devices/*/*-port*/led_trigger file?
>
> (Do you plan one USB trigger, or multiple ones?)

I guess it means slightly more complex cross-subsystem interaction I
may need help to understand.

First of all: I will need multiple USB port triggers. It's because
there are many devices with multiple USB LEDs. Some complex (but
existing!) case:
USB 2.0 white LED - activated by USB 2.0 dev in USB 2.0 port
USB 3.0 white LED - activated by USB 2.0 dev in USB 3.0 port
USB 3.0 green LED - activated by USB 3.0 dev in USB 3.0 port
(This devices has separated EHCI and XHCI controllers, so we have 2
logical ports for 1 physical one)

So I guess I'll need something more complex like
/sys/bus/usb/devices/*/*-port*/bcm53xx:white:usb2_led_trigger
/sys/bus/usb/devices/*/*-port*/bcm53xx:white:usb3_led_trigger
/sys/bus/usb/devices/*/*-port*/bcm53xx:green:usb3_led_trigger
in case every USB led has "usbport" trigger assigned.

How can I create above sysfs files? Should I write code for this in
ledtrig-usbport.c? That would require accessing struct usb_hub and
then struct usb_port, but both of them are internal structs defined in
drivers/usb/core/hub.h. How could I work with that?

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

Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

[Pavel Machek]

On Mon 2016-08-29 10:21:48, Rafał Miłecki wrote:
> On 29 August 2016 at 10:05, Pavel Machek  wrote:
> >> >2) Having "ports" subdir with RW files, one per each existing physical 
> >> >port
> >> >In this situation we don't need "new_port" or "remove_port". If we
> >> >want port to be observable we just do:
> >> >echo 1 > 1-1
> >> >Implementing this solution needs reading more details from USB subsystem.
> >>
> >> The situation here is clear IMO - the number of USB ports in the system
> >> can change dynamically. I'm not sure if this can be handled easily with
> >> sysfs, where we usually expose an interface for known set of settings.
> >> struct attribute arrays are usually defined statically at the compile
> >> time and filled with the variables, that are created with DEVICE_ATTR
> >> macro.
> >
> > sysfs already exposes current view of all usb devices. Just use it.
> 
> We're talking about USB ports not devices, but this is still true. You
> can find them in
> /sys/bus/usb/devices/*/*-port*
> 
> I can't see how we could use them. How could I develop sysfs interface
> in /sys/class/leds/*/ to allow userspace assigning USB ports to the
> LED trigger?

Create /sys/bus/usb/devices/*/*-port*/led_trigger file?

(Do you plan one USB trigger, or multiple ones?)
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

[Jacek Anaszewski]

On 08/26/2016 09:50 PM, Pavel Machek wrote:

On Thu 2016-08-25 20:48:04, Jacek Anaszewski wrote:

On 08/25/2016 04:30 PM, Alan Stern wrote:

On Thu, 25 Aug 2016, Jacek Anaszewski wrote:


I'd see it as follows:

#cat available_ports
#1-1 1-2 2-1

#echo "1-1" > new_port

#cat observed_ports
#1-1

#echo "2-1" > new_port

#cat observed_ports
#1-1 2-1

We've already had few discussions about the sysfs designs trying
to break the one-value-per-file rule for LED class device, and
there was always strong resistance against.


This scheme has multiple values in both the available_ports and
observed_ports files.  :-(  Not that I have any better suggestions...


Right, I forgot to add a note here, that this follows space
separated list pattern similarly as in case of triggers attribute.
Of course other suggestions are welcome.


Also a description of the device connected to the port would be a nice
feature, however I am not certain about the feasibility thereof.


What kind of description do you mean? Where should it be used / where
should it appear?



Product name/symbol. Actually it should be USB subsystem responsibility
to provide the means for querying the product name by port id, if it
is possible at all.


cat /sys/bus/usb/devices/PORT/product
cat /sys/bus/usb/devices/PORT/manufacturer

These will work if there is a device registered under PORT.


I've found only idProduct and idVendor files. They indeed uniquely
identify the device, but the numbers are not human readable.


Actually, they don't. They identify device _type_. If you have two
mice of the same type connected, they'll have same idProduct /
idVendor values.


That's true. We'd have to be able to distinguish between the devices
of the same type. The only way seems to be the port id, whereas
the initial intention was to give a hint on what device is represented
by given port id :-)

Regardless of that, having a device name instead of port id would allow
for unique identification of a device in most of cases.

--
Best regards,
Jacek Anaszewski
--
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 v1] usb: gadget: configfs: log function unbinding as information

[Romain Izard]

2016-08-29 10:13 GMT+02:00 Felipe Balbi :
>
> Hi,
>
> Romain Izard  writes:
>> Disabling USB gadget functions configured through configfs is something
>> that can happen in normal use cases. Keep the existing log for this type
>> of event, but only as information, not as an error.
>>
>> Signed-off-by: Romain Izard 
>> ---
>>  drivers/usb/gadget/configfs.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
>> index 70cf3477f951..11f3a649d9e5 100644
>> --- a/drivers/usb/gadget/configfs.c
>> +++ b/drivers/usb/gadget/configfs.c
>> @@ -1211,8 +1211,9 @@ static void purge_configs_funcs(struct gadget_info *gi)
>>
>>   list_move_tail(>list, >func_list);
>>   if (f->unbind) {
>> - dev_err(>cdev.gadget->dev, "unbind 
>> function"
>> - " '%s'/%p\n", f->name, f);
>> + dev_info(>cdev.gadget->dev,
>
> seems to me dev_dbg() is a far better alternative. We really don't need
> this on everybody's log buffer unless they really _are_ debugging some
> possible issues.

OK, I'll send a v2.

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

Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

[Rafał Miłecki]

On 29 August 2016 at 10:05, Pavel Machek  wrote:
>> >2) Having "ports" subdir with RW files, one per each existing physical port
>> >In this situation we don't need "new_port" or "remove_port". If we
>> >want port to be observable we just do:
>> >echo 1 > 1-1
>> >Implementing this solution needs reading more details from USB subsystem.
>>
>> The situation here is clear IMO - the number of USB ports in the system
>> can change dynamically. I'm not sure if this can be handled easily with
>> sysfs, where we usually expose an interface for known set of settings.
>> struct attribute arrays are usually defined statically at the compile
>> time and filled with the variables, that are created with DEVICE_ATTR
>> macro.
>
> sysfs already exposes current view of all usb devices. Just use it.

We're talking about USB ports not devices, but this is still true. You
can find them in
/sys/bus/usb/devices/*/*-port*

I can't see how we could use them. How could I develop sysfs interface
in /sys/class/leds/*/ to allow userspace assigning USB ports to the
LED trigger?

-- 
Rafał
--
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 v1] usb: gadget: configfs: log function unbinding as information

[Felipe Balbi]

Hi,

Romain Izard  writes:
> Disabling USB gadget functions configured through configfs is something
> that can happen in normal use cases. Keep the existing log for this type
> of event, but only as information, not as an error.
>
> Signed-off-by: Romain Izard 
> ---
>  drivers/usb/gadget/configfs.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
> index 70cf3477f951..11f3a649d9e5 100644
> --- a/drivers/usb/gadget/configfs.c
> +++ b/drivers/usb/gadget/configfs.c
> @@ -1211,8 +1211,9 @@ static void purge_configs_funcs(struct gadget_info *gi)
>  
>   list_move_tail(>list, >func_list);
>   if (f->unbind) {
> - dev_err(>cdev.gadget->dev, "unbind function"
> - " '%s'/%p\n", f->name, f);
> + dev_info(>cdev.gadget->dev,

seems to me dev_dbg() is a far better alternative. We really don't need
this on everybody's log buffer unless they really _are_ debugging some
possible issues.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v1] usb: gadget: configfs: log function unbinding as information

[Romain Izard]

2016-07-26 18:21 GMT+02:00 Romain Izard :
> Disabling USB gadget functions configured through configfs is something
> that can happen in normal use cases. Keep the existing log for this type
> of event, but only as information, not as an error.
>
> Signed-off-by: Romain Izard 
> ---
>  drivers/usb/gadget/configfs.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
> index 70cf3477f951..11f3a649d9e5 100644
> --- a/drivers/usb/gadget/configfs.c
> +++ b/drivers/usb/gadget/configfs.c
> @@ -1211,8 +1211,9 @@ static void purge_configs_funcs(struct gadget_info *gi)
>
> list_move_tail(>list, >func_list);
> if (f->unbind) {
> -   dev_err(>cdev.gadget->dev, "unbind 
> function"
> -   " '%s'/%p\n", f->name, f);
> +   dev_info(>cdev.gadget->dev,
> +"unbind function '%s'/%p\n",
> +f->name, f);
> f->unbind(c, f);
> }
> }
> --
> 2.7.4
>

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

Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

[Pavel Machek]

Hi!

> >2) Having "ports" subdir with RW files, one per each existing physical port
> >In this situation we don't need "new_port" or "remove_port". If we
> >want port to be observable we just do:
> >echo 1 > 1-1
> >Implementing this solution needs reading more details from USB subsystem.
> 
> The situation here is clear IMO - the number of USB ports in the system
> can change dynamically. I'm not sure if this can be handled easily with
> sysfs, where we usually expose an interface for known set of settings.
> struct attribute arrays are usually defined statically at the compile
> time and filled with the variables, that are created with DEVICE_ATTR
> macro.

sysfs already exposes current view of all usb devices. Just use it.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/3] USB Audio Gadget refactoring

[Felipe Balbi]

Hi,

Ruslan Bilovol  writes:
> I came to this patch series when wanted to do two things:
>  - use UAC1 as virtual ALSA sound card on gadget side,
>just like UAC2 is used so it's possible to do rate
>resampling
>  - have both playback/capture support in UAC1
>
> Since I wanted to have same behavior for both UAC1/UAC2,
> obviously I've got an utility part (u_audio.c) for
> virtual ALSA sound card handling like we have
> for ethernet(u_ether) or serial(u_serial) functions.
> Function-specific parts (f_uac1/f_uac2) became almost 
> as storage for class-specific USB descriptors, some
> boilerplate for configfs, binding and few USB
> config request handling.
>
> Originally in RFC [1] I've posted before, there was
> major change to f_uac1 after that it couldn't do
> direct play to existing ALSA sound card anymore,
> representing audio on gadget side as virtual
> ALSA sound card where audio streams are simply
> sinked to and sourced from it, so it may break
> current usecase for some people (and that's why
> it was RFC).
>
> During RFC discussion, it was agreed to not touch
> existing f_uac1 implementation and create new one
> instead. This patchset (v2) introduced new function
> named f_uac1_newapi and doesn't touch current f_uac1
> implementation, so people still can use old behavior
>
> Now, it's possible to use existing user-space
> applications for audio routing between Audio Gadget
> and real sound card. I personally use alsaloop tool
> from alsautils and have ability to create PCM
> loopback between two different ALSA cards using
> rate resampling, which was not possible with previous
> "direct play to ALSA card" approach in f_uac1. 
>
> While here, also dropped redundant platform
> driver/device creation in f_uac2 driver (as well as
> didn't add "never implemented" volume/mute functionality
> in f_uac1 to f_uac1_newapi) that made this work even
> easier to do.
>
> This series is tested with both legacy g_audio.ko and
> modern configfs approaches under Ubuntu 14.04 (UAC1 and
> UAC2) and under Windows7 x64 (UAC1 only) having
> perfect results in all cases.
>
> Comments, testing are welcome.
>
> v3 changes:
>  - renamed u_audio exported symbols so they don't
>conflict with old f_uac1 if both are built-in.
>
> v2 changes:
>  - do not touch f_uac1, instead created f_uac1_newapi

f_uac1_newapi What the hell man? :-s

Sure you can't change f_uac1 to newapi without introducing userland
visible changes? We really don't want to add another copy of f_uac1,
sorry.


-- 
balbi


signature.asc
Description: PGP signature

Re: [RESEND PATCH, v5 3/5] usb: xhci-mtk: make IPPC register optional

[Felipe Balbi]

Chunfeng Yun  writes:
> Make IPPC register optional to support host side of dual-role mode,
> due to it is moved into common glue layer for simplification.
>
> Signed-off-by: Chunfeng Yun 

Mathias? Are you taking these patches?? I don't wanna take peripheral
side driver if you won't take xhci side.

-- 
balbi


signature.asc
Description: PGP signature

[PATCH] usb: gadget: don't couple configfs to legacy gadgets

[Felipe Balbi]

It's perfectly fine to have all configfs functions
built-in while having modular legacy gadgets. Let's
allow for that.

Signed-off-by: Felipe Balbi 
---
 drivers/usb/gadget/Kconfig | 38 +++---
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 3c3f31ceece7..2ea3fc3c41b9 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -209,25 +209,6 @@ config USB_F_PRINTER
 config USB_F_TCM
tristate
 
-choice
-   tristate "USB Gadget Drivers"
-   default USB_ETH
-   help
- A Linux "Gadget Driver" talks to the USB Peripheral Controller
- driver through the abstract "gadget" API.  Some other operating
- systems call these "client" drivers, of which "class drivers"
- are a subset (implementing a USB device class specification).
- A gadget driver implements one or more USB functions using
- the peripheral hardware.
-
- Gadget drivers are hardware-neutral, or "platform independent",
- except that they sometimes must understand quirks or limitations
- of the particular controllers they work with.  For example, when
- a controller doesn't support alternate configurations or provide
- enough of the right types of endpoints, the gadget driver might
- not be able work with that controller, or might need to implement
- a less common variant of a device class protocol.
-
 # this first set of drivers all depend on bulk-capable hardware.
 
 config USB_CONFIGFS
@@ -475,6 +456,25 @@ config USB_CONFIGFS_F_TCM
  Both protocols can work on USB2.0 and USB3.0.
  UAS utilizes the USB 3.0 feature called streams support.
 
+choice
+   tristate "USB Gadget Drivers"
+   default USB_ETH
+   help
+ A Linux "Gadget Driver" talks to the USB Peripheral Controller
+ driver through the abstract "gadget" API.  Some other operating
+ systems call these "client" drivers, of which "class drivers"
+ are a subset (implementing a USB device class specification).
+ A gadget driver implements one or more USB functions using
+ the peripheral hardware.
+
+ Gadget drivers are hardware-neutral, or "platform independent",
+ except that they sometimes must understand quirks or limitations
+ of the particular controllers they work with.  For example, when
+ a controller doesn't support alternate configurations or provide
+ enough of the right types of endpoints, the gadget driver might
+ not be able work with that controller, or might need to implement
+ a less common variant of a device class protocol.
+
 source "drivers/usb/gadget/legacy/Kconfig"
 
 endchoice
-- 
2.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 v3 0/8] usb: ulpi: remove "dev" field from struct ulpi_ops

[Felipe Balbi]

Hi folks,

Tal Shorer  writes:
> struct ulpi_ops is defined as follows:
>
> struct ulpi_ops {
> struct device *dev;
> int (*read)(struct ulpi_ops *ops, u8 addr);
> int (*write)(struct ulpi_ops *ops, u8 addr, u8 val);
> };
>
> Upon calling ulpi_register_interface(), the struct device argument is
> put inside the struct ulpi_ops argument's dev field. Later, when
> calling the actual read()/write() operations, the struct ulpi_ops is
> passed to them and they use the stored device to access whatever
> private data they need.
>
> This means that if one wishes to reuse the same oprations for multiple
> interfaces (e.g if we have multiple instances of the same controller),
> any but the last interface registered will not operate properly (and
> the one that does work will be at the mercy of the others to not mess
> it up).
>
> I understand that barely any driver uses this bus right now, but I
> suppose it's there to be used at some point. We might as well fix the
> design here before we hit this bug.
>
> This series fixes this by passing the given struct device directly to
> the operation functions via ulpi->dev.parent in ulpi_read() and
> ulpi_write(). It also changes the operations struct to be constant
> since now nobody has a reason to modify it.
>
> Changes from v1:
>  * Split the actual api change into multiple patch as per Felipe Balbi's
>suggestion. The series now first adds the new api, then migrates
>everything to use and only then removes the old api.
>
> Changes from v2:
>  * Merge patches 2 and 3 (now patch 2)
>  * Merge patches 5 and 6 (now patch 4)
>  * Remove comment documenting the removed dev field in struct ulpi_ops
>
> Tal Shorer (8):
>   usb: ulpi: move setting of ulpi->dev parent up in ulpi_register()
>   usb: ulpi: add new api functions, {read|write}_dev()
>   usb: dwc3: ulpi: use new api
>   usb: ulpi: remove calls to old api callbacks
>   usb: ulpi: rename operations {read|write}_dev to simply {read|write}
>   usb: ulpi: remove "dev" field from struct ulpi_ops
>   usb: ulpi: make ops struct constant
>   usb: dwc3: ulpi: make dwc3_ulpi_ops constant

I have no idea how to apply these :-) Many of the patches touch dwc3,
but some touch common ulpi. Greg, is it okay if I take the entire series
and send it to you during my for-next pull request?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v4 08/10] usb: gadget: remove useless parameter in alloc_ep_req()

[Felipe Balbi]

Hi,

Felipe Ferreri Tonello  writes:
>> Felipe Ferreri Tonello  writes:
 "Felipe F. Tonello"  writes:
> The default_length parameter of alloc_ep_req was not really necessary
> and gadget drivers would almost always create an inline function to pass
> the same value to len and default_len.
>
> So this patch also removes duplicate code from few drivers.
>
> Signed-off-by: Felipe F. Tonello 
> ---
>  drivers/usb/gadget/function/f_hid.c| 10 ++
>  drivers/usb/gadget/function/f_loopback.c   |  9 +
>  drivers/usb/gadget/function/f_midi.c   | 10 ++
>  drivers/usb/gadget/function/f_sourcesink.c | 11 ++-
>  drivers/usb/gadget/u_f.c   |  7 +++
>  drivers/usb/gadget/u_f.h   |  3 +--
>  6 files changed, 11 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/usb/gadget/function/f_hid.c 
> b/drivers/usb/gadget/function/f_hid.c
> index 51980c50546d..e82a7468252e 100644
> --- a/drivers/usb/gadget/function/f_hid.c
> +++ b/drivers/usb/gadget/function/f_hid.c
> @@ -362,12 +362,6 @@ static int f_hidg_open(struct inode *inode, struct 
> file *fd)
>  
> /*-*/
>  /*usb_function   
>   */
>  
> -static inline struct usb_request *hidg_alloc_ep_req(struct usb_ep *ep,
> - unsigned length)
> -{
> - return alloc_ep_req(ep, length, length);
> -}

 actually, I prefer to keep these little helpers. I was recently playing
 with adding SG list support to g_zero (I should have patches soon) and
 it was actually very nice to have the sourcesink helper as I could just
 ditch alloc_ep_req(). The change to the driver was local to
 ss_alloc_ep_req() and nothing else changed :-)

>>>
>>> Right, but then it is worth to have the helper function. In this
>>> particular case, I am removing a useless helper functions, especially
>>> that the previous patch removes the need for the optional parameter in
>>> alloc_ep_req.
>> 
>> it's a static inline :-) It won't do any bad to keep it. And, as I said,
>> if we want to ditch aloc_ep_req() eventually, then we have just one
>> place to patch ;-)
>
> Yes, sure. But why drop alloc_ep_req()?

because we can't find a generic way of allocating sglist with enough
entries :-) Some drivers (like f_fs.c) could actually have zero-copy
sglist by just pinning user pages with get_user_pages_fast() and
following with sg_alloc_from_pages().

g_zero, however, would just "emulate" sglist by just allocating a
statically sized sg table and initializing chunks of the linear req->buf
to each sg entry.

> So should I keep all these helper functions? If so, I actually still
> need to fix them to use the newer alloc_ep_req() API.

yeah, keeping the helper functions would be nice. IMHO, alloc_ep_req()
doesn't have a long life, but it's pretty good for the time being.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

[Jacek Anaszewski]

On 08/26/2016 05:58 PM, Rafał Miłecki wrote:

On 25 August 2016 at 20:48, Jacek Anaszewski  wrote:

On 08/25/2016 04:30 PM, Alan Stern wrote:


On Thu, 25 Aug 2016, Jacek Anaszewski wrote:


I'd see it as follows:

#cat available_ports
#1-1 1-2 2-1

#echo "1-1" > new_port

#cat observed_ports
#1-1

#echo "2-1" > new_port

#cat observed_ports
#1-1 2-1

We've already had few discussions about the sysfs designs trying
to break the one-value-per-file rule for LED class device, and
there was always strong resistance against.



This scheme has multiple values in both the available_ports and
observed_ports files.  :-(  Not that I have any better suggestions...



Right, I forgot to add a note here, that this follows space
separated list pattern similarly as in case of triggers attribute.
Of course other suggestions are welcome.


So ppl have doubts about multiple values in a single sysfs file
(whatever we call it: "ports" or "observed_ports"). Greg clearly said:

sysfs is "one value per file", here you are listing a bunch of things in
one sysfs file.  Please don't do that.


What about my idea of using "ports" subdirectory and having each port
as separated file inside that subdir? I think there are two ways of
doing this:

1) Having "ports" subdir with 0x chmod files, one per each port
specified as observable
In this solution we need "new_port" and "remove_port" that can be used
for management of observable ports.
I think Jacek wasn't happy with this chmod and he believes Greg meant R/W files.


It looks odd to me. In this case it would also abuse "one value per
file" rule - the files would have no value, and only their names would
carry an information.


2) Having "ports" subdir with RW files, one per each existing physical port
In this situation we don't need "new_port" or "remove_port". If we
want port to be observable we just do:
echo 1 > 1-1
Implementing this solution needs reading more details from USB subsystem.


The situation here is clear IMO - the number of USB ports in the system
can change dynamically. I'm not sure if this can be handled easily with
sysfs, where we usually expose an interface for known set of settings.
struct attribute arrays are usually defined statically at the compile
time and filled with the variables, that are created with DEVICE_ATTR
macro.


Do you find any of solutions with "ports" subdir better than dealing
with new-line/space separated values in a single sysfs file?




--
Best regards,
Jacek Anaszewski
--
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: [RESEND PATCH 3/4] usb: dwc2: assert phy reset when waking up in rk3288 platform

[Felipe Balbi]

Hi,

John Youn  writes:

[...]

 +   */
 +  if (of_device_is_compatible(np, "rockchip,rk3288-usb"))
 +  hsotg->phy->ops->reset(hsotg->phy);
 +
>>>
>>> You should probably check for NULL before calling the reset()
>>> callback.
>> Sure.
>>>
>>> Also, I'd rather see a generic quirk property that you set for your
>>> platform.
>>>
>>> Something like "phy_reset_on_wakeup_quirk".
>> But Rob Herring want me to implied by the SoC specific compatible 
>> string. I agree with him. It is certainly bug in RK3288 platform.
>> It is no found no the other platform.
>
> Ok, I missed that before.
>
> Based on the drivers I'm familiar with (like dwc3), you would
> typically add a "quirk" anyways.
>
> Felipe,
>
> Do you have some policy or preference on this?

if it's not a dwc2-generic feature, then let's do it via compatible
flag, sure. What we don't want is for things like:

if (is_compatible('synopsys') || is_compatible('rockchip') ||
is_compatible('foobar') ... )

For that, we'd be better of adding a generic quirk flag which several
can use.

-- 
balbi


signature.asc
Description: PGP signature

Re: UAS and f_tcm -- is anyone using it?

[Felipe Balbi]

Hi,

John Youn  writes:
> On 8/26/2016 12:48 AM, Felipe Balbi wrote:
>> 
>> Hi,
>> 
>> John Youn  writes:
>>> I was wondering if anyone is using the f_tcm function? Specifically
>>> for UAS in superspeed with streams? Any idea if it is being using in
>>> production for this anywhere?
>>>
>>> I've been trying to get the tcm gadget running without success. It
>>> seems I need to configure the target system via configfs and somehow
>>> interface it to this gadget. But I have not found any documentation or
>>> examples on how to get it working. Anyone have ideas or pointers?
>> 
>> Sebastian has posted his scripts here several times, it's in the
>> archives :-)
>
> I found some scripts before but none of them resulted in a working
> system. Though I did manage to get something semi-working
> eventually. It would still be nice to have some documentation about
> this part especially as I have no knowledge of the target side and no
> idea what those scripts are doing.

What do you mean by "semi-working"? How far did you get? Can you capture
tracepoints so we figure out what's wrong?

# mkdir -p /t
# mount -t tracefs none /t
# echo 8192 > /t/buffer_size_kb
# echo 1 > /t/events/dwc3/enable

(trigger issue)

# cp /t/trace ~/trace.txt

Send me trace.txt ;-)

>> There's also a TCM python tool somewhere which helps with this. I
>> haven't used f_tcm in a long while, but Sebastian and I used it long
>> back to test streams with dwc3.
>
> Have you tried it recently? Or do you know of anyone who has?

Sebastian is the only one I know who has used this in the past.

>>> Just from the code it seems there will be some fundamental issues with
>>> it, such as the value of maxpacket size and some alt-interface
>>> stuff. At least when used with DWC3.
>> 
>> such as?
>
> I'll see if I can write up the exact issues later. I have to go back
> to my notes to remind myself.
>
> But just in trying to get it to work, these issues make me suspect no
> one is using this driver in superspeed, or at least regularly testing
> it, let alone using it in production.

that's probably true, but it's not enough argument to have a duplicate
implementation of it :-) Rather, we should be figuring out what's broken
and fixing it. I have a ton of other stuff to be done, but I'll add this
to my queue, no issues.

-- 
balbi


signature.asc
Description: PGP signature

Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422

[Felipe Balbi]

Hi,

Michael Niewöhner  writes:
> [1.] One line summary of the problem:
> DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
>
> [2.] Full description of the problem/report:
> No usb 3.0 devices are being detected when attached while USB 2.0
> devices work on the same port.
> USB 3.0 works after applying patches [9.1] and [9.2], but seems to be
> buggy. The usb hub is redetected every time an usb device is attached.

dwc3 is host, which means it's actually XHCI :-)

Adding Mathias

> dmesg:
> [  192.287080] usb 3-1.2: USB disconnect, device number 7
> [  210.370699] hub 3-1:1.0: hub_ext_port_status failed (err = -71)
> [  210.375159] usb 3-1-port2: connect-debounce failed
> [  210.380126] usb 3-1: USB disconnect, device number 5
> [  210.488917] usb 4-1: USB disconnect, device number 3
> [  210.708861] usb 3-1: new high-speed USB device number 9 using xhci-hcd
> [  210.851308] usb 3-1: New USB device found, idVendor=05e3, idProduct=0610
> [  210.856530] usb 3-1: New USB device strings: Mfr=1, Product=2, 
> SerialNumber=0
> [  210.863696] usb 3-1: Product: USB2.0 Hub
> [  210.867721] usb 3-1: Manufacturer: GenesysLogic
> [  210.877800] hub 3-1:1.0: USB hub found
> [  210.880600] hub 3-1:1.0: 2 ports detected
> [  210.913438] [drm:hdmi_probe] *ERROR* Failed to get ddc i2c adapter by node
> [  211.468970] usb 3-1.2: new high-speed USB device number 10 using xhci-hcd
> [  211.579279] usb 3-1.2: New USB device found, idVendor=0951, idProduct=1666
> [  211.584667] usb 3-1.2: New USB device strings: Mfr=1, Product=2, 
> SerialNumber=3
> [  211.592002] usb 3-1.2: Product: DataTraveler 3.0
> [  211.596720] usb 3-1.2: Manufacturer: Kingston
> [  211.601075] usb 3-1.2: SerialNumber: 00190F0C0295BE711962B008
> [  211.607557] usb-storage 3-1.2:1.0: USB Mass Storage device detected
> [  211.613640] scsi host0: usb-storage 3-1.2:1.0
> [  211.620179] [drm:hdmi_probe] *ERROR* Failed to get ddc i2c adapter by node
> [  212.677008] scsi 0:0:0:0: Direct-Access Kingston DataTraveler 3.0 PMAP 
> PQ: 0 ANSI: 6
> [  212.685208] sd 0:0:0:0: Attached scsi generic sg0 type 0
> [  212.687323] [drm:hdmi_probe] *ERROR* Failed to get ddc i2c adapter by node
> [  214.209074] usb 4-1: new SuperSpeed USB device number 4 using xhci-hcd
> [  214.231660] usb 4-1: New USB device found, idVendor=05e3, idProduct=0616
> [  214.236882] usb 4-1: New USB device strings: Mfr=1, Product=2, 
> SerialNumber=0
> [  214.244057] usb 4-1: Product: USB3.0 Hub
> [  214.248060] usb 4-1: Manufacturer: GenesysLogic
> [  214.254181] hub 4-1:1.0: USB hub found
> [  214.256754] hub 4-1:1.0: 2 ports detected
> [  214.264279] [drm:hdmi_probe] *ERROR* Failed to get ddc i2c adapter by node
> [  214.634773] sd 0:0:0:0: [sda] 61457664 512-byte logical blocks: (31.5 
> GB/29.3 GiB)
> [  214.641164] sd 0:0:0:0: [sda] Write Protect is off
> [  214.645631] sd 0:0:0:0: [sda] Mode Sense: 23 00 00 00
> [  214.645900] sd 0:0:0:0: [sda] No Caching mode page found
> [  214.650978] sd 0:0:0:0: [sda] Assuming drive cache: write through [  
> 214.682552]  sda: sda1
> [  214.685165] sd 0:0:0:0: [sda] Attached SCSI removable disk
> [  234.526936] usb 3-1.2: USB disconnect, device number 10
>
> [3.] Keywords (i.e., modules, networking, kernel):
> usb 3.0, dwc3, exynos, odroid
>  
> [4.] Kernel information
> 4.6.x, 4.7.x
>
> [4.1.] Kernel version (from /proc/version):
> Linux version 4.7.2+ (c0d3@z3r0) (gcc version 5.3.1 20160113 (Linaro
> GCC 5.3-2016.02) ) #1 SMP Sun Aug 28 18:52:25 CEST 2016
>
> [4.2.] Kernel .config file:
> #cat .config | grep -E "(USB|DWC|DRD).*=(m|y)"
> CONFIG_CAN_EMS_USB=m
> CONFIG_CAN_ESD_USB2=m
> CONFIG_CAN_GS_USB=m
> CONFIG_CAN_KVASER_USB=m
> CONFIG_CAN_PEAK_USB=m
> CONFIG_CAN_8DEV_USB=m
> CONFIG_BT_HCIBTUSB=m
> CONFIG_BT_HCIBTUSB_BCM=y
> CONFIG_BT_HCIBTUSB_RTL=y
> CONFIG_USB_NET_DRIVERS=y
> CONFIG_USB_CATC=m
> CONFIG_USB_KAWETH=m
> CONFIG_USB_PEGASUS=m
> CONFIG_USB_RTL8150=m
> CONFIG_USB_RTL8152=m
> CONFIG_USB_USBNET=m
> CONFIG_USB_NET_AX8817X=m
> CONFIG_USB_NET_AX88179_178A=m
> CONFIG_USB_NET_CDCETHER=m
> CONFIG_USB_NET_CDC_EEM=m
> CONFIG_USB_NET_CDC_NCM=m
> CONFIG_USB_NET_HUAWEI_CDC_NCM=m
> CONFIG_USB_NET_CDC_MBIM=m
> CONFIG_USB_NET_DM9601=m
> CONFIG_USB_NET_SR9700=m
> CONFIG_USB_NET_SR9800=m
> CONFIG_USB_NET_SMSC75XX=m
> CONFIG_USB_NET_SMSC95XX=m
> CONFIG_USB_NET_GL620A=m
> CONFIG_USB_NET_NET1080=m
> CONFIG_USB_NET_PLUSB=m
> CONFIG_USB_NET_MCS7830=m
> CONFIG_USB_NET_RNDIS_HOST=m
> CONFIG_USB_NET_CDC_SUBSET_ENABLE=m
> CONFIG_USB_NET_CDC_SUBSET=m
> CONFIG_USB_ALI_M5632=y
> CONFIG_USB_AN2720=y
> CONFIG_USB_BELKIN=y
> CONFIG_USB_ARMLINUX=y
> CONFIG_USB_EPSON2888=y
> CONFIG_USB_KC2190=y
> CONFIG_USB_NET_ZAURUS=m
> CONFIG_USB_NET_CX82310_ETH=m
> CONFIG_USB_NET_KALMIA=m
> CONFIG_USB_NET_QMI_WWAN=m
> CONFIG_USB_HSO=m
> CONFIG_USB_NET_INT51X1=m
> CONFIG_USB_CDC_PHONET=m
> CONFIG_USB_IPHETH=m
> CONFIG_USB_SIERRA_NET=m
> CONFIG_USB_VL600=m
> CONFIG_ATH6KL_USB=m
> CONFIG_AT76C50X_USB=m
> CONFIG_BRCMFMAC_USB=y
> CONFIG_P54_USB=m
> 

Re: [PATCH] usb: xhci-plat: Add generic PHY support

[Srinath Mannam]

Hi Mathias Nyman,

Could you please provide your inputs on this?
If you find it in good condition, please consider it for the next release.

Thanks & Regards,
Srinath.

On Wed, Aug 3, 2016 at 7:03 PM, Srinath Mannam
 wrote:
> Hi Mathias Nyman,
>
> Please review and provide your comments to the changes in this patch.
>
> Regards,
> srinath.
>
> On Thu, Jul 14, 2016 at 3:29 PM, Felipe Balbi
>  wrote:
>>
>> Hi,
>>
>> Srinath Mannam  writes:
>>> Generic phy support added in xhci platform driver.
>>> In the case of multiple phys to the xhci controller, this approach
>>> is helpful to pass multiple phandles to xhci platform driver from
>>> xhci device node.
>>>
>>> Signed-off-by: Srinath Mannam 
>>> Reviewed-by: Ray Jui 
>>> Reviewed-by: Scott Branden 
>>
>> I have no issues with this, but Mathias is off for a few weeks.
>>
>> --
>> balbi
--
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