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:	Fri, 7 Jan 2011 01:22:12 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	David Brownell <david-b@...bell.net>
Cc:	Len Brown <lenb@...nel.org>,
	"Linux-pm mailing list" <linux-pm@...ts.linux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>
Subject: Re: [linux-pm] [PATCH 10/11] ACPI: Drop device flag wake_capable

On Friday, January 07, 2011, David Brownell wrote:
> 
> --- On Thu, 1/6/11, Rafael J. Wysocki <rjw@...k.pl> wrote:
> 
> 
> > 
> > The wake_capable ACPI device flag is not necessary, because
> > it is
> > only used in scan.c for recording the information
> 
> 
> Only  for ACPI, yes? Generically, it records data for any
> wake-capable dvice, and is not ACPI-specific...

You're wrong, sorry.  It _is_ ACPI-specific.

> My bias is that ACPI should  work the way other PM
> solutions/hardware work, not collect special cases
> unique to ACPI (kind of like this.) ...

So this patch is going into the right direction, isn't it?

>  that _PRW
> > is
> > present for the given device.  That information is
> > only used by
> > acpi_add_single_object() to decide whether or not to call
> > acpi_bus_get_wakeup_device_flags(), so the flag may be
> > dropped
> > if the _PRW check is moved to
> > acpi_bus_get_wakeup_device_flags().
> 
> Only if you presume ACPI ....

What do you mean _exactly_?  This flags is _not_ used anywhere outside of
drivers/acpi/scan.c, so what's the problem?

> I'm glad to see that generic-vs-ACPI duplication
> of flags vanishing; way back when I started to add
> wakeup support, I had to stop part way through ACPI
> in large part because wake didn't work well yet in the Linux PM
> framework, except for select non-ACPI HW.
> (Starting with a USB subset: OTG and hub port sleep and ewakeup); oh, also GPIO wake on some HW, e.g.
> or buttons, and switches like MMC/SD card detect. ISTR that stuff still wierds out a bit as it goes
> through Linux-ACPI.
> 
> Also, to the extent that the ACPI code was supposed
> to be generic and not Linux-specific, I thought Len
> or someone from Intel should drive such issues.

Again, please be more specific.

It appears you haven't been following the development in this area for years
and now you're making comments I can't really understand.  What's up, really?

Rafael
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