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))
> > +
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
CONFIG_USB_ANNOUNCE_NEW_DEVICES
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/
> > root@wrt1900acs:/sys/devices/platform/soc/soc:int
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 might be needed initial
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 extcon API as following:
>>> - extcon_get_cable_st
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: Atul Raj
> >---
> >
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: Atul Raj
> >---
> >
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.
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 comma
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 the
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 ("").
creation of streaming_{interval,
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, right?
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: F
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
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 print
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
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 while iterating. Since
>> xhci_handl
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 deletions(-)
diff --git a/drivers/usb/hos
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.
>>
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 resource-managed extcon API for
extcon_register_notifier()
and replac
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 a
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
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
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 in
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
vhc
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 not using
Windows 10 as
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
> implemen
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
Kernel
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
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 ma
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
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 a
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() ad
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.
>
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 connecti
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 pre-d
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: C
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. On
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
> ---
> drivers/usb/gadget/udc/atmel_usba_u
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.
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).
>
> gad
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
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
> > Signed
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.
>>
>
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
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 at
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
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.
>>>
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 'clien
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 remo
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:
>>
>> P
[ 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.
>
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
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 USB/IP
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 rea
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 behavior caused
> the link st
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).
> -
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 usb_hcd_omap_probe functio
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
> > invalid 'aname' node.
> >
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 p
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 with
> the child de
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 usb_phy structure.
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 []
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 2.
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 default,
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
---
drivers/usb/core/hub.c
66 matches
Mail list logo
