Commit Graph

106 Commits

Author SHA1 Message Date
Alan Jenkins eacec3031d eeepc-laptop: set acpi_driver.owner
The owner field provides the link between drivers and modules in sysfs,
but no ACPI driver was setting it.

After setting the owner field, we can see which module provides which
driver and vice versa by looking at /sys/bus/acpi/driver/*/module and
/sys/module/*/drivers/acpi:*.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-09 15:54:31 -05:00
Alan Jenkins 2adb8bd380 eeepc-laptop: Remove uneccesary acpi_disabled check
acpi_bus_register_driver() already checks acpi_disabled, so acpi bus
drivers don't need to.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-09 15:54:30 -05:00
Alan Jenkins fbe3d8942e eeepc-laptop: Remove redundant NULL checks
The acpi device callbacks add, start, remove, suspend and resume can
never be called with a NULL acpi_device. Each callsite in acpi/scan.c
has to dereference the device in order to get the ops structure, e.g.

    struct acpi_device *acpi_dev = to_acpi_device(dev);
    struct acpi_driver *acpi_drv = acpi_dev->driver;

    if (acpi_drv && acpi_drv->ops.suspend)
        return acpi_drv->ops.suspend(acpi_dev, state);

Remove all checks for acpi_dev == NULL within these callbacks.

Also remove the checks for acpi_driver_data(acpi_dev) == NULL. None of
these checks could fail unless the driver does something strange
(which none of them do), the acpi core did something terribly wrong,
or we have a memory corruption issue. If this does happen then it's
best to dereference the pointer and crash noisily.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-09 15:54:30 -05:00
Corentin Chary 3c0eb51069 eeepc-laptop: add touchpad led
This led can be found on Eeepc 1005 series.

Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-09 15:54:30 -05:00
Alan Jenkins 6dff29b63a eeepc-laptop: disp attribute should be write-only
Currently, reading from the disp attribute fails with "No such device",
which is misleading. According to CMSG table on acpi4asus project site,
no models have a getter method corresponding to SDSP. Change the file
permission to disallow reads.

If some joker changes the permission to permit reads, then return -EIO
to be consistent with sysfs' behaviour when no show() method is
provided.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-12-09 15:54:29 -05:00
Luca Niccoli 80f0c895b5 eeepc-laptop: don't enable camera at startup if it's already on.
Switching the camera takes 500ms, checking if it's on is almost free...
The BIOS remembers the setting through reboots, so there's good chance the
camera is already enabled.

Signed-off-by: Luca Niccoli <lultimouomo@gmail.com>
Cc: Corentin Chary <corentincj@iksaif.net>
Cc: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Cc: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-11-03 10:24:19 -05:00
Corentin Chary 58ce48a9de Revert "eeepc-laptop: Prevent a panic when disabling RT2860 wireless when associated"
rt2860sta is fine with the patch as is, but iwl3945 isn't
(eeepc_rfkill_set() needs to call eeepc_rfkill_hotplug(true) – which means
that we're back to causing the rt2860sta panic

This reverts commit b56ab33d68.

Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Darren Salt <linux@youmustbejoking.demon.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-11-03 10:23:52 -05:00
Darren Salt b56ab33d68 eeepc-laptop: Prevent a panic when disabling RT2860 wireless when associated
This works around what I think is actually a bug in rt2860sta which is
triggered when the hardware "disappears" from beneath the driver, i.e. when
wireless is toggled off via ACPI. It does so by ensuring that the rfkill
soft-block flag is set before the hardware is disabled.

I do not know whether this patch is required if rt2800pci is in use instead
of rt2860sta; at the time of submission of this patch, I've not been able to
test this.

(Ref. http://bugzilla.kernel.org/show_bug.cgi?id=13390)

Signed-off-by: Darren Salt <linux@youmustbejoking.demon.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-10-13 01:26:41 -04:00
Rakib Mullick dcb73eed70 eeepc-laptop: Properly annote eeepc_enable_camera().
Currently the annotation for function eeepc_enable_camera() is
__init, and refers to a
function eeepc_hotk_add() which is non-init. Use __devinit for both
functions which is
more appropriate and fixes a section mismatch warning.

 We were warned by the following warning:

  LD      drivers/platform/x86/built-in.o
WARNING: drivers/platform/x86/built-in.o(.text+0x12e1): Section
mismatch in reference from the function eeepc_hotk_add() to the
function .init.text:eeepc_enable_camera()
The function eeepc_hotk_add() references
the function __init eeepc_enable_camera().
This is often because eeepc_hotk_add lacks a __init
annotation or the annotation of eeepc_enable_camera is wrong.

Signed-off-by: Rakib Mullick <rakib.mullick@gmail.com>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-10-13 01:24:40 -04:00
Linus Torvalds d910fc7860 Merge branch 'for-linus' of git://git.o-hand.com/linux-rpurdie-backlight
* 'for-linus' of git://git.o-hand.com/linux-rpurdie-backlight:
  backlight: new driver for ADP5520/ADP5501 MFD PMICs
  backlight: extend event support to also support poll()
  backlight/eeepc-laptop: Update the backlight state when we change brightness
  backlight/acpi: Update the backlight state when we change brightness
  backlight: Allow drivers to update the core, and generate events on changes
  backlight: switch to da903x driver to dev_pm_ops
  backlight: Add support for the Avionic Design Xanthos backlight device.
  backlight: spi driver for LMS283GF05 LCD
  backlight: move hp680-bl's probe function to .devinit.text
  backlight: Add support for new Apple machines.
  backlight: mbp_nvidia_bl: add support for MacBookAir 1,1
  backlight: Add WM831x backlight driver

Trivial conflicts due to '#ifdef CONFIG_PM' differences in
drivers/video/backlight/da903x_bl.c
2009-09-26 10:49:42 -07:00
Matthew Garrett d822d5c273 backlight/eeepc-laptop: Update the backlight state when we change brightness
Trigger a status update when the user hits a brightness key, allowing
userspace to present appropriate UI.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-09-21 21:05:02 +01:00
Alan Jenkins 52cc96bd5b eeepc-laptop: allow rfkill hotplug to work on the 900A model
The 900A provides hotplug notifications on a different ACPI object to
other models.

Reported-by: Trevor <trevor.chart@gmail.com>
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-08-29 14:17:18 -04:00
Alan Jenkins a825806979 eeepc-laptop: fix rfkill memory leak on unload
rfkill_unregister() should always be followed by rfkill_destroy()

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-08-29 14:16:30 -04:00
Len Brown aeb41b852f eeepc-laptop: whitespace for checkpatch.pl
checkpatch doesn't like tab+space for a return statement.

WARNING: suspect code indent for conditional statements (8, 17)
+	if (!device)
+		 return -EINVAL;

Signed-off-by: Len Brown <len.brown@intel.com>
2009-08-28 19:03:11 -04:00
Corentin Chary d1ec9c3d43 eeepc-laptop: add rfkill support for the Wimax in ASUS Eee PC 1000HG
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-08-28 15:21:12 -04:00
Alan Jenkins c200da5d29 eeepc-laptop: switch to dev_pm_ops
This also involves switching the resume handler from the acpi device
to the platform device.  Using the more fine grained handlers allows
two improvements:

1. We only need to recheck rfkill state after resume from hibernation.

2. The wireless LED workaround accounts for up to 1.1s out of 1.7s
resuming devices (when wireless is enabled).  We can limit the
workaround to thaw(), so that it only delays suspend to disk.

The workaround is only likely to help when hibernation is aborted.
Suspend to ram cannot be aborted by the user.  Device suspend errors may
well happen before eeepc-laptop would even be frozen.  Suspend errors
which happen after that could be pretty funky anyway.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-08-28 15:21:11 -04:00
Alan Jenkins c1edd99f1c eeepc-laptop: correct the description of the hibernation abort bug
Actually it is only the LED which is affected.  The bios bug does not
disable the wifi.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-08-28 15:21:11 -04:00
Alan Jenkins a47461011a eeepc-laptop: check the 3G rfkill state on resume
All the rfkill devices are treated as "persistent", 3G is no exception.
This means their state may change over hibernation.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-08-28 15:21:11 -04:00
Alan Jenkins ffb0357528 eeepc-laptop: remove redundant rfkill_set_sw_state in resume handler
rfkill_set_sw_state() will already be called by eeepc_rfkill_hotplug().

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-08-28 15:21:11 -04:00
Alan Jenkins f2a9d5e8a6 eeepc-laptop: make input device a child of the platform device
Sysfs showed the ehotk input device as a "virtual" device - lies!
The input device is provided by a physical device, the eeepc platform.

This requires that we move the creation of the input device to come
after platform device is created.  Input initialization is moved from
ehotk_check() [sic] to a new function called eeepc_input_init().  This
brings the input device into line with the other eeepc-laptop devices.

Also, refuse to load if we fail to register the input device.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-08-28 15:21:11 -04:00
Alan Jenkins 1e7798547f eeepc-laptop: fix ordering of init and exit functions
1. input and backlight devices were registered after acpi notifications
   are enabled.  This left a window where eeepc_hotk_notify() might
   find these devices in an inconsistent (half-initialized) state.

-> Move all device registration into eeepc_hotk_add(), which is called
   before enabling acpi notifications.

2. input and backlight devices were unregistered before acpi
   notifications are disabled.  This left a window where
   eeepc_hotk_notify() might find these devices in an inconsistent
   (half-destroyed) state.

-> Move all device unregistration into eeepc_hotk_remove(), which is
   called after disabling acpi notifications.

3. The acpi driver was not freed if an error occured further down in
   eeepc_laptop_init().

-> The rest of eeepc_laptop_init() has been moved to eeepc_hotk_add(),
   so this is no longer a problem.

4. The acpi driver was unregistered before the platform driver.  This
   left a window where a sysfs access could attempt to read the ehotk
   structure after it had been freed by eeepc_hotk_remove().

-> The acpi driver is now unregistered as the last step in
   eeepc_laptop_exit(), so this is no longer a problem.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-08-28 15:21:11 -04:00
Alan Jenkins 07e84aa98f eeepc-laptop: fix pci hotplug race on load and unload
Wifi rfkill state changes can race with pci hotplug cleanup.  A simple
fix is to refresh the hotplug state just before deregistering the pci
hotplug slot.

There is also potential for a hotplug notification to fire too early
during setup, while the structures it uses are still being initialised.
(This could only happen if the BIOS performs hotplug itself; a bug
triggered by removing the battery while hibernated).  Avoid this by
registering the notifier later.  The same refresh mechanism is used
to handle rfkill state changes which can now race with registration.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-08-28 15:21:11 -04:00
Alan Jenkins dcf443b581 eeepc-laptop: use a mutex to serialize pci hotplug (resume vs. notify)
Commit d0265f0 "eeepc-laptop: fix hot-unplug on resume" used a workqueue
to protect pci hotplug against multiple simultaneous calls during
resume.  It seems to work, but a mutex would be more appropriate.

This is in preparation to fix the potential pci hotplug race on unload.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-08-28 15:21:11 -04:00
Alan Jenkins 6d41839e76 eeepc-laptop: don't touch the pci slot if it was claimed by a different driver
The whole point of registering as a PCI hotplug driver was to prevent
conflict with pciehp.  At the moment it happens to work because
eeepc-laptop is loaded first, but it doesn't work the other way round.
If pciehp is loaded first then we fail to claim the slot - we need to
respect this and not handle hotplug events.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-08-28 15:21:10 -04:00
Alan Jenkins 7334546a52 eeepc-laptop: fix hot-unplug on resume
OOPS on resume when the wireless adaptor is disabled during suspend was
introduced by "eeepc-laptop: read rfkill soft-blocked state on resume".

Unable to handle kernel NULL pointer dereference

Process s2disk
Tainted: G W
IP: klist_put

Call trace:
? klist_del
? device_del
? device_unregister
? pci_stop_dev
? pci_stop_bus
? pci_remove_device
? eeepc_rfkill_hotplug [eeepc_laptop]
? eeepc_hotk_resume [eeepc_laptop]
? acpi_device_resume
? device_resume
? hibernation_snapshot

It appears the PCI device is removed twice.  The eeepc_rfkill_hotplug()
call from the resume handler is racing against the call from the ACPI
notifier callback.  The ACPI notification is triggered by the resume
handler when it refreshes the value of CM_ASL_WLAN.

The fix is to serialize hotplug calls using a workqueue.

http://bugzilla.kernel.org/show_bug.cgi?id=13825

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Acked-by: Corentin Chary <corentin.chary@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-08-02 12:35:53 -04:00
Corentin Chary 3cd530b5aa eeepc-laptop: add rfkill support for the 3G modem in Eee PC 901 Go
Signed-off-by: Janne Grunau <j@jannau.net>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-06-26 00:23:41 -04:00
Corentin Chary dbfa3ba90d eeepc-laptop: get the right value for CMSG
CMSG is an ACPI method used to find features available on
an Eee PC. But some features are never repported, even if present.

If the getter of a feature is present, this patch will set
the corresponding bit in cmsg.

Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-06-26 00:23:41 -04:00
Corentin Chary f36509e724 eeepc-laptop: makes get_acpi() returns -ENODEV
If there is there is no getter defined, get_acpi()
will return -ENODEV.

Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-06-26 00:23:40 -04:00
Corentin Chary 1ddec2f943 eeepc-laptop: right parent device
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-06-26 00:23:40 -04:00
Corentin Chary 7de39389d8 eeepc-laptop: rfkill refactoring
Refactor rfkill code, because we'll add another
rfkill for wwan3g later.

Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-06-26 00:23:39 -04:00
Joe Perches 19b5328928 eeepc-laptop.c: use pr_fmt and pr_<level>
Convert the unusual printk(EEEPC_<level> uses to
the more standard pr_fmt and pr_<level>(.

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-06-26 00:23:39 -04:00
Corentin Chary 2b121bc262 eeepc-laptop: Register as a pci-hotplug device
The eee contains a logically (but not physically) hotpluggable PCIe slot.
Currently this is handled by adding or removing the PCI device in response
to rfkill events, but if a user has forced pciehp to bind to it (with the
force=1 argument) then both drivers will try to handle the event and
hilarity (in the form of oopses) will ensue. This can be avoided by having
eee-laptop register the slot as a hotplug slot. Only one of pciehp and
eee-laptop will successfully register this, avoiding the problem.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Tested-by: Darren Salt <linux@youmustbejoking.demon.co.uk>
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-06-26 00:23:29 -04:00
Corentin Chary b31d0fde89 eeepc-laptop: cpufv updates
Limit cpufv input to acceptables values.
Add an available_cpufv file to show available
presets.
Change cpufv ouput format from %d to %#x, it won't
break compatibility with existing userspace tools, but
it provide a more human readable output.

Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-06-24 01:31:21 -04:00
Corentin Chary b7b700d4a4 eeepc-laptop: sync eeepc-laptop with asus_acpi
In the default Eee PC distribution, there is a modified
asus_acpi driver. eeepc-laptop is a cleaned version of this
driver. Sync ASL enum and getter/setters with asus_acpi.

Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-06-24 01:31:10 -04:00
Pekka Enberg cede2cb6ee eeepc-laptop: enable camera by default
If we leave the camera disabled by default, userspace programs (e.g.
Skype, Cheese) leave the user out in the cold saying that the machine
"has no camera." Therefore, it's better to enable camera by default and
let people who really don't want it just disable the thing.

To reduce power usage you should enable USB autosuspend:
echo -n auto > /sys/bus/usb/drivers/uvcvideo/*:*/../power/level

Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-06-24 01:30:34 -04:00
Len Brown 57599cc997 Merge branch 'bjorn-notify' into release
Conflicts:
	drivers/platform/x86/eeepc-laptop.c

Signed-off-by: Len Brown <len.brown@intel.com>
2009-06-24 01:22:20 -04:00
Alan Jenkins 96e9cfeb96 eeepc-laptop: read rfkill soft-blocked state on resume
This will respect state changes over hibernation, e.g. if the user
disables the wireless in the BIOS setup screen.

It reveals an issue where ACPI silently kills the wireless on
suspend.  Normally, the BIOS restores the correct state from
non-volatile storage on boot.  But when hibernation is aborted,
the wireless would remain killed.  Fortunately we can work around
this in the resume handler by simply writing back the same value we
read from NVS.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-19 11:50:17 -04:00
Alan Jenkins 06d5caf47e rfkill: don't restore software blocked state on persistent devices
The setting of the "persistent" flag is also made more explicit using
a new rfkill_init_sw_state() function, instead of special-casing
rfkill_set_sw_state() when it is called before registration.

Suspend is a bit of a corner case so we try to get away without adding
another hack to rfkill-input - it's going to be removed soon.
If the state does change over suspend, users will simply have to prod
rfkill-input twice in order to toggle the state.

Userspace policy agents will be able to implement a more consistent user
experience.  For example, they can avoid the above problem if they
toggle devices individually.  Then there would be no "global state"
to get out of sync.

Currently there are only two rfkill drivers with persistent soft-blocked
state.  thinkpad-acpi already checks the software state on resume.
eeepc-laptop will require modification.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
CC: Marcel Holtmann <marcel@holtmann.org>
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-19 11:50:17 -04:00
Bjorn Helgaas d9b9bd7b4a ACPI: eeepc-laptop: use .notify method instead of installing handler directly
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.

This driver relies on seeing system notify events, not device-specific
ones (because it used ACPI_SYSTEM_NOTIFY).  We use the
ACPI_DRIVER_ALL_NOTIFY_EVENTS driver flag to request all events, then
just ignore any device events we get.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
CC: Corentin Chary <corentincj@iksaif.net>
CC: acpi4asus-user@lists.sourceforge.net
CC: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-06-18 00:13:15 -04:00
Alan Jenkins b3fa1329ea rfkill: remove set_global_sw_state
rfkill_set_global_sw_state() (previously rfkill_set_default()) will no
longer be exported by the rewritten rfkill core.

Instead, platform drivers which can provide persistent soft-rfkill state
across power-down/reboot should indicate their initial state by calling
rfkill_set_sw_state() before registration.  Otherwise, they will be
initialized to a default value during registration by a set_block call.

We remove existing calls to rfkill_set_sw_state() which happen before
registration, since these had no effect in the old model.  If these
drivers do have persistent state, the calls can be put back (subject
to testing :-).  This affects hp-wmi and acer-wmi.

Drivers with persistent state will affect the global state only if
rfkill-input is enabled.  This is required, otherwise booting with
wireless soft-blocked and pressing the wireless-toggle key once would
have no apparent effect.  This special case will be removed in future
along with rfkill-input, in favour of a more flexible userspace daemon
(see Documentation/feature-removal-schedule.txt).

Now rfkill_global_states[n].def is only used to preserve global states
over EPO, it is renamed to ".sav".

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-10 13:28:37 -04:00
Johannes Berg 19d337dff9 rfkill: rewrite
This patch completely rewrites the rfkill core to address
the following deficiencies:

 * all rfkill drivers need to implement polling where necessary
   rather than having one central implementation

 * updating the rfkill state cannot be done from arbitrary
   contexts, forcing drivers to use schedule_work and requiring
   lots of code

 * rfkill drivers need to keep track of soft/hard blocked
   internally -- the core should do this

 * the rfkill API has many unexpected quirks, for example being
   asymmetric wrt. alloc/free and register/unregister

 * rfkill can call back into a driver from within a function the
   driver called -- this is prone to deadlocks and generally
   should be avoided

 * rfkill-input pointlessly is a separate module

 * drivers need to #ifdef rfkill functions (unless they want to
   depend on or select RFKILL) -- rfkill should provide inlines
   that do nothing if it isn't compiled in

 * the rfkill structure is not opaque -- drivers need to initialise
   it correctly (lots of sanity checking code required) -- instead
   force drivers to pass the right variables to rfkill_alloc()

 * the documentation is hard to read because it always assumes the
   reader is completely clueless and contains way TOO MANY CAPS

 * the rfkill code needlessly uses a lot of locks and atomic
   operations in locked sections

 * fix LED trigger to actually change the LED when the radio state
   changes -- this wasn't done before

Tested-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> [thinkpad]
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-06-03 14:06:13 -04:00
Corentin Chary bd32005e12 eeepc-laptop: unregister_rfkill_notifier on failure
If there is a failure during eeepc_hotk_add() we need
to remove the acpi_notify_handler.

Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-05-14 11:28:27 -04:00
Grigori Goronzy 158ca1d75d eeepc-laptop: support for super hybrid engine (SHE)
The older eeepc-acpi driver allowed to control the SHE performance
preset through a ACPI function for just this purpose. SHE underclocks
and undervolts the FSB and undervolts the CPU (at preset 2,
"powersave"), or slightly overclocks the CPU (at preset 0,
"performance"). Preset 1 is the default setting with default clocks and
voltage.

The new eeepc-laptop driver doesn't support it anymore.
The attached patch adds support for it to eeepc-laptop. It's very
straight-forward and almost trivial.

Signed-off-by: Grigori Goronzy <greg@chown.ath.cx>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-05-14 11:23:40 -04:00
Alan Jenkins 978605c4fd eeepc-laptop: Work around rfkill firmware bug
1) Buggy firmware can change the RFKILL state by itself. This is easily
   detected.  The RFKILL API states that in such cases, we should call
   rfkill_force_state() to notify the core.

   I have reported the bug to Asus. I believe this is the right thing
   to do for robustness, even if this particular firmware bug is fixed.

2) The same bug causes the wireless toggle key to be reported as 0x11
   instead of 0x10.  0x11 is otherwise unused, so it should be safe to
   add this as a new keycode.

The bug is triggered by removing the laptop battery while hibernated.

On resume, the wireless toggle key causes the firmware to toggle the
wireless state itself.  (Also, the key is reported as 0x11 when the
current wireless state is OFF).

This is very poor behaviour because the OS can't predict whether the
firmware is controlling the RFKILL state.

Without this workaround, the bug means users have to press the wireless
toggle key twice to enable, due to the OS/firmware conflict.  (Assuming
rfkill-input or equivalent is being used).  The workaround avoids this.

I believe that acpid scripts which toggle the value of the sysfs state file
when the toggle key is pressed will be rendered ineffective by the bug,
regardless of this workaround.  If they simply toggle the state, when the
firmware has already toggled it, then you will never see a state change.

Tested on "EEEPC 4G" only.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-05-14 11:21:36 -04:00
Darren Salt 64b86b6583 eeepc-laptop: report brightness control events via the input layer
This maps the brightness control events to one of two keys, either
KEY_BRIGHTNESSDOWN or KEY_BRIGHTNESSUP, as needed.

Some mapping has to be done due to the fact that the BIOS reports them as
<base value> + <current brightness index>; the selection is done according to
the sign of the change in brightness (if this is 0, no keypress is reported).

(Ref. http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2009-April/002001.html)

Signed-off-by: Darren Salt <linux@youmustbejoking.demon.co.uk>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-05-14 11:19:32 -04:00
Alan Jenkins fbc97e4c5c eeepc-laptop: fix wlan rfkill state change during init
When an rfkill device is registered, the rfkill core will change its
state to the system default. So we need to prepare for state changes
*before* we register it. That means installing the eeepc-specific ACPI
callback which handles the hotplug of the wireless network adaptor.

This problem doesn't occur during normal operation.  You have to

1) Boot with wireless enabled. eeepc-laptop should load automatically.
2) modprobe -r eeepc-laptop
3) modprobe eeepc-laptop

