date:20201211


On 12/11/20 6:17 PM, Thiago Jung Bauermann wrote:


Lakshmi Ramasubramanian  writes:


On 12/11/20 2:10 PM, Rob Herring wrote:

Hi Rob,


Both arm64 and powerpc do essentially the same FDT /chosen setup for
kexec. We can simply combine everything each arch does. The differences
are either omissions that arm64 should have or additional properties
that will be ignored.
The differences relative to the arm64 version:
- If /chosen doesn't exist, it will be created (should never happen).
- Any old dtb and initrd reserved memory will be released.
- The new initrd and elfcorehdr are marked reserved.
- "linux,booted-from-kexec" is set.
The differences relative to the powerpc version:
- "kaslr-seed" and "rng-seed" may be set.
- "linux,elfcorehdr" is set.
- Any existing "linux,usable-memory-range" is removed.
Signed-off-by: Rob Herring 
---
This could be taken a step further and do the allocation of the new
FDT. The difference is arm64 uses vmalloc and powerpc uses kmalloc. The
arm64 version also retries with a bigger allocation. That seems
unnecessary.
---
   drivers/of/Makefile |   1 +
   drivers/of/kexec.c  | 228 
   include/linux/of.h  |   5 +
   3 files changed, 234 insertions(+)
   create mode 100644 drivers/of/kexec.c
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index 6e1e5212f058..8ce11955afde 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -13,5 +13,6 @@ obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
   obj-$(CONFIG_OF_RESOLVE)  += resolver.o
   obj-$(CONFIG_OF_OVERLAY) += overlay.o
   obj-$(CONFIG_OF_NUMA) += of_numa.o
+obj-$(CONFIG_KEXEC_FILE) += kexec.o


For the functions moved from powerpc & arm64 to "drivers/of/kexec.c" in this
patch, compiling kexec.c when CONFIG_KEXEC_FILE is enabled is fine. But when
more functions (such as remove_ima_buffer()) are moved to this file, Makefile
needs to be updated for other ima kexec related CONFIGs.


IMA kexec is only available if CONFIG_KEXEC_FILE is enabled, so I don't
understand what problem you are seeing.



delete_fdt_mem_rsv() and setup_fdt() functions are defined when 
CONFIG_KEXEC_FILE is enabled. So there is no problem with this patch as 
such.


I was thinking when other arch independent functions such as 
do_get_kexec_buffer() and remove_ima_buffer() are moved to 
"drivers/of/kexec.c", they need to be defined only when 
CONFIG_HAVE_IMA_KEXEC is enabled.


If CONFIG_HAVE_IMA_KEXEC is enabled, CONFIG_KEXEC_FILE is also enabled. 
So there shouldn't be a problem moving those functions to 
"drivers/of/kexec.c". You are right Thiago. Thanks.


 -lakshmi

Business Expansion *Capital

2020-12-11 Thread Cahil Frank

My name is Cahil Frank an advertising agent with Eurocredit & loan services, 
the company pays me commission as per each client introduced to them. The 
Company specializes in providing equity funding for projects and corporate also 
Personal loan funding at 3% Interest Rate for duration of 10 to 15 Years. They 
also have financial capability to provide early stage funding including fresh 
cut BG's, MTN and MT760.
 
They are a private equity firm made up and funded by indigenous i n v e s t o r 
s and Lenders as its shareholders across the Asia Region, with support from the 
Hong Kong government at our disposal.
 
NB: * Starting up a Franchise * Business Acquisition * Business Expansion 
*Capital / Infrastructural Project* Commercial Agriculture * Commercial Real 
Estate purchase * Contract Execution * Trade Financing etc. funding is from 
USD$1 million up to USD $2 billion depending on the nature and viability of the 
business, investment or project. We are open to having a good business 
relationship with our clients. If you have a profitable project. Investment or 
business, kindly contact me so I can forward the contact information of this 
Loan company so you can contact them to share your loan executive summary and 
any project/business you need funding. They will give you the best and most 
reliable services.
 
Kind regards,
Cahil Frank

Re: [PATCH] net/mlx4: Use true,false for bool variable

2020-12-11 Thread Joe Perches

