If a device supports #PME and can generate PME events from D0, we may see
superfluous events before a driver is loaded (drivers should only enable PME as
needed), preventing suspend from working if the corresponding GPE was enabled.

Likewise, if the ACPI device has the _PRW object, the _PSW/_DSW object will be
called in order to disable the wakeup functionality. But when it is allowed to
wake up the sleeping state, OSPM will enable it again.

So we should disable PME in the course of scanning PCI devices and enable it
again only when PME events are actually required to be generated from the
requested PCI state (for example, D3_hot or D3_cold).  It is also safe to
disable PME again when the PME is disabled for the PCI devices.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NLi Shaohua <shaohua.li@intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Some quirks should be called with interrupt disabled, we can't directly
call them in .resume_early. Also the patch introduces
pci_fixup_resume_early and pci_fixup_suspend, which matches current
device core callbacks (.suspend/.resume_early).

TBD: Somebody knows why we need quirk resume should double check if a
quirk should be called in resume or resume_early. I changed some per my
understanding, but can't make sure I fixed all.
Signed-off-by: NShaohua Li <shaohua.li@intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Signed-off-by: NRobert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

This patch makes the needlessly global {pciehp,shpchp}_slot_with_bus
static.
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Commit 54d29ad3 (Power Supply: fix race
in device_create) introduced a race in power_supply_uevent. Previously it
checked that power_supply is available by checking for dev->driver_data.
But now dev->driver_data is set before power_supply->dev is initialised.
Signed-off-by: NDmitry Baryshkov <dbaryshkov@gmail.com>
Signed-off-by: NAnton Vorontsov <cbouatmailru@gmail.com>

Format string bug.  Not exploitable, as this is only writable by root,
but worth fixing all the same.
Spotted-by: NIlja van Sprundel <ilja@netric.org>
Signed-off-by: NDave Jones <davej@redhat.com>

In 2.6.26, we added some support for send with invalidate work
requests, including a device capability flag to indicate whether a
device supports such requests.  However, the support was incomplete:
the completion structure was not extended with a field for the key
contained in incoming send with invalidate requests.

Full support for memory management extensions (send with invalidate,
local invalidate, fast register through a send queue, etc) is planned
for 2.6.27.  Since send with invalidate is not very useful by itself,
just remove the IB_DEVICE_SEND_W_INV bit before the 2.6.26 final
release; we will add an IB_DEVICE_MEM_MGT_EXTENSIONS bit in 2.6.27,
which makes things simpler for applications, since they will not have
quite as confusing an array of fine-grained bits to check.
Signed-off-by: NRoland Dreier <rolandd@cisco.com>

R8A66597 is similar to SH7723 USB 2.0 Host/Function module.
In addition, the USB of SH7366 is compatible with SH7723.
It can support SH7723 USB host by changing Kconfig.
Signed-off-by: NYoshihiro Shimoda <shimoda.yoshihiro@renesas.com>
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Now that walk_memory_resource() is available regardless of
MEMORY_HOTPLUG's setting, this dependency is not needed.
Signed-off-by: NNathan Lynch <ntl@pobox.com>
Acked-by: NJeff Garzik <jeff@garzik.org>
Acked-by: NYasunori Goto <y-goto@jp.fujitsu.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

This is the patch that follows Linus's modification about set_ldisc.
Graf has built and tested it on BF537 using Linus's git Tree.
Signed-off-by: NGraf Yang <graf.yang@analog.com>
Signed-off-by: NBryan Wu <cooloney@kernel.org>

On a 64-bit architecture, if ib_umem_get() is called with a size value
that is so big that npages is negative when cast to int, then the
length of the page list passed to get_user_pages(), namely

	min_t(int, npages, PAGE_SIZE / sizeof (struct page *))

