linux-kernel - Re: [patch 2.6.21-rc5-git] make /proc/acpi/wakeup more useful

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 17 Apr 2007 12:53:02 -0700
From:	David Brownell <david-b@...bell.net>
To:	Pavel Machek <pavel@....cz>
Cc:	Greg KH <greg@...ah.com>, Zhang Rui <rui.zhang@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>, lenb@...nel.org,
	"linux-acpi@...r" <linux-acpi@...r.kernel.org>,
	Linux Kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [patch 2.6.21-rc5-git] make /proc/acpi/wakeup more useful

On Friday 13 April 2007 8:59 am, Pavel Machek wrote:
> Hi!
> 
> > > 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

(Clarifying:  the ACPI *code* works that way.  I have no idea whether
ACPI itself makes such restrictions.  And I suspect that ACPI practice
will in some cases couple multiple ACPI devices to one PCI device...)

> ...
> > 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.
> 
> If mapping is indeed 1-to-1 in acpi... it would be nice to just merge
> the trees.

Could you elaborate a bit ... what do you mean by "merge"?

One way to merge the trees would be to relocate

	/sys/devices/pci* --> ... this *HAS* a PNP node
	/sys/devices/pnp*/X --> /sys/devices/acpi_system*/.../X

Not having the PCI root be its PNPACPI node seems more buglike
to me than anything else.  And for other nodes, it seems like
maybe there should be a "firmware" subdirectory holding the
ACPI state (hid, path, etc) ... creating a minor chicken/egg
problem that ACPI would need to sort out.  Likely one can just
assume PCI and PNP busses exist, so creating nodes on those
buses based on ACPI tables would not be a problem.  And for
ACPI-internal devices, like SLPB and power buttons, the ACPI
bus would suffice.  But are there other busses?

- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/