Hello Nils,
thanks for the patch. It sounds like we will get a behaviour that is
more similar to FreeBSD one with it. But it has the potential to have a
big influence on existing BSPs so it would be good to have some more
feedback for it before merging it.
On 09/08/2019 15:53, Nils Hölscher wrote:
> I observed all Modules loading in the last fdt pass.
> The reason was, nexus bus loading with BUS_PASS_DEFAULT.
> ---
> rtemsbsd/rtems/rtems-kernel-nexus.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/rtemsbsd/rtems/rtems-kernel-nexus.c
> b/rtemsbsd/rtems/rtems-kernel-nexus.c
> index 15b0f84d..197f23f6 100644
> --- a/rtemsbsd/rtems/rtems-kernel-nexus.c
> +++ b/rtemsbsd/rtems/rtems-kernel-nexus.c
> @@ -394,4 +394,4 @@ static driver_t nexus_driver = {
>
> static devclass_t nexus_devclass;
>
> -DRIVER_MODULE(nexus, root, nexus_driver, nexus_devclass, 0, 0);
> +EARLY_DRIVER_MODULE_ORDERED(nexus, root, nexus_driver, nexus_devclass, 0, 0,
> SI_ORDER_FIRST, BUS_PASS_BUS);
>
In freeBSD some of the nexus devices have a "BUS_PASS_BUS +
BUS_PASS_ORDER_xxx". Did you have a reason to not add a BUS_PASS_ORDER?
For example:
freebsd-org/sys/riscv/riscv/nexus.c:
EARLY_DRIVER_MODULE(nexus_fdt, root, nexus_fdt_driver,
nexus_fdt_devclass, 0, 0, BUS_PASS_BUS + BUS_PASS_ORDER_FIRST);
freebsd-org/sys/arm64/arm64/nexus.c:
EARLY_DRIVER_MODULE(nexus_fdt, root, nexus_fdt_driver,
nexus_fdt_devclass, 0, 0, BUS_PASS_BUS + BUS_PASS_ORDER_FIRST);
freebsd-org/sys/mips/mips/nexus.c:
EARLY_DRIVER_MODULE(nexus, root, nexus_driver, nexus_devclass, 0, 0,
BUS_PASS_BUS + BUS_PASS_ORDER_EARLY);
Best regards
Christian
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
