Re: [PATCH 0/5] kexec: minor fixups and enhancements
On 08/25/14 at 12:59pm, Vivek Goyal wrote: On Fri, Aug 22, 2014 at 06:39:47PM +, Geoff Levand wrote: Hi, Here are a few minor fixups and enhancements for kexec support. Patch 3 and 4 that add preprocessor macros for the kimage list flags are ones that I use in the arm64 kexec support I am working on, so it would be nice for those to go in. Please consider. Hi Geoff, Does arm64 has secureboot? If yes, then it might make sense to enable the new syscall kexec_file_load() on arm64 instead of trying to make old syscall work first. It will save efforts for efi support as well, for the in-kernel loader we do not necessary to save the efi physical addresses or runtime ranges to sysfs and passing them to 2nd kernel, we can just copy them in kernel. Thanks Dave ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/4] powerpc/eeh: Introduce eeh_ops::err_inject
From: Mike Qiu qiud...@linux.vnet.ibm.com
The patch introduces eeh_ops::err_inject(), which allows to inject
specified errors to indicated PE for testing purpose. The functionality
isn't support on pSeries platform. On PowerNV, the functionality
relies on OPAL API opal_pci_err_inject().
Signed-off-by: Mike Qiu qiud...@linux.vnet.ibm.com
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/eeh.h | 2 ++
arch/powerpc/platforms/powernv/eeh-ioda.c| 38
arch/powerpc/platforms/powernv/eeh-powernv.c | 26 +++
arch/powerpc/platforms/powernv/pci.h | 2 ++
arch/powerpc/platforms/pseries/eeh_pseries.c | 1 +
5 files changed, 69 insertions(+)
diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
index f98b1b5..1951d07 100644
--- a/arch/powerpc/include/asm/eeh.h
+++ b/arch/powerpc/include/asm/eeh.h
@@ -199,6 +199,8 @@ struct eeh_ops {
int (*wait_state)(struct eeh_pe *pe, int max_wait);
int (*get_log)(struct eeh_pe *pe, int severity, char *drv_log, unsigned
long len);
int (*configure_bridge)(struct eeh_pe *pe);
+ int (*err_inject)(struct eeh_pe *pe, int type, int function,
+ unsigned long addr, unsigned long mask);
int (*read_config)(struct device_node *dn, int where, int size, u32
*val);
int (*write_config)(struct device_node *dn, int where, int size, u32
val);
int (*next_error)(struct eeh_pe **pe);
diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c
b/arch/powerpc/platforms/powernv/eeh-ioda.c
index f3027b9..18099c5 100644
--- a/arch/powerpc/platforms/powernv/eeh-ioda.c
+++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
@@ -673,6 +673,43 @@ static int ioda_eeh_configure_bridge(struct eeh_pe *pe)
return 0;
}
+static int ioda_eeh_err_inject(struct eeh_pe *pe, int type, int function,
+ unsigned long addr, unsigned long mask)
+{
+ struct pci_controller *hose = pe-phb;
+ struct pnv_phb *phb = hose-private_data;
+ s64 ret;
+
+ /* Sanity check on error type */
+ if (type OpalErrinjctTypeIoaBusError ||
+ type OpalErrinjctTypeIoaBusError64 ||
+ function OpalEjtIoaLoadMemAddr ||
+ function OpalEjtIoaDmaWriteMemTarget) {
+ pr_warn(%s: Invalid error type %d-%d\n,
+ __func__, type, function);
+ return -ERANGE;
+ }
+
+ /* Firmware supports error injection ? */
+ ret = opal_check_token(OPAL_PCI_ERR_INJCT);
+ if (ret != OPAL_TOKEN_PRESENT) {
+ pr_warn(%s: Firmware not support error injection (%lld)\n,
+ __func__, ret);
+ return -ENXIO;
+ }
+
+ /* Do error injection */
+ ret = opal_pci_err_inject(phb-opal_id, pe-addr,
+ type, function, addr, mask);
+ if (ret != OPAL_SUCCESS) {
+ pr_warn(%s: Failure %lld injecting error to PHB#%x-PE#%x\n,
+ __func__, ret, hose-global_number, pe-addr);
+ return -EIO;
+ }
+
+ return 0;
+}
+
static void ioda_eeh_hub_diag_common(struct OpalIoP7IOCErrorData *data)
{
/* GEM */
@@ -994,5 +1031,6 @@ struct pnv_eeh_ops ioda_eeh_ops = {
.reset = ioda_eeh_reset,
.get_log= ioda_eeh_get_log,
.configure_bridge = ioda_eeh_configure_bridge,
+ .err_inject = ioda_eeh_err_inject,
.next_error = ioda_eeh_next_error
};
diff --git a/arch/powerpc/platforms/powernv/eeh-powernv.c
b/arch/powerpc/platforms/powernv/eeh-powernv.c
index fd7a16f..f5b1424 100644
--- a/arch/powerpc/platforms/powernv/eeh-powernv.c
+++ b/arch/powerpc/platforms/powernv/eeh-powernv.c
@@ -359,6 +359,31 @@ static int powernv_eeh_configure_bridge(struct eeh_pe *pe)
}
/**
+ * powernv_pe_err_inject - Inject specified error to the indicated PE
+ * @pe: the indicated PE
+ * @type: error type
+ * @function: specific error type
+ * @addr: address
+ * @mask: address mask
+ *
+ * The routine is called to inject specified error, which is
+ * determined by @type and @function, to the indicated PE for
+ * testing purpose.
+ */
+static int powernv_eeh_err_inject(struct eeh_pe *pe, int type, int function,
+ unsigned long addr, unsigned long mask)
+{
+ struct pci_controller *hose = pe-phb;
+ struct pnv_phb *phb = hose-private_data;
+ int ret = -EEXIST;
+
+ if (phb-eeh_ops phb-eeh_ops-err_inject)
+ ret = phb-eeh_ops-err_inject(pe, type, function, addr, mask);
+
+ return ret;
+}
+
+/**
* powernv_eeh_next_error - Retrieve next EEH error to handle
* @pe: Affected PE
*
@@ -414,6 +439,7 @@ static struct eeh_ops powernv_eeh_ops = {
.wait_state = powernv_eeh_wait_state,
.get_log=
[PATCH 0/4] powerpc/eeh: More precisely error injection
Previously, we inject PCI errors through various debugfs entries in /sys/kernel/debug/powerpc/PCI/. Unfortunately, the PCI errors are injected with PHB granularity. It's hard to injection errors to specified PE. The series of patches adds one more debugfs entry, which allows to inject errors to specified PE for testing purpose. echo pe_no:0:function:0:0 /sys/kernel/debug/powerpc/PCI/err_injct The frequently used function would be: 0 : MMIO read 4 : CFG read 6 : MMIO write 10: CFG write Gavin Shan (1): powerpc/powernv: Clear PAPR error injection registers Mike Qiu (3): powerpc/powernv: Sync header with firmware powerpc/eeh: Introduce eeh_ops::err_inject powerpc/powernv: Add error injection debugfs entry arch/powerpc/include/asm/eeh.h | 2 + arch/powerpc/include/asm/opal.h| 30 +++ arch/powerpc/platforms/powernv/eeh-ioda.c | 115 + arch/powerpc/platforms/powernv/eeh-powernv.c | 26 ++ arch/powerpc/platforms/powernv/opal-wrappers.S | 1 + arch/powerpc/platforms/powernv/pci.h | 2 + arch/powerpc/platforms/pseries/eeh_pseries.c | 1 + 7 files changed, 177 insertions(+) -- 1.8.3.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/4] powerpc/powernv: Add error injection debugfs entry
From: Mike Qiu qiud...@linux.vnet.ibm.com
The patch adds debugfs file (/sys/kernel/debug/powerpc/PCI/
err_injct), which accepts following formated string, to support
error injection. It will be used to support userland utility
errinjct in future.
pe_no:0:function:address:mask - 32-bits PCI errors
pe_no:1:function:address:mask - 64-bits PCI errors
Signed-off-by: Mike Qiu qiud...@linux.vnet.ibm.com
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/eeh-ioda.c | 52 +++
1 file changed, 52 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c
b/arch/powerpc/platforms/powernv/eeh-ioda.c
index 18099c5..4d40093 100644
--- a/arch/powerpc/platforms/powernv/eeh-ioda.c
+++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
@@ -66,6 +66,54 @@ static struct notifier_block ioda_eeh_nb = {
};
#ifdef CONFIG_DEBUG_FS
+static ssize_t ioda_eeh_ei_write(struct file *filp,
+const char __user *user_buf,
+size_t count, loff_t *ppos)
+{
+ struct pci_controller *hose = filp-private_data;
+ struct pnv_phb *phb = hose-private_data;
+ struct eeh_dev *edev;
+ struct eeh_pe *pe;
+ int pe_no, type, func;
+ unsigned long addr, mask;
+ char buf[50];
+ int ret;
+
+ if (!phb-eeh_ops || !phb-eeh_ops-err_inject)
+ return -ENXIO;
+
+ ret = simple_write_to_buffer(buf, sizeof(buf), ppos, user_buf, count);
+ if (!ret)
+ return -EFAULT;
+
+ /* Retrieve parameters */
+ ret = sscanf(buf, %x:%x:%x:%lx:%lx,
+pe_no, type, func, addr, mask);
+ if (ret != 5)
+ return -EINVAL;
+
+ /* Retrieve PE */
+ edev = kzalloc(sizeof(*edev), GFP_KERNEL);
+ if (!edev)
+ return -ENOMEM;
+ edev-phb = hose;
+ edev-pe_config_addr = pe_no;
+ pe = eeh_pe_get(edev);
+ kfree(edev);
+ if (!pe)
+ return -ENODEV;
+
+ /* Do error injection */
+ ret = phb-eeh_ops-err_inject(pe, type, func, addr, mask);
+ return ret 0 ? ret : count;
+}
+
+static const struct file_operations ioda_eeh_ei_fops = {
+ .open = simple_open,
+ .llseek = no_llseek,
+ .write = ioda_eeh_ei_write,
+};
+
static int ioda_eeh_dbgfs_set(void *data, int offset, u64 val)
{
struct pci_controller *hose = data;
@@ -152,6 +200,10 @@ static int ioda_eeh_post_init(struct pci_controller *hose)
if (!phb-has_dbgfs phb-dbgfs) {
phb-has_dbgfs = 1;
+ debugfs_create_file(err_injct, 0200,
+ phb-dbgfs, hose,
+ ioda_eeh_ei_fops);
+
debugfs_create_file(err_injct_outbound, 0600,
phb-dbgfs, hose,
ioda_eeh_outb_dbgfs_ops);
--
1.8.3.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/4] powerpc/powernv: Clear PAPR error injection registers
The frozen state on one specific PE is probably caused by error
injection, which is done with help of PAPR error injection registers.
According to the hardware spec, those registers should be cleared
automatically after one-shot frozen PE. However, that's not always
true, at least on P7IOC of Firebird-L. So we have to clear them
before doing PE reset to avoid recursive EEH errors at recovery
stage.
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/eeh-ioda.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c
b/arch/powerpc/platforms/powernv/eeh-ioda.c
index 4d40093..729e445 100644
--- a/arch/powerpc/platforms/powernv/eeh-ioda.c
+++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
@@ -682,6 +682,31 @@ static int ioda_eeh_reset(struct eeh_pe *pe, int option)
if (pe-type EEH_PE_PHB) {
ret = ioda_eeh_phb_reset(hose, option);
} else {
+ struct pnv_phb *phb;
+ s64 rc;
+
+ /*
+* The frozen PE might be caused by PAPR error injection
+* registers, which are expected to be cleared after hitting
+* frozen PE as stated in the hardware spec. Unfortunately,
+* that's not true on P7IOC. So we have to clear it manually
+* to avoid recursive EEH errors during recovery.
+*/
+ phb = hose-private_data;
+ if (phb-model == PNV_PHB_MODEL_P7IOC
+ (option == EEH_RESET_HOT ||
+ option == EEH_RESET_FUNDAMENTAL)) {
+ rc = opal_pci_reset(phb-opal_id,
+ OPAL_PHB_ERROR,
+ OPAL_ASSERT_RESET);
+ if (rc != OPAL_SUCCESS) {
+ pr_warn(%s: Failure %lld clearing
+ error injection registers\n,
+ __func__, rc);
+ return -EIO;
+ }
+ }
+
bus = eeh_pe_bus_get(pe);
if (pci_is_root_bus(bus) ||
pci_is_root_bus(bus-parent))
--
1.8.3.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/4] powerpc/powernv: Sync header with firmware
From: Mike Qiu qiud...@linux.vnet.ibm.com
The patch synchronizes firmware header file (opal.h) for PCI error
injection.
Signed-off-by: Mike Qiu qiud...@linux.vnet.ibm.com
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h| 30 ++
arch/powerpc/platforms/powernv/opal-wrappers.S | 1 +
2 files changed, 31 insertions(+)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 4593a93..9113653 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -148,6 +148,7 @@ struct opal_sg_list {
#define OPAL_SET_PARAM 90
#define OPAL_DUMP_RESEND 91
#define OPAL_DUMP_INFO294
+#define OPAL_PCI_ERR_INJCT 96
#define OPAL_PCI_EEH_FREEZE_SET97
#define OPAL_HANDLE_HMI98
#define OPAL_REGISTER_DUMP_REGION 101
@@ -200,6 +201,33 @@ enum OpalPciErrorSeverity {
OPAL_EEH_SEV_INF= 5
};
+enum OpalErrinjctType {
+ OpalErrinjctTypeIoaBusError = 0,
+ OpalErrinjctTypeIoaBusError64 = 1,
+
+ /* IoaBusError IoaBusError64 */
+ OpalEjtIoaLoadMemAddr = 0,
+ OpalEjtIoaLoadMemData = 1,
+ OpalEjtIoaLoadIoAddr= 2,
+ OpalEjtIoaLoadIoData= 3,
+ OpalEjtIoaLoadConfigAddr= 4,
+ OpalEjtIoaLoadConfigData= 5,
+ OpalEjtIoaStoreMemAddr = 6,
+ OpalEjtIoaStoreMemData = 7,
+ OpalEjtIoaStoreIoAddr = 8,
+ OpalEjtIoaStoreIoData = 9,
+ OpalEjtIoaStoreConfigAddr = 10,
+ OpalEjtIoaStoreConfigData = 11,
+ OpalEjtIoaDmaReadMemAddr= 12,
+ OpalEjtIoaDmaReadMemData= 13,
+ OpalEjtIoaDmaReadMemMaster = 14,
+ OpalEjtIoaDmaReadMemTarget = 15,
+ OpalEjtIoaDmaWriteMemAddr = 16,
+ OpalEjtIoaDmaWriteMemData = 17,
+ OpalEjtIoaDmaWriteMemMaster = 18,
+ OpalEjtIoaDmaWriteMemTarget = 19,
+};
+
enum OpalShpcAction {
OPAL_SHPC_GET_LINK_STATE = 0,
OPAL_SHPC_GET_SLOT_STATE = 1
@@ -825,6 +853,8 @@ int64_t opal_pci_eeh_freeze_clear(uint64_t phb_id, uint64_t
pe_number,
uint64_t eeh_action_token);
int64_t opal_pci_eeh_freeze_set(uint64_t phb_id, uint64_t pe_number,
uint64_t eeh_action_token);
+int64_t opal_pci_err_inject(uint64_t phb_id, uint32_t pe_no, uint32_t type,
+ uint32_t function, uint64_t addr, uint64_t mask);
int64_t opal_pci_shpc(uint64_t phb_id, uint64_t shpc_action, uint8_t *state);
diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S
b/arch/powerpc/platforms/powernv/opal-wrappers.S
index 5718855..9c68501 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -184,6 +184,7 @@ OPAL_CALL(opal_register_exception_handler,
OPAL_REGISTER_OPAL_EXCEPTION_HANDLER)
OPAL_CALL(opal_pci_eeh_freeze_status, OPAL_PCI_EEH_FREEZE_STATUS);
OPAL_CALL(opal_pci_eeh_freeze_clear, OPAL_PCI_EEH_FREEZE_CLEAR);
OPAL_CALL(opal_pci_eeh_freeze_set, OPAL_PCI_EEH_FREEZE_SET);
+OPAL_CALL(opal_pci_err_inject, OPAL_PCI_ERR_INJCT);
OPAL_CALL(opal_pci_shpc, OPAL_PCI_SHPC);
OPAL_CALL(opal_pci_phb_mmio_enable,OPAL_PCI_PHB_MMIO_ENABLE);
OPAL_CALL(opal_pci_set_phb_mem_window, OPAL_PCI_SET_PHB_MEM_WINDOW);
--
1.8.3.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: Fix warning reported by verify_cpu_node_mapping()
Hi Nathan,
On 26.08.2014 [08:10:14 -0500], Nathan Fontenot wrote:
On 08/25/2014 02:22 AM, Li Zhong wrote:
With commit 2fabf084b, during boottime, cpu_numa_callback() is called
earlier(before their online) for each cpu, and verify_cpu_node_mapping()
uses cpu_to_node() to check whether siblings are in the same node.
It skips the checking for siblings that are not online yet. So the only
check done here is for the bootcpu, which is online at that time. But
the per-cpu numa_node cpu_to_node() uses hasn't been set up yet (which
will be set up in smp_prepare_cpus()).
So I saw something like following reported:
[0.00] CPU thread siblings 1/2/3 and 0 don't belong to the same
node!
As we don't actually do the checking during this early stage, so maybe
we could directly call numa_setup_cpu() in do_init_bootmem().
Also, as Nish suggested, here it's better to use present cpu mask
instead of possible mask to avoid warning in numa_setup_cpu().
Signed-off-by: Li Zhong zh...@linux.vnet.ibm.com
---
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index d7737a5..3a9061e 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -1127,9 +1127,8 @@ void __init do_init_bootmem(void)
* even before we online them, so that we can use cpu_to_{node,mem}
* early in boot, cf. smp_prepare_cpus().
*/
- for_each_possible_cpu(cpu) {
- cpu_numa_callback(ppc64_numa_nb, CPU_UP_PREPARE,
- (void *)(unsigned long)cpu);
+ for_each_present_cpu(cpu) {
+ numa_setup_cpu((unsigned long)cpu);
}
}
I am getting the following error on my system booting with this patch.
With the patch below, you don't get the error, I assume? Does it boot
fully in that case?
-Nish
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] fsl_ifc: Support all 8 IFC chip selects
Freescale's QorIQ T Series processors support 8 IFC chip selects
within a memory map backward compatible with previous P Series
processors which supported only 4 chip selects.
Signed-off-by: Aaron Sierra asie...@xes-inc.com
---
drivers/memory/fsl_ifc.c| 2 +-
drivers/mtd/nand/fsl_ifc_nand.c | 17 ++---
include/linux/fsl_ifc.h | 34 +-
3 files changed, 36 insertions(+), 17 deletions(-)
diff --git a/drivers/memory/fsl_ifc.c b/drivers/memory/fsl_ifc.c
index 3d5d792..a539dc2 100644
--- a/drivers/memory/fsl_ifc.c
+++ b/drivers/memory/fsl_ifc.c
@@ -61,7 +61,7 @@ int fsl_ifc_find(phys_addr_t addr_base)
if (!fsl_ifc_ctrl_dev || !fsl_ifc_ctrl_dev-regs)
return -ENODEV;
- for (i = 0; i ARRAY_SIZE(fsl_ifc_ctrl_dev-regs-cspr_cs); i++) {
+ for (i = 0; i fsl_ifc_bank_count(fsl_ifc_ctrl_dev-regs); i++) {
u32 cspr = in_be32(fsl_ifc_ctrl_dev-regs-cspr_cs[i].cspr);
if (cspr CSPR_V (cspr CSPR_BA) ==
convert_ifc_address(addr_base))
diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
index 2338124..f7b7077 100644
--- a/drivers/mtd/nand/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/fsl_ifc_nand.c
@@ -31,7 +31,6 @@
#include linux/mtd/nand_ecc.h
#include linux/fsl_ifc.h
-#define FSL_IFC_V1_1_0 0x0101
#define ERR_BYTE 0xFF /* Value returned for read
bytes when read failed */
#define IFC_TIMEOUT_MSECS 500 /* Maximum number of mSecs to wait
@@ -54,7 +53,7 @@ struct fsl_ifc_mtd {
/* overview of the fsl ifc controller */
struct fsl_ifc_nand_ctrl {
struct nand_hw_control controller;
- struct fsl_ifc_mtd *chips[FSL_IFC_BANK_COUNT];
+ struct fsl_ifc_mtd *chips[FSL_IFC_BANK_COUNT_MAX];
void __iomem *addr; /* Address of assigned IFC buffer */
unsigned int page; /* Last page written to / read from */
@@ -877,7 +876,7 @@ static int fsl_ifc_chip_init(struct fsl_ifc_mtd *priv)
struct fsl_ifc_regs __iomem *ifc = ctrl-regs;
struct nand_chip *chip = priv-chip;
struct nand_ecclayout *layout;
- u32 csor, ver;
+ u32 csor;
/* Fill in fsl_ifc_mtd structure */
priv-mtd.priv = chip;
@@ -984,8 +983,7 @@ static int fsl_ifc_chip_init(struct fsl_ifc_mtd *priv)
chip-ecc.mode = NAND_ECC_SOFT;
}
- ver = ioread32be(ifc-ifc_rev);
- if (ver == FSL_IFC_V1_1_0)
+ if (fsl_ifc_version(ifc) == FSL_IFC_VERSION_1_1_0)
fsl_ifc_sram_init(priv);
return 0;
@@ -1044,13 +1042,18 @@ static int fsl_ifc_nand_probe(struct platform_device
*dev)
return ret;
}
+ dev_info(dev-dev, IFC version %d.%d, %d banks\n,
+ fsl_ifc_version(ifc) 24,
+ (fsl_ifc_version(ifc) 16) 0xf,
+ fsl_ifc_bank_count(ifc));
+
/* find which chip select it is connected to */
- for (bank = 0; bank FSL_IFC_BANK_COUNT; bank++) {
+ for (bank = 0; bank fsl_ifc_bank_count(ifc); bank++) {
if (match_bank(ifc, bank, res.start))
break;
}
- if (bank = FSL_IFC_BANK_COUNT) {
+ if (bank = fsl_ifc_bank_count(ifc)) {
dev_err(dev-dev, %s: address did not match any chip
selects\n,
__func__);
return -ENODEV;
diff --git a/include/linux/fsl_ifc.h b/include/linux/fsl_ifc.h
index 84d60cb..7a92773 100644
--- a/include/linux/fsl_ifc.h
+++ b/include/linux/fsl_ifc.h
@@ -29,7 +29,16 @@
#include linux/of_platform.h
#include linux/interrupt.h
-#define FSL_IFC_BANK_COUNT 4
+/*
+ * The actual number of banks implemented depends on the IFC version
+ *- IFC version 1.0 implements 4 banks.
+ *- IFC version 1.1 onward implements 8 banks.
+ */
+#define FSL_IFC_BANK_COUNT_MAX 8
+
+#define FSL_IFC_VERSION_MASK 0x0F0F
+#define FSL_IFC_VERSION_1_0_0 0x0100
+#define FSL_IFC_VERSION_1_1_0 0x0101
/*
* CSPR - Chip Select Property Register
@@ -775,24 +784,24 @@ struct fsl_ifc_regs {
__be32 cspr_ext;
__be32 cspr;
u32 res2;
- } cspr_cs[FSL_IFC_BANK_COUNT];
- u32 res3[0x19];
+ } cspr_cs[FSL_IFC_BANK_COUNT_MAX];
+ u32 res3[0xd];
struct {
__be32 amask;
u32 res4[0x2];
- } amask_cs[FSL_IFC_BANK_COUNT];
- u32 res5[0x18];
+ } amask_cs[FSL_IFC_BANK_COUNT_MAX];
+ u32 res5[0xc];
struct {
__be32 csor;
__be32 csor_ext;
u32 res6;
- } csor_cs[FSL_IFC_BANK_COUNT];
- u32 res7[0x18];
+ } csor_cs[FSL_IFC_BANK_COUNT_MAX];
+ u32 res7[0xc];
struct {
__be32 ftim[4];
u32 res8[0x8];
- } ftim_cs[FSL_IFC_BANK_COUNT];
- u32 res9[0x60];
+
Re: [PATCH v2] fsl_ifc: Support all 8 IFC chip selects
On Tue, 2014-08-26 at 12:31 -0500, Aaron Sierra wrote:
Freescale's QorIQ T Series processors support 8 IFC chip selects
within a memory map backward compatible with previous P Series
processors which supported only 4 chip selects.
Signed-off-by: Aaron Sierra asie...@xes-inc.com
---
drivers/memory/fsl_ifc.c| 2 +-
drivers/mtd/nand/fsl_ifc_nand.c | 17 ++---
include/linux/fsl_ifc.h | 34 +-
3 files changed, 36 insertions(+), 17 deletions(-)
diff --git a/drivers/memory/fsl_ifc.c b/drivers/memory/fsl_ifc.c
index 3d5d792..a539dc2 100644
--- a/drivers/memory/fsl_ifc.c
+++ b/drivers/memory/fsl_ifc.c
@@ -61,7 +61,7 @@ int fsl_ifc_find(phys_addr_t addr_base)
if (!fsl_ifc_ctrl_dev || !fsl_ifc_ctrl_dev-regs)
return -ENODEV;
- for (i = 0; i ARRAY_SIZE(fsl_ifc_ctrl_dev-regs-cspr_cs); i++) {
+ for (i = 0; i fsl_ifc_bank_count(fsl_ifc_ctrl_dev-regs); i++) {
u32 cspr = in_be32(fsl_ifc_ctrl_dev-regs-cspr_cs[i].cspr);
if (cspr CSPR_V (cspr CSPR_BA) ==
convert_ifc_address(addr_base))
diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
index 2338124..f7b7077 100644
--- a/drivers/mtd/nand/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/fsl_ifc_nand.c
@@ -31,7 +31,6 @@
#include linux/mtd/nand_ecc.h
#include linux/fsl_ifc.h
-#define FSL_IFC_V1_1_0 0x0101
#define ERR_BYTE 0xFF /* Value returned for read
bytes when read failed */
#define IFC_TIMEOUT_MSECS500 /* Maximum number of mSecs to wait
@@ -54,7 +53,7 @@ struct fsl_ifc_mtd {
/* overview of the fsl ifc controller */
struct fsl_ifc_nand_ctrl {
struct nand_hw_control controller;
- struct fsl_ifc_mtd *chips[FSL_IFC_BANK_COUNT];
+ struct fsl_ifc_mtd *chips[FSL_IFC_BANK_COUNT_MAX];
FSL_IFC_MAX_BANKS would be more concise. I'm not sure we really need to
rename this, though.
@@ -834,5 +843,12 @@ struct fsl_ifc_ctrl {
extern struct fsl_ifc_ctrl *fsl_ifc_ctrl_dev;
+static inline u32 fsl_ifc_version(struct fsl_ifc_regs *regs) {
+ return ioread32be(regs-ifc_rev) FSL_IFC_VERSION_MASK;
+}
+
+static inline int fsl_ifc_bank_count(struct fsl_ifc_regs *regs) {
+ return (fsl_ifc_version(regs) == FSL_IFC_VERSION_1_0_0) ? 4 : 8;
+}
Whitespace
Do we really need the bank count here, as opposed to just checking it in
probe()? I also don't really care for reading the registers over and
over, even though it's not performance critical.
The reserved bits of the version register are defined as zero for
current versions -- I think just comparing ifc_rev to the version
constant, as is currently done, is fine.
Also, please send the patch to the mtd list and maintainer.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: fsl_pci: Add forced PCI Agent enumeration
On Mon, 2014-08-25 at 18:54 -0500, Aaron Sierra wrote: The following commit prevents the MPC8548E on the XPedite5200 PrPMC module from enumerating its PCI/PCI-X bus: powerpc/fsl-pci: use 'Header Type' to identify PCIE mode The previous patch prevents any Freescale PCI-X bridge from enumerating the bus, if it is hardware strapped into Agent mode. In PCI-X, the Host is responsible for driving the PCI-X initialization pattern to devices on the bus, so that they know whether to operate in conventional PCI or PCI-X mode as well as what the bus timing will be. For a PCI-X PrPMC, the pattern is driven by the mezzanine carrier it is installed onto. Therefore, PrPMCs are PCI-X Agents, but one per system may still enumerate the bus. This patch causes the device node of any PCI/PCI-X bridge strapped into Agent mode to be checked for the fsl,pci-agent-force-enum property. If the property is present in the node, the bridge will be allowed to enumerate the bus. Cc: Minghuan Lian minghuan.l...@freescale.com Signed-off-by: Aaron Sierra asie...@xes-inc.com --- .../bindings/pci/fsl,pci-agent-force-enum.txt | 27 ++ arch/powerpc/sysdev/fsl_pci.c | 3 ++- 2 files changed, 29 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/pci/fsl,pci-agent-force-enum.txt diff --git a/Documentation/devicetree/bindings/pci/fsl,pci-agent-force-enum.txt b/Documentation/devicetree/bindings/pci/fsl,pci-agent-force-enum.txt new file mode 100644 index 000..d8ac4a7 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/fsl,pci-agent-force-enum.txt This ought to be part of a general fsl,pci binding, rather than its own file. Unfortunately there isn't such a binding yet, but let's call this something like fsl,pci.txt anyway so that there's a place to add the rest of the binding to. Also, CC devicet...@vger.kernel.org on all device tree patches. Otherwise it looks OK. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: fsl_pci: Add forced PCI Agent enumeration
- Original Message - From: Scott Wood scottw...@freescale.com Sent: Tuesday, August 26, 2014 3:52:56 PM On Mon, 2014-08-25 at 18:54 -0500, Aaron Sierra wrote: The following commit prevents the MPC8548E on the XPedite5200 PrPMC module from enumerating its PCI/PCI-X bus: powerpc/fsl-pci: use 'Header Type' to identify PCIE mode The previous patch prevents any Freescale PCI-X bridge from enumerating the bus, if it is hardware strapped into Agent mode. In PCI-X, the Host is responsible for driving the PCI-X initialization pattern to devices on the bus, so that they know whether to operate in conventional PCI or PCI-X mode as well as what the bus timing will be. For a PCI-X PrPMC, the pattern is driven by the mezzanine carrier it is installed onto. Therefore, PrPMCs are PCI-X Agents, but one per system may still enumerate the bus. This patch causes the device node of any PCI/PCI-X bridge strapped into Agent mode to be checked for the fsl,pci-agent-force-enum property. If the property is present in the node, the bridge will be allowed to enumerate the bus. Cc: Minghuan Lian minghuan.l...@freescale.com Signed-off-by: Aaron Sierra asie...@xes-inc.com --- .../bindings/pci/fsl,pci-agent-force-enum.txt | 27 ++ arch/powerpc/sysdev/fsl_pci.c | 3 ++- 2 files changed, 29 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/pci/fsl,pci-agent-force-enum.txt diff --git a/Documentation/devicetree/bindings/pci/fsl,pci-agent-force-enum.txt b/Documentation/devicetree/bindings/pci/fsl,pci-agent-force-enum.txt new file mode 100644 index 000..d8ac4a7 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/fsl,pci-agent-force-enum.txt This ought to be part of a general fsl,pci binding, rather than its own file. Unfortunately there isn't such a binding yet, but let's call this something like fsl,pci.txt anyway so that there's a place to add the rest of the binding to. Ok, no problem. Also, CC devicet...@vger.kernel.org on all device tree patches. Will do. Otherwise it looks OK. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] fsl_ifc: Support all 8 IFC chip selects
- Original Message -
From: Scott Wood scottw...@freescale.com
Sent: Tuesday, August 26, 2014 3:48:51 PM
On Tue, 2014-08-26 at 12:31 -0500, Aaron Sierra wrote:
Freescale's QorIQ T Series processors support 8 IFC chip selects
within a memory map backward compatible with previous P Series
processors which supported only 4 chip selects.
Signed-off-by: Aaron Sierra asie...@xes-inc.com
---
drivers/memory/fsl_ifc.c| 2 +-
drivers/mtd/nand/fsl_ifc_nand.c | 17 ++---
include/linux/fsl_ifc.h | 34 +-
3 files changed, 36 insertions(+), 17 deletions(-)
diff --git a/drivers/memory/fsl_ifc.c b/drivers/memory/fsl_ifc.c
index 3d5d792..a539dc2 100644
--- a/drivers/memory/fsl_ifc.c
+++ b/drivers/memory/fsl_ifc.c
@@ -61,7 +61,7 @@ int fsl_ifc_find(phys_addr_t addr_base)
if (!fsl_ifc_ctrl_dev || !fsl_ifc_ctrl_dev-regs)
return -ENODEV;
- for (i = 0; i ARRAY_SIZE(fsl_ifc_ctrl_dev-regs-cspr_cs); i++) {
+ for (i = 0; i fsl_ifc_bank_count(fsl_ifc_ctrl_dev-regs); i++) {
u32 cspr = in_be32(fsl_ifc_ctrl_dev-regs-cspr_cs[i].cspr);
if (cspr CSPR_V (cspr CSPR_BA) ==
convert_ifc_address(addr_base))
diff --git a/drivers/mtd/nand/fsl_ifc_nand.c
b/drivers/mtd/nand/fsl_ifc_nand.c
index 2338124..f7b7077 100644
--- a/drivers/mtd/nand/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/fsl_ifc_nand.c
@@ -31,7 +31,6 @@
#include linux/mtd/nand_ecc.h
#include linux/fsl_ifc.h
-#define FSL_IFC_V1_1_0 0x0101
#define ERR_BYTE 0xFF /* Value returned for read
bytes when read failed */
#define IFC_TIMEOUT_MSECS 500 /* Maximum number of mSecs to wait
@@ -54,7 +53,7 @@ struct fsl_ifc_mtd {
/* overview of the fsl ifc controller */
struct fsl_ifc_nand_ctrl {
struct nand_hw_control controller;
- struct fsl_ifc_mtd *chips[FSL_IFC_BANK_COUNT];
+ struct fsl_ifc_mtd *chips[FSL_IFC_BANK_COUNT_MAX];
FSL_IFC_MAX_BANKS would be more concise. I'm not sure we really need to
rename this, though.
I renamed it to be sure that I found all of the places it was used and I
wanted to make clear that the FSL_IFC_BANK_COUNT doesn't refer to the
implemented number of banks. I agree that with the comment immediately above
the definition, renaming the define is redundant.
@@ -834,5 +843,12 @@ struct fsl_ifc_ctrl {
extern struct fsl_ifc_ctrl *fsl_ifc_ctrl_dev;
+static inline u32 fsl_ifc_version(struct fsl_ifc_regs *regs) {
+ return ioread32be(regs-ifc_rev) FSL_IFC_VERSION_MASK;
+}
+
+static inline int fsl_ifc_bank_count(struct fsl_ifc_regs *regs) {
+ return (fsl_ifc_version(regs) == FSL_IFC_VERSION_1_0_0) ? 4 : 8;
+}
Whitespace
Oops.
Do we really need the bank count here, as opposed to just checking it in
probe()? I also don't really care for reading the registers over and
over, even though it's not performance critical.
The bank count is used in fsl_ifc_nand.c and fsl_ifc.c, so I thought it
was a good idea to have the version to bank count mapping defined in one
place rather than two.
The reserved bits of the version register are defined as zero for
current versions -- I think just comparing ifc_rev to the version
constant, as is currently done, is fine.
I wasn't sure because the manuals I have only say that reserved values
are zero at reset.
Also, please send the patch to the mtd list and maintainer.
Ok.
-Aaron
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3] powerpc: fsl_pci: Add forced PCI Agent enumeration
The following commit prevents the MPC8548E on the XPedite5200 PrPMC
module from enumerating its PCI/PCI-X bus:
powerpc/fsl-pci: use 'Header Type' to identify PCIE mode
The previous patch prevents any Freescale PCI-X bridge from enumerating
the bus, if it is hardware strapped into Agent mode.
In PCI-X, the Host is responsible for driving the PCI-X initialization
pattern to devices on the bus, so that they know whether to operate in
conventional PCI or PCI-X mode as well as what the bus timing will be.
For a PCI-X PrPMC, the pattern is driven by the mezzanine carrier it is
installed onto. Therefore, PrPMCs are PCI-X Agents, but one per system
may still enumerate the bus.
This patch causes the device node of any PCI/PCI-X bridge strapped into
Agent mode to be checked for the fsl,pci-agent-force-enum property. If
the property is present in the node, the bridge will be allowed to
enumerate the bus.
Cc: Minghuan Lian minghuan.l...@freescale.com
Signed-off-by: Aaron Sierra asie...@xes-inc.com
---
Documentation/devicetree/bindings/pci/fsl,pci.txt | 27 +++
arch/powerpc/sysdev/fsl_pci.c | 3 ++-
2 files changed, 29 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/pci/fsl,pci.txt
diff --git a/Documentation/devicetree/bindings/pci/fsl,pci.txt
b/Documentation/devicetree/bindings/pci/fsl,pci.txt
new file mode 100644
index 000..d8ac4a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/fsl,pci.txt
@@ -0,0 +1,27 @@
+* Bus Enumeration by Freescale PCI-X Agent
+
+Typically any Freescale PCI-X bridge hardware strapped into Agent mode
+is prevented from enumerating the bus. The PrPMC form-factor requires
+all mezzanines to be PCI-X Agents, but one per system may still
+enumerate the bus.
+
+The property defined below will allow a PCI-X bridge to be used for bus
+enumeration despite being strapped into Agent mode.
+
+Required properties:
+- fsl,pci-agent-force-enum : There is no value associated with this
+ property. The property itself is treated as a boolean.
+
+Example:
+
+ /* PCI-X bridge known to be PrPMC Monarch */
+ pci0: pci@ef008000 {
+ fsl,pci-agent-force-enum;
+ #interrupt-cells = 1;
+ #size-cells = 2;
+ #address-cells = 3;
+ compatible = fsl,mpc8540-pcix, fsl,mpc8540-pci;
+ device_type = pci;
+ ...
+ ...
+ };
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 4bd091a..d13663f 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -522,7 +522,8 @@ int fsl_add_bridge(struct platform_device *pdev, int
is_primary)
} else {
/* For PCI read PROG to identify controller mode */
early_read_config_byte(hose, 0, 0, PCI_CLASS_PROG, progif);
- if ((progif 1) == 1)
+ if ((progif 1)
+ !of_property_read_bool(dev, fsl,pci-agent-force-enum))
goto no_bridge;
}
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] fsl_ifc: Support all 8 IFC chip selects
On Tue, 2014-08-26 at 16:34 -0500, Aaron Sierra wrote:
+static inline u32 fsl_ifc_version(struct fsl_ifc_regs *regs) {
+ return ioread32be(regs-ifc_rev) FSL_IFC_VERSION_MASK;
+}
+
+static inline int fsl_ifc_bank_count(struct fsl_ifc_regs *regs) {
+ return (fsl_ifc_version(regs) == FSL_IFC_VERSION_1_0_0) ? 4 : 8;
+}
Whitespace
Oops.
Do we really need the bank count here, as opposed to just checking it in
probe()? I also don't really care for reading the registers over and
over, even though it's not performance critical.
The bank count is used in fsl_ifc_nand.c and fsl_ifc.c, so I thought it
was a good idea to have the version to bank count mapping defined in one
place rather than two.
OK.
The reserved bits of the version register are defined as zero for
current versions -- I think just comparing ifc_rev to the version
constant, as is currently done, is fine.
I wasn't sure because the manuals I have only say that reserved values
are zero at reset.
Well, we already have a version check that assumes they're zero, but if
you want to be especially safe I guess that's OK. :-)
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Documentation: dts: fsl-usb: Document USB node compatible string for IP version
On Fri, 2014-08-22 at 00:05 -0500, Mehresh Ramneek-B31383 wrote:
-Original Message-
From: Badola Nikhil-B46172
Sent: Friday, August 22, 2014 10:18 AM
To: Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org; devicet...@vger.kernel.org; Mehresh
Ramneek-B31383
Subject: RE: [PATCH] Documentation: dts: fsl-usb: Document USB node
compatible string for IP version
Adding Ramneek
-Original Message-
From: Wood Scott-B07421
Sent: Friday, August 22, 2014 3:53 AM
To: Badola Nikhil-B46172
Cc: linuxppc-dev@lists.ozlabs.org; devicet...@vger.kernel.org
Subject: Re: [PATCH] Documentation: dts: fsl-usb: Document USB node
compatible string for IP version
On Thu, 2014-08-21 at 14:48 +0530, Nikhil Badola wrote:
Document compatible string containing IP version in USB device tree
node
Signed-off-by: Nikhil Badola nikhil.bad...@freescale.com
---
Documentation/devicetree/bindings/usb/fsl-usb.txt | 13
-
1 file changed, 8 insertions(+), 5 deletions(-)
Please CC devicet...@vger.kernel.org on all device tree patches (in
addition to linuxppc-dev).
diff --git a/Documentation/devicetree/bindings/usb/fsl-usb.txt
b/Documentation/devicetree/bindings/usb/fsl-usb.txt
index 4779c02..5a3a0a8 100644
--- a/Documentation/devicetree/bindings/usb/fsl-usb.txt
+++ b/Documentation/devicetree/bindings/usb/fsl-usb.txt
@@ -10,7 +10,10 @@ Required properties :
controllers, or fsl-usb2-dr for dual role USB controllers
or fsl,mpc5121-usb2-dr for dual role USB controllers of MPC5121.
Wherever applicable, the IP version of the USB controller should
- also be mentioned (for eg. fsl-usb2-dr-v2.2 for bsc9132).
+ also be mentioned in another string.
+ For multi port host USB controller with IP version IP_Ver, it
should be
+ fsl-usb2-mph-IP_Ver. For dual role USB controller with IP version
+ IP_Ver, it should be fsl-usb2-dr-IP_Ver.
It was documented before -- this is just making it more explicit, right?
FWIW, the version number can be read out of a USB register, so I'd
rather remove the suggestion to specify the version number and replace
it with a reference to the ID register.
we have following two issues -
(a) our USBIP version register doesn't have consistent version field size
over
multiple version(s). This is why we couldn't use it for reading version info
across
various IP versions
(b) this register is not exposed in all SoC RMs (probably because of above
reason)
:-(
If this is just a problem with older chips, we could have a new
compatible name that designates the family of USB block versions with a
sane version register.
@@ -55,9 +58,9 @@ Example multi port host USB controller device node :
port1;
};
-Example dual role USB controller device node :
+Example dual role USB controller version 2.5 device node :
usb@23000 {
- compatible = fsl-usb2-dr;
+ compatible = fsl-usb2-dr-v2.5, fsl-usb2-dr;
reg = 23000 1000;
#address-cells = 1;
#size-cells = 0;
This example doesn't correspond to any device tree I see. Even after
your next patch that sets t2080's USB to v2.5, the addresses are different.
I reckon that the example emphasizes on showing how IP version information is
to be stored in compatible string. Is it necessary to make sure that we
should
always site actual values already used?
The more realistic the examples are, the better.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/5] kexec: minor fixups and enhancements
Hi Vivek, On Mon, 2014-08-25 at 12:59 -0400, Vivek Goyal wrote: Does arm64 has secureboot? If yes, then it might make sense to enable the new syscall kexec_file_load() on arm64 instead of trying to make old syscall work first. Yes, arm64 should support secureboot, but I have not looked into it. When do you expect syscall kexec_file_load to get merged? I won't wait until then to push my current kexec work. -Geoff ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/5] kexec: minor fixups and enhancements
On Tue, Aug 26, 2014 at 05:33:28PM -0700, Geoff Levand wrote: Hi Vivek, On Mon, 2014-08-25 at 12:59 -0400, Vivek Goyal wrote: Does arm64 has secureboot? If yes, then it might make sense to enable the new syscall kexec_file_load() on arm64 instead of trying to make old syscall work first. Yes, arm64 should support secureboot, but I have not looked into it. When do you expect syscall kexec_file_load to get merged? I won't wait until then to push my current kexec work. It got merged in 3.17-rc1 Thanks Vivek ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: Fix warning reported by verify_cpu_node_mapping()
On 二, 2014-08-26 at 08:10 -0500, Nathan Fontenot wrote:
On 08/25/2014 02:22 AM, Li Zhong wrote:
With commit 2fabf084b, during boottime, cpu_numa_callback() is called
earlier(before their online) for each cpu, and verify_cpu_node_mapping()
uses cpu_to_node() to check whether siblings are in the same node.
It skips the checking for siblings that are not online yet. So the only
check done here is for the bootcpu, which is online at that time. But
the per-cpu numa_node cpu_to_node() uses hasn't been set up yet (which
will be set up in smp_prepare_cpus()).
So I saw something like following reported:
[0.00] CPU thread siblings 1/2/3 and 0 don't belong to the same
node!
As we don't actually do the checking during this early stage, so maybe
we could directly call numa_setup_cpu() in do_init_bootmem().
Also, as Nish suggested, here it's better to use present cpu mask
instead of possible mask to avoid warning in numa_setup_cpu().
Signed-off-by: Li Zhong zh...@linux.vnet.ibm.com
---
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index d7737a5..3a9061e 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -1127,9 +1127,8 @@ void __init do_init_bootmem(void)
* even before we online them, so that we can use cpu_to_{node,mem}
* early in boot, cf. smp_prepare_cpus().
*/
- for_each_possible_cpu(cpu) {
- cpu_numa_callback(ppc64_numa_nb, CPU_UP_PREPARE,
- (void *)(unsigned long)cpu);
+ for_each_present_cpu(cpu) {
+ numa_setup_cpu((unsigned long)cpu);
}
}
I am getting the following error on my system booting with this patch.
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.16.0-202712-g9e81330-dirty #42
task: c000fea4 ti: c000fea8 task.ti: c000fea8
NIP: c01afad8 LR: c0193b68 CTR:
REGS: c000fea839e0 TRAP: 0300 Not tainted
(3.16.0-202712-g9e81330-dirty)
MSR: 80019033 SF,EE,ME,IR,DR,RI,LE CR: 2400 XER: 2004
CFAR: c00084d4 DAR: 1690 DSISR: 4000 SOFTE: 1
GPR00: c0b6db9c c000fea83c60 c0cd0628 1688
GPR04: 0001 c000fea83c80 0990
GPR08: c0d531e0 c0d66218 c0d60628
GPR12: cec6 c000bc88
GPR16:
GPR20: c0c21b88 c0c03738
GPR24: c0c03638 c0d24b10 c0c03638 c0c03738
GPR28: 0080 0080 c0d208e8 0010
NIP [c01afad8] next_zones_zonelist+0x8/0xa0
LR [c0193b68] local_memory_node+0x38/0x60
Call Trace:
[c000fea83c60] [c000fea83c90] 0xc000fea83c90 (unreliable)
[c000fea83c90] [c0b6db9c] smp_prepare_cpus+0x16c/0x278
[c000fea83d00] [c0b64098] kernel_init_freeable+0x150/0x340
[c000fea83dc0] [c000bca4] kernel_init+0x24/0x140
[c000fea83e30] [c0009560] ret_from_kernel_thread+0x5c/0x7c
Instruction dump:
e9230038 39490f00 7fa35040 409c000c 38630780 4e800020 7d234b78 4b64
6000 6042 2c25 40c2004c 81230008 7f892040 419d0014 4830
---[ end trace cb88537fdc8fa200 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b
I think the loop needs to go back to initializing all possibe cpus instead of
only the present cpus. We can add a check for present cpus in numa_setup_cpu()
to avoid printing the WARN_ON() for cpus that are not present, something like
the following...
Ah, yes, seems the panic was caused by smp_prepare_cpus() using
uninitialized numa_cpu_lookup_table for cpus which are possible but not
present during boottime.
However, by following change, it seems those cpus will be set to node 0
at boottime, and not be changed after they become present, because of
the following check in numa_setup_cpu():
if ((nid = numa_cpu_lookup_table[lcpu]) = 0) {
map_cpu_to_node(lcpu, nid);
return nid;
}
Maybe we could change the smp_prepare_cpus() to set numa information for
present cpus instead?
And for those possible, !present cpus, we could do the setup after they
are started.
Thanks, Zhong
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index d7737a5..b827f2e 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -554,7 +554,8 @@ static int numa_setup_cpu(unsigned long lcpu)
cpu = of_get_cpu_node(lcpu, NULL);
if (!cpu) {
- WARN_ON(1);
+ if (cpu_present(lcpu))
+ WARN_ON(1);
nid = 0;
goto out;
}
@@ -1128,8 +1129,7 @@ void __init do_init_bootmem(void)
* early in boot, cf.
RE: [RESEND] clk: ppc-corenet: Add Freescale ARM-based platforms CLK_OF_DECLARE support
-Original Message- From: Wood Scott-B07421 Sent: Wednesday, August 27, 2014 6:51 AM To: Lu Jingchang-B35083 Cc: mturque...@linaro.org; linuxppc-dev@lists.ozlabs.org; linux- ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [RESEND] clk: ppc-corenet: Add Freescale ARM-based platforms CLK_OF_DECLARE support On Fri, 2014-08-22 at 17:34 +0800, Jingchang Lu wrote: Signed-off-by: Jingchang Lu jingchang...@freescale.com --- drivers/clk/Kconfig | 7 --- drivers/clk/clk-ppc-corenet.c | 5 + 2 files changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index cfd3af7..8784704 100644 --- a/drivers/clk/Kconfig +++ b/drivers/clk/Kconfig @@ -82,11 +82,12 @@ config COMMON_CLK_AXI_CLKGEN FPGAs. It is commonly used in Analog Devices' reference designs. config CLK_PPC_CORENET -bool Clock driver for PowerPC corenet platforms -depends on PPC_E500MC OF +bool Clock driver for PowerPC corenet and compatible ARM-based platforms +depends on (PPC_E500MC || ARM) OF Should the symbol and driver be renamed to something like CLK_FSL_QORIQ? This name is better for sharing on ARM and PowerPC, I will rename them. Thanks. diff --git a/drivers/clk/clk-ppc-corenet.c b/drivers/clk/clk-ppc- corenet.c index 8e58edf..7692cac 100644 --- a/drivers/clk/clk-ppc-corenet.c +++ b/drivers/clk/clk-ppc-corenet.c @@ -305,3 +305,8 @@ static int __init ppc_corenet_clk_init(void) return platform_driver_register(ppc_corenet_clk_driver); } subsys_initcall(ppc_corenet_clk_init); + +CLK_OF_DECLARE(ppc_core_pll_v1, fsl,qoriq-core-pll-1.0, core_pll_init); +CLK_OF_DECLARE(ppc_core_pll_v2, fsl,qoriq-core-pll-2.0, core_pll_init); +CLK_OF_DECLARE(ppc_core_mux_v1, fsl,qoriq-core-mux-1.0, core_mux_init); +CLK_OF_DECLARE(ppc_core_mux_v2, fsl,qoriq-core-mux-2.0, core_mux_init); What does this do that the existing platform driver and match table don't? Why is it needed for ARM when PPC didn't need it? -Scott Common clk init on ARM platform is initialized earlier via of_clk_init() instead of driver probe method, the of_clk_init will walk a __clk_of_table to init each clk provider in the table, the CLK_OF_DECLARE() macro puts a supported clk in the __clk_of_table for it initializing on starup, and the clk system has added some common clk such as fixed-clk to this table already. So here I add our specific clk init declaration to consist this framework, and the driver probe function will not be needed on ARM. Best Regards, Jingchang ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Add private HCALL to inform updated RTAS base and entry
Aravinda Prasad aravi...@linux.vnet.ibm.com writes: This patch adds a private HCALL to inform qemu the updated rtas-base and rtas-entry address when OS invokes the call instantiate-rtas. This is required as qemu allocates the error reporting structure in RTAS space upon a machine check exception and hence needs to know the updated RTAS. Enhancements to qemu to handle the private HCALL, prepare error log and invoke machine check notification routine are in a separate patch. Signed-off-by: Nikunj A. Dadhania nik...@linux.vnet.ibm.com Signed-off-by: Aravinda Prasad aravi...@linux.vnet.ibm.com Thanks, applied. --- board-qemu/slof/rtas.fs |6 +- lib/libhvcall/hvcall.code |6 ++ lib/libhvcall/hvcall.in |1 + lib/libhvcall/libhvcall.h |4 +++- 4 files changed, 15 insertions(+), 2 deletions(-) diff --git a/board-qemu/slof/rtas.fs b/board-qemu/slof/rtas.fs index 41e30c2..c081b57 100644 --- a/board-qemu/slof/rtas.fs +++ b/board-qemu/slof/rtas.fs @@ -174,7 +174,11 @@ rtas-node set-node : instantiate-rtas ( adr -- entry ) dup rtas-base swap rtas-size move -rtas-entry rtas-base - + +dup rtas-entry rtas-base - + +2dup hv-rtas-update 0 IF +. Failed to update RTAS cr +THEN +nip ; device-end diff --git a/lib/libhvcall/hvcall.code b/lib/libhvcall/hvcall.code index 744469f..0ff50f2 100644 --- a/lib/libhvcall/hvcall.code +++ b/lib/libhvcall/hvcall.code @@ -111,6 +111,12 @@ PRIM(hv_X2d_cas) TOS.u = hv_cas(vec, buf, size); MIRP +PRIM(hv_X2d_rtas_X2d_update) + unsigned long rtas_entry = TOS.u; POP; + unsigned long rtas_base= TOS.u; + TOS.u = hv_generic(KVMPPC_H_RTAS_UPDATE, rtas_base, rtas_entry); +MIRP + PRIM(get_X2d_print_X2d_version) unsigned long addr = TOS.u; POP; get_print_banner(addr); diff --git a/lib/libhvcall/hvcall.in b/lib/libhvcall/hvcall.in index e99d6d1..4437b77 100644 --- a/lib/libhvcall/hvcall.in +++ b/lib/libhvcall/hvcall.in @@ -30,4 +30,5 @@ cod(RX!) cod(hv-logical-memop) cod(hv-cas) +cod(hv-rtas-update) cod(get-print-version) diff --git a/lib/libhvcall/libhvcall.h b/lib/libhvcall/libhvcall.h index 6356a62..193b738 100644 --- a/lib/libhvcall/libhvcall.h +++ b/lib/libhvcall/libhvcall.h @@ -24,7 +24,9 @@ #define KVMPPC_H_LOGICAL_MEMOP (KVMPPC_HCALL_BASE + 0x1) /* Client Architecture support */ #define KVMPPC_H_CAS(KVMPPC_HCALL_BASE + 0x2) -#define KVMPPC_HCALL_MAXKVMPPC_H_CAS +#define KVMPPC_H_RTAS_UPDATE(KVMPPC_HCALL_BASE + 0x3) +#define KVMPPC_H_REPORT_MC_ERR (KVMPPC_HCALL_BASE + 0x4) +#define KVMPPC_HCALL_MAXKVMPPC_H_NMI_MCE #ifndef __ASSEMBLY__ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
