[U-Boot] [PATCH 05/16] mtd: spi: Port SPI NOR framework from Linux

[Stefan Roese]

On 13.12.18 04:01, Tom Rini wrote:
> On Thu, Dec 13, 2018 at 04:51:56AM +0530, Jagan Teki wrote:
>> On Thu, Dec 13, 2018 at 4:26 AM Tom Rini <trini at konsulko.com> wrote:
>>>
>>> On Thu, Dec 13, 2018 at 02:01:15AM +0530, Jagan Teki wrote:
>>>> On Wed, Dec 12, 2018 at 11:10 PM Vignesh R <vigneshr at ti.com> wrote:
>>>>>
>>>>> Current U-Boot SPI NOR support (sf layer) is quite outdated as it does not
>>>>> support 4 byte addressing opcodes, SFDP table parsing and different types of
>>>>> quad mode enable sequences. Many newer flashes no longer support BANK
>>>>> registers used by sf layer to a access >16MB space.
>>>>> Also, many SPI controllers have special MMIO interfaces which provide
>>>>> accelerated read/write access but require knowledge of flash parameters
>>>>> to make use of it. Recent spi-mem layer provides a way to support such
>>>>> flashes but sf layer isn't using that.
>>>>> So sync SPI NOR framework from Linux v4.19 and add spi-mem support on top.
>>>>> in order to gain 4 byte addressing support, SFDP support and a way to
>>>>> support SPI controllers with MMIO flash interface.
>>>>>
>>>>> Signed-off-by: Vignesh R <vigneshr at ti.com>
>>>>> ---
>>>>>   drivers/mtd/spi/spi-nor-core.c | 2647 ++++++++++++++++++++++++++++++++
>>>>>   include/linux/mtd/cfi.h        |   32 +
>>>>>   include/linux/mtd/spi-nor.h    |  421 +++++
>>>>
>>>> Please refer many mails about this comment. I don't look for carbon
>>>> copy of the code from Linux, you can use the implementation and even
>>>> macro names etc but the end code would be the code that require
>>>> U-Boot.
>>>>
>>>> - no __UBOOT ifdef
>>>
>>> What?  This is the exact opposite of what we're doing in several other
>>> areas, with a large amount of success precisely because it allows us to
>>> leverage developer base to catch and fix problems.  Dropping in the code
>>> and minor and obvious deviations make for easier re-sync.
>>
>> Several areas, but not spi-flash or spi. ie what I'm maintaining from
>> long. I'm always looking for persistent code to be IN. May be it can't
>> be syn-cable but we can work it more maintainable in u-boot way like
>> other opensource project.  Well this is my experience with the U-Boot
>> project development so-far, I never ever hold any features but if
>> u-boot need the same features, better to add then like new code.
> 
> I think that for flash related SPI we should follow the lead of the rest
> of MTD/NAND and adapt the kernel code.

Yes, we should have learned this lesson from the past. So full ACK from
me.

Thanks,
Stefan