brcmfmac: Change mask array size to dynamic allocation#7269
Open
the-gabe wants to merge 663 commits intoraspberrypi:rpi-6.18.yfrom
Open
brcmfmac: Change mask array size to dynamic allocation#7269the-gabe wants to merge 663 commits intoraspberrypi:rpi-6.18.yfrom
the-gabe wants to merge 663 commits intoraspberrypi:rpi-6.18.yfrom
Conversation
If a device frequently NAKs, it can exhaust the scheduled handshakes in a frame. It will then not get polled by the controller until the next frame interval. This is most noticeable on FS devices as the controller schedules a small set of transactions only once per full-speed frame. Setting the ENH_PER_NAK_FS/LS bits in the GUCTL1 register increases the number of transactions that can be scheduled to Async (Control/Bulk) endpoints in the respective frame time. In the FS case, this only applies to FS devices directly connected to root ports. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
For platforms that have xHCI controllers attached over PCIe, and non-coherent routes to main memory, a theoretical race exists between posting new TRBs to a ring, and writing to the doorbell register. In a contended system, write traffic from the CPU may be stalled before the memory controller, whereas the CPU to Endpoint route is separate and not likely to be contended. Similarly, the DMA route from the endpoint to main memory may be separate and uncontended. Therefore the xHCI can receive a doorbell write and find a stale view of a transfer ring. In cases where only a single TRB is ping-ponged at a time, this can cause the endpoint to not get polled at all. Adding a readl() before the write forces a round-trip transaction across PCIe, definitively serialising the CPU along the PCI producer-consumer ordering rules. Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
The DHT11 datasheet is pretty cryptic, but it does suggest that after each integer value (humidity and temperature) there are "decimal" values. Validate these as integers in the range 0-9 and treat them as tenths of a unit. Link: raspberrypi#6220 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
…ctors The non-desktop property "Indicates the output should be ignored for purposes of displaying a standard desktop environment or console." That sounds like it should be true for all writeback and virtual connectors as you shouldn't render a desktop to them, so set it by default. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The limit of 32 planes per DRM device is dictated by the use of planes_mask returning a u32. Change to a u64 such that 64 planes can be supported by a device. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Some hardware will implement transpose as a rotation operation, which when combined with X and Y reflect can result in a rotation, but is a discrete operation in its own right. Add an option for transpose only. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Some connectors, particularly writeback, can implement flip or transpose operations as writing back to memory. Add a connector rotation property to control this. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
For devices where transfer lengths are not known upfront, there is a danger when the destination is wider than the source that partial words can be lost at the end of a transfer. Ideally the controller would be able to flush the residue, but it can't - it's not even possible to tell that there is any. Instead, allow the client driver to avoid the problem by setting a smaller width. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
SPI transfers are of defined length, unlike some UART traffic, so it is safe to let the DMA controller choose a suitable memory width. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
In order to avoid losing residue bytes when a receive is terminated early, set the destination width to single bytes. Link: raspberrypi#6365 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The xHC may commence Host Initiated Data Moves for streaming endpoints -
see USB3.2 spec s8.12.1.4.2.4. However, this behaviour is typically
counterproductive as the submission of UAS URBs in {Status, Data,
Command} order and 1 outstanding IO per stream ID means the device never
enters Move Data after a HIMD for Status or Data stages with the same
stream ID. For OUT transfers this is especially inefficient as the host
will start transmitting multiple bulk packets as a burst, all of which
get NAKed by the device - wasting bandwidth.
Also, some buggy UAS adapters don't properly handle the EP flow control
state this creates - e.g. RTL9210.
Set Host Initiated Data Move Disable to always defer stream selection to
the device. xHC implementations may treat this field as "don't care,
forced to 1" anyway - xHCI 1.2 s4.12.1.
Signed-off-by: Jonathan Bell <jonathan@raspberrypi.com>
Attempting to start a non-idle channel causes an error message to be logged, and is inefficient. Test for emptiness of the desc_issued list before doing so. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The Raspberry Pi RP1 includes 2 M3 cores running firmware. This driver adds a mailbox communication channel to them via a doorbell and some shared memory. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
The RP1 firmware runs a simple communications channel over some shared memory and a mailbox. This driver provides access to that channel. Signed-off-by: Phil Elwell <phil@raspberrypi.com> firmware: rp1: Simplify rp1_firmware_get Simplify the implementation of rp1_firmware_get, requiring its clients to have a valid 'firmware' property. Also make it return NULL on error. Link: raspberrypi#6593 Signed-off-by: Phil Elwell <phil@raspberrypi.com> firmware: rp1: Linger on firmware failure To avoid pointless retries, let the probe function succeed if the firmware interface is configured correctly but the firmware is incompatible. The value of the private drvdata field holds the outcome. Link: raspberrypi#6642 Signed-off-by: Phil Elwell <phil@raspberrypi.com> firmware: rp1: Rename to rp1-fw to avoid module name collision There is already the driver in drivers/mfd/rp1.ko, so having drivers/firmware/rp1.ko can cause issues when using modinfo and similar, and we can get errors with "Module rp1 is already loaded" when trying to load it. Rename the module so that the name is unique. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> mailbox: rp1: Don't claim channels in of_xlate The of_xlate method saves the calculated event mask in the con_priv field. It also rejects subsequent attempt to use that channel because the mask is non-zero, which causes a repeated instantiation of a client driver to fail. The of_xlate method is not meant to be a point of resource acquisition. Leave the con_priv initialisation, but drop the test that it was previously zero. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Provide remote access to the PIO hardware in RP1. There is a single instance, with 4 state machines. Signed-off-by: Phil Elwell <phil@raspberrypi.com> misc: rp1-pio: Support larger data transfers Add a separate IOCTL for larger transfer with a 32-bit data_bytes field. See: raspberrypi/utils#107 Signed-off-by: Phil Elwell <phil@raspberrypi.com> misc: rp1-pio: More logical probe sequence Sort the probe function initialisation into a more logical order. Signed-off-by: Phil Elwell <phil@raspberrypi.com> misc: rp1-pio: Minor cosmetic tweaks No functional change. Signed-off-by: Phil Elwell <phil@raspberrypi.com> misc: rp1-pio: Add in-kernel DMA support Add kernel-facing implementations of pio_sm_config_xfer and pio_xm_xfer_data. Signed-off-by: Phil Elwell <phil@raspberrypi.com> misc: rp1-pio: Handle probe errors Ensure that rp1_pio_open fails if the device failed to probe. Link: raspberrypi#6593 Signed-off-by: Phil Elwell <phil@raspberrypi.com> misc: rp1-pio: SM_CONFIG_XFER32 = larger DMA bufs Add an ioctl type - SM_CONFIG_XFER32 - that takes uints for the buf_size and buf_count values. Signed-off-by: Phil Elwell <phil@raspberrypi.com> misc/rp1-pio: Fix copy/paste error in pio_rp1.h As per the subject, there was a copy/paste error that caused pio_sm_unclaim from a driver to result in a call to pio_sm_claim. Fix it. Signed-off-by: Phil Elwell <phil@raspberrypi.com> misc: rp1-pio: Fix parameter checks wihout client Passing bad parameters to an API call without a pio pointer will cause a NULL pointer exception when the persistent error is set. Guard against that. Signed-off-by: Phil Elwell <phil@raspberrypi.com> misc: rp1-pio: Convert floats to 24.8 fixed point Floating point arithmetic is not supported in the kernel, so use fixed point instead. Signed-off-by: Phil Elwell <phil@raspberrypi.com> misc: rp1-pio: Error out on incompatible firmware If the RP1 firmware has reported an error then return that from the PIO probe function, otherwise defer the probing. Link: raspberrypi#6642 Signed-off-by: Phil Elwell <phil@raspberrypi.com> misc: rp1-pio: Demote fw probe error to warning Support for the RP1 firmware mailbox API is rolling out to Pi 5 EEPROM images. For most users, the fact that the PIO is not available is no cause for alarm. Change the message to a warning, so that it does not appear with "quiet" in cmdline.txt. Link: raspberrypi#6642 Signed-off-by: Phil Elwell <phil@raspberrypi.com> misc: rp1-pio: Don't just reuse the same DMA buf A missing pointer increment meant that not only was the same buffer being reused again and again, there was also no protection against using it simultaneously for multiple transfers. Fix that basic bug, and also move a similar increment to before the transfer is started, which feels less racy. See: raspberrypi#6919 Signed-off-by: Phil Elwell <phil@raspberrypi.com> misc: rp1-pio: Fix a config_xfer error path If the DMA channel allocation fails, the relevant dma_configs entry should be marked as no longer claimed, otherwise rp1_pio_sm_dma_free will be called with an error number as a DMA channel pointer. Signed-off-by: Phil Elwell <phil@raspberrypi.com> misc: rp1-pio: Request a DMA burst size of 8 Improve DMA performance by increasing the burst size to 8. Signed-off-by: Phil Elwell <phil@raspberrypi.com> misc: rp1-pio: Get burst size from DMA capabilities Although the PIO throughput benefits from larger burst sizes, only the first two DMA channels support a burst size of 8 - the others are capped at 4. To avoid misconfiguring the PIO hardware, retrieve the actual max_burst value from the DMA channel's capabilities. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Use the PIO hardware on RP1 to implement a PWM interface. Signed-off-by: Phil Elwell <phil@raspberrypi.com> pwm: rp1: use pwmchip_get_drvdata() instead of container_of() The PWM framework may not embed struct pwm_chip within the driver’s private data. Using container_of() can result in accessing invalid memory or NULL pointers, especially after recent kernel changes. Switch to pwmchip_get_drvdata() to reliably access the driver data. This resolves kernel warnings and probe failures seen after updating from kernel 6.12.28 to 6.12.34 [1] While at it remove the now obsolete `struct pwm_chip chip` member from `struct pwm_pio_rp1`. [1] raspberrypi#6971 Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de> pwm: rp1: Silently correct illegal values Remove the need for the user to know the limitations of this PWM implementation by adjusting configuration requests to be the closest acceptable value. Add a get_state method so that the actual values can be queried. Signed-off-by: Phil Elwell <phil@raspberrypi.com> pwm: rp1: Correct period off-by-1 error Correct the set_period method to pass (period - 1), as required by the PIO state machine. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
ws2812-pio-rp1 is a PIO-based driver for WS2812 LEDS. It creates a character device in /dev, the default name of which is /dev/leds<n>, where <n> is the instance number. The number of LEDS should be set in the DT overlay, as should whether it is RGB or RGBW, and the default brightness. Write data to the /dev/* entry in a 4 bytes-per-pixel format in RGBW order: RR GG BB WW RR GG BB WW ... The white values are ignored unless the rgbw flag is set for the device. To change the brightness, write a single byte to offset 0, 255 being full brightness and 0 being off. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Using increased bit depth for no reason increases power consumption, and differs from the behaviour prior to the conversion to use the HDMI helper functions. Initialise the state max_bpc and requested_max_bpc to the minimum value supported. This only affects Raspberry Pi, as the other users of the helpers (rockchip/inno_hdmi and sunx4i) only support a bit depth of 8. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
DSI0 and DSI1 have different widths for the command FIFO (24bit vs 32bit), but the driver was assuming the 32bit width of DSI1 in all cases. DSI0 also wants the data packed as 24bit big endian, so the formatting code needs updating. Handle the difference via the variant structure. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
During normal operations, the cursor position update is done through an asynchronous plane update, which on the vc4 driver basically just modifies the right dlist word to move the plane to the new coordinates. However, when we have the overscan margins setup, we fall back to a regular commit when we are next to the edges. And since that commit happens to be on a cursor plane, it's considered a legacy cursor update by KMS. The main difference it makes is that it won't wait for its completion (ie, next vblank) before returning. This means if we have multiple commits happening in rapid succession, we can have several of them happening before the next vblank. In parallel, our dlist allocation is tied to a CRTC state, and each time we do a commit we end up with a new CRTC state, with the previous one being freed. This means that we free our previous dlist entry (but don't clear it though) every time a new one is being committed. Now, if we were to have two commits happening before the next vblank, we could end up freeing reusing the same dlist entries before the next vblank. Indeed, we would start from an initial state taking, for example, the dlist entries 10 to 20, then start a commit taking the entries 20 to 30 and setting the dlist pointer to 20, and freeing the dlist entries 10 to 20. However, since we haven't reach vblank yet, the HVS is still using the entries 10 to 20. If we were to make a new commit now, chances are the allocator are going to give the 10 to 20 entries back, and we would change their content to match the new state. If vblank hasn't happened yet, we just corrupted the active dlist entries. A first attempt to solve this was made by creating an intermediate dlist buffer to store the current (ie, as of the last commit) dlist content, that we would update each time the HVS is done with a frame. However, if the interrupt handler missed the vblank window, we would end up copying our intermediate dlist to the hardware one during the composition, essentially creating the same issue. Since making sure that our interrupt handler runs within a fixed, constrained, time window would require to make Linux a real-time kernel, this seems a bit out of scope. Instead, we can work around our original issue by keeping the dlist slots allocation longer. That way, we won't reuse a dlist slot while it's still in flight. In order to achieve this, instead of freeing the dlist slot when its associated CRTC state is destroyed, we'll queue it in a list. A naive implementation would free the buffers in that queue when we get our end of frame interrupt. However, there's still a race since, just like in the shadow dlist case, we don't control when the handler for that interrupt is going to run. Thus, we can end up with a commit adding an old dlist allocation to our queue during the window between our actual interrupt and when our handler will run. And since that buffer is still being used for the composition of the current frame, we can't free it right away, exposing us to the original bug. Fortunately for us, the hardware provides a frame counter that is increased each time the first line of a frame is being generated. Associating the frame counter the image is supposed to go away to the allocation, and then only deallocate buffers that have a counter below or equal to the one we see when the deallocation code should prevent the above race from occurring. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Users are reporting running out of DLIST memory. Add a debugfs file to dump out all the allocations. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
We have a read-modify-write race when updating SCALER_DISPCTRL for underrun and end-of-frame interrupts. Ideally it would be fixed via a spinlock or similar, but that will require a reasonable amount of study to ensure we don't get deadlocks. The underrun reporting is only for debug, so disable it for now. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The dmabuf import already checks that the backing buffer is contiguous and rejects it if it isn't. vc4 also requires that the buffer is in the bottom 1GB of RAM, and this is all correctly defined via dma-ranges. However the kernel silently uses swiotlb to bounce dma buffers around if they are in the wrong region. This relies on dma sync functions to be called in order to copy the data to/from the bounce buffer. DRM is based on all memory allocations being coherent with the GPU so that any updates to a framebuffer will be acted on without the need for any additional update. This is fairly fundamentally incompatible with needing to call dma_sync_ to handle the bounce buffer copies, and therefore we have to detect and reject mappings that use bounce buffers. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
DSI0 is misbehaving and needs to action things on vblank to work around it. Add a new hook to call across during vblank. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The initialisation sequence differs slightly from the documentation in that the clocks are meant to be running before resets and similar. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
vc4_dsi_bridge_disable wasn't resetting things during shutdown, so add that in. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The block must be enabled for the FIFO resets to be actioned, so ensure this is the case. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The pixel to byte FIFO appears to not always reset correctly, which can lead to colour errors and/or horizontal shifts. Reset on every vblank to work around the issue. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The TC358762 bridge and panel decodes the mode differently on DSI0 to DSI1 for no obvious reason, and results in a shift off the screen. Whilst it would be possible to change the compatible used for the panel, that then messes up Pi5. As it appears to be restricted to vc4 DSI0, fix up the mode in vc4_dsi. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Some DSI peripheral drivers wish to send commands in the post_disable or panel unprepare callback. These are called after the DSI host's disable call, but before the host's post_disable if pre_enable_prev_first is set. Don't reset the block until post_disable to allow these commands to be sent. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
The 10bit column format from the HEVC codec is supported by the PISP BE, so add the configuration. It requires some additional handling as it packs 3 10bit samples into 32 bits, with 2 bits of padding. Alignment and calculating strides is therefore not quite as straightforward. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Add the option to release the audio pins, effectively disabling audio usage. See: raspberrypi/rpi-eeprom#801 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Add an overlay so spi10 can be disabled on Raspberry Pi 5. This allows the firmware to continue to access EEPROM after boot so that AB firmware updates can be performed. Signed-off-by: Mathew Blowers <mathew.blowers@raspberrypi.com>
Fixes the following build failure:
drivers/gpio/gpio-pwm.c:108:26: error: assignment to 'int (*)(struct gpio_chip *, unsigned int, int)' from incompatible pointer type 'void (*)(struct gpio_chip *, unsigned int, int)' [-Wincompatible-pointer-types]
108 | pwm_gpio->gc.set = pwm_gpio_set;
| ^
drivers/gpio/gpio-pwm.c:30:13: note: 'pwm_gpio_set' declared here
30 | static void pwm_gpio_set(struct gpio_chip *gc, unsigned int off, int val)
| ^~~~~~~~~~~~
Fixes: 8b95d76 ("drivers/gpio: Add a driver that wraps the PWM API as a GPIO controller")
Signed-off-by: Juerg Haefliger <juerg.haefliger@canonical.com>
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
SIMPLE_PANEL and REGULATOR_RASPBERRYPI_TOUCHSCREEN_V2 are already in the defconfig. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
CM4S is unusual in that the high GPIOs are not used for RGMII, so give the GPIOs names. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
…er EEPROM Add a GPIO hog on GPIO 57 (active high, output-low) to enable the onboard bootloader EEPROM on CM4S. The hog is disabled by default and can be activated via dtparam=enable_eeprom=on in config.txt. Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
Add RS-485 support to UARTs 0 to 4 of Pi 5. Signed-off-by: Giampiero Baggiani <giampiero@sferalabs.cc>
Extend the pcf857x overlay to support all the chipsets, which are also compatible. Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
The eee dtparam is also available on Pi4 and CM4 via the __overrides__ in bcm2711-rpi-ds.dtsi. Update the description accordingly. Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
Extend the mcp2515 overlay to support the spi3 and spi5 buses available on newer Raspberry Pi hardware. This adds the required dormant fragments to disable the default spidev drivers, updates the __overrides__ routing logic, and updates the README accordingly. Signed-off-by: Kevin Beichler <k.beichler@gmx.com>
This a purely cosmetic change to move the sgp30 option in the i2c-sensor README to be in a more logical place. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Add a parameter to the i2c-sensor overlay to support the STS3X sensors from Sensirion. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Add a parameter to the i2c-sensor overlay to support the SHT85 sensors from Sensirion. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Enable the Silicon Labs CP2112 HID USB to I2C/GPIO bridge driver as a module. Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Signed-off-by: Maíra Canal <mcanal@igalia.com>
On current firmware versions, RPI_FIRMWARE_SET_CLOCK_STATE doesn't actually power off the clock. To achieve meaningful power savings, the clock rate must be set to the minimum before disabling. This might be fixed in future firmware releases. Rather than pushing rate management to clock consumers, handle it directly in the clock framework's prepare/unprepare callbacks. In unprepare, set the rate to the firmware-reported minimum before disabling the clock. In prepare, for clocks marked with `maximize` (currently v3d), restore the rate to the maximum after enabling. Signed-off-by: Maíra Canal <mcanal@igalia.com>
If PIXEL_CLK or HEVC_CLK is disabled during boot, the firmware will skip HSM initialization, which would result in a bus lockup. However, those clocks are consumed by drivers (vc4 and HEVC decoder drivers, respectively), which means that they can be enabled/disabled by the drivers. Mark those clocks as CLK_IGNORE_UNUSED to allow them to be disabled by drivers when appropriate. Acked-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Maíra Canal <mcanal@igalia.com>
The bcm2835_asb_control() function uses a tight polling loop to wait for the ASB bridge to acknowledge a request. During intensive workloads, this handshake intermittently fails for V3D's master ASB on BCM2711, resulting in "Failed to disable ASB master for v3d" errors during runtime PM suspend. As consequence, the failed power-off leaves V3D in a broken state, leading to bus faults or system hangs on later accesses. As the timeout is insufficient in some scenarios, increase the polling timeout from 1us to 5us, which is still negligible in the context of a power domain transition. Also, move the start timestamp to after the MMIO write, as the write latency is counted against the timeout, reducing the effective wait time for the hardware to respond. Signed-off-by: Maíra Canal <mcanal@igalia.com>
Simplify optional reset handling by using the function devm_reset_control_get_optional_exclusive(). Reviewed-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Maíra Canal <mcanal@igalia.com>
Move all resource allocation operations before actually enabling the clock, as those operations don't require the GPU to be powered on. This is a preparation for runtime PM support. The next commit will move all code related to powering on and initiating the GPU into the runtime PM resume callback and all resource allocation will happen before resume(). Reviewed-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Maíra Canal <mcanal@igalia.com>
Commit 90a64ad ("drm/v3d: Get rid of pm code") removed the last bits of power management code that V3D had, which were actually never hooked. Therefore, currently, the GPU clock is enabled during probe and only disabled when removing the driver. Implement proper power management using the kernel's Runtime PM framework. Signed-off-by: Maíra Canal <mcanal@igalia.com>
d3d8a3d introduced this, but this breaks when building with Clang with -Werror,-Warray-bounds
Author
|
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 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.
d3d8a3d introduced this, but this breaks when building with Clang with -Werror,-Warray-bounds