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@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@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.