On 24 August 2017 at 11:11, Jan Beulich <JBeulich@xxxxxxxx> wrote: >>>> On 24.08.17 at 11:52, <ard.biesheuvel@xxxxxxxxxx> wrote: >> On 24 August 2017 at 10:48, Jan Beulich <JBeulich@xxxxxxxx> wrote: >>>>>> On 24.08.17 at 11:18, <ard.biesheuvel@xxxxxxxxxx> wrote: >>>> On 24 August 2017 at 10:11, Jan Beulich <JBeulich@xxxxxxxx> wrote: >>>>> --- 4.13-rc6-EFI.orig/drivers/firmware/efi/efi.c >>>>> +++ 4.13-rc6-EFI/drivers/firmware/efi/efi.c >>>>> @@ -819,6 +819,35 @@ u64 __weak efi_mem_attributes(unsigned l >>>>> return 0; >>>>> } >>>>> >>>>> +/* >>>>> + * efi_mem_type - lookup memmap type for physical address >>>>> + * @phys_addr: the physical address to lookup >>>>> + * >>>>> + * Search in the EFI memory map for the region covering @phys_addr. >>>>> + * Returns the EFI memory type if the region was found in the memory >>>>> + * map, EFI_RESERVED_TYPE (zero) otherwise. >>>>> + * >>>>> + * Despite being marked __weak, most architectures should *not* >>>>> + * override this function. It is __weak solely for the benefit >>>>> + * of ia64 which has a funky EFI memory map that doesn't work >>>>> + * the same way as other architectures. >>>>> + */ >>>>> +u32 __weak efi_mem_type(unsigned long phys_addr) >>>> >>>> Why is this __weak now? >>> >>> As the comment (matching the one ahead of efi_mem_attributes()) >>> says, in particular for ia64 to be able to override it. >>> >> >> Apologies. I don't know how I could miss that ... >> >> If it already has its own version, I'd prefer we just add #ifndef >> CONFIG_IA64 around it instead. > > Which would then preclude other environments to override it. ... which is what the comment says in the first place. > I have such a case in an out-of-tree patch set (which is why > I've stumbled over this and the open-coding of it in the BGRT > code in the first place). Plus to me it seems preferable to have > both functions consistent (of course you could then as for > the __weak to be dropped from the other one). > Making symbols __weak in mainline to accommodate unidentified out-of-tree users is something I'd prefer to avoid. -- 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
