From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: mathias.nyman@linux.intel.com, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org, lenb@kernel.org,
rafael.j.wysocki@intel.com, broonie@opensource.wolfsonmicro.com,
grant.likely@secretlab.ca, linus.walleij@linaro.org,
khali@linux-fr.org, Bjorn Helgaas <bhelgaas@google.com>,
"Moore, Robert" <robert.moore@intel.com>
Subject: Re: [Replacement][PATCH 3/3]
Date: Tue, 13 Nov 2012 16:15:51 +0100 [thread overview]
Message-ID: <1956273.aTIDahOxd1@vostro.rjw.lan> (raw)
In-Reply-To: <20121113141642.GJ31759@intel.com>
On Tuesday, November 13, 2012 04:16:42 PM Mika Westerberg wrote:
> On Tue, Nov 13, 2012 at 01:06:59PM +0100, Rafael J. Wysocki wrote:
> > > I don't know any better option.
> >
> > Well, a better option would be to convince ACPICA to provide us different
> > interfaces. :-)
>
> Heh, indeed.
>
> > We might actually try to do that in the future, but for now we still need
> > _CRS to be evaluated centrally rather than by every interested party in
> > isolation. So below is a replacement for my original [3/3] patch that
> > approaches the problem from a different angle (on top of [1/3] and
> > updated [2/3] sent yesterday). Please let me know what you think.
> >
> > Thanks,
> > Rafael
> >
> >
> > ---
> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > Subject: ACPI: Centralized processing of ACPI device resources
> >
> > Currently, whoever wants to use ACPI device resources has to call
> > acpi_walk_resources() to browse the buffer returned by the _CRS
> > method for the given device and create filters passed to that
> > routine to apply to the individual resource items. This generally
> > is cumbersome, time-consuming and inefficient. Moreover, it may
> > be problematic if resource conflicts need to be resolved, because
> > the different users of _CRS will need to do that in a consistent
> > way. However, if there are resource conflicts, the ACPI core
> > should be able to resolve them centrally instead of relying on
> > various users of acpi_walk_resources() to handle them correctly
> > together.
> >
> > For this reason, introduce a new function, acpi_dev_get_resources(),
> > that can be used by subsystems to obtain a list of struct resource
> > objects corresponding to the ACPI device resources returned by
> > _CRS and, if necessary, to apply additional preprocessing routine
> > to the ACPI resources before converting them to the struct resource
> > format.
> >
> > Make the ACPI code that creates platform device objects use
> > acpi_dev_get_resources() for resource processing instead of executing
> > acpi_walk_resources() twice by itself, which causes it to be much
> > more straightforward and easier to follow.
> >
> > In the future, acpi_dev_get_resources() can be extended to meet
> > the needs of the ACPI PNP subsystem and other users of _CRS in
> > the kernel.
> >
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> I found one problem which resulted failure (see below) but once that was
> fixed devices were enumerated correctly. I tested this also with modified
> SPI/I2C/GPIO patches and they also work as expected on my test machine.
>
> Nice work, thanks.
Well, thanks! :-)
> > ---
> > drivers/acpi/acpi_platform.c | 94 +++++-------------------------
> > drivers/acpi/resource.c | 132 +++++++++++++++++++++++++++++++++++++++++++
> > include/linux/acpi.h | 10 +++
> > 3 files changed, 159 insertions(+), 77 deletions(-)
> >
> > Index: linux/include/linux/acpi.h
> > ===================================================================
> > --- linux.orig/include/linux/acpi.h
> > +++ linux/include/linux/acpi.h
> > @@ -261,6 +261,16 @@ unsigned long acpi_dev_irq_flags(u8 trig
> > bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
> > struct resource *res);
> >
> > +struct resource_list_entry {
> > + struct list_head node;
> > + struct resource res;
> > +};
> > +
> > +void acpi_dev_free_resource_list(struct list_head *list);
> > +int acpi_dev_get_resources(struct acpi_device *adev, struct list_head *list,
> > + int (*preproc)(struct acpi_resource *, void *),
> > + void *preproc_data);
> > +
> > int acpi_check_resource_conflict(const struct resource *res);
> >
> > int acpi_check_region(resource_size_t start, resource_size_t n,
> > Index: linux/drivers/acpi/resource.c
> > ===================================================================
> > --- linux.orig/drivers/acpi/resource.c
> > +++ linux/drivers/acpi/resource.c
> > @@ -26,6 +26,7 @@
> > #include <linux/device.h>
> > #include <linux/export.h>
> > #include <linux/ioport.h>
> > +#include <linux/slab.h>
> >
> > #ifdef CONFIG_X86
> > #define valid_IRQ(i) (((i) != 0) && ((i) != 2))
> > @@ -391,3 +392,134 @@ bool acpi_dev_resource_interrupt(struct
> > return true;
> > }
> > EXPORT_SYMBOL_GPL(acpi_dev_resource_interrupt);
> > +
> > +/**
> > + * acpi_dev_free_resource_list - Free resource from %acpi_dev_get_resources().
> > + * @list: The head of the resource list to free.
> > + */
> > +void acpi_dev_free_resource_list(struct list_head *list)
> > +{
> > + struct resource_list_entry *rentry, *re;
> > +
> > + list_for_each_entry_safe(rentry, re, list, node) {
> > + list_del(&rentry->node);
> > + kfree(rentry);
> > + }
> > +}
> > +EXPORT_SYMBOL_GPL(acpi_dev_free_resource_list);
> > +
> > +struct res_proc_context {
> > + struct list_head *list;
> > + int (*preproc)(struct acpi_resource *, void *);
> > + void *preproc_data;
> > + int count;
> > + int error;
> > +};
> > +
> > +static acpi_status acpi_dev_new_resource_entry(struct resource *r,
> > + struct res_proc_context *c)
> > +{
> > + struct resource_list_entry *rentry;
> > +
> > + rentry = kmalloc(sizeof(*rentry), GFP_KERNEL);
> > + if (!rentry) {
> > + c->error = -ENOMEM;
> > + return AE_NO_MEMORY;
> > + }
> > + INIT_LIST_HEAD(&rentry->node);
> > + rentry->res = *r;
> > + list_add_tail(&rentry->node, c->list);
> > + c->count++;
> > + return AE_OK;
> > +}
> > +
> > +static acpi_status acpi_dev_process_resource(struct acpi_resource *ares,
> > + void *context)
> > +{
> > + struct res_proc_context *c = context;
> > + struct resource r;
>
> We should initialize this to zero, otherwise insert_resource() will fail as
> parent, sibling etc. pointers are garbage.
Ah, sorry for overlooking that.
I'll resend the whole [1-3/3] series later today with this bug fixed (hopefully).
> > + int i;
> > +
> > + if (c->preproc) {
> > + int ret;
> > +
> > + ret = c->preproc(ares, c->preproc_data);
> > + if (ret < 0) {
> > + c->error = ret;
> > + return AE_ABORT_METHOD;
> > + } else if (ret > 0) {
> > + return AE_OK;
> > + }
> > + }
> > +
> > + if (acpi_dev_resource_memory(ares, &r)
> > + || acpi_dev_resource_io(ares, &r)
> > + || acpi_dev_resource_address_space(ares, &r)
> > + || acpi_dev_resource_ext_address_space(ares, &r))
> > + return acpi_dev_new_resource_entry(&r, c);
> > +
> > + for (i = 0; acpi_dev_resource_interrupt(ares, i, &r); i++) {
> > + acpi_status status;
> > +
> > + status = acpi_dev_new_resource_entry(&r, c);
> > + if (ACPI_FAILURE(status))
> > + return status;
> > + }
> > +
> > + return AE_OK;
> > +}
> > +
> > +/**
> > + * acpi_dev_get_resources - Get current resources of a device.
> > + * @adev: ACPI device node to get the resources for.
> > + * @list: Head of the resultant list of resources (must be empty).
> > + * @preproc: The caller's preprocessing routine.
> > + * @preproc_data: Pointer passed to the caller's preprocessing routine.
> > + *
> > + * Evaluate the _CRS method for the given device node and process its output by
> > + * (1) executing the @preproc() rountine provided by the caller, passing the
> > + * resource pointer and @preproc_data to it as arguments, for each ACPI resource
> > + * returned and (2) converting all of the returned ACPI resources into struct
> > + * resource objects if possible. If the return value of @preproc() in step (1)
> > + * is different from 0, step (2) is not applied to the given ACPI resource and
> > + * if that value is negative, the whole processing is aborted and that value is
> > + * returned as the final error code.
> > + *
> > + * The resultant struct resource objects are put on the list pointed to by
> > + * @list, that must be empty initially, as members of struct resource_list_entry
> > + * objects. Callers of this routine should use %acpi_dev_free_resource_list() to
> > + * free that list.
> > + *
> > + * The number of resources in the output list is returned on success, an error
> > + * code reflecting the error condition is returned otherwise.
> > + */
> > +int acpi_dev_get_resources(struct acpi_device *adev, struct list_head *list,
> > + int (*preproc)(struct acpi_resource *, void *),
> > + void *preproc_data)
>
> Could we change this so that you can pass NULL list as well (provided that
> the preproc is given)?
>
> This is useful in case when we try to find the SPI/I2C device handle based
> on the ACPI serial bus resource address. In that case we are not interested
> in any other resources (and hence there is no need to allocate memory for
> them etc.)
I'd prefer to have a separate helper function for that, if that's not a
problem. It should be clear when we ask for resources of a given device
and when we only want to poke things like that.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
next prev parent reply other threads:[~2012-11-13 15:11 UTC|newest]
Thread overview: 119+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-03 7:46 [PATCH 0/3] ACPI 5 support for GPIO, SPI and I2C Mika Westerberg
2012-11-03 7:46 ` [PATCH 1/3] gpio / ACPI: add ACPI support Mika Westerberg
2012-11-05 11:53 ` Linus Walleij
2012-11-05 12:14 ` Mathias Nyman
2012-11-05 12:46 ` Rafael J. Wysocki
2012-11-05 13:11 ` Linus Walleij
2012-11-05 13:19 ` Rafael J. Wysocki
2012-11-05 13:28 ` Linus Walleij
2012-11-05 13:50 ` Rafael J. Wysocki
2012-11-05 14:40 ` Linus Walleij
2012-11-06 9:39 ` Mika Westerberg
2012-11-06 10:15 ` Linus Walleij
2012-11-07 8:54 ` Mika Westerberg
2012-11-08 15:55 ` Grant Likely
2012-11-08 19:38 ` Mika Westerberg
2012-11-09 14:11 ` Mathias Nyman
2012-11-09 14:18 ` Grant Likely
2012-11-09 15:05 ` Mathias Nyman
2012-11-09 15:46 ` Grant Likely
2012-11-11 9:50 ` Mika Westerberg
2012-11-03 7:46 ` [PATCH 2/3] spi / ACPI: add ACPI enumeration support Mika Westerberg
2012-11-03 19:42 ` Bjorn Helgaas
2012-11-03 20:13 ` Mika Westerberg
2012-11-03 20:59 ` Rafael J. Wysocki
2012-11-05 10:31 ` Rafael J. Wysocki
2012-11-05 10:56 ` Mika Westerberg
2012-11-05 10:56 ` Mark Brown
2012-11-05 12:02 ` Mika Westerberg
2012-11-05 12:23 ` Jean Delvare
2012-11-05 12:59 ` Rafael J. Wysocki
2012-11-05 13:15 ` Mika Westerberg
2012-11-05 13:20 ` Linus Walleij
2012-11-05 13:43 ` Mika Westerberg
2012-11-05 14:03 ` Jean Delvare
2012-11-05 14:19 ` Rafael J. Wysocki
2012-11-05 14:53 ` Mika Westerberg
2012-11-05 15:19 ` Jean Delvare
2012-11-05 17:12 ` Mika Westerberg
2012-11-05 17:43 ` Bjorn Helgaas
2012-11-05 18:08 ` Mika Westerberg
2012-11-05 17:49 ` Jean Delvare
2012-11-05 20:42 ` Linus Walleij
2012-11-06 8:11 ` Mark Brown
2012-11-05 16:54 ` Bjorn Helgaas
2012-11-06 13:43 ` Rafael J. Wysocki
2012-11-06 20:35 ` Bjorn Helgaas
2012-11-06 22:28 ` Rafael J. Wysocki
2012-11-06 22:36 ` Rafael J. Wysocki
2012-11-07 9:58 ` Mika Westerberg
2012-11-07 11:14 ` Rafael J. Wysocki
2012-11-07 13:05 ` Mika Westerberg
2012-11-08 0:46 ` Rafael J. Wysocki
2012-11-08 20:20 ` Mika Westerberg
2012-11-08 20:54 ` Rafael J. Wysocki
2012-11-08 18:05 ` Grant Likely
2012-11-08 21:06 ` Rafael J. Wysocki
2012-11-08 21:34 ` Grant Likely
2012-11-05 10:54 ` Mark Brown
2012-11-03 20:39 ` Rafael J. Wysocki
2012-11-05 16:54 ` Bjorn Helgaas
2012-11-06 13:16 ` Rafael J. Wysocki
2012-11-06 20:53 ` Bjorn Helgaas
2012-11-06 22:18 ` Rafael J. Wysocki
2012-11-07 9:56 ` Mika Westerberg
2012-11-08 19:32 ` Bjorn Helgaas
2012-11-08 20:04 ` Mika Westerberg
2012-11-09 15:11 ` Bjorn Helgaas
2012-11-09 15:45 ` Grant Likely
2012-11-09 16:35 ` Bjorn Helgaas
2012-11-09 16:43 ` Grant Likely
2012-11-09 16:48 ` Mark Brown
2012-11-09 16:53 ` Bjorn Helgaas
2012-11-10 11:10 ` Rafael J. Wysocki
2012-11-10 11:16 ` Grant Likely
2012-11-10 17:14 ` Bjorn Helgaas
2012-11-10 19:40 ` Rafael J. Wysocki
2012-11-05 10:54 ` Mark Brown
2012-11-05 11:03 ` Mika Westerberg
2012-11-05 11:13 ` Mark Brown
2012-11-08 18:48 ` Grant Likely
2012-11-09 3:50 ` Mika Westerberg
2012-11-03 7:46 ` [PATCH 3/3] i2c " Mika Westerberg
2012-11-03 21:52 ` Jean Delvare
2012-11-04 7:23 ` Mika Westerberg
2012-11-04 8:50 ` Jean Delvare
2012-11-04 10:50 ` Mika Westerberg
2012-11-08 18:58 ` Grant Likely
2012-11-09 3:51 ` Mika Westerberg
2012-11-04 18:29 ` [PATCH 0/3] ACPI 5 support for GPIO, SPI and I2C Linus Walleij
2012-11-05 9:23 ` Mika Westerberg
2012-11-12 11:51 ` [PATCH 0/3] Centralized parsing of ACPI device resources (was: Re: [PATCH 0/3] ACPI 5 support for GPIO, SPI and I2C) Rafael J. Wysocki
2012-11-12 12:00 ` [PATCH 1/3] ACPI: Move device resources interpretation code from PNP to ACPI core Rafael J. Wysocki
2012-11-12 13:27 ` Mika Westerberg
2012-11-12 20:25 ` [Update][PATCH " Rafael J. Wysocki
2012-11-12 12:01 ` [PATCH 2/3] ACPI / platform: Use common ACPI device resource parsing routines Rafael J. Wysocki
2012-11-12 12:02 ` [PATCH 3/3] ACPI: Evaluate _CRS while creating device node objects Rafael J. Wysocki
2012-11-12 14:46 ` Mika Westerberg
2012-11-12 21:03 ` Rafael J. Wysocki
2012-11-13 7:12 ` Mika Westerberg
2012-11-13 12:06 ` [Replacement][PATCH 3/3] Rafael J. Wysocki
2012-11-13 14:16 ` Mika Westerberg
2012-11-13 15:15 ` Rafael J. Wysocki [this message]
2012-11-13 15:18 ` Mika Westerberg
2012-11-13 15:28 ` Rafael J. Wysocki
2012-11-13 15:37 ` Mika Westerberg
2012-11-13 16:34 ` [PATCH 3/3] ACPI: Evaluate _CRS while creating device node objects Moore, Robert
2012-11-13 20:44 ` Rafael J. Wysocki
2012-11-13 22:06 ` Moore, Robert
2012-11-13 22:56 ` Rafael J. Wysocki
2012-11-14 2:23 ` Moore, Robert
2012-11-14 9:18 ` Rafael J. Wysocki
2012-11-14 9:32 ` Rafael J. Wysocki
2012-11-14 14:20 ` Moore, Robert
2012-11-13 20:51 ` [PATCH 0/3 rev 2] Centralized parsing of ACPI device resources Rafael J. Wysocki
2012-11-13 20:55 ` [PATCH 1/3 rev 2] ACPI: Move device resources interpretation code from PNP to ACPI core Rafael J. Wysocki
2012-11-13 20:55 ` [PATCH 2/3 rev 2] ACPI / platform: Use common ACPI device resource parsing routines Rafael J. Wysocki
2012-11-13 20:56 ` [PATCH 3/3 rev 2] ACPI: Centralized processing of ACPI device resources Rafael J. Wysocki
2012-11-14 9:52 ` [PATCH 0/3 rev 2] Centralized parsing " Mika Westerberg
2012-11-14 10:08 ` Rafael J. Wysocki
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=1956273.aTIDahOxd1@vostro.rjw.lan \
--to=rjw@sisk.pl \
--cc=bhelgaas@google.com \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=grant.likely@secretlab.ca \
--cc=khali@linux-fr.org \
--cc=lenb@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathias.nyman@linux.intel.com \
--cc=mika.westerberg@linux.intel.com \
--cc=rafael.j.wysocki@intel.com \
--cc=robert.moore@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
all inboxes | Powered by JetHome®