Hi Morimoto-san,
On Fri, 18 Apr 2025 at 00:31, Kuninori Morimoto
<kuninori.morimoto.gx@xxxxxxxxxxx> wrote:
> > > [SoC file]: Warning (spi_bus_bridge): /soc/spi@xxxx: incorrect #address-cells for SPI bus
> > > also defined at [Board file]
> > > [SoC file]: Warning (spi_bus_bridge): /soc/spi@xxxx: incorrect #size-cells for SPI bus
> > > also defined at [Board file]
> > >
> > > MSIOF dt-bindings doesn't load spi-controller.yaml, but why I got "spi_bus_bridge"
> > > warning ?? I wonder dt compiler (?) automatically check "spi" node ?
> > > I have tryed some code, my expectation seems correct (In case of node name was "spi@xxx",
> > > I got many SPI related warnings even though I didn't load spi-controller).
> >
> > These come from dtc, which makes its own assumptions:
> >
> > $ git grep spi_bus_bridge
> > scripts/dtc/checks.c:static void check_spi_bus_bridge(struct check
> > *c, struct dt_info *dti, struct node *node)
> > scripts/dtc/checks.c:WARNING(spi_bus_bridge, check_spi_bus_bridge,
> > NULL, &addr_size_cells);
> > scripts/dtc/checks.c:WARNING(spi_bus_reg, check_spi_bus_reg, NULL,
> > ®_format, &spi_bus_bridge);
> > scripts/dtc/checks.c: &spi_bus_bridge,
> >
> > Perhaps we do need to extend the use of role-specifying properties
> > like "interrupt-controller" (in Device Tree Specification v0.4 and in
> > dt-schema) and the few others in Documentation/devicetree/bindings:
> >
> > gpio-controller
> > mctp-controller
> > msi-controller
> > system-power-controller
>
> Hmm... but I'm not familiar with DT. Should I do it ??
I do not think you should do that.
This is something to be decided by the DT and SPI maintainers.
> Except from SPI warning, and focus to MSIOF-I2S, my patch itself is
> not so bad, right ?
> I will post v4 patch-set, with comment above.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
