Re: [PATCH] usbip: Remove unnecessary null check

[shuah]

Hi Suwan,

On 3/5/19 8:11 AM, Suwan Kim wrote:

"vdev" points to vhci_hcd->vdev[] array and vhci_hcd->vdev[] array
is not a pointer array but a structure array and it is already used
in vhci_urb_enqueue() and then passed to vhci_tx_urb() as an argument.
vhci_tx_urb() is not called except vhci_urb_enqueue(). So, "vdev"
can not be null pointer. This null check statement is meaningless.

Signed-off-by: Suwan Kim 
---
  drivers/usb/usbip/vhci_hcd.c | 8 +---
  1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
index f46ee1fefe02..667d9c0ec905 100644
--- a/drivers/usb/usbip/vhci_hcd.c
+++ b/drivers/usb/usbip/vhci_hcd.c
@@ -654,15 +654,9 @@ static int vhci_hub_control(struct usb_hcd *hcd, u16 
typeReq, u16 wValue,
  static void vhci_tx_urb(struct urb *urb, struct vhci_device *vdev)
  {
struct vhci_priv *priv;
-   struct vhci_hcd *vhci_hcd;
+   struct vhci_hcd *vhci_hcd = vdev_to_vhci_hcd(vdev);
unsigned long flags;
  
-	if (!vdev) {

-   pr_err("could not get virtual device");
-   return;
-   }
-   vhci_hcd = vdev_to_vhci_hcd(vdev);
-
priv = kzalloc(sizeof(struct vhci_priv), GFP_ATOMIC);
if (!priv) {
usbip_event_add(&vdev->ud, VDEV_EVENT_ERROR_MALLOC);



Thanks for the patch. Looks good to me.

Acked-by: Shuah Khan 

thanks,
-- Shuah

Re: [PATCH] usb: usbip: fix isoc packet num validation in get_pipe

[shuah]

On 4/14/19 4:00 AM, Malte Leip wrote:

Change the validation of number_of_packets in get_pipe to compare the
number of packets to a fixed maximum number of packets allowed, set to
be 1024. This number was chosen due to it being used by other drivers as
well, for example drivers/usb/host/uhci-q.c

Background/reason:
The get_pipe function in stub_rx.c validates the number of packets in
isochronous mode and aborts with an error if that number is too large,
in order to prevent malicious input from possibly triggering large
memory allocations. This was previously done by checking whether
pdu->u.cmd_submit.number_of_packets is bigger than the number of packets
that would be needed for pdu->u.cmd_submit.transfer_buffer_length bytes
if all except possibly the last packet had maximum length, given by
usb_endpoint_maxp(epd) *  usb_endpoint_maxp_mult(epd). This leads to an
error if URBs with packets shorter than the maximum possible length are
submitted, which is allowed according to
Documentation/driver-api/usb/URB.rst and occurs for example with the
snd-usb-audio driver.

Fixes: c6688ef9f297 ("usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious 
input")
Signed-off-by: Malte Leip 


Looks good to me.

Acked-by: Shuah Khan 

thanks,
-- Shuah

Re: [PATCH] usbip: stub_rx: tidy the indenting in is_clear_halt_cmd()

[shuah]

On 4/24/19 3:54 AM, Dan Carpenter wrote:

There is an extra space character before the return statement.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/usb/usbip/stub_rx.c b/drivers/usb/usbip/stub_rx.c
index 97b09a42a10c..f3230bed18af 100644
--- a/drivers/usb/usbip/stub_rx.c
+++ b/drivers/usb/usbip/stub_rx.c
@@ -17,9 +17,9 @@ static int is_clear_halt_cmd(struct urb *urb)
  
  	req = (struct usb_ctrlrequest *) urb->setup_packet;
  
-	 return (req->bRequest == USB_REQ_CLEAR_FEATURE) &&

-(req->bRequestType == USB_RECIP_ENDPOINT) &&
-(req->wValue == USB_ENDPOINT_HALT);
+   return (req->bRequest == USB_REQ_CLEAR_FEATURE) &&
+  (req->bRequestType == USB_RECIP_ENDPOINT) &&
+  (req->wValue == USB_ENDPOINT_HALT);
  }
  
  static int is_set_interface_cmd(struct urb *urb)




Thanks for the patch.

Acked-by: Shuah Khan 

thanks,
-- Shuah

Re: [PATCH v2 0/2] usbip: Implement SG support

[shuah]

On 7/5/19 10:43 AM, Suwan Kim wrote:

There are bugs on vhci with usb 3.0 storage device. Originally, vhci
doesn't supported SG, so USB storage driver on vhci breaks SG list
into multiple URBs and it causes error that a transfer got terminated
too early because the transfer length for one of the URBs was not
divisible by the maxpacket size.

To support SG, vhci doesn't map and unmap URB for DMA to use native
SG list (urb->num_sgs). In DMA mapping function of vhci, it sets
URB_DMA_MAP_SG flag in urb->transfer_flags if URB has SG list and
this flag will tell the stub driver to use SG list.

In this patch, vhci basically support SG and it sends each SG list
entry to the stub driver. Then, the stub driver sees the total length
of the buffer and allocates SG table and pages according to the total
buffer length calling sgl_alloc(). After the stub driver receives
completed URB, it again sends each SG list entry to vhci.

If HCD of the server doesn't support SG, the stub driver breaks a
single SG reqeust into several URBs and submit them to the server's
HCD. When all the split URBs are completed, the stub driver
reassembles the URBs into a single return command and sends it to
vhci.

Alan fixed vhci bug with the USB 3.0 storage device by modifying
USB storage driver.
("usb-storage: Set virt_boundary_mask to avoid SG overflows")
But the fundamental solution of it is to add SG support to vhci.

This patch works well with the USB 3.0 storage devices without Alan's
patch, and we can revert Alan's patch if it causes some troubles.

Suwan Kim (2):
   usbip: Skip DMA mapping and unmapping for urb at vhci
   usbip: Implement SG support to vhci

  drivers/usb/usbip/stub.h |   7 +-
  drivers/usb/usbip/stub_main.c|  52 +---
  drivers/usb/usbip/stub_rx.c  | 207 ++-
  drivers/usb/usbip/stub_tx.c  | 108 +++-
  drivers/usb/usbip/usbip_common.c |  60 +++--
  drivers/usb/usbip/vhci_hcd.c |  29 -
  drivers/usb/usbip/vhci_tx.c  |  49 ++--
  7 files changed, 391 insertions(+), 121 deletions(-)



Hi Suwan,

I have been traveling and would like to test this series before I ask
Greg to pick it up.

Just a quick note that I will get to this early next week.

thanks,
-- Shuah

Re: [PATCH v2 1/2] usbip: Skip DMA mapping and unmapping for urb at vhci

[shuah]

Hi Suwan,

On 7/5/19 10:43 AM, Suwan Kim wrote:

vhci doesn’t do DMA for remote device. Actually, the real DMA
operation is done by network card driver. vhci just passes virtual
address of the buffer to the network stack, so vhci doesn’t use and
need dma address of the buffer of the URB.

When it comes to supporting SG for vhci, it is useful to use native
SG list (urb->num_sgs) instead of mapped SG list because DMA mapping
fnuction can adjust the number of SG list (urb->num_mapped_sgs).

But HCD provides DMA mapping and unmapping function by default.
Moreover, it causes unnecessary DMA mapping and unmapping which
will be done again at the NIC driver and it wastes CPU cycles.
So, implement map_urb_for_dma and unmap_urb_for_dma function for
vhci in order to skip the DMA mapping and unmapping procedure.

To support SG, vhci_map_urb_for_dma() sets URB_DMA_MAP_SG flag in
urb->transfer_flags if URB has SG list and this flag will tell the
stub driver to use SG list.

Signed-off-by: Suwan Kim 
---
  drivers/usb/usbip/vhci_hcd.c | 19 +++
  1 file changed, 19 insertions(+)

diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
index 000ab7225717..14fc6d9f4e6a 100644
--- a/drivers/usb/usbip/vhci_hcd.c
+++ b/drivers/usb/usbip/vhci_hcd.c
@@ -1288,6 +1288,22 @@ static int vhci_free_streams(struct usb_hcd *hcd, struct 
usb_device *udev,
return 0;
  }
  
+static int vhci_map_urb_for_dma(struct usb_hcd *hcd, struct urb *urb,

+   gfp_t mem_flags)
+{
+   dev_dbg(hcd->self.controller, "vhci does not map urb for dma\n");
+
+   if (urb->num_sgs)
+   urb->transfer_flags |= URB_DMA_MAP_SG;
+


Shouldn't this be part of patch 2. The debug message saying "no map"
and setting flag doesn't make sense.


+   return 0;


This should be a tab and no spaces btw. chekpatch isn't happy.


+}
+
+static void vhci_unmap_urb_for_dma(struct usb_hcd *hcd, struct urb *urb)
+{
+   dev_dbg(hcd->self.controller, "vhci does not unmap urb for dma\n");


This should be a tab and no spaces btw. chekpatch isn't happy.


WARNING: please, no spaces at the start of a line
#144: FILE: drivers/usb/usbip/vhci_hcd.c:1299:
+   return 0;$

WARNING: please, no spaces at the start of a line
#149: FILE: drivers/usb/usbip/vhci_hcd.c:1304:
+   dev_dbg(hcd->self.controller, "vhci does not unmap urb for dma\n");$

total: 0 errors, 2 warnings, 31 lines checked



+}
+
  static const struct hc_driver vhci_hc_driver = {
.description= driver_name,
.product_desc   = driver_desc,
@@ -1304,6 +1320,9 @@ static const struct hc_driver vhci_hc_driver = {
  
  	.get_frame_number = vhci_get_frame_number,
  
+	.map_urb_for_dma = vhci_map_urb_for_dma,

+   .unmap_urb_for_dma = vhci_unmap_urb_for_dma,
+
.hub_status_data = vhci_hub_status,
.hub_control    = vhci_hub_control,
.bus_suspend= vhci_bus_suspend,



thanks,
-- Shuah

Re: [PATCH v2 2/2] usbip: Implement SG support to vhci

[shuah]

   kfree(urb->transfer_buffer);
-   urb->transfer_buffer = NULL;
+   for (i = 0; i < priv->num_urbs; i++)
+   usb_kill_urb(priv->urbs[i]);
  
-		kfree(urb->setup_packet);

-   urb->setup_packet = NULL;
-
-   usb_free_urb(urb);
+   stub_free_priv_and_urb(priv);
}
  }
  
diff --git a/drivers/usb/usbip/stub_rx.c b/drivers/usb/usbip/stub_rx.c

index b0a855acafa3..8e32697acabb 100644
--- a/drivers/usb/usbip/stub_rx.c
+++ b/drivers/usb/usbip/stub_rx.c
@@ -7,6 +7,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include "usbip_common.h"

  #include "stub.h"
@@ -201,7 +202,7 @@ static void tweak_special_requests(struct urb *urb)
  static int stub_recv_cmd_unlink(struct stub_device *sdev,
struct usbip_header *pdu)
  {
-   int ret;
+   int ret, i;
unsigned long flags;
struct stub_priv *priv;
  
@@ -246,12 +247,13 @@ static int stub_recv_cmd_unlink(struct stub_device *sdev,

 * so a driver in a client host will know the failure
 * of the unlink request ?
 */
-   ret = usb_unlink_urb(priv->urb);
-   if (ret != -EINPROGRESS)
-   dev_err(&priv->urb->dev->dev,
-   "failed to unlink a urb # %lu, ret %d\n",
-   priv->seqnum, ret);
-
+   for (i = priv->completed_urbs; i < priv->num_urbs; i++) {
+   ret = usb_unlink_urb(priv->urbs[i]);
+   if (ret != -EINPROGRESS)
+   dev_err(&priv->urbs[i]->dev->dev,
+   "failed to unlink a urb # %lu, ret 
%d\n",
+   priv->seqnum, ret);


This could result in several error messages. This code path is much
longer now compared to previous.

This is how far I have gotten. I am going to take a look at the rest
tomorrow.

thanks,
-- Shuah

Re: [PATCH v2 2/2] usbip: Implement SG support to vhci

[shuah]

xsize;
-
size_t total_size = 0;
+   int iovnum;
+   int i;
  
  	while ((priv = dequeue_from_priv_tx(vdev)) != NULL) {

int ret;
@@ -72,18 +74,41 @@ static int vhci_send_cmd_submit(struct vhci_device *vdev)
usbip_dbg_vhci_tx("setup txdata urb seqnum %lu\n",
  priv->seqnum);
  
+		if (urb->num_sgs && usb_pipeout(urb->pipe))

+   iovnum = 2 + urb->num_sgs;


Don't you want to do some kind of range check on num_sgs?


+   else
+   iovnum = 3;
+
+   iov = kzalloc(iovnum * sizeof(*iov), GFP_KERNEL);
+   if (!iov) {
+   usbip_event_add(&vdev->ud,
+   SDEV_EVENT_ERROR_MALLOC);
+   return -ENOMEM;
+   }
+
/* 1. setup usbip_header */
setup_cmd_submit_pdu(&pdu_header, urb);
usbip_header_correct_endian(&pdu_header, 1);
+   iovnum = 0;
  
-		iov[0].iov_base = &pdu_header;

-   iov[0].iov_len  = sizeof(pdu_header);
+   iov[iovnum].iov_base = &pdu_header;
+   iov[iovnum].iov_len  = sizeof(pdu_header);
txsize += sizeof(pdu_header);
+   iovnum++;
  
  		/* 2. setup transfer buffer */

if (!usb_pipein(urb->pipe) && urb->transfer_buffer_length > 0) {
-   iov[1].iov_base = urb->transfer_buffer;
-   iov[1].iov_len  = urb->transfer_buffer_length;
+   if (urb->num_sgs && 
!usb_endpoint_xfer_isoc(&urb->ep->desc)) {
+   for_each_sg(urb->sg, sg, urb->num_sgs ,i) {
+   iov[iovnum].iov_base = sg_virt(sg);
+   iov[iovnum].iov_len = sg->length;
+   iovnum++;
+   }
+   } else {
+   iov[iovnum].iov_base = urb->transfer_buffer;
+   iov[iovnum].iov_len  = 
urb->transfer_buffer_length;
+   iovnum++;


You would have allocated 2 + urb->num_sgs for the isochronous
case as well and not use them?


+   }
txsize += urb->transfer_buffer_length;
}
  
@@ -93,25 +118,29 @@ static int vhci_send_cmd_submit(struct vhci_device *vdev)
  
  			iso_buffer = usbip_alloc_iso_desc_pdu(urb, &len);

if (!iso_buffer) {
+   kfree(iov);


Consolidate error handling for kfree(iov)


usbip_event_add(&vdev->ud,
SDEV_EVENT_ERROR_MALLOC);
return -1;
}
  
-			iov[2].iov_base = iso_buffer;

-   iov[2].iov_len  = len;
+   iov[iovnum].iov_base = iso_buffer;
+   iov[iovnum].iov_len  = len;
+   iovnum++;
txsize += len;
}
  
-		ret = kernel_sendmsg(vdev->ud.tcp_socket, &msg, iov, 3, txsize);

+   ret = kernel_sendmsg(vdev->ud.tcp_socket, &msg, iov, iovnum, 
txsize);
if (ret != txsize) {
pr_err("sendmsg failed!, ret=%d for %zd\n", ret,
   txsize);
+   kfree(iov);
kfree(iso_buffer);


Consolidate error handling for kfree(iov) and kfree(iso_buffer)


usbip_event_add(&vdev->ud, VDEV_EVENT_ERROR_TCP);
return -1;
}
  
+		kfree(iov);

kfree(iso_buffer);
usbip_dbg_vhci_tx("send txdata\n");
  



thanks,
-- Shuah

Re: [PATCH v2] usbip: tools: fix GCC8 warning for strncpy

[shuah]

On 7/25/19 7:22 AM, Liu, Changcheng wrote:

GCC8 started emitting warning about using strncpy with number of bytes
exactly equal destination size which could lead to non-zero terminated
string being copied. Use "SYSFS_PATH_MAX - 1" & "SYSFS_BUS_ID_SIZE - 1"
as number of bytes to ensure name is always zero-terminated.

Signed-off-by: Changcheng Liu 
---
v1 -> v2:
  * Correct array tail index
---
  tools/usb/usbip/libsrc/usbip_common.c| 6 --
  tools/usb/usbip/libsrc/usbip_device_driver.c | 6 --
  2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/tools/usb/usbip/libsrc/usbip_common.c 
b/tools/usb/usbip/libsrc/usbip_common.c
index bb424638d75b..b8d7d480595a 100644
--- a/tools/usb/usbip/libsrc/usbip_common.c
+++ b/tools/usb/usbip/libsrc/usbip_common.c
@@ -226,8 +226,10 @@ int read_usb_device(struct udev_device *sdev, struct 
usbip_usb_device *udev)
path = udev_device_get_syspath(sdev);
name = udev_device_get_sysname(sdev);
  
-	strncpy(udev->path,  path,  SYSFS_PATH_MAX);

-   strncpy(udev->busid, name, SYSFS_BUS_ID_SIZE);
+   strncpy(udev->path,  path,  SYSFS_PATH_MAX - 1);
+   udev->path[SYSFS_PATH_MAX - 1] = '\0';
+   strncpy(udev->busid, name, SYSFS_BUS_ID_SIZE - 1);
+   udev->busid[SYSFS_BUS_ID_SIZE - 1] = '\0';


strlcpy() would be better choice here. Any reason to not use that?

  
  	sscanf(name, "%u-%u", &busnum, &devnum);

udev->busnum = busnum;
diff --git a/tools/usb/usbip/libsrc/usbip_device_driver.c 
b/tools/usb/usbip/libsrc/usbip_device_driver.c
index 5a3726eb44ab..051d7d3f443b 100644
--- a/tools/usb/usbip/libsrc/usbip_device_driver.c
+++ b/tools/usb/usbip/libsrc/usbip_device_driver.c
@@ -91,7 +91,8 @@ int read_usb_vudc_device(struct udev_device *sdev, struct 
usbip_usb_device *dev)
copy_descr_attr16(dev, &descr, idProduct);
copy_descr_attr16(dev, &descr, bcdDevice);
  
-	strncpy(dev->path, path, SYSFS_PATH_MAX);

+   strncpy(dev->path, path, SYSFS_PATH_MAX - 1);
+   dev->path[SYSFS_PATH_MAX - 1] = '\0';
  
  	dev->speed = USB_SPEED_UNKNOWN;

speed = udev_device_get_sysattr_value(sdev, "current_speed");
@@ -110,7 +111,8 @@ int read_usb_vudc_device(struct udev_device *sdev, struct 
usbip_usb_device *dev)
dev->busnum = 0;
  
  	name = udev_device_get_sysname(plat);

-   strncpy(dev->busid, name, SYSFS_BUS_ID_SIZE);
+   strncpy(dev->busid, name, SYSFS_BUS_ID_SIZE - 1);
+   dev->busid[SYSFS_BUS_ID_SIZE - 1] = '\0';


strlcpy() would be better choice here. Any reason to not use that?


return 0;
  err:
fclose(fd);



thanks,
-- Shuah

Re: [PATCH v2] usbip: tools: fix GCC8 warning for strncpy

[shuah]

On 7/25/19 8:44 AM, Liu, Changcheng wrote:

On 08:19 Thu 25 Jul, shuah wrote:

On 7/25/19 7:22 AM, Liu, Changcheng wrote:

GCC8 started emitting warning about using strncpy with number of bytes
exactly equal destination size which could lead to non-zero terminated
string being copied. Use "SYSFS_PATH_MAX - 1" & "SYSFS_BUS_ID_SIZE - 1"
as number of bytes to ensure name is always zero-terminated.

Signed-off-by: Changcheng Liu 
---
v1 -> v2:
   * Correct array tail index
---
   tools/usb/usbip/libsrc/usbip_common.c| 6 --
   tools/usb/usbip/libsrc/usbip_device_driver.c | 6 --
   2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/tools/usb/usbip/libsrc/usbip_common.c 
b/tools/usb/usbip/libsrc/usbip_common.c
index bb424638d75b..b8d7d480595a 100644
--- a/tools/usb/usbip/libsrc/usbip_common.c
+++ b/tools/usb/usbip/libsrc/usbip_common.c
@@ -226,8 +226,10 @@ int read_usb_device(struct udev_device *sdev, struct 
usbip_usb_device *udev)
path = udev_device_get_syspath(sdev);
name = udev_device_get_sysname(sdev);
-   strncpy(udev->path,  path,  SYSFS_PATH_MAX);
-   strncpy(udev->busid, name, SYSFS_BUS_ID_SIZE);
+   strncpy(udev->path,  path,  SYSFS_PATH_MAX - 1);
+   udev->path[SYSFS_PATH_MAX - 1] = '\0';
+   strncpy(udev->busid, name, SYSFS_BUS_ID_SIZE - 1);
+   udev->busid[SYSFS_BUS_ID_SIZE - 1] = '\0';


strlcpy() would be better choice here. Any reason to not use that?


@Shuah: linux tools link with libc which doesn't implment strlcpy yet.
So tools source code can't use strlcpy function like other kernel source
code.


Right I keep forgetting that. :)
Thinking about it, udev_device_get_syspath() could return
null. Not related to this change anyway.

Thanks for fixing this.

Greg! Please pick this up:

Acked-by: Shuah Khan 

thanks,
-- Shuah

Re: [PATCH v2 2/2] usbip: Implement SG support to vhci

[shuah]

On 7/29/19 8:52 AM, Suwan Kim wrote:

Hi Shuah,

On Tue, Jul 23, 2019 at 06:21:53PM -0600, shuah wrote:

Hi Suwan,

On 7/5/19 10:43 AM, Suwan Kim wrote:

There are bugs on vhci with usb 3.0 storage device. Originally, vhci
doesn't supported SG, so USB storage driver on vhci breaks SG list
into multiple URBs and it causes error that a transfer got terminated
too early because the transfer length for one of the URBs was not
divisible by the maxpacket size.

In this patch, vhci basically support SG and it sends each SG list
entry to the stub driver. Then, the stub driver sees the total length
of the buffer and allocates SG table and pages according to the total
buffer length calling sgl_alloc(). After the stub driver receives
completed URB, it again sends each SG list entry to vhci.

If HCD of the server doesn't support SG, the stub driver breaks a
single SG reqeust into several URBs and submit them to the server's
HCD. When all the split URBs are completed, the stub driver
reassembles the URBs into a single return command and sends it to
vhci.

Signed-off-by: Suwan Kim 
---
   drivers/usb/usbip/stub.h |   7 +-
   drivers/usb/usbip/stub_main.c|  52 +---
   drivers/usb/usbip/stub_rx.c  | 207 ++-
   drivers/usb/usbip/stub_tx.c  | 108 +++-
   drivers/usb/usbip/usbip_common.c |  60 +++-- >   
drivers/usb/usbip/vhci_hcd.c |  10 +-
   drivers/usb/usbip/vhci_tx.c  |  49 ++--
   7 files changed, 372 insertions(+), 121 deletions(-)


While you are working on v3 to fix chekpatch and other issues
I pointed out, I have more for you.

What happens when you have mismatched server and client side?
i.e stub does and vhci doesn't and vice versa.

Make sure to run checkpatch. Also check spelling errors in
comments and your commit log.

I am not sure if your eeror paths are correct. Run usbip_test.sh

tools/testing/selftests/drivers/usb/usbip


I don't know what mismatch you mentioned. Are you saying
"match busid table" at the end of usbip_test.sh?
How does it relate to SG support of this patch?
Could you tell me more about the problem situation?



What happens when usbip_host is running a kernel without the sg
support and vhci_hcd does? Just make sure this works with the
checks for sg support status as a one of your tests for this
sg feature.

Looking forward to seeing v3 soon!

thanks,
-- Shuah

Re: [PATCH v2 2/2] usbip: Implement SG support to vhci

[shuah]

On 8/1/19 12:38 AM, Suwan Kim wrote:

On Mon, Jul 29, 2019 at 10:32:31AM -0600, shuah wrote:

On 7/29/19 8:52 AM, Suwan Kim wrote:

Hi Shuah,

On Tue, Jul 23, 2019 at 06:21:53PM -0600, shuah wrote:

Hi Suwan,

On 7/5/19 10:43 AM, Suwan Kim wrote:

There are bugs on vhci with usb 3.0 storage device. Originally, vhci
doesn't supported SG, so USB storage driver on vhci breaks SG list
into multiple URBs and it causes error that a transfer got terminated
too early because the transfer length for one of the URBs was not
divisible by the maxpacket size.

In this patch, vhci basically support SG and it sends each SG list
entry to the stub driver. Then, the stub driver sees the total length
of the buffer and allocates SG table and pages according to the total
buffer length calling sgl_alloc(). After the stub driver receives
completed URB, it again sends each SG list entry to vhci.

If HCD of the server doesn't support SG, the stub driver breaks a
single SG reqeust into several URBs and submit them to the server's
HCD. When all the split URBs are completed, the stub driver
reassembles the URBs into a single return command and sends it to
vhci.

Signed-off-by: Suwan Kim 
---
drivers/usb/usbip/stub.h |   7 +-
drivers/usb/usbip/stub_main.c|  52 +---
drivers/usb/usbip/stub_rx.c  | 207 ++-
drivers/usb/usbip/stub_tx.c  | 108 +++-
drivers/usb/usbip/usbip_common.c |  60 +++-- >   
drivers/usb/usbip/vhci_hcd.c |  10 +-
drivers/usb/usbip/vhci_tx.c  |  49 ++--
7 files changed, 372 insertions(+), 121 deletions(-)


While you are working on v3 to fix chekpatch and other issues
I pointed out, I have more for you.

What happens when you have mismatched server and client side?
i.e stub does and vhci doesn't and vice versa.

Make sure to run checkpatch. Also check spelling errors in
comments and your commit log.

I am not sure if your eeror paths are correct. Run usbip_test.sh

tools/testing/selftests/drivers/usb/usbip


I don't know what mismatch you mentioned. Are you saying
"match busid table" at the end of usbip_test.sh?
How does it relate to SG support of this patch?
Could you tell me more about the problem situation?



What happens when usbip_host is running a kernel without the sg
support and vhci_hcd does? Just make sure this works with the
checks for sg support status as a one of your tests for this
sg feature.


Now I understand. Thanks for the details!
As a result of testing, in the situation where vhci supports SG,
but stub does not, or vice versa, usbip works normally. Moreover,
because there is no protocol modification, there is no problem in
communication between server and client even if the one has a kernel
without SG support.

In the case of vhci supports SG and stub doesn't, because vhci sends
only the total length of the buffer to stub as it did before the
patch applied, stub only needs to allocate the required length of
buffers regardless of whether vhci supports SG or not.

If stub needs to send data buffer to vhci because of IN pipe, stub
also sends only total length of buffer as metadata and then send real
data as vhci does. Then vhci receive data from stub and store it to
the corresponding buffer of SG list entry.

In the case of stub that supports SG, if SG buffer is requested by
vhci, buffer is allocated by sgl_alloc(). However, stub that does
not support SG allocates buffer using only kmalloc(). Therefore, if
vhci supports SG and stub doesn't, stub has to allocate buffer with
kmalloc() as much as the total length of SG buffer which is quite
huge when vhci sends SG request, so it has big overhead in buffer
allocation.

And for the case of stub supports SG and vhci doesn't, since the
USB storage driver checks that vhci doesn't support SG and sends
the request to stub by splitting the SG list into multiple URBs,
stub allocates a buffer with kmalloc() as it did before this patch.

Therefore, everything works normally in a mismatch situation.


Looking for you add a test case for that. Please include this
in the commit log.


I will send the v3 soon.



Please send it soon. It would be nice to have this done as soon
as possible.

thanks,
-- Shuah

Re: [PATCH v2 2/2] usbip: Implement SG support to vhci

[shuah]

On 8/2/19 1:41 AM, Suwan Kim wrote:

On Thu, Aug 01, 2019 at 08:03:59AM -0600, shuah wrote:

On 8/1/19 12:38 AM, Suwan Kim wrote:

On Mon, Jul 29, 2019 at 10:32:31AM -0600, shuah wrote:

On 7/29/19 8:52 AM, Suwan Kim wrote:

Hi Shuah,

On Tue, Jul 23, 2019 at 06:21:53PM -0600, shuah wrote:

Hi Suwan,

On 7/5/19 10:43 AM, Suwan Kim wrote:

There are bugs on vhci with usb 3.0 storage device. Originally, vhci
doesn't supported SG, so USB storage driver on vhci breaks SG list
into multiple URBs and it causes error that a transfer got terminated
too early because the transfer length for one of the URBs was not
divisible by the maxpacket size.

In this patch, vhci basically support SG and it sends each SG list
entry to the stub driver. Then, the stub driver sees the total length
of the buffer and allocates SG table and pages according to the total
buffer length calling sgl_alloc(). After the stub driver receives
completed URB, it again sends each SG list entry to vhci.

If HCD of the server doesn't support SG, the stub driver breaks a
single SG reqeust into several URBs and submit them to the server's
HCD. When all the split URBs are completed, the stub driver
reassembles the URBs into a single return command and sends it to
vhci.

Signed-off-by: Suwan Kim 
---
 drivers/usb/usbip/stub.h |   7 +-
 drivers/usb/usbip/stub_main.c|  52 +---
 drivers/usb/usbip/stub_rx.c  | 207 ++-
 drivers/usb/usbip/stub_tx.c  | 108 +++-
 drivers/usb/usbip/usbip_common.c |  60 +++-- >   
drivers/usb/usbip/vhci_hcd.c |  10 +-
 drivers/usb/usbip/vhci_tx.c  |  49 ++--
 7 files changed, 372 insertions(+), 121 deletions(-)


While you are working on v3 to fix chekpatch and other issues
I pointed out, I have more for you.

What happens when you have mismatched server and client side?
i.e stub does and vhci doesn't and vice versa.

Make sure to run checkpatch. Also check spelling errors in
comments and your commit log.

I am not sure if your eeror paths are correct. Run usbip_test.sh

tools/testing/selftests/drivers/usb/usbip


I don't know what mismatch you mentioned. Are you saying
"match busid table" at the end of usbip_test.sh?
How does it relate to SG support of this patch?
Could you tell me more about the problem situation?



What happens when usbip_host is running a kernel without the sg
support and vhci_hcd does? Just make sure this works with the
checks for sg support status as a one of your tests for this
sg feature.


Now I understand. Thanks for the details!
As a result of testing, in the situation where vhci supports SG,
but stub does not, or vice versa, usbip works normally. Moreover,
because there is no protocol modification, there is no problem in
communication between server and client even if the one has a kernel
without SG support.

In the case of vhci supports SG and stub doesn't, because vhci sends
only the total length of the buffer to stub as it did before the
patch applied, stub only needs to allocate the required length of
buffers regardless of whether vhci supports SG or not.

If stub needs to send data buffer to vhci because of IN pipe, stub
also sends only total length of buffer as metadata and then send real
data as vhci does. Then vhci receive data from stub and store it to
the corresponding buffer of SG list entry.

In the case of stub that supports SG, if SG buffer is requested by
vhci, buffer is allocated by sgl_alloc(). However, stub that does
not support SG allocates buffer using only kmalloc(). Therefore, if
vhci supports SG and stub doesn't, stub has to allocate buffer with
kmalloc() as much as the total length of SG buffer which is quite
huge when vhci sends SG request, so it has big overhead in buffer
allocation.

And for the case of stub supports SG and vhci doesn't, since the
USB storage driver checks that vhci doesn't support SG and sends
the request to stub by splitting the SG list into multiple URBs,
stub allocates a buffer with kmalloc() as it did before this patch.

Therefore, everything works normally in a mismatch situation.


Looking for you add a test case for that. Please include this
in the commit log.


I'm confused about the test case. Do I add the test case for each
SG support status of vhci_hcd and usbip_host in usbip_test.sh?
Or, do I implement the test logic in vhci_hcd code that asks if
usbip_host supports SG when attaching a remote device?
I'm sorry but I don't know what exactly you want to add.



What I am asking you do is:

1. test with mismatched host and client.
2. run usbip_test.sh

These two are separate tests. I am not asking you to add any tests.
If you want to add it, I am not going say no :)

How close are you sending the patch?

thanks,
-- Shuah

Re: [PATCH v3 1/2] usbip: Skip DMA mapping and unmapping for urb at vhci

[shuah]

On 8/2/19 11:36 AM, Suwan Kim wrote:

vhci doesn’t do DMA for remote device. Actually, the real DMA
operation is done by network card driver. vhci just passes virtual
address of the buffer to the network stack, so vhci doesn’t use and
need dma address of the buffer of the URB.

But HCD provides DMA mapping and unmapping function by default.
Moreover, it causes unnecessary DMA mapping and unmapping which
will be done again at the NIC driver and it wastes CPU cycles.
So, implement map_urb_for_dma and unmap_urb_for_dma function for
vhci in order to skip the DMA mapping and unmapping procedure.

When it comes to supporting SG for vhci, it is useful to use native
SG list (urb->num_sgs) instead of mapped SG list because DMA mapping
fnuction can adjust the number of SG list (urb->num_mapped_sgs).
And vhci_map_urb_for_dma() prevents isoc pipe from using SG as
hcd_map_urb_for_dma() does.

Signed-off-by: Suwan Kim 
---
  drivers/usb/usbip/vhci_hcd.c | 19 +++
  1 file changed, 19 insertions(+)

diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
index 000ab7225717..c62f7fa8118c 100644
--- a/drivers/usb/usbip/vhci_hcd.c
+++ b/drivers/usb/usbip/vhci_hcd.c
@@ -1288,6 +1288,22 @@ static int vhci_free_streams(struct usb_hcd *hcd, struct 
usb_device *udev,
return 0;
  }
  
+static int vhci_map_urb_for_dma(struct usb_hcd *hcd, struct urb *urb,

+   gfp_t mem_flags)
+{
+   if (usb_endpoint_xfer_isoc(&urb->ep->desc) && urb->num_sgs) {
+   WARN_ON(1);


Don't add WARN_ON. I cleaned them all up recently and don't want new
ones added.

thanks,
-- Shuah

Re: [PATCH v3 2/2] usbip: Implement SG support to vhci-hcd and stub driver

[shuah]

, struct urb *urb)
  {
-   int ret;
+   struct scatterlist *sg;
+   int ret = 0;
+   int recv;
int size;
+   int copy;
+   int i;
  
  	if (ud->side == USBIP_STUB || ud->side == USBIP_VUDC) {

/* the direction of urb must be OUT. */
@@ -701,29 +705,48 @@ int usbip_recv_xbuff(struct usbip_device *ud, struct urb 
*urb)
if (!(size > 0))
return 0;
  
-	if (size > urb->transfer_buffer_length) {

+   if (size > urb->transfer_buffer_length)
/* should not happen, probably malicious packet */
-   if (ud->side == USBIP_STUB) {
-   usbip_event_add(ud, SDEV_EVENT_ERROR_TCP);
-   return 0;
-   } else {
-   usbip_event_add(ud, VDEV_EVENT_ERROR_TCP);
-   return -EPIPE;
-   }
-   }
+   goto error;
  
-	ret = usbip_recv(ud->tcp_socket, urb->transfer_buffer, size);

-   if (ret != size) {
-   dev_err(&urb->dev->dev, "recv xbuf, %d\n", ret);
-   if (ud->side == USBIP_STUB || ud->side == USBIP_VUDC) {
-   usbip_event_add(ud, SDEV_EVENT_ERROR_TCP);
-   } else {
-   usbip_event_add(ud, VDEV_EVENT_ERROR_TCP);
-   return -EPIPE;
+   if (urb->num_sgs) {
+   copy = size;
+   for_each_sg(urb->sg, sg, urb->num_sgs, i) {
+   int recv_size;
+
+   if (copy < sg->length)
+   recv_size = copy;
+   else
+   recv_size = sg->length;
+
+   recv = usbip_recv(ud->tcp_socket, sg_virt(sg),
+   recv_size);
+
+   if (recv != recv_size)
+   goto error;
+
+   copy -= recv;
+   ret += recv;
}
+
+   if (ret != size)
+   goto error;
+   } else {
+   ret = usbip_recv(ud->tcp_socket, urb->transfer_buffer, size);
+   if (ret != size)
+   goto error;
}
  
  	return ret;

+
+error:
+   dev_err(&urb->dev->dev, "recv xbuf, %d\n", ret);
+   if (ud->side == USBIP_STUB || ud->side == USBIP_VUDC)


Did you test VUDC and USB lowspeed cases? If you haven't please
test those two cases for regressions.

thanks,
-- Shuah

Re: [PATCH v3 0/2] usbip: Implement SG support

[shuah]

Hi Suwan,

On 8/2/19 11:36 AM, Suwan Kim wrote:

There are bugs on vhci with usb 3.0 storage device. Currently, vhci
doesn't supported SG, so USB storage driver on vhci breaks SG list
into multiple URBs and it causes error that a transfer got terminated
too early because the transfer length for one of the URBs was not
divisible by the maxpacket size.
  
In this patch, vhci supports SG regardless of whether the server's

host controller supports SG or not, because stub driver splits SG
list into several URBs if the server's host controller doesn't
support SG.
  
To support SG, vhci_map_urb_for_dma() sets URB_DMA_MAP_SG flag in

urb->transfer_flags if URB has SG list and this flag will tell stub
driver to use SG list.
  
vhci sends each SG list entry to stub driver. Then, stub driver sees

the total length of the buffer and allocates SG table and pages
according to the total buffer length calling sgl_alloc(). After stub
driver receives completed URB, it again sends each SG list entry to
vhci.
  
If the server's host controller doesn't support SG, stub driver

breaks a single SG request into several URBs and submits them to
the server's host controller. When all the split URBs are completed,
stub driver reassembles the URBs into a single return command and
sends it to vhci.

Alan fixed vhci bug with the USB 3.0 storage device by modifying
USB storage driver.
("usb-storage: Set virt_boundary_mask to avoid SG overflows")
But the fundamental solution of it is to add SG support to vhci.

This patch works well with the USB 3.0 storage devices without Alan's
patch, and we can revert Alan's patch if it causes some troubles.



Why just 3.0? Please test with lowspeed and VUDC to make sure there are
no regressions.

thanks,
-- Shuah

Re: [PATCH v3 2/2] usbip: Implement SG support to vhci-hcd and stub driver

[shuah]

On 8/5/19 2:04 AM, Suwan Kim wrote:

On Fri, Aug 02, 2019 at 04:41:52PM -0600, shuah wrote:

Hi Suwan,

On 8/2/19 11:36 AM, Suwan Kim wrote:

There are bugs on vhci with usb 3.0 storage device.


This sentence doesn't make sense to me. What bugs? Ca you eloborate?


Alan's patch description "usb-storage: Set virt_boundary_mask to
avoid SG overflows" elaborates the problem. In USB, each SG list
entry buffer should be divisible by the bulk maxpacket size. But
with native SG support, this problem doesn't matter because the
SG buffer is treated as contiguous buffer. But without native SG
support, storage driver breaks SG list into several URBs and each
URB is sparate transfer.

Let's assume that driver request 31.5 KB data and has SG list which
has 3584 bytes buffer followed by 7 4096 bytes buffer for some
reason. USB Storage driver splits this SG list into several URBs
because VHCI doesn't support SG and send them separately. So the
first URB buffer size is 3584 bytes. When receiving data from device,
USB 3.0 device sends data packet of 1024 bytes size because the max
packet size of BULK pipe is 1024 bytes. So device sends 4096 bytes.
But the first URB buffer has only 3584 bytes buffer size. So host
controller terminates the transfer even though there is more data
to receive.

Please also reference the mail thread
https://marc.info/?t=15544920963&r=1&w=2
https://marc.info/?l=linux-usb&m=15548231773&w=2



I am asking you to elaborate and add it to the commit log instead of
just saying "There are bugs on vhci with usb 3.0 storage device."

thanks,
-- Shuah

Re: [PATCH v3 1/2] usbip: Skip DMA mapping and unmapping for urb at vhci

[shuah]

On 8/4/19 11:23 PM, Suwan Kim wrote:

On Fri, Aug 02, 2019 at 04:22:27PM -0600, shuah wrote:

On 8/2/19 11:36 AM, Suwan Kim wrote:

vhci doesn’t do DMA for remote device. Actually, the real DMA
operation is done by network card driver. vhci just passes virtual
address of the buffer to the network stack, so vhci doesn’t use and
need dma address of the buffer of the URB.

But HCD provides DMA mapping and unmapping function by default.
Moreover, it causes unnecessary DMA mapping and unmapping which
will be done again at the NIC driver and it wastes CPU cycles.
So, implement map_urb_for_dma and unmap_urb_for_dma function for
vhci in order to skip the DMA mapping and unmapping procedure.

When it comes to supporting SG for vhci, it is useful to use native
SG list (urb->num_sgs) instead of mapped SG list because DMA mapping
fnuction can adjust the number of SG list (urb->num_mapped_sgs).
And vhci_map_urb_for_dma() prevents isoc pipe from using SG as
hcd_map_urb_for_dma() does.

Signed-off-by: Suwan Kim 
---
   drivers/usb/usbip/vhci_hcd.c | 19 +++
   1 file changed, 19 insertions(+)

diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
index 000ab7225717..c62f7fa8118c 100644
--- a/drivers/usb/usbip/vhci_hcd.c
+++ b/drivers/usb/usbip/vhci_hcd.c
@@ -1288,6 +1288,22 @@ static int vhci_free_streams(struct usb_hcd *hcd, struct 
usb_device *udev,
return 0;
   }
+static int vhci_map_urb_for_dma(struct usb_hcd *hcd, struct urb *urb,
+   gfp_t mem_flags)
+{
+   if (usb_endpoint_xfer_isoc(&urb->ep->desc) && urb->num_sgs) {
+   WARN_ON(1);


Don't add WARN_ON. I cleaned them all up recently and don't want new
ones added.


Ok. I will remove it and resend v4.



Please add appropriate error message in place of WARN_ON

thanks,
-- Shuah

Re: [PATCH] USB: usbip: convert platform driver to use dev_groups

[shuah]

On 8/5/19 1:36 PM, Greg Kroah-Hartman wrote:

Platform drivers now have the option to have the platform core create
and remove any needed sysfs attribute files.  So take advantage of that
and do not register "by hand" any sysfs files.

Cc: Valentina Manea 
Cc: Shuah Khan 
Signed-off-by: Greg Kroah-Hartman 
---
  drivers/usb/usbip/vudc.h   | 2 +-
  drivers/usb/usbip/vudc_dev.c   | 9 -
  drivers/usb/usbip/vudc_main.c  | 1 +
  drivers/usb/usbip/vudc_sysfs.c | 7 ++-
  4 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/usbip/vudc.h b/drivers/usb/usbip/vudc.h
index cf968192e59f..1bd4bc005829 100644
--- a/drivers/usb/usbip/vudc.h
+++ b/drivers/usb/usbip/vudc.h
@@ -115,7 +115,7 @@ struct vudc_device {
struct list_head dev_entry;
  };
  
-extern const struct attribute_group vudc_attr_group;

+extern const struct attribute_group *vudc_groups[];
  
  /* visible everywhere */
  
diff --git a/drivers/usb/usbip/vudc_dev.c b/drivers/usb/usbip/vudc_dev.c

index a72c17ff1c6a..c8eeabdd9b56 100644
--- a/drivers/usb/usbip/vudc_dev.c
+++ b/drivers/usb/usbip/vudc_dev.c
@@ -616,18 +616,10 @@ int vudc_probe(struct platform_device *pdev)
if (ret < 0)
goto err_add_udc;
  
-	ret = sysfs_create_group(&pdev->dev.kobj, &vudc_attr_group);

-   if (ret) {
-   dev_err(&udc->pdev->dev, "create sysfs files\n");
-   goto err_sysfs;
-   }
-
platform_set_drvdata(pdev, udc);
  
  	return ret;
  
-err_sysfs:

-   usb_del_gadget_udc(&udc->gadget);
  err_add_udc:
cleanup_vudc_hw(udc);
  err_init_vudc_hw:
@@ -640,7 +632,6 @@ int vudc_remove(struct platform_device *pdev)
  {
struct vudc *udc = platform_get_drvdata(pdev);
  
-	sysfs_remove_group(&pdev->dev.kobj, &vudc_attr_group);

usb_del_gadget_udc(&udc->gadget);
cleanup_vudc_hw(udc);
kfree(udc);
diff --git a/drivers/usb/usbip/vudc_main.c b/drivers/usb/usbip/vudc_main.c
index 390733e6937e..678faa82598c 100644
--- a/drivers/usb/usbip/vudc_main.c
+++ b/drivers/usb/usbip/vudc_main.c
@@ -22,6 +22,7 @@ static struct platform_driver vudc_driver = {
.remove = vudc_remove,
.driver = {
.name   = GADGET_NAME,
+   .dev_groups = vudc_groups,
},
  };
  
diff --git a/drivers/usb/usbip/vudc_sysfs.c b/drivers/usb/usbip/vudc_sysfs.c

index 6dcd3ff655c3..100f680c572a 100644
--- a/drivers/usb/usbip/vudc_sysfs.c
+++ b/drivers/usb/usbip/vudc_sysfs.c
@@ -215,7 +215,12 @@ static struct bin_attribute *dev_bin_attrs[] = {
NULL,
  };
  
-const struct attribute_group vudc_attr_group = {

+static const struct attribute_group vudc_attr_group = {
.attrs = dev_attrs,
.bin_attrs = dev_bin_attrs,
  };
+
+const struct attribute_group *vudc_groups[] = {
+   &vudc_attr_group,
+   NULL,
+};



Looks good to me.

Acked-by: Shuah Khan 

thanks,
-- Shuah

Re: [PATCH v4 1/2] usbip: Skip DMA mapping and unmapping for urb at vhci

[shuah]

On 8/6/19 6:31 AM, Suwan Kim wrote:

vhci doesn’t do DMA for remote device. Actually, the real DMA
operation is done by network card driver. vhci just passes virtual
address of the buffer to the network stack, so vhci doesn’t use and
need dma address of the buffer of the URB.

But HCD provides DMA mapping and unmapping function by default.
Moreover, it causes unnecessary DMA mapping and unmapping which
will be done again at the NIC driver and it wastes CPU cycles.
So, implement map_urb_for_dma and unmap_urb_for_dma function for
vhci in order to skip the DMA mapping and unmapping procedure.

When it comes to supporting SG for vhci, it is useful to use native
SG list (urb->num_sgs) instead of mapped SG list because DMA mapping
fnuction can adjust the number of SG list (urb->num_mapped_sgs).
And vhci_map_urb_for_dma() prevents isoc pipe from using SG as
hcd_map_urb_for_dma() does.

Signed-off-by: Suwan Kim 
---
v3 - v4:
- Replace WARN_ON() with pr_err() in the error path.

v2 - v3
- Move setting URB_DMA_MAP_SG flag to the patch 2.
- Prevent isoc pipe from using SG buffer.

v1 - v2
- Add setting URB_DMA_MAP_SG flag in urb->transfer_flags to tell
stub driver to use SG buffer.
---
  drivers/usb/usbip/vhci_hcd.c | 19 +++
  1 file changed, 19 insertions(+)

diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
index 000ab7225717..429e4e989f38 100644
--- a/drivers/usb/usbip/vhci_hcd.c
+++ b/drivers/usb/usbip/vhci_hcd.c
@@ -1288,6 +1288,22 @@ static int vhci_free_streams(struct usb_hcd *hcd, struct 
usb_device *udev,
return 0;
  }
  
+static int vhci_map_urb_for_dma(struct usb_hcd *hcd, struct urb *urb,

+   gfp_t mem_flags)
+{
+   if (usb_endpoint_xfer_isoc(&urb->ep->desc) && urb->num_sgs) {
+   pr_err("SG is not supported for isochronous transfer\n");


Any reason to not use dev_err()?

Looks good otherwise.

thanks,
-- Shuah

Re: [PATCH v4 2/2] usbip: Implement SG support to vhci-hcd and stub driver

[shuah]

On 8/6/19 6:31 AM, Suwan Kim wrote:

There are bugs on vhci with usb 3.0 storage device. In USB, each SG
list entry buffer should be divisible by the bulk max packet size.
But with native SG support, this problem doesn't matter because the
SG buffer is treated as contiguous buffer. But without native SG
support, USB storage driver breaks SG list into several URBs and the
error occurs because of a buffer size of URB that cannot be divided
by the bulk max packet size. The error situation is as follows.

When USB Storage driver requests 31.5 KB data and has SG list which
has 3584 bytes buffer followed by 7 4096 bytes buffer for some
reason. USB Storage driver splits this SG list into several URBs
because VHCI doesn't support SG and sends them separately. So the
first URB buffer size is 3584 bytes. When receiving data from device,
USB 3.0 device sends data packet of 1024 bytes size because the max
packet size of BULK pipe is 1024 bytes. So device sends 4096 bytes.
But the first URB buffer has only 3584 bytes buffer size. So host
controller terminates the transfer even though there is more data to
receive. So, vhci needs to support SG transfer to prevent this error.

In this patch, vhci supports SG regardless of whether the server's
host controller supports SG or not, because stub driver splits SG
list into several URBs if the server's host controller doesn't
support SG.

To support SG, vhci_map_urb_for_dma() sets URB_DMA_MAP_SG flag in
urb->transfer_flags if URB has SG list and this flag will tell stub
driver to use SG list.

vhci sends each SG list entry to stub driver. Then, stub driver sees
the total length of the buffer and allocates SG table and pages
according to the total buffer length calling sgl_alloc(). After stub
driver receives completed URB, it again sends each SG list entry to
vhci.

If the server's host controller doesn't support SG, stub driver
breaks a single SG request into several URBs and submits them to
the server's host controller. When all the split URBs are completed,
stub driver reassembles the URBs into a single return command and
sends it to vhci.

Moreover, in the situation where vhci supports SG, but stub driver
does not, or vice versa, usbip works normally. Because there is no
protocol modification, there is no problem in communication between
server and client even if the one has a kernel without SG support.

In the case of vhci supports SG and stub driver doesn't, because
vhci sends only the total length of the buffer to stub driver as
it did before the patch applied, stub driver only needs to allocate
the required length of buffers regardless of whether vhci supports
SG or not.

If stub driver needs to send data buffer to vhci because of IN pipe,
stub driver also sends only total length of buffer as metadata and
then sends real data as vhci does. Then vhci receive data from stub
driver and store it to the corresponding buffer of SG list entry.

In the case of stub driver that supports SG, buffer is allocated by
sgl_alloc(). However, stub driver that does not support SG allocates
buffer using only kmalloc(). Therefore, if vhci supports SG and stub
driver doesn't, stub driver has to allocate buffer with kmalloc() as
much as the total length of SG buffer which is quite huge when vhci
sends SG request, so it has big overhead in buffer allocation.

And for the case of stub driver supports SG and vhci doesn't, since
the USB storage driver checks that vhci doesn't support SG and sends
the request to stub driver by splitting the SG list into multiple
URBs, stub driver allocates a buffer with kmalloc() as it did before
this patch.

VUDC also works well with this patch. Tests are done with two USB
gadget created by CONFIGFS USB gadget. Both use the BULK pipe.

 1. Serial gadget
 2. Mass storage gadget

  * Serial gadget test

Serial gadget on the host sends and receives data using cat command
on the /dev/ttyGS. The client uses minicom to communicate with
the serial gadget.

  * Mass storage gadget test

After connecting the gadget with vhci, use "dd" to test read and
write operation on the client side.

Read  - dd if=/dev/sd iflag=direct of=/dev/null bs=1G count=1
Write - dd if= iflag=direct of=/dev/sd bs=1G count=1



Thanks for the test results.

Were you able to test with USB lowspeed devices?

thanks,
-- Shuah

Re: [PATCH v4 1/2] usbip: Skip DMA mapping and unmapping for urb at vhci

[shuah]

On 8/6/19 9:32 AM, Suwan Kim wrote:

On Tue, Aug 06, 2019 at 09:11:30AM -0600, shuah wrote:

On 8/6/19 6:31 AM, Suwan Kim wrote:

vhci doesn’t do DMA for remote device. Actually, the real DMA
operation is done by network card driver. vhci just passes virtual
address of the buffer to the network stack, so vhci doesn’t use and
need dma address of the buffer of the URB.

But HCD provides DMA mapping and unmapping function by default.
Moreover, it causes unnecessary DMA mapping and unmapping which
will be done again at the NIC driver and it wastes CPU cycles.
So, implement map_urb_for_dma and unmap_urb_for_dma function for
vhci in order to skip the DMA mapping and unmapping procedure.

When it comes to supporting SG for vhci, it is useful to use native
SG list (urb->num_sgs) instead of mapped SG list because DMA mapping
fnuction can adjust the number of SG list (urb->num_mapped_sgs).
And vhci_map_urb_for_dma() prevents isoc pipe from using SG as
hcd_map_urb_for_dma() does.

Signed-off-by: Suwan Kim 
---
v3 - v4:
- Replace WARN_ON() with pr_err() in the error path.

v2 - v3
- Move setting URB_DMA_MAP_SG flag to the patch 2.
- Prevent isoc pipe from using SG buffer.

v1 - v2
- Add setting URB_DMA_MAP_SG flag in urb->transfer_flags to tell
stub driver to use SG buffer.
---
   drivers/usb/usbip/vhci_hcd.c | 19 +++
   1 file changed, 19 insertions(+)

diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
index 000ab7225717..429e4e989f38 100644
--- a/drivers/usb/usbip/vhci_hcd.c
+++ b/drivers/usb/usbip/vhci_hcd.c
@@ -1288,6 +1288,22 @@ static int vhci_free_streams(struct usb_hcd *hcd, struct 
usb_device *udev,
return 0;
   }
+static int vhci_map_urb_for_dma(struct usb_hcd *hcd, struct urb *urb,
+   gfp_t mem_flags)
+{
+   if (usb_endpoint_xfer_isoc(&urb->ep->desc) && urb->num_sgs) {
+   pr_err("SG is not supported for isochronous transfer\n");


Any reason to not use dev_err()?


Because some codes in vhci_hcd.c use pr_err().There is no other
reason. However, dev_err() seems more appropriate than pr_err().
I will replace pr_err() with dev_err(urb->dev->dev, "SG is ...")
Is it ok?



Please. This way we will have the device information. pr_err()
won't us that. In general I prefer dev_* if dev is available in
the code path, which is the case here.

thanks,
-- Shuah

Re: [PATCH v4 2/2] usbip: Implement SG support to vhci-hcd and stub driver

[shuah]

On 8/6/19 9:48 AM, Suwan Kim wrote:

On Tue, Aug 06, 2019 at 09:13:54AM -0600, shuah wrote:

On 8/6/19 6:31 AM, Suwan Kim wrote:

There are bugs on vhci with usb 3.0 storage device. In USB, each SG
list entry buffer should be divisible by the bulk max packet size.
But with native SG support, this problem doesn't matter because the
SG buffer is treated as contiguous buffer. But without native SG
support, USB storage driver breaks SG list into several URBs and the
error occurs because of a buffer size of URB that cannot be divided
by the bulk max packet size. The error situation is as follows.

When USB Storage driver requests 31.5 KB data and has SG list which
has 3584 bytes buffer followed by 7 4096 bytes buffer for some
reason. USB Storage driver splits this SG list into several URBs
because VHCI doesn't support SG and sends them separately. So the
first URB buffer size is 3584 bytes. When receiving data from device,
USB 3.0 device sends data packet of 1024 bytes size because the max
packet size of BULK pipe is 1024 bytes. So device sends 4096 bytes.
But the first URB buffer has only 3584 bytes buffer size. So host
controller terminates the transfer even though there is more data to
receive. So, vhci needs to support SG transfer to prevent this error.

In this patch, vhci supports SG regardless of whether the server's
host controller supports SG or not, because stub driver splits SG
list into several URBs if the server's host controller doesn't
support SG.

To support SG, vhci_map_urb_for_dma() sets URB_DMA_MAP_SG flag in
urb->transfer_flags if URB has SG list and this flag will tell stub
driver to use SG list.

vhci sends each SG list entry to stub driver. Then, stub driver sees
the total length of the buffer and allocates SG table and pages
according to the total buffer length calling sgl_alloc(). After stub
driver receives completed URB, it again sends each SG list entry to
vhci.

If the server's host controller doesn't support SG, stub driver
breaks a single SG request into several URBs and submits them to
the server's host controller. When all the split URBs are completed,
stub driver reassembles the URBs into a single return command and
sends it to vhci.

Moreover, in the situation where vhci supports SG, but stub driver
does not, or vice versa, usbip works normally. Because there is no
protocol modification, there is no problem in communication between
server and client even if the one has a kernel without SG support.

In the case of vhci supports SG and stub driver doesn't, because
vhci sends only the total length of the buffer to stub driver as
it did before the patch applied, stub driver only needs to allocate
the required length of buffers regardless of whether vhci supports
SG or not.

If stub driver needs to send data buffer to vhci because of IN pipe,
stub driver also sends only total length of buffer as metadata and
then sends real data as vhci does. Then vhci receive data from stub
driver and store it to the corresponding buffer of SG list entry.

In the case of stub driver that supports SG, buffer is allocated by
sgl_alloc(). However, stub driver that does not support SG allocates
buffer using only kmalloc(). Therefore, if vhci supports SG and stub
driver doesn't, stub driver has to allocate buffer with kmalloc() as
much as the total length of SG buffer which is quite huge when vhci
sends SG request, so it has big overhead in buffer allocation.

And for the case of stub driver supports SG and vhci doesn't, since
the USB storage driver checks that vhci doesn't support SG and sends
the request to stub driver by splitting the SG list into multiple
URBs, stub driver allocates a buffer with kmalloc() as it did before
this patch.

VUDC also works well with this patch. Tests are done with two USB
gadget created by CONFIGFS USB gadget. Both use the BULK pipe.

  1. Serial gadget
  2. Mass storage gadget

   * Serial gadget test

Serial gadget on the host sends and receives data using cat command
on the /dev/ttyGS. The client uses minicom to communicate with
the serial gadget.

   * Mass storage gadget test

After connecting the gadget with vhci, use "dd" to test read and
write operation on the client side.

Read  - dd if=/dev/sd iflag=direct of=/dev/null bs=1G count=1
Write - dd if= iflag=direct of=/dev/sd bs=1G count=1



Thanks for the test results.

Were you able to test with USB lowspeed devices?


I tested USB3 super-speed device and USB2 high-speed device.
But I don't have full/low speed device that uses BULK transfer.
In USB spec, low-speed device doesn't support BULK transfer.



I think I mentioned earlier that the reason to test with lowspeed
is make sure there are no regressions due this change. You aren't
testing BULK transfer, you are looking for any regressions.


Do I add test description about the USB3 super-speed and USB2
high-speed device to the commit log?



Please do.

thanks,
-- Shuah

Re: [PATCH v5 1/2] usbip: Skip DMA mapping and unmapping for urb at vhci

[shuah]

On 8/8/19 9:54 AM, Suwan Kim wrote:

vhci doesn’t do DMA for remote device. Actually, the real DMA
operation is done by network card driver. vhci just passes virtual
address of the buffer to the network stack, so vhci doesn’t use and
need dma address of the buffer of the URB.

But HCD provides DMA mapping and unmapping function by default.
Moreover, it causes unnecessary DMA mapping and unmapping which
will be done again at the NIC driver and it wastes CPU cycles.
So, implement map_urb_for_dma and unmap_urb_for_dma function for
vhci in order to skip the DMA mapping and unmapping procedure.

When it comes to supporting SG for vhci, it is useful to use native
SG list (urb->num_sgs) instead of mapped SG list because DMA mapping
fnuction can adjust the number of SG list (urb->num_mapped_sgs).
And vhci_map_urb_for_dma() prevents isoc pipe from using SG as
hcd_map_urb_for_dma() does.

Signed-off-by: Suwan Kim 
---
v4 - v5
- Replace pr_err() with dev_err() in the error path.

v3 - v4
- Replace WARN_ON() with pr_err() in the error path.

v2 - v3
- Move setting URB_DMA_MAP_SG flag to the patch 2.
- Prevent isoc pipe from using SG buffer.

v1 - v2
- Add setting URB_DMA_MAP_SG flag in urb->transfer_flags to tell
stub driver to use SG buffer.
---
  drivers/usb/usbip/vhci_hcd.c | 19 +++
  1 file changed, 19 insertions(+)

diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
index 000ab7225717..ea82b932a2f9 100644
--- a/drivers/usb/usbip/vhci_hcd.c
+++ b/drivers/usb/usbip/vhci_hcd.c
@@ -1288,6 +1288,22 @@ static int vhci_free_streams(struct usb_hcd *hcd, struct 
usb_device *udev,
return 0;
  }
  
+static int vhci_map_urb_for_dma(struct usb_hcd *hcd, struct urb *urb,

+   gfp_t mem_flags)
+{
+   if (usb_endpoint_xfer_isoc(&urb->ep->desc) && urb->num_sgs) {
+   dev_err(&urb->dev->dev, "SG is not supported for isochronous 
transfer\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static void vhci_unmap_urb_for_dma(struct usb_hcd *hcd, struct urb *urb)
+{
+   dev_dbg(hcd->self.controller, "vhci does not unmap urb for dma\n");
+}
+
  static const struct hc_driver vhci_hc_driver = {
.description= driver_name,
.product_desc   = driver_desc,
@@ -1304,6 +1320,9 @@ static const struct hc_driver vhci_hc_driver = {
  
  	.get_frame_number = vhci_get_frame_number,
  
+	.map_urb_for_dma = vhci_map_urb_for_dma,

+   .unmap_urb_for_dma = vhci_unmap_urb_for_dma,
+
.hub_status_data = vhci_hub_status,
.hub_control= vhci_hub_control,
.bus_suspend    = vhci_bus_suspend,



Looks good to me.

Reviewed-by: Shuah Khan 

thanks,
-- Shuah

Re: [PATCH v5 2/2] usbip: Implement SG support to vhci-hcd and stub driver

[shuah]

 /* 1. setup usbip_header */
setup_cmd_submit_pdu(&pdu_header, urb);
usbip_header_correct_endian(&pdu_header, 1);
+   iovnum = 0;
  
-		iov[0].iov_base = &pdu_header;

-   iov[0].iov_len  = sizeof(pdu_header);
+   iov[iovnum].iov_base = &pdu_header;
+   iov[iovnum].iov_len  = sizeof(pdu_header);
txsize += sizeof(pdu_header);
+   iovnum++;
  
  		/* 2. setup transfer buffer */

if (!usb_pipein(urb->pipe) && urb->transfer_buffer_length > 0) {
-   iov[1].iov_base = urb->transfer_buffer;
-   iov[1].iov_len  = urb->transfer_buffer_length;
+   if (urb->num_sgs &&
+ !usb_endpoint_xfer_isoc(&urb->ep->desc)) {
+   for_each_sg(urb->sg, sg, urb->num_sgs, i) {
+   iov[iovnum].iov_base = sg_virt(sg);
+   iov[iovnum].iov_len = sg->length;
+   iovnum++;
+   }
+   } else {
+   iov[iovnum].iov_base = urb->transfer_buffer;
+   iov[iovnum].iov_len  =
+   urb->transfer_buffer_length;
+   iovnum++;
+   }
txsize += urb->transfer_buffer_length;
}
  
@@ -95,23 +124,26 @@ static int vhci_send_cmd_submit(struct vhci_device *vdev)

if (!iso_buffer) {
usbip_event_add(&vdev->ud,
        SDEV_EVENT_ERROR_MALLOC);
-   return -1;
+   goto err_iso_buffer;
}
  
-			iov[2].iov_base = iso_buffer;

-   iov[2].iov_len  = len;
+   iov[iovnum].iov_base = iso_buffer;
+   iov[iovnum].iov_len  = len;
+   iovnum++;
txsize += len;
}
  
-		ret = kernel_sendmsg(vdev->ud.tcp_socket, &msg, iov, 3, txsize);

+   ret = kernel_sendmsg(vdev->ud.tcp_socket, &msg, iov, iovnum,
+txsize);
if (ret != txsize) {
pr_err("sendmsg failed!, ret=%d for %zd\n", ret,
   txsize);
-   kfree(iso_buffer);
usbip_event_add(&vdev->ud, VDEV_EVENT_ERROR_TCP);
-   return -1;
+   err = -EPIPE;
+   goto err_tx;
}
  
+		kfree(iov);

kfree(iso_buffer);
usbip_dbg_vhci_tx("send txdata\n");
  
@@ -119,6 +151,13 @@ static int vhci_send_cmd_submit(struct vhci_device *vdev)

}
  
  	return total_size;

+
+err_tx:
+   kfree(iso_buffer);
+err_iso_buffer:
+   kfree(iov);
+
+   return err;
  }
  
  static struct vhci_unlink *dequeue_from_unlink_tx(struct vhci_device *vdev)




Thanks for doing this work.

Reviewed-by: Shuah Khan 

thanks,
-- Shuah

Re: [PATCH] USB: usbip: delete README file

[shuah]

On 1/17/19 1:23 AM, Greg Kroah-Hartman wrote:

The README file ni the drivers/usb/usbip/ directory is not needed
anymore, so just delete it.

Cc: Valentina Manea 
Cc: Shuah Khan 
Signed-off-by: Greg Kroah-Hartman 
---
  drivers/usb/usbip/README | 7 ---
  1 file changed, 7 deletions(-)
  delete mode 100644 drivers/usb/usbip/README

diff --git a/drivers/usb/usbip/README b/drivers/usb/usbip/README
deleted file mode 100644
index 41a2cf2e77a6..
--- a/drivers/usb/usbip/README
+++ /dev/null
@@ -1,7 +0,0 @@
-TODO:
-   - more discussion about the protocol
-   - testing
-   - review of the userspace interface
-   - document the protocol
-
-Please send patches for this code to Greg Kroah-Hartman 



Thanks for the patch.

Acked-by: Shuah Khan 

thanks,
-- Shuah

Re: [PATCH] usbip: Fix vhci_urb_enqueue() URB null transfer buffer error path

[shuah]

On 1/19/19 9:58 AM, Sergei Shtylyov wrote:

Hello!

On 01/19/2019 12:29 AM, Shuah Khan wrote:


From: Shuah Khan 

Fix vhci_urb_enqueue() to print error and return error instead of
failing with WARN_ON.


It's BUG_ON().


Thanks. I will fix it.

-- Shuah

Re: [PATCH] usbip: Fix vep_free_request() null pointer checks on input args

[shuah]

On 1/19/19 1:17 AM, Greg KH wrote:

On Fri, Jan 18, 2019 at 02:29:30PM -0700, Shuah Khan wrote:

From: Shuah Khan 

Fix vep_free_request() to return when usb_ep and usb_request are null
instead of calling WARN_ON.

Signed-off-by: Shuah Khan 
---
  drivers/usb/usbip/vudc_dev.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/usbip/vudc_dev.c b/drivers/usb/usbip/vudc_dev.c
index 1634d8698e15..bfc8218e3fb6 100644
--- a/drivers/usb/usbip/vudc_dev.c
+++ b/drivers/usb/usbip/vudc_dev.c
@@ -297,7 +297,7 @@ static void vep_free_request(struct usb_ep *_ep, struct 
usb_request *_req)
  {
struct vrequest *req;
  
-	if (WARN_ON(!_ep || !_req))

+   if (!_ep || !_req)


It's impossible for _ep to be NULL in this callback (see
usb_ep_free_request() for where this is called from to prove that), so I
don't think you need to check that.  It's almost impossible for _req to
be NULL, so you might as well leave that check in.



Yes. ep can never be null here in vep_free_request(). I will leave
this alone.

thanks,
-- Shuah

Re: [PATCH] usbip: Fix vep_free_request() null pointer checks on input args

[shuah]

On 1/25/19 1:02 AM, Greg KH wrote:

On Tue, Jan 22, 2019 at 04:05:28PM -0700, shuah wrote:

On 1/19/19 1:17 AM, Greg KH wrote:

On Fri, Jan 18, 2019 at 02:29:30PM -0700, Shuah Khan wrote:

From: Shuah Khan 

Fix vep_free_request() to return when usb_ep and usb_request are null
instead of calling WARN_ON.

Signed-off-by: Shuah Khan 
---
   drivers/usb/usbip/vudc_dev.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/usbip/vudc_dev.c b/drivers/usb/usbip/vudc_dev.c
index 1634d8698e15..bfc8218e3fb6 100644
--- a/drivers/usb/usbip/vudc_dev.c
+++ b/drivers/usb/usbip/vudc_dev.c
@@ -297,7 +297,7 @@ static void vep_free_request(struct usb_ep *_ep, struct 
usb_request *_req)
   {
struct vrequest *req;
-   if (WARN_ON(!_ep || !_req))
+   if (!_ep || !_req)


It's impossible for _ep to be NULL in this callback (see
usb_ep_free_request() for where this is called from to prove that), so I
don't think you need to check that.  It's almost impossible for _req to
be NULL, so you might as well leave that check in.



Yes. ep can never be null here in vep_free_request(). I will leave
this alone.


You can drop the !_ep check at the least, no need to check something
that is impossible to hit :)



Thanks. I will do that.

-- Shuah

Re: [PATCH v5 1/2] usbip: Skip DMA mapping and unmapping for urb at vhci

[shuah]

On 8/8/19 10:18 AM, shuah wrote:

On 8/8/19 9:54 AM, Suwan Kim wrote:

vhci doesn’t do DMA for remote device. Actually, the real DMA
operation is done by network card driver. vhci just passes virtual
address of the buffer to the network stack, so vhci doesn’t use and
need dma address of the buffer of the URB.

But HCD provides DMA mapping and unmapping function by default.
Moreover, it causes unnecessary DMA mapping and unmapping which
will be done again at the NIC driver and it wastes CPU cycles.
So, implement map_urb_for_dma and unmap_urb_for_dma function for
vhci in order to skip the DMA mapping and unmapping procedure.

When it comes to supporting SG for vhci, it is useful to use native
SG list (urb->num_sgs) instead of mapped SG list because DMA mapping
fnuction can adjust the number of SG list (urb->num_mapped_sgs).
And vhci_map_urb_for_dma() prevents isoc pipe from using SG as
hcd_map_urb_for_dma() does.

Signed-off-by: Suwan Kim 
---
v4 - v5
- Replace pr_err() with dev_err() in the error path.

v3 - v4
- Replace WARN_ON() with pr_err() in the error path.

v2 - v3
- Move setting URB_DMA_MAP_SG flag to the patch 2.
- Prevent isoc pipe from using SG buffer.

v1 - v2
- Add setting URB_DMA_MAP_SG flag in urb->transfer_flags to tell
stub driver to use SG buffer.
---
  drivers/usb/usbip/vhci_hcd.c | 19 +++
  1 file changed, 19 insertions(+)

diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
index 000ab7225717..ea82b932a2f9 100644
--- a/drivers/usb/usbip/vhci_hcd.c
+++ b/drivers/usb/usbip/vhci_hcd.c
@@ -1288,6 +1288,22 @@ static int vhci_free_streams(struct usb_hcd 
*hcd, struct usb_device *udev,

  return 0;
  }
+static int vhci_map_urb_for_dma(struct usb_hcd *hcd, struct urb *urb,
+    gfp_t mem_flags)
+{
+    if (usb_endpoint_xfer_isoc(&urb->ep->desc) && urb->num_sgs) {
+    dev_err(&urb->dev->dev, "SG is not supported for isochronous 
transfer\n");

+    return -EINVAL;
+    }
+
+    return 0;
+}
+
+static void vhci_unmap_urb_for_dma(struct usb_hcd *hcd, struct urb *urb)
+{
+    dev_dbg(hcd->self.controller, "vhci does not unmap urb for dma\n");
+}
+
  static const struct hc_driver vhci_hc_driver = {
  .description    = driver_name,
  .product_desc    = driver_desc,
@@ -1304,6 +1320,9 @@ static const struct hc_driver vhci_hc_driver = {
  .get_frame_number = vhci_get_frame_number,
+    .map_urb_for_dma = vhci_map_urb_for_dma,
+    .unmap_urb_for_dma = vhci_unmap_urb_for_dma,
+
  .hub_status_data = vhci_hub_status,
  .hub_control    = vhci_hub_control,
  .bus_suspend    = vhci_bus_suspend,



Looks good to me.

Reviewed-by: Shuah Khan 



Greg!

Please pick this one up.

Acked-by: Shuah Khan 

thanks,
-- Shuah

Re: [PATCH v5 2/2] usbip: Implement SG support to vhci-hcd and stub driver

[shuah]

On 8/8/19 10:21 AM, shuah wrote:

On 8/8/19 9:54 AM, Suwan Kim wrote:

There are bugs on vhci with usb 3.0 storage device. In USB, each SG
list entry buffer should be divisible by the bulk max packet size.
But with native SG support, this problem doesn't matter because the
SG buffer is treated as contiguous buffer. But without native SG
support, USB storage driver breaks SG list into several URBs and the
error occurs because of a buffer size of URB that cannot be divided
by the bulk max packet size. The error situation is as follows.

When USB Storage driver requests 31.5 KB data and has SG list which
has 3584 bytes buffer followed by 7 4096 bytes buffer for some
reason. USB Storage driver splits this SG list into several URBs
because VHCI doesn't support SG and sends them separately. So the
first URB buffer size is 3584 bytes. When receiving data from device,
USB 3.0 device sends data packet of 1024 bytes size because the max
packet size of BULK pipe is 1024 bytes. So device sends 4096 bytes.
But the first URB buffer has only 3584 bytes buffer size. So host
controller terminates the transfer even though there is more data to
receive. So, vhci needs to support SG transfer to prevent this error.

In this patch, vhci supports SG regardless of whether the server's
host controller supports SG or not, because stub driver splits SG
list into several URBs if the server's host controller doesn't
support SG.

To support SG, vhci_map_urb_for_dma() sets URB_DMA_MAP_SG flag in
urb->transfer_flags if URB has SG list and this flag will tell stub
driver to use SG list.

vhci sends each SG list entry to stub driver. Then, stub driver sees
the total length of the buffer and allocates SG table and pages
according to the total buffer length calling sgl_alloc(). After stub
driver receives completed URB, it again sends each SG list entry to
vhci.

If the server's host controller doesn't support SG, stub driver
breaks a single SG request into several URBs and submits them to
the server's host controller. When all the split URBs are completed,
stub driver reassembles the URBs into a single return command and
sends it to vhci.

Moreover, in the situation where vhci supports SG, but stub driver
does not, or vice versa, usbip works normally. Because there is no
protocol modification, there is no problem in communication between
server and client even if the one has a kernel without SG support.

In the case of vhci supports SG and stub driver doesn't, because
vhci sends only the total length of the buffer to stub driver as
it did before the patch applied, stub driver only needs to allocate
the required length of buffers using only kmalloc() regardless of
whether vhci supports SG or not. But stub driver has to allocate
buffer with kmalloc() as much as the total length of SG buffer which
is quite huge when vhci sends SG request, so it has overhead in
buffer allocation in this situation.

If stub driver needs to send data buffer to vhci because of IN pipe,
stub driver also sends only total length of buffer as metadata and
then sends real data as vhci does. Then vhci receive data from stub
driver and store it to the corresponding buffer of SG list entry.

And for the case of stub driver supports SG and vhci doesn't, since
the USB storage driver checks that vhci doesn't support SG and sends
the request to stub driver by splitting the SG list into multiple
URBs, stub driver allocates a buffer for each URB with kmalloc() as
it did before this patch.

* Test environment

Test uses two difference machines and two different kernel version
to make mismatch situation between the client and the server where
vhci supports SG, but stub driver does not, or vice versa. All tests
are conducted in both full SG support that both vhci and stub support
SG and half SG support that is the mismatch situation.

  - Test kernel version
 - 5.2-rc6 with SG support
 - 5.1.20-200.fc29.x86_64 without SG support

* SG support test

  - Test devices
 - Super-speed storage device - SanDisk Ultra USB 3.0
 - High-speed storage device - SMI corporation USB 2.0 flash drive

  - Test description

Test read and write operation of mass storage device that uses the
BULK transfer. In test, the client reads and writes files whose size
is over 1G and it works normally.

* Regression test

  - Test devices
 - Super-speed device - Logitech Brio webcam
 - High-speed device - Logitech C920 HD Pro webcam
 - Full-speed device - Logitech bluetooth mouse
 - Britz BR-Orion speaker
 - Low-speed device - Logitech wired mouse

  - Test description

Moving and click test for mouse. To test the webcam, use gnome-cheese.
To test the speaker, play music and video on the client. All works
normally.

* VUDC compatibility test

VUDC also works well with this patch. Tests are done with two USB
gadget created by CONFIGFS USB gadget. Both use the BULK pipe.

 1. Serial gadg

Re: [PATCH v5 0/2] usbip: Implement SG support

[shuah]

On 8/15/19 7:23 AM, Greg KH wrote:

On Wed, Aug 14, 2019 at 06:19:51AM -0700, Christoph Hellwig wrote:

FYI, I think my

"usb: add a HCD_DMA flag instead of guestimating DMA capabilities"

is the proper core fix for what your patch 1 works around, as the USB
core should not assume DMA capabilities based on the presence of a DMA
mask.


I agree.  Let's wait for Christoph's series to be applied before taking
this one.



Great. Thanks you both looking at these. Makes sense.

thanks,
-- Shuah

Re: [PATCH v6] usbip: Implement SG support to vhci-hcd and stub driver

[shuah]

descriptor *iso_buffer = NULL;
struct vhci_priv *priv = NULL;
+   struct scatterlist *sg;
  
  	struct msghdr msg;

-   struct kvec iov[3];
+   struct kvec *iov;
size_t txsize;
  
  	size_t total_size = 0;

+   int iovnum;
+   int err = -ENOMEM;
+   int i;
  
  	while ((priv = dequeue_from_priv_tx(vdev)) != NULL) {

int ret;
struct urb *urb = priv->urb;
struct usbip_header pdu_header;
-   struct usbip_iso_packet_descriptor *iso_buffer = NULL;
  
  		txsize = 0;

memset(&pdu_header, 0, sizeof(pdu_header));
@@ -72,18 +77,45 @@ static int vhci_send_cmd_submit(struct vhci_device *vdev)
usbip_dbg_vhci_tx("setup txdata urb seqnum %lu\n",
  priv->seqnum);
  
+		if (urb->num_sgs && usb_pipeout(urb->pipe))

+   iovnum = 2 + urb->num_sgs;
+   else
+   iovnum = 3;
+
+   if (urb->num_sgs)
+   urb->transfer_flags |= URB_DMA_MAP_SG;
+


Move this down after the kcalloc()


+   iov = kcalloc(iovnum, sizeof(*iov), GFP_KERNEL);
+   if (!iov) {
+   usbip_event_add(&vdev->ud, SDEV_EVENT_ERROR_MALLOC);
+   return -ENOMEM;
+   }
+
/* 1. setup usbip_header */
setup_cmd_submit_pdu(&pdu_header, urb);
usbip_header_correct_endian(&pdu_header, 1);
+   iovnum = 0;
  
-		iov[0].iov_base = &pdu_header;

-   iov[0].iov_len  = sizeof(pdu_header);
+   iov[iovnum].iov_base = &pdu_header;
+   iov[iovnum].iov_len  = sizeof(pdu_header);
txsize += sizeof(pdu_header);
+   iovnum++;
  
  		/* 2. setup transfer buffer */

if (!usb_pipein(urb->pipe) && urb->transfer_buffer_length > 0) {
-   iov[1].iov_base = urb->transfer_buffer;
-   iov[1].iov_len  = urb->transfer_buffer_length;
+   if (urb->num_sgs &&
+ !usb_endpoint_xfer_isoc(&urb->ep->desc)) {
+   for_each_sg(urb->sg, sg, urb->num_sgs, i) {
+   iov[iovnum].iov_base = sg_virt(sg);
+   iov[iovnum].iov_len = sg->length;
+   iovnum++;
+   }
+   } else {
+   iov[iovnum].iov_base = urb->transfer_buffer;
+   iov[iovnum].iov_len  =
+   urb->transfer_buffer_length;
+   iovnum++;
+   }
txsize += urb->transfer_buffer_length;
}
  
@@ -95,23 +127,26 @@ static int vhci_send_cmd_submit(struct vhci_device *vdev)

    if (!iso_buffer) {
usbip_event_add(&vdev->ud,
SDEV_EVENT_ERROR_MALLOC);
-   return -1;
+   goto err_iso_buffer;
}
  
-			iov[2].iov_base = iso_buffer;

-   iov[2].iov_len  = len;
+   iov[iovnum].iov_base = iso_buffer;
+   iov[iovnum].iov_len  = len;
+   iovnum++;
txsize += len;
}
  
-		ret = kernel_sendmsg(vdev->ud.tcp_socket, &msg, iov, 3, txsize);

+   ret = kernel_sendmsg(vdev->ud.tcp_socket, &msg, iov, iovnum,
+txsize);
if (ret != txsize) {
pr_err("sendmsg failed!, ret=%d for %zd\n", ret,
   txsize);
-   kfree(iso_buffer);
usbip_event_add(&vdev->ud, VDEV_EVENT_ERROR_TCP);
-   return -1;
+   err = -EPIPE;
+   goto err_tx;
}
  
+		kfree(iov);

kfree(iso_buffer);
usbip_dbg_vhci_tx("send txdata\n");
  
@@ -119,6 +154,13 @@ static int vhci_send_cmd_submit(struct vhci_device *vdev)

}
  
  	return total_size;

+
+err_tx:
+   kfree(iso_buffer);
+err_iso_buffer:
+   kfree(iov);
+
+   return err;
  }
  
  static struct vhci_unlink *dequeue_from_unlink_tx(struct vhci_device *vdev)




thanks,
-- Shuah

Re: [PATCH v8] usbip: Implement SG support to vhci-hcd and stub driver

[shuah]

ll with this patch. Tests are done with two USB
gadget created by CONFIGFS USB gadget. Both use the BULK pipe.

 1. Serial gadget
 2. Mass storage gadget

  - Serial gadget test

Serial gadget on the host sends and receives data using cat command
on the /dev/ttyGS. The client uses minicom to communicate with
the serial gadget.

  - Mass storage gadget test

After connecting the gadget with vhci, use "dd" to test read and
write operation on the client side.

Read  - dd if=/dev/sd iflag=direct of=/dev/null bs=1G count=1
Write - dd if= iflag=direct of=/dev/sd bs=1G count=1

Signed-off-by: Suwan Kim 
---
v7 - v8
- Modify the commit log which describes URB_DMA_MAP_SG flag setting.

v6 - v7
- Move the flag set in setup_cmd_submit_pdu() of vhci_tx.c and
   manipulate usbip header flag instead of urb->transfer_flags.

- Remove clearing URB_DMA_MAP_SG flag in vhci_rx.


setup_cmd_submit_pdu() is just for pdu and shouldn't be concerned
about the urb.

Please keep the URB_DMA_MAP_SG setting in urb->transfer_flags.
That mean you are restoring v6 code change with the commit log
updates from v8.

This flag belongs with urb and not the cmd.submit. Having it in
urb also helps when we debug and dump the urb from usbip_dump_urb()

thanks,
-- Shuah

Re: [PATCH v8] usbip: Implement SG support to vhci-hcd and stub driver

[shuah]

On 8/27/19 8:38 AM, shuah wrote:

On 8/26/19 11:23 AM, Suwan Kim wrote:

There are bugs on vhci with usb 3.0 storage device. In USB, each SG
list entry buffer should be divisible by the bulk max packet size.
But with native SG support, this problem doesn't matter because the
SG buffer is treated as contiguous buffer. But without native SG
support, USB storage driver breaks SG list into several URBs and the
error occurs because of a buffer size of URB that cannot be divided
by the bulk max packet size. The error situation is as follows.

When USB Storage driver requests 31.5 KB data and has SG list which
has 3584 bytes buffer followed by 7 4096 bytes buffer for some
reason. USB Storage driver splits this SG list into several URBs
because VHCI doesn't support SG and sends them separately. So the
first URB buffer size is 3584 bytes. When receiving data from device,
USB 3.0 device sends data packet of 1024 bytes size because the max
packet size of BULK pipe is 1024 bytes. So device sends 4096 bytes.
But the first URB buffer has only 3584 bytes buffer size. So host
controller terminates the transfer even though there is more data to
receive. So, vhci needs to support SG transfer to prevent this error.

In this patch, vhci supports SG regardless of whether the server's
host controller supports SG or not, because stub driver splits SG
list into several URBs if the server's host controller doesn't
support SG.

To support SG, vhci sets URB_DMA_MAP_SG flag in transfer_flags of
usbip header if URB has SG list and this flag will tell stub driver
to use SG list.

vhci sends each SG list entry to stub driver. Then, stub driver sees
the total length of the buffer and allocates SG table and pages
according to the total buffer length calling sgl_alloc(). After stub
driver receives completed URB, it again sends each SG list entry to
vhci.

If the server's host controller doesn't support SG, stub driver
breaks a single SG request into several URBs and submits them to
the server's host controller. When all the split URBs are completed,
stub driver reassembles the URBs into a single return command and
sends it to vhci.

Moreover, in the situation where vhci supports SG, but stub driver
does not, or vice versa, usbip works normally. Because there is no
protocol modification, there is no problem in communication between
server and client even if the one has a kernel without SG support.

In the case of vhci supports SG and stub driver doesn't, because
vhci sends only the total length of the buffer to stub driver as
it did before the patch applied, stub driver only needs to allocate
the required length of buffers using only kmalloc() regardless of
whether vhci supports SG or not. But stub driver has to allocate
buffer with kmalloc() as much as the total length of SG buffer which
is quite huge when vhci sends SG request, so it has overhead in
buffer allocation in this situation.

If stub driver needs to send data buffer to vhci because of IN pipe,
stub driver also sends only total length of buffer as metadata and
then sends real data as vhci does. Then vhci receive data from stub
driver and store it to the corresponding buffer of SG list entry.

And for the case of stub driver supports SG and vhci doesn't, since
the USB storage driver checks that vhci doesn't support SG and sends
the request to stub driver by splitting the SG list into multiple
URBs, stub driver allocates a buffer for each URB with kmalloc() as
it did before this patch.

* Test environment

Test uses two difference machines and two different kernel version
to make mismatch situation between the client and the server where
vhci supports SG, but stub driver does not, or vice versa. All tests
are conducted in both full SG support that both vhci and stub support
SG and half SG support that is the mismatch situation. Test kernel
version is 5.3-rc6 with commit "usb: add a HCD_DMA flag instead of
guestimating DMA capabilities" to avoid unnecessary DMA mapping and
unmapping.

  - Test kernel version
 - 5.3-rc6 with SG support
 - 5.1.20-200.fc29.x86_64 without SG support

* SG support test

  - Test devices
 - Super-speed storage device - SanDisk Ultra USB 3.0
 - High-speed storage device - SMI corporation USB 2.0 flash drive

  - Test description

Test read and write operation of mass storage device that uses the
BULK transfer. In test, the client reads and writes files whose size
is over 1G and it works normally.

* Regression test

  - Test devices
 - Super-speed device - Logitech Brio webcam
 - High-speed device  - Logitech C920 HD Pro webcam
 - Full-speed device  - Logitech bluetooth mouse
  - Britz BR-Orion speaker
 - Low-speed device   - Logitech wired mouse

  - Test description

Moving and click test for mouse. To test the webcam, use gnome-cheese.
To test the speaker, play music and video on the client. All works
normally.

* VUDC compatibilit

Re: [PATCH] usbip: tools: Fix read_usb_vudc_device() error path handling

[shuah]

On 10/15/19 7:14 AM, GwanYeong Kim wrote:

cannot be less than 0 - fread() returns 0 on error.

Signed-off-by: GwanYeong Kim 
---
  tools/usb/usbip/libsrc/usbip_device_driver.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/usb/usbip/libsrc/usbip_device_driver.c 
b/tools/usb/usbip/libsrc/usbip_device_driver.c
index 051d7d3f443b..49760b98aabc 100644
--- a/tools/usb/usbip/libsrc/usbip_device_driver.c
+++ b/tools/usb/usbip/libsrc/usbip_device_driver.c
@@ -79,7 +79,7 @@ int read_usb_vudc_device(struct udev_device *sdev, struct 
usbip_usb_device *dev)
if (!fd)
return -1;
ret = fread((char *) &descr, sizeof(descr), 1, fd);
-   if (ret < 0) > +  if (ret != sizeof(descr))


Are you sure this check is correct? fread() returns the number
of elements read, # elements = 1  in this case.

fread() returns 0 when size or # of elements is 0 and in other
error cases it will return < # of elements. I would think you
want to check ret != 1 here.

thanks,
-- Shuah

Re: [PATCH v2] usbip: tools: Fix read_usb_vudc_device() error path handling

[shuah]

On 10/16/19 8:25 PM, GwanYeong Kim wrote:

cannot be less than 0 - fread() returns 0 on error.



This isn't really accurate right. fread() doesn't always
return 0 in error. It could return < number of elements
and set errno.

Please make changes to reflect that.


Signed-off-by: GwanYeong Kim 
---
  tools/usb/usbip/libsrc/usbip_device_driver.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/usb/usbip/libsrc/usbip_device_driver.c 
b/tools/usb/usbip/libsrc/usbip_device_driver.c
index 051d7d3f443b..959bb29d0477 100644
--- a/tools/usb/usbip/libsrc/usbip_device_driver.c
+++ b/tools/usb/usbip/libsrc/usbip_device_driver.c
@@ -69,7 +69,7 @@ int read_usb_vudc_device(struct udev_device *sdev, struct 
usbip_usb_device *dev)
FILE *fd = NULL;
struct udev_device *plat;
const char *speed;
-   int ret = 0;
+   size_t ret = 0;


You don't need to initialize this.

  
  	plat = udev_device_get_parent(sdev);

path = udev_device_get_syspath(plat);
@@ -79,7 +79,7 @@ int read_usb_vudc_device(struct udev_device *sdev, struct 
usbip_usb_device *dev)
if (!fd)
return -1;
ret = fread((char *) &descr, sizeof(descr), 1, fd);
-   if (ret < 0)
+   if (ret != 1)


Why not print error message?


goto err;
fclose(fd);
  



thanks,
-- Shuah

Re: [PATCH v2] usbip: tools: Fix read_usb_vudc_device() error path handling

[shuah]

On 10/16/19 11:26 PM, GwanYeong Kim wrote:

On Wed, 16 Oct 2019 20:33:39 -0600
shuah  wrote:


On 10/16/19 8:25 PM, GwanYeong Kim wrote:

cannot be less than 0 - fread() returns 0 on error.



This isn't really accurate right. fread() doesn't always
return 0 in error. It could return < number of elements
and set errno.

Please make changes to reflect that.


Will reflect this.




Signed-off-by: GwanYeong Kim 
---
   tools/usb/usbip/libsrc/usbip_device_driver.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/usb/usbip/libsrc/usbip_device_driver.c
b/tools/usb/usbip/libsrc/usbip_device_driver.c index
051d7d3f443b..959bb29d0477 100644 ---
a/tools/usb/usbip/libsrc/usbip_device_driver.c +++
b/tools/usb/usbip/libsrc/usbip_device_driver.c @@ -69,7 +69,7 @@
int read_usb_vudc_device(struct udev_device *sdev, struct
usbip_usb_device *dev) FILE *fd = NULL; struct udev_device *plat;
const char *speed;
-   int ret = 0;
+   size_t ret = 0;


You don't need to initialize this.


Exactly, because "ret" variable receives a "fread()" return value,



   
   	plat = udev_device_get_parent(sdev);

path = udev_device_get_syspath(plat);
@@ -79,7 +79,7 @@ int read_usb_vudc_device(struct udev_device
*sdev, struct usbip_usb_device *dev) if (!fd)
return -1;
ret = fread((char *) &descr, sizeof(descr), 1, fd);
-   if (ret < 0)
+   if (ret != 1)


Why not print error message?



Sorry, I'll add a message.

How about this?

err("Cannot read vudc device descr file");


Using strerror() with errno gives you more information. Add that
to them essage you proposed.

thanks,
-- Shuah

Re: [PATCH v3] usbip: tools: Fix read_usb_vudc_device() error path handling

[shuah]

On 10/17/19 9:22 PM, GwanYeong Kim wrote:

This isn't really accurate right. fread() doesn't always
return 0 in error. It could return < number of elements
and set errno.

Signed-off-by: GwanYeong Kim 
---
  tools/usb/usbip/libsrc/usbip_device_driver.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/usb/usbip/libsrc/usbip_device_driver.c 
b/tools/usb/usbip/libsrc/usbip_device_driver.c
index 051d7d3f443b..927a151fa9aa 100644
--- a/tools/usb/usbip/libsrc/usbip_device_driver.c
+++ b/tools/usb/usbip/libsrc/usbip_device_driver.c
@@ -69,7 +69,7 @@ int read_usb_vudc_device(struct udev_device *sdev, struct 
usbip_usb_device *dev)
FILE *fd = NULL;
struct udev_device *plat;
const char *speed;
-   int ret = 0;
+   size_t ret;
  
  	plat = udev_device_get_parent(sdev);

path = udev_device_get_syspath(plat);
@@ -79,8 +79,10 @@ int read_usb_vudc_device(struct udev_device *sdev, struct 
usbip_usb_device *dev)
if (!fd)
return -1;
ret = fread((char *) &descr, sizeof(descr), 1, fd);
-   if (ret < 0)
+   if (ret != 1) {
+   err("Cannot read vudc device descr file: %s", strerror(errno));
goto err;
+   }
fclose(fd);
  
  	copy_descr_attr(dev, &descr, bDeviceClass);




Looks good.

Acked-by: Shuah Khan 

thanks,
-- Shuah

Re: [PATCH v13 00/10] usbip: exporting devices

[Shuah Khan]

On 11/23/2016 02:30 AM, Greg KH wrote:
> On Tue, Nov 22, 2016 at 03:48:09PM +0900, Nobuo Iwata wrote:
>> Dear all,
>>
>> This series of patches adds exporting device operation to USB/IP.
> 
> I would _love_ it if some of the people who are listed as MAINTAINERS of
> this code could actually review these patch series.  I don't think I've
> seen that happen yet, which isn't good...
> 
> {hint hint hint}
> 
> greg k-h
> 

I started reviewing the patch series. Didn't get a chance to go
through all of them yet.

thanks,
-- Shuah

-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America(Silicon Valley)
shuah...@samsung.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v13 00/10] usbip: exporting devices

[Shuah Khan]

On 11/21/2016 11:48 PM, Nobuo Iwata wrote:
> Dear all,
> 
> This series of patches adds exporting device operation to USB/IP.
> 
> NOTE:
> This patch set modifies only userspace codes in tools/usb/usbip.
> 
> 1. Goal
> 
> 1-1) To give flexibility to direction of connection
> Using USB/IP in internet, there can be two cases.
> a) an application is inside firewall and devices are outside.
> b) devices are inside firewall and an application is inside.
> In case-a, import works because the connection is from inside.
> In case-b, import doesn't works because the connection is from outside. 
> Connection from device side is needed. This patch set adds the 
> direction of connection establishment.
> 

Can you elaborate on the use-case a bit more? What does it mean
to "Connection from device side is needed"?

I would like to see server side and client side operations clearly.
It would help me understand the use-case you are trying to add.

I do have some concerns about security on client side. User sits
on the client side and it should be a pull from client side as
opposed to push from server side.

It sounds like this patch series adds push from server side.

thanks,
-- Shuah

> NOTE:
> Directions of URBs requests and responses are not changed. Only 
> direction of connection establishment initiated with usbip command is 
> added to exsiting one.
> 
> 1-2) To improve usability of operations
> When two Linux machines are in a small distance, it's OK to bind (makes 
> importable) at device side machine and attach (import) at application 
> side.
> If application is as cloud service or in blade server, it's not 
> practical to attach from application side. It's useful to connect 
> (export) from device side. This patch set adds the new operation to 
> connect from device side.
> 
> 2. What's 'exporting' device
> 
> Exporting devices is not new. The request and response PDU have already 
> been defined in tools/usbip/usbip/src/usbip_network.h.
> #/* Export a USB device to a remote host. */
> #define OP_EXPORT   0x06
> #define OP_REQ_EXPORT   (OP_REQUEST | OP_EXPORT)
> #define OP_REP_EXPORT   (OP_REPLY   | OP_EXPORT)
> # struct op_export_request
> # struct op_export_reply
> #/* un-Export a USB device from a remote host. */
> #define OP_UNEXPORT 0x07
> #define OP_REQ_UNEXPORT (OP_REQUEST | OP_UNEXPORT)
> #define OP_REP_UNEXPORT (OP_REPLY   | OP_UNEXPORT)
> # struct op_unexport_request
> # struct op_unexport_reply 
> 
> But they have not been used yet. This series adds new operations: 
> 'connect' and 'disconnect' using these PDUs.
> 
> EXISTING) - invites devices from application(vhci)-side
>  +--+ +--+
>  device--+ STUB | | application/VHCI |
>  +--+ +--+
>  1) usbipd ... start daemon
>  = = =
>  2) usbip list --local
>  3) usbip bind
> <--- list bound devices ---   4) usbip list --remote
> <--- import a device --   5) usbip attach
>  = = =
>X disconnected 6) usbip detach
>  7) usbip unbind
> 
> NEW) - dedicates devices from device(stb)-side
>  +--+ +--+
>  device--+ STUB | | application/VHCI |
>  +--+ +--+
>   1) usbipa ... start daemon
>  = = =
>  2) usbip list --local
>  3) usbip connect --- export a device -->
>  = = =
>  4) usbip disconnect  --- un-export a device --->
> 
>  Bind and unbind are done in connect and disconnect internally.
> 
> 3. The use cases
> 
> EXISTING)
> 
> In existing way, computers in small distance, having same user account, 
> can be easily managed by a same user. Bind in local machine and attach 
> in remote machine by the user. The devices can be exporsed 
> automatically in the local machine, for example, at strat up. They can 
> be attached from remote.
> 
> When there are distributes linux nodes with USB devices in internet, 
> they are exposed by bind operation at start up, server behind firewall 
> can list and attach the devices.  
>Internet  
>  Exposed   +--+++++
>  +--+  |Linux |+   |Router, ||Service |
> +|device|--|Controller||---|proxy,  ||on  |
> |+--+  +--+|   |firewall||Linux   |
> +--++--+ 

