Many controllers have an upper limit on the number of blocks that can be
transferred in one request. Allow the host drivers to specify this and make
sure we avoid hitting this limit.

Also change the max_sectors field to avoid confusion. This makes it map
less directly to the block layer limits, but as they didn't apply directly
on MMC cards anyway, this isn't a great loss.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Most controllers have an upper limit on the block size. Allow the host
drivers to specify this and make sure we avoid hitting this limit.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Signed-off-by: NAlex Dubov <oakad@yahoo.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Signed-off-by: NAlex Dubov <oakad@yahoo.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Fix some spaces and tabs. No semantic changes are introduced.
Signed-off-by: NAlex Dubov <oakad@yahoo.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

This patch also adds symbolic defines for supported pci ids.
Signed-off-by: NAlex Dubov <oakad@yahoo.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

As there's only one work item (media_switcher) to handle and it's effectively
serialized with itself, I found it more convenient to use kthread instead of
workqueue. This also allows for a working implementation of suspend/resume,
which were totally broken in the past version.
Signed-off-by: NAlex Dubov <oakad@yahoo.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Hardware does not say whether card was inserted or removed when reporting
socket events. Moreover, during suspend, media can be removed or switched
to some other card type without notification. Therefore, for each socket
in the change set the following is performed:
1. If there's active device in the socket it's unregistered
2. Media detection is performed
3. If detection recognizes supportable media, new device is registered

This patch also alters some macros and variable names to enhance clarity.
Signed-off-by: NAlex Dubov <oakad@yahoo.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Eject function can take advantage of the socket_id field instead of explicit
pointer comparison.
Signed-off-by: NAlex Dubov <oakad@yahoo.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Signed-off-by: NAlex Dubov <oakad@yahoo.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Signed-off-by: NAlex Dubov <oakad@yahoo.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

This patch introduces no semantic changes - it is here for estetic purposes.
Signed-off-by: NAlex Dubov <oakad@yahoo.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

In order to support correct suspend and resume several changes were needed:
1. Switch from work_struct to tasklet for command handling. When device
suspend is called workqueues are already frozen and can not be used.
2. Separate host initialization code from driver's probe and don't rely
on interrupts for host initialization. This, in turn, addresses two
problems:
 a) Resume needs to re-initialize the host, but can not assume that
    device interrupts were already re-armed.
 b) Previously, probe will return successfully before really knowing
    the state of the host, as host interrupts were not armed in time.
    Now it uses polling to determine the real host state before returning.
3. Separate termination code from driver's remove. Termination may be caused
by resume, if media changed type or became unavailable during suspend.
Signed-off-by: NAlex Dubov <oakad@yahoo.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

The register access order when setting hardware timeout was incorrect and
causing problems (wrong timeout intervals). This is now fixed.
Signed-off-by: NAlex Dubov <oakad@yahoo.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Two changes are introduced to software timeout handler in order to simplify
its management:
1. The implementation is switched from work_struct to timer
2. Previously, software timeout was rearmed with each interrupt. Now,
current request must complete entirely within timeout interval.
Signed-off-by: NAlex Dubov <oakad@yahoo.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Data buffer for PIO transfer used to be mapped in advance with kmap.
Abolish it in favor of on-demand kmap_atomic.
Signed-off-by: NAlex Dubov <oakad@yahoo.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Previously, stop command was issued right after BRS (block received/sent)
event. Stop command completion event could interfere with the card busy
event, causing miscount of the written blocks.
This patch ensures that stop command issued as last action for a
particular command, after DMA sompletion event and written block
count verification.
Signed-off-by: NAlex Dubov <oakad@yahoo.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Thanks to the generous donation of an SDHC card by John Gilmore, and
the surprisingly enlightened decision by the SD Card Association to
publish useful specs, I've been able to bash out support for SDHC. The
changes are not too profound:

i) Add a card flag indicating the card uses block level addressing and
check it in the block driver. As we never took advantage of byte-level
addressing, this simply involves skipping the block -> byte
translation when sending commands.

ii) The layout of the CSD is changed - a set of fields are discarded
to make space for a larger C_SIZE. We did not reference any of the
discarded fields except those related to the C_SIZE.

iii) Read and write timeouts are fixed values and not calculated from
CSD values.

iv) Before invoking SEND_APP_OP_COND, we must invoke the new
SEND_IF_COND to inform the card we support SDHC.
Signed-off-by: NPhilipl Langdale <philipl@overt.org>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Support for these devices was broken for 2.6.18-rc1 and later by commit
146ad66e, which added voltage level support.

This restores the previous behaviour for these devices by ensuring that when
the voltage is changed, only one write to set the voltage is performed.

It may be that both writes are needed if the voltage is being changed between
two non-zero values or that it's safe to ensure that only one write is done
if the hardware only supports one voltage; I don't know whether either is the
case nor can I test since I have only the one SD reader (1524:0550), and it
supports just the one voltage.
Signed-off-by: NDarren Salt <linux@youmustbejoking.demon.co.uk>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Change the parent of cards to be a specific host (a class
device), not the physical controller. This is particularly
useful when the hardware has multiple slots, meaning
multiple hosts.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

As card_busy was only used to indicate if the host was exclusively
claimed and not really used to identify a particular card, replacing
it with just a boolean makes things a lot more easily understandable.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

au1xmmc: return error when encountering unhandled/unknown response type.
Signed-off-by: NManuel Lauss <mano@roarinelk.homelinux.net>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

au1xmmc: implement proper R/O switch detection.
Signed-off-by: NManuel Lauss <mano@roarinelk.homelinux.net>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

When calling into the EFI firmware, the parameters need to be passed on
the stack. The recent change to use -mregparm=3 breaks x86 EFI support.
This patch is needed to allow the new Intel-based Macs to suspend to ram
(efi.get_time is called during the suspend phase).
Signed-off-by: NFrederic Riss <frederic.riss@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

That code doesn't do what its author apparently thought it would do...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

* master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6:
  [SCSI] sd: udev accessing an uninitialized scsi_disk field results in a crash
  [SCSI] st: A MTIOCTOP/MTWEOF within the early warning will cause the file number to be incorrect
  [SCSI] qla4xxx: bug fixes
  [SCSI] Fix scsi_add_device() for async scanning

x86-64 is missing these:
Signed-off-by: NJeff Garzik <jeff@garzik.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The SN Altix platform does not conform to the IOSAPIC IRQ routing model.
Add code in acpi_unregister_gsi() to check if (acpi_irq_model ==
ACPI_IRQ_MODEL_PLATFORM) and return.

Due to an oversight, this code was not added previously when
similar code was added to acpi_register_gsi().

http://marc.theaimsgroup.com/?l=linux-acpi&m=116680983430121&w=2Signed-off-by: NJohn Keller <jpk@sgi.com>
Acked-by: NLen Brown <lenb@kernel.org>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Andrew Vasquez is reporting as-iosched oopses and a 65% throughput
slowdown due to the recent special-casing of direct-io against
blockdevs.  We don't know why either of these things are occurring.

The patch minimally reverts us back to the 2.6.19 code for a 2.6.20
release.

Cc: Andrew Vasquez <andrew.vasquez@qlogic.com>
Cc: Ken Chen <kenchen@google.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

We went and named them __NR_sys_foo instead of __NR_foo.

It may be too late to change this, but we can at least add the proper names
now.
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

smc911x_phy_configure's error handling unconditionally unlocks the
spinlock even if it wasn't locked. Patch fixes it.
Signed-off-by: NPeter Korsgaard <jacmet@sunsite.dk>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This patch fixes up ia64 kexec support for HP rx2620 hardware.  It does
this by skipping migration of already disabled irqs.  This is most likely a
problem on other ia64 platforms as well, but I've only been able to
reproduce it on one machine so far.

The full story is that handle_bad_irq() gets invoked before starting the
new kernel without this patch.  This seems to happen when fixup_irqs()
calls generic_handle_irq() on already migrated (and disabled) irqs.  So by
avoiding migration of disabled irqs we stay away of handle_bad_irq().

The code has been tested on three different ia64 machines, all with good
results.  It is possible to trigger the same bug by offlining a processor
using echo 0 > /sys/devices/system/cpu/cpuX/online.

More detailed information is available in the following mail thread:
http://lists.osdl.org/pipermail/fastboot/2007-January/thread.html#5774Signed-off-by: NMagnus Damm <magnus@valinux.co.jp>
Acked-by: NSimon Horman <horms@verge.net.au>
Acked-by: NZou, Nanhai <nanhai.zou@intel.com>
Acked-by: NJay Lan <jlan@sgi.com>
Acked-by: N"Luck, Tony" <tony.luck@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

An AIO bug was reported that sleeping function is being called in softirq
context:

