| Message ID | 20210624142209.1193073-1-f4bug@amsat.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | hw/sd: Start splitting SD vs SPI protocols | expand |
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(-) >