Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

 a) every bitwise declaration will give a unique type; use typedefs.

 b) no need to bother with the stuff pointed to by iomem pointers,
    unless it's accessed directly.  noderef will force us to use helpers
    anyway.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

NB: remaining endianness warnings in the file are, AFAICS, real bugs.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

aka if you see a force-cast, be very suspicious...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Acked-and-tested-by: NFrank Seidel <fseidel@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Acked-by: NHarvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Acked-by: NHarvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This patch fixes bits of the DRM so to make the radeon DRI work on
non-cache coherent PCI DMA variants of the PowerPC processors.

It moves the few places that needs change to wrappers to that
other architectures with similar issues can easily add their
own changes to those wrappers, at least until we have more useful
generic kernel API.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDave Airlie <airlied@linux.ie>

drivers/char/drm/radeon_mem.c:91:23: warning: Using plain integer as NULL pointer
drivers/char/drm/radeon_mem.c:116:28: warning: Using plain integer as NULL pointer
drivers/char/drm/radeon_mem.c:124:28: warning: Using plain integer as NULL pointer
drivers/char/drm/radeon_mem.c:177:26: warning: Using plain integer as NULL pointer
drivers/char/drm/radeon_mem.c:177:53: warning: Using plain integer as NULL pointer
Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDave Airlie <airlied@linux.ie>

From Kernel BZ 10289 - not sure why anyone would boot an intel with no agp
but it shouldn't crash.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This interface was originally designed wrong, confusing bit-fields and
integers, major brown paper bag going back many years...

But userspace only ever used 4 values so fix the interface for new
users and fix the implementation to deal with the 4 values userspace
has ever emitted (0x1, 0x2, 0x3, 0x6).
Signed-off-by: NDave Airlie <airlied@redhat.com>

This reverts commit b140b99c.

[ conflict in drivers/ide/ide-probe.c fixed manually ]

It turned out that probing order change causes problems for some drives:

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

Since root causes are still being investigated and are unlikely to be fixed
before 2.6.25 lets revert this change for now.  As a result cable detection
becomes less reliable when compared with 2.6.24 but the affected drives are
useable again.
Reported-by: NRichard Genoud <richard.genoud@gmail.com>
Bisected-by: NRichard Genoud <richard.genoud@gmail.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

EH actions are ATA_EH_* not ATA_EHI_*.  Rename ATA_EHI_LPM to
ATA_EH_LPM.
Signed-off-by: NTejun Heo <htejun@gmail.com>
Cc: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

There have been reported regressions of the SIL 680 driver when using MMIO, so
this makes it only try MMIO on Cell blades where it's known to be necessary
(the host bridge doesn't do PIO on these).

We'll try to find the root problem with MMIO separately.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: NAlan Cox <alan@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

The Coverity checker spotted that we leak the storage allocated to 'name' in
int driver_add_kobj().  The leak looks legit to me - this is the code :

int driver_add_kobj(struct device_driver *drv, struct kobject *kobj,
                    const char *fmt, ...)
{
        va_list args;
        char *name;
        int ret;

        va_start(args, fmt);
        name = kvasprintf(GFP_KERNEL, fmt, args);
        ^^^^^^^^ This dynamically allocates space...

        va_end(args);

        if (!name)
                return -ENOMEM;

        return kobject_add(kobj, &drv->p->kobj, "%s", name);
	^^^^^^^^ This neglects to free the space allocated
}

Inside kobject_add() a copy of 'name' will be made and used.  As far as I can
see, Coverity is correct in flagging this as a leak, but I'd like some
configmation before the patch is applied.

This should fix it.
Signed-off-by: NJesper Juhl <jesper.juhl@gmail.com>
Cc: Greg KH <greg@kroah.com>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

write_err is an unsigned long used with set_bit() so should not be passed
around as unsigned int.

http://bugzilla.kernel.org/show_bug.cgi?id=10271Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

drivers/memstick/host/tifm_ms.c: In function 'tifm_ms_data_event':
drivers/memstick/host/tifm_ms.c:185: warning: 'p_off' may be used uninitialized in this function

Cc: Alex Dubov <oakad@yahoo.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

# reboot
...
[   42.351266] Flash device refused suspend due to active operation (state 0)
[   42.358195] Unable to handle kernel NULL pointer dereference at virtual address 00000078
[   42.360060] pgd = c7d9c000
[   42.362769] [00000078] *pgd=a7d8d031, *pte=00000000, *ppte=00000000
[   42.372902] Internal error: Oops: 17 [#1]
[   42.376911] Modules linked in:
[   42.379980] CPU: 0    Not tainted  (2.6.25-rc2-10642-ge8f2594-dirty #73)
[   42.380000] PC is at physmap_flash_shutdown+0x28/0x54
...
[   42.380000] Backtrace:
[   42.380000] [<c0130c1c>] (physmap_flash_shutdown+0x0/0x54) from [<c01207c0>] (platform_drv_shutdown+0x20/0x24)
[   42.380000]  r5:28121969 r4:c0229e08
[   42.380000] [<c01207a0>] (platform_drv_shutdown+0x0/0x24) from [<c011cd40>] (device_shutdown+0x60/0x88)
[   42.380000] [<c011cce0>] (device_shutdown+0x0/0x88) from [<c003e8a4>] (kernel_restart_prepare+0x2c/0x3c)
[   42.380000]  r4:00000000
[   42.380000] [<c003e878>] (kernel_restart_prepare+0x0/0x3c) from [<c003ea00>] (kernel_restart+0x14/0x48)
[   42.380000] [<c003e9ec>] (kernel_restart+0x0/0x48) from [<c003fdc0>] (sys_reboot+0xe8/0x1f8)
[   42.380000]  r4:01234567
[   42.380000] [<c003fcd8>] (sys_reboot+0x0/0x1f8) from [<c001aa00>] (ret_fast_syscall+0x0/0x2c)
[   42.380000]  r7:00000058 r6:00000004 r5:00000001 r4:00000000
[   42.380000] Code: 0a000009 e7953004 e1a00003 e1a0e00f (e593f078)
[   42.650051] ---[ end trace 6d6c26a0fc3141de ]---
Segmentation fault
INIT: no more processes left in this runlevel

While looping for mtd[i]s, we should stop at the mtd[i] == NULL.

This patch also removes unnecessary "if (info)" checks:
suspend/resume/shutdown ops are executed only if probe() is succeeded, so info
is guaranteed to be !NULL.
Signed-off-by: NAnton Vorontsov <cbouatmailru@gmail.com>
Cc: David Brownell <david-b@pacbell.net>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix regression in dm-crypt introduced in commit
3a7f6c99 ("dm crypt: use async crypto").

If write requests need to be split into pieces, the code must not process them
in parallel because the crypto context cannot be shared.  So there can be
parallel crypto operations on one part of the write, but only one write bio
can be processed at a time.

This is not optimal and the workqueue code needs to be optimized for parallel
processing, but for now it solves the problem without affecting the
performance of synchronous crypto operation (most of current dm-crypt users).

http://bugzilla.kernel.org/show_bug.cgi?id=10242
http://bugzilla.kernel.org/show_bug.cgi?id=10207Signed-off-by: NMilan Broz <mbroz@redhat.com>
Signed-off-by: NAlasdair G Kergon <agk@redhat.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

blackfin video driver: fix bug when opening/reading/mmaping BF54x and BF52x framebuffer simultaneously

http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=3974

opening/reading/mmaping BF54x and BF52x framebuffer simultaneously triggers
BUG: failure at mm/nommu.c:470/add_nommu_vma() Add VM_SHARED to the default
vm_flags
Signed-off-by: NMichael Hennerich <michael.hennerich@analog.com>
Signed-off-by: NBryan Wu <cooloney@kernel.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

- Allocate pseudo_palette together with fbinfo
- Code cleanup
Signed-off-by: NMichael Hennerich <michael.hennerich@analog.com>
Signed-off-by: NBryan Wu <cooloney@kernel.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This reverts commit 3c0a654e and
fixes kernel bug #10245:

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

The HP Compaq nc6120 has the same PCI sub-device ID as the nx6110, and the
SMBus is used by ACPI for thermal management on the nc6120, so Linux should
not attach a native driver to it.  This means that this quirk is unsafe and
has to be removed.

I also added a comment to help developers realize that adding new IDs to this
SMBus unhiding quirk table should be done only with great care, and in
particular only after checking that ACPI is not making use of the SMBus.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Tomasz Koprowski <tomek@koprowski.org>
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The following patch allows ixp4xx-beeper to be loaded by udev
automatically when compiled as a module with kernel versions 2.4.24 and
greater.

This patch is required because 43cc71ee
("platform: prefix MODALIAS with "platform:"") changed the modalias
string to have the extra prefix.

LKG7102D7:~# udevinfo -a -p /sys/devices/platform/ixp4xx-beeper.4

 looking at device '/devices/platform/ixp4xx-beeper.4':
   KERNEL=="ixp4xx-beeper.4"
   SUBSYSTEM=="platform"
   DRIVER==""
   ATTR{modalias}=="platform:ixp4xx-beeper"

udev therefore tries to modprobe platform:ixp4xx-beeper instead of
ixp4xx-beeper.

LKG7102D7:~# udevtest /sys/devices/platform/ixp4xx-beeper.4
...
import_uevent_var: import into environment: 'PHYSDEVBUS=platform'
import_uevent_var: import into environment: 'MODALIAS=platform:ixp4xx-beeper'
main: looking at device '/devices/platform/ixp4xx-beeper.4' from
subsystem 'platform'
wait_for_sysfs: file '/sys/devices/platform/ixp4xx-beeper.4/bus'
appeared after 0 loops
main: run: 'socket:/org/kernel/udev/monitor'
main: run: '/sbin/modprobe --use-blacklist platform:ixp4xx-beeper'

With this patch, depmod adds an alias line (see below) to
modules.alias which allows modprobe to load the right module.

alias platform:ixp4xx-beeper ixp4xx-beeper
Signed-off-by: NGordon Farquharson <gordonfarquharson@gmail.com>
Signed-off-by: NAlessandro Zummo <a.zummo@towertech.it>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: David Brownell <david-b@pacbell.net>
Cc: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

drivers/char/drm/ati_pcigart.c: In function 'drm_ati_pcigart_init':
drivers/char/drm/ati_pcigart.c:125: warning: format '%08X' expects type 'unsigned int', but argument 3 has type 'dma_addr_t'

Cc: Dave Airlie <airlied@linux.ie>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This has been forgotten in commit f5bbdacc ("[MTD] NAND Modularize
read function") and nobody compiled the driver.
Signed-off-by: NSebastian Siewior <bigeasy@linutronix.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Joern Engel <joern@wh.fh-wedel.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Because of a typo in iwch_accept_cr(), the cxgb3 connection handling
code programs the hardware IRD (incoming RDMA read queue depth) with
the value that is passed in for the ORD (outgoing RDMA read queue
depth).  In particular this means that if an application passes in IRD
> 0 and ORD = 0 (which is a completely sane and valid thing to do for
an app that expects only incoming RDMA read requests), then the
hardware will end up programmed with IRD = 0 and the app will fail in
a mysterious way.

Fix this by using "ep->ird" instead of "ep->ord" in the intended place.
Signed-off-by: NRoland Dreier <rolandd@cisco.com>
Acked-by: NSteve Wise <swise@opengridcomputing.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Revert commit 1192aeb9 ("ACPI:
drivers/acpi: elide a non-zero test on a result that is never 0")
because it turns out that thermal_cooling_device_register() does
actually return NULL if CONFIG_THERMAL is turned off (then the routine
turns into a dummy inline routine in the header files that returns NULL
unconditionally).

This was found with randconfig testing, causing a crash during bootup:

  initcall 0x78878534 ran for 13 msecs: acpi_button_init+0x0/0x51()
  Calling initcall 0x78878585: acpi_fan_init+0x0/0x2c()
  BUG: unable to handle kernel NULL pointer dereference at 00000000
  IP: [<782b8ad0>] acpi_fan_add+0x7d/0xfd
  *pde = 00000000
  Oops: 0000 [#1]
  Modules linked in:

  Pid: 1, comm: swapper Not tainted (2.6.25-rc7-sched-devel.git-x86-latest.git #14)
  EIP: 0060:[<782b8ad0>] EFLAGS: 00010246 CPU: 0
  EIP is at acpi_fan_add+0x7d/0xfd
  EAX: b787c718 EBX: b787c400 ECX: b782ceb4 EDX: 00000007
  ESI: 00000000 EDI: b787c6f4 EBP: b782cee0 ESP: b782cecc
   DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
  Process swapper (pid: 1, ti=b782c000 task=b7846000 task.ti=b782c000)
  Stack: b787c459 00000000 b787c400 78790888 b787c60c b782cef8 782b6fb8 ffffffda
         b787c60c 00000000 78790958 b782cf0c 783005d7 b787c60c 78790958 78790584
         b782cf1c 783007f6 b782cf28 00000000 b782cf40 782ffc4a 78790958 b794d558
  Call Trace:
   [<782b6fb8>] ? acpi_device_probe+0x3e/0xdb
   [<783005d7>] ? driver_probe_device+0x82/0xfc
   [<783007f6>] ? __driver_attach+0x3a/0x70
   [<782ffc4a>] ? bus_for_each_dev+0x3e/0x60
   [<7830048c>] ? driver_attach+0x14/0x16
   [<783007bc>] ? __driver_attach+0x0/0x70
   [<7830006a>] ? bus_add_driver+0x9d/0x1b0
   [<783008c3>] ? driver_register+0x47/0xa3
   [<7813db00>] ? timespec_to_ktime+0x9/0xc
   [<782b7331>] ? acpi_bus_register_driver+0x3a/0x3c
   [<78878592>] ? acpi_fan_init+0xd/0x2c
   [<78863656>] ? kernel_init+0xac/0x1f9
   [<788635aa>] ? kernel_init+0x0/0x1f9
   [<78114563>] ? kernel_thread_helper+0x7/0x10
   =======================
  Code: 6e 78 e8 57 44 e7 ff 58 e9 93 00 00 00 8b 55 f0 8d bb f4 02 00 00 80 4b 2d 10 8b 03 e8 87 cb ff ff 8d 83 18 03 00 00 80 63 2d ef <ff> 35 00 00 00 00 50 68 e8 9c 6e 78 e8 22 44 e7 ff b9 b6 9c 6e
  EIP: [<782b8ad0>] acpi_fan_add+0x7d/0xfd SS:ESP 0068:b782cecc
  ---[ end trace 778e504de7e3b1e3 ]---
  Kernel panic - not syncing: Attempted to kill init!
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Acked-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Took some cycles to re-read the Lguest Journey end-to-end, fix some
rot and tighten some phrases.

Only comments change.  No new jokes, but a couple of recycled old jokes.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

lguest doesn't have features, it has puppies!
Signed-off-by: NTimothy R Ansell <mithro@mithis.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Make sure to call unregister_virtio_device() when a virtio device is removed.
Otherwise, virtio_pci.ko cannot be rmmod'd.

This was spotted by Marcelo Tosatti.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

The function thermal_cooling_device_register always returns either a valid
pointer or a value made with ERR_PTR, so a test for non-zero on the result
will always succeed.

The problem was found using the following semantic match.
(http://www.emn.fr/x-info/coccinelle/)

//<smpl>
@a@
expression E, E1;
statement S,S1;
position p;
@@

E = thermal_cooling_device_register(...)
... when != E = E1
if@p (E) S else S1

@n@
position a.p;
expression E,E1;
statement S,S1;
@@

E = NULL
... when != E = E1
if@p (E) S else S1

@depends on !n@
expression E;
statement S,S1;
position a.p;
@@

* if@p (E)
  S else S1
//</smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

This reverts commit 8fa5913d, which
caused various interesting problems for people, including wrong resource
allocations.  See for example bugzilla entry "2.6.25-rc2: ohci1394
problem (MMIO broken)" at

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

And Gary Hade says:

 "The same change had also exposed an issue reported by Paul Martin that
  has been causing an Oops while hotplugging ThinkPads to a ThinkPad
  Dock II.  See

	http://lkml.org/lkml/2008/2/19/405
	http://bugzilla.kernel.org/show_bug.cgi?id=9961

  I have a fix for the ThinkPad docking Oops but if the issue being
  discussed here is caused by the transparent bridge sizing removal
  change I totally agree that it should be reverted."

  The transparent bridge sizing removal change was motivated by
  insufficient PCI memory resource for a transparent bridge window that
  was being created as a result of expansion ROM(s) being included in
  the transparent bridge sizing calculations.

  A later "PCI: Remove default PCI expansion ROM memory allocation"
  change ( re: http://lkml.org/lkml/2007/12/11/361 ) removes the
  expansion ROM(s) from the transparent bridge sizing calculations which
  actually resolves the original issue in a different manner.  So, even
  if the "PCI: remove transparent bridge sizing" is not problematic it
  is no longer needed anyway."
Identified-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru>
Tested-by: NThomas Meyer <thomas@m3y3r.de>
Acked-by: NGary Hade <garyhade@us.ibm.com>
Acked-by: NIngo Molnar <mingo@elte.hu>
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

We have been printing these messages at KERN_ERR since 2.6.24,
per http://bugzilla.kernel.org/show_bug.cgi?id=9535

But KERN_ERR pops up on a console booted with "quiet"
and causes users to get alarmed and file bugs
about the message itself:
https://bugzilla.redhat.com/show_bug.cgi?id=436589

So reduce the severity of these messages to
KERN_WARNING, which is not printed by "quiet".

This message will still be seen without "quiet",
but a lot of messages are printed in that mode
and it will be less likely to cause undue alarm.

We could go all the way to KERN_DEBUG, but this
is a real warning after all, so it seems prudent
not to require "debug" to see it.
Signed-off-by: NLen Brown <len.brown@intel.com>