linux-kernel - Re: [PATCH v2 4/4] mtd: spi-nor: sfdp: Keep SFDP definitions private

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

Message-ID: <1fa079c4a0341ffe6ad7bdebd3cb8958@walle.cc>
Date:   Wed, 06 Apr 2022 12:31:22 +0200
From:   Michael Walle <michael@...le.cc>
To:     Pratyush Yadav <p.yadav@...com>
Cc:     Tudor.Ambarus@...rochip.com, miquel.raynal@...tlin.com,
        richard@....at, vigneshr@...com, linux-mtd@...ts.infradead.org,
        linux-kernel@...r.kernel.org, Nicolas.Ferre@...rochip.com
Subject: Re: [PATCH v2 4/4] mtd: spi-nor: sfdp: Keep SFDP definitions private

Hi,

I didn't follow the series closely, so I might miss something.

Am 2022-04-05 21:31, schrieb Pratyush Yadav:
> On 04/04/22 06:19AM, Tudor.Ambarus@...rochip.com wrote:
>> On 4/1/22 23:01, Pratyush Yadav wrote:
>> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>> >
>> > On 09/03/22 04:42PM, Tudor Ambarus wrote:
>> >> Keep the SFDP definitions private and expose just the definitions that are
>> >> required by the core and manufacturer drivers.
>> >
>> > I am not so sure about this. Since the post_bfpt hook passes in the bfpt
>> > table to flash drivers, they might end up wanting to use these for some
>> > checks like issi.c does for DWORD 1. They would have to move them back
>> > to sfdp.h for that, which just causes extra churn, and also puts some
>> > BFPT related defines in sfdp.h and some in sfdp.c.
>> >

It's not the extra churn, but also git blame doesn't really work. In
fact, it is already really hard to follow all the commits in spi-nor/
with all the code moving around. So what is the actual adavantage of
having this stuff private? One clear disadvantage is that you need to
move it from sfdp.c to sfdp.h once you need it. And potentially, you
might need all the defines.

Also, if you pass the SFDP data to any fixups, the drivers are expected
to use them.

>> That's correct, but I think exposing just the public defines in sfdp.h 
>> is
>> the path to follow. We should keep private all the definitions that we 
>> can
>> private in sfdp.c and expose publicly in sfdp.h just the ones that are 
>> shared.
>> Flash collisions, and implicitly the need of public SFDP definitions, 
>> should be
>> an exception, so I expect sfdp.h to be short in size.
> 
> I disagree. I think we should keep everything in the same place. And
> since we need to expose this to manufacturer drivers, that place is
> sfdp.h. Who is going to cast the tiebreaking vote here? ;-)

I'm leaning towards Pratyush opinion unless there is a clear advantage
to move the defines.

-michael