ACPI: button: whitespace changes

This patch changes a bit of whitespace to follow Linux conventions.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
ACPI: button: remove unnecessary null pointer checks

Better to oops and learn about a bug than to silently cover it up.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
ACPI: button: use Linux style for getting driver_data

It's typical and slightly more compact to look up the driver_data
structure by initializing the automatic variable at its definition.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
ACPI: button: cache hid/name/class pointers

This patch adds temporaries to cache the acpi_device_hid(),
acpi_device_name(), and acpi_device_class() pointers so we
don't have to clutter the code with so many uses of those
interfaces.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
ACPI: button: remove button->device pointer

We no longer need a pointer from struct acpi_button back to the
struct acpi_device.  Everywhere we used that pointer, we either
already have, or can easily get, the acpi_device pointer without
using the copy from acpi_button.  So this patch removes the
structure element.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
ACPI: button: remove control method/fixed hardware distinctions

This patch removes the driver distinction between control method (CM)
and fixed hardware (FF) buttons.  We previously needed that so we
could install either a fixed event handler or a notify handler, but
the Linux/ACPI code now handles that for us, so we don't need to
worry about it.

Note that this removes the FF/CM annotation from the "info" files
in /proc.  For example,

    /proc/acpi/button/PWRF/info:
    -type:		Power Button (FF)
    +type:		Power Button

I don't think there's anything meaningful user-space can do by
knowing whether a button is a control method or a fixed hardware
button, so nobody should be looking at the FF/CM.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
ACPI: Revert conflicting workaround for BIOS w/ mangled PRT entries

2f894ef9c8b36a35d80709bedca276d2fc691941
in Linux-2.6.21 worked around BIOS with mangled _PRT entries:
http://bugzilla.kernel.org/show_bug.cgi?id=6859

d0e184abc5983281ef189db2c759d65d56eb1b80
worked around the same issue via ACPICA, and shipped in 2.6.27.

Unfortunately the two workarounds conflict:
http://bugzilla.kernel.org/show_bug.cgi?id=12270

So revert the Linux specific one.

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
ACPI video: handle indexed _BQC correctly

In the current code, for a box with an indexed _BQC method, we
1. get the current brightness level by evaluating _BQC
2. set the value gotten in step 1 to _BCM
3. get the current brightness level again
4. set the _BQC_use_index flag if the results gotten
   in step 1 and in step 3 don't equal.

But this logic doesn't work actually, because the _BQC_use_index
is not set when ﻿acpi_video_device_lcd_set_level is invoked.
This results in a failure in step 2.
http://bugzilla.kernel.org/show_bug.cgi?id=12249#c83

Now, we set the _BQC_use_index flag after invoking _BQC for the first
time. And reevaluate the _BQC to get the correct brightness level.

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
ext4: really print the find_group_flex fallback warning only once

Missing braces caused the warning to print more than once.

Signed-Off-By: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
jbd2: use SWRITE_SYNC_PLUG when writing synchronous revoke records

The revoke records must be written using the same way as the rest of
the blocks during the commit process; that is, either marked as
synchronous writes or as asynchornous writes.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
x86, irq: Remove IRQ_DISABLED check in process context IRQ move

As discussed in the thread here:

  http://marc.info/?l=linux-kernel&m=123964468521142&w=2

Eric W. Biederman observed:

> It looks like some additional bugs have slipped in since last I looked.
>
> set_irq_affinity does this:
> ifdef CONFIG_GENERIC_PENDING_IRQ
>        if (desc->status & IRQ_MOVE_PCNTXT || desc->status & IRQ_DISABLED) {
>                cpumask_copy(desc->affinity, cpumask);
>                desc->chip->set_affinity(irq, cpumask);
>        } else {
>                desc->status |= IRQ_MOVE_PENDING;
>                cpumask_copy(desc->pending_mask, cpumask);
>        }
> #else
>
> That IRQ_DISABLED case is a software state and as such it has nothing to
> do with how safe it is to move an irq in process context.

[...]

>
> The only reason we migrate MSIs in interrupt context today is that there
> wasn't infrastructure for support migration both in interrupt context
> and outside of it.

