On Thu, Dec 08, 2016 at 05:31:13PM +0000, David Howells wrote: > Lukas Wunner <lukas@xxxxxxxxx> wrote: > > > +out_efi_err: > > > + pr_efi_err(sys_table_arg, "Could not determine UEFI Secure Boot status.\n"); > > > + if (status == EFI_NOT_FOUND) > > > + return efi_secureboot_mode_disabled; > > > + return efi_secureboot_mode_unknown; > > > +} > > > > In the out_efi_err path, the if-statement needs to come before the > > pr_efi_err() call. Otherwise it would be a change of behaviour for > > ARM to what we have now. > > As I understand it, if the BIOS is an EFI BIOS, these variables must exist - > in which case I would argue that the pr_efi_err-statement should be before > the if-statement. The existing efi_get_secureboot() in arm-stub.c returns 0 in the EFI_NOT_FOUND case and the "Could not determine ..." error is only printed if the return value is < 0. So you're introducing a change of behaviour. If you feel the change is justified, fine, I won't argue against it since I don't have a dog in this fight. But obviously it's something that a reader of your patch will trip over, so at least explain it in the commit message. It would also be good to explain why you're moving the pr_efi_err() calls in the first place. ISTR it has to do with the different interpretation of an error, what I wrote in my previous e-mail: x86 defaults to considering secureboot disabled on error, ARM to enabled. I'm not even sure that's correct, I'd have to go re-read the whole thread, which again shows that there's too little documentation in the commit message. Thanks, Lukas -- 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
