On Mon, Jan 31, 2022 at 03:59:08PM -0700, Simon Glass wrote:
Hi Tom,
(yes Mark I am trying to stop further boards going in that use the shell scripts)
On Mon, 31 Jan 2022 at 15:05, Tom Rini trini@konsulko.com wrote:
On Mon, Jan 31, 2022 at 02:22:41PM -0700, Simon Glass wrote:
Hi Tom,
On Mon, 31 Jan 2022 at 13:40, Tom Rini trini@konsulko.com wrote:
On Mon, Jan 31, 2022 at 12:57:57PM -0700, Simon Glass wrote:
Hi Tom,
On Mon, 31 Jan 2022 at 11:00, Tom Rini trini@konsulko.com wrote:
On Mon, Jan 31, 2022 at 10:27:41AM -0700, Simon Glass wrote: > Hi Tom, > > On Mon, 31 Jan 2022 at 09:15, Tom Rini trini@konsulko.com wrote: > > > > On Mon, Jan 31, 2022 at 09:13:02AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Mon, 31 Jan 2022 at 07:24, Tom Rini trini@konsulko.com wrote: > > > > > > > > On Sun, Jan 30, 2022 at 08:52:25AM -0700, Simon Glass wrote: > > > > > > > > > More than a year after this migration message appeared, we still have new > > > > > boards being added with this option. Add a check against this. > > > > > > > > > > Signed-off-by: Simon Glass sjg@chromium.org > > > > > > > > Please just make this an error in checkpatch.pl instead. > > > > > > I couldn't think of a way of doing that...do you have an idea? > > > > Yes, 2f3e8d6a86cb ("checkpatch: report ERROR only on disabling of fdt > > and initrd relocation") updates the check I had for fdt_high/initrd_high > > being in the file at all to only be for additions. And yes, I check > > every PR for new checkpatch ERROR lines and only ignore the ones for > > code imported from other projects. > > Yes, I understand that, but SPL_FIT_GENERATOR defaults to on for > certain boards, so there is no need to mention it anywhere in the > patch. Also someone could adjust the condition in the Kconfig to add > other boards.
Then you want something a bit more like the fdt|initrd_high check now, along with updating the help around SPL_FIT_GENERATOR to note that this option is deprecated, is the path forward then I think.
I'm still a bit lost.
What I want: break the build if someone adds a new board that uses SPL_FIT_GENERATOR
What you are offering: checkpatch check for people adding that option
But the patch doesn't generally include that option.
I can certainly mention in the Kconfig help that the option is deprecated, but without checking if it is defined for a NEW board, I cannot prevent it from growing.
What am I missing? Can you be more specific?
How do you add a new board that enables SPL_FIT_GENERATOR without "SPL_FIT_GENERATOR" being in the resulting patch, other than being ARCH_ZYNQMP/ARCH_ROCKCHIP ?
Well that's the case I am most concerned with, actually. Also, someone might add a new condition to SPL_FIT_GENERATOR.
For the current cases, we just need to get them migrated since it's all the same logic? So it would I think be a one-and-done thing. For a new
Yes I think so and some of them are done. These are what I can find:
./arch/riscv/lib/mkimage_fit_opensbi.sh ./arch/arm/mach-zynqmp/mkimage_fit_atf.sh ./arch/arm/mach-imx/mkimage_fit_atf.sh ./arch/arm/mach-rockchip/make_fit_atf.py
but they are not used by that many boards.
I feel that the amount of pending migration is somewhat overwhelming and we should take a stronger line in mainline.
Perhaps I should send a patch to simply remove the option? Would that be acceptable?
Is there something technically preventing their migration to buildman? Looking over examples for imx8* conversions, it's just adding a binman node and describing things there, yes?