Le 21/05/2020 à 12:38, Christophe Leroy a écrit :
Le 21/05/2020 à 09:02, Michael Ellerman a écrit :
Arnd Bergmann <arnd@xxxxxxxx> writes:
+On Wed, Apr 8, 2020 at 2:04 PM Michael Ellerman <mpe@xxxxxxxxxxxxxx> wrote:
Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> writes:
On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote:
Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> 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