Re: [PATCH v8 3/4] phy: Add Sparx5 ethernet serdes PHY driver

[Alexandre Belloni]

Hi Russell,

On 03/12/2020 22:52:33+, Russell King - ARM Linux admin wrote:
> You still have not Cc'd me on your patches. Please can you either:
> 
> 1) use get_maintainer.pl to find out whom you should be sending
>your patches to
> or
> 2) include me in your cc for this patch set as phylink maintainer in
>your patch set so I can review your use of phylink.
> 

Note that this series is different from the network (switchdev) driver
series and doesn't make use of phylink.

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

[PATCH v2 4/5] dt-bindings: interconnect: Add Qualcomm MSM8939 DT bindings

[Jun Nie]

The Qualcomm MSM8939 platform has several bus fabrics that could be
controlled and tuned dynamically according to the bandwidth demand.

Signed-off-by: Jun Nie 
Reviewed-by: Rob Herring 
---
 .../bindings/interconnect/qcom,rpm.yaml   |   4 +
 .../dt-bindings/interconnect/qcom,msm8939.h   | 105 ++
 2 files changed, 109 insertions(+)
 create mode 100644 include/dt-bindings/interconnect/qcom,msm8939.h

diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml 
b/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml
index d720b68b3ead..983d71fb5399 100644
--- a/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml
+++ b/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml
@@ -23,6 +23,10 @@ properties:
   - qcom,msm8916-bimc
   - qcom,msm8916-pcnoc
   - qcom,msm8916-snoc
+  - qcom,msm8939-bimc
+  - qcom,msm8939-pcnoc
+  - qcom,msm8939-snoc
+  - qcom,msm8939-snoc-mm
   - qcom,qcs404-bimc
   - qcom,qcs404-pcnoc
   - qcom,qcs404-snoc
diff --git a/include/dt-bindings/interconnect/qcom,msm8939.h 
b/include/dt-bindings/interconnect/qcom,msm8939.h
new file mode 100644
index ..c22369a4b9f5
--- /dev/null
+++ b/include/dt-bindings/interconnect/qcom,msm8939.h
@@ -0,0 +1,105 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Qualcomm interconnect IDs
+ *
+ * Copyright (c) 2020, Linaro Ltd.
+ * Author: Jun Nie 
+ */
+
+#ifndef __DT_BINDINGS_INTERCONNECT_QCOM_MSM8939_H
+#define __DT_BINDINGS_INTERCONNECT_QCOM_MSM8939_H
+
+#define BIMC_SNOC_SLV  0
+#define MASTER_QDSS_BAM1
+#define MASTER_QDSS_ETR2
+#define MASTER_SNOC_CFG3
+#define PCNOC_SNOC_SLV 4
+#define SLAVE_APSS 5
+#define SLAVE_CATS_128 6
+#define SLAVE_OCMEM_64 7
+#define SLAVE_IMEM 8
+#define SLAVE_QDSS_STM 9
+#define SLAVE_SRVC_SNOC10
+#define SNOC_BIMC_0_MAS11
+#define SNOC_BIMC_1_MAS12
+#define SNOC_BIMC_2_MAS13
+#define SNOC_INT_0 14
+#define SNOC_INT_1 15
+#define SNOC_INT_BIMC  16
+#define SNOC_PCNOC_MAS 17
+#define SNOC_QDSS_INT  18
+
+#define MASTER_VIDEO_P00
+#define MASTER_JPEG1
+#define MASTER_VFE 2
+#define MASTER_MDP_PORT0   3
+#define MASTER_MDP_PORT1   4
+#define MASTER_CPP 5
+#define SNOC_MM_INT_0  6
+#define SNOC_MM_INT_1  7
+#define SNOC_MM_INT_2  8
+
+#define BIMC_SNOC_MAS  0
+#define MASTER_AMPSS_M01
+#define MASTER_GRAPHICS_3D 2
+#define MASTER_TCU03
+#define SLAVE_AMPSS_L2 4
+#define SLAVE_EBI_CH0  5
+#define SNOC_BIMC_0_SLV6
+#define SNOC_BIMC_1_SLV7
+#define SNOC_BIMC_2_SLV8
+
+#define MASTER_BLSP_1  0
+#define MASTER_DEHR1
+#define MASTER_LPASS   2
+#define MASTER_CRYPTO_CORE03
+#define MASTER_SDCC_1  4
+#define MASTER_SDCC_2  5
+#define MASTER_SPDM6
+#define MASTER_USB_HS1 7
+#define MASTER_USB_HS2 8
+#define PCNOC_INT_09
+#define PCNOC_INT_110
+#define PCNOC_MAS_011
+#define PCNOC_MAS_112
+#define PCNOC_SLV_013
+#define PCNOC_SLV_114
+#define PCNOC_SLV_215
+#define PCNOC_SLV_316
+#define PCNOC_SLV_417
+#define PCNOC_SLV_818
+#define PCNOC_SLV_919
+#define PCNOC_SNOC_MAS 20
+#define SLAVE_BIMC_CFG 21
+#define SLAVE_BLSP_1   22
+#define SLAVE_BOOT_ROM 23
+#define SLAVE_CAMERA_CFG   24
+#define SLAVE_CLK_CTL  25
+#define SLAVE_CRYPTO_0_CFG 26
+#define SLAVE_DEHR_CFG 27
+#define SLAVE_DISPLAY_CFG  28
+#define SLAVE_GRAPHICS_3D_CFG  29
+#define SLAVE_IMEM_CFG 30
+#define SLAVE_LPASS31
+#define SLAVE_MPM  32
+#define SLAVE_MSG_RAM  33
+#define SLAVE_MSS  34
+#define SLAVE_PDM  35
+#define SLAVE_PMIC_ARB 36
+#define SLAVE_PCNOC_CFG37
+#define SLAVE_PRNG 38
+#define SLAVE_QDSS_CFG 39
+#define SLAVE_RBCPR_CFG40

Re: [RFC v2 2/2] [MOCKUP] sched/mm: Lightweight lazy mm refcounting

[Nicholas Piggin]

Excerpts from Andy Lutomirski's message of December 4, 2020 3:26 pm:
> This is a mockup.  It's designed to illustrate the algorithm and how the
> code might be structured.  There are several things blatantly wrong with
> it:
> 
> The coding stype is not up to kernel standards.  I have prototypes in the
> wrong places and other hacks.
> 
> There's a problem with mm_cpumask() not being reliable.

Interesting, this might be a way to reduce those IPIs with fairly 
minimal fast path cost. Would be interesting to see how much performance 
advantage it has over my dumb simple shoot-lazies.

For powerpc I don't think we'd be inclined to go that way, so don't feel 
the need to add this complexity for us alone -- we'd be more inclined to 
move the exit lazy to the final TLB shootdown path, which we're slowly 
getting more infrastructure in place to do.

(The powerpc hash MMU code which we're slowly moving away from might 
never get that capability because it's complex there and hard to do with
that virtualisation model so current big systems (and radix MMU until we
finish the TLB flushing stuff) want something here, but for those the
shoot-lazies could quite likely be sufficient)

But if core code was moved over to something like this for the benefit of
others archs we'd probably just as happily do that.

There's a few nits but I don't think I can see a fundamental problem 
yet.

Thanks,
Nick

[PATCH v2 5/5] interconnect: qcom: Add MSM8939 interconnect provider driver

[Jun Nie]

Add driver for the Qualcomm interconnect buses found in MSM8939 based
platforms. The topology consists of four NoCs that are controlled by
a remote processor that collects the aggregated bandwidth for each
master-slave pairs.

Signed-off-by: Jun Nie 
---
 drivers/interconnect/qcom/Kconfig   |   9 +
 drivers/interconnect/qcom/Makefile  |   2 +
 drivers/interconnect/qcom/msm8939.c | 355 
 3 files changed, 366 insertions(+)
 create mode 100644 drivers/interconnect/qcom/msm8939.c

diff --git a/drivers/interconnect/qcom/Kconfig 
b/drivers/interconnect/qcom/Kconfig
index a8f93ba265f8..a469470b4e4f 100644
--- a/drivers/interconnect/qcom/Kconfig
+++ b/drivers/interconnect/qcom/Kconfig
@@ -17,6 +17,15 @@ config INTERCONNECT_QCOM_MSM8916
  This is a driver for the Qualcomm Network-on-Chip on msm8916-based
  platforms.
 
+config INTERCONNECT_QCOM_MSM8939
+   tristate "Qualcomm MSM8939 interconnect driver"
+   depends on INTERCONNECT_QCOM
+   depends on QCOM_SMD_RPM
+   select INTERCONNECT_QCOM_SMD_RPM
+   help
+ This is a driver for the Qualcomm Network-on-Chip on msm8939-based
+ platforms.
+
 config INTERCONNECT_QCOM_MSM8974
tristate "Qualcomm MSM8974 interconnect driver"
depends on INTERCONNECT_QCOM
diff --git a/drivers/interconnect/qcom/Makefile 
b/drivers/interconnect/qcom/Makefile
index 916d7bbe55b7..709f65d2447d 100644
--- a/drivers/interconnect/qcom/Makefile
+++ b/drivers/interconnect/qcom/Makefile
@@ -2,6 +2,7 @@
 
 icc-bcm-voter-objs := bcm-voter.o
 qnoc-msm8916-objs  := msm8916.o
+qnoc-msm8939-objs  := msm8939.o
 qnoc-msm8974-objs  := msm8974.o
 icc-osm-l3-objs:= osm-l3.o
 qnoc-qcs404-objs   := qcs404.o
@@ -14,6 +15,7 @@ icc-smd-rpm-objs  := smd-rpm.o icc-rpm.o
 
 obj-$(CONFIG_INTERCONNECT_QCOM_BCM_VOTER) += icc-bcm-voter.o
 obj-$(CONFIG_INTERCONNECT_QCOM_MSM8916) += qnoc-msm8916.o
+obj-$(CONFIG_INTERCONNECT_QCOM_MSM8939) += qnoc-msm8939.o
 obj-$(CONFIG_INTERCONNECT_QCOM_MSM8974) += qnoc-msm8974.o
 obj-$(CONFIG_INTERCONNECT_QCOM_OSM_L3) += icc-osm-l3.o
 obj-$(CONFIG_INTERCONNECT_QCOM_QCS404) += qnoc-qcs404.o