On Fri, 2020-12-11 at 11:05 +0100, Vasyl Gomonovych wrote:
> Fix en_rx.c:687:1-17: WARNING: Assignment of 0/1 to bool variable
> Fix main.c:4465:5-13: WARNING: Comparison of 0/1 to bool variable
[]
> diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c 
> b/drivers/net/ethernet/mellanox/mlx4/main.c
[]
> @@ -4462,7 +4462,7 @@ static int __init mlx4_verify_params(void)
>   pr_warn("mlx4_core: log_num_vlan - obsolete module param, using 
> %d\n",
>   MLX4_LOG_NUM_VLANS);
>  
> 
> - if (use_prio != 0)
> + if (use_prio != false)
>   pr_warn("mlx4_core: use_prio - obsolete module param, 
> ignored\n");

Generally, assuming use_prio is bool, this would be written

if (use_prio)
pr_warn("etc...")

Re: [PATCH v3 00/20] dmaengine/soc: k3-udma: Add support for BCDMA and PKTDMA

2020-12-11 Thread Vinod Koul

On 11-12-20, 21:16, Peter Ujfalusi wrote:
> Hi Vinod,
> 
> On 11/12/2020 18.24, Vinod Koul wrote:
> > On 08-12-20, 11:04, Peter Ujfalusi wrote:
> >> Hi,
> >>
> >> The series have build dependency on ti_sci/soc series (v2):
> >> https://lore.kernel.org/lkml/20201008115224.1591-1-peter.ujfal...@ti.com/
> >>
> >> Santosh kindly provided immutable branch and tag holding the series:
> >> git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git 
> >> tags/drivers_soc_for_5.11 
> > 
> > I have picked this and then merged this and pushed to test branch. If
> > everything is okay, it will be next on monday
> 
> Thank you!
> 
> this might cause a sparse warning:
> https://lore.kernel.org/lkml/a1f83b16-c1ce-630e-3410-738b80a92...@ti.com/
> 
> I can send an incremental patch or resend the whole series with this
> correction?

Incremental please

Thanks

-- 
~Vinod

[rcu:rcu/test] BUILD SUCCESS 4cef066889e3af15f564a2b29d05030a8204a9a3

2020-12-11 Thread kernel test robot

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git  rcu/test
branch HEAD: 4cef066889e3af15f564a2b29d05030a8204a9a3  Merge tag 'v5.10-rc7' 
into dev.2020.12.11a

elapsed time: 724m

configs tested: 127
configs skipped: 2

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

gcc tested configs:
arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
powerpc linkstation_defconfig
sh apsh4a3a_defconfig
arm   omap1_defconfig
powerpc mpc512x_defconfig
microblazenommu_defconfig
powerpc   allnoconfig
armqcom_defconfig
sh  rsk7264_defconfig
powerpccell_defconfig
arm  jornada720_defconfig
sh  urquell_defconfig
mips   mtx1_defconfig
powerpcmvme5100_defconfig
mips cobalt_defconfig
m68k allyesconfig
arm   imx_v6_v7_defconfig
c6x dsk6455_defconfig
xtensasmp_lx200_defconfig
armxcep_defconfig
armmulti_v5_defconfig
arm socfpga_defconfig
arm  moxart_defconfig
arm s3c6400_defconfig
mips cu1000-neo_defconfig
arm   aspeed_g4_defconfig
arc haps_hs_defconfig
powerpcwarp_defconfig
sh   se7343_defconfig
nds32   defconfig
parisc   alldefconfig
powerpcklondike_defconfig
powerpc mpc8560_ads_defconfig
arm assabet_defconfig
powerpc  tqm8xx_defconfig
powerpc pq2fads_defconfig
shedosk7760_defconfig
arm mxs_defconfig
i386defconfig
xtensa virt_defconfig
xtensageneric_kc705_defconfig
sparcallyesconfig
powerpc  g5_defconfig
m68k   bvme6000_defconfig
xtensa   allyesconfig
arm mv78xx0_defconfig
sh  sh7785lcr_32bit_defconfig
arm  simpad_defconfig
powerpc mpc832x_rdb_defconfig
sh   se7724_defconfig
c6x defconfig
sh   secureedge5410_defconfig
shhp6xx_defconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparc   defconfig
i386   tinyconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
i386 randconfig-a004-20201209
i386 randconfig-a005-20201209
i386 randconfig-a001-20201209
i386 randconfig-a002-20201209
i386 randconfig-a006-20201209
i386 randconfig-a003-20201209
x86_64   randconfig-a016-20201209
x86_64   randconfig-a012-20201209
x86_64   randconfig-a013-20201209
x86_64   randconfig-a014-20201209
x86_64   randconfig-a015-20201209
x86_64   randconfig-a011-20201209
i386 randconfig-a013-20201209
i386 randconfig-a014-20201209
i386 randconfig-a011-20201209
i386 randconfig-a015-20201209
i386

[RFC PATCH 12/12] [DO NOT MERGE] ARM: dts: sun8i: v831: add a device tree file for Y20GA

Yi Y20GA is an IP camera with QG2101A chip (a rebranded Allwinner V831).

Add a device tree for it.

Signed-off-by: Icenowy Zheng 
---
 arch/arm/boot/dts/Makefile|  3 +-
 arch/arm/boot/dts/sun8i-v831-yi-y20ga.dts | 53 +++
 2 files changed, 55 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/sun8i-v831-yi-y20ga.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ce66ffd5a1bb..2b2e93bb9ee2 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1212,7 +1212,8 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-t3-cqa3t-bv3.dtb \
sun8i-v3s-licheepi-zero.dtb \
sun8i-v3s-licheepi-zero-dock.dtb \
-   sun8i-v40-bananapi-m2-berry.dtb
+   sun8i-v40-bananapi-m2-berry.dtb \
+   sun8i-v831-yi-y20ga.dtb
 dtb-$(CONFIG_MACH_SUN9I) += \
sun9i-a80-optimus.dtb \
sun9i-a80-cubieboard4.dtb
diff --git a/arch/arm/boot/dts/sun8i-v831-yi-y20ga.dts 
b/arch/arm/boot/dts/sun8i-v831-yi-y20ga.dts
new file mode 100644
index ..16f4b6dbe0d2
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-v831-yi-y20ga.dts
@@ -0,0 +1,53 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2020 Icenowy Zheng 
+ */
+
+/dts-v1/;
+#include "sun8i-v831.dtsi"
+#include 
+
+/ {
+   model = "Yi Camera Y20GA";
+   compatible = "xiaoyi,y20ga", "allwinner,sun8i-v831";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   reg_vcc3v3: vcc3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+};
+
+ {
+   vmmc-supply = <_vcc3v3>;
+   cd-gpios = < 5 6 GPIO_ACTIVE_LOW>;
+   bus-width = <4>;
+   status = "okay";
+};
+
+ {
+   pinctrl-0 = <_qspi_pins>, <_cs_pin>;
+   pinctrl-names = "default";
+   status = "okay";
+
+   flash@0 {
+   compatible = "winbond,w25q128", "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <400>;
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_ph9_ph10_pins>;
+   status = "okay";
+};
-- 
2.28.0

[RFC PATCH 11/12] ARM: dts: sun8i: add DTSI file for V831

V831 is a new chip by Allwinner, and its functionality is a subset of
V833 (another new chip with the same die but larger pin count).

Add a DTSI file for V831.

Signed-off-by: Icenowy Zheng 
---
 arch/arm/boot/dts/sun8i-v831.dtsi | 244 ++
 1 file changed, 244 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun8i-v831.dtsi

diff --git a/arch/arm/boot/dts/sun8i-v831.dtsi 
b/arch/arm/boot/dts/sun8i-v831.dtsi
new file mode 100644
index ..7ddc4d33d8b2
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-v831.dtsi
@@ -0,0 +1,244 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2020 Icenowy Zheng 
+ */
+
+#include 
+#include 
+#include 
+
+/ {
+   interrupt-parent = <>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   compatible = "arm,cortex-a7";
+   device_type = "cpu";
+   reg = <0>;
+   clocks = < CLK_CPUX>;
+   };
+   };
+
+   osc24M: osc24M_clk {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <2400>;
+   clock-output-names = "osc24M";
+   };
+
+   timer {
+   compatible = "arm,armv7-timer";
+   interrupts = ,
+,
+,
+;
+   };
+
+   soc {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   ccu: clock@3001000 {
+   compatible = "allwinner,sun8i-v833-ccu";
+   reg = <0x03001000 0x1000>;
+   clocks = <>, < 0>, < 2>;
+   clock-names = "hosc", "losc", "iosc";
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+   };
+
+   watchdog: watchdog@30090a0 {
+   compatible = "allwinner,sun8i-v831-wdt",
+"allwinner,sun6i-a31-wdt";
+   reg = <0x030090a0 0x20>;
+   interrupts = ;
+   clocks = <>;
+   };
+
+   pio: pinctrl@300b000 {
+   compatible = "allwinner,sun8i-v831-pinctrl";
+   reg = <0x0300b000 0x400>;
+   interrupts = ,
+,
+,
+,
+,
+,
+;
+   clocks = < CLK_APB1>, <>, < 0>;
+   clock-names = "apb", "hosc", "losc";
+   gpio-controller;
+   #gpio-cells = <3>;
+   interrupt-controller;
+   #interrupt-cells = <3>;
+
+   mmc0_pins: mmc0-pins {
+   pins = "PF0", "PF1", "PF2", "PF3",
+  "PF4", "PF5";
+   function = "mmc0";
+   drive-strength = <30>;
+   bias-pull-up;
+   };
+
+   /omit-if-no-ref/
+   mmc1_pins: mmc1-pins {
+   pins = "PG0", "PG1", "PG2", "PG3",
+  "PG4", "PG5";
+   function = "mmc1";
+   drive-strength = <30>;
+   bias-pull-up;
+   };
+
+   /omit-if-no-ref/
+   spi0_qspi_pins: spi0-qspi-pins {
+   pins = "PC0", "PC2", "PC3", "PC4", "PC5";
+   function = "spi0";
+   };
+
+   /omit-if-no-ref/
+   spi0_cs_pin: spi0-cs-pin {
+   pins = "PC1";
+   function = "spi0";
+   };
+
+   uart0_ph9_ph10_pins: uart0-ph9-ph10-pins {
+   pins = "PH9", "PH10";
+   function = "uart0";
+   };
+   };
+
+   gic: interrupt-controller@3021000 {
+   compatible = "arm,gic-400";
+   reg = <0x03021000 0x1000>,
+ <0x03022000 0x2000>,
+ <0x03024000 0x2000>,
+ <0x03026000 0x2000>;
+   interrupts = ;
+   interrupt-controller;
+   #interrupt-cells = <3>;
+

[RFC PATCH 10/12] dt-bindings: spi: sun6i: add compatible for V831 SPI

V831 has a SPI controller similar to the H6 one.

Add a compatible string for it.

Cc: Mark Brown 
Cc: linux-...@vger.kernel.org
Signed-off-by: Icenowy Zheng 
---
H6 and V831 SPI controllers is not totally the same with H3: they have
QSPI support added. Here V831 compatible string is just added in
parallel with H6 one, but maybe we should make H6 SPI do not fallback to
H3 one, and add H6 one as fallback to V831?

 .../devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml 
b/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml
index 7866a655d81c..a620ff30033e 100644
--- a/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml
+++ b/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml
@@ -24,6 +24,7 @@ properties:
   - items:
   - enum:
   - allwinner,sun8i-r40-spi
+  - allwinner,sun8i-v831-spi
   - allwinner,sun50i-h6-spi
   - const: allwinner,sun8i-h3-spi
 
-- 
2.28.0

[PATCH v3] block: drop dead assignments in loop_init()

2020-12-11 Thread Lukas Bulwahn

Commit 8410d38c2552 ("loop: use __register_blkdev to allocate devices on
demand") simplified loop_init(); so computing the range of the block region
is not required anymore and can be dropped.

Drop dead assignments in loop_init().

As compilers will detect these unneeded assignments and optimize this,
the resulting object code is identical before and after this change.

No functional change. No change in object code.

Signed-off-by: Lukas Bulwahn 
---
v1 -> v2:
  - replaced if block with ternary operator after Julia's style comment

v2 -> v3:
  - use if instead of ternary following Jens' preference

Christoph, please ack.

Jens, please pick this minor non-urgent clean-up patch on your
block -next tree on top of Christoph's commit above.


 drivers/block/loop.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index d2ce1ddc192d..e5ff328f0917 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -2304,7 +2304,6 @@ MODULE_ALIAS("devname:loop-control");
 static int __init loop_init(void)
 {
int i, nr;
-   unsigned long range;
struct loop_device *lo;
int err;
 
@@ -2341,13 +2340,10 @@ static int __init loop_init(void)
 * /dev/loop-control interface, or be instantiated by accessing
 * a 'dead' device node.
 */
-   if (max_loop) {
+   if (max_loop)
nr = max_loop;
-   range = max_loop << part_shift;
-   } else {
+   else
nr = CONFIG_BLK_DEV_LOOP_MIN_COUNT;
-   range = 1UL << MINORBITS;
-   }
 
err = misc_register(_misc);
if (err < 0)
-- 
2.17.1

[rcu:dev.2020.12.10a] BUILD SUCCESS 3952b4a5d591b2052bf9700b6de783a0dceb6cc0

2020-12-11 Thread kernel test robot

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git  
dev.2020.12.10a
branch HEAD: 3952b4a5d591b2052bf9700b6de783a0dceb6cc0  squash! mm: Add 
mem_dump_obj() to print source of memory block

elapsed time: 724m

configs tested: 118
configs skipped: 2

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

gcc tested configs:
arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
powerpc linkstation_defconfig
sh apsh4a3a_defconfig
arm   omap1_defconfig
powerpc mpc512x_defconfig
microblazenommu_defconfig
powerpc   allnoconfig
openriscdefconfig
armpleb_defconfig
arm  collie_defconfig
arm   sunxi_defconfig
sh  urquell_defconfig
mips   mtx1_defconfig
powerpcmvme5100_defconfig
mips cobalt_defconfig
m68k allyesconfig
arm  gemini_defconfig
sh  rsk7269_defconfig
shapsh4ad0a_defconfig
m68km5272c3_defconfig
mips   sb1250_swarm_defconfig
arm   aspeed_g4_defconfig
arc haps_hs_defconfig
powerpcwarp_defconfig
sh   se7343_defconfig
parisc   alldefconfig
powerpcklondike_defconfig
powerpc mpc8560_ads_defconfig
arm assabet_defconfig
powerpc  mpc885_ads_defconfig
mips   xway_defconfig
powerpc  cm5200_defconfig
arm  footbridge_defconfig
mips  pistachio_defconfig
mips  maltaaprp_defconfig
xtensa virt_defconfig
xtensageneric_kc705_defconfig
sparcallyesconfig
powerpc  g5_defconfig
m68k   bvme6000_defconfig
nds32   defconfig
powerpc  pasemi_defconfig
mips cu1000-neo_defconfig
xtensasmp_lx200_defconfig
sh   se7619_defconfig
xtensa   allyesconfig
arm mv78xx0_defconfig
sh  sh7785lcr_32bit_defconfig
arm  simpad_defconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparc   defconfig
i386   tinyconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
i386 randconfig-a004-20201209
i386 randconfig-a005-20201209
i386 randconfig-a001-20201209
i386 randconfig-a002-20201209
i386 randconfig-a006-20201209
i386 randconfig-a003-20201209
x86_64   randconfig-a016-20201209
x86_64   randconfig-a012-20201209
x86_64   randconfig-a013-20201209
x86_64   randconfig-a014-20201209
x86_64   randconfig-a015-20201209
x86_64   randconfig-a011-20201209
i386 randconfig-a013-20201209
i386 randconfig-a014-20201209
i386 randconfig-a011-20201209
i386 randconfig-a015-20201209
i386 randconfig-a012-20201209
i386 randconfig-a016-20201209
riscv

[RFC PATCH 09/12] dt-bindings: watchdog: sunxi: add compatible string for V831/V833 WDT

V831/V833 has a watchdog similar to the ones on previous Allwinner SoCs
after sun6i.

Add a compatible string for it.

Cc: Wim Van Sebroeck 
Cc: Guenter Roeck 
Cc: linux-watch...@vger.kernel.org
Signed-off-by: Icenowy Zheng 
---
 .../devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml  | 3 +++
 1 file changed, 3 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml 
b/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml
index e8f226376108..2f3c350b0057 100644
--- a/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml
@@ -18,6 +18,9 @@ properties:
 oneOf:
   - const: allwinner,sun4i-a10-wdt
   - const: allwinner,sun6i-a31-wdt
+  - items:
+  - const: allwinner,sun8i-v831-wdt
+  - const: allwinner,sun6i-a31-wdt
   - items:
   - const: allwinner,sun50i-a64-wdt
   - const: allwinner,sun6i-a31-wdt
-- 
2.28.0

[RFC PATCH 08/12] dt-bindings: mmc: sunxi: add compatible strings for V831 MMC

V831 has MMC controllers similar to the ones on H6.

Add a compatible string for them.

The eMMC controller compatible is not added, because the eMMC controller
is not available on V831, only V833.

Cc: Ulf Hansson 
Cc: linux-...@vger.kernel.org
Signed-off-by: Icenowy Zheng 
---
 .../devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml   | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml 
b/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml
index e82c9a07b6fb..985586cb93b4 100644
--- a/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml
+++ b/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml
@@ -35,6 +35,9 @@ properties:
   - items:
   - const: allwinner,sun8i-r40-mmc
   - const: allwinner,sun50i-a64-mmc
+  - items:
+  - const: allwinner,sun8i-v831-mmc
+  - const: allwinner,sun50i-a64-mmc
   - items:
   - const: allwinner,sun50i-h5-emmc
   - const: allwinner,sun50i-a64-emmc
-- 
2.28.0

[rcu:dev.2020.12.11a] BUILD SUCCESS 915fc30b2c2c6f03d8fe36707ee0f908bb28dc0d

2020-12-11 Thread kernel test robot

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git  
dev.2020.12.11a
branch HEAD: 915fc30b2c2c6f03d8fe36707ee0f908bb28dc0d  doc: Remove obsolete 
rcutree.rcu_idle_lazy_gp_delay boot parameter

elapsed time: 722m

configs tested: 122
configs skipped: 2

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

gcc tested configs:
arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
powerpc linkstation_defconfig
sh apsh4a3a_defconfig
arm   omap1_defconfig
powerpc mpc512x_defconfig
microblazenommu_defconfig
powerpc   allnoconfig
openriscdefconfig
armpleb_defconfig
arm  collie_defconfig
arm   sunxi_defconfig
sh  urquell_defconfig
mips   mtx1_defconfig
powerpcmvme5100_defconfig
mips cobalt_defconfig
m68k allyesconfig
powerpc tqm8541_defconfig
sh  landisk_defconfig
powerpc   holly_defconfig
arm  exynos_defconfig
arm  gemini_defconfig
sh  rsk7269_defconfig
shapsh4ad0a_defconfig
m68km5272c3_defconfig
mips   sb1250_swarm_defconfig
arm   aspeed_g4_defconfig
arc haps_hs_defconfig
powerpcwarp_defconfig
sh   se7343_defconfig
parisc   alldefconfig
powerpcklondike_defconfig
powerpc mpc8560_ads_defconfig
arm assabet_defconfig
powerpc  mpc885_ads_defconfig
mips   xway_defconfig
powerpc  cm5200_defconfig
arm  footbridge_defconfig
mips  pistachio_defconfig
mips  maltaaprp_defconfig
xtensa virt_defconfig
xtensageneric_kc705_defconfig
sparcallyesconfig
powerpc  g5_defconfig
m68k   bvme6000_defconfig
nds32   defconfig
powerpc  pasemi_defconfig
mips cu1000-neo_defconfig
xtensasmp_lx200_defconfig
sh   se7619_defconfig
xtensa   allyesconfig
arm mv78xx0_defconfig
sh  sh7785lcr_32bit_defconfig
arm  simpad_defconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparc   defconfig
i386   tinyconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
i386 randconfig-a004-20201209
i386 randconfig-a005-20201209
i386 randconfig-a001-20201209
i386 randconfig-a002-20201209
i386 randconfig-a006-20201209
i386 randconfig-a003-20201209
x86_64   randconfig-a016-20201209
x86_64   randconfig-a012-20201209
x86_64   randconfig-a013-20201209
x86_64   randconfig-a014-20201209
x86_64   randconfig-a015-20201209
x86_64   randconfig-a011-20201209
i386 randconfig-a013-20201209
i386 randconfig-a014-20201209
i386

Re: [RESEND PATCH] ath11k: use MHI provided APIs to allocate and free MHI controller

2020-12-11 Thread Kalle Valo

Bhaumik Bhatt  wrote:

> Use MHI provided APIs to allocate and free MHI controller to
> improve MHI host driver handling. This also fixes a memory leak
> as the MHI controller was allocated but never freed.
> 
> Signed-off-by: Bhaumik Bhatt 
> Reviewed-by: Manivannan Sadhasivam 
> Signed-off-by: Kalle Valo 

Patch applied to ath-next branch of ath.git, thanks.

57449b07eafc ath11k: use MHI provided APIs to allocate and free MHI controller

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/1605634436-36506-1-git-send-email-bbh...@codeaurora.org/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH v3] ath10k: add option for chip-id based BDF selection

2020-12-11 Thread Kalle Valo

Abhishek Kumar  wrote:

> In some devices difference in chip-id should be enough to pick
> the right BDF. Add another support for chip-id based BDF selection.
> With this new option, ath10k supports 2 fallback options.
> 
> The board name with chip-id as option looks as follows
> board name 'bus=snoc,qmi-board-id=ff,qmi-chip-id=320'
> 
> Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.2.2-00696-QCAHLSWMTPL-1
> Tested-on: QCA6174 HW3.2 WLAN.RM.4.4.1-00157-QCARMSWPZ-1
> Signed-off-by: Abhishek Kumar 
> Reviewed-by: Douglas Anderson 
> Reviewed-by: Rakesh Pillai 
> Signed-off-by: Kalle Valo 

Patch applied to ath-next branch of ath.git, thanks.

2bc2b87bb35a ath10k: add option for chip-id based BDF selection

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/20201207231824.v3.1.Ia6b95087ca566f77423f3802a78b946f7b593ff5@changeid/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH] crypto: x86/crc32c-intel - Don't match some Zhaoxin CPUs

2020-12-11 Thread Tony W Wang-oc

On 11/12/2020 21:00, Peter Zijlstra wrote:
> On Fri, Dec 11, 2020 at 07:29:04PM +0800, Tony W Wang-oc wrote:
>> The driver crc32c-intel match CPUs supporting X86_FEATURE_XMM4_2.
>> On platforms with Zhaoxin CPUs supporting this X86 feature, When
>> crc32c-intel and crc32c-generic are both registered, system will
>> use crc32c-intel because its .cra_priority is greater than
>> crc32c-generic. This case expect to use crc32c-generic driver for
>> some Zhaoxin CPUs to get performance gain, So remove these Zhaoxin
>> CPUs support from crc32c-intel.
>>
>> Signed-off-by: Tony W Wang-oc 
>> ---
>>  arch/x86/crypto/crc32c-intel_glue.c | 8 
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/arch/x86/crypto/crc32c-intel_glue.c 
>> b/arch/x86/crypto/crc32c-intel_glue.c
>> index feccb52..6dafdae 100644
>> --- a/arch/x86/crypto/crc32c-intel_glue.c
>> +++ b/arch/x86/crypto/crc32c-intel_glue.c
>> @@ -222,8 +222,16 @@ MODULE_DEVICE_TABLE(x86cpu, crc32c_cpu_id);
>>  
>>  static int __init crc32c_intel_mod_init(void)
>>  {
>> +struct cpuinfo_x86 *c = _cpu_data;
>> +
>>  if (!x86_match_cpu(crc32c_cpu_id))
>>  return -ENODEV;
>> +
>> +if (c->x86_vendor == X86_VENDOR_ZHAOXIN || c->x86_vendor == 
>> X86_VENDOR_CENTAUR) {
>> +if (c->x86 == 0x6 || (c->x86 == 0x7 && c->x86_model <= 0x3b))
>> +return -ENODEV;
>> +}
> 
> Egads, why can't you use that x86_match_cpu() above, and also this
> really wants a comment on why you're excluding these chips. 

When doing lmbench3 Create and Delete file test on partitions with ext4
enabling metadata checksum, found using crc32c-generic driver could get
about 20% performance gain than using the driver crc32c-intel on these
chips.

Also, since
> (IIRC) ZHAOXIN is basically AND, shouldn't they also be listed?
> 
> That is; write it like:
> 
>   m = x86_match_cpu(crc32_cpu_id);
>   if (!m || !m->data)
>   return -ENODEV;
> 
> That way you can have positive and negative matches in the array
> (obviously the existing FEATURE test would need data=1 and be last).
> .
> 

Lot thanks for you suggestion, will list these chips in crc32c_cpu_id
and use x86_match_cpu:

 static const struct x86_cpu_id crc32c_cpu_id[] = {
+   X86_MATCH_VENDOR_FAM_FEATURE(ZHAOXIN, 0x6, X86_FEATURE_XMM4_2, 1),
+   X86_MATCH_VENDOR_FAM_MODEL_FEATURE(ZHAOXIN, 0x7, 0x1b,
X86_FEATURE_XMM4_2, 1),
+   X86_MATCH_VENDOR_FAM_MODEL_FEATURE(ZHAOXIN, 0x7, 0x3b,
X86_FEATURE_XMM4_2, 1),
+   X86_MATCH_VENDOR_FAM_FEATURE(CENTAUR, 0x6, X86_FEATURE_XMM4_2, 1),
+   X86_MATCH_VENDOR_FAM_MODEL_FEATURE(CENTAUR, 0x7, 0x1b,
X86_FEATURE_XMM4_2, 1),
+   X86_MATCH_VENDOR_FAM_MODEL_FEATURE(CENTAUR, 0x7, 0x3b,
X86_FEATURE_XMM4_2, 1),
X86_MATCH_FEATURE(X86_FEATURE_XMM4_2, NULL),
{}
 };
@@ -228,8 +234,10 @@ MODULE_DEVICE_TABLE(x86cpu, crc32c_cpu_id);

 static int __init crc32c_intel_mod_init(void)
 {
-   if (!x86_match_cpu(crc32c_cpu_id))
+   const struct x86_cpu_id *m = x86_match_cpu(crc32c_cpu_id);
+   if (!m || m->driver_data)
return -ENODEV;


sincerely
TonyWWangoc

Re: [PATCH] block: drop dead assignments in loop_init()

2020-12-11 Thread Joe Perches

On Fri, 2020-12-11 at 19:40 +0100, Lukas Bulwahn wrote:
> On Fri, Dec 11, 2020 at 7:23 PM Julia Lawall  wrote:
> > On Fri, 11 Dec 2020, Lukas Bulwahn wrote:
> > > Commit 8410d38c2552 ("loop: use __register_blkdev to allocate devices on
> > > demand") simplified loop_init(); so computing the range of the block 
> > > region
> > > is not required anymore and can be dropped.
> > > 
> > > Drop dead assignments in loop_init().
> > > 
> > > As compilers will detect these unneeded assignments and optimize this,
> > > the resulting object code is identical before and after this change.
> > > 
> > > No functional change. No change in object code.
> > 
> > It looks like some braces should be dropped too?

> I just rewrote it to:
> 
> nr = max_loop ? max_loop : CONFIG_BLK_DEV_LOOP_MIN_COUNT;

A relatively common gcc extension would use ?: like:

nr = max_loop ?: CONFIG_BLK_DEV_LOOP_MIN_COUNT;

[PATCH v2, 08/17] drm/mediatek: enable OVL_LAYER_SMI_ID_EN for multi-layer usecase

enable OVL_LAYER_SMI_ID_EN for multi-layer usecase

Signed-off-by: Yongqiang Niu 
---
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 8cf9f3b..97f8380 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -23,6 +23,7 @@
 #define DISP_REG_OVL_RST   0x0014
 #define DISP_REG_OVL_ROI_SIZE  0x0020
 #define DISP_REG_OVL_DATAPATH_CON  0x0024
+#define OVL_LAYER_SMI_ID_ENBIT(0)
 #define OVL_BGCLR_SEL_IN   BIT(2)
 #define DISP_REG_OVL_ROI_BGCLR 0x0028
 #define DISP_REG_OVL_SRC_CON   0x002c
@@ -61,6 +62,7 @@ struct mtk_disp_ovl_data {
unsigned int gmc_bits;
unsigned int layer_nr;
bool fmt_rgb565_is_0;
+   bool smi_id_en;
 };
 
 /**
@@ -115,7 +117,17 @@ static void mtk_ovl_disable_vblank(struct mtk_ddp_comp 
*comp)
 
 static void mtk_ovl_start(struct mtk_ddp_comp *comp)
 {
+   struct mtk_disp_ovl *ovl = comp_to_ovl(comp);
+
writel_relaxed(0x1, comp->regs + DISP_REG_OVL_EN);
+
+   if(ovl->data->smi_id_en) {
+   unsigned int reg;
+
+   reg = readl(comp->regs + DISP_REG_OVL_DATAPATH_CON);
+   reg = reg | OVL_LAYER_SMI_ID_EN;
+   writel_relaxed(reg, comp->regs + DISP_REG_OVL_DATAPATH_CON);
+   }
 }
 
 static void mtk_ovl_stop(struct mtk_ddp_comp *comp)
-- 
1.8.1.1.dirty

Re: [PATCH net-next] gve: simplify the gve code return expression

2020-12-11 Thread Jakub Kicinski

On Fri, 11 Dec 2020 16:37:06 +0800 Zheng Yongjun wrote:
> Simplify the return expression at diffrent gve_adminq.c file, simplify this 
> all.
> 
> Signed-off-by: Zheng Yongjun 

Does not apply, please rebase.

[PATCH v2, 17/17] arm64: dts: mt8192: add display node

add display node

Signed-off-by: Yongqiang Niu 
---
 arch/arm64/boot/dts/mediatek/mt8192.dtsi | 130 +++
 1 file changed, 130 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index 7c0c233..da681b0 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -17,6 +17,11 @@
#address-cells = <2>;
#size-cells = <2>;
 
+   aliases {
+   ovl_2l2 = _2l2;
+   rdma4 = 
+   };
+
clk26m: oscillator0 {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -614,9 +619,134 @@
mmsys: syscon@1400 {
compatible = "mediatek,mt8192-mmsys", "syscon";
reg = <0 0x1400 0 0x1000>;
+   mboxes = < 0 CMDQ_THR_PRIO_HIGHEST 1>,
+< 1 CMDQ_THR_PRIO_HIGHEST 1>;
+   mediatek,gce-client-reg = < SUBSYS_1400 0 
0x1000>;
#clock-cells = <1>;
};
 
+   mutex: mutex@14001000 {
+   compatible = "mediatek,mt8192-disp-mutex";
+   reg = <0 0x14001000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_MM_DISP_CONFIG>,
+< CLK_MM_26MHZ>,
+< CLK_MM_DISP_MUTEX0>;
+   mediatek,gce-events = 
,
+ 
;
+   };
+
+   ovl0: ovl@14005000 {
+   compatible = "mediatek,mt8192-disp-ovl";
+   reg = <0 0x14005000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_MM_DISP_OVL0>;
+   //iommus = < M4U_PORT_L0_OVL_RDMA0>,
+   //   < M4U_PORT_L0_OVL_RDMA0_HDR>;
+   //power-domains = < MT8192_POWER_DOMAIN_DISP>;
+   mediatek,gce-client-reg = < SUBSYS_1400 0x5000 
0x1000>;
+   };
+
+   ovl_2l0: ovl@14006000 {
+   compatible = "mediatek,mt8192-disp-ovl-2l";
+   reg = <0 0x14006000 0 0x1000>;
+   interrupts = ;
+   //power-domains = < MT8192_POWER_DOMAIN_DISP>;
+   clocks = < CLK_MM_DISP_OVL0_2L>;
+   //iommus = < M4U_PORT_L1_OVL_2L_RDMA0>,
+   //   < M4U_PORT_L1_OVL_2L_RDMA0_HDR>;
+   mediatek,gce-client-reg = < SUBSYS_1400 0x6000 
0x1000>;
+   };
+
+   rdma0: rdma@14007000 {
+   compatible = "mediatek,mt8192-disp-rdma";
+   reg = <0 0x14007000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_MM_DISP_RDMA0>;
+   //iommus = < M4U_PORT_L0_DISP_RDMA0>;
+   mediatek,rdma_fifo_size = <5120>;
+   //power-domains = < MT8192_POWER_DOMAIN_DISP>;
+   mediatek,gce-client-reg = < SUBSYS_1400 0x7000 
0x1000>;
+   };
+
+   color0: color@14009000 {
+   compatible = "mediatek,mt8192-disp-color",
+"mediatek,mt8173-disp-color";
+   reg = <0 0x14009000 0 0x1000>;
+   interrupts = ;
+   //power-domains = < MT8192_POWER_DOMAIN_DISP>;
+   clocks = < CLK_MM_DISP_COLOR0>;
+   mediatek,gce-client-reg = < SUBSYS_1400 0x9000 
0x1000>;
+   };
+
+   ccorr0: ccorr@1400a000 {
+   compatible = "mediatek,mt8192-disp-ccorr";
+   reg = <0 0x1400a000 0 0x1000>;
+   interrupts = ;
+   //power-domains = < MT8192_POWER_DOMAIN_DISP>;
+   clocks = < CLK_MM_DISP_CCORR0>;
+   mediatek,gce-client-reg = < SUBSYS_1400 0xa000 
0x1000>;
+   };
+
+   aal0: aal@1400b000 {
+   compatible = "mediatek,mt8192-disp-aal";
+   reg = <0 0x1400b000 0 0x1000>;
+   interrupts = ;
+   //power-domains = < MT8192_POWER_DOMAIN_DISP>;
+   clocks = < CLK_MM_DISP_AAL0>;
+   mediatek,gce-client-reg = < SUBSYS_1400 0xb000 
0x1000>;
+   };
+
+   gamma0: gamma@1400c000 {
+   compatible = "mediatek,mt8192-disp-gamma";
+   reg = <0 0x1400c000 0 0x1000>;
+   interrupts = ;
+   //power-domains = < MT8192_POWER_DOMAIN_DISP>;
+   clocks = < CLK_MM_DISP_GAMMA0>;
+

[PATCH v2, 16/17] drm/mediatek: add support for mediatek SOC MT8192

add support for mediatek SOC MT8192

Signed-off-by: Yongqiang Niu 
---
 drivers/gpu/drm/mediatek/mtk_disp_color.c |  6 
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c   | 20 +
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c  |  6 
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c| 35 ++
 drivers/gpu/drm/mediatek/mtk_drm_drv.c| 48 +++
 5 files changed, 115 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_color.c 
b/drivers/gpu/drm/mediatek/mtk_disp_color.c
index 3ae9c81..15389f8 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_color.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_color.c
@@ -152,11 +152,17 @@ static int mtk_disp_color_remove(struct platform_device 
*pdev)
.color_offset = DISP_COLOR_START_MT8173,
 };
 
+static const struct mtk_disp_color_data mt8192_color_driver_data = {
+   .color_offset = DISP_COLOR_START_MT8173,
+};
+
 static const struct of_device_id mtk_disp_color_driver_dt_match[] = {
{ .compatible = "mediatek,mt2701-disp-color",
  .data = _color_driver_data},
{ .compatible = "mediatek,mt8173-disp-color",
  .data = _color_driver_data},
+   { .compatible = "mediatek,mt8192-disp-color",
+ .data = _color_driver_data},
{},
 };
 MODULE_DEVICE_TABLE(of, mtk_disp_color_driver_dt_match);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 47ae98c..bcb455f 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -456,6 +456,22 @@ static int mtk_disp_ovl_remove(struct platform_device 
*pdev)
.fmt_rgb565_is_0 = true,
 };
 
+static const struct mtk_disp_ovl_data mt8192_ovl_driver_data = {
+   .addr = DISP_REG_OVL_ADDR_MT8173,
+   .gmc_bits = 10,
+   .layer_nr = 4,
+   .fmt_rgb565_is_0 = true,
+   .smi_id_en = true,
+};
+
+static const struct mtk_disp_ovl_data mt8192_ovl_2l_driver_data = {
+   .addr = DISP_REG_OVL_ADDR_MT8173,
+   .gmc_bits = 10,
+   .layer_nr = 2,
+   .fmt_rgb565_is_0 = true,
+   .smi_id_en = true,
+};
+
 static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
{ .compatible = "mediatek,mt2701-disp-ovl",
  .data = _ovl_driver_data},
@@ -465,6 +481,10 @@ static int mtk_disp_ovl_remove(struct platform_device 
*pdev)
  .data = _ovl_driver_data},
{ .compatible = "mediatek,mt8183-disp-ovl-2l",
  .data = _ovl_2l_driver_data},
+   { .compatible = "mediatek,mt8192-disp-ovl",
+ .data = _ovl_driver_data},
+   { .compatible = "mediatek,mt8192-disp-ovl-2l",
+ .data = _ovl_2l_driver_data},
{},
 };
 MODULE_DEVICE_TABLE(of, mtk_disp_ovl_driver_dt_match);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c 
b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 86e77c2..2b79af0 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -363,6 +363,10 @@ static int mtk_disp_rdma_remove(struct platform_device 
*pdev)
.fifo_size = 5 * SZ_1K,
 };
 
+static const struct mtk_disp_rdma_data mt8192_rdma_driver_data = {
+   .fifo_size = 5 * SZ_1K,
+};
+
 static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
{ .compatible = "mediatek,mt2701-disp-rdma",
  .data = _rdma_driver_data},
@@ -370,6 +374,8 @@ static int mtk_disp_rdma_remove(struct platform_device 
*pdev)
  .data = _rdma_driver_data},
{ .compatible = "mediatek,mt8183-disp-rdma",
  .data = _rdma_driver_data},
+   { .compatible = "mediatek,mt8192-disp-rdma",
+ .data = _rdma_driver_data},
{},
 };
 MODULE_DEVICE_TABLE(of, mtk_disp_rdma_driver_dt_match);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index de618a1..14105b3 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -27,6 +27,18 @@
 
 #define INT_MUTEX  BIT(1)
 
+#define MT8192_MUTEX_MOD_DISP_OVL0 0
+#define MT8192_MUTEX_MOD_DISP_OVL0_2L  1
+#define MT8192_MUTEX_MOD_DISP_RDMA02
+#define MT8192_MUTEX_MOD_DISP_COLOR0   4
+#define MT8192_MUTEX_MOD_DISP_CCORR0   5
+#define MT8192_MUTEX_MOD_DISP_AAL0 6
+#define MT8192_MUTEX_MOD_DISP_GAMMA0   7
+#define MT8192_MUTEX_MOD_DISP_POSTMASK08
+#define MT8192_MUTEX_MOD_DISP_DITHER0  9
+#define MT8192_MUTEX_MOD_DISP_OVL2_2L  16
+#define MT8192_MUTEX_MOD_DISP_RDMA417
+
 #define MT8183_MUTEX_MOD_DISP_RDMA00
 #define MT8183_MUTEX_MOD_DISP_RDMA11
 #define MT8183_MUTEX_MOD_DISP_OVL0 9
@@ -185,6 +197,20 @@ struct mtk_ddp {
[DDP_COMPONENT_WDMA0] = MT8183_MUTEX_MOD_DISP_WDMA0,
 };
 
+static const unsigned int mt8192_mutex_mod[DDP_COMPONENT_ID_MAX] = {
+   [DDP_COMPONENT_AAL0] = MT8192_MUTEX_MOD_DISP_AAL0,
+

[PATCH v2, 12/17] drm/mediatek: fix gamma size config

fix gamma size config

Fixes: e0a5d3370245 (drm/mediatek: Add GAMMA engine basic function)
Signed-off-by: Yongqiang Niu 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 00d5687..52b6fc7 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -297,7 +297,7 @@ static void mtk_gamma_config(struct mtk_ddp_comp *comp, 
unsigned int w,
 unsigned int h, unsigned int vrefresh,
 unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
 {
-   mtk_ddp_write(cmdq_pkt, h << 16 | w, comp, DISP_GAMMA_SIZE);
+   mtk_ddp_write(cmdq_pkt, w << 16 | h, comp, DISP_GAMMA_SIZE);
mtk_dither_set(comp, bpc, DISP_GAMMA_CFG, cmdq_pkt);
 }
 
-- 
1.8.1.1.dirty

[PATCH v2, 15/17] soc: mediatek: mmsys: add mt8192 mmsys support

add mt8192 mmsys support

Signed-off-by: Yongqiang Niu 
---
 drivers/soc/mediatek/mmsys/Makefile   |   1 +
 drivers/soc/mediatek/mmsys/mt8192-mmsys.c | 119 ++
 include/linux/soc/mediatek/mtk-mmsys.h|   1 +
 3 files changed, 121 insertions(+)
 create mode 100644 drivers/soc/mediatek/mmsys/mt8192-mmsys.c

diff --git a/drivers/soc/mediatek/mmsys/Makefile 
b/drivers/soc/mediatek/mmsys/Makefile
index 25eeb9e5..7508cd3 100644
--- a/drivers/soc/mediatek/mmsys/Makefile
+++ b/drivers/soc/mediatek/mmsys/Makefile
@@ -1,4 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0-only
 obj-$(CONFIG_MTK_MMSYS) += mt2701-mmsys.o
 obj-$(CONFIG_MTK_MMSYS) += mt8183-mmsys.o
+obj-$(CONFIG_MTK_MMSYS) += mt8192-mmsys.o
 obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o
diff --git a/drivers/soc/mediatek/mmsys/mt8192-mmsys.c 
b/drivers/soc/mediatek/mmsys/mt8192-mmsys.c
new file mode 100644
index 000..79cb33f
--- /dev/null
+++ b/drivers/soc/mediatek/mmsys/mt8192-mmsys.c
@@ -0,0 +1,119 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) 2020 MediaTek Inc.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MMSYS_OVL_MOUT_EN  0xf04
+#define DISP_OVL0_GO_BLEND BIT(0)
+#define DISP_OVL0_GO_BGBIT(1)
+#define DISP_OVL0_2L_GO_BLEND  BIT(2)
+#define DISP_OVL0_2L_GO_BG BIT(3)
+#define DISP_OVL1_2L_MOUT_EN   0xf08
+#define OVL1_2L_MOUT_EN_RDMA1  BIT(4)
+#define DISP_OVL0_2L_MOUT_EN   0xf18
+#define DISP_OVL0_MOUT_EN  0xf1c
+#define OVL0_MOUT_EN_DISP_RDMA0BIT(0)
+#define OVL0_MOUT_EN_OVL0_2L   BIT(4)
+#define DISP_RDMA0_SEL_IN  0xf2c
+#define RDMA0_SEL_IN_OVL0_2L   0x3
+#define DISP_RDMA0_SOUT_SEL0xf30
+#define RDMA0_SOUT_COLOR0  0x1
+#define DISP_CCORR0_SOUT_SEL   0xf34
+#define CCORR0_SOUT_AAL0   0x1
+#define DISP_AAL0_SEL_IN   0xf38
+#define AAL0_SEL_IN_CCORR0 0x1
+#define DISP_DITHER0_MOUT_EN   0xf3c
+#define DITHER0_MOUT_DSI0  BIT(0)
+#define DISP_DSI0_SEL_IN   0xf40
+#define DSI0_SEL_IN_DITHER00x1
+#define DISP_OVL2_2L_MOUT_EN   0xf4c
+#define OVL2_2L_MOUT_RDMA4 BIT(0)
+
+static unsigned int mtk_mmsys_ddp_mout_en(enum mtk_ddp_comp_id cur,
+ enum mtk_ddp_comp_id next,
+ unsigned int *addr)
+{
+   unsigned int value;
+
+   if (cur == DDP_COMPONENT_OVL_2L0 && next == DDP_COMPONENT_RDMA0) {
+   *addr = DISP_OVL0_2L_MOUT_EN;
+   value = OVL0_MOUT_EN_DISP_RDMA0;
+   } else if (cur == DDP_COMPONENT_OVL_2L2 && next == DDP_COMPONENT_RDMA4) 
{
+   *addr = DISP_OVL2_2L_MOUT_EN;
+   value = OVL2_2L_MOUT_RDMA4;
+   } else if (cur == DDP_COMPONENT_DITHER && next == DDP_COMPONENT_DSI0) {
+   *addr = DISP_DITHER0_MOUT_EN;
+   value = DITHER0_MOUT_DSI0;
+   } else {
+   value = 0;
+   }
+
+   return value;
+}
+
+static unsigned int mtk_mmsys_ddp_sel_in(enum mtk_ddp_comp_id cur,
+enum mtk_ddp_comp_id next,
+unsigned int *addr)
+{
+   unsigned int value;
+
+   if (cur == DDP_COMPONENT_OVL_2L0 && next == DDP_COMPONENT_RDMA0) {
+   *addr = DISP_RDMA0_SEL_IN;
+   value = RDMA0_SEL_IN_OVL0_2L;
+   } else if (cur == DDP_COMPONENT_CCORR && next == DDP_COMPONENT_AAL0) {
+   *addr = DISP_AAL0_SEL_IN;
+   value = AAL0_SEL_IN_CCORR0;
+   } else if (cur == DDP_COMPONENT_DITHER && next == DDP_COMPONENT_DSI0) {
+   *addr = DISP_DSI0_SEL_IN;
+   value = DSI0_SEL_IN_DITHER0;
+   } else {
+   value = 0;
+   }
+
+   return value;
+}
+
+static void mtk_mmsys_ddp_sout_sel(void __iomem *config_regs,
+  enum mtk_ddp_comp_id cur,
+  enum mtk_ddp_comp_id next)
+{
+   if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_COLOR0) {
+   writel_relaxed(RDMA0_SOUT_COLOR0, config_regs + 
DISP_RDMA0_SOUT_SEL);
+   } else if (cur == DDP_COMPONENT_CCORR && next == DDP_COMPONENT_AAL0) {
+   writel_relaxed(CCORR0_SOUT_AAL0, config_regs + 
DISP_CCORR0_SOUT_SEL);
+   }
+}
+
+static unsigned int mtk_mmsys_ovl_mout_en(enum mtk_ddp_comp_id cur,
+ enum mtk_ddp_comp_id next,
+ unsigned int *addr)
+{
+   int value = -1;
+
+   *addr = MMSYS_OVL_MOUT_EN;
+
+   if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_OVL_2L0)
+   value = DISP_OVL0_GO_BG;
+   else if (cur ==

[PATCH v2, 10/17] drm/mediatek: fix aal size config

fix aal size config

Fixes: 0664d1392c26 (drm/mediatek: Add AAL engine basic function)
Signed-off-by: Yongqiang Niu 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index be61d11..e7d481e0 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -33,8 +33,13 @@
 #define DISP_REG_UFO_START 0x
 
 #define DISP_AAL_EN0x
+#define DISP_AAL_CFG   0x0020
+#define AAL_RELAY_MODE BIT(0)
+#define AAL_ENGINE_EN  BIT(1)
 #define DISP_AAL_SIZE  0x0030
 
+#define DISP_AAL_OUTPUT_SIZE   0x04d8
+
 #define DISP_CCORR_EN  0x
 #define CCORR_EN   BIT(0)
 #define DISP_CCORR_CFG 0x0020
@@ -184,7 +189,11 @@ static void mtk_aal_config(struct mtk_ddp_comp *comp, 
unsigned int w,
   unsigned int h, unsigned int vrefresh,
   unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
 {
-   mtk_ddp_write(cmdq_pkt, h << 16 | w, comp, DISP_AAL_SIZE);
+   mtk_ddp_write(cmdq_pkt, w << 16 | h, comp, DISP_AAL_SIZE);
+   mtk_ddp_write(cmdq_pkt, w << 16 | h, comp, DISP_AAL_OUTPUT_SIZE);
+
+   mtk_ddp_write_mask(NULL, AAL_RELAY_MODE, comp, DISP_AAL_CFG,
+  AAL_RELAY_MODE | AAL_ENGINE_EN);
 }
 
 static void mtk_aal_start(struct mtk_ddp_comp *comp)
-- 
1.8.1.1.dirty

[PATCH v2, 06/17] drm/mediatek: add component RDMA4

This patch add component RDMA4

Signed-off-by: Yongqiang Niu 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
 include/linux/soc/mediatek/mtk-mmsys.h  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 4c91584..be61d11 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -441,6 +441,7 @@ struct mtk_ddp_comp_match {
[DDP_COMPONENT_RDMA0]   = { MTK_DISP_RDMA,  0, NULL },
[DDP_COMPONENT_RDMA1]   = { MTK_DISP_RDMA,  1, NULL },
[DDP_COMPONENT_RDMA2]   = { MTK_DISP_RDMA,  2, NULL },
+   [DDP_COMPONENT_RDMA4]   = { MTK_DISP_RDMA,  4, NULL },
[DDP_COMPONENT_UFOE]= { MTK_DISP_UFOE,  0, _ufoe },
[DDP_COMPONENT_WDMA0]   = { MTK_DISP_WDMA,  0, NULL },
[DDP_COMPONENT_WDMA1]   = { MTK_DISP_WDMA,  1, NULL },
diff --git a/include/linux/soc/mediatek/mtk-mmsys.h 
b/include/linux/soc/mediatek/mtk-mmsys.h
index 09ee424..aa4f60e 100644
--- a/include/linux/soc/mediatek/mtk-mmsys.h
+++ b/include/linux/soc/mediatek/mtk-mmsys.h
@@ -38,6 +38,7 @@ enum mtk_ddp_comp_id {
DDP_COMPONENT_RDMA0,
DDP_COMPONENT_RDMA1,
DDP_COMPONENT_RDMA2,
+   DDP_COMPONENT_RDMA4,
DDP_COMPONENT_UFOE,
DDP_COMPONENT_WDMA0,
DDP_COMPONENT_WDMA1,
-- 
1.8.1.1.dirty

[PATCH v2, 14/17] soc: mediatek: mmsys: Use function call for setting mmsys ovl mout register

Use function call for setting mmsys ovl mout register

Signed-off-by: Yongqiang Niu 
---
 drivers/soc/mediatek/mmsys/mtk-mmsys.c | 18 ++
 include/linux/soc/mediatek/mtk-mmsys.h |  3 +++
 2 files changed, 21 insertions(+)

diff --git a/drivers/soc/mediatek/mmsys/mtk-mmsys.c 
b/drivers/soc/mediatek/mmsys/mtk-mmsys.c
index cb76e64..2558b42 100644
--- a/drivers/soc/mediatek/mmsys/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mmsys/mtk-mmsys.c
@@ -78,6 +78,15 @@ void mtk_mmsys_ddp_connect(struct device *dev,
reg = readl_relaxed(mmsys->regs + addr) | value;
writel_relaxed(reg, mmsys->regs + addr);
}
+
+   if (!funcs->ovl_mout_en)
+   return;
+
+   value = funcs->ovl_mout_en(cur, next, );
+   if (value) {
+   reg = readl_relaxed(mmsys->regs + addr) | value;
+   writel_relaxed(reg, mmsys->regs + addr);
+   }
 }
 EXPORT_SYMBOL_GPL(mtk_mmsys_ddp_connect);
 
@@ -103,6 +112,15 @@ void mtk_mmsys_ddp_disconnect(struct device *dev,
reg = readl_relaxed(mmsys->regs + addr) & ~value;
writel_relaxed(reg, mmsys->regs + addr);
}
+
+   if (!funcs->ovl_mout_en)
+   return;
+
+   value = funcs->ovl_mout_en(cur, next, );
+   if (value) {
+   reg = readl_relaxed(mmsys->regs + addr) & ~value;
+   writel_relaxed(reg, mmsys->regs + addr);
+   }
 }
 EXPORT_SYMBOL_GPL(mtk_mmsys_ddp_disconnect);
 
diff --git a/include/linux/soc/mediatek/mtk-mmsys.h 
b/include/linux/soc/mediatek/mtk-mmsys.h
index aa4f60e..220203d 100644
--- a/include/linux/soc/mediatek/mtk-mmsys.h
+++ b/include/linux/soc/mediatek/mtk-mmsys.h
@@ -49,6 +49,9 @@ struct mtk_mmsys_conn_funcs {
u32 (*mout_en)(enum mtk_ddp_comp_id cur,
   enum mtk_ddp_comp_id next,
   unsigned int *addr);
+   u32 (*ovl_mout_en)(enum mtk_ddp_comp_id cur,
+  enum mtk_ddp_comp_id next,
+  unsigned int *addr);
u32 (*sel_in)(enum mtk_ddp_comp_id cur,
  enum mtk_ddp_comp_id next,
  unsigned int *addr);
-- 
1.8.1.1.dirty

[PATCH v2, 02/17] dt-bindings: mediatek: add CLK_MM_DISP_CONFIG control description for mt8192 display

add CLK_MM_DISP_CONFIG control description for mt8192 displa

Signed-off-by: Yongqiang Niu 
---
 Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
index 1972fa7..dfbec76 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
@@ -54,6 +54,9 @@ Required properties (all function blocks):
   DPI controller nodes have multiple clock inputs. These are documented in
   mediatek,dsi.txt and mediatek,dpi.txt, respectively.
   An exception is that the mt8183 mutex is always free running with no clocks 
property.
+  An exception is that the mt8192 display add 2 more 
clocks(CLK_MM_DISP_CONFIG, CLK_MM_26MHZ),
+  and these 2 clocks need enabled before display module work like mutex clock, 
so we add these
+  2 clocks controled same with mutex clock.
 
 Required properties (DMA function blocks):
 - compatible: Should be one of
-- 
1.8.1.1.dirty

[PATCH v2, 03/17] dt-bindings: mediatek: add description for mt8192 display

add description for mt8192 display

Signed-off-by: Yongqiang Niu 
---
 Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
index dfbec76..b4e62ae 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
@@ -44,7 +44,7 @@ Required properties (all function blocks):
"mediatek,-dpi"   - DPI controller, see 
mediatek,dpi.txt
"mediatek,-disp-mutex"- display mutex
"mediatek,-disp-od"   - overdrive
-  the supported chips are mt2701, mt7623, mt2712, mt8173 and mt8183.
+  the supported chips are mt2701, mt7623, mt2712, mt8173, mt8183 and mt8192.
 - reg: Physical base address and length of the function block register space
 - interrupts: The interrupt signal from the function block (required, except 
for
   merge and split function blocks).
-- 
1.8.1.1.dirty

[PATCH v2, 05/17] drm/mediatek: add component POSTMASK

This patch add component POSTMASK

Signed-off-by: Yongqiang Niu 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 31 +
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |  1 +
 include/linux/soc/mediatek/mtk-mmsys.h  |  1 +
 3 files changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 8938554..4c91584 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -60,6 +60,10 @@
 #define DISP_GAMMA_SIZE0x0030
 #define DISP_GAMMA_LUT 0x0700
 
+#define DISP_POSTMASK_EN   0x
+#define DISP_POSTMASK_CFG  0x0020
+#define DISP_POSTMASK_SIZE 0x0030
+
 #define LUT_10BIT_MASK 0x03ff
 
 #define OD_RELAYMODE   BIT(0)
@@ -321,6 +325,24 @@ static void mtk_gamma_set(struct mtk_ddp_comp *comp,
}
 }
 
+static void mtk_postmask_config(struct mtk_ddp_comp *comp, unsigned int w,
+ unsigned int h, unsigned int vrefresh,
+ unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
+{
+   mtk_ddp_write(cmdq_pkt, w << 16 | h, comp, DISP_POSTMASK_SIZE);
+   mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, comp, DISP_POSTMASK_CFG);
+}
+
+static void mtk_postmask_start(struct mtk_ddp_comp *comp)
+{
+   writel(DITHER_EN, comp->regs + DISP_POSTMASK_EN);
+}
+
+static void mtk_postmask_stop(struct mtk_ddp_comp *comp)
+{
+   writel_relaxed(0x0, comp->regs + DISP_POSTMASK_EN);
+}
+
 static const struct mtk_ddp_comp_funcs ddp_aal = {
.gamma_set = mtk_gamma_set,
.config = mtk_aal_config,
@@ -348,6 +370,12 @@ static void mtk_gamma_set(struct mtk_ddp_comp *comp,
.stop = mtk_gamma_stop,
 };
 
+static const struct mtk_ddp_comp_funcs ddp_postmask = {
+   .config = mtk_postmask_config,
+   .start = mtk_postmask_start,
+   .stop = mtk_postmask_stop,
+};
+
 static const struct mtk_ddp_comp_funcs ddp_od = {
.config = mtk_od_config,
.start = mtk_od_start,
@@ -374,6 +402,7 @@ static void mtk_gamma_set(struct mtk_ddp_comp *comp,
[MTK_DISP_MUTEX] = "mutex",
[MTK_DISP_OD] = "od",
[MTK_DISP_BLS] = "bls",
+   [MTK_DISP_POSTMASK] = "postmask",
 };
 
 struct mtk_ddp_comp_match {
@@ -404,6 +433,8 @@ struct mtk_ddp_comp_match {
[DDP_COMPONENT_OVL_2L0] = { MTK_DISP_OVL_2L,0, NULL },
[DDP_COMPONENT_OVL_2L1] = { MTK_DISP_OVL_2L,1, NULL },
[DDP_COMPONENT_OVL_2L2] = { MTK_DISP_OVL_2L,2, NULL },
+   [DDP_COMPONENT_POSTMASK0]
+   = { MTK_DISP_POSTMASK,  0, _postmask },
[DDP_COMPONENT_PWM0]= { MTK_DISP_PWM,   0, NULL },
[DDP_COMPONENT_PWM1]= { MTK_DISP_PWM,   1, NULL },
[DDP_COMPONENT_PWM2]= { MTK_DISP_PWM,   2, NULL },
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index 5aa52b7..1a55496 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -29,6 +29,7 @@ enum mtk_ddp_comp_type {
MTK_DISP_UFOE,
MTK_DSI,
MTK_DPI,
+   MTK_DISP_POSTMASK,
MTK_DISP_PWM,
MTK_DISP_MUTEX,
MTK_DISP_OD,
diff --git a/include/linux/soc/mediatek/mtk-mmsys.h 
b/include/linux/soc/mediatek/mtk-mmsys.h
index 42476c2..09ee424 100644
--- a/include/linux/soc/mediatek/mtk-mmsys.h
+++ b/include/linux/soc/mediatek/mtk-mmsys.h
@@ -31,6 +31,7 @@ enum mtk_ddp_comp_id {
DDP_COMPONENT_OVL_2L1,
DDP_COMPONENT_OVL_2L2,
DDP_COMPONENT_OVL1,
+   DDP_COMPONENT_POSTMASK0,
DDP_COMPONENT_PWM0,
DDP_COMPONENT_PWM1,
DDP_COMPONENT_PWM2,
-- 
1.8.1.1.dirty

[PATCH v2, 07/17] drm/mediatek: add disp config and mm 26mhz clock into mutex device

there are 2 more clock need enable for display.
parser these clock when mutex device probe,
enable and disable when mutex on/off

Signed-off-by: Yongqiang Niu 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 49 --
 1 file changed, 41 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 60788c1..de618a1 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -118,7 +118,7 @@ struct mtk_ddp_data {
 
 struct mtk_ddp {
struct device   *dev;
-   struct clk  *clk;
+   struct clk  *clk[3];
void __iomem*regs;
struct mtk_disp_mutex   mutex[10];
const struct mtk_ddp_data   *data;
@@ -257,14 +257,39 @@ int mtk_disp_mutex_prepare(struct mtk_disp_mutex *mutex)
 {
struct mtk_ddp *ddp = container_of(mutex, struct mtk_ddp,
   mutex[mutex->id]);
-   return clk_prepare_enable(ddp->clk);
+   int ret;
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(ddp->clk); i++) {
+   if (IS_ERR(ddp->clk[i]))
+   continue;
+   ret = clk_prepare_enable(ddp->clk[i]);
+   if (ret) {
+   pr_err("failed to enable clock, err %d. i:%d\n",
+   ret, i);
+   goto err;
+   }
+   }
+
+   return 0;
+
+err:
+   while (--i >= 0)
+   clk_disable_unprepare(ddp->clk[i]);
+   return ret;
 }
 
 void mtk_disp_mutex_unprepare(struct mtk_disp_mutex *mutex)
 {
struct mtk_ddp *ddp = container_of(mutex, struct mtk_ddp,
   mutex[mutex->id]);
-   clk_disable_unprepare(ddp->clk);
+   int i;
+
+for (i = 0; i < ARRAY_SIZE(ddp->clk); i++) {
+   if (IS_ERR(ddp->clk[i]))
+   continue;
+   clk_disable_unprepare(ddp->clk[i]);
+   }
 }
 
 void mtk_disp_mutex_add_comp(struct mtk_disp_mutex *mutex,
@@ -415,11 +440,19 @@ static int mtk_ddp_probe(struct platform_device *pdev)
ddp->data = of_device_get_match_data(dev);
 
if (!ddp->data->no_clk) {
-   ddp->clk = devm_clk_get(dev, NULL);
-   if (IS_ERR(ddp->clk)) {
-   if (PTR_ERR(ddp->clk) != -EPROBE_DEFER)
-   dev_err(dev, "Failed to get clock\n");
-   return PTR_ERR(ddp->clk);
+   int ret;
+
+   for (i = 0; i < ARRAY_SIZE(ddp->clk); i++) {
+   ddp->clk[i] = of_clk_get(dev->of_node, i);
+
+   if (IS_ERR(ddp->clk[i])) {
+   ret = PTR_ERR(ddp->clk[i]);
+   if (ret != EPROBE_DEFER)
+   dev_err(dev, "Failed to get clock %d\n",
+   ret);
+
+   return ret;
+   }
}
}
 
-- 
1.8.1.1.dirty

[PATCH v2, 04/17] drm/mediatek: add component OVL_2L2

This patch add component OVL_2L2

Signed-off-by: Yongqiang Niu 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
 include/linux/soc/mediatek/mtk-mmsys.h  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 8eba44b..8938554 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -403,6 +403,7 @@ struct mtk_ddp_comp_match {
[DDP_COMPONENT_OVL1]= { MTK_DISP_OVL,   1, NULL },
[DDP_COMPONENT_OVL_2L0] = { MTK_DISP_OVL_2L,0, NULL },
[DDP_COMPONENT_OVL_2L1] = { MTK_DISP_OVL_2L,1, NULL },
+   [DDP_COMPONENT_OVL_2L2] = { MTK_DISP_OVL_2L,2, NULL },
[DDP_COMPONENT_PWM0]= { MTK_DISP_PWM,   0, NULL },
[DDP_COMPONENT_PWM1]= { MTK_DISP_PWM,   1, NULL },
[DDP_COMPONENT_PWM2]= { MTK_DISP_PWM,   2, NULL },
diff --git a/include/linux/soc/mediatek/mtk-mmsys.h 
b/include/linux/soc/mediatek/mtk-mmsys.h
index 4b6c514..42476c2 100644
--- a/include/linux/soc/mediatek/mtk-mmsys.h
+++ b/include/linux/soc/mediatek/mtk-mmsys.h
@@ -29,6 +29,7 @@ enum mtk_ddp_comp_id {
DDP_COMPONENT_OVL0,
DDP_COMPONENT_OVL_2L0,
DDP_COMPONENT_OVL_2L1,
+   DDP_COMPONENT_OVL_2L2,
DDP_COMPONENT_OVL1,
DDP_COMPONENT_PWM0,
DDP_COMPONENT_PWM1,
-- 
1.8.1.1.dirty

[PATCH v2, 11/17] drm/mediatek: fix dither size config

fix dither size config

Fixes: 450aa87c7353 (drm/mediatek: add component DITHER)
Signed-off-by: Yongqiang Niu 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index e7d481e0..00d5687 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -279,7 +279,7 @@ static void mtk_dither_config(struct mtk_ddp_comp *comp, 
unsigned int w,
  unsigned int h, unsigned int vrefresh,
  unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
 {
-   mtk_ddp_write(cmdq_pkt, h << 16 | w, comp, DISP_DITHER_SIZE);
+   mtk_ddp_write(cmdq_pkt, w << 16 | h, comp, DISP_DITHER_SIZE);
mtk_ddp_write(cmdq_pkt, DITHER_RELAY_MODE, comp, DISP_DITHER_CFG);
 }
 
-- 
1.8.1.1.dirty

[PATCH v2, 13/17] drm/mediatek: fix ccorr size config

fix ccorr size config

Fixes: cefb6abfcc1c (drm/mediatek: add ddp component CCORR)
Signed-off-by: Yongqiang Niu 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 52b6fc7..c11de66 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -210,7 +210,7 @@ static void mtk_ccorr_config(struct mtk_ddp_comp *comp, 
unsigned int w,
 unsigned int h, unsigned int vrefresh,
 unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
 {
-   mtk_ddp_write(cmdq_pkt, h << 16 | w, comp, DISP_CCORR_SIZE);
+   mtk_ddp_write(cmdq_pkt, w << 16 | h, comp, DISP_CCORR_SIZE);
mtk_ddp_write(cmdq_pkt, CCORR_ENGINE_EN, comp, DISP_CCORR_CFG);
 }
 
-- 
1.8.1.1.dirty

[PATCH v2, 09/17] drm/mediatek: check if fb is null

It's possible that state->base.fb is null. Add a check before access its
format.

Fixes: b6b1bb980ec4 ( drm/mediatek: Turn off Alpha bit when plane format has no 
alpha)
Signed-off-by: Yongqiang Niu 
---
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 97f8380..47ae98c 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -278,7 +278,7 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp *comp, 
unsigned int idx,
}
 
con = ovl_fmt_convert(ovl, fmt);
-   if (state->base.fb->format->has_alpha)
+   if (state->base.fb && state->base.fb->format->has_alpha)
con |= OVL_CON_AEN | OVL_CON_ALPHA;
 
if (pending->rotation & DRM_MODE_REFLECT_Y) {
-- 
1.8.1.1.dirty

[PATCH v2, 01/17] dt-bindings: mediatek: add description for postmask

add description for postmask

Signed-off-by: Yongqiang Niu 
---
 Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
index 5ca693a..1972fa7 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
@@ -37,6 +37,7 @@ Required properties (all function blocks):
"mediatek,-disp-aal"  - adaptive ambient light 
controller
"mediatek,-disp-gamma"- gamma correction
"mediatek,-disp-merge"- merge streams from two RDMA 
sources
+   "mediatek,-disp-postmask" - post mask
"mediatek,-disp-split"- split stream to two encoders
"mediatek,-disp-ufoe" - data compression engine
"mediatek,-dsi"   - DSI controller, see 
mediatek,dsi.txt
-- 
1.8.1.1.dirty

[PATCH v2, 00/17] drm/mediatek: add support for mediatek SOC MT8192

This series are based on 5.10-rc1 and provid 17 patch
to support mediatek SOC MT8192

Changes in v2:
- base mmsys
https://patchwork.kernel.org/project/linux-mediatek/cover/1607506379-10998-1-git-send-email-yongqiang@mediatek.com/
- base mt8192 gce dtbinding file
https://patchwork.kernel.org/project/linux-mediatek/patch/1607141728-17307-2-git-send-email-yongqiang@mediatek.com/
- add dt-bindings description for post mask
- add dt-bindings description for mt8192 display
- fix some comment in v1
- add mt8192 mmsys function call

Changes in v1:
- add some more ddp component
- add mt8192 mmsys support
- add ovl mount on support
- add 2 more clock into mutex device
- fix ovl smi_id_en and fb null software bug
- fix ddp compoent size config bug
- add mt8192 drm support
- add ddp bypass shadow register function
- add 8192 dts description

Yongqiang Niu (17):
  dt-bindings: mediatek: add description for postmask
  dt-bindings: mediatek: add CLK_MM_DISP_CONFIG control description for
mt8192 display
  dt-bindings: mediatek: add description for mt8192 display
  drm/mediatek: add component OVL_2L2
  drm/mediatek: add component POSTMASK
  drm/mediatek: add component RDMA4
  drm/mediatek: add disp config and mm 26mhz clock into mutex device
  drm/mediatek: enable OVL_LAYER_SMI_ID_EN for multi-layer usecase
  drm/mediatek: check if fb is null
  drm/mediatek: fix aal size config
  drm/mediatek: fix dither size config
  drm/mediatek: fix gamma size config
  drm/mediatek: fix ccorr size config
  soc: mediatek: mmsys: Use function call for setting mmsys ovl mout
register
  soc: mediatek: mmsys: add mt8192 mmsys support
  drm/mediatek: add support for mediatek SOC MT8192
  arm64: dts: mt8192: add display node

 .../bindings/display/mediatek/mediatek,disp.txt|   6 +-
 arch/arm64/boot/dts/mediatek/mt8192.dtsi   | 130 +
 drivers/gpu/drm/mediatek/mtk_disp_color.c  |   6 +
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c|  34 +-
 drivers/gpu/drm/mediatek/mtk_disp_rdma.c   |   6 +
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c |  84 +++--
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c|  50 +++-
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h|   1 +
 drivers/gpu/drm/mediatek/mtk_drm_drv.c |  48 
 drivers/soc/mediatek/mmsys/Makefile|   1 +
 drivers/soc/mediatek/mmsys/mt8192-mmsys.c  | 119 +++
 drivers/soc/mediatek/mmsys/mtk-mmsys.c |  18 +++
 include/linux/soc/mediatek/mtk-mmsys.h |   7 ++
 13 files changed, 496 insertions(+), 14 deletions(-)
 create mode 100644 drivers/soc/mediatek/mmsys/mt8192-mmsys.c

-- 
1.8.1.1.dirty

[RFC PATCH 07/12] rtc: sun6i: add compatible string for V831/V833 RTC

These chips share the same die, and the RTC block is similar to H6
one, but with functionality of dividing 24M clock to get 32k (useful for
32k clock output).

Add compatible string for it. The special clock divider is TODO.

Cc: Alessandro Zummo 
Cc: Alexandre Belloni 
Cc: linux-...@vger.kernel.org
Signed-off-by: Icenowy Zheng 
---
 drivers/rtc/rtc-sun6i.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index e2b8b150bcb4..c9a1f2319f92 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -378,6 +378,23 @@ static void __init sun50i_h6_rtc_clk_init(struct 
device_node *node)
 CLK_OF_DECLARE_DRIVER(sun50i_h6_rtc_clk, "allwinner,sun50i-h6-rtc",
  sun50i_h6_rtc_clk_init);
 
+static const struct sun6i_rtc_clk_data sun8i_v831_rtc_data = {
+   .rc_osc_rate = 1600,
+   .fixed_prescaler = 32,
+   .has_prescaler = 1,
+   .has_out_clk = 1,
+   .export_iosc = 1,
+   .has_losc_en = 1,
+   .has_auto_swt = 1,
+};
+
+static void __init sun8i_v831_rtc_clk_init(struct device_node *node)
+{
+   sun6i_rtc_clk_init(node, _v831_rtc_data);
+}
+CLK_OF_DECLARE_DRIVER(sun8i_v831_rtc_clk, "allwinner,sun8i-v831-rtc",
+ sun8i_v831_rtc_clk_init);
+
 /*
  * The R40 user manual is self-conflicting on whether the prescaler is
  * fixed or configurable. The clock diagram shows it as fixed, but there
@@ -745,6 +762,7 @@ static const struct of_device_id sun6i_rtc_dt_ids[] = {
{ .compatible = "allwinner,sun8i-h3-rtc" },
{ .compatible = "allwinner,sun8i-r40-rtc" },
{ .compatible = "allwinner,sun8i-v3-rtc" },
+   { .compatible = "allwinner,sun8i-v831-rtc" },
{ .compatible = "allwinner,sun50i-h5-rtc" },
{ .compatible = "allwinner,sun50i-h6-rtc" },
{ /* sentinel */ },
-- 
2.28.0

[RFC PATCH 06/12] dt-bindings: rtc: sun6i: add compatible string for V831/V833 RTC

V831/V833 SoCs (the same die) have a RTC block similar to the one in H6,
but allow to generate the osc32k clock from osc24M.

Add a new compatible string for that.

The functionality of dividing osc24M to generate osc32k is still TODO.

Cc: Alessandro Zummo 
Cc: Alexandre Belloni 
Cc: linux-...@vger.kernel.org
Signed-off-by: Icenowy Zheng 
---
 .../devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml| 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml 
b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
index 37c2a601c3fa..6e3a3b14db7b 100644
--- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
@@ -21,6 +21,7 @@ properties:
   - const: allwinner,sun8i-h3-rtc
   - const: allwinner,sun8i-r40-rtc
   - const: allwinner,sun8i-v3-rtc
+  - const: allwinner,sun8i-v831-rtc
   - const: allwinner,sun50i-h5-rtc
   - items:
   - const: allwinner,sun50i-a64-rtc
@@ -97,6 +98,7 @@ allOf:
   properties:
 compatible:
   contains:
+const: allwinner,sun8i-v831-rtc
 const: allwinner,sun50i-h6-rtc
 
 then:
-- 
2.28.0

Response Required

2020-12-11 Thread Moussa

Greeetings from Mali. I am sorry for contacting you like this but 
I do have a very urgent matter that I want to discuss with you. 
Before I proceed, I want you to keep an open mind while reading 
this proposal. My name is Moussa Traore, I am the Personal 
Assistant to Mr. Issa Saley Maiga who was the head of the civil 
aviation agency in Mali during the tenure of Ibrahim Boubacar 
Keïta, the former president of Mali. His tenure was overtaken by 
the military during a coup d'etat. I am sure you would have read 
about this in your country because it was covered by the 
international news agencies worldwide.

Anyway, my boss was also affected by the coup d'etat and he was 
arrested along with other high profile politicians. Also, all of 
his local assets (bother property and financial assets) were 
seized by the Government. Due to this situation, my boss belives 
that he is at risk and he is now very scared for the safety of 
his family especially his wife and kids. In order to ensure that 
his family is taken care of and protected incase anything happens 
to him, he has asked me to help him find a foreign investor who 
can help him accommodate and manage the finanical assets that he 
has in Europe. These assets was secured with the help of a proxy 
and it is currently held with an offshore financial bank so it is 
safe so secure. Also, the Government of his country do not know 
of this asset hence why they are unable to seize it as they have 
done his other assets.

My proposal to you is for you to help us manage these funds, and 
invest it in lucrative projects in your country that will yeild 
good profits. You also do not have to worry about if this is safe 
or not because everything will be handled in a legal and 
transparent manner. You will also be handosmely rewarded for your 
help if you decide to work with us. If this proposal interests 
you, please kindly respond so that I can give you more details. I 
hope to hear from you soon.

Regards,

Moussa.

Re: [PATCH v17 3/3] bus: mhi: Add userspace client interface driver

2020-12-11 Thread Jakub Kicinski

On Fri, 11 Dec 2020 11:37:34 -0600 Dan Williams wrote:
> Just to re-iterate: QMI ~= AT commands ~= MBIM (not quite, but same
> level)
> 
> We already do QMI-over-USB, or AT-over-CDC-ACM. This is QMI-over-MHI.

Why do we need a different QMI-over-X for every X? If you say there 
are already chardev interfaces to configure WWAN why not provide one 
of those?

> It's not networking data plane. It's WWAN device configuration.

Ack. Not that network config doesn't fall under networking, but eh.
I wonder - did DaveM ever ack this, or was it just out of his sight
enough, behind the cdev, to never trigger a nack?

> There are no current kernel APIs for this, and I really don't think we
> want there to be. The API surface is *huge* and we definitely don't
> want that in-kernel.

It is what it is today for WWAN. I don't think anyone in the
development community or among users is particularly happy about
the situation. Which makes it rather self evident why there is 
so much apprehension about this patch set. It's going to be 
a user space channel for everything Qualcomm - AI accelerator etc.
Widening the WWAN status quo to more device types.

[RFC PATCH 05/12] pinctrl: sunxi: add pinctrl driver for V831/V833

V831/V833 are new chips from Allwinner. They're the same die with
different package.

Add a pinctrl driver for them.

The difference between V831/V833 pinctrl is implemented based on the
user manual.

Cc: Linus Walleij 
Cc: linux-g...@vger.kernel.org
Signed-off-by: Icenowy Zheng 
---
 drivers/pinctrl/sunxi/Kconfig  |   5 +
 drivers/pinctrl/sunxi/Makefile |   1 +
 drivers/pinctrl/sunxi/pinctrl-sun8i-v83x.c | 743 +
 drivers/pinctrl/sunxi/pinctrl-sunxi.h  |   2 +
 4 files changed, 751 insertions(+)
 create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun8i-v83x.c

diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
index 593293584ecc..fc13335a3eda 100644
--- a/drivers/pinctrl/sunxi/Kconfig
+++ b/drivers/pinctrl/sunxi/Kconfig
@@ -73,6 +73,11 @@ config PINCTRL_SUN8I_V3S
default MACH_SUN8I
select PINCTRL_SUNXI
 
+config PINCTRL_SUN8I_V83X
+   bool "Support for the Allwinner V831/V833 PIO"
+   default MACH_SUN8I
+   select PINCTRL_SUNXI
+
 config PINCTRL_SUN9I_A80
bool "Support for the Allwinner A80 PIO"
default MACH_SUN9I
diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
index 8b7ff0dc3bdf..8bcca109e942 100644
--- a/drivers/pinctrl/sunxi/Makefile
+++ b/drivers/pinctrl/sunxi/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_PINCTRL_SUN8I_A83T_R)+= 
pinctrl-sun8i-a83t-r.o
 obj-$(CONFIG_PINCTRL_SUN8I_H3) += pinctrl-sun8i-h3.o
 obj-$(CONFIG_PINCTRL_SUN8I_H3_R)   += pinctrl-sun8i-h3-r.o
 obj-$(CONFIG_PINCTRL_SUN8I_V3S)+= pinctrl-sun8i-v3s.o
+obj-$(CONFIG_PINCTRL_SUN8I_V83X)   += pinctrl-sun8i-v83x.o
 obj-$(CONFIG_PINCTRL_SUN50I_H5)+= pinctrl-sun50i-h5.o
 obj-$(CONFIG_PINCTRL_SUN50I_H6)+= pinctrl-sun50i-h6.o
 obj-$(CONFIG_PINCTRL_SUN50I_H6_R)  += pinctrl-sun50i-h6-r.o
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun8i-v83x.c 
b/drivers/pinctrl/sunxi/pinctrl-sun8i-v83x.c
new file mode 100644
index ..19d035dcebbf
--- /dev/null
+++ b/drivers/pinctrl/sunxi/pinctrl-sun8i-v83x.c
@@ -0,0 +1,743 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Icenowy Zheng 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "pinctrl-sunxi.h"
+
+static const struct sunxi_desc_pin sun8i_v83x_pins[] = {
+   /* Hole */
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 0),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION_VARIANT(0x3,
+"mmc2",/* DS */
+PINCTRL_SUN8I_V833),
+ SUNXI_FUNCTION(0x4, "spi0"),  /* CLK */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)),
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 1),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION_VARIANT(0x3,
+"mmc2",/* RST */
+PINCTRL_SUN8I_V833),
+ SUNXI_FUNCTION(0x4, "spi0"),  /* CS0 */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)),
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 2),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION_VARIANT(0x3,
+"mmc2",/* CLK */
+PINCTRL_SUN8I_V833),
+ SUNXI_FUNCTION(0x4, "spi0"),  /* MOSI */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)),
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 3),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION_VARIANT(0x3,
+"mmc2",/* CMD */
+PINCTRL_SUN8I_V833),
+ SUNXI_FUNCTION(0x4, "spi0"),  /* MISO */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 3)),
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 4),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION_VARIANT(0x3,
+"mmc2",/* WP */
+PINCTRL_SUN8I_V833),
+ SUNXI_FUNCTION(0x4, "spi0"),  /* D3 */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 4)),
+   SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 5),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION_VARIANT(0x3,
+"mmc2",/* HOLD */
+PINCTRL_SUN8I_V833),
+ SUNXI_FUNCTION(0x4, "spi0"),  /* D4 */
+ SUNXI_FUNCTION_IRQ_BANK(0x6,

[RFC PATCH 04/12] dt-bindings: pinctrl: sunxi: add compatible for V831/V833 pinctrl

V831/V833 are a pair of new Allwinner chips. The difference between them
is similar to V3s/V3, but the chip design is similar to newer Allwinner
chips started from H6.

Add compatible strings for V831/V833 pinctrl.

Cc: Linus Walleij 
Cc: linux-g...@vger.kernel.org
Signed-off-by: Icenowy Zheng 
---
 .../bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml | 4 
 1 file changed, 4 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml 
b/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml
index 5240487dfe50..3d6855856594 100644
--- a/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml
@@ -44,6 +44,8 @@ properties:
   - allwinner,sun8i-r40-pinctrl
   - allwinner,sun8i-v3-pinctrl
   - allwinner,sun8i-v3s-pinctrl
+  - allwinner,sun8i-v831-pinctrl
+  - allwinner,sun8i-v833-pinctrl
   - allwinner,sun9i-a80-pinctrl
   - allwinner,sun9i-a80-r-pinctrl
   - allwinner,sun50i-a64-pinctrl
@@ -189,6 +191,8 @@ allOf:
   enum:
 - allwinner,sun8i-a23-pinctrl
 - allwinner,sun8i-a83t-pinctrl
+- allwinner,sun8i-v831-pinctrl
+- allwinner,sun8i-v833-pinctrl
 - allwinner,sun50i-a64-pinctrl
 - allwinner,sun50i-h5-pinctrl
 - allwinner,suniv-f1c100s-pinctrl
-- 
2.28.0

[RFC PATCH 03/12] clk: sunxi-ng: add CCU driver for V831/V833

V831/V833 are new chips from Allwinner targeting camera market. The
difference between them is similar to V3s/V3, the former one is a
reduced-pin package with co-packaged DDR2 and the latter one is a BGA
package w/o DRAM packaged in.

Add a CCU driver for them. As the user manual didn't have marks for
different chips (V831 and V833 shares the same user manual file), only
implementing a full-functional CCU driver with V833 compatible.

Signed-off-by: Icenowy Zheng 
---
There's a PLL that is called PLL_UNI in the user manual. However a duck
test shows that it is quite similar to PLL_PERI1 on other SoCs: it
functions as parent to some peripherals, occupies the same register
offset with PLL_PERI1 and have the same clock rate configuration with
PLL_PERI1. Here I called it as pll-uni to follow the official document,
but I doubt whether we should call it pll-periph1 to be consistent with
other SoCs.

 drivers/clk/sunxi-ng/Kconfig  |   5 +
 drivers/clk/sunxi-ng/Makefile |   1 +
 drivers/clk/sunxi-ng/ccu-sun8i-v833.c | 930 ++
 drivers/clk/sunxi-ng/ccu-sun8i-v833.h |  46 ++
 4 files changed, 982 insertions(+)
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-v833.c
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-v833.h

diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
index ce5f5847d5d3..eb038d0f48d7 100644
--- a/drivers/clk/sunxi-ng/Kconfig
+++ b/drivers/clk/sunxi-ng/Kconfig
@@ -77,6 +77,11 @@ config SUN8I_V3S_CCU
default MACH_SUN8I
depends on MACH_SUN8I || COMPILE_TEST
 
+config SUN8I_V833_CCU
+   bool "Support for the Allwinner V833 CCU"
+   default MACH_SUN8I
+   depends on MACH_SUN8I || COMPILE_TEST
+
 config SUN8I_DE2_CCU
bool "Support for the Allwinner SoCs DE2 CCU"
default MACH_SUN8I || (ARM64 && ARCH_SUNXI)
diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
index 3eb5cff40eac..dd33aba983bb 100644
--- a/drivers/clk/sunxi-ng/Makefile
+++ b/drivers/clk/sunxi-ng/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_SUN8I_A33_CCU)   += ccu-sun8i-a33.o
 obj-$(CONFIG_SUN8I_A83T_CCU)   += ccu-sun8i-a83t.o
 obj-$(CONFIG_SUN8I_H3_CCU) += ccu-sun8i-h3.o
 obj-$(CONFIG_SUN8I_V3S_CCU)+= ccu-sun8i-v3s.o
