dwc_otg: checking the urb->transfer_buffer too early (#3332) #3341
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The log line was missing a closing \n, so wasn't added to the log immediately. Adds the function of the V4L2 device that is being unregistered too. Signed-off-by: Dave Stevenson <[email protected]>
…vals vidioc_enum_framesizes and vidioc_enum_frameintervals weren't implemented, therefore clients couldn't enumerate the supported resolutions. Implement them by forwarding on to the sensor driver. Signed-off-by: Dave Stevenson <[email protected]>
The default resolution code was different for each role as compressed formats need to pass bytesperline as 0 and set up customised buffer sizes. This is common setup, therefore amend get_sizeimage and get_bytesperline to do the correct thing whether compressed or uncompressed. Signed-off-by: Dave Stevenson <[email protected]>
The calculation converting from V4L2 bytesperline to MMAL width had an operator ordering issue that lead to Bayer raw 10 (and 12 and 14) setting an incorrect stride for the buffer. Correct this operation ordering issue. Signed-off-by: Dave Stevenson <[email protected]>
The ISP has no need for heights to be a multiple of macroblock sizes, therefore doesn't require the align on the height. Remove it for the ISP role. (It is required for the codecs). Signed-off-by: Dave Stevenson <[email protected]>
vchiq_mmal_component_init calls init_event_context for the control port, but vchiq_mmal_component_finalise didn't free it, causing a memory leak.. Add the free call. Signed-off-by: Dave Stevenson <[email protected]>
On error, vchiq_mmal_component_init could leave the event context allocated for ports. Clean them up in the error path. Signed-off-by: Dave Stevenson <[email protected]>
The encryption is only mandatory to be enforced when both sides are using Secure Simple Pairing and this means the key size check makes only sense in that case. On legacy Bluetooth 2.0 and earlier devices like mice the encryption was optional and thus causing an issue if the key size check is not bound to using Secure Simple Pairing. Fixes: d5bb334 ("Bluetooth: Align minimum encryption key size for LE and BR/EDR connections") Signed-off-by: Marcel Holtmann <[email protected]> Cc: [email protected]
V4L2 uses nsecs, whilst MMAL uses usecs, but the code wasn't converting between them. This upsets video encode rate control. Signed-off-by: Dave Stevenson <[email protected]>
Video encode can use the frame rate for rate control calculations, therefore plumb it through from V4L2's [S|G]_PARM ioctl. Signed-off-by: Dave Stevenson <[email protected]>
The logic to drive the data line high to implement a strong pullup assumed that the pin was already an output - setting a value does not change an input. See: raspberrypi/firmware#1143 Signed-off-by: Phil Elwell <[email protected]>
Signed-off-by: Phil Elwell <[email protected]>
The ioremapping creates mappings within the vmalloc area. The equivalent early function, create_mapping, now checks that the requested explicit virtual address is between VMALLOC_START and VMALLOC_END. As there is no reason to have any correlation between the physical and virtual addresses, put the required mappings at VMALLOC_START and above. Signed-off-by: Phil Elwell <[email protected]>
The change which introduced CONFIG_BCM2835_FAST_MEMCPY unconditionally changed the behaviour of arm_copy_from_user. The page pinning code is not safe on ARMv7 if LPAE & high memory is enabled and causes crashes which look like PTE corruption. Make __copy_from_user_memcpy conditional on CONFIG_2835_FAST_MEMCPY=y which is really an ARMv6 / Pi1 optimization and not necessary on newer ARM processors.
This commit adds the basic Broadcom STB PCIe controller. Missing is the ability to process MSI and also handle dma-ranges for inbound memory accesses. These two functionalities are added in subsequent commits. The PCIe block contains an MDIO interface. This is a local interface only accessible by the PCIe controller. It cannot be used or shared by any other HW. As such, the small amount of code for this controller is included in this driver as there is little upside to put it elsewhere. Signed-off-by: Jim Quinlan <[email protected]>
The Broadcom STB PCIe host controller is intimately related to the
memory subsystem. This close relationship adds complexity to how cpu
system memory is mapped to PCIe memory. Ideally, this mapping is an
identity mapping, or an identity mapping off by a constant. Not so in
this case.
Consider the Broadcom reference board BCM97445LCC_4X8 which has 6 GB
of system memory. Here is how the PCIe controller maps the
system memory to PCIe memory:
memc0-a@[ 0....3fffffff] <=> pci@[ 0....3fffffff]
memc0-b@[100000000...13fffffff] <=> pci@[ 40000000....7fffffff]
memc1-a@[ 40000000....7fffffff] <=> pci@[ 80000000....bfffffff]
memc1-b@[300000000...33fffffff] <=> pci@[ c0000000....ffffffff]
memc2-a@[ 80000000....bfffffff] <=> pci@[100000000...13fffffff]
memc2-b@[c00000000...c3fffffff] <=> pci@[140000000...17fffffff]
Although there are some "gaps" that can be added between the
individual mappings by software, the permutation of memory regions for
the most part is fixed by HW. The solution of having something close
to an identity mapping is not possible.
The idea behind this HW design is that the same PCIe module can
act as an RC or EP, and if it acts as an EP it concatenates all
of system memory into a BAR so anything can be accessed. Unfortunately,
when the PCIe block is in the role of an RC it also presents this
"BAR" to downstream PCIe devices, rather than offering an identity map
between its system memory and PCIe space.
Suppose that an endpoint driver allocs some DMA memory. Suppose this
memory is located at 0x6000_0000, which is in the middle of memc1-a.
The driver wants a dma_addr_t value that it can pass on to the EP to
use. Without doing any custom mapping, the EP will use this value for
DMA: the driver will get a dma_addr_t equal to 0x6000_0000. But this
won't work; the device needs a dma_addr_t that reflects the PCIe space
address, namely 0xa000_0000.
So, essentially the solution to this problem must modify the
dma_addr_t returned by the DMA routines routines. There are two
ways (I know of) of doing this:
(a) overriding/redefining the dma_to_phys() and phys_to_dma() calls
that are used by the dma_ops routines. This is the approach of
arch/mips/cavium-octeon/dma-octeon.c
In ARM and ARM64 these two routines are defiend in asm/dma-mapping.h
as static inline functions.
(b) Subscribe to a notifier that notifies when a device is added to a
bus. When this happens, set_dma_ops() can be called for the device.
This method is mentioned in:
http://lxr.free-electrons.com/source/drivers/of/platform.c?v=3.16#L152
where it says as a comment
"In case if platform code need to use own special DMA
configuration, it can use Platform bus notifier and
handle BUS_NOTIFY_ADD_DEVICE event to fix up DMA
configuration."
Solution (b) is what this commit does. It uses its own set of
dma_ops which are wrappers around the arch_dma_ops. The
wrappers translate the dma addresses before/after invoking
the arch_dma_ops, as appropriate.
Signed-off-by: Jim Quinlan <[email protected]>
This commit adds MSI to the Broadcom STB PCIe host controller. It does not add MSIX since that functionality is not in the HW. The MSI controller is physically located within the PCIe block, however, there is no reason why the MSI controller could not be moved elsewhere in the future. Since the internal Brcmstb MSI controller is intertwined with the PCIe controller, it is not its own platform device but rather part of the PCIe platform device. Signed-off-by: Jim Quinlan <[email protected]>
The DT bindings description of the Brcmstb PCIe device is described. This node can be used by almost all Broadcom settop box chips, using ARM, ARM64, or MIPS CPU architectures. Signed-off-by: Jim Quinlan <[email protected]>
The initial brcmstb PCIe driver - originally taken from the V3(?) patch set - has been modified significantly for the BCM2711. Signed-off-by: Phil Elwell <[email protected]>
The legacy peripherals can only address the first gigabyte of RAM, so ensure that DMA allocations are restricted to that region. Signed-off-by: Phil Elwell <[email protected]>
Signed-off-by: Phil Elwell <[email protected]>
Add a filter for "spurious" Transfer Complete interrupts, attempting to make it as specific as possible: * INT_DATA_END (transfer complete) is set * There is a stop command in progress * There is no data transfer in progress Signed-off-by: Phil Elwell <[email protected]>
The emmc2 interface of the BCM2838 should be integrated in sdhci-iproc to avoid code redundancy. Except 32 bit only access no other quirks are known yet. Add an additional compatible string for upstream proposal. Signed-off-by: Stefan Wahren <[email protected]>
The HWRNG on the BCM2838 is compatible to iproc-rng200, so add the support to this driver instead of bcm2835-rng. Signed-off-by: Stefan Wahren <[email protected]>
The BCM2838 has an AVS TMON hardware block. This adds the necessary support to the brcmstb_thermal driver ( no trip handling ). Signed-off-by: Stefan Wahren <[email protected]>
Conditional on a new compatible string, change the pagelist encoding such that the top 24 bits are the pfn, leaving 8 bits for run length (-1). Signed-off-by: Phil Elwell <[email protected]>
Set defaults for TX and RX packet coalescing to be equivalent to: # ethtool -C eth0 tx-frames 10 # ethtool -C eth0 rx-usecs 50 This may be something we want to set via DT parameters in the future. Signed-off-by: Phil Elwell <[email protected]>
Adds the Infineon IRS1125 driver module to the downstream defconfigs. Signed-off-by: Markus Proeller <[email protected]>
The Infineon IRS1125 is a CSI2 time of flight depth sensor which has a suitable V4L2 subdevice driver. Add an overlay for configuring it. Signed-off-by: Markus Proeller <[email protected]>
The Allo Digione board wants a fixed MCLKDIV of 256. See: raspberrypi#3296 Signed-off-by: Phil Elwell <[email protected]>
Turning off the OTG USB block saves power. Since it requires the use of the dwc2 overlay to make use of it, we can disable it by default. Signed-off-by: Phil Elwell <[email protected]>
Required for compliance testing for the encoder. Signed-off-by: Dave Stevenson <[email protected]>
The output queue buffer type is now OUTPUT_MPLANE. Fixes: 5e484a3 staging: bcm2835-codec: switch to multi-planar API Signed-off-by: Dave Stevenson <[email protected]>
G_PARM default was invalid as 0/0, and the driver didn't check the value set in S_PARM wasn't 0/0. Signed-off-by: Dave Stevenson <[email protected]>
When represented with a dmabuf buffer that had previously been imported, there was a call to dma_buf_get without a matching dma_buf_put. This left dmabufs in limbo after all users had supposedly released them. Signed-off-by: Dave Stevenson <[email protected]>
Requires new display power mailbox call to be present. Signed-off-by: James Hughes <[email protected]>
Enabling CONFIG_CGROUP_BPF allows BPF filters to access cgroup-local storage, which is useful for control network interactions at the cgroup level. CONFIG_BPF_SYSCALL is required to make use of it. See: raspberrypi#3294 Signed-off-by: Phil Elwell <[email protected]>
MMU exception conditions are reported in the V3D_MMU_CTRL register as write-1-to-clear (W1C) bits. The MMU interrupt handling code clears any exceptions, but does so by masking out any other bits and writing the result back. There are some important control bits in that register, including MMU_ENABLE, so a safer approach is to simply write back the value just read unaltered. This patch doesn't remove the cause of the apparent PTE errors, but it does reduce the impact to just an error in the kernel log. Signed-off-by: Phil Elwell <[email protected]>
Signed-off-by: popcornmix <[email protected]>
Signed-off-by: Phil Elwell <[email protected]>
… interface Setting the v3d clock to low value allows firmware to handle dvfs in case where v3d hardware is not being actively used (e.g. console use). Signed-off-by: popcornmix <[email protected]>
For performance/power it is beneficial to adjust gpu clocks with arm clock. This is how the downstream cpufreq driver works Signed-off-by: popcornmix <[email protected]>
Signed-off-by: popcornmix <[email protected]>
This is controlled by firmware, see clk-raspberrypi.c Signed-off-by: popcornmix <[email protected]>
Signed-off-by: popcornmix <[email protected]>
popcornmix
force-pushed
the
rpi-5.3.y
branch
3 times, most recently
from
049b87a to
216c323
Compare
After enable the HIGHMEM and VMSPLIT_3G, the dwc_otg driver doesn't work well on Pi2/3 boards with 1G physical ram. Users experience the failure when copying a file of 600M size to the USB stick. And at the same time, the dmesg shows: usb 1-1.1.2: reset high-speed USB device number 8 using dwc_otg sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK blk_update_request: I/O error, dev sda, sector 3024048 op 0x1:(WRITE) flags 0x4000 phys_seg 15 prio class 0 When this happens, the sg_buf sent to the driver is located in the highmem region, the usb_sg_init() in the core/message.c will leave transfer_buffer to NULL if the sg_buf is in highmem, but in the dwc_otg driver, it returns -EINVAL unconditionally if transfer_buffer is NULL. The driver can handle the situation of buffer to be NULL, if it is in DMA mode, it will convert an address from transfer_dma. But if the conversion fails or it is in the PIO mode, we should check buffer and return -EINVAL if it is NULL. BugLink: https://bugs.launchpad.net/bugs/1852510 Signed-off-by: Hui Wang <[email protected]>
jason77-wang
force-pushed
the
rpi-5.3.y
branch
from
9cb735e to
7ce66d7
Compare
popcornmix
added a commit
to raspberrypi/firmware
that referenced
this pull request
Dec 11, 2019
kernel: dwc_otg: checking the urb->transfer_buffer too early See: raspberrypi/linux#3341 kernel: overlays: Make mcp342x run-time compatible See: https://www.raspberrypi.org/forums/viewtopic.php?f=107&t=258294 kernel: Add Support for simultaneous use of JustBoom DAC and JustBoom Digi based Audio boards See: raspberrypi/linux#3337 kernel: drm/vc4: Correct disabling of render nodes See: raspberrypi/linux#3365 firmware: power: Use Pi4 PMIC values on Pi3+ firmware: Fix filtered handling of array variables See: #1296 firmware: Update libfdt to v1.5.1+ See: raspberrypi/userland#582 firmware: dtoverlay: Extend DT parameter syntax firmware: memorymap: Include FW revision in start.elf userland: mmal: Support 64 bit clients See: raspberrypi/userland#586
popcornmix
added a commit
to Hexxeh/rpi-firmware
that referenced
this pull request
Dec 11, 2019
kernel: dwc_otg: checking the urb->transfer_buffer too early See: raspberrypi/linux#3341 kernel: overlays: Make mcp342x run-time compatible See: https://www.raspberrypi.org/forums/viewtopic.php?f=107&t=258294 kernel: Add Support for simultaneous use of JustBoom DAC and JustBoom Digi based Audio boards See: raspberrypi/linux#3337 kernel: drm/vc4: Correct disabling of render nodes See: raspberrypi/linux#3365 firmware: power: Use Pi4 PMIC values on Pi3+ firmware: Fix filtered handling of array variables See: raspberrypi/firmware#1296 firmware: Update libfdt to v1.5.1+ See: raspberrypi/userland#582 firmware: dtoverlay: Extend DT parameter syntax firmware: memorymap: Include FW revision in start.elf userland: mmal: Support 64 bit clients See: raspberrypi/userland#586
big-henry
pushed a commit
to big-henry/mirror_ubuntu-bionic-kernel
that referenced
this pull request
Feb 17, 2020
…#3332) BugLink: https://bugs.launchpad.net/bugs/1852510 After enable the HIGHMEM and VMSPLIT_3G, the dwc_otg driver doesn't work well on Pi2/3 boards with 1G physical ram. Users experience the failure when copying a file of 600M size to the USB stick. And at the same time, the dmesg shows: usb 1-1.1.2: reset high-speed USB device number 8 using dwc_otg sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK blk_update_request: I/O error, dev sda, sector 3024048 op 0x1:(WRITE) flags 0x4000 phys_seg 15 prio class 0 When this happens, the sg_buf sent to the driver is located in the highmem region, the usb_sg_init() in the core/message.c will leave transfer_buffer to NULL if the sg_buf is in highmem, but in the dwc_otg driver, it returns -EINVAL unconditionally if transfer_buffer is NULL. The driver can handle the situation of buffer to be NULL, if it is in DMA mode, it will convert an address from transfer_dma. But if the conversion fails or it is in the PIO mode, we should check buffer and return -EINVAL if it is NULL. raspberrypi/linux#3341 Signed-off-by: Hui Wang <[email protected]> Acked-by: Connor Kuehl <[email protected]> Acked-by: Stefan Bader <[email protected]> Signed-off-by: Connor Kuehl <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
26 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch should apply to 5.3.y/5.4.y/4.19.y and all other major branches. After applying this patch, we could enable HIGHMEM, LPAE and VMSPLIT_3G for armv7 kernel, then we could use one kernel to support rpi2/3/4 boards.
After enable the HIGHMEM and VMSPLIT_3G, the dwc_otg driver doesn't
work well on Pi2/3 boards with 1G physical ram. Users experience
the failure when copying a file of 600M size to the USB stick. And
at the same time, the dmesg shows:
usb 1-1.1.2: reset high-speed USB device number 8 using dwc_otg
sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
blk_update_request: I/O error, dev sda, sector 3024048 op 0x1:(WRITE) flags 0x4000 phys_seg 15 prio class 0
When this happens, the sg_buf sent to the driver is located in the
highmem region, the usb_sg_init() in the core/message.c will leave
transfer_buffer to NULL if the sg_buf is in highmem, but in the
dwc_otg driver, it returns -EINVAL unconditionally if transfer_buffer
is NULL.
The driver can handle the situation of buffer to be NULL, if it is in
DMA mode, it will convert an address from transfer_dma.
But if the conversion fails or it is in the PIO mode, we should check
buffer and return -EINVAL if it is NULL.
BugLink: https://bugs.launchpad.net/bugs/1852510
Signed-off-by: Hui Wang [email protected]