linux-stable.git/drivers/ide, branch linux-2.6.31.y

slc90e66: fix UDMA handling

2009-12-18T21:43:50+00:00

[ Upstream commit ee31527a02b0a8e1aa4a5e4084d2db5fa34737ed ]

Fix checking of the currently programmed UDMA mode.

Signed-off-by: Bartlomiej Zolnierkiewicz 
Acked-by: Sergei Shtylyov 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Revert "ide: try to use PIO Mode 0 during probe if possible"

2009-12-18T21:43:49+00:00

[ Upstream commit 0fb18c4777ff424c1db694af98443a201fa4fc30 ]

This reverts commit 6029336426a2b43e4bc6f4a84be8789a047d139e.

Ok, we really do need to revert this, even with Bart's sis5513.c
fix in there.

The problem is that several driver's ->set_pio_mode() method
depends upon the drive->media type being set properly.  Most
of them use this to enable prefetching, which can only be done
for disk media.

But the commit being reverted here calls ->set_pio_mode() before
it's setup.  Actually it considers everything disk because that
is the default media type set by ide_port_init_devices_data().

The set of drivers that depend upon the media type in their
->set_pio_method() are:

drivers/ide/alim15x3.c
drivers/ide/it8172.c
drivers/ide/it8213.c
drivers/ide/pdc202xx_old.c
drivers/ide/piix.c
drivers/ide/qd65xx.c
drivers/ide/sis5513.c
drivers/ide/slc90e66.c

And it is possible that we could fix this by guarding the prefetching
and other media dependent setting changes with a test on
IDE_PFLAG_PROBING in hwif->port_flags, that's simply too risky for
2.6.32-rcX and -stable.

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ide: fix ioctl to pass requested transfer mode to ide_find_dma_mode instead of UDMA6

2009-12-18T21:43:49+00:00

[ Upstream commit 28c1969ff887bc2a7df39272850dece01de03285 ]

Currently, ide_cmd_ioctl when invoked for setting DMA transfer mode calls
ide_find_dma_mode with requested mode as XFER_UDMA_6. This prevents setting DMA
mode to any other value than the default (maximum) supported by the device (or
UDMA6, if supported) irrespective of the actual requested transfer mode and
returns error.

For example, setting mode to UDMA2 using hdparm, where UDMA4 is the default
transfer mode gives following error:
	# ./hdparm -d1 -Xudma2  /dev/hda
	 /dev/hda:hda: UDMA/66 mode selected
	 setting using_dma to 1 (on)
	 hda: UDMA/66 mode selected
	 setting xfermode to 66 (UltraDMA mode2)
	 HDIO_DRIVE_CMD(setxfermode) failed: Invalid argument
	 using_dma     =  1 (on)

This patch fixes the issue.

Signed-off-by: Hemant Pedanekar 
Acked-by: Bartlomiej Zolnierkiewicz 
Acked-by: Sergei Shtylyov 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ide: Serialize CMD643 and CMD646 to fix a hardware bug with SSD

2009-12-18T21:43:49+00:00

[ Upstream commit 9bd7496f5dd488e109e91d9d5743915fb4dfbfde ]

CMD646 corrupts data on concurrent transfers on both channels when IDE SSD is
connected to one of the channels.

Setup that demonstrates this hardware bug: Ultra 5, onboard CMD646, rev 3.
/dev/hda is 8GB Seagate ST38410A in MWDMA2
/dev/hdd is 32GB SSD SiliconHardDisk in MWDMA2

- When reading /dev/hdd (for example with dd or fsck), reads from /dev/hda
  are corrupted, there are twiddled single bits 1->0 and some full 32-bit
  words corrupted, sometimes commands fail (which switches /dev/hda to
  PIO mode but the corruptions happen even in PIO).
- Reads from /dev/hdd don't seem to be corrupted (i.e. fsck passes fine).
- When I connected normal rotating harddisk to /dev/hdd, there was no
  corruption, so the corruption is something specific to SSD.
- I tried the same setup on a PCI card with CMD649 and saw no corruption.

This patch serializes the operation for CMD646 and 643 (I didn't test
CMD643 but it may have the same hw bug too because it's earlier design).
CMD649 is good. I don't know anything about CMD 648.

Signed-off-by: Mikulas Patocka 
Tested-by: Frans Pop 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sis5513: fix PIO setup for ATAPI devices

2009-10-12T19:40:21+00:00

commit e13ee546bb06453939014c7b854e77fb643fd6f1 upstream.

Clear prefetch setting before potentially (re-)enabling it in
config_drive_art_rwp() so the transition of the device type on
the port from ATA to ATAPI (i.e. during warm-plug operation)
is handled correctly.

This is a really old bug (it probably goes back to very early
days of the driver) but it was only affecting warm-plug operation
until the recent "ide: try to use PIO Mode 0 during probe if
possible" change (commit 6029336426a2b43e4bc6f4a84be8789a047d139e).

Signed-off-by: Bartlomiej Zolnierkiewicz 
Tested-by: David Fries 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

pcmcia: add CNF-CDROM-ID for ide

2009-08-14T20:09:32+00:00

Fixes this report:
http://article.gmane.org/gmane.linux.kernel.pcmcia.devel/2228/

Reported-by: John McGrath 
Signed-off-by: Wolfram Sang 
Signed-off-by: David S. Miller

ide-tape: Don't leak kernel stack information

2009-07-22T03:36:25+00:00

Don't leak kernel stack information through uninitialized structure members.

Signed-off-by: Michael Buesch 
Acked-by: Borislav Petkov .
Signed-off-by: David S. Miller

ide: fix memory leak when flush command is issued

2009-07-22T03:23:46+00:00

I'm using ide on 2.6.30.1 with xfs filesystem. I noticed a kernel memory
leak after writing lots of data, the kmalloc-96 slab cache keeps
growing. It seems the struct ide_cmd kmalloced by idedisk_prepare_flush
is never kfreed.

Commit a09485df9cda49fbde2766c86eb18a9cae585162 ("ide: move request
type specific code from ide_end_drive_cmd() to callers (v3)") and
f505d49ffd25ed062e76ffd17568d3937fcd338c ("ide: fix barriers support")
cause this regression, cmd->rq must now be set for ide_complete_cmd to
honor the IDE_TFLAG_DYN flag.

Signed-off-by: Maxime Bizon 
Acked-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: David S. Miller

Revert "ide: improve handling of Power Management requests"

2009-07-06T19:39:27+00:00

This reverts commit a1317f714af7aed60ddc182d0122477cbe36ee9b.

ide: memory overrun in ide_get_identity_ioctl() on big endian machines using ioctl HDIO_OBSOLETE_IDENTITY

2009-06-30T02:31:41+00:00

This patch fixes a memory overrun in function ide_get_identity_ioctl() which
chooses the size of a memory buffer depending on the ioctl command that led
to the function call, however, passes that buffer to a function which needs the
buffer size to be always chosen unconditionally.

Due to conditional compilation the memory overrun can only happen on big endian
machines. The error can be triggered using ioctl HDIO_OBSOLETE_IDENTITY. Usage
of ioctl HDIO_GET_IDENTITY is safe.

Signed-off-by: Christian Engelmayer 
Acked-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: David S. Miller