Hi Tom, On Wed, 11 Aug 2021 at 09:40, Tom Rini <tr...@konsulko.com> wrote: > > On Wed, Aug 11, 2021 at 08:26:38AM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Wed, 11 Aug 2021 at 08:17, Tom Rini <tr...@konsulko.com> wrote: > > > > > > On Wed, Aug 11, 2021 at 08:03:00AM -0600, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Wed, 11 Aug 2021 at 07:47, Tom Rini <tr...@konsulko.com> wrote: > > > > > > > > > > On Wed, Aug 11, 2021 at 06:56:31AM -0600, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Tue, 10 Aug 2021 at 13:38, Tom Rini <tr...@konsulko.com> wrote: > > > > > [snip] > > > > > > > I need to take another pass at converting a bunch of symbols, to > > > > > > > see > > > > > > > where we're at. Probably the biggest chunk of progress next > > > > > > > would be to > > > > > > > start converting CONFIG_SYS_xxx to SYS_xxx and moving defines out > > > > > > > of > > > > > > > config.h and in to something else. I'm taking a peek at some of > > > > > > > the > > > > > > > remaining PCI ones now. > > > > > > > > > > > > How about we set a deadline for this? It has gone on for too long > > > > > > and > > > > > > we just need to drop these CONFIGs. It's probably a higher priority > > > > > > than a Kconfig change. > > > > > > > > > > > > I was expecting that the config.h files would go away and we would > > > > > > use > > > > > > Kconfig (or DT) for everything. What sort of things don't fit into > > > > > > that model? > > > > > > > > > > Environment is the hard one to move out from config.h and in to, > > > > > well, I > > > > > > > > Well you know my views on that :-) > > > > > > > > http://patchwork.ozlabs.org/project/uboot/patch/1382763695-2849-4-git-send-email-...@chromium.org/ > > > > > > > > I still think it makes more sense than #defines and I can resurrect > > > > that series if you like. > > > > > > That might work, yeah. I just also want to focus on less things in > > > progress at once. That too I think has been part of why everything is > > > taking so long. > > > > OK I'll take a look. Other things in progress I can think of are: > > > > - drop common.h (could be done in one series if we just go for it) > > - set up issue tracking so we can keep an eye on these things > > Well, all of the DM migrations that have deadlines, and the there's > probably some that don't still. And the high level size concern about
Yes, I'm going to send a patch for serial and GPIO. > using DM on platforms where dynamic selection/detection isn't a > functional win. Assuming it is about 20KB added (plus devicetree), enabling OF_CONTROL seems worth it to me. For SPL I would like to see more adoption of your of-platdata idea. > > > > > > don't know what. I think there's also a handful of symbols like > > > > > CONFIG_SPL_MAX_SIZE that are a little tricky to convert directly (they > > > > > do math based on other symbols) rather than just as evaluate-and-set. > > > > > > > > We can either evaluate them and put the answer in as the defconfig > > > > value...or perhaps ask Masahiro to support evaluation in kconfig?! > > > > > > I do forget what kind of operations are allowed in Kconfig at this > > > point, it might be possible now, yes. And if not, something worth > > > trying. > > > > OK > > > > > > > > > > Right now, a little more than half of the unmigrated symbols are > > > > > CONFIG_SYS_xxx things and those likely should become SYS_xxx things. > > > > > Of > > > > > the ones that don't just go away. > > > > > > > > Do you mean things like this? > > > > > > > > arch/m68k/include/asm/immap.h:#define CONFIG_SYS_PCI_BAR0 > > > > (0x40000000) > > > > > > > > Assuming this doesn't move to devicetree, it should be in its own asm/ > > > > or asm/arch header file I think, not in the config.h file at all. > > > > > > > > FSL layerscape should move CONFIG_SYS_PCIE3_PHYS_SIZE et al to > > > > devcetree. > > > > > > I started and set aside *PCI* since a bunch of that goes away once > > > UCP1020 gets updated. But yes, there are lots of CONFIG_SYS_xxx things > > > that live inside and outside of config.h and step one is likely a simple > > > regex. They aren't really configurable. We can try and figure out what > > > "get this from DT" approach makes sense after. > > > > Yes agree we can't wait for DT move. > > > > > > > > > Some of the DM migrations will help - e.g. for I2C. NAND seems to have > > > > a lot - who is the NAND maintainer? > > > > > > There's not currently a NAND maintainer. > > > > > > > But really what I am asking is, can we set a deadline where all > > > > config.h files will be dropped? It has been 7 years... > > > > > > It's going to come down once again to figuring out what to do about > > > older platforms. Since I picked on khadas platforms earlier, here's > > > where meson64.h looks really good. All of the platforms use > > > include/configs/meson64.h and that's very little outside of environment > > > stuff. To go back to another part of the thread, it also shows how hard > > > environment stuff is. > > > > Well let's see. > > > > > > > > It also reminded me that buildman never got kconfiglib support directly > > > and we still have genboardcfg.py to spit out boards.cfg to be parsed by > > > buildman. > > > > Ah yes, so is buildman the only reason we have that file? I do like > > being able to grep it for stuff, but I suppose buildman could support > > that. Is there no other user? > > Ah, yes, so there's two things it does. One is buildman. Two is "spit > an error out if a defconfig lacks a MAINTAINER entry". The latter is > important but could be its own tool, and then of course looking at > MAINTAINER files is how to see what config header a given defconfig > uses. OK I see. The defconfig file seems to be in the Kconfig now...so I suppose I don't fully understand that. Regards, Simon