Change comment at top of swiotlb.c to reflect that the code is shared
with EM64T (i.e. Intel x86_64). Also add an entry for myself so that
if I "broke it", everyone knows who "bought it"... :-)
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

The current implementation of sync_single in swiotlb.c chokes on
DMA_BIDIRECTIONAL mappings. This patch adds the capability to sync
those mappings, and optimizes other syncs by accounting for the
sync target (i.e. cpu or device) in addition to the DMA direction of
the mapping.
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

This patch implements swiotlb_sync_single_range_for_{cpu,device}. This
is intended to support an x86_64 implementation of
dma_sync_single_range_for_{cpu,device}.
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

The implementations of swiotlb_sync_single_for_{cpu,device} are
identical. Likewise for swiotlb_syng_sg_for_{cpu,device}. This patch
move the guts of those functions to two new inline functions, and
calls the appropriate one from the bodies of those functions.
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

The swiotlb implementation is shared by both IA-64 and EM64T. However,
the source itself lives under arch/ia64. This patch moves swiotlb.c
from arch/ia64/lib to lib/ and fixes-up the appropriate Makefile and
Kconfig files. No actual changes are made to swiotlb.c.
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Machine vector selection has always been a bit of a hack given how
early in system boot it needs to be done.  Services like ACPI namespace
are not available and there are non-trivial problems to moving them to
early boot.  However, there's no reason we can't change to a different
machvec later in boot when the services we need are available.  By
adding a entry point for later initialization of the swiotlb, we can add
an error path for the hpzx1 machevec initialization and fall back to the
DIG machine vector if IOMMU hardware isn't found in the system.  Since
ia64 uses 4GB for zone DMA (no ISA support), it's trivial to allocate a
contiguous range from the slab for bounce buffer usage.
Signed-off-by: NAlex Williamson <alex.williamson@hp.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Commit 66759a01 introduced the fix for
time ticking too fast on some boards by disabling one of the doubly
connected timer pins on ATI boards.

However, it ends up being _much_ too broad a brush, and that just makes
some other ATI boards not work at all since they now have no timer
source.

So disable the automatic ATI southbridge detection, and just rely on
people who see this problem disabling it by hand with the option
"disable_timer_pin_1" on the kernel command line.

Maybe somebody can figure out the proper tests at a later date.
Acked-by: NPeter Osterlund <petero2@telia.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Actually add the file this time.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This allows i2c-pxa to finally build.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Nicolas Pitre

This apparently fell in the crack somewhere.  Add it back.
Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Vincent Sanders

When building the ARM platforms several serial drivers fail to compile
with GCC 4.01 due to extern/static ambiguity.
Signed-off-by: NVincent Sanders <vince@arm.linux.org.uk>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Its possible that we can write to the hvc_console tty as soon it is
registered.  Recently this started happening due to (what looks like) a
change to the hotplug code.

Unfortunately at this stage we have not started the khvcd kernel thread and
oops.  The solution is to start the kernel thread before registering the
tty.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

While doing an allyesconfig build, I noticed that the commit

    commit 8cdfd251
    Author: Takashi Iwai <tiwai@suse.de>
    Date:   Wed Sep 7 14:08:11 2005 +0200

        [ALSA] Remove superfluous PCI ID definitions

broke the RME32 and RME96 drivers, since the PCI IDs they use seem to have
changed names.  Here's a patch to fix this -- compile tested only, since I
have no idea what the hardware even is.

Fix the build of the RME32 and RME96 drivers by having them use the
PCI_DEVICE_ID_RME_xxx names defined in <linux/pci_ids.h> instead of the
PCI_DEVICE_ID_xxx names that they used to define themselves.

Also fix the typo in the id PCI_DEVICE_IDRME__DIGI96_8_PAD_OR_PST so the
name is PCI_DEVICE_ID_RME_DIGI96_8_PAD_OR_PST.
Signed-off-by: NRoland Dreier <rolandd@cisco.com>
Acked-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The call to fb_firmware_edid may return NULL but this is not checked before
trying to memcpy using this pointer.
Signed-off-by: NAntonino Daplas <adaplas@pol.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

