Re: [PATCH v2 7/7] ARM: mxc: remove esdhc.h and use the public one
Hello Shawn, On Thu, May 05, 2011 at 09:22:58PM +0800, Shawn Guo wrote: > Signed-off-by: Shawn Guo > --- > .../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/ | ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[tip:perf/urgent] hw_breakpoints, powerpc: Fix CONFIG_HAVE_HW_BREAKPOINT off-case in ptrace_set_debugreg()
Commit-ID: 925f83c085e1bb08435556c5b4844a60de002e31
Gitweb: http://git.kernel.org/tip/925f83c085e1bb08435556c5b4844a60de002e31
Author: Frederic Weisbecker
AuthorDate: Fri, 6 May 2011 01:53:18 +0200
Committer: Ingo Molnar
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
Signed-off-by: Frederic Weisbecker
Cc: LPPC
Cc: Prasad
Cc: v2.6.33..
Link:
http://lkml.kernel.org/r/1304639598-4707-1-git-send-email-fweis...@gmail.com
Signed-off-by: Ingo Molnar
---
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC v2] virtio: add virtio-over-PCI driver
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.
Thanks,
Prabhakar
-Original Message-
From: linux-kernel-ow...@vger.kernel.org
[mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Ira Snyder
Sent: Friday, 27 February, 2009 3:19 AM
To: Arnd Bergmann
Cc: linux-ker...@vger.kernel.org; Rusty Russell; Jan-Bernd Themann;
linuxppc-...@ozlabs.org; net...@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 0x8000-0xc000
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
Re: [RFC v2] virtio: add virtio-over-PCI driver
On Fri, May 06, 2011 at 12:00:34PM +, 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-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Ira Snyder
> Sent: Friday, 27 February, 2009 3:19 AM
> To: Arnd Bergmann
> Cc: linux-ker...@vger.kernel.org; Rusty Russell; Jan-Bernd Themann;
> linuxppc-...@ozlabs.org; net...@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
> > yo
Re: [PATCH 2/2] powerpc: add support for MPIC message register API
On Thu, 5 May 2011 16:41:29 -0500
Meador Inge 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 n
[PATCH] powerpc: fix kexec with dynamic dma windows
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
Cc: Milton Miller
Cc: Paul Mackerras
Cc: Anton Blanchard
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: add support for MPIC message register API
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
ibm_newemac driver hangs while using 10Mbps full-duplex
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 CR: 2424 XER: 2000 TASK = c037f440[0] 'swapper' THREAD: c03a8000 GPR00: c02094a4 c03a9db0 c037f440 003f 2631 c0175a5c 0036 GPR08: c03b1d40 c038 2631 4000 2482 feef 0ffed700 0080 GPR16: 007fff00 c038138c c03b c030 c03b 000a c03a9e18 GPR24: c038 c03a8000 c03b5ec8 c03b c038 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 4b78 38810008 7fe3fb78 38a00040 4bfebc4d 7c651b78 3c60c033 7fc6f378 7fe4fb78 3863e668 4be1a415 <0fe0> 3801 901cfa00 4b14 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] lib: Consolidate DEBUG_STACK_USAGE option
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-a...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: uclinux-dist-de...@blackfin.uclinux.org Cc: linux-m...@ml.linux-m32r.org Cc: linux-m...@linux-mips.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux...@vger.kernel.org Cc: sparcli...@vger.kernel.org Cc: Chris Metcalf Cc: user-mode-linux-de...@lists.sourceforge.net Cc: x...@kernel.org Signed-off-by: Stephen Boyd --- 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
RE: [RFC v2] virtio: add virtio-over-PCI driver
Thanks Ira for your kind reply.
I will look for the mentioned pointers :)
Prabhakar
> -Original Message-
> From: Ira W. Snyder [mailto:i...@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-ker...@vger.kernel.org;
> linuxppc-...@ozlabs.org; net...@vger.kernel.org
> Subject: Re: [RFC v2] virtio: add virtio-over-PCI driver
>
> On Fri, May 06, 2011 at 12:00:34PM +, 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-ow...@vger.kernel.org
> > [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Ira Snyder
> > Sent: Friday, 27 February, 2009 3:19 AM
> > To: Arnd Bergmann
> > Cc: linux-ker...@vger.kernel.org; Rusty Russell; Jan-Bernd Themann;
> > linuxppc-...@ozlabs.org; net...@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;
> > > };
> >
