On Thu, Aug 22, 2019 at 1:55 AM Saravana Kannan <saravanak@xxxxxxxxxx> wrote: > > Hi Rob, > > Frank, Greg and I got together during ELC and had an extensive and > very productive discussion about my "postboot supplier state cleanup" > patch series [1]. The three of us are on the same page now -- the > series as it stands is the direction we want to go in, with some minor > refactoring, documentation and naming changes. > > However, one of the things Frank is concerned about (and Greg and I > agree) in the current patch series is that the "cyclic dependency > breaking" logic has been pushed off to individual drivers using the > edit_links() callback. I would think the core can detect this condition. There's nothing device specific once you have the dependency tree. You still need to know what device needs to probe first and the drivers are going to have that knowledge anyways. So wouldn't it be enough to allow probe to proceed for devices in the loop. Once 1 driver succeeds, then you can enforce the dependencies on the rest. > The concern being, there are going to be multiple device specific ad > hoc implementations to break a cyclic dependency. Also, if a device > can be part of a cyclic dependency, the driver for that device has to > check for specific system/products in which the device is part of a > cyclic dependency (because it might not always be part of a cycle), > and then potentially have cycle/product specific code to break the > cycle (since the cycle can be different on each system/product). > > One way to avoid all of the device/driver specific code and simplify > my patch series by a non-trivial amount would be by adding a > "depends-on" DT binding that can ONLY be used to break cycles. We can > document it as such and reject any attempts to use it for other > purposes. When a depends-on property is present in a device node, that > specific device's supplier list will be parsed ONLY from the > depends-on property and the other properties won't be parsed for > deriving dependency information for that device. Seems like only ignoring the dependencies with a cycle would be sufficient. For example, consider a clock controller which has 2 clock inputs from other clock controllers where one has a cycle and one doesn't. Also consider it has a regulator dependency. We only need to ignore the dependency for 1 of the clock inputs. The rest of the dependencies should be honored. > Frank, Greg and I like this usage model for a new depends-on DT > binding. Is this something you'd be willing to accept? To do the above, it needs to be inverted. Convince me that cycles are really a problem anywhere besides clocks. I'd be more comfortable with a clock specific property if we only need it for clocks and I'm having a hard time imagining cycles for other dependencies. Rob
