[PATCH] vchiq driver

[Arnd Bergmann]

On Sat, Aug 13, 2022 at 8:15 AM Stefan Wahren <stefan.wahren at i2se.com> wrote:
> Am 12.08.22 um 22:57 schrieb Steven A. Falco:
> > On 8/12/22 04:31 PM, Stefan Wahren wrote:
> >> Hi Steven,
> >>
> >> Am 12.08.22 um 19:13 schrieb Steven A. Falco:
> >>> I am using Fedora Linux on a Raspberry Pi 4B.  When I use the
> >>> kernel-provided device tree, I have a /dev/vchiq node, but if I
> >>> instead use the firmware-provided device tree, this node is not
> >>> created.
> >> not sure which kernel is meant, but it's not the mainline kernel.
> >
> > I'm running Fedora Rawhide, which has kernel 5.19.0-65.fc37.aarch64.
> > I thought that kernel was current, but I can see that I was wrong. :-)
>
> sorry, i was wrong. I checked this. The wrong vchiq compatible is
> accidentally enabled on the Raspberry Pi 4 & Co. Thanks for reporting
> this issue
>
>          mailbox at 7e00b840 {
>              compatible = "brcm,bcm2835-vchiq";
>              reg = <0x7e00b840 0x3c>;
>              interrupts = <0x00 0x22 0x04>;
>          };
>
> @Florian, @Arnd
>
> What do you think about how to handle this? The vchiq driver is in
> staging and Greg is not very happy about new features like bcm2711
> support until the TODOs are finished.
>
> Replacing the compatible with the proper one would fix the device tree,
> but would stop probing of the driver for the few brave mainline users
> (regression from user point of view).
>
> Should we add "brcm,bcm2711-vchiq" to compatibles even the driver
> doesn't supported it yet or better keep as it is?

Does the staging driver work with the bcm2711 vchiq at the moment?

If the device is compatible with the old interface, keeping both the
old and the new ID is not wrong, and I don't see a problem with adding
the more specific identifier along with it.

The question is whether there need to be any additional properties
that have to be documented in the binding first, otherwise establishing
a new compatible string may get us into backwards compatibility
problems later on.

        Arnd