[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <BN3PR0301MB121958CF49F85A624B3AD2F6AB010@BN3PR0301MB1219.namprd03.prod.outlook.com>
Date: Thu, 19 Mar 2015 19:21:53 +0000
From: Jake Oshins <jakeo@...rosoft.com>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>,
"olaf@...fle.de" <olaf@...fle.de>
CC: "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
KY Srinivasan <kys@...rosoft.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"apw@...onical.com" <apw@...onical.com>,
"vkuznets@...hat.com" <vkuznets@...hat.com>,
Linux ACPI <linux-acpi@...r.kernel.org>,
Linux PCI <linux-pci@...r.kernel.org>,
"Bjorn Helgaas" <bhelgaas@...gle.com>
Subject: RE: [PATCH 1/3] drivers:pnp Add support for descendants claiming
memory address space
> -----Original Message-----
> From: Rafael J. Wysocki [mailto:rjw@...ysocki.net]
> Sent: Tuesday, March 10, 2015 5:34 PM
> To: Jake Oshins; olaf@...fle.de
> Cc: Rafael J. Wysocki; gregkh@...uxfoundation.org; KY Srinivasan; linux-
> kernel@...r.kernel.org; apw@...onical.com; vkuznets@...hat.com; Linux
> ACPI; Linux PCI; Bjorn Helgaas
> Subject: Re: [PATCH 1/3] drivers:pnp Add support for descendants claiming
> memory address space
>
<snip>
> It seems to me then that what you really want is a null protocol for PNP
> which simply doesn't do anything. I don't see any justification for the
> "descendant_protocol" name. It's just a null one.
>
> In that case you should slightly modify the PNP bus type to be able to
> use a null protocol without defining the stub ->get, ->put and ->disable
> methods that just do nothing and return 0.
>
> Then, you can define the null protocol without any methods in
> drivers/pnp/core.c and use it in your code without adding the "descendant"
> concept.
>
> Of course, that comes with a price which is that every device using the
> null protocol will have that protocol's abstract device as its parent.
> I suppose that this is not a problem?
>
<snip>
>
> > The problem comes in if there are PCI devices in the same region. There's
> no
> > easy way to figure out whether the claim conflicts with the PCI devices,
> since
> > the PCI device's claims are made through the pnp layer.
>
> Well, please look at __pci_request_region() then and tell me where it uses
> the
> PNP layer.
>
I've been thinking a lot (and poking around in the code, trying things) in response to what you wrote, and in particular in response to the two parts quoted above. Having a null protocol where each of the devices has the same abstract parent doesn't serve my needs, because it won't guarantee that the ranges claimed fall within the _CRS of the grandparent or great-grandparent node. And, in fact, I don't think that my proposed patch is actually accomplishing that deterministically either, at the moment.
Your response, at length, convinced me to look at things differently and I realized that I wasn't getting as much from this approach as I thought I was. I'd like to withdraw this patch series. I can come up with an alternative solution that exists only within the Hyper-V-related drivers.
Thanks again for your time and patience,
Jake Oshins
Powered by blists - more mailing lists