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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
