Messages in this thread | | | From | Bjorn Helgaas <> | Date | Thu, 26 Jul 2012 15:50:18 -0600 | Subject | Re: [PATCH v3 1/4] ACPI: Add acpi_pr_<level>() interfaces |
| |
On Thu, Jul 26, 2012 at 3:43 PM, Joe Perches <joe@perches.com> wrote: > On Thu, 2012-07-26 at 15:37 -0600, Bjorn Helgaas wrote: >> PNP0C01:00: new device for \_SB_.PCI0.ISA_.MBIO >> >> I fiddled with this a while ago; it would look something like this: > [] >> +static noinline_for_stack >> +char *acpi_name_string(char *buf, char *end, acpi_handle handle, >> + struct printf_spec spec, const char *fmt) >> +{ >> + acpi_status status; >> + struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL }; >> + u32 type = ACPI_SINGLE_NAME; >> + char *p = buf; >> + >> + if (fmt[0] == 'A') >> + type = ACPI_FULL_PATHNAME; > > maybe if (fmt[1] == 'f') > >> @@ -982,6 +1007,9 @@ char *pointer(const char *fmt, char *buf, char *end, void *ptr, >> } >> >> switch (*fmt) { >> + case 'A': >> + case 'a': >> + return acpi_name_string(buf, end, ptr, spec, fmt); > > There are only so many letters, it might be better to > just use 'a' and another 'f' after that if necessary > for "full". > > And of course that should be #ifdef'd too
Yes. I'm hesitant about this approach in general, because I don't think printing the ACPI path is something we should be doing often. It's not like a struct resource or a MAC address, where there are dozens or hundreds of users. I really think we should only print ACPI paths in one or two places, so adding a %p extension would waste a letter and encourage the wrong behavior.
| |