Andrew Vasquez [Wed, 31 Aug 2005 22:18:35 +0000 (15:18 -0700)]
[SCSI] fc_transport: Generalize WWN to u64 interger conversions.
On some platforms the hard-casting of 8 byte node_name and
port_name arrays to an u64 would cause unaligned-access
warnings. Generalize the conversions with a transport
helper function which performs consistent shifting of WWN
bytes.
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
adam radford [Fri, 9 Sep 2005 22:55:13 +0000 (15:55 -0700)]
[SCSI] 3ware 9000: handle use_sg != 0 for emulated commands
The attached patch updates the driver for the 3ware 9000 series to do
the following:
- Correctly handle single sgl's with use_sg = 1.
This is needed with the latest scsi-block-2.6 merge otherwise the 3w-9xxx
driver will not work. I tested the patch James sent a few weeks back to fix
this, and it had a bug where the request_buffer was accessed in
twa_scsiop_execute_scsi_complete() when it was invalid. This is a corrected
variation of that patch.
Signed-off-by: Adam Radford <linuxraid@amcc.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
The SAS transport class contains common code to deal with SAS HBAs, an
aproximated representation of SAS topologies in the driver model,
and various sysfs attributes to expose these topologies and managment
interfaces to userspace.
In addition to the basic SCSI core objects this transport class introduces
two additional intermediate objects: The SAS PHY as represented by struct
sas_phy defines an "outgoing" PHY on a SAS HBA or Expander, and the SAS
remote PHY represented by struct sas_rphy defines an "incoming" PHY on a
SAS Expander or end device. Note that this is purely a software concept, the
underlying hardware for a PHY and a remote PHY is the exactly the same.
There is no concept of a SAS port in this code, users can see what PHYs
form a wide port based on the port_identifier attribute, which is the same
for all PHYs in a port.
This submission doesn't handle hot-plug addition or removal of SAS devices
and thus doesn't do scanning in a workqueue yet, that will be added in
phase2 after this submission. In a third phase I will add additional
managment infrastructure.
I think this submission is ready for 2.6.14, but additional comments are
of course very welcome.
I'd like to thanks James Smart a lot for his very useful input on the
design.
Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Douglas Gilbert [Fri, 9 Sep 2005 10:07:32 +0000 (20:07 +1000)]
[SCSI] permit READ DEFECT DATA in block/scsi_ioctl
The soon to be released smartmontools 5.34 uses the
READ DEFECT DATA command on SCSI disks. A disk that
has defect list entries (or worse, an increasing number
of them) is at risk.
Currently the first invocation of smartctl causes this:
scsi: unknown opcode 0x37
message to appear the console and in the log.
The READ DEFECT DATA SCSI command does not change
the state of a disk. Its opcode (0x37) is valid for
SBC devices (e.g. disks) and SMC-2 devices (media
changers) where it is called INITIALIZE STATUS ELEMENT
WITH RANGE and again doesn't change the external state
of the device.
Changelog:
- mark SCSI opcode 0x37 (READ DEFECT DATA) as
safe_for_read
Signed-off-by: Douglas Gilbert <dougg@torque.net> Acked-by: Jens Axboe <axboe@suse.de> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Douglas Gilbert [Fri, 9 Sep 2005 07:18:57 +0000 (17:18 +1000)]
[SCSI] sg: do not set VM_IO flag on mmap-ed pages
Further to the problem discussed in this post:
http://marc.theaimsgroup.com/?l=linux-scsi&m=112540053711489&w=2
It seems that the sg driver does not need to set the VM_IO flag
on pages that it memory maps to the user space since they are
not from the IO space. Ahmed Teirelbar <ahmed.teirelbar@adic.com>
wants the facility and has tested this patch as I have without
adverse effects.
The oops protection is still important. Some users really did
try and use dio transfers from the sg driver to memory mapped
IO space (on a video capture card if my memory serves) during the
lk 2.4 series. I'm not sure how successful it was but that will
now be politely refused in lk 2.6.13+ .
Changelog:
- set the page flags for sg's reserved buffer mmap-ed
to the user space to VM_RESERVED (rather than
VM_RESERVED | VM_IO )
Signed-off-by: Douglas Gilbert <dougg@torque.net> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
James Bottomley [Fri, 9 Sep 2005 18:40:23 +0000 (13:40 -0500)]
[SCSI] SCSI core: fix leakage of scsi_cmnd's
Actually, just one problem and one cosmetic fix:
1) We need to dequeue for the loop and kill case (it seems easiest
simply to dequeue in the scsi_kill_request() routine)
2) There's no real need to drop the queue lock. __scsi_done() is lock
agnostic, so since there's no requirement, let's just leave it in to
avoid any locking issues.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
James Bottomley [Fri, 9 Sep 2005 15:44:16 +0000 (10:44 -0500)]
[SCSI] SCSI core: fix leakage of scsi_cmnd's
From: Alan Stern <stern@rowland.harvard.edu>
This patch (as559b) adds a new routine, scsi_unprep_request, which
gets called every place a request is requeued. (That includes
scsi_queue_insert as well as scsi_requeue_command.) It also changes
scsi_kill_requests to make it call __scsi_done with result equal to
DID_NO_CONNECT << 16. (I'm not sure if it's necessary to call
scsi_init_cmd_errh here; maybe you can check on that.) Finally, the
patch changes the return value from scsi_end_request, to avoid
returning a stale pointer in the case where the request was requeued.
Fortunately the return value is used in only place, and the change
actually simplified it.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Rejections fixed up and Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Neil Brown [Fri, 2 Sep 2005 03:13:54 +0000 (13:13 +1000)]
[SCSI] fix possible deadlock in scsi_lib.c
If a filesystem, while writing out data, decides that it is good
to issue a cache flush on a SCSI drive (or other 'sd' device), it will
call blkdev_issue_flush which calls ->issue_flush_fn which is
scsi_issue_flush_fn.
This calls sd_issue_flush which calls sd_sync_cache, which calls
scsi_execute_request.
This will (as sshdr != NULL) call
kmalloc(SCSI_SENSE_BUFFERSIZE, GFP_KERNEL)
If memory is tight, the presence of GFP_KERNEL may cause write
requests to be sent to some filesystem to free up memory, however if
that filesystem is waiting for the issue_flush_fn to complete, you
could get a deadlock.
I wonder if it might be more appropriate to use GFP_NOIO as in the
following patch.
I wonder if it might be even more appropriate to cope better with a
kmalloc failure, especially as in this use, sd_sync_cache only will
use the sense information to print out a more informative error
message.
Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Alan Stern [Tue, 26 Jul 2005 14:20:53 +0000 (10:20 -0400)]
[SCSI] fix callers of scsi_remove_device() who already hold the scan muted
This patch (as544) adds a private entry point to scsi_remove_device, for
use when callers already own the scan_mutex. The appropriate callers are
modified to use the new entry point.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Alan Stern [Tue, 26 Jul 2005 14:18:45 +0000 (10:18 -0400)]
[SCSI] add missing scan mutex to scsi_scan_target()
This patch (as543) adds a private entry point to scsi_scan_target, for use
when the caller already owns the scan_mutex, and updates the kerneldoc for
that routine (which was badly out-of-date). It converts scsi_scan_channel
to use the new entry point. Lastly, it modifies scsi_get_host_dev to make
it acquire the scan_mutex, necessary since the routine adds a new
scsi_device even if it doesn't do any actual scanning.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
James Bottomley [Tue, 6 Sep 2005 23:56:51 +0000 (16:56 -0700)]
[PATCH] fix klist semantics for lists which have elements removed on traversal
The problem is that klists claim to provide semantics for safe traversal of
lists which are being modified. The failure case is when traversal of a
list causes element removal (a fairly common case). The issue is that
although the list node is refcounted, if it is embedded in an object (which
is universally the case), then the object will be freed regardless of the
klist refcount leading to slab corruption because the klist iterator refers
to the prior element to get the next.
The solution is to make the klist take and release references to the
embedding object meaning that the embedding object won't be released until
the list relinquishes the reference to it.
(akpm: fast-track this because it's needed for the 2.6.13 scsi merge)
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
All uses of ADDRLEN are comparisons with 64 (it's an address width).
added define to 32 (again, we only care about comparisons with 64)
if not defined.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] bogus symbol used in arch/um/os-Linux/elf_aux.c
elf_aux is userland code; it uses symbol (ELF_CLASS) that doesn't exist in
userland headers; pulled into kernel-offsets.h, switched elf_aux to using it.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
A piece of the UML stubs patch got lost - it has
Killed STUBS_CFLAGS - it's not needed and the only remaining use had been
gratitious - it only polluted CFLAGS
in description and does remove it in arch/um/Makefile-x86_64, but forgets to
do the same in i386 counterpart. Lost chunk follows:
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Sanitized and fixed floppy dependencies: split the messy dependencies for
BLK_DEV_FD by introducing a new symbol (ARCH_MAY_HAVE_PC_FDC), making
BLK_DEV_FD depend on that one and taking declarations of ARCH_MAY_HAVE_PC_FDC
to arch/*/Kconfig. While we are at it, fixed several obvious cases when
BLK_DEV_FD should have been excluded (architectures lacking asm/floppy.h
are *not* going to have floppy.c compile, let alone work).
If you can come up with better name for that ("this architecture might
have working PC-compatible floppy disk controller"), you are more than
welcome - just s/ARCH_MAY_HAVE_PC_FDC/your_prefered_name/g in the patch
below...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Michael Krufky [Tue, 6 Sep 2005 22:19:40 +0000 (15:19 -0700)]
[PATCH] DVB: lgdt330x check callback fix
Most of the patch is whitespace cleanup, but more importantly, this patch
checks to see whether a callback is set before calling it. On cx88 boards
(currently the only boards using lgdt330x in 2.6.13) every callback is set.
However, newer drivers currently in development leave a callback undefined,
and lgdt330x must not call it if it isn't defined.
Signed-off-by: Patrick Boettcher <pb@linuxtv.org> Signed-off-by: Michael Krufky <mkrufky@m1k.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Michael Krufky [Tue, 6 Sep 2005 22:19:38 +0000 (15:19 -0700)]
[PATCH] DVB: Clarify description text for dvb-bt8xx in Kconfig
Patrick Keene wrote to the linux-dvb list, asking where in menuconfig he
can enable dvb-bt8xx for his AVerMedia DVB card. I pointed the following
out to him:
When pivot_root is called from an init script in an initramfs environment,
it causes a circular reference in the mount tree.
The cause of this is that pivot_root() is not prepared to handle pivoting
an unattached mount. In an initramfs environment, rootfs is the root of
the namespace, and so it is not attached.
This patch fixes this and related problems, by returning -EINVAL if either
the current root or the new root is detached.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu> Acked-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk> Cc: <bigfish@asmallpond.org> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] kprobes: fix bug when probed on task and isr functions
This patch fixes a race condition where in system used to hang or sometime
crash within minutes when kprobes are inserted on ISR routine and a task
routine.
The fix has been stress tested on i386, ia64, pp64 and on x86_64. To
reproduce the problem insert kprobes on schedule() and do_IRQ() functions
and you should see hang or system crash.
Signed-off-by: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com> Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com> Acked-by: Prasanna S Panchamukhi <prasanna@in.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Jim Keniston [Tue, 6 Sep 2005 22:19:34 +0000 (15:19 -0700)]
[PATCH] kprobes: fix handling of simultaneous probe hit/unregister
This patch fixes a bug in kprobes's handling of a corner case on i386 and
x86_64. On an SMP system, if one CPU unregisters a kprobe just after
another CPU hits that probepoint, kprobe_handler() on the latter CPU sees
that the kprobe has been unregistered, and attempts to let the CPU continue
as if the probepoint hadn't been hit. The bug is that on i386 and x86_64,
we were neglecting to set the IP back to the beginning of the probed
instruction. This could cause an oops or crash.
This bug doesn't exist on ppc64 and ia64, where a breakpoint instruction
leaves the IP pointing to the beginning of the instruction. I don't know
about sparc64. (Dave, could you please advise?)
This fix has been tested on i386 and x86_64 SMP systems. To reproduce the
problem, set one CPU to work registering and unregistering a kprobe
repeatedly, and another CPU pounding the probepoint in a tight loop.
Acked-by: Prasanna S Panchamukhi <prasanna@in.ibm.com> Signed-off-by: Jim Keniston <jkenisto@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] Kprobes/IA64: fix race when break hits and kprobe not found
This patch addresses a potential race condition for a case where Kprobe has
been removed right after another CPU has taken a break hit.
The way this is addressed here is when the CPU that has taken a break hit
does not find its corresponding kprobe, then we check to see if the
original instruction got replaced with other than break. If it got
replaced with other than break instruction, then we continue to execute
from the replaced instruction, else if we find that it is still a break,
then we let the kernel handle this, as this might be the break instruction
inserted by other than kprobe(may be kernel debugger).
Signed-off-by: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] Kprobes: prevent possible race conditions generic
There are possible race conditions if probes are placed on routines within the
kprobes files and routines used by the kprobes. For example if you put probe
on get_kprobe() routines, the system can hang while inserting probes on any
routine such as do_fork(). Because while inserting probes on do_fork(),
register_kprobes() routine grabs the kprobes spin lock and executes
get_kprobe() routine and to handle probe of get_kprobe(), kprobes_handler()
gets executed and tries to grab kprobes spin lock, and spins forever. This
patch avoids such possible race conditions by preventing probes on routines
within the kprobes file and routines used by kprobes.
I have modified the patches as per Andi Kleen's suggestion to move kprobes
routines and other routines used by kprobes to a seperate section
.kprobes.text.
Also moved page fault and exception handlers, general protection fault to
.kprobes.text section.
These patches have been tested on i386, x86_64 and ppc64 architectures, also
compiled on ia64 and sparc64 architectures.
Signed-off-by: Prasanna S Panchamukhi <prasanna@in.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
I noticed a strange return value in smsc_ircc_init in
drivers/net/irda/smsc_ircc2.c in rc4-mm1.
When reaching the line "if (ircc_fir > 0 && ircc_sir > 0)", ret is 0. So I
don't see the point of setting it to 0 in the "else" case. >From what I
see in 2.6.12 it should probably be set to -ENODEV at the begining of the
"else" case. The attached patch does this.
Note that I didn't actually see any breakage caused by this.
Jan Kara [Tue, 6 Sep 2005 22:19:17 +0000 (15:19 -0700)]
[PATCH] Fix race in do_get_write_access()
attached patch should fix the following race:
Proc 1 Proc 2
__flush_batch()
ll_rw_block()
do_get_write_access()
lock_buffer
jh is only waiting for checkpoint
-> b_transaction == NULL ->
do nothing
unlock_buffer
test_set_buffer_locked()
test_clear_buffer_dirty()
__journal_file_buffer()
change the data
submit_bh()
and we have sent wrong data to disk... We now clean the dirty buffer flag
under buffer lock in all cases and hence we know that whenever a buffer is
starting to be journaled we either finish the pending write-out before
attaching a buffer to a transaction or we won't write the buffer until the
transaction is going to be committed.
The test in jbd_unexpected_dirty_buffer() is redundant - remove it.
Furthermore we have to clear the buffer dirty bit under the buffer lock to
prevent races with buffer write-out (and hence prevent returning a buffer with
IO happening).
Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Jan Kara [Tue, 6 Sep 2005 22:19:10 +0000 (15:19 -0700)]
[PATCH] Make ll_rw_block() wait for buffer lock
Introduce new ll_rw_block() operation SWRITE meaning that block layer should
wait for the buffer lock and write-out afterwards. Hence data in buffers at
the time of call are guaranteed to be submitted to the disk.
Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Jan Kara [Tue, 6 Sep 2005 22:19:09 +0000 (15:19 -0700)]
[PATCH] Fix JBD race in t_forget list handling
Fix race between journal_commit_transaction() and other places as
journal_unmap_buffer() that are adding buffers to transaction's t_forget list.
We have to protect against such places by holding j_list_lock even when
traversing the t_forget list. The fact that other places can only add buffers
to the list makes the locking easier. OTOH the lock ranking complicates the
stuff...
Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Mark Fasheh [Tue, 6 Sep 2005 22:19:08 +0000 (15:19 -0700)]
[PATCH] kjournald: missing JFS_UNMOUNT check
It seems that kjournald() may be missing a check of the JFS_UNMOUNT flag
before calling schedule(). This showed up in testing of OCFS2 recovery
where our recovery thread would hang in journal_kill_thread() called from
journal_destroy() because kjournald never got a chance to read the flag to
shut down before the schedule().
Zach pointed out the missing check which led me to hack up this trivial
patch. It's been tested many times now and I have yet to reproduce the
hang, which was happening very regularly before.
<mild rant>
I'm guessing that we could really use some wait_event() calls with helper
functions in, well, most of jbd these days which would make a ton of the
wait code there vastly cleaner.
</mild rant>
As for why this doesn't happen in ext3 (or OCFS2 during normal
mount/unmount of the local nodes journal), I think it may that the specific
timing of events in the ocfs2 recovery thread exposes a race there.
Because ocfs2_replay_journal() is only interested in playing back the
journal, initialization and shutdown happen very quicky with no other
metadata put into that specific journal.
Acked-by: "Stephen C. Tweedie" <sct@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Richard Purdie [Tue, 6 Sep 2005 22:19:05 +0000 (15:19 -0700)]
[PATCH] w100fb: Update corgi platform code to match new driver
This patch moves the platform specific Sharp SL-C7x0 LCD code from the
w100fb driver into a more appropriate place and updates the Corgi code to
match the new w100fb driver.
It also updates the corgi touchscreen code to match the new simplified
interface available from w100fb.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Richard Purdie [Tue, 6 Sep 2005 22:19:03 +0000 (15:19 -0700)]
[PATCH] w100fb: Rewrite for platform independence
The code w100fb was based on was horribly Sharp SL-C7x0 specific and there
was little else that could be done as I had no access to anything else with
a w100 in it. There is no real documentation about this chipset available.
Ian Molton has access to other platforms with the w100 (Toshiba e-series)
and so between us, we've improved w100fb and made it platform independent.
Ian Molton also added support for the very similar w3220 and w3200
chipsets.
There are a lot of changes here and it nearly amounts to a rewrite of the
driver but it has been extensively tested and is being used in preference
to the original driver in the Zaurus community. I'd therefore like to
update the mainline code to reflect this.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Acked-by: Antonino Daplas <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Richard Purdie [Tue, 6 Sep 2005 22:19:01 +0000 (15:19 -0700)]
[PATCH] Corgi Touchscreen: Allow the driver to share the PMU
The Corgi Touchscreen driver uses the PMU as an accurate timing source which
conflicts with its usage for performance monitoring. This patch allows it to
be shared with other users such as oprofile.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Richard Purdie [Tue, 6 Sep 2005 22:19:00 +0000 (15:19 -0700)]
[PATCH] Corgi Keyboard: Code tidying
The input system handles key state tracking so there's no need for the driver
to do so as well. Also tidy up some comment formatting and remove a now
unneeded function.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Richard Purdie [Tue, 6 Sep 2005 22:18:59 +0000 (15:18 -0700)]
[PATCH] Corgi Keyboard: Add some power management code
Add some power management code to the corgi keyboard driver so that only one
power event gets reported within any reasonable time frame and the driver
doesn't enter an infinte loop due to key repeat.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Pierre Ossman [Tue, 6 Sep 2005 22:18:57 +0000 (15:18 -0700)]
[PATCH] mmc: wbsd Secure Digital support
Add support for Secure Digital specific features in the wbsd driver. Adds
support for read-only switch and wide bus transfers.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Pierre Ossman [Tue, 6 Sep 2005 22:18:56 +0000 (15:18 -0700)]
[PATCH] sd: SD copyright notice
Credit where credit is due.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx> Cc: Russell King <rmk@arm.linux.org.uk> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Pierre Ossman [Tue, 6 Sep 2005 22:18:55 +0000 (15:18 -0700)]
[PATCH] sd: SD 4-bit bus
Infrastructure for 4-bit bus transfers with SD cards.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx> Cc: Russell King <rmk@arm.linux.org.uk> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Pierre Ossman [Tue, 6 Sep 2005 22:18:54 +0000 (15:18 -0700)]
[PATCH] sd: SCR in sysfs
Export the SCR register through sysfs.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx> Cc: Russell King <rmk@arm.linux.org.uk> Cc: David Brownell <david-b@pacbell.net> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Pierre Ossman [Tue, 6 Sep 2005 22:18:53 +0000 (15:18 -0700)]
[PATCH] sd: SCR register
Read the SD specific SCR register from the card.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx> Cc: Russell King <rmk@arm.linux.org.uk> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Pierre Ossman [Tue, 6 Sep 2005 22:18:52 +0000 (15:18 -0700)]
[PATCH] sd: read-only switch
Support for the read-only switch on SD cards which must be enforced by the
host.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx> Cc: Russell King <rmk@arm.linux.org.uk> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Pierre Ossman [Tue, 6 Sep 2005 22:18:50 +0000 (15:18 -0700)]
[PATCH] sd: initialize SD cards
Support for the Secure Digital protocol in the MMC layer.
A summary of the legal issues surrounding SD cards, as understood by yours
truly:
Members of the Secure Digital Association, hereafter SDA, are required to sign
a NDA[1] before given access to any specifications. It has been speculated
that including an SD implementation would forbid these members to redistribute
Linux. This is the basic problem with SD support so it is unclear if it even
is a problem since it has no effect on those of us that aren't members.
The SDA doesn't seem to enforce these rules though since the patches included
here are based on documentation made public by some of the members. The most
complete specs[2] are actually released by Sandisk, one of the founding
companies of the SDA.
Because of this the NDA is considered a non-issue by most involved in the
discussions concerning these patches. It might be that the SDA is only
interested in protecting the so called "secure" bits of SD, which so far
hasn't been found in any public spec. (The card is split into two sections,
one "normal" and one "secure" which has an access scheme similar to TPM:s).
(As a side note, Microsoft is working to make things easier for us since they
want to be able to include the source code for a SD driver in one of their
development kits. HP is making sure that the new NDA will allow a Linux
implementation. So far only the SDIO specs have been opened up[3]. More will
hopefully follow.)
This patch contains the central parts of the SD support. If no MMC cards are
found on a bus then the MMC layer proceeds looking for SD cards. Helper
functions are extended to handle the special needs of SD cards.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx> Cc: Russell King <rmk@arm.linux.org.uk> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Roman Zippel [Tue, 6 Sep 2005 22:18:49 +0000 (15:18 -0700)]
[PATCH] hfs: NLS support
This adds NLS support to HFS. Using the kernel options iocharset and codepage
it's possible to map the disk encoding to a local mapping. If these options
are not used, it falls back to the old direct mapping.
Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The IPMI power control function proc_write_chassctrl was badly written, it
directly used userspace pointers, it assumed that strings were NULL
terminated, and it used the evil sscanf function. This converts over to
using the sysctl interface for this data and changes the semantics to be a
little more logical.
[PATCH] ipmi: add hacks for IPMI chassis poweroff for certain Dell servers
This patch allows Dell servers with IPMI controllers that predate IPMI 1.5
to use the standard poweroff or powercycle commands. These systems
firmware don't set the chassis capability bit in the Get Device ID, but
they do implement the standard poweroff and powercycle commands.
Tested on RHEL3 kernel 2.4.21-20.ELsmp on a PowerEdge 2600. The standard
ipmi_poweroff driver cannot drive these systems. With this patch, they
power off or powercycle as expected.
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com> Signed-off-by: Corey Minyard <minyard@acm.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The "null message handler" in the IPMI driver is used in startup and panic
situations to handle messages. It was only designed to work with messages
from the local management controller, but in some cases it was used to get
messages from remote managmenet controllers, and the system would then
panic. This patch makes the "null message handler" in the IPMI driver more
general so it works with any kind of message.
[PATCH] ipmi: clean up versioning of the IPMI driver
This adds MODULE_VERSION, MODULE_DESCRIPTION, and MODULE_AUTHOR tags to the
IPMI driver modules. Also changes the MODULE_VERSION to remove the
prepended 'v' on each value, consistent with the module versioning policy.
This patch also removes all the version information from everything except
the ipmi_msghandler module.
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com> Signed-off-by: Corey Minyard <minyard@acm.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] ipmi: OEM flag handling and hacks for some Dell machines
The ipmi driver does not have a way to handle firmware-generated events
which have the OEM[012] Data Available flags set. In such a case, the
SMS_ATN bit may never get cleared by firmware, leaving the driver looping
infinitely but never able to make any progress.
This patch first simplifies storage and use of the data returned from an
IPMI Get Device ID command.
It then creates a new per-OEM handler hook, which should know how to handle
events with the OEM[012] Data Available flags set. It then uses this to
implement a workaround for IPMI 1.5-capable Dell PowerEdge servers which
are susceptable to setting the OEM[012] Data Available flags when the
driver can't handle it.
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com> Signed-off-by: Corey Minyard <minyard@acm.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
projects / linux-2.6 / log