linux-kernel - Re: [PATCH for 3.0] AT91: Change nand buswidth logic to match hardware default configuration

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:	Mon, 4 Jul 2011 16:25:25 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	linux-arm-kernel@...ts.infradead.org
Cc:	Nicolas Ferre <nicolas.ferre@...el.com>, patrice.vilchez@...el.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH for 3.0] AT91: Change nand buswidth logic to match hardware default configuration

On Monday 04 July 2011, Nicolas Ferre wrote:
> Le 01/07/2011 12:25, Nicolas Ferre :
> > The recently modified nand buswitth configuration is not aligned with
> > board reality: the double footprint on boards is always populated with 8bits
> > buswidth nand flashes.
> > So we have to consider that without particular configuration the 8bits
> > buswidth is selected by default.
> > Moreover, the previous logic was always using !board_have_nand_8bit(), we
> > change it to a simpler: board_have_nand_16bit().
> > 
> > Signed-off-by: Nicolas Ferre <nicolas.ferre@...el.com>
> > Tested-by: Ludovic Desroches <ludovic.desroches@...el.com>
> 
> Arnd,
> 
> Can you please handle this parch for 3.0-final as a bug fix through the
> arm-soc.git tree?
> 
> You can queue it in addition of the pull request sent by
> Jean-Christophe: "AT91: Fix pull requset".

Ok, I've integrated it in the branch and will send the pull request.

My preference would be to see fixes this late in the cycle more
minmal. This patch does two things: 1. change the polarity of the
system_rev bit as a bug fix and 2. change the polarity of the
function reading it as a cleanup. Both changes look absolutely
ok, but it's better to do the cleanup for the next kernel.

In this case, studying the patch more closely shows that it's
very harmless, but I'd rather not have to look that closely.

Am I correct that the bug is a regression against 2.6.39?

	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/