[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZibT-38ZfEkIZrtG@rric.localdomain>
Date: Mon, 22 Apr 2024 23:17:47 +0200
From: Robert Richter <rrichter@....com>
To: Alison Schofield <alison.schofield@...el.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Dan Williams <dan.j.williams@...el.com>, linux-acpi@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-cxl@...r.kernel.org,
Len Brown <lenb@...nel.org>
Subject: Re: [PATCH v3 2/5] ACPI/NUMA: Print CXL Early Discovery Table (CEDT)
On 22.04.24 13:56:00, Alison Schofield wrote:
> On Fri, Apr 19, 2024 at 04:02:00PM +0200, Robert Richter wrote:
> > The CEDT contains similar entries as the SRAT. For diagnostic reasons
> > print the CEDT same style as the SRAT.
> >
> > Adding also a pr_info() when successfully adding a CFMWS memory range.
> >
> > Suggested-by: Alison Schofield <alison.schofield@...el.com> # CEDT node info
>
> Ah, I see you annotated the Suggested-by. I did suggest the pr_info
> when we extend or add a node during CFMWS parsing.
That's what I meant here and what I have added to this patch with this
update.
>
> There is an update in acpitools for CEDT decode and dump[1] offering
> pretty dumps of this info. Is this printing for convenience or for
> something else?
No, this helped early boot debugging of kernel and ACPI issues since
CEDT entries are important for this. For acpitools you need the
machine to be up already. If it is not part of the kernel log there
would be a 2nd step needed to get this information from. The patch
also lifts CEDT logging to the same level as for SRAT.
I hope that makes sense?
Thanks,
-Robert
>
> [1] https://github.com/acpica/acpica/pull/939
>
> -- Alison
Powered by blists - more mailing lists