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

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20181122/17b6c118/attachment.sig>