Hi Mattijs, On Tue, Oct 20, 2026 at 1:43 PM Mattijs Korpershoek <[email protected]> wrote: > > Hi Jan, > > Thank you for the patch. > > On Fri, Oct 16, 2026 at 09:26, Jan Kehren <[email protected]> wrote: > > > AVB assumed its partitions were on mmc: avb_ops_alloc() took a bare device > > number and get_partition() called find_mmc_device(), which rules out > > verified boot from anything else. > > > > The user that benefits is "avb init", where boards already expect to name > > an interface: board/armltd/total_compute/total_compute.env picks between > > virtio and mmc at runtime and then runs "avb init ${blk_dev} 0", which no > > release has ever accepted. bootmeth_android gains nothing yet, since > > android_check() rejects non-mmc bootdevs through bootflow_iter_check_mmc(). > > > > Carry a uclass id alongside the device number and resolve the block device > > with blk_get_devnum_by_uclass_id(), keeping mmc_init() and the hardware > > partition switch on the mmc path only. "avb init <dev>" still means mmc, > > "avb init <interface> <dev>" selects another bus, and neither touches the > > device: it is still resolved on the first partition access. > > > > Only mmc is started by AVB itself, so say that in Kconfig and avb2.rst. > > > > Signed-off-by: Jan Kehren <[email protected]> > > Reviewed-by: Mattijs Korpershoek <[email protected]> > > > ---
Hi Mattijs, A bit off-topic: it looks like this patch series will land soon, so should I rebase v3 of "avb: device lock state, root key provisioning and in-place verification", which I'm about to send, on top of this patch series? Best regards, Igor
