On 17 May 2018 at 09:47, Shawn Lin <shawn.lin@xxxxxxxxxxxxxx> wrote: > It's pointless to switch and trace partition type if the current > selected device partition is the same with that one. Moreover, cycled > claiming host associated with mmc_blk_part_switch() could make > mmc_blk_remove() end up waiting for grabbing the context if it's > occupied, which lead requests could still hit the low-level drivers, > if an asynchronous unbind for host drivers happened, as the card hasn't > been set removed in the remove path. > > So a simple dd in background: > dd if=/dev/mmcblk0 of=/dev/null bs=512k count=100000 & > > and doing unbind then: > echo fe320000.dwmmc > /sys/bus/platform/drivers/dwmmc_rockchip/unbind > > could make the console stuck for quite a while depending on the > numbers of requests. > > Suggested-by: Adrian Hunter <adrian.hunter@xxxxxxxxx> > Signed-off-by: Shawn Lin <shawn.lin@xxxxxxxxxxxxxx> Thanks, applied for next! Kind regards Uffe > > --- > > Changes in v2: > - Skip mmc_blk_part_switch() stuff suggested by Adrian in the > disscussion of v1 in https://patchwork.kernel.org/patch/10334959/ > > drivers/mmc/core/block.c | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c > index 03e3d48..54457d8 100644 > --- a/drivers/mmc/core/block.c > +++ b/drivers/mmc/core/block.c > @@ -2968,9 +2968,11 @@ static void mmc_blk_remove(struct mmc_card *card) > mmc_blk_remove_debugfs(card, md); > mmc_blk_remove_parts(card, md); > pm_runtime_get_sync(&card->dev); > - mmc_claim_host(card->host); > - mmc_blk_part_switch(card, md->part_type); > - mmc_release_host(card->host); > + if (md->part_curr != md->part_type) { > + mmc_claim_host(card->host); > + mmc_blk_part_switch(card, md->part_type); > + mmc_release_host(card->host); > + } > if (card->type != MMC_TYPE_SD_COMBO) > pm_runtime_disable(&card->dev); > pm_runtime_put_noidle(&card->dev); > -- > 1.9.1 > > -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html