Re: [PATCH] cavium: let USB subsystem determine the ARCH_HAS values
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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 IThe 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.
Paul.Ok, please try hard to resolve this first, before pooh-pooing other's attempts at resolving the issue :) thanks, greg k-h
-- 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
[Linux Media] [Video for Linux] [Linux Input] [Linux Audio Users] [Photo] [Yosemite News] [Yosemite Photos] [Free Online Dating] [Linux Kernel] [Linux SCSI] [Old Linux USB Devel Archive] [More Archives]