public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
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" <edk2-devel@lists.01.org>,
	"Gao, Liming" <liming.gao@intel.com>,
	 "afish@apple.com" <afish@apple.com>,
	Leif Lindholm <leif.lindholm@linaro.org>
Subject: Re: [PATCH v3 1/5] MdeModulePkg: introduce non-discoverable device protocol
Date: Fri, 18 Nov 2016 06:57:06 +0000	[thread overview]
Message-ID: <CAKv+Gu_RcVejtNojtrCsnNLxnGY9o3gXbg3M1tndJYPJyr3K+g@mail.gmail.com> (raw)
In-Reply-To: <7F1BAD85ADEA444D97065A60D2E97EE566E521B3@SHSMSX101.ccr.corp.intel.com>

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


  reply	other threads:[~2016-11-18  6:57 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-16 16:59 [PATCH v3 0/5] MdeModulePkg: add support for non-discoverable devices Ard Biesheuvel
2016-11-16 16:59 ` [PATCH v3 1/5] MdeModulePkg: introduce non-discoverable device protocol Ard Biesheuvel
2016-11-16 17:48   ` Leif Lindholm
2016-11-17  2:53     ` Ni, Ruiyu
2016-11-17  6:07       ` Ard Biesheuvel
2016-11-17  7:52         ` Ni, Ruiyu
2016-11-17 10:43           ` Ard Biesheuvel
2016-11-18  2:11             ` Ni, Ruiyu
2016-11-18  4:59               ` Ard Biesheuvel
2016-11-18  5:24                 ` Tian, Feng
2016-11-18  6:57                   ` Ard Biesheuvel [this message]
2016-11-18  8:39                     ` Tian, Feng
2016-11-18  8:52                       ` Ard Biesheuvel
2016-11-18  6:13                 ` Ni, Ruiyu
2016-11-18  7:04                   ` Ard Biesheuvel
2016-11-18 13:39                     ` Ni, Ruiyu
2016-11-18 13:50                       ` Ard Biesheuvel
2016-11-25 15:21                         ` Ard Biesheuvel
2016-11-16 16:59 ` [PATCH v3 2/5] MdeModule: introduce helper library to register non-discoverable devices Ard Biesheuvel
2016-11-16 16:59 ` [PATCH v3 3/5] MdeModulePkg: implement generic PCI I/O driver for " Ard Biesheuvel
2016-11-17  3:29   ` Ni, Ruiyu
2016-11-18 12:30     ` Ard Biesheuvel
2016-11-24 18:14       ` Ard Biesheuvel
2016-11-16 16:59 ` [PATCH v3 4/5] MdeModulePkg/NonDiscoverablePciDeviceDxe: add support for non-coherent DMA Ard Biesheuvel
2016-11-16 16:59 ` [PATCH v3 5/5] Omap35xxPkg/PciEmulation: port to new non-discoverable device infrastructure Ard Biesheuvel
2016-11-17  4:36 ` [PATCH v3 0/5] MdeModulePkg: add support for non-discoverable devices Marcin Wojtas
2016-11-23 14:31   ` Marcin Wojtas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKv+Gu_RcVejtNojtrCsnNLxnGY9o3gXbg3M1tndJYPJyr3K+g@mail.gmail.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox