From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 BB92581EBA for ; Thu, 17 Nov 2016 23:04:10 -0800 (PST) Received: by mail-it0-x229.google.com with SMTP id j191so17020254ita.1 for ; Thu, 17 Nov 2016 23:04:16 -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=Vidx9TUyxr5qsJbGzu5jSLtlFlwKw3DxPqiU595UaXU=; b=FpCqk82ZscuQRsnQZ7vZVgJWVUfe6JOmt0LNZYTbReZYdB43wjajcLJTEkNbKZvE0D U7qc9C/66djV4W7tdGAIYui8gDhChhL5jgFOPzWwJsF1r7dgCrGZjmny1K60LDZoCxSb Lq/KSBiYngPVku0oreSlWuP5jnwNGBdLGQraA= 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=Vidx9TUyxr5qsJbGzu5jSLtlFlwKw3DxPqiU595UaXU=; b=PE/GzHR0pLuaSgKoToNoPZLElJ+vszxiqXoFFT75RT1JI5gwx34Q98Y1Gflft8qwu6 MqEdYK3TPb8ARogj92AKD1xOoAYP3XlS8kuCCdztOC1AoE6KH+pdys/LsyB8dLZU8InM GCYym/7/x9hDqKwXw4ZJLF0jAjI4vKHdxm/+HaY8jhCiIcOWT+I3Dw8R6pnNA68gWvms wrHTb313hGLZfhhWti+jYNwu5iHBQnnyvnsyGoJpyc1r+Lc+WwNGDuqxq2vI4OQ+KlvN vHTHpxcew3mWFUFW7WJ+R2ogTSV9lh1emKIsFN3DZr/a+CA71TWvZ72kwfabM8sXd16K v1VQ== X-Gm-Message-State: ABUngvcnijnHn3NhDwLTKcXZNydgHZKwYwPOCrcn/IMZ+wMswsQwh1YAqydzIae7DgGH7T1YhCENs544VPbKuMuD X-Received: by 10.36.14.131 with SMTP id 125mr16114766ite.59.1479452655570; Thu, 17 Nov 2016 23:04:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.59.147 with HTTP; Thu, 17 Nov 2016 23:04:14 -0800 (PST) In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D58E80120@SHSMSX104.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> <734D49CCEBEEF84792F5B80ED585239D58E80120@SHSMSX104.ccr.corp.intel.com> From: Ard Biesheuvel Date: Fri, 18 Nov 2016 07:04:14 +0000 Message-ID: To: "Ni, Ruiyu" Cc: "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 07:04:11 -0000 Content-Type: text/plain; charset=UTF-8 On 18 November 2016 at 06:13, Ni, Ruiyu wrote: > > > Regards, > Ray > >>-----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 ; 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 should 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, 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 model has priority rules and protocols to >>decide which driver gets precedence. I don't see how it should be any >>different here. > > I see they are different. Based on PciIo, the *HCI drivers can query > additional information from PCI CFG header, instead of just using > the PCI class code. > > But with the NonDiscoverableDevice protocol, there is no additional > information can help the *HCI drivers decide which to manage. > > I don't see any practical negative point which prevents degrading > NonDiscoverableDevice protocol to NonDiscoverable*Pci*Protocol. > After all, as I said, all *HCI drivers are based on PciIo. > Yes the *drivers* are based on PCI. But that does not make the *devices* PCI devices. That is the whole problem we are trying to deal with. So describing the non-PCI devices as PCI devices is incorrect imo. The fact that we will use PCI drivers to drive non-PCI devices is an implementation detail of EDK2, and is a property of the *driver* side not the *device* side. So using PCI class codes etc to wire up the correct driver should be local to the driver, and not pollute the description of the device. For example, if we would ever split the AHCI driver into a AHCI part and a PCI part (which I know is unlikely to occur), I would want the non-PCI AHCI driver to be used with the same protocol. Perhaps that means we need a protocol for each type of device rather than an enum? In any case, putting PCI-specific metadata into the device description makes the situation worse, because now both the *device* and the *driver* side are forced to use PCI internals to describe devices that have nothing to do with PCI Thanks, Ard.