On Wed 07 Jul 20:06 PDT 2021, Peter Chen wrote: > On 21-07-07 14:03:19, Bjorn Andersson wrote: > > On Tue 06 Jul 20:57 CDT 2021, Peter Chen wrote: > > > > Allow me to reorder your two questions: > > > > > And why using a notifier need to concern core's deferral probe? > > > > The problem at hand calls for the core for somehow invoking > > dwc3_qcom_vbus_overrride_enable() with a pointer to dwc3_qcom passed. > > > > This means that dwc3-qcom somehow needs to inform the dwc3-core about > > this (and stash the pointer). And this can't be done until dwc3-core > > actually exist, which it won't until dwc3_probe() has completed > > successfully (or in particular allocated struct dwc). > > Maybe you misunderstood the notifier I meant previous, my pointer was > calling glue layer API directly. > > Role switch is from dwc3-core, when it occurs, it means structure dwc3 has > allocated successfully, you could call glue layer notifier at function > dwc3_usb_role_switch_set directly. > Some references of my idea [1] [2] > > [1] Function ci_hdrc_msm_notify_event at ci_hdrc_msm_notify_event > [2] https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/usb/dwc3/core.c?h=lf-5.10.y#n205 > Hi Peter, I took a proper look at this again, hoping to find a way to pass a callback pointer from dwc3-qcom to the dwc3 core, that can be called from __dwc3_set_mode() to inform the Qualcomm glue about mode changes. This looks quite promising and I think we should be able to get rid of some duplicated extcon code from the Qualcomm glue as well... I reworked the existing code to replace of_platform_populate() with of_platform_device_create_pdata() to register the core device and pass a struct with a function pointer and this works fine. But then I searched the list archives and found this: https://lore.kernel.org/lkml/CAL_JsqJ5gsctd7L3VOhTO1JdUqmMmSJRpos1XQyfxzmGO7wauw@xxxxxxxxxxxxxx/ In other words, per Rob's NACK this seems like a dead end. @Rob, for your understanding, the dwc3 platform glue is implemented in a set of platform_drivers, registering the core as a separate platform_device and we need to make a function call from the core dwc3 code into the glue code. My initial proposal was that we provide some helper function that the glue code would use to allocate and register the core device, along which we can pass such callback information. But this turns out to pretty much be a re-implementation of of_platform_device_create_pdata(). Perhaps that's still preferable? Regards, Bjorn
