linux-kernel - Re: [GIT PULL] at91: soc for 3.18 #2

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 26 Sep 2014 16:47:12 +0200
From:	Nicolas Ferre <nicolas.ferre@...el.com>
To:	Arnd Bergmann <arnd@...db.de>
CC:	Olof Johansson <olof@...om.net>, <arm@...nel.org>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
	Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
	Boris BREZILLON <boris.brezillon@...e-electrons.com>,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
	Ludovic Desroches <ludovic.desroches@...el.com>
Subject: Re: [GIT PULL] at91: soc for 3.18 #2

On 26/09/2014 12:50, Arnd Bergmann :
> On Monday 22 September 2014, Nicolas Ferre wrote:
> 
>> Nicolas Ferre (4):
>>       ARM: at91: introduce basic SAMA5D4 support
>>       ARM: at91: SAMA5D4 SoC detection code and low level routines
> 
> This resulted in build failures both in at91x40_defconfig and some
> randconfigs with MMU disabled. I've applied the patch below on top
> to fix it.

Ok, I see: sorry for the inconvenience.
What about taking the patch that I sent about removing completely the
at91x40 as it is "Acked" by everybody now? The would prevent from adding
these unneeded values.

> I'm not exactly happy about the soc detection code anyway after I
> had to look at that. Why do you even hardcode the physical register
> location rather than getting it from DT?
>
> Also, why do you care about which SoC version you have for the
> modern SAMA5 chips? All I see is a sama5d4_map_io() callback
> that maps a lot of completely unused registers along with
> the uart that you normally get from the implicit debug_ll_io_init,
> and the SRAM that should probably be turned into a normal driver.

Yes, as said by Alexandre, we are aware of the flaws of AT91 SoC
initialization, but last time I tried, our code was called too early.
Now with the work from Maxime with the timer (in 3.18) it might be
possible to reorder all this.
But please, I would really like to remove all !DT *and* !CCF material
before starting this work, otherwise we will again have a double path
for sam9's and I'd like to avoid this.

Your thoughts?

Bye,

> 8<-------
>>>From 45aeea29c360551519edd8e041b36d8a4d5f6a23 Mon Sep 17 00:00:00 2001
> From: Arnd Bergmann <arnd@...db.de>
> Date: Fri, 26 Sep 2014 12:27:00 +0200
> Subject: [PATCH] ARM: at91: fix nommu build regression
> 
> The newly introduced support for SAMA5D4 added access to the
> 'AT91_ALT_BASE_SYS' register area, but failed to define the
> symbols in the case when CONFIG_MMU is disabled.
> 
> We really should not hardwire addresses like this any more,
> but as a small fixup, this patch just adds the missing
> definitions for the nommu case, which gets at91x40_defconfig
> and any configuration of sam9 and sama5 with MMU disabled
> back to work.
> 
> Signed-off-by: Arnd Bergmann <arnd@...db.de>
> Fixes: 726d32bf79ef4 ("ARM: at91: SAMA5D4 SoC detection code and low ...")
> 
> diff --git a/arch/arm/mach-at91/include/mach/hardware.h b/arch/arm/mach-at91/include/mach/hardware.h
> index d84776f6b8ac..c13797352688 100644
> --- a/arch/arm/mach-at91/include/mach/hardware.h
> +++ b/arch/arm/mach-at91/include/mach/hardware.h
> @@ -51,11 +51,12 @@
>   */
>  #define AT91_BASE_SYS	0xffffc000
>  
> +#endif
> +
>  /*
>   * On sama5d4 there is no system controller, we map some needed peripherals
>   */
>  #define AT91_ALT_BASE_SYS	0xfc069000
> -#endif
>  
>  /*
>   * On all at91 have the Advanced Interrupt Controller starts at address
> @@ -90,6 +91,9 @@
>   */
>  #define AT91_IO_PHYS_BASE	AT91_BASE_SYS
>  #define AT91_IO_VIRT_BASE	IOMEM(AT91_IO_PHYS_BASE)
> +
> +#define AT91_ALT_IO_PHYS_BASE	AT91_ALT_BASE_SYS
> +#define AT91_ALT_IO_VIRT_BASE	IOMEM(AT91_ALT_BASE_SYS)
>  #endif
>  
>  #define AT91_IO_SIZE		(0xFFFFFFFF - AT91_IO_PHYS_BASE + 1)
> 
> 


-- 
Nicolas Ferre
--
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/