On Thu, 20 Jun 2024 at 20:15, Daniel Kucera <linux-mmc@xxxxxxxxx> wrote: > > On 2024-06-20 16:32, Ulf Hansson wrote: > > On Thu, 20 Jun 2024 at 14:59, Daniel Kucera <linux-mmc@xxxxxxxxx> > > wrote: > >> > >> On 2024-06-20 14:38, Ulf Hansson wrote: > >> > On Thu, 6 Jun 2024 at 15:12, <linux-mmc@xxxxxxxxx> wrote: > >> >> > >> >> From: Daniel Kucera <linux-mmc@xxxxxxxxx> > >> >> > >> >> Locked SD card will not reply to SEND_SCR or SD_STATUS commands > >> >> so it was failing to initialize previously. When skipped, > >> >> the card will get initialized and CMD42 can be sent using > >> >> ioctl to unlock the card or remove password protection. > >> >> For eMMC, this is not necessary because all initialization > >> >> commands are allowed in locked state. > >> >> Until unlocked, all read/write calls will timeout. > >> > > >> > Skipping the commands above, only means the card gets partially > >> > initialized. > >> > >> Correct, but it's an improvement in comparison to current state. > > > > Not sure I agree with that, sorry. > > Are you saying that that being able to work with locked card is not an > improvement in comparison to not being able to? Or did I misunderstand > that? > > > > >> > >> > Leaving a card in that state seems fragile. > >> > >> Fragile in what sense? Nothing can happen to the card as it is locked. > > > > We may end up having a card half-way initialized that we can't really > > communicate with in a stable manner. From a system point of view, I > > would be worried. > > It's not half-way initialized, it's initialized correctly, it's just not > using the full potential of the card (higher speeds, etc.). > > The situation would be the same as it is currently with emmc. Locked > emmc gets initialized correctly but reads/writes time-out. What is wrong > in having the same result for both sd and emmc? Very good point! > > > > > I would rather just power off the card if initialization fails and > > remove its corresponding device from the system. > > > >> > >> > What will > >> > happen to upper block layers and filesystems when trying to access it? > >> > >> Everything will simply time-out. > > > > Yes, but it's uncertain what that could lead to? > > > > What will happen with power consumption and power management support, > > for example. > > Okay, this is a valid concern. Would it be acceptable if we just enabled > this "feature" with a module parameter, something like > "sd_initialize_locked=1" with default 0? That would be an option, but I don't quite like that either. I guess using locked cards isn't that terribly common. So, perhaps we should simply leave this to be managed entirely by userspace, for now. As pointed out by Avri too. We should still be able to power on/off the card during suspend/resume, which I think is the most important part here. [...] Let me get back to reviewing the actual code for $subject patch, to see how we can move this forward then. Kind regards Uffe
