Segher Boessenkool <seg...@kernel.crashing.org> writes: > On Wed, Jul 26, 2017 at 08:03:30PM +1000, Michael Ellerman wrote: >> Segher Boessenkool <seg...@kernel.crashing.org> writes: >> > A general question about these patches: some things are inside #ifdef >> > __powerpc64__, some are not. It seems it is the wrong macro, and it >> > should be used (or not used) consistently? >> >> Why is it the wrong macro? Because we tend to use CONFIG_PPC64 you mean? > > Yeah. But I see sstep.c already mixes those two at will (or if there > is a distinction, I'm not seeing it :-) )
Yeah OK. In practice they're equivalent, if CONFIG_PPC64=y then the kernel is built 64-bit and therefore __powerpc64__ is defined. But I agree it's a mess, we should use CONFIG_PPC64 exclusively unless there's some reason not to (which I don't think there ever is). >> I thought the reason some are #ifdef'ed is that some are 64-bit only. >> ie. bpermd is 64-bit only ? > > 64-bit only, in what way? It's not clear what the rules are. Instructions that have "d" in the name? :P > It's not instructions that can only run in 64-bit mode. > It's not instructions that only give a usable result with 64-bit regs > implemented. > It's not instructions only implemented on 64-bit CPUs. I think it's trying to be that ^ If you build a 32-bit kernel then instructions that are only defined on 64-bit CPUs should be treated as illegal, so the easiest way to achieve that is to #ifdef off the code for those instructions. cheers
