linux-kernel - Re: [PATCH v5] mtd: rawnand: brcmnand: legacy exec

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] [day] [month] [year] [list]

Message-ID: <871psb1zte.fsf@bootlin.com>
Date: Mon, 26 May 2025 11:33:33 +0200
From: Miquel Raynal <miquel.raynal@...tlin.com>
To: Álvaro Fernández Rojas <noltari@...il.com>
Cc: linux-mtd@...ts.infradead.org,  dregan@...adcom.com,
  bcm-kernel-feedback-list@...adcom.com,  florian.fainelli@...adcom.com,
  rafal@...ecki.pl,  computersforpeace@...il.com,  kamal.dasu@...adcom.com,
  dan.beygelman@...adcom.com,  william.zhang@...adcom.com,
  frieder.schrempf@...tron.de,  linux-kernel@...r.kernel.org,
  vigneshr@...com,  richard@....at,  bbrezillon@...nel.org,
  kdasu.kdev@...il.com,  jaimeliao.tw@...il.com,  kilobyte@...band.pl,
  jonas.gorski@...il.com,  dgcbueu@...il.com
Subject: Re: [PATCH v5] mtd: rawnand: brcmnand: legacy exec_op implementation

Hello,

>> AFAIK, the legacy functions were only using it for
>> NAND_CMD_SET_FEATURES, which we don't support:
>> https://github.com/torvalds/linux/blob/c86b63b82fde4f96ee94dde827a5f28ff5adeb57/drivers/mtd/nand/raw/brcmnand/brcmnand.c#L1922-L1938
>>
>> The other uses I could find are already covered by our
>> chip->ecc.read/write functions.
>>
>> In any case I've tested the patch for reading, erasing and writing the
>> NAND and so far I haven't found any unsupported error apart from
>> NAND_CMD_GET_FEATURES with a Macronix NAND in the Sercom H500-s
>> (BCM63268).
>> I believe it's used for unlocking the NAND, which isn't needed in that
>> device.
>
> Well, you are restoring an old behavior so I won't ask for a better
> support, but you should normally allow software ECC engines (and even no
> engine at all) and in this case the core will require a write path. I
> honestly think it is not very complex to implement but if someone is
> lacking this feature it can be added later.
>
> Please just fix the braces in the for loop that was reported, but no
> hurry, I'll only take this after -rc1.

Nevermind, I'm applying now. You can send a follow-up patch for -rc1 if
you want.