From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 A760981EBA for ; Thu, 17 Nov 2016 22:57:02 -0800 (PST) Received: by mail-it0-x22b.google.com with SMTP id y23so16928057itc.0 for ; Thu, 17 Nov 2016 22:57:08 -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:content-transfer-encoding; bh=Z76pkYJ31q0NedDSsdxHeRBYTXuDI0xPe+zaWL0UPBk=; b=JEmZLvuRCuISg2tSbyIcUoV2FnfT4rslziVFD5m4jU0BuDo7U3AMuw0dSPaTptwas7 iWpA2kbf5YV0yCjolq0cxQ4b5J3D4halaFCVFKhAvrh1tDwi550AkaWTKaDnWeU8yFVy bzuxfS68OJHfz3SeQX4kYkF7Kj7LgyUmqAuZA= 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:content-transfer-encoding; bh=Z76pkYJ31q0NedDSsdxHeRBYTXuDI0xPe+zaWL0UPBk=; b=aJteejudrTmVQCJGoA/4cXgD27FrfOEC6oygopmmCLvM4Oh0/3K100lsvV4tdbhuIi WJ4u6U7k2vUPRVu55+JE2sOtJi+4I/NElHNW6SbFaoiBIgwDvVOBIRwDfwpDGoMB1U4x XcOKoO+nyXe11Nryg47WxXcyI5DsptM+jDXFPYbPdel/ttHcvGhT05JBNDfwDmIdnZXn mauQs9OGUAY2TCGQ+R/31vHp4adhxz6gJlR6At7LP9+EE02ng6yF7b2fi8ByRV3qTSPg nRA9u14kGlzyePT6X16SHSTGfxbbJVUawIF+ZpREXx3XgW7KItiIW2k8j45Kdzm4YOzH ggSg== X-Gm-Message-State: AKaTC03Ozc7phJ80nYd1TmiTgmxOEwilFqnf6qIAPyD+C2qQqZkpkE+D+xzcv+RsrD3im1aolbv1t5zBu4oY+gun X-Received: by 10.107.18.39 with SMTP id a39mr6845674ioj.45.1479452227379; Thu, 17 Nov 2016 22:57:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.59.147 with HTTP; Thu, 17 Nov 2016 22:57:06 -0800 (PST) In-Reply-To: <7F1BAD85ADEA444D97065A60D2E97EE566E521B3@SHSMSX101.ccr.corp.intel.com> References: <1479315571-14953-1-git-send-email-ard.biesheuvel@linaro.org> <1479315571-14953-2-git-send-email-ard.biesheuvel@linaro.org> <20161116174848.GC27644@bivouac.eciton.net> <734D49CCEBEEF84792F5B80ED585239D58E7C6D4@SHSMSX104.ccr.corp.intel.com> <4E810E45-F1CC-429C-B3F4-FC6182F7D9B2@linaro.org> <734D49CCEBEEF84792F5B80ED585239D58E7D6F5@SHSMSX104.ccr.corp.intel.com> <734D49CCEBEEF84792F5B80ED585239D58E7FCF6@SHSMSX104.ccr.corp.intel.com> <7F1BAD85ADEA444D97065A60D2E97EE566E521B3@SHSMSX101.ccr.corp.intel.com> From: Ard Biesheuvel Date: Fri, 18 Nov 2016 06:57:06 +0000 Message-ID: To: "Tian, Feng" Cc: "Ni, Ruiyu" , "Kinney, Michael D" , "edk2-devel@lists.01.org" , "Gao, Liming" , "afish@apple.com" , Leif Lindholm Subject: Re: [PATCH v3 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: Fri, 18 Nov 2016 06:57:02 -0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 18 November 2016 at 05:24, Tian, Feng wrote: > Ard, > > I have another question. > > Is it the only way to specify device type in below enum? Looks like it wi= ll be changed often. Is it possible to make use of DevicePath node? Of cour= se, I have no good idea to handle AMBA controller... > How would you use a device path node to do that? I think we will always need a mapping somewhere in the code between numbers and AHCI/EHCI/etc types, given that the device itself cannot be interrogated to provide this information. If we can do the same with a device path, I'm happy to investigate, but I will need some help understanding how that would work > +// > +// Data Types > +// > +typedef enum { > + NonDiscoverableDeviceTypeAmba, > + NonDiscoverableDeviceTypeOhci, > + NonDiscoverableDeviceTypeUhci, > + NonDiscoverableDeviceTypeEhci, > + NonDiscoverableDeviceTypeXhci, > + NonDiscoverableDeviceTypeAhci, > + NonDiscoverableDeviceTypeSdhci, > + NonDiscoverableDeviceTypeUfs, > + NonDiscoverableDeviceTypeNvme, > + NonDiscoverableDeviceTypeMax, > +} NON_DISCOVERABLE_DEVICE_TYPE; > > Thanks > Feng > > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Ar= d Biesheuvel > Sent: Friday, November 18, 2016 12:59 PM > To: Ni, Ruiyu > Cc: Kinney, Michael D ; edk2-devel@lists.01.o= rg; Gao, Liming ; afish@apple.com; Leif Lindholm > Subject: Re: [edk2] [PATCH v3 1/5] MdeModulePkg: introduce non-discoverab= le device protocol > > On 18 November 2016 at 02:11, Ni, Ruiyu wrote: >> >> >> Regards, >> Ray >> >>>-----Original Message----- >>>From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] >>>Sent: Thursday, November 17, 2016 6:43 PM >>>To: Ni, Ruiyu >>>Cc: Kinney, Michael D ; >>>edk2-devel@lists.01.org; Gao, Liming ; >>>afish@apple.com; Leif Lindholm >>>Subject: Re: [edk2] [PATCH v3 1/5] MdeModulePkg: introduce >>>non-discoverable device protocol >>> >>> >>>> On 17 Nov 2016, at 08:52, Ni, Ruiyu wrote: >>>> >>>> >>>> >>>> Thanks/Ray >>>> >>>>> -----Original Message----- >>>>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf >>>>> Of Ard Biesheuvel >>>>> Sent: Thursday, November 17, 2016 2:07 PM >>>>> To: Ni, Ruiyu >>>>> Cc: Kinney, Michael D ; edk2- >>>>> devel@lists.01.org; Gao, Liming ; >>>>> afish@apple.com; Leif Lindholm >>>>> Subject: Re: [edk2] [PATCH v3 1/5] MdeModulePkg: introduce non- >>>>> discoverable device protocol >>>>> >>>>> >>>>> >>>>>> On 17 Nov 2016, at 02:53, Ni, Ruiyu wrote: >>>>>> >>>>>> Ard, >>>>>> I have two comments in below. >>>>>> >>>>>> Thanks/Ray >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On >>>>>>> Behalf Of Leif Lindholm >>>>>>> Sent: Thursday, November 17, 2016 1:49 AM >>>>>>> To: Ard Biesheuvel >>>>>>> Cc: Ni, Ruiyu ; edk2-devel@lists.01.org; >>>>>>> afish@apple.com; Gao, Liming ; Kinney, >>>>>>> Michael D >>>>>>> Subject: Re: [edk2] [PATCH v3 1/5] MdeModulePkg: introduce non- >>>>>>> discoverable device protocol >>>>>>> >>>>>>>> On Wed, Nov 16, 2016 at 04:59:27PM +0000, Ard Biesheuvel wrote: >>>>>>>> Introduce a protocol that can be exposed by a platform for >>>>>>>> devices that are not discoverable, usually because they are >>>>>>>> wired straight to the memory bus rather than to an enumerable bus = like PCI or USB. >>>>>>>> >>>>>>>> Contributed-under: TianoCore Contribution Agreement 1.0 >>>>>>>> Signed-off-by: Ard Biesheuvel >>>>>>>> --- >>>>>>>> MdeModulePkg/Include/Protocol/NonDiscoverableDevice.h | 90 >>>>>>> ++++++++++++++++++++ >>>>>>>> MdeModulePkg/MdeModulePkg.dec | 3 + >>>>>>>> 2 files changed, 93 insertions(+) >>>>>>>> >>>>>>>> diff --git >>>>>>>> a/MdeModulePkg/Include/Protocol/NonDiscoverableDevice.h >>>>>>>> b/MdeModulePkg/Include/Protocol/NonDiscoverableDevice.h >>>>>>>> new file mode 100644 >>>>>>>> index 000000000000..47ed841b407b >>>>>>>> --- /dev/null >>>>>>>> +++ b/MdeModulePkg/Include/Protocol/NonDiscoverableDevice.h >>>>>>>> @@ -0,0 +1,90 @@ >>>>>>>> +/** @file >>>>>>>> + Protocol to describe devices that are not on a discoverable >>>>>>>> +bus >>>>>>>> + >>>>>>>> + Copyright (c) 2016, Linaro, Ltd. All rights reserved.
>>>>>>>> + >>>>>>>> + This program and the accompanying materials are licensed and >>>>>>>> + made available under the terms and conditions of the BSD >>>>>>>> + License which accompanies this distribution. The full text of >>>>>>>> + the license may be found at >>>>>>>> + http://opensource.org/licenses/bsd-license.php >>>>>>>> + >>>>>>>> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS >>>>> IS" >>>>>>>> + BASIS, WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, >>>>>>> EITHER EXPRESS OR IMPLIED. >>>>>>>> + >>>>>>>> +**/ >>>>>>>> + >>>>>>>> +#ifndef __NON_DISCOVERABLE_DEVICE_H__ #define >>>>>>>> +__NON_DISCOVERABLE_DEVICE_H__ >>>>>>>> + >>>>>>>> +#include >>>>>>>> + >>>>>>>> +#define EDKII_NON_DISCOVERABLE_DEVICE_PROTOCOL_GUID \ >>>>>>>> + { 0x0d51905b, 0xb77e, 0x452a, {0xa2, 0xc0, 0xec, 0xa0, 0xcc, >>>>>>>> +0x8d, 0x51, 0x4a } } >>>>>> >>>>>> 1. Can you add "PCI" keyword into the protocol name? >>>>>> e.g.: EDKII_NON_DISCOVERABLE_PCI_DEVICE_PROTOCOL_GUID >>>>>> >>>>> >>>>> No. This protocol does not describe pci devices, and it is a >>>>> peculiarity of the >>>>> edk2 driver stack that some non-pci devices can only be driven by pci= drivers. >>>>> >>>>> in other words, pci is part of the /driver/ side, and it is >>>>> perfectly possible for, e.g., a non-discoverable ahci device to be >>>>> driven by a different non-pci driver in the future. >>>>> >>>> >>>> I see. So some types of devices are handled by the current >>>> NonDiscoveablePciDevice driver, and some other types of devices may >>>> be handled by a future NonDiscoverableXXXDevice driver. >>>> Now since the AHCI type is already handled by the >>>> NonDiscoverablePciDevice driver, when there is a new >>>> NonDiscoverableXXXDevice driver, how can the two know whether it shoul= d manage the AHCI type device or not? >>> >>>Good question. But how does the UEFI driver model deal with that? What >>>happens if i have two drivers that both support the Ahci Pci class codes= ? >> PCI CFG header contains VendorID/DeviceID fields which can be used to >> distinguish them. >> > > No, that is not what I mean. > > Your question is how we should deal with multiple drivers that support, f= or instance, the AHCI non-discoverable device type. My answer is that this = is not any different from a platform configuration that has more than one P= CI I/O based driver that supports the AHCI PCI class codes. The UEFI driver= model has priority rules and protocols to decide which driver gets precede= nce. I don't see how it should be any different here. > > Thanks, > Ard. > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel