On Fri, Oct 06, 2023 at 11:37:12AM +0300, Tony Lindgren wrote: > * Johan Hovold <johan@xxxxxxxxxx> [231006 08:03]: > > On Fri, Oct 06, 2023 at 10:27:38AM +0300, Tony Lindgren wrote: > > > You're right, so how about: > > > > > > The serdev device and the serial core controller devices are children of > > > the serial port hardware device. The runtime PM usage count from serdev > > > device does not propagate to the serial core device siblings, it only > > > propagates to the parent. > > > > That's still not accurate: > > > > - the serdev device is not a child (but a grandchild) of the serial > > controller > > - the new serial port devices are not "siblings" (but descendants) of > > the serial controller > > - the serdev controller ignores the power state of its children so that > > bit is also incorrect > > > > You just want to describe the fact that the serdev controller runtime PM > > state is currently not propagated to your new "devices" that are > > descendants to the serial controller. > > OK so let's just use: > > The serdev controller runtime PM state is not currently propagated > to the serial core controller port device. The runtime PM usage count > only propagates to the parent device. That sounds better. > > I'm still not sure why it was implemented this way, or if it is even > > correct, but this seems to be the state of things. > > Care to clarify a bit which parts are unclear? The hierarchy of port > devices, making serial core manage runtime PM in a generic way, or > flushing tx? I still don't know why you added these two new abstractions (controller and port), and that isn't really explained by the commit message either. And if these are indeed needed, then why isn't the serdev controller now a child of the "port" device, for example? There are just a lot of questions and I worry that there are more problems lurking, but unfortunately I still don't have time to review this. Johan
