1. 13 Jun, 2022 5 commits
    • Alex Elder's avatar
      net: ipa: determine channel from event · 7dd9558f
      Alex Elder authored
      Each event in an event ring describes the TRE whose completion
      caused the event.  Currently, every event ring is dedicated to a
      single channel, so the channel is easily derived from the event
      ring.
      
      An event ring can actually be shared by more than one channel
      though, and to distinguish events for one channel from another, the
      event structure contains a field indicating which channel the event
      is associated with.
      
      In gsi_event_trans(), use the channel ID in an event to determine
      which channel the event is for.  This makes the channel pointer now
      passed to that function irrelevant; pass the GSI pointer to that
      function instead.
      
      And although it shouldn't happen, warn if an event arrives that
      records a channel ID that's not in use, or if the event does not
      have a transaction associated with it.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7dd9558f
    • Alex Elder's avatar
      net: ipa: simplify endpoint transaction completion · 983a1a30
      Alex Elder authored
      When a GSI transaction completes, ipa_endpoint_trans_complete() is
      eventually called.  That handles TX and RX completions separately,
      but ipa_endpoint_tx_complete() is a no-op.
      
      Instead, have ipa_endpoint_trans_complete() return immediately for a
      TX transaction, and incorporate code from ipa_endpoint_rx_complete()
      to handle RX transactions.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      983a1a30
    • Alex Elder's avatar
      net: ipa: rename endpoint->trans_tre_max · 317595d2
      Alex Elder authored
      The trans_tre_max field of the IPA endpoint structure is only used
      to limit the number of fragments allowed for an SKB being prepared
      for transmission.  Recognizing that, rename the field skb_frag_max,
      and reduce its value by 1.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      317595d2
    • Alex Elder's avatar
      net: ipa: rename channel->tlv_count · 88e03057
      Alex Elder authored
      Each GSI channel has a TLV FIFO of a certain size, specified in the
      configuration data for an AP channel.  That size dictates the
      maximum number of TREs that are allowed in a single transaction.
      
      The only way that value is used after initialization is as a limit
      on the number of TREs in a transaction; calling it "tlv_count"
      isn't helpful, and in fact gsi_channel_trans_tre_max() exists to
      sort of abstract it.
      
      Instead, rename the channel->tlv_count field trans_tre_max, and get
      rid of the helper function.  Update a couple of comments as well.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      88e03057
    • Alex Elder's avatar
      net: ipa: verify command channel TLV count · 92f78f81
      Alex Elder authored
      In commit 8797972a ("net: ipa: remove command info pool"), the
      maximum number of IPA commands that would be sent in a single
      transaction was defined.  That number can't exceed the size of the
      TLV FIFO on the command channel, and we can check that at runtime.
      
      To add this check, pass a new flag to gsi_channel_data_valid() to
      indicate the channel being checked is being used for IPA commands.
      Knowing that we can also verify the channel direction is correct.
      
      Use a new local variable that refers to the command-specific portion
      of the data being checked.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      92f78f81
  2. 11 Jun, 2022 3 commits
  3. 10 Jun, 2022 32 commits