From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 10365C31E44 for ; Fri, 14 Jun 2019 09:57:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E3D642177E for ; Fri, 14 Jun 2019 09:57:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726482AbfFNJ5t (ORCPT ); Fri, 14 Jun 2019 05:57:49 -0400 Received: from foss.arm.com ([217.140.110.172]:58416 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725812AbfFNJ5t (ORCPT ); Fri, 14 Jun 2019 05:57:49 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 507BC2B; Fri, 14 Jun 2019 02:57:48 -0700 (PDT) Received: from e121166-lin.cambridge.arm.com (unknown [10.1.196.255]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3E46C3F718; Fri, 14 Jun 2019 02:59:31 -0700 (PDT) Date: Fri, 14 Jun 2019 10:57:42 +0100 From: Lorenzo Pieralisi To: Benjamin Herrenschmidt Cc: Ard Biesheuvel , Bjorn Helgaas , Sinan Kaya , linux-pci , linux-arm-kernel Subject: Re: [RFC PATCH v2] arm64: acpi/pci: invoke _DSM whether to preserve firmware PCI setup Message-ID: <20190614095742.GA27188@e121166-lin.cambridge.arm.com> References: <5783e36561bb77a1deb6ba67e5a9824488cc69c6.camel@kernel.crashing.org> <20190613190248.GH13533@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Fri, Jun 14, 2019 at 06:36:32PM +1000, Benjamin Herrenschmidt wrote: [...] > The biggest issue for me right now is that the spec says pretty much at > _DSM #5 = 0 is equivalent to _DSM #5 absent, and Bjorn seems keen on > having it this way, but for arm64, we specifically want to distinguish > those 2 cases. > > We want to honor _DSM #5 = 0, and at least initially, leave the rest > alone. > > Now, we *also* want to look at switching the rest to the "normal" (for > ACPI platforms at least) mechanism of using what FW setup and fixing up > if necessary, but that's not what the code does today, we know just > switching to pci_bus_claim_resources() will break some platforms, and > we need more testing and possibly quirks to get there, so it's material > for a separate patch. > > But in the meantime, I need to differenciate. > > Also using "probe_only" for _DSM #5 = 0 isn't a good idea, at least as > implemented today in the rest of the kernel, probe_only also means we > shouldn't assign what was left unassigned. However _DSM #5 allows this. I am not sure about this. PCI_PROBE_ONLY cannot stop an OS from reassigning BARs that are clearly misconfigured, it does not make any sense. It can't stop an OS from writing those BARs anyway, since they must be sized, why firmware would prevent an OS from reassigning BARs that are programmed with values that can be deemed 100% bogus ? Or put it differently, why must an OS preserve those values willy-nilly ? For me, PCI_PROBE_ONLY and _DSM == 0 on a host bridge must be considered equivalent. I agree with Bjorn on his reading of _DSM #5 and I think that the original patch that claims on _DSM #5 == 0 is a good starting point. I would like to make it a default even without _DSM #5 == 0 so that claim and reassign on claim failure works irrespective of _DSM #5, it is now or never, I think we can give it a shot, with an incremental patch. Lorenzo > So we'll need to find some more subtle way to convey these. > > Bjorn: At this point, because of all the above, I'm keen on going back > to my original patch (slightly modified Ard's patch), possibly > rewording a thing or two and addressing Lorenzo comment. > > We can look at a better and more generic implementation of _DSM #5 > including for child nodes after I have consolidated more of the > resource management code. > > Looking at the spec (and followup discussions for specs updates), I'm > quite keen on treating _DSM #5 = 1 as "wipe out the resource for that > endpoint/bridge and realloc something better. There are reasons for > that, but we can probably discuss that later. > > Cheers, > Ben. > >