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  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, 6 Oct 2015 13:28:38 +0300
From:	Roger Quadros <>
To:	Tony Lindgren <>
CC:	<>, <>,
	<>, <>,
	<>, <>,
	<>, <>,
	<>, <>
Subject: Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND
 on non-OMAP platforms

On 06/10/15 13:05, Roger Quadros wrote:
> On 06/10/15 13:00, Tony Lindgren wrote:
>> * Roger Quadros <> [151006 02:59]:
>>> On 06/10/15 11:33, Tony Lindgren wrote:
>>>> Does build and boot and use NAND work throughtout the series?
>>>> Otherwise we'll have hard time bisecting anything..
>>> Yes it does with the following exceptions.
>>> - Patch 7 "memory: omap-gpmc: Remove NAND IRQ code" breaks prefetch-irq mode
>>> but none of the boards seem to be using it so it shouldn't break NAND on existing boards.
>>> At patch 9 "mtd: nand: omap2: manage NAND interrupts" prefetch-irq mode is working again.
>>> Do you want me to squash patches 7,8,9 so that pre-fetch irq is not broken at any point?
>> OK, no that's fine, no need to squash them together then.
>>> - Then at patch 11 "mtd: nand: omap: Clean up device tree support" we break NAND on all DT
>>> boards as we expect NAND to be a real child node with compatible id. Simply applying the
>>> DT patch at this point makes it work again.
>> Hmm can we at least warn about incompatible DT entry when somebody boots
>> with an older dtb?
> Yes that could be done. It looks like we can use the missing compatible property to identify
> that it is and old DT entry.
> I'll send a v4 of patch 11.

There is another issue. Some of the old DT nodes set the NAND IO address to 0.
As we prevent mapping into first 16MB we see the following message for those nodes. e.g. dra7-evm

[    1.727598] omap-gpmc 50000000.gpmc: cannot remap GPMC CS 0 to 0x00000000
[    1.727605] omap-gpmc 50000000.gpmc: GPMC CS 0 start cannot be lesser than 0x1000000
[    1.727611] omap-gpmc 50000000.gpmc: failed to probe DT children

Hope this is good enough information that DT needs to be updated?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists