1. 19 9月, 2017 2 次提交
  2. 19 8月, 2017 5 次提交
  3. 16 8月, 2017 5 次提交
  4. 01 7月, 2017 1 次提交
  5. 21 6月, 2017 2 次提交
  6. 16 6月, 2017 1 次提交
    • J
      networking: introduce and use skb_put_data() · 59ae1d12
      Johannes Berg 提交于
      A common pattern with skb_put() is to just want to memcpy()
      some data into the new space, introduce skb_put_data() for
      this.
      
      An spatch similar to the one for skb_put_zero() converts many
      of the places using it:
      
          @@
          identifier p, p2;
          expression len, skb, data;
          type t, t2;
          @@
          (
          -p = skb_put(skb, len);
          +p = skb_put_data(skb, data, len);
          |
          -p = (t)skb_put(skb, len);
          +p = skb_put_data(skb, data, len);
          )
          (
          p2 = (t2)p;
          -memcpy(p2, data, len);
          |
          -memcpy(p, data, len);
          )
      
          @@
          type t, t2;
          identifier p, p2;
          expression skb, data;
          @@
          t *p;
          ...
          (
          -p = skb_put(skb, sizeof(t));
          +p = skb_put_data(skb, data, sizeof(t));
          |
          -p = (t *)skb_put(skb, sizeof(t));
          +p = skb_put_data(skb, data, sizeof(t));
          )
          (
          p2 = (t2)p;
          -memcpy(p2, data, sizeof(*p));
          |
          -memcpy(p, data, sizeof(*p));
          )
      
          @@
          expression skb, len, data;
          @@
          -memcpy(skb_put(skb, len), data, len);
          +skb_put_data(skb, data, len);
      
      (again, manually post-processed to retain some comments)
      Reviewed-by: NStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      59ae1d12
  7. 12 6月, 2017 1 次提交
  8. 07 6月, 2017 4 次提交
  9. 12 5月, 2017 2 次提交
    • 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
    • U
      s390/qeth: handle sysfs error during initialization · 9111e788
      Ursula Braun 提交于
      When setting up the device from within the layer discipline's
      probe routine, creating the layer-specific sysfs attributes can fail.
      Report this error back to the caller, and handle it by
      releasing the layer discipline.
      Signed-off-by: NUrsula Braun <ubraun@linux.vnet.ibm.com>
      [jwi: updated commit msg, moved an OSN change to a subsequent patch]
      Signed-off-by: NJulian Wiedmann <jwi@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9111e788
  10. 12 4月, 2017 8 次提交
  11. 07 4月, 2017 5 次提交
  12. 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
  13. 12 1月, 2017 3 次提交