* Re: [4/5] IBM Akebono: Add the Akebono platform
From: Paul Bolle @ 2014-09-04 22:29 UTC (permalink / raw)
To: Alistair Popple; +Cc: linuxppc-dev, linux-kernel, devicetree
In-Reply-To: <10214508.Vq3Ynjy2Co@mexican>
Hi Alistair,
On Fri, 2014-05-02 at 10:35 +1000, Alistair Popple wrote:
> On Thu, 1 May 2014 11:27:27 Paul Bolle wrote:
> > On Thu, 2014-03-06 at 14:52 +1100, Alistair Popple wrote:
> > > This patch adds support for the IBM Akebono board.
> > > + select IBM_EMAC_RGMII_WOL
> >
> > The patch that added this symbol (and the related driver) was submitted
> > in https://lkml.org/lkml/2014/2/21/25 . It's not (yet) included in
> > linux-next. Is it queued somewhere else?
>
> To be honest I'm not sure. I will follow this up on the netdev list.
I noticed that this symbol (and its driver) are still not in v3.17-rc3
nor in next-20140904. Any update on this?
Thanks,
Paul Bolle
^ permalink raw reply
* Re: bit fields && data tearing
From: H. Peter Anvin @ 2014-09-04 22:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt, David Laight
Cc: Jakub Jelinek, linux-arch@vger.kernel.org, Tony Luck,
linux-ia64@vger.kernel.org, Peter Hurley, Oleg Nesterov,
linux-kernel@vger.kernel.org, Paul Mackerras, Paul E. McKenney,
linuxppc-dev@lists.ozlabs.org, Miroslav Franc, Richard Henderson
In-Reply-To: <1409824374.4246.62.camel@pasglop>
On 09/04/2014 02:52 AM, Benjamin Herrenschmidt wrote:
>
> Yeah correct, alpha and bytes right ? Is there any other ? That's why I
> suggested int.
>
Even for Alpha it is only the 21064 AFAIK.
-hpa
^ permalink raw reply
* Re: bit fields && data tearing
From: H. Peter Anvin @ 2014-09-04 22:16 UTC (permalink / raw)
To: Peter Hurley, One Thousand Gnomes
Cc: Jakub Jelinek, Mikael Pettersson, Tony Luck, linux-ia64,
Oleg Nesterov, linux-kernel, Paul Mackerras, linux-arch,
Paul E. McKenney, linuxppc-dev, Miroslav Franc, Richard Henderson
In-Reply-To: <5408C0AB.6050801@hurleysoftware.com>
On 09/04/2014 12:42 PM, Peter Hurley wrote:
>
> Or we could give up on the Alpha.
>
If Alpha is turning into Voyager (kept alive only as a museum piece, but
actively causing problems) then please let's kill it.
-hpa
^ permalink raw reply
* Re: [PATCH v2] QE: move qe code from arch/powerpc to drivers/soc
From: Scott Wood @ 2014-09-04 22:46 UTC (permalink / raw)
To: Zhao Qiang; +Cc: B07421, linuxppc-dev, linux-kernel, R63061
In-Reply-To: <1409807186-45816-1-git-send-email-B45475@freescale.com>
On Thu, 2014-09-04 at 13:06 +0800, Zhao Qiang wrote:
> LS1 is arm cpu and it has qe ip block.
> move qe code from platform directory to public directory.
>
> QE is an IP block integrates several comunications peripheral
> controllers. It can implement a variety of applications, such
> as uart, usb and tdm and so on.
>
> Signed-off-by: Zhao Qiang <B45475@freescale.com>
> ---
> Changes for v2:
> - mv code to drivers/soc
Who will be the maintainer of this code once it lives in drivers/soc,
especially once it is no longer used only by PPC?
> 44 files changed, 113 insertions(+), 113 deletions(-)
> delete mode 100644 arch/powerpc/sysdev/qe_lib/Kconfig
> create mode 100644 drivers/soc/qe/Kconfig
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/qe}/Makefile (100%)
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/qe}/gpio.c (99%)
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/qe}/qe.c (99%)
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/qe}/qe_ic.c (99%)
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/qe}/qe_ic.h (98%)
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/qe}/qe_io.c (99%)
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/qe}/ucc.c (98%)
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/qe}/ucc_fast.c (98%)
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/qe}/ucc_slow.c (98%)
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/qe}/usb.c (96%)
drivers/soc/fsl-qe
> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
> index 0f7c447..5da1a482 100644
> --- a/drivers/soc/Makefile
> +++ b/drivers/soc/Makefile
> @@ -3,3 +3,5 @@
> #
>
> obj-$(CONFIG_ARCH_QCOM) += qcom/
> +
> +obj-$(CONFIG_QUICC_ENGINE) += qe/
Please keep the file consistent regarding tabs versus spaces.
Plus, why do you need a newline between them?
> diff --git a/drivers/soc/qe/Kconfig b/drivers/soc/qe/Kconfig
> new file mode 100644
> index 0000000..8b03ca2
> --- /dev/null
> +++ b/drivers/soc/qe/Kconfig
> @@ -0,0 +1,45 @@
> +#
> +# QE Communication options
> +#
> +config QUICC_ENGINE
> + bool "Freescale QUICC Engine (QE) Support"
> + depends on FSL_SOC && PPC32
> + select PPC_LIB_RHEAP
> + select CRC32
> + help
> + The QUICC Engine (QE) is a new generation of communications
> + coprocessors on Freescale embedded CPUs (akin to CPM in older chips).
> + Selecting this option means that you wish to build a kernel
> + for a machine with a QE coprocessor.
> +
> +config QE_GPIO
> + bool "QE GPIO support"
> + depends on QUICC_ENGINE
> + select ARCH_REQUIRE_GPIOLIB
> + help
> + Say Y here if you're going to use hardware that connects to the
> + QE GPIOs.
> +
> +config UCC_SLOW
> + bool
> + default y if SERIAL_QE
> + help
> + This option provides qe_lib support to UCC slow
> + protocols: UART, BISYNC, QMC
> +
> +config UCC_FAST
> + bool
> + default y if UCC_GETH
> + help
> + This option provides qe_lib support to UCC fast
> + protocols: HDLC, Ethernet, ATM, transparent
> +
> +config UCC
> + bool
> + default y if UCC_FAST || UCC_SLOW
> +
> +config QE_USB
> + bool
> + default y if USB_FSL_QE
> + help
> + QE USB Controller support
First could we give these names better namespacing?
-Scott
^ permalink raw reply
* Re: bit fields && data tearing
From: Paul E. McKenney @ 2014-09-05 0:17 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Jakub Jelinek, One Thousand Gnomes, Tony Luck, linux-ia64,
Peter Hurley, Mikael Pettersson, Oleg Nesterov, linux-kernel,
Paul Mackerras, linux-arch, linuxppc-dev, Miroslav Franc,
Richard Henderson
In-Reply-To: <5408E4A3.2060303@zytor.com>
On Thu, Sep 04, 2014 at 03:16:03PM -0700, H. Peter Anvin wrote:
> On 09/04/2014 12:42 PM, Peter Hurley wrote:
> >
> > Or we could give up on the Alpha.
> >
>
> If Alpha is turning into Voyager (kept alive only as a museum piece, but
> actively causing problems) then please let's kill it.
Sorry for being slow to join this thread, but I propose the following
patch. If we can remove support for all CPUs that to not support
direct access to bytes and shorts (which I would very much like to
see happen), I will remove the last non-guarantee.
Thanx, Paul
------------------------------------------------------------------------
documentation: Record limitations of bitfields and small variables
This commit documents the fact that it is not safe to use bitfields
as shared variables in synchronization algorithms.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index 87be0a8a78de..a28bfe4fd759 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -269,6 +269,26 @@ And there are a number of things that _must_ or _must_not_ be assumed:
STORE *(A + 4) = Y; STORE *A = X;
STORE {*A, *(A + 4) } = {X, Y};
+And there are anti-guarantees:
+
+ (*) These guarantees do not apply to bitfields, because compilers often
+ generate code to modify these using non-atomic read-modify-write
+ sequences. Do not attempt to use bitfields to synchronize parallel
+ algorithms.
+
+ (*) Even in cases where bitfields are protected by locks, all fields
+ in a given bitfield must be protected by one lock. If two fields
+ in a given bitfield are protected by different locks, the compiler's
+ non-atomic read-modify-write sequences can cause an update to one
+ field to corrupt the value of an adjacent field.
+
+ (*) These guarantees apply only to properly aligned and sized scalar
+ variables. "Properly sized" currently means "int" and "long",
+ because some CPU families do not support loads and stores of
+ other sizes. ("Some CPU families" is currently believed to
+ be only Alpha 21064. If this is actually the case, a different
+ non-guarantee is likely to be formulated.)
+
=========================
WHAT ARE MEMORY BARRIERS?
^ permalink raw reply related
* Re: bit fields && data tearing
From: Peter Hurley @ 2014-09-05 0:59 UTC (permalink / raw)
To: H. Peter Anvin, Benjamin Herrenschmidt, David Laight
Cc: Jakub Jelinek, linux-arch@vger.kernel.org, Tony Luck,
linux-ia64@vger.kernel.org, Oleg Nesterov,
linux-kernel@vger.kernel.org, Paul Mackerras, linux-alpha,
Paul E. McKenney, linuxppc-dev@lists.ozlabs.org, Miroslav Franc,
Richard Henderson
In-Reply-To: <5408E458.3@zytor.com>
[ +cc linux-alpha ]
On 09/04/2014 06:14 PM, H. Peter Anvin wrote:
> On 09/04/2014 02:52 AM, Benjamin Herrenschmidt wrote:
>>
>> Yeah correct, alpha and bytes right ? Is there any other ? That's why I
>> suggested int.
>>
>
> Even for Alpha it is only the 21064 AFAIK.
For -mcpu=ev5 (21164) and the following test
struct x {
long a;
char b;
char c;
char d;
char e;
};
void store_b(struct x *p) {
p->b = 1;
}
gcc generates:
void store_b(struct x *p) {
0: 08 00 30 a0 ldl t0,8(a0)
4: 01 f1 3f 44 andnot t0,0xff,t0
8: 01 34 20 44 or t0,0x1,t0
c: 08 00 30 b0 stl t0,8(a0)
10: 01 80 fa 6b ret
IOW, rmw on 3 adjacent bytes, which is bad :)
For -mcpu=ev56 (21164A), the generated code is:
void store_b(struct x *p) {
0: 01 00 3f 20 lda t0,1
4: 08 00 30 38 stb t0,8(a0)
8: 01 80 fa 6b ret
which is ok.
I have no idea how prevalent the ev56 is compared to the ev5.
Still we're talking about a chip that came out in 1996.
I still hate split caches though.
Regards,
Peter Hurley
^ permalink raw reply
* [PATCH] Make CONFIG_FHANDLE=y for all 64 bit powerpc defconfigs
From: Cyril Bur @ 2014-09-05 1:16 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Cyril Bur
CONFIG_FHANDLE is a requirement for systemd and with the increasing
uptake of systemd within distros it makes sense for 64 bit defconfigs
to include it.
Signed-off-by: Cyril Bur <cyril.bur@au1.ibm.com>
---
arch/powerpc/configs/cell_defconfig | 1 +
arch/powerpc/configs/celleb_defconfig | 1 +
arch/powerpc/configs/corenet64_smp_defconfig | 1 +
arch/powerpc/configs/g5_defconfig | 1 +
arch/powerpc/configs/maple_defconfig | 1 +
arch/powerpc/configs/pasemi_defconfig | 1 +
arch/powerpc/configs/ppc64_defconfig | 1 +
arch/powerpc/configs/ppc64e_defconfig | 1 +
arch/powerpc/configs/ps3_defconfig | 1 +
arch/powerpc/configs/pseries_defconfig | 1 +
arch/powerpc/configs/pseries_le_defconfig | 1 +
11 files changed, 11 insertions(+)
diff --git a/arch/powerpc/configs/cell_defconfig b/arch/powerpc/configs/cell_defconfig
index 4bee1a6..45fd06c 100644
--- a/arch/powerpc/configs/cell_defconfig
+++ b/arch/powerpc/configs/cell_defconfig
@@ -5,6 +5,7 @@ CONFIG_SMP=y
CONFIG_NR_CPUS=4
CONFIG_EXPERIMENTAL=y
CONFIG_SYSVIPC=y
+CONFIG_FHANDLE=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=15
diff --git a/arch/powerpc/configs/celleb_defconfig b/arch/powerpc/configs/celleb_defconfig
index 6d7b22f..77d7bf3 100644
--- a/arch/powerpc/configs/celleb_defconfig
+++ b/arch/powerpc/configs/celleb_defconfig
@@ -5,6 +5,7 @@ CONFIG_SMP=y
CONFIG_NR_CPUS=4
CONFIG_EXPERIMENTAL=y
CONFIG_SYSVIPC=y
+CONFIG_FHANDLE=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=15
diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig
index 4b07bad..269d6e4 100644
--- a/arch/powerpc/configs/corenet64_smp_defconfig
+++ b/arch/powerpc/configs/corenet64_smp_defconfig
@@ -4,6 +4,7 @@ CONFIG_ALTIVEC=y
CONFIG_SMP=y
CONFIG_NR_CPUS=24
CONFIG_SYSVIPC=y
+CONFIG_FHANDLE=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
diff --git a/arch/powerpc/configs/g5_defconfig b/arch/powerpc/configs/g5_defconfig
index 3c72fa6..7594c5a 100644
--- a/arch/powerpc/configs/g5_defconfig
+++ b/arch/powerpc/configs/g5_defconfig
@@ -5,6 +5,7 @@ CONFIG_NR_CPUS=4
CONFIG_EXPERIMENTAL=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
+CONFIG_FHANDLE=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_BLK_DEV_INITRD=y
diff --git a/arch/powerpc/configs/maple_defconfig b/arch/powerpc/configs/maple_defconfig
index 95e545d..c8b6a9d 100644
--- a/arch/powerpc/configs/maple_defconfig
+++ b/arch/powerpc/configs/maple_defconfig
@@ -4,6 +4,7 @@ CONFIG_NR_CPUS=4
CONFIG_EXPERIMENTAL=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
+CONFIG_FHANDLE=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_COMPAT_BRK is not set
diff --git a/arch/powerpc/configs/pasemi_defconfig b/arch/powerpc/configs/pasemi_defconfig
index cec044a..e5e7838 100644
--- a/arch/powerpc/configs/pasemi_defconfig
+++ b/arch/powerpc/configs/pasemi_defconfig
@@ -3,6 +3,7 @@ CONFIG_ALTIVEC=y
CONFIG_SMP=y
CONFIG_NR_CPUS=2
CONFIG_SYSVIPC=y
+CONFIG_FHANDLE=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_BLK_DEV_INITRD=y
diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig
index f26b267..f6c02f8 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -4,6 +4,7 @@ CONFIG_VSX=y
CONFIG_SMP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
+CONFIG_FHANDLE=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
diff --git a/arch/powerpc/configs/ppc64e_defconfig b/arch/powerpc/configs/ppc64e_defconfig
index 438e813..587f551 100644
--- a/arch/powerpc/configs/ppc64e_defconfig
+++ b/arch/powerpc/configs/ppc64e_defconfig
@@ -3,6 +3,7 @@ CONFIG_PPC_BOOK3E_64=y
CONFIG_SMP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
+CONFIG_FHANDLE=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_TASKSTATS=y
diff --git a/arch/powerpc/configs/ps3_defconfig b/arch/powerpc/configs/ps3_defconfig
index fdee37f..2e637c8 100644
--- a/arch/powerpc/configs/ps3_defconfig
+++ b/arch/powerpc/configs/ps3_defconfig
@@ -5,6 +5,7 @@ CONFIG_SMP=y
CONFIG_NR_CPUS=2
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
+CONFIG_FHANDLE=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_RD_LZMA=y
diff --git a/arch/powerpc/configs/pseries_defconfig b/arch/powerpc/configs/pseries_defconfig
index a905063..50375f1 100644
--- a/arch/powerpc/configs/pseries_defconfig
+++ b/arch/powerpc/configs/pseries_defconfig
@@ -5,6 +5,7 @@ CONFIG_SMP=y
CONFIG_NR_CPUS=2048
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
+CONFIG_FHANDLE=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_IRQ_DOMAIN_DEBUG=y
diff --git a/arch/powerpc/configs/pseries_le_defconfig b/arch/powerpc/configs/pseries_le_defconfig
index 58e3dbf..4428ee4 100644
--- a/arch/powerpc/configs/pseries_le_defconfig
+++ b/arch/powerpc/configs/pseries_le_defconfig
@@ -6,6 +6,7 @@ CONFIG_NR_CPUS=2048
CONFIG_CPU_LITTLE_ENDIAN=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
+CONFIG_FHANDLE=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_IRQ_DOMAIN_DEBUG=y
--
1.9.1
^ permalink raw reply related
* Re: bit fields && data tearing
From: Peter Hurley @ 2014-09-05 1:57 UTC (permalink / raw)
To: paulmck, H. Peter Anvin
Cc: Jakub Jelinek, One Thousand Gnomes, Tony Luck, linux-ia64,
Mikael Pettersson, linux-alpha, Oleg Nesterov, linux-kernel,
Paul Mackerras, linux-arch, linuxppc-dev, Miroslav Franc,
Richard Henderson
In-Reply-To: <20140905001751.GL5001@linux.vnet.ibm.com>
[ +cc linux-alpha ]
Hi Paul,
On 09/04/2014 08:17 PM, Paul E. McKenney wrote:
> On Thu, Sep 04, 2014 at 03:16:03PM -0700, H. Peter Anvin wrote:
>> On 09/04/2014 12:42 PM, Peter Hurley wrote:
>>>
>>> Or we could give up on the Alpha.
>>>
>>
>> If Alpha is turning into Voyager (kept alive only as a museum piece, but
>> actively causing problems) then please let's kill it.
>
> Sorry for being slow to join this thread, but I propose the following
> patch. If we can remove support for all CPUs that to not support
> direct access to bytes and shorts (which I would very much like to
> see happen), I will remove the last non-guarantee.
>
> Thanx, Paul
Although I don't mind the patch below, I don't think the bitfield thing
happened because anyone was confused about what the compiler would do;
here, it's more a case of legacy code that came out from under the
Big Kernel Lock and the bitfield was an oversight.
However, my patch to fix it by splitting the bitfield into 4 bytes
was rejected as insufficient to prevent accidental sharing. This is
what spun off the Alpha discussion about non-atomic byte updates.
FWIW, there are a bunch of problems with both the documentation and
kernel code if adjacent bytes can be overwritten by a single byte write.
Documentation/atomic-ops.txt claims that properly aligned chars are
atomic in the same sense that ints are, which is not true on the Alpha
(hopefully not a possible optimization on other arches -- I tried
with the ia64 cross compiler but it stuck with byte-sized writes).
Pretty much any large aggregate kernel structure is bound to have some
byte-size fields that are either lockless or serialized by different
locks, which may be corrupted by concurrent updates to adjacent data.
IOW, ACCESS_ONCE(), spinlocks, whatever, doesn't prevent adjacent
byte-sized data from being overwritten. I haven't bothered to count
how many global bools/chars there are and whether they might be
overwritten by adjacent updates.
Documentation/circular-buffers.txt and any lockless implementation based
on or similar to it for bytes or shorts will be corrupted if the head
nears the tail.
I'm sure there's other interesting outcomes that haven't come to light.
I think that 'naturally aligned scalar writes are atomic' should be the
minimum arch guarantee.
Regards,
Peter Hurley
> ------------------------------------------------------------------------
>
> documentation: Record limitations of bitfields and small variables
>
> This commit documents the fact that it is not safe to use bitfields
> as shared variables in synchronization algorithms.
>
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>
> diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
> index 87be0a8a78de..a28bfe4fd759 100644
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -269,6 +269,26 @@ And there are a number of things that _must_ or _must_not_ be assumed:
> STORE *(A + 4) = Y; STORE *A = X;
> STORE {*A, *(A + 4) } = {X, Y};
>
> +And there are anti-guarantees:
> +
> + (*) These guarantees do not apply to bitfields, because compilers often
> + generate code to modify these using non-atomic read-modify-write
> + sequences. Do not attempt to use bitfields to synchronize parallel
> + algorithms.
> +
> + (*) Even in cases where bitfields are protected by locks, all fields
> + in a given bitfield must be protected by one lock. If two fields
> + in a given bitfield are protected by different locks, the compiler's
> + non-atomic read-modify-write sequences can cause an update to one
> + field to corrupt the value of an adjacent field.
> +
> + (*) These guarantees apply only to properly aligned and sized scalar
> + variables. "Properly sized" currently means "int" and "long",
> + because some CPU families do not support loads and stores of
> + other sizes. ("Some CPU families" is currently believed to
> + be only Alpha 21064. If this is actually the case, a different
> + non-guarantee is likely to be formulated.)
> +
>
> =========================
> WHAT ARE MEMORY BARRIERS?
^ permalink raw reply
* Re: bit fields && data tearing
From: H. Peter Anvin @ 2014-09-05 2:08 UTC (permalink / raw)
To: Peter Hurley, Benjamin Herrenschmidt, David Laight
Cc: Jakub Jelinek, linux-arch@vger.kernel.org, Tony Luck,
linux-ia64@vger.kernel.org, Oleg Nesterov,
linux-kernel@vger.kernel.org, Paul Mackerras, linux-alpha,
Paul E. McKenney, linuxppc-dev@lists.ozlabs.org, Miroslav Franc,
Richard Henderson
In-Reply-To: <54090AF4.7060406@hurleysoftware.com>
On 09/04/2014 05:59 PM, Peter Hurley wrote:
> I have no idea how prevalent the ev56 is compared to the ev5.
> Still we're talking about a chip that came out in 1996.
Ah yes, I stand corrected. According to Wikipedia, the affected CPUs
were all the 2106x CPUs (EV4, EV45, LCA4, LCA45) plus the 21164 with no
suffix (EV5). However, we're still talking about museum pieces here.
I wonder what the one I have in my garage is... I'm sure I could emulate
it faster, though.
-hpa
^ permalink raw reply
* Re: bit fields && data tearing
From: H. Peter Anvin @ 2014-09-05 2:08 UTC (permalink / raw)
To: Peter Hurley, Benjamin Herrenschmidt, David Laight
Cc: Jakub Jelinek, linux-arch@vger.kernel.org, Tony Luck,
linux-ia64@vger.kernel.org, Oleg Nesterov,
linux-kernel@vger.kernel.org, Paul Mackerras, linux-alpha,
Paul E. McKenney, linuxppc-dev@lists.ozlabs.org, Miroslav Franc,
Richard Henderson
In-Reply-To: <54090AF4.7060406@hurleysoftware.com>
On 09/04/2014 05:59 PM, Peter Hurley wrote:
> I have no idea how prevalent the ev56 is compared to the ev5.
> Still we're talking about a chip that came out in 1996.
Ah yes, I stand corrected. According to Wikipedia, the affected CPUs
were all the 2106x CPUs (EV4, EV45, LCA4, LCA45) plus the 21164 with no
suffix (EV5). However, we're still talking about museum pieces here.
I wonder what the one I have in my garage is... I'm sure I could emulate
it faster, though.
-hpa
^ permalink raw reply
* Re: bit fields && data tearing
From: James Bottomley @ 2014-09-05 2:11 UTC (permalink / raw)
To: paulmck
Cc: Jakub Jelinek, One Thousand Gnomes, linux-arch, linux-ia64,
Peter Hurley, Mikael Pettersson, Oleg Nesterov, linux-kernel,
Tony Luck, Paul Mackerras, H. Peter Anvin, linuxppc-dev,
Miroslav Franc, Richard Henderson
In-Reply-To: <20140905001751.GL5001@linux.vnet.ibm.com>
On Thu, 2014-09-04 at 17:17 -0700, Paul E. McKenney wrote:
> +And there are anti-guarantees:
> +
> + (*) These guarantees do not apply to bitfields, because compilers often
> + generate code to modify these using non-atomic read-modify-write
> + sequences. Do not attempt to use bitfields to synchronize parallel
> + algorithms.
> +
> + (*) Even in cases where bitfields are protected by locks, all fields
> + in a given bitfield must be protected by one lock. If two fields
> + in a given bitfield are protected by different locks, the compiler's
> + non-atomic read-modify-write sequences can cause an update to one
> + field to corrupt the value of an adjacent field.
> +
> + (*) These guarantees apply only to properly aligned and sized scalar
> + variables. "Properly sized" currently means "int" and "long",
> + because some CPU families do not support loads and stores of
> + other sizes. ("Some CPU families" is currently believed to
> + be only Alpha 21064. If this is actually the case, a different
> + non-guarantee is likely to be formulated.)
This is a bit unclear. Presumably you're talking about definiteness of
the outcome (as in what's seen after multiple stores to the same
variable). The guarantees are only for natural width on Parisc as well,
so you would get a mess if you did byte stores to adjacent memory
locations. But multiple 32 bit stores guarantees to see one of the
stored values as the final outcome.
James
^ permalink raw reply
* Re: [PATCH] IBM Akebono: Remove obsolete config select
From: Alistair Popple @ 2014-09-05 2:39 UTC (permalink / raw)
To: benh; +Cc: devicetree, Paul Bolle, linuxppc-dev, linux-kernel
In-Reply-To: <1409869242.5546.119.camel@x220>
On Fri, 5 Sep 2014 00:20:42 Paul Bolle wrote:
<snip>
> > On Fri, 13 Jun 2014 13:56:32 Paul Bolle wrote:
> > > On Fri, 2014-05-02 at 18:06 +1000, Alistair Popple wrote:
> > > > The original implementation of MMC support for Akebono introduced a
> > > > new configuration symbol (MMC_SDHCI_OF_476GTR). This symbol has been
> > > > dropped in favour of using the generic platform driver however the
> > > > select for this symbol was mistakenly left in the platform
> > > > configuration.
> > > >
> > > > This patch removes the obsolete symbol selection.
> > > >
> > > > Signed-off-by: Alistair Popple <alistair@popple.id.au>
> > >
> > > This patch hasn't yet entered linux-next nor Linus' tree. Is it queued
> > > somewhere? If not, would a
> > >
> > > Acked-by: Paul Bolle <pebolle@tiscali.nl>
> > >
> > > help to get this trivial patch queued for either of those trees?
> > >
> > >
> > > Paul Bolle
> > >
> > > > ---
> > > >
> > > > arch/powerpc/platforms/44x/Kconfig | 1 -
> > > > 1 file changed, 1 deletion(-)
> > > >
> > > > diff --git a/arch/powerpc/platforms/44x/Kconfig
> > > > b/arch/powerpc/platforms/44x/Kconfig index 8beec7d..908bf11 100644
> > > > --- a/arch/powerpc/platforms/44x/Kconfig
> > > > +++ b/arch/powerpc/platforms/44x/Kconfig
> > > > @@ -220,7 +220,6 @@ config AKEBONO
> > > >
> > > > select USB_EHCI_HCD_PLATFORM
> > > > select MMC_SDHCI
> > > > select MMC_SDHCI_PLTFM
> > > >
> > > > - select MMC_SDHCI_OF_476GTR
> > > >
> > > > select ATA
> > > > select SATA_AHCI_PLATFORM
> > > > help
>
> This trivial cleanup is still not in linux-next nor in Linus' tree.
> Could someone else please have a look at it?
>
> Thanks,
>
>
> Paul Bolle
Ben,
Any chance you could merge this? It's in patchwork (see
http://patchwork.ozlabs.org/patch/344894/).
Regards,
Alistair
^ permalink raw reply
* Re: bit fields && data tearing
From: Peter Hurley @ 2014-09-05 2:47 UTC (permalink / raw)
To: James Bottomley, paulmck
Cc: Jakub Jelinek, One Thousand Gnomes, linux-arch, linux-ia64,
Mikael Pettersson, Oleg Nesterov, linux-kernel, Tony Luck,
Paul Mackerras, H. Peter Anvin, linuxppc-dev, Miroslav Franc,
Richard Henderson
In-Reply-To: <1409883098.5078.14.camel@jarvis.lan>
Hi James,
On 09/04/2014 10:11 PM, James Bottomley wrote:
> On Thu, 2014-09-04 at 17:17 -0700, Paul E. McKenney wrote:
>> +And there are anti-guarantees:
>> +
>> + (*) These guarantees do not apply to bitfields, because compilers often
>> + generate code to modify these using non-atomic read-modify-write
>> + sequences. Do not attempt to use bitfields to synchronize parallel
>> + algorithms.
>> +
>> + (*) Even in cases where bitfields are protected by locks, all fields
>> + in a given bitfield must be protected by one lock. If two fields
>> + in a given bitfield are protected by different locks, the compiler's
>> + non-atomic read-modify-write sequences can cause an update to one
>> + field to corrupt the value of an adjacent field.
>> +
>> + (*) These guarantees apply only to properly aligned and sized scalar
>> + variables. "Properly sized" currently means "int" and "long",
>> + because some CPU families do not support loads and stores of
>> + other sizes. ("Some CPU families" is currently believed to
>> + be only Alpha 21064. If this is actually the case, a different
>> + non-guarantee is likely to be formulated.)
>
> This is a bit unclear. Presumably you're talking about definiteness of
> the outcome (as in what's seen after multiple stores to the same
> variable).
No, the last conditions refers to adjacent byte stores from different
cpu contexts (either interrupt or SMP).
> The guarantees are only for natural width on Parisc as well,
> so you would get a mess if you did byte stores to adjacent memory
> locations.
For a simple test like:
struct x {
long a;
char b;
char c;
char d;
char e;
};
void store_bc(struct x *p) {
p->b = 1;
p->c = 2;
}
on parisc, gcc generates separate byte stores
void store_bc(struct x *p) {
0: 34 1c 00 02 ldi 1,ret0
4: 0f 5c 12 08 stb ret0,4(r26)
8: 34 1c 00 04 ldi 2,ret0
c: e8 40 c0 00 bv r0(rp)
10: 0f 5c 12 0a stb ret0,5(r26)
which appears to confirm that on parisc adjacent byte data
is safe from corruption by concurrent cpu updates; that is,
CPU 0 | CPU 1
|
p->b = 1 | p->c = 2
|
will result in p->b == 1 && p->c == 2 (assume both values
were 0 before the call to store_bc()).
Regards,
Peter Hurley
^ permalink raw reply
* Re: bit fields && data tearing
From: Paul E. McKenney @ 2014-09-05 4:06 UTC (permalink / raw)
To: Peter Hurley
Cc: Jakub Jelinek, One Thousand Gnomes, linux-arch, linux-ia64,
Mikael Pettersson, Oleg Nesterov, linux-kernel, James Bottomley,
Tony Luck, Paul Mackerras, H. Peter Anvin, linuxppc-dev,
Miroslav Franc, Richard Henderson
In-Reply-To: <5409243C.4080704@hurleysoftware.com>
On Thu, Sep 04, 2014 at 10:47:24PM -0400, Peter Hurley wrote:
> Hi James,
>
> On 09/04/2014 10:11 PM, James Bottomley wrote:
> > On Thu, 2014-09-04 at 17:17 -0700, Paul E. McKenney wrote:
> >> +And there are anti-guarantees:
> >> +
> >> + (*) These guarantees do not apply to bitfields, because compilers often
> >> + generate code to modify these using non-atomic read-modify-write
> >> + sequences. Do not attempt to use bitfields to synchronize parallel
> >> + algorithms.
> >> +
> >> + (*) Even in cases where bitfields are protected by locks, all fields
> >> + in a given bitfield must be protected by one lock. If two fields
> >> + in a given bitfield are protected by different locks, the compiler's
> >> + non-atomic read-modify-write sequences can cause an update to one
> >> + field to corrupt the value of an adjacent field.
> >> +
> >> + (*) These guarantees apply only to properly aligned and sized scalar
> >> + variables. "Properly sized" currently means "int" and "long",
> >> + because some CPU families do not support loads and stores of
> >> + other sizes. ("Some CPU families" is currently believed to
> >> + be only Alpha 21064. If this is actually the case, a different
> >> + non-guarantee is likely to be formulated.)
> >
> > This is a bit unclear. Presumably you're talking about definiteness of
> > the outcome (as in what's seen after multiple stores to the same
> > variable).
>
> No, the last conditions refers to adjacent byte stores from different
> cpu contexts (either interrupt or SMP).
>
> > The guarantees are only for natural width on Parisc as well,
> > so you would get a mess if you did byte stores to adjacent memory
> > locations.
>
> For a simple test like:
>
> struct x {
> long a;
> char b;
> char c;
> char d;
> char e;
> };
>
> void store_bc(struct x *p) {
> p->b = 1;
> p->c = 2;
> }
>
> on parisc, gcc generates separate byte stores
>
> void store_bc(struct x *p) {
> 0: 34 1c 00 02 ldi 1,ret0
> 4: 0f 5c 12 08 stb ret0,4(r26)
> 8: 34 1c 00 04 ldi 2,ret0
> c: e8 40 c0 00 bv r0(rp)
> 10: 0f 5c 12 0a stb ret0,5(r26)
>
> which appears to confirm that on parisc adjacent byte data
> is safe from corruption by concurrent cpu updates; that is,
>
> CPU 0 | CPU 1
> |
> p->b = 1 | p->c = 2
> |
>
> will result in p->b == 1 && p->c == 2 (assume both values
> were 0 before the call to store_bc()).
What Peter said. I would ask for suggestions for better wording, but
I would much rather be able to say that single-byte reads and writes
are atomic and that aligned-short reads and writes are also atomic.
Thus far, it looks like we lose only very old Alpha systems, so unless
I hear otherwise, I update my patch to outlaw these very old systems.
Thanx, Paul
^ permalink raw reply
* deb-pkg: Add support for powerpc little endian
From: Michael Neuling @ 2014-09-05 5:28 UTC (permalink / raw)
To: Michal Marek, Ben Hutchings
Cc: Leann Ogasawara, linuxppc-dev, linux-kernel, Anton Blanchard,
linux-kbuild
The Debian powerpc little endian architecture is called ppc64le. This
is the default architecture used by Ubuntu for powerpc.
The below checks the kernel config to see if we are compiling little
endian and sets the Debian arch appropriately.
Signed-off-by: Michael Neuling <mikey@neuling.org>
diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index 35d5a58..6f4a1af 100644
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -37,7 +37,7 @@ create_package() {
s390*)
debarch=3Ds390$(grep -q CONFIG_64BIT=3Dy $KCONFIG_CONFIG && echo x || tr=
ue) ;;
ppc*)
- debarch=3Dpowerpc ;;
+ debarch=3D$(grep -q CPU_LITTLE_ENDIAN=3Dy $KCONFIG_CONFIG && echo ppc64e=
l || echo powerpc) ;;
parisc*)
debarch=3Dhppa ;;
mips*)
^ permalink raw reply related
* Re: [PATCH] fadump: fix endianess issues in firmware assisted dump handling
From: Mahesh Jagannath Salgaonkar @ 2014-09-05 5:55 UTC (permalink / raw)
To: Hari Bathini, linuxppc-dev
In-Reply-To: <20140903122948.28708.22188.stgit@localhost.localdomain>
On 09/03/2014 05:59 PM, Hari Bathini wrote:
> Firmware-assisted dump (fadump) kernel code is not LE compliant. The
> below patch tries to fix this issue. Tested this patch with upstream
> kernel. Did some sanity testing for the LE fadump vmcore generated.
> Below output shows crash tool successfully opening LE fadump vmcore.
>
> # crash $vmlinux vmcore
>
> crash 7.0.5
> Copyright (C) 2002-2014 Red Hat, Inc.
> Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
> Copyright (C) 1999-2006 Hewlett-Packard Co
> Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited
> Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
> Copyright (C) 2005, 2011 NEC Corporation
> Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
> Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
> This program is free software, covered by the GNU General Public License,
> and you are welcome to change it and/or distribute copies of it under
> certain conditions. Enter "help copying" to see the conditions.
> This program has absolutely no warranty. Enter "help warranty" for details.
>
> crash: /boot/vmlinux-3.16.0-rc7-7-default+: no .gnu_debuglink section
> GNU gdb (GDB) 7.6
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "powerpc64le-unknown-linux-gnu"...
>
> KERNEL: /boot/vmlinux-3.16.0-rc7-7-default+
> DUMPFILE: vmcore
> CPUS: 16
> DATE: Sun Aug 24 14:31:28 2014
> UPTIME: 00:02:57
> LOAD AVERAGE: 0.05, 0.08, 0.04
> TASKS: 256
> NODENAME: linux-dhr2
> RELEASE: 3.16.0-rc7-7-default+
> VERSION: #54 SMP Mon Aug 18 14:08:23 EDT 2014
> MACHINE: ppc64le (4116 Mhz)
> MEMORY: 40 GB
> PANIC: "Oops: Kernel access of bad area, sig: 11 [#1]" (check log for details)
> PID: 2234
> COMMAND: "bash"
> TASK: c0000009652e4a30 [THREAD_INFO: c00000096777c000]
> CPU: 2
> STATE: TASK_RUNNING (PANIC)
>
> crash>
>
> Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/fadump.h | 52 ++++++++-------
> arch/powerpc/kernel/fadump.c | 112 +++++++++++++++++----------------
> arch/powerpc/platforms/pseries/lpar.c | 9 ++-
> 3 files changed, 89 insertions(+), 84 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/fadump.h b/arch/powerpc/include/asm/fadump.h
> index a677456..493e72f 100644
> --- a/arch/powerpc/include/asm/fadump.h
> +++ b/arch/powerpc/include/asm/fadump.h
> @@ -70,39 +70,39 @@
> #define CPU_UNKNOWN (~((u32)0))
>
> /* Utility macros */
> -#define SKIP_TO_NEXT_CPU(reg_entry) \
> -({ \
> - while (reg_entry->reg_id != REG_ID("CPUEND")) \
> - reg_entry++; \
> - reg_entry++; \
> +#define SKIP_TO_NEXT_CPU(reg_entry) \
> +({ \
> + while (be64_to_cpu(reg_entry->reg_id) != REG_ID("CPUEND")) \
> + reg_entry++; \
> + reg_entry++; \
> })
>
> /* Kernel Dump section info */
> struct fadump_section {
> - u32 request_flag;
> - u16 source_data_type;
> - u16 error_flags;
> - u64 source_address;
> - u64 source_len;
> - u64 bytes_dumped;
> - u64 destination_address;
> + __be32 request_flag;
> + __be16 source_data_type;
> + __be16 error_flags;
> + __be64 source_address;
> + __be64 source_len;
> + __be64 bytes_dumped;
> + __be64 destination_address;
> };
>
> /* ibm,configure-kernel-dump header. */
> struct fadump_section_header {
> - u32 dump_format_version;
> - u16 dump_num_sections;
> - u16 dump_status_flag;
> - u32 offset_first_dump_section;
> + __be32 dump_format_version;
> + __be16 dump_num_sections;
> + __be16 dump_status_flag;
> + __be32 offset_first_dump_section;
>
> /* Fields for disk dump option. */
> - u32 dd_block_size;
> - u64 dd_block_offset;
> - u64 dd_num_blocks;
> - u32 dd_offset_disk_path;
> + __be32 dd_block_size;
> + __be64 dd_block_offset;
> + __be64 dd_num_blocks;
> + __be32 dd_offset_disk_path;
>
> /* Maximum time allowed to prevent an automatic dump-reboot. */
> - u32 max_time_auto;
> + __be32 max_time_auto;
> };
>
> /*
> @@ -174,15 +174,15 @@ static inline u64 str_to_u64(const char *str)
>
> /* Register save area header. */
> struct fadump_reg_save_area_header {
> - u64 magic_number;
> - u32 version;
> - u32 num_cpu_offset;
> + __be64 magic_number;
> + __be32 version;
> + __be32 num_cpu_offset;
> };
>
> /* Register entry. */
> struct fadump_reg_entry {
> - u64 reg_id;
> - u64 reg_value;
> + __be64 reg_id;
> + __be64 reg_value;
> };
>
> /* fadump crash info structure */
> diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
> index 742694c..7d73b2d 100644
> --- a/arch/powerpc/kernel/fadump.c
> +++ b/arch/powerpc/kernel/fadump.c
> @@ -72,7 +72,7 @@ int __init early_init_dt_scan_fw_dump(unsigned long node,
> return 1;
>
> fw_dump.fadump_supported = 1;
> - fw_dump.ibm_configure_kernel_dump = *token;
> + fw_dump.ibm_configure_kernel_dump = be32_to_cpu(*token);
>
> /*
> * The 'ibm,kernel-dump' rtas node is present only if there is
> @@ -147,11 +147,11 @@ static unsigned long init_fadump_mem_struct(struct fadump_mem_struct *fdm,
> memset(fdm, 0, sizeof(struct fadump_mem_struct));
> addr = addr & PAGE_MASK;
>
> - fdm->header.dump_format_version = 0x00000001;
> - fdm->header.dump_num_sections = 3;
> + fdm->header.dump_format_version = cpu_to_be32(0x00000001);
> + fdm->header.dump_num_sections = cpu_to_be16(3);
> fdm->header.dump_status_flag = 0;
> fdm->header.offset_first_dump_section =
> - (u32)offsetof(struct fadump_mem_struct, cpu_state_data);
> + cpu_to_be32((u32)offsetof(struct fadump_mem_struct, cpu_state_data));
>
> /*
> * Fields for disk dump option.
> @@ -167,27 +167,27 @@ static unsigned long init_fadump_mem_struct(struct fadump_mem_struct *fdm,
>
> /* Kernel dump sections */
> /* cpu state data section. */
> - fdm->cpu_state_data.request_flag = FADUMP_REQUEST_FLAG;
> - fdm->cpu_state_data.source_data_type = FADUMP_CPU_STATE_DATA;
> + fdm->cpu_state_data.request_flag = cpu_to_be32(FADUMP_REQUEST_FLAG);
> + fdm->cpu_state_data.source_data_type = cpu_to_be16(FADUMP_CPU_STATE_DATA);
> fdm->cpu_state_data.source_address = 0;
> - fdm->cpu_state_data.source_len = fw_dump.cpu_state_data_size;
> - fdm->cpu_state_data.destination_address = addr;
> + fdm->cpu_state_data.source_len = cpu_to_be64(fw_dump.cpu_state_data_size);
> + fdm->cpu_state_data.destination_address = cpu_to_be64(addr);
> addr += fw_dump.cpu_state_data_size;
>
> /* hpte region section */
> - fdm->hpte_region.request_flag = FADUMP_REQUEST_FLAG;
> - fdm->hpte_region.source_data_type = FADUMP_HPTE_REGION;
> + fdm->hpte_region.request_flag = cpu_to_be32(FADUMP_REQUEST_FLAG);
> + fdm->hpte_region.source_data_type = cpu_to_be16(FADUMP_HPTE_REGION);
> fdm->hpte_region.source_address = 0;
> - fdm->hpte_region.source_len = fw_dump.hpte_region_size;
> - fdm->hpte_region.destination_address = addr;
> + fdm->hpte_region.source_len = cpu_to_be64(fw_dump.hpte_region_size);
> + fdm->hpte_region.destination_address = cpu_to_be64(addr);
> addr += fw_dump.hpte_region_size;
>
> /* RMA region section */
> - fdm->rmr_region.request_flag = FADUMP_REQUEST_FLAG;
> - fdm->rmr_region.source_data_type = FADUMP_REAL_MODE_REGION;
> - fdm->rmr_region.source_address = RMA_START;
> - fdm->rmr_region.source_len = fw_dump.boot_memory_size;
> - fdm->rmr_region.destination_address = addr;
> + fdm->rmr_region.request_flag = cpu_to_be32(FADUMP_REQUEST_FLAG);
> + fdm->rmr_region.source_data_type = cpu_to_be16(FADUMP_REAL_MODE_REGION);
> + fdm->rmr_region.source_address = cpu_to_be64(RMA_START);
> + fdm->rmr_region.source_len = cpu_to_be64(fw_dump.boot_memory_size);
> + fdm->rmr_region.destination_address = cpu_to_be64(addr);
> addr += fw_dump.boot_memory_size;
>
> return addr;
> @@ -272,7 +272,7 @@ int __init fadump_reserve_mem(void)
> * first kernel.
> */
> if (fdm_active)
> - fw_dump.boot_memory_size = fdm_active->rmr_region.source_len;
> + fw_dump.boot_memory_size = be64_to_cpu(fdm_active->rmr_region.source_len);
> else
> fw_dump.boot_memory_size = fadump_calculate_reserve_size();
>
> @@ -314,8 +314,8 @@ int __init fadump_reserve_mem(void)
> (unsigned long)(base >> 20));
>
> fw_dump.fadumphdr_addr =
> - fdm_active->rmr_region.destination_address +
> - fdm_active->rmr_region.source_len;
> + be64_to_cpu(fdm_active->rmr_region.destination_address) +
> + be64_to_cpu(fdm_active->rmr_region.source_len);
> pr_debug("fadumphdr_addr = %p\n",
> (void *) fw_dump.fadumphdr_addr);
> } else {
> @@ -472,9 +472,9 @@ fadump_read_registers(struct fadump_reg_entry *reg_entry, struct pt_regs *regs)
> {
> memset(regs, 0, sizeof(struct pt_regs));
>
> - while (reg_entry->reg_id != REG_ID("CPUEND")) {
> - fadump_set_regval(regs, reg_entry->reg_id,
> - reg_entry->reg_value);
> + while (be64_to_cpu(reg_entry->reg_id) != REG_ID("CPUEND")) {
> + fadump_set_regval(regs, be64_to_cpu(reg_entry->reg_id),
> + be64_to_cpu(reg_entry->reg_value));
> reg_entry++;
> }
> reg_entry++;
> @@ -603,20 +603,20 @@ static int __init fadump_build_cpu_notes(const struct fadump_mem_struct *fdm)
> if (!fdm->cpu_state_data.bytes_dumped)
> return -EINVAL;
>
> - addr = fdm->cpu_state_data.destination_address;
> + addr = be64_to_cpu(fdm->cpu_state_data.destination_address);
> vaddr = __va(addr);
>
> reg_header = vaddr;
> - if (reg_header->magic_number != REGSAVE_AREA_MAGIC) {
> + if (be64_to_cpu(reg_header->magic_number) != REGSAVE_AREA_MAGIC) {
> printk(KERN_ERR "Unable to read register save area.\n");
> return -ENOENT;
> }
> pr_debug("--------CPU State Data------------\n");
> - pr_debug("Magic Number: %llx\n", reg_header->magic_number);
> - pr_debug("NumCpuOffset: %x\n", reg_header->num_cpu_offset);
> + pr_debug("Magic Number: %llx\n", be64_to_cpu(reg_header->magic_number));
> + pr_debug("NumCpuOffset: %x\n", be32_to_cpu(reg_header->num_cpu_offset));
>
> - vaddr += reg_header->num_cpu_offset;
> - num_cpus = *((u32 *)(vaddr));
> + vaddr += be32_to_cpu(reg_header->num_cpu_offset);
> + num_cpus = be32_to_cpu(*((u32 *)(vaddr)));
> pr_debug("NumCpus : %u\n", num_cpus);
> vaddr += sizeof(u32);
> reg_entry = (struct fadump_reg_entry *)vaddr;
> @@ -639,13 +639,13 @@ static int __init fadump_build_cpu_notes(const struct fadump_mem_struct *fdm)
> fdh = __va(fw_dump.fadumphdr_addr);
>
> for (i = 0; i < num_cpus; i++) {
> - if (reg_entry->reg_id != REG_ID("CPUSTRT")) {
> + if (be64_to_cpu(reg_entry->reg_id) != REG_ID("CPUSTRT")) {
> printk(KERN_ERR "Unable to read CPU state data\n");
> rc = -ENOENT;
> goto error_out;
> }
> /* Lower 4 bytes of reg_value contains logical cpu id */
> - cpu = reg_entry->reg_value & FADUMP_CPU_ID_MASK;
> + cpu = be64_to_cpu(reg_entry->reg_value) & FADUMP_CPU_ID_MASK;
> if (fdh && !cpumask_test_cpu(cpu, &fdh->cpu_online_mask)) {
> SKIP_TO_NEXT_CPU(reg_entry);
> continue;
> @@ -692,7 +692,7 @@ static int __init process_fadump(const struct fadump_mem_struct *fdm_active)
> return -EINVAL;
>
> /* Check if the dump data is valid. */
> - if ((fdm_active->header.dump_status_flag == FADUMP_ERROR_FLAG) ||
> + if ((be16_to_cpu(fdm_active->header.dump_status_flag) == FADUMP_ERROR_FLAG) ||
> (fdm_active->cpu_state_data.error_flags != 0) ||
> (fdm_active->rmr_region.error_flags != 0)) {
> printk(KERN_ERR "Dump taken by platform is not valid\n");
> @@ -828,7 +828,7 @@ static void fadump_setup_crash_memory_ranges(void)
> static inline unsigned long fadump_relocate(unsigned long paddr)
> {
> if (paddr > RMA_START && paddr < fw_dump.boot_memory_size)
> - return fdm.rmr_region.destination_address + paddr;
> + return be64_to_cpu(fdm.rmr_region.destination_address) + paddr;
> else
> return paddr;
> }
> @@ -902,7 +902,7 @@ static int fadump_create_elfcore_headers(char *bufp)
> * to the specified destination_address. Hence set
> * the correct offset.
> */
> - phdr->p_offset = fdm.rmr_region.destination_address;
> + phdr->p_offset = be64_to_cpu(fdm.rmr_region.destination_address);
> }
>
> phdr->p_paddr = mbase;
> @@ -951,7 +951,7 @@ static void register_fadump(void)
>
> fadump_setup_crash_memory_ranges();
>
> - addr = fdm.rmr_region.destination_address + fdm.rmr_region.source_len;
> + addr = be64_to_cpu(fdm.rmr_region.destination_address) + be64_to_cpu(fdm.rmr_region.source_len);
> /* Initialize fadump crash info header. */
> addr = init_fadump_header(addr);
> vaddr = __va(addr);
> @@ -1023,7 +1023,7 @@ void fadump_cleanup(void)
> /* Invalidate the registration only if dump is active. */
> if (fw_dump.dump_active) {
> init_fadump_mem_struct(&fdm,
> - fdm_active->cpu_state_data.destination_address);
> + be64_to_cpu(fdm_active->cpu_state_data.destination_address));
> fadump_invalidate_dump(&fdm);
> }
> }
> @@ -1063,7 +1063,7 @@ static void fadump_invalidate_release_mem(void)
> return;
> }
>
> - destination_address = fdm_active->cpu_state_data.destination_address;
> + destination_address = be64_to_cpu(fdm_active->cpu_state_data.destination_address);
> fadump_cleanup();
> mutex_unlock(&fadump_mutex);
>
> @@ -1183,31 +1183,31 @@ static int fadump_region_show(struct seq_file *m, void *private)
> seq_printf(m,
> "CPU : [%#016llx-%#016llx] %#llx bytes, "
> "Dumped: %#llx\n",
> - fdm_ptr->cpu_state_data.destination_address,
> - fdm_ptr->cpu_state_data.destination_address +
> - fdm_ptr->cpu_state_data.source_len - 1,
> - fdm_ptr->cpu_state_data.source_len,
> - fdm_ptr->cpu_state_data.bytes_dumped);
> + be64_to_cpu(fdm_ptr->cpu_state_data.destination_address),
> + be64_to_cpu(fdm_ptr->cpu_state_data.destination_address) +
> + be64_to_cpu(fdm_ptr->cpu_state_data.source_len) - 1,
> + be64_to_cpu(fdm_ptr->cpu_state_data.source_len),
> + be64_to_cpu(fdm_ptr->cpu_state_data.bytes_dumped));
> seq_printf(m,
> "HPTE: [%#016llx-%#016llx] %#llx bytes, "
> "Dumped: %#llx\n",
> - fdm_ptr->hpte_region.destination_address,
> - fdm_ptr->hpte_region.destination_address +
> - fdm_ptr->hpte_region.source_len - 1,
> - fdm_ptr->hpte_region.source_len,
> - fdm_ptr->hpte_region.bytes_dumped);
> + be64_to_cpu(fdm_ptr->hpte_region.destination_address),
> + be64_to_cpu(fdm_ptr->hpte_region.destination_address) +
> + be64_to_cpu(fdm_ptr->hpte_region.source_len) - 1,
> + be64_to_cpu(fdm_ptr->hpte_region.source_len),
> + be64_to_cpu(fdm_ptr->hpte_region.bytes_dumped));
> seq_printf(m,
> "DUMP: [%#016llx-%#016llx] %#llx bytes, "
> "Dumped: %#llx\n",
> - fdm_ptr->rmr_region.destination_address,
> - fdm_ptr->rmr_region.destination_address +
> - fdm_ptr->rmr_region.source_len - 1,
> - fdm_ptr->rmr_region.source_len,
> - fdm_ptr->rmr_region.bytes_dumped);
> + be64_to_cpu(fdm_ptr->rmr_region.destination_address),
> + be64_to_cpu(fdm_ptr->rmr_region.destination_address) +
> + be64_to_cpu(fdm_ptr->rmr_region.source_len) - 1,
> + be64_to_cpu(fdm_ptr->rmr_region.source_len),
> + be64_to_cpu(fdm_ptr->rmr_region.bytes_dumped));
>
> if (!fdm_active ||
> (fw_dump.reserve_dump_area_start ==
> - fdm_ptr->cpu_state_data.destination_address))
> + be64_to_cpu(fdm_ptr->cpu_state_data.destination_address)))
> goto out;
>
> /* Dump is active. Show reserved memory region. */
> @@ -1215,10 +1215,10 @@ static int fadump_region_show(struct seq_file *m, void *private)
> " : [%#016llx-%#016llx] %#llx bytes, "
> "Dumped: %#llx\n",
> (unsigned long long)fw_dump.reserve_dump_area_start,
> - fdm_ptr->cpu_state_data.destination_address - 1,
> - fdm_ptr->cpu_state_data.destination_address -
> + be64_to_cpu(fdm_ptr->cpu_state_data.destination_address) - 1,
> + be64_to_cpu(fdm_ptr->cpu_state_data.destination_address) -
> fw_dump.reserve_dump_area_start,
> - fdm_ptr->cpu_state_data.destination_address -
> + be64_to_cpu(fdm_ptr->cpu_state_data.destination_address) -
> fw_dump.reserve_dump_area_start);
> out:
> if (fdm_active)
> diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
> index 34e6423..587887e 100644
> --- a/arch/powerpc/platforms/pseries/lpar.c
> +++ b/arch/powerpc/platforms/pseries/lpar.c
> @@ -43,6 +43,7 @@
> #include <asm/trace.h>
> #include <asm/firmware.h>
> #include <asm/plpar_wrappers.h>
> +#include <asm/fadump.h>
>
> #include "pseries.h"
>
> @@ -249,8 +250,12 @@ static void pSeries_lpar_hptab_clear(void)
> }
>
> #ifdef __LITTLE_ENDIAN__
> - /* Reset exceptions to big endian */
> - if (firmware_has_feature(FW_FEATURE_SET_MODE)) {
> + /*
> + * Reset exceptions to big endian
> + * During fadump kernel boot, we dont need to reset exception to big endian
> + * as we have already booted into LE kernel.
> + */
> + if (firmware_has_feature(FW_FEATURE_SET_MODE) && !is_fadump_active()) {
> long rc;
>
> rc = pseries_big_endian_exceptions();
>
^ permalink raw reply
* [PATCH V2 0/2] cpufreq/powernv: Set core pstate to a minimum just before hotplugging it out
From: Preeti U Murthy @ 2014-09-05 7:39 UTC (permalink / raw)
To: viresh.kumar, rjw
Cc: linux-pm, dirk.j.brandewie, shreyas, linux-kernel,
patrick.marlier, linuxppc-dev, dirk.brandewie
Today cpus go to winkle when they are offlined. Since it is the deepest
idle state that we have, it is expected to save good amount of power as compared
to online state, where cores can enter nap/fastsleep only which are
shallower idle states.
However we observed no powersavings with winkle as compared to nap/fastsleep
and traced the problem to the pstate of the core being kept at a high even
when the core is offline. This can keep the socket pstate high, thus burning
power unnecessarily. This patchset fixes this issue.
Changes in V2: Changed smp_call_function_any() to smp_call_function_single() in Patch[2/2]
---
Preeti U Murthy (2):
cpufreq: Allow stop CPU callback to be used by all cpufreq drivers
powernv/cpufreq: Set the pstate of the last hotplugged out cpu in policy->cpus to minimum
drivers/cpufreq/cpufreq.c | 2 +-
drivers/cpufreq/powernv-cpufreq.c | 9 +++++++++
2 files changed, 10 insertions(+), 1 deletion(-)
--
^ permalink raw reply
* [PATCH V2 1/2] cpufreq: Allow stop CPU callback to be used by all cpufreq drivers
From: Preeti U Murthy @ 2014-09-05 7:40 UTC (permalink / raw)
To: viresh.kumar, rjw
Cc: linux-pm, dirk.j.brandewie, shreyas, linux-kernel,
patrick.marlier, linuxppc-dev, dirk.brandewie
In-Reply-To: <20140905073812.3629.29175.stgit@preeti.in.ibm.com>
Commit 367dc4aa932bfb3 ("cpufreq: Add stop CPU callback to
cpufreq_driver interface") introduced the stop CPU callback for
intel_pstate drivers. During the CPU_DOWN_PREPARE stage, this
callback is invoked so that drivers can take some action on the
pstate of the cpu before it is taken offline. This callback was
assumed to be useful only for those drivers which have implemented
the set_policy CPU callback because they have no other way to take
action about the cpufreq of a CPU which is being hotplugged out
except in the exit callback which is called very late in the offline
process.
The drivers which implement the target/target_index callbacks were
expected to take care of requirements like the ones that commit
367dc4aa addresses in the GOV_STOP notification event. But there
are disadvantages to restricting the usage of stop CPU callback
to cpufreq drivers that implement the set_policy callbacks and who
want to take explicit action on the setting the cpufreq during a
hotplug operation.
1.GOV_STOP gets called for every CPU offline and drivers would usually
want to take action when the last cpu in the policy->cpus mask
is taken offline. As long as there is more than one cpu in the
policy->cpus mask, cpufreq core itself makes sure that the freq
for the other cpus in this mask is set according to the maximum load.
This is sensible and drivers which implement the target_index callback
would mostly not want to modify that. However the cpufreq core leaves a
loose end when the cpu in the policy->cpus mask is the last one to go offline;
it does nothing explicit to the frequency of the core. Drivers may need
a way to take some action here and stop CPU callback mechanism is the
best way to do it today.
2. We cannot implement driver specific actions in the GOV_STOP mechanism.
So we will need another driver callback which is invoked from here which is
unnecessary.
Therefore this patch extends the usage of stop CPU callback to be used
by all cpufreq drivers as long as they have this callback implemented
and irrespective of whether they are set_policy/target_index drivers.
The assumption is if the drivers find the GOV_STOP path to be a suitable
way of implementing what they want to do with the freq of the cpu
going offine,they will not implement the stop CPU callback at all.
Signed-off-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
---
drivers/cpufreq/cpufreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index d9fdedd..6463f35 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1380,7 +1380,7 @@ static int __cpufreq_remove_dev_prepare(struct device *dev,
if (!cpufreq_suspended)
pr_debug("%s: policy Kobject moved to cpu: %d from: %d\n",
__func__, new_cpu, cpu);
- } else if (cpufreq_driver->stop_cpu && cpufreq_driver->setpolicy) {
+ } else if (cpufreq_driver->stop_cpu) {
cpufreq_driver->stop_cpu(policy);
}
^ permalink raw reply related
* [PATCH V2 2/2] powernv/cpufreq: Set the pstate of the last hotplugged out cpu in policy->cpus to minimum
From: Preeti U Murthy @ 2014-09-05 7:40 UTC (permalink / raw)
To: viresh.kumar, rjw
Cc: linux-pm, dirk.j.brandewie, shreyas, linux-kernel,
patrick.marlier, linuxppc-dev, dirk.brandewie
In-Reply-To: <20140905073812.3629.29175.stgit@preeti.in.ibm.com>
Its possible today that the pstate of a core is held at a high even after the
entire core is hotplugged out if a load had just run on the hotplugged cpu. This is
fair, since it is assumed that the pstate does not matter to a cpu in a deep idle
state, which is the expected state of a hotplugged core on powerpc. However on powerpc,
the pstate at a socket level is held at the maximum of the pstates of each core. Even
if the pstates of the active cores on that socket is low, the socket pstate is held
high due to the pstate of the hotplugged core in the above mentioned scenario. This
can cost significant amount of power loss for no good.
Besides, since it is a non active core, nothing can be done from the kernel's end
to set the frequency of the core right. Hence make use of the stop_cpu callback
to explicitly set the pstate of the core to a minimum when the last cpu of the
core gets hotplugged out.
Signed-off-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
---
drivers/cpufreq/powernv-cpufreq.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c
index 379c083..5a628f1 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -317,6 +317,14 @@ static int powernv_cpufreq_cpu_init(struct cpufreq_policy *policy)
return cpufreq_table_validate_and_show(policy, powernv_freqs);
}
+static void powernv_cpufreq_stop_cpu(struct cpufreq_policy *policy)
+{
+ struct powernv_smp_call_data freq_data;
+
+ freq_data.pstate_id = powernv_pstate_info.min;
+ smp_call_function_single(policy->cpu, set_pstate, &freq_data, 1);
+}
+
static struct cpufreq_driver powernv_cpufreq_driver = {
.name = "powernv-cpufreq",
.flags = CPUFREQ_CONST_LOOPS,
@@ -324,6 +332,7 @@ static struct cpufreq_driver powernv_cpufreq_driver = {
.verify = cpufreq_generic_frequency_table_verify,
.target_index = powernv_cpufreq_target_index,
.get = powernv_cpufreq_get,
+ .stop_cpu = powernv_cpufreq_stop_cpu,
.attr = powernv_cpu_freq_attr,
};
^ permalink raw reply related
* Re: [PATCH V2 0/2] cpufreq/powernv: Set core pstate to a minimum just before hotplugging it out
From: Viresh Kumar @ 2014-09-05 7:41 UTC (permalink / raw)
To: Preeti U Murthy
Cc: linux-pm@vger.kernel.org, Dirk Brandewie, Shreyas Prabhu,
Rafael J. Wysocki, Linux Kernel Mailing List, Patrick Marlier,
linuxppc-dev@ozlabs.org, Dirk Brandewie
In-Reply-To: <20140905073812.3629.29175.stgit@preeti.in.ibm.com>
On 5 September 2014 13:09, Preeti U Murthy <preeti@linux.vnet.ibm.com> wrote:
> Today cpus go to winkle when they are offlined. Since it is the deepest
> idle state that we have, it is expected to save good amount of power as compared
> to online state, where cores can enter nap/fastsleep only which are
> shallower idle states.
> However we observed no powersavings with winkle as compared to nap/fastsleep
> and traced the problem to the pstate of the core being kept at a high even
> when the core is offline. This can keep the socket pstate high, thus burning
> power unnecessarily. This patchset fixes this issue.
>
> Changes in V2: Changed smp_call_function_any() to smp_call_function_single() in Patch[2/2]
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
^ permalink raw reply
* Re: deb-pkg: Add support for powerpc little endian
From: Gabriel Paubert @ 2014-09-05 7:13 UTC (permalink / raw)
To: Michael Neuling
Cc: Michal Marek, linux-kbuild, Ben Hutchings, linux-kernel,
Anton Blanchard, Leann Ogasawara, linuxppc-dev
In-Reply-To: <1409894927.11359.26.camel@ale.ozlabs.ibm.com>
On Fri, Sep 05, 2014 at 03:28:47PM +1000, Michael Neuling wrote:
> The Debian powerpc little endian architecture is called ppc64le. This
Huh? ppc64le or ppc64el?
> is the default architecture used by Ubuntu for powerpc.
>
> The below checks the kernel config to see if we are compiling little
> endian and sets the Debian arch appropriately.
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
>
> diff --git a/scripts/package/builddeb b/scripts/package/builddeb
> index 35d5a58..6f4a1af 100644
> --- a/scripts/package/builddeb
> +++ b/scripts/package/builddeb
> @@ -37,7 +37,7 @@ create_package() {
> s390*)
> debarch=s390$(grep -q CONFIG_64BIT=y $KCONFIG_CONFIG && echo x || true) ;;
> ppc*)
> - debarch=powerpc ;;
> + debarch=$(grep -q CPU_LITTLE_ENDIAN=y $KCONFIG_CONFIG && echo ppc64el || echo powerpc) ;;
> parisc*)
> debarch=hppa ;;
> mips*)
Gabriel
^ permalink raw reply
* [PATCH v2] deb-pkg: Add support for powerpc little endian
From: Michael Neuling @ 2014-09-05 7:55 UTC (permalink / raw)
To: Gabriel Paubert
Cc: Michal Marek, linux-kbuild, Ben Hutchings, linux-kernel,
Anton Blanchard, Leann Ogasawara, linuxppc-dev
In-Reply-To: <20140905071344.GA16024@visitor2.iram.es>
On Fri, 2014-09-05 at 09:13 +0200, Gabriel Paubert wrote:
> On Fri, Sep 05, 2014 at 03:28:47PM +1000, Michael Neuling wrote:
> > The Debian powerpc little endian architecture is called ppc64le. This
>=20
> Huh? ppc64le or ppc64el?
ppc64el. Commit message is wrong. Fixed below.
Mikey
From: Michael Neuling <mikey@neuling.org>
deb-pkg: Add support for powerpc little endian
The Debian powerpc little endian architecture is called ppc64el. This
is the default architecture used by Ubuntu for powerpc.
The below checks the kernel config to see if we are compiling little
endian and sets the Debian arch appropriately.
Signed-off-by: Michael Neuling <mikey@neuling.org>
diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index 35d5a58..6f4a1af 100644
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -37,7 +37,7 @@ create_package() {
s390*)
debarch=3Ds390$(grep -q CONFIG_64BIT=3Dy $KCONFIG_CONFIG && echo x || tr=
ue) ;;
ppc*)
- debarch=3Dpowerpc ;;
+ debarch=3D$(grep -q CPU_LITTLE_ENDIAN=3Dy $KCONFIG_CONFIG && echo ppc64e=
l || echo powerpc) ;;
parisc*)
debarch=3Dhppa ;;
mips*)
^ permalink raw reply related
* RE: bit fields && data tearing
From: David Laight @ 2014-09-05 8:30 UTC (permalink / raw)
To: 'paulmck@linux.vnet.ibm.com', Peter Hurley
Cc: Jakub Jelinek, One Thousand Gnomes, Tony Luck,
linux-ia64@vger.kernel.org, Mikael Pettersson, H. Peter Anvin,
Oleg Nesterov, linux-kernel@vger.kernel.org, James Bottomley,
Paul Mackerras, linux-arch@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, Miroslav Franc, Richard Henderson
In-Reply-To: <20140905040645.GO5001@linux.vnet.ibm.com>
RnJvbTogUGF1bCBFLiBNY0tlbm5leQ0KPiBPbiBUaHUsIFNlcCAwNCwgMjAxNCBhdCAxMDo0Nzoy
NFBNIC0wNDAwLCBQZXRlciBIdXJsZXkgd3JvdGU6DQo+ID4gSGkgSmFtZXMsDQo+ID4NCj4gPiBP
biAwOS8wNC8yMDE0IDEwOjExIFBNLCBKYW1lcyBCb3R0b21sZXkgd3JvdGU6DQo+ID4gPiBPbiBU
aHUsIDIwMTQtMDktMDQgYXQgMTc6MTcgLTA3MDAsIFBhdWwgRS4gTWNLZW5uZXkgd3JvdGU6DQo+
ID4gPj4gK0FuZCB0aGVyZSBhcmUgYW50aS1ndWFyYW50ZWVzOg0KPiA+ID4+ICsNCj4gPiA+PiAr
ICgqKSBUaGVzZSBndWFyYW50ZWVzIGRvIG5vdCBhcHBseSB0byBiaXRmaWVsZHMsIGJlY2F1c2Ug
Y29tcGlsZXJzIG9mdGVuDQo+ID4gPj4gKyAgICAgZ2VuZXJhdGUgY29kZSB0byBtb2RpZnkgdGhl
c2UgdXNpbmcgbm9uLWF0b21pYyByZWFkLW1vZGlmeS13cml0ZQ0KPiA+ID4+ICsgICAgIHNlcXVl
bmNlcy4gIERvIG5vdCBhdHRlbXB0IHRvIHVzZSBiaXRmaWVsZHMgdG8gc3luY2hyb25pemUgcGFy
YWxsZWwNCj4gPiA+PiArICAgICBhbGdvcml0aG1zLg0KPiA+ID4+ICsNCj4gPiA+PiArICgqKSBF
dmVuIGluIGNhc2VzIHdoZXJlIGJpdGZpZWxkcyBhcmUgcHJvdGVjdGVkIGJ5IGxvY2tzLCBhbGwg
ZmllbGRzDQo+ID4gPj4gKyAgICAgaW4gYSBnaXZlbiBiaXRmaWVsZCBtdXN0IGJlIHByb3RlY3Rl
ZCBieSBvbmUgbG9jay4gIElmIHR3byBmaWVsZHMNCj4gPiA+PiArICAgICBpbiBhIGdpdmVuIGJp
dGZpZWxkIGFyZSBwcm90ZWN0ZWQgYnkgZGlmZmVyZW50IGxvY2tzLCB0aGUgY29tcGlsZXIncw0K
PiA+ID4+ICsgICAgIG5vbi1hdG9taWMgcmVhZC1tb2RpZnktd3JpdGUgc2VxdWVuY2VzIGNhbiBj
YXVzZSBhbiB1cGRhdGUgdG8gb25lDQo+ID4gPj4gKyAgICAgZmllbGQgdG8gY29ycnVwdCB0aGUg
dmFsdWUgb2YgYW4gYWRqYWNlbnQgZmllbGQuDQo+ID4gPj4gKw0KPiA+ID4+ICsgKCopIFRoZXNl
IGd1YXJhbnRlZXMgYXBwbHkgb25seSB0byBwcm9wZXJseSBhbGlnbmVkIGFuZCBzaXplZCBzY2Fs
YXINCj4gPiA+PiArICAgICB2YXJpYWJsZXMuICAiUHJvcGVybHkgc2l6ZWQiIGN1cnJlbnRseSBt
ZWFucyAiaW50IiBhbmQgImxvbmciLA0KPiA+ID4+ICsgICAgIGJlY2F1c2Ugc29tZSBDUFUgZmFt
aWxpZXMgZG8gbm90IHN1cHBvcnQgbG9hZHMgYW5kIHN0b3JlcyBvZg0KPiA+ID4+ICsgICAgIG90
aGVyIHNpemVzLiAgKCJTb21lIENQVSBmYW1pbGllcyIgaXMgY3VycmVudGx5IGJlbGlldmVkIHRv
DQo+ID4gPj4gKyAgICAgYmUgb25seSBBbHBoYSAyMTA2NC4gIElmIHRoaXMgaXMgYWN0dWFsbHkg
dGhlIGNhc2UsIGEgZGlmZmVyZW50DQo+ID4gPj4gKyAgICAgbm9uLWd1YXJhbnRlZSBpcyBsaWtl
bHkgdG8gYmUgZm9ybXVsYXRlZC4pDQo+ID4gPg0KPiA+ID4gVGhpcyBpcyBhIGJpdCB1bmNsZWFy
LiAgUHJlc3VtYWJseSB5b3UncmUgdGFsa2luZyBhYm91dCBkZWZpbml0ZW5lc3Mgb2YNCj4gPiA+
IHRoZSBvdXRjb21lIChhcyBpbiB3aGF0J3Mgc2VlbiBhZnRlciBtdWx0aXBsZSBzdG9yZXMgdG8g
dGhlIHNhbWUNCj4gPiA+IHZhcmlhYmxlKS4NCj4gPg0KPiA+IE5vLCB0aGUgbGFzdCBjb25kaXRp
b25zIHJlZmVycyB0byBhZGphY2VudCBieXRlIHN0b3JlcyBmcm9tIGRpZmZlcmVudA0KPiA+IGNw
dSBjb250ZXh0cyAoZWl0aGVyIGludGVycnVwdCBvciBTTVApLg0KPiA+DQo+ID4gPiBUaGUgZ3Vh
cmFudGVlcyBhcmUgb25seSBmb3IgbmF0dXJhbCB3aWR0aCBvbiBQYXJpc2MgYXMgd2VsbCwNCj4g
PiA+IHNvIHlvdSB3b3VsZCBnZXQgYSBtZXNzIGlmIHlvdSBkaWQgYnl0ZSBzdG9yZXMgdG8gYWRq
YWNlbnQgbWVtb3J5DQo+ID4gPiBsb2NhdGlvbnMuDQo+ID4NCj4gPiBGb3IgYSBzaW1wbGUgdGVz
dCBsaWtlOg0KPiA+DQo+ID4gc3RydWN0IHggew0KPiA+IAlsb25nIGE7DQo+ID4gCWNoYXIgYjsN
Cj4gPiAJY2hhciBjOw0KPiA+IAljaGFyIGQ7DQo+ID4gCWNoYXIgZTsNCj4gPiB9Ow0KPiA+DQo+
ID4gdm9pZCBzdG9yZV9iYyhzdHJ1Y3QgeCAqcCkgew0KPiA+IAlwLT5iID0gMTsNCj4gPiAJcC0+
YyA9IDI7DQo+ID4gfQ0KPiA+DQo+ID4gb24gcGFyaXNjLCBnY2MgZ2VuZXJhdGVzIHNlcGFyYXRl
IGJ5dGUgc3RvcmVzDQo+ID4NCj4gPiB2b2lkIHN0b3JlX2JjKHN0cnVjdCB4ICpwKSB7DQo+ID4g
ICAgMDoJMzQgMWMgMDAgMDIgCWxkaSAxLHJldDANCj4gPiAgICA0OgkwZiA1YyAxMiAwOCAJc3Ri
IHJldDAsNChyMjYpDQo+ID4gICAgODoJMzQgMWMgMDAgMDQgCWxkaSAyLHJldDANCj4gPiAgICBj
OgllOCA0MCBjMCAwMCAJYnYgcjAocnApDQo+ID4gICAxMDoJMGYgNWMgMTIgMGEgCXN0YiByZXQw
LDUocjI2KQ0KPiA+DQo+ID4gd2hpY2ggYXBwZWFycyB0byBjb25maXJtIHRoYXQgb24gcGFyaXNj
IGFkamFjZW50IGJ5dGUgZGF0YQ0KPiA+IGlzIHNhZmUgZnJvbSBjb3JydXB0aW9uIGJ5IGNvbmN1
cnJlbnQgY3B1IHVwZGF0ZXM7IHRoYXQgaXMsDQo+ID4NCj4gPiBDUFUgMCAgICAgICAgICAgICAg
ICB8IENQVSAxDQo+ID4gICAgICAgICAgICAgICAgICAgICAgfA0KPiA+IHAtPmIgPSAxICAgICAg
ICAgICAgIHwgcC0+YyA9IDINCj4gPiAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4NCj4gPiB3
aWxsIHJlc3VsdCBpbiBwLT5iID09IDEgJiYgcC0+YyA9PSAyIChhc3N1bWUgYm90aCB2YWx1ZXMN
Cj4gPiB3ZXJlIDAgYmVmb3JlIHRoZSBjYWxsIHRvIHN0b3JlX2JjKCkpLg0KPiANCj4gV2hhdCBQ
ZXRlciBzYWlkLiAgSSB3b3VsZCBhc2sgZm9yIHN1Z2dlc3Rpb25zIGZvciBiZXR0ZXIgd29yZGlu
ZywgYnV0DQo+IEkgd291bGQgbXVjaCByYXRoZXIgYmUgYWJsZSB0byBzYXkgdGhhdCBzaW5nbGUt
Ynl0ZSByZWFkcyBhbmQgd3JpdGVzDQo+IGFyZSBhdG9taWMgYW5kIHRoYXQgYWxpZ25lZC1zaG9y
dCByZWFkcyBhbmQgd3JpdGVzIGFyZSBhbHNvIGF0b21pYy4NCj4gDQo+IFRodXMgZmFyLCBpdCBs
b29rcyBsaWtlIHdlIGxvc2Ugb25seSB2ZXJ5IG9sZCBBbHBoYSBzeXN0ZW1zLCBzbyB1bmxlc3MN
Cj4gSSBoZWFyIG90aGVyd2lzZSwgSSB1cGRhdGUgbXkgcGF0Y2ggdG8gb3V0bGF3IHRoZXNlIHZl
cnkgb2xkIHN5c3RlbXMuDQoNClBlb3BsZSB3aXRoIG9sZCBBbHBoYXMgY2FuIHJ1biBOZXRCU0Qg
aW5zdGVhZCwgYWxvbmcgd2l0aCB0aG9zZSB3aG8gaGF2ZSByZWFsIFZBWGVuIDotKQ0KDQpJJ3Zl
IHNlZW4gZ2NjIGdlbmVyYXRlIDMyYml0IGFjY2Vzc2VzIGZvciAxNmJpdCBzdHJ1Y3R1cmUgbWVt
YmVycyBvbiBhcm0uDQpJdCBkb2VzIHRoaXMgYmVjYXVzZSBvZiB0aGUgbW9yZSBsaW1pdGVkIHJh
bmdlIG9mIHRoZSBvZmZzZXRzIGZvciB0aGUgMTZiaXQgYWNjZXNzLg0KT1RPSCBJIGRvbid0IGtu
b3cgaWYgaXQgZXZlciBkaWQgdGhpcyBmb3Igd3JpdGVzIC0gc28gaXQgbWF5IGJlIG1vb3QuDQoN
CglEYXZpZA0KDQo=
^ permalink raw reply
* Re: bit fields && data tearing
From: Michael Cree @ 2014-09-05 8:16 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Jakub Jelinek, linux-arch@vger.kernel.org, Tony Luck,
linux-ia64@vger.kernel.org, Peter Hurley, Oleg Nesterov,
linux-kernel@vger.kernel.org, David Laight, Paul Mackerras,
linux-alpha, Paul E. McKenney, linuxppc-dev@lists.ozlabs.org,
Miroslav Franc, Richard Henderson
In-Reply-To: <54091B30.2090509@zytor.com>
On Thu, Sep 04, 2014 at 07:08:48PM -0700, H. Peter Anvin wrote:
> On 09/04/2014 05:59 PM, Peter Hurley wrote:
> > I have no idea how prevalent the ev56 is compared to the ev5.
> > Still we're talking about a chip that came out in 1996.
>
> Ah yes, I stand corrected. According to Wikipedia, the affected CPUs
> were all the 2106x CPUs (EV4, EV45, LCA4, LCA45) plus the 21164 with no
> suffix (EV5). However, we're still talking about museum pieces here.
Yes, that is correct, EV56 is the first Alpha CPU to have the byte-word
extension (BWX) CPU instructions.
It would not worry me if the kernel decided to assume atomic aligned
scalar accesses for all arches, thus terminating support for Alphas
without BWX.
The X server, ever since the libpciaccess change, does not work on
Alphas without BWX.
Debian Alpha (pretty much up to date at Debian-Ports) is still compiled
for all Alphas, i.e., without BWX. The last attempt to start compiling
Debian Alpha with BWX, about three years ago when Alpha was kicked out
to Debian-Ports resulted in a couple or so complaints so got nowhere.
It's frustrating supporting the lowest common demoninator as many of
the bugs specific to Alpha can be resolved by recompiling with the BWX.
The kernel no longer supporting Alphas without BWX might just be the
incentive we need to switch Debian Alpha to compiling with BWX.
Cheers
Michael.
^ permalink raw reply
* [PATCH] pseries: Make CPU hotplug path endian safe
From: bharata.rao @ 2014-09-05 9:16 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev, Bharata B Rao
From: Bharata B Rao <bharata@linux.vnet.ibm.com>
- ibm,rtas-configure-connector should treat the RTAS data as big endian.
- Treat ibm,ppc-interrupt-server#s as big-endian when setting
smp_processor_id during hotplug.
Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/dlpar.c | 10 +++++-----
arch/powerpc/platforms/pseries/hotplug-cpu.c | 4 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/dlpar.c b/arch/powerpc/platforms/pseries/dlpar.c
index 2d0b4d6..dc55f9c 100644
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -48,11 +48,11 @@ static struct property *dlpar_parse_cc_property(struct cc_workarea *ccwa)
if (!prop)
return NULL;
- name = (char *)ccwa + ccwa->name_offset;
+ name = (char *)ccwa + be32_to_cpu(ccwa->name_offset);
prop->name = kstrdup(name, GFP_KERNEL);
- prop->length = ccwa->prop_length;
- value = (char *)ccwa + ccwa->prop_offset;
+ prop->length = be32_to_cpu(ccwa->prop_length);
+ value = (char *)ccwa + be32_to_cpu(ccwa->prop_offset);
prop->value = kmemdup(value, prop->length, GFP_KERNEL);
if (!prop->value) {
dlpar_free_cc_property(prop);
@@ -78,7 +78,7 @@ static struct device_node *dlpar_parse_cc_node(struct cc_workarea *ccwa,
if (!dn)
return NULL;
- name = (char *)ccwa + ccwa->name_offset;
+ name = (char *)ccwa + be32_to_cpu(ccwa->name_offset);
dn->full_name = kasprintf(GFP_KERNEL, "%s/%s", path, name);
if (!dn->full_name) {
kfree(dn);
@@ -148,7 +148,7 @@ struct device_node *dlpar_configure_connector(u32 drc_index,
return NULL;
ccwa = (struct cc_workarea *)&data_buf[0];
- ccwa->drc_index = drc_index;
+ ccwa->drc_index = cpu_to_be32(drc_index);
ccwa->zero = 0;
do {
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index 20d6297..447f8c6 100644
--- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -247,7 +247,7 @@ static int pseries_add_processor(struct device_node *np)
unsigned int cpu;
cpumask_var_t candidate_mask, tmp;
int err = -ENOSPC, len, nthreads, i;
- const u32 *intserv;
+ const __be32 *intserv;
intserv = of_get_property(np, "ibm,ppc-interrupt-server#s", &len);
if (!intserv)
@@ -293,7 +293,7 @@ static int pseries_add_processor(struct device_node *np)
for_each_cpu(cpu, tmp) {
BUG_ON(cpu_present(cpu));
set_cpu_present(cpu, true);
- set_hard_smp_processor_id(cpu, *intserv++);
+ set_hard_smp_processor_id(cpu, be32_to_cpu(*intserv++));
}
err = 0;
out_unlock:
--
1.7.11.7
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox