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, Sudeep Holla <firstname.lastname@example.org> 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: <email@example.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
next prev parent 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 \ --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 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).