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 D8F247803CD for ; Sun, 25 Feb 2024 16:31:59 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=R++Poal4BmgHhAeAso3/aQHdenMvm11aHLhW/zMqgBM=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20140610; t=1708878718; v=1; b=jxOSiZcKe/HfZ+uSj2lnAnGSuQG4UuwBb7i3WPtkowHRQ7jP56F1bXglJrkDJHGMbMUcH7N4 cKSP6ZQ68WOSTRLSpm20JamV1dYNosKuR592TD8dbPO3IVvBwOf5twEaKYj/rjXOZiZg6pvNMPG 4uBGA9rtrkuFoylVZYmDektc= X-Received: by 127.0.0.2 with SMTP id GQHOYY7687511xRfGX0hDIRb; Sun, 25 Feb 2024 08:31:58 -0800 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web11.328.1708878717514130684 for ; Sun, 25 Feb 2024 08:31:57 -0800 X-Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-671-7VE-349pM5eBrjVbqbzGlQ-1; Sun, 25 Feb 2024 11:31:53 -0500 X-MC-Unique: 7VE-349pM5eBrjVbqbzGlQ-1 X-Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 83DAC102020E; Sun, 25 Feb 2024 16:31:53 +0000 (UTC) X-Received: from [10.39.192.57] (unknown [10.39.192.57]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 02D102166B33; Sun, 25 Feb 2024 16:31:52 +0000 (UTC) Message-ID: Date: Sun, 25 Feb 2024 17:31:51 +0100 MIME-Version: 1.0 Subject: Re: [edk2-devel] [PATCH 1/1] MdeModulePkg: Load Serial driver earlier in DXE From: "Laszlo Ersek" To: devel@edk2.groups.io, mateusz.albecki@intel.com Cc: Michael Kinney References: <5914.1708703400468529849@groups.io> <7a99d4e0-9fbb-9c9c-b82a-6425e1b9c9ea@redhat.com> In-Reply-To: <7a99d4e0-9fbb-9c9c-b82a-6425e1b9c9ea@redhat.com> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com 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,lersek@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: DUWSOQZFLiLZoCbyrFVj1eEfx7686176AA= Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=jxOSiZcK; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.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 On 2/25/24 17:18, Laszlo Ersek wrote: > ... Ah, okay! This is the point where I re-read your steps, and now I > see the actual breakage. >=20 > It is your step #2. >=20 > Placing the PciSioSerialDxe driver -- which is a UEFI driver that > follows the UEFI driver model, and has a long list of dependencies on > the architectural protocols -- in the APRIORI DXE file of the firmware > volume(s) *completely violates* the DXE dispatch order. >=20 > I wrote above: >=20 > How do you ensure that step (4) happens *both* early enough *and* > late enough? >=20 > You must do step (4) *late enough* for PciSioSerialDxe to have a > fleeting chance to be dispatched by the DXE dispatcher (due to arch > protocol deps), and *early enough* for your key modules to find > SERIAL_IO_PROTOCOL (from PciSioSerialDxe) via DebugLib, in order to > produce actual debug messages. >=20 > And your step#2 is the answer to that: you violate the standard DXE > dispatch order, by *overriding* the UEFI arch protocols depex in > PciSioSerialDxe, by placing the driver in the APRIORI DXE file. >=20 > The APRIORI DXE file is *only* appropriate to use when you have > *platform DXE* drivers that, for some reason, cannot be ordered > deterministically correctly, by way of depexes, against other platform > DXE drivers. APRIORI DXE is always a last resort; it serves as a crutch > when the DEPEX language is simply not expressive enough for a given > platform; APRIORI DXE is not license to *override* existent (and > standard!) depexes. I've looked again at the patch. It introduces a variant of PciSioSerialDxe that is a DXE_DRIVER, and has [Depex] TRUE This means that step#2 (=3D APRIORI DXE) doesn't actually override a UEFI driver's depex -- therefore I must agree that step#2 in itself does not violate DXE dispatch order. However, I continue to object to step (4), that is, to ConnectController() being called by a platform module way before BDS is entered. That's not how the driver binding protocol and the ConnectController() boot service were intended, to my understanding. Laszlo -=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 (#115932): https://edk2.groups.io/g/devel/message/115932 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-