Messages in this thread | | | From | Geert Uytterhoeven <> | Date | Tue, 27 Apr 2021 19:10:41 +0200 | Subject | Re: [PATCH v1 3/3] Revert "Revert "driver core: Set fw_devlink=on by default"" |
| |
Hi Florian,
On Tue, Apr 27, 2021 at 6:50 PM Florian Fainelli <f.fainelli@gmail.com> wrote: > On 4/27/2021 9:39 AM, Sudeep Holla wrote: > > On Tue, Apr 27, 2021 at 09:24:55AM -0700, Florian Fainelli wrote: > > > > [...] > > > >> This is a self inflicted problem that we have in that the bootloader > >> provides a Device Tree to the kernel which is massaged in different ways > >> and intends to stay backwards compatible as much as possible. And indeed > >> after removing the 'mboxes' property gets us going with fw_devlink=on. > >> > > > > I assume the bootloader checks the presence of SMC support and modifies > > the DT node accordingly. Can't it remove the mbox properties as it make > > no sense with SMC compatible ? However ... > > The bootloader has always assumed the SMC support was there from the day > we introduced it because it was. What changed is the way we advertised > to Linux that support. We used to have a custom mailbox driver that > would be pretty much what the ARM SMC transport eventually came to be. > > Since we still support earlier kernels that were deployed with the old > mailbox we cannot arbitrarily break that setup, especially as our > customers tend to be slow in picking up new kernel versions, fortunately > before they get to 5.13 we can mandate a new bootloader that may not be > compatible with their 4.1 kernel anymore, or at least not without some > backporting of the ARM SMC transport, that's all fair IMHO. > > >>> 2. IIUC, the fw_devlink might use information from DT to establish the > >>> dependency and having mailbox information in this context may be > >>> considered wrong as there is no dependency if it is using SMC. > >> > >> Right, unfortunately, short of having some special casing for SCMI and > >> checking that if we have both an "arm,smc-id" and "mboxes" phandle we > >> should prefer the former, there is not probably much that can be done > >> here. Do we want to do that? > > > > I *think* we could do that in the SCMI drivers, but: > > 1. I am not sure if that helps fw_devlinks if they are deriving the info > > purely based on DT > > 2. I am also afraid that someone might come up with exactly opposite > > requirement that let us prefer mailbox over SMC as they would use > > SMC only if h/w lacks proper mailbox support. I fear that we will get > > into rabbit hole trying to do something like that. > > That is true, and to get to the SCMI driver, even the base protocol you > must have been probed, so we have a nice chicken and egg problem. I > highly appreciate your time understanding the context and trying to find > a solution it is pretty clear that we must fix our FDT now.
Alternatively, you can have a quirk in the kernel that removes the phandle from the FDT during early boot.
Gr{oetje,eeting}s,
Geert
-- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
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
| |