On Thu, Oct 3, 2019 at 1:51 PM Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > On 03-10-2019 22:37, John Stultz wrote: > > Fair point. I'm sort of taking a larger patchset and trying to break > > it up into more easily reviewable chunks, but I guess here I mis-cut. > > > > The user is the hikey960 gpio hub driver here: > > https://git.linaro.org/people/john.stultz/android-dev.git/commit/?id=b06158a2d3eb00c914f12c76c93695e92d9af00f > > Hmm, that seems to tie the TypeC data-role to the power-role, which > is not going to work with role swapping. Thanks again for the feedback here. Sorry for the slow response. Been reworking some of the easier changes but am starting to look at how to address your feedback here. > What is controlling the usb-role-switch, and thus ultimately > causing the notifier you are suggesting to get called ? The tcpm_mux_set() call via tcpm_state_machine_work() > Things like TYPEC_VBUS_POWER_OFF and TYPEC_VBUS_POWER_ON > really beg to be modeled as a regulator and then the > Type-C controller (using e.g. the drivers/usb/typec/tcpm/tcpm.c > framework) can use that regulator to control things. > in case of the tcpm.c framework it can then use that > regulator to implement the set_vbus callback. So I'm looking at the bindings and I'm not sure exactly how to tie a regulator style driver into the tcpm for this? Looking at the driver I just see this commented out bit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/typec/tcpm/tcpm.c#n3075 Do you happen to have a pointer to something closer to what you are describing? thanks -john
