linux-kernel - Re: [PATCH v4 07/11] ARM: allow MULTIPLATFORM with !MMU

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]

Message-ID: <24394c50bcd8000c21aca0360fd20b6f@agner.ch>
Date:	Mon, 06 Apr 2015 00:19:43 +0200
From:	Stefan Agner <stefan@...er.ch>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	shawn.guo@...aro.org, kernel@...gutronix.de,
	u.kleine-koenig@...gutronix.de, jason@...edaemon.net,
	olof@...om.net, arnd@...db.de, daniel.lezcano@...aro.org,
	tglx@...utronix.de, mark.rutland@....com, pawel.moll@....com,
	robh+dt@...nel.org, ijc+devicetree@...lion.org.uk,
	galak@...eaurora.org, marc.zyngier@....com,
	mcoquelin.stm32@...il.com, devicetree@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 07/11] ARM: allow MULTIPLATFORM with !MMU

On 2015-04-05 18:10, Russell King - ARM Linux wrote:
> On Sat, Apr 04, 2015 at 01:56:20AM +0200, Stefan Agner wrote:
>> On 2015-04-03 22:09, Russell King - ARM Linux wrote:
>> > On Fri, Apr 03, 2015 at 09:44:48PM +0200, Stefan Agner wrote:
>> >> In order to support SoC with heterogenous CPU architectures (such
>> >> as Freescale Vybrid/i.MXSX) it is preferable to use the same
>> >> architecture (ARCH_MXC in this case) for the MMU enabled and !MMU
>> >> CPU. Hence allow to select MULTIPLATFORM even without MMU.
>> >>
>> >> Signed-off-by: Stefan Agner <stefan@...er.ch>
>> >> ---
>> >>  arch/arm/Kconfig | 21 ++++++++++-----------
>> >>  1 file changed, 10 insertions(+), 11 deletions(-)
>> >>
>> >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> >> index 9f1f09a..636cb3f 100644
>> >> --- a/arch/arm/Kconfig
>> >> +++ b/arch/arm/Kconfig
>> >> @@ -230,7 +230,7 @@ config VECTORS_BASE
>> >>  	  in size.
>> >>
>> >>  config ARM_PATCH_PHYS_VIRT
>> >> -	bool "Patch physical to virtual translations at runtime" if EMBEDDED
>> >> +	bool "Patch physical to virtual translations at runtime" if EMBEDDED || (ARCH_MULTIPLATFORM && MMU)
>> >>  	default y
>> >
>> > This makes no sense.  Multiplatform MMU _requires_ this feature, so why
>> > offer it to the user when multiplatform is enabled _and_ MMU is enabled?
>>
>> I see, this is plain wrong. Will replace that with a select ... if MMU
>> in multiplatform.
> 
> I think what I'd like to see is, in the top level choice:
> 
> config ARM_SINGLE_ARMV7M
> 	bool "ARM architecture v7M compliant (Cortex-M0/M3/M4) SoC"
> 	depends on !MMU
> 	select ARM_NVIC
> 	... etc ...

I guess that would be ARCH_SINGLE_ARMV7M?

> 
> which then allows a /multiplatform/ v7M kernel to be built, allowing the
> selection of EFM32, SOC_VF610, and any other v7M compliant SoC.

In my view, that wouldn't end up being much different than what that
patchset is doing:
With the introduction of ARCH_MULTI_V7M, we add something like a top
level v7M compliant selection. Due to the !MMU dependencies of all other
CPU families the family selection is minimal (when selecting !MMU):

    *** CPU Core family selection *** 
[*] ARMv7-M based platforms (Cortex-M)

And since ARCH_MULTI_V7M is not part of ARCH_MULTI_V6_V7 or anything,
the whole SoC selection contains only sensible SoC's without further
changes (also within the i.MX family, currently only "Vybrid Family
VF610 support" is selectable):

[ ] MMU-based Paged Memory Management Support                       
    ARM system type (Allow multiple platforms to be selected)  ---> 
    Multiple platform selection  --->                               
[*] Energy Micro efm32                                              
[*] Freescale i.MX family  --->    
    *** Processor Type ***
...

> So, it's very similar to multiplatform in the sense that several SoCs
> can be built together, but we preserve the need not to build
> incompatible stuff together.

As far as I can tell, this is already the case with that patchset.

The differences boil down to on which level we split the v7M CPU
selection apart: On ARCH_* level or ARCH_MULTI_* level. Given that we
allow a multiplatform _v7M kernel, the latter sounds more natural to
me...

Are there arguments to split v7M CPU selection apart on ARCH_* level
which I don't see?

--
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/