linux-kernel - Re: [PATCH v1 05/14] mtd: spi-nor: xilinx: rename vendor specific functions and defines

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: <c3a58de8ee39dd473483dfd0ed8a0058@walle.cc>
Date:   Tue, 15 Feb 2022 09:25:49 +0100
From:   Michael Walle <michael@...le.cc>
To:     Tudor.Ambarus@...rochip.com
Cc:     linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
        p.yadav@...com, miquel.raynal@...tlin.com, richard@....at,
        vigneshr@...com
Subject: Re: [PATCH v1 05/14] mtd: spi-nor: xilinx: rename vendor specific
 functions and defines

Am 2022-02-10 09:06, schrieb Tudor.Ambarus@...rochip.com:
> On 2/10/22 10:04, Michael Walle wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know 
>> the content is safe
>> 
>> Am 2022-02-10 04:08, schrieb Tudor.Ambarus@...rochip.com:
>>> On 2/2/22 16:58, Michael Walle wrote:
>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you 
>>>> know
>>>> the content is safe
>>>> 
>>>> Drop the generic spi_nor prefix for all the xilinx functions.
>>> 
>>> mm, no, I would keep the spi_nor prefix because xilinx_sr_ready is 
>>> too
>>> generic and can conflict with methods from other subsystems.
>> 
>> But all the other functions in this file start with xilinx_ ;)
>> 
>> I don't have a strong opinion here, other than it shouldn't
>> be called spi_nor_read_blaba() because that looks like a
>> standard spi nor function belonging in core.c
>> 
> 
> then let's prepend all with spi_nor_xilinx_*()?

I'm still not sure what to do here. Have a look at all the other
vendor modules in spi-nor. they are all prefixed with the vendor
name? E.g. there is a sst_write() which is far more likely to
cause a conflict. So should we rename all these functions? Or
do we just take our chance that it might have a conflict in
the future (with an easy fix to rename the function then). TBH
I doubt there will be a global symbol "xilinx_read_sr()".

But I care for consistency, so having some named xilinx_, sst_,
st_micron_ and some spi_nor_read_xsr sounds and looks awful.

-michael