[PATCH] of: Allow mem_reserve of memory with a base address of zero

[PATCH] of: Allow mem_reserve of memory with a base address of zero

[Al Cooper]

__reserved_mem_reserve_reg() won't reserve memory if the base address
is zero. This change removes the check for a base address of zero and
allows it to be reserved.

Allowing the first 4K of memory to be reserved will help solve a
problem on some ARM systems where the the first 16K of memory is
unused and becomes allocable memory. This will prevent this memory
from being used for DMA by drivers like the USB OHCI driver which
consider a physical address of zero to be illegal.

Signed-off-by: Al Cooper <alcooperx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 drivers/of/fdt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 9aa012e..379ad4f 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -453,7 +453,7 @@ static int __init __reserved_mem_reserve_reg(unsigned long node,
 		base = dt_mem_next_cell(dt_root_addr_cells, &prop);
 		size = dt_mem_next_cell(dt_root_size_cells, &prop);
 
-		if (base && size &&
+		if (size &&
 		    early_init_dt_reserve_memory_arch(base, size, nomap) == 0)
 			pr_debug("Reserved memory: reserved region for node '%s': base %pa, size %ld MiB\n",
 				uname, &base, (unsigned long)size / SZ_1M);
-- 
1.9.0.138.g2de3478

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of: Allow mem_reserve of memory with a base address of zero

[Rob Herring]

On Wed, Aug 6, 2014 at 3:30 PM, Al Cooper <alcooperx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> __reserved_mem_reserve_reg() won't reserve memory if the base address
> is zero. This change removes the check for a base address of zero and
> allows it to be reserved.
>
> Allowing the first 4K of memory to be reserved will help solve a
> problem on some ARM systems where the the first 16K of memory is
> unused and becomes allocable memory. This will prevent this memory
> from being used for DMA by drivers like the USB OHCI driver which
> consider a physical address of zero to be illegal.

OHCI driver or hardware? I agree with the change, but really think
this should be fixed in the driver in the former case or a property of
the OHCI node in the latter.

Rob

>
> Signed-off-by: Al Cooper <alcooperx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
>  drivers/of/fdt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 9aa012e..379ad4f 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -453,7 +453,7 @@ static int __init __reserved_mem_reserve_reg(unsigned long node,
>                 base = dt_mem_next_cell(dt_root_addr_cells, &prop);
>                 size = dt_mem_next_cell(dt_root_size_cells, &prop);
>
> -               if (base && size &&
> +               if (size &&
>                     early_init_dt_reserve_memory_arch(base, size, nomap) == 0)
>                         pr_debug("Reserved memory: reserved region for node '%s': base %pa, size %ld MiB\n",
>                                 uname, &base, (unsigned long)size / SZ_1M);
> --
> 1.9.0.138.g2de3478
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of: Allow mem_reserve of memory with a base address of zero

[Grant Likely]

On Wed, 6 Aug 2014 17:02:44 -0500, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Wed, Aug 6, 2014 at 3:30 PM, Al Cooper <alcooperx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > __reserved_mem_reserve_reg() won't reserve memory if the base address
> > is zero. This change removes the check for a base address of zero and
> > allows it to be reserved.
> >
> > Allowing the first 4K of memory to be reserved will help solve a
> > problem on some ARM systems where the the first 16K of memory is
> > unused and becomes allocable memory. This will prevent this memory
> > from being used for DMA by drivers like the USB OHCI driver which
> > consider a physical address of zero to be illegal.
> 
> OHCI driver or hardware? I agree with the change, but really think
> this should be fixed in the driver in the former case or a property of
> the OHCI node in the latter.

I'm not hard and fast on that. I don't think it is unreasonable to
reserve the base of memory as the platform level if there is a bug
causing DMA to fail at that address.

If this is a common problem (and not merely a few boards) then I agree.
Fixing it this way is just asking for the same problem to show up again
and again on new boards that haven't explicitly reserved the memory.

g.

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of: Allow mem_reserve of memory with a base address of zero

[Laura Abbott]

On 8/12/2014 9:48 AM, Grant Likely wrote:
> On Wed, 6 Aug 2014 17:02:44 -0500, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Wed, Aug 6, 2014 at 3:30 PM, Al Cooper <alcooperx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> __reserved_mem_reserve_reg() won't reserve memory if the base address
>>> is zero. This change removes the check for a base address of zero and
>>> allows it to be reserved.
>>>
>>> Allowing the first 4K of memory to be reserved will help solve a
>>> problem on some ARM systems where the the first 16K of memory is
>>> unused and becomes allocable memory. This will prevent this memory
>>> from being used for DMA by drivers like the USB OHCI driver which
>>> consider a physical address of zero to be illegal.
>>
>> OHCI driver or hardware? I agree with the change, but really think
>> this should be fixed in the driver in the former case or a property of
>> the OHCI node in the latter.
> 
> I'm not hard and fast on that. I don't think it is unreasonable to
> reserve the base of memory as the platform level if there is a bug
> causing DMA to fail at that address.
> 
> If this is a common problem (and not merely a few boards) then I agree.
> Fixing it this way is just asking for the same problem to show up again
> and again on new boards that haven't explicitly reserved the memory.
> 
> g.
> 

Reserving memory at physical address 0 has been semi-common on our boards
for many issues. Sometimes it's been for temporary debugging purposes
to catch an unknown driver corrupting physical address 0. Sometimes it has
been a permanent fix to a hardware limitation.

Thanks,
Laura

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of: Allow mem_reserve of memory with a base address of zero

[Alan Cooper]

I guess another way to look at this is, why disallow reserving memory
at location 0?

Al

On Tue, Aug 12, 2014 at 1:02 PM, Laura Abbott <lauraa-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
> On 8/12/2014 9:48 AM, Grant Likely wrote:
>> On Wed, 6 Aug 2014 17:02:44 -0500, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> On Wed, Aug 6, 2014 at 3:30 PM, Al Cooper <alcooperx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>> __reserved_mem_reserve_reg() won't reserve memory if the base address
>>>> is zero. This change removes the check for a base address of zero and
>>>> allows it to be reserved.
>>>>
>>>> Allowing the first 4K of memory to be reserved will help solve a
>>>> problem on some ARM systems where the the first 16K of memory is
>>>> unused and becomes allocable memory. This will prevent this memory
>>>> from being used for DMA by drivers like the USB OHCI driver which
>>>> consider a physical address of zero to be illegal.
>>>
>>> OHCI driver or hardware? I agree with the change, but really think
>>> this should be fixed in the driver in the former case or a property of
>>> the OHCI node in the latter.
>>
>> I'm not hard and fast on that. I don't think it is unreasonable to
>> reserve the base of memory as the platform level if there is a bug
>> causing DMA to fail at that address.
>>
>> If this is a common problem (and not merely a few boards) then I agree.
>> Fixing it this way is just asking for the same problem to show up again
>> and again on new boards that haven't explicitly reserved the memory.
>>
>> g.
>>
>
> Reserving memory at physical address 0 has been semi-common on our boards
> for many issues. Sometimes it's been for temporary debugging purposes
> to catch an unknown driver corrupting physical address 0. Sometimes it has
> been a permanent fix to a hardware limitation.
>
> Thanks,
> Laura
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] of: Allow mem_reserve of memory with a base address of zero

[Rob Herring]

On Tue, Aug 19, 2014 at 1:54 PM, Alan Cooper <alcooperx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> I guess another way to look at this is, why disallow reserving memory
> at location 0?

Please don't top post in replies to the list.

This absolutely should be fixed and I will apply. The /memreserve/ tag
already supports this as I reserve address 0 on the platform I
maintain and the new reserved regions should support the same. I'm
only questioning the reasoning for this case. With the limitations in
dma masks, there's not an easy way to fix this just for OHCI.

Rob

>
> Al
>
> On Tue, Aug 12, 2014 at 1:02 PM, Laura Abbott <lauraa-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
>> On 8/12/2014 9:48 AM, Grant Likely wrote:
>>> On Wed, 6 Aug 2014 17:02:44 -0500, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>> On Wed, Aug 6, 2014 at 3:30 PM, Al Cooper <alcooperx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>> __reserved_mem_reserve_reg() won't reserve memory if the base address
>>>>> is zero. This change removes the check for a base address of zero and
>>>>> allows it to be reserved.
>>>>>
>>>>> Allowing the first 4K of memory to be reserved will help solve a
>>>>> problem on some ARM systems where the the first 16K of memory is
>>>>> unused and becomes allocable memory. This will prevent this memory
>>>>> from being used for DMA by drivers like the USB OHCI driver which
>>>>> consider a physical address of zero to be illegal.
>>>>
>>>> OHCI driver or hardware? I agree with the change, but really think
>>>> this should be fixed in the driver in the former case or a property of
>>>> the OHCI node in the latter.
>>>
>>> I'm not hard and fast on that. I don't think it is unreasonable to
>>> reserve the base of memory as the platform level if there is a bug
>>> causing DMA to fail at that address.
>>>
>>> If this is a common problem (and not merely a few boards) then I agree.
>>> Fixing it this way is just asking for the same problem to show up again
>>> and again on new boards that haven't explicitly reserved the memory.
>>>
>>> g.
>>>
>>
>> Reserving memory at physical address 0 has been semi-common on our boards
>> for many issues. Sometimes it's been for temporary debugging purposes
>> to catch an unknown driver corrupting physical address 0. Sometimes it has
>> been a permanent fix to a hardware limitation.
>>
>> Thanks,
>> Laura
>>
>> --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html