> > Why we cannot use "select HAS_RAPIDIO" HW-specific Kconfig file > > (mach-*/Kconfig)? And have on-chip port selection in the same board-specific > > place. > > As I've already explained, HAS_RAPIDIO has the expectation that it > controls the availability of the RAPIDIO option, not of drivers. > It is HAS_*RAPIDIO*, the clue is in the name. Using it as you are > (basically, to mean that on-SoC rapidio hardware is present) and > allowing such configurations as HAS_RAPIDIO=n RAPIDIO=y PCI=y is > completely counter-intuitive.
The intention in the patch was for HAS_RAPIDIO to mean exactly "on-SoC RapidIO hardware is present". Since the name does not reflect that well, I'll change it in the next version: would HAS_RAPIDIO_ONCHIP reflect the meaning well? HAS_RAPIDIO=n RAPIDIO=y PCI=y should be an intuitive configuration, for example for MIPS until last week it effectively was the only option https://www.linux-mips.org/archives/linux-mips/2018-07/msg00584.html If we have to rename to make this configuration intuitive again, then I'll rename and resubmit. There was never the intention to assign any other meaning to HAS_RAPIDIO, specifically that it controls the availability of the RAPIDIO menu option. I think interpreting it this way is is behind a lot of the issues raised. The intention is that availability of the menu options is controlled by (1) whether the architecture sources the rapidio/Kconfig and (2) whether dependencies of RapidIO are satisfied (either having a PCI bus and enabling it, or having the on-SoC RapidIO hardware. The patch does not indend to change the current meaning and usage of the config options and behavior for X86, PPC, MIPS -- the patch only refactors there (because it was requested). For ARM and ARM64, we are adding the same behavior in same way as for those three architectures. I assume there is nothing that sets ARM and ARM64 apart from the others in this narrow context. This is the indended scope of this patch. Are we now discussing a change in the current meaning/usage/behavior? If so, could we do one piece at a time -- first, add ARM and ARM64 in the way consistent with the way other architectures currently do it?
