[RFC PATCH 1/1] Makefile: Expand legacy (non-DM) driver warnings
sjg at chromium.org
Tue Mar 31 01:57:03 CEST 2020
On Mon, 30 Mar 2020 at 10:07, Niel Fourie <lusus at denx.de> wrote:
> Hi Simon
> On 3/28/20 9:05 PM, Simon Glass wrote:
> > Hi Niel,
> > On Wed, 25 Mar 2020 at 07:47, Niel Fourie <lusus at denx.de> wrote:
> >> Expand warnings printed by Makefile after compile when legacy
> >> drivers are in use. These include:
> >> - CONFIG_HAVE_BLOCK_DEVICE without CONFIG_BLK
> >> - CONFIG_BOOTCOUNT_LIMIT without CONFIG_DM_BOOTCOUNT
> >> - CONFIG_MTD without CONFIG_DM_MTD
> >> - CONFIG_PHYLIB without CONFIG_DM_MDIO
> >> - CONFIG_POWER, also without CONFIG_DM_PMIC
> >> - Absence of CONFIG_RAM and CONFIG_SPL_RAM
> >> Also replaced existing CONFIG_DM_SPI warning for consistency.
> >> Removed CONFIG_BLK requirement for CONFIG_DM_USB, as all USB
> >> devices not block devices.
> >> Signed-off-by: Niel Fourie <lusus at denx.de>
> >> Cc: Simon Glass <sjg at chromium.org>
> >> ---
> >> Makefile | 73 +++++++++++++++++++++++++++++++++++++++++++++++++++-----
> >> 1 file changed, 67 insertions(+), 6 deletions(-)
> > Could we add instructions on what should be done? It seems a little
> > unclear to me.
> Yes, sure. I am still a little uncertain on how to correctly create a
> sensible RFC patch.
> My question is basically: How useful would you consider having more of
> these warnings in the Makefile, if at all? I am the least certain of the
> last one with CONFIG_RAM and CONFIG_SPL_RAM.
> For background, I explored the driver model and then I had a look at how
> much legacy there was still around. I found some further defines and
> conditions which could be turned into legacy warnings in the Makefile
> for some more visibility. Any even further such warnings would mostly
> involve checking the defines for the individual legacy drivers, which I
> do not really consider viable.
> Testing of these warnings, especially automated, would be a challenge. I
> have a heavily butchered Sandbox build which triggers most of the legacy
> warnings in the Makefile, but I would not want to inflict it on anybody
I suggest creating a series that adds each warning, and cc trini.
Overall I think it is a good idea.
would love to see a test (maybe a shell/Python script called from
test/run?) that builds sandbox with various CONFIG options
added/removed. There are a few combinations that it would be nice to
add to that. For example building sandbox with NO_SDL=1 in addition to
what you have above.
I'm thinking of something like:
sed '/CONFIG_XXX/d' .config
echo CONFIG_YYY >>.config
So if you feel up to trying that, please do. Otherwise manual testing
is good enough.
More information about the U-Boot