Re: [PATCH 5/7] powerpc/perf: Define big-endian version of perf_mem_data_src
Vince Weaver [vi...@deater.net] wrote: | On Sat, 10 Aug 2013, Sukadev Bhattiprolu wrote: | | | include/uapi/linux/perf_event.h | 55 +++ | 1 files changed, 55 insertions(+), 0 deletions(-) | | +#define __PERF_LE 1234 | +#define __PERF_BE 4321 | + | +#if defined(__KERNEL__) | | I could be wrong, but I thought files under uapi weren't supposed to | contain __KERNEL__ code. Wasn't that the whole point of uapi? | | Also having the perf_event interface depend on endianess just seems like a | complicated mess. Can't we just declare the interface to be a certain | endianess and have the kernel byte-swap as necessary? Except for the __KERNEL__ check, it looked like this approach would keep the kernel and user code same. Would it complicate user space ? I tried to avoid the __KERNEL__ check hack, but like I tried to explain in the patch, user space and kernel do the endian check differently. And, there are about ~300 sites in the kernel with __*ENDIAN checks Sukadev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/kvm: Copy the pvr value after memset
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Otherwise we would clear the pvr value
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
arch/powerpc/kvm/book3s_hv.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 2efa9dd..dd1b72c 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -680,13 +680,12 @@ static int kvmppc_handle_exit(struct kvm_run *run, struct
kvm_vcpu *vcpu,
}
int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu *vcpu,
- struct kvm_sregs *sregs)
+ struct kvm_sregs *sregs)
{
int i;
- sregs-pvr = vcpu-arch.pvr;
-
memset(sregs, 0, sizeof(struct kvm_sregs));
+ sregs-pvr = vcpu-arch.pvr;
for (i = 0; i vcpu-arch.slb_max; i++) {
sregs-u.s.ppc64.slb[i].slbe = vcpu-arch.slb[i].orige;
sregs-u.s.ppc64.slb[i].slbv = vcpu-arch.slb[i].origv;
@@ -696,7 +695,7 @@ int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu *vcpu,
}
int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
- struct kvm_sregs *sregs)
+ struct kvm_sregs *sregs)
{
int i, j;
--
1.8.1.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/kvm: Handle the boundary condition correctly
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
We should be able to copy upto count bytes
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
arch/powerpc/kvm/book3s_64_mmu_hv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c
b/arch/powerpc/kvm/book3s_64_mmu_hv.c
index 710d313..0ae6bb6 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
@@ -1362,7 +1362,7 @@ static ssize_t kvm_htab_read(struct file *file, char
__user *buf,
lbuf = (unsigned long __user *)buf;
nb = 0;
- while (nb + sizeof(hdr) + HPTE_SIZE count) {
+ while (nb + sizeof(hdr) + HPTE_SIZE = count) {
/* Initialize header */
hptr = (struct kvm_get_htab_header __user *)buf;
hdr.n_valid = 0;
@@ -1385,7 +1385,7 @@ static ssize_t kvm_htab_read(struct file *file, char
__user *buf,
/* Grab a series of valid entries */
while (i kvm-arch.hpt_npte
hdr.n_valid 0x
- nb + HPTE_SIZE count
+ nb + HPTE_SIZE = count
record_hpte(flags, hptp, hpte, revp, 1, first_pass)) {
/* valid entry, write it out */
++hdr.n_valid;
--
1.8.1.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/7] powerpc/perf: Define big-endian version of perf_mem_data_src
On Sat, Aug 10, 2013 at 10:34:58PM -0400, Vince Weaver wrote: On Sat, 10 Aug 2013, Sukadev Bhattiprolu wrote: include/uapi/linux/perf_event.h | 55 +++ 1 files changed, 55 insertions(+), 0 deletions(-) +#define __PERF_LE 1234 +#define __PERF_BE 4321 + +#if defined(__KERNEL__) I could be wrong, but I thought files under uapi weren't supposed to contain __KERNEL__ code. Wasn't that the whole point of uapi? Yes. Also having the perf_event interface depend on endianess just seems like a complicated mess. Can't we just declare the interface to be a certain endianess and have the kernel byte-swap as necessary? Yes I think so. The interface is already defined and it's little endian, so on big endian we just need to swap. The only part I'm not clear on is how things are handled in perf userspace, it seems to already do some byte swapping. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] powerpc: put the common parts of the ppc64*defconfigs in a Kconfig file
Hi Kumar, Thanks for your comments. On Fri, 9 Aug 2013 09:41:54 -0500 Kumar Gala ga...@kernel.crashing.org wrote: On Aug 9, 2013, at 1:24 AM, Stephen Rothwell wrote: We cannot put the unsetting of config options in the Kconfig file, nor the integer or string options. I checked that after this we get the same .config files generated (except for the addition of the new PPC64_DEFCONFIG* config options. Any thoughts? --- arch/powerpc/Kconfig | 2 + arch/powerpc/configs/Kconfig | 295 + arch/powerpc/configs/ppc64_defconfig | 301 +- arch/powerpc/configs/ppc64e_defconfig | 297 + 4 files changed, 302 insertions(+), 593 deletions(-) create mode 100644 arch/powerpc/configs/Kconfig Am I missing something here, isn't this a bit of a maintenance pain if symbol names change? I don't think it is any worse than what we have, and in fact may be better. Currently if someone renames a config option, they usually do nothing about the defconfigs, this way, at least if the option is in configs/Kconfig, they may update it. Also, how much of a benefit is this? There has been some discussion about Anton adding 2 new defconfigs that are very similar to the current defconfigs. This is an attempt to reduce the amount of unnecessary repetition and churn. A similar thing could be done for other sets of similar defconfig files. There was a plan a few years ago to replace the defconfigs with Kconfig fragments and this would be a step along that path. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpAck7jwVjF_.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] Register bootmem pages at boot on powerpc
On Fri, 2013-08-09 at 10:32 -0500, Nathan Fontenot wrote:
+void register_page_bootmem_memmap(unsigned long section_nr,
+ struct page *start_page, unsigned long size)
+{
+ WARN_ONCE(1, KERN_INFO
+ Sparse Vmemmap not fully supported for bootmem info
nodes\n);
+}
#endif /* CONFIG_SPARSEMEM_VMEMMAP */
But SPARSEMEM_VMEMMAP is our default on ppc64 pseries ... and you are
select'ing the new option, so it looks like we are missing something
here...
Can you tell me a bit more, the above makes me nervous...
Cheers,
Ben.
Index: powerpc/arch/powerpc/mm/mem.c
===
--- powerpc.orig/arch/powerpc/mm/mem.c
+++ powerpc/arch/powerpc/mm/mem.c
@@ -297,12 +297,21 @@ void __init paging_init(void)
}
#endif /* ! CONFIG_NEED_MULTIPLE_NODES */
+static void __init register_page_bootmem_info(void)
+{
+ int i;
+
+ for_each_online_node(i)
+ register_page_bootmem_info_node(NODE_DATA(i));
+}
+
void __init mem_init(void)
{
#ifdef CONFIG_SWIOTLB
swiotlb_init(0);
#endif
+ register_page_bootmem_info();
high_memory = (void *) __va(max_low_pfn * PAGE_SIZE);
set_max_mapnr(max_pfn);
free_all_bootmem();
Index: powerpc/mm/Kconfig
===
--- powerpc.orig/mm/Kconfig
+++ powerpc/mm/Kconfig
@@ -183,7 +183,7 @@ config MEMORY_HOTPLUG_SPARSE
config MEMORY_HOTREMOVE
bool Allow for memory hot remove
select MEMORY_ISOLATION
- select HAVE_BOOTMEM_INFO_NODE if X86_64
+ select HAVE_BOOTMEM_INFO_NODE if (X86_64 || PPC64)
depends on MEMORY_HOTPLUG ARCH_ENABLE_MEMORY_HOTREMOVE
depends on MIGRATION
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] cpufreq: pmac64: speed up frequency switch
On Wed, 2013-07-24 at 07:14 +1000, Benjamin Herrenschmidt wrote: On Tue, 2013-07-23 at 23:20 +0200, Rafael J. Wysocki wrote: All looks good in the patchset from 1 feet (or more), but I need Ben to speak here. I want to give it a quick spin on the HW here, I'll ack then. But yes, it looks good. Seems to work here on the quad G5. However, If I use on-demand, there's a huge latency of switch as far as I can tell (about 10s) after I start/stop a bunch of CPU eaters... I quite like how the userspace powernowd which I used to use switches more aggressively. Is that expected ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Failure to detect PCI card
On Thu, 2013-08-08 at 13:31 -0700, Peter LaDow wrote: For those that are interested, we did figure out what was going on. Turns out that the clock buffer driving the PCI connector was, well, less than adequate. With some cards, the load on the clock line was large enough that the clock was in horrible shape. Fixing the clock line and the card that failed to be recognized started working. For the other cards that worked, the load on the clock line was significantly less, but the clock was still marginal. Anyway, turned out to be a hardware issue. Thanks to all that helped! Do that help with e1000 as well ? IE. A bad clock might have caused malfunctions of the DMA for example... Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/3 V4] mmc:core: parse voltage from device-tree
Add function to support get voltage from device-tree.
If there are voltage-range specified in device-tree node, this function
will parse it and return the available voltage mask.
Signed-off-by: Haijun Zhang haijun.zh...@freescale.com
---
changes for V4:
- Add new parameter mask to return voltages.
changes for V3:
- Correct the type of return value.
drivers/mmc/core/core.c | 44
include/linux/mmc/core.h | 2 ++
2 files changed, 46 insertions(+)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 49a5bca..b9b9fb6 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -27,6 +27,7 @@
#include linux/fault-inject.h
#include linux/random.h
#include linux/slab.h
+#include linux/of.h
#include linux/mmc/card.h
#include linux/mmc/host.h
@@ -1196,6 +1197,49 @@ u32 mmc_vddrange_to_ocrmask(int vdd_min, int vdd_max)
}
EXPORT_SYMBOL(mmc_vddrange_to_ocrmask);
+#ifdef CONFIG_OF
+
+/**
+ * mmc_of_parse_voltage - return mask of supported voltages
+ * @np: The device node need to be parsed.
+ * @mask: mask of voltages available for MMC/SD/SDIO
+ *
+ * 1. Return zero on success.
+ * 2. Return negative errno: voltage-range is invalid.
+ */
+int mmc_of_parse_voltage(struct device_node *np, u32 *mask)
+{
+ const u32 *voltage_ranges;
+ int num_ranges, i;
+
+ voltage_ranges = of_get_property(np, voltage-ranges, num_ranges);
+ num_ranges = num_ranges / sizeof(*voltage_ranges) / 2;
+ if (!voltage_ranges || !num_ranges) {
+ pr_info(%s: voltage-ranges unspecified\n, np-full_name);
+ return -EINVAL;
+ }
+
+ for (i = 0; i num_ranges; i++) {
+ const int j = i * 2;
+ u32 ocr_mask;
+
+ ocr_mask = mmc_vddrange_to_ocrmask(
+ be32_to_cpu(voltage_ranges[j]),
+ be32_to_cpu(voltage_ranges[j + 1]));
+ if (!ocr_mask) {
+ pr_err(%s: voltage-range #%d is invalid\n,
+ np-full_name, i);
+ return -EINVAL;
+ }
+ *mask |= ocr_mask;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(mmc_of_parse_voltage);
+
+#endif /* CONFIG_OF */
+
#ifdef CONFIG_REGULATOR
/**
diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h
index 443243b..da51bec 100644
--- a/include/linux/mmc/core.h
+++ b/include/linux/mmc/core.h
@@ -208,6 +208,8 @@ static inline void mmc_claim_host(struct mmc_host *host)
__mmc_claim_host(host, NULL);
}
+struct device_node;
extern u32 mmc_vddrange_to_ocrmask(int vdd_min, int vdd_max);
+extern int mmc_of_parse_voltage(struct device_node *np, u32 *mask);
#endif /* LINUX_MMC_CORE_H */
--
1.8.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V3] mmc:of_spi: Update the code of getting voltage-ranges
Using function mmc_of_parse_voltage() to get voltage-ranges.
Signed-off-by: Haijun Zhang haijun.zh...@freescale.com
---
changes for V3:
- changes the type of ocr_mask and function mmc_of_parse_voltage
drivers/mmc/host/of_mmc_spi.c | 23 +++
1 file changed, 3 insertions(+), 20 deletions(-)
diff --git a/drivers/mmc/host/of_mmc_spi.c b/drivers/mmc/host/of_mmc_spi.c
index d720b5e..fd1928d 100644
--- a/drivers/mmc/host/of_mmc_spi.c
+++ b/drivers/mmc/host/of_mmc_spi.c
@@ -90,8 +90,7 @@ struct mmc_spi_platform_data *mmc_spi_get_pdata(struct
spi_device *spi)
struct device *dev = spi-dev;
struct device_node *np = dev-of_node;
struct of_mmc_spi *oms;
- const u32 *voltage_ranges;
- int num_ranges;
+ u32 ocr_mask;
int i;
int ret = -EINVAL;
@@ -102,26 +101,10 @@ struct mmc_spi_platform_data *mmc_spi_get_pdata(struct
spi_device *spi)
if (!oms)
return NULL;
- voltage_ranges = of_get_property(np, voltage-ranges, num_ranges);
- num_ranges = num_ranges / sizeof(*voltage_ranges) / 2;
- if (!voltage_ranges || !num_ranges) {
- dev_err(dev, OF: voltage-ranges unspecified\n);
+ if (mmc_of_parse_voltage(np, ocr_mask))
goto err_ocr;
- }
-
- for (i = 0; i num_ranges; i++) {
- const int j = i * 2;
- u32 mask;
- mask = mmc_vddrange_to_ocrmask(be32_to_cpu(voltage_ranges[j]),
- be32_to_cpu(voltage_ranges[j +
1]));
- if (!mask) {
- ret = -EINVAL;
- dev_err(dev, OF: voltage-range #%d is invalid\n, i);
- goto err_ocr;
- }
- oms-pdata.ocr_mask |= mask;
- }
+ oms-pdata.ocr_mask |= ocr_mask;
for (i = 0; i ARRAY_SIZE(oms-gpios); i++) {
enum of_gpio_flags gpio_flags;
--
1.8.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/3 V3] mmc:sdhc: get voltage from sdhc host
We use host-ocr_mask to hold the voltage get from device-tree
node, In case host-ocr_mask was available, we use host-ocr_mask
as the final available voltage can be used by MMC/SD/SDIO card.
Signed-off-by: Haijun Zhang haijun.zh...@freescale.com
---
changes for V3:
- changed the type of mask
drivers/mmc/host/sdhci.c | 3 +++
include/linux/mmc/sdhci.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index a78bd4f..57541e0 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -3119,6 +3119,9 @@ int sdhci_add_host(struct sdhci_host *host)
SDHCI_MAX_CURRENT_MULTIPLIER;
}
+ if (host-ocr_mask)
+ ocr_avail = host-ocr_mask;
+
mmc-ocr_avail = ocr_avail;
mmc-ocr_avail_sdio = ocr_avail;
if (host-ocr_avail_sdio)
diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
index e3c6a74..3e781b8 100644
--- a/include/linux/mmc/sdhci.h
+++ b/include/linux/mmc/sdhci.h
@@ -171,6 +171,7 @@ struct sdhci_host {
unsigned intocr_avail_sdio; /* OCR bit masks */
unsigned intocr_avail_sd;
unsigned intocr_avail_mmc;
+ u32 ocr_mask; /* available voltages */
wait_queue_head_t buf_ready_int; /* Waitqueue for Buffer Read
Ready interrupt */
unsigned inttuning_done;/* Condition flag set when
CMD19 succeeds */
--
1.8.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/3 V3] mmc:esdhc: add support to get voltage from device-tree
Add suppport to get voltage from device-tree node for esdhc host, if voltage-ranges was specified in device-tree node we can get ocr_mask instead of read from host capacity register. If not voltages still can be get from host capacity register. Signed-off-by: Haijun Zhang haijun.zh...@freescale.com --- changes for V3: - changed the parameter of function drivers/mmc/host/sdhci-of-esdhc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c index 15039e2..e328252 100644 --- a/drivers/mmc/host/sdhci-of-esdhc.c +++ b/drivers/mmc/host/sdhci-of-esdhc.c @@ -316,6 +316,7 @@ static int sdhci_esdhc_probe(struct platform_device *pdev) /* call to generic mmc_of_parse to support additional capabilities */ mmc_of_parse(host-mmc); + mmc_of_parse_voltage(np, host-ocr_mask); ret = sdhci_add_host(host); if (ret) -- 1.8.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/7] powerpc/perf: Define big-endian version of perf_mem_data_src
On Mon, 12 Aug 2013, Michael Ellerman wrote: Yes I think so. The interface is already defined and it's little endian, so on big endian we just need to swap. The only part I'm not clear on is how things are handled in perf userspace, it seems to already do some byte swapping. It would be nice to clarify this. struct perf_branch_entry also has bitfields like this, though to make things more confusing that structure isn't exported via the uapi header so it's not clear how userspace code is supposed to interpret the values. As you say it gets complicated with perf userspace, especially in cases where you record the data on big-endian but then try to analyze the results on a little-endian machine. It would be nice to get confirmation that these bitfields will always be little-endian. I guess they currently are by definition because only x86/pebs sets data.data_src.val so far? Vince ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3 V2] mmc:core: parse voltage from device-tree
On 08/09/2013 10:48 PM, Kumar Gala wrote: On Jul 31, 2013, at 1:25 AM, Haijun Zhang wrote: Add function to support get voltage from device-tree. If there are voltage-range specified in device-tree node, this function will parse it and return the avail voltage mask. Signed-off-by: Haijun Zhang haijun.zh...@freescale.com --- changes for v2: - Update the parameters of function drivers/mmc/core/core.c | 46 ++ include/linux/mmc/core.h | 1 + 2 files changed, 47 insertions(+) There should be a device tree binding spec update to go with this patch series. - k Hi, kumar I'll update this tree binding spec after the patch set is accept by Anton. -- Thanks Regards Haijun ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: Pull out cpu_core_mask updates into a separate function
Hi Paul, On Sat, 10 Aug 2013 13:45:30 +1000 Paul Mackerras pau...@samba.org wrote: This factors out the details of updating cpu_core_mask into a separate function, to make it easier to change how the mask is calculated later. This makes no functional change. Signed-off-by: Paul Mackerras pau...@samba.org --- arch/powerpc/kernel/smp.c | 56 +++ 1 file changed, 28 insertions(+), 28 deletions(-) diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c index 38b0ba6..663cefd 100644 --- a/arch/powerpc/kernel/smp.c +++ b/arch/powerpc/kernel/smp.c @@ -609,11 +609,36 @@ static struct device_node *cpu_to_l2cache(int cpu) return cache; } +static void traverse_core_siblings(int cpu, int add) This add parameter is only used as a boolean, so should be declared that way. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpR0OW4Uggnu.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: Use ibm,chip-id property to compute cpu_core_mask if available
Hi Paul,
On Sat, 10 Aug 2013 13:46:15 +1000 Paul Mackerras pau...@samba.org wrote:
+static void traverse_siblings_chip_id(int cpu, int add, int chipid)
Again, the add is a boolean.
+{
+ const struct cpumask *mask;
+ struct device_node *np;
+ int i, plen;
+ const int *prop;
+
+ mask = add ? cpu_online_mask : cpu_present_mask;
+ for_each_cpu(i, mask) {
+ np = of_get_cpu_node(i, NULL);
+ if (!np)
+ continue;
+ prop = of_get_property(np, ibm,chip-id, plen);
+ if (prop plen == sizeof(int) *prop == chipid) {
^
You should be using of_read_number(), I think.
static void traverse_core_siblings(int cpu, int add)
{
- struct device_node *l2_cache;
+ struct device_node *l2_cache, *np;
const struct cpumask *mask;
- int i;
+ int i, chip, plen;
+ const int *prop;
+
+ /* First see if we have ibm,chip-id properties in cpu nodes */
+ np = of_get_cpu_node(cpu, NULL);
+ if (np) {
+ chip = -1;
+ prop = of_get_property(np, ibm,chip-id, plen);
+ if (prop plen == sizeof(int))
+ chip = *(int *)prop;
Here as well.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpMsT6pk8KlA.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Build errors on mainline kernel
On Fri, 2013-08-09 at 11:24 -0700, Sukadev Bhattiprolu wrote:
I am tryng to compile clean mainline kernel with a few different config files
and running into errors with some configs.
I am building on RHEL6.3 with following binaries:
gcc (GCC) 4.4.6 20120305 (Red Hat 4.4.6-4)
GNU ld version 2.20.51.0.2-5.34.el6 20100205
binutils-2.20.51.0.2-5.34.el6.ppc64
binutils-devel-2.20.51.0.2-5.34.el6.ppc64
I am getting the error with several files and configs, but other configs
(eg: ppc64_defconfig, pmac32_defconfig) build fine.
For instance, with latest mainline kernel (commit 6c2580c) and
ppc64_defconfig, I get:
Here you say ppc64_defconfig ..
make O=linux-obj mrproper
make O=linux-obj ppc64e_defconfig
But here you say ppc64e_defconfig ?
make O=linux-obj arch/powerpc/platforms/85xx/smp.o
...
CC arch/powerpc/platforms/85xx/smp.o
{standard input}: Assembler messages:
{standard input}:240: Error: junk at end of line: `1'
make[2]: *** [arch/powerpc/platforms/85xx/smp.o] Error 1
make[1]: *** [arch/powerpc/platforms/85xx/smp.o] Error 2
So I'm not clear which config you're building.
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
