> >> > This streamlines device tree and allows to anchor > >> > runtime power management on master device in all cases. > >> > >> Please explain in more detail why this is needed. > >> If this change makes the overall situation better and breaks > >> no userspace, I'm happy. :-) > >> > > > > The rest of the series is a driver that need runtime power management. > > Absence of the master device breaks power management logic, > > as kernel automatically propagates state from children to parent. > > I initially hooked runtime_pm on chip auxiliary device, but this is a hack, > > not a solution. > > So, the problem is that mtd partitions don't have a common parent/master > like > we have for generic disks? > Please give more details. > We have already a non-optimal situation in mtd and I want to fully understand > the requirements to get it this time right. > Yes, the mtd may have master, if CONFIG_MTD_PARTITIONED_MASTER is set, but it came with forced partition and usually unset in generic distributions. If CONFIG_MTD_PARTITIONED_MASTER is unset the dev structure is not initialized in full. I've tried to preserve status-quo when CONFIG_MTD_PARTITIONED_MASTER is set and introduce initialized master device structure otherwise. > Thanks, > //Richard - - Thanks, Sasha
