Messages in this thread | | | From | Stephen Boyd <> | Subject | Re: [PATCH v2 2/2] firmware: coreboot: Collapse platform drivers into bus core | Date | Wed, 08 Aug 2018 16:42:29 -0700 |
| |
Quoting Julius Werner (2018-08-08 12:07:30) > > +config GOOGLE_COREBOOT_TABLE_ACPI > > + tristate > > + default GOOGLE_COREBOOT_TABLE > > I don't think this helps in upgrading (as your commit message says) > unless you also keep the 'select GOOGLE_COREBOOT_TABLE' here, right?
Oh yes should be select, not default.
> > > -int coreboot_table_init(struct device *dev, void __iomem *ptr) > > +static int coreboot_table_init(struct device *dev, void __iomem *ptr) > > nit: There's little reason to keep coreboot_table_init() a separate > function now. Could maybe compact the code a little more if you merge > it into probe()? (Also could then do the signature sanity check before > trusting the length values to map the whole thing, which is probably a > good idea.)
Sure. I can make another patch for squashing that all together.
> > > if (ptr_header) { > > bus_unregister(&coreboot_bus_type); > > iounmap(ptr_header); > > Could ptr_header be handled by devm now, somehow?
Yes. It hasn't been devmified yet because that would be more things in one big patch. This is quickly blowing up!
> Also, don't you have > two bus_unregister() now (here and in coreboot_exit())? Or is that > intentional?
That's nice. I didn't notice that module_init() was registering the bus and then platform drivers could remove the bus later with the driver unbind. I'll move them both into the driver bind/unbind path, in another patch.
> > > +static struct platform_driver coreboot_table_driver = { > > + .probe = coreboot_table_probe, > > + .remove = coreboot_table_remove, > > + .driver = { > > + .name = "coreboot_table", > > + .acpi_match_table = ACPI_PTR(cros_coreboot_acpi_match), > > + .of_match_table = of_match_ptr(coreboot_of_match), > > Who takes precedence if they both exist? Will we have two > coreboot_table busses? (That would probably not be so good...)
I'm not aware of a system that has both ACPI and devicetree, so this isn't a problem.
| |