Hi, On 05/08/2018 04:25 PM, Heikki Krogerus wrote: > Hi, > > On Mon, May 07, 2018 at 11:19:40PM +0200, Mats Karrman wrote: >>>> Even so, when the mux driver "set" function is called, it will just get the >>>> mode argument but since the mode (TYPEC_STATE_...) is overlapping for different >>>> AMs if I understand your proposal correctly, the mux also needs to know what AM >>>> is active. >>>> Does this imply that the mux set function signature need to change? >>> My plan was actually to propose we get rid of the current mux handling >>> (just leave the orientation switch) in favour of the notifications I'm >>> introducing with the type-c bus for the alternate modes. The current >>> mux handling is definitely not enough, and does not work in every >>> scenario, like also you pointed out. >> So, the mux need to subscribe to each svid:mode pair it is interested in using >> typec_altmode_register_notifier() and then use those callbacks to switch the correct >> signals to the connector. And a driver for an off-the-shelf mux device could have >> the translation between svid:mode pairs and mux device specific control specified by >> of/acpi properties. Right? > Yes. That is the plan. Would it work for you? I think so. I'll give it a go. When about do you think you'll post the next version of your RFC? Or do you have an updated series available somewhere public? BR // Mats > Thanks, -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
