public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Albecki, Mateusz" <mateusz.albecki@intel.com>
To: Laszlo Ersek <lersek@redhat.com>,devel@edk2.groups.io
Subject: Re: [edk2-devel] [PATCH 1/1] MdeModulePkg: Load Serial driver earlier in DXE
Date: Tue, 27 Feb 2024 09:15:56 -0800	[thread overview]
Message-ID: <21276.1709054156537513390@groups.io> (raw)
In-Reply-To: <643d0b1f-1f90-97ea-721d-3462f74d14a1@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2184 bytes --]

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.
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]
-=-=-=-=-=-=-=-=-=-=-=-



[-- Attachment #2: Type: text/html, Size: 2638 bytes --]

  reply	other threads:[~2024-02-27 17:15 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-20 12:10 [edk2-devel] [PATCH 0/1] EDK2 Serial driver UART debug print enablement Borzeszkowski, Alan
2024-02-20 12:10 ` [edk2-devel] [PATCH 1/1] MdeModulePkg: Load Serial driver earlier in DXE Borzeszkowski, Alan
2024-02-20 17:11   ` Michael D Kinney
2024-02-21 17:15     ` Borzeszkowski, Alan
2024-02-21 20:59       ` Michael D Kinney
2024-02-21 21:59       ` Laszlo Ersek
2024-02-23 15:50         ` Albecki, Mateusz
2024-02-23 22:30           ` Michael D Kinney
2024-02-25 16:18           ` Laszlo Ersek
2024-02-25 16:31             ` Laszlo Ersek
2024-02-26 15:13               ` Albecki, Mateusz
2024-02-26 15:37                 ` Laszlo Ersek
2024-02-27 17:15                   ` Albecki, Mateusz [this message]
2024-02-28 10:12                     ` Laszlo Ersek
2024-02-28 16:27                       ` Albecki, Mateusz
2024-02-29  7:48                         ` Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=21276.1709054156537513390@groups.io \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox