linux-kernel - Re: [PATCH] mmc: sd: Add a variable to check a faulty device

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPDyKFpOLU3nsQuXLRdK2KAaQqX=Vwe0+A3jZc7pP4XaMG7Wug@mail.gmail.com>
Date: Thu, 15 Feb 2024 12:00:44 +0100
From: Ulf Hansson <ulf.hansson@...aro.org>
To: 이승희 <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 Thu, 15 Feb 2024 at 02:03, 이승희 <sh043.lee@...sung.com> 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.

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 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.

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