Hi Rob, > > Either I'm missing something, or the devicetree description of the > > Type-C connectors really is way too complex, way too "low level", > > causing us potential problems without providing anything that we could > > actually ever use in the operating system. > > Well, all bindings are a balancing act of being flexible enough vs. > high-level enough to be stable. What I need is something that's going > to work for everyone, not just CrOS. Adding a new property at time is > death by 1000 cuts and usually a sign of someone only fixing their own > immediate problem. If you referring to the phandles that are related to the muxes, then those we will need. Those phandles point to the components that can configure the muxes, but those components are not the muxes themselves. On these platforms the muxes can not be configured directly, and this is by the way the normal setup these days. I have even alternate mode adapters that do not configure the mux directly from the microcontroller. So we are not talking about the first platform with this setup here. The problem is that these components are not physically connected to the connector, so we can't place them to the OF graph. The mux should be placed into the graph (we may not be able to configure the muxes, but we may still be able to read their status), but these components should not. I was really hoping that we could follow the "mux-controller" bindings, but it just did not feel it would work perfectly with these components that are not exactly the mux-controllers, but more like proxies to the actual mux-controllers. We could probable ignore that fact if the real mux-controllers were not visible to us, but unfortunately they are visible to us. More importantly, the "muxes" that we need to use with USB Type-C connectors will not always be actual muxes at all. Depending on the platform, for example the USB role switching will be handled by a mux, or a dual-role capable USB controller. But I'm open for suggestions here. The only thing that I can say for sure about this is that we can't rely on OF graph with the muxes. Right now I actually only have a wish that we had a reference array that would hold all the phandles to the components that can configure the lines behind the connector a bit like in mux bindings, but regardless of were they real muxes, "proxy" to the muxes, or anything else. Then we would need to define also somekind of device property for each known function, like "orientation", "role" and so on, that would return index to the component (mux, or what ever it is) in the reference array that can handle that particular function. I also don't feel comfortable using the name "mux" with these because, they really will not always be muxes. That's why I talk about switches, though I'm not sure if that's any better. Sorry about the long mail. thanks, -- heikki
