On Wed, 12 Jun 2019, Mark Cave-Ayland wrote:
OpenBIOS SPARC32 has always maintained a fallback option of an internal TCX driver if an FCode driver cannot be located on the TCX card itself.
Since QEMU's TCX adapter has supported FCode payloads for a long time then we only require this logic for non-QEMU builds. Otherwise we unintentionally install the fallback driver and device node even if the framebuffer card hasn't been installed into the machine.
Signed-off-by: Mark Cave-Ayland mark.cave-ayland@ilande.co.uk
arch/sparc32/init.fs | 7 +++++-- drivers/sbus.c | 11 +++++++++++ 2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/sparc32/init.fs b/arch/sparc32/init.fs index 814c720..5e8805b 100644 --- a/arch/sparc32/init.fs +++ b/arch/sparc32/init.fs @@ -78,6 +78,9 @@ defer ignore-dfault
\ Load TCX FCode driver blob [IFDEF] CONFIG_DRIVER_SBUS
- -1 value tcx-driver-fcode
- " QEMU,tcx.bin" $encode-file to tcx-driver-fcode
- [IFDEF] CONFIG_QEMU
- [ELSE]
- -1 value tcx-driver-fcode
- " QEMU,tcx.bin" $encode-file to tcx-driver-fcode
- [THEN]
[THEN]
It looks strange that the driver is called QEMU,tcx but is not used on QEMU. Does it make sense to use it when not in QEMU at all? Should it be completely removed instead or maybe renamed to some other name when it's not related to QEMU any more?
Also the commit message says that the problem is that driver should not be installed when TCX hardware is not present so maybe you should test for hardware presence instead of QEMU or not which may be the wrong conditional to decide if the driver is needed or not if I got this correctly.
(But it's possible I haven't understood something in which case just disregard my comment.)
Regards, BALATON Zoltan