>>> On 18.10.13 at 08:29, Ingo Molnar <mi...@kernel.org> wrote: > * Jan Beulich <jbeul...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
