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=-1.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, T_DKIMWL_WL_HIGH autolearn=unavailable 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 4C2A8C282CE for ; Mon, 3 Jun 2019 23:41:37 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 203C422CBB for ; Mon, 3 Jun 2019 23:41:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="knkLO9l1" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 203C422CBB Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Mime-Version:Date:To:From:Subject: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=CMOFpHsKocRmb4FOUYQ0TCcvLPo239U5xJzgVf5N5bA=; b=knkLO9l11Xc/vA Cz8KrUvjnp+4UkPgvGGp6G00CC5kRpVZun/KMUwJo0UE2rONrg/Te32ArxcK4SWOE6dOmwhYOJ4CM fzQ6TTW6/I15onTNey0tzfb841WNrug9FTuepacEEhZdOm243kNFTRB9g3+MiSesqxyJcLfk/tzJ6 +q2SfDKaESU1QUarHB2SRlDD6iS4xU9d9OpuodM7H82jSn8QiPuRwbirqua8rMYMH+rnlv/XlJ5FP dvtdFJ0/gf3DtvMTfm6PVJW5s7cY7e3lHRlC3Xgjr3Y6cEm2Kj+lXDTWWeFpSdWJd0cJ2r8LUtRTV LsPat7zt6I9/AqZC2c0A==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hXwa8-0006dJ-AE; Mon, 03 Jun 2019 23:41:36 +0000 Received: from gate.crashing.org ([63.228.1.57]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hXwa4-0006cv-Mj for linux-arm-kernel@lists.infradead.org; Mon, 03 Jun 2019 23:41:34 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x53NfGPf015895; Mon, 3 Jun 2019 18:41:17 -0500 Message-ID: <56715377f941f1953be43b488c2203ec090079a1.camel@kernel.crashing.org> Subject: [RFC] ARM64 PCI resource survey issue(s) From: Benjamin Herrenschmidt To: Ard Biesheuvel Date: Tue, 04 Jun 2019 09:41:16 +1000 X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 Mime-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190603_164132_891076_8CCC9A54 X-CRM114-Status: UNSURE ( 9.25 ) X-CRM114-Notice: Please train this message. X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Lorenzo Pieralisi , linux-pci@vger.kernel.org, Sinan Kaya , "Zilberman, Zeev" , "Saidi, Ali" , bhelgaas@google.com, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Folks ! I'd like to revive the discussion around Ard's old patch: https://patchwork.kernel.org/patch/9675707/ We (Amazon) need that sorted one way or another ASAP since we have setups coming where we must not let Linux change the FW assignments under some host bridges. In fact it's a reasonable thing to require for other reasons. The EFI framebuffer is an example, there can be others where FW/ACPI/EL3 etc... might have assumptions based on where some system devices were located by the boot FW and will break if we move them (such things are common on x86 and powerpc). Taking a step back I think (and I suspect we generally agree based on followup discussions I've seen) that the "right" thing to do is to have our default behaviour be: - Claim what the FW established if it's not obviously broken - Call pci_assign_unassigned_resources() to assign what the FW didn't assign Which is more or less what powerpc and x86 do today, but using a different mechanism than what's in pci_bus_claim_resources() (they are similar to each other, I wrote the current powerpc one loosely based on the x86 one at the time). That leads to a side question (which we should probably discuss in a separate thread) of whether we want to consolidate all that. That said, we also know this is going to break *some* existing platforms that have known broken FW assignment. The question is then can we sufficiently detect the breakage and re-assign in those cases (like x86 does fairly successfully in a number of cases), or do we need to add some board/platform quirks to force the full re-assigment on known broken platforms ? Even if all arm64 platforms are found to be broken today, I would still like to have our default be to use the FW setup, if anything as an incentive for newer platforms to get it right. At the very least on ACPI. We can use DSM#5 when it exists to force one way or another (ideally on a per bus basis but that's harder, so let's start with host bridges maybe ?) Thoughts ? I'm happy to do some of the work here. We have an emergency to get the AZ case solved, and Ard old patch does that... Cheers, Ben. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel