Re: [PATCH V3 1/3] arm64: topology: Avoid the have_policy check

[Viresh Kumar]

On 15-12-20, 11:04, Viresh Kumar wrote:
> Every time I have stumbled upon this routine, I get confused with the
> way 'have_policy' is used and I have to dig in to understand why is it
> so. Here is an attempt to make it easier to understand, and hopefully it
> is an improvement.
> 
> The 'have_policy' check was just an optimization to avoid writing
> to amu_fie_cpus in case we don't have to, but that optimization itself
> is creating more confusion than the real work. Lets just do that if all
> the CPUs support AMUs. It is much cleaner that way.
> 
> Reviewed-by: Ionela Voinescu 
> Signed-off-by: Viresh Kumar 
> ---
> V3:
> - Added Reviewed by tag.

Catalin, please pick the first two patches for 5.11. I will send the
last one separately later on.

-- 
viresh

Re: [PATCH 1/2] blk-iocost: Add iocg idle state tracepoint

[Baolin Wang]

Hi Jens,


It will be helpful to trace the iocg's whole state, including active and
idle state. And we can easily expand the original iocost_iocg_activate
trace event to support a state trace class, including active and idle
state tracing.

Signed-off-by: Baolin Wang 


Could you pick up patch 1 which was already acked by Tejun. Thanks.


---
  block/blk-iocost.c|  3 +++
  include/trace/events/iocost.h | 16 +++-
  2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/block/blk-iocost.c b/block/blk-iocost.c
index ffa418c..ac6078a 100644
--- a/block/blk-iocost.c
+++ b/block/blk-iocost.c
@@ -2185,6 +2185,9 @@ static int ioc_check_iocgs(struct ioc *ioc, struct 
ioc_now *now)
WEIGHT_ONE);
}
  
+			TRACE_IOCG_PATH(iocg_idle, iocg, now,

+   atomic64_read(>active_period),
+   atomic64_read(>cur_period), vtime);
__propagate_weights(iocg, 0, 0, false, now);
list_del_init(>active_list);
}
diff --git a/include/trace/events/iocost.h b/include/trace/events/iocost.h
index 0b68699..e282ce0 100644
--- a/include/trace/events/iocost.h
+++ b/include/trace/events/iocost.h
@@ -11,7 +11,7 @@
  
  #include 
  
-TRACE_EVENT(iocost_iocg_activate,

+DECLARE_EVENT_CLASS(iocost_iocg_state,
  
  	TP_PROTO(struct ioc_gq *iocg, const char *path, struct ioc_now *now,

u64 last_period, u64 cur_period, u64 vtime),
@@ -59,6 +59,20 @@
)
  );
  
+DEFINE_EVENT(iocost_iocg_state, iocost_iocg_activate,

+   TP_PROTO(struct ioc_gq *iocg, const char *path, struct ioc_now *now,
+u64 last_period, u64 cur_period, u64 vtime),
+
+   TP_ARGS(iocg, path, now, last_period, cur_period, vtime)
+);
+
+DEFINE_EVENT(iocost_iocg_state, iocost_iocg_idle,
+   TP_PROTO(struct ioc_gq *iocg, const char *path, struct ioc_now *now,
+u64 last_period, u64 cur_period, u64 vtime),
+
+   TP_ARGS(iocg, path, now, last_period, cur_period, vtime)
+);
+
  DECLARE_EVENT_CLASS(iocg_inuse_update,
  
  	TP_PROTO(struct ioc_gq *iocg, const char *path, struct ioc_now *now,

[PATCH V2 XRT Alveo 3/6] fpga: xrt: core infrastructure for xrt-lib module

[Sonal Santan]

From: Sonal Santan 

Add xrt-lib kernel module infrastructrure code which defines APIs
for working with device nodes, iteration and lookup of platform
devices, common interfaces for platform devices, plumbing of
function call and ioctls between platform devices and parent
partitions.

Signed-off-by: Sonal Santan 
---
 drivers/fpga/xrt/include/metadata.h  |  184 
 drivers/fpga/xrt/include/parent.h|  103 ++
 drivers/fpga/xrt/include/partition.h |   33 +
 drivers/fpga/xrt/include/subdev.h|  333 ++
 drivers/fpga/xrt/lib/subdevs/xrt-partition.c |  261 +
 drivers/fpga/xrt/lib/xrt-cdev.c  |  234 
 drivers/fpga/xrt/lib/xrt-main.c  |  270 +
 drivers/fpga/xrt/lib/xrt-main.h  |   46 +
 drivers/fpga/xrt/lib/xrt-subdev.c| 1007 ++
 9 files changed, 2471 insertions(+)
 create mode 100644 drivers/fpga/xrt/include/metadata.h
 create mode 100644 drivers/fpga/xrt/include/parent.h
 create mode 100644 drivers/fpga/xrt/include/partition.h
 create mode 100644 drivers/fpga/xrt/include/subdev.h
 create mode 100644 drivers/fpga/xrt/lib/subdevs/xrt-partition.c
 create mode 100644 drivers/fpga/xrt/lib/xrt-cdev.c
 create mode 100644 drivers/fpga/xrt/lib/xrt-main.c
 create mode 100644 drivers/fpga/xrt/lib/xrt-main.h
 create mode 100644 drivers/fpga/xrt/lib/xrt-subdev.c

diff --git a/drivers/fpga/xrt/include/metadata.h 
b/drivers/fpga/xrt/include/metadata.h
new file mode 100644
index ..f445bfc279d2
--- /dev/null
+++ b/drivers/fpga/xrt/include/metadata.h
@@ -0,0 +1,184 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Xilinx Alveo FPGA Test Leaf Driver
+ *
+ * Copyright (C) 2020 Xilinx, Inc.
+ *
+ * Authors:
+ *  Lizhi Hou 
+ */
+
+#ifndef _XRT_METADATA_H
+#define _XRT_METADATA_H
+
+#include 
+#include 
+#include 
+
+#define PROP_COMPATIBLE "compatible"
+#define PROP_PF_NUM "pcie_physical_function"
+#define PROP_BAR_IDX "pcie_bar_mapping"
+#define PROP_IO_OFFSET "reg"
+#define PROP_INTERRUPTS "interrupts"
+#define PROP_INTERFACE_UUID "interface_uuid"
+#define PROP_LOGIC_UUID "logic_uuid"
+#define PROP_VERSION_MAJOR "firmware_version_major"
+
+#define PROP_HWICAP "axi_hwicap"
+#define PROP_PDI_CONFIG "pdi_config_mem"
+
+#define NODE_ENDPOINTS "addressable_endpoints"
+#define INTERFACES_PATH "/interfaces"
+
+#define NODE_FIRMWARE "firmware"
+#define NODE_INTERFACES "interfaces"
+#define NODE_PARTITION_INFO "partition_info"
+
+#define NODE_FLASH "ep_card_flash_program_00"
+#define NODE_XVC_PUB "ep_debug_bscan_user_00"
+#define NODE_XVC_PRI "ep_debug_bscan_mgmt_00"
+#define NODE_SYSMON "ep_cmp_sysmon_00"
+#define NODE_AF_BLP_CTRL_MGMT "ep_firewall_blp_ctrl_mgmt_00"
+#define NODE_AF_BLP_CTRL_USER "ep_firewall_blp_ctrl_user_00"
+#define NODE_AF_CTRL_MGMT "ep_firewall_ctrl_mgmt_00"
+#define NODE_AF_CTRL_USER "ep_firewall_ctrl_user_00"
+#define NODE_AF_CTRL_DEBUG "ep_firewall_ctrl_debug_00"
+#define NODE_AF_DATA_H2C "ep_firewall_data_h2c_00"
+#define NODE_AF_DATA_C2H "ep_firewall_data_c2h_00"
+#define NODE_AF_DATA_P2P "ep_firewall_data_p2p_00"
+#define NODE_AF_DATA_M2M "ep_firewall_data_m2m_00"
+#define NODE_CMC_REG "ep_cmc_regmap_00"
+#define NODE_CMC_RESET "ep_cmc_reset_00"
+#define NODE_CMC_MUTEX "ep_cmc_mutex_00"
+#define NODE_CMC_FW_MEM "ep_cmc_firmware_mem_00"
+#define NODE_ERT_FW_MEM "ep_ert_firmware_mem_00"
+#define NODE_ERT_CQ_MGMT "ep_ert_command_queue_mgmt_00"
+#define NODE_ERT_CQ_USER "ep_ert_command_queue_user_00"
+#define NODE_MAILBOX_MGMT "ep_mailbox_mgmt_00"
+#define NODE_MAILBOX_USER "ep_mailbox_user_00"
+#define NODE_GATE_PLP "ep_pr_isolate_plp_00"
+#define NODE_GATE_ULP "ep_pr_isolate_ulp_00"
+#define NODE_PCIE_MON "ep_pcie_link_mon_00"
+#define NODE_DDR_CALIB "ep_ddr_mem_calib_00"
+#define NODE_CLK_KERNEL1 "ep_aclk_kernel_00"
+#define NODE_CLK_KERNEL2 "ep_aclk_kernel_01"
+#define NODE_CLK_KERNEL3 "ep_aclk_hbm_00"
+#define NODE_KDMA_CTRL "ep_kdma_ctrl_00"
+#define NODE_FPGA_CONFIG "ep_fpga_configuration_00"
+#define NODE_ERT_SCHED "ep_ert_sched_00"
+#define NODE_XDMA "ep_xdma_00"
+#define NODE_MSIX "ep_msix_00"
+#define NODE_QDMA "ep_qdma_00"
+#define NODE_QDMA4 "ep_qdma4_00"
+#define NODE_STM "ep_stream_traffic_manager_00"
+#define NODE_STM4 "ep_stream_traffic_manager4_00"
+#define NODE_CLK_SHUTDOWN "ep_aclk_shutdown_00"
+#define NODE_ERT_BASE "ep_ert_base_address_00"
+#define NODE_ERT_RESET "ep_ert_reset_00"
+#define NODE_CLKFREQ_K1 "ep_freq_cnt_aclk_kernel_00"
+#define NODE_CLKFREQ_K2 "ep_freq_cnt_aclk_kernel_01"
+#define NODE_CLKFREQ_HBM "ep_freq_cnt_aclk_hbm_00"
+#define NODE_GAPPING "ep_gapping_demand_00"
+#define NODE_UCS_CONTROL_STATUS "ep_ucs_control_status_00"
+#define NODE_P2P "ep_p2p_00"
+#define NODE_REMAP_P2P "ep_remap_p2p_00"
+#define NODE_DDR4_RESET_GATE "ep_ddr_mem_srsr_gate_00"
+#define NODE_ADDR_TRANSLATOR "ep_remap_data_c2h_00"
+#define NODE_MAILBOX_XRT "ep_mailbox_user_to_ert_00"
+#define NODE_PMC_INTR   "ep_pmc_intr_00"
+#define NODE_PMC_MUX"ep_pmc_mux_00"
+
+/* 

[PATCH V2 XRT Alveo 6/6] fpga: xrt: Kconfig and Makefile updates for XRT drivers

[Sonal Santan]

From: Sonal Santan 

Update fpga Kconfig/Makefile and add Kconfig/Makefile for
new drivers.

Signed-off-by: Sonal Santan 
---
 drivers/fpga/Kconfig   |  2 ++
 drivers/fpga/Makefile  |  4 
 drivers/fpga/xrt/Kconfig   |  7 +++
 drivers/fpga/xrt/Makefile  | 21 +
 drivers/fpga/xrt/lib/Kconfig   | 11 +++
 drivers/fpga/xrt/lib/Makefile  | 30 ++
 drivers/fpga/xrt/mgmt/Kconfig  | 11 +++
 drivers/fpga/xrt/mgmt/Makefile | 27 +++
 8 files changed, 113 insertions(+)
 create mode 100644 drivers/fpga/xrt/Kconfig
 create mode 100644 drivers/fpga/xrt/Makefile
 create mode 100644 drivers/fpga/xrt/lib/Kconfig
 create mode 100644 drivers/fpga/xrt/lib/Makefile
 create mode 100644 drivers/fpga/xrt/mgmt/Kconfig
 create mode 100644 drivers/fpga/xrt/mgmt/Makefile

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 7cd5a29fc437..73e4deb20986 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -215,4 +215,6 @@ config FPGA_MGR_ZYNQMP_FPGA
  to configure the programmable logic(PL) through PS
  on ZynqMP SoC.
 
+source "drivers/fpga/xrt/Kconfig"
+
 endif # FPGA
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index d8e21dfc6778..2b4453ff7c52 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -46,3 +46,7 @@ dfl-afu-objs += dfl-afu-error.o
 
 # Drivers for FPGAs which implement DFL
 obj-$(CONFIG_FPGA_DFL_PCI) += dfl-pci.o
+
+# XRT drivers for Alveo
+obj-$(CONFIG_FPGA_XRT_LIB) += xrt/lib/
+obj-$(CONFIG_FPGA_XRT_XMGMT)   += xrt/mgmt/
diff --git a/drivers/fpga/xrt/Kconfig b/drivers/fpga/xrt/Kconfig
new file mode 100644
index ..50422f77c6df
--- /dev/null
+++ b/drivers/fpga/xrt/Kconfig
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Xilinx Alveo FPGA device configuration
+#
+
+source "drivers/fpga/xrt/lib/Kconfig"
+source "drivers/fpga/xrt/mgmt/Kconfig"
diff --git a/drivers/fpga/xrt/Makefile b/drivers/fpga/xrt/Makefile
new file mode 100644
index ..19e828cc7af9
--- /dev/null
+++ b/drivers/fpga/xrt/Makefile
@@ -0,0 +1,21 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Copyright (C) 2020 Xilinx, Inc. All rights reserved.
+#
+# Authors: sonal.san...@xilinx.com
+#
+
+all:
+   $(MAKE) -C lib all
+   $(MAKE) -C mgmt all
+   $(MAKE) lint
+
+tags:
+   ../../../../scripts/tags.sh
+
+clean:
+   $(MAKE) -C lib clean
+   $(MAKE) -C mgmt clean
+
+lint:
+   ../../../../scripts/lint.sh
diff --git a/drivers/fpga/xrt/lib/Kconfig b/drivers/fpga/xrt/lib/Kconfig
new file mode 100644
index ..541af91008ee
--- /dev/null
+++ b/drivers/fpga/xrt/lib/Kconfig
@@ -0,0 +1,11 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# XRT Alveo FPGA device configuration
+#
+
+config FPGA_XRT_LIB
+   tristate "XRT Alveo Driver Library"
+   depends on HWMON && PCI
+   select LIBFDT
+   help
+ XRT Alveo FPGA PCIe device driver common library.
diff --git a/drivers/fpga/xrt/lib/Makefile b/drivers/fpga/xrt/lib/Makefile
new file mode 100644
index ..176e2134171c
--- /dev/null
+++ b/drivers/fpga/xrt/lib/Makefile
@@ -0,0 +1,30 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Copyright (C) 2020 Xilinx, Inc. All rights reserved.
+#
+# Authors: sonal.san...@xilinx.com
+#
+
+FULL_XRT_PATH=$(srctree)/$(src)/..
+FULL_DTC_PATH=$(srctree)/scripts/dtc/libfdt
+
+obj-$(CONFIG_FPGA_XRT_LIB) := xrt-lib.o
+
+xrt-lib-objs :=\
+   xrt-main.o  \
+   xrt-subdev.o\
+   xrt-cdev.o  \
+   ../common/xrt-metadata.o\
+   subdevs/xrt-partition.o \
+   subdevs/xrt-vsec.o  \
+   subdevs/xrt-axigate.o   \
+   subdevs/xrt-gpio.o  \
+   subdevs/xrt-icap.o  \
+   subdevs/xrt-clock.o \
+   subdevs/xrt-clkfreq.o   \
+   subdevs/xrt-ucs.o   \
+   subdevs/xrt-calib.o
+
+ccflags-y := -I$(FULL_XRT_PATH)/include \
+   -I$(FULL_XRT_PATH)/common \
+   -I$(FULL_DTC_PATH)
diff --git a/drivers/fpga/xrt/mgmt/Kconfig b/drivers/fpga/xrt/mgmt/Kconfig
new file mode 100644
index ..a2fe7ab21941
--- /dev/null
+++ b/drivers/fpga/xrt/mgmt/Kconfig
@@ -0,0 +1,11 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Xilinx XRT FPGA device configuration
+#
+
+config FPGA_XRT_XMGMT
+   tristate "Xilinx Alveo Management Driver"
+   depends on HWMON && PCI && FPGA_XRT_LIB
+   select LIBFDT
+   help
+ XRT Alveo FPGA PCIe device driver for Management Physical Function.
diff --git a/drivers/fpga/xrt/mgmt/Makefile b/drivers/fpga/xrt/mgmt/Makefile
new file mode 100644
index ..d32698b8bf58
--- /dev/null
+++ b/drivers/fpga/xrt/mgmt/Makefile
@@ -0,0 +1,27 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Copyright (C) 2019-2020 Xilinx, Inc. All rights reserved.
+#
+# 

[PATCH V2 XRT Alveo 4/6] fpga: xrt: XRT Alveo management physical function driver

[Sonal Santan]

From: Sonal Santan 

Add management physical function driver core. The driver attaches
to management physical function of Alveo devices. It instantiates
the root driver and one or more partition drivers which in turn
instantiate platform drivers. The instantiation of partition and
platform drivers is completely data driven. The driver integrates
with FPGA manager and provides xclbin download service.

Signed-off-by: Sonal Santan 
---
 drivers/fpga/xrt/include/xmgmt-main.h |  34 +
 drivers/fpga/xrt/mgmt/xmgmt-fmgr-drv.c| 179 ++
 drivers/fpga/xrt/mgmt/xmgmt-fmgr.h|  29 +
 drivers/fpga/xrt/mgmt/xmgmt-main-impl.h   |  35 +
 drivers/fpga/xrt/mgmt/xmgmt-main-region.c | 476 ++
 drivers/fpga/xrt/mgmt/xmgmt-main.c| 738 ++
 drivers/fpga/xrt/mgmt/xmgmt-root.c| 375 +++
 include/uapi/linux/xrt/xmgmt-ioctl.h  |  72 +++
 8 files changed, 1938 insertions(+)
 create mode 100644 drivers/fpga/xrt/include/xmgmt-main.h
 create mode 100644 drivers/fpga/xrt/mgmt/xmgmt-fmgr-drv.c
 create mode 100644 drivers/fpga/xrt/mgmt/xmgmt-fmgr.h
 create mode 100644 drivers/fpga/xrt/mgmt/xmgmt-main-impl.h
 create mode 100644 drivers/fpga/xrt/mgmt/xmgmt-main-region.c
 create mode 100644 drivers/fpga/xrt/mgmt/xmgmt-main.c
 create mode 100644 drivers/fpga/xrt/mgmt/xmgmt-root.c
 create mode 100644 include/uapi/linux/xrt/xmgmt-ioctl.h

diff --git a/drivers/fpga/xrt/include/xmgmt-main.h 
b/drivers/fpga/xrt/include/xmgmt-main.h
new file mode 100644
index ..3f26c480ce27
--- /dev/null
+++ b/drivers/fpga/xrt/include/xmgmt-main.h
@@ -0,0 +1,34 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2020 Xilinx, Inc.
+ *
+ * Authors:
+ * Cheng Zhen 
+ */
+
+#ifndef_XMGMT_MAIN_H_
+#define_XMGMT_MAIN_H_
+
+#include 
+
+enum xrt_mgmt_main_ioctl_cmd {
+   // section needs to be vfree'd by caller
+   XRT_MGMT_MAIN_GET_AXLF_SECTION = 0,
+   // vbnv needs to be kfree'd by caller
+   XRT_MGMT_MAIN_GET_VBNV,
+};
+
+enum provider_kind {
+   XMGMT_BLP,
+   XMGMT_PLP,
+   XMGMT_ULP,
+};
+
+struct xrt_mgmt_main_ioctl_get_axlf_section {
+   enum provider_kind xmmigas_axlf_kind;
+   enum axlf_section_kind xmmigas_section_kind;
+   void *xmmigas_section;
+   u64 xmmigas_section_size;
+};
+
+#endif /* _XMGMT_MAIN_H_ */
diff --git a/drivers/fpga/xrt/mgmt/xmgmt-fmgr-drv.c 
b/drivers/fpga/xrt/mgmt/xmgmt-fmgr-drv.c
new file mode 100644
index ..5e4a4e20b228
--- /dev/null
+++ b/drivers/fpga/xrt/mgmt/xmgmt-fmgr-drv.c
@@ -0,0 +1,179 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx Alveo Management Function Driver
+ *
+ * Copyright (C) 2019-2020 Xilinx, Inc.
+ * Bulk of the code borrowed from XRT mgmt driver file, fmgr.c
+ *
+ * Authors: sonal.san...@xilinx.com
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "xrt-xclbin.h"
+#include "subdev.h"
+#include "xmgmt-fmgr.h"
+#include "subdev/axigate.h"
+#include "subdev/icap.h"
+#include "xmgmt-main-impl.h"
+
+struct xfpga_klass {
+   const struct platform_device *pdev;
+   char  name[64];
+};
+
+/*
+ * xclbin download plumbing -- find the download subsystem, ICAP and
+ * pass the xclbin for heavy lifting
+ */
+static int xmgmt_download_bitstream(struct platform_device *pdev,
+   const struct axlf *xclbin)
+
+{
+   struct XHwIcap_Bit_Header bit_header = { 0 };
+   struct platform_device *icap_leaf = NULL;
+   struct xrt_icap_ioctl_wr arg;
+   char *bitstream = NULL;
+   int ret;
+
+   ret = xrt_xclbin_get_section(xclbin, BITSTREAM, (void **),
+   NULL);
+   if (ret || !bitstream) {
+   xrt_err(pdev, "bitstream not found");
+   return -ENOENT;
+   }
+   ret = xrt_xclbin_parse_header(bitstream,
+   DMA_HWICAP_BITFILE_BUFFER_SIZE, _header);
+   if (ret) {
+   ret = -EINVAL;
+   xrt_err(pdev, "invalid bitstream header");
+   goto done;
+   }
+   icap_leaf = xrt_subdev_get_leaf_by_id(pdev, XRT_SUBDEV_ICAP,
+   PLATFORM_DEVID_NONE);
+   if (!icap_leaf) {
+   ret = -ENODEV;
+   xrt_err(pdev, "icap does not exist");
+   goto done;
+   }
+   arg.xiiw_bit_data = bitstream + bit_header.HeaderLength;
+   arg.xiiw_data_len = bit_header.BitstreamLength;
+   ret = xrt_subdev_ioctl(icap_leaf, XRT_ICAP_WRITE, );
+   if (ret)
+   xrt_err(pdev, "write bitstream failed, ret = %d", ret);
+
+done:
+   if (icap_leaf)
+   xrt_subdev_put_leaf(pdev, icap_leaf);
+   vfree(bitstream);
+
+   return ret;
+}
+
+/*
+ * There is no HW prep work we do here since we need the full
+ * xclbin for its sanity check.
+ */
+static int xmgmt_pr_write_init(struct fpga_manager *mgr,
+   struct fpga_image_info *info, const char *buf, size_t count)
+{
+   const struct axlf *bin = 

Re: [PATCH 2/2] blk-iocost: Use alloc_percpu_gfp() to simplify the code

[Baolin Wang]

Hi Tejun,


Hello,

On Fri, Dec 11, 2020 at 03:13:29PM +0800, Baolin Wang wrote:

Thanks for teaching me this, at least I did not get this from the local_ops
Documentation before. Just out of curiosity, these local[64]_t variables are
also allocated from budy allocator ultimately, why they can not be
initialized to zeros on some ARCHs with __GFP_ZERO? Could you elaborate on
about this restriction? Thanks.


* It's highly unlikely but theoretically possible that some arch might need
   more than raw value to implement local semantics.

* People might wanna add debug annotations which may require more than just
   the raw value.


Thanks for your explanation. It will be helpful to add these comments 
for the code in case someone else wants to do the same thing like this 
patch in future. I can send a patch to add these comments if you have no 
objection.



By the way, seems the kyber-iosched has the same issue, since the 'struct
kyber_cpu_latency' also contains an atomic_t variable.

kqd->cpu_latency = alloc_percpu_gfp(struct kyber_cpu_latency,
GFP_KERNEL | __GFP_ZERO);
if (!kqd->cpu_latency)
goto err_kqd;


Yeah, the lines become blurry when all existing usages are fine with zeroing
and we do end up needing to clean up those when the need arises (e.g. we
used to zero some spinlocks too). It's just a better form to stick with
initializers when they are provided.


OK. Sounds it is worth sending a patch to initialize this structure 
explicitly to keep consistent.

[PATCH V2 XRT Alveo 5/6] fpga: xrt: platform drivers for subsystems in shell partition

[Sonal Santan]

From: Sonal Santan 

Add platform drivers for HW subsystems found in shell partition.
Each driver implements interfaces defined by xrt-subdev.h. The
driver instances are created by parent partition to manage
subsystem instances discovered by walking device tree. The
platform drivers may populate their own sysfs nodes, create
device nodes if needed and make calls into parent or other
platform drivers. The platform drivers can also send and receive
events.

Signed-off-by: Sonal Santan 
---
 drivers/fpga/xrt/include/subdev/axigate.h  |  31 +
 drivers/fpga/xrt/include/subdev/calib.h|  28 +
 drivers/fpga/xrt/include/subdev/clkfreq.h  |  21 +
 drivers/fpga/xrt/include/subdev/clock.h|  29 +
 drivers/fpga/xrt/include/subdev/gpio.h |  41 ++
 drivers/fpga/xrt/include/subdev/icap.h |  27 +
 drivers/fpga/xrt/include/subdev/ucs.h  |  22 +
 drivers/fpga/xrt/lib/subdevs/xrt-axigate.c | 298 ++
 drivers/fpga/xrt/lib/subdevs/xrt-calib.c   | 226 
 drivers/fpga/xrt/lib/subdevs/xrt-clkfreq.c | 214 +++
 drivers/fpga/xrt/lib/subdevs/xrt-clock.c   | 638 +
 drivers/fpga/xrt/lib/subdevs/xrt-gpio.c| 198 +++
 drivers/fpga/xrt/lib/subdevs/xrt-icap.c| 306 ++
 drivers/fpga/xrt/lib/subdevs/xrt-ucs.c | 238 
 drivers/fpga/xrt/lib/subdevs/xrt-vsec.c| 337 +++
 15 files changed, 2654 insertions(+)
 create mode 100644 drivers/fpga/xrt/include/subdev/axigate.h
 create mode 100644 drivers/fpga/xrt/include/subdev/calib.h
 create mode 100644 drivers/fpga/xrt/include/subdev/clkfreq.h
 create mode 100644 drivers/fpga/xrt/include/subdev/clock.h
 create mode 100644 drivers/fpga/xrt/include/subdev/gpio.h
 create mode 100644 drivers/fpga/xrt/include/subdev/icap.h
 create mode 100644 drivers/fpga/xrt/include/subdev/ucs.h
 create mode 100644 drivers/fpga/xrt/lib/subdevs/xrt-axigate.c
 create mode 100644 drivers/fpga/xrt/lib/subdevs/xrt-calib.c
 create mode 100644 drivers/fpga/xrt/lib/subdevs/xrt-clkfreq.c
 create mode 100644 drivers/fpga/xrt/lib/subdevs/xrt-clock.c
 create mode 100644 drivers/fpga/xrt/lib/subdevs/xrt-gpio.c
 create mode 100644 drivers/fpga/xrt/lib/subdevs/xrt-icap.c
 create mode 100644 drivers/fpga/xrt/lib/subdevs/xrt-ucs.c
 create mode 100644 drivers/fpga/xrt/lib/subdevs/xrt-vsec.c

diff --git a/drivers/fpga/xrt/include/subdev/axigate.h 
b/drivers/fpga/xrt/include/subdev/axigate.h
new file mode 100644
index ..d26f6d31a948
--- /dev/null
+++ b/drivers/fpga/xrt/include/subdev/axigate.h
@@ -0,0 +1,31 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2020 Xilinx, Inc.
+ *
+ * Authors:
+ * Lizhi Hou 
+ */
+
+#ifndef_XRT_AXIGATE_H_
+#define_XRT_AXIGATE_H_
+
+
+#include "subdev.h"
+#include "metadata.h"
+
+/*
+ * AXIGATE driver IOCTL calls.
+ */
+enum xrt_axigate_ioctl_cmd {
+   XRT_AXIGATE_FREEZE = 0,
+   XRT_AXIGATE_FREE,
+};
+
+/* the ep names are in the order of hardware layers */
+static const char * const xrt_axigate_epnames[] = {
+   NODE_GATE_PLP,
+   NODE_GATE_ULP,
+   NULL
+};
+
+#endif /* _XRT_AXIGATE_H_ */
diff --git a/drivers/fpga/xrt/include/subdev/calib.h 
b/drivers/fpga/xrt/include/subdev/calib.h
new file mode 100644
index ..9328f28a83b0
--- /dev/null
+++ b/drivers/fpga/xrt/include/subdev/calib.h
@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2020 Xilinx, Inc.
+ *
+ * Authors:
+ * Cheng Zhen 
+ */
+
+#ifndef_XRT_CALIB_H_
+#define_XRT_CALIB_H_
+
+#include "subdev.h"
+#include 
+
+/*
+ * Memory calibration driver IOCTL calls.
+ */
+enum xrt_calib_results {
+   XRT_CALIB_UNKNOWN,
+   XRT_CALIB_SUCCEEDED,
+   XRT_CALIB_FAILED,
+};
+
+enum xrt_calib_ioctl_cmd {
+   XRT_CALIB_RESULT = 0,
+};
+
+#endif /* _XRT_CALIB_H_ */
diff --git a/drivers/fpga/xrt/include/subdev/clkfreq.h 
b/drivers/fpga/xrt/include/subdev/clkfreq.h
new file mode 100644
index ..c4ed0e074510
--- /dev/null
+++ b/drivers/fpga/xrt/include/subdev/clkfreq.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2020 Xilinx, Inc.
+ *
+ * Authors:
+ * Lizhi Hou 
+ */
+
+#ifndef_XRT_CLKFREQ_H_
+#define_XRT_CLKFREQ_H_
+
+#include "subdev.h"
+
+/*
+ * CLKFREQ driver IOCTL calls.
+ */
+enum xrt_clkfreq_ioctl_cmd {
+   XRT_CLKFREQ_READ = 0,
+};
+
+#endif /* _XRT_CLKFREQ_H_ */
diff --git a/drivers/fpga/xrt/include/subdev/clock.h 
b/drivers/fpga/xrt/include/subdev/clock.h
new file mode 100644
index ..8f0b8954dcdb
--- /dev/null
+++ b/drivers/fpga/xrt/include/subdev/clock.h
@@ -0,0 +1,29 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2020 Xilinx, Inc.
+ *
+ * Authors:
+ * Lizhi Hou 
+ */
+
+#ifndef_XRT_CLOCK_H_
+#define_XRT_CLOCK_H_
+
+#include "subdev.h"
+#include 
+
+/*
+ * CLOCK driver IOCTL calls.
+ */
+enum xrt_clock_ioctl_cmd {
+   XRT_CLOCK_SET = 0,
+   XRT_CLOCK_GET,
+   XRT_CLOCK_VERIFY,
+};
+
+struct 

[PATCH V2 XRT Alveo 2/6] fpga: xrt: infrastructure support for xmgmt driver

[Sonal Santan]

From: Sonal Santan 

Add infrastructure code for XRT management physical function
driver. This provides support for enumerating and extracting
sections from xclbin files, interacting with device tree nodes
found in xclbin and working with Alveo partitions.

Signed-off-by: Sonal Santan 
---
 drivers/fpga/xrt/common/xrt-metadata.c | 590 
 drivers/fpga/xrt/common/xrt-root.c | 737 +
 drivers/fpga/xrt/common/xrt-root.h |  26 +
 drivers/fpga/xrt/common/xrt-xclbin.c   | 387 +
 drivers/fpga/xrt/common/xrt-xclbin.h   |  48 ++
 include/uapi/linux/xrt/xclbin.h| 386 +
 6 files changed, 2174 insertions(+)
 create mode 100644 drivers/fpga/xrt/common/xrt-metadata.c
 create mode 100644 drivers/fpga/xrt/common/xrt-root.c
 create mode 100644 drivers/fpga/xrt/common/xrt-root.h
 create mode 100644 drivers/fpga/xrt/common/xrt-xclbin.c
 create mode 100644 drivers/fpga/xrt/common/xrt-xclbin.h
 create mode 100644 include/uapi/linux/xrt/xclbin.h

diff --git a/drivers/fpga/xrt/common/xrt-metadata.c 
b/drivers/fpga/xrt/common/xrt-metadata.c
new file mode 100644
index ..2a5b1ee9e37c
--- /dev/null
+++ b/drivers/fpga/xrt/common/xrt-metadata.c
@@ -0,0 +1,590 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx Alveo FPGA Metadata parse APIs
+ *
+ * Copyright (C) 2020 Xilinx, Inc.
+ *
+ * Authors:
+ *  Lizhi Hou 
+ */
+
+#include 
+#include "libfdt.h"
+#include "metadata.h"
+
+#define MAX_BLOB_SIZE  (4096 * 25)
+
+#define md_err(dev, fmt, args...)  \
+   dev_err(dev, "%s: "fmt, __func__, ##args)
+#define md_warn(dev, fmt, args...) \
+   dev_warn(dev, "%s: "fmt, __func__, ##args)
+#define md_info(dev, fmt, args...) \
+   dev_info(dev, "%s: "fmt, __func__, ##args)
+#define md_dbg(dev, fmt, args...)  \
+   dev_dbg(dev, "%s: "fmt, __func__, ##args)
+
+static int xrt_md_setprop(struct device *dev, char *blob, int offset,
+   const char *prop, const void *val, int size);
+static int xrt_md_overlay(struct device *dev, char *blob, int target,
+   const char *overlay_blob, int overlay_offset);
+static int xrt_md_get_endpoint(struct device *dev, const char *blob,
+   const char *ep_name, const char *regmap_name, int *ep_offset);
+
+long xrt_md_size(struct device *dev, const char *blob)
+{
+   long len = (long) fdt_totalsize(blob);
+
+   return (len > MAX_BLOB_SIZE) ? -EINVAL : len;
+}
+
+int xrt_md_create(struct device *dev, char **blob)
+{
+   int ret = 0;
+
+   WARN_ON(!blob);
+
+   *blob = vmalloc(MAX_BLOB_SIZE);
+   if (!*blob)
+   return -ENOMEM;
+
+   ret = fdt_create_empty_tree(*blob, MAX_BLOB_SIZE);
+   if (ret) {
+   md_err(dev, "format blob failed, ret = %d", ret);
+   goto failed;
+   }
+
+   ret = fdt_next_node(*blob, -1, NULL);
+   if (ret < 0) {
+   md_err(dev, "No Node, ret = %d", ret);
+   goto failed;
+   }
+
+   ret = fdt_add_subnode(*blob, ret, NODE_ENDPOINTS);
+   if (ret < 0)
+   md_err(dev, "add node failed, ret = %d", ret);
+
+failed:
+   if (ret < 0) {
+   vfree(*blob);
+   *blob = NULL;
+   } else
+   ret = 0;
+
+   return ret;
+}
+
+int xrt_md_add_node(struct device *dev, char *blob, int parent_offset,
+   const char *ep_name)
+{
+   int ret;
+
+   ret = fdt_add_subnode(blob, parent_offset, ep_name);
+   if (ret < 0 && ret != -FDT_ERR_EXISTS)
+   md_err(dev, "failed to add node %s. %d", ep_name, ret);
+
+   return ret;
+}
+
+int xrt_md_del_endpoint(struct device *dev, char *blob, const char *ep_name,
+   char *regmap_name)
+{
+   int ret;
+   int ep_offset;
+
+   ret = xrt_md_get_endpoint(dev, blob, ep_name, regmap_name, _offset);
+   if (ret) {
+   md_err(dev, "can not find ep %s", ep_name);
+   return -EINVAL;
+   }
+
+   ret = fdt_del_node(blob, ep_offset);
+   if (ret)
+   md_err(dev, "delete node %s failed, ret %d", ep_name, ret);
+
+   return ret;
+}
+
+static int __xrt_md_add_endpoint(struct device *dev, char *blob,
+   struct xrt_md_endpoint *ep, int *offset, bool root)
+{
+   int ret = 0;
+   int ep_offset;
+   u32 val, count = 0;
+   u64 io_range[2];
+   char comp[128];
+
+   if (!ep->ep_name) {
+   md_err(dev, "empty name");
+   return -EINVAL;
+   }
+
+   if (!root) {
+   ret = xrt_md_get_endpoint(dev, blob, NODE_ENDPOINTS, NULL,
+   _offset);
+   if (ret) {
+   md_err(dev, "invalid blob, ret = %d", ret);
+   return -EINVAL;
+   }
+   } else {
+   ep_offset = 0;
+   }
+
+   ep_offset = xrt_md_add_node(dev, blob, ep_offset, ep->ep_name);
+   if 

[RFC PATCH v2 4/8] net: sparx5: add port module support

[Steen Hegelund]

This add configuration of the Sparx5 port module instances.

Signed-off-by: Steen Hegelund 
Signed-off-by: Bjarni Jonasson 
Signed-off-by: Lars Povlsen 
---
 .../net/ethernet/microchip/sparx5/Makefile|3 +-
 .../ethernet/microchip/sparx5/sparx5_main.c   |9 +
 .../ethernet/microchip/sparx5/sparx5_netdev.c |   14 +-
 .../microchip/sparx5/sparx5_phylink.c |   37 +-
 .../ethernet/microchip/sparx5/sparx5_port.c   | 1140 +
 .../ethernet/microchip/sparx5/sparx5_port.h   |   98 ++
 6 files changed, 1292 insertions(+), 9 deletions(-)
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_port.c
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_port.h

diff --git a/drivers/net/ethernet/microchip/sparx5/Makefile 
b/drivers/net/ethernet/microchip/sparx5/Makefile
index 19a593d17f4a..9c14eec33fd7 100644
--- a/drivers/net/ethernet/microchip/sparx5/Makefile
+++ b/drivers/net/ethernet/microchip/sparx5/Makefile
@@ -5,4 +5,5 @@
 
 obj-$(CONFIG_SPARX5_SWITCH) += sparx5-switch.o
 
-sparx5-switch-objs  := sparx5_main.o sparx5_packet.o sparx5_netdev.o 
sparx5_phylink.o
+sparx5-switch-objs  := sparx5_main.o sparx5_packet.o \
+ sparx5_netdev.o sparx5_port.o sparx5_phylink.o
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_main.c 
b/drivers/net/ethernet/microchip/sparx5/sparx5_main.c
index baa108cd99b2..ea75f993f80e 100644
--- a/drivers/net/ethernet/microchip/sparx5/sparx5_main.c
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_main.c
@@ -24,6 +24,7 @@
 #include 
 
 #include "sparx5_main.h"
+#include "sparx5_port.h"
 
 /* Switch core reset/protect */
 #define RESET_PROT_STAT0x84
@@ -269,6 +270,14 @@ static int sparx5_probe_port(struct sparx5 *sparx5,
spx5_port->conf.speed = SPEED_UNKNOWN;
spx5_port->conf.power_down = true;
sparx5->ports[portno] = spx5_port;
+
+   err = sparx5_port_init(sparx5, spx5_port, conf);
+   if (err) {
+   dev_err(sparx5->dev, "port init failed\n");
+   return err;
+   }
+   spx5_port->conf = *conf;
+
/* Create a phylink for PHY management.  Also handles SFPs */
spx5_port->phylink_config.dev = _port->ndev->dev;
spx5_port->phylink_config.type = PHYLINK_NETDEV;
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_netdev.c 
b/drivers/net/ethernet/microchip/sparx5/sparx5_netdev.c
index 6f9282e9d3f4..98decd1d6f57 100644
--- a/drivers/net/ethernet/microchip/sparx5/sparx5_netdev.c
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_netdev.c
@@ -5,6 +5,7 @@
  */
 
 #include "sparx5_main.h"
+#include "sparx5_port.h"
 
 /* The IFH bit position of the first VSTAX bit. This is because the
  * VSTAX bit positions in Data sheet is starting from zero.
@@ -70,6 +71,7 @@ static int sparx5_port_open(struct net_device *ndev)
struct sparx5_port *port = netdev_priv(ndev);
int err = 0;
 
+   sparx5_port_enable(port, true);
err = phylink_of_phy_connect(port->phylink, port->of_node, 0);
if (err) {
netdev_err(ndev, "Could not attach to PHY\n");
@@ -81,7 +83,10 @@ static int sparx5_port_open(struct net_device *ndev)
if (!ndev->phydev) {
/* power up serdes */
port->conf.power_down = false;
-   err = phy_power_on(port->serdes);
+   if (port->conf.serdes_reset)
+   err = sparx5_serdes_set(port->sparx5, port, 
>conf);
+   else
+   err = phy_power_on(port->serdes);
if (err)
netdev_err(ndev, "%s failed\n", __func__);
}
@@ -94,12 +99,17 @@ static int sparx5_port_stop(struct net_device *ndev)
struct sparx5_port *port = netdev_priv(ndev);
int err = 0;
 
+   sparx5_port_enable(port, false);
phylink_stop(port->phylink);
phylink_disconnect_phy(port->phylink);
 
if (!ndev->phydev) {
+   /* power down serdes */
port->conf.power_down = true;
-   err = phy_power_off(port->serdes);
+   if (port->conf.serdes_reset)
+   err = sparx5_serdes_set(port->sparx5, port, 
>conf);
+   else
+   err = phy_power_off(port->serdes);
if (err)
netdev_err(ndev, "%s failed\n", __func__);
}
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_phylink.c 
b/drivers/net/ethernet/microchip/sparx5/sparx5_phylink.c
index 8166bdedaea1..b474fc29e8df 100644
--- a/drivers/net/ethernet/microchip/sparx5/sparx5_phylink.c
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_phylink.c
@@ -11,6 +11,7 @@
 #include 
 
 #include "sparx5_main.h"
+#include "sparx5_port.h"
 
 static void sparx5_phylink_validate(struct phylink_config *config,
unsigned long *supported,
@@ -91,6 +92,7 @@ static void sparx5_phylink_mac_config(struct phylink_config 
*config,
 {
struct 

[RFC PATCH v2 5/8] net: sparx5: add switching, vlan and mactable support

[Steen Hegelund]

This adds SwitchDev support by hardware offloading the
SW bridge and setting up the Sparx5 MAC/VLAN tables, and listening
for MAC table updates.

Signed-off-by: Steen Hegelund 
Signed-off-by: Bjarni Jonasson 
Signed-off-by: Lars Povlsen 
---
 .../net/ethernet/microchip/sparx5/Makefile|   3 +-
 .../microchip/sparx5/sparx5_mactable.c| 502 +
 .../ethernet/microchip/sparx5/sparx5_main.c   |  32 ++
 .../ethernet/microchip/sparx5/sparx5_main.h   |  51 ++
 .../ethernet/microchip/sparx5/sparx5_netdev.c |  31 ++
 .../ethernet/microchip/sparx5/sparx5_packet.c |   6 +
 .../microchip/sparx5/sparx5_switchdev.c   | 516 ++
 .../ethernet/microchip/sparx5/sparx5_vlan.c   | 223 
 8 files changed, 1363 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_mactable.c
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_switchdev.c
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_vlan.c

diff --git a/drivers/net/ethernet/microchip/sparx5/Makefile 
b/drivers/net/ethernet/microchip/sparx5/Makefile
index 9c14eec33fd7..32e0691e328a 100644
--- a/drivers/net/ethernet/microchip/sparx5/Makefile
+++ b/drivers/net/ethernet/microchip/sparx5/Makefile
@@ -5,5 +5,6 @@
 
 obj-$(CONFIG_SPARX5_SWITCH) += sparx5-switch.o
 
-sparx5-switch-objs  := sparx5_main.o sparx5_packet.o \
+sparx5-switch-objs  := sparx5_main.o sparx5_switchdev.o \
+ sparx5_vlan.o sparx5_mactable.o sparx5_packet.o \
  sparx5_netdev.o sparx5_port.o sparx5_phylink.o
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_mactable.c 
b/drivers/net/ethernet/microchip/sparx5/sparx5_mactable.c
new file mode 100644
index ..a65a87cdba85
--- /dev/null
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_mactable.c
@@ -0,0 +1,502 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Microchip Sparx5 Switch driver
+ *
+ * Copyright (c) 2020 Microchip Technology Inc. and its subsidiaries.
+ */
+
+#include 
+#include 
+
+#include "sparx5_main.h"
+
+/* Commands for Mac Table Command register */
+#define MAC_CMD_LEARN 0 /* Insert (Learn) 1 entry */
+#define MAC_CMD_UNLEARN   1 /* Unlearn (Forget) 1 entry */
+#define MAC_CMD_LOOKUP2 /* Look up 1 entry */
+#define MAC_CMD_READ  3 /* Read entry at Mac Table Index */
+#define MAC_CMD_WRITE 4 /* Write entry at Mac Table Index */
+#define MAC_CMD_SCAN  5 /* Scan (Age or find next) */
+#define MAC_CMD_FIND_SMALLEST 6 /* Get next entry */
+#define MAC_CMD_CLEAR_ALL 7 /* Delete all entries in table */
+
+/* Commands for MAC_ENTRY_ADDR_TYPE */
+#define  MAC_ENTRY_ADDR_TYPE_UPSID_PN 0
+#define  MAC_ENTRY_ADDR_TYPE_UPSID_CPU_OR_INT 1
+#define  MAC_ENTRY_ADDR_TYPE_GLAG 2
+#define  MAC_ENTRY_ADDR_TYPE_MC_IDX   3
+
+#define TABLE_UPDATE_SLEEP_US 10
+#define TABLE_UPDATE_TIMEOUT_US 10
+
+struct sparx5_mact_entry {
+   struct list_head list;
+   unsigned char mac[ETH_ALEN];
+   u32 flags;
+#define MAC_ENT_ALIVE  BIT(0)
+#define MAC_ENT_MOVED  BIT(1)
+#define MAC_ENT_LOCK   BIT(1)
+   u16 vid;
+   u16 port;
+};
+
+static inline int sparx5_mact_get_status(struct sparx5 *sparx5)
+{
+   return spx5_rd(sparx5, LRN_COMMON_ACCESS_CTRL);
+}
+
+static inline int sparx5_mact_wait_for_completion(struct sparx5 *sparx5)
+{
+   u32 val;
+
+   return readx_poll_timeout(sparx5_mact_get_status,
+   sparx5, val,
+   LRN_COMMON_ACCESS_CTRL_MAC_TABLE_ACCESS_SHOT_GET(val) == 0,
+   TABLE_UPDATE_SLEEP_US, TABLE_UPDATE_TIMEOUT_US);
+}
+
+static void sparx5_mact_select(struct sparx5 *sparx5,
+  const unsigned char mac[ETH_ALEN],
+  u16 vid)
+{
+   u32 macl = 0, mach = 0;
+
+   /* Set the MAC address to handle and the vlan associated in a format
+* understood by the hardware.
+*/
+   mach |= vid<< 16;
+   mach |= mac[0] << 8;
+   mach |= mac[1] << 0;
+   macl |= mac[2] << 24;
+   macl |= mac[3] << 16;
+   macl |= mac[4] << 8;
+   macl |= mac[5] << 0;
+
+   spx5_wr(mach, sparx5, LRN_MAC_ACCESS_CFG_0);
+   spx5_wr(macl, sparx5, LRN_MAC_ACCESS_CFG_1);
+}
+
+int sparx5_mact_learn(struct sparx5 *sparx5, int pgid,
+ const unsigned char mac[ETH_ALEN], u16 vid)
+{
+   int addr, type, ret;
+
+   if (pgid < SPX5_PORTS) {
+   type = MAC_ENTRY_ADDR_TYPE_UPSID_PN;
+   addr = pgid % 32;
+   addr += (pgid / 32) << 5; /* Add upsid */
+   } else {
+   type = MAC_ENTRY_ADDR_TYPE_MC_IDX;
+   addr = pgid - SPX5_PORTS;
+   }
+
+   mutex_lock(>lock);
+
+   sparx5_mact_select(sparx5, mac, vid);
+
+   /* MAC entry properties */
+   spx5_wr(LRN_MAC_ACCESS_CFG_2_MAC_ENTRY_ADDR_SET(addr) |
+   LRN_MAC_ACCESS_CFG_2_MAC_ENTRY_ADDR_TYPE_SET(type) |
+   

[RFC PATCH v2 7/8] net: sparx5: add ethtool configuration and statistics support

[Steen Hegelund]

This adds statistic counters for the network interfaces provided
by the driver.  It also adds CPU port counters (which are not
exposed by ethtool).
This also adds support for configuring the network interface
parameters via ethtool: speed, duplex, aneg etc.

Signed-off-by: Steen Hegelund 
Signed-off-by: Bjarni Jonasson 
Signed-off-by: Lars Povlsen 
---
 .../net/ethernet/microchip/sparx5/Makefile|   3 +-
 .../microchip/sparx5/sparx5_ethtool.c | 979 ++
 .../ethernet/microchip/sparx5/sparx5_main.c   |   5 +
 .../ethernet/microchip/sparx5/sparx5_main.h   |  17 +-
 .../ethernet/microchip/sparx5/sparx5_netdev.c |   2 +
 5 files changed, 1001 insertions(+), 5 deletions(-)
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_ethtool.c

diff --git a/drivers/net/ethernet/microchip/sparx5/Makefile 
b/drivers/net/ethernet/microchip/sparx5/Makefile
index 17654ab90ce1..de3155cd582c 100644
--- a/drivers/net/ethernet/microchip/sparx5/Makefile
+++ b/drivers/net/ethernet/microchip/sparx5/Makefile
@@ -7,4 +7,5 @@ obj-$(CONFIG_SPARX5_SWITCH) += sparx5-switch.o
 
 sparx5-switch-objs  := sparx5_main.o sparx5_switchdev.o \
  sparx5_vlan.o sparx5_mactable.o sparx5_packet.o \
- sparx5_netdev.o sparx5_port.o sparx5_phylink.o sparx5_calendar.o
+ sparx5_ethtool.o sparx5_netdev.o sparx5_port.o \
+ sparx5_phylink.o sparx5_calendar.o
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_ethtool.c 
b/drivers/net/ethernet/microchip/sparx5/sparx5_ethtool.c
new file mode 100644
index ..f72f2126fea2
--- /dev/null
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_ethtool.c
@@ -0,0 +1,979 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Microchip Sparx5 Switch driver
+ *
+ * Copyright (c) 2020 Microchip Technology Inc. and its subsidiaries.
+ */
+
+#include 
+
+#include "sparx5_main.h"
+#include "sparx5_port.h"
+
+/* Add a potentially wrapping 32 bit value to a 64 bit counter */
+static void sparx5_update_counter(u64 *cnt, u32 val)
+{
+   if (val < (*cnt & U32_MAX))
+   *cnt += (u64)1 << 32; /* value has wrapped */
+
+   *cnt = (*cnt & ~(u64)U32_MAX) + val;
+}
+
+/* Get a set of Queue System statistics */
+static void sparx5_xqs_prio_stats(struct sparx5 *sparx5,
+ u32 addr,
+ u64 *stats)
+{
+   int idx;
+
+   for (idx = 0; idx < 2 * SPX5_PRIOS; ++idx, ++addr, ++stats)
+   sparx5_update_counter(stats, spx5_rd(sparx5, XQS_CNT(addr)));
+}
+
+#define SPX5_STAT_GET(sname)portstats[spx5_stats_##sname]
+#define SPX5_STAT_SUM(sname)(portstats[spx5_stats_##sname] + \
+portstats[spx5_stats_pmac_##sname])
+#define SPX5_STAT_XQS_PRIOS_COUNTER_SUM(sname)\
+   (portstats[spx5_stats_green_p0_##sname] + \
+   portstats[spx5_stats_green_p1_##sname] +  \
+   portstats[spx5_stats_green_p2_##sname] +  \
+   portstats[spx5_stats_green_p3_##sname] +  \
+   portstats[spx5_stats_green_p4_##sname] +  \
+   portstats[spx5_stats_green_p5_##sname] +  \
+   portstats[spx5_stats_green_p6_##sname] +  \
+   portstats[spx5_stats_green_p7_##sname] +  \
+   portstats[spx5_stats_yellow_p0_##sname] + \
+   portstats[spx5_stats_yellow_p1_##sname] + \
+   portstats[spx5_stats_yellow_p2_##sname] + \
+   portstats[spx5_stats_yellow_p3_##sname] + \
+   portstats[spx5_stats_yellow_p4_##sname] + \
+   portstats[spx5_stats_yellow_p5_##sname] + \
+   portstats[spx5_stats_yellow_p6_##sname] + \
+   portstats[spx5_stats_yellow_p7_##sname])
+
+enum sparx5_stats_entry {
+   spx5_stats_rx_in_bytes,
+   spx5_stats_rx_symbol_err,
+   spx5_stats_rx_pause,
+   spx5_stats_rx_unsup_opcode,
+   spx5_stats_rx_ok_bytes,
+   spx5_stats_rx_bad_bytes,
+   spx5_stats_rx_unicast,
+   spx5_stats_rx_multicast,
+   spx5_stats_rx_broadcast,
+   spx5_stats_rx_crc_err,
+   spx5_stats_rx_undersize,
+   spx5_stats_rx_fragments,
+   spx5_stats_rx_inrangelen_err,
+   spx5_stats_rx_outofrangelen_err,
+   spx5_stats_rx_oversize,
+   spx5_stats_rx_jabbers,
+   spx5_stats_rx_size64,
+   spx5_stats_rx_size65_127,
+   spx5_stats_rx_size128_255,
+   spx5_stats_rx_size256_511,
+   spx5_stats_rx_size512_1023,
+   spx5_stats_rx_size1024_1518,
+   spx5_stats_rx_size1519_max,
+   spx5_stats_pmac_rx_symbol_err,
+   spx5_stats_pmac_rx_pause,
+   spx5_stats_pmac_rx_unsup_opcode,
+   spx5_stats_pmac_rx_ok_bytes,
+   spx5_stats_pmac_rx_bad_bytes,
+   spx5_stats_pmac_rx_unicast,
+   spx5_stats_pmac_rx_multicast,
+   spx5_stats_pmac_rx_broadcast,
+   spx5_stats_pmac_rx_crc_err,
+   spx5_stats_pmac_rx_undersize,
+   spx5_stats_pmac_rx_fragments,
+   spx5_stats_pmac_rx_inrangelen_err,
+   spx5_stats_pmac_rx_outofrangelen_err,
+   spx5_stats_pmac_rx_oversize,
+   spx5_stats_pmac_rx_jabbers,
+   

[PATCH V2 XRT Alveo 1/6] Documentation: fpga: Add a document describing XRT Alveo drivers

[Sonal Santan]

From: Sonal Santan 

Describe XRT driver architecture and provide basic overview of
Xilinx Alveo platform.

Signed-off-by: Sonal Santan 
---
 Documentation/fpga/index.rst |   1 +
 Documentation/fpga/xrt.rst   | 649 +++
 2 files changed, 650 insertions(+)
 create mode 100644 Documentation/fpga/xrt.rst

diff --git a/Documentation/fpga/index.rst b/Documentation/fpga/index.rst
index f80f95667ca2..30134357b70d 100644
--- a/Documentation/fpga/index.rst
+++ b/Documentation/fpga/index.rst
@@ -8,6 +8,7 @@ fpga
 :maxdepth: 1
 
 dfl
+xrt
 
 .. only::  subproject and html
 
diff --git a/Documentation/fpga/xrt.rst b/Documentation/fpga/xrt.rst
new file mode 100644
index ..8faf259be1c3
--- /dev/null
+++ b/Documentation/fpga/xrt.rst
@@ -0,0 +1,649 @@
+==
+XRTV2 Linux Kernel Driver Overview
+==
+
+Authors:
+
+* Sonal Santan 
+* Max Zhen 
+* Lizhi Hou 
+
+XRTV2 drivers are second generation `XRT `_
+drivers which support `Alveo 
`_
+PCIe platforms from Xilinx.
+
+XRTV2 drivers support *subsystem* style data driven platforms where driver's
+configuration and behavior is determined by meta data provided by the platform
+(in *device tree* format). Primary management physical function (MPF) driver
+is called **xmgmt**. Primary user physical function (UPF) driver is called
+**xuser** and HW subsystem drivers are packaged into a library module called
+**xrt-lib**, which is shared by **xmgmt** and **xuser** (under development).
+
+Alveo Platform Overview
+===
+
+Alveo platforms are architected as two physical FPGA partitions: *Shell* and
+*User*. The Shell provides basic infrastructure for the Alveo platform like
+PCIe connectivity, board management, Dynamic Function Exchange (DFX), sensors,
+clocking, reset, and security. User partition contains user compiled FPGA
+binary which is loaded by a process called DFX also known as partial
+reconfiguration.
+
+Physical partitions require strict HW compatibility with each other for DFX to
+work properly. Every physical partition has two interface UUIDs: *parent* UUID
+and *child* UUID. For simple single stage platforms, Shell → User forms parent
+child relationship. For complex two stage platforms, Base → Shell → User forms
+the parent child relationship chain.
+
+.. note::
+   Partition compatibility matching is key design component of Alveo platforms
+   and XRT. Partitions have child and parent relationship. A loaded partition
+   exposes child partition UUID to advertise its compatibility requirement for
+   child partition. When loading a child partition the xmgmt management driver
+   matches parent UUID of the child partition against child UUID exported by
+   the parent. Parent and child partition UUIDs are stored in the *xclbin*
+   (for user) or *xsabin* (for base and shell). Except for root UUID, VSEC,
+   hardware itself does not know about UUIDs. UUIDs are stored in xsabin and
+   xclbin.
+
+
+The physical partitions and their loading is illustrated below::
+
+   SHELL   USER
++---+  +---+
+|   |  |   |
+| VSEC UUID | CHILD PARENT |LOGIC UUID |
+|   o--->|

[RFC PATCH v2 8/8] arm64: dts: sparx5: Add the Sparx5 switch node

[Steen Hegelund]

This provides switchdev support for the Microship Sparx5 PCB134 and PCB135
reference boards.

This commit depends on the following series currently on their way
into the kernel:

- Sparx5 SerDes Driver
  Link: 
https://lore.kernel.org/r/20201211090541.157926-1-steen.hegel...@microchip.com/

- Serial GPIO Controller
  Link: 
https://lore.kernel.org/r/20201113145151.68900-1-lars.povl...@microchip.com/

Signed-off-by: Steen Hegelund 
Signed-off-by: Lars Povlsen 
---
 arch/arm64/boot/dts/microchip/sparx5.dtsi |  60 ++
 .../dts/microchip/sparx5_pcb134_board.dtsi| 424 ++--
 .../dts/microchip/sparx5_pcb135_board.dtsi| 602 +-
 3 files changed, 1026 insertions(+), 60 deletions(-)

diff --git a/arch/arm64/boot/dts/microchip/sparx5.dtsi 
b/arch/arm64/boot/dts/microchip/sparx5.dtsi
index e480238489fa..085ab5a4fa50 100644
--- a/arch/arm64/boot/dts/microchip/sparx5.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5.dtsi
@@ -267,6 +267,21 @@ emmc_pins: emmc-pins {
"GPIO_46", "GPIO_47";
function = "emmc";
};
+
+   miim1_pins: miim1-pins {
+   pins = "GPIO_56", "GPIO_57";
+   function = "miim";
+   };
+
+   miim2_pins: miim2-pins {
+   pins = "GPIO_58", "GPIO_59";
+   function = "miim";
+   };
+
+   miim3_pins: miim3-pins {
+   pins = "GPIO_52", "GPIO_53";
+   function = "miim";
+   };
};
 
sgpio0: gpio@61101036c {
@@ -379,6 +394,44 @@ tmon0: tmon@610508110 {
clocks = <_clk>;
};
 
+   mdio0: mdio@6110102b0 {
+   compatible = "mscc,ocelot-miim";
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x6 0x110102b0 0x24>;
+   };
+
+   mdio1: mdio@6110102d4 {
+   compatible = "mscc,ocelot-miim";
+   status = "disabled";
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x6 0x110102d4 0x24>;
+   };
+
+   mdio2: mdio@6110102f8 {
+   compatible = "mscc,ocelot-miim";
+   status = "disabled";
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x6 0x110102d4 0x24>;
+   };
+
+   mdio3: mdio@61101031c {
+   compatible = "mscc,ocelot-miim";
+   status = "disabled";
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x6 0x1101031c 0x24>;
+   };
+
serdes: serdes@10808000 {
compatible = "microchip,sparx5-serdes";
#phy-cells = <1>;
@@ -386,5 +439,12 @@ serdes: serdes@10808000 {
reg = <0x6 0x10808000 0x5d>;
};
 
+   switch: switch@610004000 {
+   compatible = "microchip,sparx5-switch";
+   reg =   <0x6 0x10004000 0x80>,
+   <0x6 0x1101 0x1b0>;
+   reg-names = "devices", "gcb";
+   interrupts = ;
+   };
};
 };
diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi 
b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
index 6820579448d0..efa35cbcef49 100644
--- a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
@@ -7,30 +7,6 @@
 #include "sparx5_pcb_common.dtsi"
 
 /{
-   aliases {
-   i2c0   = 
-   i2c100 = 
-   i2c101 = 
-   i2c102 = 
-   i2c103 = 
-   i2c104 = 
-   i2c105 = 
-   i2c106 = 
-   i2c107 = 
-   i2c108 = 
-   i2c109 = 
-   i2c110 = 
-   i2c111 = 
-   i2c112 = 
-   i2c113 = 
-   i2c114 = 
-   i2c115 = 
-   i2c116 = 
-   i2c117 = 
-   i2c118 = 
-   i2c119 = 
-   };
-
gpio-restart {
compatible = "gpio-restart";
gpios = < 37 GPIO_ACTIVE_LOW>;
@@ -328,6 +304,11 @@ gpio@1 {
 

[RFC PATCH v2 3/8] net: sparx5: add hostmode with phylink support

[Steen Hegelund]

This adds phylink support for ports and register base injection
and extraction.

Signed-off-by: Steen Hegelund 
Signed-off-by: Bjarni Jonasson 
Signed-off-by: Lars Povlsen 
---
 .../net/ethernet/microchip/sparx5/Makefile|   2 +-
 .../ethernet/microchip/sparx5/sparx5_main.c   |  68 +
 .../ethernet/microchip/sparx5/sparx5_main.h   |  26 ++
 .../ethernet/microchip/sparx5/sparx5_netdev.c | 203 +
 .../ethernet/microchip/sparx5/sparx5_packet.c | 273 ++
 .../microchip/sparx5/sparx5_phylink.c | 168 +++
 6 files changed, 739 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_netdev.c
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_packet.c
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_phylink.c

diff --git a/drivers/net/ethernet/microchip/sparx5/Makefile 
b/drivers/net/ethernet/microchip/sparx5/Makefile
index 41a31843d86f..19a593d17f4a 100644
--- a/drivers/net/ethernet/microchip/sparx5/Makefile
+++ b/drivers/net/ethernet/microchip/sparx5/Makefile
@@ -5,4 +5,4 @@
 
 obj-$(CONFIG_SPARX5_SWITCH) += sparx5-switch.o
 
-sparx5-switch-objs  := sparx5_main.o
+sparx5-switch-objs  := sparx5_main.o sparx5_packet.o sparx5_netdev.o 
sparx5_phylink.o
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_main.c 
b/drivers/net/ethernet/microchip/sparx5/sparx5_main.c
index 67435fa45c7f..baa108cd99b2 100644
--- a/drivers/net/ethernet/microchip/sparx5/sparx5_main.c
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_main.c
@@ -240,13 +240,20 @@ static int sparx5_probe_port(struct sparx5 *sparx5,
 u32 portno,
 struct sparx5_port_config *conf)
 {
+   phy_interface_t phy_mode = conf->phy_mode;
struct sparx5_port *spx5_port;
struct net_device *ndev;
+   struct phylink *phylink;
int err;
 
err = sparx5_create_targets(sparx5);
if (err)
return err;
+   ndev = sparx5_create_netdev(sparx5, portno);
+   if (IS_ERR(ndev)) {
+   dev_err(sparx5->dev, "Could not create net device: %02u\n", 
portno);
+   return PTR_ERR(ndev);
+   }
spx5_port = netdev_priv(ndev);
spx5_port->of_node = portnp;
spx5_port->serdes = serdes;
@@ -262,6 +269,24 @@ static int sparx5_probe_port(struct sparx5 *sparx5,
spx5_port->conf.speed = SPEED_UNKNOWN;
spx5_port->conf.power_down = true;
sparx5->ports[portno] = spx5_port;
+   /* Create a phylink for PHY management.  Also handles SFPs */
+   spx5_port->phylink_config.dev = _port->ndev->dev;
+   spx5_port->phylink_config.type = PHYLINK_NETDEV;
+   spx5_port->phylink_config.pcs_poll = true;
+
+   /* phylink needs a valid interface mode to parse dt node */
+   if (phy_mode == PHY_INTERFACE_MODE_NA)
+   phy_mode = PHY_INTERFACE_MODE_10GBASER;
+
+   phylink = phylink_create(_port->phylink_config,
+of_fwnode_handle(portnp),
+phy_mode,
+_phylink_mac_ops);
+   if (IS_ERR(phylink))
+   return PTR_ERR(phylink);
+
+   spx5_port->phylink = phylink;
+
return 0;
 }
 
@@ -336,6 +361,9 @@ static int sparx5_init_switchcore(struct sparx5 *sparx5)
spx5_wr(ANA_AC_STAT_RESET_RESET_SET(1), sparx5, ANA_AC_STAT_RESET);
spx5_wr(ASM_STAT_CFG_STAT_CNT_CLR_SHOT_SET(1), sparx5, ASM_STAT_CFG);
 
+   /* Configure manual injection */
+   sparx5_manual_injection_mode(sparx5);
+
/* Enable switch-core and queue system */
spx5_wr(HSCH_RESET_CFG_CORE_ENA_SET(1), sparx5, HSCH_RESET_CFG);
 
@@ -495,11 +523,22 @@ static int sparx5_qlim_set(struct sparx5 *sparx5)
 
 static int sparx5_init(struct sparx5 *sparx5)
 {
+   int irq, ret;
u32 idx;
 
if (sparx5_create_targets(sparx5))
return -ENODEV;
 
+   /* Hook xtr irq */
+   irq = platform_get_irq(sparx5->pdev, 0);
+   if (irq < 0)
+   return irq;
+   ret = devm_request_irq(sparx5->dev, irq,
+  sparx5_xtr_handler, IRQF_SHARED,
+  "sparx5-xtr", sparx5);
+   if (ret)
+   return ret;
+
/* Read chip ID to check CPU interface */
sparx5->chip_id = spx5_rd(sparx5, GCB_CHIP_ID);
 
@@ -580,6 +619,18 @@ static void sparx5_board_init(struct sparx5 *sparx5)
}
 }
 
+static void sparx5_cleanup_ports(struct sparx5 *sparx5)
+{
+   int idx;
+
+   for (idx = 0; idx < SPX5_PORTS; ++idx) {
+   struct sparx5_port *port = sparx5->ports[idx];
+
+   if (port && port->ndev)
+   sparx5_destroy_netdev(sparx5, port);
+   }
+}
+
 static int mchp_sparx5_probe(struct platform_device *pdev)
 {
struct device_node *np = pdev->dev.of_node;
@@ -666,12 +717,28 @@ static int mchp_sparx5_probe(struct 

[RFC PATCH v2 6/8] net: sparx5: add calendar bandwidth allocation support

[Steen Hegelund]

This configures the Sparx5 calendars according to the bandwidth
requested in the Device Tree nodes.
It also checks if the total requested bandwidth is within the
specs of the detected Sparx5 models limits.

Signed-off-by: Steen Hegelund 
Signed-off-by: Bjarni Jonasson 
Signed-off-by: Lars Povlsen 
---
 .../net/ethernet/microchip/sparx5/Makefile|   2 +-
 .../microchip/sparx5/sparx5_calendar.c| 595 ++
 .../ethernet/microchip/sparx5/sparx5_main.c   |   8 +
 .../ethernet/microchip/sparx5/sparx5_main.h   |   4 +
 4 files changed, 608 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/ethernet/microchip/sparx5/sparx5_calendar.c

diff --git a/drivers/net/ethernet/microchip/sparx5/Makefile 
b/drivers/net/ethernet/microchip/sparx5/Makefile
index 32e0691e328a..17654ab90ce1 100644
--- a/drivers/net/ethernet/microchip/sparx5/Makefile
+++ b/drivers/net/ethernet/microchip/sparx5/Makefile
@@ -7,4 +7,4 @@ obj-$(CONFIG_SPARX5_SWITCH) += sparx5-switch.o
 
 sparx5-switch-objs  := sparx5_main.o sparx5_switchdev.o \
  sparx5_vlan.o sparx5_mactable.o sparx5_packet.o \
- sparx5_netdev.o sparx5_port.o sparx5_phylink.o
+ sparx5_netdev.o sparx5_port.o sparx5_phylink.o sparx5_calendar.o
diff --git a/drivers/net/ethernet/microchip/sparx5/sparx5_calendar.c 
b/drivers/net/ethernet/microchip/sparx5/sparx5_calendar.c
new file mode 100644
index ..932c897c72a7
--- /dev/null
+++ b/drivers/net/ethernet/microchip/sparx5/sparx5_calendar.c
@@ -0,0 +1,595 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Microchip Sparx5 Switch driver
+ *
+ * Copyright (c) 2020 Microchip Technology Inc. and its subsidiaries.
+ */
+
+#include 
+#include 
+
+#include "sparx5_main.h"
+
+/* QSYS calendar information */
+#define SPX5_PORTS_PER_CALREG  10  /* Ports mapped in a calendar 
register */
+#define SPX5_CALBITS_PER_PORT  3   /* Bit per port in calendar 
register */
+
+/* DSM calendar information */
+#define SPX5_DSM_CAL_LEN   64
+#define SPX5_DSM_CAL_EMPTY 0x
+#define SPX5_DSM_CAL_MAX_DEVS_PER_TAXI 13
+#define SPX5_DSM_CAL_TAXIS 8
+#define SPX5_DSM_CAL_BW_LOSS   553
+
+#define SPX5_TAXI_PORT_MAX 70
+
+#define SPEED_1250012500
+
+/* Maps from taxis to port numbers */
+static u32 
sparx5_taxi_ports[SPX5_DSM_CAL_TAXIS][SPX5_DSM_CAL_MAX_DEVS_PER_TAXI] = {
+   {57, 12, 0, 1, 2, 16, 17, 18, 19, 20, 21, 22, 23},
+   {58, 13, 3, 4, 5, 24, 25, 26, 27, 28, 29, 30, 31},
+   {59, 14, 6, 7, 8, 32, 33, 34, 35, 36, 37, 38, 39},
+   {60, 15, 9, 10, 11, 40, 41, 42, 43, 44, 45, 46, 47},
+   {61, 48, 49, 50, 99, 99, 99, 99, 99, 99, 99, 99, 99},
+   {62, 51, 52, 53, 99, 99, 99, 99, 99, 99, 99, 99, 99},
+   {56, 63, 54, 55, 99, 99, 99, 99, 99, 99, 99, 99, 99},
+   {64, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99},
+};
+
+struct sparx5_calendar_data {
+   u32 schedule[SPX5_DSM_CAL_LEN];
+   u32 avg_dist[SPX5_DSM_CAL_MAX_DEVS_PER_TAXI];
+   u32 taxi_ports[SPX5_DSM_CAL_MAX_DEVS_PER_TAXI];
+   u32 taxi_speeds[SPX5_DSM_CAL_MAX_DEVS_PER_TAXI];
+   u32 dev_slots[SPX5_DSM_CAL_MAX_DEVS_PER_TAXI];
+   u32 new_slots[SPX5_DSM_CAL_LEN];
+   u32 temp_sched[SPX5_DSM_CAL_LEN];
+   u32 indices[SPX5_DSM_CAL_LEN];
+   u32 short_list[SPX5_DSM_CAL_LEN];
+   u32 long_list[SPX5_DSM_CAL_LEN];
+};
+
+static u32 sparx5_target_bandwidth(struct sparx5 *sparx5)
+{
+   switch (sparx5->target_ct) {
+   case SPX5_TARGET_CT_7546:
+   case SPX5_TARGET_CT_7546TSN:
+   return 65000;
+   case SPX5_TARGET_CT_7549:
+   case SPX5_TARGET_CT_7549TSN:
+   return 91000;
+   case SPX5_TARGET_CT_7552:
+   case SPX5_TARGET_CT_7552TSN:
+   return 129000;
+   case SPX5_TARGET_CT_7556:
+   case SPX5_TARGET_CT_7556TSN:
+   return 161000;
+   case SPX5_TARGET_CT_7558:
+   case SPX5_TARGET_CT_7558TSN:
+   return 201000;
+   default:
+   return 0;
+   }
+}
+
+/* This is used in calendar configuration */
+enum sparx5_cal_bw {
+   SPX5_CAL_SPEED_NONE = 0,
+   SPX5_CAL_SPEED_1G   = 1,
+   SPX5_CAL_SPEED_2G5  = 2,
+   SPX5_CAL_SPEED_5G   = 3,
+   SPX5_CAL_SPEED_10G  = 4,
+   SPX5_CAL_SPEED_25G  = 5,
+   SPX5_CAL_SPEED_0G5  = 6,
+   SPX5_CAL_SPEED_12G5 = 7
+};
+
+static u32 sparx5_clk_to_bandwidth(enum sparx5_core_clockfreq cclock)
+{
+   switch (cclock) {
+   case SPX5_CORE_CLOCK_250MHZ: return 83000; /* 25 / 3 */
+   case SPX5_CORE_CLOCK_500MHZ: return 166000; /* 50 / 3 */
+   case SPX5_CORE_CLOCK_625MHZ: return  208000; /* 625000 / 3 */
+   default: return 0;
+   }
+   return 0;
+}
+
+static u32 sparx5_cal_speed_to_value(enum sparx5_cal_bw speed)
+{
+   switch (speed) {
+   case SPX5_CAL_SPEED_1G:   return 1000;
+   case SPX5_CAL_SPEED_2G5:  return 2500;
+   case SPX5_CAL_SPEED_5G:   return 5000;
+   case 

[PATCH V2 XRT Alveo 0/6] XRT Alveo driver overview

[Sonal Santan]

Hello,

This is V2 of patch series which adds management physical function driver
for Xilinx Alveo PCIe accelerator cards,
https://www.xilinx.com/products/boards-and-kits/alveo.html
This driver is part of Xilinx Runtime (XRT) open source stack.

The patch series depends on libfdt patches which were posted before:
https://lore.kernel.org/lkml/20201128235659.24679-1-son...@xilinx.com/
https://lore.kernel.org/lkml/20201128235659.24679-2-son...@xilinx.com/

ALVEO PLATFORM ARCHITECTURE

Alveo PCIe FPGA based platforms have a static *shell* partition and a partial
re-configurable *user* partition. The shell partition is automatically loaded 
from
flash when host is booted and PCIe is enumerated by BIOS. Shell cannot be 
changed
till the next cold reboot. The shell exposes two PCIe physical functions:

1. management physical function
2. user physical function

The patch series includes Documentation/xrt.rst which describes Alveo
platform, XRT driver architecture and deployment model in more detail.

Users compile their high level design in C/C++/OpenCL or RTL into FPGA image
using Vitis 
https://www.xilinx.com/products/design-tools/vitis/vitis-platform.html
tools. The compiled image is packaged as xclbin and contains partial bitstream
for the user partition and necessary metadata. Users can dynamically swap the
image running on the user partition in order to switch between different 
workloads.

XRT DRIVERS FOR ALVEO

XRT Linux kernel driver *xmgmt* binds to management physical function of
Alveo platform. The modular driver framework is organized into several
platform drivers which primarily handle the following functionality:

1.  Loading firmware container also called xsabin at driver attach time
2.  Loading of user compiled xclbin with FPGA Manager integration
3.  Clock scaling of image running on user partition
4.  In-band sensors: temp, voltage, power, etc.
5.  Device reset and rescan
6.  Flash upgrade of static *shell* partition

The platform drivers are packaged into *xrt-lib* helper module with a well
defined interfaces the details of which can be found in Documentation/xrt.rst.

User physical function driver is not included in this patch series.

TESTING AND VALIDATION

xmgmt driver can be tested with full XRT open source stack which includes
user space libraries, board utilities and (out of tree) first generation
user physical function driver xocl. XRT open source runtime stack is
available at https://github.com/Xilinx/XRT

Complete documentation for XRT open source stack including sections on
Alveo/XRT security and platform architecture can be found here:
https://xilinx.github.io/XRT/master/html/index.html
https://xilinx.github.io/XRT/master/html/security.html
https://xilinx.github.io/XRT/master/html/platforms_partitions.html

Changes since v1:
- Updated the driver to use fpga_region and fpga_bridge for FPGA
  programming
- Dropped subdev drivers not related to PR programming to focus on XRT
  core framework
- Updated Documentation/fpga/xrt.rst with information on XRT core framework
- Addressed checkpatch issues 
- Dropped xrt- prefix from some header files

For reference V1 version of patch series can be found here--
https://lore.kernel.org/lkml/2020112940.24777-1-son...@xilinx.com/
https://lore.kernel.org/lkml/2020112940.24777-2-son...@xilinx.com/
https://lore.kernel.org/lkml/2020112940.24777-3-son...@xilinx.com/
https://lore.kernel.org/lkml/2020112940.24777-4-son...@xilinx.com/
https://lore.kernel.org/lkml/2020112940.24777-5-son...@xilinx.com/
https://lore.kernel.org/lkml/2020112940.24777-6-son...@xilinx.com/
https://lore.kernel.org/lkml/2020112940.24777-7-son...@xilinx.com/
https://lore.kernel.org/lkml/2020112940.24777-8-son...@xilinx.com/
https://lore.kernel.org/lkml/2020112940.24777-9-son...@xilinx.com/

Thanks,
-Sonal

Sonal Santan (6):
  Documentation: fpga: Add a document describing XRT Alveo drivers
  fpga: xrt: infrastructure support for xmgmt driver
  fpga: xrt: core infrastructure for xrt-lib module
  fpga: xrt: XRT Alveo management physical function driver
  fpga: xrt: platform drivers for subsystems in shell partition
  fpga: xrt: Kconfig and Makefile updates for XRT drivers

 Documentation/fpga/index.rst |1 +
 Documentation/fpga/xrt.rst   |  649 +++
 drivers/fpga/Kconfig |2 +
 drivers/fpga/Makefile|4 +
 drivers/fpga/xrt/Kconfig |7 +
 drivers/fpga/xrt/Makefile|   21 +
 drivers/fpga/xrt/common/xrt-metadata.c   |  590 ++
 drivers/fpga/xrt/common/xrt-root.c   |  737 +
 drivers/fpga/xrt/common/xrt-root.h   |   26 +
 drivers/fpga/xrt/common/xrt-xclbin.c |  387 +++
 drivers/fpga/xrt/common/xrt-xclbin.h |   48 +
 drivers/fpga/xrt/include/metadata.h  |  184 
 drivers/fpga/xrt/include/parent.h|  103 ++
 

[RFC PATCH v2 1/8] dt-bindings: net: sparx5: Add sparx5-switch bindings

[Steen Hegelund]

Document the Sparx5 switch device driver bindings

Signed-off-by: Steen Hegelund 
Signed-off-by: Lars Povlsen 
---
 .../bindings/net/microchip,sparx5-switch.yaml | 178 ++
 1 file changed, 178 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml

diff --git a/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml 
b/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml
new file mode 100644
index ..6e3ef8285e9a
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml
@@ -0,0 +1,178 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/microchip,sparx5-switch.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip Sparx5 Ethernet switch controller
+
+maintainers:
+  - Lars Povlsen 
+  - Steen Hegelund 
+
+description: |
+  The SparX-5 Enterprise Ethernet switch family provides a rich set of
+  Enterprise switching features such as advanced TCAM-based VLAN and
+  QoS processing enabling delivery of differentiated services, and
+  security through TCAM-based frame processing using versatile content
+  aware processor (VCAP).
+
+  IPv4/IPv6 Layer 3 (L3) unicast and multicast routing is supported
+  with up to 18K IPv4/9K IPv6 unicast LPM entries and up to 9K IPv4/3K
+  IPv6 (S,G) multicast groups.
+
+  L3 security features include source guard and reverse path
+  forwarding (uRPF) tasks. Additional L3 features include VRF-Lite and
+  IP tunnels (IP over GRE/IP).
+
+  The SparX-5 switch family targets managed Layer 2 and Layer 3
+  equipment in SMB, SME, and Enterprise where high port count
+  1G/2.5G/5G/10G switching with 10G/25G aggregation links is required.
+
+properties:
+  $nodename:
+pattern: "^switch@[0-9a-f]+$"
+
+  compatible:
+const: microchip,sparx5-switch
+
+  reg:
+minItems: 2
+
+  reg-names:
+minItems: 2
+items:
+  - const: devices
+  - const: gcb
+
+  interrupts:
+maxItems: 1
+description: Interrupt used for reception of packets to the CPU
+
+  ethernet-ports:
+type: object
+properties:
+  '#address-cells':
+const: 1
+  '#size-cells':
+const: 0
+
+patternProperties:
+  "^port@[0-9]+$":
+type: object
+description: Switch ports
+
+allOf:
+  - $ref: ethernet-controller.yaml#
+
+properties:
+  reg:
+description: Switch port number
+
+  max-speed:
+maxItems: 1
+description: Bandwidth allocated to this port
+
+  phys:
+description: phandle of a Ethernet Serdes PHY
+
+  phy-handle:
+description: phandle of a Ethernet PHY
+
+  phy-mode:
+description: Interface between the serdes and the phy
+
+  sfp:
+description: phandle of an SFP
+
+  managed:
+maxItems: 1
+description: SFP management
+
+required:
+  - reg
+  - max-speed
+  - phys
+
+oneOf:
+  - required:
+  - phy-handle
+  - phy-mode
+  - required:
+  - sfp
+  - managed
+
+additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - interrupts
+  - ethernet-ports
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+switch: switch@6 {
+  compatible = "microchip,sparx5-switch";
+  reg =  <0x1000 0x80>,
+ <0x1101 0x1b0>;
+  reg-names = "devices", "gcb";
+
+  interrupts = ;
+  ethernet-ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port0: port@0 {
+  reg = <0>;
+  max-speed = <1000>;
+  phys = < 13>;
+  phy-handle = <>;
+  phy-mode = "qsgmii";
+};
+/* ... */
+/* Then the 25G interfaces */
+port60: port@60 {
+  reg = <60>;
+  max-speed = <25000>;
+  phys = < 29>;
+  sfp = <_eth60>;
+  managed = "in-band-status";
+};
+port61: port@61 {
+  reg = <61>;
+  max-speed = <25000>;
+  phys = < 30>;
+  sfp = <_eth61>;
+  managed = "in-band-status";
+};
+port62: port@62 {
+  reg = <62>;
+  max-speed = <25000>;
+  phys = < 31>;
+  sfp = <_eth62>;
+  managed = "in-band-status";
+};
+port63: port@63 {
+  reg = <63>;
+  max-speed = <25000>;
+  phys = < 32>;
+  sfp = <_eth63>;
+  managed = "in-band-status";
+};
+/* Finally the Management interface */
+port64: port@64 {
+  reg = <64>;
+  max-speed = <1000>;
+  phys = < 0>;
+  phy-handle = <>;
+  phy-mode = "sgmii";
+};
+  };
+};
+
+...
-- 

[RFC PATCH v2 0/8] Adding the Sparx5 Switch Driver

[Steen Hegelund]

This series provides the Microchip Sparx5 Switch Driver

The Sparx5 Carrier Ethernet and Industrial switch family delivers 64
Ethernet ports and up to 200 Gbps of switching bandwidth.

It provides a rich set of Ethernet switching features such as hierarchical
QoS, hardware-based OAM  and service activation testing, protection
switching, IEEE 1588, and Synchronous Ethernet.

Using provider bridging (Q-in-Q) and MPLS/MPLS-TP technology, it delivers
MEF CE
2.0 Ethernet virtual connections (EVCs) and features advanced TCAM
  classification in both ingress and egress.

Per-EVC features include advanced L3-aware classification, a rich set of
statistics, OAM for end-to-end performance monitoring, and dual-rate
policing and shaping.

Time sensitive networking (TSN) is supported through a comprehensive set of
features including frame preemption, cut-through, frame replication and
elimination for reliability, enhanced scheduling: credit-based shaping,
time-aware shaping, cyclic queuing, and forwarding, and per-stream policing
and filtering.

Together with IEEE 1588 and IEEE 802.1AS support, this guarantees
low-latency deterministic networking for Fronthaul, Carrier, and Industrial
Ethernet.

The Sparx5 switch family consists of following SKUs:

- VSC7546 Sparx5-64 up to 64 Gbps of bandwidth with the following primary
  port configurations:
  - 6 *10G
  - 16 * 2.5G + 2 * 10G
  - 24 * 1G + 4 * 10G

- VSC7549 Sparx5-90 up to 90 Gbps of bandwidth with the following primary
  port configurations:
  - 9 * 10G
  - 16 * 2.5G + 4 * 10G
  - 48 * 1G + 4 * 10G

- VSC7552 Sparx5-128 up to 128 Gbps of bandwidth with the following primary
  port configurations:
  - 12 * 10G
  - 16 * 2.5G + 8 * 10G
  - 48 * 1G + 8 * 10G

- VSC7556 Sparx5-160 up to 160 Gbps of bandwidth with the following primary
  port configurations:
  - 16 * 10G
  - 10 * 10G + 2 * 25G
  - 16 * 2.5G + 10 * 10G
  - 48 * 1G + 10 * 10G

- VSC7558 Sparx5-200 up to 200 Gbps of bandwidth with the following primary
  port configurations:
  - 20 * 10G
  - 8 * 25G

In addition, the device supports one 10/100/1000/2500/5000 Mbps
SGMII/SerDes node processor interface (NPI) Ethernet port.

The Sparx5 support is developed on the PCB134 and PCB135 evaluation boards.

- PCB134 main networking features:
  - 12x SFP+ front 10G module slots (connected to Sparx5 through SFI).
  - 8x SFP28 front 25G module slots (connected to Sparx5 through SFI high
speed).
  - Optional, one additional 10/100/1000BASE-T (RJ45) Ethernet port
(on-board VSC8211 PHY connected to Sparx5 through SGMII).

- PCB135 main networking features:
  - 48x1G (10/100/1000M) RJ45 front ports using 12xVSC8514 QuadPHY’s each
connected to VSC7558 through QSGMII.
  - 4x10G (1G/2.5G/5G/10G) RJ45 front ports using the AQR407 10G QuadPHY
each port connects to VSC7558 through SFI.
  - 4x SFP28 25G module slots on back connected to VSC7558 through SFI high
speed.
  - Optional, one additional 1G (10/100/1000M) RJ45 port using an on-board
VSC8211 PHY, which can be connected to VSC7558 NPI port through SGMII
using a loopback add-on PCB)

This series provides support for:
  - SFPs and DAC cables via PHYLINK with a number of 5G, 10G and 25G
devices and media types.
  - Port module configuration for 10M to 25G speeds with SGMII, QSGMII,
1000BASEX, 2500BASEX and 10GBASER as appropriate for these modes.
  - SerDes configuration via the Sparx5 SerDes driver (see below).
  - Host mode providing register based injection and extraction.
  - Switch mode providing MAC/VLAN table learning and Layer2 switching
offloaded to the Sparx5 switch.
  - STP state, VLAN support, host/bridge port mode, Forwarding DB, and
configuration and statistics via ethtool.

More support will be added at a later stage.

The Sparx5 Switch chip register model can be browsed here:
Link: https://microchip-ung.github.io/sparx-5_reginfo/reginfo_sparx-5.html

The series depends on the following series currently on their way
into the kernel:

- Sparx5 SerDes Driver
  Link: 
https://lore.kernel.org/r/20201211090541.157926-1-steen.hegel...@microchip.com/

- Serial GPIO Controller
  Link: 
https://lore.kernel.org/r/20201113145151.68900-1-lars.povl...@microchip.com/

ChangeLog:
v2:
- The driver patch has been split into 6 patches by functionality
  like this:
- the basic sparx5 driver
- hostmode with phylink support
- port module support
- switching, vlan and mactable support
- calendar bandwidth allocation support
- ethtool configuration and statistics support
- IO ranges have been collapsed into just 2 (the SerDes
  driver uses the area inbetween) and the driver uses an
  offset table to get the target instances.
- register macros have been converted to functions
- register_netdev() moved to the end of the switch initialization.
- sparx5_update_port_stats: use reverse christmas tree
- 

[PATCH] RISC-V: Fix usage of memblock_enforce_memory_limit

[Atish Patra]

memblock_enforce_memory_limit accepts the maximum memory size not the last
address. Fix the function invocation correctly.

Fixes: 1bd14a66ee52 ("RISC-V: Remove any memblock representing unusable memory 
area")

Signed-off-by: Atish Patra 
---
 arch/riscv/mm/init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index 8e577f14f120..e4133c20744c 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -174,7 +174,7 @@ void __init setup_bootmem(void)
 * Make sure that any memory beyond mem_start + (-PAGE_OFFSET) is 
removed
 * as it is unusable by kernel.
 */
-   memblock_enforce_memory_limit(mem_start - PAGE_OFFSET);
+   memblock_enforce_memory_limit(-PAGE_OFFSET);
 
/* Reserve from the start of the kernel to the end of the kernel */
memblock_reserve(vmlinux_start, vmlinux_end - vmlinux_start);
-- 
2.25.1

Re: memory leak in xskq_create

[Peilin Ye]

Hi Björn,

On Thu, Dec 17, 2020 at 08:12:26AM +0100, Björn Töpel wrote:
> On 2020-12-16 19:11, Peilin Ye wrote:
> > I have tested the following diff locally against syzbot's reproducer,
> > and sent a patch to it [1] for testing.  I will send a real patch here
> > tomorrow if syzbot is happy about it.  Please see explanation below.
> 
> Hi Peilin Ye!
> 
> Thanks for taking a look! Magnus has already addressed this problem in
> another patch [1].

No problem!  Oops, I searched for "cfa88ddd0655afa88763" on LKML and
didn't notice Magnus's patch.  I should have searched netdev too.

Thanks,
Peilin Ye

[PATCH 2/4] sched/fair: Make CFS bandwidth controller burstable

[Huaixin Chang]

Accumulate unused quota from previous periods, thus accumulated
bandwidth runtime can be used in the following periods. During
accumulation, take care of runtime overflow. Previous non-burstable
CFS bandwidth controller only assign quota to runtime, that saves a lot.

A sysctl parameter sysctl_sched_cfs_bw_burst_onset_percent is introduced to
denote how many percent of burst is given on setting cfs bandwidth. By
default it is 0, which means on burst is allowed unless accumulated.

Also, parameter sysctl_sched_cfs_bw_burst_enabled is introduced as a
switch for burst. It is enabled by default.

Signed-off-by: Huaixin Chang 
Signed-off-by: Shanpei Chen 
---
 include/linux/sched/sysctl.h |  2 ++
 kernel/sched/core.c  | 31 +
 kernel/sched/fair.c  | 46 
 kernel/sched/sched.h |  4 ++--
 kernel/sysctl.c  | 18 +
 5 files changed, 87 insertions(+), 14 deletions(-)

diff --git a/include/linux/sched/sysctl.h b/include/linux/sched/sysctl.h
index 3c31ba88aca5..3400828eaf2d 100644
--- a/include/linux/sched/sysctl.h
+++ b/include/linux/sched/sysctl.h
@@ -72,6 +72,8 @@ extern unsigned int sysctl_sched_uclamp_util_min_rt_default;
 
 #ifdef CONFIG_CFS_BANDWIDTH
 extern unsigned int sysctl_sched_cfs_bandwidth_slice;
+extern unsigned int sysctl_sched_cfs_bw_burst_onset_percent;
+extern unsigned int sysctl_sched_cfs_bw_burst_enabled;
 #endif
 
 #ifdef CONFIG_SCHED_AUTOGROUP
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 48d3bad12be2..71cced83df2f 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -66,6 +66,16 @@ const_debug unsigned int sysctl_sched_features =
  */
 const_debug unsigned int sysctl_sched_nr_migrate = 32;
 
+#ifdef CONFIG_CFS_BANDWIDTH
+/*
+ * Percent of burst assigned to cfs_b->runtime on tg_set_cfs_bandwidth,
+ * 0 by default.
+ */
+unsigned int sysctl_sched_cfs_bw_burst_onset_percent;
+
+unsigned int sysctl_sched_cfs_bw_burst_enabled = 1;
+#endif
+
 /*
  * period over which we measure -rt task CPU usage in us.
  * default: 1s
@@ -7891,7 +7901,7 @@ static DEFINE_MUTEX(cfs_constraints_mutex);
 const u64 max_cfs_quota_period = 1 * NSEC_PER_SEC; /* 1s */
 static const u64 min_cfs_quota_period = 1 * NSEC_PER_MSEC; /* 1ms */
 /* More than 203 days if BW_SHIFT equals 20. */
-static const u64 max_cfs_runtime = MAX_BW * NSEC_PER_USEC;
+const u64 max_cfs_runtime = MAX_BW * NSEC_PER_USEC;
 
 static int __cfs_schedulable(struct task_group *tg, u64 period, u64 runtime);
 
@@ -7900,7 +7910,7 @@ static int tg_set_cfs_bandwidth(struct task_group *tg, 
u64 period, u64 quota,
 {
int i, ret = 0, runtime_enabled, runtime_was_enabled;
struct cfs_bandwidth *cfs_b = >cfs_bandwidth;
-   u64 buffer;
+   u64 buffer, burst_onset;
 
if (tg == _task_group)
return -EINVAL;
@@ -7961,11 +7971,24 @@ static int tg_set_cfs_bandwidth(struct task_group *tg, 
u64 period, u64 quota,
cfs_b->burst = burst;
cfs_b->buffer = buffer;
 
-   __refill_cfs_bandwidth_runtime(cfs_b);
+   cfs_b->max_overrun = DIV_ROUND_UP_ULL(max_cfs_runtime, quota);
+   cfs_b->runtime = cfs_b->quota;
+
+   /* burst_onset needed */
+   if (cfs_b->quota != RUNTIME_INF &&
+   sysctl_sched_cfs_bw_burst_enabled &&
+   sysctl_sched_cfs_bw_burst_onset_percent > 0) {
+
+   burst_onset = burst / 100 *
+   sysctl_sched_cfs_bw_burst_onset_percent;
+
+   cfs_b->runtime += burst_onset;
+   cfs_b->runtime = min(max_cfs_runtime, cfs_b->runtime);
+   }
 
/* Restart the period timer (if active) to handle new period expiry: */
if (runtime_enabled)
-   start_cfs_bandwidth(cfs_b);
+   start_cfs_bandwidth(cfs_b, 1);
 
raw_spin_unlock_irq(_b->lock);
 
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 6bb4f89259fd..38a726f77783 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4598,10 +4598,22 @@ static inline u64 sched_cfs_bandwidth_slice(void)
  *
  * requires cfs_b->lock
  */
-void __refill_cfs_bandwidth_runtime(struct cfs_bandwidth *cfs_b)
+void __refill_cfs_bandwidth_runtime(struct cfs_bandwidth *cfs_b, u64 overrun)
 {
-   if (cfs_b->quota != RUNTIME_INF)
-   cfs_b->runtime = cfs_b->quota;
+   u64 refill;
+
+   if (cfs_b->quota != RUNTIME_INF) {
+
+   if (!sysctl_sched_cfs_bw_burst_enabled) {
+   cfs_b->runtime = cfs_b->quota;
+   return;
+   }
+
+   overrun = min(overrun, cfs_b->max_overrun);
+   refill = cfs_b->quota * overrun;
+   cfs_b->runtime += refill;
+   cfs_b->runtime = min(cfs_b->runtime, cfs_b->buffer);
+   }
 }
 
 static inline struct cfs_bandwidth *tg_cfs_bandwidth(struct task_group *tg)
@@ -4623,7 +4635,7 @@ static int 

[PATCH 1/4] sched/fair: Introduce primitives for CFS bandwidth burst

[Huaixin Chang]

In this patch, we introduce the notion of CFS bandwidth burst. Unused
"quota" from pervious "periods" might be accumulated and used in the
following "periods". The maximum amount of accumulated bandwidth is
bounded by "burst". And the maximun amount of CPU a group can consume in
a given period is "buffer" which is equivalent to "quota" + "burst in
case that this group has done enough accumulation.

Signed-off-by: Huaixin Chang 
Signed-off-by: Shanpei Chen 
---
 kernel/sched/core.c  | 91 
 kernel/sched/fair.c  |  2 ++
 kernel/sched/sched.h |  2 ++
 3 files changed, 82 insertions(+), 13 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index e7e453492cff..48d3bad12be2 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7895,10 +7895,12 @@ static const u64 max_cfs_runtime = MAX_BW * 
NSEC_PER_USEC;
 
 static int __cfs_schedulable(struct task_group *tg, u64 period, u64 runtime);
 
-static int tg_set_cfs_bandwidth(struct task_group *tg, u64 period, u64 quota)
+static int tg_set_cfs_bandwidth(struct task_group *tg, u64 period, u64 quota,
+   u64 burst)
 {
int i, ret = 0, runtime_enabled, runtime_was_enabled;
struct cfs_bandwidth *cfs_b = >cfs_bandwidth;
+   u64 buffer;
 
if (tg == _task_group)
return -EINVAL;
@@ -7925,6 +7927,16 @@ static int tg_set_cfs_bandwidth(struct task_group *tg, 
u64 period, u64 quota)
if (quota != RUNTIME_INF && quota > max_cfs_runtime)
return -EINVAL;
 
+   /*
+* Bound burst to defend burst against overflow during bandwidth shift.
+*/
+   if (burst > max_cfs_runtime)
+   return -EINVAL;
+
+   if (quota == RUNTIME_INF)
+   buffer = RUNTIME_INF;
+   else
+   buffer = min(max_cfs_runtime, quota + burst);
/*
 * Prevent race between setting of cfs_rq->runtime_enabled and
 * unthrottle_offline_cfs_rqs().
@@ -7946,6 +7958,8 @@ static int tg_set_cfs_bandwidth(struct task_group *tg, 
u64 period, u64 quota)
raw_spin_lock_irq(_b->lock);
cfs_b->period = ns_to_ktime(period);
cfs_b->quota = quota;
+   cfs_b->burst = burst;
+   cfs_b->buffer = buffer;
 
__refill_cfs_bandwidth_runtime(cfs_b);
 
@@ -7979,9 +7993,10 @@ static int tg_set_cfs_bandwidth(struct task_group *tg, 
u64 period, u64 quota)
 
 static int tg_set_cfs_quota(struct task_group *tg, long cfs_quota_us)
 {
-   u64 quota, period;
+   u64 quota, period, burst;
 
period = ktime_to_ns(tg->cfs_bandwidth.period);
+   burst = tg->cfs_bandwidth.burst;
if (cfs_quota_us < 0)
quota = RUNTIME_INF;
else if ((u64)cfs_quota_us <= U64_MAX / NSEC_PER_USEC)
@@ -7989,7 +8004,7 @@ static int tg_set_cfs_quota(struct task_group *tg, long 
cfs_quota_us)
else
return -EINVAL;
 
-   return tg_set_cfs_bandwidth(tg, period, quota);
+   return tg_set_cfs_bandwidth(tg, period, quota, burst);
 }
 
 static long tg_get_cfs_quota(struct task_group *tg)
@@ -8007,15 +8022,16 @@ static long tg_get_cfs_quota(struct task_group *tg)
 
 static int tg_set_cfs_period(struct task_group *tg, long cfs_period_us)
 {
-   u64 quota, period;
+   u64 quota, period, burst;
 
if ((u64)cfs_period_us > U64_MAX / NSEC_PER_USEC)
return -EINVAL;
 
period = (u64)cfs_period_us * NSEC_PER_USEC;
quota = tg->cfs_bandwidth.quota;
+   burst = tg->cfs_bandwidth.burst;
 
-   return tg_set_cfs_bandwidth(tg, period, quota);
+   return tg_set_cfs_bandwidth(tg, period, quota, burst);
 }
 
 static long tg_get_cfs_period(struct task_group *tg)
@@ -8028,6 +8044,35 @@ static long tg_get_cfs_period(struct task_group *tg)
return cfs_period_us;
 }
 
+static int tg_set_cfs_burst(struct task_group *tg, long cfs_burst_us)
+{
+   u64 quota, period, burst;
+
+   period = ktime_to_ns(tg->cfs_bandwidth.period);
+   quota = tg->cfs_bandwidth.quota;
+   if (cfs_burst_us < 0)
+   burst = RUNTIME_INF;
+   else if ((u64)cfs_burst_us <= U64_MAX / NSEC_PER_USEC)
+   burst = (u64)cfs_burst_us * NSEC_PER_USEC;
+   else
+   return -EINVAL;
+
+   return tg_set_cfs_bandwidth(tg, period, quota, burst);
+}
+
+static long tg_get_cfs_burst(struct task_group *tg)
+{
+   u64 burst_us;
+
+   if (tg->cfs_bandwidth.burst == RUNTIME_INF)
+   return -1;
+
+   burst_us = tg->cfs_bandwidth.burst;
+   do_div(burst_us, NSEC_PER_USEC);
+
+   return burst_us;
+}
+
 static s64 cpu_cfs_quota_read_s64(struct cgroup_subsys_state *css,
  struct cftype *cft)
 {
@@ -8052,6 +8097,18 @@ static int cpu_cfs_period_write_u64(struct 
cgroup_subsys_state *css,
return tg_set_cfs_period(css_tg(css), cfs_period_us);
 }
 
+static s64 

[PATCH 4/4] sched/fair: Add document for burstable CFS bandwidth control

[Huaixin Chang]

Basic description of usage and effect for CFS Bandwidth Control Burst.

Signed-off-by: Huaixin Chang 
Signed-off-by: Shanpei Chen 
---
 Documentation/scheduler/sched-bwc.rst | 49 ---
 1 file changed, 45 insertions(+), 4 deletions(-)

diff --git a/Documentation/scheduler/sched-bwc.rst 
b/Documentation/scheduler/sched-bwc.rst
index 9801d6b284b1..67c5de641149 100644
--- a/Documentation/scheduler/sched-bwc.rst
+++ b/Documentation/scheduler/sched-bwc.rst
@@ -16,6 +16,11 @@ assigned any additional requests for quota will result in 
those threads being
 throttled. Throttled threads will not be able to run again until the next
 period when the quota is replenished.
 
+With "burst", unused quota from previous periods might be accumulated and
+assigned when a task group requests more CPU than quota during a specific
+period, thus allowing CPU time requests as long as the average request is below
+quota on the long run. The maximum accumulation is capped by burst.
+
 A group's unassigned quota is globally tracked, being refreshed back to
 cfs_quota units at each period boundary. As threads consume this bandwidth it
 is transferred to cpu-local "silos" on a demand basis. The amount transferred
@@ -23,16 +28,18 @@ within each of these updates is tunable and described as 
the "slice".
 
 Management
 --
-Quota and period are managed within the cpu subsystem via cgroupfs.
+Quota, period and burst are managed within the cpu subsystem via cgroupfs.
 
-cpu.cfs_quota_us: the total available run-time within a period (in 
microseconds)
+cpu.cfs_quota_us: run-time replenished within a period (in microseconds)
 cpu.cfs_period_us: the length of a period (in microseconds)
+cpu.cfs_burst_us: the maximum accumulated run-time (in microseconds)
 cpu.stat: exports throttling statistics [explained further below]
 
 The default values are::
 
cpu.cfs_period_us=100ms
-   cpu.cfs_quota=-1
+   cpu.cfs_quota_us=-1
+   cpu.cfs_burst_us=0
 
 A value of -1 for cpu.cfs_quota_us indicates that the group does not have any
 bandwidth restriction in place, such a group is described as an unconstrained
@@ -48,6 +55,11 @@ more detail below.
 Writing any negative value to cpu.cfs_quota_us will remove the bandwidth limit
 and return the group to an unconstrained state once more.
 
+A value of 0 for cpu.cfs_burst_us indicates that the group can not accumulate
+any unused bandwidth. It makes the traditional bandwidth control behavior for
+CFS unchanged. Writing any (valid) positive value(s) into cpu.cfs_burst_us
+will enact the cap on unused bandwidth accumulation.
+
 Any updates to a group's bandwidth specification will result in it becoming
 unthrottled if it is in a constrained state.
 
@@ -65,9 +77,21 @@ This is tunable via procfs::
 Larger slice values will reduce transfer overheads, while smaller values allow
 for more fine-grained consumption.
 
+There is also a global switch to turn off burst for all groups::
+   /proc/sys/kernel/sched_cfs_bw_burst_enabled (default=1)
+
+By default it is enabled. Write 0 values means no accumulated CPU time can be
+used for any group, even if cpu.cfs_burst_us is configured.
+
+Sometimes users might want a group to burst without accumulation. This is
+tunable via::
+   /proc/sys/kernel/sched_cfs_bw_burst_onset_percent (default=0)
+
+Up to 100% runtime of cpu.cfs_burst_us might be given on setting bandwidth.
+
 Statistics
 --
-A group's bandwidth statistics are exported via 3 fields in cpu.stat.
+A group's bandwidth statistics are exported via 6 fields in cpu.stat.
 
 cpu.stat:
 
@@ -75,6 +99,11 @@ cpu.stat:
 - nr_throttled: Number of times the group has been throttled/limited.
 - throttled_time: The total time duration (in nanoseconds) for which entities
   of the group have been throttled.
+- current_bw: Current runtime in global pool.
+- nr_burst: Number of periods burst occurs.
+- burst_time: Cumulative wall-time that any cpus has used above quota in
+  respective periods
+
 
 This interface is read-only.
 
@@ -172,3 +201,15 @@ Examples
 
By using a small period here we are ensuring a consistent latency
response at the expense of burst capacity.
+
+4. Limit a group to 20% of 1 CPU, and allow accumulate up to 60% of 1 CPU
+   addtionally, in case accumulation has been done.
+
+   With 50ms period, 10ms quota will be equivalent to 20% of 1 CPU.
+   And 30ms burst will be equivalent to 60% of 1 CPU.
+
+   # echo 1 > cpu.cfs_quota_us /* quota = 10ms */
+   # echo 5 > cpu.cfs_period_us /* period = 50ms */
+   # echo 3 > cpu.cfs_burst_us /* burst = 30ms */
+
+   Larger buffer setting allows greater burst capacity.
-- 
2.14.4.44.g2045bb6

[PATCH 3/4] sched/fair: Add cfs bandwidth burst statistics

[Huaixin Chang]

Introduce statistics exports for the burstable cfs bandwidth
controller.

The following exports are included:

current_bw: current runtime in global pool
nr_burst:   number of periods bandwidth burst occurs
burst_time: cumulative wall-time that any cpus has
used above quota in respective periods

Signed-off-by: Huaixin Chang 
Signed-off-by: Shanpei Chen 
---
 kernel/sched/core.c  |  6 ++
 kernel/sched/fair.c  | 12 +++-
 kernel/sched/sched.h |  3 +++
 3 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 71cced83df2f..d80a37819d7a 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7986,6 +7986,8 @@ static int tg_set_cfs_bandwidth(struct task_group *tg, 
u64 period, u64 quota,
cfs_b->runtime = min(max_cfs_runtime, cfs_b->runtime);
}
 
+   cfs_b->previous_runtime = cfs_b->runtime;
+
/* Restart the period timer (if active) to handle new period expiry: */
if (runtime_enabled)
start_cfs_bandwidth(cfs_b, 1);
@@ -8234,6 +8236,10 @@ static int cpu_cfs_stat_show(struct seq_file *sf, void 
*v)
seq_printf(sf, "wait_sum %llu\n", ws);
}
 
+   seq_printf(sf, "current_bw %llu\n", cfs_b->runtime);
+   seq_printf(sf, "nr_burst %d\n", cfs_b->nr_burst);
+   seq_printf(sf, "burst_time %llu\n", cfs_b->burst_time);
+
return 0;
 }
 #endif /* CONFIG_CFS_BANDWIDTH */
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 38a726f77783..e431b2fff01d 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4600,7 +4600,7 @@ static inline u64 sched_cfs_bandwidth_slice(void)
  */
 void __refill_cfs_bandwidth_runtime(struct cfs_bandwidth *cfs_b, u64 overrun)
 {
-   u64 refill;
+   u64 refill, runtime;
 
if (cfs_b->quota != RUNTIME_INF) {
 
@@ -4609,10 +4609,20 @@ void __refill_cfs_bandwidth_runtime(struct 
cfs_bandwidth *cfs_b, u64 overrun)
return;
}
 
+   if (cfs_b->previous_runtime > cfs_b->runtime) {
+   runtime = cfs_b->previous_runtime - cfs_b->runtime;
+   if (runtime > cfs_b->quota) {
+   cfs_b->burst_time += runtime - cfs_b->quota;
+   cfs_b->nr_burst++;
+   }
+   }
+
overrun = min(overrun, cfs_b->max_overrun);
refill = cfs_b->quota * overrun;
cfs_b->runtime += refill;
cfs_b->runtime = min(cfs_b->runtime, cfs_b->buffer);
+
+   cfs_b->previous_runtime = cfs_b->runtime;
}
 }
 
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index ff8b5382485d..4adb984e5197 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -367,6 +367,7 @@ struct cfs_bandwidth {
u64 burst;
u64 buffer;
u64 max_overrun;
+   u64 previous_runtime;
s64 hierarchical_quota;
 
u8  idle;
@@ -379,7 +380,9 @@ struct cfs_bandwidth {
/* Statistics: */
int nr_periods;
int nr_throttled;
+   int nr_burst;
u64 throttled_time;
+   u64 burst_time;
 #endif
 };
 
-- 
2.14.4.44.g2045bb6

[PATCH 0/4] sched/fair: Burstable CFS bandwidth controller

[Huaixin Chang]

The CFS bandwidth controller limits CPU requests of a task group to
quota during each period. However, parallel workloads might be bursty
so that they get throttled. And they are latency sensitive at the same
time so that throttling them is undesired.

Scaling up period and quota allows greater burst capacity. But it might
cause longer stuck till next refill. We introduce "burst" to allow
accumulating unused quota from previous periods, and to be assigned when
a task group requests more CPU than quota during a specific period. Thus
allowing CPU time requests as long as the average requested CPU time is
below quota on the long run. The maximum accumulation is capped by burst
and is set 0 by default, thus the traditional behaviour remains.

A huge drop of 99th tail latency from more than 500ms to 27ms is seen for
real java workloads when using burst. Similar drops are seen when
testing with schbench too:

echo $$ > /sys/fs/cgroup/cpu/test/cgroup.procs
echo 70 > /sys/fs/cgroup/cpu/test/cpu.cfs_quota_us
echo 10 > /sys/fs/cgroup/cpu/test/cpu.cfs_period_us
echo 40 > /sys/fs/cgroup/cpu/test/cpu.cfs_burst_us

# The average CPU usage is around 500%, which is 200ms CPU time
# every 40ms.
./schbench -m 1 -t 30 -r 60 -c 1 -R 500

Without burst:

Latency percentiles (usec)
50.th: 7
75.th: 8
90.th: 9
95.th: 10
*99.th: 933
99.5000th: 981
99.9000th: 3068
min=0, max=20054
rps: 498.31 p95 (usec) 10 p99 (usec) 933 p95/cputime 0.10% p99/cputime 
9.33%

With burst:

Latency percentiles (usec)
50.th: 7
75.th: 8
90.th: 9
95.th: 9
*99.th: 12
99.5000th: 13
99.9000th: 19
min=0, max=406
rps: 498.36 p95 (usec) 9 p99 (usec) 12 p95/cputime 0.09% p99/cputime 
0.12%

How much workloads with benefit from burstable CFS bandwidth control
depends on how bursty and how latency sensitive they are.

Previously, Cong Wang and Konstantin Khlebnikov proposed similar
feature:
https://lore.kernel.org/lkml/20180522062017.5193-1-xiyou.wangc...@gmail.com/
https://lore.kernel.org/lkml/157476581065.5793.4518979877345136813.stgit@buzz/

This time we present more latency statistics and handle overflow while
accumulating.

Huaixin Chang (4):
  sched/fair: Introduce primitives for CFS bandwidth burst
  sched/fair: Make CFS bandwidth controller burstable
  sched/fair: Add cfs bandwidth burst statistics
  sched/fair: Add document for burstable CFS bandwidth control

 Documentation/scheduler/sched-bwc.rst |  49 +++--
 include/linux/sched/sysctl.h  |   2 +
 kernel/sched/core.c   | 126 +-
 kernel/sched/fair.c   |  58 +---
 kernel/sched/sched.h  |   9 ++-
 kernel/sysctl.c   |  18 +
 6 files changed, 232 insertions(+), 30 deletions(-)

-- 
2.14.4.44.g2045bb6

Re: brk checks in PR_SET_MM code

[Cyrill Gorcunov]

On Wed, Dec 16, 2020 at 08:29:30PM -0500, Keno Fischer wrote:
> Hi all,
> 
> The code in prctl(PR_SET_MM, ...) performs a number of sanity checks,
> among them
> 
> ```
> /*
>  * @brk should be after @end_data in traditional maps.
>  */
> if (prctl_map->start_brk <= prctl_map->end_data ||
> prctl_map->brk <= prctl_map->end_data)
> goto out;
> ```
> 

Thanks for pointing, Keno! I don't remember the details right now,
gimme some time and once I refresh my memory I'll reply with
details.

[PATCH] arm64: Kconfig: select ZONE_DMA

[Peng Fan (OSS)]

From: Peng Fan 

ZONE_DMA should not be disabled, otherwise arm64_dma_phys_limit is
left uninitialized and cause swiotlb have IO TLB above 4GB which
might crash some platforms

Signed-off-by: Peng Fan 
---

Not sure whether need to address code to initialize the variables or
force select ZONE_DMA

 arch/arm64/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 33446269f692..377b391a41d6 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -206,6 +206,7 @@ config ARM64
select SWIOTLB
select SYSCTL_EXCEPTION_TRACE
select THREAD_INFO_IN_TASK
+   select ZONE_DMA
help
  ARM 64-bit (AArch64) Linux support.
 
-- 
2.28.0

Re: [net-next PATCH v2 02/14] net: phy: Introduce phy related fwnode functions

[Calvin Johnson]

On Tue, Dec 15, 2020 at 07:23:26PM +0200, Andy Shevchenko wrote:
> On Tue, Dec 15, 2020 at 6:44 PM Calvin Johnson
>  wrote:
> >
> > Define fwnode_phy_find_device() to iterate an mdiobus and find the
> > phy device of the provided phy fwnode. Additionally define
> > device_phy_find_device() to find phy device of provided device.
> >
> > Define fwnode_get_phy_node() to get phy_node using named reference.
> 
> ...
> 
> > +#include 
> 
> Not sure we need this. See below.

This is required to use is_acpi_node().
> 
> ...
> 
> > +/**
> > + * fwnode_phy_find_device - Find phy_device on the mdiobus for the provided
> > + * phy_fwnode.
> 
> Can we keep a summary on one line?

Ok
> 
> > + * @phy_fwnode: Pointer to the phy's fwnode.
> > + *
> > + * If successful, returns a pointer to the phy_device with the embedded
> > + * struct device refcount incremented by one, or NULL on failure.
> > + */
> > +struct phy_device *fwnode_phy_find_device(struct fwnode_handle *phy_fwnode)
> > +{
> > +   struct mdio_device *mdiodev;
> > +   struct device *d;
> 
> > +   if (!phy_fwnode)
> > +   return NULL;
> 
> Why is this needed?
> Perhaps a comment to the function description explains a case when
> @phy_fwnode == NULL.

I think this function should be modified to follow of_phy_find_device() which
has NULL check. I'll add fwnode_mdio_find_device() also.
Here is a case where of_phy_find_device() is called without checking phy_np.
https://elixir.bootlin.com/linux/latest/source/drivers/net/ethernet/qualcomm/emac/emac-phy.c#L145
> 
> > +   d = bus_find_device_by_fwnode(_bus_type, phy_fwnode);
> > +   if (d) {
> > +   mdiodev = to_mdio_device(d);
> > +   if (mdiodev->flags & MDIO_DEVICE_FLAG_PHY)
> > +   return to_phy_device(d);
> > +   put_device(d);
> > +   }
> > +
> > +   return NULL;
> > +}
> 
> ...
> 
> > + * For ACPI, only "phy-handle" is supported. DT supports all the three
> > + * named references to the phy node.
> 
> ...
> 
> > +   /* Only phy-handle is used for ACPI */
> > +   phy_node = fwnode_find_reference(fwnode, "phy-handle", 0);
> > +   if (is_acpi_node(fwnode) || !IS_ERR(phy_node))
> > +   return phy_node;
> 
> So, what is the problem with going through the rest on ACPI?
> Usually we describe the restrictions in the documentation.

Others are legacy DT properties which are not intended to be supported
in ACPI. I can add this info in the document.

Thanks for the review, Andy!

Regards
Calvin

Re: [PATCH 00/21] Control VQ support in vDPA

[Eli Cohen]

On Wed, Dec 16, 2020 at 02:47:57PM +0800, Jason Wang wrote:

Hi Jason,
I saw the patchset and will start reviewing it starting Dec 27. I am out
of office next week.

> Hi All:
> 
> This series tries to add the support for control virtqueue in vDPA.
> 
> Control virtqueue is used by networking device for accepting various
> commands from the driver. It's a must to support multiqueue and other
> configurations.
> 
> When used by vhost-vDPA bus driver for VM, the control virtqueue
> should be shadowed via userspace VMM (Qemu) instead of being assigned
> directly to Guest. This is because Qemu needs to know the device state
> in order to start and stop device correctly (e.g for Live Migration).
> 
> This requies to isolate the memory mapping for control virtqueue
> presented by vhost-vDPA to prevent guest from accesing it directly.
> 
> To achieve this, vDPA introduce two new abstractions:
> 
> - address space: identified through address space id (ASID) and a set
>  of memory mapping in maintained
> - virtqueue group: the minimal set of virtqueues that must share an
>  address space
> 
> Device needs to advertise the following attributes to vDPA:
> 
> - the number of address spaces supported in the device
> - the number of virtqueue groups supported in the device
> - the mappings from a specific virtqueue to its virtqueue groups
> 
> The mappings from virtqueue to virtqueue groups is fixed and defined
> by vDPA device driver. E.g:
> 
> - For the device that has hardware ASID support, it can simply
>   advertise a per virtqueue virtqueue group.
> - For the device that does not have hardware ASID support, it can
>   simply advertise a single virtqueue group that contains all
>   virtqueues. Or if it wants a software emulated control virtqueue, it
>   can advertise two virtqueue groups, one is for cvq, another is for
>   the rest virtqueues.
> 
> vDPA also allow to change the association between virtqueue group and
> address space. So in the case of control virtqueue, userspace
> VMM(Qemu) may use a dedicated address space for the control virtqueue
> group to isolate the memory mapping.
> 
> The vhost/vhost-vDPA is also extend for the userspace to:
> 
> - query the number of virtqueue groups and address spaces supported by
>   the device
> - query the virtqueue group for a specific virtqueue
> - assocaite a virtqueue group with an address space
> - send ASID based IOTLB commands
> 
> This will help userspace VMM(Qemu) to detect whether the control vq
> could be supported and isolate memory mappings of control virtqueue
> from the others.
> 
> To demonstrate the usage, vDPA simulator is extended to support
> setting MAC address via a emulated control virtqueue.
> 
> Please review.
> 
> Changes since RFC:
> 
> - tweak vhost uAPI documentation
> - switch to use device specific IOTLB really in patch 4
> - tweak the commit log
> - fix that ASID in vhost is claimed to be 32 actually but 16bit
>   actually
> - fix use after free when using ASID with IOTLB batching requests
> - switch to use Stefano's patch for having separated iov
> - remove unused "used_as" variable
> - fix the iotlb/asid checking in vhost_vdpa_unmap()
> 
> Thanks
> 
> Jason Wang (20):
>   vhost: move the backend feature bits to vhost_types.h
>   virtio-vdpa: don't set callback if virtio doesn't need it
>   vhost-vdpa: passing iotlb to IOMMU mapping helpers
>   vhost-vdpa: switch to use vhost-vdpa specific IOTLB
>   vdpa: add the missing comment for nvqs in struct vdpa_device
>   vdpa: introduce virtqueue groups
>   vdpa: multiple address spaces support
>   vdpa: introduce config operations for associating ASID to a virtqueue
> group
>   vhost_iotlb: split out IOTLB initialization
>   vhost: support ASID in IOTLB API
>   vhost-vdpa: introduce asid based IOTLB
>   vhost-vdpa: introduce uAPI to get the number of virtqueue groups
>   vhost-vdpa: introduce uAPI to get the number of address spaces
>   vhost-vdpa: uAPI to get virtqueue group id
>   vhost-vdpa: introduce uAPI to set group ASID
>   vhost-vdpa: support ASID based IOTLB API
>   vdpa_sim: advertise VIRTIO_NET_F_MTU
>   vdpa_sim: factor out buffer completion logic
>   vdpa_sim: filter destination mac address
>   vdpasim: control virtqueue support
> 
> Stefano Garzarella (1):
>   vdpa_sim: split vdpasim_virtqueue's iov field in out_iov and in_iov
> 
>  drivers/vdpa/ifcvf/ifcvf_main.c   |   9 +-
>  drivers/vdpa/mlx5/net/mlx5_vnet.c |  11 +-
>  drivers/vdpa/vdpa.c   |   8 +-
>  drivers/vdpa/vdpa_sim/vdpa_sim.c  | 292 --
>  drivers/vhost/iotlb.c |  23 ++-
>  drivers/vhost/vdpa.c  | 246 -
>  drivers/vhost/vhost.c |  23 ++-
>  drivers/vhost/vhost.h |   4 +-
>  drivers/virtio/virtio_vdpa.c  |   2 +-
>  include/linux/vdpa.h  |  42 -
>  include/linux/vhost_iotlb.h   |   2 +
>  include/uapi/linux/vhost.h|  25 ++-
>  

[PATCH] usemem: Add option touch-alloc

[Hui Zhu]

Some environment will not fault in memory even if MAP_POPULATE is set.
This commit add option touch-alloc to read memory after allocate it to
make sure the pages is fault in.

Signed-off-by: Hui Zhu 
---
 usemem.c | 37 +
 1 file changed, 25 insertions(+), 12 deletions(-)

diff --git a/usemem.c b/usemem.c
index 6d1d575..d93691b 100644
--- a/usemem.c
+++ b/usemem.c
@@ -97,6 +97,7 @@ unsigned long opt_delay = 0;
 int opt_read_again = 0;
 int opt_punch_holes = 0;
 int opt_init_time = 0;
+int opt_touch_alloc = 0;
 int nr_task;
 int nr_thread;
 int nr_cpu;
@@ -157,6 +158,7 @@ void usage(int ok)
"-Z|--read-again read memory again after access the memory\n"
"--punch-holes   free every other page after allocation\n"
"--init-time remove the initialization time from the run 
time and show the initialization time\n"
+   "--touch-alloc   read memory after allocate it\n"
"-h|--help   show this message\n"
,   ourname);
 
@@ -197,6 +199,7 @@ static const struct option opts[] = {
{ "read-again"  , 0, NULL, 'Z' },
{ "punch-holes" , 0, NULL,   0 },
{ "init-time"   , 0, NULL,   0 },
+   { "touch-alloc" , 0, NULL,   0 },
{ "help", 0, NULL, 'h' },
{ NULL  , 0, NULL, 0 }
 };
@@ -326,6 +329,18 @@ void detach(void)
}
 }
 
+unsigned long do_access(unsigned long *p, unsigned long idx, int read)
+{
+   volatile unsigned long *vp = p;
+
+   if (read)
+   return vp[idx]; /* read data */
+   else {
+   vp[idx] = idx;  /* write data */
+   return 0;
+   }
+}
+
 unsigned long * allocate(unsigned long bytes)
 {
unsigned long *p;
@@ -352,6 +367,14 @@ unsigned long * allocate(unsigned long bytes)
p = (unsigned long *)ALIGN((unsigned long)p, pagesize - 1);
}
 
+   if (opt_touch_alloc) {
+   unsigned long i;
+   unsigned long m = bytes / sizeof(*p);
+
+   for (i = 0; i < m; i += 1)
+   do_access(p, i, 1);
+   }
+
return p;
 }
 
@@ -433,18 +456,6 @@ void shm_unlock(int seg_id)
shmctl(seg_id, SHM_UNLOCK, NULL);
 }
 
-unsigned long do_access(unsigned long *p, unsigned long idx, int read)
-{
-   volatile unsigned long *vp = p;
-
-   if (read)
-   return vp[idx]; /* read data */
-   else {
-   vp[idx] = idx;  /* write data */
-   return 0;
-   }
-}
-
 #define NSEC_PER_SEC  (1UL * 1000 * 1000 * 1000)
 
 long nsec_sub(long nsec1, long nsec2)
@@ -950,6 +961,8 @@ int main(int argc, char *argv[])
opt_punch_holes = 1;
} else if (strcmp(opts[opt_index].name, "init-time") == 
0) { 
opt_init_time = 1;
+   } else if (strcmp(opts[opt_index].name, "touch-alloc") 
== 0) { 
+   opt_touch_alloc = 1;
} else
usage(1);
break;
-- 
2.17.1

[PATCH v1 1/4] Bluetooth: Keep MSFT extension info throughout a hci_dev's life cycle

[Miao-chen Chou]

This moves msft_do_close() from hci_dev_do_close() to
hci_unregister_dev() to avoid clearing MSFT extension info. This also
avoids retrieving MSFT info upon every msft_do_open() if MSFT extension
has been initialized.

The following test steps were performed.
(1) boot the test device and verify the MSFT support debug log in syslog
(2) restart bluetoothd and verify msft_do_close() doesn't get invoked

Signed-off-by: Miao-chen Chou 
Reviewed-by: Abhishek Pandit-Subedi 
Reviewed-by: Archie Pusaka 
---

 net/bluetooth/hci_core.c | 4 ++--
 net/bluetooth/msft.c | 3 ++-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 9d2c9a1c552fd..8471be105a2ac 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1780,8 +1780,6 @@ int hci_dev_do_close(struct hci_dev *hdev)
 
hci_sock_dev_event(hdev, HCI_DEV_DOWN);
 
-   msft_do_close(hdev);
-
if (hdev->flush)
hdev->flush(hdev);
 
@@ -3869,6 +3867,8 @@ void hci_unregister_dev(struct hci_dev *hdev)
unregister_pm_notifier(>suspend_notifier);
cancel_work_sync(>suspend_prepare);
 
+   msft_do_close(hdev);
+
hci_dev_do_close(hdev);
 
if (!test_bit(HCI_INIT, >flags) &&
diff --git a/net/bluetooth/msft.c b/net/bluetooth/msft.c
index 4b39534a14a18..d9d2269bc93ef 100644
--- a/net/bluetooth/msft.c
+++ b/net/bluetooth/msft.c
@@ -76,7 +76,8 @@ void msft_do_open(struct hci_dev *hdev)
 {
struct msft_data *msft;
 
-   if (hdev->msft_opcode == HCI_OP_NOP)
+   /* Skip if opcode is not supported or MSFT has been initiatlized */
+   if (hdev->msft_opcode == HCI_OP_NOP || hdev->msft_data)
return;
 
bt_dev_dbg(hdev, "Initialize MSFT extension");
-- 
2.29.2.684.gfbc64c5ab5-goog

[PATCH v1 2/4] Bluetooth: btqca: Enable MSFT extension for Qualcomm WCN399x

[Miao-chen Chou]

The following Qualcomm WCN399x Bluetooth controllers support the
Microsoft vendor extension and they are using 0xFD70 for VsMsftOpCode.
-WCN3990
-WCN3991
-WCN3998

< HCI Command: ogf 0x3f, ocf 0x0170, plen 1
  00
> HCI Event: 0x0e plen 18
  01 70 FD 00 00 1F 00 00 00 00 00 00 00 04 4D 53 46 54

The following test step was performed.
- Boot the device with WCN3991 and verify INFO print in dmesg.

Signed-off-by: Miao-chen Chou 
Reviewed-by: Abhishek Pandit-Subedi 
Reviewed-by: Archie Pusaka 
---

 drivers/bluetooth/btqca.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c
index f85a55add9be5..ab19963c83616 100644
--- a/drivers/bluetooth/btqca.c
+++ b/drivers/bluetooth/btqca.c
@@ -517,6 +517,19 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate,
return err;
}
 
+   /* WCN399x supports the Microsoft vendor extension with 0xFD70 as the
+* VsMsftOpCode.
+*/
+   switch (soc_type) {
+   case QCA_WCN3990:
+   case QCA_WCN3991:
+   case QCA_WCN3998:
+   hci_set_msft_opcode(hdev, 0xFD70);
+   break;
+   default:
+   break;
+   }
+
/* Perform HCI reset */
err = qca_send_reset(hdev);
if (err < 0) {
-- 
2.29.2.684.gfbc64c5ab5-goog

[PATCH v1 3/4] Bluetooth: btusb: Enable MSFT extension for Intel controllers

[Miao-chen Chou]

The Intel JeffersonPeak, HarrisonPeak and CyclonePeak Bluetooth
controllers support the Microsoft vendor extension and they are using
0xFC1E for VsMsftOpCode.

< HCI Command: Vendor (0x3f|0x001e) plen 1
00
> HCI Event: Command Complete (0x0e) plen 15
  Vendor (0x3f|0x001e) ncmd 1
Status: Success (0x00)
00 3f 00 00 00 00 00 00 00 01 50

The following test step was performed.
- Boot the test devices with HarrisonPeak and verify INFO print in
dmesg.

Signed-off-by: Miao-chen Chou 
Reviewed-by: Abhishek Pandit-Subedi 
Reviewed-by: Archie Pusaka 
---

 drivers/bluetooth/btusb.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 03b83aa912779..25cfa47995a8a 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -2924,7 +2924,10 @@ static int btusb_setup_intel_new(struct hci_dev *hdev)
 * extension are using 0xFC1E for VsMsftOpCode.
 */
switch (ver.hw_variant) {
+   case 0x11:  /* JfP */
case 0x12:  /* ThP */
+   case 0x13:  /* HrP */
+   case 0x14:  /* CcP */
hci_set_msft_opcode(hdev, 0xFC1E);
break;
}
-- 
2.29.2.684.gfbc64c5ab5-goog

[PATCH v1 4/4] Bluetooth: btrtl: Enable MSFT extension for RTL8822CE controller

[Miao-chen Chou]

The Realtek RTL8822CE Bluetooth controller support Microsoft vendor
extension and it uses 0xFCF0 for VsMsftOpCode.

The following test step was performed.
- Boot the test device with RTL8822CE and verify the INFO print in
dmesg.

Signed-off-by: Miao-chen Chou 
Reviewed-by: Abhishek Pandit-Subedi 
Reviewed-by: Archie Pusaka 
---

 drivers/bluetooth/btrtl.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/bluetooth/btrtl.c b/drivers/bluetooth/btrtl.c
index a4f7cace66b06..94df4e94999d5 100644
--- a/drivers/bluetooth/btrtl.c
+++ b/drivers/bluetooth/btrtl.c
@@ -658,6 +658,12 @@ struct btrtl_device_info *btrtl_initialize(struct hci_dev 
*hdev,
}
}
 
+   /* RTL8822CE supports the Microsoft vendor extension and uses 0xFCF0
+* for VsMsftOpCode.
+*/
+   if (lmp_subver == RTL_ROM_LMP_8822B)
+   hci_set_msft_opcode(hdev, 0xFCF0);
+
return btrtl_dev;
 
 err_free:
-- 
2.29.2.684.gfbc64c5ab5-goog

[PATCH] MAINTAINERS: include governors into CPU IDLE TIME MANAGEMENT FRAMEWORK

[Lukas Bulwahn]

The current pattern in the file entry does not make the files in the
governors subdirectory to be a part of the CPU IDLE TIME MANAGEMENT
FRAMEWORK.

Adjust the file pattern to include files in governors.

Signed-off-by: Lukas Bulwahn 
---
applies cleanly on current master and next-20201215

 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 952731d1e43c..ac679aa00e0d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4596,7 +4596,7 @@ B:https://bugzilla.kernel.org
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
 F: Documentation/admin-guide/pm/cpuidle.rst
 F: Documentation/driver-api/pm/cpuidle.rst
-F: drivers/cpuidle/*
+F: drivers/cpuidle/
 F: include/linux/cpuidle.h
 
 CPU POWER MONITORING SUBSYSTEM
-- 
2.17.1

Re: memory leak in xskq_create

[Björn Töpel]

On 2020-12-16 19:11, Peilin Ye wrote:

Hi all,

On Sun, Dec 13, 2020 at 06:53:10AM -0800, syzbot wrote:

BUG: memory leak
unreferenced object 0x88810f897940 (size 64):
   comm "syz-executor991", pid 8502, jiffies 4294942194 (age 14.080s)
   hex dump (first 32 bytes):
 7f 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00  
 00 a0 37 0c 81 88 ff ff 00 00 00 00 00 00 00 00  ..7.
   backtrace:
 [<639d0dd1>] xskq_create+0x23/0xd0 include/linux/slab.h:552
 [] xsk_init_queue net/xdp/xsk.c:508 [inline]
 [] xsk_setsockopt+0x1c4/0x590 net/xdp/xsk.c:875
 [<2b302260>] __sys_setsockopt+0x1b0/0x360 net/socket.c:2132
 [] __do_sys_setsockopt net/socket.c:2143 [inline]
 [] __se_sys_setsockopt net/socket.c:2140 [inline]
 [] __x64_sys_setsockopt+0x22/0x30 net/socket.c:2140
 [<05c2b4a0>] do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 [<03db140f>] entry_SYSCALL_64_after_hwframe+0x44/0xa9


I have tested the following diff locally against syzbot's reproducer,
and sent a patch to it [1] for testing.  I will send a real patch here
tomorrow if syzbot is happy about it.  Please see explanation below.



Hi Peilin Ye!

Thanks for taking a look! Magnus has already addressed this problem in
another patch [1].


Cheers,
Björn



[1] 
https://lore.kernel.org/bpf/20201214085127.3960-1-magnus.karls...@gmail.com/

Re: linux-next: build failure after merge of the watchdog tree

[Wim Van Sebroeck]

Hi Stephen,

Some operational work-related issues broke my planning yesterday.
I just made the changes to the watchdog tree.

My apologies,
Wim.

> Hi Stephen,
> 
> It's on my todo list for today.
> 
> Kind ergards,
> Wim.
> 
> > Hi all,
> > 
> > On Sun, 13 Dec 2020 22:09:55 -0800 Guenter Roeck  wrote:
> > >
> > > On 12/13/20 9:23 PM, Stephen Rothwell wrote:
> > > > Hi all,
> > > > 
> > > > After merging the watchdog tree, today's linux-next build (x86_64
> > > > allmodconfig) failed like this:
> > > > 
> > > > In file included from include/linux/device.h:15,
> > > >  from include/linux/acpi.h:15,
> > > >  from drivers/watchdog/iTCO_wdt.c:48:
> > > > drivers/watchdog/iTCO_wdt.c: In function 'iTCO_wdt_start':
> > > > drivers/watchdog/iTCO_wdt.c:280:17: error: 'struct watchdog_device' has 
> > > > no member named 'dev'
> > > >   280 |   dev_err(wd_dev->dev, "failed to reset NO_REBOOT flag, reboot 
> > > > disabled by hardware/BIOS\n");
> > > >   | ^~  
> > > 
> > > Yes, that should have been wd_dev->parent. Sorry I didn't notice that 
> > > earlier.
> > > 
> > > Guenter
> > > 
> > > > include/linux/dev_printk.h:112:11: note: in definition of macro 
> > > > 'dev_err'
> > > >   112 |  _dev_err(dev, dev_fmt(fmt), ##__VA_ARGS__)
> > > >   |   ^~~
> > > > 
> > > > Caused by commit
> > > > 
> > > >   9c612b338fdf ("watchdog: iTCO_wdt: use dev_*() instead of pr_*() for 
> > > > logging")
> > > 
> > > > I have used the wtchdog tree from next-20201211 for today.
> > 
> > I am still getting this build failure.
> > 
> > -- 
> > Cheers,
> > Stephen Rothwell
> 
> 

Re: [dm-devel] [PATCH v1 0/5] dm: dm-user: New target that proxies BIOs to userspace

[Palmer Dabbelt]

On Wed, 16 Dec 2020 10:24:59 PST (-0800), v.mayats...@gmail.com wrote:

On Mon, Dec 14, 2020 at 10:03 PM Palmer Dabbelt  wrote:


I was really experting someone to say that.  It does seem kind of silly to build
out the new interface, but not go all the way to a ring buffer.  We just didn't
really have any way to justify the extra complexity as our use cases aren't
that high performance.   I kind of like to have benchmarks for this sort of
thing, though, and I didn't have anyone who had bothered avoiding the last copy
to compare against.


I worked on something very similar, though performance was one of the
goals. The implementation was floating around lockless ring buffers,
shared memory for zerocopy, multiqueue and error handling. It could be
that every disk storage vendor has to implement something like that in
order to bridge Linux kernel to their own proprietary datapath running
in userspace.


OK, good to know.  That's kind of the feeling I'd gotten from having chatted to
a handful of people about this, but I don't remember people having actually
gotten all the way to zero-copy.  That's how we managed to end up at this
middle-ground ABI style: when I thought people were, in practice, punting on
zero copy because the complexity just wasn't worth the performance benefit.
Maybe I'd just been colored by how my projects ended up going, but I've ended
up designing complicated interfaces in the past that allow for zero-copy only
to never get around to actually making that work.  I don't know if that's just
because I've had the good fortune to avoid working on anything that ended up
with users, though :).

For our use case I think we actually get better performance out of the
copy-based (and probably more importantly kalloc-based, but that's an
implementation thing not an ABI thing) approach: essentially we're very
sensitive to memory pressure and expect this first dm-user daemon to mostly be
idle, so we're really worried about avoiding excess memory usage while idle and
less worried about throughput when active.  This stream-based interface means
that userspace doesn't need much memory allocated to service a request, which
helps with sleep/wake latencies and/or idle memory usage.  That's also why we
have the simple locking scheme: no sense splitting locks if there's no
contention, and we only need a single thread to saturate the storage bandwidth
on these phones.

That said, it does sound like people really do care about the sort of
performance levels where zero copy is relevant in this space.  I'll take a shot
at something along those lines, and while it will add a degree of userspace
complexity I'm not sure it'll add much in the way of kernel complexity -- at
least compared to a fast version of this, where we'd need most of that stuff
anyway (obviously the malloc+single lock design is simple, but probably
wouldn't stick around for long).  At a bare minimum it'll be interesting to
play around with, but if people are doing it in practice then I'm more
confident that I can put something together that at least serves as a starting
point for further discussion.

I haven't gotten around to writing any code yet, but I had spent a bit of time
thinking about how to put this zero-copy version together and am leaning
towards it being a standalone block device (as opposed to a DM target).  I'd
avoided that before as I didn't want to mess around with my own device control
scheme so I'll still try to do the DM thing, but I'm not sure it'll be viable.
That's all speculation now, but it does bring up one interesting question:

IIUC, this version of dm-user handles BIOs before they reach the block
scheduler while a standalone driver would likely handle them after blk-mq.  I
don't have direct experience with this, but the last time I ran into people who
had these sorts of performance requirements for userspace drivers they weren't
actually trying to write userspace drivers but were instead trying to write a
userspace scheduler, with the userspace drivers just being the mechanism to
implement that scheduler.  This was a decade ago and I'm not sure that's what
people are trying to do in the new blk-mq world, but if it is then it's going
to be a major design consideration.  I'm also not entirely sure that we're
really solving the same problem at that point.

Re: [External] Re: [PATCH v9 03/11] mm/hugetlb: Free the vmemmap pages associated with each HugeTLB page

[Muchun Song]

On Thu, Dec 17, 2020 at 6:52 AM Mike Kravetz  wrote:
>
> On 12/16/20 2:25 PM, Oscar Salvador wrote:
> > On Wed, Dec 16, 2020 at 02:08:30PM -0800, Mike Kravetz wrote:
> >>> + * vmemmap_rmap_walk - walk vmemmap page table
> >>> +
> >>> +static void vmemmap_pte_range(pmd_t *pmd, unsigned long addr,
> >>> + unsigned long end, struct vmemmap_rmap_walk 
> >>> *walk)
> >>> +{
> >>> +   pte_t *pte;
> >>> +
> >>> +   pte = pte_offset_kernel(pmd, addr);
> >>> +   do {
> >>> +   BUG_ON(pte_none(*pte));
> >>> +
> >>> +   if (!walk->reuse)
> >>> +   walk->reuse = pte_page(pte[VMEMMAP_TAIL_PAGE_REUSE]);
> >>
> >> It may be just me, but I don't like the pte[-1] here.  It certainly does 
> >> work
> >> as designed because we want to remap all pages in the range to the page 
> >> before
> >> the range (at offset -1).  But, we do not really validate this 'reuse' 
> >> page.
> >> There is the BUG_ON(pte_none(*pte)) as a sanity check, but we do nothing 
> >> similar
> >> for pte[-1].  Based on the usage for HugeTLB pages, we can be confident 
> >> that
> >> pte[-1] is actually a pte.  In discussions with Oscar, you mentioned 
> >> another
> >> possible use for these routines.
> >
> > Without giving it much of a thought, I guess we could duplicate the
> > BUG_ON for the pte outside the loop, and add a new one for pte[-1].
> > Also, since walk->reuse seems to not change once it is set, we can take
> > it outside the loop? e.g:
> >
> >   pte *pte;
> >
> >   pte = pte_offset_kernel(pmd, addr);
> >   BUG_ON(pte_none(*pte));
> >   BUG_ON(pte_none(pte[VMEMMAP_TAIL_PAGE_REUSE]));
> >   walk->reuse = pte_page(pte[VMEMMAP_TAIL_PAGE_REUSE]);
> >   do {
> >   
> >   } while...
> >
> > Or I am not sure whether we want to keep it inside the loop in case
> > future cases change walk->reuse during the operation.
> > But to be honest, I do not think it is realistic of all future possible
> > uses of this, so I would rather keep it simple for now.
>
> I was thinking about possibly passing the 'reuse' address as another parameter
> to vmemmap_remap_reuse().  We could add this addr to the vmemmap_rmap_walk
> struct and set walk->reuse when we get to the pte for that address.  Of
> course this would imply that the addr would need to be part of the range.

Maybe adding another one parameter is unnecessary.  How about doing
this in the vmemmap_remap_reuse?

The 'reuse' address just is start + PAGE_SIZE.

void vmemmap_remap_free(unsigned long start, unsigned long size)
{
 unsigned long end = start + size;
 unsigned long reuse_addr = start + PAGE_SIZE;
 LIST_HEAD(vmemmap_pages);

 struct vmemmap_remap_walk walk = {
  .remap_pte = vmemmap_remap_pte,
  .vmemmap_pages = _pages,
  .reuse_addr = reuse_addr.
 };

}

>
> Ideally, we would walk the page table to get to the reuse page.  My concern
> was not explicitly about adding the BUG_ON.  In more general use, *pte could
> be the first entry on a pte page.  And, then pte[-1] may not even be a pte.
>
> Again, I don't think this matters for the current HugeTLB use case.  Just a
> little concerned if code is put to use for other purposes.
> --
> Mike Kravetz



-- 
Yours,
Muchun

Re: [PATCH] tick/nohz: Make the idle_exittime update correctly

[Yunfeng Ye]

On 2020/12/15 22:47, Frederic Weisbecker wrote:
> On Tue, Dec 15, 2020 at 08:06:34PM +0800, Yunfeng Ye wrote:
>> The idle_exittime field of tick_sched is used to record the time when
>> the idle state was left. but currently the idle_exittime is updated in
>> the function tick_nohz_restart_sched_tick(), which is not always in idle
>> state when nohz_full is configured.
>>
>>   tick_irq_exit
>> tick_nohz_irq_exit
>>   tick_nohz_full_update_tick
>> tick_nohz_restart_sched_tick
>>   ts->idle_exittime = now;
>>
>> So move to tick_nohz_stop_idle() to make the idle_exittime update
>> correctly.
>>
>> Signed-off-by: Yunfeng Ye 
>> ---
>>  kernel/time/tick-sched.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
>> index 749ec2a583de..be2e5d772d50 100644
>> --- a/kernel/time/tick-sched.c
>> +++ b/kernel/time/tick-sched.c
>> @@ -591,6 +591,7 @@ static void tick_nohz_stop_idle(struct tick_sched *ts, 
>> ktime_t now)
>>  {
>>  update_ts_time_stats(smp_processor_id(), ts, now, NULL);
>>  ts->idle_active = 0;
>> +ts->idle_exittime = now;
> 
> This changes a bit the meaning of idle_exittime then since this is also called
> from idle interrupt entry.
> 
> __tick_nohz_idle_restart_tick() would be a better place.
> 
So is it necessary to modify the comment "@idle_exittime:  Time when the 
idle state was left" ?

On the other hand, if the patch "nohz: Update tick instead of restarting tick 
in tick_nohz_idle_exit()"
(https://www.spinics.net/lists/kernel/msg3747039.html ) applied, 
__tick_nohz_idle_restart_tick will not
be called always, So is it put here also a better place?

Thanks.

> Thanks.
> 
>>
>>  sched_clock_idle_wakeup_event();
>>  }
>> @@ -901,7 +902,6 @@ static void tick_nohz_restart_sched_tick(struct 
>> tick_sched *ts, ktime_t now)
>>   * Cancel the scheduled timer and restore the tick
>>   */
>>  ts->tick_stopped  = 0;
>> -ts->idle_exittime = now;
>>
>>  tick_nohz_restart(ts, now);
>>  }
>> -- 
>> 2.18.4
>>
> .
> 

Re: [PATCH] f2fs: fix out-of-repair __setattr_copy()

[Chao Yu]

On 2020/12/16 17:44, Greg KH wrote:

On Wed, Dec 16, 2020 at 05:15:23PM +0800, Chao Yu wrote:

__setattr_copy() was copied from setattr_copy() in fs/attr.c, there is
two missing patches doesn't cover this inner function, fix it.

Commit 7fa294c8991c ("userns: Allow chown and setgid preservation")
Commit 23adbe12ef7d ("fs,userns: Change inode_capable to 
capable_wrt_inode_uidgid")


Are these lines supposed to be "Fixes:" instead of "Commit "?


IMO, the issue was introduced when f2fs module was added, and above two commits
missed to cover f2fs module... so I guess we can add Fixes line as below?

Fixes: fbfa2cc58d53 ("f2fs: add file operations")

Thanks,



thanks,

greg k-h
.

Re: [PATCH v3 3/5] RISC-V: Align the .init.text section

[Palmer Dabbelt]

On Tue, 15 Dec 2020 22:02:54 PST (-0800), Palmer Dabbelt wrote:

On Wed, 04 Nov 2020 16:04:37 PST (-0800), Atish Patra wrote:

In order to improve kernel text protection, we need separate .init.text/
.init.data/.text in separate sections. However, RISC-V linker relaxation
code is not aware of any alignment between sections. As a result, it may
relax any RISCV_CALL relocations between sections to JAL without realizing
that an inter section alignment may move the address farther. That may
lead to a relocation truncated fit error. However, linker relaxation code
is aware of the individual section alignments.

The detailed discussion on this issue can be found here.
https://github.com/riscv/riscv-gnu-toolchain/issues/738

Keep the .init.text section aligned so that linker relaxation will take
that as a hint while relaxing inter section calls.
Here are the code size changes for each section because of this change.

section change in size (in bytes)
  .head.text  +4
  .text   +40
  .init.text  +6530
  .exit.text  +84

The only significant increase in size happened for .init.text because
all intra relocations also use 2MB alignment.

Suggested-by: Jim Wilson 
Signed-off-by: Atish Patra 
---
 arch/riscv/kernel/vmlinux.lds.S | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/kernel/vmlinux.lds.S b/arch/riscv/kernel/vmlinux.lds.S
index 3ffbd6cbdb86..cacd7898ba7f 100644
--- a/arch/riscv/kernel/vmlinux.lds.S
+++ b/arch/riscv/kernel/vmlinux.lds.S
@@ -30,7 +30,13 @@ SECTIONS
. = ALIGN(PAGE_SIZE);

__init_begin = .;
-   INIT_TEXT_SECTION(PAGE_SIZE)
+   __init_text_begin = .;
+   .init.text : AT(ADDR(.init.text) - LOAD_OFFSET) ALIGN(SECTION_ALIGN) { \
+   _sinittext = .; \
+   INIT_TEXT   \
+   _einittext = .; \
+   }
+
. = ALIGN(8);
__soc_early_init_table : {
__soc_early_init_table_start = .;


Not sure what's going on here (or why I wasn't catching it earlier), but this
is breaking boot on one of my test configs.  I'm not getting any Linux boot
spew, so it's something fairly early.  I'm running defconfig with

CONFIG_PREEMPT=y
CONFIG_DEBUG_PREEMPT=y
CONFIG_PROVE_LOCKING=y

It looks like that's been throwing a bunch of warnings for a while, but it did
at least used to boot.  No idea what PREEMPT would have to do with this, and
the other two don't generally trigger issues that early in boot (or at least,
trigger halts that early in boot).

There's a bunch of other stuff that depends on this that's on for-next so I
don't want to just drop it, but I also don't want to break something.  I'm just
running QEMU's virt board.

I'll take a look again tomorrow night, but if anyone has some time to look
that'd be great!


Looks like this breaks on QEMU 5.0.0 but works on 5.2.0.  I guess technically
that means could be considered a regression, but as we don't really have any
scheme for which old versions of QEMU we support it's not absolute.  I'd
usually err on the side of keeping support for older platforms, but in this
case it's probably just not worth the time so I'm going to just ignore it.

Re: [PATCH v2] ath10k: Remove voltage regulator votes during wifi disable

[Kalle Valo]

Rakesh Pillai  wrote:

> When the wlan is disabled, i.e when all the interfaces are
> deleted, voltage regulator votes are not removed. This leads
> to more power consumption even when wlan is disabled.
> 
> Move the adding/removing of voltage regulator votes as part
> of hif power on/off in SNOC targets, so that these voltage
> regulator votes are there only when wlan is enabled.
> 
> Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1
> 
> Signed-off-by: Rakesh Pillai 
> Signed-off-by: Kalle Valo 

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

5f1aa93ffa1f ath10k: Remove voltage regulator votes during wifi disable

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/1607713230-18382-1-git-send-email-pill...@codeaurora.org/

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

Re: [PATCH] ext4: fix -Wstringop-truncation warnings

[Wenlin Kang]

On 2020/12/16 下午12:20, Theodore Y. Ts'o wrote:

[Please note this e-mail is from an EXTERNAL e-mail address]

On Thu, Nov 12, 2020 at 05:33:24PM +0800, Kang Wenlin wrote:

From: Wenlin Kang 

The strncpy() function may create a unterminated string,
use strscpy_pad() instead.

This fixes the following warning:

fs/ext4/super.c: In function '__save_error_info':
fs/ext4/super.c:349:2: warning: 'strncpy' specified bound 32 equals destination 
size [-Wstringop-truncation]
   strncpy(es->s_last_error_func, func, sizeof(es->s_last_error_func));
   ^~~
fs/ext4/super.c:353:3: warning: 'strncpy' specified bound 32 equals destination 
size [-Wstringop-truncation]
strncpy(es->s_first_error_func, func,
^
 sizeof(es->s_first_error_func));
 ~~~

What compiler are you using?  s_last_error_func is defined to not
necessarily be NUL terminated.  So strscpy_pad() is not a proper
replacement for strncpy() in this use case.



My compiler is gcc 8.2.0,  this is found in v4.18, and I see mainline 
codes is
using the same code too,  so sent this patch. But according to your 
instructions,
I just re-check the code, with "__nonstring" attribute, it seems it has 
fixed.

Thank for your explain.




 From Documentation/process/deprecated:

If a caller is using non-NUL-terminated strings, strncpy() can
still be used, but destinations should be marked with the `__nonstring
`_
attribute to avoid future compiler warnings.

s_{first,last}_error_func is properly annotated with __nonstring in
fs/ext4/ext4.h.

 - Ted



--
Thanks,
Wenlin Kang

Re: [PATCH] ath10k: Fix error handling in case of CE pipe init failure

[Kalle Valo]

Rakesh Pillai  wrote:

> Currently if the copy engine pipe init fails for snoc based
> chipsets, the rri is not freed.
> 
> Fix this error handling for copy engine pipe init
> failure.
> 
> Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1
> 
> Fixes: 4945af5b264f ("ath10k: enable SRRI/DRRI support on ddr for WCN3990")
> Signed-off-by: Rakesh Pillai 
> Reviewed-by: Brian Norris 
> Signed-off-by: Kalle Valo 

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

31561e8557cd ath10k: Fix error handling in case of CE pipe init failure

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/1607713210-18320-1-git-send-email-pill...@codeaurora.org/

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

Re: arm64: entry.S:774: Error: immediate out of range at operand 3 -- `and x2,x19,

[Stephen Rothwell]

Hi Naresh,

On Thu, 17 Dec 2020 12:13:03 +0530 Naresh Kamboju  
wrote:
>
> arm64 build failed on Linux next 20201217 tag with gcc-8, gcc-9 and gcc-10.
> 
> make --silent --keep-going --jobs=8
> O=/home/tuxbuild/.cache/tuxmake/builds/2/tmp ARCH=arm64
> CROSS_COMPILE=aarch64-linux-gnu- 'CC=sccache aarch64-linux-gnu-gcc'
> 'HOSTCC=sccache gcc'
> arch/arm64/kernel/entry.S: Assembler messages:
> arch/arm64/kernel/entry.S:774: Error: immediate out of range at
> operand 3 -- `and
> x2,x19,#((1<<1)|(1<<0)|(1<<2)|(1<<3)|(1<<4)|(1<<5)|(1<<7))'
> make[3]: *** [scripts/Makefile.build:360: arch/arm64/kernel/entry.o] Error 1

This is fixed by commit

  870d16757ba8 ("arm64: make _TIF_WORK_MASK bits contiguous")

in Linus' tree which will be in linux-next tomorrow.

-- 
Cheers,
Stephen Rothwell


pgp9apBtQQ_D1.pgp
Description: OpenPGP digital signature

Re: [PATCH][next] ath11k: add missing null check on allocated skb

[Kalle Valo]

Colin King  wrote:

> Currently the null check on a newly allocated skb is missing and
> this can lead to a null pointer dereference is the allocation fails.
> Fix this by adding a null check and returning -ENOMEM.
> 
> Addresses-Coverity: ("Dereference null return")
> Fixes: 43ed15e1ee01 ("ath11k: put hw to DBS using WMI_PDEV_SET_HW_MODE_CMDID")
> Signed-off-by: Colin Ian King 
> Signed-off-by: Kalle Valo 

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

292bff9480c8 ath11k: add missing null check on allocated skb

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/20201214232417.84556-1-colin.k...@canonical.com/

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

Re: USGv6 Tunnel Mode Fragmentation Failures

[Steffen Klassert]

On Thu, Nov 26, 2020 at 09:21:39AM +, Marler, Jonathan wrote:
> We've found an issue while running the following USGv6 tests where the kernel 
> drops outgoing packets:
> 
> 5.3.11 Tunnel Mode: Fragmentation
> 5.4.11 Tunnel Mode: Fragmentation
> 
> During the test, an esp PING request is sent to our device under test, and we 
> send back a response that is rejected by our router with a "packet to big" 
> error.  This error is fine, it's part of the test.  This error packet then 
> sets the MTU to 1280 (which also happens to be the minimum MTU size allowed 
> by ipv6 and the kernel).
> 
> The issue comes up when this mtu is adjusted by the esp6_get_mtu function.  
> It adjusts it to a value below the 1280 threshold, which causes any packets 
> associated with this MTU to be dropped in the ipv6_setup_cork function.
> 
> We are running on kernel version 4.9.180, but this issue looks as if it would 
> still exist in the latest version except that esp6_get_mtu has been replaced 
> by xfrm_state_mtu.  By adding instrumentation, we found during the test the 
> mtu value of 1280 given by the "packet to big" response gets passed to the 
> esp6_get_mtu function, and the following values are what we logged in that 
> function:
> 
> mtu = 1280
> x->props.header_len = 56
> crypto_aead_authsize(aead) = 12
> net_adj = 0
> blocksize = 8
> 
> This causes the function to return an mtu size of 1206, causing packets 
> thereafter to be dropped because this falls below the IPV6_MIN_MTU threshold.
> 
> Our idea is to modify esp6_get_mtu to limit the minimum mtu to IPV6_MIN_MTU.  
> We're not certain this is the correct fix, and thought to check with the 
> maintainers of that file, and a few others who have modified that function.  
> Any help or guidance here is appreciated, thank you.
> 

We should not return a mtu below IPV6_MIN_MTU for IPv6 and not below
IPV6_MIN_MTU for IPv4. So the proposed fix looks correct to me.

arm64: entry.S:774: Error: immediate out of range at operand 3 -- `and x2,x19,

[Naresh Kamboju]

arm64 build failed on Linux next 20201217 tag with gcc-8, gcc-9 and gcc-10.

make --silent --keep-going --jobs=8
O=/home/tuxbuild/.cache/tuxmake/builds/2/tmp ARCH=arm64
CROSS_COMPILE=aarch64-linux-gnu- 'CC=sccache aarch64-linux-gnu-gcc'
'HOSTCC=sccache gcc'
arch/arm64/kernel/entry.S: Assembler messages:
arch/arm64/kernel/entry.S:774: Error: immediate out of range at
operand 3 -- `and
x2,x19,#((1<<1)|(1<<0)|(1<<2)|(1<<3)|(1<<4)|(1<<5)|(1<<7))'
make[3]: *** [scripts/Makefile.build:360: arch/arm64/kernel/entry.o] Error 1


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

tuxmake --runtime docker --target-arch arm64 --toolchain gcc-9
--kconfig defconfig

Full build log link,
https://gitlab.com/Linaro/lkft/mirrors/next/linux-next/-/jobs/917491444


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

Re: [PATCH][next] ath11k: add missing null check on allocated skb

[Kalle Valo]

Kalle Valo  writes:

> Colin King  wrote:
>
>> Currently the null check on a newly allocated skb is missing and
>> this can lead to a null pointer dereference is the allocation fails.
>> Fix this by adding a null check and returning -ENOMEM.
>> 
>> Addresses-Coverity: ("Dereference null return")
>> Fixes: 43ed15e1ee01 ("ath11k: put hw to DBS using 
>> WMI_PDEV_SET_HW_MODE_CMDID")
>> Signed-off-by: Colin Ian King 
>> Signed-off-by: Kalle Valo 
>
> Patch applied to ath-current branch of ath.git, thanks.
>
> c86a36a621f2 ath11k: add missing null check on allocated skb

I did a mistake and that commit id will change, so please disregard
this. There will be a new mail soon.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

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

Re: [PATCH][next] ath11k: add missing null check on allocated skb

[Kalle Valo]

Colin King  wrote:

> Currently the null check on a newly allocated skb is missing and
> this can lead to a null pointer dereference is the allocation fails.
> Fix this by adding a null check and returning -ENOMEM.
> 
> Addresses-Coverity: ("Dereference null return")
> Fixes: 43ed15e1ee01 ("ath11k: put hw to DBS using WMI_PDEV_SET_HW_MODE_CMDID")
> Signed-off-by: Colin Ian King 
> Signed-off-by: Kalle Valo 

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

c86a36a621f2 ath11k: add missing null check on allocated skb

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/20201214232417.84556-1-colin.k...@canonical.com/

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

[PATCH 2/3] mm/memcg: remove rcu locking for lock_page_lruvec function series

[Alex Shi]

The rcu_read_lock was used to block memcg destory, but with the detailed
calling conditions, the memcg won't gone since the page is hold. So we
don't need it now, let's remove them to save locking load in debugging.

Signed-off-by: Alex Shi 
Cc: Hugh Dickins 
Cc: Johannes Weiner 
Cc: Michal Hocko 
Cc: Vladimir Davydov 
Cc: Andrew Morton 
Cc: cgro...@vger.kernel.org
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
---
 mm/memcontrol.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index e6b50d068b2f..98bbee1d2faf 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -1356,10 +1356,8 @@ struct lruvec *lock_page_lruvec(struct page *page)
struct lruvec *lruvec;
struct pglist_data *pgdat = page_pgdat(page);
 
-   rcu_read_lock();
lruvec = mem_cgroup_page_lruvec(page, pgdat);
spin_lock(>lru_lock);
-   rcu_read_unlock();
 
lruvec_memcg_debug(lruvec, page);
 
@@ -1371,10 +1369,8 @@ struct lruvec *lock_page_lruvec_irq(struct page *page)
struct lruvec *lruvec;
struct pglist_data *pgdat = page_pgdat(page);
 
-   rcu_read_lock();
lruvec = mem_cgroup_page_lruvec(page, pgdat);
spin_lock_irq(>lru_lock);
-   rcu_read_unlock();
 
lruvec_memcg_debug(lruvec, page);
 
@@ -1386,10 +1382,8 @@ struct lruvec *lock_page_lruvec_irqsave(struct page 
*page, unsigned long *flags)
struct lruvec *lruvec;
struct pglist_data *pgdat = page_pgdat(page);
 
-   rcu_read_lock();
lruvec = mem_cgroup_page_lruvec(page, pgdat);
spin_lock_irqsave(>lru_lock, *flags);
-   rcu_read_unlock();
 
lruvec_memcg_debug(lruvec, page);
 
-- 
2.29.GIT

[PATCH 3/3] mm/compaction: remove rcu_read_lock during page compaction

[Alex Shi]

rcu_read_lock was used to guard memcg destory, now TestClearPageLRU
could block this happen, so we don't need it. Remove it to reduce
locking load in debugging mode.

Signed-off-by: Alex Shi 
Cc: Hugh Dickins 
Cc: Johannes Weiner 
Cc: Andrew Morton 
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
---
 mm/compaction.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index 8049d3530812..02af220fb992 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -995,7 +995,6 @@ isolate_migratepages_block(struct compact_control *cc, 
unsigned long low_pfn,
if (!TestClearPageLRU(page))
goto isolate_fail_put;
 
-   rcu_read_lock();
lruvec = mem_cgroup_page_lruvec(page, pgdat);
 
/* If we already hold the lock, we can skip some rechecking */
@@ -1005,7 +1004,6 @@ isolate_migratepages_block(struct compact_control *cc, 
unsigned long low_pfn,
 
compact_lock_irqsave(>lru_lock, , cc);
locked = lruvec;
-   rcu_read_unlock();
 
lruvec_memcg_debug(lruvec, page);
 
@@ -1026,8 +1024,7 @@ isolate_migratepages_block(struct compact_control *cc, 
unsigned long low_pfn,
SetPageLRU(page);
goto isolate_fail_put;
}
-   } else
-   rcu_read_unlock();
+   }
 
/* The whole page is taken off the LRU; skip the tail pages. */
if (PageCompound(page))
-- 
2.29.GIT

[PATCH 1/3] mm/memcg: revise the using condition of lock_page_lruvec function series

[Alex Shi]

The series function could be used under lock_page_memcg(), add this and
a bit style changes following commit_charge().

Signed-off-by: Alex Shi 
Cc: Hugh Dickins 
Cc: Johannes Weiner 
Cc: Michal Hocko 
Cc: Vladimir Davydov 
Cc: Andrew Morton 
Cc: cgro...@vger.kernel.org
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
---
 mm/memcontrol.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index b80328f52fb4..e6b50d068b2f 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -1345,10 +1345,11 @@ void lruvec_memcg_debug(struct lruvec *lruvec, struct 
page *page)
  * lock_page_lruvec - lock and return lruvec for a given page.
  * @page: the page
  *
- * This series functions should be used in either conditions:
- * PageLRU is cleared or unset
- * or page->_refcount is zero
- * or page is locked.
+ * This series functions should be used in any one of following conditions:
+ * - PageLRU is cleared or unset
+ * - page->_refcount is zero
+ * - page is locked.
+ * - lock_page_memcg()
  */
 struct lruvec *lock_page_lruvec(struct page *page)
 {
-- 
2.29.GIT

Re: [PATCH 3/5] thermal/drivers/acpi: Use hot and critical ops

[Daniel Lezcano]

On 10/12/2020 13:15, Daniel Lezcano wrote:
> The acpi driver wants to do a netlink notification in case of a hot or
> critical trip point. Implement the corresponding ops to be used for
> the thermal zone and use them instead of the notify ops.
> 
> Signed-off-by: Daniel Lezcano 

Is there any comment on this patch ?

> ---
>  drivers/acpi/thermal.c | 30 ++
>  1 file changed, 14 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
> index 12c0ece746f0..b5e4bc9e3282 100644
> --- a/drivers/acpi/thermal.c
> +++ b/drivers/acpi/thermal.c
> @@ -677,27 +677,24 @@ static int thermal_get_trend(struct thermal_zone_device 
> *thermal,
>   return 0;
>  }
>  
> -
> -static int thermal_notify(struct thermal_zone_device *thermal, int trip,
> -enum thermal_trip_type trip_type)
> +static void acpi_thermal_zone_device_hot(struct thermal_zone_device *thermal)
>  {
> - u8 type = 0;
>   struct acpi_thermal *tz = thermal->devdata;
>  
> - if (trip_type == THERMAL_TRIP_CRITICAL)
> - type = ACPI_THERMAL_NOTIFY_CRITICAL;
> - else if (trip_type == THERMAL_TRIP_HOT)
> - type = ACPI_THERMAL_NOTIFY_HOT;
> - else
> - return 0;
> -
>   acpi_bus_generate_netlink_event(tz->device->pnp.device_class,
> - dev_name(>device->dev), type, 1);
> + dev_name(>device->dev),
> + ACPI_THERMAL_NOTIFY_HOT, 1);
> +}
>  
> - if (trip_type == THERMAL_TRIP_CRITICAL && nocrt)
> - return 1;
> +static void acpi_thermal_zone_device_critical(struct thermal_zone_device 
> *thermal)
> +{
> + struct acpi_thermal *tz = thermal->devdata;
>  
> - return 0;
> + acpi_bus_generate_netlink_event(tz->device->pnp.device_class,
> + dev_name(>device->dev),
> + ACPI_THERMAL_NOTIFY_CRITICAL, 1);
> +
> + thermal_zone_device_critical(thermal);
>  }
>  
>  static int acpi_thermal_cooling_device_cb(struct thermal_zone_device 
> *thermal,
> @@ -812,7 +809,8 @@ static struct thermal_zone_device_ops 
> acpi_thermal_zone_ops = {
>   .get_trip_temp = thermal_get_trip_temp,
>   .get_crit_temp = thermal_get_crit_temp,
>   .get_trend = thermal_get_trend,
> - .notify = thermal_notify,
> + .hot = acpi_thermal_zone_device_hot,
> + .critical = acpi_thermal_zone_device_critical,
>  };
>  
>  static int acpi_thermal_register_thermal_zone(struct acpi_thermal *tz)
> 


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

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH] fs: ext4: remove unnecessary wbc parameter from ext4_bio_write_page

[Theodore Y. Ts'o]

On Fri, Dec 11, 2020 at 02:54:24PM +0800, chenle...@gmail.com wrote:
> From: Lei Chen 
> 
> ext4_bio_write_page does not need wbc parameter, since its parameter
> io contains the io_wbc field. The io::io_wbc is initialized by
> ext4_io_submit_init which is called in ext4_writepages and
> ext4_writepage functions prior to ext4_bio_write_page.
> Therefor, when ext4_bio_write_page is called, wbc info
> has already been included in io parameter.
> 
> Signed-off-by: Lei Chen 

Thanks, applied.

- Ted

Re: [PATCH 2/3] usb: xhci-mtk: fix UAS issue by XHCI_BROKEN_STREAMS quirk

[Chunfeng Yun]

On Thu, 2020-12-17 at 11:32 +0800, Nicolas Boichat wrote:
> On Thu, Dec 17, 2020 at 10:19 AM Chunfeng Yun  
> wrote:
> >
> > On Wed, 2020-12-16 at 20:28 +0800, Nicolas Boichat wrote:
> > > On Wed, Dec 16, 2020 at 7:53 PM Chunfeng Yun  
> > > wrote:
> > > >
> > > > The 0.96 xHCI controller on some platforms does not support
> > > > bulk stream even HCCPARAMS says supporting, due to MaxPSASize
> > > > is set a non-zero default value by mistake, here use
> > > > XHCI_BROKEN_STREAMS quirk to fix it.
> > > >
> > > > Fixes: 94a631d91ad3 ("usb: xhci-mtk: check hcc_params after adding 
> > > > primary hcd")
> > > > Signed-off-by: Chunfeng Yun 
> > > > ---
> > > >  drivers/usb/host/xhci-mtk.c | 7 ++-
> > > >  drivers/usb/host/xhci-mtk.h | 1 +
> > > >  2 files changed, 7 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
> > > > index 8f321f39ab96..08dab974d847 100644
> > > > --- a/drivers/usb/host/xhci-mtk.c
> > > > +++ b/drivers/usb/host/xhci-mtk.c
> > > > @@ -395,6 +395,9 @@ static void xhci_mtk_quirks(struct device *dev, 
> > > > struct xhci_hcd *xhci)
> > > > xhci->quirks |= XHCI_SPURIOUS_SUCCESS;
> > > > if (mtk->lpm_support)
> > > > xhci->quirks |= XHCI_LPM_SUPPORT;
> > > > +
> > > > +   if (mtk->broken_streams)
> > > > +   xhci->quirks |= XHCI_BROKEN_STREAMS;
> > > >  }
> > > >
> > > >  /* called during probe() after chip reset completes */
> > > > @@ -460,6 +463,8 @@ static int xhci_mtk_probe(struct platform_device 
> > > > *pdev)
> > > > return ret;
> > > >
> > > > mtk->lpm_support = of_property_read_bool(node, 
> > > > "usb3-lpm-capable");
> > > > +   mtk->broken_streams =
> > > > +   of_property_read_bool(node, 
> > > > "mediatek,broken_streams_quirk");
> > >
> > > Would it be better to add a data field to struct of_device_id
> > > mtk_xhci_of_match, and enable this quirk on mediatek,mt8173-xhci only?
> > This is the common issue for all SoCs (before 2016.06) with 0.96 xHCI
> > when the controller don't support bulk stream. If enable this quirk only
> > for mt8173, then for other SoCs, the compatible need include
> > "mediatek,mt8173-xhci" in dts, this may be not flexible for some cases,
> > e.g. a new SoC has the broken stream as mt8173, but also has another
> > different quirk, the way you suggested will not handle it.
> 
> It can, we do this regularly for many other components. One example:
> https://elixir.bootlin.com/linux/latest/source/drivers/i2c/busses/i2c-mt65xx.c#L402
> 
Got it. Indeed works when add compatible private data.

Due to many SoCs supports USB and not upstream, I'd prefer to avoid
adding new compatible in driver when support new SoCs, and leave the
code as simple as possible.

> > And I plan to remove "mediatek,mt8173-xhci" in mtk_xhci_of_match after
> > converting the binding to YMAL.
> >
> > >
> > > (IMHO usb3-lpm-capable detection should also be done in the same way)
> > I prefer to provide a property for common issues, and use the way you
> > suggested for the issue only happened at a specific SoC.
> 
> Understand, it's just different approaches, 
Yes

> there seems to be
> precedent (at least in this driver/binding) for using properties, so
> I'll let the USB maintainers speak up ,-)
> 
> >
> > Thank you
> >
> > >
> > > Thanks,
> > >
> > > > /* optional property, ignore the error if it does not exist */
> > > > of_property_read_u32(node, "mediatek,u3p-dis-msk",
> > > >  >u3p_dis_msk);
> > > > @@ -546,7 +551,7 @@ static int xhci_mtk_probe(struct platform_device 
> > > > *pdev)
> > > > if (ret)
> > > > goto put_usb3_hcd;
> > > >
> > > > -   if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
> > > > +   if (!mtk->broken_streams && HCC_MAX_PSA(xhci->hcc_params) >= 4)
> > > > xhci->shared_hcd->can_do_streams = 1;
> > > >
> > > > ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
> > > > diff --git a/drivers/usb/host/xhci-mtk.h b/drivers/usb/host/xhci-mtk.h
> > > > index a93cfe817904..86aa4978915e 100644
> > > > --- a/drivers/usb/host/xhci-mtk.h
> > > > +++ b/drivers/usb/host/xhci-mtk.h
> > > > @@ -147,6 +147,7 @@ struct xhci_hcd_mtk {
> > > > struct phy **phys;
> > > > int num_phys;
> > > > bool lpm_support;
> > > > +   bool broken_streams;
> > > > /* usb remote wakeup */
> > > > bool uwk_en;
> > > > struct regmap *uwk;
> > > > --
> > > > 2.18.0
> >

Re: Re: Subject: [PATCH v14 1/3] scsi: ufs: Introduce HPB feature

[Greg KH]

On Thu, Dec 17, 2020 at 02:21:36PM +0900, Daejun Park wrote:
> On Wed, Dec 16, 2020 at 11:45:32AM +0900, Daejun Park wrote:
> > > This is a patch for the HPB initialization and adds HPB function calls to
> > > UFS core driver.
> > 
> > 
> > 
> > Your "subject" is odd, it has "Subject:" in it twice, did git
> > format-patch create that?
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Sorry, It is my mistake.
> Should I resend this patch with proper subject?

Eventually yes.  Nothing anyone can do with this before 5.11-rc1 is out
anyway, so you might want to wait.

thanks,

greg k-h

Re: [RFC PATCH v1 7/7] powerpc/bpf: Implement extended BPF on PPC32

[Alexei Starovoitov]

On Wed, Dec 16, 2020 at 10:07:37AM +, Christophe Leroy wrote:
> Implement Extended Berkeley Packet Filter on Powerpc 32
> 
> Test result with test_bpf module:
> 
>   test_bpf: Summary: 378 PASSED, 0 FAILED, [354/366 JIT'ed]

nice!

> Registers mapping:
> 
>   [BPF_REG_0] = r11-r12
>   /* function arguments */
>   [BPF_REG_1] = r3-r4
>   [BPF_REG_2] = r5-r6
>   [BPF_REG_3] = r7-r8
>   [BPF_REG_4] = r9-r10
>   [BPF_REG_5] = r21-r22 (Args 9 and 10 come in via the stack)
>   /* non volatile registers */
>   [BPF_REG_6] = r23-r24
>   [BPF_REG_7] = r25-r26
>   [BPF_REG_8] = r27-r28
>   [BPF_REG_9] = r29-r30
>   /* frame pointer aka BPF_REG_10 */
>   [BPF_REG_FP] = r31
>   /* eBPF jit internal registers */
>   [BPF_REG_AX] = r19-r20
>   [TMP_REG] = r18
> 
> As PPC32 doesn't have a redzone in the stack,
> use r17 as tail call counter.
> 
> r0 is used as temporary register as much as possible. It is referenced
> directly in the code in order to avoid misuse of it, because some
> instructions interpret it as value 0 instead of register r0
> (ex: addi, addis, stw, lwz, ...)
> 
> The following operations are not implemented:
> 
>   case BPF_ALU64 | BPF_DIV | BPF_X: /* dst /= src */
>   case BPF_ALU64 | BPF_MOD | BPF_X: /* dst %= src */
>   case BPF_STX | BPF_XADD | BPF_DW: /* *(u64 *)(dst + off) += src 
> */
> 
> The following operations are only implemented for power of two constants:
> 
>   case BPF_ALU64 | BPF_MOD | BPF_K: /* dst %= imm */
>   case BPF_ALU64 | BPF_DIV | BPF_K: /* dst /= imm */

Those are sensible limitations. MOD and DIV are rare, but XADD is common.
Please consider doing it as a cmpxchg loop in the future.

Also please run test_progs. It will give a lot better coverage than test_bpf.ko

Re: [PATCH v2, 2/2] soc: mediatek: mmsys: Use function call for setting the routing registers

[Hsin-Yi Wang]

On Wed, Dec 9, 2020 at 9:32 AM Yongqiang Niu  wrote:
>
> Actually, setting the registers for routing, use multiple 'if-else' for 
> different
> routes, but this code would be more and more complicated while we
> support more and more SoCs. Change that and use a function call per SoC so the
> code will be more portable and clear.
>
> Signed-off-by: Yongqiang Niu 
> ---
>  drivers/soc/mediatek/mmsys/Makefile   |   3 +-
>  drivers/soc/mediatek/mmsys/mt2701-mmsys.c | 233 +
>  drivers/soc/mediatek/mmsys/mtk-mmsys.c| 241 
> +++---
>  include/linux/soc/mediatek/mtk-mmsys.h|  14 ++
>  4 files changed, 268 insertions(+), 223 deletions(-)
>  create mode 100644 drivers/soc/mediatek/mmsys/mt2701-mmsys.c
>
> diff --git a/drivers/soc/mediatek/mmsys/Makefile 
> b/drivers/soc/mediatek/mmsys/Makefile
> index 5d976d7..ac03025 100644
> --- a/drivers/soc/mediatek/mmsys/Makefile
> +++ b/drivers/soc/mediatek/mmsys/Makefile
> @@ -1,2 +1,3 @@
>  # SPDX-License-Identifier: GPL-2.0-only
> -obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o
> \ No newline at end of file
> +obj-$(CONFIG_MTK_MMSYS) += mt2701-mmsys.o
> +obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o
> diff --git a/drivers/soc/mediatek/mmsys/mt2701-mmsys.c 
> b/drivers/soc/mediatek/mmsys/mt2701-mmsys.c
> new file mode 100644
> index 000..40576d3
> --- /dev/null
> +++ b/drivers/soc/mediatek/mmsys/mt2701-mmsys.c
> @@ -0,0 +1,233 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2020 MediaTek Inc.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DISP_REG_CONFIG_DISP_OVL0_MOUT_EN  0x040
> +#define DISP_REG_CONFIG_DISP_OVL1_MOUT_EN  0x044
> +#define DISP_REG_CONFIG_DISP_OD_MOUT_EN0x048
> +#define DISP_REG_CONFIG_DISP_GAMMA_MOUT_EN 0x04c
> +#define DISP_REG_CONFIG_DISP_UFOE_MOUT_EN  0x050
> +#define DISP_REG_CONFIG_DISP_COLOR0_SEL_IN 0x084
> +#define DISP_REG_CONFIG_DISP_COLOR1_SEL_IN 0x088
> +#define DISP_REG_CONFIG_DSIE_SEL_IN0x0a4
> +#define DISP_REG_CONFIG_DSIO_SEL_IN0x0a8
> +#define DISP_REG_CONFIG_DPI_SEL_IN 0x0ac
> +#define DISP_REG_CONFIG_DISP_RDMA2_SOUT0x0b8
> +#define DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN 0x0c4
> +#define DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN 0x0c8
> +#define DISP_REG_CONFIG_MMSYS_CG_CON0  0x100
> +
> +#define DISP_REG_CONFIG_DISP_OVL_MOUT_EN   0x030
> +#define DISP_REG_CONFIG_OUT_SEL0x04c
> +#define DISP_REG_CONFIG_DSI_SEL0x050
> +#define DISP_REG_CONFIG_DPI_SEL0x064
> +
> +#define OVL0_MOUT_EN_COLOR00x1
> +#define OD_MOUT_EN_RDMA0   0x1
> +#define OD1_MOUT_EN_RDMA1  BIT(16)
> +#define UFOE_MOUT_EN_DSI0  0x1
> +#define COLOR0_SEL_IN_OVL0 0x1
> +#define OVL1_MOUT_EN_COLOR10x1
> +#define GAMMA_MOUT_EN_RDMA10x1
> +#define RDMA0_SOUT_DPI00x2
> +#define RDMA0_SOUT_DPI10x3
> +#define RDMA0_SOUT_DSI10x1
> +#define RDMA0_SOUT_DSI20x4
> +#define RDMA0_SOUT_DSI30x5
> +#define RDMA1_SOUT_DPI00x2
> +#define RDMA1_SOUT_DPI10x3
> +#define RDMA1_SOUT_DSI10x1
> +#define RDMA1_SOUT_DSI20x4
> +#define RDMA1_SOUT_DSI30x5
> +#define RDMA2_SOUT_DPI00x2
> +#define RDMA2_SOUT_DPI10x3
> +#define RDMA2_SOUT_DSI10x1
> +#define RDMA2_SOUT_DSI20x4
> +#define RDMA2_SOUT_DSI30x5
> +#define DPI0_SEL_IN_RDMA1  0x1
> +#define DPI0_SEL_IN_RDMA2  0x3
> +#define DPI1_SEL_IN_RDMA1  (0x1 << 8)
> +#define DPI1_SEL_IN_RDMA2  (0x3 << 8)
> +#define DSI0_SEL_IN_RDMA1  0x1
> +#define DSI0_SEL_IN_RDMA2  0x4
> +#define DSI1_SEL_IN_RDMA1  0x1
> +#define DSI1_SEL_IN_RDMA2  0x4
> +#define DSI2_SEL_IN_RDMA1  (0x1 << 16)
> +#define DSI2_SEL_IN_RDMA2  (0x4 << 16)
> +#define DSI3_SEL_IN_RDMA1  (0x1 << 16)
> +#define DSI3_SEL_IN_RDMA2  (0x4 << 16)
> +#define COLOR1_SEL_IN_OVL1 0x1
> +
> +#define OVL_MOUT_EN_RDMA   0x1
> +#define BLS_TO_DSI_RDMA1_TO_DPI1   0x8
> +#define BLS_TO_DPI_RDMA1_TO_DSI0x2
> +#define DSI_SEL_IN_BLS 0x0
> +#define DPI_SEL_IN_BLS

Re: [PATCH] dt-bindings/display: abt,y030xx067a: Fix binding

[Sam Ravnborg]

On Thu, Dec 17, 2020 at 12:59:45AM +, Paul Cercueil wrote:
> The binding should use "unevaluatedProperties" instead of
> "additionalProperties", since it is a SPI device and may have
> SPI-related Device Tree properties, for instance the "spi-max-frequency"
> property that is present in the example.
> 
> Fixes: e366a644c69d ("dt-bindings: display: Add ABT Y030XX067A panel 
> bindings")
> Signed-off-by: Paul Cercueil 
Reviewed-by: Sam Ravnborg 

[GIT PULL] f2fs update for 5.11-rc1

[Jaegeuk Kim]

Hi Linus,

Could you please consider this pull request?

Thank you so much,

The following changes since commit 3cea11cd5e3b00d91caf0b4730194039b45c5891:

  Linux 5.10-rc2 (2020-11-01 14:43:51 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git 
tags/f2fs-for-5.11-rc1

for you to fetch changes up to 75e91c888989cf2df5c78b251b07de1f5052e30e:

  f2fs: compress: fix compression chksum (2020-12-10 09:13:53 -0800)


f2fs-for-5.11-rc1

In this round, we've made more work into per-file compression support. For
example, F2FS_IOC_GET|SET_COMPRESS_OPTION provides a way to change the
algorithm or cluster size per file. F2FS_IOC_COMPRESS|DECOMPRESS_FILE provides
a way to compress and decompress the existing normal files manually along with
a new mount option, compress_mode=fs|user, which can control who compresses the
data. Chao also added a checksum feature with a mount option so that we are able
to detect any corrupted cluster. In addition, Daniel contributed casefolding
with encryption patch, which will be used for Android devices.

Enhancement:
 - add ioctls and mount option to manage per-file compression feature
 - support casefolding with encryption
 - support checksum for compressed cluster
 - avoid IO starvation by replacing mutex with rwsem
 - add sysfs, max_io_bytes, to control max bio size

Bug fix:
 - fix use-after-free issue when compression and fsverity are enabled
 - fix consistency corruption during fault injection test
 - fix data offset for lseek
 - get rid of buffer_head which has 32bits limit in fiemap
 - fix some bugs in multi-partitions support
 - fix nat entry count calculation in shrinker
 - fix some stat information

And, we've refactored some logics and fix minor bugs as well.


Chao Yu (10):
  f2fs: fix to seek incorrect data offset in inline data file
  f2fs: move ioctl interface definitions to separated file
  f2fs: avoid unneeded data copy in f2fs_ioc_move_range()
  f2fs: fix compat F2FS_IOC_{MOVE,GARBAGE_COLLECT}_RANGE
  f2fs: fix to avoid REQ_TIME and CP_TIME collision
  f2fs: compress: support chksum
  f2fs: fix kbytes written stat for multi-device case
  f2fs: fix to account inline xattr correctly during recovery
  f2fs: fix shift-out-of-bounds in sanity_check_raw_super()
  f2fs: compress: fix compression chksum

Daeho Jeong (5):
  f2fs: add F2FS_IOC_GET_COMPRESS_OPTION ioctl
  f2fs: add F2FS_IOC_SET_COMPRESS_OPTION ioctl
  f2fs: add compress_mode mount option
  f2fs: add F2FS_IOC_DECOMPRESS_FILE and F2FS_IOC_COMPRESS_FILE
  f2fs: fix race of pending_pages in decompression

Daniel Rosenberg (3):
  libfs: Add generic function for setting dentry_ops
  fscrypt: Have filesystems handle their d_ops
  f2fs: Handle casefolding with Encryption

Hyeongseok Kim (1):
  f2fs: fix double free of unicode map

Jack Qiu (3):
  f2fs: init dirty_secmap incorrectly
  f2fs: inline: correct comment in f2fs_recover_inline_data
  f2fs: inline: fix wrong inline inode stat

Jaegeuk Kim (8):
  f2fs: call f2fs_get_meta_page_retry for nat page
  f2fs: rename logical_to_blk and blk_to_logical
  f2fs: use new conversion functions between blks and bytes
  f2fs: fix wrong block count instead of bytes
  f2fs: remove buffer_head which has 32bits limit
  f2fs: avoid race condition for shrinker count
  f2fs: don't allow any writes on readonly mount
  f2fs: introduce max_io_bytes, a sysfs entry, to limit bio size

Liu Song (1):
  f2fs: remove writeback_inodes_sb in f2fs_remount

Sahitya Tummala (1):
  f2fs: change to use rwsem for cp_mutex

Yangtao Li (3):
  f2fs: Remove unnecessary unlikely()
  f2fs: convert to F2FS_*_INO macro
  f2fs: don't check PAGE_SIZE again in sanity_check_raw_super()

Zhang Qilong (1):
  f2fs: Remove the redundancy initialization

 Documentation/ABI/testing/sysfs-fs-f2fs |   7 +
 Documentation/filesystems/f2fs.rst  |  36 +++
 MAINTAINERS |   1 +
 fs/crypto/fname.c   |   4 -
 fs/crypto/fscrypt_private.h |   1 -
 fs/crypto/hooks.c   |   1 -
 fs/ext4/dir.c   |   7 -
 fs/ext4/ext4.h  |   4 -
 fs/ext4/namei.c |   1 +
 fs/ext4/super.c |   5 -
 fs/f2fs/acl.c   |   2 +-
 fs/f2fs/checkpoint.c|  39 ++-
 fs/f2fs/compress.c  |  26 +-
 fs/f2fs/compress.h  |   0
 fs/f2fs/data.c  | 211 +---
 fs/f2fs/debug.c |  11 +-
 fs/f2fs/dir.c   | 105 +---
 fs/f2fs/f2fs.h  | 181 ++
 fs/f2fs/file.c   

Re: [PATCH v2 3/3] thermal/core: Remove ms based delay fields

[Daniel Lezcano]

On 16/12/2020 23:35, Peter Kästle wrote:
> 16. Dezember 2020 23:04, "Daniel Lezcano"  schrieb:
> 
>> The code does no longer use the ms unit based fields to set the
>> delays as they are replaced by the jiffies.
>>
>> Remove them and replace their user to use the jiffies version instead.
>>
>> Cc: Thara Gopinath 
>> Signed-off-by: Daniel Lezcano 
>> Reviewed-by: Lukasz Luba 
>> ---
>> drivers/platform/x86/acerhdf.c | 3 ++-
> 
> Reviewed-by: Peter Kästle 

Thanks for reviewing

  -- Daniel


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

Follow Linaro:   Facebook |
 Twitter |
 Blog

linux-next: Tree for Dec 17

[Stephen Rothwell]

Hi all,

Please do not add any v5.12 destined code to your linux-next included
branches until after v5.11-rc1 has been released.

Changes since 20201216:

The watchdog tree still had its build failure so I used the version from
next-20201211.

The kvm tree gained a conflict against Linus' tree.

Non-merge commits (relative to Linus' tree): 4083
 3692 files changed, 14 insertions(+), 56131 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig and htmldocs. And finally, a simple boot test
of the powerpc pseries_le_defconfig kernel in qemu (with and without
kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 327 trees (counting Linus' and 85 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (69f637c33560 Merge tag 'for-5.11/drivers-2020-12-14' of 
git://git.kernel.dk/linux-block)
Merging fixes/fixes (9223e74f9960 Merge tag 'io_uring-5.10-2020-11-27' of 
git://git.kernel.dk/linux-block)
Merging kbuild-current/fixes (7d32358be8ac kbuild: avoid split lines in .mod 
files)
Merging arc-current/for-curr (3a71e423133a ARC: build: use $(READELF) instead 
of hard-coded readelf)
Merging arm-current/fixes (e64ab473ddda ARM: 9034/1: __div64_32(): straighten 
up inline asm constraints)
Merging arm64-fixes/for-next/fixes (31f80a4e9603 arm64: Warn the user when a 
small VA_BITS value wastes memory)
Merging arm-soc-fixes/arm/fixes (43ffe817bfe3 arm64: dts: bitmain: Use generic 
"ngpios" rather than "snps,nr-gpios")
Merging drivers-memory-fixes/fixes (3650b228f83a Linux 5.10-rc1)
Merging m68k-current/for-linus (2ae92e8b9b7e MAINTAINERS: Update m68k Mac entry)
Merging powerpc-fixes/fixes (5eedf9fe8db2 powerpc/mm: Fix KUAP warning by 
providing copy_from_kernel_nofault_allowed())
Merging s390-fixes/fixes (586592478b1f Merge tag 's390-5.11-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux)
Merging sparc/master (0a95a6d1a4cd sparc: use for_each_child_of_node() macro)
Merging fscrypt-current/for-stable (d19d8d345eec fscrypt: fix inline encryption 
not used on new files)
Merging net/master (ef72cd3c5ce1 ethtool: fix error paths in 
ethnl_set_channels())
Merging bpf/master (1a3449c19407 selftests/bpf: Clarify build error if no 
vmlinux)
Merging ipsec/master (7f376f1917d7 Merge tag 'mtd/fixes-for-5.10-rc8' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux)
Merging netfilter/master (3db1a3fa9880 Merge tag 'staging-5.11-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging)
Merging ipvs/master (3db1a3fa9880 Merge tag 'staging-5.11-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging)
Merging wireless-drivers/master (74a8c816fa8f rtw88: debug: Fix uninitialized 
memory in debugfs code)
Merging mac80211/master (2c85ebc57b3e Linux 5.10)
Merging rdma-fixes/for-rc (340b940ea0ed RDMA/cm: Fix an attempt to use 
non-valid pointer when cleaning timewait)
Merging sound-current/for-linus (598100be3053 Merge tag 'asoc-v5.11' of 
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging sound-asoc-fixes/for-linus (20b7445d8aa1 Merge remote-tracking branch 
'asoc/for-5.11' into asoc-linus)
Merging regmap-fixes/for-linus (e6e9354b5830 regmap: Remove duplicate `type` 
field from regmap `regcache_sync` trace event)
Merging regulator-fixes/for-linus (87a96de608de Merge remote-tracking branch 
'regulator/for-5.11' into regulator-linus)
Merging spi-fixes/for-linus (58f7553fa424 Mer

[PATCH v3 3/3] Documentation: fpga: dfl: Add description for DFL UIO support

[Xu Yilun]

This patch adds description for UIO support for dfl devices on DFL
bus.

Signed-off-by: Xu Yilun 
---
v2: no doc in v1, add it for v2.
v3: some documentation fixes.
---
 Documentation/fpga/dfl.rst | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst
index 0404fe6..b298ad9 100644
--- a/Documentation/fpga/dfl.rst
+++ b/Documentation/fpga/dfl.rst
@@ -7,6 +7,7 @@ Authors:
 - Enno Luebbers 
 - Xiao Guangrong 
 - Wu Hao 
+- Xu Yilun 
 
 The Device Feature List (DFL) FPGA framework (and drivers according to
 this framework) hides the very details of low layer hardwares and provides
@@ -502,6 +503,32 @@ FME Partial Reconfiguration Sub Feature driver (see 
drivers/fpga/dfl-fme-pr.c)
 could be a reference.
 
 
+UIO support for DFL devices
+===
+The purpose of an FPGA is to be reprogrammed with newly developed hardware
+components. New hardware can instantiate a new private feature in the DFL, and
+then get a DFL device in their system. In some cases users may need a userspace
+driver for the DFL device:
+
+* Users may need to run some diagnostic test for their hardwares.
+* Users may prototype the kernel driver in user space.
+* Some hardware is designed for specific purposes and does not fit into one of
+  the standard kernel subsystems.
+
+This requires the direct access to the MMIO space and interrupt handling in
+userspace. The dfl-uio-pdev module exposes the UIO device interfaces for this
+purpose. It adds the uio_pdrv_genirq platform device with the resources of
+the DFL feature, and lets the generic UIO platform device driver provide UIO
+support to userspace.
+
+FPGA_DFL_UIO_PDEV should be selected to enable this feature.
+
+The DFL UIO driver has a special matching algorithem. It will match any DFL
+device which could not be handled by other DFL drivers. In this way, it will
+not impact the functionality of the features which are already supported by the
+system.
+
+
 Open discussion
 ===
 FME driver exports one ioctl (DFL_FPGA_FME_PORT_PR) for partial reconfiguration
-- 
2.7.4

[PATCH v3 2/3] fpga: dfl: add the userspace I/O device support for DFL devices

[Xu Yilun]

This patch supports the DFL drivers be written in userspace. This is
realized by exposing the userspace I/O device interfaces.

The driver leverages the uio_pdrv_genirq, it adds the uio_pdrv_genirq
platform device with the DFL device's resources, and let the generic UIO
platform device driver provide support to userspace access to kernel
interrupts and memory locations.

The driver matches DFL devices in a different way. It has no device id
table, instead it matches any DFL device which could not be handled by
other DFL drivers.

Signed-off-by: Xu Yilun 
---
v2: switch to the new matching algorithem. It matches DFL devices which
 could not be handled by other DFL drivers.
refacor the code about device resources filling.
fix some comments.
v3: split the dfl.c changes out of this patch.
some minor fixes
---
 drivers/fpga/Kconfig|  10 
 drivers/fpga/Makefile   |   1 +
 drivers/fpga/dfl-uio-pdev.c | 110 
 3 files changed, 121 insertions(+)
 create mode 100644 drivers/fpga/dfl-uio-pdev.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 5d7f0ae..7a88af9 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -202,6 +202,16 @@ config FPGA_DFL_NIOS_INTEL_PAC_N3000
  the card. It also instantiates the SPI master (spi-altera) for
  the card's BMC (Board Management Controller).
 
+config FPGA_DFL_UIO_PDEV
+   tristate "FPGA DFL Driver for Userspace I/O platform devices"
+   depends on FPGA_DFL && UIO_PDRV_GENIRQ
+   help
+ Enable this to allow some DFL drivers be written in userspace. It
+ adds the uio_pdrv_genirq platform device with the DFL feature's
+ resources, and lets the generic UIO platform device driver provide
+ support for userspace access to kernel interrupts and memory
+ locations.
+
 config FPGA_DFL_PCI
tristate "FPGA DFL PCIe Device Driver"
depends on PCI && FPGA_DFL
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 18dc9885..8847fe0 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -45,6 +45,7 @@ dfl-afu-objs := dfl-afu-main.o dfl-afu-region.o 
dfl-afu-dma-region.o
 dfl-afu-objs += dfl-afu-error.o
 
 obj-$(CONFIG_FPGA_DFL_NIOS_INTEL_PAC_N3000)+= dfl-n3000-nios.o
+obj-$(CONFIG_FPGA_DFL_UIO_PDEV)+= dfl-uio-pdev.o
 
 # Drivers for FPGAs which implement DFL
 obj-$(CONFIG_FPGA_DFL_PCI) += dfl-pci.o
diff --git a/drivers/fpga/dfl-uio-pdev.c b/drivers/fpga/dfl-uio-pdev.c
new file mode 100644
index 000..8c57233
--- /dev/null
+++ b/drivers/fpga/dfl-uio-pdev.c
@@ -0,0 +1,110 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DFL driver for Userspace I/O platform devices
+ *
+ * Copyright (C) 2020 Intel Corporation, Inc.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "dfl.h"
+
+#define DRIVER_NAME "dfl-uio-pdev"
+
+static struct dfl_driver dfl_uio_pdev_driver;
+
+static int check_for_other_drv_match(struct device_driver *drv, void *data)
+{
+   struct dfl_driver *ddrv = to_dfl_drv(drv);
+   struct dfl_device *ddev = data;
+
+   /* skip myself */
+   if (ddrv == _uio_pdev_driver)
+   return 0;
+
+   return dfl_match_device(ddev, ddrv);
+}
+
+static int dfl_uio_pdev_match(struct dfl_device *ddev)
+{
+   /*
+* If any other driver wants the device, leave the device to this other
+* driver.
+*/
+   if (bus_for_each_drv(_bus_type, NULL, ddev, 
check_for_other_drv_match))
+   return 0;
+
+   return 1;
+}
+
+static int dfl_uio_pdev_probe(struct dfl_device *ddev)
+{
+   struct device *dev = >dev;
+   struct platform_device_info pdevinfo = { 0 };
+   struct uio_info uio_pdata = { 0 };
+   struct platform_device *uio_pdev;
+   struct resource *res;
+   int i;
+
+   pdevinfo.name = "uio_pdrv_genirq";
+
+   res = kcalloc(ddev->num_irqs + 1, sizeof(*res), GFP_KERNEL);
+   if (!res)
+   return -ENOMEM;
+
+   res[0].parent = >mmio_res;
+   res[0].flags = IORESOURCE_MEM;
+   res[0].start = ddev->mmio_res.start;
+   res[0].end = ddev->mmio_res.end;
+
+   /* then add irq resource */
+   for (i = 0; i < ddev->num_irqs; i++) {
+   res[i + 1].flags = IORESOURCE_IRQ;
+   res[i + 1].start = ddev->irqs[i];
+   res[i + 1].end = ddev->irqs[i];
+   }
+
+   uio_pdata.name = DRIVER_NAME;
+   uio_pdata.version = "0";
+
+   pdevinfo.res = res;
+   pdevinfo.num_res = ddev->num_irqs + 1;
+   pdevinfo.parent = >dev;
+   pdevinfo.id = PLATFORM_DEVID_AUTO;
+   pdevinfo.data = _pdata;
+   pdevinfo.size_data = sizeof(uio_pdata);
+
+   uio_pdev = platform_device_register_full();
+   if (!IS_ERR(uio_pdev))
+   dev_set_drvdata(dev, uio_pdev);
+
+   kfree(res);
+
+   return PTR_ERR_OR_ZERO(uio_pdev);
+}
+
+static void 

[PATCH v3 1/3] fpga: dfl: add the match() ops for dfl driver

[Xu Yilun]

The match ops allows dfl drivers have their own matching algorithem
instead of the standard id_table matching.

This is to support the DFL UIO driver. It intends to match any DFL
device which could not be handled by other DFL drivers.

Signed-off-by: Xu Yilun 
---
v3: this patch is splited out from DFL UIO patch.
move the declarations of exported symbols from include/linux/dfl.h
 to driver/fpga/dfl.h
fix some comments.
---
 drivers/fpga/dfl.c  | 22 +-
 drivers/fpga/dfl.h  |  5 +
 include/linux/dfl.h |  3 +++
 3 files changed, 25 insertions(+), 5 deletions(-)

diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
index 511b20f..dd90111 100644
--- a/drivers/fpga/dfl.c
+++ b/drivers/fpga/dfl.c
@@ -256,12 +256,13 @@ dfl_match_one_device(const struct dfl_device_id *id, 
struct dfl_device *ddev)
return NULL;
 }
 
-static int dfl_bus_match(struct device *dev, struct device_driver *drv)
+int dfl_match_device(struct dfl_device *ddev, struct dfl_driver *ddrv)
 {
-   struct dfl_device *ddev = to_dfl_dev(dev);
-   struct dfl_driver *ddrv = to_dfl_drv(drv);
const struct dfl_device_id *id_entry;
 
+   if (ddrv->match)
+   return ddrv->match(ddev);
+
id_entry = ddrv->id_table;
if (id_entry) {
while (id_entry->feature_id) {
@@ -275,6 +276,15 @@ static int dfl_bus_match(struct device *dev, struct 
device_driver *drv)
 
return 0;
 }
+EXPORT_SYMBOL_GPL(dfl_match_device);
+
+static int dfl_bus_match(struct device *dev, struct device_driver *drv)
+{
+   struct dfl_device *ddev = to_dfl_dev(dev);
+   struct dfl_driver *ddrv = to_dfl_drv(drv);
+
+   return dfl_match_device(ddev, ddrv);
+}
 
 static int dfl_bus_probe(struct device *dev)
 {
@@ -328,7 +338,7 @@ static struct attribute *dfl_dev_attrs[] = {
 };
 ATTRIBUTE_GROUPS(dfl_dev);
 
-static struct bus_type dfl_bus_type = {
+struct bus_type dfl_bus_type = {
.name   = "dfl",
.match  = dfl_bus_match,
.probe  = dfl_bus_probe,
@@ -336,6 +346,7 @@ static struct bus_type dfl_bus_type = {
.uevent = dfl_bus_uevent,
.dev_groups = dfl_dev_groups,
 };
+EXPORT_SYMBOL_GPL(dfl_bus_type);
 
 static void release_dfl_dev(struct device *dev)
 {
@@ -469,7 +480,8 @@ static int dfl_devs_add(struct dfl_feature_platform_data 
*pdata)
 
 int __dfl_driver_register(struct dfl_driver *dfl_drv, struct module *owner)
 {
-   if (!dfl_drv || !dfl_drv->probe || !dfl_drv->id_table)
+   if (!dfl_drv || !dfl_drv->probe ||
+   (!dfl_drv->id_table && !dfl_drv->match))
return -EINVAL;
 
dfl_drv->drv.owner = owner;
diff --git a/drivers/fpga/dfl.h b/drivers/fpga/dfl.h
index 2b82c96..01c43d8 100644
--- a/drivers/fpga/dfl.h
+++ b/drivers/fpga/dfl.h
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -517,4 +518,8 @@ long dfl_feature_ioctl_set_irq(struct platform_device *pdev,
   struct dfl_feature *feature,
   unsigned long arg);
 
+extern struct bus_type dfl_bus_type;
+
+int dfl_match_device(struct dfl_device *ddev, struct dfl_driver *ddrv);
+
 #endif /* __FPGA_DFL_H */
diff --git a/include/linux/dfl.h b/include/linux/dfl.h
index 6cc1098..cfd98a4 100644
--- a/include/linux/dfl.h
+++ b/include/linux/dfl.h
@@ -51,6 +51,8 @@ struct dfl_device {
  * @drv: driver model structure.
  * @id_table: pointer to table of device IDs the driver is interested in.
  *   { } member terminated.
+ * @match: returns one if given device can be handled by the driver and zero
+ *otherwise. If NULL, matching is based on id_table.
  * @probe: mandatory callback for device binding.
  * @remove: callback for device unbinding.
  */
@@ -58,6 +60,7 @@ struct dfl_driver {
struct device_driver drv;
const struct dfl_device_id *id_table;
 
+   int (*match)(struct dfl_device *dfl_dev);
int (*probe)(struct dfl_device *dfl_dev);
void (*remove)(struct dfl_device *dfl_dev);
 };
-- 
2.7.4

[PATCH v5 0/4] gpio: visconti: Add Toshiba Visconti GPIO support

[Nobuhiro Iwamatsu]

Hi,

This series is the GPIO driver for Toshiba's ARM SoC, Visconti[0].
This provides DT binding documentation, device driver, MAINTAINER files, and 
updates to DT files.

Best regards,
  Nobuhiro

[0]: 
https://toshiba.semicon-storage.com/ap-en/semiconductor/product/image-recognition-processors-visconti.html

dt-bindings: gpio: Add bindings for Toshiba Visconti GPIO Controller:
  v4 -> v5: Drop interrupts property.
Add interrupts-parrent property.
  v3 -> v4: Add Reviewed-by tag.
  v2 -> v3: Fix dtschema/dtc warnings.
dtschema/dtc warnings/errors:
  
Documentation/devicetree/bindings/gpio/toshiba,gpio-visconti.example.dt.yaml: 
gpio@2802: interrupts: [[0, 24, 4], [0, 25, 4], [0, 26, 4], [0, 27, 4], [0, 
28, 4], [0, 29, 4], [0, 30, 4], [0, 31, 4], [0, 32, 4], [0, 33, 4], [0, 34, 4], 
[0, 35, 4], [0, 36, 4], [0, 37, 4], [0, 38, 4], [0, 39, 4]] is too short
From schema: 
Documentation/devicetree/bindings/gpio/toshiba,gpio-visconti.yaml
  v1 -> v2: Fix typo.

gpio: visoconti: Add Toshiba Visconti GPIO support:
  v4 -> v5: Add IRQ_DOMAIN_HIERARCH to Kconfig
Updated for using hierarchical irqs.
  v3 -> v4: Drop VISCONTI_GPIO_NR.
Fix return code of platform_irq_count.
Fix coprytight header.
Add Reviewed-by tag.
  v2 -> v3: Add select GPIO_GENERIC
Use genric MMIO GPIO library
Use bgpio_init() as initialized the generic helpers.
Use irqchip template instead of gpiochip_irqchip_add().
  v1 -> v2: No update

MAINTAINERS: Add entries for Toshiba Visconti GPIO controller:
  v4 -> v5: No update
  v3 -> v4: No update
  v2 -> v3: No update
  v1 -> v2: No update

arm: dts: visconti: Add DT support for Toshiba Visconti5 GPIO driver:
  v4 -> v5: Drop interrupts property.
Add interrupts-parrent property.
  v3 -> v4: Add Reviewed-by tag.
  v2 -> v3: Fix compatible string.
  v1 -> v2: No update

Nobuhiro Iwamatsu (4):
  dt-bindings: gpio: Add bindings for Toshiba Visconti GPIO Controller
  gpio: visconti: Add Toshiba Visconti GPIO support
  MAINTAINERS: Add entries for Toshiba Visconti GPIO controller
  arm: dts: visconti: Add DT support for Toshiba Visconti5 GPIO driver

 .../bindings/gpio/toshiba,gpio-visconti.yaml  |  70 ++
 MAINTAINERS   |   2 +
 .../boot/dts/toshiba/tmpv7708-rm-mbrc.dts |   4 +
 arch/arm64/boot/dts/toshiba/tmpv7708.dtsi |  11 +
 drivers/gpio/Kconfig  |  10 +
 drivers/gpio/Makefile |   1 +
 drivers/gpio/gpio-visconti.c  | 218 ++
 drivers/pinctrl/visconti/pinctrl-common.c |  23 ++
 8 files changed, 339 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/gpio/toshiba,gpio-visconti.yaml
 create mode 100644 drivers/gpio/gpio-visconti.c

-- 
2.29.2

[PATCH v3 0/3] UIO support for dfl devices

[Xu Yilun]

This patchset supports some dfl device drivers written in userspace.

In the patchset v1, the "driver_override" interface should be used to bind
the DFL UIO driver to DFL devices. But there is concern that the
"driver_override" interface is not OK itself. So in v2, we use a new
matching algorithem. The "driver_override" interface is abandoned, the DFL
UIO driver matches any DFL device which could not be handled by other DFL
drivers. So the DFL UIO driver could be used for new DFL devices which are
not supported by kernel, also it will not impact the devices which are
already got supported.

Main changes from v1:
- switch to the new matching algorithem. It matches DFL devices which could
  not be handled by other DFL drivers.
- refacor the code about device resources filling.
- add the documentation.

Main changes from v2:
- split the match ops changes in dfl.c to an independent patch.
- move the declarations needed for dfl-uio-pdev from include/linux/dfl.h
  to driver/fpga/dfl.h
- some minor fixes.


Xu Yilun (3):
  fpga: dfl: add the match() ops for dfl driver
  fpga: dfl: add the userspace I/O device support for DFL devices
  Documentation: fpga: dfl: Add description for DFL UIO support

 Documentation/fpga/dfl.rst  |  27 +++
 drivers/fpga/Kconfig|  10 
 drivers/fpga/Makefile   |   1 +
 drivers/fpga/dfl-uio-pdev.c | 110 
 drivers/fpga/dfl.c  |  22 +++--
 drivers/fpga/dfl.h  |   5 ++
 include/linux/dfl.h |   3 ++
 7 files changed, 173 insertions(+), 5 deletions(-)
 create mode 100644 drivers/fpga/dfl-uio-pdev.c

-- 
2.7.4

[PATCH v5 1/4] dt-bindings: gpio: Add bindings for Toshiba Visconti GPIO Controller

[Nobuhiro Iwamatsu]

Add bindings for the Toshiba Visconti GPIO Controller.

Signed-off-by: Nobuhiro Iwamatsu 
Reviewed-by: Rob Herring 
Reviewed-by: Punit Agrawal 
---
 .../bindings/gpio/toshiba,gpio-visconti.yaml  | 70 +++
 1 file changed, 70 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/gpio/toshiba,gpio-visconti.yaml

diff --git a/Documentation/devicetree/bindings/gpio/toshiba,gpio-visconti.yaml 
b/Documentation/devicetree/bindings/gpio/toshiba,gpio-visconti.yaml
new file mode 100644
index ..9ad470e01953
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/toshiba,gpio-visconti.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/toshiba,gpio-visconti.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Toshiba Visconti ARM SoCs GPIO controller
+
+maintainers:
+  - Nobuhiro Iwamatsu 
+
+properties:
+  compatible:
+items:
+  - const: toshiba,gpio-tmpv7708
+
+  reg:
+maxItems: 1
+
+  "#gpio-cells":
+const: 2
+
+  gpio-ranges: true
+
+  gpio-controller: true
+
+  interrupt-controller: true
+
+  "#interrupt-cells":
+const: 2
+
+  interrupts:
+description:
+  interrupt mapping one per GPIO.
+minItems: 16
+maxItems: 16
+
+required:
+  - compatible
+  - reg
+  - "#gpio-cells"
+  - gpio-ranges
+  - gpio-controller
+  - interrupt-controller
+  - "#interrupt-cells"
+  - interrupt-parent
+
+additionalProperties: false
+
+examples:
+  - |
+  #include 
+  #include 
+
+  soc {
+#address-cells = <2>;
+#size-cells = <2>;
+
+gpio: gpio@2802 {
+  compatible = "toshiba,gpio-tmpv7708";
+  reg = <0 0x2802 0 0x1000>;
+  #gpio-cells = <0x2>;
+  gpio-ranges = < 0 0 32>;
+  gpio-controller;
+  interrupt-controller;
+  #interrupt-cells = <2>;
+  interrupt-parent = <>;
+};
+  };
+...
-- 
2.29.2

[PATCH v5 2/4] gpio: visconti: Add Toshiba Visconti GPIO support

[Nobuhiro Iwamatsu]

Add the GPIO driver for Toshiba Visconti ARM SoCs.

Signed-off-by: Nobuhiro Iwamatsu 
Reviewed-by: Punit Agrawal 
---
 drivers/gpio/Kconfig  |  10 +
 drivers/gpio/Makefile |   1 +
 drivers/gpio/gpio-visconti.c  | 218 ++
 drivers/pinctrl/visconti/pinctrl-common.c |  23 +++
 4 files changed, 252 insertions(+)
 create mode 100644 drivers/gpio/gpio-visconti.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 5d4de5cd6759..14151d67f0cc 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -631,6 +631,16 @@ config GPIO_VF610
help
  Say yes here to support Vybrid vf610 GPIOs.
 
+config GPIO_VISCONTI
+   tristate "Toshiba Visconti GPIO support"
+   depends on ARCH_VISCONTI || COMPILE_TEST
+   depends on OF_GPIO
+   select GPIOLIB_IRQCHIP
+   select GPIO_GENERIC
+   select IRQ_DOMAIN_HIERARCHY
+   help
+ Say yes here to support GPIO on Tohisba Visconti.
+
 config GPIO_VR41XX
tristate "NEC VR4100 series General-purpose I/O Uint support"
depends on CPU_VR41XX
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 09dada80ac34..02c9d8d83a54 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -162,6 +162,7 @@ obj-$(CONFIG_GPIO_UCB1400)  += gpio-ucb1400.o
 obj-$(CONFIG_GPIO_UNIPHIER)+= gpio-uniphier.o
 obj-$(CONFIG_GPIO_VF610)   += gpio-vf610.o
 obj-$(CONFIG_GPIO_VIPERBOARD)  += gpio-viperboard.o
+obj-$(CONFIG_GPIO_VISCONTI)+= gpio-visconti.o
 obj-$(CONFIG_GPIO_VR41XX)  += gpio-vr41xx.o
 obj-$(CONFIG_GPIO_VX855)   += gpio-vx855.o
 obj-$(CONFIG_GPIO_WCD934X) += gpio-wcd934x.o
diff --git a/drivers/gpio/gpio-visconti.c b/drivers/gpio/gpio-visconti.c
new file mode 100644
index ..0e3d19828eb1
--- /dev/null
+++ b/drivers/gpio/gpio-visconti.c
@@ -0,0 +1,218 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Toshiba Visconti GPIO Support
+ *
+ * (C) Copyright 2020 Toshiba Electronic Devices & Storage Corporation
+ * (C) Copyright 2020 TOSHIBA CORPORATION
+ *
+ * Nobuhiro Iwamatsu 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* register offset */
+#define GPIO_DIR   0x00
+#define GPIO_IDATA 0x08
+#define GPIO_ODATA 0x10
+#define GPIO_OSET  0x18
+#define GPIO_OCLR  0x20
+#define GPIO_INTMODE   0x30
+
+#define BASE_HW_IRQ 24
+
+struct visconti_gpio {
+   void __iomem *base;
+   spinlock_t lock; /* protect gpio register */
+   struct gpio_chip gpio_chip;
+   struct irq_chip irq_chip;
+};
+
+static int visconti_gpio_irq_set_type(struct irq_data *d, unsigned int type)
+{
+   struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+   struct visconti_gpio *priv = gpiochip_get_data(gc);
+   u32 offset = irqd_to_hwirq(d);
+   u32 bit = BIT(offset);
+   u32 intc_type = IRQ_TYPE_EDGE_RISING;
+   u32 intmode, odata;
+   int ret = 0;
+   unsigned long flags;
+
+   spin_lock_irqsave(>lock, flags);
+
+   odata = readl(priv->base + GPIO_ODATA);
+   intmode = readl(priv->base + GPIO_INTMODE);
+
+   switch (type) {
+   case IRQ_TYPE_EDGE_RISING:
+   odata &= ~bit;
+   intmode &= ~bit;
+   break;
+   case IRQ_TYPE_EDGE_FALLING:
+   odata |= bit;
+   intmode &= ~bit;
+   break;
+   case IRQ_TYPE_EDGE_BOTH:
+   intmode |= bit;
+   break;
+   case IRQ_TYPE_LEVEL_HIGH:
+   intc_type = IRQ_TYPE_LEVEL_HIGH;
+   odata &= ~bit;
+   intmode &= ~bit;
+   break;
+   case IRQ_TYPE_LEVEL_LOW:
+   intc_type = IRQ_TYPE_LEVEL_HIGH;
+   odata |= bit;
+   intmode &= ~bit;
+   break;
+   default:
+   ret = -EINVAL;
+   goto err;
+   }
+
+   writel(odata, priv->base + GPIO_ODATA);
+   writel(intmode, priv->base + GPIO_INTMODE);
+   irq_set_irq_type(offset, intc_type);
+
+   ret = irq_chip_set_type_parent(d, type);
+err:
+   spin_unlock_irqrestore(>lock, flags);
+   return ret;
+}
+
+static int visconti_gpio_child_to_parent_hwirq(struct gpio_chip *gc,
+  unsigned int child,
+  unsigned int child_type,
+  unsigned int *parent,
+  unsigned int *parent_type)
+{
+   /* Interrupts 0..15 mapped to interrupts 24..39 on the GIC */
+   if (child < 16) {
+   /* All these interrupts are level high in the CPU */
+   *parent_type = IRQ_TYPE_LEVEL_HIGH;
+   *parent = child + BASE_HW_IRQ;
+   return 0;
+   }
+   return -EINVAL;
+}
+
+static void 

[PATCH v5 4/4] arm: dts: visconti: Add DT support for Toshiba Visconti5 GPIO driver

[Nobuhiro Iwamatsu]

Add the GPIO node in Toshiba Visconti5 SoC-specific DT file.
And enable the GPIO node in TMPV7708 RM main board's board-specific DT file.

Signed-off-by: Nobuhiro Iwamatsu 
Reviewed-by: Punit Agrawal 
---
 arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts |  4 
 arch/arm64/boot/dts/toshiba/tmpv7708.dtsi| 11 +++
 2 files changed, 15 insertions(+)

diff --git a/arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts 
b/arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
index ed0bf7f13f54..950010a290f0 100644
--- a/arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
+++ b/arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
@@ -41,3 +41,7 @@  {
clocks = <_clk>;
clock-names = "apb_pclk";
 };
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm64/boot/dts/toshiba/tmpv7708.dtsi 
b/arch/arm64/boot/dts/toshiba/tmpv7708.dtsi
index 242f25f4e12a..17fdcbd4b075 100644
--- a/arch/arm64/boot/dts/toshiba/tmpv7708.dtsi
+++ b/arch/arm64/boot/dts/toshiba/tmpv7708.dtsi
@@ -157,6 +157,17 @@ pmux: pmux@2419 {
reg = <0 0x2419 0 0x1>;
};
 
+   gpio: gpio@2802 {
+   compatible = "toshiba,gpio-tmpv7708";
+   reg = <0 0x2802 0 0x1000>;
+   #gpio-cells = <0x2>;
+   gpio-ranges = < 0 0 32>;
+   gpio-controller;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   interrupt-parent = <>;
+   };
+
uart0: serial@2820 {
compatible = "arm,pl011", "arm,primecell";
reg = <0 0x2820 0 0x1000>;
-- 
2.29.2

[PATCH v5 3/4] MAINTAINERS: Add entries for Toshiba Visconti GPIO controller

[Nobuhiro Iwamatsu]

Add entries for Toshiba Visconti GPIO Controller binding and driver.

Signed-off-by: Nobuhiro Iwamatsu 
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 50fbbfffb921..8565272d95c4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2636,8 +2636,10 @@ L:   linux-arm-ker...@lists.infradead.org (moderated 
for non-subscribers)
 S: Supported
 T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/iwamatsu/linux-visconti.git
 F: Documentation/devicetree/bindings/arm/toshiba.yaml
+F: Documentation/devicetree/bindings/gpio/toshiba,gpio-visconti.yaml
 F: Documentation/devicetree/bindings/pinctrl/toshiba,tmpv7700-pinctrl.yaml
 F: arch/arm64/boot/dts/toshiba/
+F: drivers/gpio/gpio-visconti.c
 F: drivers/pinctrl/visconti/
 N: visconti
 
-- 
2.29.2

Re: [PATCH v3] lib: stackdepot: Add support to configure STACK_HASH_SIZE

[Vijayanand Jitta]

On 12/16/2020 7:04 PM, Alexander Potapenko wrote:
>>> To reiterate, I think you don't need a tunable stack_hash_order
>>> parameter if the only use case is to disable the stack depot.
>>> Maybe it is enough to just add a boolean flag?
>>
>> There are multiple users of stackdepot they might still want to use
>> stack depot but with a lower memory footprint instead of MAX_SIZE
>> so, a configurable size might help here ?
> 
> Can you provide an example of a use case in which the user wants to
> use the stack depot of a smaller size without disabling it completely,
> and that size cannot be configured statically?
> As far as I understand, for the page owner example you gave it's
> sufficient to provide a switch that can disable the stack depot if
> page_owner=off.
> 
There are two use cases here,

1. We don't want to consume memory when page_owner=off ,boolean flag
would work here.

2. We would want to enable page_owner on low ram devices but we don't
want stack depot to consume 8 MB of memory, so for this case we would
need a configurable stack_hash_size so that we can still use page_owner
with lower memory consumption.

So, a configurable stack_hash_size would work for both these use cases,
we can set it to '0' for first case and set the required size for the
second case.

>>> Or even go further and disable the stack depot in the same place that
>>> disables page owner, as the user probably doesn't want to set two
>>> flags instead of one?
>>>
>>
>> Since, page owner is not the only user of stack depot we can't take that
>> decision of disabling stack depot if page owner is disabled.
> 
> Agreed, but if multiple subsystems want to use stackdepot together, it
> is even harder to estimate the total memory consumption.
> How likely is it that none of them will need MAX_SIZE?
> 
 Minchan,
 This should be fine right ? Do you see any issue with disabling
 stack depot completely ?

 Thanks,
 Vijay

>> Thanks,
>> Vijay
>>
> Thanks,
> Vijay
>
>>> Thanks,
>>> Vijay
>>>
>>> --
>>> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
>>> member of Code Aurora Forum, hosted by The Linux Foundation
>>
>>
>>
>
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
> member of Code Aurora Forum, hosted by The Linux Foundation



>>>
>>
>> --
>> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
>> member of Code Aurora Forum, hosted by The Linux Foundation
>
>
>

 --
 QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
 member of Code Aurora Forum, hosted by The Linux Foundation
>>>
>>>
>>>
>>
>> --
>> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
>> member of Code Aurora Forum, hosted by The Linux Foundation
> 
> 
> 

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH v4 12/18] vdpa_sim: add get_config callback in vdpasim_dev_attr

[Jason Wang]

On 2020/12/15 下午10:42, Stefano Garzarella wrote:

The get_config callback can be used by the device to fill the
config structure.
The callback will be invoked in vdpasim_get_config() before copying
bytes into caller buffer.

Move vDPA-net config updates from vdpasim_set_features() in the
new vdpasim_net_get_config() callback.
This is safe since in vdpa_get_config() we already check that
.set_features() callback is called before .get_config().

Signed-off-by: Stefano Garzarella 



Acked-by: Jason Wang 



---
v4:
- explained in the commit message that the moving is safe [Jason]

v3:
- checked if get_config callback is set before call it
---
  drivers/vdpa/vdpa_sim/vdpa_sim.c | 35 +++-
  1 file changed, 21 insertions(+), 14 deletions(-)

diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index 4a0a6cadb9ff..5eadcd19ab6f 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -68,6 +68,8 @@ struct vdpasim_virtqueue {
  #define VDPASIM_NET_FEATURES  (VDPASIM_FEATURES | \
 (1ULL << VIRTIO_NET_F_MAC))
  
+struct vdpasim;

+
  struct vdpasim_dev_attr {
u64 supported_features;
size_t config_size;
@@ -75,6 +77,7 @@ struct vdpasim_dev_attr {
u32 id;
  
  	work_func_t work_fn;

+   void (*get_config)(struct vdpasim *vdpasim, void *config);
  };
  
  /* State of each vdpasim device */

@@ -530,8 +533,6 @@ static u64 vdpasim_get_features(struct vdpa_device *vdpa)
  static int vdpasim_set_features(struct vdpa_device *vdpa, u64 features)
  {
struct vdpasim *vdpasim = vdpa_to_sim(vdpa);
-   struct virtio_net_config *config =
-   (struct virtio_net_config *)vdpasim->config;
  
  	/* DMA mapping must be done by driver */

if (!(features & (1ULL << VIRTIO_F_ACCESS_PLATFORM)))
@@ -539,16 +540,6 @@ static int vdpasim_set_features(struct vdpa_device *vdpa, 
u64 features)
  
  	vdpasim->features = features & vdpasim->dev_attr.supported_features;
  
-	/* We generally only know whether guest is using the legacy interface

-* here, so generally that's the earliest we can set config fields.
-* Note: We actually require VIRTIO_F_ACCESS_PLATFORM above which
-* implies VIRTIO_F_VERSION_1, but let's not try to be clever here.
-*/
-
-   config->mtu = cpu_to_vdpasim16(vdpasim, 1500);
-   config->status = cpu_to_vdpasim16(vdpasim, VIRTIO_NET_S_LINK_UP);
-   memcpy(config->mac, macaddr_buf, ETH_ALEN);
-
return 0;
  }
  
@@ -603,8 +594,13 @@ static void vdpasim_get_config(struct vdpa_device *vdpa, unsigned int offset,

  {
struct vdpasim *vdpasim = vdpa_to_sim(vdpa);
  
-	if (offset + len < vdpasim->dev_attr.config_size)

-   memcpy(buf, vdpasim->config + offset, len);
+   if (offset + len > vdpasim->dev_attr.config_size)
+   return;
+
+   if (vdpasim->dev_attr.get_config)
+   vdpasim->dev_attr.get_config(vdpasim, vdpasim->config);
+
+   memcpy(buf, vdpasim->config + offset, len);
  }
  
  static void vdpasim_set_config(struct vdpa_device *vdpa, unsigned int offset,

@@ -747,6 +743,16 @@ static const struct vdpa_config_ops 
vdpasim_batch_config_ops = {
.free   = vdpasim_free,
  };
  
+static void vdpasim_net_get_config(struct vdpasim *vdpasim, void *config)

+{
+   struct virtio_net_config *net_config =
+   (struct virtio_net_config *)config;
+
+   net_config->mtu = cpu_to_vdpasim16(vdpasim, 1500);
+   net_config->status = cpu_to_vdpasim16(vdpasim, VIRTIO_NET_S_LINK_UP);
+   memcpy(net_config->mac, macaddr_buf, ETH_ALEN);
+}
+
  static int __init vdpasim_dev_init(void)
  {
struct vdpasim_dev_attr dev_attr = {};
@@ -755,6 +761,7 @@ static int __init vdpasim_dev_init(void)
dev_attr.supported_features = VDPASIM_NET_FEATURES;
dev_attr.nvqs = VDPASIM_VQ_NUM;
dev_attr.config_size = sizeof(struct virtio_net_config);
+   dev_attr.get_config = vdpasim_net_get_config;
dev_attr.work_fn = vdpasim_net_work;
  
  	vdpasim_dev = vdpasim_create(_attr);

[PATCH 1/1] x86/mm: Refine mmap syscall implementation

[Adrian Huang]

From: Adrian Huang 

It is unnecessary to use the local variable 'error' in the mmap
syscall implementation function, so use the return statement
instead of it.

Signed-off-by: Adrian Huang 
---
 arch/x86/kernel/sys_x86_64.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/sys_x86_64.c b/arch/x86/kernel/sys_x86_64.c
index 504fa5425bce..660b78827638 100644
--- a/arch/x86/kernel/sys_x86_64.c
+++ b/arch/x86/kernel/sys_x86_64.c
@@ -90,14 +90,10 @@ SYSCALL_DEFINE6(mmap, unsigned long, addr, unsigned long, 
len,
unsigned long, prot, unsigned long, flags,
unsigned long, fd, unsigned long, off)
 {
-   long error;
-   error = -EINVAL;
if (off & ~PAGE_MASK)
-   goto out;
+   return -EINVAL;
 
-   error = ksys_mmap_pgoff(addr, len, prot, flags, fd, off >> PAGE_SHIFT);
-out:
-   return error;
+   return ksys_mmap_pgoff(addr, len, prot, flags, fd, off >> PAGE_SHIFT);
 }
 
 static void find_start_end(unsigned long addr, unsigned long flags,
-- 
2.17.1

RE: [PATCH][next] octeontx2-af: Fix undetected unmap PF error check

[George Cherian]

> -Original Message-
> From: Colin King 
> Sent: Wednesday, December 16, 2020 6:06 PM
> To: Sunil Kovvuri Goutham ; Linu Cherian
> ; Geethasowjanya Akula ;
> Jerin Jacob Kollanukkaran ; David S . Miller
> ; Jakub Kicinski ; George
> Cherian ; net...@vger.kernel.org
> Cc: kernel-janit...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [PATCH][next] octeontx2-af: Fix undetected unmap PF error
> check
> 
> From: Colin Ian King 
> 
> Currently the check for an unmap PF error is always going to be false because
> intr_val is a 32 bit int and is being bit-mask checked against 1ULL << 32.  
> Fix
> this by making intr_val a u64 to match the type at it is copied from, namely
> npa_event_context->npa_af_rvu_ge.
> 
> Addresses-Coverity: ("Operands don't affect result")
> Fixes: f1168d1e207c ("octeontx2-af: Add devlink health reporters for NPA")
> Signed-off-by: Colin Ian King 
Acked-by: George Cherian 

> ---
>  drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c
> b/drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c
> index 3f9d0ab6d5ae..bc0e4113370e 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c
> @@ -275,7 +275,8 @@ static int rvu_npa_report_show(struct devlink_fmsg
> *fmsg, void *ctx,
>  enum npa_af_rvu_health health_reporter)  {
>   struct rvu_npa_event_ctx *npa_event_context;
> - unsigned int intr_val, alloc_dis, free_dis;
> + unsigned int alloc_dis, free_dis;
> + u64 intr_val;
>   int err;
> 
>   npa_event_context = ctx;
> --
> 2.29.2

Regards,
-George

keembay-ocs-aes-core.c:undefined reference to `devm_ioremap_resource'

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   accefff5b547a9a1d959c7e76ad539bf2480e78b
commit: 88574332451380f4b51f6ca88ab9810e714bfb9b crypto: keembay - Add support 
for Keem Bay OCS AES/SM4
date:   6 days ago
config: s390-randconfig-c004-20201217 (attached as .config)
compiler: s390-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/torvalds/linux.git/commit/?id=88574332451380f4b51f6ca88ab9810e714bfb9b
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 88574332451380f4b51f6ca88ab9810e714bfb9b
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=s390 

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

All errors (new ones prefixed by >>):

   s390-linux-ld: kernel/dma/coherent.o: in function `dma_init_coherent_memory':
   coherent.c:(.text+0x54c): undefined reference to `memremap'
   s390-linux-ld: coherent.c:(.text+0x67e): undefined reference to `memunmap'
   s390-linux-ld: kernel/dma/coherent.o: in function 
`dma_declare_coherent_memory':
   coherent.c:(.text+0x8ee): undefined reference to `memunmap'
   s390-linux-ld: drivers/clk/clk-fixed-mmio.o: in function 
`fixed_mmio_clk_setup':
   clk-fixed-mmio.c:(.text+0x98): undefined reference to `of_iomap'
   s390-linux-ld: clk-fixed-mmio.c:(.text+0xe8): undefined reference to 
`iounmap'
   s390-linux-ld: drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.o: in function 
`dw_probe':
   dw-axi-dmac-platform.c:(.text+0x20ac): undefined reference to 
`devm_ioremap_resource'
   s390-linux-ld: drivers/dma/fsl-edma.o: in function `fsl_edma_probe':
   fsl-edma.c:(.text+0x1238): undefined reference to `devm_ioremap_resource'
   s390-linux-ld: fsl-edma.c:(.text+0x1628): undefined reference to 
`devm_ioremap_resource'
   s390-linux-ld: drivers/dma/sf-pdma/sf-pdma.o: in function `sf_pdma_probe':
   sf-pdma.c:(.text+0x92e): undefined reference to `devm_ioremap_resource'
   s390-linux-ld: drivers/crypto/ccree/cc_driver.o: in function 
`init_cc_resources':
   cc_driver.c:(.text+0x89e): undefined reference to `devm_ioremap_resource'
   s390-linux-ld: drivers/crypto/ccree/cc_debugfs.o: in function 
`cc_debugfs_init':
   cc_debugfs.c:(.text+0x108): undefined reference to `debugfs_create_regset32'
   s390-linux-ld: cc_debugfs.c:(.text+0x206): undefined reference to 
`debugfs_create_regset32'
   s390-linux-ld: drivers/crypto/keembay/keembay-ocs-aes-core.o: in function 
`kmb_ocs_aes_probe':
>> keembay-ocs-aes-core.c:(.text+0x1ed2): undefined reference to 
>> `devm_ioremap_resource'

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


.config.gz
Description: application/gzip

RE: Re: Subject: [PATCH v14 1/3] scsi: ufs: Introduce HPB feature

[Daejun Park]

On Wed, Dec 16, 2020 at 11:45:32AM +0900, Daejun Park wrote:
> > This is a patch for the HPB initialization and adds HPB function calls to
> > UFS core driver.
> 
> 
> 
> Your "subject" is odd, it has "Subject:" in it twice, did git
> format-patch create that?
> 
> thanks,
> 
> greg k-h
> 

Sorry, It is my mistake.
Should I resend this patch with proper subject?

Thansk,
Daejun

Re: [PATCH v4 2/4] gpio: visconti: Add Toshiba Visconti GPIO support

[Nobuhiro Iwamatsu]

Hi,

On Wed, Dec 16, 2020 at 09:36:17AM +, Marc Zyngier wrote:
> On 2020-12-16 09:11, Nobuhiro Iwamatsu wrote:
> 
> [...]
> 
> > > > +   for (i = 0; i < num_irq; i++) {
> > > > +   desc = irq_to_desc(priv->irq[i]);
> > > > +   desc->status_use_accessors |= IRQ_NOAUTOEN;
> > > > +   if (devm_request_irq(dev, priv->irq[i],
> > > > +visconti_gpio_irq_handler, 0, 
> > > > name, priv)) {
> > > > +   dev_err(dev, "failed to request IRQ[%d]\n", i);
> > > > +   return -ENOENT;
> > > > +   }
> > > > +   }
> > > 
> > > This should not be needed either when using hiearchical IRQs,
> > > also the irqchip maintainers will beat us up for poking around in the
> > > descs like this.
> > 
> > I understand that the processing equivalent to request_irq() is
> > processed
> > by the irqchip frame work (or GIC driver). Is this correct?
> 
> request_irq() is reserved to endpoint drivers (the driver for the device
> driving the IRQ line). If this is indeed a hierarchical irqchip, the
> line allocation will be driven from the GPIO framework, and request_irq()
> will perform the activation. There isn't anything that this driver should
> do directly other than configuring its own state and passing the request
> along to the parent controller.
> 
> And yes, mucking with the irq descriptor will get you in massive trouble,
> never do that.
> 

I see. Thank you for the explanation.
I got a better understanding.

Best regards,
  Nobuhiro

> -- 
> Jazz is not dead. It just smells funny...
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

Re: [PATCH v4 3/4] pinctrl: qcom: Don't clear pending interrupts when enabling

[Stephen Boyd]

Quoting Douglas Anderson (2020-12-11 14:15:37)
> In Linux, if a driver does disable_irq() and later does enable_irq()
> on its interrupt, I believe it's expecting these properties:
> * If an interrupt was pending when the driver disabled then it will
>   still be pending after the driver re-enables.
> * If an edge-triggered interrupt comes in while an interrupt is
>   disabled it should assert when the interrupt is re-enabled.
> 
> If you think that the above sounds a lot like the disable_irq() and
> enable_irq() are supposed to be masking/unmasking the interrupt
> instead of disabling/enabling it then you've made an astute
> observation.  Specifically when talking about interrupts, "mask"
> usually means to stop posting interrupts but keep tracking them and
> "disable" means to fully shut off interrupt detection.  It's
> unfortunate that this is so confusing, but presumably this is all the
> way it is for historical reasons.
> 
> Perhaps more confusing than the above is that, even though clients of
> IRQs themselves don't have a way to request mask/unmask
> vs. disable/enable calls, IRQ chips themselves can implement both.
> ...and yet more confusing is that if an IRQ chip implements
> disable/enable then they will be called when a client driver calls
> disable_irq() / enable_irq().
> 
> It does feel like some of the above could be cleared up.  However,
> without any other core interrupt changes it should be clear that when
> an IRQ chip gets a request to "disable" an IRQ that it has to treat it
> like a mask of that IRQ.
> 
> In any case, after that long interlude you can see that the "unmask
> and clear" can break things.  Maulik tried to fix it so that we no
> longer did "unmask and clear" in commit 71266d9d3936 ("pinctrl: qcom:
> Move clearing pending IRQ to .irq_request_resources callback"), but it
> only handled the PDC case (it also had problems, but that's the
> subject of another patch).  Let's fix this for the non-PDC case.
> 
> From my understanding the source of the phantom interrupt in the
> non-PDC case was the one that could have been introduced in
> msm_gpio_irq_set_type().  Let's handle that one and then get rid of
> the clear.
> 
> Fixes: 4b7618fdc7e6 ("pinctrl: qcom: Add irq_enable callback for msm gpio")
> Signed-off-by: Douglas Anderson 
> ---

Reviewed-by: Stephen Boyd 

One comment clarification below.

> I don't have lots of good test cases here, so hopefully someone from
> Qualcomm can confirm that this works well for them and there isn't
> some other phantom interrupt source that I'm not aware of.
> 
> Changes in v4:
> - ("pinctrl: qcom: Don't clear pending interrupts when enabling") split for 
> v4.
> 
>  drivers/pinctrl/qcom/pinctrl-msm.c | 32 +-
>  1 file changed, 14 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c 
> b/drivers/pinctrl/qcom/pinctrl-msm.c
> index 588df91274e2..f785646d1df7 100644
> --- a/drivers/pinctrl/qcom/pinctrl-msm.c
> +++ b/drivers/pinctrl/qcom/pinctrl-msm.c
> @@ -1046,6 +1032,16 @@ static int msm_gpio_irq_set_type(struct irq_data *d, 
> unsigned int type)
> }
> msm_writel_intr_cfg(val, pctrl, g);
>  
> +   /*
> +* The first time we set RAW_STATUS_EN it could trigger an interrupt.
> +* Clear it.  This is safe because we have IRQCHIP_SET_TYPE_MASKED.

Clear the interrupt? 'it' is ambiguous.

> +*/
> +   if (!was_enabled) {
> +   val = msm_readl_intr_status(pctrl, g);
> +   val &= ~BIT(g->intr_status_bit);
> +   msm_writel_intr_status(val, pctrl, g);
> +   }
> +
> if (test_bit(d->hwirq, pctrl->dual_edge_irqs))
> msm_gpio_update_dual_edge_pos(pctrl, g, d);
>

Re: [PATCH v2 0/6] kernfs: proposed locking and concurrency improvement

[Ian Kent]

On Tue, 2020-12-15 at 20:59 +0800, Ian Kent wrote:
> On Tue, 2020-12-15 at 16:33 +0800, Fox Chen wrote:
> > On Mon, Dec 14, 2020 at 9:30 PM Ian Kent  wrote:
> > > On Mon, 2020-12-14 at 14:14 +0800, Fox Chen wrote:
> > > > On Sun, Dec 13, 2020 at 11:46 AM Ian Kent 
> > > > wrote:
> > > > > On Fri, 2020-12-11 at 10:17 +0800, Ian Kent wrote:
> > > > > > On Fri, 2020-12-11 at 10:01 +0800, Ian Kent wrote:
> > > > > > > > For the patches, there is a mutex_lock in kn-
> > > > > > > > >attr_mutex, 
> > > > > > > > as
> > > > > > > > Tejun
> > > > > > > > mentioned here
> > > > > > > > (
> > > > > > > > https://lore.kernel.org/lkml/x8fe0cmu+aq1g...@mtj.duckdns.org/
> > > > > > > > ),
> > > > > > > > maybe a global
> > > > > > > > rwsem for kn->iattr will be better??
> > > > > > > 
> > > > > > > I wasn't sure about that, IIRC a spin lock could be used
> > > > > > > around
> > > > > > > the
> > > > > > > initial check and checked again at the end which would
> > > > > > > probably
> > > > > > > have
> > > > > > > been much faster but much less conservative and a bit
> > > > > > > more
> > > > > > > ugly
> > > > > > > so
> > > > > > > I just went the conservative path since there was so much
> > > > > > > change
> > > > > > > already.
> > > > > > 
> > > > > > Sorry, I hadn't looked at Tejun's reply yet and TBH didn't
> > > > > > remember
> > > > > > it.
> > > > > > 
> > > > > > Based on what Tejun said it sounds like that needs work.
> > > > > 
> > > > > Those attribute handling patches were meant to allow taking
> > > > > the
> > > > > rw
> > > > > sem read lock instead of the write lock for
> > > > > kernfs_refresh_inode()
> > > > > updates, with the added locking to protect the inode
> > > > > attributes
> > > > > update since it's called from the VFS both with and without
> > > > > the
> > > > > inode lock.
> > > > 
> > > > Oh, understood. I was asking also because lock on kn-
> > > > >attr_mutex
> > > > drags
> > > > concurrent performance.
> > > > 
> > > > > Looking around it looks like kernfs_iattrs() is called from
> > > > > multiple
> > > > > places without a node database lock at all.
> > > > > 
> > > > > I'm thinking that, to keep my proposed change straight
> > > > > forward
> > > > > and on topic, I should just leave kernfs_refresh_inode()
> > > > > taking
> > > > > the node db write lock for now and consider the attributes
> > > > > handling
> > > > > as a separate change. Once that's done we could reconsider
> > > > > what's
> > > > > needed to use the node db read lock in
> > > > > kernfs_refresh_inode().
> > > > 
> > > > You meant taking write lock of kernfs_rwsem for
> > > > kernfs_refresh_inode()??
> > > > It may be a lot slower in my benchmark, let me test it.
> > > 
> > > Yes, but make sure the write lock of kernfs_rwsem is being taken
> > > not the read lock.
> > > 
> > > That's a mistake I had initially?
> > > 
> > > Still, that attributes handling is, I think, sufficient to
> > > warrant
> > > a separate change since it looks like it might need work, the
> > > kernfs
> > > node db probably should be kept stable for those attribute
> > > updates
> > > but equally the existence of an instantiated dentry might
> > > mitigate
> > > the it.
> > > 
> > > Some people might just know whether it's ok or not but I would
> > > like
> > > to check the callers to work out what's going on.
> > > 
> > > In any case it's academic if GCH isn't willing to consider the
> > > series
> > > for review and possible merge.
> > > 
> > Hi Ian
> > 
> > I removed kn->attr_mutex and changed read lock to write lock for
> > kernfs_refresh_inode
> > 
> > down_write(_rwsem);
> > kernfs_refresh_inode(kn, inode);
> > up_write(_rwsem);
> > 
> > 
> > Unfortunate, changes in this way make things worse,  my benchmark
> > runs
> > 100% slower than upstream sysfs.  :(
> > open+read+close a sysfs file concurrently took 1000us. (Currently,
> > sysfs with a big mutex kernfs_mutex only takes ~500us
> > for one open+read+close operation concurrently)
> 
> Right, so it does need attention nowish.
> 
> I'll have a look at it in a while, I really need to get a new autofs
> release out, and there are quite a few changes, and testing is seeing
> a number of errors, some old, some newly introduced. It's proving
> difficult.

I've taken a breather for the autofs testing and had a look at this.

I think my original analysis of this was wrong.

Could you try this patch please.
I'm not sure how much difference it will make but, in principle,
it's much the same as the previous approach except it doesn't
increase the kernfs node struct size or mess with the other
attribute handling code.

Note, this is not even compile tested.

kernfs: use kernfs read lock in .getattr() and .permission()

From: Ian Kent 

>From Documenation/filesystems.rst and (slightly outdated) comments
in fs/attr.c the inode i_rwsem is used for attribute handling.

This lock satisfies the requirememnts needed to reduce lock contention,
namely a per-object lock needs to be used 

s390-linux-ld: ll_temac_main.c:undefined reference to `devm_platform_ioremap_resource'

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   accefff5b547a9a1d959c7e76ad539bf2480e78b
commit: cc6596fc7295e9dcd78156ed42f9f8e1221f7530 net: ll_temac: Fix potential 
NULL dereference in temac_probe()
date:   8 days ago
config: s390-randconfig-r032-20201217 (attached as .config)
compiler: s390-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/torvalds/linux.git/commit/?id=cc6596fc7295e9dcd78156ed42f9f8e1221f7530
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout cc6596fc7295e9dcd78156ed42f9f8e1221f7530
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=s390 

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

All errors (new ones prefixed by >>):

   s390-linux-ld: drivers/dma/altera-msgdma.o: in function `request_and_map':
   altera-msgdma.c:(.text+0xffa): undefined reference to `devm_ioremap'
   s390-linux-ld: drivers/dma/dw/platform.o: in function `dw_probe':
   platform.c:(.text+0x2d6): undefined reference to 
`devm_platform_ioremap_resource'
   s390-linux-ld: drivers/dma/idma64.o: in function `idma64_platform_probe':
   idma64.c:(.text+0x22f6): undefined reference to `devm_ioremap_resource'
   s390-linux-ld: drivers/dma/sf-pdma/sf-pdma.o: in function `sf_pdma_probe':
   sf-pdma.c:(.text+0x1760): undefined reference to `devm_ioremap_resource'
   s390-linux-ld: drivers/dma/qcom/hidma_mgmt.o: in function `hidma_mgmt_probe':
   hidma_mgmt.c:(.text+0x6b0): undefined reference to `devm_ioremap_resource'
   s390-linux-ld: drivers/dma/xilinx/xilinx_dpdma.o: in function 
`xilinx_dpdma_probe':
   xilinx_dpdma.c:(.text+0x23aa): undefined reference to 
`devm_platform_ioremap_resource'
   s390-linux-ld: drivers/net/ethernet/altera/altera_tse_main.o: in function 
`request_and_map':
   altera_tse_main.c:(.text+0x2fa): undefined reference to `devm_ioremap'
   s390-linux-ld: drivers/net/ethernet/xilinx/ll_temac_main.o: in function 
`temac_probe':
   ll_temac_main.c:(.text+0x3162): undefined reference to 
`devm_platform_ioremap_resource_byname'
>> s390-linux-ld: ll_temac_main.c:(.text+0x32e6): undefined reference to 
>> `devm_platform_ioremap_resource'
   s390-linux-ld: drivers/net/ethernet/xilinx/xilinx_axienet_main.o: in 
function `axienet_probe':
   xilinx_axienet_main.c:(.text+0x49e): undefined reference to 
`devm_ioremap_resource'

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


.config.gz
Description: application/gzip

Re: [PATCH v15 09/10] fs/ntfs3: Add NTFS3 in fs/Kconfig and fs/Makefile

[kernel test robot]

Hi Konstantin,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.10 next-20201215]
[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/Konstantin-Komarov/NTFS-read-write-driver-GPL-implementation-by-Paragon-Software/20201212-002454
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
33dc9614dc208291d0c4bcdeb5d30d481dcd2c4c
config: parisc-randconfig-r003-20201217 (attached as .config)
compiler: hppa-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/1b2891569e06a47bd2cfaf86fe29919d40e3b486
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Konstantin-Komarov/NTFS-read-write-driver-GPL-implementation-by-Paragon-Software/20201212-002454
git checkout 1b2891569e06a47bd2cfaf86fe29919d40e3b486
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=parisc 

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

All errors (new ones prefixed by >>):

   In file included from fs/ntfs3/xattr.c:17:
   fs/ntfs3/ntfs.h:427:1: warning: 'inline' is not at beginning of declaration 
[-Wold-style-declaration]
 427 | static const inline __le16 *attr_name(const struct ATTRIB *attr)
 | ^~
   fs/ntfs3/ntfs.h:544:1: warning: 'inline' is not at beginning of declaration 
[-Wold-style-declaration]
 544 | static const inline __le16 *le_name(const struct ATTR_LIST_ENTRY *le)
 | ^~
   fs/ntfs3/xattr.c: In function 'ntfs_get_acl_ex':
>> fs/ntfs3/xattr.c:512:4: error: implicit declaration of function 
>> 'set_cached_acl'; did you mean 'is_uncached_acl'? 
>> [-Werror=implicit-function-declaration]
 512 |set_cached_acl(inode, type, acl);
 |^~
 |is_uncached_acl
   fs/ntfs3/xattr.c: In function 'ntfs_init_acl':
>> fs/ntfs3/xattr.c:1013:7: error: 'struct inode' has no member named 
>> 'i_default_acl'
1013 |  inode->i_default_acl = NULL;
 |   ^~
>> fs/ntfs3/xattr.c:1046:8: error: 'struct inode' has no member named 'i_acl'
1046 |   inode->i_acl = NULL;
 |^~
   cc1: some warnings being treated as errors


vim +512 fs/ntfs3/xattr.c

65c2a48e1da93c6 Konstantin Komarov 2020-12-11  480  
65c2a48e1da93c6 Konstantin Komarov 2020-12-11  481  static struct posix_acl 
*ntfs_get_acl_ex(struct inode *inode, int type,
65c2a48e1da93c6 Konstantin Komarov 2020-12-11  482  
 int locked)
65c2a48e1da93c6 Konstantin Komarov 2020-12-11  483  {
65c2a48e1da93c6 Konstantin Komarov 2020-12-11  484  struct ntfs_inode *ni = 
ntfs_i(inode);
65c2a48e1da93c6 Konstantin Komarov 2020-12-11  485  const char *name;
65c2a48e1da93c6 Konstantin Komarov 2020-12-11  486  struct posix_acl *acl;
65c2a48e1da93c6 Konstantin Komarov 2020-12-11  487  size_t req;
65c2a48e1da93c6 Konstantin Komarov 2020-12-11  488  int err;
65c2a48e1da93c6 Konstantin Komarov 2020-12-11  489  void *buf;
65c2a48e1da93c6 Konstantin Komarov 2020-12-11  490  
65c2a48e1da93c6 Konstantin Komarov 2020-12-11  491  /* allocate PATH_MAX 
bytes */
65c2a48e1da93c6 Konstantin Komarov 2020-12-11  492  buf = __getname();
65c2a48e1da93c6 Konstantin Komarov 2020-12-11  493  if (!buf)
65c2a48e1da93c6 Konstantin Komarov 2020-12-11  494  return 
ERR_PTR(-ENOMEM);
65c2a48e1da93c6 Konstantin Komarov 2020-12-11  495  
65c2a48e1da93c6 Konstantin Komarov 2020-12-11  496  /* Possible values of 
'type' was already checked above */
65c2a48e1da93c6 Konstantin Komarov 2020-12-11  497  name = type == 
ACL_TYPE_ACCESS ? XATTR_NAME_POSIX_ACL_ACCESS :
65c2a48e1da93c6 Konstantin Komarov 2020-12-11  498  
 XATTR_NAME_POSIX_ACL_DEFAULT;
65c2a48e1da93c6 Konstantin Komarov 2020-12-11  499  
65c2a48e1da93c6 Konstantin Komarov 2020-12-11  500  if (!locked)
65c2a48e1da93c6 Konstantin Komarov 2020-12-11  501  ni_lock(ni);
65c2a48e1da93c6 Konstantin Komarov 2020-12-11  502  
65c2a48e1da93c6 Konstantin Komarov 2020-12-11  503  err = 
ntfs_getxattr_hlp(inode, name, buf, PATH_MAX, );
65c2a48e1da93c6 Konstantin Komarov 2020-12-11  504  
65c2a48e1da93c6 Konstantin Komarov 2020-12-11  505  if (!locked)
65c2a48e1da93c6 Konstantin Komarov 2020-12-11  506  ni_unlock(ni);
65c2a48e1da93c6 Konstantin Komarov 2020-12-11  507  
65c2a48e1da93c6 Konstantin Komarov 2020-12-11  508  /* Translate extended 
attribute to acl */
65c2a48e1da93c6 

Re: [PATCH v4 04/18] vdpa_sim: make IOTLB entries limit configurable

[Jason Wang]

On 2020/12/15 下午10:42, Stefano Garzarella wrote:

Some devices may require a higher limit for the number of IOTLB
entries, so let's make it configurable through a module parameter.

By default, it's initialized with the current limit (2048).

Suggested-by: Jason Wang 
Signed-off-by: Stefano Garzarella 



Acked-by: Jason Wang 



---
  drivers/vdpa/vdpa_sim/vdpa_sim.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index 07ccc8609784..d716bfaadb3b 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -31,6 +31,11 @@ static int batch_mapping = 1;
  module_param(batch_mapping, int, 0444);
  MODULE_PARM_DESC(batch_mapping, "Batched mapping 1 -Enable; 0 - Disable");
  
+static int max_iotlb_entries = 2048;

+module_param(max_iotlb_entries, int, 0444);
+MODULE_PARM_DESC(max_iotlb_entries,
+"Maximum number of iotlb entries. 0 means unlimited. (default: 
2048)");
+
  static char *macaddr;
  module_param(macaddr, charp, 0);
  MODULE_PARM_DESC(macaddr, "Ethernet MAC address");
@@ -371,7 +376,7 @@ static struct vdpasim *vdpasim_create(void)
if (!vdpasim->vqs)
goto err_iommu;
  
-	vdpasim->iommu = vhost_iotlb_alloc(2048, 0);

+   vdpasim->iommu = vhost_iotlb_alloc(max_iotlb_entries, 0);
if (!vdpasim->iommu)
goto err_iommu;
  

Re: [PATCH v2 3/4] spi: spi-geni-qcom: Don't try to set CS if an xfer is pending

[Stephen Boyd]

Quoting Douglas Anderson (2020-12-16 14:41:51)
> If we get a timeout sending then this happens:
> * spi_transfer_wait() will get a timeout.
> * We'll set the chip select
> * We'll call handle_err() => handle_fifo_timeout().
> 
> Unfortunately that won't work so well on geni.  If we got a timeout
> transferring then it's likely that our interrupt handler is blocked,
> but we need that same interrupt handler to adjust the chip select.
> Trying to set the chip select doesn't crash us but ends up confusing
> our state machine and leads to messages like:
>   Premature done. rx_rem = 32 bpw8
> 
> Let's just drop the chip select request in this case.  Sure, we might
> leave the chip select in the wrong state but it's likely it was going
> to fail anyway and this avoids getting the driver even more confused
> about what it's doing.
> 
> The SPI core in general assumes that setting chip select is a simple
> operation that doesn't fail.  Yet another reason to just reconfigure
> the chip select line as GPIOs.

BTW, we could peek at the irq bit for the CS change and ignore the irq
handler entirely. That would be one way to make sure the cs change went
through, and would avoid an irq delay/scheduling problem for this simple
operation. Maybe using the irq path is worse in general here?

Re: [PATCH v2 3/4] spi: spi-geni-qcom: Don't try to set CS if an xfer is pending

[Stephen Boyd]

Quoting Douglas Anderson (2020-12-16 14:41:51)
> If we get a timeout sending then this happens:
> * spi_transfer_wait() will get a timeout.
> * We'll set the chip select
> * We'll call handle_err() => handle_fifo_timeout().
> 
> Unfortunately that won't work so well on geni.  If we got a timeout
> transferring then it's likely that our interrupt handler is blocked,
> but we need that same interrupt handler to adjust the chip select.
> Trying to set the chip select doesn't crash us but ends up confusing
> our state machine and leads to messages like:
>   Premature done. rx_rem = 32 bpw8
> 
> Let's just drop the chip select request in this case.  Sure, we might
> leave the chip select in the wrong state but it's likely it was going
> to fail anyway and this avoids getting the driver even more confused
> about what it's doing.
> 
> The SPI core in general assumes that setting chip select is a simple
> operation that doesn't fail.  Yet another reason to just reconfigure
> the chip select line as GPIOs.

Indeed.

> 
> Signed-off-by: Douglas Anderson 
> ---
> 
> Changes in v2:
> - ("spi: spi-geni-qcom: Don't try to set CS if an xfer is pending") new for 
> v2.
> 
>  drivers/spi/spi-geni-qcom.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
> index d988463e606f..0e4fa52ac017 100644
> --- a/drivers/spi/spi-geni-qcom.c
> +++ b/drivers/spi/spi-geni-qcom.c
> @@ -204,9 +204,14 @@ static void spi_geni_set_cs(struct spi_device *slv, bool 
> set_flag)
> goto exit;
> }
>  
> -   mas->cs_flag = set_flag;
> -
> spin_lock_irq(>lock);
> +   if (mas->cur_xfer) {

How is it possible that cs change happens when cur_xfer is non-NULL?

> +   dev_err(mas->dev, "Can't set CS when prev xfter running\n");

xfer? or xfter?

> +   spin_unlock_irq(>lock);
> +   goto exit;
> +   }
> +
> +   mas->cs_flag = set_flag;
> reinit_completion(>cs_done);

[PATCH v1] scsi: ufs: Fix possible power drain during system suspend

[Stanley Chu]

Currently if device needs to do flush or BKOP operations,
the device VCC power is kept during runtime-suspend period.

However, if system suspend is happening while device is
runtime-suspended, such power may not be disabled successfully.

The reasons may be,

1. If current PM level is the same as SPM level, device will
   keep runtime-suspended by ufshcd_system_suspend().

2. Flush recheck work may not be scheduled successfully
   during system suspend period. If it can wake up the system,
   this is also not the intention of the recheck work.

To fix this issue, simply runtime-resume the device if the flush
is allowed during runtime suspend period. Flush capability will be
disabled while leaving runtime suspend, and also not be allowed in
system suspend period.

Fixes: 51dd905bd2f6 ("scsi: ufs: Fix WriteBooster flush during runtime suspend")
Reviewed-by: Chaotian Jing 
Signed-off-by: Stanley Chu 
---
 drivers/scsi/ufs/ufshcd.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index e221add25a7e..9d61dc3eb842 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -8903,7 +8903,8 @@ int ufshcd_system_suspend(struct ufs_hba *hba)
if ((ufs_get_pm_lvl_to_dev_pwr_mode(hba->spm_lvl) ==
 hba->curr_dev_pwr_mode) &&
(ufs_get_pm_lvl_to_link_pwr_state(hba->spm_lvl) ==
-hba->uic_link_state))
+hba->uic_link_state) &&
+!hba->dev_info.b_rpm_dev_flush_capable)
goto out;
 
if (pm_runtime_suspended(hba->dev)) {
-- 
2.18.0

Re: [PATCH v2 2/4] spi: spi-geni-qcom: Fail new xfers if xfer/cancel/abort pending

[Stephen Boyd]

Quoting Douglas Anderson (2020-12-16 14:41:50)
> If we got a timeout when trying to send an abort command then it means
> that we just got 3 timeouts in a row:
> 
> 1. The original timeout that caused handle_fifo_timeout() to be
>called.
> 2. A one second timeout waiting for the cancel command to finish.
> 3. A one second timeout waiting for the abort command to finish.
> 
> SPI is clocked by the controller, so nothing (aside from a hardware
> fault or a totally broken sequencer) should be causing the actual
> commands to fail in hardware.  However, even though the hardware
> itself is not expected to fail (and it'd be hard to predict how we
> should handle things if it did), it's easy to hit the timeout case by
> simply blocking our interrupt handler from running for a long period
> of time.  Obviously the system is in pretty bad shape if a interrupt
> handler is blocked for > 2 seconds, but there are certainly bugs (even
> bugs in other unrelated drivers) that can make this happen.
> 
> Let's make things a bit more robust against this case.  If we fail to
> abort we'll set a flag and then we'll block all future transfers until
> we have no more interrupts pending.

Why can't we forcibly roll the ball forward and clear the irq if it's a
cancel/abort that's pending? Basically tell the hardware that we
understand it did the job and canceled things out but our sad little CPU
didn't run that irq handler yet. Here have a cookie and get ready for
the next transfer.

if (M_CMD_CANCEL_EN || M_CMD_ABORT_EN) /* but not the other irqs like 
CMD_DONE or refill fifos */
writel(M_CMD_CANCEL_EN | M_CMD_ABORT_EN, se->base + 
SE_GENI_M_IRQ_CLEAR);

This would let us limp along and try to send another transfer in the
case that we timed out but the transfer went through by servicing our
own interrupt.

> 
> Fixes: 561de45f72bd ("spi: spi-geni-qcom: Add SPI driver support for GENI 
> based QUP")
> Signed-off-by: Douglas Anderson 
> ---
> 
> Changes in v2:
> - Make this just about the failed abort.
> 
>  drivers/spi/spi-geni-qcom.c | 56 +++--
>  1 file changed, 54 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
> index bf55abbd39f1..d988463e606f 100644
> --- a/drivers/spi/spi-geni-qcom.c
> +++ b/drivers/spi/spi-geni-qcom.c
> @@ -83,6 +83,7 @@ struct spi_geni_master {
> spinlock_t lock;
> int irq;
> bool cs_flag;
> +   bool abort_failed;
>  };
>  
>  static int get_spi_clk_cfg(unsigned int speed_hz,
> @@ -141,8 +142,46 @@ static void handle_fifo_timeout(struct spi_master *spi,
> spin_unlock_irq(>lock);
>  
> time_left = wait_for_completion_timeout(>abort_done, HZ);
> -   if (!time_left)
> +   if (!time_left) {
> dev_err(mas->dev, "Failed to cancel/abort m_cmd\n");
> +
> +   /*
> +* No need for a lock since SPI core has a lock and we never
> +* access this from an interrupt.
> +*/
> +   mas->abort_failed = true;
> +   }
> +}
> +
> +static bool spi_geni_is_abort_still_pending(struct spi_geni_master *mas)
> +{
> +   struct geni_se *se = >se;
> +   u32 m_irq, m_irq_en;
> +
> +   if (!mas->abort_failed)
> +   return false;
> +
> +   /*
> +* The only known case where a transfer times out and then a cancel
> +* times out then an abort times out is if something is blocking our
> +* interrupt handler from running.  Avoid starting any new transfers
> +* until that sorts itself out.
> +*/
> +   m_irq = readl(se->base + SE_GENI_M_IRQ_STATUS);
> +   m_irq_en = readl(se->base + SE_GENI_M_IRQ_EN);

I suppose this could race with the irq handler. Maybe we should grab the
irq lock around the register reads so we can synchronize with the irq
handler and save a fail?

> +   if (m_irq & m_irq_en) {
> +   dev_err(mas->dev, "Interrupts pending after abort: %#010x\n",
> +   m_irq & m_irq_en);
> +   return true;
> +   }
> +

Re: [RFC PATCH v1 3/4] KVM: arm64: GICv4.1: Restore VLPI's pending state to physical side

[Shenming Lu]

On 2020/12/16 18:35, Auger Eric wrote:
> Hi Shenming,
> 
> On 12/1/20 1:15 PM, Shenming Lu wrote:
>> On 2020/12/1 19:50, Marc Zyngier wrote:
>>> On 2020-12-01 11:40, Shenming Lu wrote:
 On 2020/12/1 18:55, Marc Zyngier wrote:
> On 2020-11-30 07:23, Shenming Lu wrote:
>
> Hi Shenming,
>
>> We are pondering over this problem these days, but still don't get a
>> good solution...
>> Could you give us some advice on this?
>>
>> Or could we move the restoring of the pending states (include the sync
>> from guest RAM and the transfer to HW) to the GIC VM state change 
>> handler,
>> which is completely corresponding to save_pending_tables (more 
>> symmetric?)
>> and don't expose GICv4...
>
> What is "the GIC VM state change handler"? Is that a QEMU thing?

 Yeah, it is a a QEMU thing...

> We don't really have that concept in KVM, so I'd appreciate if you could
> be a bit more explicit on this.

 My thought is to add a new interface (to QEMU) for the restoring of
 the pending states, which is completely corresponding to
 KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES...
 And it is called from the GIC VM state change handler in QEMU, which
 is happening after the restoring (call kvm_vgic_v4_set_forwarding())
 but before the starting (running) of the VFIO device.
>>>
>>> Right, that makes sense. I still wonder how much the GIC save/restore
>>> stuff differs from other architectures that implement similar features,
>>> such as x86 with VT-D.
>>
>> I am not familiar with it...
>>
>>>
>>> It is obviously too late to change the userspace interface, but I wonder
>>> whether we missed something at the time.
>>
>> The interface seems to be really asymmetrical?...
> 
> in qemu d5aa0c229a ("hw/intc/arm_gicv3_kvm: Implement pending table
> save") commit message, it is traced:
> 
> "There is no explicit restore as the tables are implicitly sync'ed
> on ITS table restore and on LPI enable at redistributor level."
> 
> At that time there was no real justification behind adding the RESTORE
> fellow attr.
> 
> Maybe a stupid question but isn't it possible to unset the forwarding
> when saving and rely on VFIO to automatically restore it when resuming
> on destination?

It seems that the unset_forwarding would not be called when saving, it would
be called after migration completion...
As for the resuming/set_forwarding, I still wonder: is it really improper to
transfer the pending states from vgic to VPT in set_forwarding (not only in
migration)?...  -_-

Thanks,
Shenming

> 
> Thanks
> 
> Eric
> 
> 
>>
>> Or is there a possibility that we could know which irq is hw before the VFIO
>> device calls kvm_vgic_v4_set_forwarding()?
>>
>> Thanks,
>> Shenming
>>
>>>
>>> Thanks,
>>>
>>>     M.
>>
> 
> .
> 

Re: [PATCH v3 5/6] i2c: iproc: handle master read request

[Rayagonda Kokatanur]

On Wed, Dec 2, 2020 at 11:14 PM Ray Jui  wrote:
>
>
>
> On 12/2/2020 6:35 AM, Wolfram Sang wrote:
> >
> >> All review comments are scattered now, please let me know what has to be
> >> done further,
> >> Are we going to change the tasklet to irq thread ?
> >> Are we going to remove batching 64 packets if transaction > 64B and use rx
> >> fifo threshold ?
> >>
> >> I don't see any issue with current code but if it has to change we need a
> >> valid reason for the same.
> >> If nothing to be done, please acknowledge the patch.
> >
> > Valid request. Has there been any news?
> >
>
> Sorry for the delay. I just replied.

This patch is tested and validated with all corner cases and its working.
Can we merge this and take up any improvement as part of separate patch?

Thanks,
Rayagonda

>
>
> Thanks,
>
> Ray

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [External] Re: [PATCH v9 03/11] mm/hugetlb: Free the vmemmap pages associated with each HugeTLB page

[Muchun Song]

On Thu, Dec 17, 2020 at 6:08 AM Mike Kravetz  wrote:
>
> On 12/13/20 7:45 AM, Muchun Song wrote:
> > Every HugeTLB has more than one struct page structure. We __know__ that
> > we only use the first 4(HUGETLB_CGROUP_MIN_ORDER) struct page structures
> > to store metadata associated with each HugeTLB.
> >
> > There are a lot of struct page structures associated with each HugeTLB
> > page. For tail pages, the value of compound_head is the same. So we can
> > reuse first page of tail page structures. We map the virtual addresses
> > of the remaining pages of tail page structures to the first tail page
> > struct, and then free these page frames. Therefore, we need to reserve
> > two pages as vmemmap areas.
> >
> > When we allocate a HugeTLB page from the buddy, we can free some vmemmap
> > pages associated with each HugeTLB page. It is more appropriate to do it
> > in the prep_new_huge_page().
> >
> > The free_vmemmap_pages_per_hpage(), which indicates how many vmemmap
> > pages associated with a HugeTLB page can be freed, returns zero for
> > now, which means the feature is disabled. We will enable it once all
> > the infrastructure is there.
> >
> > Signed-off-by: Muchun Song 
> > ---
> >  include/linux/bootmem_info.h |  27 +-
> >  include/linux/mm.h   |   2 +
> >  mm/Makefile  |   1 +
> >  mm/hugetlb.c |   3 +
> >  mm/hugetlb_vmemmap.c | 209 
> > +++
> >  mm/hugetlb_vmemmap.h |  20 +
> >  mm/sparse-vmemmap.c  | 170 +++
> >  7 files changed, 431 insertions(+), 1 deletion(-)
> >  create mode 100644 mm/hugetlb_vmemmap.c
> >  create mode 100644 mm/hugetlb_vmemmap.h
>
> > diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
> > index 16183d85a7d5..78c527617e8d 100644
> > --- a/mm/sparse-vmemmap.c
> > +++ b/mm/sparse-vmemmap.c
> > @@ -27,8 +27,178 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> > +
> >  #include 
> >  #include 
> > +#include 
> > +
> > +/*
> > + * vmemmap_rmap_walk - walk vmemmap page table
>
> I am not sure if 'rmap' should be part of these names.  rmap today is mostly
> about reverse mapping lookup.  Did you use rmap for 'remap', or because this
> code is patterned after the page table walking rmap code?  Just think the
> naming could cause some confusion.

Yeah. I should use "remap" to avoid confusion.

>
> > + *
> > + * @rmap_pte:called for each non-empty PTE (lowest-level) 
> > entry.
> > + * @reuse:   the page which is reused for the tail vmemmap pages.
> > + * @vmemmap_pages:   the list head of the vmemmap pages that can be freed.
> > + */
> > +struct vmemmap_rmap_walk {
> > + void (*rmap_pte)(pte_t *pte, unsigned long addr,
> > +  struct vmemmap_rmap_walk *walk);
> > + struct page *reuse;
> > + struct list_head *vmemmap_pages;
> > +};
> > +
> > +/*
> > + * The index of the pte page table which is mapped to the tail of the
> > + * vmemmap page.
> > + */
> > +#define VMEMMAP_TAIL_PAGE_REUSE  -1
>
> That is the index/offset from the range to be remapped.  See comments below.

You are right. I need to update the comment.

>
> > +
> > +static void vmemmap_pte_range(pmd_t *pmd, unsigned long addr,
> > +   unsigned long end, struct vmemmap_rmap_walk 
> > *walk)
> > +{
> > + pte_t *pte;
> > +
> > + pte = pte_offset_kernel(pmd, addr);
> > + do {
> > + BUG_ON(pte_none(*pte));
> > +
> > + if (!walk->reuse)
> > + walk->reuse = pte_page(pte[VMEMMAP_TAIL_PAGE_REUSE]);
>
> It may be just me, but I don't like the pte[-1] here.  It certainly does work
> as designed because we want to remap all pages in the range to the page before
> the range (at offset -1).  But, we do not really validate this 'reuse' page.
> There is the BUG_ON(pte_none(*pte)) as a sanity check, but we do nothing 
> similar
> for pte[-1].  Based on the usage for HugeTLB pages, we can be confident that
> pte[-1] is actually a pte.  In discussions with Oscar, you mentioned another
> possible use for these routines.

Yeah, we should add a BUG_ON for pte[-1].

>
> Don't change anything based on my opinion only.  I would like to see what
> others think as well.
>
> > +
> > + if (walk->rmap_pte)
> > + walk->rmap_pte(pte, addr, walk);
> > + } while (pte++, addr += PAGE_SIZE, addr != end);
> > +}
> > +
> > +static void vmemmap_pmd_range(pud_t *pud, unsigned long addr,
> > +   unsigned long end, struct vmemmap_rmap_walk 
> > *walk)
> > +{
> > + pmd_t *pmd;
> > + unsigned long next;
> > +
> > + pmd = pmd_offset(pud, addr);
> > + do {
> > + BUG_ON(pmd_none(*pmd));
> > +
> > + next = pmd_addr_end(addr, end);
> > + vmemmap_pte_range(pmd, addr, next, walk);
> > + } while (pmd++, addr = next, addr != end);
> > +}
> 

Re: [PATCH v5 7/7] pwm: pca9685: Restrict period change for prescaler users

[Sven Van Asbroeck]

Hi Clemens, see below.

On Wed, Dec 16, 2020 at 7:53 AM Clemens Gruber
 wrote:
>
> Previously, the last used PWM channel could change the global prescale
> setting, even if other channels were already in use.
>
> Fix it by only allowing the first user of the prescaler to change the
> global chip-wide prescale setting. If there is more than one channel in
> use, the prescale settings resulting from the chosen periods must match.
>
> PWMs that are disabled or have a duty cycle of 0% or 100% are not
> considered to be using the prescaler as they have the full OFF or full
> ON bits set. This also applies to channels used as GPIOs.
>
> Signed-off-by: Clemens Gruber 
> ---
>  drivers/pwm/pwm-pca9685.c | 51 +--
>  1 file changed, 44 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/pwm/pwm-pca9685.c b/drivers/pwm/pwm-pca9685.c
> index ff916980de49..438492d4aed4 100644
> --- a/drivers/pwm/pwm-pca9685.c
> +++ b/drivers/pwm/pwm-pca9685.c
> @@ -23,11 +23,11 @@
>  #include 
>
>  /*
> - * Because the PCA9685 has only one prescaler per chip, changing the period 
> of
> - * one channel affects the period of all 16 PWM outputs!
> - * However, the ratio between each configured duty cycle and the chip-wide
> - * period remains constant, because the OFF time is set in proportion to the
> - * counter range.
> + * Because the PCA9685 has only one prescaler per chip, only the first 
> channel
> + * that uses the prescaler is allowed to change the prescale register.
> + * PWM channels requested afterwards must use a period that results in the 
> same
> + * prescale setting as the one set by the first requested channel, unless 
> they
> + * use duty cycles of 0% or 100% (prescaler not used for full OFF/ON).
>   */
>
>  #define PCA9685_MODE1  0x00
> @@ -80,6 +80,8 @@ struct pca9685 {
> struct pwm_chip chip;
> struct regmap *regmap;
> bool staggered_outputs;
> +   struct mutex prescaler_users_lock;

Keep things simple by re-using the "struct mutex lock" below?
This code isn't performance-intensive, so having a single lock for
pwm/gpio requests + pwm_apply() is probably ok.

> +   DECLARE_BITMAP(prescaler_users, PCA9685_MAXCHAN + 1);

Rename to pwms_use_prescale ?

>  #if IS_ENABLED(CONFIG_GPIOLIB)
> struct mutex lock;
> struct gpio_chip gpio;
> @@ -92,6 +94,18 @@ static inline struct pca9685 *to_pca(struct pwm_chip *chip)
> return container_of(chip, struct pca9685, chip);
>  }
>
> +/* This function is supposed to be called with the prescaler_users_lock held 
> */
> +static inline bool pca9685_may_change_prescaler(struct pca9685 *pca, int 
> channel)

Drop the inline? Only the compiler knows if inlining this function makes sense
on a platform (armv7, x86, etc). Compilers are usually better at this then
humans...

Rename to pca9685_prescaler_can_change() ?

> +{
> +   /*
> +* A PWM channel may only change the prescaler if there are no users 
> of
> +* the prescaler yet or that same channel is the only one in use.
> +*/
> +   return bitmap_empty(pca->prescaler_users, PCA9685_MAXCHAN + 1) ||
> +   (bitmap_weight(pca->prescaler_users, PCA9685_MAXCHAN + 1) == 
> 1 &&
> +test_bit(channel, pca->prescaler_users));
> +}

I found this logic expression quite complex to read. Perhaps simplify by using
a few steps? For example:

/* if prescaler not in use, we can always change it */
if (empty) return true;
/* if more than one pwm is using the prescaler, we can never change it */
if (weight > 1) return false;
/* one pwm is using the prescaler, we can only change it if it's us */
return test_bit(us);

> +
>  static void pca9685_pwm_set_duty(struct pca9685 *pca, int channel, unsigned 
> int duty)
>  {
> unsigned int on, off;
> @@ -337,16 +351,25 @@ static int pca9685_pwm_apply(struct pwm_chip *chip, 
> struct pwm_device *pwm,
> duty = PCA9685_COUNTER_RANGE * state->duty_cycle;
> duty = DIV_ROUND_CLOSEST_ULL(duty, state->period);
>
> +   mutex_lock(>prescaler_users_lock);
> +
> if (!state->enabled || duty < 1) {
> pca9685_pwm_set_duty(pca, pwm->hwpwm, 0);
> -   return 0;
> +   goto prescaler_unused;
> } else if (duty == PCA9685_COUNTER_RANGE) {
> pca9685_pwm_set_duty(pca, pwm->hwpwm, duty);
> -   return 0;
> +   goto prescaler_unused;
> }
>
> regmap_read(pca->regmap, PCA9685_PRESCALE, );
> if (prescale != val) {
> +   if (!pca9685_may_change_prescaler(pca, pwm->hwpwm)) {
> +   mutex_unlock(>prescaler_users_lock);
> +   dev_err(chip->dev,
> +   "prescaler not set: already in use with 
> different setting!\n");
> +   return -EBUSY;
> +   }
> +
> /*
>  * Putting the chip briefly into SLEEP mode
>

Re: [PATCH v5 5/7] pwm: pca9685: Support staggered output ON times

[Sven Van Asbroeck]

Hi Clemens, see below.

On Wed, Dec 16, 2020 at 7:53 AM Clemens Gruber
 wrote:
>
> The PCA9685 supports staggered LED output ON times to minimize current
> surges and reduce EMI.
> When this new option is enabled, the ON times of each channel are
> delayed by channel number x counter range / 16, which avoids asserting
> all enabled outputs at the same counter value while still maintaining
> the configured duty cycle of each output.
>
> Signed-off-by: Clemens Gruber 
> ---
>  drivers/pwm/pwm-pca9685.c | 62 +++
>  1 file changed, 50 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/pwm/pwm-pca9685.c b/drivers/pwm/pwm-pca9685.c
> index 38aadaf50996..ff916980de49 100644
> --- a/drivers/pwm/pwm-pca9685.c
> +++ b/drivers/pwm/pwm-pca9685.c
> @@ -79,6 +79,7 @@
>  struct pca9685 {
> struct pwm_chip chip;
> struct regmap *regmap;
> +   bool staggered_outputs;
>  #if IS_ENABLED(CONFIG_GPIOLIB)
> struct mutex lock;
> struct gpio_chip gpio;
> @@ -93,45 +94,79 @@ static inline struct pca9685 *to_pca(struct pwm_chip 
> *chip)
>
>  static void pca9685_pwm_set_duty(struct pca9685 *pca, int channel, unsigned 
> int duty)
>  {
> +   unsigned int on, off;
> +
> if (duty == 0) {
> /* Set the full OFF bit, which has the highest precedence */
> regmap_write(pca->regmap, REG_OFF_H(channel), LED_FULL);
> +   return;
> } else if (duty >= PCA9685_COUNTER_RANGE) {
> /* Set the full ON bit and clear the full OFF bit */
> regmap_write(pca->regmap, REG_ON_H(channel), LED_FULL);
> regmap_write(pca->regmap, REG_OFF_H(channel), 0);
> -   } else {
> -   /* Set OFF time (clears the full OFF bit) */
> -   regmap_write(pca->regmap, REG_OFF_L(channel), duty & 0xff);
> -   regmap_write(pca->regmap, REG_OFF_H(channel), (duty >> 8) & 
> 0xf);
> -   /* Clear the full ON bit */
> -   regmap_write(pca->regmap, REG_ON_H(channel), 0);
> +   return;
> +   }
> +
> +   if (pca->staggered_outputs) {
> +   if (channel < PCA9685_MAXCHAN) {
> +   /*
> +* To reduce EMI, the ON times of each channel are
> +* spread out evenly within the counter range, while
> +* still maintaining the configured duty cycle
> +*/
> +   on = channel * PCA9685_COUNTER_RANGE / 
> PCA9685_MAXCHAN;
> +   off = (on + duty) % PCA9685_COUNTER_RANGE;
> +   regmap_write(pca->regmap, REG_ON_L(channel), on & 
> 0xff);
> +   regmap_write(pca->regmap, REG_ON_H(channel), (on >> 
> 8) & 0xf);
> +   regmap_write(pca->regmap, REG_OFF_L(channel), off & 
> 0xff);
> +   regmap_write(pca->regmap, REG_OFF_H(channel), (off >> 
> 8) & 0xf);
> +   return;
> +   }
> +   /* No staggering possible if "all LEDs" channel is used */
> +   regmap_write(pca->regmap, PCA9685_ALL_LED_ON_L, 0);
> }
> +   /* Set OFF time (clears the full OFF bit) */
> +   regmap_write(pca->regmap, REG_OFF_L(channel), duty & 0xff);
> +   regmap_write(pca->regmap, REG_OFF_H(channel), (duty >> 8) & 0xf);
> +   /* Clear the full ON bit */
> +   regmap_write(pca->regmap, REG_ON_H(channel), 0);
>  }

I find the set_duty() function quite hard to follow.
Can we simplify this by eliminating the !staggered_outputs special case?
E.g. always calculate and write 'on' and 'off'.
But if !staggered_outputs => on = 0 and off = duty.

Yes this adds one extra/unnecessary register write in the !staggered case,
but simplicity/maintainability >>> efficiency here. And this "issue" will
disappear when we switch on regmap caching.

>
>  static unsigned int pca9685_pwm_get_duty(struct pca9685 *pca, int channel)
>  {
> -   unsigned int off_h, val;
> +   unsigned int off, on, val;
>
> if (WARN_ON(channel >= PCA9685_MAXCHAN)) {
> /* Hardware readout not supported for "all LEDs" channel */
> return 0;
> }
>
> -   regmap_read(pca->regmap, LED_N_OFF_H(channel), _h);
> -   if (off_h & LED_FULL) {
> +   regmap_read(pca->regmap, LED_N_OFF_H(channel), );
> +   if (off & LED_FULL) {
> /* Full OFF bit is set */
> return 0;
> }
>
> -   regmap_read(pca->regmap, LED_N_ON_H(channel), );
> -   if (val & LED_FULL) {
> +   regmap_read(pca->regmap, LED_N_ON_H(channel), );
> +   if (on & LED_FULL) {
> /* Full ON bit is set */
> return PCA9685_COUNTER_RANGE;
> }
>
> regmap_read(pca->regmap, LED_N_OFF_L(channel), );
> -   return ((off_h & 0xf) << 8) | (val & 0xff);
> +   off = ((off & 0xf) << 8) | (val & 

Re: [PATCH v5 4/7] pwm: pca9685: Reset registers to POR state in probe

[Sven Van Asbroeck]

Hi Clemens, minor nit below.

On Wed, Dec 16, 2020 at 7:53 AM Clemens Gruber
 wrote:
>
> Reset the prescale and ON/OFF registers to their POR default state in
> the probe function. Otherwise, the PWMs could still be active after a
> watchdog reset and reboot, etc.
>
> Signed-off-by: Clemens Gruber 
> ---
>  drivers/pwm/pwm-pca9685.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pwm/pwm-pca9685.c b/drivers/pwm/pwm-pca9685.c
> index 7b14447f3c05..38aadaf50996 100644
> --- a/drivers/pwm/pwm-pca9685.c
> +++ b/drivers/pwm/pwm-pca9685.c
> @@ -47,6 +47,7 @@
>  #define PCA9685_ALL_LED_OFF_H  0xFD
>  #define PCA9685_PRESCALE   0xFE
>
> +#define PCA9685_PRESCALE_DEF   0x1E/* => default frequency of ~200 Hz */
>  #define PCA9685_PRESCALE_MIN   0x03/* => max. frequency of 1526 Hz */
>  #define PCA9685_PRESCALE_MAX   0xFF/* => min. frequency of 24 Hz */
>
> @@ -446,9 +447,11 @@ static int pca9685_pwm_probe(struct i2c_client *client,
> reg &= ~(MODE1_ALLCALL | MODE1_SUB1 | MODE1_SUB2 | MODE1_SUB3);
> regmap_write(pca->regmap, PCA9685_MODE1, reg);
>
> -   /* Clear all "full off" bits */
> +   /* Reset ON/OFF registers to HW defaults (only full OFF bit is set) */
> +   regmap_write(pca->regmap, PCA9685_ALL_LED_ON_L, 0);
> +   regmap_write(pca->regmap, PCA9685_ALL_LED_ON_H, 0);
> regmap_write(pca->regmap, PCA9685_ALL_LED_OFF_L, 0);
> -   regmap_write(pca->regmap, PCA9685_ALL_LED_OFF_H, 0);
> +   regmap_write(pca->regmap, PCA9685_ALL_LED_OFF_H, LED_FULL);
>
> pca->chip.ops = _pwm_ops;
> /* Add an extra channel for ALL_LED */
> @@ -470,8 +473,10 @@ static int pca9685_pwm_probe(struct i2c_client *client,
> /*
>  * The chip comes out of power-up in the sleep state,
>  * but force it to sleep in case it was woken up before
> +* and set the default prescale value
>  */
> pca9685_set_sleep_mode(pca, true);
> +   regmap_write(pca->regmap, PCA9685_PRESCALE, PCA9685_PRESCALE_DEF);
> pm_runtime_set_suspended(>dev);
> pm_runtime_enable(>dev);

Consider making it clearer that prescale can only be touched when the chip is
in sleep mode. Suggestion:

/* set the default prescale value - chip _must_ be in sleep mode */
regmap_write(pca->regmap, PCA9685_PRESCALE, PCA9685_PRESCALE_DEF);

>
> --
> 2.29.2
>

Re: [PATCH v5 2/7] pwm: pca9685: Support hardware readout

[Sven Van Asbroeck]

On Wed, Dec 16, 2020 at 7:53 AM Clemens Gruber
 wrote:
>
> Implements .get_state to read-out the current hardware state.
>

I am not convinced that we actually need this.

Looking at the pwm core, .get_state() is only called right after .request(),
to initialize the cached value of the state. The core then uses the cached
value throughout, it'll never read out the h/w again, until the next .request().

In our case, we know that the state right after request is always disabled,
because:
- we disable all pwm channels on probe (in PATCH v5 4/7)
- .free() disables the pwm channel

Conclusion: .get_state() will always return "pwm disabled", so why do we
bother reading out the h/w?

Of course, if we choose to leave the pwm enabled after .free(), then
.get_state() can even be left out! Do we want that? Genuine question, I do
not know the answer.

> The hardware readout may return slightly different values than those
> that were set in apply due to the limited range of possible prescale and
> counter register values.
>
> Also note that although the datasheet mentions 200 Hz as default
> frequency when using the internal 25 MHz oscillator, the calculated
> period from the default prescaler register setting of 30 is 5079040ns.
>
> Signed-off-by: Clemens Gruber 
> ---
>  drivers/pwm/pwm-pca9685.c | 41 +++
>  1 file changed, 41 insertions(+)
>
> diff --git a/drivers/pwm/pwm-pca9685.c b/drivers/pwm/pwm-pca9685.c
> index 1b5b5fb93b43..b3398963c0ff 100644
> --- a/drivers/pwm/pwm-pca9685.c
> +++ b/drivers/pwm/pwm-pca9685.c
> @@ -331,6 +331,46 @@ static int pca9685_pwm_apply(struct pwm_chip *chip, 
> struct pwm_device *pwm,
> return 0;
>  }
>
> +static void pca9685_pwm_get_state(struct pwm_chip *chip, struct pwm_device 
> *pwm,
> + struct pwm_state *state)
> +{
> +   struct pca9685 *pca = to_pca(chip);
> +   unsigned long long duty;
> +   unsigned int val;
> +
> +   /* Calculate (chip-wide) period from prescale value */
> +   regmap_read(pca->regmap, PCA9685_PRESCALE, );
> +   state->period = (PCA9685_COUNTER_RANGE * 1000 / 
> PCA9685_OSC_CLOCK_MHZ) *
> +   (val + 1);
> +
> +   /* The (per-channel) polarity is fixed */
> +   state->polarity = PWM_POLARITY_NORMAL;
> +
> +   if (pwm->hwpwm >= PCA9685_MAXCHAN) {
> +   /*
> +* The "all LEDs" channel does not support HW readout
> +* Return 0 and disabled for backwards compatibility
> +*/
> +   state->duty_cycle = 0;
> +   state->enabled = false;
> +   return;
> +   }
> +
> +   duty = pca9685_pwm_get_duty(pca, pwm->hwpwm);
> +
> +   state->enabled = !!duty;
> +   if (!state->enabled) {
> +   state->duty_cycle = 0;
> +   return;
> +   } else if (duty == PCA9685_COUNTER_RANGE) {
> +   state->duty_cycle = state->period;
> +   return;
> +   }
> +
> +   duty *= state->period;
> +   state->duty_cycle = duty / PCA9685_COUNTER_RANGE;
> +}
> +
>  static int pca9685_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
>  {
> struct pca9685 *pca = to_pca(chip);
> @@ -353,6 +393,7 @@ static void pca9685_pwm_free(struct pwm_chip *chip, 
> struct pwm_device *pwm)
>
>  static const struct pwm_ops pca9685_pwm_ops = {
> .apply = pca9685_pwm_apply,
> +   .get_state = pca9685_pwm_get_state,
> .request = pca9685_pwm_request,
> .free = pca9685_pwm_free,
> .owner = THIS_MODULE,
> --
> 2.29.2
>

Re: [kbuild-all] Re: ERROR: "snd_soc_new_ac97_component" undefined!

[Randy Dunlap]

On 12/16/20 7:15 PM, Rong Chen wrote:
> 
> 
> On 12/11/20 8:16 AM, Randy Dunlap wrote:
>> On 12/6/20 10:11 AM, kernel test robot wrote:
>>> Hi Geert,
>>>
>>> First bad commit (maybe != root cause):
>>>
>>> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
>>> master
>>> head:   7059c2c00a2196865c2139083cbef47cd18109b6
>>> commit: ea00d95200d02ece71f5814d41b14f2eb16d598b ASoC: Use imply for 
>>> SND_SOC_ALL_CODECS
>>> date:   10 months ago
>>> config: powerpc-randconfig-r012-20201207 (attached as .config)
>>> compiler: powerpc-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/torvalds/linux.git/commit/?id=ea00d95200d02ece71f5814d41b14f2eb16d598b
>>>  git remote add linus 
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>>>  git fetch --no-tags linus master
>>>  git checkout ea00d95200d02ece71f5814d41b14f2eb16d598b
>>>  # save the attached .config to linux build tree
>>>  COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
>>> ARCH=powerpc
>>>
>>> If you fix the issue, kindly add following tag as appropriate
>>> Reported-by: kernel test robot 
>>>
>>> All errors (new ones prefixed by >>):
>>>
>>>     ERROR: "mpc5200_audio_dma_create" [sound/soc/fsl/mpc5200_psc_ac97.ko] 
>>> undefined!
>>>     ERROR: "mpc5200_audio_dma_destroy" [sound/soc/fsl/mpc5200_psc_ac97.ko] 
>>> undefined!
> ERROR: "snd_soc_new_ac97_component" 
> [sound/soc/codecs/snd-soc-stac9766.ko] undefined!
> ERROR: "snd_soc_free_ac97_component" 
> [sound/soc/codecs/snd-soc-stac9766.ko] undefined!
>>>     ERROR: "snd_soc_new_ac97_component" 
>>> [sound/soc/codecs/snd-soc-ad1980.ko] undefined!
>>>     ERROR: "snd_soc_free_ac97_component" 
>>> [sound/soc/codecs/snd-soc-ad1980.ko] undefined!
>>
>> I also see these:
>>
>> ERROR: modpost: "__regmap_init_ac97" [sound/soc/codecs/snd-soc-stac9766.ko] 
>> undefined!
>> ERROR: modpost: "regmap_ac97_default_volatile" 
>> [sound/soc/codecs/snd-soc-stac9766.ko] undefined!
>>
>> and the (usual) missing Kconfig warnings:    :(
>>
>> WARNING: unmet direct dependencies detected for SND_SOC_MPC5200_AC97
>>    Depends on [n]: SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && 
>> SND_POWERPC_SOC [=m] && PPC_MPC52xx [=y] && PPC_BESTCOMM [=n]
>>    Selected by [m]:
>>    - SND_MPC52xx_SOC_EFIKA [=m] && SOUND [=m] && !UML && SND [=m] && SND_SOC 
>> [=m] && SND_POWERPC_SOC [=m] && PPC_EFIKA [=y]
>>
>> WARNING: unmet direct dependencies detected for SND_SOC_STAC9766
>>    Depends on [n]: SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && 
>> SND_SOC_AC97_BUS [=n]
>>    Selected by [m]:
>>    - SND_MPC52xx_SOC_EFIKA [=m] && SOUND [=m] && !UML && SND [=m] && SND_SOC 
>> [=m] && SND_POWERPC_SOC [=m] && PPC_EFIKA [=y]
>>
>> WARNING: unmet direct dependencies detected for HOTPLUG_CPU
>>    Depends on [n]: SMP [=y] && (PPC_PSERIES [=n] || PPC_PMAC [=n] || 
>> PPC_POWERNV [=n] || FSL_SOC_BOOKE [=n])
>>    Selected by [y]:
>>    - PM_SLEEP_SMP [=y] && SMP [=y] && (ARCH_SUSPEND_POSSIBLE [=y] || 
>> ARCH_HIBERNATION_POSSIBLE [=y]) && PM_SLEEP [=y]
>>
>>
>>
>> Please begin including Kconfig warnings. I have asked previously but...
>>
>> thanks.
> 
> Hi Randy,
> 
> We have added Kconfig warnings in reports now. please see another report: 
> https://lore.kernel.org/linux-block/202012170150.y7ycoei9-...@intel.com/

Great!  Thank you for doing this.

-- 
~Randy

Re: [PATCH v5 1/7] pwm: pca9685: Switch to atomic API

[Sven Van Asbroeck]

Hi Clemens, this looks compact, simple and neat. I like it a lot !!

Few very minor nits below.

On Wed, Dec 16, 2020 at 7:53 AM Clemens Gruber
 wrote:
>
> The switch to the atomic API goes hand in hand with a few fixes to
> previously experienced issues:
> - The duty cycle is no longer lost after disable/enable (previously the
>   OFF registers were cleared in disable and the user was required to
>   call config to restore the duty cycle settings)
> - If one sets a period resulting in the same prescale register value,
>   the sleep and write to the register is now skipped
>
> Signed-off-by: Clemens Gruber 
> ---
> Changes since v4:
> - Patches split up
> - Use a single set_duty function
> - Improve readability / new macros
> - Added a patch to restrict prescale changes to the first user
>
> Changes since v3:
> - Refactoring: Extracted common functions
> - Read prescale register value instead of caching it
> - Return all zeros and disabled for "all LEDs" channel state
> - Improved duty calculation / mapping to 0..4096
>
> Changes since v2:
> - Always set default prescale value in probe
> - Simplified probe code
> - Inlined functions with one callsite
>
> Changes since v1:
> - Fixed a logic error
> - Impoved PM runtime handling and fixed !CONFIG_PM
> - Write default prescale reg value if invalid in probe
> - Reuse full_off/_on functions throughout driver
> - Use cached prescale value whenever possible
>
>  drivers/pwm/pwm-pca9685.c | 253 +-
>  1 file changed, 87 insertions(+), 166 deletions(-)
>
> diff --git a/drivers/pwm/pwm-pca9685.c b/drivers/pwm/pwm-pca9685.c
> index 4a55dc18656c..1b5b5fb93b43 100644
> --- a/drivers/pwm/pwm-pca9685.c
> +++ b/drivers/pwm/pwm-pca9685.c
> @@ -51,7 +51,6 @@
>  #define PCA9685_PRESCALE_MAX   0xFF/* => min. frequency of 24 Hz */
>
>  #define PCA9685_COUNTER_RANGE  4096
> -#define PCA9685_DEFAULT_PERIOD 500 /* Default period_ns = 1/200 Hz */
>  #define PCA9685_OSC_CLOCK_MHZ  25  /* Internal oscillator with 25 MHz */
>
>  #define PCA9685_NUMREGS0xFF
> @@ -71,10 +70,14 @@
>  #define LED_N_OFF_H(N) (PCA9685_LEDX_OFF_H + (4 * (N)))
>  #define LED_N_OFF_L(N) (PCA9685_LEDX_OFF_L + (4 * (N)))
>
> +#define REG_ON_H(C)((C) >= PCA9685_MAXCHAN ? PCA9685_ALL_LED_ON_H : 
> LED_N_ON_H((C)))
> +#define REG_ON_L(C)((C) >= PCA9685_MAXCHAN ? PCA9685_ALL_LED_ON_L : 
> LED_N_ON_L((C)))
> +#define REG_OFF_H(C)   ((C) >= PCA9685_MAXCHAN ? PCA9685_ALL_LED_OFF_H : 
> LED_N_OFF_H((C)))
> +#define REG_OFF_L(C)   ((C) >= PCA9685_MAXCHAN ? PCA9685_ALL_LED_OFF_L : 
> LED_N_OFF_L((C)))

Yes !!

> +
>  struct pca9685 {
> struct pwm_chip chip;
> struct regmap *regmap;
> -   int period_ns;
>  #if IS_ENABLED(CONFIG_GPIOLIB)
> struct mutex lock;
> struct gpio_chip gpio;
> @@ -87,6 +90,49 @@ static inline struct pca9685 *to_pca(struct pwm_chip *chip)
> return container_of(chip, struct pca9685, chip);
>  }
>
> +static void pca9685_pwm_set_duty(struct pca9685 *pca, int channel, unsigned 
> int duty)
> +{

Add brief function documentation to clarify that 'duty' sets the duty cycle
_ratio_ to 'duty/4096' on ? I.e.
duty == 2048 => duty cycle ratio = 2048/4096 = 50%  on
duty == 4096 => duty cycle ratio = 4096/4086 = 100% on etc

> +   if (duty == 0) {
> +   /* Set the full OFF bit, which has the highest precedence */
> +   regmap_write(pca->regmap, REG_OFF_H(channel), LED_FULL);
> +   } else if (duty >= PCA9685_COUNTER_RANGE) {
> +   /* Set the full ON bit and clear the full OFF bit */
> +   regmap_write(pca->regmap, REG_ON_H(channel), LED_FULL);
> +   regmap_write(pca->regmap, REG_OFF_H(channel), 0);
> +   } else {
> +   /* Set OFF time (clears the full OFF bit) */
> +   regmap_write(pca->regmap, REG_OFF_L(channel), duty & 0xff);
> +   regmap_write(pca->regmap, REG_OFF_H(channel), (duty >> 8) & 
> 0xf);
> +   /* Clear the full ON bit */
> +   regmap_write(pca->regmap, REG_ON_H(channel), 0);
> +   }
> +}
> +
> +static unsigned int pca9685_pwm_get_duty(struct pca9685 *pca, int channel)
> +{
> +   unsigned int off_h, val;
> +
> +   if (WARN_ON(channel >= PCA9685_MAXCHAN)) {
> +   /* Hardware readout not supported for "all LEDs" channel */
> +   return 0;
> +   }
> +
> +   regmap_read(pca->regmap, LED_N_OFF_H(channel), _h);
> +   if (off_h & LED_FULL) {

I believe this may trigger bots which are monitoring patches on LKML:
if regmap_read() somehow fails, off_h will be used uninitialized.

Prevent by initializing off_h and val?

> +   /* Full OFF bit is set */
> +   return 0;
> +   }
> +
> +   regmap_read(pca->regmap, LED_N_ON_H(channel), );
> +   if (val & LED_FULL) {
> +   /* Full ON bit is set */
> +   return PCA9685_COUNTER_RANGE;
> +   }
> +
> +   

Re: [PATCH] media: vsp1: Fix an error handling path in the probe function

[Laurent Pinchart]

Hi Christophe,

Thank you for the patch.

On Sat, Dec 12, 2020 at 06:41:19PM +0100, Christophe JAILLET wrote:
> A previous 'rcar_fcp_get()' call must be undone in the error handling path,
> as already done in the remove function.
> 
> Fixes: 94fcdf829793 ("[media] v4l: vsp1: Add FCP support")
> Signed-off-by: Christophe JAILLET 

Reviewed-by: Laurent Pinchart 

and queued in my tree for v5.12.

> ---
>  drivers/media/platform/vsp1/vsp1_drv.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
> b/drivers/media/platform/vsp1/vsp1_drv.c
> index dc62533cf32c..aa66e4f5f3f3 100644
> --- a/drivers/media/platform/vsp1/vsp1_drv.c
> +++ b/drivers/media/platform/vsp1/vsp1_drv.c
> @@ -882,8 +882,10 @@ static int vsp1_probe(struct platform_device *pdev)
>   }
>  
>  done:
> - if (ret)
> + if (ret) {
>   pm_runtime_disable(>dev);
> + rcar_fcp_put(vsp1->fcp);
> + }
>  
>   return ret;
>  }

-- 
Regards,

Laurent Pinchart

Re: [PATCH 031/141] ext4: Fix fall-through warnings for Clang

[Theodore Y. Ts'o]

On Fri, Nov 20, 2020 at 12:28:32PM -0600, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
> by explicitly adding a break statement instead of just letting the code
> fall through to the next case.
> 
> Link: https://github.com/KSPP/linux/issues/115
> Signed-off-by: Gustavo A. R. Silva 

Thanks, applied.

- Ted