Hi all, Chris Ball wrote: > Ah, we're not proposing a new ioctl for this -- we're proposing that > the > perm-r/o command could be sent from a userspace binary that *uses* the > arbitrary command ioctl that we already have. > > The arbitrary command ioctl is > drivers/mmc/card/block.c:mmc_blk_ioctl_cmd(). > > Please could you send a version of the patch that supports power-on r/o > but not perm r/o, and perhaps also post userspace code for submitting > the perm r/o command through the ioctl interface? (Perhaps this code > should eventually be submitted to a disk management tool..) I've reworked the patch now, and will send it in a moment. I've also written some sample userspace code using the ioctl, but I'm having a hard time getting it to issue the MMC_SWITCH opcode -- the ioctl call never returns. I believe this problem is similar to the issue discussed in a separate thread (Extension of MMC Block IOCTL ...), since I'm sending no data with the data_ptr. I have a patch for this as well, which does not initiate the struct mmc_data if blksz and blocks is zero, but I'm not sure this is the proper way to do it for all commands and uses. I can send it if there is interest. > Also, it looks like it's possible to set read-only for the whole > device, > as well as for boot partitions. Could you update the patch to allow > setting power-on r/o for the entire card, not just the boot partitions? Hmm, I'm not able to find this in the spec -- could you point a little closer please? > I think the overlap between your patch and Andrei's > mmcblkXbootY/force_ro > node is going to be confusing -- one operates purely in the kernel and > the other is sent to the card. Do you have any proposal for making the > difference clearer? At least it is mentioned in the documentation now. Kind regards, Johan -- 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
