On Thu, Feb 11, 2016 at 10:00:50AM +0100, Ulf Hansson wrote: > On 11 February 2016 at 01:07, Wolfram Sang <wsa@xxxxxxxxxxxxx> wrote: > >> I suspect you are using a delayed work in this driver to deal with > >> request timeouts. > >> > >> The value for the delay that is used, needs to be informed towards the > >> mmc core via the "->max_busy_timeout". > > > > Shouldn't that be a seperate patch? In patch 9, I add support for > > another SoC. But your requested change will affect all SoCs. > > This is related to how the core treat hosts that announces > MMC_CAP_WAIT_WHILE_BUSY. > > Therefore max_busy_timeout needs to be set within the same patch. Right. I assumed previous SoC (Gen2) were using MMC_CAP_WAIT_WHILE_BUSY already, so this step would then have to be taken seperately to catch all SoC. But I was wrong. I meanwhile found the timeout bits which are present in Gen3 and also in Gen2 and are currently unused by the driver. While this helps explaining that the HW has internal busy detection, its full potential is not implemented yet. So, I am going to resend patch 9 without MMC_CAP_WAIT_WHILE_BUSY set and will implement timeout handling incrementally as a seperate series. Sounds good? -- 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
