On Wed, 24 Sep, at 09:26:33AM, Ingo Molnar wrote: > > So 'status' is unused - either use it for a less threatening > message, or remove the return code from the function and document > that failure is an option?
I think removing the return code is the way to go (I have a patch queued for v3.18 that adds call-site error messages). Something like this? --- >From 737ed0ea66f79fe1e5343f9f4cbdf7c0f57e1a0f Mon Sep 17 00:00:00 2001 From: Matt Fleming <matt.flem...@intel.com> Date: Thu, 11 Sep 2014 09:04:25 +0100 Subject: [PATCH] x86/efi: Delete misleading efi_printk() error message MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit A number of people are reporting seeing the "setup_efi_pci() failed!" error message in what used to be a quiet boot, https://bugzilla.kernel.org/show_bug.cgi?id=81891 The message isn't all that helpful because setup_efi_pci() can return a non-success error code for a variety of reasons, not all of them fatal. Let's drop the return code from setup_efi_pci*() altogether, since there's no way to process it in any meaningful way outside of the inner __setup_efi_pci*() functions. Reported-by: Darren Hart <dvh...@linux.intel.com> Reported-by: Josh Boyer <jwbo...@fedoraproject.org> Cc: Ulf Winkelvos <u...@winkelvos.de> Cc: Andre Müller <andre.mul...@web.de> Cc: Ingo Molnar <mi...@kernel.org> Cc: Linus Torvalds <torva...@linux-foundation.org> Signed-off-by: Matt Fleming <matt.flem...@intel.com> --- arch/x86/boot/compressed/eboot.c | 31 ++++++++++++++++--------------- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c index 8c311ab1b8c8..41ded80b3424 100644 --- a/arch/x86/boot/compressed/eboot.c +++ b/arch/x86/boot/compressed/eboot.c @@ -365,7 +365,7 @@ free_struct: return status; } -static efi_status_t +static void setup_efi_pci32(struct boot_params *params, void **pci_handle, unsigned long size) { @@ -408,8 +408,6 @@ setup_efi_pci32(struct boot_params *params, void **pci_handle, data = (struct setup_data *)rom; } - - return status; } static efi_status_t @@ -468,7 +466,7 @@ free_struct: } -static efi_status_t +static void setup_efi_pci64(struct boot_params *params, void **pci_handle, unsigned long size) { @@ -511,11 +509,18 @@ setup_efi_pci64(struct boot_params *params, void **pci_handle, data = (struct setup_data *)rom; } - - return status; } -static efi_status_t setup_efi_pci(struct boot_params *params) +/* + * There's no way to return an informative status from this function, + * because any analysis (and printing of error messages) needs to be + * done directly at the EFI function call-site. + * + * For example, EFI_INVALID_PARAMETER could indicate a bug or maybe we + * just didn't find any PCI devices, but there's no way to tell outside + * the context of the call. + */ +static void setup_efi_pci(struct boot_params *params) { efi_status_t status; void **pci_handle = NULL; @@ -532,7 +537,7 @@ static efi_status_t setup_efi_pci(struct boot_params *params) size, (void **)&pci_handle); if (status != EFI_SUCCESS) - return status; + return; status = efi_call_early(locate_handle, EFI_LOCATE_BY_PROTOCOL, &pci_proto, @@ -543,13 +548,12 @@ static efi_status_t setup_efi_pci(struct boot_params *params) goto free_handle; if (efi_early->is64) - status = setup_efi_pci64(params, pci_handle, size); + setup_efi_pci64(params, pci_handle, size); else - status = setup_efi_pci32(params, pci_handle, size); + setup_efi_pci32(params, pci_handle, size); free_handle: efi_call_early(free_pool, pci_handle); - return status; } static void @@ -1385,10 +1389,7 @@ struct boot_params *efi_main(struct efi_config *c, setup_graphics(boot_params); - status = setup_efi_pci(boot_params); - if (status != EFI_SUCCESS) { - efi_printk(sys_table, "setup_efi_pci() failed!\n"); - } + setup_efi_pci(boot_params); status = efi_call_early(allocate_pool, EFI_LOADER_DATA, sizeof(*gdt), (void **)&gdt); -- 1.9.3 -- Matt Fleming, Intel Open Source Technology Center -- 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/
