[U-Boot] [PATCH 5/7] Convert CONFIG_SF_DEFAULT_* to Kconfig

[Patrick DELAUNAY]

Hi Simon,

> From: Simon Goldschmidt <simon.k.r.goldschmidt at gmail.com>
> Sent: lundi 4 mars 2019 11:51
> 
> On Mon, Mar 4, 2019 at 11:44 AM Patrick DELAUNAY
> <patrick.delaunay at st.com> wrote:
> >
> > Hi Simon,
> >
> > > From: Simon Goldschmidt <simon.k.r.goldschmidt at gmail.com>
> > > Sent: mercredi 27 février 2019 15:50
> > >
> > > [reducing the CC list as gmail won't let me send otherwise]
> > >
> > > On 27.02.2019 15:20, Patrick Delaunay wrote:
> > > > This converts the following to Kconfig:
> > > >    CONFIG_SF_DEFAULT_BUS
> > > >    CONFIG_SF_DEFAULT_CS
> > > >    CONFIG_SF_DEFAULT_MODE
> > > >    CONFIG_SF_DEFAULT_SPEED
> > > >
> > > > I use moveconfig script and then manual check on generated
> > > > u-boot.cfg to solve the remaining issue.
> > > >
> > > > Signed-off-by: Patrick Delaunay <patrick.delaunay at st.com>
> > >
> > > I admit I haven't followed the patches regarding these defines
> > > completely, but isn't moving these to Kconfig the opposite of what we want?
> >
> > Yes it was my first plan in the series:
> >
> > http://patchwork.ozlabs.org/project/uboot/list/?series=76834&state=*
> > http://patchwork.ozlabs.org/project/uboot/list/?series=80769&state=*
> >
> > But it is not possible too many dependency with board using platdata for SPI
> initialization and regression after my v3.
> 
> Oh, ok. That's sad. But I wouldn't have time to work on this, either...
> 
> >
> > > I always thought the goal would be to move U-Boot to DM and
> > > devicetree completely sooner or later (where these defines aren't
> > > used). Adding them to Kconfig does not make them optional but makes
> > > them *always* present (but probably with default values if not used).
> >
> > Migration to Kconfig was requested by Jagan in
> > http://patchwork.ozlabs.org/patch/1031768/
> >
> > The define need to be always define, as they are used in cmd/sf.c They
> > could dependent on CONFIG_CMD_SF when they are no more used is other
> part of code (for other purpose).
> 
> Well, defaults for that command are not necessarily defaults for use at driver
> level?

Yes, but today it is the case for some fallback when DT information is not available (dfu_sf / spl_spi).
And I don't know solve this issue.

This serie is only a step, I hope in the good direction.

> >
> > ./board/Arcturus/ucp1020/cmd_arc.c
> > ./board/aristainetos/aristainetos-v1.c
> > ./board/aristainetos/aristainetos-v2.c
> > ./board/davinci/da8xxevm/da850evm.c
> > ./board/davinci/da8xxevm/omapl138_lcdk.c
> > ./board/el/el6x/el6x.c
> > ./board/siemens/taurus/taurus.c
> > ./board/Synology/ds414/cmd_syno.c
> > ./board/tqc/tqma6/tqma6.c
> > ./cmd/mvebu/bubt.c
> > ./common/splash_source.c
> > ./common/spl/spl_spi.c
> > ./drivers/dfu/dfu_sf.c
> >
> > And yes, 0 is the "default" value, so defines are present in .config.
> >
> > Why it is disturbing if these defines are requested by command sf ?
> 
> Because I would have thought with DM, defaults would come from dts, not from
> some defines.
> 
> Anyway, I guess I now understand why you have done it like that.
> I'm not the SPI maintainer, so I won't interfere. I was only a little bit surprised that
> this took a different direction as the first things we discussed in that area...

In fact, I am also waiting feedback to be sure that is the good direction.

> And as long as this define doesn't interfere with my SPL + U-Boot using the
> settings from dts, this looks good, I guess.

Yes, no interference: they are used only when DT is not available
(tested on my board stm32mp1 ev1 which use only device tree, and it is OK).

> 
> Regards,
> Simon
> 
> >
> > > Regards,
> > > Simon
> >
> > Jagan: can you tell me what is the right direction.for you...
> >
> > Regards
> >
> > Patrick

Patrick