[RFCv2] doc: develop: Describe system configuration

[Pali Rohár]

On Thursday 28 July 2022 15:18:03 Tom Rini wrote:
> On Thu, Jul 28, 2022 at 09:05:07PM +0200, Pali Rohár wrote:
> > On Thursday 28 July 2022 14:53:49 Tom Rini wrote:
> [snip]
> > > +When it has been determined that the practical solution for where to have
> > > +something is in the ``CFG`` namespace, the next decision is where to place these
> > > +settings. It is strongly encouraged to place these in the architecture header
> > > +files, if they are generic to a given SoC, or under the board directory if board
> > > +specific. Placing them under the board.h file in the *include/configs/*
> > > +directory should be seen as a last resort.
> > 
> > Sounds good.
> > 
> > The only missing bit of information for me, which I really do not know
> > still remain... Where, how and in which format to store board specific
> > CFG option which is required for architecture or SoC for proper setup?
> > 
> > It cannot be in board/ subdir because arch/ code cannot use it (and even
> > do not know which include file should use). It cannot be in arch/ subdir
> > because it is SoC specific (e.g. arch would have to use long spaghetti
> > #if defined(BOARD_1) ... #elif defined(BOARD_2) ... #endif block). And
> > it cannot be in include/configs/ because you do not like it and do not
> > want it here.
> > 
> > Currently this issue is _un_solved by using CONFIG option either in
> > Kconfig or in include/configs/ ... and both options are not ideal.
> > 
> > I just do not see how to solve this problem.
> 
> I think it's fine to have things in quite literally <asm/arch/soc.h>
> (which we have a few of already) and then as needed #if / #elif / #endif
> for SoC changes.  Much of this _could_ be instead pulled from device
> trees.  But that's unlikely to happen for a number of platforms.  And
> for the board specific cases which are not converted to come out of
> device tree, include/configs/board.h isn't going to be able to go away
> for that platform just yet.
> 
> So in a round about way, yes, I'm just punting on the problem because I
> suspect the "right" answer is converting to driver model in a more
> complete way and pulling the information from the device tree.  But I
> accept there's not a desire on anyones part to invest that much time in
> a dead end platform.
> 
> -- 
> Tom

Driver model and device tree is probably the better place. But in case
such option is required for SoC setup to allow U-Boot to access device
tree then it cannot be in device tree...