* master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6:
PCI: Add Kconfig option to disable deprecated pci_find_* API
PCI: pciserial_resume_one ignored return value of pci_enable_device
PCI Hotplug: cpqhp_pushbutton_thread(): remove a pointless if() check
PCI: make pci_match_device() static
PCI: Remove 3 incorrect MSI quirks.
PCI: Add MSI INTX_DISABLE quirks for ATI SB700/800 SATA and IXP SB400 USB
PCI: Add quirk for devices which disable MSI when INTX_DISABLE is set.
PCI: Add MSI quirk for ServerWorks HT1000 PCIX bridge.
PCI: Revert "PCI: disable MSI by default on systems with Serverworks HT1000 chips"
David Brownell [Wed, 31 Oct 2007 09:37:37 +0000 (10:37 +0100)]
leds: bugfixes for leds-gpio
Three bugfixes to the leds-gpio driver, plus minor whitespace tweaks:
- Do the INIT_WORK() before registering each LED, so if its trigger
becomes immediately active it can schedule work without oopsing..
- Use normal registration, not platform_driver_probe(), so that
devices appearing "late" (hotplug type) can still be bound.
- Mark the driver remove code as "__devexit", preventing oopses
when the underlying device is removed.
These issues came up when using this driver with some GPIO expanders
living on serial busses, which act unlike "normal" platform devices:
they can appear and vanish along with the serial bus driver.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
David Miller [Thu, 25 Oct 2007 08:17:16 +0000 (01:17 -0700)]
PCI: Remove 3 incorrect MSI quirks.
Now that we have dealt with the real issue, in that some ATI SATA and
USB controllers needed the INTX_DISABLE quirk, we can remove these AMD
chipset global MSI disabling quirks.
This is based upon testing and feedback from
Shane Huang <Shane.Huang@amd.com>.
Cc: Shane Huang <Shane.Huang@amd.com> Signed-off-by: David S. Miller <davem@davemloft.net> Acked-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David Miller [Thu, 25 Oct 2007 08:16:30 +0000 (01:16 -0700)]
PCI: Add quirk for devices which disable MSI when INTX_DISABLE is set.
A reasonably common problem with some devices is that they will
disable MSI generation when the INTX_DISABLE bit is set in the
PCI_COMMAND register.
Quirk this explicitly, guarding the pci_intx() calls in msi.c with
this quirk indication.
The first entries for this quirk are for 5714 and 5780 Tigon3 chips,
and thus we can remove the workaround code from the tg3.c driver.
Signed-off-by: David S. Miller <davem@davemloft.net> Acked-by: Michael Chan <mchan@broadcom.com> Acked-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
"PCI: disable MSI by default on systems with Serverworks HT1000 chips"
was not entirely correct, and has been reverted.
MSI does not work on the PCIX bus because the BIOS did not set the
HT_MSI_FLAGS_ENABLE bit in the HyperTransport MSI capability on the
bridge. We use the existing quirk_msi_ht_cap() to detect the problem
and disable MSI in all buses behind it.
Signed-off-by: Michael Chan <mchan@broadcom.com> Cc: Anantha Subramanyam <ananth@broadcom.com> Cc: Naren Sankar <nsankar@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> Acked-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ide: fix IDE_HFLAG_NO_ATAPI_DMA handling in config_drive_for_dma()
commit 33c1002ed912ac9dacedd5d5b166da3b72d18460 incorrectly changed return
value from '0' to '-1', fix it (ns87415 was the only host driver affected
since it uses both IDE_HFLAG_TRUST_BIOS_FOR_DMA and IDE_HFLAG_NO_ATAPI_DMA).
drive_cmd_intr() is used by both REQ_TYPE_ATA_CMD and REQ_TYPE_ATA_TASK
but commands using PIO-in protocol are valid only for REQ_TYPE_ATA_CMD
(&args[4] in case of REQ_TYPE_ATA_TASK points to a value for IDE_LCYL_REG
register instead of the data buffer). This fix allows REQ_TYPE_ATA_TASK
commands to use non-zero values for IDE_SECTOR_REG (args[3]).
This config option is effective only for host drivers that use
IDE_HFLAG_OFF_BOARD host flag (aec62xx, generic, hpt34x, hpt366,
pdc202xx_new, pdc202xx_old and tc86c001).
sebdeg@ngi.it [Mon, 5 Nov 2007 20:42:25 +0000 (21:42 +0100)]
piix: add support for ICH7 on Acer 5602aWLMi
In piix.c (and in ata_piix.c) are already included some patches to skip the
cable check on some laptops and to enable UDMA > 33 modes, but I've noticed
than theese doesn't work on my Acer Aspire 5602WLMi (maybe exist more
versions of this laptop). With this simple patch I can set transfer mode
to UDMA100.
From: "sebdeg@ngi.it" <sebdeg@ngi.it> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: Alan Cox <alan@redhat.com> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Linus Torvalds [Mon, 5 Nov 2007 19:39:25 +0000 (11:39 -0800)]
Merge branch 'for-linus' of git://git390.osdl.marist.edu/pub/scm/linux-2.6
* 'for-linus' of git://git390.osdl.marist.edu/pub/scm/linux-2.6:
[S390] tod clock: announce clocksource as perfect
[S390] Rename "idle_time" attribute to "idle_time_us".
[S390] Fix priority mistakes in drivers/s390/cio/cmf.c
[S390] Fix memory detection.
[S390] Fix compile on !CONFIG_SMP.
[S390] device_schedule_callback() for dcssblk.
[S390] Fix smsgiucv init on no iucv machines
[S390] cio: use INIT_WORK to initialize struct work.
Linus Torvalds [Mon, 5 Nov 2007 19:39:00 +0000 (11:39 -0800)]
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-lguest
* 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-lguest:
lguest: tidy up documentation
kernel/futex.c: make 3 functions static
unexport access_process_vm
lguest: make async_hcall() static
Commit f2a0bd3753dad7ea4605ebd5435716b39e9f92bb defines the function
with "void cpm_load_patch(cpm8xx_t *cp)" prtotype and is declared as
"extern void cpm_load_patch(volatile immap_t *immr)" in the header file.
Fix the memory leak that may occur when we attempt to reuse a cpu_slab
that was allocated while we reenabled interrupts in order to be able to
grow a slab cache.
The per cpu freelist may contain objects and in that situation we may
overwrite the per cpu freelist pointer loosing objects. This only
occurs if we find that the concurrently allocated slab fits our
allocation needs.
If we simply always deactivate the slab then the freelist will be
properly reintegrated and the memory leak will go away.
The Time of Day clock is the standard time source for s390. It is
- monotonic
- allows very fast reading
- architecture guarantees at least microsecond stepping
- available as part of the architecture
We should announce the rate of tod as 400 to be in sync with the
description found in clocksource.h:
"400-499:Perfect The ideal clocksource. A must-use where available."
This change will prefer tod over less reliable clock sources.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
# cat /sys/devices/system/cpu/cpu0/idle_time 131473592 us
Cc: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Heiko Carstens [Mon, 5 Nov 2007 10:10:11 +0000 (11:10 +0100)]
[S390] Fix memory detection.
Yet another patch in the countless series of memory detection fixes:
if the last area of the reported storage size is a hole the detection
loop will loop forever.
Just break chunk detection loop if its end is going to be larger than
reported storage size.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Heiko Carstens [Mon, 5 Nov 2007 10:10:10 +0000 (11:10 +0100)]
[S390] Fix compile on !CONFIG_SMP.
Commit fae8b22d3e3e3a3d317a7746493997af02a3f35c
"[S390] Add per-cpu idle time / idle count sysfs attributes" causes
a link error on !CONFIG_SMP.
Fix this by adding some #ifdef's. Real fix would be to cleanup the
code since we don't register a cpu on !CONFIG_SMP. But that would
be quite a big patch. For the time being this is good enough.
arch/s390/kernel/built-in.o: In function `do_monitor_call':
(.text+0x50d4): undefined reference to `per_cpu__s390_idle'
arch/s390/kernel/built-in.o: In function `cpu_idle':
(.text+0x518c): undefined reference to `per_cpu__s390_idle'
make: *** [.tmp_vmlinux1] Error 1
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Gerald Schaefer [Mon, 5 Nov 2007 10:10:09 +0000 (11:10 +0100)]
[S390] device_schedule_callback() for dcssblk.
Unregistering a device from within a device attribute handler leads to
a deadlock. Need to use device_schedule_callback() to unregister device
in error path.
Signed-off-by: Gerald Schaefer <geraldsc@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
smsgiucv is a driver that relies on iucv to work properly. If
iucv ans smsgiucv are compiled into the kernel and run on an
lpar the following scenario happens:
iucv is initialized early as a subsystem. It checks for z/VM and
returns with EPROTONOTSUPPORT. Later smsgiucv tries to run
driver_register with iucv_bus as bus. As this bus is not
initialized the driver core and list debugging issue several
warnings and oopses.
Solution is to let smsgiucv also check for z/VM and return
EPROTONOTSUPPORT as well.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Heiko Carstens [Mon, 5 Nov 2007 10:10:07 +0000 (11:10 +0100)]
[S390] cio: use INIT_WORK to initialize struct work.
Use INIT_WORK to initialize struct work and don't initialize a
struct work partial by explicitly initializing its private structures.
Fixes the following lockdep bug because no key was assigned:
Linus Torvalds [Mon, 5 Nov 2007 02:00:35 +0000 (18:00 -0800)]
Merge branch 'drm-patches' of master.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6
* 'drm-patches' of master.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm/sis: missing mutex unlock in error path.
radeon: set the address to access the GART table on the CPU side correctly
Dave Airlie [Mon, 5 Nov 2007 00:45:27 +0000 (10:45 +1000)]
radeon: set the address to access the GART table on the CPU side correctly
This code relied on the CPU and GPU address for the aperture being the same,
On some r5xx hardware I was playing with I noticed that this isn't always true.
This fixes issues seen on some r400 cards. (bugs.freedesktop.org 9957)
Mike Isely [Sat, 3 Nov 2007 03:06:42 +0000 (00:06 -0300)]
V4L/DVB (6548): pvrusb2: Fix oops on module removal
The pvrusb2 driver is tearing down its sysfs related pieces in the
incorrect order. This leaves dangling pointers which causes the
kernel device core to oops. The problem has been present virtually
forever but became malignant with the changeover to the way of
handling /sys/class. Fix is just to make sure we don't tear down the
class structure until AFTER the driver instances are deregistered.
Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Trent Piepho [Thu, 1 Nov 2007 04:16:09 +0000 (01:16 -0300)]
V4L/DVB (6514): em28xx: Include linux/mm.h
This em28xx-video.c uses functions from this header, but doesn't include it.
It depends on some v4l headers included two levels down including poll.h,
which includes mm.h.
These v4l headers might change, so it's best to include the headers needed
directly.
It also causes problems for the out of core build system's backward
compatibility with older kernels, which is the real reason I bothered to
create a patch for something that would otherwise be so minor that it would
hardly be worth the trouble.
Trent Piepho wrote:
> I do not think the saa7134-alsa driver supports mmap. The cx88-alsa driver
> also claimed to support mmap, but it never worked until I fixed it. It's
> pretty clear that the code in saa7134-alsa was based on the same code as
> cx88-alsa, so it's likely it has the same bug.
You are right. The patch below (based on your cx88 patch, but I don't
really understand it) fixes mmap support in saa7134-alsa for me.
Recording via mmap (arecord -M -f S16_LE -c 2 -r 32000 -D hw:1) didn't
work at all before, works now, tested for at least 20 minutes (but,
unfortunately, with one overrun at least 0.719 ms long).
Signed-off-by: Alexander E. Patrakov <patrakov@ums.usu.ru> Acked-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Trent Piepho <xyzzy@speakeasy.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Mike Isely [Mon, 29 Oct 2007 01:19:53 +0000 (22:19 -0300)]
V4L/DVB (6504): pvrusb2: Remove dead sysfs code
The pvrusb2 driver's sysfs implementation had long since implemented a
dummy hotplug function because at the time the kernel would oops
without at least the empty function being present. Today - after
numerous class interface changes in the kernel - this pvrusb2 change
had been dutifully carried forward but an inspection of the kernel
sources shows that it is no longer needed. So remove the dummy
function and its reference. This also solves a recurring backwards
compatibility issue in the pvrusb2 driver as the class interface has
been getting thrashed in the kernel.
Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Hartmut Birr [Wed, 31 Oct 2007 05:04:16 +0000 (02:04 -0300)]
V4L/DVB (6501): stv0297: Signal strength fixes
Fixes the signal strength value (higher value = higher signal strength)
and scales the value to the range of 0..ffff. The characteristic itself
is wrong. To get proper values on a TT-C2300 in the range of 40..60%
real signal strength, the values from the patch should be divide by two.
The attached patch doesn't fix the characteristic.
Oliver Endriss [Wed, 31 Oct 2007 04:34:25 +0000 (01:34 -0300)]
V4L/DVB (6498): ves1820: Change the acquisition range for clock recovery from 120 ppm to 240ppm
Change the acquisition range for clock recovery from 120 ppm to
240ppm. Apparently, some cable providers in Germany are playing with
their parameters, and the capture range of the ves1820 is too small
to acquire a lock with the current setting... ;-(
Signed-off-by: Oliver Endriss <o.endriss@gmx.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Two fixes for the 'saa7146_wait_for_debi_done' code:
(a) Timeout did not work when the routine was called with
interrupts disabled.
(b) Reduce PCI I/O load caused by saa7146_wait_for_debi_done.
Seems to be very important on fast machines!
Based on code posted by Hartmut Birr @vdr-portal.
Signed-off-by: Oliver Endriss <o.endriss@gmx.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Randy Dunlap [Mon, 29 Oct 2007 18:19:55 +0000 (15:19 -0300)]
V4L/DVB (6479): use input functions, should depend on INPUT
All of these drivers select VIDEO_IR, which uses the input subsystem,
so they should also depend on INPUT.
Problem examples:
drivers/built-in.o: In function `ir_input_key_event':
ir-functions.c:(.text+0x10849a): undefined reference to `input_event'
ir-functions.c:(.text+0x1084ac): undefined reference to `input_event'
drivers/built-in.o: In function `saa7134_set_i2c_ir':
(.text+0x11cc0a): undefined reference to `get_key_pinnacle_color'
drivers/built-in.o: In function `saa7134_set_i2c_ir':
(.text+0x11cc4f): undefined reference to `get_key_pinnacle_grey'
drivers/built-in.o: In function `saa7134_input_fini':
(.text+0x11cd8b): undefined reference to `input_unregister_device'
drivers/built-in.o: In function `saa7134_input_init1':
(.text+0x11d1fa): undefined reference to `input_allocate_device'
drivers/built-in.o: In function `saa7134_input_init1':
(.text+0x11d317): undefined reference to `input_register_device'
drivers/built-in.o: In function `saa7134_input_init1':
(.text+0x11d6ca): undefined reference to `input_free_device'
drivers/built-in.o: In function `saa7134_set_i2c_ir':
(.text+0x11c3f3): undefined reference to `ir_codes_hauppauge_new'
drivers/built-in.o: In function `saa7134_set_i2c_ir':
(.text+0x11c450): undefined reference to `ir_codes_pinnacle_color'
drivers/built-in.o: In function `saa7134_set_i2c_ir':
(.text+0x11c480): undefined reference to `ir_codes_purpletv'
drivers/built-in.o: In function `saa7134_set_i2c_ir':
(.text+0x11c495): undefined reference to `ir_codes_pinnacle_grey'
drivers/built-in.o: In function `saa7134_ir_start':
(.text+0x11c622): undefined reference to `ir_rc5_timer_end'
drivers/built-in.o: In function `saa7134_ir_start':
(.text+0x11c637): undefined reference to `ir_rc5_timer_keyup'
drivers/built-in.o: In function `build_key':
saa7134-input.c:(.text+0x11c769): undefined reference to `ir_extract_bits'
saa7134-input.c:(.text+0x11c7ad): undefined reference to `ir_input_keydown'
saa7134-input.c:(.text+0x11c7f0): undefined reference to `ir_input_keydown'
saa7134-input.c:(.text+0x11c7f9): undefined reference to `ir_input_nokey'
saa7134-input.c:(.text+0x11c806): undefined reference to `ir_input_nokey'
drivers/built-in.o: In function `saa7134_input_init1':
(.text+0x11ca07): undefined reference to `ir_codes_encore_enltv'
drivers/built-in.o: In function `saa7134_input_init1':
(.text+0x11caf6): undefined reference to `ir_input_init'
drivers/built-in.o: In function `saa7134_input_init1':
(.text+0x11cbf2): undefined reference to `ir_codes_avermedia'
drivers/built-in.o: In function `saa7134_input_init1':
(.text+0x11cc24): undefined reference to `ir_codes_pctv_sedna'
drivers/built-in.o: In function `saa7134_input_init1':
(.text+0x11cc53): undefined reference to `ir_codes_flydvb'
drivers/built-in.o: In function `saa7134_input_init1':
(.text+0x11cc85): undefined reference to `ir_codes_videomate_tv_pvr'
drivers/built-in.o: In function `saa7134_input_init1':
(.text+0x11ccb7): undefined reference to `ir_codes_pixelview'
drivers/built-in.o: In function `saa7134_input_init1':
(.text+0x11cce9): undefined reference to `ir_codes_eztv'
drivers/built-in.o: In function `saa7134_input_init1':
(.text+0x11cd1b): undefined reference to `ir_codes_manli'
drivers/built-in.o: In function `saa7134_input_init1':
(.text+0x11cda8): undefined reference to `ir_codes_cinergy'
drivers/built-in.o: In function `saa7134_input_init1':
(.text+0x11cdd7): undefined reference to `ir_codes_flyvideo'
drivers/built-in.o: In function `saa7134_input_init1':
(.text+0x11ce06): undefined reference to `ir_codes_asus_pc39'
drivers/built-in.o: In function `saa7134_input_init1':
(.text+0x11ce7d): undefined reference to `ir_codes_gotview7135'
drivers/built-in.o: In function `saa7134_input_init1':
(.text+0x11cee1): undefined reference to `ir_codes_proteus_2309'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Randy Dunlap [Mon, 29 Oct 2007 18:19:50 +0000 (15:19 -0300)]
V4L/DVB (6478): ir-functions use input functions, should depend on INPUT
Media ir-functions uses input_(*) functions so it should depend
on the INPUT config symbol.
drivers/built-in.o: In function `ir_input_key_event':
ir-functions.c:(.text+0x10849a): undefined reference to `input_event'
ir-functions.c:(.text+0x1084ac): undefined reference to `input_event'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Trent Piepho [Mon, 22 Oct 2007 20:44:55 +0000 (17:44 -0300)]
V4L/DVB (6392): bttv: Update initial image size when set via V4L1 VIDIOCMCAPTURE
The V4L1 spec says that the image size should be with with VIDIOCSWIN before
requesting buffers with VIDIOCGMBUF and capturing into them with
VIDIOCMCAPTURE.
But it seems that many apps don't do this. They set the size using the fields
in the VIDIOCMCAPTURE ioctl. The driver doesn't know what size to capture
until it actually starts to capture. In particular, it doesn't know what size
to capture until it has already mmap the captured buffers. Which is quite
stupid. Why V4L1 has size and format fields for VIDIOCMCAPTURE I have no idea.
Many drivers don't support this, including those using v4l1-compat.
The bttv does, which is probably the only reason such broken software is so
prevalent.
But, the driver doesn't adjust its idea of what size is being captured when it
is set this way. If you try to query the driver's current setting with
v4l2-ctl, it won't be correct.
Trent Piepho [Mon, 22 Oct 2007 20:44:54 +0000 (17:44 -0300)]
V4L/DVB (6391): bttv: SPICT ioctl doesn't work with vlc
The bttv driver instists that the depth specified in the call to VIDIOCSPICT
match the pixel format specified in the same call.
vlc doesn't set the depth field, which makes the SPICT ioctl always fail.
The V4L1 standard is not clear on how most operation are supposed to work, and
this is no exception. The depth field would appear to be entirely redundant,
as the pixel format specifies a specific depth. It could be that this field
was only meant for output from the *G*PICT ioctl and should be ignored in
*S*PICT. This is in fact what the v4l1-compat wrapper does.
Mark Lord [Sun, 4 Nov 2007 02:04:03 +0000 (22:04 -0400)]
rtc: ignore msb when reading back mday from alarm
I have a system here that actively relies upon RTC wake alarms, and it
has been failing (again) for a few days when attempting to use the
/sys/class/rtc/rtc?/wakealarm interface.
The old (fixed by Linus) /proc/ interface still works, but I'd like to
get it using the new one.
This patch fixes rtc-cmos to ignore the two upper bits when reading the
BCD mday (day of month) register from CMOS. Some systems (eg. mine)
seem to have the top bit set to "1" for some reason.
The older /proc/ interface ignores the upper bits, and so we should too.
Signed-off-by: Mark Lord <mlord@pobox.com> Acked-by: David Brownell <david-b@pacbell.net> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Sam Ravnborg [Sun, 4 Nov 2007 18:00:46 +0000 (19:00 +0100)]
kbuild: do not pick up CFLAGS from the environment
Too many people have CFLAGS set to support building userspace.
And now Kbuild picks up CFLAGS this caused troubles.
Although people should realise that setting CFLAGS has
a 'global' effect the impact on the kernel build is a suprise.
So change kbuild to pick up value from KCFLAGS that is
much less used.
When kbuild pick up a value it will warn like this:
Makefile:544: "WARNING: Appending $KCFLAGS (-O3) from environment to kernel $CFLAGS"
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Bächler <thomas@archlinux.org> Cc: David Miller <davem@davemloft.net> Cc: Ingo Molnar <mingo@redhat.com>
Jens Axboe [Sun, 4 Nov 2007 08:44:56 +0000 (09:44 +0100)]
ieee1394: iso and async streams: s/g list fix
Torsten Kaiser wrote:
> Looking that calltrace upwards, it seems replacing the
> memset(dma->sglist,...) with sg_init_table(...) would fix the BUG_ON()
> as that inits the SG_MAGIC.
Tested-by: Torsten Kaiser <just.for.lkml@googlemail.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Linus Torvalds [Sat, 3 Nov 2007 19:43:36 +0000 (12:43 -0700)]
Merge branch 'for-linus' of git://git.kernel.dk/linux-2.6-block
* 'for-linus' of git://git.kernel.dk/linux-2.6-block:
[BLOCK] Don't allow empty barriers to be passed down to queues that don't grok them
dm: bounce_pfn limit added
Deadline iosched: Fix batching fairness
Deadline iosched: Reset batch for ordered requests
Deadline iosched: Factor out finding latter reques
Linus Torvalds [Sat, 3 Nov 2007 19:43:21 +0000 (12:43 -0700)]
Merge branch 'sg' of git://git.kernel.dk/linux-2.6-block
* 'sg' of git://git.kernel.dk/linux-2.6-block:
[SG] Get rid of __sg_mark_end()
cleanup asm/scatterlist.h includes
SG: Make sg_init_one() use general table init functions
Robert Jennings [Tue, 30 Oct 2007 16:37:07 +0000 (11:37 -0500)]
[SCSI] ibmvscsi: Prevent IO during partner login
By setting the request_limit in send_srp_login to 1 we allowed login
requests to be sent to the server adapter. If this was not an initial
login, but was a login after a disconnect with the server, other I/O
requests could attempt to be processed before the login occured. These
I/O requests would fail, sometimes resulting in filesystems getting
marked read-only.
To address this we can set the request_limit to 0 while doing the login
and add an exception where login requests, along with task management
events, are always passed to the server.
There is a case where the request_limit had already reached 0 would result
in all events being sent rather than returning SCSI_MLQUEUE_HOST_BUSY; this
has also been fixed by this patch.
Signed-off-by: Robert Jennings <rcj@linux.vnet.ibm.com> Signed-off-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
James Smart [Mon, 29 Oct 2007 15:00:39 +0000 (11:00 -0400)]
[SCSI] lpfc : Correct queue tag handling
This patch corrects the lpfc tag handling issue identified by Hannes Reinecke
http://marc.info/?l=linux-scsi@m=119270235628850&w=2
The basis for this patch originated from Hajime Kai. Thank You Hajime.
Signed-off-by: hajime-kai@soft.fujitsu.com Signed-off-by: James Smart <James.Smart@emulex.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Tejun Heo [Wed, 31 Oct 2007 01:17:07 +0000 (10:17 +0900)]
libata: don't configure downstream links faster than the upstream link
There's nothing to be gained by configuring downstream links faster
than the upstream link and such configurations cause problems on
certain PMPs. Limit downstream link speed by the upstream link speed.
Signed-off-by: Tejun Heo <htejun@gmail.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
Tejun Heo [Wed, 31 Oct 2007 01:17:06 +0000 (10:17 +0900)]
libata: request PHY speed configuration on SControl access failure
In sata_set_spd_needed(), if SControl read failed, it returned 0 and
skipped PHY speed configuration. However, if SControl access fails,
it's far more logical to request PHY speed configuration. Reverse the
logic.
Signed-off-by: Tejun Heo <htejun@gmail.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
Tejun Heo [Wed, 31 Oct 2007 01:17:05 +0000 (10:17 +0900)]
libata: consider errors not associated with commands for speed down
libata EH used to ignore errors not associated with commands when
determining whether speed down is necessary or not. This leads to the
following problems.
* Errors not associated with commands can occur indefinitely without
libata EH taking corrective actions.
* Upstream link errors don't trigger speed down when PMP is attached
to it and commands issued to downstream device trigger errors on the
upstream link.
This patch makes ata_eh_link_autopsy() consider errors not associated
with command for speed down.
Signed-off-by: Tejun Heo <htejun@gmail.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
Tejun Heo [Wed, 31 Oct 2007 01:17:04 +0000 (10:17 +0900)]
libata: more robust reset failure handling
Reset failure is a critical error. It results in disabling the link
requiring user intervention to re-enable it. Make reset failure
handling more robust such that libata EH doesn't give up too early.
* Temporary glitches during hardreset may lead to classification
failure when there's no softreset available. Retry instead of
giving up.
* Initial softreset or follow up softreset may fail classification.
Move classification error handling block out of followup softreset
block such that both cases are handled and retry instead of giving
up. Also, on the last try, give ATA class a blind shot.
Signed-off-by: Tejun Heo <htejun@gmail.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>