The C99 specification states in section 6.11.5:
The placement of a storage-class specifier other than at the
beginning of the declaration specifiers in a declaration is an
obsolescent feature.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
Minor cleanups to the OMAP RNG:
- Comment update re RNG status:
* yes, it works on 16xx; "rngtest" is quite happy
* it's fast enough that polling vs IRQ is a non-issue
- Get rid of BUG_ON
- Help GCC not be stupid about inlining (object code shrink)
- Remove "sparse" warning
- Cope with new hotplug rule requiring "platform:" modalias
And make the file header match kernel conventions.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The struct class_device *dev_class is not used in the struct drm_head
structure at all, so remove it as class_device is being removed entirely
from the kernel.
Cc: David Airlie <airlied@linux.ie>
Cc: Tony Jones <tonyj@suse.de>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
After 2.6.24 there was a plan to make the PM core acquire all device
semaphores during a suspend/hibernation to protect itself from
concurrent operations involving device objects. That proved to be
too heavy-handed and we found a better way to achieve the goal, but
before it happened, we had introduced the functions
device_pm_schedule_removal() and destroy_suspended_device() to allow
drivers to "safely" destroy a suspended device and we had adapted some
drivers to use them. Now that these functions are no longer necessary,
it seems reasonable to remove them and modify their users to use the
normal device unregistration instead.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch fixes the following compile error:
<-- snip -->
...
CC [M] drivers/char/genrtc.o
/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/char/genrtc.c:58:21: error: asm/rtc.h: No such file or directory
...
make[3]: *** [drivers/char/genrtc.o] Error 1
<-- snip -->
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
This patch fixes the following compile error:
<-- snip -->
...
CC [M] drivers/char/rtc.o
In file included from /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/char/rtc.c:70:
/home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/mc146818rtc.h:16:59: error: asm/mc146818rtc.h: No such file or directory
...
make[3]: *** [drivers/char/rtc.o] Error 1
<-- snip -->
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
This patchs adds the AVR32 architecture to the list of archs to generate a
table of raw keyboard keycodes.
Signed-off-by: Hans-Christian Egtvedt <hcegtvedt@atmel.com>
Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
None of these files use any of the functionality promised by
asm/semaphore.h. It's possible that they rely on it dragging in some
unrelated header file, but I can't build all these files, so we'll have
fix any build failures as they come up.
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
polled console handling support, to access a console in an irq-less
way while in debug or irq context.
absolutely zero impact as long as CONFIG_CONSOLE_POLL is disabled.
(which is the default)
[ jan.kiszka@siemens.com: lots of cleanups ]
[ mingo@elte.hu: redesign, splitups, cleanups. ]
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Jan Kiszka <jan.kiszka@web.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
The api for hardware random number generators is currently limited to
devices that never fail. If the hardware is registered as a source for
random numbers it has to work. This prevents the use of i/o based
random number devices where the i/o might fail.
Add a check for errors after the read from a hardware random number device.
This patch is required to support large random numbers retrieved
from the CEX2C cards on System z.
Signed-off-by: Ralph Wuerthner <rwuerthn@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
This fixes a potential bug at drivers/char/hvc_beat.c.
- hvc_put_term_char routine will decrement "rest" variable twice,
and forget to advance "buf" pointer by "nlen" bytes.
This bug was not hit previously because the output handler in
drivers/char/hvc_console.c splits given output into 16 bytes
at maximum.
Reported-by: Timur Tabi <timur@freescale.com>
Signed-off-by: Kou Ishizaki <kou.ishizaki@toshiba.co.jp>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Now that we're mapping registers in the DRM driver at load time, the
driver actually checks the PCI ID, so we need to make sure the macros
have all the right bits (and longer term use the DRM headers as the sole
copy of the PCI & register definitions).
This patch adds 945GME support to the DRM headers, fixing a regression
reported in http://bugzilla.kernel.org/show_bug.cgi?id=10395.
Tested-by: Alexander Oltu <alexander@all-2.com>
Signed-off-by: Jesse Barnes <jesse.barnes@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The commits:
commit 37a47db8d7
Author: Balaji Rao <balajirrao@gmail.com>
Date: Wed Jan 30 13:30:03 2008 +0100
x86: assign IRQs to HPET timers, fix
and
commit e3f37a54f6
Author: Balaji Rao <balajirrao@gmail.com>
Date: Wed Jan 30 13:30:03 2008 +0100
x86: assign IRQs to HPET timers
have been identified to cause a regression on some platforms due to
the assignement of legacy IRQs which makes the legacy devices
connected to those IRQs disfunctional.
Revert them.
This fixes http://bugzilla.kernel.org/show_bug.cgi?id=10382
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Add some locks and unlocks to some code paths.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Unlock two grabbed locks on some paths.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
aka if you see a force-cast, be very suspicious...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Acked-and-tested-by: Frank Seidel <fseidel@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch fixes bits of the DRM so to make the radeon DRI work on
non-cache coherent PCI DMA variants of the PowerPC processors.
It moves the few places that needs change to wrappers to that
other architectures with similar issues can easily add their
own changes to those wrappers, at least until we have more useful
generic kernel API.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Dave Airlie <airlied@linux.ie>
drivers/char/drm/radeon_mem.c:91:23: warning: Using plain integer as NULL pointer
drivers/char/drm/radeon_mem.c:116:28: warning: Using plain integer as NULL pointer
drivers/char/drm/radeon_mem.c:124:28: warning: Using plain integer as NULL pointer
drivers/char/drm/radeon_mem.c:177:26: warning: Using plain integer as NULL pointer
drivers/char/drm/radeon_mem.c:177:53: warning: Using plain integer as NULL pointer
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Dave Airlie <airlied@linux.ie>
This interface was originally designed wrong, confusing bit-fields and
integers, major brown paper bag going back many years...
But userspace only ever used 4 values so fix the interface for new
users and fix the implementation to deal with the 4 values userspace
has ever emitted (0x1, 0x2, 0x3, 0x6).
Signed-off-by: Dave Airlie <airlied@redhat.com>
drivers/char/drm/ati_pcigart.c: In function 'drm_ati_pcigart_init':
drivers/char/drm/ati_pcigart.c:125: warning: format '%08X' expects type 'unsigned int', but argument 3 has type 'dma_addr_t'
Cc: Dave Airlie <airlied@linux.ie>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Major 259 has been assigned by lanana. Use it. Also, publish
/dev/icap[0-k] as the device entries, and register platform devices
named 'icap' to be consistent.
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
It appears that in some cases, the sync word might not be recognized
by the hardware correctly. If this happens, then attempting to read
from the port results in an unrecoverable error because of the design
of the FPGA core. This patch updates the code to check the status of
the device before reading the IDCODE, in order to avoid entering this
unrecoverable state. This patch also adds additional NOOP commands
into the sychronization sequence, which appears to be necessary to
avoid the condition on some hardware.
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Both the buffer-based and fifo-based icap cores have a status
register. Previously, this was only used internally to check whether
transactions have completed. However, the status can be useful to the
main driver as well. This patch exposes these status functions to the
main driver along with some masks for the differnet bits.
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Update documentation for the hw_random support to be current:
- Documentation/hw_random.txt has been updated to reflect the
current code: it's a framework now, a "core" with a small
sysfs interface, that hardware-specific drivers plug in to.
Text specific to Intel hardware is now at the end.
- Kconfig now references the Documentation/hw_random.txt file
and better explains what this really does.
Both chunks of documentation now higlight the fact that the kernel entropy
pool is maintained by "rngd", and this driver has nothing directly to do with
that important task.
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>
unsigned long != __le32, TYVM, and unsigned char[4] is not guaranteed
to be aligned for u32.
While we are at it, sanitize sOutDW() a bit - have it take Byte_t * and
handle dereferencing internally.
NB: sWriteTxPrioByte() is almost certainly buggered on big-endian and is
missing cpu_to_le16() on assignments to *WordPtr; I've left it alone for now.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Acked-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This fixes a problem on 64-bit with 4GB with ATI RS690 chipsets. It
makes sure the pcigart table is allocated in coherent memory for DMA operations.
Signed-off-by: Dave Airlie <airlied@redhat.com>
It's worth remembering that all new bright ideas on how to make this command reader work properly and according to docs will probably fail :( Bring in some old code.
Also allow a larger SG-DMA download stride, and remove unnecessary waits for
command regulators pauses.
Signed-off-by: Dave Airlie <airlied@redhat.com>
The i915_vblank_swap() function schedules an automatic buffer swap
upon receipt of the vertical sync interrupt. Such an operation is
lengthy so it can't be allowed to happen in normal interrupt context,
thus the DRM implements this by scheduling the work in a kernel
softirq-scheduled tasklet. In order for the buffer swap to work
safely, the DRM's central lock must be taken, via a call to
drm_lock_take() located in drivers/char/drm/drm_irq.c within the
function drm_locked_tasklet_func(). The lock-taking logic uses a
non-interrupt-blocking spinlock to implement the manipulations needed
to take the lock. This semantic would be safe if all attempts to use
the spinlock only happen from process context. However this buffer
swap happens from softirq context which is really a form of interrupt
context. Thus we have an unsafe situation, in that
drm_locked_tasklet_func() can block on a spinlock already taken by a
thread in process context which will never get scheduled again because
of the blocked softirq tasklet. This wedges the kernel hard.
To trigger this bug, run a dual-head cloned mode configuration which
uses the i915 drm, then execute an opengl application which
synchronizes buffer swaps against the vertical sync interrupt. In my
testing, a lockup always results after running anywhere from 5 minutes
to an hour and a half. I believe dual-head is needed to really
trigger the problem because then the vertical sync interrupt handling
is no longer predictable (due to being interrupt-sourced from two
different heads running at different speeds). This raises the
probability of the tasklet trying to run while the userspace DRI is
doing things to the GPU (and manipulating the DRM lock).
The fix is to change the relevant spinlock semantics to be the
interrupt-blocking form. After this change I am no longer able to
trigger the lockup; the longest test run so far was 20 hours (test
stopped after that point).
Note: I have examined the places where this spinlock is being
employed; all are reasonably short bounded sequences and should be
suitable for interrupts being blocked without impacting overall kernel
interrupt response latency.
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
In riscom8_init_module, rc_board should be indexed by i, not by 0, otherwise
the loop is useless.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Due to some flaws in the initialization and flow control
code kernel oopses could be triggered e.g. when accessing
the card too early after insertion.
See e.g. kernel.org bug #10077.
The main part of the fix is a trivial state management
making sure the card is realy ready to use before allowing
any access.
Signed-off-by: Frank Seidel <fseidel@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This has been around for a while but nobody reported it until recently.
Resubmitting the fix as it's appropriate for 2.6.25
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
randconfig testing found a bootup lockup in drivers/char/esp.c because
of a spinlock that wasn't correctly initialized.
I'm not sure why it became more prominent in 2.6.25-rc4, the bug seems
rather old and i've been doing allyesconfig bootups for ages with
CONFIG_ESP enabled.
This fixes this bootup lockup:
PM: Adding info for No Bus:ttyP63
ttyP32 at 0x0240 (irq = 0) is an ESP primary port
BUG: spinlock lockup on CPU#0, swapper/1, f56dd004
Pid: 1, comm: swapper Not tainted 2.6.25-rc4-sched-devel.git-x86-latest.git #402 [<c03ac6f4>] _raw_spin_lock+0x134/0x140
[<c08649be>] _spin_lock_irqsave+0x5e/0x80
[<c0b9fbfe>] ? espserial_init+0x2be/0x6e0
[<c0b9fbfe>] espserial_init+0x2be/0x6e0
[<c0b877a3>] kernel_init+0x83/0x260
[<c0b9f940>] ? espserial_init+0x0/0x6e0
[<c010416a>] ? restore_nocheck_notrace+0x0/0xe
[<c0b87720>] ? kernel_init+0x0/0x260
[<c0b87720>] ? kernel_init+0x0/0x260
[<c0104507>] kernel_thread_helper+0x7/0x10
=======================
kzalloc() is not the way to initialize spinlocks anymore.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In commit e6bafba5b4 ("wmi: (!x & y)
strikes again"), a bug was fixed that involved converting !x & y to !(x
& y). The code below shows the same pattern, and thus should perhaps be
fixed in the same way.
This is not tested and clearly changes the semantics, so it is only
something to consider.
The semantic patch that makes this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@@ expression E1,E2; @@
(
!E1 & !E2
|
- !E1 & E2
+ !(E1 & E2)
)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Cc: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
VT notifier callbacks need to be aware of console switches. This is already
partially done from console_callback(), but at that time fg_console, cursor
positions, etc. are not yet updated and hence screen readers fetch the old
values.
This adds an update notify after all of the values are updated in
redraw_screen(vc, 1).
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Oddly enough, unsigned int c = '\300'; puts a "negative" value in c, not
0300... This fixes the default unicode compose table by using integers
instead of character constants.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix hpet_(un)register_irq_handler() for when CONFIG_HPET_EMULATE_RTC=n. They
are provided macros that substitute value 0, but if they are called as
functions and the return value isn't checked, the following warnings appear:
drivers/char/rtc.c: In function `rtc_init':
drivers/char/rtc.c:1063: warning: statement with no effect
drivers/char/rtc.c: In function `rtc_exit':
drivers/char/rtc.c:1157: warning: statement with no effect
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This fixes various items pointed out during a review of the hwicap driver.
Primarily, reversed memcpy calls, re-entrancy issues, and mutex conversion
have been addressed. There are also fixes to comments to use the kerneldoc
format, as well as some sparse annotations.
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Make sure the restoration correctly restores the AR registers by
flipping the ARX register into index mode before doing anything.
Without this, some people have had the text mode restore all green.
Signed-off-by: Jesse Barnes <jesse.barnes@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Tobias Klauser