Re: [PATCH v7 2/4] usb: dwc3: qcom: Add interconnect support in dwc3 driver
From: Bjorn Andersson <hidden>
Date: 2020-05-18 18:36:38
Also in:
linux-arm-msm, linux-usb, lkml
On Thu 14 May 23:29 PDT 2020, Felipe Balbi wrote:
Hi, Georgi Djakov [off-list ref] writes:quoted
quoted
quoted
quoted
quoted
quoted
Sandeep Maheswaram [off-list ref] writes:quoted
+static int dwc3_qcom_interconnect_init(struct dwc3_qcom *qcom) +{ + struct device *dev = qcom->dev; + int ret; + + if (!device_is_bound(&qcom->dwc3->dev)) + return -EPROBE_DEFER;this breaks allmodconfig. I'm dropping this series from my queue for this merge window.Sorry, I meant this patch ;-)I guess that's due to INTERCONNECT being a module. There is currently aI believe it's because of this: ERROR: modpost: "device_is_bound" [drivers/usb/dwc3/dwc3-qcom.ko] undefined!quoted
discussion about this with Viresh and Georgi in response to another automated build failure. Viresh suggests changing CONFIG_INTERCONNECT from tristate to bool, which seems sensible to me given that interconnect is a core subsystem.The problem you are talking about would arise when INTERCONNECT=m and USB_DWC3_QCOM=y and it definitely exists here and could be triggered with randconfig build. So i suggest to squash also the diff below. Thanks, Georgi ---8<---diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig index 206caa0ea1c6..6661788b1a76 100644 --- a/drivers/usb/dwc3/Kconfig +++ b/drivers/usb/dwc3/Kconfig@@ -129,6 +129,7 @@ config USB_DWC3_QCOM tristate "Qualcomm Platform" depends on ARCH_QCOM || COMPILE_TEST depends on EXTCON || !EXTCON + depends on INTERCONNECT || !INTERCONNECTI would prefer to see a patch adding EXPORT_SYMBOL_GPL() to device_is_bound()Agree, but just to clarify, that these are two separate issues that need to be fixed. The device_is_bound() is the first one and USB_DWC3_QCOM=y combined with INTERCONNECT=m is the second one.If INTERCONNECT=m, QCOM3 shouldn't be y. I think the following is enough: depends on INTERCONNECT=y || INTERCONNECT=USB_DWC3_QCOM
This misses the case where INTERCONNECT=n and USB_DWC3_QCOM=[ym] which I don't see a reason for breaking. But if only INTERCONNECT where a bool, then we don't need to specify a depends on, because it will either be there, or the stubs will. We've come to this conclusion in a lot of different frameworks and I don't see why we should do this differently with INTERCONNECT. Regards, Bjorn