>>> On 09.03.14 at 17:20, Matt Fleming <matt@xxxxxxxxxxxxxxxxx> wrote: > On Fri, 07 Mar, at 03:25:37PM, Dan Carpenter wrote: >> >> You're on your own for fixing the complicated stuff like layering >> violations. I just do static checker stuff and sed fixes. ;) > > Thanks for the patch Dan. Nice catch. > > But I'm wondering if we can simply delete phys_efi_get_time() to avoid > the whole problem of doing GFP_KERNEL allocations under a spinlock. > > In fact, the whole EFI time stuff is looking a bit crusty. > > I only see two direct users of efi.get_time() outside of arch, > > drivers/char/efirtc.c > drivers/rtc/rtc-efi.c > > which are both "depends on IA64". And wrongly so. I continue to think that the fact that various firmware implementations are broken should not make us by default avoid using proper abstraction functionality whenever possible. There's a reason behind that abstraction after all... > For x86, all other callers are inside > arch/x86/platform/efi/efi.c, > > efi_set_rtc_mmss() > efi_get_time() > > neither of which have any callers - it all appears to be dead code. The > diff stat of deleting all this dead code isn't too bad either, > > arch/x86/platform/efi/efi.c | 151 ++--------------------------------------- > arch/x86/platform/efi/efi_64.c | 90 ------------------------ > 2 files changed, 5 insertions(+), 236 deletions(-) > > Thoughts? Please don't, except perhaps for the phys_efi_get_time() removal. Jan -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
