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
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.
David Daney
