Re: [PATCH] mmc: block: ioctl: Poll for TRAN if possible

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>> +        */
>> +       return !(cmd->opcode == MMC_SEND_CID
>> +                       || cmd->opcode == MMC_ALL_SEND_CID
>> +                       || cmd->opcode == MMC_SEND_CSD
>> +                       || cmd->opcode == MMC_SEND_STATUS
>> +                       || cmd->opcode == MMC_SELECT_CARD
>> +                       || cmd->opcode == MMC_APP_CMD
>> +                       || cmd->opcode == MMC_GO_INACTIVE_STATE
>> +                       || cmd->opcode == MMC_GO_IDLE_STATE);
>> +
>Aren’t you only interested in cmds that move to tran state from other state?
>According to the Device state transitions (table 61 in eMMC5.1) it only concern
>cmd7 (stby->tran), cmd12 (data->tran), and cmd14 (btst->tran).
>
>Thanks,
>Avri

No, I'd poll for any command where this is possible, so I only exclude the
ones not ending up in TRAN.
The TRAN->RCV->PRG->TRAN commands are the ones that need polling
to be race condition free.
Technically CMD16, 23  and so on (TRAN->TRAN directly) don't need the
CMD13 polling but it does not hurt either, especially because the cmd->opcode
itself overlaps for general and sd commands.
Tracking whether CMD55 was the last command would have been awkward and
CMD13 polling wherever possible seems the more sane option.
If adding a flag to disable any inter-CMD13 polling of none-R1b commands is
desired, I can add that, but I did not see a good reason for that right now.

Regards,
Christian
Hyperstone GmbH | Line-Eid-Strasse 3 | 78467 Konstanz
Managing Directors: Dr. Jan Peter Berns.
Commercial register of local courts: Freiburg HRB381782




[Index of Archives]     [Linux Memonry Technology]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux