a8328210d0
ensure that all such commands have a non-zero retry count except for those that are expected to fail (for example, because they are used to probe for feature support). While it is possible to pass a retry count down to the hardware driver in the command request structure, no hardware driver currently implements any retry logic. The hardware doesn't know much about the context of a single request, so it makes more sense to handle retries at a layer that does. This adds retry loops to the mmc_wait_for_cmd() and mmc_wait_for_app_cmd() functions. These functions are the gateway from other code within mmc.c to the hardware. App commands are a sequence of two commands and a retry has to rerun both of them in order, so it needs its own retry loop. Retry looping is specifically NOT implemented in mmc_wait_for_request() because it is the gateway for children on the bus, and they have to implement their own retry logic depending on what makes sense for them. |
||
|---|---|---|
| .. | ||
| bridge.h | ||
| mmc.c | ||
| mmcbr_if.m | ||
| mmcbrvar.h | ||
| mmcbus_if.m | ||
| mmcreg.h | ||
| mmcsd.c | ||
| mmcvar.h | ||