* Re: [PATCH v1 15/21] Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
From: Sergei Shtylyov @ 2014-09-05 10:47 UTC (permalink / raw)
To: Yijing Wang, Bjorn Helgaas
Cc: linux-mips, linux-ia64, linux-pci, Bharat.Bhushan, sparclinux,
linux-arch, linux-s390, Russell King, Joerg Roedel, x86,
Sebastian Ott, xen-devel, arnab.basu, Arnd Bergmann,
Konrad Rzeszutek Wilk, Chris Metcalf, Thomas Gleixner,
linux-arm-kernel, Xinwei Hu, Tony Luck, Ralf Baechle, iommu,
Wuyun, linuxppc-dev, David S. Miller
In-Reply-To: <1409911806-10519-16-git-send-email-wangyijing@huawei.com>
Hello.
On 9/5/2014 2:10 PM, Yijing Wang wrote:
> Use MSI chip framework instead of arch MSI functions to configure
> MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
> Signed-off-by: Yijing Wang <wangyijing@huawei.com>
> ---
> arch/powerpc/kernel/msi.c | 14 ++++++++++++--
> 1 files changed, 12 insertions(+), 2 deletions(-)
> diff --git a/arch/powerpc/kernel/msi.c b/arch/powerpc/kernel/msi.c
> index 71bd161..01781a4 100644
> --- a/arch/powerpc/kernel/msi.c
> +++ b/arch/powerpc/kernel/msi.c
[...]
> @@ -27,7 +27,17 @@ int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
> return ppc_md.setup_msi_irqs(dev, nvec, type);
> }
>
> -void arch_teardown_msi_irqs(struct pci_dev *dev)
> +static void ppc_teardown_msi_irqs(struct pci_dev *dev)
Shouldn't this function take IRQ # instead?
> {
> ppc_md.teardown_msi_irqs(dev);
> }
> +
> +static struct msi_chip ppc_msi_chip = {
> + .setup_irqs = ppc_setup_msi_irqs,
> + .teardown_irqs = ppc_teardown_msi_irqs,
> +};
> +
> +struct msi_chip *arch_find_msi_chip(struct pci_dev *dev)
> +{
> + return &ppc_msi_chip;
> +}
WBR, Sergei
^ permalink raw reply
* [PATCH 1/2][v4] powerpc/fsl-booke: Add initial T1040/T1042 RDB board support
From: Priyanka Jain @ 2014-09-05 10:44 UTC (permalink / raw)
To: linuxppc-dev, devicetree, scottwood
Cc: Priyanka Jain, Poonam Aggrwal, Prabhakar Kushwaha
T1040/T1042RDB is Freescale Reference Design Board.
The board can support both T1040/T1042 QorIQ Power Architecture™ processor.
T1040/T1042RDB board Overview
-----------------------
- SERDES Connections, 8 lanes supporting:
- PCI
- SGMII
- QSGMII
- SATA 2.0
- DDR Controller
- Supports rates of up to 1600 MHz data-rate
- Supports one DDR3LP UDIMM
-IFC/Local Bus
- NAND flash: 1GB 8-bit NAND flash
- NOR: 128MB 16-bit NOR Flash
- Ethernet
- Two on-board RGMII 10/100/1G ethernet ports.
- PHY #0 remains powered up during deep-sleep
- CPLD
- Clocks
- System and DDR clock (SYSCLK, “DDRCLK”)
- SERDES clocks
- Power Supplies
- USB
- Supports two USB 2.0 ports with integrated PHYs
- Two type A ports with 5V@1.5A per port.
- SDHC
- SDHC/SDXC connector
- SPI
- On-board 64MB SPI flash
- I2C
- Devices connected: EEPROM, thermal monitor, VID controller
- Other IO
- Two Serial ports
- ProfiBus port
Add support for T1040/T1042 RDB board:
-add device tree
-add entry in Kconfig to build
-Add entry in corenet_generic.c, as it is similar to other corenet platforms
Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
---
changes for v4: Updated cpld compatible string field
changes for v3: Incorporated Scott comments on moving cpld compatible
field to board specific file as cpld binaries are different
changes for v2: Incorporated Scott comments on using common name
for compatible string for cpld as register set is same
arch/powerpc/boot/dts/t1040rdb.dts | 48 ++++++++
arch/powerpc/boot/dts/t1042rdb.dts | 48 ++++++++
arch/powerpc/boot/dts/t104xrdb.dtsi | 156 +++++++++++++++++++++++++
arch/powerpc/platforms/85xx/Kconfig | 2 +-
arch/powerpc/platforms/85xx/corenet_generic.c | 2 +
5 files changed, 255 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/boot/dts/t1040rdb.dts
create mode 100644 arch/powerpc/boot/dts/t1042rdb.dts
create mode 100644 arch/powerpc/boot/dts/t104xrdb.dtsi
diff --git a/arch/powerpc/boot/dts/t1040rdb.dts b/arch/powerpc/boot/dts/t1040rdb.dts
new file mode 100644
index 0000000..79a0bed
--- /dev/null
+++ b/arch/powerpc/boot/dts/t1040rdb.dts
@@ -0,0 +1,48 @@
+/*
+ * T1040RDB Device Tree Source
+ *
+ * Copyright 2014 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/t104xsi-pre.dtsi"
+/include/ "t104xrdb.dtsi"
+
+/ {
+ model = "fsl,T1040RDB";
+ compatible = "fsl,T1040RDB";
+ ifc: localbus@ffe124000 {
+ cpld@3,0 {
+ compatible = "fsl,t1040rdb-cpld";
+ };
+ };
+};
+
+/include/ "fsl/t1040si-post.dtsi"
diff --git a/arch/powerpc/boot/dts/t1042rdb.dts b/arch/powerpc/boot/dts/t1042rdb.dts
new file mode 100644
index 0000000..228a635
--- /dev/null
+++ b/arch/powerpc/boot/dts/t1042rdb.dts
@@ -0,0 +1,48 @@
+/*
+ * T1042RDB Device Tree Source
+ *
+ * Copyright 2014 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/t104xsi-pre.dtsi"
+/include/ "t104xrdb.dtsi"
+
+/ {
+ model = "fsl,T1042RDB";
+ compatible = "fsl,T1042RDB";
+ ifc: localbus@ffe124000 {
+ cpld@3,0 {
+ compatible = "fsl,t1042rdb-cpld";
+ };
+ };
+};
+
+/include/ "fsl/t1042si-post.dtsi"
diff --git a/arch/powerpc/boot/dts/t104xrdb.dtsi b/arch/powerpc/boot/dts/t104xrdb.dtsi
new file mode 100644
index 0000000..1cf0f3c
--- /dev/null
+++ b/arch/powerpc/boot/dts/t104xrdb.dtsi
@@ -0,0 +1,156 @@
+/*
+ * T1040RDB/T1042RDB Device Tree Source
+ *
+ * Copyright 2014 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: localbus@ffe124000 {
+ reg = <0xf 0xfe124000 0 0x2000>;
+ ranges = <0 0 0xf 0xe8000000 0x08000000
+ 2 0 0xf 0xff800000 0x00010000
+ 3 0 0xf 0xffdf0000 0x00008000>;
+
+ nor@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x8000000>;
+ bank-width = <2>;
+ device-width = <1>;
+ };
+
+ nand@2,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,ifc-nand";
+ reg = <0x2 0x0 0x10000>;
+ };
+
+ cpld@3,0 {
+ reg = <3 0 0x300>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ };
+
+ dcsr: dcsr@f00000000 {
+ ranges = <0x00000000 0xf 0x00000000 0x01072000>;
+ };
+
+ soc: soc@ffe000000 {
+ ranges = <0x00000000 0xf 0xfe000000 0x1000000>;
+ reg = <0xf 0xfe000000 0 0x00001000>;
+
+ spi@110000 {
+ flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "micron,n25q512a";
+ reg = <0>;
+ spi-max-frequency = <10000000>; /* input clock */
+ };
+ };
+
+ i2c@118100 {
+ pca9546@77 {
+ compatible = "nxp,pca9546";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ };
+
+ pci0: pcie@ffe240000 {
+ reg = <0xf 0xfe240000 0 0x10000>;
+ ranges = <0x02000000 0 0xe0000000 0xc 0x00000000 0x0 0x10000000
+ 0x01000000 0 0x00000000 0xf 0xf8000000 0x0 0x00010000>;
+ pcie@0 {
+ ranges = <0x02000000 0 0xe0000000
+ 0x02000000 0 0xe0000000
+ 0 0x10000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+
+ pci1: pcie@ffe250000 {
+ reg = <0xf 0xfe250000 0 0x10000>;
+ ranges = <0x02000000 0x0 0xe0000000 0xc 0x10000000 0x0 0x10000000
+ 0x01000000 0x0 0x00000000 0xf 0xf8010000 0x0 0x00010000>;
+ pcie@0 {
+ ranges = <0x02000000 0 0xe0000000
+ 0x02000000 0 0xe0000000
+ 0 0x10000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+
+ pci2: pcie@ffe260000 {
+ reg = <0xf 0xfe260000 0 0x10000>;
+ ranges = <0x02000000 0 0xe0000000 0xc 0x20000000 0 0x10000000
+ 0x01000000 0 0x00000000 0xf 0xf8020000 0 0x00010000>;
+ pcie@0 {
+ ranges = <0x02000000 0 0xe0000000
+ 0x02000000 0 0xe0000000
+ 0 0x10000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+
+ pci3: pcie@ffe270000 {
+ reg = <0xf 0xfe270000 0 0x10000>;
+ ranges = <0x02000000 0 0xe0000000 0xc 0x30000000 0 0x10000000
+ 0x01000000 0 0x00000000 0xf 0xf8030000 0 0x00010000>;
+ pcie@0 {
+ ranges = <0x02000000 0 0xe0000000
+ 0x02000000 0 0xe0000000
+ 0 0x10000000
+
+ 0x01000000 0 0x00000000
+ 0x01000000 0 0x00000000
+ 0 0x00010000>;
+ };
+ };
+};
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index 5063696..157a1a4 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -276,7 +276,7 @@ config CORENET_GENERIC
For 64bit kernel, the following boards are supported:
T208x QDS, T4240 QDS/RDB and B4 QDS
The following boards are supported for both 32bit and 64bit kernel:
- P5020 DS, P5040 DS and T104xQDS
+ P5020 DS, P5040 DS and T104xQDS/RDB
endif # FSL_SOC_BOOKE
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c b/arch/powerpc/platforms/85xx/corenet_generic.c
index 4f22ad1..c268f89 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -128,6 +128,8 @@ static const char * const boards[] __initconst = {
"fsl,B4220QDS",
"fsl,T1040QDS",
"fsl,T1042QDS",
+ "fsl,T1040RDB",
+ "fsl,T1042RDB",
"keymile,kmcoge4",
NULL
};
^ permalink raw reply related
* [PATCH 2/2][v4] powerpc/fsl-booke: Add initial T1042RDB_PI board support
From: Priyanka Jain @ 2014-09-05 10:45 UTC (permalink / raw)
To: linuxppc-dev, devicetree, scottwood
Cc: Priyanka Jain, Poonam Aggrwal, Prabhakar Kushwaha
T1042RDB_PI is Freescale Reference Design Board supporting the T1042
QorIQ Power Architecture™ processor. T1042 is a reduced personality
of T1040 SoC without Integrated 8-port Gigabit. The board is designed
with low power features targeted for Printing Image Market.
T1042RDB_PI is similar to T1040RDB board with few differences like
it has video interface, supports T1042 personality only
T1042RDB_PI board Overview
-----------------------
- SERDES Connections, 8 lanes supporting:
- PCI
- SATA 2.0
- DDR Controller
- Supports rates of up to 1600 MHz data-rate
- Supports one DDR3LP UDIMM
-IFC/Local Bus
- NAND flash: 1GB 8-bit NAND flash
- NOR: 128MB 16-bit NOR Flash
- Ethernet
- Two on-board RGMII 10/100/1G ethernet ports.
- PHY #0 remains powered up during deep-sleep
- CPLD
- Clocks
- System and DDR clock (SYSCLK, “DDRCLK”)
- SERDES clocks
- Power Supplies
- USB
- Supports two USB 2.0 ports with integrated PHYs
- Two type A ports with 5V@1.5A per port.
- SDHC
- SDHC/SDXC connector
- SPI
- On-board 64MB SPI flash
- I2C
- Device connected: EEPROM, thermal monitor, VID controller, RTC
- Other IO
- Two Serial ports
- ProfiBus port
Add support for T1042RDB_PI board:
-add device tree
-Add entry in corenet_generic.c, as it is similar to other corenet platforms
Signed-off-by: Poonam Aggrwal <poonam.aggrwal@freescale.com>
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
---
changes for v4: Updated cpld compatible string field
changes for v3: Incorporated Scott comments on moving cpld compatible
field to board specific file as cpld binaries are different
changes for v2: Incorporated Scott comments on using common name
for compatible string for cpld as register set is same
arch/powerpc/boot/dts/t1042rdb_pi.dts | 57 +++++++++++++++++++++++++
arch/powerpc/platforms/85xx/corenet_generic.c | 1 +
2 files changed, 58 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/t1042rdb_pi.dts
diff --git a/arch/powerpc/boot/dts/t1042rdb_pi.dts b/arch/powerpc/boot/dts/t1042rdb_pi.dts
new file mode 100644
index 0000000..b9d0877
--- /dev/null
+++ b/arch/powerpc/boot/dts/t1042rdb_pi.dts
@@ -0,0 +1,57 @@
+/*
+ * T1042RDB_PI Device Tree Source
+ *
+ * Copyright 2014 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/t104xsi-pre.dtsi"
+/include/ "t104xrdb.dtsi"
+
+/ {
+ model = "fsl,T1042RDB_PI";
+ compatible = "fsl,T1042RDB_PI";
+ ifc: localbus@ffe124000 {
+ cpld@3,0 {
+ compatible = "fsl,t1042rdb_pi-cpld";
+ };
+ };
+ soc: soc@ffe000000 {
+ i2c@118000 {
+ rtc@68 {
+ compatible = "dallas,ds1337";
+ reg = <0x68>;
+ interrupts = <0x2 0x1 0 0>;
+ };
+ };
+ };
+};
+
+/include/ "fsl/t1042si-post.dtsi"
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c b/arch/powerpc/platforms/85xx/corenet_generic.c
index c268f89..100e80d 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -130,6 +130,7 @@ static const char * const boards[] __initconst = {
"fsl,T1042QDS",
"fsl,T1040RDB",
"fsl,T1042RDB",
+ "fsl,T1042RDB_PI",
"keymile,kmcoge4",
NULL
};
^ permalink raw reply related
* Re: [PATCH v1 09/21] Irq_remapping/MSI: Use MSI chip framework to configure MSI/MSI-X irq
From: wangyijing @ 2014-09-05 11:30 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: linux-mips@linux-mips.org, linux-ia64@vger.kernel.org,
linux-pci@vger.kernel.org, Bharat.Bhushan@freescale.com,
sparclinux@vger.kernel.org, Yijing Wang,
linux-arch@vger.kernel.org, linux-s390@vger.kernel.org,
Russell King, Joerg Roedel, x86@kernel.org, Sebastian Ott,
xen-devel@lists.xenproject.org, arnab.basu@freescale.com,
Arnd Bergmann, Konrad Rzeszutek Wilk, Chris Metcalf,
Bjorn Helgaas, Thomas Gleixner,
linux-arm-kernel@lists.infradead.org, Xinwei Hu, Tony Luck,
Ralf Baechle, iommu@lists.linux-foundation.org, Wuyun,
linuxppc-dev@lists.ozlabs.org, David S. Miller
In-Reply-To: <540993B3.1000701@cogentembedded.com>
> =D4=DA 2014=C4=EA9=D4=C25=C8=D5=A3=AC18:42=A3=ACSergei Shtylyov <sergei.sh=
tylyov@cogentembedded.com> =D0=B4=B5=C0=A3=BA
>=20
> Hello.
>=20
>> On 9/5/2014 2:09 PM, Yijing Wang wrote:
>>=20
>> Use MSI chip framework instead of arch MSI functions to configure
>> MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
>=20
>> Signed-off-by: Yijing Wang <wangyijing@huawei.com>
>> ---
>> drivers/iommu/irq_remapping.c | 8 +++++++-
>> 1 files changed, 7 insertions(+), 1 deletions(-)
>=20
>> diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.=
c
>> index 33c4395..e75026e 100644
>> --- a/drivers/iommu/irq_remapping.c
>> +++ b/drivers/iommu/irq_remapping.c
> [...]
>> @@ -165,9 +170,10 @@ static void __init irq_remapping_modify_x86_ops(void=
)
>> x86_io_apic_ops.set_affinity =3D set_remapped_irq_affinity;
>> x86_io_apic_ops.setup_entry =3D setup_ioapic_remapped_entry;
>> x86_io_apic_ops.eoi_ioapic_pin =3D eoi_ioapic_pin_remapped;
>> - x86_msi.setup_msi_irqs =3D irq_remapping_setup_msi_irqs;
>> + x86_msi.setup_msi_irqs =3D irq_remapping_setup_msi_irqs;
>=20
> AFAICS, this change only converts tabs to spaces, so not needed at all.
Will update, thanks.
>=20
>> x86_msi.setup_hpet_msi =3D setup_hpet_msi_remapped;
>> x86_msi.compose_msi_msg =3D compose_remapped_msi_msg;
>> + x86_msi_chip =3D &remap_msi_chip;
>=20
> Please align =3D with the rest of assignments.
Ok.
Thanks!
Yijing.
>=20
> WBR, Sergei
>=20
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v1 15/21] Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
From: wangyijing @ 2014-09-05 11:33 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: linux-mips@linux-mips.org, linux-ia64@vger.kernel.org,
linux-pci@vger.kernel.org, Bharat.Bhushan@freescale.com,
sparclinux@vger.kernel.org, Yijing Wang,
linux-arch@vger.kernel.org, linux-s390@vger.kernel.org,
Russell King, Joerg Roedel, x86@kernel.org, Sebastian Ott,
xen-devel@lists.xenproject.org, arnab.basu@freescale.com,
Arnd Bergmann, Konrad Rzeszutek Wilk, Chris Metcalf,
Bjorn Helgaas, Thomas Gleixner,
linux-arm-kernel@lists.infradead.org, Xinwei Hu, Tony Luck,
Ralf Baechle, iommu@lists.linux-foundation.org, Wuyun,
linuxppc-dev@lists.ozlabs.org, David S. Miller
In-Reply-To: <540994D4.6040500@cogentembedded.com>
> =D4=DA 2014=C4=EA9=D4=C25=C8=D5=A3=AC18:47=A3=ACSergei Shtylyov <sergei.sh=
tylyov@cogentembedded.com> =D0=B4=B5=C0=A3=BA
>=20
> Hello.
>=20
>> On 9/5/2014 2:10 PM, Yijing Wang wrote:
>>=20
>> Use MSI chip framework instead of arch MSI functions to configure
>> MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
>=20
>> Signed-off-by: Yijing Wang <wangyijing@huawei.com>
>> ---
>> arch/powerpc/kernel/msi.c | 14 ++++++++++++--
>> 1 files changed, 12 insertions(+), 2 deletions(-)
>=20
>> diff --git a/arch/powerpc/kernel/msi.c b/arch/powerpc/kernel/msi.c
>> index 71bd161..01781a4 100644
>> --- a/arch/powerpc/kernel/msi.c
>> +++ b/arch/powerpc/kernel/msi.c
> [...]
>> @@ -27,7 +27,17 @@ int arch_setup_msi_irqs(struct pci_dev *dev, int nvec,=
int type)
>> return ppc_md.setup_msi_irqs(dev, nvec, type);
>> }
>>=20
>> -void arch_teardown_msi_irqs(struct pci_dev *dev)
>> +static void ppc_teardown_msi_irqs(struct pci_dev *dev)
>=20
> Shouldn't this function take IRQ # instead?
This function need to teardown all msi irqs of the pci dev, we should pass t=
he pci dev as argument .
Thanks!
Yijing.
>=20
>> {
>> ppc_md.teardown_msi_irqs(dev);
>> }
>> +
>> +static struct msi_chip ppc_msi_chip =3D {
>> + .setup_irqs =3D ppc_setup_msi_irqs,
>> + .teardown_irqs =3D ppc_teardown_msi_irqs,
>> +};
>> +
>> +struct msi_chip *arch_find_msi_chip(struct pci_dev *dev)
>> +{
>> + return &ppc_msi_chip;
>> +}
>=20
> WBR, Sergei
>=20
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v1 15/21] Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
From: Sergei Shtylyov @ 2014-09-05 11:41 UTC (permalink / raw)
To: wangyijing
Cc: linux-mips@linux-mips.org, linux-ia64@vger.kernel.org,
linux-pci@vger.kernel.org, Bharat.Bhushan@freescale.com,
sparclinux@vger.kernel.org, Yijing Wang,
linux-arch@vger.kernel.org, linux-s390@vger.kernel.org,
Russell King, Joerg Roedel, x86@kernel.org, Sebastian Ott,
xen-devel@lists.xenproject.org, arnab.basu@freescale.com,
Arnd Bergmann, Konrad Rzeszutek Wilk, Chris Metcalf,
Bjorn Helgaas, Thomas Gleixner,
linux-arm-kernel@lists.infradead.org, Xinwei Hu, Tony Luck,
Ralf Baechle, iommu@lists.linux-foundation.org, Wuyun,
linuxppc-dev@lists.ozlabs.org, David S. Miller
In-Reply-To: <43412AE0-85BB-4B4B-A4EA-2C6D3B8B85D7@gmail.com>
On 9/5/2014 3:33 PM, wangyijing wrote:
>>> Use MSI chip framework instead of arch MSI functions to configure
>>> MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
>>> Signed-off-by: Yijing Wang <wangyijing@huawei.com>
>>> ---
>>> arch/powerpc/kernel/msi.c | 14 ++++++++++++--
>>> 1 files changed, 12 insertions(+), 2 deletions(-)
>>> diff --git a/arch/powerpc/kernel/msi.c b/arch/powerpc/kernel/msi.c
>>> index 71bd161..01781a4 100644
>>> --- a/arch/powerpc/kernel/msi.c
>>> +++ b/arch/powerpc/kernel/msi.c
>> [...]
>>> @@ -27,7 +27,17 @@ int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
>>> return ppc_md.setup_msi_irqs(dev, nvec, type);
>>> }
>>>
>>> -void arch_teardown_msi_irqs(struct pci_dev *dev)
>>> +static void ppc_teardown_msi_irqs(struct pci_dev *dev)
>> Shouldn't this function take IRQ # instead?
> This function need to teardown all msi irqs of the pci dev, we should pass the pci dev as argument .
Ah, I've mixed up the teardown_irqs() method with teardown_irq()! Too
similar. :-)
> Thanks!
> Yijing.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH v2] deb-pkg: Add support for powerpc little endian
From: Thadeu Lima de Souza Cascardo @ 2014-09-05 12:09 UTC (permalink / raw)
To: Michael Neuling
Cc: Michal Marek, linux-kbuild, linuxppc-dev, linux-kernel,
Anton Blanchard, Leann Ogasawara, Ben Hutchings
In-Reply-To: <1409903718.11359.30.camel@ale.ozlabs.ibm.com>
On Fri, Sep 05, 2014 at 05:55:18PM +1000, Michael Neuling wrote:
> 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
> >
> > Huh? ppc64le or ppc64el?
>
> ppc64el. Commit message is wrong. Fixed below.
>
> Mikey
>
>
What about ppc64?
Also, I sent that already a month ago. Both linuxppc-dev and Michal
Marek were on cc.
http://marc.info/?l=linux-kernel&m=140744360328562&w=2
Cascardo.
> 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=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*)
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH v2] deb-pkg: Add support for powerpc little endian
From: Josh Boyer @ 2014-09-05 12:14 UTC (permalink / raw)
To: Michael Neuling
Cc: Michal Marek, linux-kbuild@vger.kernel.org, Ben Hutchings,
linux-kernel, Anton Blanchard, Leann Ogasawara, linuxppc-dev
In-Reply-To: <1409903718.11359.30.camel@ale.ozlabs.ibm.com>
On Fri, Sep 5, 2014 at 3:55 AM, Michael Neuling <mikey@neuling.org> wrote:
> 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
>>
>> Huh? ppc64le or ppc64el?
>
> ppc64el. Commit message is wrong. Fixed below.
Yay! Just like every other architecture, we continue to have the deb
based distros call it one thing, and the RPM based distros call it
another. At least we're consistent in our inconsistency.
josh
^ permalink raw reply
* Re: bit fields && data tearing
From: Peter Hurley @ 2014-09-05 12:31 UTC (permalink / raw)
To: David Laight, 'paulmck@linux.vnet.ibm.com'
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, linux-arm,
linuxppc-dev@lists.ozlabs.org, Miroslav Franc, Richard Henderson
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D17487F66@AcuExch.aculab.com>
[ +cc linux-arm ]
Hi David,
On 09/05/2014 04:30 AM, David Laight wrote:
> I've seen gcc generate 32bit accesses for 16bit structure members on arm.
> It does this because of the more limited range of the offsets for the 16bit access.
> OTOH I don't know if it ever did this for writes - so it may be moot.
Can you recall the particulars, like what ARM config or what code?
I tried an overly-simple test to see if gcc would bump up to the word load for
the 12-bit offset mode, but it stuck with register offset rather than immediate
offset. [I used the compiler options for allmodconfig and a 4.8 cross-compiler.]
Maybe the test doesn't generate enough register pressure on the compiler?
Regards,
Peter Hurley
#define ARRAY_SIZE(x) (sizeof(x)/sizeof((x)[0]))
struct x {
long unused[64];
short b[12];
int unused2[10];
short c;
};
void store_c(struct x *p, short a[]) {
int i;
for (i = 0; i < ARRAY_SIZE(p->b); i++)
p->b[i] = a[i];
p->c = 2;
}
void store_c(struct x *p, short a[]) {
0: e1a0c00d mov ip, sp
4: e3a03000 mov r3, #0
8: e92dd800 push {fp, ip, lr, pc}
c: e24cb004 sub fp, ip, #4
int i;
for (i = 0; i < ARRAY_SIZE(p->b); i++)
p->b[i] = a[i];
10: e191c0b3 ldrh ip, [r1, r3]
14: e0802003 add r2, r0, r3
18: e2822c01 add r2, r2, #256 ; 0x100
1c: e2833002 add r3, r3, #2
20: e3530018 cmp r3, #24
24: e1c2c0b0 strh ip, [r2]
28: 1afffff8 bne 10 <store_c+0x10>
p->c = 2;
2c: e3a03d05 mov r3, #320 ; 0x140
30: e3a02002 mov r2, #2
34: e18020b3 strh r2, [r0, r3]
38: e89da800 ldm sp, {fp, sp, pc}
^ permalink raw reply
* RE: bit fields && data tearing
From: David Laight @ 2014-09-05 12:37 UTC (permalink / raw)
To: 'Peter Hurley', 'paulmck@linux.vnet.ibm.com'
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,
linux-arm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Miroslav Franc, Richard Henderson
In-Reply-To: <5409AD0A.5090305@hurleysoftware.com>
RnJvbTogUGV0ZXIgSHVybGV5DQo+IFsgK2NjIGxpbnV4LWFybSBdDQo+IA0KPiBIaSBEYXZpZCwN
Cj4gDQo+IE9uIDA5LzA1LzIwMTQgMDQ6MzAgQU0sIERhdmlkIExhaWdodCB3cm90ZToNCj4gPiBJ
J3ZlIHNlZW4gZ2NjIGdlbmVyYXRlIDMyYml0IGFjY2Vzc2VzIGZvciAxNmJpdCBzdHJ1Y3R1cmUg
bWVtYmVycyBvbiBhcm0uDQo+ID4gSXQgZG9lcyB0aGlzIGJlY2F1c2Ugb2YgdGhlIG1vcmUgbGlt
aXRlZCByYW5nZSBvZiB0aGUgb2Zmc2V0cyBmb3IgdGhlIDE2Yml0IGFjY2Vzcy4NCj4gPiBPVE9I
IEkgZG9uJ3Qga25vdyBpZiBpdCBldmVyIGRpZCB0aGlzIGZvciB3cml0ZXMgLSBzbyBpdCBtYXkg
YmUgbW9vdC4NCj4gDQo+IENhbiB5b3UgcmVjYWxsIHRoZSBwYXJ0aWN1bGFycywgbGlrZSB3aGF0
IEFSTSBjb25maWcgb3Igd2hhdCBjb2RlPw0KPiANCj4gSSB0cmllZCBhbiBvdmVybHktc2ltcGxl
IHRlc3QgdG8gc2VlIGlmIGdjYyB3b3VsZCBidW1wIHVwIHRvIHRoZSB3b3JkIGxvYWQgZm9yDQo+
IHRoZSAxMi1iaXQgb2Zmc2V0IG1vZGUsIGJ1dCBpdCBzdHVjayB3aXRoIHJlZ2lzdGVyIG9mZnNl
dCByYXRoZXIgdGhhbiBpbW1lZGlhdGUNCj4gb2Zmc2V0LiBbSSB1c2VkIHRoZSBjb21waWxlciBv
cHRpb25zIGZvciBhbGxtb2Rjb25maWcgYW5kIGEgNC44IGNyb3NzLWNvbXBpbGVyLl0NCj4gDQo+
IE1heWJlIHRoZSB0ZXN0IGRvZXNuJ3QgZ2VuZXJhdGUgZW5vdWdoIHJlZ2lzdGVyIHByZXNzdXJl
IG9uIHRoZSBjb21waWxlcj8NCg0KRHVubm8sIEkgd291bGQgaGF2ZSBiZWVuIHVzaW5nIGEgbXVj
aCBvbGRlciB2ZXJzaW9uIG9mIHRoZSBjb21waWxlci4NCkl0IGlzIHBvc3NpYmxlIHRoYXQgaXQg
ZG9lc24ndCBkbyBpdCBhbnkgbW9yZS4NCkl0IG1pZ2h0IG9ubHkgaGF2ZSBkb25lIGl0IGZvciBs
b2Fkcy4NCg0KVGhlIGNvbXBpbGVyIHVzZWQgdG8gdXNlIG1pc2FsaWduZWQgMzJiaXQgbG9hZHMg
Zm9yIHN0cnVjdHVyZQ0KbWVtYmVycyBvbiBsYXJnZSA0bisyIGJ5dGUgYm91bmRhcmllcyBhcyB3
ZWxsLg0KSSdtIHByZXR0eSBzdXJlIGl0IGRvZXNuJ3QgZG8gdGhhdCBlaXRoZXIuDQoNClRoZXJl
IGhhdmUgYmVlbiBhIGxvdCBvZiBjb21waWxlciB2ZXJzaW9ucyBzaW5jZSBJIHdhcyBjb21waWxp
bmcNCmFueXRoaW5nIGZvciBhcm0uDQoNCglEYXZpZA0KDQo+IFJlZ2FyZHMsDQo+IFBldGVyIEh1
cmxleQ0KPiANCj4gI2RlZmluZSBBUlJBWV9TSVpFKHgpICAoc2l6ZW9mKHgpL3NpemVvZigoeClb
MF0pKQ0KPiANCj4gc3RydWN0IHggew0KPiAJbG9uZyB1bnVzZWRbNjRdOw0KPiAJc2hvcnQgYlsx
Ml07DQo+IAlpbnQgdW51c2VkMlsxMF07DQo+IAlzaG9ydCBjOw0KPiB9Ow0KPiANCj4gdm9pZCBz
dG9yZV9jKHN0cnVjdCB4ICpwLCBzaG9ydCBhW10pIHsNCj4gCWludCBpOw0KPiANCj4gCWZvciAo
aSA9IDA7IGkgPCBBUlJBWV9TSVpFKHAtPmIpOyBpKyspDQo+IAkJcC0+YltpXSA9IGFbaV07DQo+
IAlwLT5jID0gMjsNCj4gfQ0KPiANCj4gDQo+IHZvaWQgc3RvcmVfYyhzdHJ1Y3QgeCAqcCwgc2hv
cnQgYVtdKSB7DQo+ICAgIDA6CWUxYTBjMDBkIAltb3YJaXAsIHNwDQo+ICAgIDQ6CWUzYTAzMDAw
IAltb3YJcjMsICMwDQo+ICAgIDg6CWU5MmRkODAwIAlwdXNoCXtmcCwgaXAsIGxyLCBwY30NCj4g
ICAgYzoJZTI0Y2IwMDQgCXN1YglmcCwgaXAsICM0DQo+IAlpbnQgaTsNCj4gDQo+IAlmb3IgKGkg
PSAwOyBpIDwgQVJSQVlfU0laRShwLT5iKTsgaSsrKQ0KPiAJCXAtPmJbaV0gPSBhW2ldOw0KPiAg
IDEwOgllMTkxYzBiMyAJbGRyaAlpcCwgW3IxLCByM10NCj4gICAxNDoJZTA4MDIwMDMgCWFkZAly
MiwgcjAsIHIzDQo+ICAgMTg6CWUyODIyYzAxIAlhZGQJcjIsIHIyLCAjMjU2CTsgMHgxMDANCj4g
ICAxYzoJZTI4MzMwMDIgCWFkZAlyMywgcjMsICMyDQo+ICAgMjA6CWUzNTMwMDE4IAljbXAJcjMs
ICMyNA0KPiAgIDI0OgllMWMyYzBiMCAJc3RyaAlpcCwgW3IyXQ0KPiAgIDI4OgkxYWZmZmZmOCAJ
Ym5lCTEwIDxzdG9yZV9jKzB4MTA+DQo+IAlwLT5jID0gMjsNCj4gICAyYzoJZTNhMDNkMDUgCW1v
dglyMywgIzMyMAk7IDB4MTQwDQo+ICAgMzA6CWUzYTAyMDAyIAltb3YJcjIsICMyDQo+ICAgMzQ6
CWUxODAyMGIzIAlzdHJoCXIyLCBbcjAsIHIzXQ0KPiAgIDM4OgllODlkYTgwMCAJbGRtCXNwLCB7
ZnAsIHNwLCBwY30NCg0K
^ permalink raw reply
* Re: [PATCH v2] iommu/fsl: Fix warning resulting from adding PCI device twice
From: Joerg Roedel @ 2014-09-05 14:04 UTC (permalink / raw)
To: Varun Sethi
Cc: linuxppc-dev, iommu, alex.williamson, Emilian.Medve, linux-kernel
In-Reply-To: <1409830725-4469-1-git-send-email-Varun.Sethi@freescale.com>
On Thu, Sep 04, 2014 at 05:08:45PM +0530, Varun Sethi wrote:
> iommu_group_get_for_dev determines the iommu group for the PCI device and adds
> the device to the group.
>
> In the PAMU driver we were again adding the device to the same group without checking
> if the device already had an iommu group. This resulted in the following warning.
>
> [...]
>
> Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
> ---
> v2 changes
> - directly check for the device iommu_group
>
> drivers/iommu/fsl_pamu_domain.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
Applied to iommu/fixes and added stable tag, thanks.
^ permalink raw reply
* Re: [PATCH] pseries: Make CPU hotplug path endian safe
From: Nathan Fontenot @ 2014-09-05 14:08 UTC (permalink / raw)
To: bharata.rao, linux-kernel; +Cc: linuxppc-dev, Bharata B Rao
In-Reply-To: <1409908577-10648-1-git-send-email-bharata.rao@gmail.com>
On 09/05/2014 04:16 AM, bharata.rao@gmail.com wrote:
> 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);
I need to look at this some more but I think this may cause an issue for
partition migration. If I am following the code correctly, starting in
pseries_devicetree_update(), the drc_index value passed to
dlpar_configure_connector is pulled directly out of a buffer we get from
firmware. This would mean the drc_index value is already in BE format.
Whereas for cpu hotplug the drc_index value is passed in from userspace
via the cpu probe interface in sysfs. I assume that you are seeing the
drc_index value getting passed in in LE format.
-Nathan
> 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:
>
^ permalink raw reply
* Re: [Xen-devel] [PATCH v1 08/21] x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq
From: David Vrabel @ 2014-09-05 14:29 UTC (permalink / raw)
To: Yijing Wang, Bjorn Helgaas
Cc: linux-mips, linux-ia64, linux-pci, Xinwei Hu, sparclinux,
linux-arch, linux-s390, Russell King, Joerg Roedel, x86,
Sebastian Ott, xen-devel, arnab.basu, Arnd Bergmann,
Chris Metcalf, Thomas Gleixner, linux-arm-kernel, Bharat.Bhushan,
Tony Luck, Ralf Baechle, iommu, Wuyun, linuxppc-dev,
David S. Miller
In-Reply-To: <1409911806-10519-9-git-send-email-wangyijing@huawei.com>
On 05/09/14 11:09, Yijing Wang wrote:
> Use MSI chip framework instead of arch MSI functions to configure
> MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
[...]
> --- a/arch/x86/pci/xen.c
> +++ b/arch/x86/pci/xen.c
[...]
> @@ -418,9 +430,9 @@ int __init pci_xen_init(void)
> #endif
>
> #ifdef CONFIG_PCI_MSI
> - x86_msi.setup_msi_irqs = xen_setup_msi_irqs;
> - x86_msi.teardown_msi_irq = xen_teardown_msi_irq;
> - x86_msi.teardown_msi_irqs = xen_teardown_msi_irqs;
> + xen_msi_chip.setup_irqs = xen_setup_msi_irqs;
> + xen_msi_chip.teardown_irqs = xen_teardown_msi_irqs;
> + x86_msi_chip = &xen_msi_chip;
> msi_chip.irq_mask = xen_nop_msi_mask;
> msi_chip.irq_unmask = xen_nop_msi_mask;
Why have these not been changed to set the x86_msi_chip.mask/unmask
fields instead?
David
^ permalink raw reply
* Re: bit fields && data tearing
From: Peter Hurley @ 2014-09-05 15:31 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Jakub Jelinek, linux-arch@vger.kernel.org, Tony Luck,
linux-ia64@vger.kernel.org, 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.7080100@zytor.com>
On 09/04/2014 10:08 PM, 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.
>
> I wonder what the one I have in my garage is... I'm sure I could emulate
> it faster, though.
Which is a bit ironic because I remember when Digital had a team
working on emulating native x86 apps on Alpha/NT.
^ permalink raw reply
* Re: [PATCH] pseries: Make CPU hotplug path endian safe
From: Bharata B Rao @ 2014-09-05 15:33 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linuxppc-dev, linux-kernel@vger.kernel.org, Bharata B Rao
In-Reply-To: <5409C3C6.90204@linux.vnet.ibm.com>
On Fri, Sep 5, 2014 at 7:38 PM, Nathan Fontenot
<nfont@linux.vnet.ibm.com> wrote:
> On 09/05/2014 04:16 AM, bharata.rao@gmail.com wrote:
>> 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);
>
> I need to look at this some more but I think this may cause an issue for
> partition migration. If I am following the code correctly, starting in
> pseries_devicetree_update(), the drc_index value passed to
> dlpar_configure_connector is pulled directly out of a buffer we get from
> firmware. This would mean the drc_index value is already in BE format.
Yes I see that now.
>
> Whereas for cpu hotplug the drc_index value is passed in from userspace
> via the cpu probe interface in sysfs. I assume that you are seeing the
> drc_index value getting passed in in LE format.
Yes I am seeing drc_index in LE format for an LE guest during CPU
hotplug operation.
Regards,
Bharata.
^ permalink raw reply
* Re: bit fields && data tearing
From: H. Peter Anvin @ 2014-09-05 15:41 UTC (permalink / raw)
To: Peter Hurley
Cc: Jakub Jelinek, linux-arch@vger.kernel.org, Tony Luck,
linux-ia64@vger.kernel.org, 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: <5409D76D.2070203@hurleysoftware.com>
On 09/05/2014 08:31 AM, Peter Hurley wrote:
>
> Which is a bit ironic because I remember when Digital had a team
> working on emulating native x86 apps on Alpha/NT.
>
Right, because the x86 architecture was obsolete and would never scale...
-hpa
^ permalink raw reply
* Re: bit fields && data tearing
From: Peter Hurley @ 2014-09-05 16:17 UTC (permalink / raw)
To: David Laight, 'paulmck@linux.vnet.ibm.com'
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,
linux-arm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Miroslav Franc, Richard Henderson
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D17488265@AcuExch.aculab.com>
On 09/05/2014 08:37 AM, David Laight wrote:
> From: Peter Hurley
>> On 09/05/2014 04:30 AM, David Laight wrote:
>>> I've seen gcc generate 32bit accesses for 16bit structure members on arm.
>>> It does this because of the more limited range of the offsets for the 16bit access.
>>> OTOH I don't know if it ever did this for writes - so it may be moot.
>>
>> Can you recall the particulars, like what ARM config or what code?
>>
>> I tried an overly-simple test to see if gcc would bump up to the word load for
>> the 12-bit offset mode, but it stuck with register offset rather than immediate
>> offset. [I used the compiler options for allmodconfig and a 4.8 cross-compiler.]
>>
>> Maybe the test doesn't generate enough register pressure on the compiler?
>
> Dunno, I would have been using a much older version of the compiler.
> It is possible that it doesn't do it any more.
> It might only have done it for loads.
>
> The compiler used to use misaligned 32bit loads for structure
> members on large 4n+2 byte boundaries as well.
> I'm pretty sure it doesn't do that either.
>
> There have been a lot of compiler versions since I was compiling
> anything for arm.
Yeah, it seems gcc for ARM no longer uses the larger operand size as a
substitute for 12-bit immediate offset addressing mode, even for reads.
While this test:
struct x {
short b[12];
};
short load_b(struct x *p) {
return p->b[8];
}
generates the 8-bit immediate offset form,
short load_b(struct x *p) {
0: e1d001f0 ldrsh r0, [r0, #16]
4: e12fff1e bx lr
pushing the offset out past 256:
struct x {
long unused[64];
short b[12];
};
short load_b(struct x *p) {
return p->b[8];
}
generates the register offset addressing mode instead of 12-bit immediate:
short load_b(struct x *p) {
0: e3a03e11 mov r3, #272 ; 0x110
4: e19000f3 ldrsh r0, [r0, r3]
8: e12fff1e bx lr
Regards,
Peter Hurley
[Note: I compiled without the frame pointer to simplify the code generation]
^ permalink raw reply
* Re: bit fields && data tearing
From: Paul E. McKenney @ 2014-09-05 18:09 UTC (permalink / raw)
To: Michael Cree, H. Peter Anvin, Peter Hurley,
Benjamin Herrenschmidt, David Laight, Jakub Jelinek,
linux-arch@vger.kernel.org, Tony Luck, linux-ia64@vger.kernel.org,
Oleg Nesterov, linux-kernel@vger.kernel.org, Paul Mackerras,
linuxppc-dev@lists.ozlabs.org, Miroslav Franc, Richard Henderson,
linux-alpha
In-Reply-To: <20140905081648.GB5281@omega>
On Fri, Sep 05, 2014 at 08:16:48PM +1200, Michael Cree wrote:
> 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.
Very good, then I update my patch as follows. Thoughts?
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. It also documents that
CPUs must provide one-byte and two-byte load and store instructions
in order to be supported by the Linux kernel. (Michael Cree
has agreed to the resulting non-support of pre-EV56 Alpha CPUs:
https://lkml.org/lkml/2014/9/5/143.
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..455df6b298f7 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -269,6 +269,30 @@ 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 variables that are the
+ same size as "char", "short", "int" and "long". "Properly aligned"
+ means the natural alignment, thus no constraints for "char",
+ two-byte alignment for "short", four-byte alignment for "int",
+ and either four-byte or eight-byte alignment for "long", on 32-bit
+ and 64-bit systems, respectively. Note that this means that the
+ Linux kernel does not support pre-EV56 Alpha CPUs, because these
+ older CPUs do not provide one-byte and two-byte loads and stores.
+ Alpha EV56 and later Alpha CPUs are still supported.
+
=========================
WHAT ARE MEMORY BARRIERS?
^ permalink raw reply related
* Re: bit fields && data tearing
From: Paul E. McKenney @ 2014-09-05 18:31 UTC (permalink / raw)
To: Michael Cree, H. Peter Anvin, Peter Hurley,
Benjamin Herrenschmidt, David Laight, Jakub Jelinek,
linux-arch@vger.kernel.org, Tony Luck, linux-ia64@vger.kernel.org,
Oleg Nesterov, linux-kernel@vger.kernel.org, Paul Mackerras,
linuxppc-dev@lists.ozlabs.org, Miroslav Franc, Richard Henderson,
linux-alpha
Cc: peterz
In-Reply-To: <20140905180950.GU5001@linux.vnet.ibm.com>
On Fri, Sep 05, 2014 at 11:09:50AM -0700, Paul E. McKenney wrote:
> On Fri, Sep 05, 2014 at 08:16:48PM +1200, Michael Cree wrote:
> > 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.
>
> Very good, then I update my patch as follows. Thoughts?
And, while I am at it, fix smp_load_acquire() and smp_store_release()
to allow single-byte and double-byte accesses. (Adding Peter Zijlstra
on CC.)
Thanx, Paul
------------------------------------------------------------------------
compiler: Allow 1- and 2-byte smp_load_acquire() and smp_store_release()
CPUs without single-byte and double-byte loads and stores place some
"interesting" requirements on concurrent code. For example (adapted
from Peter Hurley's test code), suppose we have the following structure:
struct foo {
spinlock_t lock1;
spinlock_t lock2;
char a; /* Protected by lock1. */
char b; /* Protected by lock2. */
};
struct foo *foop;
Of course, it is common (and good) practice to place data protected
by different locks in separate cache lines. However, if the locks are
rarely acquired (for example, only in rare error cases), and there are
a great many instances of the data structure, then memory footprint can
trump false-sharing concerns, so that it can be better to place them in
the same cache cache line as above.
But if the CPU does not support single-byte loads and stores, a store
to foop->a will do a non-atomic read-modify-write operation on foop->b,
which will come as a nasty surprise to someone holding foop->lock2. So we
now require CPUs to support single-byte and double-byte loads and stores.
Therefore, this commit adjusts the definition of __native_word() to allow
these sizes to be used by smp_load_acquire() and smp_store_release().
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index d5ad7b1118fc..934a834ab9f9 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -311,7 +311,7 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
/* Is this type a native word size -- useful for atomic operations */
#ifndef __native_word
-# define __native_word(t) (sizeof(t) == sizeof(int) || sizeof(t) == sizeof(long))
+# define __native_word(t) (sizeof(t) == sizeof(char) || sizeof(t) == sizeof(short) || sizeof(t) == sizeof(int) || sizeof(t) == sizeof(long))
#endif
/* Compile time object size, -1 for unknown */
^ permalink raw reply related
* Re: bit fields && data tearing
From: Peter Hurley @ 2014-09-05 18:50 UTC (permalink / raw)
To: paulmck, Michael Cree, H. Peter Anvin, Benjamin Herrenschmidt,
David Laight, Jakub Jelinek, linux-arch@vger.kernel.org,
Tony Luck, linux-ia64@vger.kernel.org, Oleg Nesterov,
linux-kernel@vger.kernel.org, Paul Mackerras,
linuxppc-dev@lists.ozlabs.org, Miroslav Franc, Richard Henderson,
linux-alpha
In-Reply-To: <20140905180950.GU5001@linux.vnet.ibm.com>
On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
> On Fri, Sep 05, 2014 at 08:16:48PM +1200, Michael Cree wrote:
>> 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.
>
> Very good, then I update my patch as follows. Thoughts?
>
> Thanx, Paul
Minor [optional] edits.
Thanks,
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. It also documents that
> CPUs must provide one-byte and two-byte load and store instructions
^
atomic
> in order to be supported by the Linux kernel. (Michael Cree
> has agreed to the resulting non-support of pre-EV56 Alpha CPUs:
> https://lkml.org/lkml/2014/9/5/143.
>
> 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..455df6b298f7 100644
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -269,6 +269,30 @@ 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 variables that are the
> + same size as "char", "short", "int" and "long". "Properly aligned"
> + means the natural alignment, thus no constraints for "char",
> + two-byte alignment for "short", four-byte alignment for "int",
> + and either four-byte or eight-byte alignment for "long", on 32-bit
> + and 64-bit systems, respectively. Note that this means that the
> + Linux kernel does not support pre-EV56 Alpha CPUs, because these
> + older CPUs do not provide one-byte and two-byte loads and stores.
^
non-atomic
> + Alpha EV56 and later Alpha CPUs are still supported.
> +
>
> =========================
> WHAT ARE MEMORY BARRIERS?
>
^ permalink raw reply
* Re: bit fields && data tearing
From: Paul E. McKenney @ 2014-09-05 19:05 UTC (permalink / raw)
To: Peter Hurley
Cc: Jakub Jelinek, linux-arch@vger.kernel.org, Tony Luck,
linux-ia64@vger.kernel.org, Michael Cree, linux-alpha,
Oleg Nesterov, linux-kernel@vger.kernel.org, David Laight,
Paul Mackerras, H. Peter Anvin, linuxppc-dev@lists.ozlabs.org,
Miroslav Franc, Richard Henderson
In-Reply-To: <540A05F7.1070202@hurleysoftware.com>
On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
> On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
> > On Fri, Sep 05, 2014 at 08:16:48PM +1200, Michael Cree wrote:
> >> 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.
> >
> > Very good, then I update my patch as follows. Thoughts?
> >
> > Thanx, Paul
>
> Minor [optional] edits.
>
> Thanks,
> 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. It also documents that
> > CPUs must provide one-byte and two-byte load and store instructions
> ^
> atomic
Here you meant non-atomic? My guess is that you are referring to the
fact that you could emulate a one-byte store on pre-EV56 Alpha CPUs
using the ll and sc atomic-read-modify-write instructions, correct?
> > in order to be supported by the Linux kernel. (Michael Cree
> > has agreed to the resulting non-support of pre-EV56 Alpha CPUs:
> > https://lkml.org/lkml/2014/9/5/143.
> >
> > 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..455df6b298f7 100644
> > --- a/Documentation/memory-barriers.txt
> > +++ b/Documentation/memory-barriers.txt
> > @@ -269,6 +269,30 @@ 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 variables that are the
> > + same size as "char", "short", "int" and "long". "Properly aligned"
> > + means the natural alignment, thus no constraints for "char",
> > + two-byte alignment for "short", four-byte alignment for "int",
> > + and either four-byte or eight-byte alignment for "long", on 32-bit
> > + and 64-bit systems, respectively. Note that this means that the
> > + Linux kernel does not support pre-EV56 Alpha CPUs, because these
> > + older CPUs do not provide one-byte and two-byte loads and stores.
> ^
> non-atomic
I took this, thank you!
Thanx, Paul
> > + Alpha EV56 and later Alpha CPUs are still supported.
> > +
> >
> > =========================
> > WHAT ARE MEMORY BARRIERS?
> >
>
^ permalink raw reply
* [PATCH] pseries: Fix endianness in cpu hotplug and hotremove
From: Thomas Falcon @ 2014-09-05 19:09 UTC (permalink / raw)
To: linuxppc-dev; +Cc: nfont, Thomas Falcon
This patch attempts to ensure that all values are in the proper
endianness format when both hotadding and hotremoving cpus.
Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/dlpar.c | 56 ++++++++++++++--------------
arch/powerpc/platforms/pseries/hotplug-cpu.c | 20 +++++-----
2 files changed, 38 insertions(+), 38 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/dlpar.c b/arch/powerpc/platforms/pseries/dlpar.c
index a2450b8..c1d7e40 100644
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -24,11 +24,11 @@
#include <asm/rtas.h>
struct cc_workarea {
- u32 drc_index;
- u32 zero;
- u32 name_offset;
- u32 prop_length;
- u32 prop_offset;
+ __be32 drc_index;
+ __be32 zero;
+ __be32 name_offset;
+ __be32 prop_length;
+ __be32 prop_offset;
};
void dlpar_free_cc_property(struct property *prop)
@@ -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 {
@@ -363,10 +363,10 @@ static int dlpar_online_cpu(struct device_node *dn)
int rc = 0;
unsigned int cpu;
int len, nthreads, i;
- const u32 *intserv;
+ const __be32 *intserv_be;
- intserv = of_get_property(dn, "ibm,ppc-interrupt-server#s", &len);
- if (!intserv)
+ intserv_be = of_get_property(dn, "ibm,ppc-interrupt-server#s", &len);
+ if (!intserv_be)
return -EINVAL;
nthreads = len / sizeof(u32);
@@ -374,7 +374,7 @@ static int dlpar_online_cpu(struct device_node *dn)
cpu_maps_update_begin();
for (i = 0; i < nthreads; i++) {
for_each_present_cpu(cpu) {
- if (get_hard_smp_processor_id(cpu) != intserv[i])
+ if (get_hard_smp_processor_id(cpu) != be32_to_cpu(intserv_be[i]))
continue;
BUG_ON(get_cpu_current_state(cpu)
!= CPU_STATE_OFFLINE);
@@ -388,7 +388,7 @@ static int dlpar_online_cpu(struct device_node *dn)
}
if (cpu == num_possible_cpus())
printk(KERN_WARNING "Could not find cpu to online "
- "with physical id 0x%x\n", intserv[i]);
+ "with physical id 0x%x\n", be32_to_cpu(intserv_be[i]));
}
cpu_maps_update_done();
@@ -442,18 +442,17 @@ static int dlpar_offline_cpu(struct device_node *dn)
int rc = 0;
unsigned int cpu;
int len, nthreads, i;
- const u32 *intserv;
+ const __be32 *intserv_be;
- intserv = of_get_property(dn, "ibm,ppc-interrupt-server#s", &len);
- if (!intserv)
+ intserv_be = of_get_property(dn, "ibm,ppc-interrupt-server#s", &len);
+ if (!intserv_be)
return -EINVAL;
nthreads = len / sizeof(u32);
-
cpu_maps_update_begin();
for (i = 0; i < nthreads; i++) {
for_each_present_cpu(cpu) {
- if (get_hard_smp_processor_id(cpu) != intserv[i])
+ if (get_hard_smp_processor_id(cpu) != be32_to_cpu(intserv_be[i]))
continue;
if (get_cpu_current_state(cpu) == CPU_STATE_OFFLINE)
@@ -469,20 +468,19 @@ static int dlpar_offline_cpu(struct device_node *dn)
break;
}
-
/*
* The cpu is in CPU_STATE_INACTIVE.
* Upgrade it's state to CPU_STATE_OFFLINE.
*/
set_preferred_offline_state(cpu, CPU_STATE_OFFLINE);
- BUG_ON(plpar_hcall_norets(H_PROD, intserv[i])
+ BUG_ON(plpar_hcall_norets(H_PROD, be32_to_cpu(intserv_be[i]))
!= H_SUCCESS);
__cpu_die(cpu);
break;
}
if (cpu == num_possible_cpus())
printk(KERN_WARNING "Could not find cpu to offline "
- "with physical id 0x%x\n", intserv[i]);
+ "with physical id 0x%x\n", be32_to_cpu(intserv_be[i]));
}
cpu_maps_update_done();
@@ -494,26 +492,28 @@ out:
static ssize_t dlpar_cpu_release(const char *buf, size_t count)
{
struct device_node *dn;
- const u32 *drc_index;
+ const __be32 *drc_index_be;
+ u32 drc_index;
int rc;
dn = of_find_node_by_path(buf);
if (!dn)
return -EINVAL;
- drc_index = of_get_property(dn, "ibm,my-drc-index", NULL);
- if (!drc_index) {
+ drc_index_be = of_get_property(dn, "ibm,my-drc-index", NULL);
+ if (!drc_index_be) {
of_node_put(dn);
return -EINVAL;
}
+ drc_index = be32_to_cpup(drc_index_be);
rc = dlpar_offline_cpu(dn);
if (rc) {
of_node_put(dn);
return -EINVAL;
}
- rc = dlpar_release_drc(*drc_index);
+ rc = dlpar_release_drc(drc_index);
if (rc) {
of_node_put(dn);
return rc;
@@ -521,7 +521,7 @@ static ssize_t dlpar_cpu_release(const char *buf, size_t count)
rc = dlpar_detach_node(dn);
if (rc) {
- dlpar_acquire_drc(*drc_index);
+ dlpar_acquire_drc(drc_index);
return rc;
}
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index 20d6297..fc9c2cd 100644
--- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -90,7 +90,7 @@ static void rtas_stop_self(void)
{
static struct rtas_args args = {
.nargs = 0,
- .nret = 1,
+ .nret = cpu_to_be32(1),
.rets = &args.args[0],
};
@@ -247,10 +247,10 @@ 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_be;
- intserv = of_get_property(np, "ibm,ppc-interrupt-server#s", &len);
- if (!intserv)
+ intserv_be = of_get_property(np, "ibm,ppc-interrupt-server#s", &len);
+ if (!intserv_be)
return 0;
zalloc_cpumask_var(&candidate_mask, GFP_KERNEL);
@@ -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_be++));
}
err = 0;
out_unlock:
@@ -312,10 +312,10 @@ static void pseries_remove_processor(struct device_node *np)
{
unsigned int cpu;
int len, nthreads, i;
- const u32 *intserv;
+ const __be32 *intserv_be;
- intserv = of_get_property(np, "ibm,ppc-interrupt-server#s", &len);
- if (!intserv)
+ intserv_be = of_get_property(np, "ibm,ppc-interrupt-server#s", &len);
+ if (!intserv_be)
return;
nthreads = len / sizeof(u32);
@@ -323,7 +323,7 @@ static void pseries_remove_processor(struct device_node *np)
cpu_maps_update_begin();
for (i = 0; i < nthreads; i++) {
for_each_present_cpu(cpu) {
- if (get_hard_smp_processor_id(cpu) != intserv[i])
+ if (get_hard_smp_processor_id(cpu) != be32_to_cpu(intserv_be[i]))
continue;
BUG_ON(cpu_online(cpu));
set_cpu_present(cpu, false);
@@ -332,7 +332,7 @@ static void pseries_remove_processor(struct device_node *np)
}
if (cpu >= nr_cpu_ids)
printk(KERN_WARNING "Could not find cpu to remove "
- "with physical id 0x%x\n", intserv[i]);
+ "with physical id 0x%x\n", be32_to_cpu(intserv_be[i]));
}
cpu_maps_update_done();
}
--
1.8.5.2
^ permalink raw reply related
* Re: bit fields && data tearing
From: Peter Hurley @ 2014-09-05 19:24 UTC (permalink / raw)
To: paulmck
Cc: Jakub Jelinek, linux-arch@vger.kernel.org, Tony Luck,
linux-ia64@vger.kernel.org, Michael Cree, linux-alpha,
Oleg Nesterov, linux-kernel@vger.kernel.org, David Laight,
Paul Mackerras, H. Peter Anvin, linuxppc-dev@lists.ozlabs.org,
Miroslav Franc, Richard Henderson
In-Reply-To: <20140905190506.GV5001@linux.vnet.ibm.com>
On 09/05/2014 03:05 PM, Paul E. McKenney wrote:
> On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
>> On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
[cut]
>>> ------------------------------------------------------------------------
>>>
>>> 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. It also documents that
>>> CPUs must provide one-byte and two-byte load and store instructions
>> ^
>> atomic
>
> Here you meant non-atomic? My guess is that you are referring to the
> fact that you could emulate a one-byte store on pre-EV56 Alpha CPUs
> using the ll and sc atomic-read-modify-write instructions, correct?
Yes, that's what I meant. I must be tired and am misreading the commit
message, or misinterpreting it's meaning.
^ permalink raw reply
* Re: bit fields && data tearing
From: Peter Zijlstra @ 2014-09-05 19:52 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Jakub Jelinek, linux-arch@vger.kernel.org, Tony Luck,
linux-ia64@vger.kernel.org, Peter Hurley, Michael Cree,
linux-alpha, Oleg Nesterov, linux-kernel@vger.kernel.org,
David Laight, Paul Mackerras, H. Peter Anvin,
linuxppc-dev@lists.ozlabs.org, Miroslav Franc, Richard Henderson
In-Reply-To: <20140905183109.GA5497@linux.vnet.ibm.com>
On Fri, Sep 05, 2014 at 11:31:09AM -0700, Paul E. McKenney wrote:
> compiler: Allow 1- and 2-byte smp_load_acquire() and smp_store_release()
>
> CPUs without single-byte and double-byte loads and stores place some
> "interesting" requirements on concurrent code. For example (adapted
> from Peter Hurley's test code), suppose we have the following structure:
>
> struct foo {
> spinlock_t lock1;
> spinlock_t lock2;
> char a; /* Protected by lock1. */
> char b; /* Protected by lock2. */
> };
> struct foo *foop;
>
> Of course, it is common (and good) practice to place data protected
> by different locks in separate cache lines. However, if the locks are
> rarely acquired (for example, only in rare error cases), and there are
> a great many instances of the data structure, then memory footprint can
> trump false-sharing concerns, so that it can be better to place them in
> the same cache cache line as above.
>
> But if the CPU does not support single-byte loads and stores, a store
> to foop->a will do a non-atomic read-modify-write operation on foop->b,
> which will come as a nasty surprise to someone holding foop->lock2. So we
> now require CPUs to support single-byte and double-byte loads and stores.
> Therefore, this commit adjusts the definition of __native_word() to allow
> these sizes to be used by smp_load_acquire() and smp_store_release().
So does this patch depends on a patch that removes pre EV56 alpha
support? I'm all for removing that, but I need to see the patch merged
before we can do this.
^ permalink raw reply
* Re: bit fields && data tearing
From: Peter Hurley @ 2014-09-05 20:01 UTC (permalink / raw)
To: Peter Zijlstra, Paul E. McKenney
Cc: Jakub Jelinek, linux-arch@vger.kernel.org, Tony Luck,
linux-ia64@vger.kernel.org, Michael Cree, linux-alpha,
Oleg Nesterov, linux-kernel@vger.kernel.org, David Laight,
Paul Mackerras, H. Peter Anvin, linuxppc-dev@lists.ozlabs.org,
Miroslav Franc, Richard Henderson
In-Reply-To: <20140905195234.GT4783@worktop.ger.corp.intel.com>
On 09/05/2014 03:52 PM, Peter Zijlstra wrote:
> On Fri, Sep 05, 2014 at 11:31:09AM -0700, Paul E. McKenney wrote:
>> compiler: Allow 1- and 2-byte smp_load_acquire() and smp_store_release()
>>
>> CPUs without single-byte and double-byte loads and stores place some
>> "interesting" requirements on concurrent code. For example (adapted
>> from Peter Hurley's test code), suppose we have the following structure:
>>
>> struct foo {
>> spinlock_t lock1;
>> spinlock_t lock2;
>> char a; /* Protected by lock1. */
>> char b; /* Protected by lock2. */
>> };
>> struct foo *foop;
>>
>> Of course, it is common (and good) practice to place data protected
>> by different locks in separate cache lines. However, if the locks are
>> rarely acquired (for example, only in rare error cases), and there are
>> a great many instances of the data structure, then memory footprint can
>> trump false-sharing concerns, so that it can be better to place them in
>> the same cache cache line as above.
>>
>> But if the CPU does not support single-byte loads and stores, a store
>> to foop->a will do a non-atomic read-modify-write operation on foop->b,
>> which will come as a nasty surprise to someone holding foop->lock2. So we
>> now require CPUs to support single-byte and double-byte loads and stores.
>> Therefore, this commit adjusts the definition of __native_word() to allow
>> these sizes to be used by smp_load_acquire() and smp_store_release().
>
> So does this patch depends on a patch that removes pre EV56 alpha
> support? I'm all for removing that, but I need to see the patch merged
> before we can do this.
I'm working on that but Alpha's Kconfig is not quite straightforward.
... and I'm wondering if I should _remove_ pre-EV56 configurations or
move the default choice and produce a warning about unsupported Alpha
CPUs instead?
Regards,
Peter Hurley
[ How does one do a red popup in kbuild?
The 'comment' approach is too subtle.
]
^ 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