From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Logan Gunthorpe <logang@deltatee.com>,
Nicholas Johnson <nicholas.johnson-opensource@outlook.com.au>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: Multitude of resource assignment functions
Date: Fri, 28 Jun 2019 06:26:00 +1000 [thread overview]
Message-ID: <29195ddffa377c5d080552bb5194018681f8f5f7.camel@kernel.crashing.org> (raw)
In-Reply-To: <e2eec9dc-5eef-62ba-6251-f420d6579d03@deltatee.com>
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.
next prev parent reply other threads:[~2019-06-27 20:26 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <SL2P216MB01874DFDDBDE49B935A9B1B380E50@SL2P216MB0187.KORP216.PROD.OUTLOOK.COM>
2019-06-19 16:21 ` [nicholas.johnson-opensource@outlook.com.au: [PATCH v6 3/4] PCI: Fix bug resulting in double hpmemsize being assigned to MMIO window] Logan Gunthorpe
2019-06-20 0:44 ` Nicholas Johnson
2019-06-20 0:49 ` Logan Gunthorpe
2019-06-23 5:01 ` Nicholas Johnson
2019-06-24 9:13 ` Multitude of resource assignment functions Benjamin Herrenschmidt
2019-06-24 16:45 ` Logan Gunthorpe
2019-06-27 7:40 ` Nicholas Johnson
2019-06-27 8:48 ` Benjamin Herrenschmidt
2019-06-30 2:40 ` Nicholas Johnson
2019-06-27 16:35 ` Logan Gunthorpe
2019-06-27 20:26 ` Benjamin Herrenschmidt [this message]
2019-06-30 2:57 ` Nicholas Johnson
2019-07-01 4:33 ` Oliver O'Halloran
2019-07-02 21:39 ` Bjorn Helgaas
2019-07-03 13:43 ` Nicholas Johnson
2019-07-03 14:19 ` Bjorn Helgaas
2019-07-03 22:54 ` Benjamin Herrenschmidt
2019-06-20 13:43 ` [nicholas.johnson-opensource@outlook.com.au: [PATCH v6 3/4] PCI: Fix bug resulting in double hpmemsize being assigned to MMIO window] Bjorn Helgaas
2019-06-20 23:24 ` Benjamin Herrenschmidt
2019-06-27 7:50 ` Nicholas Johnson
2019-06-27 16:54 ` Logan Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=29195ddffa377c5d080552bb5194018681f8f5f7.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=bhelgaas@google.com \
--cc=linux-pci@vger.kernel.org \
--cc=logang@deltatee.com \
--cc=nicholas.johnson-opensource@outlook.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).