From: Bjorn Helgaas <bjorn_helgaas@hp.com>
To: "Moore, Robert" <robert.moore@intel.com>,
"Grover, Andrew" <andrew.grover@intel.com>,
"Walz, Michael" <michael.walz@intel.com>
Cc: t-kochi@bq.jp.nec.com, linux-kernel@vger.kernel.org,
acpi-devel@lists.sourceforge.net
Subject: Re: [ACPI] [PATCH] 1/3 ACPI resource handling
Date: Fri, 21 Feb 2003 15:09:15 -0700 [thread overview]
Message-ID: <200302211509.15641.bjorn_helgaas@hp.com> (raw)
In-Reply-To: <B9ECACBD6885D5119ADC00508B68C1EA0D19BAFC@orsmsx107.jf.intel.com>
> 2) I'm not convinced that this buys a whole lot -- it just hides the code
> behind a macro (something that's not generally liked in the Linux world.)
> Would this procedure be called from more than one place?
Or, since you mention a macro, maybe your question is not about
the usefulness of acpi_resource_to_address64() itself, but about
how I implemented it, namely, with the copy_field and copy_address
macros:
+#define copy_field(out, in, field) out->field = in->field
+#define copy_address(out, in) \
+ copy_field(out, in, resource_type); \
+ copy_field(out, in, producer_consumer); \
...
If you'd rather see it implemented without the macros, I have no
objection to that. I just used the macros to reduce the chance of
making typographical errors along the way. Attached is the
equivalent patch (untested) without the macros. I also added a
note to the struct acpi_resource_addressXX definitions about the
need to make corresponding changes to acpi_resource_to_address64()
if the structures change.
Bjorn
diff -u -ur linux-2.5.59/drivers/acpi/resources/rsxface.c acpi-2/drivers/acpi/resources/rsxface.c
--- linux-2.5.59/drivers/acpi/resources/rsxface.c 2003-01-16 19:22:23.000000000 -0700
+++ acpi-2/drivers/acpi/resources/rsxface.c 2003-02-21 14:45:00.000000000 -0700
@@ -233,3 +233,83 @@
status = acpi_rs_set_srs_method_data (device_handle, in_buffer);
return_ACPI_STATUS (status);
}
+
+
+/*******************************************************************************
+ *
+ * FUNCTION: acpi_resource_to_address64
+ *
+ * PARAMETERS: resource - Pointer to a resource
+ * out - Pointer to the users's return
+ * buffer (a struct
+ * acpi_resource_address64)
+ *
+ * RETURN: Status
+ *
+ * DESCRIPTION: If the resource is an address16, address32, or address64,
+ * copy it to the address64 return buffer. This saves the
+ * caller from having to duplicate code for different-sized
+ * addresses.
+ *
+ ******************************************************************************/
+
+acpi_status
+acpi_resource_to_address64 (
+ struct acpi_resource *resource,
+ struct acpi_resource_address64 *out)
+{
+ struct acpi_resource_address16 *address16;
+ struct acpi_resource_address32 *address32;
+ struct acpi_resource_address64 *address64;
+
+ switch (resource->id) {
+ case ACPI_RSTYPE_ADDRESS16:
+ address16 = (struct acpi_resource_address16 *) &resource->data;
+ out->resource_type = address16->resource_type;
+ out->producer_consumer = address16->producer_consumer;
+ out->decode = address16->decode;
+ out->min_address_fixed = address16->min_address_fixed;
+ out->max_address_fixed = address16->max_address_fixed;
+ out->attribute = address16->attribute;
+ out->granularity = address16->granularity;
+ out->min_address_range = address16->min_address_range;
+ out->max_address_range = address16->max_address_range;
+ out->address_translation_offset = address16->address_translation_offset;
+ out->address_length = address16->address_length;
+ out->resource_source = address16->resource_source;
+ break;
+ case ACPI_RSTYPE_ADDRESS32:
+ address32 = (struct acpi_resource_address32 *) &resource->data;
+ out->resource_type = address32->resource_type;
+ out->producer_consumer = address32->producer_consumer;
+ out->decode = address32->decode;
+ out->min_address_fixed = address32->min_address_fixed;
+ out->max_address_fixed = address32->max_address_fixed;
+ out->attribute = address32->attribute;
+ out->granularity = address32->granularity;
+ out->min_address_range = address32->min_address_range;
+ out->max_address_range = address32->max_address_range;
+ out->address_translation_offset = address32->address_translation_offset;
+ out->address_length = address32->address_length;
+ out->resource_source = address32->resource_source;
+ break;
+ case ACPI_RSTYPE_ADDRESS64:
+ address64 = (struct acpi_resource_address64 *) &resource->data;
+ out->resource_type = address64->resource_type;
+ out->producer_consumer = address64->producer_consumer;
+ out->decode = address64->decode;
+ out->min_address_fixed = address64->min_address_fixed;
+ out->max_address_fixed = address64->max_address_fixed;
+ out->attribute = address64->attribute;
+ out->granularity = address64->granularity;
+ out->min_address_range = address64->min_address_range;
+ out->max_address_range = address64->max_address_range;
+ out->address_translation_offset = address64->address_translation_offset;
+ out->address_length = address64->address_length;
+ out->resource_source = address64->resource_source;
+ break;
+ default:
+ return (AE_BAD_PARAMETER);
+ }
+ return (AE_OK);
+}
diff -u -ur linux-2.5.59/include/acpi/acpixf.h acpi-2/include/acpi/acpixf.h
--- linux-2.5.59/include/acpi/acpixf.h 2003-02-21 14:39:23.000000000 -0700
+++ acpi-2/include/acpi/acpixf.h 2003-02-21 14:40:16.000000000 -0700
@@ -340,6 +340,11 @@
acpi_handle bus_device_handle,
struct acpi_buffer *ret_buffer);
+acpi_status
+acpi_resource_to_address64 (
+ struct acpi_resource *resource,
+ struct acpi_resource_address64 *out);
+
/*
* Hardware (ACPI device) interfaces
diff -u -ur linux-2.5.59/include/acpi/actypes.h acpi-2/include/acpi/actypes.h
--- linux-2.5.59/include/acpi/actypes.h 2003-02-21 14:39:23.000000000 -0700
+++ acpi-2/include/acpi/actypes.h 2003-02-21 14:48:35.000000000 -0700
@@ -1049,6 +1049,11 @@
char *string_ptr;
};
+/*
+ * Changes to the following address structures should
+ * also be reflected in acpi_resource_to_address64().
+ */
+
struct acpi_resource_address16
{
u32 resource_type;
next prev parent reply other threads:[~2003-02-21 21:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-21 18:25 Moore, Robert
2003-02-21 18:33 ` Bjorn Helgaas
2003-02-21 22:09 ` Bjorn Helgaas [this message]
2003-02-21 22:15 ` Matthew Wilcox
2003-02-21 22:36 ` Bjorn Helgaas
2003-02-23 22:54 ` Pavel Machek
2003-02-24 20:48 ` Folkert van Heusden
2003-02-21 23:07 Moore, Robert
2003-02-24 22:48 Moore, Robert
2003-02-25 16:57 ` Bjorn Helgaas
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=200302211509.15641.bjorn_helgaas@hp.com \
--to=bjorn_helgaas@hp.com \
--cc=acpi-devel@lists.sourceforge.net \
--cc=andrew.grover@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.walz@intel.com \
--cc=robert.moore@intel.com \
--cc=t-kochi@bq.jp.nec.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
all inboxes | Powered by JetHome®