mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Toshi Kani <toshi.kani@hp.com>
Cc: ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Matthew Garrett <matthew.garrett@nebula.com>,
	Yinghai Lu <yinghai@kernel.org>, Jiang Liu <liuj97@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/4] ACPI / scan: Introduce struct acpi_scan_handler
Date: Tue, 29 Jan 2013 22:32:21 +0100	[thread overview]
Message-ID: <12270898.1ejuD0aCLg@vostro.rjw.lan> (raw)
In-Reply-To: <1359471043.15120.38.camel@misato.fc.hp.com>

On Tuesday, January 29, 2013 07:50:43 AM Toshi Kani wrote:
> On Tue, 2013-01-29 at 12:28 +0100, Rafael J. Wysocki wrote:
> > On Monday, January 28, 2013 07:35:39 PM Toshi Kani wrote:
> > > On Mon, 2013-01-28 at 13:59 +0100, Rafael J. Wysocki wrote:
> > > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > > 
> > > > Introduce struct acpi_scan_handler for representing objects that
> > > > will do configuration tasks depending on ACPI device nodes'
> > > > hardware IDs (HIDs).
> > > > 
> > > > Currently, those tasks are done either directly by the ACPI namespace
> > > > scanning code or by ACPI device drivers designed specifically for
> > > > this purpose.  None of the above is desirable, however, because
> > > > doing that directly in the namespace scanning code makes that code
> > > > overly complicated and difficult to follow and doing that in
> > > > "special" device drivers leads to a great deal of confusion about
> > > > their role and to confusing interactions with the driver core (for
> > > > example, sysfs directories are created for those drivers, but they
> > > > are completely unnecessary and only increase the kernel's memory
> > > > footprint in vain).
> > > > 
> > > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > > ---
> > > >  Documentation/acpi/scan_handlers.txt |   77 +++++++++++++++++++++++++++++++++++
> > > >  drivers/acpi/scan.c                  |   60 ++++++++++++++++++++++++---
> > > >  include/acpi/acpi_bus.h              |   14 ++++++
> > > >  3 files changed, 144 insertions(+), 7 deletions(-)
> > > > 
> > > > Index: test/include/acpi/acpi_bus.h
> > > > ===================================================================
> > > > --- test.orig/include/acpi/acpi_bus.h
> > > > +++ test/include/acpi/acpi_bus.h
> > > > @@ -84,6 +84,18 @@ struct acpi_driver;
> > > >  struct acpi_device;
> > > >  
> > > >  /*
> > > > + * ACPI Scan Handler
> > > > + * -----------------
> > > > + */
> > > > +
> > > > +struct acpi_scan_handler {
> > > > +	const struct acpi_device_id *ids;
> > > > +	struct list_head list_node;
> > > > +	int (*attach)(struct acpi_device *dev, const struct acpi_device_id *id);
> > > > +	void (*detach)(struct acpi_device *dev);
> > > > +};
> > > > +
> > > > +/*
> > > >   * ACPI Driver
> > > >   * -----------
> > > >   */
> > > > @@ -269,6 +281,7 @@ struct acpi_device {
> > > >  	struct acpi_device_wakeup wakeup;
> > > >  	struct acpi_device_perf performance;
> > > >  	struct acpi_device_dir dir;
> > > > +	struct acpi_scan_handler *handler;
> > > >  	struct acpi_driver *driver;
> > > >  	void *driver_data;
> > > >  	struct device dev;
> > > > @@ -382,6 +395,7 @@ int acpi_bus_receive_event(struct acpi_b
> > > >  static inline int acpi_bus_generate_proc_event(struct acpi_device *device, u8 type, int data)
> > > >  	{ return 0; }
> > > >  #endif
> > > > +int acpi_scan_add_handler(struct acpi_scan_handler *handler);
> > > >  int acpi_bus_register_driver(struct acpi_driver *driver);
> > > >  void acpi_bus_unregister_driver(struct acpi_driver *driver);
> > > >  int acpi_bus_scan(acpi_handle handle);
> > > > Index: test/drivers/acpi/scan.c
> > > > ===================================================================
> > > > --- test.orig/drivers/acpi/scan.c
> > > > +++ test/drivers/acpi/scan.c
> > > > @@ -53,6 +53,7 @@ static const struct acpi_device_id acpi_
> > > >  static LIST_HEAD(acpi_device_list);
> > > >  static LIST_HEAD(acpi_bus_id_list);
> > > >  static DEFINE_MUTEX(acpi_scan_lock);
> > > > +static LIST_HEAD(acpi_scan_handlers_list);
> > > >  DEFINE_MUTEX(acpi_device_lock);
> > > >  LIST_HEAD(acpi_wakeup_device_list);
> > > >  
> > > > @@ -62,6 +63,15 @@ struct acpi_device_bus_id{
> > > >  	struct list_head node;
> > > >  };
> > > >  
> > > > +int acpi_scan_add_handler(struct acpi_scan_handler *handler)
> > > > +{
> > > > +	if (!handler || !handler->attach)
> > > > +		return -EINVAL;
> > > > +
> > > > +	list_add_tail(&handler->list_node, &acpi_scan_handlers_list);
> > > > +	return 0;
> > > > +}
> > > > +
> > > >  /*
> > > >   * Creates hid/cid(s) string needed for modalias and uevent
> > > >   * e.g. on a device with hid:IBM0001 and cid:ACPI0001 you get:
> > > > @@ -1570,20 +1580,42 @@ static acpi_status acpi_bus_check_add(ac
> > > >  	return AE_OK;
> > > >  }
> > > >  
> > > > +static int acpi_scan_attach_handler(struct acpi_device *device)
> > > > +{
> > > > +	struct acpi_scan_handler *handler;
> > > > +	int ret = 0;
> > > > +
> > > > +	list_for_each_entry(handler, &acpi_scan_handlers_list, list_node) {
> > > > +		const struct acpi_device_id *id;
> > > > +
> > > > +		id = __acpi_match_device(device, handler->ids);
> > > > +		if (!id)
> > > > +			continue;
> > > > +
> > > > +		ret = handler->attach(device, id);
> > > > +		if (ret > 0) {
> > > > +			device->handler = handler;
> > > > +			break;
> > > > +		} else if (ret < 0) {
> > > > +			break;
> > > > +		}
> > > > +	}
> > > > +	return ret;
> > > > +}
> > > 
> > > Now that we have full control over the attach logic, it would be great
> > > if we can update it to match with the ACPI spec -- HID has priority over
> > > CIDs, and CIDs are also listed in their priority.  For example, Device-X
> > > has HID and CID.  In this case, this Device-X should be attached to
> > > Handler-A since it supports HID.  The current logic simply chooses a
> > > handler whichever registered before.  
> > > 
> > > Device-X: HID PNPID-A, CID PNPID-B
> > > Handler-A: PNPID-A
> > > Handler-B: PNPID-B
> > > 
> > > So, the attach logic should be something like:
> > > 
> > > list_for_each_entry(hwid, acpi_device->pnp.ids,) {
> > > 	list_for_each_entry(,&acpi_scan_handlers_list,)
> > > 		check if this handler supports a given hwid
> > > }
> > 
> > OK, I see the problem, but I think it's better to address it in a separate
> > patch on top of the current series.
> 
> I agree.
> 
> > I'm not sure what approach is best, though.  Do you think there should be two
> > passes the first of which will check HIDs only and the second one will check
> > CIDs?  Or do you have something different in mind?
> 
> HID and CIDs are already listed in their priority order in
> acpi_device->pnp.ids.  So, the single pass like I described above should
> work.

Well, I'm not sure if I understand you correctly.

The device is given and we need to find a handler for it.  So, it looks like
we first should check if any handler matches the HID.  This has to be a pass
through all handlers.  If there's no match, we need to check if any handler
matches any of the device IDs.  That will be the second pass, won't it?

The difficulty is that the first item in pnp.ids need not be *the* HID.
It only will be the HID if ACPI_VALID_HID is set in the device info in
acpi_device_set_id().  So perhaps we need to add a hid_valid bit in
device->flags and only do the "HID pass" if that is set?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

  reply	other threads:[~2013-01-29 21:26 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-24  0:26 [RFC] ACPI scan handlers Rafael J. Wysocki
2013-01-25 16:52 ` Toshi Kani
2013-01-25 22:11   ` Rafael J. Wysocki
2013-01-25 23:07     ` Toshi Kani
2013-01-26  1:49       ` Rafael J. Wysocki
2013-01-26 14:03         ` Rafael J. Wysocki
2013-01-26 18:42 ` Jiang Liu
2013-01-26 21:46   ` Rafael J. Wysocki
2013-01-28 12:58 ` [PATCH 0/4] " Rafael J. Wysocki
2013-01-28 12:59   ` [PATCH 1/4] ACPI / scan: Introduce struct acpi_scan_handler Rafael J. Wysocki
2013-01-29  2:04     ` Yasuaki Ishimatsu
2013-01-29  2:29       ` Yasuaki Ishimatsu
2013-01-29  2:35     ` Toshi Kani
2013-01-29 11:28       ` Rafael J. Wysocki
2013-01-29 14:50         ` Toshi Kani
2013-01-29 21:32           ` Rafael J. Wysocki [this message]
2013-01-29 22:57             ` Toshi Kani
2013-01-29 23:19               ` Rafael J. Wysocki
2013-01-29 23:27                 ` Toshi Kani
2013-01-30 13:18                   ` Rafael J. Wysocki
2013-02-03  0:52                     ` [PATCH] ACPI / scan: Follow priorities of IDs when matching scan handlers Rafael J. Wysocki
2013-02-03  4:54                       ` Yinghai Lu
2013-02-03 13:05                         ` Rafael J. Wysocki
2013-02-05 23:44                       ` Toshi Kani
2013-01-28 13:00   ` [PATCH 2/4] ACPI / PCI: Make PCI root driver use struct acpi_scan_handler Rafael J. Wysocki
2013-01-28 13:00   ` [PATCH 3/4] ACPI / PCI: Make PCI IRQ link " Rafael J. Wysocki
2013-01-28 13:01   ` [PATCH 4/4] ACPI / platform: Use struct acpi_scan_handler for creating devices Rafael J. Wysocki
2013-01-29  2:20     ` Yasuaki Ishimatsu
2013-01-29 11:36       ` Rafael J. Wysocki
2013-01-29 12:30         ` [Update][PATCH " Rafael J. Wysocki
2013-01-29 23:51           ` Yasuaki Ishimatsu
2013-01-29  7:35     ` [PATCH " Mika Westerberg
2013-01-29 12:01       ` Rafael J. Wysocki
2013-01-29  8:05     ` Mika Westerberg
2013-01-29 12:02       ` Rafael J. Wysocki
2013-01-28 21:54   ` [PATCH 0/4] ACPI scan handlers Yinghai Lu
2013-01-29  0:38     ` Rafael J. Wysocki
2013-01-29  2:33   ` Toshi Kani
2013-01-30  1:58   ` Toshi Kani
2013-01-30 13:36     ` Rafael J. Wysocki
2013-02-03 23:45   ` [PATCH 0/2] ACPI scan handler for memory hotplug and container simplification Rafael J. Wysocki
2013-02-03 23:46     ` [PATCH 1/2] ACPI / scan: Make memory hotplug driver use struct acpi_scan_handler Rafael J. Wysocki
2013-02-03 23:47     ` [PATCH 2/2] ACPI / scan: Simplify container driver Rafael J. Wysocki
2013-02-06 22:32       ` Toshi Kani
2013-02-07  0:55         ` Rafael J. Wysocki
2013-02-07  0:51           ` Toshi Kani
2013-02-07  1:32             ` Rafael J. Wysocki
2013-02-07 14:32               ` Toshi Kani
2013-02-07 22:42                 ` Rafael J. Wysocki
2013-02-08  1:05                   ` Toshi Kani
2013-02-08 12:52                     ` Rafael J. Wysocki
2013-02-08 16:24                       ` Toshi Kani
2013-02-07  8:32       ` Yasuaki Ishimatsu
2013-02-07 11:43         ` Rafael J. Wysocki
2013-02-07 14:38           ` Toshi Kani
2013-02-08  0:24       ` [PATCH 0/2] ACPI / scan: Remove useless #ifndef and simplify " Rafael J. Wysocki
2013-02-08  0:25         ` [PATCH 1/2] ACPI / scan: Remove useless #ifndef from acpi_eject_store() Rafael J. Wysocki
2013-02-08  0:27         ` [PATCH 2/2] ACPI / scan: Make container driver use struct acpi_scan_handler Rafael J. Wysocki
2013-02-08  3:32           ` Yinghai Lu
2013-02-08 12:45             ` Rafael J. Wysocki
2013-02-08  3:19         ` [PATCH 0/2] ACPI / scan: Remove useless #ifndef and simplify container driver Yasuaki Ishimatsu
2013-02-08 12:46           ` Rafael J. Wysocki
2013-02-08 16:57         ` Toshi Kani
2013-02-08 19:59           ` Rafael J. Wysocki
2013-02-08 22:41             ` Rafael J. Wysocki
2013-02-08 23:18               ` [PATCH] ACPI: Drop the container.h header file Rafael J. Wysocki
2013-02-08 23:27                 ` Toshi Kani
2013-02-09 14:26         ` [PATCH 0/2] ACPI / scan: Two fixes for device hot-removal Rafael J. Wysocki
2013-02-09 14:29           ` [PATCH 1/2] ACPI / scan: Make acpi_bus_hot_remove_device() acquire the scan lock Rafael J. Wysocki
2013-02-11 23:42             ` Toshi Kani
2013-02-09 14:31           ` [PATCH 2/2] ACPI / scan: Full transition to D3cold in acpi_device_unregister() 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=12270898.1ejuD0aCLg@vostro.rjw.lan \
    --to=rjw@sisk.pl \
    --cc=bhelgaas@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liuj97@gmail.com \
    --cc=matthew.garrett@nebula.com \
    --cc=mika.westerberg@linux.intel.com \
    --cc=toshi.kani@hp.com \
    --cc=yinghai@kernel.org \
    /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®