linux-kernel - Re: [PATCH v4 2/5] mtd: nand: Qualcomm NAND controller driver

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: <55F57D42.10802@codeaurora.org>
Date:	Sun, 13 Sep 2015 19:12:26 +0530
From:	Archit Taneja <architt@...eaurora.org>
To:	linux-mtd@...ts.infradead.org, computersforpeace@...il.com
Cc:	Stephen Boyd <sboyd@...eaurora.org>, dehrenberg@...gle.com,
	cernekee@...il.com, linux-arm-msm@...r.kernel.org,
	agross@...eaurora.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 2/5] mtd: nand: Qualcomm NAND controller driver


On 8/27/2015 5:07 AM, Stephen Boyd wrote:
> On 08/19, Archit Taneja wrote:
>> The Qualcomm NAND controller is found in SoCs like IPQ806x, MSM7xx,
>> MDM9x15 series.
>>
>> It exists as a sub block inside the IPs EBI2 (External Bus Interface 2)
>> and QPIC (Qualcomm Parallel Interface Controller). These IPs provide a
>> broader interface for external slow peripheral devices such as LCD and
>> NAND/NOR flash memory or SRAM like interfaces.
>>
>> We add support for the NAND controller found within EBI2. For the SoCs
>> of our interest, we only use the NAND controller within EBI2. Therefore,
>> it's safe for us to assume that the NAND controller is a standalone block
>> within the SoC.
>>
>> The controller supports 512B, 2kB, 4kB and 8kB page 8-bit and 16-bit NAND
>> flash devices. It contains a HW ECC block that supports BCH ECC (4, 8 and
>> 16 bit correction/step) and RS ECC(4 bit correction/step) that covers main
>> and spare data. The controller contains an internal 512 byte page buffer
>> to which we read/write via DMA. The EBI2 type NAND controller uses ADM DMA
>> for register read/write and data transfers. The controller performs page
>> reads and writes at a codeword/step level of 512 bytes. It can support up
>> to 2 external chips of different configurations.
>>
>> The driver prepares register read and write configuration descriptors for
>> each codeword, followed by data descriptors to read or write data from the
>> controller's internal buffer. It uses a single ADM DMA channel that we get
>> via dmaengine API. The controller requires 2 ADM CRCIs for command and
>> data flow control. These are passed via DT.
>>
>> The ecc layout used by the controller is syndrome like, but we can't use
>> the standard syndrome ecc ops because of several reasons. First, the amount
>> of data bytes covered by ecc isn't same in each step. Second, writing to
>> free oob space requires us writing to the entire step in which the oob
>> lies. This forces us to create our own ecc ops.
>>
>> One more difference is how the controller accesses the bad block marker.
>> The controller ignores reading the marker when ECC is enabled. ECC needs
>> to be explicity disabled to read or write to the bad block marker. For
>> this reason, we use the newly created flag NAND_BBT_ACCESS_BBM_RAW to
>> read the factory provided bad block markers.
>>
>> v4:
>> - Shrink submit_descs
>> - add desc list node at the end of dma_prep_desc
>> - Endianness and warning fixes
>>
>> Signed-off-by: Stephen Boyd <sboyd@...eaurora.org>
>>
>> v3:
>> - Refactor dma functions for maximum reuse
>> - Use dma_slave_confing on stack
>> - optimize and clean upempty_page_fixup using memchr_inv
>> - ensure portability with dma register reads using le32_* funcs
>> - use NAND_USE_BOUNCE_BUFFER instead of doing it ourselves
>> - fix handling of return values of dmaengine funcs
>> - constify wherever possible
>> - Remove dependency on ADM DMA in Kconfig
>> - Misc fixes and clean ups
>>
>> v2:
>> - Use new BBT flag that allows us to read BBM in raw mode
>> - reduce memcpy-s in the driver
>> - some refactor and clean ups because of above changes
>>
>> Reviewed-by: Andy Gross <agross@...eaurora.org>
>> Signed-off-by: Archit Taneja <architt@...eaurora.org>
>> ---
>
> Reviewed-by: Stephen Boyd <sboyd@...eaurora.org>
>

Can someone from the the linux-mtd community review this?

Thanks,
Archit

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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/