Le 21/05/2020 à 12:38, Christophe Leroy a écrit :
Le 21/05/2020 à 09:02, Michael Ellerman a écrit :
Arnd Bergmann arnd@arndb.de writes:
+On Wed, Apr 8, 2020 at 2:04 PM Michael Ellerman mpe@ellerman.id.au wrote:
Benjamin Herrenschmidt benh@kernel.crashing.org writes:
On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote:
Benjamin Herrenschmidt benh@kernel.crashing.org writes:
IBM still put 40x cores inside POWER chips no ?
Oh yeah that's true. I guess most folks don't know that, or that they run RHEL on them.
Is there a reason for not having those dts files in mainline then? If nothing else, it would document what machines are still being used with future kernels.
Sorry that part was a joke :D Those chips don't run Linux.
Nice to know :)
What's the plan then, do we still want to keep 40x in the kernel ?
If yes, is it ok to drop the oldies anyway as done in my series https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=172630 ?
(Note that this series will conflict with my series on hugepages on 8xx due to the PTE_ATOMIC_UPDATES stuff. I can rebase the 40x modernisation series on top of the 8xx hugepages series if it is worth it)
Do we still want to keep 40x in the kernel ? We don't even have a running 40x QEMU machine as far as I know.
I'm asking because I'd like to drop the non CONFIG_VMAP_STACK code to simplify and ease stuff (code that works with vmalloc'ed stacks also works with stacks in linear memory), but I can't do it because 40x doesn't have VMAP_STACK and should I implement it for 40x, I have to means to test it.
So it would ease things if we could drop 40x completely, unless someone there has a 40x platform to test stuff.
Thanks Christophe