> > >> @@ -474,20 +478,28 @@ static int intel_dg_mtd_erase(struct mtd_info > > *mtd, struct erase_info *info) > > >> total_len = info->len; > > >> addr = info->addr; > > >> > > >> + ret = pm_runtime_resume_and_get(mtd->dev.parent); > > > on this, I really don't believe this is right and we should use > > > the parent child relation ship in our favor and only have the mtd > > > device to handle their own runtime pm... > > I concur with Rodrigo. If the parent-child relationship is preserved, > > the parent will resume before the child, eliminating the need to > > explicitly wake the parent. > > Please refer to https://docs.kernel.org/driver-api/pm/devices.html > > > > The ordering of the device hierarchy is defined by the order in which > > devices get registered: > > "a child can never be registered, probed or > > resumed before its parent; " > > and can’t be removed or suspended after that parent. > > > > > If so, I have to add patch for mtd subsystem to always have device for master > initialized regardless of kernel flag. > Only to initialize struct device, not to create full mtd node. > > Miquel - are you agree to this? I've looked deeply in the mtd code and there is some interesting discrepancy: - the mtd partition creates device and puts parent of parent in its parent pointer if master does not exist - the callbacks, like _write/_read/_erase receive master object pointer Thus, we can't use good partition device for power management... Maybe rewrite these callbacks to receive actual partition (huge change all over)? > > - - > Thanks, > Sasha >
