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

[Michael Walle]

Am 2022-02-15 09:52, schrieb Tudor.Ambarus@xxxxxxxxxxxxx:
> Miquel in To:
>
> On 2/15/22 10:25, Michael Walle wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know 
> > the content is safe
> >
> > Am 2022-02-10 09:06, schrieb Tudor.Ambarus@xxxxxxxxxxxxx:
> > > 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@xxxxxxxxxxxxx:
> > > > > 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()".
>
> I doubt it will not be a conflict.
>
> > But I care for consistency, so having some named xilinx_, sst_,
> > st_micron_ and some spi_nor_read_xsr sounds and looks awful.
>
> yes, I agree. Take a look on what's happening in NAND. They prepend
> the name with vendor_nand_*(). Or in SPI NAND they use flash family
> names which should be unique. So how about aligning with NAND and
> use vendor_nor_*()?

Sounds good. Regarding the flash family.. take a look at Winbond W25M
which can either be NAND or NOR depending on the size ;)

But the main question was rather whether we rename all the function
names at once or bit by bit. To proceed here with this series, I'd
use the vendor_nor_ prefix for the moved functions (but still keep
the micron_st_ st_micron_ rename patch).

-michael