[PATCH v1 2/4] dt-bindings: clock: Add support for the MSM8998 mmcc

[Jeffrey Hugo]

Document the multimedia clock controller found on MSM8998

Signed-off-by: Jeffrey Hugo 
---
 Documentation/devicetree/bindings/clock/qcom,mmcc.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/qcom,mmcc.txt 
b/Documentation/devicetree/bindings/clock/qcom,mmcc.txt
index 8b0f784..ae85bca 100644
--- a/Documentation/devicetree/bindings/clock/qcom,mmcc.txt
+++ b/Documentation/devicetree/bindings/clock/qcom,mmcc.txt
@@ -10,11 +10,18 @@ Required properties :
"qcom,mmcc-msm8960"
"qcom,mmcc-msm8974"
"qcom,mmcc-msm8996"
+   "qcom,mmcc-msm8998"
 
 - reg : shall contain base register location and length
 - #clock-cells : shall contain 1
 - #reset-cells : shall contain 1
 
+For MSM8998 only:
+   - clocks: a list of phandles and clock-specifier pairs,
+ one for each entry in clock-names.
+   - clock-names: "xo" for the xo clock,
+  "gpll0" for the global pll 0 clock.
+
 Optional properties :
 - #power-domain-cells : shall contain 1
 
-- 
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

[PATCH v1 3/4] clk: qcom: Add MSM8998 Multimedia Clock Controller (MMCC) driver

[Jeffrey Hugo]

Add a driver for the multimedia clock controller found on MSM8998
based devices. This should allow most multimedia device drivers
to probe and control their clocks.

Signed-off-by: Jeffrey Hugo 
---
 drivers/clk/qcom/Kconfig  |9 +
 drivers/clk/qcom/Makefile |1 +
 drivers/clk/qcom/mmcc-msm8998.c   | 2937 +
 include/dt-bindings/clock/qcom,mmcc-msm8998.h |  210 ++
 4 files changed, 3157 insertions(+)
 create mode 100644 drivers/clk/qcom/mmcc-msm8998.c
 create mode 100644 include/dt-bindings/clock/qcom,mmcc-msm8998.h

diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 1c04575c..6c36603 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -221,6 +221,15 @@ config MSM_GCC_8998
  Say Y if you want to use peripheral devices such as UART, SPI,
  i2c, USB, UFS, SD/eMMC, PCIe, etc.
 
+config MSM_MMCC_8998
+   tristate "MSM8998 Multimedia Clock Controller"
+   select MSM_GCC_8998
+   select QCOM_GDSC
+   help
+ Support for the multimedia clock controller on msm8998 devices.
+ Say Y if you want to support multimedia devices such as display,
+ graphics, video encode/decode, camera, etc.
+
 config QCS_GCC_404
tristate "QCS404 Global Clock Controller"
help
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index ee8d069..d6de24b 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_MSM_GCC_8998) += gcc-msm8998.o
 obj-$(CONFIG_MSM_MMCC_8960) += mmcc-msm8960.o
 obj-$(CONFIG_MSM_MMCC_8974) += mmcc-msm8974.o
 obj-$(CONFIG_MSM_MMCC_8996) += mmcc-msm8996.o
+obj-$(CONFIG_MSM_MMCC_8996) += mmcc-msm8998.o
 obj-$(CONFIG_QCOM_A53PLL) += a53-pll.o
 obj-$(CONFIG_QCOM_CLK_APCS_MSM8916) += apcs-msm8916.o
 obj-$(CONFIG_QCOM_CLK_RPM) += clk-rpm.o
diff --git a/drivers/clk/qcom/mmcc-msm8998.c b/drivers/clk/qcom/mmcc-msm8998.c
new file mode 100644
index 000..5ad2e2a
--- /dev/null
+++ b/drivers/clk/qcom/mmcc-msm8998.c
@@ -0,0 +1,2937 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "common.h"
+#include "clk-regmap.h"
+#include "clk-regmap-divider.h"
+#include "clk-alpha-pll.h"
+#include "clk-rcg.h"
+#include "clk-branch.h"
+#include "reset.h"
+#include "gdsc.h"
+
+enum {
+   P_XO,
+   P_GPLL0,
+   P_GPLL0_DIV,
+   P_MMPLL0_OUT_EVEN,
+   P_MMPLL1_OUT_EVEN,
+   P_MMPLL3_OUT_EVEN,
+   P_MMPLL4_OUT_EVEN,
+   P_MMPLL5_OUT_EVEN,
+   P_MMPLL6_OUT_EVEN,
+   P_MMPLL7_OUT_EVEN,
+   P_MMPLL10_OUT_EVEN,
+   P_DSI0PLL,
+   P_DSI1PLL,
+   P_DSI0PLL_BYTE,
+   P_DSI1PLL_BYTE,
+   P_HDMIPLL,
+   P_DPVCO,
+   P_DPLINK,
+   P_CORE_BI_PLL_TEST_SE,
+};
+
+static const struct parent_map mmss_xo_hdmi_map[] = {
+   { P_XO, 0 },
+   { P_HDMIPLL, 1 },
+   { P_CORE_BI_PLL_TEST_SE, 7 }
+};
+
+static const char * const mmss_xo_hdmi[] = {
+   "mmss_xo",
+   "hdmi_phy_pll_out",
+   "core_bi_pll_test_se"
+};
+
+static const struct parent_map mmss_xo_dsi0pll_dsi1pll_map[] = {
+   { P_XO, 0 },
+   { P_DSI0PLL, 1 },
+   { P_DSI1PLL, 2 },
+   { P_CORE_BI_PLL_TEST_SE, 7 }
+};
+
+static const char * const mmss_xo_dsi0pll_dsi1pll[] = {
+   "mmss_xo",
+   "dsi0_phy_pll_out_dsiclk",
+   "dsi1_phy_pll_out_dsiclk",
+   "core_bi_pll_test_se"
+};
+
+static const struct parent_map mmss_xo_dsibyte_map[] = {
+   { P_XO, 0 },
+   { P_DSI0PLL_BYTE, 1 },
+   { P_DSI1PLL_BYTE, 2 },
+   { P_CORE_BI_PLL_TEST_SE, 7 }
+};
+
+static const char * const mmss_xo_dsibyte[] = {
+   "mmss_xo",
+   "dsi0_phy_pll_out_byteclk",
+   "dsi1_phy_pll_out_byteclk",
+   "core_bi_pll_test_se"
+};
+
+static const struct parent_map mmss_xo_dp_map[] = {
+   { P_XO, 0 },
+   { P_DPLINK, 1 },
+   { P_DPVCO, 2 },
+   { P_CORE_BI_PLL_TEST_SE, 7 }
+};
+
+static const char * const mmss_xo_dp[] = {
+   "mmss_xo",
+   "dp_phy_pll_link_clk",
+   "dp_phy_pll_vco_div",
+   "core_bi_pll_test_se"
+};
+
+static const struct parent_map mmss_xo_gpll0_gpll0_div_map[] = {
+   { P_XO, 0 },
+   { P_GPLL0, 5 },
+   { P_GPLL0_DIV, 6 },
+   { P_CORE_BI_PLL_TEST_SE, 7 }
+};
+
+static const char * const mmss_xo_gpll0_gpll0_div[] = {
+   "mmss_xo",
+   "mmss_gpll0",
+   "mmss_gpll0_div",
+   "core_bi_pll_test_se"
+};
+
+static const struct parent_map mmss_xo_mmpll0_gpll0_gpll0_div_map[] = {
+   { P_XO, 0 },
+   { P_MMPLL0_OUT_EVEN, 1 },
+   { P_GPLL0, 5 },
+   { P_GPLL0_DIV, 6 },
+   { P_CORE_BI_PLL_TEST_SE, 7 }
+};
+
+static const char * const mmss_xo_mmpll0_gpll0_gpll0_div[] = {
+   "mmss_xo",
+   "mmpll0_out_even",
+

[PATCH v1 4/4] arm64: dts: qcom: msm8998: Add mmcc node

[Jeffrey Hugo]

Add MSM8998 Multimedia Clock Controller DT node.

Signed-off-by: Jeffrey Hugo 
---
 arch/arm64/boot/dts/qcom/msm8998.dtsi | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi 
b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index 7136ab1..5673a65 100644
--- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -814,6 +814,21 @@
status = "disabled";
};
 
+   mmcc: clock-controller@c8c {
+   compatible = "qcom,mmcc-msm8998";
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+   #power-domain-cells = <1>;
+   reg = <0x0c8c 0x4>;
+
+   clock-names =
+   "xo",
+   "gpll0";
+   clocks =
+   <&rpmcc RPM_SMD_XO_CLK_SRC>,
+   <&gcc GPLL0_OUT_MAIN>;
+   };
+
timer@1792 {
#address-cells = <1>;
#size-cells = <1>;
-- 
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH v4 1/5] misc: dt-bindings: Add Qualcomm Fastrpc bindings

[Rob Herring]

On Thu, 24 Jan 2019 15:24:08 +, Srinivas Kandagatla wrote:
> The FastRPC driver implements an IPC (Inter-Processor Communication)
> mechanism that allows for clients to transparently make remote method
> invocations across DSP and APPS boundaries. This enables developers
> to offload tasks to the DSP and free up the application processor for
> other tasks.
> 
> Co-developed-by: Thierry Escande 
> Signed-off-by: Thierry Escande 
> Signed-off-by: Srinivas Kandagatla 
> ---
>  .../devicetree/bindings/misc/qcom,fastrpc.txt | 78 +++
>  1 file changed, 78 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/misc/qcom,fastrpc.txt
> 

Reviewed-by: Rob Herring 

Re: [PATCH v2] staging: mt7621-eth/ethtool.c: Correction of SPDX license identifier

[Andrew Lunn]

On Wed, Jan 30, 2019 at 02:48:27PM +, Carlos Henrique Lima Melara wrote:
>   This patch fix the checkpatch.p1 warning:
> 
>   WARNING: Missing or malformed SPDX-License-Identifier tag in line 1
>   +/*
> 
>   It includes the SPDX expression for GPL-2.0 and corrects the comment 
> format to suit the kernel's coding style.
> 
> Signed-off-by: Carlos (Charles) Henrique Lima Melara 
> 
> ---
>  drivers/staging/mt7621-eth/ethtool.c | 22 --
>  1 file changed, 12 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/staging/mt7621-eth/ethtool.c 
> b/drivers/staging/mt7621-eth/ethtool.c
> index 40a7d47be913..49d417de64c8 100644
> --- a/drivers/staging/mt7621-eth/ethtool.c
> +++ b/drivers/staging/mt7621-eth/ethtool.c
> @@ -1,15 +1,17 @@
> -/*   This program is free software; you can redistribute it and/or modify
> - *   it under the terms of the GNU General Public License as published by
> - *   the Free Software Foundation; version 2 of the License
> +// SPDX-License-Identifier: GPL-2.0

Hi Carlos

drivers/staging/mt7621-eth$ grep LICENSE *
gsw_mt7621.c:MODULE_LICENSE("GPL");
mtk_eth_soc.c:MODULE_LICENSE("GPL");

And include/linux/module.h 
says:

/*
 * The following license idents are currently accepted as indicating free
 * software modules
 *
 *  "GPL"   [GNU Public License v2 or later]
 *  "GPL v2"[GNU Public License v2]

So the SPDX string probably does not match the MODULE_LICENSE.

   Andrew

[PATCH v2] usb: chipidea: Grab the (legacy) USB PHY by phandle first

[Paul Kocialkowski]

According to the chipidea driver bindings, the USB PHY is specified via
the "phys" phandle node. However, this only takes effect for USB PHYs
that use the common PHY framework. For legacy USB PHYs, a simple lookup
based on the USB PHY type is done instead.

This does not play out well when more than USB PHY is registered, since
the first registered PHY matching the type will always be returned
regardless of what the driver was bound to.

Fix this by looking up the PHY based on the "phys" phandle node.
Although generic PHYS and rather matched by their "phys-name" and not
the "phys" phandle directly, there is no helper for similar lookup on
legacy PHYs and it's probably not worth the effort to add it.

When no legacy USB PHY is found by phandle, fallback to grabbing any
registered USB2 PHY. This ensures backward compatibility if some users
were actually relying on this mechanism.

Signed-off-by: Paul Kocialkowski 
---
Changes since v1:
* Only consider legacy USB PHY error for fallback as suggested;
* Checked against EPROBE_DEFER before entering fallback.

 drivers/usb/chipidea/core.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 7bfcbb23c2a4..016e4004fe9d 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -954,8 +954,15 @@ static int ci_hdrc_probe(struct platform_device *pdev)
} else if (ci->platdata->usb_phy) {
ci->usb_phy = ci->platdata->usb_phy;
} else {
+   ci->usb_phy = devm_usb_get_phy_by_phandle(dev->parent, "phys",
+ 0);
ci->phy = devm_phy_get(dev->parent, "usb-phy");
-   ci->usb_phy = devm_usb_get_phy(dev->parent, USB_PHY_TYPE_USB2);
+
+   /* Fallback to grabbing any registered USB2 PHY */
+   if (IS_ERR(ci->usb_phy) &&
+   PTR_ERR(ci->usb_phy) != -EPROBE_DEFER)
+   ci->usb_phy = devm_usb_get_phy(dev->parent,
+  USB_PHY_TYPE_USB2);
 
/* if both generic PHY and USB PHY layers aren't enabled */
if (PTR_ERR(ci->phy) == -ENOSYS &&
-- 
2.20.1

[PATCH 4/4] ARM: dts: stm32: Add romem and temperature calibration on stm32mp157c

[Fabrice Gasnier]

Add & enable stm32 factory-programmed memory. Describe temperature sensor
calibration cells. Non-volatile calibration data is made available by
stm32mp157c bootrom in bsec_dataX registers.

Signed-off-by: Fabrice Gasnier 
---
 arch/arm/boot/dts/stm32mp157c.dtsi | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi 
b/arch/arm/boot/dts/stm32mp157c.dtsi
index 8bf1c17..9a7ac80 100644
--- a/arch/arm/boot/dts/stm32mp157c.dtsi
+++ b/arch/arm/boot/dts/stm32mp157c.dtsi
@@ -1106,6 +1106,19 @@
status = "disabled";
};
 
+   bsec: nvmem@5c005000 {
+   compatible = "st,stm32mp15-bsec";
+   reg = <0x5c005000 0x400>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ts_cal1: calib@5c {
+   reg = <0x5c 0x2>;
+   };
+   ts_cal2: calib@5e {
+   reg = <0x5e 0x2>;
+   };
+   };
+
i2c6: i2c@5c009000 {
compatible = "st,stm32f7-i2c";
reg = <0x5c009000 0x400>;
-- 
1.9.1

[PATCH 2/4] nvmem: Add driver for STM32 factory-programmed read only mem

[Fabrice Gasnier]

Add a read only nvmem driver for STM32 factory-programmed memory area
(on-chip non-volatile storage).

Signed-off-by: Fabrice Gasnier 
---
 drivers/nvmem/Kconfig   | 10 ++
 drivers/nvmem/Makefile  |  2 ++
 drivers/nvmem/stm32-romem.c | 78 +
 3 files changed, 90 insertions(+)
 create mode 100644 drivers/nvmem/stm32-romem.c

diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 0a7a470e..f398b18 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -113,6 +113,16 @@ config NVMEM_BCM_OCOTP
  This driver can also be built as a module. If so, the module
  will be called nvmem-bcm-ocotp.
 
+config NVMEM_STM32_ROMEM
+   tristate "STMicroelectronics STM32 factory-programmed memory support"
+   depends on ARCH_STM32 || COMPILE_TEST
+   help
+ Say y here to enable read-only access for STMicroelectronics STM32
+ factory-programmed memory area.
+
+ This driver can also be built as a module. If so, the module
+ will be called nvmem-stm32-romem.
+
 config NVMEM_SUNXI_SID
tristate "Allwinner SoCs SID support"
depends on ARCH_SUNXI
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 4e8c616..e85c946 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -26,6 +26,8 @@ nvmem_qfprom-y:= qfprom.o
 obj-$(CONFIG_ROCKCHIP_EFUSE)   += nvmem_rockchip_efuse.o
 nvmem_rockchip_efuse-y := rockchip-efuse.o
 obj-$(CONFIG_NVMEM_SUNXI_SID)  += nvmem_sunxi_sid.o
+nvmem_stm32_romem-y:= stm32-romem.o
+obj-$(CONFIG_NVMEM_STM32_ROMEM) += nvmem_stm32_romem.o
 nvmem_sunxi_sid-y  := sunxi_sid.o
 obj-$(CONFIG_UNIPHIER_EFUSE)   += nvmem-uniphier-efuse.o
 nvmem-uniphier-efuse-y := uniphier-efuse.o
diff --git a/drivers/nvmem/stm32-romem.c b/drivers/nvmem/stm32-romem.c
new file mode 100644
index 000..dadbcc2
--- /dev/null
+++ b/drivers/nvmem/stm32-romem.c
@@ -0,0 +1,78 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * STM32 Factory-programmed memory read access driver
+ *
+ * Copyright (C) 2017, STMicroelectronics - All Rights Reserved
+ * Author: Fabrice Gasnier  for STMicroelectronics.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+struct stm32_romem_priv {
+   void __iomem *base;
+   struct nvmem_config cfg;
+};
+
+static int stm32_romem_read(void *context, unsigned int offset, void *buf,
+   size_t bytes)
+{
+   struct stm32_romem_priv *priv = context;
+   u8 *buf8 = buf;
+   int i;
+
+   for (i = offset; i < offset + bytes; i++)
+   *buf8++ = readb_relaxed(priv->base + i);
+
+   return 0;
+}
+
+static int stm32_romem_probe(struct platform_device *pdev)
+{
+   struct device *dev = &pdev->dev;
+   struct stm32_romem_priv *priv;
+   struct resource *res;
+
+   priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+   if (!priv)
+   return -ENOMEM;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   priv->base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(priv->base))
+   return PTR_ERR(priv->base);
+
+   priv->cfg.name = "stm32-romem";
+   priv->cfg.read_only = true;
+   priv->cfg.word_size = 1;
+   priv->cfg.stride = 1;
+   priv->cfg.size = resource_size(res);
+   priv->cfg.reg_read = stm32_romem_read;
+   priv->cfg.dev = dev;
+   priv->cfg.priv = priv;
+   priv->cfg.owner = THIS_MODULE;
+
+   return PTR_ERR_OR_ZERO(devm_nvmem_register(dev, &priv->cfg));
+}
+
+static const struct of_device_id stm32_romem_of_match[] = {
+   { .compatible = "st,stm32-romem", },
+   {},
+};
+MODULE_DEVICE_TABLE(of, stm32_romem_of_match);
+
+static struct platform_driver stm32_romem_driver = {
+   .probe = stm32_romem_probe,
+   .driver = {
+   .name = "stm32-romem",
+   .of_match_table = of_match_ptr(stm32_romem_of_match),
+   },
+};
+module_platform_driver(stm32_romem_driver);
+
+MODULE_AUTHOR("Fabrice Gasnier ");
+MODULE_DESCRIPTION("STMicroelectronics STM32 RO-MEM");
+MODULE_ALIAS("platform:nvmem-stm32-romem");
+MODULE_LICENSE("GPL v2");
-- 
1.9.1

[PATCH 3/4] nvmem: stm32: add support for STM32MP15 BSEC to control OTP data

[Fabrice Gasnier]

On STM32MP15, OTP area may be read/written by using BSEC (boot, security
and OTP control). BSEC registers set is composed of various regions, among
which control registers and OTP shadow registers.
Secure monitor calls are involved in this process to allow (or deny)
access to the full range of OTP data.
This adds support for reading and writing OTP data using SMC services.
Data content can be aligned on 16-bits or 8-bits. Then take care of it,
since BSEC data is 32-bits wide.

Signed-off-by: Fabrice Gasnier 
---
 drivers/nvmem/stm32-romem.c | 134 ++--
 1 file changed, 129 insertions(+), 5 deletions(-)

diff --git a/drivers/nvmem/stm32-romem.c b/drivers/nvmem/stm32-romem.c
index dadbcc2..efb9f38 100644
--- a/drivers/nvmem/stm32-romem.c
+++ b/drivers/nvmem/stm32-romem.c
@@ -6,11 +6,29 @@
  * Author: Fabrice Gasnier  for STMicroelectronics.
  */
 
+#include 
 #include 
 #include 
 #include 
 #include 
 
+/* BSEC secure service access from non-secure */
+#define STM32_SMC_BSEC 0x82001003
+#define STM32_SMC_READ_SHADOW  0x01
+#define STM32_SMC_PROG_OTP 0x02
+#define STM32_SMC_WRITE_SHADOW 0x03
+#define STM32_SMC_READ_OTP 0x04
+
+/* shadow registers offest */
+#define STM32MP15_BSEC_DATA0   0x200
+
+/* 32 (x 32-bits) lower shadow registers */
+#define STM32MP15_BSEC_NUM_LOWER   32
+
+struct stm32_romem_cfg {
+   int size;
+};
+
 struct stm32_romem_priv {
void __iomem *base;
struct nvmem_config cfg;
@@ -29,8 +47,98 @@ static int stm32_romem_read(void *context, unsigned int 
offset, void *buf,
return 0;
 }
 
+static int stm32_bsec_smc(u8 op, u32 otp, u32 data, u32 *result)
+{
+#if IS_ENABLED(CONFIG_HAVE_ARM_SMCCC)
+   struct arm_smccc_res res;
+
+   arm_smccc_smc(STM32_SMC_BSEC, op, otp, data, 0, 0, 0, 0, &res);
+   if (res.a0)
+   return -EIO;
+
+   if (result)
+   *result = (u32)res.a1;
+
+   return 0;
+#else
+   return -ENXIO;
+#endif
+}
+
+static int stm32_bsec_read(void *context, unsigned int offset, void *buf,
+  size_t bytes)
+{
+   struct stm32_romem_priv *priv = context;
+   struct device *dev = priv->cfg.dev;
+   u32 roffset, rbytes, val;
+   u8 *buf8 = buf, *val8 = (u8 *)&val;
+   int i, j = 0, ret, skip_bytes, size;
+
+   /* Round unaligned access to 32-bits */
+   roffset = rounddown(offset, 4);
+   skip_bytes = offset & 0x3;
+   rbytes = roundup(bytes + skip_bytes, 4);
+
+   if (roffset + rbytes > priv->cfg.size)
+   return -EINVAL;
+
+   for (i = roffset; (i < roffset + rbytes); i += 4) {
+   u32 otp = i >> 2;
+
+   if (otp < STM32MP15_BSEC_NUM_LOWER) {
+   /* read lower data from shadow registers */
+   val = readl_relaxed(
+   priv->base + STM32MP15_BSEC_DATA0 + i);
+   } else {
+   ret = stm32_bsec_smc(STM32_SMC_READ_SHADOW, otp, 0,
+&val);
+   if (ret) {
+   dev_err(dev, "Can't read data%d (%d)\n", otp,
+   ret);
+   return ret;
+   }
+   }
+   /* skip first bytes in case of unaligned read */
+   if (skip_bytes)
+   size = min(bytes, (size_t)(4 - skip_bytes));
+   else
+   size = min(bytes, (size_t)4);
+   memcpy(&buf8[j], &val8[skip_bytes], size);
+   bytes -= size;
+   j += size;
+   skip_bytes = 0;
+   }
+
+   return 0;
+}
+
+static int stm32_bsec_write(void *context, unsigned int offset, void *buf,
+   size_t bytes)
+{
+   struct stm32_romem_priv *priv = context;
+   struct device *dev = priv->cfg.dev;
+   u32 *buf32 = buf;
+   int ret, i;
+
+   /* Allow only writing complete 32-bits aligned words */
+   if ((bytes % 4) || (offset % 4))
+   return -EINVAL;
+
+   for (i = offset; i < offset + bytes; i += 4) {
+   ret = stm32_bsec_smc(STM32_SMC_PROG_OTP, i >> 2, *buf32++,
+NULL);
+   if (ret) {
+   dev_err(dev, "Can't write data%d (%d)\n", i >> 2, ret);
+   return ret;
+   }
+   }
+
+   return 0;
+}
+
 static int stm32_romem_probe(struct platform_device *pdev)
 {
+   const struct stm32_romem_cfg *cfg;
struct device *dev = &pdev->dev;
struct stm32_romem_priv *priv;
struct resource *res;
@@ -45,21 +153,37 @@ static int stm32_romem_probe(struct platform_device *pdev)
return PTR_ERR(priv->base);
 
priv->cfg.name = "stm32-romem";
-   priv->cfg.read_only = true;
   

[PATCH 0/4] Add nvmem support on STM32

[Fabrice Gasnier]

Non volatile memory area is available on STM32. It contains various
factory programmed information such as unique device ID, analog calibration...
This patchset adds NVMEM support to access these data.

Fabrice Gasnier (4):
  dt-bindings: nvmem: Add STM32 factory-programmed romem
  nvmem: Add driver for STM32 factory-programmed read only mem
  nvmem: stm32: add support for STM32MP15 BSEC to control OTP data
  ARM: dts: stm32: Add romem and temperature calibration on stm32mp157c

 .../devicetree/bindings/nvmem/st,stm32-romem.txt   |  31 
 arch/arm/boot/dts/stm32mp157c.dtsi |  13 ++
 drivers/nvmem/Kconfig  |  10 +
 drivers/nvmem/Makefile |   2 +
 drivers/nvmem/stm32-romem.c| 202 +
 5 files changed, 258 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/st,stm32-romem.txt
 create mode 100644 drivers/nvmem/stm32-romem.c

-- 
1.9.1

[PATCH 1/4] dt-bindings: nvmem: Add STM32 factory-programmed romem

[Fabrice Gasnier]

Add documentation for STMicroelectronics STM32 Factory-programmed
read only memory area.

Signed-off-by: Fabrice Gasnier 
---
 .../devicetree/bindings/nvmem/st,stm32-romem.txt   | 31 ++
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/st,stm32-romem.txt

diff --git a/Documentation/devicetree/bindings/nvmem/st,stm32-romem.txt 
b/Documentation/devicetree/bindings/nvmem/st,stm32-romem.txt
new file mode 100644
index 000..fbff52e
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/st,stm32-romem.txt
@@ -0,0 +1,31 @@
+STMicroelectronics STM32 Factory-programmed data device tree bindings
+
+This represents STM32 Factory-programmed read only non-volatile area: locked
+flash, OTP, read-only HW regs... This contains various information such as:
+analog calibration data for temperature sensor (e.g. TS_CAL1, TS_CAL2),
+internal vref (VREFIN_CAL), unique device ID...
+
+Required properties:
+- compatible:  Should be one of:
+   "st,stm32-romem"
+   "st,stm32mp15-bsec"
+- reg: Offset and length of factory-programmed area.
+- #address-cells:  Should be '<1>'.
+- #size-cells: Should be '<1>'.
+
+Optional Data cells:
+- Must be child nodes as described in nvmem.txt.
+
+Example on stm32f4:
+   romem: nvmem@1fff7800 {
+   compatible = "st,stm32-romem";
+   reg = <0x1fff7800 0x400>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   /* Data cells: ts_cal1 at 0x1fff7a2c */
+   ts_cal1: calib@22c {
+   reg = <0x22c 0x2>;
+   };
+   ...
+   };
-- 
1.9.1

[PATCH 5/5] virtio-blk: Consider virtio_max_dma_size() for maximum segment size

[Joerg Roedel]

From: Joerg Roedel 

Segments can't be larger than the maximum DMA mapping size
supported on the platform. Take that into account when
setting the maximum segment size for a block device.

Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Joerg Roedel 
---
 drivers/block/virtio_blk.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index b16a887bbd02..4bc083b7c9b5 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -723,7 +723,7 @@ static int virtblk_probe(struct virtio_device *vdev)
struct request_queue *q;
int err, index;
 
-   u32 v, blk_size, sg_elems, opt_io_size;
+   u32 v, blk_size, max_size, sg_elems, opt_io_size;
u16 min_io_size;
u8 physical_block_exp, alignment_offset;
 
@@ -826,14 +826,16 @@ static int virtblk_probe(struct virtio_device *vdev)
/* No real sector limit. */
blk_queue_max_hw_sectors(q, -1U);
 
+   max_size = virtio_max_dma_size(vdev);
+
/* Host can optionally specify maximum segment size and number of
 * segments. */
err = virtio_cread_feature(vdev, VIRTIO_BLK_F_SIZE_MAX,
   struct virtio_blk_config, size_max, &v);
if (!err)
-   blk_queue_max_segment_size(q, v);
-   else
-   blk_queue_max_segment_size(q, -1U);
+   max_size = min(max_size, v);
+
+   blk_queue_max_segment_size(q, max_size);
 
/* Host can optionally specify the block size of the device */
err = virtio_cread_feature(vdev, VIRTIO_BLK_F_BLK_SIZE,
-- 
2.17.1

[PATCH 2/5] swiotlb: Add is_swiotlb_active() function

[Joerg Roedel]

From: Joerg Roedel 

This function will be used from dma_direct code to determine
the maximum segment size of a dma mapping.

Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Joerg Roedel 
---
 include/linux/swiotlb.h | 6 ++
 kernel/dma/swiotlb.c| 9 +
 2 files changed, 15 insertions(+)

diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 1c22d96e1742..e9e786b4b598 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -63,6 +63,7 @@ extern void swiotlb_tbl_sync_single(struct device *hwdev,
 extern int
 swiotlb_dma_supported(struct device *hwdev, u64 mask);
 size_t swiotlb_max_mapping_size(struct device *dev);
+bool is_swiotlb_active(void);
 
 #ifdef CONFIG_SWIOTLB
 extern enum swiotlb_force swiotlb_force;
@@ -100,6 +101,11 @@ static inline size_t swiotlb_max_mapping_size(struct 
device *dev)
 {
return SIZE_MAX;
 }
+
+static inline bool is_swiotlb_active(void)
+{
+   return false;
+}
 #endif /* CONFIG_SWIOTLB */
 
 extern void swiotlb_print_info(void);
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 9cb21259cb0b..c873f9cc2146 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -667,3 +667,12 @@ size_t swiotlb_max_mapping_size(struct device *dev)
 {
return ((size_t)1 << IO_TLB_SHIFT) * IO_TLB_SEGSIZE;
 }
+
+bool is_swiotlb_active(void)
+{
+   /*
+* When SWIOTLB is initialized, even if io_tlb_start points to physical
+* address zero, io_tlb_end surely doesn't.
+*/
+   return io_tlb_end != 0;
+}
-- 
2.17.1

[PATCH 3/5] dma: Introduce dma_max_mapping_size()

[Joerg Roedel]

From: Joerg Roedel 

The function returns the maximum size that can be mapped
using DMA-API functions. The patch also adds the
implementation for direct DMA and a new dma_map_ops pointer
so that other implementations can expose their limit.

Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Joerg Roedel 
---
 Documentation/DMA-API.txt   |  8 
 include/linux/dma-mapping.h | 16 
 kernel/dma/direct.c | 12 
 3 files changed, 36 insertions(+)

diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index e133ccd60228..acfe3d0f78d1 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -195,6 +195,14 @@ Requesting the required mask does not alter the current 
mask.  If you
 wish to take advantage of it, you should issue a dma_set_mask()
 call to set the mask to the value returned.
 
+::
+
+   size_t
+   dma_direct_max_mapping_size(struct device *dev);
+
+Returns the maximum size of a mapping for the device. The size parameter
+of the mapping functions like dma_map_single(), dma_map_page() and
+others should not be larger than the returned value.
 
 Part Id - Streaming DMA mappings
 
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index f6ded992c183..a3ca8a71a704 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -130,6 +130,7 @@ struct dma_map_ops {
enum dma_data_direction direction);
int (*dma_supported)(struct device *dev, u64 mask);
u64 (*get_required_mask)(struct device *dev);
+   size_t (*max_mapping_size)(struct device *dev);
 };
 
 #define DMA_MAPPING_ERROR  (~(dma_addr_t)0)
@@ -257,6 +258,8 @@ static inline void dma_direct_sync_sg_for_cpu(struct device 
*dev,
 }
 #endif
 
+size_t dma_direct_max_mapping_size(struct device *dev);
+
 #ifdef CONFIG_HAS_DMA
 #include 
 
@@ -440,6 +443,19 @@ static inline int dma_mapping_error(struct device *dev, 
dma_addr_t dma_addr)
return 0;
 }
 
+static inline size_t dma_max_mapping_size(struct device *dev)
+{
+   const struct dma_map_ops *ops = get_dma_ops(dev);
+   size_t size = SIZE_MAX;
+
+   if (dma_is_direct(ops))
+   size = dma_direct_max_mapping_size(dev);
+   else if (ops && ops->max_mapping_size)
+   size = ops->max_mapping_size(dev);
+
+   return size;
+}
+
 void *dma_alloc_attrs(struct device *dev, size_t size, dma_addr_t *dma_handle,
gfp_t flag, unsigned long attrs);
 void dma_free_attrs(struct device *dev, size_t size, void *cpu_addr,
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 355d16acee6d..81ca8170b928 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -380,3 +380,15 @@ int dma_direct_supported(struct device *dev, u64 mask)
 */
return mask >= __phys_to_dma(dev, min_mask);
 }
+
+size_t dma_direct_max_mapping_size(struct device *dev)
+{
+   size_t size = SIZE_MAX;
+
+   /* If SWIOTLB is active, use its maximum mapping size */
+   if (is_swiotlb_active())
+   size = swiotlb_max_mapping_size(dev);
+
+   return size;
+}
+EXPORT_SYMBOL(dma_direct_max_mapping_size);
-- 
2.17.1

[PATCH 0/5 v5] Fix virtio-blk issue with SWIOTLB

[Joerg Roedel]

Hi,

here is the next version of this patch-set. Previous
versions can be found here:

V1: https://lore.kernel.org/lkml/20190110134433.15672-1-j...@8bytes.org/

V2: https://lore.kernel.org/lkml/20190115132257.6426-1-j...@8bytes.org/

V3: https://lore.kernel.org/lkml/20190123163049.24863-1-j...@8bytes.org/

V4: https://lore.kernel.org/lkml/20190129084342.26030-1-j...@8bytes.org/

The problem solved here is a limitation of the SWIOTLB implementation,
which does not support allocations larger than 256kb.  When the
virtio-blk driver tries to read/write a block larger than that, the
allocation of the dma-handle fails and an IO error is reported.

Changes to v4 are:

- Added Reviewed-by tags from Christoph

- Added missing EXPORT_SYMBOL(_GPL) lines

Please review.

Thanks,

Joerg
Joerg Roedel (5):
  swiotlb: Introduce swiotlb_max_mapping_size()
  swiotlb: Add is_swiotlb_active() function
  dma: Introduce dma_max_mapping_size()
  virtio: Introduce virtio_max_dma_size()
  virtio-blk: Consider virtio_max_dma_size() for maximum segment size

 Documentation/DMA-API.txt|  8 
 drivers/block/virtio_blk.c   | 10 ++
 drivers/virtio/virtio_ring.c | 11 +++
 include/linux/dma-mapping.h  | 16 
 include/linux/swiotlb.h  | 11 +++
 include/linux/virtio.h   |  2 ++
 kernel/dma/direct.c  | 12 
 kernel/dma/swiotlb.c | 14 ++
 8 files changed, 80 insertions(+), 4 deletions(-)

-- 
2.17.1

Re: [PATCH v2] ALSA: hda/tegra: enable clock during probe

[Takashi Iwai]

On Wed, 30 Jan 2019 13:45:49 +0100,
Jon Hunter wrote:
> 
> 
> On 25/01/2019 11:06, Sameer Pujar wrote:
> > If CONFIG_PM is disabled or runtime PM calls are forbidden, the clocks
> > will not be ON. This could cause issue during probe, where hda init
> > setup is done. This patch enables clocks unconditionally during probe.
> > 
> > Along with above, follwoing changes are done.
> >   * enable runtime PM before exiting from probe work. This helps to avoid
> > usage of pm_runtime_get_sync/pm_runtime_put() in probe work.
> >   * hda_tegra_disable_clocks() is moved out of CONFIG_PM_SLEEP check.
> >   * runtime PM callbacks moved out of CONFIG_PM check
> > 
> > Signed-off-by: Sameer Pujar 
> > Reviewed-by: Ravindra Lokhande 
> > Reviewed-by: Jon Hunter 
> > ---
> >  sound/pci/hda/hda_tegra.c | 26 +-
> >  1 file changed, 17 insertions(+), 9 deletions(-)
> > 
> > diff --git a/sound/pci/hda/hda_tegra.c b/sound/pci/hda/hda_tegra.c
> > index c8d18dc..ba6175f 100644
> > --- a/sound/pci/hda/hda_tegra.c
> > +++ b/sound/pci/hda/hda_tegra.c
> > @@ -219,7 +219,6 @@ static int hda_tegra_enable_clocks(struct hda_tegra 
> > *data)
> > return rc;
> >  }
> >  
> > -#ifdef CONFIG_PM_SLEEP
> >  static void hda_tegra_disable_clocks(struct hda_tegra *data)
> >  {
> > clk_disable_unprepare(data->hda2hdmi_clk);
> > @@ -227,6 +226,7 @@ static void hda_tegra_disable_clocks(struct hda_tegra 
> > *data)
> > clk_disable_unprepare(data->hda_clk);
> >  }
> >  
> > +#ifdef CONFIG_PM_SLEEP
> >  /*
> >   * power management
> >   */
> > @@ -257,7 +257,6 @@ static int hda_tegra_resume(struct device *dev)
> >  }
> >  #endif /* CONFIG_PM_SLEEP */
> >  
> > -#ifdef CONFIG_PM
> >  static int hda_tegra_runtime_suspend(struct device *dev)
> >  {
> > struct snd_card *card = dev_get_drvdata(dev);
> > @@ -283,7 +282,7 @@ static int hda_tegra_runtime_resume(struct device *dev)
> > int rc;
> >  
> > rc = hda_tegra_enable_clocks(hda);
> > -   if (rc != 0)
> > +   if (rc)
> > return rc;
> > if (chip && chip->running) {
> > hda_tegra_init(hda);
> > @@ -292,7 +291,6 @@ static int hda_tegra_runtime_resume(struct device *dev)
> >  
> > return 0;
> >  }
> > -#endif /* CONFIG_PM */
> >  
> >  static const struct dev_pm_ops hda_tegra_pm = {
> > SET_SYSTEM_SLEEP_PM_OPS(hda_tegra_suspend, hda_tegra_resume)
> > @@ -551,9 +549,9 @@ static int hda_tegra_probe(struct platform_device *pdev)
> >  
> > dev_set_drvdata(&pdev->dev, card);
> >  
> > -   pm_runtime_enable(hda->dev);
> > -   if (!azx_has_pm_runtime(chip))
> > -   pm_runtime_forbid(hda->dev);
> > +   err = hda_tegra_enable_clocks(hda);
> > +   if (err)
> > +   goto out_free;
> 
> We also need to think about power-domains here. Enabling the clocks
> might not be enough as the appropriate power-domain needs to be enabled.
> For 64-bit Tegra runtime-pm will handle the power-domains (assuming they
> are populated in device-tree). So I still think it is better we call
> pm_runtime_get_sync() at some point rather than just replying on
> enabling the clocks.

If I understand correctly the code, the pm domain is already activated
at calling driver's probe callback.


thanks,

Takashi

[PATCH 1/5] swiotlb: Introduce swiotlb_max_mapping_size()

[Joerg Roedel]

From: Joerg Roedel 

The function returns the maximum size that can be remapped
by the SWIOTLB implementation. This function will be later
exposed to users through the DMA-API.

Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Joerg Roedel 
---
 include/linux/swiotlb.h | 5 +
 kernel/dma/swiotlb.c| 5 +
 2 files changed, 10 insertions(+)

diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 7c007ed7505f..1c22d96e1742 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -62,6 +62,7 @@ extern void swiotlb_tbl_sync_single(struct device *hwdev,
 
 extern int
 swiotlb_dma_supported(struct device *hwdev, u64 mask);
+size_t swiotlb_max_mapping_size(struct device *dev);
 
 #ifdef CONFIG_SWIOTLB
 extern enum swiotlb_force swiotlb_force;
@@ -95,6 +96,10 @@ static inline unsigned int swiotlb_max_segment(void)
 {
return 0;
 }
+static inline size_t swiotlb_max_mapping_size(struct device *dev)
+{
+   return SIZE_MAX;
+}
 #endif /* CONFIG_SWIOTLB */
 
 extern void swiotlb_print_info(void);
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 1fb6fd68b9c7..9cb21259cb0b 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -662,3 +662,8 @@ swiotlb_dma_supported(struct device *hwdev, u64 mask)
 {
return __phys_to_dma(hwdev, io_tlb_end - 1) <= mask;
 }
+
+size_t swiotlb_max_mapping_size(struct device *dev)
+{
+   return ((size_t)1 << IO_TLB_SHIFT) * IO_TLB_SEGSIZE;
+}
-- 
2.17.1

Re: [RESEND PATCH v4 0/3] fs/dcache: Track # of negative dentries

[Waiman Long]

On 01/15/2019 04:27 PM, Waiman Long wrote:
> On 12/16/2018 02:37 PM, Linus Torvalds wrote:
>> On Fri, Dec 14, 2018 at 1:53 PM Waiman Long  wrote:
>>> This patchset addresses 2 issues found in the dentry code and adds a
>>> new nr_dentry_negative per-cpu counter to track the total number of
>>> negative dentries in all the LRU lists.
>> The series looks sane to me. I'm assuming I'll get it either though
>> -mm or from Al..
>>
>> Linus
> Could anyone pick up this patchset?
>
> Thanks,
> Longman
>
Ping. Will this patch be picked up?

Thanks,
Longman

[PATCH 4/5] virtio: Introduce virtio_max_dma_size()

[Joerg Roedel]

From: Joerg Roedel 

This function returns the maximum segment size for a single
dma transaction of a virtio device. The possible limit comes
from the SWIOTLB implementation in the Linux kernel, that
has an upper limit of (currently) 256kb of contiguous
memory it can map. Other DMA-API implementations might also
have limits.

Use the new dma_max_mapping_size() function to determine the
maximum mapping size when DMA-API is in use for virtio.

Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Joerg Roedel 
---
 drivers/virtio/virtio_ring.c | 11 +++
 include/linux/virtio.h   |  2 ++
 2 files changed, 13 insertions(+)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index cd7e755484e3..8a31c6862b2b 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -266,6 +266,17 @@ static bool vring_use_dma_api(struct virtio_device *vdev)
return false;
 }
 
+size_t virtio_max_dma_size(struct virtio_device *vdev)
+{
+   size_t max_segment_size = SIZE_MAX;
+
+   if (vring_use_dma_api(vdev))
+   max_segment_size = dma_max_mapping_size(&vdev->dev);
+
+   return max_segment_size;
+}
+EXPORT_SYMBOL_GPL(virtio_max_dma_size);
+
 static void *vring_alloc_queue(struct virtio_device *vdev, size_t size,
  dma_addr_t *dma_handle, gfp_t flag)
 {
diff --git a/include/linux/virtio.h b/include/linux/virtio.h
index fa1b5da2804e..673fe3ef3607 100644
--- a/include/linux/virtio.h
+++ b/include/linux/virtio.h
@@ -157,6 +157,8 @@ int virtio_device_freeze(struct virtio_device *dev);
 int virtio_device_restore(struct virtio_device *dev);
 #endif
 
+size_t virtio_max_dma_size(struct virtio_device *vdev);
+
 #define virtio_device_for_each_vq(vdev, vq) \
list_for_each_entry(vq, &vdev->vqs, list)
 
-- 
2.17.1

[PATCH 1/2] x86/boot: fix KASL when memmap range manipulation is used

[Julian Stecklina]

From: Julian Stecklina 

When the user passes a memmap=%-+
parameter to the kernel to reclassify some memory, this information is
ignored during the randomization of the kernel base address. This in
turn leads to cases where the kernel is unpacked to memory regions that
the user marked as reserved.

Fix this situation to avoid any memory region for KASLR that is
reclassified.

Fixes: ef61f8a340fd6d49df6b367785743febc47320c1 ("x86/boot/e820: Implement a 
range manipulation operator")

Signed-off-by: Julian Stecklina 
---
 arch/x86/boot/compressed/kaslr.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 9ed9709..5657e34 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -155,6 +155,12 @@ parse_memmap(char *p, unsigned long long *start, unsigned 
long long *size)
case '#':
case '$':
case '!':
+   /*
+* % would need some more complex parsing, because regions might
+* actually become usable for KASLR, but the simple way of
+* ignoring anything that is mentioned in % works for now.
+*/
+   case '%':
*start = memparse(p + 1, &p);
return 0;
case '@':
-- 
2.7.4

Re: [PATCH v2 3/7] scsi: libsas: optimize the debug print of the revalidate process

[John Garry]

On 30/01/2019 08:24, Jason Yan wrote:

sas_rediscover() returns error code if discover failed for a expander
phy. And sas_ex_revalidate_domain() only returns the last phy's error
code. So when sas_revalidate_domain() prints the return value of the
discover process, we do not know if the revalidation for every phy is
successful or not. We just know the last bcast phy revalidation
succeeded or not.

No need to return a error code for sas_ex_revalidate_domain() and
sas_rediscover(), and just print the debug log for each bcast phy directly
in sas_rediscover().


do we want to know about every PHY, or just the PHY where res != 0?





I don't see any optimisation here. Maybe an improvement.



Signed-off-by: Jason Yan 
CC: John Garry 
CC: Johannes Thumshirn 
CC: Ewan Milne 
CC: Christoph Hellwig 
CC: Tomas Henzl 
CC: Dan Williams 
CC: Hannes Reinecke 
---
 drivers/scsi/libsas/sas_discover.c |  7 +++
 drivers/scsi/libsas/sas_expander.c | 11 ++-
 include/scsi/libsas.h  |  2 +-
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/scsi/libsas/sas_discover.c 
b/drivers/scsi/libsas/sas_discover.c
index 726ada9b8c79..ffc571a12916 100644
--- a/drivers/scsi/libsas/sas_discover.c
+++ b/drivers/scsi/libsas/sas_discover.c
@@ -500,7 +500,6 @@ static void sas_discover_domain(struct work_struct *work)

 static void sas_revalidate_domain(struct work_struct *work)
 {
-   int res = 0;
struct sas_discovery_event *ev = to_sas_discovery_event(work);
struct asd_sas_port *port = ev->port;
struct sas_ha_struct *ha = port->ha;
@@ -521,10 +520,10 @@ static void sas_revalidate_domain(struct work_struct 
*work)

if (ddev && (ddev->dev_type == SAS_FANOUT_EXPANDER_DEVICE ||
 ddev->dev_type == SAS_EDGE_EXPANDER_DEVICE))
-   res = sas_ex_revalidate_domain(ddev);
+   sas_ex_revalidate_domain(ddev);

-   pr_debug("done REVALIDATING DOMAIN on port %d, pid:%d, res 0x%x\n",
-port->id, task_pid_nr(current), res);
+   pr_debug("done REVALIDATING DOMAIN on port %d, pid:%d\n",
+port->id, task_pid_nr(current));
  out:
mutex_unlock(&ha->disco_mutex);

diff --git a/drivers/scsi/libsas/sas_expander.c 
b/drivers/scsi/libsas/sas_expander.c
index 7b0e6dcef6e6..5cd720f93f96 100644
--- a/drivers/scsi/libsas/sas_expander.c
+++ b/drivers/scsi/libsas/sas_expander.c
@@ -2062,7 +2062,7 @@ static int sas_rediscover_dev(struct domain_device *dev, 
int phy_id, bool last)
  * first phy,for other phys in this port, we add it to the port to
  * forming the wide-port.
  */
-static int sas_rediscover(struct domain_device *dev, const int phy_id)
+static void sas_rediscover(struct domain_device *dev, const int phy_id)
 {
struct expander_device *ex = &dev->ex_dev;
struct ex_phy *changed_phy = &ex->ex_phy[phy_id];
@@ -2090,7 +2090,9 @@ static int sas_rediscover(struct domain_device *dev, 
const int phy_id)
res = sas_rediscover_dev(dev, phy_id, last);
} else
res = sas_discover_new(dev, phy_id);
-   return res;
+
+   pr_debug("ex %016llx phy%d discover returned 0x%x\n",


Hmmm.. this is not just discover, but also rediscover


+SAS_ADDR(dev->sas_addr), phy_id, res);
 }

 /**
@@ -2102,7 +2104,7 @@ static int sas_rediscover(struct domain_device *dev, 
const int phy_id)
  * Discover process only interrogates devices in order to discover the
  * domain.
  */
-int sas_ex_revalidate_domain(struct domain_device *port_dev)
+void sas_ex_revalidate_domain(struct domain_device *port_dev)
 {
int res;
struct domain_device *dev = NULL;
@@ -2117,11 +2119,10 @@ int sas_ex_revalidate_domain(struct domain_device 
*port_dev)
res = sas_find_bcast_phy(dev, &phy_id, i, true);


this was missed


if (phy_id == -1)
break;
-   res = sas_rediscover(dev, phy_id);
+   sas_rediscover(dev, phy_id);
i = phy_id + 1;
} while (i < ex->num_phys);
}
-   return res;
 }

 void sas_smp_handler(struct bsg_job *job, struct Scsi_Host *shost,
diff --git a/include/scsi/libsas.h b/include/scsi/libsas.h
index 420156cea3ee..e557bcb0c266 100644
--- a/include/scsi/libsas.h
+++ b/include/scsi/libsas.h
@@ -692,7 +692,7 @@ int  sas_discover_root_expander(struct domain_device *);

 void sas_init_ex_attr(void);

-int  sas_ex_revalidate_domain(struct domain_device *);
+void sas_ex_revalidate_domain(struct domain_device *);

 void sas_unregister_domain_devices(struct asd_sas_port *port, int gone);
 void sas_init_disc(struct sas_discovery *disc, struct asd_sas_port *);

[PATCH 2/2] x86/boot: increase maximum number of avoided KASLR regions

[Julian Stecklina]

From: Julian Stecklina 

The boot code has a limit of 4 "non-standard" regions to avoid for
KASLR. This limit is easy to reach when supplying memmap= parameters to
the kernel. In this case, KASLR would be disabled.

Increase the limit to avoid turning off KASLR even when the user is
heavily manipulating the memory map.

Signed-off-by: Julian Stecklina 
---
 arch/x86/boot/compressed/kaslr.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 5657e34..f078d60 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -92,8 +92,8 @@ struct mem_vector {
unsigned long long size;
 };
 
-/* Only supporting at most 4 unusable memmap regions with kaslr */
-#define MAX_MEMMAP_REGIONS 4
+/* Only supporting at most this many unusable memmap regions with kaslr */
+#define MAX_MEMMAP_REGIONS 16
 
 static bool memmap_too_large;
 
@@ -213,7 +213,7 @@ static void mem_avoid_memmap(char *str)
i++;
}
 
-   /* More than 4 memmaps, fail kaslr */
+   /* Can't store all regions, fail kaslr */
if ((i >= MAX_MEMMAP_REGIONS) && str)
memmap_too_large = true;
 }
-- 
2.7.4

Re: [PATCH v3 2/2] dt-bindings: interrupt-controller: loongson ls1x intc

[Rob Herring]

On Thu, Jan 24, 2019 at 11:27:30AM +0800, Jiaxun Yang wrote:
> Dt-bindings doc about Loongson-1 interrupt controller
> 
> Signed-off-by: Jiaxun Yang 
> ---
>  .../loongson,ls1x-intc.txt| 24 +++
>  1 file changed, 24 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/interrupt-controller/loongson,ls1x-intc.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/interrupt-controller/loongson,ls1x-intc.txt
>  
> b/Documentation/devicetree/bindings/interrupt-controller/loongson,ls1x-intc.txt
> new file mode 100644
> index ..a4e17c3f5f93
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/interrupt-controller/loongson,ls1x-intc.txt
> @@ -0,0 +1,24 @@
> +Loongson ls1x Interrupt Controller
> +
> +Required properties:
> +
> +- compatible : should be "loongson,ls1x-intc". Valid strings are:
> +
> +- reg : Specifies base physical address and size of the registers.
> +- interrupt-controller : Identifies the node as an interrupt controller
> +- #interrupt-cells : Specifies the number of cells needed to encode an
> +  interrupt source. The value shall be 1.
> +- interrupts : Specifies the CPU interrupts the controller is connected to.
> +
> +Example:
> +
> +intc: interrupt-controller@1fd01040 {
> + compatible = "loongson,ls1x-intc";
> + reg = <0x1fd01040 0x78>;
> +
> + interrupt-controller;
> + #interrupt-cells = <1>;
> +
> + interrupt-parent = <&cpu_intc>;
> + interrupts = <2>, <3>, <4>, <5>, <6>;
> +};
> \ No newline at end of file

Please fix.

Otherwise,

Reviewed-by: Rob Herring 

Re: [PATCH v6 12/13] KVM: s390: add gib_alert_irq_handler()

[Michael Mueller]

On 30.01.19 17:24, Pierre Morel wrote:

On 29/01/2019 16:29, Michael Mueller wrote:



On 29.01.19 14:26, Halil Pasic wrote:

On Thu, 24 Jan 2019 13:59:38 +0100
Michael Mueller  wrote:


The patch implements a handler for GIB alert interruptions
on the host. Its task is to alert guests that interrupts are
pending for them.

A GIB alert interrupt statistic counter is added as well:

$ cat /proc/interrupts
   CPU0   CPU1
   ...
   GAL:  23 37   [I/O] GIB Alert
   ...

Signed-off-by: Michael Mueller 

[..]

+/**
+ * gisa_get_ipm_or_restore_iam - return IPM or restore GISA IAM
+ *
+ * @gi: gisa interrupt struct to work on
+ *
+ * Atomically restores the interruption alert mask if none of the
+ * relevant ISCs are pending and return the IPM.


The word 'relevant' probably reflects some previous state. It does not
bother me too much.


"relevant" refers to the ISCs handled by the GAL mechanism, i.e those
registered in the kvm->arch.gisa_int.alert.mask.



[..]

+static void __airqs_kick_single_vcpu(struct kvm *kvm, u8 
deliverable_mask)

+{
+    int vcpu_id, online_vcpus = atomic_read(&kvm->online_vcpus);
+    struct kvm_s390_gisa_interrupt *gi = &kvm->arch.gisa_int;
+    struct kvm_vcpu *vcpu;
+
+    for_each_set_bit(vcpu_id, kvm->arch.idle_mask, online_vcpus) {
+    vcpu = kvm_get_vcpu(kvm, vcpu_id);
+    if (psw_ioint_disabled(vcpu))
+    continue;
+    deliverable_mask &= (u8)(vcpu->arch.sie_block->gcr[6] >> 24);
+    if (deliverable_mask) {
+    /* lately kicked but not yet running */


How about /* was kicked but didn't run yet */?


what is the difference here...




+    if (test_and_set_bit(vcpu_id, gi->kicked_mask))
+    return;
+    kvm_s390_vcpu_wakeup(vcpu);
+    return;
+    }
+    }
+}
+


