Jon, Ulf,
Can we first get the current implementation upstream and _then_ add
more patches to it?
On Mon, Sep 21, 2015 at 4:19 AM, Jon Hunter <jonathanh@xxxxxxxxxx> wrote:
...
>>>> + for (i = 0; i < num_of_cmds; i++) {
>>>> + err = __mmc_blk_ioctl_cmd(card, md, idata[i]);
>>>> + if (err) {
>>>> + mmc_put_card(card);
>>>> + goto cmd_done;
>>> Instead of exiting here, you should first copy to the user the data
>>> and response of successful commands, mark the failed command as failed
>>> and the remaining ones as "not executed".
>>> This way, it will be easier for the user space application to find out
>>> where the sequence failed. This especially true if some reverts are
>>> needed.
>>
>> Yes that sounds like a sensible thing to do. I will incorporate that change.
I also liked Gwendal's idea and incorporated that into our 3.18 kernel
tree here:
https://chromium-review.googlesource.com/#/c/299956
(this is on top of Jon's most recently proposed patch - we'll align
with what lands shortly)
But as I've demonstrated, this can be a separate patch.
cheers,
grant
>
> At first, I thought that may be the response field of the command could
> be used to indicate the failed command. However, thinking about this
> some more, I am not sure that it seems correct to use this field as this
> is really used to carry the MMC response as defined by the MMC
> specification.
>
> Should the response field always be non-zero for a successful command?
> If this is guaranteed, then may be the best thing to do would be to have
> user-space clear the response field to field before submitting the
> commands. It would then be easy to detect which command failed and which
> were not attempted.
>
> Ulf, what are your thoughts?
>
> Cheers
> Jon
--
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
