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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 29 Sep 2014 10:52:50 +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 20:55, Arnd Bergmann :
> On Friday 26 September 2014 16:47:12 Nicolas Ferre wrote:
>> 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 thought about that, but it would still be broken in randconfig builds
> that turn off the MMU on any of the other at91 variants, as I wrote above.

Okay, sorry, I overlooked this part.

> at91 is actually one of the platforms that I'd assume would even work in
> that configuration. We should at one point in the future discuss more
> widely whether we try to fix more of the bugs one hits with this or
> we just outright prevent users from turning off the MMU on platforms
> that have one.

Well, for the moment, it still makes sense to keep this possibility. So
your patch is perfectly fine for me, if needed:

Acked-by: Nicolas Ferre <nicolas.ferre@...el.com>

Bye,

>>> 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.
> 
> I'm not complaining about the use of the early registers on sam9, I know
> you are working hard on cleaning that up. I still don't see why you
> duplicate it for sama5, but it's ok as long as you have a plan.
> 
> 	Arnd
> 


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