BUG: warning at kernel/mutex.c:132/__mutex_lock_common()
Call Trace:
     [<a000000100577b00>] __mutex_lock_slowpath+0x640/0x6c0
     [<a000000100577ba0>] mutex_lock+0x20/0x40
     [<a0000001000a25b0>] flush_workqueue+0xb0/0x1a0
     [<a00000010018c0c0>] __put_ioctx+0xc0/0x240
     [<a00000010018d470>] aio_complete+0x2f0/0x420
     [<a00000010019cc80>] finished_one_bio+0x200/0x2a0
     [<a00000010019d1c0>] dio_bio_complete+0x1c0/0x200
     [<a00000010019d260>] dio_bio_end_aio+0x60/0x80
     [<a00000010014acd0>] bio_endio+0x110/0x1c0
     [<a0000001002770e0>] __end_that_request_first+0x180/0xba0
     [<a000000100277b90>] end_that_request_chunk+0x30/0x60
     [<a0000002073c0c70>] scsi_end_request+0x50/0x300 [scsi_mod]
     [<a0000002073c1240>] scsi_io_completion+0x200/0x8a0 [scsi_mod]
     [<a0000002074729b0>] sd_rw_intr+0x330/0x860 [sd_mod]
     [<a0000002073b3ac0>] scsi_finish_command+0x100/0x1c0 [scsi_mod]
     [<a0000002073c2910>] scsi_softirq_done+0x230/0x300 [scsi_mod]
     [<a000000100277d20>] blk_done_softirq+0x160/0x1c0
     [<a000000100083e00>] __do_softirq+0x200/0x240
     [<a000000100083eb0>] do_softirq+0x70/0xc0

See report: http://marc.theaimsgroup.com/?l=linux-kernel&m=116599593200888&w=2

flush_workqueue() is not allowed to be called in the softirq context.
However, aio_complete() called from I/O interrupt can potentially call
put_ioctx with last ref count on ioctx and triggers bug.  It is simply
incorrect to perform ioctx freeing from aio_complete.

The bug is trigger-able from a race between io_destroy() and aio_complete().
A possible scenario:

cpu0                               cpu1
io_destroy                         aio_complete
  wait_for_all_aios {                __aio_put_req
     ...                                 ctx->reqs_active--;
     if (!ctx->reqs_active)
        return;
  }
  ...
  put_ioctx(ioctx)

                                     put_ioctx(ctx);
                                        __put_ioctx
                                          bam! Bug trigger!

The real problem is that the condition check of ctx->reqs_active in
wait_for_all_aios() is incorrect that access to reqs_active is not
being properly protected by spin lock.

This patch adds that protective spin lock, and at the same time removes
all duplicate ref counting for each kiocb as reqs_active is already used
as a ref count for each active ioctx.  This also ensures that buggy call
to flush_workqueue() in softirq context is eliminated.
Signed-off-by: N"Ken Chen" <kenchen@google.com>
Cc: Zach Brown <zach.brown@oracle.com>
Cc: Suparna Bhattacharya <suparna@in.ibm.com>
Cc: Benjamin LaHaise <bcrl@kvack.org>
Cc: Badari Pulavarty <pbadari@us.ibm.com>
Cc: <stable@kernel.org>
Acked-by: NJeff Moyer <jmoyer@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix this by letting NF_CONNTRACK_H323 depend on (IPV6 || IPV6=n).
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

  CC      net/netfilter/nf_conntrack_netlink.o
net/netfilter/nf_conntrack_netlink.c: In function 'ctnetlink_conntrack_event':
net/netfilter/nf_conntrack_netlink.c:392: error: 'struct nf_conn' has no member named 'mark'
make[3]: *** [net/netfilter/nf_conntrack_netlink.o] Error 1
Signed-off-by: NPatrick McHardy <kaber@trash.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

	sd_probe() calls class_device_add() even before initializing the
sdkp->device variable. class_device_add() eventually results in the user mode
udev program to be called. udev program can read the the allow_restart
attribute of the newly created scsi device. This is resulting in a crash as
the show function for allow_restart (i.e sd_show_allow_restart) returns the
attribute value by reading the sdkp->device->allow_restart variable. As the
sdkp->device is not initialized before calling the user mode hotplug helper,
this results in a crash.
	The patch below solves it by calling class_device_add() only after the
necessary fields in the scsi_disk structure are initialized properly.
Signed-off-by: NNagendra Singh Tomar <nagendra_tomar@adaptec.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>

* 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev:
  libata: Initialize nbytes for internal sg commands
  libata: Fix ata_busy_wait() kernel docs
  pata_via: Correct missing comments
  pata_atiixp: propogate cable detection hack from drivers/ide to the new driver
  ahci/pata_jmicron: fix JMicron quirk

Some LLDDs, like ipr, use nbytes and pad_len to determine
the total data transfer length of a command. Make sure
nbytes gets initialized for internally generated commands.
Signed-off-by: NBrian King <brking@linux.vnet.ibm.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>

> Looks like you should use ata_busy_wait() here, rather than reproducing
> the same code again.

It waits in 10uS chunks while 1uS chunks were used in the workaround.
Could indeed do that once I know the fix is right. While I'm at it the
ata_busy_wait kerneldoc is borked so here's a fix
Signed-off-by: NAlan Cox <alan@redhat.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>