* Re: kvm PCI assignment & VFIO ramblings
From: Avi Kivity @ 2011-08-22 13:06 UTC (permalink / raw)
To: Roedel, Joerg
Cc: Alexey Kardashevskiy, kvm@vger.kernel.org, Paul Mackerras,
qemu-devel, iommu, chrisw, Alex Williamson, Anthony Liguori,
linux-pci@vger.kernel.org, linuxppc-dev, benve@cisco.com
In-Reply-To: <20110822125502.GF2079@amd.com>
On 08/22/2011 03:55 PM, Roedel, Joerg wrote:
> On Mon, Aug 22, 2011 at 08:42:35AM -0400, Avi Kivity wrote:
> > On 08/22/2011 03:36 PM, Roedel, Joerg wrote:
> > > On the AMD IOMMU side this information is stored in the IVRS ACPI table.
> > > Not sure about the VT-d side, though.
> >
> > I see. There is no sysfs node representing it?
>
> No. It also doesn't exist as a 'struct pci_dev'. This caused problems in
> the AMD IOMMU driver in the past and I needed to fix that. There I know
> that from :)
Well, too bad.
>
> > I'd rather not add another meaningless identifier.
>
> Well, I don't think its really meaningless, but we need some way to
> communicate the information about device groups to userspace.
>
I mean the contents of the group descriptor. There are enough 42s in
the kernel, it's better if we can replace a synthetic number with
something meaningful.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: Roedel, Joerg @ 2011-08-22 12:55 UTC (permalink / raw)
To: Avi Kivity
Cc: Alexey Kardashevskiy, kvm@vger.kernel.org, Paul Mackerras,
qemu-devel, iommu, chrisw, Alex Williamson, Anthony Liguori,
linux-pci@vger.kernel.org, linuxppc-dev, benve@cisco.com
In-Reply-To: <4E524EBB.8090603@redhat.com>
On Mon, Aug 22, 2011 at 08:42:35AM -0400, Avi Kivity wrote:
> On 08/22/2011 03:36 PM, Roedel, Joerg wrote:
> > On the AMD IOMMU side this information is stored in the IVRS ACPI table.
> > Not sure about the VT-d side, though.
>
> I see. There is no sysfs node representing it?
No. It also doesn't exist as a 'struct pci_dev'. This caused problems in
the AMD IOMMU driver in the past and I needed to fix that. There I know
that from :)
> I'd rather not add another meaningless identifier.
Well, I don't think its really meaningless, but we need some way to
communicate the information about device groups to userspace.
Joerg
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: Avi Kivity @ 2011-08-22 12:42 UTC (permalink / raw)
To: Roedel, Joerg
Cc: Alexey Kardashevskiy, kvm@vger.kernel.org, Paul Mackerras,
qemu-devel, iommu, chrisw, Alex Williamson, Anthony Liguori,
linux-pci@vger.kernel.org, linuxppc-dev, benve@cisco.com
In-Reply-To: <20110822123651.GD2079@amd.com>
On 08/22/2011 03:36 PM, Roedel, Joerg wrote:
> On Mon, Aug 22, 2011 at 06:51:35AM -0400, Avi Kivity wrote:
> > On 08/22/2011 01:46 PM, Joerg Roedel wrote:
> > > That does not work. The bridge in question may not even be visible as a
> > > PCI device, so you can't link to it. This is the case on a few PCIe
> > > cards which only have a PCIx chip and a PCIe-2-PCIx bridge to implement
> > > the PCIe interface (yes, I have seen those cards).
> >
> > How does the kernel detect that devices behind the invisible bridge must
> > be assigned as a unit?
>
> On the AMD IOMMU side this information is stored in the IVRS ACPI table.
> Not sure about the VT-d side, though.
>
I see. There is no sysfs node representing it?
I'd rather not add another meaningless identifier.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: Roedel, Joerg @ 2011-08-22 12:36 UTC (permalink / raw)
To: Avi Kivity
Cc: Alexey Kardashevskiy, kvm@vger.kernel.org, Paul Mackerras,
qemu-devel, iommu, chrisw, Alex Williamson, Anthony Liguori,
linux-pci@vger.kernel.org, linuxppc-dev, benve@cisco.com
In-Reply-To: <4E5234B7.7000700@redhat.com>
On Mon, Aug 22, 2011 at 06:51:35AM -0400, Avi Kivity wrote:
> On 08/22/2011 01:46 PM, Joerg Roedel wrote:
> > That does not work. The bridge in question may not even be visible as a
> > PCI device, so you can't link to it. This is the case on a few PCIe
> > cards which only have a PCIx chip and a PCIe-2-PCIx bridge to implement
> > the PCIe interface (yes, I have seen those cards).
>
> How does the kernel detect that devices behind the invisible bridge must
> be assigned as a unit?
On the AMD IOMMU side this information is stored in the IVRS ACPI table.
Not sure about the VT-d side, though.
Joerg
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
^ permalink raw reply
* Re: [PATCH 2/2] arch/powerpc/platforms/powermac/setup.c: add missing of_node_put
From: Julia Lawall @ 2011-08-22 12:31 UTC (permalink / raw)
To: walter harms
Cc: devicetree-discuss, kernel-janitors, linux-kernel, Paul Mackerras,
linuxppc-dev
In-Reply-To: <4E522AD0.7030907@bfs.de>
On Mon, 22 Aug 2011, walter harms wrote:
>
>
> Am 21.08.2011 18:10, schrieb Julia Lawall:
> > From: Julia Lawall <julia@diku.dk>
> >
> > np is initialized to the result of calling a function that calls
> > of_node_get, so of_node_put should be called before the pointer is dropped.
> >
> > The semantic match that finds this problem is as follows:
> > (http://coccinelle.lip6.fr/)
> >
> > // <smpl>
> > @@
> > expression e,e1,e2;
> > @@
> >
> > * e = \(of_find_node_by_type\|of_find_node_by_name\)(...)
> > ... when != of_node_put(e)
> > when != true e == NULL
> > when != e2 = e
> > e = e1
> > // </smpl>
> >
> > Signed-off-by: Julia Lawall <julia@diku.dk>
> >
> > ---
> > arch/powerpc/platforms/powermac/setup.c | 8 ++++++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/powerpc/platforms/powermac/setup.c b/arch/powerpc/platforms/powermac/setup.c
> > index 96580b1..970ea1d 100644
> > --- a/arch/powerpc/platforms/powermac/setup.c
> > +++ b/arch/powerpc/platforms/powermac/setup.c
> > @@ -494,11 +494,15 @@ static int __init pmac_declare_of_platform_devices(void)
> > return -1;
> >
> > np = of_find_node_by_name(NULL, "valkyrie");
> > - if (np)
> > + if (np) {
> > of_platform_device_create(np, "valkyrie", NULL);
> > + of_node_put(np);
> > + }
> > np = of_find_node_by_name(NULL, "platinum");
> > - if (np)
> > + if (np) {
> > of_platform_device_create(np, "platinum", NULL);
> > + of_node_put(np);
> > + }
> > np = of_find_node_by_type(NULL, "smu");
> > if (np) {
> > of_platform_device_create(np, "smu", NULL);
> >
>
>
> hi,
> it seems save to call of_node_put(np) with np==NULL, i assume the same is true
> for of_platform_device_create().
>
> so the code collapses to:
>
> _test_node(char *name)
> {
> struct device_node *np;
> np = of_find_node_by_name(NULL, name);
> of_platform_device_create(np, name, NULL);
> of_node_put(np);
> return NULL?:0:1;
> }
>
> maybe there is already something like find_node() ?
of_platform_device_create is not much used, and one might want to use it
with other functions than of_find_node_by_name, as indeed is done here.
Is the problem just a missing else between the calls? Is it certain that
all of the cases are disjoint?
julia
^ permalink raw reply
* Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Artem Bityutskiy @ 2011-08-22 10:58 UTC (permalink / raw)
To: Scott Wood
Cc: linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org, LiuShuo,
dwmw2@infradead.org, Matthieu CASTET
In-Reply-To: <4E4EA70B.9050203@freescale.com>
On Fri, 2011-08-19 at 13:10 -0500, Scott Wood wrote:
> On 08/19/2011 03:57 AM, Matthieu CASTET wrote:
> > LiuShuo a écrit :
> >> 于 2011年08月19日 01:00, Matthieu CASTET 写道:
> >>> b35362@freescale.com a écrit :
> >>>> From: Liu Shuo<b35362@freescale.com>
> >>>>
> >>>> Freescale FCM controller has a 2K size limitation of buffer RAM. In order
> >>>> to support the Nand flash chip whose page size is larger than 2K bytes,
> >>>> we divide a page into multi-2K pages for MTD layer driver. In that case,
> >>>> we force to set the page size to 2K bytes. We convert the page address of
> >>>> MTD layer driver to a real page address in flash chips and a column index
> >>>> in fsl_elbc driver. We can issue any column address by UA instruction of
> >>>> elbc controller.
> >>>>
> >>> Why do you need to do that ?
> >>>
> >>> When mtd send you a 4k page, why can't you write it by 2*2k pages write ?
> >> 1. It's easy to implement.
> >> 2. We don't need to move the data in buffer more times, because we
> >> want to use the HW_ECC.
> >>
> >> In flash chip per Page:
> >> ----------------------------------------------------------------
> >> | first data | first oob | second data | second oob |
> >> ----------------------------------------------------------------
> > How the bad block marker are handled with this remapping ?
>
> It has to be migrated prior to first use (this needs to be documented,
> and ideally a U-Boot command provided do do this), or else special
> handling would be needed when building the BBT. The only way around
> this would be to do ECC in software, and do the buffering needed to let
> MTD treat it as a 4K chip.
It really feels like a special hack which would better not go to
mainline - am I the only one with such feeling? If yes, probably I am
wrong...
--
Best Regards,
Artem Bityutskiy
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: Avi Kivity @ 2011-08-22 10:51 UTC (permalink / raw)
To: Joerg Roedel
Cc: Alexey Kardashevskiy, kvm@vger.kernel.org, Paul Mackerras,
qemu-devel, iommu, chrisw, Alex Williamson, Anthony Liguori,
linux-pci@vger.kernel.org, linuxppc-dev, benve@cisco.com
In-Reply-To: <20110822104635.GC2079@amd.com>
On 08/22/2011 01:46 PM, Joerg Roedel wrote:
> > $ readlink /sys/devices/pci0000:00/0000:00:19.0/iommu_group
> > ../../../path/to/device/which/represents/the/resource/constraint
> >
> > (the pci-to-pci bridge on x86, or whatever node represents partitionable
> > endpoints on power)
>
> That does not work. The bridge in question may not even be visible as a
> PCI device, so you can't link to it. This is the case on a few PCIe
> cards which only have a PCIx chip and a PCIe-2-PCIx bridge to implement
> the PCIe interface (yes, I have seen those cards).
>
How does the kernel detect that devices behind the invisible bridge must
be assigned as a unit?
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Artem Bityutskiy @ 2011-08-22 10:53 UTC (permalink / raw)
To: b35362; +Cc: linuxppc-dev, dwmw2, linux-mtd
In-Reply-To: <1313634783-8855-1-git-send-email-b35362@freescale.com>
On Thu, 2011-08-18 at 10:33 +0800, b35362@freescale.com wrote:
> From: Liu Shuo <b35362@freescale.com>
>
> Freescale FCM controller has a 2K size limitation of buffer RAM. In order
> to support the Nand flash chip whose page size is larger than 2K bytes,
> we divide a page into multi-2K pages for MTD layer driver. In that case,
> we force to set the page size to 2K bytes. We convert the page address of
> MTD layer driver to a real page address in flash chips and a column index
> in fsl_elbc driver. We can issue any column address by UA instruction of
> elbc controller.
>
> NOTE: Due to there is a limitation of 'Number of Partial Program Cycles in
> the Same Page (NOP)', the flash chip which is supported by this workaround
> have to meet below conditions.
> 1. page size is not greater than 4KB
> 2. 1) if main area and spare area have independent NOPs:
> main area NOP : >=3
> spare area NOP : >=2
> 2) if main area and spare area have a common NOP:
> NOP : >=4
Could you please also add this kind of info to the driver code comments?
Does it also make sense to print a message if you do the emulation,
like:
pr_info("attention! emulating 2KiB NAND pages!");
--
Best Regards,
Artem Bityutskiy
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: Joerg Roedel @ 2011-08-22 10:46 UTC (permalink / raw)
To: Avi Kivity
Cc: Alexey Kardashevskiy, kvm@vger.kernel.org, Paul Mackerras,
qemu-devel, iommu, chrisw, Alex Williamson, Anthony Liguori,
linux-pci@vger.kernel.org, linuxppc-dev, benve@cisco.com
In-Reply-To: <4E51F782.7060005@redhat.com>
On Mon, Aug 22, 2011 at 02:30:26AM -0400, Avi Kivity wrote:
> On 08/20/2011 07:51 PM, Alex Williamson wrote:
> > We need to address both the description and enforcement of device
> > groups. Groups are formed any time the iommu does not have resolution
> > between a set of devices. On x86, this typically happens when a
> > PCI-to-PCI bridge exists between the set of devices and the iommu. For
> > Power, partitionable endpoints define a group. Grouping information
> > needs to be exposed for both userspace and kernel internal usage. This
> > will be a sysfs attribute setup by the iommu drivers. Perhaps:
> >
> > # cat /sys/devices/pci0000:00/0000:00:19.0/iommu_group
> > 42
> >
>
> $ readlink /sys/devices/pci0000:00/0000:00:19.0/iommu_group
> ../../../path/to/device/which/represents/the/resource/constraint
>
> (the pci-to-pci bridge on x86, or whatever node represents partitionable
> endpoints on power)
That does not work. The bridge in question may not even be visible as a
PCI device, so you can't link to it. This is the case on a few PCIe
cards which only have a PCIx chip and a PCIe-2-PCIx bridge to implement
the PCIe interface (yes, I have seen those cards).
Regards,
Joerg
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
^ permalink raw reply
* Re: [PATCH] sound/soc/fsl/fsl_dma.c: add missing of_node_put
From: Liam Girdwood @ 2011-08-22 10:18 UTC (permalink / raw)
To: Julia Lawall
Cc: alsa-devel@alsa-project.org, Takashi Iwai,
devicetree-discuss@lists.ozlabs.org, Mark Brown,
kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org,
Jaroslav Kysela, linuxppc-dev@lists.ozlabs.org, Timur Tabi
In-Reply-To: <1313825025-17590-1-git-send-email-julia@diku.dk>
On 20/08/11 08:23, Julia Lawall wrote:
> From: Julia Lawall <julia@diku.dk>
>
> of_parse_phandle increments the reference count of np, so this should be
> decremented before trying the next possibility.
>
> The semantic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @@
> expression e,e1,e2;
> @@
>
> *e = of_parse_phandle(...)
> ... when != of_node_put(e)
> when != true e == NULL
> when != e2 = e
> e = e1
> // </smpl>
>
> Signed-off-by: Julia Lawall <julia@diku.dk>
>
> ---
> sound/soc/fsl/fsl_dma.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/sound/soc/fsl/fsl_dma.c b/sound/soc/fsl/fsl_dma.c
> index 0efc04a..b33271b 100644
> --- a/sound/soc/fsl/fsl_dma.c
> +++ b/sound/soc/fsl/fsl_dma.c
> @@ -880,10 +880,12 @@ static struct device_node *find_ssi_node(struct device_node *dma_channel_np)
> np = of_parse_phandle(ssi_np, "fsl,playback-dma", 0);
> if (np == dma_channel_np)
> return ssi_np;
> + of_node_put(np);
>
> np = of_parse_phandle(ssi_np, "fsl,capture-dma", 0);
> if (np == dma_channel_np)
> return ssi_np;
> + of_node_put(np);
> }
>
> return NULL;
>
Acked-by: Liam Girdwood <lrg@ti.com>
^ permalink raw reply
* Re: [PATCH 2/2] arch/powerpc/platforms/powermac/setup.c: add missing of_node_put
From: Julia Lawall @ 2011-08-22 10:14 UTC (permalink / raw)
To: walter harms
Cc: devicetree-discuss, kernel-janitors, linux-kernel, Paul Mackerras,
linuxppc-dev
In-Reply-To: <4E522AD0.7030907@bfs.de>
On Mon, 22 Aug 2011, walter harms wrote:
>
>
> Am 21.08.2011 18:10, schrieb Julia Lawall:
> > From: Julia Lawall <julia@diku.dk>
> >
> > np is initialized to the result of calling a function that calls
> > of_node_get, so of_node_put should be called before the pointer is dropped.
> >
> > The semantic match that finds this problem is as follows:
> > (http://coccinelle.lip6.fr/)
> >
> > // <smpl>
> > @@
> > expression e,e1,e2;
> > @@
> >
> > * e = \(of_find_node_by_type\|of_find_node_by_name\)(...)
> > ... when != of_node_put(e)
> > when != true e == NULL
> > when != e2 = e
> > e = e1
> > // </smpl>
> >
> > Signed-off-by: Julia Lawall <julia@diku.dk>
> >
> > ---
> > arch/powerpc/platforms/powermac/setup.c | 8 ++++++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/powerpc/platforms/powermac/setup.c b/arch/powerpc/platforms/powermac/setup.c
> > index 96580b1..970ea1d 100644
> > --- a/arch/powerpc/platforms/powermac/setup.c
> > +++ b/arch/powerpc/platforms/powermac/setup.c
> > @@ -494,11 +494,15 @@ static int __init pmac_declare_of_platform_devices(void)
> > return -1;
> >
> > np = of_find_node_by_name(NULL, "valkyrie");
> > - if (np)
> > + if (np) {
> > of_platform_device_create(np, "valkyrie", NULL);
> > + of_node_put(np);
> > + }
> > np = of_find_node_by_name(NULL, "platinum");
> > - if (np)
> > + if (np) {
> > of_platform_device_create(np, "platinum", NULL);
> > + of_node_put(np);
> > + }
> > np = of_find_node_by_type(NULL, "smu");
> > if (np) {
> > of_platform_device_create(np, "smu", NULL);
> >
>
>
> hi,
> it seems save to call of_node_put(np) with np==NULL, i assume the same is true
> for of_platform_device_create().
>
> so the code collapses to:
>
> _test_node(char *name)
> {
> struct device_node *np;
> np = of_find_node_by_name(NULL, name);
> of_platform_device_create(np, name, NULL);
of_platform_device_create seems to do a lot of work if np is NULL. It
returns NULL in the end, as far as I can see, but a lot of function calls
are required.
julia
> of_node_put(np);
> return NULL?:0:1;
> }
>
> maybe there is already something like find_node() ?
>
> re,
> wh
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 2/2] arch/powerpc/platforms/powermac/setup.c: add missing of_node_put
From: walter harms @ 2011-08-22 10:09 UTC (permalink / raw)
To: Julia Lawall
Cc: devicetree-discuss, kernel-janitors, linux-kernel, Paul Mackerras,
linuxppc-dev
In-Reply-To: <1313943001-12884-2-git-send-email-julia@diku.dk>
Am 21.08.2011 18:10, schrieb Julia Lawall:
> From: Julia Lawall <julia@diku.dk>
>
> np is initialized to the result of calling a function that calls
> of_node_get, so of_node_put should be called before the pointer is dropped.
>
> The semantic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @@
> expression e,e1,e2;
> @@
>
> * e = \(of_find_node_by_type\|of_find_node_by_name\)(...)
> ... when != of_node_put(e)
> when != true e == NULL
> when != e2 = e
> e = e1
> // </smpl>
>
> Signed-off-by: Julia Lawall <julia@diku.dk>
>
> ---
> arch/powerpc/platforms/powermac/setup.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powermac/setup.c b/arch/powerpc/platforms/powermac/setup.c
> index 96580b1..970ea1d 100644
> --- a/arch/powerpc/platforms/powermac/setup.c
> +++ b/arch/powerpc/platforms/powermac/setup.c
> @@ -494,11 +494,15 @@ static int __init pmac_declare_of_platform_devices(void)
> return -1;
>
> np = of_find_node_by_name(NULL, "valkyrie");
> - if (np)
> + if (np) {
> of_platform_device_create(np, "valkyrie", NULL);
> + of_node_put(np);
> + }
> np = of_find_node_by_name(NULL, "platinum");
> - if (np)
> + if (np) {
> of_platform_device_create(np, "platinum", NULL);
> + of_node_put(np);
> + }
> np = of_find_node_by_type(NULL, "smu");
> if (np) {
> of_platform_device_create(np, "smu", NULL);
>
hi,
it seems save to call of_node_put(np) with np==NULL, i assume the same is true
for of_platform_device_create().
so the code collapses to:
_test_node(char *name)
{
struct device_node *np;
np = of_find_node_by_name(NULL, name);
of_platform_device_create(np, name, NULL);
of_node_put(np);
return NULL?:0:1;
}
maybe there is already something like find_node() ?
re,
wh
^ permalink raw reply
* Re: [PATCH] mtd/nand: Don't add disabled nand flash devices
From: Lan Chunhe @ 2011-08-22 10:04 UTC (permalink / raw)
To: Scott Wood, Chunhe Lan; +Cc: dwmw2, kumar.gala, linux-mtd, akpm, linuxppc-dev
In-Reply-To: <4E4AE535.4070400@freescale.com>
On Wed, 17 Aug 2011 05:46:29 +0800, Scott Wood <scottwood@freescale.com>=
=
wrote:
> On 08/16/2011 04:27 AM, Chunhe Lan wrote:
>> Nand flash nodes with the property status=3D"disabled" are not
>> usable and so avoid adding "disabled" nand flash devices with
>> the system.
>>
>> Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
>> ---
>> drivers/mtd/nand/fsl_elbc_nand.c | 5 ++++-
>> 1 files changed, 4 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/mtd/nand/fsl_elbc_nand.c =
>> b/drivers/mtd/nand/fsl_elbc_nand.c
>> index 33d8aad..8212c12 100644
>> --- a/drivers/mtd/nand/fsl_elbc_nand.c
>> +++ b/drivers/mtd/nand/fsl_elbc_nand.c
>> @@ -1,6 +1,6 @@
>> /* Freescale Enhanced Local Bus Controller NAND driver
>> *
>> - * Copyright =C2=A9 2006-2007, 2010 Freescale Semiconductor
>> + * Copyright =C2=A9 2006-2007, 2010-2011 Freescale Semiconductor
>> *
>> * Authors: Nick Spence <nick.spence@freescale.com>,
>> * Scott Wood <scottwood@freescale.com>
>> @@ -849,6 +849,9 @@ static int __devinit fsl_elbc_nand_probe(struct =
>> platform_device *pdev)
>> struct device *dev;
>> struct device_node *node =3D pdev->dev.of_node;
>>
>> + if (!of_device_is_available(node))
>> + return -ENODEV;
>> +
>> if (!fsl_lbc_ctrl_dev || !fsl_lbc_ctrl_dev->regs)
>> return -ENODEV;
>> lbc =3D fsl_lbc_ctrl_dev->regs;
>
> Same comment as the other patch -- unavailable devices should already
> not be getting probed. Also, this subject line makes it sound like th=
is
> is a NAND subsystem change rather than a change in one specific driver=
.
You are right.
The upper layers have prevented unavailable devices.
So, this patch is no need.
Thanks.
-Jack Lan
> -Scott
^ permalink raw reply
* Re: [PATCH] mtd/physmap_of: Don't add disabled flash devices
From: Lan Chunhe @ 2011-08-22 10:02 UTC (permalink / raw)
To: Scott Wood, Chunhe Lan; +Cc: dwmw2, kumar.gala, linux-mtd, akpm, linuxppc-dev
In-Reply-To: <4E4AE4D8.1080903@freescale.com>
On Wed, 17 Aug 2011 05:44:56 +0800, Scott Wood <scottwood@freescale.com>
wrote:
> On 08/16/2011 04:25 AM, Chunhe Lan wrote:
>> Flash(cfi-flash, jedec-flash, and so on) nodes with the
>> property status="disabled" are not usable and so avoid
>> adding "disabled" flash devices with the system.
>>
>> Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
>> ---
>> drivers/mtd/maps/physmap_of.c | 3 +++
>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/mtd/maps/physmap_of.c
>> b/drivers/mtd/maps/physmap_of.c
>> index d251d1d..812e6dc 100644
>> --- a/drivers/mtd/maps/physmap_of.c
>> +++ b/drivers/mtd/maps/physmap_of.c
>> @@ -219,6 +219,9 @@ static int __devinit of_flash_probe(struct
>> platform_device *dev)
>> struct mtd_info **mtd_list = NULL;
>> resource_size_t res_size;
>>
>> + if (!of_device_is_available(dp))
>> + return -ENODEV;
>> +
>> match = of_match_device(of_flash_match, &dev->dev);
>> if (!match)
>> return -EINVAL;
>
> Are you actually seeing unavailable devices get probed? I thought the
> upper layers were supposed to prevent that.
You are right.
The upper layers have prevented unavailable devices.
So, this patch is no need.
Thanks.
-Jack Lan
> -Scott
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: Avi Kivity @ 2011-08-22 6:30 UTC (permalink / raw)
To: Alex Williamson
Cc: chrisw, Alexey Kardashevskiy, kvm, Paul Mackerras, qemu-devel,
aafabbri, iommu, Anthony Liguori, linux-pci@vger.kernel.org,
linuxppc-dev, benve
In-Reply-To: <1313859105.6866.192.camel@x201.home>
On 08/20/2011 07:51 PM, Alex Williamson wrote:
> We need to address both the description and enforcement of device
> groups. Groups are formed any time the iommu does not have resolution
> between a set of devices. On x86, this typically happens when a
> PCI-to-PCI bridge exists between the set of devices and the iommu. For
> Power, partitionable endpoints define a group. Grouping information
> needs to be exposed for both userspace and kernel internal usage. This
> will be a sysfs attribute setup by the iommu drivers. Perhaps:
>
> # cat /sys/devices/pci0000:00/0000:00:19.0/iommu_group
> 42
>
$ readlink /sys/devices/pci0000:00/0000:00:19.0/iommu_group
../../../path/to/device/which/represents/the/resource/constraint
(the pci-to-pci bridge on x86, or whatever node represents partitionable
endpoints on power)
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply
* Re: kvm PCI assignment & VFIO ramblings
From: David Gibson @ 2011-08-22 5:55 UTC (permalink / raw)
To: Alex Williamson
Cc: aafabbri, Alexey Kardashevskiy, kvm, Paul Mackerras, qemu-devel,
chrisw, iommu, Avi Kivity, Anthony Liguori,
linux-pci@vger.kernel.org, linuxppc-dev, benve
In-Reply-To: <1313859105.6866.192.camel@x201.home>
On Sat, Aug 20, 2011 at 09:51:39AM -0700, Alex Williamson wrote:
> We had an extremely productive VFIO BoF on Monday. Here's my attempt to
> capture the plan that I think we agreed to:
>
> We need to address both the description and enforcement of device
> groups. Groups are formed any time the iommu does not have resolution
> between a set of devices. On x86, this typically happens when a
> PCI-to-PCI bridge exists between the set of devices and the iommu. For
> Power, partitionable endpoints define a group. Grouping information
> needs to be exposed for both userspace and kernel internal usage. This
> will be a sysfs attribute setup by the iommu drivers. Perhaps:
>
> # cat /sys/devices/pci0000:00/0000:00:19.0/iommu_group
> 42
>
> (I use a PCI example here, but attribute should not be PCI specific)
Ok. Am I correct in thinking these group IDs are representing the
minimum granularity, and are therefore always static, defined only by
the connected hardware, not by configuration?
> >From there we have a few options. In the BoF we discussed a model where
> binding a device to vfio creates a /dev/vfio$GROUP character device
> file. This "group" fd provides provides dma mapping ioctls as well as
> ioctls to enumerate and return a "device" fd for each attached member of
> the group (similar to KVM_CREATE_VCPU). We enforce grouping by
> returning an error on open() of the group fd if there are members of the
> group not bound to the vfio driver. Each device fd would then support a
> similar set of ioctls and mapping (mmio/pio/config) interface as current
> vfio, except for the obvious domain and dma ioctls superseded by the
> group fd.
It seems a slightly strange distinction that the group device appears
when any device in the group is bound to vfio, but only becomes usable
when all devices are bound.
> Another valid model might be that /dev/vfio/$GROUP is created for all
> groups when the vfio module is loaded. The group fd would allow open()
> and some set of iommu querying and device enumeration ioctls, but would
> error on dma mapping and retrieving device fds until all of the group
> devices are bound to the vfio driver.
Which is why I marginally prefer this model, although it's not a big
deal.
> In either case, the uiommu interface is removed entirely since dma
> mapping is done via the group fd. As necessary in the future, we can
> define a more high performance dma mapping interface for streaming dma
> via the group fd. I expect we'll also include architecture specific
> group ioctls to describe features and capabilities of the iommu. The
> group fd will need to prevent concurrent open()s to maintain a 1:1 group
> to userspace process ownership model.
A 1:1 group<->process correspondance seems wrong to me. But there are
many ways you could legitimately write the userspace side of the code,
many of them involving some sort of concurrency. Implementing that
concurrency as multiple processes (using explicit shared memory and/or
other IPC mechanisms to co-ordinate) seems a valid choice that we
shouldn't arbitrarily prohibit.
Obviously, only one UID may be permitted to have the group open at a
time, and I think that's enough to prevent them doing any worse than
shooting themselves in the foot.
> Also on the table is supporting non-PCI devices with vfio. To do this,
> we need to generalize the read/write/mmap and irq eventfd interfaces.
> We could keep the same model of segmenting the device fd address space,
> perhaps adding ioctls to define the segment offset bit position or we
> could split each region into it's own fd (VFIO_GET_PCI_BAR_FD(0),
> VFIO_GET_PCI_CONFIG_FD(), VFIO_GET_MMIO_FD(3)), though we're already
> suffering some degree of fd bloat (group fd, device fd(s), interrupt
> event fd(s), per resource fd, etc). For interrupts we can overload
> VFIO_SET_IRQ_EVENTFD to be either PCI INTx or non-PCI irq
Sounds reasonable.
> (do non-PCI
> devices support MSI?).
They can. Obviously they might not have exactly the same semantics as
PCI MSIs, but I know we have SoC systems with (non-PCI) on-die devices
whose interrupts are treated by the (also on-die) root interrupt
controller in the same way as PCI MSIs.
> For qemu, these changes imply we'd only support a model where we have a
> 1:1 group to iommu domain. The current vfio driver could probably
> become vfio-pci as we might end up with more target specific vfio
> drivers for non-pci. PCI should be able to maintain a simple -device
> vfio-pci,host=bb:dd.f to enable hotplug of individual devices. We'll
> need to come up with extra options when we need to expose groups to
> guest for pvdma.
Are you saying that you'd no longer support the current x86 usage of
putting all of one guest's devices into a single domain? If that's
not what you're saying, how would the domains - now made up of a
user's selection of groups, rather than individual devices - be
configured?
> Hope that captures it, feel free to jump in with corrections and
> suggestions. Thanks,
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: linux-next: boot test failure (net tree)
From: Stephen Rothwell @ 2011-08-22 1:30 UTC (permalink / raw)
To: David Miller
Cc: mikey, netdev, ppc-dev, linux-kernel, linux-next, Paul Mackerras,
jeffrey.t.kirsher, akpm, torvalds
In-Reply-To: <20110817.225356.1790362313048139752.davem@davemloft.net>
Hi Dave,
On Wed, 17 Aug 2011 22:53:56 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 18 Aug 2011 15:22:14 +1000
>
> > Mikey asks: Will Dave take these updates if we get Acks from the
> > maintainers? :-)
>
> I'm more than happy to :-)
Here's what I am applying as a merge fixup to the net tree today so that
my ppc64_defconfig builds actually build more or less the same set of
drivers as before this rearrangement.
This has no Acks yet, but produces a very similar .config to what we had
previously.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 22 Aug 2011 11:23:56 +1000
Subject: [PATCH] powerpc: update ppc64_defconfig for net device movement
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/configs/ppc64_defconfig | 71 +++++++++++++--------------------
1 files changed, 28 insertions(+), 43 deletions(-)
diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig
index 84a685a5..9a424c4 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -49,7 +49,6 @@ CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_HZ_100=y
CONFIG_BINFMT_MISC=m
-CONFIG_HOTPLUG_CPU=y
CONFIG_KEXEC=y
CONFIG_IRQ_ALL_CPUS=y
CONFIG_MEMORY_HOTREMOVE=y
@@ -75,7 +74,6 @@ CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
-CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NF_CONNTRACK=m
CONFIG_NF_CONNTRACK_EVENTS=y
CONFIG_NF_CT_PROTO_SCTP=m
@@ -133,7 +131,6 @@ CONFIG_NETFILTER_XT_MATCH_U32=m
CONFIG_NF_CONNTRACK_IPV4=m
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
-CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_AH=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_TTL=m
@@ -145,7 +142,6 @@ CONFIG_NF_NAT=m
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_REDIRECT=m
-CONFIG_NF_NAT_SNMP_BASIC=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_CLUSTERIP=m
CONFIG_IP_NF_TARGET_ECN=m
@@ -176,7 +172,6 @@ CONFIG_CHR_DEV_SG=y
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_FC_ATTRS=y
-CONFIG_SCSI_SAS_ATTRS=m
CONFIG_SCSI_CXGB3_ISCSI=m
CONFIG_SCSI_CXGB4_ISCSI=m
CONFIG_SCSI_BNX2_ISCSI=m
@@ -208,13 +203,6 @@ CONFIG_DM_SNAPSHOT=m
CONFIG_DM_MIRROR=m
CONFIG_DM_ZERO=m
CONFIG_DM_MULTIPATH=m
-CONFIG_IEEE1394=y
-CONFIG_IEEE1394_OHCI1394=y
-CONFIG_IEEE1394_SBP2=m
-CONFIG_IEEE1394_ETH1394=m
-CONFIG_IEEE1394_RAWIO=y
-CONFIG_IEEE1394_VIDEO1394=m
-CONFIG_IEEE1394_DV1394=m
CONFIG_ADB_PMU=y
CONFIG_PMAC_SMU=y
CONFIG_THERM_PM72=y
@@ -223,43 +211,49 @@ CONFIG_WINDFARM_PM81=y
CONFIG_WINDFARM_PM91=y
CONFIG_WINDFARM_PM112=y
CONFIG_WINDFARM_PM121=y
-CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
CONFIG_BONDING=m
CONFIG_TUN=m
CONFIG_MARVELL_PHY=y
CONFIG_BROADCOM_PHY=m
-CONFIG_NET_ETHERNET=y
-CONFIG_SUNGEM=y
CONFIG_NET_VENDOR_3COM=y
CONFIG_VORTEX=y
-CONFIG_IBMVETH=m
-CONFIG_NET_PCI=y
-CONFIG_PCNET32=y
-CONFIG_E100=y
+CONFIG_NET_VENDOR_ALTEON=y
CONFIG_ACENIC=m
CONFIG_ACENIC_OMIT_TIGON_I=y
-CONFIG_E1000=y
-CONFIG_E1000E=y
+CONFIG_NET_VENDOR_AMD=y
+CONFIG_PCNET32=y
CONFIG_TIGON3=y
-CONFIG_BNX2=m
-CONFIG_SPIDER_NET=m
-CONFIG_GELIC_NET=m
-CONFIG_GELIC_WIRELESS=y
CONFIG_CHELSIO_T1=m
-CONFIG_CHELSIO_T3=m
-CONFIG_CHELSIO_T4=m
+CONFIG_NET_VENDOR_EMULEX=y
+CONFIG_BE2NET=m
+CONFIG_NET_VENDOR_EXAR=y
+CONFIG_S2IO=m
+CONFIG_NET_VENDOR_IBM=y
+CONFIG_IBMVETH=m
+CONFIG_ISERIES_VETH=m
CONFIG_EHEA=m
-CONFIG_IXGBE=m
+CONFIG_NET_VENDOR_INTEL=y
+CONFIG_E100=y
+CONFIG_E1000=y
+CONFIG_E1000E=y
CONFIG_IXGB=m
-CONFIG_S2IO=m
+CONFIG_IXGBE=m
+CONFIG_MLX4_EN=m
+CONFIG_NET_VENDOR_MYRI=y
CONFIG_MYRI10GE=m
-CONFIG_NETXEN_NIC=m
+CONFIG_NET_VENDOR_NVIDIA=y
+CONFIG_NET_VENDOR_PASEMI=y
CONFIG_PASEMI_MAC=y
-CONFIG_MLX4_EN=m
+CONFIG_NET_VENDOR_QLOGIC=y
CONFIG_QLGE=m
-CONFIG_BE2NET=m
-CONFIG_ISERIES_VETH=m
+CONFIG_NETXEN_NIC=m
+CONFIG_NET_VENDOR_SUN=y
+CONFIG_SUNGEM=y
+CONFIG_NET_VENDOR_TOSHIBA=y
+CONFIG_GELIC_NET=m
+CONFIG_GELIC_WIRELESS=y
+CONFIG_SPIDER_NET=m
CONFIG_PPP=m
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
@@ -331,7 +325,6 @@ CONFIG_USB=y
CONFIG_USB_DEVICEFS=y
CONFIG_USB_MON=m
CONFIG_USB_EHCI_HCD=y
-CONFIG_USB_EHCI_TT_NEWSCHED=y
# CONFIG_USB_EHCI_HCD_PPC_OF is not set
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_STORAGE=m
@@ -373,11 +366,9 @@ CONFIG_JFS_POSIX_ACL=y
CONFIG_JFS_SECURITY=y
CONFIG_XFS_FS=m
CONFIG_XFS_POSIX_ACL=y
-CONFIG_OCFS2_FS=m
CONFIG_BTRFS_FS=m
CONFIG_BTRFS_FS_POSIX_ACL=y
CONFIG_NILFS2_FS=m
-CONFIG_INOTIFY=y
CONFIG_AUTOFS4_FS=m
CONFIG_FUSE_FS=m
CONFIG_ISO9660_FS=y
@@ -398,7 +389,6 @@ CONFIG_ROOT_NFS=y
CONFIG_NFSD=m
CONFIG_NFSD_V3_ACL=y
CONFIG_NFSD_V4=y
-CONFIG_RPCSEC_GSS_SPKM3=m
CONFIG_CIFS=m
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
@@ -444,15 +434,13 @@ CONFIG_CRC_T10DIF=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_KERNEL=y
CONFIG_LOCKUP_DETECTOR=y
-CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEBUG_MUTEXES=y
-# CONFIG_RCU_CPU_STALL_DETECTOR is not set
+CONFIG_DEBUG_STACK_USAGE=y
CONFIG_LATENCYTOP=y
CONFIG_SYSCTL_SYSCALL_CHECK=y
CONFIG_SCHED_TRACER=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_DEBUG_STACKOVERFLOW=y
-CONFIG_DEBUG_STACK_USAGE=y
CONFIG_CODE_PATCHING_SELFTEST=y
CONFIG_FTR_FIXUP_SELFTEST=y
CONFIG_MSI_BITMAP_SELFTEST=y
@@ -463,10 +451,8 @@ CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_TEST=m
CONFIG_CRYPTO_CCM=m
CONFIG_CRYPTO_GCM=m
-CONFIG_CRYPTO_ECB=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_HMAC=y
-CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
@@ -474,7 +460,6 @@ CONFIG_CRYPTO_TGR192=m
CONFIG_CRYPTO_WP512=m
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_ANUBIS=m
-CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_KHAZAD=m
--
1.7.5.4
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* [PATCH 2/2] arch/powerpc/platforms/powermac/setup.c: add missing of_node_put
From: Julia Lawall @ 2011-08-21 16:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: devicetree-discuss, kernel-janitors, linux-kernel, Paul Mackerras,
linuxppc-dev
From: Julia Lawall <julia@diku.dk>
np is initialized to the result of calling a function that calls
of_node_get, so of_node_put should be called before the pointer is dropped.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression e,e1,e2;
@@
* e = \(of_find_node_by_type\|of_find_node_by_name\)(...)
... when != of_node_put(e)
when != true e == NULL
when != e2 = e
e = e1
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
arch/powerpc/platforms/powermac/setup.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/powermac/setup.c b/arch/powerpc/platforms/powermac/setup.c
index 96580b1..970ea1d 100644
--- a/arch/powerpc/platforms/powermac/setup.c
+++ b/arch/powerpc/platforms/powermac/setup.c
@@ -494,11 +494,15 @@ static int __init pmac_declare_of_platform_devices(void)
return -1;
np = of_find_node_by_name(NULL, "valkyrie");
- if (np)
+ if (np) {
of_platform_device_create(np, "valkyrie", NULL);
+ of_node_put(np);
+ }
np = of_find_node_by_name(NULL, "platinum");
- if (np)
+ if (np) {
of_platform_device_create(np, "platinum", NULL);
+ of_node_put(np);
+ }
np = of_find_node_by_type(NULL, "smu");
if (np) {
of_platform_device_create(np, "smu", NULL);
^ permalink raw reply related
* [PATCH 1/2] arch/powerpc/platforms/cell/iommu.c: add missing of_node_put
From: Julia Lawall @ 2011-08-21 16:10 UTC (permalink / raw)
To: Arnd Bergmann
Cc: cbe-oss-dev, devicetree-discuss, kernel-janitors, linux-kernel,
Paul Mackerras, linuxppc-dev
From: Julia Lawall <julia@diku.dk>
np is initialized to the result of calling a function that calls
of_node_get, so of_node_put should be called before the pointer is dropped.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression e,e1,e2;
@@
* e = \(of_find_node_by_type\|of_find_node_by_name\)(...)
... when != of_node_put(e)
when != true e == NULL
when != e2 = e
e = e1
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
arch/powerpc/platforms/cell/iommu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index 26a0671..d0c5dfd 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -1038,6 +1038,8 @@ static int __init cell_iommu_fixed_mapping_init(void)
/* The fixed mapping is only supported on axon machines */
np = of_find_node_by_name(NULL, "axon");
+ of_node_put(np);
+
if (!np) {
pr_debug("iommu: fixed mapping disabled, no axons found\n");
return -1;
^ permalink raw reply related
* Re: kvm PCI assignment & VFIO ramblings
From: Alex Williamson @ 2011-08-20 16:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: chrisw, Alexey Kardashevskiy, kvm, Paul Mackerras,
linux-pci@vger.kernel.org, qemu-devel, aafabbri, iommu,
Avi Kivity, Anthony Liguori, linuxppc-dev, benve
In-Reply-To: <1312944513.29273.28.camel@pasglop>
We had an extremely productive VFIO BoF on Monday. Here's my attempt to
capture the plan that I think we agreed to:
We need to address both the description and enforcement of device
groups. Groups are formed any time the iommu does not have resolution
between a set of devices. On x86, this typically happens when a
PCI-to-PCI bridge exists between the set of devices and the iommu. For
Power, partitionable endpoints define a group. Grouping information
needs to be exposed for both userspace and kernel internal usage. This
will be a sysfs attribute setup by the iommu drivers. Perhaps:
# cat /sys/devices/pci0000:00/0000:00:19.0/iommu_group
42
(I use a PCI example here, but attribute should not be PCI specific)
>From there we have a few options. In the BoF we discussed a model where
binding a device to vfio creates a /dev/vfio$GROUP character device
file. This "group" fd provides provides dma mapping ioctls as well as
ioctls to enumerate and return a "device" fd for each attached member of
the group (similar to KVM_CREATE_VCPU). We enforce grouping by
returning an error on open() of the group fd if there are members of the
group not bound to the vfio driver. Each device fd would then support a
similar set of ioctls and mapping (mmio/pio/config) interface as current
vfio, except for the obvious domain and dma ioctls superseded by the
group fd.
Another valid model might be that /dev/vfio/$GROUP is created for all
groups when the vfio module is loaded. The group fd would allow open()
and some set of iommu querying and device enumeration ioctls, but would
error on dma mapping and retrieving device fds until all of the group
devices are bound to the vfio driver.
In either case, the uiommu interface is removed entirely since dma
mapping is done via the group fd. As necessary in the future, we can
define a more high performance dma mapping interface for streaming dma
via the group fd. I expect we'll also include architecture specific
group ioctls to describe features and capabilities of the iommu. The
group fd will need to prevent concurrent open()s to maintain a 1:1 group
to userspace process ownership model.
Also on the table is supporting non-PCI devices with vfio. To do this,
we need to generalize the read/write/mmap and irq eventfd interfaces.
We could keep the same model of segmenting the device fd address space,
perhaps adding ioctls to define the segment offset bit position or we
could split each region into it's own fd (VFIO_GET_PCI_BAR_FD(0),
VFIO_GET_PCI_CONFIG_FD(), VFIO_GET_MMIO_FD(3)), though we're already
suffering some degree of fd bloat (group fd, device fd(s), interrupt
event fd(s), per resource fd, etc). For interrupts we can overload
VFIO_SET_IRQ_EVENTFD to be either PCI INTx or non-PCI irq (do non-PCI
devices support MSI?).
For qemu, these changes imply we'd only support a model where we have a
1:1 group to iommu domain. The current vfio driver could probably
become vfio-pci as we might end up with more target specific vfio
drivers for non-pci. PCI should be able to maintain a simple -device
vfio-pci,host=bb:dd.f to enable hotplug of individual devices. We'll
need to come up with extra options when we need to expose groups to
guest for pvdma.
Hope that captures it, feel free to jump in with corrections and
suggestions. Thanks,
Alex
^ permalink raw reply
* Re: [PATCH 4/4] sound/aoa/fabrics/layout.c: remove unneeded kfree
From: Takashi Iwai @ 2011-08-20 7:30 UTC (permalink / raw)
To: Julia Lawall
Cc: alsa-devel, devicetree-discuss, kernel-janitors, linux-kernel,
Jaroslav Kysela, Johannes Berg, linuxppc-dev
In-Reply-To: <1313820761-12042-4-git-send-email-julia@diku.dk>
At Sat, 20 Aug 2011 08:12:41 +0200,
Julia Lawall wrote:
>
> From: Julia Lawall <julia@diku.dk>
>
> The label outnodev is only used when kzalloc has not yet taken place or has
> failed, so there is no need for the call for kfree under this label.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @@
> identifier x;
> expression E1!=0,E2,E3,E4;
> statement S;
> iterator I;
> @@
>
> (
> if (...) { ... when != kfree(x)
> when != x = E3
> when != E3 = x
> * return ...;
> }
> ... when != x = E2
> when != I(...,x,...) S
> if (...) { ... when != x = E4
> kfree(x); ... return ...; }
> )
> // </smpl>
>
> Signed-off-by: Julia Lawall <julia@diku.dk>
Thanks, applied this one.
The rest three are left for review by Mark & Liam.
Takashi
> ---
> sound/aoa/fabrics/layout.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/aoa/fabrics/layout.c b/sound/aoa/fabrics/layout.c
> index 3fd1a7e..552b97a 100644
> --- a/sound/aoa/fabrics/layout.c
> +++ b/sound/aoa/fabrics/layout.c
> @@ -1073,10 +1073,10 @@ static int aoa_fabric_layout_probe(struct soundbus_dev *sdev)
> sdev->pcmid = -1;
> list_del(&ldev->list);
> layouts_list_items--;
> + kfree(ldev);
> outnodev:
> of_node_put(sound);
> layout_device = NULL;
> - kfree(ldev);
> return -ENODEV;
> }
>
>
^ permalink raw reply
* [PATCH] sound/soc/fsl/fsl_dma.c: add missing of_node_put
From: Julia Lawall @ 2011-08-20 7:23 UTC (permalink / raw)
To: Timur Tabi
Cc: alsa-devel, Takashi Iwai, devicetree-discuss, Mark Brown,
kernel-janitors, linux-kernel, Jaroslav Kysela, linuxppc-dev,
Liam Girdwood
From: Julia Lawall <julia@diku.dk>
of_parse_phandle increments the reference count of np, so this should be
decremented before trying the next possibility.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression e,e1,e2;
@@
*e = of_parse_phandle(...)
... when != of_node_put(e)
when != true e == NULL
when != e2 = e
e = e1
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
sound/soc/fsl/fsl_dma.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sound/soc/fsl/fsl_dma.c b/sound/soc/fsl/fsl_dma.c
index 0efc04a..b33271b 100644
--- a/sound/soc/fsl/fsl_dma.c
+++ b/sound/soc/fsl/fsl_dma.c
@@ -880,10 +880,12 @@ static struct device_node *find_ssi_node(struct device_node *dma_channel_np)
np = of_parse_phandle(ssi_np, "fsl,playback-dma", 0);
if (np == dma_channel_np)
return ssi_np;
+ of_node_put(np);
np = of_parse_phandle(ssi_np, "fsl,capture-dma", 0);
if (np == dma_channel_np)
return ssi_np;
+ of_node_put(np);
}
return NULL;
^ permalink raw reply related
* [PATCH 2/2] sound/soc/fsl/mpc8610_hpcd.c: add missing of_node_put
From: Julia Lawall @ 2011-08-20 7:02 UTC (permalink / raw)
To: Timur Tabi
Cc: alsa-devel, Takashi Iwai, devicetree-discuss, Mark Brown,
kernel-janitors, linux-kernel, Jaroslav Kysela, linuxppc-dev,
Liam Girdwood
From: Julia Lawall <julia@diku.dk>
The first change is to add an of_node_put, since codec_np has previously
been allocated. The rest of the patch reorganizes the error handling code
so the only code executed is that which is needed.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
identifier x;
expression E1!=0,E2,E3,E4;
statement S;
iterator I;
@@
(
if (...) { ... when != of_node_put(x)
when != x = E3
when != E3 = x
* return ...;
}
... when != x = E2
when != I(...,x,...) S
if (...) { ... when != x = E4
of_node_put(x); ... return ...; }
)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
sound/soc/fsl/mpc8610_hpcd.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/sound/soc/fsl/mpc8610_hpcd.c b/sound/soc/fsl/mpc8610_hpcd.c
index a192979..358f0ba 100644
--- a/sound/soc/fsl/mpc8610_hpcd.c
+++ b/sound/soc/fsl/mpc8610_hpcd.c
@@ -345,8 +345,10 @@ static int mpc8610_hpcd_probe(struct platform_device *pdev)
}
machine_data = kzalloc(sizeof(struct mpc8610_hpcd_data), GFP_KERNEL);
- if (!machine_data)
- return -ENOMEM;
+ if (!machine_data) {
+ ret = -ENOMEM;
+ goto error_alloc;
+ }
machine_data->dai[0].cpu_dai_name = dev_name(&ssi_pdev->dev);
machine_data->dai[0].ops = &mpc8610_hpcd_ops;
@@ -494,7 +496,7 @@ static int mpc8610_hpcd_probe(struct platform_device *pdev)
ret = platform_device_add(sound_device);
if (ret) {
dev_err(&pdev->dev, "platform device add failed\n");
- goto error;
+ goto error_sound;
}
dev_set_drvdata(&pdev->dev, sound_device);
@@ -502,14 +504,12 @@ static int mpc8610_hpcd_probe(struct platform_device *pdev)
return 0;
+error_sound:
+ platform_device_unregister(sound_device);
error:
- of_node_put(codec_np);
-
- if (sound_device)
- platform_device_unregister(sound_device);
-
kfree(machine_data);
-
+error_alloc:
+ of_node_put(codec_np);
return ret;
}
^ permalink raw reply related
* [PATCH 4/4] sound/aoa/fabrics/layout.c: remove unneeded kfree
From: Julia Lawall @ 2011-08-20 6:12 UTC (permalink / raw)
To: Johannes Berg
Cc: alsa-devel, Takashi Iwai, devicetree-discuss, kernel-janitors,
linux-kernel, Jaroslav Kysela, linuxppc-dev
From: Julia Lawall <julia@diku.dk>
The label outnodev is only used when kzalloc has not yet taken place or has
failed, so there is no need for the call for kfree under this label.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
identifier x;
expression E1!=0,E2,E3,E4;
statement S;
iterator I;
@@
(
if (...) { ... when != kfree(x)
when != x = E3
when != E3 = x
* return ...;
}
... when != x = E2
when != I(...,x,...) S
if (...) { ... when != x = E4
kfree(x); ... return ...; }
)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
sound/aoa/fabrics/layout.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/aoa/fabrics/layout.c b/sound/aoa/fabrics/layout.c
index 3fd1a7e..552b97a 100644
--- a/sound/aoa/fabrics/layout.c
+++ b/sound/aoa/fabrics/layout.c
@@ -1073,10 +1073,10 @@ static int aoa_fabric_layout_probe(struct soundbus_dev *sdev)
sdev->pcmid = -1;
list_del(&ldev->list);
layouts_list_items--;
+ kfree(ldev);
outnodev:
of_node_put(sound);
layout_device = NULL;
- kfree(ldev);
return -ENODEV;
}
^ permalink raw reply related
* Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Scott Wood @ 2011-08-19 18:10 UTC (permalink / raw)
To: Matthieu CASTET
Cc: linuxppc-dev@ozlabs.org, LiuShuo, dwmw2@infradead.org,
linux-mtd@lists.infradead.org
In-Reply-To: <4E4E2571.20409@parrot.com>
On 08/19/2011 03:57 AM, Matthieu CASTET wrote:
> LiuShuo a =C3=A9crit :
>> =E4=BA=8E 2011=E5=B9=B408=E6=9C=8819=E6=97=A5 01:00, Matthieu CASTET =E5=
=86=99=E9=81=93:
>>> b35362@freescale.com a =C3=A9crit :
>>>> From: Liu Shuo<b35362@freescale.com>
>>>>
>>>> Freescale FCM controller has a 2K size limitation of buffer RAM. In =
order
>>>> to support the Nand flash chip whose page size is larger than 2K byt=
es,
>>>> we divide a page into multi-2K pages for MTD layer driver. In that c=
ase,
>>>> we force to set the page size to 2K bytes. We convert the page addre=
ss of
>>>> MTD layer driver to a real page address in flash chips and a column =
index
>>>> in fsl_elbc driver. We can issue any column address by UA instructio=
n of
>>>> elbc controller.
>>>>
>>> Why do you need to do that ?
>>>
>>> When mtd send you a 4k page, why can't you write it by 2*2k pages wri=
te ?
>> 1. It's easy to implement.
>> 2. We don't need to move the data in buffer more times, because we
>> want to use the HW_ECC.
>>
>> In flash chip per Page:
>> ----------------------------------------------------------------
>> | first data | first oob | second data | second oob |
>> ----------------------------------------------------------------
> How the bad block marker are handled with this remapping ?
It has to be migrated prior to first use (this needs to be documented,
and ideally a U-Boot command provided do do this), or else special
handling would be needed when building the BBT. The only way around
this would be to do ECC in software, and do the buffering needed to let
MTD treat it as a 4K chip.
-Scott
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox