Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 28 Jul 2021 12:39:57 +0530
From:   Vinod Koul <vkoul@kernel.org>
To:     Amelie Delaunay <amelie.delaunay@foss.st.com>
Cc:     Rob Herring <robh+dt@kernel.org>,
        Dan Williams <dan.j.williams@intel.com>,
        Maxime Coquelin <mcoquelin.stm32@gmail.com>,
        Alexandre Torgue <alexandre.torgue@foss.st.com>,
        dmaengine@vger.kernel.org, devicetree@vger.kernel.org,
        linux-stm32@st-md-mailman.stormreply.com,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        Pierre-Yves Mordret <pierre-yves.mordret@foss.st.com>
Subject: Re: [PATCH 0/2] STM32 DMA alternative REQ/ACK protocol support
Message-ID: <YQECxSZqa9aHw6CB@matsya>
References: <20210624093959.142265-1-amelie.delaunay@foss.st.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210624093959.142265-1-amelie.delaunay@foss.st.com>
Precedence: bulk

On 24-06-21, 11:39, Amelie Delaunay wrote:
> Default REQ/ACK protocol consists in maintaining ACK signal up to the
> removal of REQuest and the transfer completion.
> In case of alternative REQ/ACK protocol, ACK de-assertion does not wait the
> removal of the REQuest, but only the transfer completion.
> Due to a possible DMA stream lock when transferring data to/from STM32
> USART/UART, add support to select alternative REQ/ACK protocol.

Applied, thanks

-- 
~Vinod