On 17 March 2016 at 08:36, Nguyen Viet Dung <nv-dung@xxxxxxxxxxx> wrote: > Hi Ulf, > > Thank for your reply. > > On 2016年03月16日 18:53, Ulf Hansson wrote: >> >> On 7 March 2016 at 04:17, Nguyen Viet Dung <nv-dung@xxxxxxxxxxx> wrote: >>> >>> Hi Ulf >>> >>> I have testted two cases use these patchs that you send. >>> >>> case01: >>> [PATCH 1/3] mmc: sh_mmcif: Make sure the device stays active when needed >>> in >>> ->probe() >>> [PATCH 2/3] mmc: sh_mmcif: Restructure ->set_ios() >>> [PATCH 3/3] mmc: sh_mmci: Get rid of wrapper function for regulators >>> >>> case02: >>> [PATCH 1/3] mmc: sh_mmcif: Make sure the device stays active when needed >>> in >>> ->probe() >>> >>> The problem of mmcif is not resolved by both two cases. >> >> Okay, thanks for testing! >> >> Even if it doesn't solve you original issue after a system PM resumed >> has been accomplished, does the driver still works as before? In other >> words are cards detected properly and can data transfers be done? > > After a system PM resumed has been accomplished,if write data to mmc then > happen kernel panic. >> >> The reason for my question, is that I think these patches makes some >> nice cleanups of some of the PM related code in the driver. So unless >> you see a *new* regression, I would like to apply them. > > If see only this problem of mmc,i can not know effect of these patchs. As I understand your test, there are no new issues observed. For that reason, I am going to apply patch 1->3 for next to give them some more testing. Please tell me if any new issues pops up. Regarding the issue you reported as a regression, unfortunate it seems like someone with the hardware at hand needs to some debugging. Kind regards Uffe -- 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
