[RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC

[Nishanth Menon]

The AM654 SoC is a lead device of the K3 Multicore SoC architecture
platform, targeted for broad market and industrial control with aim to
meet the complex processing needs of modern embedded products.

Some highlights of this SoC are:
* Quad ARMv8 A53 cores split over two clusters
* GICv3 compliant GIC500
* Configurable L3 Cache and IO-coherent architecture
* Dual lock-step capable R5F uC for safety-critical applications
* High data throughput capable distributed DMA architecture under NAVSS
* Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual
  PRUs and dual RTUs
* Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
* Centralized System Controller for Security, Power, and Resource
  management.
* Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD
* Flash subystem with OSPI and Hyperbus interfaces
* Multimedia capability with CAL, DSS7-UL, SGX544, McASP
* Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI,
  GPIO

See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7

We introduce the Kconfig symbol for the SoC along with this patch since
it is logically relevant point, however the usage is in subsequent
patches.

NOTE: AM654 is the first of the device variants, hence we introduce a
generic am6.dtsi.

Signed-off-by: Benjamin Fair 
Signed-off-by: Nishanth Menon 
---
 MAINTAINERS  |   1 +
 arch/arm64/boot/dts/ti/k3-am6.dtsi   | 144 +++
 arch/arm64/boot/dts/ti/k3-am654.dtsi | 117 
 drivers/soc/ti/Kconfig   |  14 
 4 files changed, 276 insertions(+)
 create mode 100644 arch/arm64/boot/dts/ti/k3-am6.dtsi
 create mode 100644 arch/arm64/boot/dts/ti/k3-am654.dtsi

diff --git a/MAINTAINERS b/MAINTAINERS
index cfb35b252ac7..5f5c4eddec7a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2092,6 +2092,7 @@ M:Nishanth Menon 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 S: Supported
 F: Documentation/devicetree/bindings/arm/ti/k3.txt
+F: arch/arm64/boot/dts/ti/k3-*
 
 ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE
 M: Santosh Shilimkar 
diff --git a/arch/arm64/boot/dts/ti/k3-am6.dtsi 
b/arch/arm64/boot/dts/ti/k3-am6.dtsi
new file mode 100644
index ..cdfa12173aac
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am6.dtsi
@@ -0,0 +1,144 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for AM6 SoC Family
+ *
+ * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#include 
+#include 
+#include 
+
+/ {
+   model = "Texas Instruments K3 AM654 SoC";
+   compatible = "ti,am654";
+   interrupt-parent = <>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   aliases {
+   serial0 = _uart0;
+   serial1 = _uart0;
+   serial2 = _uart0;
+   serial3 = _uart1;
+   serial4 = _uart2;
+   };
+
+   chosen { };
+
+   firmware {
+   optee {
+   compatible = "linaro,optee-tz";
+   method = "smc";
+   };
+
+   psci: psci {
+   compatible = "arm,psci-1.0";
+   method = "smc";
+   };
+   };
+
+   soc0: soc0 {
+   compatible = "simple-bus";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   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 = ;
+   };
+
+   gic: interrupt-controller@180 {
+   compatible = "arm,gic-v3";
+   #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
+*/
+   reg = <0x0 0x0180 0x0 0x1>, /* GICD */
+ <0x0 0x0188 0x0 0x9>; /* GICR */
+
+   /*
+* vcpumntirq:
+* virtual CPU interface maintenance interrupt
+*/
+   interrupts = ;
+
+   gic_its: gic-its@100 {
+  

[RFC PATCH 6/6] arm64: dts: ti: Add support for AM654 EVM base board

[Nishanth Menon]

The EValuation Module(EVM) platform for AM654 consists of a
common Base board + one or more of daughter cards, which include:
a) "Personality Modules", which can be specific to a profile, such as
 ICSSG enabled or Multi-media (including audio).
b) SERDES modules, which may be 2 lane PCIe or two port PCIe + USB2
c) Camera daughter card
d) various display panels

Among other options. There are two basic configurations defined which
include an "EVM" configuration and "IDK" (Industrial development kit)
which differ in the specific combination of daughter cards that are
used.

To simplify support, we choose to support just the base board as the
core device tree file and all daughter cards would be expected to be
device tree overlays.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Nishanth Menon 
---
 MAINTAINERS|  1 +
 arch/arm64/boot/dts/Makefile   |  1 +
 arch/arm64/boot/dts/ti/Makefile|  9 ++
 arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 40 ++
 4 files changed, 51 insertions(+)
 create mode 100644 arch/arm64/boot/dts/ti/Makefile
 create mode 100644 arch/arm64/boot/dts/ti/k3-am654-base-board.dts

diff --git a/MAINTAINERS b/MAINTAINERS
index 5f5c4eddec7a..4491a0f0625f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2092,6 +2092,7 @@ M:Nishanth Menon 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 S: Supported
 F: Documentation/devicetree/bindings/arm/ti/k3.txt
+F: arch/arm64/boot/dts/ti/Makefile
 F: arch/arm64/boot/dts/ti/k3-*
 
 ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE
diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index 3543bc324553..4690364d584b 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -23,5 +23,6 @@ subdir-y += rockchip
 subdir-y += socionext
 subdir-y += sprd
 subdir-y += synaptics
+subdir-y += ti
 subdir-y += xilinx
 subdir-y += zte
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
new file mode 100644
index ..63e619d0b5b8
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -0,0 +1,9 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Make file to build device tree binaries for boards based on
+# Texas Instruments Inc processors
+#
+# Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+#
+
+dtb-$(CONFIG_ARCH_K3_AM6_SOC) += k3-am654-base-board.dtb
diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts 
b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
new file mode 100644
index ..d227d792de60
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+/dts-v1/;
+
+#include "k3-am654.dtsi"
+
+/ {
+   compatible =  "ti,am654-evm", "ti,am654";
+   model = "Texas Instruments AM654 Base Board";
+
+   chosen {
+   stdout-path = "serial2:115200n8";
+   bootargs = "earlycon=ns16550a,mmio32,0x0280";
+   };
+
+   memory@8000 {
+   device_type = "memory";
+   /* 4G RAM */
+   reg = <0x 0x8000 0x 0x8000>,
+ <0x0008 0x8000 0x 0x8000>;
+   };
+
+   reserved-memory {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   secure_ddr: secure_ddr@9e80 {
+   reg = <0 0x9e80 0 0x0180>; /* for OP-TEE */
+   alignment = <0x1000>;
+   no-map;
+   };
+   };
+};
+
+_uart0 {
+   status = "okay";
+};
-- 
2.15.1

Re: [PATCH 6/6] x86/vdso: Move out the CPU number store

[Mika Penttilä]

On 06/05/2018 08:36 AM, H. Peter Anvin wrote:
> On 06/04/18 20:57, Mika Penttilä wrote:
>>
>> This won't work on X86-32 because it actually uses the segment limit with 
>> fs: access. So there 
>> is a reason why the lsl based method is X86-64 only.
>>
> 
> 
> 
> Why does that matter in any shape, way, or form?  The LSL instruction
> doesn't touch any of the segment registers, it just uses a segment
> selector number.
> 
> 
> 
> I see... we have a VERY unfortunate name collision: the x86-64
> GDT_ENTRY_PERC_PU and the i386 GDT_ENTRY_PERCPU are in fact two
> completely different things, with the latter being the actual percpu
> offset used by the kernel.
> 
> So yes, this patch is wrong, because the naming of the x86-64 segment is
> insane especially in the proximity of the  -- it should be something
> like GDT_ENTRY_CPU_NUMBER.
> 
> Unfortunately we probably can't use the same GDT entry on x86-32 and
> x86-64, because entry 15 (selector 0x7b) is USER_DS, which is something
> we really don't want to screw with.  This means i386 programs that
> execute LSL directly for whatever reason will have to understand the
> difference, but most of the other segment numbers differ as well,
> including user space %cs (USER_CS/USER32_CS) and %ds/%es/%ss (USER_DS).
> Perhaps we could bump down segments 23-28 by one and put it as 23, that
> way the CPU_NUMBER segment would always be at %ss+80 for the default
> (flat, initial) user space %ss.  (We want to specify using %ss rather
> than %ds, because it is less likely to be changed and because 64 bits,
> too, have %ss defined, but not %ds.)
> 
> 
> 
> Rename the x86-64 segment to CPU_NUMBER, fixing the naming conflict.
> Add 1 to GDT entry numbers 23-28 for i386 (all of these are
> kernel-internal segments and so have no impact on user space).
> Add i386 CPU_NUMBER equivalent to x86-64 at GDT entry 23.
> Document the above relationship between segments.
> 
> OK, everyone?
> 
>   -hpa
> 

Yes GDT_ENTRY_PER_CPU and GDT_ENTRY_PERCPU meaning two totally different things 
is really confusing,
the proposal seems ok to me!

--Mika

[RFC PATCH 4/6] serial: 8250_omap: Make 8250_omap driver driver depend on ARCH_K3

[Nishanth Menon]

From: Lokesh Vutla 

Allow 8250 omap serial driver to be used for K3 platforms.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Nishanth Menon 
---
 drivers/tty/serial/8250/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
index f005eaf8bc57..15c2c5463835 100644
--- a/drivers/tty/serial/8250/Kconfig
+++ b/drivers/tty/serial/8250/Kconfig
@@ -375,7 +375,7 @@ config SERIAL_8250_RT288X
 
 config SERIAL_8250_OMAP
tristate "Support for OMAP internal UART (8250 based driver)"
-   depends on SERIAL_8250 && ARCH_OMAP2PLUS
+   depends on SERIAL_8250 && (ARCH_OMAP2PLUS || ARCH_K3)
help
  If you have a machine based on an Texas Instruments OMAP CPU you
  can enable its onboard serial ports by enabling this option.
-- 
2.15.1

[RFC PATCH 2/6] arm64: Add support for TI's K3 Multicore SoC architecture

[Nishanth Menon]

Add support for Texas Instrument's K3 Multicore SoC architecture
processors.

Signed-off-by: Nishanth Menon 
---
 arch/arm64/Kconfig.platforms | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index d5aeac351fc3..52df25bf4f8c 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -71,6 +71,13 @@ config ARCH_EXYNOS
help
  This enables support for ARMv8 based Samsung Exynos SoC family.
 
+config ARCH_K3
+   bool "Texas Instruments Inc. K3 multicore SoC architecture"
+   select PM_GENERIC_DOMAINS if PM
+   help
+ This enables support for Texas Instruments' K3 multicore SoC
+ architecture.
+
 config ARCH_LAYERSCAPE
bool "ARMv8 based Freescale Layerscape SoC family"
select EDAC_SUPPORT
-- 
2.15.1

Re: [PATCH] remoteproc: qcom: Introduce Hexagon V5 based WCSS driver

[Vinod]

On 05-06-18, 11:12, Sricharan R wrote:

> +config QCOM_Q6V5_WCSS
> + tristate "Qualcomm Hexagon based WCSS Peripheral Image Loader"
> + depends on OF && ARCH_QCOM
> + depends on QCOM_SMEM
> + depends on RPMSG_QCOM_SMD || (COMPILE_TEST && RPMSG_QCOM_SMD=n)
> + depends on RPMSG_QCOM_GLINK_SMEM || RPMSG_QCOM_GLINK_SMEM=n

Is there a reason why it depends on RPMSG_QCOM_GLINK_SMEM=n? What would
happen if distro wants both this and RPMSG_QCOM_GLINK_SMEM

> +/* QDSP6SS Register Offsets */
> +#define QDSP6SS_RESET_REG0x014
> +#define QDSP6SS_GFMUX_CTL_REG0x020
> +#define QDSP6SS_PWR_CTL_REG  0x030
> +#define QDSP6SS_MEM_PWR_CTL  0x0B0
> +
> +/* AXI Halt Register Offsets */
> +#define AXI_HALTREQ_REG  0x0
> +#define AXI_HALTACK_REG  0x4
> +#define AXI_IDLE_REG 0x8
> +
> +#define HALT_ACK_TIMEOUT_MS  100
> +
> +/* QDSP6SS_RESET */
> +#define Q6SS_STOP_CORE   BIT(0)
> +#define Q6SS_CORE_ARES   BIT(1)
> +#define Q6SS_BUS_ARES_ENABLE BIT(2)

Wouldn't it be nice if the defines are all consistent, some of them are
QDSP6SS_xxx, some Q6SS_ some are not

Please do pick one and make it consistent :)

> +/* QDSP6v56 parameters */
> +#define QDSP6v56_LDO_BYP BIT(25)
> +#define QDSP6v56_BHS_ON  BIT(24)
> +#define QDSP6v56_CLAMP_WLBIT(21)
> +#define QDSP6v56_CLAMP_QMC_MEM   BIT(22)
> +#define HALT_CHECK_MAX_LOOPS 200
> +#define QDSP6SS_XO_CBCR  0x0038

GENMASK() perhaps?

> +static int q6v5_wcss_reset(struct q6v5_wcss *wcss)
> +{
> + int ret;
> + u32 val;
> + int i;

int ret, i;

> +static int q6v5_wcss_start(struct rproc *rproc)
> +{
> + struct q6v5_wcss *wcss = rproc->priv;
> + int ret;
> +
> + qcom_q6v5_prepare(>q6v5);
> +
> + /* Release Q6 and WCSS reset */
> + ret = reset_control_deassert(wcss->wcss_reset);
> + if (ret) {
> + dev_err(wcss->dev, "wcss_reset failed\n");
> + return ret;
> + }
> +
> + ret = reset_control_deassert(wcss->wcss_q6_reset);
> + if (ret) {
> + dev_err(wcss->dev, "wcss_q6_reset failed\n");
> + goto wcss_reset;
> + }
> +
> + /* Lithium configuration - clock gating and bus arbitration */
> + ret = regmap_update_bits(wcss->halt_map,
> +  wcss->halt_nc + TCSR_GLOBAL_CFG0,
> +  0x1F, 0x14);

magic numbers??

> +static int q6v5_wcss_powerdown(struct q6v5_wcss *wcss)
> +{
> + int ret;
> + u32 val;
> +
> + /* 1 - Assert WCSS/Q6 HALTREQ */
> + q6v5_wcss_halt_axi_port(wcss, wcss->halt_map, wcss->halt_wcss);
> +
> + /* 2 - Enable WCSSAON_CONFIG */
> + val = readl(wcss->rmb_base + SSCAON_CONFIG);
> + val |= SSCAON_ENABLE;
> + writel(val, wcss->rmb_base + SSCAON_CONFIG);
> +
> + /* 3 - Set SSCAON_CONFIG */
> + val |= BIT(15);
> + val &= ~BIT(16);
> + val &= ~BIT(17);
> + val &= ~BIT(18);

wouldn't it be nice to define these bits?

> +static int q6v5_q6_powerdown(struct q6v5_wcss *wcss)
> +{
> + int ret;
> + u32 val;
> + int i;

int ret, i;
-- 
~Vinod

[RFC PATCH 2/8] mailbox: ti-msgmgr: Allocate Rx channel resources only on request

[Nishanth Menon]

In a much bigger system SoCs, the number of Rx channels can be
many and mostly unused based on the system of choice, and not all
Rx channels need IRQs and allocating all memory at probe will be
inefficient. Some SoCs could have total threads in the 100s and usage
would be just 1 Rx thread.

Thus, request and map the IRQs and allocate memory only when needed.

Since these channels are requested by client drivers on need, our
utilization will be optimal.

Signed-off-by: Nishanth Menon 
---
 drivers/mailbox/ti-msgmgr.c | 91 ++---
 1 file changed, 61 insertions(+), 30 deletions(-)

diff --git a/drivers/mailbox/ti-msgmgr.c b/drivers/mailbox/ti-msgmgr.c
index 7cd5f9c9c97f..7221590c409c 100644
--- a/drivers/mailbox/ti-msgmgr.c
+++ b/drivers/mailbox/ti-msgmgr.c
@@ -310,6 +310,51 @@ static int ti_msgmgr_send_data(struct mbox_chan *chan, 
void *data)
return 0;
 }
 
+/**
+ *  ti_msgmgr_queue_rx_irq_req() - RX IRQ request
+ *  @dev:  device pointer
+ *  @qinst:Queue instance
+ *  @chan: Channel pointer
+ */
+static int ti_msgmgr_queue_rx_irq_req(struct device *dev,
+ struct ti_queue_inst *qinst,
+ struct mbox_chan *chan)
+{
+   int ret = 0;
+   char of_rx_irq_name[7];
+   struct device_node *np;
+
+   snprintf(of_rx_irq_name, sizeof(of_rx_irq_name),
+"rx_%03d", qinst->queue_id);
+
+   /* Get the IRQ if not found */
+   if (qinst->irq < 0) {
+   np = of_node_get(dev->of_node);
+   if (!np)
+   return -ENODATA;
+   qinst->irq = of_irq_get_byname(np, of_rx_irq_name);
+   of_node_put(np);
+
+   if (qinst->irq < 0) {
+   dev_err(dev,
+   "QID %d PID %d:No IRQ[%s]: %d\n",
+   qinst->queue_id, qinst->proxy_id,
+   of_rx_irq_name, qinst->irq);
+   return qinst->irq;
+   }
+   }
+
+   /* With the expectation that the IRQ might be shared in SoC */
+   ret = request_irq(qinst->irq, ti_msgmgr_queue_rx_interrupt,
+ IRQF_SHARED, qinst->name, chan);
+   if (ret) {
+   dev_err(dev, "Unable to get IRQ %d on %s(res=%d)\n",
+   qinst->irq, qinst->name, ret);
+   }
+
+   return ret;
+}
+
 /**
  * ti_msgmgr_queue_startup() - Startup queue
  * @chan:  Channel pointer
@@ -318,19 +363,21 @@ static int ti_msgmgr_send_data(struct mbox_chan *chan, 
void *data)
  */
 static int ti_msgmgr_queue_startup(struct mbox_chan *chan)
 {
-   struct ti_queue_inst *qinst = chan->con_priv;
struct device *dev = chan->mbox->dev;
+   struct ti_msgmgr_inst *inst = dev_get_drvdata(dev);
+   struct ti_queue_inst *qinst = chan->con_priv;
+   const struct ti_msgmgr_desc *d = inst->desc;
int ret;
 
if (!qinst->is_tx) {
-   /*
-* With the expectation that the IRQ might be shared in SoC
-*/
-   ret = request_irq(qinst->irq, ti_msgmgr_queue_rx_interrupt,
- IRQF_SHARED, qinst->name, chan);
+   /* Allocate usage buffer for rx */
+   qinst->rx_buff = kzalloc(d->max_message_size, GFP_KERNEL);
+   if (!qinst->rx_buff)
+   return -ENOMEM;
+   /* Request IRQ */
+   ret = ti_msgmgr_queue_rx_irq_req(dev, qinst, chan);
if (ret) {
-   dev_err(dev, "Unable to get IRQ %d on %s(res=%d)\n",
-   qinst->irq, qinst->name, ret);
+   kfree(qinst->rx_buff);
return ret;
}
}
@@ -346,8 +393,10 @@ static void ti_msgmgr_queue_shutdown(struct mbox_chan 
*chan)
 {
struct ti_queue_inst *qinst = chan->con_priv;
 
-   if (!qinst->is_tx)
+   if (!qinst->is_tx) {
free_irq(qinst->irq, chan);
+   kfree(qinst->rx_buff);
+   }
 }
 
 /**
@@ -425,27 +474,6 @@ static int ti_msgmgr_queue_setup(int idx, struct device 
*dev,
 dev_name(dev), qinst->is_tx ? "tx" : "rx", qinst->queue_id,
 qinst->proxy_id);
 
-   if (!qinst->is_tx) {
-   char of_rx_irq_name[7];
-
-   snprintf(of_rx_irq_name, sizeof(of_rx_irq_name),
-"rx_%03d", qinst->queue_id);
-
-   qinst->irq = of_irq_get_byname(np, of_rx_irq_name);
-   if (qinst->irq < 0) {
-   dev_crit(dev,
-"[%d]QID %d PID %d:No IRQ[%s]: %d\n",
-idx, qinst->queue_id, qinst->proxy_id,
-of_rx_irq_name, qinst->irq);
-   return qinst->irq;
-   }
-   /* Allocate usage buffer 

[RFC PATCH 4/8] mailbox: ti-msgmgr: Move the memory region name to descriptor

[Nishanth Menon]

For newer generation of the hardware, the naming of the region is
decided at integration level and there could be additional regions
as well. Hence move the region naming to be described from compatible
descriptor.

Signed-off-by: Nishanth Menon 
---
 drivers/mailbox/ti-msgmgr.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/mailbox/ti-msgmgr.c b/drivers/mailbox/ti-msgmgr.c
index 2952339a8446..a37d6a4b392f 100644
--- a/drivers/mailbox/ti-msgmgr.c
+++ b/drivers/mailbox/ti-msgmgr.c
@@ -48,6 +48,8 @@ struct ti_msgmgr_valid_queue_desc {
  * @tx_polled: Do I need to use polled mechanism for tx
  * @tx_poll_timeout_ms: Timeout in ms if polled
  * @valid_queues:  List of Valid queues that the processor can access
+ * @data_region_name:  Name of the proxy data region
+ * @status_region_name:Name of the proxy status region
  * @num_valid_queues:  Number of valid queues
  *
  * This structure is used in of match data to describe how integration
@@ -63,6 +65,8 @@ struct ti_msgmgr_desc {
bool tx_polled;
int tx_poll_timeout_ms;
const struct ti_msgmgr_valid_queue_desc *valid_queues;
+   const char *data_region_name;
+   const char *status_region_name;
int num_valid_queues;
 };
 
@@ -531,6 +535,8 @@ static const struct ti_msgmgr_desc k2g_desc = {
.queue_count = 64,
.max_message_size = 64,
.max_messages = 128,
+   .data_region_name = "queue_proxy_region",
+   .status_region_name = "queue_state_debug_region",
.data_first_reg = 16,
.data_last_reg = 31,
.status_cnt_mask = Q_STATE_ENTRY_COUNT_MASK,
@@ -582,13 +588,13 @@ static int ti_msgmgr_probe(struct platform_device *pdev)
inst->desc = desc;
 
res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
-  "queue_proxy_region");
+  desc->data_region_name);
inst->queue_proxy_region = devm_ioremap_resource(dev, res);
if (IS_ERR(inst->queue_proxy_region))
return PTR_ERR(inst->queue_proxy_region);
 
res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
-  "queue_state_debug_region");
+  desc->status_region_name);
inst->queue_state_debug_region = devm_ioremap_resource(dev, res);
if (IS_ERR(inst->queue_state_debug_region))
return PTR_ERR(inst->queue_state_debug_region);
-- 
2.15.1

[RFC PATCH 8/8] arm64: dts: ti: k3-am6: Add Secure Proxy instance

[Nishanth Menon]

Add support for Secure Proxy instances in AM6 family of SoCs.

Signed-off-by: Nishanth Menon 
---
 arch/arm64/boot/dts/ti/k3-am6.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am6.dtsi 
b/arch/arm64/boot/dts/ti/k3-am6.dtsi
index cdfa12173aac..07e9cc05519c 100644
--- a/arch/arm64/boot/dts/ti/k3-am6.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am6.dtsi
@@ -86,6 +86,17 @@
};
};
 
+   secure_proxy: secure_proxy@32c0 {
+   compatible = "ti,am654-secure-proxy";
+   #mbox-cells = <1>;
+   reg-names = "target_data", "rt", "scfg";
+   reg = <0x0 0x32c0 0x0 0x10>,
+ <0x0 0x3240 0x0 0x10>,
+ <0x0 0x3280 0x0 0x10>;
+   interrupt-names = "rx_011";
+   interrupts = ;
+   };
+
wkup_uart0: serial@4230 {
compatible = "ti,am654-uart", "ti,omap4-uart", 
"ns16550a";
reg = <0x0 0x4230 0x0 0x100>;
-- 
2.15.1

Re: [PATCH] ksys_mount: check for permissions before resource allocation

[Ilya Matveychikov]

Just CC’ed to some of maintainers.

$ perl scripts/get_maintainer.pl 
fs/0001-ksys_mount-check-for-permissions-before-resource-all.patch
Alexander Viro  (maintainer:FILESYSTEMS (VFS and 
infrastructure))
linux-fsde...@vger.kernel.org (open list:FILESYSTEMS (VFS and infrastructure))
linux-kernel@vger.kernel.org (open list)

> On Jun 5, 2018, at 6:00 AM, Ilya Matveychikov  wrote:
> 
> Early check for mount permissions prevents possible allocation of 3
> pages from kmalloc() pool by unpriveledged user which can be used for
> spraying the kernel heap.
> 
> Signed-off-by: Ilya V. Matveychikov 
> ---
> fs/namespace.c | 3 +++
> 1 file changed, 3 insertions(+)
> 
> diff --git a/fs/namespace.c b/fs/namespace.c
> index 5f75969adff1..1ef8feb2de2a 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -3046,6 +3046,9 @@ int ksys_mount(char __user *dev_name, char __user 
> *dir_name, char __user *type,
>   char *kernel_dev;
>   void *options;
> 
> + if (!may_mount())
> + return -EPERM;
> +
>   kernel_type = copy_mount_string(type);
>   ret = PTR_ERR(kernel_type);
>   if (IS_ERR(kernel_type))
> --
> 2.17.0
> 

Re: [PATCH v2] cros_ec: Use devm_kzalloc for private data

[Lee Jones]

On Wed, 30 May 2018, Gwendal Grignou wrote:

> Use dev_kzmalloc, remove .release entry point.
> 
> Signed-off-by: Gwendal Grignou 
> ---
> Change sinc v1:
> - Readd __remove to avoid a warning when loaded as a module.
> 
>  drivers/mfd/cros_ec_dev.c | 10 ++
>  1 file changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
> index 1d6dc5c7a19d..81466264f7fc 100644
> --- a/drivers/mfd/cros_ec_dev.c
> +++ b/drivers/mfd/cros_ec_dev.c
> @@ -262,12 +262,7 @@ static const struct file_operations fops = {
>  #endif
>  };
>  
> -static void __remove(struct device *dev)
> -{
> - struct cros_ec_dev *ec = container_of(dev, struct cros_ec_dev,
> -   class_dev);
> - kfree(ec);
> -}
> +static void __remove(struct device *dev) { }

I missed this line when reviewing.

Why are you keeping the function around?

As a result, we now suffer with a build warning:

  drivers/mfd/cros_ec_dev.c:265:13: warning: '__remove' defined but not used 
[-Wunused-function]
   static void __remove(struct device *dev) { }

Can I just remove the line?  What are the ramifications of doing so?

Please reply swiftly, so resolve this issue in good time.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [patch 3/8] x86/apic: Provide apic_ack_irq()

[Song Liu]

On Mon, Jun 4, 2018 at 8:33 AM, Thomas Gleixner  wrote:
> apic_ack_edge() is explicitely for handling interrupt affinity cleanup when
> interrupt remapping is not available or disable.
>
> Remapped interrupts and also some of the platform specific special
> interrupts, e.g. UV, invoke ack_APIC_irq() directly.
>
> To address the issue of failing an affinity update with -EBUSY the delayed
> affinity mechanism can be reused, but ack_APIC_irq() does not handle
> that. Adding this to ack_APIC_irq() is not possible, because that function
> is also used for exceptions and directly handled interrupts like IPIs.
>
> Create a new function, which just contains the conditional invocation of
> irq_move_irq() and the final ack_APIC_irq(). Making the invocation of
> irq_move_irq() conditional avoids the out of line call if the pending bit
> is not set.
>
> Reuse the new function in apic_ack_edge().
>
> Preparatory change for the real fix
>
> Fixes: dccfe3147b42 ("x86/vector: Simplify vector move cleanup")
> Signed-off-by: Thomas Gleixner 
> Cc: sta...@vger.kernel.org

Tested-by: Song Liu 

> ---
>  arch/x86/include/asm/apic.h   |2 ++
>  arch/x86/kernel/apic/vector.c |   10 --
>  2 files changed, 10 insertions(+), 2 deletions(-)
>
> --- a/arch/x86/include/asm/apic.h
> +++ b/arch/x86/include/asm/apic.h
> @@ -436,6 +436,8 @@ static inline void apic_set_eoi_write(vo
>
>  #endif /* CONFIG_X86_LOCAL_APIC */
>
> +extern void apic_ack_irq(struct irq_data *data);
> +
>  static inline void ack_APIC_irq(void)
>  {
> /*
> --- a/arch/x86/kernel/apic/vector.c
> +++ b/arch/x86/kernel/apic/vector.c
> @@ -809,11 +809,17 @@ static int apic_retrigger_irq(struct irq
> return 1;
>  }
>
> +void apic_ack_irq(struct irq_data *irqd)
> +{
> +   if (unlikely(irqd_is_setaffinity_pending(irqd)))
> +   irq_move_irq(irqd);
> +   ack_APIC_irq();
> +}
> +
>  void apic_ack_edge(struct irq_data *irqd)
>  {
> irq_complete_move(irqd_cfg(irqd));
> -   irq_move_irq(irqd);
> -   ack_APIC_irq();
> +   apic_ack_irq(irqd);
>  }
>
>  static struct irq_chip lapic_controller = {
>
>

Re: [PATCH] module: exclude SHN_UNDEF symbols from kallsyms api

[Jessica Yu]

+++ Josh Poimboeuf [04/06/18 18:02 -0500]:

On Mon, Jun 04, 2018 at 05:56:05PM -0500, Josh Poimboeuf wrote:

On Mon, Jun 04, 2018 at 09:54:12AM -0500, Josh Poimboeuf wrote:
> On Mon, Jun 04, 2018 at 04:05:11PM +0200, Jessica Yu wrote:
> > +++ Josh Poimboeuf [04/06/18 08:16 -0500]:
> > > On Mon, Jun 04, 2018 at 03:01:31PM +0200, Jessica Yu wrote:
> > > > +++ Jessica Yu [04/06/18 11:54 +0200]:
> > > > > +++ Jessica Yu [04/06/18 10:05 +0200]:
> > > > > > +++ Josh Poimboeuf [02/06/18 12:32 -0500]:
> > > > > > > Hi Jessica,
> > > > > > >
> > > > > > > I found a bug:
> > > > > > >
> > > > > > > [root@f25 ~]# modprobe livepatch-sample
> > > > > > > [root@f25 ~]# grep ' u ' /proc/kallsyms
> > > > > > > 81161080 u klp_enable_patch  [livepatch_sample]
> > > > > > > 81a01800 u __fentry__[livepatch_sample]
> > > > > > > 81161250 u klp_unregister_patch  [livepatch_sample]
> > > > > > > 81161870 u klp_register_patch[livepatch_sample]
> > > > > > > 8131f0b0 u seq_printf[livepatch_sample]
> > > > > > >
> > > > > > > Notice that livepatch modules' undefined symbols are showing up in
> > > > > > > /proc/kallsyms.  This can confuse klp_find_object_symbol() which 
can
> > > > > > > cause subtle bugs in livepatch.
> > > > > > >
> > > > > > > I stared at the module kallsyms code for a bit, but I don't see 
the bug.
> > > > > > > Maybe it has something to do with how we save the symbol table in
> > > > > > > copy_module_elf().  Any ideas?
> > > > > >
> > > > > > Hi Josh!
> > > > > >
> > > > > > This is because we preserve the entire symbol table for livepatch
> > > > > > modules, including the SHN_UNDEF symbols. IIRC, this is so that we 
can
> > > > > > still apply relocations properly with apply_relocate_add() after a
> > > > > > to-be-patched object is loaded. Normally we don't save these 
SHN_UNDEF
> > > > > > symbols for modules so they do not appear in /proc/kallsyms.
> > > > >
> > > > > Hm, if having the full symtab in kallsyms is causing trouble, one
> > > > > possibility would be to just have the module kallsyms code simply
> > > > > skip/ignore undef symbols. That's what we technically do for normal
> > > > > modules anyway (we normally cut undef syms out of the symtab). Haven't
> > > > > tested this idea but does that sound like it'd help?
> > > >
> > > > See if the following patch (untested) helps. It does not fix the
> > > > /proc/kallsyms lookup, that requires a separate patch. But it should
> > > > exclude the undef symbols from module_kallsyms_on_each_symbol() and
> > > > thus also from klp_find_object_symbol().
> > >
> > > That seems like it would work.  But wouldn't it be more robust if we
> > > don't store the SHN_UNDEF symbols to start with?  Really it's only the
> > > SHN_LIVEPATCH symbols that we need to keep, right?
> >
> > Hm, didn't we have a reason for preserving the original symbol tables?
> > It's not that we're storing the undef symbols on purpose, it's just
> > that in the case of a livepatch module we keep *all* the symbols.
> > IIRC, the original reasoning was that we needed to keep the original
> > symtab indices in place, otherwise apply_relocate() (which uses the
> > original symbol index encoded in the relocation) won't work.
> > Selectively copying only SHN_LIVEPATCH symbols when building the
> > module's symbol table will unfortunately mess the symbol indices up :/
> > Under these restrictions, it just seemed easier to make kallsyms
> > ignore undef symbols.
>
> Ah, you're right.  I'll try out your patch.

I can confirm that your patch fixes the issue.  Thanks!


BTW you can add my

Reported-by: Josh Poimboeuf 
Tested-by: Josh Poimboeuf 


Thanks for testing! Will clean up the patch and formally repost it.
It'll be queued up in modules-next after the merge window.

Thanks,

Jessica

[RESEND PATCH v5 0/4] kernel hacking: GCC optimization for better debug experience (-Og)

[changbin . du]

From: Changbin Du 

Hi all,
I know some kernel developers was searching for a method to dissable GCC
optimizations, probably they want to apply GCC '-O0' option. But since Linux
kernel replys on GCC optimization to remove some dead code, so '-O0' just
breaks the build. They do need this because they want to debug kernel with
qemu, simics, kgtp or kgdb.

Thanks for the GCC '-Og' optimization level introduced in GCC 4.8, which
offers a reasonable level of optimization while maintaining fast compilation
and a good debugging experience. It is similar to '-O1' while perferring to
keep debug ability over runtime speed. With '-Og', we can build a kernel with
better debug ability and little performance drop after some simple change.

In this series, firstly introduce a new config CONFIG_NO_AUTO_INLINE after two
fixes for this new option. With this option, only functions explicitly marked
with "inline" will  be inlined. This will allow the function tracer to trace
more functions because it only traces functions that the compiler has not
inlined.

Then introduce new config CC_OPTIMIZE_FOR_DEBUGGING which apply '-Og'
optimization level for whole kernel, with a simple fix in fix_to_virt().
Currently I have only tested this option on x86 and ARM platform. Other
platforms should also work but probably need some compiling fixes as what
having done in this series. I leave that to who want to try this debug
option.

Comparison of vmlinux size: a bit smaller.

w/o CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
$ size vmlinux
   textdata bss dec hex filename
22665554   9709674  2920908 3529613621a9388 vmlinux

w/ CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
$ size vmlinux
   textdata bss dec hex filename
21499032   10102758 2920908 3452269820ec64a vmlinux


Comparison of system performance: a bit drop (~6%).
This benchmark of kernel compilation is suggested by Ingo Molnar.
https://lkml.org/lkml/2018/5/2/74

Preparation: Set cpufreq to 'performance'.
for ((cpu=0; cpu<120; cpu++)); do
  G=/sys/devices/system/cpu/cpu$cpu/cpufreq/scaling_governor
  [ -f $G ] && echo performance > $G
done

w/o CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
$ perf stat --repeat 5 --null --pre '\
cp -a kernel ../kernel.copy.$(date +%s); \
rm -rf *;\
git checkout .;  \
echo 1 > /proc/sys/vm/drop_caches;   \
find ../kernel* -type f | xargs cat >/dev/null;  \
make -j kernel >/dev/null;   \
make clean >/dev/null 2>&1;  \
sync'\
 \
make -j8 >/dev/null

 Performance counter stats for 'make -j8' (5 runs):

219.764246652 seconds time elapsed   ( +-  0.78% )

w/ CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
$ perf stat --repeat 5 --null --pre '\
cp -a kernel ../kernel.copy.$(date +%s); \
rm -rf *;\
git checkout .;  \
echo 1 > /proc/sys/vm/drop_caches;   \
find ../kernel* -type f | xargs cat >/dev/null;  \
make -j kernel >/dev/null;   \
make clean >/dev/null 2>&1;  \
sync'\
 \
make -j8 >/dev/null

Performance counter stats for 'make -j8' (5 runs):

 233.574187771 seconds time elapsed  ( +-  0.19% )

v5:
  o Exchange the position of last two patches to avoid compiling error.
v4:
  o Remove aready merged one "regulator: add dummy function 
of_find_regulator_by_node".

Changbin Du (4):
  x86/mm: surround level4_kernel_pgt with #ifdef
CONFIG_X86_5LEVEL...#endif
  kernel hacking: new config NO_AUTO_INLINE to disable compiler
auto-inline optimizations
  ARM: mm: fix build error in fix_to_virt with
CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
  kernel hacking: new config CC_OPTIMIZE_FOR_DEBUGGING to apply GCC -Og
optimization

 Makefile  | 10 ++
 arch/arm/mm/mmu.c |  2 +-
 arch/x86/include/asm/pgtable_64.h |  2 ++
 arch/x86/kernel/head64.c  | 13 ++---
 include/linux/compiler-gcc.h  |  2 +-
 include/linux/compiler.h  |  2 +-
 init/Kconfig  | 19 +++
 lib/Kconfig.debug | 17 +
 8 files changed, 57 insertions(+), 10 deletions(-)

-- 
2.7.4

[PATCH v5 4/4] kernel hacking: new config CC_OPTIMIZE_FOR_DEBUGGING to apply GCC -Og optimization

[changbin . du]

From: Changbin Du 

This will apply GCC '-Og' optimization level which is supported
since GCC 4.8. This optimization level offers a reasonable level
of optimization while maintaining fast compilation and a good
debugging experience. It is similar to '-O1' while perferring
to keep debug ability over runtime speed.

If enabling this option breaks your kernel, you should either
disable this or find a fix (mostly in the arch code). Currently
this option has only been tested on x86_64 and arm platform.

This option can satisfy people who was searching for a method
to disable compiler optimizations so to achieve better kernel
debugging experience with kgdb or qemu.

The main problem of '-Og' is we must not use __attribute__((error(msg))).
The compiler will report error though the call to error function
still can be optimize out. So we must fallback to array tricky.

Comparison of vmlinux size: a bit smaller.

w/o CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
$ size vmlinux
   textdata bss dec hex filename
22665554   9709674  2920908 3529613621a9388 vmlinux

w/ CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
$ size vmlinux
   textdata bss dec hex filename
21499032   10102758 2920908 3452269820ec64a vmlinux

Comparison of system performance: a bit drop (~6%).
This benchmark of kernel compilation is suggested by Ingo Molnar.
https://lkml.org/lkml/2018/5/2/74

Preparation: Set cpufreq to 'performance'.
for ((cpu=0; cpu<120; cpu++)); do
  G=/sys/devices/system/cpu/cpu$cpu/cpufreq/scaling_governor
  [ -f $G ] && echo performance > $G
done

w/o CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
$ perf stat --repeat 5 --null --pre '\
cp -a kernel ../kernel.copy.$(date +%s); \
rm -rf *;\
git checkout .;  \
echo 1 > /proc/sys/vm/drop_caches;   \
find ../kernel* -type f | xargs cat >/dev/null;  \
make -j kernel >/dev/null;   \
make clean >/dev/null 2>&1;  \
sync'\
 \
make -j8 >/dev/null

Performance counter stats for 'make -j8' (5 runs):

219.764246652 seconds time elapsed   ( +-  0.78% )

w/ CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
$ perf stat --repeat 5 --null --pre '\
cp -a kernel ../kernel.copy.$(date +%s); \
rm -rf *;\
git checkout .;  \
echo 1 > /proc/sys/vm/drop_caches;   \
find ../kernel* -type f | xargs cat >/dev/null;  \
make -j kernel >/dev/null;   \
make clean >/dev/null 2>&1;  \
sync'\
 \
make -j8 >/dev/null

Performance counter stats for 'make -j8' (5 runs):

 233.574187771 seconds time elapsed  ( +-  0.19% )

Signed-off-by: Changbin Du 
Acked-by: Steven Rostedt (VMware) 
---
v3:
  o Rename DEBUG_EXPERIENCE to CC_OPTIMIZE_FOR_DEBUGGING
  o Move new configuration item to "General setup->Compiler optimization level"
v2:
  o Improve performance benchmark as suggested by Ingo.
  o Grammar updates in description. (Randy Dunlap)
---
 Makefile |  4 
 include/linux/compiler-gcc.h |  2 +-
 include/linux/compiler.h |  2 +-
 init/Kconfig | 19 +++
 4 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 6720c40..977418a 100644
--- a/Makefile
+++ b/Makefile
@@ -639,6 +639,9 @@ KBUILD_CFLAGS   += $(call cc-disable-warning, 
format-truncation)
 KBUILD_CFLAGS  += $(call cc-disable-warning, format-overflow)
 KBUILD_CFLAGS  += $(call cc-disable-warning, int-in-bool-context)
 
+ifdef CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
+KBUILD_CFLAGS  += $(call cc-option, -Og)
+else
 ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
 KBUILD_CFLAGS  += $(call cc-option,-Oz,-Os)
 KBUILD_CFLAGS  += $(call cc-disable-warning,maybe-uninitialized,)
@@ -649,6 +652,7 @@ else
 KBUILD_CFLAGS   += -O2
 endif
 endif
+endif
 
 KBUILD_CFLAGS += $(call cc-ifversion, -lt, 0409, \
$(call cc-disable-warning,maybe-uninitialized,))
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index b4bf73f..586ed11 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -192,7 +192,7 @@
 
 #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
 
-#ifndef __CHECKER__
+#if !defined(__CHECKER__) && !defined(CONFIG_CC_OPTIMIZE_FOR_DEBUGGING)
 # define __compiletime_warning(message) __attribute__((warning(message)))
 # define __compiletime_error(message) 

Re: [PATCH 0/4] exit: Make unlikely case in mm_update_next_owner() more scalable

[Kirill Tkhai]

On 01.06.2018 18:25, Eric W. Biederman wrote:
> Michal Hocko  writes:
> 
>> On Fri 01-06-18 09:32:42, Eric W. Biederman wrote:
>>> Michal Hocko  writes:
>> [...]
 Group leader exiting early without tearing down the whole thread
 group should be quite rare as well. No question that somebody might do
 that on purpose though...
>>>
>>> The group leader exiting early is a completely legitimate and reasonable
>>> thing to do, even if it is rare.
>>
>> I am not saying it isn't legitimate. But the most common case is the
>> main thread waiting for its threads or calling exit which would tear the
>> whole group down. Is there any easy way to achieve this other than tkill
>> to group leader? Calling exit(3) from the leader performs group exit
>> IIRC.
> 
> pthread_exit from the group leader.
> 
>> I am not arguing this is non-issue. And it certainly is a problem once
>> somebody wants to be nasty... I was more interested how often this
>> really happens for sane workloads.
> 
> That is a fair question.  All I know for certain is that whatever Kirill
> Tkhai's workload was it was triggering this the slow path.

It was triggered on a server, where many VPS of many people are hosted.
Sorry, I have no an idea what they did.

Kirill

[PATCH] ARM64: dts: meson-gxl-s905x-p212: Add phy-supply for usb0

[Neil Armstrong]

Like LibreTech-CC, the USB0 needs the 5V regulator to be enabled to power the
devices on the P212 Reference Design based boards.

Fixes: b9f07cb4f41f ("ARM64: dts: meson-gxl-s905x-p212: enable the USB 
controller")
Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi
index 0cfd701..a1b3101 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi
@@ -189,3 +189,10 @@
  {
status = "okay";
 };
+
+_phy0 {
+   /*
+* HDMI_5V is also used as supply for the USB VBUS.
+*/
+   phy-supply = <_5v>;
+};
-- 
2.7.4

Re: [PATCH v3]: perf record: enable arbitrary event names thru name= modifier

[Alexey Budankov]

Hi,
On 04.06.2018 22:16, Arnaldo Carvalho de Melo wrote:
> Em Mon, Jun 04, 2018 at 06:22:43PM +0300, Alexey Budankov escreveu:
>> On 04.06.2018 17:58, Arnaldo Carvalho de Melo wrote:
>>> Em Mon, Jun 04, 2018 at 05:51:03PM +0300, Alexey Budankov escreveu:
 event names quoted there. If such cases were pointed out then they also 
 could be addressed along with the unit/regression testing mentioned above.
> 
>>> So lests stick to just the unit/regression testing, can you take a look
>>> at that?
>  
>> Sure. Is it enough to run perf record with some quoted event name to make 
>> sure it runs successfully?
> 
> I mentioned tools/perf/tests/attr/, for checking if the perf_event_attr
> was setup the way you intended, and tools/perf/tests/parse-events.c,
> which probably is what we want here, see, for instance, this cset I've
> added recently to have we testing intel_pt event parsing:
> 
> $ git show b3f58c8da64bc63bd0c0a06a4e2cf258a3d20be6
> commit b3f58c8da64bc63bd0c0a06a4e2cf258a3d20be6
> Author: Arnaldo Carvalho de Melo 
> Date:   Fri May 11 11:48:54 2018 -0300
> 
> perf tests parse-events: Add intel_pt parse test
> 
> To avoid regressions such as the one fixed by 4a35a9027f64 ("Revert
> "perf pmu: Fix pmu events parsing rule""), where '-e intel_pt//u' got
> broken, with this new entry in this 'perf tests' subtest, we would have
> caught it before pushing upstream.
> 
> Acked-by: Jiri Olsa 
> Cc: Adrian Hunter 
> Cc: Alexander Shishkin 
> Cc: Andi Kleen 
> Cc: David Ahern 
> Cc: Jiri Olsa 
> Cc: Kan Liang 
> Cc: Namhyung Kim 
> Cc: Peter Zijlstra 
> Cc: Wang Nan 
> Link: 
> https://lkml.kernel.org/n/tip-kw62fys9bwdgsp722so2l...@git.kernel.org
> Signed-off-by: Arnaldo Carvalho de Melo 
> 
> diff --git a/tools/perf/tests/parse-events.c b/tools/perf/tests/parse-events.c
> index 18b06444f230..6829dd416a99 100644
> --- a/tools/perf/tests/parse-events.c
> +++ b/tools/perf/tests/parse-events.c
> @@ -1309,6 +1309,14 @@ static int test__checkevent_config_cache(struct 
> perf_evlist *evlist)
>   return 0;
>  }
>  
> +static int test__intel_pt(struct perf_evlist *evlist)
> +{
> + struct perf_evsel *evsel = perf_evlist__first(evlist);
> +
> + TEST_ASSERT_VAL("wrong name setting", strcmp(evsel->name, 
> "intel_pt//u") == 0);
> + return 0;
> +}
> +
>  static int count_tracepoints(void)
>  {
>   struct dirent *events_ent;
> @@ -1637,6 +1645,11 @@ static struct evlist_test test__events[] = {
>   .check = test__checkevent_config_cache,
>   .id= 51,
>   },
> + {
> + .name  = "intel_pt//u",
> + .check = test__intel_pt,
> + .id= 52,
> + },
>  };
>  
>  static struct evlist_test test__events_pmu[] = {
> 
> See also this one:
> 
> static int
> test__checkevent_breakpoint_len_rw_modifier(struct perf_evlist *evlist)
> {
> struct perf_evsel *evsel = perf_evlist__first(evlist);
> 
> TEST_ASSERT_VAL("wrong exclude_user", !evsel->attr.exclude_user);
> TEST_ASSERT_VAL("wrong exclude_kernel", evsel->attr.exclude_kernel);
> TEST_ASSERT_VAL("wrong exclude_hv", evsel->attr.exclude_hv);
> TEST_ASSERT_VAL("wrong precise_ip", !evsel->attr.precise_ip);
> 
> return test__checkevent_breakpoint_rw(evlist);
> }
> {
> .name  = "mem:0/4:rw:u",
> .check = test__checkevent_breakpoint_len_rw_modifier,
> .id= 44
> },
> 
> 
> I.e. have as many TEST_ASSERT_VAL as you need, checking how parsing the
> event name ends up setting up the evsel, evlist and perf_event_attr.

Ok, I see. But please expect delay in delivery since I am on vacations till 
06/18.

Thanks,
Alexey

> 
> - Arnaldo
> 

[RFC PATCH 1/8] mailbox: ti-msgmgr: Get rid of unused structure members

[Nishanth Menon]

Though q_proxies and q_slices do describe the hardware configuration,
they are not necessary for operation given that the values are
always default. Hence drop the same.

Signed-off-by: Nishanth Menon 
---
 drivers/mailbox/ti-msgmgr.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/mailbox/ti-msgmgr.c b/drivers/mailbox/ti-msgmgr.c
index 78753a87ba4d..7cd5f9c9c97f 100644
--- a/drivers/mailbox/ti-msgmgr.c
+++ b/drivers/mailbox/ti-msgmgr.c
@@ -42,8 +42,6 @@ struct ti_msgmgr_valid_queue_desc {
  * @queue_count:   Number of Queues
  * @max_message_size:  Message size in bytes
  * @max_messages:  Number of messages
- * @q_slices:  Number of queue engines
- * @q_proxies: Number of queue proxies per page
  * @data_first_reg:First data register for proxy data region
  * @data_last_reg: Last data register for proxy data region
  * @tx_polled: Do I need to use polled mechanism for tx
@@ -58,8 +56,6 @@ struct ti_msgmgr_desc {
u8 queue_count;
u8 max_message_size;
u8 max_messages;
-   u8 q_slices;
-   u8 q_proxies;
u8 data_first_reg;
u8 data_last_reg;
bool tx_polled;
@@ -494,8 +490,6 @@ static const struct ti_msgmgr_desc k2g_desc = {
.queue_count = 64,
.max_message_size = 64,
.max_messages = 128,
-   .q_slices = 1,
-   .q_proxies = 1,
.data_first_reg = 16,
.data_last_reg = 31,
.tx_polled = false,
-- 
2.15.1

Re: [PATCH v3] kbuild: check for pkg-config on make {menu,n,g.x}config

[Masahiro Yamada]

Hi Randy,


2018-06-04 11:59 GMT+09:00 Randy Dunlap :
> From: Randy Dunlap 
>
> Each of 'make {menu,n,g,x}config' uses (needs) pkg-config to make sure
> that other required files are present and to determine build flags
> settings, but none of these check that pkg-config itself is present.
> Add a check for all 4 of these targets and update
> Documentation/process/changes.rst to mention 'pkg-config'.
>
> Fixes kernel bugzilla #77511:
> https://bugzilla.kernel.org/show_bug.cgi?id=77511
>
> Signed-off-by: Randy Dunlap 
> Cc: Bjørn Forsman 
> ---
> Strictly speaking, pkg-config is not required if someone is only
> using 'make {menu,n}config' since there are fallbacks for those
> two targets.
>
>  Documentation/process/changes.rst  |8 
>  scripts/kconfig/Makefile   |6 ++
>  scripts/kconfig/check-pkgconfig.sh |   12 
>  3 files changed, 26 insertions(+)
>
> --- linux-next-20180601.orig/scripts/kconfig/Makefile
> +++ linux-next-20180601/scripts/kconfig/Makefile
> @@ -214,11 +214,17 @@ $(obj)/gconf.o: $(obj)/.gconf-cfg
>  $(obj)/zconf.tab.o: $(obj)/zconf.lex.c
>
>  # check if necessary packages are available, and configure build flags
> +# pkg-config check
> +define check_pkg_config
> +   $(CONFIG_SHELL) $(srctree)/scripts/kconfig/check-pkgconfig.sh FORCE


Passing FORCE to check-pkg-config.sh strange.



How about calling your script from filechk_conf_cfg, like this?


define filechk_conf_cfg
$(CONFIG_SHELL) $(srctree)/scripts/kconfig/check-pkgconfig.sh; \
$(CONFIG_SHELL) $<
endef






> +endef
> +
>  define filechk_conf_cfg
> $(CONFIG_SHELL) $<
>  endef
>
>  $(obj)/.%conf-cfg: $(src)/%conf-cfg.sh FORCE
> +   $(call check_pkg_config)
> $(call filechk,conf_cfg)
>
>  clean-files += .*conf-cfg
> --- /dev/null
> +++ linux-next-20180601/scripts/kconfig/check-pkgconfig.sh
> @@ -0,0 +1,12 @@
> +#!/bin/sh
> +# SPDX-License-Identifier: GPL-2.0
> +# Check for pkg-config presence
> +
> +pkgcfg=`command -v pkg-config`
> +
> +if [ "$pkgcfg" = "" ]; then
> +   echo "'make *config' requires 'pkg-config'. Please install it." 1>&2
> +   exit 1  # error
> +fi
> +
> +exit 0


You can remove 'exit 0' at the end.
and move the 'pkgcfg' to the conditional line.

How about something like this?


if [ -z $(command -v pkg-config) ]; then
echo "'make *config' requires 'pkg-config'. Please install it." 1>&2
exit 1
fi


Thanks.



> --- linux-next-20180601.orig/Documentation/process/changes.rst
> +++ linux-next-20180601/Documentation/process/changes.rst
> @@ -81,6 +81,14 @@ The build system has, as of 4.13, switch
>  rather than incremental linking (`ld -r`) for built-in.a intermediate steps.
>  This requires binutils 2.20 or newer.
>
> +pkg-config
> +--
> +
> +The build system, as of 4.18, requires pkg-config to check for installed
> +kconfig tools and to determine flags settings for use in
> +'make {menu,n,g,x}config'.  Previously pkg-config was being used but not
> +verified or documented.
> +
>  Flex
>  
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards
Masahiro Yamada

Re: linux-next: build warning after merge of the mfd tree

[Lee Jones]

On Tue, 05 Jun 2018, Stephen Rothwell wrote:

> Hi Lee,
> 
> After merging the mfd tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
> 
> drivers/mfd/cros_ec_dev.c:265:13: warning: '__remove' defined but not used 
> [-Wunused-function]
>  static void __remove(struct device *dev) { }
>  ^~~~
> 
> Introduced by commit
> 
>   3aa2177e4787 ("mfd: cros_ec: Use devm_kzalloc for private data")

Thanks Stephen.  Will chase today.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [patch 6/8] x86/platform/uv: Use apic_ack_irq()

[Song Liu]

Tested-by: Song Liu 

On Mon, Jun 4, 2018 at 8:33 AM, Thomas Gleixner  wrote:
>

Re: [patch 5/8] x86/ioapic: Use apic_ack_irq()

[Song Liu]

Tested-by: Song Liu 

On Mon, Jun 4, 2018 at 8:33 AM, Thomas Gleixner  wrote:
>

Re: [patch 4/8] irq_remapping: Use apic_ack_irq()

[Song Liu]

Tested-by: Song Liu 

On Mon, Jun 4, 2018 at 8:33 AM, Thomas Gleixner  wrote:
>

Re: [PATCH 13/19] mm/migrate: Use xchg instead of spinlock

[Srikar Dronamraju]

* Peter Zijlstra  [2018-06-04 21:28:21]:

> > if (time_after(jiffies, pgdat->numabalancing_migrate_next_window)) {
> > -   spin_lock(>numabalancing_migrate_lock);
> > -   pgdat->numabalancing_migrate_nr_pages = 0;
> > -   pgdat->numabalancing_migrate_next_window = jiffies +
> > -   msecs_to_jiffies(migrate_interval_millisecs);
> > -   spin_unlock(>numabalancing_migrate_lock);
> > +   if (xchg(>numabalancing_migrate_nr_pages, 0))
> > +   pgdat->numabalancing_migrate_next_window = jiffies +
> > +   msecs_to_jiffies(migrate_interval_millisecs);
>
> Note that both are in fact wrong. That wants to be something like:
>
>   pgdat->numabalancing_migrate_next_window += interval;
>
> Otherwise you stretch every interval by 'jiffies - 
> numabalancing_migrate_next_window'.

Okay, I get your point.


>
> Also, that all wants READ_ONCE/WRITE_ONCE, irrespective of the
> spinlock/xchg.
>
> I suppose the problem here is that PPC has a very nasty test-and-set
> spinlock with fwd progress issues while xchg maps to a fairly simple
> ll/sc that (hopefully) has some hardware fairness.
>
> And pgdata being a rather course data structure (per node?) there could
> be a lot of CPUs stomping on this here thing.
>
> So simpler not really, but better for PPC.
>

unsigned long interval = READ_ONCE(pgdat->numabalancing_migrate_next_window);

if (time_after(jiffies, interval)) {
interval += msecs_to_jiffies(migrate_interval_millisecs));
if (xchg(>numabalancing_migrate_nr_pages, 0))
WRITE_ONCE(pgdat->numabalancing_migrate_next_window, interval);
}

Something like this?

Re: [PATCH v2 5/9] x86: bug: prevent gcc distortions

[kbuild test robot]

Hi Nadav,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.17 next-20180604]
[cannot apply to tip/x86/core]
[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/Nadav-Amit/x86-macrofying-inline-asm-for-better-compilation/20180605-124313
config: i386-tinyconfig (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=i386 

All error/warnings (new ones prefixed by >>):

   In file included from include/linux/bug.h:5:0,
from include/linux/crypto.h:23,
from arch/x86/kernel/asm-offsets.c:9:
   include/linux/ktime.h: In function 'ktime_divns':
>> arch/x86/include/asm/bug.h:31:17: error: invalid application of 'sizeof' to 
>> incomplete type 'struct bug_entry'
"i" (sizeof(struct bug_entry)));  \
^
   arch/x86/include/asm/bug.h:37:2: note: in expansion of macro '_BUG_FLAGS'
 _BUG_FLAGS(ASM_UD2, 0); \
 ^~
   include/asm-generic/bug.h:176:47: note: in expansion of macro 'BUG'
#define BUG_ON(condition) do { if (condition) BUG(); } while (0)
  ^~~
>> include/linux/ktime.h:150:2: note: in expansion of macro 'BUG_ON'
 BUG_ON(div < 0);
 ^~
   include/linux/rhashtable.h: In function 'rhashtable_lookup_insert_fast':
>> arch/x86/include/asm/bug.h:31:17: error: invalid application of 'sizeof' to 
>> incomplete type 'struct bug_entry'
"i" (sizeof(struct bug_entry)));  \
^
   arch/x86/include/asm/bug.h:37:2: note: in expansion of macro '_BUG_FLAGS'
 _BUG_FLAGS(ASM_UD2, 0); \
 ^~
   include/asm-generic/bug.h:176:47: note: in expansion of macro 'BUG'
#define BUG_ON(condition) do { if (condition) BUG(); } while (0)
  ^~~
>> include/linux/rhashtable.h:936:2: note: in expansion of macro 'BUG_ON'
 BUG_ON(ht->p.obj_hashfn);
 ^~
   include/linux/rhashtable.h: In function 'rhashtable_lookup_get_insert_fast':
>> arch/x86/include/asm/bug.h:31:17: error: invalid application of 'sizeof' to 
>> incomplete type 'struct bug_entry'
"i" (sizeof(struct bug_entry)));  \
^
   arch/x86/include/asm/bug.h:37:2: note: in expansion of macro '_BUG_FLAGS'
 _BUG_FLAGS(ASM_UD2, 0); \
 ^~
   include/asm-generic/bug.h:176:47: note: in expansion of macro 'BUG'
#define BUG_ON(condition) do { if (condition) BUG(); } while (0)
  ^~~
   include/linux/rhashtable.h:962:2: note: in expansion of macro 'BUG_ON'
 BUG_ON(ht->p.obj_hashfn);
 ^~
   include/linux/rhashtable.h: In function 'rhashtable_lookup_insert_key':
>> arch/x86/include/asm/bug.h:31:17: error: invalid application of 'sizeof' to 
>> incomplete type 'struct bug_entry'
"i" (sizeof(struct bug_entry)));  \
^
   arch/x86/include/asm/bug.h:37:2: note: in expansion of macro '_BUG_FLAGS'
 _BUG_FLAGS(ASM_UD2, 0); \
 ^~
   include/asm-generic/bug.h:176:47: note: in expansion of macro 'BUG'
#define BUG_ON(condition) do { if (condition) BUG(); } while (0)
  ^~~
   include/linux/rhashtable.h:996:2: note: in expansion of macro 'BUG_ON'
 BUG_ON(!ht->p.obj_hashfn || !key);
 ^~
   include/linux/rhashtable.h: In function 'rhashtable_lookup_get_insert_key':
>> arch/x86/include/asm/bug.h:31:17: error: invalid application of 'sizeof' to 
>> incomplete type 'struct bug_entry'
"i" (sizeof(struct bug_entry)));  \
^
   arch/x86/include/asm/bug.h:37:2: note: in expansion of macro '_BUG_FLAGS'
 _BUG_FLAGS(ASM_UD2, 0); \
 ^~
   include/asm-generic/bug.h:176:47: note: in expansion of macro 'BUG'
#define BUG_ON(condition) do { if (condition) BUG(); } while (0)
  ^~~
   include/linux/rhashtable.h:1020:2: note: in expansion of macro 'BUG_ON'
 BUG_ON(!ht->p.obj_hashfn || !key);
 ^~
   include/linux/crypto.h: In function 'crypto_blkcipher_cast':
>> arch/x86/include/asm/bug.h:31:17: error: invalid application of 'sizeof' to 
>> incomplete type 'struct bug_entry'
"i" (sizeof(struct bug_entry)));  \
^
   arch/x86/include/asm/bug.h:37:2: note: in expansion of macro '_BUG_FLAGS'
 _BUG_FLAGS(ASM_UD2, 0); \
 ^~
   include/asm-generic/bug.h:176:47: note: in expansion of macro 'BUG'
#define BUG_ON(condition) do { if (condition) BUG(); } while (0)
 

Re: [PATCH 1/2] platform/x86: asus-wmi: Call new led hw_changed API on kbd brightness change

[Hans de Goede]

Hi,

On 05-06-18 04:31, Darren Hart wrote:

On Mon, Jun 04, 2018 at 04:23:04PM +0200, Hans de Goede wrote:

Hi,

On 04-06-18 15:51, Daniel Drake wrote:

On Mon, Jun 4, 2018 at 7:22 AM, Hans de Goede  wrote:

Is this really a case of the hardware itself processing the
keypress and then changing the brightness *itself* ?

  From the "[PATCH 2/2] platform/x86: asus-wmi: Add keyboard backlight
toggle support" patch I get the impression that the driver is
modifying the brightness from within the kernel rather then the
keyboard controller are ACPI embeddec-controller doing it itself.

If that is the case then the right fix is for the driver to stop
mucking with the brighness itself, it should simply report the
right keyboard events and export a led interface and then userspace
will do the right thing (and be able to offer flexible policies
to the user).


Before this modification, the driver reports the brightness keypresses
to userspace and then userspace can respond by changing the brightness
level, as you describe.

You are right in that the hardware doesn't change the brightness
directly itself, which is the normal usage of LED_BRIGHT_HW_CHANGED.

However this approach was suggested by Benjamin Berg and Bastien
Nocera in the thread: Re: [PATCH v2] platform/x86: asus-wmi: Add
keyboard backlight toggle support
https://marc.info/?l=linux-kernel=152639169210655=2

The issue is that we need to support a new "keyboard backlight
brightness cycle" key (in the patch that follows this one) which
doesn't fit into any definitions of keys recognised by the kernel and
likewise there's no userspace code to handle it.

If preferred we could leave the standard brightness keys behaving as
they are (input events) and make the new special key type directly
handled by the kernel?


I'm sorry that Benjamin and Bastien steered you in this direction,
IMHO none of it should be handled in the kernel.

Anytime any sort of input is directly responded to by the kernel
it is a huge PITA to deal with from userspace. The kernel will have
a simplistic implementation which almost always is wrong.

Benjamin, remember the pain we went through with rfkill hotkey
presses being handled in the kernel ?

And then there is the whole acpi_video.brightness_switch_enabled
debacle, which is an option which defaults to true which causes
the kernel to handle LCD brightness key presses, which all distros
have been patching to default to off for ages.

To give a concrete example, we may want to implement software
dimming / auto-off of the kbd backlight when the no keys are
touched for x seconds. This would seriously get in the way of that.

So sorry, but NACK to this series.


So if instead of modifying the LED value, the kernel platform drivers
converted the TOGGLE into a cycle even by converting to an UP event
based on awareness of the plaform specific max value and the read
current value, leaving userspace to act on the TOGGLE/UP events - would
that be preferable?


I was thinking about doing that as a workaround myself, but I'm not sure
that is a good idea (because of e.g. races with userspace auto-correcting
the brightness based on ambient light and/or keyboard activity).

As I see it there are 2 proper solutions to this:

1) Make userspace treat KEY_KBDILLUMTOGGLE as a cycle key, this is
what the kbd-backlight on most laptops with a single hotkey (*) does
in cases where this is handled in firmware, rather then left to the
OS. The handled in firmware is the case which I created the
led_classdev_notify_brightness_hw_changed() API for. This would be
my preferred solution and I believe that Benjamin is discussing this
with Bastien ATM.

2) Add a new KEY_KBDILLUMCYCLE event and send that for the TOGGLE code
on these laptops.

Regards,

Hans



*) Rather then separate up / down hotkeys




