public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <bjorn.helgaas@hp.com>
To: acpi-devel@lists.sourceforge.net
Cc: "Moore, Robert" <robert.moore@intel.com>,
	"Brown, Len" <len.brown@intel.com>,
	Alex Williamson <alex.williamson@hp.com>,
	"Luck, Tony" <tony.luck@intel.com>,
	linux-ia64@vger.kernel.org
Subject: Re: [ACPI] [PATCH] ACPI: implement UUID-labelled vendor-defined resources
Date: Mon, 19 Sep 2005 15:31:20 +0000	[thread overview]
Message-ID: <200509190931.20643.bjorn.helgaas@hp.com> (raw)
In-Reply-To: <971FCB6690CD0E4898387DBF7552B90E02C0B5F2@orsmsx403.amr.corp.intel.com>

On Friday 16 September 2005 3:56 pm, Moore, Robert wrote:
> And to make things even more interesting, the base ACPICA code looks
> nothing like the final Linux version of the code; it is converted on the
> fly before every release to Linux.

Well, if you decide you'll integrate the code, I can dig out the
pre-converted ACPICA code and make a patch against it.

> BTW, Please explain in more detail what support is needed in ACPICA for
> the ACPI 3.0 vendor-defined resource.  Also, any idea how we are
> supposed to determine if the UUID data exists within the descriptor?
> (i.e., how do we differentiate an ACPI 2.0 vendor descriptor from an
> ACPI 3.0 descriptor?)

There's no mark that distinguishes 2.0 and 3.0 vendor descriptors.
As far as I can tell, a 3.0 descriptor (that contains a UUID and
sub-type) is also a perfectly valid 2.0 descriptor.

ACPI 3.0 "strongs recommends," but apparently doesn't actually
require a UUID, so a 2.0 vendor descriptor should also be a valid
3.0 descriptor.

The idea is that we just look through all the vendor descriptors
for the supplied UUID.  If we find one, we return the information.
There's a small possibility that an ACPI 2.0, non-UUID-labelled
descriptor will contain data that happens to match the random
16-byte UUID, and we'll return it by mistake.  But that possibility
is pretty remote, I think.

The point of having this code in ACPICA is so that people who
use UUID-labelled vendor descriptors can do something simple
like this:

> struct acpi_vendor_descriptor hp_ccsr_descriptor = {
>         .uuid_subtype = 2,
>         .uuid = ACPI_UUID(0x69e9adf9, 0x924f, 0xab5f, 0xf6, 0x4a, 0x24, 0xd2,
>                           0x01, 0x37, 0x0e, 0xad)
> };
> 
> acpi_status hp_acpi_csr_space(acpi_handle obj, u64 * csr_base, u64 * csr_length)
> {
>...
>         status = acpi_find_vendor_resource(obj, &hp_ccsr_descriptor, &data,
>                 &length);

rather than having to duplicate the implementation of
acpi_find_vendor_resource().  But that's an obvious answer.
Maybe you had a deeper question that I missed?

This is pretty generic stuff, certainly not ia64-, or even OS-
dependent.  So I thought ACPICA would be a logical place for it.
If you have other suggestions, let me know.

  reply	other threads:[~2005-09-19 15:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-18 20:19 [PATCH] ACPI: implement UUID-labelled vendor-defined resources Bjorn Helgaas
2005-06-21 20:21 ` [ACPI] " Bjorn Helgaas
2005-09-16 21:56   ` Moore, Robert
2005-09-19 15:31     ` Bjorn Helgaas [this message]
     [not found]       ` <200509190931.20643.bjorn.helgaas-VXdhtT5mjnY@public.gmane.org>
2005-09-20 23:09         ` Bjorn Helgaas
     [not found]     ` <971FCB6690CD0E4898387DBF7552B90E02C0B5F2-sBd4vmA9Se5Qxe9IK+vIArfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2005-09-19 15:52       ` Christoph Hellwig
     [not found]         ` <20050919155203.GA24346-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2005-09-22 17:48           ` Pavel Machek
2005-09-20 23:16   ` Moore, Robert

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=200509190931.20643.bjorn.helgaas@hp.com \
    --to=bjorn.helgaas@hp.com \
    --cc=acpi-devel@lists.sourceforge.net \
    --cc=alex.williamson@hp.com \
    --cc=len.brown@intel.com \
    --cc=linux-ia64@vger.kernel.org \
    --cc=robert.moore@intel.com \
    --cc=tony.luck@intel.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox