Re: [PATCH v3 1/5] MdeModulePkg: introduce non-discoverable device protocol

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On 18 November 2016 at 08:39, Tian, Feng <feng.tian@intel.com> 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 <feng.tian@intel.com>
> Cc: Ni, Ruiyu <ruiyu.ni@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel@lists.01.org; Gao, Liming <liming.gao@intel.com>; afish@apple.com; Leif Lindholm <leif.lindholm@linaro.org>
> Subject: Re: [edk2] [PATCH v3 1/5] MdeModulePkg: introduce non-discoverable device protocol
>
> On 18 November 2016 at 05:24, Tian, Feng <feng.tian@intel.com> wrote:
>> 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...
>>
>
> 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
>> Ard Biesheuvel
>> Sent: Friday, November 18, 2016 12:59 PM
>> To: Ni, Ruiyu <ruiyu.ni@intel.com>
>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>;
>> edk2-devel@lists.01.org; Gao, Liming <liming.gao@intel.com>;
>> afish@apple.com; Leif Lindholm <leif.lindholm@linaro.org>
>> Subject: Re: [edk2] [PATCH v3 1/5] MdeModulePkg: introduce
>> non-discoverable device protocol
>>
>> On 18 November 2016 at 02:11, Ni, Ruiyu <ruiyu.ni@intel.com> wrote:
>>>
>>>
>>> Regards,
>>> Ray
>>>
>>>>-----Original Message-----
>>>>From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
>>>>Sent: Thursday, November 17, 2016 6:43 PM
>>>>To: Ni, Ruiyu <ruiyu.ni@intel.com>
>>>>Cc: Kinney, Michael D <michael.d.kinney@intel.com>;
>>>>edk2-devel@lists.01.org; Gao, Liming <liming.gao@intel.com>;
>>>>afish@apple.com; Leif Lindholm <leif.lindholm@linaro.org>
>>>>Subject: Re: [edk2] [PATCH v3 1/5] MdeModulePkg: introduce
>>>>non-discoverable device protocol
>>>>
>>>>
>>>>> On 17 Nov 2016, at 08:52, Ni, Ruiyu <ruiyu.ni@intel.com> 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 <ruiyu.ni@intel.com>
>>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; edk2-
>>>>>> devel@lists.01.org; Gao, Liming <liming.gao@intel.com>;
>>>>>> afish@apple.com; Leif Lindholm <leif.lindholm@linaro.org>
>>>>>> Subject: Re: [edk2] [PATCH v3 1/5] MdeModulePkg: introduce non-
>>>>>> discoverable device protocol
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 17 Nov 2016, at 02:53, Ni, Ruiyu <ruiyu.ni@intel.com> 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 <ard.biesheuvel@linaro.org>
>>>>>>>> Cc: Ni, Ruiyu <ruiyu.ni@intel.com>; edk2-devel@lists.01.org;
>>>>>>>> afish@apple.com; Gao, Liming <liming.gao@intel.com>; Kinney,
>>>>>>>> Michael D <michael.d.kinney@intel.com>
>>>>>>>> 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 <ard.biesheuvel@linaro.org>
>>>>>>>>> ---
>>>>>>>>> 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.<BR>
>>>>>>>>> +
>>>>>>>>> +  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 <IndustryStandard/Acpi.h>
>>>>>>>>> +
>>>>>>>>> +#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.
>>
>> Thanks,
>> Ard.
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel