Re: [PATCH] powerpc/powernv: Fix mis-merge of OPAL support for LEDS driver
On 08/22/2015 05:12 AM, Michael Ellerman wrote:
When I merged the OPAL support for the powernv LEDS driver I missed a
hunk.
This is slightly modified from the original patch, as the original added
code to opal-api.h which is not in the skiboot version, which is
discouraged.
Yeah. I should have made sure opal-api.h is in sync with skiboot. On skiboot
side I added below macros to fsp-leds.h instead of opal-api.h :-(
Anyway for now these macros are used by led driver only (on both side).. Hence I
think its fine to add to driver code itself. But we should make sure these
strings won't change as we use them while creating sysfs entries and use that
information to identify the type of LED.
Instead those values are moved into the driver, which is the only place
they are used.
Fixes: 8a8d91817aec (powerpc/powernv: Add OPAL interfaces for accessing and
modifying system LED states)
Signed-off-by: Michael Ellerman m...@ellerman.id.au
Patch looks good.
Reviewed-by: Vasant Hegde hegdevas...@linux.vnet.ibm.com
-Vasant
---
arch/powerpc/include/asm/opal-api.h | 12
drivers/leds/leds-powernv.c | 6 +++---
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/opal-api.h
b/arch/powerpc/include/asm/opal-api.h
index b516ec1d3b4c..9784c9241c70 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -343,6 +343,18 @@ enum OpalPciResetState {
OPAL_ASSERT_RESET = 1
};
+enum OpalSlotLedType {
+ OPAL_SLOT_LED_TYPE_ID = 0, /* IDENTIFY LED */
+ OPAL_SLOT_LED_TYPE_FAULT = 1, /* FAULT LED */
+ OPAL_SLOT_LED_TYPE_ATTN = 2,/* System Attention LED */
+ OPAL_SLOT_LED_TYPE_MAX = 3
+};
+
+enum OpalSlotLedState {
+ OPAL_SLOT_LED_STATE_OFF = 0,/* LED is OFF */
+ OPAL_SLOT_LED_STATE_ON = 1 /* LED is ON */
+};
+
/*
* Address cycle types for LPC accesses. These also correspond
* to the content of the first cell of the reg property for
diff --git a/drivers/leds/leds-powernv.c b/drivers/leds/leds-powernv.c
index a2fea192573b..2c5c5b12ab64 100644
--- a/drivers/leds/leds-powernv.c
+++ b/drivers/leds/leds-powernv.c
@@ -27,9 +27,9 @@ struct led_type_map {
const char *desc;
};
static const struct led_type_map led_type_map[] = {
- {OPAL_SLOT_LED_TYPE_ID, POWERNV_LED_TYPE_IDENTIFY},
- {OPAL_SLOT_LED_TYPE_FAULT, POWERNV_LED_TYPE_FAULT},
- {OPAL_SLOT_LED_TYPE_ATTN, POWERNV_LED_TYPE_ATTENTION},
+ {OPAL_SLOT_LED_TYPE_ID, identify},
+ {OPAL_SLOT_LED_TYPE_FAULT, fault},
+ {OPAL_SLOT_LED_TYPE_ATTN, attention},
{-1,NULL},
};
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the powerpc tree
On 08/22/2015 05:10 AM, Michael Ellerman wrote: On Fri, 2015-08-21 at 14:29 +0530, Vasant Hegde wrote: On 08/21/2015 01:55 PM, Stephen Rothwell wrote: Hi all, After merging the nvdimm tree, today's linux-next build (powerpc allyesconfig) failed like this: Stephen, Thanks for reporting! I checked powerpc tree.. This is because of commit 8a8d9181 in powerpc tree.. Basically Michael missed one hunk (below hunk in opal-api.h) Hmm, looks like it. I do remember the patch didn't apply to my tree, so I guess I accidentally dropped a hunk when I was forcing it to apply. Hmmm yeah..My patchset was based on pstream tree (4.2-rc7) instead of powerpc next tree. I also should have looked closer, as the following aren't in the skiboot version of opal-api.h. The skiboot and Linux versions of opal-api.h should be in sync as much as possible. As I mentioned in other thread I should have added all these macros to opal-api.h in skiboot.. +/* LED Mode */ +#define POWERNV_LED_MODE_LIGHT_PATHlightpath +#define POWERNV_LED_MODE_GUIDING_LIGHT guidinglight + +/* LED type */ +#define POWERNV_LED_TYPE_IDENTIFY identify +#define POWERNV_LED_TYPE_FAULT fault +#define POWERNV_LED_TYPE_ATTENTION attention Furthermore, I don't see the first two used at all, and the bottom three are only used in one place in the driver. So I've just sucked the values into the driver code and dropped the #defines. Patch coming shortly. Also we're obviously not building this in any of our defconfigs. Can you please send a patch to enable it for pseries_defconfig and ppc64_defconfig. Sure.. Will send separate patch. -Vasant ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/8xx: Shorten irq_chip name for the SIU
show_interrupts() expects the irq_chip name to be max 8 characters
otherwise everything get misaligned
# cat /proc/interrupts
CPU0
17: 0 CPM PIC 0 Level error
19: 0 MPC8XX SIU 15 Level tbint
20: 90 CPM PIC 4 Level cpm_uart
38: 29746 MPC8XX SIU 5 Level fs_enet-mac
39: 0 MPC8XX SIU 7 Level fs_enet-mac
47:401 CPM PIC 5 Level fsl_spi
68: 1 MPC8XX SIU 2 Level phy_interrupt, phy_interrupt,
phy_interrupt
LOC:7225485 Local timer interrupts for timer event device
LOC: 9 Local timer interrupts for others
SPU: 0 Spurious interrupts
PMI: 0 Performance monitoring interrupts
MCE: 0 Machine check exceptions
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
---
arch/powerpc/sysdev/mpc8xx_pic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/mpc8xx_pic.c b/arch/powerpc/sysdev/mpc8xx_pic.c
index c4828c0..475e706 100644
--- a/arch/powerpc/sysdev/mpc8xx_pic.c
+++ b/arch/powerpc/sysdev/mpc8xx_pic.c
@@ -61,7 +61,7 @@ static int mpc8xx_set_irq_type(struct irq_data *d, unsigned
int flow_type)
}
static struct irq_chip mpc8xx_pic = {
- .name = MPC8XX SIU,
+ .name = 8XX SIU,
.irq_unmask = mpc8xx_unmask_irq,
.irq_mask = mpc8xx_mask_irq,
.irq_ack = mpc8xx_ack,
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: handle error case in cpm_muram_alloc()
rh_alloc() returns (unsigned long)-ERRxx on error, which may result in overwriting memory outside the MURAM AREA. Signed-off-by: Christophe Leroy christophe.le...@c-s.fr --- arch/powerpc/sysdev/cpm_common.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/sysdev/cpm_common.c b/arch/powerpc/sysdev/cpm_common.c index e2ea519..e00a5ee 100644 --- a/arch/powerpc/sysdev/cpm_common.c +++ b/arch/powerpc/sysdev/cpm_common.c @@ -147,7 +147,8 @@ unsigned long cpm_muram_alloc(unsigned long size, unsigned long align) spin_lock_irqsave(cpm_muram_lock, flags); cpm_muram_info.alignment = align; start = rh_alloc(cpm_muram_info, size, commproc); - memset_io(cpm_muram_addr(start), 0, size); + if (!IS_ERR_VALUE(start)) + memset_io(cpm_muram_addr(start), 0, size); spin_unlock_irqrestore(cpm_muram_lock, flags); return start; -- 2.1.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the powerpc tree
On Fri, 2015-08-21 at 14:29 +0530, Vasant Hegde wrote: On 08/21/2015 01:55 PM, Stephen Rothwell wrote: Hi all, After merging the nvdimm tree, today's linux-next build (powerpc allyesconfig) failed like this: Stephen, Thanks for reporting! I checked powerpc tree.. This is because of commit 8a8d9181 in powerpc tree.. Basically Michael missed one hunk (below hunk in opal-api.h) Hmm, looks like it. I do remember the patch didn't apply to my tree, so I guess I accidentally dropped a hunk when I was forcing it to apply. I also should have looked closer, as the following aren't in the skiboot version of opal-api.h. The skiboot and Linux versions of opal-api.h should be in sync as much as possible. +/* LED Mode */ +#define POWERNV_LED_MODE_LIGHT_PATHlightpath +#define POWERNV_LED_MODE_GUIDING_LIGHT guidinglight + +/* LED type */ +#define POWERNV_LED_TYPE_IDENTIFY identify +#define POWERNV_LED_TYPE_FAULT fault +#define POWERNV_LED_TYPE_ATTENTION attention Furthermore, I don't see the first two used at all, and the bottom three are only used in one place in the driver. So I've just sucked the values into the driver code and dropped the #defines. Patch coming shortly. Also we're obviously not building this in any of our defconfigs. Can you please send a patch to enable it for pseries_defconfig and ppc64_defconfig. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/powernv: Fix mis-merge of OPAL support for LEDS driver
When I merged the OPAL support for the powernv LEDS driver I missed a
hunk.
This is slightly modified from the original patch, as the original added
code to opal-api.h which is not in the skiboot version, which is
discouraged.
Instead those values are moved into the driver, which is the only place
they are used.
Fixes: 8a8d91817aec (powerpc/powernv: Add OPAL interfaces for accessing and
modifying system LED states)
Signed-off-by: Michael Ellerman m...@ellerman.id.au
---
arch/powerpc/include/asm/opal-api.h | 12
drivers/leds/leds-powernv.c | 6 +++---
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/opal-api.h
b/arch/powerpc/include/asm/opal-api.h
index b516ec1d3b4c..9784c9241c70 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -343,6 +343,18 @@ enum OpalPciResetState {
OPAL_ASSERT_RESET = 1
};
+enum OpalSlotLedType {
+ OPAL_SLOT_LED_TYPE_ID = 0, /* IDENTIFY LED */
+ OPAL_SLOT_LED_TYPE_FAULT = 1, /* FAULT LED */
+ OPAL_SLOT_LED_TYPE_ATTN = 2,/* System Attention LED */
+ OPAL_SLOT_LED_TYPE_MAX = 3
+};
+
+enum OpalSlotLedState {
+ OPAL_SLOT_LED_STATE_OFF = 0,/* LED is OFF */
+ OPAL_SLOT_LED_STATE_ON = 1 /* LED is ON */
+};
+
/*
* Address cycle types for LPC accesses. These also correspond
* to the content of the first cell of the reg property for
diff --git a/drivers/leds/leds-powernv.c b/drivers/leds/leds-powernv.c
index a2fea192573b..2c5c5b12ab64 100644
--- a/drivers/leds/leds-powernv.c
+++ b/drivers/leds/leds-powernv.c
@@ -27,9 +27,9 @@ struct led_type_map {
const char *desc;
};
static const struct led_type_map led_type_map[] = {
- {OPAL_SLOT_LED_TYPE_ID, POWERNV_LED_TYPE_IDENTIFY},
- {OPAL_SLOT_LED_TYPE_FAULT, POWERNV_LED_TYPE_FAULT},
- {OPAL_SLOT_LED_TYPE_ATTN, POWERNV_LED_TYPE_ATTENTION},
+ {OPAL_SLOT_LED_TYPE_ID, identify},
+ {OPAL_SLOT_LED_TYPE_FAULT, fault},
+ {OPAL_SLOT_LED_TYPE_ATTN, attention},
{-1,NULL},
};
--
2.1.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/8] jump_label: introduce DEFINE_STATIC_KEY_{TRUE,FALSE}_ARRAY macros
* Kevin Hao haoke...@gmail.com wrote:
On Fri, Aug 21, 2015 at 08:28:26AM +0200, Ingo Molnar wrote:
* Kevin Hao haoke...@gmail.com wrote:
These are used to define a static_key_{true,false} array.
Signed-off-by: Kevin Hao haoke...@gmail.com
---
include/linux/jump_label.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index 7f653e8f6690..5c1d6a49dd6b 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -267,6 +267,12 @@ struct static_key_false {
#define DEFINE_STATIC_KEY_FALSE(name)\
struct static_key_false name = STATIC_KEY_FALSE_INIT
+#define DEFINE_STATIC_KEY_TRUE_ARRAY(name, n)\
+ struct static_key_true name[n] = { [0 ... n - 1] = STATIC_KEY_TRUE_INIT
}
+
+#define DEFINE_STATIC_KEY_FALSE_ARRAY(name, n) \
+ struct static_key_false name[n] = { [0 ... n - 1] =
STATIC_KEY_FALSE_INIT }
I think the define makes the code more obfuscated and less clear, the
open-coded
initialization is pretty dense and easy to read to begin with.
OK, I will drop this patch and move the initialization of the array to the
corresponding patch.
Please also Cc: peterz and me to the next submission of the series - static key
(and jump label) changes go through the locking tree normally, and there's a
number of changes pending already for v4.3:
20f9ed1568c0 locking/static_keys: Make verify_keys() static
412758cb2670 jump label, locking/static_keys: Update docs
2bf9e0ab08c6 locking/static_keys: Provide a selftest
ed79e946732e s390/uaccess, locking/static_keys: employ static_branch_likely()
3bbfafb77a06 x86, tsc, locking/static_keys: Employ static_branch_likely()
1987c947d905 locking/static_keys: Add selftest
11276d5306b8 locking/static_keys: Add a new static_key interface
706249c222f6 locking/static_keys: Rework update logic
e33886b38cc8 locking/static_keys: Add static_key_{en,dis}able() helpers
7dcfd915bae5 jump_label: Add jump_entry_key() helper
a1efb01feca5 jump_label, locking/static_keys: Rename JUMP_LABEL_TYPE_* and
related helpers to the static_key* pattern
Thanks,
Ingo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 51/52] PCI: Introduce resource_disabled()
Current is using !flags, and we are going to use
IORESOURCE_DISABLED instead of clearing resource flags.
Let's convert all !flags to helper function resource_disabled().
resource_disabled will check !flags and IORESOURCE_DISABLED both.
Cc: linux-al...@vger.kernel.org
Cc: linux-i...@vger.kernel.org
Cc: linux-am33-l...@redhat.com
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-xte...@linux-xtensa.org
Cc: io...@lists.linux-foundation.org
Cc: linux...@vger.kernel.org
Signed-off-by: Yinghai Lu ying...@kernel.org
---
arch/alpha/kernel/pci.c | 2 +-
arch/ia64/pci/pci.c | 4 ++--
arch/microblaze/pci/pci-common.c | 15 ---
arch/mn10300/unit-asb2305/pci-asb2305.c | 4 ++--
arch/mn10300/unit-asb2305/pci.c | 4 ++--
arch/powerpc/kernel/pci-common.c | 16 +---
arch/powerpc/platforms/powernv/pci-ioda.c | 12 ++--
arch/s390/pci/pci.c | 2 +-
arch/sparc/kernel/pci.c | 2 +-
arch/x86/pci/i386.c | 4 ++--
arch/xtensa/kernel/pci.c | 4 ++--
drivers/iommu/intel-iommu.c | 3 ++-
drivers/pci/host/pcie-rcar.c | 2 +-
drivers/pci/iov.c | 2 +-
drivers/pci/probe.c | 2 +-
drivers/pci/quirks.c | 4 ++--
drivers/pci/rom.c | 2 +-
drivers/pci/setup-bus.c | 8
drivers/pci/setup-res.c | 2 +-
include/linux/ioport.h| 4
20 files changed, 53 insertions(+), 45 deletions(-)
diff --git a/arch/alpha/kernel/pci.c b/arch/alpha/kernel/pci.c
index 82f738e..91a7153 100644
--- a/arch/alpha/kernel/pci.c
+++ b/arch/alpha/kernel/pci.c
@@ -282,7 +282,7 @@ pcibios_claim_one_bus(struct pci_bus *b)
for (i = 0; i PCI_NUM_RESOURCES; i++) {
struct resource *r = dev-resource[i];
- if (r-parent || !r-start || !r-flags)
+ if (r-parent || !r-start || resource_disabled(r))
continue;
if (pci_has_flag(PCI_PROBE_ONLY) ||
(r-flags IORESOURCE_PCI_FIXED)) {
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 7cc3be9..cc293ea 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -501,7 +501,7 @@ void pcibios_fixup_device_resources(struct pci_dev *dev)
for (idx = 0; idx PCI_BRIDGE_RESOURCES; idx++) {
struct resource *r = dev-resource[idx];
- if (!r-flags || r-parent || !r-start)
+ if (resource_disabled(r) || r-parent || !r-start)
continue;
pci_claim_resource(dev, idx);
@@ -519,7 +519,7 @@ static void pcibios_fixup_bridge_resources(struct pci_dev
*dev)
for (idx = PCI_BRIDGE_RESOURCES; idx PCI_NUM_RESOURCES; idx++) {
struct resource *r = dev-resource[idx];
- if (!r-flags || r-parent || !r-start)
+ if (resource_disabled(r) || r-parent || !r-start)
continue;
pci_claim_bridge_resource(dev, idx);
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index 09b1af6..c123d3c 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -705,7 +705,7 @@ static void pcibios_fixup_resources(struct pci_dev *dev)
}
for (i = 0; i DEVICE_COUNT_RESOURCE; i++) {
struct resource *res = dev-resource + i;
- if (!res-flags)
+ if (resource_disabled(res))
continue;
if (res-start == 0) {
pr_debug(PCI:%s Resource %d %016llx-%016llx [%x],
@@ -806,7 +806,7 @@ static void pcibios_fixup_bridge(struct pci_bus *bus)
pci_bus_for_each_resource(bus, res, i) {
if (!res)
continue;
- if (!res-flags)
+ if (resource_disabled(res))
continue;
if (i = 3 bus-self-transparent)
continue;
@@ -985,7 +985,7 @@ static void pcibios_allocate_bus_resources(struct pci_bus
*bus)
pci_domain_nr(bus), bus-number);
pci_bus_for_each_resource(bus, res, i) {
- if (!res || !res-flags
+ if (!res || resource_disabled(res)
|| res-start res-end || res-parent)
continue;
if (bus-parent == NULL)
@@ -1087,7 +1087,8 @@ static void __init pcibios_allocate_resources(int pass)
r = dev-resource[idx];
if (r-parent) /* Already allocated */
continue;
- if (!r-flags
Re: [PATCH 3/8] jump_label: introduce DEFINE_STATIC_KEY_{TRUE,FALSE}_ARRAY macros
On Fri, Aug 21, 2015 at 08:28:26AM +0200, Ingo Molnar wrote:
* Kevin Hao haoke...@gmail.com wrote:
These are used to define a static_key_{true,false} array.
Signed-off-by: Kevin Hao haoke...@gmail.com
---
include/linux/jump_label.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index 7f653e8f6690..5c1d6a49dd6b 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -267,6 +267,12 @@ struct static_key_false {
#define DEFINE_STATIC_KEY_FALSE(name) \
struct static_key_false name = STATIC_KEY_FALSE_INIT
+#define DEFINE_STATIC_KEY_TRUE_ARRAY(name, n) \
+ struct static_key_true name[n] = { [0 ... n - 1] = STATIC_KEY_TRUE_INIT
}
+
+#define DEFINE_STATIC_KEY_FALSE_ARRAY(name, n) \
+ struct static_key_false name[n] = { [0 ... n - 1] =
STATIC_KEY_FALSE_INIT }
I think the define makes the code more obfuscated and less clear, the
open-coded
initialization is pretty dense and easy to read to begin with.
OK, I will drop this patch and move the initialization of the array to the
corresponding patch.
Thanks,
Kevin
pgpYG6ePRc7ly.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/8] jump_label: introduce DEFINE_STATIC_KEY_{TRUE,FALSE}_ARRAY macros
On Fri, Aug 21, 2015 at 08:40:59AM +0200, Ingo Molnar wrote: Please also Cc: peterz and me to the next submission of the series - static key (and jump label) changes go through the locking tree normally, and there's a number of changes pending already for v4.3: Sure. Thanks, Kevin pgpesUVc6FUqb.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 31/52] PCI: Unify skip_ioresource_align()
There are powerpc generic version and x86 local version for
skip_ioresource_align().
Move the powerpc version to setup-bus.c, and kill x86 local version.
Also kill dummy version in microblaze.
Cc: Michal Simek mon...@monstr.eu
Cc: Paul Mackerras pau...@samba.org
Cc: Michael Ellerman m...@ellerman.id.au
Cc: Arnd Bergmann a...@arndb.de
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-a...@vger.kernel.org
Signed-off-by: Yinghai Lu ying...@kernel.org
---
arch/microblaze/pci/pci-common.c | 8
arch/powerpc/kernel/pci-common.c | 11 +--
arch/x86/include/asm/pci_x86.h | 1 -
arch/x86/pci/common.c| 4 ++--
arch/x86/pci/i386.c | 12 ++--
drivers/pci/setup-bus.c | 9 +
include/asm-generic/pci-bridge.h | 2 ++
7 files changed, 16 insertions(+), 31 deletions(-)
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index ae838ed..09b1af6 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -878,11 +878,6 @@ void pcibios_fixup_bus(struct pci_bus *bus)
}
EXPORT_SYMBOL(pcibios_fixup_bus);
-static int skip_isa_ioresource_align(struct pci_dev *dev)
-{
- return 0;
-}
-
/*
* We need to avoid collisions with `mirrored' VGA ports
* and other strange ISA hardware, so we always want the
@@ -899,12 +894,9 @@ static int skip_isa_ioresource_align(struct pci_dev *dev)
resource_size_t pcibios_align_resource(void *data, const struct resource *res,
resource_size_t size, resource_size_t align)
{
- struct pci_dev *dev = data;
resource_size_t start = res-start;
if (res-flags IORESOURCE_IO) {
- if (skip_isa_ioresource_align(dev))
- return start;
if (start 0x300)
start = (start + 0x3ff) ~0x3ff;
}
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index b9de34d..2d8d654 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -1064,15 +1064,6 @@ void pci_fixup_cardbus(struct pci_bus *bus)
pcibios_setup_bus_devices(bus);
}
-
-static int skip_isa_ioresource_align(struct pci_dev *dev)
-{
- if (pci_has_flag(PCI_CAN_SKIP_ISA_ALIGN)
- !(dev-bus-bridge_ctl PCI_BRIDGE_CTL_ISA))
- return 1;
- return 0;
-}
-
/*
* We need to avoid collisions with `mirrored' VGA ports
* and other strange ISA hardware, so we always want the
@@ -1093,7 +1084,7 @@ resource_size_t pcibios_align_resource(void *data, const
struct resource *res,
resource_size_t start = res-start;
if (res-flags IORESOURCE_IO) {
- if (skip_isa_ioresource_align(dev))
+ if (skip_isa_ioresource_align(dev-bus))
return start;
if (start 0x300)
start = (start + 0x3ff) ~0x3ff;
diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
index 164e3f8..ddac225 100644
--- a/arch/x86/include/asm/pci_x86.h
+++ b/arch/x86/include/asm/pci_x86.h
@@ -28,7 +28,6 @@ do { \
#define PCI_ASSIGN_ROMS0x1000
#define PCI_BIOS_IRQ_SCAN 0x2000
#define PCI_ASSIGN_ALL_BUSSES 0x4000
-#define PCI_CAN_SKIP_ISA_ALIGN 0x8000
#define PCI_USE__CRS 0x1
#define PCI_CHECK_ENABLE_AMD_MMCONF0x2
#define PCI_HAS_IO_ECS 0x4
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index 8fd6f44..e8df922 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -83,7 +83,7 @@ DEFINE_RAW_SPINLOCK(pci_config_lock);
static int __init can_skip_ioresource_align(const struct dmi_system_id *d)
{
- pci_probe |= PCI_CAN_SKIP_ISA_ALIGN;
+ pci_add_flags(PCI_CAN_SKIP_ISA_ALIGN);
printk(KERN_INFO PCI: %s detected, can skip ISA alignment\n,
d-ident);
return 0;
}
@@ -619,7 +619,7 @@ char *__init pcibios_setup(char *str)
pci_routeirq = 1;
return NULL;
} else if (!strcmp(str, skip_isa_align)) {
- pci_probe |= PCI_CAN_SKIP_ISA_ALIGN;
+ pci_add_flags(PCI_CAN_SKIP_ISA_ALIGN);
return NULL;
} else if (!strcmp(str, noioapicquirk)) {
noioapicquirk = 1;
diff --git a/arch/x86/pci/i386.c b/arch/x86/pci/i386.c
index 0a9f2ca..3f17726 100644
--- a/arch/x86/pci/i386.c
+++ b/arch/x86/pci/i386.c
@@ -33,6 +33,7 @@
#include linux/errno.h
#include linux/bootmem.h
+#include asm-generic/pci-bridge.h
#include asm/pat.h
#include asm/e820.h
#include asm/pci_x86.h
@@ -128,15 +129,6 @@ static void __init pcibios_fw_addr_list_del(void)
pcibios_fw_addr_done = true;
}
-static int
-skip_isa_ioresource_align(struct pci_dev *dev) {
-
- if ((pci_probe PCI_CAN_SKIP_ISA_ALIGN)
- !(dev-bus-bridge_ctl PCI_BRIDGE_CTL_ISA))
- return 1;
- return 0;
-}
-
/*
*
Re: [V4,2/2] powerpc/kexec: Reset HILE before kexec_sequence
On Wed, 2015-22-07 at 05:50:51 UTC, Samuel Mendoza-Jonas wrote: On powernv secondary cpus are returned to OPAL, and will then enter the target kernel in big-endian. However if it is set the HILE bit will persist, causing the first exception in the target kernel to be delivered in litte-endian regardless of the current endianess. If running on top of OPAL make sure the HILE bit is reset once we've finished waiting for all of the secondaries to be returned to OPAL. Signed-off-by: Samuel Mendoza-Jonas sam...@au1.ibm.com Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/e72bb8a5a884d0222311 cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: build failure after merge of the powerpc tree
Hi all,
After merging the nvdimm tree, today's linux-next build (powerpc
allyesconfig) failed like this:
drivers/leds/leds-powernv.c:30:3: error: 'OPAL_SLOT_LED_TYPE_ID' undeclared
here (not in a function)
{OPAL_SLOT_LED_TYPE_ID, POWERNV_LED_TYPE_IDENTIFY},
^
drivers/leds/leds-powernv.c:30:27: error: 'POWERNV_LED_TYPE_IDENTIFY'
undeclared here (not in a function)
{OPAL_SLOT_LED_TYPE_ID, POWERNV_LED_TYPE_IDENTIFY},
^
drivers/leds/leds-powernv.c:31:3: error: 'OPAL_SLOT_LED_TYPE_FAULT' undeclared
here (not in a function)
{OPAL_SLOT_LED_TYPE_FAULT, POWERNV_LED_TYPE_FAULT},
^
drivers/leds/leds-powernv.c:31:29: error: 'POWERNV_LED_TYPE_FAULT' undeclared
here (not in a function)
{OPAL_SLOT_LED_TYPE_FAULT, POWERNV_LED_TYPE_FAULT},
^
drivers/leds/leds-powernv.c:32:3: error: 'OPAL_SLOT_LED_TYPE_ATTN' undeclared
here (not in a function)
{OPAL_SLOT_LED_TYPE_ATTN, POWERNV_LED_TYPE_ATTENTION},
^
drivers/leds/leds-powernv.c:32:28: error: 'POWERNV_LED_TYPE_ATTENTION'
undeclared here (not in a function)
{OPAL_SLOT_LED_TYPE_ATTN, POWERNV_LED_TYPE_ATTENTION},
^
drivers/leds/leds-powernv.c: In function 'powernv_led_set':
drivers/leds/leds-powernv.c:92:13: error: 'OPAL_SLOT_LED_STATE_ON' undeclared
(first use in this function)
led_mask = OPAL_SLOT_LED_STATE_ON powernv_led-led_type;
^
drivers/leds/leds-powernv.c:92:13: note: each undeclared identifier is reported
only once for each function it appears in
drivers/leds/leds-powernv.c:92:36: error: invalid operands to binary (have
'const struct led_type_map *' and 'int')
led_mask = OPAL_SLOT_LED_STATE_ON powernv_led-led_type;
^
drivers/leds/leds-powernv.c:92:11: warning: assignment makes integer from
pointer without a cast
led_mask = OPAL_SLOT_LED_STATE_ON powernv_led-led_type;
^
drivers/leds/leds-powernv.c: In function 'powernv_led_get':
drivers/leds/leds-powernv.c:159:46: error: 'OPAL_SLOT_LED_STATE_ON' undeclared
(first use in this function)
if (!((led_mask powernv_led-led_type) OPAL_SLOT_LED_STATE_ON)) {
^
drivers/leds/leds-powernv.c:159:44: error: invalid operands to binary (have
'u64' and 'const struct led_type_map *')
if (!((led_mask powernv_led-led_type) OPAL_SLOT_LED_STATE_ON)) {
^
drivers/leds/leds-powernv.c:166:43: error: invalid operands to binary (have
'u64' and 'const struct led_type_map *')
if ((led_value powernv_led-led_type) OPAL_SLOT_LED_STATE_ON)
^
In file included from include/linux/byteorder/big_endian.h:4:0,
from arch/powerpc/include/uapi/asm/byteorder.h:13,
from include/asm-generic/bitops/le.h:5,
from arch/powerpc/include/asm/bitops.h:279,
from include/linux/bitops.h:36,
from include/linux/kernel.h:10,
from include/linux/list.h:8,
from include/linux/kobject.h:20,
from include/linux/device.h:17,
from include/linux/leds.h:15,
from drivers/leds/leds-powernv.c:15:
drivers/leds/leds-powernv.c: In function 'powernv_led_probe':
drivers/leds/leds-powernv.c:300:49: error: 'OPAL_SLOT_LED_TYPE_MAX' undeclared
(first use in this function)
powernv_led_common-max_led_type = cpu_to_be64(OPAL_SLOT_LED_TYPE_MAX);
^
include/uapi/linux/byteorder/big_endian.h:36:51: note: in definition of macro
'__cpu_to_be64'
#define __cpu_to_be64(x) ((__force __be64)(__u64)(x))
^
drivers/leds/leds-powernv.c:300:37: note: in expansion of macro 'cpu_to_be64'
powernv_led_common-max_led_type = cpu_to_be64(OPAL_SLOT_LED_TYPE_MAX);
^
Caused by commit
84ad6e5cd3e8 (leds/powernv: Add driver for PowerNV platform)
I suspect that the updates to a file were missed in the commit?
I have reverted that commit for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/hvsi: Fix endianness issues in the HVSI driver
On Fri, 2015-31-07 at 09:29:50 UTC, Laurent Dufour wrote: This patch fixes several endianness issues detected when running the HVSI driver in little endian mode. These issues are raised in little endian mode because the data exchanged in memory between the kernel and the hypervisor has to be in big endian format. Signed-off-by: Laurent Dufour lduf...@linux.vnet.ibm.com CC: Greg Kroah-Hartman gre...@linuxfoundation.org CC: Jiri Slaby jsl...@suse.cz CC: linuxppc-dev@lists.ozlabs.org CC: linux-ker...@vger.kernel.org Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/480798044eb268a31f6b cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] cxl: Remove racy attempt to force EEH invocation in reset
Acked-by: Ian Munsie imun...@au1.ibm.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the powerpc tree
On 08/21/2015 01:55 PM, Stephen Rothwell wrote:
Hi all,
After merging the nvdimm tree, today's linux-next build (powerpc
allyesconfig) failed like this:
Stephen,
Thanks for reporting! I checked powerpc tree.. This is because of commit
8a8d9181 in powerpc tree.. Basically Michael missed one hunk (below hunk in
opal-api.h)
+/* LED Mode */
+#define POWERNV_LED_MODE_LIGHT_PATHlightpath
+#define POWERNV_LED_MODE_GUIDING_LIGHT guidinglight
+
+/* LED type */
+#define POWERNV_LED_TYPE_IDENTIFY identify
+#define POWERNV_LED_TYPE_FAULT fault
+#define POWERNV_LED_TYPE_ATTENTION attention
+
+enum OpalSlotLedType {
+ OPAL_SLOT_LED_TYPE_ID = 0, /* IDENTIFY LED */
+ OPAL_SLOT_LED_TYPE_FAULT = 1, /* FAULT LED */
+ OPAL_SLOT_LED_TYPE_ATTN = 2,/* System Attention LED */
+ OPAL_SLOT_LED_TYPE_MAX = 3
+};
+
+enum OpalSlotLedState {
+ OPAL_SLOT_LED_STATE_OFF = 0,/* LED is OFF */
+ OPAL_SLOT_LED_STATE_ON = 1 /* LED is ON */
+};
+
@Michael,
Will you be fixing it or you want me to send separate patch for this one ?
-Vasant
drivers/leds/leds-powernv.c:30:3: error: 'OPAL_SLOT_LED_TYPE_ID' undeclared
here (not in a function)
{OPAL_SLOT_LED_TYPE_ID, POWERNV_LED_TYPE_IDENTIFY},
^
drivers/leds/leds-powernv.c:30:27: error: 'POWERNV_LED_TYPE_IDENTIFY'
undeclared here (not in a function)
{OPAL_SLOT_LED_TYPE_ID, POWERNV_LED_TYPE_IDENTIFY},
^
drivers/leds/leds-powernv.c:31:3: error: 'OPAL_SLOT_LED_TYPE_FAULT'
undeclared here (not in a function)
{OPAL_SLOT_LED_TYPE_FAULT, POWERNV_LED_TYPE_FAULT},
^
drivers/leds/leds-powernv.c:31:29: error: 'POWERNV_LED_TYPE_FAULT' undeclared
here (not in a function)
{OPAL_SLOT_LED_TYPE_FAULT, POWERNV_LED_TYPE_FAULT},
^
drivers/leds/leds-powernv.c:32:3: error: 'OPAL_SLOT_LED_TYPE_ATTN' undeclared
here (not in a function)
{OPAL_SLOT_LED_TYPE_ATTN, POWERNV_LED_TYPE_ATTENTION},
^
drivers/leds/leds-powernv.c:32:28: error: 'POWERNV_LED_TYPE_ATTENTION'
undeclared here (not in a function)
{OPAL_SLOT_LED_TYPE_ATTN, POWERNV_LED_TYPE_ATTENTION},
^
drivers/leds/leds-powernv.c: In function 'powernv_led_set':
drivers/leds/leds-powernv.c:92:13: error: 'OPAL_SLOT_LED_STATE_ON' undeclared
(first use in this function)
led_mask = OPAL_SLOT_LED_STATE_ON powernv_led-led_type;
^
drivers/leds/leds-powernv.c:92:13: note: each undeclared identifier is
reported only once for each function it appears in
drivers/leds/leds-powernv.c:92:36: error: invalid operands to binary (have
'const struct led_type_map *' and 'int')
led_mask = OPAL_SLOT_LED_STATE_ON powernv_led-led_type;
^
drivers/leds/leds-powernv.c:92:11: warning: assignment makes integer from
pointer without a cast
led_mask = OPAL_SLOT_LED_STATE_ON powernv_led-led_type;
^
drivers/leds/leds-powernv.c: In function 'powernv_led_get':
drivers/leds/leds-powernv.c:159:46: error: 'OPAL_SLOT_LED_STATE_ON'
undeclared (first use in this function)
if (!((led_mask powernv_led-led_type) OPAL_SLOT_LED_STATE_ON)) {
^
drivers/leds/leds-powernv.c:159:44: error: invalid operands to binary (have
'u64' and 'const struct led_type_map *')
if (!((led_mask powernv_led-led_type) OPAL_SLOT_LED_STATE_ON)) {
^
drivers/leds/leds-powernv.c:166:43: error: invalid operands to binary (have
'u64' and 'const struct led_type_map *')
if ((led_value powernv_led-led_type) OPAL_SLOT_LED_STATE_ON)
^
In file included from include/linux/byteorder/big_endian.h:4:0,
from arch/powerpc/include/uapi/asm/byteorder.h:13,
from include/asm-generic/bitops/le.h:5,
from arch/powerpc/include/asm/bitops.h:279,
from include/linux/bitops.h:36,
from include/linux/kernel.h:10,
from include/linux/list.h:8,
from include/linux/kobject.h:20,
from include/linux/device.h:17,
from include/linux/leds.h:15,
from drivers/leds/leds-powernv.c:15:
drivers/leds/leds-powernv.c: In function 'powernv_led_probe':
drivers/leds/leds-powernv.c:300:49: error: 'OPAL_SLOT_LED_TYPE_MAX'
undeclared (first use in this function)
powernv_led_common-max_led_type = cpu_to_be64(OPAL_SLOT_LED_TYPE_MAX);
^
include/uapi/linux/byteorder/big_endian.h:36:51: note: in definition of macro
'__cpu_to_be64'
#define __cpu_to_be64(x) ((__force __be64)(__u64)(x))
^
drivers/leds/leds-powernv.c:300:37: note: in expansion of macro 'cpu_to_be64'
powernv_led_common-max_led_type = cpu_to_be64(OPAL_SLOT_LED_TYPE_MAX);
[PATCH] cxl: Remove racy attempt to force EEH invocation in reset
cxl_reset currently PERSTs the slot, and then repeatedly tries to
read MMIO space in order to kick off EEH.
There are 2 problems with this: it's unnecessary, and it's racy.
It's unnecessary because the PERST will bring down the PHB link.
That will be picked up by the CAPP, which will send out an HMI.
Skiboot, noticing an HMI from the CAPP, will send an OPAL
notification to the kernel, which will trigger EEH recovery.
It's also racy: the EEH recovery triggered by the CAPP will
eventually cause the MMIO space to have its mapping invalidated
and the pointer NULLed out. This races with our attempt to read
the MMIO space. This is causing OOPSes in testing.
Simply drop all the attempts to force EEH detection, and trust
that Skiboot will send the notification and that we'll act on it.
The Skiboot code to send the EEH notification has been in Skiboot
for as long as CAPP recovery has been supported, so we don't need
to worry about breaking obscure setups with ancient firmware.
Cc: Ryan Grimm gr...@linux.vnet.ibm.com
Cc: sta...@vger.kernel.org
Fixes: 62fa19d4b4fd (cxl: Add ability to reset the card)
Signed-off-by: Daniel Axtens d...@axtens.net
---
Oddly, the commit message in 62fa19d4b4fd (cxl: Add ability to
reset the card) is correct in its explanation of EEH triggering.
My guess is that the extra code was added because in our development
environment (bml) the notifications don't seem to work reliably.
However, I have tested that the notifications do work on real/normal
hardware.
---
drivers/misc/cxl/pci.c | 16
1 file changed, 16 deletions(-)
diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c
index be3839e34b7c..84bb9adbccb1 100644
--- a/drivers/misc/cxl/pci.c
+++ b/drivers/misc/cxl/pci.c
@@ -887,8 +887,6 @@ int cxl_reset(struct cxl *adapter)
{
struct pci_dev *dev = to_pci_dev(adapter-dev.parent);
int rc;
- int i;
- u32 val;
if (adapter-perst_same_image) {
dev_warn(dev-dev,
@@ -906,20 +904,6 @@ int cxl_reset(struct cxl *adapter)
return rc;
}
- /* the PERST done above fences the PHB. So, reset depends on EEH
-* to unbind the driver, tell Sapphire to reinit the PHB, and rebind
-* the driver. Do an mmio read explictly to ensure EEH notices the
-* fenced PHB. Retry for a few seconds before giving up. */
- i = 0;
- while (((val = mmio_read32be(adapter-p1_mmio)) != 0x)
- (i 5)) {
- msleep(500);
- i++;
- }
-
- if (val != 0x)
- dev_err(dev-dev, cxl: PERST failed to trigger EEH\n);
-
return rc;
}
--
2.5.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [V4, 1/2] powerpc/kexec: Reset secondary cpu endianess before kexec
On Wed, 2015-22-07 at 05:50:50 UTC, Samuel Mendoza-Jonas wrote: If the target kernel does not inlcude the FIXUP_ENDIAN check, coming from a different-endian kernel will cause the target kernel to panic. All ppc64 kernels can handle starting in big-endian mode, so return to big-endian before branching into the target kernel. This mainly affects pseries as secondaries on powernv are returned to OPAL. Signed-off-by: Samuel Mendoza-Jonas sam...@au1.ibm.com Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/ffebf5f391dfa9da3e08 cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 42/52] powerpc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in OF parsing
For device resource PREF bit setting under bridge 64-bit pref resource,
we need to make sure only set PREF for 64bit resource, so set
IORESOUCE_MEM_64 for 64bit resource during of device resource flags
parsing.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96261
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96241
Signed-off-by: Yinghai Lu ying...@kernel.org
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: Michael Ellerman m...@ellerman.id.au
Cc: Gavin Shan gws...@linux.vnet.ibm.com
Cc: Yijing Wang wangyij...@huawei.com
Cc: Anton Blanchard an...@samba.org
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/kernel/pci_of_scan.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/pci_of_scan.c
b/arch/powerpc/kernel/pci_of_scan.c
index 42e02a2..f31bfd0 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -44,8 +44,10 @@ static unsigned int pci_parse_of_flags(u32 addr0, int bridge)
if (addr0 0x0200) {
flags = IORESOURCE_MEM | PCI_BASE_ADDRESS_SPACE_MEMORY;
- flags |= (addr0 22) PCI_BASE_ADDRESS_MEM_TYPE_64;
flags |= (addr0 28) PCI_BASE_ADDRESS_MEM_TYPE_1M;
+ if (addr0 0x0100)
+ flags |= IORESOURCE_MEM_64
+| PCI_BASE_ADDRESS_MEM_TYPE_64;
if (addr0 0x4000)
flags |= IORESOURCE_PREFETCH
| PCI_BASE_ADDRESS_MEM_PREFETCH;
--
1.8.4.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/8] jump_label: introduce DEFINE_STATIC_KEY_{TRUE,FALSE}_ARRAY macros
* Kevin Hao haoke...@gmail.com wrote:
These are used to define a static_key_{true,false} array.
Signed-off-by: Kevin Hao haoke...@gmail.com
---
include/linux/jump_label.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index 7f653e8f6690..5c1d6a49dd6b 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -267,6 +267,12 @@ struct static_key_false {
#define DEFINE_STATIC_KEY_FALSE(name)\
struct static_key_false name = STATIC_KEY_FALSE_INIT
+#define DEFINE_STATIC_KEY_TRUE_ARRAY(name, n)\
+ struct static_key_true name[n] = { [0 ... n - 1] = STATIC_KEY_TRUE_INIT
}
+
+#define DEFINE_STATIC_KEY_FALSE_ARRAY(name, n) \
+ struct static_key_false name[n] = { [0 ... n - 1] =
STATIC_KEY_FALSE_INIT }
I think the define makes the code more obfuscated and less clear, the
open-coded
initialization is pretty dense and easy to read to begin with.
Thanks,
Ingo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
