src/sys/arm/broadcom/bcm2835, branch main

arm/bcm2835: Release mailbox resources on attach failure

2026-06-14T16:51:04Z

Also remove the rid variable since it was unused. Signed-off-by: Haoxiang Li Reviewed-by: vexeduxr Pull-Request: https://github.com/freebsd/freebsd-src/pull/2255

pci: bcm2838: cleanup on attach failure to fix devmatch panic

2026-06-04T05:15:14Z

Specifically on the RPi CM4, we currently don't set the controller up right and it never moves into the ready state (we don't observe the link active bit). Failure to cleanup here actually results in a panic not long after, due to a use-after-free in the rman bits. Further down in pci_host_generic, we have some rman stashed in the softc that are initialized and placed onto the rman tailq, then the softc is later freed without an rman_fini() to pull them off of the tailq properly. Note that PCIe on this board won't come up at boot without something plugged in, so it currently can't be booted with an empty slot with the intent to hotplug a supported card. Some issues with controller startup have been observed with Broadcom NICs in the wild, but no problems have been observed with other NICs and a variety of different PCIe cards. Shout-out to Vince for the extensive debugging and analysis to arrive at this conclusion. Reviewed by: andrew, imp Differential Revision: https://reviews.freebsd.org/D56897

bcm2835_sdhci: Clean up DMA resources on attach failure

2026-05-27T18:12:09Z

bcm_sdhci_attach() allocates a DMA channel with bcm_dma_allocate() before creating the bus_dma tag and map. If a later initialization step fails, the common error path releases the interrupt and memory resources, but leaves the DMA channel allocated. Call bcm_dma_free() for cleanup, as it already performs the required internal checks and can therefore be invoked directly. Signed-off-by: Haoxiang Li Reviewed by: mhorne MFC after: 3 days Pull Request: https://github.com/freebsd/freebsd-src/pull/2241

pmap_change_attr: Use void * instead of vm_offset_t

2026-04-23T17:05:53Z

Effort: CHERI upstreaming Reviewed by: kib Sponsored by: AFRL, DARPA Pull Request: https://github.com/freebsd/freebsd-src/pull/2068

raspberry_virtgpio: fix OF_hasprop() usage

2026-04-16T16:15:41Z

The function returns a bool. This driver was merged recently (by me) and I missed this instance. While here, adjust the ofw_bus_status_okay() call similarly. This function still returns an int, but this usage is more widely used in our drivers. No functional change intended. MFC after: 3 days Sponsored by: The FreeBSD Foundation Fixes: b60cd486a652 ("ofw: bool-ify OF_hasprop()")

Fix xhci detection on Raspberry Pi 400

2026-04-16T06:05:20Z

If you use the FreeBSD pre-build Raspberry Pi image, it does not include the specific .dtb file for the Raspberry Pi 400. On this hardware, it will fall back to attempting to load the Raspberry Pi 4 .dtb file instead. The Pi 4 .dtb file reports the board compatible name as "raspberrypi,4-model-b" The Pi 400 .dtb file reports the board compatible name as "raspberrypi,400" However, it's even better to use the generic name. When using the official Pi 400 .dtb file from the Raspberry Pi Firmware collection, the FreeBSD xhci driver currently fails to recognize this, and thus fails to initialize the xhci device. This means no external USB, or internal USB (which feeds the build-in keyboard) The official Raspberry Pi FreeBSD image has been working on the Pi 400 "on accident" simply because it didn't include the Pi 400 .dtb file prior to this. But the Stratipi Builder uses the full Raspberry Pi firmware suite and hit this bug. As a note: this is probably also a bug on the Compute Module 4 (CM4), but I don't own one of these devices in order to test/validate it. MFC After: 5 days Reviewed by: imp, Ali Mashtizadeh Pull Request: https://github.com/freebsd/freebsd-src/pull/2115

bcm2835_virtgpio: Add driver for virtual GPIO controller on some RPi models

2026-03-31T19:54:21Z

This driver enables bcm2835-virtgpio GPIO controller found on RPi3B and some CM boards. On which, the ACT (green) LED is connected to this controller. It is essential for FreeBSD to have this driver to control this LED. It will be exposed via gpioled(4). Reviewed by: mhorne MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D51456

arm bcm2835: Appease a warning from GCC

2026-02-17T20:46:48Z

No code currently uses the vc_audio_msg_type_names array of strings. Reported by: -Wunused-variable Differential Revision: https://reviews.freebsd.org/D55162

arm/broadcom: Fix a typo in a source code comment

2026-02-08T11:58:39Z

- s/preceeded/preceded/ MFC after: 3 days

vchiq: fix build with clang 21

2026-01-16T14:02:35Z

When compiling vchiq with clang 21, the following -Werror warning is produced: sys/contrib/vchiq/interface/vchiq_arm/vchiq_arm.c:728:27: error: default initialization of an object of type 'VCHIQ_QUEUE_MESSAGE32_T' with const member leaves the object uninitialized [-Werror,-Wdefault-const-init-field-unsafe] 728 | VCHIQ_QUEUE_MESSAGE32_T args32; | ^ sys/contrib/vchiq/interface/vchiq_arm/vchiq_ioctl.h:151:40: note: member 'elements' declared 'const' here 151 | const /*VCHIQ_ELEMENT_T * */ uint32_t elements; | ^ While the warning is formally correct, the 'args32' object is immediately initialized after its declaration. Therefore, suppress the warning. MFC after: 3 days