On boot, the default rfkill state will be set to enabled.
With the current core code, step 2) will disable the wireless.
Therefore in step 3), the wireless will change state during registration,
from disabled to enabled.  But without this fix, the PCI device for the
wireless adaptor will not appear.

Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Acked-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-05-14 11:14:42 -04:00
Corentin Chary 7950b71c3b eeepc-laptop: restore acpi_generate_proc_event()
Restore acpi_generate_proc_event() for backward
compatibility with old acpi scripts.

Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-03-16 00:37:31 -04:00
Len Brown 2d29c6a075 Merge branches 'release', 'asus', 'bugzilla-12450', 'cpuidle', 'debug', 'ec', 'misc', 'printk' and 'processor' into release 2009-02-07 01:34:56 -05:00
Darren Salt 7695fb04ac eeepc-laptop: fix oops when changing backlight brightness during eeepc-laptop init
I got the following oops while changing the backlight brightness during
startup.  When it happens, it prevents use of the hotkeys, Fn-Fx, and the
lid button.

It's a clear use-before-init, as I verified by testing with an
appropriately-placed "else printk".

BUG: unable to handle kernel NULL pointer dereference at 00000000
*pde = 00000000
Oops: 0002 [#1] PREEMPT SMP
Pid: 160, comm: kacpi_notify Not tainted (2.6.28.1-eee901 #4) 901
EIP: 0060:[<c0264e68>]  [<c0264e68>] eeepc_hotk_notify+26/da
EFLAGS: 00010246 CPU: 1
Using defaults from ksymoops -t elf32-i386 -a i386
EAX: 00000009 EBX: 00000000 ECX: 00000009 EDX: f70dbf64
ESI: 00000029 EDI: f7335188 EBP: c02112c9 ESP: f70dbf80
 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
 f70731e0 f73acd50 c02164ac f7335180 f70aa040 c02112e6 f733518c c012b62f
 f70aa044 f70aa040 c012bdba f70aa04c 00000000 c012be6e 00000000 f70bdf80
 c012e198 f70dbfc4 f70dbfc4 f70aa040 c012bdba 00000000 c012e0c9 c012e091
Call Trace:
 [<c02164ac>] ? acpi_ev_notify_dispatch+4c/55
 [<c02112e6>] ? acpi_os_execute_deferred+1d/25
 [<c012b62f>] ? run_workqueue+71/f1
 [<c012bdba>] ? worker_thread+0/bf
 [<c012be6e>] ? worker_thread+b4/bf
 [<c012e198>] ? autoremove_wake_function+0/2b
 [<c012bdba>] ? worker_thread+0/bf
 [<c012e0c9>] ? kthread+38/5f
 [<c012e091>] ? kthread+0/5f
 [<c0103abf>] ? kernel_thread_helper+7/10
Code: 00 00 00 00 c3 83 3d 60 5c 50 c0 00 56 89 d6 53 0f 84 c4 00 00 00 8d 42
e0 83 f8 0f 77 0f 8b 1d 68 5c 50 c0 89 d8 e8 a9 fa ff ff <89> 03 8b 1d 60 5c
50 c0 89 f2 83 e2 7f 0f b7 4c 53 10 8d 41 01

Signed-off-by: Darren Salt <linux@youmustbejoking.demon.co.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-02-07 01:02:07 -05:00
Corentin Chary 2b25c9f01a eeepc-laptop: use netlink interface
To be prepared for /proc/acpi/event removal we export events
also through generic netlink interface.

Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-01-20 14:37:12 -05:00
Matthew Garrett 5740294ca3 eeepc-laptop: Implement rfkill hotplugging in eeepc-laptop
The Eee implements rfkill by logically unplugging the wireless card from the
PCI bus. Despite sending ACPI notifications, this does not appear to be
implemented using standard ACPI hotplug - nor does the firmware provide the
_OSC method required to support native PCIe hotplug. The only sensible choice
appears to be to handle the hotplugging directly in the eeepc-laptop driver.
Tested successfully on a 700, 900 and 901.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-01-20 14:36:53 -05:00
Matthew Garrett c9ddf8fede eeepc-laptop: Check return values from rfkill_register
Error out if rfkill registration fails, and also set the default system state
appropriately on boot

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-01-20 14:36:38 -05:00
Matthew Garrett b5f6f26550 eeepc-laptop: Add support for extended hotkeys
Newer Eees have extra hotkeys above the function keys. This patch adds support
for sending them through the input layer.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-01-20 14:35:42 -05:00
Corentin Chary a9df80c509 eeepc-laptop: split eeepc_backlight_exit()
eeepc_backlight_exit() was doing rfkill and input stuff, which
is a nonsense. This patch add two specific exit functions, one
for input and one for rfkill.

Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-01-20 14:34:07 -05:00
Jonathan McDowell 3af9bfcb43 eeepc-laptop: enable Bluetooth ACPI details
Although rfkill support for the EEE bluetooth device has been added to
2.6.28-rc the appropriate ACPI accessor definitions were not added, so
the support was non functional. The patch below adds the get and set
accessors and has been verified to work on an EEE 901.

Signed-off-by: Jonathan McDowell <noodles@earth.li>
Acked-by: Matthew Garrett <mjg@redhat.com>
Acked-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
2009-01-16 14:32:18 -05:00
Len Brown 41b16dce39 create drivers/platform/x86/ from drivers/misc/
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>
2008-12-19 04:42:32 -05:00