Fix kernel oops due to machine check occuring in init_chipset_siimage() on PPC
44x platforms.  These 32-bit CPUs have 36-bit physical address and PCI I/O and
memory spaces are mapped beyond 4 GB; arch/ppc/ code has a fixup in ioremap()
that creates an illusion of the PCI I/O and memory resources being mapped below
4 GB, while arch/powerpc/ code got rid of this fixup with PPC 44x having instead
CONFIG_RESOURCES_64BIT=y -- this causes the resources to be truncated to 32-bit
'unsigned long' type in this driver, and so non-existant memory being ioremap'ed
and then accessed...

Thanks to Valentine Barshak for providing an initial patch and explanations.
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86:
  x86: fix 64-bit asm NOPS for CONFIG_GENERIC_CPU
  x86: fix call to set_cyc2ns_scale() from time_cpufreq_notifier()
  revert "x86: tsc prevent time going backwards"

The 'disable_cb' callback is designed as an optimization to tell the host
we don't need callbacks now.  As it is not reliable, the debug check is
overzealous: it can happen on two CPUs at the same time.  Document this.

Even if it were reliable, the virtio_net driver doesn't disable
callbacks on transmit so the START_USE/END_USE debugging reentrance
protection can be easily tripped even on UP.

Thanks to Balaji Rao for the bug report and testing.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
CC: Balaji Rao <balajirrao@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

ASM_NOP's for 64-bit kernel with CONFIG_GENERIC_CPU is broken
with the recent x86 nops merge. They were using GENERIC_NOPS
which will truncate the upper 32bits of %rsi, because of the missing
64bit rex prefix.

For now, fall back ASM NOPS for generic cpu to K8 NOPS, similar
to the code before the wrong x86 nop merge.

This should resolve the crash seen by Ingo on a test-system:

BUG: unable to handle kernel paging request at 00000000d80d8ee8
IP: [<ffffffff802121af>] save_i387_ia32+0x61/0xd8
PGD b8e0067 PUD 51490067 PMD 0
Oops: 0000 [1] SMP
CPU 2
Modules linked in:
Pid: 3871, comm: distcc Not tainted 2.6.25-rc7-sched-devel.git-x86-latest.git #359
RIP: 0010:[<ffffffff802121af>]  [<ffffffff802121af>] save_i387_ia32+0x61/0xd8
RSP: 0000:ffff81003abd3cb8  EFLAGS: 00010246
RAX: ffff810082e93400 RBX: 00000000ffc37f84 RCX: ffff8100d80d8ee0
RDX: 0000000000000000 RSI: 00000000d80d8ee0 RDI: ffff810082e93400
RBP: 00000000ffc37fdc R08: 00000000ffc37f88 R09: 0000000000000008
R10: ffff81003abd2000 R11: 0000000000000000 R12: ffff810082e93400
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff81011fb12dc0(0063) knlGS:00000000f7f1a6c0
CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 00000000d80d8ee8 CR3: 0000000076922000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process distcc (pid: 3871, threadinfo ffff81003abd2000, task ffff8100d80d8ee0)
Stack:  ffff8100bb670380 ffffffff8026de50 0000000000000118 0000000000000002
 0000000000000002 ffff81003abd3e68 ffff81003abd3ed8 ffff81003abd3de8
 ffff81003abd3d18 ffffffff80229785 ffff8100d80d8ee0 ffff810001041280
Call Trace:
 [<ffffffff8026de50>] ? __generic_file_aio_write_nolock+0x343/0x377
 [<ffffffff80229785>] ? update_curr+0x54/0x64
 [<ffffffff80227cd3>] ? ia32_setup_sigcontext+0x125/0x1d2
 [<ffffffff8022839f>] ? ia32_setup_frame+0x73/0x1a5
 [<ffffffff8020b2a5>] ? do_notify_resume+0x1aa/0x7db
 [<ffffffff8024ae8c>] ? getnstimeofday+0x31/0x85
 [<ffffffff80249858>] ? ktime_get_ts+0x17/0x48
 [<ffffffff80249933>] ? ktime_get+0xc/0x41
 [<ffffffff8024973e>] ? hrtimer_nanosleep+0x75/0xd5
 [<ffffffff80249261>] ? hrtimer_wakeup+0x0/0x21
 [<ffffffff8020bfbc>] ? int_signal+0x12/0x17
 [<ffffffff8030e6b3>] ? dummy_file_free_security+0x0/0x1

