* Re: [PATCH 5/6 v2] kvm: powerpc: booke: Add linux pte lookup like booke3s
From: "“tiejun.chen”" @ 2013-08-02 6:37 UTC (permalink / raw)
To: Bharat Bhushan
Cc: kvm, agraf, kvm-ppc, Bharat Bhushan, scottwood, linuxppc-dev
In-Reply-To: <1375355558-19187-6-git-send-email-Bharat.Bhushan@freescale.com>
On 08/01/2013 07:12 PM, Bharat Bhushan wrote:
> KVM need to lookup linux pte for getting TLB attributes (WIMGE).
> This is similar to how book3s does.
> This will be used in follow-up patches.
>
> Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
> ---
> v1->v2
> - This is a new change in this version
>
> arch/powerpc/include/asm/kvm_booke.h | 73 ++++++++++++++++++++++++++++++++++
> 1 files changed, 73 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/kvm_booke.h b/arch/powerpc/include/asm/kvm_booke.h
> index d3c1eb3..903624d 100644
> --- a/arch/powerpc/include/asm/kvm_booke.h
> +++ b/arch/powerpc/include/asm/kvm_booke.h
> @@ -102,4 +102,77 @@ static inline ulong kvmppc_get_msr(struct kvm_vcpu *vcpu)
> {
> return vcpu->arch.shared->msr;
> }
> +
> +/*
> + * Lock and read a linux PTE. If it's present and writable, atomically
> + * set dirty and referenced bits and return the PTE, otherwise return 0.
> + */
> +static inline pte_t kvmppc_read_update_linux_pte(pte_t *p, int writing)
> +{
> + pte_t pte;
> +
> +#ifdef PTE_ATOMIC_UPDATES
> + pte_t tmp;
> + /* wait until _PAGE_BUSY is clear then set it atomically */
> +#ifdef CONFIG_PPC64
> + __asm__ __volatile__ (
> + "1: ldarx %0,0,%3\n"
> + " andi. %1,%0,%4\n"
> + " bne- 1b\n"
> + " ori %1,%0,%4\n"
> + " stdcx. %1,0,%3\n"
> + " bne- 1b"
> + : "=&r" (pte), "=&r" (tmp), "=m" (*p)
> + : "r" (p), "i" (_PAGE_BUSY)
> + : "cc");
> +#else
> + __asm__ __volatile__ (
> + "1: lwarx %0,0,%3\n"
> + " andi. %1,%0,%4\n"
> + " bne- 1b\n"
> + " ori %1,%0,%4\n"
> + " stwcx. %1,0,%3\n"
> + " bne- 1b"
> + : "=&r" (pte), "=&r" (tmp), "=m" (*p)
> + : "r" (p), "i" (_PAGE_BUSY)
> + : "cc");
> +#endif
> +#else
> + pte = pte_val(*p);
> +#endif
> +
> + if (pte_present(pte)) {
> + pte = pte_mkyoung(pte);
> + if (writing && pte_write(pte))
> + pte = pte_mkdirty(pte);
> + }
> +
> + *p = pte; /* clears _PAGE_BUSY */
> +
> + return pte;
> +}
> +
> +static inline pte_t lookup_linux_pte(pgd_t *pgdir, unsigned long hva,
> + int writing, unsigned long *pte_sizep)
Looks this function is as same as book3s, so why not improve that as common :)
Tiejun
> +{
> + pte_t *ptep;
> + unsigned long ps = *pte_sizep;
> + unsigned int shift;
> +
> + ptep = find_linux_pte_or_hugepte(pgdir, hva, &shift);
> + if (!ptep)
> + return __pte(0);
> + if (shift)
> + *pte_sizep = 1ul << shift;
> + else
> + *pte_sizep = PAGE_SIZE;
> +
> + if (ps > *pte_sizep)
> + return __pte(0);
> + if (!pte_present(*ptep))
> + return __pte(0);
> +
> + return kvmppc_read_update_linux_pte(ptep, writing);
> +}
> +
> #endif /* __ASM_KVM_BOOKE_H__ */
>
^ permalink raw reply
* Re: [PATCH 3/6 v2] kvm: powerpc: allow guest control "G" attribute in mas2
From: "“tiejun.chen”" @ 2013-08-02 6:39 UTC (permalink / raw)
To: Bharat Bhushan
Cc: kvm, agraf, kvm-ppc, Bharat Bhushan, scottwood, linuxppc-dev
In-Reply-To: <1375355558-19187-4-git-send-email-Bharat.Bhushan@freescale.com>
On 08/01/2013 07:12 PM, Bharat Bhushan wrote:
> "G" bit in MAS2 indicates whether the page is Guarded.
> There is no reason to stop guest setting "E", so allow him.
Could we merge patch 2 and 3 into only one.
Tiejun
>
> Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
> ---
> v1->v2
> - no change
>
> arch/powerpc/kvm/e500.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kvm/e500.h b/arch/powerpc/kvm/e500.h
> index 277cb18..4fd9650 100644
> --- a/arch/powerpc/kvm/e500.h
> +++ b/arch/powerpc/kvm/e500.h
> @@ -117,7 +117,7 @@ static inline struct kvmppc_vcpu_e500 *to_e500(struct kvm_vcpu *vcpu)
> #define E500_TLB_USER_PERM_MASK (MAS3_UX|MAS3_UR|MAS3_UW)
> #define E500_TLB_SUPER_PERM_MASK (MAS3_SX|MAS3_SR|MAS3_SW)
> #define MAS2_ATTRIB_MASK \
> - (MAS2_X0 | MAS2_X1 | MAS2_E)
> + (MAS2_X0 | MAS2_X1 | MAS2_E | MAS2_G)
> #define MAS3_ATTRIB_MASK \
> (MAS3_U0 | MAS3_U1 | MAS3_U2 | MAS3_U3 \
> | E500_TLB_USER_PERM_MASK | E500_TLB_SUPER_PERM_MASK)
>
^ permalink raw reply
* [PATCH v4 1/3] powerpc/85xx: Add SEC6.0 device tree
From: Po Liu @ 2013-08-02 6:39 UTC (permalink / raw)
To: linuxppc-dev; +Cc: scottwood, Mingkai Hu, afleming, Po Liu
In-Reply-To: <1375174163-19246-3-git-send-email-Po.Liu@freescale.com>
From: Mingkai Hu <Mingkai.Hu@freescale.com>
Add device tree for SEC 6.0 used on C29x silicon.
Signed-off-by: Mingkai Hu <Mingkai.Hu@freescale.com>
Signed-off-by: Po Liu <Po.Liu@freescale.com>
---
Changes for v2:
- Remove the compatible sec v4.0/v4.4/v5.0;
- Add the device tree binding file fsl-sec6.txt;
Changes for v3:
- Change some comments in fsl-sec6.txt
Changes for v4:
- Change the full example in fsl-sec6.txt
.../devicetree/bindings/crypto/fsl-sec6.txt | 157 +++++++++++++++++++++
arch/powerpc/boot/dts/fsl/qoriq-sec6.0-0.dtsi | 56 ++++++++
2 files changed, 213 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/fsl-sec6.txt
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-sec6.0-0.dtsi
diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec6.txt b/Documentation/devicetree/bindings/crypto/fsl-sec6.txt
new file mode 100644
index 0000000..c0a20cd
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/fsl-sec6.txt
@@ -0,0 +1,157 @@
+SEC 6 is as Freescale's Cryptographic Accelerator and Assurance Module (CAAM).
+Currently Freescale powerpc chip C29X is embeded with SEC 6.
+SEC 6 device tree binding include:
+ -SEC 6 Node
+ -Job Ring Node
+ -Full Example
+
+=====================================================================
+SEC 6 Node
+
+Description
+
+ Node defines the base address of the SEC 6 block.
+ This block specifies the address range of all global
+ configuration registers for the SEC 6 block.
+ For example, In C293, we could see three SEC 6 node.
+
+PROPERTIES
+
+ - compatible
+ Usage: required
+ Value type: <string>
+ Definition: Must include "fsl,sec-v6.0".
+
+ - fsl,sec-era
+ Usage: optional
+ Value type: <u32>
+ Definition: A standard property. Define the 'ERA' of the SEC
+ device.
+
+ - #address-cells
+ Usage: required
+ Value type: <u32>
+ Definition: A standard property. Defines the number of cells
+ for representing physical addresses in child nodes.
+
+ - #size-cells
+ Usage: required
+ Value type: <u32>
+ Definition: A standard property. Defines the number of cells
+ for representing the size of physical addresses in
+ child nodes.
+
+ - reg
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: A standard property. Specifies the physical
+ address and length of the SEC 6 configuration registers.
+
+ - ranges
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: A standard property. Specifies the physical address
+ range of the SEC 6.0 register space (-SNVS not included). A
+ triplet that includes the child address, parent address, &
+ length.
+
+ Note: All other standard properties (see the ePAPR) are allowed
+ but are optional.
+
+EXAMPLE
+ crypto@a0000 {
+ compatible = "fsl,sec-v6.0";
+ fsl,sec-era = <6>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0xa0000 0x20000>;
+ ranges = <0 0xa0000 0x20000>;
+ };
+
+=====================================================================
+Job Ring (JR) Node
+
+ Child of the crypto node defines data processing interface to SEC 6
+ across the peripheral bus for purposes of processing
+ cryptographic descriptors. The specified address
+ range can be made visible to one (or more) cores.
+ The interrupt defined for this node is controlled within
+ the address range of this node.
+
+ - compatible
+ Usage: required
+ Value type: <string>
+ Definition: Must include "fsl,sec-v6.0-job-ring".
+
+ - reg
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: Specifies a two JR parameters: an offset from
+ the parent physical address and the length the JR registers.
+
+ - interrupts
+ Usage: required
+ Value type: <prop_encoded-array>
+ Definition: Specifies the interrupts generated by this
+ device. The value of the interrupts property
+ consists of one interrupt specifier. The format
+ of the specifier is defined by the binding document
+ describing the node's interrupt parent.
+
+EXAMPLE
+ jr@1000 {
+ compatible = "fsl,sec-v6.0-job-ring";
+ reg = <0x1000 0x1000>;
+ interrupts = <49 2 0 0>;
+ };
+
+===================================================================
+Full Example
+
+Since some chips may contain more than one SEC, the dtsi contains
+only the node contents, not the node itself. A chip using the SEC
+should include the dtsi inside each SEC node. Example:
+
+In qoriq-sec6.0.dtsi:
+
+ compatible = "fsl,sec-v6.0";
+ fsl,sec-era = <6>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ jr@1000 {
+ compatible = "fsl,sec-v6.0-job-ring",
+ "fsl,sec-v5.2-job-ring",
+ "fsl,sec-v5.0-job-ring",
+ "fsl,sec-v4.4-job-ring",
+ "fsl,sec-v4.0-job-ring";
+ reg = <0x1000 0x1000>;
+ };
+
+ jr@2000 {
+ compatible = "fsl,sec-v6.0-job-ring",
+ "fsl,sec-v5.2-job-ring",
+ "fsl,sec-v5.0-job-ring",
+ "fsl,sec-v4.4-job-ring",
+ "fsl,sec-v4.0-job-ring";
+ reg = <0x2000 0x1000>;
+ };
+
+In the C293 device tree, we add the include of public property:
+
+ crypto@a0000 {
+ /include/ "qoriq-sec6.0.dtsi"
+ }
+
+ crypto@a0000 {
+ reg = <0xa0000 0x20000>;
+ ranges = <0 0xa0000 0x20000>;
+
+ jr@1000 {
+ interrupts = <49 2 0 0>;
+ };
+
+ jr@2000 {
+ interrupts = <50 2 0 0>;
+ };
+ };
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-sec6.0-0.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-sec6.0-0.dtsi
new file mode 100644
index 0000000..f75b4f820
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/qoriq-sec6.0-0.dtsi
@@ -0,0 +1,56 @@
+/*
+ * QorIQ Sec/Crypto 6.0 device tree stub
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+ compatible = "fsl,sec-v6.0";
+ fsl,sec-era = <6>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ jr@1000 {
+ compatible = "fsl,sec-v6.0-job-ring",
+ "fsl,sec-v5.2-job-ring",
+ "fsl,sec-v5.0-job-ring",
+ "fsl,sec-v4.4-job-ring",
+ "fsl,sec-v4.0-job-ring";
+ reg = <0x1000 0x1000>;
+ };
+
+ jr@2000 {
+ compatible = "fsl,sec-v6.0-job-ring",
+ "fsl,sec-v5.2-job-ring",
+ "fsl,sec-v5.0-job-ring",
+ "fsl,sec-v4.4-job-ring",
+ "fsl,sec-v4.0-job-ring";
+ reg = <0x2000 0x1000>;
+ };
--
1.8.0
^ permalink raw reply related
* [PATCH v4 2/3] powerpc/85xx: Add silicon device tree for C293
From: Po Liu @ 2013-08-02 6:39 UTC (permalink / raw)
To: linuxppc-dev; +Cc: scottwood, Mingkai Hu, afleming, Po Liu
In-Reply-To: <1375425551-821-1-git-send-email-Po.Liu@freescale.com>
From: Mingkai Hu <Mingkai.Hu@freescale.com>
Signed-off-by: Mingkai Hu <Mingkai.Hu@freescale.com>
Signed-off-by: Po Liu <Po.Liu@freescale.com>
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- None
arch/powerpc/boot/dts/fsl/c293si-post.dtsi | 193 +++++++++++++++++++++++++++++
arch/powerpc/boot/dts/fsl/c293si-pre.dtsi | 63 ++++++++++
2 files changed, 256 insertions(+)
create mode 100644 arch/powerpc/boot/dts/fsl/c293si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/c293si-pre.dtsi
diff --git a/arch/powerpc/boot/dts/fsl/c293si-post.dtsi b/arch/powerpc/boot/dts/fsl/c293si-post.dtsi
new file mode 100644
index 0000000..bd20832
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/c293si-post.dtsi
@@ -0,0 +1,193 @@
+/*
+ * C293 Silicon/SoC Device Tree Source (post include)
+ *
+ * Copyright 2012 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+&ifc {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,ifc", "simple-bus";
+ interrupts = <19 2 0 0>;
+};
+
+/* controller at 0xa000 */
+&pci0 {
+ compatible = "fsl,qoriq-pcie-v2.2", "fsl,qoriq-pcie";
+ device_type = "pci";
+ #size-cells = <2>;
+ #address-cells = <3>;
+ bus-range = <0 255>;
+ clock-frequency = <33333333>;
+ interrupts = <16 2 0 0>;
+
+ pcie@0 {
+ reg = <0 0 0 0 0>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ interrupts = <16 2 0 0>;
+ interrupt-map-mask = <0xf800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0000 0x0 0x0 0x1 &mpic 0x0 0x1 0x0 0x0
+ 0000 0x0 0x0 0x2 &mpic 0x1 0x1 0x0 0x0
+ 0000 0x0 0x0 0x3 &mpic 0x2 0x1 0x0 0x0
+ 0000 0x0 0x0 0x4 &mpic 0x3 0x1 0x0 0x0
+ >;
+ };
+};
+
+&soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ compatible = "simple-bus";
+ bus-frequency = <0>; // Filled out by uboot.
+
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <12>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,c293-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <16 2 0 0>;
+ };
+
+ memory-controller@2000 {
+ compatible = "fsl,c293-memory-controller";
+ reg = <0x2000 0x1000>;
+ interrupts = <16 2 0 0>;
+ };
+
+/include/ "pq3-i2c-0.dtsi"
+/include/ "pq3-i2c-1.dtsi"
+/include/ "pq3-duart-0.dtsi"
+/include/ "pq3-espi-0.dtsi"
+ spi0: spi@7000 {
+ fsl,espi-num-chipselects = <1>;
+ };
+
+/include/ "pq3-gpio-0.dtsi"
+ L2: l2-cache-controller@20000 {
+ compatible = "fsl,c293-l2-cache-controller";
+ reg = <0x20000 0x1000>;
+ cache-line-size = <32>; // 32 bytes
+ cache-size = <0x80000>; // L2,512K
+ interrupts = <16 2 0 0>;
+ };
+
+/include/ "pq3-dma-0.dtsi"
+/include/ "pq3-esdhc-0.dtsi"
+ sdhc@2e000 {
+ compatible = "fsl,c293-esdhc", "fsl,esdhc";
+ sdhci,auto-cmd12;
+ };
+
+ crypto@80000 {
+/include/ "qoriq-sec6.0-0.dtsi"
+ };
+
+ crypto@80000 {
+ reg = <0x80000 0x20000>;
+ ranges = <0x0 0x80000 0x20000>;
+
+ jr@1000{
+ interrupts = <45 2 0 0>;
+ };
+ jr@2000{
+ interrupts = <57 2 0 0>;
+ };
+ };
+
+ crypto@a0000 {
+/include/ "qoriq-sec6.0-0.dtsi"
+ };
+
+ crypto@a0000 {
+ reg = <0xa0000 0x20000>;
+ ranges = <0x0 0xa0000 0x20000>;
+
+ jr@1000{
+ interrupts = <49 2 0 0>;
+ };
+ jr@2000{
+ interrupts = <50 2 0 0>;
+ };
+ };
+
+ crypto@c0000 {
+/include/ "qoriq-sec6.0-0.dtsi"
+ };
+
+ crypto@c0000 {
+ reg = <0xc0000 0x20000>;
+ ranges = <0x0 0xc0000 0x20000>;
+
+ jr@1000{
+ interrupts = <55 2 0 0>;
+ };
+ jr@2000{
+ interrupts = <56 2 0 0>;
+ };
+ };
+
+/include/ "pq3-mpic.dtsi"
+/include/ "pq3-mpic-timer-B.dtsi"
+
+/include/ "pq3-etsec2-0.dtsi"
+ enet0: ethernet@b0000 {
+ queue-group@b0000 {
+ reg = <0x10000 0x1000>;
+ fsl,rx-bit-map = <0xff>;
+ fsl,tx-bit-map = <0xff>;
+ };
+ };
+
+/include/ "pq3-etsec2-1.dtsi"
+ enet1: ethernet@b1000 {
+ queue-group@b1000 {
+ reg = <0x11000 0x1000>;
+ fsl,rx-bit-map = <0xff>;
+ fsl,tx-bit-map = <0xff>;
+ };
+ };
+
+ global-utilities@e0000 {
+ compatible = "fsl,c293-guts";
+ reg = <0xe0000 0x1000>;
+ fsl,has-rstcr;
+ };
+};
diff --git a/arch/powerpc/boot/dts/fsl/c293si-pre.dtsi b/arch/powerpc/boot/dts/fsl/c293si-pre.dtsi
new file mode 100644
index 0000000..065049d
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/c293si-pre.dtsi
@@ -0,0 +1,63 @@
+/*
+ * C293 Silicon/SoC Device Tree Source (pre include)
+ *
+ * Copyright 2012 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/dts-v1/;
+
+/include/ "e500v2_power_isa.dtsi"
+
+/ {
+ compatible = "fsl,C293";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <&mpic>;
+
+ aliases {
+ serial0 = &serial0;
+ serial1 = &serial1;
+ ethernet0 = &enet0;
+ ethernet1 = &enet1;
+ pci0 = &pci0;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,e500v2@0 {
+ device_type = "cpu";
+ reg = <0x0>;
+ next-level-cache = <&L2>;
+ };
+ };
+};
--
1.8.0
^ permalink raw reply related
* [PATCH v4 3/3] powerpc/85xx: Add C293PCIE board support
From: Po Liu @ 2013-08-02 6:39 UTC (permalink / raw)
To: linuxppc-dev; +Cc: scottwood, Mingkai Hu, afleming, Po Liu
In-Reply-To: <1375425551-821-1-git-send-email-Po.Liu@freescale.com>
From: Mingkai Hu <Mingkai.Hu@freescale.com>
C293PCIE board is a series of Freescale PCIe add-in cards to perform
as public key crypto accelerator or secure key management module.
- 512KB platform SRAM in addition to 512K L2 Cache/SRAM
- 512MB soldered DDR3 32bit memory
- CPLD System Logic
- 64MB x16 NOR flash and 4GB x8 NAND flash
- 16MB SPI flash
Signed-off-by: Mingkai Hu <Mingkai.Hu@freescale.com>
Signed-off-by: Po Liu <Po.Liu@freescale.com>
---
Changes for v2:
- Remove the JFFS2 partitions in NOR/NAND/SPI flash;
- Implement the NAND partitions;
- Remove the no use descriptions for cpld node;
- Add mpc85xx_smp_defconfig and mpc85xx_defconfig for C293;
- Remove the no use includes in c293pcie.c
Changes for v3:
- Remove some partitions for NAND, merge them into RFS
- Modify the SPI RFS partition expression
- Remove #address-cells #size-cells in cpld node
Changes for v4:
- Set NAND kernel image partition to be 16MB size from 4MB
arch/powerpc/boot/dts/c293pcie.dts | 223 +++++++++++++++++++++++++++++
arch/powerpc/configs/mpc85xx_defconfig | 1 +
arch/powerpc/configs/mpc85xx_smp_defconfig | 1 +
arch/powerpc/platforms/85xx/Kconfig | 6 +
arch/powerpc/platforms/85xx/Makefile | 1 +
arch/powerpc/platforms/85xx/c293pcie.c | 75 ++++++++++
6 files changed, 307 insertions(+)
create mode 100644 arch/powerpc/boot/dts/c293pcie.dts
create mode 100644 arch/powerpc/platforms/85xx/c293pcie.c
diff --git a/arch/powerpc/boot/dts/c293pcie.dts b/arch/powerpc/boot/dts/c293pcie.dts
new file mode 100644
index 0000000..1238bda
--- /dev/null
+++ b/arch/powerpc/boot/dts/c293pcie.dts
@@ -0,0 +1,223 @@
+/*
+ * C293 PCIE Device Tree Source
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor "AS IS" AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "fsl/c293si-pre.dtsi"
+
+/ {
+ model = "fsl,C293PCIE";
+ compatible = "fsl,C293PCIE";
+
+ memory {
+ device_type = "memory";
+ };
+
+ ifc: ifc@fffe1e000 {
+ reg = <0xf 0xffe1e000 0 0x2000>;
+ ranges = <0x0 0x0 0xf 0xec000000 0x04000000
+ 0x2 0x0 0xf 0xffdf0000 0x00010000>;
+
+ };
+
+ soc: soc@fffe00000 {
+ ranges = <0x0 0xf 0xffe00000 0x100000>;
+ };
+
+ pci0: pcie@fffe0a000 {
+ reg = <0xf 0xffe0a000 0 0x1000>;
+ ranges = <0x2000000 0x0 0x80000000 0xc 0x00000000 0x0 0x20000000
+ 0x1000000 0x0 0x00000000 0xf 0xffc00000 0x0 0x10000>;
+ pcie@0 {
+ ranges = <0x2000000 0x0 0x80000000
+ 0x2000000 0x0 0x80000000
+ 0x0 0x20000000
+
+ 0x1000000 0x0 0x0
+ 0x1000000 0x0 0x0
+ 0x0 0x100000>;
+ };
+ };
+};
+
+&ifc {
+ nor@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x4000000>;
+ bank-width = <2>;
+ device-width = <1>;
+
+ partition@0 {
+ /* 1MB for DTB Image */
+ reg = <0x0 0x00100000>;
+ label = "NOR DTB Image";
+ };
+
+ partition@100000 {
+ /* 8 MB for Linux Kernel Image */
+ reg = <0x00100000 0x00800000>;
+ label = "NOR Linux Kernel Image";
+ };
+
+ partition@900000 {
+ /* 53MB for rootfs */
+ reg = <0x00900000 0x03500000>;
+ label = "NOR Rootfs Image";
+ };
+
+ partition@3e00000 {
+ /* 1MB for blob encrypted key */
+ reg = <0x03e00000 0x00100000>;
+ label = "NOR blob encrypted key";
+ };
+
+ partition@3f00000 {
+ /* 512KB for u-boot Bootloader Image and evn */
+ reg = <0x03f00000 0x00100000>;
+ label = "NOR U-Boot Image";
+ read-only;
+ };
+ };
+
+ nand@1,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,ifc-nand";
+ reg = <0x1 0x0 0x10000>;
+
+ partition@0 {
+ /* This location must not be altered */
+ /* 1MB for u-boot Bootloader Image */
+ reg = <0x0 0x00100000>;
+ label = "NAND U-Boot Image";
+ read-only;
+ };
+
+ partition@100000 {
+ /* 1MB for DTB Image */
+ reg = <0x00100000 0x00100000>;
+ label = "NAND DTB Image";
+ };
+
+ partition@200000 {
+ /* 16MB for Linux Kernel Image */
+ reg = <0x00200000 0x01000000>;
+ label = "NAND Linux Kernel Image";
+ };
+
+ partition@1200000 {
+ /* 4078MB for Root file System Image */
+ reg = <0x00600000 0xfee00000>;
+ label = "NAND RFS Image";
+ };
+ };
+
+ cpld@2,0 {
+ compatible = "fsl,c293pcie-cpld";
+ reg = <0x2 0x0 0x20>;
+ };
+};
+
+&soc {
+ i2c@3000 {
+ eeprom@50 {
+ compatible = "st,24c1024";
+ reg = <0x50>;
+ };
+
+ adt7461@4c {
+ compatible = "adi,adt7461";
+ reg = <0x4c>;
+ };
+ };
+
+ spi@7000 {
+ flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "spansion,s25sl12801";
+ reg = <0>;
+ spi-max-frequency = <50000000>;
+
+ partition@0 {
+ /* 1MB for u-boot Bootloader Image */
+ /* 1MB for Environment */
+ reg = <0x0 0x00100000>;
+ label = "SPI Flash U-Boot Image";
+ read-only;
+ };
+
+ partition@100000 {
+ /* 512KB for DTB Image */
+ reg = <0x00100000 0x00080000>;
+ label = "SPI Flash DTB Image";
+ };
+
+ partition@180000 {
+ /* 4MB for Linux Kernel Image */
+ reg = <0x00180000 0x00400000>;
+ label = "SPI Flash Linux Kernel Image";
+ };
+
+ partition@580000 {
+ /* 10.5MB for RFS Image */
+ reg = <0x00580000 0x00a80000>;
+ label = "SPI Flash RFS Image";
+ };
+ };
+ };
+
+ mdio@24000 {
+ phy0: ethernet-phy@0 {
+ interrupts = <2 1 0 0>;
+ reg = <0x0>;
+ };
+
+ phy1: ethernet-phy@1 {
+ interrupts = <2 1 0 0>;
+ reg = <0x2>;
+ };
+ };
+
+ enet0: ethernet@b0000 {
+ phy-handle = <&phy0>;
+ phy-connection-type = "rgmii-id";
+ };
+
+ enet1: ethernet@b1000 {
+ phy-handle = <&phy1>;
+ phy-connection-type = "rgmii-id";
+ };
+};
+/include/ "fsl/c293si-post.dtsi"
diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig
index 5a58882..1592f8c 100644
--- a/arch/powerpc/configs/mpc85xx_defconfig
+++ b/arch/powerpc/configs/mpc85xx_defconfig
@@ -27,6 +27,7 @@ CONFIG_MPC85xx_MDS=y
CONFIG_MPC8536_DS=y
CONFIG_MPC85xx_DS=y
CONFIG_MPC85xx_RDB=y
+CONFIG_C293_PCIE=y
CONFIG_P1010_RDB=y
CONFIG_P1022_DS=y
CONFIG_P1022_RDK=y
diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig
index 152fa05..d6549ff 100644
--- a/arch/powerpc/configs/mpc85xx_smp_defconfig
+++ b/arch/powerpc/configs/mpc85xx_smp_defconfig
@@ -30,6 +30,7 @@ CONFIG_MPC85xx_MDS=y
CONFIG_MPC8536_DS=y
CONFIG_MPC85xx_DS=y
CONFIG_MPC85xx_RDB=y
+CONFIG_C293_PCIE=y
CONFIG_P1010_RDB=y
CONFIG_P1022_DS=y
CONFIG_P1022_RDK=y
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index efdd37c..42fc72a 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -32,6 +32,12 @@ config BSC9131_RDB
StarCore SC3850 DSP
Manufacturer : Freescale Semiconductor, Inc
+config C293_PCIE
+ bool "Freescale C293PCIE"
+ select DEFAULT_UIMAGE
+ help
+ This option enables support for the C293PCIE board
+
config MPC8540_ADS
bool "Freescale MPC8540 ADS"
select DEFAULT_UIMAGE
diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
index 2eab37e..53c9f75 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_SMP) += smp.o
obj-y += common.o
obj-$(CONFIG_BSC9131_RDB) += bsc913x_rdb.o
+obj-$(CONFIG_C293_PCIE) += c293pcie.o
obj-$(CONFIG_MPC8540_ADS) += mpc85xx_ads.o
obj-$(CONFIG_MPC8560_ADS) += mpc85xx_ads.o
obj-$(CONFIG_MPC85xx_CDS) += mpc85xx_cds.o
diff --git a/arch/powerpc/platforms/85xx/c293pcie.c b/arch/powerpc/platforms/85xx/c293pcie.c
new file mode 100644
index 0000000..6208e49
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/c293pcie.c
@@ -0,0 +1,75 @@
+/*
+ * C293PCIE Board Setup
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/stddef.h>
+#include <linux/kernel.h>
+#include <linux/of_platform.h>
+
+#include <asm/machdep.h>
+#include <asm/udbg.h>
+#include <asm/mpic.h>
+
+#include <sysdev/fsl_soc.h>
+#include <sysdev/fsl_pci.h>
+
+#include "mpc85xx.h"
+
+void __init c293_pcie_pic_init(void)
+{
+ struct mpic *mpic = mpic_alloc(NULL, 0, MPIC_BIG_ENDIAN |
+ MPIC_SINGLE_DEST_CPU, 0, 256, " OpenPIC ");
+
+ BUG_ON(mpic == NULL);
+
+ mpic_init(mpic);
+}
+
+
+/*
+ * Setup the architecture
+ */
+static void __init c293_pcie_setup_arch(void)
+{
+ if (ppc_md.progress)
+ ppc_md.progress("c293_pcie_setup_arch()", 0);
+
+ fsl_pci_assign_primary();
+
+ printk(KERN_INFO "C293 PCIE board from Freescale Semiconductor\n");
+}
+
+machine_arch_initcall(c293_pcie, mpc85xx_common_publish_devices);
+
+/*
+ * Called very early, device-tree isn't unflattened
+ */
+static int __init c293_pcie_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if (of_flat_dt_is_compatible(root, "fsl,C293PCIE"))
+ return 1;
+ return 0;
+}
+
+define_machine(c293_pcie) {
+ .name = "C293 PCIE",
+ .probe = c293_pcie_probe,
+ .setup_arch = c293_pcie_setup_arch,
+ .init_IRQ = c293_pcie_pic_init,
+#ifdef CONFIG_PCI
+ .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+#endif
+ .get_irq = mpic_get_irq,
+ .restart = fsl_rstcr_restart,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+};
--
1.8.0
^ permalink raw reply related
* [PATCH] powerpc/pci: Change the DECLARE_PCI_FIXUP_{HEADER => EARLY} macro of pci quirk
From: Chunhe Lan @ 2013-08-02 8:46 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Bjorn Helgaas, Paul Mackerras, Chunhe Lan
Freescale platform has class code = 0x0b2000, when it boots. This makes
kernel PCI bus code to setup these devices resulting into the following
notice information when trying to enable them:
pci 0000:00:00.0: ignoring class 0x0b2000 (doesn't match header type 01)
The above information is outputted by judging value of dev->class before
pci_setup_device() function, and the DECLARE_PCI_FIXUP_HEADER quirk runs
after pci_setup_device() function. But the DECLARE_PCI_FIXUP_EARLY quirk
runs before judging value of dev->class and pci_setup_device() function.
So we use the DECLARE_PCI_FIXUP_EARLY macro to fix this issue.
Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Paul Mackerras <paulus@samba.org>
---
arch/powerpc/sysdev/fsl_pci.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 46ac1dd..3e8b9d4 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -36,7 +36,7 @@
static int fsl_pcie_bus_fixup, is_mpc83xx_pci;
-static void quirk_fsl_pcie_header(struct pci_dev *dev)
+static void quirk_fsl_pcie_early(struct pci_dev *dev)
{
u8 hdr_type;
@@ -556,7 +556,8 @@ no_bridge:
}
#endif /* CONFIG_FSL_SOC_BOOKE || CONFIG_PPC_86xx */
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID, quirk_fsl_pcie_header);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID,
+ quirk_fsl_pcie_early);
#if defined(CONFIG_PPC_83xx) || defined(CONFIG_PPC_MPC512x)
struct mpc83xx_pcie_priv {
--
1.7.6.5
^ permalink raw reply related
* Re: therm_pm72 units, interface
From: Michel Dänzer @ 2013-08-02 10:03 UTC (permalink / raw)
To: Aaro Koskinen; +Cc: Jan Engelhardt, linuxppc-dev, Ben Hutchings
In-Reply-To: <20130720203346.GM14385@blackmetal.musicnaut.iki.fi>
On Sam, 2013-07-20 at 23:33 +0300, Aaro Koskinen wrote:
> Hi,
>=20
> On Sat, Jul 20, 2013 at 09:16:49AM +1000, Benjamin Herrenschmidt wrote:
> > On Fri, 2013-07-19 at 20:43 +0300, Aaro Koskinen wrote:
> > > I booted a Xserve today with 3.11-rc1, and noticed the noise is comin=
g
> > > from slots-fan (PCI fan?) which is always 99%, although the slots-tem=
p is
> > > just 33. Is it on purpose the rm31 slots PID params are totally diffe=
rent
> > > from therm_pm72 slots params? It seems like they have been copied fro=
m
> > > pm72 "drive bay" PID params instead.
> >=20
> > Could be my mistake. What happens if you change them to match the old c=
ode ?
>=20
> I tried the change below (use SLOTS_PID_* values from therm_pm72.h),
> and the noise level is considerably lower. The slots-fan stays at 19%,
> and slots-temp rises to 42'C but not higher after running couple of hours=
.
>=20
> diff --git a/drivers/macintosh/windfarm_rm31.c b/drivers/macintosh/windfa=
rm_rm31.c
> index 0b9a79b..82fc86a 100644
> --- a/drivers/macintosh/windfarm_rm31.c
> +++ b/drivers/macintosh/windfarm_rm31.c
> @@ -439,15 +439,15 @@ static void backside_setup_pid(void)
> =20
> /* Slots fan */
> static const struct wf_pid_param slots_param =3D {
> - .interval =3D 5,
> - .history_len =3D 2,
> - .gd =3D 30 << 20,
> - .gp =3D 5 << 20,
> - .gr =3D 0,
> - .itarget =3D 40 << 16,
> - .additive =3D 1,
> - .min =3D 300,
> - .max =3D 4000,
> + .interval =3D 1,
> + .history_len =3D 20,
> + .gd =3D 0,
> + .gp =3D 0,
> + .gr =3D 0x00100000,
> + .itarget =3D 3200000,
> + .additive =3D 0,
> + .min =3D 20,
> + .max =3D 100,
> };
> =20
> static void slots_fan_tick(void)
Could a similar change fix the same problem on desktop G5s? The same
values for slots_param in windfarm_pm112.c don't help, unfortunately.
--=20
Earthling Michel D=C3=A4nzer | http://www.amd.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: [linux-pm] [PATCH 1/3] cpuidle/powernv: cpuidle backend driver for powernv
From: Preeti U Murthy @ 2013-08-02 10:32 UTC (permalink / raw)
To: Daniel Lezcano; +Cc: Deepthi Dharwar, linux-pm, linuxppc-dev, linux-kernel
In-Reply-To: <51F35A2A.1080408@linaro.org>
Hi Daniel,
On 07/27/2013 10:57 AM, Daniel Lezcano wrote:
> On 07/23/2013 11:01 AM, Deepthi Dharwar wrote:
>> This patch implements a back-end cpuidle driver for
>> powernv calling power7_nap and snooze idle states.
>> This can be extended by adding more idle states
>> in the future to the existing framework.
>>
>> Signed-off-by: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
>> ---
>> arch/powerpc/platforms/powernv/Kconfig | 9 +
>> arch/powerpc/platforms/powernv/Makefile | 1
>> arch/powerpc/platforms/powernv/processor_idle.c | 239 +++++++++++++++++++++++
>> 3 files changed, 249 insertions(+)
>> create mode 100644 arch/powerpc/platforms/powernv/processor_idle.c
>>
>> diff --git a/arch/powerpc/platforms/powernv/processor_idle.c b/arch/powerpc/platforms/powernv/processor_idle.c
>> new file mode 100644
>> index 0000000..f43ad91a
>> --- /dev/null
>> +++ b/arch/powerpc/platforms/powernv/processor_idle.c
>> @@ -0,0 +1,239 @@
>> +/*
>> + * processor_idle - idle state cpuidle driver.
>> + */
>> +
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/init.h>
>> +#include <linux/moduleparam.h>
>> +#include <linux/cpuidle.h>
>> +#include <linux/cpu.h>
>> +#include <linux/notifier.h>
>> +
>> +#include <asm/machdep.h>
>> +#include <asm/runlatch.h>
>> +
>> +struct cpuidle_driver powernv_idle_driver = {
>> + .name = "powernv_idle",
>> + .owner = THIS_MODULE,
>> +};
>> +
>> +#define MAX_IDLE_STATE_COUNT 2
>> +
>> +static int max_idle_state = MAX_IDLE_STATE_COUNT - 1;
>> +static struct cpuidle_device __percpu *powernv_cpuidle_devices;
>> +static struct cpuidle_state *cpuidle_state_table;
>> +
>> +static int snooze_loop(struct cpuidle_device *dev,
>> + struct cpuidle_driver *drv,
>> + int index)
>> +{
>> + int cpu = dev->cpu;
>> +
>> + local_irq_enable();
>> + set_thread_flag(TIF_POLLING_NRFLAG);
>> +
>> + while ((!need_resched()) && cpu_online(cpu)) {
>> + ppc64_runlatch_off();
>> + HMT_very_low();
>> + }
>
> Why are you using the cpu_online test here ?
>
>> +
>> + HMT_medium();
>> + clear_thread_flag(TIF_POLLING_NRFLAG);
>> + smp_mb();
>> + return index;
>> +}
>> +
>> +
>> +static int nap_loop(struct cpuidle_device *dev,
>> + struct cpuidle_driver *drv,
>> + int index)
>> +{
>> + ppc64_runlatch_off();
>> + power7_idle();
>> + return index;
>> +}
>> +
>> +/*
>> + * States for dedicated partition case.
>> + */
>> +static struct cpuidle_state powernv_states[MAX_IDLE_STATE_COUNT] = {
>> + { /* Snooze */
>> + .name = "snooze",
>> + .desc = "snooze",
>> + .flags = CPUIDLE_FLAG_TIME_VALID,
>> + .exit_latency = 0,
>> + .target_residency = 0,
>> + .enter = &snooze_loop },
>> + { /* Nap */
>> + .name = "Nap",
>> + .desc = "Nap",
>> + .flags = CPUIDLE_FLAG_TIME_VALID,
>> + .exit_latency = 10,
>> + .target_residency = 100,
>> + .enter = &nap_loop },
>> +};
>> +
>> +static int powernv_cpuidle_add_cpu_notifier(struct notifier_block *n,
>> + unsigned long action, void *hcpu)
>> +{
>> + int hotcpu = (unsigned long)hcpu;
>> + struct cpuidle_device *dev =
>> + per_cpu_ptr(powernv_cpuidle_devices, hotcpu);
>> +
>> + if (dev && cpuidle_get_driver()) {
>> + switch (action) {
>> + case CPU_ONLINE:
>> + case CPU_ONLINE_FROZEN:
>> + cpuidle_pause_and_lock();
>> + cpuidle_enable_device(dev);
>> + cpuidle_resume_and_unlock();
>> + break;
>> +
>> + case CPU_DEAD:
>> + case CPU_DEAD_FROZEN:
>> + cpuidle_pause_and_lock();
>> + cpuidle_disable_device(dev);
>> + cpuidle_resume_and_unlock();
>> + break;
>> +
>> + default:
>> + return NOTIFY_DONE;
>> + }
>> + }
>> + return NOTIFY_OK;
>> +}
>> +
>> +static struct notifier_block setup_hotplug_notifier = {
>> + .notifier_call = powernv_cpuidle_add_cpu_notifier,
>> +};
>
> This is duplicated code with the pseries cpuidle driver and IMHO it
> should be moved to the cpuidle framework.
>
Will this not require a cleanup of the hotplug cpuidle notifiers from
other architectures into the cpuidle framework as well?
Regards
Preeti U Murthy
^ permalink raw reply
* [PATCH v2 0/2] drivers/crypto/nx: fixes when input data is too large
From: Marcelo Cerri @ 2013-08-02 12:09 UTC (permalink / raw)
To: benh; +Cc: Marcelo Cerri, linuxppc-dev, linux-kernel, linux-crypto
This series of patches fixes two bugs that are triggered when the input data is
too large. The first one is caused by the miscalculation of physical addresses
and the second one by some limits that the co-processor has to the input data.
Changes in v2:
* Replace Signed-Off-By tags with Reviewed-By tags where it is
appropriate.
Marcelo Cerri (2):
drivers/crypto/nx: fix physical addresses added to sg lists
drivers/crypto/nx: fix limits to sg lists for SHA-2
drivers/crypto/nx/nx-sha256.c | 108 +++++++++++++++++++++++-----------------
drivers/crypto/nx/nx-sha512.c | 113 ++++++++++++++++++++++++------------------
drivers/crypto/nx/nx.c | 22 ++++++--
3 files changed, 148 insertions(+), 95 deletions(-)
--
1.7.12
^ permalink raw reply
* [PATCH v2 1/2] drivers/crypto/nx: fix physical addresses added to sg lists
From: Marcelo Cerri @ 2013-08-02 12:09 UTC (permalink / raw)
To: benh; +Cc: Marcelo Cerri, linuxppc-dev, linux-kernel, linux-crypto
In-Reply-To: <1375445392-16237-1-git-send-email-mhcerri@linux.vnet.ibm.com>
The co-processor receives data to be hashed through scatter/gather lists
pointing to physical addresses. When a vmalloc'ed data is given, the
driver must calculate the physical address to each page of the data.
However the current version of it just calculates the physical address
once and keeps incrementing it even when a page boundary is crossed.
This patch fixes this behaviour.
Reviewed-by: Fionnuala Gunter <fin@linux.vnet.ibm.com>
Reviewed-by: Joel Schopp <jschopp@linux.vnet.ibm.com>
Reviewed-by: Joy Latten <jmlatten@linux.vnet.ibm.com>
Signed-off-by: Marcelo Cerri <mhcerri@linux.vnet.ibm.com>
---
drivers/crypto/nx/nx.c | 22 +++++++++++++++++++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/nx/nx.c b/drivers/crypto/nx/nx.c
index bbdab6e..ad07dc6 100644
--- a/drivers/crypto/nx/nx.c
+++ b/drivers/crypto/nx/nx.c
@@ -114,13 +114,29 @@ struct nx_sg *nx_build_sg_list(struct nx_sg *sg_head,
* have been described (or @sgmax elements have been written), the
* loop ends. min_t is used to ensure @end_addr falls on the same page
* as sg_addr, if not, we need to create another nx_sg element for the
- * data on the next page */
+ * data on the next page.
+ *
+ * Also when using vmalloc'ed data, every time that a system page
+ * boundary is crossed the physical address needs to be re-calculated.
+ */
for (sg = sg_head; sg_len < len; sg++) {
+ u64 next_page;
+
sg->addr = sg_addr;
- sg_addr = min_t(u64, NX_PAGE_NUM(sg_addr + NX_PAGE_SIZE), end_addr);
- sg->len = sg_addr - sg->addr;
+ sg_addr = min_t(u64, NX_PAGE_NUM(sg_addr + NX_PAGE_SIZE),
+ end_addr);
+
+ next_page = (sg->addr & PAGE_MASK) + PAGE_SIZE;
+ sg->len = min_t(u64, sg_addr, next_page) - sg->addr;
sg_len += sg->len;
+ if (sg_addr >= next_page &&
+ is_vmalloc_addr(start_addr + sg_len)) {
+ sg_addr = page_to_phys(vmalloc_to_page(
+ start_addr + sg_len));
+ end_addr = sg_addr + len - sg_len;
+ }
+
if ((sg - sg_head) == sgmax) {
pr_err("nx: scatter/gather list overflow, pid: %d\n",
current->pid);
--
1.7.12
^ permalink raw reply related
* [PATCH v2 2/2] drivers/crypto/nx: fix limits to sg lists for SHA-2
From: Marcelo Cerri @ 2013-08-02 12:09 UTC (permalink / raw)
To: benh; +Cc: Marcelo Cerri, linuxppc-dev, linux-kernel, linux-crypto
In-Reply-To: <1375445392-16237-1-git-send-email-mhcerri@linux.vnet.ibm.com>
The co-processor has several limits regarding the length of
scatter/gather lists and the total number of bytes in it. These limits
are available in the device tree, as following:
- "ibm,max-sg-len": maximum number of bytes of each scatter/gather
list.
- "ibm,max-sync-cop": used for synchronous operations, it is an array
of structures that contains information regarding the limits that
must be considered for each mode and operation. The most important
limits in it are:
- The total number of bytes that a scatter/gather list can hold.
- The maximum number of elements that a scatter/gather list can
have.
This patch updates the NX driver to perform several hyper calls if
needed in order to always respect the length limits for scatter/gather
lists.
Reviewed-by: Fionnuala Gunter <fin@linux.vnet.ibm.com>
Reviewed-by: Joel Schopp <jschopp@linux.vnet.ibm.com>
Reviewed-by: Joy Latten <jmlatten@linux.vnet.ibm.com>
Signed-off-by: Marcelo Cerri <mhcerri@linux.vnet.ibm.com>
---
drivers/crypto/nx/nx-sha256.c | 108 +++++++++++++++++++++++-----------------
drivers/crypto/nx/nx-sha512.c | 113 ++++++++++++++++++++++++------------------
2 files changed, 129 insertions(+), 92 deletions(-)
diff --git a/drivers/crypto/nx/nx-sha256.c b/drivers/crypto/nx/nx-sha256.c
index 67024f2..254b01a 100644
--- a/drivers/crypto/nx/nx-sha256.c
+++ b/drivers/crypto/nx/nx-sha256.c
@@ -55,70 +55,86 @@ static int nx_sha256_update(struct shash_desc *desc, const u8 *data,
struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(&desc->tfm->base);
struct nx_csbcpb *csbcpb = (struct nx_csbcpb *)nx_ctx->csbcpb;
struct nx_sg *in_sg;
- u64 to_process, leftover;
+ u64 to_process, leftover, total;
+ u32 max_sg_len;
int rc = 0;
- if (NX_CPB_FDM(csbcpb) & NX_FDM_CONTINUATION) {
- /* we've hit the nx chip previously and we're updating again,
- * so copy over the partial digest */
- memcpy(csbcpb->cpb.sha256.input_partial_digest,
- csbcpb->cpb.sha256.message_digest, SHA256_DIGEST_SIZE);
- }
-
/* 2 cases for total data len:
- * 1: <= SHA256_BLOCK_SIZE: copy into state, return 0
- * 2: > SHA256_BLOCK_SIZE: process X blocks, copy in leftover
+ * 1: < SHA256_BLOCK_SIZE: copy into state, return 0
+ * 2: >= SHA256_BLOCK_SIZE: process X blocks, copy in leftover
*/
- if (len + sctx->count < SHA256_BLOCK_SIZE) {
+ total = sctx->count + len;
+ if (total < SHA256_BLOCK_SIZE) {
memcpy(sctx->buf + sctx->count, data, len);
sctx->count += len;
goto out;
}
- /* to_process: the SHA256_BLOCK_SIZE data chunk to process in this
- * update */
- to_process = (sctx->count + len) & ~(SHA256_BLOCK_SIZE - 1);
- leftover = (sctx->count + len) & (SHA256_BLOCK_SIZE - 1);
+ in_sg = nx_ctx->in_sg;
+ max_sg_len = min_t(u32, nx_driver.of.max_sg_len/sizeof(struct nx_sg),
+ nx_ctx->ap->sglen);
- if (sctx->count) {
- in_sg = nx_build_sg_list(nx_ctx->in_sg, (u8 *)sctx->buf,
- sctx->count, nx_ctx->ap->sglen);
- in_sg = nx_build_sg_list(in_sg, (u8 *)data,
+ do {
+ /*
+ * to_process: the SHA256_BLOCK_SIZE data chunk to process in
+ * this update. This value is also restricted by the sg list
+ * limits.
+ */
+ to_process = min_t(u64, total, nx_ctx->ap->databytelen);
+ to_process = min_t(u64, to_process,
+ NX_PAGE_SIZE * (max_sg_len - 1));
+ to_process = to_process & ~(SHA256_BLOCK_SIZE - 1);
+ leftover = total - to_process;
+
+ if (sctx->count) {
+ in_sg = nx_build_sg_list(nx_ctx->in_sg,
+ (u8 *) sctx->buf,
+ sctx->count, max_sg_len);
+ }
+ in_sg = nx_build_sg_list(in_sg, (u8 *) data,
to_process - sctx->count,
- nx_ctx->ap->sglen);
+ max_sg_len);
nx_ctx->op.inlen = (nx_ctx->in_sg - in_sg) *
sizeof(struct nx_sg);
- } else {
- in_sg = nx_build_sg_list(nx_ctx->in_sg, (u8 *)data,
- to_process, nx_ctx->ap->sglen);
- nx_ctx->op.inlen = (nx_ctx->in_sg - in_sg) *
- sizeof(struct nx_sg);
- }
- NX_CPB_FDM(csbcpb) |= NX_FDM_INTERMEDIATE;
+ if (NX_CPB_FDM(csbcpb) & NX_FDM_CONTINUATION) {
+ /*
+ * we've hit the nx chip previously and we're updating
+ * again, so copy over the partial digest.
+ */
+ memcpy(csbcpb->cpb.sha256.input_partial_digest,
+ csbcpb->cpb.sha256.message_digest,
+ SHA256_DIGEST_SIZE);
+ }
+
+ NX_CPB_FDM(csbcpb) |= NX_FDM_INTERMEDIATE;
+ if (!nx_ctx->op.inlen || !nx_ctx->op.outlen) {
+ rc = -EINVAL;
+ goto out;
+ }
+
+ rc = nx_hcall_sync(nx_ctx, &nx_ctx->op,
+ desc->flags & CRYPTO_TFM_REQ_MAY_SLEEP);
+ if (rc)
+ goto out;
- if (!nx_ctx->op.inlen || !nx_ctx->op.outlen) {
- rc = -EINVAL;
- goto out;
- }
+ atomic_inc(&(nx_ctx->stats->sha256_ops));
+ csbcpb->cpb.sha256.message_bit_length += (u64)
+ (csbcpb->cpb.sha256.spbc * 8);
- rc = nx_hcall_sync(nx_ctx, &nx_ctx->op,
- desc->flags & CRYPTO_TFM_REQ_MAY_SLEEP);
- if (rc)
- goto out;
+ /* everything after the first update is continuation */
+ NX_CPB_FDM(csbcpb) |= NX_FDM_CONTINUATION;
- atomic_inc(&(nx_ctx->stats->sha256_ops));
+ total -= to_process;
+ data += to_process;
+ sctx->count = 0;
+ in_sg = nx_ctx->in_sg;
+ } while (leftover >= SHA256_BLOCK_SIZE);
/* copy the leftover back into the state struct */
if (leftover)
- memcpy(sctx->buf, data + len - leftover, leftover);
+ memcpy(sctx->buf, data, leftover);
sctx->count = leftover;
-
- csbcpb->cpb.sha256.message_bit_length += (u64)
- (csbcpb->cpb.sha256.spbc * 8);
-
- /* everything after the first update is continuation */
- NX_CPB_FDM(csbcpb) |= NX_FDM_CONTINUATION;
out:
return rc;
}
@@ -129,8 +145,10 @@ static int nx_sha256_final(struct shash_desc *desc, u8 *out)
struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(&desc->tfm->base);
struct nx_csbcpb *csbcpb = (struct nx_csbcpb *)nx_ctx->csbcpb;
struct nx_sg *in_sg, *out_sg;
+ u32 max_sg_len;
int rc;
+ max_sg_len = min_t(u32, nx_driver.of.max_sg_len, nx_ctx->ap->sglen);
if (NX_CPB_FDM(csbcpb) & NX_FDM_CONTINUATION) {
/* we've hit the nx chip previously, now we're finalizing,
@@ -146,9 +164,9 @@ static int nx_sha256_final(struct shash_desc *desc, u8 *out)
csbcpb->cpb.sha256.message_bit_length += (u64)(sctx->count * 8);
in_sg = nx_build_sg_list(nx_ctx->in_sg, (u8 *)sctx->buf,
- sctx->count, nx_ctx->ap->sglen);
+ sctx->count, max_sg_len);
out_sg = nx_build_sg_list(nx_ctx->out_sg, out, SHA256_DIGEST_SIZE,
- nx_ctx->ap->sglen);
+ max_sg_len);
nx_ctx->op.inlen = (nx_ctx->in_sg - in_sg) * sizeof(struct nx_sg);
nx_ctx->op.outlen = (nx_ctx->out_sg - out_sg) * sizeof(struct nx_sg);
diff --git a/drivers/crypto/nx/nx-sha512.c b/drivers/crypto/nx/nx-sha512.c
index 08eee11..2d6d913 100644
--- a/drivers/crypto/nx/nx-sha512.c
+++ b/drivers/crypto/nx/nx-sha512.c
@@ -55,72 +55,88 @@ static int nx_sha512_update(struct shash_desc *desc, const u8 *data,
struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(&desc->tfm->base);
struct nx_csbcpb *csbcpb = (struct nx_csbcpb *)nx_ctx->csbcpb;
struct nx_sg *in_sg;
- u64 to_process, leftover, spbc_bits;
+ u64 to_process, leftover, total, spbc_bits;
+ u32 max_sg_len;
int rc = 0;
- if (NX_CPB_FDM(csbcpb) & NX_FDM_CONTINUATION) {
- /* we've hit the nx chip previously and we're updating again,
- * so copy over the partial digest */
- memcpy(csbcpb->cpb.sha512.input_partial_digest,
- csbcpb->cpb.sha512.message_digest, SHA512_DIGEST_SIZE);
- }
-
/* 2 cases for total data len:
- * 1: <= SHA512_BLOCK_SIZE: copy into state, return 0
- * 2: > SHA512_BLOCK_SIZE: process X blocks, copy in leftover
+ * 1: < SHA512_BLOCK_SIZE: copy into state, return 0
+ * 2: >= SHA512_BLOCK_SIZE: process X blocks, copy in leftover
*/
- if ((u64)len + sctx->count[0] < SHA512_BLOCK_SIZE) {
+ total = sctx->count[0] + len;
+ if (total < SHA512_BLOCK_SIZE) {
memcpy(sctx->buf + sctx->count[0], data, len);
sctx->count[0] += len;
goto out;
}
- /* to_process: the SHA512_BLOCK_SIZE data chunk to process in this
- * update */
- to_process = (sctx->count[0] + len) & ~(SHA512_BLOCK_SIZE - 1);
- leftover = (sctx->count[0] + len) & (SHA512_BLOCK_SIZE - 1);
+ in_sg = nx_ctx->in_sg;
+ max_sg_len = min_t(u32, nx_driver.of.max_sg_len/sizeof(struct nx_sg),
+ nx_ctx->ap->sglen);
- if (sctx->count[0]) {
- in_sg = nx_build_sg_list(nx_ctx->in_sg, (u8 *)sctx->buf,
- sctx->count[0], nx_ctx->ap->sglen);
- in_sg = nx_build_sg_list(in_sg, (u8 *)data,
+ do {
+ /*
+ * to_process: the SHA512_BLOCK_SIZE data chunk to process in
+ * this update. This value is also restricted by the sg list
+ * limits.
+ */
+ to_process = min_t(u64, total, nx_ctx->ap->databytelen);
+ to_process = min_t(u64, to_process,
+ NX_PAGE_SIZE * (max_sg_len - 1));
+ to_process = to_process & ~(SHA512_BLOCK_SIZE - 1);
+ leftover = total - to_process;
+
+ if (sctx->count[0]) {
+ in_sg = nx_build_sg_list(nx_ctx->in_sg,
+ (u8 *) sctx->buf,
+ sctx->count[0], max_sg_len);
+ }
+ in_sg = nx_build_sg_list(in_sg, (u8 *) data,
to_process - sctx->count[0],
- nx_ctx->ap->sglen);
+ max_sg_len);
nx_ctx->op.inlen = (nx_ctx->in_sg - in_sg) *
sizeof(struct nx_sg);
- } else {
- in_sg = nx_build_sg_list(nx_ctx->in_sg, (u8 *)data,
- to_process, nx_ctx->ap->sglen);
- nx_ctx->op.inlen = (nx_ctx->in_sg - in_sg) *
- sizeof(struct nx_sg);
- }
- NX_CPB_FDM(csbcpb) |= NX_FDM_INTERMEDIATE;
+ if (NX_CPB_FDM(csbcpb) & NX_FDM_CONTINUATION) {
+ /*
+ * we've hit the nx chip previously and we're updating
+ * again, so copy over the partial digest.
+ */
+ memcpy(csbcpb->cpb.sha512.input_partial_digest,
+ csbcpb->cpb.sha512.message_digest,
+ SHA512_DIGEST_SIZE);
+ }
+
+ NX_CPB_FDM(csbcpb) |= NX_FDM_INTERMEDIATE;
+ if (!nx_ctx->op.inlen || !nx_ctx->op.outlen) {
+ rc = -EINVAL;
+ goto out;
+ }
+
+ rc = nx_hcall_sync(nx_ctx, &nx_ctx->op,
+ desc->flags & CRYPTO_TFM_REQ_MAY_SLEEP);
+ if (rc)
+ goto out;
- if (!nx_ctx->op.inlen || !nx_ctx->op.outlen) {
- rc = -EINVAL;
- goto out;
- }
+ atomic_inc(&(nx_ctx->stats->sha512_ops));
+ spbc_bits = csbcpb->cpb.sha512.spbc * 8;
+ csbcpb->cpb.sha512.message_bit_length_lo += spbc_bits;
+ if (csbcpb->cpb.sha512.message_bit_length_lo < spbc_bits)
+ csbcpb->cpb.sha512.message_bit_length_hi++;
- rc = nx_hcall_sync(nx_ctx, &nx_ctx->op,
- desc->flags & CRYPTO_TFM_REQ_MAY_SLEEP);
- if (rc)
- goto out;
+ /* everything after the first update is continuation */
+ NX_CPB_FDM(csbcpb) |= NX_FDM_CONTINUATION;
- atomic_inc(&(nx_ctx->stats->sha512_ops));
+ total -= to_process;
+ data += to_process;
+ sctx->count[0] = 0;
+ in_sg = nx_ctx->in_sg;
+ } while (leftover >= SHA512_BLOCK_SIZE);
/* copy the leftover back into the state struct */
if (leftover)
- memcpy(sctx->buf, data + len - leftover, leftover);
+ memcpy(sctx->buf, data, leftover);
sctx->count[0] = leftover;
-
- spbc_bits = csbcpb->cpb.sha512.spbc * 8;
- csbcpb->cpb.sha512.message_bit_length_lo += spbc_bits;
- if (csbcpb->cpb.sha512.message_bit_length_lo < spbc_bits)
- csbcpb->cpb.sha512.message_bit_length_hi++;
-
- /* everything after the first update is continuation */
- NX_CPB_FDM(csbcpb) |= NX_FDM_CONTINUATION;
out:
return rc;
}
@@ -131,9 +147,12 @@ static int nx_sha512_final(struct shash_desc *desc, u8 *out)
struct nx_crypto_ctx *nx_ctx = crypto_tfm_ctx(&desc->tfm->base);
struct nx_csbcpb *csbcpb = (struct nx_csbcpb *)nx_ctx->csbcpb;
struct nx_sg *in_sg, *out_sg;
+ u32 max_sg_len;
u64 count0;
int rc;
+ max_sg_len = min_t(u32, nx_driver.of.max_sg_len, nx_ctx->ap->sglen);
+
if (NX_CPB_FDM(csbcpb) & NX_FDM_CONTINUATION) {
/* we've hit the nx chip previously, now we're finalizing,
* so copy over the partial digest */
@@ -152,9 +171,9 @@ static int nx_sha512_final(struct shash_desc *desc, u8 *out)
csbcpb->cpb.sha512.message_bit_length_hi++;
in_sg = nx_build_sg_list(nx_ctx->in_sg, sctx->buf, sctx->count[0],
- nx_ctx->ap->sglen);
+ max_sg_len);
out_sg = nx_build_sg_list(nx_ctx->out_sg, out, SHA512_DIGEST_SIZE,
- nx_ctx->ap->sglen);
+ max_sg_len);
nx_ctx->op.inlen = (nx_ctx->in_sg - in_sg) * sizeof(struct nx_sg);
nx_ctx->op.outlen = (nx_ctx->out_sg - out_sg) * sizeof(struct nx_sg);
--
1.7.12
^ permalink raw reply related
* Re: therm_pm72 units, interface
From: Benjamin Herrenschmidt @ 2013-08-02 12:51 UTC (permalink / raw)
To: Michel Dänzer
Cc: Ben Hutchings, Jan Engelhardt, linuxppc-dev, Aaro Koskinen
In-Reply-To: <1375437816.3852.12.camel@thor.local>
On Fri, 2013-08-02 at 12:03 +0200, Michel Dänzer wrote:
> Could a similar change fix the same problem on desktop G5s? The same
> values for slots_param in windfarm_pm112.c don't help, unfortunately.
You have a 11,2 and a noisy fan ? Odd, mine(s) don't.... I can dbl check
the values vs. what Darwin uses tomorrow...
The one that is known to have a noisy slot fan is the 7,2/7,3 one
because the Apple algorithm relies on sensors on the video card to
control the slots fan and I don't have the infrastructure for that in
Linux, so I set it to a fixed speed.
But the 11,2 should be fine.
Cheers,
Ben.
^ permalink raw reply
* Re: therm_pm72 units, interface
From: Michel Dänzer @ 2013-08-02 14:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Ben Hutchings, Jan Engelhardt, linuxppc-dev
In-Reply-To: <1375447861.15999.1.camel@pasglop>
On Fre, 2013-08-02 at 22:51 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2013-08-02 at 12:03 +0200, Michel D=C3=A4nzer wrote:
> > Could a similar change fix the same problem on desktop G5s? The same
> > values for slots_param in windfarm_pm112.c don't help, unfortunately.
>=20
> You have a 11,2 and a noisy fan ? Odd, mine(s) don't.... I can dbl check
> the values vs. what Darwin uses tomorrow...
Yes, see /proc/cpuinfo below.
With older kernels (currently still using Debian's 3.2.0-4-powerpc64
because of this problem), the fans go basically silent as soon as the
windfarm modules are loaded. With current kernels, the fans stay at the
level OF sets them to, until after a while they go into 'airplane mode'.
One thing I notice now is that the lines like
[ 9.539173] windfarm: CPUs control loops started.
[ 16.209962] windfarm: Backside control loop started.
[ 16.262274] windfarm: Slots control loop started.
[ 16.371642] windfarm: Drive bay control loop started.
no longer appear in dmesg with current kernels. Should they?
processor : 0
cpu : PPC970MP, altivec supported
clock : 2500.000000MHz
revision : 1.1 (pvr 0044 0101)
processor : 1
cpu : PPC970MP, altivec supported
clock : 2500.000000MHz
revision : 1.1 (pvr 0044 0101)
processor : 2
cpu : PPC970MP, altivec supported
clock : 2500.000000MHz
revision : 1.1 (pvr 0044 0101)
processor : 3
cpu : PPC970MP, altivec supported
clock : 2500.000000MHz
revision : 1.1 (pvr 0044 0101)
timebase : 33333333
platform : PowerMac
model : PowerMac11,2
machine : PowerMac11,2
motherboard : PowerMac11,2 MacRISC4 Power Macintosh=20
detected as : 337 (PowerMac G5 Dual Core)
pmac flags : 00000000
L2 cache : 1024K unified
pmac-generation : NewWorld
--=20
Earthling Michel D=C3=A4nzer | http://www.amd.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: Inbound PCI and Memory Corruption
From: Peter LaDow @ 2013-08-02 15:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <CAN8Q1EeAaL-WnRPh77CNQBw3mH+Q2ejFhLKzBMimWu1w37bgcg@mail.gmail.com>
On Wed, Jul 24, 2013 at 11:13 PM, Peter LaDow <petela@gocougs.wsu.edu> wrote:
> There are other items, such as drivers for our custom hardware modules
> implemented on the FPGA. Perhaps I'll pull our drivers and run a
> stock kernel. Maybe a stock 83xx configuration (such as the
> MPC8349E-MITX). If we have problems even on a stock configuration...
Well, that didn't work either. Unfortunately, the PCI slot on our
MPC8349E-MITX eval kit doesn't work. It doesn't matter what card I
plug into that slot neither uboot, nor the kernel, recognize anything.
But I did have one thought. Is it possible that somehow the
configured incoming PCI regions are marked as pre-fetchable, and the
e1000 is prefetching the descriptors? Then at some later point the
kernel changes things with the e1000 unaware?
Thanks,
Pete
^ permalink raw reply
* Re: therm_pm72 units, interface
From: Aaro Koskinen @ 2013-08-02 15:58 UTC (permalink / raw)
To: Michel Dänzer; +Cc: Jan Engelhardt, Ben Hutchings, linuxppc-dev
In-Reply-To: <1375454871.3852.27.camel@thor.local>
On Fri, Aug 02, 2013 at 04:47:51PM +0200, Michel Dänzer wrote:
> On Fre, 2013-08-02 at 22:51 +1000, Benjamin Herrenschmidt wrote:
> > On Fri, 2013-08-02 at 12:03 +0200, Michel Dänzer wrote:
> > > Could a similar change fix the same problem on desktop G5s? The same
> > > values for slots_param in windfarm_pm112.c don't help, unfortunately.
> >
> > You have a 11,2 and a noisy fan ? Odd, mine(s) don't.... I can dbl check
> > the values vs. what Darwin uses tomorrow...
>
> Yes, see /proc/cpuinfo below.
>
> With older kernels (currently still using Debian's 3.2.0-4-powerpc64
> because of this problem), the fans go basically silent as soon as the
> windfarm modules are loaded. With current kernels, the fans stay at the
> level OF sets them to, until after a while they go into 'airplane mode'.
>
> One thing I notice now is that the lines like
>
> [ 9.539173] windfarm: CPUs control loops started.
> [ 16.209962] windfarm: Backside control loop started.
> [ 16.262274] windfarm: Slots control loop started.
> [ 16.371642] windfarm: Drive bay control loop started.
>
> no longer appear in dmesg with current kernels. Should they?
Yes. They are printed once all the sensor and control modules are
loaded and registered. If the loops are not started, it's basically
doing nothing. Maybe something goes wrong in module loading? What lsmod
is showing?
A.
^ permalink raw reply
* Re: therm_pm72 units, interface
From: Michel Dänzer @ 2013-08-02 16:52 UTC (permalink / raw)
To: Aaro Koskinen; +Cc: Jan Engelhardt, Ben Hutchings, linuxppc-dev
In-Reply-To: <20130802155818.GB29933@blackmetal.musicnaut.iki.fi>
On Fre, 2013-08-02 at 18:58 +0300, Aaro Koskinen wrote:
> On Fri, Aug 02, 2013 at 04:47:51PM +0200, Michel D=C3=A4nzer wrote:
> > On Fre, 2013-08-02 at 22:51 +1000, Benjamin Herrenschmidt wrote:
> > > On Fri, 2013-08-02 at 12:03 +0200, Michel D=C3=A4nzer wrote:
> > > > Could a similar change fix the same problem on desktop G5s? The sam=
e
> > > > values for slots_param in windfarm_pm112.c don't help, unfortunatel=
y.
> > >=20
> > > You have a 11,2 and a noisy fan ? Odd, mine(s) don't.... I can dbl ch=
eck
> > > the values vs. what Darwin uses tomorrow...
> >=20
> > Yes, see /proc/cpuinfo below.
> >=20
> > With older kernels (currently still using Debian's 3.2.0-4-powerpc64
> > because of this problem), the fans go basically silent as soon as the
> > windfarm modules are loaded. With current kernels, the fans stay at the
> > level OF sets them to, until after a while they go into 'airplane mode'=
.
> >=20
> > One thing I notice now is that the lines like
> >=20
> > [ 9.539173] windfarm: CPUs control loops started.
> > [ 16.209962] windfarm: Backside control loop started.
> > [ 16.262274] windfarm: Slots control loop started.
> > [ 16.371642] windfarm: Drive bay control loop started.
> >=20
> > no longer appear in dmesg with current kernels. Should they?
>=20
> Yes. They are printed once all the sensor and control modules are
> loaded and registered. If the loops are not started, it's basically
> doing nothing. Maybe something goes wrong in module loading? What lsmod
> is showing?
Thanks for the suggestion. The same windfarm modules were loaded in both
cases, but i2c_powermac wasn't loaded with the newer kernels. Loading it
manually fixes the problem.
How is i2c_powermac supposed to get loaded with current kernels?
--=20
Earthling Michel D=C3=A4nzer | http://www.amd.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: [PATCH 1/8] register bootmem pages for powerpc when sparse vmemmap is not defined
From: Nathan Fontenot @ 2013-08-02 19:04 UTC (permalink / raw)
To: Michael Ellerman
Cc: linux-mm, isimatu.yasuaki, linuxppc-dev, LKML, Greg Kroah-Hartman
In-Reply-To: <20130802022703.GA1680@concordia>
On 08/01/2013 09:27 PM, Michael Ellerman wrote:
> On Wed, Jul 24, 2013 at 01:35:11PM -0500, Nathan Fontenot wrote:
>> Previous commit 46723bfa540... introduced a new config option
>> HAVE_BOOTMEM_INFO_NODE that ended up breaking memory hot-remove for powerpc
>> when sparse vmemmap is not defined.
>
> So that's a bug fix that should go into 3.10 stable?
>
Yes, I believe this one as well as patch 2/8 should go into 3.10 stable.
I'll re-send with linux stable added.
-Nathan
^ permalink raw reply
* Re: [PATCH 2/8] Mark powerpc memory resources as busy
From: Nathan Fontenot @ 2013-08-02 19:05 UTC (permalink / raw)
To: Michael Ellerman
Cc: linux-mm, isimatu.yasuaki, linuxppc-dev, LKML, Greg Kroah-Hartman
In-Reply-To: <20130802022827.GB1680@concordia>
On 08/01/2013 09:28 PM, Michael Ellerman wrote:
> On Wed, Jul 24, 2013 at 01:36:34PM -0500, Nathan Fontenot wrote:
>> Memory I/O resources need to be marked as busy or else we cannot remove
>> them when doing memory hot remove.
>
> I would have thought it was the opposite?
Me too.
As it turns out the code in kernel/resource.c checks to make sure the
IORESOURCE_BUSY flag is set when trying to release a resource.
-Nathan
^ permalink raw reply
* windfarm_fcu_controls: cpu-pump-0 <HW FAULT>
From: Andreas Schwab @ 2013-08-02 19:08 UTC (permalink / raw)
To: linuxppc-dev
wf_fcu_fan_get_rpm is returning EFAULT when reading the values for the
cpu pump controls on the PowerMac7,3. Also, wf_fcu_get_pump_minmax is
unable to get the real limits and falls back to using the defaults.
Here is the output when DEBUG is defined:
wf_fcu: FCU Initialized, RPM fan shift is 3
Looking up FCU controls in device-tree...
control: rpm0, type: fan-rpm-control
matching location: CPU B PUMP, reg: 0x00000010
location match, name: cpu-pump-1
wf_fcu: pump min/max for cpu-pump-1 set to: [1250..3200] RPM
wf_pm72: Liquid cooling pump(s) detected, using new algorithm !
control: rpm1, type: fan-rpm-control
matching location: CPU A PUMP, reg: 0x00000012
location match, name: cpu-pump-0
wf_fcu: pump min/max for cpu-pump-0 set to: [1250..3200] RPM
control: rpm2, type: fan-rpm-control
matching location: DRIVE BAY, reg: 0x00000014
location match, name: drive-bay-fan
wf_fcu: fan min/max for drive-bay-fan set to: [300..7000] RPM
control: rpm3, type: fan-rpm-control
matching location: CPU A INTAKE, reg: 0x00000016
location match, name: cpu-front-fan-0
wf_fcu: fan min/max for cpu-front-fan-0 set to: [300..3200] RPM
control: rpm4, type: fan-rpm-control
matching location: CPU A EXHAUST, reg: 0x00000018
location match, name: cpu-rear-fan-0
wf_fcu: fan min/max for cpu-rear-fan-0 set to: [300..3200] RPM
control: rpm5, type: fan-rpm-control
matching location: CPU B INTAKE, reg: 0x0000001a
location match, name: cpu-front-fan-1
wf_fcu: fan min/max for cpu-front-fan-1 set to: [300..3200] RPM
control: rpm6, type: fan-rpm-control
matching location: CPU B EXHAUST, reg: 0x0000001c
location match, name: cpu-rear-fan-1
wf_fcu: fan min/max for cpu-rear-fan-1 set to: [300..3200] RPM
control: pwm1, type: fan-pwm-control
matching location: BACKSIDE, reg: 0x00000032
location match, name: backside-fan
control: pwm2, type: fan-pwm-control
matching location: SLOT, reg: 0x00000034
location match, name: slots-fan
control: adc0, type: power-sensor
control: adc1, type: power-sensor
control: adc2, type: power-sensor
control: adc3, type: power-sensor
control: gpi0, type: gpi-sensor
control: gpi1, type: gpi-sensor
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH 3/8] Add all memory via sysfs probe interface at once
From: Nathan Fontenot @ 2013-08-02 19:13 UTC (permalink / raw)
To: Michael Ellerman
Cc: linux-mm, isimatu.yasuaki, linuxppc-dev, LKML, Greg Kroah-Hartman
In-Reply-To: <20130802023259.GC1680@concordia>
On 08/01/2013 09:32 PM, Michael Ellerman wrote:
> On Wed, Jul 24, 2013 at 01:37:47PM -0500, Nathan Fontenot wrote:
>> When doing memory hot add via the 'probe' interface in sysfs we do not
>> need to loop through and add memory one section at a time. I think this
>> was originally done for powerpc, but is not needed. This patch removes
>> the loop and just calls add_memory for all of the memory to be added.
>
> Looks like memory hot add is supported on ia64, x86, sh, powerpc and
> s390. Have you tested on any?
I have tested on powerpc. I would love to say I tested on the other
platforms... but I haven't. I should be able to get a x86 box to test
on but the other architectures may not be possible.
-Nathan
^ permalink raw reply
* Re: [PATCH V3 0/3] networking: Use ETH_ALEN where appropriate
From: David Miller @ 2013-08-02 19:34 UTC (permalink / raw)
To: joe
Cc: wimax, netdev, linux-usb, linux-kernel, virtualization,
netfilter-devel, linuxppc-dev, linux-arm-kernel, linux-media
In-Reply-To: <cover.1375398692.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Thu, 1 Aug 2013 16:17:46 -0700
> Convert the uses mac addresses to ETH_ALEN so
> it's easier to find and verify where mac addresses
> need to be __aligned(2)
Series applied to net-next, thanks.
^ permalink raw reply
* Re: therm_pm72 units, interface
From: Benjamin Herrenschmidt @ 2013-08-02 20:47 UTC (permalink / raw)
To: Michel Dänzer; +Cc: Ben Hutchings, Jan Engelhardt, linuxppc-dev
In-Reply-To: <1375454871.3852.27.camel@thor.local>
On Fri, 2013-08-02 at 16:47 +0200, Michel Dänzer wrote:
> On Fre, 2013-08-02 at 22:51 +1000, Benjamin Herrenschmidt wrote:
> > On Fri, 2013-08-02 at 12:03 +0200, Michel Dänzer wrote:
> > > Could a similar change fix the same problem on desktop G5s? The same
> > > values for slots_param in windfarm_pm112.c don't help, unfortunately.
> >
> > You have a 11,2 and a noisy fan ? Odd, mine(s) don't.... I can dbl check
> > the values vs. what Darwin uses tomorrow...
>
> Yes, see /proc/cpuinfo below.
>
> With older kernels (currently still using Debian's 3.2.0-4-powerpc64
> because of this problem), the fans go basically silent as soon as the
> windfarm modules are loaded. With current kernels, the fans stay at the
> level OF sets them to, until after a while they go into 'airplane mode'.
>
> One thing I notice now is that the lines like
>
> [ 9.539173] windfarm: CPUs control loops started.
> [ 16.209962] windfarm: Backside control loop started.
> [ 16.262274] windfarm: Slots control loop started.
> [ 16.371642] windfarm: Drive bay control loop started.
>
> no longer appear in dmesg with current kernels. Should they?
Yes. Do you have all the windfarm modules loaded ? What about
i2c-powermac ? (It's typical that the latter is missed, I think it
doesn't auto-load, which we never fixed, we used to request distros to
just built it in)
Ben.
>
> processor : 0
> cpu : PPC970MP, altivec supported
> clock : 2500.000000MHz
> revision : 1.1 (pvr 0044 0101)
>
> processor : 1
> cpu : PPC970MP, altivec supported
> clock : 2500.000000MHz
> revision : 1.1 (pvr 0044 0101)
>
> processor : 2
> cpu : PPC970MP, altivec supported
> clock : 2500.000000MHz
> revision : 1.1 (pvr 0044 0101)
>
> processor : 3
> cpu : PPC970MP, altivec supported
> clock : 2500.000000MHz
> revision : 1.1 (pvr 0044 0101)
>
> timebase : 33333333
> platform : PowerMac
> model : PowerMac11,2
> machine : PowerMac11,2
> motherboard : PowerMac11,2 MacRISC4 Power Macintosh
> detected as : 337 (PowerMac G5 Dual Core)
> pmac flags : 00000000
> L2 cache : 1024K unified
> pmac-generation : NewWorld
>
>
^ permalink raw reply
* [PATCH] drivers/crypto/nx: saves chaining value from co-processor
From: Fionnuala Gunter @ 2013-08-02 20:58 UTC (permalink / raw)
To: linuxppc-dev
The chaining value from co-processor was not being saved. This value is
needed because it is used as the IV, for example by cts i.e.
cts(cbc(aes)).
Signed-off-by: Fionnuala Gunter <fin@linux.vnet.ibm.com>
Signed-off-by: Marcelo Cerri <mhcerri@linux.vnet.ibm.com>
---
drivers/crypto/nx/nx-aes-cbc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/nx/nx-aes-cbc.c
b/drivers/crypto/nx/nx-aes-cbc.c
index 35d483f..a2f99a9 100644
--- a/drivers/crypto/nx/nx-aes-cbc.c
+++ b/drivers/crypto/nx/nx-aes-cbc.c
@@ -95,6 +95,7 @@ static int cbc_aes_nx_crypt(struct blkcipher_desc
*desc,
if (rc)
goto out;
+ memcpy(desc->info, csbcpb->cpb.aes_cbc.cv, AES_BLOCK_SIZE);
atomic_inc(&(nx_ctx->stats->aes_ops));
atomic64_add(csbcpb->csb.processed_byte_count,
&(nx_ctx->stats->aes_bytes));
--
1.7.10.4
^ permalink raw reply related
* Re: therm_pm72 units, interface
From: Benjamin Herrenschmidt @ 2013-08-02 21:02 UTC (permalink / raw)
To: Michel Dänzer
Cc: linuxppc-dev, Jan Engelhardt, Ben Hutchings, Aaro Koskinen
In-Reply-To: <1375462346.3852.42.camel@thor.local>
On Fri, 2013-08-02 at 18:52 +0200, Michel Dänzer wrote:
> Thanks for the suggestion. The same windfarm modules were loaded in both
> cases, but i2c_powermac wasn't loaded with the newer kernels. Loading it
> manually fixes the problem.
>
> How is i2c_powermac supposed to get loaded with current kernels?
It's a platform driver, but it's missing a module device-table
Can you try this completely untested patch ?
diff --git a/drivers/i2c/busses/i2c-powermac.c b/drivers/i2c/busses/i2c-powermac.c
index 8dc90da..5af5153 100644
--- a/drivers/i2c/busses/i2c-powermac.c
+++ b/drivers/i2c/busses/i2c-powermac.c
@@ -458,9 +458,15 @@ static int i2c_powermac_probe(struct platform_device *dev)
return rc;
}
+static const struct platform_device_id i2c_powermac_id = {
+ .name = "i2c-powermac"
+};
+MODULE_DEVICE_TABLE(platform, i2c_powermac_id);
+
static struct platform_driver i2c_powermac_driver = {
.probe = i2c_powermac_probe,
.remove = i2c_powermac_remove,
+ .id_table = *i2c_powermac_id,
.driver = {
.name = "i2c-powermac",
.bus = &platform_bus_type,
@@ -468,5 +474,3 @@ static struct platform_driver i2c_powermac_driver = {
};
module_platform_driver(i2c_powermac_driver);
-
-MODULE_ALIAS("platform:i2c-powermac");
^ permalink raw reply related
* Re: therm_pm72 units, interface
From: Benjamin Herrenschmidt @ 2013-08-02 21:04 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Michel Dänzer, linuxppc-dev, Jan Engelhardt
In-Reply-To: <1375477013.32254.22.camel@deadeye.wl.decadent.org.uk>
On Fri, 2013-08-02 at 22:56 +0200, Ben Hutchings wrote:
> > Yes. Do you have all the windfarm modules loaded ? What about
> > i2c-powermac ? (It's typical that the latter is missed, I think it
> > doesn't auto-load, which we never fixed, we used to request distros
> to
> > just built it in)
>
> We built it as a module in 3.2 and we still do. The regression
> apparently occurred between 3.8 and 3.9.
Interesting. Maybe the old MODULE_ALIAS statement in there no longer
work....
Ben.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox