Re: [PATCH mm] kfence: make reporting sensitive information configurable

[Marco Elver]

On Tue, 9 Feb 2021 at 19:06, Vlastimil Babka  wrote:
> On 2/9/21 4:13 PM, Marco Elver wrote:
> > We cannot rely on CONFIG_DEBUG_KERNEL to decide if we're running a
> > "debug kernel" where we can safely show potentially sensitive
> > information in the kernel log.
> >
> > Therefore, add the option CONFIG_KFENCE_REPORT_SENSITIVE to decide if we
> > should add potentially sensitive information to KFENCE reports. The
> > default behaviour remains unchanged.
> >
> > Signed-off-by: Marco Elver 
>
> Hi,
>
> could we drop this kconfig approach in favour of the boot option proposed 
> here?
> [1] Just do the prints with %p unconditionally and the boot option takes care 
> of
> it? Also Linus mentioned dislike of controlling potential memory leak to be a
> config option [2]
>
> Thanks,
> Vlastimil
>
> [1] https://lore.kernel.org/linux-mm/20210202213633.755469-1-ti...@kernel.org/
> [2]
> https://lore.kernel.org/linux-mm/CAHk-=wgaK4cz=k-jb4p-kpxbv73m9bja2w1w1lr3iu8+nep...@mail.gmail.com/

Is the patch at [1] already in -next? If not I'll wait until it is,
because otherwise KFENCE reports will be pretty useless.

I think it is reasonable to switch to '%p' once we have the boot
option, but doing so while we do not yet have the option doesn't work
for us. We can potentially drop this patch if the boot option patch
will make it into mainline soon. Otherwise my preference would be to
take this patch and revert it with the switch to '%p' when the boot
option has landed.

Thanks,
-- Marco

[tip:locking/core] BUILD SUCCESS 7f82e631d236cafd28518b998c6d4d8dc2ef68f6

[kernel test robot]

 allmodconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparc   defconfig
i386   tinyconfig
i386defconfig
sparcallyesconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
x86_64   randconfig-a006-20210209
x86_64   randconfig-a001-20210209
x86_64   randconfig-a005-20210209
x86_64   randconfig-a004-20210209
x86_64   randconfig-a002-20210209
x86_64   randconfig-a003-20210209
i386 randconfig-a001-20210209
i386 randconfig-a005-20210209
i386 randconfig-a003-20210209
i386 randconfig-a002-20210209
i386 randconfig-a006-20210209
i386 randconfig-a004-20210209
i386 randconfig-a016-20210209
i386 randconfig-a013-20210209
i386 randconfig-a012-20210209
i386 randconfig-a014-20210209
i386 randconfig-a011-20210209
i386 randconfig-a015-20210209
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  rhel-8.3-kbuiltin
x86_64  kexec

clang tested configs:
x86_64   randconfig-a013-20210209
x86_64   randconfig-a014-20210209
x86_64   randconfig-a015-20210209
x86_64   randconfig-a012-20210209
x86_64   randconfig-a016-20210209
x86_64   randconfig-a011-20210209

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

[tip:ras/core] BUILD SUCCESS 9223d0dccb8f8523754122f68316dd1a4f39f7f8

[kernel test robot]

  ppc40x_defconfig
arm socfpga_defconfig
um   x86_64_defconfig
armlart_defconfig
riscvallyesconfig
armkeystone_defconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
nios2   defconfig
nds32 allnoconfig
c6x  allyesconfig
nios2allyesconfig
cskydefconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
parisc  defconfig
s390 allyesconfig
s390 allmodconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparc   defconfig
i386   tinyconfig
i386defconfig
sparcallyesconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc   allnoconfig
x86_64   randconfig-a006-20210209
x86_64   randconfig-a001-20210209
x86_64   randconfig-a005-20210209
x86_64   randconfig-a004-20210209
x86_64   randconfig-a002-20210209
x86_64   randconfig-a003-20210209
i386 randconfig-a001-20210209
i386 randconfig-a005-20210209
i386 randconfig-a003-20210209
i386 randconfig-a002-20210209
i386 randconfig-a006-20210209
i386 randconfig-a004-20210209
i386 randconfig-a016-20210209
i386 randconfig-a013-20210209
i386 randconfig-a012-20210209
i386 randconfig-a014-20210209
i386 randconfig-a011-20210209
i386 randconfig-a015-20210209
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  rhel-8.3-kbuiltin
x86_64  kexec

clang tested configs:
x86_64   randconfig-a013-20210209
x86_64   randconfig-a014-20210209
x86_64   randconfig-a015-20210209
x86_64   randconfig-a012-20210209
x86_64   randconfig-a016-20210209
x86_64   randconfig-a011-20210209

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

[tip:x86/cleanups] BUILD SUCCESS 3228e1dc80983ee1f5d2e533d010b3bd8b50f0e2

[kernel test robot]

 decstation_r4k_defconfig
arm   imx_v4_v5_defconfig
arm am200epdkit_defconfig
microblaze  mmu_defconfig
sh  sh7785lcr_32bit_defconfig
arm orion5x_defconfig
m68kstmark2_defconfig
h8300 edosk2674_defconfig
powerpc mpc832x_rdb_defconfig
powerpc mpc8313_rdb_defconfig
powerpc  ppc40x_defconfig
arm socfpga_defconfig
um   x86_64_defconfig
armlart_defconfig
armkeystone_defconfig
riscvallyesconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
nios2   defconfig
nds32 allnoconfig
c6x  allyesconfig
nios2allyesconfig
cskydefconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
s390 allmodconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparc   defconfig
i386   tinyconfig
i386defconfig
sparcallyesconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc   allnoconfig
x86_64   randconfig-a006-20210209
x86_64   randconfig-a001-20210209
x86_64   randconfig-a005-20210209
x86_64   randconfig-a004-20210209
x86_64   randconfig-a002-20210209
x86_64   randconfig-a003-20210209
i386 randconfig-a001-20210209
i386 randconfig-a005-20210209
i386 randconfig-a003-20210209
i386 randconfig-a002-20210209
i386 randconfig-a006-20210209
i386 randconfig-a004-20210209
i386 randconfig-a016-20210209
i386 randconfig-a013-20210209
i386 randconfig-a012-20210209
i386 randconfig-a014-20210209
i386 randconfig-a011-20210209
i386 randconfig-a015-20210209
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  rhel-8.3-kbuiltin
x86_64  kexec

clang tested configs:
x86_64   randconfig-a013-20210209
x86_64   randconfig-a014-20210209
x86_64   randconfig-a015-20210209
x86_64   randconfig-a012-20210209
x86_64   randconfig-a016-20210209
x86_64   randconfig-a011-20210209

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

[PATCH v2 4/8] cxl/mem: Add basic IOCTL interface

[Ben Widawsky]

Add a straightforward IOCTL that provides a mechanism for userspace to
query the supported memory device commands. CXL commands as they appear
to userspace are described as part of the UAPI kerneldoc. The command
list returned via this IOCTL will contain the full set of commands that
the driver supports, however, some of those commands may not be
available for use by userspace.

Memory device commands first appear in the CXL 2.0 specification. They
are submitted through a mailbox mechanism specified also originally
specified in the CXL 2.0 specification.

The send command allows userspace to issue mailbox commands directly to
the hardware. The list of available commands to send are the output of
the query command. The driver verifies basic properties of the command
and possibly inspect the input (or output) payload to determine whether
or not the command is allowed (or might taint the kernel).

Reported-by: kernel test robot  # bug in earlier revision
Signed-off-by: Ben Widawsky 
Reviewed-by: Dan Williams 
---
 .clang-format |   1 +
 .../userspace-api/ioctl/ioctl-number.rst  |   1 +
 drivers/cxl/mem.c | 291 +-
 include/uapi/linux/cxl_mem.h  | 152 +
 4 files changed, 443 insertions(+), 2 deletions(-)
 create mode 100644 include/uapi/linux/cxl_mem.h

diff --git a/.clang-format b/.clang-format
index 10dc5a9a61b3..3f11c8901b43 100644
--- a/.clang-format
+++ b/.clang-format
@@ -109,6 +109,7 @@ ForEachMacros:
   - 'css_for_each_child'
   - 'css_for_each_descendant_post'
   - 'css_for_each_descendant_pre'
+  - 'cxl_for_each_cmd'
   - 'device_for_each_child_node'
   - 'dma_fence_chain_for_each'
   - 'do_for_each_ftrace_op'
diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst 
b/Documentation/userspace-api/ioctl/ioctl-number.rst
index a4c75a28c839..6eb8e634664d 100644
--- a/Documentation/userspace-api/ioctl/ioctl-number.rst
+++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
@@ -352,6 +352,7 @@ Code  Seq#Include File  
 Comments
  

 0xCC  00-0F  drivers/misc/ibmvmc.h   pseries 
VMC driver
 0xCD  01 linux/reiserfs_fs.h
+0xCE  01-02  uapi/linux/cxl_mem.hCompute 
Express Link Memory Devices
 0xCF  02 fs/cifs/ioctl.c
 0xDB  00-0F  drivers/char/mwave/mwavepub.h
 0xDD  00-3F  ZFCP 
device driver see drivers/s390/scsi/
diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
index 8bbd2495e237..ce65630bb75e 100644
--- a/drivers/cxl/mem.c
+++ b/drivers/cxl/mem.c
@@ -1,5 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0-only
 /* Copyright(c) 2020 Intel Corporation. All rights reserved. */
+#include 
 #include 
 #include 
 #include 
@@ -39,6 +40,7 @@
 #define CXL_MAILBOX_TIMEOUT_MS (2 * HZ)
 
 enum opcode {
+   CXL_MBOX_OP_INVALID = 0x,
CXL_MBOX_OP_IDENTIFY= 0x4000,
CXL_MBOX_OP_MAX = 0x1
 };
@@ -90,9 +92,57 @@ struct cxl_memdev {
 static int cxl_mem_major;
 static DEFINE_IDA(cxl_memdev_ida);
 
+/**
+ * struct cxl_mem_command - Driver representation of a memory device command
+ * @info: Command information as it exists for the UAPI
+ * @opcode: The actual bits used for the mailbox protocol
+ * @flags: Set of flags reflecting the state of the command.
+ *
+ *  * %CXL_CMD_FLAG_MANDATORY: Hardware must support this command. This flag is
+ *only used internally by the driver for sanity checking.
+ *
+ * The cxl_mem_command is the driver's internal representation of commands that
+ * are supported by the driver. Some of these commands may not be supported by
+ * the hardware. The driver will use @info to validate the fields passed in by
+ * the user then submit the @opcode to the hardware.
+ *
+ * See struct cxl_command_info.
+ */
+struct cxl_mem_command {
+   struct cxl_command_info info;
+   enum opcode opcode;
+};
+
+#define CXL_CMD(_id, _flags, sin, sout)
\
+   [CXL_MEM_COMMAND_ID_##_id] = { \
+   .info = {  \
+   .id = CXL_MEM_COMMAND_ID_##_id,\
+   .flags = CXL_MEM_COMMAND_FLAG_##_flags,\
+   .size_in = sin,\
+   .size_out = sout,  \
+   }, \
+   .opcode = CXL_MBOX_OP_##_id,   \
+   }
+
+/*
+ * This table defines the supported mailbox commands for the driver. This table
+ * is made up of a UAPI 

[tip:x86/urgent] BUILD SUCCESS 256b92af784d5043eeb7d559b6d5963dcc2ecb10

[kernel test robot]

  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
x86_64   randconfig-a006-20210209
x86_64   randconfig-a001-20210209
x86_64   randconfig-a005-20210209
x86_64   randconfig-a004-20210209
x86_64   randconfig-a002-20210209
x86_64   randconfig-a003-20210209
i386 randconfig-a001-20210209
i386 randconfig-a005-20210209
i386 randconfig-a003-20210209
i386 randconfig-a002-20210209
i386 randconfig-a006-20210209
i386 randconfig-a004-20210209
i386 randconfig-a016-20210209
i386 randconfig-a013-20210209
i386 randconfig-a012-20210209
i386 randconfig-a014-20210209
i386 randconfig-a011-20210209
i386 randconfig-a015-20210209
riscvallyesconfig
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  rhel-8.3-kbuiltin
x86_64  kexec

clang tested configs:
x86_64   randconfig-a013-20210209
x86_64   randconfig-a014-20210209
x86_64   randconfig-a015-20210209
x86_64   randconfig-a012-20210209
x86_64   randconfig-a016-20210209
x86_64   randconfig-a011-20210209

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

[PATCH v2 1/8] cxl/mem: Introduce a driver for CXL-2.0-Type-3 endpoints

[Ben Widawsky]

From: Dan Williams 

The CXL.mem protocol allows a device to act as a provider of "System
RAM" and/or "Persistent Memory" that is fully coherent as if the memory
was attached to the typical CPU memory controller.

With the CXL-2.0 specification a PCI endpoint can implement a "Type-3"
device interface and give the operating system control over "Host
Managed Device Memory". See section 2.3 Type 3 CXL Device.

The memory range exported by the device may optionally be described by
the platform firmware memory map, or by infrastructure like LIBNVDIMM to
provision persistent memory capacity from one, or more, CXL.mem devices.

A pre-requisite for Linux-managed memory-capacity provisioning is this
cxl_mem driver that can speak the mailbox protocol defined in section
8.2.8.4 Mailbox Registers.

For now just land the initial driver boiler-plate and Documentation/
infrastructure.

Link: https://www.computeexpresslink.org/download-the-specification
Cc: Jonathan Corbet 
Signed-off-by: Dan Williams 
Signed-off-by: Ben Widawsky 
Acked-by: David Rientjes  (v1)
---
 Documentation/driver-api/cxl/index.rst| 12 
 .../driver-api/cxl/memory-devices.rst | 29 +
 Documentation/driver-api/index.rst|  1 +
 drivers/Kconfig   |  1 +
 drivers/Makefile  |  1 +
 drivers/cxl/Kconfig   | 35 +++
 drivers/cxl/Makefile  |  4 ++
 drivers/cxl/mem.c | 63 +++
 drivers/cxl/pci.h | 18 ++
 include/linux/pci_ids.h   |  1 +
 10 files changed, 165 insertions(+)
 create mode 100644 Documentation/driver-api/cxl/index.rst
 create mode 100644 Documentation/driver-api/cxl/memory-devices.rst
 create mode 100644 drivers/cxl/Kconfig
 create mode 100644 drivers/cxl/Makefile
 create mode 100644 drivers/cxl/mem.c
 create mode 100644 drivers/cxl/pci.h

diff --git a/Documentation/driver-api/cxl/index.rst 
b/Documentation/driver-api/cxl/index.rst
new file mode 100644
index ..036e49553542
--- /dev/null
+++ b/Documentation/driver-api/cxl/index.rst
@@ -0,0 +1,12 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+
+Compute Express Link
+
+
+.. toctree::
+   :maxdepth: 1
+
+   memory-devices
+
+.. only::  subproject and html
diff --git a/Documentation/driver-api/cxl/memory-devices.rst 
b/Documentation/driver-api/cxl/memory-devices.rst
new file mode 100644
index ..43177e700d62
--- /dev/null
+++ b/Documentation/driver-api/cxl/memory-devices.rst
@@ -0,0 +1,29 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: 
+
+===
+Compute Express Link Memory Devices
+===
+
+A Compute Express Link Memory Device is a CXL component that implements the
+CXL.mem protocol. It contains some amount of volatile memory, persistent 
memory,
+or both. It is enumerated as a PCI device for configuration and passing
+messages over an MMIO mailbox. Its contribution to the System Physical
+Address space is handled via HDM (Host Managed Device Memory) decoders
+that optionally define a device's contribution to an interleaved address
+range across multiple devices underneath a host-bridge or interleaved
+across host-bridges.
+
+Driver Infrastructure
+=
+
+This section covers the driver infrastructure for a CXL memory device.
+
+CXL Memory Device
+-
+
+.. kernel-doc:: drivers/cxl/mem.c
+   :doc: cxl mem
+
+.. kernel-doc:: drivers/cxl/mem.c
+   :internal:
diff --git a/Documentation/driver-api/index.rst 
b/Documentation/driver-api/index.rst
index 2456d0a97ed8..d246a18fd78f 100644
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@ -35,6 +35,7 @@ available subsections can be seen below.
usb/index
firewire
pci/index
+   cxl/index
spi
i2c
ipmb
diff --git a/drivers/Kconfig b/drivers/Kconfig
index dcecc9f6e33f..62c753a73651 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -6,6 +6,7 @@ menu "Device Drivers"
 source "drivers/amba/Kconfig"
 source "drivers/eisa/Kconfig"
 source "drivers/pci/Kconfig"
+source "drivers/cxl/Kconfig"
 source "drivers/pcmcia/Kconfig"
 source "drivers/rapidio/Kconfig"
 
diff --git a/drivers/Makefile b/drivers/Makefile
index fd11b9ac4cc3..678ea810410f 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -73,6 +73,7 @@ obj-$(CONFIG_NVM) += lightnvm/
 obj-y  += base/ block/ misc/ mfd/ nfc/
 obj-$(CONFIG_LIBNVDIMM)+= nvdimm/
 obj-$(CONFIG_DAX)  += dax/
+obj-$(CONFIG_CXL_BUS)  += cxl/
 obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf/
 obj-$(CONFIG_NUBUS)+= nubus/
 obj-y  += macintosh/
diff --git a/drivers/cxl/Kconfig b/drivers/cxl/Kconfig
new file mode 100644
index ..9e80b311e928
--- /dev/null
+++ 

[PATCH v2 2/8] cxl/mem: Find device capabilities

[Ben Widawsky]

Provide enough functionality to utilize the mailbox of a memory device.
The mailbox is used to interact with the firmware running on the memory
device. The flow is proven with one implemented command, "identify".
Because the class code has already told the driver this is a memory
device and the identify command is mandatory.

CXL devices contain an array of capabilities that describe the
interactions software can have with the device or firmware running on
the device. A CXL compliant device must implement the device status and
the mailbox capability. Additionally, a CXL compliant memory device must
implement the memory device capability. Each of the capabilities can
[will] provide an offset within the MMIO region for interacting with the
CXL device.

The capabilities tell the driver how to find and map the register space
for CXL Memory Devices. The registers are required to utilize the CXL
spec defined mailbox interface. The spec outlines two mailboxes, primary
and secondary. The secondary mailbox is earmarked for system firmware,
and not handled in this driver.

Primary mailboxes are capable of generating an interrupt when submitting
a background command. That implementation is saved for a later time.

Link: https://www.computeexpresslink.org/download-the-specification
Signed-off-by: Ben Widawsky 
Reviewed-by: Dan Williams 
---
 drivers/cxl/Kconfig   |  14 +
 drivers/cxl/cxl.h |  93 +++
 drivers/cxl/mem.c | 511 +-
 drivers/cxl/pci.h |  13 +
 include/uapi/linux/pci_regs.h |   1 +
 5 files changed, 630 insertions(+), 2 deletions(-)
 create mode 100644 drivers/cxl/cxl.h

diff --git a/drivers/cxl/Kconfig b/drivers/cxl/Kconfig
index 9e80b311e928..c4ba3aa0a05d 100644
--- a/drivers/cxl/Kconfig
+++ b/drivers/cxl/Kconfig
@@ -32,4 +32,18 @@ config CXL_MEM
  Chapter 2.3 Type 3 CXL Device in the CXL 2.0 specification.
 
  If unsure say 'm'.
+
+config CXL_MEM_INSECURE_DEBUG
+   bool "CXL.mem debugging"
+   depends on CXL_MEM
+   help
+ Enable debug of all CXL command payloads.
+
+ Some CXL devices and controllers support encryption and other
+ security features. The payloads for the commands that enable
+ those features may contain sensitive clear-text security
+ material. Disable debug of those command payloads by default.
+ If you are a kernel developer actively working on CXL
+ security enabling say Y, otherwise say N.
+
 endif
diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
new file mode 100644
index ..745f5e0bfce3
--- /dev/null
+++ b/drivers/cxl/cxl.h
@@ -0,0 +1,93 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/* Copyright(c) 2020 Intel Corporation. */
+
+#ifndef __CXL_H__
+#define __CXL_H__
+
+#include 
+#include 
+#include 
+
+/* CXL 2.0 8.2.8.1 Device Capabilities Array Register */
+#define CXLDEV_CAP_ARRAY_OFFSET 0x0
+#define   CXLDEV_CAP_ARRAY_CAP_ID 0
+#define   CXLDEV_CAP_ARRAY_ID_MASK GENMASK(15, 0)
+#define   CXLDEV_CAP_ARRAY_COUNT_MASK GENMASK(47, 32)
+/* CXL 2.0 8.2.8.2.1 CXL Device Capabilities */
+#define CXLDEV_CAP_CAP_ID_DEVICE_STATUS 0x1
+#define CXLDEV_CAP_CAP_ID_PRIMARY_MAILBOX 0x2
+#define CXLDEV_CAP_CAP_ID_SECONDARY_MAILBOX 0x3
+#define CXLDEV_CAP_CAP_ID_MEMDEV 0x4000
+
+/* CXL 2.0 8.2.8.4 Mailbox Registers */
+#define CXLDEV_MBOX_CAPS_OFFSET 0x00
+#define   CXLDEV_MBOX_CAP_PAYLOAD_SIZE_MASK GENMASK(4, 0)
+#define CXLDEV_MBOX_CTRL_OFFSET 0x04
+#define   CXLDEV_MBOX_CTRL_DOORBELL BIT(0)
+#define CXLDEV_MBOX_CMD_OFFSET 0x08
+#define   CXLDEV_MBOX_CMD_COMMAND_OPCODE_MASK GENMASK(15, 0)
+#define   CXLDEV_MBOX_CMD_PAYLOAD_LENGTH_MASK GENMASK(36, 16)
+#define CXLDEV_MBOX_STATUS_OFFSET 0x10
+#define   CXLDEV_MBOX_STATUS_RET_CODE_MASK GENMASK(47, 32)
+#define CXLDEV_MBOX_BG_CMD_STATUS_OFFSET 0x18
+#define CXLDEV_MBOX_PAYLOAD_OFFSET 0x20
+
+/* CXL 2.0 8.2.8.5.1.1 Memory Device Status Register */
+#define CXLMDEV_STATUS_OFFSET 0x0
+#define   CXLMDEV_DEV_FATAL BIT(0)
+#define   CXLMDEV_FW_HALT BIT(1)
+#define   CXLMDEV_STATUS_MEDIA_STATUS_MASK GENMASK(3, 2)
+#define CXLMDEV_MS_NOT_READY 0
+#define CXLMDEV_MS_READY 1
+#define CXLMDEV_MS_ERROR 2
+#define CXLMDEV_MS_DISABLED 3
+#define CXLMDEV_READY(status)  
\
+   (FIELD_GET(CXLMDEV_STATUS_MEDIA_STATUS_MASK, status) ==\
+CXLMDEV_MS_READY)
+#define   CXLMDEV_MBOX_IF_READY BIT(4)
+#define   CXLMDEV_RESET_NEEDED_MASK GENMASK(7, 5)
+#define CXLMDEV_RESET_NEEDED_NOT 0
+#define CXLMDEV_RESET_NEEDED_COLD 1
+#define CXLMDEV_RESET_NEEDED_WARM 2
+#define CXLMDEV_RESET_NEEDED_HOT 3
+#define CXLMDEV_RESET_NEEDED_CXL 4
+#define CXLMDEV_RESET_NEEDED(status)   
\
+   (FIELD_GET(CXLMDEV_RESET_NEEDED_MASK, status) !=   \
+CXLMDEV_RESET_NEEDED_NOT)
+
+/**
+ * struct cxl_mem - A CXL memory device
+ * @pdev: The PCI 

[PATCH v2 3/8] cxl/mem: Register CXL memX devices

[Ben Widawsky]

From: Dan Williams 

Create the /sys/bus/cxl hierarchy to enumerate:

* Memory Devices (per-endpoint control devices)

* Memory Address Space Devices (platform address ranges with
  interleaving, performance, and persistence attributes)

* Memory Regions (active provisioned memory from an address space device
  that is in use as System RAM or delegated to libnvdimm as Persistent
  Memory regions).

For now, only the per-endpoint control devices are registered on the
'cxl' bus. However, going forward it will provide a mechanism to
coordinate cross-device interleave.

Signed-off-by: Dan Williams 
Signed-off-by: Ben Widawsky 
---
 Documentation/ABI/testing/sysfs-bus-cxl   |  26 ++
 .../driver-api/cxl/memory-devices.rst |  17 +
 drivers/cxl/Makefile  |   3 +
 drivers/cxl/bus.c |  29 ++
 drivers/cxl/cxl.h |   4 +
 drivers/cxl/mem.c | 301 +-
 6 files changed, 378 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-cxl
 create mode 100644 drivers/cxl/bus.c

diff --git a/Documentation/ABI/testing/sysfs-bus-cxl 
b/Documentation/ABI/testing/sysfs-bus-cxl
new file mode 100644
index ..2fe7490ad6a8
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-cxl
@@ -0,0 +1,26 @@
+What:  /sys/bus/cxl/devices/memX/firmware_version
+Date:  December, 2020
+KernelVersion: v5.12
+Contact:   linux-...@vger.kernel.org
+Description:
+   (RO) "FW Revision" string as reported by the Identify
+   Memory Device Output Payload in the CXL-2.0
+   specification.
+
+What:  /sys/bus/cxl/devices/memX/ram/size
+Date:  December, 2020
+KernelVersion: v5.12
+Contact:   linux-...@vger.kernel.org
+Description:
+   (RO) "Volatile Only Capacity" as bytes. Represents the
+   identically named field in the Identify Memory Device Output
+   Payload in the CXL-2.0 specification.
+
+What:  /sys/bus/cxl/devices/memX/pmem/size
+Date:  December, 2020
+KernelVersion: v5.12
+Contact:   linux-...@vger.kernel.org
+Description:
+   (RO) "Persistent Only Capacity" as bytes. Represents the
+   identically named field in the Identify Memory Device Output
+   Payload in the CXL-2.0 specification.
diff --git a/Documentation/driver-api/cxl/memory-devices.rst 
b/Documentation/driver-api/cxl/memory-devices.rst
index 43177e700d62..1bad466f9167 100644
--- a/Documentation/driver-api/cxl/memory-devices.rst
+++ b/Documentation/driver-api/cxl/memory-devices.rst
@@ -27,3 +27,20 @@ CXL Memory Device
 
 .. kernel-doc:: drivers/cxl/mem.c
:internal:
+
+CXL Bus
+---
+.. kernel-doc:: drivers/cxl/bus.c
+   :doc: cxl bus
+
+External Interfaces
+===
+
+CXL IOCTL Interface
+---
+
+.. kernel-doc:: include/uapi/linux/cxl_mem.h
+   :doc: UAPI
+
+.. kernel-doc:: include/uapi/linux/cxl_mem.h
+   :internal:
diff --git a/drivers/cxl/Makefile b/drivers/cxl/Makefile
index 4a30f7c3fc4a..a314a1891f4d 100644
--- a/drivers/cxl/Makefile
+++ b/drivers/cxl/Makefile
@@ -1,4 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_CXL_BUS) += cxl_bus.o
 obj-$(CONFIG_CXL_MEM) += cxl_mem.o
 
+ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE=CXL
+cxl_bus-y := bus.o
 cxl_mem-y := mem.o
diff --git a/drivers/cxl/bus.c b/drivers/cxl/bus.c
new file mode 100644
index ..58f74796d525
--- /dev/null
+++ b/drivers/cxl/bus.c
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Copyright(c) 2020 Intel Corporation. All rights reserved. */
+#include 
+#include 
+
+/**
+ * DOC: cxl bus
+ *
+ * The CXL bus provides namespace for control devices and a rendezvous
+ * point for cross-device interleave coordination.
+ */
+struct bus_type cxl_bus_type = {
+   .name = "cxl",
+};
+EXPORT_SYMBOL_GPL(cxl_bus_type);
+
+static __init int cxl_bus_init(void)
+{
+   return bus_register(_bus_type);
+}
+
+static void cxl_bus_exit(void)
+{
+   bus_unregister(_bus_type);
+}
+
+module_init(cxl_bus_init);
+module_exit(cxl_bus_exit);
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
index 745f5e0bfce3..b3c56fa6e126 100644
--- a/drivers/cxl/cxl.h
+++ b/drivers/cxl/cxl.h
@@ -3,6 +3,7 @@
 
 #ifndef __CXL_H__
 #define __CXL_H__
+#include 
 
 #include 
 #include 
@@ -55,6 +56,7 @@
(FIELD_GET(CXLMDEV_RESET_NEEDED_MASK, status) !=   \
 CXLMDEV_RESET_NEEDED_NOT)
 
+struct cxl_memdev;
 /**
  * struct cxl_mem - A CXL memory device
  * @pdev: The PCI device associated with this CXL device.
@@ -72,6 +74,7 @@
 struct cxl_mem {
struct pci_dev *pdev;
void __iomem *regs;
+   struct cxl_memdev *cxlmd;
 
void __iomem *status_regs;
void __iomem *mbox_regs;
@@ -90,4 +93,5 @@ struct cxl_mem {
} ram;
 };
 
+extern struct bus_type cxl_bus_type;
 #endif 

[PATCH v2 0/8] CXL 2.0 Support

[Ben Widawsky]

# Changes since v1 [1]

   * Squash together several other patches (Ben)
   * Make register locator only search the DVSEC size. Bug fix. (Ben)
   * Get rid of anonymous structs in send UAPI (Ben)
   * Rename "MB" to "MBOX" in defines (Ben)
   * Dynamically allocate enable_cmds bitmask (Ben)
   * Async probe (Dan)
   * Remove get_live_device() (Dan)
   * CXL_MAILBOX_TIMEOUT_MS 2*HZ instead of runtime conversion (Dan)
   * Reword RAW Kconfig help (Dan)
   * Move IOCTL handlers to their own functions (Dan)
   * Remove HIDDEN flag (Dan)
   * Remove MUTEX flag (Dan)
   * Get rid of const info in mem_command (Dan)
   * Remove useless mbox initialiazation in user commands (Dan)
   * Rename DEBUG_UUID to VENDOR_DEBUG_UUID (Dan)
   * Remove dev_info of enabled commands (Dan)
   * Get rid of MANDATORY and PSEUDO flags (Dan)
   * Clarify cmd vs. mbox_cmd in send by removing cmd (Dan)
 * This results in removal of some very unlikely debug messages.
   * Reword Kconfig (David)
   * Cap payload size max to 1M to match spec (David)
   ** Driver still binds, but IOCTls fail if too large.
   * s/US/MS for timeout (David)
   * Fix comment indenting to denote, not part of spec (David)
   * Use struct initializer for mailbox command (David)
   * Add units to sysfs ABI documentation (David)
   * Use FIELD_GET for register locator parsing (hch)
   * Use FIELD_GET/SET directly instead of wrappers (hch)
   * Remove cpp guards (hch)
   * Drop register read/write helpers (hch)
   * Squash together device capability patches (hch)
   * Move PCI_CLASS_MEMORY_CXL to pci_ids.h (hch)
   * Use file_inode instead of file->private_data (hch)
   * Hide RAW commands behind CONFIG option (Konrad)
   * Include security_locked_down() check (Konrad)
   * Extend past 80 characters in certain places (Konrad)
   * Remove magic numbers of register locator enumeration (Konrad)
   * Fix packing for send UAPI (Konrad)

---

In addition to the mailing list, please feel free to use #cxl on oftc IRC for
discussion.

---

# Summary

Introduce support for “type-3” memory devices defined in the Compute Express
Link (CXL) 2.0 specification [2]. Specifically, these are the memory devices
defined by section 8.2.8.5 of the CXL 2.0 spec. A reference implementation
emulating these devices has been submitted to the QEMU mailing list [3] and is
available on gitlab [4], but will move to a shared tree on kernel.org after
initial acceptance. “Type-3” is a CXL device that acts as a memory expander for
RAM or Persistent Memory. The device might be interleaved with other CXL devices
in a given physical address range.

In addition to the core functionality of discovering the spec defined registers
and resources, introduce a CXL device model that will be the foundation for
translating CXL capabilities into existing Linux infrastructure for Persistent
Memory and other memory devices. For now, this only includes support for the
management command mailbox the surfacing of type-3 devices. These control
devices fill the role of “DIMMs” / nmemX memory-devices in LIBNVDIMM terms.

## Userspace Interaction

Interaction with the driver and type-3 devices via the CXL drivers is introduced
in this patch series and considered stable ABI. They include

   * sysfs - Documentation/ABI/testing/sysfs-bus-cxl
   * IOCTL - Documentation/driver-api/cxl/memory-devices.rst
   * debugfs - Documentation/ABI/testing/debugfs-debug

Work is in process to add support for CXL interactions to the ndctl project [5]

### Development plans

One of the unique challenges that CXL imposes on the Linux driver model is that
it requires the operating system to perform physical address space management
interleaved across devices and bridges. Whereas LIBNVDIMM handles a list of
established static persistent memory address ranges (for example from the ACPI
NFIT), CXL introduces hotplug and the concept of allocating address space to
instantiate persistent memory ranges. This is similar to PCI in the sense that
the platform establishes the MMIO range for PCI BARs to be allocated, but it is
significantly complicated by the fact that a given device can optionally be
interleaved with other devices and can participate in several interleave-sets at
once. LIBNVDIMM handled something like this with the aliasing between PMEM and
BLOCK-WINDOW mode, but CXL adds flexibility to alias DEVICE MEMORY through up to
10 decoders per device.

All of the above needs to be enabled with respect to PCI hotplug events on
Type-3 memory device which needs hooks to determine if a given device is
contributing to a "System RAM" address range that is unable to be unplugged. In
other words CXL ties PCI hotplug to Memory Hotplug and PCI hotplug needs to be
able to negotiate with memory hotplug.  In the medium term the implications of
CXL hotplug vs ACPI SRAT/SLIT/HMAT need to be reconciled. One capability that
seems to be needed is either the dynamic allocation of new memory nodes, or
default initializing extra pgdat instances beyond what 

[tip:sched/core] BUILD SUCCESS 936eba768e7d4701373115977db1dbe954b6f6af

[kernel test robot]

armkeystone_defconfig
riscvallyesconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
nios2   defconfig
nds32 allnoconfig
c6x  allyesconfig
nios2allyesconfig
cskydefconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
parisc  defconfig
s390 allyesconfig
s390 allmodconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparc   defconfig
i386   tinyconfig
i386defconfig
sparcallyesconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
x86_64   randconfig-a006-20210209
x86_64   randconfig-a001-20210209
x86_64   randconfig-a005-20210209
x86_64   randconfig-a004-20210209
x86_64   randconfig-a002-20210209
x86_64   randconfig-a003-20210209
i386 randconfig-a001-20210209
i386 randconfig-a005-20210209
i386 randconfig-a003-20210209
i386 randconfig-a002-20210209
i386 randconfig-a006-20210209
i386 randconfig-a004-20210209
i386 randconfig-a016-20210209
i386 randconfig-a013-20210209
i386 randconfig-a012-20210209
i386 randconfig-a014-20210209
i386 randconfig-a011-20210209
i386 randconfig-a015-20210209
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  rhel-8.3-kbuiltin
x86_64  kexec

clang tested configs:
x86_64   randconfig-a013-20210209
x86_64   randconfig-a014-20210209
x86_64   randconfig-a015-20210209
x86_64   randconfig-a012-20210209
x86_64   randconfig-a016-20210209
x86_64   randconfig-a011-20210209

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

[tip:timers/urgent] BUILD SUCCESS 24c242ec7abb3d21fa0b1da6bb251521dc1717b5

[kernel test robot]

  multi_defconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
nios2   defconfig
nds32 allnoconfig
c6x  allyesconfig
nios2allyesconfig
cskydefconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
parisc  defconfig
s390 allyesconfig
s390 allmodconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparc   defconfig
i386   tinyconfig
i386defconfig
sparcallyesconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
x86_64   randconfig-a006-20210209
x86_64   randconfig-a001-20210209
x86_64   randconfig-a005-20210209
x86_64   randconfig-a004-20210209
x86_64   randconfig-a002-20210209
x86_64   randconfig-a003-20210209
i386 randconfig-a001-20210209
i386 randconfig-a005-20210209
i386 randconfig-a003-20210209
i386 randconfig-a002-20210209
i386 randconfig-a006-20210209
i386 randconfig-a004-20210209
i386 randconfig-a016-20210209
i386 randconfig-a013-20210209
i386 randconfig-a012-20210209
i386 randconfig-a014-20210209
i386 randconfig-a011-20210209
i386 randconfig-a015-20210209
riscvallyesconfig
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  rhel-8.3-kbuiltin
x86_64  kexec

clang tested configs:
x86_64   randconfig-a013-20210209
x86_64   randconfig-a014-20210209
x86_64   randconfig-a015-20210209
x86_64   randconfig-a012-20210209
x86_64   randconfig-a016-20210209
x86_64   randconfig-a011-20210209

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

[tip:master] BUILD SUCCESS 4e2c97c69a3b1e5f303e3de8f4353cbd9b55123b

[kernel test robot]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git master
branch HEAD: 4e2c97c69a3b1e5f303e3de8f4353cbd9b55123b  Merge remote-tracking 
branch 'tip/x86/sgx' into tip-master

elapsed time: 722m

configs tested: 100
configs skipped: 2

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

gcc tested configs:
arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
m68k   m5208evb_defconfig
shedosk7760_defconfig
sparcalldefconfig
arm palmz72_defconfig
h8300h8300h-sim_defconfig
powerpc  ep88xc_defconfig
arm  zx_defconfig
mips  rb532_defconfig
powerpc mpc836x_mds_defconfig
powerpc mpc836x_rdk_defconfig
arm at91_dt_defconfig
arm   aspeed_g5_defconfig
arm   cns3420vb_defconfig
powerpcwarp_defconfig
openrisc simple_smp_defconfig
powerpc ep8248e_defconfig
sh  sdk7786_defconfig
m68kmac_defconfig
armneponset_defconfig
mips  rm200_defconfig
powerpc  bamboo_defconfig
x86_64   alldefconfig
powerpc mpc85xx_cds_defconfig
riscvnommu_k210_defconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
nds32   defconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
nios2allyesconfig
h8300allyesconfig
arc defconfig
xtensa   allyesconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
s390 allmodconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparc   defconfig
i386   tinyconfig
i386defconfig
sparcallyesconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
x86_64   randconfig-a006-20210209
x86_64   randconfig-a001-20210209
x86_64   randconfig-a005-20210209
x86_64   randconfig-a004-20210209
x86_64   randconfig-a002-20210209
x86_64   randconfig-a003-20210209
i386 randconfig-a001-20210209
i386 randconfig-a005-20210209
i386 randconfig-a003-20210209
i386 randconfig-a002-20210209
i386 randconfig-a006-20210209
i386 randconfig-a004-20210209
i386 randconfig-a016-20210209
i386 randconfig-a013-20210209
i386 randconfig-a012-20210209
i386 randconfig-a014-20210209
i386 randconfig-a011-20210209
i386 randconfig-a015-20210209
riscvallyesconfig
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  rhel-8.3-kbuiltin
x86_64  kexec

clang tested configs:
x86_64   randconfig-a013-20210209
x86_64   randconfig-a014-20210209
x86_64   randconfig-a015-20210209
x86_64   randconfig-a012-20210209
x86_64   randconfig-a016-20210209
x86_64   randconfig-a011-20210209

[tip:timers/core] BUILD SUCCESS 174bcc691f44fdd05046c694fc650933819f72c7

[kernel test robot]

 allmodconfig
m68kdefconfig
nios2   defconfig
nds32 allnoconfig
c6x  allyesconfig
cskydefconfig
alphaallyesconfig
nios2allyesconfig
h8300allyesconfig
arc defconfig
xtensa   allyesconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
s390 allmodconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparc   defconfig
i386   tinyconfig
i386defconfig
sparcallyesconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
x86_64   randconfig-a006-20210209
x86_64   randconfig-a001-20210209
x86_64   randconfig-a005-20210209
x86_64   randconfig-a004-20210209
x86_64   randconfig-a002-20210209
x86_64   randconfig-a003-20210209
i386 randconfig-a001-20210209
i386 randconfig-a005-20210209
i386 randconfig-a003-20210209
i386 randconfig-a002-20210209
i386 randconfig-a006-20210209
i386 randconfig-a004-20210209
i386 randconfig-a016-20210209
i386 randconfig-a013-20210209
i386 randconfig-a012-20210209
i386 randconfig-a014-20210209
i386 randconfig-a011-20210209
i386 randconfig-a015-20210209
riscvallyesconfig
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  rhel-8.3-kbuiltin
x86_64  kexec

clang tested configs:
x86_64   randconfig-a013-20210209
x86_64   randconfig-a014-20210209
x86_64   randconfig-a015-20210209
x86_64   randconfig-a012-20210209
x86_64   randconfig-a016-20210209
x86_64   randconfig-a011-20210209

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

[tip:core/urgent] BUILD SUCCESS 36a6c843fd0d8e02506681577e96dabd203dd8e8

[kernel test robot]

defconfig
sparcallyesconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
x86_64   randconfig-a006-20210209
x86_64   randconfig-a001-20210209
x86_64   randconfig-a005-20210209
x86_64   randconfig-a004-20210209
x86_64   randconfig-a002-20210209
x86_64   randconfig-a003-20210209
i386 randconfig-a001-20210209
i386 randconfig-a005-20210209
i386 randconfig-a003-20210209
i386 randconfig-a002-20210209
i386 randconfig-a006-20210209
i386 randconfig-a004-20210209
i386 randconfig-a016-20210209
i386 randconfig-a013-20210209
i386 randconfig-a012-20210209
i386 randconfig-a014-20210209
i386 randconfig-a011-20210209
i386 randconfig-a015-20210209
riscvallyesconfig
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  rhel-8.3-kbuiltin
x86_64  kexec

clang tested configs:
x86_64   randconfig-a013-20210209
x86_64   randconfig-a014-20210209
x86_64   randconfig-a015-20210209
x86_64   randconfig-a012-20210209
x86_64   randconfig-a016-20210209
x86_64   randconfig-a011-20210209

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

[tip:sched/urgent] BUILD SUCCESS 2452483d9546de1c540f330469dc4042ff089731

[kernel test robot]

onfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
nios2   defconfig
nds32 allnoconfig
c6x  allyesconfig
cskydefconfig
alphaallyesconfig
nios2allyesconfig
h8300allyesconfig
arc defconfig
xtensa   allyesconfig
parisc  defconfig
s390 allyesconfig
s390 allmodconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparc   defconfig
i386   tinyconfig
i386defconfig
sparcallyesconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
x86_64   randconfig-a006-20210209
x86_64   randconfig-a001-20210209
x86_64   randconfig-a005-20210209
x86_64   randconfig-a004-20210209
x86_64   randconfig-a002-20210209
x86_64   randconfig-a003-20210209
i386 randconfig-a001-20210209
i386 randconfig-a005-20210209
i386 randconfig-a003-20210209
i386 randconfig-a002-20210209
i386 randconfig-a006-20210209
i386 randconfig-a004-20210209
i386 randconfig-a016-20210209
i386 randconfig-a013-20210209
i386 randconfig-a012-20210209
i386 randconfig-a014-20210209
i386 randconfig-a011-20210209
i386 randconfig-a015-20210209
riscvallyesconfig
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  rhel-8.3-kbuiltin
x86_64  kexec

clang tested configs:
x86_64   randconfig-a013-20210209
x86_64   randconfig-a014-20210209
x86_64   randconfig-a015-20210209
x86_64   randconfig-a012-20210209
x86_64   randconfig-a016-20210209
x86_64   randconfig-a011-20210209

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

[tip:irq/urgent] BUILD SUCCESS 4c7bcb51ae25f79e3733982e5d0cd8ce8640ddfc

[kernel test robot]

 mpc8313_rdb_defconfig
powerpc  ppc40x_defconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
nios2   defconfig
nds32 allnoconfig
c6x  allyesconfig
nios2allyesconfig
cskydefconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
s390 allmodconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparc   defconfig
i386   tinyconfig
i386defconfig
sparcallyesconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc   allnoconfig
x86_64   randconfig-a006-20210209
x86_64   randconfig-a001-20210209
x86_64   randconfig-a005-20210209
x86_64   randconfig-a004-20210209
x86_64   randconfig-a002-20210209
x86_64   randconfig-a003-20210209
i386 randconfig-a001-20210209
i386 randconfig-a005-20210209
i386 randconfig-a003-20210209
i386 randconfig-a002-20210209
i386 randconfig-a006-20210209
i386 randconfig-a004-20210209
i386 randconfig-a016-20210209
i386 randconfig-a013-20210209
i386 randconfig-a012-20210209
i386 randconfig-a014-20210209
i386 randconfig-a011-20210209
i386 randconfig-a015-20210209
riscvallyesconfig
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  rhel-8.3-kbuiltin
x86_64  kexec

clang tested configs:
x86_64   randconfig-a013-20210209
x86_64   randconfig-a014-20210209
x86_64   randconfig-a015-20210209
x86_64   randconfig-a012-20210209
x86_64   randconfig-a016-20210209
x86_64   randconfig-a011-20210209

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

[tip:x86/sgx] BUILD SUCCESS 848477782bfa2b6aec738045246abd6cd104006c

[kernel test robot]

vdk_hs38_defconfig
powerpc sequoia_defconfig
powerpc taishan_defconfig
mips  maltaaprp_defconfig
powerpc rainier_defconfig
arcvdk_hs38_smp_defconfig
sh   se7343_defconfig
powerpc kilauea_defconfig
sh   se7780_defconfig
archsdk_defconfig
arm   omap1_defconfig
sh  rsk7201_defconfig
nds32   defconfig
m68k allyesconfig
powerpc mpc8540_ads_defconfig
shdreamcast_defconfig
mips decstation_r4k_defconfig
arm   imx_v4_v5_defconfig
arm am200epdkit_defconfig
microblaze  mmu_defconfig
sh  sh7785lcr_32bit_defconfig
arm orion5x_defconfig
m68kstmark2_defconfig
h8300 edosk2674_defconfig
powerpc mpc832x_rdb_defconfig
powerpc mpc8313_rdb_defconfig
powerpc  ppc40x_defconfig
arm socfpga_defconfig
um   x86_64_defconfig
armlart_defconfig
armkeystone_defconfig
riscvallyesconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
nios2   defconfig
nds32 allnoconfig
c6x  allyesconfig
nios2allyesconfig
cskydefconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
s390 allmodconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparc   defconfig
i386   tinyconfig
i386defconfig
sparcallyesconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc   allnoconfig
x86_64   randconfig-a006-20210209
x86_64   randconfig-a001-20210209
x86_64   randconfig-a005-20210209
x86_64   randconfig-a004-20210209
x86_64   randconfig-a002-20210209
x86_64   randconfig-a003-20210209
i386 randconfig-a001-20210209
i386 randconfig-a005-20210209
i386 randconfig-a003-20210209
i386 randconfig-a002-20210209
i386 randconfig-a006-20210209
i386 randconfig-a004-20210209
i386 randconfig-a016-20210209
i386 randconfig-a013-20210209
i386 randconfig-a012-20210209
i386 randconfig-a014-20210209
i386 randconfig-a011-20210209
i386 randconfig-a015-20210209
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  rhel-8.3-kbuiltin
x86_64  kexec

clang tested configs:
x86_64   randconfig-a013-20210209
x86_64   randconfig-a014-20210209
x86_64   randconfig-a015-20210209
x86_64   randconfig-a012-20210209
x86_64   randconfig-a016-20210209
x86_64   randconfig-a011-20210209

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

[PATCH v3 2/5] drm/sun4i: tcon: set sync polarity for tcon1 channel

[Jernej Skrabec]

Channel 1 has polarity bits for vsync and hsync signals but driver never
sets them. It turns out that with pre-HDMI2 controllers seemingly there
is no issue if polarity is not set. However, with HDMI2 controllers
(H6) there often comes to de-synchronization due to phase shift. This
causes flickering screen. It's safe to assume that similar issues might
happen also with pre-HDMI2 controllers.

Solve issue with setting vsync and hsync polarity. Note that display
stacks with tcon top have polarity bits actually in tcon0 polarity
register.

Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
Reviewed-by: Chen-Yu Tsai 
Tested-by: Andre Heider 
Signed-off-by: Jernej Skrabec 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 25 +
 drivers/gpu/drm/sun4i/sun4i_tcon.h |  6 ++
 2 files changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 6b9af4c08cd6..9f06dec0fc61 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -672,6 +672,30 @@ static void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
 SUN4I_TCON1_BASIC5_V_SYNC(vsync) |
 SUN4I_TCON1_BASIC5_H_SYNC(hsync));
 
+   /* Setup the polarity of multiple signals */
+   if (tcon->quirks->polarity_in_ch0) {
+   val = 0;
+
+   if (mode->flags & DRM_MODE_FLAG_PHSYNC)
+   val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE;
+
+   if (mode->flags & DRM_MODE_FLAG_PVSYNC)
+   val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
+
+   regmap_write(tcon->regs, SUN4I_TCON0_IO_POL_REG, val);
+   } else {
+   /* according to vendor driver, this bit must be always set */
+   val = SUN4I_TCON1_IO_POL_UNKNOWN;
+
+   if (mode->flags & DRM_MODE_FLAG_PHSYNC)
+   val |= SUN4I_TCON1_IO_POL_HSYNC_POSITIVE;
+
+   if (mode->flags & DRM_MODE_FLAG_PVSYNC)
+   val |= SUN4I_TCON1_IO_POL_VSYNC_POSITIVE;
+
+   regmap_write(tcon->regs, SUN4I_TCON1_IO_POL_REG, val);
+   }
+
/* Map output pins to channel 1 */
regmap_update_bits(tcon->regs, SUN4I_TCON_GCTL_REG,
   SUN4I_TCON_GCTL_IOMAP_MASK,
@@ -1500,6 +1524,7 @@ static const struct sun4i_tcon_quirks 
sun8i_a83t_tv_quirks = {
 
 static const struct sun4i_tcon_quirks sun8i_r40_tv_quirks = {
.has_channel_1  = true,
+   .polarity_in_ch0= true,
.set_mux= sun8i_r40_tcon_tv_set_mux,
 };
 
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h 
b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index c5ac1b02482c..e624f6977eb8 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -154,6 +154,11 @@
 #define SUN4I_TCON1_BASIC5_V_SYNC(height)  (((height) - 1) & 0x3ff)
 
 #define SUN4I_TCON1_IO_POL_REG 0xf0
+/* there is no documentation about this bit */
+#define SUN4I_TCON1_IO_POL_UNKNOWN BIT(26)
+#define SUN4I_TCON1_IO_POL_HSYNC_POSITIVE  BIT(25)
+#define SUN4I_TCON1_IO_POL_VSYNC_POSITIVE  BIT(24)
+
 #define SUN4I_TCON1_IO_TRI_REG 0xf4
 
 #define SUN4I_TCON_ECC_FIFO_REG0xf8
@@ -236,6 +241,7 @@ struct sun4i_tcon_quirks {
boolneeds_de_be_mux; /* sun6i needs mux to select backend */
boolneeds_edp_reset; /* a80 edp reset needed for tcon0 access */
boolsupports_lvds;   /* Does the TCON support an LVDS output? */
+   boolpolarity_in_ch0; /* some tcon1 channels have polarity bits in 
tcon0 pol register */
u8  dclk_min_div;   /* minimum divider for TCON0 DCLK */
 
/* callback to handle tcon muxing options */
-- 
2.30.0

[PATCH v3 0/5] sunxi: fix H6 HDMI related issues

[Jernej Skrabec]

Over the year I got plenty of reports of troubles with H6 HDMI signal.
Sometimes monitor flickers, sometimes there was no image at all and
sometimes it didn't play well with AVR.

It turns out there are multiple issues. Patch 1 fixes clock issue,
which didn't adjust parent rate, even if it is allowed to do so. Patch 2
adds polarity config in tcon1. This is seemingly not needed for pre-HDMI2
controllers, although BSP drivers set it accordingly every time. It
turns out that HDMI2 controllers often don't work with monitors if
polarity is not set correctly. Patch 3 always set clock rate for HDMI
controller. Patch 4 fixes H6 HDMI PHY settings. Patch 5 fixes comment and
clock rate limit (wrong reasoning).

Please take a look.

Best regards,
Jernej

Changes from v2:
- use clk_hw_can_set_rate_parent() directly instead of checking flags
Changes from v1:
- collected Chen-Yu tags (except on replaced patch 4)
- Added some comments in patch 2
- Replaced patch 4 (see commit log for explanation)

Jernej Skrabec (5):
  clk: sunxi-ng: mp: fix parent rate change flag check
  drm/sun4i: tcon: set sync polarity for tcon1 channel
  drm/sun4i: dw-hdmi: always set clock rate
  drm/sun4i: Fix H6 HDMI PHY configuration
  drm/sun4i: dw-hdmi: Fix max. frequency for H6

 drivers/clk/sunxi-ng/ccu_mp.c  |  2 +-
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 25 +
 drivers/gpu/drm/sun4i/sun4i_tcon.h |  6 ++
 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c  | 10 +++---
 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h  |  1 -
 drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 26 +-
 6 files changed, 44 insertions(+), 26 deletions(-)

--
2.30.0

[PATCH v3 3/5] drm/sun4i: dw-hdmi: always set clock rate

[Jernej Skrabec]

As expected, HDMI controller clock should always match pixel clock. In
the past, changing HDMI controller rate would seemingly worsen
situation. However, that was the result of other bugs which are now
fixed.

Fix that by removing set_rate quirk and always set clock rate.

Fixes: 40bb9d3147b2 ("drm/sun4i: Add support for H6 DW HDMI controller")
Reviewed-by: Chen-Yu Tsai 
Tested-by: Andre Heider 
Signed-off-by: Jernej Skrabec 
---
 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 4 +---
 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 1 -
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c 
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
index 92add2cef2e7..23773a5e0650 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -21,8 +21,7 @@ static void sun8i_dw_hdmi_encoder_mode_set(struct drm_encoder 
*encoder,
 {
struct sun8i_dw_hdmi *hdmi = encoder_to_sun8i_dw_hdmi(encoder);
 
-   if (hdmi->quirks->set_rate)
-   clk_set_rate(hdmi->clk_tmds, mode->crtc_clock * 1000);
+   clk_set_rate(hdmi->clk_tmds, mode->crtc_clock * 1000);
 }
 
 static const struct drm_encoder_helper_funcs
@@ -295,7 +294,6 @@ static int sun8i_dw_hdmi_remove(struct platform_device 
*pdev)
 
 static const struct sun8i_dw_hdmi_quirks sun8i_a83t_quirks = {
.mode_valid = sun8i_dw_hdmi_mode_valid_a83t,
-   .set_rate = true,
 };
 
 static const struct sun8i_dw_hdmi_quirks sun50i_h6_quirks = {
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h 
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
index d983746fa194..d4b55af0592f 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
@@ -179,7 +179,6 @@ struct sun8i_dw_hdmi_quirks {
enum drm_mode_status (*mode_valid)(struct dw_hdmi *hdmi, void *data,
   const struct drm_display_info *info,
   const struct drm_display_mode *mode);
-   unsigned int set_rate : 1;
unsigned int use_drm_infoframe : 1;
 };
 
-- 
2.30.0

Re: [EXT] Re: [net-next v4 00/14] Add Marvell CN10K support

[Geethasowjanya Akula]

Thanks Jakub. Overlooked new warnings as I was using C=2 flag.
Will fix it in the next version.



From: Jakub Kicinski 
Sent: Monday, February 8, 2021 11:10 PM
To: Geethasowjanya Akula
Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org; 
linux-cry...@vger.kernel.org; Sunil Kovvuri Goutham; da...@davemloft.net; 
Subbaraya Sundeep Bhatta; Hariprasad Kelam; Jerin Jacob Kollanukkaran; Linu 
Cherian; bbrezil...@kernel.org; a...@natisbad.org; Srujana Challa
Subject: [EXT] Re: [net-next v4 00/14] Add Marvell CN10K support

External Email

--
On Sat, 6 Feb 2021 04:19:59 +0530 Geetha sowjanya wrote:
> The current admin function (AF) driver and the netdev driver supports
> OcteonTx2 silicon variants. The same OcteonTx2's
> Resource Virtualization Unit (RVU) is carried forward to the next-gen
> silicon ie OcteonTx3, with some changes and feature enhancements.
>
> This patch set adds support for OcteonTx3 (CN10K) silicon and gets
> the drivers to the same level as OcteonTx2. No new OcteonTx3 specific
> features are added.
>
> Changes cover below HW level differences
> - PCIe BAR address changes wrt shared mailbox memory region
> - Receive buffer freeing to HW
> - Transmit packet's descriptor submission to HW
> - Programmable HW interface identifiers (channels)
> - Increased MTU support
> - A Serdes MAC block (RPM) configuration
>
> v3-v4
> Fixed compiler warnings.

Still 4 new sparse warnings in patch 1.

[gustavoars-linux:testing/drm/radeon/si_dpm 8321/8744] arch/mips/kernel/setup.c:47:39: error: conflicting types for '__appended_dtb'

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git 
testing/drm/radeon/si_dpm
head:   ec57589a61c44bedeaac6c8f39c7c7425fcf8249
commit: b83ba0b9df56f8404ccc6ebcc7050fb8294f0f20 [8321/8744] MIPS: of: 
Introduce helper function to get DTB
config: mips-randconfig-r021-20210209 (attached as .config)
compiler: mipsel-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://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git/commit/?id=b83ba0b9df56f8404ccc6ebcc7050fb8294f0f20
git remote add gustavoars-linux 
https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git
git fetch --no-tags gustavoars-linux testing/drm/radeon/si_dpm
git checkout b83ba0b9df56f8404ccc6ebcc7050fb8294f0f20
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=mips 

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

All errors (new ones prefixed by >>):

>> arch/mips/kernel/setup.c:47:39: error: conflicting types for '__appended_dtb'
  47 | const char __section(".appended_dtb") __appended_dtb[0x10];
 |   ^~
   In file included from arch/mips/kernel/setup.c:34:
   arch/mips/include/asm/bootinfo.h:118:13: note: previous declaration of 
'__appended_dtb' was here
 118 | extern char __appended_dtb[];
 | ^~


vim +/__appended_dtb +47 arch/mips/kernel/setup.c

^1da177e4c3f41 Linus Torvalds 2005-04-16  45  
87db537da4cd1b Aaro Koskinen  2015-09-11  46  #ifdef 
CONFIG_MIPS_ELF_APPENDED_DTB
33def8498fdde1 Joe Perches2020-10-21 @47  const char 
__section(".appended_dtb") __appended_dtb[0x10];
87db537da4cd1b Aaro Koskinen  2015-09-11  48  #endif /* 
CONFIG_MIPS_ELF_APPENDED_DTB */
87db537da4cd1b Aaro Koskinen  2015-09-11  49  

:: The code at line 47 was first introduced by commit
:: 33def8498fdde180023444b08e12b72a9efed41d treewide: Convert macro and 
uses of __section(foo) to __section("foo")

:: TO: Joe Perches 
:: CC: Linus Torvalds 

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


.config.gz
Description: application/gzip

[PATCH v5 2/4] drm/i915/gen9_bc: Introduce TGP PCH DDC pin mappings

[Lyude Paul]

With the introduction of gen9_bc, where Intel combines Cometlake CPUs with
a Tigerpoint PCH, we'll need to introduce new DDC pin mappings for this
platform in order to make all of the display connectors work. So, let's do
that.

Changes since v4:
* Split this into it's own patch - vsyrjala

Cc: Matt Roper 
Cc: Jani Nikula 
Cc: Ville Syrjala 
[originally from Tejas's work]
Signed-off-by: Tejas Upadhyay 
Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/i915/display/intel_bios.c |  9 +
 drivers/gpu/drm/i915/display/intel_hdmi.c | 20 
 2 files changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index 7118530a1c38..1289f9d437e4 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -1638,6 +1638,12 @@ static const u8 adls_ddc_pin_map[] = {
[ADLS_DDC_BUS_PORT_TC4] = GMBUS_PIN_12_TC4_ICP,
 };
 
+static const u8 gen9bc_tgp_ddc_pin_map[] = {
+   [DDC_BUS_DDI_B] = GMBUS_PIN_2_BXT,
+   [DDC_BUS_DDI_C] = GMBUS_PIN_9_TC1_ICP,
+   [DDC_BUS_DDI_D] = GMBUS_PIN_10_TC2_ICP,
+};
+
 static u8 map_ddc_pin(struct drm_i915_private *dev_priv, u8 vbt_pin)
 {
const u8 *ddc_pin_map;
@@ -1651,6 +1657,9 @@ static u8 map_ddc_pin(struct drm_i915_private *dev_priv, 
u8 vbt_pin)
} else if (IS_ROCKETLAKE(dev_priv) && INTEL_PCH_TYPE(dev_priv) == 
PCH_TGP) {
ddc_pin_map = rkl_pch_tgp_ddc_pin_map;
n_entries = ARRAY_SIZE(rkl_pch_tgp_ddc_pin_map);
+   } else if (HAS_PCH_TGP(dev_priv) && IS_GEN9_BC(dev_priv)) {
+   ddc_pin_map = gen9bc_tgp_ddc_pin_map;
+   n_entries = ARRAY_SIZE(gen9bc_tgp_ddc_pin_map);
} else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP) {
ddc_pin_map = icp_ddc_pin_map;
n_entries = ARRAY_SIZE(icp_ddc_pin_map);
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index dad54e116bc4..49528d07c7f3 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -3138,6 +3138,24 @@ static u8 rkl_port_to_ddc_pin(struct drm_i915_private 
*dev_priv, enum port port)
return GMBUS_PIN_1_BXT + phy;
 }
 
+static u8 gen9bc_port_to_ddc_pin(struct drm_i915_private *i915, enum port port)
+{
+   enum phy phy = intel_port_to_phy(i915, port);
+
+   drm_WARN_ON(>drm, port == PORT_A);
+
+   /*
+* Pin mapping for GEN9 BC depends on which PCH is present.  With TGP,
+* final two outputs use type-c pins, even though they're actually
+* combo outputs.  With CMP, the traditional DDI A-D pins are used for
+* all outputs.
+*/
+   if (INTEL_PCH_TYPE(i915) >= PCH_TGP && phy >= PHY_C)
+   return GMBUS_PIN_9_TC1_ICP + phy - PHY_C;
+
+   return GMBUS_PIN_1_BXT + phy;
+}
+
 static u8 dg1_port_to_ddc_pin(struct drm_i915_private *dev_priv, enum port 
port)
 {
return intel_port_to_phy(dev_priv, port) + 1;
@@ -3202,6 +3220,8 @@ static u8 intel_hdmi_ddc_pin(struct intel_encoder 
*encoder)
ddc_pin = dg1_port_to_ddc_pin(dev_priv, port);
else if (IS_ROCKETLAKE(dev_priv))
ddc_pin = rkl_port_to_ddc_pin(dev_priv, port);
+   else if (IS_GEN9_BC(dev_priv) && HAS_PCH_TGP(dev_priv))
+   ddc_pin = gen9bc_port_to_ddc_pin(dev_priv, port);
else if (HAS_PCH_MCC(dev_priv))
ddc_pin = mcc_port_to_ddc_pin(dev_priv, port);
else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
-- 
2.29.2

[PATCH] drm/msm: a6xx: Make sure the SQE microcode is safe

[Jordan Crouse]

Most a6xx targets have security issues that were fixed with new versions
of the microcode(s). Make sure that we are booting with a safe version of
the microcode for the target and print a message and error if not.

Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 67 +--
 1 file changed, 54 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index ba8e9d3cf0fe..cfb0d5f63784 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -522,28 +522,61 @@ static int a6xx_cp_init(struct msm_gpu *gpu)
return a6xx_idle(gpu, ring) ? 0 : -EINVAL;
 }
 
-static void a6xx_ucode_check_version(struct a6xx_gpu *a6xx_gpu,
+/*
+ * Check that the microcode version is new enough to include several key
+ * security fixes. Return true if the ucode is safe.
+ */
+static bool a6xx_ucode_check_version(struct a6xx_gpu *a6xx_gpu,
struct drm_gem_object *obj)
 {
+   struct adreno_gpu *adreno_gpu = _gpu->base;
u32 *buf = msm_gem_get_vaddr(obj);
+   bool ret = false;
 
if (IS_ERR(buf))
-   return;
+   return false;
 
/*
-* If the lowest nibble is 0xa that is an indication that this microcode
-* has been patched. The actual version is in dword [3] but we only care
-* about the patchlevel which is the lowest nibble of dword [3]
-*
-* Otherwise check that the firmware is greater than or equal to 1.90
-* which was the first version that had this fix built in
+* Targets up to a640 (a618, a630 and a640) need to check for a
+* microcode version that is patched to support the whereami opcode or
+* one that is new enough to include it by default.
 */
-   if (((buf[0] & 0xf) == 0xa) && (buf[2] & 0xf) >= 1)
-   a6xx_gpu->has_whereami = true;
-   else if ((buf[0] & 0xfff) > 0x190)
-   a6xx_gpu->has_whereami = true;
+   if (adreno_is_a618(adreno_gpu) || adreno_is_a630(adreno_gpu) ||
+   adreno_is_a640(adreno_gpu)) {
+   /*
+* If the lowest nibble is 0xa that is an indication that this
+* microcode has been patched. The actual version is in dword
+* [3] but we only care about the patchlevel which is the lowest
+* nibble of dword [3]
+*
+* Otherwise check that the firmware is greater than or equal
+* to 1.90 which was the first version that had this fix built
+* in
+*/
+   if buf[0] & 0xf) == 0xa) && (buf[2] & 0xf) >= 1) ||
+   (buf[0] & 0xfff) > 0x190) {
+   a6xx_gpu->has_whereami = true;
+   ret = true;
+   }
+   }  else {
+   /*
+* a650 tier targets don't need whereami but still need to be
+* equal to or newer than 1.95 for other security fixes
+*/
+   if (adreno_is_a640(adreno_gpu)) {
+   if ((buf[0] & 0xfff) >= 0x195)
+   ret = true;
+   }
+
+   /*
+* When a660 is added those targets should return true here
+* since those have all the critiical security fixes built in
+* from the start
+*/
+   }
 
msm_gem_put_vaddr(obj);
+   return ret;
 }
 
 static int a6xx_ucode_init(struct msm_gpu *gpu)
@@ -566,7 +599,15 @@ static int a6xx_ucode_init(struct msm_gpu *gpu)
}
 
msm_gem_object_set_name(a6xx_gpu->sqe_bo, "sqefw");
-   a6xx_ucode_check_version(a6xx_gpu, a6xx_gpu->sqe_bo);
+   if (!a6xx_ucode_check_version(a6xx_gpu, a6xx_gpu->sqe_bo)) {
+   DRM_DEV_ERROR(>pdev->dev,
+   "SQE ucode version is too old. It is likely 
unsafe\n");
+   msm_gem_unpin_iova(a6xx_gpu->sqe_bo, gpu->aspace);
+   drm_gem_object_put(a6xx_gpu->sqe_bo);
+
+   a6xx_gpu->sqe_bo = NULL;
+   return -EPERM;
+   }
}
 
gpu_write64(gpu, REG_A6XX_CP_SQE_INSTR_BASE_LO,
-- 
2.25.1

Re: [PATCH v1] mm, hwpoison: enable error handling on shmem thp

[Naoya Horiguchi]

On Tue, Feb 09, 2021 at 11:46:40AM -0800, Andrew Morton wrote:
> On Tue,  9 Feb 2021 15:21:28 +0900 Naoya Horiguchi  
> wrote:
> 
> > Currently hwpoison code checks PageAnon() for thp and refuses to handle
> > errors on non-anonymous thps (just for historical reason).  We now
> > support non-anonymou thp like shmem one, so this patch suggests to enable
> > to handle shmem thps. Fortunately, we already have can_split_huge_page()
> > to check if a give thp is splittable, so this patch relies on it.
> 
> Thanks.  We're at -rc7 so I think I'll park this one for 5.12-rc1,
> unless it is more urgent than I believe it to be?

This patch is not so urgent, so I'm fine to make this targeted at 5.12-rc1.

Thanks,
Naoya Horiguchi

[ANNOUNCE] exfatprogs-1.1.0 version released

[Namjae Jeon]

Hi folk,

We have released exfatprogs 1.1.0 version. In this release, exfatlabel
has been added to print or re-write volume label and volume serial value.
Also, A new dump.exfat util has been added to display statistics from
a given device(Requested by Mike Fleetwood(GParted Developer)).

Any feedback is welcome!:)

CHANGES :
 * fsck.exfat: Recover corrupted boot region.

NEW FEATURES :
 * exfatlabel: Print or set volume label and serial.
 * dump.exfat: Show the on-disk metadata information and the statistics.

BUG FIXES :
 * Set _FILE_OFFSET_BITS=64 for Android build.

The git tree is at:
  https://github.com/exfatprogs/exfatprogs

The tarballs can be found at:
  
https://github.com/exfatprogs/exfatprogs/releases/download/1.1.0/exfatprogs-1.1.0.tar.gz

Re: [PATCH 2/5] ARM: dts: rockchip: assign a fixed index to mmc devices on rv1108 boards

[Heiko Stübner]

Am Dienstag, 9. Februar 2021, 23:25:40 CET schrieb Arnd Bergmann:
> On Mon, Jan 18, 2021 at 4:52 PM Johan Jonker  wrote:
> >
> > Recently introduced async probe on mmc devices can shuffle block IDs.
> > Pin them to fixed values to ease booting in environments where UUIDs are
> > not practical. Use newly introduced aliases for mmcblk devices from [1].
> > The sort order is based on reg address.
> >
> > [1] https://patchwork.kernel.org/patch/11747669/
> 
> I just saw this in the pull request:
> 
> > Signed-off-by: Johan Jonker 
> > ---
> >  arch/arm/boot/dts/rv1108.dtsi | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/rv1108.dtsi b/arch/arm/boot/dts/rv1108.dtsi
> > index bec47e0be..a754851f4 100644
> > --- a/arch/arm/boot/dts/rv1108.dtsi
> > +++ b/arch/arm/boot/dts/rv1108.dtsi
> > @@ -19,6 +19,9 @@
> > i2c1 = 
> > i2c2 = 
> > i2c3 = 
> > +   mmc0 = 
> > +   mmc1 = 
> > +   mmc2 = 
> > serial0 = 
> > serial1 = 
> > serial2 = 
> 
> Please don't put these aliases into a .dtsi file, as not every board
> will provide each instance. The entire point of the aliases is to
> have sane enumeration, so you should start at index 0 for the
> first one that is actually present and count up from there.

Hmm, right now I don't see the disadvantage of missing mmc numbers.
As similarly we count i2c and serial numbers for a long time, even though
not all of them appear on every board.

Especially as the main goal is to simply have stable numbers and
not having the mmc devices swap numbers on every boot.

So right now we're not using them from a userspace POV but
instead agreed on following the address ordering of the soc.
so when ordering mmc controllers by their io-address, mmc0
is the first one, then mmc1, etc.

So just for my understanding, what is different for mmc?
I guess to guarantee ongoing numbering similar to sd{a,b,c,...}
Or should all aliases be duplicted in each board dts and not
live in any soc dtsi?


Heiko


> I would suggest you move these aliases into the .dts files for
> the existing boards for the next cycle, and then make sure
> only the ones that are present have an alias.
> 
> It might actually be a good idea to have a warning in dtc when
> there is an alias pointing to a status="disabled" device, but I
> suspect there would be a lot of fallout from that.
> 
>   Arnd
> 

[PATCH 3/3] drm/nouveau/ttm: constify static vm_operations_struct

[Rikard Falkeborn]

The only usage of nouveau_ttm_vm_ops is to assign its address to the
vm_ops field in the vm_area_struct struct. Make it const to allow the
compiler to put it in read-only memory

Signed-off-by: Rikard Falkeborn 
---
 drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c 
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index 495288182c2d..b81ae90b8449 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -154,7 +154,7 @@ static vm_fault_t nouveau_ttm_fault(struct vm_fault *vmf)
return ret;
 }
 
-static struct vm_operations_struct nouveau_ttm_vm_ops = {
+static const struct vm_operations_struct nouveau_ttm_vm_ops = {
.fault = nouveau_ttm_fault,
.open = ttm_bo_vm_open,
.close = ttm_bo_vm_close,
-- 
2.30.0

[PATCH 0/3] drm/ttm: constify static vm_operations_structs

[Rikard Falkeborn]

Constify a few static vm_operations_struct that are never modified. Their
only usage is to assign their address to the vm_ops field in the
vm_area_struct, which is a pointer to const vm_operations_struct. Make them
const to allow the compiler to put them in read-only memory.

With this series applied, all static struct vm_operations_struct in the
kernel tree are const.

Rikard Falkeborn (3):
  drm/amdgpu/ttm: constify static vm_operations_struct
  drm/radeon/ttm: constify static vm_operations_struct
  drm/nouveau/ttm: constify static vm_operations_struct

 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
 drivers/gpu/drm/nouveau/nouveau_ttm.c   | 2 +-
 drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

-- 
2.30.0

Re: [RFC][PATCH 06/13] mm/migrate: update migration order during on hotplug events

[Dave Hansen]

On 2/2/21 3:42 AM, Oscar Salvador wrote:
>> +static int __meminit migrate_on_reclaim_callback(struct notifier_block 
>> *self,
>> + unsigned long action, void 
>> *arg)
>> +{
>> +switch (action) {
>> +case MEM_GOING_OFFLINE:
>> +/*
>> + * Make sure there are not transient states where
>> + * an offline node is a migration target.  This
>> + * will leave migration disabled until the offline
>> + * completes and the MEM_OFFLINE case below runs.
>> + */
>> +disable_all_migrate_targets();
>> +break;
>> +case MEM_OFFLINE:
>> +case MEM_ONLINE:
>> +/*
>> + * Recalculate the target nodes once the node
>> + * reaches its final state (online or offline).
>> + */
>> +__set_migration_target_nodes();
>> +break;
>> +case MEM_CANCEL_OFFLINE:
>> +/*
>> + * MEM_GOING_OFFLINE disabled all the migration
>> + * targets.  Reenable them.
>> + */
>> +__set_migration_target_nodes();
>> +break;
>> +case MEM_GOING_ONLINE:
>> +case MEM_CANCEL_ONLINE:
>> +break;
>> +}
>> +
>> +return notifier_from_errno(0);
>> +}
> This looks good, and I kinda like it.
> But in this case, all we care about is whether NUMA node does or does
> not have memory, so we have to remove/added into the demotion list.
> So, would make more sense to have a kinda helper in
> node_states_{set,clear}_node that calls the respective functions
> (disable_all_migrate_targets and __set_migration_target_nodes)?

Of, you're saying that we could do this in the hotplug code itself
instead of from a notifier?  I agree, we *could*.  That would be more
efficient.  But, I do like the idea of doing this from a notifier
because it's a bit less brittle.

Do you feel strongly about this one?

[PATCH 2/3] drm/radeon/ttm: constify static vm_operations_struct

[Rikard Falkeborn]

The only usage of radeon_ttm_vm_ops is to assign its address to the
vm_ops field in the vm_area_struct struct. Make it const to allow the
compiler to put it in read-only memory

Signed-off-by: Rikard Falkeborn 
---
 drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index c45e919e03c5..5fc8bae401af 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -835,7 +835,7 @@ static vm_fault_t radeon_ttm_fault(struct vm_fault *vmf)
return ret;
 }
 
-static struct vm_operations_struct radeon_ttm_vm_ops = {
+static const struct vm_operations_struct radeon_ttm_vm_ops = {
.fault = radeon_ttm_fault,
.open = ttm_bo_vm_open,
.close = ttm_bo_vm_close,
-- 
2.30.0

[PATCH 1/3] drm/amdgpu/ttm: constify static vm_operations_struct

[Rikard Falkeborn]

The only usage of amdgpu_ttm_vm_ops is to assign its address to the
vm_ops field in the vm_area_struct struct. Make it const to allow the
compiler to put it in read-only memory.

Signed-off-by: Rikard Falkeborn 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 29cfb0809634..a785acc09f20 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -2002,7 +2002,7 @@ static vm_fault_t amdgpu_ttm_fault(struct vm_fault *vmf)
return ret;
 }
 
-static struct vm_operations_struct amdgpu_ttm_vm_ops = {
+static const struct vm_operations_struct amdgpu_ttm_vm_ops = {
.fault = amdgpu_ttm_fault,
.open = ttm_bo_vm_open,
.close = ttm_bo_vm_close,
-- 
2.30.0

Re: [PATCH] wireless: brcm80211: Fix the spelling configation to configuration in the file d11.h

[Randy Dunlap]

On 2/9/21 3:29 PM, Bhaskar Chowdhury wrote:
> 
> s/configation/configuration/
> 
> Signed-off-by: Bhaskar Chowdhury 

Acked-by: Randy Dunlap 

Thanks.

> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmsmac/d11.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/d11.h 
> b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/d11.h
> index 9035cc4d6ff3..dc395566e495 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/d11.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/d11.h
> @@ -1469,7 +1469,7 @@ struct d11rxhdr {
>  /* htphy PhyRxStatus_1: */
>  /* core enables for {3..0}, 0=disabled, 1=enabled */
>  #define PRXS1_HTPHY_CORE_MASK0x000F
> -/* antenna configation */
> +/* antenna configuration */
>  #define PRXS1_HTPHY_ANTCFG_MASK  0x00F0
>  /* Mixmode PLCP Length low byte mask */
>  #define PRXS1_HTPHY_MMPLCPLenL_MASK  0xFF00
> --
> 2.30.0
> 


-- 
~Randy

Re: [PATCH] PCI: Use subdir-ccflags-* to inherit debug flag

[Krzysztof Wilczyński]

Hi Bjorn,

Thank you!  This looks great!

[...]
> commit e8e9aababe60 ("PCI: Apply CONFIG_PCI_DEBUG to entire drivers/pci 
> hierarchy")
> Author: Junhao He 
> Date:   Thu Feb 4 19:30:15 2021 +0800
> 
> PCI: Apply CONFIG_PCI_DEBUG to entire drivers/pci hierarchy
> 
> CONFIG_PCI_DEBUG=y adds -DDEBUG to CFLAGS, which enables things like
> pr_debug() and dev_dbg() (and hence pci_dbg()).  Previously we added
> -DDEBUG for files in drivers/pci/, but not files in subdirectories of
> drivers/pci/.
> 
> Add -DDEBUG to CFLAGS for all files below drivers/pci/ so CONFIG_PCI_DEBUG
> applies to the entire hierarchy.
> 
> [bhelgaas: commit log]
> Link: 
> https://lore.kernel.org/r/1612438215-33105-1-git-send-email-yangyic...@hisilicon.com
> Signed-off-by: Junhao He 
> Signed-off-by: Yicong Yang 
> Signed-off-by: Bjorn Helgaas 
> Reviewed-by: Krzysztof Wilczyński 
> 
> diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
> index 11cc79411e2d..d62c4ac4ae1b 100644
> --- a/drivers/pci/Makefile
> +++ b/drivers/pci/Makefile
> @@ -36,4 +36,4 @@ obj-$(CONFIG_PCI_ENDPOINT)  += endpoint/
>  obj-y+= controller/
>  obj-y+= switch/
>  
> -ccflags-$(CONFIG_PCI_DEBUG) := -DDEBUG
> +subdir-ccflags-$(CONFIG_PCI_DEBUG) := -DDEBUG

And thank you again, Yicong, for fixing this.  Much appreciated.

Krzysztof

Re: [RFC][PATCH 07/13] mm/migrate: make migrate_pages() return nr_succeeded

[Dave Hansen]

On 1/29/21 1:04 PM, Yang Shi wrote:
>> @@ -1527,7 +1527,7 @@ retry:
>> nr_succeeded += nr_subpages;
> It seems the above line is missed. The THP accounting change was
> merged in v5.9 before I submitted this patch.

Thanks for reporting that.  Ying found and reported that too.  It's
fixed up in my most recent version.

Re: [PATCH net v2] vsock: fix locking in vsock_shutdown()

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net.git (refs/heads/master):

On Tue,  9 Feb 2021 09:52:19 +0100 you wrote:
> In vsock_shutdown() we touched some socket fields without holding the
> socket lock, such as 'state' and 'sk_flags'.
> 
> Also, after the introduction of multi-transport, we are accessing
> 'vsk->transport' in vsock_send_shutdown() without holding the lock
> and this call can be made while the connection is in progress, so
> the transport can change in the meantime.
> 
> [...]

Here is the summary with links:
  - [net,v2] vsock: fix locking in vsock_shutdown()
https://git.kernel.org/netdev/net/c/1c5fae9c9a09

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH 1/2] arm64: dts: qcom: sdm845: Move reserved-memory to devices

[Bjorn Andersson]

On Tue 09 Feb 17:25 CST 2021, Doug Anderson wrote:

> Hi,
> 
> On Tue, Feb 9, 2021 at 8:09 AM Bjorn Andersson
>  wrote:
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi 
> > b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> > index 216a74f0057c..2f44785d1af0 100644
> > --- a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> > @@ -153,36 +153,66 @@ panel_in_edp: endpoint {
> >   * all modifications to the memory map (from sdm845.dtsi) in one place.
> >   */
> >
> > -/*
> > - * Our mpss_region is 8MB bigger than the default one and that conflicts
> > - * with venus_mem and cdsp_mem.
> > - *
> > - * For venus_mem we'll delete and re-create at a different address.
> > - *
> > - * cdsp_mem isn't used on cheza right now so we won't bother re-creating 
> > it; but
> > - * that also means we need to delete cdsp_pas.
> > - */
> > -/delete-node/ _mem;
> > -/delete-node/ _mem;
> > -/delete-node/ _pas;
> 
> Note to self: on cheza we'll end up with "cdsp_pas" existing now, but
> that _should_ be OK since it's disabled
> 

That was not intentional, but as you say it shouldn't make a difference.

> 
> > @@ -1321,6 +1359,7 @@ config {
> >  };
> >
> >   {
> > +   memory-region = <_mem>;
> > video-firmware {
> > iommus = <_smmu 0x10b2 0x0>;
> > };
> 
> slight nit: I think it looks ugly not to have a blank line between the
> property and the sub-node.  ;-)
> 

I agree, will go over and adjust this in v2.

> 
> > @@ -766,8 +697,6 @@ adsp_pas: remoteproc-adsp {
> > clocks = < RPMH_CXO_CLK>;
> > clock-names = "xo";
> >
> > -   memory-region = <_mem>;
> > -
> 
> Note to self: we're losing the above on cheza, but that _should_ be OK
> since the node is disabled anyway.
> 
> Probably not critical at this point, but it makes me wonder whether we
> could remove adsp_mem on cheza...
> 

I noticed this too, but figured that this is an actual change, so it
would be better to do in a separate commit - if that's desired.

> ---
> 
> So I only looked at the cheza and sdm845 changes and they look fine to
> me and this seems like a good change overall.  I'm assuming that folks
> who focus on the other boards will double-check your work there if
> they care or just trust that everything is great.  ;-)
> 
> OK, I lied.  I took a quick glance.  In "sdm845-db845c" you maybe miss
> adding the "memory-region" back to the WiFi?  Have you tried running
> something like this before/after:
> 
> for f in sdm845*.dtb; do   dtc -I dtb -O dts --sort $f > $f.dts; done
> 

I was not aware of the --sort, so I did this by chaining together some
more things in the shell to confirm that I didn't actually change any
reserved-memory regions...

> You've gotta ignore phandle ID differences but otherwise it'll point
> out things like this.
> 

But as the phandles changed all over the place I looked only at the
reserved-memory, will fix up the db845c wifi node and double check the
rest of the nodes. Thanks for spotting this!

Regards,
Bjorn

Re: [v7 PATCH 05/12] mm: memcontrol: rename shrinker_map to shrinker_info

[Yang Shi]

On Tue, Feb 9, 2021 at 12:50 PM Roman Gushchin  wrote:
>
> On Tue, Feb 09, 2021 at 09:46:39AM -0800, Yang Shi wrote:
> > The following patch is going to add nr_deferred into shrinker_map, the 
> > change will
> > make shrinker_map not only include map anymore, so rename it to 
> > "memcg_shrinker_info".
> > And this should make the patch adding nr_deferred cleaner and readable and 
> > make
> > review easier.  Also remove the "memcg_" prefix.
> >
> > Acked-by: Vlastimil Babka 
> > Acked-by: Kirill Tkhai 
> > Signed-off-by: Yang Shi 
> > ---
> >  include/linux/memcontrol.h |  8 ++---
> >  mm/memcontrol.c|  6 ++--
> >  mm/vmscan.c| 62 +++---
> >  3 files changed, 38 insertions(+), 38 deletions(-)
> >
> > diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> > index 1739f17e0939..4c9253896e25 100644
> > --- a/include/linux/memcontrol.h
> > +++ b/include/linux/memcontrol.h
> > @@ -96,7 +96,7 @@ struct lruvec_stat {
> >   * Bitmap of shrinker::id corresponding to memcg-aware shrinkers,
> >   * which have elements charged to this memcg.
> >   */
> > -struct memcg_shrinker_map {
> > +struct shrinker_info {
> >   struct rcu_head rcu;
> >   unsigned long map[];
> >  };
> > @@ -118,7 +118,7 @@ struct mem_cgroup_per_node {
> >
> >   struct mem_cgroup_reclaim_iter  iter;
> >
> > - struct memcg_shrinker_map __rcu *shrinker_map;
> > + struct shrinker_info __rcu  *shrinker_info;
>
> Nice!
>
> I really like how it looks now in comparison to the v1. Thank you for
> working on it!

Thanks a lot for all the great comments from all of you.

>
> >
> >   struct rb_node  tree_node;  /* RB tree node */
> >   unsigned long   usage_in_excess;/* Set to the value by which 
> > */
> > @@ -1581,8 +1581,8 @@ static inline bool 
> > mem_cgroup_under_socket_pressure(struct mem_cgroup *memcg)
> >   return false;
> >  }
> >
> > -int alloc_shrinker_maps(struct mem_cgroup *memcg);
> > -void free_shrinker_maps(struct mem_cgroup *memcg);
> > +int alloc_shrinker_info(struct mem_cgroup *memcg);
> > +void free_shrinker_info(struct mem_cgroup *memcg);
> >  void set_shrinker_bit(struct mem_cgroup *memcg, int nid, int shrinker_id);
> >  #else
> >  #define mem_cgroup_sockets_enabled 0
> > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > index f5c9a0d2160b..f64ad0d044d9 100644
> > --- a/mm/memcontrol.c
> > +++ b/mm/memcontrol.c
> > @@ -5246,11 +5246,11 @@ static int mem_cgroup_css_online(struct 
> > cgroup_subsys_state *css)
> >   struct mem_cgroup *memcg = mem_cgroup_from_css(css);
> >
> >   /*
> > -  * A memcg must be visible for expand_shrinker_maps()
> > +  * A memcg must be visible for expand_shrinker_info()
> >* by the time the maps are allocated. So, we allocate maps
> >* here, when for_each_mem_cgroup() can't skip it.
> >*/
> > - if (alloc_shrinker_maps(memcg)) {
> > + if (alloc_shrinker_info(memcg)) {
> >   mem_cgroup_id_remove(memcg);
> >   return -ENOMEM;
> >   }
> > @@ -5314,7 +5314,7 @@ static void mem_cgroup_css_free(struct 
> > cgroup_subsys_state *css)
> >   vmpressure_cleanup(>vmpressure);
> >   cancel_work_sync(>high_work);
> >   mem_cgroup_remove_from_trees(memcg);
> > - free_shrinker_maps(memcg);
> > + free_shrinker_info(memcg);
> >   memcg_free_kmem(memcg);
> >   mem_cgroup_free(memcg);
> >  }
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index 641077b09e5d..9436f9246d32 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -190,20 +190,20 @@ static int shrinker_nr_max;
> >  #define NR_MAX_TO_SHR_MAP_SIZE(nr_max) \
> >   (DIV_ROUND_UP(nr_max, BITS_PER_LONG) * sizeof(unsigned long))
> >
> > -static void free_shrinker_map_rcu(struct rcu_head *head)
> > +static void free_shrinker_info_rcu(struct rcu_head *head)
> >  {
> > - kvfree(container_of(head, struct memcg_shrinker_map, rcu));
> > + kvfree(container_of(head, struct shrinker_info, rcu));
> >  }
> >
> > -static int expand_one_shrinker_map(struct mem_cgroup *memcg,
> > +static int expand_one_shrinker_info(struct mem_cgroup *memcg,
> >  int size, int old_size)
> >  {
> > - struct memcg_shrinker_map *new, *old;
> > + struct shrinker_info *new, *old;
> >   int nid;
> >
> >   for_each_node(nid) {
> >   old = rcu_dereference_protected(
> > - mem_cgroup_nodeinfo(memcg, nid)->shrinker_map, true);
> > + mem_cgroup_nodeinfo(memcg, nid)->shrinker_info, true);
> >   /* Not yet online memcg */
> >   if (!old)
> >   return 0;
> > @@ -216,17 +216,17 @@ static int expand_one_shrinker_map(struct mem_cgroup 
> > *memcg,
> >   memset(new->map, (int)0xff, old_size);
> >   memset((void *)new->map + old_size, 0, size - old_size);
> >
> > - 

Re: [v7 PATCH 04/12] mm: vmscan: remove memcg_shrinker_map_size

[Yang Shi]

On Tue, Feb 9, 2021 at 12:43 PM Roman Gushchin  wrote:
>
> On Tue, Feb 09, 2021 at 09:46:38AM -0800, Yang Shi wrote:
> > Both memcg_shrinker_map_size and shrinker_nr_max is maintained, but 
> > actually the
> > map size can be calculated via shrinker_nr_max, so it seems unnecessary to 
> > keep both.
> > Remove memcg_shrinker_map_size since shrinker_nr_max is also used by 
> > iterating the
> > bit map.
> >
> > Acked-by: Kirill Tkhai 
> > Signed-off-by: Yang Shi 
> > ---
> >  mm/vmscan.c | 18 +-
> >  1 file changed, 9 insertions(+), 9 deletions(-)
> >
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index e4ddaaaeffe2..641077b09e5d 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -185,8 +185,10 @@ static LIST_HEAD(shrinker_list);
> >  static DECLARE_RWSEM(shrinker_rwsem);
> >
> >  #ifdef CONFIG_MEMCG
> > +static int shrinker_nr_max;
> >
> > -static int memcg_shrinker_map_size;
> > +#define NR_MAX_TO_SHR_MAP_SIZE(nr_max) \
> > + (DIV_ROUND_UP(nr_max, BITS_PER_LONG) * sizeof(unsigned long))
>
> How about something like this?
>
> static inline int shrinker_map_size(int nr_items)
> {
> return DIV_ROUND_UP(nr_items, BITS_PER_LONG) * sizeof(unsigned long);
> }
>
> I think it look less cryptic.

OK, I don't have a strong opinion for either one (inline function or
macro). If no one objects this I could do it in the new version.

>
> The rest of the patch looks good to me.
>
> Thanks!

Re: [PATCH 1/2] dt-bindings: Add doc for FriendlyARM NanoPi R4S

[Rob Herring]

On Tue, 09 Feb 2021 03:16:45 +0800, Tianling Shen wrote:
> Add devicetree binding documentation for the FriendlyARM NanoPi R4S.
> 
> Signed-off-by: Tianling Shen 
> ---
>  Documentation/devicetree/bindings/arm/rockchip.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring 

[PATCH] wireless: brcm80211: Fix the spelling configation to configuration in the file d11.h

[Bhaskar Chowdhury]

s/configation/configuration/

Signed-off-by: Bhaskar Chowdhury 
---
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/d11.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/d11.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/d11.h
index 9035cc4d6ff3..dc395566e495 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/d11.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/d11.h
@@ -1469,7 +1469,7 @@ struct d11rxhdr {
 /* htphy PhyRxStatus_1: */
 /* core enables for {3..0}, 0=disabled, 1=enabled */
 #define PRXS1_HTPHY_CORE_MASK  0x000F
-/* antenna configation */
+/* antenna configuration */
 #define PRXS1_HTPHY_ANTCFG_MASK0x00F0
 /* Mixmode PLCP Length low byte mask */
 #define PRXS1_HTPHY_MMPLCPLenL_MASK0xFF00
--
2.30.0

Re: [v7 PATCH 03/12] mm: vmscan: use shrinker_rwsem to protect shrinker_maps allocation

[Yang Shi]

On Tue, Feb 9, 2021 at 12:33 PM Roman Gushchin  wrote:
>
> On Tue, Feb 09, 2021 at 09:46:37AM -0800, Yang Shi wrote:
> > Since memcg_shrinker_map_size just can be changed under holding 
> > shrinker_rwsem
> > exclusively, the read side can be protected by holding read lock, so it 
> > sounds
> > superfluous to have a dedicated mutex.
> >
> > Kirill Tkhai suggested use write lock since:
> >
> >   * We want the assignment to shrinker_maps is visible for 
> > shrink_slab_memcg().
> >   * The rcu_dereference_protected() dereferrencing in shrink_slab_memcg(), 
> > but
> > in case of we use READ lock in alloc_shrinker_maps(), the dereferrencing
> > is not actually protected.
> >   * READ lock makes alloc_shrinker_info() racy against memory allocation 
> > fail.
> > alloc_shrinker_info()->free_shrinker_info() may free memory right after
> > shrink_slab_memcg() dereferenced it. You may say
> > shrink_slab_memcg()->mem_cgroup_online() protects us from it? Yes, sure,
> > but this is not the thing we want to remember in the future, since this
> > spreads modularity.
> >
> > And a test with heavy paging workload didn't show write lock makes things 
> > worse.
> >
> > Acked-by: Vlastimil Babka 
> > Acked-by: Kirill Tkhai 
> > Signed-off-by: Yang Shi 
>
> Acked-by: Roman Gushchin 
>
> with a small nit (below):
>
> > ---
> >  mm/vmscan.c | 16 ++--
> >  1 file changed, 6 insertions(+), 10 deletions(-)
> >
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index 96b08c79f18d..e4ddaaaeffe2 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -187,7 +187,6 @@ static DECLARE_RWSEM(shrinker_rwsem);
> >  #ifdef CONFIG_MEMCG
> >
> >  static int memcg_shrinker_map_size;
> > -static DEFINE_MUTEX(memcg_shrinker_map_mutex);
> >
> >  static void free_shrinker_map_rcu(struct rcu_head *head)
> >  {
> > @@ -200,8 +199,6 @@ static int expand_one_shrinker_map(struct mem_cgroup 
> > *memcg,
> >   struct memcg_shrinker_map *new, *old;
> >   int nid;
> >
> > - lockdep_assert_held(_shrinker_map_mutex);
> > -
>
> Why not check that shrinker_rwsem is down here?

No special reason, just because we know it was acquired before. We
could add the check, but not here. I think it'd be better to have the
assert in expand_shrinker_maps() since the rwsem was acquired before
calling it.

>
> >   for_each_node(nid) {
> >   old = rcu_dereference_protected(
> >   mem_cgroup_nodeinfo(memcg, nid)->shrinker_map, true);
> > @@ -249,7 +246,7 @@ int alloc_shrinker_maps(struct mem_cgroup *memcg)
> >   if (mem_cgroup_is_root(memcg))
> >   return 0;
> >
> > - mutex_lock(_shrinker_map_mutex);
> > + down_write(_rwsem);
> >   size = memcg_shrinker_map_size;
> >   for_each_node(nid) {
> >   map = kvzalloc_node(sizeof(*map) + size, GFP_KERNEL, nid);
> > @@ -260,7 +257,7 @@ int alloc_shrinker_maps(struct mem_cgroup *memcg)
> >   }
> >   rcu_assign_pointer(memcg->nodeinfo[nid]->shrinker_map, map);
> >   }
> > - mutex_unlock(_shrinker_map_mutex);
> > + up_write(_rwsem);
> >
> >   return ret;
> >  }
> > @@ -275,9 +272,8 @@ static int expand_shrinker_maps(int new_id)
> >   if (size <= old_size)
> >   return 0;
> >
> > - mutex_lock(_shrinker_map_mutex);
>
> And here as well. It will make the locking model more obvious and will help
> to avoid errors in the future.
>
> >   if (!root_mem_cgroup)
> > - goto unlock;
> > + goto out;
> >
> >   memcg = mem_cgroup_iter(NULL, NULL, NULL);
> >   do {
> > @@ -286,13 +282,13 @@ static int int new_id)
> >   ret = expand_one_shrinker_map(memcg, size, old_size);
> >   if (ret) {
> >   mem_cgroup_iter_break(NULL, memcg);
> > - goto unlock;
> > + goto out;
> >   }
> >   } while ((memcg = mem_cgroup_iter(NULL, memcg, NULL)) != NULL);
> > -unlock:
> > +out:
> >   if (!ret)
> >   memcg_shrinker_map_size = size;
> > - mutex_unlock(_shrinker_map_mutex);
> > +
> >   return ret;
> >  }
> >
> > --
> > 2.26.2
> >

Re: [PATCH v2 1/2] misc: Add clock control logic into Aspeed LPC SNOOP driver

[Arnd Bergmann]

On Sat, Jan 16, 2021 at 2:03 AM Ryan Chen  wrote:
> >
> > Sorry it did not make it into the merge window. The patch is still in 
> > patchwork.
> > I could just pick it up directly for v5.12, or wait for a combined pull 
> > request
> > with other work.
>
> Hello Arnd,
> Thanks your update.
>
> >Joel, please let me know what you prefer.
> >
> Hello Joel,
> Could you help check on this patch?
> https://patchwork.ozlabs.org/project/linux-aspeed/patch/20200928070108.14040-2-ryan_c...@aspeedtech.com/

Hi Joel,

I see there has been no new pull request for mach-aspeed in
v5.12. If you have any material at all, please send it as soon
as you can so I can pick it up this time.

As a reminder, the patch here has still not been merged, as I
never heard back from you.

   Arnd

Re: [PATCH 1/2] arm64: dts: qcom: sdm845: Move reserved-memory to devices

[Doug Anderson]

Hi,

On Tue, Feb 9, 2021 at 8:09 AM Bjorn Andersson
 wrote:
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi 
> b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> index 216a74f0057c..2f44785d1af0 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> @@ -153,36 +153,66 @@ panel_in_edp: endpoint {
>   * all modifications to the memory map (from sdm845.dtsi) in one place.
>   */
>
> -/*
> - * Our mpss_region is 8MB bigger than the default one and that conflicts
> - * with venus_mem and cdsp_mem.
> - *
> - * For venus_mem we'll delete and re-create at a different address.
> - *
> - * cdsp_mem isn't used on cheza right now so we won't bother re-creating it; 
> but
> - * that also means we need to delete cdsp_pas.
> - */
> -/delete-node/ _mem;
> -/delete-node/ _mem;
> -/delete-node/ _pas;

Note to self: on cheza we'll end up with "cdsp_pas" existing now, but
that _should_ be OK since it's disabled


> @@ -1321,6 +1359,7 @@ config {
>  };
>
>   {
> +   memory-region = <_mem>;
> video-firmware {
> iommus = <_smmu 0x10b2 0x0>;
> };

slight nit: I think it looks ugly not to have a blank line between the
property and the sub-node.  ;-)


> @@ -766,8 +697,6 @@ adsp_pas: remoteproc-adsp {
> clocks = < RPMH_CXO_CLK>;
> clock-names = "xo";
>
> -   memory-region = <_mem>;
> -

Note to self: we're losing the above on cheza, but that _should_ be OK
since the node is disabled anyway.

Probably not critical at this point, but it makes me wonder whether we
could remove adsp_mem on cheza...

---

So I only looked at the cheza and sdm845 changes and they look fine to
me and this seems like a good change overall.  I'm assuming that folks
who focus on the other boards will double-check your work there if
they care or just trust that everything is great.  ;-)

OK, I lied.  I took a quick glance.  In "sdm845-db845c" you maybe miss
adding the "memory-region" back to the WiFi?  Have you tried running
something like this before/after:

for f in sdm845*.dtb; do   dtc -I dtb -O dts --sort $f > $f.dts; done

You've gotta ignore phandle ID differences but otherwise it'll point
out things like this.


-Doug

Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz

[Marek Behún]

On Tue, 09 Feb 2021 15:16:45 -0800
nnet  wrote:

> I've two of these and I've just swapped them (and re-pasted the heat sinks).
> 
> The second one ran under load for awhile and now has frozen as well.
> 
> Under a moderate load `wget -O /dev/null ` @X00Mbits they are fine.
> 
> Under a 1 min speed test of load ~200Mbits routed WireGuard they freeze.
> 
> They fine with both those workloads @1000_800.
> 
> Perhaps it's heat? Unfortunately I don't have any numbers on that ATM.

Try disabling cpufreq in kernel completely, compile boot image at
1200 MHz. If it continues freezing, then I fear we can't help you with
1200 MHz :(

Marek

Re: [PATCH 02/16] dt-bindings: net: Add Baikal-T1 GMAC bindings

[Rob Herring]

On Mon, Feb 08, 2021 at 05:08:06PM +0300, Serge Semin wrote:
> Baikal-T1 SoC is equipped with two DW GMAC v3.73a-based 1GBE ethernet
> interfaces synthesized with: RGMII PHY interface, AXI-DMA and APB3 CSR,
> 16KB Tx/Rx FIFOs and PBL up to half of that, PTP, PMT, TCP/IP CoE, up to 4
> outstanding AXI read/write requests, maximum AXI burst length of 16 beats,
> up to eight MAC address slots, one GPI and one GPO ports. Generic DW
> MAC/STMMAC driver will easily handle the DT-node describing the Baikal-T1
> GMAC network devices, but the bindings still needs to be created to have a
> better understanding of what the interface looks like.
> 
> Signed-off-by: Serge Semin 
> 
> ---
> 
> Rob, please note I couldn't declare the axi-config object properties 
> constraints
> without specifying the properties type and description. If I remove them the
> dt_binding_check will curse with the error:
> 
> >> .../baikal,bt1-gmac.yaml: properties:axi-config:properties:snps,blen: 
> >> 'description' is a required property
> >> .../baikal,bt1-gmac.yaml: 
> >> properties:axi-config:properties:snps,wr_osr_lmt: 'oneOf' conditional 
> >> failed, one must be fixed:
> 'type' is a required property
> Additional properties are not allowed ('maximum' was unexpected)
> >> ...
> 
> I did't know what to do with these errors, so I just created normal sub-node
> properties with stricter constraints than they are specified in the main
> snps,dwmac.yaml schema. Any suggestion what is a better way to apply
> additional constraints on sub-node properties?

Yes, that's known problem which I don't have a solution for. I think the 
solution is checking all properties have a type defined once and only 
once. That would also make sure we don't have 2 property names with 
different types. With that we can loosen the meta-schema checks. In the 
vast majority of cases though we need a type, so the exceptions like 
here will need to duplicate the type and description.


Reviewed-by: Rob Herring 

> ---
>  .../bindings/net/baikal,bt1-gmac.yaml | 150 ++
>  1 file changed, 150 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/net/baikal,bt1-gmac.yaml

Dearest

[Mrs. Sophia]

Hello My Dearest

Please I appeal to you to exercise a little patience and read through
my mail carefully, I am contacting you personally for investment
assistance and a long term business relationship in your Country.

I am Mrs. Sophia Robin  a citizen of the united state of America ,  I
work at HSBC Bank in Milan Italy  as a Telex Manager charge of wire
transfer department.

I am contacting you for an important and  urgent business transaction,
I  want the bank to transfer the money left by Dr. Cheng Chao,  A
Chinese  Politician who  died, March 17th 2020 without any trace of
his family members,  he used our bank to launder money overseas
through the help of their Political advisers. And most of the funds
which they transferred out of the shores of China  were gold and oil
money that was supposed to have been used to develop the continent.
Can you invest this money and also help the poor ? The amount value at
$15.5million Dollars  ($US15,500,000), left in his account still
unclaimed, if you know that you are capable to invest this fund into
any  profitable business in your country kindly send me your details
information as listed below to enable me draft you an application form
of claim along with the deposit certificate which you are going to
fill with your bank account detail necessary and contact the HSBC Bank
in Italy  for immediate transfer of the Amounted sum into your bank
account direct.

Percentage share will be 60,for me/ 40, for you.

(1) Your full name..
(2) Your address
(3) Your Nationality.
(4) Your Age / Sex.
(5) Your  Occupation
(6) Your marital status..
(7) Your direct telephone number..
(8) Your photo...

Thanks with my best regards.
Mrs. Sophia Robin
Telex Manager
Milan Italy  (H.S.B.C)

Re: [PATCH 1/2] ext4: Handle casefolding with encryption

[Theodore Ts'o]

On Wed, Feb 03, 2021 at 11:31:28AM -0500, Theodore Ts'o wrote:
> On Wed, Feb 03, 2021 at 03:55:06AM -0700, Andreas Dilger wrote:
> > 
> > It looks like this change will break the dirdata feature, which is similarly
> > storing a data field beyond the end of the dirent. However, that feature 
> > also
> > provides for flags stored in the high bits of the type field to indicate
> > which of the fields are in use there.
> > The first byte of each field stores
> > the length, so it can be skipped even if the content is not understood.
> 
> Daniel, for context, the dirdata field is an out-of-tree feature which
> is used by Lustre, and so has fairly large deployed base.  So if there
> is a way that we can accomodate not breaking dirdata, that would be
> good.
> 
> Did the ext4 casefold+encryption implementation escape out to any
> Android handsets?

So from an OOB chat with Daniel, it appears that the ext4
casefold+encryption implementation did in fact escape out to Android
handsets.  So I think what we will need to do, ultiumately, is support
one way of supporting the casefold IV in the case where "encryption &&
casefold", and another way when "encryption && casefold && dirdata".

That's going to be a bit sucky, but I don't think it should be that
complex.  Daniel, Andreas, does that make sense to you?

   - Ted

[PATCH] ubsan: remove overflow checks

[Andrey Ryabinin]

Since GCC 8.0 -fsanitize=signed-integer-overflow doesn't work with -fwrapv.
-fwrapv makes signed overflows defines and GCC essentially disables
ubsan checks. On GCC < 8.0 -fwrapv doesn't have influence on
-fsanitize=signed-integer-overflow setting, so it kinda works
but generates false-positves and violates uaccess rules:

lib/iov_iter.o: warning: objtool: iovec_from_user()+0x22d: call to 
__ubsan_handle_add_overflow() with UACCESS enabled

Disable signed overflow checks to avoid these problems.
Remove unsigned overflow checks as well.
Unsigned overflow appeared as side effect of the commit
 cdf8a76fda4a ("ubsan: move cc-option tests into Kconfig"),
but it never worked (kernel doesn't boot). And unsigned overflows
are allowed by C standard, so it just pointless.

Signed-off-by: Andrey Ryabinin 
Cc: Peter Zijlstra 
Cc: Josh Poimboeuf 
Cc: Randy Dunlap 
Cc: Stephen Rothwell 
Cc: Dmitry Vyukov 
Cc: Kees Cook 
Cc: Alexander Viro 
---
 lib/Kconfig.ubsan  | 17 ---
 lib/test_ubsan.c   | 49 --
 lib/ubsan.c| 68 --
 scripts/Makefile.ubsan |  2 --
 4 files changed, 136 deletions(-)

diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan
index 3a0b1c930733..e5372a13511d 100644
--- a/lib/Kconfig.ubsan
+++ b/lib/Kconfig.ubsan
@@ -112,23 +112,6 @@ config UBSAN_UNREACHABLE
  This option enables -fsanitize=unreachable which checks for control
  flow reaching an expected-to-be-unreachable position.
 
-config UBSAN_SIGNED_OVERFLOW
-   bool "Perform checking for signed arithmetic overflow"
-   default UBSAN
-   depends on $(cc-option,-fsanitize=signed-integer-overflow)
-   help
- This option enables -fsanitize=signed-integer-overflow which checks
- for overflow of any arithmetic operations with signed integers.
-
-config UBSAN_UNSIGNED_OVERFLOW
-   bool "Perform checking for unsigned arithmetic overflow"
-   depends on $(cc-option,-fsanitize=unsigned-integer-overflow)
-   depends on !X86_32 # avoid excessive stack usage on x86-32/clang
-   help
- This option enables -fsanitize=unsigned-integer-overflow which checks
- for overflow of any arithmetic operations with unsigned integers. This
- currently causes x86 to fail to boot.
-
 config UBSAN_OBJECT_SIZE
bool "Perform checking for accesses beyond the end of objects"
default UBSAN
diff --git a/lib/test_ubsan.c b/lib/test_ubsan.c
index 5e5d9355ef49..7e7bbd0f3fd2 100644
--- a/lib/test_ubsan.c
+++ b/lib/test_ubsan.c
@@ -11,51 +11,6 @@ typedef void(*test_ubsan_fp)(void);
#config, IS_ENABLED(config) ? "y" : "n");   \
} while (0)
 
-static void test_ubsan_add_overflow(void)
-{
-   volatile int val = INT_MAX;
-   volatile unsigned int uval = UINT_MAX;
-
-   UBSAN_TEST(CONFIG_UBSAN_SIGNED_OVERFLOW);
-   val += 2;
-
-   UBSAN_TEST(CONFIG_UBSAN_UNSIGNED_OVERFLOW);
-   uval += 2;
-}
-
-static void test_ubsan_sub_overflow(void)
-{
-   volatile int val = INT_MIN;
-   volatile unsigned int uval = 0;
-   volatile int val2 = 2;
-
-   UBSAN_TEST(CONFIG_UBSAN_SIGNED_OVERFLOW);
-   val -= val2;
-
-   UBSAN_TEST(CONFIG_UBSAN_UNSIGNED_OVERFLOW);
-   uval -= val2;
-}
-
-static void test_ubsan_mul_overflow(void)
-{
-   volatile int val = INT_MAX / 2;
-   volatile unsigned int uval = UINT_MAX / 2;
-
-   UBSAN_TEST(CONFIG_UBSAN_SIGNED_OVERFLOW);
-   val *= 3;
-
-   UBSAN_TEST(CONFIG_UBSAN_UNSIGNED_OVERFLOW);
-   uval *= 3;
-}
-
-static void test_ubsan_negate_overflow(void)
-{
-   volatile int val = INT_MIN;
-
-   UBSAN_TEST(CONFIG_UBSAN_SIGNED_OVERFLOW);
-   val = -val;
-}
-
 static void test_ubsan_divrem_overflow(void)
 {
volatile int val = 16;
@@ -155,10 +110,6 @@ static void test_ubsan_object_size_mismatch(void)
 }
 
 static const test_ubsan_fp test_ubsan_array[] = {
-   test_ubsan_add_overflow,
-   test_ubsan_sub_overflow,
-   test_ubsan_mul_overflow,
-   test_ubsan_negate_overflow,
test_ubsan_shift_out_of_bounds,
test_ubsan_out_of_bounds,
test_ubsan_load_invalid_value,
diff --git a/lib/ubsan.c b/lib/ubsan.c
index bec38c64d6a6..26229973049d 100644
--- a/lib/ubsan.c
+++ b/lib/ubsan.c
@@ -163,74 +163,6 @@ static void ubsan_epilogue(void)
}
 }
 
-static void handle_overflow(struct overflow_data *data, void *lhs,
-   void *rhs, char op)
-{
-
-   struct type_descriptor *type = data->type;
-   char lhs_val_str[VALUE_LENGTH];
-   char rhs_val_str[VALUE_LENGTH];
-
-   if (suppress_report(>location))
-   return;
-
-   ubsan_prologue(>location, type_is_signed(type) ?
-   "signed-integer-overflow" :
-   "unsigned-integer-overflow");
-
-   val_to_string(lhs_val_str, sizeof(lhs_val_str), type, lhs);
-   val_to_string(rhs_val_str, 

[GIT PULL] timer drivers for v5.12

[Daniel Lezcano]

Hi Thomas,

please consider pulling the following changes for v5.12.

Thanks

  -- Daniel


The following changes since commit e85c1d21b16b278f50d191155bc674633270e9c6:

  clocksource/drivers/timer-microchip-pit64b: Add clocksource
suspend/resume (2021-02-03 09:36:50 +0100)

are available in the Git repository at:

  https://git.linaro.org/people/daniel.lezcano/linux.git
tags/timers-v5.12-rc1

for you to fetch changes up to e85c1d21b16b278f50d191155bc674633270e9c6:

  clocksource/drivers/timer-microchip-pit64b: Add clocksource
suspend/resume (2021-02-03 09:36:50 +0100)


- Drop dead code on efm32 (Uwe Kleine-König)

- Move pr_fmt() before the includes on davinci driver (Bartosz
  Golaszewski)

- Clarified timer interrupt must be specified on nuvoton DT bindings
  (Jonathan Neuschäfer)

- Remove tango, sirf, u300 and atlas timer drivers (Arnd Bergman)

- Add suspend/resume on pit64b (Claudiu Beznea)



-- 
 Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

[GIT PULL] I3C fixes for 5.11

[Alexandre Belloni]

Hello Linus,

Here is a single compilation warning fix for v5.11.

The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e:

  Linux 5.11-rc1 (2020-12-27 15:30:22 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/i3c/linux.git 
tags/i3c/fixes-for-5.11

for you to fetch changes up to 291b5c9870fc546376d69cf792b7885cd0c9c1b3:

  i3c/master/mipi-i3c-hci: Fix position of __maybe_unused in i3c_hci_of_match 
(2020-12-31 18:41:37 +0100)


I3C fixes for 5.11

Drivers:
 - mipi-i3c-hci: fix compilation warning with Clang


Nathan Chancellor (1):
  i3c/master/mipi-i3c-hci: Fix position of __maybe_unused in 
i3c_hci_of_match

 drivers/i3c/master/mipi-i3c-hci/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: Conflict with Mickaël Salaün's blacklist patches [was [PATCH v5 0/4] Add EFI_CERT_X509_GUID support for dbx/mokx entries]

[Mickaël Salaün]

On 09/02/2021 00:05, Eric Snowberg wrote:
> 
>> On Feb 6, 2021, at 11:30 AM, Mickaël Salaün  wrote:
>>
>> On 06/02/2021 02:14, Eric Snowberg wrote:
>>
>>> I have done some additional testing, I am seeing a regression. The 
>>> blacklist 
>>> keyring is no longer picking up any of the hashes from the dbx during boot. 
>>> I backed out the merge with my changes  
>>> (fdbbe7ceeb95090d09c33ce0497e0394c82aa33d) 
>>> and still see the regression.  I then backed out Mickaël merge
>>> (5bf1adccf5c41dbdd51d1f4de220d335d9548598) and it fixes the regression.
>>>
>>> On a x86 with the updated dbx from uefi.org, I’d expect to see 234 bin hash 
>>> entries
>>> in the blacklist keyring.  With the current merged code, there is none.
>>
>> Hum, I missed a part in refactoring (commit
>> f78e50c8f750c0ac6767ac1ed006360cf77c56c4). :/
>> Could you please test the following patch?
>>
>> diff --git a/certs/blacklist.c b/certs/blacklist.c
>> index 07c592ae5307..f998a2e85ddc 100644
>> --- a/certs/blacklist.c
>> +++ b/certs/blacklist.c
>> @@ -197,13 +197,16 @@ int mark_hash_blacklisted(const u8 *hash, size_t
>> hash_len,
>>enum blacklist_hash_type hash_type)
>> {
>>const char *buffer;
>> +   int err;
>>
>>buffer = get_raw_hash(hash, hash_len, hash_type);
>>if (IS_ERR(buffer))
>>return PTR_ERR(buffer);
>> +   err = mark_raw_hash_blacklisted(buffer);
>>kfree(buffer);
>> -   return 0;
>> +   return err;
>> }
> 
> I applied this patch, it works better, but there is still a regression. 
> Most of the hashes show up in the blacklist keyring now.  However some 
> do not, here is what I see in the log during boot:
> 
> [2.321876] blacklist: Problem blacklisting hash (-13)
> [2.322729] blacklist: Problem blacklisting hash (-13)
> [2.323549] blacklist: Problem blacklisting hash (-13)
> [2.324369] blacklist: Problem blacklisting hash (-13)
> 
>> Is it possible to test these kind of dbx blacklist with Qemu?
> 
> Yes, just use OVMF. 
> 

My changes (with the fix) don't change the previous semantic. I just
tested without my changes and with my changes (and the fix), and I get
the same result: 184 bin hashes with
https://uefi.org/sites/default/files/resources/dbxupdate_x64.bin

Could you please re-test and if there is still an issue bisect and share
the certificates causing this issue?

David, do you want me to send the two new patches or an updated full
patch series?

Re: [v7 PATCH 01/12] mm: vmscan: use nid from shrink_control for tracepoint

[Roman Gushchin]

On Tue, Feb 09, 2021 at 09:46:35AM -0800, Yang Shi wrote:
> The tracepoint's nid should show what node the shrink happens on, the start 
> tracepoint
> uses nid from shrinkctl, but the nid might be set to 0 before end tracepoint 
> if the
> shrinker is not NUMA aware, so the traceing log may show the shrink happens 
> on one
> node but end up on the other node.  It seems confusing.  And the following 
> patch
> will remove using nid directly in do_shrink_slab(), this patch also helps 
> cleanup
> the code.
> 
> Acked-by: Vlastimil Babka 
> Acked-by: Kirill Tkhai 
> Signed-off-by: Yang Shi 

Acked-by: Roman Gushchin 

> ---
>  mm/vmscan.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index b1b574ad199d..b512dd5e3a1c 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -535,7 +535,7 @@ static unsigned long do_shrink_slab(struct shrink_control 
> *shrinkctl,
>   else
>   new_nr = atomic_long_read(>nr_deferred[nid]);
>  
> - trace_mm_shrink_slab_end(shrinker, nid, freed, nr, new_nr, total_scan);
> + trace_mm_shrink_slab_end(shrinker, shrinkctl->nid, freed, nr, new_nr, 
> total_scan);
>   return freed;
>  }
>  
> -- 
> 2.26.2
> 

Re: [PATCH 1/2] dt-bindings: mailbox: omap: Update binding for AM64x SoCs

[Suman Anna]

On 2/9/21 1:24 PM, Rob Herring wrote:
> On Wed, Jan 27, 2021 at 01:55:59PM -0600, Suman Anna wrote:
>> Update the existing OMAP Mailbox binding to include the info for
>> AM64x SoCs. There are some minor IP integration differences between
>> the AM64x SoCs and the previous AM65x and J721E SoC families.
>>
>> Signed-off-by: Suman Anna 
>> ---
>>  .../bindings/mailbox/omap-mailbox.txt | 22 +++
>>  1 file changed, 22 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt 
>> b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
>> index 5fe80c1c19fc..c993d1a5c14a 100644
>> --- a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
>> +++ b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
>> @@ -28,6 +28,9 @@ SoCs has each of these instances form a cluster and 
>> combine multiple clusters
>>  into a single IP block present within the Main NavSS. The interrupt lines 
>> from
>>  all these clusters are multiplexed and routed to different processor 
>> subsystems
>>  over a limited number of common interrupt output lines of an Interrupt 
>> Router.
>> +The AM64x SoCS also uses a single IP block comprising of multiple clusters,
>> +but the number of clusters are smaller, and the interrupt output lines are
>> +connected directly to various processors.
>>  
>>  Mailbox Device Node:
>>  
>> @@ -42,6 +45,7 @@ Required properties:
>>  "ti,omap4-mailbox" for OMAP44xx, OMAP54xx, AM33xx,
>> AM43xx and DRA7xx SoCs
>>  "ti,am654-mailbox" for K3 AM65x and J721E SoCs
>> +"ti,am64-mailbox" for K3 AM64x SoCs
>>  - reg:  Contains the mailbox register address range 
>> (base
>>  address and length)
>>  - interrupts:   Contains the interrupt information for the 
>> mailbox
>> @@ -178,3 +182,21 @@ mailbox: mailbox@480c8000 {
>>  };
>>  };
>>  };
>> +
>> +4. /* AM64x */
>> +_main {
> 
> Please don't add examples for just a new compatible.

Thanks, will keep this in mind for the future and drop this as well just like on
the HwSpinlock binding update.

regards
Suman

> 
>> +mailbox0_cluster2: mailbox@2902 {
>> +compatible = "ti,am64-mailbox";
>> +reg = <0x00 0x2902 0x00 0x200>;
>> +interrupts = ,
>> + ;
>> +#mbox-cells = <1>;
>> +ti,mbox-num-users = <4>;
>> +ti,mbox-num-fifos = <16>;
>> +
>> +mbox_main_r5fss0_core0: mbox-main-r5fss0-core0 {
>> +ti,mbox-rx = <0 0 2>;
>> +ti,mbox-tx = <1 0 2>;
>> +};
>> +};
>> +};
>> -- 
>> 2.29.2
>>

Re: [PATCH v4 4/8] of: property: Add fw_devlink support for optional properties

[Saravana Kannan]

On Tue, Feb 9, 2021 at 1:33 PM Rob Herring  wrote:
>
> On Fri, Feb 05, 2021 at 02:26:40PM -0800, Saravana Kannan wrote:
> > Not all DT bindings are mandatory bindings. Add support for optional DT
> > bindings and mark iommus, iommu-map, dmas as optional DT bindings.
>
> I don't think we can say these are optional or not. It's got to be a
> driver decision somehow.

Right, so maybe the word "optional" isn't a good name for it. I can
change that if you want.

The point being, fw_devlink can't block the probe of this driver based
on iommu property. We let the driver decide if it wants to
-EPROBE_DEFER or not or however it wants to handle this.

> For example, if IOMMU is optional, what happens with this sequence:
>
> driver probes without IOMMU
> driver calls dma_map_?()
> IOMMU driver probes
> h/w accesses DMA buffer --> BOOM!

Right. But how is this really related to fw_devlink? AFAICT, this is
an issue even today. If the driver needs the IOMMU, then it needs to
make sure the IOMMU has probed? What am I missing?

-Saravana

Re: [PATCH] drivers: soc: atmel: fix type for same7

[Arnd Bergmann]

From: Arnd Bergmann 

On Thu, 4 Feb 2021 16:49:25 +0100, Arnd Bergmann wrote:
> A missing comma caused a build failure:
> 
> drivers/soc/atmel/soc.c:196:24: error: too few arguments provided to 
> function-like macro invocation

Applied to arm/drivers, thanks!

[1/1] drivers: soc: atmel: fix type for same7
  commit: 7deff441f53cc148cbf18381bd252a754b0d7d4e

   Arnd

Ju lutemi përgjigjeni emailin tim të mëparshëm.

[Lisa Jaster]

Ju lutemi përgjigjeni emailin tim të mëparshëm.

[PATCH 1/2] power: supply: bq25980: Applies multiple fixes brought on

[Ricardo Rivera-Matos]

fix: corrects various register step size and offset values

fix: corrects bq25980_get_input_curr_lim() and bq25980_set_input_curr_lim()

fix: corrects bq25980_get_const_charge_curr() and 
bq25980_set_const_charge_curr()

fix: corrects BQ25960_BATOVP_MIN_uV, BQ25960_BATOVP_OFFSET_uV,

BQ25960_BATOVP_STEP_uV, and BQ25960_BATOVP_MAX_uV

fix: corrects busocp_sc_min and busocp_byp_min members

fix: removes unnecessary polarity check from bq25980_get_adc_ibus()

fix: removes unnecessary polarity check from bq25980_get_adc_ibat()

fix: clamps ibat_adc to match datasheet change

Fixes: 5069185fc18e ("power: supply: bq25980: Add support for the BQ259xx 
family")
Signed-off-by: Ricardo Rivera-Matos 
---
 drivers/power/supply/bq25980_charger.c | 141 -
 drivers/power/supply/bq25980_charger.h |  77 ++
 2 files changed, 173 insertions(+), 45 deletions(-)

diff --git a/drivers/power/supply/bq25980_charger.c 
b/drivers/power/supply/bq25980_charger.c
index 530ff4025b31..7c489a9e8877 100644
--- a/drivers/power/supply/bq25980_charger.c
+++ b/drivers/power/supply/bq25980_charger.c
@@ -52,6 +52,10 @@ struct bq25980_chip_info {
int busocp_byp_max;
int busocp_sc_min;
int busocp_byp_min;
+   int busocp_sc_step;
+   int busocp_byp_step;
+   int busocp_sc_offset;
+   int busocp_byp_offset;
 
int busovp_sc_def;
int busovp_byp_def;
@@ -73,6 +77,20 @@ struct bq25980_chip_info {
 
int batocp_def;
int batocp_max;
+   int batocp_min;
+   int batocp_step;
+
+   int vbus_adc_step;
+   int vbus_adc_offset;
+
+   int ibus_adc_step;
+   int ibus_adc_offset;
+
+   int vbat_adc_step;
+   int vbat_adc_offset;
+
+   int ibat_adc_step;
+   int ibat_adc_offset;
 };
 
 struct bq25980_init_data {
@@ -275,13 +293,22 @@ static int bq25980_watchdog_time[BQ25980_NUM_WD_VAL] = 
{5000, 1, 5,
 static int bq25980_get_input_curr_lim(struct bq25980_device *bq)
 {
unsigned int busocp_reg_code;
+   int offset, step;
int ret;
 
+   if (bq->state.bypass) {
+   step = bq->chip_info->busocp_byp_step;
+   offset = bq->chip_info->busocp_byp_offset;
+   } else {
+   step = bq->chip_info->busocp_sc_step;
+   offset = bq->chip_info->busocp_sc_offset;
+   }
+
ret = regmap_read(bq->regmap, BQ25980_BUSOCP, _reg_code);
if (ret)
return ret;
 
-   return (busocp_reg_code * BQ25980_BUSOCP_STEP_uA) + 
BQ25980_BUSOCP_OFFSET_uA;
+   return (busocp_reg_code * step) + offset;
 }
 
 static int bq25980_set_hiz(struct bq25980_device *bq, int setting)
@@ -293,6 +320,7 @@ static int bq25980_set_hiz(struct bq25980_device *bq, int 
setting)
 static int bq25980_set_input_curr_lim(struct bq25980_device *bq, int busocp)
 {
unsigned int busocp_reg_code;
+   int step, offset;
int ret;
 
if (!busocp)
@@ -303,13 +331,17 @@ static int bq25980_set_input_curr_lim(struct 
bq25980_device *bq, int busocp)
if (busocp < BQ25980_BUSOCP_MIN_uA)
busocp = BQ25980_BUSOCP_MIN_uA;
 
-   if (bq->state.bypass)
+   if (bq->state.bypass) {
busocp = min(busocp, bq->chip_info->busocp_sc_max);
-   else
+   step = bq->chip_info->busocp_byp_step;
+   offset = bq->chip_info->busocp_byp_offset;
+   } else {
busocp = min(busocp, bq->chip_info->busocp_byp_max);
+   step = bq->chip_info->busocp_sc_step;
+   offset = bq->chip_info->busocp_sc_offset;
+   }
 
-   busocp_reg_code = (busocp - BQ25980_BUSOCP_OFFSET_uA)
-   / BQ25980_BUSOCP_STEP_uA;
+   busocp_reg_code = (busocp - offset) / step;
 
ret = regmap_write(bq->regmap, BQ25980_BUSOCP, busocp_reg_code);
if (ret)
@@ -374,6 +406,7 @@ static int bq25980_set_input_volt_lim(struct bq25980_device 
*bq, int busovp)
 
 static int bq25980_get_const_charge_curr(struct bq25980_device *bq)
 {
+   int step = bq->chip_info->batocp_step;
unsigned int batocp_reg_code;
int ret;
 
@@ -381,19 +414,20 @@ static int bq25980_get_const_charge_curr(struct 
bq25980_device *bq)
if (ret)
return ret;
 
-   return (batocp_reg_code & BQ25980_BATOCP_MASK) *
-   BQ25980_BATOCP_STEP_uA;
+   return (batocp_reg_code & BQ25980_BATOCP_MASK) * step;
 }
 
 static int bq25980_set_const_charge_curr(struct bq25980_device *bq, int batocp)
 {
+   int step = bq->chip_info->batocp_step;
+   int max = bq->chip_info->batocp_max;
+   int min = bq->chip_info->batocp_min;
unsigned int batocp_reg_code;
int ret;
 
-   batocp = max(batocp, BQ25980_BATOCP_MIN_uA);
-   batocp = min(batocp, bq->chip_info->batocp_max);
+   batocp = clamp(batocp, min, max);
 
-   batocp_reg_code = batocp / 

Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz

[nnet]

I've two of these and I've just swapped them (and re-pasted the heat sinks).

The second one ran under load for awhile and now has frozen as well.

Under a moderate load `wget -O /dev/null ` @X00Mbits they are fine.

Under a 1 min speed test of load ~200Mbits routed WireGuard they freeze.

They fine with both those workloads @1000_800.

Perhaps it's heat? Unfortunately I don't have any numbers on that ATM.

On Tue, Feb 9, 2021, at 2:56 PM, Pali Rohár wrote:
> On Tuesday 09 February 2021 14:52:56 nnet wrote:
> > On Tue, Feb 9, 2021, at 2:42 PM, Pali Rohár wrote:
> > > On Tuesday 09 February 2021 13:45:08 nnet wrote:
> > > > On Tue, Feb 9, 2021, at 1:33 PM, Pali Rohár wrote:
> > > > > On Tuesday 09 February 2021 13:00:26 nnet wrote:
> > > > > > > If you have other Armada 3720 boards (Espressobin v5/v7, uDPU, 
> > > > > > > Devel Board, ...) then it will be nice to do an additional tests 
> > > > > > > and check if instability issues are finally fixed.
> > > > > > 
> > > > > > These patches applied to the 5.4.96 in OpenWrt (98d61b5) work fine 
> > > > > > so far on an Espressobin v7 AFAICT per changing values in 
> > > > > > /sys/devices/system/cpu/cpufreq/policy0.
> > > > > > 
> > > > > > Are these changes intended to work @1.2 GHz on the v7?
> > > > > 
> > > > > Hello! Do you have 1.2 GHz A3720 SoC?
> > > > 
> > > > Maybe (not)? ESPRESSObin_V7_1-0 on the underside.
> > > 
> > > Look at the package of SoC chip. On top of the package is printed
> > > identifier 88F3720. On the last line should be one of the string:
> > > C080, C100, C120, I080, I100 which identifies frequency
> > > (080 = 800 MHz, 100 = 1 GHz, 120 = 1.2 GHz)
> > > 
> > > Can you check what is printed on A3720 SoC package?
> > 
> > Both of mine are 88F3720-A0-C120.
> 
> Interesting... it is really 1.2 GHz. I have not seen it yet. And few
> weeks ago I thought that it was never available on market.
> 
> Well, if 1.2 GHz variant has same issues as 1 GHz variants then this
> patch series should fix it. But you said that with this patch series is
> board crashing when running at 1.2 GHz?
>

Re: [PATCH] ubsan: Require GCC-8+ or Clang to use UBSAN

[Andrey Rybainin]

On 2/9/21 9:24 PM, Josh Poimboeuf wrote:
> On Mon, Jan 18, 2021 at 11:53:37AM -0600, Josh Poimboeuf wrote:
>> On Thu, Jan 14, 2021 at 02:09:28PM +0300, Andrey Ryabinin wrote:
>>>
>>>
>>> On 1/14/21 1:59 PM, Peter Zijlstra wrote:
 On Mon, Jan 04, 2021 at 04:13:17PM +0100, Peter Zijlstra wrote:
> On Tue, Dec 22, 2020 at 11:04:54PM -0600, Josh Poimboeuf wrote:
>> GCC 7 has a known bug where UBSAN ignores '-fwrapv' and generates false
>> signed-overflow-UB warnings.  The type mismatch between 'i' and
>> 'nr_segs' in copy_compat_iovec_from_user() is causing such a warning,
>> which also happens to violate uaccess rules:
>>
>>   lib/iov_iter.o: warning: objtool: iovec_from_user()+0x22d: call to 
>> __ubsan_handle_add_overflow() with UACCESS enabled
>>
>> Fix it by making the variable types match.
>>
>> This is similar to a previous commit:
>>
>>   29da93fea3ea ("mm/uaccess: Use 'unsigned long' to placate UBSAN 
>> warnings on older GCC versions")
>
> Maybe it's time we make UBSAN builds depend on GCC-8+ ?

 ---
 Subject: ubsan: Require GCC-8+ or Clang to use UBSAN

 Just like how we require GCC-8.2 for KASAN due to compiler bugs, require
 a sane version of GCC for UBSAN.

 Specifically, before GCC-8 UBSAN doesn't respect -fwrapv and thinks
 signed arithmetic is buggered.

>>>
>>> Actually removing CONFIG_UBSAN_SIGNED_OVERFLOW would give us the same
>>> effect without restricting GCC versions.
>>
>> Is that preferable?  Always happy to remove code, just need some
>> justification behind it.
> 
> Andrey,
> 
> Is Peter's patch acceptable or do you want to do something else?
> 

I do prefer to just remove the code, I'll send the patch shortly.

Re: [PATCH 6/8] lib: bitmap: support "N" as an alias for size of bitmap

[Yury Norov]

On Tue, Feb 9, 2021 at 3:01 PM Paul Gortmaker
 wrote:
>
> While this is done for all bitmaps, the original use case in mind was
> for CPU masks and cpulist_parse() as described below.
>
> It seems that a common configuration is to use the 1st couple cores for
> housekeeping tasks.  This tends to leave the remaining ones to form a
> pool of similarly configured cores to take on the real workload of
> interest to the user.
>
> So on machine A - with 32 cores, it could be 0-3 for "system" and then
> 4-31 being used in boot args like nohz_full=, or rcu_nocbs= as part of
> setting up the worker pool of CPUs.
>
> But then newer machine B is added, and it has 48 cores, and so while
> the 0-3 part remains unchanged, the pool setup cpu list becomes 4-47.
>
> Multiple deployment becomes easier when we can just simply replace 31
> and 47 with "N" and let the system substitute in the actual number at
> boot; a number that it knows better than we do.
>
> Cc: Yury Norov 
> Cc: Peter Zijlstra 
> Cc: "Paul E. McKenney" 
> Cc: Rasmus Villemoes 
> Cc: Andy Shevchenko 
> Suggested-by: Yury Norov  # move it from CPU code
> Signed-off-by: Paul Gortmaker 
> ---
>  .../admin-guide/kernel-parameters.rst |  7 +
>  lib/bitmap.c  | 27 ++-
>  2 files changed, 27 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.rst 
> b/Documentation/admin-guide/kernel-parameters.rst
> index 682ab28b5c94..7733a773f5f8 100644
> --- a/Documentation/admin-guide/kernel-parameters.rst
> +++ b/Documentation/admin-guide/kernel-parameters.rst
> @@ -68,6 +68,13 @@ For example one can add to the command line following 
> parameter:
>
>  where the final item represents CPUs 100,101,125,126,150,151,...
>
> +The value "N" can be used to represent the numerically last CPU on the 
> system,
> +i.e "foo_cpus=16-N" would be equivalent to "16-31" on a 32 core system.
> +
> +Keep in mind that "N" is dynamic, so if system changes cause the bitmap width
> +to change, such as less cores in the CPU list, then N and any ranges using N
> +will also change.  Use the same on a small 4 core system, and "16-N" becomes
> +"16-3" and now the same boot input will be flagged as invalid (start > end).
>
>
>  This document may not be entirely up to date and comprehensive. The command
> diff --git a/lib/bitmap.c b/lib/bitmap.c
> index 6b568f98af3d..cc7cb1fca1ac 100644
> --- a/lib/bitmap.c
> +++ b/lib/bitmap.c
> @@ -530,11 +530,17 @@ static int bitmap_check_region(const struct 
> bitmap_region *br)
> return 0;
>  }
>
> -static const char *bitmap_getnum(const char *str, unsigned int *num)
> +static const char *bitmap_getnum(const char *str, unsigned int *num,
> +unsigned int lastbit)

The idea of struct bitmap_region is avoid passing the lastbit to the functions.
But here you do pass. Can you please be consistent? Or if I misunderstand
the idea of struct bitmap_region, can you please clarify it?

Also, I don't think that in this specific case it's worth it to create
a hierarchy of
structures. Just adding lastbits to struct region will be simpler and more
transparent.

>  {
> unsigned long long n;
> unsigned int len;
>
> +   if (str[0] == 'N') {
> +   *num = lastbit;
> +   return str + 1;
> +   }
> +
> len = _parse_integer(str, 10, );
> if (!len)
> return ERR_PTR(-EINVAL);
> @@ -580,9 +586,12 @@ static const char *bitmap_find_region_reverse(const char 
> *start, const char *end
> return end;
>  }
>
> -static const char *bitmap_parse_region(const char *str, struct region *r)
> +static const char *bitmap_parse_region(const char *str, struct bitmap_region 
> *br)

It seems like you declare struct bitmap_region in patch 8, but use it
in patch 6.
Can you please reorder your patches and resubmit?

>  {
> -   str = bitmap_getnum(str, >start);
> +   struct region *r = br->r;
> +   unsigned int lastbit = br->nbits - 1;
> +
> +   str = bitmap_getnum(str, >start, lastbit);
> if (IS_ERR(str))
> return str;
>
> @@ -592,7 +601,7 @@ static const char *bitmap_parse_region(const char *str, 
> struct region *r)
> if (*str != '-')
> return ERR_PTR(-EINVAL);
>
> -   str = bitmap_getnum(str + 1, >end);
> +   str = bitmap_getnum(str + 1, >end, lastbit);
> if (IS_ERR(str))
> return str;
>
> @@ -602,14 +611,14 @@ static const char *bitmap_parse_region(const char *str, 
> struct region *r)
> if (*str != ':')
> return ERR_PTR(-EINVAL);
>
> -   str = bitmap_getnum(str + 1, >off);
> +   str = bitmap_getnum(str + 1, >off, lastbit);
> if (IS_ERR(str))
> return str;
>
> if (*str != '/')
> return ERR_PTR(-EINVAL);
>
> -   return bitmap_getnum(str + 1, >group_len);
> +   return bitmap_getnum(str + 1, >group_len, 

Re: [PATCH 0/4] btrfs: Convert kmaps to core page calls

[Ira Weiny]

On Tue, Feb 09, 2021 at 01:58:37PM -0800, Andrew Morton wrote:
> On Tue, 9 Feb 2021 13:52:29 -0800 Ira Weiny  wrote:
> 
> > > 
> > > Let's please queue this up separately.
> > 
> > Ok can I retain your Ack on the move part of the patch?
> 
> I missed that.
> 
> >  Note that it does change kmap_atomic() to kmap_local_page() currently.
> > 
> > Would you prefer a separate change for that as well?
> 
> Really that should be separated out as well, coming after the move, to
> make it more easily reverted.  With a standalone changlog for this.
> 
> All a bit of a pain, but it's best in the long run.

Consider it done.

Ira

BTW does anyone know the reason this thread is not making it to lore?  I don't
see any of the emails between Andrew and me?


https://lore.kernel.org/lkml/20210205232304.1670522-1-ira.we...@intel.com/

linux-next: Signed-off-by missing for commit in the arm-soc tree

[Stephen Rothwell]

Hi all,

Commit

  70ba3b1adbf5 ("arm64: defconfig: Enable RT5659")

is missing a Signed-off-by from its committer.

-- 
Cheers,
Stephen Rothwell


pgpMjyQjBZ9rf.pgp
Description: OpenPGP digital signature

Re: [PATCH 0/9] Add support for SVM atomics in Nouveau

[Jerome Glisse]

On Tue, Feb 09, 2021 at 09:35:20AM -0400, Jason Gunthorpe wrote:
> On Tue, Feb 09, 2021 at 11:57:28PM +1100, Alistair Popple wrote:
> > On Tuesday, 9 February 2021 9:27:05 PM AEDT Daniel Vetter wrote:
> > > >
> > > > Recent changes to pin_user_pages() prevent the creation of pinned pages 
> > > > in
> > > > ZONE_MOVABLE. This series allows pinned pages to be created in 
> > ZONE_MOVABLE
> > > > as attempts to migrate may fail which would be fatal to userspace.
> > > >
> > > > In this case migration of the pinned page is unnecessary as the page 
> > > > can 
> > be
> > > > unpinned at anytime by having the driver revoke atomic permission as it
> > > > does for the migrate_to_ram() callback. However a method of calling this
> > > > when memory needs to be moved has yet to be resolved so any discussion 
> > > > is
> > > > welcome.
> > > 
> > > Why do we need to pin for gpu atomics? You still have the callback for
> > > cpu faults, so you
> > > can move the page as needed, and hence a long-term pin sounds like the
> > > wrong approach.
> > 
> > Technically a real long term unmoveable pin isn't required, because as you 
> > say 
> > the page can be moved as needed at any time. However I needed some way of 
> > stopping the CPU page from being freed once the userspace mappings for it 
> > had 
> > been removed. 
> 
> The issue is you took the page out of the PTE it belongs to, which
> makes it orphaned and unlocatable by the rest of the mm?
> 
> Ideally this would leave the PTE in place so everything continues to
> work, just disable CPU access to it.
> 
> Maybe some kind of special swap entry?
> 
> I also don't much like the use of ZONE_DEVICE here, that should only
> be used for actual device memory, not as a temporary proxy for CPU
> pages.. Having two struct pages refer to the same physical memory is
> pretty ugly.
> 
> > The normal solution of registering an MMU notifier to unpin the page when 
> > it 
> > needs to be moved also doesn't work as the CPU page tables now point to the
> > device-private page and hence the migration code won't call any invalidate 
> > notifiers for the CPU page.
> 
> The fact the page is lost from the MM seems to be the main issue here.
> 
> > Yes, I would like to avoid the long term pin constraints as well if 
> > possible I 
> > just haven't found a solution yet. Are you suggesting it might be possible 
> > to 
> > add a callback in the page migration logic to specially deal with moving 
> > these 
> > pages?
> 
> How would migration even find the page?

Migration can scan memory from physical address (isolate_migratepages_range())
So the CPU mapping is not the only path to get to a page.

Cheers,
Jérôme

[PATCH] tpm: ibmvtpm: Avoid -EINTR error when IMA talks to TPM

[Stefan Berger]

When IMA is taking measurements during compilation for example and a
user presses ctrl-c to abort the compilation, lots of these types of
messages will appear in the kernel log:

[ 7406.275163] tpm tpm0: tpm_transmit: tpm_recv: error -4
[ 7406.275242] ima: Error Communicating to TPM chip, result: -4

The issue is caused by the fact that the IBM vTPM driver's recv()
function is called immediately after send() without waiting for
status on whether a response was received. It currently waits for
the current command to finish using this call that ends up throwing
these error messages because it is 'interruptible':

sig = wait_event_interruptible(ibmvtpm->wq,
   !ibmvtpm->tpm_processing_cmd);

Instead, it should be using the polling loop in tpm_try_transmit()
that uses a command's duration to poll until a result has been
returned by the TPM, thus ending when the timeout has occurred but
not responding to users' ctrl-c request anymore. To stay in this
polling loop we now extend tpm_ibmvtpm_status() to return
PM_STATUS_BUSY for as long as the vTPM is busy. Since we will need
the timeouts in this loop now we get the TPM 1.2 and TPM 2 timeouts
with tpm_get_timeouts().

We change tpm_processing_cmd to tpm_status and set the TPM_STATUS_BUSY
flag while the vTPM is busy processing a command.

Signed-off-by: Stefan Berger 
Fixes: 18b3670d79ae9 ("tpm: ibmvtpm: Add support for TPM2")
Cc: Nayna Jain 
Cc: George Wilson 
---
 drivers/char/tpm/tpm_ibmvtpm.c | 31 ++-
 drivers/char/tpm/tpm_ibmvtpm.h |  3 ++-
 2 files changed, 20 insertions(+), 14 deletions(-)

diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
index 994385bf37c0..6290bd8889e4 100644
--- a/drivers/char/tpm/tpm_ibmvtpm.c
+++ b/drivers/char/tpm/tpm_ibmvtpm.c
@@ -106,17 +106,12 @@ static int tpm_ibmvtpm_recv(struct tpm_chip *chip, u8 
*buf, size_t count)
 {
struct ibmvtpm_dev *ibmvtpm = dev_get_drvdata(>dev);
u16 len;
-   int sig;
 
if (!ibmvtpm->rtce_buf) {
dev_err(ibmvtpm->dev, "ibmvtpm device is not ready\n");
return 0;
}
 
-   sig = wait_event_interruptible(ibmvtpm->wq, 
!ibmvtpm->tpm_processing_cmd);
-   if (sig)
-   return -EINTR;
-
len = ibmvtpm->res_len;
 
if (count < len) {
@@ -220,11 +215,12 @@ static int tpm_ibmvtpm_send(struct tpm_chip *chip, u8 
*buf, size_t count)
return -EIO;
}
 
-   if (ibmvtpm->tpm_processing_cmd) {
+   if ((ibmvtpm->tpm_status & TPM_STATUS_BUSY)) {
dev_info(ibmvtpm->dev,
 "Need to wait for TPM to finish\n");
/* wait for previous command to finish */
-   sig = wait_event_interruptible(ibmvtpm->wq, 
!ibmvtpm->tpm_processing_cmd);
+   sig = wait_event_interruptible(ibmvtpm->wq,
+   (ibmvtpm->tpm_status & TPM_STATUS_BUSY) == 0);
if (sig)
return -EINTR;
}
@@ -237,7 +233,7 @@ static int tpm_ibmvtpm_send(struct tpm_chip *chip, u8 *buf, 
size_t count)
 * set the processing flag before the Hcall, since we may get the
 * result (interrupt) before even being able to check rc.
 */
-   ibmvtpm->tpm_processing_cmd = true;
+   ibmvtpm->tpm_status |= TPM_STATUS_BUSY;
 
 again:
rc = ibmvtpm_send_crq(ibmvtpm->vdev,
@@ -255,7 +251,7 @@ static int tpm_ibmvtpm_send(struct tpm_chip *chip, u8 *buf, 
size_t count)
goto again;
}
dev_err(ibmvtpm->dev, "tpm_ibmvtpm_send failed rc=%d\n", rc);
-   ibmvtpm->tpm_processing_cmd = false;
+   ibmvtpm->tpm_status &= ~TPM_STATUS_BUSY;
}
 
spin_unlock(>rtce_lock);
@@ -269,7 +265,9 @@ static void tpm_ibmvtpm_cancel(struct tpm_chip *chip)
 
 static u8 tpm_ibmvtpm_status(struct tpm_chip *chip)
 {
-   return 0;
+   struct ibmvtpm_dev *ibmvtpm = dev_get_drvdata(>dev);
+
+   return ibmvtpm->tpm_status;
 }
 
 /**
@@ -459,7 +457,7 @@ static const struct tpm_class_ops tpm_ibmvtpm = {
.send = tpm_ibmvtpm_send,
.cancel = tpm_ibmvtpm_cancel,
.status = tpm_ibmvtpm_status,
-   .req_complete_mask = 0,
+   .req_complete_mask = TPM_STATUS_BUSY,
.req_complete_val = 0,
.req_canceled = tpm_ibmvtpm_req_canceled,
 };
@@ -552,7 +550,7 @@ static void ibmvtpm_crq_process(struct ibmvtpm_crq *crq,
case VTPM_TPM_COMMAND_RES:
/* len of the data in rtce buffer */
ibmvtpm->res_len = be16_to_cpu(crq->len);
-   ibmvtpm->tpm_processing_cmd = false;
+   ibmvtpm->tpm_status &= ~TPM_STATUS_BUSY;
wake_up_interruptible(>wq);
return;
default:
@@ -690,8 +688,15 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev,

[PATCH 2/2] power: supply: bq25980: Moves properties from battery node

[Ricardo Rivera-Matos]

fix: exposes POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT on the

charger node

fix: exposes POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE on the

charger node

fix: eliminates unnecessary set_property for the battery node

Fixes: 5069185fc18e ("power: supply: bq25980: Add support for the BQ259xx 
family")
Signed-off-by: Ricardo Rivera-Matos 
---
 drivers/power/supply/bq25980_charger.c | 40 --
 1 file changed, 12 insertions(+), 28 deletions(-)

diff --git a/drivers/power/supply/bq25980_charger.c 
b/drivers/power/supply/bq25980_charger.c
index 7c489a9e8877..ac73e2c19238 100644
--- a/drivers/power/supply/bq25980_charger.c
+++ b/drivers/power/supply/bq25980_charger.c
@@ -641,33 +641,6 @@ static int bq25980_get_state(struct bq25980_device *bq,
return 0;
 }
 
-static int bq25980_set_battery_property(struct power_supply *psy,
-   enum power_supply_property psp,
-   const union power_supply_propval *val)
-{
-   struct bq25980_device *bq = power_supply_get_drvdata(psy);
-   int ret = 0;
-
-   switch (psp) {
-   case POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT:
-   ret = bq25980_set_const_charge_curr(bq, val->intval);
-   if (ret)
-   return ret;
-   break;
-
-   case POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE:
-   ret = bq25980_set_const_charge_volt(bq, val->intval);
-   if (ret)
-   return ret;
-   break;
-
-   default:
-   return -EINVAL;
-   }
-
-   return ret;
-}
-
 static int bq25980_get_battery_property(struct power_supply *psy,
enum power_supply_property psp,
union power_supply_propval *val)
@@ -736,6 +709,18 @@ static int bq25980_set_charger_property(struct 
power_supply *psy,
return ret;
break;
 
+   case POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT:
+   ret = bq25980_set_const_charge_curr(bq, val->intval);
+   if (ret)
+   return ret;
+   break;
+
+   case POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE:
+   ret = bq25980_set_const_charge_volt(bq, val->intval);
+   if (ret)
+   return ret;
+   break;
+
default:
return -EINVAL;
}
@@ -957,7 +942,6 @@ static struct power_supply_desc bq25980_battery_desc = {
.name   = "bq25980-battery",
.type   = POWER_SUPPLY_TYPE_BATTERY,
.get_property   = bq25980_get_battery_property,
-   .set_property   = bq25980_set_battery_property,
.properties = bq25980_battery_props,
.num_properties = ARRAY_SIZE(bq25980_battery_props),
.property_is_writeable  = bq25980_property_is_writeable,
-- 
2.30.0

Re: [PATCH 01/16] dt-bindings: net: dwmac: Add DW GMAC GPIOs properties

[Rob Herring]

On Mon, Feb 08, 2021 at 05:08:05PM +0300, Serge Semin wrote:
> Synopsys DesignWare Ethernet controllers can be synthesized with
> General-Purpose IOs support. GPIOs can work either as inputs or as outputs
> thus belong to the gpi_i and gpo_o ports respectively. The ports width
> (number of possible inputs/outputs) and the configuration registers layout
> depend on the IP-core version. For instance, DW GMAC can have from 0 to 4
> GPIs and from 0 to 4 GPOs, while DW xGMAC have a wider ports width up to
> 16 pins of each one.
> 
> So the DW MAC DT-node can be equipped with "ngpios" property, which can't
> have a value greater than 32, standard GPIO-related properties like
> "gpio-controller" and "#gpio-cells", and, if GPIs are supposed to be
> detected, IRQ-controller related properties.
> 
> Signed-off-by: Serge Semin 
> ---
>  .../devicetree/bindings/net/snps,dwmac.yaml | 17 +
>  1 file changed, 17 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml 
> b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> index bdc437b14878..fcca23d3727e 100644
> --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> @@ -110,6 +110,23 @@ properties:
>reset-names:
>  const: stmmaceth
>  
> +  ngpios:
> +description:
> +  Total number of GPIOs the MAC supports. The property shall include both
> +  the GPI and GPO ports width.
> +minimum: 1
> +maximum: 32

Does the driver actually need this? I'd omit it if just to validate 
consumers are in range.

Are GPI and GPO counts independent? If so, this isn't really sufficient.

Rob

Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz

[Pali Rohár]

On Tuesday 09 February 2021 14:52:56 nnet wrote:
> On Tue, Feb 9, 2021, at 2:42 PM, Pali Rohár wrote:
> > On Tuesday 09 February 2021 13:45:08 nnet wrote:
> > > On Tue, Feb 9, 2021, at 1:33 PM, Pali Rohár wrote:
> > > > On Tuesday 09 February 2021 13:00:26 nnet wrote:
> > > > > > If you have other Armada 3720 boards (Espressobin v5/v7, uDPU, 
> > > > > > Devel Board, ...) then it will be nice to do an additional tests 
> > > > > > and check if instability issues are finally fixed.
> > > > > 
> > > > > These patches applied to the 5.4.96 in OpenWrt (98d61b5) work fine so 
> > > > > far on an Espressobin v7 AFAICT per changing values in 
> > > > > /sys/devices/system/cpu/cpufreq/policy0.
> > > > > 
> > > > > Are these changes intended to work @1.2 GHz on the v7?
> > > > 
> > > > Hello! Do you have 1.2 GHz A3720 SoC?
> > > 
> > > Maybe (not)? ESPRESSObin_V7_1-0 on the underside.
> > 
> > Look at the package of SoC chip. On top of the package is printed
> > identifier 88F3720. On the last line should be one of the string:
> > C080, C100, C120, I080, I100 which identifies frequency
> > (080 = 800 MHz, 100 = 1 GHz, 120 = 1.2 GHz)
> > 
> > Can you check what is printed on A3720 SoC package?
> 
> Both of mine are 88F3720-A0-C120.

Interesting... it is really 1.2 GHz. I have not seen it yet. And few
weeks ago I thought that it was never available on market.

Well, if 1.2 GHz variant has same issues as 1 GHz variants then this
patch series should fix it. But you said that with this patch series is
board crashing when running at 1.2 GHz?

RE: [PATCH] x86, sched: Allow NUMA nodes to share an LLC on Intel platforms

[Luck, Tony]

> +#define X86_BUG_NUMA_SHARES_LLC  X86_BUG(25) /* CPU may 
> enumerate an LLC shared by multiple NUMA nodes */

During internal review I wondered why this is a "BUG" rather than a "FEATURE" 
bit.

Apparently, the suggestion for "BUG" came from earlier community discussions.

Historically it may have seemed reasonable to say that a cache cannot span
NUMA domains. But with more and more things moving off the motherboard
and into the socket, this doesn't seem too weird now.

-Tony

Re: [PATCH 14/18] dt-bindings: interrupt-controller: Add DT bindings for apple-aic

[Rob Herring]

On Fri, Feb 05, 2021 at 05:39:47AM +0900, Hector Martin wrote:
> AIC is the Apple Interrupt Controller found on Apple ARM SoCs, such as
> the M1.
> 
> Signed-off-by: Hector Martin 
> ---
>  .../interrupt-controller/AAPL,aic.yaml| 88 +++
>  MAINTAINERS   |  2 +
>  .../interrupt-controller/apple-aic.h  | 14 +++
>  3 files changed, 104 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/interrupt-controller/AAPL,aic.yaml
>  create mode 100644 include/dt-bindings/interrupt-controller/apple-aic.h
> 
> diff --git 
> a/Documentation/devicetree/bindings/interrupt-controller/AAPL,aic.yaml 
> b/Documentation/devicetree/bindings/interrupt-controller/AAPL,aic.yaml
> new file mode 100644
> index ..7e119614275a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interrupt-controller/AAPL,aic.yaml
> @@ -0,0 +1,88 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/interrupt-controller/AAPL,aic.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Apple Interrupt Controller
> +
> +maintainers:
> +  - Hector Martin 
> +
> +description: |
> +  The Apple Interrupt Controller is a simple interrupt controller present on
> +  Apple ARM SoC platforms, including various iPhone and iPad devices and the
> +  "Apple Silicon" M1 Macs.
> +
> +  It provides the following features:
> +
> +  - Level-triggered hardware IRQs wired to SoC blocks
> +- Single mask bit per IRQ
> +- Per-IRQ affinity setting
> +- Automatic masking on event delivery (auto-ack)
> +- Software triggering (ORed with hw line)
> +  - 2 per-CPU IPIs (meant as "self" and "other", but they are interchangeable
> +if not symmetric)
> +  - Automatic prioritization (single event/ack register per CPU, lower IRQs =
> +higher priority)
> +  - Automatic masking on ack
> +  - Default "this CPU" register view and explicit per-CPU views
> +
> +allOf:
> +  - $ref: /schemas/interrupt-controller.yaml#
> +
> +properties:
> +  compatible:
> +contains:
> +  enum:
> +- AAPL,aic
> +- AAPL,m1-aic

Instead of 'contains', this should be:

items:
  - const: AAPL,m1-aic
  - const: AAPL,aic

With 'apple' instead...

> +
> +  interrupt-controller: true
> +
> +  '#interrupt-cells':
> +const: 3
> +description: |
> +  The 1st cell contains the interrupt type:
> +- 0: Hardware IRQ
> +- 1: FIQ
> +- 2: IPI
> +
> +  The 2nd cell contains the interrupt number.
> +- HW IRQs: interrupt number
> +- FIQs:
> +  - 0: physical timer
> +  - 1: virtual timer
> +- IPIs:
> +  - 0: normal/"other" IPI (used interanlly for virtual IPIs)
> +  - 1: self IPI (normally unused)
> +
> +  The 3rd cell contains the interrupt flags. This is normally
> +  IRQ_TYPE_LEVEL_HIGH (4).
> +
> +  reg:
> +description: |
> +  Specifies base physical address and size of the AIC registers.
> +maxItems: 1
> +
> +required:
> +  - compatible
> +  - '#interrupt-cells'
> +  - interrupt-controller
> +  - reg
> +
> +unevaluatedProperties: false

additionalProperties: false

(stricter and actually has support implemented)

> +
> +examples:
> +  - |
> +soc {
> +#address-cells = <2>;
> +#size-cells = <2>;
> +
> +aic: interrupt-controller@23b10 {
> +compatible = "AAPL,m1-aic", "AAPL,aic";
> +#interrupt-cells = <3>;
> +interrupt-controller;
> +reg = <0x2 0x3b10 0x0 0x8000>;
> +};
> +};
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 91a7b33834ac..f3d4661731c8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1634,6 +1634,8 @@ B:  https://github.com/AsahiLinux/linux/issues
>  C:   irc://chat.freenode.net/asahi-dev
>  T:   git https://github.com/AsahiLinux/linux.git
>  F:   Documentation/devicetree/bindings/arm/AAPL.yaml
> +F:   Documentation/devicetree/bindings/interrupt-controller/AAPL,aic.yaml
> +F:   include/dt-bindings/interrupt-controller/apple-aic.h
>  
>  ARM/ARTPEC MACHINE SUPPORT
>  M:   Jesper Nilsson 
> diff --git a/include/dt-bindings/interrupt-controller/apple-aic.h 
> b/include/dt-bindings/interrupt-controller/apple-aic.h
> new file mode 100644
> index ..f54dc0cd6e9a
> --- /dev/null
> +++ b/include/dt-bindings/interrupt-controller/apple-aic.h
> @@ -0,0 +1,14 @@
> +/* SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause */
> +#ifndef _DT_BINDINGS_INTERRUPT_CONTROLLER_APPLE_AIC_H
> +#define _DT_BINDINGS_INTERRUPT_CONTROLLER_APPLE_AIC_H
> +
> +#include 
> +
> +#define AIC_IRQ 0
> +#define AIC_FIQ 1
> +#define AIC_IPI 2
> +
> +#define AIC_TMR_PHYS 0
> +#define AIC_TMR_VIRT 1
> +
> +#endif
> -- 
> 2.30.0
> 

Re: [PATCH] dt-bindings: power: renesas,apmu: Group tuples in cpus properties

[Rob Herring]

On Thu, 04 Feb 2021 13:55:42 +0100, Geert Uytterhoeven wrote:
> To improve human readability and enable automatic validation, the tuples
> in "cpus" properties in device nodes for Advanced Power Management Units
> for AP-System Core (APMU) should be grouped using angle brackets.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
>  Documentation/devicetree/bindings/power/renesas,apmu.yaml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Applied, thanks!

Re: [PATCH] ASoC: soc-pcm: change error message to debug message

[Pierre-Louis Bossart]

On 2/9/21 4:23 PM, Mark Brown wrote:

On Mon, Feb 08, 2021 at 09:06:44AM -0600, Pierre-Louis Bossart wrote:


If you demote this to dev_dbg, we'll have to ask every single user who
reports 'sound is broken' to enable dynamic debug traces. I really don't see
the benefit, this is a clear case of 'fail big and fail early', partly
concealing the problem doesn't make it go away but harder to diagnose.


Don't you also get the same information out of the DAPM debugfs or did
I misread where the error is generated from?


I re-checked and I will back-pedal on my comment. I confused this error 
message with the classic "ASoC: no backend DAIs enabled for %s".


I didn't find a single occurrence of this "ASoC: no BE found for %s" in 
any bug report or Google search.


Reviewed-by: Pierre-Louis Bossart 

Re: [GIT PULL] extcon next for v5.12

[Chanwoo Choi]

Dear Greg,

On Tue, Feb 9, 2021 at 7:43 PM Greg KH  wrote:
>
> On Tue, Feb 09, 2021 at 07:49:59PM +0900, Chanwoo Choi wrote:
> > Dear Greg,
> >
> > This is extcon-next pull request for v5.12. I add detailed description of
> > this pull request on below. Please pull extcon with following updates.
> >
> > Best Regards,
> > Chanwoo Choi
>
> I see the following error in this repo when trying to pull it:
>
> Commit d8cc19be483a ("extcon: sm5502: Detect OTG when USB_ID is connected to 
> ground")
> committer Signed-off-by missing
> author email:nikitos...@gmail.com
> committer email: cw00.c...@samsung.com
> Signed-off-by: Nikita Travkin 
>
> Please fix up.

It's my fault. I'm sorry. I'll resend the pull request.

Best Regards,
Chanwoo Choi

Re: [PATCH v3 1/3] drm/mediatek: mtk_dpi: Add check for max clock rate in mode_valid

[kernel test robot]

Hi Jitao,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on robh/for-next]
[also build test ERROR on pza/reset/next linux/master linus/master v5.11-rc7 
next-20210125]
[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/Jitao-Shi/Add-check-for-max-clock-rate-in-mode_valid/20210208-094340
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm64-randconfig-r023-20210209 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
c9439ca36342fb6013187d0a69aef92736951476)
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 arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# 
https://github.com/0day-ci/linux/commit/7036ee290c5a384eeaa0b45d739a8b024235671d
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Jitao-Shi/Add-check-for-max-clock-rate-in-mode_valid/20210208-094340
git checkout 7036ee290c5a384eeaa0b45d739a8b024235671d
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 

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

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/mediatek/mtk_dpi.c:574:16: error: incompatible function 
>> pointer types initializing 'enum drm_mode_status (*)(struct drm_bridge *, 
>> const struct drm_display_info *, const struct drm_display_mode *)' with an 
>> expression of type 'enum drm_mode_status (struct drm_bridge *, const struct 
>> drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types]
   .mode_valid = mtk_dpi_bridge_mode_valid,
 ^
   1 error generated.


vim +574 drivers/gpu/drm/mediatek/mtk_dpi.c

   570  
   571  static const struct drm_bridge_funcs mtk_dpi_bridge_funcs = {
   572  .attach = mtk_dpi_bridge_attach,
   573  .mode_set = mtk_dpi_bridge_mode_set,
 > 574  .mode_valid = mtk_dpi_bridge_mode_valid,
   575  .disable = mtk_dpi_bridge_disable,
   576  .enable = mtk_dpi_bridge_enable,
   577  };
   578  

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


.config.gz
Description: application/gzip

Trouble with perf_guest_get_msrs() and pebs_no_isolation

[Jim Mattson]

On a host that suffers from pebs_no_isolation, perf_guest_get_msrs()
adds an entry to cpuc->guest_switch_msrs for
MSR_IA32_PEBS_ENABLE. Kvm's atomic_switch_perf_msrs() is the only
caller of perf_guest_get_msrs(). If atomic_switch_perf_msrs() finds an
entry for MSR_IA32_PEBS_ENABLE in cpuc->guest_switch_msrs, it puts the
"host" value of this entry on the VM-exit MSR-load list for the
current VMCS. At the next VM-exit, that "host" value will be written
to MSR_IA32_PEBS_ENABLE.

The problem is that by the next VM-exit, that "host" value may be
stale. Though maskable interrupts are blocked from well before
atomic_switch_perf_msrs() to the next VM-entry, PMIs are delivered as
NMIs. Moreover, due to PMI throttling, the PMI handler may clear bits
in MSR_IA32_PEBS_ENABLE. See the comment to that effect in
handle_pmi_common(). In fact, by the time that perf_guest_get_msrs()
returns to its caller, the "host" value that it has recorded for
MSR_IA32_PEBS_ENABLE could already be stale.

What happens if a VM-exit sets a bit in MSR_IA32_PEBS_ENABLE that the
perf subsystem thinks should be clear? In the short term, nothing
happens at all. But note that this situation may not get better at the
next VM-exit, because kvm won't add MSR_IA32_PEBS_ENABLE to the
VM-exit MSR-load list if perf_guest_get_mrs() reports that the "host"
value of the MSR is 0. So, if the new MSR_IA32_PEBS_ENABLE "host"
value is 0, the stale bits can actually persist for a long time.

If, at some point in the future, the perf subsystem programs a counter
overflow interrupt on the same PMC for a PEBS-capable event, we are in
for some nasty surprises. (Note that the perf subsystem never
*intentionally* programs a PMC for both PEBS and counter overflow
interrupts at the same time.)

If a PEBS assist is triggered while in VMX non-root operation, the CPU
will try to access the host's DS_AREA using the guest's page tables,
and a page fault is likely (specifically on a read of the PEBS
interrupt threshold at offset 0x38 in the DS_AREA).

If the PEBS interrupt threshold is met while in VMX root operation,
two separate PMIs are generated: one for the PEBS interrupt threshold
and one for the counter overflow. This results in a message from
unknown_nmi_error(): "Uhhuh. NMI received for unknown reason  on
CPU ."

[PATCH] x86, sched: Allow NUMA nodes to share an LLC on Intel platforms

[Alison Schofield]

Commit 1340ccfa9a9a ("x86,sched: Allow topologies where NUMA nodes
share an LLC") added a vendor and model specific check to skip the
topology_sane() check for Intel's Sky Lake Server CPUs where NUMA
nodes shared an LLC.

This topology is no longer a quirk for Intel CPUs as Ice Lake and
Sapphire Rapids CPUs exhibit the same topology. Rather than maintain
the quirk list, define a synthetic flag that directs the scheduler
to allow this topology without warning for all Intel CPUs when NUMA
is configured.

Acked-by: Dave Hansen 
Signed-off-by: Alison Schofield 
Cc: Dave Hansen 
Cc: Tony Luck 
Cc: Tim Chen 
Cc: "H. Peter Anvin" 
Cc: Borislav Petkov 
Cc: Peter Zijlstra (Intel) 
Cc: David Rientjes 
Cc: Igor Mammedov 
Cc: Prarit Bhargava 
Cc: brice.gog...@gmail.com
---
 arch/x86/include/asm/cpufeatures.h |  1 +
 arch/x86/kernel/cpu/intel.c| 15 +++
 arch/x86/kernel/smpboot.c  | 23 ++-
 3 files changed, 18 insertions(+), 21 deletions(-)

diff --git a/arch/x86/include/asm/cpufeatures.h 
b/arch/x86/include/asm/cpufeatures.h
index 84b887825f12..bec74b90d3d6 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -421,5 +421,6 @@
 #define X86_BUG_TAAX86_BUG(22) /* CPU is affected by TSX 
Async Abort(TAA) */
 #define X86_BUG_ITLB_MULTIHIT  X86_BUG(23) /* CPU may incur MCE during 
certain page attribute changes */
 #define X86_BUG_SRBDS  X86_BUG(24) /* CPU may leak RNG bits if 
not mitigated */
+#define X86_BUG_NUMA_SHARES_LLCX86_BUG(25) /* CPU may 
enumerate an LLC shared by multiple NUMA nodes */
 
 #endif /* _ASM_X86_CPUFEATURES_H */
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 816fdbec795a..027348261080 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -719,6 +719,21 @@ static void init_intel(struct cpuinfo_x86 *c)
tsx_disable();
 
split_lock_init();
+
+   /*
+* Set X86_BUG_NUMA_SHARES_LLC to allow topologies where NUMA
+* nodes share an LLC. In Sub-NUMA Clustering mode Intel CPUs
+* may enumerate an LLC as shared by multiple NUMA nodes. The
+* LLC is shared for off-package data access but private to
+* the NUMA node for on-package access. This topology first
+* appeared in SKYLAKE_X. It was treated as a quirk and allowed.
+* This topology reappeared in ICELAKE_X and SAPPHIRERAPIDS_X.
+* Rather than maintain a list of quirk CPUS, allow this topology
+* on all Intel CPUs with NUMA configured. When this X86_BUG is
+* set, the scheduler accepts this topology without warning.
+*/
+   if (IS_ENABLED(CONFIG_NUMA))
+   set_cpu_bug(c, X86_BUG_NUMA_SHARES_LLC);
 }
 
 #ifdef CONFIG_X86_32
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 117e24fbfd8a..7d05c3552795 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -458,26 +458,6 @@ static bool match_smt(struct cpuinfo_x86 *c, struct 
cpuinfo_x86 *o)
return false;
 }
 
-/*
- * Define snc_cpu[] for SNC (Sub-NUMA Cluster) CPUs.
- *
- * These are Intel CPUs that enumerate an LLC that is shared by
- * multiple NUMA nodes. The LLC on these systems is shared for
- * off-package data access but private to the NUMA node (half
- * of the package) for on-package access.
- *
- * CPUID (the source of the information about the LLC) can only
- * enumerate the cache as being shared *or* unshared, but not
- * this particular configuration. The CPU in this case enumerates
- * the cache to be shared across the entire package (spanning both
- * NUMA nodes).
- */
-
-static const struct x86_cpu_id snc_cpu[] = {
-   X86_MATCH_INTEL_FAM6_MODEL(SKYLAKE_X, NULL),
-   {}
-};
-
 static bool match_llc(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o)
 {
int cpu1 = c->cpu_index, cpu2 = o->cpu_index;
@@ -495,7 +475,8 @@ static bool match_llc(struct cpuinfo_x86 *c, struct 
cpuinfo_x86 *o)
 * means 'c' does not share the LLC of 'o'. This will be
 * reflected to userspace.
 */
-   if (!topology_same_node(c, o) && x86_match_cpu(snc_cpu))
+   if (!topology_same_node(c, o) &&
+   boot_cpu_has_bug(X86_BUG_NUMA_SHARES_LLC))
return false;
 
return topology_sane(c, o, "llc");
-- 
2.20.1

Re: [PATCH v7 0/6] tracing: More synthetic event error fixes

[Tom Zanussi]

Hi Steve,

On Tue, 2021-02-09 at 16:09 -0500, Steven Rostedt wrote:
> On Mon,  1 Feb 2021 13:48:10 -0600
> Tom Zanussi  wrote:
> 
> > Hi,
> > 
> > This is v7 of the synthetic event error fix patchset.  This version
> > addresses the comments from v6:
> > 
> >   - moved check_command() from '[PATCH v6 3/6] tracing: Update
> > synth
> > command errors' to '[PATCH v6 2/6] tracing: Rework synthetic
> > event
> > command parsing'.
> > 
> >   - in __create_synth_event(), moved mutex_lock(_mutex) after
> > is_good_name() check and changed related error handling.
> > 
> >   - simplified check_command() a bit by calling argv_free() sooner
> > as
> > suggested by Steve.
> > 
> >   - added Steve's comment about check_field_version() into that
> > function and added additional comments to the caller.
> > 
> 
> After applying these, the following test fails:
> 
>  test.d/trigger/inter-event/trigger-synthetic_event_syntax_errors.tc
> 

Did you apply '[PATCH v7 5/6] selftests/ftrace: Update synthetic event
syntax errors' before you ran the test?  It actually removes the test
that failed.  Here's what I get with all patches applied:

  # ./ftracetest test.d/trigger/inter-event/
=== Ftrace unit tests ===
[1] event trigger - test inter-event histogram trigger expected fail
actions [XFAIL]
[2] event trigger - test field variable support [PASS]
[3] event trigger - test inter-event combined histogram trigger [PASS]
[4] event trigger - test multiple actions on hist trigger   [PASS]
[5] event trigger - test inter-event histogram trigger onchange action  
[PASS]
[6] event trigger - test inter-event histogram trigger onmatch action   
[PASS]
[7] event trigger - test inter-event histogram trigger onmatch-onmax
action  [PASS]
[8] event trigger - test inter-event histogram trigger onmax action 
[PASS]
[9] event trigger - test inter-event histogram trigger snapshot action  
[PASS]
[10] event trigger - test synthetic event create remove [PASS]
[11] event trigger - test inter-event histogram trigger trace action
with dynamic string param   [PASS]
[12] event trigger - test synthetic_events syntax parser errors [PASS]
[13] event trigger - test synthetic_events syntax parser[PASS]
[14] event trigger - test inter-event histogram trigger trace action
[PASS]


# of passed:  13
# of failed:  0
# of unresolved:  0
# of untested:  0
# of unsupported:  0
# of xfailed:  1
# of undefined(test bug):  0

> It appears that:
> 
>   echo 'myevent char str[];; int v' > synthetic_events
> 
> doesn't error after these changes.
> 

Right, it shouldn't fail any more - that was one of the reasons for
reworking the parser, so things like that wouldn't fail.

My assumption, and the reason for adding '[PATCH v7 4/6] tracing: Add a
backward-compatibility check for synthetic event creation', was that we
didn't want previously-working things to suddenly start failing after
the rework, but not that things that used to fail would continue to 
backwards-compatibly fail.

Tom

> -- Steve

Re: [PATCH] dt-bindings: spi: zynq: Convert Zynq QSPI binding to yaml

[Rob Herring]

On Wed, Feb 03, 2021 at 02:46:44PM +0100, Michal Simek wrote:
> Convert spi-zynq-qspi.txt to yaml.
> 
> Signed-off-by: Michal Simek 
> ---
> 
>  .../devicetree/bindings/spi/spi-zynq-qspi.txt | 25 
>  .../bindings/spi/xlnx,zynq-qspi.yaml  | 59 +++
>  MAINTAINERS   |  1 +
>  3 files changed, 60 insertions(+), 25 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/spi/spi-zynq-qspi.txt
>  create mode 100644 Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
> 
> diff --git a/Documentation/devicetree/bindings/spi/spi-zynq-qspi.txt 
> b/Documentation/devicetree/bindings/spi/spi-zynq-qspi.txt
> deleted file mode 100644
> index 16b734ad3102..
> --- a/Documentation/devicetree/bindings/spi/spi-zynq-qspi.txt
> +++ /dev/null
> @@ -1,25 +0,0 @@
> -Xilinx Zynq QSPI controller Device Tree Bindings
> 
> -
> -Required properties:
> -- compatible : Should be "xlnx,zynq-qspi-1.0".
> -- reg: Physical base address and size of QSPI 
> registers map.
> -- interrupts : Property with a value describing the interrupt
> -   number.
> -- clock-names: List of input clock names - "ref_clk", "pclk"
> -   (See clock bindings for details).
> -- clocks : Clock phandles (see clock bindings for details).
> -
> -Optional properties:
> -- num-cs : Number of chip selects used.
> -
> -Example:
> - qspi: spi@e000d000 {
> - compatible = "xlnx,zynq-qspi-1.0";
> - reg = <0xe000d000 0x1000>;
> - interrupt-parent = <>;
> - interrupts = <0 19 4>;
> - clock-names = "ref_clk", "pclk";
> - clocks = < 10>, < 43>;
> - num-cs = <1>;
> - };
> diff --git a/Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml 
> b/Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
> new file mode 100644
> index ..03269a7433b3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
> @@ -0,0 +1,59 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/spi/xlnx,zynq-qspi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Xilinx Zynq QSPI controller
> +
> +description:
> +  The Xilinx Zynq QSPI controller is used to access multi-bit serial flash
> +  memory devices.
> +
> +allOf:
> +  - $ref: "spi-controller.yaml#"
> +
> +maintainers:
> +  - Michal Simek 
> +
> +# Everything else is described in the common file
> +properties:
> +  compatible:
> +const: xlnx,zynq-qspi-1.0
> +
> +  reg:
> +maxItems: 1
> +
> +  interrupts:
> +maxItems: 1
> +
> +  clocks:
> +items:
> +  - description: reference clock
> +  - description: peripheral clock
> +
> +  clock-names:
> +items:
> +  - const: ref_clk
> +  - const: pclk
> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +  - clocks
> +  - clock-names
> +
> +additionalProperties: true

unevaluatedProperties: false

> +
> +examples:
> +  - |
> +spi@e000d000 {
> +compatible = "xlnx,zynq-qspi-1.0";
> +reg = <0xe000d000 0x1000>;
> +interrupt-parent = <>;
> +interrupts = <0 19 4>;
> +clock-names = "ref_clk", "pclk";
> +clocks = < 10>, < 43>;
> +num-cs = <1>;
> +};
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 546aa66428c9..e494b061dcd1 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2766,6 +2766,7 @@ W:  http://wiki.xilinx.com
>  T:   git https://github.com/Xilinx/linux-xlnx.git
>  F:   Documentation/devicetree/bindings/i2c/cdns,i2c-r1p10.yaml
>  F:   Documentation/devicetree/bindings/i2c/xlnx,xps-iic-2.00.a.yaml
> +F:   Documentation/devicetree/bindings/spi/xlnx,zynq-qspi.yaml
>  F:   arch/arm/mach-zynq/
>  F:   drivers/block/xsysace.c
>  F:   drivers/clocksource/timer-cadence-ttc.c
> -- 
> 2.30.0
> 

Re: linux-next: Tree for Feb 8 (objtool: warnings: 5)

[Josh Poimboeuf]

On Mon, Feb 08, 2021 at 01:39:03PM -0800, Randy Dunlap wrote:
> On 2/8/21 1:21 PM, Josh Poimboeuf wrote:
> > On Mon, Feb 08, 2021 at 11:30:59AM -0800, Randy Dunlap wrote:
> >> On 2/8/21 4:52 AM, Stephen Rothwell wrote:
> >>> Hi all,
> >>>
> >>> Changes since 20210205:
> >>>
> >>
> >> on x86_64:
> >>
> >> objtool warnings: (from 3 different randconfig builds)
> >>
> >> drivers/input/touchscreen/elants_i2c.o: warning: objtool: 
> >> elants_i2c_initialize() falls through to next function elants_i2c_resume()
> > 
> > Randy, can you share the .o?  (you may need to gzip it, still waiting on
> > corporate IT to allow me to receive .o files)
> 
> Sure, no problem. It's attached.

Does this fix?

From: Josh Poimboeuf 
Subject: [PATCH] input/elants_i2c: Detect enum overflow

If an enum value were to get added without updating this switch
statement, the unreachable() annotation would trigger undefined
behavior, causing execution to fall through the end of the function,
into the next one.

Make the error handling more robust for an unexpected enum value, by
doing BUG() instead of unreachable().

Fixes the following objtool warning:

  drivers/input/touchscreen/elants_i2c.o: warning: objtool: 
elants_i2c_initialize() falls through to next function elants_i2c_resume()

Reported-by: Randy Dunlap 
Signed-off-by: Josh Poimboeuf 
---
 drivers/input/touchscreen/elants_i2c.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/input/touchscreen/elants_i2c.c 
b/drivers/input/touchscreen/elants_i2c.c
index 6f57ec579f00..4c2b579f6c8b 100644
--- a/drivers/input/touchscreen/elants_i2c.c
+++ b/drivers/input/touchscreen/elants_i2c.c
@@ -656,8 +656,7 @@ static int elants_i2c_initialize(struct elants_data *ts)
error = elants_i2c_query_ts_info_ektf(ts);
break;
default:
-   unreachable();
-   break;
+   BUG();
}
 
if (error)
-- 
2.29.2

Re: [PATCH net-next] net: phy: introduce phydev->port

[Florian Fainelli]

On 2/9/21 8:38 AM, Michael Walle wrote:
> At the moment, PORT_MII is reported in the ethtool ops. This is odd
> because it is an interface between the MAC and the PHY and no external
> port. Some network card drivers will overwrite the port to twisted pair
> or fiber, though. Even worse, the MDI/MDIX setting is only used by
> ethtool if the port is twisted pair.
> 
> Set the port to PORT_TP by default because most PHY drivers are copper
> ones. If there is fibre support and it is enabled, the PHY driver will
> set it to PORT_FIBRE.
> 
> This will change reporting PORT_MII to either PORT_TP or PORT_FIBRE;
> except for the genphy fallback driver.
> 
> Suggested-by: Andrew Lunn 
> Signed-off-by: Michael Walle 

Reviewed-by: Florian Fainelli 
-- 
Florian

Re: [RFC PATCH v3 1/2] topology: Represent clusters of CPUs within a die.

[Masayoshi Mizuma]

On Wed, Jan 06, 2021 at 09:30:25PM +1300, Barry Song wrote:
> From: Jonathan Cameron 
> 
> Both ACPI and DT provide the ability to describe additional layers of
> topology between that of individual cores and higher level constructs
> such as the level at which the last level cache is shared.
> In ACPI this can be represented in PPTT as a Processor Hierarchy
> Node Structure [1] that is the parent of the CPU cores and in turn
> has a parent Processor Hierarchy Nodes Structure representing
> a higher level of topology.
> 
> For example Kunpeng 920 has 6 clusters in each NUMA node, and each
> cluster has 4 cpus. All clusters share L3 cache data, but each cluster
> has local L3 tag. On the other hand, each clusters will share some
> internal system bus.
> 
> +---+  +-+
> |  +--++--++---+ |
> |  | CPU0 || cpu1 | |+---+ | |
> |  +--++--+ ||   | | |
> |   ++L3 | | |
> |  +--++--+   cluster   ||tag| | |
> |  | CPU2 || CPU3 | ||   | | |
> |  +--++--+ |+---+ | |
> |   |  | |
> +---+  | |
> +---+  | |
> |  +--++--+ +--+ |
> |  |  ||  | |+---+ | |
> |  +--++--+ ||   | | |
> |   ||L3 | | |
> |  +--++--+ ++tag| | |
> |  |  ||  | ||   | | |
> |  +--++--+ |+---+ | |
> |   |  | |
> +---+  |   L3|
>|   data  |
> +---+  | |
> |  +--++--+ |+---+ | |
> |  |  ||  | ||   | | |
> |  +--++--+ ++L3 | | |
> |   ||tag| | |
> |  +--++--+ ||   | | |
> |  |  ||  |+++---+ | |
> |  +--++--+|---+ |
> +---|  | |
> +---|  | |
> |  +--++--++---+ |
> |  |  ||  | |+---+ | |
> |  +--++--+ ||   | | |
> |   ++L3 | | |
> |  +--++--+ ||tag| | |
> |  |  ||  | ||   | | |
> |  +--++--+ |+---+ | |
> |   |  | |
> +---+  | |
> +---+  | |
> |  +--++--+ +--+ |
> |  |  ||  | |   +---+  | |
> |  +--++--+ |   |   |  | |
> |   |   |L3 |  | |
> |  +--++--+ +---+tag|  | |
> |  |  ||  | |   |   |  | |
> |  +--++--+ |   +---+  | |
> |   |  | |
> +---+  | |
> +---+ ++ |
> |  +--++--+ +--+ |
> |  |  ||  | |  +---+   | |
> |  +--++--+ |  |   |   | |
> |   |  |L3 |   | |

Greetings

[DESMOND WILLIAMS]

Dear Friend,

I am Mr. Desmond Williams an auditor in Credit & Debit Dept in Group
Bank Of Africa (BOA), Ouagadougou; Burkina Faso. I contacted you as
regards to a business proposal that will be of an immense benefit to
both of us and the less privileged ones. Being the auditing manager, I
discovered a sum of Ten Million Five Hundred Thousand United States
Dollars [$10.5M] only in a Fixed Deposit Account belonging to one of
our foreign customers Late Mr. Moses Saba Masri. He was a Jewish
business man from Mexico that died on a helicopter crash event happen in
earlier 2010. Mr. Saba was 47-years-old when both his wife, his only
son Avraham (Albert) and his daughter-in-law died in a helicopter
crash.

You can get more information's as regards to this on below website:
http://www.ynetnews.com/articles/0,7340,L-3832556,00.html

This will be shared 50% to me and 50% for you. Please, kindly provide
me your full contact details as l stated below:

1. Your full name...?
2. Direct Mobile Number.?
3. Contact Address?
4. Sex/Age...?
5. Marital Status...
6. Occupation...?
7. Country of Origin.
8. Attached any of Your Identification Copy?..

As to enable us proceed immediately. Weave 14 working days to run this
transaction successfully. Having gone through a methodical search, I


decided to contact you hoping that you will find this proposal
interesting. Please on your confirmation of this message and
indicating your interest I will furnish you with more information's.

Your assent to this e-mail and business proposal will be highly appreciated.
Thanks, and Have a great day.
Yours Sincerely.
Mr. Desmond Williams.

Re: [PATCH v2 net-next 04/11] net: bridge: offload initial and final port flags through switchdev

[Vladimir Oltean]

On Wed, Feb 10, 2021 at 12:01:24AM +0200, Ido Schimmel wrote:
> On Tue, Feb 09, 2021 at 10:20:45PM +0200, Vladimir Oltean wrote:
> > On Tue, Feb 09, 2021 at 08:51:00PM +0200, Ido Schimmel wrote:
> > > On Tue, Feb 09, 2021 at 05:19:29PM +0200, Vladimir Oltean wrote:
> > > > So switchdev drivers operating in standalone mode should disable address
> > > > learning. As a matter of practicality, we can reduce code duplication in
> > > > drivers by having the bridge notify through switchdev of the initial and
> > > > final brport flags. Then, drivers can simply start up hardcoded for no
> > > > address learning (similar to how they already start up hardcoded for no
> > > > forwarding), then they only need to listen for
> > > > SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS and their job is basically done, no
> > > > need for special cases when the port joins or leaves the bridge etc.
> > >
> > > How are you handling the case where a port leaves a LAG that is linked
> > > to a bridge? In this case the port becomes a standalone port, but will
> > > not get this notification.
> >
> > Apparently the answer to that question is "I delete the code that makes
> > this use case work", how smart of me. Thanks.
>
> Not sure how you expect to interpret this.

Next patch (05/11) deletes that explicit notification from 
dsa_port_bridge_leave,
function which is called from dsa_port_lag_leave too, apparently with good 
reason.

> > Unless you have any idea how I could move the logic into the bridge, I
> > guess I'm stuck with DSA and all the other switchdev drivers having this
> > forest of corner cases to deal with. At least I can add a comment so I'm
> > not tempted to delete it next time.
>
> There are too many moving pieces with stacked devices. It is not only
> LAG/bridge. In L3 you have VRFs, SVIs, macvlans etc. It might be better
> to gracefully / explicitly not handle a case rather than pretending to
> handle it correctly with complex / buggy code.
>
> For example, you should refuse to be enslaved to a LAG that already has
> upper devices such as a bridge. You are probably not handling this
> correctly / at all. This is easy. Just a call to
> netdev_has_any_upper_dev().

Correct, good point, in particular this means that joining a bridged LAG
will not get me any notifications of that LAG's CHANGEUPPER because that
was consumed a long time ago. An equally valid approach seems to be to
check for netdev_master_upper_dev_get_rcu in dsa_port_lag_join, and call
dsa_port_bridge_join on the upper if that is present.

> The reverse, during unlinking, would be to refuse unlinking if the upper
> has uppers of its own. netdev_upper_dev_unlink() needs to learn to
> return an error and callers such as team/bond need to learn to handle
> it, but it seems patchable.

Again, this was treated prior to my deletion in this series and not by
erroring out, I just really didn't think it through.

So you're saying that if we impose that all switchdev drivers restrict
the house of cards to be constructed from the bottom up, and destructed
from the top down, then the notification of bridge port flags can stay
in the bridge layer?

Re: [PATCH] dt-bindings: pinctrl: Group tuples in pin control properties

[Rob Herring]

On Thu, 04 Feb 2021 13:57:18 +0100, Geert Uytterhoeven wrote:
> To improve human readability and enable automatic validation, the tuples
> in "pinctrl-*" properties should be grouped using angle brackets.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
>  .../devicetree/bindings/pinctrl/brcm,ns2-pinmux.txt|  2 +-
>  .../devicetree/bindings/pinctrl/brcm,nsp-pinmux.txt|  2 +-
>  .../devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt  |  2 +-
>  .../devicetree/bindings/pinctrl/pinctrl-bindings.txt   |  4 ++--
>  .../devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt   |  2 +-
>  .../devicetree/bindings/pinctrl/pinctrl-mt65xx.txt |  2 +-
>  .../devicetree/bindings/pinctrl/pinctrl-single.txt | 10 +-
>  .../devicetree/bindings/pinctrl/samsung-pinctrl.txt|  2 +-
>  8 files changed, 13 insertions(+), 13 deletions(-)
> 

Reviewed-by: Rob Herring 

Re: [PATCH] dt-bindings: can: rcar_canfd: Group tuples in pin control properties

[Rob Herring]

On Thu, 04 Feb 2021 13:59:37 +0100, Geert Uytterhoeven wrote:
> To improve human readability and enable automatic validation, the tuples
> in "pinctrl-*" properties should be grouped using angle brackets.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
>  Documentation/devicetree/bindings/net/can/rcar_canfd.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Applied, thanks!

Re: [PATCH RFC 00/30] userfaultfd-wp: Support shmem and hugetlbfs

[Mike Kravetz]

On 2/5/21 6:36 PM, Peter Xu wrote:
> On Fri, Feb 05, 2021 at 01:53:34PM -0800, Mike Kravetz wrote:
>> On 1/29/21 2:49 PM, Peter Xu wrote:
>>> On Fri, Jan 15, 2021 at 12:08:37PM -0500, Peter Xu wrote:
 This is a RFC series to support userfaultfd upon shmem and hugetlbfs.
>> ...
>>> Huge & Mike,
>>>
>>> Would any of you have comment/concerns on the high-level design of this 
>>> series?
>>>
>>> It would be great to know it, especially major objection, before move on to 
>>> an
>>> non-rfc version.
>>
>> My apologies for not looking at this sooner.  Even now, I have only taken
>> a very brief look at the hugetlbfs patches.
>>
>> Coincidentally, I am working on the 'BUG' that soft dirty does not work for
>> hugetlbfs.  As you can imagine, there is some overlap in handling of wp ptes
>> set for soft dirty.  In addition, pmd sharing must be disabled for soft dirty
>> as here and in Axel's uffd minor fault code.
> 
> Interesting to know that we'll reach and need something common from different
> directions, especially when they all mostly happen at the same time. :)
> 
> Is there a real "BUG" that you mentioned?  I'd be glad to read about it if
> there is a link or something.
> 

Sorry, I was referring to a bugzilla bug not a BUG().  Bottom line is that
hugetlb was mostly overlooked when soft dirty support was added.  A thread
mostly from me is at:
lore.kernel.org/r/999775bf-4204-2bec-7c3d-72d81b4fc...@oracle.com
I am close to sending out a RFC, but keep getting distracted.

>> No objections to the overall approach based on my quick look.
> 
> Thanks for having a look.
> 
> So for hugetlb one major thing is indeed about the pmd sharing part, which
> seems that we've got very good consensus on.

Yes

> The other thing that I'd love to get some comment would be a shared topic with
> shmem in that: for a file-backed memory type, uffd-wp needs a consolidated way
> to record wr-protect information even if the pgtable entries were flushed.
> That comes from a fundamental difference between anonymous and file-backed
> memory in that anonymous pages keep all info in the pgtable entry, but
> file-backed memory is not, e.g., pgtable entries can be dropped at any time as
> long as page cache is there.

Sorry, but I can not recall this difference for hugetlb pages.  What operations
lead to flushing of pagetable entries?  It would need to be something other
than unmap as it seems we want to lose the information in unmap IIUC.

> I goes to look at soft-dirty then regarding this issue, and there's actually a
> paragraph about it:
> 
> While in most cases tracking memory changes by #PF-s is more than 
> enough
> there is still a scenario when we can lose soft dirty bits -- a task
> unmaps a previously mapped memory region and then maps a new one at
> exactly the same place. When unmap is called, the kernel internally
> clears PTE values including soft dirty bits. To notify user space
> application about such memory region renewal the kernel always marks
> new memory regions (and expanded regions) as soft dirty.
> 
> I feel like it just means soft-dirty currently allows false positives: we 
> could
> have set the soft dirty bit even if the page is clean.  And that's what this
> series wanted to avoid: it used the new concept called "swap special pte" to
> persistent that information even for file-backed memory.  That all goes for
> avoiding those false positives.

Yes, I have seen this with soft dirty.  It really does not seem right.  When
you first create a mapping, even before faulting in anything the vma is marked
VM_SOFTDIRTY and from the user's perspective all addresses/pages appear dirty.

To be honest, I am not sure you want to try and carry per-process/per-mapping
wp information in the file.  In the comment about soft dirty above, it seems
reasonable that unmapping would clear all soft dirty information.  Also,
unmapping would clear any uffd state/information.
-- 
Mike Kravetz

>>
>> I'll try to take a closer look at the areas where efforts overlap.
> 
> I dumped above just to hope maybe it could help a little bit more for the
> reviews, but if it's not, I totally agree we can focus on the overlapped part.
> And, I'd be more than glad to read your work too if I can understand more on
> what you're working on with the hugetlb soft dirty bug, since I do feel 
> uffd-wp
> is servicing similar goals just like what soft-dirty does, so we could share a
> lot of common knowledge there. :)
> 
> Thanks again!
> 

Re: [PATCH][RESEND] lib/vsprintf: make-printk-non-secret printks all addresses as unhashed

[Timur Tabi]

On 2/9/21 3:59 PM, Marco Elver wrote:

Would it be reasonable to make this non-static? Or somehow make it
possible to get this flag from other subsystems?

There are other places in the kernel that dump sensitive data such as
registers. We'd like to be able to use 'debug_never_hash_pointers' to
decide if our debugging tools can dump registers etc. What we really
need is info if the kernel is in debug mode and we can dump all kinds of
sensitive info; debug_never_hash_pointers is would be a good enough
proxy for that.


The next version of my patch (coming soon) will export the symbol.  It's 
intended for test_printf, but if you think it can be used by others, so 
much the better.

Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz

[nnet]

On Tue, Feb 9, 2021, at 2:42 PM, Pali Rohár wrote:
> On Tuesday 09 February 2021 13:45:08 nnet wrote:
> > On Tue, Feb 9, 2021, at 1:33 PM, Pali Rohár wrote:
> > > On Tuesday 09 February 2021 13:00:26 nnet wrote:
> > > > > If you have other Armada 3720 boards (Espressobin v5/v7, uDPU, Devel 
> > > > > Board, ...) then it will be nice to do an additional tests and check 
> > > > > if instability issues are finally fixed.
> > > > 
> > > > These patches applied to the 5.4.96 in OpenWrt (98d61b5) work fine so 
> > > > far on an Espressobin v7 AFAICT per changing values in 
> > > > /sys/devices/system/cpu/cpufreq/policy0.
> > > > 
> > > > Are these changes intended to work @1.2 GHz on the v7?
> > > 
> > > Hello! Do you have 1.2 GHz A3720 SoC?
> > 
> > Maybe (not)? ESPRESSObin_V7_1-0 on the underside.
> 
> Look at the package of SoC chip. On top of the package is printed
> identifier 88F3720. On the last line should be one of the string:
> C080, C100, C120, I080, I100 which identifies frequency
> (080 = 800 MHz, 100 = 1 GHz, 120 = 1.2 GHz)
> 
> Can you check what is printed on A3720 SoC package?

Both of mine are 88F3720-A0-C120.

[PATCH v3 1/2] kunit: support failure from dynamic analysis tools

[Daniel Latypov]

From: Uriel Guajardo 

Add a kunit_fail_current_test() function to fail the currently running
test, if any, with an error message.

This is largely intended for dynamic analysis tools like UBSAN and for
fakes.
E.g. say I had a fake ops struct for testing and I wanted my `free`
function to complain if it was called with an invalid argument, or
caught a double-free. Most return void and have no normal means of
signalling failure (e.g. super_operations, iommu_ops, etc.).

Key points:
* Always update current->kunit_test so anyone can use it.
  * commit 83c4e7a0363b ("KUnit: KASAN Integration") only updated it for
  CONFIG_KASAN=y

* Create a new header  so non-test code doesn't have
to include all of  (e.g. lib/ubsan.c)

* Forward the file and line number to make it easier to track down
failures

* Declare the helper function for nice __printf() warnings about mismatched
format strings even when KUnit is not enabled.

Example output from kunit_fail_current_test("message"):
[15:19:34] [FAILED] example_simple_test
[15:19:34] # example_simple_test: initializing
[15:19:34] # example_simple_test: lib/kunit/kunit-example-test.c:24: message
[15:19:34] not ok 1 - example_simple_test

Co-developed-by: Daniel Latypov 
Signed-off-by: Uriel Guajardo 
Signed-off-by: Daniel Latypov 
---
 include/kunit/test-bug.h | 30 ++
 lib/kunit/test.c | 37 +
 2 files changed, 63 insertions(+), 4 deletions(-)
 create mode 100644 include/kunit/test-bug.h

diff --git a/include/kunit/test-bug.h b/include/kunit/test-bug.h
new file mode 100644
index ..18b1034ec43a
--- /dev/null
+++ b/include/kunit/test-bug.h
@@ -0,0 +1,30 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * KUnit API allowing dynamic analysis tools to interact with KUnit tests
+ *
+ * Copyright (C) 2020, Google LLC.
+ * Author: Uriel Guajardo 
+ */
+
+#ifndef _KUNIT_TEST_BUG_H
+#define _KUNIT_TEST_BUG_H
+
+#define kunit_fail_current_test(fmt, ...) \
+   __kunit_fail_current_test(__FILE__, __LINE__, fmt, ##__VA_ARGS__)
+
+#if IS_ENABLED(CONFIG_KUNIT)
+
+extern __printf(3, 4) void __kunit_fail_current_test(const char *file, int 
line,
+   const char *fmt, ...);
+
+#else
+
+static __printf(3, 4) void __kunit_fail_current_test(const char *file, int 
line,
+   const char *fmt, ...)
+{
+}
+
+#endif
+
+
+#endif /* _KUNIT_TEST_BUG_H */
diff --git a/lib/kunit/test.c b/lib/kunit/test.c
index ec9494e914ef..5794059505cf 100644
--- a/lib/kunit/test.c
+++ b/lib/kunit/test.c
@@ -7,6 +7,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -16,6 +17,38 @@
 #include "string-stream.h"
 #include "try-catch-impl.h"
 
+/*
+ * Fail the current test and print an error message to the log.
+ */
+void __kunit_fail_current_test(const char *file, int line, const char *fmt, 
...)
+{
+   va_list args;
+   int len;
+   char *buffer;
+
+   if (!current->kunit_test)
+   return;
+
+   kunit_set_failure(current->kunit_test);
+
+   /* kunit_err() only accepts literals, so evaluate the args first. */
+   va_start(args, fmt);
+   len = vsnprintf(NULL, 0, fmt, args) + 1;
+   va_end(args);
+
+   buffer = kunit_kmalloc(current->kunit_test, len, GFP_KERNEL);
+   if (!buffer)
+   return;
+
+   va_start(args, fmt);
+   vsnprintf(buffer, len, fmt, args);
+   va_end(args);
+
+   kunit_err(current->kunit_test, "%s:%d: %s", file, line, buffer);
+   kunit_kfree(current->kunit_test, buffer);
+}
+EXPORT_SYMBOL_GPL(__kunit_fail_current_test);
+
 /*
  * Append formatted message to log, size of which is limited to
  * KUNIT_LOG_SIZE bytes (including null terminating byte).
@@ -273,9 +306,7 @@ static void kunit_try_run_case(void *data)
struct kunit_suite *suite = ctx->suite;
struct kunit_case *test_case = ctx->test_case;
 
-#if (IS_ENABLED(CONFIG_KASAN) && IS_ENABLED(CONFIG_KUNIT))
current->kunit_test = test;
-#endif /* IS_ENABLED(CONFIG_KASAN) && IS_ENABLED(CONFIG_KUNIT) */
 
/*
 * kunit_run_case_internal may encounter a fatal error; if it does,
@@ -624,9 +655,7 @@ void kunit_cleanup(struct kunit *test)
spin_unlock(>lock);
kunit_remove_resource(test, res);
}
-#if (IS_ENABLED(CONFIG_KASAN) && IS_ENABLED(CONFIG_KUNIT))
current->kunit_test = NULL;
-#endif /* IS_ENABLED(CONFIG_KASAN) && IS_ENABLED(CONFIG_KUNIT)*/
 }
 EXPORT_SYMBOL_GPL(kunit_cleanup);
 
-- 
2.30.0.478.g8a0d178c01-goog

Re: [PATCH] driver core: auxiliary bus: Fix calling stage for auxiliary bus init

[Greg KH]

On Tue, Feb 09, 2021 at 12:38:06PM -0700, Dave Jiang wrote:
> 
> On 2/9/2021 12:14 PM, Greg KH wrote:
> > On Tue, Feb 09, 2021 at 12:05:05PM -0700, Dave Jiang wrote:
> > > When the auxiliary device code is built into the kernel, it can be 
> > > executed
> > > before the auxiliary bus is registered. This causes bus->p to be not
> > > allocated and triggers a NULL pointer dereference when the auxiliary bus
> > > device gets added with bus_add_device(). Change the init of auxiliary bus
> > > to subsys_initcall() from module_init() to ensure the bus is registered
> > > before devices.
> > > 
> > > Below is the kernel splat for the bug:
> > > [ 1.948215] BUG: kernel NULL pointer dereference, address: 
> > > 0060
> > > [ 1.950670] #PF: supervisor read access in kernel mode
> > > [ 1.950670] #PF: error_code(0x) - not-present page
> > > [ 1.950670] PGD 0
> > > [ 1.950670] Oops:  1 SMP NOPTI
> > > [ 1.950670] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
> > > 5.10.0-intel-nextsvmtest+ #2205
> > > [ 1.950670] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
> > > rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
> > > [ 1.950670] RIP: 0010:bus_add_device+0x64/0x140
> > > [ 1.950670] Code: 00 49 8b 75 20 48 89 df e8 59 a1 ff ff 41 89 c4 85 c0 
> > > 75 7b 48 8b 53 50 48 85 d2 75 03 48 8b 13 49 8b 85 a0 00 00 00 48 89 de 
> > > <48> 8
> > > 78 60 48 83 c7 18 e8 ef d9 a9 ff 41 89 c4 85 c0 75 45 48 8b
> > > [ 1.950670] RSP: :ff46032ac001baf8 EFLAGS: 00010246
> > > [ 1.950670] RAX:  RBX: ff4597f7414aa680 RCX: 
> > > 
> > > [ 1.950670] RDX: ff4597f74142bbc0 RSI: ff4597f7414aa680 RDI: 
> > > ff4597f7414aa680
> > > [ 1.950670] RBP: ff46032ac001bb10 R08: 0044 R09: 
> > > 0228
> > > [ 1.950670] R10: ff4597f741141b30 R11: ff4597f740182a90 R12: 
> > > 
> > > [ 1.950670] R13: a5e936c0 R14:  R15: 
> > > 
> > > [ 1.950670] FS: () GS:ff4597f7bba0() 
> > > knlGS:
> > > [ 1.950670] CS: 0010 DS:  ES:  CR0: 80050033
> > > [ 1.950670] CR2: 0060 CR3: 2140c001 CR4: 
> > > 00f71ef0
> > > [ 1.950670] DR0:  DR1:  DR2: 
> > > 
> > > [ 1.950670] DR3:  DR6: fffe07f0 DR7: 
> > > 0400
> > > [ 1.950670] PKRU: 5554
> > > [ 1.950670] Call Trace:
> > > [ 1.950670] device_add+0x3ee/0x850
> > > [ 1.950670] __auxiliary_device_add+0x47/0x60
> > > [ 1.950670] idxd_pci_probe+0xf77/0x1180
> > > [ 1.950670] local_pci_probe+0x4a/0x90
> > > [ 1.950670] pci_device_probe+0xff/0x1b0
> > > [ 1.950670] really_probe+0x1cf/0x440
> > > [ 1.950670] ? rdinit_setup+0x31/0x31
> > > [ 1.950670] driver_probe_device+0xe8/0x150
> > > [ 1.950670] device_driver_attach+0x58/0x60
> > > [ 1.950670] __driver_attach+0x8f/0x150
> > > [ 1.950670] ? device_driver_attach+0x60/0x60
> > > [ 1.950670] ? device_driver_attach+0x60/0x60
> > > [ 1.950670] bus_for_each_dev+0x79/0xc0
> > > [ 1.950670] ? kmem_cache_alloc_trace+0x323/0x430
> > > [ 1.950670] driver_attach+0x1e/0x20
> > > [ 1.950670] bus_add_driver+0x154/0x1f0
> > > [ 1.950670] driver_register+0x70/0xc0
> > > [ 1.950670] __pci_register_driver+0x54/0x60
> > > [ 1.950670] idxd_init_module+0xe2/0xfc
> > > [ 1.950670] ? idma64_platform_driver_init+0x19/0x19
> > > [ 1.950670] do_one_initcall+0x4a/0x1e0
> > > [ 1.950670] kernel_init_freeable+0x1fc/0x25c
> > > [ 1.950670] ? rest_init+0xba/0xba
> > > [ 1.950670] kernel_init+0xe/0x116
> > > [ 1.950670] ret_from_fork+0x1f/0x30
> > > [ 1.950670] Modules linked in:
> > > [ 1.950670] CR2: 0060
> > > [ 1.950670] --[ end trace cd7d1b226d3ca901 ]--
> > > 
> > > Fixes: 7de3697e9cbd ("Add auxiliary bus support")
> > > Reported-by: Jacob Pan 
> > > Acked-by: Dave Ertman 
> > > Reviewed-by: Dan Williams 
> > > Signed-off-by: Dave Jiang 
> > > ---
> > >   drivers/base/auxiliary.c |2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/base/auxiliary.c b/drivers/base/auxiliary.c
> > > index 8336535f1e11..53f93a506626 100644
> > > --- a/drivers/base/auxiliary.c
> > > +++ b/drivers/base/auxiliary.c
> > > @@ -270,7 +270,7 @@ static void __exit auxiliary_bus_exit(void)
> > >   bus_unregister(_bus_type);
> > >   }
> > > -module_init(auxiliary_bus_init);
> > > +subsys_initcall(auxiliary_bus_init);
> > Ah, the linker priority dance.  Are you _SURE_ this will solve this?
> > 
> > Why not just call this explicitly in driver_init() so that you know it
> > will be ok?  Just like we do for the platform bus?
> 
> It would require making auxiliary_bus part of the base just like platform
> instead of a module.

The auxiliary_bus code is not a module today, so I have no idea what
you are talking about, sorry.

> Is that ok?

No it is not.

greg k-h

Re: [PATCH] firmware: qcom_scm: Add MDM9607 compatible

[Konrad Dybcio]

On 09.02.2021 21:38, Rob Herring wrote:
> In the future, please split binding changes to separate patch.


I will keep that in mind for the upcoming patches!


Konrad

Re: [PATCH v2 net-next 04/11] net: bridge: offload initial and final port flags through switchdev

[Ido Schimmel]

On Tue, Feb 09, 2021 at 10:20:45PM +0200, Vladimir Oltean wrote:
> On Tue, Feb 09, 2021 at 08:51:00PM +0200, Ido Schimmel wrote:
> > On Tue, Feb 09, 2021 at 05:19:29PM +0200, Vladimir Oltean wrote:
> > > So switchdev drivers operating in standalone mode should disable address
> > > learning. As a matter of practicality, we can reduce code duplication in
> > > drivers by having the bridge notify through switchdev of the initial and
> > > final brport flags. Then, drivers can simply start up hardcoded for no
> > > address learning (similar to how they already start up hardcoded for no
> > > forwarding), then they only need to listen for
> > > SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS and their job is basically done, no
> > > need for special cases when the port joins or leaves the bridge etc.
> > 
> > How are you handling the case where a port leaves a LAG that is linked
> > to a bridge? In this case the port becomes a standalone port, but will
> > not get this notification.
> 
> Apparently the answer to that question is "I delete the code that makes
> this use case work", how smart of me. Thanks.

Not sure how you expect to interpret this.

> 
> Unless you have any idea how I could move the logic into the bridge, I
> guess I'm stuck with DSA and all the other switchdev drivers having this
> forest of corner cases to deal with. At least I can add a comment so I'm
> not tempted to delete it next time.

There are too many moving pieces with stacked devices. It is not only
LAG/bridge. In L3 you have VRFs, SVIs, macvlans etc. It might be better
to gracefully / explicitly not handle a case rather than pretending to
handle it correctly with complex / buggy code.

For example, you should refuse to be enslaved to a LAG that already has
upper devices such as a bridge. You are probably not handling this
correctly / at all. This is easy. Just a call to
netdev_has_any_upper_dev().

The reverse, during unlinking, would be to refuse unlinking if the upper
has uppers of its own. netdev_upper_dev_unlink() needs to learn to
return an error and callers such as team/bond need to learn to handle
it, but it seems patchable.

[PATCH v3 0/2] kunit: fail tests on UBSAN errors

[Daniel Latypov]

v1 by Uriel is here: [1].
Since it's been a while, I've dropped the Reviewed-By's.

It depended on commit 83c4e7a0363b ("KUnit: KASAN Integration") which
hadn't been merged yet, so that caused some kerfuffle with applying them
previously and the series was reverted.

This revives the series but makes the kunit_fail_current_test() function
take a format string and logs the file and line number of the failing
code, addressing Alan Maguire's comments on the previous version.

As a result, the patch that makes UBSAN errors was tweaked slightly to
include an error message.

v2 -> v3:
  Fix kunit_fail_current_test() so it works w/ CONFIG_KUNIT=m
  s/_/__ on the helper func to match others in test.c

[1] 
https://lore.kernel.org/linux-kselftest/20200806174326.3577537-1-urielguajard...@gmail.com/

Uriel Guajardo (2):
  kunit: support failure from dynamic analysis tools
  kunit: ubsan integration

 include/kunit/test-bug.h | 30 ++
 lib/kunit/test.c | 37 +
 lib/ubsan.c  |  3 +++
 3 files changed, 66 insertions(+), 4 deletions(-)
 create mode 100644 include/kunit/test-bug.h


base-commit: 1e0d27fce010b0a4a9e595506b6ede75934c31be
-- 
2.30.0.478.g8a0d178c01-goog

Re: [PATCH] PCI: Use subdir-ccflags-* to inherit debug flag

[Bjorn Helgaas]

[+cc Masahiro, Michal, linux-kbuild, linux-kernel]

On Thu, Feb 04, 2021 at 07:30:15PM +0800, Yicong Yang wrote:
> From: Junhao He 
> 
> Use subdir-ccflags-* instead of ccflags-* to inherit the debug
> settings from Kconfig when traversing subdirectories.
> 
> Signed-off-by: Junhao He 
> Signed-off-by: Yicong Yang 

I applied this with Krzysztof's reviewed-by and the commit log below
to pci/misc for v5.12, thanks!

Feel free to copy or improve the commit log for use elsewhere.

> ---
>  drivers/pci/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
> index 11cc794..d62c4ac 100644
> --- a/drivers/pci/Makefile
> +++ b/drivers/pci/Makefile
> @@ -36,4 +36,4 @@ obj-$(CONFIG_PCI_ENDPOINT)  += endpoint/
>  obj-y+= controller/
>  obj-y+= switch/
>  
> -ccflags-$(CONFIG_PCI_DEBUG) := -DDEBUG
> +subdir-ccflags-$(CONFIG_PCI_DEBUG) := -DDEBUG

commit e8e9aababe60 ("PCI: Apply CONFIG_PCI_DEBUG to entire drivers/pci 
hierarchy")
Author: Junhao He 
Date:   Thu Feb 4 19:30:15 2021 +0800

PCI: Apply CONFIG_PCI_DEBUG to entire drivers/pci hierarchy

CONFIG_PCI_DEBUG=y adds -DDEBUG to CFLAGS, which enables things like
pr_debug() and dev_dbg() (and hence pci_dbg()).  Previously we added
-DDEBUG for files in drivers/pci/, but not files in subdirectories of
drivers/pci/.

Add -DDEBUG to CFLAGS for all files below drivers/pci/ so CONFIG_PCI_DEBUG
applies to the entire hierarchy.

[bhelgaas: commit log]
Link: 
https://lore.kernel.org/r/1612438215-33105-1-git-send-email-yangyic...@hisilicon.com
Signed-off-by: Junhao He 
Signed-off-by: Yicong Yang 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Krzysztof Wilczyński 

diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 11cc79411e2d..d62c4ac4ae1b 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -36,4 +36,4 @@ obj-$(CONFIG_PCI_ENDPOINT)+= endpoint/
 obj-y  += controller/
 obj-y  += switch/
 
-ccflags-$(CONFIG_PCI_DEBUG) := -DDEBUG
+subdir-ccflags-$(CONFIG_PCI_DEBUG) := -DDEBUG

[PATCH v3 1/5] clk: sunxi-ng: mp: fix parent rate change flag check

[Jernej Skrabec]

CLK_SET_RATE_PARENT flag is checked on parent clock instead of current
one. Fix that.

Fixes: 3f790433c3cb ("clk: sunxi-ng: Adjust MP clock parent rate when allowed")
Reviewed-by: Chen-Yu Tsai 
Tested-by: Andre Heider 
Signed-off-by: Jernej Skrabec 
---
 drivers/clk/sunxi-ng/ccu_mp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/sunxi-ng/ccu_mp.c b/drivers/clk/sunxi-ng/ccu_mp.c
index fa4ecb915590..9d3a76604d94 100644
--- a/drivers/clk/sunxi-ng/ccu_mp.c
+++ b/drivers/clk/sunxi-ng/ccu_mp.c
@@ -108,7 +108,7 @@ static unsigned long ccu_mp_round_rate(struct 
ccu_mux_internal *mux,
max_m = cmp->m.max ?: 1 << cmp->m.width;
max_p = cmp->p.max ?: 1 << ((1 << cmp->p.width) - 1);
 
-   if (!(clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT)) {
+   if (!clk_hw_can_set_rate_parent(>common.hw)) {
ccu_mp_find_best(*parent_rate, rate, max_m, max_p, , );
rate = *parent_rate / p / m;
} else {
-- 
2.30.0

Re: [GIT PULL] fscache: I/O API modernisation and netfs helper library

[David Wysochanski]

On Tue, Feb 9, 2021 at 2:07 PM Linus Torvalds
 wrote:
>
> So I'm looking at this early, because I have more time now than I will
> have during the merge window, and honestly, your pull requests have
> been problematic in the past.
>
> The PG_fscache bit waiting functions are completely crazy. The comment
> about "this will wake up others" is actively wrong, and the waiting
> function looks insane, because you're mixing the two names for
> "fscache" which makes the code look totally incomprehensible. Why
> would we wait for PF_fscache, when PG_private_2 was set? Yes, I know
> why, but the code looks entirely nonsensical.
>
> So just looking at the support infrastructure changes, I get a big "Hmm".
>
> But the thing that makes me go "No, I won't pull this", is that it has
> all the same hallmark signs of trouble that I've complained about
> before: I see absolutely zero sign of "this has more developers
> involved".
>
> There's not a single ack from a VM person for the VM changes. There's
> no sign that this isn't yet another "David Howells went off alone and
> did something that absolutely nobody else cared about".
>

I care about it.

I cannot speak to your concerns about the infrastructure changes, nor
can I comment about a given maintainers involvement or lack thereof.
However, I can tell you what my involvement has been.  I got involved
with it because some of our customers use fscache with NFS and I've
supported it.  I saw dhowells rewriting it to greatly simplify the
code and make it easier to debug and wanted to support the effort.

I have been working on the NFS conversion as dhowells has been
evolving the fscache-iter API.  David first posted the series I think
in Dec 2019 and I started with NFS about mid-year 2020, and had my
first post of NFS patches in July:
https://marc.info/?l=linux-nfs=159482591232752=2

One thing that came out of the earlier iterations as a result of my
testing was the need for the network filesystem to be able to 'cap'
the IO size based on its parameters, hence the "clamp_length()"
function.  So the next iteration dhowells further evolved it into a
'netfs' API and a 'fscache' API, and my November post was based on
that:
https://marc.info/?l=linux-nfs=160596540022461=2

Each iteration has greatly simplified the interface to the network
filesystem until today where the API is pretty simple.  I have done
extensive tests with each iteration with all the main NFS versions,
specific unit tests, xfstests, etc.  However my test matrix did not
hit enough fscache + pNFS servers, and I found a problem too late to
include in his pull request.  This is mostly why my patches were not
included to convert NFS to the new fscache API, but I intend to work
out the remaining issues for the next merge window, and I'll have an
opportunity to do more testing last week of Feb with the NFS "remote
bakeathon".  My most recent post was at the end of Jan, and Anna is
taking the first 5 refactoring patches in the next merge window:
https://marc.info/?l=linux-nfs=161184595127618=2

I do not have the skills of a Trond or Anna NFS developers, but I have
worked in this in earnest and intend to see it through to completion
and support NFS and fscache work.  I have received some feedback on
the NFS patches though it's not been a lot, I do know I have some
things to address still.  With open source, no feedback is hard to
draw conclusions other than it's not "super popular" area, but we
always knew that about fscache - it's an "add on" that some customers
require but not everyone. I know Trond speaks up when I make a mistake
and/or something will cause a problem, so I consider the silence
mostly a positive sign.



> See my problem? I need to be convinced that this makes sense outside
> of your world, and it's not yet another thing that will cause problems
> down the line because nobody else really ever used it or cared about
> it until we hit a snag.
>
>   Linus
>

[PATCH v5 4/4] drm/i915/gen9_bc: Add W/A for missing STRAP config on TGP PCH + CML combos

[Lyude Paul]

Apparently the new gen9_bc platforms that Intel has introduced don't
provide us with a STRAP config register to read from for initializing DDI
B, C, and D detection. So, workaround this by hard-coding our strap config
in intel_setup_outputs().

Changes since v4:
* Split this into it's own commit

Cc: Matt Roper 
Cc: Jani Nikula 
Cc: Ville Syrjala 
[originally from Tejas's work]
Signed-off-by: Tejas Upadhyay 
Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/i915/display/intel_display.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index beed08c00b6c..4dee37f8659d 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -11943,7 +11943,14 @@ static void intel_setup_outputs(struct 
drm_i915_private *dev_priv)
 
/* DDI B, C, D, and F detection is indicated by the SFUSE_STRAP
 * register */
-   found = intel_de_read(dev_priv, SFUSE_STRAP);
+   if (HAS_PCH_TGP(dev_priv)) {
+   /* W/A due to lack of STRAP config on TGP PCH*/
+   found = (SFUSE_STRAP_DDIB_DETECTED |
+SFUSE_STRAP_DDIC_DETECTED |
+SFUSE_STRAP_DDID_DETECTED);
+   } else {
+   found = intel_de_read(dev_priv, SFUSE_STRAP);
+   }
 
if (found & SFUSE_STRAP_DDIB_DETECTED)
intel_ddi_init(dev_priv, PORT_B);
-- 
2.29.2

Re: [RESEND][PATCH] drm/tilcdc: send vblank event when disabling crtc

[Jyri Sarha]

On 2021-02-09 10:24, quanyang.w...@windriver.com wrote:

From: Quanyang Wang 

When run xrandr to change resolution on Beaglebone Black board, it will
print the error information:

root@beaglebone:~# xrandr -display :0 --output HDMI-1 --mode 720x400
[drm:drm_crtc_commit_wait] *ERROR* flip_done timed out
[drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:32:tilcdc
crtc] commit wait timed out
[drm:drm_crtc_commit_wait] *ERROR* flip_done timed out
[drm:drm_atomic_helper_wait_for_dependencies] *ERROR*
[CONNECTOR:34:HDMI-A-1] commit wait timed out
[drm:drm_crtc_commit_wait] *ERROR* flip_done timed out
[drm:drm_atomic_helper_wait_for_dependencies] *ERROR*
[PLANE:31:plane-0] commit wait timed out
tilcdc 4830e000.lcdc: already pending page flip!

This is because there is operation sequence as below:

drm_atomic_connector_commit_dpms(mode is DRM_MODE_DPMS_OFF):
...
drm_atomic_helper_setup_commit <- 
init_completion(commit_A->flip_done)

drm_atomic_helper_commit_tail
tilcdc_crtc_atomic_disable
tilcdc_plane_atomic_update <- drm_crtc_send_vblank_event in
tilcdc_crtc_irq
  is skipped since 
tilcdc_crtc->enabled is 0

tilcdc_crtc_atomic_flush   <- drm_crtc_send_vblank_event is
skipped since
  crtc->state->event is set to be 
NULL in

  tilcdc_plane_atomic_update
drm_mode_setcrtc:
...
drm_atomic_helper_setup_commit <- 
init_completion(commit_B->flip_done)

drm_atomic_helper_wait_for_dependencies
drm_crtc_commit_wait   <- wait for commit_A->flip_done 
completing


Just as shown above, the steps which could complete commit_A->flip_done
are all skipped and commit_A->flip_done will never be completed. This 
will
result a time-out ERROR when drm_crtc_commit_wait check the 
commit_A->flip_done.

So add drm_crtc_send_vblank_event in tilcdc_crtc_atomic_disable to
complete commit_A->flip_done.

Fixes: cb345decb4d2 ("drm/tilcdc: Use standard 
drm_atomic_helper_commit")

Signed-off-by: Quanyang Wang 


Reviewed-by: Jyri Sarha 
Tested-by: Jyri Sarha 

Thanks a lot! I think I have bumbed into this once or twice, but latelu 
I have had time to look into this. I'll merge this to drm-misc-next 
soon.


Best regards,
Jyri


---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 30213708fc99..d99afd19ca08 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -515,6 +515,15 @@ static void tilcdc_crtc_off(struct drm_crtc
*crtc, bool shutdown)

drm_crtc_vblank_off(crtc);

+   spin_lock_irq(>dev->event_lock);
+
+   if (crtc->state->event) {
+   drm_crtc_send_vblank_event(crtc, crtc->state->event);
+   crtc->state->event = NULL;
+   }
+
+   spin_unlock_irq(>dev->event_lock);
+
tilcdc_crtc_disable_irqs(dev);

pm_runtime_put_sync(dev->dev);

Re: [PATCH mvebu v2 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz

[Pali Rohár]

On Tuesday 09 February 2021 13:45:08 nnet wrote:
> On Tue, Feb 9, 2021, at 1:33 PM, Pali Rohár wrote:
> > On Tuesday 09 February 2021 13:00:26 nnet wrote:
> > > > If you have other Armada 3720 boards (Espressobin v5/v7, uDPU, Devel 
> > > > Board, ...) then it will be nice to do an additional tests and check if 
> > > > instability issues are finally fixed.
> > > 
> > > These patches applied to the 5.4.96 in OpenWrt (98d61b5) work fine so far 
> > > on an Espressobin v7 AFAICT per changing values in 
> > > /sys/devices/system/cpu/cpufreq/policy0.
> > > 
> > > Are these changes intended to work @1.2 GHz on the v7?
> > 
> > Hello! Do you have 1.2 GHz A3720 SoC?
> 
> Maybe (not)? ESPRESSObin_V7_1-0 on the underside.

Look at the package of SoC chip. On top of the package is printed
identifier 88F3720. On the last line should be one of the string:
C080, C100, C120, I080, I100 which identifies frequency
(080 = 800 MHz, 100 = 1 GHz, 120 = 1.2 GHz)

Can you check what is printed on A3720 SoC package?

> BTW, with the 1200_750 firmware and the patches:
> 
> root@OpenWrt:/sys/devices/system/cpu/cpufreq/policy0# cat 
> scaling_available_frequencies 
> 20 30 60 120
> 
> Of course that could mean nothing, but thought I'd mention what I do see.

This is value set by firmware file which you have started.