[PATCH 1/2] USB: turn off padding of resume time delays

Add a module parameter that replaces the USB_RESUME_TIMEOUT and other hardcoded delay numbers with the USB spec minimums. By default the patch retains the current values. The USB subsystem currently uses heavily padded values for TDRSMDN and TRSTRCY. This patch keeps the current values by

[PATCH 2/2] USB: resume timing debug

Add debug support for experimenting with USB timing delay values on the fly. This provides a debug interface through /sys/kernel/usb where a user can tweak the values. The code enforces the spec minimums so that a user can't set them too low. Signed-off-by: Todd Brandt

[PATCH 0/2] USB: resume time optimization by using spec minimums

The USB resume code in the kernel currently uses a set of hard coded delay values that are defined in the USB 2.0 spec. Specifically these three have the most effect on resume time: - tdrsmdn: resume signal time (20ms - infinity) usb 2.0 spec 7.1.7.7 - trsmrcy: resume recovery time (10ms) usb

Re: [PATCH] usb: dwc2: fix flags for DMA descriptor allocation in dwc2_hsotg_ep_enable

On 12/1/2016 1:02 AM, Marek Szyprowski wrote: > dwc2_hsotg_ep_enable can be called from interrupt context, so all > allocations should be done with GFP_ATOMIC flags. This fixes following > issue on ARM architecture: > > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > [] (show_stack) from

Re: [RFC][PATCH 1/3] phy: phy-hi6220-usb: Wire up extconn support to hikey's phy driver

On 12/1/2016 12:12 PM, John Stultz wrote: > On Thu, Dec 1, 2016 at 12:23 AM, Kishon Vijay Abraham I wrote: >> Hi, >> >> On Wednesday 23 November 2016 09:16 AM, John Stultz wrote: >>> This wires extconn support to hikey's phy driver, and >>> connects it to the usb UDC layer via a

Re: [PATCH v5 1/6] usb: separate out sysdev pointer from usb_bus

Hi all, On Thu, Nov 17, 2016 at 05:13:43PM +0530, Sriram Dash wrote: > From: Arnd Bergmann > > For xhci-hcd platform device, all the DMA parameters are not > configured properly, notably dma ops for dwc3 devices. > > The idea here is that you pass in the parent of_node along

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

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

Re: [PATCH] usb: gadget: uvc: fix UVC_ATTR macro for UVCG_OPTS_ATTR

On Friday 02 Dec 2016 07:56:32 Greg KH wrote: > On Fri, Dec 02, 2016 at 11:52:02AM +0530, Jassi Brar wrote: > > From: Jassi Brar > > > > Typo in commit 76e0da34c7cec5a7d introduced a bug that prevents > > creation of streaming_{interval,maxpacket,maxburst} nodes for >

Re: [PATCH] USB: OHCI: ohci-omap: remove useless functions

On Fri, 2 Dec 2016 csmanjuvi...@gmail.com wrote: > From: Manjunath Goudar > > The ohci_hcd_omap_drv_probe and ohci_hcd_omap_drv_remove > functions are removed as these are useless functions except calling > usb_hcd_omap_probe and usb_hcd_omap_remove functions. > > The

Re: [PATCH] usb: hub: Wait for connection to be reestablished after port reset

On Thu, 1 Dec 2016, Guenter Roeck wrote: > On a system with a defective USB device connected to an USB hub, > an endless sequence of port connect events was observed. The sequence > of events as observed is as follows: > > - Port reports connected event (port status=USB_PORT_STAT_CONNECTION). >

Re: [PATH net v2] cdc_ether: Fix handling connection notification

From: Kristian Evensen Date: Thu, 1 Dec 2016 14:23:17 +0100 > Commit bfe9b9d2df66 ("cdc_ether: Improve ZTE MF823/831/910 handling") > introduced a work-around in usbnet_cdc_status() for devices that exported > cdc carrier on twice on connect. Before the commit, this

