From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id D0DAC81EE5 for ; Thu, 17 Nov 2016 21:24:48 -0800 (PST) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP; 17 Nov 2016 21:24:53 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,655,1473145200"; d="scan'208";a="32124996" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga004.jf.intel.com with ESMTP; 17 Nov 2016 21:24:53 -0800 Received: from fmsmsx154.amr.corp.intel.com (10.18.116.70) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 17 Nov 2016 21:24:53 -0800 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by FMSMSX154.amr.corp.intel.com (10.18.116.70) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 17 Nov 2016 21:24:52 -0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.96]) with mapi id 14.03.0248.002; Fri, 18 Nov 2016 13:24:49 +0800 From: "Tian, Feng" To: Ard Biesheuvel , "Ni, Ruiyu" CC: "Kinney, Michael D" , "edk2-devel@lists.01.org" , "Gao, Liming" , "afish@apple.com" , Leif Lindholm , "Tian, Feng" Thread-Topic: [edk2] [PATCH v3 1/5] MdeModulePkg: introduce non-discoverable device protocol Thread-Index: AQHSQCrhi0OUwc/voky3wz5P0wSZY6DbXOsAgACYTQCAADX9AIAAHWGAgAAvvwCAAQNngIAALueAgACMmTA= Date: Fri, 18 Nov 2016 05:24:49 +0000 Message-ID: <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> In-Reply-To: Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 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 05:24:49 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ard, I have another question. Is it the only way to specify device type in below enum? Looks like it will= be changed often. Is it possible to make use of DevicePath node? Of course= , I have no good idea to handle AMBA controller... +// +// 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 Ard = Biesheuvel Sent: Friday, November 18, 2016 12:59 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 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 ;=20 >>edk2-devel@lists.01.org; Gao, Liming ;=20 >>afish@apple.com; Leif Lindholm >>Subject: Re: [edk2] [PATCH v3 1/5] MdeModulePkg: introduce=20 >>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=20 >>>> Of Ard Biesheuvel >>>> Sent: Thursday, November 17, 2016 2:07 PM >>>> To: Ni, Ruiyu >>>> Cc: Kinney, Michael D ; edk2-=20 >>>> devel@lists.01.org; Gao, Liming ;=20 >>>> afish@apple.com; Leif Lindholm >>>> Subject: Re: [edk2] [PATCH v3 1/5] MdeModulePkg: introduce non-=20 >>>> 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=20 >>>>>> Behalf Of Leif Lindholm >>>>>> Sent: Thursday, November 17, 2016 1:49 AM >>>>>> To: Ard Biesheuvel >>>>>> Cc: Ni, Ruiyu ; edk2-devel@lists.01.org;=20 >>>>>> afish@apple.com; Gao, Liming ; Kinney,=20 >>>>>> Michael D >>>>>> Subject: Re: [edk2] [PATCH v3 1/5] MdeModulePkg: introduce non-=20 >>>>>> 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=20 >>>>>>> devices that are not discoverable, usually because they are=20 >>>>>>> wired straight to the memory bus rather than to an enumerable bus l= ike 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=20 >>>>>>> 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=20 >>>>>>> +bus >>>>>>> + >>>>>>> + Copyright (c) 2016, Linaro, Ltd. All rights reserved.
>>>>>>> + >>>>>>> + This program and the accompanying materials are licensed and=20 >>>>>>> + made available under the terms and conditions of the BSD=20 >>>>>>> + License which accompanies this distribution. The full text of=20 >>>>>>> + the license may be found at =20 >>>>>>> + 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=20 >>>>>>> +__NON_DISCOVERABLE_DEVICE_H__ >>>>>>> + >>>>>>> +#include >>>>>>> + >>>>>>> +#define EDKII_NON_DISCOVERABLE_DEVICE_PROTOCOL_GUID \ >>>>>>> + { 0x0d51905b, 0xb77e, 0x452a, {0xa2, 0xc0, 0xec, 0xa0, 0xcc,=20 >>>>>>> +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=20 >>>> 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=20 >>>> perfectly possible for, e.g., a non-discoverable ahci device to be=20 >>>> driven by a different non-pci driver in the future. >>>> >>> >>> I see. So some types of devices are handled by the current=20 >>> NonDiscoveablePciDevice driver, and some other types of devices may=20 >>> be handled by a future NonDiscoverableXXXDevice driver. >>> Now since the AHCI type is already handled by the=20 >>> NonDiscoverablePciDevice driver, when there is a new=20 >>> NonDiscoverableXXXDevice driver, how can the two know whether it should= manage the AHCI type device or not? >> >>Good question. But how does the UEFI driver model deal with that? What=20 >>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=20 > distinguish them. > No, that is not what I mean. Your question is how we should deal with multiple drivers that support, for= 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 PCI= I/O based driver that supports the AHCI PCI class codes. The UEFI driver m= odel has priority rules and protocols to decide which driver gets precedenc= e. 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