Received-SPF: pass (google.com: domain of linux-kernel+bounces-66727-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Precedence: bulk
MIME-Version: 1.0
References: <CGME20240213051332epcas1p1f45d02dc34d1b95ea5608ab779d6b6cc@epcas1p1.samsung.com>
 <20240213051716.6596-1-sh043.lee@samsung.com> <CAPDyKFrjZ4jRHAfXsvrEvezuHTxbA3SAniF8CuObyLuW=AUoeA@mail.gmail.com>
 <000001da5faa$d34e1600$79ea4200$@samsung.com>
In-Reply-To: <000001da5faa$d34e1600$79ea4200$@samsung.com>
From: Ulf Hansson <ulf.hansson@linaro.org>
Date: Thu, 15 Feb 2024 12:00:44 +0100
Message-ID: <CAPDyKFpOLU3nsQuXLRdK2KAaQqX=Vwe0+A3jZc7pP4XaMG7Wug@mail.gmail.com>
Subject: Re: [PATCH] mmc: sd: Add a variable to check a faulty device
To: =?UTF-8?B?7J207Iq57Z2s?= <sh043.lee@samsung.com>
Cc: linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org, 
	gregkh@linuxfoundation.org, avri.altman@wdc.com, grant.jung@samsung.com, 
	jt77.jang@samsung.com, dh0421.hwang@samsung.com, junwoo80.lee@samsung.com, 
	jangsub.yi@samsung.com, cw9316.lee@samsung.com, sh8267.baek@samsung.com, 
	wkon.kim@samsung.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 15 Feb 2024 at 02:03, =EC=9D=B4=EC=8A=B9=ED=9D=AC <sh043.lee@samsun=
g.com> wrote:
>
> > -----Original Message-----
> > From: Ulf Hansson <ulf.hansson@linaro.org>
> > Sent: Wednesday, February 14, 2024 8:27 PM
> > To: Seunghui Lee <sh043.lee@samsung.com>
> > Cc: linux-mmc@vger.kernel.org; linux-kernel@vger.kernel.org;
> > gregkh@linuxfoundation.org; avri.altman@wdc.com; grant.jung@samsung.com=
;
> > jt77.jang@samsung.com; dh0421.hwang@samsung.com; junwoo80.lee@samsung.c=
om;
> > jangsub.yi@samsung.com; cw9316.lee@samsung.com; sh8267.baek@samsung.com=
;
> > wkon.kim@samsung.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@samsung.com> wrot=
e:
> > >
> > > 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 ar=
e many cases where people recognize that it is not recognized later on. In =
most cases, this is a problem with the SD card itself.

Right. Thanks for clarifying.

A follow up question from me is then, do you know more exactly *why*
the SD cards encounter problems?

In the past people have told me that powering on/off an SD card during
system suspend/resume, too frequently, could damage the card. For
non-removable cards, the card stays powered-off even after a system
resume, but instead gets powered-on (and re-initialized) when there is
a new request for it.

In other words, if the problem is related to too frequent powering
on/off the card, my advice would be to test with having the card set
non-removable (the DT property for this is "non-removable"), to see if
that can help. If that solves the problem, we can work towards another
common solution instead.

>
> 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 unreco=
gnized 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 co=
nsidered the patch.
>
> The variable's usage is expected to be used through the sysfs node in the=
 vendor module.

As Greg said, please provide the complete code.

Although, I want to stress already at this point, I don't see a
solution with sysfs being the correct thing to do here. The kernel
should be able to manage this problem itself.

[...]

Kind regards
Uffe