Re: [PATCH v2 2/2] leds/powernv: Add driver for PowerNV platform
On Thu, 2015-04-23 at 16:13 +0200, Jacek Anaszewski wrote: How the firmware is related to kernel? These bindings are for kernel, not for the firmware. There should be no relation. DT bindings should be kernel agnostic and represent the HW layout, not be designed based on what a given kernel driver wants, but I'm digressing... DT bindings are compiled to *.dtb file which is concatenated with zImage. No. First, a binding isn't compiled to a dtb, a binding is a piece documentation. A flat device tree *might* be compiled from a dts to a dtb but that isn't necessarily the case. For example, any machine with an actual implementation of Open Firmware will essentially flatten OF internal tree into a dtb at boot time, and that tree is itself generated by forth code. In our case, the device tree is procedurally generated by two layers of firmware, there is no dts compilation happening. HostBoot generates a shell and OPAL extends it before flattening it and passing it to the kernel. The concatenated with zImage point you make is also a very ARM centric one. ARM provides the *optional* ability to concatenate a dtb with a zImage, but that's specific to ARM zImage wrapper. For example, powerpc can do something similar (but not identical) using the wrapper script we have in arch/powerpc/boot where we embed the dtb. However, this too is optional, we have a longer history of having firwmares generating device-trees. Note: We invented the whole FDT business :-) During system boot device drivers are matched with DT bindings through 'compatible' property. A driver should have single matching DT node, i.e. no other driver can probe with the same DT node. This implies that the node should contain only the properties required for configuring the related device. I don't see how you goes from A to implying B here. Yes, a device generally will have a single representing node but that doesn't mean that the node only contains what the driver needs. The DT node can contain all sort of auxilliary informations that the driver may or may not be interested in that was deemed potentially relevant or useful by the platform designer. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] leds/powernv: Add driver for PowerNV platform
On Fri, 2015-04-24 at 12:15 +0200, Jacek Anaszewski wrote: No matter what format of device tree OPAL produces, I assume that it must compile it from some sources. Nope. Well... .C code maybe qualifies as sources :-) dtb file is a compiled form of human readable dts file containing Flattened Device Tree - a data structure for describing the hardware in the system. Please refer to: http://elinux.org/Device_Tree We are quite familiar with this, guess what architecture created the whole flat device-tree stuff in the first place ? In any case, in our case, the fdt is procedurally generated by firmware. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ehea: Fix memory hook reference counting crashes
On Sat, 2015-04-25 at 14:43 -0400, David Miller wrote: From: Michael Ellerman m...@ellerman.id.au Date: Fri, 24 Apr 2015 15:52:32 +1000 The recent commit to only register the EHEA memory hotplug hooks on adapter probe has a few problems. Firstly the reference counting is wrong for multiple adapters, in that the hooks are registered multiple times. Secondly the check in the tear down path is backward. Finally the error path doesn't decrement the count. The multiple registration of the hooks is the biggest problem, as it leads to oopses when the system is rebooted, and/or errors during memory hotplug, eg: ... Fixes: aa183323312d (ehea: Register memory hotplug, reboot and crash hooks on adapter probe) Signed-off-by: Michael Ellerman m...@ellerman.id.au Applied, but using an atomic counter for this is really inappropriate and is what lead to this bug in the first place. You're not counting anything, because if you were, then you would be decrementing this thing somewhere. Rather, it's purely a boolean state saying I did X. So it should be a boolean, and no atomicity nor other special considerations are needed for setting it to true. Yeah I agree, it's a mess. We should be unregistering the hooks when the last adapter is removed, which is where we'd do the decrement. As it's written the hooks stay registered until the driver is removed. I'll try and find time, or someone else with time, to fix it up properly for 4.2. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V2 1/4] powerpc/eeh: fix start/end/flags type in struct pci_io_addr_range{}
struct pci_io_addr_range{} stores the information of pci resources. It
would be better to keep these related fields have the same type as in
struct resource{}.
This patch fixes the start/end/flags type in struct pci_io_addr_range{} to
have the same type as in struct resource{}.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
Acked-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/kernel/eeh_cache.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/kernel/eeh_cache.c b/arch/powerpc/kernel/eeh_cache.c
index eeabeab..a1e86e1 100644
--- a/arch/powerpc/kernel/eeh_cache.c
+++ b/arch/powerpc/kernel/eeh_cache.c
@@ -48,11 +48,11 @@
*/
struct pci_io_addr_range {
struct rb_node rb_node;
- unsigned long addr_lo;
- unsigned long addr_hi;
+ resource_size_t addr_lo;
+ resource_size_t addr_hi;
struct eeh_dev *edev;
struct pci_dev *pcidev;
- unsigned int flags;
+ unsigned long flags;
};
static struct pci_io_addr_cache {
@@ -125,8 +125,8 @@ static void eeh_addr_cache_print(struct pci_io_addr_cache
*cache)
/* Insert address range into the rb tree. */
static struct pci_io_addr_range *
-eeh_addr_cache_insert(struct pci_dev *dev, unsigned long alo,
- unsigned long ahi, unsigned int flags)
+eeh_addr_cache_insert(struct pci_dev *dev, resource_size_t alo,
+ resource_size_t ahi, unsigned long flags)
{
struct rb_node **p = pci_io_addr_cache_root.rb_root.rb_node;
struct rb_node *parent = NULL;
@@ -197,9 +197,9 @@ static void __eeh_addr_cache_insert_dev(struct pci_dev *dev)
/* Walk resources on this device, poke them into the tree */
for (i = 0; i DEVICE_COUNT_RESOURCE; i++) {
- unsigned long start = pci_resource_start(dev,i);
- unsigned long end = pci_resource_end(dev,i);
- unsigned int flags = pci_resource_flags(dev,i);
+ resource_size_t start = pci_resource_start(dev,i);
+ resource_size_t end = pci_resource_end(dev,i);
+ unsigned long flags = pci_resource_flags(dev,i);
/* We are interested only bus addresses, not dma or other stuff
*/
if (0 == (flags (IORESOURCE_IO | IORESOURCE_MEM)))
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V2 0/4] EEH Cleanup
Four patches to cleanup the EEH, in type, comment and logic
---
v2:
* rebased on the latest kernel
Wei Yang (4):
powerpc/eeh: fix start/end/flags type in struct pci_io_addr_range{}
powerpc/eeh: fix comment for wait_state()
powerpc/eeh: fix powernv_eeh_wait_state delay logic
powerpc/eeh: remove unused macro IS_BRIDGE
arch/powerpc/kernel/eeh.c|2 --
arch/powerpc/kernel/eeh_cache.c | 16
arch/powerpc/kernel/eeh_driver.c |2 +-
arch/powerpc/platforms/powernv/eeh-powernv.c |4 ++--
arch/powerpc/platforms/pseries/eeh_pseries.c |2 +-
5 files changed, 12 insertions(+), 14 deletions(-)
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V2 4/4] powerpc/eeh: remove unused macro IS_BRIDGE
Currently, the macro IS_BRIDGE is not used any where.
This patch just removes it.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
Acked-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/kernel/eeh.c |2 --
1 file changed, 2 deletions(-)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index a4c62eb..4501bbb 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -144,8 +144,6 @@ struct eeh_stats {
static struct eeh_stats eeh_stats;
-#define IS_BRIDGE(class_code) (((class_code)16) == PCI_BASE_CLASS_BRIDGE)
-
static int __init eeh_setup(char *str)
{
if (!strcmp(str, off))
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/powernv: Fix early pci_controller_ops loading.
On Mon, Apr 27, 2015 at 11:54:26AM +1000, Daniel Axtens wrote: Load the PowerNV platform pci controller ops into pci controllers after all the operations are loaded into the platform ops struct, not before. Fixes: c88c2a188905cb3077c3c38dc498e7e9f8eebeee I think it would fix commit 65ebf4b63 (powerpc/powernv: Move controller ops from ppc_md to controller_ops) If that's the case, the above line could be replaced with: Fixes: 65ebf4b63 (powerpc/powernv: Move controller ops from ppc_md to controller_ops) Reported-by: Gavin Shan gws...@linux.vnet.ibm.com Signed-off-by: Daniel Axtens d...@axtens.net The changes look good to me. Reviewed-by: Gavin Shan gws...@linux.vnet.ibm.com Thanks, Gavin --- arch/powerpc/platforms/powernv/pci-ioda.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c index 920c252..f8bc950 100644 --- a/arch/powerpc/platforms/powernv/pci-ioda.c +++ b/arch/powerpc/platforms/powernv/pci-ioda.c @@ -2693,7 +2693,6 @@ static void __init pnv_pci_init_ioda_phb(struct device_node *np, hose-last_busno = 0xff; } hose-private_data = phb; - hose-controller_ops = pnv_pci_controller_ops; phb-hub_id = hub_id; phb-opal_id = phb_id; phb-type = ioda_type; @@ -2812,6 +2811,7 @@ static void __init pnv_pci_init_ioda_phb(struct device_node *np, pnv_pci_controller_ops.enable_device_hook = pnv_pci_enable_device_hook; pnv_pci_controller_ops.window_alignment = pnv_pci_window_alignment; pnv_pci_controller_ops.reset_secondary_bus = pnv_pci_reset_secondary_bus; + hose-controller_ops = pnv_pci_controller_ops; #ifdef CONFIG_PCI_IOV ppc_md.pcibios_fixup_sriov = pnv_pci_ioda_fixup_iov_resources; -- 2.1.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V2 3/4] powerpc/eeh: fix powernv_eeh_wait_state delay logic
As the comment indicates, powernv_eeh_get_state() will inform EEH core to
delay 1 second. This means the delay doesn't happen when
powernv_eeh_get_state() returns.
This patch moves the delay subtraction just before msleep(), which is the
same logic in pseries_eeh_wait_state().
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
Acked-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/eeh-powernv.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/eeh-powernv.c
b/arch/powerpc/platforms/powernv/eeh-powernv.c
index d025471..622f08c 100644
--- a/arch/powerpc/platforms/powernv/eeh-powernv.c
+++ b/arch/powerpc/platforms/powernv/eeh-powernv.c
@@ -1000,13 +1000,13 @@ static int pnv_eeh_wait_state(struct eeh_pe *pe, int
max_wait)
if (ret != EEH_STATE_UNAVAILABLE)
return ret;
- max_wait -= mwait;
if (max_wait = 0) {
pr_warn(%s: Timeout getting PE#%x's state (%d)\n,
__func__, pe-addr, max_wait);
return EEH_STATE_NOT_SUPPORT;
}
+ max_wait -= mwait;
msleep(mwait);
}
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V2 2/4] powerpc/eeh: fix comment for wait_state()
To retrieve the PCI slot state, EEH driver would set a timeout for that.
While current comment is not aligned to what the code does.
This patch fixes those comments according to the code.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
Acked-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/kernel/eeh_driver.c |2 +-
arch/powerpc/platforms/powernv/eeh-powernv.c |2 +-
arch/powerpc/platforms/pseries/eeh_pseries.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/eeh_driver.c b/arch/powerpc/kernel/eeh_driver.c
index 24768ff..89eb4bc 100644
--- a/arch/powerpc/kernel/eeh_driver.c
+++ b/arch/powerpc/kernel/eeh_driver.c
@@ -660,7 +660,7 @@ static void eeh_handle_normal_event(struct eeh_pe *pe)
eeh_pe_dev_traverse(pe, eeh_report_error, result);
/* Get the current PCI slot state. This can take a long time,
-* sometimes over 3 seconds for certain systems.
+* sometimes over 300 seconds for certain systems.
*/
rc = eeh_ops-wait_state(pe, MAX_WAIT_FOR_RECOVERY*1000);
if (rc 0 || rc == EEH_STATE_NOT_SUPPORT) {
diff --git a/arch/powerpc/platforms/powernv/eeh-powernv.c
b/arch/powerpc/platforms/powernv/eeh-powernv.c
index ce738ab..d025471 100644
--- a/arch/powerpc/platforms/powernv/eeh-powernv.c
+++ b/arch/powerpc/platforms/powernv/eeh-powernv.c
@@ -979,7 +979,7 @@ static int pnv_eeh_reset(struct eeh_pe *pe, int option)
/**
* pnv_eeh_wait_state - Wait for PE state
* @pe: EEH PE
- * @max_wait: maximal period in microsecond
+ * @max_wait: maximal period in millisecond
*
* Wait for the state of associated PE. It might take some time
* to retrieve the PE's state.
diff --git a/arch/powerpc/platforms/pseries/eeh_pseries.c
b/arch/powerpc/platforms/pseries/eeh_pseries.c
index 2039397..1ba55d0 100644
--- a/arch/powerpc/platforms/pseries/eeh_pseries.c
+++ b/arch/powerpc/platforms/pseries/eeh_pseries.c
@@ -519,7 +519,7 @@ static int pseries_eeh_reset(struct eeh_pe *pe, int option)
/**
* pseries_eeh_wait_state - Wait for PE state
* @pe: EEH PE
- * @max_wait: maximal period in microsecond
+ * @max_wait: maximal period in millisecond
*
* Wait for the state of associated PE. It might take some time
* to retrieve the PE's state.
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/powernv: Fix early pci_controller_ops loading.
Load the PowerNV platform pci controller ops into pci controllers after all the operations are loaded into the platform ops struct, not before. Fixes: c88c2a188905cb3077c3c38dc498e7e9f8eebeee Reported-by: Gavin Shan gws...@linux.vnet.ibm.com Signed-off-by: Daniel Axtens d...@axtens.net --- arch/powerpc/platforms/powernv/pci-ioda.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c index 920c252..f8bc950 100644 --- a/arch/powerpc/platforms/powernv/pci-ioda.c +++ b/arch/powerpc/platforms/powernv/pci-ioda.c @@ -2693,7 +2693,6 @@ static void __init pnv_pci_init_ioda_phb(struct device_node *np, hose-last_busno = 0xff; } hose-private_data = phb; - hose-controller_ops = pnv_pci_controller_ops; phb-hub_id = hub_id; phb-opal_id = phb_id; phb-type = ioda_type; @@ -2812,6 +2811,7 @@ static void __init pnv_pci_init_ioda_phb(struct device_node *np, pnv_pci_controller_ops.enable_device_hook = pnv_pci_enable_device_hook; pnv_pci_controller_ops.window_alignment = pnv_pci_window_alignment; pnv_pci_controller_ops.reset_secondary_bus = pnv_pci_reset_secondary_bus; + hose-controller_ops = pnv_pci_controller_ops; #ifdef CONFIG_PCI_IOV ppc_md.pcibios_fixup_sriov = pnv_pci_ioda_fixup_iov_resources; -- 2.1.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] cpufreq: powernv: Register for OCC related opal_message notification
On 22 April 2015 at 22:34, Shilpasri G Bhat
shilpa.b...@linux.vnet.ibm.com wrote:
diff --git a/drivers/cpufreq/powernv-cpufreq.c
b/drivers/cpufreq/powernv-cpufreq.c
+static char throttle_reason[6][50] = { No throttling,
Don't need to mention 6 here.
And the max length you need right now is 27, so maybe s/50/30 ?
Also, start 'No Throttling' in a new line, like below.
+ Power Cap,
+ Processor Over Temperature,
+ Power Supply Failure,
+ OverCurrent,
s/OverCurrent/Over Current/ ?
+ OCC Reset
+};
+
+static int powernv_cpufreq_occ_msg(struct notifier_block *nb,
+ unsigned long msg_type, void *msg)
+{
+ struct opal_msg *occ_msg = msg;
+ uint64_t token;
+ uint64_t chip_id, reason;
+
+ if (msg_type != OPAL_MSG_OCC)
+ return 0;
Blank line here.
+ token = be64_to_cpu(occ_msg-params[0]);
Here as well..
+ switch (token) {
+ case 0:
+ occ_reset = true;
+ /*
+* powernv_cpufreq_throttle_check() is called in
+* target() callback which can detect the throttle state
+* for governors like ondemand.
+* But static governors will not call target() often thus
+* report throttling here.
+*/
Now, do I understand correctly that this notifier will be called as
soon as we switch throttling state ?
If yes, then do we still need the throttle_check() routine you added
earlier ? Maybe not.
+ if (!throttled) {
+ throttled = true;
+ pr_crit(CPU Frequency is throttled\n);
+ }
+ pr_info(OCC in Reset\n);
+ break;
+ case 1:
+ pr_info(OCC is Loaded\n);
+ break;
+ case 2:
+ chip_id = be64_to_cpu(occ_msg-params[1]);
+ reason = be64_to_cpu(occ_msg-params[2]);
Blank line here.
+ if (occ_reset) {
+ occ_reset = false;
+ throttled = false;
+ pr_info(OCC is Active\n);
+ /* Sanity check for static governors */
+ powernv_cpufreq_throttle_check(smp_processor_id());
+ } else if (reason) {
+ throttled = true;
+ pr_info(Pmax reduced due to %s on chip %x\n,
+ throttle_reason[reason],
(int)chip_id);
+ } else {
+ throttled = false;
+ pr_info(%s on chip %x\n,
+ throttle_reason[reason],
(int)chip_id);
+ }
Run checkpatch with --strict option, and you will see some warnings.
+ break;
+ }
+ return 0;
+}
+
+static struct notifier_block powernv_cpufreq_opal_nb = {
+ .notifier_call = powernv_cpufreq_occ_msg,
+ .next = NULL,
+ .priority = 0,
+};
+
static void powernv_cpufreq_stop_cpu(struct cpufreq_policy *policy)
{
struct powernv_smp_call_data freq_data;
@@ -430,6 +497,7 @@ static int __init powernv_cpufreq_init(void)
}
register_reboot_notifier(powernv_cpufreq_reboot_nb);
+ opal_message_notifier_register(OPAL_MSG_OCC,
powernv_cpufreq_opal_nb);
return cpufreq_register_driver(powernv_cpufreq_driver);
}
module_init(powernv_cpufreq_init);
--
1.9.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] pci: Use Qemu created PCI device nodes
Hi Thomas, Thomas Huth th...@redhat.com writes: Hi Nikunj, On Wed, 22 Apr 2015 16:27:20 +0530 Nikunj A Dadhania nik...@linux.vnet.ibm.com wrote: PCI Enumeration has been part of SLOF. Now with hotplug code addition in Qemu, it makes more sense to have this code a one place, i.e. Qemu. s/Qemu/QEMU/ and s/code a one place/code in one place/ ? Sure Adding routines to walk through the device nodes created by Qemu. SLOF will configure the device/bridges and program the BARs for communicating with the devices. I wonder whether it would make more sense to also set up the BARs etc. in QEMU instead of SLOF? diff --git a/board-qemu/slof/pci-phb.fs b/board-qemu/slof/pci-phb.fs index e307d95..30b7443 100644 --- a/board-qemu/slof/pci-phb.fs +++ b/board-qemu/slof/pci-phb.fs @@ -283,6 +283,41 @@ setup-puid THEN ; +: phb-pci-walk-bridge ( -- ) +phb-debug? IF . Calling pci-walk-bridge pwd cr THEN + +get-node child ?dup 0= IF EXIT THEN\ get and check if we have children +BEGIN +dup \ Continue as long as there are children +WHILE Most Forth code uses the same indentation for the code between BEGIN...WHILE and WHILE...REPEAT ... so I think you could decrease the indentation of the following block by one level. Sure, emacs is autoindenting this, so i ended up like this. +\ Set child node as current node: +dup set-node Below you are calling pci-device-setup which in turn might include some pci-class_*.fs or pci-device_*.fs files (or even run some FCODE?). At least pci-class_02.fs seems to use an INSTANCE VARIABLE, i.e. the instance template should get modified in that case == Please double-check whether you need to use extend-device here instead (I'm not 100% sure right now ... what happens for example when you run qemu with a network device that SLOF does not provide a pci-device_*.fs for? I guess it will try to include pci-class_02.fs and fail due to the INSTANCE VARIABLE ?) I tried using rtl8139 device, SLOF does not provide driver for that. And that did not create any problem. Not sure about FCODE though, i will do more experiments with non supported devices to check if things are fine. +my-space pci-set-slot \ set the slot bit pci-set-slot seems to rely on the pci-device-slots global variable. This is normally initialized by pci-probe-bus. Now that you provide your own implementation of that function below, I think it should likely also set up the pci-device-slots variable, shouldn't it? Yes, I will need to initialize it for every bus probe to 0. +my-space pci-htype@ \ read HEADER-Type +7f and \ Mask bit 7 - multifunction device +CASE + 0 OF my-space pci-device-setup ENDOF \ | set up the device + 1 OF my-space pci-bridge-setup ENDOF \ | set up the bridge + dup OF my-space pci-htype@ pci-out ENDOF + ENDCASE + peer +REPEAT drop +get-parent set-node +; The remaining part of the patch looks ok to me. Regards, Nikunj ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] pci-phb: check for the 32-bit overflow
Thomas Huth th...@redhat.com writes: On Fri, 24 Apr 2015 12:56:57 +0200 Thomas Huth th...@redhat.com wrote: On Fri, 24 Apr 2015 09:22:33 +0530 Nikunj A Dadhania nik...@linux.vnet.ibm.com wrote: Hi Thomas, Thomas Huth th...@redhat.com writes: Am Wed, 22 Apr 2015 16:27:19 +0530 schrieb Nikunj A Dadhania nik...@linux.vnet.ibm.com: With the addition of 64-bit BARS and increase in the mmio address space, the code was hitting this limit. The memory of pci devices across the bridges were not accessible due to which the drivers failed. Signed-off-by: Nikunj A Dadhania nik...@linux.vnet.ibm.com --- board-qemu/slof/pci-phb.fs | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/board-qemu/slof/pci-phb.fs b/board-qemu/slof/pci-phb.fs index 529772f..e307d95 100644 --- a/board-qemu/slof/pci-phb.fs +++ b/board-qemu/slof/pci-phb.fs @@ -258,7 +258,8 @@ setup-puid decode-64 2 / dup r\ Decode and calc size/2 pci-next-mem @ + dup pci-max-mem ! \ and calc max mem address Could pci-max-mem overflow, too? Should not, its only the boundary that was an issue. Qemu sends base and size, base + size can be till uint32 max. So for example base was 0xC000. and size was 0x4000., we add up base + size and put pci-max-mmio as 0x1.., which would get programmend in the bridge bars: lower limit as 0xC000 and 0x as upper limit. And no mmio access were going across the bridge. In my testing, I have found one more issue with translate-my-address, it does not take care of 64-bit addresses. I have a patch working for SLOF, but its breaking the guest kernel booting. dup pci-next-mmio ! \ which is the same as MMIO base -r + pci-max-mmio ! \ calc max MMIO address +r + min pci-max-mmio !\ calc max MMIO address and +\ check the 32-bit boundary Ok, thanks a lot for the example! I think your patch likely works in practice, but after staring at the code for a while, I think the real bug is slightly different. If I get the code above right, pci-max-mmio is normally set to the first address that is _not_ part of the mmio window anymore, right. Now have a look at pci-bridge-set-mmio-base in pci-scan.fs: : pci-bridge-set-mmio-base ( addr -- ) pci-next-mmio @ 10 #aligned \ read the current Value and align to 1MB boundary dup 10 + pci-next-mmio !\ and write back with 1MB for bridge 10 rshift \ mmio-base reg is only the upper 16 bits pci-max-mmio @ and or \ and Insert mmio Limit (set it to max) swap 20 + rtas-config-l!\ and write it into the bridge ; Seems like the pci-max-mmio, i.e. the first address that is not in the window anymore, is programmed into the memory limit register here - but according to the pci-to-pci bridge specification, it should be the last address of the window instead. So I think the correct fix would be to decrease the pci-max-mmio value in pci-bridge-set-mmio-base by 1- before programming it into the limit register (note: in pci-bridge-set-mmio-limit you can find a 1- already, so I think this also should be done in pci-bridge-set-mmio-base, too) So if you've got some spare minutes, could you please check whether that would fix the issue, too? By the way, if I'm right, pci-bridge-set-mem-base seems to suffer from the same problem, too. And pci-bridge-set-io-base as well. Regards Nikunj ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv2 2/8] perf probe: Improve detection of file/function name in the probe pattern
On 2015/03/13 08:20PM, Masami Hiramatsu wrote:
(2015/03/13 5:24), Arnaldo Carvalho de Melo wrote:
Em Mon, Dec 15, 2014 at 08:20:32PM +0530, Naveen N. Rao escreveu:
Currently, perf probe considers patterns including a '.' to be a file.
However, this causes problems on powerpc ABIv1 where all functions have
a leading '.':
$ perf probe -F | grep schedule_timeout_interruptible
.schedule_timeout_interruptible
$ perf probe .schedule_timeout_interruptible
Semantic error :File always requires line number or lazy pattern.
Error: Command Parse Error.
Fix this by checking the probe pattern in more detail.
Masami, can I have your Acked-by or Reviewed-by?
As far as I can see, this is not enough for fixing that issue.
Could you fold the first half of [4/8] to this patch?
Sure.
I also have some comments on it. See below.
Signed-off-by: Naveen N. Rao naveen.n@linux.vnet.ibm.com
---
tools/perf/util/probe-event.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 28eb141..9943ff3 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -999,6 +999,24 @@ static int parse_perf_probe_point(char *arg, struct
perf_probe_event *pev)
arg = tmp;
}
+ /*
+ * Check arg is function or file name and copy it.
+ *
+ * We consider arg to be a file spec if and only if it satisfies
+ * all of the below criteria::
+ * - it does not include any of +@%,
+ * - it includes one of :;, and
+ * - it has a period '.' in the name.
+ *
+ * Otherwise, we consider arg to be a function specification.
+ */
+ c = 0;
Oh please, don't reuse 'char c' for a boolean flag, you should
introduce new 'bool file_loc' etc.
+ if (!strpbrk(arg, +@%) (ptr = strpbrk(arg, ;:)) != NULL) {
+ /* This is a file spec if it includes a '.' before ; or : */
+ if (memchr(arg, '.', ptr-arg))
^^ add spaces around '-'.
Sure.
- Naveen
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] pci-phb: check for the 32-bit overflow
Thomas Huth th...@redhat.com writes: On Fri, 24 Apr 2015 09:22:33 +0530 Nikunj A Dadhania nik...@linux.vnet.ibm.com wrote: Hi Thomas, Thomas Huth th...@redhat.com writes: Am Wed, 22 Apr 2015 16:27:19 +0530 schrieb Nikunj A Dadhania nik...@linux.vnet.ibm.com: With the addition of 64-bit BARS and increase in the mmio address space, the code was hitting this limit. The memory of pci devices across the bridges were not accessible due to which the drivers failed. Signed-off-by: Nikunj A Dadhania nik...@linux.vnet.ibm.com --- board-qemu/slof/pci-phb.fs | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/board-qemu/slof/pci-phb.fs b/board-qemu/slof/pci-phb.fs index 529772f..e307d95 100644 --- a/board-qemu/slof/pci-phb.fs +++ b/board-qemu/slof/pci-phb.fs @@ -258,7 +258,8 @@ setup-puid decode-64 2 / dup r\ Decode and calc size/2 pci-next-mem @ + dup pci-max-mem ! \ and calc max mem address Could pci-max-mem overflow, too? Should not, its only the boundary that was an issue. Qemu sends base and size, base + size can be till uint32 max. So for example base was 0xC000. and size was 0x4000., we add up base + size and put pci-max-mmio as 0x1.., which would get programmend in the bridge bars: lower limit as 0xC000 and 0x as upper limit. And no mmio access were going across the bridge. In my testing, I have found one more issue with translate-my-address, it does not take care of 64-bit addresses. I have a patch working for SLOF, but its breaking the guest kernel booting. dup pci-next-mmio ! \ which is the same as MMIO base -r + pci-max-mmio ! \ calc max MMIO address +r + min pci-max-mmio !\ calc max MMIO address and +\ check the 32-bit boundary Ok, thanks a lot for the example! I think your patch likely works in practice, but after staring at the code for a while, I think the real bug is slightly different. If I get the code above right, pci-max-mmio is normally set to the first address that is _not_ part of the mmio window anymore, right. Now have a look at pci-bridge-set-mmio-base in pci-scan.fs: : pci-bridge-set-mmio-base ( addr -- ) pci-next-mmio @ 10 #aligned \ read the current Value and align to 1MB boundary dup 10 + pci-next-mmio !\ and write back with 1MB for bridge 10 rshift \ mmio-base reg is only the upper 16 bits pci-max-mmio @ and or \ and Insert mmio Limit (set it to max) swap 20 + rtas-config-l!\ and write it into the bridge ; Seems like the pci-max-mmio, i.e. the first address that is not in the window anymore, is programmed into the memory limit register here - but according to the pci-to-pci bridge specification, it should be the last address of the window instead. So I think the correct fix would be to decrease the pci-max-mmio value in pci-bridge-set-mmio-base by 1- before programming it into the limit register (note: in pci-bridge-set-mmio-limit you can find a 1- already, so I think this also should be done in pci-bridge-set-mmio-base, too) Yes, you are right, and because it was being done during probing and correct values set later on nobody noticed this as an issue. We only found it when we had an address that was over 32-bit. So if you've got some spare minutes, could you please check whether that would fix the issue, too? I have tried this fix and works fine, will change this and repost. Regards, Nikunj ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv2 5/8] perf probe powerpc: Allow matching against dot symbols
On 2015/03/12 05:30PM, Arnaldo Carvalho de Melo wrote:
Em Mon, Dec 15, 2014 at 08:20:35PM +0530, Naveen N. Rao escreveu:
Allow perf probe to work on powerpc ABIv1 without the need to specify
the leading dot '.' for functions. 'perf probe do_fork' works with this
patch.
Introduce HAVE_ARCH_SYMBOL_HANDLING to indicate need for special
handling of symbols. In this patch, we override probe_function_filter()
on powerpc to account for dot symbols.
This one looks better, does arch specific stuff in tools/perf/arch,
good, some nits below.
Signed-off-by: Naveen N. Rao naveen.n@linux.vnet.ibm.com
---
Changes from the previous patchset:
Introduced arch helper to override the way probe function filter works.
tools/perf/arch/powerpc/Makefile| 1 +
tools/perf/arch/powerpc/util/sym-handling.c | 28
tools/perf/config/Makefile | 1 +
tools/perf/util/probe-event.c | 10 +-
tools/perf/util/probe-event.h | 5 +
5 files changed, 40 insertions(+), 5 deletions(-)
create mode 100644 tools/perf/arch/powerpc/util/sym-handling.c
diff --git a/tools/perf/arch/powerpc/Makefile
b/tools/perf/arch/powerpc/Makefile
index 6f7782b..1c3d435 100644
--- a/tools/perf/arch/powerpc/Makefile
+++ b/tools/perf/arch/powerpc/Makefile
@@ -3,4 +3,5 @@ PERF_HAVE_DWARF_REGS := 1
LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/dwarf-regs.o
LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/skip-callchain-idx.o
endif
+LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/sym-handling.o
LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/header.o
diff --git a/tools/perf/arch/powerpc/util/sym-handling.c
b/tools/perf/arch/powerpc/util/sym-handling.c
new file mode 100644
index 000..0a77825
--- /dev/null
+++ b/tools/perf/arch/powerpc/util/sym-handling.c
@@ -0,0 +1,28 @@
+/*
+ * Special symbol handling for PowerPC:
+ * - Handle dot symbols on ABIv1
+ *
+ * Copyright (C) 2014 Naveen N Rao, IBM Corporation.
+ *
+ * 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 map.h
+#include symbol.h
+#include probe-event.h
+
+int probe_function_filter(struct map *map __maybe_unused, struct symbol
*sym)
+{
+ if (sym-binding == STB_GLOBAL || sym-binding == STB_LOCAL) {
+ if ((strcmp(looking_function_name, sym-name) == 0) ||
+ (sym-name[0] == '.' looking_function_name[0] != '.'
+strcmp(looking_function_name, sym-name+1) == 0)) {
+ num_matched_functions++;
+ return 0;
+ }
+ }
+ return 1;
+}
diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index 5d4b039..35cf934 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -383,6 +383,7 @@ ifeq ($(ARCH),powerpc)
ifndef NO_DWARF
CFLAGS += -DHAVE_SKIP_CALLCHAIN_IDX
endif
+ CFLAGS += -DHAVE_ARCH_SYMBOL_HANDLING
Dunno about this naming, looks too general: SYMBOL_HANDLING, but can't
come to some better one now, anyone?
endif
ifndef NO_LIBUNWIND
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 74b7fef..7eb9b27 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -50,6 +50,8 @@
#define PERFPROBE_GROUP probe
bool probe_event_dry_run; /* Dry run flag */
+char *looking_function_name;
+int num_matched_functions;
#define semantic_error(msg ...) pr_err(Semantic error : msg)
@@ -2210,11 +2212,8 @@ static int __add_probe_trace_events(struct
perf_probe_event *pev,
return ret;
}
-static char *looking_function_name;
-static int num_matched_functions;
-
-static int probe_function_filter(struct map *map __maybe_unused,
- struct symbol *sym)
+#ifndef HAVE_ARCH_SYMBOL_HANDLING
+int probe_function_filter(struct map *map __maybe_unused, struct symbol
*sym)
{
if ((sym-binding == STB_GLOBAL || sym-binding == STB_LOCAL)
strcmp(looking_function_name, sym-name) == 0) {
@@ -2223,6 +,7 @@ static int probe_function_filter(struct map *map
__maybe_unused,
}
return 1;
}
+#endif /* HAVE_ARCH_SYMBOL_HANDLING */
Can't we do something like providing a weak function and let the linked
to its work? I guess we have cases like this in tools/ already. I.e. not
using the ifndef block. Minor nit tho.
That sounds like a good idea. I will move these over to use __weak
functions.
#define strdup_or_goto(str, label) \
({ char *__p = strdup(str); if (!__p) goto label; __p; })
diff --git a/tools/perf/util/probe-event.h b/tools/perf/util/probe-event.h
Re: [PATCHv2 3/8] perf probe powerpc: Fix symbol fixup issues due to ELF type
On 2015/03/12 05:23PM, Arnaldo Carvalho de Melo wrote:
Em Mon, Dec 15, 2014 at 08:20:33PM +0530, Naveen N. Rao escreveu:
If using the symbol table, symbol addresses are not being fixed up
properly, resulting in probes being placed at wrong addresses:
# perf probe do_fork
Added new event:
probe:do_fork(on do_fork)
You can now use it in all perf tools, such as:
perf record -e probe:do_fork -aR sleep 1
# cat /sys/kernel/debug/tracing/kprobe_events
p:probe/do_fork _text+635952
# printf %x 635952
9b430
# grep do_fork /boot/System.map
c00ab430 T .do_fork
Fix by checking for ELF type ET_DYN used by ppc64 kernels.
Sorry if this was answered already, its been a while since this was
posted/discussed... Are you completely sure this is not a problem on
!ppc?
Woudln't it be more conservative to somehow only adjust symbols for this
ET_DYN type if the arch is ppc? I.e. something like moving that
adjust_symbols logic to be arch_adjust_symbols(), provide a default and
then override it for ppc to include also ET_DYN?
I did check and I don't think any other arch kernel uses ET_DYN, but
yes, being conservative, I could just make this a arch helper. Will do.
- Naveen
Looking at the other patches...
- Arnaldo
Signed-off-by: Naveen N. Rao naveen.n@linux.vnet.ibm.com
---
tools/perf/util/symbol-elf.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 06fcd1b..7ac4e4c 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -683,7 +683,8 @@ int symsrc__init(struct symsrc *ss, struct dso *dso,
const char *name,
NULL) != NULL);
} else {
ss-adjust_symbols = ehdr.e_type == ET_EXEC ||
-ehdr.e_type == ET_REL;
+ehdr.e_type == ET_REL ||
+ehdr.e_type == ET_DYN;
}
ss-name = strdup(name);
--
2.1.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] pci-phb: check for the 32-bit overflow
Thomas Huth th...@redhat.com writes: On Fri, 24 Apr 2015 12:56:57 +0200 Thomas Huth th...@redhat.com wrote: On Fri, 24 Apr 2015 09:22:33 +0530 Nikunj A Dadhania nik...@linux.vnet.ibm.com wrote: Hi Thomas, Thomas Huth th...@redhat.com writes: Am Wed, 22 Apr 2015 16:27:19 +0530 schrieb Nikunj A Dadhania nik...@linux.vnet.ibm.com: With the addition of 64-bit BARS and increase in the mmio address space, the code was hitting this limit. The memory of pci devices across the bridges were not accessible due to which the drivers failed. Signed-off-by: Nikunj A Dadhania nik...@linux.vnet.ibm.com --- board-qemu/slof/pci-phb.fs | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/board-qemu/slof/pci-phb.fs b/board-qemu/slof/pci-phb.fs index 529772f..e307d95 100644 --- a/board-qemu/slof/pci-phb.fs +++ b/board-qemu/slof/pci-phb.fs @@ -258,7 +258,8 @@ setup-puid decode-64 2 / dup r\ Decode and calc size/2 pci-next-mem @ + dup pci-max-mem ! \ and calc max mem address Could pci-max-mem overflow, too? Should not, its only the boundary that was an issue. Qemu sends base and size, base + size can be till uint32 max. So for example base was 0xC000. and size was 0x4000., we add up base + size and put pci-max-mmio as 0x1.., which would get programmend in the bridge bars: lower limit as 0xC000 and 0x as upper limit. And no mmio access were going across the bridge. In my testing, I have found one more issue with translate-my-address, it does not take care of 64-bit addresses. I have a patch working for SLOF, but its breaking the guest kernel booting. dup pci-next-mmio ! \ which is the same as MMIO base -r + pci-max-mmio ! \ calc max MMIO address +r + min pci-max-mmio !\ calc max MMIO address and +\ check the 32-bit boundary Ok, thanks a lot for the example! I think your patch likely works in practice, but after staring at the code for a while, I think the real bug is slightly different. If I get the code above right, pci-max-mmio is normally set to the first address that is _not_ part of the mmio window anymore, right. Now have a look at pci-bridge-set-mmio-base in pci-scan.fs: : pci-bridge-set-mmio-base ( addr -- ) pci-next-mmio @ 10 #aligned \ read the current Value and align to 1MB boundary dup 10 + pci-next-mmio !\ and write back with 1MB for bridge 10 rshift \ mmio-base reg is only the upper 16 bits pci-max-mmio @ and or \ and Insert mmio Limit (set it to max) swap 20 + rtas-config-l!\ and write it into the bridge ; Seems like the pci-max-mmio, i.e. the first address that is not in the window anymore, is programmed into the memory limit register here - but according to the pci-to-pci bridge specification, it should be the last address of the window instead. So I think the correct fix would be to decrease the pci-max-mmio value in pci-bridge-set-mmio-base by 1- before programming it into the limit register (note: in pci-bridge-set-mmio-limit you can find a 1- already, so I think this also should be done in pci-bridge-set-mmio-base, too) So if you've got some spare minutes, could you please check whether that would fix the issue, too? By the way, if I'm right, pci-bridge-set-mem-base seems to suffer from the same problem, too. Both have the same issue, so fixed like below diff --git a/slof/fs/pci-scan.fs b/slof/fs/pci-scan.fs index 15d0c8e..a552a74 100644 --- a/slof/fs/pci-scan.fs +++ b/slof/fs/pci-scan.fs @@ -87,7 +87,7 @@ here 100 allot CONSTANT pci-device-vec pci-next-mmio @ 10 #aligned \ read the current Value and align to 1MB boundary dup 10 + pci-next-mmio !\ and write back with 1MB for bridge 10 rshift \ mmio-base reg is only the upper 16 bits -pci-max-mmio @ and or \ and Insert mmio Limit (set it to max) +pci-max-mmio @ 1- and or \ and Insert mmio Limit (set it to max) swap 20 + rtas-config-l!\ and write it into the bridge ; @@ -116,7 +116,7 @@ here 100 allot CONSTANT pci-device-vec 2 pick 2C + rtas-config-l! \ | and set the Limit THEN\ FI 10 rshift \ keep upper 16 bits -pci-max-mem @ and or \ and Insert mmem Limit (set it to max) +pci-max-mem @ 1- and or\ and Insert mmem Limit (set it to max) swap 24 + rtas-config-l!\ and write it into the
Re: [PATCHv2 2/8] perf probe: Improve detection of file/function name in the probe pattern
On 2015/03/13 08:20PM, Masami Hiramatsu wrote: (2015/03/13 5:24), Arnaldo Carvalho de Melo wrote: Em Mon, Dec 15, 2014 at 08:20:32PM +0530, Naveen N. Rao escreveu: Currently, perf probe considers patterns including a '.' to be a file. However, this causes problems on powerpc ABIv1 where all functions have a leading '.': $ perf probe -F | grep schedule_timeout_interruptible .schedule_timeout_interruptible $ perf probe .schedule_timeout_interruptible Semantic error :File always requires line number or lazy pattern. Error: Command Parse Error. Fix this by checking the probe pattern in more detail. Masami, can I have your Acked-by or Reviewed-by? As far as I can see, this is not enough for fixing that issue. Could you fold the first half of [4/8] to this patch? I also have some comments on it. See below. Masami, Arnaldo, Thanks for the review. v3 patches forthcoming... - Naveen ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] powerpc/powernv: Fix early pci_controller_ops loading.
Load the PowerNV platform pci controller ops into pci controllers after all the operations are loaded into the platform ops struct, not before. Fixes: 65ebf4b63 (powerpc/powernv: Move controller ops from ppc_md to controller_ops) Reported-by: Gavin Shan gws...@linux.vnet.ibm.com Reviewed-by: Gavin Shan gws...@linux.vnet.ibm.com Signed-off-by: Daniel Axtens d...@axtens.net --- v2: Correcct Fixes: line arch/powerpc/platforms/powernv/pci-ioda.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c index 920c252..f8bc950 100644 --- a/arch/powerpc/platforms/powernv/pci-ioda.c +++ b/arch/powerpc/platforms/powernv/pci-ioda.c @@ -2693,7 +2693,6 @@ static void __init pnv_pci_init_ioda_phb(struct device_node *np, hose-last_busno = 0xff; } hose-private_data = phb; - hose-controller_ops = pnv_pci_controller_ops; phb-hub_id = hub_id; phb-opal_id = phb_id; phb-type = ioda_type; @@ -2812,6 +2811,7 @@ static void __init pnv_pci_init_ioda_phb(struct device_node *np, pnv_pci_controller_ops.enable_device_hook = pnv_pci_enable_device_hook; pnv_pci_controller_ops.window_alignment = pnv_pci_window_alignment; pnv_pci_controller_ops.reset_secondary_bus = pnv_pci_reset_secondary_bus; + hose-controller_ops = pnv_pci_controller_ops; #ifdef CONFIG_PCI_IOV ppc_md.pcibios_fixup_sriov = pnv_pci_ioda_fixup_iov_resources; -- 2.1.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/powernv: Fix early pci_controller_ops loading.
Fixes: c88c2a188905cb3077c3c38dc498e7e9f8eebeee I think it would fix commit 65ebf4b63 (powerpc/powernv: Move controller ops from ppc_md to controller_ops) If that's the case, the above line could be replaced with: Fixes: 65ebf4b63 (powerpc/powernv: Move controller ops from ppc_md to controller_ops) Reported-by: Gavin Shan gws...@linux.vnet.ibm.com Signed-off-by: Daniel Axtens d...@axtens.net The changes look good to me. Reviewed-by: Gavin Shan gws...@linux.vnet.ibm.com You are right again! I have sent v2 with the correct Fixes: line. Thanks for the review. Daniel signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 2/8] ipmi/powernv: Convert to irq event interface
On Fri, 2015-04-10 at 18:24 +1000, Alistair Popple wrote: Convert the opal ipmi driver to use the new irq interface for events. drivers/char/ipmi/ipmi_powernv.c | 39 ++- This needs to be CC'ed to the IPMI folks, and preferably get their ACK so we can take the whole series via the powerpc tree. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
