linux-kernel - RE: [PATCH] mmc: core: Apply trim broken quirk to R1J57L

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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <VI1PR04MB52946B4A7CCB0651230633AB90BD0@VI1PR04MB5294.eurprd04.prod.outlook.com>
Date:   Mon, 25 Jan 2021 11:34:45 +0000
From:   Bough Chen <haibo.chen@....com>
To:     Fabio Estevam <festevam@...il.com>,
        Ulf Hansson <ulf.hansson@...aro.org>
CC:     "Wang, Xiaolei" <Xiaolei.Wang@...driver.com>,
        Pali Rohár <pali@...nel.org>,
        Lee Jones <lee.jones@...aro.org>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] mmc: core: Apply trim broken quirk to R1J57L

> -----Original Message-----
> From: Fabio Estevam [mailto:festevam@...il.com]
> Sent: 2021年1月25日 18:47
> To: Ulf Hansson <ulf.hansson@...aro.org>
> Cc: Wang, Xiaolei <Xiaolei.Wang@...driver.com>; Bough Chen
> <haibo.chen@....com>; Pali Rohár <pali@...nel.org>; Lee Jones
> <lee.jones@...aro.org>; linux-mmc@...r.kernel.org; Linux Kernel Mailing List
> <linux-kernel@...r.kernel.org>
> Subject: Re: [PATCH] mmc: core: Apply trim broken quirk to R1J57L
> 
> Hi Haibo,
> 
> Could you please take a look?

I will look into this issue this week.

Haibo Chen
> 
> Thanks
> 
> On Thu, Jan 21, 2021 at 10:26 AM Ulf Hansson <ulf.hansson@...aro.org>
> wrote:
> >
> > + Fabio, Haibo
> >
> > On Thu, 21 Jan 2021 at 10:54, Wang, Xiaolei <Xiaolei.Wang@...driver.com>
> wrote:
> > >
> > > Hi
> > >
> > > >Are you sure this is an eMMC problem and not a mmc host driver issue?
> > >
> > > >Can you elaborate more what happens?
> > >
> > > When I use the mkfs.f2fs tool to format the eMMC file system on the
> > > imx8qxp board, because mkfs.f2fs will use secdiscard first, when
> > > entering mmc_blk_issue_secdiscard_rq erase, once the parameters are
> passed into MMC_SECURE_TRIM1_ARG, this function will take a long time to
> return .
> > > The program has not ended, has been in TASK_UNINTERRUPTIBLE state.
> > >
> > > I compared the mkfs.ext4 tool to format the file system. Because it
> > > directly uses mmc_blk_issue_discard_rq, this is a normal formatting
> phenomenon.
> > >
> > > mmc_blk_issue_secdiscard_rq and mmc_blk_issue_discard_rq are just
> different commands and parameters sent by the host as a bus.
> > >  I did not see the description of trim in the data sheet. Could the host
> driver cause this problem?
> >
> > Yes, it can - and we have had issues like these before. So before
> > adding a card quirk, I think we need to make sure this isn't the case.
> >
> > When using MMC_SECURE_TRIM1_ARG, it's very likely that the request
> > takes longer to complete.
> >
> > The mmc host is responsible for either dealing with busy detection
> > with the help of its HW/controller - or if that can't be supported,
> > the mmc core falls back to polling the card for busy with a CMD13.
> >
> > See mmc_do_erase() in /drivers/mmc/core/core.c
> >
> > >
> > > Note:
> > > The host driver I use is sdhci-esdhc-imx.c
> >
> > Alright, I have looped in Fabio and Haibo that knows this driver,
> > let's see if they can help.
> >
> > >
> > > Thanks
> > > Xiaolei
> >
> > Kind regards
> > Uffe
> >
> > >
> > > -----Original Message-----
> > > From: Ulf Hansson <ulf.hansson@...aro.org>
> > > Sent: Wednesday, January 20, 2021 9:41 PM
> > > To: Wang, Xiaolei <Xiaolei.Wang@...driver.com>
> > > Cc: Pali Rohár <pali@...nel.org>; Lee Jones <lee.jones@...aro.org>;
> > > linux-mmc@...r.kernel.org; Linux Kernel Mailing List
> > > <linux-kernel@...r.kernel.org>
> > > Subject: Re: [PATCH] mmc: core: Apply trim broken quirk to R1J57L
> > >
> > > [Please note this e-mail is from an EXTERNAL e-mail address]
> > >
> > > On Mon, 18 Jan 2021 at 05:27, Xiaolei Wang <xiaolei.wang@...driver.com>
> wrote:
> > > >
> > > > R1J57L mmc chip hw capibility indicates that it supports trim
> > > > function, but this function does not work properly, the SDIO bus
> > > > does not respond, and the IO has been waiting so set quirks to
> > > > skip trim
> > >
> > > Are you sure this is an eMMC problem and not a mmc host driver issue?
> > >
> > > Can you elaborate more what happens?
> > >
> > > Kind regards
> > > Uffe
> > >
> > > >
> > > > Signed-off-by: Xiaolei Wang <xiaolei.wang@...driver.com>
> > > > ---
> > > >  drivers/mmc/core/quirks.h | 4 ++++
> > > >  1 file changed, 4 insertions(+)
> > > >
> > > > diff --git a/drivers/mmc/core/quirks.h b/drivers/mmc/core/quirks.h
> > > > index d68e6e513a4f..63e02391c133 100644
> > > > --- a/drivers/mmc/core/quirks.h
> > > > +++ b/drivers/mmc/core/quirks.h
> > > > @@ -89,6 +89,8 @@ static const struct mmc_fixup __maybe_unused
> mmc_blk_fixups[] = {
> > > >                   MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
> > > >         MMC_FIXUP("VZL00M", CID_MANFID_SAMSUNG,
> CID_OEMID_ANY, add_quirk_mmc,
> > > >                   MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
> > > > +       MMC_FIXUP("R1J57L", CID_MANFID_MICRON,
> CID_OEMID_ANY, add_quirk_mmc,
> > > > +                 MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
> > > >
> > > >         /*
> > > >          *  On Some Kingston eMMCs, performing trim can result in
> > > > @@
> > > > -98,6 +100,8 @@ static const struct mmc_fixup __maybe_unused
> mmc_blk_fixups[] = {
> > > >                   MMC_QUIRK_TRIM_BROKEN),
> > > >         MMC_FIXUP("V10016", CID_MANFID_KINGSTON,
> CID_OEMID_ANY, add_quirk_mmc,
> > > >                   MMC_QUIRK_TRIM_BROKEN),
> > > > +       MMC_FIXUP("R1J57L", CID_MANFID_MICRON,
> CID_OEMID_ANY, add_quirk_mmc,
> > > > +                 MMC_QUIRK_TRIM_BROKEN),
> > > >
> > > >         END_FIXUP
> > > >  };
> > > > --
> > > > 2.25.1
> > > >