Re: [PATCH] powerpc/pseries: Add pcibios_default_alignment implementation

2020-08-22 Thread Oliver O'Halloran 
On Sat, Aug 22, 2020 at 6:51 AM Shawn Anastasio  wrote:
>
> Implement pcibios_default_alignment for pseries so that
> resources are page-aligned. The main benefit of this is being
> able to map any resource from userspace via mechanisms like VFIO.

Reviewed-by: Oliver O'Halloran 

That said, there's nothing power specific about this so we should
probably drop the pcibios hacks and fix the default alignment in the
PCI core.

> This is identical to powernv's implementation.
>
> Signed-off-by: Shawn Anastasio 
> ---
>  arch/powerpc/platforms/pseries/pci.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/arch/powerpc/platforms/pseries/pci.c 
> b/arch/powerpc/platforms/pseries/pci.c
> index 911534b89c85..6d922c096354 100644
> --- a/arch/powerpc/platforms/pseries/pci.c
> +++ b/arch/powerpc/platforms/pseries/pci.c
> @@ -210,6 +210,11 @@ int pseries_pcibios_sriov_disable(struct pci_dev *pdev)
>  }
>  #endif
>
> +static resource_size_t pseries_pcibios_default_alignment(void)
> +{
> +   return PAGE_SIZE;
> +}
> +
>  static void __init pSeries_request_regions(void)
>  {
> if (!isa_io_base)
> @@ -231,6 +236,8 @@ void __init pSeries_final_fixup(void)
>
> eeh_show_enabled();
>
> +   ppc_md.pcibios_default_alignment = pseries_pcibios_default_alignment;
> +
>  #ifdef CONFIG_PCI_IOV
> ppc_md.pcibios_sriov_enable = pseries_pcibios_sriov_enable;
> ppc_md.pcibios_sriov_disable = pseries_pcibios_sriov_disable;
> --
> 2.28.0
>

Re: Re：Re: [PATCH] powerpc: Fix a bug in __div64_32 if divisor is zero

2020-08-22 Thread Segher Boessenkool 
On Sun, Aug 23, 2020 at 12:54:33AM +0800, Guohua Zhong wrote:
> Yet, I have noticed that there is no checking of 'base' in these functions.
> But I am not sure how to check is better.As we know that the result is 
> undefined when divisor is zero. It maybe good to print error and dump stack.
>  Let the process to know that the divisor is zero by sending SIGFPE. 

That is now what the PowerPC integer divide insns do: they just leave
the result undefined (and they can set the overflow flag then, but no
one uses that).


Segher

[PATCH v2 4/4] powerpc: apm82181: integrate bluestone.dts

2020-08-22 Thread Christian Lamparter 
This patch tries to integrate the existing bluestone.dts into the
apm82181.dtsi framework.

The original bluestone.dts produces a  peculiar warning message.
> bluestone.dts:120.10-125.4: Warning (i2c_bus_reg):
>  /plb/opb/i2c@ef600700/sttm@4C: I2C bus unit address format error, expected 
> "4c"
For now, this has been kept as-is.

Signed-off-by: Christian Lamparter 
---
 arch/powerpc/boot/dts/bluestone.dts | 458 +++-
 1 file changed, 104 insertions(+), 354 deletions(-)

diff --git a/arch/powerpc/boot/dts/bluestone.dts 
b/arch/powerpc/boot/dts/bluestone.dts
index cc965a1816b6..b568fe7ae526 100644
--- a/arch/powerpc/boot/dts/bluestone.dts
+++ b/arch/powerpc/boot/dts/bluestone.dts
@@ -8,388 +8,138 @@
 
 /dts-v1/;
 
+#include "apm82181.dtsi"
+
 / {
-   #address-cells = <2>;
-   #size-cells = <1>;
model = "apm,bluestone";
compatible = "apm,bluestone";
-   dcr-parent = <&{/cpus/cpu@0}>;
 
aliases {
-   ethernet0 = 
serial0 = 
serial1 = 
};
+};
 
-   cpus {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   cpu@0 {
-   device_type = "cpu";
-   model = "PowerPC,apm821xx";
-   reg = <0x>;
-   clock-frequency = <0>; /* Filled in by U-Boot */
-   timebase-frequency = <0>; /* Filled in by U-Boot */
-   i-cache-line-size = <32>;
-   d-cache-line-size = <32>;
-   i-cache-size = <32768>;
-   d-cache-size = <32768>;
-   dcr-controller;
-   dcr-access-method = "native";
-   next-level-cache = <>;
-   };
-   };
-
-   memory {
-   device_type = "memory";
-   reg = <0x 0x 0x>; /* Filled in by 
U-Boot */
-   };
-
-   UIC0: interrupt-controller0 {
-   compatible = "ibm,uic";
-   interrupt-controller;
-   cell-index = <0>;
-   dcr-reg = <0x0c0 0x009>;
-   #address-cells = <0>;
-   #size-cells = <0>;
-   #interrupt-cells = <2>;
-   };
-
-   UIC1: interrupt-controller1 {
-   compatible = "ibm,uic";
-   interrupt-controller;
-   cell-index = <1>;
-   dcr-reg = <0x0d0 0x009>;
-   #address-cells = <0>;
-   #size-cells = <0>;
-   #interrupt-cells = <2>;
-   interrupts = <0x1e 0x4 0x1f 0x4>; /* cascade */
-   interrupt-parent = <>;
-   };
+ {
+   status = "okay";
+};
 
-   UIC2: interrupt-controller2 {
-   compatible = "ibm,uic";
-   interrupt-controller;
-   cell-index = <2>;
-   dcr-reg = <0x0e0 0x009>;
-   #address-cells = <0>;
-   #size-cells = <0>;
-   #interrupt-cells = <2>;
-   interrupts = <0xa 0x4 0xb 0x4>; /* cascade */
-   interrupt-parent = <>;
-   };
+ {
+   status = "okay";
+};
 
-   UIC3: interrupt-controller3 {
-   compatible = "ibm,uic";
-   interrupt-controller;
-   cell-index = <3>;
-   dcr-reg = <0x0f0 0x009>;
-   #address-cells = <0>;
-   #size-cells = <0>;
-   #interrupt-cells = <2>;
-   interrupts = <0x10 0x4 0x11 0x4>; /* cascade */
-   interrupt-parent = <>;
-   };
+ {
+   status = "okay";
 
-   OCM: ocm@40004 {
-   compatible = "ibm,ocm";
-   status = "okay";
-   cell-index = <1>;
-   /* configured in U-Boot */
-   reg = <4 0x0004 0x8000>; /* 32K */
-   };
+   compatible = "amd,s29gl512n", "cfi-flash";
+   bank-width = <2>;
+   reg = <0x 0x 0x0040>;
 
-   SDR0: sdr {
-   compatible = "ibm,sdr-apm821xx";
-   dcr-reg = <0x00e 0x002>;
+   partition@0 {
+   label = "kernel";
+   reg = <0x 0x0018>;
};
-
-   CPR0: cpr {
-   compatible = "ibm,cpr-apm821xx";
-   dcr-reg = <0x00c 0x002>;
+   partition@18 {
+   label = "env";
+   reg = <0x0018 0x0002>;
};
-
-   L2C0: l2c {
-   compatible = "ibm,l2-cache-apm82181", "ibm,l2-cache";
-   dcr-reg = <0x020 0x008
-  0x030 0x008>;
-   cache-line-size = <32>;
-   cache-size = <262144>;
-   interrupt-parent = <>;
-   interrupts = <11 1>;
+   partition@1a {
+   label = "u-boot";
+   reg = <0x001a 0x0006>;
};
+};
 
-   plb {
-   compatible = "ibm,plb4";
-

[PATCH v2 3/4] powerpc: apm82181: add Meraki MR24 AP

2020-08-22 Thread Christian Lamparter 
This patch adds the device-tree definitions for Meraki MR24
Accesspoint devices.

Board: MR24 - Meraki MR24 Cloud Managed Access Point
CPU: APM82181 SoC 800 MHz (PLB=200 OPB=100 EBC=100)
Flash size: 32MiB
RAM Size: 128MiB
Wireless: Atheros AR9380 5.0GHz + Atheros AR9380 2.4GHz
EPHY: 1x Gigabit Atheros AR8035

Ready to go images and install instruction can be found @OpenWrt.

Signed-off-by: Chris Blake 
Signed-off-by: Christian Lamparter 

---
- rfc v1 -> v2:
- use new led naming scheme
- space-vs-tab snafu cleanup
- remove led-aliases (openwrt specific)
- overhauled commit message
---
 arch/powerpc/boot/dts/meraki-mr24.dts  | 235 +
 arch/powerpc/platforms/44x/ppc44x_simple.c |   1 +
 2 files changed, 236 insertions(+)
 create mode 100644 arch/powerpc/boot/dts/meraki-mr24.dts

diff --git a/arch/powerpc/boot/dts/meraki-mr24.dts 
b/arch/powerpc/boot/dts/meraki-mr24.dts
new file mode 100644
index ..58050c2c92a2
--- /dev/null
+++ b/arch/powerpc/boot/dts/meraki-mr24.dts
@@ -0,0 +1,235 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Device Tree Source for Meraki MR24 (Ikarem)
+ *
+ * Copyright (C) 2016 Chris Blake 
+ *
+ * Based on Cisco Meraki GPL Release r23-20150601 MR24 DTS
+ */
+
+/dts-v1/;
+
+#include 
+#include "apm82181.dtsi"
+
+/ {
+   model = "Meraki MR24 Access Point";
+   compatible = "meraki,mr24";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "/plb/opb/serial@ef600400";
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+
+   /* 32 MiB NAND Flash */
+   nand {
+   partition@0 {
+   label = "u-boot";
+   reg = <0x 0x0015>;
+   read-only;
+   };
+
+   partition@15 {
+   /*
+* The u-boot environment size is one NAND
+* block (16KiB). u-boot allocates four NAND
+* blocks (64KiB) in order to have spares
+* around for bad block management
+*/
+   label = "u-boot-env";
+   reg = <0x0015 0x0001>;
+   read-only;
+   };
+
+   partition@16 {
+   /*
+* redundant u-boot environment.
+* has to be kept it in sync with the
+* data in "u-boot-env".
+*/
+   label = "u-boot-env-redundant";
+   reg = <0x0016 0x0001>;
+   read-only;
+   };
+
+   partition@17 {
+   label = "oops";
+   reg = <0x0017 0x0001>;
+   };
+
+   partition@18 {
+   label = "ubi";
+   reg = <0x0018 0x01e8>;
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+   /* Boot ROM is at 0x52-0x53, do not touch */
+   /* Unknown chip at 0x6e, not sure what it is */
+};
+
+ {
+   status = "okay";
+
+   phy-mode = "rgmii-id";
+   phy-map = <0x2>;
+   phy-address = <0x1>;
+   phy-handle = <>;
+
+   mdio {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   phy: phy@1 {
+   compatible = "ethernet-phy-ieee802.3-c22";
+   reg = <1>;
+   };
+   };
+};
+
+ {
+   leds {
+   compatible = "gpio-leds";
+
+   status: power-green {
+   function = LED_FUNCTION_POWER;
+   color = ;
+   gpios = < 18 GPIO_ACTIVE_LOW>;
+   };
+
+   failsafe: power-amber {
+   function = LED_FUNCTION_FAULT;
+   color = ;
+   gpios = < 19 GPIO_ACTIVE_LOW>;
+   };
+
+   lan {
+   function = LED_FUNCTION_WAN;
+   color = ;
+   gpios = < 17 GPIO_ACTIVE_LOW>;
+   };
+
+   /* signal strength indicator */
+   ssi-0 {
+   function = LED_FUNCTION_INDICATOR;
+   color = ;
+   gpios = < 23 GPIO_ACTIVE_LOW>;
+   };
+
+   ssi-1 {
+   function = LED_FUNCTION_INDICATOR;
+   color = ;
+   gpios = < 22 GPIO_ACTIVE_LOW>;
+   };
+
+   ssi-2 {
+   function = LED_FUNCTION_INDICATOR;
+   color = ;
+   gpios = < 21

[PATCH v2 2/4] powerpc: apm82181: add WD MyBook Live NAS

2020-08-22 Thread Christian Lamparter 
This patch adds the device-tree definitions for
Western Digital MyBook Live NAS devices.

CPU: AMCC PowerPC  APM82181 (PVR=12c41c83) at 800 MHz
 (PLB=200, OPB=100, EBC=100 MHz)
 32 kB I-Cache 32 kB D-Cache, 256 kB L2-Cache, 32 kB OnChip Memory
DRAM:  256 MB (2x NT5TU64M16GG-AC)
FLASH: 512 kB
Ethernet: 1xRGMII - 1 Gbit - Broadcom PHY BCM54610
SATA: 2*SATA (DUO Variant) / 1*SATA (Single Variant)
USB: 1xUSB2.0 (Only DUO)

Technically, this devicetree file is shared by two, very
similar devices.

There's the My Book Live and the My Book Live Duo. WD's uboot
on the device will enable/disable the nodes for the device.
This device boots from a u-boot on a 512 KiB NOR Flash onto a
Linux image stored on one of the harddrives.

Ready to go images and install instruction can be found @OpenWrt.org

Signed-off-by: Christian Lamparter 

---
- rfc v1 -> v2:
- use new LED naming scheme
- dish out read-only; for essential NOR partitions
- remove openwrt led-aliases
- comment on the location of linux kernel (on the HDD)
- overhauled commit message
---
 arch/powerpc/boot/dts/wd-mybooklive.dts| 200 +
 arch/powerpc/platforms/44x/ppc44x_simple.c |   3 +-
 2 files changed, 202 insertions(+), 1 deletion(-)
 create mode 100644 arch/powerpc/boot/dts/wd-mybooklive.dts

diff --git a/arch/powerpc/boot/dts/wd-mybooklive.dts 
b/arch/powerpc/boot/dts/wd-mybooklive.dts
new file mode 100644
index ..792401673053
--- /dev/null
+++ b/arch/powerpc/boot/dts/wd-mybooklive.dts
@@ -0,0 +1,200 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright 2008 DENX Software Engineering, Stefan Roese 
+ * (c) Copyright 2010 Western Digital Technologies, Inc. All Rights Reserved.
+ */
+
+/dts-v1/;
+
+#include 
+#include "apm82181.dtsi"
+
+/ {
+   compatible = "wd,mybooklive";
+   model = "MyBook Live";
+
+   aliases {
+   serial0 = 
+   };
+};
+
+ {
+   GPIO1: gpio@e000 {
+   compatible = "wd,mbl-gpio";
+   reg-names = "dat";
+   reg = <0xe000 0x1>;
+   #gpio-cells = <2>;
+   gpio-controller;
+
+   enable-button {
+   /* Defined in u-boot as: NOT_NOR
+* "enables features other than NOR
+* specifically, the buffer at CS2"
+* (button).
+*
+* Note: This option is disabled as
+* it prevents the system from being
+* rebooted successfully.
+*/
+
+   gpio-hog;
+   line-name = "Enable Reset Button, disable NOR";
+   gpios = <1 GPIO_ACTIVE_HIGH>;
+   output-low;
+   };
+   };
+
+   GPIO2: gpio@e010 {
+   compatible = "wd,mbl-gpio";
+   reg-names = "dat";
+   reg = <0xe010 0x1>;
+   #gpio-cells = <2>;
+   gpio-controller;
+   no-output;
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   /* There's just one tri-color LED. */
+   failsafe: power-red {
+   function = LED_FUNCTION_FAULT;
+   color = ;
+   gpios = < 4 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "panic";
+   };
+
+   power-green {
+   function = LED_FUNCTION_POWER;
+   color = ;
+   gpios = < 5 GPIO_ACTIVE_HIGH>;
+   };
+
+   power-blue {
+   function = LED_FUNCTION_DISK;
+   color = ;
+   gpios = < 6 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "disk-activity";
+   };
+   };
+
+   keys {
+   compatible = "gpio-keys-polled";
+   poll-interval = <60>;   /* 3 * 20 = 60ms */
+   autorepeat;
+
+   reset-button {
+   label = "Reset button";
+   linux,code = ;
+   gpios = < 2 GPIO_ACTIVE_LOW>;
+   };
+   };
+
+   usbpwr: usb-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "Power USB Core";
+   gpios = < 2 GPIO_ACTIVE_LOW>;
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+
+   sata1pwr: sata1-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "Power Drive Port 1";
+   gpios = < 3 GPIO_ACTIVE_LOW>;
+   regulator-min-microvolt = <1200>;
+   regulator-max-microvolt = <1200>;
+   regulator-always-on; /* needed to read OS from HDD */
+   };
+
+

[PATCH v2 1/4] powerpc: apm82181: create shared dtsi for APM bluestone

2020-08-22 Thread Christian Lamparter 
This patch adds an DTSI-File that can be used by various device-tree
files for APM82181-based devices.

Some of the nodes (like UART, PCIE, SATA) are used by the uboot and
need to stick with the naming-conventions of the old times'.
I've added comments whenever this was the case. But unfortunately,
keeping uboot happy causes warning messages when compiling the dtb:

> apm82181.dtsi:440.26-483.5: Warning (pci_bridge): /plb/pciex@d: node 
> name is not "pci" or "pcie"
> wd-mybooklive.dtb: Warning (pci_device_bus_num): Failed prerequisite 
> 'pci_bridge'

Signed-off-by: Chris Blake 
Signed-off-by: Christian Lamparter 
---
- rfc v1 -> v2:
- removed PKA (this CryptoPU will need driver)
- stick with compatibles, nodes, ... from either
  Bluestone (APM82181) or Canyonlands (PPC460EX).
- add labels for NAND and NOR to help with access.
---
 arch/powerpc/boot/dts/apm82181.dtsi | 467 
 1 file changed, 467 insertions(+)
 create mode 100644 arch/powerpc/boot/dts/apm82181.dtsi

diff --git a/arch/powerpc/boot/dts/apm82181.dtsi 
b/arch/powerpc/boot/dts/apm82181.dtsi
new file mode 100644
index ..362a6262c553
--- /dev/null
+++ b/arch/powerpc/boot/dts/apm82181.dtsi
@@ -0,0 +1,467 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Device Tree template include for various APM82181 boards.
+ *
+ * The SoC is an evolution of the PPC460EX predecessor.
+ * This is why dt-nodes from the canyonlands EBC, OPB, USB,
+ * DMA, SATA, EMAC, ... ended up in here.
+ *
+ * Copyright (c) 2010, Applied Micro Circuits Corporation
+ * Author: Tirumala R Marri ,
+ *Christian Lamparter ,
+ *Chris Blake 
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   #address-cells = <2>;
+   #size-cells = <1>;
+   dcr-parent = <&{/cpus/cpu@0}>;
+   compatible = "apm,apm82181";
+
+   aliases {
+   ethernet0 =  /* needed for BSP u-boot */
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   CPU0: cpu@0 {
+   device_type = "cpu";
+   model = "PowerPC,apm82181";
+   reg = <0x>;
+   clock-frequency = <0>; /* Filled in by U-Boot */
+   timebase-frequency = <0>; /* Filled in by U-Boot */
+   i-cache-line-size = <32>;
+   d-cache-line-size = <32>;
+   i-cache-size = <32768>;
+   d-cache-size = <32768>;
+   dcr-controller;
+   dcr-access-method = "native";
+   next-level-cache = <>;
+   };
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x 0x 0x>; /* Filled in by 
U-Boot */
+   };
+
+   UIC0: interrupt-controller0 {
+   compatible = "apm,uic-apm82181", "ibm,uic";
+   interrupt-controller;
+   cell-index = <0>;
+   dcr-reg = <0x0c0 0x009>;
+   #address-cells = <0>;
+   #size-cells = <0>;
+   #interrupt-cells = <2>;
+   };
+
+   UIC1: interrupt-controller1 {
+   compatible = "apm,uic-apm82181", "ibm,uic";
+   interrupt-controller;
+   cell-index = <1>;
+   dcr-reg = <0x0d0 0x009>;
+   #address-cells = <0>;
+   #size-cells = <0>;
+   #interrupt-cells = <2>;
+   interrupts = <0x1e IRQ_TYPE_LEVEL_HIGH>,
+<0x1f IRQ_TYPE_LEVEL_HIGH>; /* cascade */
+   interrupt-parent = <>;
+   };
+
+   UIC2: interrupt-controller2 {
+   compatible = "apm,uic-apm82181", "ibm,uic";
+   interrupt-controller;
+   cell-index = <2>;
+   dcr-reg = <0x0e0 0x009>;
+   #address-cells = <0>;
+   #size-cells = <0>;
+   #interrupt-cells = <2>;
+   interrupts = <0x0a IRQ_TYPE_LEVEL_HIGH>,
+<0x0b IRQ_TYPE_LEVEL_HIGH>; /* cascade */
+   interrupt-parent = <>;
+   };
+
+   UIC3: interrupt-controller3 {
+   compatible = "apm,uic-apm82181","ibm,uic";
+   interrupt-controller;
+   cell-index = <3>;
+   dcr-reg = <0x0f0 0x009>;
+   #address-cells = <0>;
+   #size-cells = <0>;
+   #interrupt-cells = <2>;
+   interrupts = <0x10 IRQ_TYPE_LEVEL_HIGH>,
+<0x11 IRQ_TYPE_LEVEL_HIGH>; /* cascade */
+   interrupt-parent = <>;
+   };
+
+   OCM: ocm@40004 {
+   compatible = "ibm,ocm";
+   status = "okay";
+   cell-index = <1>;
+   /* configured in U-Boot */
+   reg = <4 0x0004 0x8000>; /* 32K */
+

[PATCH v2 0/4] powerpc: apm82181: adding customer devices

2020-08-22 Thread Christian Lamparter 
Hello,

I've been holding on to these devices dts' for a while now.
But ever since the recent purge of the PPC405, I'm feeling
the urge to move forward.

The devices in question have been running with OpenWrt since
around 2016/2017. Back then it was linux v4.4 and required
many out-of-tree patches (for WIFI, SATA, CRYPTO...), that
since have been integrated. So, there's nothing else in the
way I think.

A patch that adds the Meraki vendor-prefix has been sent
separately, as there's also the Meraki MR32 that I'm working
on as well. Here's the link to the patch:


Now, I've looked around in the arch/powerpc for recent .dts
and device submissions to get an understanding of what is
required.
>From the looks of it, it seems like every device gets a
skeleton defconfig and a CONFIG_$DEVICE symbol (Like:
CONFIG_MERAKI_MR24, CONFIG_WD_MYBOOKLIVE).

Will this be the case? Or would it make sense to further
unite the Bluestone, MR24 and MBL under a common CONFIG_APM82181
and integrate the BLUESTONE device's defconfig into it as well?
(I've stumbled across the special machine compatible
handling of ppc in the Documentation/devicetree/usage-model.rst
already.)

Cheers,
Christian

Note:
If someone has a WD MyBook Live (DUO) and is interested in
giving it a spin with 5.8. I've made a:
"build your own Debian System" sort of script that can be
found on github: 
(the only remaining patch hack is for debian's make-kpkg crossbuild)

Furthermore, the OpenWrt project currently has images for the
following apm82181 devices:
 Cisco Meraki MX60(W) - Needs DSA for the AR8327
 Netgear WNDAP620/WNDAP660 - (Could be next)
 Netgear WNDR4700 - Needs DSA for the AR8327

Note2: I do have a stash of extensive APM82181 related documentation.

Christian Lamparter (4):
  powerpc: apm82181: create shared dtsi for APM bluestone
  powerpc: apm82181: add WD MyBook Live NAS
  powerpc: apm82181: add Meraki MR24 AP
  powerpc: apm82181: integrate bluestone.dts

 arch/powerpc/boot/dts/apm82181.dtsi| 485 +
 arch/powerpc/boot/dts/bluestone.dts| 456 +--
 arch/powerpc/boot/dts/meraki-mr24.dts  | 237 ++
 arch/powerpc/boot/dts/wd-mybooklive.dts| 199 +
 arch/powerpc/platforms/44x/ppc44x_simple.c |   4 +-
 5 files changed, 1033 insertions(+), 348 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/apm82181.dtsi
 create mode 100644 arch/powerpc/boot/dts/meraki-mr24.dts
 create mode 100644 arch/powerpc/boot/dts/wd-mybooklive.dts

-- 
2.28.0

Re: Re：Re: [PATCH] powerpc: Fix a bug in __div64_32 if divisor is zero

2020-08-22 Thread Gabriel Paubert 
On Sun, Aug 23, 2020 at 12:54:33AM +0800, Guohua Zhong wrote:
> >In generic version in lib/math/div64.c, there is no checking of 'base' 
> >either.
> >Do we really want to add this check in the powerpc version only ?
> 
> >The only user of __div64_32() is do_div() in 
> >include/asm-generic/div64.h. Wouldn't it be better to do the check there ?
> 
> >Christophe
> 
> Yet, I have noticed that there is no checking of 'base' in these functions.
> But I am not sure how to check is better.As we know that the result is 
> undefined when divisor is zero. It maybe good to print error and dump stack.
>  Let the process to know that the divisor is zero by sending SIGFPE. 
> 
> diff --git a/include/asm-generic/div64.h b/include/asm-generic/div64.h
> index a3b98c86f077..161c656ee3ee 100644
> --- a/include/asm-generic/div64.h
> +++ b/include/asm-generic/div64.h
> @@ -43,6 +43,11 @@
>  # define do_div(n,base) ({ \
> uint32_t __base = (base);   \
> uint32_t __rem; \
> + if (unlikely(base == 0)) {  \
> + pr_err("do_div base=%d\n",base);\
> + dump_stack();   \
> + force_sig(SIGFPE);  \
> + }  
> 

I suspect this will generate a strong reaction. SIGFPE is for user space
instruction attempting a division by zero. A division by zero in the
kernel is a kernel bug, period, and you don't want to kill a user
process for this reason.

If it happens in an interrupt, the context of the kernel may not even be
related to the current process.

Many other architectures (x86 for example) already trigger an exception
on a division by zero but the handler will find that the exception
happened in kernel context and generate an Oops, not raise a signal in a
(possibly innocent) userland process.

Gabriel

> Then it also needto add this checking in functions of
> div64_s64(), div64_u64(), div64_u64_rem(), div_s64_rem and div_u64_rem () 
> in include/linux/math64.h
> 
> + if (unlikely(divisor == 0)) {
> + pr_err("%s divisor=0\n",__func__);
> + dump_stack();
> + force_sig(SIGFPE);
> + }
> 
> Guohua
> 
> >>lwz r5,0(r3)# get the dividend into r5/r6
> >>lwz r6,4(r3)
> >>cmplw   r5,r4
> >>@@ -52,6 +55,7 @@ __div64_32:
> >>  4:stw r7,0(r3)# return the quotient in *r3
> >>stw r8,4(r3)
> >>mr  r3,r6   # return the remainder in r3
> >>+5: # return if divisor r4 is zero
> >>blr
> >>  
> >>  /*
> >>diff --git a/arch/powerpc/lib/div64.S b/arch/powerpc/lib/div64.S
> >>index 3d5426e7dcc4..1cc9bcabf678 100644
> >>--- a/arch/powerpc/lib/div64.S
> >>+++ b/arch/powerpc/lib/div64.S
> >>@@ -13,6 +13,9 @@
> >>  #include 
> >>  
> >>  _GLOBAL(__div64_32)
> >>+   li  r9,0
> >>+   cmplw   r4,r9   # check if divisor r4 is zero
> >>+   beq 5f  # jump to label 5 if r4(divisor) is zero
> >>lwz r5,0(r3)# get the dividend into r5/r6
> >>lwz r6,4(r3)
> >>cmplw   r5,r4
> >>@@ -52,4 +55,5 @@ _GLOBAL(__div64_32)
> >>  4:stw r7,0(r3)# return the quotient in *r3
> >>stw r8,4(r3)
> >>mr  r3,r6   # return the remainder in r3
> >>+5: # return if divisor r4 is zero
> >>blr
> >>
>

Re：Re: [PATCH] powerpc: Fix a bug in __div64_32 if divisor is zero

2020-08-22 Thread Guohua Zhong 
>In generic version in lib/math/div64.c, there is no checking of 'base' 
>either.
>Do we really want to add this check in the powerpc version only ?

>The only user of __div64_32() is do_div() in 
>include/asm-generic/div64.h. Wouldn't it be better to do the check there ?

>Christophe

Yet, I have noticed that there is no checking of 'base' in these functions.
But I am not sure how to check is better.As we know that the result is 
undefined when divisor is zero. It maybe good to print error and dump stack.
 Let the process to know that the divisor is zero by sending SIGFPE. 

diff --git a/include/asm-generic/div64.h b/include/asm-generic/div64.h
index a3b98c86f077..161c656ee3ee 100644
--- a/include/asm-generic/div64.h
+++ b/include/asm-generic/div64.h
@@ -43,6 +43,11 @@
 # define do_div(n,base) ({ \
uint32_t __base = (base);   \
uint32_t __rem; \
+ if (unlikely(base == 0)) {  \
+ pr_err("do_div base=%d\n",base);\
+ dump_stack();   \
+ force_sig(SIGFPE);  \
+ }  


Then it also needto add this checking in functions of
div64_s64(), div64_u64(), div64_u64_rem(), div_s64_rem and div_u64_rem () 
in include/linux/math64.h

+ if (unlikely(divisor == 0)) {
+ pr_err("%s divisor=0\n",__func__);
+ dump_stack();
+ force_sig(SIGFPE);
+ }

Guohua

>>  lwz r5,0(r3)# get the dividend into r5/r6
>>  lwz r6,4(r3)
>>  cmplw   r5,r4
>>@@ -52,6 +55,7 @@ __div64_32:
>>  4:  stw r7,0(r3)# return the quotient in *r3
>>  stw r8,4(r3)
>>  mr  r3,r6   # return the remainder in r3
>>+5:   # return if divisor r4 is zero
>>  blr
>>  
>>  /*
>>diff --git a/arch/powerpc/lib/div64.S b/arch/powerpc/lib/div64.S
>>index 3d5426e7dcc4..1cc9bcabf678 100644
>>--- a/arch/powerpc/lib/div64.S
>>+++ b/arch/powerpc/lib/div64.S
>>@@ -13,6 +13,9 @@
>>  #include 
>>  
>>  _GLOBAL(__div64_32)
>>+ li  r9,0
>>+ cmplw   r4,r9   # check if divisor r4 is zero
>>+ beq 5f  # jump to label 5 if r4(divisor) is zero
>>  lwz r5,0(r3)# get the dividend into r5/r6
>>  lwz r6,4(r3)
>>  cmplw   r5,r4
>>@@ -52,4 +55,5 @@ _GLOBAL(__div64_32)
>>  4:  stw r7,0(r3)# return the quotient in *r3
>>  stw r8,4(r3)
>>  mr  r3,r6   # return the remainder in r3
>>+5:   # return if divisor r4 is zero
>>  blr
>>

Re: [PATCH] powerpc: Fix a bug in __div64_32 if divisor is zero

2020-08-22 Thread Guohua Zhong 
>> When cat /proc/pid/stat, do_task_stat will call into cputime_adjust,
>> which call stack is like this:
>> 
>> [17179954.674326]BookE Watchdog detected hard LOCKUP on cpu 0
>> [17179954.674331]dCPU: 0 PID: 1262 Comm: TICK Tainted: PW  O
>> 4.4.176 #1
>> [17179954.674339]dtask: dc9d7040 task.stack: d3cb4000
>> [17179954.674344]NIP: c001b1a8 LR: c006a7ac CTR: 
>> [17179954.674349]REGS: e6fe1f10 TRAP: 3202   Tainted: PW  O 
>> (4.4.176)
>> [17179954.674355]MSR: 00021002   CR: 28002224  XER: 
>> [17179954.674364]
>> GPR00: 0016 d3cb5cb0 dc9d7040 d3cb5cc0  025d ffe15b24 
>> 
>> GPR08: de86aead  03ff  2800 0084d1c0  
>> 
>> GPR16: b5929ca0 b4bb7a48 c0863c08 048d 0062 0062  
>> 000f
>> GPR24:  d3cb5d08 d3cb5d60 d3cb5d64 00029002 d3e9c214 f30e 
>> d3e9c20c
>> [17179954.674410]NIP [c001b1a8] __div64_32+0x60/0xa0
>> [17179954.674422]LR [c006a7ac] cputime_adjust+0x124/0x138
>> [17179954.674434]Call Trace:
>> [17179961.832693]Call Trace:
>> [17179961.832695][d3cb5cb0] [c006a6dc] cputime_adjust+0x54/0x138 (unreliable)
>> [17179961.832705][d3cb5cf0] [c006a818] task_cputime_adjusted+0x58/0x80
>> [17179961.832713][d3cb5d20] [c01dab44] do_task_stat+0x298/0x870
>> [17179961.832720][d3cb5de0] [c01d4948] proc_single_show+0x60/0xa4
>> [17179961.832728][d3cb5e10] [c01963d8] seq_read+0x2d8/0x52c
>> [17179961.832736][d3cb5e80] [c01702fc] __vfs_read+0x40/0x114
>> [17179961.832744][d3cb5ef0] [c0170b1c] vfs_read+0x9c/0x10c
>> [17179961.832751][d3cb5f10] [c0171440] SyS_read+0x68/0xc4
>> [17179961.832759][d3cb5f40] [c0010a40] ret_from_syscall+0x0/0x3c
>> 
>> do_task_stat->task_cputime_adjusted->cputime_adjust->scale_stime->div_u64
>> ->div_u64_rem->do_div->__div64_32
>> 
>> In some corner case, stime + utime = 0 if overflow. Even in v5.8.2  kernel
>> the cputime has changed from unsigned long to u64 data type. About 200
>> days, the lowwer 32 bit will be 0x. Because divisor for __div64_32
>> is unsigned long data type,which is 32 bit for powepc 32, the bug still
>> exists.
>> 
>> So it is also a bug in the cputime_adjust which does not check if
>> stime + utime = 0
>> 
>> time = scale_stime((__force u64)stime, (__force u64)rtime,
>>  (__force u64)(stime + utime));
>> 
>> The commit 3dc167ba5729 ("sched/cputime: Improve cputime_adjust()") in
>> mainline kernel may has fixed this case. But it is also better to check
>> if divisor is 0 in __div64_32 for other situation.
>> 
>> Signed-off-by: Guohua Zhong 
>> Fixes:14cf11af6cf6 "( powerpc: Merge enough to start building in 
>> arch/powerpc.)"
>> Fixes:94b212c29f68 "( powerpc: Move ppc64 boot wrapper code over to 
>> arch/powerpc)"
>> Cc: sta...@vger.kernel.org # v2.6.15+
>> ---
>>   arch/powerpc/boot/div64.S | 4 
>>   arch/powerpc/lib/div64.S  | 4 
>>   2 files changed, 8 insertions(+)
>> 
>> diff --git a/arch/powerpc/boot/div64.S b/arch/powerpc/boot/div64.S
>> index 4354928ed62e..39a25b9712d1 100644
>> --- a/arch/powerpc/boot/div64.S
>> +++ b/arch/powerpc/boot/div64.S
>> @@ -13,6 +13,9 @@
>>   
>>  .globl __div64_32
>>   __div64_32:
>> +li  r9,0
>> +cmplw   r4,r9   # check if divisor r4 is zero
>> +beq 5f  # jump to label 5 if r4(divisor) is zero
>>  lwz r5,0(r3)# get the dividend into r5/r6
>>  lwz r6,4(r3)
>>  cmplw   r5,r4
>> @@ -52,6 +55,7 @@ __div64_32:
>>   4: stw r7,0(r3)# return the quotient in *r3
>>  stw r8,4(r3)
>>  mr  r3,r6   # return the remainder in r3
>> +5:  # return if divisor r4 is zero
>>  blr
>>   
>>   /*
>> diff --git a/arch/powerpc/lib/div64.S b/arch/powerpc/lib/div64.S
>> index 3d5426e7dcc4..1cc9bcabf678 100644
>> --- a/arch/powerpc/lib/div64.S
>> +++ b/arch/powerpc/lib/div64.S
>> @@ -13,6 +13,9 @@
>>   #include 
>>   
>>   _GLOBAL(__div64_32)
>> +li  r9,0

>You don't need to load r9 with 0, use cmplwi instead.

I will change cmplw to cmplwi in next patch as your suggestion. Thanks

>> +cmplw   r4,r9   # check if divisor r4 is zero
>> +beq 5f  # jump to label 5 if r4(divisor) is zero

>You should leave space between the compare and the branch (i.e. have 
>other instructions inbetween when possible), so that the processor can 
>prepare the branching and do a good prediction. Same as the compare 
>below, you see that there are two other instructions between the cmplw 
>are the blt. You can eventually use another cr field than cr0 in order 
>to nest several test/branches.
>Also because on recent powerpc32, instructions are fetched and executed 
>two by two.

Good advice! 

OK, let two lwz instructions between campare and branch as below:

diff --git a/arch/powerpc/lib/div64.S b/arch/powerpc/lib/div64.S
index 3d5426e7dcc4..570774d9782d 100644
li  r8,0
--- a/arch/powerpc/lib/div64.S
+++

Re: [PATCH] powerpc: Fix a bug in __div64_32 if divisor is zero

2020-08-22 Thread Guohua Zhong 
>> When cat /proc/pid/stat, do_task_stat will call into cputime_adjust,
>> which call stack is like this:
>> 
>> [17179954.674326]BookE Watchdog detected hard LOCKUP on cpu 0
>> [17179954.674331]dCPU: 0 PID: 1262 Comm: TICK Tainted: PW  O
>> 4.4.176 #1
>> [17179954.674339]dtask: dc9d7040 task.stack: d3cb4000
>> [17179954.674344]NIP: c001b1a8 LR: c006a7ac CTR: 
>> [17179954.674349]REGS: e6fe1f10 TRAP: 3202   Tainted: PW  O 
>> (4.4.176)
>> [17179954.674355]MSR: 00021002   CR: 28002224  XER: 
>> [17179954.674364]
>> GPR00: 0016 d3cb5cb0 dc9d7040 d3cb5cc0  025d ffe15b24 
>> 
>> GPR08: de86aead  03ff  2800 0084d1c0  
>> 
>> GPR16: b5929ca0 b4bb7a48 c0863c08 048d 0062 0062  
>> 000f
>> GPR24:  d3cb5d08 d3cb5d60 d3cb5d64 00029002 d3e9c214 f30e 
>> d3e9c20c
>> [17179954.674410]NIP [c001b1a8] __div64_32+0x60/0xa0
>> [17179954.674422]LR [c006a7ac] cputime_adjust+0x124/0x138
>> [17179954.674434]Call Trace:
>> [17179961.832693]Call Trace:
>> [17179961.832695][d3cb5cb0] [c006a6dc] cputime_adjust+0x54/0x138 (unreliable)
>> [17179961.832705][d3cb5cf0] [c006a818] task_cputime_adjusted+0x58/0x80
>> [17179961.832713][d3cb5d20] [c01dab44] do_task_stat+0x298/0x870
>> [17179961.832720][d3cb5de0] [c01d4948] proc_single_show+0x60/0xa4
>> [17179961.832728][d3cb5e10] [c01963d8] seq_read+0x2d8/0x52c
>> [17179961.832736][d3cb5e80] [c01702fc] __vfs_read+0x40/0x114
>> [17179961.832744][d3cb5ef0] [c0170b1c] vfs_read+0x9c/0x10c
>> [17179961.832751][d3cb5f10] [c0171440] SyS_read+0x68/0xc4
>> [17179961.832759][d3cb5f40] [c0010a40] ret_from_syscall+0x0/0x3c
>> 
>> do_task_stat->task_cputime_adjusted->cputime_adjust->scale_stime->div_u64
>> ->div_u64_rem->do_div->__div64_32
>> 
>> In some corner case, stime + utime = 0 if overflow. Even in v5.8.2  kernel
>> the cputime has changed from unsigned long to u64 data type. About 200
>> days, the lowwer 32 bit will be 0x. Because divisor for __div64_32
>> is unsigned long data type,which is 32 bit for powepc 32, the bug still
>> exists.
>> 
>> So it is also a bug in the cputime_adjust which does not check if
>> stime + utime = 0
>> 
>> time = scale_stime((__force u64)stime, (__force u64)rtime,
>>  (__force u64)(stime + utime));
>> 
>> The commit 3dc167ba5729 ("sched/cputime: Improve cputime_adjust()") in
>> mainline kernel may has fixed this case. But it is also better to check
>> if divisor is 0 in __div64_32 for other situation.
>> 
>> Signed-off-by: Guohua Zhong 
>> Fixes:14cf11af6cf6 "( powerpc: Merge enough to start building in 
>> arch/powerpc.)"
>> Fixes:94b212c29f68 "( powerpc: Move ppc64 boot wrapper code over to 
>> arch/powerpc)"
>> Cc: sta...@vger.kernel.org # v2.6.15+
>> ---
>>   arch/powerpc/boot/div64.S | 4 
>>   arch/powerpc/lib/div64.S  | 4 
>>   2 files changed, 8 insertions(+)
>> 
>> diff --git a/arch/powerpc/boot/div64.S b/arch/powerpc/boot/div64.S
>> index 4354928ed62e..39a25b9712d1 100644
>> --- a/arch/powerpc/boot/div64.S
>> +++ b/arch/powerpc/boot/div64.S
>> @@ -13,6 +13,9 @@
>>   
>>  .globl __div64_32
>>   __div64_32:
>> +li  r9,0
>> +cmplw   r4,r9   # check if divisor r4 is zero
>> +beq 5f  # jump to label 5 if r4(divisor) is zero
>>  lwz r5,0(r3)# get the dividend into r5/r6
>>  lwz r6,4(r3)
>>  cmplw   r5,r4
>> @@ -52,6 +55,7 @@ __div64_32:
>>   4: stw r7,0(r3)# return the quotient in *r3
>>  stw r8,4(r3)
>>  mr  r3,r6   # return the remainder in r3
>> +5:  # return if divisor r4 is zero
>>  blr
>>   
>>   /*
>> diff --git a/arch/powerpc/lib/div64.S b/arch/powerpc/lib/div64.S
>> index 3d5426e7dcc4..1cc9bcabf678 100644
>> --- a/arch/powerpc/lib/div64.S
>> +++ b/arch/powerpc/lib/div64.S
>> @@ -13,6 +13,9 @@
>>   #include 
>>   
>>   _GLOBAL(__div64_32)
>> +li  r9,0

>You don't need to load r9 with 0, use cmplwi instead.

I will change cmplw to cmplwi in next patch as your suggestion. Thanks

>> +cmplw   r4,r9   # check if divisor r4 is zero
>> +beq 5f  # jump to label 5 if r4(divisor) is zero

>You should leave space between the compare and the branch (i.e. have 
>other instructions inbetween when possible), so that the processor can 
>prepare the branching and do a good prediction. Same as the compare 
>below, you see that there are two other instructions between the cmplw 
>are the blt. You can eventually use another cr field than cr0 in order 
>to nest several test/branches.
>Also because on recent powerpc32, instructions are fetched and executed 
>two by two.

Good advice! 

OK, let two lwz instructions between campare and branch as below:

diff --git a/arch/powerpc/lib/div64.S b/arch/powerpc/lib/div64.S
index 3d5426e7dcc4..570774d9782d 100644
li  r8,0
--- a/arch/powerpc/lib/div64.S
+++

[PATCH v2] dt-bindings: vendor-prefixes: Add Cisco Meraki vendor prefix

2020-08-22 Thread Christian Lamparter 
Meraki was founded in 2006. The start-up quickly rose to prominence
by being based in part on the MIT Roofnet Project.
In December 2012, Cisco Systems, Inc. bought Meraki.
The "Meraki" branding is still around to this day.

Web site of the company: https://meraki.cisco.com/

Signed-off-by: Christian Lamparter 
---

v1 -> v2:
Split from Meraki MR32 upstreaming attempt. (Florian Fainelli)
(This patch will be needed for the MR24 upstreaming series as well)
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml 
b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 2baee2c817c1..febe7f00b1f0 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -643,6 +643,8 @@ patternProperties:
 description: MEMSIC Inc.
   "^menlo,.*":
 description: Menlo Systems GmbH
+  "^meraki,.*":
+description: Cisco Meraki, LLC
   "^merrii,.*":
 description: Merrii Technology Co., Ltd.
   "^micrel,.*":
-- 
2.28.0

Re: [PATCH v1 04/10] powerpc/kernel/iommu: Add new iommu_table_in_use() helper

2020-08-22 Thread Alexey Kardashevskiy 



On 18/08/2020 09:40, Leonardo Bras wrote:
> Having a function to check if the iommu table has any allocation helps
> deciding if a tbl can be reset for using a new DMA window.
> 
> It should be enough to replace all instances of !bitmap_empty(tbl...).
> 
> iommu_table_in_use() skips reserved memory, so we don't need to worry about
> releasing it before testing. This causes iommu_table_release_pages() to
> become unnecessary, given it is only used to remove reserved memory for
> testing.
> 
> Signed-off-by: Leonardo Bras 
> ---
>  arch/powerpc/include/asm/iommu.h |  1 +
>  arch/powerpc/kernel/iommu.c  | 62 ++--
>  2 files changed, 37 insertions(+), 26 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/iommu.h 
> b/arch/powerpc/include/asm/iommu.h
> index 5032f1593299..2913e5c8b1f8 100644
> --- a/arch/powerpc/include/asm/iommu.h
> +++ b/arch/powerpc/include/asm/iommu.h
> @@ -154,6 +154,7 @@ extern int iommu_tce_table_put(struct iommu_table *tbl);
>   */
>  extern struct iommu_table *iommu_init_table(struct iommu_table *tbl,
>   int nid, unsigned long res_start, unsigned long res_end);
> +bool iommu_table_in_use(struct iommu_table *tbl);
>  
>  #define IOMMU_TABLE_GROUP_MAX_TABLES 2
>  
> diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
> index 7f603d4e62d4..c5d5d36ab65e 100644
> --- a/arch/powerpc/kernel/iommu.c
> +++ b/arch/powerpc/kernel/iommu.c
> @@ -668,21 +668,6 @@ static void iommu_table_reserve_pages(struct iommu_table 
> *tbl,
>   set_bit(i - tbl->it_offset, tbl->it_map);
>  }
>  
> -static void iommu_table_release_pages(struct iommu_table *tbl)
> -{
> - int i;
> -
> - /*
> -  * In case we have reserved the first bit, we should not emit
> -  * the warning below.
> -  */
> - if (tbl->it_offset == 0)
> - clear_bit(0, tbl->it_map);
> -
> - for (i = tbl->it_reserved_start; i < tbl->it_reserved_end; ++i)
> - clear_bit(i - tbl->it_offset, tbl->it_map);
> -}
> -
>  /*
>   * Build a iommu_table structure.  This contains a bit map which
>   * is used to manage allocation of the tce space.
> @@ -743,6 +728,38 @@ struct iommu_table *iommu_init_table(struct iommu_table 
> *tbl, int nid,
>   return tbl;
>  }
>  
> +bool iommu_table_in_use(struct iommu_table *tbl)
> +{
> + bool in_use;
> + unsigned long p1_start = 0, p1_end, p2_start, p2_end;
> +
> + /*ignore reserved bit0*/

s/ignore reserved bit0/ ignore reserved bit0 /  (add spaces)

> + if (tbl->it_offset == 0)
> + p1_start = 1;
> +
> + /* Check if reserved memory is valid*/

A missing space here.

> + if (tbl->it_reserved_start >= tbl->it_offset &&
> + tbl->it_reserved_start <= (tbl->it_offset + tbl->it_size) &&
> + tbl->it_reserved_end   >= tbl->it_offset &&
> + tbl->it_reserved_end   <= (tbl->it_offset + tbl->it_size)) {


Uff. What if tbl->it_reserved_end is bigger than tbl->it_offset +
tbl->it_size?

The reserved area is to preserve MMIO32 so it is for it_offset==0 only
and the boundaries are checked in the only callsite, and it is unlikely
to change soon or ever.

Rather that bothering with fixing that, may be just add (did not test):

if (WARN_ON((
(tbl->it_reserved_start || tbl->it_reserved_end) && (it_offset != 0))
||
(tbl->it_reserved_start > it_offset && tbl->it_reserved_end < it_offset
+ it_size) && (it_offset == 0)) )
 return true;

Or simply always look for it_offset..it_reserved_start and
it_reserved_end..it_offset+it_size and if there is no reserved area,
initialize it_reserved_start=it_reserved_end=it_offset so the first
it_offset..it_reserved_start becomes a no-op.


> + p1_end = tbl->it_reserved_start - tbl->it_offset;
> + p2_start = tbl->it_reserved_end - tbl->it_offset + 1;
> + p2_end = tbl->it_size;
> + } else {
> + p1_end = tbl->it_size;
> + p2_start = 0;
> + p2_end = 0;
> + }
> +
> + in_use = (find_next_bit(tbl->it_map, p1_end, p1_start) != p1_end);
> + if (in_use || p2_start == 0)
> + return in_use;
> +
> + in_use = (find_next_bit(tbl->it_map, p2_end, p2_start) != p2_end);
> +
> + return in_use;
> +}
> +
>  static void iommu_table_free(struct kref *kref)
>  {
>   unsigned long bitmap_sz;
> @@ -759,10 +776,8 @@ static void iommu_table_free(struct kref *kref)
>   return;
>   }
>  
> - iommu_table_release_pages(tbl);
> -
>   /* verify that table contains no entries */
> - if (!bitmap_empty(tbl->it_map, tbl->it_size))
> + if (iommu_table_in_use(tbl))
>   pr_warn("%s: Unexpected TCEs\n", __func__);
>  
>   /* calculate bitmap size in bytes */
> @@ -1069,18 +1084,13 @@ int iommu_take_ownership(struct iommu_table *tbl)
>   for (i = 0; i < tbl->nr_pools; i++)
>   spin_lock(>pools[i].lock);
>  
> - iommu_table_release_pages(tbl);
> -
> - if

Re: [PATCH v1 03/10] powerpc/kernel/iommu: Use largepool as a last resort when !largealloc

2020-08-22 Thread Alexey Kardashevskiy 



On 18/08/2020 09:40, Leonardo Bras wrote:
> As of today, doing iommu_range_alloc() only for !largealloc (npages <= 15)
> will only be able to use 3/4 of the available pages, given pages on
> largepool  not being available for !largealloc.
> 
> This could mean some drivers not being able to fully use all the available
> pages for the DMA window.
> 
> Add pages on largepool as a last resort for !largealloc, making all pages
> of the DMA window available.
> 
> Signed-off-by: Leonardo Bras 
> ---
>  arch/powerpc/kernel/iommu.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
> index d7086087830f..7f603d4e62d4 100644
> --- a/arch/powerpc/kernel/iommu.c
> +++ b/arch/powerpc/kernel/iommu.c
> @@ -261,6 +261,15 @@ static unsigned long iommu_range_alloc(struct device 
> *dev,
>   pass++;
>   goto again;
>  
> + } else if (pass == tbl->nr_pools + 1) {
> + /* Last resort: try largepool */
> + spin_unlock(>lock);
> + pool = >large_pool;
> + spin_lock(>lock);
> + pool->hint = pool->start;
> + pass++;
> + goto again;
> +


A nit: unnecessary new line.


Reviewed-by: Alexey Kardashevskiy 



>   } else {
>   /* Give up */
>   spin_unlock_irqrestore(&(pool->lock), flags);
> 

-- 
Alexey

Re: [PATCH v1 02/10] powerpc/kernel/iommu: Align size for IOMMU_PAGE_SIZE on iommu_*_coherent()

2020-08-22 Thread Alexey Kardashevskiy 



On 18/08/2020 09:40, Leonardo Bras wrote:
> Both iommu_alloc_coherent() and iommu_free_coherent() assume that once
> size is aligned to PAGE_SIZE it will be aligned to IOMMU_PAGE_SIZE.

The only case when it is not aligned is when IOMMU_PAGE_SIZE > PAGE_SIZE
which is unlikely but not impossible, we could configure the kernel for
4K system pages and 64K IOMMU pages I suppose. Do we really want to do
this here, or simply put WARN_ON(tbl->it_page_shift > PAGE_SHIFT)?
Because if we want the former (==support), then we'll have to align the
size up to the bigger page size when allocating/zeroing system pages,
etc. Bigger pages are not the case here as I understand it.


> 
> Update those functions to guarantee alignment with requested size
> using IOMMU_PAGE_ALIGN() before doing iommu_alloc() / iommu_free().
> 
> Also, on iommu_range_alloc(), replace ALIGN(n, 1 << tbl->it_page_shift)
> with IOMMU_PAGE_ALIGN(n, tbl), which seems easier to read.
> 
> Signed-off-by: Leonardo Bras 
> ---
>  arch/powerpc/kernel/iommu.c | 17 +
>  1 file changed, 9 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
> index 9704f3f76e63..d7086087830f 100644
> --- a/arch/powerpc/kernel/iommu.c
> +++ b/arch/powerpc/kernel/iommu.c
> @@ -237,10 +237,9 @@ static unsigned long iommu_range_alloc(struct device 
> *dev,
>   }
>  
>   if (dev)
> - boundary_size = ALIGN(dma_get_seg_boundary(dev) + 1,
> -   1 << tbl->it_page_shift);
> + boundary_size = IOMMU_PAGE_ALIGN(dma_get_seg_boundary(dev) + 1, 
> tbl);


Run checkpatch.pl, should complain about a long line.


>   else
> - boundary_size = ALIGN(1UL << 32, 1 << tbl->it_page_shift);
> + boundary_size = IOMMU_PAGE_ALIGN(1UL << 32, tbl);
>   /* 4GB boundary for iseries_hv_alloc and iseries_hv_map */
>  
>   n = iommu_area_alloc(tbl->it_map, limit, start, npages, tbl->it_offset,
> @@ -858,6 +857,7 @@ void *iommu_alloc_coherent(struct device *dev, struct 
> iommu_table *tbl,
>   unsigned int order;
>   unsigned int nio_pages, io_order;
>   struct page *page;
> + size_t size_io = size;
>  
>   size = PAGE_ALIGN(size);
>   order = get_order(size);
> @@ -884,8 +884,9 @@ void *iommu_alloc_coherent(struct device *dev, struct 
> iommu_table *tbl,
>   memset(ret, 0, size);
>  
>   /* Set up tces to cover the allocated range */
> - nio_pages = size >> tbl->it_page_shift;
> - io_order = get_iommu_order(size, tbl);
> + size_io = IOMMU_PAGE_ALIGN(size_io, tbl);
> + nio_pages = size_io >> tbl->it_page_shift;
> + io_order = get_iommu_order(size_io, tbl);
>   mapping = iommu_alloc(dev, tbl, ret, nio_pages, DMA_BIDIRECTIONAL,
> mask >> tbl->it_page_shift, io_order, 0);
>   if (mapping == DMA_MAPPING_ERROR) {
> @@ -900,11 +901,11 @@ void iommu_free_coherent(struct iommu_table *tbl, 
> size_t size,
>void *vaddr, dma_addr_t dma_handle)
>  {
>   if (tbl) {
> - unsigned int nio_pages;
> + size_t size_io = IOMMU_PAGE_ALIGN(size, tbl);
> + unsigned int nio_pages = size_io >> tbl->it_page_shift;
>  
> - size = PAGE_ALIGN(size);
> - nio_pages = size >> tbl->it_page_shift;
>   iommu_free(tbl, dma_handle, nio_pages);
> +

Unrelated new line.


>   size = PAGE_ALIGN(size);
>   free_pages((unsigned long)vaddr, get_order(size));
>   }
> 

-- 
Alexey

Re: [PATCH v1 01/10] powerpc/pseries/iommu: Replace hard-coded page shift

2020-08-22 Thread Alexey Kardashevskiy 



On 18/08/2020 09:40, Leonardo Bras wrote:
> Some functions assume IOMMU page size can only be 4K (pageshift == 12).
> Update them to accept any page size passed, so we can use 64K pages.
> 
> In the process, some defines like TCE_SHIFT were made obsolete, and then
> removed. TCE_RPN_MASK was updated to generate a mask according to
> the pageshift used.
> 
> Most places had a tbl struct, so using tbl->it_page_shift was simple.
> tce_free_pSeriesLP() was a special case, since callers not always have a
> tbl struct, so adding a tceshift parameter seems the right thing to do.
> 
> Signed-off-by: Leonardo Bras 
> ---
>  arch/powerpc/include/asm/tce.h | 10 ++
>  arch/powerpc/platforms/pseries/iommu.c | 42 --
>  2 files changed, 28 insertions(+), 24 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/tce.h b/arch/powerpc/include/asm/tce.h
> index db5fc2f2262d..971cba2d87cc 100644
> --- a/arch/powerpc/include/asm/tce.h
> +++ b/arch/powerpc/include/asm/tce.h
> @@ -19,15 +19,9 @@
>  #define TCE_VB   0
>  #define TCE_PCI  1
>  
> -/* TCE page size is 4096 bytes (1 << 12) */
> -
> -#define TCE_SHIFT12
> -#define TCE_PAGE_SIZE(1 << TCE_SHIFT)
> -
>  #define TCE_ENTRY_SIZE   8   /* each TCE is 64 bits 
> */
> -
> -#define TCE_RPN_MASK 0xfful  /* 40-bit RPN (4K pages) */
> -#define TCE_RPN_SHIFT12
> +#define TCE_RPN_BITS 52  /* Bits 0-51 represent RPN on 
> TCE */


Ditch this one and use MAX_PHYSMEM_BITS instead? I am pretty sure this
is the actual limit.


> +#define TCE_RPN_MASK(ps) ((1ul << (TCE_RPN_BITS - (ps))) - 1)
>  #define TCE_VALID0x800   /* TCE valid */
>  #define TCE_ALLIO0x400   /* TCE valid for all lpars */
>  #define TCE_PCI_WRITE0x2 /* write from PCI 
> allowed */
> diff --git a/arch/powerpc/platforms/pseries/iommu.c 
> b/arch/powerpc/platforms/pseries/iommu.c
> index e4198700ed1a..8fe23b7dff3a 100644
> --- a/arch/powerpc/platforms/pseries/iommu.c
> +++ b/arch/powerpc/platforms/pseries/iommu.c
> @@ -107,6 +107,9 @@ static int tce_build_pSeries(struct iommu_table *tbl, 
> long index,
>   u64 proto_tce;
>   __be64 *tcep;
>   u64 rpn;
> + const unsigned long tceshift = tbl->it_page_shift;
> + const unsigned long pagesize = IOMMU_PAGE_SIZE(tbl);
> + const u64 rpn_mask = TCE_RPN_MASK(tceshift);

Using IOMMU_PAGE_SIZE macro for the page size and not using
IOMMU_PAGE_MASK for the mask - this incosistency makes my small brain
explode :) I understand the history but man... Oh well, ok.

Good, otherwise. Thanks,

>  
>   proto_tce = TCE_PCI_READ; // Read allowed
>  
> @@ -117,10 +120,10 @@ static int tce_build_pSeries(struct iommu_table *tbl, 
> long index,
>  
>   while (npages--) {
>   /* can't move this out since we might cross MEMBLOCK boundary */
> - rpn = __pa(uaddr) >> TCE_SHIFT;
> - *tcep = cpu_to_be64(proto_tce | (rpn & TCE_RPN_MASK) << 
> TCE_RPN_SHIFT);
> + rpn = __pa(uaddr) >> tceshift;
> + *tcep = cpu_to_be64(proto_tce | (rpn & rpn_mask) << tceshift);
>  
> - uaddr += TCE_PAGE_SIZE;
> + uaddr += pagesize;
>   tcep++;
>   }
>   return 0;
> @@ -146,7 +149,7 @@ static unsigned long tce_get_pseries(struct iommu_table 
> *tbl, long index)
>   return be64_to_cpu(*tcep);
>  }
>  
> -static void tce_free_pSeriesLP(unsigned long liobn, long, long);
> +static void tce_free_pSeriesLP(unsigned long liobn, long, long, long);
>  static void tce_freemulti_pSeriesLP(struct iommu_table*, long, long);
>  
>  static int tce_build_pSeriesLP(unsigned long liobn, long tcenum, long 
> tceshift,
> @@ -159,6 +162,7 @@ static int tce_build_pSeriesLP(unsigned long liobn, long 
> tcenum, long tceshift,
>   u64 rpn;
>   int ret = 0;
>   long tcenum_start = tcenum, npages_start = npages;
> + const u64 rpn_mask = TCE_RPN_MASK(tceshift);
>  
>   rpn = __pa(uaddr) >> tceshift;
>   proto_tce = TCE_PCI_READ;
> @@ -166,12 +170,12 @@ static int tce_build_pSeriesLP(unsigned long liobn, 
> long tcenum, long tceshift,
>   proto_tce |= TCE_PCI_WRITE;
>  
>   while (npages--) {
> - tce = proto_tce | (rpn & TCE_RPN_MASK) << tceshift;
> + tce = proto_tce | (rpn & rpn_mask) << tceshift;
>   rc = plpar_tce_put((u64)liobn, (u64)tcenum << tceshift, tce);
>  
>   if (unlikely(rc == H_NOT_ENOUGH_RESOURCES)) {
>   ret = (int)rc;
> - tce_free_pSeriesLP(liobn, tcenum_start,
> + tce_free_pSeriesLP(liobn, tcenum_start, tceshift,
>  (npages_start - (npages + 1)));
>   break;
>   }
> @@ -205,10 +209,12 @@ static int tce_buildmulti_pSeriesLP(struct iommu_table

Re: kernel since 5.6 do not boot anymore on Apple PowerBook

2020-08-22 Thread Giuseppe Sacco 
Hello Christophe,

Il giorno ven, 21/08/2020 alle 16.03 +0200, Christophe Leroy ha
scritto:
[...]
> Thanks.
> 
> The Oops in the video shows that the issue is at 0x1bcac and msr
> value 
> shows that Instruction MMU is disabled. So this corresponds to
> address 
> 0xc001bcac. In the vmlinux you sent me this address is in 
> power_save_ppc32_restore()
> 
> This issue is fixed by 
> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/7bce32ccbab3ba3e3e0f27da6961bf6313df97ed.1581663140.git.christophe.le...@c-s.fr/
> 
> 
> You also said in a previous mail that your original issue also
> happens 
> when CONFIG_VMAP_STACK is not selected. The above bug being linked
> to 
> CONFIG_VMAP_STACK, maybe it would be easier to bisect with 
> CONFIG_VMAP_STACK unselected.

I was wrong. Disabling CONFIG_VMAP_STACK led me to all "good" compile
and bisect ended without finding the culprit commit.

So, I started from scratch: I rebuilt HEAD and found that it does show
the original problem I am facing, then I rebuilt it without
CONFIG_VMAP_STACK and found that it does pass (fix?) the problem, since
kernel continue booting, but then it stops with three Oops related to
command systemd-udevd.

You may find a video that displays the complete boot, vmlinux, config,
and system.map files here:

https://eppesuigoccas.homedns.org/~giuseppe/powerpc32/config-5.9.0-rc1+
https://eppesuigoccas.homedns.org/~giuseppe/powerpc32/System.map
https://eppesuigoccas.homedns.org/~giuseppe/powerpc32/VID_20200822_095621.mp4
https://eppesuigoccas.homedns.org/~giuseppe/powerpc32/vmlinux.strip.gz

Bye,
Giuseppe

Re: [PATCH] powerpc/prom_init: Check display props exist before enabling btext

2020-08-22 Thread Alexey Kardashevskiy 



On 21/08/2020 20:34, Michael Ellerman wrote:
> It's possible to enable CONFIG_PPC_EARLY_DEBUG_BOOTX for a pseries
> kernel (maybe it shouldn't be), which is then booted with qemu/slof.


CONFIG_BOOTX_TEXT=y
CONFIG_PPC_EARLY_DEBUG=y
CONFIG_PPC_EARLY_DEBUG_BOOTX=y

this does not crash my VM. The changed chunk is sitting under "if
(prom_getprop(node, "linux,boot-display", NULL, 0)" and I cannot find
what creates this property - it is neither slof/grub/qemu, unlikely that
it is phyp so it must be this one:

arch/powerpc/platforms/powermac/bootx_init.c|244|
bootx_dt_add_string("linux,boot-display", mem_end);


which is powermac and not pseries. Or may be that pmac firmware.

Where did you see this crash?


> But if you do that the kernel crashes in draw_byte(), with a DAR
> pointing somewhere near INT_MAX.
> 
> Adding some debug to prom_init we see that we're not able to read the
> "address" property from OF, so we're just using whatever junk value
> was on the stack.
> 
> So check the properties can be read properly from OF, if not we bail
> out before initialising btext, which avoids the crash.

This is a right thing any way, just the commit log is confusing.

Reviewed-by: Alexey Kardashevskiy 



> 
> Signed-off-by: Michael Ellerman 
> ---
>  arch/powerpc/kernel/prom_init.c | 17 +
>  1 file changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
> index ae7ec9903191..5090a5ab54e5 100644
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -2422,10 +2422,19 @@ static void __init prom_check_displays(void)
>   u32 width, height, pitch, addr;
>  
>   prom_printf("Setting btext !\n");
> - prom_getprop(node, "width", , 4);
> - prom_getprop(node, "height", , 4);
> - prom_getprop(node, "linebytes", , 4);
> - prom_getprop(node, "address", , 4);
> +
> + if (prom_getprop(node, "width", , 4) == 
> PROM_ERROR)
> + return;
> +
> + if (prom_getprop(node, "height", , 4) == 
> PROM_ERROR)
> + return;
> +
> + if (prom_getprop(node, "linebytes", , 4) == 
> PROM_ERROR)
> + return;
> +
> + if (prom_getprop(node, "address", , 4) == 
> PROM_ERROR)
> + return;
> +
>   prom_printf("W=%d H=%d LB=%d addr=0x%x\n",
>   width, height, pitch, addr);
>   btext_setup_display(width, height, 8, pitch, addr);
> 

-- 
Alexey

[powerpc:merge] BUILD SUCCESS d19274eb71328b768fcebe940a61eac39f8daecc

2020-08-22 Thread kernel test robot 
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git  
merge
branch HEAD: d19274eb71328b768fcebe940a61eac39f8daecc  Automatic merge of 
'master', 'next' and 'fixes' (2020-08-21 23:47)

elapsed time: 1042m

configs tested: 79
configs skipped: 1

The following configs have been built successfully.
More configs may be tested in the coming days.

arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
mipsbcm47xx_defconfig
powerpccell_defconfig
arm   corgi_defconfig
riscvalldefconfig
arm   milbeaut_m10v_defconfig
sh ecovec24_defconfig
arm  collie_defconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
powerpc defconfig
i386 randconfig-a002-20200820
i386 randconfig-a004-20200820
i386 randconfig-a005-20200820
i386 randconfig-a003-20200820
i386 randconfig-a006-20200820
i386 randconfig-a001-20200820
x86_64   randconfig-a015-20200820
x86_64   randconfig-a012-20200820
x86_64   randconfig-a016-20200820
x86_64   randconfig-a014-20200820
x86_64   randconfig-a011-20200820
x86_64   randconfig-a013-20200820
i386 randconfig-a013-20200820
i386 randconfig-a012-20200820
i386 randconfig-a011-20200820
i386 randconfig-a016-20200820
i386 randconfig-a014-20200820
i386 randconfig-a015-20200820
i386 randconfig-a013-20200821
i386 randconfig-a012-20200821
i386 randconfig-a011-20200821
i386 randconfig-a016-20200821
i386 randconfig-a014-20200821
i386 randconfig-a015-20200821
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  kexec

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org

[powerpc:next-test] BUILD SUCCESS 02ee70dacfacaceb80719eee2c9b929170b6440a

2020-08-22 Thread kernel test robot 
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git  
next-test
branch HEAD: 02ee70dacfacaceb80719eee2c9b929170b6440a  video: fbdev: controlfb: 
Fix build for COMPILE_TEST=y && PPC_PMAC=n

elapsed time: 1041m

configs tested: 84
configs skipped: 1

The following configs have been built successfully.
More configs may be tested in the coming days.

arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
mipsbcm47xx_defconfig
powerpccell_defconfig
arm   corgi_defconfig
riscvalldefconfig
arm   milbeaut_m10v_defconfig
sh ecovec24_defconfig
arm  collie_defconfig
arm   aspeed_g4_defconfig
armclps711x_defconfig
arm   spitz_defconfig
shapsh4ad0a_defconfig
arm orion5x_defconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
powerpc defconfig
i386 randconfig-a002-20200820
i386 randconfig-a004-20200820
i386 randconfig-a005-20200820
i386 randconfig-a003-20200820
i386 randconfig-a006-20200820
i386 randconfig-a001-20200820
x86_64   randconfig-a015-20200820
x86_64   randconfig-a012-20200820
x86_64   randconfig-a016-20200820
x86_64   randconfig-a014-20200820
x86_64   randconfig-a011-20200820
x86_64   randconfig-a013-20200820
i386 randconfig-a013-20200820
i386 randconfig-a012-20200820
i386 randconfig-a011-20200820
i386 randconfig-a016-20200820
i386 randconfig-a014-20200820
i386 randconfig-a015-20200820
i386 randconfig-a013-20200821
i386 randconfig-a012-20200821
i386 randconfig-a011-20200821
i386 randconfig-a016-20200821
i386 randconfig-a014-20200821
i386 randconfig-a015-20200821
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  kexec

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org

[powerpc:fixes-test] BUILD SUCCESS 64ef8f2c4791940d7f3945507b6a45c20d959260

2020-08-22 Thread kernel test robot 
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git  
fixes-test
branch HEAD: 64ef8f2c4791940d7f3945507b6a45c20d959260  powerpc/perf/hv-24x7: 
Move cpumask file to top folder of hv-24x7 driver

elapsed time: 1042m

configs tested: 82
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
mips   ip28_defconfig
x86_64   allyesconfig
armmmp2_defconfig
h8300h8300h-sim_defconfig
riscv   defconfig
mipsbcm47xx_defconfig
powerpccell_defconfig
arm   corgi_defconfig
riscvalldefconfig
arm   milbeaut_m10v_defconfig
sh ecovec24_defconfig
arm  collie_defconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
powerpc defconfig
i386 randconfig-a002-20200820
i386 randconfig-a004-20200820
i386 randconfig-a005-20200820
i386 randconfig-a003-20200820
i386 randconfig-a006-20200820
i386 randconfig-a001-20200820
x86_64   randconfig-a015-20200820
x86_64   randconfig-a012-20200820
x86_64   randconfig-a016-20200820
x86_64   randconfig-a014-20200820
x86_64   randconfig-a011-20200820
x86_64   randconfig-a013-20200820
i386 randconfig-a013-20200820
i386 randconfig-a012-20200820
i386 randconfig-a011-20200820
i386 randconfig-a016-20200820
i386 randconfig-a014-20200820
i386 randconfig-a015-20200820
i386 randconfig-a013-20200821
i386 randconfig-a012-20200821
i386 randconfig-a011-20200821
i386 randconfig-a016-20200821
i386 randconfig-a014-20200821
i386 randconfig-a015-20200821
riscvallyesconfig
riscv allnoconfig
riscvallmodconfig
x86_64   rhel
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  kexec

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org

Re: [mm] 8e63b8bbd7: WARNING:at_mm/memory.c:#__apply_to_page_range

2020-08-22 Thread Nicholas Piggin 
Excerpts from kernel test robot's message of August 22, 2020 9:24 am:
> Greeting,
> 
> FYI, we noticed the following commit (built with gcc-9):
> 
> commit: 8e63b8bbd7d17f64ced151cebd151a2cd9f63c64 ("[PATCH v5 2/8] mm: 
> apply_to_pte_range warn and fail if a large pte is encountered")
> url: 
> https://github.com/0day-ci/linux/commits/Nicholas-Piggin/huge-vmalloc-mappings/20200821-124543
> base: https://git.kernel.org/cgit/linux/kernel/git/powerpc/linux.git next
> 
> in testcase: boot
> 
> on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 8G
> 
> caused below changes (please refer to attached dmesg/kmsg for entire 
> log/backtrace):
> 
> 
> +---+++
> |   | 185311995a | 8e63b8bbd7 |
> +---+++
> | boot_successes| 4  | 0  |
> | boot_failures | 0  | 4  |
> | WARNING:at_mm/memory.c:#__apply_to_page_range | 0  | 4  |
> | RIP:__apply_to_page_range | 0  | 4  |
> +---+++
> 
> 
> If you fix the issue, kindly add following tag
> Reported-by: kernel test robot 
> 
> 
> [0.786159] WARNING: CPU: 0 PID: 0 at mm/memory.c:2269 
> __apply_to_page_range+0x537/0x9c0

Hmm, I wonder if that's WARN_ON_ONCE(pmd_bad(*pmd))), which would be
odd. I don't know x86 asm well enough to see what the *pmd value would
be there.

I'll try to reproduce and work out what's going on.

Thanks,
Nick


> [0.786675] Modules linked in:
> [0.786888] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
> 5.9.0-rc1-2-g8e63b8bbd7d17f #2
> [0.787402] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> 1.12.0-1 04/01/2014
> [0.787935] RIP: 0010:__apply_to_page_range+0x537/0x9c0
> [0.788280] Code: 8b 5c 24 50 48 39 5c 24 38 0f 84 6b 03 00 00 4c 8b 74 24 
> 38 e9 63 fb ff ff 84 d2 0f 84 ba 01 00 00 48 8b 1c 24 e9 3c fe ff ff <0f> 0b 
> 45 84 ed 0f 84 08 01 00 00 48 89 ef e8 8f 8f 02 00 48 89 e8
> [0.789467] RSP: :83e079d0 EFLAGS: 00010293
> [0.789805] RAX:  RBX: f5201000 RCX: 
> 000fffe0
> [0.790260] RDX:  RSI: 000ff000 RDI: 
> 
> [0.790724] RBP: 888107408000 R08: 0001 R09: 
> 000107408000
> [0.791179] R10: 840dcb5b R11: fbfff081b96b R12: 
> f520001f
> [0.791634] R13: 0001 R14: f520 R15: 
> dc00
> [0.792090] FS:  () GS:8881eae0() 
> knlGS:
> [0.792607] CS:  0010 DS:  ES:  CR0: 80050033
> [0.792977] CR2: 88823000 CR3: 03e14000 CR4: 
> 000406b0
> [0.793433] DR0:  DR1:  DR2: 
> 
> [0.793889] DR3:  DR6: fffe0ff0 DR7: 
> 0400
> [0.794344] Call Trace:
> [0.794517]  ? memset+0x40/0x40
> [0.794745]  alloc_vmap_area+0x7a9/0x2280
> [0.795054]  ? trace_hardirqs_on+0x4f/0x2e0
> [0.795354]  ? _raw_spin_unlock_irqrestore+0x39/0x60
> [0.795682]  ? free_vmap_area+0x1a20/0x1a20
> [0.795959]  ? __kasan_kmalloc+0xbf/0xe0
> [0.796292]  __get_vm_area_node+0xd1/0x300
> [0.796605]  get_vm_area_caller+0x2d/0x40
> [0.796872]  ? acpi_os_map_iomem+0x3c3/0x4e0
> [0.797155]  __ioremap_caller+0x1d8/0x480
> [0.797486]  ? acpi_os_map_iomem+0x3c3/0x4e0
> [0.797770]  ? iounmap+0x160/0x160
> [0.798002]  ? __kasan_kmalloc+0xbf/0xe0
> [0.798335]  acpi_os_map_iomem+0x3c3/0x4e0
> [0.798612]  acpi_tb_acquire_table+0xb3/0x1c5
> [0.798910]  acpi_tb_validate_table+0x68/0xbf
> [0.799199]  acpi_tb_verify_temp_table+0xa1/0x640
> [0.799512]  ? __down_trylock_console_sem+0x7a/0xa0
> [0.799833]  ? acpi_tb_validate_temp_table+0x9d/0x9d
> [0.800159]  ? acpi_ut_init_stack_ptr_trace+0xaa/0xaa
> [0.800490]  ? vprintk_emit+0x10b/0x2a0
> [0.800748]  ? acpi_ut_acquire_mutex+0x1d7/0x32f
> [0.801056]  acpi_reallocate_root_table+0x339/0x385
> [0.801377]  ? acpi_tb_parse_root_table+0x5a5/0x5a5
> [0.801700]  ? dmi_matches+0xc6/0x120
> [0.801968]  acpi_early_init+0x116/0x3ae
> [0.802230]  start_kernel+0x2f7/0x39f
> [0.802477]  secondary_startup_64+0xa4/0xb0
> [0.802770] irq event stamp: 5137
> [0.802992] hardirqs last  enabled at (5145): [] 
> console_unlock+0x632/0xa00
> [0.803539] hardirqs last disabled at (5152): [] 
> console_unlock+0xe0/0xa00
> [0.804082] softirqs last  enabled at (4430): [] 
> irq_read_recursion_soft_321+0xcf/0x160
> [0.804694] softirqs last disabled at (4428): [] 
> irq_read_recursion_soft_321+0xcf/0x160
> [0.805311] ---[ end trace