[..]


+static void process_gib_alert_list(void)
+{
+    struct kvm_s390_gisa_interrupt *gi;
+    struct kvm_s390_gisa *gisa;
+    struct kvm *kvm;
+    u32 final, origin = 0UL;
+
+    do {
+    /*
+ * If the NONE_GISA_ADDR is still stored in the alert list
+ * origin, we will leave the outer loop. No further GISA has
+ * been added to the alert list by millicode while processing
+ * the current alert list.
+ */
+    final = (origin & NONE_GISA_ADDR);
+    /*
+ * Cut off the alert list and store the NONE_GISA_ADDR in the
+ * alert list origin to avoid further GAL interruptions.
+ * A new alert list can be build up by millicode in parallel
+ * for guests not in the yet cut-off alert list. When in the
+ * final loop, store the NULL_GISA_ADDR instead. This will re-
+ * enable GAL interruptions on the host again.
+ */
+    origin = xchg(&gib->alert_list_origin,
+  (!final) ? NONE_GISA_ADDR : NULL_GISA_ADDR);
+    /*
+ * Loop through the just cut-off alert list and start the
+ * gisa timers to kick idle vcpus to consume the pending
+ * interruptions asap.
+ */
+    while (origin & GISA_ADDR_MASK) {
+    gisa = (struct kvm_s390_gisa *)(u64)origin;
+    origin = gisa->next_alert;
+    gisa->next_alert = (u32)(u64)gisa;
+    kvm = container_of(gisa, struct sie_page2, gisa)->kvm;
+    gi = &kvm->arch.gisa_int;
+    if (hrtimer_active(&gi->timer))
+    hrtimer_cancel(&gi->timer);
+    hrtimer_start(&gi->timer, 0, HRTIMER_MODE_REL);
+    }
+    } while (!final);
+
+}
+
  void kvm_s390_gisa_clear(struct kvm *kvm)
  {
  struct kvm_s390_gisa_interrupt *gi = &kvm->arch.gisa_int;
  if (!gi->origin)
  return;
-    memset(gi->origin, 0, sizeof(struct kvm_s390_gisa));
-    gi->origin->next_alert = (u32)(u64)gi->origin;
+    gisa_clear_ipm(gi->origin);


This could be a separate patch. I would like little more explanation
to this.


I can break at out as I had before... ;)




  VM_EVENT(kvm, 3, "gisa 0x%pK cleared", gi->origin);
  }
@@ -2940,13 +3078,25 @@ void kvm_s390_gisa_init(struct kvm *kvm)
  gi->origin = &kvm->arch.sie_page2->gisa;
  gi->alert.mask = 0;
  spin_lock_init(&gi->alert.ref_lock);
-    kvm_s390_gisa_clear(kvm);
+    gi->expires = 50 * 1000; /* 50 usec */


I blindly trust your choice here ;)


You know I will increase it to 1 ms together with the change that I
proposed. (gisa_get_ipm_or_restore_iam() in kvm_s390_handle_wait()).


With this.
Reviewed-by: Pierre Morel


Pierre,

please see my mail with the measurements that I have done. Up to that
I can't take your Reviewed-by. I will keep the 50 usec.

Michael

Re: [PATCH v3 2/3] dt-bindings: PCI: dra7xx: Add properties to enable x2 lane in dra7

[Rob Herring]

On Thu, 24 Jan 2019 13:59:56 +0530, Kishon Vijay Abraham I wrote:
> Add syscon properties required for configuring PCIe in x2 lane mode.
> 
> Signed-off-by: Kishon Vijay Abraham I 
> Signed-off-by: Sekhar Nori 
> ---
>  Documentation/devicetree/bindings/pci/ti-pci.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 

Reviewed-by: Rob Herring 

Re: [PATCH v3 1/3] dt-bindings: usb: Add support for msm8998

[Jeffrey Hugo]

On 1/30/2019 8:42 AM, Rob Herring wrote:

On Mon, Jan 21, 2019 at 02:32:46PM -0700, Jeffrey Hugo wrote:

msm8998 USB has a dwc3 controller just like the existing sdm845 support.

Signed-off-by: Jeffrey Hugo 
Reviewed-by: Bjorn Andersson 
---
  Documentation/devicetree/bindings/usb/qcom,dwc3.txt | 1 +
  1 file changed, 1 insertion(+)


You missed my R-by.



Drat.  Sorry.

--
Jeffrey Hugo
Qualcomm Datacenter Technologies as an affiliate of Qualcomm 
Technologies, Inc.

Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH 3/4] arm64: dts: sprd: Add SC2731 charger device

[Arnd Bergmann]

On Mon, Jan 21, 2019 at 8:39 AM Baolin Wang  wrote:
>
> Add charger device node and related battery node for SC2731 PMIC.
>
> Signed-off-by: Baolin Wang 
> ---
>  arch/arm64/boot/dts/sprd/sc2731.dtsi  |6 ++
>  arch/arm64/boot/dts/sprd/sp9860g-1h10.dts |   16 
>  2 files changed, 22 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/sprd/sc2731.dtsi 
> b/arch/arm64/boot/dts/sprd/sc2731.dtsi
> index a2edc25..b52eaf0 100644
> --- a/arch/arm64/boot/dts/sprd/sc2731.dtsi
> +++ b/arch/arm64/boot/dts/sprd/sc2731.dtsi
> @@ -17,6 +17,12 @@
> #address-cells = <1>;
> #size-cells = <0>;
>
> +   charger@0 {
> +   compatible = "sprd,sc27xx-charger", 
> "sprd,sc2731-charger";
> +   reg = <0x0>;
> +   monitored-battery = <&bat>;
> +   };

I see some of these have already slipped through, but we should probably
fix those and not add new ones: "sprd,sc27xx-charger" is not an appropriate
compatible string, because it has a 'xx' wildcard.

What you should have instead is to list compatibility with specific older
models. You also need to have the more generic string as the last one,
not the first.

 Arnd

Re: [PATCH 2/5] ARCv2: introduce unaligned access under a Kconfig option

[Eugeniy Paltsev]

On Tue, 2019-01-29 at 21:44 +, Vineet Gupta wrote:
> On 1/29/19 2:49 AM, Eugeniy Paltsev wrote:
> > As of today we enable unaligned access unconditionally on ARCv2.
> > Lets move it under Kconfig option so we can disable it in case of
> > using HW configuration which lacks of it.
> > 
> > Signed-off-by: Eugeniy Paltsev 
> > ---
> >  arch/arc/Kconfig  | 8 
> >  arch/arc/include/asm/irqflags-arcv2.h | 4 
> >  arch/arc/kernel/intc-arcv2.c  | 4 +++-
> >  3 files changed, 15 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arc/include/asm/irqflags-arcv2.h 
> > b/arch/arc/include/asm/irqflags-arcv2.h
> > index 8a4f77ea3238..9b911e2c6b31 100644
> > --- a/arch/arc/include/asm/irqflags-arcv2.h
> > +++ b/arch/arc/include/asm/irqflags-arcv2.h
> > @@ -44,8 +44,12 @@
> >  #define ARCV2_IRQ_DEF_PRIO 1
> >  
> >  /* seed value for status register */
> > +#ifdef CONFIG_ARC_USE_UNALIGNED_MEM_ACCESS
> >  #define ISA_INIT_STATUS_BITS   (STATUS_IE_MASK | STATUS_AD_MASK | \
> > (ARCV2_IRQ_DEF_PRIO << 1))
> > +#else
> > +#define ISA_INIT_STATUS_BITS   (STATUS_IE_MASK | (ARCV2_IRQ_DEF_PRIO 
> > << 1))
> > +#endif /* CONFIG_ARC_USE_UNALIGNED_MEM_ACCESS */
> 
> I'd prefer to change the define of STATUS_AD_MASK itself and keep all of this
> unchanged !
> 

Actually I'd prefer to leave STATUS_AD_MASK untouched. Otherwise we will 
implicitly assign
wrong value to STATUS_AD_MASK which is quite misleading.

BTW, STATUS_AD_MASK is used in ASM code in v2 patch and it shouldn't be 
dependent on
CONFIG_ARC_USE_UNALIGNED_MEM_ACCESS.

-- 
 Eugeniy Paltsev

Re: [PATCH] x86: avoid confusion over the new RESCTRL config prompt

[Johannes Weiner]

On Wed, Jan 30, 2019 at 12:08:45AM +0100, Borislav Petkov wrote:
> On Tue, Jan 29, 2019 at 05:52:18PM -0500, Johannes Weiner wrote:
> > "Resource Control" is a very broad term for this CPU feature, and a
> > term that is also associated with containers, cgroups etc. This can
> > easily cause confusion.
> > 
> > Make the user prompt more specific.
> > 
> > Signed-off-by: Johannes Weiner 
> > ---
> >  arch/x86/Kconfig | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > As somebody who works in "resource control", this prompt in oldconfig
> > certainly had me go wtf. Can we do something more specific?
> 
> Well, since this is an interface to a hardware feature, we could call it
> 
> Hardware Resource Control
> 
> for example. I.e., HW_RESCTRL.
> 
> Linus had another suggestion - CPU_RESCTRL - which sounds ok to me too.
> 
> > Not insisting on this name, and I haven't renamed all the config
> > symbols yet, but we should probably fix this before 5.0 is released.
> > 
> > Thanks!
> > 
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index 26387c7bf305..426677b759c0 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -447,11 +447,11 @@ config RETPOLINE
> >   support for full protection. The kernel may run slower.
> >  
> >  config X86_RESCTRL
> > -   bool "Resource Control support"
> > +   bool "x86 cache control support"
> 
> Except that it is not only cache but memory (bandwidth) control too. So I 
> guess
> 
>   bool "CPU Resource Control support"

This is still awefully close to the cgroup CPU resource
controller. Since it's more hardware-specific, and the config symbol
also has the x86 in it, how about "x86 CPU resource control support"?

---

>From 2a24f6e30ed9dbc0abb96c73ec0e205e07034383 Mon Sep 17 00:00:00 2001
From: Johannes Weiner 
Date: Tue, 29 Jan 2019 17:44:36 -0500
Subject: [PATCH] x86: avoid confusion over the new RESCTRL config prompt

"Resource Control" is a very broad term for this CPU feature, and a
term that is also associated with containers, cgroups etc. This can
easily cause confusion.

Make the user prompt more specific.

Signed-off-by: Johannes Weiner 
---
 arch/x86/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 26387c7bf305..ac432379df11 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -447,11 +447,11 @@ config RETPOLINE
  support for full protection. The kernel may run slower.
 
 config X86_RESCTRL
-   bool "Resource Control support"
+   bool "x86 CPU resource control support"
depends on X86 && (CPU_SUP_INTEL || CPU_SUP_AMD)
select KERNFS
help
- Enable Resource Control support.
+ Enable x86 CPU resource control support.
 
  Provide support for the allocation and monitoring of system resources
  usage by the CPU.
-- 
2.20.1

Re: [PATCH 0/4] Add new device nodes for Spreadtrum SC9860 platform

[Arnd Bergmann]

On Mon, Jan 21, 2019 at 8:39 AM Baolin Wang  wrote:
>
> This patch set adds charger and fuel gauge device nodes for Spreadtrum
> SC2731 PMIC, it also removes redundant irq trigger setting for PMIC
> devices and adds nvmem cells for ADC to calibrate the ADC channel scales.
>
> Baolin Wang (4):
>   arm64: dts: sprd: Remove PMIC INTC irq trigger type
>   arm64: dts: sprd: Add ADC calibration support
>   arm64: dts: sprd: Add SC2731 charger device
>   arm64: dts: sprd: Add SC27XX fuel gauge device

I did not apply these because of the 'sc27xx' wildcard matching.

Please fix those up and resend.

  Arnd

Re: [PATCH 2/5] ARCv2: introduce unaligned access under a Kconfig option

[Vineet Gupta]

On 1/30/19 8:44 AM, Eugeniy Paltsev wrote:
>> I'd prefer to change the define of STATUS_AD_MASK itself and keep all of this
>> unchanged !
>>
> Actually I'd prefer to leave STATUS_AD_MASK untouched. Otherwise we will 
> implicitly assign
> wrong value to STATUS_AD_MASK which is quite misleading.
>
> BTW, STATUS_AD_MASK is used in ASM code in v2 patch and it shouldn't be 
> dependent on
> CONFIG_ARC_USE_UNALIGNED_MEM_ACCESS.

Agree !

-Vineet

Re: [PATCH 2/2] mm: Consider subtrees in memory.events

[Michal Hocko]

On Tue 29-01-19 06:52:40, Tejun Heo wrote:
> Hello,
> 
> On Tue, Jan 29, 2019 at 03:43:06PM +0100, Michal Hocko wrote:
> > All memcg events are represented non-hierarchical AFAICS
> > memcg_memory_event() simply accounts at the level when it happens. Or do
> > I miss something? Or are you talking about .events files for other
> > controllers?
> 
> Yeah, cgroup.events and .stat files as some of the local stats would
> be useful too, so if we don't flip memory.events we'll end up with sth
> like cgroup.events.local, memory.events.tree and memory.stats.local,
> which is gonna be hilarious.

Why cannot we simply have memory.events_tree and be done with it? Sure
the file names are not goin to be consistent which is a minus but that
ship has already sailed some time ago.

> If you aren't willing to change your mind, the only option seems to be
> introducing a mount option to gate the flip and additions of local
> files.  Most likely, userspace will enable the option by default
> everywhere, so the end result will be exactly the same but I guess
> it'll better address your concern.

How does the consumer of the API learns about the mount type?
-- 
Michal Hocko
SUSE Labs

Re: [PATCH v3 2/3] dt-bindings: crypto: document Exynos5433 SlimSSS

[Rob Herring]

On Thu, Jan 24, 2019 at 04:45:20PM +0100, Kamil Konieczny wrote:
> Document DT bindings for crypto Samsung Exynos5433 SlimSSS (Slim Security
> SubSystem) IP.
> 
> Reviewed-by: Krzysztof Kozlowski 
> Signed-off-by: Kamil Konieczny 
> ---
>  .../devicetree/bindings/crypto/samsung-sss.txt | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/crypto/samsung-sss.txt 
> b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
> index 7a5ca56683cc..d9af679d38ab 100644
> --- a/Documentation/devicetree/bindings/crypto/samsung-sss.txt
> +++ b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
> @@ -1,4 +1,4 @@
> -Samsung SoC SSS (Security SubSystem) module
> +Samsung SoC SSS (Security SubSystem) and SlimSSS module
>  
>  The SSS module in S5PV210 SoC supports the following:
>  -- Feeder (FeedCtrl)
> @@ -15,6 +15,12 @@ supports the following also:
>  -- True Random Number Generator (TRNG)
>  -- Secure Key Manager
>  
> +Exynos5433 has both SSS and SlimSSS module.

That's not really relevant to the binding.

What do the SSS and SlimSSS share? Only that both have a single reg and 
interrupt based on the binding? This should probably be just 2 
documents. If not now, it will have to be when converted to a DT schema.

> +SlimSSS in Exynos5433 supports:
> +-- Feeder (FeedCtrl)
> +-- Advanced Encryption Standard (AES)
> +-- SHA-1/SHA-256/HMAC (SHA-1/SHA-256)
> +
>  Required properties:
>  
>  - compatible : Should contain entries for this and backward compatible
> @@ -22,11 +28,13 @@ Required properties:
>- "samsung,s5pv210-secss" for S5PV210 SoC.
>- "samsung,exynos4210-secss" for Exynos4210, Exynos4212, Exynos4412, 
> Exynos5250,
>   Exynos5260 and Exynos5420 SoCs.
> +  - "samsung,exynos5433-slim-sss" for Exynos5433 SoCs.
>  - reg : Offset and length of the register set for the module
>  - interrupts : interrupt specifiers of SSS module interrupts (one feed
>   control interrupt).
>  
>  - clocks : list of clock phandle and specifier pairs for all clocks  listed 
> in
>   clock-names property.
> -- clock-names : list of device clock input names; should contain one entry
> - "secss".
> +- clock-names : list of device clock input names; should contain "pclk" and
> + "aclk" for slim-sss in Exynos5433, and one entry "secss" for
> + other compatibles.
> -- 
> 2.20.0
> 

Re: [PATCH 1/3] dt-bindings: dmaengine: Add one new cell to present hardware slave id

[Arnd Bergmann]

On Tue, Jan 22, 2019 at 2:21 PM Baolin Wang  wrote:
>
> The DMA engine clients can trigger DMA engine automatically by setting
> the corresponding hardware slave id for the DMA engine. Thus add one
> cell to present the hardware slave id for DMA clients.
>
> Signed-off-by: Baolin Wang 
> ---
>  Documentation/devicetree/bindings/dma/sprd-dma.txt |   12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/dma/sprd-dma.txt 
> b/Documentation/devicetree/bindings/dma/sprd-dma.txt
> index 7a10fea..7812cf0 100644
> --- a/Documentation/devicetree/bindings/dma/sprd-dma.txt
> +++ b/Documentation/devicetree/bindings/dma/sprd-dma.txt
> @@ -6,8 +6,8 @@ Required properties:
>  - compatible: Should be "sprd,sc9860-dma".
>  - reg: Should contain DMA registers location and length.
>  - interrupts: Should contain one interrupt shared by all channel.
> -- #dma-cells: must be <1>. Used to represent the number of integer
> -   cells in the dmas property of client device.
> +- #dma-cells: must be <2>. Used to represent the channel id and slave id
> +   of integer cells in the dmas property of client device.
>  - #dma-channels : Number of DMA channels supported. Should be 32.
>  - clock-names: Should contain the clock of the DMA controller.
>  - clocks: Should contain a clock specifier for each entry in clock-names.
> @@ -28,14 +28,16 @@ apdma: dma-controller@2010 {
>
>  Client:
>  DMA clients connected to the Spreadtrum DMA controller must use the format
> -described in the dma.txt file, using a two-cell specifier for each channel.
> -The two cells in order are:
> +described in the dma.txt file, using a three-cell specifier for each channel.
> +The three cells in order are:
>  1. A phandle pointing to the DMA controller.
>  2. The channel id.
> +3. The hardware slave id which is used for clients to trigger DMA engine
> +automatically.

I notice that this is an incompatible binding change. Is that necessary?
If the current code works, I'd suggest allowing both #dma-cells=<2>
and <3>, and then implementing both in the driver.

 Arnd

Re: [PATCH v2 7/9] usb: typec: Find the ports by also matching against the device node

[Andy Shevchenko]

On Wed, Jan 30, 2019 at 6:03 PM Heikki Krogerus
 wrote:
>
> When the connections are defined in firmware, struct
> device_connection will have the fwnode member pointing to
> the device node (struct fwnode_handle) of the requested
> device, and the endpoint will not be used at all in that
> case.

> +   /*
> +* FIXME: Check does the fwnode supports the requested SVID. If it 
> does
> +* we need to return ERR_PTR(-PROBE_DEFER) when there is no device.
> +*/
> +   if (con->fwnode)
> +   return class_find_device(typec_class, NULL, con->fwnode,
> +typec_port_fwnode_match);
> +
> +   dev = class_find_device(typec_class, NULL, con->endpoint[ep],
> +   typec_port_name_match);
> +
> +   return dev ? dev : ERR_PTR(-EPROBE_DEFER);

Just  to be clear, this one takes a reference on dev. Is it taken into account?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v6 4/7] cgroup: cgroup v2 freezer

[Oleg Nesterov]

Hi Roman,

On 01/28, Roman Gushchin wrote:
>
> Yes, I think you're right: cgroup_exit() should check CGRP_FREEZE bit,
> not CGRP_FROZEN. Like cgroup_post_fork() does (a one-liner change below).

but this won't fix all problems? it seems that you missed my other concerns.

Firstly, this doesn't look consistent. Suppose a cgroup contains a single
process sleeping in ptrace_stop(). Then it becomes CGRP_FROZEN right after
"echo 1 > cgroup.freeze".

OTOH. if this single task sleeps in do_freezer_trap() and gets PTRACE_INTERRUPT,
it will equally sleep ptrace_stop() but cgroup won't be CGRP_FROZEN. Never.

Worse, this looks just wrong. In the latter case, cgroup becomes CGRP_FROZEN
right after a 2nd task migrates to this cgroup, before this new task calls
do_freezer_trap() or cgroup_enter_stopped().



> About spurious transitions (like frozen->non frozen->frozen on a task
> being SIGKILLed):
> in early versions of the patchset I've tried to avoid them, but then
> following the Tejun's advice
> switched over to expose them to a user. The logic behind is simple: if
> the state of the cgroup has been changed (a task is gone, for
> example), let's notify a user.

OK, I won't argue...

actually I can't argue because I do not really understand why do we want
a "killable" freezer, let alone ptraceable ;)

Oleg.

Re: [PATCH] PCI: make pci_size() return real size

[Bjorn Helgaas]

On Sat, Oct 13, 2018 at 08:49:19AM +0800, changbin...@gmail.com wrote:
> From: Du Changbin 
> 
> Currently, the pci_size() function actually return 'size-1'.
> Make it return real size to avoid confusing.
> 
> Signed-off-by: Du Changbin 

Applied to pci/enumeration for v5.1, thanks!

I think it's good to have the "end = start + size - 1" idiom made more
obvious to help avoid off-by-one errors.

> ---
>  drivers/pci/probe.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 201f9e5ff55c..8ff2b1413865 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -121,13 +121,13 @@ static u64 pci_size(u64 base, u64 maxbase, u64 mask)
>* Get the lowest of them to find the decode size, and from that
>* the extent.
>*/
> - size = (size & ~(size-1)) - 1;
> + size = size & ~(size-1);
>  
>   /*
>* base == maxbase can be valid only if the BAR has already been
>* programmed with all 1s.
>*/
> - if (base == maxbase && ((base | size) & mask) != mask)
> + if (base == maxbase && ((base | (size - 1)) & mask) != mask)
>   return 0;
>  
>   return size;
> @@ -278,7 +278,7 @@ int __pci_read_base(struct pci_dev *dev, enum 
> pci_bar_type type,
>   /* Above 32-bit boundary; try to reallocate */
>   res->flags |= IORESOURCE_UNSET;
>   res->start = 0;
> - res->end = sz64;
> + res->end = sz64 - 1;
>   pci_info(dev, "reg 0x%x: can't handle BAR above 4GB 
> (bus address %#010llx)\n",
>pos, (unsigned long long)l64);
>   goto out;
> @@ -286,7 +286,7 @@ int __pci_read_base(struct pci_dev *dev, enum 
> pci_bar_type type,
>   }
>  
>   region.start = l64;
> - region.end = l64 + sz64;
> + region.end = l64 + sz64 - 1;
>  
>   pcibios_bus_to_resource(dev->bus, res, ®ion);
>   pcibios_resource_to_bus(dev->bus, &inverted_region, res);
> -- 
> 2.17.1
> 

Re: [PATCH v3 2/2] Add device tree binding documentation for MAX44009

[Rob Herring]

On Sun, Jan 27, 2019 at 09:09:14AM -0800, Robert Eshleman wrote:
> This patch adds device tree documentation for the max44009 ambient light 
> sensor.

Wrap long lines.

Follow the subject style used for the directory (git log --oneline 
). In this case, 'dt-bindings: iio: light: Add max44009'

> 
> Signed-off-by: Robert Eshleman 
> ---
> Changes to v3:
> - None
> 
> Changes to v2:
> - Clean up style
> 
>  .../bindings/iio/light/max44009.txt   | 25 +++
>  1 file changed, 25 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/light/max44009.txt
> 
> diff --git a/Documentation/devicetree/bindings/iio/light/max44009.txt 
> b/Documentation/devicetree/bindings/iio/light/max44009.txt
> new file mode 100644
> index ..b287d7732e37
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/light/max44009.txt
> @@ -0,0 +1,25 @@
> +* MAX44009 Ambient Light Sensor
> +
> +Required properties:
> +
> +- compatible: should be "maxim,max44009"
> +- reg: the I2C address of the device (default is <0x4a>)
> +
> +Optional properties:
> +
> +- interrupts: interrupt mapping for GPIO IRQ. Should be configured with
> +  IRQ_TYPE_EDGE_FALLING.
> +
> +Refer to interrupt-controller/interrupts.txt for generic interrupt client
> +node bindings.
> +
> +Example:
> +
> +max44009: max44009@4a {

light-sensor@4a

> + compatible = "maxim,max44009";
> + reg = <0x4a>;
> +
> + interrupt-parent = <&gpio1>;
> + interrupts = <17 IRQ_TYPE_EDGE_FALLING>;
> +};
> +
> -- 
> 2.20.1
> 

Re: [PATCH v3 3/4] uaccess: Check no rescheduling function is called in unsafe region

[Valentin Schneider]

On 15/01/2019 13:58, Julien Thierry wrote:
[...]> @@ -6151,6 +6159,20 @@ void ___might_sleep(const char *file, int line, 
int preempt_offset)
>  EXPORT_SYMBOL(___might_sleep);
>  #endif
> 
> +#ifdef CONFIG_DEBUG_UACCESS_SLEEP
> +void __might_resched(const char *file, int line)
> +{
> + if (!unsafe_user_region_active())
> + return;
> +
> + printk(KERN_ERR
> + "BUG: rescheduling function called from user access context at 
> %s:%d\n",
> + file, line);
> + dump_stack();

Since I've been staring intensely at ___might_sleep() lately, I was thinking
we could "copy" it a bit more closely (sorry for going back on what I said
earlier).

Coming back to the double warnings (__might_resched() + schedule_debug()),
it might be better to drop the schedule_debug() warning and just have the
one in __might_resched() - if something goes wrong, there'll already be a
"BUG" in the log.

> +}
> +EXPORT_SYMBOL(__might_resched);
> +#endif
> +
>  #ifdef CONFIG_MAGIC_SYSRQ
>  void normalize_rt_tasks(void)
>  {
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index d4df5b2..d030e31 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -2069,6 +2069,14 @@ config IO_STRICT_DEVMEM
> 
> If in doubt, say Y.
> 
> +config DEBUG_UACCESS_SLEEP
> + bool "Check sleep inside a user access region"
> + depends on DEBUG_KERNEL
> + help
> +   If you say Y here, various routines which may sleep will become very
> +   noisy if they are called inside a user access region (i.e. between
> +   a user_access_begin() and a user_access_end())

If it does get noisy, we should go for some ratelimiting - it's probably
good practice even if it is not noisy actually.

___might_sleep() has this:

  if (time_before(jiffies, prev_jiffy + HZ) && prev_jiffy)
return;
  prev_jiffy = jiffies;

> +
>  source "arch/$(SRCARCH)/Kconfig.debug"
> 
>  endmenu # Kernel hacking
> --
> 1.9.1
> 

Re: [PATCH v2] sched/fair: Fix insertion in rq->leaf_cfs_rq_list

[Peter Zijlstra]

On Wed, Jan 30, 2019 at 04:48:47PM +0100, Vincent Guittot wrote:
> On Wed, 30 Jan 2019 at 14:40, Peter Zijlstra  wrote:
> >
> 
> >
> >  static inline void list_del_leaf_cfs_rq(struct cfs_rq *cfs_rq)
> > @@ -352,7 +354,12 @@ static inline void list_del_leaf_cfs_rq(struct cfs_rq 
> > *cfs_rq)
> > }
> >  }
> >
> > -/* Iterate through all leaf cfs_rq's on a runqueue: */
> > +static inline void assert_list_leaf_cfs_rq(struct rq *rq)
> > +{
> > +   SCHED_WARN_ON(rq->tmp_alone_branch != &rq->lead_cfs_rq_list);
> 
> small typo : s/lead_cfs_rq_list/leaf_cfs_rq_list/

D'0h, thanks!

Re: [PATCH] drm/savage: mark expected switch fall-throughs

[Gustavo A. R. Silva]

On 1/30/19 10:35 AM, Daniel Vetter wrote:
> On Tue, Jan 29, 2019 at 02:20:06PM -0600, Gustavo A. R. Silva wrote:
>> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
>> where we are expecting to fall through.
>>
>> This patch fixes the following warnings:
>>
>> drivers/gpu/drm/savage/savage_state.c:301:8: warning: this statement may 
>> fall through [-Wimplicit-fallthrough=]
>> drivers/gpu/drm/savage/savage_state.c:438:8: warning: this statement may 
>> fall through [-Wimplicit-fallthrough=]
>> drivers/gpu/drm/savage/savage_state.c:559:8: warning: this statement may 
>> fall through [-Wimplicit-fallthrough=]
>> drivers/gpu/drm/savage/savage_state.c:697:8: warning: this statement may 
>> fall through [-Wimplicit-fallthrough=]
>>
>> Warning level 3 was used: -Wimplicit-fallthrough=3
>>
>> This patch is part of the ongoing efforts to enabling
>> -Wimplicit-fallthrough.
>>
>> Signed-off-by: Gustavo A. R. Silva 
> 
> This and the via patch merged to drm-misc-next, thanks.
> -Daniel
> 

Daniel,

I wonder if you can take this one too:

https://lore.kernel.org/patchwork/patch/1001180/

Thanks
--
Gustavo

Re: [PATCH 2/2] binderfs: remove separate device_initcall()

[Christian Brauner]

On Wed, Jan 30, 2019 at 03:24:12PM +0100, Greg KH wrote:
> On Wed, Jan 23, 2019 at 12:41:16PM +0100, Christian Brauner wrote:
> > binderfs should not have a separate device_initcall(). When a kernel is
> > compiled with CONFIG_ANDROID_BINDERFS register the filesystem alongside
> > CONFIG_ANDROID_IPC. This use-case is especially sensible when users specify
> > CONFIG_ANDROID_IPC=y, CONFIG_ANDROID_BINDERFS=y and
> > ANDROID_BINDER_DEVICES="".
> > When CONFIG_ANDROID_BINDERFS=n then this always succeeds so there's no
> > regression potential for legacy workloads.
> > 
> > Signed-off-by: Christian Brauner 
> > ---
> >  drivers/android/binder.c  | 4 
> >  drivers/android/binder_internal.h | 9 +
> >  drivers/android/binderfs.c| 4 +---
> >  3 files changed, 14 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> > index cdfc87629efb..751d76173f81 100644
> > --- a/drivers/android/binder.c
> > +++ b/drivers/android/binder.c
> > @@ -5915,6 +5915,10 @@ static int __init binder_init(void)
> > goto err_init_binder_device_failed;
> > }
> >  
> > +   ret = init_binderfs();
> > +   if (ret)
> > +   goto err_init_binder_device_failed;
> > +
> > return ret;
> >  
> >  err_init_binder_device_failed:
> > diff --git a/drivers/android/binder_internal.h 
> > b/drivers/android/binder_internal.h
> > index 7fb97f503ef2..045b3e42d98b 100644
> > --- a/drivers/android/binder_internal.h
> > +++ b/drivers/android/binder_internal.h
> > @@ -46,4 +46,13 @@ static inline bool is_binderfs_device(const struct inode 
> > *inode)
> >  }
> >  #endif
> >  
> > +#ifdef CONFIG_ANDROID_BINDERFS
> > +extern int __init init_binderfs(void);
> > +#else
> > +static inline int __init init_binderfs(void)
> > +{
> > +   return 0;
> > +}
> > +#endif
> > +
> >  #endif /* _LINUX_BINDER_INTERNAL_H */
> > diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c
> > index 7a550104a722..e773f45d19d9 100644
> > --- a/drivers/android/binderfs.c
> > +++ b/drivers/android/binderfs.c
> > @@ -550,7 +550,7 @@ static struct file_system_type binder_fs_type = {
> > .fs_flags   = FS_USERNS_MOUNT,
> >  };
> >  
> > -static int __init init_binderfs(void)
> > +int __init init_binderfs(void)
> >  {
> > int ret;
> >  
> > @@ -568,5 +568,3 @@ static int __init init_binderfs(void)
> >  
> > return ret;
> >  }
> > -
> > -device_initcall(init_binderfs);
> 
> I get a build warning when applying this patch :(

Hm, I can't reproduce that build error with this patch applied to what
you currently have in char-misc-linus. :(
Any chance you can give me the config that produced this warning?
I tried with CONFIG_BINDERFS=y and CONFIG_BINDERFS=n.

Thanks!
Christian

Re: [PATCH 2/3] perf/x86/intel/pt: Inject PMI for KVM guest

[Paolo Bonzini]

On 19/01/19 21:04, Luwei Kang wrote:
>  static struct pt_pmu pt_pmu;
>  
> @@ -1260,6 +1262,14 @@ void intel_pt_interrupt(void)
>   struct pt_buffer *buf;
>   struct perf_event *event = pt->handle.event;
>  
> + if (pt->vcpu) {
> + /* Inject PMI to Guest */
> + kvm_make_request(KVM_REQ_PMI, pt->vcpu);
> + __set_bit(MSR_CORE_PERF_GLOBAL_OVF_CTRL_TRACE_TOPA_PMI_BIT,
> + (unsigned long *)&pt->vcpu->arch.pmu.global_status);
> + return;
> + }
> +

There is no need to touch struct pt and to know details of KVM in
arch/x86/events.  Please add a function pointer

void (*kvm_handle_pt_interrupt)(void);

to some header, and in handle_pmi_common do

if (unlikely(kvm_handle_intel_pt_interrupt))
kvm_handle_intel_pt_interrupt();
else
intel_pt_interrupt();

The function pointer can be assigned in
kvm_before_interrupt/kvm_after_interrupt just like you do now.

This should be a simpler patch too.

Paolo

Re: [PATCH v2 0/8] qcom: support wakeup capable GPIOs

[Lina Iyer]

On Mon, Jan 28 2019 at 07:19 -0700, Linus Walleij wrote:

On Thu, Jan 24, 2019 at 9:22 PM Lina Iyer  wrote:


This is a bug fix submission of the v1 posted here [1]. The discussion on how
to represent the wakeup-parent interrupt controller is on-going [2] here. The
reiew comments in [1], from Doug and Stephen are addressed in this patch.

The series attempts to add GPIO chip in hierarchy with PDC interrupt controller
that can detect and wakeup the GPIOs routed to it, when the system is
suspend/deep sleep mode.


I kind of start to get the hang of this now. This is starting to
look finished. Some words on the hierarchical GPIO IRQs:

I have started to look into hierarchical GPIO+irqchip since
the usage of such is spreading.

I have been on to Thierry patches trying to make him implement
more generic helpers in the gpiolib irqchip library functions.

In short I see the following:

- Hierarchical gpiochips all have .alloc() and .translate() functions
 that look more or less the same.


Yes.


- They all fall down to remapping either tuples or entire ranges
 of IRQs from parent to child with a linear look-up table on
 allocation.


I would think this would be the generic case, unless its QCOM, where we
would want to push the tuples up hierarchy :(


So my idea would be to add support for this into the gpiolib
hierarchical irqchip helper: by supplying a parent irqdomain
and a list of translation tuples, we should be able to handle
pretty much any hierarchical GPIO irqdomain (famous last
words).


We would read the tuples from DT? Also please consider Rob's idea of
specifying hierarchy from [2].


Right now I am converting the IXP4xx platform to hierarchical
IRQ from the ground up (it is not even using device tree
so it is a bit of a challenge) but it seems to be working.

So I will try to post this in some hopefully working form, and
on top of those changes or before them introduce some
helpers in the core for hierarchical irqs. Or I fail.


Thanks, please copy me on the thread. I would not want to miss this.


Anyways, I do not think my ambitions for refactoring the
helpers can stand in the way of support for these use cases
and new hardware, so maybe we need to merge a few
more hierarchical drivers just bypassing the gpiolib
helpers. I don't want to block development, and I suspect
Thierry might be getting annoyed at me at this point, so
we should maybe just pile up a few more hierarchical
chips so I can refactor them later.

What do you think?


I attempted refactoring the .alloc and .translate and for a generic case
and it seemed like it would fit the bill very well. Will await your
patches.

Thanks,
Lina

[PATCH v2 2/5] cpufreq: dt: Register an Energy Model

[Quentin Perret]

Now that PM_OPP provides a helper function to estimate the power
consumed by CPUs, make sure to try and register an Energy Model (EM)
from cpufreq-dt, hence ensuring interested subsystems (the task
scheduler, for example) can make use of that information when available.

Signed-off-by: Quentin Perret 
---
 drivers/cpufreq/cpufreq-dt.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index e58bfcb1169e..1d4ad6f67408 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -160,7 +160,7 @@ static int cpufreq_init(struct cpufreq_policy *policy)
unsigned int transition_latency;
bool fallback = false;
const char *name;
-   int ret;
+   int ret, nr_opp;
 
cpu_dev = get_cpu_device(policy->cpu);
if (!cpu_dev) {
@@ -231,8 +231,8 @@ static int cpufreq_init(struct cpufreq_policy *policy)
 * But we need OPP table to function so if it is not there let's
 * give platform code chance to provide it for us.
 */
-   ret = dev_pm_opp_get_opp_count(cpu_dev);
-   if (ret <= 0) {
+   nr_opp = dev_pm_opp_get_opp_count(cpu_dev);
+   if (nr_opp <= 0) {
dev_dbg(cpu_dev, "OPP table is not ready, deferring probe\n");
ret = -EPROBE_DEFER;
goto out_free_opp;
@@ -280,6 +280,8 @@ static int cpufreq_init(struct cpufreq_policy *policy)
policy->cpuinfo.transition_latency = transition_latency;
policy->dvfs_possible_from_any_cpu = true;
 
+   dev_pm_opp_of_register_em(policy->cpus, nr_opp);
+
return 0;
 
 out_free_cpufreq_table:
-- 
2.20.1

[PATCH v2 1/5] PM / OPP: Introduce a power estimation helper

[Quentin Perret]

The Energy Model (EM) framework provides an API to let drivers register
the active power of CPUs. The drivers are expected to provide a callback
method which estimates the power consumed by a CPU at each available
performance levels. How exactly this should be implemented, however,
depends on the platform.

On some systems, PM_OPP knows the voltage and frequency at which CPUs
can run. When coupled with the CPU 'capacitance' (as provided by the
'dynamic-power-coefficient' devicetree binding), it is possible to
estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with
C its capacitance and V and f respectively the voltage and frequency of
the OPP. The Intelligent Power Allocator (IPA) thermal governor already
implements that estimation method, in the thermal framework.

However, this power estimation method can be applied to any platform
where all the parameters are known (C, V and f), and not only those
suffering thermal issues. As such, the code implementing this feature
can be re-used to also populate the EM framework now used by EAS.

As a first step, introduce in PM_OPP a helper function which CPUFreq
drivers can use to register into the EM framework. This duplicates the
power estimation done in IPA until it can be migrated to using the EM
framework. This will be done later, once the EM framework has support
for at least all platforms currently supported by IPA.

Signed-off-by: Quentin Perret 

---

Matthias: Given this patch changed a bit I dropped your Reviewed-by and
Tested-by, but let me know if you think they still hold.
---
 drivers/opp/of.c   | 88 ++
 include/linux/pm_opp.h |  6 +++
 2 files changed, 94 insertions(+)

diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index 06f0f632ec47..4c8bf172e9ed 100644
--- a/drivers/opp/of.c
+++ b/drivers/opp/of.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "opp.h"
 
@@ -1047,3 +1048,90 @@ struct device_node *dev_pm_opp_get_of_node(struct 
dev_pm_opp *opp)
return of_node_get(opp->np);
 }
 EXPORT_SYMBOL_GPL(dev_pm_opp_get_of_node);
+
+/*
+ * Callback function provided to the Energy Model framework upon registration.
+ * This computes the power estimated by @CPU at the first OPP above @kHz 
(ceil),
+ * and updates @kHz and @mW accordingly. The power is estimated as
+ * P = C * V^2 * f with C being the CPU's capacitance and V and f respectively
+ * the voltage and frequency of the OPP.
+ *
+ * Returns -ENODEV if the CPU device cannot be found, -EINVAL if the power
+ * calculation failed because of missing parameters, 0 otherwise.
+ */
+static int __maybe_unused _get_cpu_power(unsigned long *mW, unsigned long *kHz,
+int cpu)
+{
+   struct device *cpu_dev;
+   struct dev_pm_opp *opp;
+   struct device_node *np;
+   unsigned long mV, Hz;
+   u32 cap;
+   u64 tmp;
+   int ret;
+
+   cpu_dev = get_cpu_device(cpu);
+   if (!cpu_dev)
+   return -ENODEV;
+
+   np = of_node_get(cpu_dev->of_node);
+   if (!np)
+   return -EINVAL;
+
+   ret = of_property_read_u32(np, "dynamic-power-coefficient", &cap);
+   of_node_put(np);
+   if (ret)
+   return -EINVAL;
+
+   Hz = *kHz * 1000;
+   opp = dev_pm_opp_find_freq_ceil(cpu_dev, &Hz);
+   if (IS_ERR(opp))
+   return -EINVAL;
+
+   mV = dev_pm_opp_get_voltage(opp) / 1000;
+   dev_pm_opp_put(opp);
+   if (!mV)
+   return -EINVAL;
+
+   tmp = (u64)cap * mV * mV * (Hz / 100);
+   do_div(tmp, 10);
+
+   *mW = (unsigned long)tmp;
+   *kHz = Hz / 1000;
+
+   return 0;
+}
+
+/**
+ * dev_pm_opp_of_register_em() - Attempt to register an Energy Model
+ * @cpus   : CPUs for which an Energy Model has to be registered
+ * @nr_opp : Number of OPPs to register in the Energy Model
+ *
+ * This checks whether the "dynamic-power-coefficient" devicetree binding has
+ * been specified, and tries to register an Energy Model with it if it has.
+ */
+void dev_pm_opp_of_register_em(struct cpumask *cpus, int nr_opp)
+{
+   struct em_data_callback em_cb = EM_DATA_CB(_get_cpu_power);
+   int ret, cpu = cpumask_first(cpus);
+   struct device *cpu_dev;
+   struct device_node *np;
+   u32 cap;
+
+   cpu_dev = get_cpu_device(cpu);
+   if (!cpu_dev)
+   return;
+
+   np = of_node_get(cpu_dev->of_node);
+   if (!np)
+   return;
+
+   /* Don't register an EM without the right DT binding */
+   ret = of_property_read_u32(np, "dynamic-power-coefficient", &cap);
+   of_node_put(np);
+   if (ret || !cap)
+   return;
+
+   em_register_perf_domain(cpus, nr_opp, &em_cb);
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_of_register_em);
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index b895f4e79868..58ae08b024bd 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm

[PATCH v2 3/5] cpufreq: scpi: Register an Energy Model

[Quentin Perret]

Now that PM_OPP provides a helper function to estimate the power
consumed by CPUs, make sure to try and register an Energy Model (EM)
from scpi-cpufreq, hence ensuring interested subsystems (the task
scheduler, for example) can make use of that information when available.

Signed-off-by: Quentin Perret 
---
 drivers/cpufreq/scpi-cpufreq.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/cpufreq/scpi-cpufreq.c b/drivers/cpufreq/scpi-cpufreq.c
index 99449738faa4..8e77a67a8d8c 100644
--- a/drivers/cpufreq/scpi-cpufreq.c
+++ b/drivers/cpufreq/scpi-cpufreq.c
@@ -98,7 +98,7 @@ scpi_get_sharing_cpus(struct device *cpu_dev, struct cpumask 
*cpumask)
 
 static int scpi_cpufreq_init(struct cpufreq_policy *policy)
 {
-   int ret;
+   int ret, nr_opp;
unsigned int latency;
struct device *cpu_dev;
struct scpi_data *priv;
@@ -129,8 +129,8 @@ static int scpi_cpufreq_init(struct cpufreq_policy *policy)
return ret;
}
 
-   ret = dev_pm_opp_get_opp_count(cpu_dev);
-   if (ret <= 0) {
+   nr_opp = dev_pm_opp_get_opp_count(cpu_dev);
+   if (nr_opp <= 0) {
dev_dbg(cpu_dev, "OPP table is not ready, deferring probe\n");
ret = -EPROBE_DEFER;
goto out_free_opp;
@@ -170,6 +170,9 @@ static int scpi_cpufreq_init(struct cpufreq_policy *policy)
policy->cpuinfo.transition_latency = latency;
 
policy->fast_switch_possible = false;
+
+   dev_pm_opp_of_register_em(policy->cpus, nr_opp);
+
return 0;
 
 out_free_cpufreq_table:
-- 
2.20.1

[PATCH v2 5/5] cpufreq: scmi: Register an Energy Model

[Quentin Perret]

The Energy Model (EM) framework provides an API to register the active
power of CPUs. Call this API from the scmi-cpufreq driver by using the
power costs obtained from firmware. This is done to ensure interested
subsystems (the task scheduler, for example) can make use of the EM
when available.

Signed-off-by: Quentin Perret 
---
 drivers/cpufreq/scmi-cpufreq.c | 39 +++---
 1 file changed, 36 insertions(+), 3 deletions(-)

diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
index 242c3370544e..0d87e1433296 100644
--- a/drivers/cpufreq/scmi-cpufreq.c
+++ b/drivers/cpufreq/scmi-cpufreq.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -103,13 +104,42 @@ scmi_get_sharing_cpus(struct device *cpu_dev, struct 
cpumask *cpumask)
return 0;
 }
 
+static int __maybe_unused
+scmi_get_cpu_power(unsigned long *power, unsigned long *KHz, int cpu)
+{
+   struct device *cpu_dev = get_cpu_device(cpu);
+   unsigned long Hz;
+   int ret, domain;
+
+   if (!cpu_dev) {
+   pr_err("failed to get cpu%d device\n", cpu);
+   return -ENODEV;
+   }
+
+   domain = handle->perf_ops->device_domain_id(cpu_dev);
+   if (domain < 0)
+   return domain;
+
+   /* Get the power cost of the performance domain. */
+   Hz = *KHz * 1000;
+   ret = handle->perf_ops->est_power_get(handle, domain, &Hz, power);
+   if (ret)
+   return ret;
+
+   /* The EM framework specifies the frequency in KHz. */
+   *KHz = Hz / 1000;
+
+   return 0;
+}
+
 static int scmi_cpufreq_init(struct cpufreq_policy *policy)
 {
-   int ret;
+   int ret, nr_opp;
unsigned int latency;
struct device *cpu_dev;
struct scmi_data *priv;
struct cpufreq_frequency_table *freq_table;
+   struct em_data_callback em_cb = EM_DATA_CB(scmi_get_cpu_power);
 
cpu_dev = get_cpu_device(policy->cpu);
if (!cpu_dev) {
@@ -136,8 +166,8 @@ static int scmi_cpufreq_init(struct cpufreq_policy *policy)
return ret;
}
 
-   ret = dev_pm_opp_get_opp_count(cpu_dev);
-   if (ret <= 0) {
+   nr_opp = dev_pm_opp_get_opp_count(cpu_dev);
+   if (nr_opp <= 0) {
dev_dbg(cpu_dev, "OPP table is not ready, deferring probe\n");
ret = -EPROBE_DEFER;
goto out_free_opp;
@@ -171,6 +201,9 @@ static int scmi_cpufreq_init(struct cpufreq_policy *policy)
policy->cpuinfo.transition_latency = latency;
 
policy->fast_switch_possible = true;
+
+   em_register_perf_domain(policy->cpus, nr_opp, &em_cb);
+
return 0;
 
 out_free_priv:
-- 
2.20.1

[PATCH v2 0/5] Register an Energy Model for Arm reference platforms

[Quentin Perret]

The Energy Model (EM) framework feeds interested subsystems (the
scheduler/EAS as of now) with power costs provided by drivers. Yet, no
driver is actually doing that upstream yet. This series updates a set of
CPUFreq drivers in order to register power costs in the EM framework for
some of the Arm reference platforms for EAS: Hikey960, Juno and TC2.

The series is split as follows:
 - Patch 01 introduces in PM_OPP a helper function which estimates the
   CPU power using the P=CV²f equation also used by IPA. It should be
   noted that this introduces duplicate code with IPA, which will
   eventually be fixed by migrating IPA to using PM_EM. The ideal plan
   would be to do so later, in a separate patch series. I would indeed
   prefer to keep the thermal and CPUFreq discussion separate at this
   stage, if deemed acceptable.
 - Patches 02-04 make use of that PM_OPP helper function from the
   following CPUFreq drivers: cpufreq-dt, scpi-cpufreq and
   arm_big_little.
 - Patch 05 modifies the SCMI cpufreq driver to pass the power costs
   obtained from firmware to PM_EM. This patch is independent from the
   rest of the series.


Changes since v1 (20190128165522.31749-1-quentin.per...@arm.com):
 - Dropped the DT patches that have been queued by Sudeep
 - Introduced dev_pm_opp_of_register_em() helper to check the presence
   of the DT coeff before calling PM_EM (Viresh, Matthias)
 - Coding-style improvements (Viresh, Matthias)


Thanks,
Quentin


Dietmar Eggemann (1):
  cpufreq: arm_big_little: Register an Energy Model

Quentin Perret (4):
  PM / OPP: Introduce a power estimation helper
  cpufreq: dt: Register an Energy Model
  cpufreq: scpi: Register an Energy Model
  cpufreq: scmi: Register an Energy Model

 drivers/cpufreq/arm_big_little.c |  8 +++
 drivers/cpufreq/cpufreq-dt.c |  8 +--
 drivers/cpufreq/scmi-cpufreq.c   | 39 --
 drivers/cpufreq/scpi-cpufreq.c   |  9 ++--
 drivers/opp/of.c | 88 
 include/linux/pm_opp.h   |  6 +++
 6 files changed, 149 insertions(+), 9 deletions(-)

-- 
2.20.1

[PATCH v2 4/5] cpufreq: arm_big_little: Register an Energy Model

[Quentin Perret]

From: Dietmar Eggemann 

Now that PM_OPP provides a helper function to estimate the power
consumed by CPUs, make sure to try and register an Energy Model (EM)
from the arm_big_little CPUFreq driver, hence ensuring interested
subsystems (the task scheduler, for example) can make use of that
information when available.

Signed-off-by: Dietmar Eggemann 
Signed-off-by: Quentin Perret 
---
 drivers/cpufreq/arm_big_little.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
index cf62a1f64dd7..18b05bcb2614 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -487,6 +487,14 @@ static int bL_cpufreq_init(struct cpufreq_policy *policy)
policy->cpuinfo.transition_latency =
arm_bL_ops->get_transition_latency(cpu_dev);
 
+   ret = dev_pm_opp_get_opp_count(cpu_dev);
+   if (ret <= 0) {
+   dev_dbg(cpu_dev, "OPP table is not ready, deferring probe\n");
+   return -EPROBE_DEFER;
+   }
+
+   dev_pm_opp_of_register_em(policy->cpus, ret);
+
if (is_bL_switching_enabled())
per_cpu(cpu_last_req_freq, policy->cpu) = 
clk_get_cpu_rate(policy->cpu);
 
-- 
2.20.1

Re: [PATCH 2/2] mm: Consider subtrees in memory.events

[Tejun Heo]

Hello, Michal.

On Wed, Jan 30, 2019 at 05:50:58PM +0100, Michal Hocko wrote:
> > Yeah, cgroup.events and .stat files as some of the local stats would
> > be useful too, so if we don't flip memory.events we'll end up with sth
> > like cgroup.events.local, memory.events.tree and memory.stats.local,
> > which is gonna be hilarious.
> 
> Why cannot we simply have memory.events_tree and be done with it? Sure
> the file names are not goin to be consistent which is a minus but that
> ship has already sailed some time ago.

Because the overall cost of shitty interface will be way higher in the
longer term.  cgroup2 interface is far from perfect but is way better
than cgroup1 especially for the memory controller.  Why do you think
that is?

> > If you aren't willing to change your mind, the only option seems to be
> > introducing a mount option to gate the flip and additions of local
> > files.  Most likely, userspace will enable the option by default
> > everywhere, so the end result will be exactly the same but I guess
> > it'll better address your concern.
> 
> How does the consumer of the API learns about the mount type?

It's gonna be a mount flag exposed in /sys/kernel/cgroup/features.

Thanks.

-- 
tejun

Re: [PATCH v9 2/9] PCI: Using PCI configuration space header type instead of class type to assign resource

[Bjorn Helgaas]

On Tue, Oct 16, 2018 at 06:44:43PM +0800, honghui.zh...@mediatek.com wrote:
> From: Honghui Zhang 
> 
> The PCI configuration space header type defines the layout of the rest
> of the header (PCI r3.0 sec 6.1, PCIe r4.0 sec 7.5.1.1.9) while the
> resource assignment is based on the configuration space layout instead
> of its class type. Using configuration space header type instead of
> class type for the resource assignment.
> 
> Suggested-by: Bjorn Helgaas 
> Signed-off-by: Honghui Zhang 

I applied the patch below to pci/enumeration for v5.1.

I dropped the hunk that removed the PCI_CLASS_BRIDGE_HOST check per
Lorenzo's concern.  Let me know if you have any other concerns.


commit b2fb5cc57469
Author: Honghui Zhang 
Date:   Tue Oct 16 18:44:43 2018 +0800

PCI: Rely on config space header type, not class code

The PCI configuration space header type tells us whether the device is a
bridge, a CardBus bridge, or a normal device, and defines the layout of the
rest of the header (PCI r3.0 sec 6.1, PCIe r4.0 sec 7.5.1.1.9).

When we rely on the header format, e.g., when we're dealing with bridge
windows, we should check the header type, not the class code.  The class
code is loosely related to the header type, but is often incorrect and the
spec doesn't actually require it to be related to the header format.

Suggested-by: Bjorn Helgaas 
Signed-off-by: Honghui Zhang 
[bhelgaas: changelog, keep the PCI_CLASS_BRIDGE_HOST check]
Signed-off-by: Bjorn Helgaas 

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index c9d8e3c837de..e9d938e14ba8 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -6000,8 +6000,7 @@ void pci_reassigndev_resource_alignment(struct pci_dev 
*dev)
 * to enable the kernel to reassign new resource
 * window later on.
 */
-   if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE &&
-   (dev->class >> 8) == PCI_CLASS_BRIDGE_PCI) {
+   if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
for (i = PCI_BRIDGE_RESOURCES; i < PCI_NUM_RESOURCES; i++) {
r = &dev->resource[i];
if (!(r->flags & IORESOURCE_MEM))
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 8e2e4154cdd9..128459a0ffba 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1779,9 +1779,6 @@ int pci_setup_device(struct pci_dev *dev)
break;
 
case PCI_HEADER_TYPE_BRIDGE:/* bridge header */
-   if (class != PCI_CLASS_BRIDGE_PCI)
-   goto bad;
-
/*
 * The PCI-to-PCI bridge spec requires that subtractive
 * decoding (i.e. transparent) bridge must have programming
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 1941bb0a6c13..ec44a0f3a7ac 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -1186,12 +1186,12 @@ void __pci_bus_size_bridges(struct pci_bus *bus, struct 
list_head *realloc_head)
if (!b)
continue;
 
-   switch (dev->class >> 8) {
-   case PCI_CLASS_BRIDGE_CARDBUS:
+   switch (dev->hdr_type) {
+   case PCI_HEADER_TYPE_CARDBUS:
pci_bus_size_cardbus(b, realloc_head);
break;
 
-   case PCI_CLASS_BRIDGE_PCI:
+   case PCI_HEADER_TYPE_BRIDGE:
default:
__pci_bus_size_bridges(b, realloc_head);
break;
@@ -1202,12 +1202,12 @@ void __pci_bus_size_bridges(struct pci_bus *bus, struct 
list_head *realloc_head)
if (pci_is_root_bus(bus))
return;
 
-   switch (bus->self->class >> 8) {
-   case PCI_CLASS_BRIDGE_CARDBUS:
+   switch (bus->self->hdr_type) {
+   case PCI_HEADER_TYPE_CARDBUS:
/* don't size cardbuses yet. */
break;
 
-   case PCI_CLASS_BRIDGE_PCI:
+   case PCI_HEADER_TYPE_BRIDGE:
pci_bridge_check_ranges(bus);
if (bus->self->is_hotplug_bridge) {
additional_io_size  = pci_hotplug_io_size;
@@ -1356,13 +1356,13 @@ void __pci_bus_assign_resources(const struct pci_bus 
*bus,
 
__pci_bus_assign_resources(b, realloc_head, fail_head);
 
-   switch (dev->class >> 8) {
-   case PCI_CLASS_BRIDGE_PCI:
+   switch (dev->hdr_type) {
+   case PCI_HEADER_TYPE_BRIDGE:
if (!pci_is_enabled(dev))
pci_setup_bridge(b);
break;
 
-   case PCI_CLASS_BRIDGE_CARDBUS:
+   case PCI_HEADER_TYPE_CARDBUS:
pci_setup_cardbus(b);
break;
 

Re: [PATCH v3 2/2] iio:dac:dac7612: device tree bindings

[Rob Herring]

On Mon, Jan 28, 2019 at 10:49:31AM +0100, Ricardo Ribalda Delgado wrote:
> Bindings for dac7612.
> 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Ricardo Ribalda Delgado 
> ---
>  .../bindings/iio/dac/ti,dac7612.txt   | 29 +++
>  MAINTAINERS   |  1 +
>  2 files changed, 30 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt
> 
> diff --git a/Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt 
> b/Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt
> new file mode 100644
> index ..e1b8158fab35
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt
> @@ -0,0 +1,29 @@
> +* Texas Instruments Dual, 12-Bit Serial Input Digital-to-Analog Converter
> +
> +The DAC7612 is a dual, 12-bit digital-to-analog converter (DAC) with 
> guaranteed
> +12-bit monotonicity performance over the industrial temperature range.
> +Is is programmable through an SPI interface.
> +
> +The internal DACs are loaded when the LOADDACS pin is pulled down.
> +
> +http://www.ti.com/lit/ds/sbas106/sbas106.pdf
> +
> +Required Properties:
> +- compatible: Should be one of:
> + "ti,dac7612"
> + "ti,dac7612u"
> + "ti,dac7612b"

What's the difference? I can only find 'u' and 'ub' variants and nothing 
about how those are different. So maybe just 1 string is enough?

> +- reg: Definition as per Documentation/devicetree/bindings/spi/spi-bus.txt
> +
> +Optional Properties:
> +- loaddacs-gpios: GPIO descriptor for the LOADDACS pin.

Needs a 'ti' vendor prefix.

> +- spi-*: Definition as per Documentation/devicetree/bindings/spi/spi-bus.txt
> +
> +Example:
> +
> + dac7612@1 {

dac@1

> + compatible = "ti,dac7612";
> + reg = <0x1>;
> + loaddacs-gpios = <&msmgpio 25 GPIO_ACTIVE_LOW>;
> + };
> +
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 30ba5435906b..e28e5afaae16 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -14882,6 +14882,7 @@ M:Ricardo Ribalda 
>  L:   linux-...@vger.kernel.org
>  S:   Supported
>  F:   drivers/iio/dac/ti-dac7612.c
> +F:   Documentation/devicetree/bindings/iio/dac/ti,dac7612.txt
>  
>  THANKO'S RAREMONO AM/FM/SW RADIO RECEIVER USB DRIVER
>  M:   Hans Verkuil 
> -- 
> 2.20.1
> 

Re: [PATCH] lib/ubsan: default UBSAN_ALIGNMENT to not set

[Andrey Ryabinin]

On 1/30/19 4:36 AM, Andrew Morton wrote:
> On Fri, 11 Jan 2019 22:01:16 +0300 Andrey Ryabinin  
> wrote:
> 
>>
>>
>> On 12/17/18 6:03 PM, Anders Roxell wrote:
>>> When booting an allmodconfig kernel, there are a lot of false-positives.
>>> With a message like this 'UBSAN: Undefined behaviour in...' with a call
>>> trace that follows.
>>>
>>> Reworked so that when building a allmodconfig kernel that turns
>>> everything into '=m' or '=y' will turn off UBSAN_ALIGNMENT.
>>>
>>> Suggested-by: Arnd Bergmann 
>>> Signed-off-by: Anders Roxell 
>>> ---
>>
>> Acked-by: Andrey Ryabinin 
>>
> 
> Confused.  Why does allmodconfig result in UBSAN warnings?
>  

UBSAN warnings is a result of enabling noisy CONFIG_UBSAN_ALIGNMENT which is 
disabled
by default if HAVE_EFFICIENT_UNALIGNED_ACCESS=y.
It's noisy even if don't have efficient unaligned access, e.g. people often add 
 __cacheline_aligned_in_smp
in structs, but forget to align allocations of such struct (kmalloc() give 
8-byte alignment in worst case).

Re: [PATCH] usb: typec: tcpm: Correct the PPS out_volt calculation

[Guenter Roeck]

On Wed, Jan 30, 2019 at 11:13:53AM +0800, Kyle Tso wrote:
> When Sink negotiates PPS, the voltage range of selected PPS APDO might
> not cover the previous voltage (out_volt). If the previous out_volt is
> lower than the new min_volt, the output voltage in RDO might be set to
> an invalid value. For instance, supposed that the previous voltage is
> 5V, and the new voltage range in the APDO is 7V-12V. Then the output
> voltage in the RDO should not be set to 5V which is lower than the
> possible min_volt 7V.
> 
> Fix this by choosing the maximal value between the previous voltage and
> the new min_volt first. And ensure that this value will not exceed the
> new max_volt. The new out_volt will fall within the new voltage range
> while being the closest value compared to the previous out_volt.
> 
> Signed-off-by: Kyle Tso 

Reviewed-by: Guenter Roeck 

> ---
>  drivers/usb/typec/tcpm/tcpm.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> index f1d3e54210df..8f2af348bda5 100644
> --- a/drivers/usb/typec/tcpm/tcpm.c
> +++ b/drivers/usb/typec/tcpm/tcpm.c
> @@ -2297,7 +2297,8 @@ static unsigned int tcpm_pd_select_pps_apdo(struct 
> tcpm_port *port)
> pdo_pps_apdo_max_voltage(snk));
>   port->pps_data.max_curr = min_pps_apdo_current(src, snk);
>   port->pps_data.out_volt = min(port->pps_data.max_volt,
> -   port->pps_data.out_volt);
> +   max(port->pps_data.min_volt,
> +   port->pps_data.out_volt));
>   port->pps_data.op_curr = min(port->pps_data.max_curr,
>port->pps_data.op_curr);
>   }
> -- 
> 2.20.1.495.gaa96b0ce6b-goog
> 

Re: [PATCH v5 04/13] KVM: Introduce a new guest mapping API

[Paolo Bonzini]

On 23/01/19 18:50, Konrad Rzeszutek Wilk wrote:
>> +if (dirty)
>> +kvm_release_pfn_dirty(map->pfn);
>> +else
>> +kvm_release_pfn_clean(map->pfn);
>> +map->hva = NULL;
> I keep on having this gnawing feeling that we MUST set map->page to
> NULL.
> 
> That is I can see how it is not needed if you are using 'map' and
> 'unmap' together - for that we are good. But what I am worried is that
> some one unmaps it .. and instead of checking map->hva they end up
> checking map->page and think the page is mapped.

I think that would break anyway the memremap case.

So I think we should indeed reset map->page, but we should set it to a
poison value:

#define KVM_UNMAPPED_PAGE((void *) 0x500 + POISON_POINTER_DELTA)

mem->page = KVM_UNMAPPED_PAGE;

This should make it clear to everyone that checking map->page is _not_
the right thing to do in any case.

Paolo

> Would you be OK adding that extra statement just as a fail-safe
> mechanism in case someones misues the APIs?

Re: [PATCH v5 00/13] KVM/X86: Introduce a new guest mapping interface

[Paolo Bonzini]

On 25/01/19 19:28, Raslan, KarimAllah wrote:
> So the simple way to do it is:
> 
> 1- Pass 'mem=' in the kernel command-line to limit the amount of memory 
> managed 
>    by the kernel.
> 2- Map this physical memory you want to give to the guest with
>       mmap("/dev/mem", physical_address_offset, ..)
> 3- Use the user-space virtual address as the "userspace_addr" field 
>    in KVM_SET_USER_MEMORY_REGION ioctl.
> 
> You will also need this patch (hopefully I will repost next week as well):
> https://patchwork.kernel.org/patch/9191755/

I took a look again at that patch and I guess I've changed my mind now
that the kernel provides e820__mapped_any and e820__mapped_all.
However, please do use e820__mapped_any instead of adding a new function
e820_is_ram.

Thanks,

Paolo

> I will make sure to expand on this in the cover letter in v6.

Re: [PATCH 1/9] spi: atmel-quadspi: optimize qspi init

[Boris Brezillon]

On Wed, 30 Jan 2019 15:08:29 +
 wrote:

> From: Tudor Ambarus 
> 
> Set the QSPI controller in Serial Memory Mode at init and not
> at each exec_op() call.

If you ever want to support regular SPI you'll have to put it back to
atmel_qspi_exec_op(), so I'm not sure this is a good move. Another
approach would be to cache the MR value to avoid doing a write access
on the bus when the value hasn't changed.

> 
> Signed-off-by: Tudor Ambarus 
> ---
>  drivers/spi/atmel-quadspi.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/spi/atmel-quadspi.c b/drivers/spi/atmel-quadspi.c
> index ddc712410812..f79b17792a11 100644
> --- a/drivers/spi/atmel-quadspi.c
> +++ b/drivers/spi/atmel-quadspi.c
> @@ -238,8 +238,6 @@ static int atmel_qspi_exec_op(struct spi_mem *mem, const 
> struct spi_mem_op *op)
>   icr = QSPI_ICR_INST(op->cmd.opcode);
>   ifr = QSPI_IFR_INSTEN;
>  
> - qspi_writel(aq, QSPI_MR, QSPI_MR_SMM);
> -
>   mode = find_mode(op);
>   if (mode < 0)
>   return -ENOTSUPP;
> @@ -381,6 +379,9 @@ static int atmel_qspi_init(struct atmel_qspi *aq)
>   /* Reset the QSPI controller */
>   qspi_writel(aq, QSPI_CR, QSPI_CR_SWRST);
>  
> + /* Set the QSPI controller in Serial Memory Mode */
> + qspi_writel(aq, QSPI_MR, QSPI_MR_SMM);
> +
>   /* Enable the QSPI controller */
>   qspi_writel(aq, QSPI_CR, QSPI_CR_QSPIEN);
>  

Re: [PATCH v2 0/2] KVM: x86: expose direct stores instructions into VM.

[Paolo Bonzini]

On 30/11/18 21:41, Eric Northup wrote:
> On Mon, Nov 5, 2018 at 10:01 PM Liu Jingqi  wrote:
>>
>> Direct stores instructions MOVDIRI and MOVDIR64B will be available in
>> Tremont and other future x86 processors,
>> and need to be exposed to guest VM.
> 
> It seems like KVM's emulator should be able to complete these
> instructions to emulated MMIO before exposing CPUID to guests in any
> default or supported configurations.
> 
> It'll be much simpler for usermode to implement that property if the
> KVM-reported supported CPUID table doesn't get updated before the KVM
> emulator does.

We already do not support emulation for many CPUID bits we expose (AVX
and AVX512 above all), so that's not a huge problem.

I suppose these instructions are unlikely to be used on MMIO areas such
as legacy VGA VRAM.

Paolo

Re: [PATCH v2 0/2] KVM: x86: expose direct stores instructions into VM.

[Paolo Bonzini]

On 06/11/18 06:55, Liu Jingqi wrote:
> Direct stores instructions MOVDIRI and MOVDIR64B will be available in
> Tremont and other future x86 processors,
> and need to be exposed to guest VM.
> 
> The release document ref below link:
> https://software.intel.com/sites/default/files/managed/c5/15/\
> architecture-instruction-set-extensions-programming-reference.pdf
> 
> This series expose movdiri and movdir64b features to guest VM.
> 
> Changelog:
> v2:
>   Separated from the series https://lkml.org/lkml/2018/7/10/160
>   since umonitor/umwait/tpause instructions patches are not ready yet.
> v1:
>   Sent out with umonitor/umwait/tpause instructions patches.
> 
> Liu Jingqi (2):
>   KVM: x86: expose MOVDIRI CPU feature into VM.
>   KVM: x86: expose MOVDIR64B CPU feature into VM.
> 
>  arch/x86/kvm/cpuid.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Queued, thanks.

Paolo

Re: [PATCH 2/9] spi: atmel-quadspi: order header files inclusion alphabetically

[Boris Brezillon]

On Wed, 30 Jan 2019 15:08:31 +
 wrote:

> From: Tudor Ambarus 
> 
> Cosmetic change, no functional change.
> 
> Signed-off-by: Tudor Ambarus 

Reviewed-by: Boris Brezillon 

> ---
>  drivers/spi/atmel-quadspi.c | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/spi/atmel-quadspi.c b/drivers/spi/atmel-quadspi.c
> index f79b17792a11..64475ad16c83 100644
> --- a/drivers/spi/atmel-quadspi.c
> +++ b/drivers/spi/atmel-quadspi.c
> @@ -22,16 +22,15 @@
>   * This driver is based on drivers/mtd/spi-nor/fsl-quadspi.c from Freescale.
>   */
>  
> -#include 
>  #include 
> -#include 
> -#include 
>  #include 
>  #include 
>  #include 
> -#include 
> -
>  #include 
> +#include 
> +#include 
> +#include 
> +#include 
>  #include 
>  
>  /* QSPI register offsets */

Re: [PATCH 1/4] powerpc/64s: Clear on-stack exception marker upon exception return

[Nicolai Stange]

Michael Ellerman  writes:

> Joe Lawrence  writes:
>> From: Nicolai Stange 
>>
>> The ppc64 specific implementation of the reliable stacktracer,
>> save_stack_trace_tsk_reliable(), bails out and reports an "unreliable
>> trace" whenever it finds an exception frame on the stack. Stack frames
>> are classified as exception frames if the STACK_FRAME_REGS_MARKER magic,
>> as written by exception prologues, is found at a particular location.
>>
>> However, as observed by Joe Lawrence, it is possible in practice that
>> non-exception stack frames can alias with prior exception frames and thus,
>> that the reliable stacktracer can find a stale STACK_FRAME_REGS_MARKER on
>> the stack. It in turn falsely reports an unreliable stacktrace and blocks
>> any live patching transition to finish. Said condition lasts until the
>> stack frame is overwritten/initialized by function call or other means.
>>
>> In principle, we could mitigate this by making the exception frame
>> classification condition in save_stack_trace_tsk_reliable() stronger:
>> in addition to testing for STACK_FRAME_REGS_MARKER, we could also take into
>> account that for all exceptions executing on the kernel stack
>> - their stack frames's backlink pointers always match what is saved
>>   in their pt_regs instance's ->gpr[1] slot and that
>> - their exception frame size equals STACK_INT_FRAME_SIZE, a value
>>   uncommonly large for non-exception frames.
>>
>> However, while these are currently true, relying on them would make the
>> reliable stacktrace implementation more sensitive towards future changes in
>> the exception entry code. Note that false negatives, i.e. not detecting
>> exception frames, would silently break the live patching consistency model.
>>
>> Furthermore, certain other places (diagnostic stacktraces, perf, xmon)
>> rely on STACK_FRAME_REGS_MARKER as well.
>>
>> Make the exception exit code clear the on-stack STACK_FRAME_REGS_MARKER
>> for those exceptions running on the "normal" kernel stack and returning
>> to kernelspace: because the topmost frame is ignored by the reliable stack
>> tracer anyway, returns to userspace don't need to take care of clearing
>> the marker.
>>
>> Furthermore, as I don't have the ability to test this on Book 3E or
>> 32 bits, limit the change to Book 3S and 64 bits.
>>
>> Finally, make the HAVE_RELIABLE_STACKTRACE Kconfig option depend on
>> PPC_BOOK3S_64 for documentation purposes. Before this patch, it depended
>> on PPC64 && CPU_LITTLE_ENDIAN and because CPU_LITTLE_ENDIAN implies
>> PPC_BOOK3S_64, there's no functional change here.
>
> That has nothing to do with the fix and should really be in a separate
> patch.
>
> I can split it when applying.

If you don't mind, that would be nice! Or simply drop that
chunk... Otherwise, let me know if I shall send a split v2 for this
patch [1/4] only.

Thanks,

Nicolai

-- 
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)

Re: [PATCH 3/9] spi: atmel-quadspi: fix naming scheme

[Boris Brezillon]

On Wed, 30 Jan 2019 15:08:33 +
 wrote:

> From: Tudor Ambarus 
> 
> Let general names to core drivers.
> 
> Signed-off-by: Tudor Ambarus 
> ---
>  drivers/spi/atmel-quadspi.c | 52 
> ++---
>  1 file changed, 26 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/spi/atmel-quadspi.c b/drivers/spi/atmel-quadspi.c
> index 64475ad16c83..e156c345705b 100644
> --- a/drivers/spi/atmel-quadspi.c
> +++ b/drivers/spi/atmel-quadspi.c
> @@ -157,14 +157,14 @@ struct atmel_qspi {
>   struct completion   cmd_completion;
>  };
>  
> -struct qspi_mode {
> +struct atmel_qspi_mode {
>   u8 cmd_buswidth;
>   u8 addr_buswidth;
>   u8 data_buswidth;
>   u32 config;
>  };
>  
> -static const struct qspi_mode sama5d2_qspi_modes[] = {
> +static const struct atmel_qspi_mode sama5d2_qspi_modes[] = {
>   { 1, 1, 1, QSPI_IFR_WIDTH_SINGLE_BIT_SPI },
>   { 1, 1, 2, QSPI_IFR_WIDTH_DUAL_OUTPUT },
>   { 1, 1, 4, QSPI_IFR_WIDTH_QUAD_OUTPUT },
> @@ -175,18 +175,18 @@ static const struct qspi_mode sama5d2_qspi_modes[] = {
>  };
>  
>  /* Register access functions */
> -static inline u32 qspi_readl(struct atmel_qspi *aq, u32 reg)
> +static inline u32 atmel_qspi_readl(struct atmel_qspi *aq, u32 reg)
>  {
>   return readl_relaxed(aq->regs + reg);
>  }
>  
> -static inline void qspi_writel(struct atmel_qspi *aq, u32 reg, u32 value)
> +static inline void atmel_qspi_writel(struct atmel_qspi *aq, u32 reg, u32 
> value)
>  {
>   writel_relaxed(value, aq->regs + reg);
>  }

Can we get rid of these wrappers? I'm not a big fan of wrappers that
hide the fact that accesses are relaxed.

>  
> -static inline bool is_compatible(const struct spi_mem_op *op,
> -  const struct qspi_mode *mode)
> +static inline bool atmel_qspi_is_compatible(const struct spi_mem_op *op,
> + const struct atmel_qspi_mode *mode)
>  {
>   if (op->cmd.buswidth != mode->cmd_buswidth)
>   return false;
> @@ -200,12 +200,12 @@ static inline bool is_compatible(const struct 
> spi_mem_op *op,
>   return true;
>  }
>  
> -static int find_mode(const struct spi_mem_op *op)
> +static int atmel_qspi_find_mode(const struct spi_mem_op *op)
>  {
>   u32 i;
>  
>   for (i = 0; i < ARRAY_SIZE(sama5d2_qspi_modes); i++)
> - if (is_compatible(op, &sama5d2_qspi_modes[i]))
> + if (atmel_qspi_is_compatible(op, &sama5d2_qspi_modes[i]))
>   return i;
>  
>   return -1;
> @@ -214,7 +214,7 @@ static int find_mode(const struct spi_mem_op *op)
>  static bool atmel_qspi_supports_op(struct spi_mem *mem,
>  const struct spi_mem_op *op)
>  {
> - if (find_mode(op) < 0)
> + if (atmel_qspi_find_mode(op) < 0)
>   return false;
>  
>   /* special case not supported by hardware */
> @@ -237,7 +237,7 @@ static int atmel_qspi_exec_op(struct spi_mem *mem, const 
> struct spi_mem_op *op)
>   icr = QSPI_ICR_INST(op->cmd.opcode);
>   ifr = QSPI_IFR_INSTEN;
>  
> - mode = find_mode(op);
> + mode = atmel_qspi_find_mode(op);
>   if (mode < 0)
>   return -ENOTSUPP;
>  
> @@ -293,17 +293,17 @@ static int atmel_qspi_exec_op(struct spi_mem *mem, 
> const struct spi_mem_op *op)
>   ifr |= QSPI_IFR_TFRTYP_TRSFR_WRITE;
>  
>   /* Clear pending interrupts */
> - (void)qspi_readl(aq, QSPI_SR);
> + (void)atmel_qspi_readl(aq, QSPI_SR);
>  
>   /* Set QSPI Instruction Frame registers */
> - qspi_writel(aq, QSPI_IAR, iar);
> - qspi_writel(aq, QSPI_ICR, icr);
> - qspi_writel(aq, QSPI_IFR, ifr);
> + atmel_qspi_writel(aq, QSPI_IAR, iar);
> + atmel_qspi_writel(aq, QSPI_ICR, icr);
> + atmel_qspi_writel(aq, QSPI_IFR, ifr);
>  
>   /* Skip to the final steps if there is no data */
>   if (op->data.nbytes) {
>   /* Dummy read of QSPI_IFR to synchronize APB and AHB accesses */
> - (void)qspi_readl(aq, QSPI_IFR);
> + (void)atmel_qspi_readl(aq, QSPI_IFR);
>  
>   /* Send/Receive data */
>   if (op->data.dir == SPI_MEM_DATA_IN)
> @@ -314,22 +314,22 @@ static int atmel_qspi_exec_op(struct spi_mem *mem, 
> const struct spi_mem_op *op)
>   op->data.buf.out, op->data.nbytes);
>  
>   /* Release the chip-select */
> - qspi_writel(aq, QSPI_CR, QSPI_CR_LASTXFER);
> + atmel_qspi_writel(aq, QSPI_CR, QSPI_CR_LASTXFER);
>   }
>  
>   /* Poll INSTRuction End status */
> - sr = qspi_readl(aq, QSPI_SR);
> + sr = atmel_qspi_readl(aq, QSPI_SR);
>   if ((sr & QSPI_SR_CMD_COMPLETED) == QSPI_SR_CMD_COMPLETED)
>   return err;
>  
>   /* Wait for INSTRuction End interrupt */
>   reinit_completion(&aq->cmd_completion);
>   aq->pending = sr & QSPI_SR_CMD_COMPLETED;
> - qspi_writel(aq, QSPI_IER, QSPI_SR_CMD_COMPLETED);
> + atm

Re: [PATCH 4/9] spi: atmel-quadspi: remove unnecessary cast

[Boris Brezillon]

On Wed, 30 Jan 2019 15:08:35 +
 wrote:

> From: Tudor Ambarus 
> 
> The cast is done implicitly.
> 
> Signed-off-by: Tudor Ambarus 

Reviewed-by: Boris Brezillon 

> ---
>  drivers/spi/atmel-quadspi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/spi/atmel-quadspi.c b/drivers/spi/atmel-quadspi.c
> index e156c345705b..3643f0c851b0 100644
> --- a/drivers/spi/atmel-quadspi.c
> +++ b/drivers/spi/atmel-quadspi.c
> @@ -389,7 +389,7 @@ static int atmel_qspi_init(struct atmel_qspi *aq)
>  
>  static irqreturn_t atmel_qspi_interrupt(int irq, void *dev_id)
>  {
> - struct atmel_qspi *aq = (struct atmel_qspi *)dev_id;
> + struct atmel_qspi *aq = dev_id;
>   u32 status, mask, pending;
>  
>   status = atmel_qspi_readl(aq, QSPI_SR);

Re: [PATCH 5/9] spi: atmel-quadspi: return appropriate error code

[Boris Brezillon]

On Wed, 30 Jan 2019 15:08:38 +
 wrote:

> From: Tudor Ambarus 
> 
> Return -ENOTSUPP when atmel_qspi_find_mode() fails. Propagate
> the error in atmel_qspi_exec_op().
> 
> Signed-off-by: Tudor Ambarus 

Reviewed-by: Boris Brezillon 

> ---
>  drivers/spi/atmel-quadspi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/spi/atmel-quadspi.c b/drivers/spi/atmel-quadspi.c
> index 3643f0c851b0..e6de6e3d1345 100644
> --- a/drivers/spi/atmel-quadspi.c
> +++ b/drivers/spi/atmel-quadspi.c
> @@ -208,7 +208,7 @@ static int atmel_qspi_find_mode(const struct spi_mem_op 
> *op)
>   if (atmel_qspi_is_compatible(op, &sama5d2_qspi_modes[i]))
>   return i;
>  
> - return -1;
> + return -ENOTSUPP;
>  }
>  
>  static bool atmel_qspi_supports_op(struct spi_mem *mem,
> @@ -239,7 +239,7 @@ static int atmel_qspi_exec_op(struct spi_mem *mem, const 
> struct spi_mem_op *op)
>  
>   mode = atmel_qspi_find_mode(op);
>   if (mode < 0)
> - return -ENOTSUPP;
> + return mode;
>  
>   ifr |= sama5d2_qspi_modes[mode].config;
>  

Re: [PATCH v2 4/7] scsi: libsas: split the replacement of sas disks in two steps

[John Garry]

On 30/01/2019 08:24, Jason Yan wrote:

Now if a new device replaced a old device, the sas address will change.


Hmmm... not if it's a SATA disk, which would have some same invented SAS 
address.



We unregister the old device and discover the new device in one
revalidation process. But after we deferred the sas_port_delete(), the
sas port is not deleted when we registering the new port and device.
The sas port cannot be added because the name of the new port is the
same as the old.

Fix this by doing the replacement in two steps. The first revalidation
only delete the old device and trigger a new revalidation. The second
revalidation discover the new device. To keep the event processing
synchronised to the original event,


Did I originally suggest this? It seems to needlessly make the code more 
complicated.


we wrapped a loop and added a new

parameter to see if we should revalidate again.

Signed-off-by: Jason Yan 
CC: chenxiang 
CC: John Garry 
CC: Johannes Thumshirn 
CC: Ewan Milne 
CC: Christoph Hellwig 
CC: Tomas Henzl 
CC: Dan Williams 
CC: Hannes Reinecke 
---
 drivers/scsi/libsas/sas_discover.c | 20 +++-
 drivers/scsi/libsas/sas_expander.c | 20 ++--
 include/scsi/libsas.h  |  2 +-
 3 files changed, 30 insertions(+), 12 deletions(-)

diff --git a/drivers/scsi/libsas/sas_discover.c 
b/drivers/scsi/libsas/sas_discover.c
index ffc571a12916..c825c89fbddd 100644
--- a/drivers/scsi/libsas/sas_discover.c
+++ b/drivers/scsi/libsas/sas_discover.c
@@ -498,12 +498,10 @@ static void sas_discover_domain(struct work_struct *work)
 task_pid_nr(current), error);
 }

-static void sas_revalidate_domain(struct work_struct *work)
+static void sas_do_revalidate_domain(struct asd_sas_port *port, bool *retry)
 {
-   struct sas_discovery_event *ev = to_sas_discovery_event(work);
-   struct asd_sas_port *port = ev->port;
-   struct sas_ha_struct *ha = port->ha;
struct domain_device *ddev = port->port_dev;
+   struct sas_ha_struct *ha = port->ha;

/* prevent revalidation from finding sata links in recovery */
mutex_lock(&ha->disco_mutex);
@@ -520,7 +518,7 @@ static void sas_revalidate_domain(struct work_struct *work)

if (ddev && (ddev->dev_type == SAS_FANOUT_EXPANDER_DEVICE ||
 ddev->dev_type == SAS_EDGE_EXPANDER_DEVICE))
-   sas_ex_revalidate_domain(ddev);
+   sas_ex_revalidate_domain(ddev, retry);

pr_debug("done REVALIDATING DOMAIN on port %d, pid:%d\n",
 port->id, task_pid_nr(current));
@@ -532,6 +530,18 @@ static void sas_revalidate_domain(struct work_struct *work)
sas_probe_devices(port);
 }

+static void sas_revalidate_domain(struct work_struct *work)
+{
+   struct sas_discovery_event *ev = to_sas_discovery_event(work);
+   struct asd_sas_port *port = ev->port;
+   bool retry;
+
+   do {
+   retry = false;
+   sas_do_revalidate_domain(port, &retry);
+   } while (retry);
+}
+
 /* -- Events -- */

 static void sas_chain_work(struct sas_ha_struct *ha, struct sas_work *sw)
diff --git a/drivers/scsi/libsas/sas_expander.c 
b/drivers/scsi/libsas/sas_expander.c
index 5cd720f93f96..cdbf8d8a28bf 100644
--- a/drivers/scsi/libsas/sas_expander.c
+++ b/drivers/scsi/libsas/sas_expander.c
@@ -1994,7 +1994,8 @@ static bool dev_type_flutter(enum sas_device_type new, 
enum sas_device_type old)
return false;
 }

-static int sas_rediscover_dev(struct domain_device *dev, int phy_id, bool last)
+static int sas_unregister(struct domain_device *dev, int phy_id, bool last,
+ bool *retry)
 {
struct expander_device *ex = &dev->ex_dev;
struct ex_phy *phy = &ex->ex_phy[phy_id];
@@ -2045,7 +2046,12 @@ static int sas_rediscover_dev(struct domain_device *dev, 
int phy_id, bool last)
SAS_ADDR(phy->attached_sas_addr));
sas_unregister_devs_sas_addr(dev, phy_id, last);

-   return sas_discover_new(dev, phy_id);
+   /* force the next revalidation find this phy and bring it up */
+   phy->phy_change_count = -1;
+   ex->ex_change_count = -1;
+   *retry = true;


Ohh, sorry to say, but that's a real hack :)

Could we just add a flag for the expander PHY to force a discovery 
instead of this?


I assume that you need to do this as the expander PHY change count will 
not be modified for the next revalidation (so no discovery on that PHY).



+
+   return 0;
 }

 /**
@@ -2062,7 +2068,8 @@ static int sas_rediscover_dev(struct domain_device *dev, 
int phy_id, bool last)
  * first phy,for other phys in this port, we add it to the port to
  * forming the wide-port.
  */
-static void sas_rediscover(struct domain_device *dev, const int phy_id)
+static void sas_rediscover(struct domain_device *dev, const int phy_id,
+  bool *retry)
 {
struct expander_device *ex = &dev->ex_dev;
struct 

Re: [PATCH resend 1/3] hwmon: (lm85) remove freq_map size hardcodes

[Guenter Roeck]

On Wed, Jan 30, 2019 at 09:14:45AM -0700, Jeremy Gebben wrote:
> 
> Allow support for chips that support more than 8 frequencies.
> The size still must be a power of two.
> 
This is risky. Someone later may not know/remember and 
expand the table without maintaining that restriction.
I would suggest to use map_size instead of map_mask.
While that adds some divide operations, none of those are
in a critical path, and the code would be much more robust.

> Signed-off-by: Jeremy Gebben 
> ---
>  drivers/hwmon/lm85.c | 25 +++--
>  1 file changed, 15 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/hwmon/lm85.c b/drivers/hwmon/lm85.c
> index 0a325878e8f5..48f59667a88c 100644
> --- a/drivers/hwmon/lm85.c
> +++ b/drivers/hwmon/lm85.c
> @@ -198,13 +198,13 @@ static int RANGE_TO_REG(long range)
>  #define RANGE_FROM_REG(val)  lm85_range_map[(val) & 0x0f]
>  
>  /* These are the PWM frequency encodings */
> -static const int lm85_freq_map[8] = { /* 1 Hz */
> +static const int lm85_freq_map[] = { /* 1 Hz */
>   10, 15, 23, 30, 38, 47, 61, 94
>  };
> -static const int adm1027_freq_map[8] = { /* 1 Hz */
> +
> +static const int adm1027_freq_map[] = { /* 1 Hz */
>   11, 15, 22, 29, 35, 44, 59, 88
>  };
> -#define FREQ_MAP_LEN 8
>  
>  static int FREQ_TO_REG(const int *map,
>  unsigned int map_size, unsigned long freq)
> @@ -212,9 +212,9 @@ static int FREQ_TO_REG(const int *map,
>   return find_closest(freq, map, map_size);
>  }
>  
> -static int FREQ_FROM_REG(const int *map, u8 reg)
> +static int FREQ_FROM_REG(const int *map, unsigned int map_size, u8 reg)
>  {
> - return map[reg & 0x07];
> + return map[reg & (map_size - 1)];

Passing in map_size (calculated as map_mask + 1) just to subtract one
doesn't make sense.

>  }
>  
>  /*
> @@ -296,6 +296,8 @@ struct lm85_data {
>   struct i2c_client *client;
>   const struct attribute_group *groups[6];
>   const int *freq_map;
> + unsigned int freq_map_mask;
> +
>   enum chips type;
>  
>   bool has_vid5;  /* true if VID5 is configured for ADT7463 or ADT7468 */
> @@ -514,7 +516,7 @@ static struct lm85_data *lm85_update_device(struct device 
> *dev)
>   data->autofan[i].config =
>   lm85_read_value(client, LM85_REG_AFAN_CONFIG(i));
>   val = lm85_read_value(client, LM85_REG_AFAN_RANGE(i));
> - data->pwm_freq[i] = val & 0x07;
> + data->pwm_freq[i] = val & data->freq_map_mask;
>   data->zone[i].range = val >> 4;
>   data->autofan[i].min_pwm =
>   lm85_read_value(client, LM85_REG_AFAN_MINPWM(i));
> @@ -791,7 +793,8 @@ static ssize_t show_pwm_freq(struct device *dev,
>   if (IS_ADT7468_HFPWM(data))
>   freq = 22500;
>   else
> - freq = FREQ_FROM_REG(data->freq_map, data->pwm_freq[nr]);
> + freq = FREQ_FROM_REG(data->freq_map, data->freq_map_mask + 1,
> +  data->pwm_freq[nr]);
>  
>   return sprintf(buf, "%d\n", freq);
>  }
> @@ -820,7 +823,7 @@ static ssize_t set_pwm_freq(struct device *dev,
>   lm85_write_value(client, ADT7468_REG_CFG5, data->cfg5);
>   } else {/* Low freq. mode */
>   data->pwm_freq[nr] = FREQ_TO_REG(data->freq_map,
> -  FREQ_MAP_LEN, val);
> +  data->freq_map_mask + 1, val);
>   lm85_write_value(client, LM85_REG_AFAN_RANGE(nr),
>(data->zone[nr].range << 4)
>| data->pwm_freq[nr]);
> @@ -1196,7 +1199,7 @@ static ssize_t set_temp_auto_temp_min(struct device 
> *dev,
>   TEMP_FROM_REG(data->zone[nr].limit));
>   lm85_write_value(client, LM85_REG_AFAN_RANGE(nr),
>   ((data->zone[nr].range & 0x0f) << 4)
> - | (data->pwm_freq[nr] & 0x07));
> + | data->pwm_freq[nr]);
>  
>   mutex_unlock(&data->update_lock);
>   return count;
> @@ -1232,7 +1235,7 @@ static ssize_t set_temp_auto_temp_max(struct device 
> *dev,
>   val - min);
>   lm85_write_value(client, LM85_REG_AFAN_RANGE(nr),
>   ((data->zone[nr].range & 0x0f) << 4)
> - | (data->pwm_freq[nr] & 0x07));
> + | data->pwm_freq[nr]);
>   mutex_unlock(&data->update_lock);
>   return count;
>  }
> @@ -1569,9 +1572,11 @@ static int lm85_probe(struct i2c_client *client, const 
> struct i2c_device_id *id)
>   case emc6d103:
>   case emc6d103s:
>   data->freq_map = adm1027_freq_map;
> + data->freq_map_mask = ARRAY_SIZE(adm1027_freq_map) - 1;
>   break;
>   default:
>   data->freq_map = lm85_freq_map;
> + data->freq_map_mask = ARRAY_SIZE(lm85_freq_map) - 1;
>   }

You'd have to 

Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma

[Logan Gunthorpe]

On 2019-01-29 9:18 p.m., Jason Gunthorpe wrote:
> Every attempt to give BAR memory to struct page has run into major
> trouble, IMHO, so I like that this approach avoids that.
> 
> And if you don't have struct page then the only kernel object left to
> hang meta data off is the VMA itself.
> 
> It seems very similar to the existing P2P work between in-kernel
> consumers, just that VMA is now mediating a general user space driven
> discovery process instead of being hard wired into a driver.

But the kernel now has P2P bars backed by struct pages and it works
well. And that's what we are doing in-kernel. We even have a hacky
out-of-tree module which exposes these pages and it also works (but
would need Jerome's solution for denying those pages in GUP, etc). So
why do something completely different in userspace so they can't share
any of the DMA map infrastructure?

Logan

DMCA take-down request to GitHub regarding: GPC-Slots2 (after GPL Revocation from "John Doe")

[mikeeusa]

I have a good faith belief that use of the copyrighted materials 
described above on the infringing web pages is not authorized by the 
copyright owner, or its agent, or the law. I have taken fair use into 
consideration.


I swear, under penalty of perjury, that the information in this 
notification is accurate and that I am the copyright owner, or am 
authorized to act on behalf of the owner, of an exclusive right that is 
allegedly infringed.

:


As you may know, In the United States; a license, absent an attached 
interest, is revocable.


A "John Doe" had his non-exclusive license regarding the game 
"GPC-Slots2" terminated by the copyright owner (me: MikeeUSA).
The copyright owner may do this as-of-right, unless there is an attached 
interest (ie: unless the licensee paid good consideration for the 
license).


The "John Doe" then proceeded to belligerently upload a copy of 
"GPC-Slots2" to your host, GitHub.
This violated Author's (my) copyright, since "John Doe"'s gratuitous 
bare license had been terminated by the copyright holder (me).


The "John Doe" then proceeded to modify my work, which again violated my 
copyright since I had previously revoked his license.
The license flows from me, the copyright owner, not any text. It is 
permission to use, redistribute, modify, etc. Instructions on how to use 
my property.
When such permission is not supported by any consideration, it may be 
rescinded by the owner, at his will.
(/Regardless/ of the "terms". "Terms" are only enforceable against the 
grantor if the licensee has paid consideration for them, essentially, 
under US law.)


I have done so.

I reiterated to the "John Doe" that his license had been terminated.

"John Doe" then informed me that I "can't do that". I tried to explain 
to him US law.
"John Doe" declared that he did not care and would keep the violating 
work up, in defiance of me.

(IE: he would "pirate" it)

He then cited works from a discredited paralegal while I cited published 
works by lawyers studied in their field.


(Note: I make no claim to PERL, the color ansi library, any supporting 
libraries, or the -2 split screen function. My copyright covers the game 
code of GPC-Slots2. I (MikeeUSA) am the original author of the work and 
never signed over copyright to the work.)
(Note: "obeying the terms" (obeying the copyright holders instructions 
regarding the use of his property) is not consideration: it is a 
preexisting legal duty: outside of the "terms" there is no right for the 
licensee to copy, modify, make derivative works, distribute, distribute 
derivative works)


[Additionally "John Doe" registered a fraudulent account under my 
long-held non-de-gurre, adding a Code of Conduct ("CoC"), something I 
would never do (being opposed to "CoC" for gratis projects on 
principal)]


I now have no choice but to issue a DMCA take-down request, to you, 
GitHub.


Regrettably;
--MikeeUSA--
(electronic signature)
Jan 29, 2019

Contact information:
email: mikee...@redchan.it

infringing content: github.com/MikeeUSA/GPC-Slots-2
The material is not authorized by me, the copyright owner of the 
GPC-Slots2 game code, as I explicitly rescinded the license from the 
"John Doe", and he acknowledged that I had informed him of such and 
communicated that he would defy my will regarding my property and 
copyright.
Everything stated within this above communication is accurate to the 
best of my knowledge and ability.


Some notices to you, github:
1) Yes I viewed your page at: 
https://help.github.com/articles/guide-to-submitting-a-dmca-takedown-notice/

2) Yes this is "opensource" code.
3) No that does not matter:
The GPL(any version), being a bare license, is revocable 
("retroactively").

Just as any bare license, not supported by an interest, in the US.
The "John Doe" is not in privity of contract with me and has paid me no 
consideration.

He cannot "bind" me (the grantor) to the terms.
It is his duty to abide by my instructions regarding my property.
I did not transfer my property away, the license is just that: a license 
(temporary permission, that can be rescinded unless a "term" was indeed 
"purchased")
It is also his duty to cease all use, modification, distribution of my 
property at my demand.

I have made such a demand.
4) Yes I will consider taking legal action against you if you do not 
heed my request.
Cite the paralegal from groklaw, ZDnet, the FSF, and the SFConservancy 
all you want.

They are wrong on the law and have been wrong for 10 years.

-

The conversation with the "John Doe" can be found here: 
8ch.net/tech/res/1018729.html#1024398


Some excerpts:

From me to "John Doe":

>>1024390

1) I rescind your permission to modify, make derivative works, 
distribute the program. The GPL license you "have" been granted from 
me, is revoked.


2) you are impersonating me.





>>1024400
I rescind the license from you.
I am going to sue you if I find out who you are.




From "John Doe"

>Your license was rescinded

RE: [PATCH] media: staging/intel-ipu3: Implement lock for stream on/off operations

[Mani, Rajmohan]

Hi Sakari,

> -Original Message-
> From: Sakari Ailus [mailto:sakari.ai...@linux.intel.com]
> Sent: Wednesday, January 30, 2019 12:59 AM
> To: Mani, Rajmohan 
> Cc: Mauro Carvalho Chehab ; Greg Kroah-Hartman
> ; linux-me...@vger.kernel.org;
> de...@driverdev.osuosl.org; linux-kernel@vger.kernel.org; Laurent Pinchart
> ; Jacopo Mondi ;
> Qiu, Tian Shu ; Cao, Bingbu
> ; z...@paasikivi.fi.intel.com; Zhi, Yong
> ; hverk...@xs4all.nl; tf...@chromium.org
> Subject: Re: [PATCH] media: staging/intel-ipu3: Implement lock for stream
> on/off operations
> 
> Hi Rajmohan,
> 
> On Tue, Jan 29, 2019 at 02:27:36PM -0800, Rajmohan Mani wrote:
> > Currently concurrent stream off operations on ImgU nodes are not
> > synchronized, leading to use-after-free bugs (as reported by KASAN).
> >
> > [  250.090724] BUG: KASAN: use-after-free in
> > ipu3_dmamap_free+0xc5/0x116 [ipu3_imgu] [  250.090726] Read of size 8
> > at addr 888127b29bc0 by task yavta/18836 [  250.090731] Hardware
> > name: HP Soraka/Soraka, BIOS Google_Soraka.10431.17.0 03/22/2018 [
> 250.090732] Call Trace:
> > [  250.090735]  dump_stack+0x6a/0xb1
> > [  250.090739]  print_address_description+0x8e/0x279
> > [  250.090743]  ? ipu3_dmamap_free+0xc5/0x116 [ipu3_imgu] [
> > 250.090746]  kasan_report+0x260/0x28a [  250.090750]
> > ipu3_dmamap_free+0xc5/0x116 [ipu3_imgu] [  250.090754]
> > ipu3_css_pool_cleanup+0x24/0x37 [ipu3_imgu] [  250.090759]
> > ipu3_css_pipeline_cleanup+0x61/0xb9 [ipu3_imgu] [  250.090763]
> > ipu3_css_stop_streaming+0x1f2/0x321 [ipu3_imgu] [  250.090768]
> > imgu_s_stream+0x94/0x443 [ipu3_imgu] [  250.090772]  ?
> > ipu3_vb2_buf_queue+0x280/0x280 [ipu3_imgu] [  250.090775]  ?
> > vb2_dma_sg_unmap_dmabuf+0x16/0x6f [videobuf2_dma_sg] [  250.090778]
> ?
> > vb2_buffer_in_use+0x36/0x58 [videobuf2_common] [  250.090782]
> > ipu3_vb2_stop_streaming+0xf9/0x135 [ipu3_imgu]
> >
> > Implemented a lock to synchronize imgu stream on / off operations and
> > the modification of streaming flag (in struct imgu_device), to prevent
> > these issues.
> >
> > Reported-by: Laurent Pinchart 
> > Suggested-by: Laurent Pinchart 
> >
> > Signed-off-by: Rajmohan Mani 
> > ---
> >  drivers/staging/media/ipu3/ipu3-v4l2.c | 6 ++
> >  drivers/staging/media/ipu3/ipu3.c  | 3 +++
> >  drivers/staging/media/ipu3/ipu3.h  | 4 
> >  3 files changed, 13 insertions(+)
> >
> > diff --git a/drivers/staging/media/ipu3/ipu3-v4l2.c
> > b/drivers/staging/media/ipu3/ipu3-v4l2.c
> > index c7936032beb9..cf7e917cd0c8 100644
> > --- a/drivers/staging/media/ipu3/ipu3-v4l2.c
> > +++ b/drivers/staging/media/ipu3/ipu3-v4l2.c
> > @@ -507,12 +507,15 @@ static int ipu3_vb2_start_streaming(struct
> vb2_queue *vq, unsigned int count)
> > goto fail_stop_pipeline;
> > }
> >
> > +   mutex_lock(&imgu->streaming_lock);
> > +
> 
> You appear to be using imgu_device.lock (while searching buffers to queue to
> the device) as well as imgu_video_device.lock (qbuf, dqbuf) to serialise 
> access
> to imgu_video_device.buffers list.

Ack

> The two locks may be acquired at the same
> time but each by different processes. That needs to be addressed, but
> probably not in this patch.
> 

The node specific locks will be used by different processes and all of these 
processes
will be competing commonly (and successfully) for the imgu_device lock.
I will look into this more.

> I wonder if it'd be more simple to use imgu->lock here instead of adding a new
> one.
> 

Extending imgu->lock here, does not work in this case, as imgu_queue_buffers()
will be stuck acquiring imgu->lock, which was already acquired by 
imgu_s_stream()
through ipu3_vb2_start_streaming().

> > /* Start streaming of the whole pipeline now */
> > dev_dbg(dev, "IMGU streaming is ready to start");
> > r = imgu_s_stream(imgu, true);
> > if (!r)
> > imgu->streaming = true;
> >
> > +   mutex_unlock(&imgu->streaming_lock);
> > return 0;
> >
> >  fail_stop_pipeline:
> > @@ -543,6 +546,8 @@ static void ipu3_vb2_stop_streaming(struct
> vb2_queue *vq)
> > dev_err(&imgu->pci_dev->dev,
> > "failed to stop subdev streaming\n");
> >
> > +   mutex_lock(&imgu->streaming_lock);
> > +
> > /* Was this the first node with streaming disabled? */
> > if (imgu->streaming && ipu3_all_nodes_streaming(imgu, node)) {
> > /* Yes, really stop streaming now */ @@ -552,6 +557,7 @@
> static
> > void ipu3_vb2_stop_streaming(struct vb2_queue *vq)
> > imgu->streaming = false;
> > }
> >
> > +   mutex_unlock(&imgu->streaming_lock);
> > ipu3_return_all_buffers(imgu, node, VB2_BUF_STATE_ERROR);
> 
> > media_pipeline_stop(&node->vdev.entity);
> >  }
> > diff --git a/drivers/staging/media/ipu3/ipu3.c
> > b/drivers/staging/media/ipu3/ipu3.c
> > index d521b3afb8b1..2daee51cd845 100644
> > --- a/drivers/staging/media/ipu3/ipu3.c
> > +++ b/drivers/staging/media/ipu3/ipu3.c
> > @@ -635,6 +635,7 @@ static int imgu_pci_probe(str

Re: [PATCH 6/9] spi: atmel-quadspi: switch to SPDX license identifiers

[Boris Brezillon]

On Wed, 30 Jan 2019 15:08:40 +
 wrote:

> From: Tudor Ambarus 
> 
> Adopt the SPDX license identifiers to ease license compliance
> management.
> 
> Signed-off-by: Tudor Ambarus 

Reviewed-by: Boris Brezillon 

> ---
>  drivers/spi/atmel-quadspi.c | 13 +
>  1 file changed, 1 insertion(+), 12 deletions(-)
> 
> diff --git a/drivers/spi/atmel-quadspi.c b/drivers/spi/atmel-quadspi.c
> index e6de6e3d1345..1d21db7851e9 100644
> --- a/drivers/spi/atmel-quadspi.c
> +++ b/drivers/spi/atmel-quadspi.c
> @@ -1,3 +1,4 @@
> +// SPDX-License-Identifier: GPL-2.0
>  /*
>   * Driver for Atmel QSPI Controller
>   *
> @@ -7,18 +8,6 @@
>   * Author: Cyrille Pitchen 
>   * Author: Piotr Bugalski 
>   *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> - *
> - * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> - * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> - * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> - * more details.
> - *
> - * You should have received a copy of the GNU General Public License along 
> with
> - * this program.  If not, see .
> - *
>   * This driver is based on drivers/mtd/spi-nor/fsl-quadspi.c from Freescale.
>   */
>  

Re: [PATCH] x86: avoid confusion over the new RESCTRL config prompt

[Borislav Petkov]

On Wed, Jan 30, 2019 at 11:46:26AM -0500, Johannes Weiner wrote:
> This is still awefully close to the cgroup CPU resource
> controller. Since it's more hardware-specific, and the config symbol
> also has the x86 in it, how about "x86 CPU resource control support"?

Fine by me.

What about

s/X86_RESCTRL/X86_CPU_RESCTRL/g

?

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)

Re: [PATCH 6/7] MIPS: SGI-IP27: use generic PCI driver

[Thomas Bogendoerfer]

On Wed, 30 Jan 2019 01:17:06 -0800
Christoph Hellwig  wrote:

> On Tue, Jan 29, 2019 at 04:24:45PM +0100, Thomas Bogendoerfer wrote:
> > > From an abstraction point of view this doesn't really belong into
> > > a bridge driver as it is a global exported function.  I guess we can
> > > keep it here with a fixme comment, but we should probably move this
> > > into a method call instead.
> > 
> > or put the nodeid into the bus struct ?
> 
> Doesn't sound to bad to me, you'll just have to update a fair
> amount of arch implementations.

and it's already there:-) Each struct device has a field numa_node and pci_bus 
has
contains a struct device. arm64 is already using it only not so nice part is the
usage of pcibios_root_bridge_prepare() to set the numa_node for the root bus.

> > I'm all for it. I looked at the examples for using dma_pfn_offset and the
> > only one coming close to usefull for me is arch/sh/drivers/pci/pcie-sh7786.c
> > It overloads pcibios_bus_add_device() to set dma_pfn_offset, which doesn't
> > look much nicer. What about having a dma_pfn_offset in struct pci_bus
> > which all device inherit from ?
> 
> Or add a add_dev callback, similar to what I did for a previous series
> that we didn't end up needing after all:
> 
> http://git.infradead.org/users/hch/misc.git/commitdiff/06d9b4fc7deed336edc1292fe2e661729e98ec39

that's exactly what I'm looking for. Should I add the patch for my patchset or
are you going to submit it after having a use case ?

Thomas.

-- 
SUSE Linux GmbH
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH 09/10] mm/hmm: allow to mirror vma of a file on a DAX backed filesystem

[Dan Williams]

On Tue, Jan 29, 2019 at 7:03 PM Jerome Glisse  wrote:
[..]
> > > 1) Convert ODP to use HMM underneath so that we share code between
> > > infiniband ODP and GPU drivers. ODP do support DAX today so i can
> > > not convert ODP to HMM without also supporting DAX in HMM otherwise
> > > i would regress the ODP features.
> > >
> > > 2) I expect people will be running GPGPU on computer with file that
> > > use DAX and they will want to use HMM there too, in fact from user-
> > > space point of view wether the file is DAX or not should only change
> > > one thing ie for DAX file you will never be able to use GPU memory.
> > >
> > > 3) I want to convert as many user of GUP to HMM (already posted
> > > several patchset to GPU mailing list for that and i intend to post
> > > a v2 of those latter on). Using HMM avoids GUP and it will avoid
> > > the GUP pin as here we abide by mmu notifier hence we do not want to
> > > inhibit any of the filesystem regular operation. Some of those GPU
> > > driver do allow GUP on DAX file. So again i can not regress them.
> >
> > Is this really a GUP to HMM conversion, or a GUP to mmu_notifier
> > solution? It would be good to boil this conversion down to the base
> > building blocks. It seems "HMM" can mean several distinct pieces of
> > infrastructure. Is it possible to replace some GUP usage with an
> > mmu_notifier based solution without pulling in all of HMM?
>
> Kind of both, some of the GPU driver i am converting will use HMM for
> more than just this GUP reason. But when and for what hardware they
> will use HMM for is not something i can share (it is up to each vendor
> to announce their hardware and feature on their own timeline).

