All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Zhang Rui <rui.zhang@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Greg KH <greg@kroah.com>,
	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: Fri, 6 Apr 2007 08:43:30 -0700	[thread overview]
Message-ID: <200704060843.30723.david-b@pacbell.net> (raw)
In-Reply-To: <1175852213.2650.4.camel@localhost.localdomain>

On Friday 06 April 2007 2:36 am, Zhang Rui wrote:
> On Thu, 2007-04-05 at 03:58 -0700, David Brownell wrote: 
> > 
> > For wakeup devices, the main issue I've seen is with button devices.
> > In my limited set of test sytems, everything else is either PCI, PNP,
> > or a bug (listing a non-existent device).
>
> There may be other wakeup-enabled devices like legacy serial,
> PS2 devices described in ACPI name space.

Do you mean they wouldn't be listed in /proc/acpi/wakeup though?

Or just that they wouldn't be listed as PNP devices (like the button
devices)?  That seems buglike.  Not that BIOS bugs are so rare; and
I sure wouldn't know which types are common...

Because that example file certainly included UART and PS2 devices,
which were listed both as PNP devices and as ACPI devices.


> > If this patch starts to get deployed, I expect other people will find
> > a few other curiousities ... and likely some things to be fixed.
> 
> > The /sys/devices/acpi_system:00/ tree is kind of new.  I suspect one
> > way it could be more informative is to set up cross-links in sysfs
> > between the ACPI devices and the "real" device nodes ... e.g. on the
> > system I'm using right now .../device:00/PNP0A03:00/device:15/PNP0B00:00
> > could have a link pointing to /sys/devices/pnp0/00:06 ... and that PNP
> > node in turn could have an "acpi" link pointing back to the ACPI thing.
> > 
> > Such cross-links would let people see those relationships, and observe
> > which links are missing or otherwise strange.  Fixing the bugs would
> > seem unlikely until those things become visible.
>
> Sounds nice.
> The patch below should make sense.

Yeah, that's the idea.  Let's see if it's any good.  :)

I'd just call it "acpi_node" not "ACPI_node" (NO POINT IN SHOUTING),
and might not even use the "_node" suffix.

I cc'd Greg, who's our resident (or is that itinerant?) sysfs guru,
in case he has comments on this issue.

This applied over the "ACPI driver model flags and platform_enable_wake()"
patch with a bit of fuzz, on RC6.

- Dave


> Add cross-links between ACPI device and "real" devices in sysfs.
> 
> Signed-off-by: Zhang Rui <rui.zhang@intel.com> 
> ---
>  drivers/acpi/glue.c |   14 ++++++++++++++
>  1 files changed, 14 insertions(+)
> 
> Index: linux-2.6.21-rc5/drivers/acpi/glue.c
> ===================================================================
> --- linux-2.6.21-rc5.orig/drivers/acpi/glue.c	2007-04-06 16:06:04.000000000 +0800
> +++ linux-2.6.21-rc5/drivers/acpi/glue.c	2007-04-06 17:32:40.000000000 +0800
> @@ -147,6 +147,7 @@ EXPORT_SYMBOL(acpi_get_physical_device);
>  static int acpi_bind_one(struct device *dev, acpi_handle handle)
>  {
>  	acpi_status status;
> +	struct acpi_device *acpi_dev;
>  
>  	if (dev->archdata.acpi_handle) {
>  		printk(KERN_WARNING PREFIX
> @@ -161,16 +162,29 @@ static int acpi_bind_one(struct device *
>  	}
>  	dev->archdata.acpi_handle = handle;
>  
> +	if (!acpi_bus_get_device(handle, &acpi_dev)) {
> +		sysfs_create_link(&dev->kobj, &acpi_dev->dev.kobj, "ACPI_node");
> +		sysfs_create_link(&acpi_dev->dev.kobj, &dev->kobj, "physical_node");
> +	}
> +
>  	return 0;
>  }
>  
>  static int acpi_unbind_one(struct device *dev)
>  {
> +	struct acpi_device *acpi_dev;
> +
>  	if (!dev->archdata.acpi_handle)
>  		return 0;
>  	if (dev == acpi_get_physical_device(dev->archdata.acpi_handle)) {
>  		/* acpi_get_physical_device increase refcnt by one */
>  		put_device(dev);
> +
> +		if (!acpi_bus_get_device(dev->archdata.acpi_handle, &acpi_dev)) {
> +			sysfs_remove_link(&dev->kobj, "ACPI_node");
> +			sysfs_remove_link(&acpi_dev->dev.kobj, "physical_node");
> +		}
> +
>  		acpi_detach_data(dev->archdata.acpi_handle,
>  				 acpi_glue_data_handler);
>  		dev->archdata.acpi_handle = NULL;
> 

  reply	other threads:[~2007-04-06 15:43 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 [this message]
2007-04-07  5:01         ` Greg KH
2007-04-07 20:08           ` David Brownell
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=200704060843.30723.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.