+obj-$(CONFIG_SUN8I_V833_CCU)   += ccu-sun8i-v833.o
 obj-$(CONFIG_SUN8I_DE2_CCU)+= ccu-sun8i-de2.o
 obj-$(CONFIG_SUN8I_R_CCU)  += ccu-sun8i-r.o
 obj-$(CONFIG_SUN8I_R40_CCU)+= ccu-sun8i-r40.o
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-v833.c 
b/drivers/clk/sunxi-ng/ccu-sun8i-v833.c
new file mode 100644
index ..c60178035117
--- /dev/null
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-v833.c
@@ -0,0 +1,930 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2020 Icenowy Zheng 
+ * Based on the H616 CCU driver, which is:
+ *   Copyright (c) 2020 Arm Ltd.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "ccu_common.h"
+#include "ccu_reset.h"
+
+#include "ccu_div.h"
+#include "ccu_gate.h"
+#include "ccu_mp.h"
+#include "ccu_mult.h"
+#include "ccu_nk.h"
+#include "ccu_nkm.h"
+#include "ccu_nkmp.h"
+#include "ccu_nm.h"
+
+#include "ccu-sun8i-v833.h"
+
+/*
+ * The CPU PLL is actually NP clock, with P being /1, /2 or /4. However
+ * P should only be used for output frequencies lower than 288 MHz.
+ *
+ * For now we can just model it as a multiplier clock, and force P to /1.
+ *
+ * The M factor is present in the register's description, but not in the
+ * frequency formula, and it's documented as "M is only used for backdoor
+ * testing", so it's not modelled and then force to 0.
+ */
+#define SUN8I_V833_PLL_CPUX_REG0x000
+static struct ccu_mult pll_cpux_clk = {
+   .enable = BIT(31),
+   .lock   = BIT(28),
+   .mult   = _SUNXI_CCU_MULT_MIN(8, 8, 12),
+   .common = {
+   .reg= 0x000,
+   .hw.init= CLK_HW_INIT("pll-cpux", "osc24M",
+ _mult_ops,
+ CLK_SET_RATE_UNGATE),
+   },
+};
+
+/* Some PLLs are input * N / div1 / P. Model them as NKMP with no K */
+#define SUN8I_V833_PLL_DDR0_REG0x010
+static struct ccu_nkmp pll_ddr0_clk = {
+   .enable = BIT(31),
+   .lock   = BIT(28),
+   .n  = _SUNXI_CCU_MULT_MIN(8, 8, 12),
+   .m  = _SUNXI_CCU_DIV(1, 1), /* input divider */
+   .p  = _SUNXI_CCU_DIV(0, 1), /* output divider */
+   .common = {
+   .reg= 0x010,
+   .hw.init= CLK_HW_INIT("pll-ddr0", "osc24M",
+ _nkmp_ops,
+ CLK_SET_RATE_UNGATE),
+   },
+};
+
+#define SUN8I_V833_PLL_PERIPH0_REG 0x020
+static struct ccu_nkmp pll_periph0_clk = {
+   .enable = BIT(31),
+   .lock   = BIT(28),
+   .n  = _SUNXI_CCU_MULT_MIN(8, 8,

[RFC PATCH 00/12] Support for Allwinner V831 SoC

Allwinner V831 is a new SoC by Allwinner oriented at the camera market.
It has a QFN88 package with co-packaged 64MiB DDR2 DRAM. Another SoC,
V833, is also available, which has the same die with V831 but w/o
co-packaged DRAM (thus a BGA package).

This patchset tries to add basical support for V831, with consideration
of V833 in many drivers.

The DT is only for a temporary test device w/o schematics, development
will be shifted to another device when the patchset leaves RFC.

Icenowy Zheng (12):
  dt-bindings: clock: sunxi-ng: add compatible for V831/V833 CCU
  dt-bindings: clk: sunxi-ng: add V833 CCU clock/reset indices headers
  clk: sunxi-ng: add CCU driver for V831/V833
  dt-bindings: pinctrl: sunxi: add compatible for V831/V833 pinctrl
  pinctrl: sunxi: add pinctrl driver for V831/V833
  dt-bindings: rtc: sun6i: add compatible string for V831/V833 RTC
  rtc: sun6i: add compatible string for V831/V833 RTC
  dt-bindings: mmc: sunxi: add compatible strings for V831 MMC
  dt-bindings: watchdog: sunxi: add compatible string for V831/V833 WDT
  dt-bindings: spi: sun6i: add compatible for V831 SPI
  ARM: dts: sun8i: add DTSI file for V831
  [DO NOT MERGE] ARM: dts: sun8i: v831: add a device tree file for Y20GA

 .../clock/allwinner,sun4i-a10-ccu.yaml|   2 +
 .../bindings/mmc/allwinner,sun4i-a10-mmc.yaml |   3 +
 .../pinctrl/allwinner,sun4i-a10-pinctrl.yaml  |   4 +
 .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml |   2 +
 .../bindings/spi/allwinner,sun6i-a31-spi.yaml |   1 +
 .../watchdog/allwinner,sun4i-a10-wdt.yaml |   3 +
 arch/arm/boot/dts/Makefile|   3 +-
 arch/arm/boot/dts/sun8i-v831-yi-y20ga.dts |  53 +
 arch/arm/boot/dts/sun8i-v831.dtsi | 244 +
 drivers/clk/sunxi-ng/Kconfig  |   5 +
 drivers/clk/sunxi-ng/Makefile |   1 +
 drivers/clk/sunxi-ng/ccu-sun8i-v833.c | 930 ++
 drivers/clk/sunxi-ng/ccu-sun8i-v833.h |  46 +
 drivers/pinctrl/sunxi/Kconfig |   5 +
 drivers/pinctrl/sunxi/Makefile|   1 +
 drivers/pinctrl/sunxi/pinctrl-sun8i-v83x.c| 743 ++
 drivers/pinctrl/sunxi/pinctrl-sunxi.h |   2 +
 drivers/rtc/rtc-sun6i.c   |  18 +
 include/dt-bindings/clock/sun8i-v833-ccu.h|  89 ++
 include/dt-bindings/reset/sun8i-v833-ccu.h|  52 +
 20 files changed, 2206 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/sun8i-v831-yi-y20ga.dts
 create mode 100644 arch/arm/boot/dts/sun8i-v831.dtsi
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-v833.c
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-v833.h
 create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun8i-v83x.c
 create mode 100644 include/dt-bindings/clock/sun8i-v833-ccu.h
 create mode 100644 include/dt-bindings/reset/sun8i-v833-ccu.h

-- 
2.28.0

[RFC PATCH 02/12] dt-bindings: clk: sunxi-ng: add V833 CCU clock/reset indices headers

As the device tree needs the clock/reset indices, add them to DT binding
headers.

The driver itself will be then added.

Signed-off-by: Icenowy Zheng 
---
 include/dt-bindings/clock/sun8i-v833-ccu.h | 89 ++
 include/dt-bindings/reset/sun8i-v833-ccu.h | 52 +
 2 files changed, 141 insertions(+)
 create mode 100644 include/dt-bindings/clock/sun8i-v833-ccu.h
 create mode 100644 include/dt-bindings/reset/sun8i-v833-ccu.h

diff --git a/include/dt-bindings/clock/sun8i-v833-ccu.h 
b/include/dt-bindings/clock/sun8i-v833-ccu.h
new file mode 100644
index ..885f3462eab6
--- /dev/null
+++ b/include/dt-bindings/clock/sun8i-v833-ccu.h
@@ -0,0 +1,89 @@
+/* SPDX-License-Identifier: (GPL-2.0+ or MIT) */
+/*
+ * Copyright (C) 2020 Icenowy Zheng 
+ */
+
+#ifndef _DT_BINDINGS_CLK_SUN8I_V833_H_
+#define _DT_BINDINGS_CLK_SUN8I_V833_H_
+
+#define CLK_CPUX   14
+
+#define CLK_APB1   19
+
+#define CLK_DE 21
+#define CLK_BUS_DE 22
+#define CLK_G2D23
+#define CLK_BUS_G2D24
+#define CLK_CE 25
+#define CLK_BUS_CE 26
+#define CLK_VE 27
+#define CLK_BUS_VE 28
+#define CLK_EISE   29
+#define CLK_BUS_EISE   30
+#define CLK_NPU31
+#define CLK_BUS_NPU32
+#define CLK_BUS_DMA33
+#define CLK_BUS_HSTIMER34
+#define CLK_AVS35
+#define CLK_BUS_DBG36
+#define CLK_BUS_PSI37
+#define CLK_BUS_PWM38
+#define CLK_MBUS_DMA   40
+#define CLK_MBUS_VE41
+#define CLK_MBUS_CE42
+#define CLK_MBUS_TS43
+#define CLK_MBUS_NAND  44
+#define CLK_MBUS_G2D   45
+#define CLK_MBUS_EISE  46
+#define CLK_MBUS_VDPO  47
+#define CLK_MMC0   49
+#define CLK_MMC1   50
+#define CLK_MMC2   51
+#define CLK_BUS_MMC0   52
+#define CLK_BUS_MMC1   53
+#define CLK_BUS_MMC2   54
+#define CLK_BUS_UART0  55
+#define CLK_BUS_UART1  56
+#define CLK_BUS_UART2  57
+#define CLK_BUS_UART3  58
+#define CLK_BUS_I2C0   59
+#define CLK_BUS_I2C1   60
+#define CLK_BUS_I2C2   61
+#define CLK_BUS_I2C3   62
+#define CLK_SPI0   63
+#define CLK_SPI1   64
+#define CLK_SPI2   65
+#define CLK_BUS_SPI0   66
+#define CLK_BUS_SPI1   67
+#define CLK_BUS_SPI2   68
+#define CLK_EMAC_25M   69
+#define CLK_BUS_EMAC0  70
+#define CLK_BUS_GPADC  71
+#define CLK_BUS_THS72
+#define CLK_I2S0   73
+#define CLK_I2S1   74
+#define CLK_BUS_I2S0   75
+#define CLK_BUS_I2S1   76
+#define CLK_AUDIO_CODEC_1X 77
+#define CLK_AUDIO_CODEC_4X 78
+#define CLK_BUS_AUDIO_CODEC79
+#define CLK_USB_OHCI0  80
+#define CLK_USB_PHY0   81
+#define CLK_BUS_OHCI0  82
+#define CLK_BUS_EHCI0  83
+#define CLK_BUS_OTG84
+#define CLK_MIPI_DSI_DPHY0_HS  85
+#define CLK_MIPI_DSI_HOST0 86
+#define CLK_BUS_MIPI_DSI   87
+#define CLK_BUS_TCON_TOP   88
+#define CLK_TCON_LCD0  89
+#define CLK_BUS_TCON_LCD0  90
+#define CLK_CSI_TOP91
+#define CLK_CSI_MCLK0  92
+#define CLK_CSI_MCLK1  93
+#define CLK_ISP94
+#define CLK_BUS_CSI95
+#define CLK_DSPO   96
+#define CLK_BUS_DSPO   97
+
+#endif /* _DT_BINDINGS_CLK_SUN8I_V833_H_ */
diff --git a/include/dt-bindings/reset/sun8i-v833-ccu.h 
b/include/dt-bindings/reset/sun8i-v833-ccu.h
new file mode 100644
index ..fb2b0e3b287f
--- /dev/null
+++ b/include/dt-bindings/reset/sun8i-v833-ccu.h
@@ -0,0 +1,52 @@
+/* SPDX-License-Identifier: (GPL-2.0+ or MIT) */
+/*
+ * Copyright (C) 2017 Icenowy Zheng 
+ */
+
+#ifndef _DT_BINDINGS_RESET_SUN8I_V833_H_
+#define _DT_BINDINGS_RESET_SUN8I_V833_H_
+
+#define RST_MBUS   0
+#define RST_BUS_DE 1
+#define RST_BUS_G2D2
+#define RST_BUS_CE 3
+#define RST_BUS_VE 4
+#define RST_BUS_EISE   5
+#define RST_BUS_NPU6
+#define RST_BUS_DMA7
+#define RST_BUS_HSTIMER8
+#define RST_BUS_DBG9
+#define RST_BUS_PSI10
+#define RST_BUS_PWM11
+#define RST_BUS_DRAM   12
+#define RST_BUS_MMC0   13
+#define RST_BUS_MMC1   14
+#define RST_BUS_MMC2   15
+#define RST_BUS_UART0  16
+#define RST_BUS_UART1  17
+#define RST_BUS_UART2  18
+#define RST_BUS_UART3  19
+#define RST_BUS_I2C0   20
+#define RST_BUS_I2C1   21
+#define RST_BUS_I2C2   22
+#define RST_BUS_I2C3   23
+#define RST_BUS_SPI0   24
+#define RST_BUS_SPI1   25
+#define

[RFC PATCH 01/12] dt-bindings: clock: sunxi-ng: add compatible for V831/V833 CCU

V831/V833 has a CCU similar to the ones on H6/A100.

Add a compatible string for it.

As the user manual do not mention the difference between V831 and V833
in the CCU chapter, only a single compatible string for V833
(full-functional chip) is made.

Signed-off-by: Icenowy Zheng 
---
 .../devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml  | 2 ++
 1 file changed, 2 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml 
b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml
index 3b45344ed758..b874d887995a 100644
--- a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml
+++ b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml
@@ -33,6 +33,7 @@ properties:
   - allwinner,sun8i-r40-ccu
   - allwinner,sun8i-v3-ccu
   - allwinner,sun8i-v3s-ccu
+  - allwinner,sun8i-v833-ccu
   - allwinner,sun9i-a80-ccu
   - allwinner,sun50i-a64-ccu
   - allwinner,sun50i-a64-r-ccu
@@ -98,6 +99,7 @@ else:
 properties:
   compatible:
 enum:
+  - allwinner,sun8i-v833-ccu
   - allwinner,sun50i-a100-ccu
   - allwinner,sun50i-h6-ccu
 
-- 
2.28.0

Re: [PATCH] thermal/core: Make 'forced_passive' as obsolete candidate

2020-12-11 Thread Matthew Garrett

On Fri, Dec 11, 2020 at 02:17:55PM +0100, Daniel Lezcano wrote:
> On 08/12/2020 16:30, Daniel Lezcano wrote:
> > The passive file in sysfs forces the usage of a passive trip point set
> > by the userspace when a broken BIOS does not provide the mitigation
> > temperature for such thermal zone. The hardware evolved a lot since
> > 2008 as a good thermal management is no longer an option.
> > 
> > Linux on the other side also provides now a way to load fixed ACPI
> > table via the option ACPI_TABLE_UPGRADE, so additionnal trip point
> > could be added there.
> > 
> > Set the option obsolete and plan to remove it, so the corresponding
> > code can be removed from the core code and allow more cleanups the
> > thermal framework deserves.
> > 
> > Signed-off-by: Daniel Lezcano 
> > ---
> 
> Is there any concern about this change ?

Yes - what's the reason to do so? The code isn't specific to ACPI,
so being able to override ACPI tables doesn't seem to justify it.

Re: [PATCH] mm/mmap: replace if (cond) BUG() with BUG_ON()

2020-12-11 Thread Alex Shi



I'm very sorry, a typo here. the patch should be updated:

>From ed4fa1c6d5bed5766c5f0c35af0c597855d7be06 Mon Sep 17 00:00:00 2001
From: Alex Shi 
Date: Fri, 11 Dec 2020 21:26:46 +0800
Subject: [PATCH] mm/mmap: replace if (cond) BUG() with BUG_ON()

coccinelle reports some warnings:
WARNING: Use BUG_ON instead of if condition followed by BUG.

It could be fixed by BUG_ON().

Reported-by: ab...@linux.alibaba.com
Signed-off-by: Alex Shi 
Cc: Andrew Morton 
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
---
 mm/mmap.c | 22 --
 1 file changed, 8 insertions(+), 14 deletions(-)

diff --git a/mm/mmap.c b/mm/mmap.c
index 8144fc3c5a78..107fa91bb59f 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -712,9 +712,8 @@ static void __insert_vm_struct(struct mm_struct *mm, struct 
vm_area_struct *vma)
struct vm_area_struct *prev;
struct rb_node **rb_link, *rb_parent;
 
-   if (find_vma_links(mm, vma->vm_start, vma->vm_end,
-  , _link, _parent))
-   BUG();
+   BUG_ON(find_vma_links(mm, vma->vm_start, vma->vm_end,
+  , _link, _parent));
__vma_link(mm, vma, prev, rb_link, rb_parent);
mm->map_count++;
 }
@@ -3585,9 +3584,8 @@ static void vm_lock_anon_vma(struct mm_struct *mm, struct 
anon_vma *anon_vma)
 * can't change from under us thanks to the
 * anon_vma->root->rwsem.
 */
-   if (__test_and_set_bit(0, (unsigned long *)
-  
_vma->root->rb_root.rb_root.rb_node))
-   BUG();
+   BUG_ON(__test_and_set_bit(0, (unsigned long *)
+   _vma->root->rb_root.rb_root.rb_node));
}
 }
 
