On 12/06/2012 07:24 AM, Seungwon Jeon wrote: > Hi, > > Doesn't it consider SD path? > It have a problem with uninitialized 'context_info'. > 'context_info' is moved into mmc_host struct in v4. > Please, could you explain the reason in brief? >
The problem I'm trying to resolve with the v4 change is: there should be no core/core.c API change from upper layers point of view. There was such violation, when the synchronization mechanism of async request for data commands was changed (from "completion" to "wait_event" + number of flags to pass event reason). Before v4, the 'context_info' initialized by mmc_init_queue() function and this is valid only for mmcblk. For example when running the mmc_test module, the code for card/queue.c, card/block.c layers is not run at all and the struct remains uninitialized. In the current version the initialization was moved into mmc_attach_mmc(), but now, I understand, that this initialization should be moved even before mmc_attach_XXX() (XXX is sdio/sd/mmc...) - it may be placed in mmc_rescan_try_freq(). Will resend v4 after the testing. 'mmc_host' structure contains a host information for all sdio/sd/mmc, so 'context_info' may be accessed by any protocol willing to use NEW_REQUEST notification (when async request mechanism is used). -- Konstantin Dorfman, QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