will be negative, and get_user_pages() will immediately return 0 (at
least since 900cf086, "Be more robust about bad arguments in
get_user_pages()").  This leads to an infinite loop in ib_umem_get(),
since the code boils down to:

	while (npages) {
		ret = get_user_pages(...);
		npages -= ret;
	}

Fix this by taking the minimum as unsigned longs, so that the value of
npages is never truncated.

The impact of this bug isn't too severe, since the value of npages is
checked against RLIMIT_MEMLOCK, so a process would need to have an
astronomical limit or have CAP_IPC_LOCK to be able to trigger this,
and such a process could already cause lots of mischief.  But it does
let buggy userspace code cause a kernel lock-up; for example I hit
this with code that passes a negative value into a memory registartion
function where it is promoted to a huge u64 value.

Cc: <stable@kernel.org>
Signed-off-by: NRoland Dreier <rolandd@cisco.com>

Packet sending is driven by two flags, tx_ready and tx_queued.
It was possible, that there were queued data for sending and
hardware was flagged as blocked but in fact it was not.

The tx_queued was indicator but should be really a counter else
first fragmented packet resets tx_queued flag, but there may be
pending packets which do not get sent.

New semantics:
tx_ready - set, if hw is ready to send packet, no packet is being
           transferred right now
           set the flag right at the place where data are copied
           into hw memory and not earlier without checking if it
           was succesful
tx_queued - count of enqueued packets, including fragments
Tested-by: NMichal Rokos <michal.rokos@gmail.com>
Signed-off-by: NDavid Sterba <dsterba@suse.cz>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Adds DMI system identifier for ThinkPad T61.

Originally written by Klaus S. Madsen.

Taken from http://launchpadlibrarian.net/10864950/hdaps-t61.patchSigned-off-by: NTim Gardner <tim.gardner@canonical.com>
Signed-off-by: Nmaximilian attems <max@stro.at>
Cc: Klaus S. Madsen <ubuntu@hjernemadsen.org>
Cc: Mark M. Hoffman <mhoffman@lightlink.com>
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This hooks up the platform-specific [gs]et_rtc_time functions so that
kernels using CONFIG_RTC_CLASS have RTC support on most PowerPC platforms.

A new driver, and one which we've been shipping in Fedora for a while
already, since otherwise RTC support breaks.

[akpm@linux-foundation.org: fix Kconfig indenting]
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
Acked-by: NAlessandro Zummo <a.zummo@towertech.it>
Acked-by: NDavid Brownell <david-b@pacbell.net>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Frame buffer and mode setting drivers can be built as modules,
so fb_mode_option needs to be exported to support these.

Prevents this error:

  ERROR: "fb_mode_option" [drivers/ps3/ps3av_mod.ko] undefined!
Signed-off-by: NGeoff Levand <geoffrey.levand@am.sony.com>
Acked-by: NGeert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

I made a change to u-boot that used the FP (Fractional Part) field of BRGR
to achieve more accurate baud rate generation.  Unfortunately, the
atmel_serial driver looks at the whole BRGR register when trying to detect
the baud rate that the port is currently running at, so setting FP to a
nonzero value breaks the baud rate detection.

I'll sit on the u-boot patch for a while longer, but this is clearly a
bug in the atmel_serial driver which should be fixed.
Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
Acked-by: NAndrew Victor <linux@maxim.org.za>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Lockdep says we can't take tasklist lock or sighand lock inside ctrl_lock.
Signed-off-by: NNick Piggin <npiggin@suse.de>
Acked-by: NAlan Cox <alan@redhat.com>
Cc: Oleg Nesterov <oleg@tv-sign.ru>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Original report: """I used to force my console to black-on-white by the
command `setterm -inversescreen on`.  In 2.6.26-rc4, I get lots of black
background characters."""

Another addendum to commit c9e587ab.  This was previously missed out since
I was not aware of what vc_decscnm was for.
Signed-off-by: NJan Engelhardt <jengelh@medozas.de>
Reported-by: <thunder7@xs4all.nl>
Tested-by: <thunder7@xs4all.nl>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If cpu specific cpufreq driver(i.e.  longrun) has "setpolicy" function,
governor object isn't set into cpufreq_policy object at "__cpufreq_set_policy"
function in driver/cpufreq/cpufreq.c .

This causes a null object access at "store_scaling_setspeed" and
"show_scaling_setspeed" function in driver/cpufreq/cpufreq.c when reading or
writing through /sys interface (ex.  cat
/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed)

Addresses:
	http://bugzilla.kernel.org/show_bug.cgi?id=10654
	https://bugzilla.redhat.com/show_bug.cgi?id=443354Signed-off-by: NCHIKAMA Masaki <masaki.chikama@gmail.com>
Cc: Dave Jones <davej@codemonkey.org.uk>
Cc: Chuck Ebbert <cebbert@redhat.com>
Acked-by: NDominik Brodowski <linux@dominikbrodowski.net>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The interlaced and double line mode bits should not be copied to new
console when the console is switched.  Otherwise, the new console may be
set to incorrect refresh rate.

Also, the x and y offsets does not need to be copied.
Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Change the name of the device from "rtc-ds1374" to just "ds1374", to match
what all other RTC drivers do.  I seem to remember that this name was
chosen to avoid possible confusion with an older ds1374 driver, but that
driver was removed 3 months ago.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NAlessandro Zummo <a.zummo@towertech.it>
Acked-by: NKumar Gala <galak@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Although if people have questions about ARCnet, perhaps it's _better_
for them to be mailing dwmw2@cam.ac.uk about it...
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NDan Williams <dcbw@redhat.com>
Cc: Jonathan Woithe <jwoithe@physics.adelaide.edu.au>
Cc: Len Brown <len.brown@intel.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

As commit 6089093e ("ip2: fix crashes on
load/unload") fixed the ip2 crashes on load/unload by making ip2/ip2main
one module (ip2), Kconfig shouldn't mention a now non-existing module.
Signed-off-by: NRoland.Kletzing <devzero@web.de>
Acked-by: NAlan Cox <alan@redhat.com>
Cc: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Cc: Matt Domsch <Matt_Domsch@dell.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Some drivers are using too generic "serial" name for driver_name, this
might cause issues, like this:

Freescale QUICC Engine UART device driver
proc_dir_entry 'serial' already registered
Call Trace:
[cf82de50] [c0007f7c] show_stack+0x4c/0x1ac (unreliable)
[cf82de90] [c00b03fc] proc_register+0xfc/0x1ac
[cf82dec0] [c00b05c8] create_proc_entry+0x60/0xac
[cf82dee0] [c00b23dc] proc_tty_register_driver+0x60/0x98
[cf82def0] [c016dbd8] tty_register_driver+0x1b4/0x228
[cf82df20] [c0184d70] uart_register_driver+0x144/0x194
[cf82df40] [c030a378] ucc_uart_init+0x2c/0x94
[cf82df50] [c02f21a0] kernel_init+0x98/0x27c
[cf82dff0] [c000fa74] kernel_thread+0x44/0x60

^^ The board is using ucc_uart.c and 8250.c, both registered as
   "serial".

This patch fixes two drivers that are using "serial" for driver_name and
not "ttyS" for dev_name.  Drivers that are using "ttyS" for dev_name, will
conflict anyway, so we don't bother with these.
Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: NAlan Cox <alan@redhat.com>
Acked-By: NTimur Tabi <timur@freescale.com>
Acked-by: NMaciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The temporary structure for calculated CVT mode is not initialized.  Few
fields have only bits or-ed or and-ed so they may be left in incorrect
(random) state.

Testing of the tridentfb seems like a good exercise for the fbdev layer.
Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If a block is computed (rather than read) then a check/repair operation
may be lead to believe that the data on disk is correct, when infact it
isn't.  So only compute blocks for failed devices.

This issue has been around since at least 2.6.12, but has become harder to
hit in recent kernels since most reads bypass the cache.

echo repair > /sys/block/mdN/md/sync_action will set the parity blocks to the
correct state.

Cc: <stable@kernel.org>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NNeil Brown <neilb@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If an array was created with --assume-clean we will oops when trying to
set ->resync_max.

Fix this by initializing ->recovery_wait in mddev_find.

Cc: <stable@kernel.org>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NNeil Brown <neilb@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

During the initial array synchronization process there is a window between
when a prexor operation is scheduled to a specific stripe and when it
completes for a sync_request to be scheduled to the same stripe.  When
this happens the prexor completes and the stripe is unconditionally marked
"insync", effectively canceling the sync_request for the stripe.  Prior to
2.6.23 this was not a problem because the prexor operation was done under
sh->lock.  The effect in older kernels being that the prexor would still
erroneously mark the stripe "insync", but sync_request would be held off
and re-mark the stripe as "!in_sync".

Change the write completion logic to not mark the stripe "in_sync" if a
prexor was performed.  The effect of the change is to sometimes not set
STRIPE_INSYNC.  The worst this can do is cause the resync to stall waiting
for STRIPE_INSYNC to be set.  If this were happening, then STRIPE_SYNCING
would be set and handle_issuing_new_read_requests would cause all
available blocks to eventually be read, at which point prexor would never
be used on that stripe any more and STRIPE_INSYNC would eventually be set.

echo repair > /sys/block/mdN/md/sync_action will correct arrays that may
have lost this race.

Cc: <stable@kernel.org>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NNeil Brown <neilb@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This addresses other oopsing paths in "spidev" by changing how it manages
refcounting.  It decouples the lifecycle of the per-device data from the
class device (not just the spi device):

  - Use class_{create,destroy} not class_{register,unregister}.
  - Use device_{create,destroy} not device_{register,unregister}.
  - Free the per-device data only when TWO conditions are true:
      * Driver is unbound from underlying SPI device, and
      * Device is no longer open (new)

Also, spi_{get,set}_drvdata not dev_{get,set}_drvdata for simpler code.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Sebastian Siewior <bigeasy@tglx.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

SM/SMA traps received by the ipath driver should be forwarded to the
SM if it is running on the host.  The ib_ipath driver was incorrectly
replying with "bad method."
Signed-off-by: NRalph Campbell <ralph.campbell@qlogic.com>
Signed-off-by: NRoland Dreier <rolandd@cisco.com>

Signed-off-by: NJoachim Fenkes <fenkes@de.ibm.com>
Signed-off-by: NRoland Dreier <rolandd@cisco.com>

fix a mutex release bug in function m25p80_write.
Signed-off-by: NChen Gong <g.chen@freescale.com>
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>

Fairly simple. "dev_use" was being allocated as a zero length array
because of bad math on 64-bit systems, causing a crash in
find_first_zero_bit(). One-liner follows:
Signed-off-by: NBen Collins <ben.collins@canonical.com>
Acked-by: NPierre Ossman <drzeus@drzeus.cx>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Alias brd to rd in the hope of helping legacy users. Suggested by Jan.
Signed-off-by: NNick Piggin <npiggin@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

We don't need to reserve "unset" resources.  Trying to reserve
them results in messages like this, which are ugly but harmless:

    system 00:08: iomem range 0x0-0x0 could not be reserved

Future PNP patches will remove use of IORESOURCE_UNSET, but
we still need it for now.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix G5 SATA irq 18: nobody cared, reported on -rc5 by Olaf Hering:
fixlet to a57c1bad libata-sff:
Fix oops reported in kerneloops.org for pnp devices with no ctl
Signed-off-by: NHugh Dickins <hugh@veritas.com>
Acked-by: NAlan Cox <alan@lxorguk.ukuu.org.uk>
Tested-by: NOlaf Hering <olaf@aepfle.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NMichael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Check that tda827x_config is defined before attempting to use it.
Signed-off-by: NSigmund Augdal <sigmund@snap.tv>
Signed-off-by: NMichael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>