-
Notifications
You must be signed in to change notification settings - Fork 5.2k
Side-port dwc_otg fixes to dwc2 #6892
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
As a result of a hardware bug, small IN packets with length < 4 cause a 4-byte write to memory. Generally, buffers allocated with kmalloc reserve at least one cacheline of memory, but the UVC driver passes offsets into a struct as the buffer. This causes trampling of video control min/max/default/range data. e.g. on a generic UVC camera, these default values are nonsense: $ v4l2-ctl -d0 --all [...] brightness 0x00980900 (int) : min=0 max=255 step=1 default=-8193 value=128 contrast 0x00980901 (int) : min=0 max=100 step=1 default=57343 value=67 saturation 0x00980902 (int) : min=0 max=100 step=1 default=57343 value=62 hue 0x00980903 (int) : min=-90 max=90 step=2 default=12287 value=0 gamma 0x00980910 (int) : min=1 max=30 step=1 default=57343 value=29 [...] Update the pre-existing DMA alignment code to catch this case. Link: raspberrypi#3148 Signed-off-by: Jonathan Bell <[email protected]>
Masquerading Interrupt split transfers as Control puts the transfer into the non-periodic handler in the hub. This stops the hub dropping complete-split data in the microframe after a CSPLIT should have arrived, improving resilience to host IRQ latency. Devices are none the wiser - the handshake tokens are the same. Originally devised by Hans Petter Selasky @ FreeBSD. Signed-off-by: Jonathan Bell <[email protected]>
The HFNUM register increments on every microframe in HS mode, and USB device drivers expect the returned frame count to relate to the overall frame. Right-shift the returned value by 3 to drop the microframe bits. Signed-off-by: Jonathan Bell <[email protected]>
dwc2_hc_start_transfer() overwrites hc->xfer_len for split-IN transfers. Drivers may not allocate buffers that are multiples of the endpoint max packet size, which may cause buffer overruns in the last transfer. The hardware needs HCTSIZ to be set to a multiple of HCCHAR.MPS, so trim chan->max_packet in dwc2_assign_and_init_hc(). Signed-off-by: Jonathan Bell <[email protected]>
I wasn't as disciplined with linking changes to github issues as I thought - I may have to trawl back through all the PRs mentioning dwc_otg to find the failure case / hardware involved to replicate the test. |
It will be make upstreaming easier, should somebody decide to do it. |
They seem fairly self-contained, and dwc2 is relatively low churn in mainline. |
And upstream likely won't care about links to our development or issue reports if the commit texts are good (which they seem to be) |
kernel: Updates to support CM5 on the Crystalfontz CFA050-PI-M See: raspberrypi/linux#6889 kernel: Side-port dwc_otg fixes to dwc2 See: raspberrypi/linux#6892 kernel: Also build kernel8_rt
kernel: Updates to support CM5 on the Crystalfontz CFA050-PI-M See: raspberrypi/linux#6889 kernel: Side-port dwc_otg fixes to dwc2 See: raspberrypi/linux#6892 kernel: Also build kernel8_rt
Thanks for porting this to dwc2. Since all of them are bugs, they will need a Fixes tag upstream. Otherwise these won't be backported. Additionally there might be discussions about 699b9da, because it's not clear if all dwc2 platforms are affected or just those which based on BCM2835 IP. |
This is a grab-bag of commits accumulated as a result of fixing things in dwc_otg and not dwc2. As dwc2 was derived from some variant of dwc_otg far in the past, the codebases have diverged.
With the recent emphasis on moving more platforms to dwc2, it's time to remove these inherited bugs. Or at least the ones that are obvious from the dwc_otg commit history.