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

[Simon Glass]

Hi Tom,

On Thu, 22 Nov 2018 at 16:23, Tom Rini <trini at konsulko.com> wrote:
>
> On Thu, Nov 22, 2018 at 01:50:08PM -0700, Simon Glass wrote:
> > 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.
>
> No, the problem we have right here is that the logic in
> drivers/block/blk-uclass.c to call part_init() doesn't match the logic
> we have around when we build disk/part.c that defines part_init().
> Locally I've made disk/part.o be built with CONFIG_BLK (and SPL/TPL).
> Once we've got the transition done we can see what clean-ups follow from
> it.

Oh wow I see.

But it seems to me that CONFIG_HAVE_BLOCK_DEVICE could be dropped and
we could just use CONFIG_BLK?

Regards,
Simon