On Tue, Jan 28, 2020 at 8:28 PM John Garry <john.garry@xxxxxxxxxx> wrote: > > > >>>> > >>>> Signed-off-by: John Garry <john.garry@xxxxxxxxxx> > >>>> --- > >>>> drivers/soc/Makefile | 1 + > >>>> drivers/soc/acpi_generic.c | 102 +++++++++++++++++++++++++++++++++++++ > >>>> 2 files changed, 103 insertions(+) > >>>> create mode 100644 drivers/soc/acpi_generic.c > >>>> > >>>> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile > >>>> index 8b49d782a1ab..2a59a30a22cd 100644 > >>>> --- a/drivers/soc/Makefile > >>>> +++ b/drivers/soc/Makefile > >>>> @@ -3,6 +3,7 @@ > >>>> # Makefile for the Linux Kernel SOC specific device drivers. > >>>> # > >>>> > >>>> +obj-$(CONFIG_ACPI_PPTT) += acpi_generic.o > >>>> obj-$(CONFIG_ARCH_ACTIONS) += actions/ > >>>> obj-$(CONFIG_SOC_ASPEED) += aspeed/ > >>>> obj-$(CONFIG_ARCH_AT91) += atmel/ > >>> > >>> Based on everything I've seen so far, this should go under drivers/acpi instead. > >> > >> soc drivers seem to live in drivers/soc (non-arm32, anyway), so I > >> decided on this location. But drivers/acpi would also seem reasonable now. > > > > Hi Rafael, > > > Any reasons for not putting it into drivers/acpi/pptt.c specifically? > > . > > I don't think so. > > One thing is that the code does a one-time scan of the PPTT to find all > processor package nodes with ID structures to register the soc devices - > so we would need some new call from from acpi_init() for that. Or an extra initcall or similar. [Calls from acpi_init() are basically for things that need to be strictly ordered in a specific way for some reason.] Why would that be a problem?
