Mike Rapoport wrote:
[..]
> > > +config RAMDAX
> > > + tristate "Support persistent memory interfaces on RAM carveouts"
> > > + depends on OF || X86
> >
> > I see no compile time dependency for CONFIG_OF. The one call to
> > dev_of_node() looks like it still builds in the CONFIG_OF=n case. For
> > CONFIG_X86 the situation is different because the kernel needs
> > infrastructure to build the device.
> >
> > So maybe change the dependency to drop OF and make it:
> >
> > depends on X86_PMEM_LEGACY if X86
>
> We can't put if in a depends statement :(
Ugh, yeah, whoops.
> My intention with "depends on OF || X86" was that if it's not really
> possible to use this driver if it's not X86 or OF because there's nothing
> to define a platform device for ramdax to bind.
>
> Maybe what we actually need is
>
> select X86_PMEM_LEGACY_DEVICE if X86
> default n
> so that it could be only explicitly enabled in the configuration and if it
> is, it will also enable X86_PMEM_LEGACY_DEVICE on x86.
> With default set to no it won't be build "accidentailly", but OTOH cloud
> providers can disable X86_PMEM_LEGACY and enable RAMDAX and distros can
> build them as modules on x86 and architectures that support OF.
>
> What do you think?
Perhaps:
depends on X86_PMEM_LEGACY || OF || COMPILE_TEST
...because it is awkward to select symbols that has dependencies that
may be missing, and it shows that this driver has no compile time
dependencies on those symbols.
[..]
> With how driver_override is implemented it's possible to get fireworks with
> any platform device :)
True.
> I'll add a manual check for of_match_node() to be on the safer side.
Sounds good.
