On Fri, Mar 9, 2012 at 6:55 PM, gregkh@xxxxxxxxxxxxxxxxxxx <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > On Fri, Mar 09, 2012 at 03:50:50PM -0800, David Daney wrote: >> On 03/09/2012 03:05 PM, gregkh@xxxxxxxxxxxxxxxxxxx wrote: >> >On Fri, Mar 09, 2012 at 02:59:05PM -0800, David Daney wrote: >> >>On 03/09/2012 02:31 PM, Paul Gortmaker wrote: >> >>>It seems that the current trend is to have the USB subsystem >> >>>"know" which arch are ECHI and OHCI, versus having the board >> >>>manually select the values. >> >> >> >>I think the opposite is true, which is why the OCTEON code is in its >> >>current state. >> > >> >What is the "current state"? >> > >> >> The board Kconfig code selects USB_ARCH_HAS_EHCI. >> >> This way we don't have an ever growing list of: >> >> default y if SOME_GARBAGE >> >> in drivers/usb/Kconfig >> >> Also you can add new boards by selecting USB_ARCH_HAS_EHCI in the >> architecture Kconfig without bothering or depending on the USB >> maintainers. >> >> >> >>Unless Greg KH overrides me, I would have to say NACK. >> > >> >Why? Isn't this the way that other boards work? >> >> Some of them do, but do you like it that way? Sprinkling board >> dependent code throughout the various generic Kconfig files in the >> drivers tree? >> >> I much prefer putting all the board specific code in one place in >> the Kconfig for the particular board. Others may have different >> tastes than I >> >> > >> >>>The current defconfig for Cavium >> >>>produces the following: >> >>> >> >>> warning: (MIPS_ALCHEMY&& CAVIUM_OCTEON_REFERENCE_BOARD&& >> >>> SOC_AR71XX&& SOC_AR724X&& SOC_AR913X&& SOC_AR933X) selects >> >>> USB_ARCH_HAS_EHCI which has unmet direct dependencies (USB_SUPPORT) >> > >> >How will you resolve this warning if you NACK this patch? >> > >> >> I might try: >> >> select USB_ARCH_HAS_OHCI if USB_SUPPORT ...which is exactly what I described in the commit log. >> >> I'm not sure if it would work though. If it didn't, then I would >> try very hard to find something that did before I moved this into >> drivers/usb/Kconfig. It does work. This is what I tried 1st before sending the patch. But I looked at it and decided that it was simply wrong. As I noted in the commit log, it is somewhat bogus, because to change "ARCH_HAS" based on what the end user chooses, is really false. The arch either has it or it does not. The end user choice does _not_ change whether the arch has the capability or does not. That is why I went with letting the subsystem choose. The idea of the user's config choice actually changing whether an arch has or does not have a feature is totally misleading. Paul. > > Ok, please try hard to resolve this first, before pooh-pooing other's > attempts at resolving the issue :) > > thanks, > > greg k-h >
