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, Sudeep Holla <sudeep.holla@arm.com>
Subject: Re: [PATCH RFC 2/2] soc: Add a basic ACPI generic driver
Date: Tue, 28 Jan 2020 16:17:51 +0000	[thread overview]
Message-ID: <20200128161751.GA30489@bogus> (raw)
In-Reply-To: <ff2ebe43-639d-085b-d043-55c402513390@huawei.com>

On Tue, Jan 28, 2020 at 03:59:15PM +0000, John Garry wrote:
> On 28/01/2020 15:20, Sudeep Holla wrote:
>

[...]

> Hi Sudeep,
>
> > What do you want to match this ? The same silicon can end up with
> > different OEMs and this list just blows up soon for single SoC if
> > used by different OEM/ODMs. I assume we get all the required info
> > from the Type 2 table entry and hence can just rely on that. If
> > PPTT has type 2 entry, just initialise this soc driver and expose
> > the relevant information from the table entry.
>
> As before, the LEVEL_1_ID and LEVEL_2_ID table members are too open to
> interpretation in the spec to generate a consistent form soc_id and
> family_id for all platforms.
>

One of the argument I was making during evolution of SOC_ID is to have
IDs like LEVEL_1_ID and LEVEL_2_ID in PPTT as they are 8 bytes long and
can just be a string that is self-sufficient and can be exposed to user
space as is instead of having to do some interpretation in the kernel.
Remember this is ACPI table entry and is designed to work with multiple
OS, we can at-least expect the strings to be as self-explanatory and
need no further decoding in the kernel.

> As such, I was trying to limit to known PPTT implementations and how they
> should be interpreted. Obviously that's *far* from ideal.
>

I am saying not to take that path and just throw the strings as is at
the user. If OEM/ODMs are serious about suggesting user-space to make
use of it, they better put sane value there and don't expect kernel to
do interpretation for them.

> So what's your idea? Just always put LEVEL_1_ID and LEVEL_2_ID in soc driver
> family_id and soc_id fields, respectively?
>

Yes, that's my opinion. It gets messy soon if kernel tries to interpret
this for OEM/ODM, they must better get it right if they are serious about
it.

--
Regards,
Sudeep

  reply	other threads:[~2020-01-28 16:17 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
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 [this message]
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=20200128161751.GA30489@bogus \
    --to=sudeep.holla@arm.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 \
    --subject='Re: [PATCH RFC 2/2] soc: Add a basic ACPI generic driver' \
    /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).