From: Sudeep Holla <email@example.com> To: John Garry <firstname.lastname@example.org> Cc: email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, Jonathan Cameron <Jonathan.Cameron@huawei.com>, Sudeep Holla <firstname.lastname@example.org>, wanghuiqiang <email@example.com> Subject: Re: [PATCH RFC 1/2] ACPI/PPTT: Add acpi_pptt_get_package_info() API Date: Tue, 28 Jan 2020 14:54:40 +0000 [thread overview] Message-ID: <20200128145430.GA47557@bogus> (raw) In-Reply-To: <firstname.lastname@example.org> 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 188.8.131.52) 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. 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://email@example.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. > 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
next prev parent reply other threads:[~2020-01-28 14:54 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-01-28 11:14 [PATCH RFC 0/2] Add basic generic ACPI soc driver John Garry 2020-01-28 11:14 ` [PATCH RFC 1/2] ACPI/PPTT: Add acpi_pptt_get_package_info() API John Garry 2020-01-28 12:34 ` Sudeep Holla 2020-01-28 14:04 ` John Garry 2020-01-28 14:54 ` Sudeep Holla [this message] 2020-01-29 11:03 ` John Garry 2020-01-30 11:23 ` Sudeep Holla 2020-01-30 16:12 ` John Garry 2020-01-30 17:41 ` Sudeep Holla 2020-01-31 10:58 ` John Garry 2020-01-28 11:14 ` [PATCH RFC 2/2] soc: Add a basic ACPI generic driver John Garry 2020-01-28 11:56 ` Greg KH 2020-01-28 13:33 ` John Garry 2020-01-28 12:50 ` Arnd Bergmann 2020-01-28 14:46 ` John Garry 2020-01-28 15:20 ` Sudeep Holla 2020-01-28 15:59 ` John Garry 2020-01-28 16:17 ` Sudeep Holla 2020-01-28 17:51 ` Olof Johansson 2020-01-28 18:22 ` John Garry 2020-01-28 19:11 ` Rafael J. Wysocki 2020-01-28 19:28 ` John Garry 2020-01-28 22:30 ` Rafael J. Wysocki 2020-01-29 10:27 ` John Garry 2020-01-28 20:06 ` Olof Johansson 2020-01-29 9:58 ` John Garry 2020-01-28 16:56 ` [PATCH RFC 0/2] Add basic generic ACPI soc driver Jeremy Linton 2020-01-28 17:28 ` John Garry 2020-01-28 19:04 ` Jeremy Linton 2020-01-28 20:07 ` John Garry
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200128145430.GA47557@bogus \ --firstname.lastname@example.org \ --cc=Jonathan.Cameron@huawei.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH RFC 1/2] ACPI/PPTT: Add acpi_pptt_get_package_info() API' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).