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. 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. Frank, Greg and I like this usage model for a new depends-on DT binding. Is this something you'd be willing to accept? Thanks, Saravana [1] - https://lore.kernel.org/lkml/20190731221721.187713-1-saravanak@xxxxxxxxxx/
