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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 E847EC004E6 for ; Thu, 27 Jun 2019 20:26:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C93AA20665 for ; Thu, 27 Jun 2019 20:26:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726480AbfF0U0R (ORCPT ); Thu, 27 Jun 2019 16:26:17 -0400 Received: from gate.crashing.org ([63.228.1.57]:57300 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726463AbfF0U0Q (ORCPT ); Thu, 27 Jun 2019 16:26:16 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x5RKQ0JI017540; Thu, 27 Jun 2019 15:26:01 -0500 Message-ID: <29195ddffa377c5d080552bb5194018681f8f5f7.camel@kernel.crashing.org> Subject: Re: Multitude of resource assignment functions From: Benjamin Herrenschmidt To: Logan Gunthorpe , Nicholas Johnson Cc: Bjorn Helgaas , "linux-pci@vger.kernel.org" Date: Fri, 28 Jun 2019 06:26:00 +1000 In-Reply-To: References: <024eec86-dfb9-0a23-6385-9e8dfe9a0381@deltatee.com> <442c6b35a1aab9833fd2942b499d4fb082a71a15.camel@kernel.crashing.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Thu, 2019-06-27 at 10:35 -0600, Logan Gunthorpe wrote: > My worry would be if the firmware depends on any of those PCI resources > for any of it's calls. For example, laptop firmware often has specific > code for screen blanking/dimming when the special buttons are pressed. > If it implements this by communicating with a PCI device then the kernel > will break things by reassigning all the addresses. > > However, having a kernel parameter to ignore the firmware choices might > be a good way for us to start testing whether this is a problem or not > on some systems As I consolidate that accross archs I can add such a parameter... I haven't quite folded x86 in yet, but I'm hoping I'll be able to do so soon. I plan to move some of those x86 specific kernel parameters into generic code while doing so. I can add this one. Cheers, Ben.