Re: [RFC PATCH 00/10] hw/sd: Start splitting SD vs SPI protocols

["Cédric Le Goater" <clg@kaod.org>]

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(-)
>