The wakeup.run_wake_count ACPI device field is only used by the PCI
runtime PM code to "protect" devices from being prepared for
generating wakeup signals more than once in a row.  However, it
really doesn't provide any protection, because (1) all of the
functions it is supposed to protect use their own reference counters
effectively ensuring that the device will be set up for generating
wakeup signals just once and (2) the PCI runtime PM code uses
wakeup.run_wake_count in a racy way, since nothing prevents
acpi_dev_run_wake() from being called concurrently from two different
threads for the same device.

Remove the wakeup.run_wake_count ACPI device field which is
unnecessary, confusing and used in a wrong way.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

This reverts commit 556ea928.

Jeff Chua reports that it can cause some bluetooth devices (he mentions
an Bluetooth Intermec scanner) to just stop responding after a while
with messages like

  [ 4533.361959] btusb 8-1:1.0: no reset_resume for driver btusb?
  [ 4533.361964] btusb 8-1:1.1: no reset_resume for driver btusb?

from the kernel. See also

  https://bugzilla.kernel.org/show_bug.cgi?id=26182

for other reports.
Reported-by: NJeff Chua <jeff.chua.linux@gmail.com>
Reported-by: NAndrew Meakovski <meako@bigmir.net>
Reported-by: NJim Faulkner <jfaulkne@ccs.neu.edu>
Acked-by: NGreg KH <gregkh@suse.de>
Acked-by: NMatthew Garrett <mjg@redhat.com>
Acked-by: NGustavo F. Padovan <padovan@profusion.mobi>
Cc: stable@kernel.org (for 2.6.37)
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The device is very similar to (0x0fe6, 0x8101),
And works well with dm9601 driver.
Signed-off-by: NShahar Havivi <shaharh@redhat.com>
Acked-by: NPeter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

- fix the RTL8111DP turn off the power when DASH is enabled.
- RTL_GIGA_MAC_VER_27 must wait for tx finish before reset.
Signed-off-by: NHayes Wang <hayeswang@realtek.com>
Acked-by: NFrancois Romieu <romieu@fr.zoreil.com>

Adjust and remove certain settings of RTL8102E which are for previous chips.
Signed-off-by: NHayes Wang <hayeswang@realtek.com>
Acked-off-by: NFrancois Romieu <romieu@fr.zoreil.com>

It results in the wrong point address and influences RTL8168DP.
Signed-off-by: NHayes Wang <hayeswang@realtek.com>
Acked-by: NFrancois Romieu <romieu@fr.zoreil.com>

DM9000 revision B needs 1 ms delay after PHY power-on.
PHY must be powered on by writing 0 into register DM9000_GPR before
all other settings will change (see Davicom spec and example code).

Remember, that register DM9000_GPR was not changed by reset sequence.

Without this fix the FIFO is out of sync and sends wrong data after
sequence of "ifconfig ethX down ; ifconfig ethX up".
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The spin_lock should hold before reading register.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit 8ee294cd converted serio
subsystem event handling from using a dedicated thread to using
common workqueue. Unfortunately, this regressed our boot times,
due to the fact that serio jobs take long time to execute. While
the new concurrency managed workqueue code manages long-playing
works just fine and schedules additional workers as needed, such
works wreck havoc among remaining users of flush_scheduled_work().

To solve this problem let's move serio/gameport works from system_wq
to system_long_wq which nobody tries to flush.
Reported-and-tested-by: NHernando Torque <pantherchen@versanet.de>
Acked-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

Since Synaptics technical writers department is a bit slow releasing updated
Synaptics interface guide, let's add some new bits (with their blessing)
to the code so that they don't get lost.
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

The module forgot to sometimes unregister some resources.

This fixes Bug #22882.

[Patch updated to 2.6.38-rc3 by Randy Dunlap.]
Tested-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NFlorian Mickler <florian@mickler.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Fixup the whitespace error noticed in cb527edeSigned-off-by: NBen Dooks <ben-linux@fluff.org>

This errata occurs when the ARDY interrupt generation is enabled.
At the begining of every new transaction the ARDY interrupt is cleared.

On continuous i2c transactions where after clearing the ARDY bit from
I2C_STAT register (clearing the interrupt), the IRQ line is reasserted and the
I2C_STAT[ARDY] bit set again on 1. In fact, the ARDY status bit is not cleared
at the write access to I2C_STAT[ARDY] and only the IRQ line is deasserted and
then reasserted. This is not captured in the usual errata documents.

The workaround is to have a double clear of ARDY status in irq handler.
Signed-off-by: NRichard woodruff <r-woodruff2@ti.com>
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

fix the build break when !CONFIG_SUSPEND

drivers/i2c/busses/i2c-omap.c:1173: error: lvalue required as unary '&' operand
make[3]: *** [drivers/i2c/busses/i2c-omap.o] Error 1
make[2]: *** [drivers/i2c/busses] Error 2
make[1]: *** [drivers/i2c] Error 2
make: *** [drivers] Error 2
Signed-off-by: NBalaji T K <balajitk@ti.com>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Some userspaces can emit a whole packet without disabling AA resolve
by the looks of it, so we have to deal with them.
Signed-off-by: NDave Airlie <airlied@redhat.com>
Tested-by: NJorg Otte <jrg.otte@googlemail.com>

