On Sat, 28 Dec 2019 at 21:09, Tuomas Tynkkynen <[email protected]> wrote:
> Hi, > > On Sat, 28 Dec 2019 at 17:19, Heinrich Schuchardt <[email protected]> > wrote: > > > > On 12/28/19 4:03 PM, Sughosh Ganu wrote: > > > > > > On Sat, 28 Dec 2019 at 20:01, Heinrich Schuchardt <[email protected] > > > <mailto:[email protected]>> wrote: > > > > > > On 12/27/19 3:26 PM, Sughosh Ganu wrote: > > > > Add support for the EFI_RNG_PROTOCOL routines for the qemu arm64 > > > > platform. EFI_RNG_PROTOCOL is an uefi boottime service which is > > > > invoked by the efi stub in the kernel for getting random seed > for > > > > kaslr. > > > > > > > > The routines are platform specific, and use the virtio-rng > device on > > > > the platform to get random data. > > > > > > > > The feature can be enabled through the following config > > > > CONFIG_EFI_RNG_PROTOCOL > > > > > > > > Signed-off-by: Sughosh Ganu <[email protected] > > > <mailto:[email protected]>> > ... > > > > Adding the uclass_get_device() solution in a weak function is ok for me. > > > > When testing I already experienced that I had to issue the `virtio scan` > > command. > > > > But in board_init() in qemu-arm.c we already call virtio_init(). If that > is not > working correctly, there is a bug that should be fixed instead. > There is no issue with virtio_init. > > Maybe the problem is that PCI bus has not been scanned at the time of > that virtio_init() call (so everything would work correctly with > virtio-mmio > but virtio-pci is broken)? > Yes, this is the issue. The pci bus has not been scanned when virtio_init is called. In fact, the pci_init function gets called only as part of the preboot function, before the main loop is invoked. Thus 'dm tree' shows the virtio-pci device, but a virtio scan is needed to get the rng device. Calling pci_init before virtio_init is called shows up all the virtio devices. -sughosh
