1. 01 10月, 2018 18 次提交
  2. 24 9月, 2018 1 次提交
    • E
      netpoll: make ndo_poll_controller() optional · ac3d9dd0
      Eric Dumazet 提交于
      As diagnosed by Song Liu, ndo_poll_controller() can
      be very dangerous on loaded hosts, since the cpu
      calling ndo_poll_controller() might steal all NAPI
      contexts (for all RX/TX queues of the NIC). This capture
      can last for unlimited amount of time, since one
      cpu is generally not able to drain all the queues under load.
      
      It seems that all networking drivers that do use NAPI
      for their TX completions, should not provide a ndo_poll_controller().
      
      NAPI drivers have netpoll support already handled
      in core networking stack, since netpoll_poll_dev()
      uses poll_napi(dev) to iterate through registered
      NAPI contexts for a device.
      
      This patch allows netpoll_poll_dev() to process NAPI
      contexts even for drivers not providing ndo_poll_controller(),
      allowing for following patches in NAPI drivers.
      
      Also we export netpoll_poll_dev() so that it can be called
      by bonding/team drivers in following patches.
      Reported-by: NSong Liu <songliubraving@fb.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Tested-by: NSong Liu <songliubraving@fb.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ac3d9dd0
  3. 22 9月, 2018 1 次提交
    • O
      block: use nanosecond resolution for iostat · b57e99b4
      Omar Sandoval 提交于
      Klaus Kusche reported that the I/O busy time in /proc/diskstats was not
      updating properly on 4.18. This is because we started using ktime to
      track elapsed time, and we convert nanoseconds to jiffies when we update
      the partition counter. However, this gets rounded down, so any I/Os that
      take less than a jiffy are not accounted for. Previously in this case,
      the value of jiffies would sometimes increment while we were doing I/O,
      so at least some I/Os were accounted for.
      
      Let's convert the stats to use nanoseconds internally. We still report
      milliseconds as before, now more accurately than ever. The value is
      still truncated to 32 bits for backwards compatibility.
      
      Fixes: 522a7775 ("block: consolidate struct request timestamp fields")
      Cc: stable@vger.kernel.org
      Reported-by: NKlaus Kusche <klaus.kusche@computerix.info>
      Signed-off-by: NOmar Sandoval <osandov@fb.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      b57e99b4
  4. 21 9月, 2018 2 次提交
  5. 20 9月, 2018 3 次提交
  6. 19 9月, 2018 1 次提交
    • J
      net: stmmac: Rework coalesce timer and fix multi-queue races · 8fce3331
      Jose Abreu 提交于
      This follows David Miller advice and tries to fix coalesce timer in
      multi-queue scenarios.
      
      We are now using per-queue coalesce values and per-queue TX timer.
      
      Coalesce timer default values was changed to 1ms and the coalesce frames
      to 25.
      
      Tested in B2B setup between XGMAC2 and GMAC5.
      Signed-off-by: NJose Abreu <joabreu@synopsys.com>
      Fixes: 	ce736788 ("net: stmmac: adding multiple buffers for TX")
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Neil Armstrong <narmstrong@baylibre.com>
      Cc: Jerome Brunet <jbrunet@baylibre.com>
      Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Joao Pinto <jpinto@synopsys.com>
      Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
      Cc: Alexandre Torgue <alexandre.torgue@st.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8fce3331
  7. 14 9月, 2018 1 次提交
    • L
      mm: get rid of vmacache_flush_all() entirely · 7a9cdebd
      Linus Torvalds 提交于
      Jann Horn points out that the vmacache_flush_all() function is not only
      potentially expensive, it's buggy too.  It also happens to be entirely
      unnecessary, because the sequence number overflow case can be avoided by
      simply making the sequence number be 64-bit.  That doesn't even grow the
      data structures in question, because the other adjacent fields are
      already 64-bit.
      
      So simplify the whole thing by just making the sequence number overflow
      case go away entirely, which gets rid of all the complications and makes
      the code faster too.  Win-win.
      
      [ Oleg Nesterov points out that the VMACACHE_FULL_FLUSHES statistics
        also just goes away entirely with this ]
      Reported-by: NJann Horn <jannh@google.com>
      Suggested-by: NWill Deacon <will.deacon@arm.com>
      Acked-by: NDavidlohr Bueso <dave@stgolabs.net>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7a9cdebd
  8. 13 9月, 2018 2 次提交
  9. 12 9月, 2018 2 次提交
  10. 10 9月, 2018 1 次提交
    • P
      mfd: da9063: Fix DT probing with constraints · a318c243
      Philipp Zabel 提交于
      Commit 1c892e38 ("regulator: da9063: Handle less LDOs on DA9063L")
      reordered the da9063_regulator_info[] array, but not the DA9063_ID_*
      regulator ids and not the da9063_matches[] array, because ids are used
      as indices in the array initializer. This mismatch between regulator id
      and da9063_regulator_info[] array index causes the driver probe to fail
      because constraints from DT are not applied to the correct regulator:
      
        da9063 0-0058: Device detected (chip-ID: 0x61, var-ID: 0x50)
        DA9063_BMEM: Bringing 900000uV into 3300000-3300000uV
        DA9063_LDO9: Bringing 3300000uV into 2500000-2500000uV
        DA9063_LDO1: Bringing 900000uV into 3300000-3300000uV
        DA9063_LDO1: failed to apply 3300000-3300000uV constraint(-22)
      
      This patch reorders the DA9063_ID_* as apparently intended, and with
      them the entries in the da90630_matches[] array.
      
      Fixes: 1c892e38 ("regulator: da9063: Handle less LDOs on DA9063L")
      Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
      Reviewed-by: NMarek Vasut <marek.vasut@gmail.com>
      Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      a318c243
  11. 06 9月, 2018 3 次提交
  12. 05 9月, 2018 3 次提交
  13. 04 9月, 2018 1 次提交
  14. 03 9月, 2018 1 次提交
    • M
      regulator: Fix 'do-nothing' value for regulators without suspend state · 3edd79cf
      Marek Szyprowski 提交于
      Some regulators don't have all states defined and in such cases regulator
      core should not assume anything. However in current implementation
      of of_get_regulation_constraints() DO_NOTHING_IN_SUSPEND enable value was
      set only for regulators which had suspend node defined, otherwise the
      default 0 value was used, what means DISABLE_IN_SUSPEND. This lead to
      broken system suspend/resume on boards, which had simple regulator
      constraints definition (without suspend state nodes).
      
      To avoid further mismatches between the default and uninitialized values
      of the suspend enabled/disabled states, change the values of the them,
      so default '0' means DO_NOTHING_IN_SUSPEND.
      
      Fixes: 72069f99: regulator: leave one item to record whether regulator is enabled
      Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      3edd79cf