1. 20 Mar, 2015 7 commits
  2. 19 Mar, 2015 27 commits
  3. 18 Mar, 2015 6 commits
    • David S. Miller's avatar
      Merge branch 'txq_max_rate' · 8f6320de
      David S. Miller authored
      Or Gerlitz says:
      
      ====================
      Add max rate TXQ attribute
      
      Add the ability to set a max-rate limitation for TX queues.
      The attribute name is maxrate and the units are Mbs, to make
      it similar to the existing max-rate limitation knobs (ETS and
      SRIOV ndo calls).
      
      changes from V2:
        - added Documentation (thanks Florian and Tom)
        - rebased to latest net-next to comply with the swdev ndo removal
        - addressed more feedback from Dave on the comments style
      
      changes from V1:
        - addressed feedback from Dave
      
      changes from V0:
        - addressed feedback from Sergei
      
      John Fastabend (1):
        net: Add max rate tx queue attribute
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8f6320de
    • Or Gerlitz's avatar
      net/mlx4_en: Add tx queue maxrate support · c10e4fc6
      Or Gerlitz authored
      Add ndo_set_tx_maxrate support.
      
      To support per tx queue maxrate limit, we use the update-qp firmware
      command to do run-time rate setting for the qp that serves this tx ring.
      Signed-off-by: default avatarOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: default avatarIdo Shamay <idos@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c10e4fc6
    • Or Gerlitz's avatar
      net/mlx4_core: Add basic support for QP max-rate limiting · fc31e256
      Or Gerlitz authored
      Add the low-level device commands and definitions used for QP max-rate limiting.
      
      This is done through the following elements:
      
        - read rate-limit device caps in QUERY_DEV_CAP: number of different
          rates and the min/max rates in Kbs/Mbs/Gbs units
      
        - enhance the QP context struct to contain rate limit units and value
      
        - allow to do run time rate-limit setting to QPs through the
          update-qp firmware command
      
        - QP rate-limiting is disallowed for VFs
      Signed-off-by: default avatarOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fc31e256
    • John Fastabend's avatar
      net: Add max rate tx queue attribute · 822b3b2e
      John Fastabend authored
      This adds a tx_maxrate attribute to the tx queue sysfs entry allowing
      for max-rate limiting. Along with DCB-ETS and BQL this provides another
      knob to tune queue performance. The limit units are Mbps.
      
      By default it is disabled. To disable the rate limitation after it
      has been set for a queue, it should be set to zero.
      Signed-off-by: default avatarJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: default avatarOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      822b3b2e
    • Brad Campbell's avatar
      cc2520: Add support for CC2591 amplifier. · f0b7d43c
      Brad Campbell authored
      The TI CC2521 is an RF power amplifier that is designed to interface
      with the CC2520. Conveniently, it directly interfaces with the CC2520
      and does not require any pins to be connected to a
      microcontroller/processor. Adding a CC2591 increases the CC2520's range,
      which is useful for border router and other wall-powered applications.
      
      Using the CC2591 with the CC2520 requires configuring the CC2520 GPIOs
      that are connected to the CC2591 to correctly set the CC2591 into TX and
      RX modes. Further, TI recommends that the CC2520_TXPOWER and
      CC2520_AGCCTRL1 registers are set differently to maximize the CC2591's
      performance. These settings are covered in TI Application Note AN065.
      
      This patch adds an optional `amplified` field to the cc2520 entry in the
      device tree. If present, the CC2520 will be configured to operate with a
      CC2591.
      
      The expected pin mapping is:
      CC2520 GPIO0 --> CC2591 EN
      CC2520 GPIO5 --> CC2591 PAEN
      Signed-off-by: default avatarBrad Campbell <bradjc5@gmail.com>
      Acked-by: default avatarVarka Bhadram <varkabhadram@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      f0b7d43c
    • Brad Campbell's avatar
      cc2520: Do not store platform_data in spi_device · 0db055c9
      Brad Campbell authored
      Storing the `platform_data` struct inside of the SPI struct when using
      the device tree allows for a later function to edit the content of that
      struct. This patch refactors the `cc2520_get_platformat_data` function
      to accept a pointer to a `cc2520_platform_data` struct and populates
      the fields inside of it.
      
      This change mirrors commit aaa1c4d2
      ("at86rf230: copy pdata to driver allocated space").
      Signed-off-by: default avatarBrad Campbell <bradjc5@gmail.com>
      Acked-by: default avatarVarka Bhadram <varkabhadram@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      0db055c9