From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 D3AFF81F1B for ; Thu, 17 Nov 2016 02:43:08 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id f82so136921559wmf.1 for ; Thu, 17 Nov 2016 02:43:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+REIV6bRJOKc01I8f5LdKn8uxnyCzw64Y+tUzXBO4AI=; b=G/3O6dCr5+WO/Vqx4RnpvYnwznUd2rxxaK9N3IUnmKV3A0WLbTpfajKBtTBpsM23nX 5BIAgfaiXzSY0wKj/z5ELnh+8ju3EMAwolLToLzmJzhj/39XNU2nmYk+yAA0KyKnW2ua HbdTGe/hKoRlKu78k5pDrcIjHkihqatM3stDE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+REIV6bRJOKc01I8f5LdKn8uxnyCzw64Y+tUzXBO4AI=; b=G3H9xdYPBOAcWxP/S1/GL16zSVVbbuQ2WiQgUHUcF7bXw5Rr9LqOmh6gbWuUQAV3AY lrpOtftB8EtzdJc2/dQuF4E41ekuQtEj1ZlnNjEy1YOf3zJhVU8vN5suV6+DcEp+0zkN ZKm4JUvpl+7w7cDN6TH2NVsMjul0P1vlCRdLkrkih46l94jvWOVqtjofzylbtSTnNUVS 3cs38h0i13I5UHZEfhtsatVegPUfUQhR15X4oWCiKk2jD3/EQOEg4+MZX0bph72b2tF3 LYMpHFS+wjaVGbywinZIzpVLs7GEQHl5jubfHvqg7G48PDH9Isv+YoxRZB9COjg2WTGk B85w== X-Gm-Message-State: AKaTC00UzSfZvH3nnLRZ3DZyOxOLVW2M8XUwH9ksbxX0yuuWTFeBFuX9ltFZT/yE97xJubfh X-Received: by 10.28.158.148 with SMTP id h142mr3543889wme.59.1479379392461; Thu, 17 Nov 2016 02:43:12 -0800 (PST) Received: from [10.26.46.55] (84.21.90.92.rev.sfr.net. [92.90.21.84]) by smtp.gmail.com with ESMTPSA id dj5sm2533629wjb.34.2016.11.17.02.43.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Nov 2016 02:43:11 -0800 (PST) Mime-Version: 1.0 (1.0) From: Ard Biesheuvel X-Mailer: iPhone Mail (14B100) In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D58E7D6F5@SHSMSX104.ccr.corp.intel.com> Date: Thu, 17 Nov 2016 11:43:10 +0100 Cc: "Kinney, Michael D" , "edk2-devel@lists.01.org" , "Gao, Liming" , "afish@apple.com" , Leif Lindholm Message-Id: 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> To: "Ni, Ruiyu" 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: Thu, 17 Nov 2016 10:43:09 -0000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 17 Nov 2016, at 08:52, Ni, Ruiyu wrote: >=20 >=20 >=20 > Thanks/Ray >=20 >> -----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 >>=20 >>=20 >>=20 >>> On 17 Nov 2016, at 02:53, Ni, Ruiyu wrote: >>>=20 >>> Ard, >>> I have two comments in below. >>>=20 >>> Thanks/Ray >>>=20 >>>> -----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 >>>>=20 >>>>> 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. >>>>>=20 >>>>> 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(+) >>>>>=20 >>>>> 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 } } >>>=20 >>> 1. Can you add "PCI" keyword into the protocol name? >>> e.g.: EDKII_NON_DISCOVERABLE_PCI_DEVICE_PROTOCOL_GUID >>>=20 >>=20 >> No. This protocol does not describe pci devices, and it is a peculiarity o= f the >> edk2 driver stack that some non-pci devices can only be driven by pci dri= vers. >>=20 >> in other words, pci is part of the /driver/ side, and it is perfectly pos= sible for, >> e.g., a non-discoverable ahci device to be driven by a different non-pci d= river >> in the future. >>=20 >=20 > 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 t= wo > know whether it should manage the AHCI type device or not? Good question. But how does the UEFI driver model deal with that? What happe= ns if i have two drivers that both support the Ahci Pci class codes? > Besides since now all the EDKII Host Controller drivers are based on > PciIo, it implicitly requires all the low layer needs to produce PciIo int= erface > in order to re-use the EDKII Host Controller drivers. >=20 Yes, that is the whole point of these patches. My preferred solution would b= e to split the ?hci drivers from pci i/o, by introducing intermediate protoc= ols, but we both know that is unlikely to be accepted >>>>> + >>>>> +// >>>>> +// Protocol interface structure >>>>> +// >>>>> +typedef struct _NON_DISCOVERABLE_DEVICE >>>> NON_DISCOVERABLE_DEVICE; >>>>> + >>>>> +// >>>>> +// Data Types >>>>> +// >>>>> +typedef enum { >>>>> + NonDiscoverableDeviceTypeAmba, >>>>> + NonDiscoverableDeviceTypeOhci, >>>>> + NonDiscoverableDeviceTypeUhci, >>>>> + NonDiscoverableDeviceTypeEhci, >>>>> + NonDiscoverableDeviceTypeXhci, >>>>> + NonDiscoverableDeviceTypeAhci, >>>>> + NonDiscoverableDeviceTypeSdhci, >>>>> + NonDiscoverableDeviceTypeUfs, >>>>> + NonDiscoverableDeviceTypeNvme, >>>=20 >>>=20 >>>>=20 >>>> Just one OCD comment/question left: >>>> Can we keep these sorted alphabetically? >>>> (Also in switch statements in later patches?) >>>>=20 >>>> Other than that, I'm (very) happy with this series. >>>>=20 >>>> / >>>> Leif >>>>=20 >>>>> + NonDiscoverableDeviceTypeMax, >>>>> +} NON_DISCOVERABLE_DEVICE_TYPE; >>>>> + >>>>> +typedef enum { >>>>> + NonDiscoverableDeviceDmaTypeCoherent, >>>>> + NonDiscoverableDeviceDmaTypeNonCoherent, >>>>> + NonDiscoverableDeviceDmaTypeMax, >>>>> +} NON_DISCOVERABLE_DEVICE_DMA_TYPE; >>>>> + >>>>> +// >>>>> +// Function Prototypes >>>>> +// >>>>> + >>>>> +/** >>>>> + Perform device specific initialization before the device is >>>>> +started >>>>> + >>>>> + @param This The non-discoverable device protocol pointer >>>>> + >>>>> + @retval EFI_SUCCESS Initialization successful, the device may be >> used >>>>> + @retval Other Initialization failed, device should not be s= tarted >>>>> +**/ >>>>> +typedef >>>>> +EFI_STATUS >>>>> +(EFIAPI *NON_DISCOVERABLE_DEVICE_INIT) ( >>>>> + IN NON_DISCOVERABLE_DEVICE *This >>>>> + ); >>>>> + >>>>> +struct _NON_DISCOVERABLE_DEVICE { >>>>> + // >>>>> + // The type of device >>>>> + // >>>>> + NON_DISCOVERABLE_DEVICE_TYPE Type; >>> 2. Can you use PCI class code to replace the enum type here? >>> e.g.: UINT8 Class; UINT8 SubClass; UINT8 Programming Interface; The >>> enum type can be defined in the helper library. >>> In this way, we make the protocol definition stable enough. >>>=20 >>=20 >> Again, i think this is a bad idea. This is meant to describe the /device/= , not the >> edk2 implementation detail that some standardized host controller >> interfaces were implemented in a way that requires pci. It would also mak= e it >> impossible to describe AMBA devices > Does AMBA stand for Advanced Microcontroller Bus Architecture? > I have no idea about the AMBA. > Can you explain more why it's impossible to describe AMBA devices? >=20 Amba devices are identifiable but not discoverable. If you know the base add= ress, you know where the id registers are because they are always at the sam= e register offset Thanks, Ard. >>=20 >>>>> + // >>>>> + // 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; >>>>> +}; >>>>> + >>>>> +extern EFI_GUID gEdkiiNonDiscoverableDeviceProtocolGuid; >>>>> + >>>>> +#endif >>>>> diff --git a/MdeModulePkg/MdeModulePkg.dec >>>>> b/MdeModulePkg/MdeModulePkg.dec index >> 74b870051c67..6b956fc80c93 >>>>> 100644 >>>>> --- a/MdeModulePkg/MdeModulePkg.dec >>>>> +++ b/MdeModulePkg/MdeModulePkg.dec >>>>> @@ -505,6 +505,9 @@ [Protocols] >>>>> # Include/Protocol/Ps2Policy.h >>>>> gEfiPs2PolicyProtocolGuid =3D { 0x4DF19259, 0xDC71, 0x4D46, { 0xBE, >>>>> 0xF1, 0x35, 0x7B, 0xB5, 0x78, 0xC4, 0x18 } } >>>>>=20 >>>>> + ## Include/Protocol/NonDiscoverableDevice.h >>>>> + gEdkiiNonDiscoverableDeviceProtocolGuid =3D { 0x0d51905b, 0xb77e, >>>>> + 0x452a, {0xa2, 0xc0, 0xec, 0xa0, 0xcc, 0x8d, 0x51, 0x4a } } >>>>> + >>>>> # >>>>> # [Error.gEfiMdeModulePkgTokenSpaceGuid] >>>>> # 0x80000001 | Invalid value provided. >>>>> -- >>>>> 2.7.4 >>>>>=20 >>>> _______________________________________________ >>>> edk2-devel mailing list >>>> edk2-devel@lists.01.org >>>> https://lists.01.org/mailman/listinfo/edk2-devel >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel