aboutsummaryrefslogtreecommitdiffstats
path: root/tools/missing-macros/src/m4/lib-link.m4
diff options
context:
space:
mode:
authorMarian Hello <marian.hello@gmail.com>2016-12-07 17:06:47 +0100
committerZoltan HERPAI <wigyori@uid0.hu>2016-12-07 17:06:47 +0100
commit6ee59728b9c293d76146d9021639b72147065aad (patch)
tree77115643a5689c4edf25b439d10d7b8407f89c4d /tools/missing-macros/src/m4/lib-link.m4
parent2aefb514a4852f4c427b467150bbc7cdfe024528 (diff)
downloadupstream-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 'tools/missing-macros/src/m4/lib-link.m4')
0 files changed, 0 insertions, 0 deletions