A FreeBSD DTB content handling question, via an example that currently crashes
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 03 Nov 2022 04:28:07 UTC
The following setup for a question is based on the RPi* support code in the kernel, code that leads to crashes for RPi* DTB's from over more than the last year. The question is really more general and the RPi* is an example. There is for the RPi* support: static int bcm_sdhci_attach(device_t dev) { . . . sc->sc_dma_ch = bcm_dma_allocate(BCM_DMA_CH_ANY); if (sc->sc_dma_ch == BCM_DMA_CH_INVALID) goto fail; . . . where: static struct bcm_dma_softc *bcm_dma_sc = NULL; . . . int bcm_dma_allocate(int req_ch) { struct bcm_dma_softc *sc = bcm_dma_sc; . . . mtx_lock(&sc->sc_mtx); . . . and bcm_dma_sc is made non-NULL via bcm_dma_probe/bcm_dma_attach (not shown). This used to not crash when the RPi* .dtb's used the order: QUOTE > dma@7e007000 { > compatible = "brcm,bcm2835-dma"; > . . . > mmc@7e300000 { > compatible = "brcm,bcm2835-mmc", "brcm,bcm2835-sdhci"; > . . . END QUOTE so the brcm,bcm2835-dma happened to be probed and attached before brcm,bcm2835-sdhci was probed and attached. However, since sometime after the 2021-08-05 RPi* firmware release, the more modern RPi* .dtb content has had the order: QUOTE > mmc@7e300000 { > compatible = "brcm,bcm2835-mmc", "brcm,bcm2835-sdhci"; > . . . > dma@7e007000 { > compatible = "brcm,bcm2835-dma"; > . . . END QUOTE This leads to the bcm_dma_allocate in bcm_sdhci_attach doing, in effect: struct bcm_dma_softc *sc = NULL; . . . mtx_lock(&sc->sc_mtx); because the bcm_dma_probe/bcm_dma_attach does not happen first. Result: crash. (But just avoiding the crash locally, would not be sufficient overall.) (I failed to find any DTB specification material indicating an ordering requirement for such things. If I'm wrong, point me at it.) Does FreeBSD have any principles that cover handling DTB content for both potential orders for such things? If yes, what is it? Are there good examples around to follow? === Mark Millard marklmi at yahoo.com