Code: a6 08 05 00 00 f6 40 14 01 74 34 4c 89 e7 48 0f ae 07 48 8b 86 08 05 00 00 80 78 02 00 79 02 db e2 90 8d b4 26 00 00 00 00 89 f6 <48> 8b 46 08 83 60 14 fe 0f 20 c0 48 83 c8 08 0f 22 c0 eb 07 c6 
Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

In time_cpufreq_notifier() the cpu id to act upon is held in freq->cpu. Use it
instead of smp_processor_id() in the call to set_cyc2ns_scale().
This makes the preempt_*able() unnecessary and lets set_cyc2ns_scale() update
the intended cpu's cyc2ns.

Related mail/thread: http://lkml.org/lkml/2007/12/7/130Signed-off-by: NKarsten Wiese <fzu@wemgehoertderstaat.de>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

revert:

| commit 47001d60
| Author: Thomas Gleixner <tglx@linutronix.de>
| Date:   Tue Apr 1 19:45:18 2008 +0200
|
|     x86: tsc prevent time going backwards

it has been identified to cause suspend regression - and the
commit fixes a longstanding bug that existed before 2.6.25 was
opened - so it can wait some more until the effects are better
understood.
Signed-off-by: NIngo Molnar <mingo@elte.hu>

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6:
  fix endian lossage in forcedeth
  net/tokenring/olympic.c section fixes
  net: marvell.c fix sparse shadowed variable warning
  [VLAN]: Fix egress priority mappings leak.
  [TG3]: Add PHY workaround for 5784
  [NET]: srandom32 fixes for networking v2
  [IPV6]: Fix refcounting for anycast dst entries.
  [IPV6]: inet6_dev on loopback should be kept until namespace stop.
  [IPV6]: Event type in addrconf_ifdown is mis-used.
  [ICMP]: Ensure that ICMP relookup maintains status quo

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6:
  [SPARC64]: Fix user accesses in regset code.
  [SPARC64]: Fix FPU saving in 64-bit signal handling.

* 'pci_id_updates' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/v4l-dvb:
  V4L/DVB (7497): pvrusb2: add new usb pid for 73xxx models
  V4L/DVB (7496): pvrusb2: add new usb pid for 75xxx models

* git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/v4l-dvb:
  V4L/DVB (7499): v4l/dvb Kconfig: Fix bugzilla #10067
  V4L/DVB (7495): s5h1409: fix blown-away bit in function s5h1409_set_gpio
  V4L/DVB (7460): bttv: Bt832 - fix possible NULL pointer deref

* git://git.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog:
  [WATCHDOG] it8712f_wdt Zero MSB timeout byte when disabling watchdog

We handle a broken tsc these days, so no need to panic.  We clear the
TSC bit when tsc_init decides it's unreliable (eg.  under lguest w/ bad
host TSC), leading to bogus panic.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Acked-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Now that we're mapping registers in the DRM driver at load time, the
driver actually checks the PCI ID, so we need to make sure the macros
have all the right bits (and longer term use the DRM headers as the sole
copy of the PCI & register definitions).

This patch adds 945GME support to the DRM headers, fixing a regression
reported in http://bugzilla.kernel.org/show_bug.cgi?id=10395.
Tested-by: NAlexander Oltu <alexander@all-2.com>
Signed-off-by: NJesse Barnes <jesse.barnes@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Since 2.6.25-rc7, I've been seeing an occasional livelock on one x86_64
machine, copying kernel trees to tmpfs, paging out to swap.

Signature: 6000 pages under writeback but never getting written; most
tasks of interest trying to reclaim, but each get_swap_bio waiting for a
bio in mempool_alloc's io_schedule_timeout(5*HZ); every five seconds an
atomic page allocation failure report from kblockd failing to allocate a
sense_buffer in __scsi_get_command.

