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

[Tom Rini]

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 <trini at 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.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.
> 
> 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
-------------- 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/20181124/4c703bbc/attachment.sig>