On Sat, 4 Nov 2023 09:00:07 +0200 Heinrich Schuchardt <heinrich.schucha...@canonical.com> wrote:
Hi Heinrich, many thanks for finding and fixing this! > In different parts of our code we assume that the first RNG device is the > one to be used. Therefore it is preferable to detect the availability of > the RNDR register already in the bind method. > > For signaling the non-existence of a device the driver model requires using > ENOENT (and not ENODEV). Doh, now I feel silly! I thought I checked the call path, and looked at initcall_run_list(), which prints the error message, and suggests that only 0 would be acceptable. But indeed -ENOENT works, with the slight caveat of printing: ================ No match for driver 'arm-rndr' Some drivers were not found ================ But it's definitely an improvement over the current situation, and I don't feel like boiling the DM ocean for this stupid little driver. > Fixes: 31565bb0aa2d ("driver: rng: Add DM_RNG interface for ARMv8.5 RNDR > registers") > Signed-off-by: Heinrich Schuchardt> <heinrich.schucha...@canonical.com> Reviewed-by: Andre Przywara <andre.przyw...@arm.com> Tested-by: Andre Przywara <andre.przyw...@arm.com> Many thanks! Andre --- > drivers/rng/arm_rndr.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/rng/arm_rndr.c b/drivers/rng/arm_rndr.c > index 55989743ea..4512330e68 100644 > --- a/drivers/rng/arm_rndr.c > +++ b/drivers/rng/arm_rndr.c > @@ -62,10 +62,10 @@ static const struct dm_rng_ops arm_rndr_ops = { > .read = arm_rndr_read, > }; > > -static int arm_rndr_probe(struct udevice *dev) > +static int arm_rndr_bind(struct udevice *dev) > { > if (!cpu_has_rndr()) > - return -ENODEV; > + return -ENOENT; > > return 0; > } > @@ -74,7 +74,7 @@ U_BOOT_DRIVER(arm_rndr) = { > .name = DRIVER_NAME, > .id = UCLASS_RNG, > .ops = &arm_rndr_ops, > - .probe = arm_rndr_probe, > + .bind = arm_rndr_bind, > }; > > U_BOOT_DRVINFO(cpu_arm_rndr) = {