On 03/09/2012 05:02 PM, Paul Gortmaker wrote:
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.
Let's think about this a bit more before coming to a final decision
about this patch. I will try some things Monday.
David Daney
Paul.
Ok, please try hard to resolve this first, before pooh-pooing other's
attempts at resolving the issue :)
thanks,
greg k-h
