1. 27 8月, 2020 1 次提交
  2. 01 8月, 2020 2 次提交
  3. 15 7月, 2020 1 次提交
  4. 28 5月, 2020 1 次提交
    • A
      s390/cio, s390/qeth: cleanup PNSO CHSC · a0138f59
      Alexandra Winter 提交于
      CHSC3D (PNSO - perform network subchannel operation) is used for
      OC0 (Store-network-bridging-information) as well as for
      OC3 (Store-network-address-information). So common fields are renamed
      from *brinfo* to *pnso*.
      Also *_bridge_host_* is changed into *_addr_change_*, e.g.
      qeth_bridge_host_event to qeth_addr_change_event, for the
      same reasons.
      The keywords in the card traces are changed accordingly.
      
      Remove unused L3 types, as PNSO will only return Layer2 entries.
      
      Make PNSO CHSC implementation more consistent with existing API usage:
      Add new function ccw_device_pnso() to drivers/s390/cio/device_ops.c and
      the function declaration to arch/s390/include/asm/ccwdev.h, which takes
      a struct ccw_device * as parameter instead of schid and calls
      chsc_pnso().
      
      PNSO CHSC has no strict relationship to qdio. So move the calling
      function from qdio to qeth_l2 and move the necessary structures to a
      new file arch/s390/include/asm/chsc.h.
      
      Do response code evaluation only in chsc_error_from_response() and
      use return code in all other places. qeth_anset_makerc() was meant to
      evaluate the PNSO response code, but never did, because pnso_rc was
      already non-zero.
      
      Indentation was corrected in some places.
      Signed-off-by: NAlexandra Winter <wintera@linux.ibm.com>
      Reviewed-by: NPeter Oberparleiter <oberpar@linux.ibm.com>
      Reviewed-by: NVineeth Vijayan <vneethv@linux.ibm.com>
      Reviewed-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
      a0138f59
  5. 07 5月, 2020 2 次提交
  6. 28 3月, 2020 2 次提交
    • J
      s390/qeth: phase out OSN support · fb64de1b
      Julian Wiedmann 提交于
      OSN devices currently spend an awful long time in qeth_l2_set_online()
      until various unsupported HW cmds time out. This has been broken for
      over two years, ever since
      commit d22ffb5a ("s390/qeth: fix IPA command submission race")
      triggered a FW bug in cmd processing.
      Prior to commit 782e4a79 ("s390/qeth: don't poll for cmd IO completion"),
      this wait for timeout would have even been spent busy-polling.
      
      The offending patch was picked up by stable and all relevant distros,
      and yet noone noticed.
      OSN setups only ever worked in combination with an out-of-tree blob, and
      the last machine that even offered HW with OSN support was released back
      in 2015.
      
      Rather than attempting to work-around this FW issue for no actual gain,
      add a deprecation warning so anyone who still wants to maintain this
      part of the code can speak up. Else rip it all out in 2021.
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fb64de1b
    • J
      s390/qeth: make OSN / OSX support configurable · 4e2b5aa5
      Julian Wiedmann 提交于
      The last machine generation that supports OSN is z13, and OSX is only
      supported up to z14. Allow users and distros to decide whether they
      still need support for these device types.
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4e2b5aa5
  7. 26 3月, 2020 2 次提交
  8. 19 3月, 2020 4 次提交
  9. 11 3月, 2020 1 次提交
  10. 10 3月, 2020 1 次提交
  11. 21 2月, 2020 1 次提交
  12. 26 1月, 2020 5 次提交
  13. 27 12月, 2019 1 次提交
  14. 25 12月, 2019 4 次提交
    • A
      s390/qeth: vnicc Fix init to default · d1b9ae18
      Alexandra Winter 提交于
      During vnicc_init wanted_char should be compared to cur_char and not
      to QETH_VNICC_DEFAULT. Without this patch there is no way to enforce
      the default values as desired values.
      
      Note, that it is expected, that a card comes online with default values.
      This patch was tested with private card firmware.
      
      Fixes: caa1f0b1 ("s390/qeth: add VNICC enable/disable support")
      Signed-off-by: NAlexandra Winter <wintera@linux.ibm.com>
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d1b9ae18
    • A
      s390/qeth: Fix vnicc_is_in_use if rx_bcast not set · e8a66d80
      Alexandra Winter 提交于
      Symptom: After vnicc/rx_bcast has been manually set to 0,
      	bridge_* sysfs parameters can still be set or written.
      Only occurs on HiperSockets, as OSA doesn't support changing rx_bcast.
      
      Vnic characteristics and bridgeport settings are mutually exclusive.
      rx_bcast defaults to 1, so manually setting it to 0 should disable
      bridge_* parameters.
      
      Instead it makes sense here to check the supported mask. If the card
      does not support vnicc at all, bridge commands are always allowed.
      
      Fixes: caa1f0b1 ("s390/qeth: add VNICC enable/disable support")
      Signed-off-by: NAlexandra Winter <wintera@linux.ibm.com>
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e8a66d80
    • A
      s390/qeth: fix false reporting of VNIC CHAR config failure · 68c57bfd
      Alexandra Winter 提交于
      Symptom: Error message "Configuring the VNIC characteristics failed"
      in dmesg whenever an OSA interface on z15 is set online.
      
      The VNIC characteristics get re-programmed when setting a L2 device
      online. This follows the selected 'wanted' characteristics - with the
      exception that the INVISIBLE characteristic unconditionally gets
      switched off.
      
      For devices that don't support INVISIBLE (ie. OSA), the resulting
      IO failure raises a noisy error message
      ("Configuring the VNIC characteristics failed").
      For IQD, INVISIBLE is off by default anyways.
      
      So don't unnecessarily special-case the INVISIBLE characteristic, and
      thereby suppress the misleading error message on OSA devices.
      
      Fixes: caa1f0b1 ("s390/qeth: add VNICC enable/disable support")
      Signed-off-by: NAlexandra Winter <wintera@linux.ibm.com>
      Reviewed-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      68c57bfd
    • J
      s390/qeth: fix qdio teardown after early init error · 8b5026bc
      Julian Wiedmann 提交于
      qeth_l?_set_online() goes through a number of initialization steps, and
      on any error uses qeth_l?_stop_card() to tear down the residual state.
      
      The first initialization step is qeth_core_hardsetup_card(). When this
      fails after having established a QDIO context on the device
      (ie. somewhere after qeth_mpc_initialize()), qeth_l?_stop_card() doesn't
      shut down this QDIO context again (since the card state hasn't
      progressed from DOWN at this stage).
      
      Even worse, we then call qdio_free() as final teardown step to free the
      QDIO data structures - while some of them are still hooked into wider
      QDIO infrastructure such as the IRQ list. This is inevitably followed by
      use-after-frees and other nastyness.
      
      Fix this by unconditionally calling qeth_qdio_clear_card() to shut down
      the QDIO context, and also to halt/clear any pending activity on the
      various IO channels.
      Remove the naive attempt at handling the teardown in
      qeth_mpc_initialize(), it clearly doesn't suffice and we're handling it
      properly now in the wider teardown code.
      
      Fixes: 4a71df50 ("qeth: new qeth device driver")
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8b5026bc
  15. 21 12月, 2019 1 次提交
    • J
      s390/qeth: fix promiscuous mode after reset · 0f399305
      Julian Wiedmann 提交于
      When managing the promiscuous mode during an RX modeset, qeth caches the
      current HW state to avoid repeated programming of the same state on each
      modeset.
      
      But while tearing down a device, we forget to clear the cached state. So
      when the device is later set online again, the initial RX modeset
      doesn't program the promiscuous mode since we believe it is already
      enabled.
      Fix this by clearing the cached state in the tear-down path.
      
      Note that for the SBP variant of promiscuous mode, this accidentally
      works right now because we unconditionally restore the SBP role while
      re-initializing.
      
      Fixes: 4a71df50 ("qeth: new qeth device driver")
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Reviewed-by: NAlexandra Winter <wintera@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0f399305
  16. 06 12月, 2019 1 次提交
    • J
      s390/qeth: fix dangling IO buffers after halt/clear · f9e50b02
      Julian Wiedmann 提交于
      The cio layer's intparm logic does not align itself well with how qeth
      manages cmd IOs. When an active IO gets terminated via halt/clear, the
      corresponding IRQ's intparm does not reflect the cmd buffer but rather
      the intparm that was passed to ccw_device_halt() / ccw_device_clear().
      This behaviour was recently clarified in
      commit b91d9e67 ("s390/cio: fix intparm documentation").
      
      As a result, qeth_irq() currently doesn't cancel a cmd that was
      terminated via halt/clear. This primarily causes us to leak
      card->read_cmd after the qeth device is removed, since our IO path still
      holds a refcount for this cmd.
      
      For qeth this means that we need to keep track of which IO is pending on
      a device ('active_cmd'), and use this as the intparm when calling
      halt/clear. Otherwise qeth_irq() can't match the subsequent IRQ to its
      cmd buffer.
      Since we now keep track of the _expected_ intparm, we can also detect
      any mismatch; this would constitute a bug somewhere in the lower layers.
      In this case cancel the active cmd - we effectively "lost" the IRQ and
      should not expect any further notification for this IO.
      
      Fixes: 40554895 ("s390/qeth: add support for dynamically allocated cmds")
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f9e50b02
  17. 21 11月, 2019 1 次提交
    • J
      s390/qeth: fix potential deadlock on workqueue flush · c8183f54
      Julian Wiedmann 提交于
      The L2 bridgeport code uses the coarse 'conf_mutex' for guarding access
      to its configuration state.
      This can result in a deadlock when qeth_l2_stop_card() - called under the
      conf_mutex - blocks on flush_workqueue() to wait for the completion of
      pending bridgeport workers. Such workers would also need to aquire
      the conf_mutex, stalling indefinitely.
      
      Introduce a lock that specifically guards the bridgeport configuration,
      so that the workers no longer need the conf_mutex.
      Wrapping qeth_l2_promisc_to_bridge() in this fine-grained lock then also
      fixes a theoretical race against a concurrent qeth_bridge_port_role_store()
      operation.
      
      Fixes: c0a2e4d1 ("s390/qeth: conclude all event processing before offlining a card")
      Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
      Reviewed-by: NAlexandra Winter <wintera@linux.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c8183f54
  18. 15 11月, 2019 2 次提交
  19. 01 11月, 2019 1 次提交
  20. 10 10月, 2019 2 次提交
  21. 25 8月, 2019 1 次提交
  22. 21 8月, 2019 3 次提交