public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Greg KH <greg@kroah.com>
Cc: Zhang Rui <rui.zhang@intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	lenb@kernel.org, "linux-acpi@vger" <linux-acpi@vger.kernel.org>,
	Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [patch 2.6.21-rc5-git] make /proc/acpi/wakeup more useful
Date: Sat, 7 Apr 2007 13:08:07 -0700	[thread overview]
Message-ID: <200704071308.07571.david-b@pacbell.net> (raw)
In-Reply-To: <20070407050131.GB25511@kroah.com>

On Friday 06 April 2007 10:01 pm, Greg KH wrote:

> Are you _sure_ you have a 1-to-1 relationship here?  No multiple devices
> pointing to the same acpi node?  Or the other way around?  If so, you
> are going to have to change the name to be something more unique.

I've wondered that too.  The short answer:  APCI only supports 1-1
here.  It will emit warnings if it tries to bind more than one ACPI
device to a given "real" device ... but errors the other way are
silently ignored.

By adding a warning over this create-links patch, I found that the
system in the $SUBJECT patch (and likely every ACPI system) has
two different nodes that correspond to one ACPI node:

	/sys/devices/pci0000:00 ... pci root node
	/sys/devices/pnp0/00:00 ... id PNP0a03
	/sys/devices/acpi_system:00/device:00/PNP0A03:00 ... ditto

Arguably that's too many sysfs nodes for one device...

Plus, there's the issue of flakey ACPI tables; in the $SUBJECT patch
both MDM and AUD nodes exist in the ACPI namespace, but they could
only refer to one PCI device (with MDM as the wakeup source, not AUD
as listed in the table).  Or maybe that's another case where the ACPI
code isn't handling the tables as sensibly as it might...


> Or how about "firmware" instead of "acpi" to be able to have the
> userspace tools work on any type of firmware that provides this, like
> openfirmware?

Assuming they all adopt that same "parallel tree" model, that seems
like a good idea.  The tools will likely need to understand how ACPI
and OF differ, but there's no point in reserving more names than we
really need.  Though it may be that "parallel trees" should go away.

A small glitch in the patch:  lines bigger than 80 characters.  :)

- Dave

  reply	other threads:[~2007-04-07 20:08 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-04  0:41 [patch 2.6.21-rc5-git] make /proc/acpi/wakeup more useful David Brownell
2007-04-05  7:59 ` Zhang Rui
2007-04-05 10:58   ` David Brownell
2007-04-06  9:36     ` Zhang Rui
2007-04-06 15:43       ` David Brownell
2007-04-07  5:01         ` Greg KH
2007-04-07 20:08           ` David Brownell [this message]
2007-04-09  2:36             ` Zhang Rui
2007-04-09  5:35               ` David Brownell
2007-04-10 23:29             ` David Brownell
2007-04-11  0:10               ` David Brownell
2007-04-13 15:59             ` Pavel Machek
2007-04-17 19:53               ` David Brownell
2007-04-17 21:57                 ` David Brownell
2007-04-18  3:03                   ` Greg KH
2007-04-18  3:25                     ` David Brownell
2007-04-05  9:26 ` Matthew Garrett
2007-04-05 10:35   ` David Brownell
2007-04-25 19:22 ` Len Brown

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=200704071308.07571.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=akpm@linux-foundation.org \
    --cc=greg@kroah.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rui.zhang@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