On 28/01/2020 12:34, Sudeep Holla wrote:
Hi Sudeep,
On Tue, Jan 28, 2020 at 07:14:18PM +0800, John Garry wrote:
The ACPI PPTT ID structure (see 6.2 spec, section 5.2.29.3) allows the
vendor to provide an identifier (or vendor specific part number) for a
particular processor hierarchy node structure. That may be a processor
identifier for a processor node, or some chip identifier for a processor
package node.
Unfortunately, there were plans to deprecate this in favour of the new
SOC_ID SMCCC API[1]. I am not sure if you or anyone in your company have
access to UEFI ASWG mantis where you can look for the ECR for the PPTT
Type 2 deprecation.
I wasn't aware and I can't get access...
Personally I would rather PPTT ID structure have a fixed field
definition in future spec versions, rather than deprecate.
From checking here, nobody has even used it (properly) for processor
package nodes:
https://github.com/tianocore/edk2-platforms/tree/master/Platform
I understand it's not ideal, but we need to converge,
please take a look at both before further discussion.
I can only check the SMCCC extension which you pointed me at.
I personally would not prefer to add the support when I know it is getting
deprecated. I am not sure on kernel community policy on the same.
So I need a generic solution for this, as my userspace tool requires a
generic solution.
[...]
The ID structure table has a number of fields, which are left open to
interpretation per implementation. However the spec does provide reference
examples of how the fields could be used. As such, just provide the
table fields directly in the API, which the caller may interpret (probably
as per spec example).
The "open for interpretation" part is why it's not being favoured anymore
by silicon vendors as OEM/ODMs can override the same.
https://lore.kernel.org/linux-arm-kernel/1579876505-113251-6-git-send-email-john.garry@xxxxxxxxxx/
Ah, there's already quite a lot of dependency built for this feature :(
Not really. It's only an RFC ATM, and my requirement is a sysfs file to
read the SoC id(s) (under ACPI FW). So I would still expect to be able
to support this from the SMCCC extension method.
--
Regards,
Sudeep
[1] https://developer.arm.com/docs/den0028/c
.
Cheers,
John