diff --git a/drivers/interconnect/qcom/msm8939.c 
b/drivers/interconnect/qcom/msm8939.c
new file mode 100644
index ..dfbec30ed149
--- /dev/null
+++ b/drivers/interconnect/qcom/msm8939.c
@@ -0,0 +1,355 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Linaro Ltd
+ * Author: Jun Nie 
+ * With reference of msm8916 interconnect driver of Georgi Djakov.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "smd-rpm.h"
+#include "icc-rpm.h"
+
+enum {
+   MSM8939_BIMC_SNOC_MAS = 1,
+   MSM8939_BIMC_SNOC_SLV,
+   MSM8939_MASTER_AMPSS_M0,
+   MSM8939_MASTER_LPASS,
+   MSM8939_MASTER_BLSP_1,
+   MSM8939_MASTER_DEHR,
+   MSM8939_MASTER_GRAPHICS_3D,
+   MSM8939_MASTER_JPEG,
+   MSM8939_MASTER_MDP_PORT0,
+   MSM8939_MASTER_MDP_PORT1,
+   MSM8939_MASTER_CPP,
+   MSM8939_MASTER_CRYPTO_CORE0,
+   MSM8939_MASTER_SDCC_1,
+   MSM8939_MASTER_SDCC_2,
+   MSM8939_MASTER_QDSS_BAM,
+   MSM8939_MASTER_QDSS_ETR,
+   MSM8939_MASTER_SNOC_CFG,
+   MSM8939_MASTER_SPDM,
+   MSM8939_MASTER_TCU0,
+   MSM8939_MASTER_USB_HS1,
+   MSM8939_MASTER_USB_HS2,
+   MSM8939_MASTER_VFE,
+   MSM8939_MASTER_VIDEO_P0,
+   MSM8939_SNOC_MM_INT_0,
+   MSM8939_SNOC_MM_INT_1,
+   MSM8939_SNOC_MM_INT_2,
+   MSM8939_PNOC_INT_0,
+   MSM8939_PNOC_INT_1,
+   MSM8939_PNOC_MAS_0,
+   MSM8939_PNOC_MAS_1,
+   MSM8939_PNOC_SLV_0,
+   MSM8939_PNOC_SLV_1,
+   MSM8939_PNOC_SLV_2,
+   MSM8939_PNOC_SLV_3,
+   MSM8939_PNOC_SLV_4,
+   MSM8939_PNOC_SLV_8,
+   MSM8939_PNOC_SLV_9,
+   MSM8939_PNOC_SNOC_MAS,
+   MSM8939_PNOC_SNOC_SLV,
+   MSM8939_SNOC_QDSS_INT,
+   MSM8939_SLAVE_AMPSS_L2,
+   MSM8939_SLAVE_APSS,
+   MSM8939_SLAVE_LPASS,
+   MSM8939_SLAVE_BIMC_CFG,
+   MSM8939_SLAVE_BLSP_1,
+   MSM8939_SLAVE_BOOT_ROM,
+   MSM8939_SLAVE_CAMERA_CFG,
+   MSM8939_SLAVE_CATS_128,
+   MSM8939_SLAVE_OCMEM_64,
+   MSM8939_SLAVE_CLK_CTL,
+   MSM8939_SLAVE_CRYPTO_0_CFG,
+   MSM8939_SLAVE_DEHR_CFG,
+   MSM8939_SLAVE_DISPLAY_CFG,
+   MSM8939_SLAVE_EBI_CH0,
+   MSM8939_SLAVE_GRAPHICS_3D_CFG,
+   MSM8939_SLAVE_IMEM_CFG,
+   MSM8939_SLAVE_IMEM,
+   MSM8939_SLAVE_MPM,
+   MSM8939_SLAVE_MSG_RAM,
+   MSM8939_SLAVE_MSS,
+   MSM8939_SLAVE_PDM,
+   MSM8939_SLAVE_PMIC_ARB,
+   MSM8939_SLAVE_PNOC_CFG,
+   MSM8939_SLAVE_PRNG,
+   MSM8939_SLAVE_QDSS_CFG,
+   MSM8939_SLAVE_QDSS_STM,
+   MSM8939_SLAVE_RBCPR_CFG,
+   MSM8939_SLAVE_SDCC_1,
+   MSM8939_SLAVE_SDCC_2,
+   MSM8939_SLAVE_SECURITY,
+   

[PATCH v2 3/5] dt-bindings: interconnect: single yaml file for RPM interconnect drivers

[Jun Nie]

MSM8916 and QCS404 bindings are almost identical, so combine them into one.
This will make it easier to add interconnect bindings for more SoC with RPM.

Signed-off-by: Jun Nie 
Reviewed-by: Rob Herring 
---
 .../bindings/interconnect/qcom,qcs404.yaml| 77 ---
 .../{qcom,msm8916.yaml => qcom,rpm.yaml}  | 18 +++--
 2 files changed, 11 insertions(+), 84 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/interconnect/qcom,qcs404.yaml
 rename Documentation/devicetree/bindings/interconnect/{qcom,msm8916.yaml => 
qcom,rpm.yaml} (81%)

diff --git a/Documentation/devicetree/bindings/interconnect/qcom,qcs404.yaml 
b/Documentation/devicetree/bindings/interconnect/qcom,qcs404.yaml
deleted file mode 100644
index 3fbb8785fbc9..
--- a/Documentation/devicetree/bindings/interconnect/qcom,qcs404.yaml
+++ /dev/null
@@ -1,77 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-%YAML 1.2

-$id: http://devicetree.org/schemas/interconnect/qcom,qcs404.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Qualcomm QCS404 Network-On-Chip interconnect
-
-maintainers:
-  - Georgi Djakov 
-
-description: |
-  The Qualcomm QCS404 interconnect providers support adjusting the
-  bandwidth requirements between the various NoC fabrics.
-
-properties:
-  reg:
-maxItems: 1
-
-  compatible:
-enum:
-  - qcom,qcs404-bimc
-  - qcom,qcs404-pcnoc
-  - qcom,qcs404-snoc
-
-  '#interconnect-cells':
-const: 1
-
-  clock-names:
-items:
-  - const: bus
-  - const: bus_a
-
-  clocks:
-items:
-  - description: Bus Clock
-  - description: Bus A Clock
-
-required:
-  - compatible
-  - reg
-  - '#interconnect-cells'
-  - clock-names
-  - clocks
-
-additionalProperties: false
-
-examples:
-  - |
-  #include 
-
-  bimc: interconnect@40 {
-  reg = <0x0040 0x8>;
-  compatible = "qcom,qcs404-bimc";
-  #interconnect-cells = <1>;
-  clock-names = "bus", "bus_a";
-  clocks = < RPM_SMD_BIMC_CLK>,
-   < RPM_SMD_BIMC_A_CLK>;
-  };
-
-  pnoc: interconnect@50 {
- reg = <0x0050 0x15080>;
- compatible = "qcom,qcs404-pcnoc";
- #interconnect-cells = <1>;
- clock-names = "bus", "bus_a";
- clocks = < RPM_SMD_PNOC_CLK>,
-  < RPM_SMD_PNOC_A_CLK>;
-  };
-
-  snoc: interconnect@58 {
-reg = <0x0058 0x23080>;
-compatible = "qcom,qcs404-snoc";
-#interconnect-cells = <1>;
-clock-names = "bus", "bus_a";
-clocks = < RPM_SMD_SNOC_CLK>,
- < RPM_SMD_SNOC_A_CLK>;
-  };
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,msm8916.yaml 
b/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml
similarity index 81%
rename from Documentation/devicetree/bindings/interconnect/qcom,msm8916.yaml
rename to Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml
index e1009ae4e8f7..d720b68b3ead 100644
--- a/Documentation/devicetree/bindings/interconnect/qcom,msm8916.yaml
+++ b/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml
@@ -1,27 +1,31 @@
 # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
 %YAML 1.2
 ---
-$id: http://devicetree.org/schemas/interconnect/qcom,msm8916.yaml#
+$id: http://devicetree.org/schemas/interconnect/qcom,rpm.yaml#
 $schema: http://devicetree.org/meta-schemas/core.yaml#
 
-title: Qualcomm MSM8916 Network-On-Chip interconnect
+title: Qualcomm RPM Network-On-Chip Interconnect
 
 maintainers:
   - Georgi Djakov 
 
 description: |
-  The Qualcomm MSM8916 interconnect providers support adjusting the
-  bandwidth requirements between the various NoC fabrics.
+  RPM interconnect providers support system bandwidth requirements through
+  RPM processor. The provider is able to communicate with the RPM through
+  the RPM shared memory device.
 
 properties:
+  reg:
+maxItems: 1
+
   compatible:
 enum:
   - qcom,msm8916-bimc
   - qcom,msm8916-pcnoc
   - qcom,msm8916-snoc
-
-  reg:
-maxItems: 1
+  - qcom,qcs404-bimc
+  - qcom,qcs404-pcnoc
+  - qcom,qcs404-snoc
 
   '#interconnect-cells':
 const: 1
-- 
2.17.1

[PATCH v2 2/5] interconnect: qcom: qcs404: use shared code

[Jun Nie]

Use shared code for aggregate functionalities and probe function
to remove duplicated code.

Signed-off-by: Jun Nie 
---
 drivers/interconnect/qcom/qcs404.c | 242 +
 1 file changed, 8 insertions(+), 234 deletions(-)

diff --git a/drivers/interconnect/qcom/qcs404.c 
b/drivers/interconnect/qcom/qcs404.c
index 9820709b43db..36a7e30a00be 100644
--- a/drivers/interconnect/qcom/qcs404.c
+++ b/drivers/interconnect/qcom/qcs404.c
@@ -9,15 +9,12 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
-#include 
+#include 
 
-#include "smd-rpm.h"
 
-#define RPM_BUS_MASTER_REQ 0x73616d62
-#define RPM_BUS_SLAVE_REQ  0x766c7362
+#include "smd-rpm.h"
+#include "icc-rpm.h"
 
 enum {
QCS404_MASTER_AMPSS_M0 = 1,
@@ -95,67 +92,11 @@ enum {
QCS404_SLAVE_LPASS,
 };
 
-#define to_qcom_provider(_provider) \
-   container_of(_provider, struct qcom_icc_provider, provider)
-
-static const struct clk_bulk_data bus_clocks[] = {
+static const struct clk_bulk_data qcs404_bus_clocks[] = {
{ .id = "bus" },
{ .id = "bus_a" },
 };
 
-/**
- * struct qcom_icc_provider - Qualcomm specific interconnect provider
- * @provider: generic interconnect provider
- * @bus_clks: the clk_bulk_data table of bus clocks
- * @num_clks: the total number of clk_bulk_data entries
- */
-struct qcom_icc_provider {
-   struct icc_provider provider;
-   struct clk_bulk_data *bus_clks;
-   int num_clks;
-};
-
-#define QCS404_MAX_LINKS   12
-
-/**
- * struct qcom_icc_node - Qualcomm specific interconnect nodes
- * @name: the node name used in debugfs
- * @id: a unique node identifier
- * @links: an array of nodes where we can go next while traversing
- * @num_links: the total number of @links
- * @buswidth: width of the interconnect between a node and the bus (bytes)
- * @mas_rpm_id:RPM id for devices that are bus masters
- * @slv_rpm_id:RPM id for devices that are bus slaves
- * @rate: current bus clock rate in Hz
- */
-struct qcom_icc_node {
-   unsigned char *name;
-   u16 id;
-   u16 links[QCS404_MAX_LINKS];
-   u16 num_links;
-   u16 buswidth;
-   int mas_rpm_id;
-   int slv_rpm_id;
-   u64 rate;
-};
-
-struct qcom_icc_desc {
-   struct qcom_icc_node **nodes;
-   size_t num_nodes;
-};
-
-#define DEFINE_QNODE(_name, _id, _buswidth, _mas_rpm_id, _slv_rpm_id,  \
-...)   \
-   static struct qcom_icc_node _name = {   \
-   .name = #_name, \
-   .id = _id,  \
-   .buswidth = _buswidth,  \
-   .mas_rpm_id = _mas_rpm_id,  \
-   .slv_rpm_id = _slv_rpm_id,  \
-   .num_links = ARRAY_SIZE(((int[]){ __VA_ARGS__ })),  \
-   .links = { __VA_ARGS__ },   \
-   }
-
 DEFINE_QNODE(mas_apps_proc, QCS404_MASTER_AMPSS_M0, 8, 0, -1, 
QCS404_SLAVE_EBI_CH0, QCS404_BIMC_SNOC_SLV);
 DEFINE_QNODE(mas_oxili, QCS404_MASTER_GRAPHICS_3D, 8, -1, -1, 
QCS404_SLAVE_EBI_CH0, QCS404_BIMC_SNOC_SLV);
 DEFINE_QNODE(mas_mdp, QCS404_MASTER_MDP_PORT0, 8, -1, -1, 
QCS404_SLAVE_EBI_CH0, QCS404_BIMC_SNOC_SLV);
@@ -327,178 +268,11 @@ static struct qcom_icc_desc qcs404_snoc = {
.num_nodes = ARRAY_SIZE(qcs404_snoc_nodes),
 };
 
-static int qcom_icc_set(struct icc_node *src, struct icc_node *dst)
-{
-   struct qcom_icc_provider *qp;
-   struct qcom_icc_node *qn;
-   struct icc_provider *provider;
-   struct icc_node *n;
-   u64 sum_bw;
-   u64 max_peak_bw;
-   u64 rate;
-   u32 agg_avg = 0;
-   u32 agg_peak = 0;
-   int ret, i;
-
-   qn = src->data;
-   provider = src->provider;
-   qp = to_qcom_provider(provider);
-
-   list_for_each_entry(n, >nodes, node_list)
-   provider->aggregate(n, 0, n->avg_bw, n->peak_bw,
-   _avg, _peak);
-
-   sum_bw = icc_units_to_bps(agg_avg);
-   max_peak_bw = icc_units_to_bps(agg_peak);
-
-   /* send bandwidth request message to the RPM processor */
-   if (qn->mas_rpm_id != -1) {
-   ret = qcom_icc_rpm_smd_send(QCOM_SMD_RPM_ACTIVE_STATE,
-   RPM_BUS_MASTER_REQ,
-   qn->mas_rpm_id,
-   sum_bw);
-   if (ret) {
-   pr_err("qcom_icc_rpm_smd_send mas %d error %d\n",
-  qn->mas_rpm_id, ret);
-   return ret;
-   }
-   }
-
-   if (qn->slv_rpm_id != -1) {
-   ret = qcom_icc_rpm_smd_send(QCOM_SMD_RPM_ACTIVE_STATE,
-   RPM_BUS_SLAVE_REQ,
-

[PATCH v2 1/5] interconnect: qcom: Consolidate interconnect RPM support

[Jun Nie]

Add RPM based interconnect driver implements the set and aggregate
functionalities that translates bandwidth requests into RPM messages.
These modules provide a common set of functionalities for all
Qualcomm RPM based interconnect providers and should help reduce code
duplication when adding new providers.

Signed-off-by: Jun Nie 
---
 drivers/interconnect/qcom/Makefile  |   2 +-
 drivers/interconnect/qcom/icc-rpm.c | 191 ++
 drivers/interconnect/qcom/icc-rpm.h |  73 +
 drivers/interconnect/qcom/msm8916.c | 241 ++--
 4 files changed, 275 insertions(+), 232 deletions(-)
 create mode 100644 drivers/interconnect/qcom/icc-rpm.c
 create mode 100644 drivers/interconnect/qcom/icc-rpm.h

diff --git a/drivers/interconnect/qcom/Makefile 
b/drivers/interconnect/qcom/Makefile
index cf628f7990cd..916d7bbe55b7 100644
--- a/drivers/interconnect/qcom/Makefile
+++ b/drivers/interconnect/qcom/Makefile
@@ -10,7 +10,7 @@ qnoc-sc7180-objs  := sc7180.o
 qnoc-sdm845-objs   := sdm845.o
 qnoc-sm8150-objs   := sm8150.o
 qnoc-sm8250-objs   := sm8250.o
-icc-smd-rpm-objs   := smd-rpm.o
+icc-smd-rpm-objs   := smd-rpm.o icc-rpm.o
 
 obj-$(CONFIG_INTERCONNECT_QCOM_BCM_VOTER) += icc-bcm-voter.o
 obj-$(CONFIG_INTERCONNECT_QCOM_MSM8916) += qnoc-msm8916.o
diff --git a/drivers/interconnect/qcom/icc-rpm.c 
b/drivers/interconnect/qcom/icc-rpm.c
new file mode 100644
index ..cc6095492cbe
--- /dev/null
+++ b/drivers/interconnect/qcom/icc-rpm.c
@@ -0,0 +1,191 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Linaro Ltd
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "smd-rpm.h"
+#include "icc-rpm.h"
+
+static int qcom_icc_set(struct icc_node *src, struct icc_node *dst)
+{
+   struct qcom_icc_provider *qp;
+   struct qcom_icc_node *qn;
+   struct icc_provider *provider;
+   struct icc_node *n;
+   u64 sum_bw;
+   u64 max_peak_bw;
+   u64 rate;
+   u32 agg_avg = 0;
+   u32 agg_peak = 0;
+   int ret, i;
+
+   qn = src->data;
+   provider = src->provider;
+   qp = to_qcom_provider(provider);
+
+   list_for_each_entry(n, >nodes, node_list)
+   provider->aggregate(n, 0, n->avg_bw, n->peak_bw,
+   _avg, _peak);
+
+   sum_bw = icc_units_to_bps(agg_avg);
+   max_peak_bw = icc_units_to_bps(agg_peak);
+
+   /* send bandwidth request message to the RPM processor */
+   if (qn->mas_rpm_id != -1) {
+   ret = qcom_icc_rpm_smd_send(QCOM_SMD_RPM_ACTIVE_STATE,
+   RPM_BUS_MASTER_REQ,
+   qn->mas_rpm_id,
+   sum_bw);
+   if (ret) {
+   pr_err("qcom_icc_rpm_smd_send mas %d error %d\n",
+  qn->mas_rpm_id, ret);
+   return ret;
+   }
+   }
+
+   if (qn->slv_rpm_id != -1) {
+   ret = qcom_icc_rpm_smd_send(QCOM_SMD_RPM_ACTIVE_STATE,
+   RPM_BUS_SLAVE_REQ,
+   qn->slv_rpm_id,
+   sum_bw);
+   if (ret) {
+   pr_err("qcom_icc_rpm_smd_send slv error %d\n",
+  ret);
+   return ret;
+   }
+   }
+
+   rate = max(sum_bw, max_peak_bw);
+
+   do_div(rate, qn->buswidth);
+
+   if (qn->rate == rate)
+   return 0;
+
+   for (i = 0; i < qp->num_clks; i++) {
+   ret = clk_set_rate(qp->bus_clks[i].clk, rate);
+   if (ret) {
+   pr_err("%s clk_set_rate error: %d\n",
+  qp->bus_clks[i].id, ret);
+   return ret;
+   }
+   }
+
+   qn->rate = rate;
+
+   return 0;
+}
+
+int qnoc_probe(struct platform_device *pdev, size_t cd_size, int cd_num,
+  const struct clk_bulk_data *cd)
+{
+   struct device *dev = >dev;
+   const struct qcom_icc_desc *desc;
+   struct icc_onecell_data *data;
+   struct icc_provider *provider;
+   struct qcom_icc_node **qnodes;
+   struct qcom_icc_provider *qp;
+   struct icc_node *node;
+   size_t num_nodes, i;
+   int ret;
+
+   /* wait for the RPM proxy */
+   if (!qcom_icc_rpm_smd_available())
+   return -EPROBE_DEFER;
+
+   desc = of_device_get_match_data(dev);
+   if (!desc)
+   return -EINVAL;
+
+   qnodes = desc->nodes;
+   num_nodes = desc->num_nodes;
+
+   qp = devm_kzalloc(dev, sizeof(*qp), GFP_KERNEL);
+   if (!qp)
+   return -ENOMEM;
+
+   data = devm_kzalloc(dev, 

[PATCH v2 0/5] Consolidate RPM interconnect and support to MSM8939

[Jun Nie]

This patch set split shared RPM based interconnect operation code and add
support to MSM8939 interconnect.

Changes vs V1:
  - Rebase to latest icc code.
  - Remove unnecessary comment and info.
  - Fix some format issues.

Jun Nie (5):
  interconnect: qcom: Consolidate interconnect RPM support
  interconnect: qcom: qcs404: use shared code
  dt-bindings: interconnect: single yaml file for RPM interconnect
drivers
  dt-bindings: interconnect: Add Qualcomm MSM8939 DT bindings
  interconnect: qcom: Add MSM8939 interconnect provider driver

 .../bindings/interconnect/qcom,qcs404.yaml|  77 
 .../{qcom,msm8916.yaml => qcom,rpm.yaml}  |  22 +-
 drivers/interconnect/qcom/Kconfig |   9 +
 drivers/interconnect/qcom/Makefile|   4 +-
 drivers/interconnect/qcom/icc-rpm.c   | 191 ++
 drivers/interconnect/qcom/icc-rpm.h   |  73 
 drivers/interconnect/qcom/msm8916.c   | 241 +---
 drivers/interconnect/qcom/msm8939.c   | 355 ++
 drivers/interconnect/qcom/qcs404.c| 242 +---
 .../dt-bindings/interconnect/qcom,msm8939.h   | 105 ++
 10 files changed, 769 insertions(+), 550 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/interconnect/qcom,qcs404.yaml
 rename Documentation/devicetree/bindings/interconnect/{qcom,msm8916.yaml => 
qcom,rpm.yaml} (77%)
 create mode 100644 drivers/interconnect/qcom/icc-rpm.c
 create mode 100644 drivers/interconnect/qcom/icc-rpm.h
 create mode 100644 drivers/interconnect/qcom/msm8939.c
 create mode 100644 include/dt-bindings/interconnect/qcom,msm8939.h


base-commit: bfd521e1af519bb7096efc845f6a64a7de28c472
-- 
2.17.1

Re: [PATCH v2 0/2] Adds support to capture module's SCM version

[Christoph Hellwig]

I think your decription still shows absolutely no benefit for the
kernel, so I'not sure why anyone would want to waste time on this.

[PATCH v2 3/3] arm64: dts: ti: k3-j721e-main: Remove "syscon" nodes added for pcieX_ctrl

[Kishon Vijay Abraham I]

Remove "syscon" nodes added for pcieX_ctrl and have the PCIe node
point to the parent with an offset argument. This change is as discussed in [1]

[1] -> 
http://lore.kernel.org/r/cal_jsqkiuco76bo1goepwm1tusjwoty_bry2hfsgtevmqtr...@mail.gmail.com

Fixes: 4e5833884f66 ("arm64: dts: ti: k3-j721e-main: Add PCIe device tree 
nodes")
Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 48 ---
 1 file changed, 8 insertions(+), 40 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi 
b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
index 620e69e42974..23a0024dda79 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
@@ -28,38 +28,6 @@
#size-cells = <1>;
ranges = <0x0 0x0 0x0010 0x1c000>;
 
-   pcie0_ctrl: syscon@4070 {
-   compatible = "ti,j721e-system-controller", "syscon", 
"simple-mfd";
-   reg = <0x4070 0x4>;
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges = <0x4070 0x4070 0x4>;
-   };
-
-   pcie1_ctrl: syscon@4074 {
-   compatible = "ti,j721e-system-controller", "syscon", 
"simple-mfd";
-   reg = <0x4074 0x4>;
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges = <0x4074 0x4074 0x4>;
-   };
-
-   pcie2_ctrl: syscon@4078 {
-   compatible = "ti,j721e-system-controller", "syscon", 
"simple-mfd";
-   reg = <0x4078 0x4>;
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges = <0x4078 0x4078 0x4>;
-   };
-
-   pcie3_ctrl: syscon@407c {
-   compatible = "ti,j721e-system-controller", "syscon", 
"simple-mfd";
-   reg = <0x407c 0x4>;
-   #address-cells = <1>;
-   #size-cells = <1>;
-   ranges = <0x407c 0x407c 0x4>;
-   };
-
serdes_ln_ctrl: mux@4080 {
compatible = "mmio-mux";
reg = <0x4080 0x50>;
@@ -619,7 +587,7 @@
interrupt-names = "link_state";
interrupts = ;
device_type = "pci";
-   ti,syscon-pcie-ctrl = <_ctrl>;
+   ti,syscon-pcie-ctrl = <_conf 0x4070>;
max-link-speed = <3>;
num-lanes = <2>;
power-domains = <_pds 239 TI_SCI_PD_EXCLUSIVE>;
@@ -646,7 +614,7 @@
reg-names = "intd_cfg", "user_cfg", "reg", "mem";
interrupt-names = "link_state";
interrupts = ;
-   ti,syscon-pcie-ctrl = <_ctrl>;
+   ti,syscon-pcie-ctrl = <_conf 0x4070>;
max-link-speed = <3>;
num-lanes = <2>;
power-domains = <_pds 239 TI_SCI_PD_EXCLUSIVE>;
@@ -668,7 +636,7 @@
interrupt-names = "link_state";
interrupts = ;
device_type = "pci";
-   ti,syscon-pcie-ctrl = <_ctrl>;
+   ti,syscon-pcie-ctrl = <_conf 0x4074>;
max-link-speed = <3>;
num-lanes = <2>;
power-domains = <_pds 240 TI_SCI_PD_EXCLUSIVE>;
@@ -695,7 +663,7 @@
reg-names = "intd_cfg", "user_cfg", "reg", "mem";
interrupt-names = "link_state";
interrupts = ;
-   ti,syscon-pcie-ctrl = <_ctrl>;
+   ti,syscon-pcie-ctrl = <_conf 0x4074>;
max-link-speed = <3>;
num-lanes = <2>;
power-domains = <_pds 240 TI_SCI_PD_EXCLUSIVE>;
@@ -717,7 +685,7 @@
interrupt-names = "link_state";
interrupts = ;
device_type = "pci";
-   ti,syscon-pcie-ctrl = <_ctrl>;
+   ti,syscon-pcie-ctrl = <_conf 0x4078>;
max-link-speed = <3>;
num-lanes = <2>;
power-domains = <_pds 241 TI_SCI_PD_EXCLUSIVE>;
@@ -744,7 +712,7 @@
reg-names = "intd_cfg", "user_cfg", "reg", "mem";
interrupt-names = "link_state";
interrupts = ;
-   ti,syscon-pcie-ctrl = <_ctrl>;
+   ti,syscon-pcie-ctrl = <_conf 0x4078>;
max-link-speed = <3>;
num-lanes = <2>;
power-domains = <_pds 241 TI_SCI_PD_EXCLUSIVE>;
@@ -766,7 +734,7 @@
interrupt-names = "link_state";
interrupts = ;
device_type = "pci";
-   ti,syscon-pcie-ctrl = <_ctrl>;
+   ti,syscon-pcie-ctrl = <_conf 0x407c>;
max-link-speed = <3>;
num-lanes = <2>;
   

[PATCH v2 2/3] PCI: j721e: Get offset within "syscon" from "ti,syscon-pcie-ctrl" phandle arg

[Kishon Vijay Abraham I]

Get "syscon" pcie_ctrl offset from the argument of "ti,syscon-pcie-ctrl"
phandle. Previously a subnode to "syscon" node was added which has the
exact memory mapped address of pcie_ctrl but now the offset of pcie_ctrl
within "syscon" is now being passed as argument to "ti,syscon-pcie-ctrl"
phandle.

If the offset is not provided in "ti,syscon-pcie-ctrl", the
full memory mapped address of pcie_ctrl is used in order to maintain old
DT compatibility.

This change is as discussed in [1]

[1] -> 
http://lore.kernel.org/r/cal_jsqkiuco76bo1goepwm1tusjwoty_bry2hfsgtevmqtr...@mail.gmail.com

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/controller/cadence/pci-j721e.c | 28 +++---
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/drivers/pci/controller/cadence/pci-j721e.c 
b/drivers/pci/controller/cadence/pci-j721e.c
index 586b9d69fa5e..dac1ac8a7615 100644
--- a/drivers/pci/controller/cadence/pci-j721e.c
+++ b/drivers/pci/controller/cadence/pci-j721e.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -153,7 +154,8 @@ static const struct cdns_pcie_ops j721e_pcie_ops = {
.link_up = j721e_pcie_link_up,
 };
 
-static int j721e_pcie_set_mode(struct j721e_pcie *pcie, struct regmap *syscon)
+static int j721e_pcie_set_mode(struct j721e_pcie *pcie, struct regmap *syscon,
+  unsigned int offset)
 {
struct device *dev = pcie->dev;
u32 mask = J721E_MODE_RC;
@@ -164,7 +166,7 @@ static int j721e_pcie_set_mode(struct j721e_pcie *pcie, 
struct regmap *syscon)
if (mode == PCI_MODE_RC)
val = J721E_MODE_RC;
 
-   ret = regmap_update_bits(syscon, 0, mask, val);
+   ret = regmap_update_bits(syscon, offset, mask, val);
if (ret)
dev_err(dev, "failed to set pcie mode\n");
 
@@ -172,7 +174,7 @@ static int j721e_pcie_set_mode(struct j721e_pcie *pcie, 
struct regmap *syscon)
 }
 
 static int j721e_pcie_set_link_speed(struct j721e_pcie *pcie,
-struct regmap *syscon)
+struct regmap *syscon, unsigned int offset)
 {
struct device *dev = pcie->dev;
struct device_node *np = dev->of_node;
@@ -185,7 +187,7 @@ static int j721e_pcie_set_link_speed(struct j721e_pcie 
*pcie,
link_speed = 2;
 
val = link_speed - 1;
-   ret = regmap_update_bits(syscon, 0, GENERATION_SEL_MASK, val);
+   ret = regmap_update_bits(syscon, offset, GENERATION_SEL_MASK, val);
if (ret)
dev_err(dev, "failed to set link speed\n");
 
@@ -193,7 +195,7 @@ static int j721e_pcie_set_link_speed(struct j721e_pcie 
*pcie,
 }
 
 static int j721e_pcie_set_lane_count(struct j721e_pcie *pcie,
-struct regmap *syscon)
+struct regmap *syscon, unsigned int offset)
 {
struct device *dev = pcie->dev;
u32 lanes = pcie->num_lanes;
@@ -201,7 +203,7 @@ static int j721e_pcie_set_lane_count(struct j721e_pcie 
*pcie,
int ret;
 
val = LANE_COUNT(lanes - 1);
-   ret = regmap_update_bits(syscon, 0, LANE_COUNT_MASK, val);
+   ret = regmap_update_bits(syscon, offset, LANE_COUNT_MASK, val);
if (ret)
dev_err(dev, "failed to set link count\n");
 
@@ -212,6 +214,8 @@ static int j721e_pcie_ctrl_init(struct j721e_pcie *pcie)
 {
struct device *dev = pcie->dev;
struct device_node *node = dev->of_node;
+   struct of_phandle_args args;
+   unsigned int offset = 0;
struct regmap *syscon;
int ret;
 
@@ -221,19 +225,25 @@ static int j721e_pcie_ctrl_init(struct j721e_pcie *pcie)
return PTR_ERR(syscon);
}
 
-   ret = j721e_pcie_set_mode(pcie, syscon);
+   /* Do not error out to maintain old DT compatibility */
+   ret = of_parse_phandle_with_fixed_args(node, "ti,syscon-pcie-ctrl", 1,
+  0, );
+   if (!ret)
+   offset = args.args[0];
+
+   ret = j721e_pcie_set_mode(pcie, syscon, offset);
if (ret < 0) {
dev_err(dev, "Failed to set pci mode\n");
return ret;
}
 
-   ret = j721e_pcie_set_link_speed(pcie, syscon);
+   ret = j721e_pcie_set_link_speed(pcie, syscon, offset);
if (ret < 0) {
dev_err(dev, "Failed to set link speed\n");
return ret;
}
 
-   ret = j721e_pcie_set_lane_count(pcie, syscon);
+   ret = j721e_pcie_set_lane_count(pcie, syscon, offset);
if (ret < 0) {
dev_err(dev, "Failed to set num-lanes\n");
return ret;
-- 
2.17.1

[PATCH v2 1/3] dt-bindings: pci: ti,j721e: Fix "ti,syscon-pcie-ctrl" to take argument

[Kishon Vijay Abraham I]

Fix binding documentation of "ti,syscon-pcie-ctrl" to take phandle with
argument. The argument is the register offset within "syscon" used to
configure PCIe controller. This change is as discussed in [1]

[1] -> 
http://lore.kernel.org/r/cal_jsqkiuco76bo1goepwm1tusjwoty_bry2hfsgtevmqtr...@mail.gmail.com

Fixes: 431b53b81cdc ("dt-bindings: PCI: Add host mode dt-bindings for TI's 
J721E SoC")
Fixes: 45b39e928966 ("dt-bindings: PCI: Add EP mode dt-bindings for TI's J721E 
SoC")
Signed-off-by: Kishon Vijay Abraham I 
---
 .../devicetree/bindings/pci/ti,j721e-pci-ep.yaml  | 11 +++
 .../devicetree/bindings/pci/ti,j721e-pci-host.yaml| 11 +++
 2 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/ti,j721e-pci-ep.yaml 
b/Documentation/devicetree/bindings/pci/ti,j721e-pci-ep.yaml
index 3ae3e1a2d4b0..3766565cf258 100644
--- a/Documentation/devicetree/bindings/pci/ti,j721e-pci-ep.yaml
+++ b/Documentation/devicetree/bindings/pci/ti,j721e-pci-ep.yaml
@@ -29,9 +29,12 @@ properties:
   - const: mem
 
   ti,syscon-pcie-ctrl:
-description: Phandle to the SYSCON entry required for configuring PCIe mode
- and link speed.
-$ref: /schemas/types.yaml#/definitions/phandle
+$ref: /schemas/types.yaml#/definitions/phandle-array
+items:
+  - items:
+  - description: Phandle to the SYSCON entry
+  - description: pcie_ctrl register offset within SYSCON
+description: Specifier for configuring PCIe mode and link speed.
 
   power-domains:
 maxItems: 1
@@ -80,7 +83,7 @@ examples:
  <0x00 0x0d00 0x00 0x0080>,
  <0x00 0x1000 0x00 0x0800>;
reg-names = "intd_cfg", "user_cfg", "reg", "mem";
-   ti,syscon-pcie-ctrl = <_ctrl>;
+   ti,syscon-pcie-ctrl = <_ctrl 0x4070>;
max-link-speed = <3>;
num-lanes = <2>;
power-domains = <_pds 239 TI_SCI_PD_EXCLUSIVE>;
diff --git a/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml 
b/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml
index ee7a8eade3f6..2b6a1a5eaf7a 100644
--- a/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml
+++ b/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml
@@ -29,9 +29,12 @@ properties:
   - const: cfg
 
   ti,syscon-pcie-ctrl:
-description: Phandle to the SYSCON entry required for configuring PCIe mode
-  and link speed.
-$ref: /schemas/types.yaml#/definitions/phandle
+$ref: /schemas/types.yaml#/definitions/phandle-array
+items:
+  - items:
+  - description: Phandle to the SYSCON entry
+  - description: pcie_ctrl register offset within SYSCON
+description: Specifier for configuring PCIe mode and link speed.
 
   power-domains:
 maxItems: 1
@@ -90,7 +93,7 @@ examples:
   <0x00 0x0d00 0x00 0x0080>,
   <0x00 0x1000 0x00 0x1000>;
 reg-names = "intd_cfg", "user_cfg", "reg", "cfg";
-ti,syscon-pcie-ctrl = <_ctrl>;
+ti,syscon-pcie-ctrl = <_ctrl 0x4070>;
 max-link-speed = <3>;
 num-lanes = <2>;
 power-domains = <_pds 239 TI_SCI_PD_EXCLUSIVE>;
-- 
2.17.1

[PATCH v2 0/3] PCI: J721E: Fix Broken DT w.r.t SYSCON DT

[Kishon Vijay Abraham I]

Previously a subnode to syscon node was added which has the
exact memory mapped address of pcie_ctrl but based on review comment
provided by Rob [1], the offset is now being passed as argument to
"ti,syscon-pcie-ctrl" phandle.

This series has both driver change and DT change. The driver change
should be merged first and the driver takes care of maintaining old
DT compatibility.

Changes frm v1:
*) Remove use of allOf in schema
*) Added Fixes tag
*) Maintain old DT compatibility

[1] -> 
http://lore.kernel.org/r/cal_jsqkiuco76bo1goepwm1tusjwoty_bry2hfsgtevmqtr...@mail.gmail.com

Kishon Vijay Abraham I (3):
  dt-bindings: pci: ti,j721e: Fix "ti,syscon-pcie-ctrl" to take argument
  PCI: j721e: Get offset within "syscon" from "ti,syscon-pcie-ctrl"
phandle arg
  arm64: dts: ti: k3-j721e-main: Remove "syscon" nodes added for
pcieX_ctrl

 .../bindings/pci/ti,j721e-pci-ep.yaml | 11 +++--
 .../bindings/pci/ti,j721e-pci-host.yaml   | 11 +++--
 arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 48 ---
 drivers/pci/controller/cadence/pci-j721e.c| 28 +++
 4 files changed, 41 insertions(+), 57 deletions(-)

-- 
2.17.1

[tip:master] BUILD SUCCESS 9dc242493c6ebbea55c354b7dbce7edfc1b5a75c

[kernel test robot]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git  master
branch HEAD: 9dc242493c6ebbea55c354b7dbce7edfc1b5a75c  Merge branch 'linus'

elapsed time: 1107m

configs tested: 117
configs skipped: 2

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

gcc tested configs:
arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
arm   aspeed_g5_defconfig
riscvalldefconfig
sh espt_defconfig
shhp6xx_defconfig
arm  pxa168_defconfig
arm orion5x_defconfig
nds32alldefconfig
mips  fuloong2e_defconfig
sh   se7724_defconfig
powerpc  obs600_defconfig
arm  pcm027_defconfig
armdove_defconfig
arm  colibri_pxa300_defconfig
powerpc  pcm030_defconfig
arcnsim_700_defconfig
sparc64  alldefconfig
mips  decstation_64_defconfig
sh   se7750_defconfig
ia64  tiger_defconfig
mipsjmr3927_defconfig
xtensa  iss_defconfig
arm  ixp4xx_defconfig
powerpc   motionpro_defconfig
powerpc asp8347_defconfig
arm nhk8815_defconfig
powerpcamigaone_defconfig
sh  rsk7269_defconfig
powerpc  mgcoge_defconfig
m68k amcore_defconfig
powerpcgamecube_defconfig
xtensa  nommu_kc705_defconfig
arm shannon_defconfig
mips   ip32_defconfig
arm s3c2410_defconfig
xtensa  defconfig
powerpc skiroot_defconfig
c6xevmc6474_defconfig
arm pxa_defconfig
arm   omap2plus_defconfig
powerpcsocrates_defconfig
xtensasmp_lx200_defconfig
c6xevmc6472_defconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
parisc   allyesconfig
s390defconfig
i386   tinyconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a005-20201204
i386 randconfig-a004-20201204
i386 randconfig-a001-20201204
i386 randconfig-a002-20201204
i386 randconfig-a006-20201204
i386 randconfig-a003-20201204
i386 randconfig-a014-20201203
i386 randconfig-a013-20201203
i386 randconfig-a011-20201203
i386 randconfig-a015-20201203
i386 randconfig-a012-20201203
i386 randconfig-a016-20201203
x86_64   randconfig-a004-20201204
x86_64   randconfig-a006-20201204
x86_64   randconfig-a002-20201204
x86_64   randconfig-a001-20201204
x86_64   randconfig-a005-20201204
x86_64   randconfig-a003-20201204
riscvnommu_k210_defconfig
riscvnommu_virt_defconfig
riscv  rv32_defconfig
riscv

Re: [PATCH v3 19/19] vdpa: split vdpasim to core and net modules

[Stefano Garzarella]

On Thu, Dec 03, 2020 at 09:25:52AM -0800, Randy Dunlap wrote:

Hi,

On 12/3/20 9:05 AM, Stefano Garzarella wrote:

diff --git a/drivers/vdpa/Kconfig b/drivers/vdpa/Kconfig
index 2c892e890b9e..b0f91ad8eb47 100644
--- a/drivers/vdpa/Kconfig
+++ b/drivers/vdpa/Kconfig
@@ -9,15 +9,20 @@ menuconfig VDPA
 if VDPA

 config VDPA_SIM
-   tristate "vDPA device simulator"
+   tristate "vDPA device simulator core"
depends on RUNTIME_TESTING_MENU && HAS_DMA
select DMA_OPS
select VHOST_RING
+   help
+ Enable this module to support vDPA device simulators. These devices
+ are used for testing, prototyping and development of vDPA.
+
+config VDPA_SIM_NET
+   tristate "vDPA simulator for networking device"
+   depends on VDPA_SIM
select GENERIC_NET_UTILS
help
- vDPA networking device simulator which loop TX traffic back
- to RX. This device is used for testing, prototyping and
- development of vDPA.
+ vDPA networking device simulator which loop TX traffic back to RX.


 loops


It was pre-existing, but since I'm there I'll fix it, thanks!

Stefano

Re: [PATCH 5/6] ARM: dts: mmp2-olpc-xo-1-75: explicitly add #address-cells=<0> for slave mode

[Leizhen (ThunderTown)]

Hi everybody:
  Can somebody apply this patch? When I do any YAML dtbs_check on arm, below 
Warnings always reported.

arch/arm/boot/dts/mmp2.dtsi:472.23-480.6: Warning (spi_bus_bridge): 
/soc/apb@d400/spi@d4037000: incorrect #address-cells for SPI bus
  also defined at arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts:225.7-237.3
arch/arm/boot/dts/mmp2.dtsi:472.23-480.6: Warning (spi_bus_bridge): 
/soc/apb@d400/spi@d4037000: incorrect #size-cells for SPI bus
  also defined at arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts:225.7-237.3
arch/arm/boot/dts/mmp2-olpc-xo-1-75.dt.yaml: Warning (spi_bus_reg): Failed 
prerequisite 'spi_bus_bridge'


On 2020/10/14 0:08, Zhen Lei wrote:
> Delete the old property "#address-cells" and then explicitly add it with
> zero value. The value of "#size-cells" is already zero, so keep it no
> change.
> 
> Signed-off-by: Zhen Lei 
> ---
>  arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts 
> b/arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts
> index f1a41152e9dd70d..be88b6e551d58e9 100644
> --- a/arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts
> +++ b/arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts
> @@ -224,7 +224,7 @@
>  
>   {
>   /delete-property/ #address-cells;
> - /delete-property/ #size-cells;
> + #address-cells = <0>;
>   spi-slave;
>   status = "okay";
>   ready-gpio = < 125 GPIO_ACTIVE_HIGH>;
> 

[PATCH] scsi: fnic: fix error return code in fnic_probe()

[Zhang Changzhong]

Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.

Fixes: 5df6d737dd4b ("[SCSI] fnic: Add new Cisco PCI-Express FCoE HBA")
Reported-by: Hulk Robot 
Signed-off-by: Zhang Changzhong 
---
 drivers/scsi/fnic/fnic_main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/fnic/fnic_main.c b/drivers/scsi/fnic/fnic_main.c
index 5f8a7ef..4f7befb 100644
--- a/drivers/scsi/fnic/fnic_main.c
+++ b/drivers/scsi/fnic/fnic_main.c
@@ -740,6 +740,7 @@ static int fnic_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
for (i = 0; i < FNIC_IO_LOCKS; i++)
spin_lock_init(>io_req_lock[i]);
 
+   err = -ENOMEM;
fnic->io_req_pool = mempool_create_slab_pool(2, fnic_io_req_cache);
if (!fnic->io_req_pool)
goto err_out_free_resources;
-- 
2.9.5

Re: [f2fs-dev] [PATCH v6] f2fs: compress: support compress level

[Gao Xiang]

Hi Chao,

On Fri, Dec 04, 2020 at 03:09:20PM +0800, Chao Yu wrote:
> On 2020/12/4 8:31, Gao Xiang wrote:
> > could make more sense), could you leave some CR numbers about these
> > algorithms on typical datasets (enwik9, silisia.tar or else.) with 16k
> > cluster size?
> 
> Just from a quick test with enwik9 on vm:
> 
> Original blocks:  244382
> 
>   lz4 lz4hc-9
> compressed blocks 170647  163270
> compress ratio69.8%   66.8%
> speed 16.4207 s, 60.9 MB/s26.7299 s, 37.4 MB/s
> 
> compress ratio = after / before

Thanks for the confirmation. it'd be better to add this to commit message
if needed when adding a new algorithm to show the benefits.

About the speed, I think which is also limited to storage device and other
conditions (I mean the CPU loading during the writeback might be different
between lz4 and lz4hc-9 due to many other bounds, e.g. UFS 3.0 seq
write is somewhat higher vs VM. lz4 may have higher bandwidth on high
level devices since it seems some IO bound here... I guess but not sure,
since pure in-memory lz4 is fast according to lzbench / lz4 homepage.)

Anyway, it's up to f2fs folks if it's useful :) (the CR number is what
I expect though... I'm a bit of afraid the CPU runtime loading.)
Thanks for your time!

Thanks,
Gao Xiang

> 
> Thanks,
> 

[PATCH 4/4] phy: freescale: phy-fsl-imx8-mipi-dphy: Add i.MX8qxp LVDS PHY mode support

[Liu Ying]

i.MX8qxp SoC embeds a Mixel MIPI DPHY + LVDS PHY combo which supports
either a MIPI DSI display or a LVDS display.  The PHY mode is controlled
by SCU firmware and the driver would call a SCU firmware function to
configure the PHY mode.  The single LVDS PHY has 4 data lanes to support
a LVDS display.  Also, with a master LVDS PHY and a slave LVDS PHY, they
may work together to support a LVDS display with 8 data lanes(usually, dual
LVDS link display).  Note that this patch supports the LVDS PHY mode only
for the i.MX8qxp Mixel combo PHY, i.e., the MIPI DPHY mode is yet to be
supported, so for now error would be returned from ->set_mode() if MIPI
DPHY mode is passed over to it for the combo PHY.

Cc: Guido Günther 
Cc: Robert Chiras 
Cc: Kishon Vijay Abraham I 
Cc: Vinod Koul 
Cc: Shawn Guo 
Cc: Sascha Hauer 
Cc: Pengutronix Kernel Team 
Cc: Fabio Estevam 
Cc: NXP Linux Team 
Signed-off-by: Liu Ying 
---
 drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c | 266 -
 1 file changed, 255 insertions(+), 11 deletions(-)

diff --git a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c 
b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
index a95572b..37084a9 100644
--- a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
+++ b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
@@ -4,17 +4,31 @@
  * Copyright 2019 Purism SPC
  */
 
+#include 
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
+
+/* Control and Status Registers(CSR) */
+#define PHY_CTRL   0x00
+#define  CCM_MASK  GENMASK(7, 5)
+#define  CCM(n)FIELD_PREP(CCM_MASK, (n))
+#define  CA_MASK   GENMASK(4, 2)
+#define  CA(n) FIELD_PREP(CA_MASK, (n))
+#define  RFB   BIT(1)
+#define  LVDS_EN   BIT(0)
 
 /* DPHY registers */
 #define DPHY_PD_DPHY   0x00
@@ -55,8 +69,15 @@
 #define PWR_ON 0
 #define PWR_OFF1
 
+#define MIN_VCO_FREQ 64000
+#define MAX_VCO_FREQ 15
+
+#define MIN_LVDS_REFCLK_FREQ 2400
+#define MAX_LVDS_REFCLK_FREQ 15000
+
 enum mixel_dphy_devtype {
MIXEL_IMX8MQ,
+   MIXEL_IMX8QXP,
 };
 
 struct mixel_dphy_devdata {
@@ -65,6 +86,7 @@ struct mixel_dphy_devdata {
u8 reg_rxlprp;
u8 reg_rxcdrp;
u8 reg_rxhs_settle;
+   bool is_combo;  /* MIPI DPHY and LVDS PHY combo */
 };
 
 static const struct mixel_dphy_devdata mixel_dphy_devdata[] = {
@@ -74,6 +96,10 @@ static const struct mixel_dphy_devdata mixel_dphy_devdata[] 
= {
.reg_rxlprp = 0x40,
.reg_rxcdrp = 0x44,
.reg_rxhs_settle = 0x48,
+   .is_combo = false,
+   },
+   [MIXEL_IMX8QXP] = {
+   .is_combo = true,
},
 };
 
@@ -95,8 +121,12 @@ struct mixel_dphy_cfg {
 struct mixel_dphy_priv {
struct mixel_dphy_cfg cfg;
struct regmap *regmap;
+   struct regmap *lvds_regmap;
struct clk *phy_ref_clk;
const struct mixel_dphy_devdata *devdata;
+   struct imx_sc_ipc *ipc_handle;
+   bool is_slave;
+   int id;
 };
 
 static const struct regmap_config mixel_dphy_regmap_config = {
@@ -317,7 +347,8 @@ static int mixel_dphy_set_pll_params(struct phy *phy)
return 0;
 }
 
-static int mixel_dphy_configure(struct phy *phy, union phy_configure_opts 
*opts)
+static int
+mixel_dphy_configure_mipi_dphy(struct phy *phy, union phy_configure_opts *opts)
 {
struct mixel_dphy_priv *priv = phy_get_drvdata(phy);
struct mixel_dphy_cfg cfg = { 0 };
@@ -345,15 +376,118 @@ static int mixel_dphy_configure(struct phy *phy, union 
phy_configure_opts *opts)
return 0;
 }
 
+static int
+mixel_dphy_configure_lvds_phy(struct phy *phy, union phy_configure_opts *opts)
+{
+   struct mixel_dphy_priv *priv = phy_get_drvdata(phy);
+   struct phy_configure_opts_lvds *lvds_opts = >lvds;
+   unsigned long data_rate;
+   unsigned long fvco;
+   u32 rsc;
+   u32 co;
+   int ret;
+
+   priv->is_slave = lvds_opts->is_slave;
+
+   /* LVDS interface pins */
+   regmap_write(priv->lvds_regmap, PHY_CTRL, CCM(0x5) | CA(0x4) | RFB);
+
+   /* enable MODE8 only for slave LVDS PHY */
+   rsc = priv->id ? IMX_SC_R_MIPI_1 : IMX_SC_R_MIPI_0;
+   ret = imx_sc_misc_set_control(priv->ipc_handle, rsc, IMX_SC_C_DUAL_MODE,
+ lvds_opts->is_slave);
+   if (ret) {
+   dev_err(>dev, "Failed to configure MODE8: %d\n", ret);
+   return ret;
+   }
+
+   /*
+* Choose an appropriate divider ratio to meet the requirement of
+* PLL VCO frequency range.
+*
+*  -  640MHz ~ 1500MHz     ---
+* | VCO | > | CO divider | -> | LVDS data rate|
+*  -   

[PATCH 3/4] dt-bindings: phy: mixel: mipi-dsi-phy: Add Mixel combo PHY support for i.MX8qxp

[Liu Ying]

Add support for Mixel MIPI DPHY + LVDS PHY combo IP
as found on Freescale i.MX8qxp SoC.

Cc: Guido Günther 
Cc: Kishon Vijay Abraham I 
Cc: Vinod Koul 
Cc: Rob Herring 
Cc: NXP Linux Team 
Signed-off-by: Liu Ying 
---
 Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt 
b/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt
index 9b23407..0afce99 100644
--- a/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt
+++ b/Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt
@@ -4,9 +4,13 @@ The Mixel MIPI-DSI PHY IP block is e.g. found on i.MX8 
platforms (along the
 MIPI-DSI IP from Northwest Logic). It represents the physical layer for the
 electrical signals for DSI.
 
+The Mixel PHY IP block found on i.MX8qxp is a combo PHY that can work
+in either MIPI-DSI PHY mode or LVDS PHY mode.
+
 Required properties:
-- compatible: Must be:
+- compatible: Should be one of:
   - "fsl,imx8mq-mipi-dphy"
+  - "fsl,imx8qxp-mipi-dphy"
 - clocks: Must contain an entry for each entry in clock-names.
 - clock-names: Must contain the following entries:
   - "phy_ref": phandle and specifier referring to the DPHY ref clock
@@ -14,6 +18,8 @@ Required properties:
 - #phy-cells: number of cells in PHY, as defined in
   Documentation/devicetree/bindings/phy/phy-bindings.txt
   this must be <0>
+- fsl,syscon: Phandle to a system controller, as required by the PHY
+  in i.MX8qxp SoC.
 
 Optional properties:
 - power-domains: phandle to power domain
-- 
2.7.4

[PATCH 2/4] phy: Add LVDS configuration options

[Liu Ying]

This patch allows LVDS PHYs to be configured through
the generic functions and through a custom structure
added to the generic union.

The parameters added here are based on common LVDS PHY
implementation practices.  The set of parameters
should cover all potential users.

Cc: Kishon Vijay Abraham I 
Cc: Vinod Koul 
Cc: NXP Linux Team 
Signed-off-by: Liu Ying 
---
 include/linux/phy/phy-lvds.h | 48 
 include/linux/phy/phy.h  |  4 
 2 files changed, 52 insertions(+)
 create mode 100644 include/linux/phy/phy-lvds.h

diff --git a/include/linux/phy/phy-lvds.h b/include/linux/phy/phy-lvds.h
new file mode 100644
index ..1b5b9d6
--- /dev/null
+++ b/include/linux/phy/phy-lvds.h
@@ -0,0 +1,48 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright 2020 NXP
+ */
+
+#ifndef __PHY_LVDS_H_
+#define __PHY_LVDS_H_
+
+/**
+ * struct phy_configure_opts_lvds - LVDS configuration set
+ *
+ * This structure is used to represent the configuration state of a
+ * LVDS phy.
+ */
+struct phy_configure_opts_lvds {
+   /**
+* @bits_per_lane_and_dclk_cycle:
+*
+* Number of bits per data lane and differential clock cycle.
+*/
+   unsigned int bits_per_lane_and_dclk_cycle;
+
+   /**
+* @differential_clk_rate:
+*
+* Clock rate, in Hertz, of the LVDS differential clock.
+*/
+   unsigned long differential_clk_rate;
+
+   /**
+* @lanes:
+*
+* Number of active, consecutive, data lanes, starting from
+* lane 0, used for the transmissions.
+*/
+   unsigned int lanes;
+
+   /**
+* @is_slave:
+*
+* Boolean, true if the phy is a slave which works together
+* with a master phy to support dual link transmission,
+* otherwise a regular phy or a master phy.
+*/
+   bool is_slave;
+};
+
+#endif /* __PHY_LVDS_H_ */
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index e435bdb..d450b44 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -17,6 +17,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 struct phy;
@@ -51,10 +52,13 @@ enum phy_mode {
  * the MIPI_DPHY phy mode.
  * @dp:Configuration set applicable for phys supporting
  * the DisplayPort protocol.
+ * @lvds:  Configuration set applicable for phys supporting
+ * the LVDS phy mode.
  */
 union phy_configure_opts {
struct phy_configure_opts_mipi_dphy mipi_dphy;
struct phy_configure_opts_dpdp;
+   struct phy_configure_opts_lvds  lvds;
 };
 
 /**
-- 
2.7.4

[PATCH 1/4] drm/bridge: nwl-dsi: Set PHY mode in nwl_dsi_enable()

[Liu Ying]

The Northwest Logic MIPI DSI host controller embedded in i.MX8qxp
works with a Mixel MIPI DPHY + LVDS PHY combo to support either
a MIPI DSI display or a LVDS display.  So, this patch calls
phy_set_mode() from nwl_dsi_enable() to set PHY mode to MIPI DPHY
explicitly.

Cc: Guido Günther 
Cc: Robert Chiras 
Cc: Martin Kepplinger 
Cc: Andrzej Hajda 
Cc: Neil Armstrong 
Cc: Laurent Pinchart 
Cc: Jonas Karlman 
Cc: Jernej Skrabec 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: NXP Linux Team 
Signed-off-by: Liu Ying 
---
 drivers/gpu/drm/bridge/nwl-dsi.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
index 66b6740..be6bfc5 100644
--- a/drivers/gpu/drm/bridge/nwl-dsi.c
+++ b/drivers/gpu/drm/bridge/nwl-dsi.c
@@ -678,6 +678,12 @@ static int nwl_dsi_enable(struct nwl_dsi *dsi)
return ret;
}
 
+   ret = phy_set_mode(dsi->phy, PHY_MODE_MIPI_DPHY);
+   if (ret < 0) {
+   DRM_DEV_ERROR(dev, "Failed to set DSI phy mode: %d\n", ret);
+   goto uninit_phy;
+   }
+
ret = phy_configure(dsi->phy, phy_cfg);
if (ret < 0) {
DRM_DEV_ERROR(dev, "Failed to configure DSI phy: %d\n", ret);
-- 
2.7.4

[PATCH 0/4] phy: phy-fsl-imx8-mipi-dphy: Add i.MX8qxp LVDS PHY mode support

[Liu Ying]

Hi,

This series adds i.MX8qxp LVDS PHY mode support for the Mixel PHY in the
Freescale i.MX8qxp SoC.

The Mixel PHY is MIPI DPHY + LVDS PHY combo, which can works in either
MIPI DPHY mode or LVDS PHY mode.  The PHY mode is controlled by i.MX8qxp
SCU firmware.  The PHY driver would call a SCU function to configure the
mode.

The PHY driver is already supporting the Mixel MIPI DPHY in i.MX8mq SoC,
where it appears to be a single MIPI DPHY.


Patch 1/4 sets PHY mode in the Northwest Logic MIPI DSI host controller
bridge driver, since i.MX8qxp SoC embeds this controller IP to support
MIPI DSI displays together with the Mixel PHY.

Patch 2/4 allows LVDS PHYs to be configured through the generic PHY functions
and through a custom structure added to the generic PHY configuration union.

Patch 3/4 adds dt binding support for the Mixel combo PHY in i.MX8qxp SoC.

Patch 4/4 adds the i.MX8qxp LVDS PHY mode support in the Mixel PHY driver.


Welcome comments, thanks.


Liu Ying (4):
  drm/bridge: nwl-dsi: Set PHY mode in nwl_dsi_enable()
  phy: Add LVDS configuration options
  dt-bindings: phy: mixel: mipi-dsi-phy: Add Mixel combo PHY support for
i.MX8qxp
  phy: freescale: phy-fsl-imx8-mipi-dphy: Add i.MX8qxp LVDS PHY mode
support

 .../devicetree/bindings/phy/mixel,mipi-dsi-phy.txt |   8 +-
 drivers/gpu/drm/bridge/nwl-dsi.c   |   6 +
 drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c | 266 -
 include/linux/phy/phy-lvds.h   |  48 
 include/linux/phy/phy.h|   4 +
 5 files changed, 320 insertions(+), 12 deletions(-)
 create mode 100644 include/linux/phy/phy-lvds.h

-- 
2.7.4

[PATCH] i2c: mlxbf: Fix an error pointer vs NULL check

[Xu Wang]

In case of error, the function devm_ioremap() returns NULL pointer not
ERR_PTR(). The IS_ERR() test in the return value check should be
replaced with NULL test.

Signed-off-by: Xu Wang 
---
 drivers/i2c/busses/i2c-mlxbf.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-mlxbf.c b/drivers/i2c/busses/i2c-mlxbf.c
index 33574d40ea9c..73a58beb7b82 100644
--- a/drivers/i2c/busses/i2c-mlxbf.c
+++ b/drivers/i2c/busses/i2c-mlxbf.c
@@ -1258,9 +1258,9 @@ static int mlxbf_i2c_get_gpio(struct platform_device 
*pdev,
return -EFAULT;
 
gpio_res->io = devm_ioremap(dev, params->start, size);
-   if (IS_ERR(gpio_res->io)) {
+   if (!gpio_res->io) {
devm_release_mem_region(dev, params->start, size);
-   return PTR_ERR(gpio_res->io);
+   return -ENOMEM;
}
 
return 0;
@@ -1323,9 +1323,9 @@ static int mlxbf_i2c_get_corepll(struct platform_device 
*pdev,
return -EFAULT;
 
corepll_res->io = devm_ioremap(dev, params->start, size);
-   if (IS_ERR(corepll_res->io)) {
+   if (!corepll_res->io) {
devm_release_mem_region(dev, params->start, size);
-   return PTR_ERR(corepll_res->io);
+   return -ENOMEM;
}
 
return 0;
-- 
2.17.1

Re: [RFC PATCH 5/9] cxl/mem: Find device capabilities

[Dan Williams]

On Tue, Nov 10, 2020 at 9:44 PM Ben Widawsky  wrote:
>
> CXL devices contain an array of capabilities that describe the
> interactions software can interact with the device, or firmware running
> on the device. A CXL compliant device must implement the device status
> and the mailbox capability. A CXL compliant memory device must implement
> the memory device capability.
>
> Each of the capabilities can [will] provide an offset within the MMIO
> region for interacting with the CXL device.
>
> Signed-off-by: Ben Widawsky 
> ---
>  drivers/cxl/cxl.h | 89 +++
>  drivers/cxl/mem.c | 58 +++---
>  2 files changed, 143 insertions(+), 4 deletions(-)
>  create mode 100644 drivers/cxl/cxl.h
>
> diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
> new file mode 100644
> index ..02858ae63d6d
> --- /dev/null
> +++ b/drivers/cxl/cxl.h
[..]
> +static inline u32 __cxl_raw_read_reg32(struct cxl_mem *cxlm, u32 reg)

Going through my reworks and the "raw" jumped out at me. My typical
interpretation of "raw" in respect to register access macros is the
difference between readl() and __raw_readl()  which means "don't do
bus endian swizzling, and don't do a memory clobber barrier". Any
heartburn to drop the "raw"?

...is it only me that reacts that way?

Re: [v4,2/3] PCI: mediatek: Add new generation controller support

[Lukas Wunner]

On Mon, Nov 30, 2020 at 11:30:05AM -0600, Bjorn Helgaas wrote:
> On Mon, Nov 23, 2020 at 02:45:13PM +0800, Jianjun Wang wrote:
> > On Thu, 2020-11-19 at 14:28 -0600, Bjorn Helgaas wrote:
> > > > +static int mtk_pcie_setup(struct mtk_pcie_port *port)
> > > > +{
[...]
> > > > +   /* Try link up */
> > > > +   err = mtk_pcie_startup_port(port);
> > > > +   if (err) {
> > > > +   dev_notice(dev, "PCIe link down\n");
> > > > +   goto err_setup;
> > > 
> > > Generally it should not be a fatal error if the link is not up at
> > > probe-time.  You may be able to hot-add a device, or the device may
> > > have some external power control that will power it up later.
> > 
> > This is for the power saving requirement. If there is no device
> > connected with the PCIe slot, the PCIe MAC and PHY should be powered
> > off.
> > 
> > Is there any standard flow to support power down the hardware at
> > probe-time if no device is connected and power it up when hot-add a
> > device?
> 
> That's a good question.  I assume this looks like a standard PCIe
> hot-add event?
> 
> When you hot-add a device, does the Root Port generate a Presence
> Detect Changed interrupt?  The pciehp driver should field that
> interrupt and turn on power to the slot via the Power Controller
> Control bit in the Slot Control register.
> 
> Does your hardware require something more than that to control the MAC
> and PHY power?

Power saving of unused PCIe ports is generally achieved through the
runtime PM framework.  When a PCIe port runtime suspends, the PCIe
core will transition it to D3hot.  On top of that, the platform
may be able to transition the port to D3cold.  Currently only the
ACPI platform supports that.  Conceivably, devicetree-based systems
may want to disable certain clocks or regulators when a PCIe port
runtime suspends.  I think we do not support that yet but it could
be added to drivers/pci/pcie/portdrv*.

A hotplug port is expected to signal PDC and DLLSC interrupts even
when in D3hot.  At least that's our experience with Thunderbolt.
To support hotplug interrupts in D3cold, some external mechanism
(such as a PME) is necessary to wake up the port on hotplug.
This is also supported with recent Thunderbolt systems.

Because we've seen various incompatibilities when runtime suspending
PCIe ports, certain conditions must be satisfied for runtime PM
to be enabled.  They're encoded in pci_bridge_d3_possible().
Generally, hotplug ports only runtime suspend if they belong to
a Thunderbolt controller or if the ACPI platform explicitly allows
runtime PM (through presence of a _PR3 method or a device property).
Non-hotplug ports runtime suspend if the BIOS is newer than 2015
(as specified by DMI).

Obviously, this policy is very x86-focussed because both Thunderbolt
and DMI are only really a thing on x86.  That's about to change though
because Apple's new arm64-based Macs have Thunderbolt integrated into
the SoC and arm64 SoCs are making inroads in the datacenter, which is
an important use case for PCIe hotplug (hot-swappable NVMe drives).
So we may have to amend pci_bridge_d3_possible() to whitelist
PCIe ports for runtime PM on specific arches or systems.

Thanks,

Lukas

Re: [PATCH v2 1/2] clocksource: arm_arch_timer: Use stable count reader in erratum sne

[zhukeqian]

Hi Marc,

On 2020/12/3 22:58, Marc Zyngier wrote:
> On 2020-08-18 04:28, Keqian Zhu wrote:
>> In commit 0ea415390cd3 ("clocksource/arm_arch_timer: Use 
>> arch_timer_read_counter
>> to access stable counters"), we separate stable and normal count reader to 
>> omit
>> unnecessary overhead on systems that have no timer erratum.
>>
>> However, in erratum_set_next_event_tval_generic(), count reader becomes 
>> normal
>> reader. This converts it to stable reader.
>>
>> Fixes: 0ea415390cd3 ("clocksource/arm_arch_timer: Use
>>arch_timer_read_counter to access stable counters")
> 
> On a single line.
Addressed. Thanks.

> 
>> Signed-off-by: Keqian Zhu 
>> ---
>>  drivers/clocksource/arm_arch_timer.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/clocksource/arm_arch_timer.c
>> b/drivers/clocksource/arm_arch_timer.c
>> index 6c3e841..777d38c 100644
>> --- a/drivers/clocksource/arm_arch_timer.c
>> +++ b/drivers/clocksource/arm_arch_timer.c
>> @@ -396,10 +396,10 @@ static void
>> erratum_set_next_event_tval_generic(const int access, unsigned long
>>  ctrl &= ~ARCH_TIMER_CTRL_IT_MASK;
>>
>>  if (access == ARCH_TIMER_PHYS_ACCESS) {
>> -cval = evt + arch_counter_get_cntpct();
>> +cval = evt + arch_counter_get_cntpct_stable();
>>  write_sysreg(cval, cntp_cval_el0);
>>  } else {
>> -cval = evt + arch_counter_get_cntvct();
>> +cval = evt + arch_counter_get_cntvct_stable();
>>  write_sysreg(cval, cntv_cval_el0);
>>  }
> 
> With that fixed:
> 
> Acked-by: Marc Zyngier 
> 
> This should go via the clocksource tree.
Added Cc to it's maintainers, thanks.

> 
> Thanks,
> 
> M.
Cheers,
Keqian

Re: [RFC PATCH 5/9] cxl/mem: Find device capabilities

[Dan Williams]

On Wed, Nov 25, 2020 at 10:06 PM Jon Masters  wrote:
>
> On 11/11/20 12:43 AM, Ben Widawsky wrote:
>
> > + case CXL_CAPABILITIES_CAP_ID_SECONDARY_MAILBOX:
> > + dev_dbg(>pdev->dev,
> > +"found UNSUPPORTED Secondary Mailbox 
> > capability\n");
>
> Per spec, the secondary mailbox is intended for use by platform
> firmware, so Linux should never be using it anyway. Maybe that message
> is slightly misleading?
>
> Jon.
>
> P.S. Related - I've severe doubts about the mailbox approach being
> proposed by CXL and have begun to push back through the spec org.

The more Linux software voices the better. At the same time the spec
is released so we're into xkcd territory [1] of what the driver will
be expected to support for any future improvements.

[1]: https://xkcd.com/927/

[PATCH v3 1/2] clocksource: arm_arch_timer: Use stable count reader in erratum sne

[Keqian Zhu]

In commit 0ea415390cd3 ("clocksource/arm_arch_timer: Use arch_timer_read_counter
to access stable counters"), we separate stable and normal count reader to omit
unnecessary overhead on systems that have no timer erratum.

However, in erratum_set_next_event_tval_generic(), count reader becomes normal
reader. This converts it to stable reader.

Fixes: 0ea415390cd3 ("clocksource/arm_arch_timer: Use arch_timer_read_counter 
to access stable counters")
Acked-by: Marc Zyngier 
Signed-off-by: Keqian Zhu 
---
 drivers/clocksource/arm_arch_timer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/arm_arch_timer.c 
b/drivers/clocksource/arm_arch_timer.c
index 6c3e84180146..777d38cb39b0 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -396,10 +396,10 @@ static void erratum_set_next_event_tval_generic(const int 
access, unsigned long
ctrl &= ~ARCH_TIMER_CTRL_IT_MASK;
 
if (access == ARCH_TIMER_PHYS_ACCESS) {
-   cval = evt + arch_counter_get_cntpct();
+   cval = evt + arch_counter_get_cntpct_stable();
write_sysreg(cval, cntp_cval_el0);
} else {
-   cval = evt + arch_counter_get_cntvct();
+   cval = evt + arch_counter_get_cntvct_stable();
write_sysreg(cval, cntv_cval_el0);
}
 
-- 
2.23.0

[PATCH v3 2/2] clocksource: arm_arch_timer: Correct fault programming of CNTKCTL_EL1.EVNTI

[Keqian Zhu]

ARM virtual counter supports event stream, it can only trigger an event
when the trigger bit (the value of CNTKCTL_EL1.EVNTI) of CNTVCT_EL0 changes,
so the actual period of event stream is 2^(cntkctl_evnti + 1). For example,
when the trigger bit is 0, then virtual counter trigger an event for every
two cycles.

Fixes: 037f637767a8 ("drivers: clocksource: add support for ARM architected 
timer event stream")
Suggested-by: Marc Zyngier 
Signed-off-by: Keqian Zhu 
---
 drivers/clocksource/arm_arch_timer.c | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/clocksource/arm_arch_timer.c 
b/drivers/clocksource/arm_arch_timer.c
index 777d38cb39b0..d0177824c518 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -822,15 +822,24 @@ static void arch_timer_evtstrm_enable(int divider)
 
 static void arch_timer_configure_evtstream(void)
 {
-   int evt_stream_div, pos;
+   int evt_stream_div, lsb;
+
+   /*
+* As the event stream can at most be generated at half the frequency
+* of the counter, use half the frequency when computing the divider.
+*/
+   evt_stream_div = arch_timer_rate / ARCH_TIMER_EVT_STREAM_FREQ / 2;
+
+   /*
+* Find the closest power of two to the divisor. If the adjacent bit
+* of lsb (last set bit, starts from 0) is set, then we use (lsb + 1).
+*/
+   lsb = fls(evt_stream_div) - 1;
+   if (lsb > 0 && (evt_stream_div & BIT(lsb - 1)))
+   lsb++;
 
-   /* Find the closest power of two to the divisor */
-   evt_stream_div = arch_timer_rate / ARCH_TIMER_EVT_STREAM_FREQ;
-   pos = fls(evt_stream_div);
-   if (pos > 1 && !(evt_stream_div & (1 << (pos - 2
-   pos--;
/* enable event stream */
-   arch_timer_evtstrm_enable(min(pos, 15));
+   arch_timer_evtstrm_enable(max(0, min(lsb, 15)));
 }
 
 static void arch_counter_set_user_access(void)
-- 
2.23.0

[PATCH v3 0/2] clocksource: arm_arch_timer: Some fixes

[Keqian Zhu]

change log:

v3:
 - Address Marc's comments.
 - Reform arch_timer_configure_evtstream.

v2:
 - Do not revert commit 0ea415390cd3, fix it instead.
 - Correct the tags of second patch.

Keqian Zhu (2):
  clocksource: arm_arch_timer: Use stable count reader in erratum sne
  clocksource: arm_arch_timer: Correct fault programming of
CNTKCTL_EL1.EVNTI

 drivers/clocksource/arm_arch_timer.c | 27 ++-
 1 file changed, 18 insertions(+), 9 deletions(-)

-- 
2.23.0

[PATCH] Documentation: fix multiple typos found in the admin-guide subdirectory

[Andrew Klychkov]

Fix thirty five typos in dm-integrity.rst, dm-raid.rst, dm-zoned.rst,
verity.rst, writecache.rst, tsx_async_abort.rst, md.rst, bttv.rst,
dvb_references.rst, frontend-cardlist.rst, gspca-cardlist.rst, ipu3.rst,
remote-controller.rst, mm/index.rst, numaperf.rst, userfaultfd.rst,
module-signing.rst, imx-ddr.rst, intel-speed-select.rst,
intel_pstate.rst, ramoops.rst, abi.rst, kernel.rst, vm.rst

Reviewed-by: Jonathan Corbet 
Reviewed-by: Randy Dunlap 
Signed-off-by: Andrew Klychkov 
---
 Documentation/admin-guide/device-mapper/dm-integrity.rst | 4 ++--
 Documentation/admin-guide/device-mapper/dm-raid.rst  | 2 +-
 Documentation/admin-guide/device-mapper/dm-zoned.rst | 6 +++---
 Documentation/admin-guide/device-mapper/verity.rst   | 2 +-
 Documentation/admin-guide/device-mapper/writecache.rst   | 4 ++--
 Documentation/admin-guide/hw-vuln/tsx_async_abort.rst| 2 +-
 Documentation/admin-guide/md.rst | 2 +-
 Documentation/admin-guide/media/bttv.rst | 2 +-
 Documentation/admin-guide/media/dvb_references.rst   | 2 +-
 Documentation/admin-guide/media/frontend-cardlist.rst| 4 ++--
 Documentation/admin-guide/media/gspca-cardlist.rst   | 2 +-
 Documentation/admin-guide/media/ipu3.rst | 6 +++---
 Documentation/admin-guide/media/remote-controller.rst| 2 +-
 Documentation/admin-guide/mm/index.rst   | 4 ++--
 Documentation/admin-guide/mm/numaperf.rst| 2 +-
 Documentation/admin-guide/mm/userfaultfd.rst | 2 +-
 Documentation/admin-guide/module-signing.rst | 2 +-
 Documentation/admin-guide/perf/imx-ddr.rst   | 2 +-
 Documentation/admin-guide/pm/intel-speed-select.rst  | 4 ++--
 Documentation/admin-guide/pm/intel_pstate.rst| 6 +++---
 Documentation/admin-guide/ramoops.rst| 2 +-
 Documentation/admin-guide/sysctl/abi.rst | 2 +-
 Documentation/admin-guide/sysctl/kernel.rst  | 2 +-
 Documentation/admin-guide/sysctl/vm.rst  | 2 +-
 24 files changed, 35 insertions(+), 35 deletions(-)

diff --git a/Documentation/admin-guide/device-mapper/dm-integrity.rst 
b/Documentation/admin-guide/device-mapper/dm-integrity.rst
index 3ab4f77..4e6f504 100644
--- a/Documentation/admin-guide/device-mapper/dm-integrity.rst
+++ b/Documentation/admin-guide/device-mapper/dm-integrity.rst
@@ -117,7 +117,7 @@ journal_watermark:number
 
 commit_time:number
Commit time in milliseconds. When this time passes, the journal is
-   written. The journal is also written immediatelly if the FLUSH
+   written. The journal is also written immediately if the FLUSH
request is received.
 
 internal_hash:algorithm(:key)  (the key is optional)
@@ -147,7 +147,7 @@ journal_crypt:algorithm(:key)   (the key is optional)
"salsa20" or "ctr(aes)").
 
The journal contains history of last writes to the block device,
-   an attacker reading the journal could see the last sector nubmers
+   an attacker reading the journal could see the last sector numbers
that were written. From the sector numbers, the attacker can infer
the size of files that were written. To protect against this
situation, you can encrypt the journal.
diff --git a/Documentation/admin-guide/device-mapper/dm-raid.rst 
b/Documentation/admin-guide/device-mapper/dm-raid.rst
index 7ef9fe6..bb17e26 100644
--- a/Documentation/admin-guide/device-mapper/dm-raid.rst
+++ b/Documentation/admin-guide/device-mapper/dm-raid.rst
@@ -418,6 +418,6 @@ Version History
specific devices are requested via rebuild.  Fix RAID leg
rebuild errors.
  1.15.0 Fix size extensions not being synchronized in case of new MD bitmap
-pages allocated;  also fix those not occuring after previous reductions
+pages allocated;  also fix those not occurring after previous 
reductions
  1.15.1 Fix argument count and arguments for 
rebuild/write_mostly/journal_(dev|mode)
 on the status line.
diff --git a/Documentation/admin-guide/device-mapper/dm-zoned.rst 
b/Documentation/admin-guide/device-mapper/dm-zoned.rst
index e6350413..0fac051 100644
--- a/Documentation/admin-guide/device-mapper/dm-zoned.rst
+++ b/Documentation/admin-guide/device-mapper/dm-zoned.rst
@@ -24,7 +24,7 @@ The dm-zoned implementation is simple and minimizes system 
overhead (CPU
 and memory usage as well as storage capacity loss). For a 10TB
 host-managed disk with 256 MB zones, dm-zoned memory usage per disk
 instance is at most 4.5 MB and as little as 5 zones will be used
-internally for storing metadata and performaing reclaim operations.
+internally for storing metadata and performing reclaim operations.
 
 dm-zoned target devices are formatted and checked using the dmzadm
 utility available at:
@@ -102,7 +102,7 @@ the buffer zone assigned. If the accessed chunk has no 
mapping, or the
 accessed blocks are invalid, the read buffer is zeroed and 

Re: [RFC 1/2] perf core: Add PERF_COUNT_SW_CGROUP_SWITCHES event

[Namhyung Kim]

On Thu, Dec 3, 2020 at 9:20 PM Peter Zijlstra  wrote:
>
> On Wed, Dec 02, 2020 at 11:28:28AM -0800, Andi Kleen wrote:
> > > +   prev_cgrp = task_css_check(prev, perf_event_cgrp_id, 1)->cgroup;
> > > +   next_cgrp = task_css_check(next, perf_event_cgrp_id, 1)->cgroup;
> > > +
> > > +   if (prev_cgrp != next_cgrp)
> > > +   perf_sw_event_sched(PERF_COUNT_SW_CGROUP_SWITCHES, 1, 0);
> >
> > Seems to be the perf cgroup only, not all cgroups.
> > That's a big difference and needs to be documented properly.
>
> With cgroup-v2 that's all the same, no?

Right, but unfortunately it seems still cgroup v1 is used widely.

Thanks,
Namhyung

Re: [RFC PATCH 3/9] cxl/mem: Add a driver for the type-3 mailbox

[Dan Williams]

On Thu, Dec 3, 2020 at 11:22 PM Dan Williams  wrote:
>
> On Tue, Nov 17, 2020 at 6:50 AM Jonathan Cameron
>  wrote:
> >
> > On Tue, 10 Nov 2020 21:43:50 -0800
> > Ben Widawsky  wrote:
> >
> > > From: Dan Williams 
> > >
> > > The CXL.mem protocol allows a device to act as a provider of "System
> > > RAM" and/or "Persistent Memory" that is fully coherent as if the memory
> > > was attached to the typical CPU memory controller.
> > >
> > > The memory range exported by the device may optionally be described by
> > > the platform firmware memory map, or by infrastructure like LIBNVDIMM to
> > > provision persistent memory capacity from one, or more, CXL.mem devices.
> > >
> > > A pre-requisite for Linux-managed memory-capacity provisioning is this
> > > cxl_mem driver that can speak the "type-3 mailbox" protocol.
> > >
> > > For now just land the driver boiler-plate and fill it in with
> > > functionality in subsequent commits.
> > >
> > > Signed-off-by: Dan Williams 
> > > Signed-off-by: Ben Widawsky 
> >
> > I've tried to avoid repeats, so mostly this is me moaning about naming!
> >
> > Jonathan
> >
> > > ---
> > >  drivers/cxl/Kconfig  | 20 +++
> > >  drivers/cxl/Makefile |  2 ++
> > >  drivers/cxl/mem.c| 82 
> > >  drivers/cxl/pci.h| 15 
> > >  4 files changed, 119 insertions(+)
> > >  create mode 100644 drivers/cxl/mem.c
> > >  create mode 100644 drivers/cxl/pci.h
> > >
> > > diff --git a/drivers/cxl/Kconfig b/drivers/cxl/Kconfig
> > > index dd724bd364df..15548f5c77ff 100644
> > > --- a/drivers/cxl/Kconfig
> > > +++ b/drivers/cxl/Kconfig
> > > @@ -27,4 +27,24 @@ config CXL_ACPI
> > > resources described by the CEDT (CXL Early Discovery Table)
> > >
> > > Say 'y' to enable CXL (Compute Express Link) drivers.
> > > +
> > > +config CXL_MEM
> > > +tristate "CXL.mem Device Support"
> > > +depends on PCI && CXL_BUS_PROVIDER != n
> > > +default m if CXL_BUS_PROVIDER
> > > +help
> > > +  The CXL.mem protocol allows a device to act as a provider of
> > > +  "System RAM" and/or "Persistent Memory" that is fully coherent
> > > +  as if the memory was attached to the typical CPU memory
> > > +  controller.
> > > +
> > > +  Say 'y/m' to enable a driver named "cxl_mem.ko" that will 
> > > attach
> > > +  to CXL.mem devices for configuration, provisioning, and health
> > > +  monitoring, the so called "type-3 mailbox". Note, this driver
> > > +  is required for dynamic provisioning of CXL.mem attached
> > > +  memory, a pre-requisite for persistent memory support, but
> > > +  devices that provide volatile memory may be fully described by
> > > +  existing platform firmware memory enumeration.
> > > +
> > > +  If unsure say 'n'.
> > >  endif
> > > diff --git a/drivers/cxl/Makefile b/drivers/cxl/Makefile
> > > index d38cd34a2582..97fdffb00f2d 100644
> > > --- a/drivers/cxl/Makefile
> > > +++ b/drivers/cxl/Makefile
> > > @@ -1,5 +1,7 @@
> > >  # SPDX-License-Identifier: GPL-2.0
> > >  obj-$(CONFIG_CXL_ACPI) += cxl_acpi.o
> > > +obj-$(CONFIG_CXL_MEM) += cxl_mem.o
> > >
> > >  ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE=CXL
> > >  cxl_acpi-y := acpi.o
> > > +cxl_mem-y := mem.o
> > > diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> > > new file mode 100644
> > > index ..aa7d881fa47b
> > > --- /dev/null
> > > +++ b/drivers/cxl/mem.c
> > > @@ -0,0 +1,82 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +// Copyright(c) 2020 Intel Corporation. All rights reserved.
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include "acpi.h"
> > > +#include "pci.h"
> > > +
> > > +struct cxl_mem {
> > > + void __iomem *regs;
> > > +};
> > > +
> > > +static int cxl_mem_dvsec(struct pci_dev *pdev, int dvsec)
> > > +{
> > > + int pos;
> > > +
> > > + pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_DVSEC);
> > > + if (!pos)
> > > + return 0;
> > > +
> > > + while (pos) {
> > > + u16 vendor, id;
> > > +
> > > + pci_read_config_word(pdev, pos + PCI_DVSEC_VENDOR_OFFSET, 
> > > );
> > > + pci_read_config_word(pdev, pos + PCI_DVSEC_ID_OFFSET, );
> > > + if (vendor == PCI_DVSEC_VENDOR_CXL && dvsec == id)
> > > + return pos;
> > > +
> > > + pos = pci_find_next_ext_capability(pdev, pos, 
> > > PCI_EXT_CAP_ID_DVSEC);
> >
> > This is good generic code and wouldn't cause much backport effort (even if 
> > needed
> > to bring in a local copy), so perhaps make it a generic function and move to
> > core PCI code?
> >
> > Mind you I guess that can happen the 'second' time someone wants to find a 
> > DVSEC.
> >
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int cxl_mem_probe(struct pci_dev *pdev, const struct 
> > > pci_device_id *id)
> > > +{
> > > + struct device *dev = >dev;

[PATCH v2] f2fs: fix race of pending_pages in decompression

[Daeho Jeong]

From: Daeho Jeong 

I found out f2fs_free_dic() is invoked in a wrong timing, but
f2fs_verify_bio() still needed the dic info and it triggered the
below kernel panic. It has been caused by the race condition of
pending_pages value between decompression and verity logic, when
the same compression cluster had been split in different bios.
By split bios, f2fs_verify_bio() ended up with decreasing
pending_pages value before it is reset to nr_cpages by
f2fs_decompress_pages() and caused the kernel panic.

[ 4416.564763] Unable to handle kernel NULL pointer dereference
   at virtual address 
...
[ 4416.896016] Workqueue: fsverity_read_queue f2fs_verity_work
[ 4416.908515] pc : fsverity_verify_page+0x20/0x78
[ 4416.913721] lr : f2fs_verify_bio+0x11c/0x29c
[ 4416.913722] sp : ffc019533cd0
[ 4416.913723] x29: ffc019533cd0 x28: 0402
[ 4416.913724] x27: 0001 x26: 0100
[ 4416.913726] x25: 0001 x24: 0004
[ 4416.913727] x23: 1000 x22: 
[ 4416.913728] x21:  x20: 2076f9c0
[ 4416.913729] x19: 2076f9c0 x18: ff8a32380c30
[ 4416.913731] x17: ffc01f966d97 x16: 0298
[ 4416.913732] x15:  x14: 
[ 4416.913733] x13: f074faec89ff x12: 
[ 4416.913734] x11: 1000 x10: 1000
[ 4416.929176] x9 : 20d1f5c7 x8 : 
[ 4416.929178] x7 : 626d7464ff286b6b x6 : ffc019533ade
[ 4416.929179] x5 : 8049000e x4 : 2793e9e0
[ 4416.929180] x3 : 8049000e x2 : ff89ecfa74d0
[ 4416.929181] x1 : 0c40 x0 : 2076f9c0
[ 4416.929184] Call trace:
[ 4416.929187]  fsverity_verify_page+0x20/0x78
[ 4416.929189]  f2fs_verify_bio+0x11c/0x29c
[ 4416.929192]  f2fs_verity_work+0x58/0x84
[ 4417.050667]  process_one_work+0x270/0x47c
[ 4417.055354]  worker_thread+0x27c/0x4d8
[ 4417.059784]  kthread+0x13c/0x320
[ 4417.063693]  ret_from_fork+0x10/0x18

Signed-off-by: Daeho Jeong 
Signed-off-by: Jaegeuk Kim 
---
v2: merged verity_pages with pending_pages, and increased the
pending_pages count only if STEP_VERITY is set on bio
---
 fs/f2fs/compress.c | 2 --
 fs/f2fs/data.c | 2 ++
 fs/f2fs/f2fs.h | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/f2fs/compress.c b/fs/f2fs/compress.c
index 87090da8693d..832b19986caf 100644
--- a/fs/f2fs/compress.c
+++ b/fs/f2fs/compress.c
@@ -803,8 +803,6 @@ void f2fs_decompress_pages(struct bio *bio, struct page 
*page, bool verity)
if (cops->destroy_decompress_ctx)
cops->destroy_decompress_ctx(dic);
 out_free_dic:
-   if (verity)
-   atomic_set(>pending_pages, dic->nr_cpages);
if (!verity)
f2fs_decompress_end_io(dic->rpages, dic->cluster_size,
ret, false);
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 42254d3859c7..b825d63cabdd 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -2290,6 +2290,8 @@ int f2fs_read_multi_pages(struct compress_ctx *cc, struct 
bio **bio_ret,
ctx = bio->bi_private;
if (!(ctx->enabled_steps & (1 << STEP_DECOMPRESS)))
ctx->enabled_steps |= 1 << STEP_DECOMPRESS;
+   if (ctx->enabled_steps & (1 << STEP_VERITY))
+   atomic_inc(>pending_pages);
 
inc_page_count(sbi, F2FS_RD_DATA);
f2fs_update_iostat(sbi, FS_DATA_READ_IO, F2FS_BLKSIZE);
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 94d16bde5e24..a9ee7921c7ec 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1340,7 +1340,7 @@ struct decompress_io_ctx {
struct compress_data *cbuf; /* virtual mapped address on cpages */
size_t rlen;/* valid data length in rbuf */
size_t clen;/* valid data length in cbuf */
-   atomic_t pending_pages; /* in-flight compressed page count */
+   atomic_t pending_pages; /* in-flight compressed + verity page 
count */
bool failed;/* indicate IO error during 
decompression */
void *private;  /* payload buffer for specified 
decompression algorithm */
void *private2; /* extra payload buffer */
-- 
2.29.2.576.ga3fc446d84-goog

Re: [RFC 1/2] perf core: Add PERF_COUNT_SW_CGROUP_SWITCHES event

[Namhyung Kim]

On Thu, Dec 3, 2020 at 4:45 PM Peter Zijlstra  wrote:
>
> On Thu, Dec 03, 2020 at 11:10:30AM +0900, Namhyung Kim wrote:
> > On Thu, Dec 3, 2020 at 1:19 AM Peter Zijlstra  wrote:
> >
> > > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> > > index 9a38f579bc76..5eb284819ee5 100644
> > > --- a/include/linux/perf_event.h
> > > +++ b/include/linux/perf_event.h
> > > @@ -1174,25 +1174,19 @@ DECLARE_PER_CPU(struct pt_regs, __perf_regs[4]);
> > >   * which is guaranteed by us not actually scheduling inside other 
> > > swevents
> > >   * because those disable preemption.
> > >   */
> > > -static __always_inline void
> > > -perf_sw_event_sched(u32 event_id, u64 nr, u64 addr)
> > > +static __always_inline void __perf_sw_event_sched(u32 event_id, u64 nr, 
> > > u64 addr)
> >
> > It'd be nice to avoid the __ prefix if possible.
>
> Not having __ would seem to suggest its a function of generic utility.
> Still, *shrug* ;-)

Ok, noted.

>
> > >  {
> > > -   if 
> > > (static_key_false(_swevent_enabled[PERF_COUNT_SW_CPU_MIGRATIONS]))
> > > -   return true;
> > > -   return false;
> > > +   return static_key_false(_swevent_enabled[swevt]);
> > >  }
> > >
> > >  static inline void perf_event_task_migrate(struct task_struct *task)
> > > @@ -1207,11 +1201,9 @@ static inline void perf_event_task_sched_in(struct 
> > > task_struct *prev,
> > > if (static_branch_unlikely(_sched_events))
> > > __perf_event_task_sched_in(prev, task);
> > >
> > > -   if (perf_sw_migrate_enabled() && task->sched_migrated) {
> > > -   struct pt_regs *regs = this_cpu_ptr(&__perf_regs[0]);
> > > -
> > > -   perf_fetch_caller_regs(regs);
> > > -   ___perf_sw_event(PERF_COUNT_SW_CPU_MIGRATIONS, 1, regs, 
> > > 0);
> > > +   if (__perf_sw_enabled(PERF_COUNT_SW_CPU_MIGRATIONS) &&
> > > +   task->sched_migrated) {
> >
> > It seems task->sched_migrate is set only if the event is enabled,
> > then can we just check the value here?
>
> Why suffer the unconditional load and test? Your L1 too big?

I just wanted to avoid typing long lines.. ;-p

>
> > > +   __perf_sw_event_sched(PERF_COUNT_SW_CPU_MIGRATIONS, 1, 0);
> > > task->sched_migrated = 0;
> > > }
> > >  }
> > > @@ -1219,7 +1211,13 @@ static inline void perf_event_task_sched_in(struct 
> > > task_struct *prev,
> > >  static inline void perf_event_task_sched_out(struct task_struct *prev,
> > >  struct task_struct *next)
> > >  {
> > > -   perf_sw_event_sched(PERF_COUNT_SW_CONTEXT_SWITCHES, 1, 0);
> > > +   if (__perf_sw_enabled(PERF_COUNT_SW_CONTEXT_SWITCHES))
> > > +   __perf_sw_event_sched(PERF_COUNT_SW_CONTEXT_SWITCHES, 1, 
> > > 0);
> > > +
> > > +   if (__perf_sw_enabled(PERF_COUNT_SW_CGROUP_SWITCHES) &&
> > > +   (task_css_check(prev, perf_event_cgrp_id, 1)->cgroup !=
> > > +task_css_check(next, perf_event_cgrp_id, 1)->cgroup))
> > > +   __perf_sw_event_sched(PERF_COUNT_SW_CGROUP_SWITCHES, 1, 
> > > 0);
> >
> > I was not clear about the RCU protection here.  Is it ok to access
> > the task's css_set directly?
>
> We're here with preemption and IRQs disabled, good luck trying to get
> RCU to consider that not a critical section and spirit things away under
> us.

Ok, someday I'll go reading the RCU code.. :)

Thanks,
Namhyung

Re: [PATCH] tty: Remove dead termiox code

[Jiri Slaby]

On 03. 12. 20, 3:03, Jann Horn wrote:

set_termiox() and the TCGETX handler bail out with -EINVAL immediately
if ->termiox is NULL, but there are no code paths that can set
->termiox to a non-NULL pointer; and no such code paths seem to have
existed since the termiox mechanism was introduced back in
commit 1d65b4a088de ("tty: Add termiox") in v2.6.28.
Similarly, no driver actually implements .set_termiox; and it looks like
no driver ever has.


Nice!


Delete this dead code; but leave the definition of struct termiox in the
UAPI headers intact.


I am thinking -- can/should we mark the structure as deprecated so that 
userspace stops using it eventually?


--
js

Re: [RFC PATCH 3/9] cxl/mem: Add a driver for the type-3 mailbox

[Dan Williams]

On Tue, Nov 17, 2020 at 6:50 AM Jonathan Cameron
 wrote:
>
> On Tue, 10 Nov 2020 21:43:50 -0800
> Ben Widawsky  wrote:
>
> > From: Dan Williams 
> >
> > The CXL.mem protocol allows a device to act as a provider of "System
> > RAM" and/or "Persistent Memory" that is fully coherent as if the memory
> > was attached to the typical CPU memory controller.
> >
> > The memory range exported by the device may optionally be described by
> > the platform firmware memory map, or by infrastructure like LIBNVDIMM to
> > provision persistent memory capacity from one, or more, CXL.mem devices.
> >
> > A pre-requisite for Linux-managed memory-capacity provisioning is this
> > cxl_mem driver that can speak the "type-3 mailbox" protocol.
> >
> > For now just land the driver boiler-plate and fill it in with
> > functionality in subsequent commits.
> >
> > Signed-off-by: Dan Williams 
> > Signed-off-by: Ben Widawsky 
>
> I've tried to avoid repeats, so mostly this is me moaning about naming!
>
> Jonathan
>
> > ---
> >  drivers/cxl/Kconfig  | 20 +++
> >  drivers/cxl/Makefile |  2 ++
> >  drivers/cxl/mem.c| 82 
> >  drivers/cxl/pci.h| 15 
> >  4 files changed, 119 insertions(+)
> >  create mode 100644 drivers/cxl/mem.c
> >  create mode 100644 drivers/cxl/pci.h
> >
> > diff --git a/drivers/cxl/Kconfig b/drivers/cxl/Kconfig
> > index dd724bd364df..15548f5c77ff 100644
> > --- a/drivers/cxl/Kconfig
> > +++ b/drivers/cxl/Kconfig
> > @@ -27,4 +27,24 @@ config CXL_ACPI
> > resources described by the CEDT (CXL Early Discovery Table)
> >
> > Say 'y' to enable CXL (Compute Express Link) drivers.
> > +
> > +config CXL_MEM
> > +tristate "CXL.mem Device Support"
> > +depends on PCI && CXL_BUS_PROVIDER != n
> > +default m if CXL_BUS_PROVIDER
> > +help
> > +  The CXL.mem protocol allows a device to act as a provider of
> > +  "System RAM" and/or "Persistent Memory" that is fully coherent
> > +  as if the memory was attached to the typical CPU memory
> > +  controller.
> > +
> > +  Say 'y/m' to enable a driver named "cxl_mem.ko" that will attach
> > +  to CXL.mem devices for configuration, provisioning, and health
> > +  monitoring, the so called "type-3 mailbox". Note, this driver
> > +  is required for dynamic provisioning of CXL.mem attached
> > +  memory, a pre-requisite for persistent memory support, but
> > +  devices that provide volatile memory may be fully described by
> > +  existing platform firmware memory enumeration.
> > +
> > +  If unsure say 'n'.
> >  endif
> > diff --git a/drivers/cxl/Makefile b/drivers/cxl/Makefile
> > index d38cd34a2582..97fdffb00f2d 100644
> > --- a/drivers/cxl/Makefile
> > +++ b/drivers/cxl/Makefile
> > @@ -1,5 +1,7 @@
> >  # SPDX-License-Identifier: GPL-2.0
> >  obj-$(CONFIG_CXL_ACPI) += cxl_acpi.o
> > +obj-$(CONFIG_CXL_MEM) += cxl_mem.o
> >
> >  ccflags-y += -DDEFAULT_SYMBOL_NAMESPACE=CXL
> >  cxl_acpi-y := acpi.o
> > +cxl_mem-y := mem.o
> > diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> > new file mode 100644
> > index ..aa7d881fa47b
> > --- /dev/null
> > +++ b/drivers/cxl/mem.c
> > @@ -0,0 +1,82 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +// Copyright(c) 2020 Intel Corporation. All rights reserved.
> > +#include 
> > +#include 
> > +#include 
> > +#include "acpi.h"
> > +#include "pci.h"
> > +
> > +struct cxl_mem {
> > + void __iomem *regs;
> > +};
> > +
> > +static int cxl_mem_dvsec(struct pci_dev *pdev, int dvsec)
> > +{
> > + int pos;
> > +
> > + pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_DVSEC);
> > + if (!pos)
> > + return 0;
> > +
> > + while (pos) {
> > + u16 vendor, id;
> > +
> > + pci_read_config_word(pdev, pos + PCI_DVSEC_VENDOR_OFFSET, 
> > );
> > + pci_read_config_word(pdev, pos + PCI_DVSEC_ID_OFFSET, );
> > + if (vendor == PCI_DVSEC_VENDOR_CXL && dvsec == id)
> > + return pos;
> > +
> > + pos = pci_find_next_ext_capability(pdev, pos, 
> > PCI_EXT_CAP_ID_DVSEC);
>
> This is good generic code and wouldn't cause much backport effort (even if 
> needed
> to bring in a local copy), so perhaps make it a generic function and move to
> core PCI code?
>
> Mind you I guess that can happen the 'second' time someone wants to find a 
> DVSEC.
>
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id 
> > *id)
> > +{
> > + struct device *dev = >dev;
> > + struct cxl_mem *cxlm;
> > + int rc, regloc;
> > +
> > + rc = cxl_bus_prepared(pdev);
> > + if (rc != 0) {
> > + dev_err(dev, "failed to acquire interface\n");
> > + return rc;
> > + }
> > +
> > + regloc = cxl_mem_dvsec(pdev, PCI_DVSEC_ID_CXL_REGLOC);
> > + if (!regloc) {

REQUEST.

[Angela Campbell]

I am sorry for interrupting your day, with due respect trust and humility, I 
write to you this proposal, which I believe would be of great interest to you. 
I am looking for a reliable and capable partner that will assist my family and 
I to transfer funds to his personal or company account for investment purposes 
because of my health..

I am Mrs. Angela Campbell, A German citizen and wife to Late Mr. Mike Campbell, 
who was a Commercial Farmer and cocoa merchant in Bindura and Harare, the 
economic city of Zimbabwe.

My husband was among the people that were murdered in cold blood by the 
President Robert Mugabe Administration during the land dispute that just 
happened in Zimbabwe wholly affected the white farmers and this resulted to the 
killing and mob action by Zimbabwean war veterans and some lunatics in the 
society. In fact, a lot of people were killed because of this land reformed Act.

Please for further details, kindly email me with your direct contact 
informations to my private email address: angelacamp2...@outlook.com 

Full Name:|Home Address|Telephone Number|Mobile Number|Date of Birth| 
Occupation:.

Please do notify me immediately you receive this proposal.

Thanks and God bless you

Mrs. Angela Campbell and (Family).

Re: [PATCH v7 1/4] dt-bindings: dmaengine: Add MediaTek Command-Queue DMA controller bindings

[EastL]

sorry for the delayed response.

On Tue, 2020-08-18 at 10:47 -0600, Rob Herring wrote:
> On Tue, Aug 18, 2020 at 11:03:51AM +0800, EastL Lee wrote:
> > Document the devicetree bindings for MediaTek Command-Queue DMA controller
> > which could be found on MT6779 SoC or other similar Mediatek SoCs.
> > 
> > Signed-off-by: EastL Lee 
> > ---
> >  .../devicetree/bindings/dma/mtk-cqdma.yaml | 98 
> > ++
> >  1 file changed, 98 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/dma/mtk-cqdma.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/dma/mtk-cqdma.yaml 
> > b/Documentation/devicetree/bindings/dma/mtk-cqdma.yaml
> > new file mode 100644
> > index 000..fe03081
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/dma/mtk-cqdma.yaml
> > @@ -0,0 +1,98 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/dma/mtk-cqdma.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: MediaTek Command-Queue DMA controller Device Tree Binding
> > +
> > +maintainers:
> > +  - EastL Lee 
> > +
> > +description:
> > +  MediaTek Command-Queue DMA controller (CQDMA) on Mediatek SoC
> > +  is dedicated to memory-to-memory transfer through queue based
> > +  descriptor management.
> > +
> > +allOf:
> > +  - $ref: "dma-controller.yaml#"
> > +
> > +properties:
> > +  compatible:
> > +oneOf:
> > +  - const: mediatek,mt6765-cqdma
> > +  - const: mediatek,mt6779-cqdma
> 
> Use enum instead of oneOf+const.
OK
> 
> > +
> > +  reg:
> > +minItems: 1
> > +maxItems: 5
> > +description:
> > +A base address of MediaTek Command-Queue DMA controller,
> > +a channel will have a set of base address.
> > +
> > +  interrupts:
> > +minItems: 1
> > +maxItems: 5
> > +description:
> > +A interrupt number of MediaTek Command-Queue DMA controller,
> > +one interrupt number per dma-channels.
> > +
> > +  clocks:
> > +maxItems: 1
> > +
> > +  clock-names:
> > +const: cqdma
> > +
> > +  dma-channels:
> > +$ref: /schemas/types.yaml#definitions/uint32
> 
> Common properties already have a type definition.
OK I'll remove
> 
> > +description:
> > +  Number of DMA channels supported by MediaTek Command-Queue DMA
> > +  controller, support up to five.
> > +items:
> 
> Not an array, so drop 'items'.
OK
> 
> > +  minimum: 1
> > +  maximum: 5
> > +
> > +  dma-requests:
> > +$ref: /schemas/types.yaml#definitions/uint32
> > +description:
> > +  Number of DMA request (virtual channel) supported by MediaTek
> > +  Command-Queue DMA controller, support up to 32.
> > +items:
> > +  minimum: 1
> > +  maximum: 32
> 
> Same issues here.
OK
> 
> > +
> > +required:
> > +  - "#dma-cells"
> > +  - compatible
> > +  - reg
> > +  - interrupts
> > +  - clocks
> > +  - clock-names
> > +  - dma-channel-mask
> 
> Need to list in properties to fix the check error:
> 
> dma-channel-mask: true

OK
> 
> > +  - dma-channels
> > +  - dma-requests
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > +  - |
> > +#include 
> > +#include 
> > +#include 
> > +cqdma: dma-controller@10212000 {
> > +compatible = "mediatek,mt6779-cqdma";
> > +reg = <0x10212000 0x80>,
> > +<0x10212080 0x80>,
> > +<0x10212100 0x80>;
> > +interrupts = ,
> > +,
> > +;
> > +clocks = <_ao CLK_INFRA_CQ_DMA>;
> > +clock-names = "cqdma";
> > +dma-channel-mask = <0x3f>;
> > +dma-channels = <3>;
> > +dma-requests = <32>;
> > +#dma-cells = <1>;
> > +};
> > +
> > +...
> > -- 
> > 1.9.1

Re: [PATCH] crypto: remove trailing semicolon in macro definition

[Herbert Xu]

On Fri, Nov 27, 2020 at 08:23:45AM -0800, t...@redhat.com wrote:
> From: Tom Rix 
> 
> The macro use will already have a semicolon.
> 
> Signed-off-by: Tom Rix 
> ---
>  crypto/seed.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH V2 3/3] perf: Optimize sched_task() in a context switch

[Namhyung Kim]

Hi Peter,

On Wed, Dec 2, 2020 at 2:29 AM Peter Zijlstra  wrote:
>
> On Mon, Nov 30, 2020 at 11:38:42AM -0800, kan.li...@linux.intel.com wrote:
> > From: Kan Liang 
> >
> > Some calls to sched_task() in a context switch can be avoided. For
> > example, large PEBS only requires flushing the buffer in context switch
> > out. The current code still invokes the sched_task() for large PEBS in
> > context switch in.
>
> I still hate this one, how's something like this then?
> Which I still don't really like.. but at least its simpler.
>
> (completely untested, may contain spurious edits, might ICE the
> compiler and set your pets on fire if it doesn't)

I've tested this version... and it worked well besides the optimization.. :)

[SNIP]
> +static void context_sched_task(struct perf_cpu_context *cpuctx,
> +  struct perf_event_context *ctx,
> +  bool sched_in)
> +{
> +   struct pmu *pmu = ctx->pmu;
> +
> +   if (cpuctx->sched_cb_dir[sched_in] && pmu->sched_task)
> +   pmu->sched_task(ctx, false);

applied: s/false/sched_in/


> +}
> +
>  static void perf_event_context_sched_out(struct task_struct *task, int ctxn,
>  struct task_struct *next)
>  {
> @@ -3424,9 +3433,7 @@ static void perf_event_context_sched_out
> WRITE_ONCE(next_ctx->task, task);
>
> perf_pmu_disable(pmu);
> -
> -   if (cpuctx->sched_cb_usage && pmu->sched_task)
> -   pmu->sched_task(ctx, false);
> +   context_sched_task(cpuctx, ctx, false);
>
> /*
>  * PMU specific parts of task perf context can require
> @@ -3465,8 +3472,7 @@ static void perf_event_context_sched_out
> raw_spin_lock(>lock);
> perf_pmu_disable(pmu);
>
> -   if (cpuctx->sched_cb_usage && pmu->sched_task)
> -   pmu->sched_task(ctx, false);
> +   context_sched_task(cpuctx, ctx, false);
> task_ctx_sched_out(cpuctx, ctx, EVENT_ALL);
>
> perf_pmu_enable(pmu);

[SNIP]
> @@ -3563,8 +3582,7 @@ void __perf_event_task_sched_out(struct
>  {
> int ctxn;
>
> -   if (__this_cpu_read(perf_sched_cb_usage))
> -   perf_pmu_sched_task(task, next, false);
> +   perf_pmu_sched_task(task, next, false);

I think the reason is this change.  It now calls perf_pmu_sched_task()
without checking the counter.  And this is for per-cpu events.

>
> if (atomic_read(_switch_events))
> perf_event_switch(task, next, false);
> @@ -3828,8 +3846,7 @@ static void perf_event_context_sched_in(
> cpu_ctx_sched_out(cpuctx, EVENT_FLEXIBLE);
> perf_event_sched_in(cpuctx, ctx, task);
>
> -   if (cpuctx->sched_cb_usage && pmu->sched_task)
> -   pmu->sched_task(cpuctx->task_ctx, true);
> +   context_sched_task(cpuctx, ctx, true);
>
> perf_pmu_enable(pmu);
>
> @@ -3875,8 +3892,7 @@ void __perf_event_task_sched_in(struct t
> if (atomic_read(_switch_events))
> perf_event_switch(task, prev, true);
>
> -   if (__this_cpu_read(perf_sched_cb_usage))
> -   perf_pmu_sched_task(prev, task, true);
> +   perf_pmu_sched_task(prev, task, true);

Ditto.

>  }
>
>  static u64 perf_calculate_period(struct perf_event *event, u64 nsec, u64 
> count)

So I made a change like below.. and it could bring the optimization back.

Thanks,
Namhyung


diff --git a/kernel/events/core.c b/kernel/events/core.c
index 9107e7c3ccfb..a30243a9fab5 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -3528,6 +3528,9 @@ static void __perf_pmu_sched_task(struct
perf_cpu_context *cpuctx, bool sched_in
 {
struct pmu *pmu;

+   if (!cpuctx->sched_cb_dir[sched_in])
+   return;
+
pmu = cpuctx->ctx.pmu; /* software PMUs will not have sched_task */

if (WARN_ON_ONCE(!pmu->sched_task))

[PATCH V3 7/7] remoteproc: imx_proc: enable virtio/mailbox

[Peng Fan (OSS)]

From: Peng Fan 

Use virtio/mailbox to build connection between Remote Proccessors
and Linux. Add work queue to handle incoming messages.

Reviewed-by: Richard Zhu 
Signed-off-by: Peng Fan 
---
 drivers/remoteproc/imx_rproc.c | 133 -
 1 file changed, 130 insertions(+), 3 deletions(-)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index afa650610996..584584a00921 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -16,6 +17,9 @@
 #include 
 #include 
 #include 
+#include 
+
+#include "remoteproc_internal.h"
 
 #define IMX7D_SRC_SCR  0x0C
 #define IMX7D_ENABLE_M4BIT(3)
@@ -88,6 +92,11 @@ struct imx_rproc {
const struct imx_rproc_dcfg *dcfg;
struct imx_rproc_memmem[IMX7D_RPROC_MEM_MAX];
struct clk  *clk;
+   struct mbox_client  cl;
+   struct mbox_chan*tx_ch;
+   struct mbox_chan*rx_ch;
+   struct work_struct  rproc_work;
+   struct workqueue_struct *workqueue;
 };
 
 static const struct imx_rproc_att imx_rproc_att_imx8mq[] = {
@@ -369,9 +378,33 @@ static int imx_rproc_parse_fw(struct rproc *rproc, const 
struct firmware *fw)
return 0;
 }
 
+static void imx_rproc_kick(struct rproc *rproc, int vqid)
+{
+   struct imx_rproc *priv = rproc->priv;
+   int err;
+   __u32 mmsg;
+
+   if (!priv->tx_ch) {
+   dev_err(priv->dev, "No initialized mbox tx channel\n");
+   return;
+   }
+
+   /*
+* Send the index of the triggered virtqueue as the mu payload.
+* Let remote processor know which virtqueue is used.
+*/
+   mmsg = vqid << 16;
+
+   err = mbox_send_message(priv->tx_ch, (void *));
+   if (err < 0)
+   dev_err(priv->dev, "%s: failed (%d, err:%d)\n",
+   __func__, vqid, err);
+}
+
 static const struct rproc_ops imx_rproc_ops = {
.start  = imx_rproc_start,
.stop   = imx_rproc_stop,
+   .kick   = imx_rproc_kick,
.da_to_va   = imx_rproc_da_to_va,
.load   = rproc_elf_load_segments,
.parse_fw   = imx_rproc_parse_fw,
@@ -454,6 +487,77 @@ static void imx_rproc_memset(struct rproc *rproc, void *s, 
int c, size_t count)
memset_io((void * __iomem)s, c, count);
 }
 
+static void imx_rproc_vq_work(struct work_struct *work)
+{
+   struct imx_rproc *priv = container_of(work, struct imx_rproc,
+ rproc_work);
+
+   rproc_vq_interrupt(priv->rproc, 0);
+   rproc_vq_interrupt(priv->rproc, 1);
+}
+
+static void imx_rproc_rx_callback(struct mbox_client *cl, void *msg)
+{
+   struct rproc *rproc = dev_get_drvdata(cl->dev);
+   struct imx_rproc *priv = rproc->priv;
+
+   queue_work(priv->workqueue, >rproc_work);
+}
+
+static int imx_rproc_xtr_mbox_init(struct rproc *rproc)
+{
+   struct imx_rproc *priv = rproc->priv;
+   struct device *dev = priv->dev;
+   struct mbox_client *cl;
+   int ret = 0;
+
+   if (!of_get_property(dev->of_node, "mbox-names", NULL))
+   return 0;
+
+   cl = >cl;
+   cl->dev = dev;
+   cl->tx_block = true;
+   cl->tx_tout = 100;
+   cl->knows_txdone = false;
+   cl->rx_callback = imx_rproc_rx_callback;
+
+   priv->tx_ch = mbox_request_channel_byname(cl, "tx");
+   if (IS_ERR(priv->tx_ch)) {
+   if (PTR_ERR(priv->tx_ch) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   ret = PTR_ERR(priv->tx_ch);
+   dev_dbg(cl->dev, "failed to request mbox tx chan, ret %d\n",
+   ret);
+   goto err_out;
+   }
+
+   priv->rx_ch = mbox_request_channel_byname(cl, "rx");
+   if (IS_ERR(priv->rx_ch)) {
+   ret = PTR_ERR(priv->rx_ch);
+   dev_dbg(cl->dev, "failed to request mbox rx chan, ret %d\n",
+   ret);
+   goto err_out;
+   }
+
+   return ret;
+
+err_out:
+   if (!IS_ERR(priv->tx_ch))
+   mbox_free_channel(priv->tx_ch);
+   if (!IS_ERR(priv->rx_ch))
+   mbox_free_channel(priv->rx_ch);
+
+   return ret;
+}
+
+static void imx_rproc_free_mbox(struct rproc *rproc)
+{
+   struct imx_rproc *priv = rproc->priv;
+
+   mbox_free_channel(priv->tx_ch);
+   mbox_free_channel(priv->rx_ch);
+}
+
 static int imx_rproc_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -496,18 +600,31 @@ static int imx_rproc_probe(struct platform_device *pdev)
priv->dev = dev;
 
dev_set_drvdata(dev, rproc);
+   priv->workqueue = create_workqueue(dev_name(dev));
+   if (!priv->workqueue) {
+

[PATCH V3 5/7] remoteproc: imx_rproc: add i.MX specific parse fw hook

[Peng Fan (OSS)]

From: Peng Fan 

The hook is used to parse memory-regions and load resource table
from the address the remote processor published.

Signed-off-by: Peng Fan 
Reviewed-by: Richard Zhu 
Reviewed-by: Mathieu Poirier 
---
 drivers/remoteproc/imx_rproc.c | 93 ++
 1 file changed, 93 insertions(+)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 15c7baa480d7..de44b7d6ae63 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -243,10 +244,102 @@ static void *imx_rproc_da_to_va(struct rproc *rproc, u64 
da, size_t len)
return va;
 }
 
+static int imx_rproc_mem_alloc(struct rproc *rproc,
+  struct rproc_mem_entry *mem)
+{
+   struct device *dev = rproc->dev.parent;
+   void *va;
+
+   dev_dbg(dev, "map memory: %p+%zx\n", >dma, mem->len);
+   va = ioremap_wc(mem->dma, mem->len);
+   if (IS_ERR_OR_NULL(va)) {
+   dev_err(dev, "Unable to map memory region: %p+%zx\n",
+   >dma, mem->len);
+   return -ENOMEM;
+   }
+
+   /* Update memory entry va */
+   mem->va = va;
+
+   return 0;
+}
+
+static int imx_rproc_mem_release(struct rproc *rproc,
+struct rproc_mem_entry *mem)
+{
+   dev_dbg(rproc->dev.parent, "unmap memory: %pa\n", >dma);
+   iounmap(mem->va);
+
+   return 0;
+}
+
+static int imx_rproc_parse_memory_regions(struct rproc *rproc)
+{
+   struct imx_rproc *priv = rproc->priv;
+   struct device_node *np = priv->dev->of_node;
+   struct of_phandle_iterator it;
+   struct rproc_mem_entry *mem;
+   struct reserved_mem *rmem;
+   u32 da;
+
+   /* Register associated reserved memory regions */
+   of_phandle_iterator_init(, np, "memory-region", NULL, 0);
+   while (of_phandle_iterator_next() == 0) {
+   /*
+* Ignore the first memory region which will be used vdev 
buffer.
+* No need to do extra handlings, rproc_add_virtio_dev will 
handle it.
+*/
+   if (!strcmp(it.node->name, "vdevbuffer"))
+   continue;
+
+   rmem = of_reserved_mem_lookup(it.node);
+   if (!rmem) {
+   dev_err(priv->dev, "unable to acquire memory-region\n");
+   return -EINVAL;
+   }
+
+   /* No need to translate pa to da, i.MX use same map */
+   da = rmem->base;
+
+   /* Register memory region */
+   mem = rproc_mem_entry_init(priv->dev, NULL, 
(dma_addr_t)rmem->base, rmem->size, da,
+  imx_rproc_mem_alloc, 
imx_rproc_mem_release,
+  it.node->name);
+
+   if (mem)
+   rproc_coredump_add_segment(rproc, da, rmem->size);
+   else
+   return -ENOMEM;
+
+   rproc_add_carveout(rproc, mem);
+   }
+
+   return  0;
+}
+
+static int imx_rproc_parse_fw(struct rproc *rproc, const struct firmware *fw)
+{
+   int ret = imx_rproc_parse_memory_regions(rproc);
+
+   if (ret)
+   return ret;
+
+   ret = rproc_elf_load_rsc_table(rproc, fw);
+   if (ret)
+   dev_info(>dev, "No resource table in elf\n");
+
+   return 0;
+}
+
 static const struct rproc_ops imx_rproc_ops = {
.start  = imx_rproc_start,
.stop   = imx_rproc_stop,
.da_to_va   = imx_rproc_da_to_va,
+   .load   = rproc_elf_load_segments,
+   .parse_fw   = imx_rproc_parse_fw,
+   .find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
+   .sanity_check   = rproc_elf_sanity_check,
+   .get_boot_addr  = rproc_elf_get_boot_addr,
 };
 
 static int imx_rproc_addr_init(struct imx_rproc *priv,
-- 
2.28.0

[PATCH V3 6/7] remoteproc: imx_rproc: support i.MX8MQ/M

[Peng Fan (OSS)]

From: Peng Fan 

Add i.MX8MQ dev/sys addr map and configuration data structure
i.MX8MM share i.MX8MQ settings.

Reviewed-by: Richard Zhu 
Signed-off-by: Peng Fan 
Reviewed-by: Mathieu Poirier 
---
 drivers/remoteproc/imx_rproc.c | 40 ++
 1 file changed, 40 insertions(+)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index de44b7d6ae63..afa650610996 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -90,6 +90,34 @@ struct imx_rproc {
struct clk  *clk;
 };
 
+static const struct imx_rproc_att imx_rproc_att_imx8mq[] = {
+   /* dev addr , sys addr  , size  , flags */
+   /* TCML - alias */
+   { 0x, 0x007e, 0x0002, 0 },
+   /* OCRAM_S */
+   { 0x0018, 0x0018, 0x8000, 0 },
+   /* OCRAM */
+   { 0x0090, 0x0090, 0x0002, 0 },
+   /* OCRAM */
+   { 0x0092, 0x0092, 0x0002, 0 },
+   /* QSPI Code - alias */
+   { 0x0800, 0x0800, 0x0800, 0 },
+   /* DDR (Code) - alias */
+   { 0x1000, 0x8000, 0x0FFE, 0 },
+   /* TCML */
+   { 0x1FFE, 0x007E, 0x0002, ATT_OWN },
+   /* TCMU */
+   { 0x2000, 0x0080, 0x0002, ATT_OWN },
+   /* OCRAM_S */
+   { 0x2018, 0x0018, 0x8000, ATT_OWN },
+   /* OCRAM */
+   { 0x2020, 0x0090, 0x0002, ATT_OWN },
+   /* OCRAM */
+   { 0x2022, 0x0092, 0x0002, ATT_OWN },
+   /* DDR (Data) */
+   { 0x4000, 0x4000, 0x8000, 0 },
+};
+
 static const struct imx_rproc_att imx_rproc_att_imx7d[] = {
/* dev addr , sys addr  , size  , flags */
/* OCRAM_S (M4 Boot code) - alias */
@@ -140,6 +168,16 @@ static const struct imx_rproc_att imx_rproc_att_imx6sx[] = 
{
{ 0x8000, 0x8000, 0x6000, 0 },
 };
 
+static const struct imx_rproc_dcfg imx_rproc_cfg_imx8mq = {
+   .src_reg= IMX7D_SRC_SCR,
+   .src_mask   = IMX7D_M4_RST_MASK,
+   .src_start  = IMX7D_M4_START,
+   .src_stop   = IMX7D_M4_STOP,
+   .att= imx_rproc_att_imx8mq,
+   .att_size   = ARRAY_SIZE(imx_rproc_att_imx8mq),
+   .elf_mem_hook   = true,
+};
+
 static const struct imx_rproc_dcfg imx_rproc_cfg_imx7d = {
.src_reg= IMX7D_SRC_SCR,
.src_mask   = IMX7D_M4_RST_MASK,
@@ -513,6 +551,8 @@ static int imx_rproc_remove(struct platform_device *pdev)
 static const struct of_device_id imx_rproc_of_match[] = {
{ .compatible = "fsl,imx7d-cm4", .data = _rproc_cfg_imx7d },
{ .compatible = "fsl,imx6sx-cm4", .data = _rproc_cfg_imx6sx },
+   { .compatible = "fsl,imx8mq-cm4", .data = _rproc_cfg_imx8mq },
+   { .compatible = "fsl,imx8mm-cm4", .data = _rproc_cfg_imx8mq },
{},
 };
 MODULE_DEVICE_TABLE(of, imx_rproc_of_match);
-- 
2.28.0

[PATCH V3 4/7] remoteproc: imx_rproc: use devm_ioremap

[Peng Fan (OSS)]

From: Peng Fan 

We might need to map an region multiple times, becaue the region might
be shared between remote processors, such i.MX8QM with dual M4 cores.
So use devm_ioremap, not devm_ioremap_resource.

Reviewed-by: Oleksij Rempel 
Reviewed-by: Richard Zhu 
Signed-off-by: Peng Fan 
---
 drivers/remoteproc/imx_rproc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index aa5fbd0c7768..15c7baa480d7 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -298,9 +298,10 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
if (b >= IMX7D_RPROC_MEM_MAX)
break;
 
-   priv->mem[b].cpu_addr = devm_ioremap_resource(>dev, );
+   /* Not use resource version, because we might share region */
+   priv->mem[b].cpu_addr = devm_ioremap(>dev, res.start, 
resource_size());
if (IS_ERR(priv->mem[b].cpu_addr)) {
-   dev_err(dev, "devm_ioremap_resource failed\n");
+   dev_err(dev, "devm_ioremap %pR failed\n", );
err = PTR_ERR(priv->mem[b].cpu_addr);
return err;
}
-- 
2.28.0

[PATCH V3 3/7] remoteproc: imx_rproc: correct err message

[Peng Fan (OSS)]

From: Peng Fan 

It is using devm_ioremap, so not devm_ioremap_resource. Correct
the error message and print out sa/size.

Acked-by: Richard Zhu 
Reviewed-by: Mathieu Poirier 
Signed-off-by: Peng Fan 
---
 drivers/remoteproc/imx_rproc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index d1abb253b499..aa5fbd0c7768 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -270,7 +270,7 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
priv->mem[b].cpu_addr = devm_ioremap(>dev,
 att->sa, att->size);
if (!priv->mem[b].cpu_addr) {
-   dev_err(dev, "devm_ioremap_resource failed\n");
+   dev_err(dev, "devm_ioremap failed\n");
return -ENOMEM;
}
priv->mem[b].sys_addr = att->sa;
-- 
2.28.0

[PATCH V3 1/7] remoteproc: elf: support platform specific memory hook

[Peng Fan (OSS)]

From: Peng Fan 

To arm64, "dc  zva, dst" is used in memset.
Per ARM DDI 0487A.j, chapter C5.3.8 DC ZVA, Data Cache Zero by VA,

"If the memory region being zeroed is any type of Device memory,
this instruction can give an alignment fault which is prioritized
in the same way as other alignment faults that are determined
by the memory type."

On i.MX platforms, when elf is loaded to onchip TCM area, the region
is ioremapped, so "dc zva, dst" will trigger abort. And ioremap_wc()
on i.MX not able to write correct data to TCM area.

So we need to use io helpers, and extend the elf loader to support
platform specific memory functions.

Acked-by: Richard Zhu 
Signed-off-by: Peng Fan 
Reviewed-by: Mathieu Poirier 
---
 drivers/remoteproc/remoteproc_elf_loader.c | 20 ++--
 include/linux/remoteproc.h |  4 
 2 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/remoteproc_elf_loader.c 
b/drivers/remoteproc/remoteproc_elf_loader.c
index df68d87752e4..6cb71fe47261 100644
--- a/drivers/remoteproc/remoteproc_elf_loader.c
+++ b/drivers/remoteproc/remoteproc_elf_loader.c
@@ -129,6 +129,22 @@ u64 rproc_elf_get_boot_addr(struct rproc *rproc, const 
struct firmware *fw)
 }
 EXPORT_SYMBOL(rproc_elf_get_boot_addr);
 
+static void rproc_elf_memcpy(struct rproc *rproc, void *dest, const void *src, 
size_t count)
+{
+   if (!rproc->ops->elf_memcpy)
+   memcpy(dest, src, count);
+
+   rproc->ops->elf_memcpy(rproc, dest, src, count);
+}
+
+static void rproc_elf_memset(struct rproc *rproc, void *s, int c, size_t count)
+{
+   if (!rproc->ops->elf_memset)
+   memset(s, c, count);
+
+   rproc->ops->elf_memset(rproc, s, c, count);
+}
+
 /**
  * rproc_elf_load_segments() - load firmware segments to memory
  * @rproc: remote processor which will be booted using these fw segments
@@ -214,7 +230,7 @@ int rproc_elf_load_segments(struct rproc *rproc, const 
struct firmware *fw)
 
/* put the segment where the remote processor expects it */
if (filesz)
-   memcpy(ptr, elf_data + offset, filesz);
+   rproc_elf_memcpy(rproc, ptr, elf_data + offset, filesz);
 
/*
 * Zero out remaining memory for this segment.
@@ -224,7 +240,7 @@ int rproc_elf_load_segments(struct rproc *rproc, const 
struct firmware *fw)
 * this.
 */
if (memsz > filesz)
-   memset(ptr + filesz, 0, memsz - filesz);
+   rproc_elf_memset(rproc, ptr + filesz, 0, memsz - 
filesz);
}
 
return ret;
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index e8ac041c64d9..06c52f88a3fd 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -373,6 +373,8 @@ enum rsc_handling_status {
  * expects to find it
  * @sanity_check:  sanity check the fw image
  * @get_boot_addr: get boot address to entry point specified in firmware
+ * @elf_memcpy:platform specific elf loader memcpy
+ * @elf_memset:platform specific elf loader memset
  * @panic: optional callback to react to system panic, core will delay
  * panic at least the returned number of milliseconds
  */
@@ -392,6 +394,8 @@ struct rproc_ops {
int (*load)(struct rproc *rproc, const struct firmware *fw);
int (*sanity_check)(struct rproc *rproc, const struct firmware *fw);
u64 (*get_boot_addr)(struct rproc *rproc, const struct firmware *fw);
+   void (*elf_memcpy)(struct rproc *rproc, void *dest, const void *src, 
size_t count);
+   void (*elf_memset)(struct rproc *rproc, void *s, int c, size_t count);
unsigned long (*panic)(struct rproc *rproc);
 };
 
-- 
2.28.0

[PATCH V3 2/7] remoteproc: imx_rproc: add elf memory hooks

[Peng Fan (OSS)]

From: Peng Fan 

Add elf memory hooks according to elf_mem_hook setting in the platform
configuration dcfg.

Acked-by: Richard Zhu 
Signed-off-by: Peng Fan 
---
 drivers/remoteproc/imx_rproc.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 8957ed271d20..d1abb253b499 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -76,6 +77,7 @@ struct imx_rproc_dcfg {
u32 src_stop;
const struct imx_rproc_att  *att;
size_t  att_size;
+   boolelf_mem_hook;
 };
 
 struct imx_rproc {
@@ -310,6 +312,16 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
return 0;
 }
 
+static void imx_rproc_memcpy(struct rproc *rproc, void *dest, const void *src, 
size_t count)
+{
+   memcpy_toio((void * __iomem)dest, src, count);
+}
+
+static void imx_rproc_memset(struct rproc *rproc, void *s, int c, size_t count)
+{
+   memset_io((void * __iomem)s, c, count);
+}
+
 static int imx_rproc_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -340,6 +352,11 @@ static int imx_rproc_probe(struct platform_device *pdev)
goto err_put_rproc;
}
 
+   if (dcfg->elf_mem_hook) {
+   rproc->ops->elf_memcpy = imx_rproc_memcpy;
+   rproc->ops->elf_memset = imx_rproc_memset;
+   }
+
priv = rproc->priv;
priv->rproc = rproc;
priv->regmap = regmap;
-- 
2.28.0

[PATCH V3 0/7] remoteproc: imx_rproc: support iMX8MQ/M

[Peng Fan (OSS)]

From: Peng Fan 

V3:
 Since I was quite busy in the past days, V3 is late
 Rebased on Linux-next
 Add R-b tags
 1/7: Add R-b tag of Mathieu, add comments
 4/7: Typo fix
 5/7: Add R-b tag of Mathieu, drop index Per Mathieu's comments
 6/7: Add R-b tag of Mathieu
 7/7: Add comment for vqid << 16, drop unneeded timeout settings of mailbox
  Use queue_work instead of schedule_delayed_work
  free mbox channels when remove

V2:
 Rebased on linux-next
 Dropped early boot feature to make patchset simple.
 Drop rsc-da
 
https://patchwork.kernel.org/project/linux-remoteproc/cover/20200927064131.24101-1-peng@nxp.com/

V1:
 https://patchwork.kernel.org/cover/11682461/

This patchset is to support i.MX8MQ/M coproc.
The early boot feature was dropped to make the patchset small in V2.

Since i.MX specific TCM memory requirement, add elf platform hook.
Several patches have got reviewed by Oleksij and Mathieu in v1.

Peng Fan (7):
  remoteproc: elf: support platform specific memory hook
  remoteproc: imx_rproc: add elf memory hooks
  remoteproc: imx_rproc: correct err message
  remoteproc: imx_rproc: use devm_ioremap
  remoteproc: imx_rproc: add i.MX specific parse fw hook
  remoteproc: imx_rproc: support i.MX8MQ/M
  remoteproc: imx_proc: enable virtio/mailbox

 drivers/remoteproc/imx_rproc.c | 290 -
 drivers/remoteproc/remoteproc_elf_loader.c |  20 +-
 include/linux/remoteproc.h |   4 +
 3 files changed, 306 insertions(+), 8 deletions(-)

-- 
2.28.0

Re: [f2fs-dev] [PATCH v6] f2fs: compress: support compress level

[Chao Yu]

On 2020/12/4 8:31, Gao Xiang wrote:

could make more sense), could you leave some CR numbers about these
algorithms on typical datasets (enwik9, silisia.tar or else.) with 16k
cluster size?


Just from a quick test with enwik9 on vm:

Original blocks:244382

lz4 lz4hc-9
compressed blocks   170647  163270
compress ratio  69.8%   66.8%
speed   16.4207 s, 60.9 MB/s26.7299 s, 37.4 MB/s

compress ratio = after / before

Thanks,

[PATCH 2/2] arm64: dts: allwinner: a100: Add CPU Operating Performance Points table

[Shuosheng Huang]

Add an Operating Performance Points table for the CPU cores to
enable Dynamic Voltage & Frequency Scaling on the A100.

Signed-off-by: Shuosheng Huang 
---
 .../allwinner/sun50i-a100-allwinner-perf1.dts |  5 ++
 .../dts/allwinner/sun50i-a100-cpu-opp.dtsi| 90 +++
 .../arm64/boot/dts/allwinner/sun50i-a100.dtsi |  8 ++
 3 files changed, 103 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a100-cpu-opp.dtsi

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
index d34c2bb1079f..7c579923f973 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a100-allwinner-perf1.dts
@@ -6,6 +6,7 @@
 /dts-v1/;
 
 #include "sun50i-a100.dtsi"
+#include "sun50i-a100-cpu-opp.dtsi"
 
 /{
model = "Allwinner A100 Perf1";
@@ -20,6 +21,10 @@ chosen {
};
 };
 
+ {
+   cpu-supply = <_dcdc2>;
+};
+
  {
vcc-pb-supply = <_dcdc1>;
vcc-pc-supply = <_eldo1>;
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100-cpu-opp.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a100-cpu-opp.dtsi
new file mode 100644
index ..bc8ceaa38392
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a100-cpu-opp.dtsi
@@ -0,0 +1,90 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+// Copyright (c) 2020 Yangtao Li 
+// Copyright (c) 2020 ShuoSheng Huang 
+
+/ {
+   cpu_opp_table: cpu-opp-table {
+   compatible = "allwinner,sun50i-h6-operating-points";
+   nvmem-cells = <_speed_grade>;
+   opp-shared;
+
+   opp@40800 {
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   opp-hz = /bits/ 64 <40800>;
+
+   opp-microvolt-speed0 = <90 90 120>;
+   opp-microvolt-speed0 = <90 90 120>;
+   opp-microvolt-speed0 = <90 90 120>;
+   };
+
+   opp@6 {
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   opp-hz = /bits/ 64 <6>;
+
+   opp-microvolt-speed0 = <90 90 120>;
+   opp-microvolt-speed0 = <90 90 120>;
+   opp-microvolt-speed0 = <90 90 120>;
+   };
+
+   opp@81600 {
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   opp-hz = /bits/ 64 <81600>;
+
+   opp-microvolt-speed0 = <94 94 120>;
+   opp-microvolt-speed0 = <90 90 120>;
+   opp-microvolt-speed0 = <90 90 120>;
+   };
+
+   opp@108000 {
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   opp-hz = /bits/ 64 <108000>;
+
+   opp-microvolt-speed0 = <102 102 120>;
+   opp-microvolt-speed1 = <98 98 120>;
+   opp-microvolt-speed2 = <95 95 120>;
+   };
+
+   opp@12 {
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   opp-hz = /bits/ 64 <12>;
+
+   opp-microvolt-speed0 = <110 110 120>;
+   opp-microvolt-speed1 = <102 102 120>;
+   opp-microvolt-speed2 = <100 100 120>;
+   };
+
+   opp@132000 {
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   opp-hz = /bits/ 64 <132000>;
+
+   opp-microvolt-speed0 = <116 116 120>;
+   opp-microvolt-speed0 = <106 106 120>;
+   opp-microvolt-speed0 = <103 103 120>;
+   };
+
+   opp@146400 {
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   opp-hz = /bits/ 64 <146400>;
+
+   opp-microvolt-speed0 = <118 118 120>;
+   opp-microvolt-speed0 = <118 118 120>;
+   opp-microvolt-speed0 = <113 113 120>;
+   };
+   };
+};
+
+ {
+   operating-points-v2 = <_opp_table>;
+};
+
+ {
+   operating-points-v2 = <_opp_table>;
+};
+
+ {
+   operating-points-v2 = <_opp_table>;
+};
+
+ {
+   operating-points-v2 = <_opp_table>;
+};
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
index cc321c04f121..8f370a175ce6 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a100.dtsi
@@ -23,6 +23,7 @@ cpu0: cpu@0 {

[PATCH 1/2] cpufreq: sun50i: add a100 cpufreq support

[Shuosheng Huang]

Let's add cpufreq nvmem based for allwinner a100 soc. It's similar to h6,
let us use efuse_xlate to extract the differentiated part.

Signed-off-by: Shuosheng Huang 
---
 drivers/cpufreq/cpufreq-dt-platdev.c   |  1 +
 drivers/cpufreq/sun50i-cpufreq-nvmem.c | 81 --
 2 files changed, 64 insertions(+), 18 deletions(-)

diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c 
b/drivers/cpufreq/cpufreq-dt-platdev.c
index 3776d960f405..2ebf5d9cb616 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -102,6 +102,7 @@ static const struct of_device_id whitelist[] __initconst = {
  */
 static const struct of_device_id blacklist[] __initconst = {
{ .compatible = "allwinner,sun50i-h6", },
+   { .compatible = "allwinner,sun50i-a100", },
 
{ .compatible = "calxeda,highbank", },
{ .compatible = "calxeda,ecx-2000", },
diff --git a/drivers/cpufreq/sun50i-cpufreq-nvmem.c 
b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
index 9907a165135b..044e44a763f5 100644
--- a/drivers/cpufreq/sun50i-cpufreq-nvmem.c
+++ b/drivers/cpufreq/sun50i-cpufreq-nvmem.c
@@ -21,21 +21,63 @@
 
 #define NVMEM_MASK 0x7
 #define NVMEM_SHIFT5
+#define SUN50I_A100_NVMEM_MASK 0xf
+#define SUN50I_A100_NVMEM_SHIFT12
+
+#define SUN50I_H6_NVMEM_MASK   0x7
+#define SUN50I_H6_NVMEM_SHIFT  5
+
+struct sunxi_cpufreq_soc_data {
+   u32 (*efuse_xlate)(void *efuse);
+};
 
 static struct platform_device *cpufreq_dt_pdev, *sun50i_cpufreq_pdev;
 
+static u32 sun50i_a100_efuse_xlate(void *efuse)
+{
+   u32 efuse_value = (*(u16 *)efuse >> SUN50I_A100_NVMEM_SHIFT) &
+ SUN50I_A100_NVMEM_MASK;
+
+   switch (efuse_value) {
+   case 0b100:
+   return 2;
+   case 0b010:
+   return 1;
+   default:
+   return 0;
+   }
+}
+
+static u32 sun50i_h6_efuse_xlate(void *efuse)
+{
+   u32 efuse_value = (*(u32 *)efuse >> SUN50I_H6_NVMEM_SHIFT) &
+ SUN50I_H6_NVMEM_MASK;
+
+   /*
+* We treat unexpected efuse values as if the SoC was from
+* the slowest bin. Expected efuse values are 1-3, slowest
+* to fastest.
+*/
+   if (efuse_value >= 1 && efuse_value <= 3)
+   return efuse_value - 1;
+   else
+   return 0;
+}
+
 /**
  * sun50i_cpufreq_get_efuse() - Determine speed grade from efuse value
+ * @soc_data: pointer to sunxi_cpufreq_soc_data context
  * @versions: Set to the value parsed from efuse
  *
  * Returns 0 if success.
  */
-static int sun50i_cpufreq_get_efuse(u32 *versions)
+static int sun50i_cpufreq_get_efuse(const struct sunxi_cpufreq_soc_data 
*soc_data,
+   u32 *versions)
 {
struct nvmem_cell *speedbin_nvmem;
struct device_node *np;
struct device *cpu_dev;
-   u32 *speedbin, efuse_value;
+   u32 *speedbin;
size_t len;
int ret;
 
@@ -68,17 +110,7 @@ static int sun50i_cpufreq_get_efuse(u32 *versions)
if (IS_ERR(speedbin))
return PTR_ERR(speedbin);
 
-   efuse_value = (*speedbin >> NVMEM_SHIFT) & NVMEM_MASK;
-
-   /*
-* We treat unexpected efuse values as if the SoC was from
-* the slowest bin. Expected efuse values are 1-3, slowest
-* to fastest.
-*/
-   if (efuse_value >= 1 && efuse_value <= 3)
-   *versions = efuse_value - 1;
-   else
-   *versions = 0;
+   *versions = soc_data->efuse_xlate(speedbin);
 
kfree(speedbin);
return 0;
@@ -86,18 +118,23 @@ static int sun50i_cpufreq_get_efuse(u32 *versions)
 
 static int sun50i_cpufreq_nvmem_probe(struct platform_device *pdev)
 {
+   const struct of_device_id *match;
struct opp_table **opp_tables;
char name[MAX_NAME_LEN];
unsigned int cpu;
u32 speed = 0;
int ret;
 
+   match = dev_get_platdata(>dev);
+   if (!match)
+   return -EINVAL;
+
opp_tables = kcalloc(num_possible_cpus(), sizeof(*opp_tables),
 GFP_KERNEL);
if (!opp_tables)
return -ENOMEM;
 
-   ret = sun50i_cpufreq_get_efuse();
+   ret = sun50i_cpufreq_get_efuse(match->data, );
if (ret)
return ret;
 
@@ -163,8 +200,17 @@ static struct platform_driver sun50i_cpufreq_driver = {
},
 };
 
+static const struct sunxi_cpufreq_soc_data sun50i_a100_data = {
+   .efuse_xlate = sun50i_a100_efuse_xlate,
+};
+
+static const struct sunxi_cpufreq_soc_data sun50i_h6_data = {
+   .efuse_xlate = sun50i_h6_efuse_xlate,
+};
+
 static const struct of_device_id sun50i_cpufreq_match_list[] = {
-   { .compatible = "allwinner,sun50i-h6" },
+   { .compatible = "allwinner,sun50i-h6", .data = _h6_data },
+   { .compatible = "allwinner,sun50i-a100", .data = _a100_data },
{}
 };
 
@@ -198,9 +244,8 @@ static int __init 

Re: [PATCH bpf-next v3 13/14] bpf: Add tests for new BPF atomic operations

[Yonghong Song]

On 12/3/20 8:02 AM, Brendan Jackman wrote:

This relies on the work done by Yonghong Song in
https://reviews.llvm.org/D72184

Note the use of a define called ENABLE_ATOMICS_TESTS: this is used
to:

  - Avoid breaking the build for people on old versions of Clang
  - Avoid needing separate lists of test objects for no_alu32, where
atomics are not supported even if Clang has the feature.

The atomics_test.o BPF object is built unconditionally both for
test_progs and test_progs-no_alu32. For test_progs, if Clang supports
atomics, ENABLE_ATOMICS_TESTS is defined, so it includes the proper
test code. Otherwise, progs and global vars are defined anyway, as
stubs; this means that the skeleton user code still builds.

The atomics_test.o userspace object is built once and used for both
test_progs and test_progs-no_alu32. A variable called skip_tests is
defined in the BPF object's data section, which tells the userspace
object whether to skip the atomics test.

Change-Id: Iecc12f35f0ded4a1dd805cce1be576e7b27917ef
Signed-off-by: Brendan Jackman 
---
  tools/testing/selftests/bpf/Makefile  |   4 +
  .../selftests/bpf/prog_tests/atomics_test.c   | 262 ++
  .../selftests/bpf/progs/atomics_test.c| 154 ++
  .../selftests/bpf/verifier/atomic_and.c   |  77 +
  .../selftests/bpf/verifier/atomic_cmpxchg.c   |  96 +++
  .../selftests/bpf/verifier/atomic_fetch_add.c | 106 +++
  .../selftests/bpf/verifier/atomic_or.c|  77 +
  .../selftests/bpf/verifier/atomic_xchg.c  |  46 +++
  .../selftests/bpf/verifier/atomic_xor.c   |  77 +
  9 files changed, 899 insertions(+)
  create mode 100644 tools/testing/selftests/bpf/prog_tests/atomics_test.c
  create mode 100644 tools/testing/selftests/bpf/progs/atomics_test.c
  create mode 100644 tools/testing/selftests/bpf/verifier/atomic_and.c
  create mode 100644 tools/testing/selftests/bpf/verifier/atomic_cmpxchg.c
  create mode 100644 tools/testing/selftests/bpf/verifier/atomic_fetch_add.c
  create mode 100644 tools/testing/selftests/bpf/verifier/atomic_or.c
  create mode 100644 tools/testing/selftests/bpf/verifier/atomic_xchg.c
  create mode 100644 tools/testing/selftests/bpf/verifier/atomic_xor.c

diff --git a/tools/testing/selftests/bpf/Makefile 
b/tools/testing/selftests/bpf/Makefile
index f21c4841a612..448a9eb1a56c 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -431,11 +431,15 @@ TRUNNER_EXTRA_FILES := $(OUTPUT)/urandom_read 
\
   $(wildcard progs/btf_dump_test_case_*.c)
  TRUNNER_BPF_BUILD_RULE := CLANG_BPF_BUILD_RULE
  TRUNNER_BPF_CFLAGS := $(BPF_CFLAGS) $(CLANG_CFLAGS)
+ifeq ($(feature-clang-bpf-atomics),1)
+  TRUNNER_BPF_CFLAGS += -DENABLE_ATOMICS_TESTS
+endif
  TRUNNER_BPF_LDFLAGS := -mattr=+alu32
  $(eval $(call DEFINE_TEST_RUNNER,test_progs))
  
  # Define test_progs-no_alu32 test runner.

  TRUNNER_BPF_BUILD_RULE := CLANG_NOALU32_BPF_BUILD_RULE
+TRUNNER_BPF_CFLAGS := $(BPF_CFLAGS) $(CLANG_CFLAGS)
  TRUNNER_BPF_LDFLAGS :=
  $(eval $(call DEFINE_TEST_RUNNER,test_progs,no_alu32))
  
diff --git a/tools/testing/selftests/bpf/prog_tests/atomics_test.c b/tools/testing/selftests/bpf/prog_tests/atomics_test.c

new file mode 100644
index ..66f0ccf4f4ec
--- /dev/null
+++ b/tools/testing/selftests/bpf/prog_tests/atomics_test.c
@@ -0,0 +1,262 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include 
+
+
+#include "atomics_test.skel.h"
+
+static struct atomics_test *setup(void)
+{
+   struct atomics_test *atomics_skel;
+   __u32 duration = 0, err;
+
+   atomics_skel = atomics_test__open_and_load();
+   if (CHECK(!atomics_skel, "atomics_skel_load", "atomics skeleton 
failed\n"))
+   return NULL;
+
+   if (atomics_skel->data->skip_tests) {
+   printf("%s:SKIP:no ENABLE_ATOMICS_TEST (missing Clang BPF atomics 
support)",
+  __func__);
+   test__skip();
+   goto err;
+   }
+
+   err = atomics_test__attach(atomics_skel);
+   if (CHECK(err, "atomics_attach", "atomics attach failed: %d\n", err))
+   goto err;
+
+   return atomics_skel;
+
+err:
+   atomics_test__destroy(atomics_skel);
+   return NULL;
+}
+
+static void test_add(void)
+{
+   struct atomics_test *atomics_skel;
+   int err, prog_fd;
+   __u32 duration = 0, retval;
+
+   atomics_skel = setup();


When running the test, I observed a noticeable delay between skel load 
and skel attach. The reason is the bpf program object file contains

multiple programs and the above setup() tries to do attachment
for ALL programs but actually below only "add" program is tested.
This will unnecessarily increase test_progs running time.

The best is for setup() here only load and attach program "add".
The libbpf API bpf_program__set_autoload() can set a particular
program not autoload. You can call attach function explicitly
for 

Re: [RFC v2 1/2] [NEEDS HELP] x86/mm: Handle unlazying membarrier core sync in the arch code

[Nicholas Piggin]

Excerpts from Andy Lutomirski's message of December 4, 2020 3:26 pm:
> The core scheduler isn't a great place for
> membarrier_mm_sync_core_before_usermode() -- the core scheduler doesn't
> actually know whether we are lazy.  With the old code, if a CPU is
> running a membarrier-registered task, goes idle, gets unlazied via a TLB
> shootdown IPI, and switches back to the membarrier-registered task, it
> will do an unnecessary core sync.
> 
> Conveniently, x86 is the only architecture that does anything in this
> hook, so we can just move the code.

This should go on top of my series that adds the exit_lazy_mm call
and switches x86 over, at least.

> XXX: there are some comments in swich_mm_irqs_off() that seem to be
> trying to document what barriers are expected, and it's not clear to me
> that these barriers are actually present in all paths through the
> code.  So I think this change makes the code more comprehensible and
> has no effect on the code's correctness, but I'm not at all convinced
> that the code is correct.
> 
> Signed-off-by: Andy Lutomirski 
> ---
>  arch/x86/mm/tlb.c   | 17 -
>  kernel/sched/core.c | 14 +++---
>  2 files changed, 23 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
> index 3338a1feccf9..23df035b80e8 100644
> --- a/arch/x86/mm/tlb.c
> +++ b/arch/x86/mm/tlb.c
> @@ -8,6 +8,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -496,6 +497,8 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct 
> mm_struct *next,
>* from one thread in a process to another thread in the same
>* process. No TLB flush required.
>*/
> +
> + // XXX: why is this okay wrt membarrier?
>   if (!was_lazy)
>   return;
>  
> @@ -508,12 +511,24 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct 
> mm_struct *next,
>   smp_mb();
>   next_tlb_gen = atomic64_read(>context.tlb_gen);
>   if (this_cpu_read(cpu_tlbstate.ctxs[prev_asid].tlb_gen) ==
> - next_tlb_gen)
> + next_tlb_gen) {
> + /*
> +  * We're reactivating an mm, and membarrier might
> +  * need to serialize.  Tell membarrier.
> +  */
> +
> + // XXX: I can't understand the logic in
> + // membarrier_mm_sync_core_before_usermode().  What's
> + // the mm check for?

Writing CR3 is serializing, apparently. Another x86ism that gets 
commented and moved into arch/x86 with my patch.


> + membarrier_mm_sync_core_before_usermode(next);
>   return;
> + }
>  
>   /*
>* TLB contents went out of date while we were in lazy
>* mode. Fall through to the TLB switching code below.
> +  * No need for an explicit membarrier invocation -- the CR3
> +  * write will serialize.
>*/
>   new_asid = prev_asid;
>   need_flush = true;
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 2d95dc3f4644..6c4b76147166 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -3619,22 +3619,22 @@ static struct rq *finish_task_switch(struct 
> task_struct *prev)
>   kcov_finish_switch(current);
>  
>   fire_sched_in_preempt_notifiers(current);
> +
>   /*
>* When switching through a kernel thread, the loop in
>* membarrier_{private,global}_expedited() may have observed that
>* kernel thread and not issued an IPI. It is therefore possible to
>* schedule between user->kernel->user threads without passing though
>* switch_mm(). Membarrier requires a barrier after storing to
> -  * rq->curr, before returning to userspace, so provide them here:
> +  * rq->curr, before returning to userspace, and mmdrop() provides
> +  * this barrier.
>*
> -  * - a full memory barrier for {PRIVATE,GLOBAL}_EXPEDITED, implicitly
> -  *   provided by mmdrop(),
> -  * - a sync_core for SYNC_CORE.
> +  * XXX: I don't think mmdrop() actually does this.  There's no
> +  * smp_mb__before/after_atomic() in there.

mmdrop definitely does provide a full barrier.

>*/
> - if (mm) {
> - membarrier_mm_sync_core_before_usermode(mm);
> + if (mm)
>   mmdrop(mm);
> - }
> +
>   if (unlikely(prev_state == TASK_DEAD)) {
>   if (prev->sched_class->task_dead)
>   prev->sched_class->task_dead(prev);
> -- 
> 2.28.0
> 
> 

Re: [PATCH 0/5] crypto: hisilicon - add some new algorithms

[Herbert Xu]

On Thu, Nov 26, 2020 at 10:18:01AM +0800, Longfang Liu wrote:
> As the new Kunpeng930 supports some new algorithms,
> the driver needs to be updated
> 
> Longfang Liu (4):
>   crypto: hisilicon/sec - add new type of sqe for Kunpeng930
>   crypto: hisilicon/sec - add new skcipher mode for SEC
>   crypto: hisilicon/sec - add new AEAD mode for SEC
>   crypto: hisilicon/sec - fixes some coding style
> 
> Meng Yu (1):
>   crypto: hisilicon/hpre - add version adapt to new algorithms

Please include details on whether this has been tested with the
self-tests, including the extra fuzz tests.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v2 2/2] clocksource: arm_arch_timer: Correct fault programming of CNTKCTL_EL1.EVNTI

[zhukeqian]

Hi Marc,

On 2020/12/3 22:57, Marc Zyngier wrote:
> On 2020-08-18 04:28, Keqian Zhu wrote:
>> ARM virtual counter supports event stream, it can only trigger an event
>> when the trigger bit (the value of CNTKCTL_EL1.EVNTI) of CNTVCT_EL0 changes,
>> so the actual period of event stream is 2^(cntkctl_evnti + 1). For example,
>> when the trigger bit is 0, then virtual counter trigger an event for every
>> two cycles.
>>
>> Fixes: 037f637767a8 ("drivers: clocksource: add support for
>>ARM architected timer event stream")
> 
> Fixes: tags should on a single line.
Will do.

> 
>> Suggested-by: Marc Zyngier 
>> Signed-off-by: Keqian Zhu 
>> ---
>>  drivers/clocksource/arm_arch_timer.c | 10 +++---
>>  1 file changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/clocksource/arm_arch_timer.c
>> b/drivers/clocksource/arm_arch_timer.c
>> index 777d38c..e3b2ee0 100644
>> --- a/drivers/clocksource/arm_arch_timer.c
>> +++ b/drivers/clocksource/arm_arch_timer.c
>> @@ -824,10 +824,14 @@ static void arch_timer_configure_evtstream(void)
>>  {
>>  int evt_stream_div, pos;
>>
>> -/* Find the closest power of two to the divisor */
>> -evt_stream_div = arch_timer_rate / ARCH_TIMER_EVT_STREAM_FREQ;
>> +/*
>> + * Find the closest power of two to the divisor. As the event
>> + * stream can at most be generated at half the frequency of the
>> + * counter, use half the frequency when computing the divider.
>> + */
>> +evt_stream_div = arch_timer_rate / ARCH_TIMER_EVT_STREAM_FREQ / 2;
>>  pos = fls(evt_stream_div);
>> -if (pos > 1 && !(evt_stream_div & (1 << (pos - 2
>> +if ((pos == 1) || (pos > 1 && !(evt_stream_div & (1 << (pos - 2)
>>  pos--;
> 
> You don't explain why you are special-casing pos == 1.
The logic is not clear here, I will try to reform it.

> 
>>  /* enable event stream */
>>  arch_timer_evtstrm_enable(min(pos, 15));
> 
> Also, please Cc the subsystem maintainers:
> 
> CLOCKSOURCE, CLOCKEVENT DRIVERS
> M:  Daniel Lezcano 
> M:  Thomas Gleixner 
> L:  linux-kernel@vger.kernel.org
> S:  Supported
> T:  git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> timers/core
> F:  Documentation/devicetree/bindings/timer/
> F:  drivers/clocksource/
> 
Will do.

> Thanks,
> 
> M.

Thanks,
Keqian

Re: [PATCH 2/5] crypto: hisilicon/sec - add new type of sqe for Kunpeng930

[Herbert Xu]

On Thu, Nov 26, 2020 at 10:18:03AM +0800, Longfang Liu wrote:
>
> diff --git a/drivers/crypto/hisilicon/sec2/sec_crypto.h 
> b/drivers/crypto/hisilicon/sec2/sec_crypto.h
> index 0e933e7..712176b 100644
> --- a/drivers/crypto/hisilicon/sec2/sec_crypto.h
> +++ b/drivers/crypto/hisilicon/sec2/sec_crypto.h
> @@ -211,6 +219,167 @@ struct sec_sqe {
>   struct sec_sqe_type2 type2;
>  };
>  
> +#pragma pack(4)

Please don't use pragma pack.  Instead add the attributes as
needed to each struct or member.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[PATCH] (fixed after review) Documentation: fix typos found in admin-guide subdirectory

[Andrew Klychkov]

Fixed twelve typos in cppc_sysfs.rst, binderfs.rst, paride.rst,
zram.rst, bug-hunting.rst, introduction.rst, usage.rst, dm-crypt.rst

Reviewed-by: Jonathan Corbet 
Reviewed-by: Randy Dunlap 
Signed-off-by: Andrew Klychkov 
---
 Documentation/admin-guide/acpi/cppc_sysfs.rst| 4 ++--
 Documentation/admin-guide/binderfs.rst   | 2 +-
 Documentation/admin-guide/blockdev/paride.rst| 2 +-
 Documentation/admin-guide/blockdev/zram.rst  | 2 +-
 Documentation/admin-guide/bug-hunting.rst| 2 +-
 Documentation/admin-guide/cifs/introduction.rst  | 2 +-
 Documentation/admin-guide/cifs/usage.rst | 6 +++---
 Documentation/admin-guide/device-mapper/dm-crypt.rst | 4 ++--
 8 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/Documentation/admin-guide/acpi/cppc_sysfs.rst 
b/Documentation/admin-guide/acpi/cppc_sysfs.rst
index a4b99af..fccf221 100644
--- a/Documentation/admin-guide/acpi/cppc_sysfs.rst
+++ b/Documentation/admin-guide/acpi/cppc_sysfs.rst
@@ -8,7 +8,7 @@ CPPC
 
 
 CPPC defined in the ACPI spec describes a mechanism for the OS to manage the
-performance of a logical processor on a contigious and abstract performance
+performance of a logical processor on a contiguous and abstract performance
 scale. CPPC exposes a set of registers to describe abstract performance scale,
 to request performance levels and to measure per-cpu delivered performance.
 
@@ -45,7 +45,7 @@ for each cpu X::
 * lowest_freq : CPU frequency corresponding to lowest_perf (in MHz).
 * nominal_freq : CPU frequency corresponding to nominal_perf (in MHz).
   The above frequencies should only be used to report processor performance in
-  freqency instead of abstract scale. These values should not be used for any
+  frequency instead of abstract scale. These values should not be used for any
   functional decisions.
 
 * feedback_ctrs : Includes both Reference and delivered performance counter.
diff --git a/Documentation/admin-guide/binderfs.rst 
b/Documentation/admin-guide/binderfs.rst
index 8243af9..199d843 100644
--- a/Documentation/admin-guide/binderfs.rst
+++ b/Documentation/admin-guide/binderfs.rst
@@ -70,5 +70,5 @@ Deleting binder Devices
 Binderfs binder devices can be deleted via `unlink() `_.  This means
 that the `rm() `_ tool can be used to delete them. Note that the
 ``binder-control`` device cannot be deleted since this would make the binderfs
-instance unuseable.  The ``binder-control`` device will be deleted when the
+instance unusable.  The ``binder-control`` device will be deleted when the
 binderfs instance is unmounted and all references to it have been dropped.
diff --git a/Documentation/admin-guide/blockdev/paride.rst 
b/Documentation/admin-guide/blockdev/paride.rst
index 87b4278..e1ce90a 100644
--- a/Documentation/admin-guide/blockdev/paride.rst
+++ b/Documentation/admin-guide/blockdev/paride.rst
@@ -220,7 +220,7 @@ example::
 Finally, you can load high-level drivers for each kind of device that
 you have connected.  By default, each driver will autoprobe for a single
 device, but you can support up to four similar devices by giving their
-individual co-ordinates when you load the driver.
+individual coordinates when you load the driver.
 
 For example, if you had two no-name CD-ROM drives both using the
 KingByte KBIC-951A adapter, one on port 0x378 and the other on 0x3bc
diff --git a/Documentation/admin-guide/blockdev/zram.rst 
b/Documentation/admin-guide/blockdev/zram.rst
index a6fd1f9..9093228 100644
--- a/Documentation/admin-guide/blockdev/zram.rst
+++ b/Documentation/admin-guide/blockdev/zram.rst
@@ -360,7 +360,7 @@ like below::
/sys/block/zram0/writeback_limit.
$ echo 1 > /sys/block/zram0/writeback_limit_enable
 
-If admins want to allow further write again once the bugdet is exhausted,
+If admins want to allow further write again once the budget is exhausted,
 he could do it like below::
 
$ echo $((400<>4K_SHIFT)) > \
diff --git a/Documentation/admin-guide/bug-hunting.rst 
b/Documentation/admin-guide/bug-hunting.rst
index f7c80f4..95299b0 100644
--- a/Documentation/admin-guide/bug-hunting.rst
+++ b/Documentation/admin-guide/bug-hunting.rst
@@ -263,7 +263,7 @@ Please notice that it will point to:
 
 - The last developers that touched the source code (if this is done inside
   a git tree). On the above example, Tejun and Bhaktipriya (in this
-  specific case, none really envolved on the development of this file);
+  specific case, none really involved on the development of this file);
 - The driver maintainer (Hans Verkuil);
 - The subsystem maintainer (Mauro Carvalho Chehab);
 - The driver and/or subsystem mailing list (linux-me...@vger.kernel.org);
diff --git a/Documentation/admin-guide/cifs/introduction.rst 
b/Documentation/admin-guide/cifs/introduction.rst
index 0b98f67..cc2851d 100644
--- a/Documentation/admin-guide/cifs/introduction.rst
+++ b/Documentation/admin-guide/cifs/introduction.rst
@@ -9,7 +9,7 @@ 

Re: [f2fs-dev] [PATCH] f2fs: fix race of pending_pages in decompression

[Daeho Jeong]

Thanks for the explanation about verity.
I got your point. Thanks~

2020년 12월 4일 (금) 오후 2:18, Eric Biggers 님이 작성:
>
> On Fri, Dec 04, 2020 at 02:00:34PM +0900, Daeho Jeong wrote:
> > I think I don't understand how verity works.
> > Right after verity is enabled on a file, is the verity logic working
> > for the whole file data area?
> > Or it's just working for the data area which is updated after verity is 
> > enabled?
> >
>
> It's for the whole file.
>
> My point is just that if there is a bio that saw that verity isn't enabled yet
> when it started and therefore STEP_VERITY didn't get set in the
> bio_post_read_ctx (or the bio_post_read_ctx didn't get allocated due to one 
> not
> being needed), then the filesystem shouldn't change its mind and try to verify
> the pages when the bio completes if verity happened to be enabled 
> concurrently.
> It's too late for that bio.
>
> - Eric

Re: [PATCH 0/5] tty: add flag to suppress ready signalling on open

[Jiri Slaby]

On 02. 12. 20, 12:48, Johan Hovold wrote:

but I question the
usefulness of doing so, as it is a chicken and egg problem: one needs
to open the tty device in order to do termios ioctls on it, and if
that initial open triggers DTR/RTS hardware actions, then the end user
is still screwed.  If Johan or someone else can see a potential use
case for manipulating this new flag via termios (as opposed to sysfs
or USB-ID-based driver quirks), perhaps you could elaborate on it?


We would need to (ab)use another open flag (e.g. O_DIRECT). I am not
biased to either of solutions.


Forgot to mention that using open-flags would prevent using standard
utilities like cat, echo and terminal programs. So for that reason a
termios and/or sysfs interface is also preferred.


Nope, I meant it differently. You set it up once using the special open 
flag. Like with setserial, one sets I/O port, irqs etc. and then uses 
standard tools as the port is already set up (marked as NORDY in this case).


thanks,
--
js

Re: [PATCH] implements ecdsa 256, 384 and 521 alghorithm in akcipher model; change pcks7 and x509 to load certificates with ecdsa; increment testmgr to test ecdsa algo and finally allows signature and

[Herbert Xu]

On Wed, Nov 25, 2020 at 11:03:08PM -0300, Saulo Alessandre wrote:
> From: Saulo Alessandre 
> 
> Signed-off-by: Saulo Alessandre 
> ---
>  Documentation/admin-guide/module-signing.rst |  10 +
>  crypto/Kconfig   |  12 +
>  crypto/Makefile  |   7 +
>  crypto/asymmetric_keys/pkcs7_parser.c|   7 +-
>  crypto/asymmetric_keys/pkcs7_verify.c|   5 +-
>  crypto/asymmetric_keys/public_key.c  |  30 +-
>  crypto/asymmetric_keys/x509_cert_parser.c|  30 +-
>  crypto/ecc.c | 228 -
>  crypto/ecc.h |  62 ++-
>  crypto/ecc_curve_defs.h  |  82 +++
>  crypto/ecdsa.c   | 508 +++
>  crypto/ecdsa_params.asn1 |   1 +
>  crypto/ecdsa_signature.asn1  |   6 +
>  crypto/testmgr.c |  17 +-
>  crypto/testmgr.h |  78 +++
>  include/crypto/ecdh.h|   2 +
>  include/linux/oid_registry.h |  12 +
>  lib/oid_registry.c   | 108 +++-
>  18 files changed, 1146 insertions(+), 59 deletions(-)
>  create mode 100644 crypto/ecdsa.c
>  create mode 100644 crypto/ecdsa_params.asn1
>  create mode 100644 crypto/ecdsa_signature.asn1

Please split your patch up.  You should also explain in detail
why this patch is needed in the kernel.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [RFC PATCH] usb: hcd: complete URBs in threaded-IRQ context instead of tasklet

[Davidlohr Bueso]

On Mon, 16 Apr 2018, Sebastian Andrzej Siewior wrote:


On 2018-03-08 10:57:39 [+0100], To Mauro Carvalho Chehab wrote:

On 2018-02-27 14:39:34 [-0300], Mauro Carvalho Chehab wrote:
> Hi Sebastian,
Hi Mauro,

> Sorry for taking some time to test it, has been busy those days...
:)

> Anyway, I tested it today. Didn't work. It keep losing data.

Okay, this was unexpected. What I learned from the thread is that you
use the dwc2 controller and once upgrade to a kernel which completes the
URBs in BH context then you starting losing data from your DVB-s USB
device. And it was assumed that this is because BH/ksoftirq is getting
"paused" if it is running for too long. If that is the case then a
revert of "let us complete the URB in BH context" should get it working
again. Is that so?


ping


I ran into this while looking at getting rid of tasklets in drivers/usb.

Mauro, were you ever able to try reverting 8add17cf8e4 like Sebastian suggested?
If not would you mind trying the below, please? Considering this thread is from
over two years ago, it's a rebase of Sebastian's patch to complete urbs in 
process
context + the dwc2 changes not to use defer urb into bh.

Thanks,
Davidlohr

8<---
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 60886a7464c3..4952a8fc1719 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1665,33 +1665,76 @@ static void __usb_hcd_giveback_urb(struct urb *urb)
usb_put_urb(urb);
}

-static void usb_giveback_urb_bh(struct tasklet_struct *t)
+static void usb_hcd_rh_gb_urb(struct work_struct *work)
{
-   struct giveback_urb_bh *bh = from_tasklet(bh, t, bh);
-   struct list_head local_list;
+   struct giveback_urb *bh;
+   struct list_head urb_list;
+
+   bh = container_of(work, struct giveback_urb, rh_compl);

spin_lock_irq(>lock);
-   bh->running = true;
- restart:
-   list_replace_init(>head, _list);
+   list_replace_init(>rh_head, _list);
spin_unlock_irq(>lock);

-   while (!list_empty(_list)) {
+   while (!list_empty(_list)) {
struct urb *urb;

-   urb = list_entry(local_list.next, struct urb, urb_list);
+   urb = list_first_entry(_list, struct urb, urb_list);
list_del_init(>urb_list);
-   bh->completing_ep = urb->ep;
__usb_hcd_giveback_urb(urb);
-   bh->completing_ep = NULL;
+   }
+}
+
+#define URB_PRIO_HIGH  0
+#define URB_PRIO_LOW   1
+
+static irqreturn_t usb_hcd_gb_urb(int irq, void *__hcd)
+{
+   struct usb_hcd *hcd = __hcd;
+   struct giveback_urb *bh = >gb_urb;
+   struct list_head urb_list[2];
+   int i;
+
+   INIT_LIST_HEAD(_list[URB_PRIO_HIGH]);
+   INIT_LIST_HEAD(_list[URB_PRIO_LOW]);
+
+   spin_lock_irq(>lock);
+ restart:
+   list_splice_tail_init(>prio_hi_head, _list[URB_PRIO_HIGH]);
+   list_splice_tail_init(>prio_lo_head, _list[URB_PRIO_LOW]);
+   spin_unlock_irq(>lock);
+
+   for (i = 0; i < ARRAY_SIZE(urb_list); i++) {
+   while (!list_empty(_list[i])) {
+   struct urb *urb;
+
+   urb = list_first_entry(_list[i],
+  struct urb, urb_list);
+   list_del_init(>urb_list);
+   if (i == URB_PRIO_HIGH)
+   bh->completing_ep = urb->ep;
+
+   __usb_hcd_giveback_urb(urb);
+
+   if (i == URB_PRIO_HIGH)
+   bh->completing_ep = NULL;
+
+   if (i == URB_PRIO_LOW &&
+   !list_empty_careful(_list[URB_PRIO_HIGH])) {
+   spin_lock_irq(>lock);
+   goto restart;
+   }
+   }
}

/* check if there are new URBs to giveback */
spin_lock_irq(>lock);
-   if (!list_empty(>head))
+   if (!list_empty(>prio_hi_head) ||
+   !list_empty(>prio_lo_head))
goto restart;
-   bh->running = false;
spin_unlock_irq(>lock);
+
+   return IRQ_HANDLED;
}

/**
@@ -1717,37 +1760,34 @@ static void usb_giveback_urb_bh(struct tasklet_struct 
*t)
 */
void usb_hcd_giveback_urb(struct usb_hcd *hcd, struct urb *urb, int status)
{
-   struct giveback_urb_bh *bh;
-   bool running, high_prio_bh;
+   struct giveback_urb *bh = >gb_urb;
+   struct list_head*lh;

/* pass status to tasklet via unlinked */
if (likely(!urb->unlinked))
urb->unlinked = status;

-   if (!hcd_giveback_urb_in_bh(hcd) && !is_root_hub(urb->dev)) {
-   __usb_hcd_giveback_urb(urb);
+   if (is_root_hub(urb->dev)) {
+   spin_lock(>lock);
+   list_add_tail(>urb_list, >rh_head);
+   spin_unlock(>lock);
+

[PATCH] arm64: dts: rockchip: rk3328: Fix UART pull-ups

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

For UARTs, the local pull-ups should be on the RX pin, not the TX pin.
UARTs transmit active-low, so a disconnected RX pin should be pulled
high instead of left floating to prevent noise being interpreted as
transmissions.

This gets rid of bogus sysrq events when the UART console is not
connected.

Fixes: 52e02d377a72 ("arm64: dts: rockchip: add core dtsi file for RK3328 SoCs")
Signed-off-by: Chen-Yu Tsai 
---
 arch/arm64/boot/dts/rockchip/rk3328.dtsi | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index 521c4678ec35..1e3aa6acbc11 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -1265,8 +1265,8 @@ otp_out: otp-out {
 
uart0 {
uart0_xfer: uart0-xfer {
-   rockchip,pins = <1 RK_PB1 1 _pull_up>,
-   <1 RK_PB0 1 _pull_none>;
+   rockchip,pins = <1 RK_PB1 1 _pull_none>,
+   <1 RK_PB0 1 _pull_up>;
};
 
uart0_cts: uart0-cts {
@@ -1284,8 +1284,8 @@ uart0_rts_pin: uart0-rts-pin {
 
uart1 {
uart1_xfer: uart1-xfer {
-   rockchip,pins = <3 RK_PA4 4 _pull_up>,
-   <3 RK_PA6 4 _pull_none>;
+   rockchip,pins = <3 RK_PA4 4 _pull_none>,
+   <3 RK_PA6 4 _pull_up>;
};
 
uart1_cts: uart1-cts {
@@ -1303,15 +1303,15 @@ uart1_rts_pin: uart1-rts-pin {
 
uart2-0 {
uart2m0_xfer: uart2m0-xfer {
-   rockchip,pins = <1 RK_PA0 2 _pull_up>,
-   <1 RK_PA1 2 _pull_none>;
+   rockchip,pins = <1 RK_PA0 2 _pull_none>,
+   <1 RK_PA1 2 _pull_up>;
};
};
 
uart2-1 {
uart2m1_xfer: uart2m1-xfer {
-   rockchip,pins = <2 RK_PA0 1 _pull_up>,
-   <2 RK_PA1 1 _pull_none>;
+   rockchip,pins = <2 RK_PA0 1 _pull_none>,
+   <2 RK_PA1 1 _pull_up>;
};
};
 
-- 
2.29.2

Re: high number of dropped packets/rx_missed_errors from 4.17 kernel

[Andrei Popa]

Hi,

I’ve applied your patch on kernel 4.17.0 and dropped packets and 
rx_missed_errors are still present, through they are increasing at a lower rate.

root@shaper:~# ./test
 rx_missed_errors: 2135
RX errors 0  dropped 2155  overruns 0  frame 0
sleeping 60 seconds
 rx_missed_errors: 2433
RX errors 0  dropped 2459  overruns 0  frame 0
sleeping 60 seconds
 rx_missed_errors: 2433
RX errors 0  dropped 2465  overruns 0  frame 0
sleeping 60 seconds
 rx_missed_errors: 2526
RX errors 0  dropped 2564  overruns 0  frame 0
sleeping 60 seconds


> On 3 Dec 2020, at 21:43, Andrei Popa  wrote:
> 
> Hi,
> 
> On what kernel version should I try the patch ? I tried on 5.9 and it doesn't 
> build.
> 
>> On 18 Nov 2020, at 20:47, Rafael J. Wysocki  wrote:
>> 
>> On Tuesday, November 17, 2020 7:31:29 PM CET Rafael J. Wysocki wrote:
>>> On 11/16/2020 8:11 AM, Andrei Popa wrote:
 Hello,
 
 After an update from vmlinuz-4.15.0-106-generic to 
 vmlinuz-5.4.0-37-generic we experience, on a  number of servers, a very 
 high number of rx_missed_errors and dropped packets only on the uplink 10G 
 interface. We have another 10G downlink interface with no problems.
 
 The affected servers have the following mainboards:
 S5520HC ver E26045-455
 S5520UR ver E22554-751
 S5520UR ver E22554-753
 S5000VSA
 
 On other 30 servers with similar mainboards and/or configs there are no 
 dropped packets with vmlinuz-5.4.0-37-generic.
 
 We’ve installed vanilla 4.16 and there were no dropped packets.
 Vanilla 4.17 had a very high number of dropped packets like the following:
 
 root@shaper:~# cat test
 #!/bin/bash
 while true
 do
 ethtool -S ens6f1|grep "missed_errors"
 ifconfig ens6f1|grep RX|grep dropped
 sleep 1
 done
 
 root@shaper:~# ./test
 rx_missed_errors: 2418845
RX errors 0  dropped 241  overruns 0  frame 0
 rx_missed_errors: 2426175
RX errors 0  dropped 2426218  overruns 0  frame 0
 rx_missed_errors: 2431910
RX errors 0  dropped 2431953  overruns 0  frame 0
 rx_missed_errors: 2437266
RX errors 0  dropped 2437309  overruns 0  frame 0
 rx_missed_errors: 2443305
RX errors 0  dropped 2443348  overruns 0  frame 0
 rx_missed_errors: 2448357
RX errors 0  dropped 2448400  overruns 0  frame 0
 rx_missed_errors: 2452539
RX errors 0  dropped 2452582  overruns 0  frame 0
 
 We did a git bisect and we’ve found that the following commit generates 
 the high number of dropped packets:
 
 Author: Rafael J. Wysocki >>> >
 Date:   Thu Apr 5 19:12:43 2018 +0200
cpuidle: menu: Avoid selecting shallow states with stopped tick
If the scheduler tick has been stopped already and the governor
selects a shallow idle state, the CPU can spend a long time in that
state if the selection is based on an inaccurate prediction of idle
time.  That effect turns out to be relevant, so it needs to be
mitigated.
To that end, modify the menu governor to discard the result of the
idle time prediction if the tick is stopped and the predicted idle
time is less than the tick period length, unless the tick timer is
going to expire soon.
Signed-off-by: Rafael J. Wysocki >>> >
Acked-by: Peter Zijlstra (Intel) >>> >
 diff --git a/drivers/cpuidle/governors/menu.c 
 b/drivers/cpuidle/governors/menu.c
 index 267982e471e0..1bfe03ceb236 100644
 --- a/drivers/cpuidle/governors/menu.c
 +++ b/drivers/cpuidle/governors/menu.c
 @@ -352,13 +352,28 @@ static int menu_select(struct cpuidle_driver *drv, 
 struct cpuidle_device *dev,
 */
data->predicted_us = min(data->predicted_us, expected_interval);
 -   /*
 -* Use the performance multiplier and the user-configurable
 -* latency_req to determine the maximum exit latency.
 -*/
 -   interactivity_req = data->predicted_us / 
 performance_multiplier(nr_iowaiters, cpu_load);
 -   if (latency_req > interactivity_req)
 -   latency_req = interactivity_req;
>>> 
>>> The tick_nohz_tick_stopped() check may be done after the above and it 
>>> may be reworked a bit.
>>> 
>>> I'll send a test patch to you shortly.
>> 
>> The patch is appended, but please note that it has been rebased by hand and
>> not tested.
>> 
>> Please let me know if it makes any difference.
>> 
>> And in the future please avoid pasting the entire kernel config to your
>> reports, that's problematic.
>> 
>> ---
>> drivers/cpuidle/governors/menu.c |   23 ---
>> 1 file changed, 12 insertions(+), 11 deletions(-)
>> 
>> Index: 

Re: [PATCH bpf-next v3 10/14] bpf: Add bitwise atomic instructions

[Yonghong Song]

On 12/3/20 8:02 AM, Brendan Jackman wrote:

This adds instructions for

atomic[64]_[fetch_]and
atomic[64]_[fetch_]or
atomic[64]_[fetch_]xor

All these operations are isomorphic enough to implement with the same
verifier, interpreter, and x86 JIT code, hence being a single commit.

The main interesting thing here is that x86 doesn't directly support
the fetch_ version these operations, so we need to generate a CMPXCHG
loop in the JIT. This requires the use of two temporary registers,
IIUC it's safe to use BPF_REG_AX and x86's AUX_REG for this purpose.

Change-Id: I340b10cecebea8cb8a52e3606010cde547a10ed4
Signed-off-by: Brendan Jackman 
---
  arch/x86/net/bpf_jit_comp.c  | 50 +-
  include/linux/filter.h   | 60 
  kernel/bpf/core.c|  5 ++-
  kernel/bpf/disasm.c  | 21 ++---
  kernel/bpf/verifier.c|  6 
  tools/include/linux/filter.h | 60 
  6 files changed, 196 insertions(+), 6 deletions(-)

diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index 7d29bc3bb4ff..4ab0f821326c 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -824,6 +824,10 @@ static int emit_atomic(u8 **pprog, u8 atomic_op,
/* emit opcode */
switch (atomic_op) {
case BPF_ADD:
+   case BPF_SUB:
+   case BPF_AND:
+   case BPF_OR:
+   case BPF_XOR:
/* lock *(u32/u64*)(dst_reg + off) = src_reg */
EMIT1(simple_alu_opcodes[atomic_op]);
break;
@@ -1306,8 +1310,52 @@ st:  if (is_imm8(insn->off))
  
  		case BPF_STX | BPF_ATOMIC | BPF_W:

case BPF_STX | BPF_ATOMIC | BPF_DW:
+   if (insn->imm == (BPF_AND | BPF_FETCH) ||
+   insn->imm == (BPF_OR | BPF_FETCH) ||
+   insn->imm == (BPF_XOR | BPF_FETCH)) {
+   u8 *branch_target;
+   bool is64 = BPF_SIZE(insn->code) == BPF_DW;
+
+   /*
+* Can't be implemented with a single x86 insn.
+* Need to do a CMPXCHG loop.
+*/
+
+   /* Will need RAX as a CMPXCHG operand so save 
R0 */
+   emit_mov_reg(, true, BPF_REG_AX, 
BPF_REG_0);
+   branch_target = prog;
+   /* Load old value */
+   emit_ldx(, BPF_SIZE(insn->code),
+BPF_REG_0, dst_reg, insn->off);
+   /*
+* Perform the (commutative) operation locally,
+* put the result in the AUX_REG.
+*/
+   emit_mov_reg(, is64, AUX_REG, BPF_REG_0);
+   maybe_emit_mod(, AUX_REG, src_reg, is64);
+   EMIT2(simple_alu_opcodes[BPF_OP(insn->imm)],
+ add_2reg(0xC0, AUX_REG, src_reg));
+   /* Attempt to swap in new value */
+   err = emit_atomic(, BPF_CMPXCHG,
+ dst_reg, AUX_REG, insn->off,
+ BPF_SIZE(insn->code));
+   if (WARN_ON(err))
+   return err;
+   /*
+* ZF tells us whether we won the race. If it's
+* cleared we need to try again.
+*/
+   EMIT2(X86_JNE, -(prog - branch_target) - 2);
+   /* Return the pre-modification value */
+   emit_mov_reg(, is64, src_reg, BPF_REG_0);
+   /* Restore R0 after clobbering RAX */
+   emit_mov_reg(, true, BPF_REG_0, 
BPF_REG_AX);
+   break;
+
+   }
+
err = emit_atomic(, insn->imm, dst_reg, src_reg,
- insn->off, BPF_SIZE(insn->code));
+ insn->off, 
BPF_SIZE(insn->code));
if (err)
return err;
break;
diff --git a/include/linux/filter.h b/include/linux/filter.h
index 6186280715ed..698f82897b0d 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -280,6 +280,66 @@ static inline bool insn_is_zext(const struct bpf_insn 
*insn)
.off   = OFF,   \
.imm   = BPF_ADD | BPF_FETCH })
  
+/* Atomic memory 

[PATCH v4 3/3] docs: make reporting-bugs.rst obsolete

[Thorsten Leemhuis]

Make various places which point to
Documentation/admin-guide/reporting-bugs.rst point to
Documentation/admin-guide/reporting-issues.rst instead. That document is
brand new and as of now is not completely finished. But even at this
stage it's a lot more helpful and accurate than reporting-bugs.rst.
Hence also add a note to reporting-bugs.rst, telling people they're
better off reading reporting-issues.rst instead.

reporting-bugs.rst is scheduled for removal once reporting-issues.rst
is considered ready.

Signed-off-by: Thorsten Leemhuis 
---
 Documentation/admin-guide/README.rst | 4 ++--
 Documentation/admin-guide/bug-bisect.rst | 2 +-
 Documentation/admin-guide/index.rst  | 2 +-
 Documentation/admin-guide/reporting-bugs.rst | 5 +
 Documentation/admin-guide/security-bugs.rst  | 2 +-
 .../networking/device_drivers/ethernet/3com/vortex.rst   | 4 ++--
 Documentation/process/howto.rst  | 9 -
 7 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/Documentation/admin-guide/README.rst 
b/Documentation/admin-guide/README.rst
index 95a28f47ac30..261b7b4cca1f 100644
--- a/Documentation/admin-guide/README.rst
+++ b/Documentation/admin-guide/README.rst
@@ -398,8 +398,8 @@ If something goes wrong
 
If you for some reason cannot do the above (you have a pre-compiled
kernel image or similar), telling me as much about your setup as
-   possible will help.  Please read the :ref:`admin-guide/reporting-bugs.rst 
`
-   document for details.
+   possible will help.  Please read
+   'Documentation/admin-guide/reporting-issues.rst' for details.
 
  - Alternatively, you can use gdb on a running kernel. (read-only; i.e. you
cannot change values or set break points.) To do this, first compile the
diff --git a/Documentation/admin-guide/bug-bisect.rst 
b/Documentation/admin-guide/bug-bisect.rst
index 59567da344e8..325c5d0ed34a 100644
--- a/Documentation/admin-guide/bug-bisect.rst
+++ b/Documentation/admin-guide/bug-bisect.rst
@@ -15,7 +15,7 @@ give up. Report as much as you have found to the relevant 
maintainer. See
 MAINTAINERS for who that is for the subsystem you have worked on.
 
 Before you submit a bug report read
-:ref:`Documentation/admin-guide/reporting-bugs.rst `.
+'Documentation/admin-guide/reporting-issues.rst'.
 
 Devices not appearing
 =
diff --git a/Documentation/admin-guide/index.rst 
b/Documentation/admin-guide/index.rst
index c52c1882bd04..937e1a157fc9 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -34,7 +34,7 @@ problems and bugs in particular.
:maxdepth: 1
 
reporting-issues
-   reporting-bugs
+   Reporting bugs (obsolete) 
security-bugs
bug-hunting
bug-bisect
diff --git a/Documentation/admin-guide/reporting-bugs.rst 
b/Documentation/admin-guide/reporting-bugs.rst
index 42481ea7b41d..409fa91d7495 100644
--- a/Documentation/admin-guide/reporting-bugs.rst
+++ b/Documentation/admin-guide/reporting-bugs.rst
@@ -1,5 +1,10 @@
 .. _reportingbugs:
 
+.. note::
+
+   This document is obsolete, and will be replaced by
+   'Documentation/admin-guide/reporting-issues.rst' in the near future.
+
 Reporting bugs
 ++
 
diff --git a/Documentation/admin-guide/security-bugs.rst 
b/Documentation/admin-guide/security-bugs.rst
index c32eb786201c..82e29837d589 100644
--- a/Documentation/admin-guide/security-bugs.rst
+++ b/Documentation/admin-guide/security-bugs.rst
@@ -21,7 +21,7 @@ understand and fix the security vulnerability.
 
 As it is with any bug, the more information provided the easier it
 will be to diagnose and fix.  Please review the procedure outlined in
-:doc:`reporting-bugs` if you are unclear about what
+'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what
 information is helpful.  Any exploit code is very helpful and will not
 be released without consent from the reporter unless it has already been
 made public.
diff --git a/Documentation/networking/device_drivers/ethernet/3com/vortex.rst 
b/Documentation/networking/device_drivers/ethernet/3com/vortex.rst
index eab10fc6da5c..e89e4192af88 100644
--- a/Documentation/networking/device_drivers/ethernet/3com/vortex.rst
+++ b/Documentation/networking/device_drivers/ethernet/3com/vortex.rst
@@ -374,8 +374,8 @@ steps you should take:
email address will be in the driver source or in the MAINTAINERS file.
 
 - The contents of your report will vary a lot depending upon the
-  problem.  If it's a kernel crash then you should refer to the
-  admin-guide/reporting-bugs.rst file.
+  problem.  If it's a kernel crash then you should refer to
+  'Documentation/admin-guide/reporting-issues.rst'.
 
   But for most problems it is useful to provide the following:
 
diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst
index 20c9e07e09a4..7a5c105e34d4 100644
--- a/Documentation/process/howto.rst
+++ 

[PATCH v4 1/3] LICENSES: Add the CC-BY-4.0 license

[Thorsten Leemhuis]

Add the full text of the CC-BY-4.0 license to the kernel tree as well as
the required tags for reference and tooling.

The license text was copied directly from the following url, but for
clarification a 'Creative Commons' was added before 'Attribution 4.0
International' in the first line:
https://creativecommons.org/licenses/by/4.0/legalcode.txt

CC-BY-4.0 is GPLv2 compatible, but when for example used for the
kernel's documentation it can easily happen that sphinx during
processing combines it with text or code from files using a more
restrictive license[1]. This bears pitfalls, hence point that risk out
and suggest to only use this license in combination with the GPLv2.

[1] https://lkml.kernel.org/r/20201201144314.ga14...@lst.de

Signed-off-by: Thorsten Leemhuis 
CC: Thomas Gleixner 
CC: Greg Kroah-Hartman 
CC: Christoph Hellwig 
---
 LICENSES/dual/CC-BY-4.0 | 410 
 1 file changed, 410 insertions(+)
 create mode 100644 LICENSES/dual/CC-BY-4.0

diff --git a/LICENSES/dual/CC-BY-4.0 b/LICENSES/dual/CC-BY-4.0
new file mode 100644
index ..45a81b8e4669
--- /dev/null
+++ b/LICENSES/dual/CC-BY-4.0
@@ -0,0 +1,410 @@
+Valid-License-Identifier: CC-BY-4.0
+SPDX-URL: https://spdx.org/licenses/CC-BY-4.0
+Usage-Guide:
+  Do NOT use this license for code, but it's acceptable for content like 
artwork
+  or documentation. When using it for the latter, it's best to use it together
+  with a GPL2 compatible license using "OR", as CC-BY-4.0 texts processed by
+  the kernel's build system might combine it with content taken from more
+  restrictive licenses.
+  To use the Creative Commons Attribution 4.0 International license put
+  the following SPDX tag/value pair into a comment according to the
+  placement guidelines in the licensing rules documentation:
+SPDX-License-Identifier: CC-BY-4.0
+License-Text:
+
+Creative Commons Attribution 4.0 International
+
+===
+
+Creative Commons Corporation ("Creative Commons") is not a law firm and
+does not provide legal services or legal advice. Distribution of
+Creative Commons public licenses does not create a lawyer-client or
+other relationship. Creative Commons makes its licenses and related
+information available on an "as-is" basis. Creative Commons gives no
+warranties regarding its licenses, any material licensed under their
+terms and conditions, or any related information. Creative Commons
+disclaims all liability for damages resulting from their use to the
+fullest extent possible.
+
+Using Creative Commons Public Licenses
+
+Creative Commons public licenses provide a standard set of terms and
+conditions that creators and other rights holders may use to share
+original works of authorship and other material subject to copyright
+and certain other rights specified in the public license below. The
+following considerations are for informational purposes only, are not
+exhaustive, and do not form part of our licenses.
+
+ Considerations for licensors: Our public licenses are
+ intended for use by those authorized to give the public
+ permission to use material in ways otherwise restricted by
+ copyright and certain other rights. Our licenses are
+ irrevocable. Licensors should read and understand the terms
+ and conditions of the license they choose before applying it.
+ Licensors should also secure all rights necessary before
+ applying our licenses so that the public can reuse the
+ material as expected. Licensors should clearly mark any
+ material not subject to the license. This includes other CC-
+ licensed material, or material used under an exception or
+ limitation to copyright. More considerations for licensors:
+wiki.creativecommons.org/Considerations_for_licensors
+
+ Considerations for the public: By using one of our public
+ licenses, a licensor grants the public permission to use the
+ licensed material under specified terms and conditions. If
+ the licensor's permission is not necessary for any reason--for
+ example, because of any applicable exception or limitation to
+ copyright--then that use is not regulated by the license. Our
+ licenses grant only permissions under copyright and certain
+ other rights that a licensor has authority to grant. Use of
+ the licensed material may still be restricted for other
+ reasons, including because others have copyright or other
+ rights in the material. A licensor may make special requests,
+ such as asking that all changes be marked or described.
+ Although not required by our licenses, you are encouraged to
+ respect those requests where reasonable. More considerations
+ for the public:
+wiki.creativecommons.org/Considerations_for_licensees
+
+===
+
+Creative Commons Attribution 4.0 International Public License

[PATCH v4 2/3] docs: Add a new text describing how to report bugs

[Thorsten Leemhuis]

Add a mostly finished document describing how to report issues with the
Linux kernel to its developers. It is designed to be a lot more straight
forward and easier to follow than the current text about this
(Documentation/admin-guide/reporting-bugs.rst); at the same time the new
text should be more helpful for people unfamiliar with the topic, as it
provides a lot more details, too.

The main work on the text is done, but some polishing is still needed.
The text also needs to be reviewed by more people and a few issues still
might need some discussion. To make these tasks easier, it was decided
([1]) to add this document to the kernel sources in parallel to the
existing text; the latter will be removed once this text is considered
good enough(tm).

This document is quite long and provides a lot of details, but was
carefully crafted to make sure it's can also serve people that are in a
hurry. That's mainly achieved by having a TDLR and a step-by-step guide,
which should be good enough for quite a lot of people. Everybody that
wants or need more explanations can find them in a reference section,
which describes all the needed steps in detail.

Thanks to this structure the text can work for kernel developers that
just need to look something up, experienced FLOSS contributors that are
unfamiliar with the kernel's bug reporting workflow, and users reporting
something upstream for the first time. The text is thus a bit like the
kernel itself, which works well for embedded machines, a typical desktop
PC, cloud servers, and HPC.

The document was written in the hope it will improve the quality of the
bug reports, especially those that come from people unfamiliar with how
Linux kernel development works. Sadly quite a few reports from this
group are currently of poor quality and/or get submitted to the wrong
place. Part of the problem is the old reporting-bugs document, as it
makes its essence hard to grasp; it's and also inaccurate and slightly
outdated in a few spots. Due to this quite a few valid reports are
ignored in the end, which is annoying for those that compiled them and
bad for the kernel's quality.

The document near the top points out that it's still unfinished, but
nevertheless ready for consumption. Those few areas in the text that
might need some further discussion contain a note pointing this out.
Besides lack of review from core developers there is only one major
issue left: the section 'Decode failure message' is known to be
outdated: it's waiting for someone familiar with the topic to write
something up or give at least provide some hints and pointers what to
write there.

The new document is dual-licensed under GPL-2.0+ or CC-BY-4.0. The
latter is way more liberal and makes it attractive to use this text as a
base when writing about this topic on websites or in books. This
hopefully increases the chances that such texts are accurate and stick
to official way of doing things.

[1] https://lkml.kernel.org/r/20201118172958.5b014...@lwn.net

Signed-off-by: Thorsten Leemhuis 
CC: Thomas Gleixner 
CC: Greg Kroah-Hartman 
CC: Christoph Hellwig 
---
 Documentation/admin-guide/index.rst   |1 +
 .../admin-guide/reporting-issues.rst  | 1631 +
 2 files changed, 1632 insertions(+)
 create mode 100644 Documentation/admin-guide/reporting-issues.rst

diff --git a/Documentation/admin-guide/index.rst 
b/Documentation/admin-guide/index.rst
index 4e0c4ae44acd..c52c1882bd04 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -33,6 +33,7 @@ problems and bugs in particular.
 .. toctree::
:maxdepth: 1
 
+   reporting-issues
reporting-bugs
security-bugs
bug-hunting
diff --git a/Documentation/admin-guide/reporting-issues.rst 
b/Documentation/admin-guide/reporting-issues.rst
new file mode 100644
index ..5cbb1b5f4a52
--- /dev/null
+++ b/Documentation/admin-guide/reporting-issues.rst
@@ -0,0 +1,1631 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
+..
+   If you want to distribute this text under CC-BY-4.0 only, please use 'The
+   Linux kernel developers' for author attribution and link this as source:
+   
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/reporting-issues.rst
+..
+   Note: Only the content of this RST file as found in the Linux kernel sources
+   is available under CC-BY-4.0, as versions of this text that were processed
+   (for example by the kernel's build system) might contain content taken from
+   files which use a more restrictive license.
+
+.. important::
+
+   This document is being prepared to replace
+   'Documentation/admin-guide/reporting-bugs.rst'. The main work is done and
+   you are already free to follow its instructions when reporting issues to the
+   Linux kernel developers. But keep in mind, below text still needs a few
+   finishing touches and review. It was merged to the Linux kernel sources at
+   this stage to make 

[PATCH v4 0/3] New documentation text describing how to report issues (aka "reporting-bugs rewritten")

[Thorsten Leemhuis]

This series adds a new and mostly finished document describing how to report
issues with the Linux kernel to its developers. It is designed to be a lot more
straight forward and yet more detailed than the current text about this
(Documentation/admin-guide/reporting-bugs.rst). The new text still needs to be
reviewed by more people and a few open issues will need discussion. To make
these tasks easier, it was decided to add this document to the kernel sources in
parallel to the existing text for now:
https://lkml.kernel.org/r/20201118172958.5b014...@lwn.net

The first patch in the series adds the CC-BY-4.0 license to the
LICENSES/preferred/ directory, as the main author wants to make it easy for
others to use the new text as a base when writing about this topic in books or
on websites. He for now went with for dual-licensing the text under GPL-2.0+ and
CC-BY-4.0. We shouldn't lose much when people use the more liberal of the two,
but gain one thing: it increases chances that texts about this topic are based
on this one, which should make them more accurate and to our liking.

The last patch in the series adds a note to
Documentation/admin-guide/reporting-bugs.rst, declaring it obsolete and telling
readers to head over to the new text, as discussed after the v2 submission.

To see how the new text relates to the current reporting-bugs.rst document, see
v2 of this patchset, which gradually replaced the old text with the new (which
hasn't changed much since then):
https://lore.kernel.org/lkml/cover.1605203187.git.li...@leemhuis.info/

To see how the new text from v3 and v4 relates to the one from v2 or v1, compare
these files with tools like meld or kdiff3:

https://gitlab.com/knurd42/linux/-/raw/reporting-bugs/Documentation/admin-guide/reporting-bugs-v4-wrapped.rst
https://gitlab.com/knurd42/linux/-/raw/reporting-bugs/Documentation/admin-guide/reporting-bugs-v3-wrapped.rst
https://gitlab.com/knurd42/linux/-/raw/reporting-bugs/Documentation/admin-guide/reporting-bugs-v2-wrapped.rst
https://gitlab.com/knurd42/linux/-/raw/reporting-bugs/Documentation/admin-guide/reporting-bugs-v1-wrapped.rst

The patch series is against docs-next and can also be found on gitlab:
git://g...@gitlab.com:knurd42/linux.git reporting-bugs-v4

[1] https://lkml.kernel.org/r/20201118172958.5b014...@lwn.net

= Changes =

v3 -> v4
- move CC-BY-4.0 from LICENSES/preferred/ to LICENSES/dual/
- add note to CC-BY-4.0 file explaining why it's best used together with GPL
- add a note to as comment to the header of reporting-issues.rst, pointing out
only the unprocessed version of this file is available under CC-BY-4.0.

v2 -> v3
- drop the RFC tag
- add CC-BY-4.0 to LICENSES/preferred/
- instead of adding the new text in small parts while gradually replacing the
  old text simply dump the whole new text in a new file in one go
- add a note at the top pointing out the text is not completely finished yet,
  but ready for consumption
- add a few notes to the text pointing to issues that need discussion or work;
  this until now was done in the patch
- let the automarkup extension handle links to Documentation/whatever instead of
  using an explicit :ref:
- leave scripts/ver_linux untouched
- a handful of small improvements and fixes in the main text
- add a patch that makes reporting-bugs.rst obsolete

v1 -> v2
- all over: a whole lot of spelling fixes and small improvements. Many thx to
  suggestions from Randy Dunlap (many thx!).
- use "ref:" to reference MAINTAINERs file
- the licensing advice is now a rst comment near the top
- reshuffle and rewrite some parts to make them more straight forward:
 - The short guide (aka TL;DR)" (patch 2)
 - Locate kernel area that causes the issue (patch 9)
 - Install a fresh kernel for testing (patch 15)

= Links =

v3 submission:
https://lore.kernel.org/lkml/cover.1606137108.git.li...@leemhuis.info/

v2 submission:
https://lore.kernel.org/lkml/cover.1605203187.git.li...@leemhuis.info/

v1 submission:
https://lore.kernel.org/lkml/cover.1601541165.git.li...@leemhuis.info/

Current version of reporting-bugs.rst
https://www.kernel.org/doc/html/latest/admin-guide/reporting-bugs.html
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/reporting-bugs.rst

Commits to it and its predecessor:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/Documentation/admin-guide/reporting-bugs.rst
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/REPORTING-BUGS

Thorsten Leemhuis (3):
  LICENSES: Add the CC-BY-4.0 license
  docs: Add a new text describing how to report bugs
  docs: make reporting-bugs.rst obsolete

 Documentation/admin-guide/README.rst  |4 +-
 Documentation/admin-guide/bug-bisect.rst  |2 +-
 Documentation/admin-guide/index.rst   |3 +-
 Documentation/admin-guide/reporting-bugs.rst  |5 +
 .../admin-guide/reporting-issues.rst  | 1631 +
 

Re: [PATCH next v2 3/3] printk: remove logbuf_lock, add syslog_lock

[Sergey Senozhatsky]

On (20/12/01 21:59), John Ogness wrote:
>  
> +#ifdef CONFIG_PRINTK_NMI
> +#define NUM_RECURSION_CTX 2
> +#else
> +#define NUM_RECURSION_CTX 1
> +#endif
> +
> +struct printk_recursion {
> + charcount[NUM_RECURSION_CTX];
> +};
> +
> +static DEFINE_PER_CPU(struct printk_recursion, percpu_printk_recursion);
> +static char printk_recursion_count[NUM_RECURSION_CTX];
> +
> +static char *get_printk_count(void)

A nit: I think get_foo() has some sort of special meaning and one would
expect that there should be put_foo() as well, and that those have
something to do with the ref counting.

> +{
> + struct printk_recursion *rec;
> + char *count;
> +
> + if (!printk_percpu_data_ready()) {
> + count = _recursion_count[0];
> + } else {
> + rec = this_cpu_ptr(_printk_recursion);
> +
> + count = >count[0];
> + }
> +
> +#ifdef CONFIG_PRINTK_NMI
> + if (in_nmi())
> + count++;
> +#endif
> +
> + return count;
> +}
> +
> +static bool printk_enter(unsigned long *flags)

This better explicitly state that it disables local IRQs

printk_enter_irqsave()

I'm not very certain that printk_enter/printk_exit are best names:

if (!printk_enter())
return;

Maybe it can spell out why we couldn't enter printk so the function
name can contain recursion_limit or something.

> +{
> + char *count;
> +
> + local_irq_save(*flags);
> + count = get_printk_count();
> + /* Only 1 level of recursion allowed. */
> + if (*count > 1) {
> + local_irq_restore(*flags);
> + return false;
> + }
> + (*count)++;
> +
> + return true;
> +}
> +
> +static void printk_exit(unsigned long flags)

This enables local IRQs, so

printk_exit_irqrestore()

> +{
> + char *count;
> +
> + count = get_printk_count();
> + (*count)--;
> + local_irq_restore(flags);
> +}

-ss

Re: [PATCH][next] wilc1000: remove redundant assignment to pointer vif

[Ajay.Kathat]

On 03/12/20 11:13 pm, Colin King wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
> content is safe
> 
> From: Colin Ian King 
> 
> The assignment to pointer vif is redundant as the assigned value
> is never read, hence it can be removed.
> 
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King 

Thanks.

Acked-by: Ajay Singh 

> ---
>  drivers/net/wireless/microchip/wilc1000/wlan.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/microchip/wilc1000/wlan.c 
> b/drivers/net/wireless/microchip/wilc1000/wlan.c
> index 993ea7c03429..c12f27be9f79 100644
> --- a/drivers/net/wireless/microchip/wilc1000/wlan.c
> +++ b/drivers/net/wireless/microchip/wilc1000/wlan.c
> @@ -685,7 +685,6 @@ int wilc_wlan_handle_txq(struct wilc *wilc, u32 
> *txq_count)
> if (!tqe_q[ac])
> continue;
> 
> -   vif = tqe_q[ac]->vif;
> ac_exist = 1;
> for (k = 0; (k < num_pkts_to_add[ac]) &&
>  (!max_size_over) && tqe_q[ac]; k++) {
> --
> 2.29.2
> 

[PATCH v2] ASoC: amd: change clk_get() to devm_clk_get() and add missed checks

[Chuhong Yuan]

cz_da7219_init() does not check the return values of clk_get(),
while da7219_clk_enable() calls clk_set_rate() to dereference
the pointers.
Add checks to fix the problems.
Also, change clk_get() to devm_clk_get() to avoid data leak after
failures.

Fixes: bb24a31ed584 ("ASoC: AMD: Configure wclk and bclk of master codec")
Signed-off-by: Chuhong Yuan 
---
Changes in v2:
  - Replace clk_get() with devm_clk_get() to prevent data leak.

 sound/soc/amd/acp-da7219-max98357a.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/sound/soc/amd/acp-da7219-max98357a.c 
b/sound/soc/amd/acp-da7219-max98357a.c
index a7702e64ec51..849288d01c6b 100644
--- a/sound/soc/amd/acp-da7219-max98357a.c
+++ b/sound/soc/amd/acp-da7219-max98357a.c
@@ -73,8 +73,13 @@ static int cz_da7219_init(struct snd_soc_pcm_runtime *rtd)
return ret;
}
 
-   da7219_dai_wclk = clk_get(component->dev, "da7219-dai-wclk");
-   da7219_dai_bclk = clk_get(component->dev, "da7219-dai-bclk");
+   da7219_dai_wclk = devm_clk_get(component->dev, "da7219-dai-wclk");
+   if (IS_ERR(da7219_dai_wclk))
+   return PTR_ERR(da7219_dai_wclk);
+
+   da7219_dai_bclk = devm_clk_get(component->dev, "da7219-dai-bclk");
+   if (IS_ERR(da7219_dai_bclk))
+   return PTR_ERR(da7219_dai_bclk);
 
ret = snd_soc_card_jack_new(card, "Headset Jack",
SND_JACK_HEADSET | SND_JACK_LINEOUT |
-- 
2.26.2

Re: [PATCH] powerpc/mm: Don't see NULL pointer dereference as a KUAP fault

[Christophe Leroy]

Le 03/12/2020 à 12:55, Michael Ellerman a écrit :

Christophe Leroy  writes:

Sometimes, NULL pointer dereferences are expected. Even when they
are accidental they are unlikely an exploit attempt because the
first page is never mapped.


The first page can be mapped if mmap_min_addr is 0.

Blocking all faults to the first page would potentially break any
program that does that.

Also if there is something mapped at 0 it's a good chance it is an
exploit attempt :)


Ok, I see.

In fact, we hit this warning because we don't provide 
copy_from_kernel_nofault_allowed()

I'll cook a patch for that.

Christophe

Re: [PATCH bpf-next v3 09/14] bpf: Pull out a macro for interpreting atomic ALU operations

[Yonghong Song]

On 12/3/20 8:02 AM, Brendan Jackman wrote:

Since the atomic operations that are added in subsequent commits are
all isomorphic with BPF_ADD, pull out a macro to avoid the
interpreter becoming dominated by lines of atomic-related code.

Note that this sacrificies interpreter performance (combining
STX_ATOMIC_W and STX_ATOMIC_DW into single switch case means that we
need an extra conditional branch to differentiate them) in favour of
compact and (relatively!) simple C code.

Change-Id: I8cae5b66e75f34393de6063b91c05a8006fdd9e6
Signed-off-by: Brendan Jackman 


Ack with a minor suggestion below.

Acked-by: Yonghong Song 


---
  kernel/bpf/core.c | 79 +++
  1 file changed, 38 insertions(+), 41 deletions(-)

diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 28f960bc2e30..498d3f067be7 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -1618,55 +1618,52 @@ static u64 ___bpf_prog_run(u64 *regs, const struct 
bpf_insn *insn, u64 *stack)
LDX_PROBE(DW, 8)
  #undef LDX_PROBE
  
-	STX_ATOMIC_W:

-   switch (IMM) {
-   case BPF_ADD:
-   /* lock xadd *(u32 *)(dst_reg + off16) += src_reg */
-   atomic_add((u32) SRC, (atomic_t *)(unsigned long)
-  (DST + insn->off));
-   break;
-   case BPF_ADD | BPF_FETCH:
-   SRC = (u32) atomic_fetch_add(
-   (u32) SRC,
-   (atomic_t *)(unsigned long) (DST + insn->off));
-   break;
-   case BPF_XCHG:
-   SRC = (u32) atomic_xchg(
-   (atomic_t *)(unsigned long) (DST + insn->off),
-   (u32) SRC);
-   break;
-   case BPF_CMPXCHG:
-   BPF_R0 = (u32) atomic_cmpxchg(
-   (atomic_t *)(unsigned long) (DST + insn->off),
-   (u32) BPF_R0, (u32) SRC);
+#define ATOMIC(BOP, KOP)   \


ATOMIC a little bit generic. Maybe ATOMIC_FETCH_BOP?


+   case BOP:   \
+   if (BPF_SIZE(insn->code) == BPF_W)   \
+   atomic_##KOP((u32) SRC, (atomic_t *)(unsigned 
long) \
+(DST + insn->off)); \
+   else\
+   atomic64_##KOP((u64) SRC, (atomic64_t 
*)(unsigned long) \
+  (DST + insn->off));   \
+   break;  \
+   case BOP | BPF_FETCH:   \
+   if (BPF_SIZE(insn->code) == BPF_W)   \
+   SRC = (u32) atomic_fetch_##KOP( \
+   (u32) SRC,  \
+   (atomic_t *)(unsigned long) (DST + 
insn->off)); \
+   else\
+   SRC = (u64) atomic64_fetch_##KOP(   \
+   (u64) SRC,  \
+   (atomic64_t *)(s64) (DST + insn->off)); 
\
break;
-   default:
-   goto default_label;
-   }
-   CONT;
  
  	STX_ATOMIC_DW:

+   STX_ATOMIC_W:
switch (IMM) {
-   case BPF_ADD:
-   /* lock xadd *(u64 *)(dst_reg + off16) += src_reg */
-   atomic64_add((u64) SRC, (atomic64_t *)(unsigned long)
-(DST + insn->off));
-   break;
-   case BPF_ADD | BPF_FETCH:
-   SRC = (u64) atomic64_fetch_add(
-   (u64) SRC,
-   (atomic64_t *)(s64) (DST + insn->off));
-   break;
+   ATOMIC(BPF_ADD, add)
+
case BPF_XCHG:
-   SRC = (u64) atomic64_xchg(
-   (atomic64_t *)(u64) (DST + insn->off),
-   (u64) SRC);
+   if (BPF_SIZE(insn->code) == BPF_W)
+   SRC = (u32) atomic_xchg(
+   (atomic_t *)(unsigned long) (DST + 
insn->off),
+   (u32) SRC);
+   else
+   SRC = (u64) atomic64_xchg(
+   (atomic64_t *)(u64) (DST + insn->off),
+   (u64) SRC);
break;
  

[PATCH] USB: dummy-hcd: Fix uninitialized array use in init()

[Bui Quang Minh]

This error path

err_add_pdata:
for (i = 0; i < mod_data.num; i++)
kfree(dum[i]);

can be triggered when not all dum's elements are initialized.

Fix this by initializing all dum's elements to NULL.

Signed-off-by: Bui Quang Minh 
---
 drivers/usb/gadget/udc/dummy_hcd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/dummy_hcd.c 
b/drivers/usb/gadget/udc/dummy_hcd.c
index 0eeaead..a2cf009 100644
--- a/drivers/usb/gadget/udc/dummy_hcd.c
+++ b/drivers/usb/gadget/udc/dummy_hcd.c
@@ -2734,7 +2734,7 @@ static int __init init(void)
 {
int retval = -ENOMEM;
int i;
-   struct  dummy *dum[MAX_NUM_UDC];
+   struct  dummy *dum[MAX_NUM_UDC] = {};
 
if (usb_disabled())
return -ENODEV;
-- 
2.7.4

Re: media: i2c: add OV02A10 image sensor driver

[Tomasz Figa]

On Fri, Dec 4, 2020 at 11:47 AM Dongchun Zhu  wrote:
>
> Hi Andy,
>
> On Thu, 2020-12-03 at 20:10 +0200, Andy Shevchenko wrote:
> > On Thu, Dec 3, 2020 at 8:03 PM Colin Ian King  
> > wrote:
> >
> > > Static analysis on linux-next with Coverity has detected an issue with
> > > the following commit:
> >
> > If you want to fix it properly, see my comments below...
> >
> > > 529 static int ov02a10_s_stream(struct v4l2_subdev *sd, int on)
> > > 530 {
> > > 531struct ov02a10 *ov02a10 = to_ov02a10(sd);
> > > 532struct i2c_client *client =
> > > v4l2_get_subdevdata(>subdev);
> > >
> > >1. var_decl: Declaring variable ret without initializer.
> > >
> > > 533int ret;
> > > 534
> > > 535mutex_lock(>mutex);
> > > 536
> > >
> > >2. Condition ov02a10->streaming == on, taking true branch.
> > >
> > > 537if (ov02a10->streaming == on)
> > >
> > >3. Jumping to label unlock_and_return.
> > >
> > > 538goto unlock_and_return;
> > > 539
> > > 540if (on) {
> > > 541ret = pm_runtime_get_sync(>dev);
> > > 542if (ret < 0) {
> >
> > > 543pm_runtime_put_noidle(>dev);
> > > 544goto unlock_and_return;
> >
> > Instead of two above:
>
> From the document, pm_runtime_put_noidle is to decrease the runtime PM
> usage counter of a device unless it is 0 already; while pm_runtime_put
> would additionally run pm_request_idle to turn off the power if usage
> counter is zero.
>
> So here maybe we can really use pm_runtime_put instead of
> pm_runtime_put_noidle, although it seems that 'pm_runtime_get_sync' and
> 'pm_runtime_put_noidle' often appear in pairs.
>

In an error state (e.g. if pm_runtime_get_sync() fails),
pm_runtime_put() would decrement the usage counter and call rpm_idle()
which would instantly return an error code. The end result would be
the same, except that pm_runtime_put() would return a non-zero error
code, but we ignore it anyway. However strange it looks, this seems to
be an API guarantee, so Andy's suggestion is correct.

Best regards,
Tomasz

> >goto err_rpm_put;
> >
> > > 545}
> > > 546
> > > 547ret = __ov02a10_start_stream(ov02a10);
> > > 548if (ret) {
> > > 549__ov02a10_stop_stream(ov02a10);
> > > 550ov02a10->streaming = !on;
> > > 551goto err_rpm_put;
> > > 552}
> > > 553} else {
> > > 554__ov02a10_stop_stream(ov02a10);
> > > 555pm_runtime_put(>dev);
> > > 556}
> > > 557
> > > 558ov02a10->streaming = on;
> >
> > (1)
> >
> > > 559mutex_unlock(>mutex);
> > > 560
> > > 561return 0;
> > > 562
> > > 563 err_rpm_put:
> > > 564pm_runtime_put(>dev);
> >
> > > 565 unlock_and_return:
> >
> > Should be moved to (1).
> >
> > > 566mutex_unlock(>mutex);
> > > 567
> > >
> > > Uninitialized scalar variable (UNINIT)
> > > 4. uninit_use: Using uninitialized value ret.
> > >
> > > 568return ret;
> > > 569 }
> > >
> > > Variable ret has not been initialized, so the error return value is a
> > > garbage value. It should be initialized with some appropriate negative
> > > error code, or ret could be removed and the return should return a
> > > literal value of a error code.
> > >
> > > I was unsure what value is appropriate to fix this, so instead I'm
> > > reporting this issue.
> >
>

RE: [PATCH Xilinx Alveo 7/8] fpga: xrt: Alveo management physical function driver

[Sonal Santan]

Hello Moritz,

> -Original Message-
> From: Moritz Fischer 
> Sent: Tuesday, December 1, 2020 12:52
> To: Sonal Santan 
> Cc: linux-kernel@vger.kernel.org; linux-f...@vger.kernel.org; Max Zhen
; Lizhi Hou ; Michal
> Simek ; Stefano Stabellini ;
devicet...@vger.kernel.org
> Subject: Re: [PATCH Xilinx Alveo 7/8] fpga: xrt: Alveo management physical
function driver
>
>
> Hi Sonal,
>
> On Sat, Nov 28, 2020 at 04:00:39PM -0800, Sonal Santan wrote:
> > 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/alveo/mgmt/xmgmt-fmgr-drv.c | 194 
> >  drivers/fpga/alveo/mgmt/xmgmt-fmgr.h |  29 +
> >  drivers/fpga/alveo/mgmt/xmgmt-main-impl.h|  36 +
> >  drivers/fpga/alveo/mgmt/xmgmt-main-mailbox.c | 930
+++
> >  drivers/fpga/alveo/mgmt/xmgmt-main-ulp.c | 190 
> >  drivers/fpga/alveo/mgmt/xmgmt-main.c | 843 +
> >  drivers/fpga/alveo/mgmt/xmgmt-root.c | 375 
> >  7 files changed, 2597 insertions(+)
> >  create mode 100644 drivers/fpga/alveo/mgmt/xmgmt-fmgr-drv.c
> >  create mode 100644 drivers/fpga/alveo/mgmt/xmgmt-fmgr.h
> >  create mode 100644 drivers/fpga/alveo/mgmt/xmgmt-main-impl.h
> >  create mode 100644 drivers/fpga/alveo/mgmt/xmgmt-main-mailbox.c
> >  create mode 100644 drivers/fpga/alveo/mgmt/xmgmt-main-ulp.c
> >  create mode 100644 drivers/fpga/alveo/mgmt/xmgmt-main.c
> >  create mode 100644 drivers/fpga/alveo/mgmt/xmgmt-root.c
> >
> > diff --git a/drivers/fpga/alveo/mgmt/xmgmt-fmgr-drv.c
b/drivers/fpga/alveo/mgmt/xmgmt-fmgr-drv.c
> > new file mode 100644
> > index ..d451b5a2c291
> > --- /dev/null
> > +++ b/drivers/fpga/alveo/mgmt/xmgmt-fmgr-drv.c
> > @@ -0,0 +1,194 @@
> > +// 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-subdev.h"
> > +#include "xmgmt-fmgr.h"
> > +#include "xrt-axigate.h"
> > +#include "xmgmt-main-impl.h"
> > +
> > +/*
> > + * Container to capture and cache full xclbin as it is passed in blocks by
FPGA
> > + * Manager. Driver needs access to full xclbin to walk through xclbin
sections.
> > + * FPGA Manager's .write() backend sends incremental blocks without any
> > + * knowledge of xclbin format forcing us to collect the blocks and stitch
them
> > + * together here.
> > + */
> > +
> > +struct xfpga_klass {
> Nit: xfpga_priv or xfpga_drvdata?
> > + const struct platform_device *pdev;
> > + struct axlf *blob;
> > + char name[64];
> Nit: 64 could be a named constant ?
> > + size_t   count;
> > + size_t   total_count;
> > + struct mutex axlf_lock;
> > + int  reader_ref;
> > + enum fpga_mgr_states state;
> > + enum xfpga_sec_level sec_level;
> This appears unused, do you want to add this with the code that uses it?

This hook is for validating signature of FPGA image. Will look into adding it
into the next version of the patch.

> > +};
>
> Maybe add some kerneldoc markup?

Will do in the next version

> > +
> > +struct key *xfpga_keys;
> Appears unused, can you introduce this together with the code using it?
> > +
> > +static int xmgmt_pr_write_init(struct fpga_manager *mgr,
> > + struct fpga_image_info *info, const char *buf, size_t count)
> > +{
> > + struct xfpga_klass *obj = mgr->priv;
> > + const struct axlf *bin = (const struct axlf *)buf;
> Nit: Reverse x-mas tree please.
>
> xx
> 
> xxx
> x

Will update in the next version

> > +
> > + if (count < sizeof(struct axlf)) {
> > + obj->state = FPGA_MGR_STATE_WRITE_INIT_ERR;
> > + return -EINVAL;
> > + }
> > +
> > + if (count > bin->m_header.m_length) {
> > + obj->state = FPGA_MGR_STATE_WRITE_INIT_ERR;
> > + return -EINVAL;
> > + }
> > +
> > + /* Free up the previous blob */
> > + vfree(obj->blob);
> > + obj->blob = vmalloc(bin->m_header.m_length);
> > + if (!obj->blob) {
> > + obj->state = FPGA_MGR_STATE_WRITE_INIT_ERR;
> > + return -ENOMEM;
> > + }
> > +
> > + xrt_info(obj->pdev, "Begin download of xclbin %pUb of length %lld B",
> > + >m_header.uuid, bin->m_header.m_length);
> We already have framework level prints for that 

[PATCH 1/8] Documentation: HID: hid-alps editing & corrections

[Randy Dunlap]

Do basic editing & correction to hid-alps.rst:
- fix grammar
- fix punctuation spacing


Signed-off-by: Randy Dunlap 
Cc: Jiri Kosina 
Cc: Benjamin Tissoires 
Cc: linux-in...@vger.kernel.org
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
---
 Documentation/hid/hid-alps.rst |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- linux-next-20201201.orig/Documentation/hid/hid-alps.rst
+++ linux-next-20201201/Documentation/hid/hid-alps.rst
@@ -64,7 +64,7 @@ Case2 ReportID_3  TP  Absolute
 
 Command Read/Write
 --
-To read/write to RAM, need to send a commands to the device.
+To read/write to RAM, need to send a command to the device.
 
 The command format is as below.
 
@@ -80,7 +80,7 @@ Byte6 Value Byte
 Byte7  Checksum
 =  ==
 
-Command Byte is read=0xD1/write=0xD2 .
+Command Byte is read=0xD1/write=0xD2.
 
 Address is read/write RAM address.
 

[PATCH 7/8] Documentation: HID: hid-transport editing & corrections

[Randy Dunlap]

Do basic editing & correction to hid-transport.rst:
- s/responsible of/responsible for/
- fix grammar & punctuation


Signed-off-by: Randy Dunlap 
Cc: Jiri Kosina 
Cc: Benjamin Tissoires 
Cc: linux-in...@vger.kernel.org
Cc: David Herrmann 
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
---
 Documentation/hid/hid-transport.rst |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

--- linux-next-20201201.orig/Documentation/hid/hid-transport.rst
+++ linux-next-20201201/Documentation/hid/hid-transport.rst
@@ -12,8 +12,8 @@ Bluetooth, I2C and user-space I/O driver
 
 The HID subsystem is designed as a bus. Any I/O subsystem may provide HID
 devices and register them with the HID bus. HID core then loads generic device
-drivers on top of it. The transport drivers are responsible of raw data
-transport and device setup/management. HID core is responsible of
+drivers on top of it. The transport drivers are responsible for raw data
+transport and device setup/management. HID core is responsible for
 report-parsing, report interpretation and the user-space API. Device specifics
 and quirks are handled by all layers depending on the quirk.
 
@@ -67,7 +67,7 @@ Transport drivers attach a constant "str
 device. Once a device is registered with HID core, the callbacks provided via
 this struct are used by HID core to communicate with the device.
 
-Transport drivers are responsible of detecting device failures and unplugging.
+Transport drivers are responsible for detecting device failures and unplugging.
 HID core will operate a device as long as it is registered regardless of any
 device failures. Once transport drivers detect unplug or failure events, they
 must unregister the device from HID core and HID core will stop using the
@@ -101,7 +101,7 @@ properties in common.
channel. Any unrequested incoming or outgoing data report must be sent on
this channel and is never acknowledged by the remote side. Devices usually
send their input events on this channel. Outgoing events are normally
-   not send via intr, except if high throughput is required.
+   not sent via intr, except if high throughput is required.
  - Control Channel (ctrl): The ctrl channel is used for synchronous requests 
and
device management. Unrequested data input events must not be sent on this
channel and are normally ignored. Instead, devices only send management
@@ -161,7 +161,7 @@ allowed on the intr channel and are the
payload may be blocked by the underlying transport driver if the
specification does not allow them.
  - SET_REPORT: A SET_REPORT request has a report ID plus data as payload. It is
-   sent from host to device and a device must update it's current report state
+   sent from host to device and a device must update its current report state
according to the given data. Any of the 3 report types can be used. However,
INPUT reports as payload might be blocked by the underlying transport driver
if the specification does not allow them.
@@ -294,7 +294,7 @@ The available HID callbacks are:
   void (*request) (struct hid_device *hdev, struct hid_report *report,
   int reqtype)
 
-   Send an HID request on the ctrl channel. "report" contains the report that
+   Send a HID request on the ctrl channel. "report" contains the report that
should be sent and "reqtype" the request type. Request-type can be
HID_REQ_SET_REPORT or HID_REQ_GET_REPORT.
 

[PATCH 5/8] Documentation: HID: hidraw editing & corrections

[Randy Dunlap]

Do basic editing & correction to hidraw.rst:
- use "hidraw" consistently except at the beginning of a sentence
- add archive.org URL for signal11.us since the latter seems to be MIA
- use a list for 2 URLs so that they don't run together


Signed-off-by: Randy Dunlap 
Cc: Jiri Kosina 
Cc: Benjamin Tissoires 
Cc: linux-in...@vger.kernel.org
Cc: Alan Ott 
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
---
 Documentation/hid/hidraw.rst |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- linux-next-20201201.orig/Documentation/hid/hidraw.rst
+++ linux-next-20201201/Documentation/hid/hidraw.rst
@@ -21,7 +21,7 @@ Hidraw is the only alternative, short of
 these non-conformant devices.
 
 A benefit of hidraw is that its use by userspace applications is independent
-of the underlying hardware type.  Currently, Hidraw is implemented for USB
+of the underlying hardware type.  Currently, hidraw is implemented for USB
 and Bluetooth.  In the future, as new hardware bus types are developed which
 use the HID specification, hidraw will be expanded to add support for these
 new bus types.
@@ -31,9 +31,10 @@ create hidraw device nodes.  Udev will t
 directly under /dev (eg: /dev/hidraw0).  As this location is distribution-
 and udev rule-dependent, applications should use libudev to locate hidraw
 devices attached to the system.  There is a tutorial on libudev with a
-working example at:
+working example at::
 
http://www.signal11.us/oss/udev/
+   https://web.archive.org/web/2019*/www.signal11.us
 
 The HIDRAW API
 ---

[PATCH 8/8] Documentation: HID: uhid editing & corrections

[Randy Dunlap]

Do basic editing & correction to hid-alps.rst:
- correct a file name (.txt -> .rst)
- use less hyphenation when not needed
- fix grammar & punctuation
- fix article adjectives
- fix typos/spellos
- use HID instead of hid consistently


Signed-off-by: Randy Dunlap 
Cc: Jiri Kosina 
Cc: Benjamin Tissoires 
Cc: linux-in...@vger.kernel.org
Cc: David Herrmann 
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
---
 Documentation/hid/uhid.rst |   34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

--- linux-next-20201201.orig/Documentation/hid/uhid.rst
+++ linux-next-20201201/Documentation/hid/uhid.rst
@@ -3,7 +3,7 @@ UHID - User-space I/O driver support for
 ==
 
 UHID allows user-space to implement HID transport drivers. Please see
-hid-transport.txt for an introduction into HID transport drivers. This document
+hid-transport.rst for an introduction into HID transport drivers. This document
 relies heavily on the definitions declared there.
 
 With UHID, a user-space transport driver can create kernel hid-devices for each
@@ -15,7 +15,7 @@ There is an example user-space applicati
 The UHID API
 
 
-UHID is accessed through a character misc-device. The minor-number is allocated
+UHID is accessed through a character misc-device. The minor number is allocated
 dynamically so you need to rely on udev (or similar) to create the device node.
 This is /dev/uhid by default.
 
@@ -45,23 +45,23 @@ The "type" field defines the payload. Fo
 payload-structure available in the union "u" (except for empty payloads). This
 payload contains management and/or device data.
 
-The first thing you should do is sending an UHID_CREATE2 event. This will
-register the device. UHID will respond with an UHID_START event. You can now
+The first thing you should do is send a UHID_CREATE2 event. This will
+register the device. UHID will respond with a UHID_START event. You can now
 start sending data to and reading data from UHID. However, unless UHID sends 
the
 UHID_OPEN event, the internally attached HID Device Driver has no user 
attached.
 That is, you might put your device asleep unless you receive the UHID_OPEN
 event. If you receive the UHID_OPEN event, you should start I/O. If the last
-user closes the HID device, you will receive an UHID_CLOSE event. This may be
-followed by an UHID_OPEN event again and so on. There is no need to perform
+user closes the HID device, you will receive a UHID_CLOSE event. This may be
+followed by a UHID_OPEN event again and so on. There is no need to perform
 reference-counting in user-space. That is, you will never receive multiple
-UHID_OPEN events without an UHID_CLOSE event. The HID subsystem performs
+UHID_OPEN events without a UHID_CLOSE event. The HID subsystem performs
 ref-counting for you.
 You may decide to ignore UHID_OPEN/UHID_CLOSE, though. I/O is allowed even
 though the device may have no users.
 
 If you want to send data on the interrupt channel to the HID subsystem, you 
send
-an HID_INPUT2 event with your raw data payload. If the kernel wants to send 
data
-on the interrupt channel to the device, you will read an UHID_OUTPUT event.
+a HID_INPUT2 event with your raw data payload. If the kernel wants to send data
+on the interrupt channel to the device, you will read a UHID_OUTPUT event.
 Data requests on the control channel are currently limited to GET_REPORT and
 SET_REPORT (no other data reports on the control channel are defined so far).
 Those requests are always synchronous. That means, the kernel sends
@@ -71,7 +71,7 @@ the response via UHID_GET_REPORT_REPLY a
 The kernel blocks internal driver-execution during such round-trips (times out
 after a hard-coded period).
 
-If your device disconnects, you should send an UHID_DESTROY event. This will
+If your device disconnects, you should send a UHID_DESTROY event. This will
 unregister the device. You can now send UHID_CREATE2 again to register a new
 device.
 If you close() the fd, the device is automatically unregistered and destroyed
@@ -125,7 +125,7 @@ UHID_START:
   This is sent when the HID device is started. Consider this as an answer to
   UHID_CREATE2. This is always the first event that is sent. Note that this
   event might not be available immediately after write(UHID_CREATE2) returns.
-  Device drivers might required delayed setups.
+  Device drivers might require delayed setups.
   This event contains a payload of type uhid_start_req. The "dev_flags" field
   describes special behaviors of a device. The following flags are defined:
 
@@ -149,7 +149,7 @@ UHID_STOP:
   reloaded/changed the device driver loaded on your HID device (or some other
   maintenance actions happened).
 
-  You can usually ignored any UHID_STOP events safely.
+  You can usually ignore any UHID_STOP events safely.
 
 UHID_OPEN:
   This is sent when the HID device is opened. That is, the data that the HID
@@ -166,17 +166,17 @@ UHID_OUTPUT:
 

[PATCH 6/8] Documentation: HID: hid-sensor editing & corrections

[Randy Dunlap]

Do basic editing & correction to hid-sensor.rst:
- use HID consistently instead of hid
- drop a duplicate word
- change article adjective an -> a
- fix grammar & punctuation
- spell out RW -> read-write
- hyphenate multi-word adjectives


Signed-off-by: Randy Dunlap 
Cc: Jiri Kosina 
Cc: Jonathan Cameron 
Cc: Srinivas Pandruvada 
Cc: linux-in...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
---
 Documentation/hid/hid-sensor.rst |   18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

--- linux-next-20201201.orig/Documentation/hid/hid-sensor.rst
+++ linux-next-20201201/Documentation/hid/hid-sensor.rst
@@ -48,12 +48,12 @@ for different sensors. For example an ac
 an ambient light sensor can send illumination data.
 So the implementation has two parts:
 
-- Core hid driver
+- Core HID driver
 - Individual sensor processing part (sensor drivers)
 
 Core driver
 ---
-The core driver registers (hid-sensor-hub) registers as a HID driver. It parses
+The core driver (hid-sensor-hub) registers as a HID driver. It parses
 report descriptors and identifies all the sensors present. It adds an MFD 
device
 with name HID-SENSOR- (where  is usage id from the specification).
 
@@ -95,14 +95,14 @@ Registration functions::
u32 usage_id,
struct hid_sensor_hub_callbacks *usage_callback):
 
-Registers callbacks for an usage id. The callback functions are not allowed
+Registers callbacks for a usage id. The callback functions are not allowed
 to sleep::
 
 
   int sensor_hub_remove_callback(struct hid_sensor_hub_device *hsdev,
u32 usage_id):
 
-Removes callbacks for an usage id.
+Removes callbacks for a usage id.
 
 
 Parsing function::
@@ -166,7 +166,7 @@ This allows some differentiating use cas
 Some common use cases are debug other sensors or to provide some events like
 keyboard attached/detached or lid open/close.
 
-To allow application to utilize these sensors, here they are exported uses 
sysfs
+To allow application to utilize these sensors, here they are exported using 
sysfs
 attribute groups, attributes and misc device interface.
 
 An example of this representation on sysfs::
@@ -207,9 +207,9 @@ An example of this representation on sys
   │   │   │   ├── input-1-200202-units
   │   │   │   ├── input-1-200202-value
 
-Here there is a custom sensors with four fields, two feature and two inputs.
+Here there is a custom sensor with four fields: two feature and two inputs.
 Each field is represented by a set of attributes. All fields except the "value"
-are read only. The value field is a RW field.
+are read only. The value field is a read-write field.
 
 Example::
 
@@ -237,6 +237,6 @@ These reports are pushed using misc devi
│   │   │   ├── 10:53 -> ../HID-SENSOR-2000e1.6.auto
│   ├──  HID-SENSOR-2000e1.6.auto
 
-Each reports can be of variable length preceded by a header. This header
-consist of a 32 bit usage id, 64 bit time stamp and 32 bit length field of raw
+Each report can be of variable length preceded by a header. This header
+consists of a 32-bit usage id, 64-bit time stamp and 32-bit length field of raw
 data.

[PATCH 4/8] Documentation: HID: intel-ish-hid editing & corrections

[Randy Dunlap]

Do basic editing & correction to intel-ish-hid.rst:
- fix grammar, verb tense, punctutation, and word phrasing
- fix spellos
- hyphenate multi-word adjectives
- collapse 2 spaces to one space in the middle of sentences
- use "I2C" instead of lower-case letters (as Linux I2C does)
- change space indentation to tab
- use HID instead of hid consistently
- use a list so that some line items do not run together
- use "a UUID" instead of "an UUID"


Signed-off-by: Randy Dunlap 
Cc: Jiri Kosina 
Cc: Jonathan Cameron 
Cc: Srinivas Pandruvada 
Cc: linux-in...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
---
 Documentation/hid/intel-ish-hid.rst |   74 +-
 1 file changed, 38 insertions(+), 36 deletions(-)

--- linux-next-20201201.orig/Documentation/hid/intel-ish-hid.rst
+++ linux-next-20201201/Documentation/hid/intel-ish-hid.rst
@@ -4,19 +4,19 @@ Intel Integrated Sensor Hub (ISH)
 
 A sensor hub enables the ability to offload sensor polling and algorithm
 processing to a dedicated low power co-processor. This allows the core
-processor to go into low power modes more often, resulting in the increased
+processor to go into low power modes more often, resulting in increased
 battery life.
 
-There are many vendors providing external sensor hubs confirming to HID
-Sensor usage tables, and used in several tablets, 2 in 1 convertible laptops
+There are many vendors providing external sensor hubs conforming to HID
+Sensor usage tables, and used in several tablets, 2-in-1 convertible laptops
 and embedded products. Linux had this support since Linux 3.9.
 
 Intel® introduced integrated sensor hubs as a part of the SoC starting from
 Cherry Trail and now supported on multiple generations of CPU packages. There
 are many commercial devices already shipped with Integrated Sensor Hubs (ISH).
-These ISH also comply to HID sensor specification, but the  difference is the
+These ISH also comply to HID sensor specification, but the difference is the
 transport protocol used for communication. The current external sensor hubs
-mainly use HID over i2C or USB. But ISH doesn't use either i2c or USB.
+mainly use HID over I2C or USB. But ISH doesn't use either I2C or USB.
 
 1. Overview
 ===
@@ -35,7 +35,7 @@ for a very high speed communication::
-   --
  PCIPCI
-   --
-|Host controller|  --> |ISH processor   |
+   |Host controller|   --> |ISH processor   |
-   --
 USB Link
-   --
@@ -50,13 +50,13 @@ applications implemented in the firmware
 The ISH allows multiple sensor management applications executing in the
 firmware. Like USB endpoints the messaging can be to/from a client. As part of
 enumeration process, these clients are identified. These clients can be simple
-HID sensor applications, sensor calibration application or senor firmware
+HID sensor applications, sensor calibration application or sensor firmware
 update application.
 
 The implementation model is similar, like USB bus, ISH transport is also
 implemented as a bus. Each client application executing in the ISH processor
 is registered as a device on this bus. The driver, which binds each device
-(ISH HID driver) identifies the device type and registers with the hid core.
+(ISH HID driver) identifies the device type and registers with the HID core.
 
 2. ISH Implementation: Block Diagram
 
@@ -104,7 +104,7 @@ is registered as a device on this bus. T
 
 The ISH is exposed as "Non-VGA unclassified PCI device" to the host. The PCI
 product and vendor IDs are changed from different generations of processors. So
-the source code which enumerate drivers needs to update from generation to
+the source code which enumerates drivers needs to update from generation to
 generation.
 
 3.2 Inter Processor Communication (IPC) driver
@@ -112,41 +112,42 @@ generation.
 
 Location: drivers/hid/intel-ish-hid/ipc
 
-The IPC message used memory mapped I/O. The registers are defined in
+The IPC message uses memory mapped I/O. The registers are defined in
 hw-ish-regs.h.
 
 3.2.1 IPC/FW message types
 ^^
 
-There are two types of messages, one for management of link and other messages
-are to and from transport layers.
+There are two types of messages, one for management of link and another for
+messages to and from transport layers.
 
 TX and RX of Transport messages
 ...
 
-A set of memory mapped register offers support of multi byte messages TX and
-RX (E.g.IPC_REG_ISH2HOST_MSG, IPC_REG_HOST2ISH_MSG). The IPC layer maintains
-internal queues to sequence messages and send them in order to the FW.
+A set of 

[PATCH 2/8] Documentation: HID: amd-sfh-hid editing & corrections

[Randy Dunlap]

Do basic editing & correction to amd-sfh-hid.rst:
- fix punctuation
- use HID instead of hid consistently
- fix grammar, verb tense

Signed-off-by: Randy Dunlap 
Cc: Jiri Kosina 
Cc: Jonathan Cameron 
Cc: Srinivas Pandruvada 
Cc: linux-in...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
---
 Documentation/hid/amd-sfh-hid.rst |   16 
 1 file changed, 8 insertions(+), 8 deletions(-)

--- linux-next-20201201.orig/Documentation/hid/amd-sfh-hid.rst
+++ linux-next-20201201/Documentation/hid/amd-sfh-hid.rst
@@ -3,7 +3,7 @@
 
 AMD Sensor Fusion Hub
 =
-AMD Sensor Fusion Hub (SFH) is part of an SOC starting from Ryzen based 
platforms.
+AMD Sensor Fusion Hub (SFH) is part of an SOC starting from Ryzen-based 
platforms.
 The solution is working well on several OEM products. AMD SFH uses HID over 
PCIe bus.
 In terms of architecture it resembles ISH, however the major difference is all
 the HID reports are generated as part of the kernel driver.
@@ -45,20 +45,20 @@ the HID reports are generated as part of
 AMD HID Transport Layer
 ---
 AMD SFH transport is also implemented as a bus. Each client application 
executing in the AMD MP2 is
-registered as a device on this bus. Here: MP2 which is an ARM core connected 
to x86 for processing
+registered as a device on this bus. Here, MP2 is an ARM core connected to x86 
for processing
 sensor data. The layer, which binds each device (AMD SFH HID driver) 
identifies the device type and
-registers with the hid core. Transport layer attach a constant "struct 
hid_ll_driver" object with
+registers with the HID core. Transport layer attaches a constant "struct 
hid_ll_driver" object with
 each device. Once a device is registered with HID core, the callbacks provided 
via this struct are
 used by HID core to communicate with the device. AMD HID Transport layer 
implements the synchronous calls.
 
 AMD HID Client Layer
 
-This layer is responsible to implement HID request and descriptors. As 
firmware is OS agnostic, HID
+This layer is responsible to implement HID requests and descriptors. As 
firmware is OS agnostic, HID
 client layer fills the HID request structure and descriptors. HID client layer 
is complex as it is
-interface between MP2 PCIe layer and HID. HID client layer initialized the MP2 
PCIe layer and holds
+interface between MP2 PCIe layer and HID. HID client layer initializes the MP2 
PCIe layer and holds
 the instance of MP2 layer. It identifies the number of sensors connected using 
MP2-PCIe layer. Base
-on that allocates the DRAM address for each and every sensor and pass it to 
MP2-PCIe driver.On
-enumeration of each the sensor, client layer fills the HID Descriptor 
structure and HID input repor
+on that allocates the DRAM address for each and every sensor and passes it to 
MP2-PCIe driver. On
+enumeration of each sensor, client layer fills the HID Descriptor structure 
and HID input report
 structure. HID Feature report structure is optional. The report descriptor 
structure varies from
 sensor to sensor.
 
@@ -72,7 +72,7 @@ The communication between X86 and MP2 is
 2. Data transfer via DRAM.
 3. Supported sensor info via P2C registers.
 
-Commands are sent to MP2 using C2P Mailbox registers. Writing into C2P Message 
registers generate
+Commands are sent to MP2 using C2P Mailbox registers. Writing into C2P Message 
registers generates
 interrupt to MP2. The client layer allocates the physical memory and the same 
is sent to MP2 via
 the PCI layer. MP2 firmware writes the command output to the access DRAM 
memory which the client
 layer has allocated. Firmware always writes minimum of 32 bytes into DRAM. So 
as a protocol driver

[PATCH 0/8] Documentation: HID: edit/correct all files

[Randy Dunlap]

Make editing corrections to all files in Documentation/hid/.

Cc: Jiri Kosina 
Cc: Benjamin Tissoires 
Cc: linux-in...@vger.kernel.org
Cc: Jonathan Cameron 
Cc: Srinivas Pandruvada 
Cc: linux-...@vger.kernel.org
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org

 [PATCH 1/8] Documentation: HID: hid-alps editing & corrections
 [PATCH 2/8] Documentation: HID: amd-sfh-hid editing & corrections
 [PATCH 3/8] Documentation: HID: hiddev editing & corrections
 [PATCH 4/8] Documentation: HID: intel-ish-hid editing & corrections
 [PATCH 5/8] Documentation: HID: hidraw editing & corrections
 [PATCH 6/8] Documentation: HID: hid-sensor editing & corrections
 [PATCH 7/8] Documentation: HID: hid-transport editing & corrections
 [PATCH 8/8] Documentation: HID: uhid editing & corrections

 Documentation/hid/amd-sfh-hid.rst   |   16 ++---
 Documentation/hid/hid-alps.rst  |4 -
 Documentation/hid/hid-sensor.rst|   18 +++---
 Documentation/hid/hid-transport.rst |   12 ++--
 Documentation/hid/hiddev.rst|   12 ++--
 Documentation/hid/hidraw.rst|5 +
 Documentation/hid/intel-ish-hid.rst |   74 +-
 Documentation/hid/uhid.rst  |   34 +--
 8 files changed, 89 insertions(+), 86 deletions(-)

[PATCH 3/8] Documentation: HID: hiddev editing & corrections

[Randy Dunlap]

Do basic editing & correction to hiddev.rst:
- use HID instead of hid consistently
- add hyphenation of multi-word adjectives
- drop a duplicate word
- unhyphenate "a priori"


Signed-off-by: Randy Dunlap 
Cc: Jiri Kosina 
Cc: Benjamin Tissoires 
Cc: linux-in...@vger.kernel.org
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
---
 Documentation/hid/hiddev.rst |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

--- linux-next-20201201.orig/Documentation/hid/hiddev.rst
+++ linux-next-20201201/Documentation/hid/hiddev.rst
@@ -27,7 +27,7 @@ the following::
   --> hiddev.c > POWER / MONITOR CONTROL
 
 In addition, other subsystems (apart from USB) can potentially feed
-events into the input subsystem, but these have no effect on the hid
+events into the input subsystem, but these have no effect on the HID
 device interface.
 
 Using the HID Device Interface
@@ -72,8 +72,8 @@ The hiddev API uses a read() interface,
 
 HID devices exchange data with the host computer using data
 bundles called "reports".  Each report is divided into "fields",
-each of which can have one or more "usages".  In the hid-core,
-each one of these usages has a single signed 32 bit value.
+each of which can have one or more "usages".  In the HID core,
+each one of these usages has a single signed 32-bit value.
 
 read():
 ---
@@ -113,7 +113,7 @@ HIDIOCAPPLICATION
   - (none)
 
 This ioctl call returns the HID application usage associated with the
-hid device. The third argument to ioctl() specifies which application
+HID device. The third argument to ioctl() specifies which application
 index to get. This is useful when the device has more than one
 application collection. If the index is invalid (greater or equal to
 the number of application collections this device has) the ioctl
@@ -181,7 +181,7 @@ looked up by type (input, output or feat
 must be filled in by the user. The ID can be absolute -- the actual
 report id as reported by the device -- or relative --
 HID_REPORT_ID_FIRST for the first report, and (HID_REPORT_ID_NEXT |
-report_id) for the next report after report_id. Without a-priori
+report_id) for the next report after report_id. Without a priori
 information about report ids, the right way to use this ioctl is to
 use the relative IDs above to enumerate the valid IDs. The ioctl
 returns non-zero when there is no more next ID. The real report ID is
@@ -200,7 +200,7 @@ HIDIOCGUCODE
   - struct hiddev_usage_ref (read/write)
 
 Returns the usage_code in a hiddev_usage_ref structure, given that
-given its report type, report id, field index, and index within the
+its report type, report id, field index, and index within the
 field have already been filled into the structure.
 
 HIDIOCGUSAGE

RE: [PATCH] drm/amdgpu: fix debugfs creation/removal, again

[Zhou1, Tao]

[AMD Public Use]

Reviewed-by: Tao Zhou 

> -Original Message-
> From: Arnd Bergmann 
> Sent: Friday, December 4, 2020 7:07 AM
> To: Deucher, Alexander ; Koenig, Christian
> ; David Airlie ; Daniel Vetter
> ; Li, Dennis ; Zhou1, Tao
> ; Chen, Guchun 
> Cc: Arnd Bergmann ; Zhang, Hawking
> ; Clements, John ;
> Yang, Stanley ; Ma, Le ; amd-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH] drm/amdgpu: fix debugfs creation/removal, again
> 
> From: Arnd Bergmann 
> 
> There is still a warning when CONFIG_DEBUG_FS is disabled:
> 
> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1145:13: error:
> 'amdgpu_ras_debugfs_create_ctrl_node' defined but not used [-
> Werror=unused-function]
>  1145 | static void amdgpu_ras_debugfs_create_ctrl_node(struct
> amdgpu_device *adev)
> 
> Change the code again to make the compiler actually drop this code but not
> warn about it.
> 
> Fixes: ae2bf61ff39e ("drm/amdgpu: guard ras debugfs creation/removal based
> on CONFIG_DEBUG_FS")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 13 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h |  6 --
>  2 files changed, 5 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> index 9d11b847e6ef..c136bd449744 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> @@ -1167,7 +1167,7 @@ static void
> amdgpu_ras_debugfs_create_ctrl_node(struct amdgpu_device *adev)
>   con->dir, >disable_ras_err_cnt_harvest);
>  }
> 
> -void amdgpu_ras_debugfs_create(struct amdgpu_device *adev,
> +static void amdgpu_ras_debugfs_create(struct amdgpu_device *adev,
>   struct ras_fs_if *head)
>  {
>   struct amdgpu_ras *con = amdgpu_ras_get_context(adev); @@ -1189,7
> +1189,6 @@ void amdgpu_ras_debugfs_create(struct amdgpu_device *adev,
> 
>  void amdgpu_ras_debugfs_create_all(struct amdgpu_device *adev)  { -#if
> defined(CONFIG_DEBUG_FS)
>   struct amdgpu_ras *con = amdgpu_ras_get_context(adev);
>   struct ras_manager *obj;
>   struct ras_fs_if fs_info;
> @@ -1198,7 +1197,7 @@ void amdgpu_ras_debugfs_create_all(struct
> amdgpu_device *adev)
>* it won't be called in resume path, no need to check
>* suspend and gpu reset status
>*/
> - if (!con)
> + if (!IS_ENABLED(CONFIG_DEBUG_FS) || !con)
>   return;
> 
>   amdgpu_ras_debugfs_create_ctrl_node(adev);
> @@ -1212,10 +1211,9 @@ void amdgpu_ras_debugfs_create_all(struct
> amdgpu_device *adev)
>   amdgpu_ras_debugfs_create(adev, _info);
>   }
>   }
> -#endif
>  }
> 
> -void amdgpu_ras_debugfs_remove(struct amdgpu_device *adev,
> +static void amdgpu_ras_debugfs_remove(struct amdgpu_device *adev,
>   struct ras_common_if *head)
>  {
>   struct ras_manager *obj = amdgpu_ras_find_obj(adev, head); @@ -
> 1229,7 +1227,6 @@ void amdgpu_ras_debugfs_remove(struct amdgpu_device
> *adev,
> 
>  static void amdgpu_ras_debugfs_remove_all(struct amdgpu_device *adev)  { -
> #if defined(CONFIG_DEBUG_FS)
>   struct amdgpu_ras *con = amdgpu_ras_get_context(adev);
>   struct ras_manager *obj, *tmp;
> 
> @@ -1238,7 +1235,6 @@ static void amdgpu_ras_debugfs_remove_all(struct
> amdgpu_device *adev)
>   }
> 
>   con->dir = NULL;
> -#endif
>  }
>  /* debugfs end */
> 
> @@ -1286,7 +1282,8 @@ static int amdgpu_ras_fs_init(struct amdgpu_device
> *adev)
> 
>  static int amdgpu_ras_fs_fini(struct amdgpu_device *adev)  {
> - amdgpu_ras_debugfs_remove_all(adev);
> + if (IS_ENABLED(CONFIG_DEBUG_FS))
> + amdgpu_ras_debugfs_remove_all(adev);
>   amdgpu_ras_sysfs_remove_all(adev);
>   return 0;
>  }
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
> index 4667cce38582..762f5e46c007 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h
> @@ -592,14 +592,8 @@ int amdgpu_ras_sysfs_create(struct amdgpu_device
> *adev,  int amdgpu_ras_sysfs_remove(struct amdgpu_device *adev,
>   struct ras_common_if *head);
> 
> -void amdgpu_ras_debugfs_create(struct amdgpu_device *adev,
> - struct ras_fs_if *head);
> -
>  void amdgpu_ras_debugfs_create_all(struct amdgpu_device *adev);
> 
> -void amdgpu_ras_debugfs_remove(struct amdgpu_device *adev,
> - struct ras_common_if *head);
> -
>  int amdgpu_ras_error_query(struct amdgpu_device *adev,
>   struct ras_query_if *info);
> 
> --
> 2.27.0

Re: [PATCH next v2 1/3] printk: inline log_output(),log_store() in vprintk_store()

[Sergey Senozhatsky]

On (20/12/03 17:31), John Ogness wrote:
[..]
> >> +  if (!prb_reserve(, prb, )) {
> >> +  /* truncate the message if it is too long for empty buffer */
> >> +  truncate_msg(_len, _msg_len);
> >> +
> >> +  prb_rec_init_wr(, text_len + trunc_msg_len);
> >> +  if (!prb_reserve(, prb, ))
> >> +  return 0;
> >> +  }
> >> +
> >> +  /* fill message */
> >> +  memcpy(_buf[0], text, text_len);
> >> +  if (trunc_msg_len)
> >> +  memcpy(_buf[text_len], trunc_msg, trunc_msg_len);
> >> +  r.info->text_len = text_len + trunc_msg_len;
> >> +  r.info->facility = facility;
> >> +  r.info->level = level & 7;
> >> +  r.info->flags = lflags & 0x1f;
> >> +  r.info->ts_nsec = ts_nsec;
> >
> > This is the only location where ts_nsec is used. I would remove the
> > variable and call:
> >
> > r.info->ts_nsec = local_clock();
> 
> My reason for grabbing the clock at the beginning is so that the
> timestamp is as close to the printk() call as possible. IMHO it is a
> more deterministic timestamp than if it is taken after reservation(s)
> and sprint'ing. I prefer to keep it as it is, but will not object if
> such a change is necessary for mailine acceptance.

Sounds reasonable

Reviewed-by: Sergey Senozhatsky 

-ss

[PATCH v2 2/2] perf-stat: enable counting events for BPF programs

[Song Liu]

Introduce perf-stat -b option, which counts events for BPF programs, like:

[root@localhost ~]# ~/perf stat -e ref-cycles,cycles -b 254 -I 1000
 1.487903822115,200  ref-cycles
 1.487903822 86,012  cycles
 2.489147029 80,560  ref-cycles
 2.489147029 73,784  cycles
 3.490341825 60,720  ref-cycles
 3.490341825 37,797  cycles
 4.491540887 37,120  ref-cycles
 4.491540887 31,963  cycles

The example above counts cycles and ref-cycles of BPF program of id 254.
This is similar to bpftool-prog-profile command, but more flexible.

perf-stat -b creates per-cpu perf_event and loads fentry/fexit BPF
programs (monitor-progs) to the target BPF program (target-prog). The
monitor-progs read perf_event before and after the target-prog, and
aggregate the difference in a BPF map. Then the user space reads data
from these maps.

A new struct bpf_counter is introduced to provide common interface that
uses BPF programs/maps to count perf events.

Signed-off-by: Song Liu 
---
 tools/perf/Makefile.perf  |   2 +-
 tools/perf/builtin-stat.c |  77 -
 tools/perf/util/Build |   1 +
 tools/perf/util/bpf_counter.c | 281 ++
 tools/perf/util/bpf_counter.h |  73 +
 .../util/bpf_skel/bpf_prog_profiler.bpf.c |  96 ++
 tools/perf/util/evsel.c   |  11 +
 tools/perf/util/evsel.h   |   6 +
 tools/perf/util/stat-display.c|   4 +-
 tools/perf/util/target.c  |  34 ++-
 tools/perf/util/target.h  |  10 +
 11 files changed, 578 insertions(+), 17 deletions(-)
 create mode 100644 tools/perf/util/bpf_counter.c
 create mode 100644 tools/perf/util/bpf_counter.h
 create mode 100644 tools/perf/util/bpf_skel/bpf_prog_profiler.bpf.c

diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index a272bfb60a579..fb7de412152b5 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -1015,7 +1015,7 @@ python-clean:
 
 SKEL_OUT := $(abspath $(OUTPUT)util/bpf_skel)
 SKEL_TMP_OUT := $(abspath $(SKEL_OUT)/.tmp)
-SKELETONS :=
+SKELETONS := $(SKEL_OUT)/bpf_prog_profiler.skel.h
 
 ifdef BUILD_BPF_SKEL
 BPFTOOL := $(SKEL_TMP_OUT)/bpftool-bootstrap
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index f15b2f8aa14d8..a71684446a0e1 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -67,6 +67,7 @@
 #include "util/top.h"
 #include "util/affinity.h"
 #include "util/pfm.h"
+#include "util/bpf_counter.h"
 #include "asm/bug.h"
 
 #include 
@@ -409,12 +410,31 @@ static int read_affinity_counters(struct timespec *rs)
return 0;
 }
 
+static int read_bpf_map_counters(void)
+{
+   struct evsel *counter;
+   int err;
+
+   evlist__for_each_entry(evsel_list, counter) {
+   err = bpf_counter__read(counter);
+   if (err)
+   return err;
+   }
+   return 0;
+}
+
 static void read_counters(struct timespec *rs)
 {
struct evsel *counter;
+   int err;
 
-   if (!stat_config.stop_read_counter && (read_affinity_counters(rs) < 0))
-   return;
+   if (!stat_config.stop_read_counter) {
+   err = read_bpf_map_counters();
+   if (err == -EAGAIN)
+   err = read_affinity_counters(rs);
+   if (err < 0)
+   return;
+   }
 
evlist__for_each_entry(evsel_list, counter) {
if (counter->err)
@@ -496,11 +516,20 @@ static bool handle_interval(unsigned int interval, int 
*times)
return false;
 }
 
-static void enable_counters(void)
+static int enable_counters(void)
 {
+   struct evsel *evsel;
+   int err;
+
+   evlist__for_each_entry(evsel_list, evsel) {
+   err = bpf_counter__enable(evsel);
+   if (err)
+   return err;
+   }
+
if (stat_config.initial_delay < 0) {
pr_info(EVLIST_DISABLED_MSG);
-   return;
+   return 0;
}
 
if (stat_config.initial_delay > 0) {
@@ -518,6 +547,7 @@ static void enable_counters(void)
if (stat_config.initial_delay > 0)
pr_info(EVLIST_ENABLED_MSG);
}
+   return 0;
 }
 
 static void disable_counters(void)
@@ -720,7 +750,7 @@ static int __run_perf_stat(int argc, const char **argv, int 
run_idx)
const bool forks = (argc > 0);
bool is_pipe = STAT_RECORD ? perf_stat.data.is_pipe : false;
struct affinity affinity;
-   int i, cpu;
+   int i, cpu, err;
bool second_pass = false;
 
if (forks) {
@@ -738,6 +768,11 @@ static int __run_perf_stat(int argc, const char **argv, 
int run_idx)
if (affinity__setup() < 0)
   

[PATCH v2 1/2] perf: support build BPF skeletons with perf

[Song Liu]

BPF programs are useful in perf to profile BPF programs. BPF skeleton is
by far the easiest way to write BPF tools. Enable building BPF skeletons
in util/bpf_skel. A dummy bpf skeleton is added. More bpf skeletons will
be added for different use cases.

Signed-off-by: Song Liu 
---
 tools/bpf/bpftool/Makefile  |  2 ++
 tools/build/Makefile.feature|  4 ++-
 tools/perf/Makefile.config  |  9 ++
 tools/perf/Makefile.perf| 44 +++--
 tools/perf/util/bpf_skel/.gitignore |  3 ++
 tools/scripts/Makefile.include  |  1 +
 6 files changed, 60 insertions(+), 3 deletions(-)
 create mode 100644 tools/perf/util/bpf_skel/.gitignore

diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
index f60e6ad3a1dff..a01407ec78dc5 100644
--- a/tools/bpf/bpftool/Makefile
+++ b/tools/bpf/bpftool/Makefile
@@ -120,6 +120,8 @@ endif
 
 BPFTOOL_BOOTSTRAP := $(if 
$(OUTPUT),$(OUTPUT)bpftool-bootstrap,./bpftool-bootstrap)
 
+bootstrap: $(BPFTOOL_BOOTSTRAP)
+
 BOOTSTRAP_OBJS = $(addprefix $(OUTPUT),main.o common.o json_writer.o gen.o 
btf.o)
 OBJS = $(patsubst %.c,$(OUTPUT)%.o,$(SRCS)) $(OUTPUT)disasm.o
 
diff --git a/tools/build/Makefile.feature b/tools/build/Makefile.feature
index 97cbfb31b7625..74e255d58d8d0 100644
--- a/tools/build/Makefile.feature
+++ b/tools/build/Makefile.feature
@@ -99,7 +99,9 @@ FEATURE_TESTS_EXTRA :=  \
  clang  \
  libbpf \
  libpfm4\
- libdebuginfod
+ libdebuginfod \
+ clang-bpf-co-re
+
 
 FEATURE_TESTS ?= $(FEATURE_TESTS_BASIC)
 
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index ce8516e4de34f..fe234b8bfeefb 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -621,6 +621,15 @@ ifndef NO_LIBBPF
   endif
 endif
 
+ifdef BUILD_BPF_SKEL
+  $(call feature_check,clang-bpf-co-re)
+  ifeq ($(feature-clang-bpf-co-re), 0)
+dummy := $(error Error: clang too old. Please install recent clang)
+  endif
+  $(call detected,CONFIG_PERF_BPF_SKEL)
+  CFLAGS += -DBUILD_BPF_SKEL
+endif
+
 dwarf-post-unwind := 1
 dwarf-post-unwind-text := BUG
 
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 7ce3f2e8b9c74..a272bfb60a579 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -126,6 +126,8 @@ include ../scripts/utilities.mak
 #
 # Define NO_LIBDEBUGINFOD if you do not want support debuginfod
 #
+# Define BUILD_BPF_SKEL to enable BPF skeletons
+#
 
 # As per kernel Makefile, avoid funny character set dependencies
 unexport LC_ALL
@@ -178,6 +180,8 @@ LD += $(EXTRA_LDFLAGS)
 HOSTCC  ?= gcc
 HOSTLD  ?= ld
 HOSTAR  ?= ar
+CLANG   ?= clang
+LLVM_STRIP ?= llvm-strip
 
 PKG_CONFIG = $(CROSS_COMPILE)pkg-config
 LLVM_CONFIG ?= llvm-config
@@ -735,7 +739,8 @@ prepare: $(OUTPUT)PERF-VERSION-FILE $(OUTPUT)common-cmds.h 
archheaders $(drm_ioc
$(x86_arch_prctl_code_array) \
$(rename_flags_array) \
$(arch_errno_name_array) \
-   $(sync_file_range_arrays)
+   $(sync_file_range_arrays) \
+   bpf-skel
 
 $(OUTPUT)%.o: %.c prepare FORCE
$(Q)$(MAKE) -f $(srctree)/tools/build/Makefile.build dir=$(build-dir) $@
@@ -1008,7 +1013,42 @@ config-clean:
 python-clean:
$(python-clean)
 
-clean:: $(LIBTRACEEVENT)-clean $(LIBAPI)-clean $(LIBBPF)-clean 
$(LIBSUBCMD)-clean $(LIBPERF)-clean config-clean fixdep-clean python-clean
+SKEL_OUT := $(abspath $(OUTPUT)util/bpf_skel)
+SKEL_TMP_OUT := $(abspath $(SKEL_OUT)/.tmp)
+SKELETONS :=
+
+ifdef BUILD_BPF_SKEL
+BPFTOOL := $(SKEL_TMP_OUT)/bpftool-bootstrap
+LIBBPF_SRC := $(abspath ../lib/bpf)
+BPF_INCLUDE := -I$(SKEL_TMP_OUT)/..
+
+$(SKEL_TMP_OUT):
+   $(Q)$(MKDIR) -p $@
+
+$(BPFTOOL): | $(SKEL_TMP_OUT)
+   CFLAGS= $(MAKE) -C ../bpf/bpftool \
+   OUTPUT=$(SKEL_TMP_OUT)/ bootstrap
+
+$(SKEL_TMP_OUT)/%.bpf.o: util/bpf_skel/%.bpf.c $(LIBBPF) | $(SKEL_TMP_OUT)
+   $(call QUIET_CLANG, $@)
+   $(Q)$(CLANG) -g -O2 -target bpf $(BPF_INCLUDE) -c $(filter 
util/bpf_skel/%.bpf.c,$^) \
+   -o $@ && $(LLVM_STRIP) -g $@
+
+$(SKEL_OUT)/%.skel.h: $(SKEL_TMP_OUT)/%.bpf.o | $(BPFTOOL)
+   $(QUIET_GENSKEL)$(BPFTOOL) gen skeleton $< > $@
+
+bpf-skel: $(SKELETONS)
+
+else # BUILD_BPF_SKEL
+
+bpf-skel:
+
+endif # BUILD_BPF_SKEL
+
+bpf-skel-clean:
+   $(call QUIET_CLEAN, bpf-skel) $(RM) -r $(SKEL_TMP_OUT) $(SKELETONS)
+
+clean:: $(LIBTRACEEVENT)-clean $(LIBAPI)-clean $(LIBBPF)-clean 
$(LIBSUBCMD)-clean $(LIBPERF)-clean config-clean fixdep-clean python-clean 
bpf-skel-clean
$(call QUIET_CLEAN, core-objs)  $(RM) $(LIBPERF_A) 
$(OUTPUT)perf-archive $(OUTPUT)perf-with-kcore $(LANG_BINDINGS)
$(Q)find $(if $(OUTPUT),$(OUTPUT),.) -name '*.o' -delete -o -name 
'\.*.cmd' -delete -o -name '\.*.d' -delete
$(Q)$(RM) $(OUTPUT).config-detected
diff --git a/tools/perf/util/bpf_skel/.gitignore 

[PATCH v2 0/2] Introduce perf-stat -b for BPF programs

[Song Liu]

This set introduces perf-stat -b option to count events for BPF programs.
This is similar to bpftool-prog-profile. But perf-stat makes it much more
flexible.

Changes PATCH v1 => PATCH v2:
  1. Various fixes in Makefiles. (Jiri)
  2. Fix an build warning/error with gcc-10. (Jiri)

Changes RFC v2 => PATCH v1:
  1. Support counting on multiple BPF programs.
  2. Add BPF handling to target__validate().
  3. Improve Makefile. (Jiri)

Changes RFC v1 => RFC v2:
  1. Use bootstrap version of bpftool. (Jiri)
  2. Set default to not building bpf skeletons. (Jiri)
  3. Remove util/bpf_skel/Makefile, keep all the logic in Makefile.perf.
 (Jiri)
  4. Remove dependency to vmlinux.h in the two skeletons. The goal here is
 to enable building perf without building kernel (vmlinux) first.
 Note: I also removed the logic that build vmlinux.h. We can add that
 back when we have to use it (to access big kernel structures).

Song Liu (2):
  perf: support build BPF skeletons with perf
  perf-stat: enable counting events for BPF programs

 tools/bpf/bpftool/Makefile|   2 +
 tools/build/Makefile.feature  |   4 +-
 tools/perf/Makefile.config|   9 +
 tools/perf/Makefile.perf  |  44 ++-
 tools/perf/builtin-stat.c |  77 -
 tools/perf/util/Build |   1 +
 tools/perf/util/bpf_counter.c | 281 ++
 tools/perf/util/bpf_counter.h |  73 +
 tools/perf/util/bpf_skel/.gitignore   |   3 +
 .../util/bpf_skel/bpf_prog_profiler.bpf.c |  96 ++
 tools/perf/util/evsel.c   |  11 +
 tools/perf/util/evsel.h   |   6 +
 tools/perf/util/stat-display.c|   4 +-
 tools/perf/util/target.c  |  34 ++-
 tools/perf/util/target.h  |  10 +
 tools/scripts/Makefile.include|   1 +
 16 files changed, 637 insertions(+), 19 deletions(-)
 create mode 100644 tools/perf/util/bpf_counter.c
 create mode 100644 tools/perf/util/bpf_counter.h
 create mode 100644 tools/perf/util/bpf_skel/.gitignore
 create mode 100644 tools/perf/util/bpf_skel/bpf_prog_profiler.bpf.c

--
2.24.1

Re: [PATCH v2 1/2] KVM: arm64: Some fixes of PV-time interface document

[zhukeqian]

On 2020/12/3 23:04, Marc Zyngier wrote:
> On 2020-08-17 12:07, Keqian Zhu wrote:
>> Rename PV_FEATURES to PV_TIME_FEATURES.
>>
>> Signed-off-by: Keqian Zhu 
>> Reviewed-by: Andrew Jones 
>> Reviewed-by: Steven Price 
>> ---
>>  Documentation/virt/kvm/arm/pvtime.rst | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/virt/kvm/arm/pvtime.rst
>> b/Documentation/virt/kvm/arm/pvtime.rst
>> index 687b60d..94bffe2 100644
>> --- a/Documentation/virt/kvm/arm/pvtime.rst
>> +++ b/Documentation/virt/kvm/arm/pvtime.rst
>> @@ -3,7 +3,7 @@
>>  Paravirtualized time support for arm64
>>  ==
>>
>> -Arm specification DEN0057/A defines a standard for paravirtualised time
>> +Arm specification DEN0057/A defines a standard for paravirtualized time
>>  support for AArch64 guests:
> 
> nit: I do object to this change (some of us are British! ;-).
Oh, I will pay attention to this. Thanks!

Keqian
> 
> M.

[PATCH] x86/resctrl: Fix incorrect local bandwidth when mba_sc is enabled

[Xiaochen Shen]

MBA software controller (mba_sc) is a feedback loop which periodically
reads MBM counters and tries to restrict the bandwidth below a user
specified bandwidth. It tags along MBM counter overflow handler to do
the updates with 1s interval in mbm_update() and update_mba_bw().

The purpose of mbm_update() is to periodically read the MBM counters to
make sure that the hardware counter doesn't wrap around more than once
between user samplings. mbm_update() calls __mon_event_count() for local
bandwidth updating when mba_sc is not enabled, but calls mbm_bw_count()
instead when mba_sc is enabled. __mon_event_count() will not be called
for local bandwidth updating in MBM counter overflow handler, but it is
still called when reading MBM local bandwidth counter file
'mbm_local_bytes', the call path is as below:

  rdtgroup_mondata_show()
mon_event_read()
  mon_event_count()
__mon_event_count()

In __mon_event_count(), m->chunks is updated by delta chunks which is
calculated from previous MSR value (m->prev_msr) and current MSR value.
When mba_sc is enabled, m->chunks is also updated in mbm_update() by
mistake by the delta chunks which is calculated from m->prev_bw_msr
instead of m->prev_msr. But m->chunks is not used in update_mba_bw() in
the mba_sc feedback loop.

When reading MBM local bandwidth counter file, m->chunks was changed
unexpectedly by mbm_bw_count(). As a result, the incorrect local
bandwidth counter which calculated from incorrect m->chunks is read out
to the user.

Fix this by removing incorrect m->chunks updating in mbm_bw_count() in
MBM counter overflow handler, and always calling __mon_event_count() in
mbm_update() to make sure that the hardware local bandwidth counter
doesn't wrap around.

Test steps:
  # Run workload with aggressive memory bandwidth (e.g., 10 GB/s)
  git clone https://github.com/intel/intel-cmt-cat && cd intel-cmt-cat
  && make
  ./tools/membw/membw -c 0 -b 1 --read

  # Enable MBA software controller
  mount -t resctrl resctrl -o mba_MBps /sys/fs/resctrl

  # Create control group c1
  mkdir /sys/fs/resctrl/c1

  # Set MB throttle to 6 GB/s
  echo "MB:0=6000;1=6000" > /sys/fs/resctrl/c1/schemata

  # Write PID of the workload to tasks file
  echo `pidof membw` > /sys/fs/resctrl/c1/tasks

  # Read local bytes counters twice with 1s interval, the calculated
  # local bandwidth is not as expected (approaching to 6 GB/s):
  local_1=`cat /sys/fs/resctrl/c1/mon_data/mon_L3_00/mbm_local_bytes`
  sleep 1
  local_2=`cat /sys/fs/resctrl/c1/mon_data/mon_L3_00/mbm_local_bytes`
  echo "local b/w (bytes/s):" `expr $local_2 - $local_1`

Before fix:
  local b/w (bytes/s): 11076796416

After fix:
  local b/w (bytes/s): 5465014272

Fixes: ba0f26d8529c (x86/intel_rdt/mba_sc: Prepare for feedback loop)
Signed-off-by: Xiaochen Shen 
Reviewed-by: Tony Luck 
---
 arch/x86/kernel/cpu/resctrl/monitor.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c 
b/arch/x86/kernel/cpu/resctrl/monitor.c
index 54dffe574e67..a98519a3a2e6 100644
--- a/arch/x86/kernel/cpu/resctrl/monitor.c
+++ b/arch/x86/kernel/cpu/resctrl/monitor.c
@@ -279,7 +279,6 @@ static void mbm_bw_count(u32 rmid, struct rmid_read *rr)
return;
 
chunks = mbm_overflow_count(m->prev_bw_msr, tval, rr->r->mbm_width);
-   m->chunks += chunks;
cur_bw = (chunks * r->mon_scale) >> 20;
 
if (m->delta_comp)
@@ -450,15 +449,14 @@ static void mbm_update(struct rdt_resource *r, struct 
rdt_domain *d, int rmid)
}
if (is_mbm_local_enabled()) {
rr.evtid = QOS_L3_MBM_LOCAL_EVENT_ID;
+   __mon_event_count(rmid, );
 
/*
 * Call the MBA software controller only for the
 * control groups and when user has enabled
 * the software controller explicitly.
 */
-   if (!is_mba_sc(NULL))
-   __mon_event_count(rmid, );
-   else
+   if (is_mba_sc(NULL))
mbm_bw_count(rmid, );
}
 }
-- 
1.8.3.1

[PATCH v3] bcache: fix panic due to cache_set is null

[Yi Li]

bcache_device_detach will release the cache_set after hotunplug cache
disk.

Here is how the issue happens.
1) cached_dev_free do cancel_writeback_rate_update_dwork
   without bch_register_lock.
2) Wirting the writeback_percent by sysfs with
   bch_register_lock will insert a writeback_rate_update work.
3) cached_dev_free with bch_register_lock to do bcache_device_free.
   dc->disk.c will be set NULL.
4) update_writeback_rate will crash when access dc->disk.c.

After Patch:
1) cached_dev_free do cancel_writeback_rate_update_dwork and set dc->disk.c
   to NULL with bch_register_lock.
2) dc->disk.c = NULL will avoid that Wirting the writeback_percent by sysfs
   insert a writeback_rate_update work.

Fixes: 80265d8dfd77 ("bcache: acquire bch_register_lock later in 
cached_dev_free()")

  IP: [] update_writeback_rate+0x59/0x3a0 [bcache]
  PGD 879620067 PUD 8755d3067 PMD 0
  Oops:  [#1] SMP
  CPU: 8 PID: 1005702 Comm: kworker/8:0 Tainted: G 4.4.0+10 #1
  Hardware name: Intel BIOS SE5C610.86B.01.01.0021.032120170601 03/21/2017
  Workqueue: events update_writeback_rate [bcache]
  task: 8808786f3800 ti: 88077082c000 task.ti: 88077082c000
  RIP: e030:[] update_writeback_rate+0x59/0x3a0 [bcache]
  RSP: e02b:88077082fde0  EFLAGS: 00010202
  RAX: 0018 RBX: 8808047f0b08 RCX: 
  RDX: 0001 RSI: 88088170dab8 RDI: 88088170dab8
  RBP: 88077082fe18 R08: 000a R09: 
  R10:  R11: 00017bc8 R12: 
  R13: 8808047f R14: 0200 R15: 8808047f0b08
  FS:  7f157b6d6700() GS:88088170() knlGS:
  CS:  e033 DS:  ES:  CR0: 80050033
  CR2: 0368 CR3: 000875c05000 CR4: 00040660
  Stack:
   0001 7ff0 88085ff600c0 880881714e80
   880881719500 0200 8808047f0b08 88077082fe60
   81088c0c 81714e80  880881714e80
  Call Trace:
   [] process_one_work+0x1fc/0x3b0
   [] worker_thread+0x2a5/0x470
   [] ? __schedule+0x648/0x870
   [] ? rescuer_thread+0x300/0x300
   [] kthread+0xd5/0xe0
   [] ? kthread_stop+0x110/0x110
   [] ret_from_fork+0x3f/0x70
   [] ? kthread_stop+0x110/0x110

Reported-by: Guo Chao 
Signed-off-by: Yi Li 
---
 drivers/md/bcache/super.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
index 46a00134a36a..381f9fbcd765 100644
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -1122,9 +1122,6 @@ static void cached_dev_detach_finish(struct work_struct 
*w)
BUG_ON(refcount_read(>count));
 
 
-   if (test_and_clear_bit(BCACHE_DEV_WB_RUNNING, >disk.flags))
-   cancel_writeback_rate_update_dwork(dc);
-
if (!IS_ERR_OR_NULL(dc->writeback_thread)) {
kthread_stop(dc->writeback_thread);
dc->writeback_thread = NULL;
@@ -1138,6 +1135,9 @@ static void cached_dev_detach_finish(struct work_struct 
*w)
 
mutex_lock(_register_lock);
 
+   if (test_and_clear_bit(BCACHE_DEV_WB_RUNNING, >disk.flags))
+   cancel_writeback_rate_update_dwork(dc);
+
calc_cached_dev_sectors(dc->disk.c);
bcache_device_detach(>disk);
list_move(>list, _devices);
@@ -1334,9 +1334,6 @@ static void cached_dev_free(struct closure *cl)
 {
struct cached_dev *dc = container_of(cl, struct cached_dev, disk.cl);
 
-   if (test_and_clear_bit(BCACHE_DEV_WB_RUNNING, >disk.flags))
-   cancel_writeback_rate_update_dwork(dc);
-
if (!IS_ERR_OR_NULL(dc->writeback_thread))
kthread_stop(dc->writeback_thread);
if (!IS_ERR_OR_NULL(dc->status_update_thread))
@@ -1344,6 +1341,9 @@ static void cached_dev_free(struct closure *cl)
 
mutex_lock(_register_lock);
 
+   if (test_and_clear_bit(BCACHE_DEV_WB_RUNNING, >disk.flags))
+   cancel_writeback_rate_update_dwork(dc);
+
if (atomic_read(>running))
bd_unlink_disk_holder(dc->bdev, dc->disk.disk);
bcache_device_free(>disk);
-- 
2.25.3

Re: [PATCH v2] mm: Don't fault around userfaultfd-registered regions on reads

[Hugh Dickins]

On Thu, 3 Dec 2020, Andrea Arcangeli wrote:
> On Thu, Dec 03, 2020 at 09:30:51PM -0500, Peter Xu wrote:
> > I'm just afraid there's no space left for a migration entry, because 
> > migration
> > entries fills in the pfn information into swp offset field rather than a 
> > real
> > offset (please refer to make_migration_entry())?  I assume PFN can use any 
> > bit.
> > Or did I miss anything?
> > 
> > I went back to see the original proposal from Hugh:
> > 
> >   IIUC you only need a single value, no need to carve out another whole
> >   swp_type: could probably be swp_offset 0 of any swp_type other than 0.
> > 
> > Hugh/Andrea, sorry if this is a stupid swap question: could you help explain
> > why swp_offset=0 won't be used by any swap device?  I believe it's correct,
> > it's just that I failed to figure out the reason myself. :(
> > 

It's because swp_offset 0 is the offset of the swap header, and if we
ever used that when allocating swap, then the swap header would get
overwritten, and that swap area become unrecognizable next time.

But I said it would be usable for UFFD with any swp_type other than 0,
because a swap entry of type 0, offset 0 is simply 0, which looks just
like no swap entry at all, and there are (or were: I might not be
up-to-date) benign races where a swap entry might get passed down but
then found to be 0, and that was understandable and permitted (yes,
I still see the "if (!entry.val) goto out;" in __swap_info_get()).

And that might be related to pte_none() being 0 on most architectures
(not s390 IIRC): we need to distinguish none from swap.  Though that
all gets complicated by the way the swp_entry is munged before being
put into a pte, and the x86 swap munging got more complicated when
L1TF was revealed (and accompanied by prot none munging too) -
search git log of v4.19 for x86/speculation/l1tf if you need to.

> 
> Hugh may want to review if I got it wrong, but there's basically three
> ways.
> 
> swp_type would mean adding one more reserved value in addition of
> SWP_MIGRATION_READ and SWP_MIGRATION_WRITE (kind of increasing
> SWP_MIGRATION_NUM to 3).

I'm not very keen on actually using any of the SWP_MIGRATION defines,
partly because in principle UFFD should not depend on CONFIG_MIGRATION,
partly because the uffd_wp entry would not behave anything like a
migration entry (whose pfn should always indicate a locked page).

swp_offset 0 of swp_type 1 perhaps?

> 
> swp_offset = 0 works in combination of SWP_MIGRATION_WRITE and
> SWP_MIGRATION_READ if we enforce pfn 0 is never used by the kernel
> (I'd feel safer with pfn value -1UL truncated to the bits of the swp
> offset, since the swp_entry format is common code).
> 
> The bit I was suggesting is just one more bit like _PAGE_SWP_UFFD_WP
> from the pte, one that cannot ever be set in any swp entry today. I
> assume it can't be _PAGE_SWP_UFFD_WP since that already can be set but
> you may want to verify it...

I don't see why you would need another bit for this.

The code that checks non-present non-none entries in page table,
for whether they are actually swap or migration entries or whatever,
would now also check for swp_offset 0 of swp_type 1 and go off to
the UFFD WP processing if so.

I didn't pay much attention to below, it seemed over-complicated.
And I don't think Peter's PROT_NONE alternative was unworkable,
but would have to be more careful about pfn and L1TF than shown.
And I am more comfortable to focus on the swap-like direction,
than think in two directions at once - never my strength!

Hugh

> 
> It'd be set on the pte (not in the swap entry), then it doesn't matter
> much what's inside the swp_entry anymore. The pte value would be
> generated with this:
> 
>  pte_swp_uffd_wp_unmap(swp_entry_to_pte(swp_entry(SWP_MIGRATION_READ, 0)))
> 
> (maybe SWP_MIGRATION_READ could also be 0 and then it can be just
> enough to set that single bit in the pte and nothing else, all other
> bits zero)
> 
> We never store a raw swp entry in the pte (the raw swp entry is stored
> in the xarray, it's the index of the swapcache).
> 
> To solve our unmap issue we only deal with pte storage (no xarray
> index storage). This is why it can also be in the arch specific pte
> representation of the swp entry, it doesn't need to be a special value
> defined in the swp entry common code.
> 
> Being the swap entry to pte conversion arch dependent, such bit needs
> to be defined by each arch (reserving a offset or type value in swp
> entry would solve it in the common code).
> 
> #define SWP_OFFSET_FIRST_BIT  (_PAGE_BIT_PROTNONE + 1)
> 
> All bits below PROTNONE are available for software use and we use bit
> 1 (soft dirty) 2 (uffd_wp). protnone bit 8 itself (global bit) must
> not be set or it'll look protnone and pte_present will be true. Bit 7
> is PSE so it's also not available because pte_present checks that
> too.
> 
> It appears you can pick between bit 3 4 5 6 at your own choice and it
> doesn't look like we're running out of those 

Re: [PATCH v1 bpf-next 06/11] bpf: Introduce two attach types for BPF_PROG_TYPE_SK_REUSEPORT.

[Martin KaFai Lau]

On Thu, Dec 03, 2020 at 11:16:08PM +0900, Kuniyuki Iwashima wrote:
> From:   Martin KaFai Lau 
> Date:   Wed, 2 Dec 2020 20:24:02 -0800
> > On Wed, Dec 02, 2020 at 11:19:02AM -0800, Martin KaFai Lau wrote:
> > > On Tue, Dec 01, 2020 at 06:04:50PM -0800, Andrii Nakryiko wrote:
> > > > On Tue, Dec 1, 2020 at 6:49 AM Kuniyuki Iwashima  
> > > > wrote:
> > > > >
> > > > > This commit adds new bpf_attach_type for BPF_PROG_TYPE_SK_REUSEPORT to
> > > > > check if the attached eBPF program is capable of migrating sockets.
> > > > >
> > > > > When the eBPF program is attached, the kernel runs it for socket 
> > > > > migration
> > > > > only if the expected_attach_type is 
> > > > > BPF_SK_REUSEPORT_SELECT_OR_MIGRATE.
> > > > > The kernel will change the behaviour depending on the returned value:
> > > > >
> > > > >   - SK_PASS with selected_sk, select it as a new listener
> > > > >   - SK_PASS with selected_sk NULL, fall back to the random selection
> > > > >   - SK_DROP, cancel the migration
> > > > >
> > > > > Link: 
> > > > > https://lore.kernel.org/netdev/20201123003828.xjpjdtk4ygl6t...@kafai-mbp.dhcp.thefacebook.com/
> > > > > Suggested-by: Martin KaFai Lau 
> > > > > Signed-off-by: Kuniyuki Iwashima 
> > > > > ---
> > > > >  include/uapi/linux/bpf.h   | 2 ++
> > > > >  kernel/bpf/syscall.c   | 8 
> > > > >  tools/include/uapi/linux/bpf.h | 2 ++
> > > > >  3 files changed, 12 insertions(+)
> > > > >
> > > > > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > > > > index 85278deff439..cfc207ae7782 100644
> > > > > --- a/include/uapi/linux/bpf.h
> > > > > +++ b/include/uapi/linux/bpf.h
> > > > > @@ -241,6 +241,8 @@ enum bpf_attach_type {
> > > > > BPF_XDP_CPUMAP,
> > > > > BPF_SK_LOOKUP,
> > > > > BPF_XDP,
> > > > > +   BPF_SK_REUSEPORT_SELECT,
> > > > > +   BPF_SK_REUSEPORT_SELECT_OR_MIGRATE,
> > > > > __MAX_BPF_ATTACH_TYPE
> > > > >  };
> > > > >
> > > > > diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> > > > > index f3fe9f53f93c..a0796a8de5ea 100644
> > > > > --- a/kernel/bpf/syscall.c
> > > > > +++ b/kernel/bpf/syscall.c
> > > > > @@ -2036,6 +2036,14 @@ bpf_prog_load_check_attach(enum bpf_prog_type 
> > > > > prog_type,
> > > > > if (expected_attach_type == BPF_SK_LOOKUP)
> > > > > return 0;
> > > > > return -EINVAL;
> > > > > +   case BPF_PROG_TYPE_SK_REUSEPORT:
> > > > > +   switch (expected_attach_type) {
> > > > > +   case BPF_SK_REUSEPORT_SELECT:
> > > > > +   case BPF_SK_REUSEPORT_SELECT_OR_MIGRATE:
> > > > > +   return 0;
> > > > > +   default:
> > > > > +   return -EINVAL;
> > > > > +   }
> > > > 
> > > > this is a kernel regression, previously expected_attach_type wasn't
> > > > enforced, so user-space could have provided any number without an
> > > > error.
> > > I also think this change alone will break things like when the usual
> > > attr->expected_attach_type == 0 case.  At least changes is needed in
> > > bpf_prog_load_fixup_attach_type() which is also handling a
> > > similar situation for BPF_PROG_TYPE_CGROUP_SOCK.
> > > 
> > > I now think there is no need to expose new bpf_attach_type to the UAPI.
> > > Since the prog->expected_attach_type is not used, it can be cleared at 
> > > load time
> > > and then only set to BPF_SK_REUSEPORT_SELECT_OR_MIGRATE (probably defined
> > > internally at filter.[c|h]) in the is_valid_access() when "migration"
> > > is accessed.  When "migration" is accessed, the bpf prog can handle
> > > migration (and the original not-migration) case.
> > Scrap this internal only BPF_SK_REUSEPORT_SELECT_OR_MIGRATE idea.
> > I think there will be cases that bpf prog wants to do both
> > without accessing any field from sk_reuseport_md.
> > 
> > Lets go back to the discussion on using a similar
> > idea as BPF_PROG_TYPE_CGROUP_SOCK in bpf_prog_load_fixup_attach_type().
> > I am not aware there is loader setting a random number
> > in expected_attach_type, so the chance of breaking
> > is very low.  There was a similar discussion earlier [0].
> > 
> > [0]: https://lore.kernel.org/netdev/20200126045443.f47dzxdglazzchfm@ast-mbp/
> 
> Thank you for the idea and reference.
> 
> I will remove the change in bpf_prog_load_check_attach() and set the
> default value (BPF_SK_REUSEPORT_SELECT) in bpf_prog_load_fixup_attach_type()
> for backward compatibility if expected_attach_type is 0.
check_attach_type() can be kept.  You can refer to
commit aac3fc320d94 for a similar situation.

Re: [PATCH 1/3] kunit: tool: surface and address more typing issues

[David Gow]

On Fri, Dec 4, 2020 at 3:41 AM Daniel Latypov  wrote:
>
> The authors of this tool were more familiar with a different
> type-checker, https://github.com/google/pytype.
>
> That's open source, but mypy seems more prevalent (and runs faster).
> And unlike pytype, mypy doesn't try to infer types so it doesn't check
> unanotated functions.
>
> So annotate ~all functions in kunit tool to increase type-checking
> coverage.
> Note: per https://www.python.org/dev/peps/pep-0484/, `__init__()` should
> be annotated as `-> None`.
>
> Doing so makes mypy discover a number of new violations.
> Exclude main() since we reuse `request` for the different types of
> requests, which mypy isn't happy about.
>
> This commit fixes all but one error, where `TestSuite.status` might be
> None.
>
> Signed-off-by: Daniel Latypov 
> ---

This looks good to me: I gave it some quick testing, and reading
through it, all of the changes seem sensible.

I wasn't able to get pytype running here, but mypy worked fine.

Reviewed-by: David Gow 

-- David

[PATCH v2] HID: sony: Add support for tilt on guitar hero guitars

[sanjay . govind9]

From: Sanjay Govind 

This commit adds support for tilt on Standard Guitar Hero PS3 Guitars, and GH3 
PC Guitars, mapping it to ABS_RY.

Note that GH3 PC Guitars are identical, only they use different VID and PIDs.
Also note that vendor id 0x12ba is used by a variety of different rhythm 
controllers on the ps3.

Signed-off-by: Sanjay Govind 

Fix some incorrect constants after a refactor
---
 drivers/hid/Kconfig|  1 +
 drivers/hid/hid-ids.h  |  6 +-
 drivers/hid/hid-sony.c | 20 ++--
 3 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 18b3ad50e1ca..02124c2c4b2e 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -908,6 +908,7 @@ config HID_SONY
  * Sony PS3 Blue-ray Disk Remote Control (Bluetooth)
  * Logitech Harmony adapter for Sony Playstation 3 (Bluetooth)
  * Guitar Hero Live PS3 and Wii U guitar dongles
+ * Guitar Hero PS3 and PC guitar dongles
 
 config SONY_FF
bool "Sony PS2/3/4 accessories force feedback support" 
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index eee6e27d5f1e..3479ae7dd651 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -40,6 +40,9 @@
 #define USB_VENDOR_ID_ACTIONSTAR   0x2101
 #define USB_DEVICE_ID_ACTIONSTAR_1011  0x1011
 
+#define USB_VENDOR_ID_ACTIVISION   0x1430
+#define USB_DEVICE_ID_ACTIVISION_GUITAR_DONGLE 0x474c
+
 #define USB_VENDOR_ID_ADS_TECH 0x06e1
 #define USB_DEVICE_ID_ADS_TECH_RADIO_SI470X0xa155
 
@@ -1074,8 +1077,9 @@
 #define USB_DEVICE_ID_SONY_BUZZ_CONTROLLER 0x0002
 #define USB_DEVICE_ID_SONY_WIRELESS_BUZZ_CONTROLLER0x1000
 
-#define USB_VENDOR_ID_SONY_GHLIVE  0x12ba
+#define USB_VENDOR_ID_SONY_RHYTHM  0x12ba
 #define USB_DEVICE_ID_SONY_PS3WIIU_GHLIVE_DONGLE   0x074b
+#define USB_DEVICE_ID_SONY_PS3_GUITAR_DONGLE   0x0100
 
 #define USB_VENDOR_ID_SINO_LITE0x1345
 #define USB_DEVICE_ID_SINO_LITE_CONTROLLER 0x3008
diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index 326c4bdbd0ea..0b334a338b9a 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -12,6 +12,7 @@
  *  Copyright (c) 2014-2016 Frank Praznik 
  *  Copyright (c) 2018 Todd Kelner
  *  Copyright (c) 2020 Pascal Giard 
+ *  Copyright (c) 2020 Sanjay Govind 
  */
 
 /*
@@ -59,7 +60,8 @@
 #define NSG_MR5U_REMOTE_BTBIT(14)
 #define NSG_MR7U_REMOTE_BTBIT(15)
 #define SHANWAN_GAMEPAD   BIT(16)
-#define GHL_GUITAR_PS3WIIUBIT(17)
+#define GH_GUITAR_CONTROLLER  BIT(17)
+#define GHL_GUITAR_PS3WIIUBIT(18)
 
 #define SIXAXIS_CONTROLLER (SIXAXIS_CONTROLLER_USB | SIXAXIS_CONTROLLER_BT)
 #define MOTION_CONTROLLER (MOTION_CONTROLLER_USB | MOTION_CONTROLLER_BT)
@@ -84,7 +86,7 @@
 #define NSG_MRXU_MAX_Y 1868
 
 #define GHL_GUITAR_POKE_INTERVAL 10 /* In seconds */
-#define GHL_GUITAR_TILT_USAGE 44
+#define GUITAR_TILT_USAGE 44
 
 /* Magic value and data taken from GHLtarUtility:
  * https://github.com/ghlre/GHLtarUtility/blob/master/PS3Guitar.cs
@@ -692,7 +694,7 @@ static int guitar_mapping(struct hid_device *hdev, struct 
hid_input *hi,
if ((usage->hid & HID_USAGE_PAGE) == HID_UP_MSVENDOR) {
unsigned int abs = usage->hid & HID_USAGE;
 
-   if (abs == GHL_GUITAR_TILT_USAGE) {
+   if (abs == GUITAR_TILT_USAGE) {
hid_map_usage_clear(hi, usage, bit, max, EV_ABS, 
ABS_RY);
return 1;
}
@@ -1481,7 +1483,7 @@ static int sony_mapping(struct hid_device *hdev, struct 
hid_input *hi,
if (sc->quirks & DUALSHOCK4_CONTROLLER)
return ds4_mapping(hdev, hi, field, usage, bit, max);
 
-   if (sc->quirks & GHL_GUITAR_PS3WIIU)
+   if (sc->quirks & GH_GUITAR_CONTROLLER)
return guitar_mapping(hdev, hi, field, usage, bit, max);
 
/* Let hid-core decide for the others */
@@ -3145,8 +3147,14 @@ static const struct hid_device_id sony_devices[] = {
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SMK, 
USB_DEVICE_ID_SMK_NSG_MR7U_REMOTE),
.driver_data = NSG_MR7U_REMOTE_BT },
/* Guitar Hero Live PS3 and Wii U guitar dongles */
-   { HID_USB_DEVICE(USB_VENDOR_ID_SONY_GHLIVE, 
USB_DEVICE_ID_SONY_PS3WIIU_GHLIVE_DONGLE),
-   .driver_data = GHL_GUITAR_PS3WIIU},
+   { HID_USB_DEVICE(USB_VENDOR_ID_SONY_RHYTHM, 
USB_DEVICE_ID_SONY_PS3WIIU_GHLIVE_DONGLE),
+   .driver_data = GHL_GUITAR_PS3WIIU | GH_GUITAR_CONTROLLER },
+   /* Guitar Hero PC Guitar Dongle */
+   { HID_USB_DEVICE(USB_VENDOR_ID_ACTIVISION, 
USB_DEVICE_ID_ACTIVISION_GUITAR_DONGLE),
+   .driver_data = GH_GUITAR_CONTROLLER },
+   /* Guitar Hero PS3 World Tour Guitar Dongle */
+   { HID_USB_DEVICE(USB_VENDOR_ID_SONY_RHYTHM, 
USB_DEVICE_ID_SONY_PS3_GUITAR_DONGLE),
+   .driver_data = GH_GUITAR_CONTROLLER },
{ }
 };
 

linux-next: manual merge of the kvm-arm tree with the arm64 tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm64/kernel/head.S

between commits:

  2ffac9e3fdbd ("arm64: head.S: cleanup SCTLR_ELx initialization")
  d87a8e65b510 ("arm64: head.S: always initialize PSTATE")

from the arm64 tree and commit:

  9c322020286c ("arm64: Extract parts of el2_setup into a macro")

from the kvm-arm tree.

I have no idea how to fix this up, so I just used the kvm-arm tree from
next-20201203 instead for today.

-- 
Cheers,
Stephen Rothwell


pgpWAI91LmXiM.pgp
Description: OpenPGP digital signature