@@ -3603,8 +3601,7 @@ static void vm_lock_mapping(struct mm_struct *mm, struct 
address_space *mapping)
 * mm_all_locks_mutex, there may be other cpus
 * changing other bitflags in parallel to us.
 */
-   if (test_and_set_bit(AS_MM_ALL_LOCKS, >flags))
-   BUG();
+   BUG_ON(test_and_set_bit(AS_MM_ALL_LOCKS, >flags));
down_write_nest_lock(>i_mmap_rwsem, >mmap_lock);
}
 }
@@ -3701,9 +3698,8 @@ static void vm_unlock_anon_vma(struct anon_vma *anon_vma)
 * can't change from under us until we release the
 * anon_vma->root->rwsem.
 */
-   if (!__test_and_clear_bit(0, (unsigned long *)
- 
_vma->root->rb_root.rb_root.rb_node))
-   BUG();
+   BUG_ON(!__test_and_clear_bit(0, (unsigned long *)
+   _vma->root->rb_root.rb_root.rb_node));
anon_vma_unlock_write(anon_vma);
}
 }
@@ -3716,9 +3712,7 @@ static void vm_unlock_mapping(struct address_space 
*mapping)
 * because we hold the mm_all_locks_mutex.
 */
i_mmap_unlock_write(mapping);
-   if (!test_and_clear_bit(AS_MM_ALL_LOCKS,
-   >flags))
-   BUG();
+   BUG_ON(!test_and_clear_bit(AS_MM_ALL_LOCKS, >flags));
}
 }
 
-- 
2.29.GIT

[PATCH] mm/zsmalloc: replace if (cond) BUG() with BUG_ON()

2020-12-11 Thread Alex Shi

coccinelle reports some warning:
WARNING: Use BUG_ON instead of if condition followed by BUG.

It could be fixed by BUG_ON().

Reported-by: ab...@linux.alibaba.com
Signed-off-by: Alex Shi 
Cc: Minchan Kim 
Cc: Nitin Gupta 
Cc: Sergey Senozhatsky 
Cc: Andrew Morton 
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
---
 mm/zsmalloc.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 7289f502ffac..1ea0605dbe94 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -1988,8 +1988,7 @@ static int zs_page_migrate(struct address_space *mapping, 
struct page *newpage,
head = obj_to_head(page, addr);
if (head & OBJ_ALLOCATED_TAG) {
handle = head & ~OBJ_ALLOCATED_TAG;
-   if (!testpin_tag(handle))
-   BUG();
+   BUG_ON(!testpin_tag(handle));
 
old_obj = handle_to_obj(handle);
obj_to_location(old_obj, , _idx);
@@ -2036,8 +2035,8 @@ static int zs_page_migrate(struct address_space *mapping, 
struct page *newpage,
head = obj_to_head(page, addr);
if (head & OBJ_ALLOCATED_TAG) {
handle = head & ~OBJ_ALLOCATED_TAG;
-   if (!testpin_tag(handle))
-   BUG();
+   BUG_ON(!testpin_tag(handle));
+
unpin_tag(handle);
}
}
-- 
2.29.GIT

Re: [PATCH 2/2] soc: bcm: add PM driver for Broadcom's PMB

2020-12-11 Thread Florian Fainelli




On 12/11/2020 1:59 PM, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> PMB can be found on BCM4908 and many other chipsets (e.g. BCM63138).
> It's needed to power on and off SoC blocks like PCIe, SATA, USB.
> 
> Signed-off-by: Rafał Miłecki 

This looks good to me, just a few nipicks below.

[snip]

> +static int bcm_pmb_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + const struct bcm_pmb_pd_data *table;
> + const struct bcm_pmb_pd_data *e;
> + struct resource *res;
> + struct bcm_pmb *pmb;
> + int max_id;
> + int err;
> +
> + dev_info(dev, "START\n");

Stray debugging.

[snip]

> +
> +static const struct bcm_pmb_pd_data bcm_pmb_bcm4908_data[] = {
> + { .name = "pcie2", .id = BCM_PMB_PCIE2, .bus = 0, .device = 2, },
> + { .name = "pcie0", .id = BCM_PMB_PCIE0, .bus = 1, .device = 14, },
> + { .name = "pcie1", .id = BCM_PMB_PCIE1, .bus = 1, .device = 15, },
> + { .name = "usb", .id = BCM_PMB_HOST_USB, .bus = 1, .device = 17, },

Do you have to be more specific and spell out whether this is the host
controller (xhci) or device (bdc)? If not, then this looks good to me.
-- 
Florian

[PATCH] mm/mmap: replace if (cond) BUG() with BUG_ON()

2020-12-11 Thread Alex Shi

coccinelle reports some warnings:
WARNING: Use BUG_ON instead of if condition followed by BUG.

It could be fixed by BUG_ON().

Reported-by: ab...@linux.alibaba.com
Signed-off-by: Alex Shi 
Cc: Andrew Morton 
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
---
 mm/mmap.c | 22 --
 1 file changed, 8 insertions(+), 14 deletions(-)

diff --git a/mm/mmap.c b/mm/mmap.c
index 8144fc3c5a78..2dab93dedae6 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -712,9 +712,8 @@ static void __insert_vm_struct(struct mm_struct *mm, struct 
vm_area_struct *vma)
struct vm_area_struct *prev;
struct rb_node **rb_link, *rb_parent;
 
-   if (find_vma_links(mm, vma->vm_start, vma->vm_end,
-  , _link, _parent))
-   BUG();
+   BUF_ON(find_vma_links(mm, vma->vm_start, vma->vm_end,
+  , _link, _parent));
__vma_link(mm, vma, prev, rb_link, rb_parent);
mm->map_count++;
 }
@@ -3585,9 +3584,8 @@ static void vm_lock_anon_vma(struct mm_struct *mm, struct 
anon_vma *anon_vma)
 * can't change from under us thanks to the
 * anon_vma->root->rwsem.
 */
-   if (__test_and_set_bit(0, (unsigned long *)
-  
_vma->root->rb_root.rb_root.rb_node))
-   BUG();
+   BUG_ON(__test_and_set_bit(0, (unsigned long *)
+   _vma->root->rb_root.rb_root.rb_node));
}
 }
 
@@ -3603,8 +3601,7 @@ static void vm_lock_mapping(struct mm_struct *mm, struct 
address_space *mapping)
 * mm_all_locks_mutex, there may be other cpus
 * changing other bitflags in parallel to us.
 */
-   if (test_and_set_bit(AS_MM_ALL_LOCKS, >flags))
-   BUG();
+   BUG_ON(test_and_set_bit(AS_MM_ALL_LOCKS, >flags));
down_write_nest_lock(>i_mmap_rwsem, >mmap_lock);
}
 }
@@ -3701,9 +3698,8 @@ static void vm_unlock_anon_vma(struct anon_vma *anon_vma)
 * can't change from under us until we release the
 * anon_vma->root->rwsem.
 */
-   if (!__test_and_clear_bit(0, (unsigned long *)
- 
_vma->root->rb_root.rb_root.rb_node))
-   BUG();
+   BUG_ON(!__test_and_clear_bit(0, (unsigned long *)
+   _vma->root->rb_root.rb_root.rb_node));
anon_vma_unlock_write(anon_vma);
}
 }
@@ -3716,9 +3712,7 @@ static void vm_unlock_mapping(struct address_space 
*mapping)
 * because we hold the mm_all_locks_mutex.
 */
i_mmap_unlock_write(mapping);
-   if (!test_and_clear_bit(AS_MM_ALL_LOCKS,
-   >flags))
-   BUG();
+   BUG_ON(!test_and_clear_bit(AS_MM_ALL_LOCKS, >flags));
}
 }
 
-- 
2.29.GIT

[git pull] Input updates for v5.10-rc7

Hi Linus,

Please pull from:

git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus

to receive updates for the input subsystem. You will get:

- a fix for cm109 stomping on its own control URB if it tries to toggle
  buzzer immediately after userspace opens input device (found by
  syzcaller)
- another fix for Raydium touchscreens that do not like splitting
  command transfers
- quirks for i8042, soc_button_array, and goodix drivers to make them
  work better with certain hardware.

Changelog:
-

Chris Chiu (1):
  Input: i8042 - add Acer laptops to the i8042 reset list

Dmitry Torokhov (2):
  Input: cros_ec_keyb - send 'scancodes' in addition to key events
  Input: cm109 - do not stomp on control URB

Furquan Shaikh (1):
  Input: raydium_ts_i2c - do not split tx transactions

Hans de Goede (1):
  Input: soc_button_array - add Lenovo Yoga Tablet2 1051L to the 
dmi_use_low_level_irq list

Simon Beginn (1):
  Input: goodix - add upside-down quirk for Teclast X98 Pro tablet

Diffstat:


 drivers/input/keyboard/cros_ec_keyb.c  |   1 +
 drivers/input/misc/cm109.c |   7 +-
 drivers/input/misc/soc_button_array.c  |  11 +++
 drivers/input/serio/i8042-x86ia64io.h  |  42 ++
 drivers/input/touchscreen/goodix.c |  12 +++
 drivers/input/touchscreen/raydium_i2c_ts.c | 126 -
 6 files changed, 159 insertions(+), 40 deletions(-)

Thanks.


-- 
Dmitry

Re: [PATCH v2 3/3] dt-bindings: input: Add compatible string for SC2721 and SC2730

On Tue, Nov 17, 2020 at 11:49:49AM +0800, Chunyan Zhang wrote:
> From: Chunyan Zhang 
> 
> Add new compatible strings to support sc2730 and sc2721 which are
> two varieties of SC27XX family.
> 
> Signed-off-by: Chunyan Zhang 

Applied, thank you.

-- 
Dmitry

Re: [PATCH v2 1/3] input: sc27xx: Add support for sc2730 and sc2721

Hi Chunyan,

On Tue, Nov 17, 2020 at 11:49:47AM +0800, Chunyan Zhang wrote:
> @@ -78,8 +112,15 @@ static void sc27xx_vibra_close(struct input_dev *input)
>  static int sc27xx_vibra_probe(struct platform_device *pdev)
>  {
>   struct vibra_info *info;
> + const struct sc27xx_vibra_data *data;
>   int error;
>  
> + data = of_device_get_match_data(>dev);
> + if (!data) {
> + dev_err(>dev, "no matching driver data found\n");
> + return -EINVAL;
> + }

This does not have to be OF-specific, so I changed it to
device_get_match_data() and applied, thank you.

-- 
Dmitry

Re: [PATCH v2 2/3] dt-bindings: input: Convert sc27xx-vibra.txt to json-schema

On Tue, Nov 17, 2020 at 11:49:48AM +0800, Chunyan Zhang wrote:
> From: Chunyan Zhang 
> 
> Convert the sprd sc27xx vibrator binding to DT schema using json-schema.
> 
> Signed-off-by: Chunyan Zhang 

Applied, thank you.

-- 
Dmitry

Re: [PATCH 1/7] ARM: mstar: Unify common parts of BreadBee boards into a dtsi

2020-12-11 Thread Daniel Palmer

Hi all,

>[PATCH 1/7]

Sorry, this isn't actually a 1/7 it's 1/1. I forgot to fix the subject
before sending.

Thanks,

Daniel

[PATCH 1/7] ARM: mstar: Unify common parts of BreadBee boards into a dtsi

2020-12-11 Thread Daniel Palmer

The BreadBee and the BreadBee Crust are the same PCB with a different
SoC mounted. There are two top level dts to handle this.

To avoid deduplicating the parts that are more related to the PCB than
the SoC (i.e. the voltage regs and LEDs) add a common dtsi that can
be included in both top level dts.

Signed-off-by: Daniel Palmer 
---
 .../dts/mstar-infinity-breadbee-common.dtsi   | 47 +++
 .../mstar-infinity-msc313-breadbee_crust.dts  |  1 +
 .../dts/mstar-infinity3-msc313e-breadbee.dts  |  1 +
 3 files changed, 49 insertions(+)
 create mode 100644 arch/arm/boot/dts/mstar-infinity-breadbee-common.dtsi

diff --git a/arch/arm/boot/dts/mstar-infinity-breadbee-common.dtsi 
b/arch/arm/boot/dts/mstar-infinity-breadbee-common.dtsi
new file mode 100644
index ..53244b399126
--- /dev/null
+++ b/arch/arm/boot/dts/mstar-infinity-breadbee-common.dtsi
@@ -0,0 +1,47 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2020 thingy.jp.
+ * Author: Daniel Palmer 
+ */
+
+/ {
+   vcc_core: fixedregulator@0 {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_core";
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <100>;
+   regulator-boot-on;
+   };
+
+   vcc_dram: fixedregulator@1 {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_dram";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-boot-on;
+   };
+
+   vcc_io: fixedregulator@2 {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_io";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   red {
+   gpios = < MSC313_GPIO_SR_IO16 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "activity";
+   };
+   yellow {
+   gpios = < MSC313_GPIO_SR_IO17 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "heartbeat";
+   };
+   };
+};
+
+ {
+   cpu-supply = <_core>;
+};
diff --git a/arch/arm/boot/dts/mstar-infinity-msc313-breadbee_crust.dts 
b/arch/arm/boot/dts/mstar-infinity-msc313-breadbee_crust.dts
index f9db2ff86f2d..db4910dcb8a7 100644
--- a/arch/arm/boot/dts/mstar-infinity-msc313-breadbee_crust.dts
+++ b/arch/arm/boot/dts/mstar-infinity-msc313-breadbee_crust.dts
@@ -6,6 +6,7 @@
 
 /dts-v1/;
 #include "mstar-infinity-msc313.dtsi"
