> -----Original Message----- > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Tuesday, March 10, 2015 5:34 PM > To: Jake Oshins; o...@aepfle.de > Cc: Rafael J. Wysocki; gre...@linuxfoundation.org; KY Srinivasan; linux- > ker...@vger.kernel.org; a...@canonical.com; vkuzn...@redhat.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
