Re: [PATCH v6 41/48] powerpc: Register with kernel power-off handler
On 11/10/2014 11:42 PM, Michael Ellerman wrote: On Sun, 2014-11-09 at 17:42 -0800, Guenter Roeck wrote: Register with kernel power-off handler instead of setting pm_power_off directly. If there is an indication that there can be more than one power-off handler, use register_power_off_handler, otherwise use register_power_off_handler_simple to register the power-off handler. If the power-off handler only resets or stops the system, select the fallback priority to indicate that the power-off handler is one of last resort. If the power-off handler powers off the system, select the default priority, unless the power-off handler installation code suggests that there can be more than one power-off handler and the new handler is only installed conditionally. In this case, install the handler with low priority. Cc: Alexander Graf ag...@suse.de Cc: Michael Ellerman m...@ellerman.id.au Signed-off-by: Guenter Roeck li...@roeck-us.net Can you fold in the patch below. I know pm.h is included by device.h, so most things will already have it, but I'd rather be explicit. With that you can add my: Acked-by: Michael Ellerman m...@ellerman.id.au Done. Thanks, Guenter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] DT: add MDIO node for FMan node
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, November 11, 2014 8:23 AM
To: shh@gmail.com
Cc: linuxppc-dev@lists.ozlabs.org; devicet...@vger.kernel.org; Medve
Emilian-EMMEDVE1; Xie Shaohui-B21989
Subject: Re: [PATCH] DT: add MDIO node for FMan node
On Tue, 2014-11-04 at 19:56 +0800, shh@gmail.com wrote:
From: Shaohui Xie shaohui@freescale.com
This binding is for FMan MDIO, it covers FMan v2 FMan v3.
Signed-off-by: Shaohui Xie shaohui@freescale.com
---
based on http://patchwork.ozlabs.org/patch/390351/
for 'next' of
git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git
Are there any other FMan pieces that are missing from the above patch?
[S.H] I'm adding Igal for this comment.
.../devicetree/bindings/powerpc/fsl/fman.txt | 69
++
1 file changed, 69 insertions(+)
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
index da8e5f2..83c2f14 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
@@ -7,6 +7,7 @@ CONTENTS
- FMan MURAM Node
- FMan dTSEC/XGEC/mEMAC Node
- FMan IEEE 1588 Node
+ - FMan MDIO Node
- Example
==
=== @@ -352,6 +353,67 @@ ptp-timer@fe000 { };
==
===
+FMan MDIO Node
+
+DESCRIPTION
+
+The MDIO is a bus to which the PHY devices are connected.
+
+PROPERTIES
+
+- compatible
+ Usage: required
+ Value type: stringlist
+ Definition: A standard property.
+ Must include fsl,fman-mdio for 1 Gb/s MDIO from FMan v2.
+ Must include fsl,fman-xmdio for 10 Gb/s MDIO from FMan v2.
+ Must include fsl,fman-memac-mdio for 1/10 Gb/s MDIO from
+ FMan v3.
+
+- reg
+ Usage: required
+ Value type: prop-encoded-array
+ Definition: A standard property.
+
+- bus-frequency
+ Usage: optional
+ Value type: u32
+ Definition: Default MDIO bus clock speed.
Use clocks/clock-names
[S.H] The MDIO uses Fman clock and divides it to a proper value which is
specified by this property.
+- interrupts
+ Usage: optional
+ Value type: prop-encoded-array
+ Definition: MDIO controller event interrupts.
One interrupt or multiple?
[S.H] One for 1 Gb/s, one for 10 Gb/s.
+
+- type
+ Usage: required for FMan v3
+ Value type: stringlist
+ Definition: A standard property.
What standard is type defined in?
[S.H] It's to differentiate between the internal and external MDIO, I'm not
quite sure about naming it, or what could be better way to differentiate the
MDIOs?
+ FMan v3 has internal MDIO for internal PCS(Physical Coding
+ Sublayer) PHYs and external MDIO for external PHYs.
+ The settings and programming routines for internal/external
+ MDIO are different. Must include internal for internal MDIO,
+ must include external for external MDIO.
I assume fman v2 is always internal? How about a boolean fsl,fman-
internal-phy property instead?
[S.H] Both Fman v2 v3 have internal/external MDIO, Fman v2 uses internal MDIO
for TBI operations to set the SGMII PHY,
The TBI implements transmit/receive portions of PCS, it's not used in Linux.
The PCS on Fman V3 are not just for SGMII, it has more implementations, it's
used in Linux.
+
+EXAMPLE
+
+Example for FMan v2:
+
+mdio@f1000 {
+ compatible = fsl,fman-xmdio;
+ reg = 0xf1000 0x1000;
+};
+
+Example for FMan v3:
+
+mdio@fd000 {
+ compatible = fsl,fman-memac-mdio;
+ reg = 0xfd000 0x1000;
+ bus-frequency = 250;
+ type = external;
+};
+
+=
+
Example
fman@40 {
@@ -526,4 +588,11 @@ fman@40 {
compatible = fsl,fman-ptp-timer;
reg = 0xfe000 0x1000;
};
+
+ mdio@fd000 {
+ compatible = fsl,fman-memac-mdio;
+ reg = 0xfd000 0x1000;
+ bus-frequency = 250;
+ type = external;
+ };
};
The rest of the example is fman v2; don't mix an fman v3 node in with
that.
[S.H] OK. Will fix it.
Thanks!
Shaohui
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] DT: add MDIO node for FMan node
On Tue, 2014-11-11 at 04:32 -0600, Xie Shaohui-B21989 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, November 11, 2014 8:23 AM
To: shh@gmail.com
Cc: linuxppc-dev@lists.ozlabs.org; devicet...@vger.kernel.org; Medve
Emilian-EMMEDVE1; Xie Shaohui-B21989
Subject: Re: [PATCH] DT: add MDIO node for FMan node
On Tue, 2014-11-04 at 19:56 +0800, shh@gmail.com wrote:
From: Shaohui Xie shaohui@freescale.com
This binding is for FMan MDIO, it covers FMan v2 FMan v3.
Signed-off-by: Shaohui Xie shaohui@freescale.com
---
based on http://patchwork.ozlabs.org/patch/390351/
for 'next' of
git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git
Are there any other FMan pieces that are missing from the above patch?
[S.H] I'm adding Igal for this comment.
.../devicetree/bindings/powerpc/fsl/fman.txt | 69
++
1 file changed, 69 insertions(+)
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
index da8e5f2..83c2f14 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
@@ -7,6 +7,7 @@ CONTENTS
- FMan MURAM Node
- FMan dTSEC/XGEC/mEMAC Node
- FMan IEEE 1588 Node
+ - FMan MDIO Node
- Example
==
=== @@ -352,6 +353,67 @@ ptp-timer@fe000 { };
==
===
+FMan MDIO Node
+
+DESCRIPTION
+
+The MDIO is a bus to which the PHY devices are connected.
+
+PROPERTIES
+
+- compatible
+ Usage: required
+ Value type: stringlist
+ Definition: A standard property.
+ Must include fsl,fman-mdio for 1 Gb/s MDIO from FMan v2.
+ Must include fsl,fman-xmdio for 10 Gb/s MDIO from FMan v2.
+ Must include fsl,fman-memac-mdio for 1/10 Gb/s MDIO from
+ FMan v3.
+
+- reg
+ Usage: required
+ Value type: prop-encoded-array
+ Definition: A standard property.
+
+- bus-frequency
+ Usage: optional
+ Value type: u32
+ Definition: Default MDIO bus clock speed.
Use clocks/clock-names
[S.H] The MDIO uses Fman clock and divides it to a proper value which is
specified by this property.
Use clocks/clock-names to describe that relationship.
+- interrupts
+ Usage: optional
+ Value type: prop-encoded-array
+ Definition: MDIO controller event interrupts.
One interrupt or multiple?
[S.H] One for 1 Gb/s, one for 10 Gb/s.
Then the binding needs to say that there are two (except for
fsl,fman-mdio, right?) and which is which.
+
+- type
+ Usage: required for FMan v3
+ Value type: stringlist
+ Definition: A standard property.
What standard is type defined in?
[S.H] It's to differentiate between the internal and external MDIO, I'm
not quite sure about naming it, or what could be better way to
differentiate the MDIOs?
I'm not questioning the need to convey this information. I'm saying
it's not A standard property. I'd also like to see a better name.
+ FMan v3 has internal MDIO for internal PCS(Physical Coding
+ Sublayer) PHYs and external MDIO for external PHYs.
+ The settings and programming routines for internal/external
+ MDIO are different. Must include internal for internal MDIO,
+ must include external for external MDIO.
I assume fman v2 is always internal? How about a boolean fsl,fman-
internal-phy property instead?
[S.H] Both Fman v2 v3 have internal/external MDIO, Fman v2 uses internal
MDIO for TBI operations to set the SGMII PHY,
The TBI implements transmit/receive portions of PCS, it's not used in
Linux. The PCS on Fman V3 are not just for SGMII, it has more
implementations, it's used in Linux.
The device tree is about the hardware, not what's used in Linux.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] hwmon: (ibmpowernv) Use platform 'id_table' to probe the device
On Mon, Nov 10, 2014 at 10:04:57AM +1100, Michael Ellerman wrote: On Wed, 2014-11-05 at 06:21 -0800, Guenter Roeck wrote: On Wed, Nov 05, 2014 at 04:45:14PM +0530, Neelesh Gupta wrote: The current driver probe() function assumes the sensor device to be alwary present and gets executed every time if the driver is loaded, but the appropriate hardware could not be present. So, move the platform device creation as part of platform init code and use the 'id_table' to check if the device present or not. Signed-off-by: Neelesh Gupta neele...@linux.vnet.ibm.com Looks good. We'll need an ack from one of the powerpc maintainers to proceed. Looks OK to me. Acked-by: Michael Ellerman m...@ellerman.id.au Applied to -next. Thanks, Guenter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 net-next] PPC: bpf_jit_comp: add SKF_AD_HATYPE instruction
From: Denis Kirjanov k...@linux-powerpc.org Date: Mon, 10 Nov 2014 08:59:43 +0300 Add BPF extension SKF_AD_HATYPE to ppc JIT to check the hw type of the interface Before: [ 57.723666] test_bpf: #20 LD_HATYPE [ 57.723675] BPF filter opcode 0020 (@0) unsupported [ 57.724168] 48 48 PASS After: [ 103.053184] test_bpf: #20 LD_HATYPE 7 6 PASS CC: Alexei Starovoitovalexei.starovoi...@gmail.com CC: Daniel Borkmanndbork...@redhat.com CC: Philippe Bergheaudfe...@linux.vnet.ibm.com Signed-off-by: Denis Kirjanov k...@linux-powerpc.org v2: address Alexei's comments Applied, thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] cpufreq: qoriq: Make the driver usable on all QorIQ platforms
On Tue, 2014-10-21 at 08:59 +, Yuantian Tang wrote: -config PPC_CORENET_CPUFREQ - tristate CPU frequency scaling driver for Freescale E500MC SoCs - depends on PPC_E500MC OF COMMON_CLK +config QORIQ_CPUFREQ + tristate CPU frequency scaling driver for Freescale QorIQ SoCs + depends on OF COMMON_CLK select CLK_PPC_CORENET help - This adds the CPUFreq driver support for Freescale e500mc, - e5500 and e6500 series SoCs which are capable of changing - the CPU's frequency dynamically. + This adds the CPUFreq driver support for Freescale QorIQ SoCs + which are capable of changing the CPU's frequency dynamically. config CPU_FREQ_PMAC bool Support for Apple PowerBooks Don't need this duplication at all. Just move this to Kconfig instead of .arm and ppc. If I do so, menuconfig will display like this(on PPC): PowerPC CPU frequency scaling drivers QorIQ CPU Frequency scaling --- * CPU frequency scaling driver for Freescale QorIQ SoCs On ARM, there should be a similar problem. Isn't weird? What purpose do those arch CPU frequency scaling drivers submenus serve, versus just including the options in the main cpufreq menu? It's not as if more than one arch would be visible at once (and when a situation with multiple visible menus popped up, it was considered a bug). -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 4/7] sound/radeon: Add quirk for broken 64-bit MSI
On Thu, Oct 16, 2014 at 09:55:32AM +1100, Benjamin Herrenschmidt wrote: On Wed, 2014-10-15 at 16:19 -0600, Bjorn Helgaas wrote: PCI/MSI: Add device flag indicating that 64-bit MSIs don't work I'd be happy to merge it, but given what I know now, I would wait and merge it during the v3.19 merge window. It sounds like it's more urgent than that and should be merged earlier, but from the changelogs, it looks like we're just replacing the powerpc-specific quirk with a more generic one. So I assume you'll merge it via powerpc unless I hear otherwise. Either way works but it's easy to keep it all in one series in one tree. The urgency is that the current powerpc quirk works only with one specific card (ie, one device ID for gfx and one for audio) and misses the DMA limitation of the sound driver (which is a somewhat orthogonal issue but the patch for it is in the series). Any other radeon card causes the machine to crash at boot (the driver doesn't recover well from the EEH error triggered by the bad MSI address and the world falls over from there). So I want this to go back into distros. I'm still assuming you're going to merge this series, but I don't see it in your tree (https://git.kernel.org/cgit/linux/kernel/git/benh/powerpc.git/) yet. Do you want me to do anything with it? Bjorn ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] DT: add MDIO node for FMan node
The TBI implements transmit/receive portions of PCS, it's not used in Linux. The PCS on Fman V3 are not just for SGMII, it has more implementations, it's used in Linux. It is used for PHY less mode(aka fixed PHY) and needs to be exposed to linux so it is possible to select SGMII/1000BASE-X, AutoNeg etc. The device tree is about the hardware, not what's used in Linux. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2] powerpc/TM: Disable/Enable TM looking at the ibm, pa-features device tree entry
On Sun, 2014-11-02 at 20:02 +0530, Aneesh Kumar K.V wrote:
Runtime disable transactional memory feature looking at pa-features
device tree entry. We need to do this so that we can run a kernel
built with TM config in PR mode.
I'm happy to turn this off but why do we need to do this in PR mode?
Can you explain this in the commit message.
For PR guest we provide a device
tree entry with TM feature disabled in pa-features
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
Changes from V1:
* rebase to latest linus
arch/powerpc/kernel/prom.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 099f27e6d1b0..3e22930f15d1 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -160,6 +160,11 @@ static struct ibm_pa_feature {
{CPU_FTR_NODSISRALIGN, 0, 0,1, 1, 1},
{0, MMU_FTR_CI_LARGE_PAGE, 0, 1, 2, 0},
{CPU_FTR_REAL_LE, PPC_FEATURE_TRUE_LE, 5, 0, 0},
+ /*
+ * We should use CPU_FTR_TM_COMP so that if we disable TM, it won't get
+ * enabled via device tree
+ */
+ {CPU_FTR_TM_COMP, 0, 0, 22, 0, 0},
};
static void __init scan_features(unsigned long node, const unsigned char
*ftrs,
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 4/7] sound/radeon: Add quirk for broken 64-bit MSI
On Tue, 2014-11-11 at 14:12 -0700, Bjorn Helgaas wrote: On Thu, Oct 16, 2014 at 09:55:32AM +1100, Benjamin Herrenschmidt wrote: On Wed, 2014-10-15 at 16:19 -0600, Bjorn Helgaas wrote: PCI/MSI: Add device flag indicating that 64-bit MSIs don't work I'm still assuming you're going to merge this series, but I don't see it in your tree (https://git.kernel.org/cgit/linux/kernel/git/benh/powerpc.git/) yet. Do you want me to do anything with it? I'm doing the powerpc tree this cycle, so it'd be in my tree, but it's not: https://git.kernel.org/cgit/linux/kernel/git/mpe/linux.git/ Ben if you want me to take it let me know. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/mm: Use PAGE_FACTOR
PAGE_FACTOR was defined to reflect the difference between configured page size and fixed 4KB page size. Replace (PAGE_SHIFT - HW_PAGE_SHIFT) with PAGE_FACTOR. Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com --- arch/powerpc/mm/hash_low_64.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/mm/hash_low_64.S b/arch/powerpc/mm/hash_low_64.S index 057cbbb..5094f32 100644 --- a/arch/powerpc/mm/hash_low_64.S +++ b/arch/powerpc/mm/hash_low_64.S @@ -514,7 +514,7 @@ htab_insert_pte: andis. r0,r31,_PAGE_4K_PFN@h srdir5,r31,PTE_RPN_SHIFT bne-htab_special_pfn - sldir5,r5,PAGE_SHIFT-HW_PAGE_SHIFT + sldir5,r5,PAGE_FACTOR add r5,r5,r25 htab_special_pfn: sldir5,r5,HW_PAGE_SHIFT @@ -544,7 +544,7 @@ htab_call_hpte_insert1: andis. r0,r31,_PAGE_4K_PFN@h srdir5,r31,PTE_RPN_SHIFT bne-3f - sldir5,r5,PAGE_SHIFT-HW_PAGE_SHIFT + sldir5,r5,PAGE_FACTOR add r5,r5,r25 3: sldir5,r5,HW_PAGE_SHIFT -- 1.8.3.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/8] powerpc/powernv: PCI code cleanup
The patchset cleans up PowerNV PCI code. Also, the compound PEs are affected to each other with help of PELTV, which was missed from commit 262af557 (powerpc/powernv: Enable M64 aperatus for PHB3). Gavin Shan (8): powerpc/powernv: Check PHB type in advance powerpc/powernv: Fix condition to remove M64 powerpc/powernv: Rename alloc_m64_pe() to reserve_m64_pe() powerpc/powernv: Initialize M64 PE in time powerpc/powernv: Set PELTV for compound PEs powerpc/powernv: Simplify pnv_ioda_configure_pe() powerpc/powernv: Bail upon invalid master PE powerpc/powernv: Fix potential zero devisor arch/powerpc/platforms/powernv/pci-ioda.c | 205 +--- arch/powerpc/platforms/powernv/pci-p5ioc2.c | 28 ++-- arch/powerpc/platforms/powernv/pci.h| 2 +- 3 files changed, 172 insertions(+), 63 deletions(-) -- 1.8.3.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 8/8] powerpc/powernv: Fix potential zero devisor
If there're no PHBs under P5IOC2 HUB device tree node, we should
bail early to avoid zero devisor and allocating TCE tables.
Reported-by: Anton Blanchard an...@samba.org
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/pci-p5ioc2.c | 28
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-p5ioc2.c
b/arch/powerpc/platforms/powernv/pci-p5ioc2.c
index 94ce348..3336fcb 100644
--- a/arch/powerpc/platforms/powernv/pci-p5ioc2.c
+++ b/arch/powerpc/platforms/powernv/pci-p5ioc2.c
@@ -196,6 +196,22 @@ void __init pnv_pci_init_p5ioc2_hub(struct device_node *np)
hub_id = be64_to_cpup(prop64);
pr_info( HUB-ID : 0x%016llx\n, hub_id);
+ /* Count child PHBs and calculate TCE space per PHB */
+ for_each_child_of_node(np, phbn) {
+ if (of_device_is_compatible(phbn, ibm,p5ioc2-pcix) ||
+ of_device_is_compatible(phbn, ibm,p5ioc2-pciex))
+ phb_count++;
+ }
+
+ if (phb_count = 0) {
+ pr_info( No PHBs for Hub %s\n, np-full_name);
+ return;
+ }
+
+ tce_per_phb = __rounddown_pow_of_two(P5IOC2_TCE_MEMORY / phb_count);
+ pr_info( Allocating %lld MB of TCE memory per PHB\n,
+ tce_per_phb 20);
+
/* Currently allocate 16M of TCE memory for every Hub
*
* XXX TODO: Make it chip local if possible
@@ -215,18 +231,6 @@ void __init pnv_pci_init_p5ioc2_hub(struct device_node *np)
return;
}
- /* Count child PHBs */
- for_each_child_of_node(np, phbn) {
- if (of_device_is_compatible(phbn, ibm,p5ioc2-pcix) ||
- of_device_is_compatible(phbn, ibm,p5ioc2-pciex))
- phb_count++;
- }
-
- /* Calculate how much TCE space we can give per PHB */
- tce_per_phb = __rounddown_pow_of_two(P5IOC2_TCE_MEMORY / phb_count);
- pr_info( Allocating %lld MB of TCE memory per PHB\n,
- tce_per_phb 20);
-
/* Initialize PHBs */
for_each_child_of_node(np, phbn) {
if (of_device_is_compatible(phbn, ibm,p5ioc2-pcix) ||
--
1.8.3.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/8] powerpc/powernv: Rename alloc_m64_pe() to reserve_m64_pe()
The patch renames alloc_m64_pe() to reserve_m64_pe() to reflect
its real usage: We reserve PE numbers for M64 segments in advance
and then pick up the reserved PE numbers when building the mapping
between PE numbers and M64 segments.
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/pci-ioda.c | 8
arch/powerpc/platforms/powernv/pci.h | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 7aa0404..cf90cce 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -172,7 +172,7 @@ fail:
return -EIO;
}
-static void pnv_ioda2_alloc_m64_pe(struct pnv_phb *phb)
+static void pnv_ioda2_reserve_m64_pe(struct pnv_phb *phb)
{
resource_size_t sgsz = phb-ioda.m64_segsize;
struct pci_dev *pdev;
@@ -345,7 +345,7 @@ static void __init pnv_ioda_parse_m64_window(struct pnv_phb
*phb)
/* Use last M64 BAR to cover M64 window */
phb-ioda.m64_bar_idx = 15;
phb-init_m64 = pnv_ioda2_init_m64;
- phb-alloc_m64_pe = pnv_ioda2_alloc_m64_pe;
+ phb-reserve_m64_pe = pnv_ioda2_reserve_m64_pe;
phb-pick_m64_pe = pnv_ioda2_pick_m64_pe;
}
@@ -837,8 +837,8 @@ static void pnv_pci_ioda_setup_PEs(void)
phb = hose-private_data;
/* M64 layout might affect PE allocation */
- if (phb-alloc_m64_pe)
- phb-alloc_m64_pe(phb);
+ if (phb-reserve_m64_pe)
+ phb-reserve_m64_pe(phb);
pnv_ioda_setup_PEs(hose-bus);
}
diff --git a/arch/powerpc/platforms/powernv/pci.h
b/arch/powerpc/platforms/powernv/pci.h
index 34d29eb..6c02ff8 100644
--- a/arch/powerpc/platforms/powernv/pci.h
+++ b/arch/powerpc/platforms/powernv/pci.h
@@ -130,7 +130,7 @@ struct pnv_phb {
u32 (*bdfn_to_pe)(struct pnv_phb *phb, struct pci_bus *bus, u32 devfn);
void (*shutdown)(struct pnv_phb *phb);
int (*init_m64)(struct pnv_phb *phb);
- void (*alloc_m64_pe)(struct pnv_phb *phb);
+ void (*reserve_m64_pe)(struct pnv_phb *phb);
int (*pick_m64_pe)(struct pnv_phb *phb, struct pci_bus *bus, int all);
int (*get_pe_state)(struct pnv_phb *phb, int pe_no);
void (*freeze_pe)(struct pnv_phb *phb, int pe_no);
--
1.8.3.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 7/8] powerpc/powernv: Bail upon invalid master PE
When freezing compound PEs in pnv_ioda_freeze_pe(), we should bail
upon illegal master PE. We needn't freeze slave PE because it should
have been put into frozen state by hardware.
Reported-by: Anton Blanchard an...@samba.org
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/pci-ioda.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 762ca14..d035035 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -373,7 +373,9 @@ static void pnv_ioda_freeze_pe(struct pnv_phb *phb, int
pe_no)
/* Fetch master PE */
if (pe-flags PNV_IODA_PE_SLAVE) {
pe = pe-master;
- WARN_ON(!pe || !(pe-flags PNV_IODA_PE_MASTER));
+ if (WARN_ON(!pe || !(pe-flags PNV_IODA_PE_MASTER)))
+ return;
+
pe_no = pe-pe_number;
}
--
1.8.3.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/8] powerpc/powernv: Check PHB type in advance
The patch checks PHB type a bit early to save a bit cycles
for P7 because we don't support M64 for P7IOC no matter what
OPAL firmware we have.
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/pci-ioda.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 468a0f2..7ab1dd7 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -313,6 +313,12 @@ static void __init pnv_ioda_parse_m64_window(struct
pnv_phb *phb)
const u32 *r;
u64 pci_addr;
+ /* FIXME: Support M64 for P7IOC */
+ if (phb-type != PNV_PHB_IODA2) {
+ pr_info( Not support M64 window\n);
+ return;
+ }
+
if (!firmware_has_feature(FW_FEATURE_OPALv3)) {
pr_info( Firmware too old to support M64 window\n);
return;
@@ -325,12 +331,6 @@ static void __init pnv_ioda_parse_m64_window(struct
pnv_phb *phb)
return;
}
- /* FIXME: Support M64 for P7IOC */
- if (phb-type != PNV_PHB_IODA2) {
- pr_info( Not support M64 window\n);
- return;
- }
-
res = hose-mem_resources[1];
res-start = of_translate_address(dn, r + 2);
res-end = res-start + of_read_number(r + 4, 2) - 1;
--
1.8.3.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/8] powerpc/powernv: Initialize M64 PE in time
The patch initializes PE instance when reserving PE number to
keep consistent things as we did before. Also, it replaces the
iteration on bridge's windows with the prefered way.
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/pci-ioda.c | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index cf90cce..7a7a688 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -91,6 +91,24 @@ static inline bool pnv_pci_is_mem_pref_64(unsigned long
flags)
(IORESOURCE_MEM_64 | IORESOURCE_PREFETCH));
}
+static void pnv_ioda_reserve_pe(struct pnv_phb *phb, int pe_no)
+{
+ if (!(pe_no = 0 pe_no phb-ioda.total_pe)) {
+ pr_warn(%s: Invalid PE %d on PHB#%x\n,
+ __func__, pe_no, phb-hose-global_number);
+ return;
+ }
+
+ if (test_and_set_bit(pe_no, phb-ioda.pe_alloc)) {
+ pr_warn(%s: PE %d was assigned on PHB#%x\n,
+ __func__, pe_no, phb-hose-global_number);
+ return;
+ }
+
+ phb-ioda.pe_array[pe_no].phb = phb;
+ phb-ioda.pe_array[pe_no].pe_number = pe_no;
+}
+
static int pnv_ioda_alloc_pe(struct pnv_phb *phb)
{
unsigned long pe;
@@ -185,16 +203,15 @@ static void pnv_ioda2_reserve_m64_pe(struct pnv_phb *phb)
* instead of root bus.
*/
list_for_each_entry(pdev, phb-hose-bus-devices, bus_list) {
- for (i = PCI_BRIDGE_RESOURCES;
-i = PCI_BRIDGE_RESOURCE_END; i++) {
- r = pdev-resource[i];
+ for (i = 0; i PCI_BRIDGE_RESOURCE_NUM; i++) {
+ r = pdev-resource[PCI_BRIDGE_RESOURCES + i];
if (!r-parent ||
!pnv_pci_is_mem_pref_64(r-flags))
continue;
base = (r-start - phb-ioda.m64_base) / sgsz;
for (step = 0; step resource_size(r) / sgsz; step++)
- set_bit(base + step, phb-ioda.pe_alloc);
+ pnv_ioda_reserve_pe(phb, base + step);
}
}
}
@@ -287,8 +304,6 @@ done:
while ((i = find_next_bit(pe_alloc, phb-ioda.total_pe, i + 1))
phb-ioda.total_pe) {
pe = phb-ioda.pe_array[i];
- pe-phb = phb;
- pe-pe_number = i;
if (!master_pe) {
pe-flags |= PNV_IODA_PE_MASTER;
--
1.8.3.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 5/8] powerpc/powernv: Set PELTV for compound PEs
Commit 262af55 (powerpc/powernv: Enable M64 aperatus for PHB3)
introduced compound PEs in order to support M64 aperatus on PHB3.
However, we never configured PELTV for compound PEs. The patch
fixes that by: parent PE can freeze all child compound PEs. Any
compound PE affects the group.
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/pci-ioda.c | 118 ++
1 file changed, 102 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 7a7a688..b96ba48 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -522,6 +522,106 @@ static struct pnv_ioda_pe *pnv_ioda_get_pe(struct pci_dev
*dev)
}
#endif /* CONFIG_PCI_MSI */
+static int pnv_ioda_set_one_peltv(struct pnv_phb *phb,
+ struct pnv_ioda_pe *parent,
+ struct pnv_ioda_pe *child,
+ bool is_add)
+{
+ const char *desc = is_add ? adding : removing;
+ uint8_t op = is_add ? OPAL_ADD_PE_TO_DOMAIN :
+ OPAL_REMOVE_PE_FROM_DOMAIN;
+ struct pnv_ioda_pe *slave;
+ long rc;
+
+ /* Parent PE affects child PE */
+ rc = opal_pci_set_peltv(phb-opal_id, parent-pe_number,
+ child-pe_number, op);
+ if (rc != OPAL_SUCCESS) {
+ pe_warn(child, OPAL error %ld %s to parent PELTV\n,
+ rc, desc);
+ return -ENXIO;
+ }
+
+ if (!(child-flags PNV_IODA_PE_MASTER))
+ return 0;
+
+ /* Compound case: parent PE affects slave PEs */
+ list_for_each_entry(slave, child-slaves, list) {
+ rc = opal_pci_set_peltv(phb-opal_id, parent-pe_number,
+ slave-pe_number, op);
+ if (rc != OPAL_SUCCESS) {
+ pe_warn(slave, OPAL error %ld %s to parent PELTV\n,
+ rc, desc);
+ return -ENXIO;
+ }
+ }
+
+ return 0;
+}
+
+static int pnv_ioda_set_peltv(struct pnv_phb *phb,
+ struct pnv_ioda_pe *pe,
+ bool is_add)
+{
+ struct pnv_ioda_pe *slave;
+ struct pci_dev *pdev;
+ int ret;
+
+ /*
+* Clear PE frozen state. If it's master PE, we need
+* clear slave PE frozen state as well.
+*/
+ if (is_add) {
+ opal_pci_eeh_freeze_clear(phb-opal_id, pe-pe_number,
+ OPAL_EEH_ACTION_CLEAR_FREEZE_ALL);
+ if (pe-flags PNV_IODA_PE_MASTER) {
+ list_for_each_entry(slave, pe-slaves, list)
+ opal_pci_eeh_freeze_clear(phb-opal_id,
+ slave-pe_number,
+
OPAL_EEH_ACTION_CLEAR_FREEZE_ALL);
+ }
+ }
+
+ /*
+* Associate PE in PELT. We need add the PE into the
+* corresponding PELT-V as well. Otherwise, the error
+* originated from the PE might contribute to other
+* PEs.
+*/
+ ret = pnv_ioda_set_one_peltv(phb, pe, pe, is_add);
+ if (ret)
+ return ret;
+
+ /* For compound PEs, any one affects all of them */
+ if (pe-flags PNV_IODA_PE_MASTER) {
+ list_for_each_entry(slave, pe-slaves, list) {
+ ret = pnv_ioda_set_one_peltv(phb, slave, pe, is_add);
+ if (ret)
+ return ret;
+ }
+ }
+
+ if (pe-flags (PNV_IODA_PE_BUS_ALL | PNV_IODA_PE_BUS))
+ pdev = pe-pbus-self;
+ else
+ pdev = pe-pdev-bus-self;
+ while (pdev) {
+ struct pci_dn *pdn = pci_get_pdn(pdev);
+ struct pnv_ioda_pe *parent;
+
+ if (pdn pdn-pe_number != IODA_INVALID_PE) {
+ parent = phb-ioda.pe_array[pdn-pe_number];
+ ret = pnv_ioda_set_one_peltv(phb, parent, pe, is_add);
+ if (ret)
+ return ret;
+ }
+
+ pdev = pdev-bus-self;
+ }
+
+ return 0;
+}
+
static int pnv_ioda_configure_pe(struct pnv_phb *phb, struct pnv_ioda_pe *pe)
{
struct pci_dev *parent;
@@ -576,23 +676,9 @@ static int pnv_ioda_configure_pe(struct pnv_phb *phb,
struct pnv_ioda_pe *pe)
return -ENXIO;
}
- rc = opal_pci_set_peltv(phb-opal_id, pe-pe_number,
- pe-pe_number, OPAL_ADD_PE_TO_DOMAIN);
- if (rc)
- pe_warn(pe, OPAL error %d adding self to PELTV\n, rc);
- opal_pci_eeh_freeze_clear(phb-opal_id, pe-pe_number,
-
[PATCH 6/8] powerpc/powernv: Simplify pnv_ioda_configure_pe()
Nested if statements are always bad and the patch avoids one by
checking PHB type and bail in advance if necessary.
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/pci-ioda.c | 32 ---
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index b96ba48..762ca14 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -684,26 +684,28 @@ static int pnv_ioda_configure_pe(struct pnv_phb *phb,
struct pnv_ioda_pe *pe)
phb-ioda.pe_rmap[rid] = pe-pe_number;
/* Setup one MVTs on IODA1 */
- if (phb-type == PNV_PHB_IODA1) {
- pe-mve_number = pe-pe_number;
- rc = opal_pci_set_mve(phb-opal_id, pe-mve_number,
- pe-pe_number);
+ if (phb-type != PNV_PHB_IODA1) {
+ pe-mve_number = 0;
+ goto out;
+ }
+
+ pe-mve_number = pe-pe_number;
+ rc = opal_pci_set_mve(phb-opal_id, pe-mve_number, pe-pe_number);
+ if (rc != OPAL_SUCCESS) {
+ pe_err(pe, OPAL error %ld setting up MVE %d\n,
+ rc, pe-mve_number);
+ pe-mve_number = -1;
+ } else {
+ rc = opal_pci_set_mve_enable(phb-opal_id,
+pe-mve_number, OPAL_ENABLE_MVE);
if (rc) {
- pe_err(pe, OPAL error %ld setting up MVE %d\n,
+ pe_err(pe, OPAL error %ld enabling MVE %d\n,
rc, pe-mve_number);
pe-mve_number = -1;
- } else {
- rc = opal_pci_set_mve_enable(phb-opal_id,
-pe-mve_number,
OPAL_ENABLE_MVE);
- if (rc) {
- pe_err(pe, OPAL error %ld enabling MVE %d\n,
- rc, pe-mve_number);
- pe-mve_number = -1;
- }
}
- } else if (phb-type == PNV_PHB_IODA2)
- pe-mve_number = 0;
+ }
+out:
return 0;
}
--
1.8.3.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4] QE: Move QE from arch/powerpc to drivers/soc
ls1 has qe and ls1 has arm cpu.
move qe from arch/powerpc to drivers/soc/fsl
to adapt to powerpc and arm
Signed-off-by: Zhao Qiang b45...@freescale.com
---
Changes for v2:
- move code to driver/soc
Changes for v3:
- change drivers/soc/qe to drivers/soc/fsl-qe
Changes for v4:
- move drivers/soc/fsl-qe to drivers/soc/fsl/qe
- move head files for qe from include/linux/fsl to include/soc/fsl
- move qe_ic.c to drivers/irqchip/
arch/powerpc/platforms/83xx/km83xx.c | 4 +--
arch/powerpc/platforms/83xx/misc.c | 2 +-
arch/powerpc/platforms/83xx/mpc832x_mds.c | 4 +--
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 4 +--
arch/powerpc/platforms/83xx/mpc836x_mds.c | 4 +--
arch/powerpc/platforms/83xx/mpc836x_rdk.c | 4 +--
arch/powerpc/platforms/85xx/common.c | 2 +-
arch/powerpc/platforms/85xx/corenet_generic.c | 2 +-
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 4 +--
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 4 +--
arch/powerpc/platforms/85xx/twr_p102x.c| 4 +--
arch/powerpc/platforms/Kconfig | 19 -
arch/powerpc/sysdev/qe_lib/Kconfig | 23 +---
arch/powerpc/sysdev/qe_lib/Makefile| 10 +++
arch/powerpc/sysdev/qe_lib/gpio.c | 2 +-
arch/powerpc/sysdev/qe_lib/qe_io.c | 2 +-
arch/powerpc/sysdev/qe_lib/usb.c | 4 +--
drivers/irqchip/Makefile | 1 +
.../sysdev/qe_lib = drivers/irqchip}/qe_ic.c | 2 +-
.../sysdev/qe_lib = drivers/irqchip}/qe_ic.h | 2 +-
drivers/net/ethernet/freescale/fsl_pq_mdio.c | 2 +-
drivers/net/ethernet/freescale/ucc_geth.c | 8 +++---
drivers/net/ethernet/freescale/ucc_geth.h | 8 +++---
drivers/soc/Kconfig| 2 ++
drivers/soc/Makefile | 1 +
drivers/soc/fsl/Makefile | 5
drivers/soc/fsl/qe/Kconfig | 31 ++
drivers/soc/fsl/qe/Makefile| 8 ++
.../sysdev/qe_lib = drivers/soc/fsl/qe}/qe.c | 4 +--
.../sysdev/qe_lib = drivers/soc/fsl/qe}/ucc.c | 6 ++---
.../qe_lib = drivers/soc/fsl/qe}/ucc_fast.c | 8 +++---
.../qe_lib = drivers/soc/fsl/qe}/ucc_slow.c | 8 +++---
drivers/spi/spi-fsl-cpm.c | 2 +-
drivers/tty/serial/ucc_uart.c | 2 +-
drivers/usb/gadget/fsl_qe_udc.c| 2 +-
drivers/usb/host/fhci-hcd.c| 2 +-
drivers/usb/host/fhci-hub.c| 2 +-
drivers/usb/host/fhci-sched.c | 2 +-
drivers/usb/host/fhci.h| 4 +--
.../include/asm = include/linux/fsl}/qe_ic.h | 0
.../include/asm = include/soc/fsl}/immap_qe.h | 0
{arch/powerpc/include/asm = include/soc/fsl}/qe.h | 2 +-
.../powerpc/include/asm = include/soc/fsl}/ucc.h | 4 +--
.../include/asm = include/soc/fsl}/ucc_fast.h | 6 ++---
.../include/asm = include/soc/fsl}/ucc_slow.h | 6 ++---
45 files changed, 121 insertions(+), 107 deletions(-)
rename {arch/powerpc/sysdev/qe_lib = drivers/irqchip}/qe_ic.c (99%)
rename {arch/powerpc/sysdev/qe_lib = drivers/irqchip}/qe_ic.h (98%)
create mode 100644 drivers/soc/fsl/Makefile
create mode 100644 drivers/soc/fsl/qe/Kconfig
create mode 100644 drivers/soc/fsl/qe/Makefile
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl/qe}/qe.c (99%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl/qe}/ucc.c (98%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl/qe}/ucc_fast.c (99%)
rename {arch/powerpc/sysdev/qe_lib = drivers/soc/fsl/qe}/ucc_slow.c (98%)
rename {arch/powerpc/include/asm = include/linux/fsl}/qe_ic.h (100%)
rename {arch/powerpc/include/asm = include/soc/fsl}/immap_qe.h (100%)
rename {arch/powerpc/include/asm = include/soc/fsl}/qe.h (99%)
rename {arch/powerpc/include/asm = include/soc/fsl}/ucc.h (96%)
rename {arch/powerpc/include/asm = include/soc/fsl}/ucc_fast.h (98%)
rename {arch/powerpc/include/asm = include/soc/fsl}/ucc_slow.h (99%)
diff --git a/arch/powerpc/platforms/83xx/km83xx.c
b/arch/powerpc/platforms/83xx/km83xx.c
index bf4c447..11c386bb2 100644
--- a/arch/powerpc/platforms/83xx/km83xx.c
+++ b/arch/powerpc/platforms/83xx/km83xx.c
@@ -37,8 +37,8 @@
#include asm/udbg.h
#include sysdev/fsl_soc.h
#include sysdev/fsl_pci.h
-#include asm/qe.h
-#include asm/qe_ic.h
+#include soc/fsl/qe.h
+#include linux/fsl/qe_ic.h
#include mpc83xx.h
diff --git a/arch/powerpc/platforms/83xx/misc.c
b/arch/powerpc/platforms/83xx/misc.c
index 125336f..3e2e6d2 100644
--- a/arch/powerpc/platforms/83xx/misc.c
+++ b/arch/powerpc/platforms/83xx/misc.c
@@ -17,7 +17,7 @@
#include asm/io.h
#include asm/hw_irq.h
#include asm/ipic.h
-#include asm/qe_ic.h
Re: [PATCH] cpufreq: qoriq: Make the driver usable on all QorIQ platforms
On 12 November 2014 00:39, Scott Wood scottw...@freescale.com wrote: What purpose do those arch CPU frequency scaling drivers submenus serve, versus just including the options in the main cpufreq menu? It's not as if more than one arch would be visible at once (and when a situation with multiple visible menus popped up, it was considered a bug). Oh, that really looks fine to me. I will send it formally as well: diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig index 3489f8f..a24d678 100644 --- a/drivers/cpufreq/Kconfig +++ b/drivers/cpufreq/Kconfig @@ -196,19 +196,19 @@ config CPUFREQ_DT If in doubt, say N. -menu x86 CPU frequency scaling drivers -depends on X86 +if X86 source drivers/cpufreq/Kconfig.x86 -endmenu +endif -menu ARM CPU frequency scaling drivers -depends on ARM || ARM64 +if ARM || ARM64 source drivers/cpufreq/Kconfig.arm -endmenu +endif -menu AVR32 CPU frequency scaling drivers -depends on AVR32 +if PPC32 || PPC64 +source drivers/cpufreq/Kconfig.powerpc +endif +if AVR32 config AVR32_AT32AP_CPUFREQ bool CPU frequency driver for AT32AP depends on PLATFORM_AT32AP @@ -216,12 +216,9 @@ config AVR32_AT32AP_CPUFREQ help This enables the CPU frequency driver for AT32AP processors. If in doubt, say N. +endif -endmenu - -menu CPUFreq processor drivers -depends on IA64 - +if IA64 config IA64_ACPI_CPUFREQ tristate ACPI Processor P-States driver depends on ACPI_PROCESSOR @@ -232,12 +229,9 @@ config IA64_ACPI_CPUFREQ For details, take a look at file:Documentation/cpu-freq/. If in doubt, say N. +endif -endmenu - -menu MIPS CPUFreq processor drivers -depends on MIPS - +if MIPS config LOONGSON2_CPUFREQ tristate Loongson2 CPUFreq Driver help @@ -249,16 +243,9 @@ config LOONGSON2_CPUFREQ For details, take a look at file:Documentation/cpu-freq/. If in doubt, say N. +endif -endmenu - -menu PowerPC CPU frequency scaling drivers -depends on PPC32 || PPC64 -source drivers/cpufreq/Kconfig.powerpc -endmenu - -menu SPARC CPU frequency scaling drivers -depends on SPARC64 +if SPARC64 config SPARC_US3_CPUFREQ tristate UltraSPARC-III CPU Frequency driver help @@ -276,10 +263,9 @@ config SPARC_US2E_CPUFREQ For details, take a look at file:Documentation/cpu-freq. If in doubt, say N. -endmenu +endif -menu SH CPU Frequency scaling -depends on SUPERH +if SUPERH config SH_CPU_FREQ tristate SuperH CPU Frequency driver help @@ -293,7 +279,7 @@ config SH_CPU_FREQ For details, take a look at file:Documentation/cpu-freq. If unsure, say N. -endmenu +endif endif endmenu ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 4/7] sound/radeon: Add quirk for broken 64-bit MSI
On Wed, 2014-11-12 at 13:23 +1100, Michael Ellerman wrote: On Tue, 2014-11-11 at 14:12 -0700, Bjorn Helgaas wrote: On Thu, Oct 16, 2014 at 09:55:32AM +1100, Benjamin Herrenschmidt wrote: On Wed, 2014-10-15 at 16:19 -0600, Bjorn Helgaas wrote: PCI/MSI: Add device flag indicating that 64-bit MSIs don't work I'm still assuming you're going to merge this series, but I don't see it in your tree (https://git.kernel.org/cgit/linux/kernel/git/benh/powerpc.git/) yet. Do you want me to do anything with it? I'm doing the powerpc tree this cycle, so it'd be in my tree, but it's not: https://git.kernel.org/cgit/linux/kernel/git/mpe/linux.git/ Ben if you want me to take it let me know. Hrm, I might have dropped the ball accidentally here. Bjorn did you actually Ack the core changes ? In that case we should probably pick it up. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 4/7] sound/radeon: Add quirk for broken 64-bit MSI
On Tue, Nov 11, 2014 at 9:06 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Wed, 2014-11-12 at 13:23 +1100, Michael Ellerman wrote: On Tue, 2014-11-11 at 14:12 -0700, Bjorn Helgaas wrote: On Thu, Oct 16, 2014 at 09:55:32AM +1100, Benjamin Herrenschmidt wrote: On Wed, 2014-10-15 at 16:19 -0600, Bjorn Helgaas wrote: PCI/MSI: Add device flag indicating that 64-bit MSIs don't work I'm still assuming you're going to merge this series, but I don't see it in your tree (https://git.kernel.org/cgit/linux/kernel/git/benh/powerpc.git/) yet. Do you want me to do anything with it? I'm doing the powerpc tree this cycle, so it'd be in my tree, but it's not: https://git.kernel.org/cgit/linux/kernel/git/mpe/linux.git/ Ben if you want me to take it let me know. Hrm, I might have dropped the ball accidentally here. Bjorn did you actually Ack the core changes ? In that case we should probably pick it up. Yep, I acked it earlier in this thread (Oct 15). Bjorn ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2] powerpc/TM: Disable/Enable TM looking at the ibm, pa-features device tree entry
Michael Neuling mi...@neuling.org writes:
On Sun, 2014-11-02 at 20:02 +0530, Aneesh Kumar K.V wrote:
Runtime disable transactional memory feature looking at pa-features
device tree entry. We need to do this so that we can run a kernel
built with TM config in PR mode.
I'm happy to turn this off but why do we need to do this in PR mode?
Can you explain this in the commit message.
Hmm, that commit message needs an update. I initially did the patch for
P8 PR support and wanted a mechanism to disable TM. Alex added basic TM
support for PR mode after that. So we can drop the PR part of the
commit message.
Michael Ellerman,
Let me know if you want me to send an updated version with the those
part of the commit message dropped
For PR guest we provide a device
tree entry with TM feature disabled in pa-features
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
Changes from V1:
* rebase to latest linus
arch/powerpc/kernel/prom.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 099f27e6d1b0..3e22930f15d1 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -160,6 +160,11 @@ static struct ibm_pa_feature {
{CPU_FTR_NODSISRALIGN, 0, 0,1, 1, 1},
{0, MMU_FTR_CI_LARGE_PAGE, 0, 1, 2, 0},
{CPU_FTR_REAL_LE, PPC_FEATURE_TRUE_LE, 5, 0, 0},
+/*
+ * We should use CPU_FTR_TM_COMP so that if we disable TM, it won't get
+ * enabled via device tree
+ */
+{CPU_FTR_TM_COMP, 0, 0, 22, 0, 0},
};
static void __init scan_features(unsigned long node, const unsigned char
*ftrs,
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] of/base: Fix PowerPC address parsing hack
We have a historical hack that treats missing ranges properties as the
equivalent of an empty one. This is needed for ancient PowerMac bad
device-trees, and shouldn't be enabled for any other PowerPC platform,
otherwise we get some nasty layout of devices in sysfs or even
duplication when a set of otherwise identically named devices is
created multiple times under a different parent node with no ranges
property.
This fix is needed for the PowerNV i2c busses to be exposed properly
and will fix a number of other embedded cases.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
CC: sta...@vger.kernel.org
---
diff --git a/drivers/of/address.c b/drivers/of/address.c
index e371825..e37f017 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -7,6 +7,10 @@
#include linux/pci_regs.h
#include linux/string.h
+#ifdef CONFIG_PPC
+#include asm/machdep.h
+#endif
+
/* Max address size we deal with */
#define OF_MAX_ADDR_CELLS 4
#define OF_CHECK_ADDR_COUNT(na)((na) 0 (na) = OF_MAX_ADDR_CELLS)
@@ -428,12 +432,13 @@ static int of_translate_one(struct device_node *parent,
struct of_bus *bus,
* This code is only enabled on powerpc. --gcl
*/
ranges = of_get_property(parent, rprop, rlen);
-#if !defined(CONFIG_PPC)
+#if defined(CONFIG_PPC)
+ if (!machine_is(powermac))
+#endif /* defined(CONFIG_PPC) */
if (ranges == NULL) {
- pr_err(OF: no ranges; cannot translate\n);
+ pr_debug(OF: no ranges; cannot translate\n);
return 1;
}
-#endif /* !defined(CONFIG_PPC) */
if (ranges == NULL || rlen == 0) {
offset = of_read_number(addr, na);
memset(addr, 0, pna * 4);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/powernv: Support OPAL requested heartbeat
If OPAL requests it, call it back via opal_poll_events() at a
regular interval. Some versions of OPAL on some machines require
this to operate some internal timeouts properly.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/platforms/powernv/opal.c | 64 ++-
1 file changed, 55 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/opal.c
b/arch/powerpc/platforms/powernv/opal.c
index f1e0d8c..0153064 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -22,6 +22,8 @@
#include linux/kobject.h
#include linux/delay.h
#include linux/memblock.h
+#include linux/kthread.h
+#include linux/freezer.h
#include asm/machdep.h
#include asm/opal.h
@@ -58,6 +60,7 @@ static struct atomic_notifier_head
opal_msg_notifier_head[OPAL_MSG_TYPE_MAX];
static DEFINE_SPINLOCK(opal_notifier_lock);
static uint64_t last_notified_mask = 0x0ul;
static atomic_t opal_notifier_hold = ATOMIC_INIT(0);
+static uint32_t opal_heartbeat;
static void opal_reinit_cores(void)
{
@@ -633,17 +636,9 @@ static void opal_ipmi_init(struct device_node *opal_node)
of_platform_device_create(np, NULL, NULL);
}
-static int __init opal_init(void)
+static void opal_console_create_devs(void)
{
struct device_node *np, *consoles;
- const __be32 *irqs;
- int rc, i, irqlen;
-
- opal_node = of_find_node_by_path(/ibm,opal);
- if (!opal_node) {
- pr_warn(opal: Node not found\n);
- return -ENODEV;
- }
/* Register OPAL consoles if any ports */
if (firmware_has_feature(FW_FEATURE_OPALv2))
@@ -659,6 +654,13 @@ static int __init opal_init(void)
of_node_put(consoles);
}
+}
+
+static void opal_request_interrupts(void)
+{
+ const __be32 *irqs;
+ int rc, i, irqlen;
+
/* Find all OPAL interrupts and request them */
irqs = of_get_property(opal_node, opal-interrupts, irqlen);
pr_debug(opal: Found %d interrupts reserved for OPAL\n,
@@ -678,6 +680,49 @@ static int __init opal_init(void)
(0x%x)\n, rc, irq, hwirq);
opal_irqs[i] = irq;
}
+}
+
+static int kopald(void *unused)
+{
+ set_freezable();
+ do {
+ try_to_freeze();
+ opal_poll_events(NULL);
+ msleep_interruptible(opal_heartbeat);
+ } while (!kthread_should_stop());
+
+ return 0;
+}
+
+static void opal_init_heartbeat(void)
+{
+ /* Old firwmware, we assume the HVC heartbeat is sufficient */
+ if (of_property_read_u32(opal_node, ibm,heartbeat-freq,
+opal_heartbeat) != 0)
+ opal_heartbeat = 0;
+
+ if (opal_heartbeat)
+ kthread_run(kopald, NULL, kopald);
+}
+
+static int __init opal_init(void)
+{
+ int rc;
+
+ opal_node = of_find_node_by_path(/ibm,opal);
+ if (!opal_node) {
+ pr_warn(opal: Node not found\n);
+ return -ENODEV;
+ }
+
+ /* Setup a heatbeat thread if requested by OPAL */
+ opal_init_heartbeat();
+
+ /* Create console platform devices */
+ opal_console_create_devs();
+
+ /* Register OPAL interrupts */
+ opal_request_interrupts();
/* Create opal kobject under /sys/firmware */
rc = opal_sysfs_init();
@@ -696,6 +741,7 @@ static int __init opal_init(void)
opal_msglog_init();
}
+ /* Initialize OPAL IPMI backend */
opal_ipmi_init(opal_node);
return 0;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/2] Add IPMI support for powernv powerpc machines
On Thu, 2014-11-06 at 08:15 -0600, Corey Minyard wrote: On 11/05/2014 09:38 PM, Jeremy Kerr wrote: Corey Michael: if this is acceptable, it may be mergable as two separate patches - one for the IPMI subsystem, one for the powernv platform. However, we'd need to preserve their order: patch 2/2 depends on 1/2, which provides the structure function definitions. This'll break the build if only 2/2 is in the tree, and CONFIG_IPMI_POWERNV is set. Alternatively, they could be merged by one maintainer, pending an ack from the other. I'm fine either way. How about the third option? :) I've put patch 1 in a topic branch: https://git.kernel.org/cgit/linux/kernel/git/mpe/linux.git/log/?h=topic/opal-ipmi And will merge that into my next, probably by tomorrow. If you merge the topic branch and then apply patch 2/2, then it should all go in without any hiccups. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4] powernv: cpuidle: Redesign idle states management
Hi Shreyas,
On 11/03/2014 09:38 PM, Shreyas B. Prabhu wrote:
diff --git a/arch/powerpc/kernel/idle_power7.S
b/arch/powerpc/kernel/idle_power7.S
index 283c603..df11acb 100644
--- a/arch/powerpc/kernel/idle_power7.S
+++ b/arch/powerpc/kernel/idle_power7.S
_GLOBAL(power7_idle)
/* Now check if user or arch enabled NAP mode */
@@ -141,49 +192,16 @@ _GLOBAL(power7_idle)
_GLOBAL(power7_nap)
mr r4,r3
- li r3,0
+ li r3,1
The comment at the top of this file states 0 for nap and 1 for sleep.
You will need to change that. As an alternative I would suggest using
the macros that you have already defined:PNV_THREAD_NAP and
PNV_THREAD_SLEEP to write to r3 above and remove the lines that say 0
for nap and 1 for sleep in the comments.
b power7_powersave_common
/* No return */
snip
@@ -210,12 +226,91 @@ _GLOBAL(power7_wakeup_tb_loss)
BEGIN_FTR_SECTION
CHECK_HMI_INTERRUPT
END_FTR_SECTION_IFSET(CPU_FTR_HVMODE)
+
+ li r7,1
+ mfspr r8,SPRN_PIR
+ /*
+ * The last 3 bits of PIR represents the thread id of a cpu
+ * in power8. This will need adjusting for power7.
+ */
+ andi. r8,r8,0x07 /* Get thread id into r8 */
+ rotld r7,r7,r8
+ /* r7 now has 'thread_id'th bit set */
+
+ ld r14,PACA_CORE_IDLE_STATE_PTR(r13)
+lwarx_loop2:
+ lwarx r15,0,r14
+ andi. r9,r15,PNV_CORE_IDLE_LOCK_BIT
+ /*
+ * Lock bit is set in one of the 2 cases-
+ * a. In the sleep/winkle enter path, the last thread is executing
+ * fastsleep workaround code.
+ * b. In the wake up path, another thread is executing fastsleep
+ * workaround undo code or resyncing timebase or restoring context
+ * In either case loop until the lock bit is cleared.
+ */
+ bne lwarx_loop2
+
+ cmpwi cr2,r15,0
+ or r15,r15,r7 /* Set thread bit */
+
+ beq cr2,first_thread
+
+ /* Not first thread in core to wake up */
+ stwcx. r15,0,r14
+ bne-lwarx_loop2
+ b common_exit
+
+first_thread:
+ /* First thread in core to wakeup */
+ ori r15,r15,PNV_CORE_IDLE_LOCK_BIT
+ stwcx. r15,0,r14
+ bne-lwarx_loop2
+
+ LOAD_REG_ADDR(r3, pnv_need_fastsleep_workaround)
+ lbz r3,0(r3)
+ cmpwi r3,1
+ /* skip fastsleep workaround if its not needed */
+ bne timebase_resync
+
+ /* Undo fast sleep workaround */
+ mfcrr16 /* Backup CR into a non-volatile register */
Don't you want to do this ^^ before calling opal_call_realmode for
timebase resync below also?
+ li r3,1
+ li r4,0
+ li r0,OPAL_CONFIG_CPU_IDLE_STATE
+ bl opal_call_realmode
+ mtcrr16 /* Restore CR */
+
+ /* Do timebase resync if we are waking up from sleep. Use cr1 value
+ * set in exceptions-64s.S */
+ ble cr1,clear_lock
+
+timebase_resync:
/* Time base re-sync */
- li r3,OPAL_RESYNC_TIMEBASE
+ li r0,OPAL_RESYNC_TIMEBASE
bl opal_call_realmode;
-
diff --git a/arch/powerpc/platforms/powernv/setup.c
b/arch/powerpc/platforms/powernv/setup.c
index 34c6665..980c964 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -36,6 +36,8 @@
#include asm/opal.h
#include asm/kexec.h
#include asm/smp.h
+#include asm/cputhreads.h
+#include asm/cpuidle.h
#include powernv.h
@@ -292,11 +294,55 @@ static void __init pnv_setup_machdep_rtas(void)
static u32 supported_cpuidle_states;
+static void pnv_alloc_idle_core_states(void)
+{
+ int i, j;
+ int nr_cores = cpu_nr_cores();
+ u32 *core_idle_state;
+
+ /*
+ * Deep idle states like sleep and winkle are per core idle states.
+ * A core enters these states only when all the threads enter either
+ * the particular idle state or a deeper one. There are tasks like
+ * fastsleep hardware bug workaround and hypervisor core state save
+ * which have to be done only by the last thread of the core entering
+ * deep idle state and similarly tasks like timebase resync, hypervisor
+ * core register restore that have to be done only by the first thread
+ * waking up from these states. Introducing core_idle_state, a per core
+ * structure which will keep track threads entering idle states deeper
+ * than sleep.
Since you already have explained ^^ in the changelog, you do not need to
elaborate it here.
+ * core_idle_state - First 8 bits track the idle state of each thread
+ * of the core. The 8th bit is the lock bit. Initially all thread bits
+ * are set. They are cleared when the thread enters deep idle state
+ * like sleep and winkle. Initially the lock bit is cleared.
you can simply have the comment about the bits of core_idle_state
without
Re: [PATCH 0/2] Add IPMI support for powernv powerpc machines
Hi Corey, Alternatively, they could be merged by one maintainer, pending an ack from the other. I'm fine either way. How about the third option? :) I've put patch 1 in a topic branch: https://git.kernel.org/cgit/linux/kernel/git/mpe/linux.git/log/?h=topic/opal-ipmi And will merge that into my next, probably by tomorrow. If you merge the topic branch and then apply patch 2/2, then it should all go in without any hiccups. OK, and I have an updated IPMI driver patch (ie, 2/2) that will apply on top of the new ipmi/for-next tree (best done after that merge). Patch coming shortly... Cheers, Jeremy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] drivers/char/ipmi: Add powernv IPMI driver
This change adds an initial IPMI driver for powerpc OPAL firmware. The
interface is exposed entirely through firmware: we have two functions to
send and receive IPMI messages, and an interrupt notification from the
firmware to signify that a message is available.
Signed-off-by: Jeremy Kerr j...@ozlabs.org
---
v2: Update for ipmi/for-next tree, add copyright header
---
drivers/char/ipmi/Kconfig|6
drivers/char/ipmi/Makefile |1
drivers/char/ipmi/ipmi_powernv.c | 307 +++
3 files changed, 314 insertions(+)
diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig
index c1fccf4..65fb008 100644
--- a/drivers/char/ipmi/Kconfig
+++ b/drivers/char/ipmi/Kconfig
@@ -72,6 +72,12 @@ config IPMI_SSIF
have a driver that must be accessed over an I2C bus instead of a
standard interface. This module requires I2C support.
+config IPMI_POWERNV
+ depends on PPC_POWERNV
+ tristate 'POWERNV (OPAL firmware) IPMI interface'
+ help
+ Provides a driver for OPAL firmware-based IPMI interfaces.
+
config IPMI_WATCHDOG
tristate 'IPMI Watchdog Timer'
help
diff --git a/drivers/char/ipmi/Makefile b/drivers/char/ipmi/Makefile
index 115c08d..f3ffde1 100644
--- a/drivers/char/ipmi/Makefile
+++ b/drivers/char/ipmi/Makefile
@@ -8,5 +8,6 @@ obj-$(CONFIG_IPMI_HANDLER) += ipmi_msghandler.o
obj-$(CONFIG_IPMI_DEVICE_INTERFACE) += ipmi_devintf.o
obj-$(CONFIG_IPMI_SI) += ipmi_si.o
obj-$(CONFIG_IPMI_SSIF) += ipmi_ssif.o
+obj-$(CONFIG_IPMI_POWERNV) += ipmi_powernv.o
obj-$(CONFIG_IPMI_WATCHDOG) += ipmi_watchdog.o
obj-$(CONFIG_IPMI_POWEROFF) += ipmi_poweroff.o
diff --git a/drivers/char/ipmi/ipmi_powernv.c b/drivers/char/ipmi/ipmi_powernv.c
new file mode 100644
index 000..50134ec
--- /dev/null
+++ b/drivers/char/ipmi/ipmi_powernv.c
@@ -0,0 +1,307 @@
+/*
+ * PowerNV OPAL IPMI driver
+ *
+ * Copyright 2014 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.
+ */
+
+#define pr_fmt(fmt)ipmi-powernv: fmt
+
+#include linux/ipmi_smi.h
+#include linux/list.h
+#include linux/module.h
+#include linux/of.h
+
+#include asm/opal.h
+
+
+struct ipmi_smi_powernv {
+ u64 interface_id;
+ struct ipmi_device_id ipmi_id;
+ ipmi_smi_t intf;
+ u64 event;
+ struct notifier_block event_nb;
+
+ /**
+* We assume that there can only be one outstanding request, so
+* keep the pending message in cur_msg. We protect this from concurrent
+* updates through send recv calls, (and consequently opal_msg, which
+* is in-use when cur_msg is set) with msg_lock
+*/
+ spinlock_t msg_lock;
+ struct ipmi_smi_msg *cur_msg;
+ struct opal_ipmi_msg*opal_msg;
+};
+
+static int ipmi_powernv_start_processing(void *send_info, ipmi_smi_t intf)
+{
+ struct ipmi_smi_powernv *smi = send_info;
+ smi-intf = intf;
+ return 0;
+}
+
+static void send_error_reply(struct ipmi_smi_powernv *smi,
+ struct ipmi_smi_msg *msg, u8 completion_code)
+{
+ msg-rsp[0] = msg-data[0] | 0x4;
+ msg-rsp[1] = msg-data[1];
+ msg-rsp[2] = completion_code;
+ msg-rsp_size = 3;
+ ipmi_smi_msg_received(smi-intf, msg);
+}
+
+static void ipmi_powernv_send(void *send_info, struct ipmi_smi_msg *msg)
+{
+ struct ipmi_smi_powernv *smi = send_info;
+ struct opal_ipmi_msg *opal_msg;
+ unsigned long flags;
+ int comp, rc;
+ size_t size;
+
+ /* ensure data_len will fit in the opal_ipmi_msg buffer... */
+ if (msg-data_size IPMI_MAX_MSG_LENGTH) {
+ comp = IPMI_REQ_LEN_EXCEEDED_ERR;
+ goto err;
+ }
+
+ /* ... and that we at least have netfn and cmd bytes */
+ if (msg-data_size 2) {
+ comp = IPMI_REQ_LEN_INVALID_ERR;
+ goto err;
+ }
+
+ spin_lock_irqsave(smi-msg_lock, flags);
+
+ if (smi-cur_msg) {
+ comp = IPMI_NODE_BUSY_ERR;
+ goto err_unlock;
+ }
+
+ /* format our data for the OPAL API */
+ opal_msg = smi-opal_msg;
+ opal_msg-version = OPAL_IPMI_MSG_FORMAT_VERSION_1;
+ opal_msg-netfn = msg-data[0];
+ opal_msg-cmd = msg-data[1];
+ if (msg-data_size 2)
+ memcpy(opal_msg-data, msg-data + 2, msg-data_size - 2);
+
+ /* data_size already includes the netfn and cmd bytes */
+ size = sizeof(*opal_msg) + msg-data_size - 2;
+
+ pr_devel(%s: opal_ipmi_send(0x%llx, %p, %ld)\n, __func__,
+ smi-interface_id, opal_msg, size);
+ rc = opal_ipmi_send(smi-interface_id, opal_msg, size);
+ pr_devel(%s: - %d\n,
