* check ->speedproc return value in ide_tune_dma()
* use ide_tune_dma() in cmd64x/cs5530/sc1200/siimage/sl82c105/scc_pata drivers
* remove no longer needed ide_dma_enable()
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Add the speedproc() method for setting transfer modes, modify config_for_dma()
to call it and use ide_max_dma_mode() to select the best DMA mode.
Add support for the multiword DMA modes 0 and 1, using the upper half of the
'drive_data' field to store the DMA timings to program into the drive control
register when DMA is turned on for real.
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

* add {cs5530,sc1200}_tunepio() for programming PIO timings

* add {cs5530,sc1200}_tune_chipset() (->speedproc method) for setting
  transfer mode and convert {cs5530,sc1200}_config_dma() to use it

* bump driver version
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

sc1200.c:

* remove open-coded variant of ide_dma_host_off() (== ->dma_host_off),
  it is not needed because ->dma_off_quietly calls ->dma_host_off

* use ->dma_host_on (== ide_dma_host_on() for this driver) instead of
  open-coded variant, call it from the users of sc1200_config_dma2()

  [ there is no need to call ->dma_host_on in sc1200_config_dma() because
    core code takes care of calling ->ide_dma_on on successful execution
    of ->ide_dma_check ]

* add comment about ->tuneproc interface abuse

cs5530.c/sc1200.c:

* core code takes care of calling ->dma_off_quietly before calling
  ->ide_dma_check so there is no need to call it in ->ide_dma_check methods

* bump driver version
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Use ide_tune_dma() in ide-cris/it821x/pdc202xx_old/serverworks drivers.
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

CS5530/SC1200 specifies that two drives on the same cable cannot mix
UDMA/MDMA.  Add {cs5530,sc1200}_udma_filter() to handle this.  This also
makes it possible to remove open-coded best DMA mode selection and use
standard ide_use_dma()/ide_max_dma_mode() helpers.  While at it bump
version numbers.

There should be no functionality changes caused by this patch.
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

ide_start_power_step() and set_using_dma() were missing ->dma_off_quietly
call (comment in probe_hwif() states that DMA should be always cleared before
tuning is attempted).  Fix it.
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

* remove code enabling IORDY and prefetch from config_chipset_for_dma(),
  as the comment states it has no real effect because these settings are
  overriden when the PIO mode is set (and for this driver ->autotune == 1
  so PIO mode is always programmed)

* use ide_tune_dma() in pdcnew_config_drive_xfer_rate() and remove no longer
  needed config_chipset_for_dma()

There should be no functionality changes caused by this patch.
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Use ide_tune_dma() in ali15x3_config_drive_for_dma() and remove all the open
coded DMA tuning code and also config_chipset_for_dma().  Set ->atapi_dma flag
correctly in init_hwif_common_ali15x3() so ide_tune_dma() can take care of
checking if ATAPI DMA is allowed and remove open coded ATAPI DMA check from
ali15x3_config_drive_for_dma().

There should be no functionality changes caused by this patch.
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

* limit max PIO mode to PIO4, this driver doesn't support PIO5 and attempt
  to program PIO5 by config_art_rwp_pio() could result in incorrect PIO
  timings being programmed and possibly the data corruption (for < ATA100
  family chipsets PIO0 timings were used, for ATA100 and ATA100a - the random
  content of test1 variable was used, for ATA133 - MWDMA0 timings were used)

* BUG() in sis5513_tune_chipset() if somebody tries to force unsupported PIO5,
  also cleanup this function a bit while at it

* add comment about PIO0 timings for < ATA100 family chipsets

* remove open-coded best PIO mode selection from config_art_rwp_pio(),
  it contained numerous bugs:

  - it didn't check for validity of id->eide_pio_modes and id->eide_pio_iordy
    before using them

  - it tried to found out maximum PIO mode basing on minimum IORDY cycle time
    (moreover wrong cycle times were used for PIO1/5)

  - it was overriding PIO blacklist and conservative PIO "downgrade" done
    by ide_get_best_pio_mode()

* use sis5513_tune_drive() instead of config_art_rwp_pio()
  in sis5513_config_xfer_rate() so the correct PIO mode is also set
  on drive even if the device is not IORDY/DMA capable

* config_art_rwp_pio() was always setting the best possible mode and not
  the wanted one - fix it and move ide_get_best_pio_mode() call to
  config_chipset_for_pio()

* don't use ide_find_best_mode() in config_chipset_for_pio(), it was being
  overriden by config_art_rwp_pio() for the host timings anyway + we need to
  set the same PIO mode on the device and the host

* pass correct "pio" argument (255 instead of 5) to sis5513_tune_drive() call
  in sis5513_config_xfer_rate() so the best PIO mode is set on the drive
  and not PIO4

* rename sis5513_tune_drive() to sis5513_tuneproc()
  and config_chipset_for_pio() to sis5513_tune_driver()

* bump driver version
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

* limit max PIO mode to PIO4, this driver doesn't support PIO5 and attempt
  to program PIO5 by svwks_tune_chipset() could result in incorrect PIO
  timings being programmed and possibly the data corruption (it seems that
  the minimum possible values were used but I lack the datasheets to be sure)

* select best PIO mode in svwks_tune_drive() and not in svwks_tune_chipset()
  when doing PIO autotuning (pio == 255)

* don't try to tune PIO in config_chipset_for_dma() as ide_dma_enable() could
  return 1 if DMA was previously enabled (svwks_config_drive_xfer_rate()
  takes care of PIO tuning if no suitable DMA mode is found)

* remove config_chipset_for_pio() and use svwks_tune_drive() instead,
  config_chipset_for_pio() contained numerous bugs when selecting PIO mode
  (luckily it was only used for devices limited to PIO by capabilities/BIOS):

  - it didn't check for validity of id->eide_pio_modes and id->eide_pio_iordy
    before using them

  - it tried to found out maximum PIO mode basing on minimum IORDY cycle time
    (moreover wrong cycle times were used for PIO0/1/5)

  - it was overriding PIO blacklist and conservative PIO "downgrade" done
    by ide_get_best_pio_mode()

  - if the max drive PIO was PIO5 then XFER_PIO_0/XFER_PIO_SLOW was selected
    (XFER_PIO_SLOW is not supported by svwks_tune_chipset() so the result
     was the same as if using XFER_PIO_5 => wrong PIO timings were set)

  - it was overriding drive->current_speed

* bump driver version
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

This patch is based on the documentation (I would like to thank Promise
for it) and also partially on the older vendor driver.

Rewrite mode programming code:

* disable 66MHz clock in pdc202xx_tune_chipset() so it is correctly disabled
  even if both devices on the channel are not DMA capable and after reset

* enable/disable IORDY and PREFETCH bits in pdc202xx_tune_chipset()
  as they need to be setup correctly also for PIO only devices, plus IORDY
  wasn't disabled for non-IORDY devices and PREFETCH wasn't disabled for
  ATAPI devices

* remove dead code for setting SYNC_ERDDY_EN bits from config_chipset_for_dma()
  (driver sets ->autotune to 1 so PIO modes are always programmed => lower
   nibble of register A never equals 4 => "chipset_is_set" is always true)

* enable PIO mode programming for all ATAPI devices
  (it was limited to ->media == ide_cdrom devices)

* remove extra reads of registers A/B/C, don't read register D et all

* do clearing / programming of registers A/B/C in one go
  (gets rid of extra PCI config space read/write cycle)

* set initial values of drive_conf/AP/BP/CP variables to zero
  (paranoia for the case when PCI reads fail)

* remove XFER_UDMA6 to XFER_UDMA5 remapping case - it can't happen
  (ide_rate_filter() takes care of it)

* fix XFER_MW_DMA0 timings (they were overclocked, use the official ones)

* fix bitmasks for clearing bits of register B:

  - when programming DMA mode bit 0x10 of register B was cleared which
    resulted in overclocked PIO timing setting (iff PIO0 was used)

  - when programming PIO mode bits 0x18 weren't cleared so suboptimal
    timings were used for PIO1-4 if PIO0 was previously set (bit 0x10)
    and for PIO0/3/4 if PIO1/2 was previously set (bit 0x08)

