From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id A131674003D for ; Tue, 27 Feb 2024 17:15:58 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=0dRzVp4GHyBuDUTWFCLUM7XeVGee60udWtojZfWUYPs=; c=relaxed/simple; d=groups.io; h=Subject:To:From:User-Agent:MIME-Version:Date:References:In-Reply-To:Message-ID:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type; s=20140610; t=1709054157; v=1; b=bp+Kjbljh8B3yJYMgyRRr8pAi4ip25/+nk0MFn0FMMDM+R5h6p3KfBc5XllPcLBS5dBLQJC8 TpUtg1UFRzZ+0ld0rDyRr/ndcpgKLi9Kz+bW4gxoEqBLZa0450Tn4n5TUxV8XKyuFg/wMdTPJN5 tdrtyQ/vtuxyYNqK5573pj8I= X-Received: by 127.0.0.2 with SMTP id jMDlYY7687511xdiWuVCrKNo; Tue, 27 Feb 2024 09:15:57 -0800 Subject: Re: [edk2-devel] [PATCH 1/1] MdeModulePkg: Load Serial driver earlier in DXE To: Laszlo Ersek ,devel@edk2.groups.io From: "Albecki, Mateusz" X-Originating-Location: Olsztyn, Warmia-Masuria, PL (134.191.221.84) X-Originating-Platform: Linux Chrome 116 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Tue, 27 Feb 2024 09:15:56 -0800 References: <643d0b1f-1f90-97ea-721d-3462f74d14a1@redhat.com> In-Reply-To: <643d0b1f-1f90-97ea-721d-3462f74d14a1@redhat.com> Message-ID: <21276.1709054156537513390@groups.io> Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,mateusz.albecki@intel.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: o3rOZZc4s9s8p2RtpzYznKpdx7686176AA= Content-Type: multipart/alternative; boundary="IgliHEAQE7WWZ2WLmMrw" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=bp+Kjblj; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=intel.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io --IgliHEAQE7WWZ2WLmMrw Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Is the idea to refactor PciSioSerialDxe to extract functions that access th= e HW and wrap it in the SerialPortLib instance? That solution would still s= ave us some maintenance cost. However exploring the idea further I see foll= owing problems: 1. Relying on driver binding produces a fairly nice flow: platform driver i= nitializes enough platform HW for UART to work -> platform driver calls Con= nectController -> driver initializes UART. With SerialDxe a depex would hav= e to be injected through our instance of SerialPortLib to stop the SerialDx= e dispatch until platform driver made the platform ready. 2. I am wondering how it would work in case we want to allow dynamic config= uration of debug port(basically selecting which UART controller would be us= ed). With current solution we can select which one(or which ones) will be u= sed 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 wou= ld also need to install notify on those protocols installation in case plat= form 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 ne= eded for PCI UARTs. I also think this solution is comparable in effort to refactoring the PciSi= oSerialDxe 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 bindin= g 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 li= ke to understand if everyone would be ok with such refactoring. Thanks, Mateusz -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#116055): https://edk2.groups.io/g/devel/message/116055 Mute This Topic: https://groups.io/mt/104469297/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- --IgliHEAQE7WWZ2WLmMrw Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Is the idea to refactor PciSioSerialDxe to extract functions that access th= e HW and wrap it in the SerialPortLib instance? That solution would still s= ave us some maintenance cost. However exploring the idea further I see foll= owing problems:

1. Relying on driver binding produces a fairly n= ice 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 S= erialPortLib 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 c= ontroller 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 pr= otocols(possibly the same PCI_IO and DEVICE_PATH) that were installed by pl= atform driver. It would also need to install notify on those protocols inst= allation 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 PciSioSerialDx= e is needed for PCI UARTs.

I also think this solution is compara= ble in effort to refactoring the PciSioSerialDxe so that it doesn't use dri= ver binding when used as a DXE driver. In this solution driver would have o= ne .c file for code with driver binding and one .c file for code when every= thing 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:

=20 You receive all messages sent to this group. =20 =20

View/Reply Online (#116055) | =20 | Mute= This Topic | New Topic
Your Subscriptio= n | Contact Group Owner | Unsubscribe [rebecca@openfw.io]

_._,_._,_
--IgliHEAQE7WWZ2WLmMrw--