On Thu, Nov 22, 2018 at 01:47:24AM +0100, Daniel Schwierzeck 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@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.
There's a few different parts to the problem of switching more globally to BLK being enabled. And yes, you're right, we need to do something to ensure that disk/part.o is linked in or drivers/block/blk-uclass.c only calls part_init() in fewer cases. Thanks!