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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 1 Aug 2018 09:54:41 -0400
From:   Alexei Colin <acolin@....edu>
To:     Russell King - ARM Linux <linux@...linux.org.uk>
Cc:     Alex Bounine <alex.bou9@...il.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        linux-kernel@...r.kernel.org, John Paul Walters <jwalters@....edu>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 6/6] arm64: enable RapidIO menu in Kconfig

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