On 8xx flush_tlb_range() declaration is using a "struct mm_struct *"
pointer type while the function itself uses "struct vm_area_struct *".
Signed-off-by: NMarcelo Tosatti <marcelo.tosatti@cyclades.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

the 4th id field should be not used
Signed-off-by: NKarsten Keil <kkeil@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

And mention 'pci=assign-busses' as a possible fix.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Noted by David Miller:

  "The bug is that free_fd_array() takes a "num" argument, but when
   calling it from __free_fdtable() we're instead passing in the size in
   bytes (ie.  "num * sizeof(struct file *)")."

Yes it is a bug. I think I messed it up while merging newer
changes with an older version where I was using size in bytes
to optimize.
Signed-off-by: NDipankar Sarma <dipankar@in.ibm.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

With the new changes that we made in the initialization of the slab
allocator, we first setup the cache from which array caches are allocated,
and then the cache, from which kmem_list3's are allocated.

Now if the array cache comes from a cache in which objsize > 32, (in this
instance size-64) then, first size-64 cache will be allocated and then the
size-128 (if this is the cache from which kmem_list3's are going to be
allocated).

So with these new changes, we are not guaranteed that we will be
initializing the malloc_sizes array in a serialized order. Thus there is
a bug in __find_general_cachep, as we are checking whether the first
cache_sizes ptr is NULL.

This is replaced by checking whether the array-cache cache is initialized.
Attached is a patch which does that.  Boots fine on a x86-64, with
DEBUG_SPIN, DEBUG_SLAB, and preempt.

Attached is a patch which does that.  Boots fine on a x86-64, with
DEBUG_SPIN, DEBUG_SLAB, and preempt.Thanks & Regards, Alok
Signed-off-by: NAlok N Kataria <alokk@calsoftinc.com>
Signed-off-by: Shobhit Dayal <shobhitdayal.com>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: Christoph Lameter <christoph@lameter.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

In some cases, especially on modern laptops with a lot of PCI and
cardbus bridges, we're unable to assign correct secondary/subordinate
bus numbers to all cardbus bridges due to BIOS limitations unless
we are using "pci=assign-busses" boot option.
So some cardbus controllers may not have attached subordinate pci_bus
structure, and yenta driver must cope with it - just ignore such cardbus
bridges.

For example, see https://bugzilla.novell.com/show_bug.cgi?id=113778Signed-off-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Pavel Emelianov and Kirill Korotaev observe that fs and arch users of
security_vm_enough_memory tend to forget to vm_unacct_memory when a
failure occurs further down (typically in setup_arg_pages variants).

These are all users of insert_vm_struct, and that reservation will only
be unaccounted on exit if the vma is marked VM_ACCOUNT: which in some
cases it is (hidden inside VM_STACK_FLAGS) and in some cases it isn't.

So x86_64 32-bit and ppc64 vDSO ELFs have been leaking memory into
Committed_AS each time they're run.  But don't add VM_ACCOUNT to them,
it's inappropriate to reserve against the very unlikely case that gdb
be used to COW a vDSO page - we ought to do something about that in
do_wp_page, but there are yet other inconsistencies to be resolved.

The safe and economical way to fix this is to let insert_vm_struct do
the security_vm_enough_memory check when it finds VM_ACCOUNT is set.

And the MIPS irix_brk has been calling security_vm_enough_memory before
calling do_brk which repeats it, doubly accounting and so also leaking.
Remove that, and all the fs and arch calls to security_vm_enough_memory:
give it a less misleading name later on.
Signed-off-by: NHugh Dickins <hugh@veritas.com>
Signed-Off-By: NKirill Korotaev <dev@sw.ru>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

It turns out that the BUG_ON() in fs/exec.c: de_thread() is unreliable
and can trigger due to the test itself being racy.

de_thread() does
 	while (atomic_read(&sig->count) > count) {
	}
	.....
	.....
	BUG_ON(!thread_group_empty(current));

but release_task does
	write_lock_irq(&tasklist_lock)
	__exit_signal
		(this is where atomic_dec(&sig->count) is run)
	__exit_sighand
	__unhash_process
		takes write lock on tasklist_lock
		remove itself out of PIDTYPE_TGID list
	write_unlock_irq(&tasklist_lock)