Something like:

if (code == TOGGLE && ledval < ledmax)
code = UP;

sparse_keymap_report_event(..., code, ...)

}

Re: [PATCH 01/19] sched/numa: Remove redundant field.

[Mel Gorman]

On Mon, Jun 04, 2018 at 03:30:10PM +0530, Srikar Dronamraju wrote:
> numa_entry is a list_head defined in task_struct, but never used.
> 
> No functional change
> 
> Signed-off-by: Srikar Dronamraju 

Acked-by: Mel Gorman 

-- 
Mel Gorman
SUSE Labs

Re: [PATCH V1 3/3] scsi: ufs: Add sysfs support for ufs provision

[Greg Kroah-Hartman]

On Tue, Jun 05, 2018 at 08:16:50AM +, Stanislav Nijnikov wrote:
> Hi Sayali,
> 
> I think that passing an array of values in a string is not proper way
> to work with a sysfs entry. There are binary attributes to do such
> things.

No, don't do that, sysfs is for "one value per file", and binary
attributes are for "hardware value pass-through" type stuff.  Unless
this is "raw" data straight from the hardware, binary does not work, and
neither does a normal sysfs file either.

So this needs to be reworked please.

thanks,

greg k-h

Re: [PATCH v2 21/21] sparc64: use match_string() helper

[Yisheng Xie]

Hi Andy,

On 2018/6/4 18:06, Andy Shevchenko wrote:
> On Mon, Jun 4, 2018 at 4:06 AM, Yisheng Xie  wrote:
>> Hi Andy,
>>
>> On 2018/6/1 19:34, Andy Shevchenko wrote:
>>> On Thu, May 31, 2018 at 2:11 PM, Yisheng Xie  wrote:
 match_string() returns the index of an array for a matching string,
 which can be used instead of open coded variant.
>>>
 @@ -512,10 +512,9 @@ static unsigned long __init mdesc_cpu_hwcap_list(void)
 break;
 }
 }
>>>
>>> It seems previous loop also can be replaced.
>>
>> No, because the there is an NULL in the middle of the array hwcaps:
>>  static const char *hwcaps[] = {
>>   "flush", "stbar", "swap", "muldiv", "v9",
>>   "ultra3", "blkinit", "n2",
>>
>>   /* These strings are as they appear in the machine description
>>* 'hwcap-list' property for cpu nodes.
>>*/
>>   "mul32", "div32", "fsmuld", "v8plus", "popc", "vis", "vis2",
>>   "ASIBlkInit", "fmaf", "vis3", "hpc", "random", "trans", "fjfmau",
>>   "ima", "cspare", "pause", "cbcond", NULL /*reserved for crypto */,
>>   "adp",
>>   };
> 
> Actually you can.
> What you need is to add string literal instead of NULL and make an
> additional condition after match_string() in all users (not to many),
> something like
> 
> i = match_string();
> if (i < 0)
>  ...
> if (BIT(i) == HWCAP_SPARC_CRYPTO) // or !=

OK, I get your point.

Thanks
Yisheng
>  ...
> 

Re: [PATCH] usb: xhci: remove the code build warning

[Thierry Reding]

On Tue, Jun 05, 2018 at 04:54:17PM +0800, gengdongjiu wrote:
> 
> 
> On 2018/6/5 16:40, Greg KH wrote:
> > On Wed, Jun 06, 2018 at 12:35:00AM +0800, Dongjiu Geng wrote:
> >> Initialize the 'err' variate to remove the build warning,
> >> the warning is shown as below:
> >>
> >> drivers/usb/host/xhci-tegra.c: In function ‘tegra_xusb_mbox_thread’:
> >> drivers/usb/host/xhci-tegra.c:552:6: warning: ‘err’ may be used 
> >> uninitialized in this function [-Wuninitialized]
> >> drivers/usb/host/xhci-tegra.c:482:6: note: ‘err’ was declared here
> >>
> >> Signed-off-by: Dongjiu Geng 
> >> ---
> > 
> > Any hint as to what commit caused this warning to show up?
> 
> It seems below commit:
> 
> commit e84fce0f8837496a48d11086829bdbe170358b7a
> Author: Thierry Reding 
> Date:   Thu Feb 11 18:10:48 2016 +0100
> 
> usb: xhci: Add NVIDIA Tegra XUSB controller driver
> 
> Add support for the on-chip XUSB controller present on Tegra SoCs. This
> controller, when loaded with external firmware, exposes an interface
> compliant with xHCI. This driver loads the firmware, starts the
> controller, and is able to service host-specific messages sent by the
> controller's firmware.
> 
> The controller also supports USB device mode as well as powergating
> of the SuperSpeed and host-controller logic when not in use, but
> support for these is not yet implemented.
> 
> Based on work by:
>   Ajay Gupta 
>   Bharath Yadav 
>   Andrew Bresticker 
> 
> Cc: Mathias Nyman 
> Cc: Greg Kroah-Hartman 
> Acked-by: Mathias Nyman 
> Signed-off-by: Thierry Reding 

I've never seen this warning before. It's also a false positive in that
technically the mailbox message will always have at least one bit set in
"mask". However, I don't see how the compiler could know about it, given
that the data comes from an external source, so I think this makes sense
as a hint to the compiler. So:

Acked-by: Thierry Reding 

Can you provide more detail on what exact version of which compiler you
used that triggered this? I wonder why it's never presented itself with
the compiler that I use.

Thierry


signature.asc
Description: PGP signature

[RFC PATCH 1/6] Documentation: arm: ti: Add bindings for AM654 SoC

[Nishanth Menon]

The AM654 SoC is a lead device of the K3 Multicore SoC architecture
platform, targeted for broad market and industrial control with aim to
meet the complex processing needs of modern embedded products.

Some highlights of this SoC are:
* Quad ARMv8 A53 cores split over two clusters
* GICv3 compliant GIC500
* Configurable L3 Cache and IO-coherent architecture
* Dual lock-step capable R5F uC for safety-critical applications
* High data throughput capable distributed DMA architecture under NAVSS
* Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual
  PRUs and dual RTUs
* Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
* Centralized System Controller for Security, Power, and Resource
  management.
* Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD
* Flash subystem with OSPI and Hyperbus interfaces
* Multimedia capability with CAL, DSS7-UL, SGX544, McASP
* Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI,
  GPIO

See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7

Signed-off-by: Nishanth Menon 
---
 Documentation/devicetree/bindings/arm/ti/k3.txt | 33 +
 MAINTAINERS |  7 ++
 2 files changed, 40 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/ti/k3.txt

diff --git a/Documentation/devicetree/bindings/arm/ti/k3.txt 
b/Documentation/devicetree/bindings/arm/ti/k3.txt
new file mode 100644
index ..cbabb1b89f6f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/ti/k3.txt
@@ -0,0 +1,33 @@
+Texas Instruments K3 Multicore SoC architecture device tree bindings
+
+
+Boards based on K3 Multicore SoC architecture shall have the following 
property:
+- compatible: Every hardware block introduced in K3 Multicore SoC
+  architecture shall be of the form:
+  "ti,XXX-YYY", where:
+ 'XXX' represents the specific SoC part for which the support is added.
+ 'YYY' represents the corresponding peripheral in SoC being supported.
+
+  NOTE: Generic devices such as GIC or legacy devices shall use the specified
+  compatible for those devices.
+
+  Example:
+compatible = "ti,am654-i2c";
+
+SoCs
+---
+
+Each device tree root node must specify which exact SoC in K3 Multicore SoC
+architecture it uses, using one of the following compatible values:
+
+- AM654
+  compatible = "ti,am654";
+
+Boards
+---
+
+In addition, each device tree root node must specify which one or more
+of the following board-specific compatible values:
+
+- AM654 EVM
+  compatible = "ti,am654-evm", "ti,am654";
diff --git a/MAINTAINERS b/MAINTAINERS
index f39a8de1bbd7..cfb35b252ac7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2086,6 +2086,13 @@ L:   linux-kernel@vger.kernel.org
 S: Maintained
 F: drivers/memory/*emif*
 
+ARM/TEXAS INSTRUMENTS K3 ARCHITECTURE
+M: Tero Kristo 
+M: Nishanth Menon 
+L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
+S: Supported
+F: Documentation/devicetree/bindings/arm/ti/k3.txt
+
 ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE
 M: Santosh Shilimkar 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
-- 
2.15.1

[RFC PATCH 0/6] arm64: Initial support Texas Instrument's AM654 Platform

[Nishanth Menon]

Hi,

The following series enables support for newest addition in TI's SoC
portfolio - AM654 SoC.

The series is an RFC based off next-20180604 and will post formally once
v4.18-rc1 is available.

The series (part 1 of 4) is available here:
https://github.com/nmenon/linux-2.6-playground/commits/upstream/next-20180604/k3-1-am6-base

Full Boot log is available here: https://pastebin.ubuntu.com/p/vWCzMKtBCW/

The AM654 SoC is a lead device of the K3 Multicore SoC architecture
platform, targeted for broad market and industrial control with aim to
meet the complex processing needs of modern embedded products.

The Linux development follows closely the 66AK2G SoC model in aarch64.

See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7

Lokesh Vutla (1):
  serial: 8250_omap: Make 8250_omap driver driver depend on ARCH_K3

Nishanth Menon (5):
  Documentation: arm: ti: Add bindings for AM654 SoC
  arm64: Add support for TI's K3 Multicore SoC architecture
  serial: 8250_omap: Add support for AM654 UART controller
  arm64: dts: ti: Add Support for AM654 SoC
  arm64: dts: ti: Add support for AM654 EVM base board

 Documentation/devicetree/bindings/arm/ti/k3.txt|  33 +
 .../devicetree/bindings/serial/omap_serial.txt |   1 +
 MAINTAINERS|   9 ++
 arch/arm64/Kconfig.platforms   |   7 +
 arch/arm64/boot/dts/Makefile   |   1 +
 arch/arm64/boot/dts/ti/Makefile|   9 ++
 arch/arm64/boot/dts/ti/k3-am6.dtsi | 144 +
 arch/arm64/boot/dts/ti/k3-am654-base-board.dts |  40 ++
 arch/arm64/boot/dts/ti/k3-am654.dtsi   | 117 +
 drivers/soc/ti/Kconfig |  14 ++
 drivers/tty/serial/8250/8250_omap.c|   1 +
 drivers/tty/serial/8250/Kconfig|   2 +-
 12 files changed, 377 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/arm/ti/k3.txt
 create mode 100644 arch/arm64/boot/dts/ti/Makefile
 create mode 100644 arch/arm64/boot/dts/ti/k3-am6.dtsi
 create mode 100644 arch/arm64/boot/dts/ti/k3-am654-base-board.dts
 create mode 100644 arch/arm64/boot/dts/ti/k3-am654.dtsi

-- 
2.15.1

[RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller

[Nishanth Menon]

AM654 uses a UART controller that is compatible (partially) with
existing 8250 UART, however, has a few differences with respect to DMA
support and control paths. Introduce a base definition that allows us
to build up the differences in follow on patches.

Cc: Sekhar Nori 
Cc: Vignesh R 
Signed-off-by: Nishanth Menon 
---
 Documentation/devicetree/bindings/serial/omap_serial.txt | 1 +
 drivers/tty/serial/8250/8250_omap.c  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt 
b/Documentation/devicetree/bindings/serial/omap_serial.txt
index 4b0f05adb228..c35d5ece1156 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -1,6 +1,7 @@
 OMAP UART controller
 
 Required properties:
+- compatible : should be "ti,am654-uart" for AM654 controllers
 - compatible : should be "ti,omap2-uart" for OMAP2 controllers
 - compatible : should be "ti,omap3-uart" for OMAP3 controllers
 - compatible : should be "ti,omap4-uart" for OMAP4 controllers
diff --git a/drivers/tty/serial/8250/8250_omap.c 
b/drivers/tty/serial/8250/8250_omap.c
index 1b337fee07ed..a019286f8bb6 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -1115,6 +1115,7 @@ static const u8 am3352_habit = OMAP_DMA_TX_KICK | 
UART_ERRATA_CLOCK_DISABLE;
 static const u8 dra742_habit = UART_ERRATA_CLOCK_DISABLE;
 
 static const struct of_device_id omap8250_dt_ids[] = {
+   { .compatible = "ti,am654-uart" },
{ .compatible = "ti,omap2-uart" },
{ .compatible = "ti,omap3-uart" },
{ .compatible = "ti,omap4-uart", .data = _habit, },
-- 
2.15.1

[RFC PATCH 7/8] drivers: mailbox: Make ti-msgmr driver depend on ARCH_K3

[Nishanth Menon]

ti-msgmr driver can support K3 platforms as well.

Signed-off-by: Nishanth Menon 
---
 drivers/mailbox/Kconfig | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 725dce5ba62d..f87a857d21a5 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -99,12 +99,12 @@ config STI_MBOX
 
 config TI_MESSAGE_MANAGER
tristate "Texas Instruments Message Manager Driver"
-   depends on ARCH_KEYSTONE
+   depends on ARCH_KEYSTONE || ARCH_K3
help
  An implementation of Message Manager slave driver for Keystone
- architecture SoCs from Texas Instruments. Message Manager is a
- communication entity found on few of Texas Instrument's keystone
- architecture SoCs. These may be used for communication between
+ and K3 architecture SoCs from Texas Instruments. Message Manager
+ is a communication entity found on few of Texas Instrument's keystone
+ and K3 architecture SoCs. These may be used for communication between
  multiple processors within the SoC. Select this driver if your
  platform has support for the hardware block.
 
-- 
2.15.1

[RFC PATCH 6/8] mailbox: ti-msgmgr: Add support for Secure Proxy

[Nishanth Menon]

Secure Proxy is another communication scheme in Texas Instrument's
devices intended to provide an unique communication path from various
processors in the System on Chip(SoC) to a central System Controller.

Secure proxy is, in effect, an evolution of current generation Message
Manager hardware block found in K2G devices. However the following
changes have taken place:

Secure Proxy instance exposes "threads" or "proxies" which is
primary representation of "a" communication channel. Each thread is
preconfigured by System controller configuration based on SoC usage
requirements. Secure proxy by itself represents a single "queue" of
communication but allows the proxies to be independently operated.

Each Secure proxy thread can uniquely have their own error and threshold
interrupts allowing for more fine control of IRQ handling.

Provide the driver support for Secure Proxy and thread instances.

NOTE: Secure proxy configuration is only done by System Controller,
hence these are assumed to be pre-configured instances.

See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7

Signed-off-by: Nishanth Menon 
---
 drivers/mailbox/ti-msgmgr.c | 233 ++--
 1 file changed, 205 insertions(+), 28 deletions(-)

diff --git a/drivers/mailbox/ti-msgmgr.c b/drivers/mailbox/ti-msgmgr.c
index a37d6a4b392f..3e30b80c6401 100644
--- a/drivers/mailbox/ti-msgmgr.c
+++ b/drivers/mailbox/ti-msgmgr.c
@@ -25,6 +25,17 @@
 #define Q_STATE_OFFSET(queue)  ((queue) * 0x4)
 #define Q_STATE_ENTRY_COUNT_MASK   (0xFFF000)
 
+#define SPROXY_THREAD_OFFSET(tid) (0x1000 * (tid))
+#define SPROXY_THREAD_DATA_OFFSET(tid, reg) \
+   (SPROXY_THREAD_OFFSET(tid) + ((reg) * 0x4) + 0x4)
+
+#define SPROXY_THREAD_STATUS_OFFSET(tid) (SPROXY_THREAD_OFFSET(tid))
+
+#define SPROXY_THREAD_STATUS_COUNT_MASK (0xFF)
+
+#define SPROXY_THREAD_CTRL_OFFSET(tid) (0x1000 + SPROXY_THREAD_OFFSET(tid))
+#define SPROXY_THREAD_CTRL_DIR_MASK (0x1 << 31)
+
 /**
  * struct ti_msgmgr_valid_queue_desc - SoC valid queues meant for this 
processor
  * @queue_id:  Queue Number for this path
@@ -45,12 +56,15 @@ struct ti_msgmgr_valid_queue_desc {
  * @data_first_reg:First data register for proxy data region
  * @data_last_reg: Last data register for proxy data region
  * @status_cnt_mask:   Mask for getting the status value
+ * @status_err_mask:   Mask for getting the error value, if applicable
  * @tx_polled: Do I need to use polled mechanism for tx
  * @tx_poll_timeout_ms: Timeout in ms if polled
  * @valid_queues:  List of Valid queues that the processor can access
  * @data_region_name:  Name of the proxy data region
  * @status_region_name:Name of the proxy status region
+ * @ctrl_region_name:  Name of the proxy control region
  * @num_valid_queues:  Number of valid queues
+ * @is_sproxy: Is this an Secure Proxy instance?
  *
  * This structure is used in of match data to describe how integration
  * for a specific compatible SoC is done.
@@ -62,12 +76,15 @@ struct ti_msgmgr_desc {
u8 data_first_reg;
u8 data_last_reg;
u32 status_cnt_mask;
+   u32 status_err_mask;
bool tx_polled;
int tx_poll_timeout_ms;
const struct ti_msgmgr_valid_queue_desc *valid_queues;
const char *data_region_name;
const char *status_region_name;
+   const char *ctrl_region_name;
int num_valid_queues;
+   bool is_sproxy;
 };
 
 /**
@@ -80,6 +97,7 @@ struct ti_msgmgr_desc {
  * @queue_buff_start: First register of Data Buffer
  * @queue_buff_end: Last (or confirmation) register of Data buffer
  * @queue_state: Queue status register
+ * @queue_ctrl: Queue Control register
  * @chan:  Mailbox channel
  * @rx_buff:   Receive buffer pointer allocated at probe, max_message_size
  */
