* [PATCH 2/4] powerpc/eeh: Introduce eeh_ops::err_inject
From: Gavin Shan @ 2014-08-26 7:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: qiudayu, Gavin Shan
In-Reply-To: <1409039779-392-1-git-send-email-gwshan@linux.vnet.ibm.com>
From: Mike Qiu <qiudayu@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 <qiudayu@linux.vnet.ibm.com>
Signed-off-by: Gavin Shan <gwshan@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 = powernv_eeh_get_log,
.configure_bridge = powernv_eeh_configure_bridge,
+ .err_inject = powernv_eeh_err_inject,
.read_config = pnv_pci_cfg_read,
.write_config = pnv_pci_cfg_write,
.next_error = powernv_eeh_next_error,
diff --git a/arch/powerpc/platforms/powernv/pci.h b/arch/powerpc/platforms/powernv/pci.h
index 48494d4..b54af34 100644
--- a/arch/powerpc/platforms/powernv/pci.h
+++ b/arch/powerpc/platforms/powernv/pci.h
@@ -85,6 +85,8 @@ struct pnv_eeh_ops {
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 (*next_error)(struct eeh_pe **pe);
};
#endif /* CONFIG_EEH */
diff --git a/arch/powerpc/platforms/pseries/eeh_pseries.c b/arch/powerpc/platforms/pseries/eeh_pseries.c
index b645dc6..4fc5ff9 100644
--- a/arch/powerpc/platforms/pseries/eeh_pseries.c
+++ b/arch/powerpc/platforms/pseries/eeh_pseries.c
@@ -731,6 +731,7 @@ static struct eeh_ops pseries_eeh_ops = {
.wait_state = pseries_eeh_wait_state,
.get_log = pseries_eeh_get_log,
.configure_bridge = pseries_eeh_configure_bridge,
+ .err_inject = NULL,
.read_config = pseries_eeh_read_config,
.write_config = pseries_eeh_write_config,
.next_error = NULL,
--
1.8.3.2
^ permalink raw reply related
* [PATCH 0/4] powerpc/eeh: More precisely error injection
From: Gavin Shan @ 2014-08-26 7:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: qiudayu, Gavin Shan
Previously, we inject PCI errors through various debugfs entries in
/sys/kernel/debug/powerpc/PCIxxxx/. 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/PCIxxxx/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
^ permalink raw reply
* [PATCH 3/4] powerpc/powernv: Add error injection debugfs entry
From: Gavin Shan @ 2014-08-26 7:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: qiudayu, Gavin Shan
In-Reply-To: <1409039779-392-1-git-send-email-gwshan@linux.vnet.ibm.com>
From: Mike Qiu <qiudayu@linux.vnet.ibm.com>
The patch adds debugfs file (/sys/kernel/debug/powerpc/PCIxxxx/
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 <qiudayu@linux.vnet.ibm.com>
Signed-off-by: Gavin Shan <gwshan@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
^ permalink raw reply related
* [PATCH 4/4] powerpc/powernv: Clear PAPR error injection registers
From: Gavin Shan @ 2014-08-26 7:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: qiudayu, Gavin Shan
In-Reply-To: <1409039779-392-1-git-send-email-gwshan@linux.vnet.ibm.com>
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 <gwshan@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
^ permalink raw reply related
* [PATCH 1/4] powerpc/powernv: Sync header with firmware
From: Gavin Shan @ 2014-08-26 7:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: qiudayu, Gavin Shan
In-Reply-To: <1409039779-392-1-git-send-email-gwshan@linux.vnet.ibm.com>
From: Mike Qiu <qiudayu@linux.vnet.ibm.com>
The patch synchronizes firmware header file (opal.h) for PCI error
injection.
Signed-off-by: Mike Qiu <qiudayu@linux.vnet.ibm.com>
Signed-off-by: Gavin Shan <gwshan@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_INFO2 94
+#define OPAL_PCI_ERR_INJCT 96
#define OPAL_PCI_EEH_FREEZE_SET 97
#define OPAL_HANDLE_HMI 98
#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
^ permalink raw reply related
* Re: [PATCH v2] powerpc: Fix warning reported by verify_cpu_node_mapping()
From: Nathan Fontenot @ 2014-08-26 13:10 UTC (permalink / raw)
To: Li Zhong, Nishanth Aravamudan
Cc: Michael Ellerman, Paul Mackerras, PowerPC email list
In-Reply-To: <1408951355.2477.8.camel@TP420>
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.000000] 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 <zhong@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: c0000000fea40000 ti: c0000000fea80000 task.ti: c0000000fea80000
NIP: c0000000001afad8 LR: c000000000193b68 CTR: 0000000000000000
REGS: c0000000fea839e0 TRAP: 0300 Not tainted (3.16.0-202712-g9e81330-dirty)
MSR: 8000000100009033 <SF,EE,ME,IR,DR,RI,LE> CR: 24000000 XER: 20000004
CFAR: c0000000000084d4 DAR: 0000000000001690 DSISR: 40000000 SOFTE: 1
GPR00: c000000000b6db9c c0000000fea83c60 c000000000cd0628 0000000000001688
GPR04: 0000000000000001 0000000000000000 c0000000fea83c80 0000000009900000
GPR08: c000000000d531e0 c000000000d66218 c000000000d60628 ffffffffffffffff
GPR12: ffffffffffffffff c00000000ec60000 c00000000000bc88 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000000000 c000000000c21b88 c000000000c03738
GPR24: c000000000c03638 c000000000d24b10 c000000000c03638 c000000000c03738
GPR28: 0000000000000080 0000000000000080 c000000000d208e8 0000000000000010
NIP [c0000000001afad8] next_zones_zonelist+0x8/0xa0
LR [c000000000193b68] local_memory_node+0x38/0x60
Call Trace:
[c0000000fea83c60] [c0000000fea83c90] 0xc0000000fea83c90 (unreliable)
[c0000000fea83c90] [c000000000b6db9c] smp_prepare_cpus+0x16c/0x278
[c0000000fea83d00] [c000000000b64098] kernel_init_freeable+0x150/0x340
[c0000000fea83dc0] [c00000000000bca4] kernel_init+0x24/0x140
[c0000000fea83e30] [c000000000009560] ret_from_kernel_thread+0x5c/0x7c
Instruction dump:
e9230038 39490f00 7fa35040 409c000c 38630780 4e800020 7d234b78 4bffff64
60000000 60420000 2c250000 40c2004c <81230008> 7f892040 419d0014 48000030
---[ end trace cb88537fdc8fa200 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
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...
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. smp_prepare_cpus().
*/
for_each_possible_cpu(cpu) {
- cpu_numa_callback(&ppc64_numa_nb, CPU_UP_PREPARE,
- (void *)(unsigned long)cpu);
+ numa_setup_cpu((unsigned long)cpu);
}
}
^ permalink raw reply related
* Re: [PATCH v2] powerpc: Fix warning reported by verify_cpu_node_mapping()
From: Nishanth Aravamudan @ 2014-08-26 15:17 UTC (permalink / raw)
To: Nathan Fontenot
Cc: Michael Ellerman, Paul Mackerras, PowerPC email list, Li Zhong
In-Reply-To: <53FC8736.8080000@linux.vnet.ibm.com>
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.000000] 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 <zhong@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
^ permalink raw reply
* [PATCH v2] fsl_ifc: Support all 8 IFC chip selects
From: Aaron Sierra @ 2014-08-26 17:31 UTC (permalink / raw)
To: linuxppc-dev
Cc: Scott Wood, Greg Kroah-Hartman, Arnd Bergmann, Prabhakar Kushwaha
In-Reply-To: <1991824361.262160.1409074072267.JavaMail.zimbra@xes-inc.com>
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 <asierra@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 0x01010000
#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 0x0F0F0000
+#define FSL_IFC_VERSION_1_0_0 0x01000000
+#define FSL_IFC_VERSION_1_1_0 0x01010000
/*
* 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];
+ } ftim_cs[FSL_IFC_BANK_COUNT_MAX];
+ u32 res9[0x30];
__be32 rb_stat;
u32 res10[0x2];
__be32 ifc_gcr;
@@ -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(®s->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;
+}
#endif /* __ASM_FSL_IFC_H */
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v2] fsl_ifc: Support all 8 IFC chip selects
From: Scott Wood @ 2014-08-26 20:48 UTC (permalink / raw)
To: Aaron Sierra
Cc: Greg Kroah-Hartman, linuxppc-dev, Arnd Bergmann,
Prabhakar Kushwaha
In-Reply-To: <1720585700.271372.1409074298919.JavaMail.zimbra@xes-inc.com>
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 <asierra@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 0x01010000
> #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.
> @@ -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(®s->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
^ permalink raw reply
* Re: [PATCH v2] powerpc: fsl_pci: Add forced PCI Agent enumeration
From: Scott Wood @ 2014-08-26 20:52 UTC (permalink / raw)
To: Aaron Sierra; +Cc: Minghuan Lian, linuxppc-dev
In-Reply-To: <2036664217.106423.1409010857961.JavaMail.zimbra@xes-inc.com>
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.Lian@freescale.com>
> Signed-off-by: Aaron Sierra <asierra@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 0000000..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 devicetree@vger.kernel.org on all device tree patches.
Otherwise it looks OK.
-Scott
^ permalink raw reply
* Re: [PATCH v2] powerpc: fsl_pci: Add forced PCI Agent enumeration
From: Aaron Sierra @ 2014-08-26 21:12 UTC (permalink / raw)
To: Scott Wood; +Cc: Minghuan Lian, linuxppc-dev
In-Reply-To: <1409086376.6510.82.camel@snotra.buserror.net>
----- Original Message -----
> From: "Scott Wood" <scottwood@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.Lian@freescale.com>
> > Signed-off-by: Aaron Sierra <asierra@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 0000000..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 devicetree@vger.kernel.org on all device tree patches.
Will do.
> Otherwise it looks OK.
>
> -Scott
^ permalink raw reply
* Re: [PATCH v2] fsl_ifc: Support all 8 IFC chip selects
From: Aaron Sierra @ 2014-08-26 21:34 UTC (permalink / raw)
To: Scott Wood
Cc: Greg Kroah-Hartman, linuxppc-dev, Arnd Bergmann,
Prabhakar Kushwaha
In-Reply-To: <1409086131.6510.80.camel@snotra.buserror.net>
----- Original Message -----
> From: "Scott Wood" <scottwood@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 <asierra@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 0x01010000
> > #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(®s->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
^ permalink raw reply
* [PATCH v3] powerpc: fsl_pci: Add forced PCI Agent enumeration
From: Aaron Sierra @ 2014-08-26 21:46 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood, devicetree, Minghuan Lian
In-Reply-To: <225331217.447792.1409089347911.JavaMail.zimbra@xes-inc.com>
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.Lian@freescale.com>
Signed-off-by: Aaron Sierra <asierra@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 0000000..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
^ permalink raw reply related
* Re: [PATCH v2] fsl_ifc: Support all 8 IFC chip selects
From: Scott Wood @ 2014-08-26 21:48 UTC (permalink / raw)
To: Aaron Sierra
Cc: Greg Kroah-Hartman, linuxppc-dev, Arnd Bergmann,
Prabhakar Kushwaha
In-Reply-To: <1923004045.447083.1409088847731.JavaMail.zimbra@xes-inc.com>
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(®s->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
^ permalink raw reply
* Re: [RESEND] clk: ppc-corenet: Add Freescale ARM-based platforms CLK_OF_DECLARE support
From: Scott Wood @ 2014-08-26 22:51 UTC (permalink / raw)
To: Jingchang Lu; +Cc: linuxppc-dev, mturquette, linux-kernel, linux-arm-kernel
In-Reply-To: <1408700096-25415-1-git-send-email-jingchang.lu@freescale.com>
On Fri, 2014-08-22 at 17:34 +0800, Jingchang Lu wrote:
> Signed-off-by: Jingchang Lu <jingchang.lu@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?
> 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
^ permalink raw reply
* Re: [PATCH] Documentation: dts: fsl-usb: Document USB node compatible string for IP version
From: Scott Wood @ 2014-08-26 22:53 UTC (permalink / raw)
To: Mehresh Ramneek-B31383
Cc: devicetree@vger.kernel.org, Badola Nikhil-B46172,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <3fdd7732a9954d13a90ece684771d932@BL2PR03MB161.namprd03.prod.outlook.com>
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; devicetree@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; devicetree@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.badola@freescale.com>
> > > ---
> > > Documentation/devicetree/bindings/usb/fsl-usb.txt | 13
> > > ++++++++-----
> > > 1 file changed, 8 insertions(+), 5 deletions(-)
> >
> > Please CC devicetree@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
^ permalink raw reply
* Re: [PATCH 0/5] kexec: minor fixups and enhancements
From: Geoff Levand @ 2014-08-27 0:33 UTC (permalink / raw)
To: Vivek Goyal
Cc: kexec, linux-kernel, Eric Biederman, Andrew Morton, linuxppc-dev
In-Reply-To: <20140825165916.GC14379@redhat.com>
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
^ permalink raw reply
* Re: [PATCH 0/5] kexec: minor fixups and enhancements
From: Vivek Goyal @ 2014-08-27 0:42 UTC (permalink / raw)
To: Geoff Levand
Cc: kexec, linux-kernel, Eric Biederman, Andrew Morton, linuxppc-dev
In-Reply-To: <1409099608.21254.16.camel@smoke>
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
^ permalink raw reply
* Re: [PATCH v2] powerpc: Fix warning reported by verify_cpu_node_mapping()
From: Li Zhong @ 2014-08-27 1:41 UTC (permalink / raw)
To: Nathan Fontenot
Cc: Michael Ellerman, Paul Mackerras, Nishanth Aravamudan,
PowerPC email list
In-Reply-To: <53FC8736.8080000@linux.vnet.ibm.com>
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.000000] 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 <zhong@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: c0000000fea40000 ti: c0000000fea80000 task.ti: c0000000fea80000
> NIP: c0000000001afad8 LR: c000000000193b68 CTR: 0000000000000000
> REGS: c0000000fea839e0 TRAP: 0300 Not tainted (3.16.0-202712-g9e81330-dirty)
> MSR: 8000000100009033 <SF,EE,ME,IR,DR,RI,LE> CR: 24000000 XER: 20000004
> CFAR: c0000000000084d4 DAR: 0000000000001690 DSISR: 40000000 SOFTE: 1
> GPR00: c000000000b6db9c c0000000fea83c60 c000000000cd0628 0000000000001688
> GPR04: 0000000000000001 0000000000000000 c0000000fea83c80 0000000009900000
> GPR08: c000000000d531e0 c000000000d66218 c000000000d60628 ffffffffffffffff
> GPR12: ffffffffffffffff c00000000ec60000 c00000000000bc88 0000000000000000
> GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR20: 0000000000000000 0000000000000000 c000000000c21b88 c000000000c03738
> GPR24: c000000000c03638 c000000000d24b10 c000000000c03638 c000000000c03738
> GPR28: 0000000000000080 0000000000000080 c000000000d208e8 0000000000000010
> NIP [c0000000001afad8] next_zones_zonelist+0x8/0xa0
> LR [c000000000193b68] local_memory_node+0x38/0x60
> Call Trace:
> [c0000000fea83c60] [c0000000fea83c90] 0xc0000000fea83c90 (unreliable)
> [c0000000fea83c90] [c000000000b6db9c] smp_prepare_cpus+0x16c/0x278
> [c0000000fea83d00] [c000000000b64098] kernel_init_freeable+0x150/0x340
> [c0000000fea83dc0] [c00000000000bca4] kernel_init+0x24/0x140
> [c0000000fea83e30] [c000000000009560] ret_from_kernel_thread+0x5c/0x7c
> Instruction dump:
> e9230038 39490f00 7fa35040 409c000c 38630780 4e800020 7d234b78 4bffff64
> 60000000 60420000 2c250000 40c2004c <81230008> 7f892040 419d0014 48000030
> ---[ end trace cb88537fdc8fa200 ]---
>
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>
> 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. smp_prepare_cpus().
> */
> for_each_possible_cpu(cpu) {
> - cpu_numa_callback(&ppc64_numa_nb, CPU_UP_PREPARE,
> - (void *)(unsigned long)cpu);
> + numa_setup_cpu((unsigned long)cpu);
> }
> }
>
>
^ permalink raw reply
* RE: [RESEND] clk: ppc-corenet: Add Freescale ARM-based platforms CLK_OF_DECLARE support
From: Jingchang Lu @ 2014-08-27 2:19 UTC (permalink / raw)
To: Scott Wood
Cc: linuxppc-dev@lists.ozlabs.org, mturquette@linaro.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1409093463.6510.92.camel@snotra.buserror.net>
Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogV29vZCBTY290dC1CMDc0MjENCj5T
ZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAyNywgMjAxNCA2OjUxIEFNDQo+VG86IEx1IEppbmdjaGFu
Zy1CMzUwODMNCj5DYzogbXR1cnF1ZXR0ZUBsaW5hcm8ub3JnOyBsaW51eHBwYy1kZXZAbGlzdHMu
b3psYWJzLm9yZzsgbGludXgtDQo+a2VybmVsQHZnZXIua2VybmVsLm9yZzsgbGludXgtYXJtLWtl
cm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnDQo+U3ViamVjdDogUmU6IFtSRVNFTkRdIGNsazogcHBj
LWNvcmVuZXQ6IEFkZCBGcmVlc2NhbGUgQVJNLWJhc2VkIHBsYXRmb3Jtcw0KPkNMS19PRl9ERUNM
QVJFIHN1cHBvcnQNCj4NCj5PbiBGcmksIDIwMTQtMDgtMjIgYXQgMTc6MzQgKzA4MDAsIEppbmdj
aGFuZyBMdSB3cm90ZToNCj4+IFNpZ25lZC1vZmYtYnk6IEppbmdjaGFuZyBMdSA8amluZ2NoYW5n
Lmx1QGZyZWVzY2FsZS5jb20+DQo+PiAtLS0NCj4+ICBkcml2ZXJzL2Nsay9LY29uZmlnICAgICAg
ICAgICB8IDcgKysrKy0tLQ0KPj4gIGRyaXZlcnMvY2xrL2Nsay1wcGMtY29yZW5ldC5jIHwgNSAr
KysrKw0KPj4gIDIgZmlsZXMgY2hhbmdlZCwgOSBpbnNlcnRpb25zKCspLCAzIGRlbGV0aW9ucygt
KQ0KPj4NCj4+IGRpZmYgLS1naXQgYS9kcml2ZXJzL2Nsay9LY29uZmlnIGIvZHJpdmVycy9jbGsv
S2NvbmZpZw0KPj4gaW5kZXggY2ZkM2FmNy4uODc4NDcwNCAxMDA2NDQNCj4+IC0tLSBhL2RyaXZl
cnMvY2xrL0tjb25maWcNCj4+ICsrKyBiL2RyaXZlcnMvY2xrL0tjb25maWcNCj4+IEBAIC04Miwx
MSArODIsMTIgQEAgY29uZmlnIENPTU1PTl9DTEtfQVhJX0NMS0dFTg0KPj4gIAkgIEZQR0FzLiBJ
dCBpcyBjb21tb25seSB1c2VkIGluIEFuYWxvZyBEZXZpY2VzJyByZWZlcmVuY2UgZGVzaWducy4N
Cj4+DQo+PiAgY29uZmlnIENMS19QUENfQ09SRU5FVA0KPj4gLQlib29sICJDbG9jayBkcml2ZXIg
Zm9yIFBvd2VyUEMgY29yZW5ldCBwbGF0Zm9ybXMiDQo+PiAtCWRlcGVuZHMgb24gUFBDX0U1MDBN
QyAmJiBPRg0KPj4gKwlib29sICJDbG9jayBkcml2ZXIgZm9yIFBvd2VyUEMgY29yZW5ldCBhbmQg
Y29tcGF0aWJsZSBBUk0tYmFzZWQNCj5wbGF0Zm9ybXMiDQo+PiArCWRlcGVuZHMgb24gKFBQQ19F
NTAwTUMgfHwgQVJNKSAmJiBPRg0KPg0KPlNob3VsZCB0aGUgc3ltYm9sIGFuZCBkcml2ZXIgYmUg
cmVuYW1lZCB0byBzb21ldGhpbmcgbGlrZSBDTEtfRlNMX1FPUklRPw0KPg0KVGhpcyBuYW1lIGlz
IGJldHRlciBmb3Igc2hhcmluZyBvbiBBUk0gYW5kIFBvd2VyUEMsIEkgd2lsbCByZW5hbWUgdGhl
bS4gVGhhbmtzLg0KDQo+PiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9jbGsvY2xrLXBwYy1jb3JlbmV0
LmMgYi9kcml2ZXJzL2Nsay9jbGstcHBjLQ0KPmNvcmVuZXQuYw0KPj4gaW5kZXggOGU1OGVkZi4u
NzY5MmNhYyAxMDA2NDQNCj4+IC0tLSBhL2RyaXZlcnMvY2xrL2Nsay1wcGMtY29yZW5ldC5jDQo+
PiArKysgYi9kcml2ZXJzL2Nsay9jbGstcHBjLWNvcmVuZXQuYw0KPj4gQEAgLTMwNSwzICszMDUs
OCBAQCBzdGF0aWMgaW50IF9faW5pdCBwcGNfY29yZW5ldF9jbGtfaW5pdCh2b2lkKQ0KPj4gIAly
ZXR1cm4gcGxhdGZvcm1fZHJpdmVyX3JlZ2lzdGVyKCZwcGNfY29yZW5ldF9jbGtfZHJpdmVyKTsN
Cj4+ICB9DQo+PiAgc3Vic3lzX2luaXRjYWxsKHBwY19jb3JlbmV0X2Nsa19pbml0KTsNCj4+ICsN
Cj4+ICtDTEtfT0ZfREVDTEFSRShwcGNfY29yZV9wbGxfdjEsICJmc2wscW9yaXEtY29yZS1wbGwt
MS4wIiwNCj5jb3JlX3BsbF9pbml0KTsNCj4+ICtDTEtfT0ZfREVDTEFSRShwcGNfY29yZV9wbGxf
djIsICJmc2wscW9yaXEtY29yZS1wbGwtMi4wIiwNCj5jb3JlX3BsbF9pbml0KTsNCj4+ICtDTEtf
T0ZfREVDTEFSRShwcGNfY29yZV9tdXhfdjEsICJmc2wscW9yaXEtY29yZS1tdXgtMS4wIiwNCj5j
b3JlX211eF9pbml0KTsNCj4+ICtDTEtfT0ZfREVDTEFSRShwcGNfY29yZV9tdXhfdjIsICJmc2ws
cW9yaXEtY29yZS1tdXgtMi4wIiwNCj5jb3JlX211eF9pbml0KTsNCj4NCj5XaGF0IGRvZXMgdGhp
cyBkbyB0aGF0IHRoZSBleGlzdGluZyBwbGF0Zm9ybSBkcml2ZXIgYW5kIG1hdGNoIHRhYmxlDQo+
ZG9uJ3Q/ICBXaHkgaXMgaXQgbmVlZGVkIGZvciBBUk0gd2hlbiBQUEMgZGlkbid0IG5lZWQgaXQ/
DQo+DQo+LVNjb3R0DQo+DQpDb21tb24gY2xrIGluaXQgb24gQVJNIHBsYXRmb3JtIGlzIGluaXRp
YWxpemVkIGVhcmxpZXIgdmlhIG9mX2Nsa19pbml0KCkgaW5zdGVhZCBvZg0KZHJpdmVyIHByb2Jl
IG1ldGhvZCwgdGhlIG9mX2Nsa19pbml0IHdpbGwgd2FsayBhIF9fY2xrX29mX3RhYmxlIHRvIGlu
aXQgZWFjaCBjbGsgcHJvdmlkZXINCmluIHRoZSB0YWJsZSwgdGhlIENMS19PRl9ERUNMQVJFKCkg
bWFjcm8gcHV0cyBhIHN1cHBvcnRlZCBjbGsgaW4gdGhlIF9fY2xrX29mX3RhYmxlIGZvcg0KaXQg
aW5pdGlhbGl6aW5nIG9uIHN0YXJ1cCwgYW5kIHRoZSBjbGsgc3lzdGVtIGhhcyBhZGRlZCBzb21l
IGNvbW1vbiBjbGsgc3VjaCBhcyAiZml4ZWQtY2xrIg0KdG8gdGhpcyB0YWJsZSBhbHJlYWR5Lg0K
U28gaGVyZSBJIGFkZCBvdXIgc3BlY2lmaWMgY2xrIGluaXQgZGVjbGFyYXRpb24gdG8gY29uc2lz
dCB0aGlzIGZyYW1ld29yaywgYW5kIHRoZSBkcml2ZXINCnByb2JlIGZ1bmN0aW9uIHdpbGwgbm90
IGJlIG5lZWRlZCBvbiBBUk0uDQoNCg0KDQpCZXN0IFJlZ2FyZHMsDQpKaW5nY2hhbmcNCg0KDQoN
Cg==
^ permalink raw reply
* Re: [PATCH] Add private HCALL to inform updated RTAS base and entry
From: Nikunj A Dadhania @ 2014-08-27 5:17 UTC (permalink / raw)
To: Aravinda Prasad, aik, linuxppc-dev; +Cc: mahesh, benh, paulus
In-Reply-To: <20140825130010.1029.65141.stgit@aravindap>
Aravinda Prasad <aravinda@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 <nikunj@linux.vnet.ibm.com>
> Signed-off-by: Aravinda Prasad <aravinda@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_MAX KVMPPC_H_CAS
> +#define KVMPPC_H_RTAS_UPDATE (KVMPPC_HCALL_BASE + 0x3)
> +#define KVMPPC_H_REPORT_MC_ERR (KVMPPC_HCALL_BASE + 0x4)
> +#define KVMPPC_HCALL_MAX KVMPPC_H_NMI_MCE
>
> #ifndef __ASSEMBLY__
^ permalink raw reply
* RE: [PATCH] Documentation: dts: fsl-usb: Document USB node compatible string for IP version
From: Ramneek Mehresh @ 2014-08-27 5:46 UTC (permalink / raw)
To: Scott Wood
Cc: devicetree@vger.kernel.org, nikhil.badola@freescale.com,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1409093581.6510.94.camel@snotra.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMjcsIDIwMTQgNDoyMyBBTQ0KPiBUbzogTWVo
cmVzaCBSYW1uZWVrLUIzMTM4Mw0KPiBDYzogQmFkb2xhIE5pa2hpbC1CNDYxNzI7IGxpbnV4cHBj
LWRldkBsaXN0cy5vemxhYnMub3JnOw0KPiBkZXZpY2V0cmVlQHZnZXIua2VybmVsLm9yZw0KPiBT
dWJqZWN0OiBSZTogW1BBVENIXSBEb2N1bWVudGF0aW9uOiBkdHM6IGZzbC11c2I6IERvY3VtZW50
IFVTQiBub2RlDQo+IGNvbXBhdGlibGUgc3RyaW5nIGZvciBJUCB2ZXJzaW9uDQo+IA0KPiBPbiBG
cmksIDIwMTQtMDgtMjIgYXQgMDA6MDUgLTA1MDAsIE1laHJlc2ggUmFtbmVlay1CMzEzODMgd3Jv
dGU6DQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IEJhZG9s
YSBOaWtoaWwtQjQ2MTcyDQo+ID4gU2VudDogRnJpZGF5LCBBdWd1c3QgMjIsIDIwMTQgMTA6MTgg
QU0NCj4gPiBUbzogV29vZCBTY290dC1CMDc0MjENCj4gPiBDYzogbGludXhwcGMtZGV2QGxpc3Rz
Lm96bGFicy5vcmc7IGRldmljZXRyZWVAdmdlci5rZXJuZWwub3JnOyBNZWhyZXNoDQo+ID4gUmFt
bmVlay1CMzEzODMNCj4gPiBTdWJqZWN0OiBSRTogW1BBVENIXSBEb2N1bWVudGF0aW9uOiBkdHM6
IGZzbC11c2I6IERvY3VtZW50IFVTQiBub2RlDQo+ID4gY29tcGF0aWJsZSBzdHJpbmcgZm9yIElQ
IHZlcnNpb24NCj4gPg0KPiA+IEFkZGluZyBSYW1uZWVrDQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBXb29kIFNjb3R0LUIwNzQyMQ0KPiA+ID4gU2Vu
dDogRnJpZGF5LCBBdWd1c3QgMjIsIDIwMTQgMzo1MyBBTQ0KPiA+ID4gVG86IEJhZG9sYSBOaWto
aWwtQjQ2MTcyDQo+ID4gPiBDYzogbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7IGRldmlj
ZXRyZWVAdmdlci5rZXJuZWwub3JnDQo+ID4gPiBTdWJqZWN0OiBSZTogW1BBVENIXSBEb2N1bWVu
dGF0aW9uOiBkdHM6IGZzbC11c2I6IERvY3VtZW50IFVTQiBub2RlDQo+ID4gPiBjb21wYXRpYmxl
IHN0cmluZyBmb3IgSVAgdmVyc2lvbg0KPiA+ID4NCj4gPiA+IE9uIFRodSwgMjAxNC0wOC0yMSBh
dCAxNDo0OCArMDUzMCwgTmlraGlsIEJhZG9sYSB3cm90ZToNCj4gPiA+ID4gRG9jdW1lbnQgY29t
cGF0aWJsZSBzdHJpbmcgY29udGFpbmluZyBJUCB2ZXJzaW9uIGluIFVTQiBkZXZpY2UNCj4gPiA+
ID4gdHJlZSBub2RlDQo+ID4gPiA+DQo+ID4gPiA+IFNpZ25lZC1vZmYtYnk6IE5pa2hpbCBCYWRv
bGEgPG5pa2hpbC5iYWRvbGFAZnJlZXNjYWxlLmNvbT4NCj4gPiA+ID4gLS0tDQo+ID4gPiA+ICBE
b2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvdXNiL2ZzbC11c2IudHh0IHwgMTMNCj4g
PiA+ID4gKysrKysrKystLS0tLQ0KPiA+ID4gPiAgMSBmaWxlIGNoYW5nZWQsIDggaW5zZXJ0aW9u
cygrKSwgNSBkZWxldGlvbnMoLSkNCj4gPiA+DQo+ID4gPiBQbGVhc2UgQ0MgZGV2aWNldHJlZUB2
Z2VyLmtlcm5lbC5vcmcgb24gYWxsIGRldmljZSB0cmVlIHBhdGNoZXMgKGluDQo+ID4gPiBhZGRp
dGlvbiB0byBsaW51eHBwYy1kZXYpLg0KPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gZGlmZiAtLWdp
dCBhL0RvY3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy91c2IvZnNsLXVzYi50eHQNCj4g
PiA+ID4gYi9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvdXNiL2ZzbC11c2IudHh0
DQo+ID4gPiA+IGluZGV4IDQ3NzljMDIuLjVhM2EwYTggMTAwNjQ0DQo+ID4gPiA+IC0tLSBhL0Rv
Y3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy91c2IvZnNsLXVzYi50eHQNCj4gPiA+ID4g
KysrIGIvRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL3VzYi9mc2wtdXNiLnR4dA0K
PiA+ID4gPiBAQCAtMTAsNyArMTAsMTAgQEAgUmVxdWlyZWQgcHJvcGVydGllcyA6DQo+ID4gPiA+
ICAgICBjb250cm9sbGVycywgb3IgImZzbC11c2IyLWRyIiBmb3IgZHVhbCByb2xlIFVTQiBjb250
cm9sbGVycw0KPiA+ID4gPiAgICAgb3IgImZzbCxtcGM1MTIxLXVzYjItZHIiIGZvciBkdWFsIHJv
bGUgVVNCIGNvbnRyb2xsZXJzIG9mIE1QQzUxMjEuDQo+ID4gPiA+ICAgICBXaGVyZXZlciBhcHBs
aWNhYmxlLCB0aGUgSVAgdmVyc2lvbiBvZiB0aGUgVVNCIGNvbnRyb2xsZXIgc2hvdWxkDQo+ID4g
PiA+IC0gICBhbHNvIGJlIG1lbnRpb25lZCAoZm9yIGVnLiBmc2wtdXNiMi1kci12Mi4yIGZvciBi
c2M5MTMyKS4NCj4gPiA+ID4gKyAgIGFsc28gYmUgbWVudGlvbmVkIGluIGFub3RoZXIgc3RyaW5n
Lg0KPiA+ID4gPiArICAgRm9yIG11bHRpIHBvcnQgaG9zdCBVU0IgY29udHJvbGxlciB3aXRoIElQ
IHZlcnNpb24gPElQX1Zlcj4sIGl0IHNob3VsZA0KPiBiZQ0KPiA+ID4gPiArICAgImZzbC11c2Iy
LW1waC08SVBfVmVyPiIuIEZvciBkdWFsIHJvbGUgVVNCIGNvbnRyb2xsZXIgd2l0aCBJUCB2ZXJz
aW9uDQo+ID4gPiA+ICsgICA8SVBfVmVyPiwgaXQgc2hvdWxkIGJlICJmc2wtdXNiMi1kci08SVBf
VmVyPiIuDQo+ID4gPg0KPiA+ID4gSXQgd2FzIGRvY3VtZW50ZWQgYmVmb3JlIC0tIHRoaXMgaXMg
anVzdCBtYWtpbmcgaXQgbW9yZSBleHBsaWNpdCwgcmlnaHQ/DQo+ID4gPg0KPiA+ID4gRldJVywg
dGhlIHZlcnNpb24gbnVtYmVyIGNhbiBiZSByZWFkIG91dCBvZiBhIFVTQiByZWdpc3Rlciwgc28g
SSdkDQo+ID4gPiByYXRoZXIgcmVtb3ZlIHRoZSBzdWdnZXN0aW9uIHRvIHNwZWNpZnkgdGhlIHZl
cnNpb24gbnVtYmVyIGFuZA0KPiA+ID4gcmVwbGFjZSBpdCB3aXRoIGEgcmVmZXJlbmNlIHRvIHRo
ZSBJRCByZWdpc3Rlci4NCj4gPiB3ZSBoYXZlIGZvbGxvd2luZyB0d28gaXNzdWVzIC0NCj4gPiAo
YSkgb3VyIFVTQklQIHZlcnNpb24gcmVnaXN0ZXIgZG9lc24ndCBoYXZlIGNvbnNpc3RlbnQgInZl
cnNpb24gZmllbGQNCj4gPiBzaXplIiBvdmVyIG11bHRpcGxlIHZlcnNpb24ocykuIFRoaXMgaXMg
d2h5IHdlIGNvdWxkbid0IHVzZSBpdCBmb3INCj4gPiByZWFkaW5nIHZlcnNpb24gaW5mbyBhY3Jv
c3MgdmFyaW91cyBJUCB2ZXJzaW9ucw0KPiA+IChiKSB0aGlzIHJlZ2lzdGVyIGlzIG5vdCBleHBv
c2VkIGluIGFsbCBTb0MgUk1zIChwcm9iYWJseSBiZWNhdXNlIG9mDQo+ID4gYWJvdmUgcmVhc29u
KQ0KPiANCj4gOi0oDQo+IA0KPiBJZiB0aGlzIGlzIGp1c3QgYSBwcm9ibGVtIHdpdGggb2xkZXIg
Y2hpcHMsIHdlIGNvdWxkIGhhdmUgYSBuZXcgY29tcGF0aWJsZSBuYW1lDQo+IHRoYXQgZGVzaWdu
YXRlcyB0aGUgZmFtaWx5IG9mIFVTQiBibG9jayB2ZXJzaW9ucyB3aXRoIGEgc2FuZSB2ZXJzaW9u
IHJlZ2lzdGVyLg0KPiANCndlIGNvdWxkIGhhdmUgZG9uZS4uLmJ1dCB3ZSBoYXZlIGEgcmVxdWly
ZW1lbnQgdG8gd3JpdGUgdmVyc2lvbiBzcGVjaWZpYyBjb2RlLi4uDQpmb3IgaW5zdGFuY2UsIHVz
YiBjb250cm9sbGVyIGluaXQgc2VxdWVuY2UgaGFzIGNoYW5nZXMgZnJvbSB2ZXJzaW9uIDIuNSBv
bndhcmRzLi4uDQp0aGVuIHRoZXJlIGFyZSB2ZXJzaW9uIHNwZWNpZmljIGVycmF0YSBmaXhlKHMp
IGFsc28uIEhlbmNlIHdlIGRlY2lkZWQgdG8gZ28gZm9yDQpjb21wYXRpYmxlIHN0cmluZyBjb250
YWluaW5nIGh3IGlwIHZlcnNpb24gKG1ham9yIG5vLikgc28gdGhhdCBvdXIgd29ya2Fyb3VuZC9j
b2RlIGlzDQpjb25zaXN0ZW50IHdpdGggaHcgaXAgdmVyc2lvbihzKSBwdWJsaXNoZWQgaW4gZXJy
YXRhKHMpDQogDQo+ID4gPiA+IEBAIC01NSw5ICs1OCw5IEBAIEV4YW1wbGUgbXVsdGkgcG9ydCBo
b3N0IFVTQiBjb250cm9sbGVyIGRldmljZSBub2RlIDoNCj4gPiA+ID4gIAkJcG9ydDE7DQo+ID4g
PiA+ICAJfTsNCj4gPiA+ID4NCj4gPiA+ID4gLUV4YW1wbGUgZHVhbCByb2xlIFVTQiBjb250cm9s
bGVyIGRldmljZSBub2RlIDoNCj4gPiA+ID4gK0V4YW1wbGUgZHVhbCByb2xlIFVTQiBjb250cm9s
bGVyIHZlcnNpb24gMi41IGRldmljZSBub2RlIDoNCj4gPiA+ID4gIAl1c2JAMjMwMDAgew0KPiA+
ID4gPiAtCQljb21wYXRpYmxlID0gImZzbC11c2IyLWRyIjsNCj4gPiA+ID4gKwkJY29tcGF0aWJs
ZSA9ICJmc2wtdXNiMi1kci12Mi41IiwgImZzbC11c2IyLWRyIjsNCj4gPiA+ID4gIAkJcmVnID0g
PDIzMDAwIDEwMDA+Ow0KPiA+ID4gPiAgCQkjYWRkcmVzcy1jZWxscyA9IDwxPjsNCj4gPiA+ID4g
IAkJI3NpemUtY2VsbHMgPSA8MD47DQo+ID4gPg0KPiA+ID4gVGhpcyBleGFtcGxlIGRvZXNuJ3Qg
Y29ycmVzcG9uZCB0byBhbnkgZGV2aWNlIHRyZWUgSSBzZWUuICBFdmVuDQo+ID4gPiBhZnRlciB5
b3VyIG5leHQgcGF0Y2ggdGhhdCBzZXRzIHQyMDgwJ3MgVVNCIHRvIHYyLjUsIHRoZSBhZGRyZXNz
ZXMgYXJlDQo+IGRpZmZlcmVudC4NCj4gPiA+DQo+ID4gSSByZWNrb24gdGhhdCB0aGUgZXhhbXBs
ZSBlbXBoYXNpemVzIG9uIHNob3dpbmcgaG93IElQIHZlcnNpb24NCj4gPiBpbmZvcm1hdGlvbiBp
cyB0byBiZSBzdG9yZWQgaW4gImNvbXBhdGlibGUgc3RyaW5nIi4gSXMgaXQgbmVjZXNzYXJ5IHRv
DQo+ID4gbWFrZSBzdXJlIHRoYXQgd2Ugc2hvdWxkIGFsd2F5cyBzaXRlIGFjdHVhbCB2YWx1ZXMg
YWxyZWFkeSB1c2VkPw0KPiANCj4gVGhlIG1vcmUgcmVhbGlzdGljIHRoZSBleGFtcGxlcyBhcmUs
IHRoZSBiZXR0ZXIuDQo+IA0KdW5kZXJzdG9vZC4uLndlIGFncmVlIA0KDQo+IC1TY290dA0KPiAN
Cg0K
^ permalink raw reply
* Re: [PATCH v2] powerpc: Fix warning reported by verify_cpu_node_mapping()
From: Li Zhong @ 2014-08-27 9:10 UTC (permalink / raw)
To: Nathan Fontenot
Cc: Michael Ellerman, Paul Mackerras, Nishanth Aravamudan,
PowerPC email list
In-Reply-To: <1409103671.2466.15.camel@TP420>
On 三, 2014-08-27 at 09:41 +0800, Li Zhong wrote:
> 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.000000] 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 <zhong@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: c0000000fea40000 ti: c0000000fea80000 task.ti: c0000000fea80000
> > NIP: c0000000001afad8 LR: c000000000193b68 CTR: 0000000000000000
> > REGS: c0000000fea839e0 TRAP: 0300 Not tainted (3.16.0-202712-g9e81330-dirty)
> > MSR: 8000000100009033 <SF,EE,ME,IR,DR,RI,LE> CR: 24000000 XER: 20000004
> > CFAR: c0000000000084d4 DAR: 0000000000001690 DSISR: 40000000 SOFTE: 1
> > GPR00: c000000000b6db9c c0000000fea83c60 c000000000cd0628 0000000000001688
> > GPR04: 0000000000000001 0000000000000000 c0000000fea83c80 0000000009900000
> > GPR08: c000000000d531e0 c000000000d66218 c000000000d60628 ffffffffffffffff
> > GPR12: ffffffffffffffff c00000000ec60000 c00000000000bc88 0000000000000000
> > GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > GPR20: 0000000000000000 0000000000000000 c000000000c21b88 c000000000c03738
> > GPR24: c000000000c03638 c000000000d24b10 c000000000c03638 c000000000c03738
> > GPR28: 0000000000000080 0000000000000080 c000000000d208e8 0000000000000010
> > NIP [c0000000001afad8] next_zones_zonelist+0x8/0xa0
> > LR [c000000000193b68] local_memory_node+0x38/0x60
> > Call Trace:
> > [c0000000fea83c60] [c0000000fea83c90] 0xc0000000fea83c90 (unreliable)
> > [c0000000fea83c90] [c000000000b6db9c] smp_prepare_cpus+0x16c/0x278
> > [c0000000fea83d00] [c000000000b64098] kernel_init_freeable+0x150/0x340
> > [c0000000fea83dc0] [c00000000000bca4] kernel_init+0x24/0x140
> > [c0000000fea83e30] [c000000000009560] ret_from_kernel_thread+0x5c/0x7c
> > Instruction dump:
> > e9230038 39490f00 7fa35040 409c000c 38630780 4e800020 7d234b78 4bffff64
> > 60000000 60420000 2c250000 40c2004c <81230008> 7f892040 419d0014 48000030
> > ---[ end trace cb88537fdc8fa200 ]---
> >
> > Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> >
> > 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.
Hi, Nathan, Nish,
I did some draft code based on the above approach, and will send it out.
Could you please help to have a review?
I split the code to separate patches, so each small patch addressed only
one small issue.
Thanks, Zhong
>
> 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. smp_prepare_cpus().
> > */
> > for_each_possible_cpu(cpu) {
> > - cpu_numa_callback(&ppc64_numa_nb, CPU_UP_PREPARE,
> > - (void *)(unsigned long)cpu);
> > + numa_setup_cpu((unsigned long)cpu);
> > }
> > }
> >
> >
>
^ permalink raw reply
* [RFC PATCH v3 1/3] powerpc: Fix warning reported by verify_cpu_node_mapping()
From: Li Zhong @ 2014-08-27 9:33 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Li Zhong, Nishanth Aravamudan, paulus, Nathan Fontenot
With commit 2fabf084b6ad ("powerpc: reorder per-cpu NUMA information's
initialization"), 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.000000] 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().
Cc: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
---
arch/powerpc/mm/numa.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index d7737a5..9918c02 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -1128,8 +1128,7 @@ void __init do_init_bootmem(void)
* 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);
+ numa_setup_cpu((unsigned long)cpu);
}
}
--
1.9.1
^ permalink raw reply related
* [RFC PATCH v3 2/3] powerpc: Only set numa node information for present cpus at boottime
From: Li Zhong @ 2014-08-27 9:34 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Li Zhong, Nishanth Aravamudan, paulus, Nathan Fontenot
In-Reply-To: <1409132041-11890-1-git-send-email-zhong@linux.vnet.ibm.com>
As Nish suggested, it makes more sense to init the numa node informatiion
for present cpus at boottime, which could also avoid WARN_ON(1) in
numa_setup_cpu().
With this change, we also need to change the smp_prepare_cpus() to set up
numa information only on present cpus.
For those possible, but not present cpus, their numa information
will be set up after they are started, as the original code did before commit
2fabf084b6ad.
Cc: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
---
arch/powerpc/kernel/smp.c | 10 ++++++++--
arch/powerpc/mm/numa.c | 2 +-
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index a0738af..dc0e774 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -379,8 +379,11 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
/*
* numa_node_id() works after this.
*/
- set_cpu_numa_node(cpu, numa_cpu_lookup_table[cpu]);
- set_cpu_numa_mem(cpu, local_memory_node(numa_cpu_lookup_table[cpu]));
+ if (cpu_present(cpu)) {
+ set_cpu_numa_node(cpu, numa_cpu_lookup_table[cpu]);
+ set_cpu_numa_mem(cpu,
+ local_memory_node(numa_cpu_lookup_table[cpu]));
+ }
}
cpumask_set_cpu(boot_cpuid, cpu_sibling_mask(boot_cpuid));
@@ -728,6 +731,9 @@ void start_secondary(void *unused)
}
traverse_core_siblings(cpu, true);
+ set_numa_node(numa_cpu_lookup_table[cpu]);
+ set_numa_mem(local_memory_node(numa_cpu_lookup_table[cpu]));
+
smp_wmb();
notify_cpu_starting(cpu);
set_cpu_online(cpu, true);
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 9918c02..3a9061e 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -1127,7 +1127,7 @@ 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) {
+ for_each_present_cpu(cpu) {
numa_setup_cpu((unsigned long)cpu);
}
}
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox