Support for the GT-64120-based Wind River 4KC PPMC Evaluation board.
Signed-off-by: Rongkai.Zhan <Rongkai.zhan@windriver.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Convert sizeof/sizeof use to use of ARRAY_SIZE macro, and annotate
irqmap structures as __initdata.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
I found that NPTL's pthread_cond_signal() does not work properly on
kernels compiled by gcc 4.1.x. I suppose inline asm for
__futex_atomic_op() was wrong. I suppose:
1. "=&r" constraint should be used for oldval.
2. Instead of "r" (uaddr), "=R" (*uaddr) for output and "R" (*uaddr)
for input should be used.
3. "memory" should be added to the clobber list.
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Running a UP kernel on a bcm1480 board, I get nonsensical timing
results, like this:
release@unknown:~/tmp$ time ./a.out
real 0m22.906s
user 0m45.792s
sys 0m0.010s
According to my watch, this program took 23 seconds to run, so the real
time clock is OK. It is process accounting that is broken.
I tracked this down to a problem with the function
bcm1480_timer_interrupt in the file sibyte/bcm1480/time.c. This
function calls ll_timer_interrupt for cpu0, and ll_local_timer_interrupt
for all cpus. However, both of these functions do process accounting.
Thus processes running on cpu0 end up with doubled times. This is very
obvious in a UP kernel where all processes run on cpu0.
The correct way to do this is to only call ll_local_timer interrupt if
this is not cpu0. This can be seen in the mips-board/generic/time.c
file, and also in the sibyte/sb1250/time.c file, both of which handle
this correctly. I fixed the bcm1480/time.c file by copying over the
correct code from the sb1250/time.c file.
With this fix, I now get sensible results.
release@unknown:~/tmp$ time ./a.out
real 0m22.903s
user 0m22.894s
sys 0m0.006s
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
It took a while longer than on other architectures but gcc has finally
started to strike us as well ...
This also fixes the damage by 6edfba1b33.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The SOC-it system controller running in big endian mode might forget
byteswapping when DMAing to the last word of physical memory. Fixed by
ignoring the last page of memory.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Patch from Ben Dooks
Core support for the Samsung S3C2442, and the
serial port driver update to allow the serial
port blocks to be used.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Ben Dooks
All the S3C24XX based devices currently have similar
uart blocks, in the same location. Make the process
of adding new uart blocks easier by commonising the
device definitions and adding a new init function
for the cpu code.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Ben Dooks
Platform devices for the LEDs on all the SMDK24XX boards
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from David Brownell
This adds the platform device for SSP/SPI controller, and declares
the ads7846 device hooked up to it. Not all Lubbock boards appear
to populate the connector needed to use this instead of the ucb1400
chip, but it can always be used as a temperature sensor.
In short, this is probably most useful as an example of how to
provide the configuration data used by the pxa2xx_spi driver.
(Last tested against a slightly earlier version of that driver.)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Tony Lindgren
This patch fixes some dyntick locking issues on ARM as pointed
out by Russell King.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Ben Dooks
Move the printk of the CPU information and IDCODE
before the checking of the table entry validity
to aide in debugging new cpu entries.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Ben Dooks
Using the low-level debug routines early in the
kernel debug cause the 1:1 mapping to get into
the TLB, which is not flushed until after the
CPU detection process (which needs the GPIO VA).
This patch moves the VA for the GPIO to the
same offset as the physical offset of the UART
to the GPIO.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Ben Dooks
If CONFIG_CPU_DCACHE_WRITETHOUGH is set, then the
S3C24XX PM code fails to compile, as there is no
need to flush the D-cache, the flush function
arm920_flush_kern_cache_all() is not compiled.
Fix the code to not use this if the config is set.
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 default serial port-mapping for the Osiris has
the port 2 mapped onto the first serial port, and
no port1. Correct this so port 1 is port.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Catalin Marinas
This code was still using the old format for the ARMv6 CPU id and it wasn't
flushing the caches on the MPCore CPU (and other ARM1176 cores). The patch
changes the mask bits to cope with the new id format.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Paul Brook
The old-abi sys_syscall syscall is broken when called from Thumb mode. It
assumes the syscall number is an Arm syscall number (ie. starts from
__NR_OABI_SYSCALL_BASE). In thumb mode syscall numbers start from zero.
The patch below fixes this by clearing the nigh bits of the syscall number
instead of inverting them. Technically this means we accept some invalid
syscall numbers, but I can't see how that could be a problem. The two sets of
numbers far apart that unimplemented syscalls should still be rejected.
Signed-off-by: Paul Brook <paul@codesourcery.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Vitaly Wool
This patch adds default configuration file PNX4008 ARM platform.
It\'s basically the same as the previos one.
Signed-off-by: Vitaly Wool <vwool@ru.mvista.com>
Signed-off-by: Dmitry Pervushin <dpervushin@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Vitaly Wool
This patch adds basic chip support for PNX4008 ARM platform.
It's basically the same as the previous one, but with the rmk's
comments taken into account.
Signed-off-by: Vitaly Wool <vwool@ru.mvista.com>
Signed-off-by: Dmitry Pervushin <dpervushin@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Vitaly Wool
This patch adds kernel headers for PNX4008 ARM platform.
It's basically the same as the previos one, but with the rmk's comments taken into account.
Signed-off-by: Vitaly Wool <vwool@ru.mvista.com>
Signed-off-by: Dmitry Pervushin <dpervushin@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Marc Singer
New documentation for the touchscreen controllers and LCD panels.
Signed-off-by: Marc Singer <elf@buici.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Marc Singer
Reworking of the adaptation macros to allow driver to compile again
for the lpd7x's. Also, support added for the lh79520 so it may use
the smc91x.
Signed-off-by: Marc Singer <elf@buici.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Marc Singer
Driver for operating SSP devices through LPD7A40X CPLD chip. This
driver is used by the audio codecs.
Signed-off-by: Marc Singer <elf@buici.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Marc Singer
Board support and LCD panel configurations to integrate lh7a40x's with
the amba clcd driver.
Signed-off-by: Marc Singer <elf@buici.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Marc Singer
Revised default configuration files.
Signed-off-by: Marc Singer <elf@buici.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Marc Singer
The serial driver now sets up the third UART when it is to be used.
Signed-off-by: Marc Singer <elf@buici.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Marc Singer
Updates to the lpd7a40x_platform files. Includes support for new
architecture, lpd7a400.
Signed-off-by: Marc Singer <elf@buici.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Marc Singer
Updates to the lpd7a40x platform headers. Includes support for new
architecture, lpd7a400.
Signed-off-by: Marc Singer <elf@buici.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The function ethtool_get_ufo was referring to ETHTOOL_GTSO instead of
ETHTOOL_GUFO.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
In the event that our entire receive buffer is full with a series of
chunks that represent a single gap-ack, and then we accept a chunk
(or chunks) that fill in the gap between the ctsn and the first gap,
we renege chunks from the end of the buffer, which effectively does
nothing but move our gap to the end of our received tsn stream. This
does little but move our missing tsns down stream a little, and, if the
sender is sending sufficiently large retransmit frames, the result is a
perpetual slowdown which can never be recovered from, since the only
chunk that can be accepted to allow progress in the tsn stream necessitates
that a new gap be created to make room for it. This leads to a constant
need for retransmits, and subsequent receiver stalls. The fix I've come up
with is to deliver the frame without reneging if we have a full receive
buffer and the receiving sockets sk_receive_queue is empty(indicating that
the receive buffer is being blocked by a missing tsn).
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Right now, every time we increase our rwnd by more then MTU bytes, we
trigger a SACK. When processing large messages, this will generate a
SACK for almost every other SCTP fragment. However since we are freeing
the entire message at the same time, we might as well collapse the SACK
generation to 1.
Signed-off-by: Tsutomu Fujii <t-fujii@nb.jp.nec.com>
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When using ASSOCINFO socket option, we need to limit the number of
maximum association retransmissions to be no greater than the sum
of all the path retransmissions. This is specified in Section 7.1.2
of the SCTP socket API draft.
However, we only do this if the association has multiple paths. If
there is only one path, the protocol stack will use the
assoc_max_retrans setting when trying to retransmit packets.
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch fixes RTNLGRP_IPV6_IFINFO netlink notifications. Issue
pointed out by Patrick McHardy <kaber@trash.net>.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Acked-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
irda_device_info->hints[] is byte aligned but is being
accessed as a u16
Based upon a patch by Luke Yang <luke.adi@gmail.com>.
Signed-off-by: David S. Miller <davem@davemloft.net>
As it is the bridge will only ever declare NETIF_F_IP_CSUM even if all
its constituent devices support NETIF_F_HW_CSUM. This patch fixes
this by supporting the first one out of NETIF_F_NO_CSUM,
NETIF_F_HW_CSUM, and NETIF_F_IP_CSUM that is supported by all
constituent devices.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
The current stack treats NETIF_F_HW_CSUM and NETIF_F_NO_CSUM
identically so we test for them in quite a few places. For the sake
of brevity, I'm adding the macro NETIF_F_GEN_CSUM for these two. We
also test the disjunct of NETIF_F_IP_CSUM and the other two in various
places, for that purpose I've added NETIF_F_ALL_CSUM.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Herbert Xu pointed out that it is unsafe to call netif_tx_disable()
from LLTX drivers because it uses dev->xmit_lock to synchronize
whereas LLTX drivers use private locks.
Convert tg3 to non-LLTX to fix this issue. tg3 is a lockless driver
where hard_start_xmit and tx completion handling can run concurrently
under normal conditions. A tx_lock is only needed to prevent
netif_stop_queue and netif_wake_queue race condtions when the queue
is full.
So whether we use LLTX or non-LLTX, it makes practically no
difference.
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Remove tx_lock where it is unnecessary. tg3 runs lockless and so it
requires interrupts to be disabled and sync'ed, netif_queue and NAPI
poll to be stopped before the device can be reconfigured. After
stopping everything, it is no longer necessary to get the tx_lock.
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
