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 -- 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
