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] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 26 Sep 2014 20:55:34 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Nicolas Ferre <nicolas.ferre@...el.com>
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 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.

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.

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