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: <fcb600af-88dc-55a7-917e-4cf4673c2973@foss.st.com> Date: Mon, 27 Mar 2023 10:02:13 +0200 From: Christophe Kerello <christophe.kerello@...s.st.com> To: Miquel Raynal <miquel.raynal@...tlin.com> CC: <richard@....at>, <vigneshr@...com>, <linux-mtd@...ts.infradead.org>, <linux-kernel@...r.kernel.org>, <linux-stm32@...md-mailman.stormreply.com> Subject: Re: [PATCH] mtd: rawnand: stm32_fmc2: do not support EDO mode Hello Miquel, On 3/24/23 17:34, Christophe Kerello wrote: > Hello Miquel, > > On 3/24/23 17:25, Miquel Raynal wrote: >> Hi Christophe, >> >> christophe.kerello@...s.st.com wrote on Fri, 24 Mar 2023 17:09:18 +0100: >> >>> FMC2 controller does not support EDO mode (timings mode 4 and 5). >>> >>> Signed-off-by: Christophe Kerello <christophe.kerello@...s.st.com> >>> Fixes: 2cd457f328c1 ("mtd: rawnand: stm32_fmc2: add STM32 FMC2 NAND >>> flash controller driver") >>> --- >>> drivers/mtd/nand/raw/stm32_fmc2_nand.c | 3 +++ >>> 1 file changed, 3 insertions(+) >>> >>> diff --git a/drivers/mtd/nand/raw/stm32_fmc2_nand.c >>> b/drivers/mtd/nand/raw/stm32_fmc2_nand.c >>> index 5d627048c420..3abb63d00a0b 100644 >>> --- a/drivers/mtd/nand/raw/stm32_fmc2_nand.c >>> +++ b/drivers/mtd/nand/raw/stm32_fmc2_nand.c >>> @@ -1531,6 +1531,9 @@ static int >>> stm32_fmc2_nfc_setup_interface(struct nand_chip *chip, int chipnr, >>> if (IS_ERR(sdrt)) >>> return PTR_ERR(sdrt); >>> + if (sdrt->tRC_min < 30000) >> >> When introducing NV-DDR support we as well added a timings.mode field, >> perhaps you could use it? > > Yes, I can use it. It will be done in V2. > > Regards, > Christophe Kerello. > I had a look at Kernel LTS, and timings.mode was introduced on Kernel LTS 5.10. As this patch has also to be applied on Kernel LTS 5.4, my proposal is to send a new patch set. The first patch will be the current patch (fix for all Kernel LTS) and the second patch will use timings.mode instead of checking tRC_min timings for next Kernel delivery. Is this proposal acceptable? Regards, Christophe Kerello. >> >>> + return -EOPNOTSUPP; >>> + >>> if (chipnr == NAND_DATA_IFACE_CHECK_ONLY) >>> return 0; >> >> >> Thanks, >> Miquèl
Powered by blists - more mailing lists