From mboxrd@z Thu Jan 1 00:00:00 1970 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.web08.3940.1650374091847719867 for ; Tue, 19 Apr 2022 06:14:52 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=I+kCzFqf; spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1650374090; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ksqU5C5oamOv/7B+drzvrFePcfbx2OGrgJTM0WGQQIU=; b=I+kCzFqf4y9D8mwR27mmHsewrRtq9WVVnb9iPb6rkrfPBORWf598Pl8Y7XuedRr7qAUJe8 4W8X78Do7OWjZrOMKH2JZPU2Ax5NwE7XAo3d4tz8kNAcFaoSIpe4EBc4FBcPibvjO4NQ5h xGt4pV1heG9zf5vdFmw8oFhHabmBRR8= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-465-exKIX12wMjOP5DRguPm04A-1; Tue, 19 Apr 2022 09:14:49 -0400 X-MC-Unique: exKIX12wMjOP5DRguPm04A-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 23BA1811E78; Tue, 19 Apr 2022 13:14:49 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.9]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D643740314B; Tue, 19 Apr 2022 13:14:48 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 15C0F18000B2; Tue, 19 Apr 2022 15:14:47 +0200 (CEST) Date: Tue, 19 Apr 2022 15:14:47 +0200 From: "Gerd Hoffmann" To: devel@edk2.groups.io, abner.chang@hpe.com Cc: Leif Lindholm , Ard Biesheuvel , Jordan Justen , Jian J Wang , Ray Ni , Hao A Wu , Jiewen Yao , Liming Gao , Pawel Polawski , Oliver Steffen , Ard Biesheuvel Subject: Re: [edk2-devel] [PATCH v3 1/6] MdeModulePkg/PciHostBridge: io range is not mandatory Message-ID: <20220419131447.uglm3edvgawxfaky@sirius.home.kraxel.org> References: <20220407093304.1551182-1-kraxel@redhat.com> <20220407093304.1551182-2-kraxel@redhat.com> <20220413081216.l6j33a7emc3yy2qq@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.85 on 10.11.54.10 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Apr 13, 2022 at 01:44:55PM +0000, Abner Chang wrote: > > > > -----Original Message----- > > From: Gerd Hoffmann > > Sent: Wednesday, April 13, 2022 4:12 PM > > To: devel@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist) > > > > Cc: Leif Lindholm ; Ard Biesheuvel > > ; Jordan Justen ; > > Jian J Wang ; Ray Ni ; Hao A Wu > > ; Jiewen Yao ; Liming Gao > > ; Pawel Polawski ; > > Oliver Steffen ; Ard Biesheuvel > > Subject: Re: [edk2-devel] [PATCH v3 1/6] MdeModulePkg/PciHostBridge: io > > range is not mandatory > > > > Hi, > > > > > > diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c > > > > b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c > > > > index b20bcd310ad5..51a3b987967f 100644 > > > > --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c > > > > +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c > > > > @@ -1085,6 +1085,9 @@ NotifyPhase ( > > > > RootBridge->ResAllocNode[Index].Base = BaseAddress; > > > > RootBridge->ResAllocNode[Index].Status = ResAllocated; > > > > DEBUG ((DEBUG_INFO, "Success\n")); > > > > + } else if (Index == TypeIo) { > > > How do we tell the BaseAddress is set to UINT64 because "(BaseAddress < > > Limit)" or "gDS->AllocateMemorySpace()" returns error in AllocateResource() > > for TypeIo ? > > > > Does the reason matter? > > > > io resources are optional, so if there is no io address space available > > it should not be a fatal error, no matter what the root cause is. > If the device requires I/O resource however the io address space is not available, shouldn't this an error? How do you figure that? The PCIe spec requires devices being fully functional without io address space resources, so in theory this case should not exist. In practice things are not that simple unfortunately. But the pure presence of an io bar doesn't imply it is actually required. I think we can't do much about that at this point. An actual driver for the device which has more knowledge about the device would be in a better position to figure whenever not having io resources is a fatal error or not. > > > Is "else if (Index == TypeIo && RootBridge->Io.Base == MAX_UINT64)" > > more reliable? Or I missed the code logic here? > > > > I think it is not needed, but if you think it is better that way I can > > change it. > This is more clear to reader. That means that we don't have to treat it as an error on the TypeIo if the base address for it is MAX_UINT64. Ok, I'll change it. take care, Gerd