From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S935156AbbCPSz4 (ORCPT <rfc822;w@1wt.eu>);
	Mon, 16 Mar 2015 14:55:56 -0400
Received: from mail-pd0-f169.google.com ([209.85.192.169]:33177 "EHLO
	mail-pd0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S932812AbbCPSzy (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 16 Mar 2015 14:55:54 -0400
Message-ID: <55072714.9080104@gmail.com>
Date: Mon, 16 Mar 2015 11:55:16 -0700
From: Florian Fainelli <f.fainelli@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Brian Norris <computersforpeace@gmail.com>, linux-mtd@lists.infradead.org
CC: Dmitry Torokhov <dtor@google.com>, Anatol Pomazao <anatol@google.com>,
        Ray Jui <rjui@broadcom.com>, Corneliu Doban <cdoban@broadcom.com>,
        Jonathan Richardson <jonathar@broadcom.com>,
        =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= <zajec5@gmail.com>,
        bcm-kernel-feedback-list@broadcom.com, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org, Kevin Cernekee <cernekee@gmail.com>
Subject: Re: [PATCH 3/3] mtd: nand: add NAND driver for Broadcom STB NAND
 controller
References: <1425691129-1150-1-git-send-email-computersforpeace@gmail.com> <1425691129-1150-4-git-send-email-computersforpeace@gmail.com>
In-Reply-To: <1425691129-1150-4-git-send-email-computersforpeace@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 06/03/15 17:18, Brian Norris wrote:
> This core originated in Set-Top Box chips (BCM7xxx) but is used in a
> variety of other Broadcom chips, including some BCM63xxx, BCM33xx, and
> iProc/Cygnus. It's been used only on ARM and MIPS SoCs, so restrict it
> to those architectures.
> 
> There are multiple revisions of this core throughout the years, and
> almost every version broke register compatibility in some small way, but
> with some effort, this driver is able to support v4.0, v5.0, v6.x, v7.0,
> and v7.1. It's been tested on v5.0, v6.0, v7.0, and v7.1 recently, so
> there hopefully are no more lurking inconsistencies.
> 
> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
> ---

Looks good to me, just one nitpick below:

[snip]

> +static int brcmnand_revision_init(struct brcmnand_controller *ctrl)
> +{
> +	static const unsigned int block_sizes_v6[] = { 8, 16, 128, 256, 512, 1024, 2048, 0 };
> +	static const unsigned int block_sizes_v4[] = { 16, 128, 8, 512, 256, 1024, 2048, 0 };
> +	static const unsigned int page_sizes[] = { 512, 2048, 4096, 8192, 0 };
> +
> +	ctrl->nand_version = nand_readreg(ctrl, 0) & 0xffff;
> +
> +	/* Only support v4.0+? */
> +	if (ctrl->nand_version < 0x0400)
> +		return -ENODEV;

It could be nice to have an informative error message here that this is
either:

- an unknown controller revision (> 7.1)
- an older controller revision
- a check against the compatible property, just in case?

[snip]

> +		ctrl->cs_offsets = brcmnand_cs_offsets_v71;
> +	} else {
> +		ctrl->cs_offsets = brcmnand_cs_offsets;
> +
> +		/* pre-v5.0 has a different CS0 offset layout */
> +		if (ctrl->nand_version <= 0x0500)
> +			ctrl->cs0_offsets = brcmnand_cs_offsets_cs0;

Based on this check, should the comment should be "pre-v5.0 and v5.0
have a different CS0 offset layout"?
-- 
Florian