Typically a spec document precedes specific hardware announcement and
Linux enabling is gated on public spec availability.

> So yes you could do the mmu notifier solution without pulling HMM
> mirror (note that you do not need to pull all of HMM, HMM as many
> kernel config option and for this you only need to use HMM mirror).
> But if you are not using HMM then you will just be duplicating the
> same code as HMM mirror. So i believe it is better to share this
> code and if we want to change core mm then we only have to update
> HMM while keeping the API/contract with device driver intact.

No. Linux should not end up with the HMM-mm as distinct from the
Core-mm. For long term maintainability of Linux, the target should be
one mm.

> This
> is one of the motivation behind HMM ie have it as an impedence layer
> between mm and device drivers so that mm folks do not have to under-
> stand every single device driver but only have to understand the
> contract HMM has with all device driver that uses it.

This gets to heart of my critique of the approach taken with HMM. The
above statement is antithetical to
Documentation/process/stable-api-nonsense.rst. If HMM is trying to set
expectations that device-driver projects can write to a "stable" HMM
api then HMM is setting those device-drivers up for failure.

The possibility of refactoring driver code *across* vendors is a core
tenet of Linux maintainability. If the refactoring requires the API
exported to drivers to change then so be it. The expectation that all
out-of-tree device-drivers should have is that the API they are using
in kernel version X may not be there in version X+1. Having the driver
upstream is the only surefire insurance against that thrash.

