On Thu, Jul 27, 2017 at 11:26 AM, Michael Ellerman <m...@ellerman.id.au> wrote: > 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. >
I'll fixup this up to use the xor implementation, and change the series to use CONFIG_PPC64 for the ifdef. Thanks, Matt > cheers
