From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 39DD71A1E0A for ; Mon, 12 Sep 2016 06:47:01 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id 186so11963690itf.0 for ; Mon, 12 Sep 2016 06:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZGtEf3lfr9S2+EeohhsnC87TGG+ZjpeKhNoMdlEIsT4=; b=Xfk4r5mGhtGvnzlYuKFrng0LoZph7YSTOYKrw6nQJ39/0JKDUuQhjvI9a8KiB0HKl8 o8xX3smhLhFGl3nHXEDqkjWidexduLFlt0NoICbkhyJlseMMQNqyVeuQra1zFrSX8wNQ omMZhMpD7ADUc4b386tbRyg3Y98K3KKhIB+wY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZGtEf3lfr9S2+EeohhsnC87TGG+ZjpeKhNoMdlEIsT4=; b=Y7e17HDNh4rdO98K/7aEoDvBalBF/PG3EnQKddyEkCjmBW7r1tJczVa7pm6xhTOtgK mZR2T0mhBT+6pmrV0oqAapRsPzT8rkp+muk9vMpg5KMC9AianmG4WsttaY1Fp6FfvKLC BPpueygW8TgPQcfxh6Hj2RM7caEWoX8/iKQJuJW3Oph+ay5sQdS9JYSajQtr9Ms+qXRM mi2MPIcux+QqWkApqtc8eo7vUBR0Whugh/iYColCSdlD+OCyo35GixHnWKvb4ZhT/+S7 YABAQjhRhCwE++6/pEtVX8IdkN57DtI0MBKaRvJnuk1me/QxyL3FahOIBjXCbkGpC/7J yAVg== X-Gm-Message-State: AE9vXwPZ7wUeGhNrx6HPL+7OOgq2GF/NeM8YfG+T8eoMdvq/rXpWGfYXcZKFvKJ+i4nL6KA4i33oXOYq3cICvLRo X-Received: by 10.157.5.10 with SMTP id 10mr22522702otw.185.1473688020069; Mon, 12 Sep 2016 06:47:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.204.195 with HTTP; Mon, 12 Sep 2016 06:46:59 -0700 (PDT) In-Reply-To: <31C8ACEA-1414-4C18-8CBC-F39B58489529@intel.com> References: <1473685561-1418-1-git-send-email-ard.biesheuvel@linaro.org> <74D8A39837DF1E4DA445A8C0B3885C50385FCEB6@shsmsx102.ccr.corp.intel.com> <31C8ACEA-1414-4C18-8CBC-F39B58489529@intel.com> From: Ard Biesheuvel Date: Mon, 12 Sep 2016 14:46:59 +0100 Message-ID: To: "Ni, Ruiyu" Cc: "Yao, Jiewen" , "edk2-devel@lists.01.org" , "Gao, Liming" , "Zeng, Star" , "Tian, Feng" , "lersek@redhat.com" , "leif.lindholm@linaro.org" Subject: Re: [PATCH] MdeModulePkg/PciBusDxe: make BAR degradation dependent on OPROM presence 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: Mon, 12 Sep 2016 13:47:01 -0000 Content-Type: text/plain; charset=UTF-8 On 12 September 2016 at 14:41, Ni, Ruiyu wrote: > You could use IncompatiblePciDevice protocol. If you have no clue I will > give you more information my tomorrow. > That works around the problem, but does not solve it. MdeModulePkg is supposed to be generic/universal, and still, it contains a Intel/CSM specific hack to degrade 64-bit BARs of any device that has an option ROM. This is platform specific policy that does not belong in generic code, and by the same reasoning that Jiewen argues that MdeModulePkg should not depend on IntelFrameworkModulePkg, it should not implement legacy BIOS hacks. So what would you propose to factor out this functionality? Perhaps a PciPolicyLib, whose Null implementation does not contain the hack. Or a feature PCD that can be set to disable this behavior? In any case, the requirement to implement the IncompatiblePciDevice protocol to get normal resource allocation behavior is not the best way to deal with this IMO Thanks, Ard.