> -----Original Message----- > > > On Tue, 13 Feb 2024 at 06:13, Seunghui Lee <sh043.lee@xxxxxxxxxxx> > 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. > I understand your focus on finding the root cause of the problem. However, unlike internal storage, there is a limit to analyzing cards that have problems in the market. This is because there are many different SD card manufacturers and many manufacturers leave it to OEMs. For deferred resume, a responsiveness problem occurs on the user side on mobile devices. The response time of the initializing SD card initialization in the application seems to be slow. Currently, it seems to be a good structure for the first initialization at runtime resume. Regarding non-removable, We will test if we are given an opportunity to further analyze the cards occurring in the market. However, SD card detection is also used as a wakeup source and must be inserted/removed so I'll consider it for testing purposes. Thank you for the good suggestions though. > > > > 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 I understand it and reconsider this commit. Thank you for reviewing this. Seunghui Lee.
