Patch from Lothar Wassmann
The function serial_pxa_set_termios() is calling uart_update_timeout()
with the baud rate divisor as third parameter, while
uart_update_timeout() expects the baud rate in this place.
This results in a bogus port->timeout which is proportional to the
baud rate.
Signed-off-by: Lothar Wassmann <LW@KARO-electronics.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Ben Dooks
The NWFPE is producing a number of errors from sparse
due to not defining a number of functions in the
header files.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from George G. Davis
Fix leading, trailing and other miscellaneous whitespace issues
in arch/arm/kernel/alignment.c.
Signed-off-by: George G. Davis <gdavis@mvista.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from George G. Davis
When building for CPU_V6 targets, we should use -mtune=arm1136j-s rather
than -mtune=strongarm but fall back to the later in case someone is
using an older toolchain (although they should really upgrade instead).
Signed-off-by: George G. Davis <gdavis@mvista.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Ben Dooks
Do not export items that are not needed by symbol name
elsewhere
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Ben Dooks
The items in the export table do not need to be
exported elsehwere, so quash the sparse warning
by making the symbol for the table entry static.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Ben Dooks
The s3c2410 serial driver is missing static declerations
on several functions that are not exported, and have no
need of being exported outside the driver
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Ben Dooks
arch/arm/mach-s3c2410/time.c is missing include
of cpu.h, causing the declaration of the timer
struct (s3c24xx_timer) to be flagged as missing
the declaration.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Nicolas Pitre
Either no one is using an ARM710 with recent kernels, or all ARM710s
still in use are not afflicted by this swi bug. Nevertheless, the code
to work around the ARM710 swi bug is itself currently buggy since it
uses r8 as a pointer to S_PC while in fact it holds the spsr content
these days. Fix that, and simplify the code as well.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Glibc is about to get some new high precision timer stuff that relies on
the standard timebase of the PPC architecture.
However, some (rare & old) CPUs do not have such timebase and it is a
bit annoying to have your stuff just crash because you are running on
the wrong CPU...
This exposes to userland a CPU feature bit that tells that the current
processor doesn't have a standard timebase. It's negative logic so that
glibc will still "just work" on older kernels (it will just be unhappy
on those old CPUs but that doesn't really matter as distro tend to
update glibc & kernel at the same time).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Interestingly enough, ppc32 had broken timekeeping for ages... It
worked, but probably drifted a bit more than could be explained by the
actual bad precision of the timebase calibration. We discovered that
recently when somebody figured out that the common code was using
CLOCK_TICK_RATE to correct the timekeeing, and ppc32 had a completely
bogus value for it.
This patch turns it into something saner. Probably not as good as doing
something based on the actual timebase frequency precision but I'll
leave that sort of math to others. This at least makes it better for
the common HZ values.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Give an empty definition for clear_can_do_skas() when it is not needed.
Thanks to Junichi Uekawa <dancer@netfort.gr.jp> for reporting the
breakage and providing a fix (I re-fixed it in an IMHO cleaner way).
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The patch to use host AIO support that I submitted early after 2.6.13 exposed
some problems in the block driver. I have fixes for these, but am not
comfortable putting them into 2.6.14 at this late date. So, this patch reverts
the use of host AIO.
I will resubmit the original patch, plus fixes to the driver after 2.6.14
in order to get a reasonable amount of testing before they're exposed to
the general public.
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This removes three headers from include/asm-ppc64 that are now in
include/asm-powerpc and are sufficiently similar that they can be
used with ARCH=ppc64.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Recent commits upstream have changed files which are currently
duplicated in arch/powerpc and include/asm-powerpc. This updates
them with the corresponding changes.
Signed-off-by: Paul Mackerras <paulus@samba.org>
We weren't computing the size of the hash table correctly on iSeries
because the relevant code in prom.c was #ifdef CONFIG_PPC_PSERIES.
This moves the code to hash_utils_64.c, makes it unconditional, and
cleans it up a bit.
Signed-off-by: Paul Mackerras <paulus@samba.org>
On ARCH=ppc64 we were getting htab_hash_mask recalculated
to the correct value for our particular machine by accident.
In the merge tree, that code was commented out, so htab_hash_mask
was being corrupted.
We now set ppc64_pft_size instead which gets htab_has_mask
calculated correctly for us later. We should put an
ibm,pft-size property in the device tree at some point.
Also set -mno-minimal-toc in some makefiles.
Allow iSeries to configure PROC_DEVICETREE.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
We were not doing alignment properly when remapping the kernel image.
What we want is a 4MB aligned physical address to map at KERNBASE.
Mistakedly we were 4MB aligning the virtual address where the kernel
initially sits, that's wrong.
Instead, we should PAGE align the virtual address, then 4MB align the
physical address result the prom gives to us.
Signed-off-by: David S. Miller <davem@davemloft.net>
Refuse to install a page into a mapping if the mapping count is already
ridiculously large.
You probably cannot trigger this on 32-bit architectures, but on a
64-bit setup we should protect against it.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Newer gcc's are generating this relocation, so the module loader needs to
handle it.
Signed-off-by: Peter Bergner <bergner@vnet.ibm.com>
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Nir Tzachar <tzachar@cs.bgu.ac.il> points out that if an ELF file specifies a
zero-length bss at a whacky address, we cannot load that binary because
padzero() tries to zero out the end of the page at the whacky address, and
that may not be writeable.
See also http://bugzilla.kernel.org/show_bug.cgi?id=5411
So teach load_elf_binary() to skip the bss settng altogether if the elf file
has a zero-length bss segment.
Cc: Roland McGrath <roland@redhat.com>
Cc: Daniel Jacobowitz <dan@debian.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
I've noticed that the calculations for seg_size and nr_segs in
__dma_sync_page_highmem() (arch/ppc/kernel/dma-mapping.c) are wrong. The
incorrect calculations can result in either an oops or a panic when running
fsck depending on the size of the partition.
The problem with the seg_size calculation is that it can result in a
negative number if size is offset > size. The problem with the nr_segs
caculation is returns the wrong number of segments, e.g. it returns 1 when
size is 200 and offset is 4095, when it should return 2 or more.
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Revert this recent correctness change: Douglas Crosher <dcrosher@scieneer.com>
reported that it broke an existing application, and that madvise() works
without error on anonymous mappings on Solaris.
This means that madvise() will remain non-standards-compliant: we should
return -EBADF for all requests against non-file-backed vma's, but Linux only
does this for MADV_WILLNEED requests.
Signed-off-by: Suzuki K P <suzuki@in.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Here is a compatibility fix between Linux and Solaris when used with VxFS
filesystems: Solaris usually accepts acl entries in any order, but with
VxFS it replies with NFSERR_INVAL when it sees a four-entry acl that is not
in canonical form. It may also fail with other non-canonical acls -- I
can't tell, because that case never triggers: We only send non-canonical
acls when we fake up an ACL_MASK entry.
Instead of adding fake ACL_MASK entries at the end, inserting them in the
correct position makes Solaris+VxFS happy. The Linux client and server
sides don't care about entry order. The three-entry-acl special case in
which we need a fake ACL_MASK entry was handled in xdr_nfsace_encode. The
patch moves this into nfsacl_encode.
Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
Acked-by: Trond Myklebust <trond.myklebust@fys.uio.no>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
v9fs_file_read and v9fs_file_write use kmalloc to allocate buffers as big
as the data buffer received as parameter. kmalloc cannot be used to
allocate buffers bigger than 128K, so reading/writing data in chunks bigger
than 128k fails.
This patch reorganizes v9fs_file_read and v9fs_file_write to allocate only
buffers as big as the maximum data that can be sent in one 9P message.
Signed-off-by: Latchesar Ionkov <lucho@ionkov.net>
Cc: Eric Van Hensbergen <ericvh@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
In the current dell_rbu code ver 2.0 the packet update mechanism makes the
user app dump every individual packet in to the driver.
This adds in efficiency as every packet update makes the
/sys/class/firmware/dell_rbu/loading and data files to disappear and reappear
again. Thus the user app needs to wait for the files to reappear to dump
another packet. This slows down the packet update tremendously in case of
large number of packets. I am submitting a new patch for dell_rbu which will
change the way we do packet updates;
In the new method the user app will create a new single file which has already
packetized the rbu image and all the packets are now staged in this file.
This driver also creates a new entry in
/sys/devices/platform/dell_rbu/packet_size ; the user needs to echo the packet
size here before downloading the packet file.
The user should do the following:
create one single file which has all the packets stacked together.
echo the packet size in to /sys/devices/platform/dell_rbu/packet_size.
echo 1 > /sys/class/firmware/dell_rbu/loading
cat the packetfile > /sys/class/firmware/dell_rbu/data
echo 0 > /sys/class/firmware/dell_rbu/loading
The driver takes the file which came through /sys/class/firmware/dell_rbu/data
and takes chunks of paket_size data from it and place in contiguous memory.
This makes packet update process very efficient and fast. As all the packet
update happens in one single operation. The user can still read back the
downloaded file from /sys/devices/platform/dell_rbu/data.
Signed-off-by: Abhay Salunke <abhay_salunke@dell.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
pSeries_irq_bus_setup is marked __devinit but references s7a_workaround
which is marked __initdata.
Depending on who got the memory for s7a_workaround (and if the value was
now positive), it was possible for PCI hotplugged devices to have 3
subtracted from their interrupt number. This would happen randomly and
caused me much confusion :)
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Search for a disconnect ccw_device on the ccw bus rather than on the css
bus (was a typo in patch I did for the klist conversion). A cast to an
embedding ccw_device from an embedded device in a struct subchannel will
lead us to oopses.
Signed-off-by: Cornelia Huck <cohuck@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This used to be inline in include/asm-ppc64/unistd.h, but isn't
inline in the merged include/asm-powerpc/unistd.h, so we need a
definition here.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This fixes up a variety of minor problems in compiling with ARCH=ppc
arising from using the merged versions of various header files.
A lot of the changes are just adding #include <asm/machdep.h> to
files that use ppc_md or smp_ops_t.
This also arranges for us to use semaphore.c, vecemu.c, vector.S and
fpu.S from arch/powerpc/kernel when compiling with ARCH=ppc.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Now instead of having a ppc_md function, we just have a variable
which says whether to do the i8259 irq canonicalization or not,
and set that variable on the platforms that need that. It looks
to me that radstone_ppc7d was trying to use irq canonicalization
for something else in a broken kind of way - it will need to be
fixed properly.
Signed-off-by: Paul Mackerras <paulus@samba.org>
A bunch of printks were left in arch/powerpc/kernel/setup_64.c from
when I was chasing a bug. This removes them.
Signed-off-by: Paul Mackerras <paulus@samba.org>
for certain NICs
Reverting 685fac63f5:
> [PATCH] e100: CPU cycle saver microcode
>
>
> Add cpu cycle saver microcode to 8086:{1209/1229} other than ICH devices.
>
> Signed-off-by: Mallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com>
> Signed-off-by: Ganesh Venkatesan <ganesh.venkatesan@intel.com>
> Signed-off-by: John Ronciak <john.ronciak@intel.com>
> Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
This is required to avoid unloading a module that has active timewait
sockets, such as DCCP.
Signed-off-by: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Noticed by Andrea Bittau, that provided a patch that was modified to
not transition from RESPOND to OPEN when receiving DATA packets.
Signed-off-by: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
For consistency with ccid_exit and to fix a bug when
IP_DCCP_UNLOAD_HACK is enabled as the control sock is not associated
to any CCID.
Signed-off-by: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch add support to change the state of the private protocol
information via conntrack_netlink.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Harald Welte <laforge@netfilter.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch adds the ability of changing the state a TCP connection. I know
that this must be used with care but it's required to provide a complete
conntrack creation via conntrack_netlink. So I'll document this aspect on
the upcoming docs.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Harald Welte <laforge@netfilter.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Initially we used 64bit counters for conntrack-based accounting, since we
had no event mechanism to tell userspace that our counters are about to
overflow. With nfnetlink_conntrack, we now have such a event mechanism and
thus can save 16bytes per connection.
Signed-off-by: Harald Welte <laforge@netfilter.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch fixes the following bugs in ESP:
* Fix transport mode MTU overestimate. This means that the inner MTU
is smaller than it needs be. Worse yet, given an input MTU which
is a multiple of 4 it will always produce an estimate which is not
a multiple of 4.
For example, given a standard ESP/3DES/MD5 transform and an MTU of
1500, the resulting MTU for transport mode is 1462 when it should
be 1464.
The reason for this is because IP header lengths are always a multiple
of 4 for IPv4 and 8 for IPv6.
* Ensure that the block size is at least 4. This is required by RFC2406
and corresponds to what the esp_output function does. At the moment
this only affects crypto_null as its block size is 1.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch uses the macro ALIGN in all the applicable spots for ESP.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
