Re: [PATCH v5 3/4] mtd: nand: jz4780: driver for NAND devices on JZ4780 SoCs

[Ezequiel Garcia]

Brian,

On 9 September 2015 at 11:24, Ezequiel Garcia
<ezequiel@xxxxxxxxxxxxxxxxxxxx> wrote:
> On 08 Sep 10:10 AM, Alex Smith wrote:
>> Add a driver for NAND devices connected to the NEMC on JZ4780 SoCs, as
>> well as the hardware BCH controller. DMA is not currently implemented.
>>
>> While older 47xx SoCs also have a BCH controller, they are incompatible
>> with the one in the 4780 due to differing register/bit positions, which
>> would make implementing a common driver for them quite messy.
>>
>> Signed-off-by: Alex Smith <alex.smith@xxxxxxxxxx>
>> Cc: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@xxxxxxxxxx>
>> Cc: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
>> Cc: Brian Norris <computersforpeace@xxxxxxxxx>
>> Cc: linux-mtd@xxxxxxxxxxxxxxxxxxx
>> Cc: linux-kernel@xxxxxxxxxxxxxxx
>> ---
>> v4 -> v5:
>>  - Bump RB_DELAY up to be sufficient for the driver to work without a
>>    busy GPIO available.
>>  - Use readl_poll_timeout instead of custom polling loop.
>>  - Remove useless printks.
>>  - Change a BUG_ON to WARN_ON.
>>  - Remove use of of_translate_address(), use standard platform resource
>>    APIs.
>>  - Add DRV_NAME define to avoid duplication of the same string.
>>
>> v3 -> v4:
>>  - Rebase to 4.2-rc4
>>  - Change ECC_HW_OOB_FIRST to ECC_HW, reading OOB first is not necessary.
>>  - Fix argument to get_device() in jz4780_bch_get()
>>
>> v2 -> v3:
>>  - Rebase to 4.0-rc6
>>  - Reflect binding changes
>>  - get/put_device in bch get/release
>>  - Removed empty .remove() callback
>>  - Removed .owner
>>  - Set mtd->dev.parent
>>
>> v1 -> v2:
>>  - Fixed module license macro
>>  - Rebase to 4.0-rc3
>> ---
>>  drivers/mtd/nand/Kconfig       |   7 +
>>  drivers/mtd/nand/Makefile      |   1 +
>>  drivers/mtd/nand/jz4780_bch.c  | 348 +++++++++++++++++++++++++++++++++++++
>>  drivers/mtd/nand/jz4780_bch.h  |  42 +++++
>>  drivers/mtd/nand/jz4780_nand.c | 378 +++++++++++++++++++++++++++++++++++++++++
>>  5 files changed, 776 insertions(+)
>>  create mode 100644 drivers/mtd/nand/jz4780_bch.c
>>  create mode 100644 drivers/mtd/nand/jz4780_bch.h
>>  create mode 100644 drivers/mtd/nand/jz4780_nand.c
>>
> [..]
>> +
>> +static int jz4780_nand_init_chips(struct jz4780_nand *nand,
>> +                               struct platform_device *pdev)
>> +{
>> +     struct device *dev = &pdev->dev;
>> +     struct jz4780_nand_chip *chip;
>> +     const __be32 *prop;
>> +     struct resource *res;
>> +     int i = 0;
>> +
>> +     /*
>> +      * Iterate over each bank assigned to this device and request resources.
>> +      * The bank numbers may not be consecutive, but nand_scan_ident()
>> +      * expects chip numbers to be, so fill out a consecutive array of chips
>> +      * which map chip number to actual bank number.
>> +      */
>> +     while ((prop = of_get_address(dev->of_node, i, NULL, NULL))) {
>> +             chip = &nand->chips[i];
>> +             chip->bank = of_read_number(prop, 1);
>> +
>> +             jz4780_nemc_set_type(nand->dev, chip->bank,
>> +                                  JZ4780_NEMC_BANK_NAND);
>> +
>> +             res = platform_get_resource(pdev, IORESOURCE_MEM, i);
>> +             chip->base = devm_ioremap_resource(dev, res);
>> +             if (IS_ERR(chip->base)) {
>> +                     dev_err(dev, "failed to map bank %u: %ld\n",
>> +                             chip->bank, PTR_ERR(chip->base));
>
> You don't need to print anything on devm_ioremap_resource errors.
>
> The rest looks good:
>
> Reviewed-by: Ezequiel Garcia <ezequiel@xxxxxxxxxxxxxxxxxxxx>

Whatever the outcome of the discussion on patch 1/4
"mtd: nand: increase ready wait timeout and report timeouts"
is, the jz4780-specific patches should remain unaffected to it.

In fact, I believe patch 1/4 shouldn't even be on the same series.
So, maybe you can consider taking the rest (or not) independently
of that patch?
-- 
Ezequiel GarcÃa, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/