The dm9601 driver was including the 2 byte hardware header in the
packet length, causing the HW to send 2 extra bytes of garbage on tx.
Signed-off-by: NPeter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

instead of:
"This driver has not been ported to this 64-bit architecture yet."
the driver is said to work on alpha, see
http://bugs.debian.org/305330Signed-off-by: Nmaximilian attems <max@stro.at>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

SET_NETDEV_DEV() in myri10ge to create the "/sys/class/net/<if>/device"
symlink.
Signed-off-by: NMaik Hampel <m.hampel@gmx.de>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

Merge branch 'for_linus' of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc into upstream-fixes

Merge branch 'libertas-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6 into upstream-fixes

Last -rc? That's the plan..

Commit 52ade9b3 changed the suspend code
ordering to execute pm_ops->prepare() after the device model per-device
.suspend() calls in order to fix some ACPI-related issues.  Unfortunately, it
broke the at91 platform which assumed that pm_ops->prepare() would be called
before suspending devices.

at91 used pm_ops->prepare() to get notified of the target system sleep state,
so that it could use this information while suspending devices.  However, with
the current suspend code ordering pm_ops->prepare() is called too late for
this purpose.  Thus, at91 needs an additional method in 'struct pm_ops' that
will be used for notifying the platform of the target system sleep state.
Moreover, in the future such a method will also be needed by ACPI.

This patch adds the .set_target() method to 'struct pm_ops' and makes the
suspend code call it, if implemented, before executing the device model
per-device .suspend() calls.  It also modifies the at91 code to use
pm_ops->set_target() instead of pm_ops->prepare().
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Len Brown <lenb@kernel.org>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Don't use PNP detection by default yet.  We have some PNP and BIOS issues
to work out first.

Sample problem on a Toshiba Portege 4000: the SMCf010 device is handed off
disabled.  We assign I/O ports originally assigned to the SMCf010 to a
PCMCIA device instead.  We enable the SMCf010, configuring it to use
disjoint ports, but _SRS doesn't work correctly, so the device doesn't
work.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Andrey Borzenkov <arvidjaar@mail.ru>
Cc: Adam Belay <ambx1@neo.rr.com>
Cc: Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Cc: Samuel Ortiz <samuel@sortiz.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit 3ebad590 ("[PATCH] x86: Save and
restore the fixed-range MTRRs of the BSP when suspending") added mtrr
operations without verifying that the CPU has MTRRs.  Crashes transmeta
CPUs.

Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: <linux@horizon.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If asus_acpi_init doesn't find any device it knows about, it mistakenly
returns a "success" error code even though it cleans up after itself.  Later
when trying to rmmod asus_acpi, the module_exit routine would try to clean up
one more time and we would end up calling
acpi_bus_unregister_driver(&asus_hotk_driver) twice.  This patch addresses
this first problem by returning -ENODEV when no appropriate device is found.

Then there was also another bug with the code handling the return value of
backlight_device_register.  If this function ever failed, the driver would
cleanup by calling the module_exit routine from module_init, but it would
still return "success".  So any attempt to rmmod this module would result in
asus_acpi_exit being called twice but it's not ready to handle it (I haven't
hit this bug, just found it by code inspection).  This patch fixes that by
inserting a return -ENODEV; at the end of this error handling path.
Signed-off-by: NMaxime Austruy <maxime@tralhalla.org>
Cc: Len Brown <lenb@kernel.org>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Jan Engelhardt <jengelh@computergmbh.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Provide stubs for more PCI bus/slot functions when CONFIG_PCI=n.
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Cc: Matt Domsch <Matt_Domsch@dell.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>

Fix section mismatch warnings:

WARNING: sound/built-in.o(.exit.text+0x3ad): Section mismatch: reference to .init.text: (between 'sb_exit' and 'unload_uart6850')
WARNING: sound/built-in.o(.exit.text+0x753): Section mismatch: reference to .init.text: (between 'snd_mts64_module_exit' and 'snd_portman_module_exit')
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Cc: Jaroslav Kysela <perex@suse.cz>
Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

/home/rpjday/AMD/k/topics/0_hi/hi1.c:15: error: dereferencing pointer to incomplete type
/home/rpjday/AMD/k/topics/0_hi/hi1.c:16: error: dereferencing pointer to incomplete type
Signed-off-by: NAlexey Dobriyan <adobriyan@sw.ru>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

We agreed to remove the WARN_ON_ONCE before 2.6.22 is released.
Signed-off-by: NChristoph Lameter <clameter@sgi.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The blink driver wakes up every jiffies which wastes power unnecessarily.
Using a notifier gives same effect. Also add ability to unload module.
Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
[ We should really just delete the whole thing. The blink driver is
  broken in many other ways too  -Linus ]
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit 9215da33 "fixed" the MTRR range
check to not allow any MTRR's under the 1MB mark (since that's where the
fixed MTRR's are active).

However, that was totally bogus, since it's normal (and almost required)
to have a large variable MTRR that starts at 0, and covers some large
percentage of the whole RAM, and then using the fixed MTRR's to override
that large MTRR to handle the special ISA hole in the 640k-1M region.

The old check was bogus too (checking that no variable MTRR is used that
is entirely under the 1MB range), but at least it wasn't actively
detrimental, because no sane situation would ever trigger such MTRR
usage in the first place.

That said, the whole notion of not allowing variable MTRR's in the low
1MB is just stupid, so rather than revert the commit, this just removes
the whole sad and unnecessary check entirely.

Cc: Jan Beulich <jbeulich@novell.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Tested-by: NLuca Palermo <darkmage@sabayonlinux.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

* 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6:
  [SPARC64]: Add linux/pagemap.h to asm/tlb.h
  [SPARC64]: Need to set state to IDLE during sun4v IRQ enable.
  [SPARC64]: Fix VIRQ enabling.
  [SPARC64]: Add irqs to mdesc_node.

* 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6:
  [IRDA]: fix printk format
  [NETPOLL] netconsole: fix soft lockup when removing module
  [NETPOLL]: tx lock deadlock fix
  SCTP: lock_sock_nested in sctp_sock_migrate
  SCTP: Fix sctp_getsockopt_get_peer_addrs
  SCTP: update sctp_getsockopt helpers to allow oversized buffers

The vdso64 portion of patch 74609f45 for
fixing problems with NULL gettimeofday input mistakenly checks for a
null tz field twice, when it should be checking for null tz once, and
null tv once; by way of a r10/r11 typo.

Any application calling gettimeofday(&tv,NULL) will "fail".

This corrects that typo, and makes my G5 happy.

Tested on G5.
Signed-off-by: NWill Schmidt <will_schmidt@vnet.ibm.com>
Cc: Tony Breeds <tony@bakeyournoodle.com>
Forwarded-by: NBen Herrenschmidt <benh@kernel.crashing.org>

[ Ben says: "I checked the 32 bits part of the change is correct.  You
  can probably blame me for originally writing the 2 versions with
  inversed usage of r10 and r11, thus confusing Tony :-)"

  Ben duly blamed.   - Linus ]
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix printk format warning:
drivers/net/irda/irport.c:512: warning: format '%d' expects type 'int', but argument 5 has type 'long int'
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In commit 4bedb452 both the udp and tcp
cases where changed to use udp_hdr() instead of leaving the tcp case
alone and fixing with tcp_hdr().

This ended up causing random behavior with TCP connections because
of looking for tcp_hdr()->check in the wrong place.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

#1
Until kernel ver. 2.6.21 (including) cancel_rearming_delayed_work()
required a work function should always (unconditionally) rearm with
delay > 0 - otherwise it would endlessly loop. This patch replaces
this function with cancel_delayed_work(). Later kernel versions don't
require this, so here it's only for uniformity.

#2
After deleting a timer in cancel_[rearming_]delayed_work() there could
stay a last skb queued in npinfo->txq causing a memory leak after
kfree(npinfo).

Initial patch & testing by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: NJarek Poplawski <jarkao2@o2.pl>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

As seen on sparc64-allnoconfig:

  CC      arch/sparc64/mm/tlb.o
In file included from arch/sparc64/mm/tlb.c:19:
include/asm/tlb.h: In function 'tlb_flush_mmu':
include/asm/tlb.h:60: warning: implicit declaration of function 'release_pages'
include/asm/tlb.h: In function 'tlb_remove_page':
include/asm/tlb.h:92: warning: implicit declaration of function 'page_cache_release'
Signed-off-by: NAlexey Dobriyan <adobriyan@sw.ru>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

* 'for_linus' of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc:
  phy: Fix phy_id for Vitesse 824x PHY

Not all the world is an i386.  Many architectures need 64-bit arguments to be
aligned in suitable pairs of registers, and the original
sys_sync_file_range(int, loff_t, loff_t, int) was therefore wasting an
argument register for padding after the first integer.  Since we don't
normally have more than 6 arguments for system calls, that left no room for
the final argument on some architectures.

Fix this by introducing sys_sync_file_range2(int, int, loff_t, loff_t) which
all fits nicely.  In fact, ARM already had that, but called it
sys_arm_sync_file_range.  Move it to fs/sync.c and rename it, then implement
the needed compatibility routine.  And stop the missing syscall check from
bitching about the absence of sys_sync_file_range() if we've implemented
sys_sync_file_range2() instead.

Tested on PPC32 and with 32-bit and 64-bit userspace on PPC64.
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The interrupt clearing code in mpsc_sdma_intr_ack() mistakenly clears the
interrupt for both controllers instead of just the one its supposed to.
This can result in the other controller appearing to hang because its
interrupt was effectively lost.

So, don't clear the interrupt cause bits for both MPSC controllers when
clearing the interrupt for one of them.  Just clear the one that is
supposed to be cleared.
Signed-off-by: NJay Lubomirski <jaylubo@motorola.com>
Acked-by: NMark A. Greer <mgreer@mvista.com>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

gcc correctly says

fs/ext2/super.c: In function 'ext2_remount':
fs/ext2/super.c:1055: warning: 'err' may be used uninitialized in this function
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

arch/mips/jazz/setup.c:55:4: error: Initializer entry defined twice
Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Acked-by: NRalf Baechle <ralf@linux-mips.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This can disrupt userspace signal management.
Signed-off-by: NEvgeniy Polyakov <johnpol@2ka.mipt.ru>
Cc: Roland McGrath <roland@redhat.com>
Cc: Oleg Nesterov <oleg@tv-sign.ru>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

When I use relayfs with "overwrite" mode, read() still sets incorrect
number of consumed bytes.
Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Acked-by: NTom Zanussi <zanussi@us.ibm.com>
Acked-by: NDavid Wilder <dwilder@us.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix a bug in the relay read interface causing the number of consumed bytes
to be set incorrectly.
Signed-off-by: NTom Zanussi <zanussi@us.ibm.com>
Signed-off-by: NDavid Wilder <dwilder@us.ibm.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Change __devexit to __devexit_p:
sound/isa/opl3sa2.c:956: error: expected expression before '__attribute__'
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Cc: Jaroslav Kysela <perex@suse.cz>
Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Also, remove outdated 1394 tree and mention MAINTAINERS as pointer to
development trees.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

WARNING: drivers/built-in.o(.text+0x8742a): Section mismatch: reference to .init.data:chipsfb_fix (between 'chipsfb_pci_init' and 'chipsfb_set_par')
WARNING: drivers/built-in.o(.text+0x87432): Section mismatch: reference to .init.data:chipsfb_fix (between 'chipsfb_pci_init' and 'chipsfb_set_par')
WARNING: drivers/built-in.o(.text+0x87442): Section mismatch: reference to .init.data:chipsfb_var (between 'chipsfb_pci_init' and 'chipsfb_set_par')
WARNING: drivers/built-in.o(.text+0x8744a): Section mismatch: reference to .init.data:chipsfb_var (between 'chipsfb_pci_init' and 'chipsfb_set_par')

init_chips is only called from chipsfb_pci_init
chipsfb_fix and chipsfb_var are only referenced from init_chips
Signed-off-by: NOlaf Hering <olaf@aepfle.de>
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>

The new code in kernel/signal.c does not allow fetching private signals
from another task.  This patch avoid spurious POLLIN returns from a
signalfd poll(2) operation.
Signed-off-by: NDavide Libenzi <davidel@xmailserver.org>
Cc: Oleg Nesterov <oleg@tv-sign.ru>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This patch changes the test for the thread pid from >= 0 to > 0.

When the saa8134 driver initialization fails after a certain point, it goes
through the complete shutdown process for the driver.  Part of shutting it
down includes tearing down the thread for tv audio.

The test for tearing down the thread tests for >= 0.  Since the dev
structure is kzalloc'd, the test will always be true if we haven't tried to
start the thread yet.  We end up waiting on pid 0 to complete, which will
never happen, so we lock up.

This bug was observed in Novell Bugzilla 284718, when request_irq() failed.
Signed-off-by: NJeff Mahoney <jeffm@suse.com>
Acked-by: NMauro Carvalho Chehab <mchehab@infradead.org>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Cannot mix const and __initdata:
sound/pci/ice1712/prodigy192.c:708: error: ak4114_controls causes a section type conflict
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Cc: Jaroslav Kysela <perex@suse.cz>
Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Rename struct pci_driver data so that false section mismatch warnings won't
be produced.

Sam, ISTM that depending on variable names is the weakest & worst part of
modpost section checking.  Should __init_refok work here?  I got build
errors when I tried to use it, probably because the struct pci_driver probe
and remove methods are not marked "__init_refok".

WARNING: drivers/dma/ioatdma.o(.data+0x10): Section mismatch: reference to .init.text: (between 'ioat_pci_drv' and 'ioat_pci_tbl')
WARNING: drivers/dma/ioatdma.o(.data+0x14): Section mismatch: reference to .exit.text: (between 'ioat_pci_drv' and 'ioat_pci_tbl')
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Acked-by: NChris Leech <christopher.leech@intel.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If one has a dependency chain (tristate)FOO depends on (bool)BAR depends on
(tristate)BAZ, build problems will result.  If BAZ=m, then BAR can be set
y, which allows FOO=y.  It's possible to have FOO=y && BAZ=m, which
wouldn't be allowed if FOO depended directly on BAZ.  In effect, the bool
promotes the tristate from m to y.

This ends up causing a problem with several menuconfigs that look like:

menuconfig BAR
	bool
	depends on BAZ [tristate]
if BAR
config FOO
	tristate
endif

The solution used here is to add the dependencies of BAR to the if
statement, so that items in the if block will gain a direct
non-bool-promoted dependency on BAZ.  This is how it would work if a menu
was used instead of an if block.
Signed-off-by: NTrent Piepho <xyzzy@speakeasy.org>
Acked-by: NMauro Carvalho Chehab <mchehab@infradead.org>
Cc: "David S. Miller" <davem@davemloft.net>
Acked-by: NJeff Garzik <jeff@garzik.org>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Chas Williams <chas@cmf.nrl.navy.mil>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>