HMM seems a bold experiment in trying to violate Linux development norms.

> Also having each driver duplicating this code increase the risk of
> one getting a little detail wrong. The hope is that sharing same
> HMM code with all the driver then everyone benefit from debugging
> the same code (i am hopping i do not have many bugs left :))

"each driver duplicating code" begs for refactoring driver code to
common code and this refactoring is hindered if it must adhere to an
"HMM" api.

Re: [PATCH 7/9] dt-bindings: spi: atmel-quadspi: update example to new clock binding

[Boris Brezillon]

On Wed, 30 Jan 2019 15:08:43 +
 wrote:

> From: Tudor Ambarus 
> 
> Introduced in:
> commit b60557876849 ("ARM: dts: at91: sama5d2: switch to new clock binding")
> 
> Signed-off-by: Tudor Ambarus 

Reviewed-by: Boris Brezillon 

> ---
>  Documentation/devicetree/bindings/spi/atmel-quadspi.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/spi/atmel-quadspi.txt 
> b/Documentation/devicetree/bindings/spi/atmel-quadspi.txt
> index b93c1e2f25dd..e9dae6264d89 100644
> --- a/Documentation/devicetree/bindings/spi/atmel-quadspi.txt
> +++ b/Documentation/devicetree/bindings/spi/atmel-quadspi.txt
> @@ -19,7 +19,7 @@ spi@f002 {
>   reg = <0xf002 0x100>, <0xd000 0x800>;
>   reg-names = "qspi_base", "qspi_mmap";
>   interrupts = <52 IRQ_TYPE_LEVEL_HIGH 7>;
> - clocks = <&spi0_clk>;
> + clocks = <&pmc PMC_TYPE_PERIPHERAL 52>;
>   #address-cells = <1>;
>   #size-cells = <0>;
>   pinctrl-names = "default";

[PATCH v3] PM-runtime: fix deadlock with ktime

[Vincent Guittot]

A deadlock has been seen when swicthing clocksources which use PM runtime.
The call path is:
change_clocksource
...
write_seqcount_begin
...
timekeeping_update
...
sh_cmt_clocksource_enable
...
rpm_resume
pm_runtime_mark_last_busy
ktime_get
do
read_seqcount_begin
while read_seqcount_retry

write_seqcount_end

Although we should be safe because we haven't yet changed the clocksource
at that time, we can't because of seqcount protection.

Use ktime_get_mono_fast_ns() instead which is lock safe for such case

With ktime_get_mono_fast_ns, the timestamp is not guaranteed to be
monotonic across an update and as a result can goes backward. According to
update_fast_timekeeper() description: "In the worst case, this can
result is a slightly wrong timestamp (a few nanoseconds)". For
PM runtime autosuspend, this means only that the suspend decision can
be slightly sub optimal.

Fixes: 8234f6734c5d ("PM-runtime: Switch autosuspend over to using hrtimers")
Reported-by: Biju Das 
Signed-off-by: Vincent Guittot 
---

Hi Rafael,

Sorry, I sent the version with the typo mistake that generated the compilation 
error
reported by kbuild-test-robot

This version doesn't have the typo.

Regards,
Vincent

- v3: fix typo error that appears while updating commit message
- v2: Updated commit message to explain the impact of using 
  ktime_get_mono_fast_ns()

 drivers/base/power/runtime.c | 10 +-
 include/linux/pm_runtime.h   |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 457be03..0ea2139 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -130,7 +130,7 @@ u64 pm_runtime_autosuspend_expiration(struct device *dev)
 {
int autosuspend_delay;
u64 last_busy, expires = 0;
-   u64 now = ktime_to_ns(ktime_get());
+   u64 now = ktime_get_mono_fast_ns();
 
if (!dev->power.use_autosuspend)
goto out;
@@ -909,7 +909,7 @@ static enum hrtimer_restart  pm_suspend_timer_fn(struct 
hrtimer *timer)
 * If 'expires' is after the current time, we've been called
 * too early.
 */
-   if (expires > 0 && expires < ktime_to_ns(ktime_get())) {
+   if (expires > 0 && expires < ktime_get_mono_fast_ns()) {
dev->power.timer_expires = 0;
rpm_suspend(dev, dev->power.timer_autosuspends ?
(RPM_ASYNC | RPM_AUTO) : RPM_ASYNC);
@@ -928,7 +928,7 @@ static enum hrtimer_restart  pm_suspend_timer_fn(struct 
hrtimer *timer)
 int pm_schedule_suspend(struct device *dev, unsigned int delay)
 {
unsigned long flags;
-   ktime_t expires;
+   u64 expires;
int retval;
 
spin_lock_irqsave(&dev->power.lock, flags);
@@ -945,8 +945,8 @@ int pm_schedule_suspend(struct device *dev, unsigned int 
delay)
/* Other scheduled or pending requests need to be canceled. */
pm_runtime_cancel_pending(dev);
 
-   expires = ktime_add(ktime_get(), ms_to_ktime(delay));
-   dev->power.timer_expires = ktime_to_ns(expires);
+   expires = ktime_get_mono_fast_ns() + (u64)delay * NSEC_PER_MSEC;
+   dev->power.timer_expires = expires;
dev->power.timer_autosuspends = 0;
hrtimer_start(&dev->power.suspend_timer, expires, HRTIMER_MODE_ABS);
 
diff --git a/include/linux/pm_runtime.h b/include/linux/pm_runtime.h
index 54af4ee..fed5be7 100644
--- a/include/linux/pm_runtime.h
+++ b/include/linux/pm_runtime.h
@@ -105,7 +105,7 @@ static inline bool pm_runtime_callbacks_present(struct 
device *dev)
 
 static inline void pm_runtime_mark_last_busy(struct device *dev)
 {
-   WRITE_ONCE(dev->power.last_busy, ktime_to_ns(ktime_get()));
+   WRITE_ONCE(dev->power.last_busy, ktime_get_mono_fast_ns());
 }
 
 static inline bool pm_runtime_is_irq_safe(struct device *dev)
-- 
2.7.4

[PATCH v2] doc: Change LXR references to elixir.bootlin.com

[Jonathan Neuschäfer]

Recently, Free Electrons was renamed to Bootlin[1]. Less recently, the
Linux Cross Reference (LXR) at lxr.free-electrons.com was replaced by
Elixir[2], and lxr.free-electrons.com redirected first to
elixir.free-electrons.com and now to elixir.bootlin.com.

[1]: https://bootlin.com/blog/free-electrons-becomes-bootlin/
[2]: https://github.com/free-electrons/elixir

Signed-off-by: Jonathan Neuschäfer 
---

v2:
- Fix ident search URL, as suggested by Martin Kepplinger
- Add trailing slash, which I accidentally dropped in v1 in
  Documentation/translations/it_IT/process/howto.rst

v1: https://lore.kernel.org/lkml/20190129142923.5743-1-j.neuschae...@gmx.net/
---
 Documentation/input/devices/xpad.rst   | 2 +-
 Documentation/process/howto.rst| 2 +-
 Documentation/process/kernel-docs.rst  | 2 +-
 Documentation/translations/it_IT/process/howto.rst | 2 +-
 Documentation/translations/ja_JP/howto.rst | 2 +-
 Documentation/translations/ko_KR/howto.rst | 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/Documentation/input/devices/xpad.rst 
b/Documentation/input/devices/xpad.rst
index b8bd65962dd8..173c2acda9fd 100644
--- a/Documentation/input/devices/xpad.rst
+++ b/Documentation/input/devices/xpad.rst
@@ -218,7 +218,7 @@ References
 .. [1] http://euc.jp/periphs/xbox-controller.ja.html (ITO Takayuki)
 .. [2] http://xpad.xbox-scene.com/
 .. [3] http://www.markosweb.com/www/xboxhackz.com/
-.. [4] http://lxr.free-electrons.com/ident?i=xpad_device
+.. [4] https://elixir.bootlin.com/linux/latest/ident/xpad_device
 
 
 Historic Edits
diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst
index 00c8ddd2ed2c..64deab5cfb3b 100644
--- a/Documentation/process/howto.rst
+++ b/Documentation/process/howto.rst
@@ -225,7 +225,7 @@ Cross-Reference project, which is able to present source 
code in a
 self-referential, indexed webpage format. An excellent up-to-date
 repository of the kernel code may be found at:
 
-   http://lxr.free-electrons.com/
+   https://elixir.bootlin.com/
 
 
 The development process
diff --git a/Documentation/process/kernel-docs.rst 
b/Documentation/process/kernel-docs.rst
index 3fb28de556e4..ab12dddc773e 100644
--- a/Documentation/process/kernel-docs.rst
+++ b/Documentation/process/kernel-docs.rst
@@ -565,7 +565,7 @@ Miscellaneous
 
 * Name: **Cross-Referencing Linux**
 
-  :URL: http://lxr.free-electrons.com/
+  :URL: https://elixir.bootlin.com/
   :Keywords: Browsing source code.
   :Description: Another web-based Linux kernel source code browser.
 Lots of cross references to variables and functions. You can see
diff --git a/Documentation/translations/it_IT/process/howto.rst 
b/Documentation/translations/it_IT/process/howto.rst
index 909e6a55bc43..f9a44b1af89d 100644
--- a/Documentation/translations/it_IT/process/howto.rst
+++ b/Documentation/translations/it_IT/process/howto.rst
@@ -234,7 +234,7 @@ il progetto Linux Cross-Reference, che è in grado di 
presentare codice
 sorgente in un formato autoreferenziale ed indicizzato. Un eccellente ed
 aggiornata fonte di consultazione del codice del kernel la potete trovare qui:
 
-   http://lxr.free-electrons.com/
+   https://elixir.bootlin.com/
 
 
 Il processo di sviluppo
diff --git a/Documentation/translations/ja_JP/howto.rst 
b/Documentation/translations/ja_JP/howto.rst
index f3116381c26b..2ca9389d5915 100644
--- a/Documentation/translations/ja_JP/howto.rst
+++ b/Documentation/translations/ja_JP/howto.rst
@@ -245,7 +245,7 @@ Linux カーネルソースツリーの中に含まれる、きれいにし、
 できます。この最新の素晴しいカーネルコードのリポジトリは以下で見つかり
 ます -
 
-   http://lxr.free-electrons.com/
+   https://elixir.bootlin.com/
 
 開発プロセス
 
diff --git a/Documentation/translations/ko_KR/howto.rst 
b/Documentation/translations/ko_KR/howto.rst
index a8197e072599..9fc869087e9c 100644
--- a/Documentation/translations/ko_KR/howto.rst
+++ b/Documentation/translations/ko_KR/howto.rst
@@ -235,7 +235,7 @@ ReST 마크업을 사용하는 문서들은 Documentation/output 에 생성된
 소스코드를 인덱스된 웹 페이지들의 형태로 보여준다. 최신의 멋진 커널
 코드 저장소는 다음을 통하여 참조할 수 있다.
 
-  http://lxr.free-electrons.com/
+  https://elixir.bootlin.com/
 
 
 개발 프로세스
-- 
2.20.1

Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma

[Christoph Hellwig]

On Wed, Jan 30, 2019 at 10:55:43AM -0500, Jerome Glisse wrote:
> Even outside GPU driver, device driver like RDMA just want to share their
> doorbell to other device and they do not want to see those doorbell page
> use in direct I/O or anything similar AFAICT.

At least Mellanox HCA support and inline data feature where you
can copy data directly into the BAR.  For something like a usrspace
NVMe target it might be very useful to do direct I/O straight into
the BAR for that.

[LSF/MM TOPIC] Use NVDIMM as NUMA node and NUMA API

[Yang Shi]

Hi folks,


I would like to attend the LSF/MM Summit 2019. I'm interested in most MM 
topics, particularly the NUMA API topic proposed by Jerome since it is 
related to my below proposal.


I would like to share some our usecases, needs and approaches about 
using NVDIMM as a NUMA node.


We would like to provide NVDIMM to our cloud customers as some low cost 
memory.  Virtual machines could run with NVDIMM as backed memory.  Then 
we would like the below needs are met:


* The ratio of DRAM vs NVDIMM is configurable per process, or even 
per VMA
* The user VMs alway get DRAM first as long as the ratio is not 
reached
* Migrate cold data to NVDIMM and keep hot data in DRAM dynamically 
and throughout the life time of VMs


To meet the needs we did some in-house implementation:
* Provide madvise interface to configure the ratio
* Put NVDIMM into a separate zonelist so that default allocation 
can't touch it as long as it is requested explicitly

* A kernel thread scans cold pages

We tried to just use current NUMA APIs, but we realized they can't meet 
our needs.  For example, if we configure a VMA use 50% DRAM and 50% 
NVDIMM, mbind() could set preferred node policy (DRAM node or NVDIMM 
node) for this VMA, but it can't control how much DRAM or NVDIMM is used 
by this specific VMA to satisfy the ratio.


So, IMHO we definitely need more fine-grained APIs to control the NUMA 
behavior.


I'd like also to discuss about this topic with:
Dave Hansen
Dan Williams
Fengguang Wu

Other than the above topic, I'd also like to meet other MM developers to 
discuss about some our usecases about memory cgroup (hallway 
conversation may be good enough).  I had submitted some RFC patches to 
the mailing list and they did incur some discussion, but we have not 
reached solid conclusion yet.


https://lore.kernel.org/lkml/1547061285-100329-1-git-send-email-yang@linux.alibaba.com/


Thanks,

Yang

Re: [PATCH RFC 1/3] dt-bindings: hwmon: Add tachometer interrupt to pwm-fan

[Guenter Roeck]

On Wed, Jan 30, 2019 at 04:07:05PM +0100, Stefan Wahren wrote:
> This adds the tachometer interrupt to the pwm-fan binding, which is
> necessary for RPM support.
> 
> Signed-off-by: Stefan Wahren 
> ---
>  Documentation/devicetree/bindings/hwmon/pwm-fan.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt 
> b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
> index 49ca5d8..7f69b0b 100644
> --- a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
> +++ b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
> @@ -8,6 +8,9 @@ Required properties:
>  
>  Optional properties:
>  - fan-supply: phandle to the regulator that provides power to the fan
> +- interrupts: contains a single interrupt specifier which describes the
> +  tachometer pin output of a 2 pulse-per-revolution fan.
> +  See interrupt-controller/interrupts.txt for the format.

So a hypothetical {1,4} pulse-per-revolution fan would explicitly not be
supported ? Why ?

Guenter

Re: [PATCH v2 6/7] scsi: libsas: reset the phy address if discover failed

[John Garry]

On 30/01/2019 08:24, Jason Yan wrote:

When we failed to discover the device, the phy address is still kept
in ex_phy. So when the next time we revalidate this phy the
address and device type is the same, it will be considered as flutter
and will not be discovered again. So the device will not be brought up.

Fix this by reset the phy address to the initial value. Then
in the next revalidation the device will be discovered agian.


Why fail to discover the device? I wonder in which scenario you have 
seen this, such that it is worth rediscovery.




Tested-by: Chen Liangfei 
Signed-off-by: Jason Yan 
CC: Xiaofei Tan 
CC: John Garry 
CC: Johannes Thumshirn 
CC: Ewan Milne 
CC: Christoph Hellwig 
CC: Tomas Henzl 
CC: Dan Williams 
CC: Hannes Reinecke 
---
 drivers/scsi/libsas/sas_expander.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/scsi/libsas/sas_expander.c 
b/drivers/scsi/libsas/sas_expander.c
index 6e56ebdc2148..e781941a7088 100644
--- a/drivers/scsi/libsas/sas_expander.c
+++ b/drivers/scsi/libsas/sas_expander.c
@@ -1100,6 +1100,13 @@ static int sas_ex_discover_dev(struct domain_device 
*dev, int phy_id)
 i, 
SAS_ADDR(ex->ex_phy[i].attached_sas_addr));
}
}
+   } else {
+   /* if we failed to discover this device, we have to
+* reset the expander phy attached address so that we
+* will not treat the phy as flutter in the next
+* revalidation
+*/
+   memset(ex_phy->attached_sas_addr, 0, SAS_ADDR_SIZE);
}

return res;

Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma

[Logan Gunthorpe]

On 2019-01-30 10:26 a.m., Christoph Hellwig wrote:
> On Wed, Jan 30, 2019 at 10:55:43AM -0500, Jerome Glisse wrote:
>> Even outside GPU driver, device driver like RDMA just want to share their
>> doorbell to other device and they do not want to see those doorbell page
>> use in direct I/O or anything similar AFAICT.
> 
> At least Mellanox HCA support and inline data feature where you
> can copy data directly into the BAR.  For something like a usrspace
> NVMe target it might be very useful to do direct I/O straight into
> the BAR for that.

Yup, these are things we definitely want to be able to do, and have done
with hacky garbage code: Direct I/O from NVMe to P2P BAR, then we could
Direct I/O to another drive or map it as an MR and send it over an RNIC.

We'd definitely like to move in that direction. And a world where such
userspace mappings are gimpped by the fact that they are only some
special feature of userspace VMAs that can only be used in specialized
userspace interfaces is not useful to us.

Logan

Re: [PATCH 8/9] dt-bindings: spi: atmel-quadspi: QuadSPI driver for Microchip SAM9X60

[Boris Brezillon]

On Wed, 30 Jan 2019 15:08:45 +
 wrote:

> From: Tudor Ambarus 
> 
> The sam9x60 qspi controller uses 2 clocks, one for the peripheral register
> access, the other for the qspi core and phy. Both are mandatory.
> 
> Signed-off-by: Tudor Ambarus 
> ---
>  .../devicetree/bindings/spi/atmel-quadspi.txt  | 28 
> --
>  1 file changed, 26 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/spi/atmel-quadspi.txt 
> b/Documentation/devicetree/bindings/spi/atmel-quadspi.txt
> index e9dae6264d89..e7b7f297c5d7 100644
> --- a/Documentation/devicetree/bindings/spi/atmel-quadspi.txt
> +++ b/Documentation/devicetree/bindings/spi/atmel-quadspi.txt
> @@ -1,14 +1,22 @@
>  * Atmel Quad Serial Peripheral Interface (QSPI)
>  
>  Required properties:
> -- compatible: Should be "atmel,sama5d2-qspi".
> +- compatible: Should be one of the following
> +   - "atmel,sama5d2-qspi"
> +   - "microchip,sam9x60-qspi"
>  - reg:Should contain the locations and lengths of the base 
> registers
>and the mapped memory.
>  - reg-names:  Should contain the resource reg names:
>- qspi_base: configuration register address space
>- qspi_mmap: memory mapped address space
>  - interrupts: Should contain the interrupt for the device.
> -- clocks: The phandle of the clock needed by the QSPI controller.
> +- clocks:  - "atmel,sama5d2-qspi": the phandle of the clock needed by the
> +   QSPI controller.
> +   - "microchip,sam9x60-qspi": should reference the peripheral
> +   and system QSPI clocks.
> +- clock-names:Only for sam9x60 - should contain two strigs:

   ^strings

And I think naming clocks even for sama5d2 is a good practice, so I'd
suggest making "pclk" mandatory even if you support unnamed clk in the
driver to be backward compatible with old DTs.

> +   - "pclk" for the peripheral clock
> +   - "qspick" for the system clock
>  - #address-cells: Should be <1>.
>  - #size-cells:Should be <0>.
>  
> @@ -29,3 +37,19 @@ spi@f002 {
>   ...
>   };
>  };
> +
> +qspi@f0014000 {
> + compatible = "microchip,sam9x60-qspi";
> + reg = <0xf0014000 0x100>, <0x7000 0x0800>;
> + reg-names = "qspi_base", "qspi_mmap";
> + interrupts = <35 IRQ_TYPE_LEVEL_HIGH 7>;
> + clocks =  <&pmc PMC_TYPE_PERIPHERAL 35>, <&pmc PMC_TYPE_SYSTEM 19>;
> + clock-names = "pclk", "qspick";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-names = "default";
> +
> + flash@0 {
> + ...
> + };
> +};