+#include "mstar-infinity-breadbee-common.dtsi"
 
 / {
model = "BreadBee Crust";
diff --git a/arch/arm/boot/dts/mstar-infinity3-msc313e-breadbee.dts 
b/arch/arm/boot/dts/mstar-infinity3-msc313e-breadbee.dts
index f0eda80a95cc..e64ca4ce1830 100644
--- a/arch/arm/boot/dts/mstar-infinity3-msc313e-breadbee.dts
+++ b/arch/arm/boot/dts/mstar-infinity3-msc313e-breadbee.dts
@@ -6,6 +6,7 @@
 
 /dts-v1/;
 #include "mstar-infinity3-msc313e.dtsi"
+#include "mstar-infinity-breadbee-common.dtsi"
 
 / {
model = "BreadBee";
-- 
2.29.2

Re: [PATCH v3 0/3] Support wakeup methods of Atmel maXTouch controllers

Hi Dmitry,

On Mon, Dec 07, 2020 at 12:22:14AM +0300, Dmitry Osipenko wrote:
> Some Atmel maXTouch controllers, like mXT1386 and mXT3432S1 for example,
> have a WAKE line that needs to be asserted in order to wake controller
> from a deep sleep, otherwise it will be unusable. This series implements
> support for the wakeup methods in accordance to the mXT1386 datasheet [1],
> see page 29 (chapter "5.8 WAKE Line").
> 
> The mXT1386 is a widely used controller found on many older Android tablet
> devices. Touchscreen on Acer A500 tablet now works properly after this
> series.

I am trying to understand how your controller is configured on that
system. Could you please enable all debug messages in the driver and
post the logs? I am a bit confused why the controller needs to be woken
up twice in mxt_start() given that according to the spec it is supposed
to stay up for 2 seconds after successful I2C transfer...

Thanks!

-- 
Dmitry

Re: [PATCH 2/9] misc: Add Xilinx AI engine device driver

2020-12-11 Thread Jiaying Liang

On 12/9/20 4:47 AM, Daniel Vetter wrote:

On Tue, Dec 08, 2020 at 11:54:57AM -0800, Jiaying Liang wrote:

On 12/8/20 9:12 AM, Nicolas Dufresne wrote:

Le mercredi 18 novembre 2020 à 00:06 -0800, Wendy Liang a écrit :

Create AI engine device/partition hierarchical structure.

Each AI engine device can have multiple logical partitions(groups of AI
engine tiles). Each partition is column based and has its own node ID
in the system. AI engine device driver manages its partitions.

Applications can access AI engine partition through the AI engine
partition driver instance. AI engine registers write is moved to kernel
as there are registers in the AI engine array needs privilege
permission.

Hi there, it's nice to see an effort to upstream an AI driver. I'm a little
worried this driver is not obvious to use from it's source code itself. So you
have reference to some Open Source code that demonstrate it's usage ?

We have AI engine library which provides a cross platforms APIs for other

libraries/application to use the hardware. Here is the source code:

https://github.com/Xilinx/embeddedsw/tree/master/XilinxProcessorIPLib/drivers/aienginev2/src

The cross platforms AI engine library runs in LInux userspace it defines how
to

configure, and the kernel driver controls if what can be access and manage
errors from device.

So I kinda ignored this driver submission because in the past all these AI
drivers had at best incomplete open source (usually the compiler is
closed, often also large parts of the runtime). I think yours would be the
first that breaks this trend, is that really the case? I.e. I could make
full use of this hw without any closed source bits to run DNN workloads
and things like that?
AI engine can be used for signaling processing or high performance
computing

the kernel driver works on the AI engine software library which I
mentioned above,

which will be used by Xilinx runtime:
https://xilinx.github.io/XRT/2020.2/html/index.html

Xilinx runtime is a layer for acceleration libraries or applications to
use Xilinx accelerators.

e.g. it has OpenCL implementation

If that's the case then I think there's nothing stopping us from doing the
right thing and merging this driver into the right subsystem: The
subsystem for accelerators which their own memory and who want dma-buf
integration is drivers/gpu, not drivers/misc.

The AI engine kernel driver is used for device runtime configuration update,

and runtime monitoring, such as async errors detection. The buffer
management

is out of the AI engine driver, but it is covered by Xilinx runtime:

https://github.com/Xilinx/XRT/tree/master/src/runtime_src/core/edge/drm/zocl

AI engine driver imports the DMA buf.

The AI engine device is quite different to the GPU devices. The AI engine

operations are still needs driver specific ioctls.

We have more than 100 cores tiles, each tiles functions can be defined
at compilation

time, at runtime, we load the configuration (application defined I/O
commands) to

configure each tiles registers to set up routing, set up DMAs, configure
local memories,

and enable the tiles.

As the AI engine device hardware is different to the GPUs,

we are not able to make use of functions abstracted for GPUs, and we
don't manage the

buffers in this driver. I am not sure if it is ok to add the driver to
drivers/gpu but not

using abstractions from the GPU abstraction.

There is another reply to the patch series to ask for clarification on
the overview of the

driver, and I had some discussions with other team members. I will reply
to that email

to provide more details on overall how this driver is used.

Any suggestions on how to fit the driver in the drivers/gpu or other
drivers framework

will be much appreciated.

Thanks,

Wendy

Apologies that I'm jumping with the really big arch review when v3 is
already on the list. But last few times merging AI drivers to drivers/misc
was really just a way to avoid the merge criteria for drivers/gpu
acceleration drivers. I'd love to land the first real open AI driver in
upstream, properly.

Cheers, Daniel

Best Regards,

Wendy

Signed-off-by: Wendy Liang
Signed-off-by: Hyun Kwon
---
MAINTAINERS | 8 +
drivers/misc/Kconfig | 12 +
drivers/misc/Makefile | 1 +
drivers/misc/xilinx-ai-engine/Makefile | 11 +
drivers/misc/xilinx-ai-engine/ai-engine-aie.c | 115 +
drivers/misc/xilinx-ai-engine/ai-engine-dev.c | 448 ++
drivers/misc/xilinx-ai-engine/ai-engine-internal.h | 226 ++
drivers/misc/xilinx-ai-engine/ai-engine-part.c | 498
+
drivers/misc/xilinx-ai-engine/ai-engine-res.c | 114 +
include/uapi/linux/xlnx-ai-engine.h | 107 +
10 files changed, 1540 insertions(+)
create mode 100644 drivers/misc/xilinx-ai-engine/Makefile

Re: [RFC PATCH 2/4] of: Add a common kexec FDT setup function

2020-12-11 Thread Thiago Jung Bauermann



Lakshmi Ramasubramanian  writes:

> On 12/11/20 2:10 PM, Rob Herring wrote:
>
> Hi Rob,
>
>> Both arm64 and powerpc do essentially the same FDT /chosen setup for
>> kexec. We can simply combine everything each arch does. The differences
>> are either omissions that arm64 should have or additional properties
>> that will be ignored.
>> The differences relative to the arm64 version:
>> - If /chosen doesn't exist, it will be created (should never happen).
>> - Any old dtb and initrd reserved memory will be released.
>> - The new initrd and elfcorehdr are marked reserved.
>> - "linux,booted-from-kexec" is set.
>> The differences relative to the powerpc version:
>> - "kaslr-seed" and "rng-seed" may be set.
>> - "linux,elfcorehdr" is set.
>> - Any existing "linux,usable-memory-range" is removed.
>> Signed-off-by: Rob Herring 
>> ---
>> This could be taken a step further and do the allocation of the new
>> FDT. The difference is arm64 uses vmalloc and powerpc uses kmalloc. The
>> arm64 version also retries with a bigger allocation. That seems
>> unnecessary.
>> ---
>>   drivers/of/Makefile |   1 +
>>   drivers/of/kexec.c  | 228 
>>   include/linux/of.h  |   5 +
>>   3 files changed, 234 insertions(+)
>>   create mode 100644 drivers/of/kexec.c
>> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
>> index 6e1e5212f058..8ce11955afde 100644
>> --- a/drivers/of/Makefile
>> +++ b/drivers/of/Makefile
>> @@ -13,5 +13,6 @@ obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
>>   obj-$(CONFIG_OF_RESOLVE)  += resolver.o
>>   obj-$(CONFIG_OF_OVERLAY) += overlay.o
>>   obj-$(CONFIG_OF_NUMA) += of_numa.o
>> +obj-$(CONFIG_KEXEC_FILE) += kexec.o
>
> For the functions moved from powerpc & arm64 to "drivers/of/kexec.c" in this
> patch, compiling kexec.c when CONFIG_KEXEC_FILE is enabled is fine. But when
> more functions (such as remove_ima_buffer()) are moved to this file, Makefile
> needs to be updated for other ima kexec related CONFIGs.

IMA kexec is only available if CONFIG_KEXEC_FILE is enabled, so I don't
understand what problem you are seeing.

-- 
Thiago Jung Bauermann
IBM Linux Technology Center

Re: [PATCH v2] usb: dwc3: Trigger a GCTL soft reset when switching modes in DRD

2020-12-11 Thread John Stultz

Hey Felipe,
  Sorry for taking so long to get back to this. :(

On Fri, Oct 23, 2020 at 12:02 AM Felipe Balbi  wrote:
> John Stultz  writes:
> > On Thu, Oct 22, 2020 at 12:55 AM Felipe Balbi  wrote:
> >> The only thing we need to do is verify
> >> which registers are shadowed between host and peripheral roles and cache
> >> only those registers.
> >
> > Sorry, could you explain this a bit more? Again, I don't have access
> > to the hardware docs, so I'm just working with the source and any
> > vendor patches I can find.
>
> Right, initialize it in gadget mode, then take a register dump (I think
> our regdump facility in dwc3's debugfs is enough). Then flip to host
> mode and take the same register dump. Now diff them. You'll see that
> some registers get overwritten. The reason for that is that physically
> some host and peripheral registers map to the same block of memory in
> the IP. In other words, the address decoder in the Register File decodes
> some addresses to the same physical block of memory. This was done, I
> believe, to save die area by reducing gate count.


Ok. So I've taken regdump in gadget mode, and then in host mode
against upstream, and then again with the patches.
Diffs below (along with all the captured regdump files attached).
Note, the problem when it occurs usually at bootup is that the device
doesn't properly enter gadget mode, so in this case things were
working (not exhibiting the failure) when I captured everything. If
you need a regdump when the problem occurs and the IP gets stuck w/
COREIDLE off, I can capture that too. Let me know

Again, I'm without any hw docs here, so I'm at a little bit of a loss
to understand how to use these diffs and your comment above about the
register file using the same memory to generate an alternative
solution to the patch I have (which is still working great in my
testing/usage).

Also, Thinh's recent feedback suggests it really is a programming flow
issue when switching modes, so I'm not sure how to move this forward.

Let me know what you suggest and I'm happy to take a stab at it.

thanks
-john


--- regdump.gadget  2020-12-12 01:08:56.643246612 +
+++ regdump.host2020-12-12 01:16:40.195105355 +
@@ -2,9 +2,9 @@
 GSBUSCFG1 = 0x0300
 GTXTHRCFG = 0x2408
 GRXTHRCFG = 0x0440
-GCTL = 0x00112004
+GCTL = 0x00111004
 GEVTEN = 0x
-GSTS = 0x7e80
+GSTS = 0x7e81
 GUCTL1 = 0x0104018a
 GSNPSID = 0x5533300a
 GGPIO = 0x
@@ -22,9 +22,9 @@
 GHWPARAMS5 = 0x04204108
 GHWPARAMS6 = 0x0feaec20
 GHWPARAMS7 = 0x04881e8d
-GDBGFIFOSPACE = 0x0042
-GDBGLTSSM = 0x41090440
-GDBGBMU = 0x2030
+GDBGFIFOSPACE = 0x0082
+GDBGLTSSM = 0x48c90442
+GDBGBMU = 0x2121
 GPRTBIMAP_HS0 = 0x
 GPRTBIMAP_HS1 = 0x
 GPRTBIMAP_FS0 = 0x
@@ -93,22 +93,22 @@
 GUSB3PIPECTL(13) = 0x
 GUSB3PIPECTL(14) = 0x
 GUSB3PIPECTL(15) = 0x
-GTXFIFOSIZ(0) = 0x0042
-GTXFIFOSIZ(1) = 0x00420286
-GTXFIFOSIZ(2) = 0x02c80286
-GTXFIFOSIZ(3) = 0x054e0286
-GTXFIFOSIZ(4) = 0x07d40286
-GTXFIFOSIZ(5) = 0x0a5a0286
-GTXFIFOSIZ(6) = 0x0ce00286
-GTXFIFOSIZ(7) = 0x0f660286
-GTXFIFOSIZ(8) = 0x11ec0286
-GTXFIFOSIZ(9) = 0x14720286
-GTXFIFOSIZ(10) = 0x16f80286
-GTXFIFOSIZ(11) = 0x197e0103
-GTXFIFOSIZ(12) = 0x1a810103
-GTXFIFOSIZ(13) = 0x1b840103
-GTXFIFOSIZ(14) = 0x1c870103
-GTXFIFOSIZ(15) = 0x1d8a0103
+GTXFIFOSIZ(0) = 0x0082
+GTXFIFOSIZ(1) = 0x00820184
+GTXFIFOSIZ(2) = 0x02060286
+GTXFIFOSIZ(3) = 0x048c
+GTXFIFOSIZ(4) = 0x048c
+GTXFIFOSIZ(5) = 0x048c
+GTXFIFOSIZ(6) = 0x048c
+GTXFIFOSIZ(7) = 0x048c
+GTXFIFOSIZ(8) = 0x048c
+GTXFIFOSIZ(9) = 0x048c
+GTXFIFOSIZ(10) = 0x048c
+GTXFIFOSIZ(11) = 0x048c
+GTXFIFOSIZ(12) = 0x048c
+GTXFIFOSIZ(13) = 0x048c
+GTXFIFOSIZ(14) = 0x048c
+GTXFIFOSIZ(15) = 0x048c
 GTXFIFOSIZ(16) = 0x
 GTXFIFOSIZ(17) = 0x
 GTXFIFOSIZ(18) = 0x
@@ -125,9 +125,9 @@
 GTXFIFOSIZ(29) = 0x
 GTXFIFOSIZ(30) = 0x
 GTXFIFOSIZ(31) = 0x
-GRXFIFOSIZ(0) = 0x0285
-GRXFIFOSIZ(1) = 0x0285
-GRXFIFOSIZ(2) = 0x0285
+GRXFIFOSIZ(0) = 0x0084
+GRXFIFOSIZ(1) = 0x00840184
+GRXFIFOSIZ(2) = 0x02080280
 GRXFIFOSIZ(3) = 0x
 GRXFIFOSIZ(4) = 0x
 GRXFIFOSIZ(5) = 0x
@@ -157,148 +157,148 @@
 GRXFIFOSIZ(29) = 0x
 GRXFIFOSIZ(30) = 0x
 GRXFIFOSIZ(31) = 0x
-GEVNTADRLO(0) = 0x41ae8000
+GEVNTADRLO(0) = 0x
 GEVNTADRHI(0) = 0x
-GEVNTSIZ(0) = 0x1000
+GEVNTSIZ(0) = 0x8000
 GEVNTCOUNT(0) = 0x
 GHWPARAMS8 = 0x0fea
 DCFG = 0x0052082c
-DCTL = 0x8cf00a00
-DEVTEN = 0x1217
-DSTS = 0x0002
+DCTL = 0x0cf0
+DEVTEN = 0x
+DSTS = 0x00cf36ec
 DGCMDPAR = 0x
 DGCMD = 0x
-DALEPENA = 0x000f
+DALEPENA = 0x
 DEPCMDPAR2(0) = 0x
-DEPCMDPAR1(0) = 0x42dac000
-DEPCMDPAR0(0) = 0x
-DEPCMD(0) = 0x0006
+DEPCMDPAR1(0) = 0x0002
+DEPCMDPAR0(0) = 0x41af5001
+DEPCMD(0) = 0x
 DEPCMDPAR2(1) =

Re: [PATCH 3/3] driver core: platform: use bus_type functions

2020-12-11 Thread Guenter Roeck

On Thu, Nov 19, 2020 at 01:46:11PM +0100, Uwe Kleine-König wrote:
> This works towards the goal mentioned in 2006 in commit 594c8281f905
> ("[PATCH] Add bus_type probe, remove, shutdown methods.").
> 
> The functions are moved to where the other bus_type functions are
> defined and renamed to match the already established naming scheme.
> 
> Signed-off-by: Uwe Kleine-König 

Qemu test results:
total: 426 pass: 91 fail: 335

This patch isn't responsible for all the crashes (-next is in pretty bad
shape), but for a good chunk of it.

Guenter

---
Bisect results for arbitrary arm64 test:

# bad: [3cc2bd440f2171f093b3a8480a4b54d8c270ed38] Add linux-next specific files 
for 20201211
# good: [0477e92881850d44910a7e94fc2c46f96faa131f] Linux 5.10-rc7
git bisect start 'HEAD' 'v5.10-rc7'
# good: [0a701401d4e29d9e73f0f3cc02179fc6c9191646] Merge remote-tracking branch 
'crypto/master'
git bisect good 0a701401d4e29d9e73f0f3cc02179fc6c9191646
# good: [6fd39ad603b113e9c68180b9138084710c036e34] Merge remote-tracking branch 
'spi/for-next'
git bisect good 6fd39ad603b113e9c68180b9138084710c036e34
# bad: [c96b2eec436e87b8c673213b203559bed9e551b9] Merge remote-tracking branch 
'vfio/next'
git bisect bad c96b2eec436e87b8c673213b203559bed9e551b9
# good: [f99c2fbbff522300c309e517be1f5bed4bd34704] Merge remote-tracking branch 
'kvm-arm/next'
git bisect good f99c2fbbff522300c309e517be1f5bed4bd34704
# bad: [0e3f63470c00704498be2bfac586076cfa93214f] Merge remote-tracking branch 
'usb-chipidea-next/for-usb-next'
git bisect bad 0e3f63470c00704498be2bfac586076cfa93214f
# bad: [903821bc4404ae12d4e50e95fb5c2d7b46f4d1c6] Merge remote-tracking branch 
'driver-core/driver-core-next'
git bisect bad 903821bc4404ae12d4e50e95fb5c2d7b46f4d1c6
# good: [0cd3f561efa9adce840140720e0581355db3e554] platform/x86: ISST: Mark 
mmio_range_devid_0 and mmio_range_devid_1 with static keyword
git bisect good 0cd3f561efa9adce840140720e0581355db3e554
# good: [bd7cf676c3ed2fc91e777d91c3bf9220e84da2ad] Merge remote-tracking branch 
'chrome-platform/for-next'
git bisect good bd7cf676c3ed2fc91e777d91c3bf9220e84da2ad
# good: [d475f8ea98a039e51d27f5557dc17333cf8a52f6] driver core: Fix a couple of 
typos
git bisect good d475f8ea98a039e51d27f5557dc17333cf8a52f6
# good: [16c1af8b52ea282b098c9b7506f3f4d0d3953260] Merge remote-tracking branch 
'leds/for-next'
git bisect good 16c1af8b52ea282b098c9b7506f3f4d0d3953260
# bad: [feaba5932b6f4bfc875c874a3b7a28c7f05f5a77] vfio: platform: Switch to use 
platform_get_mem_or_io()
git bisect bad feaba5932b6f4bfc875c874a3b7a28c7f05f5a77
# bad: [9c30921fe7994907e0b3e0637b2c8c0fc4b5171f] driver core: platform: use 
bus_type functions
git bisect bad 9c30921fe7994907e0b3e0637b2c8c0fc4b5171f
# good: [e21d740a3fe5ad2db7b5f5c2331fe2b713b1edba] driver core: platform: 
reorder functions
git bisect good e21d740a3fe5ad2db7b5f5c2331fe2b713b1edba
# good: [16085668eacdc56c46652d0f3bfef81ecace57de] driver core: platform: 
change logic implementing platform_driver_probe
git bisect good 16085668eacdc56c46652d0f3bfef81ecace57de
# first bad commit: [9c30921fe7994907e0b3e0637b2c8c0fc4b5171f] driver core: 
platform: use bus_type functions

Re: [PATCH] drivers: block: skd: remove skd_pci_info()

2020-12-11 Thread Chaitanya Kulkarni

On 12/11/20 14:41, Bjorn Helgaas wrote:
>> The skd driver prints unknown if the speed is not "2.5GT/s" or "5.0GT/s".
>> __pcie_print_link_status()  prints "unknown" only if speed
>> value >= ARRAY_SIZE(speed_strings).
>>
>> If a buggy skd card returns value that is not != ("2.5GT/s" or "5.0GT/s")
>> && value < ARRAY_SIZE(speed_strings) then it will not print the unknown but
>> the value from speed string array.
>>
>> Which breaks the current behavior. Please correct me if I'm wrong.
> I think you're right, but I don't think it actually *breaks* anything.
>
> For skd devices that work correctly, there should be no problem, and
> if there ever were an skd device that operated at a speed greater than
> 5GT/s, the PCI core would print that speed correctly instead of having
> the driver print "".
That is the scenario I'm not aware why it prints unknown to start with
and I couldn't find any documentation also, that is why the concern.
> I don't think it's a good idea to have a driver artificially constrain
> the speed a device operates at.  And the existing code doesn't
> actually constrain anything; it only prints "" if it doesn't
> recognize it.  The probe still succeeds.  I don't see much value in
> that "".
>
> Or am I missing an actual problem this patch causes?
You are not, I'm just not sure without any documentation why does
it print "unknown" and I attributed that to probable firmware issue
(since we all knowhow creative firmware can get ;)).

That makes it the problem with original code more so than with this patch.
In that case I was proposing just keep the original behavior.

But maybe we should apply patch and if any user(s) comes up with the problem
then we can deal with it.

Whoever is going to apply they can add :-

Reviewed-by: Chaitanya Kulkarni

Re: [PATCH] spi: spi-geni-qcom: Fix NULL pointer access in geni_spi_isr

2020-12-11 Thread Stephen Boyd

Quoting Doug Anderson (2020-12-10 17:51:53)
> Hi,
> 
> On Thu, Dec 10, 2020 at 5:39 PM Stephen Boyd  wrote:
> >
> > Quoting Doug Anderson (2020-12-10 17:30:17)
> > > On Thu, Dec 10, 2020 at 5:21 PM Stephen Boyd  wrote:
> > > >
> > > > Yeah and so if it comes way later because it timed out then what's the
> > > > point of calling synchronize_irq() again? To make the completion
> > > > variable set when it won't be tested again until it is reinitialized?
> > >
> > > Presumably the idea is to try to recover to a somewhat usable state
> > > again?  We're not rebooting the machine so, even though this transfer
> > > failed, we will undoubtedly do another transfer later.  If that
> > > "abort" interrupt comes way later while we're setting up the next
> > > transfer we'll really confuse ourselves.
> >
> > The interrupt handler just sets a completion variable. What does that
> > confuse?
> 
> The interrupt handler sees a "DONE" interrupt.  If we've made it far
> enough into setting up the next transfer that "cur_xfer" has been set
> then it might do more, no?

I thought it saw a cancel/abort EN bit?

if (m_irq & M_CMD_CANCEL_EN)
complete(>cancel_done);
if (m_irq & M_CMD_ABORT_EN)
complete(>abort_done)

and only a DONE bit if a transfer happened.

> 
> 
> > > I guess you could go the route of adding a synchronize_irq() at the
> > > start of the next transfer, but I'd rather add the overhead in the
> > > exceptional case (the timeout) than the normal case.  In the normal
> > > case we don't need to worry about random IRQs from the past transfer
> > > suddenly showing up.
> > >
> >
> > How does adding synchronize_irq() at the end guarantee that the abort is
> > cleared out of the hardware though? It seems to assume that the abort is
> > pending at the GIC when it could still be running through the hardware
> > and not executed yet. It seems like a synchronize_irq() for that is
> > wishful thinking that the irq is merely pending even though it timed
> > out and possibly never ran. Maybe it's stuck in a write buffer in the
> > CPU?
> 
> I guess I'm asserting that if a full second passed (because we timed
> out) and after that full second no interrupts are pending then the
> interrupt will never come.  That seems a reasonable assumption to me.
> It seems hard to believe it'd be stuck in a write buffer for a full
> second?
> 

Ok, so if we don't expect an irq to come in why are we calling
synchronize_irq()? I'm lost.

[net-next PATCH] tcp: Add logic to check for SYN w/ data in tcp_simple_retransmit

2020-12-11 Thread Alexander Duyck

From: Alexander Duyck 

There are cases where a fastopen SYN may trigger either a ICMP_TOOBIG
message in the case of IPv6 or a fragmentation request in the case of
IPv4. This results in the socket stalling for a second or more as it does
not respond to the message by retransmitting the SYN frame.

Normally a SYN frame should not be able to trigger a ICMP_TOOBIG or
ICMP_FRAG_NEEDED however in the case of fastopen we can have a frame that
makes use of the entire MSS. In the case of fastopen it does, and an
additional complication is that the retransmit queue doesn't contain the
original frames. As a result when tcp_simple_retransmit is called and
walks the list of frames in the queue it may not mark the frames as lost
because both the SYN and the data packet each individually are smaller than
the MSS size after the adjustment. This results in the socket being stalled
until the retransmit timer kicks in and forces the SYN frame out again
without the data attached.

In order to resolve this we can generate our best estimate for the original
packet size by detecting the fastopen SYN frame and then adding the
overhead for MAX_TCP_OPTION_SPACE and verifying if the SYN w/ data would
have exceeded the MSS. If so we can mark the frame as lost and retransmit
it.

Signed-off-by: Alexander Duyck 
---
 net/ipv4/tcp_input.c |   30 +++---
 1 file changed, 27 insertions(+), 3 deletions(-)

diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 9e8a6c1aa019..79375b58de84 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2686,11 +2686,35 @@ static void tcp_mtup_probe_success(struct sock *sk)
 void tcp_simple_retransmit(struct sock *sk)
 {
const struct inet_connection_sock *icsk = inet_csk(sk);
+   struct sk_buff *skb = tcp_rtx_queue_head(sk);
struct tcp_sock *tp = tcp_sk(sk);
-   struct sk_buff *skb;
-   unsigned int mss = tcp_current_mss(sk);
+   unsigned int mss;
+
+   /* A fastopen SYN request is stored as two separate packets within
+* the retransmit queue, this is done by tcp_send_syn_data().
+* As a result simply checking the MSS of the frames in the queue
+* will not work for the SYN packet. So instead we must make a best
+* effort attempt by validating the data frame with the mss size
+* that would be computed now by tcp_send_syn_data and comparing
+* that against the data frame that would have been included with
+* the SYN.
+*/
+   if (TCP_SKB_CB(skb)->tcp_flags & TCPHDR_SYN && tp->syn_data) {
+   struct sk_buff *syn_data = skb_rb_next(skb);
+
+   mss = tcp_mtu_to_mss(sk, icsk->icsk_pmtu_cookie) +
+ tp->tcp_header_len - sizeof(struct tcphdr) -
+ MAX_TCP_OPTION_SPACE;
 
-   skb_rbtree_walk(skb, >tcp_rtx_queue) {
+   if (syn_data && syn_data->len > mss)
+   tcp_mark_skb_lost(sk, skb);
+
+   skb = syn_data;
+   } else {
+   mss = tcp_current_mss(sk);
+   }
+
+   skb_rbtree_walk_from(skb) {
if (tcp_skb_seglen(skb) > mss)
tcp_mark_skb_lost(sk, skb);
}

[PATCH] dt-bindings: vendor-prefixes: Fix misordering introduced by honestar prefix

2020-12-11 Thread Daniel Palmer

The prefix for honestar should come before honeywell.

Fixes: 43181b5d8072 ("dt-bindings: vendor-prefixes: Add honestar vendor prefix")
Link: 
https://lore.kernel.org/linux-arm-kernel/cafr9pxmwoeuhha-kdel1ys8bwvovrt43mxxyy1j+hgbxwpu...@mail.gmail.com/
Signed-off-by: Daniel Palmer 
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml 
b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index a6cf2cef6f89..5f9bb0c152af 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -449,10 +449,10 @@ patternProperties:
 description: Hitex Development Tools
   "^holt,.*":
 description: Holt Integrated Circuits, Inc.
-  "^honeywell,.*":
-description: Honeywell
   "^honestar,.*":
 description: Honestar Technologies Co., Ltd.
+  "^honeywell,.*":
+description: Honeywell
   "^hoperun,.*":
 description: Jiangsu HopeRun Software Co., Ltd.
   "^hp,.*":
-- 
2.29.2

Re: [PATCH v10 2/8] powerpc: Move delete_fdt_mem_rsv() to drivers/of/kexec.c

2020-12-11 Thread Thiago Jung Bauermann



Lakshmi Ramasubramanian  writes:

> On 12/11/20 10:19 AM, Thiago Jung Bauermann wrote:
>> Hi Lakshmi,
>> Lakshmi Ramasubramanian  writes:
>> 
>>> On 12/6/20 5:50 PM, Lakshmi Ramasubramanian wrote:
>>>
>>> Hi Thiago,
>>>
 On 12/4/20 6:22 PM, Thiago Jung Bauermann wrote
>
> Hello Lakshmi,
>
> Lakshmi Ramasubramanian  writes:
>
>> delete_fdt_mem_rsv() retrieves the memory reserve map entry, for
>> the given starting address and size, from the device tree blob, and
>> removes the entry from the device tree blob. This function is called
>> to free the resources reserved for the buffer used for carrying forward
>> the IMA measurement logs on kexec. This function does not have
>> architecture specific code, but is currently limited to powerpc.
>>
>> Move delete_fdt_mem_rsv() to "drivers/of/kexec_fdt.c" so that it is
>
> s/kexec_fdt.c/kexec.c/
 Missed that in the patch description. Will fix it. Thanks.

>> accessible for other architectures as well.
>>
>> Co-developed-by: Prakhar Srivastava 
>> Signed-off-by: Prakhar Srivastava 
>> Signed-off-by: Lakshmi Ramasubramanian 
>> ---
>>arch/powerpc/include/asm/kexec.h |  1 -
>>arch/powerpc/kexec/file_load.c   | 32 -
>>drivers/of/Makefile  |  1 +
>>drivers/of/kexec.c   | 61 
>>include/linux/kexec.h|  5 +++
>>5 files changed, 67 insertions(+), 33 deletions(-)
>>create mode 100644 drivers/of/kexec.c
>>
>> diff --git a/arch/powerpc/include/asm/kexec.h
>> b/arch/powerpc/include/asm/kexec.h
>> index 55d6ede30c19..7c223031ecdd 100644
>> --- a/arch/powerpc/include/asm/kexec.h
>> +++ b/arch/powerpc/include/asm/kexec.h
>> @@ -126,7 +126,6 @@ int setup_purgatory(struct kimage *image, const void
>> *slave_code,
>>int setup_new_fdt(const struct kimage *image, void *fdt,
>>  unsigned long initrd_load_addr, unsigned long initrd_len,
>>  const char *cmdline);
>> -int delete_fdt_mem_rsv(void *fdt, unsigned long start, unsigned long 
>> size);
>>#ifdef CONFIG_PPC64
>>struct kexec_buf;
>> diff --git a/arch/powerpc/kexec/file_load.c 
>> b/arch/powerpc/kexec/file_load.c
>> index 9a232bc36c8f..9efc98b1e2ae 100644
>> --- a/arch/powerpc/kexec/file_load.c
>> +++ b/arch/powerpc/kexec/file_load.c
>> @@ -109,38 +109,6 @@ int setup_purgatory(struct kimage *image, const void
>> *slave_code,
>>return 0;
>>}
>> -/**
>> - * delete_fdt_mem_rsv - delete memory reservation with given address and
>> size
>> - *
>> - * Return: 0 on success, or negative errno on error.
>> - */
>> -int delete_fdt_mem_rsv(void *fdt, unsigned long start, unsigned long 
>> size)
>> -{
>> -int i, ret, num_rsvs = fdt_num_mem_rsv(fdt);
>> -
>> -for (i = 0; i < num_rsvs; i++) {
>> -uint64_t rsv_start, rsv_size;
>> -
>> -ret = fdt_get_mem_rsv(fdt, i, _start, _size);
>> -if (ret) {
>> -pr_err("Malformed device tree.\n");
>> -return -EINVAL;
>> -}
>> -
>> -if (rsv_start == start && rsv_size == size) {
>> -ret = fdt_del_mem_rsv(fdt, i);
>> -if (ret) {
>> -pr_err("Error deleting device tree reservation.\n");
>> -return -EINVAL;
>> -}
>> -
>> -return 0;
>> -}
>> -}
>> -
>> -return -ENOENT;
>> -}
>> -
>>/*
>> * setup_new_fdt - modify /chosen and memory reservation for the next
>> kernel
>> * @image:kexec image being loaded.
>> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
>> index 6e1e5212f058..77d24712c0c8 100644
>> --- a/drivers/of/Makefile
>> +++ b/drivers/of/Makefile
>> @@ -13,5 +13,6 @@ obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
>>obj-$(CONFIG_OF_RESOLVE)  += resolver.o
>>obj-$(CONFIG_OF_OVERLAY) += overlay.o
>>obj-$(CONFIG_OF_NUMA) += of_numa.o
>> +obj-$(CONFIG_OF_FLATTREE) += kexec.o
>
> Isn't this too broad? kexec.o will only be useful to kernel configs
> which enable CONFIG_KEXEC_FILE, so perhaps do:
>
> ifdef CONFIG_OF_FLATTREE
> ifdef CONFIG_KEXEC_FILE
> obj-y += kexec.o
> endif
> endif
>
> What do you think?
 Per Rob's feedback on v9 patch set, I have moved all the architecture
 independent ima kexec functions to a single file "drivers/of/kexec.c"
 Since these functions are enabled on different kernel CONFIGs, I have
 used IS_ENABLED(CONFIG_XYZ) macro instead of "#ifdef" in the C file to
 conditionally compile.
>>> Per Rob's feedback on the v9 patch, I'll keep the ima kexec functions in a
>>>

How can a userspace program tell if the system supports the ACPI S4 state (Suspend-to-Disk)?

2020-12-11 Thread Dexuan Cui

Hi all,
It looks like Linux can hibernate even if the system does not support the ACPI
S4 state, as long as the system can shut down, so "cat /sys/power/state"
always contains "disk", unless we specify the kernel parameter "nohibernate"
or we use LOCKDOWN_HIBERNATION.

In some scenarios IMO it can still be useful if the userspace is able to detect
if the ACPI S4 state is supported or not, e.g. when a Linux guest runs on 
Hyper-V, Hyper-V uses the virtual ACPI S4 state as an indicator of the proper
support of the tool stack on the host, i.e. the guest is discouraged from 
trying hibernation if the state is not supported.

I know we can check the S4 state by 'dmesg':

# dmesg |grep ACPI: | grep support
[3.034134] ACPI: (supports S0 S4 S5)

But this method is unreliable because the kernel msg buffer can be filled
and overwritten. Is there any better method? If not, do you think if the
below patch is appropriate? Thanks!

diff --git a/kernel/power/main.c b/kernel/power/main.c
index 0aefd6f57e0a..931a1526ea69 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -600,8 +601,12 @@ static ssize_t state_show(struct kobject *kobj, struct 
kobj_attribute *attr,
s += sprintf(s,"%s ", pm_states[i]);

 #endif
-   if (hibernation_available())
-   s += sprintf(s, "disk ");
+   if (hibernation_available()) {
+   if (acpi_sleep_state_supported(ACPI_STATE_S4))
+   s += sprintf(s, "disk+ ");
+   else
+   s += sprintf(s, "disk ");
+   }
if (s != buf)
/* convert the last space to a newline */
*(s-1) = '\n';

Thanks,
-- Dexuan

Re: [patch 1/3] tick: Remove pointless cpu valid check in hotplug code

2020-12-11 Thread Frederic Weisbecker

On Sat, Dec 12, 2020 at 01:16:12AM +0100, Thomas Gleixner wrote:
> On Fri, Dec 11 2020 at 23:21, Frederic Weisbecker wrote:
> > On Sun, Dec 06, 2020 at 10:12:54PM +0100, Thomas Gleixner wrote:
> >> tick_handover_do_timer() which is invoked when a CPU is unplugged has a
> >> @@ -407,17 +407,13 @@ EXPORT_SYMBOL_GPL(tick_broadcast_oneshot
> >>  /*
> >>   * Transfer the do_timer job away from a dying cpu.
> >>   *
> >> - * Called with interrupts disabled. Not locking required. If
> >> + * Called with interrupts disabled. No locking required. If
> >>   * tick_do_timer_cpu is owned by this cpu, nothing can change it.
> >>   */
> >>  void tick_handover_do_timer(void)
> >>  {
> >> -  if (tick_do_timer_cpu == smp_processor_id()) {
> >> -  int cpu = cpumask_first(cpu_online_mask);
> >> -
> >> -  tick_do_timer_cpu = (cpu < nr_cpu_ids) ? cpu :
> >> -  TICK_DO_TIMER_NONE;
> >> -  }
> >> +  if (tick_do_timer_cpu == smp_processor_id())
> >> +  tick_do_timer_cpu = cpumask_first(cpu_online_mask);
> >
> > I was about to whine that this randomly chosen CPU may be idle and leave
> > the timekeeping stale until I realized that stop_machine() is running at 
> > that
> > time. Might be worth adding a comment about that.
> >
> > Also why not just setting it to TICK_DO_TIMER_NONE and be done with it? 
> > Perhaps
> > to avoid that all the CPUs to compete and contend on jiffies update after 
> > stop
> > machine?
> 
> No. Because we'd need to add the NONE magic to NOHZ=n kernels which does
> not make sense.

I forgot about that other half of the world.

Thanks.

Re: [RFC PATCH 2/4] of: Add a common kexec FDT setup function


On 12/11/20 2:10 PM, Rob Herring wrote:

Hi Rob,


Both arm64 and powerpc do essentially the same FDT /chosen setup for
kexec. We can simply combine everything each arch does. The differences
are either omissions that arm64 should have or additional properties
that will be ignored.

The differences relative to the arm64 version:
- If /chosen doesn't exist, it will be created (should never happen).
- Any old dtb and initrd reserved memory will be released.
- The new initrd and elfcorehdr are marked reserved.
- "linux,booted-from-kexec" is set.

The differences relative to the powerpc version:
- "kaslr-seed" and "rng-seed" may be set.
- "linux,elfcorehdr" is set.
- Any existing "linux,usable-memory-range" is removed.

Signed-off-by: Rob Herring 
---
This could be taken a step further and do the allocation of the new
FDT. The difference is arm64 uses vmalloc and powerpc uses kmalloc. The
arm64 version also retries with a bigger allocation. That seems
unnecessary.
---
  drivers/of/Makefile |   1 +
  drivers/of/kexec.c  | 228 
  include/linux/of.h  |   5 +
  3 files changed, 234 insertions(+)
  create mode 100644 drivers/of/kexec.c

diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index 6e1e5212f058..8ce11955afde 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -13,5 +13,6 @@ obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
  obj-$(CONFIG_OF_RESOLVE)  += resolver.o
  obj-$(CONFIG_OF_OVERLAY) += overlay.o
  obj-$(CONFIG_OF_NUMA) += of_numa.o
+obj-$(CONFIG_KEXEC_FILE) += kexec.o


For the functions moved from powerpc & arm64 to "drivers/of/kexec.c" in 
this patch, compiling kexec.c when CONFIG_KEXEC_FILE is enabled is fine. 
But when more functions (such as remove_ima_buffer()) are moved to this 
file, Makefile needs to be updated for other ima kexec related CONFIGs.


Why not compile kexec.c when CONFIG_OF_FLATTREE is enabled, and handle 
other CONFIGs using IS_ENABLED (like you'd suggested earlier)?


  
  obj-$(CONFIG_OF_UNITTEST) += unittest-data/

diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
new file mode 100644
index ..66787be081fe
--- /dev/null
+++ b/drivers/of/kexec.c
@@ -0,0 +1,228 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2020 Arm Limited
+ *
+ * Based on arch/arm64/kernel/machine_kexec_file.c:
+ *  Copyright (C) 2018 Linaro Limited
+ *
+ * And arch/powerpc/kexec/file_load.c:
+ *  Copyright (C) 2016  IBM Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* relevant device tree properties */
+#define FDT_PROP_KEXEC_ELFHDR  "linux,elfcorehdr"
+#define FDT_PROP_MEM_RANGE "linux,usable-memory-range"
+#define FDT_PROP_INITRD_START  "linux,initrd-start"
+#define FDT_PROP_INITRD_END"linux,initrd-end"
+#define FDT_PROP_BOOTARGS  "bootargs"
+#define FDT_PROP_KASLR_SEED"kaslr-seed"
+#define FDT_PROP_RNG_SEED  "rng-seed"
+#define RNG_SEED_SIZE  128



+
+/**
+ * fdt_find_and_del_mem_rsv - delete memory reservation with given address and 
size
+ *
+ * Return: 0 on success, or negative errno on error.
+ */
+static int fdt_find_and_del_mem_rsv(void *fdt, unsigned long start, unsigned 
long size)
+{
+   int i, ret, num_rsvs = fdt_num_mem_rsv(fdt);
+
+   for (i = 0; i < num_rsvs; i++) {
+   u64 rsv_start, rsv_size;
+
+   ret = fdt_get_mem_rsv(fdt, i, _start, _size);
+   if (ret) {
+   pr_err("Malformed device tree.\n");
+   return -EINVAL;
+   }
+
+   if (rsv_start == start && rsv_size == size) {
+   ret = fdt_del_mem_rsv(fdt, i);
+   if (ret) {
+   pr_err("Error deleting device tree 
reservation.\n");
+   return -EINVAL;
+   }
+
+   return 0;
+   }
+   }
+
+   return -ENOENT;
+}
+
+/*
+ * of_kexec_setup_new_fdt - modify /chosen and memory reservation for the next 
kernel
+ *
+ * @image: kexec image being loaded.
+ * @fdt:   Flattened device tree for the next kernel.
+ * @initrd_load_addr:  Address where the next initrd will be loaded.
+ * @initrd_len:Size of the next initrd, or 0 if there will be 
none.
+ * @cmdline:   Command line for the next kernel, or NULL if there will
+ * be none.
nit: alignment of the parameter description seems to be off. But it 
could be due to my mail client.



+ *
+ * Return: 0 on success, or negative errno on error.
+ */
+int of_kexec_setup_new_fdt(const struct kimage *image, void *fdt,
+  unsigned long initrd_load_addr, unsigned long 
initrd_len,
+  const char *cmdline)
+{
+   int ret, chosen_node;
+   const void *prop;
+
+   /* Remove memory reservation for the current device tree. */
+   ret =

Re: [PATCH v8 4/8] IMA: add policy rule to measure critical data

2020-12-11 Thread Tushar Sugandhi





On 2020-12-11 4:25 p.m., Tyler Hicks wrote:

On 2020-12-11 15:58:03, Tushar Sugandhi wrote:

A new IMA policy rule is needed for the IMA hook
ima_measure_critical_data() and the corresponding func CRITICAL_DATA for
measuring the input buffer. The policy rule should ensure the buffer
would get measured only when the policy rule allows the action. The
policy rule should also support the necessary constraints (flags etc.)
for integrity critical buffer data measurements.

Add a policy rule to define the constraints for restricting integrity
critical data measurements.

Signed-off-by: Tushar Sugandhi 
---
  Documentation/ABI/testing/ima_policy |  2 +-
  security/integrity/ima/ima_policy.c  | 34 
  2 files changed, 31 insertions(+), 5 deletions(-)

diff --git a/Documentation/ABI/testing/ima_policy 
b/Documentation/ABI/testing/ima_policy
index e35263f97fc1..6ec7daa87cba 100644
--- a/Documentation/ABI/testing/ima_policy
+++ b/Documentation/ABI/testing/ima_policy
@@ -32,7 +32,7 @@ Description:
func:= 
[BPRM_CHECK][MMAP_CHECK][CREDS_CHECK][FILE_CHECK]MODULE_CHECK]
[FIRMWARE_CHECK]
[KEXEC_KERNEL_CHECK] [KEXEC_INITRAMFS_CHECK]
-   [KEXEC_CMDLINE] [KEY_CHECK]
+   [KEXEC_CMDLINE] [KEY_CHECK] [CRITICAL_DATA]
mask:= [[^]MAY_READ] [[^]MAY_WRITE] [[^]MAY_APPEND]
   [[^]MAY_EXEC]
fsmagic:= hex value
diff --git a/security/integrity/ima/ima_policy.c 
b/security/integrity/ima/ima_policy.c
index a09d1a41a290..07116ff35c25 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -85,6 +85,7 @@ struct ima_rule_entry {
} lsm[MAX_LSM_RULES];
char *fsname;
struct ima_rule_opt_list *keyrings; /* Measure keys added to these 
keyrings */
+   struct ima_rule_opt_list *data_source; /* Measure data from this source 
*/


Argh, there are still some more instances of data_source sneaking into
this patch too early instead of waiting until the next patch.


I kept it purposefully in this patch so that the
"case CRITICAL_DATA:" could be properly defined.

Also, my impression was rule->data_source is not part of the user facing
policy.

Whereas IMA_DATA_SOURCE, Opt_data_source, data_source=%s are.
That's why they are part of Patch #5.

Patch #5 IMA: limit critical data measurement based on a label


struct ima_template_desc *template;
  };
  
@@ -479,6 +480,12 @@ static bool ima_match_rule_data(struct ima_rule_entry *rule,
  
  		opt_list = rule->keyrings;

break;
+   case CRITICAL_DATA:
+   if (!rule->data_source)
+   return true;
+
+   opt_list = rule->data_source;
+   break;


I guess this case should unconditionally return true in this patch and
then the include this additional logic in the next patch.

Sorry, I missed these on my last review.


No worries.

As I mentioned above, I kept it purposefully in this patch since
my impression was rule->data_source is not part of the user facing
policy.

But I can simply return true here as you suggested, and move the logic 
to the next patch.


+   case CRITICAL_DATA:
+   if (!rule->data_source)
+   return true;
+
+   opt_list = rule->data_source;
+   break;


~Tushar

Re: [PATCH linux hwmon-next v5 3/3] dt-bindings: (hwmon/sbtsi_tmep) Add SB-TSI hwmon driver bindings

2020-12-11 Thread Kun Yi

On Fri, Dec 11, 2020 at 3:51 PM Guenter Roeck  wrote:
>
> On 12/11/20 1:54 PM, Kun Yi wrote:
> > Document device tree bindings for AMD SB-TSI emulated temperature
> > sensor.
> >
> > Signed-off-by: Kun Yi 
>
> Any reason for dropping Rob's Reviewed-by: tag ?
>
> Guenter

Sorry that was unintentional.

>
> > ---
> >  .../devicetree/bindings/hwmon/amd,sbtsi.yaml  | 54 +++
> >  1 file changed, 54 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/hwmon/amd,sbtsi.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/hwmon/amd,sbtsi.yaml 
> > b/Documentation/devicetree/bindings/hwmon/amd,sbtsi.yaml
> > new file mode 100644
> > index ..446b09f1ce94
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/hwmon/amd,sbtsi.yaml
> > @@ -0,0 +1,54 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/hwmon/amd,sbtsi.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: >
> > +  Sideband interface Temperature Sensor Interface (SB-TSI) compliant
> > +  AMD SoC temperature device
> > +
> > +maintainers:
> > +  - Kun Yi 
> > +  - Supreeth Venkatesh 
> > +
> > +description: |
> > +  SB Temperature Sensor Interface (SB-TSI) is an SMBus compatible
> > +  interface that reports AMD SoC's Ttcl (normalized temperature),
> > +  and resembles a typical 8-pin remote temperature sensor's I2C interface
> > +  to BMC. The emulated thermal sensor can report temperatures in increments
> > +  of 0.125 degrees, ranging from 0 to 255.875.
> > +
> > +properties:
> > +  compatible:
> > +enum:
> > +  - amd,sbtsi
> > +
> > +  reg:
> > +maxItems: 1
> > +description: |
> > +  I2C bus address of the device as specified in Section 6.3.1 of the
> > +  SoC register reference. The SB-TSI address is normally 98h for socket
> > +  0 and 90h for socket 1, but it could vary based on hardware address
> > +  select pins.
> > +  \[open source SoC register reference\]
> > +https://www.amd.com/system/files/TechDocs/56255_OSRR.pdf
> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > +  - |
> > +i2c0 {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +sbtsi@4c {
> > +compatible = "amd,sbtsi";
> > +reg = <0x4c>;
> > +};
> > +};
> > +...
> >
>


-- 
Regards,
Kun

[PATCH] driver core: platform: don't oops on unbound devices

2020-12-11 Thread Dmitry Baryshkov

Platform code stopped checking if the device is bound to the actual
platform driver, thus calling non-existing drv->shutdown(). Verify that
_dev->driver is not NULL before calling remove/shutdown callbacks.

Signed-off-by: Dmitry Baryshkov 
Fixes: 9c30921fe799 ("driver core: platform: use bus_type functions")
---
 drivers/base/platform.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 0358dc3ea3ad..93f44e69b472 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1342,7 +1342,7 @@ static int platform_remove(struct device *_dev)
struct platform_device *dev = to_platform_device(_dev);
int ret = 0;
 
-   if (drv->remove)
+   if (_dev->driver && drv->remove)
ret = drv->remove(dev);
dev_pm_domain_detach(_dev, true);
 
@@ -1354,7 +1354,7 @@ static void platform_shutdown(struct device *_dev)
struct platform_driver *drv = to_platform_driver(_dev->driver);
struct platform_device *dev = to_platform_device(_dev);
 
-   if (drv->shutdown)
+   if (_dev->driver && drv->shutdown)
drv->shutdown(dev);
 }
 
-- 
2.29.2

[PATCH net-next] seg6: fix the max number of supported SRv6 behavior attributes

2020-12-11 Thread Andrea Mayer

The set of required attributes for a given SRv6 behavior is identified
using a bitmap stored in an unsigned long, since the initial design of
SRv6 networking in Linux. Recently the same approach has been used for
identifying the optional attributes.

We realized that choosing an unsigned long to store a bitmap is not a
proper design choice considering that new attributes can be defined in the
future. The problem is that the size of an unsigned long can be 32 or 64
bits depending on the architecture. Therefore the maximum number of
attributes that can be defined currently is 32 or 64 depending on the
architecture. This issue has not caused any harm so far, because new
attributes are defined statically in the kernel code, and currently only 10
attributes have been defined.

With this patch, we set the maximum number of attributes that can be
supported by the SRv6 networking in Linux to be 64 regardless of the
architecture.

We changed the unsigned long type of the bitmaps to the u64 type and
adapted the code accordingly. In particular:

 - We replaced all patterns (1 << i) with the macro SEG6_F_ATTR(i) in order
   to address overflow issues caused by 32-bit signed arithmetic.

   Many thanks to Colin Ian King for catching the overflow problem and
   inspiring this patch;

 - At compile time we verify that the total number of attributes does not
   exceed the fixed value of 64. Otherwise, kernel build fails forcing
   developers to reconsider adding a new attribute or extending the
   total number of supported attributes by the SRv6 networking.

Fixes: d1df6fd8a1d2 ("ipv6: sr: define core operations for seg6local 
lightweight tunnel")
Fixes: 140f04c33bbc ("ipv6: sr: implement several seg6local actions")
Fixes: 891ef8dd2a8d ("ipv6: sr: implement additional seg6local actions")
Fixes: 004d4b274e2a ("ipv6: sr: Add seg6local action End.BPF")
Fixes: 964adce526a4 ("seg6: improve management of behavior attributes")
Fixes: 0a3021f1d4e5 ("seg6: add support for optional attributes in SRv6 
behaviors")
Fixes: 664d6f86868b ("seg6: add support for the SRv6 End.DT4 behavior")
Fixes: 20a081b7984c ("seg6: add VRF support for SRv6 End.DT6 behavior")
Signed-off-by: Andrea Mayer 
---
 include/uapi/linux/seg6_local.h | 10 
 net/ipv6/seg6_local.c   | 89 ++---
 2 files changed, 60 insertions(+), 39 deletions(-)

diff --git a/include/uapi/linux/seg6_local.h b/include/uapi/linux/seg6_local.h
index 3b39ef1dbb46..81b3ac430670 100644
--- a/include/uapi/linux/seg6_local.h
+++ b/include/uapi/linux/seg6_local.h
@@ -27,9 +27,19 @@ enum {
SEG6_LOCAL_OIF,
SEG6_LOCAL_BPF,
SEG6_LOCAL_VRFTABLE,
+   /* new attributes go here */
__SEG6_LOCAL_MAX,
+
+   /* Support up to 64 different types of attributes.
+*
+* If you need to add a new attribute, please make sure that it DOES
+* NOT violate the constraint of having a maximum of 64 possible
+* attributes.
+*/
+   __SEG6_LOCAL_MAX_SUPP = 64,
 };
 #define SEG6_LOCAL_MAX (__SEG6_LOCAL_MAX - 1)
+#define SEG6_LOCAL_MAX_SUPP (__SEG6_LOCAL_MAX_SUPP)
 
 enum {
SEG6_LOCAL_ACTION_UNSPEC= 0,
diff --git a/net/ipv6/seg6_local.c b/net/ipv6/seg6_local.c
index b07f7c1c82a4..4e657c48e24d 100644
--- a/net/ipv6/seg6_local.c
+++ b/net/ipv6/seg6_local.c
@@ -31,6 +31,8 @@
 #include 
 #include 
 
+#define SEG6_F_ATTR(i) (((u64)1) << (i))
+
 struct seg6_local_lwt;
 
 /* callbacks used for customizing the creation and destruction of a behavior */
@@ -42,7 +44,7 @@ struct seg6_local_lwtunnel_ops {
 
 struct seg6_action_desc {
int action;
-   unsigned long attrs;
+   u64 attrs;
 
/* The optattrs field is used for specifying all the optional
 * attributes supported by a specific behavior.
@@ -56,7 +58,7 @@ struct seg6_action_desc {
 * required the same attribute CANNOT be set as optional and vice
 * versa.
 */
-   unsigned long optattrs;
+   u64 optattrs;
 
int (*input)(struct sk_buff *skb, struct seg6_local_lwt *slwt);
int static_headroom;
@@ -109,7 +111,7 @@ struct seg6_local_lwt {
/* unlike the required attrs, we have to track the optional attributes
 * that have been effectively parsed.
 */
-   unsigned long parsed_optattrs;
+   u64 parsed_optattrs;
 };
 
 static struct seg6_local_lwt *seg6_local_lwtunnel(struct lwtunnel_state *lwt)
@@ -657,11 +659,11 @@ static int seg6_end_dt4_build(struct seg6_local_lwt 
*slwt, const void *cfg,
 static enum
 seg6_end_dt_mode seg6_end_dt6_parse_mode(struct seg6_local_lwt *slwt)
 {
-   unsigned long parsed_optattrs = slwt->parsed_optattrs;
+   u64 parsed_optattrs = slwt->parsed_optattrs;
bool legacy, vrfmode;
 
-   legacy  = !!(parsed_optattrs & (1 << SEG6_LOCAL_TABLE));
-   vrfmode = !!(parsed_optattrs & (1 << SEG6_LOCAL_VRFTABLE));
+   legacy  = !!(parsed_optattrs & SEG6_F_ATTR(SEG6_LOCAL_TABLE));
+   vrfmode

Re: [PATCH 0/6] mmc: core: hs400(es) fix probe/init

2020-12-11 Thread Chris Ruehl


No Comments ?

Chris

On 8/12/2020 2:18 pm, Chris Ruehl wrote:

Fix the probe if hs400-1_8v / hs400-1_2v is used in the
dts and mmc-hs400-enhanced-strobe isn't set.
That was the first attemped, but it turns out that some
more cleanups and simplifications can be done.

* move mmc_select_hs400() in between hs200 & hs400es (preparation)
* make mmc_select_hs400() independent and move it out
   of the hs200. Run hs400 tuning inside mmc_select_hs400();
* merge hs400 with hs400es function
* remove mmc_select_hs400es function
* remove mmc_hs200_tuning()
* cleanup host->caps2 for hs400-1_8(2)v


Signed-off-by: Chris Ruehl 
---
Replace patch set [PATCH 0/3] mmc: core: hs400 fix probe

Re: [RFC PATCH 1/4] powerpc: Rename kexec elfcorehdr_addr to elf_headers_mem


On 12/11/20 2:10 PM, Rob Herring wrote:

Hi Rob,


Align with arm64 name so common code can use it.


As you'd stated in the cover letter, a better patch description would be 
good to have here.


Code changes look good to me.

Reviewed-by: Lakshmi Ramasubramanian 

thanks,
 -lakshmi



Signed-off-by: Rob Herring 
---
  arch/powerpc/include/asm/kexec.h  | 2 +-
  arch/powerpc/kexec/file_load.c| 4 ++--
  arch/powerpc/kexec/file_load_64.c | 4 ++--
  3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/include/asm/kexec.h b/arch/powerpc/include/asm/kexec.h
index 55d6ede30c19..dbf09d2f36d0 100644
--- a/arch/powerpc/include/asm/kexec.h
+++ b/arch/powerpc/include/asm/kexec.h
@@ -108,7 +108,7 @@ struct kimage_arch {
unsigned long backup_start;
void *backup_buf;
  
-	unsigned long elfcorehdr_addr;

+   unsigned long elf_headers_mem;
unsigned long elf_headers_sz;
void *elf_headers;
  
diff --git a/arch/powerpc/kexec/file_load.c b/arch/powerpc/kexec/file_load.c

index 9a232bc36c8f..e452b11df631 100644
--- a/arch/powerpc/kexec/file_load.c
+++ b/arch/powerpc/kexec/file_load.c
@@ -45,7 +45,7 @@ char *setup_kdump_cmdline(struct kimage *image, char *cmdline,
return NULL;
  
  	elfcorehdr_strlen = sprintf(cmdline_ptr, "elfcorehdr=0x%lx ",

-   image->arch.elfcorehdr_addr);
+   image->arch.elf_headers_mem);
  
  	if (elfcorehdr_strlen + cmdline_len > COMMAND_LINE_SIZE) {

pr_err("Appending elfcorehdr= exceeds cmdline size\n");
@@ -263,7 +263,7 @@ int setup_new_fdt(const struct kimage *image, void *fdt,
 * Avoid elfcorehdr from being stomped on in kdump kernel by
 * setting up memory reserve map.
 */
-   ret = fdt_add_mem_rsv(fdt, image->arch.elfcorehdr_addr,
+   ret = fdt_add_mem_rsv(fdt, image->arch.elf_headers_mem,
  image->arch.elf_headers_sz);
if (ret) {
pr_err("Error reserving elfcorehdr memory: %s\n",
diff --git a/arch/powerpc/kexec/file_load_64.c 
b/arch/powerpc/kexec/file_load_64.c
index c69bcf9b547a..a05c19b3cc60 100644
--- a/arch/powerpc/kexec/file_load_64.c
+++ b/arch/powerpc/kexec/file_load_64.c
@@ -815,7 +815,7 @@ static int load_elfcorehdr_segment(struct kimage *image, 
struct kexec_buf *kbuf)
goto out;
}
  
-	image->arch.elfcorehdr_addr = kbuf->mem;

+   image->arch.elf_headers_mem = kbuf->mem;
image->arch.elf_headers_sz = headers_sz;
image->arch.elf_headers = headers;
  out:
@@ -851,7 +851,7 @@ int load_crashdump_segments_ppc64(struct kimage *image,
return ret;
}
pr_debug("Loaded elf core header at 0x%lx, bufsz=0x%lx memsz=0x%lx\n",
-image->arch.elfcorehdr_addr, kbuf->bufsz, kbuf->memsz);
+image->arch.elf_headers_mem, kbuf->bufsz, kbuf->memsz);
  
  	return 0;

  }

Re: objtool crashes with some clang produced .o files

2020-12-11 Thread Nick Desaulniers

On Fri, Dec 11, 2020 at 4:42 PM Nick Desaulniers
 wrote:
>
> On Fri, Dec 11, 2020 at 12:57 PM Nick Desaulniers
>  wrote:
> >
> > Thanks for the patch!
> >
> > Reviewed-by: Nick Desaulniers 
> > Link: https://github.com/ClangBuiltLinux/linux/issues/1207
>
> Arnd reported another objtool warning/error from another randconfig in
> https://github.com/ClangBuiltLinux/linux/issues/1209 and CrOS just hit
> this as well.
>
> I haven't been able to isolate the configs yet (Arnd has posted the
> full config: https://pastebin.com/wwwhUL8L
>
> $ ./tools/objtool/objtool orc generate  --no-fp --no-unreachable
> --retpoline arch/x86/entry/thunk_64.o
> arch/x86/entry/thunk_64.o: warning: objtool: missing symbol for insn
> at offset 0x3e
>
> Is the offset 0x3e referring to the final `ret` instruction in
> preempt_schedule_notrace_thunk?  Observing insn_to_reloc_sym_addend()
> (with your patch applied), it looks like both calls to
> find_symbol_containing() with offset and offset-1 returns NULL.  I'm
> curious if there's another quirk going on here, or possibly a config
> from the randconfig that's messing up the special case? I don't follow
> the comment about:
> 119* Hack alert.  This happens when we need to reference
> 120* the NOP pad insn immediately after the function.
> 121*/
>
> Attached the object file FWIW.

Resending with the attachment renamed; I just got a bounceback from
Josh's mailer daemon.
-- 
Thanks,
~Nick Desaulniers
ELF>?@@UH??WVRQPAPAQARAS??UH??WVRQPAPAQARAS??A[AZAYAXXYZ^_]?BS#

*.rela.textpreempt_schedule_thunkpreempt_schedule_notrace_thunkpreempt_schedulepreempt_schedule_notrace.strtab.symtabl(|@??0t?x

Re: [patch 15/30] pinctrl: nomadik: Use irq_has_action()

On Thu, Dec 10, 2020 at 8:42 PM Thomas Gleixner  wrote:

> Let the core code do the fiddling with irq_desc.
>
> Signed-off-by: Thomas Gleixner 
> Cc: Linus Walleij 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-g...@vger.kernel.org

Reviewed-by: Linus Walleij 

I suppose you will funnel this directly to Torvalds, else tell me and
I'll apply it to my tree.

Yours,
Linus Walleij

Re: [PATCH v2] pinctrl: remove empty lines in pinctrl subsystem

On Thu, Dec 10, 2020 at 6:35 PM Zhaoyu Liu  wrote:

> Remove all empty lines at the end of functions in pinctrl subsystem,
> make the code neat.
> Target files: grep -nwR -B1 ^} drivers/pinctrl/* | grep '[0-9]-$' | less
>
> Reviewed-by: Linus Walleij 
> Reviewed-by: Andy Shevchenko 
> Signed-off-by: Zhaoyu Liu 

Nice!
But this doesn't apply to the current "devel" branch in my tree.
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/log/?h=devel

Please rebase and resend!

Yours,
Linus Walleij

Re: [PATCH -next] pinctrl/spear: simplify the return expression of spear300_pinctrl_probe()

On Thu, Dec 10, 2020 at 2:57 PM Zheng Yongjun  wrote:

> Simplify the return expression.
>
> Signed-off-by: Zheng Yongjun 

Patch applied.

Yours,
Linus Walleij

Re: objtool crashes with some clang produced .o files

2020-12-11 Thread Nick Desaulniers

On Fri, Dec 11, 2020 at 12:57 PM Nick Desaulniers
 wrote:
>
> Thanks for the patch!
>
> Reviewed-by: Nick Desaulniers 
> Link: https://github.com/ClangBuiltLinux/linux/issues/1207

Arnd reported another objtool warning/error from another randconfig in
https://github.com/ClangBuiltLinux/linux/issues/1209 and CrOS just hit
this as well.

I haven't been able to isolate the configs yet (Arnd has posted the
full config: https://pastebin.com/wwwhUL8L

$ ./tools/objtool/objtool orc generate  --no-fp --no-unreachable
--retpoline arch/x86/entry/thunk_64.o
arch/x86/entry/thunk_64.o: warning: objtool: missing symbol for insn
at offset 0x3e

Is the offset 0x3e referring to the final `ret` instruction in
preempt_schedule_notrace_thunk?  Observing insn_to_reloc_sym_addend()
(with your patch applied), it looks like both calls to
find_symbol_containing() with offset and offset-1 returns NULL.  I'm
curious if there's another quirk going on here, or possibly a config
from the randconfig that's messing up the special case? I don't follow
the comment about:
119* Hack alert.  This happens when we need to reference
120* the NOP pad insn immediately after the function.
121*/

Attached the object file FWIW.
-- 
Thanks,
~Nick Desaulniers

thunk_64.o
Description: Binary data

Re: [PATCH -next] gpio: simplify the return expression of cs5535_gpio_probe()

On Thu, Dec 10, 2020 at 2:55 PM Zheng Yongjun  wrote:

> Simplify the return expression.
>
> Signed-off-by: Zheng Yongjun 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH -next] pinctrl/mediatek: simplify the return expression of mtk_pinconf_bias_disable_set_rev1()

On Thu, Dec 10, 2020 at 2:58 PM Zheng Yongjun  wrote:

> Simplify the return expression.
>
> Signed-off-by: Zheng Yongjun 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH] kvm:vmx:code changes in handle_io() to save some CPU cycles.

2020-12-11 Thread Paolo Bonzini


On 10/12/20 09:15, Stephen Zhang wrote:

code changes in handle_io() to save some CPU cycles.

Signed-off-by: Stephen Zhang 
---
  arch/x86/kvm/vmx/vmx.c | 5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 47b8357..109bcf64 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -4899,15 +4899,14 @@ static int handle_triple_fault(struct kvm_vcpu *vcpu)
  static int handle_io(struct kvm_vcpu *vcpu)
  {
unsigned long exit_qualification;
-   int size, in, string;
+   int size, in;
unsigned port;
  
  	exit_qualification = vmx_get_exit_qual(vcpu);

-   string = (exit_qualification & 16) != 0;
  
  	++vcpu->stat.io_exits;
  
-	if (string)

+   if (exit_qualification & 16)
return kvm_emulate_instruction(vcpu, 0);
  
  	port = exit_qualification >> 16;




I would be very surprised if there's any change in the assembly code 
after this patch.


Paolo

Re: [PATCH v8 8/8] selinux: include a consumer of the new IMA critical data hook


On 12/11/20 4:32 PM, Tyler Hicks wrote:

On 2020-12-11 15:58:07, Tushar Sugandhi wrote:

From: Lakshmi Ramasubramanian 

SELinux stores the active policy in memory, so the changes to this data
at runtime would have an impact on the security guarantees provided
by SELinux. Measuring in-memory SELinux policy through IMA subsystem
provides a secure way for the attestation service to remotely validate
the policy contents at runtime.

Measure the hash of the loaded policy by calling the IMA hook
ima_measure_critical_data(). Since the size of the loaded policy can
be large (several MB), measure the hash of the policy instead of
the entire policy to avoid bloating the IMA log entry.

Add "selinux" to the list of supported data sources maintained by IMA
to enable measuring SELinux data.

To enable SELinux data measurement, the following steps are required:

1, Add "ima_policy=critical_data" to the kernel command line arguments
to enable measuring SELinux data at boot time.
For example,
   BOOT_IMAGE=/boot/vmlinuz-5.10.0-rc1+ 
root=UUID=fd643309-a5d2-4ed3-b10d-3c579a5fab2f ro nomodeset security=selinux 
ima_policy=critical_data

2, Add the following rule to /etc/ima/ima-policy
measure func=CRITICAL_DATA data_source=selinux

Sample measurement of the hash of SELinux policy:

To verify the measured data with the current SELinux policy run
the following commands and verify the output hash values match.

   sha256sum /sys/fs/selinux/policy | cut -d' ' -f 1

   grep "selinux-policy-hash" 
/sys/kernel/security/integrity/ima/ascii_runtime_measurements | tail -1 | cut -d' ' -f 6

Note that the actual verification of SELinux policy would require loading
the expected policy into an identical kernel on a pristine/known-safe
system and run the sha256sum /sys/kernel/selinux/policy there to get
the expected hash.

Signed-off-by: Lakshmi Ramasubramanian 
Suggested-by: Stephen Smalley 


This looks good but I've got one small suggestion below if you roll a
v9. Feel free to add:

Reviewed-by: Tyler Hicks 


diff --git a/security/selinux/measure.c b/security/selinux/measure.c
new file mode 100644
index ..a070d8dae403
--- /dev/null
+++ b/security/selinux/measure.c
@@ -0,0 +1,81 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Measure SELinux state using IMA subsystem.
+ */
+#include 
+#include 
+#include 
+#include "security.h"
+
+/*
+ * This function creates a unique name by appending the timestamp to
+ * the given string. This string is passed as "event_name" to the IMA
+ * hook to measure the given SELinux data.
+ *
+ * The data provided by SELinux to the IMA subsystem for measuring may have
+ * already been measured (for instance the same state existed earlier).
+ * But for SELinux the current data represents a state change and hence
+ * needs to be measured again. To enable this, pass a unique "event_name"
+ * to the IMA hook so that IMA subsystem will always measure the given data.
+ *
+ * For example,
+ * At time T0 SELinux data to be measured is "foo". IMA measures it.
+ * At time T1 the data is changed to "bar". IMA measures it.
+ * At time T2 the data is changed to "foo" again. IMA will not measure it
+ * (since it was already measured) unless the event_name, for instance,
+ * is different in this call.
+ */
+static char *selinux_event_name(const char *name_prefix)
+{
+   char *event_name = NULL;
+   struct timespec64 cur_time;
+
+   ktime_get_real_ts64(_time);
+   event_name = kasprintf(GFP_KERNEL, "%s-%lld:%09ld", name_prefix,
+  cur_time.tv_sec, cur_time.tv_nsec);
+   return event_name;


There's no longer a need to store the return of kasprintf() in a
variable. Just 'return kasprint(...);' and get rid of the event_name
variable.



Sure - I'll make the change.

 -lakshmi

Re: [PATCH v8 8/8] selinux: include a consumer of the new IMA critical data hook

On 2020-12-11 15:58:07, Tushar Sugandhi wrote:
> From: Lakshmi Ramasubramanian 
> 
> SELinux stores the active policy in memory, so the changes to this data
> at runtime would have an impact on the security guarantees provided
> by SELinux. Measuring in-memory SELinux policy through IMA subsystem
> provides a secure way for the attestation service to remotely validate
> the policy contents at runtime.
> 
> Measure the hash of the loaded policy by calling the IMA hook
> ima_measure_critical_data(). Since the size of the loaded policy can
> be large (several MB), measure the hash of the policy instead of
> the entire policy to avoid bloating the IMA log entry.
> 
> Add "selinux" to the list of supported data sources maintained by IMA
> to enable measuring SELinux data.
> 
> To enable SELinux data measurement, the following steps are required:
> 
> 1, Add "ima_policy=critical_data" to the kernel command line arguments
>to enable measuring SELinux data at boot time.
> For example,
>   BOOT_IMAGE=/boot/vmlinuz-5.10.0-rc1+ 
> root=UUID=fd643309-a5d2-4ed3-b10d-3c579a5fab2f ro nomodeset security=selinux 
> ima_policy=critical_data
> 
> 2, Add the following rule to /etc/ima/ima-policy
>measure func=CRITICAL_DATA data_source=selinux
> 
> Sample measurement of the hash of SELinux policy:
> 
> To verify the measured data with the current SELinux policy run
> the following commands and verify the output hash values match.
> 
>   sha256sum /sys/fs/selinux/policy | cut -d' ' -f 1
> 
>   grep "selinux-policy-hash" 
> /sys/kernel/security/integrity/ima/ascii_runtime_measurements | tail -1 | cut 
> -d' ' -f 6
> 
> Note that the actual verification of SELinux policy would require loading
> the expected policy into an identical kernel on a pristine/known-safe
> system and run the sha256sum /sys/kernel/selinux/policy there to get
> the expected hash.
> 
> Signed-off-by: Lakshmi Ramasubramanian 
> Suggested-by: Stephen Smalley 

This looks good but I've got one small suggestion below if you roll a
v9. Feel free to add:

Reviewed-by: Tyler Hicks 

> diff --git a/security/selinux/measure.c b/security/selinux/measure.c
> new file mode 100644
> index ..a070d8dae403
> --- /dev/null
> +++ b/security/selinux/measure.c
> @@ -0,0 +1,81 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Measure SELinux state using IMA subsystem.
> + */
> +#include 
> +#include 
> +#include 
> +#include "security.h"
> +
> +/*
> + * This function creates a unique name by appending the timestamp to
> + * the given string. This string is passed as "event_name" to the IMA
> + * hook to measure the given SELinux data.
> + *
> + * The data provided by SELinux to the IMA subsystem for measuring may have
> + * already been measured (for instance the same state existed earlier).
> + * But for SELinux the current data represents a state change and hence
> + * needs to be measured again. To enable this, pass a unique "event_name"
> + * to the IMA hook so that IMA subsystem will always measure the given data.
> + *
> + * For example,
> + * At time T0 SELinux data to be measured is "foo". IMA measures it.
> + * At time T1 the data is changed to "bar". IMA measures it.
> + * At time T2 the data is changed to "foo" again. IMA will not measure it
> + * (since it was already measured) unless the event_name, for instance,
> + * is different in this call.
> + */
> +static char *selinux_event_name(const char *name_prefix)
> +{
> + char *event_name = NULL;
> + struct timespec64 cur_time;
> +
> + ktime_get_real_ts64(_time);
> + event_name = kasprintf(GFP_KERNEL, "%s-%lld:%09ld", name_prefix,
> +cur_time.tv_sec, cur_time.tv_nsec);
> + return event_name;

There's no longer a need to store the return of kasprintf() in a
variable. Just 'return kasprint(...);' and get rid of the event_name
variable.

Tyler

Re: [PATCH v8 4/8] IMA: add policy rule to measure critical data

On 2020-12-11 15:58:03, Tushar Sugandhi wrote:
> A new IMA policy rule is needed for the IMA hook
> ima_measure_critical_data() and the corresponding func CRITICAL_DATA for
> measuring the input buffer. The policy rule should ensure the buffer
> would get measured only when the policy rule allows the action. The
> policy rule should also support the necessary constraints (flags etc.)
> for integrity critical buffer data measurements.
> 
> Add a policy rule to define the constraints for restricting integrity
> critical data measurements.
> 
> Signed-off-by: Tushar Sugandhi 
> ---
>  Documentation/ABI/testing/ima_policy |  2 +-
>  security/integrity/ima/ima_policy.c  | 34 
>  2 files changed, 31 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/ABI/testing/ima_policy 
> b/Documentation/ABI/testing/ima_policy
> index e35263f97fc1..6ec7daa87cba 100644
> --- a/Documentation/ABI/testing/ima_policy
> +++ b/Documentation/ABI/testing/ima_policy
> @@ -32,7 +32,7 @@ Description:
>   func:= 
> [BPRM_CHECK][MMAP_CHECK][CREDS_CHECK][FILE_CHECK]MODULE_CHECK]
>   [FIRMWARE_CHECK]
>   [KEXEC_KERNEL_CHECK] [KEXEC_INITRAMFS_CHECK]
> - [KEXEC_CMDLINE] [KEY_CHECK]
> + [KEXEC_CMDLINE] [KEY_CHECK] [CRITICAL_DATA]
>   mask:= [[^]MAY_READ] [[^]MAY_WRITE] [[^]MAY_APPEND]
>  [[^]MAY_EXEC]
>   fsmagic:= hex value
> diff --git a/security/integrity/ima/ima_policy.c 
> b/security/integrity/ima/ima_policy.c
> index a09d1a41a290..07116ff35c25 100644
> --- a/security/integrity/ima/ima_policy.c
> +++ b/security/integrity/ima/ima_policy.c
> @@ -85,6 +85,7 @@ struct ima_rule_entry {
>   } lsm[MAX_LSM_RULES];
>   char *fsname;
>   struct ima_rule_opt_list *keyrings; /* Measure keys added to these 
> keyrings */
> + struct ima_rule_opt_list *data_source; /* Measure data from this source 
> */

Argh, there are still some more instances of data_source sneaking into
this patch too early instead of waiting until the next patch.

>   struct ima_template_desc *template;
>  };
>  
> @@ -479,6 +480,12 @@ static bool ima_match_rule_data(struct ima_rule_entry 
> *rule,
>  
>   opt_list = rule->keyrings;
>   break;
> + case CRITICAL_DATA:
> + if (!rule->data_source)
> + return true;
> +
> + opt_list = rule->data_source;
> + break;

I guess this case should unconditionally return true in this patch and
then the include this additional logic in the next patch.

Sorry, I missed these on my last review.

Tyler

>   default:
>   return false;
>   }
> @@ -515,13 +522,19 @@ static bool ima_match_rules(struct ima_rule_entry 
> *rule, struct inode *inode,
>  {
>   int i;
>  
> - if (func == KEY_CHECK) {
> - return (rule->flags & IMA_FUNC) && (rule->func == func) &&
> - ima_match_rule_data(rule, func_data, cred);
> - }
>   if ((rule->flags & IMA_FUNC) &&
>   (rule->func != func && func != POST_SETATTR))
>   return false;
> +
> + switch (func) {
> + case KEY_CHECK:
> + case CRITICAL_DATA:
> + return ((rule->func == func) &&
> + ima_match_rule_data(rule, func_data, cred));
> + default:
> + break;
> + }
> +
>   if ((rule->flags & IMA_MASK) &&
>   (rule->mask != mask && func != POST_SETATTR))
>   return false;
> @@ -1116,6 +1129,17 @@ static bool ima_validate_rule(struct ima_rule_entry 
> *entry)
>   if (ima_rule_contains_lsm_cond(entry))
>   return false;
>  
> + break;
> + case CRITICAL_DATA:
> + if (entry->action & ~(MEASURE | DONT_MEASURE))
> + return false;
> +
> + if (entry->flags & ~(IMA_FUNC | IMA_UID | IMA_PCR))
> + return false;
> +
> + if (ima_rule_contains_lsm_cond(entry))
> + return false;
> +
>   break;
>   default:
>   return false;
> @@ -1248,6 +1272,8 @@ static int ima_parse_rule(char *rule, struct 
> ima_rule_entry *entry)
>   else if (IS_ENABLED(CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS) 
> &&
>strcmp(args[0].from, "KEY_CHECK") == 0)
>   entry->func = KEY_CHECK;
> + else if (strcmp(args[0].from, "CRITICAL_DATA") == 0)
> + entry->func = CRITICAL_DATA;
>   else
>   result = -EINVAL;
>   if (!result)
> -- 
> 2.17.1
>

Re: [PATCH 1/2] mm/madvise: allow process_madvise operations on entire memory range

2020-12-11 Thread Jann Horn

On Sat, Dec 12, 2020 at 12:01 AM Minchan Kim  wrote:
> On Fri, Dec 11, 2020 at 09:27:46PM +0100, Jann Horn wrote:
> > +CC Christoph Hellwig for opinions on compat
> >
> > On Thu, Nov 26, 2020 at 12:22 AM Minchan Kim  wrote:
> > > On Mon, Nov 23, 2020 at 09:39:42PM -0800, Suren Baghdasaryan wrote:
> > > > process_madvise requires a vector of address ranges to be provided for
> > > > its operations. When an advice should be applied to the entire process,
> > > > the caller process has to obtain the list of VMAs of the target process
> > > > by reading the /proc/pid/maps or some other way. The cost of this
> > > > operation grows linearly with increasing number of VMAs in the target
> > > > process. Even constructing the input vector can be non-trivial when
> > > > target process has several thousands of VMAs and the syscall is being
> > > > issued during high memory pressure period when new allocations for such
> > > > a vector would only worsen the situation.
> > > > In the case when advice is being applied to the entire memory space of
> > > > the target process, this creates an extra overhead.
> > > > Add PMADV_FLAG_RANGE flag for process_madvise enabling the caller to
> > > > advise a memory range of the target process. For now, to keep it simple,
> > > > only the entire process memory range is supported, vec and vlen inputs
> > > > in this mode are ignored and can be NULL and 0.
> > > > Instead of returning the number of bytes that advice was successfully
> > > > applied to, the syscall in this mode returns 0 on success. This is due
> > > > to the fact that the number of bytes would not be useful for the caller
> > > > that does not know the amount of memory the call is supposed to affect.
> > > > Besides, the ssize_t return type can be too small to hold the number of
> > > > bytes affected when the operation is applied to a large memory range.
> > >
> > > Can we just use one element in iovec to indicate entire address rather
> > > than using up the reserved flags?
> > >
> > > struct iovec {
> > > .iov_base = NULL,
> > > .iov_len = (~(size_t)0),
> > > };
> >
> > In addition to Suren's objections, I think it's also worth considering
> > how this looks in terms of compat API. If a compat process does
> > process_madvise() on another compat process, it would be specifying
> > the maximum 32-bit number, rather than the maximum 64-bit number, so
> > you'd need special code to catch that case, which would be ugly.
> >
> > And when a compat process uses this API on a non-compat process, it
> > semantically gets really weird: The actual address range covered would
> > be larger than the address range specified.
> >
> > And if we want different access checks for the two flavors in the
> > future, gating that different behavior on special values in the iovec
> > would feel too magical to me.
> >
> > And the length value SIZE_MAX doesn't really make sense anyway because
> > the length of the whole address space would be SIZE_MAX+1, which you
> > can't express.
> >
> > So I'm in favor of a new flag, and strongly against using SIZE_MAX as
> > a magic number here.
>
> Can't we simply pass NULL as iovec as special id, then?

AFAIK in theory NULL can be a valid userspace pointer (although that
basically never happens and, on MMU systems, requires root to
explicitly do it). On the other hand, there are some parts of the UAPI
that already special-case NULL, so maybe that's considered acceptable?

Also, special-casing NULL slightly increases the chance that userspace
messes up and accidentally triggers completely different behavior
because an allocation failed or something like that.

So while I'm not strongly against using NULL here, I don't exactly
like the idea.

Re: [patch 1/3] tick: Remove pointless cpu valid check in hotplug code

2020-12-11 Thread Thomas Gleixner

On Fri, Dec 11 2020 at 23:21, Frederic Weisbecker wrote:
> On Sun, Dec 06, 2020 at 10:12:54PM +0100, Thomas Gleixner wrote:
>> tick_handover_do_timer() which is invoked when a CPU is unplugged has a
>> @@ -407,17 +407,13 @@ EXPORT_SYMBOL_GPL(tick_broadcast_oneshot
>>  /*
>>   * Transfer the do_timer job away from a dying cpu.
>>   *
>> - * Called with interrupts disabled. Not locking required. If
>> + * Called with interrupts disabled. No locking required. If
>>   * tick_do_timer_cpu is owned by this cpu, nothing can change it.
>>   */
>>  void tick_handover_do_timer(void)
>>  {
>> -if (tick_do_timer_cpu == smp_processor_id()) {
>> -int cpu = cpumask_first(cpu_online_mask);
>> -
>> -tick_do_timer_cpu = (cpu < nr_cpu_ids) ? cpu :
>> -TICK_DO_TIMER_NONE;
>> -}
>> +if (tick_do_timer_cpu == smp_processor_id())
>> +tick_do_timer_cpu = cpumask_first(cpu_online_mask);
>
> I was about to whine that this randomly chosen CPU may be idle and leave
> the timekeeping stale until I realized that stop_machine() is running at that
> time. Might be worth adding a comment about that.
>
> Also why not just setting it to TICK_DO_TIMER_NONE and be done with it? 
> Perhaps
> to avoid that all the CPUs to compete and contend on jiffies update after stop
> machine?

No. Because we'd need to add the NONE magic to NOHZ=n kernels which does
not make sense.

Thanks,

tglx

Re: [PATCH v8 3/8] IMA: define a hook to measure kernel integrity critical data

On 2020-12-11 15:58:02, Tushar Sugandhi wrote:
> IMA provides capabilities to measure file data, and in-memory buffer
> data. However, various data structures, policies, and states
> stored in kernel memory also impact the integrity of the system.
> Several kernel subsystems contain such integrity critical data. These
> kernel subsystems help protect the integrity of a device. Currently,
> IMA does not provide a generic function for kernel subsystems to measure
> their integrity critical data.
>  
> Define a new IMA hook - ima_measure_critical_data to measure kernel
> integrity critical data.
> 
> Signed-off-by: Tushar Sugandhi 

Reviewed-by: Tyler Hicks 

Tyler

> ---
>  include/linux/ima.h   |  6 ++
>  security/integrity/ima/ima.h  |  1 +
>  security/integrity/ima/ima_api.c  |  2 +-
>  security/integrity/ima/ima_main.c | 34 +++
>  4 files changed, 42 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/ima.h b/include/linux/ima.h
> index ac3d82f962f2..675f54db6264 100644
> --- a/include/linux/ima.h
> +++ b/include/linux/ima.h
> @@ -30,6 +30,9 @@ extern int ima_post_read_file(struct file *file, void *buf, 
> loff_t size,
>  extern void ima_post_path_mknod(struct dentry *dentry);
>  extern int ima_file_hash(struct file *file, char *buf, size_t buf_size);
>  extern void ima_kexec_cmdline(int kernel_fd, const void *buf, int size);
> +extern void ima_measure_critical_data(const char *event_name,
> +   const void *buf, int buf_len,
> +   bool measure_buf_hash);
>  
>  #ifdef CONFIG_IMA_APPRAISE_BOOTPARAM
>  extern void ima_appraise_parse_cmdline(void);
> @@ -122,6 +125,9 @@ static inline int ima_file_hash(struct file *file, char 
> *buf, size_t buf_size)
>  }
>  
>  static inline void ima_kexec_cmdline(int kernel_fd, const void *buf, int 
> size) {}
> +static inline void ima_measure_critical_data(const char *event_name,
> +  const void *buf, int buf_len,
> +  bool measure_buf_hash) {}
>  #endif /* CONFIG_IMA */
>  
>  #ifndef CONFIG_IMA_KEXEC
> diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
> index fa3044a7539f..7d9deda6a8b3 100644
> --- a/security/integrity/ima/ima.h
> +++ b/security/integrity/ima/ima.h
> @@ -201,6 +201,7 @@ static inline unsigned int ima_hash_key(u8 *digest)
>   hook(POLICY_CHECK, policy)  \
>   hook(KEXEC_CMDLINE, kexec_cmdline)  \
>   hook(KEY_CHECK, key)\
> + hook(CRITICAL_DATA, critical_data)  \
>   hook(MAX_CHECK, none)
>  
>  #define __ima_hook_enumify(ENUM, str)ENUM,
> diff --git a/security/integrity/ima/ima_api.c 
> b/security/integrity/ima/ima_api.c
> index af218babd198..9917e1730cb6 100644
> --- a/security/integrity/ima/ima_api.c
> +++ b/security/integrity/ima/ima_api.c
> @@ -176,7 +176,7 @@ void ima_add_violation(struct file *file, const unsigned 
> char *filename,
>   *   subj=, obj=, type=, func=, mask=, fsmagic=
>   *   subj,obj, and type: are LSM specific.
>   *   func: FILE_CHECK | BPRM_CHECK | CREDS_CHECK | MMAP_CHECK | MODULE_CHECK
> - *   | KEXEC_CMDLINE | KEY_CHECK
> + *   | KEXEC_CMDLINE | KEY_CHECK | CRITICAL_DATA
>   *   mask: contains the permission mask
>   *   fsmagic: hex value
>   *
> diff --git a/security/integrity/ima/ima_main.c 
> b/security/integrity/ima/ima_main.c
> index 0f8409d77602..dff4bce4fb09 100644
> --- a/security/integrity/ima/ima_main.c
> +++ b/security/integrity/ima/ima_main.c
> @@ -922,6 +922,40 @@ void ima_kexec_cmdline(int kernel_fd, const void *buf, 
> int size)
>   fdput(f);
>  }
>  
> +/**
> + * ima_measure_critical_data - measure kernel integrity critical data
> + * @event_name: event name to be used for the buffer entry
> + * @buf: pointer to buffer containing data to measure
> + * @buf_len: length of buffer(in bytes)
> + * @measure_buf_hash: measure buffer hash
> + *
> + * Measure the kernel subsystem data, critical to the integrity of the 
> kernel,
> + * into the IMA log and extend the @pcr.
> + *
> + * Use @event_name to describe the state/buffer data change.
> + * Examples of critical data (@buf) could be various data structures,
> + * policies, and states stored in kernel memory that can impact the integrity
> + * of the system.
> + *
> + * If @measure_buf_hash is set to true - measure hash of the buffer data,
> + * else measure the buffer data itself.
> + * @measure_buf_hash can be used to save space, if the data being measured
> + * is too large.
> + *
> + * The data (@buf) can only be measured, not appraised.
> + */
> +void ima_measure_critical_data(const char *event_name,
> +const void *buf, int buf_len,
> +bool measure_buf_hash)
> +{
> + if (!event_name || !buf || !buf_len)
> + return;
> +
> +

Re: [PATCH v3] KVM: mmu: Fix SPTE encoding of MMIO generation upper half

2020-12-11 Thread Paolo Bonzini


On 12/12/20 00:54, Sean Christopherson wrote:

On Fri, Dec 11, 2020, Paolo Bonzini wrote:

From: "Maciej S. Szmigiero" 

Commit cae7ed3c2cb0 ("KVM: x86: Refactor the MMIO SPTE generation handling")
cleaned up the computation of MMIO generation SPTE masks, however it
introduced a bug how the upper part was encoded:
SPTE bits 52-61 were supposed to contain bits 10-19 of the current
generation number, however a missing shift encoded bits 1-10 there instead
(mostly duplicating the lower part of the encoded generation number that
then consisted of bits 1-9).

In the meantime, the upper part was shrunk by one bit and moved by
subsequent commits to become an upper half of the encoded generation number
(bits 9-17 of bits 0-17 encoded in a SPTE).

In addition to the above, commit 56871d444bc4 ("KVM: x86: fix overlap between 
SPTE_MMIO_MASK and generation")
has changed the SPTE bit range assigned to encode the generation number and
the total number of bits encoded but did not update them in the comment
attached to their defines, nor in the KVM MMU doc.
Let's do it here, too, since it is too trivial thing to warrant a separate
commit.

Fixes: cae7ed3c2cb0 ("KVM: x86: Refactor the MMIO SPTE generation handling")
Signed-off-by: Maciej S. Szmigiero 
Message-Id: 
<156700708db2a5296c5ed7a8b9ac71f1e9765c85.1607129096.git.maciej.szmigi...@oracle.com>
Cc: sta...@nongnu.org


I assume you want sta...@vger.kernel.org?


I do.


[Reorganize macros so that everything is computed from the bit ranges. - Paolo]
Signed-off-by: Paolo Bonzini 
---
Compared to v2 by Maciej, I chose to keep GEN_MASK's argument 
calculated,


Bo.  :-D


But I explained why. :)

Paolo


Reviewed-by: Sean Christopherson 



but assert on the number of bits in the low and high parts.  This is
because any change on those numbers will have to be reflected in the
comment, and essentially we're asserting that the comment is up-to-date.

Re: [PATCH] lib/find_bit_bench: fix the unmatched iterations cnt

2020-12-11 Thread Yun Levi

> I didn't understand why is so (I mean "same", I think you rather talking about
> same order of amount of itterations).

Yes. That's what I want to talk about. Thanks!

> Can you provide before and after to compare?

I tested when the bitmap's 0 bit is set only. and below are before and
after results.

before:
  Start testing find_bit() with random-filled bitmap
[  +0.000481] find_next_bit:8966 ns,  2 iterations
[  +0.001739] find_next_zero_bit:1726335 ns, 327679 iterations
[  +0.20] find_last_bit:7428 ns,  1 iterations
[  +0.17] find_first_bit:   5523 ns,  2 iterations
[  +0.22] find_next_and_bit:9643 ns,  1 iterations
[  +0.07]
  Start testing find_bit() with sparse bitmap
[  +0.41] find_next_bit:   16343 ns,656 iterations
[  +0.001943] find_next_zero_bit:1928324 ns, 327025 iterations
[  +0.29] find_last_bit:   14398 ns,656 iterations
[  +0.000725] find_first_bit: 711383 ns,656 iterations
[  +0.22] find_next_and_bit:9581 ns,  1 iterations

after:
[Dec12 08:25]
  Start testing find_bit() with random-filled bitmap
[  +0.000687] find_next_bit:   11079 ns,  1 iterations
[  +0.002156] find_next_zero_bit:2055752 ns, 327679 iterations
[  +0.22] find_last_bit:8052 ns,  1 iterations
[  +0.20] find_first_bit:   6270 ns,  1 iterations
[  +0.24] find_next_and_bit:9519 ns,  0 iterations
[  +0.07]
  Start testing find_bit() with sparse bitmap
[  +0.47] find_next_bit:   18389 ns,655 iterations
[  +0.001807] find_next_zero_bit:1793314 ns, 327025 iterations
[  +0.27] find_last_bit:   13600 ns,655 iterations
[  +0.000604] find_first_bit: 591173 ns,655 iterations
[  +0.23] find_next_and_bit:9392 ns,  0 iterations

>I think it's not that important, because the difference is not measurable.
> But if this part raises questions, I have nothing against aligning numbers.
Right it's not that important, But if the amount of iteration value is
not same to the same bitmap,
makes people confused when they run the test cases. so I just fix.

> What for this check against ++cnt? I doubt that the counter can overflow.
This test case suppose the bitmap size is 327680 (4096UL * 8 * 10)
So I think there is no case that the counter can overflow in the testcase.

>> time = ktime_get() - time;
>> pr_err("find_first_bit: %18llu ns, %6ld\n", time, cnt);
> Why this?
Sorry, I don't catch what you are saying.
Could you tell me in detail?


> Can you please confirm that for bitmap 0001,
> test_find_{first,next,next_and}_bit reports cnt == 0, and
> test_find_last_bit() reports 1?
This happens because "test_find_first_bit" calls __clear_bit
in case of bitmap 0001 (only 0 bit set), the test_find_first_bit will
clear the 0 bit
that makes no match with bitmap2 so it reports 0.

In the view we need to call the find_last_bit or find_next_bit to know
bitmap is empty so cnt should be the 1 in that case,
I think it possible by initializing cnt as 1.

> Do you experience the same problem with find_next_and_bit() as well?
Nope, But compared to other test cases, I think it's better to
integrate their format.
Should I sustain the former one?

On Sat, Dec 12, 2020 at 2:20 AM Yury Norov  wrote:
>
> On Fri, Dec 11, 2020 at 12:50 AM Levi Yun  wrote:
> >
> > We should have same iteration count when we walk the same bitmap
> > regardless of using find_next_bit or find_last_b
>
> I think it's not that important, because the difference is not measurable.
> But if this part raises questions, I have nothing against aligning numbers.
>
> > When we run the find_bit_benchmark.ko, we sometime get
> > unmatched iterations count below:
> >
> >  Start testing find_bit() with random-filled bitmap
> > [+...] find_next_bit:  875085 ns, 163755 iterations <
> > [+...] find_next_zero_bit: 865319 ns, 163926 iterations
> > [+...] find_last_bit:  611807 ns, 163756 iterations <
> > [+...] find_first_bit:1601016 ns,  16335 iterations
> > [+...] find_next_and_bit:  400645 ns,  74040 iterations
> > [+...]
> >   Start testing find_bit() with sparse bitmap
> > [+...] find_next_bit:9942 ns,654 iterations
> > [+...] find_next_zero_bit:1678445 ns, 327027 iterations
> > [+...] find_last_bit:7131 ns,654 iterations
> > [+...] find_first_bit: 551383 ns,654 iterations
> > [+...] find_next_and_bit:3027 ns,  1 iterations
> >
> > Normally, this is happen when the last bit of bitmap was set.
>
> Can you please

Re: [PATCH v8 1/8] IMA: generalize keyring specific measurement constructs

On 2020-12-11 15:58:00, Tushar Sugandhi wrote:
> IMA functions such as ima_match_keyring(), process_buffer_measurement(),
> ima_match_policy() etc. handle data specific to keyrings. Currently,
> these constructs are not generic to handle any func specific data.
> This makes it harder to extend them without code duplication.
> 
> Refactor the keyring specific measurement constructs to be generic and
> reusable in other measurement scenarios.
> 
> Signed-off-by: Tushar Sugandhi 
> Reviewed-by: Tyler Hicks 

This looks good to me. Thanks!

Tyler

> ---
>  security/integrity/ima/ima.h|  6 ++--
>  security/integrity/ima/ima_api.c|  6 ++--
>  security/integrity/ima/ima_main.c   |  6 ++--
>  security/integrity/ima/ima_policy.c | 46 ++---
>  4 files changed, 37 insertions(+), 27 deletions(-)
> 
> diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
> index 8e8b1e3cb847..e5622ce8cbb1 100644
> --- a/security/integrity/ima/ima.h
> +++ b/security/integrity/ima/ima.h
> @@ -256,7 +256,7 @@ static inline void ima_process_queued_keys(void) {}
>  int ima_get_action(struct inode *inode, const struct cred *cred, u32 secid,
>  int mask, enum ima_hooks func, int *pcr,
>  struct ima_template_desc **template_desc,
> -const char *keyring);
> +const char *func_data);
>  int ima_must_measure(struct inode *inode, int mask, enum ima_hooks func);
>  int ima_collect_measurement(struct integrity_iint_cache *iint,
>   struct file *file, void *buf, loff_t size,
> @@ -268,7 +268,7 @@ void ima_store_measurement(struct integrity_iint_cache 
> *iint, struct file *file,
>  struct ima_template_desc *template_desc);
>  void process_buffer_measurement(struct inode *inode, const void *buf, int 
> size,
>   const char *eventname, enum ima_hooks func,
> - int pcr, const char *keyring);
> + int pcr, const char *func_data);
>  void ima_audit_measurement(struct integrity_iint_cache *iint,
>  const unsigned char *filename);
>  int ima_alloc_init_template(struct ima_event_data *event_data,
> @@ -284,7 +284,7 @@ const char *ima_d_path(const struct path *path, char 
> **pathbuf, char *filename);
>  int ima_match_policy(struct inode *inode, const struct cred *cred, u32 secid,
>enum ima_hooks func, int mask, int flags, int *pcr,
>struct ima_template_desc **template_desc,
> -  const char *keyring);
> +  const char *func_data);
>  void ima_init_policy(void);
>  void ima_update_policy(void);
>  void ima_update_policy_flag(void);
> diff --git a/security/integrity/ima/ima_api.c 
> b/security/integrity/ima/ima_api.c
> index 4f39fb93f278..af218babd198 100644
> --- a/security/integrity/ima/ima_api.c
> +++ b/security/integrity/ima/ima_api.c
> @@ -170,7 +170,7 @@ void ima_add_violation(struct file *file, const unsigned 
> char *filename,
>   * @func: caller identifier
>   * @pcr: pointer filled in if matched measure policy sets pcr=
>   * @template_desc: pointer filled in if matched measure policy sets template=
> - * @keyring: keyring name used to determine the action
> + * @func_data: private data specific to @func, can be NULL.
>   *
>   * The policy is defined in terms of keypairs:
>   *   subj=, obj=, type=, func=, mask=, fsmagic=
> @@ -186,14 +186,14 @@ void ima_add_violation(struct file *file, const 
> unsigned char *filename,
>  int ima_get_action(struct inode *inode, const struct cred *cred, u32 secid,
>  int mask, enum ima_hooks func, int *pcr,
>  struct ima_template_desc **template_desc,
> -const char *keyring)
> +const char *func_data)
>  {
>   int flags = IMA_MEASURE | IMA_AUDIT | IMA_APPRAISE | IMA_HASH;
>  
>   flags &= ima_policy_flag;
>  
>   return ima_match_policy(inode, cred, secid, func, mask, flags, pcr,
> - template_desc, keyring);
> + template_desc, func_data);
>  }
>  
>  /*
> diff --git a/security/integrity/ima/ima_main.c 
> b/security/integrity/ima/ima_main.c
> index 68956e884403..e76ef4bfd0f4 100644
> --- a/security/integrity/ima/ima_main.c
> +++ b/security/integrity/ima/ima_main.c
> @@ -786,13 +786,13 @@ int ima_post_load_data(char *buf, loff_t size,
>   * @eventname: event name to be used for the buffer entry.
>   * @func: IMA hook
>   * @pcr: pcr to extend the measurement
> - * @keyring: keyring name to determine the action to be performed
> + * @func_data: private data specific to @func, can be NULL.
>   *
>   * Based on policy, the buffer is measured into the ima log.
>   */
>  void process_buffer_measurement(struct inode *inode, const void *buf, int 
> size,
>   const char *eventname, enum ima_hooks func,
> -

Re: [PATCH v8 2/8] IMA: add support to measure buffer data hash