Hi,
Krzysztof Opasiak writes:
> By default user could store only valid UDC name in configfs UDC
> attr by doing:
>
> echo $UDC_NAME > UDC
>
> Commit (855ed04 "usb: gadget: udc-core: independent registration of
> gadgets and gadget drivers") broke this behavior and allowed to store
> any arbitrar
Hi,
Peter Chen writes:
>> "Du, Changbin" writes:
>> > Hi, Balbi,
>> >
>> > The step to reproduce this issue is:
>> > 1) connect device to a host and wait its enumeration.
>> > 2) trigger software disconnect by calling function
>> > usb_gadget_disconnect(), which finally call
>> >dwc3_ga
On Fri, May 06, 2016 at 08:12:24AM +0200, Krzysztof Kozlowski wrote:
> On 05/06/2016 07:44 AM, Peter Chen wrote:
> > On Thu, May 05, 2016 at 05:42:40PM -0500, Rob Herring wrote:
> >> On Thu, May 05, 2016 at 02:34:13PM +0200, Krzysztof Kozlowski wrote:
> >>> Hi,
> >>>
> >>> This is a different, seco
On Fri, May 06, 2016 at 10:01:20AM +0300, Felipe Balbi wrote:
>
> Hi,
>
> Peter Chen writes:
> >> "Du, Changbin" writes:
> >> > Hi, Balbi,
> >> >
> >> > The step to reproduce this issue is:
> >> > 1) connect device to a host and wait its enumeration.
> >> > 2) trigger software disconnect by cal
Hi,
Peter Chen writes:
>> Peter Chen writes:
>> >> "Du, Changbin" writes:
>> >> > Hi, Balbi,
>> >> >
>> >> > The step to reproduce this issue is:
>> >> > 1) connect device to a host and wait its enumeration.
>> >> > 2) trigger software disconnect by calling function
>> >> > usb_gadget_disc
Hi,
Yoshihiro Shimoda writes:
> The firmware of R-Car USB 3.0 host controller will control the reset.
> So, if the xhci driver doesn't do firmware downloading (e.g. kernel
> configuration is CONFIG_USB_XHCI_PLATFORM=y and CONFIG_USB_XHCI_RCAR
> is not set), the reset of USB 3.0 host controller d
Hi,
John Youn writes:
> As you mentioned this is handled in the soft_disconnect sysfs. Why
> shouldn't usb_gadget_disconnect() do the same thing, if not the gadget
because there might be cases where we don't need/want the gadget to know
about this disconnect.
>>>
>>>
Felipe,
On 05/05/2016 11:50 PM, Felipe Balbi wrote:
Hi Guenter,
Guenter Roeck writes:
On Tue, Feb 09, 2016 at 07:01:20PM +0200, Heikki Krogerus wrote:
Hi,
The OS, or more precisely the user space, needs to be able to control
a few things regarding USB Type-C ports. The first thing that mus
Hi,
On Wed, May 04, 2016 at 08:05:44PM -0700, Guenter Roeck wrote:
> On Tue, Feb 09, 2016 at 07:01:20PM +0200, Heikki Krogerus wrote:
> > Hi,
> >
> > The OS, or more precisely the user space, needs to be able to control
> > a few things regarding USB Type-C ports. The first thing that must be
> >
On Fri, May 06, 2016 at 09:50:00AM +0300, Felipe Balbi wrote:
>
> Hi Guenter,
>
> Guenter Roeck writes:
> > On Tue, Feb 09, 2016 at 07:01:20PM +0200, Heikki Krogerus wrote:
> >> Hi,
> >>
> >> The OS, or more precisely the user space, needs to be able to control
> >> a few things regarding USB T
On Fri, May 06, 2016 at 01:05:05AM -0700, Guenter Roeck wrote:
> Felipe,
>
> On 05/05/2016 11:50 PM, Felipe Balbi wrote:
> >
> > Hi Guenter,
> >
> > Guenter Roeck writes:
> > > On Tue, Feb 09, 2016 at 07:01:20PM +0200, Heikki Krogerus wrote:
> > > > Hi,
> > > >
> > > > The OS, or more precisel
On Mon, May 02, 2016 at 03:18:54PM +0300, Roger Quadros wrote:
> Now that we have a device reference in struct usb_otg
> let's use dev_dbg() for debug messages.
>
> Signed-off-by: Roger Quadros
> ---
> drivers/usb/common/usb-otg-fsm.c | 19 +++
> 1 file changed, 7 insertions(+),
On Mon, May 02, 2016 at 03:18:44PM +0300, Roger Quadros wrote:
> When using the OTG/drd library we can call hcd_add/remove
> consecutively without calling usb_put_hcd/usb_create_hcd in between
> so hcd->flags can be stale.
>
> If the HC dies due to whatever reason then without this
> patch we get
On Mon, May 02, 2016 at 03:18:46PM +0300, Roger Quadros wrote:
> The OTG core will use struct otg_hcd_ops to interface
> with the HCD controller.
>
> The main purpose of this interface is to avoid directly
> calling HCD APIs from the OTG core as they
> wouldn't be defined in the built-in symbol ta
> From: Bin Liu [mailto:b-...@ti.com]
> On Thu, May 05, 2016 at 04:02:55PM +, Andrew Goodbody wrote:
> > > From: Bin Liu [mailto:b-...@ti.com]
> > > On Thu, May 05, 2016 at 03:12:00PM +, Andrew Goodbody wrote:
> > > > > From: Bin Liu [mailto:b-...@ti.com] Hi,
> > > > >
> > > > > On Thu, May
On Monday 18 April 2016 10:02:57 Ivaylo Dimitrov wrote:
>
>
> On 8.04.2016 23:13, Ivaylo Dimitrov wrote:
> >Hi,
> >
> >On 16.01.2016 12:40, Ivaylo Dimitrov wrote:
> >>Hi,
> >>
> >>On 16.01.2016 00:48, Tony Lindgren wrote:
> >>>Hi all,
> >>>
> >>>Looks like there's some issue with the USB gadgets
On Fri, May 6, 2016 at 1:10 AM, Krzysztof Kozlowski
wrote:
> On 05/06/2016 12:42 AM, Rob Herring wrote:
>> On Thu, May 05, 2016 at 02:34:13PM +0200, Krzysztof Kozlowski wrote:
>>> Hi,
>>>
>>> This is a different, second try to fix usb3503+lan on Odroid U3 board
>>> if it was initialized by bootloa
On 05/06/2016 01:08 AM, Heikki Krogerus wrote:
Hi,
On Wed, May 04, 2016 at 08:05:44PM -0700, Guenter Roeck wrote:
On Tue, Feb 09, 2016 at 07:01:20PM +0200, Heikki Krogerus wrote:
Hi,
The OS, or more precisely the user space, needs to be able to control
a few things regarding USB Type-C ports.
Hello Heikki,
On 05/06/2016 01:29 AM, Heikki Krogerus wrote:
On Fri, May 06, 2016 at 01:05:05AM -0700, Guenter Roeck wrote:
[ ... ]
I know there has been a lengthy discussion about the patch set, but I may
have missed the conclusion. Is there some reason to _not_ advance it
that I may have mis
On 05/05/16 13:19, Guodong Xu wrote:
Hi, Dean
I am not sure why do you insist 'not full speed'. Actually, the tests
I run on ARM-64bit is at USB full speed mode. I pasted my log here:
http://paste.ubuntu.com/16236442/
, which includes the information you requested above, ifconfig, dmesg.
The int
> In other words, the full-speed hub is restricting the USB to
> Ethernet Adaptor to a 12Mbps (half-duplex) bandwidth to support
> Ethernet 100Mbps (full-duplex) traffic. That is not going to work
> very well because Ethernet frames (perhaps partial Ethernet frames)
> need to be discarded within th
On Fri, 6 May 2016, Felipe Balbi wrote:
> >> that's not a good idea, IMO. HCD drivers should be robust enough in
> >> these situations.
> >
> > Why? Just so that hcd-tests.sh can complete with no errors? I don't
>
> and some off-the-shelf usb-network adapters can work ;-)
>
> > know of any ac
On 06/05/16 16:27, Andrew Lunn wrote:
In other words, the full-speed hub is restricting the USB to
Ethernet Adaptor to a 12Mbps (half-duplex) bandwidth to support
Ethernet 100Mbps (full-duplex) traffic. That is not going to work
very well because Ethernet frames (perhaps partial Ethernet frames)
On Thu, May 5, 2016 at 1:11 AM, Dean Jenkins wrote:
> On 05/05/16 00:45, John Stultz wrote:
>>
>> Just as a sample point, I have managed to reproduce exactly this issue
>> on an x86_64 system by simply scp'ing a large file.
>
> Please tell us the x86_64 kernel version number that you used and whic
On Fri, May 6, 2016 at 8:00 AM, Dean Jenkins wrote:
> My conclusion is that your USB to Ethernet Adaptor is not running at high
> speed (480Mbps) mode which is causing a partial loss (corruption) of
> Ethernet frames across the USB link. A USB Protocol Analyser or software
> tool usbmon could be u
On Tue, May 3, 2016 at 2:16 PM, Dean Jenkins wrote:
> A good test would be to run "ping -c 1 -s $packet_length $ip_address" inside
> a script which has a loop with an increasing payload length $packet_length
> with a small delay between ping calls. This will show whether particular
> packet sizes
On 2016-05-04 03:58, Dean Jenkins wrote:
On 04/05/16 01:28, David B. Robins wrote:
Here is the code snippet from the patch with my annotations between #
#, I will try to explain my intentions. Feel free to point out any
flaws:
if (rx->remaining && (rx->remaining + sizeof(u32) <= skb->len
Hello Mathias,
In c311e391a7ef "xhci: rework command timeout and cancellation," xHCI
command timeouts were refactored to flow through
xhci_handle_command_timeout. We've seen a few instances of
hangs/crashes with upstream and RHEL7.2 kernels where someone gets stuck
on wait_for_completion(cmd->com
On Tue, May 3, 2016 at 2:16 PM, Dean Jenkins wrote:
>
> [ 239.027993] asix 1-1.1:1.0 eth0: asix_rx_fixup() Data Header
> synchronisation was lost, remaining 988
>
> This error message consistently shows the remaining value to be 988, at
> least for the 3 examples provided by John. This does not s
29 matches
Mail list logo
