On Mon, Oct 28, 2019 at 8:13 AM Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote: > > On Tuesday, October 22, 2019 6:48:12 PM CET Dan Williams wrote: > > On Tue, Oct 22, 2019 at 3:02 AM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > > > > > > On Fri, Oct 18, 2019 at 11:25 AM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > > > > > > > > On Wed, Oct 16, 2019 at 3:13 AM Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > > > > > > > > > > Currently hmat.c lives under an "hmat" directory which does not enhance > > > > > the description of the file. The initial motivation for giving hmat.c > > > > > its own directory was to delineate it as mm functionality in contrast to > > > > > ACPI device driver functionality. > > > > > > > > > > As ACPI continues to play an increasing role in conveying > > > > > memory location and performance topology information to the OS take the > > > > > opportunity to co-locate these NUMA relevant tables in a combined > > > > > directory. > > > > > > > > > > numa.c is renamed to srat.c and moved to drivers/acpi/numa/ along with > > > > > hmat.c. > > > > > > > > > > Cc: Len Brown <lenb@xxxxxxxxxx> > > > > > Cc: Keith Busch <kbusch@xxxxxxxxxx> > > > > > Acked-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx> > > > > > Reviewed-by: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx> > > > > > Signed-off-by: Dan Williams <dan.j.williams@xxxxxxxxx> > > > > > > > > Please note that https://patchwork.kernel.org/patch/11078171/ is being > > > > pushed to Linus (it is overdue anyway), so if it is pulled, there will > > > > be a merge conflict with this patch. > > > > > > > > Respin maybe? > > > > > > Actually, would you mind it if I took this one into the ACPI tree right away? > > > > > > There's https://patchwork.kernel.org/patch/11198373/ queued up that, > > > again, will clash with it. > > > > > > Also, there is the generic Initiator proximity domains series from > > > Jonathan depending on it and I would like to move forward with that > > > one if there are no objections. > > > > Given Ard has acked all the EFI core and ARM changes can we proceed > > with merging the EFI Specific Purpose Memory series through Rafael's > > tree? It would need acks from x86 maintainers. > > In the face of the lack of responses here, I think I will apply this patch > alone and expose a stable branch containing it in case somebody else wants > to pull it in. Ok. x86 folks, any concerns about Rafael taking the whole lot?
