U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: Tom Rini <trini@konsulko.com>
Cc: sjg@chromium.org, u-boot@lists.denx.de, monstr@monstr.eu,
	hl@rock-chips.com, jeffy.chen@rock-chips.com,
	kever.yang@rock-chips.com, philipp.tomsich@theobroma-systems.com,
	uboot-imx@nxp.com, marek.behun@nic.cz,
	yamada.masahiro@socionext.com
Subject: Re: [PATCH v2 2/2] Makefile: Don't allow new boards with SPL_FIT_GENERATOR
Date: Mon, 31 Jan 2022 23:02:51 +0100 (CET)	[thread overview]
Message-ID: <d3cbf4bd79b545f4@bloch.sibelius.xs4all.nl> (raw)
In-Reply-To: <20220131204039.GG7515@bill-the-cat> (message from Tom Rini on Mon, 31 Jan 2022 15:40:39 -0500)

> Date: Mon, 31 Jan 2022 15:40:39 -0500
> From: Tom Rini <trini@konsulko.com>
> 
> 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 a problem isn't it?  Simon is basically saying no to any
new rk3399 board, which doesn't make any sense since this isn't a
board-specific issue but a SoC specific issue.  Adding new boards
doesn't make it more difficult to fix the issue.  I guess he is hoping
that saying no to a new rk3399 board will trick someone into actually
doing the work of adding the necessary code to binman?

  parent reply	other threads:[~2022-01-31 22:02 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-30 15:52 [PATCH v2 1/2] Makefile: Create a file to indicate the config Simon Glass
2022-01-30 15:52 ` [PATCH v2 2/2] Makefile: Don't allow new boards with SPL_FIT_GENERATOR Simon Glass
2022-01-30 19:40   ` Michal Simek
2022-01-30 23:14     ` Simon Glass
2022-01-31 14:24   ` Tom Rini
2022-01-31 16:13     ` Simon Glass
2022-01-31 16:15       ` Tom Rini
2022-01-31 17:27         ` Simon Glass
2022-01-31 18:00           ` Tom Rini
2022-01-31 19:57             ` Simon Glass
2022-01-31 20:40               ` Tom Rini
2022-01-31 21:22                 ` Simon Glass
2022-01-31 22:05                   ` Tom Rini
2022-01-31 22:59                     ` Simon Glass
2022-01-31 23:25                       ` Tom Rini
2022-01-31 23:32                         ` Tom Rini
2022-02-01 14:05                           ` Simon Glass
2022-02-01 15:42                             ` Simon Glass
2022-02-01 16:08                               ` Mark Kettenis
2022-02-01 16:24                                 ` Simon Glass
2022-01-31 22:02                 ` Mark Kettenis [this message]
2022-01-31 14:24 ` [PATCH v2 1/2] Makefile: Create a file to indicate the config Tom Rini
2022-01-31 16:13   ` Simon Glass
2022-01-31 16:21     ` Tom Rini
2022-01-31 17:27       ` Simon Glass

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d3cbf4bd79b545f4@bloch.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --cc=hl@rock-chips.com \
    --cc=jeffy.chen@rock-chips.com \
    --cc=kever.yang@rock-chips.com \
    --cc=marek.behun@nic.cz \
    --cc=monstr@monstr.eu \
    --cc=philipp.tomsich@theobroma-systems.com \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    --cc=uboot-imx@nxp.com \
    --cc=yamada.masahiro@socionext.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox