Re: [PATCH 6/6] arm64: enable RapidIO menu in Kconfig

From: Alexei Colin
Date: Wed Aug 01 2018 - 09:54:45 EST

> > 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
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

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?