This was inadvertently broken when the entry.S code split up,
restore the missing branch and get subsequent traps working
under debug again. This manifested itself as a lockup when
attempting to reload the VBR base.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
SH-2 and SH-2A need to use a different syscall base for the trapa
vector than the other parts, so fixup the logic in the kernel_execve()
case.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Some time ago the schedule frame size changed and we failed to reflect
this in get_wchan() at the time. This first popped up as a problem on
SH7751R where schedule_frame ended up being unaligned and generating
an unaligned trap. This fixes it up again..
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Previously we haven't been doing anything with verbose BUG() reporting,
and we've been relying on the oops path for handling BUG()'s, which is
rather sub-optimal.
This switches BUG handling to use a fixed trapa vector (#0x3e) where we
construct a small bug frame post trapa instruction to get the context
right. This also makes it trivial to wire up a DIE_BUG for the atomic
die chain, which we couldn't really do before.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This adds alarm support for the RTC_ALM_SET, RTC_ALM_READ,
RTC_WKALM_SET and RTC_WKALM_RD operations to rtc-sh.
The only unusual part is the handling of the alarm interrupt. If you
clear the alarm flag (AF) while the time in the RTC still matches the
time in the alarm registers than AF is immediately re-set, and if the
alarm interrupt (AIE) is still enabled then it re-triggers. I was
originally getting around 20k+ interrupts generated during the second
when the RTC and alarm registers matches.
The solution I've used is to clear AIE when the alarm goes off and
then use the carry interrupt to re-enabled it. The carry interrupt
will check AF and re-enabled AIE if it's clear. If AF is not clear
it'll clear it and then the check will be repeated next carry
interrupt. This a bit in rtc structure that indicates that it's
waiting to have AIE re-enabled so it doesn't turn it on when it
wasn't enabled anyway.
Signed-off-by: Jamie Lenehan <lenehan@twibble.org>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
The RMONCNT register, which holds the month in the RTC, takes a value
between 1 and 12 while the tm_mon field in the time structures takes
a value between 0 and 11. This wasn't being taken into account in
rtc-sh resulting in the month being out by one.
eg, on my board during boot the RTC is set to:
RTC is set to Thu Jul 01 09:00:00 1999
but "hwclock -r" immediately after logging in was showing:
Sun Aug 1 09:01:43 1999 0.000000 seconds
Signed-off-by: Jamie Lenehan <lenehan@twibble.org>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This can use the generic routines, so kill off the board-specific ones.
Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
We have a few different ways to do the atomic operations, so split
them out in to different headers rather than bloating atomic.h.
Kernelspace gUSA will take this up to a third implementation.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This updates the SH7619 and SH7206 code for the IPR IRQ changes.
Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
gcc 4 for sh changes the names of some compiler intrinsic functions
and adds some additional ones. This patch adds the new ones, and
fixes up various module symbol resolution issues.
Signed-off-by: Stuart Menefy <stuart.menefy@st.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
When testing the per second interrupt support (RTC_UIE_ON/RTC_UIE_OFF)
of the new RTC system it would die in sh_rtc_interrupt due to a null
ptr dereference. The following gets it working correctly.
Signed-off-by: Jamie Lenehan <lenehan@twibble.org>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Register the RTC resources for the sh775x subtype so that the new
generic RTC support in drivers/rtc/rtc-sh.c will work.
Signed-off-by: Jamie Lenehan <lenehan@twibble.org>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This adds a new defconfig for SE7619 and updates SE7206.
Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
In the 64-bit PTE case there's no point in restricting the encoding
to the low bits of the PTE, we can instead bump all of this up to
the high 32 bits and extend PTE_FILE_MAX_BITS to 32, adopting the
same convention used by x86 PAE.
There's a minor discrepency between the number of bits used for the
swap type encoding between 32 and 64-bit PTEs, but this is unlikely
to cause any problem given the extended offset.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Make powerpc's __ilog2_u64() take a 64-bit argument.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
We should not initialize rootfs before all the core initializers have
run. So do it as a separate stage just before starting the regular
driver initializers.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
As reported by Andy Whitcroft, at least the SLES9 initrd build process
depends on getting the kernel version from the kernel binary. It does
that by simply trawling the binary and looking for the signature of the
"linux_banner" string (the string "Linux version " to be exact. Which
is really broken in itself, but whatever..)
That got broken when the string was changed to allow /proc/version to
change the UTS release information dynamically, and "get_kernel_version"
thus returned "%s" (see commit a2ee8649ba:
"[PATCH] Fix linux banner utsname information").
This just restores "linux_banner" as a static string, which should fix
the version finding. And /proc/version simply uses a different string.
To avoid wasting even that miniscule amount of memory, the early boot
string should really be marked __initdata, but that just causes the same
bug in SLES9 to re-appear, since it will then find other occurrences of
"Linux version " first.
Cc: Andy Whitcroft <apw@shadowen.org>
Acked-by: Herbert Poetzl <herbert@13thfloor.at>
Cc: Andi Kleen <ak@suse.de>
Cc: Andrew Morton <akpm@osdl.org>
Cc: Steve Fox <drfickle@us.ibm.com>
Acked-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This looks like a result of too many auto-merges. The
CONFIG_ARCH_VERSATILE case was handled a total of 6 times.
This kills 5 of them.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
--
drivers/net/smc91x.h | 90 ---------------------------------------------------
1 file changed, 90 deletions(-)
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Fix sizing of big_bytes in the case of vlan frames. The 4
VLAN_HLEN bytes were omitted, leading to sizing the big buffer
4 bytes smaller than it should be. Due to how rx buffers are
carved from pages, this was harmless for the common (9000, 1500)
byte MTUs, but could lead to data corruption for some MTUs.
Signed-off-by: Brice Goglin <brice@myri.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Receive full vlan frames into smalls when running with a jumbo MTU.
Signed-off-by: Brice Goglin <brice@myri.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Drop the old routines that used the physically contigous skb now
that we use the physical pages. And rename myri10ge_page_rx_done()
to myri10ge_rx_done() as it was previously.
Signed-off-by: Brice Goglin <brice@myri.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Switch to physical page skb, by calling the new page-based
allocation routines and using myri10ge_page_rx_done().
Signed-off-by: Brice Goglin <brice@myri.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Add physical page skb allocation routines and page based rx_done,
to be used by upcoming patches.
Signed-off-by: Brice Goglin <brice@myri.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Indentation cleanups to synchronize to our tree which is automatically
indent'ed.
Signed-off-by: Brice Goglin <brice@myri.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
This driver tries to enable/disable NAPI at runtime, but
does so in an unsafe manner, and the NAPI interrupt handling is
a mess. Replace it with a compile time selected NAPI implementation.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Since macb is a chip-internal device, use __raw_readl and
__raw_writel instead of readl/writel. This will perform native-endian
accesses, which is the right thing to do on both AVR32 and ARM devices.
Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
The macb driver calls schedule_delayed_work() and friends, so we need
to use a struct delayed_work along with it. The conversion was
explained by David Howells on lkml Dec 5 2006:
http://lkml.org/lkml/2006/12/5/269
Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Fix compilation failures when building the ucc_geth driver with spinlock
debugging.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
The driver is usable on the newer SAM9 processors so replace all text
references to AT91RM9200 with just AT91.
The controller bug where all the words are byte-swapped is fixed on the
AT91SAM9 processors. The byte-swapping work-around therefore only needs
to be done if cpu_is_at91rm9200().
[Original patch from Wojtek Kaniewski]
The AT91RM9200 and AT91SAM9260 processors support two MMC/SD slots - the
slot which is connected is now passed via the platform_data and the
correct slot selected in the AT91_MCI_SDCR register.
The driver should not be calling at91_set_gpio_output() since the VCC
pin should have already been configured as an output in the
processor/board setup code. The driver should call
at91_set_gpio_value().
Signed-off-by: Andrew Victor <andrew@sanpeople.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Some controllers report an invalid iomem size, but seem to work
correctly anyway. Change our current error to just a warning and
hope it doesn't cause too much problems.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Currently on SD/MMC card removal the system exhibits the following message (the platform is ARM Versatile):
prev->state: 2 != TASK_RUNNING??
mmcqd/762[CPU#0]: BUG in __schedule at linux-2.6/kernel/sched.c:3826
(akpm: someone tried to fix this, but it's still wrong)
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
A number of small cleanups to the AT91RM9200 MMC driver:
- fix warnings generated by pr_debug().
- prepend "AT91 MMC:" to printk() messages.
Signed-off-by: Andrew Victor <andrew@sanpeople.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