Re: [PATCH v13 01/10] usbip: exporting devices: modifications to network header

[Shuah Khan]

On 11/21/2016 11:48 PM, Nobuo Iwata wrote:
> Modification to export and un-export response in 
> tools/usb/usbip/src/usbip_network.h. It just changes return code type 
> from int to uint32_t as same as other responses.
> 
> Signed-off-by: Nobuo Iwata 

Looks fine to me.

Acked-by: Shuah Khan 

> ---
>  tools/usb/usbip/src/usbip_network.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/usb/usbip/src/usbip_network.h 
> b/tools/usb/usbip/src/usbip_network.h
> index c1e875c..e1ca86a 100644
> --- a/tools/usb/usbip/src/usbip_network.h
> +++ b/tools/usb/usbip/src/usbip_network.h
> @@ -93,7 +93,7 @@ struct op_export_request {
>  } __attribute__((packed));
>  
>  struct op_export_reply {
> - int returncode;
> + uint32_t returncode;
>  } __attribute__((packed));
>  
>  
> @@ -115,7 +115,7 @@ struct op_unexport_request {
>  } __attribute__((packed));
>  
>  struct op_unexport_reply {
> - int returncode;
> + uint32_t returncode;
>  } __attribute__((packed));
>  
>  #define PACK_OP_UNEXPORT_REQUEST(pack, request)  do {\
> 