No need to add one example per compat, especially when all that
changes is the compat string and an extra clk. 

[PATCH] [media] ts2020: Variable "utmp" in function ts2020_set_tuner_rf() could be uninitialized

[Yizhuo]

In function ts2020_set_tuner_rf(), local variable "utmp" could
be uninitialized if function regmap_read() returns -EINVAL.
However, this value is used in if statement and written to
the register, which is potentially unsafe.

Signed-off-by: Yizhuo 
---
 drivers/media/dvb-frontends/ts2020.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/ts2020.c 
b/drivers/media/dvb-frontends/ts2020.c
index 931e5c98da8a..e351039f2eae 100644
--- a/drivers/media/dvb-frontends/ts2020.c
+++ b/drivers/media/dvb-frontends/ts2020.c
@@ -177,9 +177,12 @@ static int ts2020_set_tuner_rf(struct dvb_frontend *fe)
 {
struct ts2020_priv *dev = fe->tuner_priv;
int ret;
-   unsigned int utmp;
+   unsigned int utmp = 0;
 
ret = regmap_read(dev->regmap, 0x3d, &utmp);
+   if (ret)
+   return ret;
+
utmp &= 0x7f;
if (utmp < 0x16)
utmp = 0xa1;
-- 
2.17.1

Re: [PATCH 6/7] MIPS: SGI-IP27: use generic PCI driver

[Christoph Hellwig]

On Wed, Jan 30, 2019 at 06:25:20PM +0100, Thomas Bogendoerfer wrote:
> 
> and it's already there:-) Each struct device has a field numa_node and 
> pci_bus has
> contains a struct device. arm64 is already using it only not so nice part is 
> the
> usage of pcibios_root_bridge_prepare() to set the numa_node for the root bus.

Oh, great.  Maybe we can then just use that field for mips for now
and gradually move all architectures over.

> > Or add a add_dev callback, similar to what I did for a previous series
> > that we didn't end up needing after all:
> > 
> > http://git.infradead.org/users/hch/misc.git/commitdiff/06d9b4fc7deed336edc1292fe2e661729e98ec39
> 
> that's exactly what I'm looking for. Should I add the patch for my patchset or
> are you going to submit it after having a use case ?

Feel free to pick it up.  For the dma addressing limitations we
decided that exposing it through a DT property is the right way, so
that series isn't going anywhere.

Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma

[Jason Gunthorpe]

On Wed, Jan 30, 2019 at 06:26:53PM +0100, Christoph Hellwig wrote:
> On Wed, Jan 30, 2019 at 10:55:43AM -0500, Jerome Glisse wrote:
> > Even outside GPU driver, device driver like RDMA just want to share their
> > doorbell to other device and they do not want to see those doorbell page
> > use in direct I/O or anything similar AFAICT.
> 
> At least Mellanox HCA support and inline data feature where you
> can copy data directly into the BAR.  For something like a usrspace
> NVMe target it might be very useful to do direct I/O straight into
> the BAR for that.

It doesn't really work like that. 

The PCI-E TLP sequence to trigger this feature is very precise, and
the data requires the right headers/etc. Mixing that with O_DIRECT
seems very unlikely.

Jason

Re: [PATCH v2] sched/fair: Fix insertion in rq->leaf_cfs_rq_list

[Vincent Guittot]

On Wed, 30 Jan 2019 at 15:27, Vincent Guittot
 wrote:
>
> On Wed, 30 Jan 2019 at 15:01, Peter Zijlstra  wrote:
> >
> > On Wed, Jan 30, 2019 at 03:01:04PM +0100, Peter Zijlstra wrote:
> > > --- a/kernel/sched/fair.c
> > > +++ b/kernel/sched/fair.c
> > > @@ -282,13 +282,15 @@ static inline struct cfs_rq *group_cfs_r
> > >   return grp->my_q;
> > >  }
> > >
> > > -static inline void list_add_leaf_cfs_rq(struct cfs_rq *cfs_rq)
> > > +static inline bool list_add_leaf_cfs_rq(struct cfs_rq *cfs_rq)
> > >  {
> > >   struct rq *rq = rq_of(cfs_rq);
> > >   int cpu = cpu_of(rq);
> > >
> > >   if (cfs_rq->on_list)
> > > - return;
> > > + return rq->tmp_alone_branch == &rq->leaf_cfs_rq_list;
> >
> > And I'm almost certain that can be: return true, but got my brain in a
> > twist.
>
> Yes this can return true
>
> If cfs_rq->on_list) then a child not already on the list used the path :
>
> if (cfs_rq->tg->parent &&
>cfs_rq->tg->parent->cfs_rq[cpu]->on_list) {
>
> which does rq->tmp_alone_branch = &rq->leaf_cfs_rq_list;

In fact tests show that we must keep:
  return rq->tmp_alone_branch == &rq->leaf_cfs_rq_list;

Because the 1st sched_entity that will be used in the newly added
for_each_sched_entity loop, can be the sched_entityof the cfs_rq that
we just added in the list so cfs_rq->on_list == 1 but we must continue
to add parent

Apart from that, tests are ok

>
> >
> > > +
> > > + cfs_rq->on_list = 1;
> > >
> > >   /*
> > >* Ensure we either appear before our parent (if already

Re: [PATCH 00/11] btrfs: add zstd compression level support

[Dennis Zhou]

Hi David,

On Tue, Jan 29, 2019 at 06:18:30PM +0100, David Sterba wrote:
> On Mon, Jan 28, 2019 at 04:24:26PM -0500, Dennis Zhou wrote:
> > As mentioned above, a requirement that differs zstd from zlib is that
> > higher levels of compression require more memory. To manage this, each
> > compression level has its own queue of workspaces. A global LRU is used
> > to help with reclaim. To guarantee forward progress, a max level
> > workspace is preallocated and hidden from the LRU.
> 
> Here I'd like to bring up what was mentioned in previous iteration, the
> workspace sizes.
> 
> Level   Compression Memory
> 1   0.8 MB
> 2   1.0 MB
> 3   1.3 MB
> 4   0.9 MB
> 5   1.4 MB
> 6   1.5 MB
> 7   1.4 MB
> 8   1.8 MB
> 9   1.8 MB
> 10  1.8 MB
> 11  1.8 MB
> 12  1.8 MB
> 13  2.3 MB
> 14  2.6 MB
> 15  2.6 MB
> 
> and decompression needs memory of level 1. The sizes can be grouped
> together to say 3 sizes, I'm not sure that we'd really need 15 distinct
> workspaces. The reclaim mechanism helps, but I'd rather keep a smaller
> number of workspaces that covers average use.
> 
> Default level is 3, that's 1.3 MiB, that also covers level 1, 2 and 4.
> For 5 to 12 it's 1.8 and the rest is 2.6 MiB.
> 

I realize the current implementation doesn't have a monotonic memory
requirement guarantee. I've added that, and below is updated memory
requirements per level. I've updated the commit to include this too.

Level Memory (KB)
1780 
2   1004
3   1260
4   1260
5   1388
6   1516
7   1516
8   1772
9   1772
10  1772
11  1772
12  1772
13  2284
14  2547
15  2547

> > btrfs filesystem 10 times and then read back after dropping the caches.
> > The btrfs filesystem was on an SSD.
> > 
> > Level   Ratio   Compression (MB/s)  Decompression (MB/s)
> > 1   2.658438.47910.51
> > 2   2.744364.86886.55
> > 3   2.801336.33828.41
> > 4   2.858286.71886.55
> > 5   2.916212.77556.84
> > 6   2.363119.82990.85
> > 7   3.000154.06849.30
> > 8   3.011159.54875.03
> > 9   3.025100.51940.15
> > 10  3.033118.97616.26
> > 11  3.036 94.19802.11
> > 12  3.037 73.45931.49
> > 13  3.041 55.17835.26
> > 14  3.087 44.70716.78
> > 15  3.126 37.30878.84
> 
> From my casual user's perspective, I'd use the level 1 for speed, 7 for
> better ratio and 15 for the best compression. Anything else does not
> look good, though the results would vary based on the data set. I
> assume that the silesia corpus serves as a good approximation of the
> worst case average.
> 
> The levels 7-14 strike particularly obvious pattern: same ratio but the
> speed gets worse with each level. Taking the default level into account,
> (my) recommended levels would be 1, 3, 7, 15.
> 

I do see why we want to limit the number of levels as the memory
requirements do kind of bucket themselves. But, this means when zstd
gets updated, we'd have to reevaluate the compression levels btrfs
supports. I'm not sure it's a great idea to have that dependency.
I imagine we could offer some level of guidance, but it really would be
up to the user to figure out what works best for them.

The reclaim mechanism only keeps workspaces around if they are being
used by the appropriate level. So, the memory overhead is actively used
memory and if not, it is reclaimed after at most ~2 minutes later. I
also scan up before allocating a workspace, so that should help limit
the number of workspaces in circulation.

> I went through the patches, looks mostly ok, I don't like the
> indirections but at the moment it's an implementation detail as I'd like
> to agree on the overall approach first.
> 
> We might need a few revisions or cleanup rounds to converge to an
> efficient solution, the advantage here is that it's all in-memory and
> without compatibility concerns once the level support for zstd is in and
> works.
> 
> For that reason, I'm not opposed to the current version of the patchset.
> Given the time in development schedule, it's really close to code
> freeze, but the functionality has a narrow scope so I'm tentatively
> counting with it for 5.1.

Thanks,
Dennis

Re: [PATCH 2/2] mm: Consider subtrees in memory.events

[Michal Hocko]

On Wed 30-01-19 09:06:58, Tejun Heo wrote:
> Hello, Michal.
> 
> On Wed, Jan 30, 2019 at 05:50:58PM +0100, Michal Hocko wrote:
> > > Yeah, cgroup.events and .stat files as some of the local stats would
> > > be useful too, so if we don't flip memory.events we'll end up with sth
> > > like cgroup.events.local, memory.events.tree and memory.stats.local,
> > > which is gonna be hilarious.
> > 
> > Why cannot we simply have memory.events_tree and be done with it? Sure
> > the file names are not goin to be consistent which is a minus but that
> > ship has already sailed some time ago.
> 
> Because the overall cost of shitty interface will be way higher in the
> longer term.

But we are discussing the file name effectively. I do not see a long
term maintenance burden. Confusing? Probably yes but that is were the
documentation would be helpful.
-- 
Michal Hocko
SUSE Labs

Have needs for your photos?

[Jane]

Do you need to make white background for your photos?
Adding  clipping path, or retouching?

We can do it for you.
Let's start with testing for your photos.

Thanks,
Jane

Have needs for your photos?

[Jane]

Do you need to make white background for your photos?
Adding  clipping path, or retouching?

We can do it for you.
Let's start with testing for your photos.

Thanks,
Jane

Re: [PATCH v2 2/7] coresight: perf: Add "sinks" group to PMU directory

[Suzuki K Poulose]

Hi Mathieu,


On 01/22/2019 06:11 PM, Mathieu Poirier wrote:

Add a "sinks" directory entry so that users can see all the sinks
available in the system in a single place.  Individual sink are added
as they are registered with the coresight bus.


A couple of minor comments.



Signed-off-by: Mathieu Poirier 
---
  .../hwtracing/coresight/coresight-etm-perf.c  | 76 +++
  .../hwtracing/coresight/coresight-etm-perf.h  |  6 +-
  drivers/hwtracing/coresight/coresight.c   | 18 +
  include/linux/coresight.h |  7 +-
  4 files changed, 104 insertions(+), 3 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c 
b/drivers/hwtracing/coresight/coresight-etm-perf.c
index f21eb28b6782..c68a0036532c 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -14,6 +14,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  
@@ -43,8 +44,18 @@ static const struct attribute_group etm_pmu_format_group = {

.attrs  = etm_config_formats_attr,
  };
  
+static struct attribute *etm_config_sinks_attr[] = {

+   NULL,
+};
+
+static const struct attribute_group etm_pmu_sinks_group = {
+   .name   = "sinks",
+   .attrs  = etm_config_sinks_attr,
+};
+
  static const struct attribute_group *etm_pmu_attr_groups[] = {
&etm_pmu_format_group,
+   &etm_pmu_sinks_group,
NULL,
  };


I was thinking if this could be the "events" directory for ETM pmu. We
don't have any other event codes. Even if we get in the future, we could
expose them here. But from a quick try it looks like the event names
cannot start with a number (e.g, 2007000.etr wouldn't parse as an event
name). So we could leave this as above and switch when we get generic
naming scheme.

  
@@ -479,6 +490,71 @@ int etm_perf_symlink(struct coresight_device *csdev, bool link)

return 0;
  }
  
+static ssize_t etm_perf_sink_name_show(struct device *dev,

+  struct device_attribute *dattr,
+  char *buf)
+{
+   /* See function coresight_get_sink_by_id() to know where this is used */
+   u32 hash = hashlen_hash(hashlen_string(NULL, dattr->attr.name));
+
+   return scnprintf(buf, PAGE_SIZE, "%x\n", hash);
+}


