1. 07 May, 2020 13 commits
    • 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 27 commits