This changes the uevent buffer functions to use a struct instead of a
long list of parameters. It does no longer require the caller to do the
proper buffer termination and size accounting, which is currently wrong
in some places. It fixes a known bug where parts of the uevent
environment are overwritten because of wrong index calculations.
Many thanks to Mathieu Desnoyers for finding bugs and improving the
error handling.
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6: (24 commits)
ide: use only ->set_pio_mode method for programming PIO modes (take 2)
sis5513: don't change UDMA settings when programming PIO
it8213/piix/slc90e66: don't change DMA settings when programming PIO
alim15x3: PIO mode setup fixes
siimage: fix ->set_pio_mode method to select PIO data transfer
cs5520: don't enable VDMA in ->speedproc
sc1200: remove redundant warning message from sc1200_tune_chipset()
ide-pmac: PIO mode setup fixes (take 3)
icside: fix ->speedproc to return on unsupported modes (take 5)
sgiioc4: use ide_tune_dma()
amd74xx/via82cxxx: use ide_tune_dma()
ide: add ide_set{_max}_pio() (take 4)
ide: Kconfig face-lift
ide: move ide_rate_filter() calls to the upper layer (take 2)
sis5513: add ->udma_filter method for chipset_family >= ATA_133
ide: mode limiting fixes for user requested speed changes
ide: add missing ide_rate_filter() calls to ->speedproc()-s
ide: call udma_filter() before resorting to the UltraDMA mask
ide: make jmicron match vendor and device class
pdc202xx_new: switch to using pci_get_slot() (take 2)
...
Use ->set_pio_mode method to program PIO modes in ide_set_xfer_rate()
(the only place which used ->speedproc to program PIO modes) and remove
handling of PIO modes from all ->speedproc implementations.
v2:
* Fix pmac_ide_tune_chipset() comment.
There should be no functionality changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* Return failure in ->speedproc method for unsupported/invalid transfer
modes passed from user-space (fixes theoretical OOPS in ali_tune_pio()
and/or setting random PIO timings on host controller + disabling UDMA
bit + setting unsupported/invalid transfer mode on the device).
* Don't disable UDMA bit when programming PIO modes.
* Add FIXME about DMA timings never being set.
* Bump driver version.
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* Remember to select PIO data transfer (with IORDY monitored) in sil_tune_pio()
(->set_pio_mode method) so the controller is always programmed correctly for
PIO transfers (this is important if DMA is not going to be used).
* Don't set DMA/UDMA timings for PIO modes in siimage_tune_chipset().
* Bump driver version.
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
There is no need to do it in cs5520_tune_chipset() (->speedproc method)
since it is correctly handled by cs5520_dma_on() (->ide_dma_on method).
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
ide_config_drive_speed() called by sc1200_set_xfer_mode() already gives
a meaningful warning message in case of failure.
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* Add { 0, 0 } entry to {kauai,shasta}_pio_timings[] so kauai_lookup_timing()
always returns a valid PIO timing (fixes PIO timing not being set for devices
with minimum PIO cycle <= 120ns).
* Add setting transfer mode on the device to pmac_ide_set_pio_mode().
* Fix pmac_ide_set_pio() to always program chipset for given PIO timing instead
of only when the device we want to program PIO timing for is the currently
selected one.
* Now that pmac_ide_set_pio() is fixed there is no need to set transfer mode
on the device and program chipset for PIO in pmac_ide_tune_chipset()
(returning 0 == success is not entirely correct but is OK for now since
the upper layers are only checking ->speedproc return value for DMA modes).
v2:
* s/speed/XFER_PIO_0 + pio/ in pmac_ide_set_pio_mode() so it actually compiles.
* Removal of kauai_lookup_timing() return value checking went to separate patch.
v3:
* Use XFER_PIO_0 not XFER_PIO. (Noticed by Ben)
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* All other implementations of ->speedproc return zero on success
and non-zero on failure. Currently it doesn't matter for icside host
driver and isn't a bug per se since:
- ide_set_xfer_rate() return value is ignored by all IDE core users
- icside doesn't (yet!) use ide_tune_dma() in icside_dma_check()
but sooner or later we will need to fix anyway - so lets do it now.
* icside_set_speed() happily accepts unsupported transfer modes which
results in drive->drive_data being set to the maximum value (480)
and drive->current_speed being set to the unsupported transfer mode.
Fix it.
v2:
* The initial version of the patch was broken because it didn't take into
the account (the different from usual) return values of icside_set_speed()
(Noticed by Russell).
v3:
* Remove no longer needed initialization/checking of cycle_time
(Noticed by Sergei).
* No need to set drive->drive_data if DMA is not going to be used
(Noticed by Sergei).
* Remove incorrect setting of drive->current_speed
(Noticed by Sergei).
* Move ide_config_drive_speed() at the end of icside_set_speed().
v4:
* If DMA mode is not found in icside_dma_check() then just return "-1" and
don't call icside_set_speed() (v3 got it wrong and "1" was returned instead).
v5:
* Return "-1"/"0" in icside_set_speed() instead of icside_dma_check() return
value (just like it was before this patch).
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* Add DRV_NAME define and use it instead of sgiioc4_chipset.name.
* Remove no longer needed sgiioc4_chipset.
* Remove needless clearing of ->atapi_dma from ide_dma_sgiioc4().
* Fix ide_dma_sgiioc4() to return success/failure. Check return value in
sgiioc4_ide_setup_pci_device() and set hwif->autodma accordingly. Also add
missing setting of drive->autodma.
* Add sgiioc4_speedproc() (implementation of ->speedproc method).
* Fix ->mwdma_mask (MWDMA2 mask is 0x04 not 0x02) and remove incorrect
->swdma_mask. Also remove needless initialization of ->ultra_mask.
* Use ide_tune_dma() in sgiioc4_ide_dma_check(), this fixes following bugs:
- DMA capability bit not being checked on the device
- DMA blacklist not being checked
- MWDMA2 mode support by device not being checked
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Jeremy Higdon <jeremy@sgi.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* Use ide_tune_dma() in amd74xx/via82cxxx driver, this fixes following bugs:
- DMA capability bit not being checked on the device
- DMA blacklist not being checked
- DMA mode being programmed even if drive->autodma == 0
(thus possibly destroying PIO timings)
* Bump driver version.
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* Add IDE_HFLAG_ABUSE_{PREFETCH,FAST_DEVSEL,DMA_MODES} flags
and set them in ht6560, cmd640, cmd64x and sc1200 host drivers.
* Add set_pio_mode_abuse() for checking if host driver has a non-standard
->tuneproc() implementation and use it in do_special().
* Add ide_set_pio() for setting PIO mode (it uses hwif->pio_mask to find
the maximum PIO mode supported by the host), also add ide_set_max_pio()
wrapper for ide_set_pio() to use for auto-tuning. Convert users of
->tuneproc to use ide_set{_max}_pio() where possible. This leaves only
do_special(), set_using_pio(), ide_hwif_restore() and ide_set_pio() as
a direct users of ->tuneproc.
* Remove no longer needed ide_get_best_pio_mode() calls and printk-s
reporting PIO mode selected from ->tuneproc implementations.
* Rename ->tuneproc hook to ->set_pio_mode and make 'pio' argument const.
* Remove stale comment from ide_config_drive_speed().
v2:
* Fix "ata_" prefix (Noticed by Jeff).
v3:
* Minor cleanups/fixups per Sergei's suggestions.
v4:
* Fix compile problem in drivers/ide/pci/cmd640.c
(Noticed by Andrew Morton).
* Improve some ->set_pio_mode comments.
Reviewed-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* Convert config options for PCI host drivers to select BLK_DEV_IDEPCI.
* Same for BLK_DEV_IDEDMA_PCI and PCI DMA host drivers, also make this
config option select BLK_DEV_IDEPCI.
* Remove no longer needed help for BLK_DEV_IDEPCI and BLK_DEV_IDEDMA_PCI.
* Remove redundant IDE_CHIPSETS config option.
As a result of this patch users have now three less config options
to worry about and can just select host drivers that they need
(IDE config menu is "flatter").
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* Move ide_rate_filter() calls from host drivers to IDE core.
* Make ide_rate_filter() static.
* Make 'speed' argument of ->speedproc const.
v2:
* Fix it8213_tune_chipset() comment.
There should be no functionality changes caused by this patch.
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* Add sis5513_ata133_udma_filter() for chipset_family >= ATA_133,
use it to filter UDMA6 mode if ATA133 bit is disabled.
* Remove no longer needed UDMA6 limiting logic from sis5513_tune_chipset().
* Bump driver version.
There should be no functionality changes caused by this patch.
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* Add an extra argument to ide_max_dma_mode() for passing requested transfer
mode. Use it as an upper limit when finding the best DMA for device/host.
* Rename ide_max_dma_mode() to ide_find_dma_mode() and at the same time add
ide_max_dma_mode() wrapper which passes XFER_UDMA_6 as a requested mode to
ide_find_dma_mode(). Also add inline ide_find_dma_mode() version for
CONFIG_BLK_DEV_IDEDMA=n case.
* Pass requested transfer mode from ide_find_dma_mode() to ide_get_mode_mask()
to avoid false warning from eighty_ninty_three().
* Use ide_find_dma_mode() to limit the user requested transfer mode in
ide_rate_filter(). Also limit the requested mode by host max PIO mode.
Above changes make ide_rate_filter() to:
* Clip desired transfer mode down if it is invalid (values 0x0F, 0x13-0x19
and 0x25-0x39, values > 0x46 were already clipped down, same for values
0x25-0x39 but iff UDMA was not supported by the host).
* Clip desired transfer mode down if it is currently unsupported by IDE core
(PIO6 and MWDMA3-4, the latter were already clipped down but iff UDMA was
not supported by the host).
* Clip desired transfer mode down according to the host capabilities
(UDMA modes were already clipped down but MWDMA/SWDMA/PIO weren't,
also ->atapi_dma flag was not respected).
* Clip desired transfer mode down according to the device capabilities
(except PIO modes for now which require mode work) - shouldn't be a
problem since ide_set_xfer_rate() is called _after_ device has accepted
given transfer mode.
and also result in a number of host driver specific bugfixes:
* icside
- clip unsupported PIO5 mode down
- fix unsupported/invalid modes being set in drive->current_speed
* ide-cris
- clip unsupported PIO5 and SWDMA0-2 modes down
- clip DMA modes down for ATAPI devices
- fix BUG() on unsupported/invalid modes
* au1xxx-ide
- clip unsupported PIO5, SWDMA0-2 and MWDMA0-2
(if BLK_DEV_IDE_AU1XXX_MDMA2_DBDMA=n) modes down
* aec62xx
- clip unsupported PIO5 and SWDMA0-2 modes down
- clip DMA modes down for ATAPI devices
- fix 0x00 being programmed as PIO timing for unsupported/invalid modes
- fix unsupported/invalid modes being set on the device
* alim15x3
- clip DMA modes down for ATAPI devices (chipset revision == 0x20 only)
- fix theoretical OOPS for 0x0F mode
- fix unsupported/invalid modes being set on the device
* amd74xx
- clip unsupported SWDMA0-2 (on COBRA_7401 revs <= 7) modes down
- fix random PIO timings being set for unsupported/invalid modes
- fix unsupported/invalid modes being set on the device
* atiixp
- clip unsupported PIO5 and SWDMA0-2 modes down
- fix cached MWDMA mode being cleared for unsupported/invalid modes
- fix PIO{0,2} timings being programmed for unsupported/invalid modes
- fix theoretical OOPS for PIO5-6 and 0x0F modes
- fix unsupported/invalid modes being set on the device
* cmd64x
- clip unsupported SWDMA0-2 modes down
* cs5530
- clip unsupported PIO5 and SWDMA0-2 modes down
- fix unsupported/invalid modes being set on the device
- fix BUG() on unsupported/invalid modes
(which happened if the device accepted the setting)
* cs5535
- clip unsupported PIO5 and SWDMA0-2 modes down
- fix unsupported/invalid modes being set on the device
- fix theoretical OOPS for PIO5-6 and 0x0F modes
* hpt34x
- clip DMA modes down for ATAPI devices
- fix invalid timings being programmed for unsupported/invalid modes
- fix unsupported/invalid modes being set on the device
* hpt366
- clip unsupported PIO5 and SWDMA0-2 modes down
- fix PIO0 timings being programmed for unsupported/invalid modes
- fix DMA timings being cleared for MWDMA3-4 and 0x25-0x39 modes
- fix unsupported/invalid modes being set on the device
* it8213
- clip unsupported PIO5, SWDMA0-1 and MWDMA0 modes down
* it821x
- clip unsupported PIO5 and SWDMA0-2 modes down
- clip DMA modes down for ATAPI devices
(chipset in smart mode and revision 0x10 in pass-through mode)
* jmicron
- clip unsupported SWDMA0-2 modes down
- fix unsupported/invalid modes being set on the device
* pdc202xx_new
- clip unsupported PIO5 and SWDMA0-2 modes down
- fix unsupported/invalid modes being set on the device
* pdc202xx_old
- clip unsupported PIO5 mode down
- fix incorrect timings being set for unsupported/invalid modes
- fix unsupported/invalid modes being set on the device
* piix
- clip unsupported PIO5, SWDMA0-1 and MWDMA0 modes down
* sc1200
- clip unsupported PIO5 and SWDMA0-2 modes down
- fix unsupported/invalid modes being set on the device
- fix BUG() on unsupported/invalid modes
(which happened if the device accepted the setting)
* scc_pata
- clip unsupported PIO5, SWDMA0-2 and MWDMA0-2 modes down
* serverworks
- clip unsupported PIO5 and SWDMA0-2 modes down
- fix DMA/UDMA timings/settings being cleared for unsupported/invalid modes
- fix unsupported/invalid modes being set on the device
* siimage
- clip unsupported PIO5 and SWDMA0-2 modes down
- clip DMA modes down for ATAPI devices (SATA chipsets)
* sis5513
- clip unsupported PIO5 mode down
- fix BUG() on unsupported/invalid modes
* sl82c105
- clip unsupported SWDMA0-2 modes down
* slc90e66
- clip unsupported PIO5, SWDMA0-1 and MWDMA0 modes down
* tc86c001
- clip unsupported PIO5 and SWDMA0-2 modes down
- fix PIO0 timings being programmed for PIO5/0x0F/SWDMA0-2/0x13-0x19 modes
- fix invalid 0x00 DMA timing being programmed for MWDMA3-4/0x25-0x39 modes
- fix unsupported/invalid modes being set on the device
* triflex
- clip unsupported PIO5 mode down
* via82cxxx
- fix random PIO timings being set for unsupported/invalid modes
- fix unsupported/invalid modes being set on the device
* pmac
- clip unsupported PIO5 and SWDMA0-2 modes down
* cmd640/ht6560b
- clip DMA modes down (if CONFIG_BLK_DEV_IDEDMA=y)
- fix PIO5 being clipped to PIO4 (if CONFIG_BLK_DEV_IDEDMA=n)
* opti621
- clip DMA modes down (if CONFIG_BLK_DEV_IDEDMA=y)
- clip unsupported PIO4 to PIO3 (if CONFIG_BLK_DEV_IDEDMA=n)
While at it:
* Use ide_rate_filter() in cs5520.c::cs5520_tune_chipset().
* Remove no longer needed checks from hpt366.c::hpt3{6,7}x_tune_chipset().
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
* Fix icside, cris-ide, au1xxx-ide, amd74xx, via82cxxx and pmac host drivers
to use ide_rate_filter().
This results in the following modes (from user requests) being clipped down:
- invalid modes (values 0x46-0xFF) [ for all hosts ]
- unsupported by a host UDMA modes [ for hosts which support UDMA]
- all UDMA modes and MWDMA3-4 modes [ for hosts which don't support UDMA ]
- invalid modes (values 0x25-0x39) [ for hosts which don't support UDMA ]
* Host driver specific changes in behavior:
icside:
- no change
cris-ide
- clip unsupported UDMA3-6 modes down
- fix BUG() on trying to set unsupported UDMA3-6 modes
au1xxx-ide/pmac
- clip unsupported UDMA modes down
amd74xx/via82cxxx
- clip unsupported UDMA modes down
- fix random PIO timings being set for unsupported/invalid modes
- fix unsupported/invalid modes being set on the device
* While at it remove no longer needed checks from pmac.c driver.
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Give the udma_filter() method call precedence over using the mode masks.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
PATA part of all current JMB controllers behave the same way and
JMicron confirms that all future ones will stay compatible. Matching
vendor and device class is enough.
For backward compatibility, jmicron still needs to match 361,3,5,6,8
DIDs regardless of device class if libata is not configured but won't
need further DID update from this point.
Bart: cosmetic fixes to jmicron_chipset
Signed-off-by: Tejun Heo <htejun@gmail.com>
Cc: Ethan Hsiao <ethanhsiao@jmicron.com>
Cc: Justin Tsai <justin@jmicron.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Switch to using pci_get_slot() in init_setup_pdc20270() to get to the mate chip
behind DC21150 bridge as there's no need for the driver itself to walk the list
of the PCI devices (and the driver didn't check the bus # of the found device).
While at it, make it emit warning about IRQ # being fixed up (just like hpt366.c
does) and "beautify" this whole function as well as init_setup_pdc20276()...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
ACPI spec defines the sequence of IDE power on/off:
Powering down:
Call _GTM.
Power down drive (calls _PS3 method and turns off power planes).
Powering up:
Power up drive (calls _PS0 method if present and turns on power planes).
Call _STM passing info from _GTM (possibly modified), with ID data from
each drive.
Initialize the channel.
May modify the results of _GTF.
For each drive:
Call _GTF.
Execute task file (possibly modified).
This patch adds the missed _PS0/_PS3 methods call.
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Acked-by: Len Brown <len.brown@intel.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
This is now very similar to pata_platform.c, they both use
same platform data structure and same resources.
To achieve that, byte_lanes_swapping platform data variable
and platform specified iops removed from that driver. It's fine,
since those were never used anyway.
pata_platform and ide_platform are carrying same driver names,
to easily switch between these drivers, without need to touch
platform code.
Bart:
- build fix from Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Acked-by: Alan Cox <alan@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
The Marvell bridge chips used on HighPoint SATA cards do not seem to support
the MWDMA modes (at least that could be seen in their so-called drivers :-),
so the driver needs to account for this -- to achieve this:
- add mdma_filter() method from the original patch by Bartlomiej Zolnierkiewicz
with his consent;
- install the method for all chips to only return empty mask if a SATA drive
is detected on HPT372{AN]/374 chips...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
SB700 supports one physical IDE channel, but SB700 SATA controller
supports combined mode. When the SATA combined mode is enabled,
two SATA ports (port4 and port5) share one IDE channel from IDE
controller, and PATA will share the other IDE channel.
Our previous patch adding SB700 IDE device ID only supports one
IDE channel, which contains bug. The attached patch fixes the bug.
Signed-off-by: "Shane Huang" <Shane.Huang@amd.com>
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Every usage of rq_for_each_bio wraps a usage of
bio_for_each_segment, so these can be combined into
rq_for_each_segment.
We define "struct req_iterator" to hold the 'bio' and 'index' that
are needed for the double iteration.
Signed-off-by: Neil Brown <neilb@suse.de>
Various compile fixes by me...
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Three main sets of changes:
1) dmi_get_system_info() return value should have been marked const,
since callers should not be changing that data.
2) const-ify DMI internals, since DMI firmware tables should,
whenever possible, be marked const to ensure we never ever write to
that data area.
3) const-ify DMI API, to enable marking tables const where possible
in low-level drivers.
And if we're really lucky, this might enable some additional
optimizations on the part of the compiler.
The bulk of the changes are #2 and #3, which are interrelated. #1 could
have been a separate patch, but it was so small compared to the others,
it was easier to roll it into this changeset.
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
The PCI device table in the powermac IDE driver isn't properly
terminated. Depending on how your kernel is linked and other random
factors, you can end up with this driver matched against any other PCI
device in your system, possibly crashing at boot.
Thanks to Heikki for tracking this down with me, the bug have been there
for some time, though it rarely hurts due to luck. In this case, the
switch from .22 to .23-rc9 is causing it to show up due to differences
in the resulting layout of .data I suppose.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <pmac@au1.ibm.com>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Cc: Heikki Lindholm <holindho@cs.helsinki.fi>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix a bitmask typo in the pdc202xx_new PLL frequency detection code
which causes it to truncate an intermediate difference to 26 bits
instead of the correct 30 bits (the PLL's bitwidth).
Signed-off-by: Mikael Pettersson <mikpe@it.uu.se>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Port of Alan's patch for pata_via.c.
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Mikael Pettersson <mikpe@it.uu.se>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Ensure that BLK_DEV_IDE is built-in before allowing BLK_DEV_IDE_PMAC to
be selected.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
Cc: Bret Towe <magnade@gmail.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Add Toshiba S1800-814 to whitelist for both pata_ali and alim15x3,
as it is correctly detected as 40-wire connected but this cable is
short enough to still use transfer modes higher than UDMA33.
Signed-off-by: Daniel Exner <dex@dragonslave.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
The Marvell bridge chips used on HighPoint SATA cards do not seem to support
the UltraDMA modes 1, 2, and 3 as well as any MWDMA modes, so the driver needs
to account for this in the udma_filter() method. In order to achieve that, do
the following changes:
- install the method for all chips, not only HPT36x/370 and improve the code
formatting by killing the extra tabs while at it;
- add to the end of the 'switch' statement in the method cases for HPT372[AN]
and HPT374 chips upon which the known SATA cards are based;
- use hwif->ultra_mask as a default mask for the ide_dma_filter() method to
behave correctly;
- move the HPT370[A] cases below the HPT36x case for consistency.
While at it, replace the explicit UltraDMA mode masks with ATA_UDMA* constants
all over the driver...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Bob Ham <rah@bash.sh>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Make the SATA drive detection code from eighty_ninty_three() into inline
ide_dev_is_sata() helper fixing it along the way to be more strict while
checking word 80 for the reserved values...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
HPT374 BIOS seems to only save f_CNT register value for the function #0 before
re-tuning DPLL (that causes the driver to report obviously distorted f_CNT for
the function #1) -- fix this by always reading the saved f_CNT register value
from the function #0 in the driver's init_chipset() method.
While at it, introduce 'chip_type' for holding the 'struct hpt_info' field
of the same name and replace the structure assignment with memcpy()...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
The driver erroneously "lets go" the mate IDE chip in init_setup_pdc20270()
when ide_setup_pci_devices() call succeeds -- fix this, and drop a couple of
useless assignments in this function while at it...
Bart: keep "findev" variable initialization to silence gcc
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
The IDE core never marked the PCI IDE devices as being in use after succesfull
driver probe call (the devices were marked in use only while being probed), and
so was susceptible to issues caused by unsolicited PCI hotplug device removal.
So, add pci_dev_get() call to ide_scan_pcidev() and convert this function to
the kernel style, also dropping a bunch of useless curly braces from its caller,
ide_scan_pcibus() and somewhat beautifying printk() call there, while at it...
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Currently the mpc8xx ide driver will only work on arch/ppc so only
allow it to be built there. Also, killed a minor include that isn't
actually used by the driver.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
This disk reports total number of sectors instead of maximum sector address
in response to READ_NATIVE_MAX_ADDRESS command and also happily accepts
SET_MAX_ADDRESS command with the bogus value. This results in +1 sector
capacity being used and errors on attempts to use the last sector.
...
hdd: Host Protected Area detected.
    current capacity is 78165360 sectors (40020 MB)
    native  capacity is 78165361 sectors (40020 MB)
hdd: Host Protected Area disabled.
...
hdd: reading: block=78165360, sectors=1, buffer=0xc1e63000
hdd: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hdd: dma_intr: error=0x10 { SectorIdNotFound }, LBAsect=78165360, sector=78165360
...
Add hpa_list[] table and workaround the issue in idedisk_check_hpa().
v2:
* Add missing export and improve patch description a bit.
v3:
* Add list termination. (From Mikko)
Fixes kernel bugzilla bug #8816.
Thanks to Mikko for investigating the issue and helping with this patch.
Cc: Mikko Rapeli <mikko.rapeli@iki.fi>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Programming DMA mode may destroy current PIO mode setting so if
CONFIG_HPT34X_AUTODMA=n (the default case) make ide_tune_dma() fail
early by disabling all host DMA masks and re-tune PIO mode.
This fix doesn't help with the driver being broken but is needed
for some other changes.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
If ->dma_base is not set (== PCI BAR4 cannot be reserved) then DMA hooks
shouldn't be initialized or bad things will happen.
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
If ->dma_base is not set (== PCI BAR4 cannot be reserved) then DMA hooks
shouldn't be initialized or bad things will happen.
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
If ->dma_base is not set (== PCI BAR4 cannot be reserved) then DMA hooks
shouldn't be initialized or bad things will happen.
Also this host driver requires valid PCI BAR4 for normal operation so
check it in ->init_chipset and fail initialization if not set.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
If ->dma_base is not set (== PCI BAR4 cannot be reserved) then DMA hooks
shouldn't be initialized or bad things will happen.
Also this host driver requires valid PCI BAR4 for normal operation so
check it in ->init_chipset and fail initialization if not set.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
