These tests already occur elsewhere
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Cc: Corentin Chary <corentincj@iksaif.net>
Cc: Karol Kozimor <sziwan@users.sourceforge.net>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>

Some Toshibas only send ACPI events on key down, not key release. Ignore
any release events and send key down and key up events on every ACPI key
down event.
Signed-off-by: NFrans Pop <elendil@planet.nl>

Make sure that work is cancelled after removing the i8042 filter, and
unregister the platform device rather than deleting it.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The following build bug (x86, allyesconfig):

  arch/x86/oprofile/built-in.o:(.data+0x250): multiple definition of `buffer_mutex'

Was triggered in -tip testing, caused by this upstream commit:

  116ee77b: dell-laptop: Use buffer with 32-bit physical address

There's multiple buffer_mutex's in the kernel. Make this new one
static.
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Signed-off-by: NCorentin Chary <corentincj@iksaif.net>

There is two reason to do that:
- we don't want a "gps" file if the model doesn't have a gps
- we don't want to use global variables anymore
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>

Remove all "templates" and add a generic struct asus_led instead.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>

The rfkill subsystem will enable gps by default.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>

There is no way to find the initial lcd state. A quick workaround
is to set it "on" by default. Anyway this feature is scheduled for removal.
Signed-off-by: NCorentin Chary <corentin.chary@gmail.com>

These bug where introduced in "asus-laptop: code movement".
Signed-off-by: NCorentin Chary <corentin.chary@gmail.com>

We don't want to send KEY_BRIGHTNESSDOWN or KEY_BRIGHTNESSUP
because it would be a lie to tell userspace that we want
to change the brightness while it's actually done by the
firmware.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>

Reported by Andrey F. Ilchuk
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>

This patch is based on Dmitry Torokhov's patch with
some modifications and cleanups.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>

Signed-off-by: NCorentin Chary <corentincj@iksaif.net>

Also add to helpers for bluetooth and wlan.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>

Stop using ASUS_HANDLE because most of the time it is not needed.
This macro was introduced to display_get and lcd_switch which are not
part of the interface provided by Asus, and are scheduled for removal.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>

Signed-off-by: NCorentin Chary <corentincj@iksaif.net>

Signed-off-by: NCorentin Chary <corentincj@iksaif.net>

(anyway lcd code is scheduled for removal)
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>

Signed-off-by: NCorentin Chary <corentincj@iksaif.net>

Signed-off-by: NCorentin Chary <corentincj@iksaif.net>

The asus-laptop driver implements a number of interfaces like the
backlight class driver.  This change makes it easier to examine the
implementation of one interface at at a time, without having to search
through the file to find init() and exit() functions etc.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>

(Changelog stolen from Alan's patch for eeepc-laptop, but this patch
does the same thing for asus-laptop)

Callback methods should not refer to a variable like "asus" (formally
"hotk").  Instead, they should extract the data they need either from
a "driver data" parameter, or the "driver data" field of the object
which they operate on.  The "asus" variable can then be removed.

In practice, drivers under "drivers/platform" can get away without using
driver data, because it doesn't make sense to have more than one
instance of them.  However this makes it harder to review them for
correctness.  This is especially true for core ACPI developers who have
not previously been exposed to this anti-pattern :-).

This will serve as an example of best practice for new driver writers
(whether they find it themselves, or have it pointed out during review
:-).
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>

Prepare the use of "driver data" for callbacks.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>

asus-laptop now does a lot more than just hotkeys.  Replace the "hotk"
names used throughout the driver with some slightly more appropriate
names.  The actual strings used in kernel messages and sysfs are left
unchanged.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>

Clean asus-laptop initialization to match new eeepc-laptop code.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>

Signed-off-by: NCorentin Chary <corentincj@iksaif.net>

Signed-off-by: NCorentin Chary <corentincj@iksaif.net>

We only need a buffer for "INIT". Adds write_acpi_init_ret for it.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>

We already tell the backlight class our maximum brightness value; it
will validate the user requested values for us.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>

These to parameter allow to set the status of wlan and bluetooth
device when the module load. On some models, the device will
always be down on boot, so the default behavior is to always
enable these devices.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>

Before we mark the wireless device as unplugged, check PCI config space
to see whether the wireless device is really disabled (and vice versa).
This works around newer models which don't want the hotplug code, where
we end up disabling the wired network device.

My old 701 still works correctly with this.  I can also simulate an
afflicted model by changing the hardcoded PCI bus/slot number in the
driver, and it seems to work nicely (although it is a bit noisy).

In future this type of hotplug support will be implemented by the PCI
core.  The existing blacklist and the new warning message will be
removed at that point.
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>

The wireless hotplug code is not needed on this model, and it disables
the wired ethernet card.  (Like on the 1005HA and 1201N).

References: <http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2010-February/003281.html>
Signed-off-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk>
Reported-by: NAnsgar Burchardt <ansgar@43-1.org>
CC: stable@kernel.org

Lots of changes. Remove volatile keywords. Take the advice in the comments
and change video_slot to slot_addr. Factor out fifteen or so "channel >>
8" shifts into three shifts higher up the call graph. Make
csc_setpalette() atomic, pass the correct color values. Check for
ioremap() failure. Add missing break statement, thus fixing 24 bit console
visual (blue background bug). Remove some uninformative printk() noise.
Add a description for powerbook 140/170 graphics.
Signed-off-by: NFinn Thain <fthain@telegraphics.com.au>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

Cleanup whitespace and code style. Remove unused #includes and prototypes.
Remove obsolete, redundant or misleading comments. Remove dead code and
redundant initialisers.
Signed-off-by: NFinn Thain <fthain@telegraphics.com.au>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

Add the missing mac video modes for the Portrait and 12" RGB displays. The
specs come from the Mac LC III developer note.
Signed-off-by: NFinn Thain <fthain@telegraphics.com.au>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

The valkyriefb driver needs the CUDA to work in order to set the video
mode at boot. So initialise the device earlier, and bring the m68k code
closer to the powermac code.
Signed-off-by: NFinn Thain <fthain@telegraphics.com.au>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

Valkyriefb and macfb will adopt the same card if they get the chance, so
remove valkyrie support from macfb. Also fix the "valkyriefb: can't do
832x624x8" problem reported by Raylynn Knight some time ago, by adding
vmode 13 support for CONFIG_MAC. Also add vmode 11 since that works too.
Make use of the monitor sense lines on 68k Macs too. Also some cleanups.
Signed-off-by: NFinn Thain <fthain@telegraphics.com.au>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

The valkyriefb driver assumes that this logic holds:

mac_vmode_to_var(X, cmode, &var);
mac_var_to_vmode(&var, &vmode, &cmode);
assert(vmode == X);

But it doesn't hold because mac_var_to_vmode() can return a mode with a
slower pixel clock, even when a match is available. So we end up with this
failure:

using video mode 11 and color mode 0.
valkyriefb: vmode 12 not valid.
valkyriefb: can't set default video mode
valkyriefb: vmode 12 not valid.

Rather than have mac_var_to_mode() return the first reasonable mode it
finds, have it return the mode that is closest to the requested one (or
the mode with the closest longer pixel clock period if there is no exact
match).
Signed-off-by: NFinn Thain <fthain@telegraphics.com.au>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

Move platform device code from the drivers to the platform init function.
Signed-off-by: NFinn Thain <fthain@telegraphics.com.au>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>