mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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.

  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®