... otherwise we might try to load a bitmap from an array which hasn't one.
The bug is that if you create an array with an internal bitmap, shut it down,
and then create an array with the same md device, the md drive will assume it
should have a bitmap too. As the array can be created with a different md
device, it is mostly an inconvenience. I'm pretty sure there is no risk of
data corruption.
Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The error path in pnp_request_card_device() is broken (one variable is
left initialized and the semaphore is not unlocked).
This fixes it (and has been tested).
Signed-off-by: Jaroslav Kysela <perex@suse.cz>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Add platform device data for the SA11x0 MCP device. This allows
platforms to customise the configuration of the SA11x0 MCP device
according to their needs.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Add support for the core of the multimedia communication port
framework. This is a port used to communicate with devices
with two DMA paths and a control path.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Fix for manual binding of drivers to devices. Problem is if you pass in
a valid device id, but the driver refuses to bind. Infinite loop as
write() tries to resubmit the data it just sent.
Thanks to Michal Ostrowski <mostrows@watson.ibm.com> for pointing the
problem out.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
New driver for the Marvell Yukon2 Gigabit Ethernet chipset.
This driver is based on the skge driver, but using the logic
from the SysKonnect version of the sk98lin driver.
It should support all the Yukon2 chipsets that are available
in many current Intel and AMD motherboards.
The driver does support ethtool, tx and rx checksum, and
tcp segmentation offload. But it has only been tested for
a short while and is known to stop receiving under heavy load.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
03_sil24_add-pci-fault-check.patch
On entry to interrupt handler, PORT_SLOT_STAT register is read
first. Check if PCI fault or device removal has occurred by
testing the value for 0xffffffff.
Signed-off-by: Tejun Heo <htejun@gmail.com>
sata_sil24.c | 6 ++++++
1 files changed, 6 insertions(+)
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
02_sil24_remove-irq-disable-on-spurious-intr.patch
If interrupt occurs on a disabled port, the driver used to
mask the port's interrupt, but we don't know if such action is
necessary yet and that's not what other drives do. So, just
do nothing and tell IRQ subsystem that it's not our interrupt.
Signed-off-by: Tejun Heo <htejun@gmail.com>
sata_sil24.c | 15 +++++----------
1 files changed, 5 insertions(+), 10 deletions(-)
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
On the 6700/6702 PXH part, a MSI may get corrupted if an ACPI hotplug
driver and SHPC driver in MSI mode are used together.
This patch will prevent MSI from being enabled for the SHPC as part of
an early pci quirk, as well as on any pci device which sets the no_msi
bit.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This moves the code to free devt_attr from class_device_del() to
class_dev_release() which is called after the last reference to the
corresponding kobject() is gone.
This allows us to keep the devt_attr alive while the corresponding
sysfs file is open.
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The flush threshold in the MAC chip should be increased.
Found while reviewing vendor version of sk98lin driver.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Some versions of the Marvell yukon generate bogus sensor warning interrupts.
The driver would flood log with these messages. Handle this situation
cleanly by masking away at boot time.
Fixes: http://bugs.gentoo.org/show_bug.cgi?id=87182
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
drivers/net/skge.c | 24 ++++++++++--------------
drivers/net/skge.h | 8 ++++++--
2 files changed, 16 insertions(+), 16 deletions(-)
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
This adds initial r300 3D support to the radeon DRM.
From: Nicolai Haehnle, Vladimir Dergachev, and others.
Signed-off-by: David Airlie <airlied@linux.ie>
It's been pointed out that environmental events from the system
controllers on Altix machines cause the kernel to complain about
unaligned memory accesses. This turns out to be because
"be32_to_cpup()" didn't do everything I thought/hoped it did.
I've added calls to pull the offending integers out of the
buffers using get_unaligned() before feeding them to
be32_to_cpup().
Signed-off-by: Greg Howard <ghoward@sgi.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Reported by: Pavel Kysilka (Bugzilla Bug 5059)
The intelfb driver does not keep resolution set with fbset after
switching to anot console and back.
Steps to reproduce:
initial options: tty1,tty2 - 1024x768-60
1) tty1 - fbset after booting (1024x768-60)
2) tty1 - fbset 800x600-100
tty1: 800x600-100
3) swith to tty2, swith to tty1
tty1: 1024x768-60 (the same resolution as default from kernel booting)
This bug is caused by intelfb unintentionally destroying info->flags in
set_par(). Therefore the flag, FBINFO_MISC_USEREVENT used to notify
fbcon of a mode change was cleared causing the above problem. This bug
though is not intelfb specific, as other drivers may also be affected.
The fix is to save info->flags in a local variable before calling any
of the driver hooks. A more definitive fix (for post 2.6.13) is to
separate info->flags into one that is set by the driver and another that
is set by core fbdev/fbcon.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Reported by: Pavel Kysilka (Bugzilla Bug 4738)
modprobe of intelfb results in the following error message:
intelfb: Framebuffer driver for Intel(R) 830M/845G/852GM/855GM/865G/915G chi
intelfb: Version 0.9.2
ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 16
allocation failed: out of vmalloc space - use vmalloc=<size> to increase siz
intelfb: Cannot remap FB region.
This will fail if the graphics aperture size is greater than 128 MB.
Fix is to ioremap only from the beginning of graphics aperture to the
end of the used framebuffer memory.
Signed-off-by: Sylvain Meyer <sylvain.meyer@worldonline.fr>
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
remove lots of completely dead code from aiclib, there's not a lot left
and even what's left is rather useless.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
remove ahd_tailq and do sane pci probing. ported over from aic7xxx.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
remove some dead cruft, as done already in aic7xxx
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Replace remaining WLAN_FC_* defines with the ones used in ieee80211
header file. This completes the move from hostap version of frame
control field processing to ieee80211 version.
Signed-off-by: Jouni Malinen <jkmaline@cc.hut.fi>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Remove backwards compatibility define for WLAN_CAPABILITY_ESS now that
net/ieee80211.h defines this.
Signed-off-by: Jouni Malinen <jkmaline@cc.hut.fi>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
IEEE 802.11 has a capability field flag called ESS, but ieee80211 had
renamed this to BSS for some reason. hostap has been using
WLAN_CAPABILITY_ESS and since that matches with the standard, lets use
it as the name for this define. Add WLAN_CAPABILITY_BSS as a backwards
compatibility name for the same bit since ieee80211 and ipw2200 are
using this and there are versions outside kernel tree that expect to
find this define name.
Signed-off-by: Jouni Malinen <jkmaline@cc.hut.fi>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
