* 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
* [PATCH 40/75] pasemi: convert to SKB paged frag API.
From: Ian Campbell @ 2011-08-19 13:27 UTC (permalink / raw)
To: netdev
Cc: Ian Campbell, devicetree-discuss, linux-kernel, Olof Johansson,
linuxppc-dev
In-Reply-To: <1313760393.5010.356.camel@zakaz.uk.xensource.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Olof Johansson <olof@lixom.net>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: netdev@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree-discuss@lists.ozlabs.org
---
drivers/net/pasemi_mac.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/pasemi_mac.c b/drivers/net/pasemi_mac.c
index 9ec112c..3cd2cd3 100644
--- a/drivers/net/pasemi_mac.c
+++ b/drivers/net/pasemi_mac.c
@@ -1505,9 +1505,8 @@ static int pasemi_mac_start_tx(struct sk_buff *skb, struct net_device *dev)
for (i = 0; i < nfrags; i++) {
skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
- map[i+1] = pci_map_page(mac->dma_pdev, frag->page,
- frag->page_offset, frag->size,
- PCI_DMA_TODEVICE);
+ map[i + 1] = skb_frag_dma_map(&mac->dma_pdev->dev, frag, 0,
+ frag->size, PCI_DMA_TODEVICE);
map_size[i+1] = frag->size;
if (pci_dma_mapping_error(mac->dma_pdev, map[i+1])) {
nfrags = i;
--
1.7.2.5
^ permalink raw reply related
* Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Matthieu CASTET @ 2011-08-19 8:57 UTC (permalink / raw)
To: LiuShuo
Cc: linuxppc-dev@ozlabs.org, dwmw2@infradead.org,
linux-mtd@lists.infradead.org
In-Reply-To: <4E4DD661.5080006@freescale.com>
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 ?
Mtd will search in the first oob, but this will be the data zone of the nand,
not where manufacturer put marker.
Matthieu
^ permalink raw reply
* [PATCH 2/2] [PowerPC Book3E] Introduce new ptrace debug feature flag
From: K.Prasad @ 2011-08-19 7:53 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Thiago Jung Bauermann, Edjunior Barbosa Machado, dwg
In-Reply-To: <20110819074527.GA21817@in.ibm.com>
While PPC_PTRACE_SETHWDEBUG ptrace flag in PowerPC accepts
PPC_BREAKPOINT_MODE_EXACT mode of breakpoint, the same is not intimated to the
user-space debuggers (like GDB) who may want to use it. Hence we introduce a
new PPC_DEBUG_FEATURE_DATA_BP_EXACT flag which will be populated on the
"features" member of "struct ppc_debug_info" to advertise support for the
same on Book3E PowerPC processors.
Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/ptrace.h | 1 +
arch/powerpc/kernel/ptrace.c | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/ptrace.h b/arch/powerpc/include/asm/ptrace.h
index 48223f9..cf014f9 100644
--- a/arch/powerpc/include/asm/ptrace.h
+++ b/arch/powerpc/include/asm/ptrace.h
@@ -380,6 +380,7 @@ struct ppc_debug_info {
#define PPC_DEBUG_FEATURE_INSN_BP_MASK 0x0000000000000002
#define PPC_DEBUG_FEATURE_DATA_BP_RANGE 0x0000000000000004
#define PPC_DEBUG_FEATURE_DATA_BP_MASK 0x0000000000000008
+#define PPC_DEBUG_FEATURE_DATA_BP_EXACT 0x0000000000000010
#ifndef __ASSEMBLY__
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 18d28b6..71db5a6 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -1636,6 +1636,7 @@ long arch_ptrace(struct task_struct *child, long request,
#ifdef CONFIG_PPC_ADV_DEBUG_DAC_RANGE
dbginfo.features |=
PPC_DEBUG_FEATURE_DATA_BP_RANGE |
+ PPC_DEBUG_FEATURE_DATA_BP_EXACT |
PPC_DEBUG_FEATURE_DATA_BP_MASK;
#endif
#else /* !CONFIG_PPC_ADV_DEBUG_REGS */
--
1.7.4.1
^ permalink raw reply related
* [PATCH 1/2] [hw-breakpoint] Use generic hw-breakpoint interfaces for new PPC ptrace flags
From: K.Prasad @ 2011-08-19 7:51 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Thiago Jung Bauermann, Edjunior Barbosa Machado, dwg
In-Reply-To: <20110819074527.GA21817@in.ibm.com>
PPC_PTRACE_GETHWDBGINFO, PPC_PTRACE_SETHWDEBUG and PPC_PTRACE_DELHWDEBUG are
PowerPC specific ptrace flags that use the watchpoint register. While they are
targeted primarily towards BookE users, user-space applications such as GDB
have started using them for BookS too.
This patch enables the use of generic hardware breakpoint interfaces for these
new flags. The version number of the associated data structures
"ppc_hw_breakpoint" and "ppc_debug_info" is incremented to denote new semantics.
Apart from the usual benefits of using generic hw-breakpoint interfaces, these
changes allow debuggers (such as GDB) to use a common set of ptrace flags for
their watchpoint needs and allow more precise breakpoint specification (length
of the variable can be specified).
[Edjunior: Identified an issue in the patch with the sanity check for version
numbers]
Tested-by: Edjunior Barbosa Machado <emachado@linux.vnet.ibm.com>
Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com>
---
Documentation/powerpc/ptrace.txt | 16 ++++++
arch/powerpc/kernel/ptrace.c | 104 +++++++++++++++++++++++++++++++++++---
2 files changed, 112 insertions(+), 8 deletions(-)
diff --git a/Documentation/powerpc/ptrace.txt b/Documentation/powerpc/ptrace.txt
index f4a5499..97301ae 100644
--- a/Documentation/powerpc/ptrace.txt
+++ b/Documentation/powerpc/ptrace.txt
@@ -127,6 +127,22 @@ Some examples of using the structure to:
p.addr2 = (uint64_t) end_range;
p.condition_value = 0;
+- set a watchpoint in server processors (BookS) using version 2
+
+ p.version = 2;
+ p.trigger_type = PPC_BREAKPOINT_TRIGGER_RW;
+ p.addr_mode = PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE;
+ or
+ p.addr_mode = PPC_BREAKPOINT_MODE_RANGE_EXACT;
+
+ p.condition_mode = PPC_BREAKPOINT_CONDITION_NONE;
+ p.addr = (uint64_t) begin_range;
+ /* For PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE addr2 needs to be specified, where
+ * addr2 - addr <= 8 Bytes.
+ */
+ p.addr2 = (uint64_t) end_range;
+ p.condition_value = 0;
+
3. PTRACE_DELHWDEBUG
Takes an integer which identifies an existing breakpoint or watchpoint
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 05b7dd2..18d28b6 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -1339,11 +1339,17 @@ static int set_dac_range(struct task_struct *child,
static long ppc_set_hwdebug(struct task_struct *child,
struct ppc_hw_breakpoint *bp_info)
{
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ int ret, len = 0;
+ struct thread_struct *thread = &(child->thread);
+ struct perf_event *bp;
+ struct perf_event_attr attr;
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
#ifndef CONFIG_PPC_ADV_DEBUG_REGS
unsigned long dabr;
#endif
- if (bp_info->version != 1)
+ if ((bp_info->version != 1) && (bp_info->version != 2))
return -ENOTSUPP;
#ifdef CONFIG_PPC_ADV_DEBUG_REGS
/*
@@ -1382,13 +1388,9 @@ static long ppc_set_hwdebug(struct task_struct *child,
*/
if ((bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_RW) == 0 ||
(bp_info->trigger_type & ~PPC_BREAKPOINT_TRIGGER_RW) != 0 ||
- bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT ||
bp_info->condition_mode != PPC_BREAKPOINT_CONDITION_NONE)
return -EINVAL;
- if (child->thread.dabr)
- return -ENOSPC;
-
if ((unsigned long)bp_info->addr >= TASK_SIZE)
return -EIO;
@@ -1398,15 +1400,86 @@ static long ppc_set_hwdebug(struct task_struct *child,
dabr |= DABR_DATA_READ;
if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_WRITE)
dabr |= DABR_DATA_WRITE;
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ if (bp_info->version == 1)
+ goto version_one;
+ if (ptrace_get_breakpoints(child) < 0)
+ return -ESRCH;
- child->thread.dabr = dabr;
+ bp = thread->ptrace_bps[0];
+ if (!bp_info->addr) {
+ if (bp) {
+ unregister_hw_breakpoint(bp);
+ thread->ptrace_bps[0] = NULL;
+ }
+ ptrace_put_breakpoints(child);
+ return 0;
+ }
+ /*
+ * Check if the request is for 'range' breakpoints. We can
+ * support it if range < 8 bytes.
+ */
+ if (bp_info->addr_mode == PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE)
+ len = bp_info->addr2 - bp_info->addr;
+ else if (bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT) {
+ ptrace_put_breakpoints(child);
+ return -EINVAL;
+ }
+ if (bp) {
+ attr = bp->attr;
+ attr.bp_addr = (unsigned long)bp_info->addr & ~HW_BREAKPOINT_ALIGN;
+ arch_bp_generic_fields(dabr &
+ (DABR_DATA_WRITE | DABR_DATA_READ),
+ &attr.bp_type);
+ attr.bp_len = len;
+ ret = modify_user_hw_breakpoint(bp, &attr);
+ if (ret) {
+ ptrace_put_breakpoints(child);
+ return ret;
+ }
+ thread->ptrace_bps[0] = bp;
+ ptrace_put_breakpoints(child);
+ thread->dabr = dabr;
+ return 0;
+ }
+ /* Create a new breakpoint request if one doesn't exist already */
+ hw_breakpoint_init(&attr);
+ attr.bp_addr = (unsigned long)bp_info->addr & ~HW_BREAKPOINT_ALIGN;
+ attr.bp_len = len;
+ arch_bp_generic_fields(dabr & (DABR_DATA_WRITE | DABR_DATA_READ),
+ &attr.bp_type);
+
+ thread->ptrace_bps[0] = bp = register_user_hw_breakpoint(&attr,
+ ptrace_triggered, NULL, child);
+ if (IS_ERR(bp)) {
+ thread->ptrace_bps[0] = NULL;
+ ptrace_put_breakpoints(child);
+ return PTR_ERR(bp);
+ }
+
+ ptrace_put_breakpoints(child);
+ return 1;
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
+
+version_one:
+ if (bp_info->addr_mode != PPC_BREAKPOINT_MODE_EXACT)
+ return -EINVAL;
+
+ if (child->thread.dabr)
+ return -ENOSPC;
+
+ child->thread.dabr = dabr;
return 1;
#endif /* !CONFIG_PPC_ADV_DEBUG_DVCS */
}
static long ppc_del_hwdebug(struct task_struct *child, long addr, long data)
{
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ struct thread_struct *thread = &(child->thread);
+ struct perf_event *bp;
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
#ifdef CONFIG_PPC_ADV_DEBUG_REGS
int rc;
@@ -1426,10 +1499,24 @@ static long ppc_del_hwdebug(struct task_struct *child, long addr, long data)
#else
if (data != 1)
return -EINVAL;
+
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ if (ptrace_get_breakpoints(child) < 0)
+ return -ESRCH;
+
+ bp = thread->ptrace_bps[0];
+ if (bp) {
+ unregister_hw_breakpoint(bp);
+ thread->ptrace_bps[0] = NULL;
+ }
+ ptrace_put_breakpoints(child);
+ return 0;
+#else /* CONFIG_HAVE_HW_BREAKPOINT */
if (child->thread.dabr == 0)
return -ENOENT;
child->thread.dabr = 0;
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
return 0;
#endif
@@ -1536,7 +1623,8 @@ long arch_ptrace(struct task_struct *child, long request,
case PPC_PTRACE_GETHWDBGINFO: {
struct ppc_debug_info dbginfo;
- dbginfo.version = 1;
+ /* We return the highest version number supported */
+ dbginfo.version = 2;
#ifdef CONFIG_PPC_ADV_DEBUG_REGS
dbginfo.num_instruction_bps = CONFIG_PPC_ADV_DEBUG_IACS;
dbginfo.num_data_bps = CONFIG_PPC_ADV_DEBUG_DACS;
@@ -1560,7 +1648,7 @@ long arch_ptrace(struct task_struct *child, long request,
dbginfo.data_bp_alignment = 4;
#endif
dbginfo.sizeof_condition = 0;
- dbginfo.features = 0;
+ dbginfo.features = PPC_DEBUG_FEATURE_DATA_BP_RANGE;
#endif /* CONFIG_PPC_ADV_DEBUG_REGS */
if (!access_ok(VERIFY_WRITE, datavp,
--
1.7.4.1
^ permalink raw reply related
* [PATCH 0/2] Changes to PowerPC ptrace flags using watchpoints
From: K.Prasad @ 2011-08-19 7:45 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Thiago Jung Bauermann, Edjunior Barbosa Machado, dwg
Hi All,
Please find a set of two patches that introduce generic
hw-breakpoint interfaces for a couple of ptrace flags used by server-class
processors and another change to advertise a feature to user-space hitherto
available and used, but not claimed as supported.
GDB, which recently began using the
PPC_PTRACE_GETHWDBGINFO/PPC_PTRACE_SETHWDEBUG/PPC_PTRACE_DELHWDEBUG
flags on BookS processors is presently unable to set watchpoints. The
changes in Patch1, will fix that issue and help it use a common set of code
across BookE and BookS.
K.Prasad (2):
[hw-breakpoint] Use generic hw-breakpoint interfaces for new PPC
ptrace flags
[PowerPC Book3E] Introduce new ptrace debug feature flag
Documentation/powerpc/ptrace.txt | 16 ++++++
arch/powerpc/include/asm/ptrace.h | 1 +
arch/powerpc/kernel/ptrace.c | 105
++++++++++++++++++++++++++++++++++---
3 files changed, 114 insertions(+), 8 deletions(-)
Thanks,
K.Prasad
^ permalink raw reply
* Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: LiuShuo @ 2011-08-19 3:20 UTC (permalink / raw)
To: Matthieu CASTET
Cc: linuxppc-dev@ozlabs.org, dwmw2@infradead.org,
linux-mtd@lists.infradead.org
In-Reply-To: <4E4D452C.7050805@parrot.com>
=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 or=
der
>> 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 cas=
e,
>> 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 in=
dex
>> 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 |
----------------------------------------------------------------
> Even better send the first 2K and then if your controller allow it send=
the
> remaining 2K without command/address phase.
The elbc controller don't allow that.
I have to send twice Program CMD for writing the whole 4KB data.
>
> Matthieu
>
^ permalink raw reply
* Question about mem parameter in the bootargs
From: Carlos Roberto Moratelli @ 2011-08-18 20:40 UTC (permalink / raw)
To: linuxppc-dev
Hi,
Does someone knows what is the smallest step to increase the mem
parameter in the bootargs?
I am running linux in an embedded system where I have a very critical
memory constraint and I would like to have mem=3584k instead mem=3M or
mem=4M.
The Linux boot up sucessfull with mem=3M or mem=4M but the kernel
crashes with mem=3584k.
thank you
Moratelli
^ permalink raw reply
* Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Scott Wood @ 2011-08-18 18:27 UTC (permalink / raw)
To: b35362; +Cc: linuxppc-dev, dwmw2, linux-mtd
In-Reply-To: <4E4D3CE0.7020602@freescale.com>
On 08/18/2011 11:25 AM, Scott Wood wrote:
> The NOP restrictions should be documented in the code itself, not just
> in the git changelog. Maybe print it to the console when this hack is
> used, along with the NOP value read from the ID. If it's less than 4
> for 4K or 8 for 8K, also print a message saying not to use jffs2 (does
> yaffs2 do similar things?). If it's less than 2 for 4K or 4 for 8K, the
> probe should fail.
We should also warn the user about the need to prepare the NAND chip by
copying the bad block markers to the OOB of the new layout.
-Scott
^ permalink raw reply
* Re: [PATCH v3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Scott Wood @ 2011-08-18 18:24 UTC (permalink / raw)
To: Matthieu CASTET
Cc: linuxppc-dev@ozlabs.org, b35362@freescale.com,
dwmw2@infradead.org, linux-mtd@lists.infradead.org
In-Reply-To: <4E4D452C.7050805@parrot.com>
On 08/18/2011 12:00 PM, Matthieu CASTET wrote:
> b35362@freescale.com a =E9crit :
>> From: Liu Shuo <b35362@freescale.com>
>>
>> Freescale FCM controller has a 2K size limitation of buffer RAM. In or=
der
>> 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 cas=
e,
>> 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 in=
dex
>> in fsl_elbc driver. We can issue any column address by UA instruction =
of
>> elbc controller.
>>
> Why do you need to do that ?
>=20
> When mtd send you a 4k page, why can't you write it by 2*2k pages write=
?
That would be more complicated given the statefulness of the interface,
for no real benefit.
> Even better send the first 2K and then if your controller allow it send=
the
> remaining 2K without command/address phase.
IIRC Shuo tried this first and couldn't make it work.
-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