__scsi_get_command has a (one item) free_list to protect against this,
but rc1's [SCSI] use dynamically allocated sense buffer
de25deb1 upset that slightly.  When it
fails to allocate from the separate sense_slab, instead of giving up, it
must fall back to the command free_list, which is sure to have a
sense_buffer attached.

Either my earlier -rc testing missed this, or there's some recent
contributory factor.  One very significant factor is SLUB, which merges
slab caches when it can, and on 64-bit happens to merge both bio cache
and sense_slab cache into kmalloc's 128-byte cache: so that under this
swapping load, bios above are liable to gobble up all the slots needed
for scsi_cmnd sense_buffers below.

That's disturbing behaviour, and I tried a few things to fix it.  Adding
a no-op constructor to the sense_slab inhibits SLUB from merging it, and
stops all the allocation failures I was seeing; but it's rather a hack,
and perhaps in different configurations we have other caches on the
swapout path which are ill-merged.

Another alternative is to revert the separate sense_slab, using
cache-line-aligned sense_buffer allocated beyond scsi_cmnd from the one
kmem_cache; but that might waste more memory, and is only a way of
diverting around the known problem.

While I don't like seeing the allocation failures, and hate the idea of
all those bios piled up above a scsi host working one by one, it does
seem to emerge fairly soon with the livelock fix.  So lacking better
ideas, stick with that one clear fix for now.
Signed-off-by: NHugh Dickins <hugh@veritas.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Peter Zijlstra <a.p.ziljstra@chello.nl>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
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>

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

tda8290 breaks if tuner is selected, but CONFIG_DVB=n.
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Preserve all other bits when setting gpio.
Signed-off-by: NMichael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NSteven Toth <stoth@hauppauge.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

This patch does fix potential NULL pointer dereference
Signed-off-by: NCyrill Gorcunov <gorcunov@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

I noticed this while testing the latest code. I'm not sure if it is required,
but the normal (or LSB) timeout value is set to zero, so the MSB should
be as well to stay consistent.

If the chip revision is >= 8, set MSB of the 16-bit timeout value to zero
when disabling the watchdog in it8712f_wdt_disable().
Signed-off-by: NAndrew Paprocki <andrew@ishiboo.com>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>

This reverts commit 7c0ea45b which
caused a regression with the backlight being set to off when a laptop
doesn't have a _BQC entry to query the actual backlight value.  The code
blindly then falls back on a value of 0.

See
	http://bugzilla.kernel.org/show_bug.cgi?id=10387
	http://lkml.org/lkml/2008/4/2/366

for details.
Bisected-and-reported-by: NAndrey Borzenkov <arvidjaar@mail.ru>
Cc: Zhao Yakui <yakui.zhao@intel.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Len Brown <len.brown@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

* 'upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/ralf/upstream-linus:
  [MIPS] Make KGDB compile on UP
  [MIPS] Pb1200: Fix header breakage

In 2.6.14 a patch was merged which switching the order of the ipmi device
naming from in-order-of-discovery over to reverse-order-of-discovery.

So on systems with multiple BMC interfaces, the ipmi device names are being
created in reverse order relative to how they are discovered on the system
(e.g.  on an IBM x3950 multinode server with N nodes, the device name for the
BMC in the first node is /dev/ipmiN-1 and the device name for the BMC in the
last node is /dev/ipmi0, etc.).

The problem is caused by the list handling routines chosen in dmi_scan.c.
Using list_add() causes the multiple ipmi devices to be added to the device
list using a stack-paradigm and so the ipmi driver subsequently pulls them off
during initialization in LIFO order.  This patch changes the
dmi_save_ipmi_device() list handling paradigm to a queue, thereby allowing the
ipmi driver to build the ipmi device names in the order in which they are
found on the system.
Signed-off-by: NCarol Hebert <cah@us.ibm.com>
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

THe CFI driver in 2.6.24 kernel is broken.  Not so intensive read/write
operations cause incomplete writes which lead to kernel panics in JFFS2.

We investigated the issue - it is caused by bug in FL_SHUTDOWN parsing code.
Sometimes chip returns -EIO as if it is in FL_SHUTDOWN state when it should
wait in FL_PONT (error in order of conditions).

