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. > > > 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. 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. > > > > > Several years ago Al Cooper made an attempt [1] to manage the > > unlocking of the card during initialization, by finding the password > > through the "keys" subsystem. The series didn't really make it to the > > upstream kernel, but overall the approach seemed to make sense to me. > > It should allow us to complete the initialization of the card inside > > the kernel and prevent unnecessary complexity for userspace to manage. > > Yes, he did a great work but obviously no-one got too excited to > review/merge > his work. His solution was complex. It's quite some amount of code. On the other hand, it seemed quite straight forward, not that complex to me. > > Mine targets the smallest change possible to make it work at least. > I wanted to avoid a solution that would be hard to test, review and > maintain. > Especially when there is only a small interest in the feature. > > > Perhaps you can have a closer look at that series and see if it's > > possible to update it? > > I don't think I have the skills to revive his work. I see, maybe we should ping Al and other interested folkz to see if there still is some interest to move this forward? [...] Kind regards Uffe
