[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9fbd2fca-e4f5-d28f-74de-d9906cc232bf@foss.st.com>
Date: Thu, 4 Feb 2021 13:54:57 +0100
From: Yann GAUTIER <yann.gautier@...s.st.com>
To: Marek Vasut <marex@...x.de>, <ulf.hansson@...aro.org>
CC: <linux@...linux.org.uk>, <linus.walleij@...aro.org>,
<ludovic.barre@...s.st.com>, <per.forlin@...aro.org>,
<huyue2@...ong.com>, <wsa+renesas@...g-engineering.com>,
<vbadigan@...eaurora.org>, <adrian.hunter@...el.com>,
<p.zabel@...gutronix.de>, <swboyd@...omium.org>,
<linux-mmc@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] mmc: mmci: enable MMC_CAP_NEED_RSP_BUSY
On 2/4/21 1:26 PM, Marek Vasut wrote:
> On 2/4/21 1:05 PM, yann.gautier@...s.st.com wrote:
>> From: Yann Gautier <yann.gautier@...s.st.com>
>>
>> To properly manage commands awaiting R1B responses, the capability
>> MMC_CAP_NEED_RSP_BUSY is enabled in mmci driver, for variants that
>> manage busy detection.
>> This R1B management needs both the flags MMC_CAP_NEED_RSP_BUSY and
>> MMC_CAP_WAIT_WHILE_BUSY to be enabled together.
>>
> Shouldn't this have Fixes: tag ?
Hi Marek,
There is no unique patch that brought the issue, but a combination of
several things:
- The series that brought the MMC_CAP_NEED_RSP_BUSY flag [1]
- The series that enabled MMC_ERASE for all hosts [2] (removal of
MMC_CAP_ERASE)
But you're right, this patch may go on v5.8.x kernel and newer versions.
Regards,
Yann
[1]
https://patchwork.kernel.org/project/linux-mmc/cover/20200310153340.5593-1-ulf.hansson@linaro.org/
[2]
https://patchwork.kernel.org/project/linux-mmc/patch/20200508112853.23525-1-ulf.hansson@linaro.org/
Powered by blists - more mailing lists