Terminal Binding to Serial IO Protocol

Terminal Binding to Serial IO Protocol

[Cohen, Eugene]

Hi edk2 community, it's been a while.

We have a situation where we need to use instances of the SERIAL_IO_PROTOCOL to talk to hardware devices that are not part of a console.  As written today TerminalDxe's driver binding will consume any handle that implements the SERIAL_IO_PROTOCOL (like in a BDS connect-all case).  Clearly this is problematic when the device on the other side is not a terminal.  

The UEFI Specification does not limit the Serial IO protocol to console/terminal only applications yet the edk2 implementation of TerminalDxe effectively does this.

I'm looking for some advice on how to resolve this.

I think it's important for the BDS connect-all case to keep working so I don't think customizing the driver connect process at a BDS level is a good solution.

The UEFI Driver Binding architecture has a capable precedence system for determining which drivers get to control which devices (binding versioning, bus overrides, platform overrides) but I don't think this a proper use of the system since I understand that this system was intended for choosing the better of two possible drivers for the hardware (like a motherboard versus option rom for the same PCI network adapter).  In this case having TerminalDxe trying to connect to a non-terminal device isn't slightly worse, it's broken.  

We need a way to differentiate serial port types in the connect process.  Since the Serial IO protocol can't be used to detect what's on the other side we need to get the information from the platform with it having a list like:

Serial 0: console
Serial 1: fax
Serial 2: keyboard
Serial 3: mouse
Serial 4: console

so we would only want TerminalDxe to connect to instance 0 and 4 and leave the others alone.

Any ideas on how to best do this?

Thanks,

Eugene