* Re: [PATCH] powerpc, hw_breakpoints: Fix CONFIG_HAVE_HW_BREAKPOINT off-case in ptrace_set_debugreg
From: Ingo Molnar @ 2011-05-06 6:13 UTC (permalink / raw)
To: Frederic Weisbecker, Benjamin Herrenschmidt, Paul Mackerras
Cc: Prasad, LPPC, LKML, v2.6.33..
In-Reply-To: <1304639598-4707-1-git-send-email-fweisbec@gmail.com>
* Frederic Weisbecker <fweisbec@gmail.com> wrote:
> We make use of ptrace_get_breakpoints() / ptrace_put_breakpoints()
> to protect ptrace_set_debugreg() even if CONFIG_HAVE_HW_BREAKPOINT
> if off. However in this case, these APIs are not implemented.
>
> To fix this, push the protection down inside the relevant ifdef.
> Best would be to export the code inside CONFIG_HAVE_HW_BREAKPOINT
> into a standalone function to cleanup the ifdefury there and call
> the breakpoint ref API inside. But as it is more invasive, this
> should be rather made in an -rc1.
>
> Fixes:
>
> arch/powerpc/kernel/ptrace.c:1594: error: implicit declaration of function 'ptrace_get_breakpoints'
> make[2]: *** [arch/powerpc/kernel/ptrace.o] Error 1
> make[1]: *** [arch/powerpc/kernel] Error 2
> make: *** [sub-make] Error 2
Thanks.
I'll need a PowerPC ack for this. Note: it's dependent on hw-breakpoint fixes
in tip:perf/urgent so the commit will want to go there too.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH v2 7/7] ARM: mxc: remove esdhc.h and use the public one
From: Uwe Kleine-König @ 2011-05-06 8:39 UTC (permalink / raw)
To: Shawn Guo
Cc: Anton Vorontsov, sameo, Arnd Bergmann, patches,
devicetree-discuss, linux-mmc, Saeed Bishara, linux-arm-kernel,
kernel, Mike Rapoport, Olof Johansson, Chris Ball, linuxppc-dev,
Albert Herranz, Xiaobo Xie
In-Reply-To: <1304601778-13837-8-git-send-email-shawn.guo@linaro.org>
Hello Shawn,
On Thu, May 05, 2011 at 09:22:58PM +0800, Shawn Guo wrote:
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
> .../plat-mxc/devices/platform-sdhci-esdhc-imx.c | 1 -
> arch/arm/plat-mxc/include/mach/devices-common.h | 2 +-
what about removing arch/arm/plat-mxc/include/mach/esdhc.h in this
patch as advertised in the subject?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [tip:perf/urgent] hw_breakpoints, powerpc: Fix CONFIG_HAVE_HW_BREAKPOINT off-case in ptrace_set_debugreg()
From: tip-bot for Frederic Weisbecker @ 2011-05-06 9:43 UTC (permalink / raw)
To: linux-tip-commits
Cc: fweisbec, mingo, linux-kernel, mingo, prasad, hpa, tglx,
linuxppc-dev, stable
In-Reply-To: <1304639598-4707-1-git-send-email-fweisbec@gmail.com>
Commit-ID: 925f83c085e1bb08435556c5b4844a60de002e31
Gitweb: http://git.kernel.org/tip/925f83c085e1bb08435556c5b4844a60de002e31
Author: Frederic Weisbecker <fweisbec@gmail.com>
AuthorDate: Fri, 6 May 2011 01:53:18 +0200
Committer: Ingo Molnar <mingo@elte.hu>
CommitDate: Fri, 6 May 2011 11:24:46 +0200
hw_breakpoints, powerpc: Fix CONFIG_HAVE_HW_BREAKPOINT off-case in ptrace_set_debugreg()
We make use of ptrace_get_breakpoints() / ptrace_put_breakpoints() to
protect ptrace_set_debugreg() even if CONFIG_HAVE_HW_BREAKPOINT if off.
However in this case, these APIs are not implemented.
To fix this, push the protection down inside the relevant ifdef.
Best would be to export the code inside
CONFIG_HAVE_HW_BREAKPOINT into a standalone function to cleanup
the ifdefury there and call the breakpoint ref API inside. But
as it is more invasive, this should be rather made in an -rc1.
Fixes this build error:
arch/powerpc/kernel/ptrace.c:1594: error: implicit declaration of function 'ptrace_get_breakpoints' make[2]: ***
Reported-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Cc: LPPC <linuxppc-dev@lists.ozlabs.org>
Cc: Prasad <prasad@linux.vnet.ibm.com>
Cc: v2.6.33.. <stable@kernel.org>
Link: http://lkml.kernel.org/r/1304639598-4707-1-git-send-email-fweisbec@gmail.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/powerpc/kernel/ptrace.c | 15 +++++++++++----
1 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 4edeeb3..a6ae1cf 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -933,12 +933,16 @@ int ptrace_set_debugreg(struct task_struct *task, unsigned long addr,
if (data && !(data & DABR_TRANSLATION))
return -EIO;
#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ if (ptrace_get_breakpoints(task) < 0)
+ return -ESRCH;
+
bp = thread->ptrace_bps[0];
if ((!data) || !(data & (DABR_DATA_WRITE | DABR_DATA_READ))) {
if (bp) {
unregister_hw_breakpoint(bp);
thread->ptrace_bps[0] = NULL;
}
+ ptrace_put_breakpoints(task);
return 0;
}
if (bp) {
@@ -948,9 +952,12 @@ int ptrace_set_debugreg(struct task_struct *task, unsigned long addr,
(DABR_DATA_WRITE | DABR_DATA_READ),
&attr.bp_type);
ret = modify_user_hw_breakpoint(bp, &attr);
- if (ret)
+ if (ret) {
+ ptrace_put_breakpoints(task);
return ret;
+ }
thread->ptrace_bps[0] = bp;
+ ptrace_put_breakpoints(task);
thread->dabr = data;
return 0;
}
@@ -965,9 +972,12 @@ int ptrace_set_debugreg(struct task_struct *task, unsigned long addr,
ptrace_triggered, task);
if (IS_ERR(bp)) {
thread->ptrace_bps[0] = NULL;
+ ptrace_put_breakpoints(task);
return PTR_ERR(bp);
}
+ ptrace_put_breakpoints(task);
+
#endif /* CONFIG_HAVE_HW_BREAKPOINT */
/* Move contents to the DABR register */
@@ -1591,10 +1601,7 @@ long arch_ptrace(struct task_struct *child, long request,
}
case PTRACE_SET_DEBUGREG:
- if (ptrace_get_breakpoints(child) < 0)
- return -ESRCH;
ret = ptrace_set_debugreg(child, addr, data);
- ptrace_put_breakpoints(child);
break;
#ifdef CONFIG_PPC64
^ permalink raw reply related
* [RFC v2] virtio: add virtio-over-PCI driver
From: Kushwaha Prabhakar-B32579 @ 2011-05-06 12:00 UTC (permalink / raw)
To: iws@ovro.caltech.edu
Cc: Aggrwal Poonam-B10812, netdev@vger.kernel.org, Zang Roy-R61911,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
Kalra Ashish-B00888, Gala Kumar-B11780, Gupta Maneesh-B18878
Hi,
I want to use this patch as base patch for "FSL 85xx platform" to support P=
CIe Agent.
The work looks to be little old now. So wanted to understand if any develop=
ment has happened further on it.
In case no, I would take this work forward for PCIe Agent.=20
Any help/suggestions are most appreciated in this regard.
Thanks,
Prabhakar
-----Original Message-----
From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.ke=
rnel.org] On Behalf Of Ira Snyder
Sent: Friday, 27 February, 2009 3:19 AM
To: Arnd Bergmann
Cc: linux-kernel@vger.kernel.org; Rusty Russell; Jan-Bernd Themann; linuxpp=
c-dev@ozlabs.org; netdev@vger.kernel.org
Subject: Re: [RFC v2] virtio: add virtio-over-PCI driver
On Thu, Feb 26, 2009 at 09:37:14PM +0100, Arnd Bergmann wrote:
> On Thursday 26 February 2009, Ira Snyder wrote:
> > On Thu, Feb 26, 2009 at 05:15:27PM +0100, Arnd Bergmann wrote:
> >
> > I think so too. I was just getting something working, and thought it=20
> > would be better to have it "out there" rather than be working on it=20
> > forever. I'll try to break things up as I have time.
>=20
> Ok, perfect!
> =20
> > For the "libraries", would you suggest breaking things into seperate=20
> > code files, and using EXPORT_SYMBOL_GPL()? I'm not very familiar=20
> > with doing that, I've mostly been writing code within the existing=20
> > device driver frameworks. Or do I need export symbol at all? I'm not su=
re...
>=20
> You have both options. When you list each file as a separate module in=20
> the Makefile, you use EXPORT_SYMBOL_GPL to mark functions that get=20
> called by dependent modules, but this will work only in one way.
>=20
> You can also link multiple files together into one module, although it=20
> is less common to link a single source file into multiple modules.
>=20
Ok. I'm more familiar with the EXPORT_SYMBOL_GPL interface, so I'll do that=
. If we decide it sucks later, we'll change it.
> > I always thought you were supposed to use packed for data structures=20
> > that are external to the system. I purposely designed the structures=20
> > so they wouldn't need padding.
>=20
> That would only make sense for structures that are explicitly=20
> unaligned, like a register layout using
>=20
> struct my_registers {
> __le16 first;
> __le32 second __attribute__((packed));
> __le16 third;
> };
>=20
> Even here, I'd recommend listing the individual members as packed=20
> rather than the entire struct. Obviously if you layout the members in=20
> a sane way, you don't need either.
>=20
Ok. I'll drop the __attribute__((packed)) and make sure there aren't proble=
ms. I don't suspect any, though.
> > I mostly don't need it. In fact, the only place I'm using registers=20
> > not specific to the messaging unit is in the probe routine, where I=20
> > setup the 1GB window into host memory and setting up access to the=20
> > guest memory on the PCI bus.
>=20
> You could add the registers you need for this to the "reg" property of=20
> your device, to be mapped with of_iomap.
>=20
> If the registers for setting up this window don't logically fit into=20
> the same device as the one you already use, the cleanest solution=20
> would be to have another device just for this and then make a function=20
> call into that driver to set up the window.
>=20
The registers are part of the board control registers. They don't fit at al=
l in the message unit. Doing this in the bootloader seems like a logical pl=
ace, but that would require any testers to flash a new U-Boot image into th=
eir mpc8349emds boards.
The first set of access is used to set up a 1GB region in the memory map th=
at accesses the host's memory. Any reads/writes to addresses 0x80000000-0xc=
0000000 actually hit the host's memory.
The last access sets up PCI BAR1 to hit the memory from dma_alloc_coherent(=
). The bootloader already sets up the window as 16K, it just doesn't point =
it anywhere. Maybe this /should/ go into the bootloader. Like above, it wou=
ld require testers to flash a new U-Boot image into their mpc8349emds board=
s.
> > Now, I wouldn't need to access these registers at all if the=20
> > bootloader could handle it. I just don't know if it is possible to=20
> > have Linux not use some memory that the bootloader allocated, other=20
> > than with the mem=3DXXX trick, which I'm sure wouldn't be acceptable.
> > I've just used regular RAM so this is portable to my custom board=20
> > (mpc8349emds based) and a regular mpc8349emds. I didn't want to=20
> > change anything board specific.
> >=20
> > I would love to have the bootloader allocate (or reserve somewhere=20
> > in the memory map) 16K of RAM, and not be required to allocate it=20
> > with dma_alloc_coherent(). It would save me plenty of headaches.
>=20
> I believe you can do that through the "memory" devices in the device=20
> tree, by leaving out a small part of the description of main memory,=20
> at putting it into the "reg" property of your own device.
>=20
I'll explore this option. I didn't even know you could do this. Is a drive=
r that requires the trick acceptable for mainline inclusion? Just like sett=
ing up the 16K PCI window, this is very platform specific.
This limits the guest driver to systems which are able to change Linux's vi=
ew of their memory somehow. Maybe this isn't a problem.
> > Code complexity only. Also, it was easier to write 80-char lines=20
> > with something like:
> >=20
> > vop_get_desc(vq, idx, &desc);
> > if (desc.flags & VOP_DESC_F_NEXT) {
> > /* do something */
> > }
> >=20
> > Instead of:
> > if (le16_to_cpu(vq->desc[idx].flags) & VOP_DESC_F_NEXT) {
> > /* do something */
> > }
> >=20
> > Plus, I didn't have to remember how many bits were in each field. I=20
> > just thought it made everything simpler to understand. Suggestions?
>=20
> hmm, in this particular case, you could change the definition of=20
> VOP_DESC_F_NEXT to
>=20
> #define VOP_DESC_F_NEXT cpu_to_le16(1)
>=20
> and then do the code as the even simpler (source and object code wise)
>=20
> if (vq->desc[idx].flags) & VOP_DESC_F_NEXT)
>=20
> I'm not sure if you can do something along these lines for the other=20
> cases as well though.
>=20
That's a good idea. It wouldn't fix the addresses, lengths, and next fields=
, though. I'll make the change and see how bad it is, then report back. It =
may not be so bad after all.
> > I used 3 so they would would align to 1024 byte boundaries within a=20
> > 4K page. Then the layout was 16K on the bus, each 4K page is a=20
> > single virtio-device, and each 1K block is a single virtqueue. The=20
> > first 1K is for virtio-device status and feature bits, etc.
> >=20
> > Packing them differently isn't a problem. It was just easier to code=20
> > because setting up a window with the correct size is so platform=20
> > specific.
>=20
> Ok. I guess the important question is what part of the code makes this=20
> decision. Ideally, the virtio-net glue would instantiate the device=20
> with the right number of queues.
>=20
Yeah, virtio doesn't work that way.
The virtio drivers just call find_vq() with a different index for each queu=
e they want to use. You have no way of knowing how many queues each virtio =
driver will want, unless you go read their source code.
virtio-net currently uses 3 queues, but we only support the first two.
The third is optional (for now...), and non-symmetric.
Thanks again,
Ira
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in =
the body of a message to majordomo@vger.kernel.org More majordomo info at =
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [RFC v2] virtio: add virtio-over-PCI driver
From: Ira W. Snyder @ 2011-05-06 16:06 UTC (permalink / raw)
To: Kushwaha Prabhakar-B32579
Cc: Aggrwal Poonam-B10812, netdev@vger.kernel.org, Zang Roy-R61911,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
Kalra Ashish-B00888, Gala Kumar-B11780, Gupta Maneesh-B18878
In-Reply-To: <071A08F2C6A57E4E94D980ECA553F8741A54D4@039-SN1MPN1-004.039d.mgd.msft.net>
On Fri, May 06, 2011 at 12:00:34PM +0000, Kushwaha Prabhakar-B32579 wrote:
> Hi,
>
> I want to use this patch as base patch for "FSL 85xx platform" to support PCIe Agent.
> The work looks to be little old now. So wanted to understand if any development has happened further on it.
>
> In case no, I would take this work forward for PCIe Agent.
>
> Any help/suggestions are most appreciated in this regard.
>
Hi Prabhakar,
I use PCI agent mode on an mpc8349emds board. All of the important setup is
done very early in the boot process, by U-Boot. Search the U-Boot source
for CONFIG_PCISLAVE. I hunch that the setup needed for 85xx boards are
similar.
This virtio-over-PCI work is now very old. It was intended to provide a
communication mechanism between a PCI Master and many PCI Agents (slaves).
Dave Miller (networking maintainer) suggested to use virtio for this so
that many different devices could be used. Such as:
- network interface
- serial port (for serial console)
I am aware of other ongoing work in this area. Specifically, some ARM
developers are working on a virtio API using their message registers. This
work is much newer, and will be a much better starting place for you.
Search the virtualization mailing list for:
"[PATCH 00/02] virtio: Virtio platform driver"
Here is a link to some of their code:
http://www.spinics.net/lists/linux-sh/msg07188.html
I am currently using a custom driver to provide a network device on my PCI
agents. Searching the mailing list archives for "PCINet", you will find
early versions of the driver. I am happy to provide you a current copy. It
does not use virtio at all, and is unlikely to be accepted into mainline
Linux.
I am happy to provide any of my code if you think it would help you get
started. Specifically, the current version of "PCINet" show how to use the
DMA controller in order to get good network performance. I am also happy to
help port code to 83xx, as well as test on 83xx. Please ask any questions
you may have.
I have people ask about this code about once every two months. There is
plenty of interest in a mainline Linux solution to this problem. :) I
will be moving to 85xx someday, and I hope there is an accepted mainline
solution by then.
I hope it helps,
Ira
> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Ira Snyder
> Sent: Friday, 27 February, 2009 3:19 AM
> To: Arnd Bergmann
> Cc: linux-kernel@vger.kernel.org; Rusty Russell; Jan-Bernd Themann; linuxppc-dev@ozlabs.org; netdev@vger.kernel.org
> Subject: Re: [RFC v2] virtio: add virtio-over-PCI driver
>
> On Thu, Feb 26, 2009 at 09:37:14PM +0100, Arnd Bergmann wrote:
> > On Thursday 26 February 2009, Ira Snyder wrote:
> > > On Thu, Feb 26, 2009 at 05:15:27PM +0100, Arnd Bergmann wrote:
> > >
> > > I think so too. I was just getting something working, and thought it
> > > would be better to have it "out there" rather than be working on it
> > > forever. I'll try to break things up as I have time.
> >
> > Ok, perfect!
> >
> > > For the "libraries", would you suggest breaking things into seperate
> > > code files, and using EXPORT_SYMBOL_GPL()? I'm not very familiar
> > > with doing that, I've mostly been writing code within the existing
> > > device driver frameworks. Or do I need export symbol at all? I'm not sure...
> >
> > You have both options. When you list each file as a separate module in
> > the Makefile, you use EXPORT_SYMBOL_GPL to mark functions that get
> > called by dependent modules, but this will work only in one way.
> >
> > You can also link multiple files together into one module, although it
> > is less common to link a single source file into multiple modules.
> >
>
> Ok. I'm more familiar with the EXPORT_SYMBOL_GPL interface, so I'll do that. If we decide it sucks later, we'll change it.
>
> > > I always thought you were supposed to use packed for data structures
> > > that are external to the system. I purposely designed the structures
> > > so they wouldn't need padding.
> >
> > That would only make sense for structures that are explicitly
> > unaligned, like a register layout using
> >
> > struct my_registers {
> > __le16 first;
> > __le32 second __attribute__((packed));
> > __le16 third;
> > };
> >
> > Even here, I'd recommend listing the individual members as packed
> > rather than the entire struct. Obviously if you layout the members in
> > a sane way, you don't need either.
> >
>
> Ok. I'll drop the __attribute__((packed)) and make sure there aren't problems. I don't suspect any, though.
>
> > > I mostly don't need it. In fact, the only place I'm using registers
> > > not specific to the messaging unit is in the probe routine, where I
> > > setup the 1GB window into host memory and setting up access to the
> > > guest memory on the PCI bus.
> >
> > You could add the registers you need for this to the "reg" property of
> > your device, to be mapped with of_iomap.
> >
> > If the registers for setting up this window don't logically fit into
> > the same device as the one you already use, the cleanest solution
> > would be to have another device just for this and then make a function
> > call into that driver to set up the window.
> >
>
> The registers are part of the board control registers. They don't fit at all in the message unit. Doing this in the bootloader seems like a logical place, but that would require any testers to flash a new U-Boot image into their mpc8349emds boards.
>
> The first set of access is used to set up a 1GB region in the memory map that accesses the host's memory. Any reads/writes to addresses 0x80000000-0xc0000000 actually hit the host's memory.
>
> The last access sets up PCI BAR1 to hit the memory from dma_alloc_coherent(). The bootloader already sets up the window as 16K, it just doesn't point it anywhere. Maybe this /should/ go into the bootloader. Like above, it would require testers to flash a new U-Boot image into their mpc8349emds boards.
>
> > > Now, I wouldn't need to access these registers at all if the
> > > bootloader could handle it. I just don't know if it is possible to
> > > have Linux not use some memory that the bootloader allocated, other
> > > than with the mem=XXX trick, which I'm sure wouldn't be acceptable.
> > > I've just used regular RAM so this is portable to my custom board
> > > (mpc8349emds based) and a regular mpc8349emds. I didn't want to
> > > change anything board specific.
> > >
> > > I would love to have the bootloader allocate (or reserve somewhere
> > > in the memory map) 16K of RAM, and not be required to allocate it
> > > with dma_alloc_coherent(). It would save me plenty of headaches.
> >
> > I believe you can do that through the "memory" devices in the device
> > tree, by leaving out a small part of the description of main memory,
> > at putting it into the "reg" property of your own device.
> >
>
> I'll explore this option. I didn't even know you could do this. Is a driver that requires the trick acceptable for mainline inclusion? Just like setting up the 16K PCI window, this is very platform specific.
>
> This limits the guest driver to systems which are able to change Linux's view of their memory somehow. Maybe this isn't a problem.
>
> > > Code complexity only. Also, it was easier to write 80-char lines
> > > with something like:
> > >
> > > vop_get_desc(vq, idx, &desc);
> > > if (desc.flags & VOP_DESC_F_NEXT) {
> > > /* do something */
> > > }
> > >
> > > Instead of:
> > > if (le16_to_cpu(vq->desc[idx].flags) & VOP_DESC_F_NEXT) {
> > > /* do something */
> > > }
> > >
> > > Plus, I didn't have to remember how many bits were in each field. I
> > > just thought it made everything simpler to understand. Suggestions?
> >
> > hmm, in this particular case, you could change the definition of
> > VOP_DESC_F_NEXT to
> >
> > #define VOP_DESC_F_NEXT cpu_to_le16(1)
> >
> > and then do the code as the even simpler (source and object code wise)
> >
> > if (vq->desc[idx].flags) & VOP_DESC_F_NEXT)
> >
> > I'm not sure if you can do something along these lines for the other
> > cases as well though.
> >
>
> That's a good idea. It wouldn't fix the addresses, lengths, and next fields, though. I'll make the change and see how bad it is, then report back. It may not be so bad after all.
>
> > > I used 3 so they would would align to 1024 byte boundaries within a
> > > 4K page. Then the layout was 16K on the bus, each 4K page is a
> > > single virtio-device, and each 1K block is a single virtqueue. The
> > > first 1K is for virtio-device status and feature bits, etc.
> > >
> > > Packing them differently isn't a problem. It was just easier to code
> > > because setting up a window with the correct size is so platform
> > > specific.
> >
> > Ok. I guess the important question is what part of the code makes this
> > decision. Ideally, the virtio-net glue would instantiate the device
> > with the right number of queues.
> >
>
> Yeah, virtio doesn't work that way.
>
> The virtio drivers just call find_vq() with a different index for each queue they want to use. You have no way of knowing how many queues each virtio driver will want, unless you go read their source code.
>
> virtio-net currently uses 3 queues, but we only support the first two.
> The third is optional (for now...), and non-symmetric.
>
> Thanks again,
> Ira
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
>
>
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: add support for MPIC message register API
From: Scott Wood @ 2011-05-06 19:29 UTC (permalink / raw)
To: Meador Inge
Cc: Wood Scott-B07421, devicetree-discuss@lists.ozlabs.org,
Hollis Blanchard, Kushwaha Prabhakar-B32579,
openmcapi-dev@googlegroups.com, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4DC31989.8080703@mentor.com>
On Thu, 5 May 2011 16:41:29 -0500
Meador Inge <meador_inge@mentor.com> wrote:
> /* OS 1 */
> mpic_msgr_block0: mpic-msgr-block@41400 {
> compatible = "fsl,mpic-v3.1-msgr";
> reg = <0x41400 0x200>;
> interrupts = <0xb0 2 0xb2 2>;
> mpic-msgr-receive-mask = <0x5>;
> mpic-msgr-send-mask = <0xa>;
> };
>
> mpic_msgr_block1: mpic-msgr-block@42400 {
> compatible = "fsl,mpic-v3.1-msgr";
> reg = <0x42400 0x200>;
> interrupts = <0xb4 2 0xb6 2>;
> mpic-msgr-receive-mask = <0x5>;
> };
>
> /* OS 2 */
> mpic_msgr_block0: mpic-msgr-block@41400 {
> compatible = "fsl,mpic-v3.1-msgr";
> reg = <0x41400 0x200>;
> interrupts = <0xb0 2 0xb2 2>;
> mpic-msgr-receive-mask = <0xa>;
> mpic-msgr-send-mask = <0x5>;
> };
>
> mpic_msgr_block1: mpic-msgr-block@42400 {
> compatible = "fsl,mpic-v3.1-msgr";
> reg = <0x42400 0x200>;
> interrupts = <0xb4 2 0xb6 2>;
> mpic-msgr-send-mask = <0x5>;
> };
>
> In block0 for both OSes, all registers are partitioned and are thus not
> available for allocation. In block1 for both OSes, registers 0 and 2 are
> reserved and registers 1 and 3 are available for general allocation.
How can both OSes independently own registers 1 and 3 for alloction? And
where are the interrupt specifiers for these registers?
> So any register mentioned in one of 'mpic-msgr-receive-mask' or
> 'mpic-msgr-send-mask' is out of the running for general allocation.
mpic-msgr-receive-mask has to match interrupts -- it's not intended to be
an indication of usage, just that this partition is granted those
interrupts.
Plus, a dynamically allocated message register must be owned for both
sending and receiving, so it doesn't make sense to separate it. I'd have
an "mpic-msgr-free-mask" property, which must be a subset of
"mpic-msgr-receive-mask". If the register is not in free-mask, it is
reserved for a fixed purpose. If free-mask is absent, all registers in the
receive-mask can be allocated.
So the above example would be:
/* OS 1 */
mpic_msgr_block0: mpic-msgr-block@41400 {
compatible = "fsl,mpic-v3.1-msgr";
reg = <0x41400 0x200>;
interrupts = <0xb0 2 0xb2 2>;
mpic-msgr-receive-mask = <0x5>;
mpic-msgr-free-mask = <0>;
};
mpic_msgr_block1: mpic-msgr-block@42400 {
compatible = "fsl,mpic-v3.1-msgr";
reg = <0x42400 0x200>;
interrupts = <0xb4 2 0xb5 2>;
mpic-msgr-receive-mask = <0x3>;
mpic-msgr-free-mask = <0x2>;
};
/* OS 2 */
mpic_msgr_block0: mpic-msgr-block@41400 {
compatible = "fsl,mpic-v3.1-msgr";
reg = <0x41400 0x200>;
interrupts = <0xb1 2 0xb3 2>;
mpic-msgr-receive-mask = <0xa>;
mpic-msgr-free-mask = <0>;
};
mpic_msgr_block1: mpic-msgr-block@42400 {
compatible = "fsl,mpic-v3.1-msgr";
reg = <0x42400 0x200>;
interrupts = <0xb6 2 0xb7 2>;
mpic-msgr-receive-mask = <0xc>;
mpic-msgr-free-mask = <0x8>;
};
mpic-msgr-send-mask could be added as well, as a permissions mechanism to
serve as extra protection against an improperly specified non-free message
register -- especially if the interface is exposed to a less-trusted realm
such as userspace, or if a hypervisor is reading the device tree to
determine what to allow guests to do. In this case, just like
mpic-msgr-receive-mask, it would list both free and non-free message
registers that the partition can send to, and mpic-msgr-free-mask would be
a subset of both the send and receive masks.
> You could get into trouble with this method with cases like:
>
> /* OS 1 */
> mpic_msgr_block0: mpic-msgr-block@41400 {
> compatible = "fsl,mpic-v3.1-msgr";
> reg = <0x41400 0x200>;
> interrupts = <0xb0 2 0xb2 2>;
> mpic-msgr-send-mask = <0xa>;
> };
>
> /* OS 2 */
> mpic_msgr_block0: mpic-msgr-block@41400 {
> compatible = "fsl,mpic-v3.1-msgr";
> reg = <0x41400 0x200>;
> interrupts = <0xb0 2 0xb2 2>;
> mpic-msgr-receive-mask = <0x5>;
> };
>
> Now OS 1 has registers 0 and 2 available for general allocation, which
> OS 2 is receiving on. However, we already have that problem if someone
> botches the masks. So I am not very worried about that.
There's a big difference between "botching the masks" and having no way to
express the situation properly.
BTW, the above fragment has the two OSes inappropriately sharing
interrupts, and OS1 has only two interrupts but no receive mask
(and therefore owns all 4 message registers for receive). Only one OS
should be able to receive any given interrupt.
Consider this:
/* OS 1 */
mpic_msgr_block0: mpic-msgr-block@41400 {
compatible = "fsl,mpic-v3.1-msgr";
reg = <0x41400 0x200>;
interrupts = <0xb0 2 0xb1 2>;
mpic-msgr-receive-mask = <0x3>;
mpic-msgr-send-mask = <0xc>;
};
/* OS 2 */
mpic_msgr_block0: mpic-msgr-block@41400 {
compatible = "fsl,mpic-v3.1-msgr";
reg = <0x41400 0x200>;
interrupts = <0xb2 2>;
mpic-msgr-receive-mask = <0x4>;
mpic-msgr-send-mask = <0x1>;
};
/* OS 3 */
mpic_msgr_block0: mpic-msgr-block@41400 {
compatible = "fsl,mpic-v3.1-msgr";
reg = <0x41400 0x200>;
interrupts = <0xb3 2>;
mpic-msgr-receive-mask = <0x8>;
mpic-msgr-send-mask = <0x2>;
};
None of the message registers are actually free for allocation, but with
your scheme OS 2 would think it could allocate 1 and 3, and OS 3 would
think it could allocate 0 and 2. Even if a register were actually free
from a reserved use, it would have to be owned by one partition.
-Scott
^ permalink raw reply
* [PATCH] powerpc: fix kexec with dynamic dma windows
From: Nishanth Aravamudan @ 2011-05-06 23:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard, Milton Miller
When we kexec we look for a particular property added by the first
kernel, "linux,direct64-ddr-window-info", per-device where we already
have set up dynamic dma windows. The current code, though, wasn't
initializing the size of this property and thus when we kexec'd, we
would find the property but read uninitialized memory resulting in
garbage ddw values for the kexec'd kernel and panics. Fix this by
setting the size at enable_ddw() time and ensuring that the size of the
found property is valid at dupe_ddw_if_kexec() time.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Cc: Milton Miller <miltonm@bga.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Anton Blanchard <anton@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/platforms/pseries/iommu.c | 23 ++++++++++++++---------
1 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
index 6d5412a..019009b 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -730,16 +730,20 @@ static u64 dupe_ddw_if_kexec(struct pci_dev *dev, struct device_node *pdn)
pcidn = PCI_DN(dn);
direct64 = of_get_property(pdn, DIRECT64_PROPNAME, &len);
if (direct64) {
- window = kzalloc(sizeof(*window), GFP_KERNEL);
- if (!window) {
+ if (len < sizeof(struct dynamic_dma_window_prop)) {
remove_ddw(pdn);
} else {
- window->device = pdn;
- window->prop = direct64;
- spin_lock(&direct_window_list_lock);
- list_add(&window->list, &direct_window_list);
- spin_unlock(&direct_window_list_lock);
- dma_addr = direct64->dma_base;
+ window = kzalloc(sizeof(*window), GFP_KERNEL);
+ if (!window) {
+ remove_ddw(pdn);
+ } else {
+ window->device = pdn;
+ window->prop = direct64;
+ spin_lock(&direct_window_list_lock);
+ list_add(&window->list, &direct_window_list);
+ spin_unlock(&direct_window_list_lock);
+ dma_addr = direct64->dma_base;
+ }
}
}
@@ -833,7 +837,7 @@ static u64 enable_ddw(struct pci_dev *dev, struct device_node *pdn)
struct device_node *dn;
const u32 *uninitialized_var(ddr_avail);
struct direct_window *window;
- struct property *uninitialized_var(win64);
+ struct property *win64;
struct dynamic_dma_window_prop *ddwprop;
mutex_lock(&direct_window_init_mutex);
@@ -907,6 +911,7 @@ static u64 enable_ddw(struct pci_dev *dev, struct device_node *pdn)
}
win64->name = kstrdup(DIRECT64_PROPNAME, GFP_KERNEL);
win64->value = ddwprop = kmalloc(sizeof(*ddwprop), GFP_KERNEL);
+ win64->length = sizeof(*ddwprop);
if (!win64->name || !win64->value) {
dev_info(&dev->dev,
"couldn't allocate property name and value\n");
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH 2/2] powerpc: add support for MPIC message register API
From: Meador Inge @ 2011-05-06 23:51 UTC (permalink / raw)
To: Scott Wood
Cc: Wood Scott-B07421, devicetree-discuss@lists.ozlabs.org,
Hollis Blanchard, Kushwaha Prabhakar-B32579,
openmcapi-dev@googlegroups.com, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20110506142937.77e7a10f@schlenkerla.am.freescale.net>
On 05/06/2011 02:29 PM, Scott Wood wrote:
> On Thu, 5 May 2011 16:41:29 -0500
>
> How can both OSes independently own registers 1 and 3 for alloction?
They can't. I just choose a horrible example. It does point to a serious
flaw (which you allude to later) in inferring free registers from send/receive:
in some cases one will have to arbitrarily add registers to send/receive masks
just to keep registers out of the free allocation pool. Your free-mask
proposal is better.
>> So any register mentioned in one of 'mpic-msgr-receive-mask' or
>> 'mpic-msgr-send-mask' is out of the running for general allocation.
>
> mpic-msgr-receive-mask has to match interrupts -- it's not intended to be
> an indication of usage, just that this partition is granted those
> interrupts.
>
> Plus, a dynamically allocated message register must be owned for both
> sending and receiving, so it doesn't make sense to separate it. I'd have
> an "mpic-msgr-free-mask" property, which must be a subset of
> "mpic-msgr-receive-mask". If the register is not in free-mask, it is
> reserved for a fixed purpose. If free-mask is absent, all registers in the
> receive-mask can be allocated.
>
> So the above example would be:
>
> /* OS 1 */
> mpic_msgr_block0: mpic-msgr-block@41400 {
> compatible = "fsl,mpic-v3.1-msgr";
> reg = <0x41400 0x200>;
> interrupts = <0xb0 2 0xb2 2>;
> mpic-msgr-receive-mask = <0x5>;
> mpic-msgr-free-mask = <0>;
> };
>
> mpic_msgr_block1: mpic-msgr-block@42400 {
> compatible = "fsl,mpic-v3.1-msgr";
> reg = <0x42400 0x200>;
> interrupts = <0xb4 2 0xb5 2>;
> mpic-msgr-receive-mask = <0x3>;
> mpic-msgr-free-mask = <0x2>;
> };
>
> /* OS 2 */
> mpic_msgr_block0: mpic-msgr-block@41400 {
> compatible = "fsl,mpic-v3.1-msgr";
> reg = <0x41400 0x200>;
> interrupts = <0xb1 2 0xb3 2>;
> mpic-msgr-receive-mask = <0xa>;
> mpic-msgr-free-mask = <0>;
> };
>
> mpic_msgr_block1: mpic-msgr-block@42400 {
> compatible = "fsl,mpic-v3.1-msgr";
> reg = <0x42400 0x200>;
> interrupts = <0xb6 2 0xb7 2>;
> mpic-msgr-receive-mask = <0xc>;
> mpic-msgr-free-mask = <0x8>;
> };
>
> mpic-msgr-send-mask could be added as well, as a permissions mechanism to
> serve as extra protection against an improperly specified non-free message
> register -- especially if the interface is exposed to a less-trusted realm
> such as userspace, or if a hypervisor is reading the device tree to
> determine what to allow guests to do. In this case, just like
> mpic-msgr-receive-mask, it would list both free and non-free message
> registers that the partition can send to, and mpic-msgr-free-mask would be
> a subset of both the send and receive masks.
free-mask seems reasonable. Although, all of these masks are starting to get
rather complicated :-)
Anyway, I am going to cut a v2 patch without the dynamic allocation. All
of this is getting complicated without a public use case. I agree with your
previous suggestion that the dynamic allocation can be added as a part of the
patch set that actually uses it.
Thanks Scott.
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
^ permalink raw reply
* ibm_newemac driver hangs while using 10Mbps full-duplex
From: Jignesh Patel @ 2011-05-07 1:18 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
Hi,
We are using denx kernel 2.6.31.4 on ppc405ex with national
semiconductor DP83640 Ethernet transceiver. The kernel driver
(ibm_newemac) seems to hang after setting the ethernet phy to use 10Mbps
Full-duplex settings. The time after which the driver hangs is random.
I am predicting that it's the driver issue because we cannot send or
receive any packets even though ethernet phy detects a good link and
interface is up (eth0). Bringing the interface down and back up using
ifconfig command fixes the hang and normal packet transfer continues.
Also, some times during 10Mbps operation we see following warning from
the kernel:
eth0: link is up, 10 FDX
NETDEV WATCHDOG: eth0 (emac): transmit queue 0 timed out
------------[ cut here ]------------
Badness at net/sched/sch_generic.c:246
NIP: c02094a4 LR: c02094a4 CTR: c0175af0
REGS: c03a9d00 TRAP: 0700 Not tainted (2.6.31.4)
MSR: 00029030 <EE,ME,CE,IR,DR> CR: 24000024 XER: 20000000
TASK = c037f440[0] 'swapper' THREAD: c03a8000
GPR00: c02094a4 c03a9db0 c037f440 0000003f 00002631 ffffffff c0175a5c
00000036
GPR08: c03b1d40 c0380000 00002631 00004000 24000082 fffffeef 0ffed700
00800000
GPR16: 00000000 007fff00 c038138c c03b0000 c0300000 c03b0000 0000000a
c03a9e18
GPR24: c0380000 c03a8000 00000000 c03b5ec8 c03b0000 c0380000 00000000
cf012000
NIP [c02094a4] dev_watchdog+0x290/0x2a0
LR [c02094a4] dev_watchdog+0x290/0x2a0
Call Trace:
[c03a9db0] [c02094a4] dev_watchdog+0x290/0x2a0 (unreliable)
[c03a9e10] [c002d60c] run_timer_softirq+0xfc/0x1b8
[c03a9e50] [c00284a8] __do_softirq+0xb0/0x130
[c03a9e90] [c0004900] do_softirq+0x58/0x5c
[c03a9ea0] [c00282bc] irq_exit+0x48/0x58
[c03a9eb0] [c000bd94] timer_interrupt+0xa4/0x108
[c03a9ed0] [c000f618] ret_from_except+0x0/0x18
[c03a9f90] [c0007eb0] cpu_idle+0xd0/0xe0
[c03a9fb0] [c0002928] rest_init+0x5c/0x6c
[c03a9fc0] [c0355738] start_kernel+0x230/0x2b8
[c03a9ff0] [c0002254] start_here+0x44/0xb0
Instruction dump:
7c0903a6 4bffff78 38810008 7fe3fb78 38a00040 4bfebc4d 7c651b78 3c60c033
7fc6f378 7fe4fb78 3863e668 4be1a415 <0fe00000> 38000001 901cfa00
4bffff14
eth0: link is down
Does anyone have an understanding of how ibm_newemac is supposed to
behave in 10Mbps Full-duplex operation? any help to solve this issue is
really appreciated
Thanks!
-Jignesh
^ permalink raw reply
* [PATCH] lib: Consolidate DEBUG_STACK_USAGE option
From: Stephen Boyd @ 2011-05-07 5:57 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-arch, linux-mips, linux-m32r, user-mode-linux-devel,
linux-sh, x86, linux-kernel, Chris Metcalf, sparclinux,
uclinux-dist-devel, linuxppc-dev, linux-arm-kernel
Most arches define CONFIG_DEBUG_STACK_USAGE exactly the same way.
Move it to lib/Kconfig.debug so each arch doesn't have to define
it. This obviously makes the option generic, but that's fine
because the config is already used in generic code.
It's not obvious to me that sysrq-P actually does anything
different with this option enabled, but I erred on the side of
caution by keeping the most inclusive wording.
Cc: linux-arch@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: uclinux-dist-devel@blackfin.uclinux.org
Cc: linux-m32r@ml.linux-m32r.org
Cc: linux-mips@linux-mips.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-sh@vger.kernel.org
Cc: sparclinux@vger.kernel.org
Cc: Chris Metcalf <cmetcalf@tilera.com>
Cc: user-mode-linux-devel@lists.sourceforge.net
Cc: x86@kernel.org
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
This is on top of mmotm's lib-conslidate-debug_per_cpu_maps patch.
arch/arm/Kconfig.debug | 7 -------
arch/blackfin/Kconfig.debug | 9 ---------
arch/m32r/Kconfig.debug | 9 ---------
arch/mips/Kconfig.debug | 9 ---------
arch/powerpc/Kconfig.debug | 9 ---------
arch/score/Kconfig.debug | 9 ---------
arch/sh/Kconfig.debug | 9 ---------
arch/sparc/Kconfig.debug | 9 ---------
arch/tile/Kconfig.debug | 9 ---------
arch/um/Kconfig.debug | 9 ---------
arch/unicore32/Kconfig.debug | 7 -------
arch/x86/Kconfig.debug | 9 ---------
lib/Kconfig.debug | 9 +++++++++
13 files changed, 9 insertions(+), 104 deletions(-)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 03d01d7..81cbe40 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -63,13 +63,6 @@ config DEBUG_USER
8 - SIGSEGV faults
16 - SIGBUS faults
-config DEBUG_STACK_USAGE
- bool "Enable stack utilization instrumentation"
- depends on DEBUG_KERNEL
- help
- Enables the display of the minimum amount of free stack which each
- task has ever had available in the sysrq-T output.
-
# These options are only for real kernel hackers who want to get their hands dirty.
config DEBUG_LL
bool "Kernel low-level debugging functions"
diff --git a/arch/blackfin/Kconfig.debug b/arch/blackfin/Kconfig.debug
index 2641731..19ccfb3 100644
--- a/arch/blackfin/Kconfig.debug
+++ b/arch/blackfin/Kconfig.debug
@@ -9,15 +9,6 @@ config DEBUG_STACKOVERFLOW
This option will cause messages to be printed if free stack space
drops below a certain limit.
-config DEBUG_STACK_USAGE
- bool "Enable stack utilization instrumentation"
- depends on DEBUG_KERNEL
- help
- Enables the display of the minimum amount of free stack which each
- task has ever had available in the sysrq-T output.
-
- This option will slow down process creation somewhat.
-
config DEBUG_VERBOSE
bool "Verbose fault messages"
default y
diff --git a/arch/m32r/Kconfig.debug b/arch/m32r/Kconfig.debug
index 2e1019d..bb1afc1 100644
--- a/arch/m32r/Kconfig.debug
+++ b/arch/m32r/Kconfig.debug
@@ -9,15 +9,6 @@ config DEBUG_STACKOVERFLOW
This option will cause messages to be printed if free stack space
drops below a certain limit.
-config DEBUG_STACK_USAGE
- bool "Stack utilization instrumentation"
- depends on DEBUG_KERNEL
- help
- Enables the display of the minimum amount of free stack which each
- task has ever had available in the sysrq-T and sysrq-P debug output.
-
- This option will slow down process creation somewhat.
-
config DEBUG_PAGEALLOC
bool "Debug page memory allocations"
depends on DEBUG_KERNEL && BROKEN
diff --git a/arch/mips/Kconfig.debug b/arch/mips/Kconfig.debug
index 5358f90..83ed00a 100644
--- a/arch/mips/Kconfig.debug
+++ b/arch/mips/Kconfig.debug
@@ -76,15 +76,6 @@ config DEBUG_STACKOVERFLOW
provides another way to check stack overflow happened on kernel mode
stack usually caused by nested interruption.
-config DEBUG_STACK_USAGE
- bool "Enable stack utilization instrumentation"
- depends on DEBUG_KERNEL
- help
- Enables the display of the minimum amount of free stack which each
- task has ever had available in the sysrq-T and sysrq-P debug output.
-
- This option will slow down process creation somewhat.
-
config SMTC_IDLE_HOOK_DEBUG
bool "Enable additional debug checks before going into CPU idle loop"
depends on DEBUG_KERNEL && MIPS_MT_SMTC
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index 12a8d18..f862fc0 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -35,15 +35,6 @@ config DEBUG_STACKOVERFLOW
This option will cause messages to be printed if free stack space
drops below a certain limit.
-config DEBUG_STACK_USAGE
- bool "Stack utilization instrumentation"
- depends on DEBUG_KERNEL
- help
- Enables the display of the minimum amount of free stack which each
- task has ever had available in the sysrq-T and sysrq-P debug output.
-
- This option will slow down process creation somewhat.
-
config HCALL_STATS
bool "Hypervisor call instrumentation"
depends on PPC_PSERIES && DEBUG_FS && TRACEPOINTS
diff --git a/arch/score/Kconfig.debug b/arch/score/Kconfig.debug
index 451ed54..a1f346d 100644
--- a/arch/score/Kconfig.debug
+++ b/arch/score/Kconfig.debug
@@ -16,15 +16,6 @@ config CMDLINE
other cases you can specify kernel args so that you don't have
to set them up in board prom initialization routines.
-config DEBUG_STACK_USAGE
- bool "Enable stack utilization instrumentation"
- depends on DEBUG_KERNEL
- help
- Enables the display of the minimum amount of free stack which each
- task has ever had available in the sysrq-T and sysrq-P debug output.
-
- This option will slow down process creation somewhat.
-
config RUNTIME_DEBUG
bool "Enable run-time debugging"
depends on DEBUG_KERNEL
diff --git a/arch/sh/Kconfig.debug b/arch/sh/Kconfig.debug
index 1553d56..c1d5a82 100644
--- a/arch/sh/Kconfig.debug
+++ b/arch/sh/Kconfig.debug
@@ -28,15 +28,6 @@ config STACK_DEBUG
every function call and will therefore incur a major
performance hit. Most users should say N.
-config DEBUG_STACK_USAGE
- bool "Stack utilization instrumentation"
- depends on DEBUG_KERNEL
- help
- Enables the display of the minimum amount of free stack which each
- task has ever had available in the sysrq-T and sysrq-P debug output.
-
- This option will slow down process creation somewhat.
-
config 4KSTACKS
bool "Use 4Kb for kernel stacks instead of 8Kb"
depends on DEBUG_KERNEL && (MMU || BROKEN) && !PAGE_SIZE_64KB
diff --git a/arch/sparc/Kconfig.debug b/arch/sparc/Kconfig.debug
index d9a795e..6db35fb 100644
--- a/arch/sparc/Kconfig.debug
+++ b/arch/sparc/Kconfig.debug
@@ -6,15 +6,6 @@ config TRACE_IRQFLAGS_SUPPORT
source "lib/Kconfig.debug"
-config DEBUG_STACK_USAGE
- bool "Enable stack utilization instrumentation"
- depends on DEBUG_KERNEL
- help
- Enables the display of the minimum amount of free stack which each
- task has ever had available in the sysrq-T and sysrq-P debug output.
-
- This option will slow down process creation somewhat.
-
config DEBUG_DCFLUSH
bool "D-cache flush debugging"
depends on SPARC64 && DEBUG_KERNEL
diff --git a/arch/tile/Kconfig.debug b/arch/tile/Kconfig.debug
index 9bc161a..ddbfc33 100644
--- a/arch/tile/Kconfig.debug
+++ b/arch/tile/Kconfig.debug
@@ -21,15 +21,6 @@ config DEBUG_STACKOVERFLOW
This option will cause messages to be printed if free stack space
drops below a certain limit.
-config DEBUG_STACK_USAGE
- bool "Stack utilization instrumentation"
- depends on DEBUG_KERNEL
- help
- Enables the display of the minimum amount of free stack which each
- task has ever had available in the sysrq-T and sysrq-P debug output.
-
- This option will slow down process creation somewhat.
-
config DEBUG_EXTRA_FLAGS
string "Additional compiler arguments when building with '-g'"
depends on DEBUG_INFO
diff --git a/arch/um/Kconfig.debug b/arch/um/Kconfig.debug
index 8fce5e5..34ac57f 100644
--- a/arch/um/Kconfig.debug
+++ b/arch/um/Kconfig.debug
@@ -28,13 +28,4 @@ config GCOV
If you're involved in UML kernel development and want to use gcov,
say Y. If you're unsure, say N.
-config DEBUG_STACK_USAGE
- bool "Stack utilization instrumentation"
- default N
- help
- Track the maximum kernel stack usage - this will look at each
- kernel stack at process exit and log it if it's the deepest
- stack seen so far.
-
- This option will slow down process creation and destruction somewhat.
endmenu
diff --git a/arch/unicore32/Kconfig.debug b/arch/unicore32/Kconfig.debug
index 3140151..ae2ec33 100644
--- a/arch/unicore32/Kconfig.debug
+++ b/arch/unicore32/Kconfig.debug
@@ -27,13 +27,6 @@ config EARLY_PRINTK
with klogd/syslogd or the X server. You should normally N here,
unless you want to debug such a crash.
-config DEBUG_STACK_USAGE
- bool "Enable stack utilization instrumentation"
- depends on DEBUG_KERNEL
- help
- Enables the display of the minimum amount of free stack which each
- task has ever had available in the sysrq-T output.
-
# These options are only for real kernel hackers who want to get their hands dirty.
config DEBUG_LL
bool "Kernel low-level debugging functions"
diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index 1bf8839..c0f8a5c 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -66,15 +66,6 @@ config DEBUG_STACKOVERFLOW
This option will cause messages to be printed if free stack space
drops below a certain limit.
-config DEBUG_STACK_USAGE
- bool "Stack utilization instrumentation"
- depends on DEBUG_KERNEL
- ---help---
- Enables the display of the minimum amount of free stack which each
- task has ever had available in the sysrq-T and sysrq-P debug output.
-
- This option will slow down process creation somewhat.
-
config X86_PTDUMP
bool "Export kernel pagetable layout to userspace via debugfs"
depends on DEBUG_KERNEL
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index c0872ee..37fae12 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -654,6 +654,15 @@ config STACKTRACE
bool
depends on STACKTRACE_SUPPORT
+config DEBUG_STACK_USAGE
+ bool "Stack utilization instrumentation"
+ depends on DEBUG_KERNEL
+ help
+ Enables the display of the minimum amount of free stack which each
+ task has ever had available in the sysrq-T and sysrq-P debug output.
+
+ This option will slow down process creation somewhat.
+
config DEBUG_KOBJECT
bool "kobject debugging"
depends on DEBUG_KERNEL
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* RE: [RFC v2] virtio: add virtio-over-PCI driver
From: Kushwaha Prabhakar-B32579 @ 2011-05-07 5:59 UTC (permalink / raw)
To: Ira W. Snyder
Cc: Aggrwal Poonam-B10812, netdev@vger.kernel.org, Zang Roy-R61911,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
Kalra Ashish-B00888, Gala Kumar-B11780, Gupta Maneesh-B18878,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20110506160627.GB14069@ovro.caltech.edu>
Thanks Ira for your kind reply.
I will look for the mentioned pointers :)=20
Prabhakar=20
> -----Original Message-----
> From: Ira W. Snyder [mailto:iws@ovro.caltech.edu]
> Sent: Friday, May 06, 2011 9:36 PM
> To: Kushwaha Prabhakar-B32579
> Cc: Zang Roy-R61911; Gala Kumar-B11780; Gupta Maneesh-B18878; Aggrwal
> Poonam-B10812; Kalra Ashish-B00888; linux-kernel@vger.kernel.org;
> linuxppc-dev@ozlabs.org; netdev@vger.kernel.org
> Subject: Re: [RFC v2] virtio: add virtio-over-PCI driver
>=20
> On Fri, May 06, 2011 at 12:00:34PM +0000, Kushwaha Prabhakar-B32579
> wrote:
> > Hi,
> >
> > I want to use this patch as base patch for "FSL 85xx platform" to
> support PCIe Agent.
> > The work looks to be little old now. So wanted to understand if any
> development has happened further on it.
> >
> > In case no, I would take this work forward for PCIe Agent.
> >
> > Any help/suggestions are most appreciated in this regard.
> >
>=20
> Hi Prabhakar,
>=20
> I use PCI agent mode on an mpc8349emds board. All of the important setup
> is done very early in the boot process, by U-Boot. Search the U-Boot
> source for CONFIG_PCISLAVE. I hunch that the setup needed for 85xx boards
> are similar.
>=20
> This virtio-over-PCI work is now very old. It was intended to provide a
> communication mechanism between a PCI Master and many PCI Agents
> (slaves).
> Dave Miller (networking maintainer) suggested to use virtio for this so
> that many different devices could be used. Such as:
> - network interface
> - serial port (for serial console)
>=20
> I am aware of other ongoing work in this area. Specifically, some ARM
> developers are working on a virtio API using their message registers.
> This work is much newer, and will be a much better starting place for
> you.
>=20
> Search the virtualization mailing list for:
> "[PATCH 00/02] virtio: Virtio platform driver"
>=20
> Here is a link to some of their code:
> http://www.spinics.net/lists/linux-sh/msg07188.html
>=20
> I am currently using a custom driver to provide a network device on my
> PCI agents. Searching the mailing list archives for "PCINet", you will
> find early versions of the driver. I am happy to provide you a current
> copy. It does not use virtio at all, and is unlikely to be accepted into
> mainline Linux.
>=20
> I am happy to provide any of my code if you think it would help you get
> started. Specifically, the current version of "PCINet" show how to use
> the DMA controller in order to get good network performance. I am also
> happy to help port code to 83xx, as well as test on 83xx. Please ask any
> questions you may have.
>=20
> I have people ask about this code about once every two months. There is
> plenty of interest in a mainline Linux solution to this problem. :) I
> will be moving to 85xx someday, and I hope there is an accepted mainline
> solution by then.
>=20
> I hope it helps,
> Ira
>=20
> > -----Original Message-----
> > From: linux-kernel-owner@vger.kernel.org
> > [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Ira Snyder
> > Sent: Friday, 27 February, 2009 3:19 AM
> > To: Arnd Bergmann
> > Cc: linux-kernel@vger.kernel.org; Rusty Russell; Jan-Bernd Themann;
> > linuxppc-dev@ozlabs.org; netdev@vger.kernel.org
> > Subject: Re: [RFC v2] virtio: add virtio-over-PCI driver
> >
> > On Thu, Feb 26, 2009 at 09:37:14PM +0100, Arnd Bergmann wrote:
> > > On Thursday 26 February 2009, Ira Snyder wrote:
> > > > On Thu, Feb 26, 2009 at 05:15:27PM +0100, Arnd Bergmann wrote:
> > > >
> > > > I think so too. I was just getting something working, and thought
> > > > it would be better to have it "out there" rather than be working
> > > > on it forever. I'll try to break things up as I have time.
> > >
> > > Ok, perfect!
> > >
> > > > For the "libraries", would you suggest breaking things into
> > > > seperate code files, and using EXPORT_SYMBOL_GPL()? I'm not very
> > > > familiar with doing that, I've mostly been writing code within the
> > > > existing device driver frameworks. Or do I need export symbol at
> all? I'm not sure...
> > >
> > > You have both options. When you list each file as a separate module
> > > in the Makefile, you use EXPORT_SYMBOL_GPL to mark functions that
> > > get called by dependent modules, but this will work only in one way.
> > >
> > > You can also link multiple files together into one module, although
> > > it is less common to link a single source file into multiple modules.
> > >
> >
> > Ok. I'm more familiar with the EXPORT_SYMBOL_GPL interface, so I'll do
> that. If we decide it sucks later, we'll change it.
> >
> > > > I always thought you were supposed to use packed for data
> > > > structures that are external to the system. I purposely designed
> > > > the structures so they wouldn't need padding.
> > >
> > > That would only make sense for structures that are explicitly
> > > unaligned, like a register layout using
> > >
> > > struct my_registers {
> > > __le16 first;
> > > __le32 second __attribute__((packed));
> > > __le16 third;
> > > };
> > >
> > > Even here, I'd recommend listing the individual members as packed
> > > rather than the entire struct. Obviously if you layout the members
> > > in a sane way, you don't need either.
> > >
> >
> > Ok. I'll drop the __attribute__((packed)) and make sure there aren't
> problems. I don't suspect any, though.
> >
> > > > I mostly don't need it. In fact, the only place I'm using
> > > > registers not specific to the messaging unit is in the probe
> > > > routine, where I setup the 1GB window into host memory and setting
> > > > up access to the guest memory on the PCI bus.
> > >
> > > You could add the registers you need for this to the "reg" property
> > > of your device, to be mapped with of_iomap.
> > >
> > > If the registers for setting up this window don't logically fit into
> > > the same device as the one you already use, the cleanest solution
> > > would be to have another device just for this and then make a
> > > function call into that driver to set up the window.
> > >
> >
> > The registers are part of the board control registers. They don't fit
> at all in the message unit. Doing this in the bootloader seems like a
> logical place, but that would require any testers to flash a new U-Boot
> image into their mpc8349emds boards.
> >
> > The first set of access is used to set up a 1GB region in the memory
> map that accesses the host's memory. Any reads/writes to addresses
> 0x80000000-0xc0000000 actually hit the host's memory.
> >
> > The last access sets up PCI BAR1 to hit the memory from
> dma_alloc_coherent(). The bootloader already sets up the window as 16K,
> it just doesn't point it anywhere. Maybe this /should/ go into the
> bootloader. Like above, it would require testers to flash a new U-Boot
> image into their mpc8349emds boards.
> >
> > > > Now, I wouldn't need to access these registers at all if the
> > > > bootloader could handle it. I just don't know if it is possible to
> > > > have Linux not use some memory that the bootloader allocated,
> > > > other than with the mem=3DXXX trick, which I'm sure wouldn't be
> acceptable.
> > > > I've just used regular RAM so this is portable to my custom board
> > > > (mpc8349emds based) and a regular mpc8349emds. I didn't want to
> > > > change anything board specific.
> > > >
> > > > I would love to have the bootloader allocate (or reserve somewhere
> > > > in the memory map) 16K of RAM, and not be required to allocate it
> > > > with dma_alloc_coherent(). It would save me plenty of headaches.
> > >
> > > I believe you can do that through the "memory" devices in the device
> > > tree, by leaving out a small part of the description of main memory,
> > > at putting it into the "reg" property of your own device.
> > >
> >
> > I'll explore this option. I didn't even know you could do this. Is a
> driver that requires the trick acceptable for mainline inclusion? Just
> like setting up the 16K PCI window, this is very platform specific.
> >
> > This limits the guest driver to systems which are able to change
> Linux's view of their memory somehow. Maybe this isn't a problem.
> >
> > > > Code complexity only. Also, it was easier to write 80-char lines
> > > > with something like:
> > > >
> > > > vop_get_desc(vq, idx, &desc);
> > > > if (desc.flags & VOP_DESC_F_NEXT) {
> > > > /* do something */
> > > > }
> > > >
> > > > Instead of:
> > > > if (le16_to_cpu(vq->desc[idx].flags) & VOP_DESC_F_NEXT) {
> > > > /* do something */
> > > > }
> > > >
> > > > Plus, I didn't have to remember how many bits were in each field.
> > > > I just thought it made everything simpler to understand.
> Suggestions?
> > >
> > > hmm, in this particular case, you could change the definition of
> > > VOP_DESC_F_NEXT to
> > >
> > > #define VOP_DESC_F_NEXT cpu_to_le16(1)
> > >
> > > and then do the code as the even simpler (source and object code
> > > wise)
> > >
> > > if (vq->desc[idx].flags) & VOP_DESC_F_NEXT)
> > >
> > > I'm not sure if you can do something along these lines for the other
> > > cases as well though.
> > >
> >
> > That's a good idea. It wouldn't fix the addresses, lengths, and next
> fields, though. I'll make the change and see how bad it is, then report
> back. It may not be so bad after all.
> >
> > > > I used 3 so they would would align to 1024 byte boundaries within
> > > > a 4K page. Then the layout was 16K on the bus, each 4K page is a
> > > > single virtio-device, and each 1K block is a single virtqueue. The
> > > > first 1K is for virtio-device status and feature bits, etc.
> > > >
> > > > Packing them differently isn't a problem. It was just easier to
> > > > code because setting up a window with the correct size is so
> > > > platform specific.
> > >
> > > Ok. I guess the important question is what part of the code makes
> > > this decision. Ideally, the virtio-net glue would instantiate the
> > > device with the right number of queues.
> > >
> >
> > Yeah, virtio doesn't work that way.
> >
> > The virtio drivers just call find_vq() with a different index for each
> queue they want to use. You have no way of knowing how many queues each
> virtio driver will want, unless you go read their source code.
> >
> > virtio-net currently uses 3 queues, but we only support the first two.
> > The third is optional (for now...), and non-symmetric.
> >
> > Thanks again,
> > Ira
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-kernel" in the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
> >
> >
> >
^ permalink raw reply
* Re: [PATCH] lib: Consolidate DEBUG_STACK_USAGE option
From: David Miller @ 2011-05-07 7:58 UTC (permalink / raw)
To: sboyd
Cc: linux-arch, linux-mips, linux-m32r, user-mode-linux-devel,
linux-sh, x86, linux-kernel, cmetcalf, sparclinux,
uclinux-dist-devel, akpm, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1304747831-2098-1-git-send-email-sboyd@codeaurora.org>
From: Stephen Boyd <sboyd@codeaurora.org>
Date: Fri, 6 May 2011 22:57:11 -0700
> Most arches define CONFIG_DEBUG_STACK_USAGE exactly the same way.
> Move it to lib/Kconfig.debug so each arch doesn't have to define
> it. This obviously makes the option generic, but that's fine
> because the config is already used in generic code.
>
> It's not obvious to me that sysrq-P actually does anything
> different with this option enabled, but I erred on the side of
> caution by keeping the most inclusive wording.
>
> Cc: linux-arch@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: uclinux-dist-devel@blackfin.uclinux.org
> Cc: linux-m32r@ml.linux-m32r.org
> Cc: linux-mips@linux-mips.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-sh@vger.kernel.org
> Cc: sparclinux@vger.kernel.org
> Cc: Chris Metcalf <cmetcalf@tilera.com>
> Cc: user-mode-linux-devel@lists.sourceforge.net
> Cc: x86@kernel.org
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH] lib: Consolidate DEBUG_STACK_USAGE option
From: richard -rw- weinberger @ 2011-05-07 9:34 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arch, linux-mips, linux-m32r, user-mode-linux-devel,
linux-sh, x86, linux-kernel, Chris Metcalf, sparclinux,
uclinux-dist-devel, Andrew Morton, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1304747831-2098-1-git-send-email-sboyd@codeaurora.org>
On Sat, May 7, 2011 at 7:57 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> Most arches define CONFIG_DEBUG_STACK_USAGE exactly the same way.
> Move it to lib/Kconfig.debug so each arch doesn't have to define
> it. This obviously makes the option generic, but that's fine
> because the config is already used in generic code.
>
> It's not obvious to me that sysrq-P actually does anything
> different with this option enabled, but I erred on the side of
> caution by keeping the most inclusive wording.
>
> Cc: linux-arch@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: uclinux-dist-devel@blackfin.uclinux.org
> Cc: linux-m32r@ml.linux-m32r.org
> Cc: linux-mips@linux-mips.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-sh@vger.kernel.org
> Cc: sparclinux@vger.kernel.org
> Cc: Chris Metcalf <cmetcalf@tilera.com>
> Cc: user-mode-linux-devel@lists.sourceforge.net
> Cc: x86@kernel.org
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
Acked-by: Richard Weinberger <richard@nod.at>
--
Thanks,
//richard
^ permalink raw reply
* Regarding P2020 in AMP mode
From: Prasanna Khanapur @ 2011-05-07 12:20 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]
Hi,
I'm running P2020 in AMP mode, each core running its linux os.
Ethernet 1(@25000) and Ethernet 2(@26000) assigned to Core0 are working
fine.
I'm facing problems with Ethernet interface(@24000) assigned to Core1, its
not working.
I'm using dts file which were added by :
http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-September/075594.html
Looks either there is some mistake in the dts file or my understanding is
wrong.
MDIO @24000 is defined in core0 dts file though the Ethernet is assigned to
Core 1.
DTS files :
http://web.mornfall.net/repos/linux-2.6/git/arch/powerpc/boot/dts/p2020rdb_camp_core0.dts
http://web.mornfall.net/repos/linux-2.6/git/arch/powerpc/boot/dts/p2020rdb_camp_core1.dts
mdio@24520 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,gianfar-mdio";
reg = <0x24520 0x20>;
phy0: ethernet-phy@0 {
interrupt-parent = <&mpic>;
interrupts = <3 1>;
reg = <0x0>;
};
phy1: ethernet-phy@1 {
interrupt-parent = <&mpic>;
interrupts = <3 1>;
reg = <0x1>;
};
};
Also, MDIO for 25520 has wrong register value:
mdio@25520 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,gianfar-tbi";
reg = <0x26520 0x20>;
tbi0: tbi-phy@11 {
reg = <0x11>;
device_type = "tbi-phy";
};
};
Please correct me if I'm wrong. Has freescale released a working dts files
for P2020 in AMP mode ? as this seems to be not working.
Best Regards
Prasanna Khanapur.
[-- Attachment #2: Type: text/html, Size: 3019 bytes --]
^ permalink raw reply
* Re: [PATCH] lib: Consolidate DEBUG_STACK_USAGE option
From: Mike Frysinger @ 2011-05-07 13:57 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arch, linux-mips, linux-m32r, user-mode-linux-devel,
linux-sh, x86, linux-kernel, Chris Metcalf, sparclinux,
uclinux-dist-devel, Andrew Morton, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1304747831-2098-1-git-send-email-sboyd@codeaurora.org>
On Sat, May 7, 2011 at 01:57, Stephen Boyd wrote:
> Most arches define CONFIG_DEBUG_STACK_USAGE exactly the same way.
> Move it to lib/Kconfig.debug so each arch doesn't have to define
> it. This obviously makes the option generic, but that's fine
> because the config is already used in generic code.
>
> It's not obvious to me that sysrq-P actually does anything
> different with this option enabled, but I erred on the side of
> caution by keeping the most inclusive wording.
>
> Cc: uclinux-dist-devel@blackfin.uclinux.org
> =C2=A0arch/blackfin/Kconfig.debug =C2=A0| =C2=A0 =C2=A09 ---------
Acked-by: Mike Frysinger <vapier@gentoo.org>
-mike
^ permalink raw reply
* [PATCH 2/2] ppc64: Fix compiler warning in pgtable-ppc64.h [-Wunused-but-set-variable]
From: Stratos Psomadakis @ 2011-05-07 14:11 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-kernel
In-Reply-To: <1304777491-7947-1-git-send-email-psomas@cslab.ece.ntua.gr>
The variable 'old' is set but not used in the wrprotect functions in
arch/powerpc/include/asm/pgtable-ppc64.h, which can trigger a compiler warning.
Remove the variable, since it's not used anyway.
Signed-off-by: Stratos Psomadakis <psomas@ece.ntua.gr>
---
arch/powerpc/include/asm/pgtable-ppc64.h | 13 ++++++-------
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h b/arch/powerpc/include/asm/pgtable-ppc64.h
index 2b09cd5..0b27dba 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
@@ -257,21 +257,20 @@ static inline int __ptep_test_and_clear_young(struct mm_struct *mm,
static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long addr,
pte_t *ptep)
{
- unsigned long old;
- if ((pte_val(*ptep) & _PAGE_RW) == 0)
- return;
- old = pte_update(mm, addr, ptep, _PAGE_RW, 0);
+ if ((pte_val(*ptep) & _PAGE_RW) == 0)
+ return;
+
+ pte_update(mm, addr, ptep, _PAGE_RW, 0);
}
static inline void huge_ptep_set_wrprotect(struct mm_struct *mm,
unsigned long addr, pte_t *ptep)
{
- unsigned long old;
-
if ((pte_val(*ptep) & _PAGE_RW) == 0)
return;
- old = pte_update(mm, addr, ptep, _PAGE_RW, 1);
+
+ pte_update(mm, addr, ptep, _PAGE_RW, 1);
}
/*
--
1.5.6.5
^ permalink raw reply related
* [PATCH 0/2] ppc/cleaup: Fix compiler warnings
From: Stratos Psomadakis @ 2011-05-07 14:11 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stratos Psomadakis, linux-kernel
Fix compiler warnings in ppc code, which can lead to build failure, if
CONFIG_PPC_WERROR is set (default).
arch/powerpc/include/asm/pgtable-ppc64.h | 13 ++++++-------
arch/powerpc/kernel/Makefile | 2 +-
2 files changed, 7 insertions(+), 8 deletions(-)
^ permalink raw reply
* [PATCH 1/2] ppc: Fix compiler warning in ptrace.c [-Wno-array-bounds]
From: Stratos Psomadakis @ 2011-05-07 14:11 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-kernel
In-Reply-To: <1304777491-7947-1-git-send-email-psomas@cslab.ece.ntua.gr>
The trick used to bypass the thread_struct fpr array in order to access the
struct fpscr, in arch/powerpc/kernel/ptrace.c, can trigger an "array subscript
is above array bounds [-Werror=array-bounds]" warning.
Add -Wno-array-bounds to CFLAGS_ptrace.o, in arch/powerpc/kernel/Makefile to
slience this warning.
Signed-off-by: Stratos Psomadakis <psomas@ece.ntua.gr>
---
arch/powerpc/kernel/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 3bb2a3e..92b1002 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -2,7 +2,7 @@
# Makefile for the linux kernel.
#
-CFLAGS_ptrace.o += -DUTS_MACHINE='"$(UTS_MACHINE)"'
+CFLAGS_ptrace.o += -DUTS_MACHINE='"$(UTS_MACHINE)"' -Wno-array-bounds
subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH 1/2] ppc: Fix compiler warning in ptrace.c [-Wno-array-bounds]
From: Andreas Schwab @ 2011-05-07 15:18 UTC (permalink / raw)
To: Stratos Psomadakis; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1304777491-7947-2-git-send-email-psomas@cslab.ece.ntua.gr>
Stratos Psomadakis <psomas@cslab.ece.ntua.gr> writes:
> +CFLAGS_ptrace.o += -DUTS_MACHINE='"$(UTS_MACHINE)"' -Wno-array-bounds
You need to check first whether the option is valid.
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
* [RESEND PATCH 1/2] ppc: Fix compiler warning in ptrace.c [-Wno-array-bounds]
From: Stratos Psomadakis @ 2011-05-07 15:54 UTC (permalink / raw)
To: linuxppc-dev; +Cc: schwab, linux-kernel
In-Reply-To: <m2oc3eh744.fsf@igel.home>
The trick used to bypass the thread_struct fpr array in order to access the
struct fpscr, in arch/powerpc/kernel/ptrace.c, can trigger an "array subscript
is above array bounds [-Werror=array-bounds]" warning.
Add -Wno-array-bounds to CFLAGS_ptrace.o, in arch/powerpc/kernel/Makefile to
slience this warning.
Signed-off-by: Stratos Psomadakis <psomas@ece.ntua.gr>
---
arch/powerpc/kernel/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 3bb2a3e..92b1002 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -2,7 +2,7 @@
# Makefile for the linux kernel.
#
-CFLAGS_ptrace.o += -DUTS_MACHINE='"$(UTS_MACHINE)"'
+CFLAGS_ptrace.o += -DUTS_MACHINE='"$(UTS_MACHINE)"' $(call cc-option, -Wno-array-bounds)
subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH 1/2] ppc: Fix compiler warning in ptrace.c [-Wno-array-bounds]
From: Stratos Psomadakis @ 2011-05-07 15:57 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Stratos Psomadakis, linuxppc-dev, linux-kernel
In-Reply-To: <m2oc3eh744.fsf@igel.home>
On 05/07/2011 06:18 PM, Andreas Schwab wrote:
> Stratos Psomadakis <psomas@cslab.ece.ntua.gr> writes:
>
>> +CFLAGS_ptrace.o += -DUTS_MACHINE='"$(UTS_MACHINE)"' -Wno-array-bounds
> You need to check first whether the option is valid.
>
> Andreas.
>
I resent the patch, with $(call cc-option) to check if GCC supports the
option. Is it ok?
Thx.
--
Stratos Psomadakis
<psomas@ece.ntua.gr>
^ permalink raw reply
* Re: [PATCH] PCI: portdrv: fix irq initialization on FSL pcie host controller
From: Kumar Gala @ 2011-05-07 16:21 UTC (permalink / raw)
To: Xu Lei; +Cc: linux-pci, linuxppc-dev, linux-kernel
In-Reply-To: <1303977671.1642.742.camel@xulei-desktop>
On Apr 28, 2011, at 3:01 AM, Xu Lei wrote:
>=20
> Any feedback on this patch? Thanks.
>=20
> On Friday, 2011-04-22 at 15:43 +0800, Lei Xu wrote:
>> Root complex ports for Freescale PCIe host controller only receive
>> interrupts, so if there is no irq setting for RC, it should not =
return
>> error, otherwise it may result the PCIe host controller is disabled.
>>=20
>> Signed-off-by: Lei Xu <B33228@freescale.com>
>> ---
>> drivers/pci/pcie/portdrv_core.c | 5 ++++-
>> 1 files changed, 4 insertions(+), 1 deletions(-)
>>=20
>> diff --git a/drivers/pci/pcie/portdrv_core.c =
b/drivers/pci/pcie/portdrv_core.c
>> index 595654a..95e64c8 100644
>> --- a/drivers/pci/pcie/portdrv_core.c
>> +++ b/drivers/pci/pcie/portdrv_core.c
>> @@ -209,7 +209,10 @@ static int init_service_irqs(struct pci_dev =
*dev, int *irqs, int mask)
>> irqs[i] =3D irq;
>> irqs[PCIE_PORT_SERVICE_VC_SHIFT] =3D -1;
>>=20
>> - if (irq < 0)
>> + /* Root complex ports for Freescale PCIe host controller only
>> + * receive interrupts, so if there is no irq setting for RC,
>> + * it should not return error. */
>> + if ((irq < 0) && (dev->pcie_type !=3D PCI_EXP_TYPE_ROOT_PORT))
>> return -ENODEV;
>> return 0;
>> }
>=20
> --=20
> Regards
>=20
> Lei
>=20
Reviewing this in more detail this is not the right solution. We should =
have an dev->irq set and need to fix that.
The means to accomplish that is by fixing up the device tree to properly =
get the interrupt assigned to the root complex node.
- k=
^ permalink raw reply
* Re: [PATCH] atomic: add *_dec_not_zero
From: Sven Eckelmann @ 2011-05-08 9:33 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: linux-arch, linux-mips, linux-m32r, linux-ia64, linux-cris-kernel,
linux-parisc, linux-s390, linux-sh, linux-kernel, Chris Metcalf,
David Howells, linux-m68k, linux-am33-list, linux-alpha,
sparclinux, uclinux-dist-devel, x86, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20110508092403.GB27807@n2100.arm.linux.org.uk>
[-- Attachment #1: Type: Text/Plain, Size: 777 bytes --]
Russell King - ARM Linux wrote:
[...]
> Do we need atomic_dec_not_zero() et.al. in every arch header - is there no
> generic header which it could be added to?
Mike Frysinger already tried to answer it in
<BANLkTimctgbto3dsnJ3d3r7NggS0KF9_Sw@mail.gmail.com>:
> that's what asm-generic is for. if the arch isnt using it, it's
> either because the arch needs to convert to it, or they're using SMP
> and asm-generic doesnt yet support that for atomic.h.
>
> for example, the Blackfin port only needed updating for the SMP case.
> in the non-SMP case, we're getting the def from asm-generic/atomic.h.
> -mike
Feel free to change that but I just followed the style used by all other
macros and will not redesign the complete atomic*.h idea.
thanks,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] atomic: add *_dec_not_zero
From: Russell King - ARM Linux @ 2011-05-08 9:24 UTC (permalink / raw)
To: Sven Eckelmann
Cc: linux-arch, linux-mips, linux-m32r, linux-ia64, linux-cris-kernel,
linux-parisc, linux-s390, linux-sh, linux-kernel, Chris Metcalf,
David Howells, linux-m68k, linux-am33-list, linux-alpha,
sparclinux, uclinux-dist-devel, x86, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <1304458235-28473-1-git-send-email-sven@narfation.org>
On Tue, May 03, 2011 at 11:30:35PM +0200, Sven Eckelmann wrote:
> Introduce an *_dec_not_zero operation. Make this a special case of
> *_add_unless because batman-adv uses atomic_dec_not_zero in different
> places like re-broadcast queue or aggregation queue management. There
> are other non-final patches which may also want to use this macro.
...
> diff --git a/arch/arm/include/asm/atomic.h b/arch/arm/include/asm/atomic.h
> index 7e79503..a005265 100644
> --- a/arch/arm/include/asm/atomic.h
> +++ b/arch/arm/include/asm/atomic.h
> @@ -218,6 +218,7 @@ static inline int atomic_add_unless(atomic_t *v, int a, int u)
> return c != u;
> }
> #define atomic_inc_not_zero(v) atomic_add_unless((v), 1, 0)
> +#define atomic_dec_not_zero(v) atomic_add_unless((v), -1, 0)
>
> #define atomic_inc(v) atomic_add(1, v)
> #define atomic_dec(v) atomic_sub(1, v)
> @@ -459,6 +460,7 @@ static inline int atomic64_add_unless(atomic64_t *v, u64 a, u64 u)
> #define atomic64_dec_return(v) atomic64_sub_return(1LL, (v))
> #define atomic64_dec_and_test(v) (atomic64_dec_return((v)) == 0)
> #define atomic64_inc_not_zero(v) atomic64_add_unless((v), 1LL, 0LL)
> +#define atomic64_dec_not_zero(v) atomic64_add_unless((v), -1LL, 0LL)
>
> #else /* !CONFIG_GENERIC_ATOMIC64 */
> #include <asm-generic/atomic64.h>
Do we need atomic_dec_not_zero() et.al. in every arch header - is there no
generic header which it could be added to?
^ permalink raw reply
* Re: [PATCH 0/2] ppc/cleaup: Fix compiler warnings
From: Stratos Psomadakis @ 2011-05-08 20:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus, linux-kernel
In-Reply-To: <1304777491-7947-1-git-send-email-psomas@cslab.ece.ntua.gr>
On 05/07/2011 05:11 PM, Stratos Psomadakis wrote:
> Fix compiler warnings in ppc code, which can lead to build failure, if
> CONFIG_PPC_WERROR is set (default).
>
> arch/powerpc/include/asm/pgtable-ppc64.h | 13 ++++++-------
> arch/powerpc/kernel/Makefile | 2 +-
> 2 files changed, 7 insertions(+), 8 deletions(-)
forgot to cc the maintainers
--
Stratos Psomadakis
<psomas@ece.ntua.gr>
^ 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