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
| ||
|
Date: Tue, 27 Jan 2015 17:53:59 +0000 From: Russell King - ARM Linux <linux@....linux.org.uk> To: Nicolas Pitre <nicolas.pitre@...aro.org> Cc: Pavel Machek <pavel@....cz>, Tony Lindgren <tony@...mide.com>, Pali Rohár <pali.rohar@...il.com>, linux-omap <linux-omap@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Aaro Koskinen <aaro.koskinen@....fi>, Sebastian Reichel <sre@...nel.org>, Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>, linux-arm-kernel@...ts.infradead.org, Laura Abbott <lauraa@...eaurora.org> Subject: Re: N900 v3.19-rc5 arm atags_to_fdt.c is broken On Tue, Jan 27, 2015 at 10:16:24AM -0500, Nicolas Pitre wrote: > On Tue, 27 Jan 2015, Pavel Machek wrote: > > (Note, that in 3.19 dts for n900 got too big, so we are actually > > triggering old bugs. That means that this is a regression fix, and > > should go in ASAP). > > It is queued here: > http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8294/1 Irrespective of that patch, I commented on another thread (about adding the serial number to DT): | How about something a little more radical. | | Rather than trying to squeeze various ATAGs into DT, why don't we add a | standard ATAG to contain the DT and pass that through into the kernel. | This is IMHO how we _should_ have done the ATAG compatibility from the | start. | | That means we could get rid of most of the libfdt in the decompressor, | and instead resolve the differences in the kernel. That would allow us to get rid of all the FDT compatibility code in the decompressor, and when we encounter these special ATAGs, we can deal with them in the kernel instead of having to mess around with the DT. I'd also assume (although I haven't checked) that it would be much easier to add additional DT properties in the kernel environment, rather than in the rather restrictive decompressor environment. We'd need to be careful about how we deal with the atags vs DT. I'd suggest (as above) that we have a tag which points at the DT in physical memory, and its size, and pre-scan the atag list for that. When we find it, we kick off the DT based stuff as we would normally do, and follow it with a parse of the atags. This would cause the atags to override whatever is in the DT, which afaics is the behaviour that we actually want. We could augment that with code to update DT too so that we can export just the DT based information to kexec'd kernels. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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/
Powered by blists - more mailing lists