Re: [PATCH] Stop pci_set_dma_mask() from failing when RAM doesn't exceed the mask anyway
On Sat, 2009-08-01 at 08:25 +1000, Benjamin Herrenschmidt wrote: On Fri, 2009-07-31 at 20:41 +0100, David Woodhouse wrote: On an iMac G5, the b43 driver is failing to initialise because trying to set the dma mask to 30-bit fails. Even though there's only 512MiB of RAM in the machine anyway: https://bugzilla.redhat.com/show_bug.cgi?id=514787 We should probably let it succeed if the available RAM in the system doesn't exceed the requested limit. Signed-off-by: David Woodhouse david.woodho...@intel.com Also, isn't our iommu code smart enough to clamp allocations to the DMA mask nowadays ? In that case, we could probably just force iommu on always... We're not using the IOMMU on this box: PowerMac motherboard: iMac G5 DART: table not allocated, using direct DMA -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Stop pci_set_dma_mask() from failing when RAM doesn't exceed the mask anyway
On Sat, 2009-08-01 at 08:54 +0100, David Woodhouse wrote: On Sat, 2009-08-01 at 08:25 +1000, Benjamin Herrenschmidt wrote: On Fri, 2009-07-31 at 20:41 +0100, David Woodhouse wrote: On an iMac G5, the b43 driver is failing to initialise because trying to set the dma mask to 30-bit fails. Even though there's only 512MiB of RAM in the machine anyway: https://bugzilla.redhat.com/show_bug.cgi?id=514787 We should probably let it succeed if the available RAM in the system doesn't exceed the requested limit. Signed-off-by: David Woodhouse david.woodho...@intel.com Also, isn't our iommu code smart enough to clamp allocations to the DMA mask nowadays ? In that case, we could probably just force iommu on always... We're not using the IOMMU on this box: PowerMac motherboard: iMac G5 DART: table not allocated, using direct DMA I know, I was suggesting we do :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/10] arch/powerpc/sysdev/qe_lib: introduce missing kfree
From: Julia Lawall ju...@diku.dk
Error handling code following a kzalloc should free the allocated data.
The semantic match that finds the problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// smpl
@r exists@
local idexpression x;
statement S;
expression E;
identifier f,f1,l;
position p1,p2;
expression *ptr != NULL;
@@
x...@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
...
if (x == NULL) S
... when != x
when != if (...) { +...x...+ }
(
x-f1 = E
|
(x-f1 == NULL || ...)
|
f(...,x-f1,...)
)
...
(
return \(0\|+...x...+\|ptr\);
|
ret...@p2 ...;
)
@script:python@
p1 r.p1;
p2 r.p2;
@@
print * file: %s kmalloc %s return %s % (p1[0].file,p1[0].line,p2[0].line)
// /smpl
Signed-off-by: Julia Lawall ju...@diku.dk
---
arch/powerpc/sysdev/qe_lib/qe_ic.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe_ic.c
b/arch/powerpc/sysdev/qe_lib/qe_ic.c
index 074905c..3faa42e 100644
--- a/arch/powerpc/sysdev/qe_lib/qe_ic.c
+++ b/arch/powerpc/sysdev/qe_lib/qe_ic.c
@@ -339,8 +339,10 @@ void __init qe_ic_init(struct device_node *node, unsigned
int flags,
qe_ic-irqhost = irq_alloc_host(node, IRQ_HOST_MAP_LINEAR,
NR_QE_IC_INTS, qe_ic_host_ops, 0);
- if (qe_ic-irqhost == NULL)
+ if (qe_ic-irqhost == NULL) {
+ kfree(qe_ic);
return;
+ }
qe_ic-regs = ioremap(res.start, res.end - res.start + 1);
@@ -352,6 +354,7 @@ void __init qe_ic_init(struct device_node *node, unsigned
int flags,
if (qe_ic-virq_low == NO_IRQ) {
printk(KERN_ERR Failed to map QE_IC low IRQ\n);
+ kfree(qe_ic);
return;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/10] arch/powerpc: introduce missing kfree
From: Julia Lawall ju...@diku.dk
Error handling code following a kzalloc should free the allocated data.
The semantic match that finds the problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// smpl
@r exists@
local idexpression x;
statement S;
expression E;
identifier f,f1,l;
position p1,p2;
expression *ptr != NULL;
@@
x...@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
...
if (x == NULL) S
... when != x
when != if (...) { +...x...+ }
(
x-f1 = E
|
(x-f1 == NULL || ...)
|
f(...,x-f1,...)
)
...
(
return \(0\|+...x...+\|ptr\);
|
ret...@p2 ...;
)
@script:python@
p1 r.p1;
p2 r.p2;
@@
print * file: %s kmalloc %s return %s % (p1[0].file,p1[0].line,p2[0].line)
// /smpl
Signed-off-by: Julia Lawall ju...@diku.dk
---
arch/powerpc/sysdev/ipic.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/ipic.c b/arch/powerpc/sysdev/ipic.c
index 69e2630..040144e 100644
--- a/arch/powerpc/sysdev/ipic.c
+++ b/arch/powerpc/sysdev/ipic.c
@@ -735,8 +735,10 @@ struct ipic * __init ipic_init(struct device_node *node,
unsigned int flags)
ipic-irqhost = irq_alloc_host(node, IRQ_HOST_MAP_LINEAR,
NR_IPIC_INTS,
ipic_host_ops, 0);
- if (ipic-irqhost == NULL)
+ if (ipic-irqhost == NULL) {
+ kfree(ipic);
return NULL;
+ }
ipic-regs = ioremap(res.start, res.end - res.start + 1);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Stop pci_set_dma_mask() from failing when RAM doesn't exceed the mask anyway
On Sat, 2009-08-01 at 18:00 +1000, Benjamin Herrenschmidt wrote: On Sat, 2009-08-01 at 08:54 +0100, David Woodhouse wrote: On Sat, 2009-08-01 at 08:25 +1000, Benjamin Herrenschmidt wrote: On Fri, 2009-07-31 at 20:41 +0100, David Woodhouse wrote: On an iMac G5, the b43 driver is failing to initialise because trying to set the dma mask to 30-bit fails. Even though there's only 512MiB of RAM in the machine anyway: https://bugzilla.redhat.com/show_bug.cgi?id=514787 We should probably let it succeed if the available RAM in the system doesn't exceed the requested limit. Signed-off-by: David Woodhouse david.woodho...@intel.com Also, isn't our iommu code smart enough to clamp allocations to the DMA mask nowadays ? In that case, we could probably just force iommu on always... We're not using the IOMMU on this box: PowerMac motherboard: iMac G5 DART: table not allocated, using direct DMA I know, I was suggesting we do :-) I'm not sure. Losing 16MiB on a machine which only has 512MiB anyway doesn't seem ideal, and we'll want to make the no-iommu code DTRT _anyway_, surely? So we might as well let the DART keep its existing logic (which is only to bother if we have more than 1GiB of RAM; a limit chosen specifically because of the Broadcom brokenness). -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/10] arch/powerpc/sysdev/qe_lib: introduce missing kfree
On Sat, Aug 1, 2009 at 3:52 AM, Julia Lawallju...@diku.dk wrote: From: Julia Lawall ju...@diku.dk Error handling code following a kzalloc should free the allocated data. ... Signed-off-by: Julia Lawall ju...@diku.dk --- arch/powerpc/sysdev/qe_lib/qe_ic.c | 5 - 1 files changed, 4 insertions(+), 1 deletions(-) Acked-by: Timur Tabi ti...@freescale.com -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] Fix perfctr oops on ppc32
This seems to be the reason why the Fedora rawhide 2.6.31-rc kernel
doesn't boot. With some CPUs, cur_cpu_spec-oprofile_cpu_type can be
NULL -- which makes strcmp() unhappy.
Signed-off-by: David Woodhouse david.woodho...@intel.com
---
At first glance, it looks like there are a bunch of other places which
use cur_cpu_spec-oprofile_cpu_type without first checking if it's
non-NULL, but maybe those are all 64-bit and all 64-bit cpu types have
it set?
diff --git a/arch/powerpc/kernel/mpc7450-pmu.c
b/arch/powerpc/kernel/mpc7450-pmu.c
index 75ff47f..ea383c1 100644
--- a/arch/powerpc/kernel/mpc7450-pmu.c
+++ b/arch/powerpc/kernel/mpc7450-pmu.c
@@ -408,7 +408,8 @@ struct power_pmu mpc7450_pmu = {
static int init_mpc7450_pmu(void)
{
- if (strcmp(cur_cpu_spec-oprofile_cpu_type, ppc/7450))
+ if (cur_cpu_spec-oprofile_cpu_type
+ strcmp(cur_cpu_spec-oprofile_cpu_type, ppc/7450))
return -ENODEV;
return register_power_pmu(mpc7450_pmu);
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] Support for PCI Express reset type
Hi Andi, 2009/7/31 Andi Kleen a...@firstfloor.org: Mike Mason mm...@us.ibm.com writes: These patches supersede the previously submitted patch that implemented a fundamental reset bit field. Please review and let me know of any concerns. Any plans to implement that for x86 too? Right now it seems to be a PPC specific hack. I've found the PCIE chipsepc somewhat daunting, but was under the impression that much if not most of what was needed was specified there. See, for example: Documentation/PCI/pcieaer-howto.txt which states: ||| The PCI Express Advanced Error Reporting Driver Guide HOWTO |||T. Long Nguyen tom.l.ngu...@intel.com |||Yanmin Zhangyanmin.zh...@intel.com |||07/29/2006 [..] ||| The PCI Express AER driver provides the infrastructure to support PCI ||| Express Advanced Error Reporting capability. The PCI Express AER ||| driver provides three basic functions: ||| ||| - Gathers the comprehensive error information if errors occurred. ||| - Reports error to the users. ||| - Performs error recovery actions. I presume the last bullet point means that the AER code works and actually does more or less the same thing as the PPC EEH code, but in a more architecture-independent way, as it only assumes that PCI AER is there (and is correctly implemented in the CPI chipset) The AER code uses the same core infrastructure as the EEH code, at the time, I did exchange emails w/ the above authors discussing this stuff. As to whether the x86 server vendors are actually selling something with AER in it, and whether any of them are actually testing this stuff is unclear. FWIW IBM has pretty much no incentive to lobby other server vendors to get on the ball ...as this is viewed as one of those things that lets IBM charge premium prices for PPC hardware. --linas ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] Support for PCI Express reset type
2009/7/30 Mike Mason mm...@us.ibm.com: This is the first of three patches that implement a bit field that PCI Express device drivers can use to indicate they need a fundamental reset during error recovery. By default, the EEH framework on powerpc does what's known as a hot reset during recovery of a PCI Express device. We've found a case where the device needs a fundamental reset to recover properly. The current PCI error recovery and EEH frameworks do not support this distinction. The attached patch (courtesy of Richard Lary) adds a bit field to pci_dev that indicates whether the device requires a fundamental reset during recovery. These patches supersede the previously submitted patch that implemented a fundamental reset bit field. Please review and let me know of any concerns. Signed-off-by: Mike Mason mm...@us.ibm.com Signed-off-by: Richard Lary rl...@us.ibm.com Signed-off-by: Linas Vepstas linasveps...@gmail.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] Support for PCI Express reset type
2009/7/30 Mike Mason mm...@us.ibm.com: This is the second of three patches that implement a bit field that PCI Express device drivers can use to indicate they need a fundamental reset during error recovery. By default, the EEH framework on powerpc does what's known as a hot reset during recovery of a PCI Express device. We've found a case where the device needs a fundamental reset to recover properly. The current PCI error recovery and EEH frameworks do not support this distinction. The attached patch updates the Documentation/PCI/pci-error-recovery.txt file with changes related to this new bit field, as well a few unrelated updates. These patches supersede the previously submitted patch that implemented a fundamental reset bit field. Please review and let me know of any concerns. Signed-off-by: Mike Mason mm...@us.ibm.com Signed-off-by: Richard Lary rl...@us.ibm.com FWIW, Signed-off-by: Linas Vepstas linasveps...@gmail.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] Support for PCI Express reset type
2009/7/30 Mike Mason mm...@us.ibm.com: This is the third of three patches that implement a bit field that PCI Express device drivers can use to indicate they need a fundamental reset during error recovery. By default, the EEH framework on powerpc does what's known as a hot reset during recovery of a PCI Express device. We've found a case where the device needs a fundamental reset to recover properly. The current PCI error recovery and EEH frameworks do not support this distinction. The attached patch makes changes to EEH to utilize the new bit field. These patches supersede the previously submitted patch that implemented a fundamental reset bit field. Please review and let me know of any concerns. Signed-off-by: Mike Mason mm...@us.ibm.com Signed-off-by: Richard Lary rl...@us.ibm.com Signed-off-by: Linas Vepstas linasveps...@gmail.com + /* Determine type of EEH reset required by device, + * default hot reset or fundamental reset + */ + if (dev-needs_freset) + rtas_pci_slot_reset(pdn, 3); + else + rtas_pci_slot_reset(pdn, 1); Gack! I remember deluges of emails and conference calls where the hardware guys went on about this; and I admit I didn't quite get it, which I guess is why this patch is showing up many years late. FWIW some of the variants of the IPR chipset almost surely need the freset bit set. --linas ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re:[PATCH 1/2] powerpc: add kexec support on FSL-Book-E
Hi, Sebastian, From: Sebastian Andrzej Siewior bigeasy at linutronix.de The relocate_new_kernel() code usually disables the MMU and the small code operates on physicall pages while moving the kernel to its final position. Book-E doesn't support this so a 1:1 mapping must be created. This patch adds support for FSL-BOOK-E implementation. Signed-off-by: Sebastian Andrzej Siewior bigeasy at linutronix.de + xorir6,r4,1 /* Setup TMP mapping in the other Address space */ + slwir6,r6,12 + orisr6,r6,(MAS1_VALID|MAS1_IPROT)@h + ori r6,r6,(MAS1_TSIZE(BOOKE_PAGESZ_1GB))@l + mtspr SPRN_MAS1,r6 . + /* find our address */ + addir7, r30, final_copy_code - relocate_new_kernel + + mtspr SPRN_SRR0,r7 + mtspr SPRN_SRR1,r6 + rfi In your patch of Booke support for kexec , it setup a 1GB TMP mapping and jump to it. But I saw that, the max size for an e500 entry is 256M，so I changed your code to setup 4*256M entries, and it works well on mpc8541. Howerver,it didn't work on mpc8548(e500 v2) and P2020ds(SMP,e500 v2) , and 'rfi' to final_copy_code failed.(I also setup a 1:1 mapping for serial ,so I can trap the flowchart in relocate_new_kernel) Any suggestions about this ? Thank you very much. regards, wilbur ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
