1. 09 11月, 2018 1 次提交
    • J
      s390/qeth: utilize virtual MAC for Layer2 OSD devices · b144b99f
      Julian Wiedmann 提交于
      By default, READ MAC on a Layer2 OSD device returns the adapter's
      burnt-in MAC address. Given the default scenario of many virtual devices
      on the same adapter, qeth can't make any use of this address and
      therefore skips the READ MAC call for this device type.
      
      But in some configurations, the READ MAC command for a Layer2 OSD device
      actually returns a pre-provisioned, virtual MAC address. So enable the
      READ MAC code to detect this situation, and let the L2 subdriver
      call READ MAC for OSD devices.
      
      This also removes the QETH_LAYER2_MAC_READ flag, which protects L2
      devices against calling READ MAC multiple times. Instead protect the
      whole call to qeth_l2_request_initial_mac().
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b144b99f
  2. 04 11月, 2018 4 次提交
  3. 13 10月, 2018 2 次提交
  4. 27 9月, 2018 3 次提交
  5. 18 9月, 2018 7 次提交
  6. 10 8月, 2018 3 次提交
  7. 22 7月, 2018 7 次提交
  8. 13 7月, 2018 3 次提交
  9. 30 6月, 2018 2 次提交
    • J
      s390/qeth: consistently re-enable device features · d025da9e
      Julian Wiedmann 提交于
      commit e830baa9 ("qeth: restore device features after recovery") and
      commit ce344356 ("s390/qeth: rely on kernel for feature recovery")
      made sure that the HW functions for device features get re-programmed
      after recovery.
      
      But we missed that the same handling is also required when a card is
      first set offline (destroying all HW context), and then online again.
      Fix this by moving the re-enable action out of the recovery-only path.
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d025da9e
    • J
      s390/qeth: don't clobber buffer on async TX completion · ce28867f
      Julian Wiedmann 提交于
      If qeth_qdio_output_handler() detects that a transmit requires async
      completion, it replaces the pending buffer's metadata object
      (qeth_qdio_out_buffer) so that this queue buffer can be re-used while
      the data is pending completion.
      
      Later when the CQ indicates async completion of such a metadata object,
      qeth_qdio_cq_handler() tries to free any data associated with this
      object (since HW has now completed the transfer). By calling
      qeth_clear_output_buffer(), it erronously operates on the queue buffer
      that _previously_ belonged to this transfer ... but which has been
      potentially re-used several times by now.
      This results in double-free's of the buffer's data, and failing
      transmits as the buffer descriptor is scrubbed in mid-air.
      
      The correct way of handling this situation is to
      1. scrub the queue buffer when it is prepared for re-use, and
      2. later obtain the data addresses from the async-completion notifier
         (ie. the AOB), instead of the queue buffer.
      
      All this only affects qeth devices used for af_iucv HiperTransport.
      
      Fixes: 0da9581d ("qeth: exploit asynchronous delivery of storage blocks")
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ce28867f
  10. 28 4月, 2018 7 次提交
  11. 23 4月, 2018 1 次提交
    • J
      s390/qeth: avoid control IO completion stalls · 901e3f49
      Julian Wiedmann 提交于
      For control IO, qeth currently tracks the index of the buffer that it
      expects to complete the next IO on each qeth_channel. If the channel
      presents an IRQ while this buffer has not yet completed, no completion
      processing for _any_ completed buffer takes place.
      So if the 'next buffer' is skipped for any sort of reason* (eg. when it
      is released due to error conditions, before the IO is started), the
      buffer obviously won't switch to PROCESSED until it is eventually
      allocated for a _different_ IO and completes.
      Until this happens, all completion processing on that channel stalls
      and pending requests possibly time out.
      
      As a fix, remove the whole 'next buffer' logic and simply process any
      IO buffer right when it completes. A channel will never have more than
      one IO pending, so there's no risk of processing out-of-sequence.
      
      *Note: currently just one location in the code really handles this problem,
             by advancing the 'next' index manually.
      Signed-off-by: NJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      901e3f49