Hi Alexander, Please reduce the context when answering, otherwise it's hard to find all places where you commented. >> > > > That's the part that I'm not sure if I agree. if I remember from some >> > > > experiments in the past, >> > > > when you call to wake up the child, the parent will wakeup first anyway. >> > > > >> > > The child (mtd device) does not exist at this point of time. >> > > To create MTD device, the partition table should be provided >> > > and it read directly from flash that should be powered to do read. >> > >> > I don't understand... you have the mtd->dev at this point... this is >> > the one you should be touching, not the mtd->dev.parent... even at the >> > probe, but moreover on everywhere else as well. >> > >> >> At the probe time I do not have dev->mtd, but now I see you point here. >> I'll separate power management: >> - probe before dev->mtd creation will use aux_dev->dev (that will be mtd- >> >dev.parent later) >> - mtd functions will use mtd->dev >> >> Is this that you have in mind? > > I've tried it and found out that mtd->dev is not initialized if partitions are present [1]. > Miquel - this may be the reason why other mtd drivers use pci or platform > devices to manage runtime pm. > Or I have missed something? Please keep in mind there is _a lot_ of history behind mtd, and sometimes choices from the past cannot be simply "fixed" without breaking userspace. The problem with mtd is that the "mtd" structure defines nothing with precision. It may be a controller, a chip, a partition, or whatever mix of those. In this particular case, I believe you are mentioning the KEEP_PARTITIONED_MASTER configuration, which by default is unset, which means you'll loose the "top level" mtd device? However in general I believe the "framework" struct device is maybe less relevant than the "bus" struct device when it comes to runtime PM, so actually I would eventually expect this device to be used? > [1] https://elixir.bootlin.com/linux/v6.12-rc6/source/drivers/mtd/mtdcore.c#L1078 Thanks, Miquèl
