* Johan Hovold <johan@xxxxxxxxxx> [231016 15:18]: > On Sat, Oct 07, 2023 at 08:45:41AM +0300, Tony Lindgren wrote: > > * Johan Hovold <johan@xxxxxxxxxx> [231006 15:37]: > > > On Fri, Oct 06, 2023 at 11:37:12AM +0300, Tony Lindgren wrote: > > > > > 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. > > > > We want serial core to do runtime PM in a generic way and have the usage > > count propagate to the parent serial port hardware device. This way we > > don't need to care much if the numerous serial port drivers implement > > runtime PM or not. Well, except for now we need to check the parent state > > for this fix :) > > That sounds like a lot of complexity to avoid checking if (the single > instance of) pm_runtime_get() returns -EACCESS. Yes only one call so far. but we have the serial core generic PM patch(es) from Andy and Ilpo that are still coming. > > We also want serial core to know the serial port to serial port hardware > > mapping as we already have multiport devices. The serial core controller > > is there to group the serial ports for each serial port hardware device. > > We at least now have an option to support devices with multiple controllers > > and ports in case we ever happen to see such things. > > Hypothetical multiple serial controllers should be modelled as separate > controllers, but yeah, perhaps we want to describe the ports. Yes and we already have multiport controllers. > > > And if these are indeed needed, then why isn't the serdev controller now > > > a child of the "port" device, for example? > > > > Yes I agree we should now move serdev controller to be a child of the > > serial core port device. Then this $subject patch can be reverted. > > > > Moving serdev controller should also help serdev to deal with multiport > > devices I think? > > It wouldn't help currently I think, since we already resume the > controller and don't manage ports individually, but if we now have port > devices then it probably should be moved. I'll post a patch for that after some more checks. Regards, Tony
