From: John Garry <firstname.lastname@example.org> To: Sudeep Holla <email@example.com> Cc: <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>, Jonathan Cameron <Jonathan.Cameron@huawei.com>, 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:04:19 +0000 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <20200128123415.GB36168@bogus> 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 184.108.40.206) 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... 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://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. > > -- > Regards, > Sudeep > >  https://developer.arm.com/docs/den0028/c > . > Cheers, John
next prev parent reply other threads:[~2020-01-28 14:06 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 [this message] 2020-01-28 14:54 ` Sudeep Holla 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 \ --firstname.lastname@example.org \ --email@example.com \ --cc=Jonathan.Cameron@huawei.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 \ --firstname.lastname@example.org \ --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).