[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <000001da6000$527c8650$f77592f0$@samsung.com>
Date: Thu, 15 Feb 2024 20:15:45 +0900
From: 이승희 <sh043.lee@...sung.com>
To: "'Greg KH'" <gregkh@...uxfoundation.org>
Cc: "'Ulf Hansson'" <ulf.hansson@...aro.org>, <linux-mmc@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <avri.altman@....com>,
<grant.jung@...sung.com>, <jt77.jang@...sung.com>,
<dh0421.hwang@...sung.com>, <junwoo80.lee@...sung.com>,
<jangsub.yi@...sung.com>, <cw9316.lee@...sung.com>,
<sh8267.baek@...sung.com>, <wkon.kim@...sung.com>, <sh043.lee@...sung.com>
Subject: RE: [PATCH] mmc: sd: Add a variable to check a faulty device
> -----Original Message-----
> From: Greg KH <gregkh@...uxfoundation.org>
> Sent: Thursday, February 15, 2024 5:07 PM
> To: 이승희 <sh043.lee@...sung.com>
> Cc: 'Ulf Hansson' <ulf.hansson@...aro.org>; linux-mmc@...r.kernel.org;
> linux-kernel@...r.kernel.org; avri.altman@....com; grant.jung@...sung.com;
> jt77.jang@...sung.com; dh0421.hwang@...sung.com; junwoo80.lee@...sung.com;
> jangsub.yi@...sung.com; cw9316.lee@...sung.com; sh8267.baek@...sung.com;
> wkon.kim@...sung.com
> Subject: Re: [PATCH] mmc: sd: Add a variable to check a faulty device
>
> On Thu, Feb 15, 2024 at 10:03:45AM +0900, 이승희 wrote:
> > > -----Original Message-----
> > > From: Ulf Hansson <ulf.hansson@...aro.org>
> > > Sent: Wednesday, February 14, 2024 8:27 PM
> > > To: Seunghui Lee <sh043.lee@...sung.com>
> > > Cc: linux-mmc@...r.kernel.org; linux-kernel@...r.kernel.org;
> > > gregkh@...uxfoundation.org; avri.altman@....com;
> > > grant.jung@...sung.com; jt77.jang@...sung.com;
> > > dh0421.hwang@...sung.com; junwoo80.lee@...sung.com;
> > > jangsub.yi@...sung.com; cw9316.lee@...sung.com;
> > > sh8267.baek@...sung.com; wkon.kim@...sung.com
> > > Subject: Re: [PATCH] mmc: sd: Add a variable to check a faulty
> > > device
> > >
> > > On Tue, 13 Feb 2024 at 06:13, Seunghui Lee <sh043.lee@...sung.com>
> wrote:
> > > >
> > > > In mobile devices, suspend/resume situations are frequent.
> > > > In the case of a defective SD card in which initialization fails,
> > > > unnecessary initialization time is consumed for each resume.
> > > > A field is needed to check that SD card initialization has failed
> > > > on the host. It could be used to remove unnecessary initialization.
> > >
> > > It's not clear to me, under what circumstance you want to optimize for.
> > >
> > > Is the SD card ever getting properly initialized during boot?
> > >
> > > Kind regards
> > > Uffe
> > >
> > We receive a lot of reports about SD card issues in the market.
> > There was no problem with the first time at the time of use, and there
> are many cases where people recognize that it is not recognized later on.
> In most cases, this is a problem with the SD card itself.
> >
> > SD card users cannot determine whether or not an SD card is a problem,
> so they should be guided in this regard.
> > It is necessary to distinguish whether the SD card is inserted but
> unrecognized or the SD card itself is not inserted, and if there is a
> field that can check for initialization failure, it will facilitate
> guidance, so we considered the patch.
> >
> > The variable's usage is expected to be used through the sysfs node in
> the vendor module.
>
> What "vendor module"? You need to include all of the needed code here
> please.
>
> thanks,
>
> greg k-h
This only purpose of this variable is to identify a faulty card on host side.
In the past, we can identify that the card is inserted or not with reading get_cd() function.
But now, most mobile devices use hybrid type of SD card tray.
If the tray is inserted, the return value of get_cd is the same whatever the SD card is inserted or not.
It can help us diagonose the status of a SD card as well.
Here is the example of usage.
static ssize_t status_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct mmc_host *host = dev_get_drvdata(dev);
struct mmc_card *card = host->card;
char *status = NULL;
if (card)
status = mmc_card_readonly(card) ? "PERMWP" : "NORMAL";
else
status = host->init_failed ? "INITFAIL" : "NOCARD";
return sysfs_emit(buf, "%s\n", status);
}
As for the sysfs node, it should keep the path of node with or without the SD card.
That's why I mention the vendor module.
If I need to update the commit's comment, I'll fix it.
If someone has the better idea(e.g. code, comment), please suggest it.
Thank you for reviewing this.
Seunghui Lee.
Powered by blists - more mailing lists