> On Fri, 3 Mar 2023 at 10:39, Avri Altman <Avri.Altman@xxxxxxx> wrote: > > > > > On 02.03.23 3:43 PM, Ulf Hansson wrote: > > > > REQ_FUA is in general supported for eMMC cards, which translates > > > > into so called "reliable writes". To support these write > > > > operations, the > > > > CMD23 (MMC_CAP_CMD23), needs to be supported by the mmc host > too, > > > > which is common but not always the case. > > > > > > > > For some eMMC devices, it has been reported that reliable writes > > > > are quite costly, leading to performance degradations. > > > > > > > > In a way to improve the situation, let's avoid announcing REQ_FUA > > > > support if the eMMC supports an internal cache, as that allows us > > > > to rely solely on flush-requests (REQ_OP_FLUSH) instead, which > > > > seems to be a > > > lot cheaper. > > > > Note that, those mmc hosts that lacks CMD23 support are already > > > > using this type of configuration, whatever that could mean. > > > > > > > > Reported-by: Wenchao Chen<wenchao.chen666@xxxxxxxxx> > > > > Signed-off-by: Ulf Hansson<ulf.hansson@xxxxxxxxxx> > > > Acked-by: Bean Huo <beanhuo@xxxxxxxxxx> > > Acked-by: Avri Altman <avri.altman@xxxxxxx> > > Thanks! > > > > > Another option might be, allowing to report "broken_fua", should the > > platform owner chooses to, much like scsi does per sdev. > > Are you suggesting a static or dynamic configuration option? Static > > For mmc, we also have the card quirks that may be used to configure the > support for FUA, based upon what would work best for the card. Is that > what you were thinking of? I was thinking to allow the platform owner the flexibility to decide if to use it or not, More like SDHCI_QUIRK_xxx But I am totally fine with your current suggestions. Thanks, Avri > > > > > Thanks, > > Avri > > Kind regards > Uffe