-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America(Silicon Valley)
shuah...@samsung.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v13 02/10] usbip: exporting devices: modifications to host side libraries

[Shuah Khan]

On 11/21/2016 11:48 PM, Nobuo Iwata wrote:
> usbip_get_device() method in usbip_host_driver_ops was not used. It is 
> modified as a function to find an exported device for new operations 
> 'connect' and 'disconnect'.
> 
> bind and unbind function are exported to reuse by new connect and 
> disconnect operation.

This doesn't look like a simple change to rename and reuse an unused
function. This patch does lot more and is changing the user interface.
Looks like instead of taking an integer value for device lookup, you
are changing it to char *.

Any reason why you have to change the user interface to go to char *busid?

I would like to see a good explanation why this user interface change is
necessary.

thanks,
-- Shuah

> 
> Here, connect and disconnect is NEW-3 and NEW-4 respactively in diagram 
> below.
> 
> EXISTING) - invites devices from application(vhci)-side
>  +--+ +--+
>  device--+ STUB | | application/VHCI |
>  +--+ +--+
>  1) usbipd ... start daemon
>  = = =
>  2) usbip list --local
>  3) usbip bind
> <--- list bound devices ---   4) usbip list --remote
> <--- import a device --   5) usbip attach
>  = = =
>X disconnected 6) usbip detach
>  7) usbip unbind
> 
> NEW) - dedicates devices from device(stb)-side
>  +--+ +--+
>  device--+ STUB | | application/VHCI |
>  +--+ +--+
>   1) usbipa ... start daemon
>  = = =
>  2) usbip list --local
>  3) usbip connect --- export a device -->
>  = = =
>  4) usbip disconnect  --- un-export a device --->
> 
>  Bind and unbind are done in connect and disconnect internally.
> 
> Signed-off-by: Nobuo Iwata 
> ---
>  tools/usb/usbip/libsrc/usbip_host_common.c | 6 ++
>  tools/usb/usbip/libsrc/usbip_host_common.h | 8 
>  tools/usb/usbip/src/usbip.h| 3 +++
>  tools/usb/usbip/src/usbip_bind.c   | 4 ++--
>  tools/usb/usbip/src/usbip_unbind.c | 4 ++--
>  5 files changed, 13 insertions(+), 12 deletions(-)
> 
> diff --git a/tools/usb/usbip/libsrc/usbip_host_common.c 
> b/tools/usb/usbip/libsrc/usbip_host_common.c
> index 9d41522..6a98d6c 100644
> --- a/tools/usb/usbip/libsrc/usbip_host_common.c
> +++ b/tools/usb/usbip/libsrc/usbip_host_common.c
> @@ -256,17 +256,15 @@ int usbip_export_device(struct usbip_exported_device 
> *edev, int sockfd)
>  }
>  
>  struct usbip_exported_device *usbip_generic_get_device(
> - struct usbip_host_driver *hdriver, int num)
> + struct usbip_host_driver *hdriver, char *busid)
>  {
>   struct list_head *i;
>   struct usbip_exported_device *edev;
> - int cnt = 0;
>  
>   list_for_each(i, &hdriver->edev_list) {
>   edev = list_entry(i, struct usbip_exported_device, node);
> - if (num == cnt)
> + if (!strncmp(busid, edev->udev.busid, SYSFS_BUS_ID_SIZE))
>   return edev;
> - cnt++;
>   }
>  
>   return NULL;
> diff --git a/tools/usb/usbip/libsrc/usbip_host_common.h 
> b/tools/usb/usbip/libsrc/usbip_host_common.h
> index a64b803..f9a9def 100644
> --- a/tools/usb/usbip/libsrc/usbip_host_common.h
> +++ b/tools/usb/usbip/libsrc/usbip_host_common.h
> @@ -38,7 +38,7 @@ struct usbip_host_driver_ops {
>   void (*close)(struct usbip_host_driver *hdriver);
>   int (*refresh_device_list)(struct usbip_host_driver *hdriver);
>   struct usbip_exported_device * (*get_device)(
> - struct usbip_host_driver *hdriver, int num);
> + struct usbip_host_driver *hdriver, char *busid);
>  
>   int (*read_device)(struct udev_device *sdev,
>  struct usbip_usb_device *dev);
> @@ -86,11 +86,11 @@ static inline int usbip_refresh_device_list(struct 
> usbip_host_driver *hdriver)
>  }
>  
>  static inline struct usbip_exported_device *
> -usbip_get_device(struct usbip_host_driver *hdriver, int num)
> +usbip_get_device(struct usbip_host_driver *hdriver, char *busid)
>  {
>   if (!hdriver->ops.get_device)
>   return NULL;
> - return hdriver->ops.get_device(hdriver, num);
> + return hdriver->ops.get_device(hdriver, busid);
>  }
>  
>  /* Helper functions for implementing driver backend */
> @@ -99,6 +99,6 @@ void usbip_generic_driver_close(struct usbip

Re: [PATCH v13 03/10] usbip: exporting devices: new connect operation

[Shuah Khan]

st");
> + usbip_driver_close(driver);
> + return -1;
> + }
> +
> + edev = usbip_get_device(driver, busid);
> + if (edev == NULL) {
> + err("find device");
> + usbip_driver_close(driver);
> + return -1;
> + }
> +
> + rc = send_export_device(sockfd, &edev->udev);
> + if (rc < 0) {
> + err("send export");
> + usbip_driver_close(driver);
> + return -1;
> + }
> +
> + rc = usbip_export_device(edev, sockfd);
> + if (rc < 0) {
> + err("export device");
> + usbip_driver_close(driver);
> + return -1;
> + }
> +
> + usbip_driver_close(driver);
> +
> + return 0;
> +}
> +
> +static int connect_device(char *host, char *busid, int bind)
> +{
> + int sockfd;
> + int rc;
> +
> + if (bind) {
> + rc = usbip_bind_device(busid);
> + if (rc) {
> + err("bind");
> + goto err_out;
> + }
> + }
> +
> + sockfd = usbip_net_tcp_connect(host, usbip_port_string);
> + if (sockfd < 0) {
> + err("tcp connect");
> + goto err_unbind_device;
> + }
> +
> + rc = export_device(busid, sockfd);
> + if (rc < 0) {
> + err("export");
> + goto err_close_conn;
> + }
> +
> + close(sockfd);
> +
> + return 0;
> +err_close_conn:
> + close(sockfd);
> +err_unbind_device:
> + if (bind)
> + usbip_unbind_device(busid);
> +err_out:
> + return -1;
> +}
> +
> +int usbip_connect(int argc, char *argv[])
> +{
> + static const struct option opts[] = {
> + { "remote", required_argument, NULL, 'r' },
> + { "busid",  required_argument, NULL, 'b' },
> + { "device", no_argument,   NULL, 'd' },
> + { NULL, 0,  NULL, 0 }
> + };
> + char *host = NULL;
> + char *busid = NULL;
> + int opt;
> + int bind = 1;
> + int ret = -1;
> +
> + for (;;) {
> + opt = getopt_long(argc, argv, "r:b:d", opts, NULL);
> +
> + if (opt == -1)
> + break;
> +
> + switch (opt) {
> + case 'r':
> + host = optarg;
> + break;
> + case 'b':
> + busid = optarg;
> + break;
> + case 'd':
> + driver = &device_driver;
> + bind = 0;
> + break;
> + default:
> + goto err_out;
> + }
> + }
> +
> + if (!host || !busid)
> + goto err_out;
> +
> + ret = connect_device(host, busid, bind);
> + goto out;
> +
> +err_out:
> + usbip_connect_usage();
> +out:
> + return ret;
> +}
> 

thanks,
-- Shuah

