From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753386AbbCBDdv (ORCPT ); Sun, 1 Mar 2015 22:33:51 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:52542 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752240AbbCBDdu (ORCPT ); Sun, 1 Mar 2015 22:33:50 -0500 Date: Sun, 1 Mar 2015 19:33:49 -0800 From: Greg KH To: Jake Oshins Cc: rafael.j.wysocki@intel.com, kys@microsoft.com, linux-kernel@vger.kernel.org, devel@linuxdriverproject.org, olaf@aepfle.de, apw@canonical.com, vkuznets@redhat.com Subject: Re: [PATCH 1/3] drivers:pnp Add support for descendants claiming memory address space Message-ID: <20150302033349.GA31395@kroah.com> References: <1424202111-14461-1-git-send-email-jakeo@microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1424202111-14461-1-git-send-email-jakeo@microsoft.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 17, 2015 at 11:41:49AM -0800, Jake Oshins wrote: > This patch adds some wrapper functions in the pnp layer. The intent is > to allow memory address space claims by devices which are descendants > (a child or grandchild of) a device which is already part of the pnp > layer. This allows a device to make a resource claim that doesn't > conflict with its "aunts" and "uncles." > > This is useful in a Hyper-V VM because some paravirtual "devices" need > memory-mapped I/O space, and their aunts and uncles can be PCI devices. > Furthermore, the hypervisor expresses the possible memory address > combinations for the devices in the VM through the ACPI namespace. > The paravirtual devices need to suballocate from the ACPI nodes, and > they need to avoid conflicting with choices that the Linux PCI code > makes about the PCI devices in the VM. > > It might seem like this should be done in the platform layer rather > than the pnp layer, but the platform layer assumes that the > configuration of the devices in the machine are static, or at least > expressed by firmware in a static fashion. The nature of a Hyper-V > VM is that new devices can be added while the machine is running, > and the potential configurations for them are expressed as part of > the paravirtual communications channel. This much more naturally > aligns with the pnp layer. > > Signed-off-by: Jake Oshins > --- > drivers/pnp/Makefile | 2 +- > drivers/pnp/base.h | 2 + > drivers/pnp/core.c | 1 + > drivers/pnp/descendant.c | 117 +++++++++++++++++++++++++++++++++++++++++++++++ > include/linux/pnp.h | 23 ++++++++++ > 5 files changed, 144 insertions(+), 1 deletion(-) > create mode 100644 drivers/pnp/descendant.c At first glance, this looks ok. Does it change the sysfs layout of hyperv devices? also, I'd like KY to sign-off on it, verifying that he at least tested the series and it works for him. thanks, greg k-h