-tip testing found the following build failure (config attached):

drivers/built-in.o: In function `amd64_check':
amd64_edac.c:(.text+0x3e9491): undefined reference to `amd_decode_nb_mce'
drivers/built-in.o: In function `amd64_init_2nd_stage':
amd64_edac.c:(.text+0x3e9b46): undefined reference to `amd_report_gart_errors'
amd64_edac.c:(.text+0x3e9b55): undefined reference to `amd_register_ecc_decoder'
drivers/built-in.o: In function `amd64_nbea_store':
amd64_edac_dbg.c:(.text+0x3ea22e): undefined reference to `amd_decode_nb_mce'
drivers/built-in.o: In function `amd64_remove_one_instance':
amd64_edac.c:(.devexit.text+0x3eea): undefined reference to `amd_report_gart_errors'
amd64_edac.c:(.devexit.text+0x3ef6): undefined reference to `amd_unregister_ecc_decoder'

the AMD EDAC code has a dependency on CONFIG_CPU_SUP_AMD facilities. The
patch below solves the problem here.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

Due to problems at cam.org, my nico@cam.org email address is no longer
valid.  FRom now on, nico@fluxnic.net should be used instead.
Signed-off-by: NNicolas Pitre <nico@fluxnic.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This patch will fix the following problem on Yeeloong netbook with
fujitsu disk.

irq 14: nobody cared (try booting with the "irqpoll" option)
Call Trace:
[<ffffffff8020d438>] dump_stack+0x8/0x40
[<ffffffff8027ec64>] __report_bad_irq+0x58/0xe4
[<ffffffff8027ee6c>] note_interrupt+0x17c/0x23c
[<ffffffff8027f9b8>] handle_level_irq+0xcc/0x134
[<ffffffff802125b0>] mach_irq_dispatch+0xb8/0x1e0
[<ffffffff8020041c>] ret_from_irq+0x0/0x4
[<ffffffff8029e678>] free_hot_cold_page+0x224/0x2a0
[<ffffffff8026f794>] swsusp_free+0xb0/0x14c
[<ffffffff8026ec08>] hibernate+0x198/0x218
[<ffffffff8026cfa8>] state_store+0x90/0x138
[<ffffffff8032b5a4>] sysfs_write_file+0x130/0x194
[<ffffffff802c94fc>] vfs_write+0xb8/0x180
[<ffffffff802c96b8>] SyS_write+0x50/0x98
[<ffffffff80203fd8>] handle_sys+0x158/0x174

handlers:
[<ffffffff80429670>] (ide_intr+0x0/0x300)
Disabling IRQ #14

References:

1. commit 1fde02e7146d4a1bab80fd1506f9018fe71e8521 of
git://dev.lemote.com/linux_loongson.git
2. 8bc1e5aa (ide: respect quirk_drives[]
list on all controllers)
Signed-off-by: NYan Hua <yanh@lemote.com>
Signed-off-by: NWu Zhangjin <wuzhangjin@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Added Kworld DVD Maker 2
Thanks to C Western <l@c-m-w.me.uk> for reporting this board.
Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

console_print() is an old legacy interface mostly unused in the entire
kernel tree. It's best to clean up its existing use and let developers
use their own implementation of it as they feel fit.
Signed-off-by: NAnirban Sinha <asinha@zeugmasystems.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This patch reworks platform driver power management code
for at_hdmac from legacy late/early callbacks to dev_pm_ops.

The callbacks are converted for CONFIG_SUSPEND like this:
  suspend_late() -> suspend_noirq()
  resume_early() -> resume_noirq()
Signed-off-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

transition_started should be set once the preparation of devices for
a PM has started, reset before starting to resume devices. When
resuming devices, kernel calls dpm_resume_noirq then
dpm_resume_end(dpm_resume).  Thus we should reset transition_started
at dpm_resume_noirq.

This patch fixes ACPI warning when resuming from suspend/hibernate:

ACPI: \_SB_.PCI0.IDE1.PRI1.MAS1 - docking
------------[ cut here ]------------
WARNING: at drivers/base/power/main.c:87 device_pm_add+0x8b/0xcc()
Hardware name: OptiPlex 760
Device: acpi
Parentless device registered during a PM transaction

[rjw: Fixed up the changelog.]
Signed-off-by: NXiaotian Feng <dfeng@redhat.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

The kerneldoc comments in drivers/base/power/main.c are generally
outdated and some of them don't describe the functions very
accurately.  Update them and standardize the format to use spaces
instead of tabs.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NRandy Dunlap <randy.dunlap@oracle.com>
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>

Gets rid of the following warning:

Platform driver 'hp-wmi' needs updating - please use dev_pm_ops

I tested that the resume handler still works on my HP 2510p notebook.

[rjw: Fixed up the definition of hp_wmi_pm_ops.]
Signed-off-by: NFrans Pop <elendil@planet.nl>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

Gets rid of the following warning:
Platform driver 'floppy' needs updating - please use dev_pm_ops

[rjw: Fixed up the definition of floppy_pm_ops.]
Signed-off-by: NFrans Pop <elendil@planet.nl>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>

See Fam10h BKDG (31116, rev. 3.28), Table 101.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

See Fam10h BKDG (31116, rev. 3.28), Table 100.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

... according to Table 69, Fam10h BKDG (31116, rev. 3.28).
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

See Fam10h BKDG (31116, rev. 3.28), Table 95
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

Those get reported in MC0_STATUS, see Table 92, F10h BKDG (31116, rev.
3.28) for more details.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

This is the MCE error code from the MCi_STATUS banks, bits [15:0] which
describe what type of error was encountered: GART TLB, Memory or Bus
error. The semantics of those bits are identical across all MCE banks so
decode those separately, irrespectively of MCE type.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

The MCi_STATUS registers have most field definitions in common so decode
them in the general path. Do not pass ecc_type along and compute it in
__amd64_decode_bus_error instead.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

Move NB decoder along with required defines to EDAC MCE core. Add
registration routines for further decoding of the MCE info in the AMD64
EDAC module.

CC: Andi Kleen <andi@firstfloor.org>
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

* don't dump info which mcheck already does
* update to newest BKDG
* mv amd64_process_error_info -> amd64_decode_nb_mce
* shorten error struct names
* remove redundant info ptr in amd64_process_error_info
* remove unused ErrorCodeExt[19:16] (MCx_STATUS) defines
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

* mv amd64_error_info_regs -> err_regs

* remove redundant info ptr
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

This is in preparation of adding AMD-specific MCE decoding functionality
to the EDAC core. The error decoding macros originate from the AMD64
EDAC driver albeit in a simplified and cleaned up version here.

While at it, add macros to generate the error description strings and
use them in the error type decoders directly which removes a bunch of
code and makes the decoding functions much more readable. Also, fix
strings and shorten macro names.

Remove superfluous htlink_msgs.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

Use new generic_write_sync() helper instead of sync_page_range().
Acked-by: NEvgeniy Polyakov <zbr@ioremap.net>
Signed-off-by: NJan Kara <jack@suse.cz>

generic_file_aio_write_nolock() is now used only by block devices and raw
character device. Filesystems should use __generic_file_aio_write() in case
generic_file_aio_write() doesn't suit them. So rename the function to
blkdev_aio_write() and move it to fs/blockdev.c.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NJan Kara <jack@suse.cz>

Use new helper __generic_file_aio_write(). Since the fs takes care of syncing
by itself afterwards, there are no more changes needed.

CC: Evgeniy Polyakov <zbr@ioremap.net>
Signed-off-by: NJan Kara <jack@suse.cz>

As early pci resume has already restored config for host
bridge and graphics device, don't need to restore it again,
This removes an original order hack for graphics device restore.

This fixed the resume hang issue found by Alan Stern on 845G,
caused by extra config restore on graphics device.

Cc: Stable Team <stable@kernel.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@linux.ie>

Implement blk_limits_io_opt() and make blk_queue_io_opt() a wrapper
around it. DM needs this to avoid poking at the queue_limits directly.
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: NMike Snitzer <snitzer@redhat.com>
Signed-off-by: NJens Axboe <jens.axboe@oracle.com>

Currently, there is a single in_flight counter measuring the number of
requests in the request_queue. But some monitoring tools would like to
know how many read requests and write requests are in progress. Split the
current in_flight counter into two seperate counters for read and write.

This information is exported as a sysfs attribute, as changing the
currently available stat files would break the existing tools.
Signed-off-by: NNikanth Karthikesan <knikanth@suse.de>
Signed-off-by: NJens Axboe <jens.axboe@oracle.com>

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

Bruno Premont noticed that aoe throws a BUG during umount of an XFS in
2.6.31:

[ 5259.349897] aoe: bi_io_vec is NULL
[ 5259.349940] ------------[ cut here ]------------
[ 5259.349958] kernel BUG at /usr/src/linux-2.6/drivers/block/aoe/aoeblk.c:177!
[ 5259.349990] invalid opcode: 0000 [#1]

The bio in question is a barrier.  Jens Axboe suggested that such bios
need to be recognized and ended with -EOPNOTSUPP by any driver that
provides its own ->make_request_fn handler and does not handle
barriers.

In testing the changes below eliminate the BUG.

(Better would be real barrier support, something that Ed says he'll add
for later in the .32 cycle. For now, this at least gets rid of a bug
with crashing on an empty barrier. Jens)
Signed-off-by: NEd L. Cashin <ecashin@coraid.com>
Signed-off-by: NJens Axboe <jens.axboe@oracle.com>

Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

This one does not have anything useful in DMI either so again
we need to use:

    force=1 keymap=aopen1557
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

There are some extra parenthesis at the clauses, and some switch() tests
for boards that don't have i2c ir. Remove those extra code.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Currently, the logic to load ir i2c ancillary module is broken. It is
associated to Hauppauge devices with IR flag on their eeprom, no matter
if the device uses i2c or em28xx direct IR support. That's wrong.

Instead, add a flag to the boards that use i2c IR chips and load the
module only for those devices and if ir is not disabled.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

ir-kbd-i2c's ir_probe() function can be called much later (i.e. at
ir-kbd-i2c module load), than the lifetime of a struct IR_i2c_init_data
allocated off of the stack in cx18_i2c_new_ir() at registration time.
Make sure we pass a pointer to a persistent IR_i2c_init_data object at
i2c registration time.

Thanks to Brian Rogers, Dustin Mitchell, Andy Walls and Jean Delvare to
rise this question.

Before this patch, if ir-kbd-i2c were probed after SAA7134, trash data
were used.

Compile tested only, but the patch is identical to em28xx one. So, it
should work properly.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

ir-kbd-i2c's ir_probe() function can be called much later (i.e. at ir-kbd-i2c
module load), than the lifetime of a struct IR_i2c_init_data allocated off of
the stack in cx18_i2c_new_ir() at registration time.  Make sure we pass
a pointer to a persistent IR_i2c_init_data object at i2c registration time.

Thanks to Brian Rogers for pointing out a solution, and Dustin Mitchell for
testing against a 2.6.30 kernel.
Reported-by: NDustin Mitchell <soxslayer@gmail.com>
Reported-by: NBrian Rogers <brian@xyzw.org>
Tested-by: NDustin Mitchell <soxslayer@gmail.com>
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

ir-kbd-i2c's ir_probe() function can be called much later (i.e. at
ir-kbd-i2c module load), than the lifetime of a struct IR_i2c_init_data
allocated off of the stack in cx18_i2c_new_ir() at registration time.
Make sure we pass a pointer to a persistent IR_i2c_init_data object at
i2c registration time.

Thanks to Brian Rogers, Dustin Mitchell, Andy Walls and Jean Delvare to
rise this question.

Before this patch, if ir-kbd-i2c were probed after em28xx, trash data
were used. After the patch, no matter what order, it is properly
reported as tested by me:

input: i2c IR (i2c IR (EM2840 Hauppaug as /class/input/input10
ir-kbd-i2c: i2c IR (i2c IR (EM2840 Hauppaug detected at i2c-4/4-0030/ir0 [em28xx #0]
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NBrian Johnson <brijohn@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Using the MT9M111's IFP to handle exposure/gain gives better results.
Signed-off-by: NBrian Johnson <brijohn@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>