Re: [PATCHv13 2/3] usb: USB Type-C connector class

On Fri, Dec 02, 2016 at 10:04:39AM -0800, Guenter Roeck wrote: > The driver interface is not my area of expertise. As such, my testing > and understanding of that part was limited to "it appears to work, > it must be ok". I very much relied on you to get this part right. > > That makes me feel

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

Dear all, On 11/22/2016 07:48 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. > > 1. Goal > > 1-1) To give flexibility to direction of connection > Using

Re: [PATCHv13 2/3] usb: USB Type-C connector class

On Wed, Nov 30, 2016 at 11:19:10AM +0200, Heikki Krogerus wrote: > Hi Greg, > > On Tue, Nov 29, 2016 at 05:27:44PM +0100, Greg KH wrote: > > > +struct typec_cable { > > > + struct device dev; > > > + enum typec_plug_typetype; > > > + u32 vdo; > > > + unsigned int

Re: XHCI controller does not detect USB key insertion

[ Fix incorrect address for Felipe ] On 02/12/2016 14:46, Neil Armstrong wrote: > On 12/02/2016 11:24 AM, Mason wrote: > >> (Sad face) All the documentation I have is in front of me, and nothing >> is ringing a bell. This is a Sigma Designs SoC, with a Pravega XHCI >> controller + Synopsys PHY.

Re: XHCI controller does not detect USB key insertion

On 02/12/2016 14:46, Neil Armstrong wrote: > On 12/02/2016 11:24 AM, Mason wrote: > >> (Sad face) All the documentation I have is in front of me, and nothing >> is ringing a bell. This is a Sigma Designs SoC, with a Pravega XHCI >> controller + Synopsys PHY. >> >> The documentation I have: >> >>

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

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

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

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

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

On 12/02/2016 06:21 PM, Shuah Khan wrote: > 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. >>>

Re: [PATCH v13 10/10] usbip: exporting devices: modifications to protocol text

On 11/22/2016 07:48 AM, Nobuo Iwata wrote: > This patch adds export and un-export request/response to > Documentation/usb/usbip_protocol.txt. > > The definition of the structs has been defined in original code of > tools/usb/usbip/usbip_network.h but not described in the document. > > Adding

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

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

Re: usb: warning in vhci_hcd_probe/lockdep_init_map

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

Re: usb: warning in vhci_hcd_probe/lockdep_init_map

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

Re: [PATCH] usb: gadget: udc: atmel: used managed kasprintf

On 02/12/2016 at 15:59:57 +, David Laight wrote : > From: Alexandre Belloni > > Sent: 01 December 2016 10:27 > > Use devm_kasprintf instead of simple kasprintf to free the allocated memory > > when needed. > > s/when needed/when the device is freed/ > > > Suggested-by: Peter Rosin

Re: usb: warning in vhci_hcd_probe/lockdep_init_map

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

Re: usb: warning in vhci_hcd_probe/lockdep_init_map

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? > On commit 2caceb3294a78c389b462e7e236a4e744a53a474 (Dec 1). > >

Re: usb/gadget: warning in dev_config/memdup_user

On Fri, Dec 02, 2016 at 04:56:15PM +0100, Greg Kroah-Hartman wrote: > On Fri, Dec 02, 2016 at 04:07:38PM +0100, Andrey Konovalov wrote: > > Hi! > > > > I've got the following error report while running the syzkaller fuzzer. > > > > The length passed to memdup_user() directly without limitations.

RE: [PATCH] usb: gadget: udc: atmel: used managed kasprintf

From: Alexandre Belloni > Sent: 01 December 2016 10:27 > Use devm_kasprintf instead of simple kasprintf to free the allocated memory > when needed. s/when needed/when the device is freed/ > Suggested-by: Peter Rosin > Signed-off-by: Alexandre Belloni

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

On Fri, Dec 02, 2016 at 08:23:49AM -0700, Shuah Khan wrote: > 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.

Re: usb/gadget: warning in dev_config/memdup_user

On Fri, Dec 02, 2016 at 04:07:38PM +0100, Andrey Konovalov wrote: > Hi! > > I've got the following error report while running the syzkaller fuzzer. > > The length passed to memdup_user() directly without limitations. > > On commit 2caceb3294a78c389b462e7e236a4e744a53a474 (Dec 1). > > WARNING:

Re: [PATCH v13 08/10] usbip: exporting devices: change to usbip_list.c

On 11/22/2016 07:48 AM, Nobuo Iwata wrote: > Correction to wording inconsistency around import and export in > usbip_list.c regarding output title, help and function names. > > 'exported' was used for devices bound in remote and to be attached with > 'import' request. This patch set uses

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

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

Re: [PATCH v13 07/10] usbip: exporting devices: new application-side daemon

On 11/22/2016 07:48 AM, Nobuo Iwata wrote: > This patch is the new application(vhci)-side daemon specific code. > > The daemons are consisting three files. > usbip.c : common code. > usbip_dev.c: device(stub)-side specific code. > usbip_app.c: application(vhci)-side specific code - this patch.

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

On 12/02/2016 04:37 PM, Shuah Khan wrote: > 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()

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

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

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

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

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

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

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

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

usb/gadget: warning in dev_config/memdup_user

Hi! I've got the following error report while running the syzkaller fuzzer. The length passed to memdup_user() directly without limitations. On commit 2caceb3294a78c389b462e7e236a4e744a53a474 (Dec 1). WARNING: CPU: 3 PID: 14477 at mm/page_alloc.c:3511 __alloc_pages_nodemask+0x159c/0x1e20

Re: [PATCH v13 06/10] usbip: exporting devices: modifications to attach and detach

On 11/22/2016 07:48 AM, Nobuo Iwata wrote: > Refactoring to attach and detach operation to reuse common portion to > application(vhci)-side daemon. > > The new application(vhci)-side daemon executes same procedures as > attach and detach. Most of common code to access vhci has been >

Re: USB gadget: configfs hid mouse device

Krzysztof Opasiak wrote: > You may also try to use your own C program instead of echo to check if > hex value is correctly written. This was the crucial hint. Seem like echo is doing something fishy here. "mouse" Works fine with my Linux host now, but unfortunately does

usb: warning in vhci_hcd_probe/lockdep_init_map

Hi! I've got the following error report while booting the kernel with various usb configs enabled. On commit 2caceb3294a78c389b462e7e236a4e744a53a474 (Dec 1). 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

Re: [PATCH 2/3] usb: musb: Add a quirk to preserve MUSB_DEVCTL during suspend

On 11/29/2016 06:56 PM, Bin Liu wrote: > On Tue, Nov 29, 2016 at 06:41:04PM +0100, Alexandre Bailon wrote: >> On 11/29/2016 05:16 PM, Bin Liu wrote: >>> Hi, >>> >>> On Mon, Nov 28, 2016 at 05:26:20PM +0100, Alexandre Bailon wrote: On da8xx, VBUS is not maintained during suspend when musb is

Re: [PATCH v13 05/10] usbip: exporting devices: modifications to daemon

On 12/02/2016 09:36 AM, fx IWATA NOBUO wrote: > Hello, > >>> -static int do_accept(int listenfd) >>> +static int do_accept(int listenfd, char *host, char *port) > >> In my opinion you should pass also the size of those arrays to this >> function instead of hardcoding them like this. > > OK. I

Re: [PATCH 1/1] usb: xhci: fix possible wild pointer

On 02.12.2016 04:29, Lu Baolu wrote: handle_cmd_completion() frees a command structure which might be still referenced by xhci->current_cmd. This might cause problem when xhci->current_cmd is accessed after that. A real-life case could be like this. The host takes a very long time to respond to

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

On 12/02/2016 08:05 AM, fx IWATA NOBUO wrote: > Hello, > >> In my humble opinion connect is not a best name for this operation. > > Yes. I think connect is not perfect. > >> it not only starts the connection to a remote server but also> exports >> a device. I think that a name like export or

Re: [PATCH 06/12] usb: dwc3: omap: Replace the extcon API

Hi Felipe, 2016-12-02 18:03 GMT+09:00 Felipe Balbi : > > Hi, > > Chanwoo Choi writes: >> Hi Felipe, >> >> On 2016년 11월 30일 19:36, Felipe Balbi wrote: >>> >>> Hi, >>> >>> Chanwoo Choi writes: This patch uses the

Re: [PATCH] usb: gadget: udc: core: fix return code of usb_gadget_probe_driver()

On 12/01/2016 10:44 PM, Felix Hädicke wrote: > Hi, > >> Hi, >> >> Good catch but I have a few comments to commit message: >> >> On 12/01/2016 12:24 AM, Felix Hädicke wrote: >>> This fixes a regression which was introduced by commit f1bddbb, by >>> reverting a small fragment of commit 855ed04.

Re: [PATCH 24/25] usb: host: xhci: use trb_to_noop() from xhci_handle_stopped_cmd_ring()

On 01.12.2016 15:31, Felipe Balbi wrote: instead of open coding how to convert a TRB to no-op, let's use our newly introduced helper. Signed-off-by: Felipe Balbi --- drivers/usb/host/xhci-ring.c | 12 ++-- 1 file changed, 2 insertions(+), 10

Re: [PATCH 22/25] usb: host: xhci: remove unnecessary list_for_each_entry_safe()

Hi Felipe, On 2 December 2016 at 18:15, Sergei Shtylyov wrote: > Hello! > > On 12/1/2016 4:31 PM, Felipe Balbi wrote: > >> the _save() version of list iterators are supposed to be used when > > >_safe(). > >> list_entry is going to be removed from the list

[PATCH] usb: host: xhci: Handle the right timeout command

If a command event is found on the event ring during an interrupt, we need to stop the command timer with del_timer(). Since del_timer() can fail if the timer is running and waiting on the xHCI lock, then it maybe get the wrong timeout command in xhci_handle_command_timeout() if host fetched a new

Re: XHCI controller does not detect USB key insertion

On Fri, Dec 02, 2016 at 12:08:21PM +0100, Mason wrote: > On 02/12/2016 11:42, Greg KH wrote: > > > On Fri, Dec 02, 2016 at 11:24:05AM +0100, Mason wrote: > > > >> # lsusb -v > >> Bus 001 Device 001: ID 1d6b:0002 > >> Bus 002 Device 001: ID 1d6b:0003 > >> > >> Isn't lsusb verbose supposed to

Re: XHCI controller does not detect USB key insertion

On 02/12/2016 11:42, Greg KH wrote: > On Fri, Dec 02, 2016 at 11:24:05AM +0100, Mason wrote: > >> # lsusb -v >> Bus 001 Device 001: ID 1d6b:0002 >> Bus 002 Device 001: ID 1d6b:0003 >> >> Isn't lsusb verbose supposed to print much more than that? > > Yes, if you are using the usbutils version of

Re: [PATCH 01/25] usb: host: xhci: dynamically allocate devs array

On 01.12.2016 15:30, Felipe Balbi wrote: Instead of always defaulting to a 256-entry array, we can dynamically allocate devs based on what HW tells us it supports. Note that we can't, yet, purge MAX_HC_SLOTS completely because of struct xhci_device_context_array reliance on it. Signed-off-by:

Re: XHCI controller does not detect USB key insertion

On Fri, Dec 02, 2016 at 11:24:05AM +0100, Mason wrote: > >> # lsusb -v > >> Bus 001 Device 001: ID 1d6b:0002 > >> Bus 002 Device 001: ID 1d6b:0003 > > Isn't lsusb verbose supposed to print much more than that? Yes, if you are using the usbutils version of 'lsusb', odds are this is busybox,

Re: [PATCH] usb: gadget: uvc: fix UVC_ATTR macro for UVCG_OPTS_ATTR

Hello! On 12/2/2016 9:22 AM, Jassi Brar wrote: From: Jassi Brar Typo in commit 76e0da34c7cec5a7d introduced a bug that prevents scripts/checkpatch.pl didn't complain about the commit citing style? You forgot to specify the summary line enclosed in ("").

Re: XHCI controller does not detect USB key insertion

On 02/12/2016 10:03, Felipe Balbi wrote: > Mason wrote: > >> I'm trying out a SoC with a brand new USB controller, which is (supposedly) >> a standard XHCI controller. In theory, I would just need to build the right >> driver, and everything would auto-magically work, right? > > perhaps, but

Re: [PATCH 22/25] usb: host: xhci: remove unnecessary list_for_each_entry_safe()

Hello! On 12/1/2016 4:31 PM, Felipe Balbi wrote: the _save() version of list iterators are supposed to be used when _safe(). list_entry is going to be removed from the list while iterating. Since xhci_handle_stopped_cmd_ring() is not removing anything from the list, just converting

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

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'

RE: RE: [PATCH] usb: chipidea: use better pattern with WARN_ON()

On 2 Dec 2016 2:18 p.m., "Atul Raj" wrote: > > > > >Instead of using: > >if (cond) { > > WARN_ON(1); > > do_stuff(); > >} > > > >Use a better pattern with WARN_ON() placed in if condition: > > > >if (WARN_ON(cond)) > > do_stuff(); > > > >Signed-off-by:

RE: RE: [PATCH] usb: chipidea: use better pattern with WARN_ON()

On 2 Dec 2016 2:17 p.m., "Atul Raj" wrote: > > > > > >Instead of using: > >if (cond) { > > WARN_ON(1); > > do_stuff(); > >} > > > >Use a better pattern with WARN_ON() placed in if condition: > > > >if (WARN_ON(cond)) > > do_stuff(); > > > >Signed-off-by:

Re: [PATCH 06/12] usb: dwc3: omap: Replace the extcon API

Hi, Chanwoo Choi writes: > Hi Felipe, > > On 2016년 11월 30일 19:36, Felipe Balbi wrote: >> >> Hi, >> >> Chanwoo Choi writes: >>> This patch uses the resource-managed extcon API for >>> extcon_register_notifier() >>> and replaces the deprecated

Re: XHCI controller does not detect USB key insertion

Hi, Mason writes: > Hello everyone, > > I'm trying out a SoC with a brand new USB controller, which is (supposedly) > a standard XHCI controller. In theory, I would just need to build the right > driver, and everything would auto-magically work, right? perhaps, but there

Re: [BUG 4.9] New led trigger usbport gets the kernel to panic

On Thu, 1 Dec 2016 17:56:07 +0100 Rafał Miłecki wrote: > On 12/01/2016 03:28 PM, Ralph Sennhauser wrote: > > Below the oops with your debug patch applied. > > > > (...) > > > > root@wrt1900acs:/# cd sys/class/leds/pca963x\:shelby\:white\:usb2/ > >

XHCI controller does not detect USB key insertion

Hello everyone, I'm trying out a SoC with a brand new USB controller, which is (supposedly) a standard XHCI controller. In theory, I would just need to build the right driver, and everything would auto-magically work, right? So my defconfig contains: CONFIG_USB=y

RE: [PATCH v13 05/10] usbip: exporting devices: modifications to daemon

Hello, > > -static int do_accept(int listenfd) > > +static int do_accept(int listenfd, char *host, char *port) > In my opinion you should pass also the size of those arrays to this > function instead of hardcoding them like this. OK. I will add them. > > - if (usbip_driver_open(driver)) > >