Hi Felipe,
On 13 October 2016 at 21:34, Felipe Balbi wrote:
>
>
> Hi,
>
> Baolin Wang writes:
>>> Baolin Wang writes:
>> Baolin Wang writes:
>> I'm thinking this is a bug in configfs interface of Gadget API, not
>> dwc3. The only reason for this to happen would be if we get
Hi,
Baolin Wang writes:
> I see what the problem is. Databook tells us we *must* set CMDIOC when
> issuing EndTransfer command and we should always wait for Command
> Complete IRQ. However, we took a shortcut and just delayed for 100us
> after issuing End Transfer
This driver is for Fintek F81532/F81534 USB to Serial Ports IC.
F81532 spec:
https://drive.google.com/file/d/0B8vRwwYO7aMFOTRRMmhWQVNvajQ/view?usp=
sharing
F81534 spec:
https://drive.google.com/file/d/0B8vRwwYO7aMFV29pQWJqbVBNc00/view?usp=
sharing
Features:
1. F81532 is 1-to-2 & F81534 is 1-to-4
Hi Felipe,
On 14 October 2016 at 15:46, Felipe Balbi wrote:
>
> Hi,
>
> Baolin Wang writes:
>> I see what the problem is. Databook tells us we *must* set CMDIOC
>> when
>> issuing EndTransfer command and we should always wait for Command
>> Complete IRQ. However,
When we change the USB function with configfs dynamically, we possibly met this
situation: one core is doing the control transfer, another core is trying to
unregister the USB gadget from userspace, we must wait for completing this
control tranfer, or it will hang the controller to set the DEVCTRLH
Hi,
Baolin Wang writes:
>> Baolin Wang writes:
>>> I see what the problem is. Databook tells us we *must* set CMDIOC
>>> when
>>> issuing EndTransfer command and we should always wait for Command
>>> Complete IRQ. However, we took a shortcut and just delayed for
f->disable() will call usb_ep_disable() which should
be called with IRQs enabled and locks released.
Signed-off-by: Felipe Balbi
---
drivers/usb/gadget/composite.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 919d7d1b
Instead of just delaying for 100us, we should
actually wait for End Transfer Command Complete
interrupt before moving on. Note that this should
only be done if we're dealing with one of the core
revisions that actually require the interrupt before
moving on.
Reported-by: Baolin Wang
Signed-off-by
That function is unnecessarily called from
dwc3_gadget_reset_interrupt(). Gadget drivers (and
thus, functions) are required to dequeue all pending
requests when they get notified about a USB Bus
Reset.
Trying to make sure there are no pending requests
only serves the purpose of working around poss
Hi,
Felipe Balbi writes:
> Instead of just delaying for 100us, we should
> actually wait for End Transfer Command Complete
> interrupt before moving on. Note that this should
> only be done if we're dealing with one of the core
> revisions that actually require the interrupt before
> moving on.
On Friday, October 14, 2016 10:59:47 AM Peter Chen wrote:
> Hi all,
>
> This is a follow-up for my last power sequence framework patch set [1].
> According to Rob Herring and Ulf Hansson's comments[2]. The kinds of
> power sequence instances will be added at postcore_initcall, the match
> criteria
On Fri, Oct 14, 2016 at 06:53:29PM +0500, Михаил Гаврилов wrote:
> [ 16.685607] xhci_hcd :00:14.0: Timeout while waiting for setup device
> command
> [ 16.893766] usb 2-5.4: Device not responding to setup address.
> [ 17.098457] usb 2-5.4: device not accepting address 6, error -71
> [
On Fri, 14 Oct 2016, Felipe Balbi wrote:
> argh, we have nested spinlocks :-( Well, we shouldn't call
> usb_ep_disable() with locks held AFAICR. So the following should be
> enough:
>
> diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
> index 919d7d1b611c..2e9359c58eb9
On Thu, Oct 13, 2016 at 6:29 PM, John Stultz wrote:
> From: Chen Yu
>
> The Hi6220's usb controller is limited in that it does not
> automatically autonegotiate the usb speed. Thus it requires a
> quirk so that we can manually negotiate the best usb speed for
> the attached device.
>
> Cc: Wei Xu
From: Heiko Stuebner
Although a host-only controller should not have any associated delay,
some rockchip SOC platforms will not show the correct host-values of
registers until after a delay.
So add a 50 ms sleep when in host-only mode.
Signed-off-by: John Youn
Signed-off-by: Heiko Stuebner
--
On Fri, Oct 14, 2016 at 8:00 AM, Rob Herring wrote:
> On Thu, Oct 13, 2016 at 6:29 PM, John Stultz wrote:
>> From: Chen Yu
>>
>> The Hi6220's usb controller is limited in that it does not
>> automatically autonegotiate the usb speed. Thus it requires a
>> quirk so that we can manually negotiate
Hi,
On Fri, Sep 30, 2016 at 11:10:08AM -0700, Tony Lindgren wrote:
> Hi all,
>
> Looks like we have two more regressions caused by my attempts
> to make musb PM simpler. As it's very close to the merge window
> opening, these are against current Linux next.
>
> Once reviewed, tested and merged t
The Issue: Scanning (with xsane 0.999) while using kernel 4.8 (I
tested 4.8 rc1, rc5, rc7, rc8, and 4.8.1) fails when the scanner
becomes disconnected from the USB bus. Every time.
Scanning (with xsane 0.999) while using kernel 4.7.0 or earlier 4's
works without fail.
My scanner is known to lsus
On 10/13/2016 4:36 PM, John Stultz wrote:
> From: Chen Yu
>
> The Hi6220's usb controller is limited in that it does not
> automatically autonegotiate the usb speed. Thus it requires a
> quirk so that we can manually negotiate the best usb speed for
> the attached device.
Hi,
Could you expand m
Hi,
On Thu, Oct 06, 2016 at 02:45:30PM +, Andrew Goodbody wrote:
> I am trying to investigate an issue on a TI Sitara CPU, AM3352 with
> the musb USB controller.
>
> The scenario is that a device has been in use and working correctly.
> The device is an Android device and is presenting as an
From: Guenter Roeck
Date: Thu, 13 Oct 2016 16:43:16 -0700
> Check answers from USB stack and avoid re-sending the request
> multiple times if the device does not respond.
>
> This fixes the following problem, observed with a probably flaky adapter.
...
> Since the USB timeout is 5 seconds, and
Due to the 80-cols checkpatch warnings, several strings
were broken into multiple lines. This is not considered
a good practice anymore, as it makes harder to grep for
strings at the source code. So, join those continuation
lines.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/usb/zr364x
On Fri, 14 Oct 2016, Benjamin Staton wrote:
> The Issue: Scanning (with xsane 0.999) while using kernel 4.8 (I
> tested 4.8 rc1, rc5, rc7, rc8, and 4.8.1) fails when the scanner
> becomes disconnected from the USB bus. Every time.
>
> Scanning (with xsane 0.999) while using kernel 4.7.0 or earli
Brian,
Working - I appreciate this. I applied this mini-patch to kernel
4.8.1 and confirm that after a few test scans, I now have no problem
with the USB Canon scanner.
Also seems to have cleared up a puzzling no-input problem I was having
with a cheap no-brand USB keyboard/video/mouse switch un
Alan,
I apologize, but git itself is still over my head, and I don't know
how to get bisect. I download the kernel tar.xz files and tell
Debian's make-kpkg utility to compile them for me.
But for what it's worth, the patch from Bryan Paluch that changes
IO_WATCHDOG_DELAY in drivers/usb/host/ohci
Hi!
I've managed to build the patched kernel on OBS, install the package
and boot! \o/
And I can confirm that the patch indeed fix the issue!
The kernel was booted without the usb.autosuspend=-1 option, of
course.
Thank you guys!
Cheers,
Pierre.
Le jeudi 13 octobre 2016, 17:11:46 NZDT Alan
26 matches
Mail list logo
