[PATCH 1/6] Revert "Convert CONFIG_SYS_BR0_PRELIM et al to Kconfig"

[Pali Rohár]

On Sunday 01 May 2022 11:14:21 Tom Rini wrote:
> On Sun, May 01, 2022 at 04:44:16PM +0200, Pali Rohár wrote:
> > On Sunday 01 May 2022 10:39:39 Tom Rini wrote:
> > > On Sun, May 01, 2022 at 04:23:52PM +0200, Pali Rohár wrote:
> > > 
> > > > This reverts commit c7fad78ec0ee41b72a58bebb61959570eb937ab1.
> > > > 
> > > > This commit made configuration, understanding, maintenance, debugging and
> > > > future development of the powerpc/mpc85xx Local Bus Controller on P1/P2
> > > > boards impossible.
> > > > 
> > > > All preliminary Base and Option registers depends on other code and C
> > > > macros generated at C compile time and they comes from the other macros.
> > > > 
> > > > For example, NOR base address and NOR options are set via macros
> > > > CONFIG_SYS_FLASH_BR_PRELIM and CONFIG_SYS_FLASH_OR_PRELIM. And then based
> > > > on other logic are filled correct values in to the correct macros
> > > > CONFIG_SYS_BR*_PRELIM and CONFIG_SYS_OR*_PRELIM.
> > > > 
> > > > These config options are not user configurable options and therefore
> > > > should not appear in menuconfig. Moreover for P1/P2 boards they have
> > > > nothing with DDR driver, so they should not appear in drivers/ddr.
> > > > 
> > > > This change was completely wrong direction, so revert it. It allows to
> > > > start fixing issues with FLASH, NOR, NAND and CPLD LBC configuration.
> > > > In current state it is impossible.
> > > > 
> > > > See also thread for more details:
> > > > https://lore.kernel.org/u-boot/20220426181740.o2n7xfg46ytljcdx@pali/t/#u
> > > > 
> > > > Signed-off-by: Pali Rohár <pali at kernel.org>
> > > 
> > > NAK.  We are not moving things back in to board config headers under
> > > CONFIG namespace.  Some other solution is required.
> > 
> > I spend time on this and I do not see any other solution. As explained
> > that commit just introduced more issues then what it brought, so it was
> > step backward, not forward. So please show other solution, if you do not
> > like this one.
> 
> Anything that I suggested in the previous thread about moving to board
> Kconfig files.

Kconfig does not support evaluating C macros from C header files. So it
would not work.

> Or move it to some other header and out of CONFIG namespace.

This is board specific setting, used by drivers and arch code. So it
needs to be in some board location, like the config header file.

> Or if dtoc (doc/develop/driver-model/of-plat.rst) isn't
> sufficient today to pull out the infos to use at build time, expand it
> to cover this case as it would be useful for large numbers of other
> cases.

This would mean to rewrite completely everything about LBC configuration
and its peripherals. I really do not have energy nor time for it.

There are issues which needs to be fixed first, then some "code cleanup"
and "non-functional" changes could be done.

But that your commit c7fad78ec0ee41b72a58bebb61959570eb937ab1 make it
impossible to do anything with LBC, neither new development, nor doing
bug fixes. So it is in the worst state in which it can be.

That commit has same effect as conservation of the code and putting it
into the state to disallow future development in this area. Because
everybody who wants to touch it, has to first do what you wrote above.
But this is such giant work which nobody is going to do, just for fixing
small bug, which is completely unrelated to that work. And that work is
only refactor/code cleanup which does not bring any functional value.
Nothing so fancy, that somebody would do in spare time.

So I hope that this was not your intension.