Messages in this thread | | | Date | Fri, 18 Oct 2013 08:37:26 +0100 | From | "Jan Beulich" <> | Subject | Re: [PATCH] x86: honor ACPI FADT flag indicating absence of a CMOS RTC |
| |
>>> On 18.10.13 at 08:29, Ingo Molnar <mingo@kernel.org> wrote: > * Jan Beulich <JBeulich@suse.com> wrote: > >> We shouldn't be creating a corresponding platform device in that case. > > There's a sad lack of context in the changelog, how was it found, does > this address any problem/bug observed in practice, etc?
This was a result from code review in Xen hypervisor code in the context of ACPI 5 work there, which lead me to check whether Linux would honor that flag. No known issue in practice so far. Once the below got clarified, I can certainly extend the description in an eventual resubmission (albeit I would have though that fixing the not honoring of a firmware flag should speak for itself).
>> +#ifdef CONFIG_ACPI >> + if (acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC) >> + return -ENODEV; >> +#endif > > It might also be prudent to emit a KERN_INFO line telling that we don't > create the device - so that people who suddenly see unexpected breakage or > change in behavior have a chance to see what we've done?
There are so many other -ENODEV return paths here which don't emit messages that this seemed inappropriate, the more that a message _is_ being issued if the platform RTC device does get registered (and hence one could judge by the message disappearing between before and after the patch got applied).
Jan
| |