Christophe Leroy <christophe.leroy@xxxxxxxxxx> writes: > Hi Michael, hi Andrew > > Le 09/03/2022 à 18:44, Christophe Leroy a écrit : >> Rebased on top of powerpc/next branch >> >> This series converts powerpc to default topdown mmap layout. >> >> powerpc requires its own arch_get_unmapped_area() only when >> slices are needed, which is only for book3s/64. First part of >> the series moves slices into book3s/64 specific directories >> and cleans up other subarchitectures. >> >> Last part converts to default topdown mmap layout. >> >> A small modification is done to core mm to allow >> powerpc to still provide its own arch_randomize_brk() >> >> Another modification is done to core mm to allow powerpc >> to use generic versions of get_unmapped_area functions for Radix >> while still providing its own implementation for Hash, the >> selection between Radix and Hash being doing at runtime. >> >> Last modification to core mm is to give len and flags to >> arch_get_mmap_end(). >> >> Signed-off-by: Christophe Leroy <christophe.leroy@xxxxxxxxxx> > > What's the way forward for this series ? It's a bit of a tricky series. > Patches 1 has been merged in PCI tree. That's fine I guess, it can go into v5.18, it's only patch 14 that depends on it. > Patches 2 to 5 are core mm, patch 5 being a fix. A fix for arm64 even, just to complicate things :) > Then patches 6 to 14 are powerpc. With a fairly sizable diffstat, ie. likely to conflict. > What will be the merge strategy ? I guess it's a bit late to get it > through powerpc tree, so I was just wondering whether we could get > patches 2 to 5 in mm this cycle, and the powerpc ones next cycle ? Yeah I didn't pick it up because the mm changes don't have many acks and I'm always nervous about carrying generic mm changes. It would be my preference if Andrew could take 2-5 through mm for v5.18, but it is quite late, so I'm not sure how he will feel about that. Arguably 2, 3, 4 do very little. It's only patch 5 that has much effect, and it has a reviewed-by from Catalin at least. cheers