The following patch fixes the bug in state parsing code of CFI.  Also I've
added comments to notify developers if they want to add new case in future.
Signed-off-by: NAlexey Korolev <akorolev@infradead.org>
Reviewed-by: NJoern Engel <joern@logfs.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

A boot option for the memory controller was discussed on lkml.  It is a good
idea to add it, since it saves memory for people who want to turn off the
memory controller.

By default the option is on for the following two reasons:

1. It provides compatibility with the current scheme where the memory
   controller turns on if the config option is enabled
2. It allows for wider testing of the memory controller, once the config
   option is enabled

We still allow the create, destroy callbacks to succeed, since they are not
aware of boot options.  We do not populate the directory will memory resource
controller specific files.
Signed-off-by: NBalbir Singh <balbir@linux.vnet.ibm.com>
Cc: Paul Menage <menage@google.com>
Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
Cc: Pavel Emelyanov <xemul@openvz.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Hugh Dickins <hugh@veritas.com>
Cc: Sudhir Kumar <skumar@linux.vnet.ibm.com>
Cc: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
Cc: David Rientjes <rientjes@google.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The effects of cgroup_disable=foo are:

- foo isn't auto-mounted if you mount all cgroups in a single hierarchy
- foo isn't visible as an individually mountable subsystem

As a result there will only ever be one call to foo->create(), at init time;
all processes will stay in this group, and the group will never be mounted on
a visible hierarchy.  Any additional effects (e.g.  not allocating metadata)
are up to the foo subsystem.

This doesn't handle early_init subsystems (their "disabled" bit isn't set be,
but it could easily be extended to do so if any of the early_init systems
wanted it - I think it would just involve some nastier parameter processing
since it would occur before the command-line argument parser had been run.

Hugh said:

  Ballpark figures, I'm trying to get this question out rather than
  processing the exact numbers: CONFIG_CGROUP_MEM_RES_CTLR adds 15% overhead
  to the affected paths, booting with cgroup_disable=memory cuts that back to
  1% overhead (due to slightly bigger struct page).

  I'm no expert on distros, they may have no interest whatever in
  CONFIG_CGROUP_MEM_RES_CTLR=y; and the rest of us can easily build with or
  without it, or apply the cgroup_disable=memory patches.

Unix bench's execl test result on x86_64 was

== just after boot without mounting any cgroup fs.==
mem_cgorup=off : Execl Throughput       43.0     3150.1      732.6
mem_cgroup=on  : Execl Throughput       43.0     2932.6      682.0
==

[lizf@cn.fujitsu.com: fix boot option parsing]
Signed-off-by: NBalbir Singh <balbir@linux.vnet.ibm.com>
Cc: Paul Menage <menage@google.com>
Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
Cc: Pavel Emelyanov <xemul@openvz.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Hugh Dickins <hugh@veritas.com>
Cc: Sudhir Kumar <skumar@linux.vnet.ibm.com>
Cc: YAMAMOTO Takashi <yamamoto@valinux.co.jp>
Cc: David Rientjes <rientjes@google.com>
Signed-off-by: NLi Zefan <lizf@cn.fujitsu.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Building UP kernel with KGDB enabled produces the following errors and warning
(fatal due to -Werror in arch/mips/kernel/Makefile):

In file included from arch/mips/kernel/gdb-stub.c:142:
include/asm/smp.h:25:1: "raw_smp_processor_id" redefined
In file included from include/linux/sched.h:69,
                 from arch/mips/kernel/gdb-stub.c:126:
include/linux/smp.h:88:1: this is the location of the previous definition
In file included from arch/mips/kernel/gdb-stub.c:142:
include/asm/smp.h:62: error: redefinition of 'smp_send_reschedule'
include/linux/smp.h:102: error: previous definition of 'smp_send_reschedule' was here
include/asm/smp.h: In function `smp_send_reschedule':
include/asm/smp.h:65: error: dereferencing pointer to incomplete type
arch/mips/kernel/gdb-stub.c: At top level:
arch/mips/kernel/gdb-stub.c:660: warning: 'kgdb_wait' defined but not used

Fix the errors by not directly including <asm/smp.h> (which is already included
by <linux/smp.h>) and the warning by enclosing kgdb_wait() in #ifdef CONFIG_SMP.
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86:
  x86: revert assign IRQs to hpet timer
  x86: tsc prevent time going backwards
  xen: Clear PG_pinned in release_{pt,pd}()
  xen: Do not pin/unpin PMD pages
  xen: refactor xen_{alloc,release}_{pt,pd}()
  x86, agpgart: scary messages are fortunately obsolete
  xen: fix grant table bug
  x86: fix breakage of vSMP irq operations
  x86: print message if nmi_watchdog=2 cannot be enabled
  x86: fix nmi_watchdog=2 on Pentium-D CPUs

Long overdue update of the m68k defconfigs
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The default defconfig should be one from arch/m68k/configs/

arch/m68k/defconfig was not exactly identical to amiga_defconfig but
also considering how long they have been without any update that doesn't
seem to have been on purpose.
Signed-off-by: NAdrian Bunk <adrian.bunk@movial.fi>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

* 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev:
  pata_ali: disable ATAPI DMA
  libata: ATA_12/16 doesn't fall into ATAPI_MISC
  libata: uninline atapi_cmd_type()
  libata: fix IDENTIFY order in ata_bus_probe()

Mikulas Patocka noted that the optimization where we check if a buffer
was already dirty (and we avoid re-dirtying it) was not really SMP-safe.

Since the read of the old status was not synchronized with anything, an
aggressive CPU re-ordering of memory accesses might have moved that read
up to before the data was even written to the buffer, and another CPU
that cleaned it again, causing the newly dirty state to never actually
hit the disk.

Admittedly this would probably never trigger in practice, but it's still
wrong.

Mikulas sent a patch that fixed the problem, but I dislike the subtlety
of the whole optimization, so this is an alternate fix that is more
explicit about the particular SMP ordering for the optimization, and
separates out the speculative reads of the buffer state into its own
conditional (and makes the memory barrier only happen if we are likely
to actually hit the optimized case in the first place).

I considered removing the optimization entirely, but Andrew argued for
it's continued existence. I'm a push-over.

Cc: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit f63fd7e2 ("parport_pc: detection
for SuperIO IT87XX POST") only released the IO port region on success,
not when the probe for the IT87XX chip failed.

That caused not only a reserved region to leak, but also caused an oops
when the driver module was unloaded and somebody tried to cat
/proc/ioports - because the string that was assigned to the IO port
region was a static string in the module virtual address area.
Reported-by: NLubos Lunak <l.lunak@suse.cz>
Cc: Jan Kara <jack@suse.cz>
Cc: Petr Cvek <petr.cvek@tul.cz>
Acked-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

a) if you initialize something with le32_to_cpu(...), then |= it
with host-endian and feed to cpu_to_le32(), it's most definitely
*not* __le32.  As sparse would've told you...

b) the whole sequence is |= cpu_to_le32(host-endian constant)
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

My previous section fix only turned one section problem into another
section problem.

This patch fixes it for real.
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

The other if blocks don't redeclare temp, remove the redeclaration in
the final if() block.

drivers/net/phy/marvell.c:214:7: warning: symbol 'temp' shadows an earlier one
drivers/net/phy/marvell.c:160:6: originally declared here
Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

These entries are allocated in vlan_dev_set_egress_priority, 
but are never released and leaks on vlan device removal.

Drop these in vlan's ->uninit callback - after the device is 
brought down and everyone is notified about it is going to
be unregistered.

Found during testing vlan netnsization patchset.
Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
Acked-by: NPatrick McHardy <kaber@trash.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The commits:

commit 37a47db8
Author: Balaji Rao <balajirrao@gmail.com>
Date:   Wed Jan 30 13:30:03 2008 +0100

    x86: assign IRQs to HPET timers, fix

and

commit e3f37a54
Author: Balaji Rao <balajirrao@gmail.com>
Date:   Wed Jan 30 13:30:03 2008 +0100

    x86: assign IRQs to HPET timers

have been identified to cause a regression on some platforms due to
the assignement of legacy IRQs which makes the legacy devices
connected to those IRQs disfunctional.

Revert them.

This fixes http://bugzilla.kernel.org/show_bug.cgi?id=10382Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NIngo Molnar <mingo@elte.hu>