[U-Boot] [PATCH v3 0/3] spi: Split CONFIG_DM_SPI* to CONFIG_{SPL_TPL}DM_SPI*

[Schrempf Frieder]

Hi Lukasz,

On 10.09.19 12:22, Lukasz Majewski wrote:
> Hi Frieder,
> 
>> On Mon, 9 Sep 2019 11:11:50 +0000
>> Schrempf Frieder <frieder.schrempf at kontron.de> wrote:
>>
>>> Hi Lukasz,
>>>
>>> On 05.09.19 20:09, Tom Rini wrote:
>>>> On Thu, Sep 05, 2019 at 12:16:36AM +0200, Lukasz Majewski wrote:
>>>>    
>>>>> This patch series introduces new SPL and TPL specific Kconfig
>>>>> entries for DM_SPI* options. Such change allows using the spi
>>>>> driver in SPL/TPL or U-Boot proper.
>>>>>
>>>>> First two patches - related to ls10{42}* NXP soc fix some issues
>>>>> with defining the DM_SPI* defines in <board>.h file instead of
>>>>> Kconfig.
>>>>>
>>>>> This series doesn't introduce build breaks, but board maintainers
>>>>> are kindly asked to check if their boards still boots.
>>>>>
>>>>> Buildman setup for binary size regression checking:
>>>>>
>>>>> ./tools/buildman/buildman.py -b HEAD --count=4 ls1043
>>>>> --output-dir=../BUILD/ --force-build -CveE
>>>>> ./tools/buildman/buildman.py -b HEAD --count=4 ls1043
>>>>> --output-dir=../BUILD/ -Ssdel
>>>>
>>>> So you did fix the ls1043 problems but ls1046 is still a problem.
>>>>     
>>>
>>> I was trying to clean up this config mess some weeks ago. I
>>> stumbled over the same issues (size deltas below) when I tested
>>> with buildman and finally gave up on it. This was my testing branch
>>> for reference: [1].
>>>
>>> Thanks for your work and I hope you/we can get this sorted out
>>> somehow...
>>
>> For now I've only posted the patch to introduce SPL_DM_SPI in Kconig:
>> https://patchwork.ozlabs.org/patch/1159655/
> 
> However, I've looked on your patchset and IMHO this work could be
> divided (as doing it at once is not feasible).
> 
> For example the CONFIG_SPI_FLASH_MTD could be converted to
> (SPL_TPL_)SPI_FLASH_MTD and then one could use
> 
> #if CONFIG_IS_ENABLED(SPI_FLASH_MTD) in drivers/mtd/spi/sf_probe.c (as
> it is only used there).
> 
> Then we could avoid situations where code is added as you remove it
> here [1]:
> https://github.com/fschrempf/u-boot/commit/b6489fb5928c2b41d7e4cb39933f078659b4f10e#diff-9d3e174d033b8b9c9d380a22a81600aaL136
> 
> What I'm afraid though, is that split of SPI_FLASH_MTD will require
> adding unwillingly SPL_(TPL_)SPI_FLASH_MTD to all boards which already
> define it (and only drop ones, which use in <config>.h file pattern as
> [1]).

Yes, this looks like what I've tried to do separately in this branch [1].

The problem with some socfpga boards is, that they enable 
CONFIG_SPI_FLASH_MTD in socfpga_common.h, without enabling 
CONFIG_SPI_FLASH, which is probably wrong. So I tried to correct this, 
but looking at it again, this should be done separately.

So if I remove the added "CONFIG_SPI_FLASH=y" from my patches and 
rebase, this should be ok.

For this set I have still one question: Should I split the patches as 
currently done in [1]? This would mean after the first patch some boards 
miss SPI_FLASH_MTD code and the subsequent board config patches correct 
it afterwards. Or should I merge all the changes to a single patch, to 
not break the boards in between.
Unfortunately I can't do it the other way round and apply the board 
config changes first, as this breaks the build.

> Frieder, would you be able to work on this topic any time soon?

I can try to find some time this weekend and try to get [1] ready. But I 
probably won't be able to spend serious amounts of time anytime soon on 
the remaining tasks.

Thanks,
Frieder

[1]: https://github.com/fschrempf/u-boot/commits/spi_flash_mtd_cleanup