[linux-next:master] BUILD REGRESSION 274d7803837da78dfc911bcda0d593412676fc20

2022-09-30 Thread kernel test robot
tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 274d7803837da78dfc911bcda0d593412676fc20  Add linux-next specific 
files for 20220930

Error/Warning reports:

https://lore.kernel.org/linux-mm/202209150141.wgbakqmx-...@intel.com
https://lore.kernel.org/linux-mm/202210010718.2kavangb-...@intel.com
https://lore.kernel.org/llvm/202209220019.yr2vuxhg-...@intel.com

Error/Warning: (recently discovered and may have been fixed)

ERROR: modpost: "devm_ioremap_resource" [drivers/dma/fsl-edma.ko] undefined!
ERROR: modpost: "devm_ioremap_resource" [drivers/dma/idma64.ko] undefined!
ERROR: modpost: "devm_ioremap_resource" [drivers/dma/qcom/hdma.ko] undefined!
ERROR: modpost: "devm_memremap" [drivers/misc/open-dice.ko] undefined!
ERROR: modpost: "devm_memunmap" [drivers/misc/open-dice.ko] undefined!
ERROR: modpost: "devm_platform_ioremap_resource" 
[drivers/char/xillybus/xillybus_of.ko] undefined!
ERROR: modpost: "devm_platform_ioremap_resource" 
[drivers/clk/xilinx/clk-xlnx-clock-wizard.ko] undefined!
ERROR: modpost: "ioremap" [drivers/tty/ipwireless/ipwireless.ko] undefined!
ERROR: modpost: "iounmap" [drivers/net/ethernet/8390/pcnet_cs.ko] undefined!
ERROR: modpost: "iounmap" [drivers/tty/ipwireless/ipwireless.ko] undefined!
arch/arm64/kernel/alternative.c:199:6: warning: no previous prototype for 
'apply_alternatives_vdso' [-Wmissing-prototypes]
arch/arm64/kernel/alternative.c:295:14: warning: no previous prototype for 
'alt_cb_patch_nops' [-Wmissing-prototypes]
depmod: ERROR: Cycle detected: nf_conntrack -> nf_nat -> nf_conntrack
depmod: ERROR: Found 2 modules in dependency cycles!
drivers/nvme/target/loop.c:623 nvme_loop_create_ctrl() warn: 'opts->queue_size 
- 1' 18446744073709551615 can't fit into 65535 'ctrl->ctrl.sqsize'
drivers/tty/serial/atmel_serial.c:2127: undefined reference to 
`__clk_is_enabled'
pahole: .tmp_vmlinux.btf: No such file or directory

Error/Warning ids grouped by kconfigs:

gcc_recent_errors
|-- arm64-allyesconfig
|   |-- 
arch-arm64-kernel-alternative.c:warning:no-previous-prototype-for-alt_cb_patch_nops
|   `-- 
arch-arm64-kernel-alternative.c:warning:no-previous-prototype-for-apply_alternatives_vdso
|-- arm64-randconfig-r003-20220928
|   |-- 
arch-arm64-kernel-alternative.c:warning:no-previous-prototype-for-alt_cb_patch_nops
|   `-- 
arch-arm64-kernel-alternative.c:warning:no-previous-prototype-for-apply_alternatives_vdso
|-- arm64-randconfig-r035-20220926
|   |-- 
arch-arm64-kernel-alternative.c:warning:no-previous-prototype-for-alt_cb_patch_nops
|   `-- 
arch-arm64-kernel-alternative.c:warning:no-previous-prototype-for-apply_alternatives_vdso
|-- parisc-randconfig-m031-20220925
|   `-- 
drivers-nvme-target-loop.c-nvme_loop_create_ctrl()-warn:opts-queue_size-can-t-fit-into-ctrl-ctrl.sqsize
|-- parisc-randconfig-r002-20220925
|   |-- 
drivers-tty-serial-atmel_serial.c:undefined-reference-to-__clk_is_enabled
|   `-- pahole:.tmp_vmlinux.btf:No-such-file-or-directory
|-- s390-allmodconfig
|   |-- ERROR:devm_ioremap_resource-drivers-dma-fsl-edma.ko-undefined
|   |-- ERROR:devm_ioremap_resource-drivers-dma-idma64.ko-undefined
|   |-- ERROR:devm_ioremap_resource-drivers-dma-qcom-hdma.ko-undefined
|   |-- ERROR:devm_memremap-drivers-misc-open-dice.ko-undefined
|   |-- ERROR:devm_memunmap-drivers-misc-open-dice.ko-undefined
|   |-- 
ERROR:devm_platform_ioremap_resource-drivers-char-xillybus-xillybus_of.ko-undefined
|   |-- 
ERROR:devm_platform_ioremap_resource-drivers-clk-xilinx-clk-xlnx-clock-wizard.ko-undefined
|   |-- ERROR:ioremap-drivers-tty-ipwireless-ipwireless.ko-undefined
|   |-- ERROR:iounmap-drivers-net-ethernet-pcnet_cs.ko-undefined
|   `-- ERROR:iounmap-drivers-tty-ipwireless-ipwireless.ko-undefined
`-- x86_64-rhel-8.3-kselftests
|-- depmod:ERROR:Cycle-detected:nf_conntrack-nf_nat-nf_conntrack
`-- depmod:ERROR:Found-modules-in-dependency-cycles
clang_recent_errors
|-- hexagon-randconfig-r041-20220925
|   `-- 
drivers-phy-mediatek-phy-mtk-tphy.c:warning:result-of-comparison-of-constant-with-expression-of-type-typeof-(_Generic((mask_)-char:(unsigned-char)-unsigned-char:(unsigned-char)-signed-char:(unsigned-c
|-- hexagon-randconfig-r041-20220926
|   |-- 
drivers-phy-mediatek-phy-mtk-hdmi-mt2701.c:warning:result-of-comparison-of-constant-with-expression-of-type-typeof-(_Generic((mask_)-char:(unsigned-char)-unsigned-char:(unsigned-char)-signed-char:(uns
|   |-- 
drivers-phy-mediatek-phy-mtk-hdmi-mt8173.c:warning:result-of-comparison-of-constant-with-expression-of-type-typeof-(_Generic((mask_)-char:(unsigned-char)-unsigned-char:(unsigned-char)-signed-char:(uns
|   `-- 
drivers-phy-mediatek-phy-mtk-tphy.c:warning:result-of-comparison-of-constant-with-expression-of-type-typeof-(_Generic((mask_)-char:(unsigned-char)-unsigned-char:(unsigned-char)-signed-char:(unsigned-c
|-- hexagon-randconfig-r045-20220926
|   |-- 
driver

[powerpc:topic/ppc-kvm] BUILD SUCCESS 1a5486b3c3517aa1f608a10003ade4da122cb175

2022-09-30 Thread kernel test robot
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
topic/ppc-kvm
branch HEAD: 1a5486b3c3517aa1f608a10003ade4da122cb175  KVM: PPC: Book3S HV P9: 
Restore stolen time logging in dtl

elapsed time: 724m

configs tested: 76
configs skipped: 111

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

gcc tested configs:
powerpc   allnoconfig
powerpc  allmodconfig
um   x86_64_defconfig
um i386_defconfig
csky  allnoconfig
alpha allnoconfig
arc   allnoconfig
riscv allnoconfig
i386 allyesconfig
i386defconfig
x86_64  rhel-8.3-func
x86_64rhel-8.3-kselftests
x86_64  defconfig
x86_64   allyesconfig
x86_64   rhel-8.3
x86_64   rhel-8.3-kvm
x86_64   rhel-8.3-syz
x86_64 rhel-8.3-kunit
arm   omap2plus_defconfig
powerpc ep8248e_defconfig
arm ezx_defconfig
powerpc   maple_defconfig
mips   bmips_be_defconfig
mips allyesconfig
sh   allmodconfig
i386 randconfig-a003-20220926
i386 randconfig-a001-20220926
i386 randconfig-a006-20220926
i386 randconfig-a004-20220926
i386 randconfig-a005-20220926
i386 randconfig-a002-20220926
x86_64   randconfig-a002-20220926
x86_64   randconfig-a001-20220926
x86_64   randconfig-a004-20220926
x86_64   randconfig-a006-20220926
x86_64   randconfig-a005-20220926
x86_64   randconfig-a003-20220926
powerpccell_defconfig
m68kdefconfig
arm  gemini_defconfig
s390defconfig
s390 allmodconfig
arc defconfig
alpha   defconfig
s390 allyesconfig
i386  randconfig-c001
m68k allyesconfig
m68k allmodconfig
arc  allyesconfig
alphaallyesconfig
arm64allyesconfig
arm defconfig
arm  allyesconfig
arm  pxa3xx_defconfig
sh  landisk_defconfig
nios2allyesconfig
shhp6xx_defconfig
powerpc  cm5200_defconfig
nios2   defconfig
parisc  defconfig
parisc64defconfig
parisc   allyesconfig

clang tested configs:
x86_64randconfig-a012
x86_64randconfig-a014
x86_64randconfig-a016
powerpc   microwatt_defconfig
mips  malta_kvm_defconfig
powerpc  mpc885_ads_defconfig
i386 randconfig-a011-20220926
i386 randconfig-a015-20220926
i386 randconfig-a014-20220926
i386 randconfig-a012-20220926
i386 randconfig-a013-20220926
i386 randconfig-a016-20220926
arm  moxart_defconfig
arm mv78xx0_defconfig

-- 
0-DAY CI Kernel Test Service
https://01.org/lkp


Re: [PATCH] powerpc/microwatt: Add litesd

2022-09-30 Thread Matt Johnston
On Thu, 2022-09-29 at 11:55 +0930, Joel Stanley wrote:
> This is the register layout of the litesd peripheral for the fusesoc
> based Microwatt SoC.

The register layout looks right, but the upstream litemmc driver also now
needs the property

clocks = <_clk>;

(and associated sys_clk node).

"non-removable" has a typo, though I'm not sure we want non-removable anyway?
Most devices have a SD or microSD socket, and eMMC needs other driver litemmc
changes.

Cheers,
Matt


> Signed-off-by: Joel Stanley 
> ---
>  arch/powerpc/boot/dts/microwatt.dts | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/powerpc/boot/dts/microwatt.dts 
> b/arch/powerpc/boot/dts/microwatt.dts
> index b69db1d275cd..0a2e82ca1c79 100644
> --- a/arch/powerpc/boot/dts/microwatt.dts
> +++ b/arch/powerpc/boot/dts/microwatt.dts
> @@ -141,6 +141,21 @@ ethernet@802 {
>   litex,slot-size = <0x800>;
>   interrupts = <0x11 0x1>;
>   };
> +
> + mmc@804 {
> + compatible = "litex,mmc";
> + reg = <0x8042800 0x800
> + 0x8041000 0x800
> + 0x8040800 0x800
> + 0x8042000 0x800
> + 0x8041800 0x800>;
> + reg-names = "phy", "core", "reader", "writer", "irq";
> + bus-width = <4>;
> + interrupts = <0x13 1>;
> + cap-sd-highspeed;
> + non-removeable;
> + status = "disabled";
> + };
>   };
>  
>   chosen {



[PATCH net-next v6 9/9] arm64: dts: layerscape: Add nodes for QSGMII PCSs

2022-09-30 Thread Sean Anderson
Now that we actually read registers from QSGMII PCSs, it's important
that we have the correct address (instead of hoping that we're the MAC
with all the QSGMII PCSs on its bus). This adds nodes for the QSGMII
PCSs.  The exact mapping of QSGMII to MACs depends on the SoC.

Since the first QSGMII PCSs share an address with the SGMII and XFI
PCSs, we only add new nodes for PCSs 2-4. This avoids address conflicts
on the bus.

Signed-off-by: Sean Anderson 
---

(no changes since v3)

Changes in v3:
- Split this patch off from the previous one

Changes in v2:
- New

 .../boot/dts/freescale/fsl-ls1043-post.dtsi   | 24 ++
 .../boot/dts/freescale/fsl-ls1046-post.dtsi   | 25 +++
 2 files changed, 49 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043-post.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1043-post.dtsi
index d237162a8744..5c4d7eef8b61 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043-post.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043-post.dtsi
@@ -24,9 +24,12 @@  {
 
/* these aliases provide the FMan ports mapping */
enet0: ethernet@e {
+   pcs-handle-names = "qsgmii";
};
 
enet1: ethernet@e2000 {
+   pcsphy-handle = <>, <_pcs1>;
+   pcs-handle-names = "sgmii", "qsgmii";
};
 
enet2: ethernet@e4000 {
@@ -36,11 +39,32 @@ enet3: ethernet@e6000 {
};
 
enet4: ethernet@e8000 {
+   pcsphy-handle = <>, <_pcs2>;
+   pcs-handle-names = "sgmii", "qsgmii";
};
 
enet5: ethernet@ea000 {
+   pcsphy-handle = <>, <_pcs3>;
+   pcs-handle-names = "sgmii", "qsgmii";
};
 
enet6: ethernet@f {
};
+
+   mdio@e1000 {
+   qsgmiib_pcs1: ethernet-pcs@1 {
+   compatible = "fsl,lynx-pcs";
+   reg = <0x1>;
+   };
+
+   qsgmiib_pcs2: ethernet-pcs@2 {
+   compatible = "fsl,lynx-pcs";
+   reg = <0x2>;
+   };
+
+   qsgmiib_pcs3: ethernet-pcs@3 {
+   compatible = "fsl,lynx-pcs";
+   reg = <0x3>;
+   };
+   };
 };
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046-post.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1046-post.dtsi
index d6caaea57d90..4e3345093943 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046-post.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046-post.dtsi
@@ -23,6 +23,8 @@  {
  {
/* these aliases provide the FMan ports mapping */
enet0: ethernet@e {
+   pcsphy-handle = <_pcs3>;
+   pcs-handle-names = "qsgmii";
};
 
enet1: ethernet@e2000 {
@@ -35,14 +37,37 @@ enet3: ethernet@e6000 {
};
 
enet4: ethernet@e8000 {
+   pcsphy-handle = <>, <_pcs1>;
+   pcs-handle-names = "sgmii", "qsgmii";
};
 
enet5: ethernet@ea000 {
+   pcsphy-handle = <>, <>;
+   pcs-handle-names = "sgmii", "qsgmii";
};
 
enet6: ethernet@f {
};
 
enet7: ethernet@f2000 {
+   pcsphy-handle = <>, <_pcs2>, <>;
+   pcs-handle-names = "sgmii", "qsgmii", "xfi";
+   };
+
+   mdio@eb000 {
+   qsgmiib_pcs1: ethernet-pcs@1 {
+   compatible = "fsl,lynx-pcs";
+   reg = <0x1>;
+   };
+
+   qsgmiib_pcs2: ethernet-pcs@2 {
+   compatible = "fsl,lynx-pcs";
+   reg = <0x2>;
+   };
+
+   qsgmiib_pcs3: ethernet-pcs@3 {
+   compatible = "fsl,lynx-pcs";
+   reg = <0x3>;
+   };
};
 };
-- 
2.35.1.1320.gc452695387.dirty



[PATCH net-next v6 1/9] dt-bindings: net: Expand pcs-handle to an array

2022-09-30 Thread Sean Anderson
This allows multiple phandles to be specified for pcs-handle, such as
when multiple PCSs are present for a single MAC. To differentiate
between them, also add a pcs-handle-names property.

Signed-off-by: Sean Anderson 
---
This was previously submitted as [1]. I expect to update this series
more, so I have moved it here. Changes from that version include:
- Add maxItems to existing bindings
- Add a dependency from pcs-names to pcs-handle.

[1] 
https://lore.kernel.org/netdev/20220711160519.741990-3-sean.ander...@seco.com/

Changes in v6:
- Remove unnecessary $ref from renesas,rzn1-a5psw
- Remove unnecessary type from pcs-handle-names
- Add maxItems to pcs-handle

Changes in v4:
- Use pcs-handle-names instead of pcs-names, as discussed

Changes in v3:
- New

 .../bindings/net/dsa/renesas,rzn1-a5psw.yaml  |  2 +-
 .../devicetree/bindings/net/ethernet-controller.yaml  | 11 ++-
 .../devicetree/bindings/net/fsl,qoriq-mc-dpmac.yaml   |  2 +-
 3 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/dsa/renesas,rzn1-a5psw.yaml 
b/Documentation/devicetree/bindings/net/dsa/renesas,rzn1-a5psw.yaml
index 7ca9c19a157c..0a0d62b6c00e 100644
--- a/Documentation/devicetree/bindings/net/dsa/renesas,rzn1-a5psw.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/renesas,rzn1-a5psw.yaml
@@ -74,10 +74,10 @@ properties:
 
 properties:
   pcs-handle:
+maxItems: 1
 description:
   phandle pointing to a PCS sub-node compatible with
   renesas,rzn1-miic.yaml#
-$ref: /schemas/types.yaml#/definitions/phandle
 
 unevaluatedProperties: false
 
diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml 
b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
index 4b3c590fcebf..3aef506fa158 100644
--- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml
+++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
@@ -108,11 +108,17 @@ properties:
 $ref: "#/properties/phy-connection-type"
 
   pcs-handle:
-$ref: /schemas/types.yaml#/definitions/phandle
+$ref: /schemas/types.yaml#/definitions/phandle-array
+items:
+  maxItems: 1
 description:
   Specifies a reference to a node representing a PCS PHY device on a MDIO
   bus to link with an external PHY (phy-handle) if exists.
 
+  pcs-handle-names:
+description:
+  The name of each PCS in pcs-handle.
+
   phy-handle:
 $ref: /schemas/types.yaml#/definitions/phandle
 description:
@@ -216,6 +222,9 @@ properties:
 required:
   - speed
 
+dependencies:
+  pcs-handle-names: [pcs-handle]
+
 allOf:
   - if:
   properties:
diff --git a/Documentation/devicetree/bindings/net/fsl,qoriq-mc-dpmac.yaml 
b/Documentation/devicetree/bindings/net/fsl,qoriq-mc-dpmac.yaml
index 7f620a71a972..600240281e8c 100644
--- a/Documentation/devicetree/bindings/net/fsl,qoriq-mc-dpmac.yaml
+++ b/Documentation/devicetree/bindings/net/fsl,qoriq-mc-dpmac.yaml
@@ -31,7 +31,7 @@ properties:
   phy-mode: true
 
   pcs-handle:
-$ref: /schemas/types.yaml#/definitions/phandle
+maxItems: 1
 description:
   A reference to a node representing a PCS PHY device found on
   the internal MDIO bus.
-- 
2.35.1.1320.gc452695387.dirty



[PATCH net-next v6 8/9] powerpc: dts: qoriq: Add nodes for QSGMII PCSs

2022-09-30 Thread Sean Anderson
Now that we actually read registers from QSGMII PCSs, it's important
that we have the correct address (instead of hoping that we're the MAC
with all the QSGMII PCSs on its bus). This adds nodes for the QSGMII
PCSs. They have the same addresses on all SoCs (e.g. if QSGMIIA is
present it's used for MACs 1 through 4).

Since the first QSGMII PCSs share an address with the SGMII and XFI
PCSs, we only add new nodes for PCSs 2-4. This avoids address conflicts
on the bus.

Signed-off-by: Sean Anderson 
---

(no changes since v4)

Changes in v4:
- Add XFI PCS for t208x MAC1/MAC2

Changes in v3:
- Add compatibles for QSGMII PCSs
- Split arm and powerpcs dts updates

Changes in v2:
- New

 .../boot/dts/fsl/qoriq-fman3-0-10g-0-best-effort.dtsi  |  3 ++-
 arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0.dtsi | 10 +-
 .../boot/dts/fsl/qoriq-fman3-0-10g-1-best-effort.dtsi  | 10 +-
 arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-1.dtsi | 10 +-
 arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-2.dtsi |  3 ++-
 arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-3.dtsi |  3 ++-
 arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-0.dtsi  |  3 ++-
 arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-1.dtsi  | 10 +-
 arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-2.dtsi  | 10 +-
 arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-3.dtsi  | 10 +-
 arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-4.dtsi  |  3 ++-
 arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-5.dtsi  | 10 +-
 arch/powerpc/boot/dts/fsl/qoriq-fman3-1-10g-0.dtsi | 10 +-
 arch/powerpc/boot/dts/fsl/qoriq-fman3-1-10g-1.dtsi | 10 +-
 arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-0.dtsi  |  3 ++-
 arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-1.dtsi  | 10 +-
 arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-2.dtsi  | 10 +-
 arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-3.dtsi  | 10 +-
 arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-4.dtsi  |  3 ++-
 arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-5.dtsi  | 10 +-
 20 files changed, 131 insertions(+), 20 deletions(-)

diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0-best-effort.dtsi 
b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0-best-effort.dtsi
index baa0c503e741..7e70977f282a 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0-best-effort.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0-best-effort.dtsi
@@ -55,7 +55,8 @@ ethernet@e {
reg = <0xe 0x1000>;
fsl,fman-ports = <_rx_0x08 _tx_0x28>;
ptp-timer = <_timer0>;
-   pcsphy-handle = <>;
+   pcsphy-handle = <>, <>;
+   pcs-handle-names = "sgmii", "qsgmii";
};
 
mdio@e1000 {
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0.dtsi 
b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0.dtsi
index 93095600e808..5f89f7c1761f 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0.dtsi
@@ -52,7 +52,15 @@ ethernet@f {
compatible = "fsl,fman-memac";
reg = <0xf 0x1000>;
fsl,fman-ports = <_rx_0x10 _tx_0x30>;
-   pcsphy-handle = <>;
+   pcsphy-handle = <>, <_pcs2>, <>;
+   pcs-handle-names = "sgmii", "qsgmii", "xfi";
+   };
+
+   mdio@e9000 {
+   qsgmiib_pcs2: ethernet-pcs@2 {
+   compatible = "fsl,lynx-pcs";
+   reg = <2>;
+   };
};
 
mdio@f1000 {
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-1-best-effort.dtsi 
b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-1-best-effort.dtsi
index ff4bd38f0645..71eb75e82c2e 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-1-best-effort.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-1-best-effort.dtsi
@@ -55,7 +55,15 @@ ethernet@e2000 {
reg = <0xe2000 0x1000>;
fsl,fman-ports = <_rx_0x09 _tx_0x29>;
ptp-timer = <_timer0>;
-   pcsphy-handle = <>;
+   pcsphy-handle = <>, <_pcs1>;
+   pcs-handle-names = "sgmii", "qsgmii";
+   };
+
+   mdio@e1000 {
+   qsgmiia_pcs1: ethernet-pcs@1 {
+   compatible = "fsl,lynx-pcs";
+   reg = <1>;
+   };
};
 
mdio@e3000 {
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-1.dtsi 
b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-1.dtsi
index 1fa38ed6f59e..fb7032ddb7fc 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-1.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-1.dtsi
@@ -52,7 +52,15 @@ ethernet@f2000 {
compatible = "fsl,fman-memac";
reg = <0xf2000 0x1000>;
fsl,fman-ports = <_rx_0x11 _tx_0x31>;
-   pcsphy-handle = <>;
+   pcsphy-handle = <>, <_pcs3>, <>;
+   

[PATCH net-next v6 7/9] powerpc: dts: t208x: Mark MAC1 and MAC2 as 10G

2022-09-30 Thread Sean Anderson
On the T208X SoCs, MAC1 and MAC2 support XGMII. Add some new MAC dtsi
fragments, and mark the QMAN ports as 10G.

Fixes: da414bb923d9 ("powerpc/mpc85xx: Add FSL QorIQ DPAA FMan support to the 
SoC device tree(s)")
Signed-off-by: Sean Anderson 
---

(no changes since v4)

Changes in v4:
- New

 .../boot/dts/fsl/qoriq-fman3-0-10g-2.dtsi | 44 +++
 .../boot/dts/fsl/qoriq-fman3-0-10g-3.dtsi | 44 +++
 arch/powerpc/boot/dts/fsl/t2081si-post.dtsi   |  4 +-
 3 files changed, 90 insertions(+), 2 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-2.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-3.dtsi

diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-2.dtsi 
b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-2.dtsi
new file mode 100644
index ..437dab3fc017
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-2.dtsi
@@ -0,0 +1,44 @@
+// SPDX-License-Identifier: BSD-3-Clause OR GPL-2.0-or-later
+/*
+ * QorIQ FMan v3 10g port #2 device tree stub [ controller @ offset 0x40 ]
+ *
+ * Copyright 2022 Sean Anderson 
+ * Copyright 2012 - 2015 Freescale Semiconductor Inc.
+ */
+
+fman@40 {
+   fman0_rx_0x08: port@88000 {
+   cell-index = <0x8>;
+   compatible = "fsl,fman-v3-port-rx";
+   reg = <0x88000 0x1000>;
+   fsl,fman-10g-port;
+   };
+
+   fman0_tx_0x28: port@a8000 {
+   cell-index = <0x28>;
+   compatible = "fsl,fman-v3-port-tx";
+   reg = <0xa8000 0x1000>;
+   fsl,fman-10g-port;
+   };
+
+   ethernet@e {
+   cell-index = <0>;
+   compatible = "fsl,fman-memac";
+   reg = <0xe 0x1000>;
+   fsl,fman-ports = <_rx_0x08 _tx_0x28>;
+   ptp-timer = <_timer0>;
+   pcsphy-handle = <>;
+   };
+
+   mdio@e1000 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "fsl,fman-memac-mdio", "fsl,fman-xmdio";
+   reg = <0xe1000 0x1000>;
+   fsl,erratum-a011043; /* must ignore read errors */
+
+   pcsphy0: ethernet-phy@0 {
+   reg = <0x0>;
+   };
+   };
+};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-3.dtsi 
b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-3.dtsi
new file mode 100644
index ..ad116b17850a
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-3.dtsi
@@ -0,0 +1,44 @@
+// SPDX-License-Identifier: BSD-3-Clause OR GPL-2.0-or-later
+/*
+ * QorIQ FMan v3 10g port #3 device tree stub [ controller @ offset 0x40 ]
+ *
+ * Copyright 2022 Sean Anderson 
+ * Copyright 2012 - 2015 Freescale Semiconductor Inc.
+ */
+
+fman@40 {
+   fman0_rx_0x09: port@89000 {
+   cell-index = <0x9>;
+   compatible = "fsl,fman-v3-port-rx";
+   reg = <0x89000 0x1000>;
+   fsl,fman-10g-port;
+   };
+
+   fman0_tx_0x29: port@a9000 {
+   cell-index = <0x29>;
+   compatible = "fsl,fman-v3-port-tx";
+   reg = <0xa9000 0x1000>;
+   fsl,fman-10g-port;
+   };
+
+   ethernet@e2000 {
+   cell-index = <1>;
+   compatible = "fsl,fman-memac";
+   reg = <0xe2000 0x1000>;
+   fsl,fman-ports = <_rx_0x09 _tx_0x29>;
+   ptp-timer = <_timer0>;
+   pcsphy-handle = <>;
+   };
+
+   mdio@e3000 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "fsl,fman-memac-mdio", "fsl,fman-xmdio";
+   reg = <0xe3000 0x1000>;
+   fsl,erratum-a011043; /* must ignore read errors */
+
+   pcsphy1: ethernet-phy@0 {
+   reg = <0x0>;
+   };
+   };
+};
diff --git a/arch/powerpc/boot/dts/fsl/t2081si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/t2081si-post.dtsi
index ecbb447920bc..74e17e134387 100644
--- a/arch/powerpc/boot/dts/fsl/t2081si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t2081si-post.dtsi
@@ -609,8 +609,8 @@ usb1: usb@211000 {
 /include/ "qoriq-bman1.dtsi"
 
 /include/ "qoriq-fman3-0.dtsi"
-/include/ "qoriq-fman3-0-1g-0.dtsi"
-/include/ "qoriq-fman3-0-1g-1.dtsi"
+/include/ "qoriq-fman3-0-10g-2.dtsi"
+/include/ "qoriq-fman3-0-10g-3.dtsi"
 /include/ "qoriq-fman3-0-1g-2.dtsi"
 /include/ "qoriq-fman3-0-1g-3.dtsi"
 /include/ "qoriq-fman3-0-1g-4.dtsi"
-- 
2.35.1.1320.gc452695387.dirty



[PATCH net-next v6 6/9] net: dpaa: Convert to phylink

2022-09-30 Thread Sean Anderson
This converts DPAA to phylink. All macs are converted. This should work
with no device tree modifications (including those made in this series),
except for QSGMII (as noted previously).

The mEMAC configuration is one of the tricker areas. I have tried to
capture all the restrictions across the various models. Most of the time,
we assume that if the serdes supports a mode or the phy-interface-mode
specifies it, then we support it. The only place we can't do this is
(RG)MII, since there's no serdes. In that case, we rely on a (new)
devicetree property.  There are also several cases where half-duplex is
broken. Unfortunately, only a single compatible is used for the MAC, so we
have to use the board compatible instead.

The 10GEC conversion is very straightforward, since it only supports XAUI.
There is generally nothing to configure.

The dTSEC conversion is broadly similar to mEMAC, but is simpler because we
don't support configuring the SerDes (though this can be easily added) and
we don't have multiple PCSs. From what I can tell, there's nothing
different in the driver or documentation between SGMII and 1000BASE-X
except for the advertising. Similarly, I couldn't find anything about
2500BASE-X. In both cases, I treat them like SGMII. These modes aren't used
by any in-tree boards. Similarly, despite being mentioned in the driver, I
couldn't find any documented SoCs which supported QSGMII.  I have left it
unimplemented for now.

10GEC and dTSEC have not been tested at all. I would greatly appreciate if
someone could try them out.

Signed-off-by: Sean Anderson 
---
This has been tested on an LS1046ARDB.

With managed=phy, I was unable to get the interfaces to come up at all,
hence the default to in-band.

Changes in v6:
- Fix uninitialized variable in dtsec_mac_config

Changes in v3:
- Remove _return label from memac_initialization in favor of returning
  directly
- Fix grabbing the default PCS not checking for -ENODATA from
  of_property_match_string
- Set DTSEC_ECNTRL_R100M in dtsec_link_up instead of dtsec_mac_config
- Remove rmii/mii properties

Changes in v2:
- Remove unused variable slow_10g_if
- Restrict valid link modes based on the phy interface. This is easier
  to set up, and mostly captures what I intended to do the first time.
  We now have a custom validate which restricts half-duplex for some SoCs
  for RGMII, but generally just uses the default phylink validate.
- Configure the SerDes in enable/disable
- Properly implement all ethtool ops and ioctls. These were mostly
  stubbed out just enough to compile last time.
- Convert 10GEC and dTSEC as well

 drivers/net/ethernet/freescale/dpaa/Kconfig   |   4 +-
 .../net/ethernet/freescale/dpaa/dpaa_eth.c|  89 +--
 .../ethernet/freescale/dpaa/dpaa_ethtool.c|  90 +--
 drivers/net/ethernet/freescale/fman/Kconfig   |   1 -
 .../net/ethernet/freescale/fman/fman_dtsec.c  | 460 +++---
 .../net/ethernet/freescale/fman/fman_mac.h|  10 -
 .../net/ethernet/freescale/fman/fman_memac.c  | 578 +-
 .../net/ethernet/freescale/fman/fman_tgec.c   | 131 ++--
 drivers/net/ethernet/freescale/fman/mac.c | 168 +
 drivers/net/ethernet/freescale/fman/mac.h |  23 +-
 10 files changed, 630 insertions(+), 924 deletions(-)

diff --git a/drivers/net/ethernet/freescale/dpaa/Kconfig 
b/drivers/net/ethernet/freescale/dpaa/Kconfig
index 0e1439fd00bd..2b560661c82a 100644
--- a/drivers/net/ethernet/freescale/dpaa/Kconfig
+++ b/drivers/net/ethernet/freescale/dpaa/Kconfig
@@ -2,8 +2,8 @@
 menuconfig FSL_DPAA_ETH
tristate "DPAA Ethernet"
depends on FSL_DPAA && FSL_FMAN
-   select PHYLIB
-   select FIXED_PHY
+   select PHYLINK
+   select PCS_LYNX
help
  Data Path Acceleration Architecture Ethernet driver,
  supporting the Freescale QorIQ chips.
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c 
b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index 31cfa121333d..021ba999d86d 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -264,8 +264,19 @@ static int dpaa_netdev_init(struct net_device *net_dev,
net_dev->needed_headroom = priv->tx_headroom;
net_dev->watchdog_timeo = msecs_to_jiffies(tx_timeout);
 
-   mac_dev->net_dev = net_dev;
+   /* The rest of the config is filled in by the mac device already */
+   mac_dev->phylink_config.dev = _dev->dev;
+   mac_dev->phylink_config.type = PHYLINK_NETDEV;
mac_dev->update_speed = dpaa_eth_cgr_set_speed;
+   mac_dev->phylink = phylink_create(_dev->phylink_config,
+ dev_fwnode(mac_dev->dev),
+ mac_dev->phy_if,
+ mac_dev->phylink_ops);
+   if (IS_ERR(mac_dev->phylink)) {
+   err = PTR_ERR(mac_dev->phylink);
+   dev_err_probe(dev, err, "Could not create phylink\n");
+   return 

[PATCH net-next v6 5/9] net: fman: memac: Use lynx pcs driver

2022-09-30 Thread Sean Anderson
Although not stated in the datasheet, as far as I can tell PCS for mEMACs
is a "Lynx." By reusing the existing driver, we can remove the PCS
management code from the memac driver. This requires calling some PCS
functions manually which phylink would usually do for us, but we will let
it do that soon.

One problem is that we don't actually have a PCS for QSGMII. We pretend
that each mEMAC's MDIO bus has four QSGMII PCSs, but this is not the case.
Only the "base" mEMAC's MDIO bus has the four QSGMII PCSs. This is not an
issue yet, because we never get the PCS state. However, it will be once the
conversion to phylink is complete, since the links will appear to never
come up. To get around this, we allow specifying multiple PCSs in pcsphy.
This breaks backwards compatibility with old device trees, but only for
QSGMII. IMO this is the only reasonable way to figure out what the actual
QSGMII PCS is.

Additionally, we now also support a separate XFI PCS. This can allow the
SerDes driver to set different addresses for the SGMII and XFI PCSs so they
can be accessed at the same time.

Signed-off-by: Sean Anderson 
---

Changes in v6:
- Fix 81-character line

Changes in v3:
- Put the PCS mdiodev only after we are done with it (since the PCS
  does not perform a get itself).

Changes in v2:
- Move PCS_LYNX dependency to fman Kconfig

 drivers/net/ethernet/freescale/fman/Kconfig   |   3 +
 .../net/ethernet/freescale/fman/fman_memac.c  | 258 +++---
 2 files changed, 105 insertions(+), 156 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fman/Kconfig 
b/drivers/net/ethernet/freescale/fman/Kconfig
index 48bf8088795d..8f5637db41dd 100644
--- a/drivers/net/ethernet/freescale/fman/Kconfig
+++ b/drivers/net/ethernet/freescale/fman/Kconfig
@@ -4,6 +4,9 @@ config FSL_FMAN
depends on FSL_SOC || ARCH_LAYERSCAPE || COMPILE_TEST
select GENERIC_ALLOCATOR
select PHYLIB
+   select PHYLINK
+   select PCS
+   select PCS_LYNX
select CRC32
default n
help
diff --git a/drivers/net/ethernet/freescale/fman/fman_memac.c 
b/drivers/net/ethernet/freescale/fman/fman_memac.c
index 56a29f505590..eeb71352603b 100644
--- a/drivers/net/ethernet/freescale/fman/fman_memac.c
+++ b/drivers/net/ethernet/freescale/fman/fman_memac.c
@@ -11,43 +11,12 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 
-/* PCS registers */
-#define MDIO_SGMII_CR  0x00
-#define MDIO_SGMII_DEV_ABIL_SGMII  0x04
-#define MDIO_SGMII_LINK_TMR_L  0x12
-#define MDIO_SGMII_LINK_TMR_H  0x13
-#define MDIO_SGMII_IF_MODE 0x14
-
-/* SGMII Control defines */
-#define SGMII_CR_AN_EN 0x1000
-#define SGMII_CR_RESTART_AN0x0200
-#define SGMII_CR_FD0x0100
-#define SGMII_CR_SPEED_SEL1_1G 0x0040
-#define SGMII_CR_DEF_VAL   (SGMII_CR_AN_EN | SGMII_CR_FD | \
-SGMII_CR_SPEED_SEL1_1G)
-
-/* SGMII Device Ability for SGMII defines */
-#define MDIO_SGMII_DEV_ABIL_SGMII_MODE 0x4001
-#define MDIO_SGMII_DEV_ABIL_BASEX_MODE 0x01A0
-
-/* Link timer define */
-#define LINK_TMR_L 0xa120
-#define LINK_TMR_H 0x0007
-#define LINK_TMR_L_BASEX   0xaf08
-#define LINK_TMR_H_BASEX   0x002f
-
-/* SGMII IF Mode defines */
-#define IF_MODE_USE_SGMII_AN   0x0002
-#define IF_MODE_SGMII_EN   0x0001
-#define IF_MODE_SGMII_SPEED_100M   0x0004
-#define IF_MODE_SGMII_SPEED_1G 0x0008
-#define IF_MODE_SGMII_DUPLEX_HALF  0x0010
-
 /* Num of additional exact match MAC adr regs */
 #define MEMAC_NUM_OF_PADDRS 7
 
@@ -326,7 +295,9 @@ struct fman_mac {
struct fman_rev_info fm_rev_info;
bool basex_if;
struct phy *serdes;
-   struct phy_device *pcsphy;
+   struct phylink_pcs *sgmii_pcs;
+   struct phylink_pcs *qsgmii_pcs;
+   struct phylink_pcs *xfi_pcs;
bool allmulti_enabled;
 };
 
@@ -487,91 +458,22 @@ static u32 get_mac_addr_hash_code(u64 eth_addr)
return xor_val;
 }
 
-static void setup_sgmii_internal_phy(struct fman_mac *memac,
-struct fixed_phy_status *fixed_link)
+static void setup_sgmii_internal(struct fman_mac *memac,
+struct phylink_pcs *pcs,
+struct fixed_phy_status *fixed_link)
 {
-   u16 tmp_reg16;
-
-   if (WARN_ON(!memac->pcsphy))
-   return;
-
-   /* SGMII mode */
-   tmp_reg16 = IF_MODE_SGMII_EN;
-   if (!fixed_link)
-   /* AN enable */
-   tmp_reg16 |= IF_MODE_USE_SGMII_AN;
-   else {
-   switch (fixed_link->speed) {
-   case 10:
-   /* For 10M: IF_MODE[SPEED_10M] = 0 */
-   break;
-   case 100:
-   tmp_reg16 |= IF_MODE_SGMII_SPEED_100M;
-   break;

[PATCH net-next v6 4/9] net: fman: memac: Add serdes support

2022-09-30 Thread Sean Anderson
This adds support for using a serdes which has to be configured. This is
primarly in preparation for the next commit, which will then change the
serdes mode dynamically.

Signed-off-by: Sean Anderson 
---

(no changes since v4)

Changes in v4:
- Don't fail if phy support was not compiled in

 .../net/ethernet/freescale/fman/fman_memac.c  | 49 ++-
 1 file changed, 47 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fman/fman_memac.c 
b/drivers/net/ethernet/freescale/fman/fman_memac.c
index 32d26cf17843..56a29f505590 100644
--- a/drivers/net/ethernet/freescale/fman/fman_memac.c
+++ b/drivers/net/ethernet/freescale/fman/fman_memac.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /* PCS registers */
@@ -324,6 +325,7 @@ struct fman_mac {
void *fm;
struct fman_rev_info fm_rev_info;
bool basex_if;
+   struct phy *serdes;
struct phy_device *pcsphy;
bool allmulti_enabled;
 };
@@ -1203,17 +1205,56 @@ int memac_initialization(struct mac_device *mac_dev,
}
}
 
+   memac->serdes = devm_of_phy_get(mac_dev->dev, mac_node, "serdes");
+   err = PTR_ERR(memac->serdes);
+   if (err == -ENODEV || err == -ENOSYS) {
+   dev_dbg(mac_dev->dev, "could not get (optional) serdes\n");
+   memac->serdes = NULL;
+   } else if (IS_ERR(memac->serdes)) {
+   dev_err_probe(mac_dev->dev, err, "could not get serdes\n");
+   goto _return_fm_mac_free;
+   } else {
+   err = phy_init(memac->serdes);
+   if (err) {
+   dev_err_probe(mac_dev->dev, err,
+ "could not initialize serdes\n");
+   goto _return_fm_mac_free;
+   }
+
+   err = phy_power_on(memac->serdes);
+   if (err) {
+   dev_err_probe(mac_dev->dev, err,
+ "could not power on serdes\n");
+   goto _return_phy_exit;
+   }
+
+   if (memac->phy_if == PHY_INTERFACE_MODE_SGMII ||
+   memac->phy_if == PHY_INTERFACE_MODE_1000BASEX ||
+   memac->phy_if == PHY_INTERFACE_MODE_2500BASEX ||
+   memac->phy_if == PHY_INTERFACE_MODE_QSGMII ||
+   memac->phy_if == PHY_INTERFACE_MODE_XGMII) {
+   err = phy_set_mode_ext(memac->serdes, PHY_MODE_ETHERNET,
+  memac->phy_if);
+   if (err) {
+   dev_err_probe(mac_dev->dev, err,
+ "could not set serdes mode to 
%s\n",
+ phy_modes(memac->phy_if));
+   goto _return_phy_power_off;
+   }
+   }
+   }
+
if (!mac_dev->phy_node && of_phy_is_fixed_link(mac_node)) {
struct phy_device *phy;
 
err = of_phy_register_fixed_link(mac_node);
if (err)
-   goto _return_fm_mac_free;
+   goto _return_phy_power_off;
 
fixed_link = kzalloc(sizeof(*fixed_link), GFP_KERNEL);
if (!fixed_link) {
err = -ENOMEM;
-   goto _return_fm_mac_free;
+   goto _return_phy_power_off;
}
 
mac_dev->phy_node = of_node_get(mac_node);
@@ -1242,6 +1283,10 @@ int memac_initialization(struct mac_device *mac_dev,
 
goto _return;
 
+_return_phy_power_off:
+   phy_power_off(memac->serdes);
+_return_phy_exit:
+   phy_exit(memac->serdes);
 _return_fixed_link_free:
kfree(fixed_link);
 _return_fm_mac_free:
-- 
2.35.1.1320.gc452695387.dirty



[PATCH net-next v6 3/9] dt-bindings: net: fman: Add additional interface properties

2022-09-30 Thread Sean Anderson
At the moment, mEMACs are configured almost completely based on the
phy-connection-type. That is, if the phy interface is RGMII, it assumed
that RGMII is supported. For some interfaces, it is assumed that the
RCW/bootloader has set up the SerDes properly. This is generally OK, but
restricts runtime reconfiguration. The actual link state is never
reported.

To address these shortcomings, the driver will need additional
information. First, it needs to know how to access the PCS/PMAs (in
order to configure them and get the link status). The SGMII PCS/PMA is
the only currently-described PCS/PMA. Add the XFI and QSGMII PCS/PMAs as
well. The XFI (and 10GBASE-KR) PCS/PMA is a c45 "phy" which sits on the
same MDIO bus as SGMII PCS/PMA. By default they will have conflicting
addresses, but they are also not enabled at the same time by default.
Therefore, we can let the XFI PCS/PMA be the default when
phy-connection-type is xgmii. This will allow for
backwards-compatibility.

QSGMII, however, cannot work with the current binding. This is because
the QSGMII PCS/PMAs are only present on one MAC's MDIO bus. At the
moment this is worked around by having every MAC write to the PCS/PMA
addresses (without checking if they are present). This only works if
each MAC has the same configuration, and only if we don't need to know
the status. Because the QSGMII PCS/PMA will typically be located on a
different MDIO bus than the MAC's SGMII PCS/PMA, there is no fallback
for the QSGMII PCS/PMA.

Signed-off-by: Sean Anderson 
Reviewed-by: Rob Herring 
---

(no changes since v3)

Changes in v3:
- Add vendor prefix 'fsl,' to rgmii and mii properties.
- Set maxItems for pcs-names
- Remove phy-* properties from example because dt-schema complains and I
  can't be bothered to figure out how to make it work.
- Add pcs-handle as a preferred version of pcsphy-handle
- Deprecate pcsphy-handle
- Remove mii/rmii properties

Changes in v2:
- Better document how we select which PCS to use in the default case

 .../bindings/net/fsl,fman-dtsec.yaml  | 53 ++-
 .../devicetree/bindings/net/fsl-fman.txt  |  5 +-
 2 files changed, 43 insertions(+), 15 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/fsl,fman-dtsec.yaml 
b/Documentation/devicetree/bindings/net/fsl,fman-dtsec.yaml
index 3a35ac1c260d..c80c880a9dab 100644
--- a/Documentation/devicetree/bindings/net/fsl,fman-dtsec.yaml
+++ b/Documentation/devicetree/bindings/net/fsl,fman-dtsec.yaml
@@ -85,9 +85,39 @@ properties:
 $ref: /schemas/types.yaml#/definitions/phandle
 description: A reference to the IEEE1588 timer
 
+  phys:
+description: A reference to the SerDes lane(s)
+maxItems: 1
+
+  phy-names:
+items:
+  - const: serdes
+
   pcsphy-handle:
-$ref: /schemas/types.yaml#/definitions/phandle
-description: A reference to the PCS (typically found on the SerDes)
+$ref: /schemas/types.yaml#/definitions/phandle-array
+minItems: 1
+maxItems: 3
+deprecated: true
+description: See pcs-handle.
+
+  pcs-handle:
+minItems: 1
+maxItems: 3
+description: |
+  A reference to the various PCSs (typically found on the SerDes). If
+  pcs-handle-names is absent, and phy-connection-type is "xgmii", then the 
first
+  reference will be assumed to be for "xfi". Otherwise, if 
pcs-handle-names is
+  absent, then the first reference will be assumed to be for "sgmii".
+
+  pcs-handle-names:
+minItems: 1
+maxItems: 3
+items:
+  enum:
+- sgmii
+- qsgmii
+- xfi
+description: The type of each PCS in pcsphy-handle.
 
   tbi-handle:
 $ref: /schemas/types.yaml#/definitions/phandle
@@ -100,6 +130,10 @@ required:
   - fsl,fman-ports
   - ptp-timer
 
+dependencies:
+  pcs-handle-names:
+- pcs-handle
+
 allOf:
   - $ref: ethernet-controller.yaml#
   - if:
@@ -110,14 +144,6 @@ allOf:
 then:
   required:
 - tbi-handle
-  - if:
-  properties:
-compatible:
-  contains:
-const: fsl,fman-memac
-then:
-  required:
-- pcsphy-handle
 
 unevaluatedProperties: false
 
@@ -138,8 +164,9 @@ examples:
 reg = <0xe8000 0x1000>;
 fsl,fman-ports = <_rx_0x0c _tx_0x2c>;
 ptp-timer = <_timer0>;
-pcsphy-handle = <>;
-phy-handle = <_phy1>;
-phy-connection-type = "sgmii";
+pcs-handle = <>, <_pcs1>;
+pcs-handle-names = "sgmii", "qsgmii";
+phys = < 1>;
+phy-names = "serdes";
 };
 ...
diff --git a/Documentation/devicetree/bindings/net/fsl-fman.txt 
b/Documentation/devicetree/bindings/net/fsl-fman.txt
index b9055335db3b..bda4b41af074 100644
--- a/Documentation/devicetree/bindings/net/fsl-fman.txt
+++ b/Documentation/devicetree/bindings/net/fsl-fman.txt
@@ -320,8 +320,9 @@ For internal PHY device on internal mdio bus, a PHY node 
should be created.
 See the definition of the PHY node in 

[PATCH net-next v6 2/9] dt-bindings: net: Add Lynx PCS binding

2022-09-30 Thread Sean Anderson
This binding is fairly bare-bones for now, since the Lynx driver doesn't
parse any properties (or match based on the compatible). We just need it
in order to prevent the PCS nodes from having phy devices attached to
them. This is not really a problem, but it is a bit inefficient.

This binding is really for three separate PCSs (SGMII, QSGMII, and XFI).
However, the driver treats all of them the same. This works because the
SGMII and XFI devices typically use the same address, and the SerDes
driver (or RCW) muxes between them. The QSGMII PCSs have the same
register layout as the SGMII PCSs. To do things properly, we'd probably
do something like

ethernet-pcs@0 {
#pcs-cells = <1>;
compatible = "fsl,lynx-pcs";
reg = <0>, <1>, <2>, <3>;
};

but that would add complexity, and we can describe the hardware just
fine using separate PCSs for now.

Signed-off-by: Sean Anderson 
Reviewed-by: Rob Herring 
---

(no changes since v5)

Changes in v5:
- New

 .../bindings/net/pcs/fsl,lynx-pcs.yaml| 40 +++
 1 file changed, 40 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/pcs/fsl,lynx-pcs.yaml

diff --git a/Documentation/devicetree/bindings/net/pcs/fsl,lynx-pcs.yaml 
b/Documentation/devicetree/bindings/net/pcs/fsl,lynx-pcs.yaml
new file mode 100644
index ..fbedf696c555
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/pcs/fsl,lynx-pcs.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/pcs/fsl,lynx-pcs.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP Lynx PCS
+
+maintainers:
+  - Ioana Ciornei 
+
+description: |
+  NXP Lynx 10G and 28G SerDes have Ethernet PCS devices which can be used as
+  protocol controllers. They are accessible over the Ethernet interface's MDIO
+  bus.
+
+properties:
+  compatible:
+const: fsl,lynx-pcs
+
+  reg:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+mdio-bus {
+  #address-cells = <1>;
+  #size-cells = <0>;
+
+  qsgmii_pcs1: ethernet-pcs@1 {
+compatible = "fsl,lynx-pcs";
+reg = <1>;
+  };
+};
-- 
2.35.1.1320.gc452695387.dirty



[PATCH net-next v6 0/9] [RFT] net: dpaa: Convert to phylink

2022-09-30 Thread Sean Anderson
This series converts the DPAA driver to phylink.

I have tried to maintain backwards compatibility with existing device
trees whereever possible. However, one area where I was unable to
achieve this was with QSGMII. Please refer to patch 2 for details.

All mac drivers have now been converted. I would greatly appreciate if
anyone has T-series or P-series boards they can test/debug this series
on. I only have an LS1046ARDB. Everything but QSGMII should work without
breakage; QSGMII needs patches 7 and 8. For this reason, the last 4
patches in this series should be applied together (and should not go
through separate trees).

Changes in v6:
- Remove unnecessary $ref from renesas,rzn1-a5psw
- Remove unnecessary type from pcs-handle-names
- Add maxItems to pcs-handle
- Fix 81-character line
- Fix uninitialized variable in dtsec_mac_config

Changes in v5:
- Add Lynx PCS binding

Changes in v4:
- Use pcs-handle-names instead of pcs-names, as discussed
- Don't fail if phy support was not compiled in
- Split off rate adaptation series
- Split off DPAA "preparation" series
- Split off Lynx 10G support
- t208x: Mark MAC1 and MAC2 as 10G
- Add XFI PCS for t208x MAC1/MAC2

Changes in v3:
- Expand pcs-handle to an array
- Add vendor prefix 'fsl,' to rgmii and mii properties.
- Set maxItems for pcs-names
- Remove phy-* properties from example because dt-schema complains and I
  can't be bothered to figure out how to make it work.
- Add pcs-handle as a preferred version of pcsphy-handle
- Deprecate pcsphy-handle
- Remove mii/rmii properties
- Put the PCS mdiodev only after we are done with it (since the PCS
  does not perform a get itself).
- Remove _return label from memac_initialization in favor of returning
  directly
- Fix grabbing the default PCS not checking for -ENODATA from
  of_property_match_string
- Set DTSEC_ECNTRL_R100M in dtsec_link_up instead of dtsec_mac_config
- Remove rmii/mii properties
- Replace 1000Base... with 1000BASE... to match IEEE capitalization
- Add compatibles for QSGMII PCSs
- Split arm and powerpcs dts updates

Changes in v2:
- Better document how we select which PCS to use in the default case
- Move PCS_LYNX dependency to fman Kconfig
- Remove unused variable slow_10g_if
- Restrict valid link modes based on the phy interface. This is easier
  to set up, and mostly captures what I intended to do the first time.
  We now have a custom validate which restricts half-duplex for some SoCs
  for RGMII, but generally just uses the default phylink validate.
- Configure the SerDes in enable/disable
- Properly implement all ethtool ops and ioctls. These were mostly
  stubbed out just enough to compile last time.
- Convert 10GEC and dTSEC as well
- Fix capitalization of mEMAC in commit messages
- Add nodes for QSGMII PCSs
- Add nodes for QSGMII PCSs

Sean Anderson (9):
  dt-bindings: net: Expand pcs-handle to an array
  dt-bindings: net: Add Lynx PCS binding
  dt-bindings: net: fman: Add additional interface properties
  net: fman: memac: Add serdes support
  net: fman: memac: Use lynx pcs driver
  net: dpaa: Convert to phylink
  powerpc: dts: t208x: Mark MAC1 and MAC2 as 10G
  powerpc: dts: qoriq: Add nodes for QSGMII PCSs
  arm64: dts: layerscape: Add nodes for QSGMII PCSs

 .../bindings/net/dsa/renesas,rzn1-a5psw.yaml  |   2 +-
 .../bindings/net/ethernet-controller.yaml |  11 +-
 .../bindings/net/fsl,fman-dtsec.yaml  |  53 +-
 .../bindings/net/fsl,qoriq-mc-dpmac.yaml  |   2 +-
 .../devicetree/bindings/net/fsl-fman.txt  |   5 +-
 .../bindings/net/pcs/fsl,lynx-pcs.yaml|  40 +
 .../boot/dts/freescale/fsl-ls1043-post.dtsi   |  24 +
 .../boot/dts/freescale/fsl-ls1046-post.dtsi   |  25 +
 .../fsl/qoriq-fman3-0-10g-0-best-effort.dtsi  |   3 +-
 .../boot/dts/fsl/qoriq-fman3-0-10g-0.dtsi |  10 +-
 .../fsl/qoriq-fman3-0-10g-1-best-effort.dtsi  |  10 +-
 .../boot/dts/fsl/qoriq-fman3-0-10g-1.dtsi |  10 +-
 .../boot/dts/fsl/qoriq-fman3-0-10g-2.dtsi |  45 ++
 .../boot/dts/fsl/qoriq-fman3-0-10g-3.dtsi |  45 ++
 .../boot/dts/fsl/qoriq-fman3-0-1g-0.dtsi  |   3 +-
 .../boot/dts/fsl/qoriq-fman3-0-1g-1.dtsi  |  10 +-
 .../boot/dts/fsl/qoriq-fman3-0-1g-2.dtsi  |  10 +-
 .../boot/dts/fsl/qoriq-fman3-0-1g-3.dtsi  |  10 +-
 .../boot/dts/fsl/qoriq-fman3-0-1g-4.dtsi  |   3 +-
 .../boot/dts/fsl/qoriq-fman3-0-1g-5.dtsi  |  10 +-
 .../boot/dts/fsl/qoriq-fman3-1-10g-0.dtsi |  10 +-
 .../boot/dts/fsl/qoriq-fman3-1-10g-1.dtsi |  10 +-
 .../boot/dts/fsl/qoriq-fman3-1-1g-0.dtsi  |   3 +-
 .../boot/dts/fsl/qoriq-fman3-1-1g-1.dtsi  |  10 +-
 .../boot/dts/fsl/qoriq-fman3-1-1g-2.dtsi  |  10 +-
 .../boot/dts/fsl/qoriq-fman3-1-1g-3.dtsi  |  10 +-
 .../boot/dts/fsl/qoriq-fman3-1-1g-4.dtsi  |   3 +-
 .../boot/dts/fsl/qoriq-fman3-1-1g-5.dtsi  |  10 +-
 arch/powerpc/boot/dts/fsl/t2081si-post.dtsi   |   4 +-
 drivers/net/ethernet/freescale/dpaa/Kconfig   |   4 +-
 .../net/ethernet/freescale/dpaa/dpaa_eth.c|  89 +--
 

Re: [Bug report] BUG: Kernel NULL pointer dereference at 0x00000069, filemap_release_folio+0x88/0xb0

2022-09-30 Thread Matthew Wilcox
On Fri, Sep 30, 2022 at 12:01:26PM +1000, Michael Ellerman wrote:
> Matthew Wilcox  writes:
> >> [ 4681.238745] Instruction dump: 
> >> [ 4681.238749] fbc1fff0 f821ffc1 7c7d1b78 7c9c2378 ebc30028 7fdff378 
> >> 4818 6000  
> >> [ 4681.238765] 6000 ebff0008 7c3ef840 41820048 <815f0060> e93f 
> >> 5529077c 7d295378  
> >
> > Running that through scripts/decodecode (with some minor hacks .. how
> > do PPC people do this properly?)
> 
> We've just always used our own scripts. Mine is here: 
> https://github.com/mpe/misc-scripts/blob/master/ppc/ppc-disasm
> 
> I've added an issue to our tracker for us to get scripts/decodecode
> working on our oopses (eventually).

Would you be open to changing your oops printer to do
s/Instruction dump/Code/ ?  That would make it work without any other
changes.

$ CROSS_COMPILE=powerpc-linux-gnu- ./scripts/decodecode
Code:
fbc1fff0 f821ffc1 7c7d1b78 7c9c2378 ebc30028 7fdff378 4818 6000
6000 ebff0008 7c3ef840 41820048 <815f0060> e93f 5529077c 7d295378
^D

gives the right answer.  You could also do like x86 and put Code: on
the same line as the first set of hex (not that it matters; the parser
is fairly flexible).  This would also work ...

diff --git a/scripts/decodecode b/scripts/decodecode
index c711a196511c..0cadf1a37cbf 100755
--- a/scripts/decodecode
+++ b/scripts/decodecode
@@ -27,8 +27,8 @@ cont=
 while read i ; do
 
 case "$i" in
-*Code:*)
-   code=$i
+*Code:* | *'Instruction dump':*)
+   code=${i##*:}
cont=yes
;;
 *)
@@ -51,7 +51,7 @@ if [ -z "$code" ]; then
 fi
 
 echo $code
-code=`echo $code | sed -e 's/.*Code: //'`
+code=`echo $code`
 
 width=`expr index "$code" ' '`
 width=$((($width-1)/2))

(no, i don't know why i need that echo $code line; trimming trailing
spaces, maybe? shell is a terrible language)

> $ ./scripts/faddr2line .build/vmlinux drop_buffers.constprop.0+0x4c
> drop_buffers.constprop.0+0x4c/0x170:
> arch_atomic_read at arch/powerpc/include/asm/atomic.h:30
> (inlined by) atomic_read at include/linux/atomic/atomic-instrumented.h:28
> (inlined by) buffer_busy at fs/buffer.c:2859
> (inlined by) drop_buffers at fs/buffer.c:2871
> 
> static inline int buffer_busy(struct buffer_head *bh)
> {
>   return atomic_read(>b_count) |
>   (bh->b_state & ((1 << BH_Dirty) | (1 << BH_Lock)));
> }
> 
> struct folio {
> union {
> struct {
> long unsigned int flags; /* 0 8 */
> union {
> struct list_head lru;/* 816 */
> struct {
> void * __filler; /* 8 8 */
> unsigned int mlock_count; /*16
>  4 */
> };   /* 816 */
> };   /* 816 */
> struct address_space * mapping;  /*24 8 */
> long unsigned int index; /*32 8 */
> void * private;  /*40 8 */
>   <
> 
> struct buffer_head {
> long unsigned int  b_state;  /* 0 8 */
> struct buffer_head *   b_this_page;  /* 8 8 */
> struct page *  b_page;   /*16 8 */
> sector_t   b_blocknr;/*24 8 */
> size_t b_size;   /*32 8 */
> char * b_data;   /*40 8 */
> struct block_device *  b_bdev;   /*48 8 */
> bh_end_io_t *  b_end_io; /*56 8 */
> void * b_private;/*64 8 */
> struct list_head   b_assoc_buffers;  /*7216 */
> struct address_space * b_assoc_map;  /*88 8 */
> atomic_t   b_count;  /*96 4 */
>   <
> 
> The buffer_head comes from folio_buffers(folio):
> 
> static bool
> drop_buffers(struct folio *folio, struct buffer_head **buffers_to_free)
> {
>   struct buffer_head *head = folio_buffers(folio);
> 
> Which is == folio_get_private()
> 
> r3 and r29 still hold folio = c00c0042f1c0 
> 
> That's a valid looking vmemmap address.
> 
> So we have a valid folio, but its private field == 9 ?
> 
> Seems like all sorts of things get stuffed into page->private, so
> presumably 9 is not necessarily a corrupt value, just not what we're
> expecting. But I'm out of my depth so over to you :)

Yes, all kinds of things do get stuffed into folio->private, alas.
However, for an ext4 folio, it should either be NULL or a pointer to
a buffer_head.  It'd be interesting to insert ...

if ((long)head < 4096) 

Re: [PATCH net-next v5 2/9] dt-bindings: net: Add Lynx PCS binding

2022-09-30 Thread Rob Herring
On Mon, 26 Sep 2022 15:03:14 -0400, Sean Anderson wrote:
> This binding is fairly bare-bones for now, since the Lynx driver doesn't
> parse any properties (or match based on the compatible). We just need it
> in order to prevent the PCS nodes from having phy devices attached to
> them. This is not really a problem, but it is a bit inefficient.
> 
> This binding is really for three separate PCSs (SGMII, QSGMII, and XFI).
> However, the driver treats all of them the same. This works because the
> SGMII and XFI devices typically use the same address, and the SerDes
> driver (or RCW) muxes between them. The QSGMII PCSs have the same
> register layout as the SGMII PCSs. To do things properly, we'd probably
> do something like
> 
>   ethernet-pcs@0 {
>   #pcs-cells = <1>;
>   compatible = "fsl,lynx-pcs";
>   reg = <0>, <1>, <2>, <3>;
>   };
> 
> but that would add complexity, and we can describe the hardware just
> fine using separate PCSs for now.
> 
> Signed-off-by: Sean Anderson 
> ---
> 
> Changes in v5:
> - New
> 
>  .../bindings/net/pcs/fsl,lynx-pcs.yaml| 40 +++
>  1 file changed, 40 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/net/pcs/fsl,lynx-pcs.yaml
> 

Reviewed-by: Rob Herring 


Re: [PATCH v6 13/25] powerpc: Remove direct call to mmap2 syscall handlers

2022-09-30 Thread Arnd Bergmann
On Fri, Sep 30, 2022, at 3:19 PM, Michael Ellerman wrote:
> "Arnd Bergmann"  writes:
>>
>> While sys_mmap_pgoff() was meant to replace the various sys_mmap2()
>> implementations, I think it was ultimately a mistake, and we later
>> converged on the sys_mmap2() calling conventions with 12 bits
>> offset for almost all 32-bit architectures.
>
> I only see 3 compat mmap2s:
>
>   $ gg "COMPAT_SYSCALL.*mmap2"
>   arch/arm64/kernel/sys32.c:COMPAT_SYSCALL_DEFINE6(aarch32_mmap2, 
> unsigned long, addr, unsigned long, len,
>   arch/powerpc/kernel/syscalls.c:COMPAT_SYSCALL_DEFINE6(mmap2, unsigned 
> long, addr, size_t, len,
>   arch/s390/kernel/compat_linux.c:COMPAT_SYSCALL_DEFINE1(s390_mmap2, 
> struct mmap_arg_struct_emu31 __user *, arg)

They are all inconsistently named, and some are shared with the 64-bit
implementation on architectures that provide mmap2 for both 32-bit
and 64-bit mode, rather than only for 32-bit.

arch/mips/kernel/syscall.c:SYSCALL_DEFINE6(mips_mmap2, unsigned long, addr, 
unsigned long, len,
arch/sparc/kernel/sys32.S:  .globl  sys32_mmap2
arch/parisc/kernel/sys_parisc.c:asmlinkage unsigned long sys_mmap2(unsigned 
long addr, unsigned long len,

> s390 is weird.

Right, they used to be limited to 5 register arguments

> The arm64 one and ours are similar, but we have the additional call to
> arch_validate_prot(prot, addr). arm64 does implement arch_validate_prot().
>
> Similar with mmap2, we call arch_validate_prot() but no one else does 
> (why not?).

This looks like it was added in ef3d3246a0d0 ("powerpc/mm: Add Strong
Access Ordering support"), which is powerpc specific. It looks like
this should correspond to a custom arch_calc_vm_prot_bits()
implementation, which exists on arm64, powerpc, sparc and x86.

I suppose it should be there for those four.

Arnd


Re: [PATCH v6 13/25] powerpc: Remove direct call to mmap2 syscall handlers

2022-09-30 Thread Michael Ellerman
"Arnd Bergmann"  writes:
> On Wed, Sep 28, 2022, at 2:15 PM, Michael Ellerman wrote:
>
>> But I think it makes more sense to do the same as mmap2() and pass the
>> 4K offset through, and pass shift = PAGE_SHIFT - 12. I also borrowed the
>> "off_4k" name from arm64. End result:
>>
>> #ifdef CONFIG_COMPAT
>> COMPAT_SYSCALL_DEFINE6(mmap2,
>> unsigned long, addr, size_t, len,
>> unsigned long, prot, unsigned long, flags,
>> unsigned long, fd, unsigned long, off_4k)
>> {
>>  return do_mmap2(addr, len, prot, flags, fd, off_4k, PAGE_SHIFT-12);
>> }
>> #endif
>>
>> With that my G5 boots again :)
>
> Any chance we can instead add a working compat_sys_mmap2/sys_mmap2
> in mm/mmap.c alongside the sys_mmap_pgoff implementation?

I've merged this, but happy to clean things up in a subsequent patch :)

> While sys_mmap_pgoff() was meant to replace the various sys_mmap2()
> implementations, I think it was ultimately a mistake, and we later
> converged on the sys_mmap2() calling conventions with 12 bits
> offset for almost all 32-bit architectures.

I only see 3 compat mmap2s:

  $ gg "COMPAT_SYSCALL.*mmap2"
  arch/arm64/kernel/sys32.c:COMPAT_SYSCALL_DEFINE6(aarch32_mmap2, unsigned 
long, addr, unsigned long, len,
  arch/powerpc/kernel/syscalls.c:COMPAT_SYSCALL_DEFINE6(mmap2, unsigned long, 
addr, size_t, len,
  arch/s390/kernel/compat_linux.c:COMPAT_SYSCALL_DEFINE1(s390_mmap2, struct 
mmap_arg_struct_emu31 __user *, arg)

s390 is weird.

The arm64 one and ours are similar, but we have the additional call to
arch_validate_prot(prot, addr). arm64 does implement arch_validate_prot().

Similar with mmap2, we call arch_validate_prot() but no one else does (why 
not?).

cheers


Re: [PATCH] powerpc: update config files

2022-09-30 Thread Michael Ellerman
Lukas Bulwahn  writes:
> On Fri, Sep 30, 2022 at 9:42 AM Michael Ellerman  wrote:
>>
>> Lukas Bulwahn  writes:
>> > Clean up config files by:
>> >   - removing configs that were deleted in the past
>> >   - removing configs not in tree and without recently pending patches
>> >   - adding new configs that are replacements for old configs in the file
>> >
>> > For some detailed information, see Link.
>> >
>> > Link: 
>> > https://lore.kernel.org/kernel-janitors/20220929090645.1389-1-lukas.bulw...@gmail.com/
>>
>> Ideally I'd like a list in the change log of each symbol and why they're
>> being removed/changed. It's pretty easy to accidentally drop something
>> otherwise.
>>
>> I think this is the list in this case:
>>
>> Renamed:
>>   - CONFIG_PPC_PTDUMP -> CONFIG_GENERIC_PTDUMP
>> e084728393a5 ("powerpc/ptdump: Convert powerpc to GENERIC_PTDUMP")
...
>>
>> I'll fold that into the change log.
>
> Sure. Go ahead. I have provided all information I collected in the
> linked email (and this information drove my scripts to take actions)
> and I am happy to provide it in any form a maintainer may think is
> good for them. But I assume you did this with a simple script
> yourself.

I did it manually actually - just a bunch of "git log -G ".
A script would have been better :)

> After going through the changes of Kconfig from the last decade, it
> seems feasible that the information on Kconfig changes is actually
> maintained somewhere and that would allow updating of arbitrary kernel
> configs to newer kernel versions. It is not completely out of reach at
> least.
>
> And to really improve the situation, I would like to reduce all these
> defconfigs in the repository to minimal kernel fragments that really
> focus on what these config for specific machines intend to tell. E.g.,
> these configs below (powerpc-configs) are about ensuring specific
> hardware support, not about setting "CONFIG_CRYPTO_XYZ" one way or the
> other. That is actually just "noise".

Yes I agree. In most cases for a lot of options we just want whatever
the default is for that subsystem.

> I do not know how to do this right yet, but with a bit of
> experimentation and investigation, I might come with a first idea and
> then we will see.

IMHO the best solution we have at the moment is generating the configs
with merge_config.sh.

See for example the way our ppc_defconfig is generated:

PHONY += ppc_defconfig
ppc_defconfig:
$(call merge_into_defconfig,book3s_32.config,)

$ cat arch/powerpc/configs/book3s_32.config
CONFIG_PPC64=n
CONFIG_PPC_BOOK3S_32=y

Everything else just gets the default.

We have some more fully featured examples too, see
arch/powerpc/Makefile.

There's a few drawbacks of that technique though.

One is that those generated configs aren't shown in 'make help'.

And the other is that there's no way to run something like savedefconfig
on those .config files to minimise them.

You have to expand them out into a full .config, run savedefconfig on
that, and then manually grep through the .config to find any symbols
that are no longer needed. You also need to be careful that any symbol
that's no longer needed is no longer needed for all the generated
configs that use that .config file.

cheers


Re: [PATCH] powerpc: dts: turris1x.dts: Add channel labels for temperature sensor

2022-09-30 Thread Pali Rohár
+ CC hwmon ML

On Friday 30 September 2022 14:39:01 Pali Rohár wrote:
> Channel 0 of SA56004ED chip refers to internal SA56004ED chip sensor (chip
> itself is located on the board) and channel 1 of SA56004ED chip refers to
> external sensor which is connected to temperature diode of the P2020 CPU.
> 
> Fixes: 54c15ec3b738 ("powerpc: dts: Add DTS file for CZ.NIC Turris 1.x 
> routers")
> Signed-off-by: Pali Rohár 
> ---
> With this change userspace 'sensors' applications prints labels:
> 
> $ sensors
> sa56004-i2c-0-4c
> Adapter: MPC adapter (i2c@3000)
> board:+34.2°C  (low  =  +0.0°C, high = +70.0°C)
>(crit = +85.0°C, hyst = +75.0°C)
> cpu:  +58.9°C  (low  =  +0.0°C, high = +70.0°C)
>(crit = +85.0°C, hyst = +75.0°C)
> 
> And without this change it prints just generic tempX names:
> 
> $ sensors
> sa56004-i2c-0-4c
> Adapter: MPC adapter (i2c@3000)
> temp1:+43.0°C  (low  =  +0.0°C, high = +70.0°C)
>(crit = +85.0°C, hyst = +75.0°C)
> temp2:+63.4°C  (low  =  +0.0°C, high = +70.0°C)
>(crit = +85.0°C, hyst = +75.0°C)
> ---
>  arch/powerpc/boot/dts/turris1x.dts | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/arch/powerpc/boot/dts/turris1x.dts 
> b/arch/powerpc/boot/dts/turris1x.dts
> index 4033c554b06a..5b5278c32e43 100644
> --- a/arch/powerpc/boot/dts/turris1x.dts
> +++ b/arch/powerpc/boot/dts/turris1x.dts
> @@ -69,6 +69,20 @@
>   interrupt-parent = <>;
>   interrupts = <12 IRQ_TYPE_LEVEL_LOW>, /* GPIO12 
> - ALERT pin */
><13 IRQ_TYPE_LEVEL_LOW>; /* GPIO13 
> - CRIT pin */
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* Local temperature sensor (SA56004ED 
> internal) */
> + channel@0 {
> + reg = <0>;
> + label = "board";
> + };
> +
> + /* Remote temperature sensor (D+/D- connected 
> to P2020 CPU Temperature Diode) */
> + channel@1 {
> + reg = <1>;
> + label = "cpu";
> + };

I'm not sure if you want UPPERCASE, lowercase, PascalCase, kebab-case
or snake_case format of labels. Or if you want also "temp" or
"temperature" keyword in the label. So please adjust label to the
preferred one, if proposed format is not the correct.

>   };
>  
>   /* DDR3 SPD/EEPROM */
> -- 
> 2.20.1
> 


Re: [PATCH] powerpc: dts: turris1x.dts: Add channel labels for temperature sensor

2022-09-30 Thread Marek Behún
On Fri, 30 Sep 2022 14:39:01 +0200
Pali Rohár  wrote:

> Channel 0 of SA56004ED chip refers to internal SA56004ED chip sensor (chip
> itself is located on the board) and channel 1 of SA56004ED chip refers to
> external sensor which is connected to temperature diode of the P2020 CPU.
> 
> Fixes: 54c15ec3b738 ("powerpc: dts: Add DTS file for CZ.NIC Turris 1.x 
> routers")
> Signed-off-by: Pali Rohár 

Reviewed-by: Marek Behún 


[PATCH] powerpc: dts: turris1x.dts: Add channel labels for temperature sensor

2022-09-30 Thread Pali Rohár
Channel 0 of SA56004ED chip refers to internal SA56004ED chip sensor (chip
itself is located on the board) and channel 1 of SA56004ED chip refers to
external sensor which is connected to temperature diode of the P2020 CPU.

Fixes: 54c15ec3b738 ("powerpc: dts: Add DTS file for CZ.NIC Turris 1.x routers")
Signed-off-by: Pali Rohár 
---
With this change userspace 'sensors' applications prints labels:

$ sensors
sa56004-i2c-0-4c
Adapter: MPC adapter (i2c@3000)
board:+34.2°C  (low  =  +0.0°C, high = +70.0°C)
   (crit = +85.0°C, hyst = +75.0°C)
cpu:  +58.9°C  (low  =  +0.0°C, high = +70.0°C)
   (crit = +85.0°C, hyst = +75.0°C)

And without this change it prints just generic tempX names:

$ sensors
sa56004-i2c-0-4c
Adapter: MPC adapter (i2c@3000)
temp1:+43.0°C  (low  =  +0.0°C, high = +70.0°C)
   (crit = +85.0°C, hyst = +75.0°C)
temp2:+63.4°C  (low  =  +0.0°C, high = +70.0°C)
   (crit = +85.0°C, hyst = +75.0°C)
---
 arch/powerpc/boot/dts/turris1x.dts | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/powerpc/boot/dts/turris1x.dts 
b/arch/powerpc/boot/dts/turris1x.dts
index 4033c554b06a..5b5278c32e43 100644
--- a/arch/powerpc/boot/dts/turris1x.dts
+++ b/arch/powerpc/boot/dts/turris1x.dts
@@ -69,6 +69,20 @@
interrupt-parent = <>;
interrupts = <12 IRQ_TYPE_LEVEL_LOW>, /* GPIO12 
- ALERT pin */
 <13 IRQ_TYPE_LEVEL_LOW>; /* GPIO13 
- CRIT pin */
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   /* Local temperature sensor (SA56004ED 
internal) */
+   channel@0 {
+   reg = <0>;
+   label = "board";
+   };
+
+   /* Remote temperature sensor (D+/D- connected 
to P2020 CPU Temperature Diode) */
+   channel@1 {
+   reg = <1>;
+   label = "cpu";
+   };
};
 
/* DDR3 SPD/EEPROM */
-- 
2.20.1



Re: [PATCH] powerpc/kprobes: Fix null pointer reference in arch_prepare_kprobe()

2022-09-30 Thread Naveen N. Rao

Li Huafei wrote:

I found a null pointer reference in arch_prepare_kprobe():


Good find!



  # echo 'p cmdline_proc_show' > kprobe_events
  # echo 'p cmdline_proc_show+16' >> kprobe_events


I think we should extend multiple_kprobes selftest to also place 
contiguous probes to catch such errors.



  [   67.278533][  T122] Kernel attempted to read user page (0) - exploit 
attempt? (uid: 0)
  [   67.279326][  T122] BUG: Kernel NULL pointer dereference on read at 
0x
  [   67.279738][  T122] Faulting instruction address: 0xc0050bfc
  [   67.280486][  T122] Oops: Kernel access of bad area, sig: 11 [#1]
  [   67.280846][  T122] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA 
PowerNV
  [   67.281435][  T122] Modules linked in:
  [   67.281903][  T122] CPU: 0 PID: 122 Comm: sh Not tainted 
6.0.0-rc3-7-gdcf8e5633e2e #10
  [   67.282547][  T122] NIP:  c0050bfc LR: c0050bec CTR: 
5bdc
  [   67.282920][  T122] REGS: c000348475b0 TRAP: 0300   Not tainted  
(6.0.0-rc3-7-gdcf8e5633e2e)
  [   67.283424][  T122] MSR:  90009033   CR: 
88002444  XER: 20040006
  [   67.284023][  T122] CFAR: c022d100 DAR:  DSISR: 
4000 IRQMASK: 0
  [   67.284023][  T122] GPR00: c0050bec c00034847850 
c13f6100 c1fb7718
  [   67.284023][  T122] GPR04: c0515c10 c0e5fe08 
c133da60 c4839300
  [   67.284023][  T122] GPR08: c14ffb98  
c0515c0c c0e18576
  [   67.284023][  T122] GPR12: c0e60170 c15a 
0001155e0460 
  [   67.284023][  T122] GPR16:  7fffe8eeb3c8 
000116320728 
  [   67.284023][  T122] GPR20: 000116320720  
c12fa918 0006
  [   67.284023][  T122] GPR24: c14ffb98 c11ed360 
 c1fb7928
  [   67.284023][  T122] GPR28:   
7c0802a6 c1fb7918
  [   67.287799][  T122] NIP [c0050bfc] arch_prepare_kprobe+0x10c/0x2d0
  [   67.288490][  T122] LR [c0050bec] arch_prepare_kprobe+0xfc/0x2d0
  [   67.289025][  T122] Call Trace:
  [   67.289268][  T122] [c00034847850] [c12f77a0] 
0xc12f77a0 (unreliable)
  [   67.28][  T122] [c000348478d0] [c0231320] 
register_kprobe+0x3c0/0x7a0
  [   67.290439][  T122] [c00034847940] [c02938c0] 
__register_trace_kprobe+0x140/0x1a0
  [   67.290898][  T122] [c000348479b0] [c02944c4] 
__trace_kprobe_create+0x794/0x1040
  [   67.291330][  T122] [c00034847b60] [c02a1614] 
trace_probe_create+0xc4/0xe0
  [   67.291717][  T122] [c00034847bb0] [c029363c] 
create_or_delete_trace_kprobe+0x2c/0x80
  [   67.292158][  T122] [c00034847bd0] [c0264420] 
trace_parse_run_command+0xf0/0x210
  [   67.292611][  T122] [c00034847c70] [c02934a0] 
probes_write+0x20/0x40
  [   67.292996][  T122] [c00034847c90] [c045e98c] 
vfs_write+0xfc/0x450
  [   67.293356][  T122] [c00034847d50] [c045eec4] 
ksys_write+0x84/0x140
  [   67.293716][  T122] [c00034847da0] [c002e4fc] 
system_call_exception+0x17c/0x3a0
  [   67.294186][  T122] [c00034847e10] [c000c0e8] 
system_call_vectored_common+0xe8/0x278
  [   67.294680][  T122] --- interrupt: 3000 at 0x7fffa5682de0
  [   67.294937][  T122] NIP:  7fffa5682de0 LR:  CTR: 

  [   67.295313][  T122] REGS: c00034847e80 TRAP: 3000   Not tainted  
(6.0.0-rc3-7-gdcf8e5633e2e)
  [   67.295725][  T122] MSR:  9280f033 
  CR: 44002408  XER: 
  [   67.296291][  T122] IRQMASK: 0
  [   67.296291][  T122] GPR00: 0004 7fffe8eeaec0 
7fffa5757300 0001
  [   67.296291][  T122] GPR04: 000116329c60 0017 
00116329 
  [   67.296291][  T122] GPR08: 0006  
 
  [   67.296291][  T122] GPR12:  7fffa580ac60 
0001155e0460 
  [   67.296291][  T122] GPR16:  7fffe8eeb3c8 
000116320728 
  [   67.296291][  T122] GPR20: 000116320720  
 0002
  [   67.296291][  T122] GPR24: 0001163206f0 0020 
7fffe8eeafa0 0001
  [   67.296291][  T122] GPR28:  0017 
000116329c60 0001
  [   67.299570][  T122] NIP [7fffa5682de0] 0x7fffa5682de0
  [   67.299837][  T122] LR [] 0x0
  [   67.300072][  T122] --- interrupt: 3000
  [   67.300447][  T122] Instruction dump:
  [   67.300736][  T122] 386319d8 481342f5 6000 6000 6000 e87f0028 
3863fffc 481dc4d1
  [   67.301230][  T122] 6000 2c23 41820018 e9230058 <8129> 
552936be 2c090001 4182018c
  [   67.302102][  T122] ---[ end trace 

Re: [PATCH] scripts/faddr2line: Fix regression in name resolution on ppc64le

2022-09-30 Thread Naveen N. Rao

Thadeu Lima de Souza Cascardo wrote:

On Tue, Sep 27, 2022 at 01:22:11PM +0530, Srikar Dronamraju wrote:

Commit 1d1a0e7c5100 ("scripts/faddr2line: Fix overlapping text section 
failures")
can cause scripts/faddr2line to fail on ppc64le machines on few
distributions, while working on other distributions. The failure can be
attributed to difference in readelf output on various distributions.

$ ./scripts/faddr2line vmlinux find_busiest_group+0x00
no match for find_busiest_group+0x00

Expected output was:
$ ./scripts/faddr2line vmlinux find_busiest_group+0x00
find_busiest_group+0x00/0x3d0:
find_busiest_group at kernel/sched/fair.c:9595

On ppc64le, readelf adds localentry tag before the symbol name on few
distributions and adds the localentry tag after the symbol name on few
other distributions. This problem has been discussed in the reference
URL given below. This problem can be overcome by filtering out
localentry tags in readelf output. Similar fixes are already present in
kernel by way of commits:

1fd6cee127e2 ("libbpf: Fix VERSIONED_SYM_COUNT number parsing")
aa915931ac3e ("libbpf: Fix readelf output parsing for Fedora")

Fixes: 1d1a0e7c5100 ("scripts/faddr2line: Fix overlapping text section 
failures")
Reference: https://lore.kernel.org/bpf/20191211160133.GB4580@calabresa/
Cc: "Naveen N. Rao" 
Cc: Jiri Olsa 
Cc: Thadeu Lima de Souza Cascardo 


Reviewed-by: Thadeu Lima de Souza Cascardo 

The other instances of readelf --wide on faddr2line use --section-headers and
should not required the same mangling.


There's one usage of readelf with --file-header in faddr2line which also 
doesn't need this. The extra information being printed is from st_other 
and is very specific to the symbol table.


Acked-by: Naveen N. Rao 


- Naveen



Re: [PATCH] powerpc/pseries/vas: Pass hw_cpu_id to node associativity HCALL

2022-09-30 Thread Michael Ellerman
Michal Suchánek  writes:
> On Thu, Sep 29, 2022 at 05:16:40PM -0500, Nathan Lynch wrote:
>> Haren Myneni  writes:
>> > Generally the hypervisor decides to allocate a window on different
>> > VAS instances. But if the user space wishes to allocate on the
>> > current VAS instance where the process is executing, the kernel has
>> > to pass associativity domain IDs to allocate VAS window HCALL. To
>> > determine the associativity domain IDs for the current CPU, passing
>> > smp_processor_id() to node associativity HCALL which may return
>> > H_P2 (-55) error during DLPAR CPU event.
>> >
>> > This patch fixes this issue by passing hard_smp_processor_id() with
>> > VPHN_FLAG_VCPU flag (PAPR 14.11.6.1 H_HOME_NODE_ASSOCIATIVITY).
>> >
>> > Signed-off-by: Haren Myneni 
>> > ---
>> >  arch/powerpc/platforms/pseries/vas.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/arch/powerpc/platforms/pseries/vas.c 
>> > b/arch/powerpc/platforms/pseries/vas.c
>> > index fe33bdb620d5..533026fd1f40 100644
>> > --- a/arch/powerpc/platforms/pseries/vas.c
>> > +++ b/arch/powerpc/platforms/pseries/vas.c
>> > @@ -348,7 +348,7 @@ static struct vas_window *vas_allocate_window(int 
>> > vas_id, u64 flags,
>> > * So no unpacking needs to be done.
>> > */
>> >rc = plpar_hcall9(H_HOME_NODE_ASSOCIATIVITY, domain,
>> > -VPHN_FLAG_VCPU, smp_processor_id());
>> > +VPHN_FLAG_VCPU, hard_smp_processor_id());
>> >if (rc != H_SUCCESS) {
>> >pr_err("H_HOME_NODE_ASSOCIATIVITY error: %d\n", rc);
>> >goto out;
>> 
>> Yes, it is always wrong to pass Linux CPU numbers to the hypervisor,
>> which has its own numbering for hardware threads. It usually coincides
>> with Linux's numbering in practice, which tends to hide bugs like this.
>> 
>> Reviewed-by: Nathan Lynch 
>
> This is the code that introduces the problem, right?
>
> Fixes: b22f2d88e435 ("powerpc/pseries/vas: Integrate API with open/close 
> windows")

Yeah, I tagged it when applying. Thanks.

cheers


Re: [PATCH] powerpc/pseries/vas: Pass hw_cpu_id to node associativity HCALL

2022-09-30 Thread Michal Suchánek
Hello,

On Thu, Sep 29, 2022 at 05:16:40PM -0500, Nathan Lynch wrote:
> Haren Myneni  writes:
> > Generally the hypervisor decides to allocate a window on different
> > VAS instances. But if the user space wishes to allocate on the
> > current VAS instance where the process is executing, the kernel has
> > to pass associativity domain IDs to allocate VAS window HCALL. To
> > determine the associativity domain IDs for the current CPU, passing
> > smp_processor_id() to node associativity HCALL which may return
> > H_P2 (-55) error during DLPAR CPU event.
> >
> > This patch fixes this issue by passing hard_smp_processor_id() with
> > VPHN_FLAG_VCPU flag (PAPR 14.11.6.1 H_HOME_NODE_ASSOCIATIVITY).
> >
> > Signed-off-by: Haren Myneni 
> > ---
> >  arch/powerpc/platforms/pseries/vas.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/powerpc/platforms/pseries/vas.c 
> > b/arch/powerpc/platforms/pseries/vas.c
> > index fe33bdb620d5..533026fd1f40 100644
> > --- a/arch/powerpc/platforms/pseries/vas.c
> > +++ b/arch/powerpc/platforms/pseries/vas.c
> > @@ -348,7 +348,7 @@ static struct vas_window *vas_allocate_window(int 
> > vas_id, u64 flags,
> >  * So no unpacking needs to be done.
> >  */
> > rc = plpar_hcall9(H_HOME_NODE_ASSOCIATIVITY, domain,
> > - VPHN_FLAG_VCPU, smp_processor_id());
> > + VPHN_FLAG_VCPU, hard_smp_processor_id());
> > if (rc != H_SUCCESS) {
> > pr_err("H_HOME_NODE_ASSOCIATIVITY error: %d\n", rc);
> > goto out;
> 
> Yes, it is always wrong to pass Linux CPU numbers to the hypervisor,
> which has its own numbering for hardware threads. It usually coincides
> with Linux's numbering in practice, which tends to hide bugs like this.
> 
> Reviewed-by: Nathan Lynch 

This is the code that introduces the problem, right?

Fixes: b22f2d88e435 ("powerpc/pseries/vas: Integrate API with open/close 
windows")

Thanks

Michal


[PATCH] serial: cpm_uart: Don't request IRQ too early for console port

2022-09-30 Thread Christophe Leroy
The following message is seen during boot and the activation of
console port gets delayed until normal serial ports activation.

[0.001346] irq: no irq domain found for pic@930 !

The console port doesn't need irq, perform irq reservation later,
during cpm_uart probe.

While at it, don't use NO_IRQ but 0 which is the value returned
by irq_of_parse_and_map() in case of error. By chance powerpc's
NO_IRQ has value 0 but on some architectures it is -1.

Fixes: 14d893fc6846 ("powerpc/8xx: Convert CPM1 interrupt controller to 
platform_device")
Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Leroy 
---
 drivers/tty/serial/cpm_uart/cpm_uart_core.c | 22 ++---
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/tty/serial/cpm_uart/cpm_uart_core.c 
b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
index db07d6a5d764..fa5c4633086e 100644
--- a/drivers/tty/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
@@ -1214,12 +1214,6 @@ static int cpm_uart_init_port(struct device_node *np,
pinfo->port.fifosize = pinfo->tx_nrfifos * pinfo->tx_fifosize;
spin_lock_init(>port.lock);
 
-   pinfo->port.irq = irq_of_parse_and_map(np, 0);
-   if (pinfo->port.irq == NO_IRQ) {
-   ret = -EINVAL;
-   goto out_pram;
-   }
-
for (i = 0; i < NUM_GPIOS; i++) {
struct gpio_desc *gpiod;
 
@@ -1229,7 +1223,7 @@ static int cpm_uart_init_port(struct device_node *np,
 
if (IS_ERR(gpiod)) {
ret = PTR_ERR(gpiod);
-   goto out_irq;
+   goto out_pram;
}
 
if (gpiod) {
@@ -1255,8 +1249,6 @@ static int cpm_uart_init_port(struct device_node *np,
 
return cpm_uart_request_port(>port);
 
-out_irq:
-   irq_dispose_mapping(pinfo->port.irq);
 out_pram:
cpm_uart_unmap_pram(pinfo, pram);
 out_mem:
@@ -1436,11 +1428,17 @@ static int cpm_uart_probe(struct platform_device *ofdev)
/* initialize the device pointer for the port */
pinfo->port.dev = >dev;
 
+   pinfo->port.irq = irq_of_parse_and_map(ofdev->dev.of_node, 0);
+   if (!pinfo->port.irq)
+   return -EINVAL;
+
ret = cpm_uart_init_port(ofdev->dev.of_node, pinfo);
-   if (ret)
-   return ret;
+   if (!ret)
+   return uart_add_one_port(_reg, >port);
 
-   return uart_add_one_port(_reg, >port);
+   irq_dispose_mapping(pinfo->port.irq);
+
+   return ret;
 }
 
 static int cpm_uart_remove(struct platform_device *ofdev)
-- 
2.37.1



[PATCH v3 6/6] powerpc/pseries: Add firmware details to the hardware description

2022-09-30 Thread Michael Ellerman
Add firmware version details to the hardware description, which is
printed at boot and in case of an oops.

Use /hypervisor if we find it, though currently it only exists if we're
running under qemu.

Look for "ibm,powervm-partition" which is specified in PAPR+ v2.11 and
tells us we're running under PowerVM.

Failing that look for "ibm,fw-net-version" which is seen on PowerVM
going back to at least Power6.

eg: Hardware name: ... of:IBM,FW860.42 (SV860_138) hv:phyp

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/platforms/pseries/setup.c | 30 ++
 1 file changed, 30 insertions(+)

v3: Drop quotes for brevity.

diff --git a/arch/powerpc/platforms/pseries/setup.c 
b/arch/powerpc/platforms/pseries/setup.c
index 5e44c65a032c..8ef3270515a9 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -41,6 +41,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1011,6 +1012,33 @@ static void __init pSeries_cmo_feature_init(void)
pr_debug(" <- fw_cmo_feature_init()\n");
 }
 
+static void __init pseries_add_hw_description(void)
+{
+   struct device_node *dn;
+   const char *s;
+
+   dn = of_find_node_by_path("/openprom");
+   if (dn) {
+   if (of_property_read_string(dn, "model", ) == 0)
+   seq_buf_printf(_hw_desc, "of:%s ", s);
+
+   of_node_put(dn);
+   }
+
+   dn = of_find_node_by_path("/hypervisor");
+   if (dn) {
+   if (of_property_read_string(dn, "compatible", ) == 0)
+   seq_buf_printf(_hw_desc, "hv:%s ", s);
+
+   of_node_put(dn);
+   return;
+   }
+
+   if (of_property_read_bool(of_root, "ibm,powervm-partition") ||
+   of_property_read_bool(of_root, "ibm,fw-net-version"))
+   seq_buf_printf(_hw_desc, "hv:phyp ");
+}
+
 /*
  * Early initialization.  Relocation is on but do not reference unbolted pages
  */
@@ -1018,6 +1046,8 @@ static void __init pseries_init(void)
 {
pr_debug(" -> pseries_init()\n");
 
+   pseries_add_hw_description();
+
 #ifdef CONFIG_HVC_CONSOLE
if (firmware_has_feature(FW_FEATURE_LPAR))
hvc_vio_init_early();
-- 
2.37.3



[PATCH v3 5/6] powerpc/powernv: Add opal details to the hardware description

2022-09-30 Thread Michael Ellerman
Add OPAL version details to the hardware description, which is printed
at boot and in case of an oops.

eg: Hardware name: ... opal:v6.2

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/platforms/powernv/setup.c | 22 ++
 1 file changed, 22 insertions(+)

v3: Drop quotes for brevity.

diff --git a/arch/powerpc/platforms/powernv/setup.c 
b/arch/powerpc/platforms/powernv/setup.c
index dac545aa0308..61ab2d38ff4b 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -207,8 +208,29 @@ static void __init pnv_setup_arch(void)
pnv_rng_init();
 }
 
+static void __init pnv_add_hw_description(void)
+{
+   struct device_node *dn;
+   const char *s;
+
+   dn = of_find_node_by_path("/ibm,opal/firmware");
+   if (!dn)
+   return;
+
+   if (of_property_read_string(dn, "version", ) == 0 ||
+   of_property_read_string(dn, "git-id", ) == 0)
+   seq_buf_printf(_hw_desc, "opal:%s ", s);
+
+   if (of_property_read_string(dn, "mi-version", ) == 0)
+   seq_buf_printf(_hw_desc, "mi:%s ", s);
+
+   of_node_put(dn);
+}
+
 static void __init pnv_init(void)
 {
+   pnv_add_hw_description();
+
/*
 * Initialize the LPC bus now so that legacy serial
 * ports can be found on it
-- 
2.37.3



[PATCH v3 2/6] powerpc: Add PVR & CPU name to hardware description

2022-09-30 Thread Michael Ellerman
Add the PVR and CPU name to the hardware description, which is printed
at boot and in case of an oops.

eg: Hardware name: ... POWER8E (raw) 0x4b0201

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/kernel/prom.c | 4 
 1 file changed, 4 insertions(+)

v3: Drop "cpu:" and "pvr:" tags for brevity.

diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 2e7a04dab2f7..09f07cc57216 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -819,6 +820,9 @@ void __init early_init_devtree(void *params)
 
dt_cpu_ftrs_scan();
 
+   // We can now add the CPU name & PVR to the hardware description
+   seq_buf_printf(_hw_desc, "%s 0x%04lx ", cur_cpu_spec->cpu_name, 
mfspr(SPRN_PVR));
+
/* Retrieve CPU related informations from the flat tree
 * (altivec support, boot CPU ID, ...)
 */
-- 
2.37.3



[PATCH v3 1/6] powerpc: Add hardware description string

2022-09-30 Thread Michael Ellerman
Create a hardware description string, which we will use to record
various details of the hardware platform we are running on.

Print the accumulated description at boot, and use it to set the generic
description which is printed in oopses.

To begin with add ppc_md.name, aka the "machine description".

Example output at boot with the full series applied:

  Linux version 6.0.0-rc2-gcc-11.1.0-00199-g893f9007a5ce-dirty 
(michael@alpine1-p1) (powerpc64-linux-gcc (GCC) 11.1.0, GNU ld (GNU Binutils) 
2.36.1) #844 SMP Thu Sep 29 22:29:53 AEST 2022
  Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1200 0xf05 
of:SLOF,git-5b4c5a pSeries
  printk: bootconsole [udbg0] enabled

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/include/asm/setup.h   |  2 ++
 arch/powerpc/kernel/setup-common.c | 19 ++-
 2 files changed, 20 insertions(+), 1 deletion(-)

v3: Drop 'machine:' tag for brevity.

diff --git a/arch/powerpc/include/asm/setup.h b/arch/powerpc/include/asm/setup.h
index 85143849a586..e29e83f8a89c 100644
--- a/arch/powerpc/include/asm/setup.h
+++ b/arch/powerpc/include/asm/setup.h
@@ -88,6 +88,8 @@ unsigned long __init prom_init(unsigned long r3, unsigned 
long r4,
   unsigned long pp, unsigned long r6,
   unsigned long r7, unsigned long kbase);
 
+extern struct seq_buf ppc_hw_desc;
+
 #endif /* !__ASSEMBLY__ */
 
 #endif /* _ASM_POWERPC_SETUP_H */
diff --git a/arch/powerpc/kernel/setup-common.c 
b/arch/powerpc/kernel/setup-common.c
index dd98f43bd685..6d041993a45d 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -25,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -588,6 +590,15 @@ static __init int add_pcspkr(void)
 device_initcall(add_pcspkr);
 #endif /* CONFIG_PCSPKR_PLATFORM */
 
+static char ppc_hw_desc_buf[128] __initdata;
+
+struct seq_buf ppc_hw_desc __initdata = {
+   .buffer = ppc_hw_desc_buf,
+   .size = sizeof(ppc_hw_desc_buf),
+   .len = 0,
+   .readpos = 0,
+};
+
 static __init void probe_machine(void)
 {
extern struct machdep_calls __machine_desc_start;
@@ -628,7 +639,13 @@ static __init void probe_machine(void)
for (;;);
}
 
-   printk(KERN_INFO "Using %s machine description\n", ppc_md.name);
+   // Append the machine name to other info we've gathered
+   seq_buf_puts(_hw_desc, ppc_md.name);
+
+   // Set the generic hardware description shown in oopses
+   dump_stack_set_arch_desc(ppc_hw_desc.buffer);
+
+   pr_info("Hardware name: %s\n", ppc_hw_desc.buffer);
 }
 
 /* Match a class of boards, not a specific device configuration. */
-- 
2.37.3



[PATCH v3 3/6] powerpc/64: Add logical PVR to the hardware description

2022-09-30 Thread Michael Ellerman
If we detect a logical PVR add that to the hardware description, which
is printed at boot and in case of an oops.

eg: Hardware name: ... 0xf04

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/kernel/prom.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

v3: Drop "lpvr:" tag for brevity.

diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 09f07cc57216..83fc72202838 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -390,8 +390,10 @@ static int __init early_init_dt_scan_cpus(unsigned long 
node,
 */
if (!dt_cpu_ftrs_in_use()) {
prop = of_get_flat_dt_prop(node, "cpu-version", NULL);
-   if (prop && (be32_to_cpup(prop) & 0xff00) == 0x0f00)
+   if (prop && (be32_to_cpup(prop) & 0xff00) == 0x0f00) {
identify_cpu(0, be32_to_cpup(prop));
+   seq_buf_printf(_hw_desc, "0x%04x ", 
be32_to_cpup(prop));
+   }
 
check_cpu_feature_properties(node);
check_cpu_features(node, "ibm,pa-features", ibm_pa_features,
-- 
2.37.3



[PATCH v3 4/6] powerpc: Add device-tree model to the hardware description

2022-09-30 Thread Michael Ellerman
Add the model of the machine we're on to the hardware description, which
is printed at boot and in case of an oops.

eg: Hardware name: IBM,8247-22L

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/kernel/prom.c | 19 +++
 1 file changed, 19 insertions(+)

v3: Drop "model:" tag for brevity.

diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 83fc72202838..1eed87d954ba 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -715,6 +715,23 @@ static void __init tm_init(void)
 static void tm_init(void) { }
 #endif /* CONFIG_PPC_TRANSACTIONAL_MEM */
 
+static int __init
+early_init_dt_scan_model(unsigned long node, const char *uname,
+int depth, void *data)
+{
+   const char *prop;
+
+   if (depth != 0)
+   return 0;
+
+   prop = of_get_flat_dt_prop(node, "model", NULL);
+   if (prop)
+   seq_buf_printf(_hw_desc, "%s ", prop);
+
+   /* break now */
+   return 1;
+}
+
 #ifdef CONFIG_PPC64
 static void __init save_fscr_to_task(void)
 {
@@ -743,6 +760,8 @@ void __init early_init_devtree(void *params)
if (!early_init_dt_verify(params))
panic("BUG: Failed verifying flat device tree, bad version?");
 
+   of_scan_flat_dt(early_init_dt_scan_model, NULL);
+
 #ifdef CONFIG_PPC_RTAS
/* Some machines might need RTAS info for debugging, grab it now. */
of_scan_flat_dt(early_init_dt_scan_rtas, NULL);
-- 
2.37.3



Re: [PATCH] powerpc: update config files

2022-09-30 Thread Lukas Bulwahn
On Fri, Sep 30, 2022 at 9:42 AM Michael Ellerman  wrote:
>
> Lukas Bulwahn  writes:
> > Clean up config files by:
> >   - removing configs that were deleted in the past
> >   - removing configs not in tree and without recently pending patches
> >   - adding new configs that are replacements for old configs in the file
> >
> > For some detailed information, see Link.
> >
> > Link: 
> > https://lore.kernel.org/kernel-janitors/20220929090645.1389-1-lukas.bulw...@gmail.com/
>
> Ideally I'd like a list in the change log of each symbol and why they're
> being removed/changed. It's pretty easy to accidentally drop something
> otherwise.
>
> I think this is the list in this case:
>
> Renamed:
>   - CONFIG_PPC_PTDUMP -> CONFIG_GENERIC_PTDUMP
> e084728393a5 ("powerpc/ptdump: Convert powerpc to GENERIC_PTDUMP")
>
> Removed:
>   - CONFIG_BLK_DEV_CRYPTOLOOP
> 47e9624616c8 ("block: remove support for cryptoloop and the xor transfer")
>
>   - CONFIG_CRYPTO_RMD128
> b21b9a5e0aef ("crypto: rmd128 - remove RIPE-MD 128 hash algorithm")
>
>   - CONFIG_CRYPTO_RMD256
> c15d4167f0b0 ("crypto: rmd256 - remove RIPE-MD 256 hash algorithm")
>
>   - CONFIG_CRYPTO_RMD320
> 93f64202926f ("crypto: rmd320 - remove RIPE-MD 320 hash algorithm")
>
>   - CONFIG_CRYPTO_SALSA20
> 663f63ee6d9c ("crypto: salsa20 - remove Salsa20 stream cipher algorithm")
>
>   - CONFIG_CRYPTO_TGR192
> 87cd723f8978 ("crypto: tgr192 - remove Tiger 128/160/192 hash algorithms")
>
>   - CONFIG_HARDENED_USERCOPY_PAGESPAN
> 1109a5d90701 ("usercopy: Remove HARDENED_USERCOPY_PAGESPAN")
>
>   - CONFIG_RAPIDIO_TSI568, CONFIG_RAPIDIO_TSI57X
> 612d4904191f ("rapidio: remove not used code about RIO_VID_TUNDRA")
>
>   - CONFIG_RAW_DRIVER
> 603e4922f1c8 ("remove the raw driver")
>
>   - CONFIG_ROCKETPORT
> 3b00b6af7a5b ("tty: rocket, remove the driver")
>
>   - CONFIG_ENABLE_MUST_CHECK
> 196793946264 ("Compiler Attributes: remove CONFIG_ENABLE_MUST_CHECK")
>
>
> I'll fold that into the change log.
>

Sure. Go ahead. I have provided all information I collected in the
linked email (and this information drove my scripts to take actions)
and I am happy to provide it in any form a maintainer may think is
good for them. But I assume you did this with a simple script
yourself.

After going through the changes of Kconfig from the last decade, it
seems feasible that the information on Kconfig changes is actually
maintained somewhere and that would allow updating of arbitrary kernel
configs to newer kernel versions. It is not completely out of reach at
least.

And to really improve the situation, I would like to reduce all these
defconfigs in the repository to minimal kernel fragments that really
focus on what these config for specific machines intend to tell. E.g.,
these configs below (powerpc-configs) are about ensuring specific
hardware support, not about setting "CONFIG_CRYPTO_XYZ" one way or the
other. That is actually just "noise". I do not know how to do this
right yet, but with a bit of experimentation and investigation, I
might come with a first idea and then we will see.

Lukas

> cheers
>
> > Signed-off-by: Lukas Bulwahn 
> > ---
> >  arch/powerpc/configs/83xx/mpc837x_rdb_defconfig | 1 -
> >  arch/powerpc/configs/85xx/ge_imp3a_defconfig| 1 -
> >  arch/powerpc/configs/85xx/ppa8548_defconfig | 2 --
> >  arch/powerpc/configs/cell_defconfig | 1 -
> >  arch/powerpc/configs/g5_defconfig   | 1 -
> >  arch/powerpc/configs/mpc512x_defconfig  | 1 -
> >  arch/powerpc/configs/mpc885_ads_defconfig   | 2 +-
> >  arch/powerpc/configs/pasemi_defconfig   | 1 -
> >  arch/powerpc/configs/pmac32_defconfig   | 1 -
> >  arch/powerpc/configs/powernv_defconfig  | 3 ---
> >  arch/powerpc/configs/ppc64_defconfig| 3 ---
> >  arch/powerpc/configs/ppc64e_defconfig   | 3 ---
> >  arch/powerpc/configs/ppc6xx_defconfig   | 7 ---
> >  arch/powerpc/configs/ps3_defconfig  | 1 -
> >  arch/powerpc/configs/pseries_defconfig  | 3 ---
> >  arch/powerpc/configs/skiroot_defconfig  | 2 --
> >  arch/powerpc/configs/storcenter_defconfig   | 1 -
> >  17 files changed, 1 insertion(+), 33 deletions(-)
> >
> > diff --git a/arch/powerpc/configs/83xx/mpc837x_rdb_defconfig 
> > b/arch/powerpc/configs/83xx/mpc837x_rdb_defconfig
> > index cbcae2a927e9..4e3373381ab6 100644
> > --- a/arch/powerpc/configs/83xx/mpc837x_rdb_defconfig
> > +++ b/arch/powerpc/configs/83xx/mpc837x_rdb_defconfig
> > @@ -77,6 +77,5 @@ CONFIG_NFS_FS=y
> >  CONFIG_NFS_V4=y
> >  CONFIG_ROOT_NFS=y
> >  CONFIG_CRC_T10DIF=y
> > -# CONFIG_ENABLE_MUST_CHECK is not set
> >  CONFIG_CRYPTO_ECB=m
> >  CONFIG_CRYPTO_PCBC=m
> > diff --git a/arch/powerpc/configs/85xx/ge_imp3a_defconfig 
> > b/arch/powerpc/configs/85xx/ge_imp3a_defconfig
> > index e7672c186325..ea719898b581 100644
> > --- a/arch/powerpc/configs/85xx/ge_imp3a_defconfig
> > +++ b/arch/powerpc/configs/85xx/ge_imp3a_defconfig
> > 

Re: [PATCH] powerpc: update config files

2022-09-30 Thread Michael Ellerman
Lukas Bulwahn  writes:
> Clean up config files by:
>   - removing configs that were deleted in the past
>   - removing configs not in tree and without recently pending patches
>   - adding new configs that are replacements for old configs in the file
>
> For some detailed information, see Link.
>
> Link: 
> https://lore.kernel.org/kernel-janitors/20220929090645.1389-1-lukas.bulw...@gmail.com/

Ideally I'd like a list in the change log of each symbol and why they're
being removed/changed. It's pretty easy to accidentally drop something
otherwise.

I think this is the list in this case:

Renamed:
  - CONFIG_PPC_PTDUMP -> CONFIG_GENERIC_PTDUMP
e084728393a5 ("powerpc/ptdump: Convert powerpc to GENERIC_PTDUMP")

Removed:
  - CONFIG_BLK_DEV_CRYPTOLOOP
47e9624616c8 ("block: remove support for cryptoloop and the xor transfer")
  
  - CONFIG_CRYPTO_RMD128
b21b9a5e0aef ("crypto: rmd128 - remove RIPE-MD 128 hash algorithm")
  
  - CONFIG_CRYPTO_RMD256
c15d4167f0b0 ("crypto: rmd256 - remove RIPE-MD 256 hash algorithm")
  
  - CONFIG_CRYPTO_RMD320
93f64202926f ("crypto: rmd320 - remove RIPE-MD 320 hash algorithm")
  
  - CONFIG_CRYPTO_SALSA20
663f63ee6d9c ("crypto: salsa20 - remove Salsa20 stream cipher algorithm")
  
  - CONFIG_CRYPTO_TGR192
87cd723f8978 ("crypto: tgr192 - remove Tiger 128/160/192 hash algorithms")
  
  - CONFIG_HARDENED_USERCOPY_PAGESPAN
1109a5d90701 ("usercopy: Remove HARDENED_USERCOPY_PAGESPAN")
  
  - CONFIG_RAPIDIO_TSI568, CONFIG_RAPIDIO_TSI57X
612d4904191f ("rapidio: remove not used code about RIO_VID_TUNDRA")
  
  - CONFIG_RAW_DRIVER
603e4922f1c8 ("remove the raw driver")
  
  - CONFIG_ROCKETPORT
3b00b6af7a5b ("tty: rocket, remove the driver")
  
  - CONFIG_ENABLE_MUST_CHECK
196793946264 ("Compiler Attributes: remove CONFIG_ENABLE_MUST_CHECK")


I'll fold that into the change log.

cheers

> Signed-off-by: Lukas Bulwahn 
> ---
>  arch/powerpc/configs/83xx/mpc837x_rdb_defconfig | 1 -
>  arch/powerpc/configs/85xx/ge_imp3a_defconfig| 1 -
>  arch/powerpc/configs/85xx/ppa8548_defconfig | 2 --
>  arch/powerpc/configs/cell_defconfig | 1 -
>  arch/powerpc/configs/g5_defconfig   | 1 -
>  arch/powerpc/configs/mpc512x_defconfig  | 1 -
>  arch/powerpc/configs/mpc885_ads_defconfig   | 2 +-
>  arch/powerpc/configs/pasemi_defconfig   | 1 -
>  arch/powerpc/configs/pmac32_defconfig   | 1 -
>  arch/powerpc/configs/powernv_defconfig  | 3 ---
>  arch/powerpc/configs/ppc64_defconfig| 3 ---
>  arch/powerpc/configs/ppc64e_defconfig   | 3 ---
>  arch/powerpc/configs/ppc6xx_defconfig   | 7 ---
>  arch/powerpc/configs/ps3_defconfig  | 1 -
>  arch/powerpc/configs/pseries_defconfig  | 3 ---
>  arch/powerpc/configs/skiroot_defconfig  | 2 --
>  arch/powerpc/configs/storcenter_defconfig   | 1 -
>  17 files changed, 1 insertion(+), 33 deletions(-)
>
> diff --git a/arch/powerpc/configs/83xx/mpc837x_rdb_defconfig 
> b/arch/powerpc/configs/83xx/mpc837x_rdb_defconfig
> index cbcae2a927e9..4e3373381ab6 100644
> --- a/arch/powerpc/configs/83xx/mpc837x_rdb_defconfig
> +++ b/arch/powerpc/configs/83xx/mpc837x_rdb_defconfig
> @@ -77,6 +77,5 @@ CONFIG_NFS_FS=y
>  CONFIG_NFS_V4=y
>  CONFIG_ROOT_NFS=y
>  CONFIG_CRC_T10DIF=y
> -# CONFIG_ENABLE_MUST_CHECK is not set
>  CONFIG_CRYPTO_ECB=m
>  CONFIG_CRYPTO_PCBC=m
> diff --git a/arch/powerpc/configs/85xx/ge_imp3a_defconfig 
> b/arch/powerpc/configs/85xx/ge_imp3a_defconfig
> index e7672c186325..ea719898b581 100644
> --- a/arch/powerpc/configs/85xx/ge_imp3a_defconfig
> +++ b/arch/powerpc/configs/85xx/ge_imp3a_defconfig
> @@ -74,7 +74,6 @@ CONFIG_MTD_PHYSMAP_OF=y
>  CONFIG_MTD_RAW_NAND=y
>  CONFIG_MTD_NAND_FSL_ELBC=y
>  CONFIG_BLK_DEV_LOOP=m
> -CONFIG_BLK_DEV_CRYPTOLOOP=m
>  CONFIG_BLK_DEV_NBD=m
>  CONFIG_BLK_DEV_RAM=y
>  CONFIG_BLK_DEV_RAM_SIZE=131072
> diff --git a/arch/powerpc/configs/85xx/ppa8548_defconfig 
> b/arch/powerpc/configs/85xx/ppa8548_defconfig
> index 190978a5b7d5..4bd5f993d26a 100644
> --- a/arch/powerpc/configs/85xx/ppa8548_defconfig
> +++ b/arch/powerpc/configs/85xx/ppa8548_defconfig
> @@ -7,9 +7,7 @@ CONFIG_RAPIDIO=y
>  CONFIG_FSL_RIO=y
>  CONFIG_RAPIDIO_DMA_ENGINE=y
>  CONFIG_RAPIDIO_ENUM_BASIC=y
> -CONFIG_RAPIDIO_TSI57X=y
>  CONFIG_RAPIDIO_CPS_XX=y
> -CONFIG_RAPIDIO_TSI568=y
>  CONFIG_RAPIDIO_CPS_GEN2=y
>  CONFIG_ADVANCED_OPTIONS=y
>  CONFIG_LOWMEM_SIZE_BOOL=y
> diff --git a/arch/powerpc/configs/cell_defconfig 
> b/arch/powerpc/configs/cell_defconfig
> index 7fd9e596ea33..06391cc2af3a 100644
> --- a/arch/powerpc/configs/cell_defconfig
> +++ b/arch/powerpc/configs/cell_defconfig
> @@ -195,7 +195,6 @@ CONFIG_NLS_ISO8859_9=m
>  CONFIG_NLS_ISO8859_13=m
>  CONFIG_NLS_ISO8859_14=m
>  CONFIG_NLS_ISO8859_15=m
> -# CONFIG_ENABLE_MUST_CHECK is not set
>  CONFIG_MAGIC_SYSRQ=y
>  CONFIG_DEBUG_KERNEL=y
>  CONFIG_DEBUG_MUTEXES=y
> diff --git a/arch/powerpc/configs/g5_defconfig 
> 

Re: [PATCH -next] powerpc/mpic_msgr: fix cast removes address space of expression warnings

2022-09-30 Thread Michael Ellerman
Christophe Leroy  writes:
> Le 01/09/2022 à 10:54, ruanjinjie a écrit :
>> [Vous ne recevez pas souvent de courriers de ruanjin...@huawei.com. 
>> Découvrez pourquoi ceci est important à 
>> https://aka.ms/LearnAboutSenderIdentification ]
>> 
>> When build Linux kernel, encounter the following warnings:
>> 
>> ./arch/powerpc/sysdev/mpic_msgr.c:230:38: warning: cast removes address 
>> space '__iomem' of expression
>> ./arch/powerpc/sysdev/mpic_msgr.c:230:27: warning: incorrect type in 
>> assignment (different address spaces)
>> 
>> The data type of msgr->mer and msgr->base are 'u32 __iomem *', but
>> converted to 'u32 *' and 'u8 *' directly and cause above warnings, now
>> recover their data types to fix these warnings.
>
> I think the best would be to change MPIC_MSGR_MER_OFFSET to 0x40 and 
> then drop the casts completely:
>
>   msgr->mer = msgr->base + MPIC_MSGR_MER_OFFSET;

Or:

#define MPIC_MSGR_MER_OFFSET(0x100 / sizeof(u32))

To document that it's 0x100 bytes, but the the offset is in units of u32.

cheers


[PATCH v2] powerpc/microwatt: Add litesd

2022-09-30 Thread Joel Stanley
This is the register layout of the litesd peripheral for the fusesoc
based Microwatt SoC.

It requires a description of the system clock, which is hardcoded to
100MHz.

Signed-off-by: Joel Stanley 
---
v2:
 * remove non-removable property
 * Remove status=disabled
 * Add clock
---
 arch/powerpc/boot/dts/microwatt.dts | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/powerpc/boot/dts/microwatt.dts 
b/arch/powerpc/boot/dts/microwatt.dts
index b69db1d275cd..269e930b3b0b 100644
--- a/arch/powerpc/boot/dts/microwatt.dts
+++ b/arch/powerpc/boot/dts/microwatt.dts
@@ -21,6 +21,14 @@ memory@0 {
reg = <0x 0x 0x 0x1000>;
};
 
+   clocks {
+   sys_clk: litex_sys_clk {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <1>;
+   };
+   };
+
cpus {
#size-cells = <0x00>;
#address-cells = <0x01>;
@@ -141,6 +149,20 @@ ethernet@802 {
litex,slot-size = <0x800>;
interrupts = <0x11 0x1>;
};
+
+   mmc@804 {
+   compatible = "litex,mmc";
+   reg = <0x8042800 0x800
+   0x8041000 0x800
+   0x8040800 0x800
+   0x8042000 0x800
+   0x8041800 0x800>;
+   reg-names = "phy", "core", "reader", "writer", "irq";
+   bus-width = <4>;
+   interrupts = <0x13 1>;
+   cap-sd-highspeed;
+   clocks = <_clk>;
+   };
};
 
chosen {
-- 
2.35.1



[PATCH v3 7/7] ASoC: imx-rpmsg: Assign platform driver used by machine driver to link with

2022-09-30 Thread Chancel Liu
Each ASoC platform driver is named by rpmsg channel. ASoC machine
driver can parse "fsl,rpmsg-channel-name" property to figure out which
ASoC platform driver it should link with.

Signed-off-by: Chancel Liu 
---
 sound/soc/fsl/imx-rpmsg.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/sound/soc/fsl/imx-rpmsg.c b/sound/soc/fsl/imx-rpmsg.c
index 2e117311e582..57684064c9da 100644
--- a/sound/soc/fsl/imx-rpmsg.c
+++ b/sound/soc/fsl/imx-rpmsg.c
@@ -36,6 +36,7 @@ static int imx_rpmsg_probe(struct platform_device *pdev)
struct platform_device *rpmsg_pdev = to_platform_device(dev);
struct device_node *np = rpmsg_pdev->dev.of_node;
struct of_phandle_args args;
+   const char *platform_name;
struct imx_rpmsg *data;
int ret = 0;
 
@@ -81,7 +82,10 @@ static int imx_rpmsg_probe(struct platform_device *pdev)
}
 
data->dai.cpus->dai_name = dev_name(_pdev->dev);
-   data->dai.platforms->name = IMX_PCM_DRV_NAME;
+   if (!of_property_read_string(np, "fsl,rpmsg-channel-name", 
_name))
+   data->dai.platforms->name = platform_name;
+   else
+   data->dai.platforms->name = "rpmsg-audio-channel";
data->dai.playback_only = true;
data->dai.capture_only = true;
data->card.num_links = 1;
-- 
2.25.1



[PATCH v3 6/7] ASoC: fsl_rpmsg: Multi-channel support in CPU DAI driver

2022-09-30 Thread Chancel Liu
Some sound card based on rpmsg may support multi-channel. This patch
expands the maximum channels to 32.

Signed-off-by: Chancel Liu 
---
 sound/soc/fsl/fsl_rpmsg.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/fsl/fsl_rpmsg.c b/sound/soc/fsl/fsl_rpmsg.c
index fde3d5006ce0..46c7868a2653 100644
--- a/sound/soc/fsl/fsl_rpmsg.c
+++ b/sound/soc/fsl/fsl_rpmsg.c
@@ -117,14 +117,14 @@ static struct snd_soc_dai_driver fsl_rpmsg_dai = {
.playback = {
.stream_name = "CPU-Playback",
.channels_min = 2,
-   .channels_max = 2,
+   .channels_max = 32,
.rates = SNDRV_PCM_RATE_KNOT,
.formats = FSL_RPMSG_FORMATS,
},
.capture = {
.stream_name = "CPU-Capture",
.channels_min = 2,
-   .channels_max = 2,
+   .channels_max = 32,
.rates = SNDRV_PCM_RATE_KNOT,
.formats = FSL_RPMSG_FORMATS,
},
-- 
2.25.1



[PATCH v3 5/7] ASoC: fsl_rpmsg: Register different ASoC machine devices

2022-09-30 Thread Chancel Liu
This driver helps register ASoC machine device thus use of
PLATFORM_DEVID_AUTO macro in API can automatically create device for
each sound card based on rpmsg.

Signed-off-by: Chancel Liu 
---
 sound/soc/fsl/fsl_rpmsg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/fsl/fsl_rpmsg.c b/sound/soc/fsl/fsl_rpmsg.c
index bf94838bdbef..fde3d5006ce0 100644
--- a/sound/soc/fsl/fsl_rpmsg.c
+++ b/sound/soc/fsl/fsl_rpmsg.c
@@ -235,7 +235,7 @@ static int fsl_rpmsg_probe(struct platform_device *pdev)
 
rpmsg->card_pdev = platform_device_register_data(>dev,
 "imx-audio-rpmsg",
-PLATFORM_DEVID_NONE,
+PLATFORM_DEVID_AUTO,
 NULL,
 0);
if (IS_ERR(rpmsg->card_pdev)) {
-- 
2.25.1



[PATCH v3 4/7] ASoC: imx-pcm-rpmsg: Multi-channel support for sound card based on rpmsg

2022-09-30 Thread Chancel Liu
Some sound card based on rpmsg may support multi-channel. The number of
channels can be sent to Cortex-M in rpmsg for process.

Signed-off-by: Chancel Liu 
---
 sound/soc/fsl/imx-pcm-rpmsg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/fsl/imx-pcm-rpmsg.c b/sound/soc/fsl/imx-pcm-rpmsg.c
index 3157cd5a837e..2f310994f7ee 100644
--- a/sound/soc/fsl/imx-pcm-rpmsg.c
+++ b/sound/soc/fsl/imx-pcm-rpmsg.c
@@ -178,7 +178,7 @@ static int imx_rpmsg_pcm_hw_params(struct snd_soc_component 
*component,
msg->s_msg.param.channels = RPMSG_CH_STEREO;
break;
default:
-   ret = -EINVAL;
+   msg->s_msg.param.channels = params_channels(params);
break;
}
 
-- 
2.25.1



[PATCH v3 3/7] ASoC: imx-pcm-rpmsg: Register different platform drivers

2022-09-30 Thread Chancel Liu
This patch can register different ASoC platform drivers if there are
several rpmsg channels. Thus sound cards based on different rpmsg
channels can link to their respective platform drivers. Besides, the
name of driver is equal to the name of rpmsg channel.

Signed-off-by: Chancel Liu 
---
 sound/soc/fsl/imx-pcm-rpmsg.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/sound/soc/fsl/imx-pcm-rpmsg.c b/sound/soc/fsl/imx-pcm-rpmsg.c
index 35049043e532..3157cd5a837e 100644
--- a/sound/soc/fsl/imx-pcm-rpmsg.c
+++ b/sound/soc/fsl/imx-pcm-rpmsg.c
@@ -684,7 +684,7 @@ static int imx_rpmsg_pcm_probe(struct platform_device *pdev)
info->rpdev = container_of(pdev->dev.parent, struct rpmsg_device, dev);
info->dev = >dev;
/* Setup work queue */
-   info->rpmsg_wq = alloc_ordered_workqueue("rpmsg_audio",
+   info->rpmsg_wq = alloc_ordered_workqueue(info->rpdev->id.name,
 WQ_HIGHPRI |
 WQ_UNBOUND |
 WQ_FREEZABLE);
@@ -723,11 +723,15 @@ static int imx_rpmsg_pcm_probe(struct platform_device 
*pdev)
if (ret)
goto fail;
 
-   component = snd_soc_lookup_component(>dev, IMX_PCM_DRV_NAME);
+   component = snd_soc_lookup_component(>dev, NULL);
if (!component) {
ret = -EINVAL;
goto fail;
}
+
+   /* platform component name is used by machine driver to link with */
+   component->name = info->rpdev->id.name;
+
 #ifdef CONFIG_DEBUG_FS
component->debugfs_prefix = "rpmsg";
 #endif
-- 
2.25.1



[PATCH v3 2/7] ASoC: imx-audio-rpmsg: Create rpmsg channel for MICFIL

2022-09-30 Thread Chancel Liu
Rpmsg channel for MICFIL can also be created through rpmsg name service
announcement. If this driver is probed, Cortex-A can access MICFIL
which is actually controlled by Cortex-M through rpmsg channel for
MICFIL. This driver also helps register ASoC platform device thus use
of PLATFORM_DEVID_AUTO macro in API can automatically create device for
each rpmsg channel.

Signed-off-by: Chancel Liu 
---
 sound/soc/fsl/imx-audio-rpmsg.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sound/soc/fsl/imx-audio-rpmsg.c b/sound/soc/fsl/imx-audio-rpmsg.c
index 905c3a071300..d5234ac4b09b 100644
--- a/sound/soc/fsl/imx-audio-rpmsg.c
+++ b/sound/soc/fsl/imx-audio-rpmsg.c
@@ -88,7 +88,7 @@ static int imx_audio_rpmsg_probe(struct rpmsg_device *rpdev)
/* Register platform driver for rpmsg routine */
data->rpmsg_pdev = platform_device_register_data(>dev,
 IMX_PCM_DRV_NAME,
-PLATFORM_DEVID_NONE,
+PLATFORM_DEVID_AUTO,
 NULL, 0);
if (IS_ERR(data->rpmsg_pdev)) {
dev_err(>dev, "failed to register rpmsg platform.\n");
@@ -110,6 +110,7 @@ static void imx_audio_rpmsg_remove(struct rpmsg_device 
*rpdev)
 
 static struct rpmsg_device_id imx_audio_rpmsg_id_table[] = {
{ .name = "rpmsg-audio-channel" },
+   { .name = "rpmsg-micfil-channel" },
{ },
 };
 
-- 
2.25.1



[PATCH v3 1/7] ASoC: dt-bindings: fsl_rpmsg: Add a property to assign the rpmsg channel

2022-09-30 Thread Chancel Liu
Add a string property to assign the rpmsg channel this sound card sits
on. This property can be omitted if there is only one sound card and it
sits on "rpmsg-audio-channel".

Signed-off-by: Chancel Liu 
---
 .../devicetree/bindings/sound/fsl,rpmsg.yaml  | 36 +--
 1 file changed, 34 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml 
b/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml
index d370c98a62c7..e847611a85f7 100644
--- a/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml
+++ b/Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml
@@ -11,8 +11,11 @@ maintainers:
 
 description: |
   fsl_rpmsg is a virtual audio device. Mapping to real hardware devices
-  are SAI, DMA controlled by Cortex M core. What we see from Linux
-  side is a device which provides audio service by rpmsg channel.
+  are SAI, MICFIL, DMA controlled by Cortex M core. What we see from
+  Linux side is a device which provides audio service by rpmsg channel.
+  We can create different sound cards which access different hardwares
+  such as SAI, MICFIL, .etc through building rpmsg channels between
+  Cortex-A and Cortex-M.
 
 properties:
   compatible:
@@ -85,6 +88,16 @@ properties:
   This is a boolean property. If present, the receiving function
   will be enabled.
 
+  fsl,rpmsg-channel-name:
+$ref: /schemas/types.yaml#/definitions/string
+description: |
+  A string property to assign rpmsg channel this sound card sits on.
+  This property can be omitted if there is only one sound card and it sits
+  on "rpmsg-audio-channel".
+enum:
+  - rpmsg-audio-channel
+  - rpmsg-micfil-channel
+
 required:
   - compatible
   - model
@@ -107,3 +120,22 @@ examples:
  < IMX8MN_AUDIO_PLL2_OUT>;
 clock-names = "ipg", "mclk", "dma", "pll8k", "pll11k";
 };
+
+  - |
+#include 
+
+rpmsg_micfil: audio-controller {
+compatible = "fsl,imx8mm-rpmsg-audio";
+model = "micfil-audio";
+fsl,rpmsg-channel-name = "rpmsg-micfil-channel";
+fsl,enable-lpa;
+fsl,rpmsg-in;
+clocks = < IMX8MM_CLK_PDM_IPG>,
+ < IMX8MM_CLK_PDM_ROOT>,
+ < IMX8MM_CLK_SDMA3_ROOT>,
+ < IMX8MM_AUDIO_PLL1_OUT>,
+ < IMX8MM_AUDIO_PLL2_OUT>;
+clock-names = "ipg", "mclk", "dma", "pll8k", "pll11k";
+};
+
+...
-- 
2.25.1



[PATCH v3 0/7] Create a new sound card to access MICFIL based on rpmsg channel

2022-09-30 Thread Chancel Liu
At a previous time, we have successfully created a virtual sound card
based on rpmsg. The sound card works under this mechanism Cortex-A core
tells the Cortex-M core the format, rate, channel, .etc configuration
of the PCM parameters and Cortex-M controls real hardware devices such
as SAI and DMA. From the view of Linux side, the sound card is bound to
a rpmsg channel through which it can access SAI.

Here these patches are introduced to create a new virtual sound card to
access MICFIL based on a new created rpmsg channel. It's easy to create
a new rpmsg channel for MICFIL through rpmsg name service announcment.
Also the other ASoC components bound to this rpmsg MICFIL sound card
will be registered with these patches.

If other sound cards using different hardware devices needs to be
created over rpmsg in the future, these patches can be referred.

changes in v3
- Delete the statement referring to linux drivers in dts

changes in v2:
- Rename property in bindings file according to Krzysztof's comments
- Update codes and comments according to Shengjiu's comments

Chancel Liu (7):
  ASoC: dt-bindings: fsl_rpmsg: Add a property to assign the rpmsg
channel
  ASoC: imx-audio-rpmsg: Create rpmsg channel for MICFIL
  ASoC: imx-pcm-rpmsg: Register different platform drivers
  ASoC: imx-pcm-rpmsg: Multi-channel support for sound card based on
rpmsg
  ASoC: fsl_rpmsg: Register different ASoC machine devices
  ASoC: fsl_rpmsg: Multi-channel support in CPU DAI driver
  ASoC: imx-rpmsg: Assign platform driver used by machine driver to link
with

 .../devicetree/bindings/sound/fsl,rpmsg.yaml  | 36 +--
 sound/soc/fsl/fsl_rpmsg.c |  6 ++--
 sound/soc/fsl/imx-audio-rpmsg.c   |  3 +-
 sound/soc/fsl/imx-pcm-rpmsg.c | 10 --
 sound/soc/fsl/imx-rpmsg.c |  6 +++-
 5 files changed, 51 insertions(+), 10 deletions(-)

--
2.25.1



Re: [PATCH -next] powerpc/mpic_msgr: fix cast removes address space of expression warnings

2022-09-30 Thread Ruan Jinjie



On 2022/9/30 14:09, Christophe Leroy wrote:
> 
> 
> Le 01/09/2022 à 10:54, ruanjinjie a écrit :
>> [Vous ne recevez pas souvent de courriers de ruanjin...@huawei.com. 
>> Découvrez pourquoi ceci est important à 
>> https://aka.ms/LearnAboutSenderIdentification ]
>>
>> When build Linux kernel, encounter the following warnings:
>>
>> ./arch/powerpc/sysdev/mpic_msgr.c:230:38: warning: cast removes address 
>> space '__iomem' of expression
>> ./arch/powerpc/sysdev/mpic_msgr.c:230:27: warning: incorrect type in 
>> assignment (different address spaces)
>>
>> The data type of msgr->mer and msgr->base are 'u32 __iomem *', but
>> converted to 'u32 *' and 'u8 *' directly and cause above warnings, now
>> recover their data types to fix these warnings.
> 
> I think the best would be to change MPIC_MSGR_MER_OFFSET to 0x40 and 
> then drop the casts completely:
> 
>   msgr->mer = msgr->base + MPIC_MSGR_MER_OFFSET;
> 
I think this is good to solve the warning.

>>
>> Signed-off-by: ruanjinjie 
>> ---
>>   arch/powerpc/sysdev/mpic_msgr.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/sysdev/mpic_msgr.c 
>> b/arch/powerpc/sysdev/mpic_msgr.c
>> index 698fefaaa6dd..cbb0d24f15ba 100644
>> --- a/arch/powerpc/sysdev/mpic_msgr.c
>> +++ b/arch/powerpc/sysdev/mpic_msgr.c
>> @@ -227,7 +227,7 @@ static int mpic_msgr_probe(struct platform_device *dev)
>>
>>  reg_number = block_number * MPIC_MSGR_REGISTERS_PER_BLOCK + 
>> i;
>>  msgr->base = msgr_block_addr + i * MPIC_MSGR_STRIDE;
>> -   msgr->mer = (u32 *)((u8 *)msgr->base + MPIC_MSGR_MER_OFFSET);
>> +   msgr->mer = (u32 __iomem *)((u8 __iomem *)msgr->base + 
>> MPIC_MSGR_MER_OFFSET);
>>  msgr->in_use = MSGR_FREE;
>>  msgr->num = i;
>>  raw_spin_lock_init(>lock);
>> --
>> 2.25.1


Re: [PATCH -next] powerpc/mpic_msgr: fix cast removes address space of expression warnings

2022-09-30 Thread Christophe Leroy


Le 01/09/2022 à 10:54, ruanjinjie a écrit :
> [Vous ne recevez pas souvent de courriers de ruanjin...@huawei.com. Découvrez 
> pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
> 
> When build Linux kernel, encounter the following warnings:
> 
> ./arch/powerpc/sysdev/mpic_msgr.c:230:38: warning: cast removes address space 
> '__iomem' of expression
> ./arch/powerpc/sysdev/mpic_msgr.c:230:27: warning: incorrect type in 
> assignment (different address spaces)
> 
> The data type of msgr->mer and msgr->base are 'u32 __iomem *', but
> converted to 'u32 *' and 'u8 *' directly and cause above warnings, now
> recover their data types to fix these warnings.

I think the best would be to change MPIC_MSGR_MER_OFFSET to 0x40 and 
then drop the casts completely:

msgr->mer = msgr->base + MPIC_MSGR_MER_OFFSET;

> 
> Signed-off-by: ruanjinjie 
> ---
>   arch/powerpc/sysdev/mpic_msgr.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/sysdev/mpic_msgr.c b/arch/powerpc/sysdev/mpic_msgr.c
> index 698fefaaa6dd..cbb0d24f15ba 100644
> --- a/arch/powerpc/sysdev/mpic_msgr.c
> +++ b/arch/powerpc/sysdev/mpic_msgr.c
> @@ -227,7 +227,7 @@ static int mpic_msgr_probe(struct platform_device *dev)
> 
>  reg_number = block_number * MPIC_MSGR_REGISTERS_PER_BLOCK + 
> i;
>  msgr->base = msgr_block_addr + i * MPIC_MSGR_STRIDE;
> -   msgr->mer = (u32 *)((u8 *)msgr->base + MPIC_MSGR_MER_OFFSET);
> +   msgr->mer = (u32 __iomem *)((u8 __iomem *)msgr->base + 
> MPIC_MSGR_MER_OFFSET);
>  msgr->in_use = MSGR_FREE;
>  msgr->num = i;
>  raw_spin_lock_init(>lock);
> --
> 2.25.1
>