"Aneesh Kumar K.V" <aneesh.kumar@xxxxxxxxxxxxx> writes:
> On 5/14/19 9:59 AM, Dan Williams wrote:
>> On Mon, May 13, 2019 at 7:55 PM Aneesh Kumar K.V
>> <aneesh.kumar@xxxxxxxxxxxxx> wrote:
>>>
>>> We already add the start_pad to the resource->start but fails to section
>>> align the start. This make sure with altmap we compute the right first
>>> pfn when start_pad is zero and we are doing an align down of start address.
>>>
>>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@xxxxxxxxxxxxx>
>>> ---
>>> kernel/memremap.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/kernel/memremap.c b/kernel/memremap.c
>>> index a856cb5ff192..23d77b60e728 100644
>>> --- a/kernel/memremap.c
>>> +++ b/kernel/memremap.c
>>> @@ -59,9 +59,9 @@ static unsigned long pfn_first(struct dev_pagemap *pgmap)
>>> {
>>> const struct resource *res = &pgmap->res;
>>> struct vmem_altmap *altmap = &pgmap->altmap;
>>> - unsigned long pfn;
>>> + unsigned long pfn = PHYS_PFN(res->start);
>>>
>>> - pfn = res->start >> PAGE_SHIFT;
>>> + pfn = SECTION_ALIGN_DOWN(pfn);
>>
>> This does not seem right to me it breaks the assumptions of where the
>> first expected valid pfn occurs in the passed in range.
>>
>
> How do we define the first valid pfn? Isn't that at pfn_sb->dataoff ?
for altmap the pfn_first should be
pfn_first = altmap->base_pfn + vmem_altmap_offset(altmap);
?
-aneesh
