linux-kernel - Re: [PATCH 3/3] mtd: nand: add NAND driver for Broadcom STB NAND controller

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]

Message-ID: <20150309174905.GU18140@ld-irv-0074>
Date:	Mon, 9 Mar 2015 10:49:05 -0700
From:	Brian Norris <computersforpeace@...il.com>
To:	Rafał Miłecki <zajec5@...il.com>
Cc:	"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
	Dmitry Torokhov <dtor@...gle.com>,
	Anatol Pomazao <anatol@...gle.com>,
	Ray Jui <rjui@...adcom.com>,
	Corneliu Doban <cdoban@...adcom.com>,
	Jonathan Richardson <jonathar@...adcom.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	bcm-kernel-feedback-list@...adcom.com,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Kevin Cernekee <cernekee@...il.com>,
	Hauke Mehrtens <hauke@...ke-m.de>, sbranden@...adcom.com
Subject: Re: [PATCH 3/3] mtd: nand: add NAND driver for Broadcom STB NAND
 controller

On Sun, Mar 08, 2015 at 01:44:02AM +0100, Rafał Miłecki wrote:
> On 7 March 2015 at 18:39, Rafał Miłecki <zajec5@...il.com> wrote:
> > It seems that brcmnand_ctlrdy_irq never fires on my device. Just like
> > controller was never generating any IRQ.
> >
> >
> > I started comparing your driver with OpenWrt's bcm_nand.c (which
> > should be very similar to Broadcom's SDK NAND driver for ARM). Below
> > are few things I've noticed.
> >
> > 1) In bcm_nand.c IRQ handler also doesn't seem to be fired (or very rarely).
> 
> Oh, wait, I was wrong there. So in bcm_nand.c IRQ handler fires very
> often, just not during the early phase (RESET, READID), when we don't
> use IRQs. During standard read/program/etc IRQ is commonly used.
> 
> So maybe all we're missing in case of brcmstb_nand.c is
> enabling/acking/disabling IRQ?

Yes, that's likely the main problem.

> It seem that my controller 6.01 has:
> 
> 1) Following IRQs:
> DIREC_READ_MISS
> ERASE_COMPLETE
> COPYBACK_COMPLETE
> PROGRAM_COMPLETE
> CONTROLLER_RDY
> RDBSY_RDY
> ECC_UNCORRECTABLE
> ECC_CORRECTABLE

Right, that's the standard set of NAND interrupts. This driver only uses
CONTROLLER_RDY, BTW.

> 2) Registers for reading/acking above IRQs:
> 0xf00 DIREC_READ_MISS
> 0xf04 ERASE_COMPLETE
> 0xf08 COPYBACK_COMPLETE
> 0xf0c PROGRAM_COMPLETE
> 0xf10 CONTROLLER_RDY
> 0xf14 RDBSY_RDY
> 0xf18 ECC_UNCORRECTABLE
> 0xf1c ECC_CORRECTABLE
> (if 0x1 is set, it means IRQ was raised, writing 0x1 ack-es it)
> 
> 3) Register 0x408 for enabling/disabling IRQs:
> 0x00000004 DIREC_READ_MISS
> 0x00000008 ERASE_COMPLETE
> 0x00000010 COPYBACK_COMPLETE
> 0x00000020 PROGRAM_COMPLETE
> 0x00000040 CONTROLLER_RDY
> 0x00000080 RDBSY_RDY
> 0x00000100 ECC_UNCORRECTABLE
> 0x00000200 ECC_CORRECTABLE

(2) and (3) look pretty similar to the Cygnus chips. We should probably
end up using the same solution for both. Several related to the Cygnus
project are on CC.

One problem for Cygnus is that some of the other bits in their register
0x408 deal with non-interrupt-related functionality (endianness and
clocks), so it might not make the cleanest design to handle this with an
irqchip driver.

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