On Tue, Aug 19, 2014 at 1:54 PM, Alan Cooper <alcooperx@xxxxxxxxx> 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@xxxxxxxxxxxxxx> wrote: >> On 8/12/2014 9:48 AM, Grant Likely wrote: >>> On Wed, 6 Aug 2014 17:02:44 -0500, Rob Herring <robherring2@xxxxxxxxx> wrote: >>>> On Wed, Aug 6, 2014 at 3:30 PM, Al Cooper <alcooperx@xxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
