| b337b3b2 | 11-Sep-2015 |
Stephen Warren <swarren@nvidia.com> |
usb: ci_udc: fix emissions of ZLPs
Commit 6a132416359e "ci_udc: Update the ci_udc driver to support bulk
transfers" caused the value of "len" to change without updating subsquent
users of that varia
usb: ci_udc: fix emissions of ZLPs
Commit 6a132416359e "ci_udc: Update the ci_udc driver to support bulk
transfers" caused the value of "len" to change without updating subsquent
users of that variable in ci_ep_submit_next_request(). This caused the
code that detects when to emit ZLPs (Zero Length Packets) never to
trigger, which in turn caused host timeouts when a ZLP was required,
which in turn broke tests/dfu/, even despite the assertion in that
commit's description that "These changes are tested for both the DFU and
lthor."
Fix this by modifying the added dtd iteration code not to modify "len",
but rather to keep state in a separate variable. Rename the variables
while we're at it so they describe their purpose better.
Fixes: 6a132416359e ("ci_udc: Update the ci_udc driver to support bulk transfers")
Cc: Siva Durga Prasad Paladugu <siva.durga.paladugu@xilinx.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
show more ...
|
| 44bfb43f | 05-Sep-2015 |
Stephen Warren <swarren@nvidia.com> |
usb: gadget: don't leak configs when unbinding
By the time g_dnl_unbind() is run, cdev->config has been set to NULL,
so the free() there does nothing, and the config struct is leaked.
Equally, struc
usb: gadget: don't leak configs when unbinding
By the time g_dnl_unbind() is run, cdev->config has been set to NULL,
so the free() there does nothing, and the config struct is leaked.
Equally, struct usb_gadget contains a linked list of config structs, so
the code should iterate over them all and free each one, rather than
freeing one particular config struct.
composite_unbind() already iterates over the list of config structs, and
unlinks each from the linked list. Fix this loop to free() each struct as
it's unlinked and otherwise forgotten.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
show more ...
|
| 58f99df4 | 15-Apr-2015 |
Siva Durga Prasad Paladugu <siva.durga.paladugu@xilinx.com> |
usb: gadget: f_thor: Allocate request up to THOR_PACKET_SIZE
Allocate request up to THOR_PACKET_SIZE not the ep0->maxpacket
as the descriptors data depend on the number of descriptors
and this 64 by
usb: gadget: f_thor: Allocate request up to THOR_PACKET_SIZE
Allocate request up to THOR_PACKET_SIZE not the ep0->maxpacket
as the descriptors data depend on the number of descriptors
and this 64 bytes were not enough and the buffer might overflow
which results in memalign failures later.
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
show more ...
|
| 5df13152 | 19-Aug-2015 |
Kishon Vijay Abraham I <kishon@ti.com> |
usb: gadget: ether: populate _reset_ callback
populate _reset_ callback to the USB ethernet gadget since UDC core
expects every gadget driver to have the reset callback. This shouldn't
be needed onc
usb: gadget: ether: populate _reset_ callback
populate _reset_ callback to the USB ethernet gadget since UDC core
expects every gadget driver to have the reset callback. This shouldn't
be needed once the ethernet gadget driver is adapted to use the
composite driver.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
show more ...
|
| 58d6d139 | 24-Jul-2015 |
Rob Herring <robh@kernel.org> |
usb: ci_udc: fix request allocation when endpoints are disabled
The ci_udc driver request allocation assumes that the endpoint descriptor
pointer is set to retrieve the endpoint number, but that is
usb: ci_udc: fix request allocation when endpoints are disabled
The ci_udc driver request allocation assumes that the endpoint descriptor
pointer is set to retrieve the endpoint number, but that is only true
when the endpoint is enabled. This results in a NULL ptr dereference
which for me happens to return 0 value. This causes the EP0 request
struct to be returned for other endpoints. Some gadget drivers like
fastboot and USB MS work fine, but ethernet does not.
Really, the ci_udc driver is the oddball here doing this EP0 special
case handling Stephen added. All the other drivers alloc/free functions
are pretty much the same with the only variation being the size of the
private struct. This could all be consolidated to a common function.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Marek Vasut <marex@denx.de>
Acked-by: Stephen Warren <swarren@nvidia.com>
show more ...
|
| a588d99a | 20-Jul-2015 |
Paul Kocialkowski <contact@paulk.fr> |
usb: CONFIG_USB_FASTBOOT prefix replacement for consistency
FASTBOOT is defined both by CONFIG_USB_FUNCTION_FASTBOOT AND CONFIG_CMD_FASTBOOT, so it doesn't
make much sense to have a CONFIG_USB_FASTB
usb: CONFIG_USB_FASTBOOT prefix replacement for consistency
FASTBOOT is defined both by CONFIG_USB_FUNCTION_FASTBOOT AND CONFIG_CMD_FASTBOOT, so it doesn't
make much sense to have a CONFIG_USB_FASTBOOT prefix for fastboot-specific options, especially
given that other config options for fastboot use the CONFIG_FASTBOOT prefix.
This replaces the CONFIG_USB_FASTBOOT prefix with CONFIG_FASTBOOT, for consistency.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
show more ...
|
| bc9071c9 | 04-Jul-2015 |
Paul Kocialkowski <contact@paulk.fr> |
usb: gadget: fastboot: Dequeue the previous IN request for the current request
Recent versions of the fastboot tool will query the partition type before doing
an operation on a partition (such as er
usb: gadget: fastboot: Dequeue the previous IN request for the current request
Recent versions of the fastboot tool will query the partition type before doing
an operation on a partition (such as erase, flash, etc). It will then submit
the operation as soon as the response for the partition type is received.
Usually, the MUSB controller will see that the partition type request return
status was read by the host at the very same time as the actual operation
request is submitted by the host. However, the operation will be read first
(int_rx is handled first in musb_interrupt) and after it is completed, the
fastboot USB gadget driver will send another return status. Hence, this happens
before the musb gadget framework has had a chance to handle the previous
acknowledgement that the host read the return status and dequeue the request.
The host will then usually empty the FIFO by the time musb_interrupt gets around
handling the return status acknowledgement (for the previous request, this is
still on the same musb_interrupt call), so no other interrupt is generated and
the most recent return status acknowledgement remains unaccounted for.
It will then be used as a response for the next command, and the proper response
for it will be delayed to the next command, and so on.
Dequeuing the previous IN request in the fastboot code ensures that no previous
return status remains. It is acceptable to do it since there is no callback to
it anyways.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
show more ...
|
| 94b385fa | 04-Jul-2015 |
Paul Kocialkowski <contact@paulk.fr> |
usb: gadget: fastboot: Request status and length check in rx handler
This avoids handling requests that have an error status or no data.
In particular, this avoids showing unnecessary error messages
usb: gadget: fastboot: Request status and length check in rx handler
This avoids handling requests that have an error status or no data.
In particular, this avoids showing unnecessary error messages when the USB
gadget gets disconnected (e.g. with fastboot continue) and the fastboot USB
gadget driver sends an error back to the host (that has disconnected already).
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
show more ...
|
| 99fc2221 | 12-Jun-2015 |
Paul Kocialkowski <contact@paulk.fr> |
usb: gadget: Weak board_usb_init/cleanup definitions in USB download gadget code
Weak versions of board_usb_init and board_usb_cleanup are defined in common USB
host code, but it is also used for US
usb: gadget: Weak board_usb_init/cleanup definitions in USB download gadget code
Weak versions of board_usb_init and board_usb_cleanup are defined in common USB
host code, but it is also used for USB device gadgets, so we also need a weak
definition of it when there is no USB host enabled.
Both weak definitions do not conflict.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Test HW: Odroid_XU3 (Exynos5422), trats (Exynos4210)
show more ...
|
| 17da3c0c | 12-Jun-2015 |
Paul Kocialkowski <contact@paulk.fr> |
usb: Fastboot function config for better consistency with other functions
USB download gadget functions such as thor and dfu have a separate config option
for the USB gadget part of the code, indepe
usb: Fastboot function config for better consistency with other functions
USB download gadget functions such as thor and dfu have a separate config option
for the USB gadget part of the code, independent from the command part.
This switches the fastboot USB gadget to the same scheme, for better
consistency.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Test HW: Odroid_XU3 (Exynos5422), trats (Exynos4210)
show more ...
|