[Skiboot] [PATCH v2] core/init: Add ibm, processor-storage-keys property to /cpus DT node.

[Thiago Jung Bauermann]

Thiago Jung Bauermann <bauerman at linux.vnet.ibm.com> writes:

> Thiago Jung Bauermann <bauerman at linux.vnet.ibm.com> writes:
>
>> LoPAPR says:
>>
>>     “ibm,processor-storage-keys”
>>
>>     property name indicating the number of virtual storage keys supported
>>     by the processor described by this node.
>>
>>     prop-encoded-array: Consists of two cells encoded as with encode-int.
>>     The first cell represents the number of virtual storage keys supported
>>     for data accesses while the second cell represents the number of
>>     virtual storage keys supported for instruction accesses. The cell value
>>     of zero indicates that no storage keys are supported for the access
>>     type.
>>
>> pHyp provides the property above but there's a bug in P8 firmware where the
>> second cell is zero even though POWER8 supports instruction access keys.
>> This bug will be fixed for P9.
>>
>> While this is a PAPR property, it's useful to have it in powernv as well
>> so that Linux has a uniform way of checking for the feature regardless of
>> the platform it's running on.
>>
>> On PAPR there is one property for each CPU node, but since it's highly
>> unlikely that different CPUs will support a different number of keys, we
>> put the property in the /cpus node instead.
>>
>> Tested on QEMU POWER8 powernv model and Mambo P9.
>>
>> Signed-off-by: Thiago Jung Bauermann <bauerman at linux.vnet.ibm.com>
>> ---
>>  core/init.c | 18 ++++++++++++++++++
>>  1 file changed, 18 insertions(+)
>>
>> Changes in v2:
>> - Put property in /cpus instead of in each CPU node.
>
> Ping?

Ping? This patch still applies cleanly and works.

The Linux kernel patches using this property are upstream now (as of
v4.16-rc1) and we are still interested in having it on OpenPower
machines.

The only open issue is where to put the property. Currently, the Linux
code only looks for it in nodes with device_type = "cpu". This patch
puts it in /cpus to avoid repeating the property in each CPU node, but
Michael Ellerman suggested putting it in the ibm,opal node instead.

What do you think?

--
Thiago Jung Bauermann
IBM Linux Technology Center