[PATCH] tpm: Add module parameter for hwrng quality.
It is now possible for drivers to easily specify a hwrng quality, however
most do not currently do this, and in cases where they do, it may be
desirable to override the driver-specified value with a user-specified
one. This patch adds a parameter to set or override the hwrng quality.
Signed-off-by: Louis Collard
---
drivers/char/tpm/tpm-chip.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
index 0a62c19937b6..4def49cfc634 100644
--- a/drivers/char/tpm/tpm-chip.c
+++ b/drivers/char/tpm/tpm-chip.c
@@ -33,6 +33,11 @@
DEFINE_IDR(dev_nums_idr);
static DEFINE_MUTEX(idr_lock);
+static short override_rng_quality = -1;
+module_param(override_rng_quality, short, 0644);
+MODULE_PARM_DESC(override_rng_quality,
+"tpm-rng quality (overrides values provided by drivers)");
+
struct class *tpm_class;
struct class *tpmrm_class;
dev_t tpm_devt;
@@ -409,6 +414,13 @@ static int tpm_add_hwrng(struct tpm_chip *chip)
"tpm-rng-%d", chip->dev_num);
chip->hwrng.name = chip->hwrng_name;
chip->hwrng.read = tpm_hwrng_read;
+ if (override_rng_quality > -1) {
+ dev_info(&chip->dev,
+"Overriding hwrng quality for %s: driver default=%d,
override=%d",
+chip->hwrng.name, chip->hwrng.quality,
+override_rng_quality);
+ chip->hwrng.quality = override_rng_quality;
+ }
return hwrng_register(&chip->hwrng);
}
--
2.13.5
Re: [PATCH] HID: google: Add support for whiskers
On Fri, Jun 8, 2018 at 2:14 AM, Nicolas Boichat wrote:
> Another device in the hammer class, with USB id 0x5030.
>
> Signed-off-by: Nicolas Boichat
> ---
Acked-by: Benjamin Tissoires
Cheers,
Benjamin
> drivers/hid/hid-google-hammer.c | 2 ++
> drivers/hid/hid-ids.h | 1 +
> 2 files changed, 3 insertions(+)
>
> diff --git a/drivers/hid/hid-google-hammer.c b/drivers/hid/hid-google-hammer.c
> index 7b8e17b03cb86..6bf4da7ad63a5 100644
> --- a/drivers/hid/hid-google-hammer.c
> +++ b/drivers/hid/hid-google-hammer.c
> @@ -124,6 +124,8 @@ static const struct hid_device_id hammer_devices[] = {
> USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_STAFF) },
> { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC,
> USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_WAND) },
> + { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC,
> +USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_WHISKERS) },
> { }
> };
> MODULE_DEVICE_TABLE(hid, hammer_devices);
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index a85634fe033f0..c7981ddd87763 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -452,6 +452,7 @@
> #define USB_DEVICE_ID_GOOGLE_TOUCH_ROSE0x5028
> #define USB_DEVICE_ID_GOOGLE_STAFF 0x502b
> #define USB_DEVICE_ID_GOOGLE_WAND 0x502d
> +#define USB_DEVICE_ID_GOOGLE_WHISKERS 0x5030
>
> #define USB_VENDOR_ID_GOTOP0x08f2
> #define USB_DEVICE_ID_SUPER_Q2 0x007f
> --
> 2.18.0.rc1.242.g61856ae69a-goog
>
Re: [PATCH v6 1/3] phy: Update PHY power control sequence
Hi,
On 5/29/2018 10:07 AM, Can Guo wrote:
> All PHYs should be powered on before register configuration starts. And
> only PCIe PHYs need an extra power control before deasserts reset state.
>
> Signed-off-by: Can Guo
> ---
> drivers/phy/qualcomm/phy-qcom-qmp.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
> b/drivers/phy/qualcomm/phy-qcom-qmp.c
> index 97ef942..f779b0f 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
> @@ -982,6 +982,8 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
> if (cfg->has_phy_com_ctrl)
> qphy_setbits(serdes, cfg->regs[QPHY_COM_POWER_DOWN_CONTROL],
>SW_PWRDN);
> + else
> + qphy_setbits(pcs, QPHY_POWER_DOWN_CONTROL, cfg->pwrdn_ctrl);
We should power-up PHYs after following dp_com_ctrl programming which
powers-off USB-DP combo PHY when it brings DP_COM block out of reset reset.
>
> if (cfg->has_phy_dp_com_ctrl) {
> qphy_setbits(dp_com, QPHY_V3_DP_COM_POWER_DOWN_CTRL,
> @@ -1127,7 +1129,8 @@ static int qcom_qmp_phy_init(struct phy *phy)
>* Pull out PHY from POWER DOWN state.
>* This is active low enable signal to power-down PHY.
>*/
> - qphy_setbits(pcs, QPHY_POWER_DOWN_CONTROL, cfg->pwrdn_ctrl);
> + if (cfg->type == PHY_TYPE_PCIE)
> + qphy_setbits(pcs, QPHY_POWER_DOWN_CONTROL, cfg->pwrdn_ctrl);
>
> if (cfg->has_pwrdn_delay)
> usleep_range(cfg->pwrdn_delay_min, cfg->pwrdn_delay_max);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH 1/2] ARM: dts: igep: Relicense the IGEP boards under GPLv2/X11
* Tony Lindgren [180607 23:32]: > Hi, > > * Enric Balletbo i Serra [180606 08:27]: > > The current GPLv2 only licensing on IGEP boards makes it very impractical > > for other software components licensed under another license. > > > > In order to make it easier for them to reuse our device trees, relicense > > all boards under a GPLv2/X11 dual-license. Also switch to use the SPDX > > identifiers and remove the boiler plate license text. > > I don't think you have all the people in Cc who have already > contributed patches to these files, can you please check the > files with git log? Oh and these still include omap3.dtsi and other GPL 2.0 licensed files so this relicensing may not work out without lots of emails and and acks from all the contributors. Regards, Tony
Re: 4.17-ad1: -march=native support or Kernel Ricers wanted
Hi Alexey, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.17] [cannot apply to tip/x86/core next-20180607] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Alexey-Dobriyan/4-17-ad1-march-native-support-or-Kernel-Ricers-wanted/20180605-090623 config: m68k-allmodconfig (attached as .config) compiler: m68k-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=m68k All errors (new ones prefixed by >>): WARNING: unmet direct dependencies detected for PREEMPT_COUNT Depends on COLDFIRE Selected by - DEBUG_ATOMIC_SLEEP && DEBUG_KERNEL execvp: scripts/march-native.sh: Permission denied Makefile arch include scripts source Error 127 Makefile arch include scripts source Error 2 >> Makefile arch include scripts source No rule to make target >> 'include/config/auto.conf', needed by 'include/config/kernel.release'. Target 'prepare' not remade because of errors. make: Makefile arch include scripts source Error 2 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
[PATCH] compiler-gcc.h: don't set COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW for sparse
sparse errors out with ./include/linux/overflow.h:254:13: error: undefined identifier '__builtin_mul_overflow' ./include/linux/overflow.h:254:13: error: incorrect type in conditional ./include/linux/overflow.h:254:13:got void ./include/linux/overflow.h:256:13: error: undefined identifier '__builtin_add_overflow' ./include/linux/overflow.h:256:13: error: incorrect type in conditional ./include/linux/overflow.h:256:13:got void Sparse has not acquired generic overflow builtins yet, so don't set COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW for it. Signed-off-by: Miroslav Benes Acked-by: Rasmus Villemoes --- include/linux/compiler-gcc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h index f1a7492a5cc8..15e55b89e952 100644 --- a/include/linux/compiler-gcc.h +++ b/include/linux/compiler-gcc.h @@ -344,6 +344,6 @@ */ #define uninitialized_var(x) x = x -#if GCC_VERSION >= 50100 +#if GCC_VERSION >= 50100 && !defined(__CHECKER__) #define COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW 1 #endif -- 2.17.0
Re: [PATCH 1/2] ARM: dts: igep: Relicense the IGEP boards under GPLv2/X11
Hi, * Enric Balletbo i Serra [180606 08:27]: > The current GPLv2 only licensing on IGEP boards makes it very impractical > for other software components licensed under another license. > > In order to make it easier for them to reuse our device trees, relicense > all boards under a GPLv2/X11 dual-license. Also switch to use the SPDX > identifiers and remove the boiler plate license text. I don't think you have all the people in Cc who have already contributed patches to these files, can you please check the files with git log? Regards, Tony
Re: [PATCH v4 3/4] mm/sparse: Add a new parameter 'data_unit_size' for alloc_usemap_and_memmap
On 06/07/18 at 03:48pm, Dave Hansen wrote: > On 05/21/2018 03:15 AM, Baoquan He wrote: > > It's used to pass the size of map data unit into alloc_usemap_and_memmap, > > and is preparation for next patch. > > This is the "what", but not the "why". Could you add another sentence > or two to explain why we need this? Thanks for reviewing, Dave. In alloc_usemap_and_memmap(), it will call sparse_early_usemaps_alloc_node() or sparse_early_mem_maps_alloc_node() to allocate usemap and memmap for each node and install them into usemap_map[] and map_map[]. Here we need pass in the number of present sections on this node so that we can move pointer of usemap_map[] and map_map[] to right position. How do think about above words? Thanks Baoquan
[PATCH v2 2/4] clk: rockchip: add dt-binding header for px30
Add the dt-bindings header for the px30, that gets shared between the clock controller and the clock references in the dts. Add softreset ID for px30. Signed-off-by: Elaine Zhang --- include/dt-bindings/clock/px30-cru.h | 402 +++ 1 file changed, 402 insertions(+) create mode 100644 include/dt-bindings/clock/px30-cru.h diff --git a/include/dt-bindings/clock/px30-cru.h b/include/dt-bindings/clock/px30-cru.h new file mode 100644 index ..6b0b9507597a --- /dev/null +++ b/include/dt-bindings/clock/px30-cru.h @@ -0,0 +1,402 @@ +/* + * Copyright (c) 2018 Rockchip Electronics Co. Ltd. + * Author: Elaine Zhang + * + * 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; either version 2 of the License, or + * (at your option) any later version. + * + * 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. + */ + +#ifndef _DT_BINDINGS_CLK_ROCKCHIP_PX30_H +#define _DT_BINDINGS_CLK_ROCKCHIP_PX30_H + +/* core clocks */ +#define PLL_APLL 1 +#define PLL_DPLL 2 +#define PLL_CPLL 3 +#define PLL_NPLL 4 +#define APLL_BOOST_H 5 +#define APLL_BOOST_L 6 +#define ARMCLK 7 + +/* sclk gates (special clocks) */ +#define USB480M14 +#define SCLK_PDM 15 +#define SCLK_I2S0_TX 16 +#define SCLK_I2S0_TX_OUT 17 +#define SCLK_I2S0_RX 18 +#define SCLK_I2S0_RX_OUT 19 +#define SCLK_I2S1 20 +#define SCLK_I2S1_OUT 21 +#define SCLK_I2S2 22 +#define SCLK_I2S2_OUT 23 +#define SCLK_UART1 24 +#define SCLK_UART2 25 +#define SCLK_UART3 26 +#define SCLK_UART4 27 +#define SCLK_UART5 28 +#define SCLK_I2C0 29 +#define SCLK_I2C1 30 +#define SCLK_I2C2 31 +#define SCLK_I2C3 32 +#define SCLK_I2C4 33 +#define SCLK_PWM0 34 +#define SCLK_PWM1 35 +#define SCLK_SPI0 36 +#define SCLK_SPI1 37 +#define SCLK_TIMER038 +#define SCLK_TIMER139 +#define SCLK_TIMER240 +#define SCLK_TIMER341 +#define SCLK_TIMER442 +#define SCLK_TIMER543 +#define SCLK_TSADC 44 +#define SCLK_SARADC45 +#define SCLK_OTP 46 +#define SCLK_OTP_USR 47 +#define SCLK_CRYPTO48 +#define SCLK_CRYPTO_APK49 +#define SCLK_DDRC 50 +#define SCLK_ISP 51 +#define SCLK_CIF_OUT 52 +#define SCLK_RGA_CORE 53 +#define SCLK_VOPB_PWM 54 +#define SCLK_NANDC 55 +#define SCLK_SDIO 56 +#define SCLK_EMMC 57 +#define SCLK_SFC 58 +#define SCLK_SDMMC 59 +#define SCLK_OTG_ADP 60 +#define SCLK_GMAC_SRC 61 +#define SCLK_GMAC 62 +#define SCLK_GMAC_RX_TX63 +#define SCLK_MAC_REF 64 +#define SCLK_MAC_REFOUT65 +#define SCLK_MAC_OUT 66 +#define SCLK_SDMMC_DRV 67 +#define SCLK_SDMMC_SAMPLE 68 +#define SCLK_SDIO_DRV 69 +#define SCLK_SDIO_SAMPLE 70 +#define SCLK_EMMC_DRV 71 +#define SCLK_EMMC_SAMPLE 72 +#define SCLK_GPU 73 +#define SCLK_PVTM 74 +#define SCLK_CORE_VPU 75 +#define SCLK_GMAC_RMII 76 +#define SCLK_UART2_SRC 77 +#define SCLK_NANDC_DIV 78 +#define SCLK_NANDC_DIV50 79 +#define SCLK_SDIO_DIV 80 +#define SCLK_SDIO_DIV5081 +#define SCLK_EMMC_DIV 82 +#define SCLK_EMMC_DIV5083 +#define SCLK_DDRCLK84 +#define SCLK_UART1_SRC 85 + +/* dclk gates */ +#define DCLK_VOPB 150 +#define DCLK_VOPL 151 + +/* aclk gates */ +#define ACLK_GPU 170 +#define ACLK_BUS_PRE 171 +#define ACLK_CRYPTO172 +#define ACLK_VI_PRE173 +#define ACLK_VO_PRE174 +#define ACLK_VPU 175 +#define ACLK_PERI_PRE 176 +#define ACLK_GMAC 178 +#define ACLK_CIF 179 +#define ACLK_ISP 180 +#define ACLK_VOPB 181 +#define ACLK_VOPL 182 +#define ACLK_RGA 183 +#define ACLK_GIC 184 +#define ACLK_DCF 186 +#define ACLK_DMAC 187 +#define ACLK_BUS_SRC 188 +#define ACLK_PERI_SRC 189 + +/* hclk gates */ +#define HCLK_BUS_PRE 240 +#define HCLK_CRYPTO241 +#define HCLK_VI_PR
[PATCH v2 0/4] clk: rockchip: support clock controller for px30 SoC
Change in V2: [PATCH v2 2/4]: modify the Author name [PATCH v2 3/4]: provide a bit more explanation for commit message Elaine Zhang (4): dt-bindings: add bindings for px30 clock controller clk: rockchip: add dt-binding header for px30 clk: rockchip: add support for half divider clk: rockchip: add clock controller for px30 .../bindings/clock/rockchip,px30-cru.txt | 67 ++ drivers/clk/rockchip/Makefile |2 + drivers/clk/rockchip/clk-half-divider.c| 235 + drivers/clk/rockchip/clk-px30.c| 1080 drivers/clk/rockchip/clk.c | 10 + drivers/clk/rockchip/clk.h | 86 +- include/dt-bindings/clock/px30-cru.h | 402 7 files changed, 1881 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/clock/rockchip,px30-cru.txt create mode 100644 drivers/clk/rockchip/clk-half-divider.c create mode 100644 drivers/clk/rockchip/clk-px30.c create mode 100644 include/dt-bindings/clock/px30-cru.h -- 1.9.1
[PATCH v2 1/4] dt-bindings: add bindings for px30 clock controller
Add devicetree bindings for Rockchip cru which found on
Rockchip SoCs.
Signed-off-by: Elaine Zhang
---
.../bindings/clock/rockchip,px30-cru.txt | 67 ++
1 file changed, 67 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/rockchip,px30-cru.txt
diff --git a/Documentation/devicetree/bindings/clock/rockchip,px30-cru.txt
b/Documentation/devicetree/bindings/clock/rockchip,px30-cru.txt
new file mode 100644
index ..af5a45b680d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rockchip,px30-cru.txt
@@ -0,0 +1,67 @@
+* Rockchip PX30 Clock and Reset Unit
+
+The PX30 clock controller generates and supplies clock to various
+controllers within the SoC and also implements a reset controller for SoC
+peripherals.
+
+Required Properties:
+
+- compatible: PMU for CRU should be "rockchip,px30-pmu-cru"
+- compatible: CRU should be "rockchip,px30-cru"
+- reg: physical base address of the controller and length of memory mapped
+ region.
+- #clock-cells: should be 1.
+- #reset-cells: should be 1.
+
+Optional Properties:
+
+- rockchip,grf: phandle to the syscon managing the "general register files"
+ If missing, pll rates are not changeable, due to the missing pll lock status.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. All available clocks are defined as
+preprocessor macros in the dt-bindings/clock/px30-cru.h headers and can be
+used in device tree sources. Similar macros exist for the reset sources in
+these files.
+
+External clocks:
+
+There are several clocks that are generated outside the SoC. It is expected
+that they are defined using standard clock bindings with following
+clock-output-names:
+ - "xin24m" - crystal input - required,
+ - "xin32k" - rtc clock - optional,
+ - "i2sx_clkin" - external I2S clock - optional,
+ - "gmac_clkin" - external GMAC clock - optional
+
+Example: Clock controller node:
+
+ pmucru: pmu-clock-controller@ff2bc000 {
+ compatible = "rockchip,px30-pmucru";
+ reg = <0x0 0xff2bc000 0x0 0x1000>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ cru: clock-controller@ff2b {
+ compatible = "rockchip,px30-cru";
+ reg = <0x0 0xff2b 0x0 0x1000>;
+ rockchip,grf = <&grf>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+Example: UART controller node that consumes the clock generated by the clock
+ controller:
+
+ uart0: serial@ff03 {
+ compatible = "rockchip,px30-uart", "snps,dw-apb-uart";
+ reg = <0x0 0xff03 0x0 0x100>;
+ interrupts = ;
+ clocks = <&pmucru SCLK_UART0_PMU>, <&pmucru PCLK_UART0_PMU>;
+ clock-names = "baudclk", "apb_pclk";
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
--
1.9.1
[PATCH v2 4/4] clk: rockchip: add clock controller for px30
Add the clock tree definition for the new px30 SoC.
Signed-off-by: Elaine Zhang
---
drivers/clk/rockchip/Makefile |1 +
drivers/clk/rockchip/clk-px30.c | 1080 +++
drivers/clk/rockchip/clk.h | 41 +-
3 files changed, 1121 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/rockchip/clk-px30.c
diff --git a/drivers/clk/rockchip/Makefile b/drivers/clk/rockchip/Makefile
index 023f83ad3429..82ab6f515179 100644
--- a/drivers/clk/rockchip/Makefile
+++ b/drivers/clk/rockchip/Makefile
@@ -14,6 +14,7 @@ obj-y += clk-muxgrf.o
obj-y += clk-ddr.o
obj-$(CONFIG_RESET_CONTROLLER) += softrst.o
+obj-y += clk-px30.o
obj-y += clk-rv1108.o
obj-y += clk-rk3036.o
obj-y += clk-rk3128.o
diff --git a/drivers/clk/rockchip/clk-px30.c b/drivers/clk/rockchip/clk-px30.c
new file mode 100644
index ..07105fe1ff6c
--- /dev/null
+++ b/drivers/clk/rockchip/clk-px30.c
@@ -0,0 +1,1080 @@
+/*
+ * Copyright (c) 2016 Rockchip Electronics Co. Ltd.
+ * Author: Elaine
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "clk.h"
+
+#define PX30_GRF_SOC_STATUS0 0x480
+
+enum px30_plls {
+ apll, dpll, cpll, npll, apll_b_h, apll_b_l,
+};
+
+enum px30_pmu_plls {
+ gpll,
+};
+
+static struct rockchip_pll_rate_table px30_pll_rates[] = {
+ /* _mhz, _refdiv, _fbdiv, _postdiv1, _postdiv2, _dsmpd, _frac */
+ RK3036_PLL_RATE(160800, 1, 67, 1, 1, 1, 0),
+ RK3036_PLL_RATE(158400, 1, 66, 1, 1, 1, 0),
+ RK3036_PLL_RATE(156000, 1, 65, 1, 1, 1, 0),
+ RK3036_PLL_RATE(153600, 1, 64, 1, 1, 1, 0),
+ RK3036_PLL_RATE(151200, 1, 63, 1, 1, 1, 0),
+ RK3036_PLL_RATE(148800, 1, 62, 1, 1, 1, 0),
+ RK3036_PLL_RATE(146400, 1, 61, 1, 1, 1, 0),
+ RK3036_PLL_RATE(144000, 1, 60, 1, 1, 1, 0),
+ RK3036_PLL_RATE(141600, 1, 59, 1, 1, 1, 0),
+ RK3036_PLL_RATE(139200, 1, 58, 1, 1, 1, 0),
+ RK3036_PLL_RATE(136800, 1, 57, 1, 1, 1, 0),
+ RK3036_PLL_RATE(134400, 1, 56, 1, 1, 1, 0),
+ RK3036_PLL_RATE(132000, 1, 55, 1, 1, 1, 0),
+ RK3036_PLL_RATE(129600, 1, 54, 1, 1, 1, 0),
+ RK3036_PLL_RATE(127200, 1, 53, 1, 1, 1, 0),
+ RK3036_PLL_RATE(124800, 1, 52, 1, 1, 1, 0),
+ RK3036_PLL_RATE(12, 1, 50, 1, 1, 1, 0),
+ RK3036_PLL_RATE(118800, 2, 99, 1, 1, 1, 0),
+ RK3036_PLL_RATE(110400, 1, 46, 1, 1, 1, 0),
+ RK3036_PLL_RATE(11, 12, 550, 1, 1, 1, 0),
+ RK3036_PLL_RATE(100800, 1, 84, 2, 1, 1, 0),
+ RK3036_PLL_RATE(10, 6, 500, 2, 1, 1, 0),
+ RK3036_PLL_RATE(98400, 1, 82, 2, 1, 1, 0),
+ RK3036_PLL_RATE(96000, 1, 80, 2, 1, 1, 0),
+ RK3036_PLL_RATE(93600, 1, 78, 2, 1, 1, 0),
+ RK3036_PLL_RATE(91200, 1, 76, 2, 1, 1, 0),
+ RK3036_PLL_RATE(9, 4, 300, 2, 1, 1, 0),
+ RK3036_PLL_RATE(88800, 1, 74, 2, 1, 1, 0),
+ RK3036_PLL_RATE(86400, 1, 72, 2, 1, 1, 0),
+ RK3036_PLL_RATE(84000, 1, 70, 2, 1, 1, 0),
+ RK3036_PLL_RATE(81600, 1, 68, 2, 1, 1, 0),
+ RK3036_PLL_RATE(8, 6, 400, 2, 1, 1, 0),
+ RK3036_PLL_RATE(7, 6, 350, 2, 1, 1, 0),
+ RK3036_PLL_RATE(69600, 1, 58, 2, 1, 1, 0),
+ RK3036_PLL_RATE(62400, 1, 52, 2, 1, 1, 0),
+ RK3036_PLL_RATE(6, 1, 75, 3, 1, 1, 0),
+ RK3036_PLL_RATE(59400, 2, 99, 2, 1, 1, 0),
+ RK3036_PLL_RATE(50400, 1, 63, 3, 1, 1, 0),
+ RK3036_PLL_RATE(5, 6, 250, 2, 1, 1, 0),
+ RK3036_PLL_RATE(40800, 1, 68, 2, 2, 1, 0),
+ RK3036_PLL_RATE(31200, 1, 52, 2, 2, 1, 0),
+ RK3036_PLL_RATE(21600, 1, 72, 4, 2, 1, 0),
+ RK3036_PLL_RATE(9600, 1, 64, 4, 4, 1, 0),
+ { /* sentinel */ },
+};
+
+#define PX30_DIV_ACLKM_MASK0x7
+#define PX30_DIV_ACLKM_SHIFT 12
+#define PX30_DIV_PCLK_DBG_MASK 0xf
+#define PX30_DIV_PCLK_DBG_SHIFT8
+
+#define PX30_CLKSEL0(_aclk_core, _pclk_dbg)\
+{ \
+ .reg = PX30_CLKSEL_CON(0), \
+ .val = HIWORD_UPDATE(_aclk_core, PX30_DIV_ACLKM_MASK, \
+PX30_DIV_ACLKM_SHIFT) |\
+ HIWORD_UPDATE(_pclk_dbg, PX30_DIV_PCLK_DBG_MASK, \
+PX30_DIV_PCLK_DBG_
[PATCH v2 3/4] clk: rockchip: add support for half divider
The new Rockchip socs have optional half divider:
The formula is shown as:
freq_out = 2*freq_in / (2*div + 3)
Is this the same for all of new SoCs.
So we use "branch_half_divider" + "COMPOSITE_NOMUX_HALFDIV \ DIV_HALF"
to hook that special divider clock-type into our clock-tree.
Signed-off-by: Elaine Zhang
---
drivers/clk/rockchip/Makefile | 1 +
drivers/clk/rockchip/clk-half-divider.c | 235
drivers/clk/rockchip/clk.c | 10 ++
drivers/clk/rockchip/clk.h | 45 ++
4 files changed, 291 insertions(+)
create mode 100644 drivers/clk/rockchip/clk-half-divider.c
diff --git a/drivers/clk/rockchip/Makefile b/drivers/clk/rockchip/Makefile
index 59b8d320960a..023f83ad3429 100644
--- a/drivers/clk/rockchip/Makefile
+++ b/drivers/clk/rockchip/Makefile
@@ -7,6 +7,7 @@ obj-y += clk-rockchip.o
obj-y += clk.o
obj-y += clk-pll.o
obj-y += clk-cpu.o
+obj-y += clk-half-divider.o
obj-y += clk-inverter.o
obj-y += clk-mmc-phase.o
obj-y += clk-muxgrf.o
diff --git a/drivers/clk/rockchip/clk-half-divider.c
b/drivers/clk/rockchip/clk-half-divider.c
new file mode 100644
index ..23830de254ec
--- /dev/null
+++ b/drivers/clk/rockchip/clk-half-divider.c
@@ -0,0 +1,235 @@
+/*
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "clk.h"
+
+#define div_mask(width)((1 << (width)) - 1)
+
+static bool _is_best_half_div(unsigned long rate, unsigned long now,
+ unsigned long best, unsigned long flags)
+{
+ if (flags & CLK_DIVIDER_ROUND_CLOSEST)
+ return abs(rate - now) < abs(rate - best);
+
+ return now <= rate && now > best;
+}
+
+static unsigned long clk_half_divider_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct clk_divider *divider = to_clk_divider(hw);
+ unsigned int val;
+
+ val = clk_readl(divider->reg) >> divider->shift;
+ val &= div_mask(divider->width);
+ val = val * 2 + 3;
+
+ return DIV_ROUND_UP_ULL((u64)(parent_rate * 2), val);
+}
+
+static int clk_half_divider_bestdiv(struct clk_hw *hw, unsigned long rate,
+ unsigned long *best_parent_rate, u8 width,
+ unsigned long flags)
+{
+ int i, bestdiv = 0;
+ unsigned long parent_rate, best = 0, now, maxdiv;
+ unsigned long parent_rate_saved = *best_parent_rate;
+
+ if (!rate)
+ rate = 1;
+
+ maxdiv = div_mask(width);
+
+ if (!(clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT)) {
+ parent_rate = *best_parent_rate;
+ bestdiv = DIV_ROUND_UP_ULL((u64)(parent_rate * 2), rate);
+ if (bestdiv < 3)
+ bestdiv = 0;
+ else
+ bestdiv = (bestdiv - 3) / 2;
+ bestdiv = bestdiv > maxdiv ? maxdiv : bestdiv;
+ return bestdiv;
+ }
+
+ /*
+* The maximum divider we can use without overflowing
+* unsigned long in rate * i below
+*/
+ maxdiv = min(ULONG_MAX / rate, maxdiv);
+
+ for (i = 0; i <= maxdiv; i++) {
+ if ((rate * (i * 2 + 3)) == (parent_rate_saved * 2)) {
+ /*
+* It's the most ideal case if the requested rate can be
+* divided from parent clock without needing to change
+* parent rate, so return the divider immediately.
+*/
+ *best_parent_rate = parent_rate_saved;
+ return i;
+ }
+ parent_rate = clk_hw_round_rate(clk_hw_get_parent(hw),
+ (rate * (i * 2 + 3)) / 2);
+ now = DIV_ROUND_UP_ULL((u64)(parent_rate * 2), (i * 2 + 3));
+ if (_is_best_half_div(rate, now, best, flags)) {
+ bestdiv = i;
+ best = now;
+ *best_parent_rate = parent_rate;
+ }
+ }
+
+ if (!bestdiv) {
+ bestdiv = div_mask(width);
+ *best_parent_rate = clk_hw_round_rate(clk_hw_get_parent(hw), 1);
+ }
+
+ return bestdiv;
+}
+
+static long clk_half_divider_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *prate)
+{
+ struct clk_divider
Re: [PATCH][next] pinctrl: pinctrl-single: add allocation failure checking of saved_vals
* Johan Hovold [180607 07:32]: > On Wed, Jun 06, 2018 at 02:43:38PM +0100, Colin King wrote: > > But for this fix, feel free to add: > > Reviewed-by: Johan Hovold Acked-by: Tony Lindgren
Re: [PATCH v3 4/6] bus: ti-sysc: Add support for software reset
* Faiz Abbas [180607 10:24]:
> Hi,
>
> On Thursday 07 June 2018 01:05 PM, Tony Lindgren wrote:
> > * Faiz Abbas [180606 06:14]:
> >> +static int sysc_reset(struct sysc *ddata)
> >> +{
> >> + int offset = ddata->offsets[SYSC_SYSCONFIG];
> >> + int val = sysc_read(ddata, offset);
> >> +
> >> + val |= (0x1 << ddata->cap->regbits->srst_shift);
> >> + sysc_write(ddata, offset, val);
> >> +
> >> + /* Poll on reset status */
> >> + if (ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS) {
> >> + offset = ddata->offsets[SYSC_SYSSTATUS];
> >> +
> >> + return readl_poll_timeout(ddata->module_va + offset, val,
> >> + (val & ddata->cfg.syss_mask) == 0x0,
> >> + 100, MAX_MODULE_SOFTRESET_WAIT);
> >> + }
> >> +
> >> + return 0;
> >> +}
> >
> > I wonder if we should also add SYSS_QUIRK_RESET_STATUS in
> > addition to SYSC_QUIRK_RESET status to make it easy to
> > read the right register?
>
> I assumed SYSC_QUIRK is the prefix to indicate the ti-sysc driver not
> the register. Are there layouts in which the reset status bit is in the
> sysconfig register rather than the sysstatus register?
Yes we can have reset status bit in either syss or syssconfig register.
We detect that in sysc_init_syss_mask() but we should also set something
at that point to make it clear which reset to use. But as we don't need
the quirk flag, it's probably set a function pointer after the detection.
So how about let's have two functions sysc_reset() and sysc_syss_reset()
and then we can implement sysc_syss_reset() in a separate patch after
testing it when we have a non-platform data using example for
sysc_syss_reset().
Regards,
Tony
[PATCH] phy: phy-brcm-usb-init: Fix power down USB 3.0 PHY when XHCI reenabled
Unset is required to enable USB 3.0 PHY when XHCI reenabled in response
to setting PHY3_IDDQ_OVERRIDE in uninit().
Fixes: cd6f769fdea7 ("phy: phy-brcm-usb-init: Power down USB 3.0 PHY when XHCI
disabled")
Signed-off-by: Jaedon Shin
---
drivers/phy/broadcom/phy-brcm-usb-init.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/phy/broadcom/phy-brcm-usb-init.c
b/drivers/phy/broadcom/phy-brcm-usb-init.c
index 1b7febc43da9..29d2c3b1913a 100644
--- a/drivers/phy/broadcom/phy-brcm-usb-init.c
+++ b/drivers/phy/broadcom/phy-brcm-usb-init.c
@@ -962,6 +962,10 @@ void brcm_usb_init_xhci(struct brcm_usb_init_params
*params)
{
void __iomem *ctrl = params->ctrl_regs;
+ USB_CTRL_UNSET(ctrl, USB30_PCTL, PHY3_IDDQ_OVERRIDE);
+ /* 1 millisecond - for USB clocks to settle down */
+ usleep_range(1000, 2000);
+
if (BRCM_ID(params->family_id) == 0x7366) {
/*
* The PHY3_SOFT_RESETB bits default to the wrong state.
--
2.17.1
Re: [LINUX PATCH v9 1/4] Devicetree: Add pl353 smc controller devicetree binding information
On Fri, 8 Jun 2018 05:20:33 +
Naga Sureshkumar Relli wrote:
> Hi Miquel,
>
> Thanks for the review.
>
> > -Original Message-
> > From: Miquel Raynal [mailto:miquel.ray...@bootlin.com]
> > Sent: Thursday, June 7, 2018 9:12 PM
> > To: Naga Sureshkumar Relli
> > Cc: boris.brezil...@bootlin.com; rich...@nod.at; w...@infradead.org;
> > computersforpe...@gmail.com; marek.va...@gmail.com; f.faine...@gmail.com;
> > mma...@broadcom.com; rog...@ti.com; la...@linux-mips.org; a...@thorsis.com;
> > honghui.zh...@mediatek.com; linux-...@lists.infradead.org;
> > linux-kernel@vger.kernel.org;
> > nagasureshkumarre...@gmail.com
> > Subject: Re: [LINUX PATCH v9 1/4] Devicetree: Add pl353 smc controller
> > devicetree
> > binding information
> >
> > Hi Naga,
> >
> > On Wed, 6 Jun 2018 13:19:39 +0530, Naga Sureshkumar Relli
> > wrote:
> >
> > > Add pl353 static memory controller devicetree binding information.
> > >
> > > Signed-off-by: Naga Sureshkumar Relli
> > >
> > > ---
> > > Changes in v9:
> > > - Addressed commens given by Randy Dunlap and Miquel Raynal
> >
> > Can you please be more specific in your next changelog? I don't remember
> > what I suggested a
> > few months ago :)
> Ok, I will update.
>
> >
> > > Changes in v8:
> > > - None
> > > Changes in v7:
> > > - Corrected clocks description
> > > - prefixed '#' for address and size cells Changes in v6:
> > > - None
> > > Changes in v5:
> > > - Removed timing properties
> > > Changes in v4:
> > > - none
> > > Changes in v3:
> > > - none
> > > Changes in v2:
> > > - modified timing binding info as per onfi timing parameters
> > > - add suffix nano second as timing unit
> > > - modified the clock names as per the IP spec
> > > ---
> > > .../bindings/memory-controllers/pl353-smc.txt | 53
> > ++
> > > 1 file changed, 53 insertions(+)
> > > create mode 100644
> > > Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
> > > b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
> > > new file mode 100644
> > > index 000..551e66b
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.t
> > > +++ xt
> > > @@ -0,0 +1,53 @@
> > > +Device tree bindings for ARM PL353 static memory controller
> > > +
> > > +PL353 static memory controller supports two kinds of memory
> > > +interfaces.i.e NAND and SRAM/NOR interfaces.
> > > +The actual devices are instantiated from the child nodes of pl353 smc
> > > node.
> > > +
> > > +Required properties:
> > > +- compatible : Should be "arm,pl353-smc-r2p1"
> >
> > I thing Rob prefers:
> >
> > - compatible: Must be one of:
> > * arm, pl353-smc-r2p1
> Are you suggesting any other compatibles?
> Or just a change from "should be to Must be one of"?
> >
> > > +- reg: Controller registers map and length.
> > > +- clock-names: List of input clock names - "ref_clk",
> > > "aper_clk"
> > > + (See clock bindings for details).
> > > +- clocks : Clock phandles (see clock bindings for details).
> > > +- address-cells : Address cells, must be 1.
> > > +- size-cells : Size cells. Must be 1.
> >
> > Please avoid padding, just this is enough:
> >
> > - something: And another thing.
> Ok, I will update it.
>
> >
> > > +
> > > +Child nodes:
> > > + For NAND the "arm,pl353-nand-r2p1" and for NOR the "cfi-flash"
> > > +drivers are supported as child nodes.
> > > +
> > > +Mandatory timing properties for child nodes:
> > > +- arm,nand-cycle-t0 : Read cycle time(t_rc).
> > > +- arm,nand-cycle-t1 : Write cycle time(t_wc).
> > > +- arm,nand-cycle-t2 : re_n assertion delay(t_rea).
> > > +- arm,nand-cycle-t3 : we_n de-assertion delay(t_wp).
> > > +- arm,nand-cycle-t4 : Status read time(t_clr)
> > > +- arm,nand-cycle-t5 : ID read time(t_ar)
> > > +- arm,nand-cycle-t6 : busy to re_n(t_rr)
> >
> > I think this has nothing to do in the DT, you should handle timings from
> > the -
> > >setup_data_interface() hook. If you need, you may use different
> > >compatibles to distinguish
> > different platform data.
> >
> This controller is applicable only to Zynq platform. No other platform will
> use this.
> Basically pl353-smc.c and pl353-nand.c, both are different drivers.
> And this data_interface hook is in nand, and to set this timings if we read
> it from setup_data_interface(), then
> We need to make call from nand to smc driver.
> Let me try this.
>
> > > +
> > > +for nand partition information please refer the below file
> >
> > s/nand/NAND/
> I will update in next version.
>
> >
> > > +Documentation/devicetree/bindings/mtd/partition.txt
> > > +
> > > +Example:
> > > + pl353smcc_0: pl353smcc@e000e000 {
> >
> > Why not something more explicit with the '-flash-
[PATCH v2 2/5] Revert "dmaengine: imx-sdma: fix pagefault when channel is disabled during interrupt"
This reverts commit 2746e2c389f9d50043d21e2204270403efb9d62f.
Don't need this patch anymore,since we can easily check 'sdmac->desc' to avoid
handling dma interrupt after channel disabled if virt-dma used.
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 21 -
1 file changed, 21 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 8d0c1fd..d93b58f 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -354,7 +354,6 @@ struct sdma_channel {
unsigned intchn_count;
unsigned intchn_real_count;
struct imx_dma_data data;
- boolenabled;
};
#define IMX_DMA_SG_LOOPBIT(0)
@@ -615,14 +614,7 @@ static int sdma_config_ownership(struct sdma_channel
*sdmac,
static void sdma_enable_channel(struct sdma_engine *sdma, int channel)
{
- unsigned long flags;
- struct sdma_channel *sdmac = &sdma->channel[channel];
-
writel(BIT(channel), sdma->regs + SDMA_H_START);
-
- spin_lock_irqsave(&sdmac->lock, flags);
- sdmac->enabled = true;
- spin_unlock_irqrestore(&sdmac->lock, flags);
}
/*
@@ -740,14 +732,6 @@ static void sdma_update_channel_loop(struct sdma_channel
*sdmac)
struct sdma_buffer_descriptor *bd;
int error = 0;
enum dma_status old_status = sdmac->status;
- unsigned long flags;
-
- spin_lock_irqsave(&sdmac->lock, flags);
- if (!sdmac->enabled) {
- spin_unlock_irqrestore(&sdmac->lock, flags);
- return;
- }
- spin_unlock_irqrestore(&sdmac->lock, flags);
/*
* loop mode. Iterate over descriptors, re-setup them and
@@ -1008,15 +992,10 @@ static int sdma_disable_channel(struct dma_chan *chan)
struct sdma_channel *sdmac = to_sdma_chan(chan);
struct sdma_engine *sdma = sdmac->sdma;
int channel = sdmac->channel;
- unsigned long flags;
writel_relaxed(BIT(channel), sdma->regs + SDMA_H_STATSTOP);
sdmac->status = DMA_ERROR;
- spin_lock_irqsave(&sdmac->lock, flags);
- sdmac->enabled = false;
- spin_unlock_irqrestore(&sdmac->lock, flags);
-
return 0;
}
--
2.7.4
[PATCH v2 3/5] dmaengine: imx-sdma: remove usless lock
No need anymore for 'lock' now since virtual dma will provide
the common lock instead.
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index d93b58f..6faec89 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -349,7 +349,6 @@ struct sdma_channel {
unsigned long event_mask[2];
unsigned long watermark_level;
u32 shp_addr, per_addr;
- spinlock_t lock;
enum dma_status status;
unsigned intchn_count;
unsigned intchn_real_count;
@@ -1908,7 +1907,6 @@ static int sdma_probe(struct platform_device *pdev)
struct sdma_channel *sdmac = &sdma->channel[i];
sdmac->sdma = sdma;
- spin_lock_init(&sdmac->lock);
sdmac->channel = i;
sdmac->vc.desc_free = sdma_desc_free;
--
2.7.4
[PATCH v2 5/5] dmaengine: imx-sdma: add sdma_transfer_init to decrease code overlap
There are lot of codes overlap between prep_sg and prep_cyclic function.
Add sdma_transfer_init() function to elimated the code overlap.
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 83 ++
1 file changed, 37 insertions(+), 46 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index afaee72..25de89e 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1255,6 +1255,40 @@ static void sdma_free_chan_resources(struct dma_chan
*chan)
clk_disable(sdma->clk_ahb);
}
+static struct sdma_desc *sdma_transfer_init(struct sdma_channel *sdmac,
+ enum dma_transfer_direction direction, u32 bds)
+{
+ struct sdma_desc *desc;
+
+ desc = kzalloc((sizeof(*desc)), GFP_KERNEL);
+ if (!desc)
+ goto err_out;
+
+ sdmac->status = DMA_IN_PROGRESS;
+ sdmac->direction = direction;
+ sdmac->flags = 0;
+
+ desc->chn_count = 0;
+ desc->chn_real_count = 0;
+ desc->buf_tail = 0;
+ desc->buf_ptail = 0;
+ desc->sdmac = sdmac;
+ desc->num_bd = bds;
+
+ if (sdma_alloc_bd(desc))
+ goto err_desc_out;
+
+ if (sdma_load_context(sdmac))
+ goto err_desc_out;
+
+ return desc;
+
+err_desc_out:
+ kfree(desc);
+err_out:
+ return NULL;
+}
+
static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
struct dma_chan *chan, struct scatterlist *sgl,
unsigned int sg_len, enum dma_transfer_direction direction,
@@ -1267,36 +1301,13 @@ static struct dma_async_tx_descriptor
*sdma_prep_slave_sg(
struct scatterlist *sg;
struct sdma_desc *desc;
- if (sdmac->status == DMA_IN_PROGRESS)
- return NULL;
- sdmac->status = DMA_IN_PROGRESS;
-
- sdmac->flags = 0;
-
- desc = kzalloc((sizeof(*desc)), GFP_KERNEL);
+ desc = sdma_transfer_init(sdmac, direction, sg_len);
if (!desc)
goto err_out;
- desc->buf_tail = 0;
- desc->buf_ptail = 0;
- desc->sdmac = sdmac;
- desc->num_bd = sg_len;
- desc->chn_real_count = 0;
-
- if (sdma_alloc_bd(desc)) {
- kfree(desc);
- goto err_out;
- }
-
dev_dbg(sdma->dev, "setting up %d entries for channel %d.\n",
sg_len, channel);
- sdmac->direction = direction;
- ret = sdma_load_context(sdmac);
- if (ret)
- goto err_bd_out;
-
- desc->chn_count = 0;
for_each_sg(sgl, sg, sg_len, i) {
struct sdma_buffer_descriptor *bd = &desc->bd[i];
int param;
@@ -1372,38 +1383,18 @@ static struct dma_async_tx_descriptor
*sdma_prep_dma_cyclic(
struct sdma_engine *sdma = sdmac->sdma;
int num_periods = buf_len / period_len;
int channel = sdmac->channel;
- int ret, i = 0, buf = 0;
+ int i = 0, buf = 0;
struct sdma_desc *desc;
dev_dbg(sdma->dev, "%s channel: %d\n", __func__, channel);
- if (sdmac->status == DMA_IN_PROGRESS)
- return NULL;
- sdmac->status = DMA_IN_PROGRESS;
-
- desc = kzalloc((sizeof(*desc)), GFP_KERNEL);
+ desc = sdma_transfer_init(sdmac, direction, num_periods);
if (!desc)
goto err_out;
-
- desc->buf_tail = 0;
- desc->buf_ptail = 0;
- desc->sdmac = sdmac;
- desc->num_bd = num_periods;
- desc->chn_real_count = 0;
desc->period_len = period_len;
sdmac->flags |= IMX_DMA_SG_LOOP;
- sdmac->direction = direction;
-
- if (sdma_alloc_bd(desc)) {
- kfree(desc);
- goto err_out;
- }
-
- ret = sdma_load_context(sdmac);
- if (ret)
- goto err_bd_out;
if (period_len > 0x) {
dev_err(sdma->dev, "SDMA channel %d: maximum period size
exceeded: %zu > %d\n",
--
2.7.4
[PATCH v2 1/5] dmaengine: imx-sdma: add virt-dma support
The legacy sdma driver has below limitations or drawbacks:
1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and alloc
one page size for one channel regardless of only few BDs needed
most time. But in few cases, the max PAGE_SIZE maybe not enough.
2. One SDMA channel can't stop immediatley once channel disabled which
means SDMA interrupt may come in after this channel terminated.There
are some patches for this corner case such as commit "2746e2c389f9",
but not cover non-cyclic.
The common virt-dma overcomes the above limitations. It can alloc bd
dynamically and free bd once this tx transfer done. No memory wasted or
maximum limititation here, only depends on how many memory can be requested
from kernel. For No.2, such issue can be workaround by checking if there
is available descript("sdmac->desc") now once the unwanted interrupt
coming. At last the common virt-dma is easier for sdma driver maintain.
The main changes as below:
--new "sdma_desc" structure containing virt_dma_desc and some members
which moved from "sdma_channel" such as "num_bd","bd_phys","bd",etc,
since multi descriptors may exist on virtual dma framework
rather than only one as before.
--remove some members of "sdma_channel" structure since it's handled
by virtual dma common framework, such as "tasklet", "dma_chan",etc.
--add specific BD0 for channel0 since such bd descriptor is must and
basic for other dma channel, no need alloc/free as other channel,so
request it during probe.
--remove sdma_request_channel(),sdma_tx_submit(),etc.
--alloc/free bd descriptor added and code changes for virtual dma.
Signed-off-by: Robin Gong
---
drivers/dma/Kconfig| 1 +
drivers/dma/imx-sdma.c | 332 -
2 files changed, 220 insertions(+), 113 deletions(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index ca1680a..d4a4230 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -250,6 +250,7 @@ config IMX_SDMA
tristate "i.MX SDMA support"
depends on ARCH_MXC
select DMA_ENGINE
+ select DMA_VIRTUAL_CHANNELS
help
Support the i.MX SDMA engine. This engine is integrated into
Freescale i.MX25/31/35/51/53/6 chips.
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index ccd03c3..8d0c1fd 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -48,6 +48,7 @@
#include
#include "dmaengine.h"
+#include "virt-dma.h"
/* SDMA registers */
#define SDMA_H_C0PTR 0x000
@@ -296,6 +297,31 @@ struct sdma_context_data {
struct sdma_engine;
/**
+ * struct sdma_desc - descriptor structor for one transfer
+ * @vd descriptor for virt dma
+ * @num_bd max NUM_BD. number of descriptors currently handling
+ * @buf_tail ID of the buffer that was processed
+ * @buf_ptail ID of the previous buffer that was processed
+ * @period_len period length, used in cyclic.
+ * @chn_real_count the real count updated from bd->mode.count
+ * @chn_count the transfer count setuped
+ * @sdmac sdma_channel pointer
+ * @bd pointer of alloced bd
+ */
+struct sdma_desc {
+ struct virt_dma_descvd;
+ unsigned intnum_bd;
+ dma_addr_t bd_phys;
+ unsigned intbuf_tail;
+ unsigned intbuf_ptail;
+ unsigned intperiod_len;
+ unsigned intchn_real_count;
+ unsigned intchn_count;
+ struct sdma_channel *sdmac;
+ struct sdma_buffer_descriptor *bd;
+};
+
+/**
* struct sdma_channel - housekeeping for a SDMA channel
*
* @sdma pointer to the SDMA engine for this channel
@@ -305,11 +331,10 @@ struct sdma_engine;
* @event_id0 aka dma request line
* @event_id1 for channels that use 2 events
* @word_size peripheral access size
- * @buf_tail ID of the buffer that was processed
- * @buf_ptail ID of the previous buffer that was processed
- * @num_bd max NUM_BD. number of descriptors currently handling
*/
struct sdma_channel {
+ struct virt_dma_chanvc;
+ struct sdma_desc*desc;
struct sdma_engine *sdma;
unsigned intchannel;
enum dma_transfer_direction direction;
@@ -317,12 +342,6 @@ struct sdma_channel {
unsigned intevent_id0;
unsigned intevent_id1;
enum dma_slave_buswidth word_size;
- unsigned intbuf_tail;
- unsigned intbuf_ptail;
- unsigned intnum_bd;
- unsigned intperiod_len;
- struct sdma_buffer_descriptor *bd;
- dma_addr_t bd_phys;
unsign
[PATCH v2 0/5] add virt-dma support for imx-sdma
The legacy sdma driver has below limitations or drawbacks:
1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and alloc
one page size for one channel regardless of only few BDs needed
most time. But in few cases, the max PAGE_SIZE maybe not enough.
2. One SDMA channel can't stop immediatley once channel disabled which
means SDMA interrupt may come in after this channel terminated.There
are some patches for this corner case such as commit "2746e2c389f9",
but not cover non-cyclic.
The common virt-dma overcomes the above limitations. It can alloc bd
dynamically and free bd once this tx transfer done. No memory wasted or
maximum limititation here, only depends on how many memory can be requested
from kernel. For No.2, such issue can be workaround by checking if there
is available descript("sdmac->desc") now once the unwanted interrupt
coming. At last the common virt-dma is easier for sdma driver maintain.
Change from v1:
1. split v1 patch into 5 patches.
2. remove some unnecessary condition check.
3. remove unneccessary 'pending' list.
Robin Gong (5):
dmaengine: imx-sdma: add virt-dma support
Revert "dmaengine: imx-sdma: fix pagefault when channel is disabled
during interrupt"
dmaengine: imx-sdma: remove usless lock
dmaengine: imx-sdma: remove the maximum limation for bd numbers
dmaengine: imx-sdma: add sdma_transfer_init to decrease code overlap
drivers/dma/Kconfig| 1 +
drivers/dma/imx-sdma.c | 392 -
2 files changed, 227 insertions(+), 166 deletions(-)
--
2.7.4
[PATCH v2 4/5] dmaengine: imx-sdma: remove the maximum limation for bd numbers
No this limitation now after virtual dma used since bd is allocated
dynamically instead of static.
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 6faec89..afaee72 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -292,7 +292,6 @@ struct sdma_context_data {
u32 scratch7;
} __attribute__ ((packed));
-#define NUM_BD (int)(PAGE_SIZE / sizeof(struct sdma_buffer_descriptor))
struct sdma_engine;
@@ -1297,13 +1296,6 @@ static struct dma_async_tx_descriptor
*sdma_prep_slave_sg(
if (ret)
goto err_bd_out;
- if (sg_len > NUM_BD) {
- dev_err(sdma->dev, "SDMA channel %d: maximum number of sg
exceeded: %d > %d\n",
- channel, sg_len, NUM_BD);
- ret = -EINVAL;
- goto err_bd_out;
- }
-
desc->chn_count = 0;
for_each_sg(sgl, sg, sg_len, i) {
struct sdma_buffer_descriptor *bd = &desc->bd[i];
@@ -1413,12 +1405,6 @@ static struct dma_async_tx_descriptor
*sdma_prep_dma_cyclic(
if (ret)
goto err_bd_out;
- if (num_periods > NUM_BD) {
- dev_err(sdma->dev, "SDMA channel %d: maximum number of sg
exceeded: %d > %d\n",
- channel, num_periods, NUM_BD);
- goto err_bd_out;
- }
-
if (period_len > 0x) {
dev_err(sdma->dev, "SDMA channel %d: maximum period size
exceeded: %zu > %d\n",
channel, period_len, 0x);
--
2.7.4
[git pull] vfs.git fix proc_fill_cache() regression
Regression fix for proc_fill_cache() braino introduced when switching instantiate() callback to d_splice_alias(). [with apologies for being MIA for several days - flu started on Sunday and got really nasty on Tuesday; back to normal now, hopefully] The following changes since commit 888e2b03ef56694290e58bd9ac23f8033bf6369f: switch the rest of procfs lookups to d_splice_alias() (2018-05-26 14:20:50 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.lookup for you to fetch changes up to d85b399b64e85a311c09205c675d4ae1c5af6246: fix proc_fill_cache() in case of d_alloc_parallel() failure (2018-06-08 01:17:11 -0400) Al Viro (1): fix proc_fill_cache() in case of d_alloc_parallel() failure fs/proc/base.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
[git pull] vfs.git - aio ioprio
The rest of aio stuff for this cycle - Adam's aio ioprio series The following changes since commit 1da92779e2e8f309d5aecbbed346e7f812b174e8: aio: sanitize the limit checking in io_submit(2) (2018-05-29 23:20:17 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.aio for you to fetch changes up to 9a6d9a62e0fd4b9927c3124db0f25fc6b4fb6576: fs: aio ioprio use ioprio_check_cap ret val (2018-06-04 14:20:39 -0400) Adam Manzanares (7): block: add ioprio_check_cap function fs: Convert kiocb rw_hint from enum to u16 fs: Add aio iopriority support fs: blkdev set bio prio from kiocb prio fs: iomap dio set bio prio from kiocb prio fs: aio ioprio add explicit block layer dependence fs: aio ioprio use ioprio_check_cap ret val block/ioprio.c | 22 -- drivers/block/loop.c | 3 +++ fs/aio.c | 18 +- fs/block_dev.c | 2 ++ fs/iomap.c | 1 + include/linux/fs.h | 16 ++-- include/linux/ioprio.h | 9 + include/uapi/linux/aio_abi.h | 1 + 8 files changed, 63 insertions(+), 9 deletions(-)
linux-next: Tree for Jun 8
Hi all, News: There will be no linux-next release on Monday. Note: please do *not* add any v4.19 material to your linux-next included branches until after v4.18-rc1 has been released. Changes since 20180607: Non-merge commits (relative to Linus' tree): 4298 4027 files changed, 122295 insertions(+), 272707 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 278 trees (counting Linus' and 64 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (289cf155d95d Merge tag 'devicetree-for-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux) Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild) Merging kbuild-current/fixes (b04e217704b7 Linux 4.17-rc7) Merging arc-current/for-curr (661e50bc8532 Linux 4.16-rc4) Merging arm-current/fixes (92d44a42af81 ARM: fix kill( ,SIGFPE) breakage) Merging arm64-fixes/for-next/fixes (82034c23fcbc arm64: Make sure permission updates happen for pmd/pud) Merging m68k-current/for-linus (b12c8a70643f m68k: Set default dma mask for platform devices) Merging powerpc-fixes/fixes (faf37c44a105 powerpc/64s: Clear PCR on boot) Merging sparc/master (1c1ff29da6c8 sparc: fix compat siginfo ABI regression) CONFLICT (content): Merge conflict in arch/sparc/kernel/traps_64.c CONFLICT (content): Merge conflict in arch/sparc/kernel/traps_32.c Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (8d97ca6b6755 bpfilter: fix OUTPUT_FORMAT) Merging bpf/master (58990d1ff3f7 bpf: reject passing modified ctx to helper functions) Merging ipsec/master (1c8c5a9d38f6 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next) Merging netfilter/master (64e6dd1fb2f1 netfilter: nf_conntrack: Increase __IPS_MAX_BIT with new bit IPS_OFFLOAD_BIT) Merging ipvs/master (312564269535 net: netsec: reduce DMA mask to 40 bits) Merging wireless-drivers/master (ab1068d6866e iwlwifi: pcie: compare with number of IRQs requested for, not number of CPUs) Merging mac80211/master (885892fb378d mlx4_core: restore optimal ICM memory allocation) Merging rdma-fixes/for-rc (a840c93ca758 IB/core: Fix error code for invalid GID entry) Merging sound-current/for-linus (d4d5a1cd298e Merge tag 'asoc-v4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus) Merging sound-asoc-fixes/for-linus (2858e2cfc2ef Merge branch 'asoc-4.17' into asoc-linus) Merging regmap-fixes/for-linus (97fe106a8027 Merge branch 'regmap-4.17' into regmap-linus) Merging regulator-fixes/for-linus (59ce5f3e5530 Merge branch 'regulator-4.17' into regulator-linus) Merging spi-fixes/for-linus (5d3257b8ea48 Merge branch 'spi-4.17' into spi-linus) Merging pci-current/for-linus (0cf22d6b317c PCI: Add "PCIe" to pcie_print_link_status() messages) Merging driver-core.current/driver-core-linus (1c8c5a9d38f6 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next) Merging tty.current/tty-linus (af6c5d5e01ad Merge branch 'for-4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq) Merging usb.current/usb-linus (af6c5d5e01ad Merge branch 'for-4.18' of git://git.ker
[PATCH] tee: optee: making OPTEE_SHM_NUM_PRIV_PAGES configurable via Kconfig
This change adds KCONFIG option to set number of pages out of whole shared memory to be used for OP-TEE driver private data structures. Signed-off-by: Sahil Malhotra --- drivers/tee/optee/Kconfig | 8 drivers/tee/optee/core.c | 2 +- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig index 524c7a80fde4..f425c960a5a2 100644 --- a/drivers/tee/optee/Kconfig +++ b/drivers/tee/optee/Kconfig @@ -12,3 +12,11 @@ config OPTEE_BENCHMARK help This enables benchmarking feature in the OP-TEE Trusted Execution Environment (TEE) driver. + +config OPTEE_SHM_NUM_PRIV_PAGES + int "Private Shared Memory Pages" + default 1 + depends on OPTEE + help + This sets the number of private shared memory pages to be + used by OP-TEE TEE driver. diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c index 4a2c420d4fe4..8d3be6b1bb96 100644 --- a/drivers/tee/optee/core.c +++ b/drivers/tee/optee/core.c @@ -33,7 +33,7 @@ #define DRIVER_NAME "optee" -#define OPTEE_SHM_NUM_PRIV_PAGES 1 +#define OPTEE_SHM_NUM_PRIV_PAGES CONFIG_OPTEE_SHM_NUM_PRIV_PAGES /** * optee_from_msg_param() - convert from OPTEE_MSG parameters to -- 2.17.0
RE: [LINUX PATCH v9 1/4] Devicetree: Add pl353 smc controller devicetree binding information
Hi Miquel,
Thanks for the review.
> -Original Message-
> From: Miquel Raynal [mailto:miquel.ray...@bootlin.com]
> Sent: Thursday, June 7, 2018 9:12 PM
> To: Naga Sureshkumar Relli
> Cc: boris.brezil...@bootlin.com; rich...@nod.at; w...@infradead.org;
> computersforpe...@gmail.com; marek.va...@gmail.com; f.faine...@gmail.com;
> mma...@broadcom.com; rog...@ti.com; la...@linux-mips.org; a...@thorsis.com;
> honghui.zh...@mediatek.com; linux-...@lists.infradead.org;
> linux-kernel@vger.kernel.org;
> nagasureshkumarre...@gmail.com
> Subject: Re: [LINUX PATCH v9 1/4] Devicetree: Add pl353 smc controller
> devicetree
> binding information
>
> Hi Naga,
>
> On Wed, 6 Jun 2018 13:19:39 +0530, Naga Sureshkumar Relli
> wrote:
>
> > Add pl353 static memory controller devicetree binding information.
> >
> > Signed-off-by: Naga Sureshkumar Relli
> >
> > ---
> > Changes in v9:
> > - Addressed commens given by Randy Dunlap and Miquel Raynal
>
> Can you please be more specific in your next changelog? I don't remember what
> I suggested a
> few months ago :)
Ok, I will update.
>
> > Changes in v8:
> > - None
> > Changes in v7:
> > - Corrected clocks description
> > - prefixed '#' for address and size cells Changes in v6:
> > - None
> > Changes in v5:
> > - Removed timing properties
> > Changes in v4:
> > - none
> > Changes in v3:
> > - none
> > Changes in v2:
> > - modified timing binding info as per onfi timing parameters
> > - add suffix nano second as timing unit
> > - modified the clock names as per the IP spec
> > ---
> > .../bindings/memory-controllers/pl353-smc.txt | 53
> ++
> > 1 file changed, 53 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
> > b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt
> > new file mode 100644
> > index 000..551e66b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.t
> > +++ xt
> > @@ -0,0 +1,53 @@
> > +Device tree bindings for ARM PL353 static memory controller
> > +
> > +PL353 static memory controller supports two kinds of memory
> > +interfaces.i.e NAND and SRAM/NOR interfaces.
> > +The actual devices are instantiated from the child nodes of pl353 smc node.
> > +
> > +Required properties:
> > +- compatible : Should be "arm,pl353-smc-r2p1"
>
> I thing Rob prefers:
>
> - compatible: Must be one of:
> * arm, pl353-smc-r2p1
Are you suggesting any other compatibles?
Or just a change from "should be to Must be one of"?
>
> > +- reg : Controller registers map and length.
> > +- clock-names : List of input clock names - "ref_clk",
> > "aper_clk"
> > + (See clock bindings for details).
> > +- clocks : Clock phandles (see clock bindings for details).
> > +- address-cells: Address cells, must be 1.
> > +- size-cells : Size cells. Must be 1.
>
> Please avoid padding, just this is enough:
>
> - something: And another thing.
Ok, I will update it.
>
> > +
> > +Child nodes:
> > + For NAND the "arm,pl353-nand-r2p1" and for NOR the "cfi-flash"
> > +drivers are supported as child nodes.
> > +
> > +Mandatory timing properties for child nodes:
> > +- arm,nand-cycle-t0: Read cycle time(t_rc).
> > +- arm,nand-cycle-t1: Write cycle time(t_wc).
> > +- arm,nand-cycle-t2: re_n assertion delay(t_rea).
> > +- arm,nand-cycle-t3: we_n de-assertion delay(t_wp).
> > +- arm,nand-cycle-t4: Status read time(t_clr)
> > +- arm,nand-cycle-t5: ID read time(t_ar)
> > +- arm,nand-cycle-t6: busy to re_n(t_rr)
>
> I think this has nothing to do in the DT, you should handle timings from the -
> >setup_data_interface() hook. If you need, you may use different compatibles
> >to distinguish
> different platform data.
>
This controller is applicable only to Zynq platform. No other platform will use
this.
Basically pl353-smc.c and pl353-nand.c, both are different drivers.
And this data_interface hook is in nand, and to set this timings if we read it
from setup_data_interface(), then
We need to make call from nand to smc driver.
Let me try this.
> > +
> > +for nand partition information please refer the below file
>
> s/nand/NAND/
I will update in next version.
>
> > +Documentation/devicetree/bindings/mtd/partition.txt
> > +
> > +Example:
> > + pl353smcc_0: pl353smcc@e000e000 {
>
> Why not something more explicit with the '-flash-controller' suffix?
Is this ok?
smcc: memory-controller@e000e000 {}
>
> > + compatible = "arm,pl353-smc-r2p1"
> > + clock-names = "memclk", "aclk";
> > + clocks = <&clkc 11>, <&clkc 44>;
> > + reg = <0xe000e000 0x1000>;
> > + #address-cells = <1>;
> > + #s
Re: 4.17-ad1: -march=native support or Kernel Ricers wanted
Hi Alexey, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.17] [cannot apply to tip/x86/core next-20180607] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Alexey-Dobriyan/4-17-ad1-march-native-support-or-Kernel-Ricers-wanted/20180605-090623 config: x86_64-kexec (attached as .config) compiler: gcc-7 (Debian 7.3.0-16) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): make[3]: execvp: scripts/march-native.sh: Permission denied make[3]: *** [syncconfig] Error 127 make[2]: *** [syncconfig] Error 2 >> make[1]: *** No rule to make target 'include/config/auto.conf', needed by >> 'include/config/kernel.release'. make[1]: Target 'prepare' not remade because of errors. make: *** [sub-make] Error 2 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH NEXT 6/6] PCI/PORTDRV: Remove ERR_FATAL handling from pcie_portdrv_slot_reset()
On 2018-06-08 03:04, Bjorn Helgaas wrote:
On Thu, Jun 07, 2018 at 07:18:03PM +0530, p...@codeaurora.org wrote:
On 2018-06-07 11:30, Oza Pawandeep wrote:
> We are handling ERR_FATAL by resetting the Link in software,skipping the
> driver pci_error_handlers callbacks, removing the devices from the PCI
> subsystem, and re-enumerating, as a result of that, no more calling
> pcie_portdrv_slot_reset in ERR_FATAL case.
>
> Signed-off-by: Oza Pawandeep
>
> diff --git a/drivers/pci/pcie/portdrv_pci.c
> b/drivers/pci/pcie/portdrv_pci.c
> index 973f1b8..92f5d330 100644
> --- a/drivers/pci/pcie/portdrv_pci.c
> +++ b/drivers/pci/pcie/portdrv_pci.c
> @@ -42,17 +42,6 @@ __setup("pcie_ports=", pcie_port_setup);
>
> /* global data */
>
> -static int pcie_portdrv_restore_config(struct pci_dev *dev)
> -{
> - int retval;
> -
> - retval = pci_enable_device(dev);
> - if (retval)
> - return retval;
> - pci_set_master(dev);
> - return 0;
> -}
> -
> #ifdef CONFIG_PM
> static int pcie_port_runtime_suspend(struct device *dev)
> {
> @@ -162,14 +151,6 @@ static pci_ers_result_t
> pcie_portdrv_mmio_enabled(struct pci_dev *dev)
>
> static pci_ers_result_t pcie_portdrv_slot_reset(struct pci_dev *dev)
> {
> - /* If fatal, restore cfg space for possible link reset at upstream */
> - if (dev->error_state == pci_channel_io_frozen) {
> - dev->state_saved = true;
> - pci_restore_state(dev);
> - pcie_portdrv_restore_config(dev);
> - pci_enable_pcie_error_reporting(dev);
> - }
> -
>return PCI_ERS_RESULT_RECOVERED;
> }
Hi Bjorn,
the above patch removes ERR_FATAL handling from
pcie_portdrv_slot_reset()
because now we are handling ERR_FATAL differently than before.
I tried to dig into pcie_portdrv_slot_reset() handling for ERR_FATAL
case
where it
restores the config space, enable device, set master and enable error
reporting
and as far as I understand this is being done for upstream link
(bridges
etc..)
why was it done at the first point (I checked the commit description,
but
could not really get it)
and do we need to handle the same thing in ERR_FATAL now ?
You mean 4bf3392e0bf5 ("PCI-Express AER implemetation: pcie_portdrv
error handler"), which added pcie_portdrv_slot_reset()? I agree, that
commit log has no useful information. I don't know any of the history
behind it.
Yes Bjorn thats right.
I am trying to understand it but no clue.
since it is restoring the stuffs in ERR_FATAL case, why would PCIe
bridge loose all the settings ? [config space, aer bits, master, device
enable etc..)
Max we do is link_reset in ERR_FATAL case, and Secondary bus reset
should affect downstream components (not upstream)
Re: [PATCH V5] powercap/drivers/idle_injection: Add an idle injection framework
On 07-06-18, 16:11, Daniel Lezcano wrote: > >> I'm wondering if we can have a CPU hotplugged right after the > >> 'put_online_cpus', resulting in the 'should park' flag set and then the > >> thread goes in the kthread_parkme instead of jumping back the idle > >> injection function and decrease the count, leading up to the timer not > >> being set again. > > > > True. That looks like a valid problem to me as well. > > > > What about starting the hrtimer right from this routine itself, after taking > > into account running-time, idle-time, delay, etc ? That would get rid of the > > count stuff, this get_online_cpus(), etc. > > > > Even if we restart the next play-idle cycle a bit early or with some delay, > > sky > > wouldn't fall :) > > We won't be able to call completion() in this case. I was just having a look at smpboot.h and saw the park/unpark callbacks. I think you can very much use them to align things with CPU hotplug. -- viresh
Re: [PATCH NEXT 6/6] PCI/PORTDRV: Remove ERR_FATAL handling from pcie_portdrv_slot_reset()
On 2018-06-08 03:04, Bjorn Helgaas wrote:
On Thu, Jun 07, 2018 at 07:18:03PM +0530, p...@codeaurora.org wrote:
On 2018-06-07 11:30, Oza Pawandeep wrote:
> We are handling ERR_FATAL by resetting the Link in software,skipping the
> driver pci_error_handlers callbacks, removing the devices from the PCI
> subsystem, and re-enumerating, as a result of that, no more calling
> pcie_portdrv_slot_reset in ERR_FATAL case.
>
> Signed-off-by: Oza Pawandeep
>
> diff --git a/drivers/pci/pcie/portdrv_pci.c
> b/drivers/pci/pcie/portdrv_pci.c
> index 973f1b8..92f5d330 100644
> --- a/drivers/pci/pcie/portdrv_pci.c
> +++ b/drivers/pci/pcie/portdrv_pci.c
> @@ -42,17 +42,6 @@ __setup("pcie_ports=", pcie_port_setup);
>
> /* global data */
>
> -static int pcie_portdrv_restore_config(struct pci_dev *dev)
> -{
> - int retval;
> -
> - retval = pci_enable_device(dev);
> - if (retval)
> - return retval;
> - pci_set_master(dev);
> - return 0;
> -}
> -
> #ifdef CONFIG_PM
> static int pcie_port_runtime_suspend(struct device *dev)
> {
> @@ -162,14 +151,6 @@ static pci_ers_result_t
> pcie_portdrv_mmio_enabled(struct pci_dev *dev)
>
> static pci_ers_result_t pcie_portdrv_slot_reset(struct pci_dev *dev)
> {
> - /* If fatal, restore cfg space for possible link reset at upstream */
> - if (dev->error_state == pci_channel_io_frozen) {
> - dev->state_saved = true;
> - pci_restore_state(dev);
> - pcie_portdrv_restore_config(dev);
> - pci_enable_pcie_error_reporting(dev);
> - }
> -
>return PCI_ERS_RESULT_RECOVERED;
> }
Hi Bjorn,
the above patch removes ERR_FATAL handling from
pcie_portdrv_slot_reset()
because now we are handling ERR_FATAL differently than before.
I tried to dig into pcie_portdrv_slot_reset() handling for ERR_FATAL
case
where it
restores the config space, enable device, set master and enable error
reporting
and as far as I understand this is being done for upstream link
(bridges
etc..)
why was it done at the first point (I checked the commit description,
but
could not really get it)
and do we need to handle the same thing in ERR_FATAL now ?
You mean 4bf3392e0bf5 ("PCI-Express AER implemetation: pcie_portdrv
error handler"), which added pcie_portdrv_slot_reset()? I agree, that
commit log has no useful information. I don't know any of the history
behind it.
Keith,
do you know why in ERR_FATAL case following was done ?
have a look at pcie_portdrv_slot_reset() handling (for bridges, switches
etc..)
Regards,
Oza.
linux-next: build warning after merge of the akpm-current tree
Hi Andrew,
After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
In file included from fs/fat/inode.c:24:0:
fs/fat/inode.c: In function '__fat_get_block':
fs/fat/inode.c:163:9: warning: format '%ld' expects argument of type 'long
int', but argument 5 has type 'sector_t {aka long long unsigned int}'
[-Wformat=]
"invalid FAT chain (i_pos %lld, last_block %ld)",
^
fs/fat/fat.h:397:24: note: in definition of macro 'fat_fs_error'
__fat_fs_error(sb, 1, fmt , ## args)
^~~
Introduced by commit
3bdac70a1921 ("fat: use fat_fs_error() instead of BUG_ON() in
__fat_get_block()")
--
Cheers,
Stephen Rothwell
pgpZZNY9AlJz2.pgp
Description: OpenPGP digital signature
Re: [PATCH] cpufreq: kryo: Add module remove and exit
On 07-06-18, 20:58, ilia@gmail.com wrote:
> From: Ilia Lin
>
> Add device remove and module exit code to make the driver
> functioning as a loadable module.
>
> Fixes: ac28927659be (cpufreq: kryo: allow building as a loadable module)
> Signed-off-by: Ilia Lin
> ---
> drivers/cpufreq/qcom-cpufreq-kryo.c | 24 +---
> 1 file changed, 21 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/cpufreq/qcom-cpufreq-kryo.c
> b/drivers/cpufreq/qcom-cpufreq-kryo.c
> index d049fe4b80c4..a08de0253169 100644
> --- a/drivers/cpufreq/qcom-cpufreq-kryo.c
> +++ b/drivers/cpufreq/qcom-cpufreq-kryo.c
> @@ -71,10 +71,10 @@ static enum _msm8996_version __init
> qcom_cpufreq_kryo_get_msm_id(void)
> return version;
> }
>
> +struct platform_device *cpufreq_dt_pdev;
Move this and the other platform device pointer at the top of the file after the
enum declarations. They don't look nice in the middle of nowhere.
> static int qcom_cpufreq_kryo_probe(struct platform_device *pdev)
> {
> struct opp_table *opp_tables[NR_CPUS] = {0};
> - struct platform_device *cpufreq_dt_pdev;
> enum _msm8996_version msm8996_version;
> struct nvmem_cell *speedbin_nvmem;
> struct device_node *np;
> @@ -115,6 +115,8 @@ static int qcom_cpufreq_kryo_probe(struct platform_device
> *pdev)
>
> speedbin = nvmem_cell_read(speedbin_nvmem, &len);
> nvmem_cell_put(speedbin_nvmem);
> + if (IS_ERR(speedbin))
> + return PTR_ERR(speedbin);
This doesn't look related to this patch. Should it be a different commit ?
And I just saw definition of nvmem_cell_read() and it says the returned buffer
must be freed by caller using kfree(). I dont' see you doing that. Please also
check if any other such resources are there which you forgot to free.
>
> switch (msm8996_version) {
> case MSM8996_V3:
> @@ -162,8 +164,15 @@ static int qcom_cpufreq_kryo_probe(struct
> platform_device *pdev)
> return ret;
> }
>
> +static int qcom_cpufreq_kryo_remove(struct platform_device *pdev)
> +{
> + platform_device_unregister(cpufreq_dt_pdev);
> + return 0;
> +}
> +
> static struct platform_driver qcom_cpufreq_kryo_driver = {
> .probe = qcom_cpufreq_kryo_probe,
> + .remove = qcom_cpufreq_kryo_remove,
> .driver = {
> .name = "qcom-cpufreq-kryo",
> },
> @@ -174,6 +183,7 @@ static const struct of_device_id
> qcom_cpufreq_kryo_match_list[] __initconst = {
> { .compatible = "qcom,msm8996", },
> };
>
> +struct platform_device *kryo_cpufreq_pdev;
> /*
> * Since the driver depends on smem and nvmem drivers, which may
> * return EPROBE_DEFER, all the real activity is done in the probe,
> @@ -198,8 +208,9 @@ static int __init qcom_cpufreq_kryo_init(void)
> if (unlikely(ret < 0))
> return ret;
>
> - ret = PTR_ERR_OR_ZERO(platform_device_register_simple(
> - "qcom-cpufreq-kryo", -1, NULL, 0));
> + kryo_cpufreq_pdev = platform_device_register_simple(
> + "qcom-cpufreq-kryo", -1, NULL, 0);
> + ret = PTR_ERR_OR_ZERO(kryo_cpufreq_pdev);
> if (0 == ret)
> return 0;
>
> @@ -208,5 +219,12 @@ static int __init qcom_cpufreq_kryo_init(void)
> }
> module_init(qcom_cpufreq_kryo_init);
>
> +static void __init qcom_cpufreq_kryo_exit(void)
> +{
> + platform_device_unregister(kryo_cpufreq_pdev);
> + platform_driver_unregister(&qcom_cpufreq_kryo_driver);
> +}
> +module_exit(qcom_cpufreq_kryo_exit);
> +
> MODULE_DESCRIPTION("Qualcomm Technologies, Inc. Kryo CPUfreq driver");
> MODULE_LICENSE("GPL v2");
--
viresh
Re: [PATCH 6/6] Convert intel uncore to struct_size
Hi Matthew,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.17 next-20180607]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Matthew-Wilcox/More-conversions-to-struct_size/20180608-112654
config: x86_64-randconfig-x016-201822 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
arch/x86/events/intel/uncore.c: In function 'uncore_type_init':
>> arch/x86/events/intel/uncore.c:838:24: error: implicit declaration of
>> function 'struct_size' [-Werror=implicit-function-declaration]
attr_group = kzalloc(struct_size(attr_group, attrs, i + 1),
^~~
arch/x86/events/intel/uncore.c:838:48: error: 'attrs' undeclared (first use
in this function); did you mean 'iattr'?
attr_group = kzalloc(struct_size(attr_group, attrs, i + 1),
^
iattr
arch/x86/events/intel/uncore.c:838:48: note: each undeclared identifier is
reported only once for each function it appears in
cc1: some warnings being treated as errors
vim +/struct_size +838 arch/x86/events/intel/uncore.c
804
805 static int __init uncore_type_init(struct intel_uncore_type *type, bool
setid)
806 {
807 struct intel_uncore_pmu *pmus;
808 size_t size;
809 int i, j;
810
811 pmus = kzalloc(sizeof(*pmus) * type->num_boxes, GFP_KERNEL);
812 if (!pmus)
813 return -ENOMEM;
814
815 size = max_packages * sizeof(struct intel_uncore_box *);
816
817 for (i = 0; i < type->num_boxes; i++) {
818 pmus[i].func_id = setid ? i : -1;
819 pmus[i].pmu_idx = i;
820 pmus[i].type= type;
821 pmus[i].boxes = kzalloc(size, GFP_KERNEL);
822 if (!pmus[i].boxes)
823 goto err;
824 }
825
826 type->pmus = pmus;
827 type->unconstrainted = (struct event_constraint)
828 __EVENT_CONSTRAINT(0, (1ULL << type->num_counters) - 1,
829 0, type->num_counters, 0, 0);
830
831 if (type->event_descs) {
832 struct {
833 struct attribute_group group;
834 struct attribute *attrs[];
835 } *attr_group;
836 for (i = 0; type->event_descs[i].attr.attr.name; i++);
837
> 838 attr_group = kzalloc(struct_size(attr_group, attrs, i +
> 1),
839
GFP_KERNEL);
840 if (!attr_group)
841 goto err;
842
843 attr_group->group.name = "events";
844 attr_group->group.attrs = attr_group->attrs;
845
846 for (j = 0; j < i; j++)
847 attr_group->attrs[j] =
&type->event_descs[j].attr.attr;
848
849 type->events_group = &attr_group->group;
850 }
851
852 type->pmu_group = &uncore_pmu_attr_group;
853
854 return 0;
855
856 err:
857 for (i = 0; i < type->num_boxes; i++)
858 kfree(pmus[i].boxes);
859 kfree(pmus);
860
861 return -ENOMEM;
862 }
863
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH][v2] sched: cpufreq: Fix long idle judgement logic in load calculation
On 08-06-18, 09:07, Chen Yu wrote: > According to current code implementation, detecting the long > idle period is done by checking if the interval between two > adjacent utilization update handers is long enough. Although > this mechanism can detect if the idle period is long enough > (no utilization hooks invoked during idle period), it might > not contain a corner case: if the task has occupied the cpu > for too long which causes no context switch during that > period, then no utilization handler will be launched until this > high prio task is switched out. As a result, the idle_periods > field might be calculated incorrectly because it regards the > 100% load as 0% and makes the conservative governor who uses > this field confusing. > > Change the judgement to compare the idle_time with sampling_rate > directly. > > Reported-by: Artem S. Tashkinov > Cc: Artem S Tashkinov > Cc: "Rafael J. Wysocki" > Cc: Viresh Kumar > Cc: linux...@vger.kernel.org > Signed-off-by: Chen Yu > --- > v2: Per Viresh's suggestion, ignore idle_time longer than 30mins and > simplify the code. > --- > drivers/cpufreq/cpufreq_governor.c | 12 +--- > 1 file changed, 5 insertions(+), 7 deletions(-) Acked-by: Viresh Kumar -- viresh
Re: [PATCH 3/6] Convert v4l2 event to struct_size
Hi Matthew,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.17 next-20180607]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Matthew-Wilcox/More-conversions-to-struct_size/20180608-112654
config: x86_64-randconfig-x017-201822 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/media/v4l2-core/v4l2-event.c: In function 'v4l2_event_subscribe':
>> drivers/media/v4l2-core/v4l2-event.c:218:17: error: implicit declaration of
>> function 'struct_size'; did you mean 'resource_size'?
>> [-Werror=implicit-function-declaration]
sev = kvzalloc(struct_size(sev, events, elems), GFP_KERNEL);
^~~
resource_size
drivers/media/v4l2-core/v4l2-event.c:218:34: error: 'events' undeclared
(first use in this function); did you mean 'elems'?
sev = kvzalloc(struct_size(sev, events, elems), GFP_KERNEL);
^~
elems
drivers/media/v4l2-core/v4l2-event.c:218:34: note: each undeclared
identifier is reported only once for each function it appears in
cc1: some warnings being treated as errors
vim +218 drivers/media/v4l2-core/v4l2-event.c
203
204 int v4l2_event_subscribe(struct v4l2_fh *fh,
205 const struct v4l2_event_subscription *sub,
unsigned elems,
206 const struct v4l2_subscribed_event_ops *ops)
207 {
208 struct v4l2_subscribed_event *sev, *found_ev;
209 unsigned long flags;
210 unsigned i;
211
212 if (sub->type == V4L2_EVENT_ALL)
213 return -EINVAL;
214
215 if (elems < 1)
216 elems = 1;
217
> 218 sev = kvzalloc(struct_size(sev, events, elems), GFP_KERNEL);
219 if (!sev)
220 return -ENOMEM;
221 for (i = 0; i < elems; i++)
222 sev->events[i].sev = sev;
223 sev->type = sub->type;
224 sev->id = sub->id;
225 sev->flags = sub->flags;
226 sev->fh = fh;
227 sev->ops = ops;
228
229 spin_lock_irqsave(&fh->vdev->fh_lock, flags);
230 found_ev = v4l2_event_subscribed(fh, sub->type, sub->id);
231 if (!found_ev)
232 list_add(&sev->list, &fh->subscribed);
233 spin_unlock_irqrestore(&fh->vdev->fh_lock, flags);
234
235 if (found_ev) {
236 kvfree(sev);
237 return 0; /* Already listening */
238 }
239
240 if (sev->ops && sev->ops->add) {
241 int ret = sev->ops->add(sev, elems);
242 if (ret) {
243 sev->ops = NULL;
244 v4l2_event_unsubscribe(fh, sub);
245 return ret;
246 }
247 }
248
249 /* Mark as ready for use */
250 sev->elems = elems;
251
252 return 0;
253 }
254 EXPORT_SYMBOL_GPL(v4l2_event_subscribe);
255
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH 6/6] Convert intel uncore to struct_size
Hi Matthew,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.17 next-20180607]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Matthew-Wilcox/More-conversions-to-struct_size/20180608-112654
config: x86_64-randconfig-x015-201822 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
arch/x86/events/intel/uncore.c: In function 'uncore_type_init':
>> arch/x86/events/intel/uncore.c:838:24: error: implicit declaration of
>> function 'struct_size'; did you mean 'bd_set_size'?
>> [-Werror=implicit-function-declaration]
attr_group = kzalloc(struct_size(attr_group, attrs, i + 1),
^~~
bd_set_size
>> arch/x86/events/intel/uncore.c:838:48: error: 'attrs' undeclared (first use
>> in this function); did you mean 'iattr'?
attr_group = kzalloc(struct_size(attr_group, attrs, i + 1),
^
iattr
arch/x86/events/intel/uncore.c:838:48: note: each undeclared identifier is
reported only once for each function it appears in
cc1: some warnings being treated as errors
vim +838 arch/x86/events/intel/uncore.c
804
805 static int __init uncore_type_init(struct intel_uncore_type *type, bool
setid)
806 {
807 struct intel_uncore_pmu *pmus;
808 size_t size;
809 int i, j;
810
811 pmus = kzalloc(sizeof(*pmus) * type->num_boxes, GFP_KERNEL);
812 if (!pmus)
813 return -ENOMEM;
814
815 size = max_packages * sizeof(struct intel_uncore_box *);
816
817 for (i = 0; i < type->num_boxes; i++) {
818 pmus[i].func_id = setid ? i : -1;
819 pmus[i].pmu_idx = i;
820 pmus[i].type= type;
821 pmus[i].boxes = kzalloc(size, GFP_KERNEL);
822 if (!pmus[i].boxes)
823 goto err;
824 }
825
826 type->pmus = pmus;
827 type->unconstrainted = (struct event_constraint)
828 __EVENT_CONSTRAINT(0, (1ULL << type->num_counters) - 1,
829 0, type->num_counters, 0, 0);
830
831 if (type->event_descs) {
832 struct {
833 struct attribute_group group;
834 struct attribute *attrs[];
835 } *attr_group;
836 for (i = 0; type->event_descs[i].attr.attr.name; i++);
837
> 838 attr_group = kzalloc(struct_size(attr_group, attrs, i +
> 1),
839
GFP_KERNEL);
840 if (!attr_group)
841 goto err;
842
843 attr_group->group.name = "events";
844 attr_group->group.attrs = attr_group->attrs;
845
846 for (j = 0; j < i; j++)
847 attr_group->attrs[j] =
&type->event_descs[j].attr.attr;
848
849 type->events_group = &attr_group->group;
850 }
851
852 type->pmu_group = &uncore_pmu_attr_group;
853
854 return 0;
855
856 err:
857 for (i = 0; i < type->num_boxes; i++)
858 kfree(pmus[i].boxes);
859 kfree(pmus);
860
861 return -ENOMEM;
862 }
863
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
linux-next: build warning after merge of the random tree
Hi Theodore,
After merging the random tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
lib/vsprintf.c:1668:13: warning: 'have_filled_random_ptr_key' defined but not
used [-Wunused-variable]
static bool have_filled_random_ptr_key __read_mostly;
^~
Introduced by commit
bfe80ed3d7c7 ("vsprintf: add command line option debug_boot_weak_hash")
--
Cheers,
Stephen Rothwell
pgpS1IXSQVb8z.pgp
Description: OpenPGP digital signature
Proposal
-- Good day, i know you do not know me personally but i have checked your profile and i see generosity in you, There's an urgent offer attach to your name here in the office of Mr. Fawaz KhE. Al Saleh Member of the Board of Directors, Kuveyt Türk Participation Bank (Turkey) and head of private banking and wealth management Regards, Mr. Fawaz KhE. Al Saleh
[PATCH v2 09/12] macintosh/via-pmu: Replace via-pmu68k driver with via-pmu driver
Now that the PowerMac via-pmu driver supports m68k PowerBooks,
switch over to that driver and remove the via-pmu68k driver.
Cc: Geert Uytterhoeven
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
arch/m68k/configs/mac_defconfig | 2 +-
arch/m68k/configs/multi_defconfig | 2 +-
arch/m68k/mac/config.c| 2 +-
arch/m68k/mac/misc.c | 48 +--
drivers/macintosh/Kconfig | 13 +-
drivers/macintosh/Makefile| 1 -
drivers/macintosh/adb.c | 2 +-
drivers/macintosh/via-pmu68k.c| 846 --
include/uapi/linux/pmu.h | 1 -
9 files changed, 13 insertions(+), 904 deletions(-)
delete mode 100644 drivers/macintosh/via-pmu68k.c
diff --git a/arch/m68k/configs/mac_defconfig b/arch/m68k/configs/mac_defconfig
index 390d4a87441c..ee63f1242e9a 100644
--- a/arch/m68k/configs/mac_defconfig
+++ b/arch/m68k/configs/mac_defconfig
@@ -370,7 +370,7 @@ CONFIG_TCM_PSCSI=m
CONFIG_ADB=y
CONFIG_ADB_MACII=y
CONFIG_ADB_IOP=y
-CONFIG_ADB_PMU68K=y
+CONFIG_ADB_PMU=y
CONFIG_ADB_CUDA=y
CONFIG_INPUT_ADBHID=y
CONFIG_MAC_EMUMOUSEBTN=y
diff --git a/arch/m68k/configs/multi_defconfig
b/arch/m68k/configs/multi_defconfig
index 77be97d82dc3..6421a3da616c 100644
--- a/arch/m68k/configs/multi_defconfig
+++ b/arch/m68k/configs/multi_defconfig
@@ -403,7 +403,7 @@ CONFIG_TCM_PSCSI=m
CONFIG_ADB=y
CONFIG_ADB_MACII=y
CONFIG_ADB_IOP=y
-CONFIG_ADB_PMU68K=y
+CONFIG_ADB_PMU=y
CONFIG_ADB_CUDA=y
CONFIG_INPUT_ADBHID=y
CONFIG_MAC_EMUMOUSEBTN=y
diff --git a/arch/m68k/mac/config.c b/arch/m68k/mac/config.c
index e522307db47c..92e80cf0d8aa 100644
--- a/arch/m68k/mac/config.c
+++ b/arch/m68k/mac/config.c
@@ -891,7 +891,7 @@ static void __init mac_identify(void)
#ifdef CONFIG_ADB_CUDA
find_via_cuda();
#endif
-#ifdef CONFIG_ADB_PMU68K
+#ifdef CONFIG_ADB_PMU
find_via_pmu();
#endif
}
diff --git a/arch/m68k/mac/misc.c b/arch/m68k/mac/misc.c
index 7ccb799eeb57..28090a44fa09 100644
--- a/arch/m68k/mac/misc.c
+++ b/arch/m68k/mac/misc.c
@@ -85,7 +85,7 @@ static void cuda_write_pram(int offset, __u8 data)
}
#endif /* CONFIG_ADB_CUDA */
-#ifdef CONFIG_ADB_PMU68K
+#ifdef CONFIG_ADB_PMU
static long pmu_read_time(void)
{
struct adb_request req;
@@ -136,7 +136,7 @@ static void pmu_write_pram(int offset, __u8 data)
while (!req.complete)
pmu_poll();
}
-#endif /* CONFIG_ADB_PMU68K */
+#endif /* CONFIG_ADB_PMU */
/*
* VIA PRAM/RTC access routines
@@ -367,38 +367,6 @@ static void cuda_shutdown(void)
}
#endif /* CONFIG_ADB_CUDA */
-#ifdef CONFIG_ADB_PMU68K
-
-void pmu_restart(void)
-{
- struct adb_request req;
- if (pmu_request(&req, NULL,
- 2, PMU_SET_INTR_MASK, PMU_INT_ADB|PMU_INT_TICK) < 0)
- return;
- while (!req.complete)
- pmu_poll();
- if (pmu_request(&req, NULL, 1, PMU_RESET) < 0)
- return;
- while (!req.complete)
- pmu_poll();
-}
-
-void pmu_shutdown(void)
-{
- struct adb_request req;
- if (pmu_request(&req, NULL,
- 2, PMU_SET_INTR_MASK, PMU_INT_ADB|PMU_INT_TICK) < 0)
- return;
- while (!req.complete)
- pmu_poll();
- if (pmu_request(&req, NULL, 5, PMU_SHUTDOWN, 'M', 'A', 'T', 'T') < 0)
- return;
- while (!req.complete)
- pmu_poll();
-}
-
-#endif
-
/*
*---
* Below this point are the generic routines; they'll dispatch to the
@@ -423,7 +391,7 @@ void mac_pram_read(int offset, __u8 *buffer, int len)
func = cuda_read_pram;
break;
#endif
-#ifdef CONFIG_ADB_PMU68K
+#ifdef CONFIG_ADB_PMU
case MAC_ADB_PB2:
func = pmu_read_pram;
break;
@@ -453,7 +421,7 @@ void mac_pram_write(int offset, __u8 *buffer, int len)
func = cuda_write_pram;
break;
#endif
-#ifdef CONFIG_ADB_PMU68K
+#ifdef CONFIG_ADB_PMU
case MAC_ADB_PB2:
func = pmu_write_pram;
break;
@@ -477,7 +445,7 @@ void mac_poweroff(void)
macintosh_config->adb_type == MAC_ADB_CUDA) {
cuda_shutdown();
#endif
-#ifdef CONFIG_ADB_PMU68K
+#ifdef CONFIG_ADB_PMU
} else if (macintosh_config->adb_type == MAC_ADB_PB2) {
pmu_shutdown();
#endif
@@ -518,7 +486,7 @@ void mac_reset(void)
macintosh_config->adb_type == MAC_ADB_CUDA) {
cuda_restart();
#endif
-#ifdef CONFIG_ADB_PMU68K
+#ifdef CONFIG_ADB_PMU
} else if (macintosh_config->adb_type == MAC_ADB_PB2) {
pmu_restart();
#endif
@@ -670,7 +638,7 @@ int mac_hwclk(int op, struct rtc_time *t)
now = cuda_read_time();
break;
#endif
-#ifdef CONFIG_ADB_PMU68K
+#ifdef CONFIG_ADB_PMU
case MAC_ADB_PB2:
Re: [PATCH] uapi: Make generic uapi headers compile standalone.
Hi Jayant, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.17 next-20180607] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jayant-Chowdhary/uapi-Make-generic-uapi-headers-compile-standalone/20180608-014548 reproduce: # apt-get install sparse make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) /usr/lib/gcc/x86_64-linux-gnu/7/include/stddef.h:417:9: sparse: preprocessor token offsetof redefined include/linux/stddef.h:17:9: this was the original definition >> drivers/hv/hv_fcopy.c:160:34: sparse: incorrect type in argument 1 >> (different type sizes) @@expected unsigned short const [usertype] *pwcs >> @@got nst [usertype] *pwcs @@ drivers/hv/hv_fcopy.c:160:34:expected unsigned short const [usertype] *pwcs drivers/hv/hv_fcopy.c:160:34:got int [usertype] * drivers/hv/hv_fcopy.c:164:34: sparse: incorrect type in argument 1 (different type sizes) @@expected unsigned short const [usertype] *pwcs @@ got nst [usertype] *pwcs @@ drivers/hv/hv_fcopy.c:164:34:expected unsigned short const [usertype] *pwcs drivers/hv/hv_fcopy.c:164:34:got int [usertype] * -- /usr/lib/gcc/x86_64-linux-gnu/7/include/stddef.h:417:9: sparse: preprocessor token offsetof redefined include/linux/stddef.h:17:9: this was the original definition drivers/hwmon/asc7621.c:194:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:194:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:194:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:194:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:194:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:194:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:194:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:227:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:227:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:227:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:227:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:227:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:227:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:227:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:227:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:277:37: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:277:37: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:277:37: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:277:37: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:277:37: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:277:37: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:277:37: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:346:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:346:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:346:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:346:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:346:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:346:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:346:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:350:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:350:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:350:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:350:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:350:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:350:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:350:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:379:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:379:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:379:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:379:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:379:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:379:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:379:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:435:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:435:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:435:18: sparse: expression using sizeof(void) drivers/hwmon/asc7621.c:435:18: sparse: expression using
Re: [RFC] IB/mad: Use IDR instead of per-port list
On Thu, Jun 07, 2018 at 04:49:26PM -0700, Matthew Wilcox wrote: > On Thu, Jun 07, 2018 at 04:26:46PM -0600, Jason Gunthorpe wrote: > > On Thu, Jun 07, 2018 at 12:08:32PM -0700, Matthew Wilcox wrote: > > > > > > Hans reports a bug where the mlx4 driver uses the MSB of the agent number > > > to store slave number, meaning we can only use agent numbers up to 2^24. > > > Fix this by using an IDR to assign the agent numbers and also look up the > > > agent when a MSD packet is received. > > > > > > I've changed the locking substantially, so this may well have a > > > performance issue. There are a few different possibilities for fixing > > > that, including moving to an RCU-based lookup. > > > > I do like this better than the last series.. > > > > This are is somewhat performance sensitive and it would be nice to > > avoid this global lock. > > OK, I wasn't sure whether it was worth it. > > > What about using a read/write spinlock instead of the IDR internal > > lock? Then all the per-port reading threads calling find_mad_agent can > > run concurrently.. > > It'd be better to switch to RCU ... the IDR is RCU-safe, but the > version/class/method or OUI match isn't. Do you have any feeling on > the relative frequency of the two types of "routing"? I would say they are close to equally important, perhaps the version/class/method is slightly more important. > Actually, I think we can use the radix tree data structure for the > version/class/method too ... that's going to take a little more work. I was wondering about that as well, this code is very old so there must be better data structure helpers these days. Jason
Re: [PATCH] slab: Clean up the code comment in slab kmem_cache struct
On 06/06/18 at 11:48pm, Christopher Lameter wrote:
> On Wed, 6 Jun 2018, Baoquan He wrote:
>
> > I am back porting Thomas's sl[a|u]b freelist randomization feature to
> > our distros, need go through slab code for better understanding. From
> > git log history, they were 'obj_offset' and 'obj_size'. Later on
> > 'obj_size' was renamed to 'object_size' in commit 3b0efdfa1e("mm, sl[aou]b:
> > Extract common fields from struct kmem_cache") which is from your patch.
> > With my understanding, I guess you changed that on purpose because
> > object_size is size of each object, obj_offset is for the whole cache,
> > representing the offset the real object starts to be stored. And putting
> > them separately is for better desribing them in code comment and
> > distinction, e.g 'object_size' is in "4) cache creation/removal",
> > while 'obj_offset' is put alone to indicate it's for the whole.
>
> obj_offset only applies when CONFIG_SLAB_DEBUG is set. Ok so that screwy
> name also indicates that something special goes on.
They are a little confusing when combine SLAB with SLUB,
SLABSLUB
sizesize
object_size object_size
obj_offset offset
object_size also only applies when CONFIG_SLAB_DEBUG is set,
otherwise it's equal to size in SLAB case. Whereas SLUB always has
object plus freeptr for each object space.
Thought to add code comment to make them clearer, on second thought,
anyone who want to understand slab/slub code well, has to go through the
whole header file and souce code, this pain need be borne.
[PATCH] component: enhance handling of devres group for master
From: Banajit Goswami
The devres group opened for a master is left open-ended (without
devres_group_close) even after bind() is complete. Similarly, while
releasing the devres resources for master, the most recently opened
devres group is selected, and released without identifying the
targeted group. As the devres group opened before master bind was
never closed, there may have unintended consequences of releasing
devres resources that were allocated after master bind() function
was complete.
Change adds a devres_group_close() after bind() call to master, to
encapsulate the resources allocated during bind, and then use a
group ID to specifically identify the group in release, so that
during master unbind, only the resources that are part of that
specific devres group, are released.
Signed-off-by: Banajit Goswami
---
drivers/base/component.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/base/component.c b/drivers/base/component.c
index 89b032f..f9ce937 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -155,17 +155,19 @@ static int try_to_bring_up_master(struct master *master,
return 0;
}
- if (!devres_open_group(master->dev, NULL, GFP_KERNEL))
+ if (!devres_open_group(master->dev, master, GFP_KERNEL))
return -ENOMEM;
/* Found all components */
ret = master->ops->bind(master->dev);
if (ret < 0) {
- devres_release_group(master->dev, NULL);
+ devres_release_group(master->dev, master);
dev_info(master->dev, "master bind failed: %d\n", ret);
return ret;
}
+ devres_close_group(master->dev, master);
+
master->bound = true;
return 1;
}
@@ -190,7 +192,7 @@ static void take_down_master(struct master *master)
{
if (master->bound) {
master->ops->unbind(master->dev);
- devres_release_group(master->dev, NULL);
+ devres_release_group(master->dev, master);
master->bound = false;
}
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH] fs: reclaim least recently used dquots
From: Greg Thelen
The dquots in the free_dquots list are not reclaimed in LRU way.
put_dquot_last() puts entries to the tail and dqcache_shrink_scan()
frees from the tail. Free unreferenced dquots in LRU order because it
seems more reasonable than freeing most recently used.
Signed-off-by: Greg Thelen
Signed-off-by: Shakeel Butt
---
fs/quota/dquot.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/quota/dquot.c b/fs/quota/dquot.c
index d88231e3b2be..241b00f835b9 100644
--- a/fs/quota/dquot.c
+++ b/fs/quota/dquot.c
@@ -716,7 +716,7 @@ dqcache_shrink_scan(struct shrinker *shrink, struct
shrink_control *sc)
unsigned long freed = 0;
spin_lock(&dq_list_lock);
- head = free_dquots.prev;
+ head = free_dquots.next;
while (head != &free_dquots && sc->nr_to_scan) {
dquot = list_entry(head, struct dquot, dq_free);
remove_dquot_hash(dquot);
@@ -725,7 +725,7 @@ dqcache_shrink_scan(struct shrinker *shrink, struct
shrink_control *sc)
do_destroy_dquot(dquot);
sc->nr_to_scan--;
freed++;
- head = free_dquots.prev;
+ head = free_dquots.next;
}
spin_unlock(&dq_list_lock);
return freed;
--
2.18.0.rc1.242.g61856ae69a-goog
Re: [PATCH] md: Unify mddev destruction paths
On 6/7/18 6:52 PM, Kent Overstreet wrote: > Previously, mddev_put() had a couple different paths for freeing a > mddev, due to the fact that the kobject wasn't initialized when the > mddev was first allocated. If we move the kobject_init() to when it's > first allocated and just use kobject_add() later, we can clean all this > up. > > This also removes a hack in mddev_put() to avoid freeing biosets under a > spinlock, which involved copying biosets on the stack after the reset > bioset_init() changes. Looks good to me, much nicer than the previous hack. -- Jens Axboe
Re: [PATCH 3.16 012/410] scsi: libsas: direct call probe and destruct
On 2018/6/8 2:18, Ben Hutchings wrote:
On Thu, 2018-06-07 at 17:32 +0100, John Garry wrote:
On 07/06/2018 15:05, Ben Hutchings wrote:
3.16.57-rc1 review patch. If anyone has any objections, please let me know.
--
Hi Ben,
I noticed that you are looking to backport this patch to 3.16
I am wondering why you are taking this libsas patch (and a couple other
libsas patches) in isolation, when these patches were part of a series
to fix libsas hotplug issues? I'm not sure if cherry-picking certain
patches is ok.
Maybe Jason (cc'ed) can comment further.
This one apparently fixed a security issue (CVE-2017-18232), though I'm
certainly not convinced it's a particularly serious one.
But please send objections to the list, not just privately.
Hi Ben,
This patch is in the series below. I recommend to backport them
together. If you really want to do this, I'm happy to help you to
backport them.
1689c9367bfa scsi: libsas: notify event PORTE_BROADCAST_RCVD in
sas_enable_revalidation()
0558f33c06bb scsi: libsas: direct call probe and destruct
517e5153d242 scsi: libsas: use flush_workqueue to process disco events
synchronously
93bdbd06b164 scsi: libsas: Use new workqueue to run sas event and disco
event
8eea9dd84e45 scsi: libsas: make the event threshold configurable
f12486e06ae8 scsi: libsas: shut down the PHY if events reached the threshold
1c393b970e0f scsi: libsas: Use dynamic alloced work to avoid sas event lost
Ben.
Thanks,
John
From: Jason Yan
commit 0558f33c06bb910e2879e355192227a8e8f0219d upstream.
In commit 87c8331fcf72 ("[SCSI] libsas: prevent domain rediscovery
competing with ata error handling") introduced disco mutex to prevent
rediscovery competing with ata error handling and put the whole
revalidation in the mutex. But the rphy add/remove needs to wait for the
error handling which also grabs the disco mutex. This may leads to dead
lock.So the probe and destruct event were introduce to do the rphy
add/remove asynchronously and out of the lock.
The asynchronously processed workers makes the whole discovery process
not atomic, the other events may interrupt the process. For example,
if a loss of signal event inserted before the probe event, the
sas_deform_port() is called and the port will be deleted.
And sas_port_delete() may run before the destruct event, but the
port-x:x is the top parent of end device or expander. This leads to
a kernel WARNING such as:
[ 82.042979] sysfs group 'power' not found for kobject 'phy-1:0:22'
[ 82.042983] [ cut here ]
[ 82.042986] WARNING: CPU: 54 PID: 1714 at fs/sysfs/group.c:237
sysfs_remove_group+0x94/0xa0
[ 82.043059] Call trace:
[ 82.043082] [] sysfs_remove_group+0x94/0xa0
[ 82.043085] [] dpm_sysfs_remove+0x60/0x70
[ 82.043086] [] device_del+0x138/0x308
[ 82.043089] [] sas_phy_delete+0x38/0x60
[ 82.043091] [] do_sas_phy_delete+0x6c/0x80
[ 82.043093] [] device_for_each_child+0x58/0xa0
[ 82.043095] [] sas_remove_children+0x40/0x50
[ 82.043100] [] sas_destruct_devices+0x64/0xa0
[ 82.043102] [] process_one_work+0x1fc/0x4b0
[ 82.043104] [] worker_thread+0x50/0x490
[ 82.043105] [] kthread+0xfc/0x128
[ 82.043107] [] ret_from_fork+0x10/0x50
Make probe and destruct a direct call in the disco and revalidate function,
but put them outside the lock. The whole discovery or revalidate won't
be interrupted by other events. And the DISCE_PROBE and DISCE_DESTRUCT
event are deleted as a result of the direct call.
Introduce a new list to destruct the sas_port and put the port delete after
the destruct. This makes sure the right order of destroying the sysfs
kobject and fix the warning above.
In sas_ex_revalidate_domain() have a loop to find all broadcasted
device, and sometimes we have a chance to find the same expander twice.
Because the sas_port will be deleted at the end of the whole revalidate
process, sas_port with the same name cannot be added before this.
Otherwise the sysfs will complain of creating duplicate filename. Since
the LLDD will send broadcast for every device change, we can only
process one expander's revalidation.
[mkp: kbuild test robot warning]
Signed-off-by: Jason Yan
CC: John Garry
CC: Johannes Thumshirn
CC: Ewan Milne
CC: Christoph Hellwig
CC: Tomas Henzl
CC: Dan Williams
Reviewed-by: Hannes Reinecke
Signed-off-by: Martin K. Petersen
[bwh: Backported to 4.9: adjust context]
Signed-off-by: Ben Hutchings
---
drivers/scsi/libsas/sas_ata.c | 1 -
drivers/scsi/libsas/sas_discover.c | 32 +-
drivers/scsi/libsas/sas_expander.c | 8 +++-
drivers/scsi/libsas/sas_internal.h | 1 +
drivers/scsi/libsas/sas_port.c | 3 +++
include/scsi/libsas.h | 3 +--
include/scsi/scsi_transport_sas.h | 1 +
7 files changed, 27 insertions(+), 22 deletions(-)
--- a/drivers/scsi/libsas/sas_ata.c
+++ b/drivers/scsi/libsas/sas_ata.c
@@ -782,7 +782,6 @@ int sas_discover_sata(struct domain_devi
if (
Re: [PATCH v2] mm/ksm: ignore STABLE_FLAG of rmap_item->address in rmap_walk_ksm
Hi Andrea Thanks for the review. On 6/8/2018 7:38 AM, Andrea Arcangeli Wrote: > On Thu, Jun 07, 2018 at 03:13:44PM -0700, Andrew Morton wrote: >> This patch is quite urgent and is tagged for -stable backporting, yet >> it remains in an unreviewed state. Any takers? > > It looks a straightforward safe fix, on x86 hva_to_gfn_memslot would > zap those bits and hide the misalignment caused by the low metadata > bits being erroneously left set in the address, but the arm code > notices when that's the last page in the memslot and the hva_end is > getting aligned and the size is below one page. > >> [35380.933345] [] dump_backtrace+0x0/0x22c >> [35380.938723] [] show_stack+0x24/0x2c >> [35380.943759] [] dump_stack+0x8c/0xb0 >> [35380.948794] [] bad_page+0xf4/0x154 >> [35380.953740] [] free_pages_check_bad+0x90/0x9c >> [35380.959642] [] free_pcppages_bulk+0x464/0x518 >> [35380.965545] [] free_hot_cold_page+0x22c/0x300 >> [35380.971448] [] __put_page+0x54/0x60 >> [35380.976484] [] unmap_stage2_range+0x170/0x2b4 >> [35380.982385] [] kvm_unmap_hva_handler+0x30/0x40 >> [35380.988375] [] handle_hva_to_gpa+0xb0/0xec >> [35380.994016] [] kvm_unmap_hva_range+0x5c/0xd0 >> [35380.999833] [] >> >> I even injected a fault on purpose in kvm_unmap_hva_range by seting >> size=size-0x200, the call trace is similar as above. So I thought the >> panic is similarly caused by the root cause of WARN_ON. > > I think the problem triggers in the addr += PAGE_SIZE of > unmap_stage2_ptes that never matches end because end is aligned but > addr is not. > > } while (pte++, addr += PAGE_SIZE, addr != end); > > x86 again only works on hva_start/hva_end after converting it to > gfn_start/end and that being in pfn units the bits are zapped before > they risk to cause trouble. For this panic issue on arm64, I started another thread to discuss https://lkml.org/lkml/2018/5/2/61 -- Cheers, Jia > >> >> Link: >> http://lkml.kernel.org/r/1525403506-6750-1-git-send-email-hejia...@gmail.com >> Signed-off-by: Jia He >> Cc: Suzuki K Poulose >> Cc: Andrea Arcangeli >> Cc: Minchan Kim >> Cc: Claudio Imbrenda >> Cc: Arvind Yadav >> Cc: Mike Rapoport >> Cc: Jia He >> Cc: >> Signed-off-by: Andrew Morton >> --- >> > > Reviewed-by: Andrea Arcangeli >
Re: [PATCH v2] mm/ksm: ignore STABLE_FLAG of rmap_item->address in rmap_walk_ksm
Hi Andrew On 6/8/2018 6:13 AM, Andrew Morton Wrote: > On Thu, 24 May 2018 13:38:05 -0700 Andrew Morton > wrote: >>> >>> Jia, Andrew, >>> >>> What is the status of this patch ? >>> >> >> I have it scheduled for 4.18-rc1, with a cc:stable for backporting. >> >> I'd normally put such a fix into 4.17-rcX but I'd like to give Hugh >> time to review it and to generally give it a bit more time for review >> and test. >> >> Have you tested it yourself? > > I'll take your silence as a no. Sorry if you asked the previous question to me. I've tested by myself in arm64 server (QDF2400,46 cpus,96G mem) Without this patch, the WARN_ON is very easy for reproducing. After this patch, I have run the same benchmarch for a whole day without any WARN_ONs Hope it helpful. Cheers, Jia
Re: mmotm 2018-06-07-16-59 uploaded (scsi/ipr)
On 06/07/2018 04:59 PM, a...@linux-foundation.org wrote: > The mm-of-the-moment snapshot 2018-06-07-16-59 has been uploaded to > >http://www.ozlabs.org/~akpm/mmotm/ > on i386 (randconfig): ../drivers/scsi/ipr.c: In function 'ipr_mask_and_clear_interrupts': ../drivers/scsi/ipr.c:767:3: error: implicit declaration of function 'writeq_relaxed' [-Werror=implicit-function-declaration] writeq_relaxed(~0, ioa_cfg->regs.set_interrupt_mask_reg); ^ need config? -- ~Randy
Re: [PATCH] uapi: Make generic uapi headers compile standalone.
Hi, On 06/06/2018 09:58 PM, Masahiro Yamada wrote: > Hi. > > > 2018-06-07 8:16 GMT+09:00 Jayant Chowdhary : >> In order for static analysis tools to analyze each of the uapi headers, >> we need to enable them to compile stand-alone. Some uapi headers were >> missing dependencies which would not make them compile stand-alone in >> user-land. This patch adds those dependencies. >> >> Test: make defconfig; make -j64 >> >> Test: make ARCH=arm64 defconfig; >> ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make -j64 all >> >> Test: ran header-abi-dumper[1] on all the affected headers with >> appropriate include paths[2] for arm64. eg: for drm_fourcc.h, >> >> $HEADER_ABI_DUMPER -o drm_fourcc.h.sdump \ >> include/uapi/drm/drm_fourcc.h -- -target aarch64-linux-android -std=gnu99 \ >> -isystem $CLANG_INCLUDE_PATH \ >> -I include/uapi/ -I arch/arm64/include/generated/uapi \ >> -I arch/arm64/include/uapi -I private-compiler-headers >> -I include/generated/uapi \ >> -I include/uapi/../../arch/arm/include/uapi > > > First of all, is this check sensible? > > scripts/headers_install.sh manipulates exported headers. > > So, shouldn't you do this check after "make headers_install"? > > Apologies, I was unaware of this. Now it is obvious that this check is not sensible :) The headers which should be checked are the ones 'make headers install' produces and not the ones being checked currently. I'll fix this in the next version of this patch. > > You are adding around to various UAPI headers. > Could you tell me why it was added? > > The tool rips off anyway when exporting UAPI headers: > https://github.com/torvalds/linux/blob/v4.17/scripts/headers_install.sh#L37 > > I had added these to satisfy the defines included from , however, since headers_install.sh removes the #includes and the defines themselves, these additions should not be needed. > > > Also, you are adding to several headers. > Please do not pull it in to the kernel space. > The kernel space defines fixed-width types in its headers. > > For example, you added to include/uapi/scsi/scsi_netlink.h > > In my opinion, the correct fix is to replace uint8_t with __u8 or __uint8_t. > > Sure, I will correct this. Thanks, Jayant > > > > >> where >> HEADER_ABI_DUMPER=\ >> $ANDROID_BUILD_TOP/prebuilts/clang-tools/linux-x86/bin/header-abi-dumper >> >> CLANG_INCLUDE_PATH=\ >> $ANDROID_BUILD_TOP/prebuilts/clang/host/linux-x86/clang-3289846/bin/../lib64/clang/3.8/include >> >> on a lunched aosp tree [3] >> >> [1] >> header-abi-dumper is a clang based static analysis tool, used by android's >> build >> system which parses a C/C++ source file and emits information about the data >> types included in the source. More information can be found at >> https://android.googlesource.com/platform/development/+/master/vndk/tools/header-checker/README.md >> >> [2] >> Some headers, eg: compiler_types.h, compiler.h, sys/socket.h are not in the >> set of uapi headers, even though they are included by uapi headers( >> include/uapi/linux/types.h, include/uapi/asm-generic/signal-defs.h etc). The >> 'private-compiler-headers' in the test clause was included with private >> copies >> of these headers. libc distributions (eg: bionic) often have their >> copies of these headers as well. >> >> [3] >> https://source.android.com/setup/build/downloading >> >> Cc: a...@linux-foundation.org >> Cc: kernel-t...@android.com >> Cc: linux-kbu...@vger.kernel.org >> Signed-off-by: Jayant Chowdhary >> --- >> include/uapi/asm-generic/ipcbuf.h | 2 ++ >> include/uapi/asm-generic/msgbuf.h | 3 +++ >> include/uapi/asm-generic/sembuf.h | 2 ++ >> include/uapi/asm-generic/shmbuf.h | 2 ++ >> include/uapi/asm-generic/ucontext.h| 5 + >> include/uapi/linux/agpgart.h | 1 - >> include/uapi/linux/android/binder.h| 1 + >> include/uapi/linux/chio.h | 6 ++ >> include/uapi/linux/coda_psdev.h| 1 + >> include/uapi/linux/dvb/dmx.h | 3 --- >> include/uapi/linux/dvb/video.h | 3 --- >> include/uapi/linux/errqueue.h | 1 + >> include/uapi/linux/kexec.h | 1 + >> include/uapi/linux/kfd_ioctl.h | 1 + >> include/uapi/linux/lightnvm.h | 1 - >> include/uapi/linux/ndctl.h | 1 + >> include/uapi/linux/netfilter_bridge/ebtables.h | 1 + >> include/uapi/linux/nfs4_mount.h| 3 +++ >> include/uapi/linux/psp-sev.h | 1 + >> include/uapi/linux/scc.h | 2 +- >> include/uapi/linux/sctp.h | 3 +++ >> include/uapi/linux/sdla.h | 2 ++ >> include/uapi/linux/socket.h| 4 >> include/uapi/linux/stddef.h| 5 + >> include/uapi/linux/sysctl.h| 1 + >> include/uapi/linux/types.h
Re: linux-next: build failure after merge of the thermal tree
Hi all,
On Fri, 8 Jun 2018 10:51:20 +1000 Stephen Rothwell
wrote:
>
> After merging the thermal tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/thermal/qcom/tsens.c: In function 'tsens_probe':
> drivers/thermal/qcom/tsens.c:144:31: error: 's' undeclared (first use in this
> function)
> num_sensors * sizeof(*s), GFP_KERNEL);
>^
>
> Caused by commit
>
> 6d7c70d1cd65 ("thermal: qcom: tsens: Allow number of sensors to come from
> DT")
>
> interacting with commit
>
> 0ed2dd03b94b ("treewide: Use struct_size() for devm_kmalloc() and friends")
>
> from Linus' tree. It looks like git somehow screwed up the automatic
> conflict resolution.
OK, this was caused by a bad rerere entry in my tree (from my recent import of
Andrew's mmotm patch series). Sorry about that, I have fixed it up.
--
Cheers,
Stephen Rothwell
pgprYtfHdeD9u.pgp
Description: OpenPGP digital signature
[PATCH][v2] sched: cpufreq: Fix long idle judgement logic in load calculation
According to current code implementation, detecting the long
idle period is done by checking if the interval between two
adjacent utilization update handers is long enough. Although
this mechanism can detect if the idle period is long enough
(no utilization hooks invoked during idle period), it might
not contain a corner case: if the task has occupied the cpu
for too long which causes no context switch during that
period, then no utilization handler will be launched until this
high prio task is switched out. As a result, the idle_periods
field might be calculated incorrectly because it regards the
100% load as 0% and makes the conservative governor who uses
this field confusing.
Change the judgement to compare the idle_time with sampling_rate
directly.
Reported-by: Artem S. Tashkinov
Cc: Artem S Tashkinov
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc: linux...@vger.kernel.org
Signed-off-by: Chen Yu
---
v2: Per Viresh's suggestion, ignore idle_time longer than 30mins and
simplify the code.
---
drivers/cpufreq/cpufreq_governor.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq_governor.c
index 871bf9c..1d50e97 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -165,7 +165,7 @@ unsigned int dbs_update(struct cpufreq_policy *policy)
* calls, so the previous load value can be used then.
*/
load = j_cdbs->prev_load;
- } else if (unlikely(time_elapsed > 2 * sampling_rate &&
+ } else if (unlikely((int)idle_time > 2 * sampling_rate &&
j_cdbs->prev_load)) {
/*
* If the CPU had gone completely idle and a task has
@@ -185,10 +185,8 @@ unsigned int dbs_update(struct cpufreq_policy *policy)
* clear prev_load to guarantee that the load will be
* computed again next time.
*
-* Detecting this situation is easy: the governor's
-* utilization update handler would not have run during
-* CPU-idle periods. Hence, an unusually large
-* 'time_elapsed' (as compared to the sampling rate)
+* Detecting this situation is easy: an unusually large
+* 'idle_time' (as compared to the sampling rate)
* indicates this scenario.
*/
load = j_cdbs->prev_load;
@@ -217,8 +215,8 @@ unsigned int dbs_update(struct cpufreq_policy *policy)
j_cdbs->prev_load = load;
}
- if (time_elapsed > 2 * sampling_rate) {
- unsigned int periods = time_elapsed / sampling_rate;
+ if (unlikely((int)idle_time > 2 * sampling_rate)) {
+ unsigned int periods = idle_time / sampling_rate;
if (periods < idle_periods)
idle_periods = periods;
--
2.7.4
Re: mmotm 2018-06-07-16-59 uploaded (fs/fat/ and fs/dax/)
On 06/07/2018 04:59 PM, a...@linux-foundation.org wrote: > The mm-of-the-moment snapshot 2018-06-07-16-59 has been uploaded to > >http://www.ozlabs.org/~akpm/mmotm/ > (on i386:) ../fs/fat/inode.c: In function '__fat_get_block': ../fs/fat/inode.c:162:3: warning: format '%ld' expects argument of type 'long int', but argument 5 has type 'sector_t' [-Wformat=] fat_fs_error(sb, ^ ../fs/dax.c: In function 'dax_load_hole': ../fs/dax.c:1031:2: error: 'entry2' undeclared (first use in this function) entry2 = dax_insert_mapping_entry(mapping, vmf, entry, pfn, ^ Easy fixes... :) -- ~Randy
Re: [PATCH 6/9] x86/mm: Introduce ptep_set_wrprotect_flush and related functions
On Thu, Jun 7, 2018 at 1:30 PM Dave Hansen wrote:
>
> On 06/07/2018 09:24 AM, Andy Lutomirski wrote:
>
> >> +static inline void ptep_set_wrprotect_flush(struct vm_area_struct *vma,
> >> + unsigned long addr, pte_t
> >> *ptep)
> >> +{
> >> + bool rw;
> >> +
> >> + rw = test_and_clear_bit(_PAGE_BIT_RW, (unsigned long *)&ptep->pte);
> >> + if (IS_ENABLED(CONFIG_X86_INTEL_SHADOW_STACK_USER)) {
> >> + struct mm_struct *mm = vma->vm_mm;
> >> + pte_t pte;
> >> +
> >> + if (rw && (atomic_read(&mm->mm_users) > 1))
> >> + pte = ptep_clear_flush(vma, addr, ptep);
> > Why are you clearing the pte?
>
> I found my notes on the subject. :)
>
> Here's the sequence that causes the problem. This could happen any time
> we try to take a PTE from read-write to read-only. P==Present, W=Write,
> D=Dirty:
>
> CPU0 does a write, sees PTE with P=1,W=1,D=0
> CPU0 decides to set D=1
> CPU1 comes in and sets W=0
> CPU0 does locked operation to set D=1
> CPU0 sees P=1,W=0,D=0
> CPU0 sets back P=1,W=0,D=1
> CPU0 loads P=1,W=0,D=1 into the TLB
> CPU0 attempts to continue the write, but sees W=0 in the TLB and a #PF
> is generated because of the write fault.
>
> The problem with this is that we end up with a shadowstack-PTE
> (Write=0,Dirty=1) where we didn't want one. This, unfortunately,
> imposes extra TLB flushing overhead on the R/W->R/O transitions that
> does not exist before shadowstack enabling.
>
So what exactly do the architects want the OS to do? AFAICS the only
valid ways to clear the dirty bit are:
--- Choice 1 ---
a) Set P=0.
b) Flush using an IPI
c) Read D (so we know if the page was actually dirty)
d) Set P=1,W=0,D=0
and we need to handle spurious faults that happen between steps (a)
and (c). This isn't so easy because the straightforward "is the fault
spurious" check is going to think it's *not* spurious.
--- Choice 2 ---
a) Set W=0
b) flush
c) Test and clear D
and we need to handle the spurious fault between b and c. At least
this particular spurious fault is easier to handle since we can check
the error code.
But surely the right solution is to get the architecture team to see
if they can fix the dirty-bit-setting algorithm or, even better, to
look and see if the dirty-bit-setting algorithm is *already* better
and just document it. If the cpu does a locked set-bit on D in your
example, the CPU is just being silly. The CPU should make the whole
operation fully atomic: when trying to write to a page that's D=0 in
the TLB, it should re-walk the page tables and, atomically, load the
PTE and, if it's W=1,D=0, set D=1. I'd honestly be a bit surprised if
modern CPUs don't already do this.
(Hmm. If the CPUs were that smart, then we wouldn't need a flush at
all in some cases. If we lock cmpxchg to change W=1,D=0 to W=0,D=0,
then we know that no other CPU can subsequently write the page without
re-walking, and we don't need to flush.)
Can you ask the architecture folks to clarify the situation? And, if
your notes are indeed correct, don't we need code to handle spurious
faults?
--Andy
[PATCH] md: Unify mddev destruction paths
Previously, mddev_put() had a couple different paths for freeing a
mddev, due to the fact that the kobject wasn't initialized when the
mddev was first allocated. If we move the kobject_init() to when it's
first allocated and just use kobject_add() later, we can clean all this
up.
This also removes a hack in mddev_put() to avoid freeing biosets under a
spinlock, which involved copying biosets on the stack after the reset
bioset_init() changes.
Signed-off-by: Kent Overstreet
---
drivers/md/md.c | 53 +
1 file changed, 18 insertions(+), 35 deletions(-)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index fc692b7128..22203eba1e 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -84,6 +84,8 @@ static void autostart_arrays(int part);
static LIST_HEAD(pers_list);
static DEFINE_SPINLOCK(pers_lock);
+static struct kobj_type md_ktype;
+
struct md_cluster_operations *md_cluster_ops;
EXPORT_SYMBOL(md_cluster_ops);
struct module *md_cluster_mod;
@@ -510,11 +512,6 @@ static void mddev_delayed_delete(struct work_struct *ws);
static void mddev_put(struct mddev *mddev)
{
- struct bio_set bs, sync_bs;
-
- memset(&bs, 0, sizeof(bs));
- memset(&sync_bs, 0, sizeof(sync_bs));
-
if (!atomic_dec_and_lock(&mddev->active, &all_mddevs_lock))
return;
if (!mddev->raid_disks && list_empty(&mddev->disks) &&
@@ -522,30 +519,23 @@ static void mddev_put(struct mddev *mddev)
/* Array is not configured at all, and not held active,
* so destroy it */
list_del_init(&mddev->all_mddevs);
- bs = mddev->bio_set;
- sync_bs = mddev->sync_set;
- memset(&mddev->bio_set, 0, sizeof(mddev->bio_set));
- memset(&mddev->sync_set, 0, sizeof(mddev->sync_set));
- if (mddev->gendisk) {
- /* We did a probe so need to clean up. Call
-* queue_work inside the spinlock so that
-* flush_workqueue() after mddev_find will
-* succeed in waiting for the work to be done.
-*/
- INIT_WORK(&mddev->del_work, mddev_delayed_delete);
- queue_work(md_misc_wq, &mddev->del_work);
- } else
- kfree(mddev);
+
+ /*
+* Call queue_work inside the spinlock so that
+* flush_workqueue() after mddev_find will succeed in waiting
+* for the work to be done.
+*/
+ INIT_WORK(&mddev->del_work, mddev_delayed_delete);
+ queue_work(md_misc_wq, &mddev->del_work);
}
spin_unlock(&all_mddevs_lock);
- bioset_exit(&bs);
- bioset_exit(&sync_bs);
}
static void md_safemode_timeout(struct timer_list *t);
void mddev_init(struct mddev *mddev)
{
+ kobject_init(&mddev->kobj, &md_ktype);
mutex_init(&mddev->open_mutex);
mutex_init(&mddev->reconfig_mutex);
mutex_init(&mddev->bitmap_info.mutex);
@@ -5215,6 +5205,8 @@ static void md_free(struct kobject *ko)
put_disk(mddev->gendisk);
percpu_ref_exit(&mddev->writes_pending);
+ bioset_exit(&mddev->bio_set);
+ bioset_exit(&mddev->sync_set);
kfree(mddev);
}
@@ -5348,8 +5340,7 @@ static int md_alloc(dev_t dev, char *name)
mutex_lock(&mddev->open_mutex);
add_disk(disk);
- error = kobject_init_and_add(&mddev->kobj, &md_ktype,
-&disk_to_dev(disk)->kobj, "%s", "md");
+ error = kobject_add(&mddev->kobj, &disk_to_dev(disk)->kobj, "%s", "md");
if (error) {
/* This isn't possible, but as kobject_init_and_add is marked
* __must_check, we must do something with the result
@@ -5506,7 +5497,7 @@ int md_run(struct mddev *mddev)
if (!bioset_initialized(&mddev->sync_set)) {
err = bioset_init(&mddev->sync_set, BIO_POOL_SIZE, 0,
BIOSET_NEED_BVECS);
if (err)
- goto abort;
+ return err;
}
spin_lock(&pers_lock);
@@ -5519,8 +5510,7 @@ int md_run(struct mddev *mddev)
else
pr_warn("md: personality for level %s is not loaded!\n",
mddev->clevel);
- err = -EINVAL;
- goto abort;
+ return -EINVAL;
}
spin_unlock(&pers_lock);
if (mddev->level != pers->level) {
@@ -5533,8 +5523,7 @@ int md_run(struct mddev *mddev)
pers->start_reshape == NULL) {
/* This personality cannot handle reshaping... */
module_put(pers->owner);
- err = -EINVAL;
- goto abort;
+ return -EINVAL;
}
if (pers->sync_request) {
@@ -5603,7 +5592,7 @@ in
linux-next: build failure after merge of the thermal tree
Hi Zhang,
After merging the thermal tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/thermal/qcom/tsens.c: In function 'tsens_probe':
drivers/thermal/qcom/tsens.c:144:31: error: 's' undeclared (first use in this
function)
num_sensors * sizeof(*s), GFP_KERNEL);
^
Caused by commit
6d7c70d1cd65 ("thermal: qcom: tsens: Allow number of sensors to come from DT")
interacting with commit
0ed2dd03b94b ("treewide: Use struct_size() for devm_kmalloc() and friends")
from Linus' tree. It looks like git somehow screwed up the automatic
conflict resolution.
I have added the following patch for today:
From: Stephen Rothwell
Date: Fri, 8 Jun 2018 10:46:46 +1000
Subject: [PATCH] thermal: gcom: fix up bad git conflict resolution
Signed-off-by: Stephen Rothwell
---
drivers/thermal/qcom/tsens.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/qcom/tsens.c b/drivers/thermal/qcom/tsens.c
index fb8c87f55240..6164fd36dda3 100644
--- a/drivers/thermal/qcom/tsens.c
+++ b/drivers/thermal/qcom/tsens.c
@@ -140,8 +140,8 @@ static int tsens_probe(struct platform_device *pdev)
return -EINVAL;
}
- tmdev = devm_kzalloc(dev, sizeof(*tmdev) +
-num_sensors * sizeof(*s), GFP_KERNEL);
+ tmdev = devm_kzalloc(dev, struct_size(tmdev, sensor, num_sensors),
+GFP_KERNEL);
if (!tmdev)
return -ENOMEM;
--
2.17.1
--
Cheers,
Stephen Rothwell
pgpoJtUFJ1A1z.pgp
Description: OpenPGP digital signature
linux-next: build warning after merge of the pm tree
Hi all,
After merging the pm tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:
WARNING: vmlinux.o(.text+0xc5b83a): Section mismatch in reference from the
function __intel_pstate_cpu_init() to the variable
.init.rodata:intel_pstate_hwp_boost_ids
The function __intel_pstate_cpu_init() references
the variable __initconst intel_pstate_hwp_boost_ids.
This is often because __intel_pstate_cpu_init lacks a __initconst
annotation or the annotation of intel_pstate_hwp_boost_ids is wrong.
Introduced by commit
f50f70793d78 ("cpufreq: intel_pstate: enable boost for Skylake Xeon")
--
Cheers,
Stephen Rothwell
pgpSpUhoBYGpn.pgp
Description: OpenPGP digital signature
Re: [PATCH v6 2/2] regulator: add QCOM RPMh regulator driver
Hi David,
On Mon, Jun 04, 2018 at 12:15:12PM -0700, David Collins wrote:
> Add the QCOM RPMh regulator driver to manage PMIC regulators
> which are controlled via RPMh on some Qualcomm Technologies, Inc.
> SoCs. RPMh is a hardware block which contains several
> accelerators which are used to manage various hardware resources
> that are shared between the processors of the SoC. The final
> hardware state of a regulator is determined within RPMh by
> performing max aggregation of the requests made by all of the
> processors.
>
> Add support for PMIC regulator control via the voltage regulator
> manager (VRM) and oscillator buffer (XOB) RPMh accelerators.
> VRM supports manipulation of enable state, voltage, and mode.
> XOB supports manipulation of enable state.
>
> Signed-off-by: David Collins
> ---
> drivers/regulator/Kconfig | 9 +
> drivers/regulator/Makefile | 1 +
> drivers/regulator/qcom-rpmh-regulator.c | 767
>
> 3 files changed, 777 insertions(+)
> create mode 100644 drivers/regulator/qcom-rpmh-regulator.c
>
> ...
>
> diff --git a/drivers/regulator/qcom-rpmh-regulator.c
> b/drivers/regulator/qcom-rpmh-regulator.c
> new file mode 100644
> index 000..a7fffb6
> --- /dev/null
> +++ b/drivers/regulator/qcom-rpmh-regulator.c
>
> ...
> static int rpmh_regulator_send_request(struct rpmh_vreg *vreg,
> + struct tcs_cmd *cmd, int count, bool wait_for_ack)
>
nit: as of now this is only called with a single command. If you
anticipate that this is unlikely to change consider removing 'count',
not having it in the calls slightly improves readability.
> ...
> +static int _rpmh_regulator_vrm_set_voltage_sel(struct regulator_dev *rdev,
> + unsigned int selector, bool wait_for_ack)
> +{
> + struct rpmh_vreg *vreg = rdev_get_drvdata(rdev);
> + struct tcs_cmd cmd = {
> + .addr = vreg->addr + RPMH_REGULATOR_REG_VRM_VOLTAGE,
> + };
> + int ret;
> +
> + /* VRM voltage control register is set with voltage in millivolts. */
> + cmd.data = DIV_ROUND_UP(regulator_list_voltage_linear_range(rdev,
> + selector), 1000);
> +
> + ret = rpmh_regulator_send_request(vreg, &cmd, 1, wait_for_ack);
> + if (!ret)
> + vreg->voltage_selector = selector;
> +
> + return 0;
Shouldn't this return 'ret'?
> +static int rpmh_regulator_enable(struct regulator_dev *rdev)
> +{
> + struct rpmh_vreg *vreg = rdev_get_drvdata(rdev);
> + struct tcs_cmd cmd = {
> + .addr = vreg->addr + RPMH_REGULATOR_REG_ENABLE,
> + .data = 1,
> + };
> + int ret;
> +
> + if (vreg->enabled == -EINVAL &&
> + vreg->voltage_selector != -ENOTRECOVERABLE) {
> + ret = _rpmh_regulator_vrm_set_voltage_sel(rdev,
> + vreg->voltage_selector, true);
> + if (ret < 0)
> + return ret;
> + }
> +
> + ret = rpmh_regulator_send_request(vreg, &cmd, 1, true);
> + if (!ret)
> + vreg->enabled = true;
> +
> + return ret;
> +}
> +
> +static int rpmh_regulator_disable(struct regulator_dev *rdev)
> +{
> + struct rpmh_vreg *vreg = rdev_get_drvdata(rdev);
> + struct tcs_cmd cmd = {
> + .addr = vreg->addr + RPMH_REGULATOR_REG_ENABLE,
> + .data = 0,
> + };
> + int ret;
> +
> + if (vreg->enabled == -EINVAL &&
> + vreg->voltage_selector != -ENOTRECOVERABLE) {
> + ret = _rpmh_regulator_vrm_set_voltage_sel(rdev,
> + vreg->voltage_selector, true);
> + if (ret < 0)
> + return ret;
> + }
> +
> + ret = rpmh_regulator_send_request(vreg, &cmd, 1, false);
> + if (!ret)
> + vreg->enabled = false;
> +
> + return ret;
> +}
nit: rpmh_regulator_enable() and rpmh_regulator_disable() are
essentially the same code, consider introducing a helper like
_rpmh_regulator_enable(struct regulator_dev *rdev, bool enable).
> +/**
> + * rpmh_regulator_init_vreg() - initialize all attributes of an
> rpmh-regulator
> + * vreg: Pointer to the individual rpmh-regulator resource
> + * dev: Pointer to the top level rpmh-regulator PMIC
> device
> + * node: Pointer to the individual rpmh-regulator resource
> + * device node
> + * pmic_id: String used to identify the top level rpmh-regulator
> + * PMIC device on the board
> + * rpmh_data:Pointer to a null-terminated array of
> rpmh-regulator
> + * resources defined for the top level PMIC device
> + *
> + * Return: 0 on success, errno on failure
> + */
> +static int rpmh_regulator_init_vreg(struct rpmh_vreg *vreg, struct device
> *dev,
> + struct device_node *node, const
[PATCH] kbuild: fix endless syncconfig in case arch Makefile sets CROSS_COMPILE
Commit 21c54b774744 ("kconfig: show compiler version text in the top
comment") was intended to detect the compiler upgrade, but Geert
reported a breakage on the m68k build.
The compiler upgrade is detected by the change of the environment
variable, CC_VERSION_TEXT, which contains the first line of the output
from $(CC) --version. Currently, this works well when CROSS_COMPILE
is given via the environment variable or the Make command line.
However, some architectures such as m68k can specify CROSS_COMPILE
from arch/$(SRCARCH)/Makefile as well. In this case, "make ARCH=m68k"
ends up with endless syncconfig loop.
$ make ARCH=m68k defconfig
*** Default configuration is based on 'multi_defconfig'
#
# configuration written to .config
#
$ make ARCH=m68k
scripts/kconfig/conf --syncconfig Kconfig
scripts/kconfig/conf --syncconfig Kconfig
scripts/kconfig/conf --syncconfig Kconfig
scripts/kconfig/conf --syncconfig Kconfig
Things are happening like this:
Because arch/$(SRCARCH)/Makefile is included after CC_VERSION_TEXT
is set, it contains the host compiler version in the defconfig phase.
To create or update auto.conf, the following line is triggered:
include/config/%.conf: $(KCONFIG_CONFIG) include/config/auto.conf.cmd
$(Q)$(MAKE) -f $(srctree)/Makefile syncconfig
This recurses the top Makefile after arch/$(SRCARCH)/Makefile is
included. CROSS_COMPILE is set to a m68k toolchain prefix and
exported to the recursed Make. Then, syncconfig is invoked with
the target compiler version in CC_VERSION_TEXT.
The Make will restart because auto.conf and auto.conf.cmd have been
updated. At this point, CROSS_COMPILE is reset, so CC_VERSION_TEXT
is set to the host compiler version again. Then, syncconfig is
triggered due to the change of CC_VERSION_TEXT. This loop continues
eternally.
To fix this problem, $(CC_VERSION_TEXT) must be evaluated only after
arch/$(SRCARCH)/Makefile. Setting it earlier is OK as long as it is
defined by using the '=' operator instead of ':='.
For the defconfig phase, $(CC_VERSION_TEXT) is evaluated when Kbuild
descends into scripts/kconfig/, so it contains the target compiler
version correctly.
include/config/auto.conf.cmd references $(CC_VERSION_TEXT) as well,
so it must be included after arch/$(SRCARCH)/Makefile.
Fixes: 21c54b774744 ("kconfig: show compiler version text in the top comment")
Reported-by: Geert Uytterhoeven
Signed-off-by: Masahiro Yamada
---
Makefile | 54 ++
1 file changed, 30 insertions(+), 24 deletions(-)
diff --git a/Makefile b/Makefile
index 019a5a0..747edaf 100644
--- a/Makefile
+++ b/Makefile
@@ -442,8 +442,6 @@ export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE
KBUILD_LDFLAGS_MODULE
export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL
export KBUILD_ARFLAGS
-export CC_VERSION_TEXT := $(shell $(CC) --version | head -n 1)
-
# When compiling out-of-tree modules, put MODVERDIR in the module
# tree rather than in the kernel tree. The kernel tree might
# even be read-only.
@@ -514,6 +512,12 @@ ifeq ($(shell $(CONFIG_SHELL)
$(srctree)/scripts/cc-can-link.sh $(CC)), y)
export CC_CAN_LINK
endif
+# The expansion should be delayed until arch/$(SRCARCH)/Makefile is included.
+# Some architectures define CROSS_COMPILE in arch/$(SRCARCH)/Makefile.
+# CC_VERSION_TEXT is referenced from Kconfig (so it needs export),
+# and from include/config/auto.conf.cmd to detect the compiler upgrade.
+CC_VERSION_TEXT = $(shell $(CC) --version | head -n 1)
+
ifeq ($(config-targets),1)
# ===
# *config targets only - make sure prerequisites are updated, and descend
@@ -523,7 +527,7 @@ ifeq ($(config-targets),1)
# KBUILD_DEFCONFIG may point out an alternative default configuration
# used for 'make defconfig'
include arch/$(SRCARCH)/Makefile
-export KBUILD_DEFCONFIG KBUILD_KCONFIG
+export KBUILD_DEFCONFIG KBUILD_KCONFIG CC_VERSION_TEXT
config: scripts_basic outputmakefile FORCE
$(Q)$(MAKE) $(build)=scripts/kconfig $@
@@ -585,12 +589,32 @@ virt-y:= virt/
endif # KBUILD_EXTMOD
ifeq ($(dot-config),1)
-# Read in config
-include include/config/auto.conf
+endif
+
+# The all: target is the default when no target is given on the
+# command line.
+# This allow a user to issue only 'make' to build a kernel including modules
+# Defaults to vmlinux, but the arch makefile usually adds further targets
+all: vmlinux
+
+CFLAGS_GCOV:= -fprofile-arcs -ftest-coverage \
+ $(call cc-option,-fno-tree-loop-im) \
+ $(call cc-disable-warning,maybe-uninitialized,)
+export CFLAGS_GCOV CFLAGS_KCOV
+
+# The arch Makefile can set ARCH_{CPP,A,C}FLAGS to override the default
+# values of the respective KBUILD_* variables
+ARCH_CPPFLAGS :=
+ARCH_AFLAGS :=
+ARCH_CFLAGS :=
+include arch/$(SRCARCH)/Makefile
+ifeq ($(dot-config),1)
ifeq ($(KBUILD_EXTMOD),)
-# Read in dependencies to all Kconfig* files, make sure
Re: [PATCH v5 07/28] fpga: dfl: add chardev support for feature devices
On Thu, Jun 07, 2018 at 01:03:18PM -0500, Alan Tull wrote:
> On Wed, Jun 6, 2018 at 7:24 AM, Wu Hao wrote:
>
> Hi Hao,
>
> One more...
>
> >> > +static dev_t dfl_get_devt(enum dfl_fpga_devt_type type, int id)
> >> > +{
> >> > + WARN_ON(type >= DFL_FPGA_DEVT_MAX);
> >> > +
> >> > + return MKDEV(MAJOR(dfl_chrdevs[type].devt), id);
> >> > +}
> >> > +
> >> > +/**
> >> > + * dfl_fpga_register_dev_ops - register cdev ops for feature dev
> >> > + *
> >> > + * @pdev: feature dev.
> >> > + * @fops: file operations for feature dev's cdev.
> >> > + * @owner: owning module/driver.
> >> > + *
> >> > + * Return: 0 on success, negative error code otherwise.
> >> > + */
> >> > +int dfl_fpga_register_dev_ops(struct platform_device *pdev,
> >> > + const struct file_operations *fops,
> >> > + struct module *owner)
> >> > +{
> >> > + struct dfl_feature_platform_data *pdata =
> >> > dev_get_platdata(&pdev->dev);
> >> > +
> >> > + cdev_init(&pdata->cdev, fops);
> >> > + pdata->cdev.owner = owner;
> >> > +
> >> > + /*
> >> > +* set parent to the feature device so that its refcount is
> >> > +* decreased after the last refcount of cdev is gone, that
> >> > +* makes sure the feature device is valid during device
> >> > +* file's life-cycle.
> >> > +*/
> >> > + pdata->cdev.kobj.parent = &pdev->dev.kobj;
> >> > +
> >> > + return cdev_add(&pdata->cdev, pdev->dev.devt, 1);
> >> > +}
> >> > +EXPORT_SYMBOL_GPL(dfl_fpga_register_dev_ops);
> >> > +
> >> > +/**
> >> > + * dfl_fpga_unregister_dev_ops - unregister cdev ops for feature dev
> >> > + * @pdev: feature dev.
> >> > + */
> >> > +void dfl_fpga_unregister_dev_ops(struct platform_device *pdev)
> >> > +{
> >> > + struct dfl_feature_platform_data *pdata =
> >> > dev_get_platdata(&pdev->dev);
> >> > +
> >> > + cdev_del(&pdata->cdev);
> >> > +}
> >> > +EXPORT_SYMBOL_GPL(dfl_fpga_unregister_dev_ops);
>
> How about dfl_fpga_dev_ops_register/unregister?
Sure, will fix this in the v6. Thanks.
Hao
>
> Thanks,
> Alan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] HID: google: Add support for whiskers
Another device in the hammer class, with USB id 0x5030.
Signed-off-by: Nicolas Boichat
---
drivers/hid/hid-google-hammer.c | 2 ++
drivers/hid/hid-ids.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/hid/hid-google-hammer.c b/drivers/hid/hid-google-hammer.c
index 7b8e17b03cb86..6bf4da7ad63a5 100644
--- a/drivers/hid/hid-google-hammer.c
+++ b/drivers/hid/hid-google-hammer.c
@@ -124,6 +124,8 @@ static const struct hid_device_id hammer_devices[] = {
USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_STAFF) },
{ HID_DEVICE(BUS_USB, HID_GROUP_GENERIC,
USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_WAND) },
+ { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC,
+USB_VENDOR_ID_GOOGLE, USB_DEVICE_ID_GOOGLE_WHISKERS) },
{ }
};
MODULE_DEVICE_TABLE(hid, hammer_devices);
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index a85634fe033f0..c7981ddd87763 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -452,6 +452,7 @@
#define USB_DEVICE_ID_GOOGLE_TOUCH_ROSE0x5028
#define USB_DEVICE_ID_GOOGLE_STAFF 0x502b
#define USB_DEVICE_ID_GOOGLE_WAND 0x502d
+#define USB_DEVICE_ID_GOOGLE_WHISKERS 0x5030
#define USB_VENDOR_ID_GOTOP0x08f2
#define USB_DEVICE_ID_SUPER_Q2 0x007f
--
2.18.0.rc1.242.g61856ae69a-goog
Re: [PATCH 09/10] perf/cputime: Don't stop idle tick if there's live cputime event
On Thu, Jun 07, 2018 at 09:01:30AM -0700, Stephane Eranian wrote: > Hi Jiri, > > On Thu, Jun 7, 2018 at 8:45 AM Andi Kleen wrote: > > > > On Thu, Jun 07, 2018 at 12:15:12AM +0200, Jiri Olsa wrote: > > > Disable stopping of the idle tick when having live cputime > > > event. When the tick is disabled, the idle counts are out > > > of date until next tick/update and perf cputime PMU provides > > > misleading counts. > > > > I really don't like this. This can totally change performance > > (e.g. less Turbo due to less idle) and performance tools shouldn't > > change the performance profile drastically. > > > You do not want to change the behavior of the kernel just because you > are monitoring. > This may introduce side effects on other events which may not otherwise exist. right.. I guess we can survive few seconds of misleading idle counts and perhaps we could detect nohz is enabled and warn about this thanks, jirka
Re: [PATCH] uapi: Make generic uapi headers compile standalone.
On 06/06/2018 04:16 PM, Jayant Chowdhary wrote:
> In order for static analysis tools to analyze each of the uapi headers,
> we need to enable them to compile stand-alone. Some uapi headers were
> missing dependencies which would not make them compile stand-alone in
> user-land. This patch adds those dependencies.
Hi,
Thanks for getting started on this. I see that the kbuild robot and I were
still not able to do successful builds even after this patch is applied.
We were building different targets though. robot was doing kernel builds
and I was doing a large "all-uapi" build.
I started on my all-uapi work about 1 week ago but haven't posted anything yet,
but it's posted (attached) below. It's not yet up to kernel quality yet (for a
Makefile), and I have made very little progress toward a successful userspace
build.
If anyone is interested, just put these 3 files in /tools/build
and then run:
make ARCH=$some_arch O=build_dir headers_check
so that the headers will be cleaned up and installed in build_dir/usr/.
Then run 'make -f all-uapi.mk'
and the userspace program with all header files found in build_dir/usr/include
will be built -- i.e., attempted (not successfully).
(note: chmod +x hdr-fix-lines.pl)
--
~Randy
# all-uapi.mk
# currently resides in tools/build/
#
# before running 'make -f all-uapi.mk',
# run (from top of kernel tree): make ARCH=arch O=dir headers_check
# so that the uapi headers will be installed.
srctree=../..
CC=gcc
all: all-uapi.h all-uapi.o
all-uapi.h: all-uapi.mk hdr-fix-lines.pl
rm -f all-uapi.h
touch all-uapi.h
# find $(srctree)/xx64/usr/include/uapi -type f | grep -v \\.orig |
find $(srctree)/xx64/usr/include -type f | grep -v \\.orig | \
./hdr-fix-lines.pl >>all-uapi.h
all-uapi.o: all-uapi.h
$(CC) -I../../xx64/usr/include all-uapi.c -o all-uapi.o
// SPDX GPL 2.0
// This userspace source file pulls in all #include header files
// to see what kinds of problems happen.
#include
#include
#include
#include
#include
#include "all-uapi.h"
int main(int argc, char *argv[])
{
}
hdr-fix-lines.pl
Description: Perl program
Re: [PATCH 01/10] perf tools: Uniquify the event name if there's no other matched event
On Thu, Jun 07, 2018 at 09:09:10AM -0700, Stephane Eranian wrote: > On Wed, Jun 6, 2018 at 11:22 PM Jiri Olsa wrote: > > > > On Wed, Jun 06, 2018 at 04:19:02PM -0700, Andi Kleen wrote: > > > On Thu, Jun 07, 2018 at 12:15:04AM +0200, Jiri Olsa wrote: > > > > Currently by default we try to match the user specified PMU > > > > name to all PMU units available and use them to aggregate > > > > all matched PMUs event counts into one 'pattern' event. > > > > > > > > While this is useful for uncore events, it screws up names > > > > for other events, where this is not desirable, like: > > > > > > > > Before: > > > > # perf stat -e cp/cpu-cycles/ kill > > > > > > I assume you mean cpU/cpu-cycles/ > > > > > > > >Performance counter stats for 'kill': > > > > > > > >1,573,757 cp/cpu-cycles/ > > > > > > > > Keeping the pattern matching logic, but making the name unique > > > > in case there's no other match found. That fixes the example > > > > above and hopefully does not screw up anything else. > > > > > And the problem I have with this approach, is that you do not really > know what you are measuring. > You have not way of knowing that the count comes from multiple PMU instances: > > perf stat -a -e uncore_cb/clockticks/ kill > 0 uncore_cb/clockticks/ > > I think you need to report that this is aggregated from uncore_cbox_0 > and uncore_cbox_1. > Otherwise it is not clear what I am monitoring. And you hope that what > you match in the regex > is related. > In my example should say: > 0 uncore_cbox[0-1]/clockticks/ ok, makes sense.. also shouldnt be that hard to do.. will repost thanks, jirka
mmotm 2018-06-07-16-59 uploaded
The mm-of-the-moment snapshot 2018-06-07-16-59 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You will need quilt to apply these patches to the latest Linus release (4.x or 4.x-rcY). The series file is in broken-out.tar.gz and is duplicated in http://ozlabs.org/~akpm/mmotm/series The file broken-out.tar.gz contains two datestamp files: .DATE and .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, followed by the base kernel version against which this patch series is to be applied. This tree is partially included in linux-next. To see which patches are included in linux-next, consult the `series' file. Only the patches within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in linux-next. A git tree which contains the memory management portion of this tree is maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git by Michal Hocko. It contains the patches which are between the "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series file, http://www.ozlabs.org/~akpm/mmotm/series. A full copy of the full kernel tree with the linux-next and mmotm patches already applied is available through git within an hour of the mmotm release. Individual mmotm releases are tagged. The master branch always points to the latest release, so it's constantly rebasing. http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/ To develop on top of mmotm git: $ git remote add mmotm git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git $ git remote update mmotm $ git checkout -b topic mmotm/master $ git send-email mmotm/master.. [...] To rebase a branch with older patches to a new mmotm release: $ git remote update mmotm $ git rebase --onto mmotm/master topic The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second) contains daily snapshots of the -mm tree. It is updated more frequently than mmotm, and is untested. A git copy of this tree is available at http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/ and use of this tree is similar to http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above. This mmotm tree contains the following patches against 4.17: (patches marked "*" will be included in linux-next) origin.patch i-need-old-gcc.patch * fs-dax-adding-new-return-type-vm_fault_t.patch * scripts-use-spdx-tag-in-get_maintainer-and-checkpatch.patch * ocfs2-clean-up-redundant-function-declarations.patch * ocfs2-ocfs2_inode_lock_tracker-does-not-distinguish-lock-level.patch * ocfs2-eliminate-a-misreported-warning.patch * ocfs2-correct-the-comments-position-of-the-structure-ocfs2_dir_block_trailer.patch * ocfs2-drop-a-vla-in-ocfs2_orphan_del.patch * fs-ocfs2-adding-new-return-type-vm_fault_t.patch * net-9p-detecting-invalid-options-as-much-as-possible.patch * fs-9p-detecting-invalid-options-as-much-as-possible.patch * xen-9pfs-dont-inclide-rwlockh-directly.patch * slab-__gfp_zero-is-incompatible-with-a-constructor.patch * mm-slubc-add-__printf-verification-to-slab_err.patch * mm-slub-remove-impertinent-comment.patch * slab-clean-up-the-code-comment-in-slab-kmem_cache-struct.patch * mm-introduce-arg_lock-to-protect-arg_startend-and-env_startend-in-mm_struct.patch * mm-memcontrol-move-swap-charge-handling-into-get_swap_page.patch * mm-memcontrol-implement-memoryswapevents.patch * zram-correct-flag-name-of-zram_access.patch * zram-mark-incompressible-page-as-zram_huge.patch * zram-record-accessed-second.patch * zram-introduce-zram-memory-tracking.patch * mm-shmem-add-__rcu-annotations-and-properly-deref-radix-entry.patch * mm-shmem-update-file-sealing-comments-and-file-checking.patch * mm-restructure-memfd-code.patch * mm-page_alloc-remove-realsize-in-free_area_init_core.patch * mm-introduce-arch_has_pte_special.patch * mm-remove-odd-have_pte_special.patch * mm-memblock-introduce-phys_addr_max.patch * mm-rename-page_counters-count-limit-into-usage-max.patch * mm-memorylow-hierarchical-behavior.patch * mm-treat-memorylow-value-inclusive.patch * mm-docs-describe-memorylow-refinements.patch * mm-gup-prevent-pmd-checking-race-in-follow_pmd_mask.patch * mm-sparse-check-__highest_present_section_nr-only-for-a-present-section.patch * mm-sparse-pass-the-__highest_present_section_nr-1-to-alloc_func.patch * mm-vmalloc-clean-up-vunmap-to-avoid-pgtable-ops-twice.patch * mm-vmalloc-avoid-racy-handling-of-debugobjects-in-vunmap.patch * mm-vmalloc-pass-proper-vm_start-into-debugobjects.patch * mm-shmem-make-statst_blksize-return-huge-page-size-if-thp-is-on.patch * lockdep-fix-fs_reclaim-annotation.patch * mm-ksm-remove-unused-page_referenced_ksm-declaration.patch * mm-ksm-move-page_stable_node-from-ksmh-to-ksmc.patch * tmpfs-allow-decoding-a-file-handle-of-an-unlinked-file.patch * memcg-writeback-use-memcg-cgwb_list-d
[PATCH] regulator: Fix typo in comment of struct regulator_linear_range
regulator_map_linar_range() => regulator_map_linear_range()
Signed-off-by: Matthias Kaehlcke
---
include/linux/regulator/driver.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index 4fc96cb8e5d7..2dc4f575de17 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -44,7 +44,7 @@ enum regulator_status {
/**
* struct regulator_linear_range - specify linear voltage ranges
*
- * Specify a range of voltages for regulator_map_linar_range() and
+ * Specify a range of voltages for regulator_map_linear_range() and
* regulator_list_linear_range().
*
* @min_uV: Lowest voltage in range
--
2.18.0.rc1.242.g61856ae69a-goog
Re: [RFC] IB/mad: Use IDR instead of per-port list
On Thu, Jun 07, 2018 at 04:26:46PM -0600, Jason Gunthorpe wrote: > On Thu, Jun 07, 2018 at 12:08:32PM -0700, Matthew Wilcox wrote: > > > > Hans reports a bug where the mlx4 driver uses the MSB of the agent number > > to store slave number, meaning we can only use agent numbers up to 2^24. > > Fix this by using an IDR to assign the agent numbers and also look up the > > agent when a MSD packet is received. > > > > I've changed the locking substantially, so this may well have a > > performance issue. There are a few different possibilities for fixing > > that, including moving to an RCU-based lookup. > > I do like this better than the last series.. > > This are is somewhat performance sensitive and it would be nice to > avoid this global lock. OK, I wasn't sure whether it was worth it. > What about using a read/write spinlock instead of the IDR internal > lock? Then all the per-port reading threads calling find_mad_agent can > run concurrently.. It'd be better to switch to RCU ... the IDR is RCU-safe, but the version/class/method or OUI match isn't. Do you have any feeling on the relative frequency of the two types of "routing"? Actually, I think we can use the radix tree data structure for the version/class/method too ... that's going to take a little more work.
Re: sparse warnings in overflow.h
On Thu, Jun 07, 2018 at 09:25:09PM +0200, Rasmus Villemoes wrote: > > IIRC, the problem is that sparse pretends to be the gcc sparse itself > was built with, which is obviously entirely unrelated to the C dialect > that that particular sparse version groks. Sigh. Ack to the fix above. Yes, indeed, and it is sometimes a problem. Ideal would be that sparse would pretend to be same GCC as the one used to compile the code being checked *and* to have exactly the same features. Pretending to be an older version of GCC would maybe solve the present problem it's not really a general solution. One good thing would be to not depend on GCC versions to enable some features (but GCC offers few facilities helping here). Best regards, -- Luc Van Oostenryck
Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
On 14:05-20180605, Rob Herring wrote:
> On Tue, Jun 5, 2018 at 1:05 AM, Nishanth Menon wrote:
[...]
> > + soc0: soc0 {
> > + compatible = "simple-bus";
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
>
> Really need 64-bit addresses and sizes? Use ranges to limit the
> address space if possible.
Done -> overall the addresses are really in the 64bit addresses, but
used bus segments and ranges to reduce to 32bit maps where possible.
OSPI, PCIE, FSS (Flash subsystem) , CPTS are some of the ones that
probably will need some level of cleanups when those are introduced
later.
Unfortunately, there is a lot of interleaved addressing between bus
segments themselves, I have tried to keep the ranges as clean as
reasonably possible. I also tried to use 1-1 map for children nodes to
maintain some level of sanity as we add more device nodes. There might
be a few exceptions, but overall the ranges currently map 1-1 physical
32bit address - OSPI, CPTS, FSS will however have to have a different
mapping.
See [1]
>
> > +
> > + a53_timer0: timer-cl0-cpu0 {
> > + compatible = "arm,armv8-timer";
> > + interrupts = , /*
> > cntpsirq */
> > +, /*
> > cntpnsirq */
> > +, /*
> > cntvirq */
> > +; /*
> > cnthpirq */
> > + };
> > +
> > + pmu: pmu {
> > + compatible = "arm,armv8-pmuv3";
> > + /* Recommendation from GIC500 TRM Table A.3 */
> > + interrupts = ;
> > + };
>
> These 2 nodes aren't on the bus, so move them up a level.
Thanks. oversight on my end. I have fixed it (see [1])
>
> > +
> > + gic: interrupt-controller@180 {
> > + compatible = "arm,gic-v3";
>
> gic-500?
Yes, GIC500.
>
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
> > + #interrupt-cells = <3>;
> > + interrupt-controller;
> > + /*
> > +* NOTE: we are NOT gicv2 backward compat, so no
> > GICC,
> > +* GICH or GICV
>
> The compatible should imply this.
GIC500 at SoC design instantiation takes a parameter
"are_option" -> this is set to no-compatibility for V2 for AM6. This is indeed
discovered by the driver, However,
Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
just notes that GICC, GICH, GICV as optional.. With backward
compatibility disabled, these are'nt even present.
I have dropped the comment, was helpful for me when I was first
adding support for GIC500, It is pretty common knowledge now for other
ARMV8 developers, so no point in retaining newbie info as comment.
[...]
> > diff --git a/arch/arm64/boot/dts/ti/k3-am654.dtsi
> > b/arch/arm64/boot/dts/ti/k3-am654.dtsi
> > new file mode 100644
> > index ..d9b70081daba
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/ti/k3-am654.dtsi
> > @@ -0,0 +1,117 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Device Tree Source for AM6 SoC family in Quad core configuration
> > + *
> > + * Copyright (C) 2016-2018 Texas Instruments Incorporated -
> > http://www.ti.com/
> > + */
> > +
> > +#include "k3-am6.dtsi"
> > +
> > +/ {
> > + cpus: cpus {
>
> Really need a label?
Thanks. Dropped.
>
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + cpu-map {
>
> IIRC, this goes at the top level.
Documentation/devicetree/bindings/arm/topology.txt
States to keep in cpus node. Quote:
| The ARM CPU topology is defined within the cpu-map node, which is a direct
| child of the cpus node and provides a container where the actual topology
| nodes are listed.
Retained as is to stay in sync with binding.
> > + cpu0: cpu@0 {
> > + compatible = "arm,cortex-a53","arm,armv8";
>
> space between compatibles.
Oops. Fixed. thanks.
>
> > + reg = <0x000>;
> > + device_type = "cpu";
> > + enable-method = "psci";
>
> > + i-cache-size = <0x8000>;
> > + i-cache-line-size = <64>;
> > + i-cache-sets = <256>;
> > + d-cache-size = <0x8000>;
> > + d-cache-line-size = <64>;
> > + d-cache-sets = <128>;
>
> All this should be discoverable.
Unfortunately no.
Previously CCSIDR_EL1 was a good place to lookup this data.
But as Sudeep pointed me offline:
commit a8d4636f96ad ("arm64: cacheinfo: Remove CCSIDR-based cache information
probing")
and commit 9a802431c527 ("arm64: cacheinfo: add support to override cache
levels
Re: [PATCH v2] mm/ksm: ignore STABLE_FLAG of rmap_item->address in rmap_walk_ksm
On Thu, Jun 07, 2018 at 03:13:44PM -0700, Andrew Morton wrote: > This patch is quite urgent and is tagged for -stable backporting, yet > it remains in an unreviewed state. Any takers? It looks a straightforward safe fix, on x86 hva_to_gfn_memslot would zap those bits and hide the misalignment caused by the low metadata bits being erroneously left set in the address, but the arm code notices when that's the last page in the memslot and the hva_end is getting aligned and the size is below one page. > [35380.933345] [] dump_backtrace+0x0/0x22c > [35380.938723] [] show_stack+0x24/0x2c > [35380.943759] [] dump_stack+0x8c/0xb0 > [35380.948794] [] bad_page+0xf4/0x154 > [35380.953740] [] free_pages_check_bad+0x90/0x9c > [35380.959642] [] free_pcppages_bulk+0x464/0x518 > [35380.965545] [] free_hot_cold_page+0x22c/0x300 > [35380.971448] [] __put_page+0x54/0x60 > [35380.976484] [] unmap_stage2_range+0x170/0x2b4 > [35380.982385] [] kvm_unmap_hva_handler+0x30/0x40 > [35380.988375] [] handle_hva_to_gpa+0xb0/0xec > [35380.994016] [] kvm_unmap_hva_range+0x5c/0xd0 > [35380.999833] [] > > I even injected a fault on purpose in kvm_unmap_hva_range by seting > size=size-0x200, the call trace is similar as above. So I thought the > panic is similarly caused by the root cause of WARN_ON. I think the problem triggers in the addr += PAGE_SIZE of unmap_stage2_ptes that never matches end because end is aligned but addr is not. } while (pte++, addr += PAGE_SIZE, addr != end); x86 again only works on hva_start/hva_end after converting it to gfn_start/end and that being in pfn units the bits are zapped before they risk to cause trouble. > > Link: > http://lkml.kernel.org/r/1525403506-6750-1-git-send-email-hejia...@gmail.com > Signed-off-by: Jia He > Cc: Suzuki K Poulose > Cc: Andrea Arcangeli > Cc: Minchan Kim > Cc: Claudio Imbrenda > Cc: Arvind Yadav > Cc: Mike Rapoport > Cc: Jia He > Cc: > Signed-off-by: Andrew Morton > --- > Reviewed-by: Andrea Arcangeli
[PATCH] kvm: fix typo in flag name
KVM_X86_DISABLE_EXITS_HTL really refers to exit on halt.
Obviously a typo: should be named KVM_X86_DISABLE_EXITS_HLT.
Fixes: caa057a2cad ("KVM: X86: Provide a capability to disable HLT intercepts")
Cc: sta...@vger.kernel.org
Signed-off-by: Michael S. Tsirkin
---
arch/x86/kvm/x86.c | 4 ++--
include/uapi/linux/kvm.h | 4 ++--
tools/include/uapi/linux/kvm.h | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 71e7cda6d014..dcc64e7d946d 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2894,7 +2894,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long
ext)
r = KVM_CLOCK_TSC_STABLE;
break;
case KVM_CAP_X86_DISABLE_EXITS:
- r |= KVM_X86_DISABLE_EXITS_HTL | KVM_X86_DISABLE_EXITS_PAUSE;
+ r |= KVM_X86_DISABLE_EXITS_HLT | KVM_X86_DISABLE_EXITS_PAUSE;
if(kvm_can_mwait_in_guest())
r |= KVM_X86_DISABLE_EXITS_MWAIT;
break;
@@ -4248,7 +4248,7 @@ static int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
if ((cap->args[0] & KVM_X86_DISABLE_EXITS_MWAIT) &&
kvm_can_mwait_in_guest())
kvm->arch.mwait_in_guest = true;
- if (cap->args[0] & KVM_X86_DISABLE_EXITS_HTL)
+ if (cap->args[0] & KVM_X86_DISABLE_EXITS_HLT)
kvm->arch.hlt_in_guest = true;
if (cap->args[0] & KVM_X86_DISABLE_EXITS_PAUSE)
kvm->arch.pause_in_guest = true;
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index b02c41e53d56..39e364c70caf 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -677,10 +677,10 @@ struct kvm_ioeventfd {
};
#define KVM_X86_DISABLE_EXITS_MWAIT (1 << 0)
-#define KVM_X86_DISABLE_EXITS_HTL(1 << 1)
+#define KVM_X86_DISABLE_EXITS_HLT(1 << 1)
#define KVM_X86_DISABLE_EXITS_PAUSE (1 << 2)
#define KVM_X86_DISABLE_VALID_EXITS (KVM_X86_DISABLE_EXITS_MWAIT | \
- KVM_X86_DISABLE_EXITS_HTL | \
+ KVM_X86_DISABLE_EXITS_HLT | \
KVM_X86_DISABLE_EXITS_PAUSE)
/* for KVM_ENABLE_CAP */
diff --git a/tools/include/uapi/linux/kvm.h b/tools/include/uapi/linux/kvm.h
index b02c41e53d56..39e364c70caf 100644
--- a/tools/include/uapi/linux/kvm.h
+++ b/tools/include/uapi/linux/kvm.h
@@ -677,10 +677,10 @@ struct kvm_ioeventfd {
};
#define KVM_X86_DISABLE_EXITS_MWAIT (1 << 0)
-#define KVM_X86_DISABLE_EXITS_HTL(1 << 1)
+#define KVM_X86_DISABLE_EXITS_HLT(1 << 1)
#define KVM_X86_DISABLE_EXITS_PAUSE (1 << 2)
#define KVM_X86_DISABLE_VALID_EXITS (KVM_X86_DISABLE_EXITS_MWAIT | \
- KVM_X86_DISABLE_EXITS_HTL | \
+ KVM_X86_DISABLE_EXITS_HLT | \
KVM_X86_DISABLE_EXITS_PAUSE)
/* for KVM_ENABLE_CAP */
--
MST
[PATCH] NTB: ntb_tool: reading the link file should not end in a NULL byte
When running ntb_test this warning is issued:
./ntb_test.sh: line 200: warning: command substitution: ignored null
byte in input
This is caused by the kernel returning one more byte than is necessary
when reading the link file.
Reduce the number of bytes read back to 2 as it was before the
commit that regressed this.
Signed-off-by: Logan Gunthorpe
Fixes: 7f46c8b3a552 ("NTB: ntb_tool: Add full multi-port NTB API
support")
---
drivers/ntb/test/ntb_tool.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/ntb/test/ntb_tool.c b/drivers/ntb/test/ntb_tool.c
index d592c0ffbd19..ec5cf095cdb9 100644
--- a/drivers/ntb/test/ntb_tool.c
+++ b/drivers/ntb/test/ntb_tool.c
@@ -504,7 +504,7 @@ static ssize_t tool_peer_link_read(struct file *filep, char
__user *ubuf,
buf[1] = '\n';
buf[2] = '\0';
- return simple_read_from_buffer(ubuf, size, offp, buf, 3);
+ return simple_read_from_buffer(ubuf, size, offp, buf, 2);
}
static TOOL_FOPS_RDWR(tool_peer_link_fops,
@@ -1690,4 +1690,3 @@ static void __exit tool_exit(void)
debugfs_remove_recursive(tool_dbgfs_topdir);
}
module_exit(tool_exit);
-
--
2.11.0
[PATCH] ARM: spectre-v2: Try to set IBE bit for Cortex-A15 and Brahma-B15
Per the ARM reference manual for the Cortex-A15, The ACTLR: Is a read/write register. Common to the Secure and Non-secure states. Is only accessible from PL1 or higher, with access rights that depend on the mode: * Read/write in Secure PL1 modes. * Read-only and write-ignored in Non-secure PL1 and PL2 modes if NSACR.NS_SMP is 0. * Read/write in Non-secure PL1 and PL2 modes if NSACR.NS_SMP is 1. In this case, all bits are write-ignored except for the SMP bit. We can attempt to set this bit from within the kernel, which helps avoiding firmware side modifications to set the IBE bit when that is impractical. We do this within __v7_ca15mp_setup and __v7_b15mp_setup because by then we already took those labels because the processors we run on do match. Signed-off-by: Florian Fainelli --- arch/arm/mm/proc-v7.S | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S index 6fe52819e014..a21cf3729efa 100644 --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -284,10 +284,16 @@ __v7_cr8mp_setup: b 1f __v7_ca7mp_setup: __v7_ca12mp_setup: + b 2f __v7_ca15mp_setup: __v7_b15mp_setup: +#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR + mrc p15, 0, r0, c1, c0, 1 + orr r0, r0, #1 @ Enable IBE bit + mcr p15, 0, r0, c1, c0, 1 +#endif __v7_ca17mp_setup: - mov r10, #0 +2: mov r10, #0 1: adr r0, __v7_setup_stack_ptr ldr r12, [r0] add r12, r12, r0@ the local stack -- 2.14.1
Re: [PATCH v4 3/4] mm/sparse: Add a new parameter 'data_unit_size' for alloc_usemap_and_memmap
On 05/21/2018 03:15 AM, Baoquan He wrote: > It's used to pass the size of map data unit into alloc_usemap_and_memmap, > and is preparation for next patch. This is the "what", but not the "why". Could you add another sentence or two to explain why we need this?
Re: [PATCH v4 2/4] mm/sparsemem: Defer the ms->section_mem_map clearing
On 05/21/2018 03:15 AM, Baoquan He wrote: > In sparse_init(), if CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y, system > will allocate one continuous memory chunk for mem maps on one node and > populate the relevant page tables to map memory section one by one. If > fail to populate for a certain mem section, print warning and its > ->section_mem_map will be cleared to cancel the marking of being present. > Like this, the number of mem sections marked as present could become > less during sparse_init() execution. > > Here just defer the ms->section_mem_map clearing if failed to populate > its page tables until the last for_each_present_section_nr() loop. This > is in preparation for later optimizing the mem map allocation. > > Signed-off-by: Baoquan He Acked-By: Dave Hansen
Re: [PATCH v4 1/4] mm/sparse: Add a static variable nr_present_sections
On 05/21/2018 03:15 AM, Baoquan He wrote: > It's used to record how many memory sections are marked as present > during system boot up, and will be used in the later patch. > > Signed-off-by: Baoquan He I think this is fine: Acked-By: Dave Hansen
Re: [PATCH v4 4/4] mm/sparse: Optimize memmap allocation during sparse_init()
> @@ -297,8 +298,8 @@ void __init sparse_mem_maps_populate_node(struct page
> **map_map,
> if (!present_section_nr(pnum))
> continue;
>
> - map_map[pnum] = sparse_mem_map_populate(pnum, nodeid, NULL);
> - if (map_map[pnum])
> + map_map[nr_consumed_maps] = sparse_mem_map_populate(pnum,
> nodeid, NULL);
> + if (map_map[nr_consumed_maps++])
> continue;
...
This looks wonky.
This seems to say that even if we fail to sparse_mem_map_populate() (it
returns NULL), we still consume a map. Is that right?
> /* fallback */
> + nr_consumed_maps = 0;
> for (pnum = pnum_begin; pnum < pnum_end; pnum++) {
> struct mem_section *ms;
>
> if (!present_section_nr(pnum))
> continue;
> - map_map[pnum] = sparse_mem_map_populate(pnum, nodeid, NULL);
> - if (map_map[pnum])
> + map_map[nr_consumed_maps] = sparse_mem_map_populate(pnum,
> nodeid, NULL);
> + if (map_map[nr_consumed_maps++])
> continue;
Same questionable pattern as above...
> #ifdef CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER
> - size2 = sizeof(struct page *) * NR_MEM_SECTIONS;
> + size2 = sizeof(struct page *) * nr_present_sections;
> map_map = memblock_virt_alloc(size2, 0);
> if (!map_map)
> panic("can not allocate map_map\n");
> @@ -586,27 +594,44 @@ void __init sparse_init(void)
> sizeof(map_map[0]));
> #endif
>
> + /* The numner of present sections stored in nr_present_sections
"number"?
Also, this is not correct comment CodingStyle.
> + * are kept the same since mem sections are marked as present in
> + * memory_present().
Are you just trying to say that we are not making sections present here?
> In this for loop, we need check which sections
> + * failed to allocate memmap or usemap, then clear its
> + * ->section_mem_map accordingly. During this process, we need
> + * increase 'alloc_usemap_and_memmap' whether its allocation of
> + * memmap or usemap failed or not, so that after we handle the i-th
> + * memory section, can get memmap and usemap of (i+1)-th section
> + * correctly. */
I'm really scratching my head over this comment. For instance "increase
'alloc_usemap_and_memmap'" doesn't make any sense to me. How do you
increase a function?
I wonder if you could give that comment another shot.
Re: [PATCH] uapi: Make generic uapi headers compile standalone.
Hi Jayant, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.17 next-20180607] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jayant-Chowdhary/uapi-Make-generic-uapi-headers-compile-standalone/20180608-014548 reproduce: # apt-get install sparse make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) drivers/gpu/drm/radeon/cik.c:6721:25: sparse: incorrect type in assignment (different base types) @@expected unsigned int volatile [unsigned] [usertype] @@got latile [unsigned] [usertype] @@ drivers/gpu/drm/radeon/cik.c:6721:25:expected unsigned int volatile [unsigned] [usertype] drivers/gpu/drm/radeon/cik.c:6721:25:got restricted __le32 [usertype] drivers/gpu/drm/radeon/cik.c:6722:25: sparse: incorrect type in assignment (different base types) @@expected unsigned int volatile [unsigned] [usertype] @@got latile [unsigned] [usertype] @@ drivers/gpu/drm/radeon/cik.c:6722:25:expected unsigned int volatile [unsigned] [usertype] drivers/gpu/drm/radeon/cik.c:6722:25:got restricted __le32 [usertype] drivers/gpu/drm/radeon/cik.c:6724:25: sparse: incorrect type in assignment (different base types) @@expected unsigned int volatile [unsigned] [usertype] @@got latile [unsigned] [usertype] @@ drivers/gpu/drm/radeon/cik.c:6724:25:expected unsigned int volatile [unsigned] [usertype] drivers/gpu/drm/radeon/cik.c:6724:25:got restricted __le32 [usertype] drivers/gpu/drm/radeon/cik.c:6725:25: sparse: incorrect type in assignment (different base types) @@expected unsigned int volatile [unsigned] [usertype] @@got latile [unsigned] [usertype] @@ drivers/gpu/drm/radeon/cik.c:6725:25:expected unsigned int volatile [unsigned] [usertype] drivers/gpu/drm/radeon/cik.c:6725:25:got restricted __le32 [usertype] drivers/gpu/drm/radeon/cik.c:6726:25: sparse: incorrect type in assignment (different base types) @@expected unsigned int volatile [unsigned] [usertype] @@got latile [unsigned] [usertype] @@ drivers/gpu/drm/radeon/cik.c:6726:25:expected unsigned int volatile [unsigned] [usertype] drivers/gpu/drm/radeon/cik.c:6726:25:got restricted __le32 [usertype] drivers/gpu/drm/radeon/cik.c:6731:49: sparse: incorrect type in assignment (different base types) @@expected unsigned int volatile [unsigned] [usertype] @@got latile [unsigned] [usertype] @@ drivers/gpu/drm/radeon/cik.c:6731:49:expected unsigned int volatile [unsigned] [usertype] drivers/gpu/drm/radeon/cik.c:6731:49:got restricted __le32 [usertype] drivers/gpu/drm/radeon/cik.c:6733:49: sparse: incorrect type in assignment (different base types) @@expected unsigned int volatile [unsigned] [usertype] @@got latile [unsigned] [usertype] @@ drivers/gpu/drm/radeon/cik.c:6733:49:expected unsigned int volatile [unsigned] [usertype] drivers/gpu/drm/radeon/cik.c:6733:49:got restricted __le32 [usertype] drivers/gpu/drm/radeon/cik.c:6735:57: sparse: incorrect type in assignment (different base types) @@expected unsigned int volatile [unsigned] [usertype] @@got latile [unsigned] [usertype] @@ drivers/gpu/drm/radeon/cik.c:6735:57:expected unsigned int volatile [unsigned] [usertype] drivers/gpu/drm/radeon/cik.c:6735:57:got restricted __le32 [usertype] drivers/gpu/drm/radeon/cik.c:6742:25: sparse: incorrect type in assignment (different base types) @@expected unsigned int volatile [unsigned] [usertype] @@got latile [unsigned] [usertype] @@ drivers/gpu/drm/radeon/cik.c:6742:25:expected unsigned int volatile [unsigned] [usertype] drivers/gpu/drm/radeon/cik.c:6742:25:got restricted __le32 [usertype] drivers/gpu/drm/radeon/cik.c:6743:25: sparse: incorrect type in assignment (different base types) @@expected unsigned int volatile [unsigned] [usertype] @@got latile [unsigned] [usertype] @@ drivers/gpu/drm/radeon/cik.c:6743:25:expected unsigned int volatile [unsigned] [usertype] drivers/gpu/drm/radeon/cik.c:6743:25:got restricted __le32 [usertype] drivers/gpu/drm/radeon/cik.c:6746:33: sparse: incorrect type in assignment (different base types) @@expected unsigned int volatile [unsigned] [usertype] @@got latile [unsigned] [usertype] @@ drivers/gpu/drm/radeon/cik.c:6746:33:expected unsigned int volatile [unsigned] [usertype] drivers/gpu/drm/radeon/cik.c:6746:33:got restricted __le32 [usertype] drivers/gpu/drm/radeon/cik.c:6747:33: sparse: incorrect type in assignment (different base types) @@expected unsigned int volatile [unsigned] [usertype] @@got latile [unsigned] [us
Re: [RFC] IB/mad: Use IDR instead of per-port list
On Thu, Jun 07, 2018 at 12:08:32PM -0700, Matthew Wilcox wrote: > > Hans reports a bug where the mlx4 driver uses the MSB of the agent number > to store slave number, meaning we can only use agent numbers up to 2^24. > Fix this by using an IDR to assign the agent numbers and also look up the > agent when a MSD packet is received. > > I've changed the locking substantially, so this may well have a > performance issue. There are a few different possibilities for fixing > that, including moving to an RCU-based lookup. I do like this better than the last series.. This are is somewhat performance sensitive and it would be nice to avoid this global lock. What about using a read/write spinlock instead of the IDR internal lock? Then all the per-port reading threads calling find_mad_agent can run concurrently.. Thanks, Jason
Re: [PATCH 3/3] x86/mce: Check for alternate indication of machine check recovery on Skylake
On Thu, Jun 07, 2018 at 10:24:46PM +0200, Borislav Petkov wrote: > On Thu, Jun 07, 2018 at 01:18:31PM -0700, Dan Williams wrote: > > I'm making an effort to get all persistent memory error handling holes > > covered this cycle, so I think it makes sense for this to go through > > the nvdimm tree. This looks sufficiently non-controversial that I > > could justify sending it to Linus along with the other pmem updates. > > tglx just took 1 and 3, 2/3 had a minor issue but the merge window > happened so I'll send it later. It is nice to have anyway. Thanks Boris. -Tony
Re: [PATCH v4 0/4] mm/sparse: Optimize memmap allocation during sparse_init()
On Mon, 21 May 2018 18:15:51 +0800 Baoquan He wrote: > This is v4 post. V3 can be found here: > https://lkml.org/lkml/2018/2/27/928 > > V1 can be found here: > https://www.spinics.net/lists/linux-mm/msg144486.html > > In sparse_init(), two temporary pointer arrays, usemap_map and map_map > are allocated with the size of NR_MEM_SECTIONS. They are used to store > each memory section's usemap and mem map if marked as present. In > 5-level paging mode, this will cost 512M memory though they will be > released at the end of sparse_init(). System with few memory, like > kdump kernel which usually only has about 256M, will fail to boot > because of allocation failure if CONFIG_X86_5LEVEL=y. > > In this patchset, optimize the memmap allocation code to only use > usemap_map and map_map with the size of nr_present_sections. This > makes kdump kernel boot up with normal crashkernel='' setting when > CONFIG_X86_5LEVEL=y. We're still a bit short on review input for this series. Hi, Dave!
Re: [PATCH v2] mm/ksm: ignore STABLE_FLAG of rmap_item->address in rmap_walk_ksm
On Thu, 24 May 2018 13:38:05 -0700 Andrew Morton wrote: > > > > Jia, Andrew, > > > > What is the status of this patch ? > > > > I have it scheduled for 4.18-rc1, with a cc:stable for backporting. > > I'd normally put such a fix into 4.17-rcX but I'd like to give Hugh > time to review it and to generally give it a bit more time for review > and test. > > Have you tested it yourself? I'll take your silence as a no. This patch is quite urgent and is tagged for -stable backporting, yet it remains in an unreviewed state. Any takers? From: Jia He Subject: mm/ksm.c: ignore STABLE_FLAG of rmap_item->address in rmap_walk_ksm() In our armv8a server(QDF2400), I noticed lots of WARN_ON caused by PAGE_SIZE unaligned for rmap_item->address under memory pressure tests(start 20 guests and run memhog in the host). --begin-- [ 410.853828] WARNING: CPU: 4 PID: 4641 at arch/arm64/kvm/../../../virt/kvm/arm/mmu.c:1826 kvm_age_hva_handler+0xc0/0xc8 [ 410.864518] Modules linked in: vhost_net vhost tap xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 ip6t_rpfilter ipt_REJECT nf_reject_ipv4 ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter rpcrdma ib_isert iscsi_target_mod ib_iser libiscsi scsi_transport_iscsi ib_srpt target_core_mod ib_srp scsi_transport_srp ib_ipoib rdma_ucm ib_ucm ib_umad rdma_cm ib_cm iw_cm mlx5_ib vfat fat ib_uverbs dm_mirror dm_region_hash ib_core dm_log dm_mod crc32_ce ipmi_ssif sg nfsd [ 410.935101] auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c mlx5_core ixgbe mlxfw devlink mdio ahci_platform libahci_platform qcom_emac libahci hdma hdma_mgmt i2c_qup [ 410.951369] CPU: 4 PID: 4641 Comm: memhog Tainted: GW 4.17.0-rc3+ #8 [ 410.959104] Hardware name: [ 410.969791] pstate: 8045 (Nzcv daif +PAN -UAO) [ 410.974575] pc : kvm_age_hva_handler+0xc0/0xc8 [ 410.979012] lr : handle_hva_to_gpa+0xa8/0xe0 [ 410.983274] sp : 801761553290 [ 410.986581] x29: 801761553290 x28: [ 410.991888] x27: 0002 x26: [ 410.997195] x25: 801765430058 x24: 080b5608 [ 411.002501] x23: x22: 8017ccb84000 [ 411.007807] x21: 03ff x20: 8017ccb84000 [ 411.013113] x19: fe00 x18: 08fb3c08 [ 411.018419] x17: x16: 0060001645820bd3 [ 411.023725] x15: 80176aacbc08 x14: [ 411.029031] x13: 0040 x12: 0228 [ 411.034337] x11: x10: [ 411.039643] x9 : 0010 x8 : 0004 [ 411.044949] x7 : x6 : 8017f077 [ 411.050255] x5 : fffda59f0200 x4 : [ 411.055561] x3 : x2 : fe00 [ 411.060867] x1 : 03ff x0 : 2000 [ 411.066173] Call trace: [ 411.068614] kvm_age_hva_handler+0xc0/0xc8 [ 411.072703] handle_hva_to_gpa+0xa8/0xe0 [ 411.076619] kvm_age_hva+0x4c/0xe8 [ 411.080014] kvm_mmu_notifier_clear_flush_young+0x54/0x98 [ 411.085408] __mmu_notifier_clear_flush_young+0x6c/0xa0 [ 411.090627] page_referenced_one+0x154/0x1d8 [ 411.094890] rmap_walk_ksm+0x12c/0x1d0 [ 411.098632] rmap_walk+0x94/0xa0 [ 411.101854] page_referenced+0x194/0x1b0 [ 411.105770] shrink_page_list+0x674/0xc28 [ 411.109772] shrink_inactive_list+0x26c/0x5b8 [ 411.114122] shrink_node_memcg+0x35c/0x620 [ 411.118211] shrink_node+0x100/0x430 [ 411.121778] do_try_to_free_pages+0xe0/0x3a8 [ 411.126041] try_to_free_pages+0xe4/0x230 [ 411.130045] __alloc_pages_nodemask+0x564/0xdc0 [ 411.134569] alloc_pages_vma+0x90/0x228 [ 411.138398] do_anonymous_page+0xc8/0x4d0 [ 411.142400] __handle_mm_fault+0x4a0/0x508 [ 411.146489] handle_mm_fault+0xf8/0x1b0 [ 411.150321] do_page_fault+0x218/0x4b8 [ 411.154064] do_translation_fault+0x90/0xa0 [ 411.158239] do_mem_abort+0x68/0xf0 [ 411.161721] el0_da+0x24/0x28 ---end--- In rmap_walk_ksm, the rmap_item->address might still have the STABLE_FLAG, then the start and end in handle_hva_to_gpa might not be PAGE_SIZE aligned. Thus it will cause exceptions in handle_hva_to_gpa on arm64. This patch fixes it by ignoring (not removing) the low bits of address when doing rmap_walk_ksm. IMO, it should be backported to stable tree. the stom of WARN_ONs is very easy for me to reproduce. More than that, I watched a panic (not reproducible) as follows: [35380.805825] page:7fe003742d80 count:-4871 mapcount:-2126053375 mapping: (null) index:0x0 [35380.815024] flags: 0x1fffc000() [
Hello Dear
Hello Fellow Charles Koch here, ceo charles koch foundation worldwide (the largest charity foundation in the world). This year under our motto of "Give while living", i and the foundation have decided to award $500,000.00 to a few selected lucky individuals and on receipt of this email kindly get back to me. Regards, Charles Koch. chkoch2...@dbzmail.com
Re: [PATCH v4 05/14] coresight: get/put module in coresight_build/release_path
On 7 June 2018 at 15:47, Kim Phillips wrote: > On Thu, 7 Jun 2018 22:10:07 +0100 > Suzuki K Poulose wrote: > >> On 06/07/2018 06:13 PM, Kim Phillips wrote: >> > I'm going to assume the series is still valid after this discussion, >> > since technically just this patch can get dropped, and the user is able >> > to shoot themselves in the foot. >> >> That doesn't mean the kernel can panic() if the user decided to unload >> the module while the trace session is in progress. It only means that >> the trace session could be stopped in between in the worst case. But >> nothing more harmful to the system. > > FWIW, I didn't see the kernel panic in my basic tests; just some bad > accesses: the new remove functions take care of cleaning up most items, > and most drivers still depend on the links and sinks (funnel, > replicator) drivers, so they can't be upset too bad. > >> > This series is for development purposes, after all. >> >> Do you mean that this series is for internal development purposes and >> not upstream ? Making the drivers modular are always helpful, especially > > no, I'm posting them for upstream review because I'd like them upstream. > >> for something related to tracing, that allows the module to be unloaded >> after use. So, it would be good to have this series in, but in a manner >> which is usable and doesn't cause harm to the overall system usage. >> >> I think the summary of the discussion is that we need more robust code >> to handle the situation, which also allows unloading the modules without >> any trouble. > > Trouble's relative. My point was since the series is going to be used > mainly by developers testing their code, they already prepare for, and > expect badness to occur anyway. Greg's point isn't lost here, and in > my interpretation, his review of this patch was that it was in the > wrong direction of safety: it made things unnecessarily too safe, up > front, and that items relative to the perf core should strive to adhere > to the higher standards set in place by the networking subsystem. So, > this patch doesn't get his ack. Greg's point was that it's OK to let users harm themselves (which I totally support), but if you're going to prevent it, make sure to do it right. > > I compiled a new v5 series that omits this patch, and overwrote the v4 > series here: > > git://linux-arm.org/linux-kp.git, coresight-modules branch > > but I'll hold of submitting a v5 for now. > > I don't know how the perf core handles AUXTRACE drivers hanging up on > it. I see intel-pt record support can't be built as a module. I'm > guessing more testing for actual panics when using perf or sysfs is > what's being sought here? There are two ways to approach the problem: 1) Kill active trace sessions (either sysFS or perf) if a driver that is being used is removed. 2) Deal with the removal in the coresight core, making sure we don't access operations provided by removed drivers. The end result in both cases will be the same: failure to properly terminate the trace session because of user action. I'm personally in favour of the second option, simply because it keeps problems resolution with the CS subsystem. > > Kim
Re: [PATCH v4 05/14] coresight: get/put module in coresight_build/release_path
On Thu, 7 Jun 2018 22:10:07 +0100 Suzuki K Poulose wrote: > On 06/07/2018 06:13 PM, Kim Phillips wrote: > > I'm going to assume the series is still valid after this discussion, > > since technically just this patch can get dropped, and the user is able > > to shoot themselves in the foot. > > That doesn't mean the kernel can panic() if the user decided to unload > the module while the trace session is in progress. It only means that > the trace session could be stopped in between in the worst case. But > nothing more harmful to the system. FWIW, I didn't see the kernel panic in my basic tests; just some bad accesses: the new remove functions take care of cleaning up most items, and most drivers still depend on the links and sinks (funnel, replicator) drivers, so they can't be upset too bad. > > This series is for development purposes, after all. > > Do you mean that this series is for internal development purposes and > not upstream ? Making the drivers modular are always helpful, especially no, I'm posting them for upstream review because I'd like them upstream. > for something related to tracing, that allows the module to be unloaded > after use. So, it would be good to have this series in, but in a manner > which is usable and doesn't cause harm to the overall system usage. > > I think the summary of the discussion is that we need more robust code > to handle the situation, which also allows unloading the modules without > any trouble. Trouble's relative. My point was since the series is going to be used mainly by developers testing their code, they already prepare for, and expect badness to occur anyway. Greg's point isn't lost here, and in my interpretation, his review of this patch was that it was in the wrong direction of safety: it made things unnecessarily too safe, up front, and that items relative to the perf core should strive to adhere to the higher standards set in place by the networking subsystem. So, this patch doesn't get his ack. I compiled a new v5 series that omits this patch, and overwrote the v4 series here: git://linux-arm.org/linux-kp.git, coresight-modules branch but I'll hold of submitting a v5 for now. I don't know how the perf core handles AUXTRACE drivers hanging up on it. I see intel-pt record support can't be built as a module. I'm guessing more testing for actual panics when using perf or sysfs is what's being sought here? Kim
Re: [PATCH v4 14/14] coresight: allow the coresight core driver to be built as a module
On 5 June 2018 at 15:07, Kim Phillips wrote:
> Allow to build coresight as a module. This enhances
> coresight developer efficiency by allowing the development to
> take place exclusively on the target, and without needing to
> reboot in between changes.
>
> - Kconfig becomes a tristate, to allow =m
> - append -core to source file name to allow module to
> be called coresight by the Makefile
> - modules can have only one init/exit, so we add the core bus
> register/unregister function calls to the etm_perf init/exit
> functions, since coresight.c does not have etm_pmu defined.
> - add a MODULE_DEVICE_TABLE for autoloading on boot
>
> Cc: Mathieu Poirier
> Cc: Leo Yan
> Cc: Alexander Shishkin
> Cc: Randy Dunlap
> Cc: Suzuki K Poulose
> Cc: Greg Kroah-Hartman
> Cc: Russell King
> Signed-off-by: Kim Phillips
> ---
> drivers/hwtracing/coresight/Kconfig | 5 -
> drivers/hwtracing/coresight/Makefile| 7 +--
> .../coresight/{coresight.c => coresight-core.c} | 6 --
> .../hwtracing/coresight/coresight-etm-perf.c| 17 -
> 4 files changed, 25 insertions(+), 10 deletions(-)
> rename drivers/hwtracing/coresight/{coresight.c => coresight-core.c} (99%)
>
> diff --git a/drivers/hwtracing/coresight/Kconfig
> b/drivers/hwtracing/coresight/Kconfig
> index 181a44ea2d61..c05b265f7731 100644
> --- a/drivers/hwtracing/coresight/Kconfig
> +++ b/drivers/hwtracing/coresight/Kconfig
> @@ -2,7 +2,7 @@
> # Coresight configuration
> #
> menuconfig CORESIGHT
> - bool "CoreSight Tracing Support"
> + tristate "CoreSight Tracing Support"
> select ARM_AMBA
> select PERF_EVENTS
> help
> @@ -12,6 +12,9 @@ menuconfig CORESIGHT
> specification and configure the right series of components when a
> trace source gets enabled.
>
> + To compile this driver as a module, choose M here: the
> + module will be called coresight.
> +
> if CORESIGHT
> config CORESIGHT_LINKS_AND_SINKS
> tristate "CoreSight Link and Sink drivers"
> diff --git a/drivers/hwtracing/coresight/Makefile
> b/drivers/hwtracing/coresight/Makefile
> index 45d7a0f34170..ed2d4bcb017b 100644
> --- a/drivers/hwtracing/coresight/Makefile
> +++ b/drivers/hwtracing/coresight/Makefile
> @@ -2,8 +2,11 @@
> #
> # Makefile for CoreSight drivers.
> #
> -obj-$(CONFIG_CORESIGHT) += coresight.o coresight-etm-perf.o
> -obj-$(CONFIG_OF) += of_coresight.o
> +obj-$(CONFIG_CORESIGHT) += coresight.o
> +coresight-objs := coresight-core.o coresight-etm-perf.o
> +ifeq ($(CONFIG_OF), y)
> +coresight-objs += of_coresight.o
> +endif
> obj-$(CONFIG_CORESIGHT_LINK_AND_SINK_TMC) += coresight-tmc.o
> coresight-tmc-objs := coresight-tmc-core.o coresight-tmc-etf.o \
> coresight-tmc-etr.o
> diff --git a/drivers/hwtracing/coresight/coresight.c
> b/drivers/hwtracing/coresight/coresight-core.c
> similarity index 99%
> rename from drivers/hwtracing/coresight/coresight.c
> rename to drivers/hwtracing/coresight/coresight-core.c
> index 1c941351f1d1..f96258de1e9b 100644
> --- a/drivers/hwtracing/coresight/coresight.c
> +++ b/drivers/hwtracing/coresight/coresight-core.c
> @@ -948,12 +948,6 @@ struct bus_type coresight_bustype = {
> .name = "coresight",
> };
>
> -static int __init coresight_init(void)
> -{
> - return bus_register(&coresight_bustype);
> -}
> -postcore_initcall(coresight_init);
> -
> struct coresight_device *coresight_register(struct coresight_desc *desc)
> {
> int i;
> diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c
> b/drivers/hwtracing/coresight/coresight-etm-perf.c
> index 0fe7e43ea1c4..ceac9aee4a82 100644
> --- a/drivers/hwtracing/coresight/coresight-etm-perf.c
> +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
> @@ -472,6 +472,10 @@ static int __init etm_perf_init(void)
> {
> int ret;
>
> + ret = bus_register(&coresight_bustype);
> + if (ret)
> + return ret;
> +
> etm_pmu.capabilities= PERF_PMU_CAP_EXCLUSIVE;
>
> etm_pmu.attr_groups = etm_pmu_attr_groups;
> @@ -494,4 +498,15 @@ static int __init etm_perf_init(void)
>
> return ret;
> }
> -device_initcall(etm_perf_init);
> +postcore_initcall(etm_perf_init);
> +
> +static void __exit etm_perf_exit(void)
> +{
> + perf_pmu_unregister(&etm_pmu);
> + bus_unregister(&coresight_bustype);
> +}
> +module_exit(etm_perf_exit);
I see the perf functionality as an accessory to the core rather than
the other way around. Initialisation in the core code should be
driving the PMU registration.
> +
> +MODULE_AUTHOR("Mathieu Poirier ");
> +MODULE_DESCRIPTION("Arm CoreSight tracer driver");
> +MODULE_LICENSE("GPL v2");
> --
> 2.17.0
>
Re: [PATCH 3.16 191/410] Input: mms114 - fix license module information
On Thu, Jun 7, 2018 at 7:05 AM, Ben Hutchings wrote:
> 3.16.57-rc1 review patch. If anyone has any objections, please let me know.
Not a hard objection, but rather a curiosity: for this to be pulled
into stable what user issue does this fix?
>
> --
>
> From: Andi Shyti
>
> commit 498e7e7ed1fd72c275a682f0903c4a20cc538658 upstream.
>
> The driver has been released with GNU Public License v2 as stated
> in the header, but the module license information has been tagged
> as "GPL" (GNU Public License v2 or later).
>
> Fix the module license information so that it matches the one in
> the header as "GPL v2".
>
> Fixes: 07b8481d4aff ("Input: add MELFAS mms114 touchscreen driver")
> Reported-by: Marcus Folkesson
> Signed-off-by: Andi Shyti
> Signed-off-by: Dmitry Torokhov
> Signed-off-by: Ben Hutchings
> ---
> drivers/input/touchscreen/mms114.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/drivers/input/touchscreen/mms114.c
> +++ b/drivers/input/touchscreen/mms114.c
> @@ -592,4 +592,4 @@ module_i2c_driver(mms114_driver);
> /* Module information */
> MODULE_AUTHOR("Joonyoung Shim ");
> MODULE_DESCRIPTION("MELFAS mms114 Touchscreen driver");
> -MODULE_LICENSE("GPL");
> +MODULE_LICENSE("GPL v2");
>
--
Dmitry
Re: [PATCH v4 05/14] coresight: get/put module in coresight_build/release_path
On 7 June 2018 at 15:10, Suzuki K Poulose wrote: > On 06/07/2018 06:13 PM, Kim Phillips wrote: >> >> On Thu, 7 Jun 2018 11:07:15 +0100 >> Suzuki K Poulose wrote: >> >>> On 06/07/2018 10:53 AM, Greg Kroah-Hartman wrote: On Thu, Jun 07, 2018 at 10:32:21AM +0100, Suzuki K Poulose wrote: > > On 06/07/2018 10:13 AM, Greg Kroah-Hartman wrote: >> >> On Thu, Jun 07, 2018 at 10:04:33AM +0100, Suzuki K Poulose wrote: >>> >>> Hi Greg, >>> >>> On 06/07/2018 09:34 AM, Greg Kroah-Hartman wrote: On Wed, Jun 06, 2018 at 03:55:01PM -0500, Kim Phillips wrote: > > On Wed, 6 Jun 2018 10:46:36 +0100 > Suzuki K Poulose wrote: > >> On 06/06/2018 09:24 AM, Greg Kroah-Hartman wrote: >>> >>> On Tue, Jun 05, 2018 at 04:07:01PM -0500, Kim Phillips wrote: Increment the refcnt for driver modules in current use by calling module_get in coresight_build_path and module_put in release_path. This prevents driver modules from being unloaded when they are in use, either in sysfs or perf mode. >>> >>> >>> Why does it matter? Shouldn't you be allowed to remove any >>> module at >>> any point in time, much like a networking driver? >>> >>> >>> The user doesn't have an explicit refcount on the individual >>> components >>> in a trace session. So, when a trace session is in progress, it is as >>> good as having a "file" open on each component that is part of the >>> active trace session. So, we don't want the driver to be removed when >>> the component is being used in the trace collection. >> >> >> Why not? What's wrong with that happening and then the trace >> collection >> starts failing with -ENODEV or something? > > > May be I am missing something here. Can we allow the driver to be > removed > when one of its device is "turned ON" and we need the same > driver to "turn it OFF" when the session ends ? To make a better > comparison : > > Can we unload a usb_mass_storage module when a USB disk(which uses the > module driver) is mounted and is being used ? I believe, the module > will eventually get unloaded when we unmount the disk, if someone did > a unload. No, mount causes the module count to be incrememted. Mount and "open/close" are the old-school way of doing module reference counting. Look at how network drivers work today, you can unload any network driver even if there is a valid network connection "up and running" attached to it. It just gets torn down when that request happens. >>> >>> >>> Ok, that makes more sense now. Thanks for the hints. However, it doesn't >>> look that easy from the coresight point due to the way the devices are >>> used in an interconnected manner which could be part of multiple trace >>> sessions. >>> >>> e.g, a funnel could be part of two independent trace sessions with >>> different sets of sources/sinks. Tearing down the trace sessions is >>> going to be a difficult task unless we make drastic changes to the PMU >>> framework itself. But will see, what best we can do to make it modern >>> :-) > We have a similar situation here. The only difference is the driver is > referenced only when one of its device is in a trace session. I understand, I'm saying that you have to be very careful when messing around with module reference counts to get it correct and perhaps you should just change your design to not care about module reference counts at all, like networking did 15+ years ago. Let's learn from the good examples in our past (like networking), and not like the older bad examples (like mount/files). >> Remember, removing a kernel module is something that only happens very >> rarely, and is an explicit choice by someone with root permissions. >> If >> you want to remove that module, it should be able to go, as you know >> what you are doing at that point in time. > > > Right, but when a device is "in use" can we do that ? I thought the > user > will get a module is in use or busy, error. Try it on networking today :) >> Don't try to "protect the user from themselves" here, they want to >> shoot >> their foot, make it hurt if they are aiming it there :) >> > > The module_get/put added here are only triggered when we start a trace > session, where we build a path for the current session from the > configured > "source" to the configured "sink" and the path is destroyed > at the end of the trace session. i.e, the path is not a permanent > thing. > It is constructed per session. So it is perfectly possible to remove a > dev
Re: [PATCH v6 0/4] enable early printing of hashed pointers
On Thu, Jun 07, 2018 at 10:00:02AM -0400, Theodore Y. Ts'o wrote: > On Thu, Jun 07, 2018 at 09:31:04AM +1000, Tobin C. Harding wrote: > > > I'm also happy to take the whole patch series through the random tree > > > if everyone else is OK with it. > > > > Looks like every one is happy (or silent) now Ted, can you please take > > this version through your tree. > > Ok, it's now on the random.git tree. I'm going to give it a few days > of soak time in linux-next, and then I'll push it to Linus before the > end of the merge window. Great, thanks. Tobin.
Re: [PATCH NEXT 6/6] PCI/PORTDRV: Remove ERR_FATAL handling from pcie_portdrv_slot_reset()
On Thu, Jun 07, 2018 at 07:18:03PM +0530, p...@codeaurora.org wrote:
> On 2018-06-07 11:30, Oza Pawandeep wrote:
> > We are handling ERR_FATAL by resetting the Link in software,skipping the
> > driver pci_error_handlers callbacks, removing the devices from the PCI
> > subsystem, and re-enumerating, as a result of that, no more calling
> > pcie_portdrv_slot_reset in ERR_FATAL case.
> >
> > Signed-off-by: Oza Pawandeep
> >
> > diff --git a/drivers/pci/pcie/portdrv_pci.c
> > b/drivers/pci/pcie/portdrv_pci.c
> > index 973f1b8..92f5d330 100644
> > --- a/drivers/pci/pcie/portdrv_pci.c
> > +++ b/drivers/pci/pcie/portdrv_pci.c
> > @@ -42,17 +42,6 @@ __setup("pcie_ports=", pcie_port_setup);
> >
> > /* global data */
> >
> > -static int pcie_portdrv_restore_config(struct pci_dev *dev)
> > -{
> > - int retval;
> > -
> > - retval = pci_enable_device(dev);
> > - if (retval)
> > - return retval;
> > - pci_set_master(dev);
> > - return 0;
> > -}
> > -
> > #ifdef CONFIG_PM
> > static int pcie_port_runtime_suspend(struct device *dev)
> > {
> > @@ -162,14 +151,6 @@ static pci_ers_result_t
> > pcie_portdrv_mmio_enabled(struct pci_dev *dev)
> >
> > static pci_ers_result_t pcie_portdrv_slot_reset(struct pci_dev *dev)
> > {
> > - /* If fatal, restore cfg space for possible link reset at upstream */
> > - if (dev->error_state == pci_channel_io_frozen) {
> > - dev->state_saved = true;
> > - pci_restore_state(dev);
> > - pcie_portdrv_restore_config(dev);
> > - pci_enable_pcie_error_reporting(dev);
> > - }
> > -
> > return PCI_ERS_RESULT_RECOVERED;
> > }
>
>
> Hi Bjorn,
>
> the above patch removes ERR_FATAL handling from pcie_portdrv_slot_reset()
> because now we are handling ERR_FATAL differently than before.
>
> I tried to dig into pcie_portdrv_slot_reset() handling for ERR_FATAL case
> where it
> restores the config space, enable device, set master and enable error
> reporting
> and as far as I understand this is being done for upstream link (bridges
> etc..)
>
> why was it done at the first point (I checked the commit description, but
> could not really get it)
> and do we need to handle the same thing in ERR_FATAL now ?
You mean 4bf3392e0bf5 ("PCI-Express AER implemetation: pcie_portdrv
error handler"), which added pcie_portdrv_slot_reset()? I agree, that
commit log has no useful information. I don't know any of the history
behind it.
Re: [PATCH] uapi: Make generic uapi headers compile standalone.
Hi Jayant, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.17 next-20180607] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Jayant-Chowdhary/uapi-Make-generic-uapi-headers-compile-standalone/20180608-014548 config: i386-randconfig-a0-201822 (attached as .config) compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4 reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): In file included from drivers//android/binder.c:79:0: >> include/uapi/linux/android/binder.h:26:23: fatal error: sys/types.h: No such >> file or directory #include ^ compilation terminated. vim +26 include/uapi/linux/android/binder.h 23 24 #include 25 #include > 26 #include 27 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
[PATCH V6 25/38] x86/intel_rdt: Enable entering of pseudo-locksetup mode
The user can request entering pseudo-locksetup mode by writing
"pseudo-locksetup" to the mode file. Act on this request as well as
support switching from a pseudo-locksetup mode (before pseudo-locked
mode was entered). It is not supported to modify the mode once
pseudo-locked mode has been entered.
The schemata reflects the new mode by adding "uninitialized" to all
resources. The size resctrl file reports zero for all cache domains in
support of the uninitialized nature. Since there are no users of this
class of service its allocations can be ignored when searching for
appropriate default allocations for new resource groups. For the same
reason resource groups in pseudo-locksetup mode are not considered when
testing if new resource groups may overlap.
Signed-off-by: Reinette Chatre
---
V6: A resource group in pseudo-locksetup mode does have a CLOSID associated
with it but until its mode is changed to pseudo-locked there is no way
in which this CLOSID can be active. When a new allocation is considered
for a different resource group the new allocation should not be
compared to the unusable allocation associated with the CLOSID assigned
to the resource group in pseudo-locksetup mode.
arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c | 16 +++
arch/x86/kernel/cpu/intel_rdt_rdtgroup.c| 41 +
2 files changed, 47 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c
b/arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c
index bc79396c5dad..1ed273220ffa 100644
--- a/arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c
+++ b/arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c
@@ -156,7 +156,8 @@ int parse_cbm(void *_data, struct rdt_resource *r, struct
rdt_domain *d)
}
if (rdtgroup_cbm_overlaps(r, d, cbm_val, rdtgrp->closid, false)) {
- if (rdtgrp->mode == RDT_MODE_EXCLUSIVE) {
+ if (rdtgrp->mode == RDT_MODE_EXCLUSIVE ||
+ rdtgrp->mode == RDT_MODE_PSEUDO_LOCKSETUP) {
rdt_last_cmd_printf("overlaps with other group\n");
return -EINVAL;
}
@@ -356,10 +357,15 @@ int rdtgroup_schemata_show(struct kernfs_open_file *of,
rdtgrp = rdtgroup_kn_lock_live(of->kn);
if (rdtgrp) {
- closid = rdtgrp->closid;
- for_each_alloc_enabled_rdt_resource(r) {
- if (closid < r->num_closid)
- show_doms(s, r, closid);
+ if (rdtgrp->mode == RDT_MODE_PSEUDO_LOCKSETUP) {
+ for_each_alloc_enabled_rdt_resource(r)
+ seq_printf(s, "%s:uninitialized\n", r->name);
+ } else {
+ closid = rdtgrp->closid;
+ for_each_alloc_enabled_rdt_resource(r) {
+ if (closid < r->num_closid)
+ show_doms(s, r, closid);
+ }
}
} else {
ret = -ENOENT;
diff --git a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
index 59b5bdbb6597..0277c4fe433c 100644
--- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
+++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
@@ -974,9 +974,10 @@ bool rdtgroup_cbm_overlaps(struct rdt_resource *r, struct
rdt_domain *d,
ctrl = d->ctrl_val;
for (i = 0; i < r->num_closid; i++, ctrl++) {
ctrl_b = (unsigned long *)ctrl;
- if (closid_allocated(i) && i != closid) {
+ mode = rdtgroup_mode_by_closid(i);
+ if (closid_allocated(i) && i != closid &&
+ mode != RDT_MODE_PSEUDO_LOCKSETUP) {
if (bitmap_intersects(cbm, ctrl_b, r->cache.cbm_len)) {
- mode = rdtgroup_mode_by_closid(i);
if (exclusive) {
if (mode == RDT_MODE_EXCLUSIVE)
return true;
@@ -1046,10 +1047,24 @@ static ssize_t rdtgroup_mode_write(struct
kernfs_open_file *of,
mode = rdtgrp->mode;
if ((!strcmp(buf, "shareable") && mode == RDT_MODE_SHAREABLE) ||
- (!strcmp(buf, "exclusive") && mode == RDT_MODE_EXCLUSIVE))
+ (!strcmp(buf, "exclusive") && mode == RDT_MODE_EXCLUSIVE) ||
+ (!strcmp(buf, "pseudo-locksetup") &&
+mode == RDT_MODE_PSEUDO_LOCKSETUP) ||
+ (!strcmp(buf, "pseudo-locked") && mode == RDT_MODE_PSEUDO_LOCKED))
goto out;
+ if (mode == RDT_MODE_PSEUDO_LOCKED) {
+ rdt_last_cmd_printf("cannot change pseudo-locked group\n");
+ ret = -EINVAL;
+ goto out;
+ }
+
if (!strcmp(buf, "shareable")) {
+ if (rdtgrp->mode == RDT_MODE_PSEUDO_LOCKSETUP) {
+ ret = rdtgroup_locksetup_exit(rdtgrp);
+
[PATCH V6 07/38] x86/intel_rdt: Initialize new resource group with sane defaults
Currently when a new resource group is created its allocations would be
those that belonged to the resource group to which its closid belonged
previously.
That is, we can encounter a case like:
mkdir newgroup
cat newgroup/schemata
L2:0=ff;1=ff
echo 'L2:0=0xf0;1=0xf0' > newgroup/schemata
cat newgroup/schemata
L2:0=0xf0;1=0xf0
rmdir newgroup
mkdir newnewgroup
cat newnewgroup/schemata
L2:0=0xf0;1=0xf0
When the new group is created it would be reasonable to expect its
allocations to be initialized with all regions that it can possibly use.
At this time these regions would be all that are shareable by other
resource groups as well as regions that are not currently used.
If the available cache region is found to be non-contiguous the
available region is adjusted to enforce validity.
When a new resource group is created the hardware is initialized with
these new default allocations.
Signed-off-by: Reinette Chatre
---
V6: The cache region that is available for use by a new resource group may
not be contiguous. Enforce the available region to be valid by
selecting only the first contiguous portion. The goal is to ensure a
sane and valid default on resource group creation, the user still has
the ability to modify this default if it does not meet requirements.
arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 107 ++-
1 file changed, 104 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
index 35e538eed977..7ae798a8ebf6 100644
--- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
+++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
@@ -133,7 +133,7 @@ void closid_free(int closid)
* Return: true if @closid is currently associated with a resource group,
* false if @closid is free
*/
-static bool __attribute__ ((unused)) closid_allocated(unsigned int closid)
+static bool closid_allocated(unsigned int closid)
{
return (closid_free_map & (1 << closid)) == 0;
}
@@ -1799,6 +1799,102 @@ static int mkdir_mondata_all(struct kernfs_node
*parent_kn,
return ret;
}
+/**
+ * cbm_ensure_valid - Enforce validity on provided CBM
+ * @_val: Candidate CBM
+ * @r: RDT resource to which the CBM belongs
+ *
+ * The provided CBM represents all cache portions available for use. This
+ * may be represented by a bitmap that does not consist of contiguous ones
+ * and thus be an invalid CBM.
+ * Here the provided CBM is forced to be a valid CBM by only considering
+ * the first set of contiguous bits as valid and clearing all bits.
+ * The intention here is to provide a valid default CBM with which a new
+ * resource group is initialized. The user can follow this with a
+ * modification to the CBM if the default does not satisfy the
+ * requirements.
+ */
+static void cbm_ensure_valid(u32 *_val, struct rdt_resource *r)
+{
+ unsigned long *val = (unsigned long *)_val;
+ unsigned int cbm_len = r->cache.cbm_len;
+ unsigned long first_bit, zero_bit;
+
+ if (*val == 0)
+ return;
+
+ first_bit = find_first_bit(val, cbm_len);
+ zero_bit = find_next_zero_bit(val, cbm_len, first_bit);
+
+ /* Clear any remaining bits to ensure contiguous region */
+ bitmap_clear(val, zero_bit, cbm_len - zero_bit);
+}
+
+/**
+ * rdtgroup_init_alloc - Initialize the new RDT group's allocations
+ *
+ * A new RDT group is being created on an allocation capable (CAT)
+ * supporting system. Set this group up to start off with all usable
+ * allocations. That is, all shareable and unused bits.
+ *
+ * All-zero CBM is invalid. If there are no more shareable bits available
+ * on any domain then the entire allocation will fail.
+ */
+static int rdtgroup_init_alloc(struct rdtgroup *rdtgrp)
+{
+ u32 used_b = 0, unused_b = 0;
+ u32 closid = rdtgrp->closid;
+ struct rdt_resource *r;
+ enum rdtgrp_mode mode;
+ struct rdt_domain *d;
+ int i, ret;
+ u32 *ctrl;
+
+ for_each_alloc_enabled_rdt_resource(r) {
+ list_for_each_entry(d, &r->domains, list) {
+ d->have_new_ctrl = false;
+ d->new_ctrl = r->cache.shareable_bits;
+ used_b = r->cache.shareable_bits;
+ ctrl = d->ctrl_val;
+ for (i = 0; i < r->num_closid; i++, ctrl++) {
+ if (closid_allocated(i) && i != closid) {
+ mode = rdtgroup_mode_by_closid(i);
+ used_b |= *ctrl;
+ if (mode == RDT_MODE_SHAREABLE)
+ d->new_ctrl |= *ctrl;
+ }
+ }
+ unused_b = used_b ^ (BIT_MASK(r->cache.cbm_len) - 1);
+ unused_b &= BIT_MASK(r->cache.cbm_len) - 1;
+ d->new_ctrl |= unused_
[PATCH v6] tpm: separate cmd_ready/go_idle from runtime_pm
We cannot use go_idle cmd_ready commands via runtime_pm handles
as with the introduction of localities this is no longer an optional
feature, while runtime pm can be not enabled.
Though cmd_ready/go_idle provides a power saving, it's also a part of
TPM2 protocol and should be called explicitly.
This patch exposes cmd_read/go_idle via tpm class ops and removes
runtime pm support as it is not used by any driver.
A new tpm transmit flag is added TPM_TRANSMIT_NESTED, which implies
TPM_TRANSMIT_UNLOCKED and TPM_TRANSMIT_RAW. Both are needed to resolve
tpm spaces and locality request recursive calls to tpm_transmit().
New wrappers are added tpm_cmd_ready() and tpm_go_idle() to
streamline tpm_try_transmit code.
tpm_crb no longer needs own power saving functions and can drop using
tpm_pm_suspend/resume.
This patch cannot be really separated from the locality fix.
Fixes: 888d867df441 (tpm: cmd_ready command can be issued only after granting
locality)
Cc: sta...@vger.kernel.org
Fixes: 888d867df441 (tpm: cmd_ready command can be issued only after granting
locality)
Signed-off-by: Tomas Winkler
---
V2-3:resent
V4: 1. Use tpm_pm_suspend/resume in tpm_crb
2. Drop cmd_ready/go_idle around tpm_chip_register, as there is no
usage counter like in runtime_pm.
V5: 1. add tpm_cmd_ready and tpm_go_idle wrappers.
2. Abuse TPM_TRANSMIT_UNLOCKED flag to resolve tpm space
recursion.
V6: 1. Add new flags TPM_TRANSMIT_NESTED which implies
TPM_TRANSMIT_UNLOCKED and TPM_TRANSMIT_RAW, as not all
unlocked flows are recursive i.e. tpm2_unseal_trusted.
drivers/char/tpm/tpm-interface.c | 51 +++
drivers/char/tpm/tpm.h| 13 -
drivers/char/tpm/tpm2-space.c | 12 ++---
drivers/char/tpm/tpm_crb.c| 101 ++
drivers/char/tpm/tpm_vtpm_proxy.c | 2 +-
include/linux/tpm.h | 2 +
6 files changed, 88 insertions(+), 93 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index e32f6e85dc6d..1abd8261651b 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -29,7 +29,6 @@
#include
#include
#include
-#include
#include
#include "tpm.h"
@@ -369,10 +368,13 @@ static int tpm_validate_command(struct tpm_chip *chip,
return -EINVAL;
}
-static int tpm_request_locality(struct tpm_chip *chip)
+static int tpm_request_locality(struct tpm_chip *chip, unsigned int flags)
{
int rc;
+ if (flags & __TPM_TRANSMIT_RAW)
+ return 0;
+
if (!chip->ops->request_locality)
return 0;
@@ -385,10 +387,13 @@ static int tpm_request_locality(struct tpm_chip *chip)
return 0;
}
-static void tpm_relinquish_locality(struct tpm_chip *chip)
+static void tpm_relinquish_locality(struct tpm_chip *chip, unsigned int flags)
{
int rc;
+ if (flags & __TPM_TRANSMIT_RAW)
+ return;
+
if (!chip->ops->relinquish_locality)
return;
@@ -399,6 +404,28 @@ static void tpm_relinquish_locality(struct tpm_chip *chip)
chip->locality = -1;
}
+static int tpm_cmd_ready(struct tpm_chip *chip, unsigned int flags)
+{
+ if (flags & __TPM_TRANSMIT_RAW)
+ return 0;
+
+ if (!chip->ops->cmd_ready)
+ return 0;
+
+ return chip->ops->cmd_ready(chip);
+}
+
+static int tpm_go_idle(struct tpm_chip *chip, unsigned int flags)
+{
+ if (flags & __TPM_TRANSMIT_RAW)
+ return 0;
+
+ if (!chip->ops->go_idle)
+ return 0;
+
+ return chip->ops->go_idle(chip);
+}
+
static ssize_t tpm_try_transmit(struct tpm_chip *chip,
struct tpm_space *space,
u8 *buf, size_t bufsiz,
@@ -449,14 +476,15 @@ static ssize_t tpm_try_transmit(struct tpm_chip *chip,
/* Store the decision as chip->locality will be changed. */
need_locality = chip->locality == -1;
- if (!(flags & TPM_TRANSMIT_RAW) && need_locality) {
- rc = tpm_request_locality(chip);
+ if (need_locality) {
+ rc = tpm_request_locality(chip, flags);
if (rc < 0)
goto out_no_locality;
}
- if (chip->dev.parent)
- pm_runtime_get_sync(chip->dev.parent);
+ rc = tpm_cmd_ready(chip, flags);
+ if (rc)
+ goto out;
rc = tpm2_prepare_space(chip, space, ordinal, buf);
if (rc)
@@ -516,13 +544,16 @@ static ssize_t tpm_try_transmit(struct tpm_chip *chip,
}
rc = tpm2_commit_space(chip, space, ordinal, buf, &len);
+ if (rc)
+ dev_err(&chip->dev, "tpm2_commit_space: error %d\n", rc);
out:
- if (chip->dev.parent)
- pm_runtime_put_sync(chip->dev.parent);
+ rc = tpm_go_idle(chip, flags);
+ if (rc)
+ goto out;
if (need_locality)
-
Re: [PATCH v4 05/14] coresight: get/put module in coresight_build/release_path
On 06/07/2018 06:13 PM, Kim Phillips wrote: On Thu, 7 Jun 2018 11:07:15 +0100 Suzuki K Poulose wrote: On 06/07/2018 10:53 AM, Greg Kroah-Hartman wrote: On Thu, Jun 07, 2018 at 10:32:21AM +0100, Suzuki K Poulose wrote: On 06/07/2018 10:13 AM, Greg Kroah-Hartman wrote: On Thu, Jun 07, 2018 at 10:04:33AM +0100, Suzuki K Poulose wrote: Hi Greg, On 06/07/2018 09:34 AM, Greg Kroah-Hartman wrote: On Wed, Jun 06, 2018 at 03:55:01PM -0500, Kim Phillips wrote: On Wed, 6 Jun 2018 10:46:36 +0100 Suzuki K Poulose wrote: On 06/06/2018 09:24 AM, Greg Kroah-Hartman wrote: On Tue, Jun 05, 2018 at 04:07:01PM -0500, Kim Phillips wrote: Increment the refcnt for driver modules in current use by calling module_get in coresight_build_path and module_put in release_path. This prevents driver modules from being unloaded when they are in use, either in sysfs or perf mode. Why does it matter? Shouldn't you be allowed to remove any module at any point in time, much like a networking driver? The user doesn't have an explicit refcount on the individual components in a trace session. So, when a trace session is in progress, it is as good as having a "file" open on each component that is part of the active trace session. So, we don't want the driver to be removed when the component is being used in the trace collection. Why not? What's wrong with that happening and then the trace collection starts failing with -ENODEV or something? May be I am missing something here. Can we allow the driver to be removed when one of its device is "turned ON" and we need the same driver to "turn it OFF" when the session ends ? To make a better comparison : Can we unload a usb_mass_storage module when a USB disk(which uses the module driver) is mounted and is being used ? I believe, the module will eventually get unloaded when we unmount the disk, if someone did a unload. No, mount causes the module count to be incrememted. Mount and "open/close" are the old-school way of doing module reference counting. Look at how network drivers work today, you can unload any network driver even if there is a valid network connection "up and running" attached to it. It just gets torn down when that request happens. Ok, that makes more sense now. Thanks for the hints. However, it doesn't look that easy from the coresight point due to the way the devices are used in an interconnected manner which could be part of multiple trace sessions. e.g, a funnel could be part of two independent trace sessions with different sets of sources/sinks. Tearing down the trace sessions is going to be a difficult task unless we make drastic changes to the PMU framework itself. But will see, what best we can do to make it modern :-) We have a similar situation here. The only difference is the driver is referenced only when one of its device is in a trace session. I understand, I'm saying that you have to be very careful when messing around with module reference counts to get it correct and perhaps you should just change your design to not care about module reference counts at all, like networking did 15+ years ago. Let's learn from the good examples in our past (like networking), and not like the older bad examples (like mount/files). Remember, removing a kernel module is something that only happens very rarely, and is an explicit choice by someone with root permissions. If you want to remove that module, it should be able to go, as you know what you are doing at that point in time. Right, but when a device is "in use" can we do that ? I thought the user will get a module is in use or busy, error. Try it on networking today :) Don't try to "protect the user from themselves" here, they want to shoot their foot, make it hurt if they are aiming it there :) The module_get/put added here are only triggered when we start a trace session, where we build a path for the current session from the configured "source" to the configured "sink" and the path is destroyed at the end of the trace session. i.e, the path is not a permanent thing. It is constructed per session. So it is perfectly possible to remove a device in between trace sessions. That's fine, but again, just be careful to get this correct. The patch I reviewed did not seem to do that. Thanks for the useful suggestions, we will explore this more. Kim, I'm going to assume the series is still valid after this discussion, since technically just this patch can get dropped, and the user is able to shoot themselves in the foot. That doesn't mean the kernel can panic() if the user decided to unload the module while the trace session is in progress. It only means that the trace session could be stopped in between in the worst case. But nothing more harmful to the system. This series is for development purposes, after all. Do you mean that this series is for internal development purposes and not upstream ? Making the drivers modular are always helpful, especially for something
Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?
On 06/06/18 18:45, Leizhen (ThunderTown) wrote: >> >> The use of signals without SA_RESTORER is considered obsolete, but it's >> somewhat surprising that the vdso isn't there; it should be mapped even for >> static binaries esp. on i386 since it is the preferred way to do system >> calls (you don't need to parse the ELF for that.) Are you explicitly >> disabling the VDSO? If so, Don't Do That. > > Yes, the vdso was explicitly disabled by the tester. Thanks. > Are there any use cases that calls for this? Maybe we should drop this option. -hpa
[PATCH] platform/x86: Rename silead_dmi to touchscreen_dmi
Not only silead touchscreens need some extra info not available in the
ACPI tables to work properly. X86 devices with a Chipone ICN8505 chip also
need some DMI based extra configuration.
There is no reason to have separate dmi config code per touchscreen
controller vendor. This commit renames silead_dmi to a more generic
touchscreen_dmi name (and Kconfig option) in preparation of adding
info for tablets with an ICN8505 based touchscreen.
Note there are no functional changes all code changes are limited to
removing references to silead where these are no longer applicable.
Acked-by: Andy Shevchenko
Acked-by: Ard Biesheuvel
Signed-off-by: Hans de Goede
---
MAINTAINERS | 2 +-
drivers/platform/x86/Kconfig | 16 ++---
drivers/platform/x86/Makefile | 2 +-
.../x86/{silead_dmi.c => touchscreen_dmi.c} | 72 +--
4 files changed, 46 insertions(+), 46 deletions(-)
rename drivers/platform/x86/{silead_dmi.c => touchscreen_dmi.c} (89%)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4543d74484d2..6be5134cab54 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12814,7 +12814,7 @@ L: linux-in...@vger.kernel.org
L: platform-driver-...@vger.kernel.org
S: Maintained
F: drivers/input/touchscreen/silead.c
-F: drivers/platform/x86/silead_dmi.c
+F: drivers/platform/x86/touchscreen_dmi.c
SILICON MOTION SM712 FRAME BUFFER DRIVER
M: Sudip Mukherjee
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index f27cb186437d..c59f71265a35 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1196,16 +1196,16 @@ config INTEL_TURBO_MAX_3
This driver is only required when the system is not using Hardware
P-States (HWP). In HWP mode, priority can be read from ACPI tables.
-config SILEAD_DMI
- bool "Tablets with Silead touchscreens"
+config TOUCHSCREEN_DMI
+ bool "DMI based touchscreen configuration info"
depends on ACPI && DMI && I2C=y && TOUCHSCREEN_SILEAD
---help---
- Certain ACPI based tablets with Silead touchscreens do not have
- enough data in ACPI tables for the touchscreen driver to handle
- the touchscreen properly, as OEMs expected the data to be baked
- into the tablet model specific version of the driver shipped
- with the OS-image for the device. This option supplies the missing
- information. Enable this for x86 tablets with Silead touchscreens.
+ Certain ACPI based tablets with e.g. Silead or Chipone touchscreens
+ do not have enough data in ACPI tables for the touchscreen driver to
+ handle the touchscreen properly, as OEMs expect the data to be baked
+ into the tablet model specific version of the driver shipped with the
+ the OS-image for the device. This option supplies the missing info.
+ Enable this for x86 tablets with Silead or Chipone touchscreens.
config INTEL_CHTDC_TI_PWRBTN
tristate "Intel Cherry Trail Dollar Cove TI power button driver"
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 2ba6cb795338..8d9477114fb5 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -78,7 +78,7 @@ obj-$(CONFIG_INTEL_SMARTCONNECT) += intel-smartconnect.o
obj-$(CONFIG_PVPANIC) += pvpanic.o
obj-$(CONFIG_ALIENWARE_WMI)+= alienware-wmi.o
obj-$(CONFIG_INTEL_PMC_IPC)+= intel_pmc_ipc.o
-obj-$(CONFIG_SILEAD_DMI) += silead_dmi.o
+obj-$(CONFIG_TOUCHSCREEN_DMI) += touchscreen_dmi.o
obj-$(CONFIG_SURFACE_PRO3_BUTTON) += surfacepro3_button.o
obj-$(CONFIG_SURFACE_3_BUTTON) += surface3_button.o
obj-$(CONFIG_INTEL_PUNIT_IPC) += intel_punit_ipc.o
diff --git a/drivers/platform/x86/silead_dmi.c
b/drivers/platform/x86/touchscreen_dmi.c
similarity index 89%
rename from drivers/platform/x86/silead_dmi.c
rename to drivers/platform/x86/touchscreen_dmi.c
index 2fea649653cc..6284946cb0d1 100644
--- a/drivers/platform/x86/silead_dmi.c
+++ b/drivers/platform/x86/touchscreen_dmi.c
@@ -1,5 +1,5 @@
/*
- * Silead touchscreen driver DMI based configuration code
+ * Touchscreen driver DMI based configuration code
*
* Copyright (c) 2017 Red Hat Inc.
*
@@ -20,7 +20,7 @@
#include
#include
-struct silead_ts_dmi_data {
+struct ts_dmi_data {
const char *acpi_name;
const struct property_entry *properties;
};
@@ -36,7 +36,7 @@ static const struct property_entry chuwi_hi8_props[] = {
{ }
};
-static const struct silead_ts_dmi_data chuwi_hi8_data = {
+static const struct ts_dmi_data chuwi_hi8_data = {
.acpi_name = "MSSL0001:00",
.properties = chuwi_hi8_props,
};
@@ -50,7 +50,7 @@ static const struct property_entry chuwi_hi8_pro_props[] = {
{ }
};
-static const struct silead_ts_dmi_data chuwi_hi8_pro_data = {
+static const struct ts_dmi_data chuwi_hi8_pro_data = {
.acpi
[PATCH 0/1] platform/x86: Rename silead_dmi to touchscreen_dmi
Hi, This patch is part of / preparation for the EFI embedded firmware stuff. But it can be merged by itself without the test of that series and since silead_dmi.c sees quite a bit of churn I would like to get this one of my queue and merged. I guess it is to late for 4.18, but please consider queuing this up for next when the merge window closes. Note this applies on top of the alphabetically sort series which I sent out earlier. Regards, Hans