-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America(Silicon Valley)
shuah...@samsung.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v13 00/10] usbip: exporting devices

[Shuah Khan]

On 11/23/2016 10:01 PM, fx IWATA NOBUO wrote:
> Hello,
> 
Looks like you removed the text. Let's go back to the goals.
Can we use server and client terminology which is we use in
instead of App and Dev. It makes lot easier to understand.

https://www.kernel.org/doc/readme/tools-usb-usbip-README

>>1. Goal

>>1-1) To give flexibility to direction of connection
>>Using USB/IP in internet, there can be two cases.
>> a) an application is inside firewall and devices are outside.

This is the case Client is behind firewall and server is outside
the firewall. 

>>b) devices are inside firewall and an application is inside.

I am not clear on this. Is Client and server behind different
firewalls?

>>In case-a, import works because the connection is from inside.

> EXISTING)
> APP# usbip attach ---(passed)> DEV# usbipd
> DEV# usbipd (blocked)|| <- APP# usbip attach

So the above doesn't apply to a) and it works?

>> In case-b, import doesn't works because the connection is from outside.

What does this mean? Why is this connection from outside?
 
>> Connection from device side is needed. This patch set adds the 
>> direction of connection establishment.

Is this something that could be solved by opening ports in the firewall?


>> Can you elaborate on the use-case a bit more? What does it mean to
>> "Connection from device side is needed"?
> 
> I'd like to update ending part of use case as following.
> ---
> Firewall, proxy, or router in front of internet usually blocks
> connections from internet regarding all TCP ports. They opens some
> ports, usually HTTP(80) and HTTPS(443), for connection from inside.
> In combination with WebSocket proxy, USB/IP can establish connection
> from inside of the firewall.
> 
> Enterprise/SOHO/Home   Firewall/Proxy/Router   Internet
> 
> EXISTING)
> APP# usbip attach ---(passed)> DEV# usbipd
> DEV# usbipd (blocked)|| <- APP# usbip attach
> 
> NEW)
> DEV# usbip connect --(passed)> DEV# usbipa
> APP# usbipa (blocked)|| <- APP# usbip connect
> 
> Attach operation can invite devices in internet but cannot invite
> devices from internet. On the other hand, connect operation can dedicate
> devices to internet but cannot dedicate devices in internet.

The above isn't very clear. Do you mean to say, client can find devices
exported by a server? When you say Internet how many servers are we
looking at? Random servers or known servers?

Current USB/IP use-cases are:

- Server could export USB devices to virtual machines running on it.
  Access is confined and limited to that one system.
- Server could export USB devices and clients as long as no firewalls
  in between.

In the above two models, user has permissions to use server and client.
In this new proposed model, how does this work? Who sets up the server
to export or push exports to clients. How does server know which clients
to push exports to?

With a feature like this, it is important to understand the use-cases in
detail.

thanks,
-- Shuah

> ---
> 
>> I would like to see server side and client side operations clearly.
>> It would help me understand the use-case you are trying to add.
> 
> It's shown in README and manual page added by patch 9/10 as below.
> 
> app:# insmod usbip-core.ko
> app:# insmod vhci-hcd.ko
> 
> app:# usbipa -D
> - Start usbip daemon.
> 
> dev:# (Physically attach your USB device.)
> 
> dev:# insmod usbip-core.ko
> dev:# insmod usbip-host.ko
> 
> dev:# usbip list -l
> - List driver assignments for USB devices and their busid.
> 
> dev:# usbip connect --remote  --busid 
> - Bind usbip-host.ko to the device with .
> - The USB device of  is connected to remote host!
> 
> dev:# usbip disconnect --remote  --busid 
> - The USB device with  is disconnected from remote host.
> - Unbind usbip-host.ko from the device.
> 
>> I do have some concerns about security on client side. User sits on
>> the client side and it should be a pull from client side as opposed to
>> push from server side.
> 
> Connection level consideration is described in "5. Security
>  Consideration". As you know, USB/IP already has TCP wrapper option.
> With SSL or WebSocket(wss) tunneling proxy, client authentication can
> be applied using the proxies.
> 
> I didn't write device level consideration. It's same as local device
> plug-and-play. I will add description below in cover letter and README.
> 
> ---
> Udev rules can allow only known devices. To identify a device is remote,
> the local b

Re: [PATCH v2] usbip: vudc: fix: Clear already_seen flag also for ep0

[Shuah Khan]

On 12/01/2016 11:14 AM, Krzysztof Opasiak wrote:
> ep_list inside gadget structure doesn't contain ep0.
> It is stored separately in ep0 field.
> 
> This causes an urb hang if gadget driver decides to
> delay setup handling. On host side this is visible as
> timeout error when setting configuration.
> 
> This bug can be reproduced using for example any gadget
> with mass storage function.
> 
> Fixes: abdb29574322 ("usbip: vudc: Add vudc_transfer")
> Signed-off-by: Krzysztof Opasiak 

Greg,

Assuming you want to continue in the same mode as you pulling
in the USB/IP patches with Ack. This patch looks good. Please
pick this up. If you want me to maintain USB/IP tree and send you
pull request, I can do that as well. Whatever works for you.

Acked-by: Shuah Khan 

thanks,
-- Shuah

> ---
> Changes since v1:
> - Use first 12 digits of commit sha in fixes tag
> 
> ---
>  drivers/usb/usbip/vudc_transfer.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/usb/usbip/vudc_transfer.c 
> b/drivers/usb/usbip/vudc_transfer.c
> index aba6bd4..bc0296d 100644
> --- a/drivers/usb/usbip/vudc_transfer.c
> +++ b/drivers/usb/usbip/vudc_transfer.c
> @@ -339,6 +339,8 @@ static void v_timer(unsigned long _vudc)
>   total = timer->frame_limit;
>   }
>  
> + /* We have to clear ep0 flags separately as it's not on the list */
> + udc->ep[0].already_seen = 0;
>   list_for_each_entry(_ep, &udc->gadget.ep_list, ep_list) {
>   ep = to_vep(_ep);
>   ep->already_seen = 0;
> 

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

Re: [PATCH] usbip: vudc: Refactor init_vudc_hw() to be more obvious

[Shuah Khan]

On 12/02/2016 08:27 AM, Krzysztof Opasiak wrote:
> 
> 
> On 12/02/2016 04:15 PM, Shuah Khan wrote:
>> Hi Krzysztof,
>>
>> Thanks for the patch.
>>
>> On 12/01/2016 10:02 AM, Krzysztof Opasiak wrote:
>>> Current implementation of init_vudc_hw() adds ep0 to ep_list
>>> and then after looping through all endpoints removes it from
>>> that list.
>>>
>>> As this may be misleading let's refactor this function
>>> and avoid adding and removing ep0 to eplist and place it
>>> immediately in correct place.
>>
>>>
>>> Signed-off-by: Krzysztof Opasiak 
>>> ---
>>>  drivers/usb/usbip/vudc_dev.c | 38 +-
>>>  1 file changed, 21 insertions(+), 17 deletions(-)
>>>
>>> diff --git a/drivers/usb/usbip/vudc_dev.c b/drivers/usb/usbip/vudc_dev.c
>>> index 7091848..a5ca29b 100644
>>> --- a/drivers/usb/usbip/vudc_dev.c
>>> +++ b/drivers/usb/usbip/vudc_dev.c
>>> @@ -549,30 +549,37 @@ static int init_vudc_hw(struct vudc *udc)
>>> sprintf(ep->name, "ep%d%s", num,
>>> i ? (is_out ? "out" : "in") : "");
>>> ep->ep.name = ep->name;
>>> +
>>> +   ep->ep.ops = &vep_ops;
>>> +
>>> +   ep->halted = ep->wedged = ep->already_seen =
>>> +   ep->setup_stage = 0;
>>
>> Do you need to clear these explicitly. kcalloc() should do it for you.
> 
> Well, that's true. I may remove this if you like.

Please do. It is redundant.

> 
>>
>>> +   usb_ep_set_maxpacket_limit(&ep->ep, ~0);
>>> +   ep->ep.max_streams = 16;
>>> +   ep->gadget = &udc->gadget;
>>> +   ep->desc = NULL;
> 
> Probably the same here.
> 
>>> +   INIT_LIST_HEAD(&ep->req_queue);
>>> +
>>> if (i == 0) {
>>> +   /* ep0 */
>>> ep->ep.caps.type_control = true;
>>> ep->ep.caps.dir_out = true;
>>> ep->ep.caps.dir_in = true;
>>> +
>>> +   udc->gadget.ep0 = &ep->ep;
>>> } else {
>>> +   /* All other eps */
>>> ep->ep.caps.type_iso = true;
>>> ep->ep.caps.type_int = true;
>>> ep->ep.caps.type_bulk = true;
>>> -   }
>>>  
>>> -   if (is_out)
>>> -   ep->ep.caps.dir_out = true;
>>> -   else
>>> -   ep->ep.caps.dir_in = true;
>>> +   if (is_out)
>>> +   ep->ep.caps.dir_out = true;
>>> +   else
>>> +   ep->ep.caps.dir_in = true;
>>
>> You are moving the is_out handling which was common for all eps
>> including ep0 under non-eop0 - is that right?
> 
> Yes it's right. take a look at ep0 inside if(). We set there both
> directions to true so setting one of them once again to true doesn't
> make any sense.
> 

Yeah. I missed that.

thanks,
-- Shuah

>>
>>>  
>>> -   ep->ep.ops = &vep_ops;
>>> -   list_add_tail(&ep->ep.ep_list, &udc->gadget.ep_list);
>>> -   ep->halted = ep->wedged = ep->already_seen =
>>> -   ep->setup_stage = 0;
>>> -   usb_ep_set_maxpacket_limit(&ep->ep, ~0);
>>> -   ep->ep.max_streams = 16;
>>> -   ep->gadget = &udc->gadget;
>>> -   ep->desc = NULL;
>>> -   INIT_LIST_HEAD(&ep->req_queue);
>>> +   list_add_tail(&ep->ep.ep_list, &udc->gadget.ep_list);
>>> +   }
>>> }
>>>  
>>> spin_lock_init(&udc->lock);
>>> @@ -589,9 +596,6 @@ static int init_vudc_hw(struct vudc *udc)
>>> ud->eh_ops.reset= vudc_device_reset;
>>> ud->eh_ops.unusable = vudc_device_unusable;
> 
> 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

Re: [PATCH] usbip: vudc: Refactor init_vudc_hw() to be more obvious

[Shuah Khan]

Hi Krzysztof,

Thanks for the patch.

On 12/01/2016 10:02 AM, Krzysztof Opasiak wrote:
> Current implementation of init_vudc_hw() adds ep0 to ep_list
> and then after looping through all endpoints removes it from
> that list.
> 
> As this may be misleading let's refactor this function
> and avoid adding and removing ep0 to eplist and place it
> immediately in correct place.

> 
> Signed-off-by: Krzysztof Opasiak 
> ---
>  drivers/usb/usbip/vudc_dev.c | 38 +-
>  1 file changed, 21 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/usb/usbip/vudc_dev.c b/drivers/usb/usbip/vudc_dev.c
> index 7091848..a5ca29b 100644
> --- a/drivers/usb/usbip/vudc_dev.c
> +++ b/drivers/usb/usbip/vudc_dev.c
> @@ -549,30 +549,37 @@ static int init_vudc_hw(struct vudc *udc)
>   sprintf(ep->name, "ep%d%s", num,
>   i ? (is_out ? "out" : "in") : "");
>   ep->ep.name = ep->name;
> +
> + ep->ep.ops = &vep_ops;
> +
> + ep->halted = ep->wedged = ep->already_seen =
> + ep->setup_stage = 0;

Do you need to clear these explicitly. kcalloc() should do it for you.

> + usb_ep_set_maxpacket_limit(&ep->ep, ~0);
> + ep->ep.max_streams = 16;
> + ep->gadget = &udc->gadget;
> + ep->desc = NULL;
> + INIT_LIST_HEAD(&ep->req_queue);
> +
>   if (i == 0) {
> + /* ep0 */
>   ep->ep.caps.type_control = true;
>   ep->ep.caps.dir_out = true;
>   ep->ep.caps.dir_in = true;
> +
> + udc->gadget.ep0 = &ep->ep;
>   } else {
> + /* All other eps */
>   ep->ep.caps.type_iso = true;
>   ep->ep.caps.type_int = true;
>   ep->ep.caps.type_bulk = true;
> - }
>  
> - if (is_out)
> - ep->ep.caps.dir_out = true;
> - else
> - ep->ep.caps.dir_in = true;
> + if (is_out)
> + ep->ep.caps.dir_out = true;
> + else
> + ep->ep.caps.dir_in = true;

You are moving the is_out handling which was common for all eps
including ep0 under non-eop0 - is that right?

>  
> - ep->ep.ops = &vep_ops;
> - list_add_tail(&ep->ep.ep_list, &udc->gadget.ep_list);
> - ep->halted = ep->wedged = ep->already_seen =
> - ep->setup_stage = 0;
> - usb_ep_set_maxpacket_limit(&ep->ep, ~0);
> - ep->ep.max_streams = 16;
> - ep->gadget = &udc->gadget;
> - ep->desc = NULL;
> - INIT_LIST_HEAD(&ep->req_queue);
> + list_add_tail(&ep->ep.ep_list, &udc->gadget.ep_list);
> + }
>   }
>  
>   spin_lock_init(&udc->lock);
> @@ -589,9 +596,6 @@ static int init_vudc_hw(struct vudc *udc)
>   ud->eh_ops.reset= vudc_device_reset;
>   ud->eh_ops.unusable = vudc_device_unusable;
>  
> - udc->gadget.ep0 = &udc->ep[0].ep;
> - list_del_init(&udc->ep[0].ep.ep_list);
> -
>   v_init_timer(udc);
>   return 0;
>  
> 

thanks,
-- Shuah

--
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 v13 00/10] usbip: exporting devices

[Shuah Khan]

On 12/02/2016 02:38 AM, fx IWATA NOBUO wrote:
> Hello,
> 
>> I am not clear on this. Is Client and server behind different
>> firewalls?
> 
> No.
> The firewall is in between internet and 
> 
>> So the above doesn't apply to a) and it works?
> 
> Yes.
> 
>> What does this mean? Why is this connection from outside?
> 
> 'usbip attach -r' tries to establish connection.

That doesn't tell me much. I am looking to see in the above where are
the server and client located.
 
> 
>> Is this something that could be solved by opening ports in
>> the firewall?
> Usually, http(80) and https(443) from inside is opened for internet
> Access.

You can open other ports if need be and if you have access to firewall.

> 
> 
>> Can we use server and client terminology which is we use in instead of
>> App and Dev.
> 
> In https://www.kernel.org/doc/readme/tools-usb-usbip-README, I couldn't
> find the definition.
> 
> Do you mean 'server' is a linux machine which has devices
> or linux machine which runs server daemon?
> 
> In existing way, they are same.

Yes. Server is the system with the USB device physically attached
to.

> 
> In new way, they are not.
> The linux machine which has device doesn't have server daemon.

Okay this is a big change and that isn't very clear in any of the
change logs. This is one of my concerns with the patch series.

I want to understand how a different server (system that doesn't
have the USB device physically attached) can be authorized to
export devices that don't belong to it. Something about this model
doesn't sound right. If I have system that sits behind a firewall,
I don't want USB devices visible to anybody and everybody. I don't
see anything in this series that disallows that, short of saying
don't enable USB/IP.

I would like to know why there is a need to change the existing
server-client model. I still would like to see a concrete answer
why the current model doesn't work.

Doesn't making sure port 3240 isn't blocked on the firewall help?

btw: could you please re-run get_maintainers - my email address
in the MAINTAINERS file changed a while ago. I think your email
might be outdated.

thanks,
-- Shuah

> 
> I'd like to confirm the definition to answer rest of questions.
> 
> Best Regards,
> 
> n.iwata
> //
>> -Original Message-
>> From: Shuah Khan [mailto:shuah...@samsung.com]
>> Sent: Friday, December 02, 2016 9:39 AM
>> To: fx IWATA NOBUO; valentina.mane...@gmail.com;
>> gre...@linuxfoundation.org; linux-usb@vger.kernel.org
>> Cc: fx MICHIMURA TADAO; Shuah Khan
>> Subject: Re: [PATCH v13 00/10] usbip: exporting devices
>>
>> On 11/23/2016 10:01 PM, fx IWATA NOBUO wrote:
>>> Hello,
>>>
>> Looks like you removed the text. Let's go back to the goals.
>> Can we use server and client terminology which is we use in instead of App
>> and Dev. It makes lot easier to understand.
>>
>> https://www.kernel.org/doc/readme/tools-usb-usbip-README
>>
>>>> 1. Goal
>>
>>>> 1-1) To give flexibility to direction of connection Using USB/IP in
>>>> internet, there can be two cases.
>>>> a) an application is inside firewall and devices are outside.
>>
>> This is the case Client is behind firewall and server is outside the
>> firewall.
>>
>>>> b) devices are inside firewall and an application is inside.
>>
>> I am not clear on this. Is Client and server behind different firewalls?
>>
>>>> In case-a, import works because the connection is from inside.
>>
>>> EXISTING)
>>> APP# usbip attach ---(passed)> DEV# usbipd
>>> DEV# usbipd (blocked)|| <- APP# usbip attach
>>
>> So the above doesn't apply to a) and it works?
>>
>>>> In case-b, import doesn't works because the connection is from outside.
>>
>> What does this mean? Why is this connection from outside?
>>
>>>> Connection from device side is needed. This patch set adds the
>>>> direction of connection establishment.
>>
>> Is this something that could be solved by opening ports in the firewall?
>>
>>
>>>> Can you elaborate on the use-case a bit more? What does it mean to
>>>> "Connection from device side is needed"?
>>>
>>> I'd like to update ending part of use case as following.
>>> ---
>>> Firewall, proxy, or router in front of internet usually blocks
>>> connections from internet regarding all TCP ports. They open

Re: usb: warning in vhci_hcd_probe/lockdep_init_map

[Shuah Khan]

On 12/02/2016 09:09 AM, Andrey Konovalov wrote:
> On Fri, Dec 2, 2016 at 4:58 PM, Greg Kroah-Hartman
>  wrote:
>> On Fri, Dec 02, 2016 at 03:35:44PM +0100, Andrey Konovalov wrote:
>>> Hi!
>>>
>>> I've got the following error report while booting the kernel with
>>> various usb configs enabled.
>>
>> Any hint as to what these "various usb configs" are?
> 
> Hi Greg,
> 
> Here's my .config:
> https://gist.github.com/xairy/46bc7495dfa7d78701d937af81db0175
> 
> Thanks for looking at this!
> 
>>
>>> On commit 2caceb3294a78c389b462e7e236a4e744a53a474 (Dec 1).

Looks like the above commit at the latest on Linus's master
that is do with

ovl: fix d_real() for stacked fs

Nothing jumped out at me from the log. What's your ability to
bisect the problem?

>>>
>>> gadgetfs: USB Gadget filesystem, version 24 Aug 2004
>>> usbip_core: USB/IP Core v1.0.0
>>> vhci_hcd vhci_hcd: USB/IP Virtual Host Controller
>>> vhci_hcd vhci_hcd: new USB bus registered, assigned bus number 2
>>> BUG: key 88006a7e8d18 not in .data!
>>> [ cut here ]
>>> WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:3131
>>> lockdep_init_map+0x60c/0x770
>>> DEBUG_LOCKS_WARN_ON(1)[1.567044] Modules linked in:
>>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc7+ #58
>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>>>  88006bce6eb8 81f96c8a 0a02 11000d79cd6a
>>>  ed000d79cd62 00046bce6ed8 41b58ab3 8598af40
>>>  81f969f8  41b58ab3 0200
>>> Call Trace:
>>>  [< inline >] __dump_stack lib/dump_stack.c:15
>>>  [] dump_stack+0x292/0x398 lib/dump_stack.c:51
>>>  [] __warn+0x19f/0x1e0 kernel/panic.c:550
>>>  [] warn_slowpath_fmt+0xc5/0x110 kernel/panic.c:565
>>>  [] lockdep_init_map+0x60c/0x770 
>>> kernel/locking/lockdep.c:3131
>>>  [] __kernfs_create_file+0x114/0x2a0 fs/kernfs/file.c:954
>>>  [] sysfs_add_file_mode_ns+0x225/0x520 fs/sysfs/file.c:305
>>>  [< inline >] create_files fs/sysfs/group.c:64
>>>  [] internal_create_group+0x239/0x8f0 fs/sysfs/group.c:134
>>>  [] sysfs_create_group+0x1f/0x30 fs/sysfs/group.c:156
>>>  [] vhci_start+0x5b4/0x7a0 
>>> drivers/usb/usbip/vhci_hcd.c:978
>>>  [] usb_add_hcd+0x8da/0x1c60 drivers/usb/core/hcd.c:2867
>>>  [] vhci_hcd_probe+0x97/0x130 
>>> drivers/usb/usbip/vhci_hcd.c:1103
>>>  [] platform_drv_probe+0x8a/0x180 
>>> drivers/base/platform.c:568
>>>  [< inline >] really_probe drivers/base/dd.c:375
>>>  [] driver_probe_device+0x514/0x980 drivers/base/dd.c:515
>>>  [] __device_attach_driver+0x22b/0x290 
>>> drivers/base/dd.c:610
>>>  [] bus_for_each_drv+0x15c/0x200 drivers/base/bus.c:463
>>>  [] __device_attach+0x266/0x3c0 drivers/base/dd.c:667
>>>  [] device_initial_probe+0x1a/0x20 drivers/base/dd.c:714
>>>  [] bus_probe_device+0x1e6/0x290 drivers/base/bus.c:557
>>>  [] device_add+0xd06/0x1660 drivers/base/core.c:1136
>>>  [] platform_device_add+0x315/0x660 
>>> drivers/base/platform.c:408
>>>  [] platform_device_register_full+0x396/0x4b0 
>>> drivers/base/platform.c:540
>>>  [< inline >] platform_device_register_resndata 
>>> ./include/linux/platform_device.h:111
>>>  [< inline >] platform_device_register_simple 
>>> ./include/linux/platform_device.h:140
>>>  [< inline >] add_platform_device drivers/usb/usbip/vhci_hcd.c:1213
>>>  [] vhci_hcd_init+0x215/0x305 
>>> drivers/usb/usbip/vhci_hcd.c:1254
>>>  [] do_one_initcall+0xf6/0x360 init/main.c:778
>>>  [< inline >] do_initcall_level init/main.c:844
>>>  [< inline >] do_initcalls init/main.c:852
>>>  [< inline >] do_basic_setup init/main.c:870
>>>  [] kernel_init_freeable+0x5c7/0x6a1 init/main.c:1017
>>>  [] kernel_init+0x13/0x180 init/main.c:943
>>>  [] ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:433
>>> ---[ end trace c33c7b202cf3aac8 ]---
>>
>> Odd, I don't see anything strange here.  Shuah, any ideas what is going
>> wrong here?

I will take a look at this. Nothing jumped out at me.

>>
>> thanks,
>>
>> greg k-h
> 
> 

thanks,
-- Shuah

--
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: usb: warning in vhci_hcd_probe/lockdep_init_map

[Shuah Khan]

On 12/02/2016 09:23 AM, Shuah Khan wrote:
> On 12/02/2016 09:09 AM, Andrey Konovalov wrote:
>> On Fri, Dec 2, 2016 at 4:58 PM, Greg Kroah-Hartman
>>  wrote:
>>> On Fri, Dec 02, 2016 at 03:35:44PM +0100, Andrey Konovalov wrote:
>>>> Hi!
>>>>
>>>> I've got the following error report while booting the kernel with
>>>> various usb configs enabled.
>>>
>>> Any hint as to what these "various usb configs" are?
>>
>> Hi Greg,
>>
>> Here's my .config:
>> https://gist.github.com/xairy/46bc7495dfa7d78701d937af81db0175
>>
>> Thanks for looking at this!
>>
>>>
>>>> On commit 2caceb3294a78c389b462e7e236a4e744a53a474 (Dec 1).
> 
> Looks like the above commit at the latest on Linus's master
> that is do with
> 
> ovl: fix d_real() for stacked fs
> 
> Nothing jumped out at me from the log. What's your ability to
> bisect the problem?

Greg/Andrey,

Okay looks like the problem is due to vhci using dynamically allocated
memory for the lock_key. This problem is introduced in

commit: 0775a9cbc694e8c7276688be3bbd2f386167ab54

>From 0775a9cbc694e8c7276688be3bbd2f386167ab54 Mon Sep 17 00:00:00 2001
From: Nobuo Iwata 
Date: Mon, 13 Jun 2016 11:33:40 +0900
Subject: [PATCH] usbip: vhci extension: modifications to vhci driver

which changed the attribute_group from static to dynamically allocated.
I will see if I can fix this without undoing the commit itself

thanks,
-- Shuah

> 
>>>>
>>>> gadgetfs: USB Gadget filesystem, version 24 Aug 2004
>>>> usbip_core: USB/IP Core v1.0.0
>>>> vhci_hcd vhci_hcd: USB/IP Virtual Host Controller
>>>> vhci_hcd vhci_hcd: new USB bus registered, assigned bus number 2
>>>> BUG: key 88006a7e8d18 not in .data!
>>>> [ cut here ]
>>>> WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:3131
>>>> lockdep_init_map+0x60c/0x770
>>>> DEBUG_LOCKS_WARN_ON(1)[1.567044] Modules linked in:
>>>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc7+ #58
>>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 
>>>> 01/01/2011
>>>>  88006bce6eb8 81f96c8a 0a02 11000d79cd6a
>>>>  ed000d79cd62 00046bce6ed8 41b58ab3 8598af40
>>>>  81f969f8  41b58ab3 0200
>>>> Call Trace:
>>>>  [< inline >] __dump_stack lib/dump_stack.c:15
>>>>  [] dump_stack+0x292/0x398 lib/dump_stack.c:51
>>>>  [] __warn+0x19f/0x1e0 kernel/panic.c:550
>>>>  [] warn_slowpath_fmt+0xc5/0x110 kernel/panic.c:565
>>>>  [] lockdep_init_map+0x60c/0x770 
>>>> kernel/locking/lockdep.c:3131
>>>>  [] __kernfs_create_file+0x114/0x2a0 fs/kernfs/file.c:954
>>>>  [] sysfs_add_file_mode_ns+0x225/0x520 
>>>> fs/sysfs/file.c:305
>>>>  [< inline >] create_files fs/sysfs/group.c:64
>>>>  [] internal_create_group+0x239/0x8f0 
>>>> fs/sysfs/group.c:134
>>>>  [] sysfs_create_group+0x1f/0x30 fs/sysfs/group.c:156
>>>>  [] vhci_start+0x5b4/0x7a0 
>>>> drivers/usb/usbip/vhci_hcd.c:978
>>>>  [] usb_add_hcd+0x8da/0x1c60 drivers/usb/core/hcd.c:2867
>>>>  [] vhci_hcd_probe+0x97/0x130 
>>>> drivers/usb/usbip/vhci_hcd.c:1103
>>>>  [] platform_drv_probe+0x8a/0x180 
>>>> drivers/base/platform.c:568
>>>>  [< inline >] really_probe drivers/base/dd.c:375
>>>>  [] driver_probe_device+0x514/0x980 drivers/base/dd.c:515
>>>>  [] __device_attach_driver+0x22b/0x290 
>>>> drivers/base/dd.c:610
>>>>  [] bus_for_each_drv+0x15c/0x200 drivers/base/bus.c:463
>>>>  [] __device_attach+0x266/0x3c0 drivers/base/dd.c:667
>>>>  [] device_initial_probe+0x1a/0x20 drivers/base/dd.c:714
>>>>  [] bus_probe_device+0x1e6/0x290 drivers/base/bus.c:557
>>>>  [] device_add+0xd06/0x1660 drivers/base/core.c:1136
>>>>  [] platform_device_add+0x315/0x660 
>>>> drivers/base/platform.c:408
>>>>  [] platform_device_register_full+0x396/0x4b0 
>>>> drivers/base/platform.c:540
>>>>  [< inline >] platform_device_register_resndata 
>>>> ./include/linux/platform_device.h:111
>>>>  [< inline >] platform_device_register_simple 
>>>> ./include/linux/platform_device.h:140
>>>>  [< inline >] add_platform_device drivers/usb/usbip/vhci_hcd.c:1213
&g

Re: [PATCH v13 09/10] usbip: exporting devices: chage to documenattion

[Shuah Khan]

On 12/02/2016 10:16 AM, Krzysztof Opasiak wrote:
> 
> 
> On 11/22/2016 07:48 AM, Nobuo Iwata wrote:
>> This patch adds function and usage of new connect operation, disconnect 
>> operation and application(vhci)-side daemon to README and manuals.
>>
>> At this point, the wording, 'server' and 'client' are ambiguous in 
>> several place.
>>
>> For existing attach command, the daemon runs device side machine and 
>> attach command is executed in application side machine. Then 'server' 
>> is used for device side and 'client' is for application side.
>>
>> For the new connect command, the daemon runs applications side machine 
>> and connect command is executed in device side machine. Now, 'server' 
>> and 'client' run in different machine than before.
>>
>> To avoid confusion, to represent things to be done in device side node 
>> by both command and daemon, words 'device-side' is used instead of 
>> 'server'. To represent things to be done is application side node by 
>> both command and daemon, 'applicationr-side' are used instead of 
>> 'client'.
>>
> 
> In my humble opinion device side is not a good term.
> 
> Meaning of Device Side means USB gadget so using it here may cause
> misunderstanding. Application side I think is also not a perfect choice.
> 
> Current terminology (server/client) is also imperfect after this series.

Introduce a new word for the intermediate server - In any case I have yet
to see a good argument for why we need this patch series.

> 
> Maybe using a terms from semiconductors world like donor (machine which
> provides the device) and acceptor (machine which accepts the device)
> would be better?
> 
> Best regards,
> 

Please don't introduce new terminology. The current terminology is
correct and makes sense:

Server - system with device physically attached that exports the devices
Client - system that imports the device.

thanks,
-- Shuah

-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America(Silicon Valley)
shuah...@samsung.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] usbip: vudc: Refactor init_vudc_hw() to be more obvious

[Shuah Khan]

On 12/02/2016 10:42 AM, Krzysztof Opasiak wrote:
> Current implementation of init_vudc_hw() adds ep0 to ep_list
> and then after looping through all endpoints removes it from
> that list.
> 
> As this may be misleading let's refactor this function
> and avoid adding and removing ep0 to eplist and place it
> immediately in correct place.
> 
> In addition let's remove redundant 0 assignments as ep
> array is zeroed during allocation.
> 
> Signed-off-by: Krzysztof Opasiak 
> ---
> Changes since v1:
> - remove redundant assignments

Thanks.

Greg,

Here is my ack. Could you please pick this up.

Acked-by: Shuah Khan 

thanks,
-- Shuah

> ---
>  drivers/usb/usbip/vudc_dev.c | 35 ++-
>  1 file changed, 18 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/usb/usbip/vudc_dev.c b/drivers/usb/usbip/vudc_dev.c
> index 7091848df6c8..70b3540ece2a 100644
> --- a/drivers/usb/usbip/vudc_dev.c
> +++ b/drivers/usb/usbip/vudc_dev.c
> @@ -549,30 +549,34 @@ static int init_vudc_hw(struct vudc *udc)
>   sprintf(ep->name, "ep%d%s", num,
>   i ? (is_out ? "out" : "in") : "");
>   ep->ep.name = ep->name;
> +
> + ep->ep.ops = &vep_ops;
> +
> + usb_ep_set_maxpacket_limit(&ep->ep, ~0);
> + ep->ep.max_streams = 16;
> + ep->gadget = &udc->gadget;
> + INIT_LIST_HEAD(&ep->req_queue);
> +
>   if (i == 0) {
> + /* ep0 */
>   ep->ep.caps.type_control = true;
>   ep->ep.caps.dir_out = true;
>   ep->ep.caps.dir_in = true;
> +
> + udc->gadget.ep0 = &ep->ep;
>   } else {
> + /* All other eps */
>   ep->ep.caps.type_iso = true;
>   ep->ep.caps.type_int = true;
>   ep->ep.caps.type_bulk = true;
> - }
>  
> - if (is_out)
> - ep->ep.caps.dir_out = true;
> - else
> - ep->ep.caps.dir_in = true;
> + if (is_out)
> + ep->ep.caps.dir_out = true;
> + else
> + ep->ep.caps.dir_in = true;
>  
> - ep->ep.ops = &vep_ops;
> - list_add_tail(&ep->ep.ep_list, &udc->gadget.ep_list);
> - ep->halted = ep->wedged = ep->already_seen =
> - ep->setup_stage = 0;
> - usb_ep_set_maxpacket_limit(&ep->ep, ~0);
> - ep->ep.max_streams = 16;
> - ep->gadget = &udc->gadget;
> - ep->desc = NULL;
> - INIT_LIST_HEAD(&ep->req_queue);
> + list_add_tail(&ep->ep.ep_list, &udc->gadget.ep_list);
> + }
>   }
>  
>   spin_lock_init(&udc->lock);
> @@ -589,9 +593,6 @@ static int init_vudc_hw(struct vudc *udc)
>   ud->eh_ops.reset= vudc_device_reset;
>   ud->eh_ops.unusable = vudc_device_unusable;
>  
> - udc->gadget.ep0 = &udc->ep[0].ep;
> - list_del_init(&udc->ep[0].ep.ep_list);
> -
>   v_init_timer(udc);
>   return 0;
>  
> 

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

[PATCH] usbip: fix warning in vhci_hcd_probe/lockdep_init_map

[Shuah Khan]

vhci_hcd calls sysfs_create_group() with dynamically allocated sysfs
attributes triggering the lock-class key not persistent warning. Call
sysfs_attr_init() for dynamically allocated sysfs attributes to fix it.

vhci_hcd vhci_hcd: USB/IP Virtual Host Controller
vhci_hcd vhci_hcd: new USB bus registered, assigned bus number 2
BUG: key 88006a7e8d18 not in .data!
[ cut here ]
WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:3131
lockdep_init_map+0x60c/0x770
DEBUG_LOCKS_WARN_ON(1)[1.567044] Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc7+ #58
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
 88006bce6eb8 81f96c8a 0a02 11000d79cd6a
 ed000d79cd62 00046bce6ed8 41b58ab3 8598af40
 81f969f8  41b58ab3 0200
Call Trace:
 [< inline >] __dump_stack lib/dump_stack.c:15
 [] dump_stack+0x292/0x398 lib/dump_stack.c:51
 [] __warn+0x19f/0x1e0 kernel/panic.c:550
 [] warn_slowpath_fmt+0xc5/0x110 kernel/panic.c:565
 [] lockdep_init_map+0x60c/0x770 kernel/locking/lockdep.c:3131
 [] __kernfs_create_file+0x114/0x2a0 fs/kernfs/file.c:954
 [] sysfs_add_file_mode_ns+0x225/0x520 fs/sysfs/file.c:305
 [< inline >] create_files fs/sysfs/group.c:64
 [] internal_create_group+0x239/0x8f0 fs/sysfs/group.c:134
 [] sysfs_create_group+0x1f/0x30 fs/sysfs/group.c:156
 [] vhci_start+0x5b4/0x7a0 drivers/usb/usbip/vhci_hcd.c:978
 [] usb_add_hcd+0x8da/0x1c60 drivers/usb/core/hcd.c:2867
 [] vhci_hcd_probe+0x97/0x130
drivers/usb/usbip/vhci_hcd.c:1103
 ---
 ---
---[ end trace c33c7b202cf3aac8 ]---

Signed-off-by: Shuah Khan 
Reported-by: Andrey Konovalov 
---
 drivers/usb/usbip/vhci_sysfs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/usbip/vhci_sysfs.c b/drivers/usb/usbip/vhci_sysfs.c
