All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Zhang, Jonathan Zhixiong" <zjzhang@codeaurora.org>
To: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Matt Fleming <matt.fleming@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, ying.huang@intel.com, fu.wei@linaro.org,
	al.stone@linaro.org, bp@alien8.de, linux-efi@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH V4 1/4] efi: x86: rearrange efi_mem_attributes()
Date: Mon, 15 Jun 2015 15:24:46 -0700	[thread overview]
Message-ID: <557F50AE.50403@codeaurora.org> (raw)
In-Reply-To: <20150615170957.GC17685@codeblueprint.co.uk>


On 6/15/2015 10:09 AM, Matt Fleming wrote:
> On Fri, 12 Jun, at 06:01:44PM, Jonathan (Zhixiong) Zhang wrote:
>> From: "Jonathan (Zhixiong) Zhang" <zjzhang@codeaurora.org>
>>
>> x86 and ia64 implement efi_mem_attributes() differently. This
>> function needs to be available for other arch (such as arm64)
>> as well, such as for the purpose of ACPI/APEI.
>>
>> ia64 efi does not setup memmap variable and does not set
>> EFI_MEMMAP flag, so it needs to have its unique implementation
>> of efi_mem_attributes().
>
> Something like the above paragraph...
>
>> @@ -517,3 +517,21 @@ char * __init efi_md_typeattr_format(char *buf, size_t size,
>>   			 attr & EFI_MEMORY_UC      ? "UC"  : "");
>>   	return buf;
>>   }
>
> needs to go here, i.e. as documentation for efi_mem_atributes(). You
> need to explain why this function is marked as __weak at the function
> definition site.
>
>> +u64 __weak efi_mem_attributes(unsigned long phys_addr)
>> +{
>> +	efi_memory_desc_t *md;
>> +	void *p;
>> +
>> +	if (!efi_enabled(EFI_MEMMAP))
>> +		return 0;
>> +
>> +	for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
>> +		md = p;
>> +		if ((md->phys_addr <= phys_addr) &&
>> +		    (phys_addr < (md->phys_addr +
>> +		    (md->num_pages << EFI_PAGE_SHIFT))))
>> +			return md->attribute;
>> +	}
>> +	return 0;
>> +}
>
> because otherwise people are going to read this in the future and think,
>
>   "efi_mem_attribute() doesn't quite work how I want it to for my arch,
>   but it's __weak, so I'll override it"
>
> which is absolutely not the practice we should be promoting.
>
> How about something like this,
>
> 	/*
> 	 * efi_mem_attributes - lookup memmap attributes 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 attributes if the region
> 	 * was found in the memory map, 0 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.
> 	 */
>
Thank you Matt for the suggestion. Will do so accordingly.

-- 
Jonathan (Zhixiong) Zhang
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

WARNING: multiple messages have this Message-ID (diff)
From: "Zhang, Jonathan Zhixiong" <zjzhang-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
To: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
Cc: Matt Fleming
	<matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
	Ingo Molnar <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	"H. Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>,
	x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	ying.huang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
	fu.wei-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	al.stone-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org,
	linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH V4 1/4] efi: x86: rearrange efi_mem_attributes()
Date: Mon, 15 Jun 2015 15:24:46 -0700	[thread overview]
Message-ID: <557F50AE.50403@codeaurora.org> (raw)
In-Reply-To: <20150615170957.GC17685-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>


On 6/15/2015 10:09 AM, Matt Fleming wrote:
> On Fri, 12 Jun, at 06:01:44PM, Jonathan (Zhixiong) Zhang wrote:
>> From: "Jonathan (Zhixiong) Zhang" <zjzhang-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>>
>> x86 and ia64 implement efi_mem_attributes() differently. This
>> function needs to be available for other arch (such as arm64)
>> as well, such as for the purpose of ACPI/APEI.
>>
>> ia64 efi does not setup memmap variable and does not set
>> EFI_MEMMAP flag, so it needs to have its unique implementation
>> of efi_mem_attributes().
>
> Something like the above paragraph...
>
>> @@ -517,3 +517,21 @@ char * __init efi_md_typeattr_format(char *buf, size_t size,
>>   			 attr & EFI_MEMORY_UC      ? "UC"  : "");
>>   	return buf;
>>   }
>
> needs to go here, i.e. as documentation for efi_mem_atributes(). You
> need to explain why this function is marked as __weak at the function
> definition site.
>
>> +u64 __weak efi_mem_attributes(unsigned long phys_addr)
>> +{
>> +	efi_memory_desc_t *md;
>> +	void *p;
>> +
>> +	if (!efi_enabled(EFI_MEMMAP))
>> +		return 0;
>> +
>> +	for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
>> +		md = p;
>> +		if ((md->phys_addr <= phys_addr) &&
>> +		    (phys_addr < (md->phys_addr +
>> +		    (md->num_pages << EFI_PAGE_SHIFT))))
>> +			return md->attribute;
>> +	}
>> +	return 0;
>> +}
>
> because otherwise people are going to read this in the future and think,
>
>   "efi_mem_attribute() doesn't quite work how I want it to for my arch,
>   but it's __weak, so I'll override it"
>
> which is absolutely not the practice we should be promoting.
>
> How about something like this,
>
> 	/*
> 	 * efi_mem_attributes - lookup memmap attributes 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 attributes if the region
> 	 * was found in the memory map, 0 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.
> 	 */
>
Thank you Matt for the suggestion. Will do so accordingly.

-- 
Jonathan (Zhixiong) Zhang
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

  reply	other threads:[~2015-06-15 22:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-13  1:01 [PATCH V4 0/4] map GHES memory region according to EFI memory map Jonathan (Zhixiong) Zhang
2015-06-13  1:01 ` [PATCH V4 1/4] efi: x86: rearrange efi_mem_attributes() Jonathan (Zhixiong) Zhang
2015-06-15 17:09   ` Matt Fleming
2015-06-15 22:24     ` Zhang, Jonathan Zhixiong [this message]
2015-06-15 22:24       ` Zhang, Jonathan Zhixiong
2015-06-13  1:01 ` [PATCH V4 2/4] x86: acpi: add arch_apei_get_mem_attributes() Jonathan (Zhixiong) Zhang
2015-06-13  1:01 ` [PATCH V4 3/4] arm64: apei: implement arch_apei_get_mem_attributes() Jonathan (Zhixiong) Zhang
2015-06-13  1:01 ` [PATCH V4 4/4] acpi, apei: use appropriate pgprot_t to map GHES memory Jonathan (Zhixiong) Zhang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=557F50AE.50403@codeaurora.org \
    --to=zjzhang@codeaurora.org \
    --cc=al.stone@linaro.org \
    --cc=bp@alien8.de \
    --cc=fu.wei@linaro.org \
    --cc=hpa@zytor.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt.fleming@intel.com \
    --cc=matt@codeblueprint.co.uk \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=ying.huang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.