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: Pavel Machek <pavel@ucw.cz>, 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: Tue, 17 Apr 2007 20:25:52 -0700	[thread overview]
Message-ID: <200704172025.52862.david-b@pacbell.net> (raw)
In-Reply-To: <20070418030343.GB12756@kroah.com>

On Tuesday 17 April 2007 8:03 pm, Greg KH wrote:
> On Tue, Apr 17, 2007 at 02:57:49PM -0700, David Brownell wrote:

> > Looks like the i8042 serial nodes will be bizarre too:
> > 
> > 	/sys/devices/pnp0/00:09
> > 		... touchpad's PNP node
> > 	/sys/devices/acpi_system:00/device:00/PNP0A03:00/device:15/PNP0F13:00
> > 		... its ACPI node
> > 	/sys/devices/platform/i8042/serio4
> > 		... its serio node
> > 
> > That seems like two nodes too many, but without me trying to twist
> > my mind around i8042 issues, I can't quite speculate why struct
> > serio "is-a" device rather than "has-a" device (the PNP node) as
> > would be the case with a more normal driver structure.
> > 
> > But the existence of that device_add() in serio.c sure explains why
> > the PNP node doesn't get associated with the input class device one
> > would expect from knowing that 00:09 is the touchpad.
> 
> Ick, how can we fix this up?

You're asking the wrong penguin for that answer ... :)

But I'd suggest that someone who knows ACPI -- and PNPACPI --- work
on merging those ACPI and PNP nodes.  (Same thing would need doing
with ACPI and PCI ...)

That ACPI subtree is quite new, at least in terms of being public.
So I'd think its details must be very flexible right now.


> > And hmm, just this morning I saw email from Greg re-affirming that
> > drivers should not device_add().  Converting such legacy drivers is
> > simple though, right?  :)
> 
> Heh, yeah right, they can remain platform drivers :)

Most platform drivers aren't legacy drivers.  Just the x86 ones!
And a lot of those wouldn't be headaches if PNPACPI were used better...

In this case, making the i8042 stuff use PNP more naturally would
seem like the most natural way to resolve the problem for all but
pre-ACPI legacy x86 hardware.  Now that ACPI implies PNPACPI by
default, various corner cases have vanished.

That said, I know less about i8042 wierdness -- and I know there's
a lot of it! -- than about ACPI, so I'll stay out of that.  Beyond
pointing out these curious little corner cases I've uncovered while
trying to make sure wakeup annotations get assigned to the right
sysfs device nodes.  :)

- Dave


> 
> thanks,
> 
> greg k-h
> 

  reply	other threads:[~2007-04-18  3:25 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
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 [this message]
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=200704172025.52862.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=pavel@ucw.cz \
    --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