On Sat, Nov 24, 2018 at 12:42:21PM -0700, Simon Glass wrote: > Hi Tom, > > On Thu, 22 Nov 2018 at 16:23, Tom Rini <tr...@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.schwierz...@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 <s...@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?
Now? Not sure. Eventually? Yes. -- Tom
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
