| 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
| ||
|
Message-Id: <1549202213.1950.1@crapouillou.net>
Date: Sun, 03 Feb 2019 10:56:53 -0300
From: Paul Cercueil <paul@...pouillou.net>
To: Boris Brezillon <bbrezillon@...nel.org>
Cc: David Woodhouse <dwmw2@...radead.org>,
Brian Norris <computersforpeace@...il.com>,
Marek Vasut <marek.vasut@...il.com>,
Richard Weinberger <richard@....at>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Miquel Raynal <miquel.raynal@...tlin.com>,
Harvey Hunt <harveyhuntnexus@...il.com>,
Mathieu Malaterre <malat@...ian.org>,
linux-mtd@...ts.infradead.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 4/9] mtd: rawnand: jz4780: Add support for the JZ4740
Le dim. 3 févr. 2019 à 4:31, Boris Brezillon <bbrezillon@...nel.org>
a écrit :
> On Sat, 2 Feb 2019 20:19:21 -0300
> Paul Cercueil <paul@...pouillou.net> wrote:
>
>> Add support for probing the jz4780-nand driver on the JZ4740 SoC
>> from
>> Ingenic.
>>
>> Signed-off-by: Paul Cercueil <paul@...pouillou.net>
>> ---
>>
>> Changes:
>>
>> v2: - Add support for the JZ4740 and not the JZ4725B: they behave
>> the
>> same, and JZ4740 is fully upstream while JZ4725B is not. The
>> JZ4725B devicetree will then simply use the
>> "ingenic,jz4740-nand"
>> compatible string.
>> - Fix the number of bytes for the ECC when the ECC strength is
>> 4.
>> This is needed for the JZ4740, which uses Reed-Solomon
>> instead of
>> BCH.
>>
>> drivers/mtd/nand/raw/ingenic/jz4780_nand.c | 48
>> +++++++++++++++++-----
>
> If we're going to make the driver compatible with jz4740 and jz4725b
> maybe we should rename the source files jz47xx_{nand,bch}.{c,h}.
I don't know about that. Adding support for new hardware isn't a good
reason to
rename the driver, or so I've been told around here, as you then make
it harder
to review the git history of the driver.
>> 1 file changed, 37 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/mtd/nand/raw/ingenic/jz4780_nand.c
>> b/drivers/mtd/nand/raw/ingenic/jz4780_nand.c
>> index 7f55358b860f..c0855fef7735 100644
>> --- a/drivers/mtd/nand/raw/ingenic/jz4780_nand.c
>> +++ b/drivers/mtd/nand/raw/ingenic/jz4780_nand.c
>> @@ -13,6 +13,7 @@
>> #include <linux/module.h>
>> #include <linux/of.h>
>> #include <linux/of_address.h>
>> +#include <linux/of_device.h>
>> #include <linux/gpio/consumer.h>
>> #include <linux/platform_device.h>
>> #include <linux/slab.h>
>> @@ -26,13 +27,15 @@
>>
>> #define DRV_NAME "jz4780-nand"
>>
>> -#define OFFSET_DATA 0x00000000
>> -#define OFFSET_CMD 0x00400000
>> -#define OFFSET_ADDR 0x00800000
>> -
>> /* Command delay when there is no R/B pin. */
>> #define RB_DELAY_US 100
>>
>> +struct jz_soc_info {
>> + unsigned long data_offset;
>> + unsigned long addr_offset;
>> + unsigned long cmd_offset;
>> +};
>> +
>> struct jz4780_nand_cs {
>> unsigned int bank;
>> void __iomem *base;
>> @@ -40,6 +43,7 @@ struct jz4780_nand_cs {
>>
>> struct jz4780_nand_controller {
>> struct device *dev;
>> + const struct jz_soc_info *soc_info;
>> struct jz4780_bch *bch;
>> struct nand_controller controller;
>> unsigned int num_banks;
>> @@ -101,9 +105,9 @@ static void jz4780_nand_cmd_ctrl(struct
>> nand_chip *chip, int cmd,
>> return;
>>
>> if (ctrl & NAND_ALE)
>> - writeb(cmd, cs->base + OFFSET_ADDR);
>> + writeb(cmd, cs->base + nfc->soc_info->addr_offset);
>> else if (ctrl & NAND_CLE)
>> - writeb(cmd, cs->base + OFFSET_CMD);
>> + writeb(cmd, cs->base + nfc->soc_info->cmd_offset);
>> }
>>
>> static int jz4780_nand_dev_ready(struct nand_chip *chip)
>> @@ -161,8 +165,13 @@ static int jz4780_nand_attach_chip(struct
>> nand_chip *chip)
>> struct jz4780_nand_controller *nfc =
>> to_jz4780_nand_controller(chip->controller);
>> int eccbytes;
>>
>> - chip->ecc.bytes = fls((1 + 8) * chip->ecc.size) *
>> - (chip->ecc.strength / 8);
>> + if (chip->ecc.strength == 4) {
>> + /* JZ4740 uses 9 bytes of ECC to correct maximum 4 errors */
>> + chip->ecc.bytes = 9;
>> + } else {
>> + chip->ecc.bytes = fls((1 + 8) * chip->ecc.size) *
>> + (chip->ecc.strength / 8);
>> + }
>>
>> switch (chip->ecc.mode) {
>> case NAND_ECC_HW:
>> @@ -272,8 +281,8 @@ static int jz4780_nand_init_chip(struct
>> platform_device *pdev,
>> return -ENOMEM;
>> mtd->dev.parent = dev;
>>
>> - chip->legacy.IO_ADDR_R = cs->base + OFFSET_DATA;
>> - chip->legacy.IO_ADDR_W = cs->base + OFFSET_DATA;
>> + chip->legacy.IO_ADDR_R = cs->base + nfc->soc_info->data_offset;
>> + chip->legacy.IO_ADDR_W = cs->base + nfc->soc_info->data_offset;
>> chip->legacy.chip_delay = RB_DELAY_US;
>> chip->options = NAND_NO_SUBPAGE_WRITE;
>> chip->legacy.select_chip = jz4780_nand_select_chip;
>> @@ -353,6 +362,10 @@ static int jz4780_nand_probe(struct
>> platform_device *pdev)
>> if (!nfc)
>> return -ENOMEM;
>>
>> + nfc->soc_info = device_get_match_data(dev);
>> + if (!nfc->soc_info)
>> + return -EINVAL;
>> +
>> /*
>> * Check for BCH HW before we call nand_scan_ident, to prevent us
>> from
>> * having to call it again if the BCH driver returns
>> -EPROBE_DEFER.
>> @@ -390,8 +403,21 @@ static int jz4780_nand_remove(struct
>> platform_device *pdev)
>> return 0;
>> }
>>
>> +static const struct jz_soc_info jz4740_soc_info = {
>> + .data_offset = 0x00000000,
>> + .cmd_offset = 0x00008000,
>> + .addr_offset = 0x00010000,
>> +};
>> +
>> +static const struct jz_soc_info jz4780_soc_info = {
>> + .data_offset = 0x00000000,
>> + .cmd_offset = 0x00400000,
>> + .addr_offset = 0x00800000,
>> +};
>> +
>> static const struct of_device_id jz4780_nand_dt_match[] = {
>> - { .compatible = "ingenic,jz4780-nand" },
>> + { .compatible = "ingenic,jz4740-nand", .data = &jz4740_soc_info },
>> + { .compatible = "ingenic,jz4780-nand", .data = &jz4780_soc_info
>> },
>> {},
>> };
>> MODULE_DEVICE_TABLE(of, jz4780_nand_dt_match);
>
Powered by blists - more mailing lists