* add FIXME comment about missing locking for 66MHz clock register

Also while at it:

* remove unused defines

* do a few cosmetic / CodingStyle fixes

* bump driver version

v2:
* in pdc202xx_tune_chipset() the old content of drive configuration
  registers is used only by the debugging code so cover "drive_conf"
  PCI registers read by #if PDC202XX_DEBUG_DRIVE_INFO
  (Noticed by Sergei Shtylyov)
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

This reverts commit f64da958.

Andi Kleen is unhappy with the changes, and they really do not seem
worth it.  IPMI could use DIE_NMI_IPI instead of the new callback, even
though that ends up having its own set of problems too, mainly because
the IPMI code cannot really know the NMI was from IPMI or not.

Manually fix up conflicts in arch/x86_64/kernel/traps.c and
drivers/char/ipmi/ipmi_watchdog.c.

Cc: Andi Kleen <ak@suse.de>
Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Corey Minyard <minyard@acm.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

In the presence of some running RX connections, we repeat
queue_delayed_work calls each 4 RX WRs, which is a waste.  It's enough
to start stale task when a first passive connection is added, and
rerun it every IPOIB_CM_RX_DELAY as long as there are outstanding
passive connections.

This removes some code from RX data path.
Signed-off-by: NMichael S. Tsirkin <mst@dev.mellanox.co.il>
Signed-off-by: NRoland Dreier <rolandd@cisco.com>

mthca_cq_clean() updates the CQ consumer index without moving CQEs
back to HW ownership.  As a result, the same WRID might get reported
twice, resulting in a use-after-free.  This was observed in IPoIB CM.
Fix by moving all freed CQEs to HW ownership.

This fixes <https://bugs.openfabrics.org/show_bug.cgi?id=617>
Signed-off-by: NMichael S. Tsirkin <mst@dev.mellanox.co.il>
Signed-off-by: NRoland Dreier <rolandd@cisco.com>

Fix posting lists of > 255 receive WRs for Tavor: rq.next_ind must
be updated each doorbell, otherwise the next doorbell will use an
incorrect index.

Found by Ronni Zimmermann at Mellanox.
Signed-off-by: NMichael S. Tsirkin <mst@dev.mellanox.co.il>
Signed-off-by: NRoland Dreier <rolandd@cisco.com>

Several checks in the rdma_cm check against the state of the
cm_id, but only to validate that the cm_id is bound to an underlying
transport specific CM and an RDMA device.  Make the check explicit
in what we're trying to check for, since we're not synchronizing
against the cm_id state.

This will allow a user to disconnect a cm_id or reject a connection
after receiving a device removal event.
Signed-off-by: NSean Hefty <sean.hefty@intel.com>
Signed-off-by: NRoland Dreier <rolandd@cisco.com>

The cma_iw_handler needs to validate the state of the rdma_cm_id before
processing a new connection request to ensure that a device removal is
not already being processed for the same rdma_cm_id.  Without the state
check, the user can receive simultaneous callbacks for the same cm_id, or
a callback after they've destroyed the cm_id.
Signed-off-by: NSean Hefty <sean.hefty@intel.com>
Signed-off-by: NRoland Dreier <rolandd@cisco.com>

Add a new routine and rename another to encapsulate common code for
synchronizing with device removal.
Signed-off-by: NSean Hefty <sean.hefty@intel.com>
Signed-off-by: NRoland Dreier <rolandd@cisco.com>

- Scaling code is still considered experimental, so disable it by default
- Increase version to SVNEHCA_0023
Signed-off-by: NJoachim Fenkes <fenkes@de.ibm.com>
Signed-off-by: NRoland Dreier <rolandd@cisco.com>

eHCA's sysfs attributes are now being created via sysfs_create_group(),
making the process neatly table-driven. The return value is checked, thus
fixing a few compiler warnings.
Signed-off-by: NJoachim Fenkes <fenkes@de.ibm.com>
Signed-off-by: NRoland Dreier <rolandd@cisco.com>

