linux-kernel - Re: [PATCH 1/2] mtd: spi-nor: Introduce erase

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: <7caffdd6-2292-d454-7a76-5dbc30ab9c29@nokia.com>
Date:   Mon, 25 Jul 2022 16:54:16 +0200
From:   Alexander Sverdlin <alexander.sverdlin@...ia.com>
To:     Tudor.Ambarus@...rochip.com, p.yadav@...com
Cc:     linux-mtd@...ts.infradead.org, michael@...le.cc,
        miquel.raynal@...tlin.com, richard@....at, vigneshr@...com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] mtd: spi-nor: Introduce erase_proto

Hi Tudor!

On 18/07/2022 18:50, Tudor.Ambarus@...rochip.com wrote:
>>> @@ -2727,6 +2727,9 @@ static void spi_nor_late_init_params(struct spi_nor *nor)
>>>        */
>>>       if (nor->flags & SNOR_F_HAS_LOCK && !nor->params->locking_ops)
>>>               spi_nor_init_default_locking_ops(nor);
>>> +
>>> +     if (!nor->erase_proto)
>>> +             nor->erase_proto = nor->write_proto;
>> I get that you are trying to not break any existing flashes with this,
>> but I don't quite like it. We should keep the same initialization flow
>> with erase_proto as with write_proto, read_proto, etc. That is,
>> initialize it to SNOR_PROTO_1_1_1 in spi_nor_scan() and then let the
>> initialization procedure change it as needed.
>>
>> The problem with this is of course that it could break some flashes by
>> selecting the wrong erase. I would expect _most_ flashes to use
>> erase_proto as 1-1-1 but I of course haven't went and looked at every
>> single flash to point out the exceptions.
>>
>> I would like to hear from others if they think it is okay to do this.
>>
> Doesn't [1] solve Alexander's problem? Alexander, would you please test
> Patrice's patch and provide a Tested-by tag if everything is ok?

Yes, looks good, provided the Tested-by tag.

> Thanks,
> ta
> 
> [1] https://patchwork.ozlabs.org/project/linux-mtd/patch/20220629133013.3382393-1-patrice.chotard@foss.st.com/
> 

-- 
Best regards,
Alexander Sverdlin.