* master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6: (97 commits)
[SCSI] zfcp: removed wrong comment
[SCSI] zfcp: use of uninitialized variable
[SCSI] zfcp: Invalid locking order
[SCSI] aic79xx: use dma_get_required_mask()
[SCSI] aic79xx: fix bracket mismatch in unused macro
[SCSI] BusLogic: Replace 'boolean' by 'bool'
[SCSI] advansys: clean up warnings
[SCSI] 53c7xx: brackets fix in uncompiled code
[SCSI] nsp_cs: remove old scsi code
[SCSI] aic79xx: make ahd_match_scb() static
[SCSI] DAC960: kmalloc->kzalloc/Casting cleanups
[SCSI] scsi_kmap_atomic_sg(): check that local irqs are disabled
[SCSI] Buslogic: local_irq_disable() is redundant after local_irq_save()
[SCSI] aic94xx: update for v28 firmware
[SCSI] scsi_error: Fix lost EH commands
[SCSI] aic94xx: Add default bus reset handler
[SCSI] aic94xx: Remove TMF result code munging
[SCSI] libsas: Add an LU reset mechanism to the error handler
[SCSI] libsas: Don't BUG when connecting two expanders via wide port
[SCSI] st: fix Tape dies if wrong block size used, bug 7919
...
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc:
tifm_sd: treat "status error" as normal command completion
mmc: wbsd: Remove stray kunmap_atomic()
mmc: sdhci: Stop asking for mail
mmc: sdhci: Remove driver version
mmc: wbsd: Remove driver version
This patch contains two fixes for RapisIO enumeration logic:
1. Fix enumeration in configurations with multiple switches. The patch adds:
a. Enumeration of an empty switch. Empty switch is a switch that
does not have any endpoint devices attached to it (except host device
or previous switch in a chain). New code assigns a phony destination
ID associated with the switch and sets up corresponding routes.
b. Adds a second pass to the enumeration to setup routes to
devices discovered after switch was scanned.
2. Fix enumeration failure when riohdid parameter has non-zero value.
Current version fails to setup response path to the host when it has
destination ID other that 0.
Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
Acked-by: Matt Porter <mporter@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
release_mem contains two copies of exactly the same code. Refactor these
into a new helper, release_tty. The only change in behaviour is that the
driver reference count is now decremented after the master tty has been
freed instead of before.
[penberg@cs.helsinki.fi: fix use-after-free in release_tty.]
Cc: Alan Cox <alan@redhat.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Minor number 0 (under the raw major) is reserved for the rawctl device
file, which is used to query, set, and unset raw device bindings. However,
the ioctl interface does not protect the user from specifying a raw device
with minor number 0:
$ sudo ./raw /dev/raw/raw0 /dev/VolGroup00/swap
/dev/raw/raw0: bound to major 253, minor 2
$ ls -l /dev/rawctl
ls: /dev/rawctl: No such file or directory
$ ls -l /dev/raw/raw0
crw------- 1 root root 162, 0 Jan 12 10:51 /dev/raw/raw0
$ sudo ./raw -qa
Cannot open master raw device '/dev/rawctl' (No such file or directory)
As you can see, this prevents any further raw operations from
succeeding. The fix (from Steve Fernandez) is quite simple--do not
allow the allocation of minor number 0.
Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Cc: Steven Fernandez <sfernand@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Mostly so people can see the work in progress. This enhances the encode
function which isn't currently used in the base tree but is when using some of
the testing tty patches.
This resolves a problem with some hardware where applications got confusing
information from the tty ioctls. Correct but confusing.
In some situations asking for, say, 9600 baud actually gets you 9595 baud or
similar near-miss values. With the old code this meant that a request for
B9600 got a return of BOTHER, 9595 which programs interpreted as a failure.
The new code now works on the following basis
- If you ask for specific rate via BOTHER, you get a precise return
- If you ask for a standard Bfoo rate and the result is close you get a Bfoo
return
- If you ask for a standard Bfoo rate and get something way off you get a
BOTHER/rate return
This seems to fix up the cases I've found where this broke compatibility.
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