Yes. The idea here was to force the MSI migration to happen in process
context. One of the patches in the series did

        disable_irq(dev->irq);
        irq_set_affinity(dev->irq, cpumask_of(dev->cpu));
        enable_irq(dev->irq);

with the above patch adding irq/manage code check for interrupt disabled
and moving the interrupt in process context.

IIRC, there was no IRQ_MOVE_PCNTXT when we were developing this HPET
code and we ended up having this ugly hack. IRQ_MOVE_PCNTXT was there
when we eventually submitted the patch upstream. But, looks like I did a
blind rebasing instead of using IRQ_MOVE_PCNTXT in hpet MSI code.

Below patch fixes this. i.e., revert commit 932775a4ab622e3c99bd59f14cc
and add PCNTXT to HPET MSI setup. Also removes copying of desc->affinity
in generic code as set_affinity routines are doing it internally.

Reported-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "Li Shaohua" <shaohua.li@intel.com>
Cc: Gary Hade <garyhade@us.ibm.com>
Cc: "lcm@us.ibm.com" <lcm@us.ibm.com>
Cc: suresh.b.siddha@intel.com
LKML-Reference: <20090413222058.GB8211@linux-os.sc.intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
jbd: use SWRITE_SYNC_PLUG when writing synchronous revoke records

The revoke records must be written using the same way as the rest of
the blocks during the commit process; that is, either marked as
synchronous writes or as asynchornous writes.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
[ARM] pxa/magician: remove un-necessary #include of pxa-regs.h and hardware.h

Signed-off-by: Eric Miao <eric.miao@marvell.com>
Cc: Philipp Zabel <philipp.zabel@gmail.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
[ARM] pxa: merge AC97 platform data structures

Currently there are two possible platform datas for the PXA AC97 driver:
one supported by the generic AC97 driver only which provides callbacks
to allow board-specific configuration at stream startup and teardown,
and another for pxa2xx-ac97-lib which allows configuration of the reset
GPIO for PXA2xx CPUs.

Obviously this won't actually work when using the generic AC97 driver
since the drivers will attempt to parse the platform data in both
formats. Fix this by merging the two structures.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: Eric Miao <eric.miao@marvell.com>
[ARM] pxa/mioa701: use GPIO95 as AC97 reset line

MioA701 board's GPIO95 is the AC97 line. The other GPIO113
is not connected to the sound chip, but to the GSM chip as a
wakeup line.

It happens that when the pxa2xx_ac97 driver reconfigures the
gpio as an "out gpio" for AC97 reset (bug workaround), it
hangs the GSM chip.

As AC97 platform data now enables to specify the AC97 reset
line, use it.

Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Eric Miao <eric.miao@marvell.com>
netfilter: nf_log regression fix

commit ca735b3aaa945626ba65a3e51145bfe4ecd9e222
'netfilter: use a linked list of loggers'
introduced an array of list_head in "struct nf_logger", but
forgot to initialize it in nf_log_register(). This resulted
in oops when calling nf_log_unregister() at module unload time.

Reported-and-tested-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Acked-by: Eric Leblond <eric@inl.fr>
Signed-off-by: Patrick McHardy <kaber@trash.net>
netfilter: nf_conntrack: fix crash when unloading helpers

Commit ea781f197d (netfilter: nf_conntrack: use SLAB_DESTROY_BY_RCU and)
get rid of call_rcu() was missing one conversion to the hlist_nulls
functions, causing a crash when unloading conntrack helper modules.

Reported-and-tested-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl>
Signed-off-by: Patrick McHardy <kaber@trash.net>
rtc: rtc-sh: clock framework support.

This adds clock framework support to the rtc-sh driver. With this in
place, platforms can default to leaving the clock disabled rather than
placing it in the always enabled state.

Signed-off-by: Paul Mundt <lethal@linux-sh.org>
sh: sh7722: Don't default enable the RTC clock.

rtc-sh takes care of this now, so no need to have this always enabled.

Signed-off-by: Paul Mundt <lethal@linux-sh.org>
sh: sh7723: Don't default enable the RTC clock.

rtc-sh takes care of this now, so no need to have this always enabled.

Signed-off-by: Paul Mundt <lethal@linux-sh.org>