* Re: [PATCH 3/5] of/device: Make of_get_next_child() check status properties
From: Hollis Blanchard @ 2010-12-15 18:35 UTC (permalink / raw)
To: Michael Ellerman, Scott Wood, devicetree-discuss, linuxppc-dev
In-Reply-To: <20101209030924.GC11856@yookeroo>
On Wed, Dec 8, 2010 at 7:09 PM, David Gibson
<david@gibson.dropbear.id.au> wrote:
> On Thu, Dec 09, 2010 at 12:33:22PM +1100, Michael Ellerman wrote:
>> On Wed, 2010-12-08 at 15:01 -0600, Scott Wood wrote:
>> > On Wed, 8 Dec 2010 11:29:44 -0800
>> > Deepak Saxena <deepak_saxena@mentor.com> wrote:
>> >
>> > > We only return the next child if the device is available.
>> > >
>> > > Signed-off-by: Hollis Blanchard <hollis_blanchard@mentor.com>
>> > > Signed-off-by: Deepak Saxena <deepak_saxena@mentor.com>
>> > > ---
>> > > =A0drivers/of/base.c | =A0 =A04 +++-
>> > > =A01 files changed, 3 insertions(+), 1 deletions(-)
>> > >
>> > > diff --git a/drivers/of/base.c b/drivers/of/base.c
>> > > index 5d269a4..81b2601 100644
>> > > --- a/drivers/of/base.c
>> > > +++ b/drivers/of/base.c
>> > > @@ -321,6 +321,8 @@ struct device_node *of_get_next_parent(struct de=
vice_node *node)
>> > > =A0 *
>> > > =A0 * =A0 =A0 =A0 Returns a node pointer with refcount incremented, =
use
>> > > =A0 * =A0 =A0 =A0 of_node_put() on it when done.
>> > > + *
>> > > + * =A0 =A0 =A0 Does not return nodes marked unavailable by a status=
property.
>> > > =A0 */
>> > > =A0struct device_node *of_get_next_child(const struct device_node *n=
ode,
>> > > =A0 struct device_node *prev)
>> > > @@ -330,7 +332,7 @@ struct device_node *of_get_next_child(const stru=
ct device_node *node,
>> > > =A0 read_lock(&devtree_lock);
>> > > =A0 next =3D prev ? prev->sibling : node->child;
>> > > =A0 for (; next; next =3D next->sibling)
>> > > - =A0 =A0 =A0 =A0 if (of_node_get(next))
>> > > + =A0 =A0 =A0 =A0 if (of_device_is_available(next) && of_node_get(ne=
xt))
>> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;
>> > > =A0 of_node_put(prev);
>> > > =A0 read_unlock(&devtree_lock);
>> >
>> > This seems like too low-level a place to put this. =A0Some code may kn=
ow
>> > how to un-disable a device in certain situations, or it may be part of
>> > debug code trying to dump the whole device tree, etc. =A0Looking
>> > further[1], I see a raw version of this function, but not other things
>> > like of_find_compatible_node.
>>
>> Yeah I agree. I think we'll eventually end up with __ versions of all or
>> lots of them. Not to mention there might be cases you've missed where
>> code expects to see unavailable nodes. The right approach is to add
>> _new_ routines that don't return unavailable nodes, and convert code
>> that you know wants to use them.
>
> Actually, I don't think we really want these status-skipping
> iterators at all. =A0The device tree iterators should give us the device
> tree, as it is. =A0Those old-style drivers which seach for a node rather
> than using the bus probing logic can keep individual checks of the
> status property until they're converted to the new scheme.
So the patch should look something like this?
@@ -321,6 +321,8 @@ struct device_node *of_get_next_parent(struct
device_node *node)
*
* Returns a node pointer with refcount incremented, use
* of_node_put() on it when done.
+ *
+ * Do not use this function.
*/
struct device_node *of_get_next_child(const struct device_node *node,
struct device_node *prev)
...
+ struct device_node *of_get_next_available_child(const struct
device_node *node,
+ struct device_node *prev)
+ ...
+ }
And then (almost) all the of_get_next_child() sites should be changed
to call the new function?
-Hollis
^ permalink raw reply
* Re: Force FB off
From: Rui Santos @ 2010-12-15 14:51 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: linuxppc-dev, linux-fbdev, Dave Airlie
In-Reply-To: <alpine.LNX.2.01.1012151430220.2052@obet.zrqbmnf.qr>
Hi Jan,
You could boot with "vga=normal i915.modeset=0". This will provide
you with a 25x80 console.
You can also use vga=ext for an somethingx50 console.
Regards,
Rui
On 15-12-2010 13:39, Jan Engelhardt wrote:
> On Tuesday 2010-12-14 21:18, Dave Airlie wrote:
>> On Wed, Dec 15, 2010 at 3:41 AM, Jan Engelhardt<jengelh@medozas.de> wrote:
>>
>>> booting with video=off nor video=i915:off has any effect on skipping
>>> FB. What is the correct option to stop FB from taking over my boot
>>> consoles?
>> For KMS its not fb taking over its the drm i915 driver, nomodeset will
>> stop it however X will no longer work since it relies on the kernel
>> driver.
> That would make sense. Furthermore I discovered that video=vesafb:off
> also has no effect, but here it is clear because the source code ignores
> the return value of fb_get_options, and so ignores any off command.
>
> The real strange thing is that video=offb:off on an Apple Xserve G5
> PPC64, while probably skipping OFFB initialization, still ends up in a
> 640x480 mode with a 8x16 font instead of retaining the PROM
> console/font.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
Cumprimentos
*Rui Santos*
Email: rsantos@grupopie.com <mailto:rsantos@grupopie.com>
^ permalink raw reply
* RE: RapidIO: multiple mport support for QorIQ
From: Bounine, Alexandre @ 2010-12-15 14:02 UTC (permalink / raw)
To: Thomas Taranowski, linuxppc-dev
In-Reply-To: <AANLkTinwP6kQvWjSO3cxNUqd7tx7dhGEShTdKQXj-+iD@mail.gmail.com>
Thomas Taranowski wrote:
=20
> I'm planning to add support for the multiple(2) mports supported by
> the Freescale p2020 processor. I'm currently looking at the fsl layer
> to add in support for multiple port enumeration, and work up from
> there. It looks like the upper layers already have at least partial
> support for this. My question is, are there any efforts already
> ongoing I can hop in on so as not to duplicate effort? If not, I'll
> just do it.
>=20
I am working on multiple port support in RapidIO subsystem.
This work is not related to FSL driver - I have a PCI RapidIO controller
which will be added into the subsystem as well. If everything goes as
planned, I hope to publish the first version of new patches in the
second half of January.
=20
=20
^ permalink raw reply
* Re: Force FB off
From: Jan Engelhardt @ 2010-12-15 13:39 UTC (permalink / raw)
To: Dave Airlie; +Cc: linux-fbdev, linuxppc-dev
In-Reply-To: <AANLkTimEh+2rEFuq7q+wLcfHw_UKKHVipC0t7mFwSzx8@mail.gmail.com>
On Tuesday 2010-12-14 21:18, Dave Airlie wrote:
>On Wed, Dec 15, 2010 at 3:41 AM, Jan Engelhardt <jengelh@medozas.de> wrote:
>
>>
>>booting with video=off nor video=i915:off has any effect on skipping
>>FB. What is the correct option to stop FB from taking over my boot
>>consoles?
>
>For KMS its not fb taking over its the drm i915 driver, nomodeset will
>stop it however X will no longer work since it relies on the kernel
>driver.
That would make sense. Furthermore I discovered that video=vesafb:off
also has no effect, but here it is clear because the source code ignores
the return value of fb_get_options, and so ignores any off command.
The real strange thing is that video=offb:off on an Apple Xserve G5
PPC64, while probably skipping OFFB initialization, still ends up in a
640x480 mode with a 8x16 font instead of retaining the PROM
console/font.
^ permalink raw reply
* Unbalanced enable for IRQ => phy_change
From: Jean-Michel Hautbois @ 2010-12-15 13:11 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <AANLkTi=vd4J8DfnLgPROrNC2Q-jxSCsrv=nv371Rhq5i@mail.gmail.com>
Hi !
I am currently using a MPC8548 PowerPC board, and I have encountered
the following problem :
[ =C2=A0 19.867849] Unbalanced enable for IRQ 48
[ =C2=A0 19.867855] ------------[ cut here ]------------
[ =C2=A0 19.873819] Badness at /.../kernel/irq/manage.c:174
[ =C2=A0 19.873823] NIP: c0044acc LR: c0044acc CTR: c0018480
[ =C2=A0 19.873828] REGS: dfc2be60 TRAP: 0700 =C2=A0 Tainted: P
(2.6.24.7_www.men.de_1.1)
[ =C2=A0 19.873831] MSR: 00021000 <ME> =C2=A0CR: 24000022 =C2=A0XER: 000000=
00
[ =C2=A0 19.873839] TASK =3D dfc204e0[5] 'events/0' THREAD: dfc2a000
[ =C2=A0 19.873842] GPR00: c0044acc dfc2bf10 dfc204e0 0000002f 00021000
00000000 00000000 00000000
[ =C2=A0 19.873854] GPR08: 00000034 ffffffff 0000574e de821b20 24000024
100607bc 00008000 00001020
[ =C2=A0 19.873865] GPR16: c0447b44 c0447b2c 00fff018 033327d2 00000008
c044b2c8 c048d1a8 c044b300
[ =C2=A0 19.873877] GPR24: dfc206a0 dfc204e0 dfc01f30 dfc2a000 00029000
c04cb714 00000030 c04cb6e4
[ =C2=A0 19.873890] NIP [c0044acc] enable_irq+0x6c/0xdc
[ =C2=A0 19.873903] LR [c0044acc] enable_irq+0x6c/0xdc
[ =C2=A0 19.873908] Call Trace:
[ =C2=A0 19.873911] [dfc2bf10] [c0044acc] enable_irq+0x6c/0xdc (unreliable)
[ =C2=A0 19.873919] [dfc2bf30] [c0217868] phy_change+0x74/0xe4
[ =C2=A0 19.873926] [dfc2bf50] [c002fb2c] run_workqueue+0xc4/0x15c
[ =C2=A0 19.873933] [dfc2bf90] [c002ffb0] worker_thread+0x74/0xd4
[ =C2=A0 19.873940] [dfc2bfd0] [c0034360] kthread+0x48/0x84
[ =C2=A0 19.873946] [dfc2bff0] [c00047bc] kernel_thread+0x44/0x60
[ =C2=A0 19.873953] Instruction dump:
[ =C2=A0 19.873957] 7fe04a14 3bbf0030 7fa3eb78 483a9461 813f001c 7c7c1b78
2f890000 409e0038
[ =C2=A0 19.873968] 3c60c045 7fc4f378 3863f1d4 4bfd9129 <0fe00000> 7fa3eb78
7f84e378 483a91a5
When looking at the phy_change function in drivers/net/phy/phy.c I
have noticed something quite strange :
We are calling phy_disable_interrupts() and after some operations, enable_i=
rq().
The first thing I thought about is why aren't we calling
disable_irq/enable_irq or phy_disable_interrupts/phy_enable_interrupts
but a mix ?
Next, I took a more deep look at phy_disable_interrupts() and
sepcifically at the phy_config_interrupt() function :
=C2=A0 =C2=A0 =C2=A0 =C2=A0int err =3D 0;
=C2=A0 =C2=A0 =C2=A0 =C2=A0phydev->interrupts =3D interrupts;
=C2=A0 =C2=A0 =C2=A0 =C2=A0if (phydev->drv->config_intr)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0err =3D phydev->drv-=
>config_intr(phydev);
=C2=A0 =C2=A0 =C2=A0 =C2=A0return err;
If phydev->drv->config_intr is not implemented (this is my use case :
I am using the drivers/net/gianfar.c driver), then, nothing will be
done, and there is no disable_irq() call.
I don't know what is better : using disable_irq/enable_irq or the phy
specific functions, but I think that we should avoid using a mix...
Am I wrong ?
Thanks in advance,
Regards,
JM
^ permalink raw reply
* [PATCH v6] ppc44x:PHY fixup for USB on canyonlands board
From: Rupjyoti Sarmah @ 2010-12-15 12:27 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel; +Cc: rsarmah
This fix is a reset for USB PHY that requires some amount of time for power to be stable on Canyonlands.
Signed-off-by: Rupjyoti Sarmah <rsarmah@apm.com>
---
changes from previous version:
-- error paths updated
-- leakage of a node corrected
-- iounmap is called on vaddr
arch/powerpc/boot/dts/canyonlands.dts | 11 +++
arch/powerpc/platforms/44x/44x.h | 4 +
arch/powerpc/platforms/44x/Kconfig | 1 -
arch/powerpc/platforms/44x/Makefile | 1 +
arch/powerpc/platforms/44x/canyonlands.c | 134 ++++++++++++++++++++++++++++
arch/powerpc/platforms/44x/ppc44x_simple.c | 1 -
6 files changed, 150 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/platforms/44x/canyonlands.c
diff --git a/arch/powerpc/boot/dts/canyonlands.dts b/arch/powerpc/boot/dts/canyonlands.dts
index a303703..8ff1f3f 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -224,6 +224,11 @@
};
};
+ cpld@2,0 {
+ compatible = "amcc,ppc460ex-bcsr";
+ reg = <2 0x0 0x9>;
+ };
+
ndfc@3,0 {
compatible = "ibm,ndfc";
reg = <0x00000003 0x00000000 0x00002000>;
@@ -320,6 +325,12 @@
interrupts = <0x3 0x4>;
};
+ GPIO0: gpio@ef600b00 {
+ compatible = "ibm,ppc4xx-gpio";
+ reg = <0xef600b00 0x00000048>;
+ gpio-controller;
+ };
+
ZMII0: emac-zmii@ef600d00 {
compatible = "ibm,zmii-460ex", "ibm,zmii";
reg = <0xef600d00 0x0000000c>;
diff --git a/arch/powerpc/platforms/44x/44x.h b/arch/powerpc/platforms/44x/44x.h
index dbc4d2b..63f703e 100644
--- a/arch/powerpc/platforms/44x/44x.h
+++ b/arch/powerpc/platforms/44x/44x.h
@@ -4,4 +4,8 @@
extern u8 as1_readb(volatile u8 __iomem *addr);
extern void as1_writeb(u8 data, volatile u8 __iomem *addr);
+#define GPIO0_OSRH 0xC
+#define GPIO0_TSRH 0x14
+#define GPIO0_ISR1H 0x34
+
#endif /* __POWERPC_PLATFORMS_44X_44X_H */
diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index 0f979c5..f485fc5 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -115,7 +115,6 @@ config CANYONLANDS
bool "Canyonlands"
depends on 44x
default n
- select PPC44x_SIMPLE
select 460EX
select PCI
select PPC4xx_PCI_EXPRESS
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
index 82ff326..6854e73 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_WARP) += warp.o
obj-$(CONFIG_XILINX_VIRTEX_5_FXT) += virtex.o
obj-$(CONFIG_XILINX_ML510) += virtex_ml510.o
obj-$(CONFIG_ISS4xx) += iss4xx.o
+obj-$(CONFIG_CANYONLANDS)+= canyonlands.o
diff --git a/arch/powerpc/platforms/44x/canyonlands.c b/arch/powerpc/platforms/44x/canyonlands.c
new file mode 100644
index 0000000..afc5e8e
--- /dev/null
+++ b/arch/powerpc/platforms/44x/canyonlands.c
@@ -0,0 +1,134 @@
+/*
+ * This contain platform specific code for APM PPC460EX based Canyonlands
+ * board.
+ *
+ * Copyright (c) 2010, Applied Micro Circuits Corporation
+ * Author: Rupjyoti Sarmah <rsarmah@apm.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ */
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <asm/pci-bridge.h>
+#include <asm/ppc4xx.h>
+#include <asm/udbg.h>
+#include <asm/uic.h>
+#include <linux/of_platform.h>
+#include <linux/delay.h>
+#include "44x.h"
+
+#define BCSR_USB_EN 0x11
+
+static __initdata struct of_device_id ppc460ex_of_bus[] = {
+ { .compatible = "ibm,plb4", },
+ { .compatible = "ibm,opb", },
+ { .compatible = "ibm,ebc", },
+ { .compatible = "simple-bus", },
+ {},
+};
+
+static int __init ppc460ex_device_probe(void)
+{
+ of_platform_bus_probe(NULL, ppc460ex_of_bus, NULL);
+
+ return 0;
+}
+machine_device_initcall(canyonlands, ppc460ex_device_probe);
+
+/* Using this code only for the Canyonlands board. */
+
+static int __init ppc460ex_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+ if (of_flat_dt_is_compatible(root, "amcc,canyonlands")) {
+ ppc_pci_set_flags(PPC_PCI_REASSIGN_ALL_RSRC);
+ return 1;
+ }
+ return 0;
+}
+
+/* USB PHY fixup code on Canyonlands kit. */
+
+static int __init ppc460ex_canyonlands_fixup(void)
+{
+ u8 __iomem *bcsr ;
+ void __iomem *vaddr;
+ struct device_node *np;
+ int ret = 0;
+
+ np = of_find_compatible_node(NULL, NULL, "amcc,ppc460ex-bcsr");
+ if (!np) {
+ printk(KERN_ERR "failed did not find amcc, ppc460ex bcsr node\n");
+ return -ENODEV;
+ }
+
+ bcsr = of_iomap(np, 0);
+ of_node_put(np);
+
+ if (!bcsr) {
+ printk(KERN_CRIT "Could not remap bcsr\n");
+ ret = -ENODEV;
+ goto err_bcsr;
+ }
+
+ np = of_find_compatible_node(NULL, NULL, "ibm,ppc4xx-gpio");
+ if (!np) {
+ printk(KERN_ERR "failed did not find ibm,ppc4xx-gpio node\n");
+ return -ENODEV;
+ }
+
+ vaddr = of_iomap(np, 0);
+ of_node_put(np);
+
+ if (!vaddr) {
+ printk(KERN_CRIT "Could not get gpio node address\n");
+ ret = -ENODEV;
+ goto err_gpio;
+ }
+ /* Disable USB, through the BCSR7 bits */
+ setbits8(&bcsr[7], BCSR_USB_EN);
+
+ /* Wait for a while after reset */
+ msleep(100);
+
+ /* Enable USB here */
+ clrbits8(&bcsr[7], BCSR_USB_EN);
+
+ /*
+ * Configure multiplexed gpio16 and gpio19 as alternate1 output
+ * source after USB reset. In this configuration gpio16 will be
+ * USB2HStop and gpio19 will be USB2DStop. For more details refer to
+ * table 34-7 of PPC460EX user manual.
+ */
+ setbits32((vaddr + GPIO0_OSRH), 0x42000000);
+ setbits32((vaddr + GPIO0_TSRH), 0x42000000);
+err_gpio:
+ iounmap(vaddr);
+err_bcsr:
+ iounmap(bcsr);
+ return ret;
+}
+machine_device_initcall(canyonlands, ppc460ex_canyonlands_fixup);
+define_machine(canyonlands) {
+ .name = "Canyonlands",
+ .probe = ppc460ex_probe,
+ .progress = udbg_progress,
+ .init_IRQ = uic_init_tree,
+ .get_irq = uic_get_irq,
+ .restart = ppc4xx_reset_system,
+ .calibrate_decr = generic_calibrate_decr,
+};
diff --git a/arch/powerpc/platforms/44x/ppc44x_simple.c b/arch/powerpc/platforms/44x/ppc44x_simple.c
index 7ddcba3..c81c19c 100644
--- a/arch/powerpc/platforms/44x/ppc44x_simple.c
+++ b/arch/powerpc/platforms/44x/ppc44x_simple.c
@@ -53,7 +53,6 @@ static char *board[] __initdata = {
"amcc,arches",
"amcc,bamboo",
"amcc,bluestone",
- "amcc,canyonlands",
"amcc,glacier",
"ibm,ebony",
"amcc,eiger",
--
1.5.6.3
^ permalink raw reply related
* Re: [PATCH V6 00/10] Add-Synopsys-DesignWare-HS-USB-OTG-driver
From: Neil Jones @ 2010-12-15 10:17 UTC (permalink / raw)
To: tmarri; +Cc: linux-usb, linuxppc-dev
In-Reply-To: <AANLkTinE1sPt4YQJGgW7-RHOsA8vF9HB-joSuryYFXpi@mail.gmail.com>
Hi,
I've looked at the patches but your email states there are 10 patches,
I can't see #1 and #10, only 2- 8 ??
It doesn't look like you have resolved the lockdep issues we have been
seeing, please get in contact as it
would be good to discuss our issues with this driver ( and our distain
for Synopsis ;-) ).
Cheers
Neil
On Mon, Dec 13, 2010 at 3:48 PM, Neil Jones <neiljay@gmail.com> wrote:
> Hi,
>
> We are currently using the latest version of this Synopsis IP in some
> of our customers SoC's.
>
> The latest hardware adds a new DMA mode which is less Interrupt
> intensive as well as a few other features.
>
> I have spent (and im still spending) a long time fixing up this driver
> to be linux standards compliant with the intention of pushing it
> upstream once complete, its still not ready yet.
>
> One of the major issues we had is the driver isn't SMP safe, I've not
> had chance to review your patches yet but have your run the driver
> with lock checking turned on ?
>
> Would it be possible to get the changes for the latest version of the
> IP merged into this driver, I can supply my current version as a
> reference.
>
> In my driver :
>
> Currently host support is working well and i've tested it with
> multiple devices and done the test outlined on
> http://www.linux-usb.org/usbtest/, the driver passed checkpatches and
> runs with lockdeps on and on a SMP system, Im still working on the
> device mode (PCD) part of the driver generally it works, but im still
> getting the odd lock dep warning and a panic on un-loading of certain
> gadget kernel modules. The only issue with our driver is I have not
> converted all the bitfield usage to macros so it might make diffing a
> pain.
>
> Cheers
>
> Neil
>
> On Fri, Dec 10, 2010 at 10:44 PM, Greg KH <greg@kroah.com> wrote:
>> On Wed, Dec 08, 2010 at 04:28:59PM -0800, tmarri@apm.com wrote:
>>> From: Tirumala Marri <tmarri@apm.com>
>>>
>>> v6:
>>> =C2=A01. Replaced register definitions and bit fields with macros.
>>> =C2=A02. Replace printks with dev_dbg or dev_err functions.
>>> =C2=A03. Cleanup some assignments.
>>> =C2=A04. Remove chip specific selections in Kconfig file.
>>
>> There are still a lot of checkpatch errors and warnings in these
>> patches. =C2=A0Patch 1-8 has:
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0total: 64 errors, 126 warnings, 13905 lines c=
hecked
>>
>> Care to fix all of these up in your next submission? =C2=A0I can't take =
these
>> as-is, sorry.
>>
>> And, if you haven't run checkpatch.pl before, odds are you haven't run
>> 'sparse'. =C2=A0Please run that as well and resolve the issues it finds.
>>
>> thanks,
>>
>> greg k-h
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at =C2=A0http://vger.kernel.org/majordomo-info.html
>>
>
^ permalink raw reply
* RE: RapidIO: multiple mport support for QorIQ
From: Li Yang-R58472 @ 2010-12-15 8:04 UTC (permalink / raw)
To: Thomas Taranowski, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <AANLkTinwP6kQvWjSO3cxNUqd7tx7dhGEShTdKQXj-+iD@mail.gmail.com>
PiBTdWJqZWN0OiBSYXBpZElPOiBtdWx0aXBsZSBtcG9ydCBzdXBwb3J0IGZvciBRb3JJUQ0KPiAN
Cj4gSSdtIHBsYW5uaW5nIHRvIGFkZCBzdXBwb3J0IGZvciB0aGUgbXVsdGlwbGUoMikgbXBvcnRz
IHN1cHBvcnRlZCBieSB0aGUgRnJlZXNjYWxlDQo+IHAyMDIwIHByb2Nlc3Nvci4gIEknbSBjdXJy
ZW50bHkgbG9va2luZyBhdCB0aGUgZnNsIGxheWVyIHRvIGFkZCBpbiBzdXBwb3J0IGZvcg0KPiBt
dWx0aXBsZSBwb3J0IGVudW1lcmF0aW9uLCBhbmQgd29yayB1cCBmcm9tIHRoZXJlLiAgSXQgbG9v
a3MgbGlrZSB0aGUgdXBwZXINCj4gbGF5ZXJzIGFscmVhZHkgaGF2ZSBhdCBsZWFzdCBwYXJ0aWFs
IHN1cHBvcnQgZm9yIHRoaXMuICBNeSBxdWVzdGlvbiBpcywgYXJlIHRoZXJlDQo+IGFueSBlZmZv
cnRzIGFscmVhZHkgb25nb2luZyBJIGNhbiBob3AgaW4gb24gc28gYXMgbm90IHRvIGR1cGxpY2F0
ZSBlZmZvcnQ/ICBJZiBub3QsDQo+IEknbGwganVzdCBkbyBpdC4NCj4gDQoNCkknbSBub3QgYXdh
cmUgb2Ygc29tZW9uZSB3b3JraW5nIG9uIHRoYXQuDQoNCj4gVGhlcmUgaXMgc29tZSBkaXZlcmdh
bmNlIGluIHJlc3BlY3QgdG8gdGhlIG1lbW9yeSBtYXAgdGhhdCBpcyBub24tdHJpdmlhbCB0aGF0
DQo+IEknbSBub3Qgc3VyZSBob3cgdG8gaGFuZGxlLCBzaW5jZSBpdCB0b3RhbGx5IGhvc2VzIHRo
ZSBjb21tb24gZnNsX3Jpby5jIHN0cnVjdHVyZXMuDQo+IEkgdGhpbmsgSSB3YW50IHRvIGNyZWF0
ZSBhIG5ldyBzZXQgdGhhdCdzIHAyMDIwIHNwZWNpZmljLCBidXQgaGFzIHBvdGVudGlhbCB0byBi
ZQ0KPiBzaGFyZWQgd2l0aCB0aGUgb3RoZXIgUW9ySVEgc2VyaWVzLCBzbyBkdW1waW5nIHRoZSBw
c2VyaWVzLXNwZWNpZmljIGNvZGUgaW50bw0KPiBwbGF0Zm9ybXMvcHNlcmllcyBzZWVtcyBsaWtl
IGEgcmVhc29uYWJsZSB3YXkgdG8gZ28uICBUaG91Z2h0cz8NCg0KVGhlIGR1YWwtcG9ydCBSSU8g
aXMgdmVyeSBjb21tb24gb24gUW9ySVEgY2hpcHMuICBJIHdvbid0IHN1Z2dlc3QgeW91IGFkZCBQ
MjAyMCBzcGVjaWZpYyBtZW1vcnkgbWFwIGZpbGUuICBUaGUgdHdvIHBvcnQgbWVtb3J5IG1hcCBz
aG91bGQgYWxzbyBiZSBjb21wYXRpYmxlIHdpdGggb25lIHBvcnQgZHJpdmVyLg0KDQotTGVvDQoN
Cg==
^ permalink raw reply
* RapidIO: multiple mport support for QorIQ
From: Thomas Taranowski @ 2010-12-15 7:29 UTC (permalink / raw)
To: linuxppc-dev
I'm planning to add support for the multiple(2) mports supported by
the Freescale p2020 processor. I'm currently looking at the fsl layer
to add in support for multiple port enumeration, and work up from
there. It looks like the upper layers already have at least partial
support for this. My question is, are there any efforts already
ongoing I can hop in on so as not to duplicate effort? If not, I'll
just do it.
There is some divergance in respect to the memory map that is
non-trivial that I'm not sure how to handle, since it totally hoses
the common fsl_rio.c structures. I think I want to create a new set
that's p2020 specific, but has potential to be shared with the other
QorIQ series, so dumping the pseries-specific code into
platforms/pseries seems like a reasonable way to go. Thoughts?
Thanks!
Thomas Taranowski
Certified netburner consultant
baringforge.com
^ permalink raw reply
* [PATCH] pata_mpc52xx: driver needs BMDMA
From: Wolfram Sang @ 2010-12-14 22:32 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-ide, Jeff Garzik, linux-kernel
Found by this build-error:
drivers/ata/pata_mpc52xx.c: In function 'mpc52xx_ata_init_one':
drivers/ata/pata_mpc52xx.c:662: error: 'ata_bmdma_interrupt' undeclared (first use in this function)
So, move the Kconfig entry to the proper location.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
---
drivers/ata/Kconfig | 20 ++++++++++----------
drivers/ata/Makefile | 2 +-
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 11ec911..85756b8 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -128,16 +128,6 @@ config PDC_ADMA
If unsure, say N.
-config PATA_MPC52xx
- tristate "Freescale MPC52xx SoC internal IDE"
- depends on PPC_MPC52xx && PPC_BESTCOMM
- select PPC_BESTCOMM_ATA
- help
- This option enables support for integrated IDE controller
- of the Freescale MPC52xx SoC.
-
- If unsure, say N.
-
config PATA_OCTEON_CF
tristate "OCTEON Boot Bus Compact Flash support"
depends on CPU_CAVIUM_OCTEON
@@ -491,6 +481,16 @@ config PATA_MARVELL
If unsure, say N.
+config PATA_MPC52xx
+ tristate "Freescale MPC52xx SoC internal IDE"
+ depends on PPC_MPC52xx && PPC_BESTCOMM
+ select PPC_BESTCOMM_ATA
+ help
+ This option enables support for integrated IDE controller
+ of the Freescale MPC52xx SoC.
+
+ If unsure, say N.
+
config PATA_NETCELL
tristate "NETCELL Revolution RAID support"
depends on PCI
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index c501af5..2b67c90 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -11,7 +11,6 @@ obj-$(CONFIG_SATA_DWC) += sata_dwc_460ex.o
# SFF w/ custom DMA
obj-$(CONFIG_PDC_ADMA) += pdc_adma.o
-obj-$(CONFIG_PATA_MPC52xx) += pata_mpc52xx.o
obj-$(CONFIG_PATA_OCTEON_CF) += pata_octeon_cf.o
obj-$(CONFIG_SATA_QSTOR) += sata_qstor.o
obj-$(CONFIG_SATA_SX4) += sata_sx4.o
@@ -52,6 +51,7 @@ obj-$(CONFIG_PATA_IT821X) += pata_it821x.o
obj-$(CONFIG_PATA_JMICRON) += pata_jmicron.o
obj-$(CONFIG_PATA_MACIO) += pata_macio.o
obj-$(CONFIG_PATA_MARVELL) += pata_marvell.o
+obj-$(CONFIG_PATA_MPC52xx) += pata_mpc52xx.o
obj-$(CONFIG_PATA_NETCELL) += pata_netcell.o
obj-$(CONFIG_PATA_NINJA32) += pata_ninja32.o
obj-$(CONFIG_PATA_NS87415) += pata_ns87415.o
--
1.7.2.3
^ permalink raw reply related
* Re: ppc_set_hwdebug vs ptrace_set_debugreg
From: Andreas Schwab @ 2010-12-14 18:59 UTC (permalink / raw)
To: prasad; +Cc: linuxppc-dev, Dave Kleikamp, Srikar Dronamraju, Paul Mackerras
In-Reply-To: <20101214125427.GA2443@in.ibm.com>
"K.Prasad" <prasad@linux.vnet.ibm.com> writes:
> How about the revised patch below? It is only compile-tested; have you
> got a quick test case that I can run?
Try the watchpoint tests in gdb.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH 0/4] V3 Add ability to link device blob(s) into vmlinux
From: Dirk Brandewie @ 2010-12-14 17:24 UTC (permalink / raw)
To: dirk.brandewie
Cc: linux-arch, mmarek, microblaze-uclinux, devicetree-discuss,
linux-kernel, sodaville, linuxppc-dev
In-Reply-To: <cover.1291820033.git.dirk.brandewie@gmail.com>
On 12/08/2010 07:01 AM, dirk.brandewie@gmail.com wrote:
> From: Dirk Brandewie<dirk.brandewie@gmail.com>
>
> This patch set adds the ability to link device tree blobs into
> vmlinux.
>
> Patch 1 implements the changes to include/asm-generic/vmlinux.lds.h and
> adds a generic rule for generating DTB objects to be linked vmlinux.
>
> Patch 2 implements linking a DTB into an x86 image.
>
> Patch 3-4 move {powerpc,microblaze}/boot/Makefile to use the dtc rule
> in patch 1.
>
> This patch set has been tested on x86.
>
> Powerpc and Microblaze have been compile tested with and without patch
> 3 and 4 applied.
>
> Changes from V1:
>
> Documentation added for dtc command in Makefile.lib to
> Documentation/kbuild/makefiles.txt
> Separate DTB_ALIGNMENT define removed.
> FORCE removed from dtc rule.
> Removed hardcoded path to dts files from dtc command.
> Moved %.dtb: %.dts rule to arch specific makefiles.
>
> Patch for adding kernel command line option to pass in dtb_compat
> string dropped from this set will be submitted seperately.
>
> Changes from V2:
>
> Rule to create assembly wrapper for blob changed to use Sam Ravnborgs
> suggested implementation.
>
> Rules in architecture specific Makefiles changed to use the cmd
> function instead of the if_changed function.
>
> Dirk Brandewie (4):
> of: Add support for linking device tree blobs into vmlinux
> x86/of: Add building device tree blob(s) into image.
> of/powerpc: Use generic rule to build dtb's
> microblaze/of: Use generic rule to build dtb's
>
> Documentation/kbuild/makefiles.txt | 15 +++++++++++++++
> arch/microblaze/boot/Makefile | 12 +++---------
> arch/powerpc/boot/Makefile | 8 +++-----
> arch/x86/platform/ce4100/Makefile | 10 ++++++++++
> include/asm-generic/vmlinux.lds.h | 13 +++++++++++--
> scripts/Makefile.lib | 23 +++++++++++++++++++++++
> 6 files changed, 65 insertions(+), 16 deletions(-)
>
Any Comments on this patch set?
--Dirk
^ permalink raw reply
* Re: [PATCH 7/7] P2020ds: add event button handler
From: Timur Tabi @ 2010-12-14 16:49 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev
In-Reply-To: <AANLkTimFpONZzSBjXJmDsX2-iYH+YgY_sANYtYq2j5x1@mail.gmail.com>
On Mon, Dec 13, 2010 at 10:24 PM, Li Yang <leoli@freescale.com> wrote:
> Any enabled IRQ is a valid wake-up source for standby. =A0The patch
> enables a board specific interrupt for the purpose of wakeup.
Oh, right. I should have realized that.
>> This patch should probably be split up, since you're adding generic
>> functionality for the IRQ that applies to all 85xx boards, but you
>> only update the device tree for one board.
>
> The IRQ is a board specific one from GPIO which not applicable on all
> 85xx boards.
Doesn't the device tree take care of that? If the node exists, the
IRQ number is specified. Otherwise, the feature is not enabled.
>>> +static irqreturn_t event_isr(int irq, void *dev_id)
>>> +{
>>> +
>>> + =A0 =A0 =A0 printk(KERN_INFO "MPC85xxDS: Event button been pushed.\n"=
);
>>> + =A0 =A0 =A0 return IRQ_HANDLED;
>>> +}
>>
>> Would it make sense to have this be a weak function, so that it would
>> be easier to implement board-specific support?
>
> It's already a board-specific one.
Hmmm.... I guess technically it is, but I wonder if it should be.
>>> +
>>> +static int __init p2020ds_ngpixis_init(void)
>>
>> You're adding a function called "p2020ds_ngpixis_init" to the file
>> "mpc85xx_ds.c". =A0mpc85xx_ds.c supports more than just the P2020DS.
>
> I'm not sure if other DS boards covered by this file has the same functio=
nality.
Well, either it does or it doesn't, but you can't add a p2020-specific
function to mpc85xx_ds.c. You should just rename the function,
because I see no reason why it can't work on other DS boards.
The problem is the compatible string. Each pixis implementation is
different, but they share several common traits. I wonder if we need
to have a generic compatible string for the FPGA node.
>> You should probably choose a less generic name than "event".
>
> Well, it's the name suggested by the board manual. =A0We may change it
> to "event_button" if not too long.
I was thinking something like "fsl-fpga-event".
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 01/19] c/r: extend arch_setup_additional_pages()
From: Dan Smith @ 2010-12-14 16:23 UTC (permalink / raw)
To: x86; +Cc: linux-s390, Oren Laadan, Alexey Dobriyan, linuxppc-dev
In-Reply-To: <1292343307-7870-1-git-send-email-danms@us.ibm.com>
DS> Cc: x86@kernel.org
DS> Cc: linux-s390@vger.kernel.org
DS> Cc: linuxppc-dev@ozlabs.org
DS> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
DS> Signed-off-by: Oren Laadan <orenl@cs.columbia.edu>
My apologies to the above mentioned recipients. I did not mean to
send this out. Please ignore.
--
Dan Smith
IBM Linux Technology Center
email: danms@us.ibm.com
^ permalink raw reply
* [PATCH 06/19] c/r: create syscalls: sys_checkpoint, sys_restart
From: Dan Smith @ 2010-12-14 16:14 UTC (permalink / raw)
To: danms; +Cc: linux-s390, linux-api, x86, Dave Hansen, linuxppc-dev,
Oren Laadan
In-Reply-To: <1292343307-7870-1-git-send-email-danms@us.ibm.com>
From: Oren Laadan <orenl@cs.columbia.edu>
Create trivial sys_checkpoint and sys_restore system calls. They will
enable to checkpoint and restart an entire container, to and from a
checkpoint image file descriptor.
The syscalls take a pid, a file descriptor (for the image file) and
flags as arguments. The pid identifies the top-most (root) task in the
process tree, e.g. the container init: for sys_checkpoint the first
argument identifies the pid of the target container/subtree; for
sys_restart it will identify the pid of restarting root task.
A checkpoint, much like a process coredump, dumps the state of multiple
processes at once, including the state of the container. The checkpoint
image is written to (and read from) the file descriptor directly from
the kernel. This way the data is generated and then pushed out naturally
as resources and tasks are scanned to save their state. This is the
approach taken by, e.g., Zap and OpenVZ.
By using a return value and not a file descriptor, we can distinguish
between a return from checkpoint, a return from restart (in case of a
checkpoint that includes self, i.e. a task checkpointing its own
container, or itself), and an error condition, in a manner analogous
to a fork() call.
We don't use copy_from_user()/copy_to_user() because it requires
holding the entire image in user space, and does not make sense for
restart. Also, we don't use a pipe, pseudo-fs file and the like,
because they work by generating data on demand as the user pulls it
(unless the entire image is buffered in the kernel) and would require
more complex logic. They also would significantly complicate
checkpoint that includes self.
Changelog[v21-rc3]:
- Reorganize code:move checkpoint/* to kernel/checkpoint/*
Changelog[v19-rc1]:
- Add 'int logfd' to prototype of sys_{checkpoint,restart}
Changelog[v18]:
- [John Dykstra] Fix no-dot-config-targets pattern in linux/Makefile
Changelog[v17]:
- Move checkpoint closer to namespaces (kconfig)
- Kill "Enable" in c/r config option
Changelog[v16]:
- Change sys_restart() first argument to be 'pid_t pid'
Changelog[v14]:
- Change CONFIG_CHEKCPOINT_RESTART to CONFIG_CHECKPOINT (Ingo)
- Remove line 'def_bool n' (default is already 'n')
- Add CHECKPOINT_SUPPORT in Kconfig (Nathan Lynch)
Changelog[v5]:
- Config is 'def_bool n' by default
Cc: linux-api@vger.kernel.org
Cc: x86@kernel.org
Cc: linux-s390@vger.kernel.org
Cc: linuxppc-dev@ozlabs.org
Signed-off-by: Oren Laadan <orenl@cs.columbia.edu>
Signed-off-by: Dave Hansen <dave@linux.vnet.ibm.com>
Acked-by: Serge E. Hallyn <serue@us.ibm.com>
Tested-by: Serge E. Hallyn <serue@us.ibm.com>
---
Makefile | 2 +-
arch/x86/Kconfig | 4 +++
arch/x86/include/asm/unistd_32.h | 4 ++-
arch/x86/kernel/syscall_table_32.S | 2 +
include/linux/syscalls.h | 4 +++
init/Kconfig | 2 +
kernel/Makefile | 1 +
kernel/checkpoint/Kconfig | 14 +++++++++++
kernel/checkpoint/Makefile | 5 ++++
kernel/checkpoint/sys.c | 45 ++++++++++++++++++++++++++++++++++++
kernel/sys_ni.c | 4 +++
11 files changed, 85 insertions(+), 2 deletions(-)
create mode 100644 kernel/checkpoint/Kconfig
create mode 100644 kernel/checkpoint/Makefile
create mode 100644 kernel/checkpoint/sys.c
diff --git a/Makefile b/Makefile
index ab5359d..38f5a25 100644
--- a/Makefile
+++ b/Makefile
@@ -421,7 +421,7 @@ endif
no-dot-config-targets := clean mrproper distclean \
cscope TAGS tags help %docs check% coccicheck \
- include/linux/version.h headers_% \
+ checkstack include/linux/version.h headers_% \
kernelversion %src-pkg
config-targets := 0
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index e832768..0e043fa 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -101,6 +101,10 @@ config STACKTRACE_SUPPORT
config HAVE_LATENCYTOP_SUPPORT
def_bool y
+config CHECKPOINT_SUPPORT
+ bool
+ default y if X86_32
+
config MMU
def_bool y
diff --git a/arch/x86/include/asm/unistd_32.h b/arch/x86/include/asm/unistd_32.h
index b766a5e..a2d589f 100644
--- a/arch/x86/include/asm/unistd_32.h
+++ b/arch/x86/include/asm/unistd_32.h
@@ -346,10 +346,12 @@
#define __NR_fanotify_init 338
#define __NR_fanotify_mark 339
#define __NR_prlimit64 340
+#define __NR_checkpoint 341
+#define __NR_restart 342
#ifdef __KERNEL__
-#define NR_syscalls 341
+#define NR_syscalls 343
#define __ARCH_WANT_IPC_PARSE_VERSION
#define __ARCH_WANT_OLD_READDIR
diff --git a/arch/x86/kernel/syscall_table_32.S b/arch/x86/kernel/syscall_table_32.S
index b35786d..13fbe8a 100644
--- a/arch/x86/kernel/syscall_table_32.S
+++ b/arch/x86/kernel/syscall_table_32.S
@@ -340,3 +340,5 @@ ENTRY(sys_call_table)
.long sys_fanotify_init
.long sys_fanotify_mark
.long sys_prlimit64 /* 340 */
+ .long ptregs_checkpoint
+ .long ptregs_restart
diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index cacc27a..20be1a6 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -820,6 +820,10 @@ asmlinkage long sys_fanotify_init(unsigned int flags, unsigned int event_f_flags
asmlinkage long sys_fanotify_mark(int fanotify_fd, unsigned int flags,
u64 mask, int fd,
const char __user *pathname);
+asmlinkage long sys_checkpoint(pid_t pid, int fd, unsigned long flags,
+ int logfd);
+asmlinkage long sys_restart(pid_t pid, int fd, unsigned long flags,
+ int logfd);
int kernel_execve(const char *filename, const char *const argv[], const char *const envp[]);
diff --git a/init/Kconfig b/init/Kconfig
index 88c1046..75650df 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -780,6 +780,8 @@ config RELAY
If unsure, say N.
+source "kernel/checkpoint/Kconfig"
+
config BLK_DEV_INITRD
bool "Initial RAM filesystem and RAM disk (initramfs/initrd) support"
depends on BROKEN || !FRV
diff --git a/kernel/Makefile b/kernel/Makefile
index 0b5ff08..3f6238c 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -106,6 +106,7 @@ obj-$(CONFIG_PERF_EVENTS) += perf_event.o
obj-$(CONFIG_HAVE_HW_BREAKPOINT) += hw_breakpoint.o
obj-$(CONFIG_USER_RETURN_NOTIFIER) += user-return-notifier.o
obj-$(CONFIG_PADATA) += padata.o
+obj-$(CONFIG_CHECKPOINT) += checkpoint/
ifneq ($(CONFIG_SCHED_OMIT_FRAME_POINTER),y)
# According to Alan Modra <alan@linuxcare.com.au>, the -fno-omit-frame-pointer is
diff --git a/kernel/checkpoint/Kconfig b/kernel/checkpoint/Kconfig
new file mode 100644
index 0000000..ef7d406
--- /dev/null
+++ b/kernel/checkpoint/Kconfig
@@ -0,0 +1,14 @@
+# Architectures should define CHECKPOINT_SUPPORT when they have
+# implemented the hooks for processor state etc. needed by the
+# core checkpoint/restart code.
+
+config CHECKPOINT
+ bool "Checkpoint/restart (EXPERIMENTAL)"
+ depends on CHECKPOINT_SUPPORT && EXPERIMENTAL
+ help
+ Application checkpoint/restart is the ability to save the
+ state of a running application so that it can later resume
+ its execution from the time at which it was checkpointed.
+
+ Turning this option on will enable checkpoint and restart
+ functionality in the kernel.
diff --git a/kernel/checkpoint/Makefile b/kernel/checkpoint/Makefile
new file mode 100644
index 0000000..8a32c6f
--- /dev/null
+++ b/kernel/checkpoint/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for linux checkpoint/restart.
+#
+
+obj-$(CONFIG_CHECKPOINT) += sys.o
diff --git a/kernel/checkpoint/sys.c b/kernel/checkpoint/sys.c
new file mode 100644
index 0000000..a81750a
--- /dev/null
+++ b/kernel/checkpoint/sys.c
@@ -0,0 +1,45 @@
+/*
+ * Generic container checkpoint-restart
+ *
+ * Copyright (C) 2008-2009 Oren Laadan
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of the Linux
+ * distribution for more details.
+ */
+
+#include <linux/sched.h>
+#include <linux/kernel.h>
+#include <linux/syscalls.h>
+
+/**
+ * sys_checkpoint - checkpoint a container
+ * @pid: pid of the container init(1) process
+ * @fd: file to which dump the checkpoint image
+ * @flags: checkpoint operation flags
+ * @logfd: fd to which to dump debug and error messages
+ *
+ * Returns positive identifier on success, 0 when returning from restart
+ * or negative value on error
+ */
+SYSCALL_DEFINE4(checkpoint, pid_t, pid, int, fd,
+ unsigned long, flags, int, logfd)
+{
+ return -ENOSYS;
+}
+
+/**
+ * sys_restart - restart a container
+ * @pid: pid of task root (in coordinator's namespace), or 0
+ * @fd: file from which read the checkpoint image
+ * @flags: restart operation flags
+ * @logfd: fd to which to dump debug and error messages
+ *
+ * Returns negative value on error, or otherwise returns in the realm
+ * of the original checkpoint
+ */
+SYSCALL_DEFINE4(restart, pid_t, pid, int, fd,
+ unsigned long, flags, int, logfd)
+{
+ return -ENOSYS;
+}
diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c
index c782fe9..b73a106 100644
--- a/kernel/sys_ni.c
+++ b/kernel/sys_ni.c
@@ -186,3 +186,7 @@ cond_syscall(sys_perf_event_open);
/* fanotify! */
cond_syscall(sys_fanotify_init);
cond_syscall(sys_fanotify_mark);
+
+/* checkpoint/restart */
+cond_syscall(sys_checkpoint);
+cond_syscall(sys_restart);
--
1.7.2.2
^ permalink raw reply related
* [PATCH 01/19] c/r: extend arch_setup_additional_pages()
From: Dan Smith @ 2010-12-14 16:14 UTC (permalink / raw)
To: danms; +Cc: linux-s390, x86, Oren Laadan, Alexey Dobriyan, linuxppc-dev
From: Alexey Dobriyan <adobriyan@gmail.com>
Add "start" argument, to request to map vDSO to a specific place,
and fail the operation if not.
This is useful for restart(2) to ensure that memory layout is restore
exactly as needed.
Changelog[v19]:
- [serge hallyn] Fix potential use-before-set ret
Changelog[v2]:
- [ntl] powerpc: vdso build fix (ckpt-v17)
Cc: x86@kernel.org
Cc: linux-s390@vger.kernel.org
Cc: linuxppc-dev@ozlabs.org
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Oren Laadan <orenl@cs.columbia.edu>
---
arch/powerpc/include/asm/elf.h | 1 +
arch/powerpc/kernel/vdso.c | 13 ++++++++++++-
arch/s390/include/asm/elf.h | 2 +-
arch/s390/kernel/vdso.c | 13 ++++++++++++-
arch/sh/include/asm/elf.h | 1 +
arch/sh/kernel/vsyscall/vsyscall.c | 2 +-
arch/x86/include/asm/elf.h | 3 ++-
arch/x86/vdso/vdso32-setup.c | 9 +++++++--
arch/x86/vdso/vma.c | 11 ++++++++---
fs/binfmt_elf.c | 2 +-
10 files changed, 46 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/include/asm/elf.h b/arch/powerpc/include/asm/elf.h
index 2b917c6..1c26833 100644
--- a/arch/powerpc/include/asm/elf.h
+++ b/arch/powerpc/include/asm/elf.h
@@ -266,6 +266,7 @@ extern int ucache_bsize;
#define ARCH_HAS_SETUP_ADDITIONAL_PAGES
struct linux_binprm;
extern int arch_setup_additional_pages(struct linux_binprm *bprm,
+ unsigned long start,
int uses_interp);
#define VDSO_AUX_ENT(a,b) NEW_AUX_ENT(a,b);
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index fd87287..c408960 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -188,7 +188,8 @@ static void dump_vdso_pages(struct vm_area_struct * vma)
* This is called from binfmt_elf, we create the special vma for the
* vDSO and insert it into the mm struct tree
*/
-int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
+int arch_setup_additional_pages(struct linux_binprm *bprm,
+ unsigned long start, int uses_interp)
{
struct mm_struct *mm = current->mm;
struct page **vdso_pagelist;
@@ -220,6 +221,10 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
vdso_base = VDSO32_MBASE;
#endif
+ /* in case restart(2) mandates a specific location */
+ if (start)
+ vdso_base = start;
+
current->mm->context.vdso_base = 0;
/* vDSO has a problem and was disabled, just don't "enable" it for the
@@ -249,6 +254,12 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
/* Add required alignment. */
vdso_base = ALIGN(vdso_base, VDSO_ALIGNMENT);
+ /* for restart(2), double check that we got we asked for */
+ if (start && vdso_base != start) {
+ rc = -EBUSY;
+ goto fail_mmapsem;
+ }
+
/*
* Put vDSO base into mm struct. We need to do this before calling
* install_special_mapping or the perf counter mmap tracking code
diff --git a/arch/s390/include/asm/elf.h b/arch/s390/include/asm/elf.h
index 354d426..5081938 100644
--- a/arch/s390/include/asm/elf.h
+++ b/arch/s390/include/asm/elf.h
@@ -216,6 +216,6 @@ do { \
struct linux_binprm;
#define ARCH_HAS_SETUP_ADDITIONAL_PAGES 1
-int arch_setup_additional_pages(struct linux_binprm *, int);
+int arch_setup_additional_pages(struct linux_binprm *, unsigned long, int);
#endif
diff --git a/arch/s390/kernel/vdso.c b/arch/s390/kernel/vdso.c
index e3150dd..199642b 100644
--- a/arch/s390/kernel/vdso.c
+++ b/arch/s390/kernel/vdso.c
@@ -187,7 +187,8 @@ static void vdso_init_cr5(void)
* This is called from binfmt_elf, we create the special vma for the
* vDSO and insert it into the mm struct tree
*/
-int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
+int arch_setup_additional_pages(struct linux_binprm *bprm,
+ unsigned long start, int uses_interp)
{
struct mm_struct *mm = current->mm;
struct page **vdso_pagelist;
@@ -218,6 +219,10 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
vdso_pages = vdso32_pages;
#endif
+ /* in case restart(2) mandates a specific location */
+ if (start)
+ vdso_base = start;
+
/*
* vDSO has a problem and was disabled, just don't "enable" it for
* the process
@@ -240,6 +245,12 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
goto out_up;
}
+ /* for restart(2), double check that we got we asked for */
+ if (start && vdso_base != start) {
+ rc = -EINVAL;
+ goto out_up;
+ }
+
/*
* Put vDSO base into mm struct. We need to do this before calling
* install_special_mapping or the perf counter mmap tracking code
diff --git a/arch/sh/include/asm/elf.h b/arch/sh/include/asm/elf.h
index f38112b..0f1dc2a 100644
--- a/arch/sh/include/asm/elf.h
+++ b/arch/sh/include/asm/elf.h
@@ -190,6 +190,7 @@ do { \
#define ARCH_HAS_SETUP_ADDITIONAL_PAGES
struct linux_binprm;
extern int arch_setup_additional_pages(struct linux_binprm *bprm,
+ unsigned long start,
int uses_interp);
extern unsigned int vdso_enabled;
diff --git a/arch/sh/kernel/vsyscall/vsyscall.c b/arch/sh/kernel/vsyscall/vsyscall.c
index 242117c..6dbdfe1 100644
--- a/arch/sh/kernel/vsyscall/vsyscall.c
+++ b/arch/sh/kernel/vsyscall/vsyscall.c
@@ -58,7 +58,7 @@ int __init vsyscall_init(void)
}
/* Setup a VMA at program startup for the vsyscall page */
-int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
+int arch_setup_additional_pages(struct linux_binprm *bprm, unsigned long start, int uses_interp)
{
struct mm_struct *mm = current->mm;
unsigned long addr;
diff --git a/arch/x86/include/asm/elf.h b/arch/x86/include/asm/elf.h
index f2ad216..3761be8 100644
--- a/arch/x86/include/asm/elf.h
+++ b/arch/x86/include/asm/elf.h
@@ -312,9 +312,10 @@ struct linux_binprm;
#define ARCH_HAS_SETUP_ADDITIONAL_PAGES 1
extern int arch_setup_additional_pages(struct linux_binprm *bprm,
+ unsigned long start,
int uses_interp);
-extern int syscall32_setup_pages(struct linux_binprm *, int exstack);
+extern int syscall32_setup_pages(struct linux_binprm *, unsigned long start, int exstack);
#define compat_arch_setup_additional_pages syscall32_setup_pages
extern unsigned long arch_randomize_brk(struct mm_struct *mm);
diff --git a/arch/x86/vdso/vdso32-setup.c b/arch/x86/vdso/vdso32-setup.c
index 36df991..8005f6f 100644
--- a/arch/x86/vdso/vdso32-setup.c
+++ b/arch/x86/vdso/vdso32-setup.c
@@ -310,7 +310,8 @@ int __init sysenter_setup(void)
}
/* Setup a VMA at program startup for the vsyscall page */
-int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
+int arch_setup_additional_pages(struct linux_binprm *bprm,
+ unsigned long start, int uses_interp)
{
struct mm_struct *mm = current->mm;
unsigned long addr;
@@ -331,13 +332,17 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
if (compat)
addr = VDSO_HIGH_BASE;
else {
- addr = get_unmapped_area(NULL, 0, PAGE_SIZE, 0, 0);
+ addr = get_unmapped_area(NULL, start, PAGE_SIZE, 0, 0);
if (IS_ERR_VALUE(addr)) {
ret = addr;
goto up_fail;
}
}
+ /* for restart(2), double check that we got we asked for */
+ if (start && addr != start)
+ goto up_fail;
+
current->mm->context.vdso = (void *)addr;
if (compat_uses_vma || !compat) {
diff --git a/arch/x86/vdso/vma.c b/arch/x86/vdso/vma.c
index 4b5d26f..5b32897 100644
--- a/arch/x86/vdso/vma.c
+++ b/arch/x86/vdso/vma.c
@@ -101,23 +101,28 @@ static unsigned long vdso_addr(unsigned long start, unsigned len)
/* Setup a VMA at program startup for the vsyscall page.
Not called for compat tasks */
-int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
+int arch_setup_additional_pages(struct linux_binprm *bprm,
+ unsigned long start, int uses_interp)
{
struct mm_struct *mm = current->mm;
unsigned long addr;
- int ret;
+ int ret = -EINVAL;
if (!vdso_enabled)
return 0;
down_write(&mm->mmap_sem);
- addr = vdso_addr(mm->start_stack, vdso_size);
+ addr = start ? : vdso_addr(mm->start_stack, vdso_size);
addr = get_unmapped_area(NULL, addr, vdso_size, 0, 0);
if (IS_ERR_VALUE(addr)) {
ret = addr;
goto up_fail;
}
+ /* for restart(2), double check that we got we asked for */
+ if (start && addr != start)
+ goto up_fail;
+
current->mm->context.vdso = (void *)addr;
ret = install_special_mapping(mm, addr, vdso_size,
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 6884e19..fc53346 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -923,7 +923,7 @@ static int load_elf_binary(struct linux_binprm *bprm, struct pt_regs *regs)
set_binfmt(&elf_format);
#ifdef ARCH_HAS_SETUP_ADDITIONAL_PAGES
- retval = arch_setup_additional_pages(bprm, !!elf_interpreter);
+ retval = arch_setup_additional_pages(bprm, 0, !!elf_interpreter);
if (retval < 0) {
send_sig(SIGKILL, current, 0);
goto out;
--
1.7.2.2
^ permalink raw reply related
* Re: ppc_set_hwdebug vs ptrace_set_debugreg
From: K.Prasad @ 2010-12-14 12:54 UTC (permalink / raw)
To: Andreas Schwab
Cc: linuxppc-dev, Dave Kleikamp, Srikar Dronamraju, Paul Mackerras
In-Reply-To: <m2vd2x1ojj.fsf@igel.home>
On Mon, Dec 13, 2010 at 08:05:36PM +0100, Andreas Schwab wrote:
> "K.Prasad" <prasad@linux.vnet.ibm.com> writes:
>
> > +#ifdef CONFIG_HAVE_HW_BREAKPOINT
> > + /* Create a new breakpoint request if one doesn't exist already */
> > + hw_breakpoint_init(&attr);
> > + attr.bp_addr = bp_info->addr & ~HW_BREAKPOINT_ALIGN;
> > + arch_bp_generic_fields(bp_info->addr &
> > + (DABR_DATA_WRITE | DABR_DATA_READ),
> > + &attr.bp_type);
> > +
> > + bp = register_user_hw_breakpoint(&attr, ptrace_triggered, task);
> > + if (IS_ERR(bp))
> > + return PTR_ERR(bp);
> > +
> > + child->thread.ptrace_bps[0] = bp;
> > +#endif /* CONFIG_HAVE_HW_BREAKPOINT */
> > +
> > child->thread.dabr = (unsigned long)bp_info->addr;
>
> That cannot work, see
> <http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/71418>.
>
Ok. The above patch makes it a bit easy.
How about the revised patch below? It is only compile-tested; have you
got a quick test case that I can run?
Enable PPC_PTRACE_SETHWDEBUG and PPC_PTRACE_DELHWDEBUG to use the generic
hardware breakpoint interfaces. This helps prevent conflict for the use of
DABR register in the absence of CONFIG_PPC_ADV_DEBUG_REGS and when
PTRACE_SET_DEBUGREG/PTRACE_GET_DEBUGREG flags are used by ptrace.
Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com>
---
arch/powerpc/kernel/ptrace.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
Index: linux-2.6.set_hwdebug/arch/powerpc/kernel/ptrace.c
===================================================================
--- linux-2.6.set_hwdebug.orig/arch/powerpc/kernel/ptrace.c
+++ linux-2.6.set_hwdebug/arch/powerpc/kernel/ptrace.c
@@ -1316,6 +1316,10 @@ static int set_dac_range(struct task_str
static long ppc_set_hwdebug(struct task_struct *child,
struct ppc_hw_breakpoint *bp_info)
{
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ struct perf_event *bp;
+ struct perf_event_attr attr;
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
#ifndef CONFIG_PPC_ADV_DEBUG_REGS
unsigned long dabr;
#endif
@@ -1365,6 +1369,10 @@ static long ppc_set_hwdebug(struct task_
if (child->thread.dabr)
return -ENOSPC;
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ if (child->thread.ptrace_bps[0])
+ return -ENOSPC;
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
if ((unsigned long)bp_info->addr >= TASK_SIZE)
return -EIO;
@@ -1376,6 +1384,20 @@ static long ppc_set_hwdebug(struct task_
if (bp_info->trigger_type & PPC_BREAKPOINT_TRIGGER_WRITE)
dabr |= DABR_DATA_WRITE;
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ /* Create a new breakpoint request if one doesn't exist already */
+ hw_breakpoint_init(&attr);
+ attr.bp_addr = dabr & ~HW_BREAKPOINT_ALIGN;
+ arch_bp_generic_fields(dabr & (DABR_DATA_WRITE | DABR_DATA_READ),
+ &attr.bp_type);
+
+ bp = register_user_hw_breakpoint(&attr, ptrace_triggered, child);
+ if (IS_ERR(bp))
+ return PTR_ERR(bp);
+
+ child->thread.ptrace_bps[0] = bp;
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
+
child->thread.dabr = dabr;
return 1;
@@ -1405,6 +1427,16 @@ static long ppc_del_hwdebug(struct task_
return -EINVAL;
if (child->thread.dabr == 0)
return -ENOENT;
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ /*
+ * There is no way by which address in ptrace_bps[0] and thread.dabr
+ * can be different. So we don't explicitly check if they're the same
+ */
+ if (child->thread.ptrace_bps[0]) {
+ unregister_hw_breakpoint(child->thread.ptrace_bps[0]);
+ child->thread.ptrace_bps[0] = NULL;
+ }
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
child->thread.dabr = 0;
^ permalink raw reply
* Re: [PATCH 7/7] P2020ds: add event button handler
From: Li Yang @ 2010-12-14 4:24 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <AANLkTikMSBwxeeA35RmGjE5qxG7Ymei3e3CmwT9M4mSB@mail.gmail.com>
On Tue, Dec 14, 2010 at 5:56 AM, Timur Tabi <timur.tabi@gmail.com> wrote:
> On Fri, Dec 3, 2010 at 6:34 AM, Li Yang <leoli@freescale.com> wrote:
>> This can be used as a wakeup source for power management.
>
> This patch doesn't actually add wake-up support.
Any enabled IRQ is a valid wake-up source for standby. The patch
enables a board specific interrupt for the purpose of wakeup.
>
> This patch should probably be split up, since you're adding generic
> functionality for the IRQ that applies to all 85xx boards, but you
> only update the device tree for one board.
The IRQ is a board specific one from GPIO which not applicable on all
85xx boards.
>
>> +static irqreturn_t event_isr(int irq, void *dev_id)
>> +{
>> +
>> + =C2=A0 =C2=A0 =C2=A0 printk(KERN_INFO "MPC85xxDS: Event button been pu=
shed.\n");
>> + =C2=A0 =C2=A0 =C2=A0 return IRQ_HANDLED;
>> +}
>
> Would it make sense to have this be a weak function, so that it would
> be easier to implement board-specific support?
It's already a board-specific one.
>
>> +
>> +static int __init p2020ds_ngpixis_init(void)
>
> You're adding a function called "p2020ds_ngpixis_init" to the file
> "mpc85xx_ds.c". =C2=A0mpc85xx_ds.c supports more than just the P2020DS.
I'm not sure if other DS boards covered by this file has the same functiona=
lity.
>
>> +{
>> + =C2=A0 =C2=A0 =C2=A0 int event_irq, ret;
>> + =C2=A0 =C2=A0 =C2=A0 struct device_node *np;
>> +
>> + =C2=A0 =C2=A0 =C2=A0 np =3D of_find_compatible_node(NULL, NULL, "fsl,p=
2020ds-fpga");
>> + =C2=A0 =C2=A0 =C2=A0 if (np) {
>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 event_irq =3D irq_of_=
parse_and_map(np, 0);
>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ret =3D request_irq(e=
vent_irq, event_isr, 0, "event", NULL);
>
> You should probably choose a less generic name than "event".
Well, it's the name suggested by the board manual. We may change it
to "event_button" if not too long.
- Leo
^ permalink raw reply
* Re: MPC831x (and others?) NAND erase performance improvements
From: Joakim Tjernlund @ 2010-12-13 22:28 UTC (permalink / raw)
To: Scott Wood; +Cc: Mark Mason, David Laight, linuxppc-dev
In-Reply-To: <20101213134950.258609b4@udp111988uds.am.freescale.net>
Scott Wood <scottwood@freescale.com> wrote on 2010/12/13 20:49:50:
>
> On Mon, 13 Dec 2010 20:30:27 +0100
> Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
>
> > Scott Wood <scottwood@freescale.com> wrote on 2010/12/13 18:51:31:
> > >
> > > On Mon, 13 Dec 2010 18:41:32 +0100
> > > Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> > >
> > > > Scott Wood <scottwood@freescale.com> wrote on 2010/12/13 18:33:56:
> > > > >
> > > > > On Mon, 13 Dec 2010 11:32:00 +0100
> > > > > Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> > > > >
> > > > > > What if one has several NAND chips to build a big FS? Is the NAND
> > > > > > controller equipped to handle that?
> > > > >
> > > > > FCM can drive one NAND chip per eLBC chipselect, though possibly you
> > > > > could go beyond that with a board-logic chipselect mechanism.
> > > >
> > > > hmm, then I guess one would have to use one GPIO/IRQ per NAND chip?
> > >
> > > Couldn't you just tie together all the open-drain busy lines before you
> > > invert it? You'll only be driving one NAND chip at a time anyway; the
> > > others should not be asserting busy.
> >
> > hmm, I guess that would work(didn't know they were open-drain), thanks.
> > Is that how the FCM do it?
>
> Yes, that's what started this discussion. :-)
True, I must be getting old :)
>
> The problem there is that they share the line with all chipselects,
> NAND or otherwise.
Right, thanks for reminding me.
^ permalink raw reply
* Re: [PATCH] fsldma: fix issue of slow dma
From: Dan Williams @ 2010-12-13 22:02 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1291882444-1523-1-git-send-email-leoli@freescale.com>
On Thu, Dec 9, 2010 at 12:14 AM, Li Yang <leoli@freescale.com> wrote:
> From: Forrest Shi <b29237@freescale.com>
>
> Fixed fsl dma slow issue by initializing dma mode register with
> bandwidth control. It boosts dma performance and should works
> with 85xx board.
>
> Signed-off-by: Forrest Shi <b29237@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
Applied.
^ permalink raw reply
* Re: [PATCH 7/7] P2020ds: add event button handler
From: Timur Tabi @ 2010-12-13 21:56 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev
In-Reply-To: <1291379651-8822-7-git-send-email-leoli@freescale.com>
On Fri, Dec 3, 2010 at 6:34 AM, Li Yang <leoli@freescale.com> wrote:
> This can be used as a wakeup source for power management.
This patch doesn't actually add wake-up support.
This patch should probably be split up, since you're adding generic
functionality for the IRQ that applies to all 85xx boards, but you
only update the device tree for one board.
> +static irqreturn_t event_isr(int irq, void *dev_id)
> +{
> +
> + =A0 =A0 =A0 printk(KERN_INFO "MPC85xxDS: Event button been pushed.\n");
> + =A0 =A0 =A0 return IRQ_HANDLED;
> +}
Would it make sense to have this be a weak function, so that it would
be easier to implement board-specific support?
> +
> +static int __init p2020ds_ngpixis_init(void)
You're adding a function called "p2020ds_ngpixis_init" to the file
"mpc85xx_ds.c". mpc85xx_ds.c supports more than just the P2020DS.
> +{
> + =A0 =A0 =A0 int event_irq, ret;
> + =A0 =A0 =A0 struct device_node *np;
> +
> + =A0 =A0 =A0 np =3D of_find_compatible_node(NULL, NULL, "fsl,p2020ds-fpg=
a");
> + =A0 =A0 =A0 if (np) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 event_irq =3D irq_of_parse_and_map(np, 0);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 ret =3D request_irq(event_irq, event_isr, 0=
, "event", NULL);
You should probably choose a less generic name than "event".
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ret)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 printk(KERN_ERR "Can't requ=
est board event int\n");
Use pr_err()
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: MPC831x (and others?) NAND erase performance improvements
From: Scott Wood @ 2010-12-13 19:49 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Mark Mason, David Laight, linuxppc-dev
In-Reply-To: <OFB1D66F80.0CE3DBB3-ONC12577F8.006ADF11-C12577F8.006B2893@transmode.se>
On Mon, 13 Dec 2010 20:30:27 +0100
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> Scott Wood <scottwood@freescale.com> wrote on 2010/12/13 18:51:31:
> >
> > On Mon, 13 Dec 2010 18:41:32 +0100
> > Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> >
> > > Scott Wood <scottwood@freescale.com> wrote on 2010/12/13 18:33:56:
> > > >
> > > > On Mon, 13 Dec 2010 11:32:00 +0100
> > > > Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> > > >
> > > > > What if one has several NAND chips to build a big FS? Is the NAND
> > > > > controller equipped to handle that?
> > > >
> > > > FCM can drive one NAND chip per eLBC chipselect, though possibly you
> > > > could go beyond that with a board-logic chipselect mechanism.
> > >
> > > hmm, then I guess one would have to use one GPIO/IRQ per NAND chip?
> >
> > Couldn't you just tie together all the open-drain busy lines before you
> > invert it? You'll only be driving one NAND chip at a time anyway; the
> > others should not be asserting busy.
>
> hmm, I guess that would work(didn't know they were open-drain), thanks.
> Is that how the FCM do it?
Yes, that's what started this discussion. :-)
The problem there is that they share the line with all chipselects,
NAND or otherwise.
-Scott
^ permalink raw reply
* [PATCH RESEND] mpc52xx: gpt: include fs.h
From: Wolfram Sang @ 2010-12-13 19:47 UTC (permalink / raw)
To: linuxppc-dev
Fix build errors like these from a randconfig:
src/arch/powerpc/platforms/52xx/mpc52xx_gpt.c:549: error: dereferencing pointer to incomplete type: 1 errors in 1 logs
src/arch/powerpc/platforms/52xx/mpc52xx_gpt.c:636: error: implicit declaration of function 'nonseekable_open': 1 errors in 1 logs
src/arch/powerpc/platforms/52xx/mpc52xx_gpt.c:657: error: variable 'mpc52xx_wdt_fops' has initializer but incomplete type: 1 errors in 1 logs
src/arch/powerpc/platforms/52xx/mpc52xx_gpt.c:658: error: excess elements in struct initializer: 1 errors in 1 logs
src/arch/powerpc/platforms/52xx/mpc52xx_gpt.c:658: error: unknown field 'owner' specified in initializer: 1 errors in 1 logs
...
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
As this is a build-fix, would be nice to have for 2.6.37.
A similar one was already comitted: f6e0722fc3a35ff818c86ffbc414f7592a8119cf
arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
index fea833e..e0d703c 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
@@ -63,6 +63,7 @@
#include <linux/of_gpio.h>
#include <linux/kernel.h>
#include <linux/slab.h>
+#include <linux/fs.h>
#include <linux/watchdog.h>
#include <linux/miscdevice.h>
#include <linux/uaccess.h>
--
1.7.2.3
^ permalink raw reply related
* Re: MPC831x (and others?) NAND erase performance improvements
From: Joakim Tjernlund @ 2010-12-13 19:30 UTC (permalink / raw)
To: Scott Wood; +Cc: Mark Mason, David Laight, linuxppc-dev
In-Reply-To: <20101213115131.57050e1d@udp111988uds.am.freescale.net>
Scott Wood <scottwood@freescale.com> wrote on 2010/12/13 18:51:31:
>
> On Mon, 13 Dec 2010 18:41:32 +0100
> Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
>
> > Scott Wood <scottwood@freescale.com> wrote on 2010/12/13 18:33:56:
> > >
> > > On Mon, 13 Dec 2010 11:32:00 +0100
> > > Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> > >
> > > > What if one has several NAND chips to build a big FS? Is the NAND
> > > > controller equipped to handle that?
> > >
> > > FCM can drive one NAND chip per eLBC chipselect, though possibly you
> > > could go beyond that with a board-logic chipselect mechanism.
> >
> > hmm, then I guess one would have to use one GPIO/IRQ per NAND chip?
>
> Couldn't you just tie together all the open-drain busy lines before you
> invert it? You'll only be driving one NAND chip at a time anyway; the
> others should not be asserting busy.
hmm, I guess that would work(didn't know they were open-drain), thanks.
Is that how the FCM do it?
Jocke
^ permalink raw reply
* Re: ppc_set_hwdebug vs ptrace_set_debugreg
From: Andreas Schwab @ 2010-12-13 19:05 UTC (permalink / raw)
To: prasad; +Cc: linuxppc-dev, Dave Kleikamp, Srikar Dronamraju, Paul Mackerras
In-Reply-To: <20101213082619.GA6582@in.ibm.com>
"K.Prasad" <prasad@linux.vnet.ibm.com> writes:
> +#ifdef CONFIG_HAVE_HW_BREAKPOINT
> + /* Create a new breakpoint request if one doesn't exist already */
> + hw_breakpoint_init(&attr);
> + attr.bp_addr = bp_info->addr & ~HW_BREAKPOINT_ALIGN;
> + arch_bp_generic_fields(bp_info->addr &
> + (DABR_DATA_WRITE | DABR_DATA_READ),
> + &attr.bp_type);
> +
> + bp = register_user_hw_breakpoint(&attr, ptrace_triggered, task);
> + if (IS_ERR(bp))
> + return PTR_ERR(bp);
> +
> + child->thread.ptrace_bps[0] = bp;
> +#endif /* CONFIG_HAVE_HW_BREAKPOINT */
> +
> child->thread.dabr = (unsigned long)bp_info->addr;
That cannot work, see
<http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/71418>.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ 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