The code in link_status_1g() computes the active speed
and duplex but does not update the link config state
with those values.

As a result the link speed is not reported correctly
and the XIF is not reprogrammed properly on link up
events.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This fixes a regression added by changeset
53e52c72 ("[NET]: Make ->poll()
breakout consistent in Intel ethernet drivers.")

As pointed out by Jesse Brandeburg, for three of the drivers edited
above there is breakout logic in the *_clean_tx_irq() code to prevent
running TX reclaim forever.  If this occurs, we have to elide NAPI
poll completion or else those TX events will never be serviced.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Acked-by: NJesse Brandeburg <jesse.brandeburg@intel.com>

Merge branch 'v2.6.24-rc7-lockdep' of git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-lockdep

* 'v2.6.24-rc7-lockdep' of git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-lockdep:
  lockdep: more hardirq annotations for notify_die()
  lockdep: fix workqueue creation API lockdep interaction
  lockdep: fix internal double unlock during self-test

sysfs_rename/move_dir() have the following bugs.

 - On dentry lookup failure, kfree() is called on ERR_PTR() value.
 - sysfs_move_dir() has an extra dput() on success path.

Fix them.
Signed-off-by: NTejun Heo <htejun@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

sysfs tries to keep dcache a strict subset of sysfs_dirent tree by
shooting down dentries when a node is removed, that is, no negative
dentry for sysfs.  However, the lookup function returned NULL and thus
created negative dentries when the target node didn't exist.

Make sysfs_lookup() return ERR_PTR(-ENOENT) on lookup failure.  This
fixes the NULL dereference bug in sysfs_get_dentry() discovered by
bluetooth rfcomm device moving around.
Signed-off-by: NTejun Heo <htejun@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

On Sat, 2007-12-29 at 18:06 +0100, Marcin Slusarz wrote:
> Hi
> Today I've got this (while i was upgrading my gentoo box):
>
> WARNING: at kernel/lockdep.c:2658 check_flags()
> Pid: 21680, comm: conftest Not tainted 2.6.24-rc6 #63
>
> Call Trace:
>  [<ffffffff80253457>] check_flags+0x1c7/0x1d0
>  [<ffffffff80257217>] lock_acquire+0x57/0xc0
>  [<ffffffff8024d5c0>] __atomic_notifier_call_chain+0x60/0xd0
>  [<ffffffff8024d641>] atomic_notifier_call_chain+0x11/0x20
>  [<ffffffff8024d67e>] notify_die+0x2e/0x30
>  [<ffffffff8020da0a>] do_divide_error+0x5a/0xa0
>  [<ffffffff80522bdd>] trace_hardirqs_on_thunk+0x35/0x3a
>  [<ffffffff80255b89>] trace_hardirqs_on+0xd9/0x180
>  [<ffffffff80522bdd>] trace_hardirqs_on_thunk+0x35/0x3a
>  [<ffffffff80523c2d>] error_exit+0x0/0xa9
>
> possible reason: unannotated irqs-off.
> irq event stamp: 4693
> hardirqs last  enabled at (4693): [<ffffffff80522bdd>] trace_hardirqs_on_thunk+0x35/0x3a
> hardirqs last disabled at (4692): [<ffffffff80522c17>] trace_hardirqs_off_thunk+0x35/0x37
> softirqs last  enabled at (3546): [<ffffffff80238343>] __do_softirq+0xb3/0xd0
> softirqs last disabled at (3521): [<ffffffff8020c97c>] call_softirq+0x1c/0x30

more early fixups for notify_die()..
Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Dave Young reported warnings from lockdep that the workqueue API
can sometimes try to register lockdep classes with the same key
but different names. This is not permitted in lockdep.

Unfortunately, I was unaware of that restriction when I wrote
the code to debug workqueue problems with lockdep and used the
workqueue name as the lockdep class name. This can obviously
lead to the problem if the workqueue name is dynamic.

This patch solves the problem by always using a constant name
for the workqueue's lockdep class, namely either the constant
name that was passed in or a string consisting of the variable
name.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>

Lockdep, during self-test (when it was simulating double unlocks) was
sometimes unconditionally unlocking a spinlock when it had not been
locked. This won't work for ticket locks.
Signed-off-by: NNick Piggin <npiggin@suse.de>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>

The compiler team did the hard work for this distilling a problem in
large fortran application which showed up when applied to a 290MB input
data set down to this instruction:

	ldfd f34=[r17],-8

Which they noticed incremented r17 by 0x10 rather than decrementing it
by 8 when the value in r17 caused an unaligned data fault.  I tracked
it down to some bad instruction decoding in unaligned.c. The code
assumes that the 'x' bit can determine whether the instruction is
an "ldf" or "ldfp" ... which it is for opcode=6 (see table 4-29 on
page 3:302 of the SDM).  But for opcode=7 the 'x' bit is irrelevent,
all variants are "ldf" instructions (see table 4-36 on page 3:306).

Note also that interpreting the instruction as "ldfp" means that the
"paired" floating point register (f35 in the example here) will also
be corrupted.
Signed-off-by: NTony Luck <tony.luck@intel.com>

* 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev:
  libata: correct handling of TSS DVD
  [libata] core checkpatch fix
  [libata] pata_bf54x: checkpatch fixes
  libata fixes for sparse-found problems

Devices that misreport the validity bit for word 93 look like SATA.  If
they are on the blacklist then we must not test for SATA but assume 40 wire
in the 40 wire case (The TSSCorp reports 80 wire on SATA it seems!)
Signed-off-by: NAlan Cox <alan@redhat.com>
Cc: Tejun Heo <htejun@gmail.com>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: Tejun Heo <htejun@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

WARNING: line over 80 characters
#36: FILE: drivers/ata/pata_bf54x.c:1512:
+	while (bfin_port_info[board_idx].udma_mask>0 && udma_fsclk[udma_mode] > fsclk) {

ERROR: need spaces around that '>' (ctx:VxV)
#36: FILE: drivers/ata/pata_bf54x.c:1512:
+	while (bfin_port_info[board_idx].udma_mask>0 && udma_fsclk[udma_mode] > fsclk) {
 	                                          ^

total: 1 errors, 1 warnings, 19 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Jeff Garzik <jeff@garzik.org>
Cc: Sonic Zhang <sonic.zhang@analog.com>
Cc: Tejun Heo <htejun@gmail.com>
Cc: sonic zhang <sonic.adi@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

In pata_legacy and pata_winbond we've got bugs - cpu_to_le16() instead
of cpu_to_le32().  Fortunately, both affected suckers are VLB, thus
l-e-only, so we might get away with that unless we hit it with slop == 3
(hadn't checked if playing with badly aligned sg could trigger that).
Still buggy...  Moreover, pata_legacy, pata_winbond and pata_qdi forgot to
initialize pad on the write side of 32bit case in their ->data_xfer().
Hopefully the hardware does't care, but still, sending uninitialized
data to it...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

This patch restores the blackfin Hardware Performance Monitor Profiling
support that was killed by the combining of instrumentation menus in
commit 09cadedb.

Since there seems to be no good reason to behave differently from other
architectures, it now automatically selects the hardware performance
counters whenever the profiling is activated.

mach-common/irqpanic.c: pm_overflow calls pm_overflow_handler which is
in oprofile/op_model_bf533.c.  I doubt that setting HARDWARE_PM as "m"
will work at all, since the pm_overflow_handler should be in the core
kernel image because it is called by irqpanic.c.

Therefore, I change HARDWARE_PM from a tristate to a bool.

The whole arch/$(ARCH)/oprofile/ is built depending on CONFIG_OPROFILE. Since
part of the HARDWARE_PM support files sits in this directory, it makes sense to
also depend on OPROFILE, not only PROFILING. Since OPROFILE already depends on
PROFILING, it is correct to only depend on OPROFILE only.

Thanks to Adrian Bunk for finding this bug and providing an initial
patch.
Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
CC: Adrian Bunk <adrian.bunk@movial.fi>
CC: Randy Dunlap <randy.dunlap@oracle.com>
CC: bryan.wu@analog.com
Acked-by: NRobin Getz <rgetz@blackfin.uclinux.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit 09cadedb ("Combine
instrumentation menus in kernel/Kconfig.instrumentation") broke ARM
profiling support, since ARM has some extra Kconfig options and doesn't
just use the common OPROFILE/KPROBES config options.

Rather than just revert the thing outright, or add ARM-specific
knowledge to the generic Kconfig.instrumentation file (where the only
and whole point was to be generic, not too architecture-specific), this
just makes ARM not use the generic version, since it doesn't suit it.

So create an arm-specific version of Kconfig.instrumentation instead,
and use that.
Acked-by: NIngo Molnar <mingo@elte.hu>
Acked-by: NRussell King <rmk+lkml@arm.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

* git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86:
  x86: fix RTC_AIE with CONFIG_HPET_EMULATE_RTC
  x86: asm-x86/msr.h: pull in linux/types.h
  x86: fix boot crash on HIGHMEM4G && SPARSEMEM

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6:
  [SPARC64]: Fix build with SPARSEMEM_VMEMMAP disabled.
  [SPARC]: Make gettimeofday() monotonic again.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6:
  [TOKENRING]: rif_timer not initialized properly
  [NETFILTER]: bridge: fix double POST_ROUTING invocation
  [NETFILTER]: xt_helper: Do not bypass RCU
  [NETFILTER]: ip6t_eui64: Fixes calculation of Universal/Local bit
  [MACVLAN]: Prevent nesting macvlan devices
  [VLAN]: nested VLAN: fix lockdep's recursive locking warning
  [DECNET] ROUTE: fix rcu_dereference() uses in /proc/net/decnet_cache
  [BLUETOOTH]: Always send explicit hci_ll wake-up acks.
  [BLUETOOTH]: rfcomm tty BUG_ON() code fix
  [AX25] af_ax25: Possible circular locking.
  [AX25]: Kill user triggable printks.
  [IPV4] ROUTE: fix rcu_dereference() uses in /proc/net/rt_cache
  [NEIGH]: Fix race between neigh_parms_release and neightbl_fill_parms
  [NIU]: Support for Marvell PHY

* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc:
  [POWERPC] Fix boot failure on POWER6
  [POWERPC] Workaround for iommu page alignment

In the current code, RTC_AIE doesn't work if the RTC relies on
CONFIG_HPET_EMULATE_RTC because the code sets the RTC_AIE flag in
hpet_set_rtc_irq_bit().  The interrupt handles does accidentally check
for RTC_PIE and not RTC_AIE when comparing the time which was set in
hpet_set_alarm_time().

I now verified on a test system here that without the patch applied,
the attached test program fails on a system that has HPET with
2.6.24-rc7-default. That's not critical since I guess the problem has
been there for several kernel releases, but as the fix is quite
obvious.

Configuration is CONFIG_RTC=y and CONFIG_HPET_EMULATE_RTC=y.
Signed-off-by: NBernhard Walle <bwalle@suse.de>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Since the msr.h header uses types like __u32, it should pull in linux/types.h.

[ mingo@elte.hu: affects user-space that includes this header. We dont
  actually like user-space including raw kernel headers but it's a
  longstanding practice and it's easy for the kernel to be nice about
  this. ]
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Denys Fedoryshchenko reported a bootup crash when he upgraded
his system from 3GB to 4GB RAM:

   http://lkml.org/lkml/2008/1/7/9

the bug is due to HIGHMEM4G && SPARSEMEM kernels making pfn_to_page()
to return an invalid pointer when the pfn is in a memory hole. The
256 MB PCI aperture at the end of RAM was not mapped by sparsemem,
and hence the pfn was not valid. But set_highmem_pages_init() iterated
this range without checking the pfn's validity first.

this bug was probably present in the sparsemem code ever since sparsemem
has been introduced in v2.6.13. It was masked due to HIGHMEM64G using
larger memory regions in sparsemem_32.h:

 #ifdef CONFIG_X86_PAE
 #define SECTION_SIZE_BITS       30
 #define MAX_PHYSADDR_BITS       36
 #define MAX_PHYSMEM_BITS        36
 #else
 #define SECTION_SIZE_BITS       26
 #define MAX_PHYSADDR_BITS       32
 #define MAX_PHYSMEM_BITS        32
 #endif

which creates 1GB sparsemem regions instead of 64MB sparsemem regions.
So in practice we only ever created true sparsemem holes on x86 with
HIGHMEM4G - but that was rarely used by distros.

( btw., we could probably save 2MB of mem_map[]s on X86_PAE if we reduced
  the sparsemem region size to 256 MB. )
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Acked-by: NThomas Gleixner <tglx@linutronix.de>

Commit 473980a9 added a call to clear
the SLB shadow buffer before registering it.  Unfortunately this means
that we clear out the entries that slb_initialize has previously set in
there.  On POWER6, the hypervisor uses the SLB shadow buffer when doing
partition switches, and that means that after the next partition switch,
each non-boot CPU has no SLB entries to map the kernel text and data,
which causes it to crash.

This fixes it by reverting most of 473980a9 and instead clearing the
3rd entry explicitly in slb_initialize.  This fixes the problem that
473980a9 was trying to solve, but without breaking POWER6.
Signed-off-by: NPaul Mackerras <paulus@samba.org>

* 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev:
  libata: relocate sdev->manage_start_stop configuration
  sata_sil24: freeze on non-dev errors reported via CERR
  sata_sil24: fix stupid typo
  ata_piix: ignore ATA_DMA_ERR on vmware ich4

* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus:
  [MIPS] Cacheops.h: Fix typo.
  [MIPS] Cobalt: Qube1 has no serial port so don't use it
  [MIPS] Cobalt: Fix ethernet interrupts for RaQ1
  [MIPS] Kconfig fixes for BCM47XX platform

This reverts commit 2e6883bd, as
requested by Fengguang Wu.  It's not quite fully baked yet, and while
there are patches around to fix the problems it caused, they should get
more testing.  Says Fengguang: "I'll resend them both for -mm later on,
in a more complete patchset".

See

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

for some of this discussion.
Requested-by: NFengguang Wu <wfg@mail.ustc.edu.cn>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit 5d2efba6 changed our iommu code
so that it always uses an iommu page size of 4kB.  That means with our
current code, drivers may do a dma_map_sg() of a 64kB page and obtain
a dma_addr_t that is only 4k aligned.

This works fine in most cases except for some infiniband HW it seems,
where they tell the HW about the page size and it ignores the low bits
of the DMA address.

This works around it by making our IOMMU code enforce a PAGE_SIZE alignment
for mappings of objects that are page aligned in the first place and whose
size is larger or equal to a page.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

After 9b8e8de7, manage_start_stop configuration depends on valid ATA
device.  Move it into ata_scsi_dev_config().  This was detected by the
coverity checker.
Signed-off-by: NTejun Heo <htejun@gmail.com>
Cc: Adrian Bunk <bunk@kernel.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

CERR reports errors detected during executing a command.  This doesn't
mean the error is tied to the command and can be recovered by just
issuing it again.  Many of the errors are fatal port-wide connditions
including HSM violation, host bus error and ATA bus error and require
freezing and port reset.

The freezing part wasn't implemented previously.  This used to be okay
because port resets were scheduled anyway and EH eventually resets and
recovers the port.  With PMP support added, this is no longer true.
The error condition and recover actions are attributed to the fan-out
port and the host port condition isn't properly recovered leading to
EH failures.

This patch makes CERR errors which require resets to freeze the port.
This will force host port reset and proper recovery.
Signed-off-by: NTejun Heo <htejun@gmail.com>
Cc: Andrew Ryder <tireman@shaw.ca>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Fix stupid typo.
Signed-off-by: NTejun Heo <htejun@gmail.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

VMware ich4 emulation incorrectly sets DMA_ERR on TF error.  Ignore
it.
Signed-off-by: NTejun Heo <htejun@gmail.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Because Qube1 doesn't have a serial chip waiting for transmit fifo empty
takes forever, which isn't a good idea. No prom_putchar/early console
for Qube1 fixes this.
Signed-off-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de>
Acked-by: NYoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

RAQ1 uses the same interrupt routing as Qube2.
Signed-off-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The patch below fixes two problems for Kconfig on the BCM47xx platform:

- arch/mips/bcm47xx/gpio.c uses ssb_extif_* functions. Selecting
  SSB_DRIVER_EXTIF makes sure those functions are available.
- arch/mips/pci/pci.c needs, when enabled, platform specific functions,
  which are defined when SSB_PCICORE_HOSTMODE is enabled.
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

* 'i2c-for-linus' of git://jdelvare.pck.nerim.net/jdelvare-2.6:
  i2c-sibyte: Fix an error path
  i2c: Driver IDs are optional
  i2c: Spelling fixes
  i2c-omap: Fix NULL pointer dereferencing

Commit 84427eae (remove task_ppid_nr_ns)
moved the task_tgid_nr_ns(task->real_parent) outside of lock_task_sighand().
This is wrong, ->real_parent could be freed/reused.

Both ->parent/real_parent point to nothing after __exit_signal() because
we remove the child from ->children list, and thus the child can't be
reparented when its parent exits.

rcu_read_lock() protects ->parent/real_parent, but _only_ if we know it was
valid before we take rcu lock.

Revert this part of the patch.
Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If the registration of the second I2C channel fails, we really want to
unregister the first one before we return with an error.

While we're here, fix the printk right above so that it displays the
real driver name.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Ralf Baechle <ralf@linux-mips.org>