@@ -92,6 +110,7 @@ struct ti_queue_inst {
void __iomem *queue_buff_start;
void __iomem *queue_buff_end;
void __iomem *queue_state;
+   void __iomem *queue_ctrl;
struct mbox_chan *chan;
u32 *rx_buff;
 };
@@ -102,6 +121,7 @@ struct ti_queue_inst {
  * @desc:  Description of the SoC integration
  * @queue_proxy_region:Queue proxy region where queue buffers are 
located
  * @queue_state_debug_region:  Queue status register regions
+ * @queue_ctrl_region: Queue Control register regions
  * @num_valid_queues:  Number of valid queues defined for the processor
  * Note: other queues are probably reserved for other processors
  * in the SoC.
@@ -114,6 +134,7 @@ struct ti_msgmgr_inst {
const struct ti_msgmgr_desc *desc;
void __iomem *queue_proxy_region;
void __iomem *queue_state_debug_region;
+   void __iomem *queue_ctrl_region;
u8 num_valid_queues;
struct ti_queue_inst *qinsts;
struct mbox_controller mbox;
@@ -144,6 +165,31 @@ ti_msgmgr_queue_get_num_messages(const 

[RFC PATCH 5/8] dt-bindings: mailbox: ti,message-manager: Add support for secure proxy threads

[Nishanth Menon]

Secure Proxy is another communication scheme in Texas Instrument's
devices intended to provide an unique communication path from various
processors in the System on Chip(SoC) to a central System Controller.

Secure proxy is, in effect, an evolution of current generation Message
Manager hardware block found in K2G devices. However the following
changes have taken place:

Secure Proxy instance exposes "threads" or "proxies" which is
primary representation of "a" communication channel. Each thread is
preconfigured by System controller configuration based on SoC usage
requirements. Secure proxy by itself represents a single "queue" of
communication but allows the proxies to be independently operated.

Each Secure proxy thread can uniquely have their own error and threshold
interrupts allowing for more fine control of IRQ handling.

Provide an hardware description of the same for device tree
representation.

See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7

Signed-off-by: Nishanth Menon 
---
 .../bindings/mailbox/ti,message-manager.txt| 58 +++---
 1 file changed, 50 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt 
b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
index ebf0e3710cee..de796e90cac6 100644
--- a/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
+++ b/Documentation/devicetree/bindings/mailbox/ti,message-manager.txt
@@ -7,22 +7,40 @@ manager is broken up into queues in different address regions 
that are called
 "proxies" - each instance is unidirectional and is instantiated at SoC
 integration level to indicate receive or transmit path.
 
+This can also be used to describe Texas Instrument's Secure Proxy
+controller that allows for individually configurable "threads" or
+"proxies" which allow for independent communication scheme.
+
 Message Manager Device Node:
 ===
 Required properties:
 
-- compatible:  Shall be: "ti,k2g-message-manager"
-- reg-namesqueue_proxy_region - Map the queue proxy region.
-   queue_state_debug_region - Map the queue state debug
-   region.
+- compatible:  Shall be one of: "ti,k2g-message-manager",
+   "ti,am654-secure-proxy"
+- reg-namesfor ti,k2g-message-manager, the following shall exist:
+   queue_proxy_region - Map the queue proxy region.
+   queue_state_debug_region - Map the queue state
+   debug region.
+   for ti,am654-secure-proxy, the following shall exist:
+   target_data - Map the proxy data region
+   rt - Map the realtime status region
+   scfg - Map the configuration region
 - reg: Contains the register map per reg-names.
-- #mbox-cells  Shall be 2. Contains the queue ID and proxy ID in that
-   order referring to the transfer path.
+- #mbox-cells  for ti,k2g-message-manager, Shall be 2. Contains the
+   queue ID and proxy ID in the following order referring
+   to the transfer path:
+   queue_proxy_region - Map the queue proxy region.
+   queue_state_debug_region - Map the queue state
+   debug region.
+   for ti,am654-secure-proxy, Shall be 1 and shall refer
+   to the transfer path called thread.
 - interrupt-names: Contains interrupt names matching the rx transfer path
for a given SoC. Receive interrupts shall be of the
-   format: "rx_".
-   For ti,k2g-message-manager, this shall contain:
+   format:
+   For ti,k2g-message-manager, this shall be: "rx_"
+   and shall contain:
"rx_005", "rx_057"
+   for ti,am654-secure-proxy, this shall be: "rx_".
 - interrupts:  Contains the interrupt information corresponding to
interrupt-names property.
 
@@ -48,3 +66,27 @@ Example(K2G):
< 0 0>;
[...]
};
+
+Example(AM654):
+
+
+   secure_proxy: secure_proxy@32c0 {
+   compatible = "ti,am654-secure-proxy";
+   #mbox-cells = <1>;
+   reg-names = "target_data", "rt", "scfg";
+   reg = <0x0 0x32c0 0x0 0x10>,
+ <0x0 0x3240 0x0 0x10>,
+ <0x0 0x3280 0x0 0x10>;
+   interrupt-names = "rx_011";
+   interrupts = ;
+   };
+
+   

[RFC PATCH 0/8] mailbox: ti-msgmgr: Add support for AM654 Secure Proxy

[Nishanth Menon]

Hi,

The following series enables support for Secure Proxy in newest addition in 
TI's SoC
portfolio - AM654 SoC.

The series is an RFC based off next-20180604 and will post formally once
v4.18-rc1 is available.

The DT and ARCH part of the series is based on 
https://marc.info/?l=linux-arm-kernel=152817866312732=2

The series (part 2 of 4) is available here:
https://github.com/nmenon/linux-2.6-playground/commits/upstream/next-20180604/k3-2-am6-sproxy

Full Boot log is available here: https://pastebin.ubuntu.com/p/vWCzMKtBCW/

See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7

Nishanth Menon (8):
  mailbox: ti-msgmgr: Get rid of unused structure members
  mailbox: ti-msgmgr: Allocate Rx channel resources only on request
  mailbox: ti-msgmgr: Change message count mask to be descriptor based
  mailbox: ti-msgmgr: Move the memory region name to descriptor
  dt-bindings: mailbox: ti,message-manager: Add support for secure proxy
threads
  mailbox: ti-msgmgr: Add support for Secure Proxy
  drivers: mailbox: Make ti-msgmr driver depend on ARCH_K3
  arm64: dts: ti: k3-am6: Add Secure Proxy instance

 .../bindings/mailbox/ti,message-manager.txt|  58 +++-
 arch/arm64/boot/dts/ti/k3-am6.dtsi |  11 +
 drivers/mailbox/Kconfig|   8 +-
 drivers/mailbox/ti-msgmgr.c| 353 +
 4 files changed, 351 insertions(+), 79 deletions(-)

-- 
2.15.1

[RFC PATCH 3/8] mailbox: ti-msgmgr: Change message count mask to be descriptor based

[Nishanth Menon]

Change mask used to extract the message count to be descriptor based.

This is to support changes for count location for various SoC
solutions.

Signed-off-by: Nishanth Menon 
---
 drivers/mailbox/ti-msgmgr.c | 25 ++---
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/drivers/mailbox/ti-msgmgr.c b/drivers/mailbox/ti-msgmgr.c
index 7221590c409c..2952339a8446 100644
--- a/drivers/mailbox/ti-msgmgr.c
+++ b/drivers/mailbox/ti-msgmgr.c
@@ -44,6 +44,7 @@ struct ti_msgmgr_valid_queue_desc {
  * @max_messages:  Number of messages
  * @data_first_reg:First data register for proxy data region
  * @data_last_reg: Last data register for proxy data region
+ * @status_cnt_mask:   Mask for getting the status value
  * @tx_polled: Do I need to use polled mechanism for tx
  * @tx_poll_timeout_ms: Timeout in ms if polled
  * @valid_queues:  List of Valid queues that the processor can access
@@ -58,6 +59,7 @@ struct ti_msgmgr_desc {
u8 max_messages;
u8 data_first_reg;
u8 data_last_reg;
+   u32 status_cnt_mask;
bool tx_polled;
int tx_poll_timeout_ms;
const struct ti_msgmgr_valid_queue_desc *valid_queues;
@@ -116,20 +118,24 @@ struct ti_msgmgr_inst {
 
 /**
  * ti_msgmgr_queue_get_num_messages() - Get the number of pending messages
+ * @d: Description of message manager
  * @qinst: Queue instance for which we check the number of pending messages
  *
  * Return: number of messages pending in the queue (0 == no pending messages)
  */
-static inline int ti_msgmgr_queue_get_num_messages(struct ti_queue_inst *qinst)
+static inline int
+ti_msgmgr_queue_get_num_messages(const struct ti_msgmgr_desc *d,
+struct ti_queue_inst *qinst)
 {
u32 val;
+   u32 status_cnt_mask = d->status_cnt_mask;
 
/*
 * We cannot use relaxed operation here - update may happen
 * real-time.
 */
-   val = readl(qinst->queue_state) & Q_STATE_ENTRY_COUNT_MASK;
-   val >>= __ffs(Q_STATE_ENTRY_COUNT_MASK);
+   val = readl(qinst->queue_state) & status_cnt_mask;
+   val >>= __ffs(status_cnt_mask);
 
return val;
 }
@@ -167,8 +173,9 @@ static irqreturn_t ti_msgmgr_queue_rx_interrupt(int irq, 
void *p)
return IRQ_NONE;
}
 
+   desc = inst->desc;
/* Do I actually have messages to read? */
-   msg_count = ti_msgmgr_queue_get_num_messages(qinst);
+   msg_count = ti_msgmgr_queue_get_num_messages(desc, qinst);
if (!msg_count) {
/* Shared IRQ? */
dev_dbg(dev, "Spurious event - 0 pending data!\n");
@@ -181,7 +188,6 @@ static irqreturn_t ti_msgmgr_queue_rx_interrupt(int irq, 
void *p)
 * of how many bytes I should be reading. Let the client figure this
 * out.. I just read the full message and pass it on..
 */
-   desc = inst->desc;
message.len = desc->max_message_size;
message.buf = (u8 *)qinst->rx_buff;
 
@@ -224,12 +230,14 @@ static irqreturn_t ti_msgmgr_queue_rx_interrupt(int irq, 
void *p)
 static bool ti_msgmgr_queue_peek_data(struct mbox_chan *chan)
 {
struct ti_queue_inst *qinst = chan->con_priv;
+   struct device *dev = chan->mbox->dev;
+   struct ti_msgmgr_inst *inst = dev_get_drvdata(dev);
int msg_count;
 
if (qinst->is_tx)
return false;
 
-   msg_count = ti_msgmgr_queue_get_num_messages(qinst);
+   msg_count = ti_msgmgr_queue_get_num_messages(inst->desc, qinst);
 
return msg_count ? true : false;
 }
@@ -243,12 +251,14 @@ static bool ti_msgmgr_queue_peek_data(struct mbox_chan 
*chan)
 static bool ti_msgmgr_last_tx_done(struct mbox_chan *chan)
 {
struct ti_queue_inst *qinst = chan->con_priv;
+   struct device *dev = chan->mbox->dev;
+   struct ti_msgmgr_inst *inst = dev_get_drvdata(dev);
int msg_count;
 
if (!qinst->is_tx)
return false;
 
-   msg_count = ti_msgmgr_queue_get_num_messages(qinst);
+   msg_count = ti_msgmgr_queue_get_num_messages(inst->desc, qinst);
 
/* if we have any messages pending.. */
return msg_count ? false : true;
@@ -523,6 +533,7 @@ static const struct ti_msgmgr_desc k2g_desc = {
.max_messages = 128,
.data_first_reg = 16,
.data_last_reg = 31,
+   .status_cnt_mask = Q_STATE_ENTRY_COUNT_MASK,
.tx_polled = false,
.valid_queues = k2g_valid_queues,
.num_valid_queues = ARRAY_SIZE(k2g_valid_queues),
-- 
2.15.1

[RFC PATCH 0/3] firmware: Add K3 Support for TISCI driver

[Nishanth Menon]

Hi,

The following series enables TI System Control Interface(TISCI) support for
the newest addition in TI's SoC portfolio - AM654 SoC.

The series is an RFC based off next-20180604 and will post formally once
v4.18-rc1 is available.

The series (part 4 of 4) is available here:
https://github.com/nmenon/linux-2.6-playground/commits/upstream/next-20180604/k3-4-am6-tisci

Full Boot log is available here: https://pastebin.ubuntu.com/p/vWCzMKtBCW/

The Linux development follows closely the 66AK2G SoC model in aarch64 with a
few additions to handle the flexibility of firmware.

The architecture and dts support depends on part 1 of the series:
https://marc.info/?l=linux-arm-kernel=152817866312732=2

See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7

Nishanth Menon (3):
  Documentation: dt: keystone: ti-sci: Add optional host-id parameter
  firmware: ti_sci: Provide host-id as an optional dt parameter
  arm64: dts: ti: k3-am6: Add Device Management Security Controller
support

 .../devicetree/bindings/arm/keystone/ti,sci.txt|  4 +++
 arch/arm64/boot/dts/ti/k3-am6.dtsi | 32 ++
 drivers/firmware/ti_sci.c  | 24 +---
 3 files changed, 56 insertions(+), 4 deletions(-)

-- 
2.15.1

[RFC PATCH 1/3] Documentation: dt: keystone: ti-sci: Add optional host-id parameter

[Nishanth Menon]

Texas Instrument's System Control Interface (TISCI) permits the
ability for Operating Systems to running in virtual machines to be
able to independently communicate with the firmware without the need
going through an hypervisor.

The "host-id" in effect is the hardware representation of the
host (example: VMs locked to a core) as identified to the System
Controller.

This is introduced as an optional parameter to maintain consistency
with legacy device tree blobs.

We call this with a vendor prefix to prevent any possible confusion
with SCSI ID (m68k) kernel option.

Signed-off-by: Nishanth Menon 
---
 Documentation/devicetree/bindings/arm/keystone/ti,sci.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt 
b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
index 31f5f9a104cc..b56a02c10ae6 100644
--- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
+++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
@@ -45,11 +45,15 @@ Optional Properties:
debug_messages - Map the Debug message region
 - reg:  register space corresponding to the debug_messages
 - ti,system-reboot-controller: If system reboot can be triggered by SoC reboot
+- ti,host-id: Integer value corresponding to the host ID assigned by Firmware
+   for identification of host processing entities such as virtual
+   machines
 
 Example (K2G):
 -
pmmc: pmmc {
compatible = "ti,k2g-sci";
+   ti,host-id = <2>;
mbox-names = "rx", "tx";
mboxes= < _proxy_pmmc_rx>,
< _proxy_pmmc_tx>;
-- 
2.15.1

[RFC PATCH 2/3] firmware: ti_sci: Provide host-id as an optional dt parameter

[Nishanth Menon]

Texas Instrument's System Control Interface (TISCI) permits the
ability for Operating Systems to running in virtual machines to be
able to independently communicate with the firmware without the need
going through an hypervisor.

The "host-id" in effect is the hardware representation of the
host (example: VMs locked to a core) as identified to the System
Controller.

Provide support as an optional parameter implementation and use the compatible
data as default if one is not provided by device tree.

Signed-off-by: Nishanth Menon 
---
 drivers/firmware/ti_sci.c | 24 
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index b74a533ef35b..6b08ee815b24 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -66,14 +66,14 @@ struct ti_sci_xfers_info {
 
 /**
  * struct ti_sci_desc - Description of SoC integration
- * @host_id:   Host identifier representing the compute entity
+ * @default_host_id:   Host identifier representing the compute entity
  * @max_rx_timeout_ms: Timeout for communication with SoC (in Milliseconds)
  * @max_msgs: Maximum number of messages that can be pending
  *   simultaneously in the system
  * @max_msg_size: Maximum size of data per message that can be handled.
  */
 struct ti_sci_desc {
-   u8 host_id;
+   u8 default_host_id;
int max_rx_timeout_ms;
int max_msgs;
int max_msg_size;
@@ -94,6 +94,7 @@ struct ti_sci_desc {
  * @chan_rx:   Receive mailbox channel
  * @minfo: Message info
  * @node:  list head
+ * @host_id:   Host ID
  * @users: Number of users of this instance
  */
 struct ti_sci_info {
@@ -110,6 +111,7 @@ struct ti_sci_info {
struct mbox_chan *chan_rx;
struct ti_sci_xfers_info minfo;
struct list_head node;
+   u8 host_id;
/* protected by ti_sci_list_mutex */
int users;
 
@@ -370,7 +372,7 @@ static struct ti_sci_xfer *ti_sci_get_one_xfer(struct 
ti_sci_info *info,
 
hdr->seq = xfer_id;
hdr->type = msg_type;
-   hdr->host = info->desc->host_id;
+   hdr->host = info->host_id;
hdr->flags = msg_flags;
 
return xfer;
@@ -1793,7 +1795,7 @@ static int tisci_reboot_handler(struct notifier_block 
*nb, unsigned long mode,
 
 /* Description for K2G */
 static const struct ti_sci_desc ti_sci_pmmc_k2g_desc = {
-   .host_id = 2,
+   .default_host_id = 2,
/* Conservative duration */
.max_rx_timeout_ms = 1000,
/* Limited by MBOX_TX_QUEUE_LEN. K2G can handle upto 128 messages! */
@@ -1819,6 +1821,7 @@ static int ti_sci_probe(struct platform_device *pdev)
int ret = -EINVAL;
int i;
int reboot = 0;
+   u32 h_id;
 
of_id = of_match_device(ti_sci_of_match, dev);
if (!of_id) {
@@ -1833,6 +1836,19 @@ static int ti_sci_probe(struct platform_device *pdev)
 
info->dev = dev;
info->desc = desc;
+   ret = of_property_read_u32(dev->of_node, "ti,host-id", _id);
+   /* if the property is not present in DT, use a default from desc */
+   if (ret < 0) {
+   info->host_id = info->desc->default_host_id;
+   } else {
+   if (!h_id) {
+   dev_warn(dev, "Host ID 0 is reserved for firmware\n");
+   info->host_id = info->desc->default_host_id;
+   } else {
+   info->host_id = h_id;
+   }
+   }
+
reboot = of_property_read_bool(dev->of_node,
   "ti,system-reboot-controller");
INIT_LIST_HEAD(>node);
-- 
2.15.1

[RFC PATCH 3/3] arm64: dts: ti: k3-am6: Add Device Management Security Controller support

[Nishanth Menon]

Add TISCI compatible System controller for AM6 SoCs.

Signed-off-by: Nishanth Menon 
---
 arch/arm64/boot/dts/ti/k3-am6.dtsi | 32 
 1 file changed, 32 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am6.dtsi 
b/arch/arm64/boot/dts/ti/k3-am6.dtsi
index 07e9cc05519c..898422e24b27 100644
--- a/arch/arm64/boot/dts/ti/k3-am6.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am6.dtsi
@@ -97,6 +97,38 @@
interrupts = ;
};
 
+   dmsc: dmsc {
+   compatible = "ti,k2g-sci";
+   ti,host-id = <12>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   /*
+* In case of rare platforms that does not use am6 as
+* system master, use /delete-property/
+*/
+   ti,system-reboot-controller;
+   mbox-names = "rx", "tx";
+
+   mboxes= <_proxy 11>,
+   <_proxy 13>;
+
+   k3_pds: power-controller {
+   compatible = "ti,sci-pm-domain";
+   #power-domain-cells = <1>;
+   };
+
+   k3_clks: clocks {
+   compatible = "ti,k2g-sci-clk";
+   #clock-cells = <2>;
+   };
+
+   k3_reset: reset-controller {
+   compatible = "ti,sci-reset";
+   #reset-cells = <2>;
+   };
+   };
+
wkup_uart0: serial@4230 {
compatible = "ti,am654-uart", "ti,omap4-uart", 
"ns16550a";
reg = <0x0 0x4230 0x0 0x100>;
-- 
2.15.1

Re: [PATCH 2/2] sched/fair: util_est: add running_sum tracking

[Vincent Guittot]

On 4 June 2018 at 18:06, Patrick Bellasi  wrote:
> The estimated utilization of a task is affected by the task being
> preempted, either by another FAIR task of by a task of an higher
> priority class (i.e. RT or DL). Indeed, when a preemption happens, the
> PELT utilization of the preempted task is going to be decayed a bit.
> That's actually correct for utilization, which goal is to measure the
> actual CPU bandwidth consumed by a task.
>
> However, the above behavior does not allow to know exactly what is the
> utilization a task "would have used" if it was running without
> being preempted. Thus, this reduces the effectiveness of util_est for a
> task because it does not always allow to predict how much CPU a task is
> likely to require.
>
> Let's improve the estimated utilization by adding a new "sort-of" PELT
> signal, explicitly only for SE which has the following behavior:
>  a) at each enqueue time of a task, its value is the (already decayed)
> util_avg of the task being enqueued
>  b) it's updated at each update_load_avg
>  c) it can just increase, whenever the task is actually RUNNING on a
> CPU, while it's kept stable while the task is RUNNANBLE but not
> actively consuming CPU bandwidth
>
> Such a defined signal is exactly equivalent to the util_avg for a task
> running alone on a CPU while, in case the task is preempted, it allows
> to know at dequeue time how much would have been the task utilization if
> it was running alone on that CPU.

I don't agree with this statement above
Let say that you have 2 periodic tasks which wants to run 4ms in every
period of 10ms and wakes up at the same time.
One task will execute 1st and the other will wait but at the end they
have the same period and running time and as a result the same
util_avg which is exactly what they need.

>
> This new signal is named "running_avg", since it tracks the actual
> RUNNING time of a task by ignoring any form of preemption.

In fact, you still take into account this preemption as you remove
some time whereas it's only a shift of the excution

>
> From an implementation standpoint, since the sched_avg should fit into a
> single cache line, we save space by tracking only a new runnable sum:
>p->se.avg.running_sum
> while the conversion into a running_avg is done on demand whenever we
> need it, which is at task dequeue time when a new util_est sample has to
> be collected.
>
> The conversion from "running_sum" to "running_avg" is done by performing
> a single division by LOAD_AVG_MAX, which introduces a small error since
> in the division we do not consider the (sa->period_contrib - 1024)
> compensation factor used in ___update_load_avg(). However:
>  a) this error is expected to be limited (~2-3%)
>  b) it can be safely ignored since the estimated utilization is the only
> consumer which is already subject to small estimation errors
>
> The additional corresponding benefit is that, at run-time, we pay the
> cost for a additional sum and multiply, while the more expensive
> division is required only at dequeue time.
>
> Signed-off-by: Patrick Bellasi 
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: Vincent Guittot 
> Cc: Juri Lelli 
> Cc: Todd Kjos 
> Cc: Joel Fernandes 
> Cc: Steve Muckle 
> Cc: Dietmar Eggemann 
> Cc: Morten Rasmussen 
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
> ---
>  include/linux/sched.h |  1 +
>  kernel/sched/fair.c   | 16 ++--
>  2 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 9d8732dab264..2bd5f1c68da9 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -399,6 +399,7 @@ struct sched_avg {
> u64 load_sum;
> u64 runnable_load_sum;
> u32 util_sum;
> +   u32 running_sum;
> u32 period_contrib;
> unsigned long   load_avg;
> unsigned long   runnable_load_avg;
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index f74441be3f44..5d54d6a4c31f 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -3161,6 +3161,8 @@ accumulate_sum(u64 delta, int cpu, struct sched_avg *sa,
> sa->runnable_load_sum =
> decay_load(sa->runnable_load_sum, periods);
> sa->util_sum = decay_load((u64)(sa->util_sum), periods);
> +   if (running)
> +   sa->running_sum = decay_load(sa->running_sum, 
> periods);

so you make some time disappearing from the equation as the signal
will not be decayed and make the period looking shorter than reality.
With the example I mentioned above, the 2nd task will be seen as if
its period becomes 6ms instead of 10ms which is not true and the
utilization of the task is overestimated without any good reason
Furthermore, this 

Re: [patch 7/8] genirq/affinity: Defer affinity setting if irq chip is busy

[Song Liu]

On Mon, Jun 4, 2018 at 8:33 AM, Thomas Gleixner  wrote:
> The case that interrupt affinity setting fails with -EBUSY can be handled
> in the kernel completely by using the already available generic pending
> infrastructure.
>
> If a irq_chip::set_affinity() fails with -EBUSY, handle it like the
> interrupts for which irq_chip::set_affinity() can only be invoked from
> interrupt context. Copy the new affinity mask to irq_desc::pending_mask and
> set the affinity pending bit. The next raised interrupt for the affected
> irq will check the pending bit and try to set the new affinity from the
> handler. This avoids that -EBUSY is returned when an affinity change is
> requested from user space and the previous change has not been cleaned
> up. The new affinity will take effect when the next interrupt is raised
> from the device.
>
> Fixes: dccfe3147b42 ("x86/vector: Simplify vector move cleanup")
> Signed-off-by: Thomas Gleixner 
> Cc: sta...@vger.kernel.org

Tested-by: Song Liu 

> ---
>  kernel/irq/manage.c |   37 +++--
>  1 file changed, 35 insertions(+), 2 deletions(-)
>
> --- a/kernel/irq/manage.c
> +++ b/kernel/irq/manage.c
> @@ -204,6 +204,39 @@ int irq_do_set_affinity(struct irq_data
> return ret;
>  }
>
> +#ifdef CONFIG_GENERIC_PENDING_IRQ
> +static inline int irq_set_affinity_pending(struct irq_data *data,
> +  const struct cpumask *dest)
> +{
> +   struct irq_desc *desc = irq_data_to_desc(data);
> +
> +   irqd_set_move_pending(data);
> +   irq_copy_pending(desc, dest);
> +   return 0;
> +}
> +#else
> +static inline int irq_set_affinity_pending(struct irq_data *data,
> +  const struct cpumask *dest)
> +{
> +   return -EBUSY;
> +}
> +#endif
> +
> +static int irq_try_set_affinity(struct irq_data *data,
> +   const struct cpumask *dest, bool force)
> +{
> +   int ret = irq_do_set_affinity(data, dest, force);
> +
> +   /*
> +* In case that the underlying vector management is busy and the
> +* architecture supports the generic pending mechanism then utilize
> +* this to avoid returning an error to user space.
> +*/
> +   if (ret == -EBUSY && !force)
> +   ret = irq_set_affinity_pending(data, dest);
> +   return ret;
> +}
> +
>  int irq_set_affinity_locked(struct irq_data *data, const struct cpumask 
> *mask,
> bool force)
>  {
> @@ -214,8 +247,8 @@ int irq_set_affinity_locked(struct irq_d
> if (!chip || !chip->irq_set_affinity)
> return -EINVAL;
>
> -   if (irq_can_move_pcntxt(data)) {
> -   ret = irq_do_set_affinity(data, mask, force);
> +   if (irq_can_move_pcntxt(data) && !irqd_is_setaffinity_pending(data)) {
> +   ret = irq_try_set_affinity(data, mask, force);
> } else {
> irqd_set_move_pending(data);
> irq_copy_pending(desc, mask);
>
>

Re: [PATCH 0/4] exit: Make unlikely case in mm_update_next_owner() more scalable

[Michal Hocko]

On Mon 04-06-18 09:31:46, Eric W. Biederman wrote:
[...]
> My key point is that it is easy to trigger which makes the current
> mm_update_next_owner a fundamentally flawed design, and something that
> needs to be fixed.

Ohh, absolutely agreed! I was not trying to argue that part of course.

-- 
Michal Hocko
SUSE Labs

Dear friend

[Mr Umar Bello]

Dear friend
I am contacting you for a business deal of $17.5 Million US Dollars,
ready for transfer into your account
if we make this claim, we will share it 60%/40%.
100% risk free and it will be legally backed up with government
approved If you are interested reply for more details.

Best regards, Umar Bello +226 68874958

[PATCH] usb: xhci: remove the code build warning

[Dongjiu Geng]

Initialize the 'err' variate to remove the build warning,
the warning is shown as below:

drivers/usb/host/xhci-tegra.c: In function ‘tegra_xusb_mbox_thread’:
drivers/usb/host/xhci-tegra.c:552:6: warning: ‘err’ may be used uninitialized 
in this function [-Wuninitialized]
drivers/usb/host/xhci-tegra.c:482:6: note: ‘err’ was declared here

Signed-off-by: Dongjiu Geng 
---
How to reproduce:
1. make defconfig ARCH=arm
2. make -j100 CROSS_COMPILE=arm-linux-gnueabi- ARCH=arm

Then you can see below warnings:
drivers/usb/host/xhci-tegra.c: In function ‘tegra_xusb_mbox_thread’:
drivers/usb/host/xhci-tegra.c:552:6: warning: ‘err’ may be used uninitialized 
in this function [-Wuninitialized]
drivers/usb/host/xhci-tegra.c:482:6: note: ‘err’ was declared here
---
 drivers/usb/host/xhci-tegra.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
index 2c076ea..1ed87ce 100644
--- a/drivers/usb/host/xhci-tegra.c
+++ b/drivers/usb/host/xhci-tegra.c
@@ -479,7 +479,7 @@ static void tegra_xusb_mbox_handle(struct tegra_xusb *tegra,
unsigned long mask;
unsigned int port;
bool idle, enable;
-   int err;
+   int err = 0;
 
memset(, 0, sizeof(rsp));
 
-- 
2.7.4

[PATCH] module: exclude SHN_UNDEF symbols from kallsyms api

[Jessica Yu]

Livepatch modules are special in that we preserve their entire symbol
tables in order to be able to apply relocations after module load. The
unwanted side effect of this is that undefined (SHN_UNDEF) symbols of
livepatch modules are accessible via the kallsyms api and this can
confuse symbol resolution in livepatch (klp_find_object_symbol()) and
cause subtle bugs in livepatch.

Have the module kallsyms api skip over SHN_UNDEF symbols. These symbols
are usually not available for normal modules anyway as we cut down their
symbol tables to just the core (non-undefined) symbols, so this should
really just affect livepatch modules. Note that this patch doesn't
affect the display of undefined symbols in /proc/kallsyms.

Reported-by: Josh Poimboeuf 
Tested-by: Josh Poimboeuf 
Signed-off-by: Jessica Yu 
---
 kernel/module.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/kernel/module.c b/kernel/module.c
index c9bea7f2b43e..dfa61490b37d 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -4070,7 +4070,7 @@ static unsigned long mod_find_symname(struct module *mod, 
const char *name)
 
for (i = 0; i < kallsyms->num_symtab; i++)
if (strcmp(name, symname(kallsyms, i)) == 0 &&
-   kallsyms->symtab[i].st_info != 'U')
+   kallsyms->symtab[i].st_shndx != SHN_UNDEF)
return kallsyms->symtab[i].st_value;
return 0;
 }
@@ -4116,6 +4116,10 @@ int module_kallsyms_on_each_symbol(int (*fn)(void *, 
const char *,
if (mod->state == MODULE_STATE_UNFORMED)
continue;
for (i = 0; i < kallsyms->num_symtab; i++) {
+
+   if (kallsyms->symtab[i].st_shndx == SHN_UNDEF)
+   continue;
+
ret = fn(data, symname(kallsyms, i),
 mod, kallsyms->symtab[i].st_value);
if (ret != 0)
-- 
2.16.3

Re: [PATCH 09/19] sched/numa: Modify migrate_swap to accept additional params

[Mel Gorman]

On Mon, Jun 04, 2018 at 03:30:18PM +0530, Srikar Dronamraju wrote:
> There are checks in migrate_swap_stop that check if the task/cpu
> combination is as per migrate_swap_arg before migrating.
> 
> However atleast one of the two tasks to be swapped by migrate_swap could
> have migrated to a completely different cpu before updating the
> migrate_swap_arg. The new cpu where the task is currently running could
> be a different node too. If the task has migrated, numa balancer might
> end up placing a task in a wrong node.  Instead of achieving node
> consolidation, it may end up spreading the load across nodes.
> 
> To avoid that pass the cpus as additional parameters.
> 
> While here, place migrate_swap under CONFIG_NUMA_BALANCING.
> 
> Signed-off-by: Srikar Dronamraju 

Acked-by: Mel Gorman 

-- 
Mel Gorman
SUSE Labs

[GIT PULL] MMC for v.4.18

[Ulf Hansson]

Hi Linus,

Here's the PR with MMC updates for v4.18. Details about the highlights are as
usual found in the signed tag.

Please pull this in!

Kind regards
Ulf Hansson


The following changes since commit 3de06d5a1f05c11c94cbb68af14dbfa7fb81d78b:

  mmc: sdhci-iproc: add SDHCI_QUIRK2_HOST_OFF_CARD_ON for cygnus (2018-05-21 
13:27:22 +0200)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git tags/mmc-v4.18

for you to fetch changes up to ef5332c10d4f332a2ac79e9ad5452f4e89d1815a:

  mmc: renesas_sdhi: really fix WP logic regressions (2018-06-04 11:16:58 +0200)


MMC core:
 - Decrease polling rate for erase/trim/discard
 - Allow non-sleeping GPIOs for card detect
 - Improve mmc block removal path
 - Enable support for mmc_sw_reset() for SDIO cards
 - Add mmc_sw_reset() to allow users to do a soft reset of the card
 - Allow power delay to be tunable via DT
 - Allow card detect debounce delay to be tunable via DT
 - Enable new quirk to limit clock rate for Marvell 8887 chip
 - Don't show eMMC RPMB and BOOT areas in /proc/partitions
 - Add capability to avoid 3.3V signaling for fragile HWs

MMC host:
 - Improve/fixup support for handle highmem pages
 - Remove depends on HAS_DMA in case of platform dependency
 - mvsdio: Enable support for erase/trim/discard
 - rtsx_usb: Enable support for erase/trim/discard
 - renesas_sdhi: Fix WP logic regressions
 - renesas_sdhi: Add r8a77965 support
 - renesas_sdhi: Add R8A77980 to whitelist
 - meson: Add optional support for device reset
 - meson: Add support for the Meson-AXG platform
 - dw_mmc: Add new driver for BlueField DW variant
 - mediatek: Add support for 64G DRAM DMA
 - sunxi: Deploy runtime PM support
 - jz4740: Add support for JZ4780
 - jz4740: Enable support for DT based platforms
 - sdhci: Various improvement to timeout handling
 - sdhci: Disable support for HS200/HS400/UHS when no 1.8V support
 - sdhci-omap: Add support for controller in k2g SoC
 - sdhci-omap: Add workarounds for a couple of Erratas
 - sdhci-omap: Enable support for generic sdhci DT properties
 - sdhci-cadence: Re-send tune request to deal with errata
 - sdhci-pci: Fix 3.3V voltage switch for some BYT-based Intel controllers
 - sdhci-pci: Avoid 3.3V signaling on some NI 904x
 - sdhci-esdhc-imx: Use watermark levels for PIO access
 - sdhci-msm: Improve card detection handling
 - sdhci-msm: Add support voltage pad switching


Aapo Vienamo (1):
  mmc: tegra: remove redundant return statement

Adrian Hunter (3):
  mmc: sdhci-pci: Fix 3.3V voltage switch for some BYT-based Intel 
controllers
  mmc: sdhci: Add quirk to disable HW timeout
  mmc: sdhci: Factor out target_timeout calculation

Alex Smith (2):
  mmc: jz4740: Set clock rate to mmc->f_max rather than JZ_MMC_CLK_RATE
  mmc: jz4740: Add support for the JZ4780

Andrew Gabbasov (2):
  mmc: card: Don't show eMMC RPMB and BOOT areas in /proc/partitions
  mmc: sdhci-esdhc-imx: Set maximum watermark levels for PIO access

Arnd Bergmann (2):
  mmc: sunxi: mark PM functions as __maybe_unused
  mmc: mxmmc: include linux/highmem.h

Chaotian Jing (1):
  mmc: mediatek: add 64G DRAM DMA support

Christoph Hellwig (6):
  mmc: android-goldfish: use sg_copy_{from,to}_buffer
  mmc: atmel-mci: use sg_copy_{from,to}_buffer
  mmc: mxcmmc: handle highmem pages
  mmc: ushc: handle highmem pages
  mmc: wbsd: handle highmem pages
  mmc: au1xmmc: handle highmem pages

Diwakar Sharma (1):
  mmc: core: sdio: Set SDIO clock of SDR104 to 150MHz for Marvell 8887 chip

Evan Green (1):
  mmc: Allow non-sleeping GPIO cd

Ezequiel Garcia (10):
  mmc: jz4780: Order headers alphabetically
  mmc: jz4740: Use dev_get_platdata
  mmc: jz4740: Introduce devicetree probe
  mmc: dt-bindings: add MMC support to JZ4740 SoC
  mmc: jz4740: Use dma_request_chan()
  MIPS: dts: jz4780: Add DMA controller node to the devicetree
  MIPS: dts: jz4780: Add MMC controller node to the devicetree
  MIPS: dts: ci20: Enable MMC in the devicetree
  MIPS: configs: ci20: Enable DMA and MMC support
  MIPS: configs: ci20: Enable ext4

Geert Uytterhoeven (1):
  mmc: Remove depends on HAS_DMA in case of platform dependency

Georgi Djakov (1):
  mmc: sdhci-msm: Remove NO_CARD_NO_RESET quirk

Gustavo A. R. Silva (1):
  mmc: sdhci-cadence: fix logically and structurally dead code

Jerome Brunet (2):
  dt-bindings: mmc: meson-gx: add reset
  mmc: meson-gx: add device reset

Jisheng Zhang (1):
  mmc: sdhci-*: Don't emit error msg if sdhci_add_host() fails

Kishon Vijay Abraham I (12):
  mmc: sdhci-omap: Fix when capabilities are obtained from 
SDHCI_CAPABILITIES reg
  mmc: sdhci-omap: Remove setting ADMA capability in driver
  mmc: sdhci-omap: Workaround for Errata i843
  mmc: 

Re: [lkp-robot] [vti6] b4331a6818: kernel_selftests.net.pmtu.sh.fail

[Stefano Brivio]

On Tue, 5 Jun 2018 15:09:27 +0800
kernel test robot  wrote:

> FYI, we noticed the following commit (built with gcc-7):
> 
> commit: b4331a681822b420511b3258f1c3db35001fde48 ("vti6: Change minimum MTU 
> to IPV4_MIN_MTU, vti6 can carry IPv4 too")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>
> [...]
>
> caused below changes (please refer to attached dmesg/kmsg for entire 
> log/backtrace):
> 
> 
> selftests: pmtu.sh
> 
> TEST: vti6: PMTU exceptions [ OK ]
> TEST: vti4: PMTU exceptions [ OK ]
> TEST: vti4: default MTU assignment  [ OK ]
> TEST: vti6: default MTU assignment  [ OK ]
> TEST: vti4: MTU setting on link creation[ OK ]
> TEST: vti6: MTU setting on link creation[FAIL]
>   vti6 tunnel created with invalid MTU 1279

This is solved by net-next.git commit 5a643c861d0f ("selftests: pmtu:
Minimum MTU for vti6 is 68"), which should get merged into net.git soon.

-- 
Stefano

Re: [PATCH 4.14 00/52] 4.14.48-stable review

[Naresh Kamboju]

On 4 June 2018 at 12:27, Greg Kroah-Hartman  wrote:
> This is the start of the stable review cycle for the 4.14.48 release.
> There are 52 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Jun  6 06:55:52 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.48-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

NOTE: Short summary report generator will resume soon.
This time we are using old and long report.

Summary


kernel: 4.14.48-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: 721adf61fde28b9a87a95e45ecf3f5a325e7c76f
git describe: v4.14.47-53-g721adf61fde2
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.47-53-g721adf61fde2


No regressions (compared to build v4.14.47)


Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 21,
* kselftest - skip: 23, pass: 43, fail: 1
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-cve-tests - skip: 8, pass: 25, fail: 2
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 6, pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - skip: 1, pass: 21,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 4, pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 133, pass: 1013, fail: 3
* ltp-timers-tests - pass: 13,

juno-r2 - arm64
* boot - pass: 9,
* kselftest - skip: 25, pass: 42, fail: 1
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-cve-tests - skip: 8, pass: 24, fail: 3
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,

qemu_arm
* boot - pass: 21,
* kselftest - skip: 29, pass: 36, fail: 3
* libhugetlbfs - skip: 1, pass: 87,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 18, pass: 63,
* ltp-cve-tests - skip: 8, pass: 22, fail: 5
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 5, pass: 61,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - skip: 1, pass: 21,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 7, pass: 7,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 93, pass: 1053, fail: 3
* ltp-timers-tests - pass: 13,

qemu_arm64
* boot - pass: 21,
* kselftest - skip: 29, pass: 40, fail: 1
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-cve-tests - skip: 8, pass: 23, fail: 4
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 6, pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 6, pass: 8,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 154, pass: 991, fail: 4
* ltp-timers-tests - pass: 13,

qemu_x86_64
* boot - pass: 21,
* kselftest - skip: 29, pass: 52, fail: 1
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-cve-tests - skip: 3, pass: 29, fail: 3
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 6, pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 1, pass: 13,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 153, pass: 994, fail: 2
* ltp-timers-tests - pass: 13,

x15 - arm
* boot - pass: 19,
* kselftest - skip: 26, pass: 38, fail: 

[RFC PATCH] clk: keystone: Enable TISCI clocks if K3_ARCH

[Nishanth Menon]

K3_ARCH uses TISCI for clocks as well. Enable the same
for the driver support.

Signed-off-by: Nishanth Menon 
---

Hi,

This patch depends on 
https://marc.info/?l=linux-arm-kernel=152817866312732=2
and is an RFC based off next-20180604 and will post formally once
v4.18-rc1 is available.

The consolidated series is also available at:
https://github.com/nmenon/linux-2.6-playground/commits/upstream/next-20180604/k3-3-am6-clk

 drivers/clk/Makefile | 1 +
 drivers/clk/keystone/Kconfig | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 0bb25dd009d1..c14187526b46 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -72,6 +72,7 @@ obj-$(CONFIG_ARCH_HISI)   += hisilicon/
 obj-y  += imgtec/
 obj-$(CONFIG_ARCH_MXC) += imx/
 obj-$(CONFIG_MACH_INGENIC) += ingenic/
+obj-$(CONFIG_ARCH_K3)  += keystone/
 obj-$(CONFIG_ARCH_KEYSTONE)+= keystone/
 obj-$(CONFIG_MACH_LOONGSON32)  += loongson1/
 obj-y  += mediatek/
diff --git a/drivers/clk/keystone/Kconfig b/drivers/clk/keystone/Kconfig
index 7e9f0176578a..b04927d06cd1 100644
--- a/drivers/clk/keystone/Kconfig
+++ b/drivers/clk/keystone/Kconfig
@@ -7,7 +7,7 @@ config COMMON_CLK_KEYSTONE
 
 config TI_SCI_CLK
tristate "TI System Control Interface clock drivers"
-   depends on (ARCH_KEYSTONE || COMPILE_TEST) && OF
+   depends on (ARCH_KEYSTONE || ARCH_K3 || COMPILE_TEST) && OF
depends on TI_SCI_PROTOCOL
default ARCH_KEYSTONE
---help---
-- 
2.15.1

Re: [PATCH v5 1/4] mfd: bd71837: mfd driver for ROHM BD71837 PMIC

[Matti Vaittinen]

On Mon, Jun 04, 2018 at 04:18:07PM +0300, Matti Vaittinen wrote:
> +static struct regmap_irq_chip bd71837_irq_chip = {
> + .name = "bd71837-irq",
> + .irqs = bd71837_irqs,
> + .num_irqs = ARRAY_SIZE(bd71837_irqs),
> + .num_regs = 1,
> + .irq_reg_stride = 1,
> + .status_base = BD71837_REG_IRQ,
> + .mask_base = BD71837_REG_MIRQ,
> + .init_ack_masked = true,
> + .mask_invert = false,
> +};

.ack_base = BD71837_REG_IRQ, is missing. I'll send yet another version
with this fixed - unless Rob tells me to drop the whole irq handling
from the patch series.

Br,
Matti Vaittinen

Re: [PATCH v2 3/9] x86: refcount: prevent gcc distortions

[kbuild test robot]

Hi Nadav,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.17 next-20180604]
[cannot apply to tip/x86/core]
[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/Nadav-Amit/x86-macrofying-inline-asm-for-better-compilation/20180605-124313
config: x86_64-fedora-25 (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/include/asm/refcount.h: Assembler messages:
   arch/x86/include/asm/refcount.h:38: Error: too many positional arguments
>> /tmp/cc0rd6kn.s: Error: local label `"111" (instance number 3 of a fb 
>> label)' is not defined

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH v5 3/4] ARM: mm: fix build error in fix_to_virt with CONFIG_CC_OPTIMIZE_FOR_DEBUGGING

[changbin . du]

From: Changbin Du 

With '-Og' optimization level, GCC would not optimize a count for a loop
as a constant value. But BUILD_BUG_ON() only accept compile-time constant
values. Let's use __fix_to_virt() to avoid the error.

arch/arm/mm/mmu.o: In function `fix_to_virt':
/home/changbin/work/linux/./include/asm-generic/fixmap.h:31: undefined 
reference to `__compiletime_assert_31'
Makefile:1051: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1

Signed-off-by: Changbin Du 
Acked-by: Steven Rostedt (VMware) 
---
v2: use __fix_to_virt() to fix the issue.
---
 arch/arm/mm/mmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index e46a6a4..c08d74e 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1599,7 +1599,7 @@ static void __init early_fixmap_shutdown(void)
pte_t *pte;
struct map_desc map;
 
-   map.virtual = fix_to_virt(i);
+   map.virtual = __fix_to_virt(i);
pte = pte_offset_early_fixmap(pmd_off_k(map.virtual), 
map.virtual);
 
/* Only i/o device mappings are supported ATM */
-- 
2.7.4

[PATCH v5 2/4] kernel hacking: new config NO_AUTO_INLINE to disable compiler auto-inline optimizations

[changbin . du]

From: Changbin Du 

This patch add a new kernel hacking option NO_AUTO_INLINE. Selecting
this option will prevent the compiler from optimizing the kernel by
auto-inlining functions not marked with the inline keyword.

With this option, only functions explicitly marked with "inline" will
be inlined. This will allow the function tracer to trace more functions
because it only traces functions that the compiler has not inlined.

Signed-off-by: Changbin Du 
Acked-by: Steven Rostedt (VMware) 

---
v2: Some grammar updates from Steven.
---
 Makefile  |  6 ++
 lib/Kconfig.debug | 17 +
 2 files changed, 23 insertions(+)

diff --git a/Makefile b/Makefile
index d0d2652..6720c40 100644
--- a/Makefile
+++ b/Makefile
@@ -775,6 +775,12 @@ KBUILD_CFLAGS  += $(call cc-option, 
-femit-struct-debug-baseonly) \
   $(call cc-option,-fno-var-tracking)
 endif
 
+ifdef CONFIG_NO_AUTO_INLINE
+KBUILD_CFLAGS   += $(call cc-option, -fno-inline-functions) \
+  $(call cc-option, -fno-inline-small-functions) \
+  $(call cc-option, -fno-inline-functions-called-once)
+endif
+
 ifdef CONFIG_FUNCTION_TRACER
 ifndef CC_FLAGS_FTRACE
 CC_FLAGS_FTRACE := -pg
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index c40c7b7..da52243 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -198,6 +198,23 @@ config GDB_SCRIPTS
  instance. See Documentation/dev-tools/gdb-kernel-debugging.rst
  for further details.
 
+config NO_AUTO_INLINE
+   bool "Disable compiler auto-inline optimizations"
+   help
+ This will prevent the compiler from optimizing the kernel by
+ auto-inlining functions not marked with the inline keyword.
+ With this option, only functions explicitly marked with
+ "inline" will be inlined. This will allow the function tracer
+ to trace more functions because it only traces functions that
+ the compiler has not inlined.
+
+ Enabling this function can help debugging a kernel if using
+ the function tracer. But it can also change how the kernel
+ works, because inlining functions may change the timing,
+ which could make it difficult while debugging race conditions.
+
+ If unsure, select N.
+
 config ENABLE_WARN_DEPRECATED
bool "Enable __deprecated logic"
default y
-- 
2.7.4

[PATCH v5 1/4] x86/mm: surround level4_kernel_pgt with #ifdef CONFIG_X86_5LEVEL...#endif

[changbin . du]

From: Changbin Du 

The level4_kernel_pgt is only defined when X86_5LEVEL is enabled. So
surround level4_kernel_pgt with #ifdef CONFIG_X86_5LEVEL...#endif to
make code correct.

Signed-off-by: Changbin Du 
Acked-by: Steven Rostedt (VMware) 
---
 arch/x86/include/asm/pgtable_64.h |  2 ++
 arch/x86/kernel/head64.c  | 13 ++---
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/pgtable_64.h 
b/arch/x86/include/asm/pgtable_64.h
index 877bc27..9e7f667 100644
--- a/arch/x86/include/asm/pgtable_64.h
+++ b/arch/x86/include/asm/pgtable_64.h
@@ -15,7 +15,9 @@
 #include 
 #include 
 
+#ifdef CONFIG_X86_5LEVEL
 extern p4d_t level4_kernel_pgt[512];
+#endif
 extern p4d_t level4_ident_pgt[512];
 extern pud_t level3_kernel_pgt[512];
 extern pud_t level3_ident_pgt[512];
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 0c408f8..775d7a6 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -143,16 +143,15 @@ unsigned long __head __startup_64(unsigned long physaddr,
 
pgd = fixup_pointer(_top_pgt, physaddr);
p = pgd + pgd_index(__START_KERNEL_map);
-   if (la57)
-   *p = (unsigned long)level4_kernel_pgt;
-   else
-   *p = (unsigned long)level3_kernel_pgt;
-   *p += _PAGE_TABLE_NOENC - __START_KERNEL_map + load_delta;
-
+#ifdef CONFIG_X86_5LEVEL
if (la57) {
+   *p = (unsigned long)level4_kernel_pgt;
p4d = fixup_pointer(_kernel_pgt, physaddr);
p4d[511] += load_delta;
-   }
+   } else
+#endif
+   *p = (unsigned long)level3_kernel_pgt;
+   *p += _PAGE_TABLE_NOENC - __START_KERNEL_map + load_delta;
 
pud = fixup_pointer(_kernel_pgt, physaddr);
pud[510] += load_delta;
-- 
2.7.4

Re: [PATCH 03/19] sched/numa: Simplify load_too_imbalanced

[Mel Gorman]

On Mon, Jun 04, 2018 at 03:30:12PM +0530, Srikar Dronamraju wrote:
> Currently load_too_imbalance() cares about the slope of imbalance.
> It doesn't care of the direction of the imbalance.
> 
> However this may not work if nodes that are being compared have
> dissimilar capacities. Few nodes might have more cores than other nodes
> in the system. Also unlike traditional load balance at a NUMA sched
> domain, multiple requests to migrate from the same source node to same
> destination node may run in parallel. This can cause huge load
> imbalance. This is specially true on a larger machines with either large
> cores per node or more number of nodes in the system. Hence allow
> move/swap only if the imbalance is going to reduce.
> 
> Testcase   Time: Min Max Avg  StdDev
> numa01.sh  Real:  516.14  892.41  739.84  151.32
> numa01.sh   Sys:  153.16  192.99  177.70   14.58
> numa01.sh  User:39821.0469528.9257193.8710989.48
> numa02.sh  Real:   60.91   62.35   61.580.63
> numa02.sh   Sys:   16.47   26.16   21.203.85
> numa02.sh  User: 5227.58 5309.61 5265.17   31.04
> numa03.sh  Real:  739.07  917.73  795.75   64.45
> numa03.sh   Sys:   94.46  136.08  109.48   14.58
> numa03.sh  User:57478.5672014.0961764.48 5343.69
> numa04.sh  Real:  442.61  715.43  530.31   96.12
> numa04.sh   Sys:  224.90  348.63  285.61   48.83
> numa04.sh  User:35836.8447522.4740235.41 3985.26
> numa05.sh  Real:  386.13  489.17  434.94   43.59
> numa05.sh   Sys:  144.29  438.56  278.80  105.78
> numa05.sh  User:33255.8636890.8234879.31 1641.98
> 
> Testcase   Time: Min Max Avg  StdDev   %Change
> numa01.sh  Real:  435.78  653.81  534.58   83.20   38.39%
> numa01.sh   Sys:  121.93  187.18  145.90   23.47   21.79%
> numa01.sh  User:37082.8151402.8043647.60 5409.75   31.03%
> numa02.sh  Real:   60.64   61.63   61.190.40   0.637%
> numa02.sh   Sys:   14.72   25.68   19.064.03   11.22%
> numa02.sh  User: 5210.95 5266.69 5233.30   20.82   0.608%
> numa03.sh  Real:  746.51  808.24  780.36   23.88   1.972%
> numa03.sh   Sys:   97.26  108.48  105.074.28   4.197%
> numa03.sh  User:58956.3061397.0560162.95 1050.82   2.661%
> numa04.sh  Real:  465.97  519.27  484.81   19.62   9.385%
> numa04.sh   Sys:  304.43  359.08  334.68   20.64   -14.6%
> numa04.sh  User:37544.1641186.1539262.44 1314.91   2.478%
> numa05.sh  Real:  411.57  457.20  433.29   16.58   0.380%
> numa05.sh   Sys:  230.05  435.48  339.95   67.58   -17.9%
> numa05.sh  User:33325.5436896.3135637.84 1222.64   -2.12%
> 
> Signed-off-by: Srikar Dronamraju 

Acked-by: Mel Gorman 

-- 
Mel Gorman
SUSE Labs

Attenzione

[Amministratore]

utente webmail

Tieni presente che il 95% delle tue e-mail ricevute dopo l'ultima volta che hai 
bisogno di aggiornare il tuo server di versione webmail nel nostro database 
sono state ritardate. Per ricevere e inviare i tuoi messaggi su base regolare. 
Il nostro team tecnico di webmail aggiornerà il tuo account entro 3 giorni 
lavorativi. Se non lo fai, il tuo account verrà sospeso temporaneamente dai 
nostri servizi. Per verificare nuovamente la tua casella di posta elettronica, 
invia le seguenti informazioni:

ordinario:
Nome utente:
parola d'ordine:
Conferma password:

Avvertimento!! Se questo si rifiuta di aggiornare gli account entro due
giorni dalla ricezione dell'e-mail, perderà definitivamente gli account dei
proprietari degli account webmail.

Grazie per la collaborazione!

Copyright © 2017-2018 WebMail, Inc. team di supporto tecnico

[GIT PULL] s390 patches for the 4.18 merge window

[Martin Schwidefsky]

Hi Linus,

please pull from the 'for-linus' branch of

git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus

to receive the following updates:

 - A rework for the s390 arch random code, the TRNG instruction is rather
   slow and should not be used on the interrupt path

 - A fix for a memory leak in the zcrypt driver

 - Changes to the early boot code to add a compile time check for code that
   may not use the .bss section, with the goal to avoid initrd corruptions

 - Add an interface to get the physical network ID (pnetid), this is
   useful to group network devices that are attached to the same network

 - Some cleanup for the linker script

 - Some code improvement for the dasd driver

 - Two fixes for the perf sampling support


Harald Freudenberger (2):
  s390/archrandom: Rework arch random implementation.
  s390/zcrypt: Fix CCA and EP11 CPRB processing failure memory leak.

Heiko Carstens (3):
  s390/early: get rid of memmove_early
  s390/early: get rid of #ifdef CONFIG_BLK_DEV_INITRD
  s390/early: move functions which may not access bss section to extra file

Martin Schwidefsky (1):
  s390: remove closung punctuation from spectre messages

Masahiro Yamada (1):
  s390: remove no-op macro VMLINUX_SYMBOL()

Sebastian Ott (3):
  s390/cio: add helper to query utility strings per given ccw device
  s390/cio: add test for ccwgroup device
  s390/dasd: simplify locking in dasd_times_out

Thomas Richter (2):
  perf: fix invalid bit in diagnostic entry
  s390/cpum_sf: Add data entry sizes to sampling trailer entry

Ursula Braun (1):
  s390/net: add pnetid support

Vasily Gorbik (1):
  s390: introduce compile time check for empty .bss section

 arch/s390/Kconfig |   4 ++
 arch/s390/crypto/arch_random.c| 103 --
 arch/s390/include/asm/archrandom.h|  13 +
 arch/s390/include/asm/ccwdev.h|   1 +
 arch/s390/include/asm/ccwgroup.h  |  10 
 arch/s390/include/asm/cpu_mf.h|   6 +-
 arch/s390/include/asm/pnet.h  |  23 
 arch/s390/kernel/Makefile |  27 +
 arch/s390/kernel/early.c  |  80 --
 arch/s390/kernel/early_nobss.c|  65 +
 arch/s390/kernel/entry.h  |   1 +
 arch/s390/kernel/head64.S |   8 ++-
 arch/s390/kernel/nospec-branch.c  |   4 +-
 arch/s390/kernel/vmlinux.lds.S|   4 +-
 arch/s390/lib/Makefile|   3 +
 arch/s390/net/Makefile|   1 +
 arch/s390/net/pnet.c  |  80 ++
 arch/s390/scripts/Makefile.chkbss |  14 +
 drivers/s390/block/dasd.c |  31 +-
 drivers/s390/char/Makefile|   3 +
 drivers/s390/cio/ccwgroup.c   |   6 ++
 drivers/s390/cio/device_ops.c |  31 ++
 drivers/s390/crypto/ap_bus.h  |  17 --
 drivers/s390/crypto/zcrypt_api.c  |  15 -
 drivers/s390/crypto/zcrypt_msgtype6.c |  51 +++--
 25 files changed, 435 insertions(+), 166 deletions(-)
 create mode 100644 arch/s390/include/asm/pnet.h
 create mode 100644 arch/s390/kernel/early_nobss.c
 create mode 100644 arch/s390/net/pnet.c
 create mode 100644 arch/s390/scripts/Makefile.chkbss

Re: [PATCH 1/2] platform/x86: asus-wmi: Call new led hw_changed API on kbd brightness change

[Hans de Goede]

Hi,

On 05-06-18 05:18, Chris Chiu wrote:

On Tue, Jun 5, 2018 at 10:31 AM, Darren Hart  wrote:

On Mon, Jun 04, 2018 at 04:23:04PM +0200, Hans de Goede wrote:

Hi,

On 04-06-18 15:51, Daniel Drake wrote:

On Mon, Jun 4, 2018 at 7:22 AM, Hans de Goede  wrote:

Is this really a case of the hardware itself processing the
keypress and then changing the brightness *itself* ?

  From the "[PATCH 2/2] platform/x86: asus-wmi: Add keyboard backlight
toggle support" patch I get the impression that the driver is
modifying the brightness from within the kernel rather then the
keyboard controller are ACPI embeddec-controller doing it itself.

If that is the case then the right fix is for the driver to stop
mucking with the brighness itself, it should simply report the
right keyboard events and export a led interface and then userspace
will do the right thing (and be able to offer flexible policies
to the user).


Before this modification, the driver reports the brightness keypresses
to userspace and then userspace can respond by changing the brightness
level, as you describe.

You are right in that the hardware doesn't change the brightness
directly itself, which is the normal usage of LED_BRIGHT_HW_CHANGED.

However this approach was suggested by Benjamin Berg and Bastien
Nocera in the thread: Re: [PATCH v2] platform/x86: asus-wmi: Add
keyboard backlight toggle support
https://marc.info/?l=linux-kernel=152639169210655=2

The issue is that we need to support a new "keyboard backlight
brightness cycle" key (in the patch that follows this one) which
doesn't fit into any definitions of keys recognised by the kernel and
likewise there's no userspace code to handle it.

If preferred we could leave the standard brightness keys behaving as
they are (input events) and make the new special key type directly
handled by the kernel?


I'm sorry that Benjamin and Bastien steered you in this direction,
IMHO none of it should be handled in the kernel.

Anytime any sort of input is directly responded to by the kernel
it is a huge PITA to deal with from userspace. The kernel will have
a simplistic implementation which almost always is wrong.

Benjamin, remember the pain we went through with rfkill hotkey
presses being handled in the kernel ?

And then there is the whole acpi_video.brightness_switch_enabled
debacle, which is an option which defaults to true which causes
the kernel to handle LCD brightness key presses, which all distros
have been patching to default to off for ages.

To give a concrete example, we may want to implement software
dimming / auto-off of the kbd backlight when the no keys are
touched for x seconds. This would seriously get in the way of that.

So sorry, but NACK to this series.


So if instead of modifying the LED value, the kernel platform drivers
converted the TOGGLE into a cycle even by converting to an UP event
based on awareness of the plaform specific max value and the read
current value, leaving userspace to act on the TOGGLE/UP events - would
that be preferable?

Something like:

 if (code == TOGGLE && ledval < ledmax)
 code = UP;

 sparse_keymap_report_event(..., code, ...)

}
--
Darren Hart
VMware Open Source Technology Center


That's what I was trying to do in  [PATCH v2] platform/x86: asus-wmi: Add
keyboard backlight toggle support. However, that brought another problem
discussed in the thread.
https://marc.info/?l=linux-kernel=152639169210655=2

So I moved the brightness change in the driver without passing to userspace.
Per Hans, seems there're some other concerns and I also wonder if the
TOGGLE event happens in ASUS HID (asus-hid.c) which also convert and
pass the keycode to userspace but no TOGGLE key support yet What should
we do then?


As I mentioned in my reply to Darren, there are 2 proper solutions to this:

1) Make userspace treat KEY_KBDILLUMTOGGLE as a cycle key, this is
what the kbd-backlight on most laptops with a single hotkey (*) does
in cases where this is handled in firmware, rather then left to the
OS. The handled in firmware is the case which I created the
led_classdev_notify_brightness_hw_changed() API for. This would be
my preferred solution and I believe that Benjamin is discussing this
with Bastien ATM.

2) Add a new KEY_KBDILLUMCYCLE event and send that for the TOGGLE code
on these laptops.

Yes both will take time to get into end-users hand, but so will a
kernel-only solution. In the mean time endless can always carry
downstream patches to make things work right now (while waiting for
the changes to trickle down from upstream).

Regards,

Hans

Re: [PULL 0/6] vfio-ccw updates for 4.18

[Cornelia Huck]

On Tue, 29 May 2018 14:35:06 +0200
Cornelia Huck  wrote:

Ping.

> The following changes since commit 3376d98021e915196f4894d835325a884e635a04:
> 
>   s390/archrandom: Rework arch random implementation. (2018-05-25 08:12:58 
> +0200)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/vfio-ccw.git 
> tags/vfio-ccw-20180529
> 
> for you to fetch changes up to 3cd90214b70f7f971496bffc3c34d23b2141feb3:
> 
>   vfio: ccw: add tracepoints for interesting error paths (2018-05-29 09:27:42 
> +0200)
> 
> 
> Various fixes and improvements in vfio-ccw, including a first stab
> at adding tracepoints.
> 
> 
> 
> Dong Jia Shi (4):
>   vfio: ccw: fix error return in vfio_ccw_sch_event
>   vfio: ccw: shorten kernel doc description for pfn_array_pin()
>   vfio: ccw: refactor and improve pfn_array_alloc_pin()
>   vfio: ccw: set ccw->cda to NULL defensively
> 
> Halil Pasic (2):
>   vfio: ccw: push down unsupported IDA check
>   vfio: ccw: add tracepoints for interesting error paths
> 
>  drivers/s390/cio/Makefile |   1 +
>  drivers/s390/cio/vfio_ccw_cp.c| 140 
> --
>  drivers/s390/cio/vfio_ccw_drv.c   |   5 +-
>  drivers/s390/cio/vfio_ccw_fsm.c   |  17 -
>  drivers/s390/cio/vfio_ccw_trace.h |  54 +++
>  5 files changed, 150 insertions(+), 67 deletions(-)
>  create mode 100644 drivers/s390/cio/vfio_ccw_trace.h
> 

Re: [PATCH 4.16 00/47] 4.16.14-stable review

[Greg Kroah-Hartman]

On Mon, Jun 04, 2018 at 06:20:44AM -0700, Guenter Roeck wrote:
> On 06/03/2018 11:58 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.16.14 release.
> > There are 47 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Jun  6 06:55:34 UTC 2018.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 136 pass: 136 fail: 0
> Qemu test results:
>   total: 141 pass: 141 fail: 0
> 
> Details are available at http://kerneltests.org/builders/.

Thanks for testing all of these and letting me know.

greg k-h

Re: [PATCH 13/19] mm/migrate: Use xchg instead of spinlock

[Peter Zijlstra]

On Tue, Jun 05, 2018 at 12:24:39AM -0700, Srikar Dronamraju wrote:
> * Peter Zijlstra  [2018-06-04 21:28:21]:
> 
> > >   if (time_after(jiffies, pgdat->numabalancing_migrate_next_window)) {
> > > - spin_lock(>numabalancing_migrate_lock);
> > > - pgdat->numabalancing_migrate_nr_pages = 0;
> > > - pgdat->numabalancing_migrate_next_window = jiffies +
> > > - msecs_to_jiffies(migrate_interval_millisecs);
> > > - spin_unlock(>numabalancing_migrate_lock);
> > > + if (xchg(>numabalancing_migrate_nr_pages, 0))
> > > + pgdat->numabalancing_migrate_next_window = jiffies +
> > > + msecs_to_jiffies(migrate_interval_millisecs);
> >
> > Note that both are in fact wrong. That wants to be something like:
> >
> > pgdat->numabalancing_migrate_next_window += interval;
> >
> > Otherwise you stretch every interval by 'jiffies - 
> > numabalancing_migrate_next_window'.
> 
> Okay, I get your point.

Note that in practise it probably doesn't matter, but it just upsets my
OCD ;-)

> > Also, that all wants READ_ONCE/WRITE_ONCE, irrespective of the
> > spinlock/xchg.

> unsigned long interval = READ_ONCE(pgdat->numabalancing_migrate_next_window);
> 
> if (time_after(jiffies, interval)) {
>   interval += msecs_to_jiffies(migrate_interval_millisecs));
>   if (xchg(>numabalancing_migrate_nr_pages, 0))
>   WRITE_ONCE(pgdat->numabalancing_migrate_next_window, interval);
> }
> 
> Something like this?

Almost, you forgot about the case where 'jiffies -
numabalancing_migrate_next_window > interval'.

That wants to be something like:

  unsigned long timo = READ_ONCE(stupid_long_name);

  if (time_after(jiffies, timo) && xchg(_long_name, 0)) {
  do {
  timo += msec_to_jiffies(..);
  } while (unlikely(time_after(jiffies, timo);

  WRITE_ONCE(stupid_long_name, timo);
  }

Re: [PATCH 4.16 00/47] 4.16.14-stable review

[Greg Kroah-Hartman]

On Mon, Jun 04, 2018 at 01:47:12PM -0600, Shuah Khan wrote:
> On 06/04/2018 12:58 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.16.14 release.
> > There are 47 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Jun  6 06:55:34 UTC 2018.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.16.14-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.16.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h

Re: [PATCH 2/2] mm: don't skip memory guarantee calculations

[Michal Hocko]

On Mon 04-06-18 17:23:06, Roman Gushchin wrote:
[...]
> I'm happy to discuss any concrete issues/concerns, but I really see
> no reasons to drop it from the mm tree now and start the discussion
> from scratch.

I do not think this is ready for the current merge window. Sorry! I
would really prefer to see the whole thing in one series to have a
better picture.

-- 
Michal Hocko
SUSE Labs

[PATCH] irqchip/gic-v3-its: fix ITS queue timeout

[Yang Yingliang]

When the kernel booted with maxcpus=x, 'x' is smaller
than actual cpu numbers, the TAs of offline cpus won't
be set to its->collection.

If LPI is bind to offline cpu, sync cmd will use zero TA,
it leads to ITS queue timeout.  Fix this by choosing a
online cpu, if there is no online cpu in cpu_mask.

Signed-off-by: Yang Yingliang 
---
 drivers/irqchip/irq-gic-v3-its.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 5416f2b..edd92a9 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -2309,7 +2309,9 @@ static int its_irq_domain_activate(struct irq_domain 
*domain,
cpu_mask = cpumask_of_node(its_dev->its->numa_node);
 
/* Bind the LPI to the first possible CPU */
-   cpu = cpumask_first(cpu_mask);
+   cpu = cpumask_first_and(cpu_mask, cpu_online_mask);
+   if (!cpu_online(cpu))
+   cpu = cpumask_first(cpu_online_mask);
its_dev->event_map.col_map[event] = cpu;
irq_data_update_effective_affinity(d, cpumask_of(cpu));
 
@@ -2466,7 +2468,10 @@ static int its_vpe_set_affinity(struct irq_data *d,
bool force)
 {
struct its_vpe *vpe = irq_data_get_irq_chip_data(d);
-   int cpu = cpumask_first(mask_val);
+   int cpu = cpumask_first_and(mask_val, cpu_online_mask);
+
+   if (!cpu_online(cpu))
+   cpu = cpumask_first(cpu_online_mask);
 
/*
 * Changing affinity is mega expensive, so let's be as lazy as
-- 
1.8.3

Re: [PATCH 4.16 00/47] 4.16.14-stable review

[Naresh Kamboju]

On 4 June 2018 at 12:28, Greg Kroah-Hartman  wrote:
> This is the start of the stable review cycle for the 4.16.14 release.
> There are 47 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Jun  6 06:55:34 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.16.14-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.16.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

NOTE:  The boot failures are due to infrastructure issues.
Test failures are known issues and these will be added to skip list.
1. kselftest: rtnetlink.sh
2. ltp syscalls: cve-2017-5669
3. ltp cve: cve-2017-5669

Summary


kernel: 4.16.14-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.16.y
git commit: 79de57953e95a587e1b673af554995d899bdd006
git describe: v4.16.13-48-g79de57953e95
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.16-oe/build/v4.16.13-48-g79de57953e95


No regressions (compared to build v4.16.13)

Boards, architectures and test suites:
-

dragonboard-410c - arm64
* boot - pass: 10, fail: 2
* kselftest - skip: 26, pass: 40, fail: 2
* libhugetlbfs - skip: 1, pass: 89, fail: 1
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 6, pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - skip: 1, pass: 21,

hi6220-hikey - arm64
* boot - pass: 13,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 6, pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - skip: 1, pass: 21,
* ltp-io-tests - pass: 3,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 4, pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 132, pass: 1015, fail: 2
* ltp-timers-tests - pass: 13,

juno-r2 - arm64
* boot - pass: 21,
* kselftest - skip: 24, pass: 43, fail: 1
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-cve-tests - skip: 8, pass: 24, fail: 3
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 6, pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 4, pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 131, pass: 1016, fail: 2
* ltp-timers-tests - pass: 13,

qemu_arm
* boot - pass: 21,
* kselftest - skip: 31, pass: 36, fail: 1
* libhugetlbfs - skip: 1, pass: 87,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 18, pass: 63,
* ltp-cve-tests - skip: 8, pass: 22, fail: 5
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 5, pass: 61,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - skip: 1, pass: 21,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 7, pass: 7,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 93, pass: 1053, fail: 3
* ltp-timers-tests - pass: 13,

qemu_arm64
* boot - pass: 21,
* kselftest - skip: 29, pass: 40, fail: 1
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-cve-tests - skip: 8, pass: 23, fail: 4
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - skip: 6, pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - skip: 6, pass: 8,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - skip: 153, pass: 993, fail: 3
* ltp-timers-tests - pass: 13,

qemu_x86_64
* boot - pass: 21,
* kselftest - skip: 29, pass: 52, fail: 1
* libhugetlbfs - skip: 1, pass: 90,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - skip: 17, pass: 64,
* ltp-cve-tests - skip: 3, pass: 29, 

Re: [PATCH 1/3] mfd: cros: add charger port count command definition

[Lee Jones]

On Mon, 04 Jun 2018, Fabien Parent wrote:

> On Mon, Jun 4, 2018 at 1:59 AM, Lee Jones  wrote:
> > On Tue, 29 May 2018, Fabien Parent wrote:
> >
> >> A new more command has been added to the ChromeOS embedded controller
> >> that allows to get the number of charger port count. Unlike
> >> EC_CMD_USB_PD_PORTS, this new command also includes the dedicated
> >> port if present.
> >>
> >> This command will be used to expose the dedicated charger port
> >> in the ChromeOS charger driver.
> >>
> >> Signed-off-by: Fabien Parent 
> >> ---
> >>  include/linux/mfd/cros_ec_commands.h | 10 ++
> >>  1 file changed, 10 insertions(+)
> >
> > Does not want to apply.  I didn't investigate why.
> >
> > Please rebase and resend?
> 
> Sorry, I forgot to add you as "to:" to the patch series.
> This patch applies on top of https://lkml.org/lkml/2018/5/2/590
> ([PATCH v4 1/3] mfd: cros_ec: Add USBPD charger commands and struct
> definitions)

Okay.  Please re-submit after that set has landed then.

Please, also add my Ack to the patch:

For my own reference:
  Acked-for-MFD-by: Lee Jones 

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH V2 2/2] arm: dts: sunxi: Add missing cooling device properties for CPUs

[Maxime Ripard]

On Tue, Jun 05, 2018 at 10:17:49AM +0530, Viresh Kumar wrote:
> The cooling device properties, like "#cooling-cells" and
> "dynamic-power-coefficient", should either be present for all the CPUs
> of a cluster or none. If these are present only for a subset of CPUs of
> a cluster then things will start falling apart as soon as the CPUs are
> brought online in a different order. For example, this will happen
> because the operating system looks for such properties in the CPU node
> it is trying to bring up, so that it can register a cooling device.
> 
> Add such missing properties.
> 
> Fix other missing properties (clocks, OPP, clock latency) as well to
> make it all work.
> 
> Signed-off-by: Viresh Kumar 

Applied both, thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

[PATCH] perf tools: Fix object code reading for PTI entry trampolines

[Adrian Hunter]

Fix object code reading and the "Object code reading" test for PTI entry
trampolines.

perf tools uses map__rip_2objdump() to calculate objdump virtual addresses.
map__rip_2objdump() needs to be amended to deal with PTI entry trampolines.
Also the "Object code reading" test will not create maps for the PTI entry
trampolines unless the machine environment exists to show that the arch is
x86_64.

Signed-off-by: Adrian Hunter 
---
 tools/perf/tests/code-reading.c |  1 +
 tools/perf/util/map.c   | 14 ++
 2 files changed, 15 insertions(+)

diff --git a/tools/perf/tests/code-reading.c b/tools/perf/tests/code-reading.c
index afa4ce21ba7c..4892bd2dc33e 100644
--- a/tools/perf/tests/code-reading.c
+++ b/tools/perf/tests/code-reading.c
@@ -560,6 +560,7 @@ static int do_test_code_reading(bool try_kcore)
pid = getpid();
 
machine = machine__new_host();
+   machine->env = _env;
 
ret = machine__create_kernel_maps(machine);
if (ret < 0) {
diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index 92abc8e248c5..89ac5b5dc218 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -449,6 +449,20 @@ int map__fprintf_srcline(struct map *map, u64 addr, const 
char *prefix,
  */
 u64 map__rip_2objdump(struct map *map, u64 rip)
 {
+   struct kmap *kmap = __map__kmap(map);
+
+   /*
+* vmlinux does not have program headers for PTI entry trampolines and
+* kcore may not either. However the trampoline object code is on the
+* main kernel map, so just use that instead.
+*/
+   if (kmap && is_entry_trampoline(kmap->name) && kmap->kmaps && 
kmap->kmaps->machine) {
+   struct map *kernel_map = 
machine__kernel_map(kmap->kmaps->machine);
+
+   if (kernel_map)
+   map = kernel_map;
+   }
+
if (!map->dso->adjust_symbols)
return rip;
 
-- 
1.9.1

Re: [PATCH v5 00/10] track CPU utilization

[Vincent Guittot]

Hi Quentin,

On 25 May 2018 at 15:12, Vincent Guittot  wrote:
> This patchset initially tracked only the utilization of RT rq. During
> OSPM summit, it has been discussed the opportunity to extend it in order
> to get an estimate of the utilization of the CPU.
>
> - Patches 1-3 correspond to the content of patchset v4 and add utilization
>   tracking for rt_rq.
>
> When both cfs and rt tasks compete to run on a CPU, we can see some frequency
> drops with schedutil governor. In such case, the cfs_rq's utilization doesn't
> reflect anymore the utilization of cfs tasks but only the remaining part that
> is not used by rt tasks. We should monitor the stolen utilization and take
> it into account when selecting OPP. This patchset doesn't change the OPP
> selection policy for RT tasks but only for CFS tasks
>
> A rt-app use case which creates an always running cfs thread and a rt threads
> that wakes up periodically with both threads pinned on same CPU, show lot of
> frequency switches of the CPU whereas the CPU never goes idles during the
> test. I can share the json file that I used for the test if someone is
> interested in.
>
> For a 15 seconds long test on a hikey 6220 (octo core cortex A53 platfrom),
> the cpufreq statistics outputs (stats are reset just before the test) :
> $ cat /sys/devices/system/cpu/cpufreq/policy0/stats/total_trans
> without patchset : 1230
> with patchset : 14

I have attached the rt-app json file that I use for this test

>
> If we replace the cfs thread of rt-app by a sysbench cpu test, we can see
> performance improvements:
>
> - Without patchset :
> Test execution summary:
> total time:  15.0009s
> total number of events:  4903
> total time taken by event execution: 14.9972
> per-request statistics:
>  min:  1.23ms
>  avg:  3.06ms
>  max: 13.16ms
>  approx.  95 percentile:  12.73ms
>
> Threads fairness:
> events (avg/stddev):   4903./0.00
> execution time (avg/stddev):   14.9972/0.00
>
> - With patchset:
> Test execution summary:
> total time:  15.0014s
> total number of events:  7694
> total time taken by event execution: 14.9979
> per-request statistics:
>  min:  1.23ms
>  avg:  1.95ms
>  max: 10.49ms
>  approx.  95 percentile:  10.39ms
>
> Threads fairness:
> events (avg/stddev):   7694./0.00
> execution time (avg/stddev):   14.9979/0.00
>
> The performance improvement is 56% for this use case.
>
> - Patches 4-5 add utilization tracking for dl_rq in order to solve similar
>   problem as with rt_rq
>
> - Patches 6 uses dl and rt utilization in the scale_rt_capacity() and remove
>   dl and rt from sched_rt_avg_update
>
> - Patches 7-8 add utilization tracking for interrupt and use it select OPP
>   A test with iperf on hikey 6220 gives:
> w/o patchsetw/ patchset
> Tx 276 Mbits/sec304 Mbits/sec +10%
> Rx 299 Mbits/sec328 Mbits/sec +09%
>
> 8 iterations of iperf -c server_address -r -t 5
> stdev is lower than 1%
> Only WFI idle state is enable (shallowest arm idle state)
>
> - Patches 9 removes the unused sched_avg_update code
>
> - Patch 10 removes the unused sched_time_avg_ms
>
> Change since v3:
> - add support of periodic update of blocked utilization
> - rebase on lastest tip/sched/core
>
> Change since v2:
> - move pelt code into a dedicated pelt.c file
> - rebase on load tracking changes
>
> Change since v1:
> - Only a rebase. I have addressed the comments on previous version in
>   patch 1/2
>
> Vincent Guittot (10):
>   sched/pelt: Move pelt related code in a dedicated file
>   sched/rt: add rt_rq utilization tracking
>   cpufreq/schedutil: add rt utilization tracking
>   sched/dl: add dl_rq utilization tracking
>   cpufreq/schedutil: get max utilization
>   sched: remove rt and dl from sched_avg
>   sched/irq: add irq utilization tracking
>   cpufreq/schedutil: take into account interrupt
>   sched: remove rt_avg code
>   proc/sched: remove unused sched_time_avg_ms
>
>  include/linux/sched/sysctl.h |   1 -
>  kernel/sched/Makefile|   2 +-
>  kernel/sched/core.c  |  38 +---
>  kernel/sched/cpufreq_schedutil.c |  24 ++-
>  kernel/sched/deadline.c  |   7 +-
>  kernel/sched/fair.c  | 381 +++--
>  kernel/sched/pelt.c  | 395 
> +++
>  kernel/sched/pelt.h  |  63 +++
>  kernel/sched/rt.c|  10 +-
>  kernel/sched/sched.h |  57 --
>  kernel/sysctl.c  |   8 -
>  11 files changed, 563 insertions(+), 423 deletions(-)
>  create 

[PATCH v8 4/5] ARM: dts: Renesas RZN1D-DB Board base file

[Michel Pollet]

This adds a base device tree file for the RZN1-DB board, with only the
basic support allowing the system to boot to a prompt. Only one UART is
used, with only a single CPU running.

Signed-off-by: Michel Pollet 
Reviewed-by: Geert Uytterhoeven 
---
 arch/arm/boot/dts/Makefile  |  1 +
 arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts | 28 
 2 files changed, 29 insertions(+)
 create mode 100644 arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 37a3de7..c07f077 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -819,6 +819,7 @@ dtb-$(CONFIG_ARCH_RENESAS) += \
r8a7793-gose.dtb \
r8a7794-alt.dtb \
r8a7794-silk.dtb \
+   r9a06g032-rzn1d400-db.dtb \
sh73a0-kzm9g.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rv1108-evb.dtb \
diff --git a/arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts 
b/arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts
new file mode 100644
index 000..4e57ae2
--- /dev/null
+++ b/arch/arm/boot/dts/r9a06g032-rzn1d400-db.dts
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the RZN1D-DB Board
+ *
+ * Copyright (C) 2018 Renesas Electronics Europe Limited
+ *
+ */
+
+/dts-v1/;
+
+#include "r9a06g032.dtsi"
+
+/ {
+   model = "RZN1D-DB Board";
+   compatible = "renesas,rzn1d400-db", "renesas,r9a06g032";
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   aliases {
+   serial0 = 
+   };
+};
+
+ {
+   status = "okay";
+};
-- 
2.7.4

Re: [PATCH 07/19] sched/numa: Skip nodes that are at hoplimit

[Mel Gorman]

On Mon, Jun 04, 2018 at 03:30:16PM +0530, Srikar Dronamraju wrote:
> When comparing two nodes at a distance of hoplimit, we should consider
> nodes only upto hoplimit. Currently we also consider nodes at hoplimit
> distance too. Hence two nodes at a distance of "hoplimit" will have same
> groupweight. Fix this by skipping nodes at hoplimit.
> 
> Testcase   Time: Min Max Avg  StdDev
> numa01.sh  Real:  478.45  565.90  515.11   30.87
> numa01.sh   Sys:  207.79  271.04  232.94   21.33
> numa01.sh  User:39763.9347303.1243210.73 2644.86
> numa02.sh  Real:   60.00   61.46   60.780.49
> numa02.sh   Sys:   15.71   25.31   20.693.42
> numa02.sh  User: 5175.92 5265.86 5235.97   32.82
> numa03.sh  Real:  776.42  834.85  806.01   23.22
> numa03.sh   Sys:  114.43  128.75  121.655.49
> numa03.sh  User:60773.9364855.2562616.91 1576.39
> numa04.sh  Real:  456.93  511.95  482.91   20.88
> numa04.sh   Sys:  178.09  460.89  356.86   94.58
> numa04.sh  User:36312.0942553.2439623.21 2247.96
> numa05.sh  Real:  393.98  493.48  436.61   35.59
> numa05.sh   Sys:  164.49  329.15  265.87   61.78
> numa05.sh  User:33182.6536654.5335074.51 1187.71
> 
> Testcase   Time: Min Max Avg  StdDev   %Change
> numa01.sh  Real:  414.64  819.20  556.08  147.70   -7.36%
> numa01.sh   Sys:   77.52  205.04  139.40   52.05   67.10%
> numa01.sh  User:37043.2461757.8845517.48 9290.38   -5.06%
> numa02.sh  Real:   60.80   63.32   61.630.88   -1.37%
> numa02.sh   Sys:   17.35   39.37   25.717.33   -19.5%
> numa02.sh  User: 5213.79 5374.73 5268.90   55.09   -0.62%
> numa03.sh  Real:  780.09  948.64  831.43   63.02   -3.05%
> numa03.sh   Sys:  104.96  136.92  116.31   11.34   4.591%
> numa03.sh  User:60465.4273339.7864368.03 4700.14   -2.72%
> numa04.sh  Real:  412.60  681.92  521.29   96.64   -7.36%
> numa04.sh   Sys:  210.32  314.10  251.77   37.71   41.74%
> numa04.sh  User:34026.3845581.2038534.49 4198.53   2.825%
> numa05.sh  Real:  394.79  439.63  411.35   16.87   6.140%
> numa05.sh   Sys:  238.32  330.09  292.31   38.32   -9.04%
> numa05.sh  User:33456.4534876.0734138.62  609.45   2.741%
> 
> While there is a regression with this change, this change is needed from a
> correctness perspective. Also it helps consolidation as seen from perf bench
> output.
> 
> Signed-off-by: Srikar Dronamraju 

Agreed that it's better from a correctness POV

Acked-by: Mel Gorman 

-- 
Mel Gorman
SUSE Labs

Re: [PATCH 06/19] sched/debug: Reverse the order of printing faults

[Mel Gorman]

On Mon, Jun 04, 2018 at 03:30:15PM +0530, Srikar Dronamraju wrote:
> Fix the order in which the private and shared numa faults are getting
> printed.
> 
> Shouldn't have any performance impact.
> 
> Signed-off-by: Srikar Dronamraju 

Acked-by: Mel Gorman 

-- 
Mel Gorman
SUSE Labs

Re: [PATCH 08/19] sched/numa: Remove unused task_capacity from numa_stats

[Mel Gorman]

On Mon, Jun 04, 2018 at 03:30:17PM +0530, Srikar Dronamraju wrote:
> task_capacity field in struct numa_stats is redundant.
> Also move nr_running for better packing within the struct.
> 
> No functional changes.
> 
> Signed-off-by: Srikar Dronamraju 

Acked-by: Mel Gorman 

-- 
Mel Gorman
SUSE Labs

Re: [rfc patch] mm, oom: fix unnecessary killing of additional processes

[Michal Hocko]

On Mon 04-06-18 21:25:39, David Rientjes wrote:
> On Fri, 1 Jun 2018, Michal Hocko wrote:
> 
> > > We've discussed the mm 
> > > having a single blockable mmu notifier.  Regardless of how we arrive at 
> > > the point where the oom reaper can't free memory, which could be any of 
> > > those three cases, if (1) the original victim is sufficiently large that 
> > > follow-up oom kills would become unnecessary and (2) other threads 
> > > allocate/charge before the oom victim reaches exit_mmap(), this occurs.
> > > 
> > > We have examples of cases where oom reaping was successful, but the rss 
> > > numbers in the kernel log are very similar to when it was oom killed and 
> > > the process is known not to mlock, the reason is because the oom reaper 
> > > could free very little memory due to blockable mmu notifiers.
> > 
> > Please be more specific. Which notifiers these were. Blockable notifiers
> > are a PITA and we should be addressing them. That requiers identifying
> > them first.
> > 
> 
> The most common offender seems to be ib_umem_notifier, but I have also 
> heard of possible occurrences for mv_invl_range_start() for xen, but that 
> would need more investigation.  The rather new invalidate_range callback 
> for hmm mirroring could also be problematic.  Any mmu_notifier without 
> MMU_INVALIDATE_DOES_NOT_BLOCK causes the mm to immediately be disregarded.  

Yes, this is unfortunate and it was meant as a stop gap quick fix with a
long term vision to be fixed properly. I am pretty sure that we can do
much better here. Teach mmu_notifier_invalidate_range_start to get a
non-block flag and back out on ranges that would block. I am pretty sure
that notifiers can be targeted a lot and so we can still process some
vmas at least.

> For this reason, we see testing harnesses often oom killed immediately 
> after running a unittest that stresses reclaim or compaction by inducing a 
> system-wide oom condition.  The harness spawns the unittest which spawns 
> an antagonist memory hog that is intended to be oom killed.  When memory 
> is mlocked or there are a large number of threads faulting memory for the 
> antagonist, the unittest and the harness itself get oom killed because the 
> oom reaper sets MMF_OOM_SKIP; this ends up happening a lot on powerpc.  
> The memory hog has mm->mmap_sem readers queued ahead of a writer that is 
> doing mmap() so the oom reaper can't grab the sem quickly enough.

How come the writer doesn't back off. mmap paths should be taking an
exclusive mmap sem in killable sleep so it should back off. Or is the
holder of the lock deep inside mmap path doing something else and not
backing out with the exclusive lock held?
 
[...]

> > As I've already said. I will nack any timeout based solution until we
> > address all particular problems and still see more to come. Here we have
> > a clear goal. Address mlocked pages and identify mmu notifier offenders.
> 
> I cannot fix all mmu notifiers to not block, I can't fix the configuration 
> to allow direct compaction for thp allocations and a large number of 
> concurrent faulters, and I cannot fix userspace mlocking a lot of memory.  
> It's worthwhile to work in that direction, but it will never be 100% 
> possible to avoid.  We must have a solution that prevents innocent 
> processes from consistently being oom killed completely unnecessarily.

None of the above has been attempted and shown not worth doing. The oom
even should be a rare thing to happen so I absolutely do not see any
reason to rush any misdesigned fix to be done right now.

-- 
Michal Hocko
SUSE Labs

Re: [greybus-dev] [PATCH] Staging:greybus Fix comparison to NULL

[Johan Hovold]

On Tue, Jun 05, 2018 at 11:02:36AM +0530, Viresh Kumar wrote:
> On 03-06-18, 08:52, Janani Sankara Babu wrote:
> > This patch replaces comparison of var to NULL with !var
> > 
> > Signed-off-by: Janani Sankara Babu 
> > ---
> >  drivers/staging/greybus/core.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/staging/greybus/core.c b/drivers/staging/greybus/core.c
> > index dafa430..5d14a4e 100644
> > --- a/drivers/staging/greybus/core.c
> > +++ b/drivers/staging/greybus/core.c
> > @@ -48,7 +48,7 @@ static bool greybus_match_one_id(struct gb_bundle *bundle,
> >  static const struct greybus_bundle_id *
> >  greybus_match_id(struct gb_bundle *bundle, const struct greybus_bundle_id 
> > *id)
> >  {
> > -   if (id == NULL)
> > +   if (!id)
> 
> It is pretty much personal preference and there is no good reason to
> accept this patch really.

I agree with you, Viresh, but greybus is still living in staging which
makes checkpatch enable the --strict option, thereby forcing its authors
preferences onto the rest of us.

I also do understand Greg's point that while --strict is enabled,
rejecting such patches will probably cause some new submitters to do
work for nothing, which is not good.

On the other hand, I at least think we should enforce having a patch
description that clearly indicates that this is just something to make
checkpatch happy (reserving the term "fix" for proper fixes, at least if
not used in conjunction with "checkpatch warning").

So Janani, would you mind resubmitting this patch with a slightly
modified commit message, such as:

staging: greybus: clean up NULL comparisons

Replace comparison of var to NULL with !var in order to address
a checkpatch (strict) warning.

You could also change the sole remaining comparison to NULL in bundle.c
in the same patch.

Thanks,
Johan

Re: [PATCH 4.9 00/29] 4.9.106-stable review

[Naresh Kamboju]

On 4 June 2018 at 12:27, Greg Kroah-Hartman  wrote:
> This is the start of the stable review cycle for the 4.9.106 release.
> There are 29 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Jun  6 06:57:52 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.106-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

NOTE: LTP fs "read_all_sys" broken on hikey and this is always reproducible.
But test PASS on qemu_arm64.
"read_all_sys" is not a real failure consider this as waiver and will
investigate.

Test log:

read_all -d /sys -q -r 10
incrementing stop
tst_test.c:1015: INFO: Timeout per run is 0h 15m 00s
read_all.c:317: BROK: queue_push(workers[j].q, path) timed out

Summary


kernel: 4.9.106-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: b0a024051e17ad3bdd5f6b1e52f5c67fb6087cb9
git describe: v4.9.105-31-gb0a024051e17
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.105-31-gb0a024051e17

No regressions (compared to build v4.9.105)

Re: [PATCH 1/2] livepatch: Send a fake signal periodically

[Miroslav Benes]

On Mon, 4 Jun 2018, Josh Poimboeuf wrote:

> On Mon, Jun 04, 2018 at 04:16:35PM +0200, Miroslav Benes wrote:
> > An administrator may send a fake signal to all remaining blocking tasks
> > of a running transition by writing to
> > /sys/kernel/livepatch//signal attribute. Let's do it
> > automatically after 10 seconds. The timeout is chosen deliberately. It
> > gives the tasks enough time to transition themselves.
> > 
> > Theoretically, sending it once should be more than enough. Better be safe
> > than sorry, so send it periodically.
> 
> This is the part I don't understand.  Why do it periodically?

I met (rare!) cases when doing it once was not enough due to a race and 
the signal was missed. However involved testcases were really artificial.
 
> Instead, might it make sense to just send the signals once, and if that
> doesn't work, reverse the transition?  Then we could make patching a
> synchronous operation.  But then, it might be remotely possible that the
> reverse operation also stalls (e.g., on a kthread).  So, maybe it's best
> to just leave all these controls in the hands of the user.

And there is 'force' option...

So given all this, I'd call klp_send_signals() once and then leave it up 
to the user. Would that work for you?

> All that said, a few code review comments:
> 
> - AFAICT, it does an 8 second delay instead of a 10 second delay,
>   because

Not that it matters, because it is still wrong, but it is a 9 second 
delay (or I miscounted again).

>   a) try_complete_transition() is first called before there's any delay;
> 
>   b) the preincrement operator used on signals_cnt.
> 
> - I think 15 seconds might be a better default.  I've seen longer
>   patching delays on a system with 100+ CPUs.

Ok, why not. 

> - If a kthread or idle task is sleeping on a patched function, the
>   pr_notice("signaling remaining tasks\n") will be repeated continously.

True.

> - It might be cleaner to do it from the delayed work function
>   (klp_transition_work_fn).

I considered it but then decided to do it in klp_try_complete_transition() 
under 'if (!complete)'. It belongs right there in my opinion.

Thanks,
Miroslav

Re: kernel panic in reading /proc/kpageflags when enabling RAM-simulated PMEM

[Naoya Horiguchi]

On Mon, Jun 04, 2018 at 06:18:36PM -0700, Matthew Wilcox wrote:
> On Tue, Jun 05, 2018 at 12:54:03AM +, Naoya Horiguchi wrote:
> > Reproduction precedure is like this:
> >  - enable RAM based PMEM (with a kernel boot parameter like memmap=1G!4G)
> >  - read /proc/kpageflags (or call tools/vm/page-types with no arguments)
> >  (- my kernel config is attached)
> > 
> > I spent a few days on this, but didn't reach any solutions.
> > So let me report this with some details below ...
> > 
> > In the critial page request, stable_page_flags() is called with an argument
> > page whose ->compound_head was somehow filled with '0x'.
> > And compound_head() returns (struct page *)(head - 1), which explains the
> > address 0xfffe in the above message.
> 
> Hm.  compound_head shares with:
> 
> struct list_head lru;
> struct list_head slab_list; /* uses lru */
> struct {/* Partial pages */
> struct page *next;
> unsigned long _compound_pad_1;  /* compound_head */
> unsigned long _pt_pad_1;/* compound_head */
> struct dev_pagemap *pgmap;
> struct rcu_head rcu_head;
> 
> None of them should be -1.
> 
> > It seems that this kernel panic happens when reading kpageflags of pfn range
> > [0xbffd7, 0xc), which coresponds to a 'reserved' range.
> > 
> > [0.00] user-defined physical RAM map:
> > [0.00] user: [mem 0x-0x0009fbff] usable
> > [0.00] user: [mem 0x0009fc00-0x0009] reserved
> > [0.00] user: [mem 0x000f-0x000f] reserved
> > [0.00] user: [mem 0x0010-0xbffd6fff] usable
> > [0.00] user: [mem 0xbffd7000-0xbfff] reserved
> > [0.00] user: [mem 0xfeffc000-0xfeff] reserved
> > [0.00] user: [mem 0xfffc-0x] reserved
> > [0.00] user: [mem 0x0001-0x00013fff] persistent 
> > (type 12)
> > 
> > So I guess 'memmap=' parameter might badly affect the memory initialization 
> > process.
> > 
> > This problem doesn't reproduce on v4.17, so some pre-released patch 
> > introduces it.
> > I hope this info helps you find the solution/workaround.
> 
> Can you try bisecting this?  It could be one of my patches to reorder struct
> page, or it could be one of Pavel's deferred page initialisation patches.
> Or something else ;-)

Thank you for the comment. I'm trying bisecting now, let you know the result 
later.

And I found that my statement "not reproduce on v4.17" was wrong (I used
different kvm guests, which made some different test condition and misguided 
me),
this seems an older (at least < 4.15) bug.

Thanks,
Naoya Horiguchi

Re: [greybus-dev] [PATCH] Staging:greybus Fix comparison to NULL

[Dan Carpenter]

On Tue, Jun 05, 2018 at 11:02:36AM +0530, Viresh Kumar wrote:
> On 03-06-18, 08:52, Janani Sankara Babu wrote:
> > This patch replaces comparison of var to NULL with !var
> > 
> > Signed-off-by: Janani Sankara Babu 
> > ---
> >  drivers/staging/greybus/core.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/staging/greybus/core.c b/drivers/staging/greybus/core.c
> > index dafa430..5d14a4e 100644
> > --- a/drivers/staging/greybus/core.c
> > +++ b/drivers/staging/greybus/core.c
> > @@ -48,7 +48,7 @@ static bool greybus_match_one_id(struct gb_bundle *bundle,
> >  static const struct greybus_bundle_id *
> >  greybus_match_id(struct gb_bundle *bundle, const struct greybus_bundle_id 
> > *id)
> >  {
> > -   if (id == NULL)
> > +   if (!id)
> 
> It is pretty much personal preference and there is no good reason to accept 
> this
> patch really.

Checkpatch complains, so it's Official Kernel Style now.

The != NULL comparison is a double negative which makes it not less
annoying than official kernel style.

regards,
dan carpenter

Re: [PATCH v3 1/3] cpufreq: imx6q: check speed grades for i.MX6ULL

[Sébastien Szymanski]

On 05/23/2018 06:29 AM, Viresh Kumar wrote:
> On 22-05-18, 08:28, Sébastien Szymanski wrote:
>> Check the max speed supported from the fuses for i.MX6ULL and update the
>> operating points table accordingly.
>>
>> Signed-off-by: Sébastien Szymanski 
>> ---
>>
>> Changes for v3:
>>  - none
> 
> @Sascha and Shawn: Can you guys please Ack this series if there is
> nothing wrong with it ?
> 

ping...

-- 
Sébastien Szymanski
Software engineer, Armadeus Systems
Tel: +33 (0)9 72 29 41 44
Fax: +33 (0)9 72 28 79 26

Re: [PATCH 4.16 00/47] 4.16.14-stable review

[Greg Kroah-Hartman]

On Tue, Jun 05, 2018 at 12:17:50PM +0530, Naresh Kamboju wrote:
> On 4 June 2018 at 12:28, Greg Kroah-Hartman  
> wrote:
> > This is the start of the stable review cycle for the 4.16.14 release.
> > There are 47 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed Jun  6 06:55:34 UTC 2018.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.16.14-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.16.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> 
> Results from Linaro’s test farm.
> No regressions on arm64, arm and x86_64.
> 
> NOTE:  The boot failures are due to infrastructure issues.
> Test failures are known issues and these will be added to skip list.
> 1. kselftest: rtnetlink.sh
> 2. ltp syscalls: cve-2017-5669
> 3. ltp cve: cve-2017-5669

Thanks for testing all 3 of these and letting me know.

greg k-h

Re: [PATCH 4.14 00/52] 4.14.48-stable review

[Greg Kroah-Hartman]

On Mon, Jun 04, 2018 at 04:11:03PM -0700, Kevin Hilman wrote:
> kernelci.org bot  writes:
> 
> > Full Boot Summary: 
> > https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.14.47-53-g721adf61fde2/
> > Full Build Summary: 
> > https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.47-53-g721adf61fde2/
> >
> > Tree: stable-rc
> > Branch: linux-4.14.y
> > Git Describe: v4.14.47-53-g721adf61fde2
> > Git Commit: 721adf61fde28b9a87a95e45ecf3f5a325e7c76f
> > Git URL: 
> > http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > Tested: 56 unique boards, 23 SoC families, 14 builds out of 185
> >
> > Boot Regressions Detected:
> >
> > arm64:
> >
> > defconfig:
> > meson-gxl-s905x-khadas-vim:
> > lab-baylibre: failing since 39 days (last pass: 
> > v4.14.26-140-g2a1700a4929f - first fail: v4.14.36-184-g3cd53e436ee2)
> >
> > Conflicting Boot Failure Detected: (These likely are not failures as other 
> > labs are reporting PASS. Needs review.)
> 
> TL;DR;  All is well.
> 
> The failing board is having a power supply issue and has been taken
> offline for repair.  Since the same board is passing fine in another
> lab, it can be ignored.

Thanks for the updates on this, and the 4.9 board breakage.

greg k-h

Re: [PATCH v5 24/31] kconfig: add CC_IS_GCC and GCC_VERSION

[Stefan Agner]

On 05.06.2018 08:27, Masahiro Yamada wrote:
> 2018-06-05 14:50 GMT+09:00 Stefan Agner :
>> On 05.06.2018 02:07, Masahiro Yamada wrote:
>>> Hi Stefan
>>>
>>> 2018-06-05 6:49 GMT+09:00 Stefan Agner :
 Hi Masahiro,

 On 28.05.2018 11:22, Masahiro Yamada wrote:
> This will be useful to specify the required compiler version,
> like this:
>
> config FOO
> bool "Use Foo"
> depends on GCC_VERSION >= 40800
> help
>   This feature requires GCC 4.8 or newer.
>

 I tried using CC_IS_GCC today while using clang. It seems that it is set
 to y despite I am using CC=clang.

 .config looks like this after config:

 ...
 CONFIG_CC_IS_GCC=y
 CONFIG_GCC_VERSION=40201
 CONFIG_CC_IS_CLANG=y
 CONFIG_CLANG_VERSION=6
 ...


 I am using clang 6.0.0 on Arch Linux, which seems to return a version
 when using gcc-version.sh:
 ./scripts/gcc-version.sh clang | sed 's/^0*//'
 402

 I guess that should not be the case?

>>>
>>>
>>> What will 'clang --version' print on your machine?
>>
>> $ clang --version
>> clang version 6.0.0 (tags/RELEASE_600/final)
>> Target: x86_64-pc-linux-gnu
>> Thread model: posix
>> InstalledDir:
>> /home/ags/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf/bin
>>
>> I use a symlink to clang in my cross compiler toolchain, that is why
>> InstalledDir points to a GCC toolchain.
>>
> 
> Ah, I see.
> 
> 
> I will fix it up like follows:
> 
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index e5a0d89..efc43c6 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -9,7 +9,7 @@ config DEFCONFIG_LIST
> default "arch/$(ARCH)/defconfig"
> 
>  config CC_IS_GCC
> -   def_bool $(success,$(CC) --version | grep -q gcc)
> +   def_bool $(success,$(CC) --version | head -n 1 | grep -q gcc)

Yes that works for me:

...
CONFIG_GCC_VERSION=0
   
CONFIG_CC_IS_CLANG=y
   
CONFIG_CLANG_VERSION=6
...

--
Stefan

> 
>  config GCC_VERSION
> int
> @@ -17,7 +17,7 @@ config GCC_VERSION
> default 0
> 
>  config CC_IS_CLANG
> -   def_bool $(success,$(CC) --version | grep -q clang)
> +   def_bool $(success,$(CC) --version | head -n 1 | grep -q clang)
> 
>  config CLANG_VERSION
> int
> 
> 
> 
> 
> Best Regards
> Masahiro Yamada

Re: [PATCH 1/1] staging: wilc1000: Use common structs to parse ip packets

[Dan Carpenter]

On Mon, Jun 04, 2018 at 09:27:02PM +0200, Thibaut Robert wrote:
> Le lundi 04 juin 2018 à 10:55:49 (+0530), Ajay Singh a écrit :
> > 
> > Thank you for submitting the patches.
> > 
> > The modification in this patch looks okay to me.
> > Please resend this by including changes as suggested by Dan.
> > I can do the modification and resubmit this patch by including review
> > comments, if its okay with you.
> > 
> Sorry, I would like to address the comments, but still had no time to do it 
> correctly. I
> am doing this as a hobby and am still learning so forgive me for the delay. 
> If you can wait a little bit more, I'll resend an updated version.
> 
> Thanks for your time !

When you're a kernel dev, you sometimes do get the feeling that everyone
is waiting for you.  We're not.  There is no rush.  We read through your
email and reply and then it's gone from our mind like dust in the wind.
There is never a rush and you will never run out of more work to do.

Plus the merge window is open so Greg won't even look at it for the next
several weeks.

Take all the time you need.

I normally write a patch, then wait until morning so I can review it
with fresh eyes before sending it.  If I wait longer than a day, though,
I forget what the issue is and I have to retest it from scratch.  After
one day in my outbox a patch gets old and boring so those are low
quality.  If it's a cleanup patch, I'll probably just delete it instead.

regards,
dan carpenter

Re: [PATCH v6 8/8] x86/microcode/AMD: Don't scan past the CPU equivalence table data

[Borislav Petkov]

On Sun, May 20, 2018 at 12:07:22AM +0200, Maciej S. Szmigiero wrote:
> Currently, the code scanning a CPU equivalence table read from a microcode
> container file assumes that it actually contains a terminating zero entry,
> but if does not then the code will continue the scan past its valid data.
> 
> For the late loader this can be improved by always appending a terminating
> zero entry to such table when loading it.
> This way we don't need an extra global variable for holding the table size
> and we don't have to reject such incomplete tables (for backward
> compatibility with the existing code which didn't do so).
> 
> For the early loader, since we can't allocate memory and have to work
> in-place, let's pass an explicit size of this table to its scanning
> functions so they will know when to stop.

I don't like the difference between early and late here. Just pass
explicit size to the late loader too.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [PATCH v5 24/31] kconfig: add CC_IS_GCC and GCC_VERSION

[Masahiro Yamada]

2018-06-05 14:50 GMT+09:00 Stefan Agner :
> On 05.06.2018 02:07, Masahiro Yamada wrote:
>> Hi Stefan
>>
>> 2018-06-05 6:49 GMT+09:00 Stefan Agner :
>>> Hi Masahiro,
>>>
>>> On 28.05.2018 11:22, Masahiro Yamada wrote:
 This will be useful to specify the required compiler version,
 like this:

 config FOO
 bool "Use Foo"
 depends on GCC_VERSION >= 40800
 help
   This feature requires GCC 4.8 or newer.

>>>
>>> I tried using CC_IS_GCC today while using clang. It seems that it is set
>>> to y despite I am using CC=clang.
>>>
>>> .config looks like this after config:
>>>
>>> ...
>>> CONFIG_CC_IS_GCC=y
>>> CONFIG_GCC_VERSION=40201
>>> CONFIG_CC_IS_CLANG=y
>>> CONFIG_CLANG_VERSION=6
>>> ...
>>>
>>>
>>> I am using clang 6.0.0 on Arch Linux, which seems to return a version
>>> when using gcc-version.sh:
>>> ./scripts/gcc-version.sh clang | sed 's/^0*//'
>>> 402
>>>
>>> I guess that should not be the case?
>>>
>>
>>
>> What will 'clang --version' print on your machine?
>
> $ clang --version
> clang version 6.0.0 (tags/RELEASE_600/final)
> Target: x86_64-pc-linux-gnu
> Thread model: posix
> InstalledDir:
> /home/ags/gcc-linaro-7.2.1-2017.11-x86_64_arm-linux-gnueabihf/bin
>
> I use a symlink to clang in my cross compiler toolchain, that is why
> InstalledDir points to a GCC toolchain.
>

Ah, I see.


I will fix it up like follows:


diff --git a/init/Kconfig b/init/Kconfig
index e5a0d89..efc43c6 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -9,7 +9,7 @@ config DEFCONFIG_LIST
default "arch/$(ARCH)/defconfig"

 config CC_IS_GCC
-   def_bool $(success,$(CC) --version | grep -q gcc)
+   def_bool $(success,$(CC) --version | head -n 1 | grep -q gcc)

 config GCC_VERSION
int
@@ -17,7 +17,7 @@ config GCC_VERSION
default 0

 config CC_IS_CLANG
-   def_bool $(success,$(CC) --version | grep -q clang)
+   def_bool $(success,$(CC) --version | head -n 1 | grep -q clang)

 config CLANG_VERSION
int




Best Regards
Masahiro Yamada

Re: [PATCH V4] powercap/drivers/idle_injection: Add an idle injection framework

[Daniel Lezcano]

On 05/06/2018 07:53, Viresh Kumar wrote:
> On 05-06-18, 07:48, Daniel Lezcano wrote:
>> As soon as we reach complete(), no timer can be set because of the
>> condition before.
> 
> Why not ? We aren't using any locks here and it is possible that 
> run_duration_ms
> is set to 0 from idle_injection_stop() only after the first thread has 
> restarted
> the hrtimer. Isn't it ?

If he restarted the timer, complete() won't be called and
idle_injection_stop() will wait until the idle cycle injection is finished.


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

Follow Linaro:   Facebook |
 Twitter |
 Blog

RE: Re: [PATCH] Smack: Fix memory leak in smack_inode_getsecctx

[CHANDAN VN]

 

>On Mon, Jun 04, 2018 at 02:01:34PM -0700, Casey Schaufler wrote:
>> On 6/1/2018 10:45 AM, Casey Schaufler wrote:
>> > Fix memory leak in smack_inode_getsecctx
>> >
>> > The implementation of smack_inode_getsecctx() made
>> > incorrect assumptions about how Smack presents a security
>> > context. Smack does not need to allocate memory to support
>> > security contexts, so "releasing" a Smack context is a no-op.
>> > The code made an unnecessary copy and returned that as a
>> > context, which was never freed. The revised implementation
>> > returns the context correctly.
>> >
>> > Signed-off-by: Casey Schaufler 
>> 
>> Tejun, does this pass your tests?
 
>Oh, I'm not the one who reported.  Chandan?
Looks good to me. Leak not found.

[lkp-robot] [x86/vdso] f52001961d: BUG:kernel_hang_in_early-boot_stage,last_printk:Probing_EDD(edd=off_to_disable)...ok

[kernel test robot]

FYI, we noticed the following commit (built with gcc-5):

commit: f52001961d6e5c397e40c4d440103288cdce9a79 ("x86/vdso: Move out the CPU 
number store")
url: 
https://github.com/0day-ci/linux/commits/Chang-S-Bae/x86-Enable-FSGSBASE-instructions/20180602-125452


in testcase: boot

on test machine: qemu-system-i386 -enable-kvm -m 256M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+--+++
|   
   | 38a5d7ab4a | f52001961d |
+--+++
| boot_successes
   | 0  | 0  |
| boot_failures 
   | 14 | 36 |
| WARNING:at_lib/debugobjects.c:#__debug_object_init
   | 14 ||
| EIP:__debug_object_init   
   | 14 ||
| 
BUG:kernel_hang_in_early-boot_stage,last_printk:Probing_EDD(edd=off_to_disable)...ok
 | 0  | 36 |
+--+++



early console in setup code
Probing EDD (edd=off to disable)... ok
BUG: kernel hang in early-boot stage, last printk: Probing EDD (edd=off to 
disable)... ok
Linux version 4.17.0-rc6-00163-gf520019 #1
Command line: ip=vm-lkp-nhm-dp1-yocto-i386-16::dhcp root=/dev/ram0 user=lkp 
job=/lkp/scheduled/vm-lkp-nhm-dp1-yocto-i386-16/boot-1-yocto-tiny-i386-2016-04-22.cgz-f52001961d6e5c397e40c4d440103288cdce9a79-20180604-59345-q3lbrc-0.yaml
 ARCH=i386 kconfig=i386-randconfig-x0-06021157 
branch=linux-devel/devel-catchup-201806021429 
commit=f52001961d6e5c397e40c4d440103288cdce9a79 
BOOT_IMAGE=/pkg/linux/i386-randconfig-x0-06021157/gcc-5/f52001961d6e5c397e40c4d440103288cdce9a79/vmlinuz-4.17.0-rc6-00163-gf520019
 max_uptime=600 
RESULT_ROOT=/result/boot/1/vm-lkp-nhm-dp1-yocto-i386/yocto-tiny-i386-2016-04-22.cgz/i386-randconfig-x0-06021157/gcc-5/f52001961d6e5c397e40c4d440103288cdce9a79/0
 LKP_SERVER=inn debug apic=debug sysrq_always_enabled 
rcupdate.rcu_cpu_stall_timeout=100 net.ifnames=0 printk.devkmsg=on panic=-1 
softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 
prompt_ramdisk=0 drbd.minor_count=8 systemd.log_level=err ignore_loglevel 
console=tty0 earlyprintk=ttyS0,115200 console=ttyS0,115200 vga=normal rw 
drbd.minor_count=8 rcuperf.shutdown=0

Elapsed time: 310



To reproduce:

git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.17.0-rc6 Kernel Configuration
#
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_FILTER_PGPROT=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
CONFIG_KERNEL_BZIP2=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
# CONFIG_USELIB is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#

Re: [patch 2/8] genirq/generic_pending: Do not lose pending affinity update

[Song Liu]

On Mon, Jun 4, 2018 at 8:33 AM, Thomas Gleixner  wrote:
> The generic pending interrupt mechanism moves interrupts from the interrupt
> handler on the original target CPU to the new destination CPU. This is
> required for x86 and ia64 due to the way the interrupt delivery and
> acknowledge works if the interrupts are not remapped.
>
> However that update can fail for various reasons. Some of them are valid
> reasons to discard the pending update, but the case, when the previous move
> has not been fully cleaned up is not a legit reason to fail.
>
> Check the return value of irq_do_set_affinity() for -EBUSY, which indicates
> a pending cleanup, and rearm the pending move in the irq dexcriptor so it's
> tried again when the next interrupt arrives.
>
> Fixes: 996c591227d9 ("x86/irq: Plug vector cleanup race")
> Signed-off-by: Thomas Gleixner 
> Cc: sta...@vger.kernel.org

Tested-by: Song Liu 

> ---
>  kernel/irq/migration.c |   24 ++--
>  1 file changed, 18 insertions(+), 6 deletions(-)
>
> --- a/kernel/irq/migration.c
> +++ b/kernel/irq/migration.c
> @@ -38,17 +38,18 @@ bool irq_fixup_move_pending(struct irq_d
>  void irq_move_masked_irq(struct irq_data *idata)
>  {
> struct irq_desc *desc = irq_data_to_desc(idata);
> -   struct irq_chip *chip = desc->irq_data.chip;
> +   struct irq_data *data = >irq_data;
> +   struct irq_chip *chip = data->chip;
>
> -   if (likely(!irqd_is_setaffinity_pending(>irq_data)))
> +   if (likely(!irqd_is_setaffinity_pending(data)))
> return;
>
> -   irqd_clr_move_pending(>irq_data);
> +   irqd_clr_move_pending(data);
>
> /*
>  * Paranoia: cpu-local interrupts shouldn't be calling in here anyway.
>  */
> -   if (irqd_is_per_cpu(>irq_data)) {
> +   if (irqd_is_per_cpu(data)) {
> WARN_ON(1);
> return;
> }
> @@ -73,9 +74,20 @@ void irq_move_masked_irq(struct irq_data
>  * For correct operation this depends on the caller
>  * masking the irqs.
>  */
> -   if (cpumask_any_and(desc->pending_mask, cpu_online_mask) < nr_cpu_ids)
> -   irq_do_set_affinity(>irq_data, desc->pending_mask, 
> false);
> +   if (cpumask_any_and(desc->pending_mask, cpu_online_mask) < 
> nr_cpu_ids) {
> +   int ret;
>
> +   ret = irq_do_set_affinity(data, desc->pending_mask, false);
> +   /*
> +* If the there is a cleanup pending in the underlying
> +* vector management, reschedule the move for the next
> +* interrupt. Leave desc->pending_mask intact.
> +*/
> +   if (ret == -EBUSY) {
> +   irqd_set_move_pending(data);
> +   return;
> +   }
> +   }
> cpumask_clear(desc->pending_mask);
>  }
>
>
>

Re: [patch 1/8] x86/apic/vector: Prevent hlist corruption and leaks

[Song Liu]

On Mon, Jun 4, 2018 at 8:33 AM, Thomas Gleixner  wrote:
> Several people observed the WARN_ON() in irq_matrix_free() which triggers
> when the caller tries to free an vector which is not in the allocation
> range. Song provided the trace information which allowed to decode the root
> cause.
>
> The rework of the vector allocation mechanism failed to preserve a sanity
> check, which prevents setting a new target vector/CPU when the previous
> affinity change has not fully completed.
>
> As a result a half finished affinity change can be overwritten, which can
> cause the leak of a irq descriptor pointer on the previous target CPU and
> double enqueue of the hlist head into the cleanup lists of two or more
> CPUs. After one CPU cleaned up its vector the next CPU will invoke the
> cleanup handler with vector 0, which triggers the out of range warning in
> the matrix allocator.
>
> Prevent this by checking the apic_data of the interrupt whether the
> move_in_progress flag is false and the hlist node is not hashed. Return
> -EBUSY if not.
>
> This prevents the damage and restores the behaviour before the vector
> allocation rework, but due to other changes in that area it also widens the
> chance that user space can observe -EBUSY. In theory this should be fine,
> but actually not all user space tools handle -EBUSY correctly. Addressing
> that is not part of this fix, but will be addressed in follow up patches.
>
> Fixes: 69cde0004a4b ("x86/vector: Use matrix allocator for vector assignment")
> Reported-by: Dmitry Safonov <0x7f454...@gmail.com>
> Reported-by: Tariq Toukan 
> Reported-by: Song Liu 
> Signed-off-by: Thomas Gleixner 
> Cc: sta...@vger.kernel.org

Thanks Thomas!

This patch alone fixes my test: ethtool -L in a loop.

I also run the same test for the full set, and it works well.

Tested-by: Song Liu 


> ---
>  arch/x86/kernel/apic/vector.c |9 +
>  1 file changed, 9 insertions(+)
>
> --- a/arch/x86/kernel/apic/vector.c
> +++ b/arch/x86/kernel/apic/vector.c
> @@ -235,6 +235,15 @@ static int allocate_vector(struct irq_da
> if (vector && cpu_online(cpu) && cpumask_test_cpu(cpu, dest))
> return 0;
>
> +   /*
> +* Careful here. @apicd might either have move_in_progress set or
> +* be enqueued for cleanup. Assigning a new vector would either
> +* leave a stale vector on some CPU around or in case of a pending
> +* cleanup corrupt the hlist.
> +*/
> +   if (apicd->move_in_progress || !hlist_unhashed(>clist))
> +   return -EBUSY;
> +
> vector = irq_matrix_alloc(vector_matrix, dest, resvd, );
> if (vector > 0)
> apic_update_vector(irqd, vector, cpu);
>
>

Re: KASAN: use-after-free Read in do_general_protection

[Dmitry Vyukov]

On Mon, May 28, 2018 at 1:25 PM, Paolo Bonzini  wrote:
> On 26/05/2018 11:29, Dmitry Vyukov wrote:
>> KASAN: stack-out-of-bounds Read in do_general_protection
>> KASAN: slab-out-of-bounds Read in vmx_vcpu_run
>> KASAN: use-after-scope Read in vmx_vcpu_run
>> KASAN: stack-out-of-bounds Write in notify_die
>>
>> See full info at:
>> https://syzkaller.appspot.com/bug?extid=a1264132fc103340628f
>>
>>
>> There seems to be 2 problems:
>>
>> 1. msr_write_intercepted doing something notoriously bad.
>
> The faulting line is
>
> msr_bitmap = to_vmx(vcpu)->loaded_vmcs->msr_bitmap;
>
> so I suppose to_vmx(vcpu)->loaded_vmcs is bogus?  That seems like "just"
> a corruption of the struct kvm_vcpu, because the loaded_vmcs field is
> pointing elsewhere inside the same struct.

This is reproducible and the reproducer only uses KVM syscalls. So it
seems that KVM corrupts itself. Perhaps it's KVM_SET_MSRS that messes
things?

Re: [PATCH v6 2/8] x86/microcode/AMD: Add microcode container data checking functions

[Borislav Petkov]

On Sun, May 20, 2018 at 12:07:16AM +0200, Maciej S. Szmigiero wrote:
> Add verify_container(), verify_equivalence_table(), verify_patch_section()
> and verify_patch() functions to the AMD microcode update driver.
> 
> These functions check whether a passed buffer contains the relevant
> structure, whether it isn't truncated and (for actual microcode patches)
> whether the size of a patch is not too large for a particular CPU family.
> By adding these checks as separate functions the actual microcode loading
> code won't get interspersed with a lot of checks and so will be more
> readable.
> 
> Signed-off-by: Maciej S. Szmigiero 
> ---
>  arch/x86/kernel/cpu/microcode/amd.c | 148 +++-
>  1 file changed, 145 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/microcode/amd.c 
> b/arch/x86/kernel/cpu/microcode/amd.c
> index dc8ea9a9d962..f9485ff7183c 100644
> --- a/arch/x86/kernel/cpu/microcode/amd.c
> +++ b/arch/x86/kernel/cpu/microcode/amd.c
> @@ -73,6 +73,150 @@ static u16 find_equiv_id(struct equiv_cpu_entry 
> *equiv_table, u32 sig)
>   return 0;
>  }
>  
> +/*
> + * Checks whether there is a valid microcode container file at the beginning

"Check whether... " imperative tone. Ditto for the rest.

> + * of a passed buffer @buf of size @size.

@buf_size

Also, fix the other comments too.

> + * If @early is set this function does not print errors which makes it
> + * usable by the early microcode loader.
> + */
> +static bool verify_container(const u8 *buf, size_t buf_size, bool early)

...

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH v6 5/8] x86/microcode/AMD: Check microcode container data in the late loader

[Borislav Petkov]

On Sun, May 20, 2018 at 12:07:19AM +0200, Maciej S. Szmigiero wrote:
> Convert the late loader in the AMD microcode update driver to use newly
> introduced microcode container data checking functions as it was previously
> done for the early loader.
> 
> Signed-off-by: Maciej S. Szmigiero 
> ---
>  arch/x86/kernel/cpu/microcode/amd.c | 70 +
>  1 file changed, 32 insertions(+), 38 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/microcode/amd.c 
> b/arch/x86/kernel/cpu/microcode/amd.c
> index f8bd74341ed8..3e10a5920f58 100644
> --- a/arch/x86/kernel/cpu/microcode/amd.c
> +++ b/arch/x86/kernel/cpu/microcode/amd.c
> @@ -693,28 +693,26 @@ static enum ucode_state apply_microcode_amd(int cpu)
>   return UCODE_UPDATED;
>  }
>  
> -static int install_equiv_cpu_table(const u8 *buf)
> +static unsigned int install_equiv_cpu_table(const u8 *buf, size_t buf_size)
>  {
> - unsigned int *ibuf = (unsigned int *)buf;
> - unsigned int type = ibuf[1];
> - unsigned int size = ibuf[2];
> + const u32 *hdr;
> + u32 equiv_tbl_len;
>  
> - if (type != UCODE_EQUIV_CPU_TABLE_TYPE || !size) {
> - pr_err("empty section/"
> -"invalid type field in container file section header\n");
> - return -EINVAL;
> - }
> + if (!verify_equivalence_table(buf, buf_size, false))
> + return 0;
> +
> + hdr = (const u32 *)buf;
> + equiv_tbl_len = hdr[2];
>  
> - equiv_cpu_table = vmalloc(size);
> + equiv_cpu_table = vmalloc(equiv_tbl_len);
>   if (!equiv_cpu_table) {
>   pr_err("failed to allocate equivalent CPU table\n");
> - return -ENOMEM;
> + return 0;
>   }
>  
> - memcpy(equiv_cpu_table, buf + CONTAINER_HDR_SZ, size);
> + memcpy(equiv_cpu_table, buf + CONTAINER_HDR_SZ, equiv_tbl_len);
>  
> - /* add header length */
> - return size + CONTAINER_HDR_SZ;
> + return equiv_tbl_len;
>  }
>  
>  static void free_equiv_cpu_table(void)
> @@ -739,13 +737,19 @@ static void cleanup(void)
>  static int verify_and_add_patch(u8 family, u8 *fw, unsigned int leftover,
>   unsigned int *crnt_size)
>  {
> + u32 *hdr = (u32 *)fw;
>   struct microcode_header_amd *mc_hdr;
>   struct ucode_patch *patch;
> - unsigned int patch_size, ret;
> + u32 patch_size;
>   u32 proc_fam;
>   u16 proc_id;
>  
> - patch_size  = *(u32 *)(fw + 4);
> + if (!verify_patch_section(fw, leftover, false)) {
> + *crnt_size = leftover;

I'm not sure about this: we verify the patch section and in the error
case we skip over the whole leftover buffer?

Maybe skipping over SECTION_HDR_SIZE or better yet skip 1 byte here
too, like in parse_container() to give us the highest chance of finding
something sensible later...

> + return 0;
> + }
> +
> + patch_size  = hdr[1];

Same comment as before: verify_patch_size()

But I think you can simply do verify_patch() at the beginning of the
function and be done with the verification in that function.

>   *crnt_size  = patch_size + SECTION_HDR_SIZE;
>   mc_hdr  = (struct microcode_header_amd *)(fw + SECTION_HDR_SIZE);
>   proc_id = mc_hdr->processor_rev_id;
> @@ -767,16 +771,8 @@ static int verify_and_add_patch(u8 family, u8 *fw, 
> unsigned int leftover,
>   return 0;
>   }
>  
> - /*
> -  * The section header length is not included in this indicated size
> -  * but is present in the leftover file length so we need to subtract
> -  * it before passing this value to the function below.
> -  */
> - ret = verify_patch_size(family, patch_size, leftover - 
> SECTION_HDR_SIZE);
> - if (!ret) {
> - pr_err("Patch-ID 0x%08x: size mismatch.\n", mc_hdr->patch_id);
> + if (!verify_patch(family, fw, leftover, false))
>   return 0;
> - }
>  
>   patch = kzalloc(sizeof(*patch), GFP_KERNEL);
>   if (!patch) {
> @@ -810,21 +806,21 @@ static enum ucode_state __load_microcode_amd(u8 family, 
> const u8 *data,
>   enum ucode_state ret = UCODE_ERROR;
>   unsigned int leftover;
>   u8 *fw = (u8 *)data;
> - int offset;
> + unsigned int offset;
>  
> - offset = install_equiv_cpu_table(data);
> - if (offset < 0) {
> + offset = install_equiv_cpu_table(data, size);
> + if (!offset) {
>   pr_err("failed to create equivalent cpu table\n");

No need for that error message anymore I guess -
install_equiv_cpu_table() and verify_equivalence_table() are pretty
vocal in the error case already.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [PATCH v6 3/8] x86/microcode/AMD: Check microcode container data in the early loader

[Borislav Petkov]

On Sun, May 20, 2018 at 12:07:17AM +0200, Maciej S. Szmigiero wrote:
> Convert the early loader in the AMD microcode update driver to use the
> container data checking functions introduced by the previous commit.
> 
> We have to be careful to call these functions with 'early' parameter set,
> so they won't try to print errors as the early loader runs too early for
> printk()-style functions to work.
> 
> Signed-off-by: Maciej S. Szmigiero 
> ---
>  arch/x86/kernel/cpu/microcode/amd.c | 59 -
>  1 file changed, 33 insertions(+), 26 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/microcode/amd.c 
> b/arch/x86/kernel/cpu/microcode/amd.c
> index f9485ff7183c..f4c7479a961c 100644
> --- a/arch/x86/kernel/cpu/microcode/amd.c
> +++ b/arch/x86/kernel/cpu/microcode/amd.c
> @@ -224,29 +224,36 @@ static bool verify_patch(u8 family, const u8 *buf, 
> size_t buf_size, bool early)
>   * Returns the amount of bytes consumed while scanning. @desc contains all 
> the
>   * data we're going to use in later stages of the application.
>   */
> -static ssize_t parse_container(u8 *ucode, ssize_t size, struct cont_desc 
> *desc)
> +static size_t parse_container(u8 *ucode, size_t size, struct cont_desc *desc)
>  {
>   struct equiv_cpu_entry *eq;
> - ssize_t orig_size = size;
> + size_t orig_size = size;
>   u32 *hdr = (u32 *)ucode;
> + u32 equiv_tbl_len;
>   u16 eq_id;
>   u8 *buf;
>  
> - /* Am I looking at an equivalence table header? */
> - if (hdr[0] != UCODE_MAGIC ||
> - hdr[1] != UCODE_EQUIV_CPU_TABLE_TYPE ||
> - hdr[2] == 0)
> - return CONTAINER_HDR_SZ;
> + /*
> +  * Skip one byte when a container cannot be parsed successfully
> +  * so the parser will correctly skip unknown data of any size until
> +  * it hopefully arrives at something that it is able to recognize.
> +  */
> + if (!verify_container(ucode, size, true) ||
> + !verify_equivalence_table(ucode, size, true))

That function already calls verify_container().

> + return 1;
>  
>   buf = ucode;
>  
> + equiv_tbl_len = hdr[2];
>   eq = (struct equiv_cpu_entry *)(buf + CONTAINER_HDR_SZ);
>  
>   /* Find the equivalence ID of our CPU in this table: */
>   eq_id = find_equiv_id(eq, desc->cpuid_1_eax);
>  
> - buf  += hdr[2] + CONTAINER_HDR_SZ;
> - size -= hdr[2] + CONTAINER_HDR_SZ;
> + buf  += CONTAINER_HDR_SZ;
> + buf  += equiv_tbl_len;
> + size -= CONTAINER_HDR_SZ;
> + size -= equiv_tbl_len;
>  
>   /*
>* Scan through the rest of the container to find where it ends. We do
> @@ -258,25 +265,27 @@ static ssize_t parse_container(u8 *ucode, ssize_t size, 
> struct cont_desc *desc)
>  
>   hdr = (u32 *)buf;
>  
> - if (hdr[0] != UCODE_UCODE_TYPE)
> + if (!verify_patch_section(buf, size, true))
>   break;
>  
> - /* Sanity-check patch size. */
>   patch_size = hdr[1];
> - if (patch_size > PATCH_MAX_SIZE)
> - break;
>  
> - /* Skip patch section header: */
> - buf  += SECTION_HDR_SIZE;
> - size -= SECTION_HDR_SIZE;
> + mc = (struct microcode_amd *)(buf + SECTION_HDR_SIZE);
> + if (eq_id != mc->hdr.processor_rev_id)
> + goto next_patch;
>  
> - mc = (struct microcode_amd *)buf;
> - if (eq_id == mc->hdr.processor_rev_id) {
> - desc->psize = patch_size;
> - desc->mc = mc;
> - }
> + if (!verify_patch(x86_family(desc->cpuid_1_eax), buf, size,
> +   true))

Let it stick out.

Ok, so above you do verify_patch_section() and then you take patch_size
without fully verifying it - it can be something non-sensically huge and
thus we might skip over good patches.

What you should do instead is call verify_patch() directly - which
already calls verify_patch_section() and if the patch size exceeds the
per-family maximum, return *that* instead and skip only the per family
maximum inside the buffer so that any patches following can get a chance
to get inspected.

For that you'll have to reshuffle the change of integrating
verify_patch_size() to happen before that change here.

Thx.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.