Is the idea to refactor PciSioSerialDxe to extract functions that access the HW and wrap it in the SerialPortLib instance? That solution would still save us some maintenance cost. However exploring the idea further I see following problems:

1. Relying on driver binding produces a fairly nice flow: platform driver initializes enough platform HW for UART to work -> platform driver calls ConnectController -> driver initializes UART. With SerialDxe a depex would have to be injected through our instance of SerialPortLib to stop the SerialDxe dispatch until platform driver made the platform ready.
2. I am wondering how it would work in case we want to allow dynamic configuration of debug port(basically selecting which UART controller would be used). With current solution we can select which one(or which ones) will be used by simply installing and connecting corresponding handles. With library solution I guess library would have to locate some protocols(possibly the same PCI_IO and DEVICE_PATH) that were installed by platform driver. It would also need to install notify on those protocols installation in case platform wants to add more uarts later on in the boot flow.
3. We still end up with 2 UART drivers in flash since PciSioSerialDxe is needed for PCI UARTs.

I also think this solution is comparable in effort to refactoring the PciSioSerialDxe so that it doesn't use driver binding when used as a DXE driver. In this solution driver would have one .c file for code with driver binding and one .c file for code when everything is done in entry point, it would still use DEVICE_PATH and PCI_IO/SIO. While I still think using the driver as is in DXE is best for us, in case that solution gets blocked I would like to understand if everyone would be ok with such refactoring.

Thanks,
Mateusz

_._,_._,_

Groups.io Links:

You receive all messages sent to this group.

_._,_._,_