From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 7BCCF81EBA for ; Fri, 18 Nov 2016 00:52:37 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id c20so17554832itb.0 for ; Fri, 18 Nov 2016 00:52:42 -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=er/RzqBvaTCZWEPUW94exdgJ8aWZfiMOfuXr2R2s+Ug=; b=Vw9rsneGE2PUcULHrrAKEZGRoz8WWQsrK9EiXqGSqbnRFBOeYe+Sa0iJVLIfhK71H3 igRyyN4v8fbFU8JdoBbfs6BkKfBGsUkyliwMLLrtP7rIkKH5sn5oPDYJEMarSzyNcwwm p6l5PgmeYDqivqZJREciLYhbvqz2rCrgfPumI= 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=er/RzqBvaTCZWEPUW94exdgJ8aWZfiMOfuXr2R2s+Ug=; b=F30M7xNMiU6Vc/BpDMVvpdfBcgKTss5fCL3WEPc7xDj0mB6yR5lHMgd4LUM3mLq+HL pPO9Pk3GRO/P/bLkg6vSJrC9HaSk39JAiKg5zMrbNy1tHvRK1Ve9DUEGquPffFAqrxYp J7ixG2asRBP41oO9W7nBLPuQdyKqqDjqP3PvCUsIiLhcAHQ3Wb4v6lfDxXdiLLEaRYUD zSGjibsC7QKbaJ3mwYeZR1owCIyukTElfUqc5mHfw7X9swrjoTTFoTWgTZinNBaPUwNT +QHNbSwLAlskn1UnQVgJNGGbzUDFm2aiVkRY8534wpYcN+/Qbl7gUYA6eq8lwSh04Y3Q mE4A== X-Gm-Message-State: AKaTC03emiWZC6Q63Smdj8D4p3VaX73KsynVW8ON3aCa8ic96OKZn/5L0fCUB9eOnYA3c4uUfA9FvMV0qMCN/w+0 X-Received: by 10.107.18.39 with SMTP id a39mr7097934ioj.45.1479459161909; Fri, 18 Nov 2016 00:52:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.59.147 with HTTP; Fri, 18 Nov 2016 00:52:41 -0800 (PST) In-Reply-To: <7F1BAD85ADEA444D97065A60D2E97EE566E522A0@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> <7F1BAD85ADEA444D97065A60D2E97EE566E522A0@SHSMSX101.ccr.corp.intel.com> From: Ard Biesheuvel Date: Fri, 18 Nov 2016 08:52:41 +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 08:52:37 -0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 18 November 2016 at 08:39, Tian, Feng wrote: > The simplest way I can think is > > +struct _NON_DISCOVERABLE_DEVICE { > + // > + // The type of device > + // > + NON_DISCOVERABLE_DEVICE_TYPE Type; -> change it to UINT8 Type; = //Type is the subtype of corresponding device, such as SATA is MSG_SATA_DP(= 0x12) What should we use for AMBA devices then? > + // > + // Whether this device is DMA coherent > + // > + NON_DISCOVERABLE_DEVICE_DMA_TYPE DmaType; > + // > + // Initialization function for the device > + // > + NON_DISCOVERABLE_DEVICE_INIT Initialize; > + // > + // The MMIO and I/O regions owned by the device > + // > + EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *Resources; > +}; > > Thanks > Feng > > -----Original Message----- > From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] > Sent: Friday, November 18, 2016 2:57 PM > To: Tian, Feng > Cc: Ni, Ruiyu ; Kinney, Michael D ; edk2-devel@lists.01.org; Gao, Liming ; afi= sh@apple.com; Leif Lindholm > Subject: Re: [edk2] [PATCH v3 1/5] MdeModulePkg: introduce non-discoverab= le device protocol > > 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 w= ill be changed often. Is it possible to make use of DevicePath node? Of cou= rse, 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 n= eed a mapping somewhere in the code between numbers and AHCI/EHCI/etc types= , given that the device itself cannot be interrogated to provide this infor= mation. 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 >> 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 pc= i 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 shou= ld 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 drive= r model has priority rules and protocols to decide which driver gets preced= ence. 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