The endpoint fifo is already flushed in _ep_nuke so there
is no need to flush it twice.
Signed-off-by: Stefan Wahren
---
drivers/usb/chipidea/udc.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 8fb0c00..fdcdcc6 100644
--- a/dr
Since there should be a write barrier before every call of
hw_ep_prime we could move it into hw_ep_prime.
Signed-off-by: Stefan Wahren
---
drivers/usb/chipidea/udc.c |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/u
Since there is no dependency from this busy wait in the reset ISR
we could remove it.
Signed-off-by: Stefan Wahren
---
drivers/usb/chipidea/udc.c |4
1 file changed, 4 deletions(-)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index fdcdcc6..bb51ae8 100644
--- a/
This patch series aim to improve the ChipIdea UDC driver in regards to
readability and runtime behavior.
Stefan Wahren (4):
usb: chipidea: udc: move write barrier into hw_ep_prime
usb: chipidea: udc: Don't flush endpoint fifo twice
usb: chipidea: udc: Avoid busy wait in reset ISR
usb: chip
This driver make assumptions about the value of the direction flags.
So better use them in comparisons to improve the readability.
Signed-off-by: Stefan Wahren
---
drivers/usb/chipidea/udc.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/chip
https://bugzilla.kernel.org/show_bug.cgi?id=120981
Bug ID: 120981
Summary: 4.6.x VIA VL805 USB 3.0 controller resets device making it
unusable until re-plugged
Product: Drivers
Version: 2.5
Kernel Version: 4.6.x
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of
On Sat, 25 Jun 2016, Dmitry K wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=120981
>
> Bug ID: 120981
> Summary: 4.6.x VIA VL805 USB 3.0 controller resets device making it
> unusable until re-plugged
I'm curious... How do you know that the controller reset the device?
I didn't see anyt
This is a minimal driver to support bringing a usb4604 device
from microchip out of reset and into hub mode. The usb4604 device
is related to the usb3503 device, but it didn't seem close enough
to warrant putting both into the same file. This patch borrows
some of the usb3503 structure and trims it
Let's follow other driver registration functions and
automatically set the driver's owner member to THIS_MODULE when
ulpi_driver_register() is called. This allows ulpi driver writers
to forget about this boiler plate detail and avoids common bugs
in the process.
Cc: Heikki Krogerus
Signed-off-by: