Applied,
and thanks for turning over the rocks in sysfs to see what wiggled out:-)
thanks,
-Len
On Tuesday 03 April 2007 20:41, David Brownell wrote:
> This updates /proc/acpi/wakeup to be more informative, primarily by showing
> the sysfs node associated with each wakeup-enabled device.
Applied,
and thanks for turning over the rocks in sysfs to see what wiggled out:-)
thanks,
-Len
On Tuesday 03 April 2007 20:41, David Brownell wrote:
This updates /proc/acpi/wakeup to be more informative, primarily by showing
the sysfs node associated with each wakeup-enabled device. Example:
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
> >
On Tue, Apr 17, 2007 at 02:57:49PM -0700, David Brownell wrote:
> On Tuesday 17 April 2007 12:53 pm, David Brownell wrote:
> > On Friday 13 April 2007 8:59 am, Pavel Machek wrote:
> >
> > > ...
> > > > Assuming they all adopt that same "parallel tree" model, that seems
> > > > like a good idea.
On Tuesday 17 April 2007 12:53 pm, David Brownell wrote:
> On Friday 13 April 2007 8:59 am, Pavel Machek wrote:
>
> > ...
> > > 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
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.
> >
> >
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
On Tuesday 17 April 2007 12:53 pm, David Brownell wrote:
On Friday 13 April 2007 8:59 am, Pavel Machek wrote:
...
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
On Tue, Apr 17, 2007 at 02:57:49PM -0700, David Brownell wrote:
On Tuesday 17 April 2007 12:53 pm, David Brownell wrote:
On Friday 13 April 2007 8:59 am, Pavel Machek wrote:
...
Assuming they all adopt that same parallel tree model, that seems
like a good idea. The tools will
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
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
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.
On Tuesday 10 April 2007 4:29 pm, David Brownell wrote:
> ... the appended
> patch goes on top of the previous pnpacpi patch, and should (nyet tested!)
> fix another place I saw that warning.
And here's a tested version. Curiouser and curiouser. I think the mapping
of ACPI tables to sysfs
On Saturday 07 April 2007 1:08 pm, David Brownell wrote:
> 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/pci:00 ... pci root
On Saturday 07 April 2007 1:08 pm, David Brownell wrote:
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/pci:00 ... pci root node
On Tuesday 10 April 2007 4:29 pm, David Brownell wrote:
... the appended
patch goes on top of the previous pnpacpi patch, and should (nyet tested!)
fix another place I saw that warning.
And here's a tested version. Curiouser and curiouser. I think the mapping
of ACPI tables to sysfs
> On Sat, 2007-04-07 at 13:08 -0700, David Brownell wrote:
> > 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
On Sat, 2007-04-07 at 13:08 -0700, David Brownell wrote:
> 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
On Sat, 2007-04-07 at 13:08 -0700, David Brownell wrote:
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
On Sat, 2007-04-07 at 13:08 -0700, David Brownell wrote:
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
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
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
On Fri, Apr 06, 2007 at 08:43:30AM -0700, David Brownell wrote:
> > > 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
> > >
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
On Thu, 2007-04-05 at 03:58 -0700, David Brownell wrote:
> On Thursday 05 April 2007 12:59 am, Zhang Rui wrote:
> > On Wed, 2007-04-04 at 08:41 +0800, David Brownell wrote:
> > > In that example, two devices don't actually exist (USB3, S139), one can't
> > > issue wakeup events (PCI0), and two
On Thu, 2007-04-05 at 03:58 -0700, David Brownell wrote:
On Thursday 05 April 2007 12:59 am, Zhang Rui wrote:
On Wed, 2007-04-04 at 08:41 +0800, David Brownell wrote:
In that example, two devices don't actually exist (USB3, S139), one can't
issue wakeup events (PCI0), and two seem
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).
On Fri, Apr 06, 2007 at 08:43:30AM -0700, David Brownell wrote:
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
On Thursday 05 April 2007 12:59 am, Zhang Rui wrote:
> On Wed, 2007-04-04 at 08:41 +0800, David Brownell wrote:
> > In that example, two devices don't actually exist (USB3, S139), one can't
> > issue wakeup events (PCI0), and two seem harmlessly (?) confused (MDM and
> > AUD are the same PCI
On Thursday 05 April 2007 2:26 am, Matthew Garrett wrote:
> On Tue, Apr 03, 2007 at 05:41:42PM -0700, David Brownell wrote:
> > This updates /proc/acpi/wakeup to be more informative, primarily by showing
> > the sysfs node associated with each wakeup-enabled device. Example:
>
> This looks good.
On Tue, Apr 03, 2007 at 05:41:42PM -0700, David Brownell wrote:
> This updates /proc/acpi/wakeup to be more informative, primarily by showing
> the sysfs node associated with each wakeup-enabled device. Example:
This looks good.
> S139 S4 disabled
Any idea what this one is?
On Wed, 2007-04-04 at 08:41 +0800, David Brownell wrote:
> This updates /proc/acpi/wakeup to be more informative, primarily by
> showing
> the sysfs node associated with each wakeup-enabled device. Example:
>
> Device S-state Status Sysfs node
> PCI0 S4 disabled
On Wed, 2007-04-04 at 08:41 +0800, David Brownell wrote:
This updates /proc/acpi/wakeup to be more informative, primarily by
showing
the sysfs node associated with each wakeup-enabled device. Example:
Device S-state Status Sysfs node
PCI0 S4 disabled
On Thursday 05 April 2007 2:26 am, Matthew Garrett wrote:
On Tue, Apr 03, 2007 at 05:41:42PM -0700, David Brownell wrote:
This updates /proc/acpi/wakeup to be more informative, primarily by showing
the sysfs node associated with each wakeup-enabled device. Example:
This looks good.
Also
On Thursday 05 April 2007 12:59 am, Zhang Rui wrote:
On Wed, 2007-04-04 at 08:41 +0800, David Brownell wrote:
In that example, two devices don't actually exist (USB3, S139), one can't
issue wakeup events (PCI0), and two seem harmlessly (?) confused (MDM and
AUD are the same PCI device, but
On Tue, Apr 03, 2007 at 05:41:42PM -0700, David Brownell wrote:
This updates /proc/acpi/wakeup to be more informative, primarily by showing
the sysfs node associated with each wakeup-enabled device. Example:
This looks good.
S139 S4 disabled
Any idea what this one is?
This updates /proc/acpi/wakeup to be more informative, primarily by showing
the sysfs node associated with each wakeup-enabled device. Example:
Device S-state Status Sysfs node
PCI0 S4 disabled no-bus:pci:00
PS2M S4 disabled pnp:00:05
This updates /proc/acpi/wakeup to be more informative, primarily by showing
the sysfs node associated with each wakeup-enabled device. Example:
Device S-state Status Sysfs node
PCI0 S4 disabled no-bus:pci:00
PS2M S4 disabled pnp:00:05
38 matches
Mail list logo