You may need "0x%x" to avoid confusions interpreting the data.


+
+int etm_perf_add_symlink_sink(struct coresight_device *csdev)
+{
+   int ret;
+   struct device *pmu_dev = etm_pmu.dev;
+   struct device *pdev = csdev->dev.parent;
+   struct device_attribute *dattr;


If we make this a struct dev_ext_attribute(), you get a space to
store the "id" in the "var" field. This can be used for

1) name_show() above

we could do :
struct dev_ext_attribute *eattr = container_of(attr,
struct dev_ext_attribute, attr);

return scnprintf(bu, PAGE_SIZE, "0x%x\n", (u32)eattr->var);

2) Matching the ID of a sink device in lookup by simply doing :
(u32)csdev->dattr.var == (u32)(void *)data

and can avoid computing the hash all the time.


+
+   if (csdev->type != CORESIGHT_DEV_TYPE_SINK &&
+   csdev->type != CORESIGHT_DEV_TYPE_LINKSINK)
+   return -EINVAL;
+
+   if (csdev->dattr != NULL)
+   return -EINVAL;
+
+   if (!etm_perf_up)
+   return -EPROBE_DEFER;
+
+   dattr = kzalloc(sizeof(*dattr), GFP_KERNEL);


nit: Could we use devm_kzalloc(pdev, ...) ?


+   dattr->attr.name = kstrdup(dev_name(pdev), GFP_KERNEL);.



similarly here : devm_kstrdup()


+   dattr->attr.mode = 0444;
+   dattr->show = etm_perf_sink_name_show;
+   csdev->dattr = dattr;
+
+   ret = sysfs_add_file_to_group(&pmu_dev->kobj,
+ &dattr->attr, "sinks");
+
+   if (!ret)
+   return 0;
+
+   csdev->dattr = NULL;
+   kfree(dattr->attr.name);
+   kfree(dattr);


And we could get rid of these ^


+
+   return ret;
+}
+
+void etm_perf_del_symlink_sink(struct coresight_device *csdev)
+{
+   struct device *pmu_dev = etm_pmu.dev;
+   struct device_attribute *dattr = csdev->dattr;
+
+   if (csdev->type != CORESIGHT_DEV_TYPE_SINK &&
+   csdev->type != CORESIGHT_DEV_TYPE_LINKSINK)
+   return;
+
+   if (!dattr)
+   return;
+
+   sysfs_remove_file_from_group(&pmu_dev->kobj,
+&dattr->attr, "sinks");
+   csdev->dattr = NULL;
+   kfree(dattr->attr.name);
+   kfree(dattr);ext


And these ^^


+}




diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index 46c67a764877..a42fac83eac9 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -154,8 +154,9 @@ struct coresight_connection {
   * @orphan:   true if the component has connections that haven't been linked.
   * @enable:   'true' if component is currently part of

Re: [PATCH 9/9] spi: atmel-quadspi: add support for sam9x60 qspi controller

[Boris Brezillon]

On Wed, 30 Jan 2019 15:08:47 +
 wrote:

> +static int atmel_sam9x60_qspi_clk_prepare_enable(struct atmel_qspi *aq)
> +{
> + struct device *dev = &aq->pdev->dev;
> + int ret;
> +
> + if (!aq->clk) {
> + /* Get the peripheral clock */
> + aq->clk = devm_clk_get(dev, "pclk");
> + if (IS_ERR(aq->clk)) {
> + dev_err(dev, "missing peripheral clock\n");
> + return PTR_ERR(aq->clk);
> + }
> + }
> +
> + if (!aq->qspick) {
> + /* Get the QSPI system clock */
> + aq->qspick = devm_clk_get(dev, "qspick");
> + if (IS_ERR(aq->qspick)) {
> + dev_err(dev, "missing system clock\n");
> + return PTR_ERR(aq->qspick);
> + }
> + }

Move the devm_clk_get() calls to the probe path instead of doing it at
prepare time, and you can make it generic for both compats with
something like:

aq->clk = devm_clk_get(dev, "pclk");
if (IS_ERR(aq->clk))
aq->clk = devm_clk_get(dev, NULL);

if (IS_ERR(aq->clk))
return PTR_ERR(aq->clk);

if (aq->caps->qspick_required) {
aq->qspick = devm_clk_get(dev, "qspick");
if (IS_ERR(aq->qspick)) {
return PTR_ERR(aq->qspick);
}

> +
> + /* Enable the peripheral clock */
> + ret = clk_prepare_enable(aq->clk);
> + if (ret) {
> + dev_err(dev, "failed to enable the peripheral clock\n");
> + return ret;
> + }
> +
> + /* Enable the QSPI system clock */
> + ret = clk_prepare_enable(aq->qspick);
> + if (ret) {
> + dev_err(dev, "failed to enable the QSPI system clock\n");
> + clk_disable_unprepare(aq->clk);
> + }

Again, you can make the enable function generic since
clk_prepare_enable(NULL) is a NO-OP that returns 0 and aq->qspick will
be NULL when it's not required.

> +
> + return ret;
> +}
> +
> +static void atmel_sam9x60_qspi_clk_disable_unprepare(struct atmel_qspi *aq)
> +{
> + clk_disable_unprepare(aq->qspick);
> + clk_disable_unprepare(aq->clk);

Ditto.

> +}

Re: [RFD] A mount api that notices previous mounts

[Karel Zak]

On Wed, Jan 30, 2019 at 01:01:54PM +, David Howells wrote:
> Karel Zak  wrote:
> 
> > It seems more elegant is to ask for Nth option as expected by fsinfo().
> 
> More elegant yes, but there's an issue with atomiticity[*].  I'm in the
> process of switching to something that returns you a single buffer with all
> the options in, but each key and each value is preceded by a length count.

Sounds good, for me is important to avoid all the split/join
operations with the strings.

> The reasons for not using separator characters are:
> 
>  (1) There's no separator char that cannot validly occur within an option[**].

Yes, it's pretty common for selinux mount options where "," is
used within an option, so mount options string looks like

'context="system_u:object_r:tmp_t:s0:c127,c456",noexec'

and I have doubts all the parses in userspace are compatible with this
use case...

>  (2) Makes it possible to return binary values if we need to.

Yes.

> [**] Oh, and look at cifs where you can *change* the separator char during
>  option parsing ("sep=").

No comment :-)

Karel

-- 
 Karel Zak  
 http://karelzak.blogspot.com

Re: [RFC PATCH 3/5] mm/vma: add support for peer to peer to device vma

[Jason Gunthorpe]

On Wed, Jan 30, 2019 at 09:02:08AM +0100, Christoph Hellwig wrote:
> On Tue, Jan 29, 2019 at 08:58:35PM +, Jason Gunthorpe wrote:
> > On Tue, Jan 29, 2019 at 01:39:49PM -0700, Logan Gunthorpe wrote:
> > 
> > > implement the mapping. And I don't think we should have 'special' vma's
> > > for this (though we may need something to ensure we don't get mapping
> > > requests mixed with different types of pages...).
> > 
> > I think Jerome explained the point here is to have a 'special vma'
> > rather than a 'special struct page' as, really, we don't need a
> > struct page at all to make this work.
> > 
> > If I recall your earlier attempts at adding struct page for BAR
> > memory, it ran aground on issues related to O_DIRECT/sgls, etc, etc.
> 
> Struct page is what makes O_DIRECT work, using sgls or biovecs, etc on
> it work.  Without struct page none of the above can work at all.  That
> is why we use struct page for backing BARs in the existing P2P code.
> Not that I'm a particular fan of creating struct page for this device
> memory, but without major invasive surgery to large parts of the kernel
> it is the only way to make it work.

I don't think anyone is interested in O_DIRECT/etc for RDMA doorbell
pages.

.. and again, I recall Logan already attempted to mix non-CPU memory
into sgls and it was a disaster. You pointed out that one cannot just
put iomem addressed into a SGL without auditing basically the entire
block stack to prove that nothing uses iomem without an iomem
accessor.

I recall that proposal veered into a direction where the block layer
would just fail very early if there was iomem in the sgl, so generally
no O_DIRECT support anyhow.

We already accepted the P2P stuff from Logan as essentially a giant
special case - it only works with RDMA and only because RDMA MR was
hacked up with a special p2p callback.

I don't see why a special case with a VMA is really that different.

If someone figures out the struct page path down the road it can
obviously be harmonized with this VMA approach pretty easily.

Jason

Re: [GIT PULL] GPIO fixes for the v5.0 series, take two

[pr-tracker-bot]

The pull request you sent on Wed, 30 Jan 2019 10:08:56 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git 
> tags/gpio-v5.0-3

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/877ef51d53abfdadabc64809d045d9c27c1cf757

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [git pull] IOMMU Fixes for Linux v5.0-rc4

[pr-tracker-bot]

The pull request you sent on Wed, 30 Jan 2019 16:06:23 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git 
> tags/iommu-fixes-v5.0-rc4

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1c0490ce902206f4685f812fa81304fd1adf4e35

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

[PATCH] staging:wlan-ng:cfg80211.c Fixed line more than 80 characters.

[SandeshKa07]

From: Sandesh Kenjana Ashok 

Lines over 80 characters are adjusted according to standards

Signed-off-by: Sandesh Kenjana Ashok 
---
 drivers/staging/wlan-ng/cfg80211.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/wlan-ng/cfg80211.c 
b/drivers/staging/wlan-ng/cfg80211.c
index e5d7def1f366..7687f619ee34 100644
--- a/drivers/staging/wlan-ng/cfg80211.c
+++ b/drivers/staging/wlan-ng/cfg80211.c
@@ -373,7 +373,8 @@ static int prism2_scan(struct wiphy *wiphy,
msg2.beaconperiod.data,
ie_buf,
ie_len,
-   (msg2.signal.data - 65536) * 100, /* Conversion to 
signed type */
+   /*Conversion to signed type*/
+   (msg2.signal.data - 65536) * 100,
GFP_KERNEL
);
 
@@ -410,7 +411,7 @@ static int prism2_set_wiphy_params(struct wiphy *wiphy, u32 
changed)
data = wiphy->rts_threshold;
 
result = prism2_domibset_uint32(wlandev,
-   
DIDMIB_DOT11MAC_OPERATIONTABLE_RTSTHRESHOLD,
+   DIDMIB_DOT11MAC_OPERATIONTABLE_RTSTHRESHOLD,
data);
if (result) {
err = -EFAULT;
@@ -425,7 +426,7 @@ static int prism2_set_wiphy_params(struct wiphy *wiphy, u32 
changed)
data = wiphy->frag_threshold;
 
result = prism2_domibset_uint32(wlandev,
-   
DIDMIB_DOT11MAC_OPERATIONTABLE_FRAGMENTATIONTHRESHOLD,
+   DIDMIB_DOT11MAC_OPERATIONTABLE_FRAGMENTATIONTHRESHOLD,
data);
if (result) {
err = -EFAULT;
@@ -455,7 +456,7 @@ static int prism2_connect(struct wiphy *wiphy, struct 
net_device *dev,
if (channel) {
chan = ieee80211_frequency_to_channel(channel->center_freq);
result = prism2_domibset_uint32(wlandev,
-   
DIDMIB_DOT11PHY_DSSSTABLE_CURRENTCHANNEL,
+   DIDMIB_DOT11PHY_DSSSTABLE_CURRENTCHANNEL,
chan);
if (result)
goto exit;
@@ -502,13 +503,13 @@ static int prism2_connect(struct wiphy *wiphy, struct 
net_device *dev,
 * seems reasonable anyways
 */
result = prism2_domibset_uint32(wlandev,
-   
DIDMIB_DOT11SMT_PRIVACYTABLE_PRIVACYINVOKED,
+   DIDMIB_DOT11SMT_PRIVACYTABLE_PRIVACYINVOKED,
P80211ENUM_truth_true);
if (result)
goto exit;
 
result = prism2_domibset_uint32(wlandev,
-   
DIDMIB_DOT11SMT_PRIVACYTABLE_EXCLUDEUNENCRYPTED,
+   DIDMIB_DOT11SMT_PRIVACYTABLE_EXCLUDEUNENCRYPTED,
P80211ENUM_truth_true);
if (result)
goto exit;
@@ -518,13 +519,13 @@ static int prism2_connect(struct wiphy *wiphy, struct 
net_device *dev,
 * and exclude unencrypted
 */
result = prism2_domibset_uint32(wlandev,
-   
DIDMIB_DOT11SMT_PRIVACYTABLE_PRIVACYINVOKED,
+   DIDMIB_DOT11SMT_PRIVACYTABLE_PRIVACYINVOKED,
P80211ENUM_truth_false);
if (result)
goto exit;
 
result = prism2_domibset_uint32(wlandev,
-   
DIDMIB_DOT11SMT_PRIVACYTABLE_EXCLUDEUNENCRYPTED,
+   DIDMIB_DOT11SMT_PRIVACYTABLE_EXCLUDEUNENCRYPTED,
P80211ENUM_truth_false);
if (result)
goto exit;
-- 
2.17.1

Re: [PATCH v2 3/7] coresight: Use event attributes for sink selection

[Suzuki K Poulose]

On 01/22/2019 06:11 PM, Mathieu Poirier wrote:

This patch uses the information conveyed by perf_event::attr::config2
to select a sink to use for the session.  That way a sink can easily be
selected to be used by more than one source, something that isn't currently
possible with the sysfs implementation.

Signed-off-by: Mathieu Poirier 
---
  .../hwtracing/coresight/coresight-etm-perf.c  | 24 ++--
  drivers/hwtracing/coresight/coresight-priv.h  |  1 +
  drivers/hwtracing/coresight/coresight.c   | 39 +++
  3 files changed, 52 insertions(+), 12 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c 
b/drivers/hwtracing/coresight/coresight-etm-perf.c
index c68a0036532c..ea031eb673b3 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -31,11 +31,14 @@ static DEFINE_PER_CPU(struct coresight_device *, csdev_src);
  PMU_FORMAT_ATTR(cycacc,   "config:" __stringify(ETM_OPT_CYCACC));
  PMU_FORMAT_ATTR(timestamp,"config:" __stringify(ETM_OPT_TS));
  PMU_FORMAT_ATTR(retstack, "config:" __stringify(ETM_OPT_RETSTK));
+/* Sink ID - same for all ETMs */
+PMU_FORMAT_ATTR(sinkid,"config2:0-31");
  
  static struct attribute *etm_config_formats_attr[] = {

&format_attr_cycacc.attr,
&format_attr_timestamp.attr,
&format_attr_retstack.attr,
+   &format_attr_sinkid.attr,
NULL,
  };
  
@@ -191,6 +194,7 @@ static void etm_free_aux(void *data)

  static void *etm_setup_aux(struct perf_event *event, void **pages,
   int nr_pages, bool overwrite)
  {
+   u32 id;
int cpu = event->cpu;
cpumask_t *mask;
struct coresight_device *sink;
@@ -201,18 +205,14 @@ static void *etm_setup_aux(struct perf_event *event, void 
**pages,
return NULL;
INIT_WORK(&event_data->work, free_event_data);
  
-	/*

-* In theory nothing prevent tracers in a trace session from being
-* associated with different sinks, nor having a sink per tracer.  But
-* until we have HW with this kind of topology we need to assume tracers
-* in a trace session are using the same sink.  Therefore go through
-* the coresight bus and pick the first enabled sink.
-*
-* When operated from sysFS users are responsible to enable the sink
-* while from perf, the perf tools will do it based on the choice made
-* on the cmd line.  As such the "enable_sink" flag in sysFS is reset.
-*/
-   sink = coresight_get_enabled_sink(true);
+   /* First get the selected sink from user space. */
+   if (event->attr.config2) {
+   id = (u32)event->attr.config2;
+   sink = coresight_get_sink_by_id(id);
+   } else {
+   sink = coresight_get_enabled_sink(true);
+   }
+
if (!sink || !sink_ops(sink)->alloc_buffer)
goto err;
  
diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h

index 579f34943bf1..b936c6d7e13f 100644
--- a/drivers/hwtracing/coresight/coresight-priv.h
+++ b/drivers/hwtracing/coresight/coresight-priv.h
@@ -147,6 +147,7 @@ void coresight_disable_path(struct list_head *path);
  int coresight_enable_path(struct list_head *path, u32 mode, void *sink_data);
  struct coresight_device *coresight_get_sink(struct list_head *path);
  struct coresight_device *coresight_get_enabled_sink(bool reset);
+struct coresight_device *coresight_get_sink_by_id(u32 id);
  struct list_head *coresight_build_path(struct coresight_device *csdev,
   struct coresight_device *sink);
  void coresight_release_path(struct list_head *path);
diff --git a/drivers/hwtracing/coresight/coresight.c 
b/drivers/hwtracing/coresight/coresight.c
index d7fa90be6f42..c5f2df186a19 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -11,6 +11,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -541,6 +542,44 @@ struct coresight_device *coresight_get_enabled_sink(bool 
deactivate)
return dev ? to_coresight_device(dev) : NULL;
  }
  
+static int coresight_sink_by_id(struct device *dev, void *data)

+{
+   struct coresight_device *csdev = to_coresight_device(dev);
+   u32 hash;
+
+   if (csdev->type == CORESIGHT_DEV_TYPE_SINK ||
+csdev->type == CORESIGHT_DEV_TYPE_LINKSINK) {
+   /*
+* See function etm_perf_sink_name_show() to know where this
+* comes from.
+*/
+   hash = hashlen_hash(hashlen_string(NULL, dev_name(dev)));
+
+   if (hash == (*(u32 *)data))
+   return 1;
+   }
+
+   return 0;
+}
+
+/**
+ * coresight_get_sink_by_id - returns the sink that matches the id
+ * @id: Id of the sink to match
+ *
+ * The n

Re: [PATCH v2 4/7] perf pmu: Moving EVENT_SOURCE_DEVICE_PATH to PMU header file

[Suzuki K Poulose]

On 01/22/2019 06:11 PM, Mathieu Poirier wrote:

Moving definition of EVENT_SOURCE_DEVICE_PATH to pmu.h so that it can be
used by other files than pmu.c

Signed-off-by: Mathieu Poirier 
---
  tools/perf/util/pmu.c | 2 --
  tools/perf/util/pmu.h | 1 +
  2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 11a234740632..51d437f55d18 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -29,8 +29,6 @@ struct perf_pmu_format {
struct list_head list;
  };
  
-#define EVENT_SOURCE_DEVICE_PATH "/bus/event_source/devices/"

-
  int perf_pmu_parse(struct list_head *list, char *name);
  extern FILE *perf_pmu_in;
  
diff --git a/tools/perf/util/pmu.h b/tools/perf/util/pmu.h

index 76fecec7b3f9..350c54e0bd3d 100644
--- a/tools/perf/util/pmu.h
+++ b/tools/perf/util/pmu.h
@@ -16,6 +16,7 @@ enum {
  };
  
  #define PERF_PMU_FORMAT_BITS 64

+#define EVENT_SOURCE_DEVICE_PATH "/bus/event_source/devices/"
  
  struct perf_event_attr;
  



FWIW:

Acked-by: Suzuki K Poulose