Saving to 32 bits of GPRs in signal context

[Kumar Gala]

On May 29, 2007, at 9:54 PM, Steve Munroe wrote:

>
> Kumar Gala <galak at kernel.crashing.org> wrote on 05/29/2007 07:43:05  
> PM:
>
>>
>> On May 29, 2007, at 6:46 PM, Olof Johansson wrote:
>>
>>> On Wed, May 30, 2007 at 07:32:33AM +1000, Benjamin Herrenschmidt
>>> wrote:
>>>> On Tue, 2007-05-29 at 08:10 -0500, Kumar Gala wrote:
>>>>> This is all problematic since some 64-bit implementations may not
>>>>> guarantee the upper bits are valid when in 32-bit mode.  Look  
>>>>> at the
>>>>> 'Computation Modes' section in the architecture specs 2.03 or
>>>>> greater
>>>>> for embedded processors.
>>>>
>>>> Yuck. Well, we might need to export a spearate CPU feature bit to
>>>> indicate that it's the case then.
>>>
>>> No need for a new bit, you should be able to key off of  
>>> PPC_FEATURE_64
>>> && !PPC_FEATURE_BOOKE.
>>
>> Nope, the architecture allows embedded to behave like server parts
>> and support the full 64-bit registers.  We really should have a new
>> feature bit so that if someone has an implementation of an embedded
>> part that supports the functionality, they get the benefit.
>>
> When such exists we can add a bit, until then we can wait. The current
> 32-bit AT_HWCAP is almost full. so we should not allocate bits on
> speculation.

Understandable.. dare I ask about a few of the current AT_HWCAPs we  
do have:

#define PPC_FEATURE_POWER4              0x00080000
#define PPC_FEATURE_POWER5              0x00040000
#define PPC_FEATURE_POWER5_PLUS         0x00020000
#define PPC_FEATURE_ARCH_2_05           0x00001000
#define PPC_FEATURE_PA6T                0x00000800
#define PPC_FEATURE_POWER6_EXT          0x00000200

What exactly are we using these for?  Can we not use platform for  
some of these?

- k