r100_gpu_init() was dropped in 90aca4d2 ("drm/radeon/kms: simplify &
improve GPU reset V2") but here it was only commented out.
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Testing showed the current code can already handle doublescan
video modes just fine. A trivial tweak makes it work for interlaced
scanout as well.

Tested and shown to be precise on Radeon rv530, r600 and
Intel 945-GME.
Signed-off-by: NMario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Documentation/atomic_ops.txt tells us that there are memory
barriers optimized for atomic_inc and other atomic_t ops.

Use these instead of smp_wmb(), and also to make the required
memory barriers around vblank counter increments more explicit.
Signed-off-by: NMario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Use of abs() wrongly wrapped diff_ns to 32 bit, which gives a 1/4000
probability of a missed vblank increment at each vblank irq reenable
if the kms driver doesn't support high precision vblank timestamping.
Not a big deal in practice, but let's make it nice.
Signed-off-by: NMario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

this aligns the height of the fb allocation so it doesn't trip
over the size checks later when we use this from userspace to
copy the buffer at X start.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This reverts commit a6f97617.

Remove this commit as it is no longer necessary. The relevant bugs
were fixed properly in:
drm/radeon/kms: hopefully fix pll issues for real (v3)
5b40ddf8
drm/radeon/kms: add missing frac fb div flag for dce4+
9f4283f4

This commit also broke certain ~5 Mhz modes on old arcade monitors,
so reverting this commit fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=29502Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

When runtime PM is enabled, each OMAP i2c device is suspended after
each i2c xfer.  However, there are two cases when the static suspend
methods must be used to ensure the devices are suspended:

1) runtime PM is disabled, either at compile time or dynamically
    via /sys/devices/.../power/control.
2) an i2c client driver uses i2c during it's suspend callback, thus
   leaving the i2c driver active (NOTE: runtime suspend transitions are
   disabled during system suspend, so i2c activity during system
   suspend will runtime resume the device, but not runtime (re)suspend it.)

Since the actual work to suspend the device is handled by the
subsytem, call the bus methods to take care of it.

NOTE: This takes care of a known suspend problem on OMAP3 where the
TWL RTC driver does i2c xfers during its suspend path leaving the i2c
driver in an active state (since runtime suspend transistions are
disabled.)
Signed-off-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Use strlcpy instead of strncpy.
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
Cc: Linus Walleij <linus.walleij@stericsson.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

drivers/net/sfc/ethtool.c: In function ‘efx_ethtool_self_test’:
drivers/net/sfc/ethtool.c:613: warning: the frame size of 1200 bytes
is larger than 1024 bytes
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Acked-by: NBen Hutchings <bhutchings@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The current code does not follow Intel documentation: It misses some things
and does other, undocumented things. This causes wrong backlight values in
certain conditions. Instead of adding tricky code handling badly documented
and rare corner cases, don't handle combination mode specially at all. This
way PCI_LBPC is never touched and weird things shouldn't happen.

If combination mode is enabled, then the only downside is that changing the
brightness has a greater granularity (the LBPC value), but LBPC is at most
254 and the maximum is in the thousands, so this is no real functional loss.

A potential problem with not handling combined mode is that a brightness of
max * PCI_LBPC is not bright enough. However, this is very unlikely because
from the documentation LBPC seems to act as a scaling factor and doesn't look
like it's supposed to be changed after boot. The value at boot should always
result in a bright enough screen.

IMPORTANT: However, although usually the above is true, it may not be when
people ran an older (2.6.37) kernel which messed up the LBPC register, and
they are unlucky enough to have a BIOS that saves and restores the LBPC value.
Then a good kernel may seem to not work: Max brightness isn't bright enough.
If this happens people should boot back into the old kernel, set brightness
to the maximum, and then reboot. After that everything should be fine.

For more information see the below links. This fixes bugs:

  http://bugzilla.kernel.org/show_bug.cgi?id=23472
  http://bugzilla.kernel.org/show_bug.cgi?id=25072Signed-off-by: NIndan Zupancic <indan@nul.nu>
Tested-by: NAlex Riesen <raa.lkml@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

It is found on Dell Inspiron 1018 that the firmware reports that the hardware
killswitch is not supported. This makes the rfkill key not functional.

This patch forces the driver to toggle the firmware rfkill status in the case
that the hardware killswitch is indicated as unsupported by the firmware.
Signed-off-by: NKeng-Yu Lin <keng-yu.lin@canonical.com>
Tested-by: NAlessio Igor Bogani <abogani@texware.it>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Some thinkpad hotkeys report key codes like KEY_FN_F8 when something
like KEY_VOLUMEDOWN is desired. Always provide the scan codes in
addition to the key codes to assist with debugging these issues. Also
send the scan code before the key code to match what other drivers do,
as some userspace utilities expect this ordering.
Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

6AF4F258-B401-42fd-BE91-3D4AC2D7C0D3 needs to be
6AF4F258-B401-42FD-BE91-3D4AC2D7C0D3 to match the hardware alias.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Acked-by: NCarlos Corbacho <carlos@strangeworlds.co.uk>
Cc: stable@kernel.org

Most platform/x86 drivers that use INPUT_SPARSEKMAP also depend on INPUT,
so do the same for ideapad-laptop.  This fixes a kconfig warning and
subsequent build errors when CONFIG_INPUT is disabled.

warning: (ACER_WMI && ASUS_LAPTOP && DELL_WMI && HP_WMI && PANASONIC_LAPTOP && IDEAPAD_LAPTOP && EEEPC_LAPTOP && EEEPC_WMI && MSI_WMI && TOPSTAR_LAPTOP && ACPI_TOSHIBA) selects INPUT_SPARSEKMAP which has unmet direct dependencies (!S390 && INPUT)

ERROR: "input_free_device" [drivers/platform/x86/ideapad-laptop.ko] undefined!
ERROR: "input_register_device" [drivers/platform/x86/ideapad-laptop.ko] undefined!
ERROR: "sparse_keymap_setup" [drivers/platform/x86/ideapad-laptop.ko] undefined!
ERROR: "input_allocate_device" [drivers/platform/x86/ideapad-laptop.ko] undefined!
ERROR: "input_unregister_device" [drivers/platform/x86/ideapad-laptop.ko] undefined!
ERROR: "sparse_keymap_free" [drivers/platform/x86/ideapad-laptop.ko] undefined!
ERROR: "sparse_keymap_report_event" [drivers/platform/x86/ideapad-laptop.ko] undefined!
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: platform-driver-x86@vger.kernel.org
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Don't allow everybody to write to hardware registers.
Signed-off-by: NVasiliy Kulikov <segoon@openwall.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Don't allow everybody to change ACPI settings.  The comment says that it
is done deliberatelly, however, the comment before disp_proc_write()
says that at least one of these setting is experimental.
Signed-off-by: NVasiliy Kulikov <segoon@openwall.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

Don't allow everybody to change WMI settings.
Signed-off-by: NVasiliy Kulikov <segoon@openwall.com>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>

There is no need to install a chained handler for this hardware. This
is a plain x86 IOAPIC interrupt which is handled by the core code
perfectly fine. There is nothing special about demultiplexing these
gpio interrupts which justifies a custom hack. Replace it by a plain
old interrupt handler installed with request_irq. That makes the code
agnostic about the underlying primary interrupt hardware. The overhead
for this is minimal, but it gives us the advantage of accounting,
balancing and to detect interrupt storms. gpio interrupts are not
really that performance critical.

Patch fixups from akpm
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>

Documentation/DMA-API-HOWTO.txt states:

"DMA transfers need to be synced properly in order for
the cpu and device to see the most uptodate and correct
copy of the DMA buffer."

Cc: <stable@kernel.org>
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

As reported and found by Johannes Stezenbach:
rt2800{pci,usb} do not report the Michael MIC in RXed frames, but do check
the Michael MIC in hardware. Therefore we have to report to mac80211 that the
received frame does not include the Michael MIC.

https://bugzilla.kernel.org/show_bug.cgi?id=16608Signed-off-by: NGertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Fast channel change fixes:

a) Always set OFDM timings
b) Don't re-activate PHY
c) Enable only NF calibration, not AGC

https://bugzilla.kernel.org/show_bug.cgi?id=27382Signed-off-by: NNick Kossifidis <mickflemm@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This reverts commit 9b29050f.

It has caused hibernate regressions, for example Juri Sladby's report:

  "I'm unable to hibernate 2.6.37.1 unless I rmmod tpm_tis:
   [10974.074587] Suspending console(s) (use no_console_suspend to debug)
   [10974.103073] tpm_tis 00:0c: Operation Timed out
   [10974.103089] legacy_suspend(): pnp_bus_suspend+0x0/0xa0 returns -62
   [10974.103095] PM: Device 00:0c failed to freeze: error -62"

and Rafael points out that some of the new conditionals in that commit
seem to make no sense.  This commit needs more work and testing, let's
revert it for now.
Reported-by: NNorbert Preining <preining@logic.at>
Reported-and-requested-by: NJiri Slaby <jirislaby@gmail.com>
Cc: Stefan Berger <stefanb@linux.vnet.ibm.com>
Cc: Guillaume Chazarain <guichaz@gmail.com>
Cc: Rajiv Andrade <srajiv@linux.vnet.ibm.com>
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Allow drivers to enable Zoomed Video support. Currently, this is only
used by out-of-tree drivers (L64020 DVB driver in particular).

CC: <stable@kernel.org> [for 2.6.37]
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>

Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>

After 2.6.34 changes, __pxa2xx_drv_pcmcia_probe() was replaced by
sa1111_pcmcia_add(). That unfortunately means that configure_sockets()
is not called, leading to MECR not being set properly, leading to
strange crashes.

Tested on pxa255+sa1111, I do not have lubbock board nearby. Perhaps
cleaner solution exists?
Signed-off-by: NPavel Machek <pma@sysgo.com>
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>