[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <58d0c47502218fd689c5ecd100ba0d5d02d89926@linux.dev>
Date: Wed, 19 Jul 2023 18:22:32 +0000
From: "Konstantin Ryabitsev" <konstantin.ryabitsev@...ux.dev>
To: "Benjamin Bara" <bbara93@...il.com>, dmitry.osipenko@...labora.com,
konstantin@...uxfoundation.org
Cc: bbara93@...il.com, benjamin.bara@...data.com, jonathanh@...dia.com,
lee@...nel.org, linux-i2c@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-tegra@...r.kernel.org,
peterz@...radead.org, rafael.j.wysocki@...el.com,
richard.leitner@...ux.dev, treding@...dia.com,
wsa+renesas@...g-engineering.com, wsa@...nel.org
Subject: Re: [PATCH v7 5/5] mfd: tps6586x: register restart handler
July 19, 2023 at 4:22 AM, "Benjamin Bara" <bbara93@...il.com> wrote:
> @Konstantin:
> Do you think it makes sense to print a warning when adding "non-standard
> trailers" during running "b4 trailers -u", maybe around the
> find_trailers() checks? I could provide a RFC, if considered useful.
With b4 being used for other projects than just the Linux kernel, I don't think it makes sense for us to track what is a valid and what is an invalid "person-trailer". I know that we could make it configurable, but I don't think this will actually improve the situation.
One goal for b4 is to allow defining validation tests and requiring them prior to "b4 send", so I think this is a better mechanism for dealing with such situations.
-K
Powered by blists - more mailing lists