Re: [RFC][PATCH 1/3] powerpc: Don't force ENOSYS as error on syscall fail
Obvious mistake on my behalf to send the patch with lines commented out. I will fix it in v2. On 09.02.2015 09:55, Bogdan Purcareata wrote: In certain scenarios - e.g. seccomp filtering with ERRNO as default action - the system call fails for other reasons than the syscall not being available. The seccomp filter can be configured to store a user-defined error code on return from a blacklisted syscall. The RFC is this: are there currently any user-space scenarios where it is required that the system call return ENOSYS as error code on failure, no matter the circumstances? I don't want to break userspace requirements. I have not added code to force this error code in situations different than secure_computing failure, in order to keep overhead at a minimum. Signed-off-by: Bogdan Purcareata bogdan.purcare...@freescale.com --- arch/powerpc/kernel/entry_32.S | 3 ++- arch/powerpc/kernel/entry_64.S | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S index 59848e5..52e48dd 100644 --- a/arch/powerpc/kernel/entry_32.S +++ b/arch/powerpc/kernel/entry_32.S @@ -425,7 +425,8 @@ END_FTR_SECTION_IFSET(CPU_FTR_NEED_PAIRED_STWCX) b 1b #endif /* CONFIG_44x */ -66:li r3,-ENOSYS +66: +# li r3,-ENOSYS b ret_from_syscall .globl ret_from_fork diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S index e6bfe8e..80db02e 100644 --- a/arch/powerpc/kernel/entry_64.S +++ b/arch/powerpc/kernel/entry_64.S @@ -269,7 +269,7 @@ syscall_dotrace: b .Lsyscall_dotrace_cont syscall_enosys: - li r3,-ENOSYS +# li r3,-ENOSYS b syscall_exit syscall_exit_work: ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powernv: Add OPAL soft-poweroff routine
On 01/30/2015 12:13 PM, Joel Stanley wrote:
Register a notifier for a OPAL message indicating that the machine
should prepare itself for a graceful power off.
OPAL will tell us if the power off is a reboot or shutdown, but for now
we perform the same orderly_poweroff action.
Signed-off-by: Joel Stanley j...@jms.id.au
---
v2:
- combine the reboot and off cases, as they are the same code
arch/powerpc/include/asm/opal.h | 2 +-
arch/powerpc/platforms/powernv/Makefile | 2 +-
arch/powerpc/platforms/powernv/opal-power.c | 66
+
3 files changed, 68 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/platforms/powernv/opal-power.c
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index ca2dd45..cdf32c0 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -250,7 +250,7 @@ enum OpalMessageType {
*/
OPAL_MSG_MEM_ERR,
OPAL_MSG_EPOW,
- OPAL_MSG_SHUTDOWN,
+ OPAL_MSG_SHUTDOWN, /* params[0] = 1 reboot, 0 shutdown */
OPAL_MSG_HMI_EVT,
OPAL_MSG_TYPE_MAX,
};
diff --git a/arch/powerpc/platforms/powernv/Makefile
b/arch/powerpc/platforms/powernv/Makefile
index f241acc..6f3c5d3 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -1,7 +1,7 @@
obj-y+= setup.o opal-wrappers.o opal.o opal-async.o
obj-y+= opal-rtc.o opal-nvram.o opal-lpc.o
opal-flash.o
obj-y+= rng.o opal-elog.o opal-dump.o
opal-sysparam.o opal-sensor.o
-obj-y+= opal-msglog.o opal-hmi.o
+obj-y+= opal-msglog.o opal-hmi.o opal-power.o
obj-$(CONFIG_SMP)+= smp.o subcore.o subcore-asm.o
obj-$(CONFIG_PCI)+= pci.o pci-p5ioc2.o pci-ioda.o
diff --git a/arch/powerpc/platforms/powernv/opal-power.c
b/arch/powerpc/platforms/powernv/opal-power.c
new file mode 100644
index 000..bbc1054
--- /dev/null
+++ b/arch/powerpc/platforms/powernv/opal-power.c
@@ -0,0 +1,66 @@
+/*
+ * PowerNV OPAL power control for graceful shutdown handling
+ *
+ * Copyright 2015 IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include linux/kernel.h
+#include linux/reboot.h
+#include linux/notifier.h
+
+#include asm/opal.h
+#include asm/machdep.h
+
+#define SOFT_OFF 0x00
+#define SOFT_REBOOT 0x01
Better move these macros to opal.h as its coming from OPAL API?
Also I think its to merge this code and Anshumans' EPOW driver and create single
event file.
-Vasant
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] perf/e6500: Make event translations available in sysfs
On Fri, Feb 06, 2015 at 04:43:54PM -0600, Tom Huynh wrote: arch/powerpc/perf/e6500-events-list.h | 289 ++ That's a lot of events to stuff in the kernel, would a userspace list not be more convenient? ISTR there being various discussions on providing support for that in tools/perf, Jiri? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V11 02/17] PCI/IOV: add VF enable/disable hook
On Tue, 2015-02-10 at 09:35 +0800, Wei Yang wrote: Don't we want pcibios_sriov_enable() to be able to crop the number of VFs or do we think any resource limits have been applied already ? The second parameter initial is the number of VFs will be enabled. Arch dependent function will check the resources for these number of VFs. Do I catch your question correctly? I was wondering if the number of resource that can be enabled is smaller, should the arch function be able to return that smaller number and we would still enable that number ? Ie, have the arch function be able to update the value of initial (by passing it by pointer for example). Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 04/18] powerpc/powernv: relocate struct opal_sg_entry in opal.h to same place it is in firmware
For whatever reason these structures were in different places.
Now they are not.
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h | 48 +++
1 file changed, 23 insertions(+), 25 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index e8d9bfc..0f9f06d 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -12,31 +12,6 @@
#ifndef __OPAL_H
#define __OPAL_H
-#ifndef __ASSEMBLY__
-/*
- * SG entry
- *
- * WARNING: The current implementation requires each entry
- * to represent a block that is 4k aligned *and* each block
- * size except the last one in the list to be as well.
- */
-struct opal_sg_entry {
- __be64 data;
- __be64 length;
-};
-
-/* SG list */
-struct opal_sg_list {
- __be64 length;
- __be64 next;
- struct opal_sg_entry entry[];
-};
-
-/* We calculate number of sg entries based on PAGE_SIZE */
-#define SG_ENTRIES_PER_NODE ((PAGE_SIZE - 16) / sizeof(struct opal_sg_entry))
-
-#endif /* __ASSEMBLY__ */
-
/** OPAL APIs **/
/* Return codes */
@@ -740,6 +715,29 @@ typedef struct oppanel_line {
uint64_tline_len;
} oppanel_line_t;
+/*
+ * SG entry
+ *
+ * WARNING: The current implementation requires each entry
+ * to represent a block that is 4k aligned *and* each block
+ * size except the last one in the list to be as well.
+ */
+struct opal_sg_entry {
+ __be64 data;
+ __be64 length;
+};
+
+/* SG list */
+struct opal_sg_list {
+ __be64 length;
+ __be64 next;
+ struct opal_sg_entry entry[];
+};
+
+/* We calculate number of sg entries based on PAGE_SIZE */
+#define SG_ENTRIES_PER_NODE ((PAGE_SIZE - 16) / sizeof(struct opal_sg_entry))
+
+
/* OPAL I2C request */
struct opal_i2c_request {
uint8_t type;
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 06/18] powerpc/powernv: move OPAL_DUMP_REGION defines in opal.h to same place as in firmware opal.h
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 9ca5167..7075f57 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -733,6 +733,13 @@ struct opal_sg_list {
struct opal_sg_entry entry[];
};
+/*
+ * Dump region ID range usable by the OS
+ */
+#define OPAL_DUMP_REGION_HOST_START0x80
+#define OPAL_DUMP_REGION_LOG_BUF 0x80
+#define OPAL_DUMP_REGION_HOST_END 0xFF
+
/* We calculate number of sg entries based on PAGE_SIZE */
#define SG_ENTRIES_PER_NODE ((PAGE_SIZE - 16) / sizeof(struct opal_sg_entry))
@@ -979,13 +986,6 @@ struct opal_sg_list *opal_vmalloc_to_sg_list(void
*vmalloc_addr,
unsigned long vmalloc_size);
void opal_free_sg_list(struct opal_sg_list *sg);
-/*
- * Dump region ID range usable by the OS
- */
-#define OPAL_DUMP_REGION_HOST_START0x80
-#define OPAL_DUMP_REGION_LOG_BUF 0x80
-#define OPAL_DUMP_REGION_HOST_END 0xFF
-
#endif /* __ASSEMBLY__ */
#endif /* __OPAL_H */
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 03/18] powerpc/powernv: s/OPAL_PCI_SET_PHB_CXL_MODE/OPAL_PCI_SET_PHB_CAPI_MODE/ to match firmware
On Tue, 2015-02-10 at 13:26 +1100, Stewart Smith wrote: --- a/arch/powerpc/platforms/powernv/pci-ioda.c +++ b/arch/powerpc/platforms/powernv/pci-ioda.c @@ -1481,9 +1481,9 @@ int pnv_phb_to_cxl(struct pci_dev *dev) pe_info(pe, Switching PHB to CXL\n); - rc = opal_pci_set_phb_cxl_mode(phb-opal_id, 1, pe-pe_number); + rc = opal_pci_set_phb_capi_mode(phb-opal_id, 1, pe-pe_number); if (rc) - dev_err(dev-dev, opal_pci_set_phb_cxl_mode failed: %i\n, rc); + dev_err(dev-dev, opal_pci_set_phb_capi_mode failed: %i\n, rc); return rc; } Add a comment above the call: /* CAPI is the IBM/Firmware name for CXL */ Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/18] sync opal.h with firmware
On Tue, 2015-02-10 at 13:26 +1100, Stewart Smith wrote: This patch series takes a careful step-by-step process to sync the opal.h header file (definition of interface to OPAL firmware) with opal.h in firmware. Each patch is designed to be as obvious as possible so that it's easy for someone else to prove that I haven't messed it up anywhere. In the process of doing this, I fixed a few things in firmware too, so this matches skiboot at 4681ed9, which is a little after the most recent skiboot release (4.1.1). The biggest change is moving the function prototypes for API calls out to opal-api.h. Hi Stewart, I'm going to be a total pain, and suggest that this is the wrong approach :) I was on board until patch 15, where you have to add an #ifdef SKIBOOT to guard an include, and you have to remove an include on the Linux side. I think the better solution would be to pull all the common parts out into a new file, opal-api.h. That file would define the API between Linux Skiboot, and absolutely nothing else. Both Linux and Skiboot would continue to have an opal.h, which would include opal-api.h, and then anything else needed on either side to make a functioning opal.h - eg. other includes definitions (SG_ENTRIES_PER_NODE). It would also have the advantage that because opal-api.h is a new file, we can get it synced from the beginning and not worry about all the whitespace rearranging patches. ie. there'd just be one patch on both sides to add the new file and move definitions into it from opal.h. If you don't violently disagree I'll do a patch for that and we can see how it looks? cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V11 07/17] powerpc/pci: Don't unset pci resources for VFs
On Tue, Feb 10, 2015 at 11:36:24AM +1100, Benjamin Herrenschmidt wrote:
On Thu, 2015-01-15 at 10:27 +0800, Wei Yang wrote:
If we're going to reassign resources with flag PCI_REASSIGN_ALL_RSRC, all
resources will be cleaned out during device header fixup time and then get
reassigned by PCI core. However, the VF resources won't be reassigned and
thus, we shouldn't clean them out.
This patch adds a condition. If the pci_dev is a VF, skip the resource
unset process.
I don't understand this, can you elaborate ? Why wouldn't we reassign
the IOV resource just like everything else ?
Sure.
VFs work a little bit different from normal devices. On powernv platform, we
have PCI_REASSIGN_ALL_RSRC set, which means all resource retrieved from
hardware will be cleaned and re-assigned by kernel. While VF's resources are
calculated from PF's IOV BAR, in virtfn_add(). And after this, there is not
re-assign process for VFs.
Ben.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
---
arch/powerpc/kernel/pci-common.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/kernel/pci-common.c
b/arch/powerpc/kernel/pci-common.c
index 37d512d..889f743 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -788,6 +788,10 @@ static void pcibios_fixup_resources(struct pci_dev *dev)
pci_name(dev));
return;
}
+
+if (dev-is_virtfn)
+return;
+
for (i = 0; i DEVICE_COUNT_RESOURCE; i++) {
struct resource *res = dev-resource + i;
struct pci_bus_region reg;
--
Richard Yang
Help you, Help me
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 00/18] sync opal.h with firmware
This patch series takes a careful step-by-step process to sync the opal.h header file (definition of interface to OPAL firmware) with opal.h in firmware. Each patch is designed to be as obvious as possible so that it's easy for someone else to prove that I haven't messed it up anywhere. In the process of doing this, I fixed a few things in firmware too, so this matches skiboot at 4681ed9, which is a little after the most recent skiboot release (4.1.1). The biggest change is moving the function prototypes for API calls out to opal-api.h. Stewart Smith (18): powerpc/powernv: sync OPAL API tokens with skiboot powerpc/powernv: synchronize OPAL calls and return codes with firmware powerpc/powernv: s/OPAL_PCI_SET_PHB_CXL_MODE/OPAL_PCI_SET_PHB_CAPI_MODE/ to match firmware powerpc/powernv: relocate struct opal_sg_entry in opal.h to same place it is in firmware powerpc/powernv: synchronize opal.h whitespace with firmware powerpc/powernv: move OPAL_DUMP_REGION defines in opal.h to same place as in firmware opal.h powerpc/powernv: make whitespace for OPAL_PM_* defines match firmware powerpc/powernv: Move OpalSysparamPerm,OpalMessageType in opal.h to match firmware powerpc/powernv: match enum OpalMessageType with firmware powerpc/powernv: move OPAL API prototypes to opal-api.h powerpc/powernv: make whitespace in enum OpalSysparamPerm match firmware powerpc/powernv: add CAPI and EPOW parts to opal.h powerpc/powernv: add remaining missing enums to opal.h powerpc/powernv: sync comments and whitespace in opal.h with firmware powerpc/powernv: sync #includes in opal.h with firmware powerpc/powernv: move SG_ENTRIES_PER_NODE to linux-specific opal-api.h powerpc/powernv: s/u8/uint8_t/ to match firmware in opal.h powerpc/powernv: s/OpalM64EnableAction/OpalM64Action/ and __be64 annotation arch/powerpc/include/asm/opal-api.h| 244 ++ arch/powerpc/include/asm/opal.h| 492 +++- arch/powerpc/kernel/prom.c |1 + arch/powerpc/platforms/powernv/eeh-ioda.c |1 + arch/powerpc/platforms/powernv/eeh-powernv.c |1 + arch/powerpc/platforms/powernv/opal-async.c|1 + arch/powerpc/platforms/powernv/opal-dump.c |1 + arch/powerpc/platforms/powernv/opal-elog.c |1 + arch/powerpc/platforms/powernv/opal-flash.c|1 + arch/powerpc/platforms/powernv/opal-hmi.c |1 + arch/powerpc/platforms/powernv/opal-lpc.c |1 + .../powerpc/platforms/powernv/opal-memory-errors.c |1 + arch/powerpc/platforms/powernv/opal-msglog.c |1 + arch/powerpc/platforms/powernv/opal-nvram.c|1 + arch/powerpc/platforms/powernv/opal-rtc.c |1 + arch/powerpc/platforms/powernv/opal-sensor.c |1 + arch/powerpc/platforms/powernv/opal-sysparam.c |1 + arch/powerpc/platforms/powernv/opal-wrappers.S |2 +- arch/powerpc/platforms/powernv/opal-xscom.c|1 + arch/powerpc/platforms/powernv/opal.c |1 + arch/powerpc/platforms/powernv/pci-ioda.c |5 +- arch/powerpc/platforms/powernv/pci-p5ioc2.c|1 + arch/powerpc/platforms/powernv/pci.c |1 + arch/powerpc/platforms/powernv/setup.c |1 + arch/powerpc/platforms/powernv/smp.c |1 + arch/powerpc/platforms/powernv/subcore.c |1 + arch/powerpc/sysdev/xics/ics-opal.c|1 + drivers/char/ipmi/ipmi_powernv.c |2 +- drivers/hwmon/ibmpowernv.c |1 + drivers/i2c/busses/i2c-opal.c |1 + drivers/rtc/rtc-opal.c |1 + drivers/tty/hvc/hvc_opal.c |1 + 32 files changed, 450 insertions(+), 322 deletions(-) create mode 100644 arch/powerpc/include/asm/opal-api.h -- 1.7.10.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 01/18] powerpc/powernv: sync OPAL API tokens with skiboot
This patch just matches whitespace and comments between
the opal.h from firmware and that in linux.
No addition/removal.
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index eb95b67..4694183 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -40,7 +40,7 @@ struct opal_sg_list {
/** OPAL APIs **/
/* Return codes */
-#define OPAL_SUCCESS 0
+#define OPAL_SUCCESS 0
#define OPAL_PARAMETER -1
#define OPAL_BUSY -2
#define OPAL_PARTIAL -3
@@ -109,7 +109,7 @@ struct opal_sg_list {
#define OPAL_GET_MSI_6440
#define OPAL_START_CPU 41
#define OPAL_QUERY_CPU_STATUS 42
-#define OPAL_WRITE_OPPANEL 43
+#define OPAL_WRITE_OPPANEL 43 /* unimplemented */
#define OPAL_PCI_MAP_PE_DMA_WINDOW 44
#define OPAL_PCI_MAP_PE_DMA_WINDOW_REAL45
#define OPAL_PCI_RESET 49
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 16/18] powerpc/powernv: move SG_ENTRIES_PER_NODE to linux-specific opal-api.h
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal-api.h |4
arch/powerpc/include/asm/opal.h |4
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/opal-api.h
b/arch/powerpc/include/asm/opal-api.h
index c4009dd..172d08e 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -237,4 +237,8 @@ extern void opal_lpc_init(void);
struct opal_sg_list *opal_vmalloc_to_sg_list(void *vmalloc_addr,
unsigned long vmalloc_size);
void opal_free_sg_list(struct opal_sg_list *sg);
+
+/* We calculate number of sg entries based on PAGE_SIZE */
+#define SG_ENTRIES_PER_NODE ((PAGE_SIZE - 16) / sizeof(struct opal_sg_entry))
+
#endif /* __OPAL_API_H */
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index b60a25a..2441f36 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -820,10 +820,6 @@ enum {
#define OPAL_PHB_CAPI_FLAG_SNOOP_CONTROL 0x0001
#define OPAL_PHB_CAPI_FLAG_REVERT_TO_PCIE 0x0002
-/* We calculate number of sg entries based on PAGE_SIZE */
-#define SG_ENTRIES_PER_NODE ((PAGE_SIZE - 16) / sizeof(struct opal_sg_entry))
-
-
/* OPAL I2C request */
struct opal_i2c_request {
uint8_t type;
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V11 07/17] powerpc/pci: Don't unset pci resources for VFs
On Tue, 2015-02-10 at 09:51 +0800, Wei Yang wrote:
On Tue, Feb 10, 2015 at 11:36:24AM +1100, Benjamin Herrenschmidt wrote:
On Thu, 2015-01-15 at 10:27 +0800, Wei Yang wrote:
If we're going to reassign resources with flag PCI_REASSIGN_ALL_RSRC, all
resources will be cleaned out during device header fixup time and then get
reassigned by PCI core. However, the VF resources won't be reassigned and
thus, we shouldn't clean them out.
This patch adds a condition. If the pci_dev is a VF, skip the resource
unset process.
I don't understand this, can you elaborate ? Why wouldn't we reassign
the IOV resource just like everything else ?
Sure.
VFs work a little bit different from normal devices. On powernv platform, we
have PCI_REASSIGN_ALL_RSRC set, which means all resource retrieved from
hardware will be cleaned and re-assigned by kernel. While VF's resources are
calculated from PF's IOV BAR, in virtfn_add(). And after this, there is not
re-assign process for VFs.
I still don't undertand, you mean SR-IOV is assigned before we assign
everybody else ? That doesn't make sense to me...
Ben.
Ben.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
---
arch/powerpc/kernel/pci-common.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/kernel/pci-common.c
b/arch/powerpc/kernel/pci-common.c
index 37d512d..889f743 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -788,6 +788,10 @@ static void pcibios_fixup_resources(struct pci_dev
*dev)
pci_name(dev));
return;
}
+
+ if (dev-is_virtfn)
+ return;
+
for (i = 0; i DEVICE_COUNT_RESOURCE; i++) {
struct resource *res = dev-resource + i;
struct pci_bus_region reg;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 05/18] powerpc/powernv: synchronize opal.h whitespace with firmware
reduces the diff between linux and firmware header files significantly.
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h | 51 +++
1 file changed, 25 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 0f9f06d..9ca5167 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -251,33 +251,32 @@ enum OpalShpcLinkState {
enum OpalMmioWindowType {
OPAL_M32_WINDOW_TYPE = 1,
OPAL_M64_WINDOW_TYPE = 2,
- OPAL_IO_WINDOW_TYPE = 3
+ OPAL_IO_WINDOW_TYPE = 3
};
-
enum OpalShpcSlotState {
OPAL_SHPC_DEV_NOT_PRESENT = 0,
- OPAL_SHPC_DEV_PRESENT = 1
+ OPAL_SHPC_DEV_PRESENT = 1
};
enum OpalExceptionHandler {
- OPAL_MACHINE_CHECK_HANDLER = 1,
+ OPAL_MACHINE_CHECK_HANDLER = 1,
OPAL_HYPERVISOR_MAINTENANCE_HANDLER = 2,
- OPAL_SOFTPATCH_HANDLER = 3
+ OPAL_SOFTPATCH_HANDLER = 3
};
enum OpalPendingState {
- OPAL_EVENT_OPAL_INTERNAL= 0x1,
- OPAL_EVENT_NVRAM= 0x2,
- OPAL_EVENT_RTC = 0x4,
- OPAL_EVENT_CONSOLE_OUTPUT = 0x8,
- OPAL_EVENT_CONSOLE_INPUT= 0x10,
- OPAL_EVENT_ERROR_LOG_AVAIL = 0x20,
- OPAL_EVENT_ERROR_LOG= 0x40,
- OPAL_EVENT_EPOW = 0x80,
- OPAL_EVENT_LED_STATUS = 0x100,
- OPAL_EVENT_PCI_ERROR= 0x200,
- OPAL_EVENT_DUMP_AVAIL = 0x400,
- OPAL_EVENT_MSG_PENDING = 0x800,
+ OPAL_EVENT_OPAL_INTERNAL = 0x1,
+ OPAL_EVENT_NVRAM = 0x2,
+ OPAL_EVENT_RTC = 0x4,
+ OPAL_EVENT_CONSOLE_OUTPUT = 0x8,
+ OPAL_EVENT_CONSOLE_INPUT = 0x10,
+ OPAL_EVENT_ERROR_LOG_AVAIL = 0x20,
+ OPAL_EVENT_ERROR_LOG = 0x40,
+ OPAL_EVENT_EPOW= 0x80,
+ OPAL_EVENT_LED_STATUS = 0x100,
+ OPAL_EVENT_PCI_ERROR = 0x200,
+ OPAL_EVENT_DUMP_AVAIL = 0x400,
+ OPAL_EVENT_MSG_PENDING = 0x800,
};
enum OpalMessageType {
@@ -353,7 +352,7 @@ enum OpalPciReinitScope {
enum OpalPciResetState {
OPAL_DEASSERT_RESET = 0,
- OPAL_ASSERT_RESET = 1
+ OPAL_ASSERT_RESET = 1
};
enum OpalPciMaskAction {
@@ -451,17 +450,17 @@ struct OpalMemoryErrorData {
union {
/* Memory Resilience corrected/uncorrected error info */
struct {
- enum OpalMemErr_ResilErrType resil_err_type:8;
- uint8_t reserved_1[7];
- __be64 physical_address_start;
- __be64 physical_address_end;
+ enum OpalMemErr_ResilErrTyperesil_err_type:8;
+ uint8_t reserved_1[7];
+ __be64 physical_address_start;
+ __be64 physical_address_end;
} resilience;
/* Dynamic memory deallocation error info */
struct {
- enum OpalMemErr_DynErrType dyn_err_type:8;
- uint8_t reserved_1[7];
- __be64 physical_address_start;
- __be64 physical_address_end;
+ enum OpalMemErr_DynErrType dyn_err_type:8;
+ uint8_t reserved_1[7];
+ __be64 physical_address_start;
+ __be64 physical_address_end;
} dyn_dealloc;
} u;
};
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 03/18] powerpc/powernv: s/OPAL_PCI_SET_PHB_CXL_MODE/OPAL_PCI_SET_PHB_CAPI_MODE/ to match firmware
OPAL/IBM calls it CAPI and Linux calls it CXL because CAPI was taken.
In order to have opal.h match between firmware and Linux, we're going
to just deal with one call used in a place be CAPI rather than CXL to
match what's in firmware.
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h|4 ++--
arch/powerpc/platforms/powernv/opal-wrappers.S |2 +-
arch/powerpc/platforms/powernv/pci-ioda.c |4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 80cb4d3..e8d9bfc 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -158,7 +158,7 @@ struct opal_sg_list {
#define OPAL_SET_PARAM 90
#define OPAL_DUMP_RESEND 91
#define OPAL_ELOG_SEND 92 /* Deprecated */
-#define OPAL_PCI_SET_PHB_CXL_MODE 93
+#define OPAL_PCI_SET_PHB_CAPI_MODE 93
#define OPAL_DUMP_INFO294
#define OPAL_WRITE_OPPANEL_ASYNC 95
#define OPAL_PCI_ERR_INJECT96
@@ -923,7 +923,7 @@ int64_t opal_handle_hmi(void);
int64_t opal_register_dump_region(uint32_t id, uint64_t start, uint64_t end);
int64_t opal_unregister_dump_region(uint32_t id);
int64_t opal_slw_set_reg(uint64_t cpu_pir, uint64_t sprn, uint64_t val);
-int64_t opal_pci_set_phb_cxl_mode(uint64_t phb_id, uint64_t mode, uint64_t
pe_number);
+int64_t opal_pci_set_phb_capi_mode(uint64_t phb_id, uint64_t mode, uint64_t
pe_number);
int64_t opal_ipmi_send(uint64_t interface, struct opal_ipmi_msg *msg,
uint64_t msg_len);
int64_t opal_ipmi_recv(uint64_t interface, struct opal_ipmi_msg *msg,
diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S
b/arch/powerpc/platforms/powernv/opal-wrappers.S
index 0509bca..03eb6e3 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -286,7 +286,7 @@ OPAL_CALL(opal_handle_hmi,
OPAL_HANDLE_HMI);
OPAL_CALL(opal_slw_set_reg,OPAL_SLW_SET_REG);
OPAL_CALL(opal_register_dump_region, OPAL_REGISTER_DUMP_REGION);
OPAL_CALL(opal_unregister_dump_region, OPAL_UNREGISTER_DUMP_REGION);
-OPAL_CALL(opal_pci_set_phb_cxl_mode, OPAL_PCI_SET_PHB_CXL_MODE);
+OPAL_CALL(opal_pci_set_phb_capi_mode, OPAL_PCI_SET_PHB_CAPI_MODE);
OPAL_CALL(opal_tpo_write, OPAL_WRITE_TPO);
OPAL_CALL(opal_tpo_read, OPAL_READ_TPO);
OPAL_CALL(opal_ipmi_send, OPAL_IPMI_SEND);
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index fac88ed..3bc5917 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1481,9 +1481,9 @@ int pnv_phb_to_cxl(struct pci_dev *dev)
pe_info(pe, Switching PHB to CXL\n);
- rc = opal_pci_set_phb_cxl_mode(phb-opal_id, 1, pe-pe_number);
+ rc = opal_pci_set_phb_capi_mode(phb-opal_id, 1, pe-pe_number);
if (rc)
- dev_err(dev-dev, opal_pci_set_phb_cxl_mode failed: %i\n,
rc);
+ dev_err(dev-dev, opal_pci_set_phb_capi_mode failed: %i\n,
rc);
return rc;
}
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 14/18] powerpc/powernv: sync comments and whitespace in opal.h with firmware
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index c09cf66..2aaa861 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -346,6 +346,11 @@ enum OpalPciResetScope {
};
enum OpalPciReinitScope {
+ /*
+* Note: we chose values that do not overlap
+* OpalPciResetScope as OPAL v2 used the same
+* enum for both
+*/
OPAL_REINIT_PCI_DEV = 1000
};
@@ -423,10 +428,10 @@ enum {
};
struct opal_ipmi_msg {
- uint8_t version;
- uint8_t netfn;
- uint8_t cmd;
- uint8_t data[];
+ uint8_t version;
+ uint8_t netfn;
+ uint8_t cmd;
+ uint8_t data[];
};
/*
@@ -477,7 +482,6 @@ enum OpalMemErr_Version {
enum OpalMemErrType {
OPAL_MEM_ERR_TYPE_RESILIENCE= 0,
OPAL_MEM_ERR_TYPE_DYN_DALLOC,
- OPAL_MEM_ERR_TYPE_SCRUB,
};
/* Memory Reilience error type */
@@ -731,11 +735,10 @@ struct OpalIoPhb3ErrorData {
__be64 errorClass;
__be64 correlator;
+ /* PHB3 MMIO Error Regs */
__be64 nFir;/* 000 */
__be64 nFirMask;/* 003 */
__be64 nFirWOF; /* 008 */
-
- /* PHB3 MMIO Error Regs */
__be64 phbPlssr;/* 120 */
__be64 phbCsr; /* 110 */
__be64 lemFir; /* C00 */
@@ -772,7 +775,7 @@ typedef struct oppanel_line {
} oppanel_line_t;
/*
- * SG entry
+ * SG entries
*
* WARNING: The current implementation requires each entry
* to represent a block that is 4k aligned *and* each block
@@ -783,7 +786,11 @@ struct opal_sg_entry {
__be64 length;
};
-/* SG list */
+/*
+ * Candiate image SG list.
+ *
+ * length = VER | length
+ */
struct opal_sg_list {
__be64 length;
__be64 next;
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 11/18] powerpc/powernv: make whitespace in enum OpalSysparamPerm match firmware
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 4373010..240ee1c 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -398,9 +398,9 @@ struct opal_msg {
/* System parameter permission */
enum OpalSysparamPerm {
- OPAL_SYSPARAM_READ = 0x1,
- OPAL_SYSPARAM_WRITE = 0x2,
- OPAL_SYSPARAM_RW= (OPAL_SYSPARAM_READ | OPAL_SYSPARAM_WRITE),
+ OPAL_SYSPARAM_READ = 0x1,
+ OPAL_SYSPARAM_WRITE = 0x2,
+ OPAL_SYSPARAM_RW= (OPAL_SYSPARAM_READ | OPAL_SYSPARAM_WRITE),
};
enum {
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 10/18] powerpc/powernv: move OPAL API prototypes to opal-api.h
To further the cause of syncing opal.h between firmware and linux, move the function prototypes that were in opal.h out to opal-api.h and fix the associated includes. There are still a few places where opal.h is adequate. Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com --- arch/powerpc/include/asm/opal-api.h| 240 arch/powerpc/include/asm/opal.h| 224 -- arch/powerpc/kernel/prom.c |1 + arch/powerpc/platforms/powernv/eeh-ioda.c |1 + arch/powerpc/platforms/powernv/eeh-powernv.c |1 + arch/powerpc/platforms/powernv/opal-async.c|1 + arch/powerpc/platforms/powernv/opal-dump.c |1 + arch/powerpc/platforms/powernv/opal-elog.c |1 + arch/powerpc/platforms/powernv/opal-flash.c|1 + arch/powerpc/platforms/powernv/opal-hmi.c |1 + arch/powerpc/platforms/powernv/opal-lpc.c |1 + .../powerpc/platforms/powernv/opal-memory-errors.c |1 + arch/powerpc/platforms/powernv/opal-msglog.c |1 + arch/powerpc/platforms/powernv/opal-nvram.c|1 + arch/powerpc/platforms/powernv/opal-rtc.c |1 + arch/powerpc/platforms/powernv/opal-sensor.c |1 + arch/powerpc/platforms/powernv/opal-sysparam.c |1 + arch/powerpc/platforms/powernv/opal-xscom.c|1 + arch/powerpc/platforms/powernv/opal.c |1 + arch/powerpc/platforms/powernv/pci-ioda.c |1 + arch/powerpc/platforms/powernv/pci-p5ioc2.c|1 + arch/powerpc/platforms/powernv/pci.c |1 + arch/powerpc/platforms/powernv/setup.c |1 + arch/powerpc/platforms/powernv/smp.c |1 + arch/powerpc/platforms/powernv/subcore.c |1 + arch/powerpc/sysdev/xics/ics-opal.c|1 + drivers/char/ipmi/ipmi_powernv.c |2 +- drivers/hwmon/ibmpowernv.c |1 + drivers/i2c/busses/i2c-opal.c |1 + drivers/rtc/rtc-opal.c |1 + drivers/tty/hvc/hvc_opal.c |1 + 31 files changed, 269 insertions(+), 225 deletions(-) create mode 100644 arch/powerpc/include/asm/opal-api.h diff --git a/arch/powerpc/include/asm/opal-api.h b/arch/powerpc/include/asm/opal-api.h new file mode 100644 index 000..c4009dd --- /dev/null +++ b/arch/powerpc/include/asm/opal-api.h @@ -0,0 +1,240 @@ +/* + * PowerNV OPAL definitions. + * + * Copyright 2011 IBM Corp. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + */ + +#ifndef __OPAL_API_H +#define __OPAL_API_H + +/* Linux specific definitions for interfacing with OPAL */ + +/* /sys/firmware/opal */ +extern struct kobject *opal_kobj; + +/* /ibm,opal */ +extern struct device_node *opal_node; + +/* API functions */ +int64_t opal_invalid_call(void); +int64_t opal_console_write(int64_t term_number, __be64 *length, + const uint8_t *buffer); +int64_t opal_console_read(int64_t term_number, __be64 *length, + uint8_t *buffer); +int64_t opal_console_write_buffer_space(int64_t term_number, + __be64 *length); +int64_t opal_rtc_read(__be32 *year_month_day, + __be64 *hour_minute_second_millisecond); +int64_t opal_rtc_write(uint32_t year_month_day, + uint64_t hour_minute_second_millisecond); +int64_t opal_tpo_read(uint64_t token, __be32 *year_mon_day, __be32 *hour_min); +int64_t opal_tpo_write(uint64_t token, uint32_t year_mon_day, + uint32_t hour_min); +int64_t opal_cec_power_down(uint64_t request); +int64_t opal_cec_reboot(void); +int64_t opal_read_nvram(uint64_t buffer, uint64_t size, uint64_t offset); +int64_t opal_write_nvram(uint64_t buffer, uint64_t size, uint64_t offset); +int64_t opal_handle_interrupt(uint64_t isn, __be64 *outstanding_event_mask); +int64_t opal_poll_events(__be64 *outstanding_event_mask); +int64_t opal_pci_set_hub_tce_memory(uint64_t hub_id, uint64_t tce_mem_addr, + uint64_t tce_mem_size); +int64_t opal_pci_set_phb_tce_memory(uint64_t phb_id, uint64_t tce_mem_addr, + uint64_t tce_mem_size); +int64_t opal_pci_config_read_byte(uint64_t phb_id, uint64_t bus_dev_func, + uint64_t offset, uint8_t *data); +int64_t opal_pci_config_read_half_word(uint64_t phb_id, uint64_t bus_dev_func, + uint64_t offset, __be16 *data); +int64_t opal_pci_config_read_word(uint64_t phb_id, uint64_t bus_dev_func, + uint64_t offset, __be32 *data); +int64_t
[PATCH 15/18] powerpc/powernv: sync #includes in opal.h with firmware
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 2aaa861..b60a25a 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -12,6 +12,12 @@
#ifndef __OPAL_H
#define __OPAL_H
+#ifdef __SKIBOOT__
+#ifndef __ASSEMBLY__
+#include types.h
+#endif /* __ASSEMBLY__ */
+#endif /* __SKIBOOT__ */
+
/** OPAL APIs **/
/* Return codes */
@@ -164,8 +170,6 @@
#ifndef __ASSEMBLY__
-#include linux/notifier.h
-
/* Other enums */
enum OpalVendorApiTokens {
OPAL_START_VENDOR_API_RANGE = 1000, OPAL_END_VENDOR_API_RANGE = 1999
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V11 07/17] powerpc/pci: Don't unset pci resources for VFs
On Tue, Feb 10, 2015 at 01:14:11PM +1100, Benjamin Herrenschmidt wrote:
On Tue, 2015-02-10 at 09:51 +0800, Wei Yang wrote:
On Tue, Feb 10, 2015 at 11:36:24AM +1100, Benjamin Herrenschmidt wrote:
On Thu, 2015-01-15 at 10:27 +0800, Wei Yang wrote:
If we're going to reassign resources with flag PCI_REASSIGN_ALL_RSRC, all
resources will be cleaned out during device header fixup time and then get
reassigned by PCI core. However, the VF resources won't be reassigned and
thus, we shouldn't clean them out.
This patch adds a condition. If the pci_dev is a VF, skip the resource
unset process.
I don't understand this, can you elaborate ? Why wouldn't we reassign
the IOV resource just like everything else ?
Sure.
VFs work a little bit different from normal devices. On powernv platform, we
have PCI_REASSIGN_ALL_RSRC set, which means all resource retrieved from
hardware will be cleaned and re-assigned by kernel. While VF's resources are
calculated from PF's IOV BAR, in virtfn_add(). And after this, there is not
re-assign process for VFs.
I still don't undertand, you mean SR-IOV is assigned before we assign
everybody else ? That doesn't make sense to me...
PF's resource will be assigned first, including normal BARs and IOV BARs.
Then PF's driver will create VFs, in virtfn_add(). In this function, VF's
resources is calculated from its PF's IOV BAR.
If you reset VF's resource as PFs, no one will try to assign it again.
Ben.
Ben.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
---
arch/powerpc/kernel/pci-common.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/kernel/pci-common.c
b/arch/powerpc/kernel/pci-common.c
index 37d512d..889f743 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -788,6 +788,10 @@ static void pcibios_fixup_resources(struct pci_dev
*dev)
pci_name(dev));
return;
}
+
+ if (dev-is_virtfn)
+ return;
+
for (i = 0; i DEVICE_COUNT_RESOURCE; i++) {
struct resource *res = dev-resource + i;
struct pci_bus_region reg;
--
Richard Yang
Help you, Help me
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V11 03/17] PCI: Add weak pcibios_iov_resource_alignment() interface
On Tue, Feb 10, 2015 at 11:32:59AM +1100, Benjamin Herrenschmidt wrote:
On Thu, 2015-01-15 at 10:27 +0800, Wei Yang wrote:
The alignment of PF's IOV BAR is designed to be the individual size of a
VF's BAR size. This works fine for many platforms, but on PowerNV platform
it needs some change.
The original alignment works, since at sizing and assigning stage the
requirement is from an individual VF's BAR size instead of the PF's IOV
BAR. This is the reason for the original code to just retrieve the
individual VF BAR size as the alignment.
On PowerNV platform, it is required to align the whole PF IOV BAR to a
hardware segment. Based on this fact, the alignment of PF's IOV BAR should
be calculated seperately.
This patch introduces a weak pcibios_iov_resource_alignment() interface,
which gives platform a chance to implement specific method to calculate
the PF's IOV BAR alignment.
While the patch is probably fine, I find the above explanation quite
confusing :)
I will try to make it more clear.
From my memory (vague now) of the scheme we put in place, we need to
practically reserve a portion of address space that corresponds to
VF_size * Number_of_PEs. IE, it's not just the alignment that has
constraints but also the size that need to be allocated.
Now I suppose if we make the alignment to be the size of the M64
window and if the core also bounces the allocated size to the
alignment boundary, then we are fine, but that should be explained.
The purpose of this patch is to give a chance to different archs to calculate
the alignment of PF's IOV BAR.
How about I move the detailed explanation on powernv platform in the following
patch? And focus on what this patch does in this log?
Cheers,
Ben.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
---
drivers/pci/iov.c | 11 ++-
include/linux/pci.h |3 +++
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index 933d8cc..5f48201 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -556,6 +556,12 @@ int pci_iov_resource_bar(struct pci_dev *dev, int resno)
4 * (resno - PCI_IOV_RESOURCES);
}
+resource_size_t __weak pcibios_iov_resource_alignment(struct pci_dev *dev,
+int resno, resource_size_t align)
+{
+return align;
+}
+
/**
* pci_sriov_resource_alignment - get resource alignment for VF BAR
* @dev: the PCI device
@@ -570,12 +576,15 @@ resource_size_t pci_sriov_resource_alignment(struct
pci_dev *dev, int resno)
{
struct resource tmp;
int reg = pci_iov_resource_bar(dev, resno);
+resource_size_t align;
if (!reg)
return 0;
__pci_read_base(dev, pci_bar_unknown, tmp, reg);
-return resource_alignment(tmp);
+align = resource_alignment(tmp);
+
+return pcibios_iov_resource_alignment(dev, resno, align);
}
/**
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 74ef944..ae7a7ea 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1163,6 +1163,9 @@ unsigned char pci_bus_max_busnr(struct pci_bus *bus);
void pci_setup_bridge(struct pci_bus *bus);
resource_size_t pcibios_window_alignment(struct pci_bus *bus,
unsigned long type);
+resource_size_t pcibios_iov_resource_alignment(struct pci_dev *dev,
+ int resno,
+ resource_size_t align);
#define PCI_VGA_STATE_CHANGE_BRIDGE (1 0)
#define PCI_VGA_STATE_CHANGE_DECODES (1 1)
--
Richard Yang
Help you, Help me
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 13/18] powerpc/powernv: add remaining missing enums to opal.h
Some enums in firmware opal.h were missing from linux opal.h, add them.
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 214a106..c09cf66 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -244,8 +244,13 @@ enum OpalShpcAction {
};
enum OpalShpcLinkState {
- OPAL_SHPC_LINK_DOWN = 0,
- OPAL_SHPC_LINK_UP = 1
+ OPAL_SHPC_LINK_DOWN = 0,
+ OPAL_SHPC_LINK_UP_x1 = 1,
+ OPAL_SHPC_LINK_UP_x2 = 2,
+ OPAL_SHPC_LINK_UP_x4 = 4,
+ OPAL_SHPC_LINK_UP_x8 = 8,
+ OPAL_SHPC_LINK_UP_x16 = 16,
+ OPAL_SHPC_LINK_UP_x32 = 32
};
enum OpalMmioWindowType {
@@ -253,10 +258,15 @@ enum OpalMmioWindowType {
OPAL_M64_WINDOW_TYPE = 2,
OPAL_IO_WINDOW_TYPE = 3
};
+
enum OpalShpcSlotState {
OPAL_SHPC_DEV_NOT_PRESENT = 0,
OPAL_SHPC_DEV_PRESENT = 1
};
+enum OpalShpcPowerState {
+ OPAL_SHPC_POWER_OFF = 0,
+ OPAL_SHPC_POWER_ON= 1
+};
enum OpalExceptionHandler {
OPAL_MACHINE_CHECK_HANDLER = 1,
@@ -367,6 +377,11 @@ enum OpalEpowStatus {
OPAL_EPOW_OVER_INTERNAL_TEMP = 3
};
+enum OpalCheckTokenStatus {
+ OPAL_TOKEN_ABSENT = 0,
+ OPAL_TOKEN_PRESENT = 1
+};
+
/*
* Address cycle types for LPC accesses. These also correspond
* to the content of the first cell of the reg property for
@@ -536,6 +551,7 @@ enum OpalHMI_ErrType {
OpalHMI_ERROR_SCOM_FIR,
OpalHMI_ERROR_DEBUG_TRIG_FIR,
OpalHMI_ERROR_HYP_RESOURCE,
+ OpalHMI_ERROR_CAPP_RECOVERY,
};
struct OpalHMIEvent {
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 17/18] powerpc/powernv: s/u8/uint8_t/ to match firmware in opal.h
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 2441f36..68ce7ef 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -612,13 +612,13 @@ struct OpalIoP7IOCErrorData {
__be64 biLdcp2; /* 3C0110, 3C0128 */
__be64 biFenceStatus; /* 3C0130, 3C0130 */
- u8 biDownbound; /* BI Downbound or Upbound */
+ uint8_t biDownbound;/* BI Downbound or Upbound */
}bi;
struct OpalIoP7IOCCiErrorData {
__be64 ciPortStatus;/* 3Dn008 */
__be64 ciPortLdcp; /* 3Dn010 */
- u8 ciPort; /* Index of CI port: 0/1 */
+ uint8_t ciPort; /* Index of CI port: 0/1 */
}ci;
};
};
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 18/18] powerpc/powernv: s/OpalM64EnableAction/OpalM64Action/ and __be64 annotation
This finally syncs the content of opal.h between linux and firmware
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 68ce7ef..6ea59ca 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -334,7 +334,7 @@ enum OpalMveEnableAction {
OPAL_ENABLE_MVE = 1
};
-enum OpalM64EnableAction {
+enum OpalM64Action {
OPAL_DISABLE_M64 = 0,
OPAL_ENABLE_M64_SPLIT = 1,
OPAL_ENABLE_M64_NON_SPLIT = 2
@@ -774,8 +774,8 @@ enum {
};
typedef struct oppanel_line {
- const char *line;
- uint64_tline_len;
+ __be64 line;
+ __be64 line_len;
} oppanel_line_t;
/*
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 07/18] powerpc/powernv: make whitespace for OPAL_PM_* defines match firmware
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com --- arch/powerpc/include/asm/opal.h |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h index 7075f57..31b9656 100644 --- a/arch/powerpc/include/asm/opal.h +++ b/arch/powerpc/include/asm/opal.h @@ -157,10 +157,10 @@ /* Flags set in power-mgmt nodes in device tree if * respective idle states are supported in the platform. */ -#define OPAL_PM_NAP_ENABLED0x0001 -#define OPAL_PM_SLEEP_ENABLED 0x0002 -#define OPAL_PM_WINKLE_ENABLED 0x0004 -#define OPAL_PM_SLEEP_ENABLED_ER1 0x0008 +#define OPAL_PM_NAP_ENABLED0x0001 +#define OPAL_PM_SLEEP_ENABLED 0x0002 +#define OPAL_PM_WINKLE_ENABLED 0x0004 +#define OPAL_PM_SLEEP_ENABLED_ER1 0x0008 /* with workaround */ #ifndef __ASSEMBLY__ -- 1.7.10.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] cxl: export symbols required for modules to use the API.
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
---
drivers/misc/cxl/api.c | 11 ++-
drivers/misc/cxl/vphb.c | 1 +
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/cxl/api.c b/drivers/misc/cxl/api.c
index c7263ed..95d7b67 100644
--- a/drivers/misc/cxl/api.c
+++ b/drivers/misc/cxl/api.c
@@ -31,11 +31,13 @@ struct cxl_context *cxl_dev_context_init(struct pci_dev
*dev)
return ctx;
}
+EXPORT_SYMBOL_GPL(cxl_dev_context_init);
void cxl_release_context(struct cxl_context *ctx)
{
cxl_context_free(ctx);
}
+EXPORT_SYMBOL_GPL(cxl_release_context);
int cxl_allocate_afu_irqs(struct cxl_context *ctx, int num)
{
@@ -43,11 +45,13 @@ int cxl_allocate_afu_irqs(struct cxl_context *ctx, int num)
num = ctx-afu-pp_irqs;
return afu_allocate_irqs(ctx, num);
}
+EXPORT_SYMBOL_GPL(cxl_allocate_afu_irqs);
void cxl_free_afu_irqs(struct cxl_context *ctx)
{
cxl_release_irq_ranges(ctx-irqs, ctx-afu-adapter);
}
+EXPORT_SYMBOL_GPL(cxl_free_afu_irqs);
static irq_hw_number_t cxl_find_afu_irq(struct cxl_context *ctx, int num)
{
@@ -80,6 +84,7 @@ int cxl_map_afu_irq(struct cxl_context *ctx, int num,
return cxl_map_irq(ctx-afu-adapter, hwirq, handler, cookie, name);
}
+EXPORT_SYMBOL_GPL(cxl_map_afu_irq);
void cxl_unmap_afu_irq(struct cxl_context *ctx, int num, void *cookie)
{
@@ -94,7 +99,7 @@ void cxl_unmap_afu_irq(struct cxl_context *ctx, int num, void
*cookie)
if (virq)
cxl_unmap_irq(virq, cookie);
}
-
+EXPORT_SYMBOL_GPL(cxl_unmap_afu_irq);
/*
* Start a context
@@ -127,12 +132,14 @@ out:
mutex_unlock(ctx-status_mutex);
return rc;
}
+EXPORT_SYMBOL_GPL(cxl_start_context);
/* Stop a context */
void cxl_stop_context(struct cxl_context *ctx)
{
___detach_context(ctx);
}
+EXPORT_SYMBOL_GPL(cxl_stop_context);
void __iomem *cxl_psa_map(struct cxl_context *ctx)
{
@@ -147,8 +154,10 @@ void __iomem *cxl_psa_map(struct cxl_context *ctx)
__func__, afu-psn_phys, afu-adapter-ps_size);
return ioremap(afu-psn_phys, afu-adapter-ps_size);
}
+EXPORT_SYMBOL_GPL(cxl_psa_map);
void cxl_psa_unmap(void __iomem *addr)
{
iounmap(addr);
}
+EXPORT_SYMBOL_GPL(cxl_psa_unmap);
diff --git a/drivers/misc/cxl/vphb.c b/drivers/misc/cxl/vphb.c
index 102f2f0..40215f8 100644
--- a/drivers/misc/cxl/vphb.c
+++ b/drivers/misc/cxl/vphb.c
@@ -189,3 +189,4 @@ struct cxl_afu *cxl_pci_to_afu(struct pci_dev *dev,
unsigned int *cfg_record)
return afu;
}
+EXPORT_SYMBOL_GPL(cxl_pci_to_afu);
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] cxl: allow example memcpy driver to be compiled as a module.
Requires fixing one typo.
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
---
drivers/misc/Kconfig | 2 +-
drivers/misc/cxl-memcpy.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 5262514..f778497 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -516,7 +516,7 @@ config VEXPRESS_SYSCFG
of generating transactions on this bus.
config CXL_MEMCPY
- bool Example CXL memcpy AFU driver
+ tristate Example CXL memcpy AFU driver
depends on CXL
default y
help
diff --git a/drivers/misc/cxl-memcpy.c b/drivers/misc/cxl-memcpy.c
index 6b7545d..fecc1fd 100644
--- a/drivers/misc/cxl-memcpy.c
+++ b/drivers/misc/cxl-memcpy.c
@@ -27,7 +27,7 @@ static DEFINE_PCI_DEVICE_TABLE(cxl_memcpy_pci_tbl) = {
{ PCI_DEVICE(PCI_VENDOR_ID_IBM, 0x4350), },
{ }
};
-MODULE_DEVICE_TABLE(pci, cxl_pci_tbl);
+MODULE_DEVICE_TABLE(pci, cxl_memcpy_pci_tbl);
uint cpu_memcopy;
module_param_named(cpu_memcopy, cpu_memcopy, uint, 0600);
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 02/18] powerpc/powernv: synchronize OPAL calls and return codes with firmware
This just leaves us with CXL vs CAPI as differences in the list of OPAL
calls between opal.h in firmware and opal.h in Linux.
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 4694183..80cb4d3 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -56,6 +56,7 @@ struct opal_sg_list {
#define OPAL_HARDWARE_FROZEN -13
#define OPAL_WRONG_STATE -14
#define OPAL_ASYNC_COMPLETION -15
+#define OPAL_EMPTY -16
#define OPAL_I2C_TIMEOUT -17
#define OPAL_I2C_INVALID_CMD -18
#define OPAL_I2C_LBUS_PARITY -19
@@ -66,7 +67,8 @@ struct opal_sg_list {
#define OPAL_I2C_STOP_ERR -24
/* API Tokens (in r0) */
-#define OPAL_INVALID_CALL -1
+#define OPAL_INVALID_CALL -1
+#define OPAL_TEST 0
#define OPAL_CONSOLE_WRITE 1
#define OPAL_CONSOLE_READ 2
#define OPAL_RTC_READ 3
@@ -155,8 +157,10 @@ struct opal_sg_list {
#define OPAL_GET_PARAM 89
#define OPAL_SET_PARAM 90
#define OPAL_DUMP_RESEND 91
+#define OPAL_ELOG_SEND 92 /* Deprecated */
#define OPAL_PCI_SET_PHB_CXL_MODE 93
#define OPAL_DUMP_INFO294
+#define OPAL_WRITE_OPPANEL_ASYNC 95
#define OPAL_PCI_ERR_INJECT96
#define OPAL_PCI_EEH_FREEZE_SET97
#define OPAL_HANDLE_HMI98
@@ -166,9 +170,12 @@ struct opal_sg_list {
#define OPAL_UNREGISTER_DUMP_REGION102
#define OPAL_WRITE_TPO 103
#define OPAL_READ_TPO 104
+#define OPAL_GET_DPO_STATUS105
+#define OPAL_OLD_I2C_REQUEST 106 /* Deprecated */
#define OPAL_IPMI_SEND 107
#define OPAL_IPMI_RECV 108
#define OPAL_I2C_REQUEST 109
+#define OPAL_LAST 109
/* Device tree flags */
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 09/18] powerpc/powernv: match enum OpalMessageType with firmware
Adds OPAL_MSG_DPO and docs for OPAL_MSG_SHUTDOWN
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 3786c6b..2deaadf 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -384,8 +384,9 @@ enum OpalMessageType {
*/
OPAL_MSG_MEM_ERR,
OPAL_MSG_EPOW,
- OPAL_MSG_SHUTDOWN,
+ OPAL_MSG_SHUTDOWN, /* params[0] = 1 reboot, 0 shutdown */
OPAL_MSG_HMI_EVT,
+ OPAL_MSG_DPO,
OPAL_MSG_TYPE_MAX,
};
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 08/18] powerpc/powernv: Move OpalSysparamPerm, OpalMessageType in opal.h to match firmware
For whatever strange reason, these two structures were in different
locations in opal.h in firmware and opal.h in Linux. Move them around
to match firmware so that the diff is less.
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 31b9656..3786c6b 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -279,17 +279,6 @@ enum OpalPendingState {
OPAL_EVENT_MSG_PENDING = 0x800,
};
-enum OpalMessageType {
- OPAL_MSG_ASYNC_COMP = 0,/* params[0] = token, params[1] = rc,
-* additional params function-specific
-*/
- OPAL_MSG_MEM_ERR,
- OPAL_MSG_EPOW,
- OPAL_MSG_SHUTDOWN,
- OPAL_MSG_HMI_EVT,
- OPAL_MSG_TYPE_MAX,
-};
-
enum OpalThreadStatus {
OPAL_THREAD_INACTIVE = 0x0,
OPAL_THREAD_STARTED = 0x1,
@@ -389,11 +378,15 @@ enum OpalLPCAddressType {
OPAL_LPC_FW = 2,
};
-/* System parameter permission */
-enum OpalSysparamPerm {
- OPAL_SYSPARAM_READ = 0x1,
- OPAL_SYSPARAM_WRITE = 0x2,
- OPAL_SYSPARAM_RW= (OPAL_SYSPARAM_READ | OPAL_SYSPARAM_WRITE),
+enum OpalMessageType {
+ OPAL_MSG_ASYNC_COMP = 0,/* params[0] = token, params[1] = rc,
+* additional params function-specific
+*/
+ OPAL_MSG_MEM_ERR,
+ OPAL_MSG_EPOW,
+ OPAL_MSG_SHUTDOWN,
+ OPAL_MSG_HMI_EVT,
+ OPAL_MSG_TYPE_MAX,
};
struct opal_msg {
@@ -402,6 +395,13 @@ struct opal_msg {
__be64 params[8];
};
+/* System parameter permission */
+enum OpalSysparamPerm {
+ OPAL_SYSPARAM_READ = 0x1,
+ OPAL_SYSPARAM_WRITE = 0x2,
+ OPAL_SYSPARAM_RW= (OPAL_SYSPARAM_READ | OPAL_SYSPARAM_WRITE),
+};
+
enum {
OPAL_IPMI_MSG_FORMAT_VERSION_1 = 1,
};
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 12/18] powerpc/powernv: add CAPI and EPOW parts to opal.h
this adds CAPI and EPOW parts to opal.h that previously were only
in firmware opal.h
Currently unused, but gets us really close to being able to share
opal.h between firmware and linux.
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h | 52 +++
1 file changed, 52 insertions(+)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 240ee1c..214a106 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -414,6 +414,46 @@ struct opal_ipmi_msg {
uint8_t data[];
};
+/*
+ * EPOW status sharing (OPAL and the host)
+ *
+ * The host will pass on OPAL, a buffer of length OPAL_SYSEPOW_MAX
+ * with individual elements being 16 bits wide to fetch the system
+ * wide EPOW status. Each element in the buffer will contain the
+ * EPOW status in it's bit representation for a particular EPOW sub
+ * class as defiend here. So multiple detailed EPOW status bits
+ * specific for any sub class can be represented in a single buffer
+ * element as it's bit representation.
+ */
+
+/* System EPOW type */
+enum OpalSysEpow {
+ OPAL_SYSEPOW_POWER = 0,/* Power EPOW */
+ OPAL_SYSEPOW_TEMP = 1,/* Temperature EPOW */
+ OPAL_SYSEPOW_COOLING= 2,/* Cooling EPOW */
+ OPAL_SYSEPOW_MAX= 3,/* Max EPOW categories */
+};
+
+/* Power EPOW */
+enum OpalSysPower {
+ OPAL_SYSPOWER_UPS = 0x0001, /* System on UPS power */
+ OPAL_SYSPOWER_CHNG = 0x0002, /* System power configuration change
*/
+ OPAL_SYSPOWER_FAIL = 0x0004, /* System impending power failure */
+ OPAL_SYSPOWER_INCL = 0x0008, /* System incomplete power */
+};
+
+/* Temperature EPOW */
+enum OpalSysTemp {
+ OPAL_SYSTEMP_AMB= 0x0001, /* System over ambient temperature */
+ OPAL_SYSTEMP_INT= 0x0002, /* System over internal temperature */
+ OPAL_SYSTEMP_HMD= 0x0004, /* System over ambient humidity */
+};
+
+/* Cooling EPOW */
+enum OpalSysCooling {
+ OPAL_SYSCOOL_INSF = 0x0001, /* System insufficient cooling */
+};
+
/* FSP memory errors handling */
enum OpalMemErr_Version {
OpalMemErr_V1 = 1,
@@ -741,6 +781,18 @@ struct opal_sg_list {
#define OPAL_DUMP_REGION_LOG_BUF 0x80
#define OPAL_DUMP_REGION_HOST_END 0xFF
+/* CAPI modes for PHB */
+enum {
+ OPAL_PHB_CAPI_MODE_PCIE = 0,
+ OPAL_PHB_CAPI_MODE_CAPI = 1,
+ OPAL_PHB_CAPI_MODE_SNOOP_OFF= 2,
+ OPAL_PHB_CAPI_MODE_SNOOP_ON = 3,
+};
+
+/* CAPI feature flags (in device-tree) */
+#define OPAL_PHB_CAPI_FLAG_SNOOP_CONTROL 0x0001
+#define OPAL_PHB_CAPI_FLAG_REVERT_TO_PCIE 0x0002
+
/* We calculate number of sg entries based on PAGE_SIZE */
#define SG_ENTRIES_PER_NODE ((PAGE_SIZE - 16) / sizeof(struct opal_sg_entry))
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/1] powerpc: fix missing L2 cache size in /sys/devices/system/cpu
On Tue, 2015-02-10 at 11:12 +1100, Benjamin Herrenschmidt wrote: On Mon, 2015-02-09 at 15:43 -0800, Dave Olson wrote: Michael Ellerman m...@ellerman.id.au wrote: On Mon, 2015-02-09 at 14:14 -0800, Dave Olson wrote: From: Dave Olson ol...@cumulusnetworks.com Fix missing L2 cache size in /sys/devices/system/cpu/cpu0/cache/index2/size This bug appears to be introduced in 2.6.29 by 93197a36a9c16a85fb24cf5a8639f7bf9af838a3. The missing entry caused lscpu to error out on e500v2 devices, and probably others error: cannot open /sys/devices/system/cpu/cpu0/cache/index2/size: No such file or directory The DTS files we see use cache-size for the unified L2 cache size, not d-cache-size Can you convince me that this is not going to break other machines that have d-cache-size but not cache-size? I'm unable to find any dts file that uses d-cache-size for the L2 unified cache. All in the powerpc tree in arch/powerpc/boot/dts/* are using cache-size in the L2 description for the cache size. As best as I can tell from looking around, this is universal. It may be universal for embedded machines using DTS in the kernel tree but it's definitely not true of any Mac or server machine (from which there is no DTS in the kernel as we get the DT from the firmware). Right. $ grep machine /proc/cpuinfo machine : PowerNV 8247-22L $ lsprop /proc/device-tree/cpus/l2-cache@2020 name l2-cache status okay reg 2020 (536870944) phandle 0005 linux,phandle0005 l2-cache 0006 i-cache-size 0008 (524288) i-cache-sets 0008 device_type cache d-cache-size 0008 (524288) d-cache-sets 0008 cache-unified cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V11 02/17] PCI/IOV: add VF enable/disable hook
On Tue, Feb 10, 2015 at 01:13:14PM +1100, Benjamin Herrenschmidt wrote: On Tue, 2015-02-10 at 09:35 +0800, Wei Yang wrote: Don't we want pcibios_sriov_enable() to be able to crop the number of VFs or do we think any resource limits have been applied already ? The second parameter initial is the number of VFs will be enabled. Arch dependent function will check the resources for these number of VFs. Do I catch your question correctly? I was wondering if the number of resource that can be enabled is smaller, should the arch function be able to return that smaller number and we would still enable that number ? Ie, have the arch function be able to update the value of initial (by passing it by pointer for example). This would increase the time to enable sriov and block others driver to enable sriov. On powernv platform, those resources needed are M64 BAR and PE numbers. Currently they are acquired separately. We have a lock to protect those resources respectively. If we want to apply the logic you mentioned, we need to have a bigger lock to protect both of them and try different values, since at the same time, other driver may want to enable their sriov too. We have to protect this contention. Another example is PF has two IOV BAR but just one M64 BAR left in system. In this case, no matter how many VFs want to enable, it will fail. Cheers, Ben. -- To unsubscribe from this list: send the line unsubscribe linux-pci in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Richard Yang Help you, Help me ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/3] powerpc: Enable seccomp filter support
Add the missing pieces in order to enable SECCOMP_FILTER on PowerPC architectures, and enable this support. Testing has been pursued using libseccomp with the latest ppc support patches [1], on Freescale platforms for both ppc and ppc64. ppc64le support is untested. [1] https://groups.google.com/forum/#!topic/libseccomp/ktR-bQr1tGw Bogdan Purcareata (3): powerpc: Don't force ENOSYS as error on syscall fail powerpc: Relax secure computing on syscall entry trace powerpc: Enable HAVE_ARCH_SECCOMP_FILTER arch/powerpc/Kconfig | 1 + arch/powerpc/kernel/entry_32.S | 3 ++- arch/powerpc/kernel/entry_64.S | 2 +- arch/powerpc/kernel/ptrace.c | 4 +++- 4 files changed, 7 insertions(+), 3 deletions(-) -- 2.1.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/3] powerpc: Relax secure computing on syscall entry trace
The secure_computing_strict will just force the kernel to panic on secure_computing failure. Once SECCOMP_FILTER support is enabled in the kernel, syscalls can be denied without system failure. Signed-off-by: Bogdan Purcareata bogdan.purcare...@freescale.com --- arch/powerpc/kernel/ptrace.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c index 100e01c..5c654ac 100644 --- a/arch/powerpc/kernel/ptrace.c +++ b/arch/powerpc/kernel/ptrace.c @@ -1772,7 +1772,9 @@ long do_syscall_trace_enter(struct pt_regs *regs) user_exit(); - secure_computing_strict(regs-gpr[0]); + /* Do the secure computing check first; failures should be fast. */ + if (secure_computing(regs-gpr[0]) == -1) + return -1L; if (test_thread_flag(TIF_SYSCALL_TRACE) tracehook_report_syscall_entry(regs)) -- 2.1.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Enable HAVE_ARCH_SECCOMP_FILTER
Signed-off-by: Bogdan Purcareata bogdan.purcare...@freescale.com --- arch/powerpc/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index a2a168e..72f363e 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -104,6 +104,7 @@ config PPC select HAVE_EFFICIENT_UNALIGNED_ACCESS if !CPU_LITTLE_ENDIAN select HAVE_KPROBES select HAVE_ARCH_KGDB + select HAVE_ARCH_SECCOMP_FILTER select HAVE_KRETPROBES select HAVE_ARCH_TRACEHOOK select HAVE_MEMBLOCK -- 2.1.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V11 02/17] PCI/IOV: add VF enable/disable hook
On Thu, 2015-01-15 at 10:27 +0800, Wei Yang wrote:
+ if ((retval = pcibios_sriov_enable(dev, initial))) {
+ dev_err(dev-dev, Failure %d from
pcibios_sriov_setup()\n,
+ retval);
+ return retval;
+ }
+
Don't we want pcibios_sriov_enable() to be able to crop the number
of VFs or do we think any resource limits have been applied
already ?
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V11 03/17] PCI: Add weak pcibios_iov_resource_alignment() interface
On Thu, 2015-01-15 at 10:27 +0800, Wei Yang wrote:
The alignment of PF's IOV BAR is designed to be the individual size of a
VF's BAR size. This works fine for many platforms, but on PowerNV platform
it needs some change.
The original alignment works, since at sizing and assigning stage the
requirement is from an individual VF's BAR size instead of the PF's IOV
BAR. This is the reason for the original code to just retrieve the
individual VF BAR size as the alignment.
On PowerNV platform, it is required to align the whole PF IOV BAR to a
hardware segment. Based on this fact, the alignment of PF's IOV BAR should
be calculated seperately.
This patch introduces a weak pcibios_iov_resource_alignment() interface,
which gives platform a chance to implement specific method to calculate
the PF's IOV BAR alignment.
While the patch is probably fine, I find the above explanation quite
confusing :)
From my memory (vague now) of the scheme we put in place, we need to
practically reserve a portion of address space that corresponds to
VF_size * Number_of_PEs. IE, it's not just the alignment that has
constraints but also the size that need to be allocated.
Now I suppose if we make the alignment to be the size of the M64
window and if the core also bounces the allocated size to the
alignment boundary, then we are fine, but that should be explained.
Cheers,
Ben.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
---
drivers/pci/iov.c | 11 ++-
include/linux/pci.h |3 +++
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index 933d8cc..5f48201 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -556,6 +556,12 @@ int pci_iov_resource_bar(struct pci_dev *dev, int resno)
4 * (resno - PCI_IOV_RESOURCES);
}
+resource_size_t __weak pcibios_iov_resource_alignment(struct pci_dev *dev,
+ int resno, resource_size_t align)
+{
+ return align;
+}
+
/**
* pci_sriov_resource_alignment - get resource alignment for VF BAR
* @dev: the PCI device
@@ -570,12 +576,15 @@ resource_size_t pci_sriov_resource_alignment(struct
pci_dev *dev, int resno)
{
struct resource tmp;
int reg = pci_iov_resource_bar(dev, resno);
+ resource_size_t align;
if (!reg)
return 0;
__pci_read_base(dev, pci_bar_unknown, tmp, reg);
- return resource_alignment(tmp);
+ align = resource_alignment(tmp);
+
+ return pcibios_iov_resource_alignment(dev, resno, align);
}
/**
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 74ef944..ae7a7ea 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1163,6 +1163,9 @@ unsigned char pci_bus_max_busnr(struct pci_bus *bus);
void pci_setup_bridge(struct pci_bus *bus);
resource_size_t pcibios_window_alignment(struct pci_bus *bus,
unsigned long type);
+resource_size_t pcibios_iov_resource_alignment(struct pci_dev *dev,
+ int resno,
+ resource_size_t align);
#define PCI_VGA_STATE_CHANGE_BRIDGE (1 0)
#define PCI_VGA_STATE_CHANGE_DECODES (1 1)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V11 07/17] powerpc/pci: Don't unset pci resources for VFs
On Thu, 2015-01-15 at 10:27 +0800, Wei Yang wrote:
If we're going to reassign resources with flag PCI_REASSIGN_ALL_RSRC, all
resources will be cleaned out during device header fixup time and then get
reassigned by PCI core. However, the VF resources won't be reassigned and
thus, we shouldn't clean them out.
This patch adds a condition. If the pci_dev is a VF, skip the resource
unset process.
I don't understand this, can you elaborate ? Why wouldn't we reassign
the IOV resource just like everything else ?
Ben.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
---
arch/powerpc/kernel/pci-common.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/kernel/pci-common.c
b/arch/powerpc/kernel/pci-common.c
index 37d512d..889f743 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -788,6 +788,10 @@ static void pcibios_fixup_resources(struct pci_dev *dev)
pci_name(dev));
return;
}
+
+ if (dev-is_virtfn)
+ return;
+
for (i = 0; i DEVICE_COUNT_RESOURCE; i++) {
struct resource *res = dev-resource + i;
struct pci_bus_region reg;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V11 06/17] powerpc/pci: Add PCI resource alignment documentation
On Wed, 2015-02-04 at 17:44 -0600, Bjorn Helgaas wrote: diff --git a/Documentation/powerpc/pci_iov_resource_on_powernv.txt b/Documentation/powerpc/pci_iov_resource_on_powernv.txt new file mode 100644 index 000..10d4ac2 --- /dev/null +++ b/Documentation/powerpc/pci_iov_resource_on_powernv.txt I added the following two patches on top of this because I'm still confused about the difference between the M64 window and the M64 BARs. Several parts of the writeup seem to imply that there are several M64 windows, but that seems to be incorrect. And I tried to write something about M64 BARs, too. But it could well be incorrect. Please correct as necessary. Ultimately I'll just fold everything into the original patch so there's only one. The way the HW works is that 2 windows of the CPU address space are routed to each PHB. One is used for 32-bit stuff and one is used for 64-bit stuff (it doesn't have to be and it's not fixed in HW which is which, it's just two windows of the fabric being forwarded but that's how we use them). The FW configures them, one is 4G and the other one is today 64G but that might get increased at some point. (Actually there's a 3rd window but it's exclusively used for the PHB own registers so we can ignore it here). Once an MMIO cycle hit one of the above window on the powerbus it gets forwarded to the PHB. Now the PHB itself contains a number of BARs which aren't the same thing as device BARs so it's confusing and I tend to call them windows for that reason. They are made of pairs of registers indicating an address and a size (sort-of, the M64 ones are actually in some CAM in the chip but that's a register access method detail that is not relevant here). - One M32. It's limited to 4G in size, and has the specific attribute that the top bits of the address from the powerbus are dropped (and replaced with the content of a register) thus allowing this window to target the 32-bit MMIO space from anywhere in the CPU 50-bit bus space. This is setup at boot time, and we can probably ignore it here. It has it's own segmenting for PEs which is a bit different from 64-bit stuff as it goes through a remapping table allowing to configure which PE each segment maps to. - 16 M64's. Each of these can be configured individually to pass a portion of the above window space to the PCIe bus. There is no remapping in that case (the powerbus addresses are passed 1:1). Each of those M64's can be configured to have either a single PE (in which case the PE number can be configured) or to be segmented (256 PE's but the PE number cannot be configured and is equal to the segment number). Additionally, the M64's can overlap, in which case we have a well defined precedence order, which allows us to create a backing M64 that cover the entire 64G window going to the PCIe for normal 64-bit BARs and overlap on top of that M64's appropriately sized and positioned to cover IOV BARs (or in some case, single-PE M64's to cover very large device BARs in order to avoid using too many PE's in the backing M64). Cheers, Ben. Bjorn commit 6f46b79d243c24fd02c662c43aec6c829013ff64 Author: Bjorn Helgaas bhelg...@google.com Date: Fri Jan 30 11:01:59 2015 -0600 Try to fix references to M64 window vs M64 BARs. If there really is only one M64 window, I'm still a little confused about why there are so many places that seem to mention multiple M64 windows. diff --git a/Documentation/powerpc/pci_iov_resource_on_powernv.txt b/Documentation/powerpc/pci_iov_resource_on_powernv.txt index 10d4ac2f25b5..140df9cb58bd 100644 --- a/Documentation/powerpc/pci_iov_resource_on_powernv.txt +++ b/Documentation/powerpc/pci_iov_resource_on_powernv.txt @@ -59,7 +59,7 @@ interrupt. * Outbound. That's where the tricky part is. The PHB basically has a concept of windows from the CPU address space to the -PCI address space. There is one M32 window and 16 M64 windows. They have different +PCI address space. There is one M32 window and one M64 window. They have different characteristics. First what they have in common: they are configured to forward a configurable portion of the CPU address space to the PCIe bus and must be naturally aligned power of two in size. The rest is different: @@ -89,29 +89,31 @@ Ideally we would like to be able to have individual functions in PE's but that would mean using a completely different address allocation scheme where individual function BARs can be grouped to fit in one or more segments - - The M64 windows. + - The M64 window: - * Their smallest size is 1M + * Must be at least 256MB in size - * They do not translate addresses (the address on PCIe is the same as the + * Does not translate addresses (the address on PCIe is the same as the address on the PowerBus. There is a way to also set the top 14 bits which are not conveyed by PowerBus but we don't use this). - * They can be
RE: PROBLEM: USB isochronous urb leak on EHCI driver
On Mon, 9 Feb 2015, Michael Tessier wrote: Okay; I did my homeworks. We've loaded kernel V3.16 (Oct 14th, 2015) on an i.MX51 plattform and the problem is still there. Unless an important change occured in V3.19, it appears that the latest kernel is not the solution for us. So we're still not able to use 4 codecs on our i.MX plattform. So just to make things clearer: - We have customers waiting for a solution with that hardware (this hardware is already delivred AND used); - We have important comittments and severe penalties ($$$) if we're not able to deliver on time (due for March 15th); - We've already looked at a hardware solution, which corresponds to replace current units ($), so that is not really an option for us; So as a last resort, I'm wondering, where is the USB expert who could help us solving our problem? Any suggestions? That would be me. If we are to get into debugging the USB driver, we would do it with the current kernel used (V2.6.31). What are the better tools to get into that? I guess a USB analyzer (hardware) would be the smart thing? Any brand name to suggest? It really would be better to start by debugging the most recent kernel possible. Once the problem has been solved there, it should be fairly straightforward to port it back. Any other ideas for a solution will be really appreciated. You should begin by using usbmon during a short test (one or two seconds ought to be enough). See the instructions in the kernel source file Documentation/usb/usbmon.txt. Alan Stern ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] perf/e6500: Make event translations available in sysfs
I'll NAK any external 'download area' (and I told that Andi before): tools/perf/event-tables/ or so is a good enough 'download area' with fast enough update cycles. The proposal was to put it on kernel.org, similar to how external firmware blobs are distributed. CPU event lists are data sheets, so are like firmware. They do not follow the normal kernel code licenses. They are not source code. They cannot be reviewed in the normal way. If any 'update' of event descriptions is needed it can happen through the distro package mechanism, or via a simple 'git pull' if it's compiled directly. Lets not overengineer this with any dependence on an external site and with a separate update mechanism - lets just get the tables into tools/ and see it from there... That experiment has been already done for oprofile, didn't work very well. -Andi -- a...@linux.intel.com -- Speaking for myself only. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powernv: Add OPAL soft-poweroff routine
Joel Stanley j...@jms.id.au writes: Register a notifier for a OPAL message indicating that the machine should prepare itself for a graceful power off. OPAL will tell us if the power off is a reboot or shutdown, but for now we perform the same orderly_poweroff action. Signed-off-by: Joel Stanley j...@jms.id.au I merged the firmware side of things, this looks like it implements what firmware exports. Acked-by: Stewart Smith stew...@linux.vnet.ibm.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] perf/e6500: Make event translations available in sysfs
* Peter Zijlstra pet...@infradead.org wrote: On Fri, Feb 06, 2015 at 04:43:54PM -0600, Tom Huynh wrote: arch/powerpc/perf/e6500-events-list.h | 289 ++ That's a lot of events to stuff in the kernel, would a userspace list not be more convenient? ISTR there being various discussions on providing support for that in tools/perf, Jiri? As long as it's in a single well organized place in tools/, I'd be fine with that solution as well. What doesn't work very well is disjunct, disorganized, inconsistent event descriptions all across the tooling and platform landscape - putting static tables into sysfs is a marked improvement over that, despite its memory usage. Thanks, Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/1] powerpc: fix missing L2 cache size in /sys/devices/system/cpu
From: Dave Olson ol...@cumulusnetworks.com
Fix missing L2 cache size in /sys/devices/system/cpu/cpu0/cache/index2/size
This bug appears to be introduced in 2.6.29 by
93197a36a9c16a85fb24cf5a8639f7bf9af838a3.
The missing entry caused lscpu to error out on e500v2 devices, and probably
others
error: cannot open /sys/devices/system/cpu/cpu0/cache/index2/size: No such
file or directory
The DTS files we see use cache-size for the unified L2 cache size, not
d-cache-size
Signed-off-by: Dave Olson ol...@cumulusnetworks.com
---
diff --git a/arch/powerpc/kernel/cacheinfo.c b/arch/powerpc/kernel/cacheinfo.c
index 40198d5..9ca1e9a 100644
--- a/arch/powerpc/kernel/cacheinfo.c
+++ b/arch/powerpc/kernel/cacheinfo.c
@@ -72,7 +72,7 @@ static const struct cache_type_info cache_type_info[] = {
* must be equal on unified caches, so just use
* d-cache properties. */
.name= Unified,
- .size_prop = d-cache-size,
+ .size_prop = cache-size,
.line_size_props = { d-cache-line-size,
d-cache-block-size, },
.nr_sets_prop= d-cache-sets,
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] perf/e6500: Make event translations available in sysfs
* Jiri Olsa jo...@redhat.com wrote: On Mon, Feb 09, 2015 at 11:07:38AM +0100, Ingo Molnar wrote: * Peter Zijlstra pet...@infradead.org wrote: On Fri, Feb 06, 2015 at 04:43:54PM -0600, Tom Huynh wrote: arch/powerpc/perf/e6500-events-list.h | 289 ++ That's a lot of events to stuff in the kernel, would a userspace list not be more convenient? ISTR there being various discussions on providing support for that in tools/perf, Jiri? As long as it's in a single well organized place in tools/, I'd be fine with that solution as well. What doesn't work very well is disjunct, disorganized, inconsistent event descriptions all across the tooling and platform landscape - putting static tables into sysfs is a marked improvement over that, despite its memory usage. the last version is in here: http://marc.info/?l=linux-kernelm=140676269017820w=2 AFAIK Andi is setting up the download area as discussed in the thread and should repost at some point I'll NAK any external 'download area' (and I told that Andi before): tools/perf/event-tables/ or so is a good enough 'download area' with fast enough update cycles. If any 'update' of event descriptions is needed it can happen through the distro package mechanism, or via a simple 'git pull' if it's compiled directly. Lets not overengineer this with any dependence on an external site and with a separate update mechanism - lets just get the tables into tools/ and see it from there... Thanks, Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/1] powerpc: fix missing L2 cache size in /sys/devices/system/cpu
Michael Ellerman m...@ellerman.id.au wrote: On Mon, 2015-02-09 at 14:14 -0800, Dave Olson wrote: From: Dave Olson ol...@cumulusnetworks.com Fix missing L2 cache size in /sys/devices/system/cpu/cpu0/cache/index2/size This bug appears to be introduced in 2.6.29 by 93197a36a9c16a85fb24cf5a8639f7bf9af838a3. The missing entry caused lscpu to error out on e500v2 devices, and probably others error: cannot open /sys/devices/system/cpu/cpu0/cache/index2/size: No such file or directory The DTS files we see use cache-size for the unified L2 cache size, not d-cache-size Can you convince me that this is not going to break other machines that have d-cache-size but not cache-size? I'm unable to find any dts file that uses d-cache-size for the L2 unified cache. All in the powerpc tree in arch/powerpc/boot/dts/* are using cache-size in the L2 description for the cache size. As best as I can tell from looking around, this is universal. Dave Olson ol...@cumulusnetworks.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/1] powerpc: fix missing L2 cache size in /sys/devices/system/cpu
On Mon, 2015-02-09 at 15:43 -0800, Dave Olson wrote: Michael Ellerman m...@ellerman.id.au wrote: On Mon, 2015-02-09 at 14:14 -0800, Dave Olson wrote: From: Dave Olson ol...@cumulusnetworks.com Fix missing L2 cache size in /sys/devices/system/cpu/cpu0/cache/index2/size This bug appears to be introduced in 2.6.29 by 93197a36a9c16a85fb24cf5a8639f7bf9af838a3. The missing entry caused lscpu to error out on e500v2 devices, and probably others error: cannot open /sys/devices/system/cpu/cpu0/cache/index2/size: No such file or directory The DTS files we see use cache-size for the unified L2 cache size, not d-cache-size Can you convince me that this is not going to break other machines that have d-cache-size but not cache-size? I'm unable to find any dts file that uses d-cache-size for the L2 unified cache. All in the powerpc tree in arch/powerpc/boot/dts/* are using cache-size in the L2 description for the cache size. As best as I can tell from looking around, this is universal. It may be universal for embedded machines using DTS in the kernel tree but it's definitely not true of any Mac or server machine (from which there is no DTS in the kernel as we get the DT from the firmware). Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V11 00/17] Enable SRIOV on Power8
On Wed, 2015-02-04 at 17:44 -0600, Bjorn Helgaas wrote: Ben, I know you chimed in earlier to help explain PEs. Are you or another powerpc maintainer planning to ack all this? I'll get through it in the next day or so. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] perf/e6500: Make event translations available in sysfs
On Mon, Feb 09, 2015 at 11:07:38AM +0100, Ingo Molnar wrote: * Peter Zijlstra pet...@infradead.org wrote: On Fri, Feb 06, 2015 at 04:43:54PM -0600, Tom Huynh wrote: arch/powerpc/perf/e6500-events-list.h | 289 ++ That's a lot of events to stuff in the kernel, would a userspace list not be more convenient? ISTR there being various discussions on providing support for that in tools/perf, Jiri? As long as it's in a single well organized place in tools/, I'd be fine with that solution as well. What doesn't work very well is disjunct, disorganized, inconsistent event descriptions all across the tooling and platform landscape - putting static tables into sysfs is a marked improvement over that, despite its memory usage. the last version is in here: http://marc.info/?l=linux-kernelm=140676269017820w=2 AFAIK Andi is setting up the download area as discussed in the thread and should repost at some point jirka ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] powerpc: Change vrX register defines to vX to match gcc and glibc
As our various loops (copy, string, crypto etc) get more complicated,
we want to share implementations between userspace (eg glibc) and
the kernel. We also want to write userspace test harnesses to put
in tools/testing/selftest.
One gratuitous difference between userspace and the kernel is the
VMX register definitions - the kernel uses vrX whereas both gcc and
glibc use vX.
Change the kernel to match userspace.
Signed-off-by: Anton Blanchard an...@samba.org
---
arch/powerpc/include/asm/ppc_asm.h | 64 +++---
arch/powerpc/include/uapi/asm/ptrace.h | 2 +-
arch/powerpc/kernel/tm.S | 8 +-
arch/powerpc/kernel/vector.S | 24 +--
arch/powerpc/lib/copypage_power7.S | 32 +--
arch/powerpc/lib/copyuser_power7.S | 226 ++---
arch/powerpc/lib/crtsavres.S | 96 -
arch/powerpc/lib/ldstfp.S | 26 +--
arch/powerpc/lib/memcpy_power7.S | 226 ++---
.../selftests/powerpc/copyloops/asm/ppc_asm.h | 33 ---
10 files changed, 352 insertions(+), 385 deletions(-)
diff --git a/arch/powerpc/include/asm/ppc_asm.h
b/arch/powerpc/include/asm/ppc_asm.h
index 7e46125..c746103 100644
--- a/arch/powerpc/include/asm/ppc_asm.h
+++ b/arch/powerpc/include/asm/ppc_asm.h
@@ -637,38 +637,38 @@
END_FTR_SECTION_NESTED(CPU_FTR_HAS_PPR,CPU_FTR_HAS_PPR,945)
/* AltiVec Registers (VPRs) */
-#definevr0 0
-#definevr1 1
-#definevr2 2
-#definevr3 3
-#definevr4 4
-#definevr5 5
-#definevr6 6
-#definevr7 7
-#definevr8 8
-#definevr9 9
-#definevr1010
-#definevr1111
-#definevr1212
-#definevr1313
-#definevr1414
-#definevr1515
-#definevr1616
-#definevr1717
-#definevr1818
-#definevr1919
-#definevr2020
-#definevr2121
-#definevr2222
-#definevr2323
-#definevr2424
-#definevr2525
-#definevr2626
-#definevr2727
-#definevr2828
-#definevr2929
-#definevr3030
-#definevr3131
+#definev0 0
+#definev1 1
+#definev2 2
+#definev3 3
+#definev4 4
+#definev5 5
+#definev6 6
+#definev7 7
+#definev8 8
+#definev9 9
+#definev10 10
+#definev11 11
+#definev12 12
+#definev13 13
+#definev14 14
+#definev15 15
+#definev16 16
+#definev17 17
+#definev18 18
+#definev19 19
+#definev20 20
+#definev21 21
+#definev22 22
+#definev23 23
+#definev24 24
+#definev25 25
+#definev26 26
+#definev27 27
+#definev28 28
+#definev29 29
+#definev30 30
+#definev31 31
/* VSX Registers (VSRs) */
diff --git a/arch/powerpc/include/uapi/asm/ptrace.h
b/arch/powerpc/include/uapi/asm/ptrace.h
index 77d2ed3..8036b38 100644
--- a/arch/powerpc/include/uapi/asm/ptrace.h
+++ b/arch/powerpc/include/uapi/asm/ptrace.h
@@ -136,7 +136,7 @@ struct pt_regs {
#endif /* __powerpc64__ */
/*
- * Get/set all the altivec registers vr0..vr31, vscr, vrsave, in one go.
+ * Get/set all the altivec registers v0..v31, vscr, vrsave, in one go.
* The transfer totals 34 quadword. Quadwords 0-31 contain the
* corresponding vector registers. Quadword 32 contains the vscr as the
* last word (offset 12) within that quadword. Quadword 33 contains the
diff --git a/arch/powerpc/kernel/tm.S b/arch/powerpc/kernel/tm.S
index 2a324f4..5754b22 100644
--- a/arch/powerpc/kernel/tm.S
+++ b/arch/powerpc/kernel/tm.S
@@ -152,9 +152,9 @@ _GLOBAL(tm_reclaim)
addir7, r3, THREAD_TRANSACT_VRSTATE
SAVE_32VRS(0, r6, r7) /* r6 scratch, r7 transact vr state */
- mfvscr vr0
+ mfvscr v0
li r6, VRSTATE_VSCR
- stvxvr0, r7, r6
+ stvxv0, r7, r6
dont_backup_vec:
mfspr r0, SPRN_VRSAVE
std r0, THREAD_TRANSACT_VRSAVE(r3)
@@ -359,8 +359,8 @@ _GLOBAL(__tm_recheckpoint)
addir8, r3, THREAD_VRSTATE
li r5, VRSTATE_VSCR
- lvx vr0, r8, r5
- mtvscr vr0
+ lvx v0, r8, r5
+ mtvscr v0
REST_32VRS(0, r5, r8) /* r5 scratch, r8 ptr */
dont_restore_vec:
ld r5, THREAD_VRSAVE(r3)
diff --git a/arch/powerpc/kernel/vector.S b/arch/powerpc/kernel/vector.S
index 74f8050..f5c80d5 100644
--- a/arch/powerpc/kernel/vector.S
+++ b/arch/powerpc/kernel/vector.S
@@ -24,8 +24,8 @@
Re: [PATCH 1/1] powerpc: fix missing L2 cache size in /sys/devices/system/cpu
On Mon, 2015-02-09 at 14:14 -0800, Dave Olson wrote: From: Dave Olson ol...@cumulusnetworks.com Fix missing L2 cache size in /sys/devices/system/cpu/cpu0/cache/index2/size This bug appears to be introduced in 2.6.29 by 93197a36a9c16a85fb24cf5a8639f7bf9af838a3. The missing entry caused lscpu to error out on e500v2 devices, and probably others error: cannot open /sys/devices/system/cpu/cpu0/cache/index2/size: No such file or directory The DTS files we see use cache-size for the unified L2 cache size, not d-cache-size Can you convince me that this is not going to break other machines that have d-cache-size but not cache-size? cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc: Change vsrX register defines to vsX to match gcc and glibc
As our various loops (copy, string, crypto etc) get more complicated, we want to share implementations between userspace (eg glibc) and the kernel. We also want to write userspace test harnesses to put in tools/testing/selftest. One gratuitous difference between userspace and the kernel is the VSX register definitions - the kernel uses vsrX whereas gcc uses vsX. Change the kernel to match userspace. Signed-off-by: Anton Blanchard an...@samba.org --- arch/powerpc/include/asm/ppc_asm.h | 128 ++--- arch/powerpc/lib/ldstfp.S | 6 +- 2 files changed, 67 insertions(+), 67 deletions(-) diff --git a/arch/powerpc/include/asm/ppc_asm.h b/arch/powerpc/include/asm/ppc_asm.h index c746103..dd0fc18 100644 --- a/arch/powerpc/include/asm/ppc_asm.h +++ b/arch/powerpc/include/asm/ppc_asm.h @@ -672,70 +672,70 @@ END_FTR_SECTION_NESTED(CPU_FTR_HAS_PPR,CPU_FTR_HAS_PPR,945) /* VSX Registers (VSRs) */ -#definevsr00 -#definevsr11 -#definevsr22 -#definevsr33 -#definevsr44 -#definevsr55 -#definevsr66 -#definevsr77 -#definevsr88 -#definevsr99 -#definevsr10 10 -#definevsr11 11 -#definevsr12 12 -#definevsr13 13 -#definevsr14 14 -#definevsr15 15 -#definevsr16 16 -#definevsr17 17 -#definevsr18 18 -#definevsr19 19 -#definevsr20 20 -#definevsr21 21 -#definevsr22 22 -#definevsr23 23 -#definevsr24 24 -#definevsr25 25 -#definevsr26 26 -#definevsr27 27 -#definevsr28 28 -#definevsr29 29 -#definevsr30 30 -#definevsr31 31 -#definevsr32 32 -#definevsr33 33 -#definevsr34 34 -#definevsr35 35 -#definevsr36 36 -#definevsr37 37 -#definevsr38 38 -#definevsr39 39 -#definevsr40 40 -#definevsr41 41 -#definevsr42 42 -#definevsr43 43 -#definevsr44 44 -#definevsr45 45 -#definevsr46 46 -#definevsr47 47 -#definevsr48 48 -#definevsr49 49 -#definevsr50 50 -#definevsr51 51 -#definevsr52 52 -#definevsr53 53 -#definevsr54 54 -#definevsr55 55 -#definevsr56 56 -#definevsr57 57 -#definevsr58 58 -#definevsr59 59 -#definevsr60 60 -#definevsr61 61 -#definevsr62 62 -#definevsr63 63 +#definevs0 0 +#definevs1 1 +#definevs2 2 +#definevs3 3 +#definevs4 4 +#definevs5 5 +#definevs6 6 +#definevs7 7 +#definevs8 8 +#definevs9 9 +#definevs1010 +#definevs1111 +#definevs1212 +#definevs1313 +#definevs1414 +#definevs1515 +#definevs1616 +#definevs1717 +#definevs1818 +#definevs1919 +#definevs2020 +#definevs2121 +#definevs2222 +#definevs2323 +#definevs2424 +#definevs2525 +#definevs2626 +#definevs2727 +#definevs2828 +#definevs2929 +#definevs3030 +#definevs3131 +#definevs3232 +#definevs3333 +#definevs3434 +#definevs3535 +#definevs3636 +#definevs3737 +#definevs3838 +#definevs3939 +#definevs4040 +#definevs4141 +#definevs4242 +#definevs4343 +#definevs4444 +#definevs4545 +#definevs4646 +#definevs4747 +#definevs4848 +#definevs4949 +#definevs5050 +#definevs5151 +#definevs5252 +#definevs5353 +#definevs5454 +#definevs5555 +#definevs5656 +#definevs5757 +#definevs5858 +#definevs5959 +#definevs6060 +#definevs6161 +#definevs6262 +#definevs6363 /* SPE Registers (EVPRs) */ diff --git a/arch/powerpc/lib/ldstfp.S b/arch/powerpc/lib/ldstfp.S index 659c7ca..5d0cdbf 100644 --- a/arch/powerpc/lib/ldstfp.S +++ b/arch/powerpc/lib/ldstfp.S @@ -280,12 +280,12 @@ _GLOBAL(do_stvx) #endif /* CONFIG_ALTIVEC */ #ifdef CONFIG_VSX -/* Get the contents of vsrN into vsr0; N is in r3. */ +/* Get the contents of vsN into vs0; N is in r3. */ _GLOBAL(get_vsr) mflrr0 rlwinm r3,r3,3,0x1f8 bcl 20,31,1f - blr /* vsr0 is already in vsr0 */ + blr /* vs0 is already in vs0 */
RE: PROBLEM: USB isochronous urb leak on EHCI driver
That is interresting, however, I have an older kernel running an OHCI driver which is able to handle 4 codecs. Same usb hardware (codecs and hub), but older kernel on a different CPU, with much less power. This makes me believe that there's a solution to make it work... Of course there is: Install an OHCI host controller and use it to drive your codecs. It should work fine. What do you mean by that? The host controller is embedded in the i.MX CPU... Changing the CPU is not really an option to me. Unless I am missing something? I didn't realize you were talking about an i.MX-based system. On a computer with a free PCI slot, it's easy to add an OHCI controller. iMX isn't as accomodating. If there's no way to add an extra USB controller to your system then the only choice is to upgrade the driver software. Alan Stern Okay; I did my homeworks. We've loaded kernel V3.16 (Oct 14th, 2015) on an i.MX51 plattform and the problem is still there. Unless an important change occured in V3.19, it appears that the latest kernel is not the solution for us. So we're still not able to use 4 codecs on our i.MX plattform. So just to make things clearer: - We have customers waiting for a solution with that hardware (this hardware is already delivred AND used); - We have important comittments and severe penalties ($$$) if we're not able to deliver on time (due for March 15th); - We've already looked at a hardware solution, which corresponds to replace current units ($), so that is not really an option for us; So as a last resort, I'm wondering, where is the USB expert who could help us solving our problem? Any suggestions? If we are to get into debugging the USB driver, we would do it with the current kernel used (V2.6.31). What are the better tools to get into that? I guess a USB analyzer (hardware) would be the smart thing? Any brand name to suggest? Any other ideas for a solution will be really appreciated. Regards, Michael Tessier. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V11 02/17] PCI/IOV: add VF enable/disable hook
On Tue, Feb 10, 2015 at 11:26:19AM +1100, Benjamin Herrenschmidt wrote:
On Thu, 2015-01-15 at 10:27 +0800, Wei Yang wrote:
+ if ((retval = pcibios_sriov_enable(dev, initial))) {
+ dev_err(dev-dev, Failure %d from
pcibios_sriov_setup()\n,
+ retval);
+ return retval;
+ }
+
Don't we want pcibios_sriov_enable() to be able to crop the number
of VFs or do we think any resource limits have been applied
already ?
The second parameter initial is the number of VFs will be enabled. Arch
dependent function will check the resources for these number of VFs.
Do I catch your question correctly?
Ben.
--
Richard Yang
Help you, Help me
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/18] sync opal.h with firmware
Michael Ellerman m...@ellerman.id.au writes: I'm going to be a total pain, and suggest that this is the wrong approach :) I was on board until patch 15, where you have to add an #ifdef SKIBOOT to guard an include, and you have to remove an include on the Linux side. (the Linux include was actually not used it seems) I think the better solution would be to pull all the common parts out into a new file, opal-api.h. That file would define the API between Linux Skiboot, and absolutely nothing else. Sounds fine. Both Linux and Skiboot would continue to have an opal.h, which would include opal-api.h, and then anything else needed on either side to make a functioning opal.h - eg. other includes definitions (SG_ENTRIES_PER_NODE). It would also have the advantage that because opal-api.h is a new file, we can get it synced from the beginning and not worry about all the whitespace rearranging patches. ie. there'd just be one patch on both sides to add the new file and move definitions into it from opal.h. Sure. I was doing it bit by bit just so that it was reviewable that I didn't miss anything or violently screw anything up. Plus, there were things that should be changed in skiboot as well. If you don't violently disagree I'll do a patch for that and we can see how it looks? Not violently :) I'd go back and do a similar thing to skiboot to make them match again though, having linux/opal-api.h match skiboot/opal.h would just cause swearing fits :) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
