linux-kernel - Re: [PATCH net-next v2 0/6] net: ipa: hardware pipeline cleanup fixes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAF=yD-JRY5P-u2ETN4Dsc4U3jQ3kRAnPt6EDPtZ3MdVcrnyLmQ@mail.gmail.com>
Date:   Wed, 27 Jan 2021 09:39:56 -0500
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Alex Elder <elder@...aro.org>
Cc:     David Miller <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, elder@...nel.org,
        evgreen@...omium.org, bjorn.andersson@...aro.org,
        cpratapa@...eaurora.org,
        Subash Abhinov Kasiviswanathan <subashab@...eaurora.org>,
        Network Development <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next v2 0/6] net: ipa: hardware pipeline cleanup fixes

On Wed, Jan 27, 2021 at 5:04 AM Alex Elder <elder@...aro.org> wrote:
>
> Version 2 of this series fixes a "restricted __le16 degrades to
> integer" warning from sparse in the third patch.  The normal host
> architecture is little-endian, so the problem did not produce
> incorrect behavior, but the code was wrong not to perform the
> endianness conversion.  The updated patch uses le16_get_bits() to
> properly extract the value of the field we're interested in.
>
> Everything else remains the same.  Below is the original description.
>
>                                         -Alex
>
> There is a procedure currently referred to as a "tag process" that
> is performed to clear the IPA hardware pipeline--either at the time
> of a modem crash, or when suspending modem GSI channels.
>
> One thing done in this procedure is issuing a command that sends a
> data packet originating from the AP->command TX endpoint, destined
> for the AP<-LAN RX (default) endpoint.  And although we currently
> wait for the send to complete, we do *not* wait for the packet to be
> received.  But the pipeline can't be assumed clear until we have
> actually received this packet.
>
> This series addresses this by detecting when the pipeline-clearing
> packet has been received, and using a completion to allow a waiter
> to know when that has happened.  This uses the IPA status capability
> (which sends an extra status buffer for certain packets).  It also
> uses the ability to supply a "tag" with a packet, which will be
> delivered with the packet's status buffer.  We tag the data packet
> that's sent to clear the pipeline, and use the receipt of a status
> buffer associated with a tagged packet to determine when that packet
> has arrived.
>
> "Tag status" just desribes one aspect of this procedure, so some
> symbols are renamed to be more like "pipeline clear" so they better
> describe the larger purpose.  Finally, two functions used in this
> code don't use their arguments, so those arguments are removed.
>
>                                         -Alex
>
> Alex Elder (6):
>   net: ipa: rename "tag status" symbols
>   net: ipa: minor update to handling of packet with status
>   net: ipa: drop packet if status has valid tag
>   net: ipa: signal when tag transfer completes
>   net: ipa: don't pass tag value to ipa_cmd_ip_tag_status_add()
>   net: ipa: don't pass size to ipa_cmd_transfer_add()
>
>  drivers/net/ipa/ipa.h          |  2 +
>  drivers/net/ipa/ipa_cmd.c      | 45 +++++++++++++------
>  drivers/net/ipa/ipa_cmd.h      | 24 ++++++-----
>  drivers/net/ipa/ipa_endpoint.c | 79 ++++++++++++++++++++++++++--------
>  drivers/net/ipa/ipa_main.c     |  1 +
>  5 files changed, 109 insertions(+), 42 deletions(-)

For netdrv

Acked-by: Willem de Bruijn <willemb@...gle.com>