On Monday 27 May 2013, Peter Turczak wrote: > > Therefore I propose to add a basic support for locked cards in the > kernel. The user space applications might take care of unlocking the > card afterwards. When a card has been unlocked it stays unlocked > until cycling it, reset commands won't lock it again. Seems reasonable to me. > My questions are: > 1. Should a card that is locked be visible via /dev/mmcblkX? > I think it should be, in order to be able to issue an unlock command Agreed > 2. What should read/write operations return on a locked card EPERM, EACCESS > or something else? I would have said EIO, but I don't have a strong opinion. > 3. Should locking/unlocking be done via a special ioctl command, as the > card needs to be rescanned anyways? I'd say we should use the generic ioctl unless it doesn't work. I would not object an unlock ioctl either if other people think that's a good idea. > 4. How to cleanly initiate a rescan from userspace if answer to 3 is no? > Currently I issue a reset command to the card which forces to kernel to > fail issuing CMD13 and therefore reinitialize it, not too nice honestly. Adding a rescan ioctl would have other possible applications, so that seems better than a special unlock ioctl. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
