From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id A603A81E53 for ; Tue, 15 Nov 2016 03:29:13 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id q124so165028948itd.1 for ; Tue, 15 Nov 2016 03:29:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tLqhfRDHl9OLZx1DnnRAl9ujY++uPV6ivIZ+6izjzf4=; b=U1C/Sl7E60HuMYRzRZnvsENMeJcyCDIvP/MO5x83vvEkOLWRgq3jttvkRaRkST6DG6 cFG7h4JidxiQ6D5RmZbqjtoczUTG9YRv8wddJgy1amqpt8mag3BEXscNmI/fYmbrlXhp +PkKkKipJtbK3D4ju0wy93qmjw5UNZlu+rSKk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tLqhfRDHl9OLZx1DnnRAl9ujY++uPV6ivIZ+6izjzf4=; b=Rlj4XRuInHiUhvTeoU9DyzkMa2V0VUUkPeXQipxZjj4Hc5tdnLlNnWjuSDB5DfC7i0 kYWumMlzYjq8w2PBKHfgonTp4lPOk48kgXCAXgoTBUN+cIUFBr6RtzKKwYjjhhSJ2ofG HeBKQqcCbrcNIFBkIDvVCZIHc+/Ei1gu1QSVuprNnirHBOSDZwtdf9qmlaOOzrKIlid3 3XiV29ETU7BWkP7BOJCqoRyXtmviX//JircB58hXDlnnPsO3grEQn13tsY+278tbw+p6 XvrKX8ZJ9ZKcSNg9V3q8eO6kiUR5KFGVxltj/9Oq1PLCfIVg0/5n/SGaRHMhVDo9B1OS xw6g== X-Gm-Message-State: ABUngvc4AO0I86qDdw6xgbzX8He1DOv1ifniWw9S62O0bRti1Wb7S8hS94v1KnNN9Dlsqk44cCi2RC+1RKXm4gyr X-Received: by 10.107.25.11 with SMTP id 11mr28823548ioz.138.1479209357375; Tue, 15 Nov 2016 03:29:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.59.147 with HTTP; Tue, 15 Nov 2016 03:29:16 -0800 (PST) In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D58E78565@SHSMSX104.ccr.corp.intel.com> References: <1478173302-22349-1-git-send-email-ard.biesheuvel@linaro.org> <734D49CCEBEEF84792F5B80ED585239D58E78565@SHSMSX104.ccr.corp.intel.com> From: Ard Biesheuvel Date: Tue, 15 Nov 2016 11:29:16 +0000 Message-ID: To: "Ni, Ruiyu" Cc: "edk2-devel@lists.01.org" , "leif.lindholm@linaro.org" , "Kinney, Michael D" , "afish@apple.com" , "Tian, Feng" , "Zeng, Star" Subject: Re: [PATCH v2 1/5] MdeModulePkg: introduce non-discoverable device protocol X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 11:29:13 -0000 Content-Type: text/plain; charset=UTF-8 On 15 November 2016 at 08:31, Ni, Ruiyu wrote: > Ard, > > For the below protocol structure, it assumes that the non-discoverable > PCI device contains only one BAR and the type is limited to USB/AHCI/SD/UFS/NVME > devices. For now, yes. It is quite unusual for such non-enumerable devices to have several MMIO ranges (and I/O ranges do not exist at all on many architectures, except when dealing with real PCI devices where the root complex takes care of the I/O to MMIO translation) > Could we have more types of such kind of device in future? Yes. I actually added AMBA as well, because those devices have a standardized identification register > Could we have a device that contains multiple BAR? Perhaps others could chime in here? The only example of mutiple BARs would be multiple SDHCI slots on the same controller, but those could easily be modeled as separate controllers as well, since they are completely independent. > Could we have a device that contains one BAR but the BAR size is non-default size? > Another good question. I think the best way for now is to extend the protocol to allow it, but only add support to the helper library when the need arises. > I am asking all about this is because I am thinking would it be more flexible to have > platform provide a ACPI resource descriptors and the NonDiscoverableDxe driver > converts the ACPI resource descriptors to PCI BARs? > > You could refer to PciIo.GetBarAttributes() to see how one ACPI resource descriptor > is created for one BAR. > > But please ignore my such concern if there is a spec to describe such non-discoverable > PCI device. > No, there is no such spec, and I think your suggestion is very good. I will investigate. Thanks, Ard.