so there's a clear (although small) window between the
atomic_dec(&sig->count) and the actual PIDTYPE_TGID unhashing of the
thread.

And actually there is no need for all threads to have exited at this
point, so we simply kill the BUG_ON.

Big thanks to Marc Lehmann who provided the test-case.

Fixes Bug 5170 (http://bugme.osdl.org/show_bug.cgi?id=5170)
Signed-off-by: NAlexander Nyberg <alexn@telia.com>
Cc: Roland McGrath <roland@redhat.com>
Cc: Andrew Morton <akpm@osdl.org>
Cc: Ingo Molnar <mingo@elte.hu>
Acked-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Certain (SGI?) ia64 boxes object to having their PCI BARs
restored unless absolutely necessary. This patch restricts calling
pci_restore_bars from pci_set_power_state unless the current state
is PCI_UNKNOWN, the actual (i.e. physical) state of the device is
PCI_D3hot, and the device indicates that it will lose its configuration
when transitioning to PCI_D0.
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Jeff,
sorry if I have flooded your inbox, I had some problems with the
mail server here yesterday, but it seems to be fixed ...
Ok patch 3-4 have no dependencies on patch 2 since only qeth driver is
affected.Thus I have made a new patch 2 for ctc driver.
Thank you .

[patch 2/4] s390: ctc driver fixes

From: Peter Tiedemann <ptiedem@de.ibm.com>
	- race condition fixed
	- minor cleanup
Signed-off-by: NPeter Tiedemann <ptiedem@de.ibm.com>
Signed-off-by: NFrank Pavlic <pavlic@de.ibm.com>

diffstat:
 ctcmain.c |   41 ++++++++++++++++++++++-------------------
 1 files changed, 22 insertions(+), 19 deletions(-)
Signed-off-by: NJeff Garzik <jgarzik@pobox.com>

Merge of four previous patches and the Kconfig fix
 * Remove debug printk's
 * whitespace cleanup and version number change
 * clear interrupts, reset phy, and reset hardware on shutdown
 * ignore 64bit counter overflow interrupts
 * fix a couple of places where second port could clobber state
   of first port.
Signed-off-by: NStephen Hemminger <shemminger@osdl.org>
Signed-off-by: NJeff Garzik <jgarzik@pobox.com>

Do not count frames dropped by the hardware as part of rx_dropped.
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: NJeff Garzik <jgarzik@pobox.com>

Do not count non-error frames dropped by the hardware as
part of rx_dropped. Instead, count those frames dropped as
rx_missed_errors. Also, do not count other error frames as part of
rx_dropped. Finally, do not count oversized frames in rx_dropped
(since they are counted as part of rx_length_errors).
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: NJeff Garzik <jgarzik@pobox.com>

Do not count frames dropped by the hardware as part of rx_dropped.
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: NJeff Garzik <jgarzik@pobox.com>

this patch display the correct channel number with iwlist scan
Signed-off-by: NMatthieu CASTET <castet.matthieu@free.fr>
Signed-off-by: NJeff Garzik <jgarzik@pobox.com>

There is an uninitialized variable issue in sata_sis.c
Signed-off-by: NJeff Garzik <jgarzik@pobox.com>

This patch fixes a nasty typo I introduced in my previous patch (commit
f2c853bc). The right offset of the
second port in pure sata mode is 64 and not 0x64.
Thanks to Martin Schuster for pointing this to me
Signed-off-by: NArnaud Patard <apatard@mandriva.com>
 ---
Signed-off-by: NJeff Garzik <jgarzik@pobox.com>

xircom_cb.c does #if CONFIG_NET_POLL_CONTROLLER instead of #ifdef,
resulting in drivers/net/tulip/xircom_cb.c:120:5: warning:
"CONFIG_NET_POLL_CONTROLLER" is not defined.
Signed-off-by: NKeith Owens <kaos@sgi.com>
Signed-off-by: NJeff Garzik <jgarzik@pobox.com>

drivers/net/s2io.c: In function `init_shared_mem':
drivers/net/s2io.c:431: warning: cast from pointer to integer of different size
drivers/net/s2io.c: In function `free_shared_mem':
drivers/net/s2io.c:662: warning: cast from pointer to integer of different size

Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NJeff Garzik <jgarzik@pobox.com>