quoted

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?