Messages in this thread | | | Subject | Re: [PATCH RFC 1/2] ACPI/PPTT: Add acpi_pptt_get_package_info() API | From | John Garry <> | Date | Tue, 28 Jan 2020 14:04:19 +0000 |
| |
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@huawei.com/ >> > 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
| |