On 18 November 2016 at 02:11, Ni, Ruiyu <ruiyu...@intel.com> wrote: > > > Regards, > Ray > >>-----Original Message----- >>From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] >>Sent: Thursday, November 17, 2016 6:43 PM >>To: Ni, Ruiyu <ruiyu...@intel.com> >>Cc: Kinney, Michael D <michael.d.kin...@intel.com>; edk2-devel@lists.01.org; >>Gao, Liming <liming....@intel.com>; >>af...@apple.com; Leif Lindholm <leif.lindh...@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...@intel.com> wrote: >>> >>> >>> >>> Thanks/Ray >>> >>>> -----Original Message----- >>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >>>> Ard Biesheuvel >>>> Sent: Thursday, November 17, 2016 2:07 PM >>>> To: Ni, Ruiyu <ruiyu...@intel.com> >>>> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; edk2- >>>> de...@lists.01.org; Gao, Liming <liming....@intel.com>; af...@apple.com; >>>> Leif Lindholm <leif.lindh...@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...@intel.com> wrote: >>>>> >>>>> Ard, >>>>> I have two comments in below. >>>>> >>>>> Thanks/Ray >>>>> >>>>>> -----Original Message----- >>>>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf >>>>>> Of Leif Lindholm >>>>>> Sent: Thursday, November 17, 2016 1:49 AM >>>>>> To: Ard Biesheuvel <ard.biesheu...@linaro.org> >>>>>> Cc: Ni, Ruiyu <ruiyu...@intel.com>; edk2-devel@lists.01.org; >>>>>> af...@apple.com; Gao, Liming <liming....@intel.com>; Kinney, Michael >>>>>> D <michael.d.kin...@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.biesheu...@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
