Re: [PATCH] media: videobuf2: Fix integer overrun in allocation

[Ricardo Ribalda]

Hi Laurent

On Wed, Mar 10, 2021 at 8:49 AM Laurent Pinchart
 wrote:
>
> Hi Ricardo,
>
> Thank you for the patch.
Thank you!
>
> On Wed, Mar 10, 2021 at 12:43:17AM +0100, Ricardo Ribalda wrote:
> > The plane_length is an unsigned integer. So, if we have a size of
> > 0x bytes we incorrectly allocate 0 bytes instead of 1 << 32.
> >
> > Cc: sta...@vger.kernel.org
> > Fixes: 7f8414594e47 ("[media] media: videobuf2: fix the length check for 
> > mmap")
> > Signed-off-by: Ricardo Ribalda 
> > ---
> >  drivers/media/common/videobuf2/videobuf2-core.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/common/videobuf2/videobuf2-core.c 
> > b/drivers/media/common/videobuf2/videobuf2-core.c
> > index 02281d13505f..543da515c761 100644
> > --- a/drivers/media/common/videobuf2/videobuf2-core.c
> > +++ b/drivers/media/common/videobuf2/videobuf2-core.c
> > @@ -223,8 +223,10 @@ static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
> >* NOTE: mmapped areas should be page aligned
> >*/
> >   for (plane = 0; plane < vb->num_planes; ++plane) {
> > + unsigned long size = vb->planes[plane].length;
>
> unsigned long is still 32-bit on 32-bit platforms.
>
> > +
> >   /* Memops alloc requires size to be page aligned. */
> > - unsigned long size = PAGE_ALIGN(vb->planes[plane].length);
> > + size = PAGE_ALIGN(size);
> >
> >   /* Did it wrap around? */
> >   if (size < vb->planes[plane].length)
>
> Doesn't this address the issue already ?

Yes and no. If you need to allocate 0x you are still affected
by the underrun. The core will return an error instead of doing the
allocation.

(yes, I know it is a lot of memory for a buffer)

>
>
> --
> Regards,
>
> Laurent Pinchart



-- 
Ricardo Ribalda

[PATCH v4 3/7] MIPS: Loongson64: Add support for the Loongson-2K1000 to get cpu_clock_freq

[Qing Zhang]

Get the fixed-clock from the CPU0 node of the device tree.

Signed-off-by: Jiaxun Yang 
Signed-off-by: Qing Zhang 
Tested-by: Ming Wang 
---

v3-v4: Standard submission of information
   Add return after error

 arch/mips/loongson64/time.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/mips/loongson64/time.c b/arch/mips/loongson64/time.c
index 91e842b58365..2d84f9b20a9b 100644
--- a/arch/mips/loongson64/time.c
+++ b/arch/mips/loongson64/time.c
@@ -11,9 +11,33 @@
 #include 
 
 #include 
+#include 
+#include 
 
 void __init plat_time_init(void)
 {
+   struct clk *clk = NULL;
+   struct device_node *np;
+
+   if (loongson_sysconf.fw_interface == LOONGSON_DTB) {
+   of_clk_init(NULL);
+
+   np = of_get_cpu_node(0, NULL);
+   if (!np) {
+   pr_err("Failed to get CPU node\n");
+   return;
+   }
+
+   clk = of_clk_get(np, 0);
+   if (IS_ERR(clk)) {
+   pr_err("Failed to get CPU clock: %ld\n", PTR_ERR(clk));
+   return;
+   }
+
+   cpu_clock_freq = clk_get_rate(clk);
+   clk_put(clk);
+   }
+
/* setup mips r4k timer */
mips_hpt_frequency = cpu_clock_freq / 2;
 
-- 
2.20.1

[PATCH v4 2/7] MIPS: Loongson64: Distinguish firmware dependencies DTB/LEFI

[Qing Zhang]

Add DTB boot support, only support Loongson-2K1000 processor
for now, determine whether to use the built-in DTB or the DTB
from the firmware by checking the range of CKSEG0 and XKPHYS.
loongson_fw_interface will be used in the future.

Signed-off-by: Jiaxun Yang 
Signed-off-by: Qing Zhang 
Tested-by: Ming Wang 
---

v3-v4: Standard submission of information
   Fix error handling 

 .../include/asm/mach-loongson64/boot_param.h |  6 ++
 arch/mips/include/asm/mach-loongson64/loongson.h |  3 ++-
 arch/mips/loongson64/env.c   | 13 -
 arch/mips/loongson64/init.c  | 16 ++--
 4 files changed, 34 insertions(+), 4 deletions(-)

diff --git a/arch/mips/include/asm/mach-loongson64/boot_param.h 
b/arch/mips/include/asm/mach-loongson64/boot_param.h
index 4592841b6b0c..43737401dc06 100644
--- a/arch/mips/include/asm/mach-loongson64/boot_param.h
+++ b/arch/mips/include/asm/mach-loongson64/boot_param.h
@@ -198,7 +198,13 @@ enum loongson_bridge_type {
VIRTUAL = 3
 };
 
+enum loongson_fw_interface {
+   LOONGSON_LEFI,
+   LOONGSON_DTB,
+};
+
 struct loongson_system_configuration {
+   enum loongson_fw_interface fw_interface;
u32 nr_cpus;
u32 nr_nodes;
int cores_per_node;
diff --git a/arch/mips/include/asm/mach-loongson64/loongson.h 
b/arch/mips/include/asm/mach-loongson64/loongson.h
index ac1c20e172a2..3f885fa26ba6 100644
--- a/arch/mips/include/asm/mach-loongson64/loongson.h
+++ b/arch/mips/include/asm/mach-loongson64/loongson.h
@@ -23,7 +23,8 @@ extern u32 memsize, highmemsize;
 extern const struct plat_smp_ops loongson3_smp_ops;
 
 /* loongson-specific command line, env and memory initialization */
-extern void __init prom_init_env(void);
+extern void __init prom_dtb_init_env(void);
+extern void __init prom_lefi_init_env(void);
 extern void __init szmem(unsigned int node);
 extern void *loongson_fdt_blob;
 
diff --git a/arch/mips/loongson64/env.c b/arch/mips/loongson64/env.c
index 51a5d050a94c..e7d3a06175e3 100644
--- a/arch/mips/loongson64/env.c
+++ b/arch/mips/loongson64/env.c
@@ -43,7 +43,18 @@ const char *get_system_type(void)
return "Generic Loongson64 System";
 }
 
-void __init prom_init_env(void)
+
+void __init prom_dtb_init_env(void)
+{
+   if ((fw_arg2 < CKSEG0 || fw_arg2 > CKSEG1)
+   && (fw_arg2 < XKPHYS || fw_arg2 > XKSEG))
+
+   loongson_fdt_blob = __dtb_loongson64_2core_2k1000_begin;
+   else
+   loongson_fdt_blob = (void *)fw_arg2;
+}
+
+void __init prom_lefi_init_env(void)
 {
struct boot_params *boot_p;
struct loongson_params *loongson_p;
diff --git a/arch/mips/loongson64/init.c b/arch/mips/loongson64/init.c
index cfa788bca871..ed280b73bf89 100644
--- a/arch/mips/loongson64/init.c
+++ b/arch/mips/loongson64/init.c
@@ -52,6 +52,10 @@ void __init szmem(unsigned int node)
static unsigned long num_physpages;
u64 node_id, node_psize, start_pfn, end_pfn, mem_start, mem_size;
 
+   /* Otherwise come from DTB */
+   if (loongson_sysconf.fw_interface != LOONGSON_LEFI)
+   return;
+
/* Parse memory information and activate */
for (i = 0; i < loongson_memmap->nr_map; i++) {
node_id = loongson_memmap->map[i].node_id;
@@ -94,12 +98,20 @@ static void __init prom_init_memory(void)
 void __init prom_init(void)
 {
fw_init_cmdline();
-   prom_init_env();
+
+   if (fw_arg2 == 0 || (fdt_magic(fw_arg2) == FDT_MAGIC)) {
+   loongson_sysconf.fw_interface = LOONGSON_DTB;
+   prom_dtb_init_env();
+   } else {
+   loongson_sysconf.fw_interface = LOONGSON_LEFI;
+   prom_lefi_init_env();
+   }
 
/* init base address of io space */
set_io_port_base(PCI_IOBASE);
 
-   loongson_sysconf.early_config();
+   if (loongson_sysconf.early_config)
+   loongson_sysconf.early_config();
 
 #ifdef CONFIG_NUMA
prom_init_numa_memory();
-- 
2.20.1

[PATCH v4 4/7] MIPS: Loongson64: Add Loongson-2K1000 early_printk_port

[Qing Zhang]

Distinguish between Loongson-3A series CPU and Loongson-2K1000 CPU UART0.

Signed-off-by: Jiaxun Yang 
Signed-off-by: Qing Zhang 
Tested-by: Ming Wang 
---

v3-v4: Standard submission of information

 arch/mips/loongson64/init.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/mips/loongson64/init.c b/arch/mips/loongson64/init.c
index ed280b73bf89..d5a1eddb8202 100644
--- a/arch/mips/loongson64/init.c
+++ b/arch/mips/loongson64/init.c
@@ -120,7 +120,10 @@ void __init prom_init(void)
 #endif
 
/* Hardcode to CPU UART 0 */
-   setup_8250_early_printk_port(TO_UNCAC(LOONGSON_REG_BASE + 0x1e0), 0, 
1024);
+   if ((read_c0_prid() & PRID_IMP_MASK) == PRID_IMP_LOONGSON_64R)
+   setup_8250_early_printk_port(TO_UNCAC(LOONGSON_REG_BASE), 0, 
1024);
+   else
+   setup_8250_early_printk_port(TO_UNCAC(LOONGSON_REG_BASE + 
0x1e0), 0, 1024);
 
register_smp_ops(_smp_ops);
board_nmi_handler_setup = mips_nmi_setup;
-- 
2.20.1

[PATCH v4 6/7] dt-bindings: interrupt-controller: Add Loongson-2K1000 LIOINTC

[Qing Zhang]

Add liointc-2.0 properties support, so update the maxItems and description.

Signed-off-by: Jiaxun Yang 
Signed-off-by: Qing Zhang 
Tested-by: Ming Wang 
---

v3-v4: Standard submission of information

 .../bindings/interrupt-controller/loongson,liointc.yaml| 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml 
b/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml
index f38e0113f360..5280cf60a9a7 100644
--- 
a/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml
@@ -10,9 +10,9 @@ maintainers:
   - Jiaxun Yang 
 
 description: |
-  This interrupt controller is found in the Loongson-3 family of chips as the 
primary
-  package interrupt controller which can route local I/O interrupt to 
interrupt lines
-  of cores.
+  This interrupt controller is found in the Loongson-3 family of chips and
+  Loongson-2K1000 chip, as the primary package interrupt controller which
+  can route local I/O interrupt to interrupt lines of cores.
 
 allOf:
   - $ref: /schemas/interrupt-controller.yaml#
@@ -22,6 +22,7 @@ properties:
 oneOf:
   - const: loongson,liointc-1.0
   - const: loongson,liointc-1.0a
+  - const: loongson,liointc-2.0
 
   reg:
 maxItems: 1
-- 
2.20.1

[PATCH v4 0/7] Add basic support for Loongson-2K1000

[Qing Zhang]

These patches support single-core DTS boot to the serial port login
interface, which can be operated using conventional commands.

I have successfully tested it on the Loongson 2K1000 machine.
pmon: http://cgit.loongnix.org/cgit/pmon-loongson3/

Note:
After the basic support is merged, 
I will submit SMP and other peripheral support in the future. 

Qing Zhang (7):
  MIPS: Loongson64: DeviceTree for Loongson-2K1000
  MIPS: Loongson64: Distinguish firmware dependencies DTB/LEFI
  MIPS: Loongson64: Add support for the Loongson-2K1000 to get
cpu_clock_freq
  MIPS: Loongson64: Add Loongson-2K1000 early_printk_port
  irqchip/loongson-liointc: irqchip add 2.0 version
  dt-bindings: interrupt-controller: Add Loongson-2K1000 LIOINTC
  MIPS: Loongson64: Add a Loongson-2K1000 default config file

 .../loongson,liointc.yaml |   7 +-
 arch/mips/boot/dts/loongson/Makefile  |   1 +
 .../boot/dts/loongson/loongson64-2k1000.dtsi  | 243 
 .../dts/loongson/loongson64_2core_2k1000.dts  |  10 +
 arch/mips/configs/loongson2k_defconfig| 353 ++
 .../include/asm/mach-loongson64/boot_param.h  |   6 +
 .../asm/mach-loongson64/builtin_dtbs.h|   1 +
 .../include/asm/mach-loongson64/loongson.h|   3 +-
 arch/mips/loongson64/env.c|  13 +-
 arch/mips/loongson64/init.c   |  21 +-
 arch/mips/loongson64/time.c   |  24 ++
 drivers/irqchip/irq-loongson-liointc.c|  58 ++-
 12 files changed, 723 insertions(+), 17 deletions(-)
 create mode 100644 arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
 create mode 100644 arch/mips/boot/dts/loongson/loongson64_2core_2k1000.dts
 create mode 100644 arch/mips/configs/loongson2k_defconfig

-- 
2.20.1

[PATCH v4 7/7] MIPS: Loongson64: Add a Loongson-2K1000 default config file

[Qing Zhang]

Add default config for Loongson-2K1000.

Signed-off-by: Jiaxun Yang 
Signed-off-by: Qing Zhang 
Tested-by: Ming Wang 
---

v3-v4: Standard submission of information

 arch/mips/configs/loongson2k_defconfig | 353 +
 1 file changed, 353 insertions(+)
 create mode 100644 arch/mips/configs/loongson2k_defconfig

diff --git a/arch/mips/configs/loongson2k_defconfig 
b/arch/mips/configs/loongson2k_defconfig
new file mode 100644
index ..e948ca487e2d
--- /dev/null
+++ b/arch/mips/configs/loongson2k_defconfig
@@ -0,0 +1,353 @@
+# CONFIG_LOCALVERSION_AUTO is not set
+CONFIG_KERNEL_LZMA=y
+CONFIG_SYSVIPC=y
+CONFIG_POSIX_MQUEUE=y
+CONFIG_AUDIT=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_PREEMPT=y
+CONFIG_BSD_PROCESS_ACCT=y
+CONFIG_BSD_PROCESS_ACCT_V3=y
+CONFIG_TASKSTATS=y
+CONFIG_TASK_DELAY_ACCT=y
+CONFIG_TASK_XACCT=y
+CONFIG_TASK_IO_ACCOUNTING=y
+CONFIG_MEMCG=y
+CONFIG_BLK_CGROUP=y
+CONFIG_SCHED_AUTOGROUP=y
+CONFIG_SYSFS_DEPRECATED=y
+CONFIG_RELAY=y
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_EMBEDDED=y
+CONFIG_MACH_LOONGSON64=y
+# CONFIG_CPU_LOONGSON3_CPUCFG_EMULATION is not set
+CONFIG_HZ_256=y
+CONFIG_MIPS32_O32=y
+CONFIG_MIPS32_N32=y
+CONFIG_MODULES=y
+CONFIG_MODULE_FORCE_LOAD=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_MODULE_FORCE_UNLOAD=y
+CONFIG_MODVERSIONS=y
+CONFIG_PARTITION_ADVANCED=y
+CONFIG_MQ_IOSCHED_DEADLINE=m
+CONFIG_IOSCHED_BFQ=y
+CONFIG_BFQ_GROUP_IOSCHED=y
+CONFIG_BINFMT_MISC=m
+CONFIG_KSM=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_XFRM_USER=y
+CONFIG_NET_KEY=y
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_IP_ADVANCED_ROUTER=y
+CONFIG_IP_MULTIPLE_TABLES=y
+CONFIG_IP_ROUTE_MULTIPATH=y
+CONFIG_IP_ROUTE_VERBOSE=y
+CONFIG_NETFILTER=y
+CONFIG_NETFILTER_NETLINK_LOG=m
+CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
+CONFIG_NETFILTER_XT_TARGET_MARK=m
+CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
+CONFIG_NETFILTER_XT_MATCH_COMMENT=m
+CONFIG_NETFILTER_XT_MATCH_DCCP=m
+CONFIG_NETFILTER_XT_MATCH_ESP=m
+CONFIG_NETFILTER_XT_MATCH_LENGTH=m
+CONFIG_NETFILTER_XT_MATCH_LIMIT=m
+CONFIG_NETFILTER_XT_MATCH_MAC=m
+CONFIG_NETFILTER_XT_MATCH_MARK=m
+CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m
+CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m
+CONFIG_NETFILTER_XT_MATCH_QUOTA=m
+CONFIG_NETFILTER_XT_MATCH_REALM=m
+CONFIG_NETFILTER_XT_MATCH_STATISTIC=m
+CONFIG_NETFILTER_XT_MATCH_STRING=m
+CONFIG_NETFILTER_XT_MATCH_TCPMSS=m
+CONFIG_IP_VS=m
+CONFIG_IP_NF_IPTABLES=m
+CONFIG_IP_NF_MATCH_AH=m
+CONFIG_IP_NF_MATCH_ECN=m
+CONFIG_IP_NF_MATCH_TTL=m
+CONFIG_IP_NF_FILTER=m
+CONFIG_IP_NF_TARGET_REJECT=m
+CONFIG_IP_NF_MANGLE=m
+CONFIG_IP_NF_TARGET_ECN=m
+CONFIG_IP_NF_TARGET_TTL=m
+CONFIG_IP_NF_RAW=m
+CONFIG_IP_NF_ARPTABLES=m
+CONFIG_IP_NF_ARPFILTER=m
+CONFIG_IP_NF_ARP_MANGLE=m
+CONFIG_IP_SCTP=m
+CONFIG_L2TP=m
+CONFIG_BRIDGE=m
+CONFIG_CFG80211=m
+CONFIG_CFG80211_WEXT=y
+CONFIG_MAC80211=m
+CONFIG_RFKILL=m
+CONFIG_RFKILL_INPUT=y
+CONFIG_PCIEPORTBUS=y
+CONFIG_HOTPLUG_PCI_PCIE=y
+CONFIG_PCIEASPM_PERFORMANCE=y
+CONFIG_HOTPLUG_PCI=y
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+CONFIG_MTD=m
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_CRYPTOLOOP=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_SIZE=8192
+CONFIG_RAID_ATTRS=m
+CONFIG_BLK_DEV_SD=y
+CONFIG_BLK_DEV_SR=y
+CONFIG_CHR_DEV_SG=y
+CONFIG_CHR_DEV_SCH=m
+CONFIG_SCSI_CONSTANTS=y
+CONFIG_SCSI_LOGGING=y
+CONFIG_SCSI_SPI_ATTRS=m
+CONFIG_SCSI_FC_ATTRS=m
+CONFIG_ISCSI_TCP=m
+CONFIG_MEGARAID_NEWGEN=y
+CONFIG_MEGARAID_MM=y
+CONFIG_MEGARAID_MAILBOX=y
+CONFIG_MEGARAID_LEGACY=y
+CONFIG_MEGARAID_SAS=y
+CONFIG_ATA=y
+CONFIG_SATA_AHCI=y
+CONFIG_PATA_ATIIXP=y
+CONFIG_MD=y
+CONFIG_BLK_DEV_MD=m
+CONFIG_MD_LINEAR=m
+CONFIG_MD_RAID0=m
+CONFIG_MD_RAID1=m
+CONFIG_MD_RAID10=m
+CONFIG_MD_RAID456=m
+CONFIG_MD_MULTIPATH=m
+CONFIG_BLK_DEV_DM=m
+CONFIG_DM_CRYPT=m
+CONFIG_DM_SNAPSHOT=m
+CONFIG_DM_MIRROR=m
+CONFIG_DM_ZERO=m
+CONFIG_TARGET_CORE=m
+CONFIG_TCM_IBLOCK=m
+CONFIG_TCM_FILEIO=m
+CONFIG_TCM_PSCSI=m
+CONFIG_LOOPBACK_TARGET=m
+CONFIG_ISCSI_TARGET=m
+CONFIG_NETDEVICES=y
+CONFIG_TUN=m
+# CONFIG_NET_VENDOR_3COM is not set
+# CONFIG_NET_VENDOR_ADAPTEC is not set
+# CONFIG_NET_VENDOR_ALTEON is not set
+# CONFIG_NET_VENDOR_AMD is not set
+# CONFIG_NET_VENDOR_ARC is not set
+# CONFIG_NET_VENDOR_ATHEROS is not set
+# CONFIG_NET_VENDOR_BROADCOM is not set
+# CONFIG_NET_VENDOR_BROCADE is not set
+# CONFIG_NET_VENDOR_CHELSIO is not set
+# CONFIG_NET_VENDOR_CIRRUS is not set
+# CONFIG_NET_VENDOR_CISCO is not set
+# CONFIG_NET_VENDOR_DEC is not set
+# CONFIG_NET_VENDOR_DLINK is not set
+# CONFIG_NET_VENDOR_EMULEX is not set
+# CONFIG_NET_VENDOR_I825XX is not set
+CONFIG_E1000=y
+CONFIG_E1000E=y
+CONFIG_IGB=y
+CONFIG_IXGB=y
+CONFIG_IXGBE=y
+# CONFIG_NET_VENDOR_MARVELL is not set
+# CONFIG_NET_VENDOR_MELLANOX is not set
+# CONFIG_NET_VENDOR_MICREL is not set
+# CONFIG_NET_VENDOR_MICROCHIP is not set
+# CONFIG_NET_VENDOR_MICROSEMI is not set
+# CONFIG_NET_VENDOR_MYRI is not set
+# CONFIG_NET_VENDOR_NATSEMI is not set
+# CONFIG_NET_VENDOR_NETERION is not set
+# CONFIG_NET_VENDOR_NETRONOME is not set
+# CONFIG_NET_VENDOR_NI is not set
+# 

[PATCH v4 1/7] MIPS: Loongson64: DeviceTree for Loongson-2K1000

[Qing Zhang]

Add DeviceTree files for Loongson-2K1000 processor,currently only
supports single-core boot.

Signed-off-by: Jiaxun Yang 
Signed-off-by: Qing Zhang 
Tested-by: Ming Wang 
---

v3-v4: Standard submission of information 

 arch/mips/boot/dts/loongson/Makefile  |   1 +
 .../boot/dts/loongson/loongson64-2k1000.dtsi  | 243 ++
 .../dts/loongson/loongson64_2core_2k1000.dts  |  10 +
 .../asm/mach-loongson64/builtin_dtbs.h|   1 +
 4 files changed, 255 insertions(+)
 create mode 100644 arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
 create mode 100644 arch/mips/boot/dts/loongson/loongson64_2core_2k1000.dts

diff --git a/arch/mips/boot/dts/loongson/Makefile 
b/arch/mips/boot/dts/loongson/Makefile
index 8fd0efb37423..72267bfda9b4 100644
--- a/arch/mips/boot/dts/loongson/Makefile
+++ b/arch/mips/boot/dts/loongson/Makefile
@@ -1,4 +1,5 @@
 # SPDX_License_Identifier: GPL_2.0
+dtb-$(CONFIG_MACH_LOONGSON64)  += loongson64_2core_2k1000.dtb
 dtb-$(CONFIG_MACH_LOONGSON64)  += loongson64c_4core_ls7a.dtb
 dtb-$(CONFIG_MACH_LOONGSON64)  += loongson64c_4core_rs780e.dtb
 dtb-$(CONFIG_MACH_LOONGSON64)  += loongson64c_8core_rs780e.dtb
diff --git a/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi 
b/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
new file mode 100644
index ..fd0e99bfe57b
--- /dev/null
+++ b/arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi
@@ -0,0 +1,243 @@
+// SPDX-License-Identifier: GPL-3.0
+
+/dts-v1/;
+
+#include 
+
+/ {
+   compatible = "loongson,loongson2k1000";
+
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "loongson,gs264";
+   reg = <0x0>;
+   #clock-cells = <1>;
+   clocks = <_clk>;
+   };
+   };
+
+   memory {
+   compatible = "memory";
+   device_type = "memory";
+   reg = <0x 0x0020 0x 0x0ee0>, /* 238 MB 
at 2 MB */
+   <0x 0x2000 0x 0x1f00>, /* 496 
MB at 512 MB */
+   <0x0001 0x1000 0x0001 0xb000>; /* 6912 
MB at 4352MB */
+   };
+
+   cpu_clk: cpu_clk {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <8>;
+   };
+
+   cpuintc: interrupt-controller {
+   #address-cells = <0>;
+   #interrupt-cells = <1>;
+   interrupt-controller;
+   compatible = "mti,cpu-interrupt-controller";
+   };
+
+   package0: bus@1000 {
+   compatible = "simple-bus";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges = <0 0x1000 0 0x1000 0 0x1000 /* ioports */
+   0 0x4000 0 0x4000 0 0x4000
+   0xfe 0x 0xfe 0x 0 0x4000>;
+
+   liointc0: interrupt-controller@1fe11400 {
+   compatible = "loongson,liointc-2.0";
+   reg = <0 0x1fe11400 0 0x40>,
+   <0 0x1fe11040 0 0x8>,
+   <0 0x1fe11140 0 0x8>;
+   reg-names = "main", "isr0", "isr1";
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+
+   interrupt-parent = <>;
+   interrupts = <2>;
+   interrupt-names = "int0";
+
+   loongson,parent_int_map = <0x>, /* int0 */
+   <0x>, /* int1 */
+   <0x>, /* int2 */
+   <0x>; /* int3 */
+   };
+
+   liointc1: interrupt-controller@1fe11440 {
+   compatible = "loongson,liointc-2.0";
+   reg = <0 0x1fe11440 0 0x40>,
+   <0 0x1fe11048 0 0x8>,
+   <0 0x1fe11148 0 0x8>;
+   reg-names = "main", "isr0", "isr1";
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+
+   interrupt-parent = <>;
+   interrupts = <3>;
+   interrupt-names = "int1";
+
+   loongson,parent_int_map = <0x>, /* int0 */
+   <0x>, /* int1 */
+   <0x>, /* int2 */
+   <0x>; /* int3 */
+   };
+
+   uart0: serial@1fe0 {
+   compatible = 

[PATCH v4 5/7] irqchip/loongson-liointc: irqchip add 2.0 version

[Qing Zhang]

Add IO interrupt controller support for Loongson-2K1000, different
from the Loongson-3A series is that 2K1000 has 64 interrupt sources,
0-31 correspond to the device tree liointc0 device node, and the other
correspond to liointc1 node.

Signed-off-by: Jiaxun Yang 
Signed-off-by: Qing Zhang 
Tested-by: Ming Wang 
---

v3-v4: Standard submission of information

 drivers/irqchip/irq-loongson-liointc.c | 58 ++
 1 file changed, 49 insertions(+), 9 deletions(-)

diff --git a/drivers/irqchip/irq-loongson-liointc.c 
b/drivers/irqchip/irq-loongson-liointc.c
index 09b91b81851c..33219244c551 100644
--- a/drivers/irqchip/irq-loongson-liointc.c
+++ b/drivers/irqchip/irq-loongson-liointc.c
@@ -20,6 +20,7 @@
 
 #define LIOINTC_CHIP_IRQ   32
 #define LIOINTC_NUM_PARENT 4
+#define LIOINTC_NUM_CORES  4
 
 #define LIOINTC_INTC_CHIP_START0x20
 
@@ -42,6 +43,7 @@ struct liointc_handler_data {
 struct liointc_priv {
struct irq_chip_generic *gc;
struct liointc_handler_data handler[LIOINTC_NUM_PARENT];
+   void __iomem*core_isr[LIOINTC_NUM_CORES];
u8  map_cache[LIOINTC_CHIP_IRQ];
boolhas_lpc_irq_errata;
 };
@@ -51,11 +53,12 @@ static void liointc_chained_handle_irq(struct irq_desc 
*desc)
struct liointc_handler_data *handler = irq_desc_get_handler_data(desc);
struct irq_chip *chip = irq_desc_get_chip(desc);
struct irq_chip_generic *gc = handler->priv->gc;
+   int core = get_ebase_cpunum() % LIOINTC_NUM_CORES;
u32 pending;
 
chained_irq_enter(chip, desc);
 
-   pending = readl(gc->reg_base + LIOINTC_REG_INTC_STATUS);
+   pending = readl(handler->priv->core_isr[core]);
 
if (!pending) {
/* Always blame LPC IRQ if we have that bug */
@@ -141,6 +144,18 @@ static void liointc_resume(struct irq_chip_generic *gc)
 }
 
 static const char * const parent_names[] = {"int0", "int1", "int2", "int3"};
+static const char * const core_reg_names[] = {"isr0", "isr1", "isr2", "isr3"};
+
+static void __iomem *liointc_get_reg_byname(struct device_node *node,
+   const char *name)
+{
+   int index = of_property_match_string(node, "reg-names", name);
+
+   if (index < 0)
+   return NULL;
+
+   return of_iomap(node, index);
+}
 
 static int __init liointc_of_init(struct device_node *node,
  struct device_node *parent)
@@ -159,10 +174,28 @@ static int __init liointc_of_init(struct device_node 
*node,
if (!priv)
return -ENOMEM;
 
-   base = of_iomap(node, 0);
-   if (!base) {
-   err = -ENODEV;
-   goto out_free_priv;
+   if (of_device_is_compatible(node, "loongson,liointc-2.0")) {
+   base = liointc_get_reg_byname(node, "main");
+   if (!base) {
+   err = -ENODEV;
+   goto out_free_priv;
+   }
+
+   for (i = 0; i < LIOINTC_NUM_CORES; i++)
+   priv->core_isr[i] = liointc_get_reg_byname(node, 
core_reg_names[i]);
+   if (!priv->core_isr[0]) {
+   err = -ENODEV;
+   goto out_iounmap_base;
+   }
+   } else {
+   base = of_iomap(node, 0);
+   if (!base) {
+   err = -ENODEV;
+   goto out_free_priv;
+   }
+
+   for (i = 0; i < LIOINTC_NUM_CORES; i++)
+   priv->core_isr[i] = base + LIOINTC_REG_INTC_STATUS;
}
 
for (i = 0; i < LIOINTC_NUM_PARENT; i++) {
@@ -172,7 +205,7 @@ static int __init liointc_of_init(struct device_node *node,
}
if (!have_parent) {
err = -ENODEV;
-   goto out_iounmap;
+   goto out_iounmap_isr;
}
 
sz = of_property_read_variable_u32_array(node,
@@ -183,7 +216,7 @@ static int __init liointc_of_init(struct device_node *node,
if (sz < 4) {
pr_err("loongson-liointc: No parent_int_map\n");
err = -ENODEV;
-   goto out_iounmap;
+   goto out_iounmap_isr;
}
 
for (i = 0; i < LIOINTC_NUM_PARENT; i++)
@@ -195,7 +228,7 @@ static int __init liointc_of_init(struct device_node *node,
if (!domain) {
pr_err("loongson-liointc: cannot add IRQ domain\n");
err = -EINVAL;
-   goto out_iounmap;
+   goto out_iounmap_isr;
}
 
err = irq_alloc_domain_generic_chips(domain, 32, 1,
@@ -260,7 +293,13 @@ static int __init liointc_of_init(struct device_node *node,
 
 out_free_domain:
irq_domain_remove(domain);
-out_iounmap:
+out_iounmap_isr:
+   for (i = 0; i < LIOINTC_NUM_CORES; i++) {
+   if (!priv->core_isr[i])
+  

Re: [PATCH v1 07/14] vfio: Add a device notifier interface

[Christoph Hellwig]

On Mon, Mar 08, 2021 at 02:48:30PM -0700, Alex Williamson wrote:
> Using a vfio device, a notifier block can be registered to receive
> select device events.  Notifiers can only be registered for contained
> devices, ie. they are available through a user context.  Registration
> of a notifier increments the reference to that container context
> therefore notifiers must minimally respond to the release event by
> asynchronously removing notifiers.

Notifiers generally are a horrible multiplexed API.  Can't we just
add a proper method table for the intended communication channel?

Re: [PATCH v6 04/12] x86/alternative: support not-feature

[Jürgen Groß]

On 10.03.21 07:07, Borislav Petkov wrote:

On Tue, Mar 09, 2021 at 02:48:05PM +0100, Juergen Gross wrote:

Add support for alternative patching for the case a feature is not
present on the current cpu.

For users of ALTERNATIVE() and friends an inverted feature is specified
by applying the ALT_NOT() macro to it, e.g.:

ALTERNATIVE(old, new, ALT_NOT(feature))

Signed-off-by: Juergen Gross 
---
V5:
- split off from next patch
- reworked to use flag byte (Boris Petkov)
V6:
- rework again to not use flag byte (Boris Petkov)
---
  arch/x86/include/asm/alternative-asm.h |  3 +++
  arch/x86/include/asm/alternative.h |  3 +++
  arch/x86/kernel/alternative.c  | 19 ++-
  3 files changed, 20 insertions(+), 5 deletions(-)


LGTM, minor touchups I'd do ontop:

---

diff --git a/arch/x86/include/asm/alternative.h 
b/arch/x86/include/asm/alternative.h
index 89889618ae01..fd205cdcfbad 100644
--- a/arch/x86/include/asm/alternative.h
+++ b/arch/x86/include/asm/alternative.h
@@ -55,18 +55,18 @@
".long 999b - .\n\t"  \
".popsection\n\t"
  
+#define ALTINSTR_FLAG_INV	(1 << 15)

+#define ALT_NOT(feat)  ((feat) | ALTINSTR_FLAG_INV)
+
  struct alt_instr {
s32 instr_offset;   /* original instruction */
s32 repl_offset;/* offset to replacement instruction */
u16 cpuid;  /* cpuid bit set for replacement */
-#define ALTINSTR_FLAG_INV (1 << 15)
u8  instrlen;   /* length of original instruction */
u8  replacementlen; /* length of new instruction */
u8  padlen; /* length of build-time padding */
  } __packed;
  
-#define ALT_NOT(feat)	((feat) | ALTINSTR_FLAG_INV)

-


Did you look at patch 13? :-)


  /*
   * Debug flag that can be tested to see whether alternative
   * instructions were patched in already:
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index d8e669a1546f..133b549dc091 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -397,9 +397,10 @@ void __init_or_module noinline apply_alternatives(struct 
alt_instr *start,
BUG_ON(feature >= (NCAPINTS + NBUGINTS) * 32);
  
  		/*

-* Drop out if either:
-* - feature not available, but required, or
-* - feature available, but NOT required
+* Patch if either:
+* - feature is present
+* - feature not present but ALTINSTR_FLAG_INV is set to mean,
+*   patch if feature is *NOT* present.


Okay.


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

[PATCH v2] media: videobuf2: Fix integer overrun in vb2_mmap

[Ricardo Ribalda]

The plane_length is an unsigned integer. So, if we have a size of
0x bytes we incorrectly allocate 0 bytes instead of 1 << 32.

Suggested-by: Sergey Senozhatsky 
Cc: sta...@vger.kernel.org
Fixes: 7f8414594e47 ("[media] media: videobuf2: fix the length check for mmap")
Reviewed-by: Sergey Senozhatsky 
Signed-off-by: Ricardo Ribalda 
---
 drivers/media/common/videobuf2/videobuf2-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/common/videobuf2/videobuf2-core.c 
b/drivers/media/common/videobuf2/videobuf2-core.c
index 543da515c761..89c8bacb94a7 100644
--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -2256,7 +2256,7 @@ int vb2_mmap(struct vb2_queue *q, struct vm_area_struct 
*vma)
 * The buffer length was page_aligned at __vb2_buf_mem_alloc(),
 * so, we need to do the same here.
 */
-   length = PAGE_ALIGN(vb->planes[plane].length);
+   length = PAGE_ALIGN((unsigned long)vb->planes[plane].length);
if (length < (vma->vm_end - vma->vm_start)) {
dprintk(q, 1,
"MMAP invalid, as it would overflow buffer length\n");
-- 
2.30.1.766.gb4fecdf3b7-goog

Re: [PATCH v6 02/12] x86/paravirt: switch time pvops functions to use static_call()

[Jürgen Groß]

On 09.03.21 19:57, Borislav Petkov wrote:

On Tue, Mar 09, 2021 at 02:48:03PM +0100, Juergen Gross wrote:

@@ -167,6 +168,17 @@ static u64 native_steal_clock(int cpu)
return 0;
  }
  
+DEFINE_STATIC_CALL(pv_steal_clock, native_steal_clock);

+DEFINE_STATIC_CALL(pv_sched_clock, native_sched_clock);
+
+bool paravirt_using_native_sched_clock = true;
+
+void paravirt_set_sched_clock(u64 (*func)(void))
+{
+   static_call_update(pv_sched_clock, func);
+   paravirt_using_native_sched_clock = (func == native_sched_clock);
+}


What's the point of this function if there's a global
paravirt_using_native_sched_clock variable now?


It is combining the two needed actions: update the static call and
set the paravirt_using_native_sched_clock boolean.


Looking how the bit of information whether native_sched_clock is used,
is needed in tsc.c, it probably would be cleaner if you add a

set_sched_clock_native(void);

or so, to tsc.c instead and call that here and make that long var name a
a shorter and static one in tsc.c instead.


I need to transfer a boolean value, so it would need to be

set_sched_clock_native(bool state);

In the end the difference is only marginal IMO.

Just had another idea: I could add a function to static_call.h for
querying the current function. This would avoid the double book keeping
and could probably be used later when switching other pv_ops calls to
static_call, too (e.g. pv_is_native_spin_unlock()).

What do you think?


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH] media: videobuf2: Fix integer overrun in allocation

[Laurent Pinchart]

Hi Ricardo,

Thank you for the patch.

On Wed, Mar 10, 2021 at 12:43:17AM +0100, Ricardo Ribalda wrote:
> The plane_length is an unsigned integer. So, if we have a size of
> 0x bytes we incorrectly allocate 0 bytes instead of 1 << 32.
> 
> Cc: sta...@vger.kernel.org
> Fixes: 7f8414594e47 ("[media] media: videobuf2: fix the length check for 
> mmap")
> Signed-off-by: Ricardo Ribalda 
> ---
>  drivers/media/common/videobuf2/videobuf2-core.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/common/videobuf2/videobuf2-core.c 
> b/drivers/media/common/videobuf2/videobuf2-core.c
> index 02281d13505f..543da515c761 100644
> --- a/drivers/media/common/videobuf2/videobuf2-core.c
> +++ b/drivers/media/common/videobuf2/videobuf2-core.c
> @@ -223,8 +223,10 @@ static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
>* NOTE: mmapped areas should be page aligned
>*/
>   for (plane = 0; plane < vb->num_planes; ++plane) {
> + unsigned long size = vb->planes[plane].length;

unsigned long is still 32-bit on 32-bit platforms.

> +
>   /* Memops alloc requires size to be page aligned. */
> - unsigned long size = PAGE_ALIGN(vb->planes[plane].length);
> + size = PAGE_ALIGN(size);
>  
>   /* Did it wrap around? */
>   if (size < vb->planes[plane].length)

Doesn't this address the issue already ?


-- 
Regards,

Laurent Pinchart

Re: [PATCH] media: videobuf2: Fix integer overrun in vb2_mmap

[Ricardo Ribalda]

On Wed, Mar 10, 2021 at 8:47 AM Jiri Slaby  wrote:
>
> On 10. 03. 21, 8:40, Ricardo Ribalda wrote:
> > The plane_length is an unsigned integer. So, if we have a size of
> > 0x bytes we incorrectly allocate 0 bytes instead of 1 << 32.
> >
> > Suggested-by: Sergey Senozhatsky 
> > Cc: sta...@vger.kernel.org
> > Fixes: 7f8414594e47 ("[media] media: videobuf2: fix the length check for 
> > mmap")
> > Signed-off-by: Ricardo Ribalda 
> > ---
> >   drivers/media/common/videobuf2/videobuf2-core.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/common/videobuf2/videobuf2-core.c 
> > b/drivers/media/common/videobuf2/videobuf2-core.c
> > index 543da515c761..876db5886867 100644
> > --- a/drivers/media/common/videobuf2/videobuf2-core.c
> > +++ b/drivers/media/common/videobuf2/videobuf2-core.c
> > @@ -2256,7 +2256,7 @@ int vb2_mmap(struct vb2_queue *q, struct 
> > vm_area_struct *vma)
> >* The buffer length was page_aligned at __vb2_buf_mem_alloc(),
> >* so, we need to do the same here.
> >*/
> > - length = PAGE_ALIGN(vb->planes[plane].length);
> > + length = PAGE_ALIGN((unsigned int)vb->planes[plane].length);
>
> Hi,
>
> I fail to see how case from uint to uint helps -- IOW, did you mean ulong?

Ups... my bad :(

Let me send a v2

>
> regards,
> --
> js
> suse labs



-- 
Ricardo Ribalda

[PATCH] virt: acrn: Use EPOLLIN instead of POLLIN

[Yejune Deng]

This fixes the following sparse warning:
"sparse warnings: (new ones prefixed by >>)"
>> drivers/virt/acrn/irqfd.c:163:13: sparse: sparse: restricted __poll_t
 degrades to integer

Fixes: 803c1aadecdb("virt: acrn: Use vfs_poll() instead of f_op->poll()")
Reported-by: kernel test robot 
Signed-off-by: Yejune Deng 
---
 drivers/virt/acrn/irqfd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/virt/acrn/irqfd.c b/drivers/virt/acrn/irqfd.c
index 98d6e9b18f9e..df5184979b28 100644
--- a/drivers/virt/acrn/irqfd.c
+++ b/drivers/virt/acrn/irqfd.c
@@ -160,7 +160,7 @@ static int acrn_irqfd_assign(struct acrn_vm *vm, struct 
acrn_irqfd *args)
/* Check the pending event in this stage */
events = vfs_poll(f.file, >pt);
 
-   if (events & POLLIN)
+   if (events & EPOLLIN)
acrn_irqfd_inject(irqfd);
 
fdput(f);
-- 
2.29.0

Re: [PATCH v4 2/4] hugetlb/userfaultfd: Forbid huge pmd sharing when uffd enabled

[Naresh Kamboju]

Hi Peter,

On Fri, 19 Feb 2021 at 04:43, Peter Xu  wrote:
>
> Huge pmd sharing could bring problem to userfaultfd.  The thing is that
> userfaultfd is running its logic based on the special bits on page table
> entries, however the huge pmd sharing could potentially share page table
> entries for different address ranges.  That could cause issues on either:
>
>   - When sharing huge pmd page tables for an uffd write protected range, the
> newly mapped huge pmd range will also be write protected unexpectedly, or,
>
>   - When we try to write protect a range of huge pmd shared range, we'll first
> do huge_pmd_unshare() in hugetlb_change_protection(), however that also
> means the UFFDIO_WRITEPROTECT could be silently skipped for the shared
> region, which could lead to data loss.
>
> Since at it, a few other things are done altogether:
>
>   - Move want_pmd_share() from mm/hugetlb.c into linux/hugetlb.h, because
> that's definitely something that arch code would like to use too
>
>   - ARM64 currently directly check against CONFIG_ARCH_WANT_HUGE_PMD_SHARE 
> when
> trying to share huge pmd.  Switch to the want_pmd_share() helper.
>
> Since at it, move vma_shareable() from huge_pmd_share() into want_pmd_share().
>
> Reviewed-by: Mike Kravetz 
> Reviewed-by: Axel Rasmussen 
> Signed-off-by: Peter Xu 
> ---
>  arch/arm64/mm/hugetlbpage.c   |  3 +--
>  include/linux/hugetlb.h   |  2 ++
>  include/linux/userfaultfd_k.h |  9 +
>  mm/hugetlb.c  | 20 ++--
>  4 files changed, 26 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> index 6e3bcffe2837..58987a98e179 100644
> --- a/arch/arm64/mm/hugetlbpage.c
> +++ b/arch/arm64/mm/hugetlbpage.c
> @@ -284,8 +284,7 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, struct 
> vm_area_struct *vma,
>  */
> ptep = pte_alloc_map(mm, pmdp, addr);
> } else if (sz == PMD_SIZE) {
> -   if (IS_ENABLED(CONFIG_ARCH_WANT_HUGE_PMD_SHARE) &&
> -   pud_none(READ_ONCE(*pudp)))
> +   if (want_pmd_share(vma, addr) && pud_none(READ_ONCE(*pudp)))

While building Linux next 20210310 tag for arm64 architecture with

  - CONFIG_ARM64_64K_PAGES=y

enabled the build failed due to below errors / warnings

make --silent --keep-going --jobs=8
O=/home/tuxbuild/.cache/tuxmake/builds/1/tmp ARCH=arm64
CROSS_COMPILE=aarch64-linux-gnu- 'CC=sccache aarch64-linux-gnu-gcc'
'HOSTCC=sccache gcc'
aarch64-linux-gnu-ld: Unexpected GOT/PLT entries detected!
aarch64-linux-gnu-ld: Unexpected run-time procedure linkages detected!
aarch64-linux-gnu-ld: arch/arm64/mm/hugetlbpage.o: in function `huge_pte_alloc':
hugetlbpage.c:(.text+0x7d8): undefined reference to `want_pmd_share'

Reported-by: Naresh Kamboju 

Steps to reproduce:

# TuxMake is a command line tool and Python library that provides
# portable and repeatable Linux kernel builds across a variety of
# architectures, toolchains, kernel configurations, and make targets.
#
# TuxMake supports the concept of runtimes.
# See https://docs.tuxmake.org/runtimes/, for that to work it requires
# that you install podman or docker on your system.
#
# To install tuxmake on your system globally:
# sudo pip3 install -U tuxmake
#
# See https://docs.tuxmake.org/ for complete documentation.


tuxmake --runtime podman --target-arch arm64 --toolchain gcc-9
--kconfig defconfig --kconfig-add
https://builds.tuxbuild.com/1pYCSoc1oGtPWlPgLAJxbHx07kL/config

Build link,
https://builds.tuxbuild.com/1pYCSoc1oGtPWlPgLAJxbHx07kL/


-- 
Linaro LKFT
https://lkft.linaro.org

Re: [PATCH v1 02/14] vfio: Update vfio_add_group_dev() API

[Christoph Hellwig]

On Mon, Mar 08, 2021 at 02:47:40PM -0700, Alex Williamson wrote:
> Rather than an errno, return a pointer to the opaque vfio_device
> to allow the bus driver to call into vfio-core without additional
> lookups and references.  Note that bus drivers are still required
> to use vfio_del_group_dev() to teardown the vfio_device.
> 
> Signed-off-by: Alex Williamson 

This looks like it is superseded by the

  vfio: Split creation of a vfio_device into init and register ops

patch from Jason, which provides a much nicer API.

Re: [PATCH] media: videobuf2: Fix integer overrun in vb2_mmap

[Jiri Slaby]

On 10. 03. 21, 8:40, Ricardo Ribalda wrote:

The plane_length is an unsigned integer. So, if we have a size of
0x bytes we incorrectly allocate 0 bytes instead of 1 << 32.

Suggested-by: Sergey Senozhatsky 
Cc: sta...@vger.kernel.org
Fixes: 7f8414594e47 ("[media] media: videobuf2: fix the length check for mmap")
Signed-off-by: Ricardo Ribalda 
---
  drivers/media/common/videobuf2/videobuf2-core.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/common/videobuf2/videobuf2-core.c 
b/drivers/media/common/videobuf2/videobuf2-core.c
index 543da515c761..876db5886867 100644
--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -2256,7 +2256,7 @@ int vb2_mmap(struct vb2_queue *q, struct vm_area_struct 
*vma)
 * The buffer length was page_aligned at __vb2_buf_mem_alloc(),
 * so, we need to do the same here.
 */
-   length = PAGE_ALIGN(vb->planes[plane].length);
+   length = PAGE_ALIGN((unsigned int)vb->planes[plane].length);


Hi,

I fail to see how case from uint to uint helps -- IOW, did you mean ulong?

regards,
--
js
suse labs

Re: [PATCH] media: videobuf2: Fix integer overrun in allocation

[Sergey Senozhatsky]

On (21/03/10 00:43), Ricardo Ribalda wrote:
> 
> The plane_length is an unsigned integer. So, if we have a size of
> 0x bytes we incorrectly allocate 0 bytes instead of 1 << 32.
> 
> Cc: sta...@vger.kernel.org
> Fixes: 7f8414594e47 ("[media] media: videobuf2: fix the length check for 
> mmap")
> Signed-off-by: Ricardo Ribalda 

Reviewed-by: Sergey Senozhatsky 

Re: [PATCH] media: videobuf2: Fix integer overrun in vb2_mmap

[Sergey Senozhatsky]

On (21/03/10 08:40), Ricardo Ribalda wrote:
> 
> The plane_length is an unsigned integer. So, if we have a size of
> 0x bytes we incorrectly allocate 0 bytes instead of 1 << 32.
> 
> Suggested-by: Sergey Senozhatsky 
> Cc: sta...@vger.kernel.org
> Fixes: 7f8414594e47 ("[media] media: videobuf2: fix the length check for 
> mmap")
> Signed-off-by: Ricardo Ribalda 


FWIF,
Reviewed-by: Sergey Senozhatsky 

Re: [PATCH 0/2] AM64: Add USB support

[Aswath Govindraju]

Hi Kishon,

On 10/03/21 12:33 pm, Kishon Vijay Abraham I wrote:
> +Vinod
> 
> Hi Aswath,
> 
> On 10/03/21 12:27 pm, Aswath Govindraju wrote:
>> Hi Nishanth,
>>
>> On 01/03/21 8:52 pm, Nishanth Menon wrote:
>>> On 11:21-20210301, Aswath Govindraju wrote:
 The following series of patches, add USB support for AM64.

 This series of patches depends on,
 https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=439039

 Aswath Govindraju (2):
   arm64: dts: ti: k3-am64-main: Add DT node for USB subsystem
   arm64: dts: ti: k3-am642-evm: Add USB support

  arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 30 
  arch/arm64/boot/dts/ti/k3-am642-evm.dts  | 18 ++
  2 files changed, 48 insertions(+)
>>>
>>> Please update the series to include SK as well.
>>>
>>
>> I was planning on posting patches that add support for USB in SK later
>> because of phy dependencies.
> 
> The dependency is only on [1] right? I've got all the required ACKs so
> it should be okay to include it in this series. (That patch will be
> required only when PCIe DT is merged for me.)
> 
> Nishant, would you be okay to merge [1] along with other patches from
> Aswath? There is no dependency as such on my other PHY patches, so don't
> think there is a need for a stable tag here.
> 
> 
> [1] ->
> https://lore.kernel.org/linux-devicetree/20210222112314.10772-4-kis...@ti.com/
>>

There is also a dependency on,

https://lore.kernel.org/linux-devicetree/20210222112314.10772-2-kis...@ti.com/

Thanks,
Aswath

[PATCH v1 2/2] Revert "mailbox: mediatek: remove implementation related to atomic_exec"

[Yongqiang Niu]

This reverts commit c9ea564f3d9dd20d88bd34f40a6ff6d31a0d7e8c.

Signed-off-by: Yongqiang Niu pa_base,
prev_task->pkt->cmd_buf_size, DMA_TO_DEVICE);
prev_task_base[CMDQ_NUM_CMD(prev_task->pkt) - 1] =
-   (u64)CMDQ_JUMP_BY_PA << 32 | task->pa_base;
+   (u64)CMDQ_JUMP_BY_PA << 32 |
+   (task->pa_base >> cmdq->shift_pa);
dma_sync_single_for_device(dev, prev_task->pa_base,
   prev_task->pkt->cmd_buf_size, DMA_TO_DEVICE);
 
cmdq_thread_invalidate_fetched_data(thread);
 }
 
+static bool cmdq_command_is_wfe(u64 cmd)
+{
+   u64 wfe_option = CMDQ_WFE_UPDATE | CMDQ_WFE_WAIT | CMDQ_WFE_WAIT_VALUE;
+   u64 wfe_op = (u64)(CMDQ_CODE_WFE << CMDQ_OP_CODE_SHIFT) << 32;
+   u64 wfe_mask = (u64)CMDQ_OP_CODE_MASK << 32 | 0x;
+
+   return ((cmd & wfe_mask) == (wfe_op | wfe_option));
+}
+
+/* we assume tasks in the same display GCE thread are waiting the same event. 
*/
+static void cmdq_task_remove_wfe(struct cmdq_task *task)
+{
+   struct device *dev = task->cmdq->mbox.dev;
+   u64 *base = task->pkt->va_base;
+   int i;
+
+   dma_sync_single_for_cpu(dev, task->pa_base, task->pkt->cmd_buf_size,
+   DMA_TO_DEVICE);
+   for (i = 0; i < CMDQ_NUM_CMD(task->pkt); i++)
+   if (cmdq_command_is_wfe(base[i]))
+   base[i] = (u64)CMDQ_JUMP_BY_OFFSET << 32 |
+ (CMDQ_JUMP_PASS >> task->cmdq->shift_pa);
+   dma_sync_single_for_device(dev, task->pa_base, task->pkt->cmd_buf_size,
+  DMA_TO_DEVICE);
+}
+
 static bool cmdq_thread_is_in_wfe(struct cmdq_thread *thread)
 {
return readl(thread->base + CMDQ_THR_WAIT_TOKEN) & CMDQ_THR_IS_WAITING;
 }
 
+static void cmdq_thread_wait_end(struct cmdq_thread *thread,
+unsigned long end_pa)
+{
+   struct device *dev = thread->chan->mbox->dev;
+   unsigned long curr_pa;
+
+   if (readl_poll_timeout_atomic(thread->base + CMDQ_THR_CURR_ADDR,
+   curr_pa, curr_pa == end_pa, 1, 20))
+   dev_err(dev, "GCE thread cannot run to end.\n");
+}
+
 static void cmdq_task_exec_done(struct cmdq_task *task, enum cmdq_cb_status 
sta)
 {
struct cmdq_task_cb *cb = >pkt->async_cb;
@@ -371,15 +410,37 @@ static int cmdq_mbox_send_data(struct mbox_chan *chan, 
void *data)
cmdq->shift_pa;
end_pa = readl(thread->base + CMDQ_THR_END_ADDR) <<
cmdq->shift_pa;
-   /* check boundary */
-   if (curr_pa == end_pa - CMDQ_INST_SIZE ||
-   curr_pa == end_pa) {
-   /* set to this task directly */
-   writel(task->pa_base >> cmdq->shift_pa,
-  thread->base + CMDQ_THR_CURR_ADDR);
+
+   /*
+* Atomic execution should remove the following wfe, i.e. only
+* wait event at first task, and prevent to pause when running.
+*/
+   if (thread->atomic_exec) {
+   /* GCE is executing if command is not WFE */
+   if (!cmdq_thread_is_in_wfe(thread)) {
+   cmdq_thread_resume(thread);
+   cmdq_thread_wait_end(thread,
+end_pa >> cmdq->shift_pa);
+   WARN_ON(cmdq_thread_suspend(cmdq, thread) < 0);
+   /* set to this task directly */
+   writel(task->pa_base >> cmdq->shift_pa,
+  thread->base + CMDQ_THR_CURR_ADDR);
+   } else {
+   cmdq_task_insert_into_thread(task);
+   cmdq_task_remove_wfe(task);
+   smp_mb(); /* modify jump before enable thread */
+   }
} else {
-   cmdq_task_insert_into_thread(task);
-   smp_mb(); /* modify jump before enable thread */
+   /* check boundary */
+   if (curr_pa == end_pa - CMDQ_INST_SIZE ||
+   curr_pa == end_pa) {
+   /* set to this task directly */
+   writel(task->pa_base >> cmdq->shift_pa,
+  thread->base + CMDQ_THR_CURR_ADDR);
+   } else {
+   cmdq_task_insert_into_thread(task);
+   smp_mb(); /* modify jump before enable thread */
+   }
}
writel((task->pa_base + pkt->cmd_buf_size) >> cmdq->shift_pa,
   thread->base + CMDQ_THR_END_ADDR);
@@ -500,6 +561,7 @@ static 

[PATCH v1 0/2] Revert "mailbox: mediatek: remove implementation related to atomic_exec"

[Yongqiang Niu]

This series base linux 5.12-rc1
these two patches will cause home ui flick when cursor moved,
there is no fix solution yet, revert these patches first.

Yongqiang Niu (2):
  Revert "drm/mediatek: Make sure previous message done or be aborted
before send"
  Revert "mailbox: mediatek: remove implementation related to
atomic_exec"

 drivers/gpu/drm/mediatek/mtk_drm_crtc.c |  1 -
 drivers/mailbox/mtk-cmdq-mailbox.c  | 80 +
 2 files changed, 71 insertions(+), 10 deletions(-)

-- 
1.8.1.1.dirty

Re: [PATCH v2] mm: page_alloc: dump migrate-failed pages

[Minchan Kim]

On Tue, Mar 09, 2021 at 08:15:41AM -0800, Minchan Kim wrote:

< snip >

> > [...]
> > > +void dump_migrate_failure_pages(struct list_head *page_list)
> > > +{
> > > + DEFINE_DYNAMIC_DEBUG_METADATA(descriptor,
> > > + "migrate failure");
> > > + if (DYNAMIC_DEBUG_BRANCH(descriptor) &&
> > > + alloc_contig_ratelimit()) {
> > > + struct page *page;
> > > +
> > > + WARN(1, "failed callstack");
> > > + list_for_each_entry(page, page_list, lru)
> > > + dump_page(page, "migration failure");
> > > + }
> > 
> > Apart from the above, do we have to warn for something that is a
> > debugging aid? A similar concern wrt dump_page which uses pr_warn and
> 
> Make sense.
> 
> > page owner is using even pr_alert.
> > Would it make sense to add a loglevel parameter both into __dump_page
> > and dump_page_owner?
> 
> Let me try it.

I looked though them and made first draft to clean them up.

It's bigger than my initial expectaion because there are many callsites
to use dump_page and stack_trace_print inconsistent loglevel. 
Since it's not a specific problem for this work, I'd like to deal with
it as separate patchset since I don't want to be stuck on here for my
initial goal.

FYI,

Subject: [RFC 0/5] make dump_page aware of loglevel

- Forked from [1]

dump_page uses __dump_page and dump_page_owner internally to
print various information. However, their printk loglevel are
inconsistent in that

__dump_page: KERN_WARNING
__dump_page_owner: KERN_ALERT
stack_trace_print: KERN_DEFAULT

To make them consistent from dump_page, this patch introduces
pr_loglevel in printk and make the utility functions aware of
loglevel. Finally, last patch changes dump_page to support
loglevel to make the printing level consistent.

[1] https://lore.kernel.org/linux-mm/yedaw6gnp9xxo...@dhcp22.suse.cz/

Minchan Kim (5):
  mm: introduce pr_loglevel for __dump_[page]_owner
  stacktrace: stack_trace_print aware of loglevel
  mm: page_owner: dump_page_owner aware of loglevel
  mm: debug: __dump_page aware of loglevel
  mm: debug: dump_page aware of loglevel
  drivers/md/dm-bufio.c   |  2 +-
 drivers/virtio/virtio_mem.c |  2 +-
 fs/btrfs/ref-verify.c   |  2 +-
 fs/fuse/dev.c   |  2 +-
 include/linux/mmdebug.h | 10 ++
 include/linux/page_owner.h  |  8 
 include/linux/printk.h  | 12 +++
 include/linux/stacktrace.h  |  4 ++--
 kernel/backtracetest.c  |  2 +-
 kernel/dma/debug.c  |  3 ++-
 kernel/kcsan/report.c   |  7 ---
 kernel/locking/lockdep.c|  3 ++-
 kernel/stacktrace.c |  5 +++--
 mm/debug.c  | 40 ++---
 mm/filemap.c|  2 +-
 mm/gup_test.c   |  4 ++--
 mm/huge_memory.c|  4 ++--
 mm/kasan/report.c   |  4 ++--
 mm/kfence/report.c  |  3 ++-
 mm/kmemleak.c   |  2 +-
 mm/memory.c |  2 +-
 mm/memory_hotplug.c |  4 ++--
 mm/page_alloc.c |  4 ++--
 mm/page_isolation.c |  2 +-
 mm/page_owner.c | 24 +++---
 25 files changed, 88 insertions(+), 69 deletions(-)

[PATCH v1 1/2] Revert "drm/mediatek: Make sure previous message done or be aborted before send"

[Yongqiang Niu]

This reverts commit 839cbf0531428f3f9535077a461b8631359c1165.

Signed-off-by: Yongqiang Niu 
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 8b0de90..c76f446 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -463,7 +463,6 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc 
*mtk_crtc)
}
 #if IS_REACHABLE(CONFIG_MTK_CMDQ)
if (mtk_crtc->cmdq_client) {
-   mbox_flush(mtk_crtc->cmdq_client->chan, 2000);
cmdq_handle = cmdq_pkt_create(mtk_crtc->cmdq_client, PAGE_SIZE);
cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event, false);
-- 
1.8.1.1.dirty

[PATCH] media: videobuf2: Fix integer overrun in vb2_mmap

[Ricardo Ribalda]

The plane_length is an unsigned integer. So, if we have a size of
0x bytes we incorrectly allocate 0 bytes instead of 1 << 32.

Suggested-by: Sergey Senozhatsky 
Cc: sta...@vger.kernel.org
Fixes: 7f8414594e47 ("[media] media: videobuf2: fix the length check for mmap")
Signed-off-by: Ricardo Ribalda 
---
 drivers/media/common/videobuf2/videobuf2-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/common/videobuf2/videobuf2-core.c 
b/drivers/media/common/videobuf2/videobuf2-core.c
index 543da515c761..876db5886867 100644
--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -2256,7 +2256,7 @@ int vb2_mmap(struct vb2_queue *q, struct vm_area_struct 
*vma)
 * The buffer length was page_aligned at __vb2_buf_mem_alloc(),
 * so, we need to do the same here.
 */
-   length = PAGE_ALIGN(vb->planes[plane].length);
+   length = PAGE_ALIGN((unsigned int)vb->planes[plane].length);
if (length < (vma->vm_end - vma->vm_start)) {
dprintk(q, 1,
"MMAP invalid, as it would overflow buffer length\n");
-- 
2.30.1.766.gb4fecdf3b7-goog

Re: [PATCH] media: videobuf2: Fix integer overrun in allocation

[Ricardo Ribalda]

Hi Sergey

On Wed, Mar 10, 2021 at 2:42 AM Sergey Senozhatsky
 wrote:
>
> On (21/03/10 00:43), Ricardo Ribalda wrote:
> > The plane_length is an unsigned integer. So, if we have a size of
> > 0x bytes we incorrectly allocate 0 bytes instead of 1 << 32.
>
> Hi Ricardo,
>
> > @@ -223,8 +223,10 @@ static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
> >* NOTE: mmapped areas should be page aligned
> >*/
> >   for (plane = 0; plane < vb->num_planes; ++plane) {
> > + unsigned long size = vb->planes[plane].length;
> > +
> >   /* Memops alloc requires size to be page aligned. */
> > - unsigned long size = PAGE_ALIGN(vb->planes[plane].length);
> > + size = PAGE_ALIGN(size);
> >
> >   /* Did it wrap around? */
> >   if (size < vb->planes[plane].length)
>
> Shouldn't the same be done in vb2_mmap()?
Indeed, I was having tunnel vision focussing on my issue.

I have sent a new patch.

Thanks!
>
> -ss



--
Ricardo Ribalda

[PATCH] arm64: dts: qcom: sc7280: Add WPSS remoteproc node

[Rakesh Pillai]

Add the WPSS remoteproc node in dts for
PIL loading.

Signed-off-by: Rakesh Pillai 
---
- This change is dependent on the below patch series
1) https://lore.kernel.org/patchwork/project/lkml/list/?series=487403
2) https://lore.kernel.org/patchwork/project/lkml/list/?series=488365
---
 arch/arm64/boot/dts/qcom/sc7280-idp.dts |  4 +++
 arch/arm64/boot/dts/qcom/sc7280.dtsi| 47 +
 2 files changed, 51 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sc7280-idp.dts 
b/arch/arm64/boot/dts/qcom/sc7280-idp.dts
index 950ecb2..603f56b 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-idp.dts
+++ b/arch/arm64/boot/dts/qcom/sc7280-idp.dts
@@ -26,6 +26,10 @@
status = "okay";
 };
 
+_wpss {
+   status = "okay";
+};
+
  {
status = "okay";
 };
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi 
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 8af6d77..26dd466 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -53,6 +53,16 @@
no-map;
reg = <0x0 0x80b0 0x0 0x10>;
};
+
+   wlan_fw_mem: memory@80c0 {
+   no-map;
+   reg = <0x0 0x80c0 0x0 0xc0>;
+   };
+
+   wpss_mem: memory@9ae0 {
+   no-map;
+   reg = <0x0 0x9ae0 0x0 0x190>;
+   };
};
 
cpus {
@@ -305,6 +315,43 @@
};
};
 
+   remoteproc_wpss: remoteproc@8a0 {
+   compatible = "qcom,sc7280-wpss-pil";
+   reg = <0 0x08a0 0 0x1>;
+
+   interrupts-extended = < GIC_SPI 587 
IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 0 0>,
+ <_smp2p_in 1 0>,
+ <_smp2p_in 2 0>,
+ <_smp2p_in 3 0>,
+ <_smp2p_in 7 0>;
+   interrupt-names = "wdog", "fatal", "ready", "handover",
+ "stop-ack", "shutdown-ack";
+
+   memory-region = <_mem>;
+
+   qcom,smem-states = <_smp2p_out 0>;
+   qcom,smem-state-names = "stop";
+
+   resets = <_reset AOSS_CC_WCSS_RESTART>;
+   reset-names = "restart";
+
+   qcom,halt-regs = <_mutex_regs 0x37000>;
+
+   status = "disabled";
+
+   glink-edge {
+   interrupts-extended = < IPCC_CLIENT_WPSS
+
IPCC_MPROC_SIGNAL_GLINK_QMP
+
IRQ_TYPE_EDGE_RISING>;
+   mboxes = < IPCC_CLIENT_WPSS
+   IPCC_MPROC_SIGNAL_GLINK_QMP>;
+
+   label = "wpss";
+   qcom,remote-pid = <13>;
+   };
+   };
+
pdc: interrupt-controller@b22 {
compatible = "qcom,sc7280-pdc", "qcom,pdc";
reg = <0 0x0b22 0 0x3>;
-- 
2.7.4

Re: [PATCH 0/2] software node: Two fixes

[Heikki Krogerus]

On Tue, Mar 09, 2021 at 02:51:22PM +0100, Rafael J. Wysocki wrote:
> On Tue, Mar 9, 2021 at 11:51 AM Andy Shevchenko
>  wrote:
> >
> > On Mon, Mar 01, 2021 at 05:30:10PM +0300, Heikki Krogerus wrote:
> > > Hi,
> > >
> > > The second one only affects 5.12-rc1.
> >
> > Rafael, Greg, can this be applied for v5.12-rcX?
> 
> Do you have a pointer to this?

Pointer?

thanks,

-- 
heikki

Re: [PATCH] xtensa: fix warning comparing pointer to 0

[Max Filippov]

On Tue, Mar 9, 2021 at 11:10 PM Jiapeng Chong
 wrote:
>
> Fix the following coccicheck warning:
>
> ./arch/xtensa/kernel/pci.c:79:17-18: WARNING comparing pointer to 0.
>
> Reported-by: Abaci Robot 
> Signed-off-by: Jiapeng Chong 
> ---
>  arch/xtensa/kernel/pci.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Thanks, applied to my xtensa tree.

-- 
Thanks.
-- Max

Re: kernel panic: Attempted to kill init!

[Palash Oswal]

On Tue, Mar 9, 2021 at 8:36 PM Dmitry Vyukov  wrote:
> FWIW the code looks reasonable:
>
> All code
> 
>0: 00 00add%al,(%rax)
>2: 00 00add%al,(%rax)
>4: 41 57push   %r15
>6: 41 56push   %r14
>8: 41 55push   %r13
>a: 41 54push   %r12
>c: 55push   %rbp
>d: 53push   %rbx
>e: 89 fdmov%edi,%ebp
>   10: 48 81 ec 48 01 00 00 sub$0x148,%rsp
>   17: 64 48 8b 04 25 28 00 mov%fs:0x28,%rax
>   1e: 00 00
>   20: 48 89 84 24 38 01 00 mov%rax,0x138(%rsp)
>   27: 00
>   28: 31 c0xor%eax,%eax
>   2a:* e8 f5 bf f7 ffcallq  0xfff7c024 <-- trapping 
> instruction
>   2f: 83 f8 01  cmp$0x1,%eax
>   32: 0f 84 b7 00 00 00je 0xef
>   38: 48rex.W
>   39: 8d.byte 0x8d
>   3a: 9cpushfq
>   3b: 40rex
>
> This is a PC-relative call to a reasonable address, right?
> I wonder if it always traps on this instruction or not. Maybe the
> executable is corrupted and has a page missing in the image or
> something similar. But also if we suspect a badly corrupted image, is
> it worth pursuing it?...

I copied over a new systemd binary from a fresh disk image generated
using  tools/create-image.sh in syzkaller (debootstrap) and the bug
was still reproducible.
root@sandbox:~# md5sum /lib/systemd/systemd
12b20bfd8321ef7884b4dbf974a91213  /lib/systemd/systemd
root@sandbox:~# md5sum /lib/systemd/systemd_orig
12b20bfd8321ef7884b4dbf974a91213  /lib/systemd/systemd_orig

root@sandbox:~# gcc -pthread hax.c -o repro
root@sandbox:~# ./repro
[  115.515840] got to 221
[  115.515853] got to 183
[  115.516400] got to 201
[  115.516935] got to 208
[  115.517475] got to 210
[  115.521008] got to 270
[  115.544984] systemd[1]: segfault at 7ffe972adfb8 ip
5560fb079466 sp 7ffe972adfc0 error 6 in
systemd[5560fafcd000+ed000]
[  115.546554] Code: 00 00 00 00 41 57 41 56 41 55 41 54 55 53 89 fd
48 81 ec 48 01 00 00 64 48 8b 04 25 28 00 00 00 48 89 84 24 38 01 00
00 31 c0  f5 bf f7 ff 83 f8 01 0f 84 b7 00 00 00 48 8d 9c 240
[  115.548575] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x000b
[  115.549352] CPU: 0 PID: 1 Comm: systemd Not tainted 5.11.2+ #22
[  115.549994] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.14.0-1 04/01/2014
[  115.550834] Call Trace:
[  115.551090]  dump_stack+0xb2/0xe4
[  115.551438]  panic+0x196/0x502
[  115.551798]  do_exit.cold+0x70/0x108
[  115.552170]  do_group_exit+0x78/0x120
[  115.552552]  get_signal+0x22e/0xd60
[  115.552916]  arch_do_signal_or_restart+0xef/0x890
[  115.553407]  exit_to_user_mode_prepare+0x102/0x190
[  115.553920]  irqentry_exit_to_user_mode+0x9/0x20
[  115.554412]  irqentry_exit+0x19/0x30
[  115.554781]  exc_page_fault+0xc3/0x240
[  115.555168]  ? asm_exc_page_fault+0x8/0x30
[  115.555626]  asm_exc_page_fault+0x1e/0x30
[  115.556092] RIP: 0033:0x5560fb079466
[  115.556476] Code: 00 00 00 00 41 57 41 56 41 55 41 54 55 53 89 fd
48 81 ec 48 01 00 00 64 48 8b 04 25 28 00 00 00 48 89 84 24 38 01 00
00 31 c0  f5 bf f7 ff 83 f8 01 0f 84 b7 00 00 00 48 8d 9c 240
[  115.558399] RSP: 002b:7ffe972adfc0 EFLAGS: 00010246
[  115.558947] RAX:  RBX: 5560fcaa7f40 RCX: 7ff6fb1c22e3
[  115.559720] RDX: 7ffe972ae140 RSI: 7ffe972ae270 RDI: 0007
[  115.560475] RBP: 0007 R08: 431bde82d7b634db R09: 000b
[  115.561219] R10:  R11: 0246 R12: 7ffe97aad190
[  115.561963] R13: 0001 R14:  R15: 0002
[  115.562768] Kernel Offset: disabled
[  115.563148] ---[ end Kernel panic - not syncing: Attempted to kill
init! exitcode=0x000b ]---

For sanity, I created a new disk image altogether, made a replica of
the image and ran syzkaller on the first copy of the image to find a
new reproducer for this bug.
[NEW IMAGE] [NEW IMAGE REPLICA]
Used by syzkallerUsed for testing the reproducer manually
After discovering the new reproducer for this fresh image, I triggered
the new reproducer on the *untainted* replica of the image and the bug
was reproducible.
This would invalidate the assumption that the image/binaries on the
image are corrupted.

[PATCH] drivers/firmware: Fix double free in dmi_sysfs_register_handle

[Lv Yunlong]

A double free bug was found in drivers/firmware/dmi-sysfs.c.
In the implementation of dmi_sysfs_register_handle, it calls
dmi_system_event_log() to initialize entry->child. If
kobject_init_and_add() failed, entry->child is freed. But
unfortunately, out_err branch in dmi_sysfs_register_handle
will freed entry->child twice!

Fixes: 925a1da7477fc ("firmware: Break out system_event_log in dmi-sysfs")
Signed-off-by: Lv Yunlong 
---
 drivers/firmware/dmi-sysfs.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/firmware/dmi-sysfs.c b/drivers/firmware/dmi-sysfs.c
index 8b8127fa8955..ad97bbd37206 100644
--- a/drivers/firmware/dmi-sysfs.c
+++ b/drivers/firmware/dmi-sysfs.c
@@ -631,7 +631,6 @@ static void __init dmi_sysfs_register_handle(const struct 
dmi_header *dh,
 
return;
 out_err:
-   kobject_put(entry->child);
kobject_put(>kobj);
return;
 }
-- 
2.25.1

[PATCH v1, RFC] docs: reporting-issues.rst: tone down 'test vanilla mainline' a little

[Thorsten Leemhuis]

Tell users that reporting bugs with vendor kernels which are only
slightly patched can be okay in some situations, but point out there's a
risk in doing so.

Adjust some related sections to make them compatible and a bit clearer.
At the same time make them less daunting: we want users to report bugs,
even if they can't test vanilla mainline kernel.

Signed-off-by: Thorsten Leemhuis 
CC: Randy Dunlap 

---
With this I try to get rid of the last remaining parts that have a
'this needs discussion' box that's in the text. I hope I've found a
middle ground that everybody can live with.

v1, RFC
* this version
---
 .../admin-guide/reporting-issues.rst  | 273 ++
 1 file changed, 149 insertions(+), 124 deletions(-)

diff --git a/Documentation/admin-guide/reporting-issues.rst 
b/Documentation/admin-guide/reporting-issues.rst
index 18b1280f7abf..a475e014f9ca 100644
--- a/Documentation/admin-guide/reporting-issues.rst
+++ b/Documentation/admin-guide/reporting-issues.rst
@@ -94,10 +94,11 @@ early if an issue that looks like a Linux kernel problem is 
actually caused by
 something else. These steps thus help to ensure the time you invest in this
 process won't feel wasted in the end:
 
- * Stop reading this document and report the problem to your vendor instead,
-   unless you are running the latest mainline kernel already or are willing to
-   install it. This kernel must not be modified or enhanced in any way, and
-   thus be considered 'vanilla'.
+ * Are you facing an issue with a Linux kernel a hardware or software vendor
+   provided? Then in almost all cases you are better off to stop reading this
+   document and reporting the issue to your vendor instead, unless you are
+   willing to install the latest Linux version yourself. Be aware the latter
+   will often be needed anyway to hunt down and fix issues.
 
  * See if the issue you are dealing with qualifies as regression, security
issue, or a really severe problem: those are 'issues of high priority' that
@@ -134,12 +135,14 @@ process won't feel wasted in the end:
 
 After these preparations you'll now enter the main part:
 
- * Install the latest Linux mainline kernel: that's where all issues get
-   fixed first, because it's the version line the kernel developers mainly
-   care about. Testing and reporting with the latest Linux stable kernel can
-   be an acceptable alternative in some situations, for example during the
-   merge window; but during that period you might want to suspend your efforts
-   till its end anyway.
+ * Unless you are already running the latest 'mainline' Linux kernel, better
+   go and install it for the reporting process. Testing and reporting with
+   the latest 'stable' Linux can be an acceptable alternative in some
+   situations; during the merge window that actually might be even the best
+   approach, but in that development phase it can be an even better idea to
+   suspend your efforts for a few days anyway. Whatever version you choose,
+   ideally use a 'vanilla' built. Ignoring these advices will dramatically
+   increase the risk you report will be rejected or ignored.
 
  * Ensure the kernel you just installed does not 'taint' itself when
running.
@@ -276,55 +279,54 @@ issues to the Linux kernel developers.
 Make sure you're using the upstream Linux kernel
 
 
-   *Stop reading this document and report the problem to your vendor instead,
-   unless you are running the latest mainline kernel already or are willing to
-   install it. This kernel must not be modified or enhanced in any way, and
-   thus be considered 'vanilla'.*
+   *Are you facing an issue with a Linux kernel a hardware or software vendor
+   provided? Then in almost all cases you are better off to stop reading this
+   document and reporting the issue to your vendor instead, unless you are
+   willing to install the latest Linux version yourself. Be aware the latter
+   will often be needed anyway to hunt down and fix issues.*
 
 Like most programmers, Linux kernel developers don't like to spend time dealing
-with reports for issues that don't even happen with the source code they
-maintain: it's just a waste everybody's time, yours included. That's why you
-later will have to test your issue with the latest 'vanilla' kernel: a kernel
-that was build using the Linux sources taken straight from `kernel.org
-`_ and not modified or enhanced in any way.
-
-Almost all kernels used in devices (Computers, Laptops, Smartphones, Routers,
-???) and most kernels shipped by Linux distributors are ancient from the point 
of
-kernel development and heavily modified. They thus do not qualify for reporting
-an issue to the Linux kernel developers: the issue you face with such a kernel
-might be fixed already or caused by the changes or additions, even if they look
-small or totally unrelated. That's why issues with such kernels need to be
-reported to the vendor that 

[PATCH 2/2] remoteproc: qcom: q6v5_wpss: Add support for sc7280 WPSS

[Rakesh Pillai]

Add support for PIL loading of WPSS processor for SC7280
WPSS boot will be requested by the wifi driver and hence
disable auto-boot for WPSS. Also add a separate shutdown
sequence handler for WPSS.

Signed-off-by: Rakesh Pillai 
---
 drivers/remoteproc/qcom_q6v5_adsp.c | 77 -
 1 file changed, 76 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/qcom_q6v5_adsp.c 
b/drivers/remoteproc/qcom_q6v5_adsp.c
index e024502..dc6b91d 100644
--- a/drivers/remoteproc/qcom_q6v5_adsp.c
+++ b/drivers/remoteproc/qcom_q6v5_adsp.c
@@ -58,6 +58,8 @@ struct adsp_pil_data {
const char *ssr_name;
const char *sysmon_name;
int ssctl_id;
+   bool is_wpss;
+   bool auto_boot;
 
const char **clk_ids;
int num_clks;
@@ -96,8 +98,54 @@ struct qcom_adsp {
struct qcom_rproc_glink glink_subdev;
struct qcom_rproc_ssr ssr_subdev;
struct qcom_sysmon *sysmon;
+
+   int (*shutdown)(struct qcom_adsp *adsp);
 };
 
+static int qcom_wpss_shutdown(struct qcom_adsp *adsp)
+{
+   unsigned long timeout;
+   unsigned int val;
+   int ret;
+
+   regmap_write(adsp->halt_map, adsp->halt_lpass + LPASS_HALTREQ_REG, 1);
+
+   /* Wait for halt ACK from QDSP6 */
+   timeout = jiffies + msecs_to_jiffies(ACK_TIMEOUT);
+   for (;;) {
+   ret = regmap_read(adsp->halt_map,
+ adsp->halt_lpass + LPASS_HALTACK_REG, );
+   if (ret || val || time_after(jiffies, timeout))
+   break;
+
+   usleep_range(1000, 1100);
+   }
+
+   /* Place the WPSS processor into reset */
+   reset_control_assert(adsp->restart);
+   /* wait after asserting subsystem restart from AOSS */
+   usleep_range(100, 105);
+   /* Remove the WPSS reset */
+   reset_control_deassert(adsp->restart);
+
+   usleep_range(100, 105);
+
+   regmap_write(adsp->halt_map, adsp->halt_lpass + LPASS_HALTREQ_REG, 0);
+
+   /* Wait for halt ACK from QDSP6 */
+   timeout = jiffies + msecs_to_jiffies(ACK_TIMEOUT);
+   for (;;) {
+   ret = regmap_read(adsp->halt_map,
+ adsp->halt_lpass + LPASS_HALTACK_REG, );
+   if (ret || !val || time_after(jiffies, timeout))
+   break;
+
+   usleep_range(1000, 1100);
+   }
+
+   return 0;
+}
+
 static int qcom_adsp_shutdown(struct qcom_adsp *adsp)
 {
unsigned long timeout;
@@ -270,7 +318,7 @@ static int adsp_stop(struct rproc *rproc)
if (ret == -ETIMEDOUT)
dev_err(adsp->dev, "timed out on wait\n");
 
-   ret = qcom_adsp_shutdown(adsp);
+   ret = adsp->shutdown(adsp);
if (ret)
dev_err(adsp->dev, "failed to shutdown: %d\n", ret);
 
@@ -439,6 +487,8 @@ static int adsp_probe(struct platform_device *pdev)
dev_err(>dev, "unable to allocate remoteproc\n");
return -ENOMEM;
}
+
+   rproc->auto_boot = desc->auto_boot;
rproc_coredump_set_elf_info(rproc, ELFCLASS32, EM_NONE);
 
adsp = (struct qcom_adsp *)rproc->priv;
@@ -447,6 +497,11 @@ static int adsp_probe(struct platform_device *pdev)
adsp->info_name = desc->sysmon_name;
platform_set_drvdata(pdev, adsp);
 
+   if (desc->is_wpss)
+   adsp->shutdown = qcom_wpss_shutdown;
+   else
+   adsp->shutdown = qcom_adsp_shutdown;
+
ret = adsp_alloc_memory_region(adsp);
if (ret)
goto free_rproc;
@@ -515,6 +570,8 @@ static const struct adsp_pil_data adsp_resource_init = {
.ssr_name = "lpass",
.sysmon_name = "adsp",
.ssctl_id = 0x14,
+   .is_wpss = false,
+   .auto_boot = true;
.clk_ids = (const char*[]) {
"sway_cbcr", "lpass_ahbs_aon_cbcr", "lpass_ahbm_aon_cbcr",
"qdsp6ss_xo", "qdsp6ss_sleep", "qdsp6ss_core", NULL
@@ -528,6 +585,8 @@ static const struct adsp_pil_data cdsp_resource_init = {
.ssr_name = "cdsp",
.sysmon_name = "cdsp",
.ssctl_id = 0x17,
+   .is_wpss = false,
+   .auto_boot = true;
.clk_ids = (const char*[]) {
"sway", "tbu", "bimc", "ahb_aon", "q6ss_slave", "q6ss_master",
"q6_axim", NULL
@@ -535,7 +594,23 @@ static const struct adsp_pil_data cdsp_resource_init = {
.num_clks = 7,
 };
 
+static const struct adsp_pil_data wpss_resource_init = {
+   .crash_reason_smem = 626,
+   .firmware_name = "wpss.mdt",
+   .ssr_name = "wpss",
+   .sysmon_name = "wpss",
+   .ssctl_id = 0x19,
+   .is_wpss = true,
+   .auto_boot = false;
+   .clk_ids = (const char*[]) {
+   "gcc_wpss_ahb_bdg_mst_clk", "gcc_wpss_ahb_clk",
+   "gcc_wpss_rscp_clk", NULL
+   },
+   .num_clks = 3,
+};
+
 static const struct of_device_id adsp_of_match[] = {
+   { .compatible = 

Re: MaxLinear, please maintain your drivers was Re: [PATCH] leds: lgm: fix gpiolib dependency

[Pavel Machek]

Hi!

> > > I'd like people from Intel to contact me. There's more to fix there,
> > > and AFAICT original author went away.
> > 
> > The following message to  was
> > undeliverable.
> 
> > : Recipient
> > +address rejected: User unknown in virtual mailbox table'
> 
> > commit c3987cd2bca34ddfec69027acedb2fae5ffcf7a0
> > Author: Amireddy Mallikarjuna reddy 
> 
> I asked around, and got told Mallikarjuna has been "sold" to MaxLinear,
> together with the rest of the Connected Home Division.  So he most likely
> still works on this stuff, just under a different banner.
> 
> > If someone knows how to contact the author, that would be welcome.
> 
> Alas, no idea about his MaxLinear address.

Thanks for the effort. Anyway, I suspect I'll just do this:

BR,
Pavel

diff --git a/drivers/leds/blink/Kconfig b/drivers/leds/blink/Kconfig
index 6dedc58c47b3..79493f21d365 100644
--- a/drivers/leds/blink/Kconfig
+++ b/drivers/leds/blink/Kconfig
@@ -1,14 +1,6 @@
-menuconfig LEDS_BLINK
-   bool "LED Blink support"
-   depends on LEDS_CLASS
-   help
- This option enables blink support for the leds class.
- If unsure, say Y.
-
-if LEDS_BLINK
-
 config LEDS_BLINK_LGM
tristate "LED support for Intel LGM SoC series"
+   depends on BROKEN
depends on GPIOLIB
depends on LEDS_CLASS
depends on MFD_SYSCON
@@ -17,5 +9,3 @@ config LEDS_BLINK_LGM
  Parallel to serial conversion, which is also called SSO controller,
  can drive external shift register for LED outputs.
  This enables LED support for Serial Shift Output controller(SSO).
-
-endif # LEDS_BLINK


-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: Digital signature

[PATCH 1/2] dt-bindings: remoteproc: qcom: Add SC7280 WPSS support

[Rakesh Pillai]

Add WPSS PIL loading support for SC7280 SoCs.

Signed-off-by: Rakesh Pillai 
---
 .../bindings/remoteproc/qcom,hexagon-v56.txt   | 35 --
 1 file changed, 20 insertions(+), 15 deletions(-)

diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,hexagon-v56.txt 
b/Documentation/devicetree/bindings/remoteproc/qcom,hexagon-v56.txt
index 1337a3d..edad5e8 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,hexagon-v56.txt
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,hexagon-v56.txt
@@ -9,6 +9,7 @@ on the Qualcomm Technology Inc. Hexagon v56 core.
Definition: must be one of:
"qcom,qcs404-cdsp-pil",
"qcom,sdm845-adsp-pil"
+   "qcom,sc7280-wpss-pil"
 
 - reg:
Usage: required
@@ -24,7 +25,13 @@ on the Qualcomm Technology Inc. Hexagon v56 core.
 - interrupt-names:
Usage: required
Value type: 
-   Definition: must be "wdog", "fatal", "ready", "handover", "stop-ack"
+   Definition: The interrupts needed depends on the compatible string
+   qcom,sdm845-adsp-pil:
+   qcom,qcs404-cdsp-pil:
+   must be "wdog", "fatal", "ready", "handover", "stop-ack"
+   qcom,sc7280-wpss-pil:
+   must be "wdog", "fatal", "ready", "handover", "stop-ack"
+   "shutdown-ack"
 
 - clocks:
Usage: required
@@ -35,19 +42,17 @@ on the Qualcomm Technology Inc. Hexagon v56 core.
 - clock-names:
Usage: required for SDM845 ADSP
Value type: 
-   Definition: List of clock input name strings sorted in the same
-   order as the clocks property. Definition must have
-   "xo", "sway_cbcr", "lpass_ahbs_aon_cbcr",
-   "lpass_ahbm_aon_cbcr", "qdsp6ss_xo", "qdsp6ss_sleep"
-   and "qdsp6ss_core".
-
-- clock-names:
-   Usage: required for QCS404 CDSP
-   Value type: 
-   Definition: List of clock input name strings sorted in the same
-   order as the clocks property. Definition must have
-   "xo", "sway", "tbu", "bimc", "ahb_aon", "q6ss_slave",
-   "q6ss_master", "q6_axim".
+   Definition: The clocks needed depends on the compatible string
+   qcom,sdm845-adsp-pil:
+   must be "xo", "sway_cbcr", "lpass_ahbs_aon_cbcr",
+   "lpass_ahbm_aon_cbcr", "qdsp6ss_xo", "qdsp6ss_sleep",
+   "qdsp6ss_core"
+   qcom,qcs404-cdsp-pil:
+   must be "xo", "sway", "tbu", "bimc", "ahb_aon", "q6ss_slave",
+   "q6ss_master", "q6_axim"
+   qcom,sc7280-wpss-pil:
+   must be "gcc_wpss_ahb_bdg_mst_clk", "gcc_wpss_ahb_clk",
+   "gcc_wpss_rscp_clk"
 
 - power-domains:
Usage: required
@@ -65,7 +70,7 @@ on the Qualcomm Technology Inc. Hexagon v56 core.
 Definition: must be "pdc_sync" and "cc_lpass"
 
 - reset-names:
-Usage: required for QCS404 CDSP
+Usage: required for QCS404 CDSP, SC7280 WPSS
 Value type: 
 Definition: must be "restart"
 
-- 
2.7.4

[PATCH 0/2] Add support for sc7280 WPSS PIL loading

[Rakesh Pillai]

Add support for PIL loading of WPSS co-processor for SC7280 SOCs.

Rakesh Pillai (2):
  dt-bindings: remoteproc: qcom: Add SC7280 WPSS support
  remoteproc: qcom: q6v5_wpss: Add support for sc7280 WPSS

 .../bindings/remoteproc/qcom,hexagon-v56.txt   | 35 +-
 drivers/remoteproc/qcom_q6v5_adsp.c| 77 +-
 2 files changed, 96 insertions(+), 16 deletions(-)

-- 
2.7.4

Re: [PATCH v5 03/15] pinctrl: bcm: add bcm63xx base code

[Álvaro Fernández Rojas]

Hi Andy,

> El 7 mar 2021, a las 20:05, Andy Shevchenko  
> escribió:
> 
> On Sat, Mar 6, 2021 at 5:57 PM Álvaro Fernández Rojas  
> wrote:
>> 
>> Add a helper for registering BCM63XX pin controllers.
> 
> Thanks for this, but I think we may use the fwnode API. See below.
> 
> ...
> 
>> +#include 
>> +#include 
> 
>> +#include 
> 
> + property.h
> + mod_devicetable.h
> 
>> +#include 
>> +
>> +#include "pinctrl-bcm63xx.h"
> 
>> +static int bcm63xx_reg_mask_xlate(struct gpio_regmap *gpio,
>> + unsigned int base, unsigned int offset,
>> + unsigned int *reg, unsigned int *mask)
>> +{
>> +   unsigned int line = offset % BCM63XX_BANK_GPIOS;
>> +   unsigned int stride = offset / BCM63XX_BANK_GPIOS;
>> +
>> +   *reg = base - stride * BCM63XX_BANK_SIZE;
>> +   *mask = BIT(line);
>> +
>> +   return 0;
>> +}
> 
>> +static int bcm63xx_gpio_probe(struct device *dev, struct device_node *node,
> 
> device_node *node -> fwnode_handle *fwnode
> 
>> + const struct bcm63xx_pinctrl_soc *soc,
>> + struct bcm63xx_pinctrl *pc)
>> +{
>> +   struct gpio_regmap_config grc = {0};
>> +
>> +   grc.parent = dev;
> 
>> +   grc.fwnode = >fwnode;
> 
> grc.fwnode = fwnode;
> 
>> +   grc.ngpio = soc->ngpios;
>> +   grc.ngpio_per_reg = BCM63XX_BANK_GPIOS;
>> +   grc.regmap = pc->regs;
>> +   grc.reg_mask_xlate = bcm63xx_reg_mask_xlate;
> 
>> +   if (of_property_read_u32(node, "data", _dat_base))
> 
> fwnode_property_read_u32()
> 
>> +   grc.reg_dat_base = BCM63XX_DATA_REG;
>> +   grc.reg_set_base = grc.reg_dat_base;
> 
>> +   if (of_property_read_u32(node, "dirout", _dir_out_base))
> 
> Ditto.
> 
>> +   grc.reg_dir_out_base = BCM63XX_DIROUT_REG;
>> +
>> +   return PTR_ERR_OR_ZERO(devm_gpio_regmap_register(dev, ));
>> +}
>> +
>> +int bcm63xx_pinctrl_probe(struct platform_device *pdev,
>> + const struct bcm63xx_pinctrl_soc *soc,
>> + void *driver_data)
>> +{
>> +   struct device *dev = >dev;
>> +   struct bcm63xx_pinctrl *pc;
> 
>> +   struct device_node *node;
> 
> struct fwnode_handle *fwnode;
> 
>> +   int err;
>> +
>> +   pc = devm_kzalloc(dev, sizeof(*pc), GFP_KERNEL);
>> +   if (!pc)
>> +   return -ENOMEM;
>> +
>> +   platform_set_drvdata(pdev, pc);
>> +
>> +   pc->dev = dev;
>> +   pc->driver_data = driver_data;
> 
>> +   pc->regs = syscon_node_to_regmap(dev->parent->of_node);
>> +   if (IS_ERR(pc->regs))
>> +   return PTR_ERR(pc->regs);
>> +
>> +   pc->pctl_desc.name = dev_name(dev);
>> +   pc->pctl_desc.pins = soc->pins;
>> +   pc->pctl_desc.npins = soc->npins;
>> +   pc->pctl_desc.pctlops = soc->pctl_ops;
>> +   pc->pctl_desc.pmxops = soc->pmx_ops;
>> +   pc->pctl_desc.owner = THIS_MODULE;
>> +
>> +   pc->pctl_dev = devm_pinctrl_register(dev, >pctl_desc, pc);
>> +   if (IS_ERR(pc->pctl_dev))
>> +   return PTR_ERR(pc->pctl_dev);
> 
>> +   for_each_child_of_node(dev->of_node, node) {
> 
> device_for_each_child_node(dev, fwnode) {
> 
>> +   if (of_match_node(bcm63xx_gpio_of_match, node)) {
> 
> // for now, since we have not an analogue (yet)
> node ==> to_of_node(fwnode)

So you want me to convert everything to fwnode, but then I would need to use 
of_node here…
It makes more sense to me to use of_node for now and convert it to fwnode in 
the future…
@Linus, what do you think?

> 
>> +   err = bcm63xx_gpio_probe(dev, node, soc, pc);
> 
> ...(dev, fwnode, soc, pc);
> 
>> +   if (err) {
>> +   dev_err(dev, "could not add GPIO chip\n");
> 
>> +   of_node_put(node);
> 
> fwnode_handle_put(fwnode);
> 
>> +   return err;
>> +   }
>> +   }
>> +   }
>> +
>> +   return 0;
>> +}
>> diff --git a/drivers/pinctrl/bcm/pinctrl-bcm63xx.h 
>> b/drivers/pinctrl/bcm/pinctrl-bcm63xx.h
>> new file mode 100644
>> index ..3bdb50021f1b
>> --- /dev/null
>> +++ b/drivers/pinctrl/bcm/pinctrl-bcm63xx.h
>> @@ -0,0 +1,43 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * Copyright (C) 2021 Álvaro Fernández Rojas 
>> + * Copyright (C) 2016 Jonas Gorski 
>> + */
>> +
>> +#ifndef __PINCTRL_BCM63XX_H__
>> +#define __PINCTRL_BCM63XX_H__
>> +
>> +#include 
>> +
>> +#define BCM63XX_BANK_GPIOS 32
>> +
>> +struct bcm63xx_pinctrl_soc {
>> +   struct pinctrl_ops *pctl_ops;
>> +   struct pinmux_ops *pmx_ops;
>> +
>> +   const struct pinctrl_pin_desc *pins;
>> +   unsigned npins;
>> +
>> +   unsigned int ngpios;
>> +};
>> +
>> +struct bcm63xx_pinctrl {
>> +   struct device *dev;
>> +   struct regmap *regs;
>> +
>> +   struct pinctrl_desc pctl_desc;
>> +   struct pinctrl_dev *pctl_dev;

Re: [PATCH v6 3/4] x86/vmemmap: Handle unpopulated sub-pmd ranges

[Oscar Salvador]

On Wed, Mar 10, 2021 at 11:37:53AM +0530, Naresh Kamboju wrote:
> Hi Oscar,

Hi Naresh,

> While building the linux next 20210310 tag for x86_64 architecture with 
> clang-12
> and gcc-9 the following warnings / errors were noticed.
> 
> arch/x86/mm/init_64.c:1585:6: error: implicit declaration of function
> 'vmemmap_use_new_sub_pmd' [-Werror,-Wimplicit-function-declaration]
> vmemmap_use_new_sub_pmd(addr, next);
> ^
> arch/x86/mm/init_64.c:1591:4: error: implicit declaration of function
> 'vmemmap_use_sub_pmd' [-Werror,-Wimplicit-function-declaration]
> vmemmap_use_sub_pmd(addr, next);
> ^
> 2 errors generated.
> make[3]: *** [scripts/Makefile.build:271: arch/x86/mm/init_64.o] Error 1
> 
> Reported-by: Naresh Kamboju 

Yes, this was also reported by Zi Yan here [1].
Looking into your .config, seems to be the same issue as you have
CONFIG_SPARSE_VMEMMAP but !CONFIG_MEMORY_HOTPLUG.

This version fixes those compilation errors.

Thanks for reporting it anyway!

[1] 
https://lore.kernel.org/linux-mm/YEfoH8US4YVxak7r@localhost.localdomain/T/#ma566ff437ff4bf8fcc5f80f62cd0cc8761edd12d

> Steps to reproduce:
> ---
> # TuxMake is a command line tool and Python library that provides
> # portable and repeatable Linux kernel builds across a variety of
> # architectures, toolchains, kernel configurations, and make targets.
> #
> # TuxMake supports the concept of runtimes.
> # See https://docs.tuxmake.org/runtimes/, for that to work it requires
> # that you install podman or docker on your system.
> #
> # To install tuxmake on your system globally:
> # sudo pip3 install -U tuxmake
> #
> # See https://docs.tuxmake.org/ for complete documentation.
> 
> 
> tuxmake --runtime podman --target-arch x86_64 --toolchain clang-12
> --kconfig defconfig --kconfig-add
> https://builds.tuxbuild.com/1pYCPt4WlgSfSdv1BULm6ABINeJ/config
> 
> 
> Build pipeline error link,
> https://gitlab.com/Linaro/lkft/mirrors/next/linux-next/-/jobs/1085496613#L428
> 
> -- 
> Linaro LKFT
> https://lkft.linaro.org



-- 
Oscar Salvador
SUSE L3

Re: [PATCH v7 2/2] ARM: ftrace: Add MODULE_PLTS support

[Alexander Sverdlin]

Hi!

On 09/03/2021 18:42, Qais Yousef wrote:
>>> I tried on 5.12-rc2 and 5.11 but couldn't reproduce the problem using your
> I still can't reproduce on 5.12-rc2.
> 
> I do have CONFIG_ARM_MODULE_PLTS=y. Do you need to do something else after
> loading the module? I tried starting ftrace, but maybe there's a particular
> combination required?

You need to load a BIG module, so big that it has no place in the modules area
any more and goes to vmalloc area.

>>> instructions on the other email. But most likely because I'm hitting another
>>> problem that could be masking it. I'm not sure it is related or just 
>>> randomly
>>> happened to hit it.
>>>
>>> Did you see something similar?
>> [...]
>>
>>> [0.00] [] (ftrace_bug) from [] 
>>> (ftrace_process_locs+0x2b0/0x518)
>>> [0.00]  r7:c3817ac4 r6:c38040c0 r5:0a3c r4:000134e4
>>> [0.00] [] (ftrace_process_locs) from [] 
>>> (ftrace_init+0xc8/0x174)
>>> [0.00]  r10:c2ffa000 r9:c2be8a78 r8:c2c5d1fc r7:c2c0c208 
>>> r6:0001 r5:c2d0908c
>>> [0.00]  r4:c362f518
>>> [0.00] [] (ftrace_init) from [] 
>>> (start_kernel+0x2f4/0x5b8)
>>> [0.00]  r9:c2be8a78 r8:dbfffec0 r7: r6:c36385cc 
>>> r5:c2d08f00 r4:c2ffa000
>>> [0.00] [] (start_kernel) from [<>] (0x0)
>> This means, FTRACE has more problems with your kernel/compiler/platform, 
>> I've addressed similar issue
>> in the past, but my patch should be long merged:
>>
>> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1817963.html
>>
>> Could it be the same problem as here:
>> https://www.spinics.net/lists/arm-kernel/msg854022.html
>>
>> Seems that the size check deserves something line BUILD_BUG_ON() with 
>> FTRACE...
> So I only see this when I convert all modules to be built-in
> 
>   sed -i 's/=m/=y/' .config
> 
> FWIW, I see the problem with your patch applied too. Trying to dig more into
> it..

Then it's definitely the problem explained in the second link. If you have 
THUMB2 kernel, maybe
you have to switch to ARM.

-- 
Best regards,
Alexander Sverdlin.

Re: [PATCH 01/10] spi: spi-axi-spi-engine: remove usage of delay_usecs

[Lars-Peter Clausen]

On 3/10/21 8:16 AM, Alexandru Ardelean wrote:

On Mon, 8 Mar 2021 at 18:42, Lars-Peter Clausen  wrote:

On 3/8/21 3:54 PM, Alexandru Ardelean wrote:

The 'delay_usecs' field was handled for backwards compatibility in case
there were some users that still configured SPI delay transfers with
this field.

They should all be removed by now.

Signed-off-by: Alexandru Ardelean 
---
   drivers/spi/spi-axi-spi-engine.c | 12 
   1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/spi/spi-axi-spi-engine.c b/drivers/spi/spi-axi-spi-engine.c
index af86e6d6e16b..80c3e38f5c1b 100644
--- a/drivers/spi/spi-axi-spi-engine.c
+++ b/drivers/spi/spi-axi-spi-engine.c
@@ -170,14 +170,10 @@ static void spi_engine_gen_sleep(struct 
spi_engine_program *p, bool dry,
   unsigned int t;
   int delay;

- if (xfer->delay_usecs) {
- delay = xfer->delay_usecs;
- } else {
- delay = spi_delay_to_ns(>delay, xfer);
- if (delay < 0)
- return;
- delay /= 1000;
- }
+ delay = spi_delay_to_ns(>delay, xfer);
+ if (delay < 0)
+ return;

Bit of a nit, but this could be `delay <= 0` and then drop the check for
`delay == 0` below.

hmm, that's a bit debatable, because the `delay == 0` check comes
after `delay /= 1000` ;
to do what you're suggesting, it would probably need a
DIV_ROUND_UP(delay, 1000) to make sure that even sub-microsecond
delays don't become zero;


Ah, true. Lets keep the code as it is.

On the other hand you could argue that we should round up to ensure the 
delay is at least as long as requested. But that is something that 
should be changed independently from this series.

[PATCH 3/3] arm64: mm: hugetlb: add support for free vmemmap pages of HugeTLB

[Muchun Song]

The preparation of supporting freeing vmemmap associated with each
infrastructure is ready, so now we can support it for arm64.

Signed-off-by: Muchun Song 
---
 arch/arm64/mm/mmu.c | 5 +
 fs/Kconfig  | 4 ++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 3802cfbdd20d..6051a120c906 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1109,6 +1110,10 @@ int __meminit vmemmap_populate(unsigned long start, 
unsigned long end, int node,
pmd_t *pmdp;
 
WARN_ON((start < VMEMMAP_START) || (end > VMEMMAP_END));
+
+   if (is_hugetlb_free_vmemmap_enabled() && !altmap)
+   return vmemmap_populate_basepages(start, end, node, altmap);
+
do {
next = pmd_addr_end(addr, end);
 
diff --git a/fs/Kconfig b/fs/Kconfig
index b5dcc68aab25..d90860135844 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -239,9 +239,9 @@ config HUGETLB_PAGE
 
 config HUGETLB_PAGE_FREE_VMEMMAP
def_bool HUGETLB_PAGE
-   depends on X86_64
+   select HAVE_BOOTMEM_INFO_NODE if X86_64
depends on SPARSEMEM_VMEMMAP
-   depends on HAVE_BOOTMEM_INFO_NODE
+   depends on X86_64 || ARM64
 
 config MEMFD_CREATE
def_bool TMPFS || HUGETLBFS
-- 
2.11.0

[PATCH 2/3] mm: hugetlb: introduce arch_free_vmemmap_page

[Muchun Song]

We register bootmem info for vmemmap pages when boot on x86-64, so
the vmemmap pages must be freed by using free_bootmem_page(). But
on some other architectures, we do not need bootmem info. In this
case, free_reserved_page() is enough to free vmemmap pages.
Currently, only x86-64 need free_bootmem_page(), so introduce a
default arch_free_vmemmap_page() which use free_reserved_page()
to free vmemmap pages directly. On x86-64, we can implement
arch_free_vmemmap_page() to override the default behavior.

Signed-off-by: Muchun Song 
---
 arch/x86/mm/init_64.c | 5 +
 mm/sparse-vmemmap.c   | 9 +++--
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 39f88c5faadc..732609dad0ec 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -1575,6 +1575,11 @@ int __meminit vmemmap_populate(unsigned long start, 
unsigned long end, int node,
 }
 
 #ifdef CONFIG_HAVE_BOOTMEM_INFO_NODE
+void arch_free_vmemmap_page(struct page *page)
+{
+   free_bootmem_page(page);
+}
+
 void register_page_bootmem_memmap(unsigned long section_nr,
  struct page *start_page, unsigned long 
nr_pages)
 {
diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
index 60fc6cd6cd23..76f7b52820e3 100644
--- a/mm/sparse-vmemmap.c
+++ b/mm/sparse-vmemmap.c
@@ -156,16 +156,21 @@ static void vmemmap_remap_range(unsigned long start, 
unsigned long end,
flush_tlb_kernel_range(start + PAGE_SIZE, end);
 }
 
+void __weak arch_free_vmemmap_page(struct page *page)
+{
+   free_reserved_page(page);
+}
+
 /*
  * Free a vmemmap page. A vmemmap page can be allocated from the memblock
  * allocator or buddy allocator. If the PG_reserved flag is set, it means
  * that it allocated from the memblock allocator, just free it via the
- * free_bootmem_page(). Otherwise, use __free_page().
+ * arch_free_vmemmap_page(). Otherwise, use __free_page().
  */
 static inline void free_vmemmap_page(struct page *page)
 {
if (PageReserved(page))
-   free_bootmem_page(page);
+   arch_free_vmemmap_page(page);
else
__free_page(page);
 }
-- 
2.11.0

[PATCH 0/3] Add support for free vmemmap pages of HugeTLB for arm64

[Muchun Song]

This patchset is based on the series of "Free some vmemmap pages of HugeTLB
page". More details can refer to the below link.

  https://lkml.kernel.org/r/20210308102807.59745-1-songmuc...@bytedance.com

I often received some feedback (We want to test this feature on arm64) before.
Because the previous code has been reviewed for 18 versions and is merged
into mm tree, I think that it is time to release this patchset. If you want
to test then you can start now :-). And I also hope someone can review this.

Thanks.

Muchun Song (3):
  mm: bootmem_info: mark register_page_bootmem_info_section __init
  mm: hugetlb: introduce arch_free_vmemmap_page
  arm64: mm: hugetlb: add support for free vmemmap pages of HugeTLB

 arch/arm64/mm/mmu.c   | 5 +
 arch/x86/mm/init_64.c | 5 +
 fs/Kconfig| 4 ++--
 mm/bootmem_info.c | 4 ++--
 mm/sparse-vmemmap.c   | 9 +++--
 5 files changed, 21 insertions(+), 6 deletions(-)

-- 
2.11.0

[PATCH 1/3] mm: bootmem_info: mark register_page_bootmem_info_section __init

[Muchun Song]

The register_page_bootmem_info_section() is only called from __init
functions, so mark it __init as well.

Signed-off-by: Muchun Song 
---
 mm/bootmem_info.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/bootmem_info.c b/mm/bootmem_info.c
index 5b152dba7344..f03f42f426f6 100644
--- a/mm/bootmem_info.c
+++ b/mm/bootmem_info.c
@@ -39,7 +39,7 @@ void put_page_bootmem(struct page *page)
 }
 
 #ifndef CONFIG_SPARSEMEM_VMEMMAP
-static void register_page_bootmem_info_section(unsigned long start_pfn)
+static void __init register_page_bootmem_info_section(unsigned long start_pfn)
 {
unsigned long mapsize, section_nr, i;
struct mem_section *ms;
@@ -74,7 +74,7 @@ static void register_page_bootmem_info_section(unsigned long 
start_pfn)
 
 }
 #else /* CONFIG_SPARSEMEM_VMEMMAP */
-static void register_page_bootmem_info_section(unsigned long start_pfn)
+static void __init register_page_bootmem_info_section(unsigned long start_pfn)
 {
unsigned long mapsize, section_nr, i;
struct mem_section *ms;
-- 
2.11.0

[PATCH] bpf: fix warning comparing pointer to 0

[Jiapeng Chong]

Fix the following coccicheck warning:

./tools/testing/selftests/bpf/progs/fentry_test.c:67:12-13: WARNING
comparing pointer to 0.

Reported-by: Abaci Robot 
Signed-off-by: Jiapeng Chong 
---
 tools/testing/selftests/bpf/progs/fentry_test.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/bpf/progs/fentry_test.c 
b/tools/testing/selftests/bpf/progs/fentry_test.c
index 5f645fd..52a550d 100644
--- a/tools/testing/selftests/bpf/progs/fentry_test.c
+++ b/tools/testing/selftests/bpf/progs/fentry_test.c
@@ -64,7 +64,7 @@ struct bpf_fentry_test_t {
 SEC("fentry/bpf_fentry_test7")
 int BPF_PROG(test7, struct bpf_fentry_test_t *arg)
 {
-   if (arg == 0)
+   if (!arg)
test7_result = 1;
return 0;
 }
-- 
1.8.3.1

Re: [PATCH 01/10] spi: spi-axi-spi-engine: remove usage of delay_usecs

[Alexandru Ardelean]

On Mon, 8 Mar 2021 at 18:42, Lars-Peter Clausen  wrote:
>
> On 3/8/21 3:54 PM, Alexandru Ardelean wrote:
> > The 'delay_usecs' field was handled for backwards compatibility in case
> > there were some users that still configured SPI delay transfers with
> > this field.
> >
> > They should all be removed by now.
> >
> > Signed-off-by: Alexandru Ardelean 
> > ---
> >   drivers/spi/spi-axi-spi-engine.c | 12 
> >   1 file changed, 4 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/spi/spi-axi-spi-engine.c 
> > b/drivers/spi/spi-axi-spi-engine.c
> > index af86e6d6e16b..80c3e38f5c1b 100644
> > --- a/drivers/spi/spi-axi-spi-engine.c
> > +++ b/drivers/spi/spi-axi-spi-engine.c
> > @@ -170,14 +170,10 @@ static void spi_engine_gen_sleep(struct 
> > spi_engine_program *p, bool dry,
> >   unsigned int t;
> >   int delay;
> >
> > - if (xfer->delay_usecs) {
> > - delay = xfer->delay_usecs;
> > - } else {
> > - delay = spi_delay_to_ns(>delay, xfer);
> > - if (delay < 0)
> > - return;
> > - delay /= 1000;
> > - }
> > + delay = spi_delay_to_ns(>delay, xfer);
> > + if (delay < 0)
> > + return;
>
> Bit of a nit, but this could be `delay <= 0` and then drop the check for
> `delay == 0` below.

hmm, that's a bit debatable, because the `delay == 0` check comes
after `delay /= 1000` ;
to do what you're suggesting, it would probably need a
DIV_ROUND_UP(delay, 1000) to make sure that even sub-microsecond
delays don't become zero;

if you're acking this suggestion i'll implement it;
i'll wait a few more days to see if there are any other acks or
complaints on the set before sending a V2;

btw: this new spi_delay struct supports delays in microseconds,
nanoseconds and clock cycles;
at some point it may be interesting to use a
`spi_delay_to_clk_cycles()` for this driver and other similar;

>
> > + delay /= 1000;
> >
> >   if (delay == 0)
> >   return;
>
>

[PATCH] xtensa: fix warning comparing pointer to 0

[Jiapeng Chong]

Fix the following coccicheck warning:

./arch/xtensa/kernel/pci.c:79:17-18: WARNING comparing pointer to 0.

Reported-by: Abaci Robot 
Signed-off-by: Jiapeng Chong 
---
 arch/xtensa/kernel/pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/xtensa/kernel/pci.c b/arch/xtensa/kernel/pci.c
index 3f32e27..62c900e 100644
--- a/arch/xtensa/kernel/pci.c
+++ b/arch/xtensa/kernel/pci.c
@@ -76,7 +76,7 @@ int pci_iobar_pfn(struct pci_dev *pdev, int bar, struct 
vm_area_struct *vma)
struct pci_controller *pci_ctrl = (struct pci_controller*) 
pdev->sysdata;
resource_size_t ioaddr = pci_resource_start(pdev, bar);
 
-   if (pci_ctrl == 0)
+   if (!pci_ctrl)
return -EINVAL; /* should never happen */
 
/* Convert to an offset within this PCI controller */
-- 
1.8.3.1

[PATCH RFC 1/1] kernel/cpu: to track which CPUHP callback is failed

[Dongli Zhang]

During bootup or cpu hotplug, the cpuhp_up_callbacks() calls many CPUHP
callbacks (e.g., perf, mm, workqueue, RCU, kvmclock and more) for each
cpu to online. It may roll back to its previous state if any of
callbacks is failed. As a result, the user will not be able to know
which callback is failed and usually the only symptom is cpu online
failure.

The error log is printed for once to have confirm which callback is
failed.

Cc: Joe Jin 
Signed-off-by: Dongli Zhang 
---
I used 'RFC' because WARN_ON_ONCE() is always used for the result from
cpuhp_invoke_callback(). I would prefer to get feedback from
maintainers/reviewers. Here I prefer to print the cpuhp name and state
value to help confirm the specific callback that is failed.

 kernel/cpu.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/kernel/cpu.c b/kernel/cpu.c
index 1b6302ecbabe..c7a719079272 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -621,6 +621,10 @@ static int cpuhp_up_callbacks(unsigned int cpu, struct 
cpuhp_cpu_state *st,
st->state++;
ret = cpuhp_invoke_callback(cpu, st->state, true, NULL, NULL);
if (ret) {
+   pr_err_once("CPUHP callback failure (%d) for cpu %u at 
%s (%d)\n",
+   ret, cpu, cpuhp_get_step(st->state)->name,
+   st->state);
+
if (can_rollback_cpu(st)) {
st->target = prev_state;
undo_cpu_up(cpu, st);
-- 
2.17.1

[PATCH] drm/amd/display: fix warning comparing pointer to 0

[Jiapeng Chong]

Fix the following coccicheck warning:

./drivers/gpu/drm/amd/display/dc/dsc/rc_calc.c:76:14-15: WARNING
comparing pointer to 0.

Reported-by: Abaci Robot 
Signed-off-by: Jiapeng Chong 
---
 drivers/gpu/drm/amd/display/dc/dsc/rc_calc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dsc/rc_calc.c 
b/drivers/gpu/drm/amd/display/dc/dsc/rc_calc.c
index c6a1cd8..69211f5 100644
--- a/drivers/gpu/drm/amd/display/dc/dsc/rc_calc.c
+++ b/drivers/gpu/drm/amd/display/dc/dsc/rc_calc.c
@@ -73,7 +73,7 @@ static void get_qp_set(qp_set qps, enum colour_mode cm, enum 
bits_per_comp bpc,
TABLE_CASE(420, 12, min);
}
 
-   if (table == 0)
+   if (!table)
return;
 
index = (bpp - table[0].bpp) * 2;
-- 
1.8.3.1

Re: [PATCH 0/2] AM64: Add USB support

[Kishon Vijay Abraham I]

+Vinod

Hi Aswath,

On 10/03/21 12:27 pm, Aswath Govindraju wrote:
> Hi Nishanth,
> 
> On 01/03/21 8:52 pm, Nishanth Menon wrote:
>> On 11:21-20210301, Aswath Govindraju wrote:
>>> The following series of patches, add USB support for AM64.
>>>
>>> This series of patches depends on,
>>> https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=439039
>>>
>>> Aswath Govindraju (2):
>>>   arm64: dts: ti: k3-am64-main: Add DT node for USB subsystem
>>>   arm64: dts: ti: k3-am642-evm: Add USB support
>>>
>>>  arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 30 
>>>  arch/arm64/boot/dts/ti/k3-am642-evm.dts  | 18 ++
>>>  2 files changed, 48 insertions(+)
>>
>> Please update the series to include SK as well.
>>
> 
> I was planning on posting patches that add support for USB in SK later
> because of phy dependencies.

The dependency is only on [1] right? I've got all the required ACKs so
it should be okay to include it in this series. (That patch will be
required only when PCIe DT is merged for me.)

Nishant, would you be okay to merge [1] along with other patches from
Aswath? There is no dependency as such on my other PHY patches, so don't
think there is a need for a stable tag here.

Thanks
Kishon

[1] ->
https://lore.kernel.org/linux-devicetree/20210222112314.10772-4-kis...@ti.com/
> 
> Thanks,
> Aswath
> 

Re: [mm, slub] 8ff60eb052: stress-ng.rawpkt.ops_per_sec -47.9% regression

[Christoph Lameter]

On Tue, 9 Mar 2021, Linus Torvalds wrote:

> So when you wrote:
>
> However, the current code accidentally stops looking at the partial list
> completely in that case.  Especially on kernels without CONFIG_NUMA set,
> this means that get_partial() fails and new_slab_objects() falls back to
> new_slab(), allocating new pages.  This could lead to an unnecessary
> increase in memory fragmentation.
>
> it really looks like this might well have been very intentional
> indeed. Or at least very beneficial for _some_ loads.
>
> Comments?

Yes the thought was that adding an additional page when contention is
there on the page objects will increase possible concurrency while
avoiding locks and increase the ability to allocate / free concurrently
from a multitude of objects.

Re: [PATCH 0/2] AM64: Add USB support

[Aswath Govindraju]

Hi Nishanth,

On 01/03/21 8:52 pm, Nishanth Menon wrote:
> On 11:21-20210301, Aswath Govindraju wrote:
>> The following series of patches, add USB support for AM64.
>>
>> This series of patches depends on,
>> https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=439039
>>
>> Aswath Govindraju (2):
>>   arm64: dts: ti: k3-am64-main: Add DT node for USB subsystem
>>   arm64: dts: ti: k3-am642-evm: Add USB support
>>
>>  arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 30 
>>  arch/arm64/boot/dts/ti/k3-am642-evm.dts  | 18 ++
>>  2 files changed, 48 insertions(+)
> 
> Please update the series to include SK as well.
> 

I was planning on posting patches that add support for USB in SK later
because of phy dependencies.

Thanks,
Aswath

Re: [PATCH v2] libnvdimm: Notify disk drivers to revalidate region read-only

[Christoph Hellwig]

Looks good to me:

Reviewed-by: Christoph Hellwig 

Question on the pre-existing code: given that nvdimm_check_and_set_ro is
the only caller of set_disk_ro for nvdimm devices, we'll also get
the message when initially setting up any read-only disk.  Is that
intentional?

[PATCH] hexagon: fix warning comparing pointer to 0

[Jiapeng Chong]

Fix the following coccicheck warning:

./arch/hexagon/kernel/traps.c:142:6-7: WARNING comparing pointer to 0.

Reported-by: Abaci Robot 
Signed-off-by: Jiapeng Chong 
---
 arch/hexagon/kernel/traps.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/hexagon/kernel/traps.c b/arch/hexagon/kernel/traps.c
index 904134b..58083df 100644
--- a/arch/hexagon/kernel/traps.c
+++ b/arch/hexagon/kernel/traps.c
@@ -139,7 +139,7 @@ static void do_show_stack(struct task_struct *task, 
unsigned long *fp,
}
 
/* Attempt to continue past exception. */
-   if (0 == newfp) {
+   if (!newfp) {
struct pt_regs *regs = (struct pt_regs *) (((void *)fp)
+ 8);
 
-- 
1.8.3.1

Re: [PATCH v5] printk: Userspace format enumeration support

[Greg Kroah-Hartman]

On Wed, Mar 10, 2021 at 02:30:31AM +, Chris Down wrote:
> + ps->file = debugfs_create_file(pi_get_module_name(mod), 0444, dfs_index,
> +ps, _index_fops);
> +
> + if (IS_ERR(ps->file)) {
> + pi_sec_remove(mod);
> + return;
> + }

No need to check this and try to clean up if there is a problem, just
save the pointer off and call debugfs_remove() when you want to clean
up.

Or better yet, no need to save anything, you can always look it up when
you want to remove it, that will save you one pointer per module.

thanks,

greg k-h

Re: [v8,5/7] PCI: mediatek-gen3: Add MSI support

[Jianjun Wang]

Hi Marc,

Thanks for your review.

On Tue, 2021-03-09 at 11:23 +, Marc Zyngier wrote:
> On Wed, 24 Feb 2021 06:11:30 +,
> Jianjun Wang  wrote:
> > 
> > Add MSI support for MediaTek Gen3 PCIe controller.
> > 
> > This PCIe controller supports up to 256 MSI vectors, the MSI hardware
> > block diagram is as follows:
> > 
> >   +-+
> >   | GIC |
> >   +-+
> >  ^
> >  |
> >  port->irq
> >  |
> >  +-+-+-+-+-+-+-+-+
> >  |0|1|2|3|4|5|6|7| (PCIe intc)
> >  +-+-+-+-+-+-+-+-+
> >   ^ ^   ^
> >   | |...|
> >   +---+ +--++---+
> >   |||
> > +-+-+---+--+--+  +-+-+---+--+--+  +-+-+---+--+--+
> > |0|1|...|30|31|  |0|1|...|30|31|  |0|1|...|30|31| (MSI sets)
> > +-+-+---+--+--+  +-+-+---+--+--+  +-+-+---+--+--+
> >  ^ ^  ^  ^^ ^  ^  ^^ ^  ^  ^
> >  | |  |  || |  |  || |  |  |  (MSI vectors)
> >  | |  |  || |  |  || |  |  |
> > 
> >   (MSI SET0)   (MSI SET1)  ...   (MSI SET7)
> > 
> > With 256 MSI vectors supported, the MSI vectors are composed of 8 sets,
> > each set has its own address for MSI message, and supports 32 MSI vectors
> > to generate interrupt.
> > 
> > Signed-off-by: Jianjun Wang 
> > Acked-by: Ryder Lee 
> > ---
> >  drivers/pci/controller/pcie-mediatek-gen3.c | 277 
> >  1 file changed, 277 insertions(+)
> > 
> > diff --git a/drivers/pci/controller/pcie-mediatek-gen3.c 
> > b/drivers/pci/controller/pcie-mediatek-gen3.c
> > index 8b3b5f838b69..3cbec22ece0c 100644
> > --- a/drivers/pci/controller/pcie-mediatek-gen3.c
> > +++ b/drivers/pci/controller/pcie-mediatek-gen3.c
> > @@ -14,6 +14,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -48,12 +49,29 @@
> >  #define PCIE_LINK_STATUS_REG   0x154
> >  #define PCIE_PORT_LINKUP   BIT(8)
> >  
> > +#define PCIE_MSI_SET_NUM   8
> > +#define PCIE_MSI_IRQS_PER_SET  32
> > +#define PCIE_MSI_IRQS_NUM \
> > +   (PCIE_MSI_IRQS_PER_SET * PCIE_MSI_SET_NUM)
> > +
> >  #define PCIE_INT_ENABLE_REG0x180
> > +#define PCIE_MSI_ENABLEGENMASK(PCIE_MSI_SET_NUM + 8 - 
> > 1, 8)
> > +#define PCIE_MSI_SHIFT 8
> >  #define PCIE_INTX_SHIFT24
> >  #define PCIE_INTX_ENABLE \
> > GENMASK(PCIE_INTX_SHIFT + PCI_NUM_INTX - 1, PCIE_INTX_SHIFT)
> >  
> >  #define PCIE_INT_STATUS_REG0x184
> > +#define PCIE_MSI_SET_ENABLE_REG0x190
> > +#define PCIE_MSI_SET_ENABLEGENMASK(PCIE_MSI_SET_NUM - 1, 0)
> > +
> > +#define PCIE_MSI_SET_BASE_REG  0xc00
> > +#define PCIE_MSI_SET_OFFSET0x10
> > +#define PCIE_MSI_SET_STATUS_OFFSET 0x04
> > +#define PCIE_MSI_SET_ENABLE_OFFSET 0x08
> > +
> > +#define PCIE_MSI_SET_ADDR_HI_BASE  0xc80
> > +#define PCIE_MSI_SET_ADDR_HI_OFFSET0x04
> >  
> >  #define PCIE_TRANS_TABLE_BASE_REG  0x800
> >  #define PCIE_ATR_SRC_ADDR_MSB_OFFSET   0x4
> > @@ -73,6 +91,16 @@
> >  #define PCIE_ATR_TLP_TYPE_MEM  PCIE_ATR_TLP_TYPE(0)
> >  #define PCIE_ATR_TLP_TYPE_IO   PCIE_ATR_TLP_TYPE(2)
> >  
> > +/**
> > + * struct mtk_pcie_msi - MSI information for each set
> > + * @base: IO mapped register base
> > + * @msg_addr: MSI message address
> > + */
> > +struct mtk_msi_set {
> > +   void __iomem *base;
> > +   phys_addr_t msg_addr;
> > +};
> > +
> >  /**
> >   * struct mtk_pcie_port - PCIe port information
> >   * @dev: pointer to PCIe device
> > @@ -86,6 +114,11 @@
> >   * @irq: PCIe controller interrupt number
> >   * @irq_lock: lock protecting IRQ register access
> >   * @intx_domain: legacy INTx IRQ domain
> > + * @msi_domain: MSI IRQ domain
> > + * @msi_bottom_domain: MSI IRQ bottom domain
> > + * @msi_sets: MSI sets information
> > + * @lock: lock protecting IRQ bit map
> > + * @msi_irq_in_use: bit map for assigned MSI IRQ
> >   */
> >  struct mtk_pcie_port {
> > struct device *dev;
> > @@ -100,6 +133,11 @@ struct mtk_pcie_port {
> > int irq;
> > raw_spinlock_t irq_lock;
> > struct irq_domain *intx_domain;
> > +   struct irq_domain *msi_domain;
> > +   struct irq_domain *msi_bottom_domain;
> > +   struct mtk_msi_set msi_sets[PCIE_MSI_SET_NUM];
> > +   struct mutex lock;
> > +   DECLARE_BITMAP(msi_irq_in_use, PCIE_MSI_IRQS_NUM);
> >  };
> >  
> >  /**
> > @@ -197,6 +235,35 @@ static int mtk_pcie_set_trans_table(struct 
> > mtk_pcie_port *port,
> > return 0;
> >  }
> >  
> > +static void mtk_pcie_enable_msi(struct mtk_pcie_port *port)
> > +{
> > +   int i;
> > +   u32 val;
> > +
> > +   val = readl_relaxed(port->base + PCIE_MSI_SET_ENABLE_REG);
> > +   val |= PCIE_MSI_SET_ENABLE;
> > +   writel_relaxed(val, port->base + 

Re: [PATCH 9/9] zsmalloc: remove the zsmalloc file system

[Minchan Kim]

On Tue, Mar 09, 2021 at 04:53:48PM +0100, Christoph Hellwig wrote:
> Just use the generic anon_inode file system.
> 
> Signed-off-by: Christoph Hellwig 
Acked-by: Minchan Kim 

[PATCH] powerpc: fix warning comparing pointer to 0

[Jiapeng Chong]

Fix the following coccicheck warning:

./arch/powerpc/platforms/powermac/pfunc_core.c:688:40-41: WARNING
comparing pointer to 0.

Reported-by: Abaci Robot 
Signed-off-by: Jiapeng Chong 
---
 arch/powerpc/platforms/powermac/pfunc_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/powermac/pfunc_core.c 
b/arch/powerpc/platforms/powermac/pfunc_core.c
index 94df0a9..a5aa40f 100644
--- a/arch/powerpc/platforms/powermac/pfunc_core.c
+++ b/arch/powerpc/platforms/powermac/pfunc_core.c
@@ -685,7 +685,7 @@ static int pmf_add_functions(struct pmf_device *dev, void 
*driverdata)
const int plen = strlen(PP_PREFIX);
int count = 0;
 
-   for (pp = dev->node->properties; pp != 0; pp = pp->next) {
+   for (pp = dev->node->properties; pp; pp = pp->next) {
const char *name;
if (strncmp(pp->name, PP_PREFIX, plen) != 0)
continue;
-- 
1.8.3.1

Re: [PATCH 8/9] vfio/pci: export nvlink2 support into vendor vfio_pci drivers

[Alexey Kardashevskiy]

On 09/03/2021 19:33, Max Gurtovoy wrote:

The new drivers introduced are nvlink2gpu_vfio_pci.ko and
npu2_vfio_pci.ko.
The first will be responsible for providing special extensions for
NVIDIA GPUs with NVLINK2 support for P9 platform (and others in the
future). The last will be responsible for POWER9 NPU2 unit (NVLink2 host
bus adapter).

Also, preserve backward compatibility for users that were binding
NVLINK2 devices to vfio_pci.ko. Hopefully this compatibility layer will
be dropped in the future

Signed-off-by: Max Gurtovoy 
---
  drivers/vfio/pci/Kconfig  |  28 +++-
  drivers/vfio/pci/Makefile |   7 +-
  .../pci/{vfio_pci_npu2.c => npu2_vfio_pci.c}  | 144 -
  drivers/vfio/pci/npu2_vfio_pci.h  |  24 +++
  ...pci_nvlink2gpu.c => nvlink2gpu_vfio_pci.c} | 149 +-
  drivers/vfio/pci/nvlink2gpu_vfio_pci.h|  24 +++
  drivers/vfio/pci/vfio_pci.c   |  61 ++-
  drivers/vfio/pci/vfio_pci_core.c  |  18 ---
  drivers/vfio/pci/vfio_pci_core.h  |  14 --
  9 files changed, 422 insertions(+), 47 deletions(-)
  rename drivers/vfio/pci/{vfio_pci_npu2.c => npu2_vfio_pci.c} (64%)
  create mode 100644 drivers/vfio/pci/npu2_vfio_pci.h
  rename drivers/vfio/pci/{vfio_pci_nvlink2gpu.c => nvlink2gpu_vfio_pci.c} (67%)
  create mode 100644 drivers/vfio/pci/nvlink2gpu_vfio_pci.h

diff --git a/drivers/vfio/pci/Kconfig b/drivers/vfio/pci/Kconfig
index 829e90a2e5a3..88c89863a205 100644
--- a/drivers/vfio/pci/Kconfig
+++ b/drivers/vfio/pci/Kconfig
@@ -48,8 +48,30 @@ config VFIO_PCI_IGD
  
  	  To enable Intel IGD assignment through vfio-pci, say Y.
  
-config VFIO_PCI_NVLINK2

-   def_bool y
+config VFIO_PCI_NVLINK2GPU
+   tristate "VFIO support for NVIDIA NVLINK2 GPUs"
depends on VFIO_PCI_CORE && PPC_POWERNV
help
- VFIO PCI support for P9 Witherspoon machine with NVIDIA V100 GPUs
+ VFIO PCI driver for NVIDIA NVLINK2 GPUs with specific extensions
+ for P9 Witherspoon machine.
+
+config VFIO_PCI_NPU2
+   tristate "VFIO support for IBM NPU host bus adapter on P9"
+   depends on VFIO_PCI_NVLINK2GPU && PPC_POWERNV
+   help
+ VFIO PCI specific extensions for IBM NVLink2 host bus adapter on P9
+ Witherspoon machine.
+
+config VFIO_PCI_DRIVER_COMPAT
+   bool "VFIO PCI backward compatibility for vendor specific extensions"
+   default y
+   depends on VFIO_PCI
+   help
+ Say Y here if you want to preserve VFIO PCI backward
+ compatibility. vfio_pci.ko will continue to automatically use
+ the NVLINK2, NPU2 and IGD VFIO drivers when it is attached to
+ a compatible device.
+
+ When N is selected the user must bind explicity to the module
+ they want to handle the device and vfio_pci.ko will have no
+ device specific special behaviors.
diff --git a/drivers/vfio/pci/Makefile b/drivers/vfio/pci/Makefile
index f539f32c9296..86fb62e271fc 100644
--- a/drivers/vfio/pci/Makefile
+++ b/drivers/vfio/pci/Makefile
@@ -2,10 +2,15 @@
  
  obj-$(CONFIG_VFIO_PCI_CORE) += vfio-pci-core.o

  obj-$(CONFIG_VFIO_PCI) += vfio-pci.o
+obj-$(CONFIG_VFIO_PCI_NPU2) += npu2-vfio-pci.o
+obj-$(CONFIG_VFIO_PCI_NVLINK2GPU) += nvlink2gpu-vfio-pci.o
  
  vfio-pci-core-y := vfio_pci_core.o vfio_pci_intrs.o vfio_pci_rdwr.o vfio_pci_config.o

  vfio-pci-core-$(CONFIG_VFIO_PCI_IGD) += vfio_pci_igd.o
-vfio-pci-core-$(CONFIG_VFIO_PCI_NVLINK2) += vfio_pci_nvlink2gpu.o 
vfio_pci_npu2.o
  vfio-pci-core-$(CONFIG_S390) += vfio_pci_zdev.o
  
  vfio-pci-y := vfio_pci.o

+
+npu2-vfio-pci-y := npu2_vfio_pci.o
+
+nvlink2gpu-vfio-pci-y := nvlink2gpu_vfio_pci.o
diff --git a/drivers/vfio/pci/vfio_pci_npu2.c b/drivers/vfio/pci/npu2_vfio_pci.c
similarity index 64%
rename from drivers/vfio/pci/vfio_pci_npu2.c
rename to drivers/vfio/pci/npu2_vfio_pci.c
index 717745256ab3..7071bda0f2b6 100644
--- a/drivers/vfio/pci/vfio_pci_npu2.c
+++ b/drivers/vfio/pci/npu2_vfio_pci.c
@@ -14,19 +14,28 @@
   *Author: Alex Williamson 
   */
  
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

+
+#include 
  #include 
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
  
  #include "vfio_pci_core.h"

+#include "npu2_vfio_pci.h"
  
  #define CREATE_TRACE_POINTS

  #include "npu2_trace.h"
  
+#define DRIVER_VERSION  "0.1"

+#define DRIVER_AUTHOR   "Alexey Kardashevskiy "
+#define DRIVER_DESC "NPU2 VFIO PCI - User Level meta-driver for POWER9 NPU 
NVLink2 HBA"
+
  EXPORT_TRACEPOINT_SYMBOL_GPL(vfio_pci_npu2_mmap);
  
  struct vfio_pci_npu2_data {

@@ -36,6 +45,10 @@ struct vfio_pci_npu2_data {
unsigned int link_speed; /* The link speed from DT's ibm,nvlink-speed */
  };
  
+struct npu2_vfio_pci_device {

+   struct vfio_pci_core_device vdev;
+};
+
  static size_t vfio_pci_npu2_rw(struct vfio_pci_core_device *vdev,
char __user *buf, size_t count, loff_t *ppos, bool iswrite)
  

Re: [PATCH 1/9] fs: rename alloc_anon_inode to alloc_anon_inode_sb

[Minchan Kim]

On Tue, Mar 09, 2021 at 04:53:40PM +0100, Christoph Hellwig wrote:
> Rename alloc_inode to free the name for a new variant that does not
> need boilerplate to create a super_block first.
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  arch/powerpc/platforms/pseries/cmm.c | 2 +-
>  drivers/dma-buf/dma-buf.c| 2 +-
>  drivers/gpu/drm/drm_drv.c| 2 +-
>  drivers/misc/cxl/api.c   | 2 +-
>  drivers/misc/vmw_balloon.c   | 2 +-
>  drivers/scsi/cxlflash/ocxl_hw.c  | 2 +-
>  drivers/virtio/virtio_balloon.c  | 2 +-
>  fs/aio.c | 2 +-
>  fs/anon_inodes.c | 4 ++--
>  fs/libfs.c   | 2 +-
>  include/linux/fs.h   | 2 +-
>  kernel/resource.c| 2 +-
>  mm/z3fold.c  | 2 +-
>  mm/zsmalloc.c| 2 +-
>  14 files changed, 15 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/pseries/cmm.c 
> b/arch/powerpc/platforms/pseries/cmm.c
> index 45a3a3022a85c9..6d36b858b14df1 100644
> --- a/arch/powerpc/platforms/pseries/cmm.c
> +++ b/arch/powerpc/platforms/pseries/cmm.c
> @@ -580,7 +580,7 @@ static int cmm_balloon_compaction_init(void)
>   return rc;
>   }
>  
> - b_dev_info.inode = alloc_anon_inode(balloon_mnt->mnt_sb);
> + b_dev_info.inode = alloc_anon_inode_sb(balloon_mnt->mnt_sb);
>   if (IS_ERR(b_dev_info.inode)) {
>   rc = PTR_ERR(b_dev_info.inode);
>   b_dev_info.inode = NULL;
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index f264b70c383eb4..dedcc9483352dc 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -445,7 +445,7 @@ static inline int is_dma_buf_file(struct file *file)
>  static struct file *dma_buf_getfile(struct dma_buf *dmabuf, int flags)
>  {
>   struct file *file;
> - struct inode *inode = alloc_anon_inode(dma_buf_mnt->mnt_sb);
> + struct inode *inode = alloc_anon_inode_sb(dma_buf_mnt->mnt_sb);
>  
>   if (IS_ERR(inode))
>   return ERR_CAST(inode);
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 20d22e41d7ce74..87e7214a8e3565 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -519,7 +519,7 @@ static struct inode *drm_fs_inode_new(void)
>   return ERR_PTR(r);
>   }
>  
> - inode = alloc_anon_inode(drm_fs_mnt->mnt_sb);
> + inode = alloc_anon_inode_sb(drm_fs_mnt->mnt_sb);
>   if (IS_ERR(inode))
>   simple_release_fs(_fs_mnt, _fs_cnt);
>  
> diff --git a/drivers/misc/cxl/api.c b/drivers/misc/cxl/api.c
> index b493de962153ba..2efbf6c98028ef 100644
> --- a/drivers/misc/cxl/api.c
> +++ b/drivers/misc/cxl/api.c
> @@ -73,7 +73,7 @@ static struct file *cxl_getfile(const char *name,
>   goto err_module;
>   }
>  
> - inode = alloc_anon_inode(cxl_vfs_mount->mnt_sb);
> + inode = alloc_anon_inode_sb(cxl_vfs_mount->mnt_sb);
>   if (IS_ERR(inode)) {
>   file = ERR_CAST(inode);
>   goto err_fs;
> diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c
> index b837e7eba5f7dc..5d057a05ddbee8 100644
> --- a/drivers/misc/vmw_balloon.c
> +++ b/drivers/misc/vmw_balloon.c
> @@ -1900,7 +1900,7 @@ static __init int vmballoon_compaction_init(struct 
> vmballoon *b)
>   return PTR_ERR(vmballoon_mnt);
>  
>   b->b_dev_info.migratepage = vmballoon_migratepage;
> - b->b_dev_info.inode = alloc_anon_inode(vmballoon_mnt->mnt_sb);
> + b->b_dev_info.inode = alloc_anon_inode_sb(vmballoon_mnt->mnt_sb);
>  
>   if (IS_ERR(b->b_dev_info.inode))
>   return PTR_ERR(b->b_dev_info.inode);
> diff --git a/drivers/scsi/cxlflash/ocxl_hw.c b/drivers/scsi/cxlflash/ocxl_hw.c
> index 244fc27215dc79..40184ed926b557 100644
> --- a/drivers/scsi/cxlflash/ocxl_hw.c
> +++ b/drivers/scsi/cxlflash/ocxl_hw.c
> @@ -88,7 +88,7 @@ static struct file *ocxlflash_getfile(struct device *dev, 
> const char *name,
>   goto err2;
>   }
>  
> - inode = alloc_anon_inode(ocxlflash_vfs_mount->mnt_sb);
> + inode = alloc_anon_inode_sb(ocxlflash_vfs_mount->mnt_sb);
>   if (IS_ERR(inode)) {
>   rc = PTR_ERR(inode);
>   dev_err(dev, "%s: alloc_anon_inode failed rc=%d\n",
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index 8985fc2cea8615..cae76ee5bdd688 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -916,7 +916,7 @@ static int virtballoon_probe(struct virtio_device *vdev)
>   }
>  
>   vb->vb_dev_info.migratepage = virtballoon_migratepage;
> - vb->vb_dev_info.inode = alloc_anon_inode(balloon_mnt->mnt_sb);
> + vb->vb_dev_info.inode = alloc_anon_inode_sb(balloon_mnt->mnt_sb);
>   if (IS_ERR(vb->vb_dev_info.inode)) {
>   err = PTR_ERR(vb->vb_dev_info.inode);
>   goto 

[PATCH v10 1/4] dt-bindings: mediatek: Add smi dts binding for Mediatek MT6765 SoC

[Macpaul Lin]

From: Mars Cheng 

This patch adds MT6765 smi binding document

Signed-off-by: Mars Cheng 
Signed-off-by: Owen Chen 
Signed-off-by: Macpaul Lin 
Acked-by: Rob Herring 
---
 .../bindings/memory-controllers/mediatek,smi-common.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml 
b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
index a08a32340987..4a4f4377576f 100644
--- 
a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
+++ 
b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml
@@ -31,6 +31,7 @@ properties:
   - enum:
   - mediatek,mt2701-smi-common
   - mediatek,mt2712-smi-common
+  - mediatek,mt6765-smi-common
   - mediatek,mt6779-smi-common
   - mediatek,mt8167-smi-common
   - mediatek,mt8173-smi-common
-- 
2.18.0

[PATCH v10 0/4] Add basic SoC support for mt6765

[Macpaul Lin]

This patch adds basic SoC support for Mediatek's new 8-core SoC,
MT6765, which is mainly for smartphone application.

Changes in V10:
   [v10,1/4] dt-bindings: mediatek: Add smi dts binding for Mediatek
MT6765 SoC
 - No Change.
   [v10,2/4] soc: mediatek: add MT6765 scpsys and subdomain support
 - No Change.
   [v10,3/4] arm64: dts: mediatek: add mt6765 support
 - Remove interrupt in mmsys node.
 - Replace smi_common@14002000 to smi@14002000
   [v10,4/4] arm64: defconfig: add CONFIG_COMMON_CLK_MT6765_XXX clocks
 - No Change.

Changes in V9:
1. Origin V8 patchset:
   https://patchwork.kernel.org/cover/11396015/
   [v9,1/4] dt-bindings: mediatek: Add smi dts binding for Mediatek
MT6765 SoC
 - No Change.
   [v9,2/4] soc: mediatek: add MT6765 scpsys and subdomain support
 - Fix build error based on 5.11-rc1 because
   - bp_table has been deprecated.
   - basic_clk_id has been renamed to clk_id.
   - correct the number order in marco GENMASK().
   Note: mediatek is working on porting mt6765's scpsys to driver
 "mtk-pm-domains", however we think supporting for "mtk-scpsys" is
 required before new glue is available.
   [v9,3/4] arm64: dts: mediatek: add mt6765 support
 - No Change.
   [v9,4/4] arm64: defconfig: add CONFIG_COMMON_CLK_MT6765_XXX clocks
 - No Change.

Changes in V8:
1. Origin V7 patchset:
   https://patchwork.kernel.org/cover/11370105/
   Split origin V7 patchset into 2 patchset,
   keep remain patches #2, #5, #6, and #7 in the same order as this
   V8 patchset.
   [v7,2/7] dt-bindings: mediatek: Add smi dts binding for Mediatek
MT6765 SoC
   [v7,5/7] soc: mediatek: add MT6765 scpsys and subdomain support
   [v7,6/7] arm64: dts: mediatek: add mt6765 support
   [v7,7/7] arm64: defconfig: add CONFIG_COMMON_CLK_MT6765_XXX clocks

Changes in V7:
1. Adapt V6's patchset to latest kernel tree 5.5-rc1.
   Origin V6 patchset:
   https://patchwork.kernel.org/cover/11041963/
2. Correct 2 clock-controller type in documentation:
   mipi0 and venc_gcon.
   [v7 1/7] dt-bindings: clock: mediatek: document clk bindings
3. Remove V6's patch 03 because it has been taken into 5.5-next-soc
   [v6, 03/08] dt-bindings: mediatek: add MT6765 power dt-bindings
3. Update Reviewed-by: Rob Herring  for
   [v6, 04/08] clk: mediatek: add mt6765 clock IDs
   --> [v7, 03/07] clk: mediatek: add mt6765 clock IDs
4. Update SPDX tag for
   [v6, 05/08] clk: mediatek: Add MT6765 clock support
   --> [v7, 04/07] clk: mediatek: Add MT6765 clock support

Changes in V6:
1. Adapt V5's patchset to latest kernel tree.
   Origin V5 patchset.
   https://lore.kernel.org/patchwork/cover/963612/
2. Due to clk's common code has been submit by other platform,
   this patch set will have dependencies with the following patchsets
   as the following orders.
   2.a. [v8,00/21] MT8183 IOMMU SUPPORT
https://patchwork.kernel.org/cover/11023585/
   2.b. [v11,0/6] Add basic node support for Mediatek MT8183 SoC
https://patchwork.kernel.org/cover/10962385/
   2.c. [v6,00/14] Mediatek MT8183 scpsys support
https://patchwork.kernel.org/cover/11005751/
3. Correct power related patches into dt-binding patches.
4. Re-order V5's 4/11, 6/11, and 7/11 due clk common code change
   and make dependencies in order.
5. Update some commit message in clk related patches.

Changes in V5:
1. add clk support

Changes in V4:
1. add gic's settings in reg properties
2. remove some patches about dt-bindings since GKH already took them

Changes in V3:
1. split dt-binding document patchs
2. fix mt6765.dtsi warnings with W=12
3. remove uncessary PPI affinity for timer
4. add gicc base for gic dt node

Changes in V2:
1. fix clk properties in uart dts node
2. fix typo in submit title
3. add simple-bus in mt6765.dtsi
4. use correct SPDX license format

Mars Cheng (3):
  dt-bindings: mediatek: Add smi dts binding for Mediatek MT6765 SoC
  soc: mediatek: add MT6765 scpsys and subdomain support
  arm64: dts: mediatek: add mt6765 support

Owen Chen (1):
  arm64: defconfig: add CONFIG_COMMON_CLK_MT6765_XXX clocks

 .../mediatek,smi-common.yaml  |   1 +
 arch/arm64/boot/dts/mediatek/Makefile |   1 +
 arch/arm64/boot/dts/mediatek/mt6765-evb.dts   |  33 +++
 arch/arm64/boot/dts/mediatek/mt6765.dtsi  | 252 ++
 arch/arm64/configs/defconfig  |   6 +
 drivers/soc/mediatek/mtk-scpsys.c |  91 +++
 6 files changed, 384 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt6765-evb.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt6765.dtsi

-- 
2.18.0

[PATCH v10 2/4] soc: mediatek: add MT6765 scpsys and subdomain support

[Macpaul Lin]

From: Mars Cheng 

This adds scpsys support for MT6765
Add subdomain support for MT6765:
isp, mm, connsys, mfg, and cam.

Signed-off-by: Mars Cheng 
Signed-off-by: Owen Chen 
Signed-off-by: Macpaul Lin 
---
 drivers/soc/mediatek/mtk-scpsys.c | 91 +++
 1 file changed, 91 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-scpsys.c 
b/drivers/soc/mediatek/mtk-scpsys.c
index ca75b14931ec..fc8d3858f1b4 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -15,6 +15,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -750,6 +751,81 @@ static const struct scp_subdomain scp_subdomain_mt2712[] = 
{
{MT2712_POWER_DOMAIN_MFG_SC2, MT2712_POWER_DOMAIN_MFG_SC3},
 };
 
+/*
+ * MT6765 power domain support
+ */
+#define SPM_PWR_STATUS_MT6765  0x0180
+#define SPM_PWR_STATUS_2ND_MT6765  0x0184
+
+static const struct scp_domain_data scp_domain_data_mt6765[] = {
+   [MT6765_POWER_DOMAIN_VCODEC] = {
+   .name = "vcodec",
+   .sta_mask = BIT(26),
+   .ctl_offs = 0x300,
+   .sram_pdn_bits = GENMASK(8, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   },
+   [MT6765_POWER_DOMAIN_ISP] = {
+   .name = "isp",
+   .sta_mask = BIT(5),
+   .ctl_offs = 0x308,
+   .sram_pdn_bits = GENMASK(8, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   },
+   [MT6765_POWER_DOMAIN_MM] = {
+   .name = "mm",
+   .sta_mask = BIT(3),
+   .ctl_offs = 0x30C,
+   .sram_pdn_bits = GENMASK(8, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   .clk_id = {CLK_MM},
+   },
+   [MT6765_POWER_DOMAIN_CONN] = {
+   .name = "conn",
+   .sta_mask = BIT(1),
+   .ctl_offs = 0x32C,
+   .sram_pdn_bits = 0,
+   .sram_pdn_ack_bits = 0,
+   },
+   [MT6765_POWER_DOMAIN_MFG_ASYNC] = {
+   .name = "mfg_async",
+   .sta_mask = BIT(23),
+   .ctl_offs = 0x334,
+   .sram_pdn_bits = 0,
+   .sram_pdn_ack_bits = 0,
+   .clk_id = {CLK_MFG},
+   },
+   [MT6765_POWER_DOMAIN_MFG] = {
+   .name = "mfg",
+   .sta_mask = BIT(4),
+   .ctl_offs = 0x338,
+   .sram_pdn_bits = GENMASK(8, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   },
+   [MT6765_POWER_DOMAIN_CAM] = {
+   .name = "cam",
+   .sta_mask = BIT(25),
+   .ctl_offs = 0x344,
+   .sram_pdn_bits = GENMASK(9, 8),
+   .sram_pdn_ack_bits = GENMASK(13, 12),
+   },
+   [MT6765_POWER_DOMAIN_MFG_CORE0] = {
+   .name = "mfg_core0",
+   .sta_mask = BIT(7),
+   .ctl_offs = 0x34C,
+   .sram_pdn_bits = GENMASK(8, 8),
+   .sram_pdn_ack_bits = GENMASK(12, 12),
+   },
+};
+
+static const struct scp_subdomain scp_subdomain_mt6765[] = {
+   {MT6765_POWER_DOMAIN_MM, MT6765_POWER_DOMAIN_CAM},
+   {MT6765_POWER_DOMAIN_MM, MT6765_POWER_DOMAIN_ISP},
+   {MT6765_POWER_DOMAIN_MM, MT6765_POWER_DOMAIN_VCODEC},
+   {MT6765_POWER_DOMAIN_MFG_ASYNC, MT6765_POWER_DOMAIN_MFG},
+   {MT6765_POWER_DOMAIN_MFG, MT6765_POWER_DOMAIN_MFG_CORE0},
+};
+
 /*
  * MT6797 power domain support
  */
@@ -1033,6 +1109,18 @@ static const struct scp_soc_data mt2712_data = {
.bus_prot_reg_update = false,
 };
 
+static const struct scp_soc_data mt6765_data = {
+   .domains = scp_domain_data_mt6765,
+   .num_domains = ARRAY_SIZE(scp_domain_data_mt6765),
+   .subdomains = scp_subdomain_mt6765,
+   .num_subdomains = ARRAY_SIZE(scp_subdomain_mt6765),
+   .regs = {
+   .pwr_sta_offs = SPM_PWR_STATUS_MT6765,
+   .pwr_sta2nd_offs = SPM_PWR_STATUS_2ND_MT6765,
+   },
+   .bus_prot_reg_update = true,
+};
+
 static const struct scp_soc_data mt6797_data = {
.domains = scp_domain_data_mt6797,
.num_domains = ARRAY_SIZE(scp_domain_data_mt6797),
@@ -1088,6 +1176,9 @@ static const struct of_device_id of_scpsys_match_tbl[] = {
}, {
.compatible = "mediatek,mt2712-scpsys",
.data = _data,
+   }, {
+   .compatible = "mediatek,mt6765-scpsys",
+   .data = _data,
}, {
.compatible = "mediatek,mt6797-scpsys",
.data = _data,
-- 
2.18.0

[PATCH v10 3/4] arm64: dts: mediatek: add mt6765 support

[Macpaul Lin]

From: Mars Cheng 

Add basic chip support for Mediatek 6765, include
uart node with correct uart clocks, pwrap device

Add clock controller nodes, include topckgen, infracfg,
apmixedsys and subsystem.

Signed-off-by: Mars Cheng 
Signed-off-by: Owen Chen 
Signed-off-by: Macpaul Lin 
Acked-by: Marc Zyngier 
---
 arch/arm64/boot/dts/mediatek/Makefile   |   1 +
 arch/arm64/boot/dts/mediatek/mt6765-evb.dts |  33 +++
 arch/arm64/boot/dts/mediatek/mt6765.dtsi| 252 
 3 files changed, 286 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt6765-evb.dts
 create mode 100644 arch/arm64/boot/dts/mediatek/mt6765.dtsi

diff --git a/arch/arm64/boot/dts/mediatek/Makefile 
b/arch/arm64/boot/dts/mediatek/Makefile
index deba27ab7657..176c817f9f9a 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt2712-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt6755-evb.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt6765-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt6779-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt6795-evb.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-evb.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt6765-evb.dts 
b/arch/arm64/boot/dts/mediatek/mt6765-evb.dts
new file mode 100644
index ..36dddff2b7f8
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt6765-evb.dts
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * dts file for Mediatek MT6765
+ *
+ * (C) Copyright 2018. Mediatek, Inc.
+ *
+ * Mars Cheng 
+ */
+
+/dts-v1/;
+#include "mt6765.dtsi"
+
+/ {
+   model = "MediaTek MT6765 EVB";
+   compatible = "mediatek,mt6765-evb", "mediatek,mt6765";
+
+   aliases {
+   serial0 = 
+   };
+
+   memory@4000 {
+   device_type = "memory";
+   reg = <0 0x4000 0 0x1e80>;
+   };
+
+   chosen {
+   stdout-path = "serial0:921600n8";
+   };
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt6765.dtsi 
b/arch/arm64/boot/dts/mediatek/mt6765.dtsi
new file mode 100644
index ..21683f3e1a3f
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt6765.dtsi
@@ -0,0 +1,252 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * dts file for Mediatek MT6765
+ *
+ * (C) Copyright 2018. Mediatek, Inc.
+ *
+ * Mars Cheng 
+ */
+
+#include 
+#include 
+#include 
+
+/ {
+   compatible = "mediatek,mt6765";
+   interrupt-parent = <>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   psci {
+   compatible = "arm,psci-0.2";
+   method = "smc";
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x000>;
+   };
+
+   cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x001>;
+   };
+
+   cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x002>;
+   };
+
+   cpu@3 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x003>;
+   };
+
+   cpu@100 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x100>;
+   };
+
+   cpu@101 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x101>;
+   };
+
+   cpu@102 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x102>;
+   };
+
+   cpu@103 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53";
+   enable-method = "psci";
+   reg = <0x103>;
+   };
+   };
+
+   clocks {
+   clk26m: clk26m {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2600>;
+   };
+
+   clk32k: clk32k {
+   compatible = "fixed-clock";
+   #clock-cells 

[PATCH v10 4/4] arm64: defconfig: add CONFIG_COMMON_CLK_MT6765_XXX clocks

[Macpaul Lin]

From: Owen Chen 

Enable MT6765 clock configs, include topckgen, apmixedsys,
infracfg, and subsystem clocks.

Signed-off-by: Owen Chen 
Signed-off-by: Macpaul Lin 
---
 arch/arm64/configs/defconfig | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index d612f633b771..553137e81b8e 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -622,6 +622,12 @@ CONFIG_REGULATOR_RK808=y
 CONFIG_REGULATOR_S2MPS11=y
 CONFIG_REGULATOR_TPS65132=m
 CONFIG_REGULATOR_VCTRL=m
+CONFIG_COMMON_CLK_MT6765_AUDIOSYS=y
+CONFIG_COMMON_CLK_MT6765_CAMSYS=y
+CONFIG_COMMON_CLK_MT6765_MMSYS=y
+CONFIG_COMMON_CLK_MT6765_IMGSYS=y
+CONFIG_COMMON_CLK_MT6765_VCODECSYS=y
+CONFIG_COMMON_CLK_MT6765_MIPI0ASYS=y
 CONFIG_RC_CORE=m
 CONFIG_RC_DECODERS=y
 CONFIG_RC_DEVICES=y
-- 
2.18.0

Re: [RFC PATCH v2 1/6] iommu: Evolve to support more scenarios of using IOPF

[Shenming Lu]

Hi Baolu,

On 2021/3/10 10:09, Lu Baolu wrote:
> Hi Shenming,
> 
> On 3/9/21 2:22 PM, Shenming Lu wrote:
>> This patch follows the discussion here:
>>
>> https://lore.kernel.org/linux-acpi/YAaxjmJW+ZMvrhac@myrica/
>>
>> In order to support more scenarios of using IOPF (mainly consider
>> the nested extension), besides keeping IOMMU_DEV_FEAT_IOPF as a
>> general capability for whether delivering faults through the IOMMU,
>> we extend iommu_register_fault_handler() with flags and introduce
>> IOPF_REPORT_FLAT and IOPF_REPORT_NESTED to describe the page fault
>> reporting capability under a specific configuration.
>> IOPF_REPORT_NESTED needs additional info to indicate which level/stage
>> is concerned since the fault client may be interested in only one
>> level.
>>
>> Signed-off-by: Shenming Lu 
>> ---
>>   .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c   |  3 +-
>>   drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c   | 11 ++--
>>   drivers/iommu/io-pgfault.c    |  4 --
>>   drivers/iommu/iommu.c | 56 ++-
>>   include/linux/iommu.h | 21 ++-
>>   include/uapi/linux/iommu.h    |  3 +
>>   6 files changed, 85 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c 
>> b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
>> index ee66d1f4cb81..5de9432349d4 100644
>> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
>> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
>> @@ -482,7 +482,8 @@ static int arm_smmu_master_sva_enable_iopf(struct 
>> arm_smmu_master *master)
>>   if (ret)
>>   return ret;
>>   -    ret = iommu_register_device_fault_handler(dev, iommu_queue_iopf, dev);
>> +    ret = iommu_register_device_fault_handler(dev, iommu_queue_iopf,
>> +  IOPF_REPORT_FLAT, dev);
>>   if (ret) {
>>   iopf_queue_remove_device(master->smmu->evtq.iopf, dev);
>>   return ret;
>> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c 
>> b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
>> index 363744df8d51..f40529d0075d 100644
>> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
>> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
>> @@ -1447,10 +1447,6 @@ static int arm_smmu_handle_evt(struct arm_smmu_device 
>> *smmu, u64 *evt)
>>   return -EOPNOTSUPP;
>>   }
>>   -    /* Stage-2 is always pinned at the moment */
>> -    if (evt[1] & EVTQ_1_S2)
>> -    return -EFAULT;
>> -
>>   if (evt[1] & EVTQ_1_RnW)
>>   perm |= IOMMU_FAULT_PERM_READ;
>>   else
>> @@ -1468,13 +1464,18 @@ static int arm_smmu_handle_evt(struct 
>> arm_smmu_device *smmu, u64 *evt)
>>   .flags = IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE,
>>   .grpid = FIELD_GET(EVTQ_1_STAG, evt[1]),
>>   .perm = perm,
>> -    .addr = FIELD_GET(EVTQ_2_ADDR, evt[2]),
>>   };
>>     if (ssid_valid) {
>>   flt->prm.flags |= IOMMU_FAULT_PAGE_REQUEST_PASID_VALID;
>>   flt->prm.pasid = FIELD_GET(EVTQ_0_SSID, evt[0]);
>>   }
>> +
>> +    if (evt[1] & EVTQ_1_S2) {
>> +    flt->prm.flags |= IOMMU_FAULT_PAGE_REQUEST_L2;
>> +    flt->prm.addr = FIELD_GET(EVTQ_3_IPA, evt[3]);
>> +    } else
>> +    flt->prm.addr = FIELD_GET(EVTQ_2_ADDR, evt[2]);
>>   } else {
>>   flt->type = IOMMU_FAULT_DMA_UNRECOV;
>>   flt->event = (struct iommu_fault_unrecoverable) {
>> diff --git a/drivers/iommu/io-pgfault.c b/drivers/iommu/io-pgfault.c
>> index 1df8c1dcae77..abf16e06bcf5 100644
>> --- a/drivers/iommu/io-pgfault.c
>> +++ b/drivers/iommu/io-pgfault.c
>> @@ -195,10 +195,6 @@ int iommu_queue_iopf(struct iommu_fault *fault, void 
>> *cookie)
>>     lockdep_assert_held(>lock);
>>   -    if (fault->type != IOMMU_FAULT_PAGE_REQ)
>> -    /* Not a recoverable page fault */
>> -    return -EOPNOTSUPP;
>> -
> 
> Any reasons why do you want to remove this check?

My thought was to make the reporting cap more detailed: IOPF_REPORT_ is only 
for recoverable
page faults (IOMMU_FAULT_PAGE_REQ), and we may add UNRECOV_FAULT_REPORT_ later 
for unrecoverable
faults (IOMMU_FAULT_DMA_UNRECOV)...

> 
>>   /*
>>    * As long as we're holding param->lock, the queue can't be unlinked
>>    * from the device and therefore cannot disappear.
>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>> index d0b0a15dba84..cb1d93b00f7d 100644
>> --- a/drivers/iommu/iommu.c
>> +++ b/drivers/iommu/iommu.c
>> @@ -1056,6 +1056,40 @@ int iommu_group_unregister_notifier(struct 
>> iommu_group *group,
>>   }
>>   EXPORT_SYMBOL_GPL(iommu_group_unregister_notifier);
>>   +/*
>> + * iommu_update_device_fault_handler - Update the device fault handler via 
>> flags
>> + * @dev: the device
>> + * @mask: bits(not set) to clear
>> + * @set: bits to set
>> + *
>> + * Update the device fault handler installed by
>> + * 

Re: [PATCH v3 05/15] dt_bindings: mfd: Add ROHM BD71815 PMIC

[Matti Vaittinen]

Hello Rob,

(I dropped other personal mails from CC - kept only the lists)

On Tue, 2021-03-09 at 08:11 -0700, Rob Herring wrote:
> On Tue, Mar 9, 2021 at 5:51 AM Matti Vaittinen
>  wrote:
> > Hello Rob,
> > 
> > On Mon, 2021-03-08 at 10:39 -0700, Rob Herring wrote:
> > > On Mon, 08 Mar 2021 12:40:50 +0200, Matti Vaittinen wrote:
> > > > 
> > > dtschema/dtc warnings/errors:
> > > Unknown file referenced: [Errno 2] No such file or directory:
> > > '/usr/local/lib/python3.8/dist-
> > > packages/dtschema/schemas/regulator/rohm,bd71815-regulator.yaml'
> > 
> > This bothers me slightly. The patch 04/15 should bring-in the
> > rohm,bd71815-regulator.yaml. Does this error indicate that file is
> > missing or is my $ref somehow invalid?
> 
> Then it's simply a false positive. I usually check these and try to
> only send the email if the dependency is not in the series so the
> dependency is clear. It's a balance of replying quickly and my time
> reviewing the errors.

Oh, good to know. I was assuming I got it wrong once again... Thanks!

Rest of the mail is further discussion why I wonder if yaml bindings
are worth it - you can skip it if you're not in a mood for babbling ;)

Best Regards
Matti

> > *** opinion follows - not sure if it just me but... ***
> > 
> > I know I should probably keep my mouth shut but... I am more and
> > more
> > thinking that the yaml bindings are yet another 'excessive unit-
> > test'
> > type solution. Tooling which should "force doing things correctly"
> > is
> > eventually hindering development and causing the end result being
> > sub-
> > optimal.
> 
> It's about validating DTS files actually do what the bindings say.
> It's pretty clear that the free form text bindings left a lot of
> things ambiguous.
> 
> How would you propose we can check every property in a DTS file has a
> definition (minimally of it's type)? Freeform text can simply never
> do
> that.

True. But I am not at all sure that the benefit of verifying the .dts
files programmatically exceeds cost (work + lost readability for humans
+ impact of increased "not that fun" work). Anyways, as I wrote - this
is just my biased opinion. Other people may have different opinions :]

> > I mean that creating binding docs takes way too much time from
> > someone
> > like me who is "yaml-illiterate". And when I eventually get yaml
> > done -
> > the end result is far less descriptive for human eyes than the
> > "good
> > old" free-text format would've been. I know one can add comments -
> > but
> > I don't see much of them in the binding docs...
> 
> Because people do the minimum?

I know. This is the very basic nature of most human beings. I think
this must be accepted. And likelihood for doing bare minimum sky-
rockets when people feel the work they do is dull/boring/not fun. And I
just have a feeling that many who enjoy writing drivers find writing
the yaml bindings quite not fun. (I have absolutely no statistics to
back up this statement - it's just a feeling).

Big question is how to get best results in this not-so-perfect world
when we know that people are both lazy and make mistakes?

I have kind of deja-vu here. I've seen many attempts of tightening
mechanical checks to get rid of human errors. In my opinion it rarely
works well. To pick few I've seen:

- demand for 100 % UT test coverage.
=> lazy people started to avoid code changes
=> autogenerated test cases which assumed current code was
   correct and brought no value but incredible inertia to all 
   changes.
- demand for heavy(ish) RCA/EDA process when severe faults were fixed
=> lazy people started to mark severe faults as minor
- demand for peculiar, hard to remember syntax for commit messages to
automatically fill in different statistics/management data
=> lazy people started to commit all changes in same category
   (syntax they had memorized/had alias for).
- demand for DT docs which can be verified
=> ... ?

Common thing is that all of these have valid, good intention - but
overhead of doing them exceeded the (visible) benefits and lazy people
tried to get around of them / did bare minimum. And as a side impact -
part of the work got more boring - which also has (bad) consequences.

I am not surprized if people try skipping creating DT docs. Or if the
people do bare minimum with the DT docs.

>  The only comments/description I object
> to are duplicating generic descriptions of common properties.

I know. And I don't think you are to blame here.

> There's certainly lots of things we could do. There are tools which
> generate pretty docs out of json-schema. Not sure how useful they
> would be OOTB. But I simply don't have the bandwidth to look into
> them. I can barely keep up with reviews...

Yes. I understand this. And now I am just taking more of that time -
sorry. I just gave an opinion (knowing it probably won't change
anything - but at least I've told what I am afraid of).

Thanks 

Re: [PATCH v3 01/14] mm/mempolicy: Add comment for missing LOCAL

[Feng Tang]

On Wed, Mar 03, 2021 at 06:20:45PM +0800, Feng Tang wrote:
> From: Ben Widawsky 
> 
> MPOL_LOCAL is a bit weird because it is simply a different name for an
> existing behavior (preferred policy with no node mask). It has been this
> way since it was added here:
> commit 479e2802d09f ("mm: mempolicy: Make MPOL_LOCAL a real policy")
> 
> It is so similar to MPOL_PREFERRED in fact that when the policy is
> created in mpol_new, the mode is set as PREFERRED, and an internal state
> representing LOCAL doesn't exist.
> 
> To prevent future explorers from scratching their head as to why
> MPOL_LOCAL isn't defined in the mpol_ops table, add a small comment
> explaining the situations.
> 
> v2:
> Change comment to refer to mpol_new (Michal)
> 
> Link: https://lore.kernel.org/r/20200630212517.308045-2-ben.widaw...@intel.com
> #Acked-by: Michal Hocko 

This shouldn't be masked:

Acked-by: Michal Hocko 

I did the mask when sending for internal review, and forgot to restore
it, sorry for the noise.

Thanks,
Feng

> Signed-off-by: Ben Widawsky 
> Signed-off-by: Feng Tang 
> ---
>  mm/mempolicy.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
> index 2c3a865..5730fc1 100644
> --- a/mm/mempolicy.c
> +++ b/mm/mempolicy.c
> @@ -427,6 +427,7 @@ static const struct mempolicy_operations 
> mpol_ops[MPOL_MAX] = {
>   .create = mpol_new_bind,
>   .rebind = mpol_rebind_nodemask,
>   },
> + /* [MPOL_LOCAL] - see mpol_new() */
>  };
>  
>  static int migrate_page_add(struct page *page, struct list_head *pagelist,
> -- 
> 2.7.4

[PATCH] Insert SFENCE.VMA in function set_pte_at for RISCV

[Jiuyang]

From: Jiuyang Liu 

This patch inserts SFENCE.VMA after modifying PTE based on RISC-V
specification.

arch/riscv/include/asm/pgtable.h:
1. implement pte_user, pte_global and pte_leaf to check correspond
attribute of a pte_t.

2. insert SFENCE.VMA in set_pte_at based on RISC-V Volume 2, Privileged
Spec v. 20190608 page 66 and 67:
If software modifies a non-leaf PTE, it should execute SFENCE.VMA with
rs1=x0. If any PTE along the traversal path had its G bit set, rs2 must
be x0; otherwise, rs2 should be set to the ASID for which the
translation is being modified.
If software modifies a leaf PTE, it should execute SFENCE.VMA with rs1
set to a virtual address within the page. If any PTE along the traversal
path had its G bit set, rs2 must be x0; otherwise, rs2 should be set to
the ASID for which the translation is being modified.

arch/riscv/include/asm/tlbflush.h:
1. implement local_flush_tlb_asid to flush tlb with asid.

Signed-off-by: Jiuyang Liu 
---
 arch/riscv/include/asm/pgtable.h  | 28 
 arch/riscv/include/asm/tlbflush.h |  8 
 2 files changed, 36 insertions(+)

diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
index ebf817c1bdf4..95f6546ddb5b 100644
--- a/arch/riscv/include/asm/pgtable.h
+++ b/arch/riscv/include/asm/pgtable.h
@@ -222,6 +222,16 @@ static inline int pte_write(pte_t pte)
return pte_val(pte) & _PAGE_WRITE;
 }
 
+static inline int pte_user(pte_t pte)
+{
+   return pte_val(pte) & _PAGE_USER;
+}
+
+static inline int pte_global(pte_t pte)
+{
+   return pte_val(pte) & _PAGE_GLOBAL;
+}
+
 static inline int pte_exec(pte_t pte)
 {
return pte_val(pte) & _PAGE_EXEC;
@@ -248,6 +258,11 @@ static inline int pte_special(pte_t pte)
return pte_val(pte) & _PAGE_SPECIAL;
 }
 
+static inline int pte_leaf(pte_t pte)
+{
+   return pte_val(pte) & (_PAGE_READ | _PAGE_WRITE | _PAGE_EXEC);
+}
+
 /* static inline pte_t pte_rdprotect(pte_t pte) */
 
 static inline pte_t pte_wrprotect(pte_t pte)
@@ -358,6 +370,18 @@ static inline void set_pte_at(struct mm_struct *mm,
flush_icache_pte(pteval);
 
set_pte(ptep, pteval);
+
+   if (pte_present(pteval)) {
+   if (pte_leaf(pteval)) {
+   local_flush_tlb_page(addr);
+   } else {
+   if (pte_global(pteval))
+   local_flush_tlb_all();
+   else
+   local_flush_tlb_asid();
+
+   }
+   }
 }
 
 static inline void pte_clear(struct mm_struct *mm,
diff --git a/arch/riscv/include/asm/tlbflush.h 
b/arch/riscv/include/asm/tlbflush.h
index 394cfbccdcd9..4b25f51f163d 100644
--- a/arch/riscv/include/asm/tlbflush.h
+++ b/arch/riscv/include/asm/tlbflush.h
@@ -21,6 +21,14 @@ static inline void local_flush_tlb_page(unsigned long addr)
 {
__asm__ __volatile__ ("sfence.vma %0" : : "r" (addr) : "memory");
 }
+
+static unsigned long asid;
+static inline void local_flush_tlb_asid(void)
+{
+   asid = csr_read(CSR_SATP) | (SATP_ASID_MASK << SATP_ASID_SHIFT);
+   __asm__ __volatile__ ("sfence.vma x0, %0" : : "r" (asid) : "memory");
+}
+
 #else /* CONFIG_MMU */
 #define local_flush_tlb_all()  do { } while (0)
 #define local_flush_tlb_page(addr) do { } while (0)
-- 
2.30.1

Re: [PATCH] vfio/pci: make the vfio_pci_mmap_fault reentrant

[Alex Williamson]

On Tue, 9 Mar 2021 19:45:03 -0400
Jason Gunthorpe  wrote:

> On Tue, Mar 09, 2021 at 12:56:39PM -0700, Alex Williamson wrote:
> 
> > And I think this is what we end up with for the current code base:  
> 
> Yeah, that looks Ok
>  
> > diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> > index 65e7e6b44578..2f247ab18c66 100644
> > +++ b/drivers/vfio/pci/vfio_pci.c
> > @@ -1568,19 +1568,24 @@ void vfio_pci_memory_unlock_and_restore(struct 
> > vfio_pci_device *vdev, u16 cmd)
> >  }
> >  
> >  /* Caller holds vma_lock */
> > -static int __vfio_pci_add_vma(struct vfio_pci_device *vdev,
> > - struct vm_area_struct *vma)
> > +struct vfio_pci_mmap_vma *__vfio_pci_add_vma(struct vfio_pci_device *vdev,
> > +struct vm_area_struct *vma)
> >  {
> > struct vfio_pci_mmap_vma *mmap_vma;
> >  
> > +   list_for_each_entry(mmap_vma, >vma_list, vma_next) {
> > +   if (mmap_vma->vma == vma)
> > +   return ERR_PTR(-EEXIST);
> > +   }
> > +
> > mmap_vma = kmalloc(sizeof(*mmap_vma), GFP_KERNEL);
> > if (!mmap_vma)
> > -   return -ENOMEM;
> > +   return ERR_PTR(-ENOMEM);
> >  
> > mmap_vma->vma = vma;
> > list_add(_vma->vma_next, >vma_list);
> >  
> > -   return 0;
> > +   return mmap_vma;
> >  }
> >  
> >  /*
> > @@ -1612,30 +1617,39 @@ static vm_fault_t vfio_pci_mmap_fault(struct 
> > vm_fault *vmf)
> >  {
> > struct vm_area_struct *vma = vmf->vma;
> > struct vfio_pci_device *vdev = vma->vm_private_data;
> > -   vm_fault_t ret = VM_FAULT_NOPAGE;
> > +   struct vfio_pci_mmap_vma *mmap_vma;
> > +   unsigned long vaddr, pfn;
> > +   vm_fault_t ret;
> >  
> > mutex_lock(>vma_lock);
> > down_read(>memory_lock);
> >  
> > if (!__vfio_pci_memory_enabled(vdev)) {
> > ret = VM_FAULT_SIGBUS;
> > -   mutex_unlock(>vma_lock);
> > goto up_out;
> > }
> >  
> > -   if (__vfio_pci_add_vma(vdev, vma)) {
> > -   ret = VM_FAULT_OOM;
> > -   mutex_unlock(>vma_lock);
> > +   mmap_vma = __vfio_pci_add_vma(vdev, vma);
> > +   if (IS_ERR(mmap_vma)) {
> > +   /* A concurrent fault might have already inserted the page */
> > +   ret = (PTR_ERR(mmap_vma) == -EEXIST) ? VM_FAULT_NOPAGE :
> > +  VM_FAULT_OOM;  
> 
> I think -EEIXST should not be an error, lets just go down to the
> vmf_insert_pfn() and let the MM resolve the race naturally.
> 
> I suspect returning VM_FAULT_NOPAGE will be averse to the userspace if
> it hits this race??

Given the serialization on vma_lock, if the vma_list entry exists then
the full vma should already be populated, so I don't see the NOPAGE
issue you're worried about.  However, if we wanted to be more similar
to what we expect the new version to do, we could proceed through
re-inserting the pages on -EEXIST.  Zeng Tao's re-ordering to add the
vma_list entry only after successfully inserting all the pfns might work
better for that.
 
> Also the _prot does look needed at least due to the SME, but possibly
> also to ensure NC gets set..

If we need more than pgprot_decrypted(vma->vm_page_prot), please let us
know, but that's all we were getting from io_remap_pfn_range() afaict.
Thanks,

Alex

[PATCH] selftests/bpf: fix warning comparing pointer to 0

[Jiapeng Chong]

Fix the following coccicheck warning:

./tools/testing/selftests/bpf/progs/test_global_func10.c:17:12-13:
WARNING comparing pointer to 0.

Reported-by: Abaci Robot 
Signed-off-by: Jiapeng Chong 
---
 tools/testing/selftests/bpf/progs/test_global_func10.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/bpf/progs/test_global_func10.c 
b/tools/testing/selftests/bpf/progs/test_global_func10.c
index 61c2ae9..97b7031 100644
--- a/tools/testing/selftests/bpf/progs/test_global_func10.c
+++ b/tools/testing/selftests/bpf/progs/test_global_func10.c
@@ -14,7 +14,7 @@ struct Big {
 
 __noinline int foo(const struct Big *big)
 {
-   if (big == 0)
+   if (!big)
return 0;
 
return bpf_get_prandom_u32() < big->y;
-- 
1.8.3.1

Re: [PATCH v5] printk: Userspace format enumeration support

[kernel test robot]

Hi Chris,

I love your patch! Yet something to improve:

[auto build test ERROR on jeyu/modules-next]
[also build test ERROR on linux/master soc/for-next openrisc/for-next 
powerpc/next uml/linux-next tip/x86/core asm-generic/master linus/master 
v5.12-rc2]
[cannot apply to pmladek/for-next next-20210310]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Chris-Down/printk-Userspace-format-enumeration-support/20210310-103231
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux.git 
modules-next
config: openrisc-randconfig-r022-20210308 (attached as .config)
compiler: or1k-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/097254e932767fc7d5ba0243a83265017d427d74
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Chris-Down/printk-Userspace-format-enumeration-support/20210310-103231
git checkout 097254e932767fc7d5ba0243a83265017d427d74
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=openrisc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   or1k-linux-ld: arch/openrisc/kernel/entry.o: in function 
`_external_irq_handler':
>> (.text+0x5e4): undefined reference to `_printk'
   (.text+0x5e4): relocation truncated to fit: R_OR1K_INSN_REL_26 against 
undefined symbol `_printk'

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


.config.gz
Description: application/gzip

Re: [RFC] scripts: kernel-doc: avoid warnings due to initial commented lines in file

[Lukas Bulwahn]

On Tue, Mar 9, 2021 at 10:24 PM Aditya  wrote:
>
> On 9/3/21 7:00 pm, Markus Heiser wrote:
> >
> > Am 09.03.21 um 13:53 schrieb Aditya Srivastava:
> >> Starting commented lines in a file mostly contains comments describing
> >> license, copyright or general information about the file.
> >>
> >> E.g., in sound/pci/ctxfi/ctresource.c, initial comment lines describe
> >> its copyright and other related file informations.
> >
> > The opening comment mark /** is used for kernel-doc comments [1]
> >
> > [1]
> > https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html#how-to-format-kernel-doc-comments
> >
>
> Hi Markus!
> That's true. But the content inside the comment does not follow
> kernel-doc format.
> For e.g., try running kernel-doc -none/man/rst on the above file in
> the example("sound/pci/ctxfi/ctresource.c").
> The starting 2-3 lines in files generally do not contain any
> struct/enum/function, etc. declaration.
>

Aditya, can you provide a diff of the warnings over the whole kernel tree?

At the moment, your patch just implements ignoring the initial
comment, which probably is good for experimentation.

Alternatively, we could simply have a dedicated warning and then
ignore it or even warn and then parse it as-if.

In the "long run", we would probably want to fix all current files in
the repository by just replacing '/**' by '/*' and have kernel-doc
warn about this suspicious pattern, when new files appear (maybe even
configurable, but that is another feature to enable or disable certain
kernel-doc checks and warnings). I would certainly assist and
contribute to such a clean-up task.

I think the first step is to look at the diff, and see how many cases
really appear in the tree... then check how many patches throughout
the whole tree are required and if they are generally accepted.


Lukas

Re: [PATCH] mm,hwpoison: return -EBUSY when page already poisoned

[Aili Yao]

On Fri, 5 Mar 2021 15:55:25 +
"Luck, Tony"  wrote:

> > From the walk, it seems we have got the virtual address, can we just send a 
> > SIGBUS with it?  
> 
> If the walk wins the race and the pte for the poisoned page is still valid, 
> then yes.
> 
> But we could have:
> 
> CPU1CPU2
> memory_failure sets poison
> bit for struct page
> 
> 
> rmap finds page in task
> on CPU2 and sets PTE
> to not-valid-poison
> 
> memory_failure returns
> early because struct page
> already marked as poison
> 
> walk page tables looking
> for mapping - don't find it
> 
> -Tony

While I don't think there is a race condition, and if you really think the pfn 
with SIGBUS is not
proper, I think following patch maybe one way.
I copy your abandon code, and make a little modification, and just now it pass
my simple test.

And also this is a RFC version, only valid if you think the pfn with SIGBUS is 
not right.

Thanks!

>From a522ab8856e3a332a2318d57bb19f3c59594d462 Mon Sep 17 00:00:00 2001
From: Aili Yao 
Date: Wed, 10 Mar 2021 13:59:18 +0800
Subject: [PATCH] x86/mce: fix invalid SIGBUS address

walk the current process pte and compare with the pfn;
1. only test for normal page and 2M hugetlb page;
2. 1G hugetlb and transparentHuge is not support currently;
3. May other fails is not recognized, This is a RFC version.

---
 arch/x86/kernel/cpu/mce/core.c | 83 --
 1 file changed, 80 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
index db4afc5..65d7ef7 100644
--- a/arch/x86/kernel/cpu/mce/core.c
+++ b/arch/x86/kernel/cpu/mce/core.c
@@ -28,8 +28,12 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1235,6 +1239,81 @@ static void __mc_scan_banks(struct mce *m, struct 
pt_regs *regs, struct mce *fin
/* mce_clear_state will clear *final, save locally for use later */
*m = *final;
 }
+static int mc_pte_entry(pte_t *pte, unsigned long addr, unsigned long next, 
struct mm_walk *walk)
+{
+   u64 *buff = (u64 *)walk->private;
+   u64 pfn = buff[0];
+
+   if (!pte_present(*pte) && is_hwpoison_entry(pte_to_swp_entry(*pte)))
+   goto find;
+   else if (pte_pfn(*pte) == pfn)
+   goto find;
+
+   return 0;
+find:
+   buff[0] = addr;
+   buff[1] = PAGE_SHIFT;
+   return true;
+}
+
+extern bool is_hugetlb_entry_hwpoisoned(pte_t pte);
+
+static int mc_hugetlb_range(pte_t *ptep, unsigned long hmask,
+unsigned long addr, unsigned long end,
+struct mm_walk *walk)
+{
+   u64 *buff = (u64 *)walk->private;
+   u64 pfn = buff[0];
+   int shift = PMD_SHIFT;
+   pte_t pte =  huge_ptep_get(ptep);
+
+   if (unlikely(is_hugetlb_entry_hwpoisoned(pte)))
+   goto find;
+
+   if (pte_pfn(*ptep) == pfn)
+   goto find;
+
+   return 0;
+find:
+   buff[0] = addr;
+   buff[1] = shift;
+   return true;
+}
+
+static struct mm_walk_ops walk = {
+   .pte_entry = mc_pte_entry,
+   .hugetlb_entry  = mc_hugetlb_range
+};
+
+void mc_memory_failure_error(struct task_struct *p, unsigned long pfn)
+{
+   u64 buff[2] = {pfn, 0};
+   struct page *page;
+   int ret = -1;
+
+   page = pfn_to_page(pfn);
+   if (!page)
+   goto force_sigbus;
+
+   if (is_zone_device_page(page))
+   goto force_sigbus;
+
+   mmap_read_lock(p->mm);
+   ret = walk_page_range(p->mm, 0, TASK_SIZE_MAX, , (void *)buff);
+   mmap_read_unlock(p->mm);
+
+   if (ret && buff[0]) {
+   pr_err("Memory error may not recovered: %#llx: Sending SIGBUS 
to %s:%d due to hardware memory corruption\n",
+   buff[0], p->comm, p->pid);
+   force_sig_mceerr(BUS_MCEERR_AR, (void __user *)buff[0], 
buff[1]);
+   } else {
+force_sigbus:
+   pr_err("Memory error may not recovered, pfn: %#lx: Sending 
SIGBUS to %s:%d due to hardware memory corruption\n",
+   pfn, p->comm, p->pid);
+   force_sig_mceerr(BUS_MCEERR_AR, (void __user *)pfn, PAGE_SHIFT);
+   }
+
+}
 
 static void kill_me_now(struct callback_head *ch)
 {
@@ -1259,9 +1338,7 @@ static void kill_me_maybe(struct callback_head *cb)
}
 
if (p->mce_vaddr != (void __user *)-1l) {
-   pr_err("Memory error may not recovered: %#lx: Sending SIGBUS to 
%s:%d due to hardware memory corruption\n",
-   p->mce_addr >> PAGE_SHIFT, p->comm, p->pid);
-   force_sig_mceerr(BUS_MCEERR_AR, p->mce_vaddr, PAGE_SHIFT);
+   mc_memory_failure_error(current, p->mce_addr >> PAGE_SHIFT);
} else {

Re: [PATCH] vfio/pci: make the vfio_pci_mmap_fault reentrant

[Alex Williamson]

On Tue, 9 Mar 2021 19:41:27 -0400
Jason Gunthorpe  wrote:

> On Tue, Mar 09, 2021 at 12:26:07PM -0700, Alex Williamson wrote:
> 
> > In the new series, I think the fault handler becomes (untested):
> > 
> > static vm_fault_t vfio_pci_mmap_fault(struct vm_fault *vmf)
> > {
> > struct vm_area_struct *vma = vmf->vma;
> > struct vfio_pci_device *vdev = vma->vm_private_data;
> > unsigned long base_pfn, pgoff;
> > vm_fault_t ret = VM_FAULT_SIGBUS;
> > 
> > if (vfio_pci_bar_vma_to_pfn(vma, _pfn))
> > return ret;
> > 
> > pgoff = (vmf->address - vma->vm_start) >> PAGE_SHIFT;  
> 
> I don't think this math is completely safe, it needs to parse the
> vm_pgoff..
> 
> I'm worried userspace could split/punch/mangle a VMA using
> munmap/mremap/etc/etc in a way that does update the pg_off but is
> incompatible with the above.

parsing vm_pgoff is done in:

static int vfio_pci_bar_vma_to_pfn(struct vm_area_struct *vma,
   unsigned long *pfn)
{
struct vfio_pci_device *vdev = vma->vm_private_data;
struct pci_dev *pdev = vdev->pdev;
int index;
u64 pgoff;

index = vma->vm_pgoff >> (VFIO_PCI_OFFSET_SHIFT - PAGE_SHIFT);

if (index >= VFIO_PCI_ROM_REGION_INDEX ||
!vdev->bar_mmap_supported[index] || !vdev->barmap[index])
return -EINVAL;

pgoff = vma->vm_pgoff &
((1U << (VFIO_PCI_OFFSET_SHIFT - PAGE_SHIFT)) - 1);

*pfn = (pci_resource_start(pdev, index) >> PAGE_SHIFT) + pgoff;

return 0;
}

But given Peter's concern about faulting individual pages, I think the
fault handler becomes:

static vm_fault_t vfio_pci_mmap_fault(struct vm_fault *vmf)
{
struct vm_area_struct *vma = vmf->vma;
struct vfio_pci_device *vdev = vma->vm_private_data;
unsigned long vaddr, pfn;
vm_fault_t ret = VM_FAULT_SIGBUS;

if (vfio_pci_bar_vma_to_pfn(vma, ))
return ret;

down_read(>memory_lock);

if (__vfio_pci_memory_enabled(vdev)) {
for (vaddr = vma->vm_start;
 vaddr < vma->vm_end; vaddr += PAGE_SIZE, pfn++) {
ret = vmf_insert_pfn_prot(vma, vaddr, pfn,
pgprot_decrypted(vma->vm_page_prot));
if (ret != VM_FAULT_NOPAGE) {
zap_vma_ptes(vma, vma->vm_start,
 vaddr - vma->vm_start);
break;
}
}
}

up_read(>memory_lock);

return ret;
}

Thanks,
Alex

Re: [PATCH v6 04/12] x86/alternative: support not-feature

[Borislav Petkov]

On Tue, Mar 09, 2021 at 02:48:05PM +0100, Juergen Gross wrote:
> Add support for alternative patching for the case a feature is not
> present on the current cpu.
> 
> For users of ALTERNATIVE() and friends an inverted feature is specified
> by applying the ALT_NOT() macro to it, e.g.:
> 
> ALTERNATIVE(old, new, ALT_NOT(feature))
> 
> Signed-off-by: Juergen Gross 
> ---
> V5:
> - split off from next patch
> - reworked to use flag byte (Boris Petkov)
> V6:
> - rework again to not use flag byte (Boris Petkov)
> ---
>  arch/x86/include/asm/alternative-asm.h |  3 +++
>  arch/x86/include/asm/alternative.h |  3 +++
>  arch/x86/kernel/alternative.c  | 19 ++-
>  3 files changed, 20 insertions(+), 5 deletions(-)

LGTM, minor touchups I'd do ontop:

---

diff --git a/arch/x86/include/asm/alternative.h 
b/arch/x86/include/asm/alternative.h
index 89889618ae01..fd205cdcfbad 100644
--- a/arch/x86/include/asm/alternative.h
+++ b/arch/x86/include/asm/alternative.h
@@ -55,18 +55,18 @@
".long 999b - .\n\t"\
".popsection\n\t"
 
+#define ALTINSTR_FLAG_INV  (1 << 15)
+#define ALT_NOT(feat)  ((feat) | ALTINSTR_FLAG_INV)
+
 struct alt_instr {
s32 instr_offset;   /* original instruction */
s32 repl_offset;/* offset to replacement instruction */
u16 cpuid;  /* cpuid bit set for replacement */
-#define ALTINSTR_FLAG_INV (1 << 15)
u8  instrlen;   /* length of original instruction */
u8  replacementlen; /* length of new instruction */
u8  padlen; /* length of build-time padding */
 } __packed;
 
-#define ALT_NOT(feat)  ((feat) | ALTINSTR_FLAG_INV)
-
 /*
  * Debug flag that can be tested to see whether alternative
  * instructions were patched in already:
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index d8e669a1546f..133b549dc091 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -397,9 +397,10 @@ void __init_or_module noinline apply_alternatives(struct 
alt_instr *start,
BUG_ON(feature >= (NCAPINTS + NBUGINTS) * 32);
 
/*
-* Drop out if either:
-* - feature not available, but required, or
-* - feature available, but NOT required
+* Patch if either:
+* - feature is present
+* - feature not present but ALTINSTR_FLAG_INV is set to mean,
+*   patch if feature is *NOT* present.
 */
if (!boot_cpu_has(feature) == !(a->cpuid & ALTINSTR_FLAG_INV)) {
if (a->padlen > 1)

-- 
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette

[PATCH RESEND][next] qed: Fix fall-through warnings for Clang

[Gustavo A. R. Silva]

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding a couple of break statements instead of
just letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Reviewed-by: Igor Russkikh 
Signed-off-by: Gustavo A. R. Silva 
---
 Changes in RESEND:
 - None. Resending now that net-next is open.

 drivers/net/ethernet/qlogic/qed/qed_l2.c| 1 +
 drivers/net/ethernet/qlogic/qed/qed_sriov.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/qlogic/qed/qed_l2.c 
b/drivers/net/ethernet/qlogic/qed/qed_l2.c
index 07824bf9d68d..dfaf10edfabf 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_l2.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_l2.c
@@ -396,6 +396,7 @@ int qed_sp_eth_vport_start(struct qed_hwfn *p_hwfn,
tpa_param->tpa_ipv6_en_flg = 1;
tpa_param->tpa_pkt_split_flg = 1;
tpa_param->tpa_gro_consistent_flg = 1;
+   break;
default:
break;
}
diff --git a/drivers/net/ethernet/qlogic/qed/qed_sriov.c 
b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
index b8dc5c4591ef..ed2b6fe5a78d 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_sriov.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
@@ -4734,6 +4734,7 @@ void qed_inform_vf_link_state(struct qed_hwfn *hwfn)
 */
link.speed = (hwfn->cdev->num_hwfns > 1) ?
 10 : 4;
+   break;
default:
/* In auto mode pass PF link image to VF */
break;
-- 
2.27.0

Re: [PATCH v8 3/4] arm64: dts: mediatek: add mt6765 support

[Macpaul Lin]

On Wed, 2021-03-10 at 00:08 +0800, Chun-Kuang Hu wrote:
> Hi, Macpaul:
> 
> Macpaul Lin  於 2020年2月21日 週五 下午6:22寫道：
> >
> > From: Mars Cheng 
> >
> > Add basic chip support for Mediatek 6765, include
> > uart node with correct uart clocks, pwrap device
> >
> > Add clock controller nodes, include topckgen, infracfg,
> > apmixedsys and subsystem.
> >
> > Signed-off-by: Mars Cheng 
> > Signed-off-by: Owen Chen 
> > Signed-off-by: Macpaul Lin 
> > Acked-by: Marc Zyngier 
> > ---
> >  arch/arm64/boot/dts/mediatek/Makefile   |1 +
> >  arch/arm64/boot/dts/mediatek/mt6765-evb.dts |   33 
> >  arch/arm64/boot/dts/mediatek/mt6765.dtsi|  253 
> > +++
> >  3 files changed, 287 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/mediatek/mt6765-evb.dts
> >  create mode 100644 arch/arm64/boot/dts/mediatek/mt6765.dtsi

[deleted]

> > +
> > +   mmsys_config: syscon@1400 {
> > +   compatible = "mediatek,mt6765-mmsys", "syscon";
> > +   reg = <0 0x1400 0 0x1000>;
> > +   interrupts = ;
> 
> I does not see interrupts property in binding document [1], please add
> this in binding document first.
> I'm curious about this interrupt. In which condition would it be triggered?
> 
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt?h=v5.12-rc2
> 
> Regards,
> Chun-Kuang.

Thanks for reminding.
I'll remove interrupts binding in next version and leave it for mmsys
driver owner to update when the configuration of mmsys driver is
enabled.

[...]


> > +   smi_common: smi_common@14002000 {
> > +   compatible = "mediatek,mt6765-smi-common", "syscon";
> > +   reg = <0 0x14002000 0 0x1000>;
> > +   };
> > +

@Yong Wu
Thanks for reviewing here, I'll replace smi_common@14002000 to
smi@14002000

Regards,
Macpaul Lin

Re: [PATCH V2] mm/memtest: Add ARCH_USE_MEMTEST

[Anshuman Khandual]

On 3/1/21 10:02 AM, Anshuman Khandual wrote:
> early_memtest() does not get called from all architectures. Hence enabling
> CONFIG_MEMTEST and providing a valid memtest=[1..N] kernel command line
> option might not trigger the memory pattern tests as would be expected in
> normal circumstances. This situation is misleading.
> 
> The change here prevents the above mentioned problem after introducing a
> new config option ARCH_USE_MEMTEST that should be subscribed on platforms
> that call early_memtest(), in order to enable the config CONFIG_MEMTEST.
> Conversely CONFIG_MEMTEST cannot be enabled on platforms where it would
> not be tested anyway.
> 
> Cc: Russell King 
> Cc: Catalin Marinas 
> Cc: Will Deacon 
> Cc: Thomas Bogendoerfer 
> Cc: Michael Ellerman 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: Chris Zankel 
> Cc: Max Filippov 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-m...@vger.kernel.org
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: linux-xte...@linux-xtensa.org
> Cc: linux...@kvack.org
> Cc: linux-kernel@vger.kernel.org
> Reviewed-by: Max Filippov 
> Signed-off-by: Anshuman Khandual 
> ---
> This patch applies on v5.12-rc1 and has been tested on arm64 platform.
> But it has been just build tested on all other platforms.
> 
> Changes in V2:
> 
> - Added ARCH_USE_MEMTEST in the sorted alphabetical order on platforms

Gentle ping, any updates or objections ?

Re: linux-next: Tree for Mar 10 (lib/test_printf.c)

[Randy Dunlap]

On 3/9/21 8:02 PM, Stephen Rothwell wrote:
> Hi all,
> 

on i386 (at least):

../lib/test_printf.c: In function 'page_flags_test':
../lib/test_printf.c:595:17: error: 'sec' undeclared (first use in this 
function); did you mean 'sem'?
  page_flags |= (sec & SECTIONS_MASK) << SECTIONS_PGSHIFT;
 ^~~


Should that be 'section'?


-- 
~Randy
Reported-by: Randy Dunlap 

Re: [External] linux-next: build failure after merge of the akpm-current tree

[Muchun Song]

On Wed, Mar 10, 2021 at 11:55 AM Stephen Rothwell  wrote:
>
> Hi all,
>
> After merging the akpm-current tree, today's linux-next build (sparc64
> defconfig) failed like this:
>
> arch/sparc/mm/init_64.c:2495:4: error: implicit declaration of function 
> 'register_page_bootmem_info_node'; did you mean 'register_page_bootmem_info'? 
> [-Werror=implicit-function-declaration]
> register_page_bootmem_info_node(NODE_DATA(i));
> ^~~
> register_page_bootmem_info
>
> Caused by commit
>
>   cd28b1a6791d ("mm: memory_hotplug: factor out bootmem core functions to 
> bootmem_info.c")
>
> grep is your friend ...
>
> I have applied the following patch for today:
>
> From: Stephen Rothwell 
> Date: Wed, 10 Mar 2021 14:46:27 +1100
> Subject: [PATCH] fix for "mm: memory_hotplug: factor out bootmem core
>  functions to bootmem_info.c"
>
> Signed-off-by: Stephen Rothwell 

Sorry, it is my mistake. Thanks Stephen to fix this. This is the right fix.


> ---
>  arch/sparc/mm/init_64.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
> index 182bb7bdaa0a..c709b72e81bf 100644
> --- a/arch/sparc/mm/init_64.c
> +++ b/arch/sparc/mm/init_64.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> --
> 2.30.0
>
> --
> Cheers,
> Stephen Rothwell

Re: [PATCH] sched/fair: Prefer idle CPU to cache affinity

[Srikar Dronamraju]

* Vincent Guittot  [2021-03-08 14:52:39]:

> On Fri, 26 Feb 2021 at 17:41, Srikar Dronamraju
>  wrote:
> >

Thanks Vincent for your review comments.

> > +static int prefer_idler_llc(int this_cpu, int prev_cpu, int sync)
> > +{
> > +   struct sched_domain_shared *tsds, *psds;
> > +   int pnr_busy, pllc_size, tnr_busy, tllc_size, diff;
> > +
> > +   tsds = rcu_dereference(per_cpu(sd_llc_shared, this_cpu));
> > +   tnr_busy = atomic_read(>nr_busy_cpus);
> > +   tllc_size = per_cpu(sd_llc_size, this_cpu);
> > +
> > +   psds = rcu_dereference(per_cpu(sd_llc_shared, prev_cpu));
> > +   pnr_busy = atomic_read(>nr_busy_cpus);
> > +   pllc_size = per_cpu(sd_llc_size, prev_cpu);
> > +
> > +   /* No need to compare, if both LLCs are fully loaded */
> > +   if (pnr_busy == pllc_size && tnr_busy == pllc_size)
> > +   return nr_cpumask_bits;
> > +
> > +   if (sched_feat(WA_WAKER) && tnr_busy < tllc_size)
> > +   return this_cpu;
> 
> Why have you chosen to favor this_cpu instead of prev_cpu unlike for 
> wake_idle ?

At this point, we know the waker running on this_cpu and wakee which was
running on prev_cpu are affine to each other and this_cpu and prev_cpu dont
share cache. I chose to move them close to each other to benefit from the
cache sharing. Based on feedback from Peter and Rik, I made the check more
conservative i.e tnr_busy <= tllc_size/smt_weight (where smt_weight is the
cpumask weight of smt domain for this_cpu) i.e if we have a free core in
this llc domain, chose this_cpu.  select_idle_sibling() should pick an idle
cpu/core/smt within the llc domain for this_cpu.

Do you feel, this may not be the correct option?

We are also experimenting with another option, were we call prefer_idler_cpu
after wa_weight. I.e 
1. if wake_affine_weight choses this_cpu but llc in prev_cpu has an idle
smt/CPU but there are no idle smt/CPU in this_cpu, then chose idle smt/CPU
in prev_cpu
2. if wake_affine_weight choses nr_cpumask(aka prev_cpu) but llc in this_cpu
has an idle smt/CPU but there are no idle smt/CPU in prev_cpu, then chose
idle smt/CPU in this_cpu


> > +
> > +   /* For better wakeup latency, prefer idler LLC to cache affinity */
> > +   diff = tnr_busy * pllc_size - sync - pnr_busy * tllc_size;
> > +   if (!diff)
> > +   return nr_cpumask_bits;
> > +   if (diff < 0)
> > +   return this_cpu;
> > +
> > +   return prev_cpu;
> > +}
> > +
> >  static int wake_affine(struct sched_domain *sd, struct task_struct *p,
> >int this_cpu, int prev_cpu, int sync)
> >  {
> > @@ -5877,6 +5907,10 @@ static int wake_affine(struct sched_domain *sd, 
> > struct task_struct *p,
> > if (sched_feat(WA_IDLE))
> > target = wake_affine_idle(this_cpu, prev_cpu, sync);
> >
> > +   if (sched_feat(WA_IDLER_LLC) && target == nr_cpumask_bits &&
> > +   !cpus_share_cache(this_cpu, prev_cpu))
> > +   target = prefer_idler_llc(this_cpu, prev_cpu, sync);
> 
> could you use the same naming convention as others function ?
> wake_affine_llc as an example

I guess you meant s/prefer_idler_llc/wake_affine_llc/
Sure. I can modify.

> 
> > +
> > if (sched_feat(WA_WEIGHT) && target == nr_cpumask_bits)
> > target = wake_affine_weight(sd, p, this_cpu, prev_cpu, 
> > sync);
> >
> > @@ -5884,8 +5918,11 @@ static int wake_affine(struct sched_domain *sd, 
> > struct task_struct *p,
> > if (target == nr_cpumask_bits)
> > return prev_cpu;
> >
> > -   schedstat_inc(sd->ttwu_move_affine);
> > -   schedstat_inc(p->se.statistics.nr_wakeups_affine);
> > +   if (target == this_cpu) {
> 
> How is this condition related to $subject ?

Before this change, wake_affine_weight and wake_affine_idle would either
return this_cpu or nr_cpumask_bits. Just before this check, we check if
target is nr_cpumask_bits and return prev_cpu. So the stats were only
incremented when target was this_cpu.

However with prefer_idler_llc, we may return this_cpu, prev_cpu or
nr_cpumask_bits. Now we only to update stats when we have chosen to migrate
the task to this_cpu. Hence I had this check.

If we use the slightly lazier approach which is check for wa_weight first
before wa_idler_llc, then we may not need this change at all.

-- 
Thanks and Regards
Srikar Dronamraju

[PATCH V2] arm64/mm: Fix __enable_mmu() for new TGRAN range values

[Anshuman Khandual]

From: James Morse 

As per ARM ARM DDI 0487G.a, when FEAT_LPA2 is implemented, ID_AA64MMFR0_EL1
might contain a range of values to describe supported translation granules
(4K and 16K pages sizes in particular) instead of just enabled or disabled
values. This changes __enable_mmu() function to handle complete acceptable
range of values (depending on whether the field is signed or unsigned) now
represented with ID_AA64MMFR0_TGRAN_SUPPORTED_[MIN..MAX] pair. While here,
also fix similar situations in EFI stub and KVM as well.

Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Marc Zyngier 
Cc: James Morse 
Cc: Suzuki K Poulose 
Cc: Ard Biesheuvel 
Cc: Mark Rutland 
Cc: linux-arm-ker...@lists.infradead.org
Cc: kvm...@lists.cs.columbia.edu
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Marc Zyngier 
Signed-off-by: James Morse 
Signed-off-by: Anshuman Khandual 
---
Changes in V2:

- Changes back to switch construct in kvm_set_ipa_limit() per Marc

Changes in V1:

https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=442817

 arch/arm64/include/asm/sysreg.h   | 20 ++--
 arch/arm64/kernel/head.S  |  6 --
 arch/arm64/kvm/reset.c| 10 ++
 drivers/firmware/efi/libstub/arm64-stub.c |  2 +-
 4 files changed, 25 insertions(+), 13 deletions(-)

diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index dfd4edb..d4a5fca9 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -796,6 +796,11 @@
 #define ID_AA64MMFR0_PARANGE_480x5
 #define ID_AA64MMFR0_PARANGE_520x6
 
+#define ID_AA64MMFR0_TGRAN_2_SUPPORTED_DEFAULT 0x0
+#define ID_AA64MMFR0_TGRAN_2_SUPPORTED_NONE0x1
+#define ID_AA64MMFR0_TGRAN_2_SUPPORTED_MIN 0x2
+#define ID_AA64MMFR0_TGRAN_2_SUPPORTED_MAX 0x7
+
 #ifdef CONFIG_ARM64_PA_BITS_52
 #define ID_AA64MMFR0_PARANGE_MAX   ID_AA64MMFR0_PARANGE_52
 #else
@@ -961,14 +966,17 @@
 #define ID_PFR1_PROGMOD_SHIFT  0
 
 #if defined(CONFIG_ARM64_4K_PAGES)
-#define ID_AA64MMFR0_TGRAN_SHIFT   ID_AA64MMFR0_TGRAN4_SHIFT
-#define ID_AA64MMFR0_TGRAN_SUPPORTED   ID_AA64MMFR0_TGRAN4_SUPPORTED
+#define ID_AA64MMFR0_TGRAN_SHIFT   ID_AA64MMFR0_TGRAN4_SHIFT
+#define ID_AA64MMFR0_TGRAN_SUPPORTED_MIN   ID_AA64MMFR0_TGRAN4_SUPPORTED
+#define ID_AA64MMFR0_TGRAN_SUPPORTED_MAX   0x7
 #elif defined(CONFIG_ARM64_16K_PAGES)
-#define ID_AA64MMFR0_TGRAN_SHIFT   ID_AA64MMFR0_TGRAN16_SHIFT
-#define ID_AA64MMFR0_TGRAN_SUPPORTED   ID_AA64MMFR0_TGRAN16_SUPPORTED
+#define ID_AA64MMFR0_TGRAN_SHIFT   ID_AA64MMFR0_TGRAN16_SHIFT
+#define ID_AA64MMFR0_TGRAN_SUPPORTED_MIN   ID_AA64MMFR0_TGRAN16_SUPPORTED
+#define ID_AA64MMFR0_TGRAN_SUPPORTED_MAX   0xF
 #elif defined(CONFIG_ARM64_64K_PAGES)
-#define ID_AA64MMFR0_TGRAN_SHIFT   ID_AA64MMFR0_TGRAN64_SHIFT
-#define ID_AA64MMFR0_TGRAN_SUPPORTED   ID_AA64MMFR0_TGRAN64_SUPPORTED
+#define ID_AA64MMFR0_TGRAN_SHIFT   ID_AA64MMFR0_TGRAN64_SHIFT
+#define ID_AA64MMFR0_TGRAN_SUPPORTED_MIN   ID_AA64MMFR0_TGRAN64_SUPPORTED
+#define ID_AA64MMFR0_TGRAN_SUPPORTED_MAX   0x7
 #endif
 
 #define MVFR2_FPMISC_SHIFT 4
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 66b0e0b..8b469f1 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -655,8 +655,10 @@ SYM_FUNC_END(__secondary_too_slow)
 SYM_FUNC_START(__enable_mmu)
mrs x2, ID_AA64MMFR0_EL1
ubfxx2, x2, #ID_AA64MMFR0_TGRAN_SHIFT, 4
-   cmp x2, #ID_AA64MMFR0_TGRAN_SUPPORTED
-   b.ne__no_granule_support
+   cmp x2, #ID_AA64MMFR0_TGRAN_SUPPORTED_MIN
+   b.lt__no_granule_support
+   cmp x2, #ID_AA64MMFR0_TGRAN_SUPPORTED_MAX
+   b.gt__no_granule_support
update_early_cpu_boot_status 0, x2, x3
adrpx2, idmap_pg_dir
phys_to_ttbr x1, x1
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 47f3f03..e81c7ec 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -311,16 +311,18 @@ int kvm_set_ipa_limit(void)
}
 
switch (cpuid_feature_extract_unsigned_field(mmfr0, tgran_2)) {
-   default:
-   case 1:
+   case ID_AA64MMFR0_TGRAN_2_SUPPORTED_NONE:
kvm_err("PAGE_SIZE not supported at Stage-2, giving up\n");
return -EINVAL;
-   case 0:
+   case ID_AA64MMFR0_TGRAN_2_SUPPORTED_DEFAULT:
kvm_debug("PAGE_SIZE supported at Stage-2 (default)\n");
break;
-   case 2:
+   case ID_AA64MMFR0_TGRAN_2_SUPPORTED_MIN ... 
ID_AA64MMFR0_TGRAN_2_SUPPORTED_MAX:
kvm_debug("PAGE_SIZE supported at Stage-2 (advertised)\n");
break;
+   default:
+   kvm_err("Unsupported value for TGRAN_2, giving up\n");
+   return -EINVAL;
}
 
kvm_ipa_limit = id_aa64mmfr0_parange_to_phys_shift(parange);
diff 

RE: [PATCH v2] arm: print alloc free paths for address in registers

[Maninder Singh]

Hi,

Any comments or updates?

>Sender : Maninder Singh  Engineer/Platform S/W Group 
>/SRI-Delhi/Samsung Electronics 
>Date : 2021-02-25 13:57 (GMT+5:30)
>Title : [PATCH v2] arm: print alloc free paths for address in registers
> 
>In case of "Use After Free" kernel OOPs, free path of object
>is required to debug futher.
>And in most of cases object address is present in one of registers.
> 
>Thus check for register address and if it belongs to slab,
>print its alloc and free path.
> 
>e.g. in below issue  register r6 belongs to slab, and use after free issue
>occurred on one of its derefer values:
> 
>[  124.310386] (ptrval)
>[  124.312647] 8<--- cut here ---
>[  124.313761] Unable to handle kernel paging request at virtual address 
>6b6b6b6f
>[  124.315972] pgd = (ptrval)
>...
>[  124.328290] pc : []lr : []psr: 6013
>[  124.330349] sp : c8993d28  ip : bff4  fp : c8ae2020
>[  124.332071] r10:   r9 : 0001  r8 : c1804cc8
>[  124.333803] r7 :   r6 : c8ae9180  r5 : c1804a80  r4 : c8ae2008
>[  124.335936] r3 : 6b6b6b6b  r2 : 315049d6  r1 : 2d867000  r0 : c1396584
>..
>[  124.365233] register r6: c8ae9180 belongs to slab object
>[  124.366364] INFO: Allocated in meminfo_proc_show+0x3c/0x500 age=1 cpu=0 
>pid=69
>[  124.367545]  meminfo_proc_show+0x3c/0x500
>[  124.368271]  seq_read_iter+0x10c/0x4bc
>[  124.368994]  proc_reg_read_iter+0x74/0xa8
>[  124.369712]  generic_file_splice_read+0xe8/0x178
>[  124.370496]  splice_direct_to_actor+0xe0/0x2b8
>[  124.371261]  do_splice_direct+0xa4/0xdc
>[  124.371917]  do_sendfile+0x1c4/0x3ec
>[  124.372550]  sys_sendfile64+0x128/0x130
>[  124.373109]  ret_fast_syscall+0x0/0x54
>[  124.373664]  0xbe9a2de4
>[  124.374081] INFO: Freed in meminfo_proc_show+0x5c/0x500 age=1 cpu=0 pid=69
>[  124.374933]  meminfo_proc_show+0x5c/0x500
>[  124.375485]  seq_read_iter+0x10c/0x4bc
>[  124.376020]  proc_reg_read_iter+0x74/0xa8
>[  124.376643]  generic_file_splice_read+0xe8/0x178
>[  124.377331]  splice_direct_to_actor+0xe0/0x2b8
>[  124.378022]  do_splice_direct+0xa4/0xdc
>[  124.378633]  do_sendfile+0x1c4/0x3ec
>[  124.379220]  sys_sendfile64+0x128/0x130
>[  124.379822]  ret_fast_syscall+0x0/0x54
>[  124.380421]  0xbe9a2de4
> 
>Co-developed-by: Vaneet Narang 
>Signed-off-by: Vaneet Narang 
>Signed-off-by: Maninder Singh 
>---
>v1 -> v2: do address sanity with virt_addr_valid
> 
> arch/arm/include/asm/bug.h |  1 +
> arch/arm/kernel/process.c  | 18 ++
> arch/arm/kernel/traps.c|  1 +
> include/linux/slab.h   | 14 ++
> mm/slab.h  |  7 ---
> mm/slub.c  | 18 ++
> 6 files changed, 52 insertions(+), 7 deletions(-)
 

Thanks,
Maninder Singh

Re: [PATCH] Input: elan_i2c - Reduce the resume time for new dev ices

['Dmitry Torokhov']

On Tue, Mar 09, 2021 at 10:53:34PM +0800, jingle.wu wrote:
> Hi Dmitry:
> 
> Was this the only issue with the updated patch? Did it work for you
> otherwise?
> -> Yes, the updated patch can work successfully after fix this issue.

OK, great, I applied it.

Thanks.

-- 
Dmitry

RE: [PATCH] usb: gadget: uvc: add bInterval checking for HS mode

[Pawel Laszczak]

Please check whether the problem occurs in this fragment of code:
https://elixir.bootlin.com/linux/latest/source/drivers/usb/cdns3/gadget.c#L2569

zlp_buff is allocated with kzalloc.

Pawel

>>On Fri, Mar 5, 2021 at 12:40 AM Pawel Laszczak  
>>wrote:
>>From: Pawel Laszczak 
>>
>>Patch adds extra checking for bInterval passed by configfs.
>>The 5.6.4 chapter of USB Specification (rev. 2.0) say:
>>"A high-bandwidth endpoint must specify a period of 1x125 µs
>>(i.e., a bInterval value of 1)."
>>
>>The issue was observed during testing UVC class on CV.
>>I treat this change as improvement because we can control
>>bInterval by configfs.
>>
>>Signed-off-by: Pawel Laszczak 
>>---
>> drivers/usb/gadget/function/f_uvc.c | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>>diff --git a/drivers/usb/gadget/function/f_uvc.c 
>>b/drivers/usb/gadget/function/f_uvc.c
>>index 44b4352a2676..5d62720bb9e1 100644
>>--- a/drivers/usb/gadget/function/f_uvc.c
>>+++ b/drivers/usb/gadget/function/f_uvc.c
>>@@ -631,6 +631,12 @@ uvc_function_bind(struct usb_configuration *c, struct 
>>usb_function *f)
>>                cpu_to_le16(min(opts->streaming_maxpacket, 1023U));
>>        uvc_fs_streaming_ep.bInterval = opts->streaming_interval;
>>
>>+       /* A high-bandwidth endpoint must specify a bInterval value of 1 */
>>+       if (max_packet_mult > 1)
>>+               uvc_hs_streaming_ep.bInterval = 1;
>>+       else
>>+               uvc_hs_streaming_ep.bInterval = opts->streaming_interval;
>>+
>>
>>There is a "uvc_hs_streaming_ep.bInterval = opts->streaming_interval;" again 
>>at below code
>>Besides, the default value is 1 for opts->streaming_interval. What the real 
>>issue you observed
>>at CV test?
>>
>
>The issue occurs when I intentionally set:
>echo 3072  > functions/$FUNCTION/streaming_maxpacket
>echo 4 > functions/$FUNCTION/streaming_interval
>
>Then for  CV CH9 TD 9.5: Endpoint Descriptor test it got:
>"(Mult = 2)Illegal high speed isochronous endpoint MaxPacketSize : 0x400
>(USB: 1.2.78) A High speed Interrupt/Isochronous endpoint must have a 
>MaxPacketSize between
>683 and 1024 and bInterval value of 1 when the Mult value is two."
>
>For default value CV passed.  Of course, I can fix it by changing  
>streaming_interval, but I thought that
>it could be good to have protection against this issue.
>Especially since Usb 2 specification say that bInterval must be 1 for high 
>bandwidth endpoints.
>
>Pawel
>
>>Peter
>>
>>        uvc_hs_streaming_ep.wMaxPacketSize =
>>                cpu_to_le16(max_packet_size | ((max_packet_mult - 1) << 11));
>>        uvc_hs_streaming_ep.bInterval = opts->streaming_interval;
>>--
>>2.25.1

[PATCH RESEND][next] net: plip: Fix fall-through warnings for Clang

[Gustavo A. R. Silva]

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva 
---
 Changes in RESEND:
 - None. Resending now that net-next is open.

 drivers/net/plip/plip.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/plip/plip.c b/drivers/net/plip/plip.c
index 4406b353123e..e26cf91bdec2 100644
--- a/drivers/net/plip/plip.c
+++ b/drivers/net/plip/plip.c
@@ -516,6 +516,7 @@ plip_receive(unsigned short nibble_timeout, struct 
net_device *dev,
*data_p |= (c0 << 1) & 0xf0;
write_data (dev, 0x00); /* send ACK */
*ns_p = PLIP_NB_BEGIN;
+   break;
case PLIP_NB_2:
break;
}
@@ -808,6 +809,7 @@ plip_send_packet(struct net_device *dev, struct net_local 
*nl,
return HS_TIMEOUT;
}
}
+   break;
 
case PLIP_PK_LENGTH_LSB:
if (plip_send(nibble_timeout, dev,
-- 
2.27.0

[PATCH RESEND][next] net: rose: Fix fall-through warnings for Clang

[Gustavo A. R. Silva]

In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of
letting the code fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva 
---
 Changes in RESEND:
 - None. Resending now that net-next is open.

 net/rose/rose_route.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/rose/rose_route.c b/net/rose/rose_route.c
index 6e35703ff353..c0e04c261a15 100644
--- a/net/rose/rose_route.c
+++ b/net/rose/rose_route.c
@@ -347,6 +347,7 @@ static int rose_del_node(struct rose_route_struct 
*rose_route,
case 1:
rose_node->neighbour[1] =
rose_node->neighbour[2];
+   break;
case 2:
break;
}
@@ -508,6 +509,7 @@ void rose_rt_device_down(struct net_device *dev)
fallthrough;
case 1:
t->neighbour[1] = t->neighbour[2];
+   break;
case 2:
break;
}
-- 
2.27.0

[PATCH RESEND][next] net: core: Fix fall-through warnings for Clang

[Gustavo A. R. Silva]

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva 
---
 Changes in RESEND:
 - None. Resending now that net-next is open.

 net/core/dev.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/core/dev.c b/net/core/dev.c
index 6c5967e80132..2bfdd528c7c3 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5265,6 +5265,7 @@ static int __netif_receive_skb_core(struct sk_buff 
**pskb, bool pfmemalloc,
goto another_round;
case RX_HANDLER_EXACT:
deliver_exact = true;
+   break;
case RX_HANDLER_PASS:
break;
default:
-- 
2.27.0

include/linux/efi.h:1101:34: warning: passing 1-byte aligned argument to 4-byte aligned parameter 2 of 'get_var' may result in an unaligned pointer access

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   05a59d79793d482f628a31753c671f2e92178a21
commit: e1ac4b2406d94eddce8ac2c5ab4235f6075a9602 efi: generalize 
efi_get_secureboot
date:   4 months ago
config: x86_64-randconfig-a016-20210308 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 
cd9a69289c7825d54450cb6829fef2c8e0f1963a)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e1ac4b2406d94eddce8ac2c5ab4235f6075a9602
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout e1ac4b2406d94eddce8ac2c5ab4235f6075a9602
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

   In file included from drivers/firmware/dmi_scan.c:8:
>> include/linux/efi.h:1101:34: warning: passing 1-byte aligned argument to 
>> 4-byte aligned parameter 2 of 'get_var' may result in an unaligned pointer 
>> access [-Walign-mismatch]
   status = get_var(L"SecureBoot", _GLOBAL_VARIABLE_GUID, NULL, 
,
   ^
   include/linux/efi.h:1109:24: warning: passing 1-byte aligned argument to 
4-byte aligned parameter 2 of 'get_var' may result in an unaligned pointer 
access [-Walign-mismatch]
   get_var(L"SetupMode", _GLOBAL_VARIABLE_GUID, NULL, , 
);
 ^
   2 warnings generated.
--
   In file included from init/main.c:50:
>> include/linux/efi.h:1101:34: warning: passing 1-byte aligned argument to 
>> 4-byte aligned parameter 2 of 'get_var' may result in an unaligned pointer 
>> access [-Walign-mismatch]
   status = get_var(L"SecureBoot", _GLOBAL_VARIABLE_GUID, NULL, 
,
   ^
   include/linux/efi.h:1109:24: warning: passing 1-byte aligned argument to 
4-byte aligned parameter 2 of 'get_var' may result in an unaligned pointer 
access [-Walign-mismatch]
   get_var(L"SetupMode", _GLOBAL_VARIABLE_GUID, NULL, , 
);
 ^
   init/main.c:766:20: warning: no previous prototype for function 
'mem_encrypt_init' [-Wmissing-prototypes]
   void __init __weak mem_encrypt_init(void) { }
  ^
   init/main.c:766:1: note: declare 'static' if the function is not intended to 
be used outside of this translation unit
   void __init __weak mem_encrypt_init(void) { }
   ^
   static 
   3 warnings generated.
--
   In file included from arch/x86/mm/ioremap.c:18:
>> include/linux/efi.h:1101:34: warning: passing 1-byte aligned argument to 
>> 4-byte aligned parameter 2 of 'get_var' may result in an unaligned pointer 
>> access [-Walign-mismatch]
   status = get_var(L"SecureBoot", _GLOBAL_VARIABLE_GUID, NULL, 
,
   ^
   include/linux/efi.h:1109:24: warning: passing 1-byte aligned argument to 
4-byte aligned parameter 2 of 'get_var' may result in an unaligned pointer 
access [-Walign-mismatch]
   get_var(L"SetupMode", _GLOBAL_VARIABLE_GUID, NULL, , 
);
 ^
   arch/x86/mm/ioremap.c:737:17: warning: no previous prototype for function 
'early_memremap_pgprot_adjust' [-Wmissing-prototypes]
   pgprot_t __init early_memremap_pgprot_adjust(resource_size_t phys_addr,
   ^
   arch/x86/mm/ioremap.c:737:1: note: declare 'static' if the function is not 
intended to be used outside of this translation unit
   pgprot_t __init early_memremap_pgprot_adjust(resource_size_t phys_addr,
   ^
   static 
   3 warnings generated.


vim +/get_var +1101 include/linux/efi.h

  1092  
  1093  static inline
  1094  enum efi_secureboot_mode efi_get_secureboot_mode(efi_get_variable_t 
*get_var)
  1095  {
  1096  u8 secboot, setupmode = 0;
  1097  efi_status_t status;
  1098  unsigned long size;
  1099  
  1100  size = sizeof(secboot);
> 1101  status = get_var(L"SecureBoot", _GLOBAL_VARIABLE_GUID, 
> NULL, ,
  1102   );
  1103  if (status == EFI_NOT_FOUND)
  1104  return efi_secureboot_mode_disabled;
  1105  if (status != EFI_SUCCESS)
  1106  return efi_secureboot_mode_unknown;
  1107  
  1108  size = sizeof(setupmode);
  1109  get_var(L"SetupMode", _GLOBAL_VARIABLE_GUID, NULL, , 
);
  1110  if (secboot == 0 || setupmode == 1)
    return 

[PATCH RESEND][next] net: bridge: Fix fall-through warnings for Clang

[Gustavo A. R. Silva]

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Acked-by: Nikolay Aleksandrov 
Signed-off-by: Gustavo A. R. Silva 
---
 Changes in RESEND:
 - None. Resending now that net-next is open.

 net/bridge/br_input.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index 85d9dae2..8875e953ac53 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_input.c
@@ -144,6 +144,7 @@ int br_handle_frame_finish(struct net *net, struct sock 
*sk, struct sk_buff *skb
break;
case BR_PKT_UNICAST:
dst = br_fdb_find_rcu(br, eth_hdr(skb)->h_dest, vid);
+   break;
default:
break;
}
-- 
2.27.0

[PATCH RESEND][next] net: ax25: Fix fall-through warnings for Clang

[Gustavo A. R. Silva]

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva 
---
 Changes in RESEND:
 - None. Resending now that net-next is open.

 net/ax25/af_ax25.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c
index 269ee89d2c2b..2631efc6e359 100644
--- a/net/ax25/af_ax25.c
+++ b/net/ax25/af_ax25.c
@@ -850,6 +850,7 @@ static int ax25_create(struct net *net, struct socket 
*sock, int protocol,
case AX25_P_ROSE:
if (ax25_protocol_is_registered(AX25_P_ROSE))
return -ESOCKTNOSUPPORT;
+   break;
 #endif
default:
break;
-- 
2.27.0

[PATCH RESEND][next] decnet: Fix fall-through warnings for Clang

[Gustavo A. R. Silva]

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva 
---
 Changes in RESEND:
 - None. Resending now that net-next is open.

 net/decnet/dn_route.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/decnet/dn_route.c b/net/decnet/dn_route.c
index 2193ae529e75..37c90c1fdc93 100644
--- a/net/decnet/dn_route.c
+++ b/net/decnet/dn_route.c
@@ -1407,7 +1407,7 @@ static int dn_route_input_slow(struct sk_buff *skb)
flags |= RTCF_DOREDIRECT;
 
local_src = DN_FIB_RES_PREFSRC(res);
-
+   break;
case RTN_BLACKHOLE:
case RTN_UNREACHABLE:
break;
-- 
2.27.0

[PATCH RESEND][next] net: cassini: Fix fall-through warnings for Clang

[Gustavo A. R. Silva]

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of just letting the code
fall through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva 
---
 Changes in RESEND:
 - None. Resending now that net-next is open.

 drivers/net/ethernet/sun/cassini.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/sun/cassini.c 
b/drivers/net/ethernet/sun/cassini.c
index 9ff894ba8d3e..54f45d8c79a7 100644
--- a/drivers/net/ethernet/sun/cassini.c
+++ b/drivers/net/ethernet/sun/cassini.c
@@ -1599,6 +1599,7 @@ static inline int cas_mdio_link_not_up(struct cas *cp)
cas_phy_write(cp, MII_BMCR, val);
break;
}
+   break;
default:
break;
}
-- 
2.27.0

[PATCH V11 5/5] of: unittest: Statically apply overlays using fdtoverlay

[Viresh Kumar]

Now that fdtoverlay is part of the kernel build, start using it to test
the unitest overlays we have by applying them statically. Create two new
base files static_base_1.dts and static_base_2.dts which includes other
.dtsi files.

Some unittest overlays deliberately contain errors that unittest checks
for. These overlays will cause fdtoverlay to fail, and are thus not
included for static builds.

Signed-off-by: Viresh Kumar 
---
 drivers/of/unittest-data/Makefile  | 48 ++
 drivers/of/unittest-data/static_base_1.dts |  4 ++
 drivers/of/unittest-data/static_base_2.dts |  4 ++
 3 files changed, 56 insertions(+)
 create mode 100644 drivers/of/unittest-data/static_base_1.dts
 create mode 100644 drivers/of/unittest-data/static_base_2.dts

diff --git a/drivers/of/unittest-data/Makefile 
b/drivers/of/unittest-data/Makefile
index 009f4045c8e4..a5d2d9254b2c 100644
--- a/drivers/of/unittest-data/Makefile
+++ b/drivers/of/unittest-data/Makefile
@@ -38,3 +38,51 @@ DTC_FLAGS_testcases += -@
 
 # suppress warnings about intentional errors
 DTC_FLAGS_testcases += -Wno-interrupts_property
+
+# Apply overlays statically with fdtoverlay.  This is a build time test that
+# the overlays can be applied successfully by fdtoverlay.  This does not
+# guarantee that the overlays can be applied successfully at run time by
+# unittest, but it provides a bit of build time test coverage for those
+# who do not execute unittest.
+#
+# The overlays are applied on top of static_base_1.dtb and static_base_2.dtb to
+# create static_test_1.dtb and static_test_2.dtb.  If fdtoverlay detects an
+# error than the kernel build will fail.  static_test_1.dtb and
+# static_test_2.dtb are not consumed by unittest.
+#
+# Some unittest overlays deliberately contain errors that unittest checks for.
+# These overlays will cause fdtoverlay to fail, and are thus not included
+# in the static test:
+#overlay_bad_add_dup_node.dtbo \
+#overlay_bad_add_dup_prop.dtbo \
+#overlay_bad_phandle.dtbo \
+#overlay_bad_symbol.dtbo \
+
+apply_static_overlay_1 := overlay_0.dtbo \
+ overlay_1.dtbo \
+ overlay_2.dtbo \
+ overlay_3.dtbo \
+ overlay_4.dtbo \
+ overlay_5.dtbo \
+ overlay_6.dtbo \
+ overlay_7.dtbo \
+ overlay_8.dtbo \
+ overlay_9.dtbo \
+ overlay_10.dtbo \
+ overlay_11.dtbo \
+ overlay_12.dtbo \
+ overlay_13.dtbo \
+ overlay_15.dtbo \
+ overlay_gpio_01.dtbo \
+ overlay_gpio_02a.dtbo \
+ overlay_gpio_02b.dtbo \
+ overlay_gpio_03.dtbo \
+ overlay_gpio_04a.dtbo \
+ overlay_gpio_04b.dtbo
+
+apply_static_overlay_2 := overlay.dtbo
+
+static_test_1-dtbs := static_base_1.dtb $(apply_static_overlay_1)
+static_test_2-dtbs := static_base_2.dtb $(apply_static_overlay_2)
+
+dtb-$(CONFIG_OF_OVERLAY) += static_test_1.dtb static_test_2.dtb
diff --git a/drivers/of/unittest-data/static_base_1.dts 
b/drivers/of/unittest-data/static_base_1.dts
new file mode 100644
index ..10556cb3f01f
--- /dev/null
+++ b/drivers/of/unittest-data/static_base_1.dts
@@ -0,0 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+#include "testcases_common.dtsi"
diff --git a/drivers/of/unittest-data/static_base_2.dts 
b/drivers/of/unittest-data/static_base_2.dts
new file mode 100644
index ..b0ea9504d6f3
--- /dev/null
+++ b/drivers/of/unittest-data/static_base_2.dts
@@ -0,0 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+#include "overlay_common.dtsi"
-- 
2.25.0.rc1.19.g042ed3e048af

[PATCH V11 3/5] kbuild: Allow .dtso format for overlay source files

[Viresh Kumar]

Since the overlays dtb files are now named as .dtbo, there is a lot of
interest in similarly naming the overlay source dts files as .dtso.

This patch makes the necessary changes to allow .dtso format for overlay
source files.

Note that we still support generating .dtbo files from .dts files. This
is required for the source files present in drivers/of/unittest-data/,
because they can't be renamed to .dtso as they are used for some runtime
testing as well.

Reviewed-by: Geert Uytterhoeven 
Tested-by: Geert Uytterhoeven 
Signed-off-by: Viresh Kumar 
---
 scripts/Makefile.lib | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index bc045a54a34e..59e86f67f9e0 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -339,7 +339,7 @@ $(obj)/%.dtb.S: $(obj)/%.dtb FORCE
 
 quiet_cmd_dtc = DTC $@
 cmd_dtc = $(HOSTCC) -E $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $< 
; \
-   $(DTC) -O $(patsubst .%,%,$(suffix $@)) -o $@ -b 0 \
+   $(DTC) -I dts -O $(patsubst .%,%,$(suffix $@)) -o $@ -b 0 \
$(addprefix -i,$(dir $<) $(DTC_INCLUDE)) $(DTC_FLAGS) \
-d $(depfile).dtc.tmp $(dtc-tmp) ; \
cat $(depfile).pre.tmp $(depfile).dtc.tmp > $(depfile)
@@ -347,9 +347,13 @@ cmd_dtc = $(HOSTCC) -E $(dtc_cpp_flags) -x 
assembler-with-cpp -o $(dtc-tmp) $< ;
 $(obj)/%.dtb: $(src)/%.dts $(DTC) FORCE
$(call if_changed_dep,dtc)
 
+# Required for of unit-test files as they can't be renamed to .dtso
 $(obj)/%.dtbo: $(src)/%.dts $(DTC) FORCE
$(call if_changed_dep,dtc)
 
+$(obj)/%.dtbo: $(src)/%.dtso $(DTC) FORCE
+   $(call if_changed_dep,dtc)
+
 overlay-y := $(addprefix $(obj)/, $(overlay-y))
 
 quiet_cmd_fdtoverlay = DTOVL   $@
@@ -375,6 +379,9 @@ endef
 $(obj)/%.dt.yaml: $(src)/%.dts $(DTC) $(DT_TMP_SCHEMA) FORCE
$(call if_changed_rule,dtc,yaml)
 
+$(obj)/%.dt.yaml: $(src)/%.dtso $(DTC) $(DT_TMP_SCHEMA) FORCE
+   $(call if_changed_rule,dtc,yaml)
+
 dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp)
 
 # Bzip2
-- 
2.25.0.rc1.19.g042ed3e048af

[PATCH V11 1/5] kbuild: Simplify builds with CONFIG_OF_ALL_DTBS

[Viresh Kumar]

We update 'extra-y' based on CONFIG_OF_ALL_DTBS three times. It would be
far more straight forward if we rather update dtb-y to include all .dtb
files if CONFIG_OF_ALL_DTBS is enabled.

Acked-by: Masahiro Yamada 
Signed-off-by: Viresh Kumar 
---
 scripts/Makefile.lib | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index eee59184de64..a2658242d956 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -73,14 +73,13 @@ always-y += $(userprogs-always-y) $(userprogs-always-m)
 
 # DTB
 # If CONFIG_OF_ALL_DTBS is enabled, all DT blobs are built
+dtb-$(CONFIG_OF_ALL_DTBS)   += $(dtb-)
+
 always-y   += $(dtb-y)
-always-$(CONFIG_OF_ALL_DTBS)   += $(dtb-)
 
 ifneq ($(CHECK_DTBS),)
 always-y += $(patsubst %.dtb,%.dt.yaml, $(dtb-y))
 always-y += $(patsubst %.dtbo,%.dt.yaml, $(dtb-y))
-always-$(CONFIG_OF_ALL_DTBS) += $(patsubst %.dtb,%.dt.yaml, $(dtb-))
-always-$(CONFIG_OF_ALL_DTBS) += $(patsubst %.dtbo,%.dt.yaml, $(dtb-))
 endif
 
 # Add subdir path
-- 
2.25.0.rc1.19.g042ed3e048af

[PATCH V11 0/5] dt: Add fdtoverlay rule and statically build unittest

[Viresh Kumar]

Hi,

This patchset adds a generic rule for applying overlays using fdtoverlay
tool and then updates unittests to get built statically using the same.

V10->V11:
- Update patch 4/5 to fix checkpatch warning on spaces and tabs.
- Added Acked-by from Masahiro for patch 2/5.

V9->V10:
- Add a new patch to allow .dtso files.
- Update 2/5 to be more efficient and also generate symbols for base
  files automatically.
- No need to add lines like DTC_FLAGS_foo_base += -@ in patch 5/5.
- Add Ack by Masahiro for 1/5.

V8->V9:
- Added some comment in patch 3/4 based on Frank's suggestions.

V7->V8:
- Patch 1 is new.
- Platforms need to use dtb-y += foo.dtb instead of overlay-y +=
  foo.dtb.
- Use multi_depend instead of .SECONDEXPANSION.
- Use dtb-y for unittest instead of overlay-y.
- Rename the commented dtb filess in unittest Makefile as .dtbo.
- Improved Makefile code (I am learning a lot every day :)

V6->V7:
- Dropped the first 4 patches, already merged.
- Patch 1/3 is new, suggested by Rob and slightly modified by me.
- Adapt Patch 3/3 to the new rule and name the overlay dtbs as .dtbo.

--
Viresh

Rob Herring (1):
  kbuild: Add generic rule to apply fdtoverlay

Viresh Kumar (4):
  kbuild: Simplify builds with CONFIG_OF_ALL_DTBS
  kbuild: Allow .dtso format for overlay source files
  of: unittest: Create overlay_common.dtsi and testcases_common.dtsi
  of: unittest: Statically apply overlays using fdtoverlay

 drivers/of/unittest-data/Makefile | 48 ++
 drivers/of/unittest-data/overlay_base.dts | 90 +-
 drivers/of/unittest-data/overlay_common.dtsi  | 91 +++
 drivers/of/unittest-data/static_base_1.dts|  4 +
 drivers/of/unittest-data/static_base_2.dts|  4 +
 drivers/of/unittest-data/testcases.dts| 23 ++---
 .../of/unittest-data/testcases_common.dtsi| 19 
 .../of/unittest-data/tests-interrupts.dtsi| 11 +--
 scripts/Makefile.lib  | 40 ++--
 9 files changed, 218 insertions(+), 112 deletions(-)
 create mode 100644 drivers/of/unittest-data/overlay_common.dtsi
 create mode 100644 drivers/of/unittest-data/static_base_1.dts
 create mode 100644 drivers/of/unittest-data/static_base_2.dts
 create mode 100644 drivers/of/unittest-data/testcases_common.dtsi


base-commit: a38fd8748464831584a19438cbb3082b5a2dab15
-- 
2.25.0.rc1.19.g042ed3e048af