Re: [PATCH v6] mmc: Add mmc CMD+ACMD passthrough ioctl

[Arnd Bergmann <arnd@arndb.de>]

On Wednesday 20 April 2011, Chris Ball wrote:
> On Wed, Apr 20 2011, John Calixto wrote:
> > Have you had the chance to look at v6 of this patch?  If so, what do you
> > think?
> 
> Looks good to me.  Since Arnd's been reviewing, it'd be nice to get a
> Reviewed-by: tag from him and acknowledgement that his concerns are all
> addressed, and then I'll merge it.

Once the pointer passing is worked out, I think we have basically resolved
the technical issues. One more thing that I just noticed: The 
__u64 data_ptr needs to be aligned, otherwise you get a problem
on x86, which uses different alignment for 64 bit members in structures
between 32 and 64 bit ABIs. Putting the 64 bit members first in the data
structure, and adding padding at the end to have a size that is a multiple
of 8 bytes should take care of this.

I don't quite understand the timeout stuff in there, so I'm not sure how
I'd fill these from an application like qemu that blindly passes down
commands. I'd feel more comfortable if we didn't have to specify these
in the interface, but I have no strict objection if you think that passing
those is a reasonable requirement.

The more important question that is still unresolved however is the
nontechnical one:

Do we want users to use this interface for DRM applications?

I would still prefer having a more high-level interface for this, ideally
something where we just export a block device for the encrypted partition,
with an ioctl interface to do the authentication. Alternatively, I could
imagine an ioctl interface that exports each SD security command as a
separate ioctl command, including the block read/write ones.

The information to do this seems to be available in
http://issuu.com/sravan/docs/sd_card, which describes the ACMDs.
It shouldn't be too hard to implement them in a high-level API.
What I don't know is whether we have a clear policy about implementing
SD standard interfaces in the kernel that are not part of the redacted
specs.

	Arnd