diff options
author | Marian Hello <marian.hello@gmail.com> | 2016-12-07 17:06:47 +0100 |
---|---|---|
committer | Zoltan HERPAI <wigyori@uid0.hu> | 2016-12-07 17:06:47 +0100 |
commit | 6ee59728b9c293d76146d9021639b72147065aad (patch) | |
tree | 77115643a5689c4edf25b439d10d7b8407f89c4d /target/linux/mvebu/patches-3.18/022-ARM-mvebu-A385-AP-Enable-the-NAND-controller.patch | |
parent | 2aefb514a4852f4c427b467150bbc7cdfe024528 (diff) | |
download | upstream-6ee59728b9c293d76146d9021639b72147065aad.tar.gz upstream-6ee59728b9c293d76146d9021639b72147065aad.tar.bz2 upstream-6ee59728b9c293d76146d9021639b72147065aad.zip |
CC: brcm2708: Fix Kernel Panic: DM9601 Fast Ethernet Adapter
The dm9601 driver expects to receive a single encapsulated ethernet
frame from the device in one URB transfer, and it provides an URB
buffer of length 1,522 to receive it. This is not a round multiple
of USB transfer packets.
The device in question [1] provides a stream of such frames and it
does not conveniently slice them up as the dm9601 driver expects. We
can end up with 1,536 (0x600) bytes returned by the device in response
to the URB request. This may include several encapsulated ethernet
frames, and/or fragments thereof.
It seems to me that the kernel 'Oops' arises because the dwc_otg driver
does not notice that the destination buffer is too small to receive the
full 1,536 bytes. Comparing dwc_otg's update_urb_state_xfer_comp with
dwc2's dwc2_update_urb_state is suggestive.
More details: https://github.com/raspberrypi/linux/issues/1045
All Credits to: https://github.com/mw9
Signed-off-by: Marian Hello <marian.hello@gmail.com>
Reviewed-by: Zoltan HERPAI <wigyori@uid0.hu>
Diffstat (limited to 'target/linux/mvebu/patches-3.18/022-ARM-mvebu-A385-AP-Enable-the-NAND-controller.patch')
0 files changed, 0 insertions, 0 deletions