- In ehca_process_eq(), we're IRQ safe throughout the whole function, so we
  don't need another _irqsave in the middle of flight.

- take_over_work() is only called by comp_pool_callback(), so it can move
  into the same #ifdef block.
Signed-off-by: NJoachim Fenkes <fenkes@de.ibm.com>
Signed-off-by: NRoland Dreier <rolandd@cisco.com>

AQP0/1 should report qp_num={0|1} and the actual QP# should be stored
in struct ehca_qp, not the other way round.
Signed-off-by: NJoachim Fenkes <fenkes@de.ibm.com>
Signed-off-by: NRoland Dreier <rolandd@cisco.com>

The driver needs to always supply the "GRH present" flag to the
hypervisor, whether it's true or false. Not supplying it (i.e. not
setting the corresponding mask bit) amounts to a "perhaps", which we
don't want.
Signed-off-by: NJoachim Fenkes <fenkes@de.ibm.com>
Signed-off-by: NRoland Dreier <rolandd@cisco.com>

Some pSeries hypervisor versions show a race condition in the allocate
MR hCall.  Serialize this call per adapter to circumvent this problem.
Signed-off-by: NJoachim Fenkes <fenkes@de.ibm.com>
Signed-off-by: NRoland Dreier <rolandd@cisco.com>

Once upon a time, GPIO interrupts were rare.  But then a chip bug in
the waldo series forced the use of a GPIO interrupt to signal packet
reception.  This greatly increased the frequency of GPIO interrupts
which have the gpio_mask bits set on the waldo chips.  Other bits in
the gpio_status register are used for I2C clock and data lines, these
bits are usually on.  An "unlikely" annotation leftover from the old
days was improperly applied to these bits, and an unnecessary chip
mmio read was being accessed in the interrupt fast path on waldo.

Remove the stagnant unlikely annotation in the interrupt handler and
keep a shadow copy of the gpio_mask register to avoid the slow mmio
read when testing for interruptable GPIO bits.
Signed-off-by: NArthur Jones <arthur.jones@qlogic.com>
Signed-off-by: NRoland Dreier <rolandd@cisco.com>

uar_lock spinlock was used in mlx4_ib_cq_arm without being initialized
(this only affects 32-bit archs, because uar_lock is not used on
64-bit archs and MLX4_INIT_DOORBELL_LOCK() is a NOP).
Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: NRoland Dreier <rolandd@cisco.com>

... and make it depend on the response flag instead of the command type.
Signed-off-by: NNicolas Pitre <npitre@mvista.com>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

The MMC block devices now have an assigned major. Make sure
we actually use it.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

When the device hits certain memory boundaries, it signals an
interrupt and expects to be serviced. We don't need the feature
but we need to make sure the device doesn't stall.
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

This patch has changed command types check from data flags.

MMC_STOP_TRANSMISSION is never passed to au1xmmc_send_command().
SEND_STOP() is used for MMC_STOP_TRANSMISSION.
Signed-off-by: NYoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>

Otherwise the allmodconfig build breaks.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The 'compatible' property can be SUNW,sun4v-console as
well as 'qcn'.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

... doh

Jeremy Fitzhardinge noted that the recent loop.c cleanups worked, but
cause lockdep to complain.

Ouch.  OK, the deadlock is real and yes, I'm an idiot.  Speaking of which,
we probably want to s/lock/pin/ in drivers/base/map.c to avoid such
brainos again.  And yes, this stuff needs clear documentation.  Will try
to put one together once I get some sleep...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

struct mlx4_priv.doorbell_lock is never used, so delete it.
Signed-off-by: NRoland Dreier <rolandd@cisco.com>

CONFIG_MLX4_DEBUG works out to a def_bool y for those that have 
CONFIG_EMBEDDED set.  Make it depend on MLX4_CORE.
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
Signed-off-by: NRoland Dreier <rolandd@cisco.com>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Acked-by: NKen Chen <kenchen@google.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>