On 6/24/21 4:21 PM, Philippe Mathieu-Daudé wrote:
> Hi Cédric,
>
> After our discussion yesterday about how to add support for MMC
> (and eMMC) I looked at how to easily add these bus protocols,
> which might have commands quite different, avoiding to have big
> unreadable if/else statements.
>
> I'm not yet happy enough with the result but it is a starting
> point which keeps things still simple.
this is a good framework but I would introduce a Class.
> What I'm wondering is if we could include the command classes
> (as another dimension in the array).
I don't quite get what you mean ?
> Also if we could use the
> older spec version supported as base set of commands, and if the
> user asks for more recent spec version, for each version we
> overwrite the array of commands. Thoughts?
Yes. I think we need another RFC to see how it looks :)
I expect these command arrays to be static. Duplicating the base
array to add custom handlers for a new version of a protocol
should be ok.
Thanks,
C.
>
> Phil.
>
> Philippe Mathieu-Daudé (10):
> hw/sd: When card is in wrong state, log which state it is
> hw/sd: Extract address_in_range() helper, log invalid accesses
> hw/sd: Move proto_name to SDProto structure
> hw/sd: Introduce sd_cmd_handler type
> hw/sd: Add sd_cmd_illegal() handler
> hw/sd: Add sd_cmd_unimplemented() handler
> hw/sd: Add sd_cmd_GO_IDLE_STATE() handler
> hw/sd: Add sd_cmd_SEND_OP_CMD() handler
> hw/sd: Add sd_cmd_ALL_SEND_CID() handler
> hw/sd: Add sd_cmd_SEND_RELATIVE_ADDR() handler
>
> hw/sd/sd.c | 251 ++---
> 1 file changed, 143 insertions(+), 108 deletions(-)
>