On Tue, Jan 28, 2020 at 02:04:19PM +0000, John Garry wrote: > 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... > I can understand, it is not well published/advertised. > 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 > Yes, that was one of the things we looked at when we started with SOC_ID SMCCC API and proposal to deprecate PPTT Type 2 table. > > 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. > Sure, that will at-least give you what SMCCC SOC_ID API looks like. > > > > 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. > Yes I agree on the generic solution and the soc driver you have proposed in the patch. No objections there, just the source of the information needs to be changed. Instead of ACPI PPTT Type 2 table, it needs to be SOC_ID SMCCC v1.2 API > > > > > > [...] > > > > > > > > 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. > As mentioned above, yes the driver would remain almost same for SMCCC SOC_ID support too. The main point was: do we need to add support to PPTT Type 2 entry when we know there is proposal to deprecate it. I would at-least wait to see progress on that until I would add this to the kernel. -- Regards, Sudeep
