Based upon a report by Meelis Roos.
Any function call can try to access the current
thread register via the _mcount hooks when the kernel
is built with -pg (via ftrace or STACK_DEBUG).
That can't be setup properly very early on during
the bootup of other cpus for sun4u and some early
sun4v systems.
So add notrace markers to these specific functions, so
that _mcount doesn't get invoked too early.
Signed-off-by: David S. Miller <davem@davemloft.net>
We no longer put the top-level PCI controller device into the
PCI layer device list. So pbm->pci_bus->self is always NULL.
Therefore, use direct PCI config space accesses to get at
the PCI controller's PCI_STATUS register.
Tested by Meelis Roos.
Signed-off-by: David S. Miller <davem@davemloft.net>
The functions cio_tm_start_key and cio_start_key use the same private
orb structure of a subchannel, so the orb needs to be cleared of old
data before it is used again. A respective memset is missing from
cio_start_key and hereby added.
Signed-off-by: Stefan Weinhuber <wein@de.ibm.com>
Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Since 16f7f9564c, we've seen
oopses when grouping/ungrouping devices:
Unable to handle kernel pointer dereference at virtual kernel address 0000000000
114000
Oops: 0004 [#1] PREEMPT SMP
Modules linked in: bonding qeth_l2 dm_multipath sunrpc qeth_l3 dm_mod qeth chsc_
sch ccwgroup
CPU: 1 Not tainted 2.6.26-29.x.20080815-s390xdefault #1
Process iperf (pid: 24412, task: 000000003f446038, ksp: 000000003c929e08)
Krnl PSW : 0404d00180000000 000003e00006f6e6 (qeth_irq+0xda/0xb28 [qeth])
R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:3
Krnl GPRS: 0000000000000000 000003e000000003 0000000000000000 0000000000114ccc
000000003fb82e48 000003e00006f60c 000000000000000c 000000003ce72100
0000000000114944 000000003fb82e48 0000000000114ccc 000000003fe8fd28
000003e000066000 000003e000076128 000000003fe8fdb8 000000003fe8fd28
Krnl Code: 000003e00006f6da: bf3f2024 icm %r3,15,36(%r2)
000003e00006f6de: a774023c brc 7,3e00006fb56
000003e00006f6e2: a7280000 lhi %r2,0
>000003e00006f6e6: 5020a1a0 st %r2,416(%r10)
000003e00006f6ea: 58109000 l %r1,0(%r9)
000003e00006f6ee: a7111000 tmll %r1,4096
000003e00006f6f2: a77400f9 brc 7,3e00006f8e4
000003e00006f6f6: 8810000c srl %r1,12
Call Trace:
([<000000003fe8fd20>] 0x3fe8fd20)
[<000000000033bf2a>] ccw_device_call_handler+0xb2/0xd8
[<0000000000339e1c>] ccw_device_irq+0x124/0x164
[<0000000000339758>] io_subchannel_irq+0x8c/0x118
[<00000000003309ba>] do_IRQ+0x192/0x1bc
[<0000000000114f66>] io_return+0x0/0x8
[<00000000001149cc>] sysc_do_svc+0x0/0x22
([<0000000000114a18>] sysc_noemu+0x10/0x16)
[<00000200002e047c>] 0x200002e047c
Last Breaking-Event-Address:
[<000003e00006f6d6>] qeth_irq+0xca/0xb28 [qeth]
The problem is that dev->driver_data for a ccw device is NULL,
while it should point to the ccwgroup device it is a member of.
This happened due to incorrect cleanup if creating a ccwgroup
device failed because the ccw devices were already grouped.
Fix this by setting cdev[i] to NULL in the error handling of
ccwgroup_create_from_string() after we give up our reference and
by checking if the driver_data points to the ccwgroup device in
ccwgroup_release() just to be really sure.
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Completely disable NOPL on 32 bits. It turns out that Microsoft
Virtual PC is so broken it can't even reliably *fail* in the presence
of NOPL.
This leaves the infrastructure in place but disables it
unconditionally.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Byte swap the addresses in the page list for fast register work requests
to big endian to match what the HCA expectx. Also, the addresses must
have the "present" bit set so that the HCA knows it can access them.
Otherwise the HCA will fault the first time it accesses the memory
region.
Signed-off-by: Vladimir Sokolovsky <vlad@mellanox.co.il>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
The previous patch in response to the recursive locking on IPsec
reception is broken as it tries to drop the BH socket lock while in
user context.
This patch fixes it by shrinking the section protected by the
socket lock to sock_queue_rcv_skb only. The only reason we added
the lock is for the accounting which happens in that function.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Initialized total objects atomic for the node in init_kmem_cache_node. The
uninitialized value was ruining the stats in /proc/slabinfo.
Acked-by: Christoph Lameter <cl@linux-foundation.org>
Signed-off-by: Salman Qazi <sqazi@google.com>
Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
The SEC's h/w IV out implementation DMAs the trailing encrypted payload
block of the last encryption to ctx->iv. Since the last encryption may
still be pending completion, we can sufficiently prevent successive
packets from being transmitted with the same IV by xoring with sequence
number.
Also initialize alg_list earlier to prevent oopsing on a failed probe.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Lee Nipper <lee.nipper@freescale.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
They were already called once in arch/x86/kernel/setup.c - we don't need to call them again.
fixes:
http://bugzilla.kernel.org/show_bug.cgi?id=11485
Signed-off-by: Alex Nixon <alex.nixon@citrix.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
PFN_PHYS() can truncate large addresses unless its passed a suitable
large type. This is fixed more generally in the patch series
introducing phys_addr_t, but we need a short-term fix to solve a
Xen regression reported by Roberto De Ioris.
Reported-by: Roberto De Ioris <roberto@unbit.it>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
There are a few commits that misencoded my name (or used "oe" instead of
"ö"). So add a correct version to .mailmap.
Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* master.kernel.org:/home/rmk/linux-2.6-arm:
[ARM] Fix PCI_DMA_BUS_IS_PHYS for ARM
[ARM] 5247/1: tosa: SW_EAR_IN support
[ARM] 5246/1: tosa: add proper clock alias for tc6393xb clock
[ARM] 5245/1: Fix warning about unused return value in drivers/pcmcia
[ARM] OMAP: Fix MMC device data
imx serial: fix rts handling for non imx1 based hardware
imx serial: set RXD mux bit on i.MX27 and i.MX31
i.MX serial: fix init failure
pcm037: add rts/cts support for serial port
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6:
niu: panic on reset
netlink: fix overrun in attribute iteration
[Bluetooth] Fix regression from using default link policy
ath9k: Assign seq# when mac80211 requests this
- 8-bit interface mode never worked properly. The only adapter I have
which supports the 8b mode (the Jmicron) had some problems with its
clock wiring and they discovered it only now. We also discovered that
ProHG media is more sensitive to the ordering of initialization
commands.
- Make the driver fall back to highest supported mode instead of always
falling back to serial. The driver will attempt the switch to 8b mode
for any new MSPro card, but not all of them support it. Previously,
these new cards ended up in serial mode, which is not the best idea
(they work fine with 4b, after all).
- Edit some macros for better conformance to Sony documentation
Signed-off-by: Alex Dubov <oakad@yahoo.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Herton Krzesinski reports that the error-checking changes in
04ebd4aee5 ("block/ioctl.c and
fs/partition/check.c: check value returned by add_partition") cause his
buggy USB camera to no longer mount. "The camera is an Olympus X-840.
The original issue comes from the camera itself: its format program
creates a partition with an off by one error".
Buggy devices happen. It is better for the kernel to warn and to proceed
with the mount.
Reported-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Cc: Abdel Benamrouche <draconux@gmail.com>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix the section mismatch warning generated by the incorrect naming of
s3c24xx_spidrv which should be s3c24xx_spi_driver:
WARNING: drivers/spi/spi_s3c24xx.o(.data+0x4):
Section mismatch in reference from the variable s3c24xx_spidrv
to the (unknown reference) .exit.text:(unknown)
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When suspending the system with atmel_lcdfb enabled, I sometimes see
this:
atmel_lcdfb atmel_lcdfb.0: FIFO underflow 0x10
Which can be explained by the fact that we're not stopping the LCD
controller and its DMA engine when suspending, we're just gating the
clocks to them.
There's another potential issue which may be harder to trigger but
much more nasty: If we gate the clocks at _just_ the right moment,
e.g. when the DMA engine is doing a bus transaction, we may cause the
DMA engine to violate the system bus protocol and cause a lockup.
Avoid these issues by shutting down the LCD controller before entering
suspend (and restarting it when resuming). This prevents the underrun
from happening in the first place, and prevents whatever nastiness is
happening when the bus clock stops in the middle of a DMA transfer.
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If you are on ia64 and you modprobe xpc then modprobe -r xpc, you
immediately get a panic. xpc depends on xp which depends on gru for a
symbol. That symbol is only used when we are running on UV hardware.
Currently, the GRU driver detects we are not on UV hardware and does no
initializing. It does not do the same check when unloading. As a result,
the gru driver attempts to tear down stuff that was not setup.
This is a simple two-line workaround to get us through this release. Once
2.6.28 is opened, we need to rework the symbols that xp is depending on
from gru so the gru driver can properly fail to load when hardware is not
available.
Signed-off-by: Robin Holt <holt@sgi.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It should be linux-uvc-devel@lists.berlios.de.
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Provide summary ABI docs about the /sys/class/gpio files.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The iterator for_each_zone_zonelist() uses a struct zoneref *z cursor when
scanning zonelists to keep track of where in the zonelist it is. The
zoneref that is returned corresponds to the the next zone that is to be
scanned, not the current one. It was intended to be treated as an opaque
list.
When the page allocator is scanning a zonelist, it marks elements in the
zonelist corresponding to zones that are temporarily full. As the
zonelist is being updated, it uses the cursor here;
if (NUMA_BUILD)
zlc_mark_zone_full(zonelist, z);
This is intended to prevent rescanning in the near future but the zoneref
cursor does not correspond to the zone that has been found to be full.
This is an easy misunderstanding to make so this patch corrects the
problem by changing zoneref cursor to be the current zone being scanned
instead of the next one.
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
Cc: Andy Whitcroft <apw@shadowen.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: <stable@kernel.org> [2.6.26.x]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fixes two DMA bugs in the pxa2xx_spi driver. The first bug is in all
versions of this driver; the second was introduced in the 2.6.20 kernel,
and prevents using the driver with chips like m25p16 flash (which can
issue large DMA reads).
1. Zero length transfers are permitted for use to insert timing,
but pxa2xx_spi.c will fail if this is requested in DMA mode.
Fixed by using programmed I/O (PIO) mode for such transfers.
2. Transfers larger than 8191 are not permitted in DMA mode. A
test for length rejects all large transfers regardless of DMA
or PIO mode. Worked around by rejecting only large transfers
with DMA mapped buffers, and forcing all other transfers
larger than 8191 to use PIO mode. A rate limited warning is
issued for DMA transfers forced to PIO mode.
This patch should apply to all kernels back to and including 2.6.20;
it was test patched against 2.6.20. An additional patch would be
required for older kernels, but those versions are very buggy anyway.
Signed-off-by: Ned Forrester <nforrester@whoi.edu>
Cc: Vernon Sauder <vernoninhand@gmail.com>
Cc: Eric Miao <eric.y.miao@gmail.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: <stable@kernel.org> [2.6.25.x, 2.6.26.x]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fixes several chipselect bugs in the pxa2xx_spi driver. These bugs are in
all versions of this driver and prevent using it with chips like m25p16
flash.
1. The spi_transfer.cs_change flag is handled too early:
before spi_transfer.delay_usecs applies, thus making the
delay ineffective at holding chip select.
2. spi_transfer.delay_usecs is ignored on the last transfer
of a message (likewise not holding chipselect long enough).
3. If spi_transfer.cs_change is set on the last transfer, the
chip select is always disabled, instead of the intended
meaning: optionally holding chip select enabled for the
next message.
Those first three bugs were fixed with a relocation of delays
and chip select de-assertions.
4. If a message has the cs_change flag set on the last transfer,
and had the chip select stayed enabled as requested (see 3,
above), it would not have been disabled if the next message is
for a different chip. Fixed by dropping chip select regardless
of cs_change at end of a message, if there is no next message
or if the next message is for a different chip.
This patch should apply to all kernels back to and including 2.6.20;
it was test patched against 2.6.20. An additional patch would be
required for older kernels, but those versions are very buggy anyway.
Signed-off-by: Ned Forrester <nforrester@whoi.edu>
Cc: Vernon Sauder <vernoninhand@gmail.com>
Cc: Eric Miao <eric.y.miao@gmail.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: <stable@kernel.org> [2.6.25.x, 2.6.26.x]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Error out on transfer length != multiple of bytes per word with -EINVAL.
Fixes a buffer overrun crash if length < bytes per word.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Acked-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit a61f5345 (spi_mpc83xx clockrate fixes) broke clockrate calculation
for low speeds. SPMODE_DIV16 should be set if the divider is higher than
64, not only if the divider gets clipped to 1024.
Furthermore, the clipping check was off by a factor 16 as well.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
A "Quicklists: 0 kB" line has just started appearing in
/proc/meminfo, but most architectures (including x86) don't have
them configured, so #ifdef it, like the highmem lines.
And those architectures which do have quicklists configured are
using them for page tables: so let's place it next to PageTables.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Acked-by: Christoph Lameter <cl@linux-foundation.org>
Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
There is no description of bit 4 of coredump_filter in the
documentation. This patch adds it.
Signed-off-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Cc: Roland McGrath <roland@redhat.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If all the cpus in a cpuset are offlined, the tasks in it will be moved to
the nearest ancestor with non-empty cpus.
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
Acked-by: Paul Jackson <pj@sgi.com>
Cc: Paul Menage <menage@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
After the patch:
commit 0b2f630a28
Author: Miao Xie <miaox@cn.fujitsu.com>
Date: Fri Jul 25 01:47:21 2008 -0700
cpusets: restructure the function update_cpumask() and update_nodemask()
It might happen that 'echo 0 > /cpuset/sub/cpus' returned failure but 'cpus'
has been changed, because cpus was changed before calling heap_init() which
may return -ENOMEM.
This patch restores the orginal behavior.
Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
Acked-by: Paul Menage <menage@google.com>
Cc: Paul Jackson <pj@sgi.com>
Cc: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
akpm: these have no callers at this time, but they shall soon, so let's
get them right.
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Print parent directory name as well.
The aim is to catch non-creation of parent directory when proc_mkdir will
return NULL and all subsequent registrations go directly in /proc instead
of intended directory.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
[ Fixed insane printk string while at it. - Linus ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I recently bought 3 HGST P7K500-series 500GB SATA drives and
had trouble accessing the block right on the LBA28-LBA48 border.
Here's how it fails (same for all 3 drives):
# dd if=/dev/sdc bs=512 count=1 skip=268435455 > /dev/null
dd: reading `/dev/sdc': Input/output error
0+0 records in
0+0 records out
0 bytes (0 B) copied, 0.288033 seconds, 0.0 kB/s
# dmesg
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: BMDMA stat 0x25
ata1.00: cmd c8/00:08:f8:ff:ff/00:00:00:00:00/ef tag 0 dma 4096 in
res 51/04:08:f8:ff:ff/00:00:00:00:00/ef Emask 0x1 (device error)
ata1.00: status: { DRDY ERR }
ata1.00: error: { ABRT }
ata1.00: configured for UDMA/33
ata1: EH complete
...
After some investigations, it turned out this seems to be caused
by misinterpretation of the ATA specification on LBA28 access.
Following part is the code in question:
=== include/linux/ata.h ===
static inline int lba_28_ok(u64 block, u32 n_block)
{
/* check the ending block number */
return ((block + n_block - 1) < ((u64)1 << 28)) && (n_block <= 256);
}
HGST drive (sometimes) fails with LBA28 access of {block = 0xfffffff,
n_block = 1}, and this behavior seems to be comformant. Other drives,
including other HGST drives are not that strict, through.
>From the ATA specification:
(http://www.t13.org/Documents/UploadedDocuments/project/d1410r3b-ATA-ATAPI-6.pdf)
8.15.29 Word (61:60): Total number of user addressable sectors
This field contains a value that is one greater than the total number
of user addressable sectors (see 6.2). The maximum value that shall
be placed in this field is 0FFFFFFFh.
So the driver shouldn't use the value of 0xfffffff for LBA28 request
as this exceeds maximum user addressable sector. The logical maximum
value for LBA28 is 0xffffffe.
The obvious fix is to cut "- 1" part, and the patch attached just do
that. I've been using the patched kernel for about a month now, and
the same fix is also floating on the net for some time. So I believe
this fix works reliably.
Just FYI, many Windows/Intel platform users also seems to be struck
by this, and HGST has issued a note pointing to Intel ICH8/9 driver.
"28-bit LBA command is being used to access LBAs 29-bits in length"
http://www.hitachigst.com/hddt/knowtree.nsf/cffe836ed7c12018862565b000530c74/b531b8bce8745fb78825740f00580e23
Also, *BSDs seems to have similar fix included sometime around ~2004,
through I have not checked out exact portion of the code.
Signed-off-by: Taisuke Yamada <tai@rakugaki.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Enable LED blinking.
Signed-off-by: Bob Stewart <bob@evoria.net>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
drivers/ata/ata_piix.c:1502:7: warning: symbol 'rc' shadows an earlier one
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
PCI_DMA_BUS_IS_PHYS was defined to be zero, which meant we ignored
the DMA mask for IDE and SCSI transfers. This is wrong - we have
no DMA translation hardware. We want to obey DMA masks so that the
block layer performs bouncing itself.
Reported-by: Mikael Pettersson <mikpe@it.uu.se>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Dmitry Baryshkov <dbaryshkov@gmail.com>
Acked-by: Eric Miao <eric.miao@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Add clock alias for clock that is used by tc6393xb device on tosa.
As that chip plays pretty major part in tosa life and is currently
disabled, this is 2.4.27 material.
Signed-off-by: Dmitry Baryshkov <dbaryshkov@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Fix warning when compiling "drivers/pcmcia/soc-common.c"
The return value of the function "device_create_file"
was not used / assigned.
Signed-off-by: Jrgen Schindele <linux@schindele.name>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Print out for device BAR values before the kernel tries to update them.
Also make related output use KERN_DEBUG.
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
The reset_task function in the niu driver does not reset the tx and rx
buffers properly. This leads to panic on reset. This patch is a
modified implementation of the previously posted fix.
Signed-off-by: Santwona Behera <santwona.behera@sun.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
As noticed by Russell King, we were not setting this properly
to the number of entries, but rather the total size.
This results in the core dumping code allocating waayyyy too
much memory.
Signed-off-by: David S. Miller <davem@davemloft.net>
We need to pass IRQF_SHARED, otherwise we get things like:
IRQ handler type mismatch for IRQ 33
current handler: PSYCHO_UE
Call Trace:
[000000000048394c] request_irq+0xac/0x120
[00000000007c5f6c] psycho_scan_bus+0x98/0x158
[00000000007c2bc0] pcibios_init+0xdc/0x12c
[0000000000426a5c] do_one_initcall+0x1c/0x160
[00000000007c0180] kernel_init+0x9c/0xfc
[0000000000427050] kernel_thread+0x30/0x60
[00000000006ae1d0] rest_init+0x10/0x60
on e3500 and similar systems.
On a single board, the UE interrupts of two Psycho nodes
are funneled through the same interrupt, from of_debug=3
dump:
/pci@b,4000: direct translate 2ee --> 21
...
/pci@b,2000: direct translate 2ee --> 21
Decimal "33" mentioned above is the hex "21" mentioned here.
Thanks to Meelis Roos for dumps and testing.
Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller