From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 4210581EB9 for ; Fri, 18 Nov 2016 05:50:40 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id u144so5871787wmu.1 for ; Fri, 18 Nov 2016 05:50:45 -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=vGpInfxkqGG2otpi3c/h2iLEnfKe7FPXT0xNHeNuxmc=; b=HfSvTq91HCdXBF2yo5f3QMKrfqoon86BSsTwrpsdx3NNxAaD53CmHYq9l+UeIXlOrc 0LYhZvtQ4UJFDplWElNsSVA+CA6k6iuU0tUE7fSPelMaFJVbSYU3WryyiWP7Ngvqzxiy V/PopG/kyqyMWjEPK4uJRpFxFKyHGCJmOfcTI= 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=vGpInfxkqGG2otpi3c/h2iLEnfKe7FPXT0xNHeNuxmc=; b=fETjhnlBNQZXx1Rr1Owzdea6bt5zY0UAt03SXQdpQBLcyAQNsXDXoSTJJX40PAipxd BeSogxsxnJasEeLlBia8wG4lskyDt7CDvBUu4ufbI+T5OX3L7QR77zD33dYaHNvSO+Cy HR4VE1ViWWu2OPAjacBRzS5cqiqCyIAd/TgfhFTr0WUEk0OTh9MPKKDvHX7Acnb4RnOR BcG6eQVoTBXL8F8S0usOMwr6GiQvIPb+870fS3KXbLX72SEjxDfizuCsMe4L+ikgqpHM cd6Trz1M2OJZwzHkEK5zCMfVQwGwjsTkKq18ZdAoi21oIFjv3wQ86NrmLtiBJZOldCtO gtGg== X-Gm-Message-State: AKaTC01mWb0uG+ns/1pwZTWt0dQa59K/JoP23vhEMnQG6rBBDRm/WrWLQXi4b5NrfMnL9UqT X-Received: by 10.28.60.194 with SMTP id j185mr196415wma.33.1479477044277; Fri, 18 Nov 2016 05:50:44 -0800 (PST) Received: from [10.150.60.50] (86.225.154.77.rev.sfr.net. [77.154.225.86]) by smtp.gmail.com with ESMTPSA id q65sm3494575wmd.6.2016.11.18.05.50.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Nov 2016 05:50:43 -0800 (PST) Mime-Version: 1.0 (1.0) From: Ard Biesheuvel X-Mailer: iPhone Mail (14B100) In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D58E804E1@SHSMSX104.ccr.corp.intel.com> Date: Fri, 18 Nov 2016 14:50:40 +0100 Cc: "Kinney, Michael D" , "edk2-devel@lists.01.org" , "Gao, Liming" , "afish@apple.com" , Leif Lindholm Message-Id: <5DD889BC-CC56-4FFE-929E-C547515D0573@linaro.org> 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> <734D49CCEBEEF84792F5B80ED585239D58E80120@SHSMSX104.ccr.corp.intel.com> <734D49CCEBEEF84792F5B80ED585239D58E804E1@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: Fri, 18 Nov 2016 13:50:40 -0000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On 18 Nov 2016, at 14:39, Ni, Ruiyu wrote: >>>>>>>>> 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 peculi= arity of the >>>>>>>> edk2 driver stack that some non-pci devices can only be driven by p= ci drivers. >>>>>>>>=20 >>>>>>>> in other words, pci is part of the /driver/ side, and it is perfect= ly possible for, >>>>>>>> e.g., a non-discoverable ahci device to be driven by a different no= n-pci driver >>>>>>>> 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 b= e >>>>>>> handled by a future NonDiscoverableXXXDevice driver. >>>>>>> Now since the AHCI type is already handled by the NonDiscoverablePci= Device >>>>>>> driver, when there is a new NonDiscoverableXXXDevice driver, how can= the two >>>>>>> know whether it should manage the AHCI type device or not? >>>>>>=20 >>>>>> Good question. But how does the UEFI driver model deal with that? Wha= t 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 d= istinguish >>>>> them. >>>>>=20 >>>>=20 >>>> No, that is not what I mean. >>>>=20 >>>> 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. >>>=20 >>> I see they are different. Based on PciIo, the *HCI drivers can query >>> additional information from PCI CFG header, instead of just using >>> the PCI class code. >>>=20 >>> But with the NonDiscoverableDevice protocol, there is no additional >>> information can help the *HCI drivers decide which to manage. >>>=20 >>> I don't see any practical negative point which prevents degrading >>> NonDiscoverableDevice protocol to NonDiscoverable*Pci*Protocol. >>> After all, as I said, all *HCI drivers are based on PciIo. >>>=20 >>=20 >> Yes the *drivers* are based on PCI. But that does not make the >> *devices* PCI devices. That is the whole problem we are trying to deal >> with. So describing the non-PCI devices as PCI devices is incorrect >> imo. The fact that we will use PCI drivers to drive non-PCI devices is >> an implementation detail of EDK2, and is a property of the *driver* >> side not the *device* side. So using PCI class codes etc to wire up >> the correct driver should be local to the driver, and not pollute the >> description of the device. >>=20 >> For example, if we would ever split the AHCI driver into a AHCI part >> and a PCI part (which I know is unlikely to occur), I would want the >> non-PCI AHCI driver to be used with the same protocol. Perhaps that >> means we need a protocol for each type of device rather than an enum? >> In any case, putting PCI-specific metadata into the device description >> makes the situation worse, because now both the *device* and the >> *driver* side are forced to use PCI internals to describe devices that >> have nothing to do with PCI >=20 > If I understand correctly, you want the protocol producer can simply > produce such protocol without the knowledge of PCI. I agree! > But we do need to make the protocol definition stable enough. I do not > like to see the enum type being extended in future to support more types > of devices. > 1. Can you use different GUIDs for different types of devices? Yes that seems like a reasonable approach, in the spirit of EDK2 :-) > 2. As I replied as comment #2 to patch 3/5, do you have better way to > deal with the SDHCI Host controller driver access? I need to think about this=