1. 19 9月, 2017 4 次提交
    • J
      s390/qeth: don't take queue lock in send_packet_fast() · 7c2e9ba3
      Julian Wiedmann 提交于
      Locking the output queue prior to TX is needed on OSA devices,
      to synchronize against a packing flush from the TX completion code
      (via qeth_check_outbound_queue()).
      But send_packet_fast() is only used for IQDs, which don't do packing.
      So remove the locking, and apply some easy cleanups.
      Signed-off-by: NJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Reviewed-by: NUrsula Braun <ubraun@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7c2e9ba3
    • H
      s390/qeth: add VNICC get/set timeout support · 349d13d5
      Hans Wippel 提交于
      HiperSockets allow configuring so called VNIC Characteristics (VNICC)
      that influence how the underlying hardware handles packets. For VNICCs,
      additional commands for getting and setting timeouts are available.
      Currently, the learning VNICC uses these commands.
      
      * Learning VNICC: If learning is enabled on a qeth device, the device
        learns the source MAC addresses of outgoing packets and incoming
        packets to those learned MAC addresses are received.
      
      For learning, the timeout specifies the idle period in seconds, after
      which the underlying hardware removes a learned MAC address again.
      
      This patch adds support for the IPA commands that are required to get
      and set the current timeout values for the learning VNIC characteristic.
      Also, it introduces the sysfs interface that allows users to configure
      the timeout.
      Signed-off-by: NHans Wippel <hwippel@linux.vnet.ibm.com>
      Reviewed-by: NJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: NJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      349d13d5
    • H
      s390/qeth: add VNICC enable/disable support · caa1f0b1
      Hans Wippel 提交于
      HiperSocket devices allow enabling and disabling so called VNIC
      Characteristics (VNICC) that influence how the underlying hardware
      handles packets. These VNICCs are:
      
      * Flooding VNICC: Flooding allows specifying if packets to unknown
        destination MAC addresses are received by the qeth device.
      
      * Multicast flooding VNICC: Multicast flooding allows specifying if
        packets to multicast MAC addresses are received by the qeth device.
      
      * Learning VNICC: If learning is enabled on a qeth device, the device
        learns the source MAC addresses of outgoing packets and incoming
        packets to those learned MAC addresses are received.
      
      * Takeover setvmac VNICC: If takeover setvmac is configured on a qeth
        device, the MAC address of this device can be configured on a
        different qeth device with the setvmac IPA command.
      
      * Takeover by learning VNICC: If takeover learning is enabled on a qeth
        device, the MAC address of this device can be learned (learning VNICC)
        on a different qeth device.
      
      * BridgePort invisible VNICC: If BridgePort invisible is enabled on a
        qeth device, (1) packets from this device are not sent to a BridgePort
        enabled qeth device and (2) packets coming from a BridgePort enabled
        qeth device are not received by this device.
      
      * Receive broadcast VNICC: Receive broadcast allows configuring if a
        qeth device receives packets with the broadcast destination MAC
        address.
      
      This patch adds support for the IPA commands that are required to enable
      and disable these VNIC characteristics on qeth devices. As a
      prerequisite, it also adds the query commands IPA command.
      
      The query commands IPA command allows requesting the supported commands
      for each characteristic from the underlying hardware.
      
      Additionally, this patch provides users with a sysfs user interface to
      enable/disable the VNICCs mentioned above.
      Signed-off-by: NHans Wippel <hwippel@linux.vnet.ibm.com>
      Reviewed-by: NJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: NJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      caa1f0b1
    • H
      s390/qeth: add basic VNICC support · a45b3faf
      Hans Wippel 提交于
      VNIC Characteristics (VNICC) are features of HiperSockets that define
      how packets are handled by the underlying network hardware. For example,
      if the VNICC flooding is configured on a qeth device, ethernet frames to
      unknown destination MAC addresses are received.
      
      Currently, there is support for seven VNICCs: flooding, multicast
      flooding, receive broadcast, learning, takeover learning, takeover
      setvmac, bridge invisible. Also, six IPA commands exist for configuring
      VNICCs on a qeth device: query characteristics, query commands, enable
      characteristic, disable characteristic, set timeout, get timeout.
      
      This patch adds the basic code infrastructure for VNICC support to qeth.
      It allows querying VNICC support from the underlying hardware. To this
      end, it adds:
      
      * basic message formats for IPA commands
      * basic data structures
      * basic error handling
      * query characteristics IPA command support
      
      The query characteristics IPA command allows requesting the currently
      supported and currently enabled VNIC characteristics from the underlying
      hardware.
      
      Support for the other IPA commands and for the configuration of VNICCs
      is added in follow-up patches together with the respective user
      interface functions.
      Signed-off-by: NHans Wippel <hwippel@linux.vnet.ibm.com>
      Reviewed-by: NJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: NJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a45b3faf
  2. 19 8月, 2017 3 次提交
  3. 16 8月, 2017 2 次提交
  4. 21 6月, 2017 1 次提交
  5. 07 6月, 2017 1 次提交
  6. 12 5月, 2017 1 次提交
    • J
      s390/qeth: unbreak OSM and OSN support · 2d2ebb3e
      Julian Wiedmann 提交于
      commit b4d72c08 ("qeth: bridgeport support - basic control")
      broke the support for OSM and OSN devices as follows:
      
      As OSM and OSN are L2 only, qeth_core_probe_device() does an early
      setup by loading the l2 discipline and calling qeth_l2_probe_device().
      In this context, adding the l2-specific bridgeport sysfs attributes
      via qeth_l2_create_device_attributes() hits a BUG_ON in fs/sysfs/group.c,
      since the basic sysfs infrastructure for the device hasn't been
      established yet.
      
      Note that OSN actually has its own unique sysfs attributes
      (qeth_osn_devtype), so the additional attributes shouldn't be created
      at all.
      For OSM, add a new qeth_l2_devtype that contains all the common
      and l2-specific sysfs attributes.
      When qeth_core_probe_device() does early setup for OSM or OSN, assign
      the corresponding devtype so that the ccwgroup probe code creates the
      full set of sysfs attributes.
      This allows us to skip qeth_l2_create_device_attributes() in case
      of an early setup.
      
      Any device that can't do early setup will initially have only the
      generic sysfs attributes, and when it's probed later
      qeth_l2_probe_device() adds the l2-specific attributes.
      
      If an early-setup device is removed (by calling ccwgroup_ungroup()),
      device_unregister() will - using the devtype - delete the
      l2-specific attributes before qeth_l2_remove_device() is called.
      So make sure to not remove them twice.
      
      What complicates the issue is that qeth_l2_probe_device() and
      qeth_l2_remove_device() is also called on a device when its
      layer2 attribute changes (ie. its layer mode is switched).
      For early-setup devices this wouldn't work properly - we wouldn't
      remove the l2-specific attributes when switching to L3.
      But switching the layer mode doesn't actually make any sense;
      we already decided that the device can only operate in L2!
      So just refuse to switch the layer mode on such devices. Note that
      OSN doesn't have a layer2 attribute, so we only need to special-case
      OSM.
      
      Based on an initial patch by Ursula Braun.
      
      Fixes: b4d72c08 ("qeth: bridgeport support - basic control")
      Signed-off-by: NJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2d2ebb3e
  7. 12 4月, 2017 7 次提交
  8. 07 4月, 2017 3 次提交
  9. 25 3月, 2017 1 次提交
    • J
      s390/qeth: size calculation outbound buffers · 7d969d2e
      Julian Wiedmann 提交于
      Depending on the device type, hard_start_xmit() builds different output
      buffer formats. For instance with HiperSockets, on both L2 and L3 we
      strip the ETH header from the skb - L3 doesn't need it, and L2 carries
      it in the buffer's header element.
      For this, we pass data_offset = ETH_HLEN all the way down to
      __qeth_fill_buffer(), where skb->data is then adjusted accordingly.
      But the initial size calculation still considers the *full* skb length
      (including the ETH header). So qeth_get_elements_no() can erroneously
      reject a skb as too big, even though it would actually fit into an
      output buffer once the ETH header has been trimmed off later.
      
      Fix this by passing an additional offset to qeth_get_elements_no(),
      that indicates where in the skb the on-wire data actually begins.
      Since the current code uses data_offset=-1 for some special handling
      on OSA, we need to clamp data_offset to 0...
      
      On HiperSockets this helps when sending ~MTU-size skbs with weird page
      alignment. No change for OSA or AF_IUCV.
      Signed-off-by: NJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: NUrsula Braun <ubraun@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7d969d2e
  10. 12 1月, 2017 3 次提交
  11. 16 9月, 2016 1 次提交
    • H
      qeth: restore device features after recovery · e830baa9
      Hans Wippel 提交于
      After device recovery, only a basic set of network device features is
      enabled on the device. If features like checksum offloading or TSO were
      enabled by the user before the recovery, this results in a mismatch
      between the network device features, that the kernel assumes to be
      enabled on the device, and the features actually enabled on the device.
      
      This patch tries to restore previously set features, that require
      changes on the device, after the recovery of a device. In case of an
      error, the network device's features are changed to contain only the
      features that are actually turned on.
      Signed-off-by: NHans Wippel <hwippel@linux.vnet.ibm.com>
      Signed-off-by: NUrsula Braun <ubraun@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e830baa9
  12. 17 6月, 2016 5 次提交
  13. 15 12月, 2015 1 次提交
  14. 07 10月, 2015 1 次提交
  15. 22 9月, 2015 2 次提交
  16. 19 5月, 2015 1 次提交
  17. 18 1月, 2015 1 次提交
  18. 27 10月, 2014 1 次提交
  19. 03 9月, 2014 1 次提交