linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: John Garry <john.garry@huawei.com>
Cc: rjw@rjwysocki.net, lenb@kernel.org, jeremy.linton@arm.com,
	arnd@arndb.de, olof@lixom.net, linux-kernel@vger.kernel.org,
	linux-acpi@vger.kernel.org, guohanjun@huawei.com,
	gregkh@linuxfoundation.org,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	wanghuiqiang <wanghuiqiang@huawei.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: <60c79aaa-4c49-71b1-11be-8e41a6bf3c1d@huawei.com>

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@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.
>

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

  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 \
    --to=sudeep.holla@arm.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=guohanjun@huawei.com \
    --cc=jeremy.linton@arm.com \
    --cc=john.garry@huawei.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olof@lixom.net \
    --cc=rjw@rjwysocki.net \
    --cc=wanghuiqiang@huawei.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).