> On Tue, Jul 01, 2014 at 08:50:19AM +0530, Sachin Kamat wrote: >> On Mon, Jun 30, 2014 at 10:19 PM, Felipe Balbi <balbi@xxxxxx> >> wrote: >>> On Mon, Jun 30, 2014 at 02:33:14PM +0530, Sachin Kamat wrote: >>>> Make the config depend on ARCH_EXYNOS5 instead of ARCH_EXYNOS >>>> as this IP is available only on Exynos5 platforms. >>>> >>>> Signed-off-by: Sachin Kamat <sachin.kamat@xxxxxxxxxxx> --- >>>> drivers/usb/dwc3/Kconfig | 2 +- 1 file changed, 1 >>>> insertion(+), 1 deletion(-) >>>> >>>> diff --git a/drivers/usb/dwc3/Kconfig >>>> b/drivers/usb/dwc3/Kconfig index 261c3b428220..24a4f8ed9fd1 >>>> 100644 --- a/drivers/usb/dwc3/Kconfig +++ >>>> b/drivers/usb/dwc3/Kconfig @@ -55,7 +55,7 @@ config >>>> USB_DWC3_OMAP >>>> >>>> config USB_DWC3_EXYNOS tristate "Samsung Exynos Platform" - >>>> depends on ARCH_EXYNOS || COMPILE_TEST + depends on >>>> ARCH_EXYNOS5 || COMPILE_TEST >>> >>> what happens when you have exynos[6789] ? Are we going to >>> continually increase this line ? To me this is a pointless >>> change. >> >> I am not sure if the IP would remain same in future Exynos SoCs. >> However for what we know for now is that this IP exists only on >> Exynos5 and it makes sense that the dependency reflect the same. I >> am not introducing any new dependency, just making the existing one >> accurate. If you feel this is a pointless change, please feel free >> to drop this patch. > > The point is that this dependency has the potential to grow every year > or so and that's just churn going upstream. You don't want OMAP to build > Exynos glue layer and that's fine (and coverned by ARCH_EXYNOS) but > consider the situation of new silicon wakeup. Just to be able to build > the USB driver, you're gonna have to change this line because you're > in the process of waking up a new SoC that doesn't match with > ARCH_EXYNOS5. You see the point ? Yes, I get the point now. Thanks for the detailed explanation, Felipe :) -- Regards, Sachin. -- 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