All of 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.