* [PATCH] powerpc: Fix CHRP platforms with only 8259
From: Benjamin Herrenschmidt @ 2006-10-25 2:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
On CHRP platforms with only a 8259 controller, we should set the
default IRQ host to the 8259 driver's one for the IRQ probing
fallbacks to work in case the IRQ tree is incorrect (like on
Pegasos for example). Without this fix, we get a bunch of WARN_ON's
during boot.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-cell/arch/powerpc/platforms/chrp/setup.c
===================================================================
--- linux-cell.orig/arch/powerpc/platforms/chrp/setup.c 2006-10-09 12:03:33.000000000 +1000
+++ linux-cell/arch/powerpc/platforms/chrp/setup.c 2006-10-25 12:51:18.000000000 +1000
@@ -477,8 +477,10 @@ static void __init chrp_find_8259(void)
" address, polling\n");
i8259_init(pic, chrp_int_ack);
- if (ppc_md.get_irq == NULL)
+ if (ppc_md.get_irq == NULL) {
ppc_md.get_irq = i8259_irq;
+ irq_set_default_host(i8259_get_host());
+ }
if (chrp_mpic != NULL) {
cascade_irq = irq_of_parse_and_map(pic, 0);
if (cascade_irq == NO_IRQ)
Index: linux-cell/arch/powerpc/sysdev/i8259.c
===================================================================
--- linux-cell.orig/arch/powerpc/sysdev/i8259.c 2006-10-09 12:03:33.000000000 +1000
+++ linux-cell/arch/powerpc/sysdev/i8259.c 2006-10-25 12:51:58.000000000 +1000
@@ -13,6 +13,7 @@
#include <linux/interrupt.h>
#include <linux/kernel.h>
#include <linux/delay.h>
+#include <linux/module.h>
#include <asm/io.h>
#include <asm/i8259.h>
#include <asm/prom.h>
@@ -224,6 +225,11 @@ static struct irq_host_ops i8259_host_op
.xlate = i8259_host_xlate,
};
+struct irq_host *i8259_get_host(void)
+{
+ return i8259_host;
+}
+
/**
* i8259_init - Initialize the legacy controller
* @node: device node of the legacy PIC (can be NULL, but then, it will match
Index: linux-cell/include/asm-powerpc/i8259.h
===================================================================
--- linux-cell.orig/include/asm-powerpc/i8259.h 2006-10-09 12:03:34.000000000 +1000
+++ linux-cell/include/asm-powerpc/i8259.h 2006-10-25 12:51:18.000000000 +1000
@@ -7,6 +7,7 @@
#ifdef CONFIG_PPC_MERGE
extern void i8259_init(struct device_node *node, unsigned long intack_addr);
extern unsigned int i8259_irq(void);
+extern struct irq_host *i8259_get_host(void);
#else
extern void i8259_init(unsigned long intack_addr, int offset);
extern int i8259_irq(void);
^ permalink raw reply
* Re: [PATCH] powerpc: Fix CHRP platforms with only 8259
From: Michael Ellerman @ 2006-10-25 3:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <1161744878.22582.5.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1970 bytes --]
On Wed, 2006-10-25 at 12:54 +1000, Benjamin Herrenschmidt wrote:
> On CHRP platforms with only a 8259 controller, we should set the
> default IRQ host to the 8259 driver's one for the IRQ probing
> fallbacks to work in case the IRQ tree is incorrect (like on
> Pegasos for example). Without this fix, we get a bunch of WARN_ON's
> during boot.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
>
> Index: linux-cell/arch/powerpc/platforms/chrp/setup.c
> ===================================================================
> --- linux-cell.orig/arch/powerpc/platforms/chrp/setup.c 2006-10-09 12:03:33.000000000 +1000
> +++ linux-cell/arch/powerpc/platforms/chrp/setup.c 2006-10-25 12:51:18.000000000 +1000
> @@ -477,8 +477,10 @@ static void __init chrp_find_8259(void)
> " address, polling\n");
>
> i8259_init(pic, chrp_int_ack);
> - if (ppc_md.get_irq == NULL)
> + if (ppc_md.get_irq == NULL) {
> ppc_md.get_irq = i8259_irq;
> + irq_set_default_host(i8259_get_host());
> + }
> if (chrp_mpic != NULL) {
> cascade_irq = irq_of_parse_and_map(pic, 0);
> if (cascade_irq == NO_IRQ)
> Index: linux-cell/arch/powerpc/sysdev/i8259.c
> ===================================================================
> --- linux-cell.orig/arch/powerpc/sysdev/i8259.c 2006-10-09 12:03:33.000000000 +1000
> +++ linux-cell/arch/powerpc/sysdev/i8259.c 2006-10-25 12:51:58.000000000 +1000
> @@ -13,6 +13,7 @@
> #include <linux/interrupt.h>
> #include <linux/kernel.h>
> #include <linux/delay.h>
> +#include <linux/module.h>
> #include <asm/io.h>
> #include <asm/i8259.h>
> #include <asm/prom.h>
You don't need module.h anymore do you ? :D
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Fix CHRP platforms with only 8259
From: Benjamin Herrenschmidt @ 2006-10-25 3:21 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <1161745918.3800.16.camel@localhost.localdomain>
> You don't need module.h anymore do you ? :D
Bloody you ! :)
New patch on the way.
Ben.
^ permalink raw reply
* [PATCH] powerpc: Fix CHRP platforms with only 8259
From: Benjamin Herrenschmidt @ 2006-10-25 3:22 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
On CHRP platforms with only a 8259 controller, we should set the
default IRQ host to the 8259 driver's one for the IRQ probing
fallbacks to work in case the IRQ tree is incorrect (like on
Pegasos for example). Without this fix, we get a bunch of WARN_ON's
during boot.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
This one without the spurrious #include. Please apply to 2.6.19
Index: linux-cell/arch/powerpc/platforms/chrp/setup.c
===================================================================
--- linux-cell.orig/arch/powerpc/platforms/chrp/setup.c 2006-10-09 12:03:33.000000000 +1000
+++ linux-cell/arch/powerpc/platforms/chrp/setup.c 2006-10-25 12:51:18.000000000 +1000
@@ -477,8 +477,10 @@ static void __init chrp_find_8259(void)
" address, polling\n");
i8259_init(pic, chrp_int_ack);
- if (ppc_md.get_irq == NULL)
+ if (ppc_md.get_irq == NULL) {
ppc_md.get_irq = i8259_irq;
+ irq_set_default_host(i8259_get_host());
+ }
if (chrp_mpic != NULL) {
cascade_irq = irq_of_parse_and_map(pic, 0);
if (cascade_irq == NO_IRQ)
Index: linux-cell/arch/powerpc/sysdev/i8259.c
===================================================================
--- linux-cell.orig/arch/powerpc/sysdev/i8259.c 2006-10-09 12:03:33.000000000 +1000
+++ linux-cell/arch/powerpc/sysdev/i8259.c 2006-10-25 13:19:33.000000000 +1000
@@ -224,6 +224,11 @@ static struct irq_host_ops i8259_host_op
.xlate = i8259_host_xlate,
};
+struct irq_host *i8259_get_host(void)
+{
+ return i8259_host;
+}
+
/**
* i8259_init - Initialize the legacy controller
* @node: device node of the legacy PIC (can be NULL, but then, it will match
Index: linux-cell/include/asm-powerpc/i8259.h
===================================================================
--- linux-cell.orig/include/asm-powerpc/i8259.h 2006-10-09 12:03:34.000000000 +1000
+++ linux-cell/include/asm-powerpc/i8259.h 2006-10-25 12:51:18.000000000 +1000
@@ -7,6 +7,7 @@
#ifdef CONFIG_PPC_MERGE
extern void i8259_init(struct device_node *node, unsigned long intack_addr);
extern unsigned int i8259_irq(void);
+extern struct irq_host *i8259_get_host(void);
#else
extern void i8259_init(unsigned long intack_addr, int offset);
extern int i8259_irq(void);
^ permalink raw reply
* RE: [PATCH] qe_ic: Do a sync when masking interrupts.
From: Benjamin Herrenschmidt @ 2006-10-25 3:51 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <4879B0C6C249214CBE7AB04453F84E4D2071C2@zch01exm20.fsl.freescale.net>
On Tue, 2006-10-24 at 15:17 +0800, Li Yang-r58472 wrote:
> > -----Original Message-----
> > From: Scott Wood [mailto:scottwood@freescale.com]
> > Sent: Tuesday, October 24, 2006 2:27 AM
> > To: Segher Boessenkool
> > Cc: mrz5149@acm.org; Li Yang-r58472; Paul Mackerras;
> linuxppc-dev@ozlabs.org
> > Subject: Re: [PATCH] qe_ic: Do a sync when masking interrupts.
> >
> > Segher Boessenkool wrote:
> > > If a sync after an MMIO write is enough, then (in almost all
> > > cases) so is an eieio.
> >
> > In this case, the spurious interrupts still happen with eieio, but not
> > with sync.
>
> eieio on e300 core is just a no-op.
It's not sent to the bus on non-cahed storage (like the PCI bridge ?)
That's pretty bad ... there is quite a bit of code that assumes that
eieio's will prevent write combining...
Ben.
^ permalink raw reply
* MPC8343: PCI resource allocation questions
From: Luong Ngo @ 2006-10-25 3:49 UTC (permalink / raw)
To: linuxppc-dev list
[-- Attachment #1: Type: text/plain, Size: 1923 bytes --]
Hello,
I am trying to bring up linux kernel 2.6.14 on a system using MPC 8343E and
am having issues with the PCI resource allocation in the kernel. I saw these
messages:
.............
PCI: Cannot allocate resource region 0 of device 0000:00:00.0
PCI: Cannot allocate resource region 2 of device 0000:00:00.0
PCI: Failed to allocate mem resource #2:80000000@0 for 0000:00:00.0
After digging into the codes, I realize that the PCI subsystem scan the bus
and reading the BARs in the CPU PCI controller, which give the region 1 from
0x0 to 0x000FFFFF and region 2 from 0x0 to 0x7FFFFFFF. And the values I
assign to the bridge resource in calling pci_init_resource during setup hose
is 0x80000000 - 0x9FFFFFFF (I got this values from the mpc834x_sys.h). So I
just extend the bridge resource to 0x70000000 - 0xFFFFFFFF to cover all 2
regions in the 2 BAR and this seems to get rid of the above messages.
However this would cause other platform devices to fail to claim its
resources,
fsl-gianfar.1: failed to claim resource 0
unable to register device 0
fsl-gianfar.2: failed to claim resource 0
unable to register device 1
fsl-i2c.1: failed to claim resource 0
unable to register device 2
Could anyone tell me how these PCI resource work and how to resolve this
conflict?
And my other questions are why is the region 2 in the mpc8343E such huge
and what is it used for?
Also Why the kernel looks into the CPU PCI controller? because as I
understand, in the hose setup step in platform initialization, the host
bridge is skipped while other PCI devices would be probed and have their
BARs assigned the address range to use ( in function pciauto_bus_scan in
arch/ppc/syslib/pci_auto.c )
One more question, are these BARs in the PCI controller related with the PCI
inbound and outbound mapping of the PCI interface? Do the regions in BAR
need to match/derive from the inbound/outbound address mapping?
Thank you,
Luong Ngo
[-- Attachment #2: Type: text/html, Size: 2016 bytes --]
^ permalink raw reply
* [PATCH] powerpc: Remove ibmveth "liobn" field
From: Benjamin Herrenschmidt @ 2006-10-25 4:17 UTC (permalink / raw)
To: Santiago Leon; +Cc: linuxppc-dev list, Paul Mackerras
Remove the now unused "liobn" field in ibmveth which also avoids
having insider knowledge of the iommu table in that driver.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
This will avoid this driver from breaking when I change the dma
mapping code for 2.6.20.
Index: linux-cell/drivers/net/ibmveth.c
===================================================================
--- linux-cell.orig/drivers/net/ibmveth.c 2006-10-23 14:41:38.000000000 +1000
+++ linux-cell/drivers/net/ibmveth.c 2006-10-25 14:12:05.000000000 +1000
@@ -50,7 +50,6 @@
#include <asm/semaphore.h>
#include <asm/hvcall.h>
#include <asm/atomic.h>
-#include <asm/iommu.h>
#include <asm/vio.h>
#include <asm/uaccess.h>
#include <linux/seq_file.h>
@@ -1000,8 +999,6 @@ static int __devinit ibmveth_probe(struc
adapter->mac_addr = 0;
memcpy(&adapter->mac_addr, mac_addr_p, 6);
- adapter->liobn = dev->iommu_table->it_index;
-
netdev->irq = dev->irq;
netdev->open = ibmveth_open;
netdev->poll = ibmveth_poll;
@@ -1115,7 +1112,6 @@ static int ibmveth_seq_show(struct seq_f
seq_printf(seq, "%s %s\n\n", ibmveth_driver_string, ibmveth_driver_version);
seq_printf(seq, "Unit Address: 0x%x\n", adapter->vdev->unit_address);
- seq_printf(seq, "LIOBN: 0x%lx\n", adapter->liobn);
seq_printf(seq, "Current MAC: %02X:%02X:%02X:%02X:%02X:%02X\n",
current_mac[0], current_mac[1], current_mac[2],
current_mac[3], current_mac[4], current_mac[5]);
Index: linux-cell/drivers/net/ibmveth.h
===================================================================
--- linux-cell.orig/drivers/net/ibmveth.h 2006-10-06 13:48:09.000000000 +1000
+++ linux-cell/drivers/net/ibmveth.h 2006-10-25 14:10:39.000000000 +1000
@@ -118,7 +118,6 @@ struct ibmveth_adapter {
struct net_device_stats stats;
unsigned int mcastFilterSize;
unsigned long mac_addr;
- unsigned long liobn;
void * buffer_list_addr;
void * filter_list_addr;
dma_addr_t buffer_list_dma;
^ permalink raw reply
* Re: MPC8343: PCI resource allocation questions
From: Kumar Gala @ 2006-10-25 4:35 UTC (permalink / raw)
To: Luong Ngo; +Cc: linuxppc-dev list
In-Reply-To: <1b2aacd80610242049j23917f61x1e277b4c6a581f9a@mail.gmail.com>
On Oct 24, 2006, at 10:49 PM, Luong Ngo wrote:
> Hello,
> I am trying to bring up linux kernel 2.6.14 on a system using MPC
> 8343E and am having issues with the PCI resource allocation in the
> kernel. I saw these messages:
> .............
> PCI: Cannot allocate resource region 0 of device 0000:00: 00.0
> PCI: Cannot allocate resource region 2 of device 0000:00:00.0
> PCI: Failed to allocate mem resource #2:80000000@0 for 0000:00:00.0
You can ignore these, they can usually be handled by adding a
pci_exclude call back to ignore the host controller itself.
something like:
int mpc83xx_exclude_device(u_char bus, u_char devfn)
{
if (bus == 0 && PCI_SLOT(devfn) == 0)
return PCIBIOS_DEVICE_NOT_FOUND;
return PCIBIOS_SUCCESSFUL;
}
> After digging into the codes, I realize that the PCI subsystem scan
> the bus and reading the BARs in the CPU PCI controller, which give
> the region 1 from 0x0 to 0x000FFFFF and region 2 from 0x0 to
> 0x7FFFFFFF. And the values I assign to the bridge resource in
> calling pci_init_resource during setup hose is 0x80000000 -
> 0x9FFFFFFF (I got this values from the mpc834x_sys.h). So I just
> extend the bridge resource to 0x70000000 - 0xFFFFFFFF to cover all
> 2 regions in the 2 BAR and this seems to get rid of the above
> messages. However this would cause other platform devices to fail
> to claim its resources,
>
> fsl-gianfar.1: failed to claim resource 0
> unable to register device 0
> fsl-gianfar.2: failed to claim resource 0
> unable to register device 1
> fsl-i2c.1: failed to claim resource 0
> unable to register device 2
You are not leaving any memory space for any of the onchip devices,
the error messages are because the regions of memory that the devices
are expected to be at are already occupied by the PCI space.
> Could anyone tell me how these PCI resource work and how to resolve
> this conflict?
The PCI resources are used for any PCI devices that need memory
mapped space allocated to them. What devices are you connecting over
PCI?
> And my other questions are why is the region 2 in the mpc8343E
> such huge and what is it used for?
The region was large since the reference board has general purpose
PCI slots for any number of various cards. We provide a large space
to allow for those cards to be allocated into. Depending on your
application you can adjust this as you need.
> Also Why the kernel looks into the CPU PCI controller? because as I
> understand, in the hose setup step in platform initialization, the
> host bridge is skipped while other PCI devices would be probed and
> have their BARs assigned the address range to use ( in function
> pciauto_bus_scan in arch/ppc/syslib/pci_auto.c )
This is because when the kernel code scan's for devices the host
bridge responses as a device. You can use the exclude function as a
way to override the scanning code and have it ignore the host bridge.
> One more question, are these BARs in the PCI controller related
> with the PCI inbound and outbound mapping of the PCI interface? Do
> the regions in BAR need to match/derive from the inbound/outbound
> address mapping?
Yes, but you should only need to setup the inbound/outbound address
mapping registers. The actually PCI BARs are only important if you
are using the MPC8343 as a PCI agent, it sounds like you are using it
as a host.
- kumar
^ permalink raw reply
* RE: [PATCH] qe_ic: Do a sync when masking interrupts.
From: Liu Dave-r63238 @ 2006-10-25 4:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Li Yang-r58472; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1161748274.22582.30.camel@localhost.localdomain>
> > > Segher Boessenkool wrote:
> > > > If a sync after an MMIO write is enough, then (in almost all
> > > > cases) so is an eieio.
> > >=20
> > > In this case, the spurious interrupts still happen with=20
> eieio, but=20
> > > not with sync.
> >=20
> > eieio on e300 core is just a no-op.
>=20
> It's not sent to the bus on non-cahed storage (like the PCI=20
> bridge ?) That's pretty bad ... there is quite a bit of code=20
> that assumes that eieio's will prevent write combining...
Due to the LSU, the e300 cored doesn't reorder non-cached
stroage, and doesn't implementation of write commbining.
So, actually its behavior likes eieio.
-Dave
^ permalink raw reply
* MPC7448_HPC2 question
From: Benjamin Herrenschmidt @ 2006-10-25 5:20 UTC (permalink / raw)
To: Roy Zang; +Cc: linuxppc-dev list
Any reason why that:
void mpc7448_hpc2_fixup_irq(struct pci_dev *dev)
{
struct pci_controller *hose;
struct device_node *node;
const unsigned int *interrupt;
int busnr;
int len;
u8 slot;
u8 pin;
/* Lookup the hose */
busnr = dev->bus->number;
hose = pci_bus_to_hose(busnr);
if (!hose)
printk(KERN_ERR "No pci hose found\n");
/* Check it has an OF node associated */
node = (struct device_node *) hose->arch_data;
if (!node)
printk(KERN_ERR "No pci node found\n");
interrupt = get_property(node, "interrupt-map", &len);
slot = find_slot_by_devfn(interrupt, dev->devfn);
pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin);
if (pin == 0 || pin > 4)
pin = 1;
pin--;
dev->irq = interrupt[slot*4*7 + pin*7 + 5];
DBG("TSI_PCI: dev->irq = 0x%x\n", dev->irq);
}
Cannot be replaced by:
pci_read_irq_line(dev);
I'm about to make pci_read_irq_line() called by default by the PCI
code (with a new ppc_md.pci_irq_fixup for platforms that really need
something else done) and so while "fixing" all platforms, I stumbled
accross the code above which is a bit shocking :)
Cheers,
Ben.
^ permalink raw reply
* [PATCH] Fix eHCA driver compilation for uniprocessor
From: Paul Mackerras @ 2006-10-25 5:28 UTC (permalink / raw)
To: raisch, schickhj, rdreier; +Cc: linuxppc-dev
The eHCA driver does not compile for a uniprocessor configuration
(CONFIG_SMP=n), due to H_SUCCESS and other symbols being undefined.
This fixes it.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff --git a/drivers/infiniband/hw/ehca/ehca_tools.h b/drivers/infiniband/hw/ehca/ehca_tools.h
index 809da3e..973c4b5 100644
--- a/drivers/infiniband/hw/ehca/ehca_tools.h
+++ b/drivers/infiniband/hw/ehca/ehca_tools.h
@@ -63,6 +63,7 @@ #include <asm/abs_addr.h>
#include <asm/ibmebus.h>
#include <asm/io.h>
#include <asm/pgtable.h>
+#include <asm/hvcall.h>
extern int ehca_debug_level;
^ permalink raw reply related
* Re: MPC7448_HPC2 question
From: Zang Roy-r61911 @ 2006-10-25 5:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1161753605.22582.42.camel@localhost.localdomain>
On Wed, 2006-10-25 at 13:20, Benjamin Herrenschmidt wrote:
> Any reason why that:
>
> void mpc7448_hpc2_fixup_irq(struct pci_dev *dev)
> {
> struct pci_controller *hose;
> struct device_node *node;
> const unsigned int *interrupt;
> int busnr;
> int len;
> u8 slot;
> u8 pin;
>
> /* Lookup the hose */
> busnr = dev->bus->number;
> hose = pci_bus_to_hose(busnr);
> if (!hose)
> printk(KERN_ERR "No pci hose found\n");
>
> /* Check it has an OF node associated */
> node = (struct device_node *) hose->arch_data;
> if (!node)
> printk(KERN_ERR "No pci node found\n");
>
> interrupt = get_property(node, "interrupt-map", &len);
> slot = find_slot_by_devfn(interrupt, dev->devfn);
> pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin);
> if (pin == 0 || pin > 4)
> pin = 1;
> pin--;
> dev->irq = interrupt[slot*4*7 + pin*7 + 5];
> DBG("TSI_PCI: dev->irq = 0x%x\n", dev->irq);
> }
>
> Cannot be replaced by:
>
> pci_read_irq_line(dev);
>
> I'm about to make pci_read_irq_line() called by default by the PCI
> code (with a new ppc_md.pci_irq_fixup for platforms that really need
> something else done) and so while "fixing" all platforms, I stumbled
> accross the code above which is a bit shocking :)
>
> Cheers,
>
> Ben.
>
>
>
Ben,
Last week, I had tried to do the replacement. While, it did not work. I
had though some update of pci_read_irq_line() should be needed.
Any way, I will investigate it and give the patch ASAP :-).
Roy
^ permalink raw reply
* Re: Crash with highmem support enabled
From: Paul Mackerras @ 2006-10-25 5:34 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20061023185714.22630@gmx.net>
Gerhard Pircher writes:
> I guess this has something to do with the IO block mapping, which is
> implemented in the amigaone_setup.c file and looks like this:
Why on earth are you still using io_block_mapping?
Paul.
^ permalink raw reply
* Re: [PATCH] IPIC: Don't call set_irq_handler with desc->lock held.
From: Kumar Gala @ 2006-10-25 5:41 UTC (permalink / raw)
To: tglx, Ingo Molnar
Cc: linuxppc-dev list, linux-kernel@vger.kernel.org mailing list
In-Reply-To: <20061023163522.GA15901@ld0162-tx32.am.freescale.net>
On Oct 23, 2006, at 11:35 AM, Scott Wood wrote:
> This patch causes ipic_set_irq_type to set the handler directly rather
> than call set_irq_handler, which causes spinlock recursion because
> the lock is already held when ipic_set_irq_type is called.
>
> I'm also not convinced that ipic_set_irq_type should be changing the
> handler at all. There seem to be several controllers that don't and
> several that do. Those that do would break what appears to be a
> common
> usage of calling set_irq_chip_and_handler followed by set_irq_type,
> if a
> non-standard handler were to be used. OTOH, irq_create_of_mapping()
> doesn't set the handler, but only calls set_irq_type().
>
> This patch gets things working in the spinlock-debugging-enabled case,
> but I'm curious as to where the handler setting is ideally supposed
> to be
> done. I don't see any documentation on set_irq_type() that clarifies
> what the semantics are supposed to be.
Guys, Scott pointed this problem out on a PPC interrupt controller,
and wanted to raise it in a larger forum since it appears to exist on
at least one ARM interrupt controller I looked at (ixp4xx). What is
the proper solution to handle this.
The callers of set_type() I found all grab desc->lock.
- kumar
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/sysdev/ipic.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/ipic.c b/arch/powerpc/sysdev/ipic.c
> index bc4d4a7..746f78c 100644
> --- a/arch/powerpc/sysdev/ipic.c
> +++ b/arch/powerpc/sysdev/ipic.c
> @@ -473,9 +473,9 @@ static int ipic_set_irq_type(unsigned in
> desc->status |= flow_type & IRQ_TYPE_SENSE_MASK;
> if (flow_type & IRQ_TYPE_LEVEL_LOW) {
> desc->status |= IRQ_LEVEL;
> - set_irq_handler(virq, handle_level_irq);
> + desc->handle_irq = handle_level_irq;
> } else {
> - set_irq_handler(virq, handle_edge_irq);
> + desc->handle_irq = handle_edge_irq;
> }
>
> /* only EXT IRQ senses are programmable on ipic
> --
> 1.4.2.3
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: status of mpc52xx with arch=powerpc?
From: Grant Likely @ 2006-10-25 6:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-embedded
In-Reply-To: <1161740815.22582.1.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 453 bytes --]
On 10/24/06, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> Can you send me your .dts ?
Here you go; for discussion purposes only! :)
This is pretty rough stuff, and it haven't even got to the point of
using it to boot a kernel. But if it's a starting point to figure out
what the 52xx device tree should look like then go to it!
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
[-- Attachment #2: lite5200b.dts --]
[-- Type: application/octet-stream, Size: 5022 bytes --]
/*
* Lite5200b board Device Tree Source
*
* Copyright 2006 Secret Lab Technologies Ltd.
* Grant Likely <grant.likely@secretlab.ca>
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
* Free Software Foundation; either version 2 of the License, or (at your
* option) any later version.
*/
/ {
model = "Lite5200b";
compatible = "mpc52xx";
#address-cells = <1>;
#size-cells = <1>;
cpus {
#cpus = <1>;
#address-cells = <1>;
#size-cells = <0>;
PowerPC,5200@0 {
device_type = "cpu";
reg = <0>;
d-cache-line-size = <20>;
i-cache-line-size = <20>;
d-cache-size = <4000>; // L1, 16K
i-cache-size = <4000>; // L1, 16K
timebase-frequency = <0>; // from bootloader
bus-frequency = <0>; // from bootloader
clock-frequency = <0>; // from bootloader
32-bit;
};
};
memory {
device_type = "memory";
reg = <00000000 10000000>; // 256MB
};
soc5200@f0000000 {
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
device_type = "soc";
ranges = <0 f0000000 f0010000>;
reg = <f0000000 00010000>;
bus-frequency = <0>;
pic@500 {
linux,phandle = <500>;
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <500 80>;
built-in;
device_type = "52xx-pic";
};
gpt@600 { // General Purpose Timers
// Should this be here at all?
// Or should there be one entry per timer (8 total)?
compatible = "5200";
device_type = "gpt";
reg = <600 100>;
interrupts = <0e 2 0f 2 10 2 11 2
12 2 13 2 14 2 14 2>;
interrupt-parent = <500>;
};
rtc@800 { // Real time clock
// Should this be here at all?
compatible = "5200";
device_type = "rtc";
reg = <800 100>;
interrupts = <0a 2 0b 2>;
interrupt-parent = <500>;
};
mscan@900 {
compatible = "5200";
device_type = "mscan";
interrupts = <37 2>;
interrupt-parent = <500>;
reg = <900 80>;
};
mscan@980 {
compatible = "5200";
device_type = "mscan";
interrupts = <38 2>;
interrupt-parent = <500>;
reg = <980 80>;
};
gpio@b00 {
compatible = "5200";
device_type = "gpio";
reg = <b00 100>;
};
gpio_wkup@c00 {
compatible = "5200";
device_type = "gpio-wkup";
reg = <c00 100>;
};
pci@0d00 {
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
compatible = "5200";
device_type = "pci";
// I actually know very little about setting up PCI,
// so anything here would just be pulled out of my
// butt. Instead I'll leave these placeholders until
// I figure out what it should be
//
// interrupt-map-mask = <>;
// interrupt-map = <>;
// bus-range = <>;
// ranges = <>;
//
clock-frequency = <3f940aa>;
interrupts = <2f 2 30 2 31 2>;
interrupt-parent = <500>;
};
spi@f00 {
device_type = "spi";
compatible = "5200";
reg = <f00 20>;
interrupts = <34 2 35 2>;
interrupt-parent = <500>;
};
serial@2000 { // PSC1
device_type = "serial";
compatible = "5200-psc";
reg = <2000 100>;
clock-frequency = <0>;
interrupts = <28 2>;
interrupt-parent = <500>;
};
// PSC2 in spi mode example
spi@2200 { // PSC2
device_type = "spi";
compatible = "5200-psc";
reg = <2200 100>;
clock-frequency = <0>;
interrupts = <29 2>;
interrupt-parent = <500>;
};
// PSC3 in CODEC mode example
i2s@2400 { // PSC3
device_type = "i2s";
compatible = "5200-psc";
reg = <2400 100>;
clock-frequency = <0>;
interrupts = <2a 2>;
interrupt-parent = <500>;
};
// PSC4 unconfigured (example of AC97 mode)
//@2600 { // PSC4
// device_type = "serial";
// compatible = "5200-psc";
// reg = <2600 100>;
// clock-frequency = <0>;
// interrupts = <32 2>;
// interrupt-parent = <500>;
//};
// PSC5 unconfigured
//serial@2800 { // PSC5
// device_type = "serial";
// compatible = "5200-psc";
// reg = <2800 100>;
// clock-frequency = <0>;
// interrupts = <33 2>;
// interrupt-parent = <500>;
//};
// PSC6 in AC97 mode example
ac97@2c00 { // PSC6
device_type = "ac97";
compatible = "5200-psc";
reg = <2c00 100>;
clock-frequency = <0>;
interrupts = <2b 2>;
interrupt-parent = <500>;
};
ethernet@3000 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
model = "FEC";
compatible = "5200";
reg = <3000 800>;
mac-address = [ 02 03 04 05 06 07 ]; // Bad!
interrupts = <2c 2>;
interrupt-parent = <500>;
};
ata@3a00 {
device_type = "ata";
compatible = "5200";
reg = <3a00 100>;
interrupts = <2e 2>;
interrupt-parent = <500>;
};
i2c@3d00 {
device_type = "i2c";
compatible = "5200";
reg = <3d00 40>;
interrupts = <35 2>;
interrupt-parent = <500>;
};
i2c@3d40 {
device_type = "i2c";
compatible = "5200";
reg = <3d40 40>;
interrupts = <36 2>;
interrupt-parent = <500>;
};
};
};
^ permalink raw reply
* Please pull powerpc.git 'merge' branch
From: Paul Mackerras @ 2006-10-25 6:26 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do:
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get some more PowerPC bugfixes, as listed below. There is also a
defconfig update and the addition of a new processor type (970GX) to
the cpu table. The first 4 listed under Ben H.'s name aren't strictly
bugfixes in themselves, but are needed for the Cell timebase hardware
bug workaround (the bug is that reads from the timebase may
occasionally not return monotonically increasing values, as they
implemented the timebase as two 32-bit counters).
Thanks,
Paul.
arch/powerpc/boot/Makefile | 2
arch/powerpc/configs/cell_defconfig | 19 +++-
arch/powerpc/kernel/cputable.c | 86 +++++++++++++++++++
arch/powerpc/kernel/head_64.S | 19 ----
arch/powerpc/kernel/misc_32.S | 74 -----------------
arch/powerpc/kernel/misc_64.S | 124 ----------------------------
arch/powerpc/kernel/module_32.c | 39 +++++++--
arch/powerpc/kernel/module_64.c | 49 +++++++++--
arch/powerpc/kernel/prom.c | 8 +-
arch/powerpc/kernel/setup_32.c | 8 +-
arch/powerpc/kernel/setup_64.c | 11 ++
arch/powerpc/kernel/time.c | 63 ++++----------
arch/powerpc/kernel/vdso.c | 43 ++++++++++
arch/powerpc/kernel/vdso32/vdso32.lds.S | 12 +++
arch/powerpc/kernel/vdso64/gettimeofday.S | 6 +
arch/powerpc/kernel/vdso64/vdso64.lds.S | 10 ++
arch/powerpc/oprofile/op_model_power4.c | 2
arch/powerpc/platforms/cell/spufs/file.c | 2
arch/powerpc/platforms/cell/spufs/hw_ops.c | 2
arch/powerpc/platforms/chrp/setup.c | 4 +
arch/powerpc/platforms/iseries/setup.c | 5 +
arch/powerpc/platforms/powermac/sleep.S | 3 -
arch/powerpc/sysdev/i8259.c | 5 +
arch/powerpc/sysdev/ipic.c | 4 -
arch/powerpc/sysdev/qe_lib/ucc.c | 2
arch/powerpc/sysdev/qe_lib/ucc_fast.c | 2
arch/powerpc/sysdev/qe_lib/ucc_slow.c | 2
arch/powerpc/sysdev/tsi108_dev.c | 4 -
arch/ppc/boot/simple/relocate.S | 6 +
arch/ppc/kernel/misc.S | 74 -----------------
arch/ppc/kernel/setup.c | 10 +-
include/asm-powerpc/asm-compat.h | 52 ++++++++++++
include/asm-powerpc/cputable.h | 37 +++-----
include/asm-powerpc/firmware.h | 17 ++--
include/asm-powerpc/i8259.h | 1
include/asm-powerpc/ppc_asm.h | 18 +++-
include/asm-powerpc/prom.h | 10 +-
include/asm-powerpc/reg.h | 26 ++++++
include/asm-powerpc/time.h | 27 ++++--
include/asm-powerpc/timex.h | 20 ++---
scripts/mod/modpost.c | 2
41 files changed, 456 insertions(+), 454 deletions(-)
Arnd Bergmann:
[POWERPC] spufs: fix another off-by-one bug in spufs_mbox_read
[POWERPC] cell: update defconfig
Benjamin Herrenschmidt:
[POWERPC] Consolidate feature fixup code
[POWERPC] Support nested cpu feature sections
[POWERPC] Support feature fixups in vdso's
[POWERPC] Support feature fixups in modules
[POWERPC] Cell timebase bug workaround
[POWERPC] Fix device_is_compatible() const warning
[POWERPC] Fix CHRP platforms with only 8259
Dwayne Grant Mcconnell:
[POWERPC] spufs: fix signal2 file to report signal2
Jake Moilanen:
[POWERPC] Add 970GX cputable entry
Liu Dave-r63238:
[POWERPC] Fix the UCC rx/tx clock of QE
Mark A. Greer:
[POWERPC] Don't require execute perms on wrapper when building zImage.initrd
Olaf Hering:
[POWERPC] Fix hang in start_ldr if _end or _edata is unaligned
Scott Wood:
[POWERPC] IPIC: Fix spinlock recursion in set_irq_handler
Srinivasa Ds:
[POWERPC] Fix build breakage with CONFIG_PPC32
Stephen Rothwell:
[POWERPC] Simplify stolen time calculation
Timur Tabi:
[POWERPC] Fix spelling errors in ucc_fast.c and ucc_slow.c
Zang Roy-r61911:
[POWERPC] Fix compiler warning message on get_property call
^ permalink raw reply
* Re: MPC8343: PCI resource allocation questions
From: Kumar Gala @ 2006-10-25 6:39 UTC (permalink / raw)
To: Luong Ngo; +Cc: linuxppc-dev list
In-Reply-To: <1b2aacd80610242246n20075a33pcc76ab5be71fb87e@mail.gmail.com>
> I'm a bit confused here. If the host bridge is ignored/excluded,
> then the region size in BARs will not be allocated corresponding
> resource by the PCI subsystem, then how would other PCI devices in
> the slots could be allocated in the BAR's range? If I understand
> correctly, the PCI devices's resources are allocated based on the
> bridge resource, which is assigned statically by PCI subsystem
> using hose->mem_space and hose->io_space instead of reading it from
> the BARs. Maybe you are saying in the case the CPU is in agent mode
> and its PCI host bridge is functioning as a PCI-PCI bridge?
The problem is the host bridge shouldn't be included in BAR
assignment since its the host bridge. The problem is FSL devices
show up when they scan themselves and the kernel then tries to
allocate resources to them as if they were any other device.
you are correct, the pci subsystem is setup via the hose structure
and not by trying to read BARs on the host controller itself.
- kumar
^ permalink raw reply
* Re: pci_set_power_state() failure and breaking suspend
From: Stefan Richter @ 2006-10-25 6:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, linux1394-devel, Linux Kernel list, Greg KH
In-Reply-To: <1161675611.10524.598.camel@localhost.localdomain>
On 24 Okt, Benjamin Herrenschmidt wrote:
>> Recently, ohci1394 grew some "proper" error handling in its suspend
>> function, something that looks like:
>>
>> err = pci_set_power_state(pdev, pci_choose_state(pdev, state));
>> if (err)
>> goto out;
...
> First, it breaks some old PowerBooks where the internal OHCI has no PM
> feature exposed on PCI....
What about the following? Could someone compile-test it with gcc4
and CONFIG_IEEE1394_VERBOSEDEBUG=n?
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
Subject: ieee1394: ohci1394: revert fail on error in suspend
The error checks in the suspend code were too harsh and broke
suspend on some PPC_PMACs again which have extra platform code.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
Index: linux/drivers/ieee1394/ohci1394.c
===================================================================
--- linux.orig/drivers/ieee1394/ohci1394.c 2006-10-25 08:26:44.000000000 +0200
+++ linux/drivers/ieee1394/ohci1394.c 2006-10-25 08:28:34.000000000 +0200
@@ -3553,11 +3553,16 @@ static int ohci1394_pci_suspend (struct
int err;
err = pci_save_state(pdev);
- if (err)
- goto out;
+ if (err) {
+ printk(KERN_ERR "%s: pci_save_state failed with %d\n",
+ OHCI1394_DRIVER_NAME, err);
+ return err;
+ }
err = pci_set_power_state(pdev, pci_choose_state(pdev, state));
+#ifdef OHCI1394_DEBUG
if (err)
- goto out;
+ printk(KERN_DEBUG "pci_set_power_state failed %d\n", err);
+#endif /* OHCI1394_DEBUG */
/* PowerMac suspend code comes last */
#ifdef CONFIG_PPC_PMAC
@@ -3570,8 +3575,8 @@ static int ohci1394_pci_suspend (struct
pmac_call_feature(PMAC_FTR_1394_ENABLE, of_node, 0, 0);
}
#endif /* CONFIG_PPC_PMAC */
-out:
- return err;
+
+ return 0;
}
#endif /* CONFIG_PM */
^ permalink raw reply
* Re: MPC8343: PCI resource allocation questions
From: Luong Ngo @ 2006-10-25 5:46 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <E2847437-6C75-4963-B9DB-BAC050015C88@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1562 bytes --]
Kumar, thanks a lot for your prompt and clear answers. But I still have a
couple questions about the BARs.
> The PCI resources are used for any PCI devices that need memory
> mapped space allocated to them. What devices are you connecting over
> PCI?
I am connecting Broadcom BCM56502 controllers over PCI.
The region was large since the reference board has general purpose
PCI slots for any number of various cards. We provide a large space
to allow for those cards to be allocated into. Depending on your
application you can adjust this as you need.
I'm a bit confused here. If the host bridge is ignored/excluded, then the
region size in BARs will not be allocated corresponding resource by the PCI
subsystem, then how would other PCI devices in the slots could be allocated
in the BAR's range? If I understand correctly, the PCI devices's resources
are allocated based on the bridge resource, which is assigned statically by
PCI subsystem using hose->mem_space and hose->io_space instead of reading it
from the BARs. Maybe you are saying in the case the CPU is in agent mode and
its PCI host bridge is functioning as a PCI-PCI bridge?
You are not leaving any memory space for any of the onchip devices,
the error messages are because the regions of memory that the devices
are expected to be at are already occupied by the PCI space.
Isn't it the PCI IO and PCI MEM space are separated from local memory space?
I believe I see the global io_resource and mem_resource have the range of
0x0 - 0xFFFFFFFF.
I appreciate your help,
Thanks,
Luong Ngo
[-- Attachment #2: Type: text/html, Size: 2062 bytes --]
^ permalink raw reply
* Re: pci_set_power_state() failure and breaking suspend
From: Stefan Richter @ 2006-10-25 6:48 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, linux1394-devel, Linux Kernel list, Greg KH
In-Reply-To: <tkrat.1b479115136413cf@s5r6.in-berlin.de>
I wrote:
> + printk(KERN_DEBUG "pci_set_power_state failed %d\n", err);
...with... ^
--
Stefan Richter
-=====-=-==- =-=- ==--=
http://arcgraph.de/sr/
^ permalink raw reply
* Re: pci_set_power_state() failure and breaking suspend
From: Stefan Richter @ 2006-10-25 6:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, linux1394-devel, Linux Kernel list, Greg KH
In-Reply-To: <453F08A0.9040506@s5r6.in-berlin.de>
And this should go on top of ohci1394_pci_suspend:
+ printk(KERN_INFO "%s does not fully support suspend yet\n",
+ OHCI1394_DRIVER_NAME);
+
--
Stefan Richter
-=====-=-==- =-=- ==--=
http://arcgraph.de/sr/
^ permalink raw reply
* Re: MPC8343: PCI resource allocation questions
From: Luong Ngo @ 2006-10-25 7:16 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <4BF669F6-7A28-4915-9DFF-0B00CC04E242@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]
Would you mind explain me the last question in previous email?
You are not leaving any memory space for any of the onchip devices,
the error messages are because the regions of memory that the devices
are expected to be at are already occupied by the PCI space.
Isn't it the PCI IO and PCI MEM space are separated from local memory space?
I think I see the global IO resource and MEM resource have the range of 0x0
- 0xFFFFFFFF.
Thanks,
Luong Ngo
On 10/24/06, Kumar Gala <galak@kernel.crashing.org> wrote:
>
>
> > I'm a bit confused here. If the host bridge is ignored/excluded,
> > then the region size in BARs will not be allocated corresponding
> > resource by the PCI subsystem, then how would other PCI devices in
> > the slots could be allocated in the BAR's range? If I understand
> > correctly, the PCI devices's resources are allocated based on the
> > bridge resource, which is assigned statically by PCI subsystem
> > using hose->mem_space and hose->io_space instead of reading it from
> > the BARs. Maybe you are saying in the case the CPU is in agent mode
> > and its PCI host bridge is functioning as a PCI-PCI bridge?
>
> The problem is the host bridge shouldn't be included in BAR
> assignment since its the host bridge. The problem is FSL devices
> show up when they scan themselves and the kernel then tries to
> allocate resources to them as if they were any other device.
>
> you are correct, the pci subsystem is setup via the hose structure
> and not by trying to read BARs on the host controller itself.
>
> - kumar
>
[-- Attachment #2: Type: text/html, Size: 2105 bytes --]
^ permalink raw reply
* Re: Crash with highmem support enabled
From: Gerhard Pircher @ 2006-10-25 7:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17726.63354.839675.689493@cargo.ozlabs.ibm.com>
-------- Original-Nachricht --------
Datum: Wed, 25 Oct 2006 15:34:50 +1000
Von: Paul Mackerras <paulus@samba.org>
An: "Gerhard Pircher" <gerhard_pircher@gmx.net>
Betreff: Re: Crash with highmem support enabled
> Gerhard Pircher writes:
>
> > I guess this has something to do with the IO block mapping, which is
> > implemented in the amigaone_setup.c file and looks like this:
>
> Why on earth are you still using io_block_mapping?
What should be used instead? ioremap()? The io_block_mapping() code was copied over from the PReP platform code in arch/ppc/platforms/.
In the meantime I found out that highmem failed due to the IO block mapping (sometimes it is good to look at the code ;). The mapping is needed for the AmigaOne/U-boot framebuffer to be able to access the ISA memory and I/O. Where and when can I savely remap (no 1:1 remapping) the ISA space so that the framebuffer survives the MMU initialization?
thanks!
Gerhard
--
GMX DSL-Flatrate 0,- Euro* - Überall, wo DSL verfügbar ist!
NEU: Jetzt bis zu 16.000 kBit/s! http://www.gmx.net/de/go/dsl
^ permalink raw reply
* Re: [PATCH 11/16] sysfs: add support for adding/removing spu sysfs attributes
From: Heiko Carstens @ 2006-10-25 7:52 UTC (permalink / raw)
To: arnd; +Cc: linuxppc-dev, paulus, cbe-oss-dev, linux-kernel
In-Reply-To: <20061024163816.460479000@arndb.de>
> +int cpu_add_sysdev_attr(struct sysdev_attribute *attr)
> +{
> + int cpu;
> +
> + mutex_lock(&cpu_mutex);
> +
> + for_each_possible_cpu(cpu) {
> + sysdev_create_file(get_cpu_sysdev(cpu), attr);
> + }
> +
> + mutex_unlock(&cpu_mutex);
> + return 0;
> +}
You probably should check for errors on sysdev_create_file, clean up and
return an error number instead of always 0.
This is true for all the new functions here.
^ permalink raw reply
* Re: [PATCH 12/16] cell: add temperature to SPU and CPU sysfs entries
From: Heiko Carstens @ 2006-10-25 8:00 UTC (permalink / raw)
To: arnd
Cc: Arnd Bergmann, linux-kernel, linuxppc-dev, paulus,
Christian Krafft, cbe-oss-dev
In-Reply-To: <20061024163816.851732000@arndb.de>
On Tue, Oct 24, 2006 at 06:31:25PM +0200, arnd@arndb.de wrote:
> + * (C) Copyright IBM Deutschland Entwicklung GmbH 2005
IBM Corp. instead of IBM DE? 2006?
> +static int __init thermal_init(void)
> +{
> + init_default_values();
> +
> + spu_add_sysdev_attr_group(&spu_attribute_group);
> + cpu_add_sysdev_attr_group(&ppe_attribute_group);
> +
> + return 0;
> +}
Same here: check for errors on spu_add_sysdev_attr_group and
cpu_add_sysdev_attr_group.
> +static void __exit thermal_exit(void)
> +{
> + spu_remove_sysdev_attr_group(&spu_attribute_group);
> + cpu_remove_sysdev_attr_group(&ppe_attribute_group);
Will crash if cpu_add_sysdev_attr_group failed...
^ 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