index c404017..b96e5b1 100644
--- a/drivers/usb/usbip/vhci_sysfs.c
+++ b/drivers/usb/usbip/vhci_sysfs.c
@@ -361,6 +361,7 @@ static void set_status_attr(int id)
status->attr.attr.name = status->name;
status->attr.attr.mode = S_IRUGO;
status->attr.show = status_show;
+   sysfs_attr_init(&status->attr.attr);
 }
 
 static int init_status_attrs(void)
-- 
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] usbip: fix warning in vhci_hcd_probe/lockdep_init_map

[Shuah Khan]

Hi Andrey,

On 12/05/2016 12:56 PM, Shuah Khan wrote:
> vhci_hcd calls sysfs_create_group() with dynamically allocated sysfs
> attributes triggering the lock-class key not persistent warning. Call
> sysfs_attr_init() for dynamically allocated sysfs attributes to fix it.
> 
> vhci_hcd vhci_hcd: USB/IP Virtual Host Controller
> vhci_hcd vhci_hcd: new USB bus registered, assigned bus number 2
> BUG: key 88006a7e8d18 not in .data!
> [ cut here ]
> WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:3131
> lockdep_init_map+0x60c/0x770
> DEBUG_LOCKS_WARN_ON(1)[1.567044] Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc7+ #58
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>  88006bce6eb8 81f96c8a 0a02 11000d79cd6a
>  ed000d79cd62 00046bce6ed8 41b58ab3 8598af40
>  81f969f8  41b58ab3 0200
> Call Trace:
>  [< inline >] __dump_stack lib/dump_stack.c:15
>  [] dump_stack+0x292/0x398 lib/dump_stack.c:51
>  [] __warn+0x19f/0x1e0 kernel/panic.c:550
>  [] warn_slowpath_fmt+0xc5/0x110 kernel/panic.c:565
>  [] lockdep_init_map+0x60c/0x770 
> kernel/locking/lockdep.c:3131
>  [] __kernfs_create_file+0x114/0x2a0 fs/kernfs/file.c:954
>  [] sysfs_add_file_mode_ns+0x225/0x520 fs/sysfs/file.c:305
>  [< inline >] create_files fs/sysfs/group.c:64
>  [] internal_create_group+0x239/0x8f0 fs/sysfs/group.c:134
>  [] sysfs_create_group+0x1f/0x30 fs/sysfs/group.c:156
>  [] vhci_start+0x5b4/0x7a0 drivers/usb/usbip/vhci_hcd.c:978
>  [] usb_add_hcd+0x8da/0x1c60 drivers/usb/core/hcd.c:2867
>  [] vhci_hcd_probe+0x97/0x130
> drivers/usb/usbip/vhci_hcd.c:1103
>  ---
>  ---
> ---[ end trace c33c7b202cf3aac8 ]---
> 
> Signed-off-by: Shuah Khan 
> Reported-by: Andrey Konovalov 

Here is the fix. Fixed the warning I reproduced on my system.
Let me know if it works for you.

thanks,
-- Shuah

> ---
>  drivers/usb/usbip/vhci_sysfs.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/usb/usbip/vhci_sysfs.c b/drivers/usb/usbip/vhci_sysfs.c
> index c404017..b96e5b1 100644
> --- a/drivers/usb/usbip/vhci_sysfs.c
> +++ b/drivers/usb/usbip/vhci_sysfs.c
> @@ -361,6 +361,7 @@ static void set_status_attr(int id)
>   status->attr.attr.name = status->name;
>   status->attr.attr.mode = S_IRUGO;
>   status->attr.show = status_show;
> + sysfs_attr_init(&status->attr.attr);
>  }
>  
>  static int init_status_attrs(void)
> 

--
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] usbip: add missing compile time generated files to .gitignore

[Shuah Khan]

Add the following files to .gitignore

compile
libsrc/libusbip_la-sysfs_utils.lo
libsrc/libusbip_la-usbip_device_driver.lo
libsrc/libusbip_la-usbip_host_common.lo

Signed-off-by: Shuah Khan 
---
 tools/usb/usbip/.gitignore | 4 
 1 file changed, 4 insertions(+)

diff --git a/tools/usb/usbip/.gitignore b/tools/usb/usbip/.gitignore
index 9aad9e3..03b892c 100644
--- a/tools/usb/usbip/.gitignore
+++ b/tools/usb/usbip/.gitignore
@@ -2,6 +2,7 @@ Makefile
 Makefile.in
 aclocal.m4
 autom4te.cache/
+compile
 config.guess
 config.h
 config.h.in
@@ -21,7 +22,10 @@ src/Makefile.in
 stamp-h1
 libsrc/libusbip.la
 libsrc/libusbip_la-names.lo
+libsrc/libusbip_la-sysfs_utils.lo
 libsrc/libusbip_la-usbip_common.lo
+libsrc/libusbip_la-usbip_device_driver.lo
+libsrc/libusbip_la-usbip_host_common.lo
 libsrc/libusbip_la-usbip_host_driver.lo
 libsrc/libusbip_la-vhci_driver.lo
 src/usbip
-- 
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] usbip: fix warning in vhci_hcd_probe/lockdep_init_map

[Shuah Khan]

Hi Nobuo.iwata,

I noticed that in many places sysfs_attr_init() is called
before populating the fields such as name etc. However, I
don't think the order matters.

sysfs_attr_init() doesn't depend on name or any other fields
being set:

#define sysfs_attr_init(attr)   \
do {\
static struct lock_class_key __key; \
\
(attr)->key = &__key;   \
} while (0)

Are you concerned about something else?

thanks,
-- Shuah


On 12/07/2016 07:15 PM, fx IWATA NOBUO wrote:
> Dear Shuah,
> 
> I'm afraid there's one thing I have concerned.
> 
> I think it's better to move sysfs_attr_init() before
> status->attr.attr.name = status->name;
> 
> Best Regards,
> 
> nobuo.iwata
> //
>> -Original Message-
>> From: linux-usb-ow...@vger.kernel.org
>> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Andrey Konovalov
>> Sent: Tuesday, December 06, 2016 9:07 PM
>> To: Shuah Khan
>> Cc: Greg Kroah-Hartman; Valentina Manea; Shuah Khan;
>> linux-usb@vger.kernel.org; LKML
>> Subject: Re: [PATCH] usbip: fix warning in vhci_hcd_probe/lockdep_init_map
>>
>> On Mon, Dec 5, 2016 at 9:00 PM, Shuah Khan  wrote:
>>> Hi Andrey,
>>>
>>> On 12/05/2016 12:56 PM, Shuah Khan wrote:
>>>> vhci_hcd calls sysfs_create_group() with dynamically allocated sysfs
>>>> attributes triggering the lock-class key not persistent warning. Call
>>>> sysfs_attr_init() for dynamically allocated sysfs attributes to fix it.
>>>>
>>>> vhci_hcd vhci_hcd: USB/IP Virtual Host Controller vhci_hcd vhci_hcd:
>>>> new USB bus registered, assigned bus number 2
>>>> BUG: key 88006a7e8d18 not in .data!
>>>> [ cut here ]
>>>> WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:3131
>>>> lockdep_init_map+0x60c/0x770
>>>> DEBUG_LOCKS_WARN_ON(1)[1.567044] Modules linked in:
>>>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc7+ #58 Hardware
>>>> name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>>>>  88006bce6eb8 81f96c8a 0a02 11000d79cd6a
>>>>  ed000d79cd62 00046bce6ed8 41b58ab3 8598af40
>>>>  81f969f8  41b58ab3 0200
>>>> Call Trace:
>>>>  [< inline >] __dump_stack lib/dump_stack.c:15
>>>>  [] dump_stack+0x292/0x398 lib/dump_stack.c:51
>>>> [] __warn+0x19f/0x1e0 kernel/panic.c:550
>>>> [] warn_slowpath_fmt+0xc5/0x110 kernel/panic.c:565
>>>> [] lockdep_init_map+0x60c/0x770
>>>> kernel/locking/lockdep.c:3131  []
>>>> __kernfs_create_file+0x114/0x2a0 fs/kernfs/file.c:954
>> [] sysfs_add_file_mode_ns+0x225/0x520
>> fs/sysfs/file.c:305
>>>>  [< inline >] create_files fs/sysfs/group.c:64
>>>>  [] internal_create_group+0x239/0x8f0
>>>> fs/sysfs/group.c:134  []
>>>> sysfs_create_group+0x1f/0x30 fs/sysfs/group.c:156
>>>> [] vhci_start+0x5b4/0x7a0
>>>> drivers/usb/usbip/vhci_hcd.c:978  []
>>>> usb_add_hcd+0x8da/0x1c60 drivers/usb/core/hcd.c:2867
>>>> [] vhci_hcd_probe+0x97/0x130
>>>> drivers/usb/usbip/vhci_hcd.c:1103
>>>>  ---
>>>>  ---
>>>> ---[ end trace c33c7b202cf3aac8 ]---
>>>>
>>>> Signed-off-by: Shuah Khan 
>>>> Reported-by: Andrey Konovalov 
>>>
>>> Here is the fix. Fixed the warning I reproduced on my system.
>>> Let me know if it works for you.
>>
>> Hi Shuah,
>>
>> This fixes the warning I've been seeing.
>>
>> Thanks!
>>
>>>
>>> thanks,
>>> -- Shuah
>>>
>>>> ---
>>>>  drivers/usb/usbip/vhci_sysfs.c | 1 +
>>>>  1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/drivers/usb/usbip/vhci_sysfs.c
>>>> b/drivers/usb/usbip/vhci_sysfs.c index c404017..b96e5b1 100644
>>>> --- a/drivers/usb/usbip/vhci_sysfs.c
>>>> +++ b/drivers/usb/usbip/vhci_sysfs.c
>>>> @@ -361,6 +361,7 @@ static void set_status_attr(int id)
>>>>   status->attr.attr.name = status->name;
>>>>   status->attr.attr.mode = S_IRUGO;
>>>>   status->attr.show = status_show;
>>>> + sysfs_attr_init(&status->attr.attr);
>>>>  }
>>>>
>>>>  static int init_status_attrs(void)
>>>>
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>> the body of a message to majord...@vger.kernel.org More majordomo info at
>> http://vger.kernel.org/majordomo-info.html

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

Re: [PATCH] usbip: fix warning in vhci_hcd_probe/lockdep_init_map

[Shuah Khan]

On 12/07/2016 09:12 PM, fx IWATA NOBUO wrote:
> Dear Shuah,
> 
>> I noticed that in many places sysfs_attr_init() is called before populating
>> the fields such as name etc. However, I don't think the order matters.
>>
>> sysfs_attr_init() doesn't depend on name or any other fields being set:
>>
>> #define sysfs_attr_init(attr)   \
>> do {\
>> static struct lock_class_key __key; \
>> \
>> (attr)->key = &__key;   \
>> } while (0)
>>
>> Are you concerned about something else?
> 
> Yes.
> 
> If the macro name is 'attr_set_key', I don't have any concern.
> 
> The name is 'attr_init' so I think there's possibility that some other
> items in attr may initialized in future.
> 
> Also I think 'initialize struct first, then set items' is idiomatic order.
> 
> Best Regards,
> 

I am seeing places where sysfs_attr_init() after setting the name as well.
As this is more of a better done this way - I will fix this in the next
release. It is more important to fix the lockdep warning.

thanks,
-- Shuah

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

[Shuah Khan]

Hi Elen,

Adding k.opas...@samsung.com

On Thu, Dec 8, 2016 at 7:07 AM, Elen Niedermeyer
 wrote:
> Dear Sir or Madam,
>
> I'm trying to run usbip-vudc since a few days. I want to access my emulated 
> usb devices over usbip.
> I use Ubuntu 16.04.01 and updated my kernel to version 4.8.0-30. I've 
> installed linux-tools-4.8.0-30-generic which includes usbip. I enabled the 
> modules usbip-host and usbip-vudc on the server. Futhermore I use configfs to 
> emulate the usb devices.
> So I could start the daemon and my emulation. But I can't detect my emulated 
> usb device with usbip to bind it.
> Could you help me to run usbip-vudc? Do I have to install an additional 
> package? Do I miss a step?
>
> Mit freundlichen Grüßen
> Kind regards,

Could you please send your dmesg? Also could you run usbipd with
--debug and usbip with --log option and send the syslog

Krzysztof,

Any ideas. Maybe it is time the documentation is updated with vudc details.

thanks,
-- Shuah

>
> i.A. Elen Niedermeyer
> Duale Studentin Informatik
> __
>
> BIOTRONIK SE & Co. KG
> Woermannkehre 1
> 12359 Berlin, Germany
>
> Phone: +49 (0) 30 68905-2459
> Fax: +49 (0) 30 68905 2940
> Mail: elen.niederme...@biotronik.com
>
> www.biotronik.com
> BIOTRONIK - excellence for life
>
> BIOTRONIK SE & Co. KG
> Woermannkehre 1, 12359 Berlin, Germany
> Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRA 6501
>
> Vertreten durch ihre Komplementärin:
> BIOTRONIK MT SE
> Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRB 118866 B
> Geschäftsführende Direktoren: Dr. Lothar Krings, Joachim Langer, Dr. Ralf 
> Lieb, Thomas Simmerer
> This e-mail and the information it contains including attachments are 
> confidential and meant only for use by the intended recipient(s); disclosure 
> or copying is strictly prohibited. If you are not addressed, but in the 
> possession of this e-mail, please notify the sender immediately and delete 
> the document.
--
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: vUDC

[Shuah Khan]

On 12/08/2016 08:07 AM, Krzysztof Opasiak wrote:
> Hi,
> 
> On 12/08/2016 03:33 PM, Shuah Khan wrote:
>> Hi Elen,
>>
>> Adding k.opas...@samsung.com
>>
>> On Thu, Dec 8, 2016 at 7:07 AM, Elen Niedermeyer
>>  wrote:
>>> Dear Sir or Madam,
>>>
>>> I'm trying to run usbip-vudc since a few days. I want to access my emulated 
>>> usb devices over usbip.
>>> I use Ubuntu 16.04.01 and updated my kernel to version 4.8.0-30. I've 
>>> installed linux-tools-4.8.0-30-generic which includes usbip. I enabled the 
>>> modules usbip-host and usbip-vudc on the server. Futhermore I use configfs 
>>> to emulate the usb devices.
>>> So I could start the daemon and my emulation. But I can't detect my 
>>> emulated usb device with usbip to bind it.
>>> Could you help me to run usbip-vudc? Do I have to install an additional 
>>> package? Do I miss a step?
>>>
>>> Mit freundlichen Grüßen
>>> Kind regards,
>>
>> Could you please send your dmesg? Also could you run usbipd with
>> --debug and usbip with --log option and send the syslog
>>
>> Krzysztof,
>>
> 
> You setup script should look like this:
> 
> Server:
> $ modprobe usbip-vudc
> # Create your gadget, for example:
> $ cd /sys/kernel/config/usb_gadget
> $ mkdir g1
> $ mkdir g1/functions/acm.ser0
> $ mkdir g1/configs/c.1
> $ ln -s g1/functions/acm.ser0 g1/configs/c.1
> $ echo "0x1234" > g1/idVendor
> $ echo "0x5678" > g1/idProduct
> $ echo usbip-vudc.0 > UDC
> $ usbipd --device
> 
> Client:
> $ modprobe usbip-vhci
> $ usbip attach -r $SERVER_IP -d usbip-vudc.0
> 
> Please let me know if your setup script is similar and what exactly is
> not working for you.
> 
>> Any ideas. Maybe it is time the documentation is updated with vudc details.
>>
> 
> Yes I think it's a good idea. I'll try to do this when I have some spare
> time.
> 
> Best regards,
> 

Thanks Krzysztof. When you get around to it, let's just add it under
Documentation. You can create a new file usbip.txt (guess at some
point we have to make .rst)

thanks,
-- Shuah

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

Re: [PATCH] usbip: fix warning in vhci_hcd_probe/lockdep_init_map

[Shuah Khan]

On 12/08/2016 05:08 PM, fx IWATA NOBUO wrote:
> Dear Shuah,
> 
> Sorry for taking time.
> 
> It's caused by my patch.
> It was included "vhci number of ports extension" patch set.
> The set consists of 3 patches.
> 
> The fixing was included in v5.
> Only 1/3 of the set was merged but I missed to check the fixing line.
> 
> This time, I took my time to check 'exporting devices' e-mails so I was
> late to read this e-mail.
> 
> Thank you for your help,
> 
> nobuo.iwata

No problem. This problem shows up when CONFIG_DEBUG_LOCK_ALLOC
is enabled which isn't a common config option.

Enabling LOCK debug options isn't bad practice when making changes.
I have them enabled in my development systems.

thanks,
-- Shuah

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

Re: Fwd: Antwort: Re: vUDC

[Shuah Khan]

Hi Krzysztof,

On 12/09/2016 01:43 AM, Krzysztof Opasiak wrote:
> FYI to the list for next generations;)
> 
> 
>  Forwarded Message 
> Subject: Antwort: Re: vUDC
> Date: Fri, 9 Dec 2016 09:00:04 +0100
> From: Elen Niedermeyer 
> To: Krzysztof Opasiak 
> 
> 
> Hi,
> 
> so your script solved my problem. I didn't know that I should start the
> daemon with 'usbipd --device' after starting my emulation. I've tried it
> with 'usbip -d' and then bind my device with 'usbip bind -b BUSID'. But
> there wasn't listet a device by usbip with 'usbip list -l', so I didn't
> know what I have to bind.  Mit freundlichen Grüßen
> Kind regards,
> 
> i.A. Elen Niedermeyer
> Duale Studentin Informatik
> __
> 
> BIOTRONIK SE & Co. KG
> Woermannkehre 1
> 12359 Berlin, Germany
> 
> Phone: +49 (0) 30 68905-2459
> Fax: +49 (0) 30 68905 2940
> Mail: elen.niederme...@biotronik.com
> 
> -Krzysztof Opasiak  schrieb: -
> An: Shuah Khan , Elen Niedermeyer
> 
> Von: Krzysztof Opasiak 
> Datum: 08.12.2016 16:11
> Kopie: linux-usb@vger.kernel.org, kernelnewb...@nl.linux.org, LKML
> , sh...@kernel.org
> Betreff: Re: vUDC
> 
> Hi,
> 
> On 12/08/2016 03:33 PM, Shuah Khan wrote:
>> Hi Elen,
>>
>> Adding k.opas...@samsung.com
>>
>> On Thu, Dec 8, 2016 at 7:07 AM, Elen Niedermeyer
>>  wrote:
>>> Dear Sir or Madam,
>>>
>>> I'm trying to run usbip-vudc since a few days. I want to access my emulated 
>>> usb devices over usbip.
>>> I use Ubuntu 16.04.01 and updated my kernel to version 4.8.0-30. I've 
>>> installed linux-tools-4.8.0-30-generic which includes usbip. I enabled the 
>>> modules usbip-host and usbip-vudc on the server. Futhermore I use configfs 
>>> to emulate the usb devices.
>>> So I could start the daemon and my emulation. But I can't detect my 
>>> emulated usb device with usbip to bind it.
>>> Could you help me to run usbip-vudc? Do I have to install an additional 
>>> package? Do I miss a step?
>>>
>>> Mit freundlichen Grüßen
>>> Kind regards,
>>
>> Could you please send your dmesg? Also could you run usbipd with
>> --debug and usbip with --log option and send the syslog
>>
>> Krzysztof,
>>
> 
> You setup script should look like this:
> 
> Server:
> $ modprobe usbip-vudc
> # Create your gadget, for example:
> $ cd /sys/kernel/config/usb_gadget
> $ mkdir g1
> $ mkdir g1/functions/acm.ser0
> $ mkdir g1/configs/c.1
> $ ln -s g1/functions/acm.ser0 g1/configs/c.1
> $ echo "0x1234" > g1/idVendor
> $ echo "0x5678" > g1/idProduct
> $ echo usbip-vudc.0 > UDC
> $ usbipd --device
> 
> Client:
> $ modprobe usbip-vhci
> $ usbip attach -r $SERVER_IP -d usbip-vudc.0
> 
> Please let me know if your setup script is similar and what exactly is

I would be good to create server_sample.sh and client_sample.sh and add
them to tools/usb/usbip - users can customize them.

What do you think? Is this something you have time for?

thanks,
-- Shuah

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

Re: [PATCH v2] tools: usb: usbip: Add simple script to show how to setup vUDC

[Shuah Khan]

Hi Krzysztof,

Thanks for getting to this so quickly. Couple of comments below:

On 12/09/2016 10:15 AM, Krzysztof Opasiak wrote:
> Add some simple script which creates a USB gadget using ConfigFS
> and then exports it using vUDC.
> 
> This may be useful for people who just started playing with
> USB/IP and vUDC as it shows exact steps how to setup all stuff.
> 
> Signed-off-by: Krzysztof Opasiak 
> ---
> Changes since v1:
> - Fix terminology mistake (server instead of client)
> ---
>  tools/usb/usbip/vudc/vudc_server_example.sh | 100 
> 
>  1 file changed, 100 insertions(+)
>  create mode 100755 tools/usb/usbip/vudc/vudc_server_example.sh

Looks like it also includes client side, would it make sense to not name is 
server
and call it vudc_export_example.sh?

> 
> diff --git a/tools/usb/usbip/vudc/vudc_server_example.sh 
> b/tools/usb/usbip/vudc/vudc_server_example.sh
> new file mode 100755
> index ..9bd1fd58d592
> --- /dev/null
> +++ b/tools/usb/usbip/vudc/vudc_server_example.sh
> @@ -0,0 +1,100 @@
> +#!/bin/bash
> +
> +
> +# This is free and unencumbered software released into the public domain.
> +#
> +# Anyone is free to copy, modify, publish, use, compile, sell, or
> +# distribute this software, either in source code form or as a compiled
> +# binary, for any purpose, commercial or non-commercial, and by any
> +# means.
> +#
> +# In jurisdictions that recognize copyright laws, the author or authors
> +# of this software dedicate any and all copyright interest in the
> +# software to the public domain. We make this dedication for the benefit
> +# of the public at large and to the detriment of our heirs and
> +# successors. We intend this dedication to be an overt act of
> +# relinquishment in perpetuity of all present and future rights to this
> +# software under copyright law.
> +#
> +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> +# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> +# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
> +# IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> +# OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> +# ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> +# OTHER DEALINGS IN THE SOFTWARE.
> +#
> +# For more information, please refer to 
> +

This is the first file under usbip with a different license. Why did you chose
this over GPL that is what is in all oter source files in this module?

Greg! Do you have any recommendation on this?

> +
> +
> +# This is a sample script which shows how to use vUDC with ConfigFS gadgets
> +
> +
> +# Stop script on error
> +set -e
> +
> +
> +# Create your USB gadget
> +# You may use bare ConfigFS interface (as below)
> +# or libusbgx or gt toool
> +# Instead of ConfigFS gadgets you may use any of legacy gadgets.
> +
> +CONFIGFS_MOUNT_POINT="/sys/kernel/config"
> +GADGET_NAME="g1"
> +ID_VENDOR="0x1d6b"
> +ID_PRODUCT="0x0104"
> +
> +cd ${CONFIGFS_MOUNT_POINT}/usb_gadget
> +# Create a new USB gadget
> +mkdir ${GADGET_NAME}
> +cd ${GADGET_NAME}
> +
> +# This gadget contains one function - ACM (serial port over USB)
> +FUNC_DIR="functions/acm.ser0"
> +mkdir ${FUNC_DIR}
> +
> +# Just one configuration
> +mkdir configs/c.1
> +ln -s ${FUNC_DIR} configs/c.1
> +
> +# Set our gadget identity
> +echo ${ID_VENDOR} > idVendor
> +echo ${ID_PRODUCT} > idProduct
> +
> +
> +# Load vudc-module if vudc is not available
> +# You may change value of num param to get more than one vUDC instance
> +
> +[[ -d /sys/class/udc/usbip-vudc.0 ]] || modprobe usbip-vudc num=1
> +
> +
> +# Bind gadget to our vUDC
> +# By default we bind to first one but you may change this if you would like
> +# to use more than one instance
> +
> +echo "usbip-vudc.0" > UDC
> +
> +
> +# Let's now run our usbip daemon in a USB device mode
> +
> +usbipd --device &
> +
> +
> +# No

Re: [PATCH v2] tools: usb: usbip: Add simple script to show how to setup vUDC

[Shuah Khan]

Hi Krzysztof,

On 12/12/2016 05:05 AM, Krzysztof Opasiak wrote:
> 
> Hi,
> 
> On 12/09/2016 10:40 PM, Shuah Khan wrote:
>> Hi Krzysztof,
>>
>> Thanks for getting to this so quickly. Couple of comments below:
>>
>> On 12/09/2016 10:15 AM, Krzysztof Opasiak wrote:
>>> Add some simple script which creates a USB gadget using ConfigFS
>>> and then exports it using vUDC.
>>>
>>> This may be useful for people who just started playing with
>>> USB/IP and vUDC as it shows exact steps how to setup all stuff.
>>>
>>> Signed-off-by: Krzysztof Opasiak 
>>> ---
>>> Changes since v1:
>>> - Fix terminology mistake (server instead of client)
>>> ---
>>>  tools/usb/usbip/vudc/vudc_server_example.sh | 100 
>>> 
>>>  1 file changed, 100 insertions(+)
>>>  create mode 100755 tools/usb/usbip/vudc/vudc_server_example.sh
>>
>> Looks like it also includes client side, would it make sense to not name is 
>> server
>> and call it vudc_export_example.sh?
>>
> 
> This script is intended to be run on a server side not on client or
> both. It contains only couple of comments with suggestion what you
> should do on a client side but any of those commands won't be executed
> as the are all placed inside comments.
> 
> Moreover, our goal while developing vUDC was to make it compatible with
> existing USB/IP infrastructure. That's why client side usage is pretty
> the same for both vUDC and stub driver.
> 
>>>
>>> diff --git a/tools/usb/usbip/vudc/vudc_server_example.sh 
>>> b/tools/usb/usbip/vudc/vudc_server_example.sh
>>> new file mode 100755
>>> index ..9bd1fd58d592
>>> --- /dev/null
>>> +++ b/tools/usb/usbip/vudc/vudc_server_example.sh
>>> @@ -0,0 +1,100 @@
>>> +#!/bin/bash
>>> +
>>> +
>>> +# This is free and unencumbered software released into the public domain.
>>> +#
>>> +# Anyone is free to copy, modify, publish, use, compile, sell, or
>>> +# distribute this software, either in source code form or as a compiled
>>> +# binary, for any purpose, commercial or non-commercial, and by any
>>> +# means.
>>> +#
>>> +# In jurisdictions that recognize copyright laws, the author or authors
>>> +# of this software dedicate any and all copyright interest in the
>>> +# software to the public domain. We make this dedication for the benefit
>>> +# of the public at large and to the detriment of our heirs and
>>> +# successors. We intend this dedication to be an overt act of
>>> +# relinquishment in perpetuity of all present and future rights to this
>>> +# software under copyright law.
>>> +#
>>> +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>>> +# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
>>> +# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
>>> +# IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR
>>> +# OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
>>> +# ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>>> +# OTHER DEALINGS IN THE SOFTWARE.
>>> +#
>>> +# For more information, please refer to <http://unlicense.org/>
>>> +
>>
>> This is the first file under usbip with a different license. Why did you 
>> chose
>> this over GPL that is what is in all oter source files in this module?
> 
> The reason is very simple. It's just an *example* of vUDC usage, nothing
> more. There is no new or useful functionality inside this script so I
> don't see any reason to guard it with GPL license.
> 
> As far as I'm familiar with this license (please correct me if I'm
> wrong), it simply allows everyone to use this script as their code base
> and modify it to fit their needs and put them into products without
> publishing the code. Which I think may be useful for some people.

Sounds reasonable.

> 
>>
>> Greg! Do you have any recommendation on this?
>>
>>> +
>>> +
>>> +# This is a sample script which shows how to use vUDC with ConfigFS gadgets
>>> +
>>> +
>>> +#

Re: [PATCH v3] tools: usb: usbip: Add simple script to show how to setup vUDC

[Shuah Khan]

On 12/12/2016 11:55 AM, Krzysztof Opasiak wrote:
> Add some simple script which creates a USB gadget using ConfigFS
> and then exports it using vUDC.
> 
> This may be useful for people who just started playing with
> USB/IP and vUDC as it shows exact steps how to setup all stuff.
> 
> Signed-off-by: Krzysztof Opasiak 
> ---

Thanks Krzysztof.

Acked-by: Shuah Khan 

-- Shuah

> Changes since v2:
> - mention about loading usbip-vhci before listing available devices
> 
> Changes since v1:
> - Fix terminology mistake (server instead of client)
> ---
>  tools/usb/usbip/vudc/vudc_server_example.sh | 107 
> 
>  1 file changed, 107 insertions(+)
>  create mode 100755 tools/usb/usbip/vudc/vudc_server_example.sh
> 
> diff --git a/tools/usb/usbip/vudc/vudc_server_example.sh 
> b/tools/usb/usbip/vudc/vudc_server_example.sh
> new file mode 100755
> index ..2736be64f203
> --- /dev/null
> +++ b/tools/usb/usbip/vudc/vudc_server_example.sh
> @@ -0,0 +1,107 @@
> +#!/bin/bash
> +
> +
> +# This is free and unencumbered software released into the public domain.
> +#
> +# Anyone is free to copy, modify, publish, use, compile, sell, or
> +# distribute this software, either in source code form or as a compiled
> +# binary, for any purpose, commercial or non-commercial, and by any
> +# means.
> +#
> +# In jurisdictions that recognize copyright laws, the author or authors
> +# of this software dedicate any and all copyright interest in the
> +# software to the public domain. We make this dedication for the benefit
> +# of the public at large and to the detriment of our heirs and
> +# successors. We intend this dedication to be an overt act of
> +# relinquishment in perpetuity of all present and future rights to this
> +# software under copyright law.
> +#
> +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> +# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> +# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
> +# IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> +# OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> +# ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> +# OTHER DEALINGS IN THE SOFTWARE.
> +#
> +# For more information, please refer to <http://unlicense.org/>
> +
> +
> +
> +# This is a sample script which shows how to use vUDC with ConfigFS gadgets
> +
> +
> +# Stop script on error
> +set -e
> +
> +
> +# Create your USB gadget
> +# You may use bare ConfigFS interface (as below)
> +# or libusbgx or gt toool
> +# Instead of ConfigFS gadgets you may use any of legacy gadgets.
> +
> +CONFIGFS_MOUNT_POINT="/sys/kernel/config"
> +GADGET_NAME="g1"
> +ID_VENDOR="0x1d6b"
> +ID_PRODUCT="0x0104"
> +
> +cd ${CONFIGFS_MOUNT_POINT}/usb_gadget
> +# Create a new USB gadget
> +mkdir ${GADGET_NAME}
> +cd ${GADGET_NAME}
> +
> +# This gadget contains one function - ACM (serial port over USB)
> +FUNC_DIR="functions/acm.ser0"
> +mkdir ${FUNC_DIR}
> +
> +# Just one configuration
> +mkdir configs/c.1
> +ln -s ${FUNC_DIR} configs/c.1
> +
> +# Set our gadget identity
> +echo ${ID_VENDOR} > idVendor
> +echo ${ID_PRODUCT} > idProduct
> +
> +
> +# Load vudc-module if vudc is not available
> +# You may change value of num param to get more than one vUDC instance
> +
> +[[ -d /sys/class/udc/usbip-vudc.0 ]] || modprobe usbip-vudc num=1
> +
> +
> +# Bind gadget to our vUDC
> +# By default we bind to first one but you may change this if you would like
> +# to use more than one instance
> +
> +echo "usbip-vudc.0" > UDC
> +
> +
> +# Let's now run our usbip daemon in a USB device mode
> +#

Re: [PATCH] tools: usb: usbip: Update README

[Shuah Khan]

Hi Krzysztof,

Thanks for the patch.

On 12/13/2016 12:52 PM, Krzysztof Opasiak wrote:
> Update README file:
> - remove outdated parts
> - clarify terminology and general structure
> - add some description of vUDC
> 
> Signed-off-by: Krzysztof Opasiak 
> ---
>  tools/usb/usbip/README | 56 
> +-
>  1 file changed, 55 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/usb/usbip/README b/tools/usb/usbip/README
> index 831f49fea3ce..148d13814306 100644
> --- a/tools/usb/usbip/README
> +++ b/tools/usb/usbip/README
> @@ -4,10 +4,32 @@
>  # Copyright (C) 2011 matt mooney 
>  #   2005-2008 Takahiro Hirofuchi
>  
> +[Overview]
> +USB/IP protocol allows to pass USB device from server to client over the
> +network. The USB device may be either physical device connected to a server 
> or
> +software entity created on a server using USB gadget subsystem.
> +Whole project consists of four parts:
> +

Please add definitions for client and server.

> +- usbip-vhci
> +Kernel module which provides a virtual USB Host Controller and allows
> +to import a USB device from a remote machine. Used on a client side.

Could be rephrased as:

A client side Kernel module which provides a virtual USB Host Controller and 
allows
import of a USB device from a remote server machine.

> +
> +- usbip-host (stub driver)
> +Kernel module which provides a USB device driver which can be bound 
> to
> +a physical USB device to make it exportable. Used on a server side.
> +

A server side Kernel module which provides a USB device driver that exports
physical USB devices that are bound to it.

> +- usbip-vudc
> +Kernel module which provides a virtual USB Device Controller and 
> allows
> +to export a USB device created using USB Gadget Subsystem. Used on
> +a server side.
> +

Similar changes as above.

> +- usbip-utils
> +A set of userspace tools used to handle connection and management.
> +Used on both sides.
>  
>  [Requirements]
>  - USB/IP device drivers
> - Found in the staging directory of the Linux kernel.
> +Found in the drivers/usb/usbip/ directory of the Linux kernel tree.
>  
>  - libudev >= 2.0
>   libudev library
> @@ -36,6 +58,10 @@
>  
>  
>  [Usage]
> +On a server side there are two entities which can be shared.
> +First of them is physical usb device connected to the machine.
> +To make it available below steps should be executed:
> +
>  server:# (Physically attach your USB device.)
>  
>  server:# insmod usbip-core.ko
> @@ -52,6 +78,30 @@
>   - The USB device 1-2 is now exportable to other hosts!
>   - Use `usbip unbind --busid 1-2' to stop exporting the device.
>  
> +Second of shareable entities is USB Gadget created using USB Gadget Subsystem
> +on a server machine. To make it available below steps should be executed:
> +
> +server:# (Create your USB gadget)
> +- Currently the most preferable way of creating a new USB gadget
> +  is ConfigFS Composite Gadget. Please refer to its documentation
> +  for details.
> +- See vudc_server_example.sh for a short example of USB gadget 
> creation
> +
> +server:# insmod usbip-core.ko
> +server:# insmod usbip-vudc.ko
> +- To create more than one instance of vudc use num module param
> +
> +server:# (Bind gadget to one of available vudc)
> +- Assign your new gadget to USB/IP UDC
> +- Using ConfigFS interface you may do this simply by:
> +server:# cd /sys/kernel/config/usb_gadget/
> +server:# echo "usbip-vudc.0" > UDC
> +
> +server:# usbipd -D --device
> +- Start usbip daemon.
> +
> +To attach new device to client machine below commands should be used:
> +
>  client:# insmod usbip-core.ko
>  client:# insmod vhci-hcd.ko
>  
> @@ -60,6 +110,8 @@
>  
>  client:# usbip attach --remote  --busid 1-2
>   - Connect the remote USB device.
> + - When using vudc on a server side busid is really vudc instance name.
> +   For example: usbip-vudc.0
>  
>  client:# usbip port
>   - Show virtual port status.
> @@ -192,6 +244,8 @@ Detach the imported device:
>   - http://usbip.wiki.sourceforge.net/how-to-debug-usbip
>  - usbip-host.ko must be bound to the target device.
>   - See /proc/bus/usb/devices and find "Driver=..." lines of the device.
> +- Target USB gadget must be bound to vudc
> +  (using USB gadget susbsys, not usbip bind command)
>  - Shutdown firewall.
>   - usbip now uses TCP port 3240.
>  - Disable SELinux.
> 

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

Re: [PATCH] usbip: vudc: check for NULL before use

[Shuah Khan]

On 12/18/2016 03:44 PM, Sudip Mukherjee wrote:
> to_vep() is doing a container_of() on _ep. It is better to do the NULL
> check first and then use it.
> 
> Signed-off-by: Sudip Mukherjee 
> ---
>  drivers/usb/usbip/vudc_dev.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/usbip/vudc_dev.c b/drivers/usb/usbip/vudc_dev.c
> index 968471b..32ea604 100644
> --- a/drivers/usb/usbip/vudc_dev.c
> +++ b/drivers/usb/usbip/vudc_dev.c
> @@ -388,10 +388,10 @@ static int vep_dequeue(struct usb_ep *_ep, struct 
> usb_request *_req)
>   unsigned long flags;
>   int ret = 0;
>  
> - ep = to_vep(_ep);
>   if (!_ep)
>   return -EINVAL;

Hmm. Linus's latest checks _ep and _req. Are you sure you are working
with the latest tree?

>  
> + ep = to_vep(_ep);
>   udc = ep_to_vudc(ep);
>   if (!udc->driver)
>   return -ESHUTDOWN;
>

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

Re: [PATCH] usbip: vudc: check for NULL before use

[Shuah Khan]

Hi Sudip,

On Wed, Dec 21, 2016 at 6:33 AM, Sudip Mukherjee
 wrote:
> On Tue, Dec 20, 2016 at 07:31:44AM -0700, Shuah Khan wrote:
>> On 12/18/2016 03:44 PM, Sudip Mukherjee wrote:
>> > to_vep() is doing a container_of() on _ep. It is better to do the NULL
>> > check first and then use it.
>> >
>> > Signed-off-by: Sudip Mukherjee 
>> > ---
>> >  drivers/usb/usbip/vudc_dev.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/usb/usbip/vudc_dev.c b/drivers/usb/usbip/vudc_dev.c
>> > index 968471b..32ea604 100644
>> > --- a/drivers/usb/usbip/vudc_dev.c
>> > +++ b/drivers/usb/usbip/vudc_dev.c
>> > @@ -388,10 +388,10 @@ static int vep_dequeue(struct usb_ep *_ep, struct 
>> > usb_request *_req)
>> > unsigned long flags;
>> > int ret = 0;
>> >
>> > -   ep = to_vep(_ep);
>> > if (!_ep)
>> > return -EINVAL;
>>
>> Hmm. Linus's latest checks _ep and _req. Are you sure you are working
>> with the latest tree?
>
> I checked with next-20161221 and its still there.

This is for  vep_dequeue() - Are you sure both linux-next and Linus's tree show
the following:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/usbip/vudc_dev.c

static int vep_dequeue(struct usb_ep *_ep, struct usb_request *_req)
{
struct vep *ep;
struct vrequest *req;
struct vudc *udc;
struct vrequest *lst;
unsigned long flags;
int ret = -EINVAL;

if (!_ep || !_req)
return ret;

ep = to_vep(_ep);
req = to_vrequest(_req);
udc = req->udc;

if (!udc->driver)
return -ESHUTDOWN;

There are other routines in this file that don't check null. I am confused.

thanks,
-- Shuah
--
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 v14 00/10] usbip: exporting devices

[Shuah Khan]

Hi Nobuo Iwata,

On 12/26/2016 12:08 AM, Nobuo Iwata wrote:
> Dear all,
> 
> This series of patches adds exporting device operation to USB/IP.
> 
> NOTE:
> This patch set modifies only userspace codes in tools/usb/usbip.
> Existing operation is still available.
> New operation will not be enabled unless new daemon is started.

This is a quick note to say that I am on vacation for Christmas
break all of this week and will review this series during the
first week of January.

> 
> 1. Background
> 
> The motivation of this series is to utilize USB/IP as a platform for 
> IoT. Or a platform to serve ubiquitous devices.
> Linux is major of server OS and various small linux node is distributed 
> everywhere. USB devices are most easy-to-use for the small nodes. 
> USB/IP is useful to serve USB devices of distributed linux nodes as if 
> they are local devices without any modification to applications.
> 
> 2. Goal
> 
> The goal is to add flexibility to USB/IP for the platform for IoT.
> 
> 1) To improve usability of operations
> When two Linux machines are in a small distance, it's OK to bind (makes 
> importable) at device side machine and attach (import) at application 
> side.
> If application is as cloud service or in blade server, it's not 
> practical to attach from application side. It's useful to connect 
> (export) from device side. This patch set adds the new operation to 
> connect devices from device side machine.
> 
> 2) To give flexibility to direction of connection
> Using USB/IP in internet, there can be two cases.
> a) an application is inside firewall and devices are outside.
> b) devices are inside firewall and an application is inside.
> In case-a, import works because the connection is from inside.
> In case-b, import doesn't works because the connection is from outside. 
> Connection from device side is needed. This patch set adds the 
> direction of connection establishment.
> 
> NOTE:
> Directions of URB requests and responses are not changed. Only 
> direction of connection establishment initiated with usbip command is 
> added to exsiting one.
> 
> 3. What's 'exporting' device
> 
> Exporting devices is not new. The request and response PDU have already 
> been defined in tools/usbip/usbip/src/usbip_network.h.
> #/* Export a USB device to a remote host. */
> #define OP_EXPORT   0x06
> #define OP_REQ_EXPORT   (OP_REQUEST | OP_EXPORT)
> #define OP_REP_EXPORT   (OP_REPLY   | OP_EXPORT)
> # struct op_export_request
> # struct op_export_reply
> #/* un-Export a USB device from a remote host. */
> #define OP_UNEXPORT 0x07
> #define OP_REQ_UNEXPORT (OP_REQUEST | OP_UNEXPORT)
> #define OP_REP_UNEXPORT (OP_REPLY   | OP_UNEXPORT)
> # struct op_unexport_request
> # struct op_unexport_reply 
> 
> But they have not been used yet. This series adds new operations: 
> 'connect' and 'disconnect' using these PDUs.
> 
> EXISTING) - invites devices from application(vhci)-side
>  +--+   +--+
>  device--+ STUB |   | application/VHCI |
>  +--+   +--+
>  (server)   (client)
>  1) # usbipd ... start daemon
>  = = =
>  2) # usbip list --local
>  3) # usbip bind
>   <--- list bound devices ---  4) # usbip list --remote
>   <--- import a device --  5) # usbip attach
>  = = =
>  X disconnected6) # usbip detach
>  7) usbip unbind
> 
> NEW) - dedicates devices from device(stub)-side
>  +--+   +--+
>  device--+ STUB |   | application/VHCI |
>  +--+   +--+
>  (client)   (server)
> 1) # usbipa ... start daemon
>  = = =
>  2) # usbip list --local
>  3) # usbip connect--- export a device -->
>  = = =
>  4) # usbip disconnect --- un-export a device --->
> 
>  Bind and unbind are done in connect and disconnect internally.
> 
> 4. The use cases
> 
> EXISTING)
> 
> In existing way, computers in small distance, having same user account, 
> can be easily managed by a same user. Bind in local machine and attach 
> in remote machine by the user. The devices can be exporsed 
> automatically in the local machine, for example, at strat up. They can 
> be attached from remote.
> 
> When there are distributes linux nodes with USB devices in internet, 
> they are exposed by bind operation at start up, server behind firewall 
> can list and attach the devices.  
>  Internet  
>  Exposed   +--+++++
>  +--+  |Linux |+   |Router, ||Service |
> +|device|--|Controller||---|proxy,  ||on  |
> |+--+  +--+|   |firewall||

Re: [PATCH v2] tools: usb: usbip: Update README

[Shuah Khan]

On 12/20/2016 12:53 PM, Krzysztof Opasiak wrote:
> Update README file:
> - remove outdated parts
> - clarify terminology and general structure
> - add some description of vUDC
> 
> Signed-off-by: Krzysztof Opasiak 

Thanks.

Acked-by: Shuah Khan 

-- Shuah

> ---
> Changes since v1:
> - Add server and client definition
> - rephrase modules description
> ---
>  tools/usb/usbip/README | 57 
> +-
>  1 file changed, 56 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/usb/usbip/README b/tools/usb/usbip/README
> index 831f49fea3ce..5eb2b6c7722b 100644
> --- a/tools/usb/usbip/README
> +++ b/tools/usb/usbip/README
> @@ -4,10 +4,33 @@
>  # Copyright (C) 2011 matt mooney 
>  #   2005-2008 Takahiro Hirofuchi
>  
> +[Overview]
> +USB/IP protocol allows to pass USB device from server to client over the
> +network. Server is a machine which provides (shares) a USB device. Client is
> +a machine which uses USB device provided by server over the network.
> +The USB device may be either physical device connected to a server or
> +software entity created on a server using USB gadget subsystem.
> +Whole project consists of four parts:
> +
> +- usbip-vhci
> +A client side kernel module which provides a virtual USB Host 
> Controller
> +and allows to import a USB device from a remote machine.
> +
> +- usbip-host (stub driver)
> +A server side module which provides a USB device driver which can be
> +bound to a physical USB device to make it exportable.
> +
> +- usbip-vudc
> +A server side module which provides a virtual USB Device Controller 
> and allows
> +to export a USB device created using USB Gadget Subsystem.
> +
> +- usbip-utils
> +A set of userspace tools used to handle connection and management.
> +Used on both sides.
>  
>  [Requirements]
>  - USB/IP device drivers
> - Found in the staging directory of the Linux kernel.
> +Found in the drivers/usb/usbip/ directory of the Linux kernel tree.
>  
>  - libudev >= 2.0
>   libudev library
> @@ -36,6 +59,10 @@
>  
>  
>  [Usage]
> +On a server side there are two entities which can be shared.
> +First of them is physical usb device connected to the machine.
> +To make it available below steps should be executed:
> +
>  server:# (Physically attach your USB device.)
>  
>  server:# insmod usbip-core.ko
> @@ -52,6 +79,30 @@
>   - The USB device 1-2 is now exportable to other hosts!
>   - Use `usbip unbind --busid 1-2' to stop exporting the device.
>  
> +Second of shareable entities is USB Gadget created using USB Gadget Subsystem
> +on a server machine. To make it available below steps should be executed:
> +
> +server:# (Create your USB gadget)
> +- Currently the most preferable way of creating a new USB gadget
> +  is ConfigFS Composite Gadget. Please refer to its documentation
> +  for details.
> +- See vudc_server_example.sh for a short example of USB gadget 
> creation
> +
> +server:# insmod usbip-core.ko
> +server:# insmod usbip-vudc.ko
> +- To create more than one instance of vudc use num module param
> +
> +server:# (Bind gadget to one of available vudc)
> +- Assign your new gadget to USB/IP UDC
> +- Using ConfigFS interface you may do this simply by:
> +server:# cd /sys/kernel/config/usb_gadget/
> +server:# echo "usbip-vudc.0" > UDC
> +
> +server:# usbipd -D --device
> +- Start usbip daemon.
> +
> +To attach new device to client machine below commands should be used:
> +
>  client:# insmod usbip-core.ko
>  client:# insmod vhci-hcd.ko
>  
> @@ -60,6 +111,8 @@
>  
>  client:# usbip attach --remote  --busid 1-2
>   - Connect the remote USB device.
> + - When using vudc on a server side busid is really vudc instance name.
> +   For example: usbip-vudc.0
>  
>  client:# usbip port
>   - Show virtual port status.
> @@ -192,6 +245,8 @@ Detach the imported device:
>   - http://usbip.wiki.sourceforge.net/how-to-debug-usbip
>  - usbip-host.ko must be bound to the target device.
>   - See /proc/bus/usb/devices and find "Driver=..." lines of the device.
> +- Target USB gadget must be bound to vudc
> +  (using USB gadget susbsys, not usbip bind command)
>  - Shutdown firewall.
>   - usbip now uses TCP port 3240.
>  - Disable SELinux.
> 

--
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 v8 1/2] usbip: vhci extension: modifications to userspace

[Shuah Khan]

On 12/26/2016 12:18 AM, Nobuo Iwata wrote:
> Modification to the userspace tools including usbip/libsrc and 
> usbip/src.

Modification to do what? Could you please write a concise change
log describing what this patch does and why? Please note that the
information in the cover-letter doesn't go int this commit.

> 
> Changed corresponding to new vhci_sysfs.c.
> 
> nports in sysfs is used to get total number of ports. 
> 
> Old get_nports() ignores the last status line because 
> udev_device_get_sysattr_value() drops last new line. New version uses 
> nports attribute so it's doesn't have this problem.
> 
> status[.N] in sysfs are used.
> 
> parse_status() which reads all status lines is broken into open, close, 
> read-line and parse-line. Parse-line is reused to find free port and 
> get imported device.
> 
> In daemon, status was loaded into memory by 
> usbip_vhci_refresh_device_list() at receiving every request. The loaded 
> status is used to find free port. It is changed to read status directly 
> to find free port.
> 
> Wording inconsistencies are fixed according to the rule below.
> 
> rhport, HC_PORTS: ports within a controller (or root hub).
> port, nports: ports across the controllers.
> 
> Signed-off-by: Nobuo Iwata 
> ---
>  tools/usb/usbip/libsrc/vhci_driver.c | 396 ++-
>  tools/usb/usbip/libsrc/vhci_driver.h |  45 +--
>  tools/usb/usbip/src/usbip_attach.c   |  12 +-
>  tools/usb/usbip/src/usbip_port.c |  13 +-
>  tools/usb/usbip/src/usbipd_app.c |  31 +--
>  5 files changed, 242 insertions(+), 255 deletions(-)
> 
> diff --git a/tools/usb/usbip/libsrc/vhci_driver.c 
> b/tools/usb/usbip/libsrc/vhci_driver.c
> index 8b94ab5..844187d 100644
> --- a/tools/usb/usbip/libsrc/vhci_driver.c
> +++ b/tools/usb/usbip/libsrc/vhci_driver.c
> @@ -15,11 +15,24 @@
>  #undef  PROGNAME
>  #define PROGNAME "libusbip"
>  
> -struct usbip_vhci_driver *vhci_driver;
> -struct udev *udev_context;
> +static struct udev_device *vhci_hc_device;
> +static struct udev *udev_context;
> +static int vhci_nports;
>  
> -static struct usbip_imported_device *
> -imported_device_init(struct usbip_imported_device *idev, char *busid)
> +struct usbip_vhci_device {
> + int port;
> + uint32_t status;
> +
> + uint32_t devid;
> +
> + uint8_t busnum;
> + uint8_t devnum;
> +
> + /* usbip_class_device list */
> + struct usbip_usb_device udev;
> +};
> +
> +static int imported_device_init(struct usbip_vhci_device *vdev, char *busid)
>  {
>   struct udev_device *sudev;
>  
> @@ -27,132 +40,131 @@ imported_device_init(struct usbip_imported_device 
> *idev, char *busid)
>  "usb", busid);
>   if (!sudev) {
>   dbg("udev_device_new_from_subsystem_sysname failed: %s", busid);
> - goto err;
> + return -1;
>   }
> - read_usb_device(sudev, &idev->udev);
> + read_usb_device(sudev, &vdev->udev);
>   udev_device_unref(sudev);
>  
> - return idev;
> -
> -err:
> - return NULL;
> + return 0;
>  }
>  
> +struct status_context {
> + int controller;
> + const char *c;
> +};
>  
> +#define OPEN_MODE_FIRST  0
> +#define OPEN_MODE_REOPEN 1
>  
> -static int parse_status(const char *value)
> -{
> - int ret = 0;
> - char *c;
> +static int open_hc_device(int mode);
>  
> +#define MAX_STATUS_NAME 16
>  
> - for (int i = 0; i < vhci_driver->nports; i++)
> - memset(&vhci_driver->idev[i], 0, sizeof(vhci_driver->idev[i]));
> +static int open_status(struct status_context *ctx, int mode)
> +{
> + char name[MAX_STATUS_NAME+1];
>  
> + if (mode == OPEN_MODE_FIRST)
> + ctx->controller = 0;
> + else
> + (ctx->controller)++;
>  
> - /* skip a header line */
> - c = strchr(value, '\n');
> - if (!c)
> + if (open_hc_device(OPEN_MODE_REOPEN))
>   return -1;
> - c++;
>  
> - while (*c != '\0') {
> - int port, status, speed, devid;
> - unsigned long socket;
> - char lbusid[SYSFS_BUS_ID_SIZE];
> -
> - ret = sscanf(c, "%d %d %d %x %lx %31s\n",
> - &port, &status, &speed,
> - &devid, &socket, lbusid);
> -
> - if (ret < 5) {
> - dbg("sscanf failed: %d", ret);
> - BUG();
> - }
> -
> - dbg("port %d status %d speed %d devid %x",
> - port, status, speed, devid);
> - dbg("socket %lx lbusid %s", socket, lbusid);
> + if (ctx->controller == 0)
> + strcpy(name, "status");
> + else
> + snprintf(name, MAX_STATUS_NAME + 1,
> + "status.%d", ctx->controller);
> + ctx->c = udev_device_get_sysattr_value(vhci_hc_device, name);
> + if (ctx->c == NULL)
> + return -1;
>  
> + return 0;
> +}
>  
> - /* if

Re: [PATCH v8 2/2] usbip: vhci extension: dynamic extension

[Shuah Khan]

On 12/26/2016 12:18 AM, Nobuo Iwata wrote:
> Modification for dynamic device registration and unregistration.

Why is this necessary? Could make your change logs concise with
important details on why a change is needed and the functionality
it adds. This change log is way too long and doesn't summarize the
changes. Please note that the information in the cover-letter doesn't
go into this commit.

It helps to have a clear change log so it is easier for me to review
the patch.

thanks,
-- Shuah

> 
> 1. kernel config
> 
> Following parameters are added.
> 
> USBIP_VHCI_HC_PORTS: Number of ports per USB/IP virtual host 
> controller. The default is 8 - same as current VHCI_NPORTS.
> USBIP_VHCI_MAX_HCS: Muximum number of USB/IP virtual host controllers. 
> The default is 1.
> USBIP_VHCI_INIT_HCS: Initial number of USB/IP virtual host controllers. 
> The default is 1.
> Static number of devices: USBIP_VHCI_NR_HCS is removed with this patch.
> 
> 2. view from sysfs
> 
> Sysfs structure is changed as following.
> 
> BEFORE this patchset:
> /sys/devices/platform
> +-- vhci
> +-- status
> +-- attach
> +-- detach
> +-- usbip_debug
> 
> AFTER: example for CONFIG_USBIP_INIT_HCS=2 CONFIG_USBIP_MAX_HCS=4
> At the beginning
> /sys/devices/platform
> +-- vhci
> |   +-- nports
> |   +-- status
> |   +-- status.1
> |   +-- status.2
> |   +-- status.3
> |   +-- attach
> |   +-- detach
> |   +-- usbip_debug
> +-- vhci.1
> 
> The status files are shown to the maximum number of devices. Port 
> status in status.2 and status.3 represents as free but corresponding 
> devices are not yes registered.
> When all ports in status and status.1 are used, userspace tool requests 
> 'attach' to a port in status.2 then vhci.2 will be registred. The limit 
> is defined with USBIP_VHCI_MAX_NCS.
> 
> By preparing muximum number of status files, there's no need to 
> introduce additional operations for userspace tool.
> 
> When number of free ports becomes more than USBIP_VHCI_HC_PORTS * 
> VHCI_FREE_HCS(2), a free controller other than the first one will be 
> unregistered. It will be invoked by 'detach' operation and other error 
> situations which ports are released.
> 
> Signed-off-by: Nobuo Iwata 
> ---
>  drivers/usb/usbip/Kconfig  |  17 ++-
>  drivers/usb/usbip/vhci.h   |  36 -
>  drivers/usb/usbip/vhci_hcd.c   | 250 -
>  drivers/usb/usbip/vhci_rx.c|  10 +-
>  drivers/usb/usbip/vhci_sysfs.c |  46 +++---
>  drivers/usb/usbip/vhci_tx.c|   6 +-
>  6 files changed, 291 insertions(+), 74 deletions(-)
> 
> diff --git a/drivers/usb/usbip/Kconfig b/drivers/usb/usbip/Kconfig
> index eeefa29..42d8979 100644
> --- a/drivers/usb/usbip/Kconfig
> +++ b/drivers/usb/usbip/Kconfig
> @@ -35,8 +35,8 @@ config USBIP_VHCI_HC_PORTS
> host controller driver, this defines number of ports per
> USB/IP virtual host controller.
>  
> -config USBIP_VHCI_NR_HCS
> - int "Number of USB/IP virtual host controllers"
> +config USBIP_VHCI_MAX_HCS
> + int "Maximum number of USB/IP virtual host controllers"
>   range 1 128
>   default 1
>   depends on USBIP_VHCI_HCD
> @@ -44,7 +44,18 @@ config USBIP_VHCI_NR_HCS
> To increase number of ports available for USB/IP virtual
> host controller driver, this defines number of USB/IP
> virtual host controllers as if adding physical host
> -   controllers.
> +   controllers. This defines the maximum number.
> +
> +config USBIP_VHCI_INIT_HCS
> + int "Initial number of USB/IP virtual host controllers"
> + range 1 USBIP_VHCI_MAX_HCS
> + default 1
> + depends on USBIP_VHCI_MAX_HCS
> + ---help---
> +   To increase number of ports available for USB/IP virtual
> +   host controller driver, this defines number of USB/IP
> +   virtual host controllers as if adding physical host
> +   controllers. This defines the number at initializing.
>  
>  config USBIP_HOST
>   tristate "Host driver"
> diff --git a/drivers/usb/usbip/vhci.h b/drivers/usb/usbip/vhci.h
> index 88b71c4..ba893a7 100644
> --- a/drivers/usb/usbip/vhci.h
> +++ b/drivers/usb/usbip/vhci.h
> @@ -51,6 +51,9 @@ struct vhci_device {
>  
>   /* vhci_tx thread sleeps for this queue */
>   wait_queue_head_t waitq_tx;
> +
> + /* denotes port is in-use */
> + atomic_t using_port;
>  };
>  
>  /* urb->hcpriv, use container_of() */
> @@ -79,12 +82,21 @@ struct

[PATCH] usb: dwc3-exynos fix unspecified suspend clk error handling

[Shuah Khan]

Fix dwc3_exynos_probe() to call clk_prepare_enable() only when suspend
clock is specified. Call clk_disable_unprepare() from remove and probe
error path only when susp_clk has been set from remove and probe error
paths.

Signed-off-by: Shuah Khan 
---
 drivers/usb/dwc3/dwc3-exynos.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index e27899b..f97a3d7 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -131,8 +131,8 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
if (IS_ERR(exynos->susp_clk)) {
dev_info(dev, "no suspend clk specified\n");
exynos->susp_clk = NULL;
-   }
-   clk_prepare_enable(exynos->susp_clk);
+   } else
+   clk_prepare_enable(exynos->susp_clk);
 
if (of_device_is_compatible(node, "samsung,exynos7-dwusb3")) {
exynos->axius_clk = devm_clk_get(dev, "usbdrd30_axius_clk");
@@ -196,7 +196,8 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
regulator_disable(exynos->vdd33);
 err2:
clk_disable_unprepare(exynos->axius_clk);
-   clk_disable_unprepare(exynos->susp_clk);
+   if (exynos->susp_clk)
+   clk_disable_unprepare(exynos->susp_clk);
clk_disable_unprepare(exynos->clk);
return ret;
 }
@@ -210,7 +211,8 @@ static int dwc3_exynos_remove(struct platform_device *pdev)
platform_device_unregister(exynos->usb3_phy);
 
clk_disable_unprepare(exynos->axius_clk);
-   clk_disable_unprepare(exynos->susp_clk);
+   if (exynos->susp_clk)
+   clk_disable_unprepare(exynos->susp_clk);
clk_disable_unprepare(exynos->clk);
 
regulator_disable(exynos->vdd33);
-- 
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] usb: dwc3-exynos fix unspecified suspend clk error handling

[Shuah Khan]

On 01/10/2017 05:05 AM, Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> On Monday, January 09, 2017 07:21:31 PM Shuah Khan wrote:
>> Fix dwc3_exynos_probe() to call clk_prepare_enable() only when suspend
>> clock is specified. Call clk_disable_unprepare() from remove and probe
>> error path only when susp_clk has been set from remove and probe error
>> paths.
> 
> It is legal to call clk_prepare_enable() and clk_disable_unprepare()
> for NULL clock.  Also your patch changes susp_clk handling while
> leaves axius_clk handling (which also can be NULL) untouched.
> 
> Do you actually see some runtime problem with the current code?
> 
> If not then the patch should probably be dropped.
> 
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics

Hi Bartlomiej,

I am seeing the "no suspend clk specified" message in dmesg.
After that it sets the exynos->susp_clk = NULL and starts
calling clk_prepare_enable(exynos->susp_clk);

That can't be good. If you see the logic right above this
one for exynos->clk, it returns error and fails the probe.
This this case it doesn't, but tries to use null susp_clk.

I believe this patch is necessary.

thanks,
-- Shuah

> 
>> Signed-off-by: Shuah Khan 
>> ---
>>  drivers/usb/dwc3/dwc3-exynos.c | 10 ++
>>  1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
>> index e27899b..f97a3d7 100644
>> --- a/drivers/usb/dwc3/dwc3-exynos.c
>> +++ b/drivers/usb/dwc3/dwc3-exynos.c
>> @@ -131,8 +131,8 @@ static int dwc3_exynos_probe(struct platform_device 
>> *pdev)
>>  if (IS_ERR(exynos->susp_clk)) {
>>  dev_info(dev, "no suspend clk specified\n");
>>  exynos->susp_clk = NULL;
>> -}
>> -clk_prepare_enable(exynos->susp_clk);
>> +} else
>> +clk_prepare_enable(exynos->susp_clk);
>>  
>>  if (of_device_is_compatible(node, "samsung,exynos7-dwusb3")) {
>>  exynos->axius_clk = devm_clk_get(dev, "usbdrd30_axius_clk");
>> @@ -196,7 +196,8 @@ static int dwc3_exynos_probe(struct platform_device 
>> *pdev)
>>  regulator_disable(exynos->vdd33);
>>  err2:
>>  clk_disable_unprepare(exynos->axius_clk);
>> -clk_disable_unprepare(exynos->susp_clk);
>> +if (exynos->susp_clk)
>> +clk_disable_unprepare(exynos->susp_clk);
>>  clk_disable_unprepare(exynos->clk);
>>  return ret;
>>  }
>> @@ -210,7 +211,8 @@ static int dwc3_exynos_remove(struct platform_device 
>> *pdev)
>>  platform_device_unregister(exynos->usb3_phy);
>>  
>>  clk_disable_unprepare(exynos->axius_clk);
>> -clk_disable_unprepare(exynos->susp_clk);
>> +if (exynos->susp_clk)
>> +clk_disable_unprepare(exynos->susp_clk);
>>  clk_disable_unprepare(exynos->clk);
>>  
>>  regulator_disable(exynos->vdd33);
> 

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

Re: [PATCH] usb: dwc3-exynos fix unspecified suspend clk error handling

[Shuah Khan]

On 01/10/2017 07:16 AM, Shuah Khan wrote:
> On 01/10/2017 05:05 AM, Bartlomiej Zolnierkiewicz wrote:
>>
>> Hi,
>>
>> On Monday, January 09, 2017 07:21:31 PM Shuah Khan wrote:
>>> Fix dwc3_exynos_probe() to call clk_prepare_enable() only when suspend
>>> clock is specified. Call clk_disable_unprepare() from remove and probe
>>> error path only when susp_clk has been set from remove and probe error
>>> paths.
>>
>> It is legal to call clk_prepare_enable() and clk_disable_unprepare()
>> for NULL clock.  Also your patch changes susp_clk handling while
>> leaves axius_clk handling (which also can be NULL) untouched.
>>
>> Do you actually see some runtime problem with the current code?
>>
>> If not then the patch should probably be dropped.
>>
>> Best regards,
>> --
>> Bartlomiej Zolnierkiewicz
>> Samsung R&D Institute Poland
>> Samsung Electronics
> 
> Hi Bartlomiej,
> 
> I am seeing the "no suspend clk specified" message in dmesg.
> After that it sets the exynos->susp_clk = NULL and starts
> calling clk_prepare_enable(exynos->susp_clk);
> 
> That can't be good. If you see the logic right above this
> one for exynos->clk, it returns error and fails the probe.
> This this case it doesn't, but tries to use null susp_clk.
> 
> I believe this patch is necessary.

Let me clarify this a bit further. Since we already know
susp_clk is null, with this patch we can avoid extra calls
to clk_prepare_enable() and clk_disable_unprepare().

One can say, it also adds extra checks, hence I will let you
decide one way or the other. :)

thanks,
-- Shuah

> 
> thanks,
> -- Shuah
> 
>>
>>> Signed-off-by: Shuah Khan 
>>> ---
>>>  drivers/usb/dwc3/dwc3-exynos.c | 10 ++
>>>  1 file changed, 6 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
>>> index e27899b..f97a3d7 100644
>>> --- a/drivers/usb/dwc3/dwc3-exynos.c
>>> +++ b/drivers/usb/dwc3/dwc3-exynos.c
>>> @@ -131,8 +131,8 @@ static int dwc3_exynos_probe(struct platform_device 
>>> *pdev)
>>> if (IS_ERR(exynos->susp_clk)) {
>>> dev_info(dev, "no suspend clk specified\n");
>>> exynos->susp_clk = NULL;
>>> -   }
>>> -   clk_prepare_enable(exynos->susp_clk);
>>> +   } else
>>> +   clk_prepare_enable(exynos->susp_clk);
>>>  
>>> if (of_device_is_compatible(node, "samsung,exynos7-dwusb3")) {
>>> exynos->axius_clk = devm_clk_get(dev, "usbdrd30_axius_clk");
>>> @@ -196,7 +196,8 @@ static int dwc3_exynos_probe(struct platform_device 
>>> *pdev)
>>> regulator_disable(exynos->vdd33);
>>>  err2:
>>> clk_disable_unprepare(exynos->axius_clk);
>>> -   clk_disable_unprepare(exynos->susp_clk);
>>> +   if (exynos->susp_clk)
>>> +   clk_disable_unprepare(exynos->susp_clk);
>>> clk_disable_unprepare(exynos->clk);
>>> return ret;
>>>  }
>>> @@ -210,7 +211,8 @@ static int dwc3_exynos_remove(struct platform_device 
>>> *pdev)
>>> platform_device_unregister(exynos->usb3_phy);
>>>  
>>> clk_disable_unprepare(exynos->axius_clk);
>>> -   clk_disable_unprepare(exynos->susp_clk);
>>> +   if (exynos->susp_clk)
>>> +   clk_disable_unprepare(exynos->susp_clk);
>>> clk_disable_unprepare(exynos->clk);
>>>  
>>> regulator_disable(exynos->vdd33);
>>
> 

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

Re: [PATCH] usb: dwc3-exynos fix unspecified suspend clk error handling

[Shuah Khan]

On 01/10/2017 04:20 AM, Sergei Shtylyov wrote:
> Hello!
> 
> On 01/10/2017 05:21 AM, Shuah Khan wrote:
> 
>> Fix dwc3_exynos_probe() to call clk_prepare_enable() only when suspend
>> clock is specified. Call clk_disable_unprepare() from remove and probe
>> error path only when susp_clk has been set from remove and probe error
>> paths.
>>
>> Signed-off-by: Shuah Khan 
>> ---
>>  drivers/usb/dwc3/dwc3-exynos.c | 10 ++
>>  1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
>> index e27899b..f97a3d7 100644
>> --- a/drivers/usb/dwc3/dwc3-exynos.c
>> +++ b/drivers/usb/dwc3/dwc3-exynos.c
>> @@ -131,8 +131,8 @@ static int dwc3_exynos_probe(struct platform_device 
>> *pdev)
>>  if (IS_ERR(exynos->susp_clk)) {
>>  dev_info(dev, "no suspend clk specified\n");
>>  exynos->susp_clk = NULL;
>> -}
>> -clk_prepare_enable(exynos->susp_clk);
>> +} else
>> +clk_prepare_enable(exynos->susp_clk);
> 
>CodingStyle: need {} here as well since another branch has them.
> 
> [...]
> 
> MBR, Sergei
> 

Thanks. There is some concerns whether or not this patch is needed.
If we decide to include the patch, I will send v2 with your comment.

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

Re: [PATCH] usb: dwc3-exynos fix unspecified suspend clk error handling

[Shuah Khan]

On 01/10/2017 09:05 AM, Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> On Tuesday, January 10, 2017 07:36:35 AM Shuah Khan wrote:
>> On 01/10/2017 07:16 AM, Shuah Khan wrote:
>>> On 01/10/2017 05:05 AM, Bartlomiej Zolnierkiewicz wrote:
>>>>
>>>> Hi,
>>>>
>>>> On Monday, January 09, 2017 07:21:31 PM Shuah Khan wrote:
>>>>> Fix dwc3_exynos_probe() to call clk_prepare_enable() only when suspend
>>>>> clock is specified. Call clk_disable_unprepare() from remove and probe
>>>>> error path only when susp_clk has been set from remove and probe error
>>>>> paths.
>>>>
>>>> It is legal to call clk_prepare_enable() and clk_disable_unprepare()
>>>> for NULL clock.  Also your patch changes susp_clk handling while
>>>> leaves axius_clk handling (which also can be NULL) untouched.
>>>>
>>>> Do you actually see some runtime problem with the current code?
>>>>
>>>> If not then the patch should probably be dropped.
>>>>
>>>> Best regards,
>>>> --
>>>> Bartlomiej Zolnierkiewicz
>>>> Samsung R&D Institute Poland
>>>> Samsung Electronics
>>>
>>> Hi Bartlomiej,
>>>
>>> I am seeing the "no suspend clk specified" message in dmesg.
>>> After that it sets the exynos->susp_clk = NULL and starts
>>> calling clk_prepare_enable(exynos->susp_clk);
>>>
>>> That can't be good. If you see the logic right above this
>>> one for exynos->clk, it returns error and fails the probe.
>>> This this case it doesn't, but tries to use null susp_clk.
> 
> exynos->susp_clk is optional, exynos->clk is not.

Right. That is clear since we don't fail the probe.

> 
>>> I believe this patch is necessary.
>>
>> Let me clarify this a bit further. Since we already know
>> susp_clk is null, with this patch we can avoid extra calls
>> to clk_prepare_enable() and clk_disable_unprepare().
>>
>> One can say, it also adds extra checks, hence I will let you
>> decide one way or the other. :)
> 
> I would prefer to leave the things as they are currently.
> 
> The code in question is not performance sensitive so extra
> calls are not a problem.  No extra checks means less code.
> 
> Also the current code seems to be more in line with the rest
> of the kernel.

What functionality is missing without the suspend clock? Would
it make sense to change the info. message to include what it
means. At the moment it doesn't anything more than "no suspend
clock" which is a very cryptic user visible message. It would be
helpful for it to also include what functionality is impacted.

thanks,
-- Shuah

> 
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
> 
>> thanks,
>> -- Shuah
>>
>>>
>>> thanks,
>>> -- Shuah
>>>
>>>>
>>>>> Signed-off-by: Shuah Khan 
>>>>> ---
>>>>>  drivers/usb/dwc3/dwc3-exynos.c | 10 ++
>>>>>  1 file changed, 6 insertions(+), 4 deletions(-)
>>>>>
>>>>> diff --git a/drivers/usb/dwc3/dwc3-exynos.c 
>>>>> b/drivers/usb/dwc3/dwc3-exynos.c
>>>>> index e27899b..f97a3d7 100644
>>>>> --- a/drivers/usb/dwc3/dwc3-exynos.c
>>>>> +++ b/drivers/usb/dwc3/dwc3-exynos.c
>>>>> @@ -131,8 +131,8 @@ static int dwc3_exynos_probe(struct platform_device 
>>>>> *pdev)
>>>>>   if (IS_ERR(exynos->susp_clk)) {
>>>>>   dev_info(dev, "no suspend clk specified\n");
>>>>>   exynos->susp_clk = NULL;
>>>>> - }
>>>>> - clk_prepare_enable(exynos->susp_clk);
>>>>> + } else
>>>>> + clk_prepare_enable(exynos->susp_clk);
>>>>>  
>>>>>   if (of_device_is_compatible(node, "samsung,exynos7-dwusb3")) {
>>>>>   exynos->axius_clk = devm_clk_get(dev, "usbdrd30_axius_clk");
>>>>> @@ -196,7 +196,8 @@ static int dwc3_exynos_probe(struct platform_device 
>>>>> *pdev)
>>>>>   regulator_disable(exynos->vdd33);
>>>>>  err2:
>>>>>   clk_disable_unprepare(exynos->axius_clk);
>>>>> - clk_disable_unprepare(exynos->susp_clk);
>>>>> + if (exynos->susp_clk)
>>>>> + clk_disable_unprepare(exynos->susp_clk);
>>>>>   clk_disable_unprepare(exynos->clk);
>>>>>   return ret;
>>>>>  }
>>>>> @@ -210,7 +211,8 @@ static int dwc3_exynos_remove(struct platform_device 
>>>>> *pdev)
>>>>>   platform_device_unregister(exynos->usb3_phy);
>>>>>  
>>>>>   clk_disable_unprepare(exynos->axius_clk);
>>>>> - clk_disable_unprepare(exynos->susp_clk);
>>>>> + if (exynos->susp_clk)
>>>>> + clk_disable_unprepare(exynos->susp_clk);
>>>>>   clk_disable_unprepare(exynos->clk);
>>>>>  
>>>>>   regulator_disable(exynos->vdd33);
> 

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

Re: [PATCH] usb: dwc3-exynos fix unspecified suspend clk error handling

[Shuah Khan]

On 01/10/2017 11:23 AM, Bartlomiej Zolnierkiewicz wrote:
> On Tuesday, January 10, 2017 07:03:57 PM Bartlomiej Zolnierkiewicz wrote:
>>
>> Hi,
>>
>> On Tuesday, January 10, 2017 11:23:38 PM Anand Moon wrote:
>>> Hi Shuah,
>>>
>>> On 10 January 2017 at 21:58, Shuah Khan  wrote:
>>>> On 01/10/2017 09:05 AM, Bartlomiej Zolnierkiewicz wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> On Tuesday, January 10, 2017 07:36:35 AM Shuah Khan wrote:
>>>>>> On 01/10/2017 07:16 AM, Shuah Khan wrote:
>>>>>>> On 01/10/2017 05:05 AM, Bartlomiej Zolnierkiewicz wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On Monday, January 09, 2017 07:21:31 PM Shuah Khan wrote:
>>>>>>>>> Fix dwc3_exynos_probe() to call clk_prepare_enable() only when suspend
>>>>>>>>> clock is specified. Call clk_disable_unprepare() from remove and probe
>>>>>>>>> error path only when susp_clk has been set from remove and probe error
>>>>>>>>> paths.
>>>>>>>>
>>>>>>>> It is legal to call clk_prepare_enable() and clk_disable_unprepare()
>>>>>>>> for NULL clock.  Also your patch changes susp_clk handling while
>>>>>>>> leaves axius_clk handling (which also can be NULL) untouched.
>>>>>>>>
>>>>>>>> Do you actually see some runtime problem with the current code?
>>>>>>>>
>>>>>>>> If not then the patch should probably be dropped.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> --
>>>>>>>> Bartlomiej Zolnierkiewicz
>>>>>>>> Samsung R&D Institute Poland
>>>>>>>> Samsung Electronics
>>>>>>>
>>>>>>> Hi Bartlomiej,
>>>>>>>
>>>>>>> I am seeing the "no suspend clk specified" message in dmesg.
>>>>>>> After that it sets the exynos->susp_clk = NULL and starts
>>>>>>> calling clk_prepare_enable(exynos->susp_clk);
>>>>>>>
>>>>>>> That can't be good. If you see the logic right above this
>>>>>>> one for exynos->clk, it returns error and fails the probe.
>>>>>>> This this case it doesn't, but tries to use null susp_clk.
>>>>>
>>>>> exynos->susp_clk is optional, exynos->clk is not.
>>>>
>>>> Right. That is clear since we don't fail the probe.
>>>>
>>>>>
>>>>>>> I believe this patch is necessary.
>>>>>>
>>>>>> Let me clarify this a bit further. Since we already know
>>>>>> susp_clk is null, with this patch we can avoid extra calls
>>>>>> to clk_prepare_enable() and clk_disable_unprepare().
>>>>>>
>>>>>> One can say, it also adds extra checks, hence I will let you
>>>>>> decide one way or the other. :)
>>>>>
>>>>> I would prefer to leave the things as they are currently.
>>>>>
>>>>> The code in question is not performance sensitive so extra
>>>>> calls are not a problem.  No extra checks means less code.
>>>>>
>>>>> Also the current code seems to be more in line with the rest
>>>>> of the kernel.
>>>>
>>>> What functionality is missing without the suspend clock? Would
>>>> it make sense to change the info. message to include what it
>>>> means. At the moment it doesn't anything more than "no suspend
>>>> clock" which is a very cryptic user visible message. It would be
>>>> helpful for it to also include what functionality is impacted.
>>>>
>>>
>>> Both usbdrd30_susp_clk and usbdrd30_axius_clk are used by exynos5433 
>>> platform
>>
>> Can you point me to the use of usbdrd30_axius_clk?
>>
>> I cannot find in the upstream code.
>>
>>> so moving the clk under compatible string "samsung,exynos7-dwusb3" make 
>>> sense.
>>
>> This is not so simple and we would probably need a new compatible for
>> Exynos5433 (it is currently using "samsung,exynos5250-dwusb3" one and
>> is not using axius_clk).
> 
> I also think that regardless of what is decided on making susp_clk
> non-optional for some Exynos SoCs we should probably remove the debug
> message as it doesn't bring useful information and may be confusing.
> 
> Shuah, can you take care of this?

Yes. This message as it reads now is not only confusing, but also can
lead users to think something is wrong.

I can get rid of it or I could change it from info to debug and change
it to read:

"Optional Suspend clock isn't found. Diver operation isn't impacted"

thanks,
-- Shuah

> 
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
> 

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

Re: [PATCH] usb: dwc3-exynos fix unspecified suspend clk error handling

[Shuah Khan]

On 01/10/2017 11:59 AM, Krzysztof Kozlowski wrote:
> On Tue, Jan 10, 2017 at 11:37:24AM -0700, Shuah Khan wrote:
>> On 01/10/2017 11:23 AM, Bartlomiej Zolnierkiewicz wrote:
>>> I also think that regardless of what is decided on making susp_clk
>>> non-optional for some Exynos SoCs we should probably remove the debug
>>> message as it doesn't bring useful information and may be confusing.
>>>
>>> Shuah, can you take care of this?
>>
>> Yes. This message as it reads now is not only confusing, but also can
>> lead users to think something is wrong.
>>
>> I can get rid of it or I could change it from info to debug and change
>> it to read:
>>
>> "Optional Suspend clock isn't found. Diver operation isn't impacted"
> 
> It is even more confusing. If the clock is required (by binding, by
> hardware) - make it an error. If it is completely not important - do not
> print anything. If it is optional but helpful (enabling clock gives
> someything) then print something... but it is not that case.
> 
> Best regards,
> Krzysztof
> 

Sounds fair. I will send a patch to remove the message.

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

[PATCH] usb: dwc3-exynos remove suspend clock unspecified debug message

[Shuah Khan]

dwc3-exynos prints debug message when suspend clock is not specified.
The suspend clock is optional and driver can work without it.

This debug message doesn't add any value and leads to confusion and
concern. Remove it.

Signed-off-by: Shuah Khan 
---
This patch is a result of the disussion on the following patch.
https://lkml.org/lkml/2017/1/9/891

drivers/usb/dwc3/dwc3-exynos.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index e27899b..3e8407a 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -128,10 +128,8 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
clk_prepare_enable(exynos->clk);
 
exynos->susp_clk = devm_clk_get(dev, "usbdrd30_susp_clk");
-   if (IS_ERR(exynos->susp_clk)) {
-   dev_info(dev, "no suspend clk specified\n");
+   if (IS_ERR(exynos->susp_clk))
exynos->susp_clk = NULL;
-   }
clk_prepare_enable(exynos->susp_clk);
 
if (of_device_is_compatible(node, "samsung,exynos7-dwusb3")) {
-- 
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] usb: dwc3-exynos fix axius clock error path to do cleanup

[Shuah Khan]

Axius clock error path returns without disabling clock and suspend clock.
Fix it to disable them before returning error.

Signed-off-by: Shuah Khan 
---
 drivers/usb/dwc3/dwc3-exynos.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index 3e8407a..f7421c2 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -136,7 +136,8 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
exynos->axius_clk = devm_clk_get(dev, "usbdrd30_axius_clk");
if (IS_ERR(exynos->axius_clk)) {
dev_err(dev, "no AXI UpScaler clk specified\n");
-   return -ENODEV;
+   ret = -ENODEV;
+   goto axius_clk_err;
}
clk_prepare_enable(exynos->axius_clk);
} else {
@@ -194,6 +195,7 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
regulator_disable(exynos->vdd33);
 err2:
clk_disable_unprepare(exynos->axius_clk);
+axius_clk_err:
clk_disable_unprepare(exynos->susp_clk);
clk_disable_unprepare(exynos->clk);
return ret;
-- 
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] usb: dwc3-exynos remove suspend clock unspecified debug message

[Shuah Khan]

On 01/10/2017 05:18 PM, Javier Martinez Canillas wrote:
> Hello Shuah,
> 
> On 01/10/2017 06:20 PM, Shuah Khan wrote:
>> dwc3-exynos prints debug message when suspend clock is not specified.
>> The suspend clock is optional and driver can work without it.
>>
>> This debug message doesn't add any value and leads to confusion and
>> concern. Remove it.
>>
>> Signed-off-by: Shuah Khan 
>> ---
>> This patch is a result of the disussion on the following patch.
>> https://lkml.org/lkml/2017/1/9/891
>>
>> drivers/usb/dwc3/dwc3-exynos.c | 4 +---
>>  1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
>> index e27899b..3e8407a 100644
>> --- a/drivers/usb/dwc3/dwc3-exynos.c
>> +++ b/drivers/usb/dwc3/dwc3-exynos.c
>> @@ -128,10 +128,8 @@ static int dwc3_exynos_probe(struct platform_device 
>> *pdev)
>>  clk_prepare_enable(exynos->clk);
>>  
>>  exynos->susp_clk = devm_clk_get(dev, "usbdrd30_susp_clk");
>> -if (IS_ERR(exynos->susp_clk)) {
>> -dev_info(dev, "no suspend clk specified\n");
> 
> Sorry for being late in the discussion, but what about making it a
> dev_dbg() instead? That way the message may not confuse others but
> still keep information that could be useful for debugging purposes.
> 
> I know the current message isn't great but keeping it as debug allows
> to improve it later.
> 
> Best regards,
> 

I proposed dev debug and the recommendation from  Krzysztof was to
just remove it. Please see response from Krzysztof's response.

thanks,
-- Shuah


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

Re: [PATCH] usb: dwc3-exynos fix axius clock error path to do cleanup

[Shuah Khan]

On 01/10/2017 05:27 PM, Javier Martinez Canillas wrote:
> Hello Shuah,
> 
> Patch looks good to me, I've just one comment.
> 
> On 01/10/2017 08:05 PM, Shuah Khan wrote:
>> Axius clock error path returns without disabling clock and suspend clock.
>> Fix it to disable them before returning error.
>>
>> Signed-off-by: Shuah Khan 
>> ---
>>  drivers/usb/dwc3/dwc3-exynos.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
>> index 3e8407a..f7421c2 100644
>> --- a/drivers/usb/dwc3/dwc3-exynos.c
>> +++ b/drivers/usb/dwc3/dwc3-exynos.c
>> @@ -136,7 +136,8 @@ static int dwc3_exynos_probe(struct platform_device 
>> *pdev)
>>  exynos->axius_clk = devm_clk_get(dev, "usbdrd30_axius_clk");
>>  if (IS_ERR(exynos->axius_clk)) {
>>  dev_err(dev, "no AXI UpScaler clk specified\n");
>> -return -ENODEV;
>> +ret = -ENODEV;
>> +goto axius_clk_err;
>>  }
>>  clk_prepare_enable(exynos->axius_clk);
>>  } else {
>> @@ -194,6 +195,7 @@ static int dwc3_exynos_probe(struct platform_device 
>> *pdev)
>>  regulator_disable(exynos->vdd33);
>>  err2:
>>  clk_disable_unprepare(exynos->axius_clk);
>> +axius_clk_err:
> 
> This label isn't consistent with the others, I know the errN aren't great
> so what about changing those to meaningful names in a preparatory patch?
> 
> Reviewed-by: Javier Martinez Canillas 
> 
> Best regards,
> 

Javier,

Right they aren't consistent. Changing them all to a better naming scheme
will have be done in another cleanup patch in my opinion. I don't want to
include cleanup in this fix.

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

Re: [PATCH] usb: dwc3-exynos fix axius clock error path to do cleanup

[Shuah Khan]

On 01/10/2017 05:32 PM, Javier Martinez Canillas wrote:
> Hello Shuah,
> 
> On 01/10/2017 09:30 PM, Shuah Khan wrote:
> 
> [snip]
> 
>>>>clk_disable_unprepare(exynos->axius_clk);
>>>> +axius_clk_err:
>>>
>>> This label isn't consistent with the others, I know the errN aren't great
>>> so what about changing those to meaningful names in a preparatory patch?
>>>
>>> Reviewed-by: Javier Martinez Canillas 
>>>
>>> Best regards,
>>>
>>
>> Javier,
>>
>> Right they aren't consistent. Changing them all to a better naming scheme
>> will have be done in another cleanup patch in my opinion. I don't want to
>> include cleanup in this fix.
>>
> 
> I didn't mean to be done in the same patch, that's why I said in another
> preparatory patch.

Yes. I can send the cleanup patch.

-- Shuah

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

[PATCH] usb: dwc3 dwc3_exynos_probe() change goto labels to meaningful names

[Shuah Khan]

Change goto labels to meaningful names from a series of errNs.

Signed-off-by: Shuah Khan 
---
 drivers/usb/dwc3/dwc3-exynos.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index f7421c2..ea50f74 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -147,53 +147,53 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
exynos->vdd33 = devm_regulator_get(dev, "vdd33");
if (IS_ERR(exynos->vdd33)) {
ret = PTR_ERR(exynos->vdd33);
-   goto err2;
+   goto vdd33_err;
}
ret = regulator_enable(exynos->vdd33);
if (ret) {
dev_err(dev, "Failed to enable VDD33 supply\n");
-   goto err2;
+   goto vdd33_err;
}
 
exynos->vdd10 = devm_regulator_get(dev, "vdd10");
if (IS_ERR(exynos->vdd10)) {
ret = PTR_ERR(exynos->vdd10);
-   goto err3;
+   goto vdd10_err;
}
ret = regulator_enable(exynos->vdd10);
if (ret) {
dev_err(dev, "Failed to enable VDD10 supply\n");
-   goto err3;
+   goto vdd10_err;
}
 
ret = dwc3_exynos_register_phys(exynos);
if (ret) {
dev_err(dev, "couldn't register PHYs\n");
-   goto err4;
+   goto phys_err;
}
 
if (node) {
ret = of_platform_populate(node, NULL, NULL, dev);
if (ret) {
dev_err(dev, "failed to add dwc3 core\n");
-   goto err5;
+   goto populate_err;
}
} else {
dev_err(dev, "no device node, failed to add dwc3 core\n");
ret = -ENODEV;
-   goto err5;
+   goto populate_err;
}
 
return 0;
 
-err5:
+populate_err:
platform_device_unregister(exynos->usb2_phy);
platform_device_unregister(exynos->usb3_phy);
-err4:
+phys_err:
regulator_disable(exynos->vdd10);
-err3:
+vdd10_err:
regulator_disable(exynos->vdd33);
-err2:
+vdd33_err:
clk_disable_unprepare(exynos->axius_clk);
 axius_clk_err:
clk_disable_unprepare(exynos->susp_clk);
-- 
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] usb: dwc3-exynos Fix dma_mask WARN_ON from xhci_plat_probe()

[Shuah Khan]

During dwc3_exynos_probe(), WARN_ON(!pdev->dev.dma_mask) is triggered from
xhci_plat_probe(). dwc3_host_init() doesn't configure DMA prior to adding
the platform device.

dwc3_host_init() was changed to not configure DMA with the change to use
bus->sysdev for DMA config.

sysdev_is_parent is not true for dwc3-exynos. This might be the reason why
there is a need to configure DMA in dwc3_host_init() prior to adding the
platform device for xhci in this path.

This fix adds the DMA config to dwc3_host_init() without undoing any other
changes in
commit d64ff406e51e ("usb: dwc3: use bus->sysdev for DMA configuration")

[3.372356] WARNING: CPU: 2 PID: 108 at drivers/usb/host/xhci-plat.c:168 xhc0
[3.381381] Modules linked in:
[3.384373] CPU: 2 PID: 108 Comm: kworker/2:1 Not tainted 4.10.0-rc2-00250-g8
[3.392783] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[3.398854] Workqueue: events deferred_probe_work_func
[3.403994] [] (unwind_backtrace) from [] (show_stack+0x)
[3.411696] [] (show_stack) from [] (dump_stack+0x78/0x8)
[3.418877] [] (dump_stack) from [] (__warn+0xe8/0x100)
[3.425796] [] (__warn) from [] (warn_slowpath_null+0x20)
[3.433344] [] (warn_slowpath_null) from [] (xhci_plat_p)
[3.441845] [] (xhci_plat_probe) from [] (platform_drv_p)
[3.450157] [] (platform_drv_probe) from [] (driver_prob)
[3.458994] [] (driver_probe_device) from [] (bus_for_ea)
[3.467485] [] (bus_for_each_drv) from [] (__device_atta)
[3.475716] [] (__device_attach) from [] (bus_probe_devi)
[3.483872] [] (bus_probe_device) from [] (device_add+0x)
[3.491741] [] (device_add) from [] (platform_device_add)
[3.499892] [] (platform_device_add) from [] (dwc3_host_)
[3.508379] [] (dwc3_host_init) from [] (dwc3_probe+0x94)
[3.516091] [] (dwc3_probe) from [] (platform_drv_probe+)
[3.523975] [] (platform_drv_probe) from [] (driver_prob)
[3.532814] [] (driver_probe_device) from [] (bus_for_ea)
[3.541306] [] (bus_for_each_drv) from [] (__device_atta)
[3.549538] [] (__device_attach) from [] (bus_probe_devi)
[3.557684] [] (bus_probe_device) from [] (device_add+0x)
[3.565582] [] (device_add) from [] (of_platform_device_)
[3.574586] [] (of_platform_device_create_pdata) from [])
[3.584722] [] (of_platform_bus_create) from [] (of_plat)
[3.593828] [] (of_platform_populate) from [] (dwc3_exyn)
[3.602660] [] (dwc3_exynos_probe) from [] (platform_drv)
[3.611150] [] (platform_drv_probe) from [] (driver_prob)
[3.619988] [] (driver_probe_device) from [] (bus_for_ea)
[3.628480] [] (bus_for_each_drv) from [] (__device_atta)
[3.636712] [] (__device_attach) from [] (bus_probe_devi)
[3.644857] [] (bus_probe_device) from [] (deferred_prob)
[3.653798] [] (deferred_probe_work_func) from [] (proce)

Signed-off-by: Shuah Khan 
---
Arnd! I isolated the smallest change to avoid the WARN_ON. Please let me
know if this problem could be fixed in another way.

 drivers/usb/dwc3/host.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index 487f0ff..f68f71f 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -84,7 +84,10 @@ int dwc3_host_init(struct dwc3 *dwc)
return -ENOMEM;
}
 
+   dma_set_coherent_mask(&xhci->dev, dwc->dev->coherent_dma_mask);
xhci->dev.parent= dwc->dev;
+   xhci->dev.dma_mask  = dwc->dev->dma_mask;
+   xhci->dev.dma_parms = dwc->dev->dma_parms;
 
dwc->xhci = xhci;
 
-- 
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] usb: dwc3-exynos Fix dma_mask WARN_ON from xhci_plat_probe()

[Shuah Khan]

On 01/12/2017 12:26 AM, Felipe Balbi wrote:
> 
> Hi,
> 
> Shuah Khan  writes:
>> During dwc3_exynos_probe(), WARN_ON(!pdev->dev.dma_mask) is triggered from
>> xhci_plat_probe(). dwc3_host_init() doesn't configure DMA prior to adding
>> the platform device.
>>
>> dwc3_host_init() was changed to not configure DMA with the change to use
>> bus->sysdev for DMA config.
>>
>> sysdev_is_parent is not true for dwc3-exynos. This might be the reason why
>> there is a need to configure DMA in dwc3_host_init() prior to adding the
>> platform device for xhci in this path.
>>
>> This fix adds the DMA config to dwc3_host_init() without undoing any other
>> changes in
>> commit d64ff406e51e ("usb: dwc3: use bus->sysdev for DMA configuration")
>>
>> [3.372356] WARNING: CPU: 2 PID: 108 at drivers/usb/host/xhci-plat.c:168 
>> xhc0
>> [3.381381] Modules linked in:
>> [3.384373] CPU: 2 PID: 108 Comm: kworker/2:1 Not tainted 
>> 4.10.0-rc2-00250-g8
>> [3.392783] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>> [3.398854] Workqueue: events deferred_probe_work_func
>> [3.403994] [] (unwind_backtrace) from [] 
>> (show_stack+0x)
>> [3.411696] [] (show_stack) from [] 
>> (dump_stack+0x78/0x8)
>> [3.418877] [] (dump_stack) from [] 
>> (__warn+0xe8/0x100)
>> [3.425796] [] (__warn) from [] 
>> (warn_slowpath_null+0x20)
>> [3.433344] [] (warn_slowpath_null) from [] 
>> (xhci_plat_p)
>> [3.441845] [] (xhci_plat_probe) from [] 
>> (platform_drv_p)
>> [3.450157] [] (platform_drv_probe) from [] 
>> (driver_prob)
>> [3.458994] [] (driver_probe_device) from [] 
>> (bus_for_ea)
>> [3.467485] [] (bus_for_each_drv) from [] 
>> (__device_atta)
>> [3.475716] [] (__device_attach) from [] 
>> (bus_probe_devi)
>> [3.483872] [] (bus_probe_device) from [] 
>> (device_add+0x)
>> [3.491741] [] (device_add) from [] 
>> (platform_device_add)
>> [3.499892] [] (platform_device_add) from [] 
>> (dwc3_host_)
>> [3.508379] [] (dwc3_host_init) from [] 
>> (dwc3_probe+0x94)
>> [3.516091] [] (dwc3_probe) from [] 
>> (platform_drv_probe+)
>> [3.523975] [] (platform_drv_probe) from [] 
>> (driver_prob)
>> [3.532814] [] (driver_probe_device) from [] 
>> (bus_for_ea)
>> [3.541306] [] (bus_for_each_drv) from [] 
>> (__device_atta)
>> [3.549538] [] (__device_attach) from [] 
>> (bus_probe_devi)
>> [3.557684] [] (bus_probe_device) from [] 
>> (device_add+0x)
>> [3.565582] [] (device_add) from [] 
>> (of_platform_device_)
>> [3.574586] [] (of_platform_device_create_pdata) from 
>> [])
>> [3.584722] [] (of_platform_bus_create) from [] 
>> (of_plat)
>> [3.593828] [] (of_platform_populate) from [] 
>> (dwc3_exyn)
>> [3.602660] [] (dwc3_exynos_probe) from [] 
>> (platform_drv)
>> [3.611150] [] (platform_drv_probe) from [] 
>> (driver_prob)
>> [3.619988] [] (driver_probe_device) from [] 
>> (bus_for_ea)
>> [3.628480] [] (bus_for_each_drv) from [] 
>> (__device_atta)
>> [3.636712] [] (__device_attach) from [] 
>> (bus_probe_devi)
>> [3.644857] [] (bus_probe_device) from [] 
>> (deferred_prob)
>> [3.653798] [] (deferred_probe_work_func) from [] 
>> (proce)
>>
>> Signed-off-by: Shuah Khan 
>> ---
>> Arnd! I isolated the smallest change to avoid the WARN_ON. Please let me
>> know if this problem could be fixed in another way.
>>
>>  drivers/usb/dwc3/host.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
>> index 487f0ff..f68f71f 100644
>> --- a/drivers/usb/dwc3/host.c
>> +++ b/drivers/usb/dwc3/host.c
>> @@ -84,7 +84,10 @@ int dwc3_host_init(struct dwc3 *dwc)
>>  return -ENOMEM;
>>  }
>>  
>> +dma_set_coherent_mask(&xhci->dev, dwc->dev->coherent_dma_mask);
>>  xhci->dev.parent= dwc->dev;
>> +xhci->dev.dma_mask  = dwc->dev->dma_mask;
>> +xhci->dev.dma_parms = dwc->dev->dma_parms;
> 
> this is the result of a missed patch. Mathias is discussing the proper
> fix for this.
> 

Can you please point me to the thread if you have it handy?

thanks,
-- Shuah
--
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 v14 01/10] usbip: exporting devices: modifications to network header

[Shuah Khan]

Hi Nobuo,

On 12/26/2016 12:08 AM, Nobuo Iwata wrote:
> This patch set implements operations to export and unexport device 
> using pre-defined but un-used export and un-export request and reply.

Get rid of the above from the changelog.

> 
> This patch modifies export and un-export reply in 
> tools/usb/usbip/src/usbip_network.h. The 'returncode' of each response 
> is removed. The status is set in op_common.status.

Please don't use file names, instead reference the structures.

As an example this change log would be lot clear as below:

"Add new status codes to network common header struct op_common.
 Add corresponding user friendly string for each of the status
 codes. Change dbg messages to use new status strings"

There is no need to describe code in the change log.

> 
> Following status codes are added for this patch set.
>   ST_NO_FREE_POR
>   ST_NOT_FOUND
> 
> The reason to use op_common.status:
>   1) usbip_net_recv_op_common() hanles as error when the status is other
>  than ST_OK.
>   2) The status has a commnet "add more error code".
> 
> They become empty struct. Other empty struct, 'op_devlist_request', 
> defined.

Does this go with this patch. Doesn't look like the above is accurate.
Don't see op_devlist_request in this patch.

> 
> This patch also includes string translation of the status codes.
> 
> Signed-off-by: Nobuo Iwata 
> ---
>  tools/usb/usbip/src/usbip_network.c | 26 +-
>  tools/usb/usbip/src/usbip_network.h |  8 
>  2 files changed, 29 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/usb/usbip/src/usbip_network.c 
> b/tools/usb/usbip/src/usbip_network.c
> index b4c37e7..069ec54 100644
> --- a/tools/usb/usbip/src/usbip_network.c
> +++ b/tools/usb/usbip/src/usbip_network.c
> @@ -163,6 +163,29 @@ int usbip_net_send_op_common(int sockfd, uint32_t code, 
> uint32_t status)
>   return 0;
>  }
>  
> +struct op_common_error {
> + uint32_tstatus;
> + const char  *str;
> +};
> +
> +struct op_common_error op_common_errors[] = {
> + {ST_NA, "not available"},
> + {ST_NO_FREE_PORT, "no free port"},
> + {ST_DEVICE_NOT_FOUND, "device not found"},
> + {0, NULL}
> +};
> +
> +static const char *op_common_strerror(uint32_t status)
> +{
> + struct op_common_error *err;
> +
> + for (err = op_common_errors; err->str != NULL; err++) {
> + if (err->status == status)
> + return err->str;
> + }
> + return "unknown error";
> +}

This loop is unnecessary. Do a range check on the passed in status
value and index and return the string.

Move the op_common_errors[] and op_common_strerror() usbip_network.h
This can easily be a macro.

Change other places ST_OK handling is done. I see some in usbipd.c

> +
>  int usbip_net_recv_op_common(int sockfd, uint16_t *code)
>  {
>   struct op_common op_common;
> @@ -196,7 +219,8 @@ int usbip_net_recv_op_common(int sockfd, uint16_t *code)
>   }
>  
>   if (op_common.status != ST_OK) {
> - dbg("request failed at peer: %d", op_common.status);
> + dbg("request failed at peer: %s",
> + op_common_strerror(op_common.status));
>   goto err;
>   }
>  
> diff --git a/tools/usb/usbip/src/usbip_network.h 
> b/tools/usb/usbip/src/usbip_network.h
> index c1e875c..86c3ff0 100644
> --- a/tools/usb/usbip/src/usbip_network.h
> +++ b/tools/usb/usbip/src/usbip_network.h
> @@ -27,8 +27,10 @@ struct op_common {
>   uint16_t code;
>  
>   /* add more error code */

codes instead of code

> -#define ST_OK0x00
> -#define ST_NA0x01
> +#define ST_OK0x00
> +#define ST_NA0x01
> +#define ST_NO_FREE_PORT  0x02
> +#define ST_DEVICE_NOT_FOUND  0x03

Maintain the indentation for the last entry.

>   uint32_t status; /* op_code status (for reply) */
>  
>  } __attribute__((packed));
> @@ -93,7 +95,6 @@ struct op_export_request {
>  } __attribute__((packed));
>  
>  struct op_export_reply {
> - int returncode;
>  } __attribute__((packed));
>  

Remove the empty structure.

>  
> @@ -115,7 +116,6 @@ struct op_unexport_request {
>  } __attribute__((packed));
>  
>  struct op_unexport_reply {
> - int returncode;
>  } __attribute__((packed));

Remove the empty structure.

>  
>  #define PACK_OP_UNEXPORT_REQUEST(pack, request)  do {\
> 

thanks,
-- Shuah
--
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 v14 02/10] usbip: exporting devices: modifications to host side libraries

[Shuah Khan]

On 12/26/2016 12:08 AM, Nobuo Iwata wrote:
> Modifications to host driver wrapper and its related operations (i.e. 
> bind/unbind).

Way too many changes in this one patch.

> 
> usbip_get_device() method was not used. The implementation of the 
> method searches a bound devices list by list index. The position in the 
> list is meaningless for any operations so it is assumed not to be used 
> in future.
> 
> For this patch set, a method to find a bound device in the bound 
> devices list by bus-id is needed. usbip_get_device() is re-implemented 
> as a function to find a bound device by bus-id.

This is not an accurate description. You are really changing look ups using
bus-id instead bus-num and whether usbip_get_device() is used or not is
irrelevant.

Please make changes to find bound device by bus-id in a separate patch.
You will have to change usbip_get_device() anyway because you are changing
.get_device() interface. Include exporting usbip_get_debice() in a separate
patch.

> 
> bind and unbind function are exported to reuse by new connect and 
> disconnect operation. Here, connect and disconnect is NEW-3 and NEW-4 
> respactively in diagram below.

Please don't include exporting bind_device() and unbind_device() and
changing their names in this patch. Send a separate patch for that.

It makes sense to move the functions you are exporting bind_device(),
unbind_device(), and usbip_get_device() to libsrc - usbip_common.c
might be a good choice.

The following isn't part of this patch, hence shouldn't be included in
the change log.

> 
> EXISTING) - invites devices from application(vhci)-side
>  +--+   +--+
>  device--+ STUB |   | application/VHCI |
>  +--+   +--+
>  (server)   (client)
>  1) # usbipd ... start daemon
>  = = =
>  2) # usbip list --local
>  3) # usbip bind
>   <--- list bound devices ---  4) # usbip list --remote
>   <--- import a device --  5) # usbip attach
>  = = =
>  X disconnected6) # usbip detach
>  7) usbip unbind
> 
> NEW) - dedicates devices from device(stub)-side
>  +--+   +--+
>  device--+ STUB |   | application/VHCI |
>  +--+   +--+
>  (client)   (server)
> 1) # usbipa ... start daemon
>  = = =
>  2) # usbip list --local
>  3) # usbip connect--- export a device -->
>  = = =
>  4) # usbip disconnect --- un-export a device --->
> 
>  Bind and unbind are done in connect and disconnect internally.
> 
> Signed-off-by: Nobuo Iwata 
> ---
>  tools/usb/usbip/libsrc/usbip_host_common.c | 6 ++
>  tools/usb/usbip/libsrc/usbip_host_common.h | 8 
>  tools/usb/usbip/src/usbip.h| 3 +++
>  tools/usb/usbip/src/usbip_bind.c   | 4 ++--
>  tools/usb/usbip/src/usbip_unbind.c | 4 ++--
>  5 files changed, 13 insertions(+), 12 deletions(-)
> 
> diff --git a/tools/usb/usbip/libsrc/usbip_host_common.c 
> b/tools/usb/usbip/libsrc/usbip_host_common.c
> index 9d41522..6a98d6c 100644
> --- a/tools/usb/usbip/libsrc/usbip_host_common.c
> +++ b/tools/usb/usbip/libsrc/usbip_host_common.c
> @@ -256,17 +256,15 @@ int usbip_export_device(struct usbip_exported_device 
> *edev, int sockfd)
>  }
>  
>  struct usbip_exported_device *usbip_generic_get_device(
> - struct usbip_host_driver *hdriver, int num)
> + struct usbip_host_driver *hdriver, char *busid)
>  {
>   struct list_head *i;
>   struct usbip_exported_device *edev;
> - int cnt = 0;
>  
>   list_for_each(i, &hdriver->edev_list) {
>   edev = list_entry(i, struct usbip_exported_device, node);
> - if (num == cnt)
> + if (!strncmp(busid, edev->udev.busid, SYSFS_BUS_ID_SIZE))

Use strlen(edev->udev.busid) instead of SYSFS_BUS_ID_SIZE

>   return edev;
> - cnt++;
>   }
>  
>   return NULL;
> diff --git a/tools/usb/usbip/libsrc/usbip_host_common.h 
> b/tools/usb/usbip/libsrc/usbip_host_common.h
> index a64b803..f9a9def 100644
> --- a/tools/usb/usbip/libsrc/usbip_host_common.h
> +++ b/tools/usb/usbip/libsrc/usbip_host_common.h
> @@ -38,7 +38,7 @@ struct usbip_host_driver_ops {
>   void (*close)(struct usbip_host_driver *hdriver);
>   int (*refresh_device_list)(struct usbip_host_driver *hdriver);
>   struct usbip_exported_device * (*get_device)(
> - struct usbip_host_driver *hdriver, int num);
> + struct usbip_host_driver *hdriver, char *busid);
>  
>   int (*read_device)(struct udev_device *sdev,
>  struct usbip_usb_device *dev);
> @@ -86,11 +86,11 @@ static inline int usbip_refres

Re: [PATCH v14 03/10] usbip: exporting devices: new connect operation

[Shuah Khan]

On 12/26/2016 12:08 AM, Nobuo Iwata wrote:
> Implementation of new connect operation. This is linked as a part of 
> usbip command. With this patch, usbip command has following operations.
> 
>  bind
>  unbind
>  list (local/remote)
>  attach
>  detach
>  port
>  connect ... this patch

Don't include existing commands. Just list the new one. Why do you call
this connect. Isn't it really export - connect isn't accurate. Call it
export/unexport.

> 
> In device side node, this binds a device internally, sends an export 
> request and receives export response. The definition of the request and 
> response are defined in original code: tools/usb/usbip/usbip_network.h 
> but was not used. They are corresponding to NEW-3 in following diagram. 
> 
> EXISTING) - invites devices from application(vhci)-side
>  +--+   +--+
>  device--+ STUB |   | application/VHCI |
>  +--+   +--+
>  (server)   (client)
>  1) # usbipd ... start daemon
>  = = =
>  2) # usbip list --local
>  3) # usbip bind
>   <--- list bound devices ---  4) # usbip list --remote
>   <--- import a device --  5) # usbip attach
>  = = =
>  X disconnected6) # usbip detach
>  7) usbip unbind
> 
> NEW) - dedicates devices from device(stub)-side
>  +--+   +--+
>  device--+ STUB |   | application/VHCI |
>  +--+   +--+
>  (client)   (server)

Make the left side server and right side client. I think you might be
using server and client network terminology. I would like to see server
as the system that has the device physically attached to.


I still want to see server as the one that is connected to the device.
It is just that in this new proposed model, server is exporting devices.

Also does usbip run here in user mode. Can any user run uspip and initiate
export? If so, I don't think I can take this patch series. I don't like to
see non root being able to export and/or make attached devices public.

> 1) # usbipa ... start daemon

Did you mean uspipd or is uspipa a new daemon? Okay now I see that
there is new daemon introduced in patch 7/10 - Why do you need to
add a new daemon? Why not add it to usbipd instead?

I would like to see all of this information in README. Including this
in every single patch is confusing. btw you are also missing doc changes
for these new options you are adding.

When you change README, please include the both server and client end
commands just like README does now.

>  = = =
>  2) # usbip list --local
>  3) # usbip connect--- export a device -->
>  = = =
>  4) # usbip disconnect --- un-export a device --->
> 
>  Bind and unbind are done in connect and disconnect internally.
> 
> Signed-off-by: Nobuo Iwata 
> ---
>  tools/usb/usbip/src/Makefile.am |   3 +-
>  tools/usb/usbip/src/usbip.c |   7 +
>  tools/usb/usbip/src/usbip.h |   3 +
>  tools/usb/usbip/src/usbip_connect.c | 212 
>  4 files changed, 224 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/usb/usbip/src/Makefile.am b/tools/usb/usbip/src/Makefile.am
> index e81a4eb..0947476 100644
> --- a/tools/usb/usbip/src/Makefile.am
> +++ b/tools/usb/usbip/src/Makefile.am
> @@ -6,6 +6,7 @@ sbin_PROGRAMS := usbip usbipd
>  
>  usbip_SOURCES := usbip.h utils.h usbip.c utils.c usbip_network.c \
>usbip_attach.c usbip_detach.c usbip_list.c \
> -  usbip_bind.c usbip_unbind.c usbip_port.c
> +  usbip_bind.c usbip_unbind.c usbip_port.c \
> +  usbip_connect.c
>  
>  usbipd_SOURCES := usbip_network.h usbipd.c usbip_network.c
> diff --git a/tools/usb/usbip/src/usbip.c b/tools/usb/usbip/src/usbip.c
> index d7599d9..ad2a259 100644
> --- a/tools/usb/usbip/src/usbip.c
> +++ b/tools/usb/usbip/src/usbip.c
> @@ -4,6 +4,7 @@
>   *
>   * Copyright (C) 2011 matt mooney 
>   *   2005-2007 Takahiro Hirofuchi
> + * Copyright (C) 2015-2016 Nobuo Iwata 
>   *
>   * This program is free software: you can redistribute it and/or modify
>   * it under the terms of the GNU General Public License as published by
> @@ -76,6 +77,12 @@ static const struct command cmds[] = {
>   .usage = usbip_detach_usage
>   },
>   {
> + .name  = "connect",
> + .fn= usbip_connect,
> + .help  = "Connect a USB device to a remote computer",
> + .usage = usbip_connect_usage
> + },
> + {
>   .name  = "list",
>   .fn= usbip_list,
>   .help  = "List exportable or local USB devices",
> diff --git a/tools/usb/usbip/src/usbip.h b/tools/usb/usbip/src/

Re: [PATCH v14 04/10] usbip: exporting devices: new disconnect operation

[Shuah Khan]

On 12/26/2016 12:08 AM, Nobuo Iwata wrote:
> Implementation of new disconnect operation. This is linked as a part of 
> usbip command. With this patch, usbip command has following operations.
> 
>  bind
>  unbind
>  list (local/remote)
>  attach
>  detach
>  port
>  connect ... previous patch
>  disconnect ... this patch
> 
> In device side node, this sends an un-export request, receives an 
> un-export response and unbind corresponding device internally. The 
> definition of the request and response are defined in original code: 
> tools/usb/usbip/usbip_network.h but was not used. It's corresponding to 
> NEW-4 in following diagram.
> 
> To find disconnecting device, requesting host and requested 
> bus-id-in-requester identifies the target. So it cannot to disconnect a 
> device from other host than a host which connected the device. 

Please see review comments on patch 3/10 - all of those apply for this
patch.

> 
> EXISTING) - invites devices from application(vhci)-side
>  +--+   +--+
>  device--+ STUB |   | application/VHCI |
>  +--+   +--+
>  (server)   (client)
>  1) # usbipd ... start daemon
>  = = =
>  2) # usbip list --local
>  3) # usbip bind
>   <--- list bound devices ---  4) # usbip list --remote
>   <--- import a device --  5) # usbip attach
>  = = =
>  X disconnected6) # usbip detach
>  7) usbip unbind
> 
> NEW) - dedicates devices from device(stub)-side
>  +--+   +--+
>  device--+ STUB |   | application/VHCI |
>  +--+   +--+
>  (client)   (server)
> 1) # usbipa ... start daemon
>  = = =
>  2) # usbip list --local
>  3) # usbip connect--- export a device -->
>  = = =
>  4) # usbip disconnect --- un-export a device --->
> 
>  Bind and unbind are done in connect and disconnect internally.
> 
> Signed-off-by: Nobuo Iwata 
> ---
>  tools/usb/usbip/src/Makefile.am|   2 +-
>  tools/usb/usbip/src/usbip.c|   6 +
>  tools/usb/usbip/src/usbip.h|   2 +
>  tools/usb/usbip/src/usbip_disconnect.c | 200 +
>  4 files changed, 209 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/usb/usbip/src/Makefile.am b/tools/usb/usbip/src/Makefile.am
> index 0947476..42760c3 100644
> --- a/tools/usb/usbip/src/Makefile.am
> +++ b/tools/usb/usbip/src/Makefile.am
> @@ -7,6 +7,6 @@ sbin_PROGRAMS := usbip usbipd
>  usbip_SOURCES := usbip.h utils.h usbip.c utils.c usbip_network.c \
>usbip_attach.c usbip_detach.c usbip_list.c \
>usbip_bind.c usbip_unbind.c usbip_port.c \
> -  usbip_connect.c
> +  usbip_connect.c usbip_disconnect.c
>  
>  usbipd_SOURCES := usbip_network.h usbipd.c usbip_network.c
> diff --git a/tools/usb/usbip/src/usbip.c b/tools/usb/usbip/src/usbip.c
> index ad2a259..ead88a2 100644
> --- a/tools/usb/usbip/src/usbip.c
> +++ b/tools/usb/usbip/src/usbip.c
> @@ -83,6 +83,12 @@ static const struct command cmds[] = {
>   .usage = usbip_connect_usage
>   },
>   {
> + .name  = "disconnect",
> + .fn= usbip_disconnect,
> + .help  = "Disconnect a USB device from a remote computer",
> + .usage = usbip_disconnect_usage
> + },
> + {
>   .name  = "list",
>   .fn= usbip_list,
>   .help  = "List exportable or local USB devices",
> diff --git a/tools/usb/usbip/src/usbip.h b/tools/usb/usbip/src/usbip.h
> index 3c22c27..b6537ef 100644
> --- a/tools/usb/usbip/src/usbip.h
> +++ b/tools/usb/usbip/src/usbip.h
> @@ -32,6 +32,7 @@ int usbip_bind(int argc, char *argv[]);
>  int usbip_unbind(int argc, char *argv[]);
>  int usbip_port_show(int argc, char *argv[]);
>  int usbip_connect(int argc, char *argv[]);
> +int usbip_disconnect(int argc, char *argv[]);
>  
>  void usbip_attach_usage(void);
>  void usbip_detach_usage(void);
> @@ -39,6 +40,7 @@ void usbip_list_usage(void);
>  void usbip_bind_usage(void);
>  void usbip_unbind_usage(void);
>  void usbip_connect_usage(void);
> +void usbip_disconnect_usage(void);
>  
>  int usbip_bind_device(char *busid);
>  int usbip_unbind_device(char *busid);
> diff --git a/tools/usb/usbip/src/usbip_disconnect.c 
> b/tools/usb/usbip/src/usbip_disconnect.c
> new file mode 100644
> index 000..4ee7feb
> --- /dev/null
> +++ b/tools/usb/usbip/src/usbip_disconnect.c
> @@ -0,0 +1,200 @@
> +/*
> + * Copyright (C) 2011 matt mooney 
> + *   2005-2007 Takahiro Hirofuchi
> + * Copyright (C) 2015-2016 Nobuo Iwata 
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it un

Re: [PATCH v14 09/10] usbip: exporting devices: chage to documenattion

[Shuah Khan]

On 12/26/2016 12:08 AM, Nobuo Iwata wrote:
> This patch adds function and usage of new connect operation, disconnect 
> operation and application(vhci)-side daemon to README and manuals.

This should be the first patch for the series. That would have saved
me lot of time. Please move this patch up.

> 
> At this point, the wording, 'server' and 'client' are ambiguous in 
> several place.
> 
> For existing attach command, the daemon runs device side machine and 
> attach command is executed in application side machine. Then 'server' 
> is used for device side and 'client' is for application side.
> 
> For the new connect command, the daemon runs applications side machine 
> and connect command is executed in device side machine. Now, 'server' 
> and 'client' run in different machine than before.
> 
> To avoid confusion, to represent things to be done in device side node 
> by both command and daemon, words 'device-side' is used instead of 
> 'server'. To represent things to be done is application side node by 
> both command and daemon, 'applicationr-side' are used instead of 
> 'client'.
> 
> EXISTING) - invites devices from application(vhci)-side
>  +--+   +--+
>  device--+ STUB |   | application/VHCI |
>  +--+   +--+
>  (server)   (client)
>  1) # usbipd ... start daemon
>  = = =
>  2) # usbip list --local
>  3) # usbip bind
>   <--- list bound devices ---  4) # usbip list --remote
>   <--- import a device --  5) # usbip attach
>  = = =
>  X disconnected6) # usbip detach
>  7) usbip unbind
> 
> NEW) - dedicates devices from device(stub)-side
>  +--+   +--+
>  device--+ STUB |   | application/VHCI |
>  +--+   +--+
>  (client)   (server)
> 1) # usbipa ... start daemon

Make the left side server and right side client. I think you might be
using server and client network terminology. I would like to see server
as the system that has the device physically attached to.


I still want to see server as the one that is connected to the device.
It is just that in this new proposed model, server is exporting devices.

Also does usbip run here in user mode. Can any user run uspip and initiate
export? If so, I don't think I can take this patch series. I don't like to
see non root being able to export and/or make attached devices public.

>  = = =
>  2) # usbip list --local
>  3) # usbip connect--- export a device -->
>  = = =
>  4) # usbip disconnect --- un-export a device --->
> 
>  Bind and unbind are done in connect and disconnect internally.
> 
> Signed-off-by: Nobuo Iwata 
> ---
>  tools/usb/usbip/Makefile.am  |   2 +-
>  tools/usb/usbip/README   |  81 -
>  tools/usb/usbip/doc/usbip.8  | 136 ---
>  tools/usb/usbip/doc/usbipa.8 |  78 
>  tools/usb/usbip/doc/usbipd.8 |  38 +-
>  5 files changed, 275 insertions(+), 60 deletions(-)
> 
> diff --git a/tools/usb/usbip/Makefile.am b/tools/usb/usbip/Makefile.am
> index 66f8bf0..f371ed9 100644
> --- a/tools/usb/usbip/Makefile.am
> +++ b/tools/usb/usbip/Makefile.am
> @@ -3,4 +3,4 @@ includedir = @includedir@/usbip
>  include_HEADERS := $(addprefix libsrc/, \
>usbip_common.h vhci_driver.h usbip_host_driver.h)
>  
> -dist_man_MANS := $(addprefix doc/, usbip.8 usbipd.8)
> +dist_man_MANS := $(addprefix doc/, usbip.8 usbipd.8 usbipa.8)
> diff --git a/tools/usb/usbip/README b/tools/usb/usbip/README
> index 831f49f..d3cae75 100644
> --- a/tools/usb/usbip/README
> +++ b/tools/usb/usbip/README
> @@ -3,6 +3,7 @@
>  #
>  # Copyright (C) 2011 matt mooney 
>  #   2005-2008 Takahiro Hirofuchi
> +# Copyright (C) 2015-2016 Nobuo Iwata 
>  
>  
>  [Requirements]
> @@ -36,41 +37,70 @@
>  
>  
>  [Usage]
> -server:# (Physically attach your USB device.)
> +Device-side: a machine has USB device(s).
> +Application-side: a machine runs an application software uses remote USB 
> device.
>  
> -server:# insmod usbip-core.ko
> -server:# insmod usbip-host.ko
> +1) Connect from application-side to device-side.
>  
> -server:# usbipd -D
> +dev:# (Physically attach your USB device.)
> +
> +dev:# insmod usbip-core.ko
> +dev:# insmod usbip-host.ko
> +
> +dev:# usbipd -D
>   - Start usbip daemon.
>  
> -server:# usbip list -l
> - - List driver assignments for USB devices.
> +dev:# usbip list -l
> + - List driver assignments for USB devices and their busid.
>  
> -server:# usbip bind --busid 1-2
> - - Bind usbip-host.ko to the device with busid 1-2.
> - - The USB dev

Re: [PATCH v14 02/10] usbip: exporting devices: modifications to host side libraries

[Shuah Khan]

On 01/13/2017 04:55 AM, Krzysztof Opasiak wrote:
> 
> 
> On 01/12/2017 10:14 PM, Shuah Khan wrote:
>> On 12/26/2016 12:08 AM, Nobuo Iwata wrote:
>>> Modifications to host driver wrapper and its related operations (i.e. 
>>> bind/unbind).
>>
>> Way too many changes in this one patch.
>>
>>>
>>> usbip_get_device() method was not used. The implementation of the 
>>> method searches a bound devices list by list index. The position in the 
>>> list is meaningless for any operations so it is assumed not to be used 
>>> in future.
>>>
>>> For this patch set, a method to find a bound device in the bound 
>>> devices list by bus-id is needed. usbip_get_device() is re-implemented 
>>> as a function to find a bound device by bus-id.
>>
>> This is not an accurate description. You are really changing look ups using
>> bus-id instead bus-num and whether usbip_get_device() is used or not is
>> irrelevant.
>>
>> Please make changes to find bound device by bus-id in a separate patch.
>> You will have to change usbip_get_device() anyway because you are changing
>> .get_device() interface. Include exporting usbip_get_debice() in a separate
>> patch.
>>
>>>
>>> bind and unbind function are exported to reuse by new connect and 
>>> disconnect operation. Here, connect and disconnect is NEW-3 and NEW-4 
>>> respactively in diagram below.
>>
>> Please don't include exporting bind_device() and unbind_device() and
>> changing their names in this patch. Send a separate patch for that.
>>
>> It makes sense to move the functions you are exporting bind_device(),
>> unbind_device(), and usbip_get_device() to libsrc - usbip_common.c
>> might be a good choice.
>>
>> The following isn't part of this patch, hence shouldn't be included in
>> the change log.
>>
>>>
>>> EXISTING) - invites devices from application(vhci)-side
>>>  +--+   +--+
>>>  device--+ STUB |   | application/VHCI |
>>>  +--+   +--+
>>>  (server)   (client)
>>>  1) # usbipd ... start daemon
>>>  = = =
>>>  2) # usbip list --local
>>>  3) # usbip bind
>>>   <--- list bound devices ---  4) # usbip list --remote
>>>   <--- import a device --  5) # usbip attach
>>>  = = =
>>>  X disconnected6) # usbip detach
>>>  7) usbip unbind
>>>
>>> NEW) - dedicates devices from device(stub)-side
>>>  +--+   +--+
>>>  device--+ STUB |   | application/VHCI |
>>>  +--+   +--+
>>>  (client)   (server)
>>> 1) # usbipa ... start daemon
>>>  = = =
>>>  2) # usbip list --local
>>>  3) # usbip connect--- export a device -->
>>>  = = =
>>>  4) # usbip disconnect --- un-export a device --->
>>>
>>>  Bind and unbind are done in connect and disconnect internally.
>>>
>>> Signed-off-by: Nobuo Iwata 
>>> ---
>>>  tools/usb/usbip/libsrc/usbip_host_common.c | 6 ++
>>>  tools/usb/usbip/libsrc/usbip_host_common.h | 8 
>>>  tools/usb/usbip/src/usbip.h| 3 +++
>>>  tools/usb/usbip/src/usbip_bind.c   | 4 ++--
>>>  tools/usb/usbip/src/usbip_unbind.c | 4 ++--
>>>  5 files changed, 13 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/tools/usb/usbip/libsrc/usbip_host_common.c 
>>> b/tools/usb/usbip/libsrc/usbip_host_common.c
>>> index 9d41522..6a98d6c 100644
>>> --- a/tools/usb/usbip/libsrc/usbip_host_common.c
>>> +++ b/tools/usb/usbip/libsrc/usbip_host_common.c
>>> @@ -256,17 +256,15 @@ int usbip_export_device(struct usbip_exported_device 
>>> *edev, int sockfd)
>>>  }
>>>  
>>>  struct usbip_exported_device *usbip_generic_get_device(
>>> -   struct usbip_host_driver *hdriver, int num)
>>> +   struct usbip_host_driver *hdriver, char *busid)
>>>  {
>>> struct list_head *i;
>>> struct usbip_exported_device *edev;
>>> -   int cnt = 0;
>>>  
>>> list_for_each(i,

[PATCH] tools: usb usbip - update README USB/IP driver location

[Shuah Khan]

Update USB/IP driver location in README.

Signed-off-by: Shuah Khan 
---
 tools/usb/usbip/README | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/usb/usbip/README b/tools/usb/usbip/README
index 831f49f..f349ef4 100644
--- a/tools/usb/usbip/README
+++ b/tools/usb/usbip/README
@@ -7,7 +7,7 @@
 
 [Requirements]
 - USB/IP device drivers
-   Found in the staging directory of the Linux kernel.
+   Found in the drivers/usb/usbip directory of the Linux kernel.
 
 - libudev >= 2.0
libudev library
-- 
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] usb: dwc3 dwc3_exynos_probe() change goto labels to meaningful names

[Shuah Khan]

On 01/16/2017 03:33 AM, Felipe Balbi wrote:
> 
> Hi,
> 
> Shuah Khan  writes:
>> Change goto labels to meaningful names from a series of errNs.
>>
>> Signed-off-by: Shuah Khan 
> 
> doesn't apply to testing/next, please rebase.
> 

Hi Felipe,

This patch is dependent on the

usb: dwc3: exynos fix axius clock error path to do cleanup
https://lkml.org/lkml/2017/1/10/1081

The above made it into usb-linus. It will apply to usb-next
or usb-testing after it gets merged. I can resend it after
the dependent patch makes it into the next rc release.

thanks,
-- Shuah


--
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] tools: usb usbip - update README USB/IP driver location

[Shuah Khan]

On 01/19/2017 02:35 AM, Greg KH wrote:
> On Fri, Jan 13, 2017 at 04:38:32PM -0700, Shuah Khan wrote:
>> Update USB/IP driver location in README.
>>
>> Signed-off-by: Shuah Khan 
>> Reviewed-by: Krzysztof Opasiak 
>> ---
>>  tools/usb/usbip/README | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tools/usb/usbip/README b/tools/usb/usbip/README
>> index 831f49f..f349ef4 100644
>> --- a/tools/usb/usbip/README
>> +++ b/tools/usb/usbip/README
>> @@ -7,7 +7,7 @@
>>  
>>  [Requirements]
>>  - USB/IP device drivers
>> -Found in the staging directory of the Linux kernel.
>> +Found in the drivers/usb/usbip directory of the Linux kernel.
>>  
>>  - libudev >= 2.0
>>  libudev library
>> -- 
>> 2.7.4
> 
> Fails to apply to my usb-next branch :(
> 

Sorry about that. I will rebase and resend the patch.

thanks,
-- Shuah
--
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] tools: usb usbip - update README USB/IP driver location

[Shuah Khan]

On 01/19/2017 07:15 AM, Shuah Khan wrote:
> On 01/19/2017 02:35 AM, Greg KH wrote:
>> On Fri, Jan 13, 2017 at 04:38:32PM -0700, Shuah Khan wrote:
>>> Update USB/IP driver location in README.
>>>
>>> Signed-off-by: Shuah Khan 
>>> Reviewed-by: Krzysztof Opasiak 
>>> ---
>>>  tools/usb/usbip/README | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/tools/usb/usbip/README b/tools/usb/usbip/README
>>> index 831f49f..f349ef4 100644
>>> --- a/tools/usb/usbip/README
>>> +++ b/tools/usb/usbip/README
>>> @@ -7,7 +7,7 @@
>>>  
>>>  [Requirements]
>>>  - USB/IP device drivers
>>> -   Found in the staging directory of the Linux kernel.
>>> +   Found in the drivers/usb/usbip directory of the Linux kernel.

This is already fixed in usb-next. My bad. Sorry for the noise.

>>>  
>>>  - libudev >= 2.0
>>> libudev library
>>> -- 
>>> 2.7.4
>>

thanks,
-- Shuah

--
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: USB Sound oops in Linus's latest tree

[Shuah Khan]

On Fri, Mar 18, 2016 at 4:26 PM,
Greg KH  wrote:
> Hi,
>
> I'm getting the following oops with my USB sound device using Linus's
> latest tree of the moment, which has the sound tree pull in it.  Anyone
> seen this before?
>

Hi Greg,

Nicolai Stange sent in a fix for this problem - I can't find the link to this.
It is coming in through Linux Media tree.

thanks,
-- Shuah

The patch:

With commit

  aebb2b89bff0 ("[media] sound/usb: Use Media Controller API to share
 media resources")

an access to quirk->media_device without checking for quirk != NULL has
been introduced in usb_audio_probe().

With a Plantronics USB headset (device ID 0x047f:0xc010) attached,
this results in the following splat at boot time:

  BUG: unable to handle kernel NULL pointer dereference at 0014
  IP: [] usb_audio_probe+0x2cc/0x9a0 [snd_usb_audio]
  Oops:  [#1] SMP
  [...]
  CPU: 2 PID: 696 Comm: systemd-udevd Not tainted 4.5.0-next-20160315 #13
  Hardware name: Dell Inc. Latitude E6540/0725FP, BIOS A10 06/26/2014
  task: 88021c88d7c0 ti: 88003d5b task.ti: 88003d5b
  RIP: 0010:[]  []
usb_audio_probe+0x2cc/0x9a0 [snd_usb_audio]
  [...]
  Call Trace:
   [] usb_probe_interface+0x136/0x2d0
   [] driver_probe_device+0x22c/0x440
   [] __driver_attach+0xd1/0xf0
   [] ? driver_probe_device+0x440/0x440
   [] bus_for_each_dev+0x6c/0xc0
   [] driver_attach+0x1e/0x20
   [] bus_add_driver+0x1c3/0x280
   [] driver_register+0x60/0xe0
   [] usb_register_driver+0x81/0x140
   [] ? 0xa08c7000
   [] usb_audio_driver_init+0x1e/0x1000 [snd_usb_audio]
   [] do_one_initcall+0xb3/0x1f0
   [] ? __vunmap+0x81/0xd0
   [] ? kmem_cache_alloc_trace+0x182/0x1d0
   [] ? do_init_module+0x27/0x1d8
   [] do_init_module+0x5f/0x1d8
   [] load_module+0x1fe5/0x27a0
   [] ? __symbol_put+0x60/0x60
   [] ? vfs_read+0x110/0x130
   [] SYSC_finit_module+0xe6/0x120
   [] SyS_finit_module+0xe/0x10
   [] do_syscall_64+0x64/0x110
   [] entry_SYSCALL64_slow_path+0x25/0x25

After encountering this, the system-udevd process seems to be blocked
until it is killed when hitting its timeout of 3min.

In analogy to the other accesses to members of quirk in usb_audio_probe(),
check for quirk != NULL before accessing its ->media_device.

Fixes: aebb2b89bff0 ("[media] sound/usb: Use Media Controller API to share
  media resources")
Signed-off-by: Nicolai Stange 
---
 Applicable to linux-next-20160315.

 sound/usb/card.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/usb/card.c b/sound/usb/card.c
index 63244bb..479621e 100644
--- a/sound/usb/card.c
+++ b/sound/usb/card.c
@@ -612,7 +612,7 @@ static int usb_audio_probe(struct usb_interface *intf,
  if (err < 0)
  goto __error;

- if (quirk->media_device) {
+ if (quirk && quirk->media_device) {
  /* don't want to fail when media_snd_device_create() fails */
  media_snd_device_create(chip, intf);
  }
-- 
2.7.2



>
> [  +0.002298] input: Schiit Audio USB Modi Device as 
> /devices/pci:00/:00:14.0/usb2/2-10/2-10.1/2-10.1:1.2/0003:0D8C:1319.0001/input/input17
> [  +0.56] hid-generic 0003:0D8C:1319.0001: input,hidraw0: USB HID v1.00 
> Device [Schiit Audio USB Modi Device] on usb-:00:14.0-10.1/input2
> [  +0.008749] BUG: unable to handle kernel NULL pointer dereference at 
> 0014
> [  +0.001151] IP: [] usb_audio_probe+0x1e1/0x8f0 
> [snd_usb_audio]
> [  +0.001142] PGD 0
> [  +0.001114] Oops:  [#1] PREEMPT SMP
> [  +0.001115] Modules linked in: snd_usb_audio(+) hid_generic snd_usbmidi_lib 
> usbhid snd_rawmidi snd_seq_device hid media arc4 fuse btusb btrtl btbcm 
> btintel bluetooth rt2800usb rt2x00usb rt2800lib rt2x00lib mac80211 crc_ccitt 
> cfg80211 rfkill nls_cp437 vfat fat iTCO_wdt iTCO_vendor_support mxm_wmi 
> x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass 
> crct10dif_pclmul crct10dif_common crc32_pclmul crc32c_intel 
> ghash_clmulni_intel aesni_intel aes_x86_64 glue_helper lrw gf128mul 
> ablk_helper cryptd psmouse serio_raw pcspkr firewire_ohci firewire_core 
> crc_itu_t xhci_pci ehci_pci xhci_hcd ehci_hcd mei_me usbcore mei lpc_ich 
> mfd_core usb_common wmi evdev ip_tables x_tables
> [  +0.004079] CPU: 4 PID: 615 Comm: systemd-udevd Not tainted 4.6.0-rc1+ #103
> [  +0.001382] Hardware name:  /, BIOS 
> KLZ8711D.86A.0457.2015.0713.1319 07/13/2015
> [  +0.001387] task: 880098ec0e00 ti: 88025192 task.ti: 
> 88025192
> [  +0.001417] RIP: 0010:[]  [] 
> usb_audio_probe+0x1e1/0x8f0 [snd_usb_audio]
> [  +0.001414] RSP: 0018:880251923af0  EFLAGS: 00010246
> [  +0.001409] RAX:  RBX: 88024d602000 RCX: 
> 
> [  +0.001404] RDX: 880254e0b340 RSI: 8802559b99f8 RDI: 
> 82181030
>

[PATCH] usb: dwc3 dwc3_exynos_probe() change goto labels to meaningful names

[Shuah Khan]

Change goto labels to meaningful names from a series of errNs.

Signed-off-by: Shuah Khan 
---

Rebased to usb-next

 drivers/usb/dwc3/dwc3-exynos.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index 1515d45..98f74ff 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -147,53 +147,53 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
exynos->vdd33 = devm_regulator_get(dev, "vdd33");
if (IS_ERR(exynos->vdd33)) {
ret = PTR_ERR(exynos->vdd33);
-   goto err2;
+   goto vdd33_err;
}
ret = regulator_enable(exynos->vdd33);
if (ret) {
dev_err(dev, "Failed to enable VDD33 supply\n");
-   goto err2;
+   goto vdd33_err;
}
 
exynos->vdd10 = devm_regulator_get(dev, "vdd10");
if (IS_ERR(exynos->vdd10)) {
ret = PTR_ERR(exynos->vdd10);
-   goto err3;
+   goto vdd10_err;
}
ret = regulator_enable(exynos->vdd10);
if (ret) {
dev_err(dev, "Failed to enable VDD10 supply\n");
-   goto err3;
+   goto vdd10_err;
}
 
ret = dwc3_exynos_register_phys(exynos);
if (ret) {
dev_err(dev, "couldn't register PHYs\n");
-   goto err4;
+   goto phys_err;
}
 
if (node) {
ret = of_platform_populate(node, NULL, NULL, dev);
if (ret) {
dev_err(dev, "failed to add dwc3 core\n");
-   goto err5;
+   goto populate_err;
}
} else {
dev_err(dev, "no device node, failed to add dwc3 core\n");
ret = -ENODEV;
-   goto err5;
+   goto populate_err;
}
 
return 0;
 
-err5:
+populate_err:
platform_device_unregister(exynos->usb2_phy);
platform_device_unregister(exynos->usb3_phy);
-err4:
+phys_err:
regulator_disable(exynos->vdd10);
-err3:
+vdd10_err:
regulator_disable(exynos->vdd33);
-err2:
+vdd33_err:
clk_disable_unprepare(exynos->axius_clk);
 axius_clk_err:
clk_disable_unprepare(exynos->susp_clk);
-- 
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] drivers: usb: usbip: Add missing break statement to switch

[Shuah Khan]

On 02/09/2017 12:49 AM, Gustavo A. R. Silva wrote:
> Add missing break statement to prevent the code for case
> USB_PORT_FEAT_C_RESET falling through to the default case.
> 
> Addresses-Coverity-ID: 143155
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/usb/usbip/vhci_hcd.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
> index c4724fb..e4cb9f0 100644
> --- a/drivers/usb/usbip/vhci_hcd.c
> +++ b/drivers/usb/usbip/vhci_hcd.c
> @@ -313,6 +313,7 @@ static int vhci_hub_control(struct usb_hcd *hcd, u16 
> typeReq, u16 wValue,
>   default:
>   break;
>   }
> + break;
>   default:
>   usbip_dbg_vhci_rh(" ClearPortFeature: default %x\n",
>     wValue);
> 


Looks good to me.

Acked-by: Shuah Khan 

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

Re: [PATCH v4 1/2] usbip: Fix-format-overflow

[Shuah Khan]

On 02/27/2017 01:31 AM, Jonathan Dieter wrote:
> The usbip userspace tools call sprintf()/snprintf() and don't check for
> the return value which can lead the paths to overflow, truncating the
> final file in the path.
> 
> More urgently, GCC 7 now warns that these aren't checked with
> -Wformat-overflow, and with -Werror enabled in configure.ac, that makes
> these tools unbuildable.
> 
> This patch fixes these problems by replacing sprintf() with snprintf() in
> one place and adding checks for the return value of snprintf().
> 
> Reviewed-by: Peter Senna Tschudin 
> Signed-off-by: Jonathan Dieter 

Greg,

Please pick this up.

Acked-by: Shuah Khan 

thanks,
-- Shuah

> ---
> Changes since v3
>  * Cast sizeof to long unsigned when printing errors to fix building for 
> 32-bit
>architectures
> 
>  tools/usb/usbip/libsrc/usbip_common.c  |  9 -
>  tools/usb/usbip/libsrc/usbip_host_common.c | 28 +++-
>  2 files changed, 31 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/usb/usbip/libsrc/usbip_common.c 
> b/tools/usb/usbip/libsrc/usbip_common.c
> index ac73710..1517a23 100644
> --- a/tools/usb/usbip/libsrc/usbip_common.c
> +++ b/tools/usb/usbip/libsrc/usbip_common.c
> @@ -215,9 +215,16 @@ int read_usb_interface(struct usbip_usb_device *udev, 
> int i,
>  struct usbip_usb_interface *uinf)
>  {
>   char busid[SYSFS_BUS_ID_SIZE];
> + int size;
>   struct udev_device *sif;
>  
> - sprintf(busid, "%s:%d.%d", udev->busid, udev->bConfigurationValue, i);
> + size = snprintf(busid, sizeof(busid), "%s:%d.%d",
> + udev->busid, udev->bConfigurationValue, i);
> + if (size < 0 || (unsigned int)size >= sizeof(busid)) {
> + err("busid length %i >= %lu or < 0", size,
> + (long unsigned)sizeof(busid));
> + return -1;
> + }
>  
>   sif = udev_device_new_from_subsystem_sysname(udev_context, "usb", 
> busid);
>   if (!sif) {
> diff --git a/tools/usb/usbip/libsrc/usbip_host_common.c 
> b/tools/usb/usbip/libsrc/usbip_host_common.c
> index 9d41522..6ff7b60 100644
> --- a/tools/usb/usbip/libsrc/usbip_host_common.c
> +++ b/tools/usb/usbip/libsrc/usbip_host_common.c
> @@ -40,13 +40,20 @@ struct udev *udev_context;
>  static int32_t read_attr_usbip_status(struct usbip_usb_device *udev)
>  {
>   char status_attr_path[SYSFS_PATH_MAX];
> + int size;
>   int fd;
>   int length;
>   char status;
>   int value = 0;
>  
> - snprintf(status_attr_path, SYSFS_PATH_MAX, "%s/usbip_status",
> -  udev->path);
> + size = snprintf(status_attr_path, sizeof(status_attr_path),
> + "%s/usbip_status", udev->path);
> + if (size < 0 || (unsigned int)size >= sizeof(status_attr_path)) {
> + err("usbip_status path length %i >= %lu or < 0", size,
> + (long unsigned)sizeof(status_attr_path));
> + return -1;
> + }
> +
>  
>   fd = open(status_attr_path, O_RDONLY);
>   if (fd < 0) {
> @@ -218,6 +225,7 @@ int usbip_export_device(struct usbip_exported_device 
> *edev, int sockfd)
>  {
>   char attr_name[] = "usbip_sockfd";
>   char sockfd_attr_path[SYSFS_PATH_MAX];
> + int size;
>   char sockfd_buff[30];
>   int ret;
>  
> @@ -237,10 +245,20 @@ int usbip_export_device(struct usbip_exported_device 
> *edev, int sockfd)
>   }
>  
>   /* only the first interface is true */
> - snprintf(sockfd_attr_path, sizeof(sockfd_attr_path), "%s/%s",
> -  edev->udev.path, attr_name);
> + size = snprintf(sockfd_attr_path, sizeof(sockfd_attr_path), "%s/%s",
> + edev->udev.path, attr_name);
> + if (size < 0 || (unsigned int)size >= sizeof(sockfd_attr_path)) {
> + err("exported device path length %i >= %lu or < 0", size,
> + (long unsigned)sizeof(sockfd_attr_path));
> + return -1;
> + }
>  
> - snprintf(sockfd_buff, sizeof(sockfd_buff), "%d\n", sockfd);
> + size = snprintf(sockfd_buff, sizeof(sockfd_buff), "%d\n", sockfd);
> + if (size < 0 || (unsigned int)size >= sizeof(sockfd_buff)) {
> + err("socket length %i >= %lu or < 0", size,
> + (long unsigned)sizeof(sockfd_buff));
> + return -1;
> + }
>  
>   ret = write_sysfs_attribute(sockfd_attr_path, sockfd_buff,
>   strlen(sockfd_buff));
> 

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