From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Sat, 24 Nov 2018 12:42:21 -0700 Subject: [U-Boot] [PATCH 70/93] arm: Remove ap121 board In-Reply-To: <20181122232335.GD11247@bill-the-cat> References: <20181119155413.158098-1-sjg@chromium.org> <20181119155413.158098-71-sjg@chromium.org> <4c8effaf-ad0d-8a5e-9426-4a2138db7136@gmail.com> <20181122232335.GD11247@bill-the-cat> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Tom, On Thu, 22 Nov 2018 at 16:23, Tom Rini 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 > > 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 > > > > --- > > > > > > > > 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