7f6921ae18
they don't check the result of BUS_READ_IVAR(9) and silently return stack garbage on failure in case a bus doesn't implement a particular instance variable for example. With MMC bridges not providing MMCBR_IVAR_RETUNE_REQ, yet, this in turn can cause mmc(4) to get into a state in which re-tuning seems to be necessary but is inappropriate, causing mmc_wait_for_request() to fail. Thus, don't use __BUS_ACCESSOR() for mmcbr_get_retune_req() and instead provide a version of the latter which returns retune_req_none if reading MMCBR_IVAR_RETUNE_REQ fails. One more straight-forward solution would have been to change mmc(4) to not call mmcbr_get_retune_req() if the current transfer mode doesn't require re-tuning to begin with. However, for modes such as SDR50, it depends on the controller whether periodic re-tuning is need. Therefore, knowledge of whether a particular transfer mode does require re-tuning should be kept to the bridge drivers. This change is the generic version of r338271, as intended not requiring bridge drivers to be touched (unless transfer modes beyond high speed are to be supported that is). Approved by: re (gjb) |
||
---|---|---|
.. | ||
host | ||
bridge.h | ||
mmc_ioctl.h | ||
mmc_private.h | ||
mmc_subr.c | ||
mmc_subr.h | ||
mmc.c | ||
mmcbr_if.m | ||
mmcbrvar.h | ||
mmcbus_if.m | ||
mmcreg.h | ||
mmcsd.c | ||
mmcvar.h |