This patch adds a .notify() method. The presence of .notify() causes
Linux/ACPI to manage event handlers and notify handlers on our behalf,
so we don't have to install and remove them ourselves.
Tested by Tony on Fujitsu-Siemens Lifebook S6420 [FJNB1E6] with
BIOS 1.18 (01/09/2009). Tested by Jonathan on Fujitsu S7020.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Acked-By: Tony Vroon <tony@linx.net>
Tested-By: Tony Vroon <tony@linx.net>
Acked-by: Jonathan Woithe <jwoithe@physics.adelaide.edu.au>
Tested-by: Jonathan Woithe <jwoithe@physics.adelaide.edu.au>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch adds a .notify() method. The presence of .notify() causes
Linux/ACPI to manage event handlers and notify handlers on our behalf,
so we don't have to install and remove them ourselves.
Tested by Tony on Fujitsu-Siemens Lifebook S6420 [FJNB1E6] with
BIOS 1.18 (01/09/2009). Tested by Jonathan on Fujitsu S7020.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Acked-By: Tony Vroon <tony@linx.net>
Tested-By: Tony Vroon <tony@linx.net>
Acked-by: Jonathan Woithe <jwoithe@physics.adelaide.edu.au>
Tested-by: Jonathan Woithe <jwoithe@physics.adelaide.edu.au>
Signed-off-by: Len Brown <len.brown@intel.com>
Up until now, we polled the rfkill status for every incoming FUJ02E3 ACPI event.
It turns out that the firmware has a bitmask which indicates what rfkill-related
state it can report.
The rfkill_supported bitmask is now used to avoid polling for rfkill at all in
the notification handler if there is no support. Also, it is used in the platform
device callbacks. As before we register all callbacks and report "unknown" if the
firmware does not give us status updates for that particular bit.
This was fed through checkpatch.pl and tested on the S6420, S7020 and P8010
platforms.
Signed-off-by: Tony Vroon <tony@linx.net>
Tested-by: Stephen Gildea <stepheng+linux@gildea.com>
Acked-by: Jonathan Woithe <jwoithe@physics.adelaide.edu.au>
Signed-off-by: Len Brown <len.brown@intel.com>
Move x86 platform specific drivers from drivers/misc/
to a new home under drivers/platform/x86/.
The community has been maintaining x86 vendor-specific
platform specific drivers under /drivers/misc/ for a few years.
The oldest ones started life under drivers/acpi.
They moved out of drivers/acpi/ because they don't actually
implement the ACPI specification, but either simply
use ACPI, or implement vendor-specific ACPI extensions.
In the future we anticipate...
drivers/misc/ will go away.
other architectures will create drivers/platform/<arch>
Signed-off-by: Len Brown <len.brown@intel.com>
