[U-Boot] [PATCH 70/93] arm: Remove ap121 board

[Simon Glass]

Hi Daniel,

On Wed, 21 Nov 2018 at 17:47, Daniel Schwierzeck
<daniel.schwierzeck at gmail.com> wrote:
>
> Hi Simon,
>
> Am 19.11.18 um 16:53 schrieb Simon Glass:
> > This board has not been converted to CONFIG_DM_BLK by the deadline.
> > Remove it.
> >
> > Signed-off-by: Simon Glass <sjg at chromium.org>
> > ---
> >
> >  arch/mips/mach-ath79/Kconfig |  1 -
> >  board/qca/ap121/Kconfig      | 27 ----------------
> >  board/qca/ap121/MAINTAINERS  |  6 ----
> >  board/qca/ap121/Makefile     |  3 --
> >  board/qca/ap121/ap121.c      | 46 ---------------------------
> >  configs/ap121_defconfig      | 60 ------------------------------------
> >  include/configs/ap121.h      | 46 ---------------------------
> >  7 files changed, 189 deletions(-)
> >  delete mode 100644 board/qca/ap121/Kconfig
> >  delete mode 100644 board/qca/ap121/MAINTAINERS
> >  delete mode 100644 board/qca/ap121/Makefile
> >  delete mode 100644 board/qca/ap121/ap121.c
> >  delete mode 100644 configs/ap121_defconfig
> >  delete mode 100644 include/configs/ap121.h
>
> your approach with simply forcing CONFIG_BLK is flawed. This board
> doesn't use any block devices. If I enable CONFIG_BLK manually via
> menuconfig, I get this link error:
>
>   LD      u-boot
> drivers/built-in.o: In function `blk_post_probe':
> drivers/block/blk-uclass.c:(.text.blk_post_probe+0x10): undefined
> reference to `part_init'
> make: *** [Makefile:1381: u-boot] Error 1
>
> But part_init() is defined in disk/part.c and guarded by
> CONFIG_HAVE_BLOCK_DEVICE. If I enable that too, the board will build fine.
>
> So the actual bug is that CONFIG_BLK doesn't do a SELECT PARTITIONS or
> that drivers/block/blk-uclass.c doesn't guard the call to part_init()
> with CONFIG_HAVE_BLOCK_DEVICE. Maybe you should fix that and then try
> again. I guess you will have much less failing boards.

Unfortunately there are many things that can go wrong.

CONFIG_HAVE_BLOCK_DEVICE should be removed, I think, and the 5 boards
that use it updated. With DM we can just use CONFIG_BLK.

If CONFIG_BLK is enabled, that means we have block devices. Ideally we
would not enable it by default, and perhaps there is some Kconfig
magic that can enable it only when USB/MMC/etc, are enabled in
Kconfig? But that will not cause us to detect all boards that need
updating, since boards that don't use DM for the subsystem would then
get CONFIG_BLK enabled.

Here I think the best solution is for you to send a patch which
disables CONFIG_BLK for your boards (either in Kconfig or defconfig).
That should take precedence over CONFIG_BLK becoming the default.

Regards,
Simon