1. 07 May, 2020 21 commits
    • David S. Miller's avatar
      Merge branch 'net-ipa-kill-endpoint-stop-workaround' · 33395f4a
      David S. Miller authored
      Alex Elder says:
      
      ====================
      net: ipa: kill endpoint stop workaround
      
      It turns out that a workaround that performs a small DMA operation
      between retried attempts to stop a GSI channel is not needed for any
      supported hardware.  The hardware quirk that required the extra DMA
      operation was fixed after IPA v3.1.  So this series gets rid of that
      workaround code, along with some other code that was only present to
      support it.
      
      NOTE:  This series depends on (and includes/duplicates) another patch
             that has already been committed in the net tree:
               713b6ebb net: ipa: fix a bug in ipa_endpoint_stop()
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      33395f4a
    • Alex Elder's avatar
      net: ipa: kill ipa_cmd_dma_task_32b_addr_add() · da1a782a
      Alex Elder authored
      A recent commit removed the only use of ipa_cmd_dma_task_32b_addr_add().
      This function (and the IPA immediate command it implements) is no
      longer needed, so get rid of it, along with all of the definitions
      associated with it.  Isolate its removal in a commit so it can be
      easily added back again if needed.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      da1a782a
    • Alex Elder's avatar
      net: ipa: kill ipa_endpoint_stop() · f30dcb7d
      Alex Elder authored
      The previous commit made ipa_endpoint_stop() be a trivial wrapper
      around gsi_channel_stop().  Since it no longer does anything
      special, just open-code it in the three places it's used.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f30dcb7d
    • Alex Elder's avatar
      net: ipa: don't retry in ipa_endpoint_stop() · 9928fcc7
      Alex Elder authored
      The only reason ipa_endpoint_stop() had a retry loop was that the
      just-removed workaround required an IPA DMA command to occur between
      attempts.  The gsi_channel_stop() call that implements the stop does
      its own retry loop, to cover a channel's transition from started to
      stop-in-progress to stopped state.
      
      Get rid of the unnecessary retry loop in ipa_endpoint_stop().
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9928fcc7
    • Alex Elder's avatar
      net: ipa: get rid of workaround in ipa_endpoint_stop() · c72ddf0d
      Alex Elder authored
      In ipa_endpoint_stop(), a workaround is used for IPA version 3.5.1
      where a 1-byte DMA request is issued between GSI channel stop
      retries.
      
      It turns out that this workaround is only required for IPA versions
      3.1 and 3.2, and we don't support those.  So remove the call to
      ipa_endpoint_stop_rx_dma() in that function.  That leaves that
      function unused, so get rid of it.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c72ddf0d
    • Alex Elder's avatar
      net: ipa: fix a bug in ipa_endpoint_stop() · 97e4692d
      Alex Elder authored
      In ipa_endpoint_stop(), for TX endpoints we set the number of retries
      to 0.  When we break out of the loop, retries being 0 means we return
      EIO rather than the value of ret (which should be 0).
      
      Fix this by using a non-zero retry count for both RX and TX
      channels, and just break out of the loop after calling
      gsi_channel_stop() for TX channels.  This way only RX channels
      will retry, and the retry count will be non-zero at the end
      for TX channels (so the proper value gets returned).
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      (cherry picked from commit 713b6ebb)
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      97e4692d
    • David S. Miller's avatar
      Merge branch 'net-ipa-kill-endpoint-delay-mode-workaround' · 6a5dc76a
      David S. Miller authored
      Alex Elder says:
      
      ====================
      net: ipa: kill endpoint delay mode workaround
      
      A "delay mode" feature was put in place to work around a problem
      where packets could passed to the modem before it was ready to
      handle them.  That problem no longer exists, and we don't need the
      workaround any more so get rid of it.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6a5dc76a
    • Alex Elder's avatar
      net: ipa: remove endpoint delay mode feature · a4dcad34
      Alex Elder authored
      A "delay mode" feature was put in place to work around a problem
      that was observed during development of the upstream IPA driver.  It
      used TX endpoint "delay mode" in order to prevent transmitting
      packets toward the modem before it was ready.
      
      A race condition that would explain the problem has long since been
      fixed, and we have concluded that the "delay mode" feature is no
      longer required.  So get rid of it.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a4dcad34
    • Alex Elder's avatar
      net: ipa: introduce ipa_endpoint_program_suspend() · 4fa95248
      Alex Elder authored
      Create a new helper function that encapsulates enabling or disabling
      suspend on an RX endpoint.  It returns the previous state of the
      endpoint (true means suspend mode was enabled).
      
      Create another function that handles enabling or disabling delay mode
      on a TX endpoint.  Delay mode does not work correctly on IPA version
      4.2, so we don't currently use it (and shouldn't).
      
      We only set delay mode in one case, and although we don't expect an
      endpoint to already be in delay mode, it doesn't really matter if it
      was.  So the delay function doesn't return a value.
      
      Stop issuing warnings if the previous suspend or delay mode state
      differs from what is expected.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4fa95248
    • Alex Elder's avatar
      net: ipa: have ipa_endpoint_init_ctrl() return previous state · 4900bf34
      Alex Elder authored
      Change ipa_endpoint_init_ctrl() so it returns the previous state
      (whether suspend or delay mode was enabled) rather than indicating
      whether the request caused a change in state.  This makes it easier
      to understand what's happening where called.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4900bf34
    • David S. Miller's avatar
      Merge branch 'net-ipa-limit-special-reset-handling' · 9c729e74
      David S. Miller authored
      Alex Elder says:
      
      ====================
      net: ipa: limit special reset handling
      
      Some special handling done during channel reset should only be done
      for IPA hardare version 3.5.1.  This series generalizes the meaning
      of a flag passed to indicate special behavior, then has the special
      handling be used only when appropriate.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9c729e74
    • Alex Elder's avatar
      net: ipa: only reset channel twice for IPA v3.5.1 · a3f2405b
      Alex Elder authored
      In gsi_channel_reset(), RX channels are subjected to two consecutive
      CHANNEL_RESET commands.  This workaround should only be used for IPA
      version 3.5.1, and for newer hardware "can lead to unwanted behavior."
      
      Only issue the second CHANNEL_RESET command for legacy hardware.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a3f2405b
    • Alex Elder's avatar
      net: ipa: rename db_enable flag · f86a1909
      Alex Elder authored
      In several places, a Boolean flag is used in the GSI code to
      indicate whether the "doorbell engine" should be enabled or not
      when a channel is configured.  This is basically done to abstract
      this property from the IPA version; the GSI code doesn't otherwise
      "know" what the IPA hardware version is.  The doorbell engine is
      enabled only for IPA v3.5.1, not for IPA v4.0 and later.
      
      The next patch makes another change that affects behavior during
      channel reset (which also involves programming the channel).  It
      also distinguishes IPA v3.5.1 hardware from newer hardware.
      
      Rather than creating another flag whose value matches the "db_enable"
      value, just rename "db_enable" to be "legacy" so it can be used to
      signal more than just the special doorbell handling.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f86a1909
    • David S. Miller's avatar
      Merge branch 'tcp-minor-adjustments-for-low-pacing-rates' · ee733cd8
      David S. Miller authored
      Eric Dumazet says:
      
      ====================
      tcp: minor adjustments for low pacing rates
      
      After pacing horizon addition, we have to adjust how we arm rto
      timer, otherwise we might freeze very low pacing rate flows.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ee733cd8
    • Eric Dumazet's avatar
      tcp: defer xmit timer reset in tcp_xmit_retransmit_queue() · 916e6d1a
      Eric Dumazet authored
      As hinted in prior change ("tcp: refine tcp_pacing_delay()
      for very low pacing rates"), it is probably best arming
      the xmit timer only when all the packets have been scheduled,
      rather than when the head of rtx queue has been re-sent.
      
      This does matter for flows having extremely low pacing rates,
      since their tp->tcp_wstamp_ns could be far in the future.
      
      Note that the regular xmit path has a stronger limit
      in tcp_small_queue_check(), meaning it is less likely to
      go beyond the pacing horizon.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      916e6d1a
    • Eric Dumazet's avatar
      tcp: refine tcp_pacing_delay() for very low pacing rates · 8dc242ad
      Eric Dumazet authored
      With the addition of horizon feature to sch_fq, we noticed some
      suboptimal behavior of extremely low pacing rate TCP flows, especially
      when TCP is not aware of a drop happening in lower stacks.
      
      Back in commit 3f80e08f ("tcp: add tcp_reset_xmit_timer() helper"),
      tcp_pacing_delay() was added to estimate an extra delay to add to standard
      rto timers.
      
      This patch removes the skb argument from this helper and
      tcp_reset_xmit_timer() because it makes more sense to simply
      consider the time at which next packet is allowed to be sent,
      instead of the time of whatever packet has been sent.
      
      This avoids arming RTO timer too soon and removes
      spurious horizon drops.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8dc242ad
    • Alex Elder's avatar
      arm64: dts: sdm845: add IPA iommus property · b94c280d
      Alex Elder authored
      Add an "iommus" property to the IPA node in "sdm845.dtsi".  It is
      required because there are two regions of memory the IPA accesses
      through an SMMU.  The next few patches define and map those regions.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b94c280d
    • David S. Miller's avatar
      Merge branch 'timer-add-fsleep-for-flexible-sleeping' · a88845d8
      David S. Miller authored
      Heiner Kallweit says:
      
      ====================
      timer: add fsleep for flexible sleeping
      
      Sleeping for a certain amount of time requires use of different
      functions, depending on the time period.
      Documentation/timers/timers-howto.rst explains when to use which
      function, and also checkpatch checks for some potentially
      problematic cases.
      
      So let's create a helper that automatically chooses the appropriate
      sleep function -> fsleep(), for flexible sleeping
      Not sure why such a helper doesn't exist yet, or where the pitfall is,
      because it's a quite obvious idea.
      
      If the delay is a constant, then the compiler should be able to ensure
      that the new helper doesn't create overhead. If the delay is not
      constant, then the new helper can save some code.
      
      First user is the r8169 network driver. If nothing speaks against it,
      then this series could go through the netdev tree.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a88845d8
    • Heiner Kallweit's avatar
      r8169: use fsleep in polling functions · d6836ef0
      Heiner Kallweit authored
      Use new flexible sleep function fsleep() to merge the udelay and msleep
      polling functions. We can safely do this because no polling function
      is used in atomic context in this driver.
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d6836ef0
    • Heiner Kallweit's avatar
      timer: add fsleep for flexible sleeping · c6af13d3
      Heiner Kallweit authored
      Sleeping for a certain amount of time requires use of different
      functions, depending on the time period.
      Documentation/timers/timers-howto.rst explains when to use which
      function, and also checkpatch checks for some potentially
      problematic cases.
      
      So let's create a helper that automatically chooses the appropriate
      sleep function -> fsleep(), for flexible sleeping
      
      If the delay is a constant, then the compiler should be able to ensure
      that the new helper doesn't create overhead. If the delay is not
      constant, then the new helper can save some code.
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c6af13d3
    • Fernando Gont's avatar
      ipv6: Implement draft-ietf-6man-rfc4941bis · 969c5464
      Fernando Gont authored
      Implement the upcoming rev of RFC4941 (IPv6 temporary addresses):
      https://tools.ietf.org/html/draft-ietf-6man-rfc4941bis-09
      
      * Reduces the default Valid Lifetime to 2 days
        The number of extra addresses employed when Valid Lifetime was
        7 days exacerbated the stress caused on network
        elements/devices. Additionally, the motivation for temporary
        addresses is indeed privacy and reduced exposure. With a
        default Valid Lifetime of 7 days, an address that becomes
        revealed by active communication is reachable and exposed for
        one whole week. The only use case for a Valid Lifetime of 7
        days could be some application that is expecting to have long
        lived connections. But if you want to have a long lived
        connections, you shouldn't be using a temporary address in the
        first place. Additionally, in the era of mobile devices, general
        applications should nevertheless be prepared and robust to
        address changes (e.g. nodes swap wifi <-> 4G, etc.)
      
      * Employs different IIDs for different prefixes
        To avoid network activity correlation among addresses configured
        for different prefixes
      
      * Uses a simpler algorithm for IID generation
        No need to store "history" anywhere
      Signed-off-by: default avatarFernando Gont <fgont@si6networks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      969c5464
  2. 06 May, 2020 19 commits