On Thu, 2019-10-31 at 16:57 +0100, Christoph Hellwig wrote: > On Thu, Oct 31, 2019 at 04:53:13PM +0100, Nicolas Saenz Julienne wrote: > > > > +#define ARM64_ZONE_DMA_BITS 30 > > > > + > > > > /* > > > > * We need to be able to catch inadvertent references to memstart_addr > > > > * that occur (potentially in generic code) before > > > > arm64_memblock_init() > > > > @@ -424,6 +427,8 @@ void __init arm64_memblock_init(void) > > > > else > > > > arm64_dma_phys_limit = PHYS_MASK + 1; > > > > > > > > + zone_dma_bits = ARM64_ZONE_DMA_BITS; > > > > + > > > > reserve_crashkernel(); > > > > > > This actually adds a new limit, as there wasn't one before for arm64. > > > > Well, as zone_dma_bits is only relevant in dma/direct when ZONE_DMA is > > defined > > I figured it doesn't matter if the variable is set conditionally to ZONE_DMA > > or > > not. > > I'd much prefer that to do separately. OK, I see what you mean now. It's wrong indeed. The trouble is the ZONE_DMA series[1] in arm64, also due for v5.5, will be affected by this patch. I don't know the right way to approach this problem since depending on the merge order, this patch should be updated or the arm64 ZONE_DMA series fixed. Maybe it's easier to just wait for v5.6. Regards, Nicolas [1] https://lkml.org/lkml/2019/9/11/734
Attachment:
signature.asc
Description: This is a digitally signed message part
