Date: Wed, 2 Nov 2022 21:28:07 -0700 From: Mark Millard <marklmi@yahoo.com> To: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: A FreeBSD DTB content handling question, via an example that currently crashes Message-ID: <E4548BC9-9D87-4B19-9817-C738461D9A49@yahoo.com> References: <E4548BC9-9D87-4B19-9817-C738461D9A49.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 =3D bcm_dma_allocate(BCM_DMA_CH_ANY);
if (sc->sc_dma_ch =3D=3D BCM_DMA_CH_INVALID)
goto fail;
. . .
where:
static struct bcm_dma_softc *bcm_dma_sc =3D NULL;
. . .
int
bcm_dma_allocate(int req_ch)
{
struct bcm_dma_softc *sc =3D 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 =3D "brcm,bcm2835-dma";
> . . .
> mmc@7e300000 {
> compatible =3D "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 =3D "brcm,bcm2835-mmc", =
"brcm,bcm2835-sdhci";
> . . .
> dma@7e007000 {
> compatible =3D "brcm,bcm2835-dma";
> . . .
END QUOTE
This leads to the bcm_dma_allocate in bcm_sdhci_attach doing,
in effect:
struct bcm_dma_softc *sc =3D 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?
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E4548BC9-9D87-4B19-9817-C738461D9A49>