@pbarker As far as I know mfd is mostly just a convenient way to have subdevices. We actually already had a fight with that maintainer because the SMC driver we have is a good fit for that subsystem, but he kept saying it wasn't because SMC doesn't "look" like most register-based drivers and he didn't understand why it made sense to use it. Still haven't had a chance to refactor and resubmit all that into what we finally agreed on (after a long mailing list discussion and a further IRC discussion).

But I don't think it fits here since in this case it's not even register-based devices involved only (e.g. tipd is on an I²C bus). We can't realistically nest all the dependencies under a parent driver. In fact for stuff like DCP which is behind a mux, that doesn't work at all since the mapping isn't 1:1.

And then the issue is getting things like the existing dwc3 driver to talk to us the way we need. No matter how you organize the device tree, that's still going to be a point of contention because it's a shared driver used by many other systems with different requirements.