[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BY2PR0301MB0711DC59362915807DC2C75FA0100@BY2PR0301MB0711.namprd03.prod.outlook.com>
Date: Mon, 2 Mar 2015 03:36:40 +0000
From: KY Srinivasan <kys@...rosoft.com>
To: Greg KH <gregkh@...uxfoundation.org>,
Jake Oshins <jakeo@...rosoft.com>
CC: "rafael.j.wysocki@...el.com" <rafael.j.wysocki@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
"olaf@...fle.de" <olaf@...fle.de>,
"apw@...onical.com" <apw@...onical.com>,
"vkuznets@...hat.com" <vkuznets@...hat.com>
Subject: RE: [PATCH 1/3] drivers:pnp Add support for descendants claiming
memory address space
> -----Original Message-----
> From: Greg KH [mailto:gregkh@...uxfoundation.org]
> Sent: Sunday, March 1, 2015 7:34 PM
> To: Jake Oshins
> Cc: rafael.j.wysocki@...el.com; KY Srinivasan; linux-kernel@...r.kernel.org;
> devel@...uxdriverproject.org; olaf@...fle.de; apw@...onical.com;
> vkuznets@...hat.com
> Subject: Re: [PATCH 1/3] drivers:pnp Add support for descendants claiming
> memory address space
>
> 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 <jakeo@...rosoft.com>
> > ---
> > 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.
Greg,
Dan had some comments that Jake will address and resend. Also, we are waiting for
Rafael to review this patch.
Regards,
K. Y
>
> thanks,
>
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists