Hi Igor, On Tue, Oct 20, 2026 at 14:57, Igor Opaniuk <[email protected]> wrote:
> 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? Yes, if you can rebase on top of this series that would be great! Thank you. Mattijs > > Best regards, > Igor
