Received-SPF: pass (google.com: domain of linux-kernel+bounces-66819-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Thu, 15 Feb 2024 12:38:12 +0100
From: 'Greg KH' <gregkh@linuxfoundation.org>
To: =?utf-8?B?7J207Iq57Z2s?= <sh043.lee@samsung.com>
Cc: 'Ulf Hansson' <ulf.hansson@linaro.org>, linux-mmc@vger.kernel.org,
	linux-kernel@vger.kernel.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
Subject: Re: [PATCH] mmc: sd: Add a variable to check a faulty device
Message-ID: <2024021531-speech-lifting-89f6@gregkh>
References: <CGME20240213051332epcas1p1f45d02dc34d1b95ea5608ab779d6b6cc@epcas1p1.samsung.com>
 <20240213051716.6596-1-sh043.lee@samsung.com>
 <CAPDyKFrjZ4jRHAfXsvrEvezuHTxbA3SAniF8CuObyLuW=AUoeA@mail.gmail.com>
 <000001da5faa$d34e1600$79ea4200$@samsung.com>
 <2024021528-fretted-sustainer-2ebc@gregkh>
 <000001da6000$527c8650$f77592f0$@samsung.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <000001da6000$527c8650$f77592f0$@samsung.com>

On Thu, Feb 15, 2024 at 08:15:45PM +0900, 이승희 wrote:
> > -----Original Message-----
> > From: Greg KH <gregkh@linuxfoundation.org>
> > Sent: Thursday, February 15, 2024 5:07 PM
> > To: 이승희 <sh043.lee@samsung.com>
> > Cc: 'Ulf Hansson' <ulf.hansson@linaro.org>; linux-mmc@vger.kernel.org;
> > linux-kernel@vger.kernel.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
> > Subject: Re: [PATCH] mmc: sd: Add a variable to check a faulty device

Does this really belong in the body of the email?  You might want a
nicer email client :)

> > > 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);
> }

What will userspace do with this information?

And why isn't this part of the patch you submitted?

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

What vendor module?  What do you mean by vendor module?  You know we
can't add code to the kernel that is only used by code that is NOT in
our kernel tree.  You don't want us to take stuff like that, so why is
it being proposed here?

confused,

greg k-h