Messages in this thread | | | Date | Tue, 4 Oct 2022 19:26:19 +0200 | From | Greg KH <> | Subject | Re: [PATCH v12] firmware: google: Implement cbmem in sysfs driver |
| |
On Tue, Oct 04, 2022 at 10:56:58AM -0600, Jack Rosenthal wrote: > On 2022-10-04 at 10:51 +0200, Greg KH wrote: > > > + A list of ids known to Coreboot can be found in the coreboot > > > + source tree at > > > + ``src/commonlib/bsd/include/commonlib/bsd/cbmem_id.h``. > > > > That will not age well, why not point to the reference in the kernel > > tree instead? > > There is no copy in the kernel tree.
Then how does the kernel know what to print out? Why not add such a reference somewhere?
> > > config GOOGLE_COREBOOT_TABLE > > > tristate "Coreboot Table Access" > > > depends on HAS_IOMEM && (ACPI || OF) > > > diff --git a/drivers/firmware/google/Makefile b/drivers/firmware/google/Makefile > > > index d17caded5d88..8151e323cc43 100644 > > > --- a/drivers/firmware/google/Makefile > > > +++ b/drivers/firmware/google/Makefile > > > @@ -7,5 +7,8 @@ obj-$(CONFIG_GOOGLE_MEMCONSOLE) += memconsole.o > > > obj-$(CONFIG_GOOGLE_MEMCONSOLE_COREBOOT) += memconsole-coreboot.o > > > obj-$(CONFIG_GOOGLE_MEMCONSOLE_X86_LEGACY) += memconsole-x86-legacy.o > > > > > > +# Must come after coreboot_table.o, as this driver depends on that bus type. > > > > Doesn't the linker handle this for us? > > Not in the case of compiling as a built-in module: I observed in this > scenario the order in the Makefile deterimined the module initialization > order, and, if this were to be listed alphabetically, the coreboot_table > module would not have been loaded before the cbmem module.
So is this a runtime dependancy or a symbol/link dependancy?
link one is easy, we always go off of the Makefile order, and if you move it and it breaks, well obviously move it back. If it's a runtime order, then how will you handle one being a module and the other not?
thanks,
greg k-h
| |