linux-kernel - Re: [PATCH] ARM: zynq: Set bit 22 in PL310 AuxCtrl register (6395/1)

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:	Tue, 12 May 2015 14:42:02 +0200
From:	Thomas.Betker@...de-schwarz.com
To:	michal.simek@...inx.com
Cc:	Dirk Behme <dirk.behme@...bosch.com>,
	Josh Cartwright <josh.cartwright@...com>,
	Russell King <linux@....linux.org.uk>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	monstr@...str.eu, Peter Crosthwaite <peter.crosthwaite@...inx.com>,
	Sören Brinkmann <soren.brinkmann@...inx.com>,
	Steffen Trumtrar <s.trumtrar@...gutronix.de>
Subject: Re: [PATCH] ARM: zynq: Set bit 22 in PL310 AuxCtrl register
 (6395/1)

> >> This patch is based on the
> >> commit 1a8e41cd672f ("ARM: 6395/1: VExpress: Set bit 22 in the PL310
> >> (cache controller) AuxCtlr register")
> > 
> > 
> > I've been under the impression that this shouldn't be done in the
> > kernel, but in the boot loader/firmware:
> > 
> > https://lkml.org/lkml/2015/2/20/199
> > 
> > http://lists.denx.de/pipermail/u-boot/2015-March/207803.html
> 
> Tegra, Exynos, sti still have this bit set.

In 4.1-rc3, the bit is set by berlin, exynos, nomadik, omap2, sti, tegra, 
vexpress.

> Does that mean that they should be just removed because fix should be in
> bootloader?
> 
> Anyway it is normal that bootloader stay on system untouched and only OS
> is updated. But OK - let's make this in bootloader if this is preferred
> solution.

So the plan is to update each and every Zynq bootloader for a problem we 
have encountered in Linux (in our case, a problem we have been hunting for 
months)? My u-boot doesn't even use the cache; it's disabled until the 
kernel boots.

I do understand that the kernel should not overwrite hardwired settings 
such as cache size, but shouldn't we at least allow to fix things that 
definitely need to be fixed?

Best regards,
Thomas Betker
--
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/