On Mon, Oct 11, 2021 at 10:42 AM Geert Uytterhoeven
<geert@xxxxxxxxxxxxxx> wrote:
> On Sat, Oct 9, 2021 at 11:24 AM Paul Menzel <pmenzel@xxxxxxxxxxxxx> wrote:
> > Am 28.09.21 um 09:50 schrieb Arnd Bergmann:
> > > From: Arnd Bergmann <arnd@xxxxxxxx>
> > +#
> > +# ARM System Control and Management Interface Protocol
> > +#
> > +# end of ARM System Control and Management Interface Protocol
> > +
> > +# CONFIG_FIRMWARE_MEMMAP is not set
> > +# CONFIG_GOOGLE_FIRMWARE is not set
> > +
> > +#
> > +# Tegra firmware driver
> > +#
> > +# end of Tegra firmware driver
> > +# end of Firmware Drivers
> > +
> > # CONFIG_GNSS is not set
> > CONFIG_MTD=m
> > # CONFIG_MTD_TESTS is not set
> > ```
> >
> > No idea if the entries could be hidden for platforms not supporting them.
> >
> > ARM System Control and Management Interface Protocol ----
> > [ ] Add firmware-provided memory map to sysfs
> > [ ] Google Firmware Drivers ----
> > Tegra firmware driver ----
>
> GOOGLE_FIRMWARE should probably depend on something.
> I highly doubt Google is running servers on e.g. h8300 and nds32.
GOOGLE_FIRMWARE is only the 'menuconfig' option that contains
the other options, but on architectures that have neither CONFIG_OF
nor CONFIG_ACPI, this is empty. Most architectures of course
do support or require CONFIG_OF, so it's unclear whether we should
show the options for coreboot. Since it's a software-only driver, I
would tend to keep showing it, given that coreboot can be ported
to every architecture. The DT binding [1] seems to be neither
Google nor Arm specific.
CONFIG_FIRMWARE_MEMMAP in turn can be used for
anything that has memory hotplug, and in theory additional
drivers that register with this interface.
I'd lean towards "leave as is" for both, to avoid having to
change the dependencies again whenever something else
can use these.
Arnd
[1] Documentation/devicetree/bindings/firmware/coreboot.txt
