[PATCH v9 03/27] dt-bindings: Add doc for the Ingenic TCU drivers

[Paul Cercueil]

Add documentation about how to properly use the Ingenic TCU
(Timer/Counter Unit) drivers from devicetree.

Signed-off-by: Paul Cercueil 
---

Notes:
 v4: New patch in this series. Corresponds to V2 patches 3-4-5 with
 added content.

 v5: - Edited PWM/watchdog DT bindings documentation to point to the new
   document.
 - Moved main document to
   Documentation/devicetree/bindings/timer/ingenic,tcu.txt
 - Updated documentation to reflect the new devicetree bindings.

 v6: - Removed PWM/watchdog documentation files as asked by upstream
 - Removed doc about properties that should be implicit
 - Removed doc about ingenic,timer-channel /
   ingenic,clocksource-channel as they are gone
 - Fix WDT clock name in the binding doc
 - Fix lengths of register areas in watchdog/pwm nodes

 v7: No change

 v8: - Fix address of the PWM node
 - Added doc about system timer and clocksource children nodes

 v9: - Remove doc about system timer and clocksource children
   nodes...
 - Add doc about ingenic,pwm-channels-mask property

 .../devicetree/bindings/pwm/ingenic,jz47xx-pwm.txt |  25 
 .../devicetree/bindings/timer/ingenic,tcu.txt  | 139 +
 .../bindings/watchdog/ingenic,jz4740-wdt.txt   |  17 ---
 3 files changed, 139 insertions(+), 42 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/pwm/ingenic,jz47xx-pwm.txt
 create mode 100644 Documentation/devicetree/bindings/timer/ingenic,tcu.txt
 delete mode 100644 
Documentation/devicetree/bindings/watchdog/ingenic,jz4740-wdt.txt

diff --git a/Documentation/devicetree/bindings/pwm/ingenic,jz47xx-pwm.txt 
b/Documentation/devicetree/bindings/pwm/ingenic,jz47xx-pwm.txt
deleted file mode 100644
index 7d9d3f90641b..
--- a/Documentation/devicetree/bindings/pwm/ingenic,jz47xx-pwm.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Ingenic JZ47xx PWM Controller
-=
-
-Required properties:
-- compatible: One of:
-  * "ingenic,jz4740-pwm"
-  * "ingenic,jz4770-pwm"
-  * "ingenic,jz4780-pwm"
-- #pwm-cells: Should be 3. See pwm.txt in this directory for a description
-  of the cells format.
-- clocks : phandle to the external clock.
-- clock-names : Should be "ext".
-
-
-Example:
-
-   pwm: pwm@10002000 {
-   compatible = "ingenic,jz4740-pwm";
-   reg = <0x10002000 0x1000>;
-
-   #pwm-cells = <3>;
-
-   clocks = <>;
-   clock-names = "ext";
-   };
diff --git a/Documentation/devicetree/bindings/timer/ingenic,tcu.txt 
b/Documentation/devicetree/bindings/timer/ingenic,tcu.txt
new file mode 100644
index ..ec9639700115
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/ingenic,tcu.txt
@@ -0,0 +1,139 @@
+Ingenic JZ47xx SoCs Timer/Counter Unit devicetree bindings
+==
+
+For a description of the TCU hardware and drivers, have a look at
+Documentation/mips/ingenic-tcu.txt.
+
+Required properties:
+
+- compatible: Must be one of:
+  * ingenic,jz4740-tcu
+  * ingenic,jz4725b-tcu
+  * ingenic,jz4770-tcu
+- reg: Should be the offset/length value corresponding to the TCU registers
+- clocks: List of phandle & clock specifiers for clocks external to the TCU.
+  The "pclk", "rtc", "ext" and "tcu" clocks should be provided.
+- clock-names: List of name strings for the external clocks.
+- #clock-cells: Should be <1>;
+  Clock consumers specify this argument to identify a clock. The valid values
+  may be found in .
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+  interrupt source. The value should be 1.
+- interrupt-parent : phandle of the interrupt controller.
+- interrupts : Specifies the interrupt the controller is connected to.
+
+Optional properties:
+
+- ingenic,pwm-channels-mask: Bitmask of TCU channels reserved for PWM use.
+  Default value is 0xfe or 0xfc if the SoC does not have the OS Timer.
+
+
+Children nodes
+==
+
+
+PWM node:
+-
+
+Required properties:
+
+- compatible: Must be one of:
+  * ingenic,jz4740-pwm
+  * ingenic,jz4725b-pwm
+- #pwm-cells: Should be 3. See ../pwm/pwm.txt for a description of the cell
+  format.
+- clocks: List of phandle & clock specifiers for the TCU clocks.
+- clock-names: List of name strings for the TCU clocks.
+
+
+Watchdog node:
+--
+
+Required properties:
+
+- compatible: Must be one of:
+  * ingenic,jz4740-watchdog
+  * ingenic,jz4780-watchdog
+- clocks: phandle to the WDT clock
+- clock-names: should be "wdt"
+
+
+OS Timer node:
+-
+
+Required properties:
+
+- compatible: Must be one of:
+  * ingenic,jz4725b-ost
+  * ingenic,jz4770-ost
+- clocks: phandle to the OST clock
+- clock-names: should be "ost"
+- interrupts : Specifies the 

[PATCH v9 06/27] MAINTAINERS: Add myself as maintainer for Ingenic TCU drivers

[Paul Cercueil]

Add myself as maintainer for the ingenic-timer and ingenic-ost drivers.

Signed-off-by: Paul Cercueil 
---

Notes:
 v2: No change

 v3: No change

 v4: No change

 v5: Update with new files

 v6: No change

 v7: No change

 v8: No change

 v9: No change

 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f3a5c97e3419..da08c2b9f261 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7401,6 +7401,15 @@ L:   linux-...@lists.infradead.org
 S: Maintained
 F: drivers/mtd/nand/raw/jz4780_*
 
+INGENIC TCU driver
+M: Paul Cercueil 
+S: Maintained
+F: drivers/clocksource/ingenic-ost.c
+F: drivers/clocksource/ingenic-timer.c
+F: drivers/clocksource/ingenic-timer.h
+F: include/linux/mfd/ingenic-tcu.h
+F: include/dt-bindings/clock/ingenic,tcu.h
+
 INOTIFY
 M: Jan Kara 
 R: Amir Goldstein 
-- 
2.11.0

[PATCH v9 09/27] watchdog: jz4740: Avoid starting watchdog in set_timeout

[Paul Cercueil]

Previously the jz4740_wdt_set_timeout() function was starting the timer
unconditionally, even if it was stopped when that function was entered.

Now, the timer will be restarted only if it was already running before
this function is called.

Signed-off-by: Paul Cercueil 
Reviewed-by: Guenter Roeck 
---

Notes:
 v6: New patch

 v7: No change

 v8: No change

 v9: No change

 drivers/watchdog/jz4740_wdt.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/watchdog/jz4740_wdt.c b/drivers/watchdog/jz4740_wdt.c
index 0f54306aee25..45d9495170e5 100644
--- a/drivers/watchdog/jz4740_wdt.c
+++ b/drivers/watchdog/jz4740_wdt.c
@@ -64,13 +64,15 @@ static int jz4740_wdt_set_timeout(struct watchdog_device 
*wdt_dev,
 {
struct jz4740_wdt_drvdata *drvdata = watchdog_get_drvdata(wdt_dev);
u16 timeout_value = (u16)(drvdata->clk_rate * new_timeout);
+   u32 tcer;
 
+   regmap_read(drvdata->map, TCU_REG_WDT_TCER, );
regmap_write(drvdata->map, TCU_REG_WDT_TCER, 0);
 
regmap_write(drvdata->map, TCU_REG_WDT_TDR, timeout_value);
regmap_write(drvdata->map, TCU_REG_WDT_TCNT, 0);
 
-   regmap_write(drvdata->map, TCU_REG_WDT_TCER, TCU_WDT_TCER_TCEN);
+   regmap_write(drvdata->map, TCU_REG_WDT_TCER, tcer & TCU_WDT_TCER_TCEN);
 
wdt_dev->timeout = new_timeout;
return 0;
@@ -86,6 +88,7 @@ static int jz4740_wdt_start(struct watchdog_device *wdt_dev)
return ret;
 
jz4740_wdt_set_timeout(wdt_dev, wdt_dev->timeout);
+   regmap_write(drvdata->map, TCU_REG_WDT_TCER, TCU_WDT_TCER_TCEN);
 
return 0;
 }
-- 
2.11.0

[PATCH v9 05/27] clocksource: Add driver for the Ingenic JZ47xx OST

[Paul Cercueil]

From: Maarten ter Huurne 

OST is the OS Timer, a 64-bit timer/counter with buffered reading.

SoCs before the JZ4770 had (if any) a 32-bit OST; the JZ4770 and
JZ4780 have a 64-bit OST.

This driver will register both a clocksource and a sched_clock to the
system.

Signed-off-by: Maarten ter Huurne 
Signed-off-by: Paul Cercueil 
---

Notes:
 v5: New patch

 v6: - Get rid of SoC IDs; pass pointer to ingenic_ost_soc_info as
   devicetree match data instead.
 - Use device_get_match_data() instead of the of_* variant
 - Handle error of dev_get_regmap() properly

 v7: Fix section mismatch by using builtin_platform_driver_probe()

 v8: builtin_platform_driver_probe() does not work anymore in
 4.20-rc6? The probe function won't be called. Work around this
 for now by using late_initcall.

 v9: No change

 drivers/clocksource/Kconfig   |   8 ++
 drivers/clocksource/Makefile  |   1 +
 drivers/clocksource/ingenic-ost.c | 215 ++
 3 files changed, 224 insertions(+)
 create mode 100644 drivers/clocksource/ingenic-ost.c

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 4e69af15c3e7..e0646878b0de 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -648,4 +648,12 @@ config INGENIC_TIMER
help
  Support for the timer/counter unit of the Ingenic JZ SoCs.
 
+config INGENIC_OST
+   bool "Ingenic JZ47xx Operating System Timer"
+   depends on MIPS || COMPILE_TEST
+   depends on COMMON_CLK
+   select INGENIC_TIMER
+   help
+ Support for the OS Timer of the Ingenic JZ4770 or similar SoC.
+
 endmenu
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 7c8f790dcf67..7faa8108574a 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -75,6 +75,7 @@ obj-$(CONFIG_ASM9260_TIMER)   += asm9260_timer.o
 obj-$(CONFIG_H8300_TMR8)   += h8300_timer8.o
 obj-$(CONFIG_H8300_TMR16)  += h8300_timer16.o
 obj-$(CONFIG_H8300_TPU)+= h8300_tpu.o
+obj-$(CONFIG_INGENIC_OST)  += ingenic-ost.o
 obj-$(CONFIG_INGENIC_TIMER)+= ingenic-timer.o
 obj-$(CONFIG_CLKSRC_ST_LPC)+= clksrc_st_lpc.o
 obj-$(CONFIG_X86_NUMACHIP) += numachip.o
diff --git a/drivers/clocksource/ingenic-ost.c 
b/drivers/clocksource/ingenic-ost.c
new file mode 100644
index ..cc0fee3efd29
--- /dev/null
+++ b/drivers/clocksource/ingenic-ost.c
@@ -0,0 +1,215 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * JZ47xx SoCs TCU Operating System Timer driver
+ *
+ * Copyright (C) 2016 Maarten ter Huurne 
+ * Copyright (C) 2018 Paul Cercueil 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ingenic-timer.h"
+
+#define TCU_OST_TCSR_MASK  0xc0
+#define TCU_OST_TCSR_CNT_MDBIT(15)
+
+#define TCU_OST_CHANNEL15
+
+struct ingenic_ost_soc_info {
+   bool is64bit;
+};
+
+struct ingenic_ost {
+   struct regmap *map;
+   struct clk *clk;
+
+   struct clocksource cs;
+};
+
+static u64 notrace ingenic_ost_read_cntl(void)
+{
+   /* Bypass the regmap here as we must return as soon as possible */
+   return readl(ingenic_tcu_base + TCU_REG_OST_CNTL);
+}
+
+static u64 notrace ingenic_ost_read_cnth(void)
+{
+   /* Bypass the regmap here as we must return as soon as possible */
+   return readl(ingenic_tcu_base + TCU_REG_OST_CNTH);
+}
+
+static u64 notrace ingenic_ost_clocksource_read(struct clocksource *cs)
+{
+   u32 val1, val2;
+   u64 count, recount;
+   s64 diff;
+
+   /*
+* The buffering of the upper 32 bits of the timer prevents wrong
+* results from the bottom 32 bits overflowing due to the timer ticking
+* along. However, it does not prevent wrong results from simultaneous
+* reads of the timer, which could reset the buffer mid-read.
+* Since this kind of wrong read can happen only when the bottom bits
+* overflow, there will be minutes between wrong reads, so if we read
+* twice in succession, at least one of the reads will be correct.
+*/
+
+   /* Bypass the regmap here as we must return as soon as possible */
+   val1 = readl(ingenic_tcu_base + TCU_REG_OST_CNTL);
+   val2 = readl(ingenic_tcu_base + TCU_REG_OST_CNTHBUF);
+   count = (u64)val1 | (u64)val2 << 32;
+
+   val1 = readl(ingenic_tcu_base + TCU_REG_OST_CNTL);
+   val2 = readl(ingenic_tcu_base + TCU_REG_OST_CNTHBUF);
+   recount = (u64)val1 | (u64)val2 << 32;
+
+   /*
+* A wrong read will produce a result that is 1<<32 too high: the bottom
+* part from before overflow and the upper part from after overflow.
+* Therefore, the lower value of the two reads is the correct value.
+*/
+
+   diff = (s64)(recount - count);
+   if 

[PATCH v9 11/27] pwm: jz4740: Apply configuration atomically

[Paul Cercueil]

This is cleaner, more future-proof, and incidentally it also fixes the
PWM resetting its config when stopped/started several times.

Signed-off-by: Paul Cercueil 
---

Notes:
 v9: New patch

 drivers/pwm/pwm-jz4740.c | 37 -
 1 file changed, 12 insertions(+), 25 deletions(-)

diff --git a/drivers/pwm/pwm-jz4740.c b/drivers/pwm/pwm-jz4740.c
index a7b134af5e04..b2f910413f81 100644
--- a/drivers/pwm/pwm-jz4740.c
+++ b/drivers/pwm/pwm-jz4740.c
@@ -83,17 +83,16 @@ static void jz4740_pwm_disable(struct pwm_chip *chip, 
struct pwm_device *pwm)
jz4740_timer_disable(pwm->hwpwm);
 }
 
-static int jz4740_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
-int duty_ns, int period_ns)
+static int jz4740_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+   struct pwm_state *state)
 {
struct jz4740_pwm_chip *jz4740 = to_jz4740(pwm->chip);
unsigned long long tmp;
unsigned long period, duty;
unsigned int prescaler = 0;
uint16_t ctrl;
-   bool is_enabled;
 
-   tmp = (unsigned long long)clk_get_rate(jz4740->clk) * period_ns;
+   tmp = (unsigned long long)clk_get_rate(jz4740->clk) * state->period;
do_div(tmp, 10);
period = tmp;
 
@@ -105,16 +104,14 @@ static int jz4740_pwm_config(struct pwm_chip *chip, 
struct pwm_device *pwm,
if (prescaler == 6)
return -EINVAL;
 
-   tmp = (unsigned long long)period * duty_ns;
-   do_div(tmp, period_ns);
+   tmp = (unsigned long long)period * state->duty_cycle;
+   do_div(tmp, state->period);
duty = period - tmp;
 
if (duty >= period)
duty = period - 1;
 
-   is_enabled = jz4740_timer_is_enabled(pwm->hwpwm);
-   if (is_enabled)
-   jz4740_pwm_disable(chip, pwm);
+   jz4740_pwm_disable(chip, pwm);
 
jz4740_timer_set_count(pwm->hwpwm, 0);
jz4740_timer_set_duty(pwm->hwpwm, duty);
@@ -125,18 +122,7 @@ static int jz4740_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
 
jz4740_timer_set_ctrl(pwm->hwpwm, ctrl);
 
-   if (is_enabled)
-   jz4740_pwm_enable(chip, pwm);
-
-   return 0;
-}
-
-static int jz4740_pwm_set_polarity(struct pwm_chip *chip,
-   struct pwm_device *pwm, enum pwm_polarity polarity)
-{
-   uint32_t ctrl = jz4740_timer_get_ctrl(pwm->pwm);
-
-   switch (polarity) {
+   switch (state->polarity) {
case PWM_POLARITY_NORMAL:
ctrl &= ~JZ_TIMER_CTRL_PWM_ACTIVE_LOW;
break;
@@ -146,16 +132,17 @@ static int jz4740_pwm_set_polarity(struct pwm_chip *chip,
}
 
jz4740_timer_set_ctrl(pwm->hwpwm, ctrl);
+
+   if (state->enabled)
+   jz4740_pwm_enable(chip, pwm);
+
return 0;
 }
 
 static const struct pwm_ops jz4740_pwm_ops = {
.request = jz4740_pwm_request,
.free = jz4740_pwm_free,
-   .config = jz4740_pwm_config,
-   .set_polarity = jz4740_pwm_set_polarity,
-   .enable = jz4740_pwm_enable,
-   .disable = jz4740_pwm_disable,
+   .apply = jz4740_pwm_apply,
.owner = THIS_MODULE,
 };
 
-- 
2.11.0

[PATCH v9 08/27] watchdog: jz4740: Use regmap provided by TCU driver

[Paul Cercueil]

Since we broke the ABI by changing the clock, the driver was also
updated to use the regmap provided by the TCU driver.

Signed-off-by: Paul Cercueil 
Reviewed-by: Guenter Roeck 
---

Notes:
 v6: New patch

 v7: No change

 v8: No change

 v9: No change

 drivers/watchdog/jz4740_wdt.c | 30 ++
 1 file changed, 14 insertions(+), 16 deletions(-)

diff --git a/drivers/watchdog/jz4740_wdt.c b/drivers/watchdog/jz4740_wdt.c
index 1d504ecf45e1..0f54306aee25 100644
--- a/drivers/watchdog/jz4740_wdt.c
+++ b/drivers/watchdog/jz4740_wdt.c
@@ -13,6 +13,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -25,10 +26,7 @@
 #include 
 #include 
 #include 
-
-#define JZ_REG_WDT_TIMER_DATA 0x0
-#define JZ_REG_WDT_COUNTER_ENABLE 0x4
-#define JZ_REG_WDT_TIMER_COUNTER  0x8
+#include 
 
 #define DEFAULT_HEARTBEAT 5
 #define MAX_HEARTBEAT 2048
@@ -48,7 +46,7 @@ MODULE_PARM_DESC(heartbeat,
 
 struct jz4740_wdt_drvdata {
struct watchdog_device wdt;
-   void __iomem *base;
+   struct regmap *map;
struct clk *clk;
unsigned long clk_rate;
 };
@@ -57,7 +55,7 @@ static int jz4740_wdt_ping(struct watchdog_device *wdt_dev)
 {
struct jz4740_wdt_drvdata *drvdata = watchdog_get_drvdata(wdt_dev);
 
-   writew(0x0, drvdata->base + JZ_REG_WDT_TIMER_COUNTER);
+   regmap_write(drvdata->map, TCU_REG_WDT_TCNT, 0);
return 0;
 }
 
@@ -67,12 +65,12 @@ static int jz4740_wdt_set_timeout(struct watchdog_device 
*wdt_dev,
struct jz4740_wdt_drvdata *drvdata = watchdog_get_drvdata(wdt_dev);
u16 timeout_value = (u16)(drvdata->clk_rate * new_timeout);
 
-   writeb(0x0, drvdata->base + JZ_REG_WDT_COUNTER_ENABLE);
+   regmap_write(drvdata->map, TCU_REG_WDT_TCER, 0);
 
-   writew((u16)timeout_value, drvdata->base + JZ_REG_WDT_TIMER_DATA);
-   writew(0x0, drvdata->base + JZ_REG_WDT_TIMER_COUNTER);
+   regmap_write(drvdata->map, TCU_REG_WDT_TDR, timeout_value);
+   regmap_write(drvdata->map, TCU_REG_WDT_TCNT, 0);
 
-   writeb(0x1, drvdata->base + JZ_REG_WDT_COUNTER_ENABLE);
+   regmap_write(drvdata->map, TCU_REG_WDT_TCER, TCU_WDT_TCER_TCEN);
 
wdt_dev->timeout = new_timeout;
return 0;
@@ -96,7 +94,7 @@ static int jz4740_wdt_stop(struct watchdog_device *wdt_dev)
 {
struct jz4740_wdt_drvdata *drvdata = watchdog_get_drvdata(wdt_dev);
 
-   writeb(0x0, drvdata->base + JZ_REG_WDT_COUNTER_ENABLE);
+   regmap_write(drvdata->map, TCU_REG_WDT_TCER, 0);
clk_disable_unprepare(drvdata->clk);
 
return 0;
@@ -138,7 +136,6 @@ static int jz4740_wdt_probe(struct platform_device *pdev)
struct device *dev = >dev;
struct jz4740_wdt_drvdata *drvdata;
struct watchdog_device *jz4740_wdt;
-   struct resource *res;
long rate;
int ret;
 
@@ -174,10 +171,11 @@ static int jz4740_wdt_probe(struct platform_device *pdev)
watchdog_set_nowayout(jz4740_wdt, nowayout);
watchdog_set_drvdata(jz4740_wdt, drvdata);
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   drvdata->base = devm_ioremap_resource(>dev, res);
-   if (IS_ERR(drvdata->base))
-   return PTR_ERR(drvdata->base);
+   drvdata->map = dev_get_regmap(dev->parent, NULL);
+   if (!drvdata->map) {
+   dev_err(dev, "regmap not found\n");
+   return -EINVAL;
+   }
 
ret = devm_watchdog_register_device(>dev, >wdt);
if (ret < 0)
-- 
2.11.0

[PATCH v9 14/27] pwm: jz4740: Improve algorithm of clock calculation

[Paul Cercueil]

The previous algorithm hardcoded details about how the TCU clocks work.
The new algorithm will use clk_round_rate to find the perfect clock rate
for the PWM channel.

Signed-off-by: Paul Cercueil 
---

Notes:
 v9: New patch

 drivers/pwm/pwm-jz4740.c | 26 +++---
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/drivers/pwm/pwm-jz4740.c b/drivers/pwm/pwm-jz4740.c
index c6136bd4434b..dd80a2cf6528 100644
--- a/drivers/pwm/pwm-jz4740.c
+++ b/drivers/pwm/pwm-jz4740.c
@@ -110,23 +110,27 @@ static int jz4740_pwm_apply(struct pwm_chip *chip, struct 
pwm_device *pwm,
struct jz4740_pwm_chip *jz4740 = to_jz4740(pwm->chip);
struct clk *clk = jz4740->clks[pwm->hwpwm],
   *parent_clk = clk_get_parent(clk);
-   unsigned long rate, period, duty;
+   unsigned long rate, new_rate, period, duty;
unsigned long long tmp;
-   unsigned int prescaler = 0;
 
rate = clk_get_rate(parent_clk);
-   tmp = (unsigned long long)rate * state->period;
-   do_div(tmp, 10);
-   period = tmp;
 
-   while (period > 0x && prescaler < 6) {
-   period >>= 2;
-   rate >>= 2;
-   ++prescaler;
+   for (;;) {
+   tmp = (unsigned long long)rate * state->period;
+   do_div(tmp, 10);
+
+   if (tmp <= 0x)
+   break;
+
+   new_rate = clk_round_rate(clk, rate - 1);
+
+   if (new_rate < rate)
+   rate = new_rate;
+   else
+   return -EINVAL;
}
 
-   if (prescaler == 6)
-   return -EINVAL;
+   period = tmp;
 
tmp = (unsigned long long)period * state->duty_cycle;
do_div(tmp, state->period);
-- 
2.11.0

[PATCH v9 17/27] pwm: jz4740: Remove unused devicetree compatible strings

[Paul Cercueil]

Right now none of the Ingenic-based boards probe this driver from
devicetree. This driver defined three compatible strings for the exact
same behaviour. Before these strings are used, we can remove two of
them.

Signed-off-by: Paul Cercueil 
Acked-by: Thierry Reding 
---

Notes:
 v5: New patch

 v6: No change

 v7: No change

 v8: No change

 v9: No change

 drivers/pwm/pwm-jz4740.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/pwm/pwm-jz4740.c b/drivers/pwm/pwm-jz4740.c
index b6e105e774bd..3171ada8c212 100644
--- a/drivers/pwm/pwm-jz4740.c
+++ b/drivers/pwm/pwm-jz4740.c
@@ -215,8 +215,6 @@ static int jz4740_pwm_remove(struct platform_device *pdev)
 #ifdef CONFIG_OF
 static const struct of_device_id jz4740_pwm_dt_ids[] = {
{ .compatible = "ingenic,jz4740-pwm", },
-   { .compatible = "ingenic,jz4770-pwm", },
-   { .compatible = "ingenic,jz4780-pwm", },
{},
 };
 MODULE_DEVICE_TABLE(of, jz4740_pwm_dt_ids);
-- 
2.11.0

Re: [PATCH] sched: fix infinity loop in update_blocked_averages

[Linus Torvalds]

On Thu, Dec 27, 2018 at 9:02 AM Vincent Guittot
 wrote:
>
> In the original behavior, the cs_rq was removed from the list only
> when the cgroup was removed.
> patch a9e7f6544b9c (sched/fair: Fix O(nr_cgroups) in load balance
> path) has added an optimization which remove the cfs_rq when there
> were no blocked load to update in order to optimize the loop but it
> has introduced a race condition that create this infinite loop. The
> patch fixes the problem by removing the optimization.
> I will look at re-adding the optimization once i will have afix for
> the race condition

Hmm. What's the race? We seem to take the rq lock for all the cases,
but maybe I'm missing something?

That commit a9e7f6544b9c is a year and a half old, why did this start
being reported now?

[ goes off and looks ]

Oh. unthrottle_cfs_rq -> enqueue_entity -> list_add_leaf_cfs_rq()
doesn't actually seem to hold the rq lock at all. It's just called
under a rcu read lock.

So it all seems to depend on that "on_list" flag for exclusion. Which
seems fundamentally racy, since it's not protected by a lock.

So yeah, the whole logic seems to depend on "on_list is sticky and
stays set until the whole task group is destroyed".

So commit a9e7f6544b9c ("sched/fair: Fix O(nr_cgroups) in load balance
path") would appear to be entirely wrong, because on_list isn't
actually protected by a lock, and that can confuse things.

But that still makes me go "how come is this only noticed 18 months
after the fact"?

So I'm probably still missing something.

Tejun? PeterZ? Tell my why I'm being dense.

   Linus

[PATCH v9 10/27] watchdog: jz4740: Drop dependency on MACH_JZ47xx, use COMPILE_TEST

[Paul Cercueil]

Depending on MACH_JZ47xx prevent us from creating a generic kernel that
works on more than one MIPS board. Instead, we just depend on MIPS being
set.

On other architectures, this driver can still be built, thanks to
COMPILE_TEST. This is used by automated tools to find bugs, for
instance.

Signed-off-by: Paul Cercueil 
Reviewed-by: Guenter Roeck 
---

Notes:
 v5: New patch

 v6: No change

 v7: No change

 v8: No change

 v9: No change

 drivers/watchdog/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index cfd7368fc3c0..eb5dbb1db64d 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1496,7 +1496,7 @@ config INDYDOG
 
 config JZ4740_WDT
tristate "Ingenic jz4740 SoC hardware watchdog"
-   depends on MACH_JZ4740 || MACH_JZ4780
+   depends on MIPS || COMPILE_TEST
depends on COMMON_CLK
select WATCHDOG_CORE
select INGENIC_TIMER
-- 
2.11.0

Re: [PATCH] i2c: bcm2835: Clear current message and count after a transaction

[Eric Anholt]

Stefan Wahren  writes:

> Hi Paul,
>
>> Paul Kocialkowski  hat am 24. Dezember 2018 
>> um 10:10 geschrieben:
>> 
>> 
>> Hi,
>> 
>> On Sat, 2018-12-22 at 13:19 +0100, Stefan Wahren wrote:
>> > Hi Paul,
>> > 
>> > > Paul Kocialkowski  hat am 21. Dezember 
>> > > 2018 um 13:11 geschrieben:
>> > > 
>> > > 
>> > > The driver's interrupt handler checks whether a message is currently
>> > > being handled with the curr_msg pointer. When it is NULL, the interrupt
>> > > is considered to be unexpected. Similarly, the i2c_start_transfer
>> > > routine checks for the remaining number of messages to handle in
>> > > num_msgs.
>> > > 
>> > > However, these values are never cleared and always keep the message and
>> > > number relevant to the latest transfer (which might be done already and
>> > > the underlying message memory might have been freed).
>> > > 
>> > > When an unexpected interrupt hits with the DONE bit set, the isr will
>> > > then try to access the flags field of the curr_msg structure, leading
>> > > to a fatal page fault.
>> > > 
>> > > Fix the issue by systematically clearing curr_msg and num_msgs in the
>> > > driver-wide device structure when a transfer is considered complete.
>> > > 
>> > > Signed-off-by: Paul Kocialkowski 
>> > > ---
>> > >  drivers/i2c/busses/i2c-bcm2835.c | 3 +++
>> > >  1 file changed, 3 insertions(+)
>> > > 
>> > > diff --git a/drivers/i2c/busses/i2c-bcm2835.c 
>> > > b/drivers/i2c/busses/i2c-bcm2835.c
>> > > index 44deae78913e..5486252f5f2f 100644
>> > > --- a/drivers/i2c/busses/i2c-bcm2835.c
>> > > +++ b/drivers/i2c/busses/i2c-bcm2835.c
>> > > @@ -298,6 +298,9 @@ static int bcm2835_i2c_xfer(struct i2c_adapter 
>> > > *adap, struct i2c_msg msgs[],
>> > >  return -ETIMEDOUT;
>> > >  }
>> > >  
>> > > +i2c_dev->curr_msg = NULL;
>> > > +i2c_dev->num_msgs = 0;
>> > 
>> > AFAIU this would reduce the chance of a use-after-free dramatically but 
>> > not completely.
>> 
>> Do you have a specific case of use-after-free related to these
>> variables in mind that this cleanup would not fix (except for the
>> timeout case)?
>
> okay i was wrong about the use-after-free. But i'm not sure about this 
> scenario on the I2C bus shared with the VC4:
>
> 1. ARM core starts I2C transfer (bcm2835_i2c_start_transfer)
> 2. VC4 triggers a BCM2835_I2C_S_DONE interrupt
> 3. ARM core catches this interrupt before the VC4

We don't share I2C buses with VC4, though, right?  That would just be
totally broken.


signature.asc
Description: PGP signature

[PATCH v9 12/27] pwm: jz4740: Use regmap from TCU driver

[Paul Cercueil]

The ingenic-timer "TCU" driver provides us with a regmap, that we can
use to safely access the TCU registers.

While this driver is devicetree-compatible, it is never (as of now)
probed from devicetree, so this change does not introduce a ABI problem
with current devicetree files.

Signed-off-by: Paul Cercueil 
---

Notes:
 v9: New patch

 drivers/pwm/Kconfig  |  1 +
 drivers/pwm/pwm-jz4740.c | 74 +++-
 2 files changed, 49 insertions(+), 26 deletions(-)

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 27e5dd47a01f..4ed003bc3d8d 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -202,6 +202,7 @@ config PWM_IMX
 config PWM_JZ4740
tristate "Ingenic JZ47xx PWM support"
depends on MACH_INGENIC
+   select REGMAP
help
  Generic PWM framework driver for Ingenic JZ47xx based
  machines.
diff --git a/drivers/pwm/pwm-jz4740.c b/drivers/pwm/pwm-jz4740.c
index b2f910413f81..8dfac5ffd71c 100644
--- a/drivers/pwm/pwm-jz4740.c
+++ b/drivers/pwm/pwm-jz4740.c
@@ -17,18 +17,19 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
-
-#include 
+#include 
 
 #define NUM_PWM 8
 
 struct jz4740_pwm_chip {
struct pwm_chip chip;
struct clk *clk;
+   struct regmap *map;
 };
 
 static inline struct jz4740_pwm_chip *to_jz4740(struct pwm_chip *chip)
@@ -38,6 +39,8 @@ static inline struct jz4740_pwm_chip *to_jz4740(struct 
pwm_chip *chip)
 
 static int jz4740_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
 {
+   struct jz4740_pwm_chip *jz = to_jz4740(chip);
+
/*
 * Timers 0 and 1 are used for system tasks, so they are unavailable
 * for use as PWMs.
@@ -45,42 +48,44 @@ static int jz4740_pwm_request(struct pwm_chip *chip, struct 
pwm_device *pwm)
if (pwm->hwpwm < 2)
return -EBUSY;
 
-   jz4740_timer_start(pwm->hwpwm);
+   regmap_write(jz->map, TCU_REG_TSCR, BIT(pwm->hwpwm));
 
return 0;
 }
 
 static void jz4740_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
 {
-   jz4740_timer_set_ctrl(pwm->hwpwm, 0);
+   struct jz4740_pwm_chip *jz = to_jz4740(chip);
 
-   jz4740_timer_stop(pwm->hwpwm);
+   regmap_write(jz->map, TCU_REG_TSCR, BIT(pwm->hwpwm));
 }
 
 static int jz4740_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
 {
-   uint32_t ctrl = jz4740_timer_get_ctrl(pwm->pwm);
+   struct jz4740_pwm_chip *jz = to_jz4740(chip);
 
-   ctrl |= JZ_TIMER_CTRL_PWM_ENABLE;
-   jz4740_timer_set_ctrl(pwm->hwpwm, ctrl);
-   jz4740_timer_enable(pwm->hwpwm);
+   /* Enable PWM output */
+   regmap_update_bits(jz->map, TCU_REG_TCSRc(pwm->hwpwm),
+  TCU_TCSR_PWM_EN, TCU_TCSR_PWM_EN);
 
+   /* Start counter */
+   regmap_write(jz->map, TCU_REG_TESR, BIT(pwm->hwpwm));
return 0;
 }
 
 static void jz4740_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
 {
-   uint32_t ctrl = jz4740_timer_get_ctrl(pwm->hwpwm);
+   struct jz4740_pwm_chip *jz = to_jz4740(chip);
 
/* Disable PWM output.
 * In TCU2 mode (channel 1/2 on JZ4750+), this must be done before the
 * counter is stopped, while in TCU1 mode the order does not matter.
 */
-   ctrl &= ~JZ_TIMER_CTRL_PWM_ENABLE;
-   jz4740_timer_set_ctrl(pwm->hwpwm, ctrl);
+   regmap_update_bits(jz->map, TCU_REG_TCSRc(pwm->hwpwm),
+  TCU_TCSR_PWM_EN, 0);
 
/* Stop counter */
-   jz4740_timer_disable(pwm->hwpwm);
+   regmap_write(jz->map, TCU_REG_TECR, BIT(pwm->hwpwm));
 }
 
 static int jz4740_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
@@ -90,7 +95,6 @@ static int jz4740_pwm_apply(struct pwm_chip *chip, struct 
pwm_device *pwm,
unsigned long long tmp;
unsigned long period, duty;
unsigned int prescaler = 0;
-   uint16_t ctrl;
 
tmp = (unsigned long long)clk_get_rate(jz4740->clk) * state->period;
do_div(tmp, 10);
@@ -113,26 +117,37 @@ static int jz4740_pwm_apply(struct pwm_chip *chip, struct 
pwm_device *pwm,
 
jz4740_pwm_disable(chip, pwm);
 
-   jz4740_timer_set_count(pwm->hwpwm, 0);
-   jz4740_timer_set_duty(pwm->hwpwm, duty);
-   jz4740_timer_set_period(pwm->hwpwm, period);
+   /* Set abrupt shutdown */
+   regmap_update_bits(jz4740->map, TCU_REG_TCSRc(pwm->hwpwm),
+  TCU_TCSR_PWM_SD, TCU_TCSR_PWM_SD);
+
+   /* Set clock prescale */
+   regmap_update_bits(jz4740->map, TCU_REG_TCSRc(pwm->hwpwm),
+  TCU_TCSR_PRESCALE_MASK,
+  prescaler << TCU_TCSR_PRESCALE_LSB);
+
+   /* Reset counter to 0 */
+   regmap_write(jz4740->map, TCU_REG_TCNTc(pwm->hwpwm), 0);
 
-   ctrl = JZ_TIMER_CTRL_PRESCALER(prescaler) | JZ_TIMER_CTRL_SRC_EXT |
-   JZ_TIMER_CTRL_PWM_ABBRUPT_SHUTDOWN;
+   /* Set duty 

[PATCH v9 13/27] pwm: jz4740: Use clocks from TCU driver

[Paul Cercueil]

The ingenic-timer "TCU" driver provides us with clocks, that can be
(un)gated, reparented or reclocked from devicetree, instead of having
these settings hardcoded in this driver.

While this driver is devicetree-compatible, it is never (as of now)
probed from devicetree, so this change does not introduce a ABI problem
with current devicetree files.

Signed-off-by: Paul Cercueil 
---

Notes:
 v9: New patch

 drivers/pwm/Kconfig  |  3 ++-
 drivers/pwm/pwm-jz4740.c | 39 ++-
 2 files changed, 28 insertions(+), 14 deletions(-)

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 4ed003bc3d8d..0343f0c1238e 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -202,7 +202,8 @@ config PWM_IMX
 config PWM_JZ4740
tristate "Ingenic JZ47xx PWM support"
depends on MACH_INGENIC
-   select REGMAP
+   depends on COMMON_CLK
+   select INGENIC_TIMER
help
  Generic PWM framework driver for Ingenic JZ47xx based
  machines.
diff --git a/drivers/pwm/pwm-jz4740.c b/drivers/pwm/pwm-jz4740.c
index 8dfac5ffd71c..c6136bd4434b 100644
--- a/drivers/pwm/pwm-jz4740.c
+++ b/drivers/pwm/pwm-jz4740.c
@@ -28,7 +28,7 @@
 
 struct jz4740_pwm_chip {
struct pwm_chip chip;
-   struct clk *clk;
+   struct clk *clks[NUM_PWM];
struct regmap *map;
 };
 
@@ -40,6 +40,9 @@ static inline struct jz4740_pwm_chip *to_jz4740(struct 
pwm_chip *chip)
 static int jz4740_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
 {
struct jz4740_pwm_chip *jz = to_jz4740(chip);
+   struct clk *clk;
+   char clk_name[16];
+   int ret;
 
/*
 * Timers 0 and 1 are used for system tasks, so they are unavailable
@@ -48,16 +51,29 @@ static int jz4740_pwm_request(struct pwm_chip *chip, struct 
pwm_device *pwm)
if (pwm->hwpwm < 2)
return -EBUSY;
 
-   regmap_write(jz->map, TCU_REG_TSCR, BIT(pwm->hwpwm));
+   snprintf(clk_name, sizeof(clk_name), "timer%u", pwm->hwpwm);
 
+   clk = clk_get(chip->dev, clk_name);
+   if (IS_ERR(clk))
+   return PTR_ERR(clk);
+
+   ret = clk_prepare_enable(clk);
+   if (ret) {
+   clk_put(clk);
+   return ret;
+   }
+
+   jz->clks[pwm->hwpwm] = clk;
return 0;
 }
 
 static void jz4740_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
 {
struct jz4740_pwm_chip *jz = to_jz4740(chip);
+   struct clk *clk = jz->clks[pwm->hwpwm];
 
-   regmap_write(jz->map, TCU_REG_TSCR, BIT(pwm->hwpwm));
+   clk_disable_unprepare(clk);
+   clk_put(clk);
 }
 
 static int jz4740_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
@@ -92,16 +108,20 @@ static int jz4740_pwm_apply(struct pwm_chip *chip, struct 
pwm_device *pwm,
struct pwm_state *state)
 {
struct jz4740_pwm_chip *jz4740 = to_jz4740(pwm->chip);
+   struct clk *clk = jz4740->clks[pwm->hwpwm],
+  *parent_clk = clk_get_parent(clk);
+   unsigned long rate, period, duty;
unsigned long long tmp;
-   unsigned long period, duty;
unsigned int prescaler = 0;
 
-   tmp = (unsigned long long)clk_get_rate(jz4740->clk) * state->period;
+   rate = clk_get_rate(parent_clk);
+   tmp = (unsigned long long)rate * state->period;
do_div(tmp, 10);
period = tmp;
 
while (period > 0x && prescaler < 6) {
period >>= 2;
+   rate >>= 2;
++prescaler;
}
 
@@ -121,10 +141,7 @@ static int jz4740_pwm_apply(struct pwm_chip *chip, struct 
pwm_device *pwm,
regmap_update_bits(jz4740->map, TCU_REG_TCSRc(pwm->hwpwm),
   TCU_TCSR_PWM_SD, TCU_TCSR_PWM_SD);
 
-   /* Set clock prescale */
-   regmap_update_bits(jz4740->map, TCU_REG_TCSRc(pwm->hwpwm),
-  TCU_TCSR_PRESCALE_MASK,
-  prescaler << TCU_TCSR_PRESCALE_LSB);
+   clk_set_rate(clk, rate);
 
/* Reset counter to 0 */
regmap_write(jz4740->map, TCU_REG_TCNTc(pwm->hwpwm), 0);
@@ -170,10 +187,6 @@ static int jz4740_pwm_probe(struct platform_device *pdev)
if (!jz4740)
return -ENOMEM;
 
-   jz4740->clk = devm_clk_get(>dev, "ext");
-   if (IS_ERR(jz4740->clk))
-   return PTR_ERR(jz4740->clk);
-
jz4740->map = dev_get_regmap(dev->parent, NULL);
if (!jz4740->map) {
dev_err(dev, "regmap not found\n");
-- 
2.11.0

[PATCH v9 25/27] MIPS: GCW0: Reduce system timer to 750 kHz

[Paul Cercueil]

The default clock (12 MHz) is too fast for the system timer.

Signed-off-by: Paul Cercueil 
---

Notes:
 v8: New patch

 v9: Don't configure clock timer1, as the OS Timer is used as
 clocksource on this SoC

 arch/mips/boot/dts/ingenic/gcw0.dts | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/mips/boot/dts/ingenic/gcw0.dts 
b/arch/mips/boot/dts/ingenic/gcw0.dts
index 35f0291e8d38..c26572f8b8ae 100644
--- a/arch/mips/boot/dts/ingenic/gcw0.dts
+++ b/arch/mips/boot/dts/ingenic/gcw0.dts
@@ -60,3 +60,9 @@
/* The WiFi module is connected to the UHC. */
status = "okay";
 };
+
+ {
+   /* 750 kHz for the system timer */
+   assigned-clocks = < TCU_CLK_TIMER0>;
+   assigned-clock-rates = <75>;
+};
-- 
2.11.0

[PATCH v9 22/27] MIPS: qi_lb60: Reduce system timer and clocksource to 750 kHz

[Paul Cercueil]

The default clock (12 MHz) is too fast for the system timer, which fails
to report time accurately.

Signed-off-by: Paul Cercueil 
---

Notes:
 v5: New patch

 v6: Remove ingenic,clocksource-channel property

 v7: No change

 v8: No change

 v9: No change

 arch/mips/boot/dts/ingenic/qi_lb60.dts | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/mips/boot/dts/ingenic/qi_lb60.dts 
b/arch/mips/boot/dts/ingenic/qi_lb60.dts
index 85529a142409..de9d45e2c24a 100644
--- a/arch/mips/boot/dts/ingenic/qi_lb60.dts
+++ b/arch/mips/boot/dts/ingenic/qi_lb60.dts
@@ -45,3 +45,9 @@
bias-disable;
};
 };
+
+ {
+   /* 750 kHz for the system timer and clocksource */
+   assigned-clocks = < TCU_CLK_TIMER0>, < TCU_CLK_TIMER1>;
+   assigned-clock-rates = <75>, <75>;
+};
-- 
2.11.0

[PATCH v9 26/27] MIPS: GCW0: defconfig: Enable OST, watchdog, PWM drivers

[Paul Cercueil]

The OST driver provides a clocksource and sched_clock that are much more
accurate than the default ones.

Signed-off-by: Paul Cercueil 
---

Notes:
 v8: New patch

 v9: No change

 arch/mips/configs/gcw0_defconfig | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/arch/mips/configs/gcw0_defconfig b/arch/mips/configs/gcw0_defconfig
index 99ac1fa3b35f..7116400e8cbf 100644
--- a/arch/mips/configs/gcw0_defconfig
+++ b/arch/mips/configs/gcw0_defconfig
@@ -1,14 +1,14 @@
+CONFIG_NO_HZ_IDLE=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_EMBEDDED=y
 CONFIG_MACH_INGENIC=y
 CONFIG_JZ4770_GCW0=y
 CONFIG_HIGHMEM=y
-# CONFIG_BOUNCE is not set
-CONFIG_PREEMPT_VOLUNTARY=y
 # CONFIG_SECCOMP is not set
-CONFIG_NO_HZ_IDLE=y
-CONFIG_HIGH_RES_TIMERS=y
-CONFIG_EMBEDDED=y
-# CONFIG_BLK_DEV_BSG is not set
 # CONFIG_SUSPEND is not set
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_BOUNCE is not set
 CONFIG_NET=y
 CONFIG_PACKET=y
 CONFIG_UNIX=y
@@ -20,8 +20,13 @@ CONFIG_SERIAL_8250=y
 # CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
 CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_8250_INGENIC=y
+CONFIG_WATCHDOG=y
+CONFIG_JZ4740_WDT=y
 CONFIG_USB=y
 CONFIG_USB_OHCI_HCD=y
 CONFIG_USB_OHCI_HCD_PLATFORM=y
 CONFIG_NOP_USB_XCEIV=y
+CONFIG_INGENIC_OST=y
+CONFIG_PWM=y
+CONFIG_PWM_JZ4740=y
 CONFIG_TMPFS=y
-- 
2.11.0

[PATCH v9 21/27] MIPS: qi_lb60: Move PWM devices to devicetree

[Paul Cercueil]

Probe the few drivers using PWMs from devicetree, now that we have a
devicetree node for the PWM driver.

Signed-off-by: Paul Cercueil 
---

Notes:
 v5: New patch

 v6: No change

 v7: No change

 v8: No change

 v9: No change

 arch/mips/boot/dts/ingenic/qi_lb60.dts | 14 ++
 arch/mips/jz4740/board-qi_lb60.c   | 19 ---
 2 files changed, 14 insertions(+), 19 deletions(-)

diff --git a/arch/mips/boot/dts/ingenic/qi_lb60.dts 
b/arch/mips/boot/dts/ingenic/qi_lb60.dts
index 76aaf8982554..85529a142409 100644
--- a/arch/mips/boot/dts/ingenic/qi_lb60.dts
+++ b/arch/mips/boot/dts/ingenic/qi_lb60.dts
@@ -9,6 +9,14 @@
chosen {
stdout-path = 
};
+
+   beeper {
+   compatible = "pwm-beeper";
+   pwms = < 4 0 0>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pwm4>;
+   };
 };
 
  {
@@ -30,4 +38,10 @@
groups = "uart0-data";
bias-disable;
};
+
+   pins_pwm4: pwm4 {
+   function = "pwm4";
+   groups = "pwm4";
+   bias-disable;
+   };
 };
diff --git a/arch/mips/jz4740/board-qi_lb60.c b/arch/mips/jz4740/board-qi_lb60.c
index af0c8ace0141..cc556be656d6 100644
--- a/arch/mips/jz4740/board-qi_lb60.c
+++ b/arch/mips/jz4740/board-qi_lb60.c
@@ -27,7 +27,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 
@@ -392,17 +391,6 @@ static struct jz4740_mmc_platform_data qi_lb60_mmc_pdata = 
{
.power_active_low   = 1,
 };
 
-/* beeper */
-static struct pwm_lookup qi_lb60_pwm_lookup[] = {
-   PWM_LOOKUP("jz4740-pwm", 4, "pwm-beeper", NULL, 0,
-  PWM_POLARITY_NORMAL),
-};
-
-static struct platform_device qi_lb60_pwm_beeper = {
-   .name = "pwm-beeper",
-   .id = -1,
-};
-
 /* charger */
 static char *qi_lb60_batteries[] = {
"battery",
@@ -451,10 +439,8 @@ static struct platform_device *jz_platform_devices[] 
__initdata = {
_i2s_device,
_codec_device,
_adc_device,
-   _pwm_device,
_dma_device,
_lb60_gpio_keys,
-   _lb60_pwm_beeper,
_lb60_charger_device,
_lb60_audio_device,
 };
@@ -483,10 +469,6 @@ static struct pinctrl_map pin_map[] __initdata = {
"1001.jz4740-pinctrl", "PD0", pin_cfg_bias_disable),
PIN_MAP_CONFIGS_PIN_DEFAULT("jz4740-mmc.0",
"1001.jz4740-pinctrl", "PD2", pin_cfg_bias_disable),
-
-   /* PWM pin configuration */
-   PIN_MAP_MUX_GROUP_DEFAULT("jz4740-pwm",
-   "1001.jz4740-pinctrl", "pwm4", "pwm4"),
 };
 
 
@@ -504,7 +486,6 @@ static int __init qi_lb60_init_platform_devices(void)
spi_register_board_info(qi_lb60_spi_board_info,
ARRAY_SIZE(qi_lb60_spi_board_info));
 
-   pwm_add_table(qi_lb60_pwm_lookup, ARRAY_SIZE(qi_lb60_pwm_lookup));
pinctrl_register_mappings(pin_map, ARRAY_SIZE(pin_map));
 
return platform_add_devices(jz_platform_devices,
-- 
2.11.0

[PATCH v9 18/27] clk: jz4740: Add TCU clock

[Paul Cercueil]

Add the missing TCU clock to the list of clocks supplied by the CGU for
the JZ4740 SoC.

Signed-off-by: Paul Cercueil 
Acked-by: Stephen Boyd 
Acked-by: Rob Herring 
---

Notes:
 v5: New patch

 v6: No change

 v7: No change

 v8: No change

 v9: No change

 drivers/clk/ingenic/jz4740-cgu.c   | 6 ++
 include/dt-bindings/clock/jz4740-cgu.h | 1 +
 2 files changed, 7 insertions(+)

diff --git a/drivers/clk/ingenic/jz4740-cgu.c b/drivers/clk/ingenic/jz4740-cgu.c
index 4479c102e899..d8ac7f2e183a 100644
--- a/drivers/clk/ingenic/jz4740-cgu.c
+++ b/drivers/clk/ingenic/jz4740-cgu.c
@@ -211,6 +211,12 @@ static const struct ingenic_cgu_clk_info 
jz4740_cgu_clocks[] = {
.parents = { JZ4740_CLK_EXT, -1, -1, -1 },
.gate = { CGU_REG_CLKGR, 5 },
},
+
+   [JZ4740_CLK_TCU] = {
+   "tcu", CGU_CLK_GATE,
+   .parents = { JZ4740_CLK_EXT, -1, -1, -1 },
+   .gate = { CGU_REG_CLKGR, 1 },
+   },
 };
 
 static void __init jz4740_cgu_init(struct device_node *np)
diff --git a/include/dt-bindings/clock/jz4740-cgu.h 
b/include/dt-bindings/clock/jz4740-cgu.h
index 6ed83f926ae7..e82d77028581 100644
--- a/include/dt-bindings/clock/jz4740-cgu.h
+++ b/include/dt-bindings/clock/jz4740-cgu.h
@@ -34,5 +34,6 @@
 #define JZ4740_CLK_ADC 19
 #define JZ4740_CLK_I2C 20
 #define JZ4740_CLK_AIC 21
+#define JZ4740_CLK_TCU 22
 
 #endif /* __DT_BINDINGS_CLOCK_JZ4740_CGU_H__ */
-- 
2.11.0

[PATCH v9 19/27] MIPS: Kconfig: Select TCU timer driver when MACH_INGENIC is set

[Paul Cercueil]

We cannot boot to userspace (not even initramfs) if the timer driver is
not present; so it makes sense to enable it unconditionally when
MACH_INGENIC is set.

Signed-off-by: Paul Cercueil 
---

Notes:
 v5: New patch

 v6: No change

 v7: No change

 v8: No change

 v9: No change

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

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 8272ea4c7264..8bd53a4e871b 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -390,6 +390,7 @@ config MACH_INGENIC
select BUILTIN_DTB
select USE_OF
select LIBFDT
+   select INGENIC_TIMER
 
 config LANTIQ
bool "Lantiq based platforms"
-- 
2.11.0

[PATCH v9 23/27] MIPS: CI20: Reduce system timer to 3 MHz

[Paul Cercueil]

The default clock (48 MHz) is too fast for the system timer.

Signed-off-by: Paul Cercueil 
---

Notes:
 v5: New patch

 v6: Set also the rate for the clocksource channel's clock

 v7: No change

 v8: No change

 v9: Don't configure clock timer1, as the OS Timer is used as
 clocksource on this SoC

 arch/mips/boot/dts/ingenic/ci20.dts | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/mips/boot/dts/ingenic/ci20.dts 
b/arch/mips/boot/dts/ingenic/ci20.dts
index 50cff3cbcc6d..700cf28a52ec 100644
--- a/arch/mips/boot/dts/ingenic/ci20.dts
+++ b/arch/mips/boot/dts/ingenic/ci20.dts
@@ -238,3 +238,9 @@
bias-disable;
};
 };
+
+ {
+   /* 3 MHz for the system timer */
+   assigned-clocks = < TCU_CLK_TIMER0>;
+   assigned-clock-rates = <300>;
+};
-- 
2.11.0

[PATCH v9 24/27] MIPS: CI20: defconfig: enable OST driver

[Paul Cercueil]

The OST driver provides a clocksource and sched_clock that are much more
accurate than the default ones.

Signed-off-by: Paul Cercueil 
---

Notes:
 v5: New patch

 v6: No change

 v7: No change

 v8: No change

 v9: No change

 arch/mips/configs/ci20_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/mips/configs/ci20_defconfig b/arch/mips/configs/ci20_defconfig
index 030ff9c205fb..9b09b9a7f943 100644
--- a/arch/mips/configs/ci20_defconfig
+++ b/arch/mips/configs/ci20_defconfig
@@ -111,6 +111,7 @@ CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_JZ4740=y
 CONFIG_DMADEVICES=y
 CONFIG_DMA_JZ4780=y
+CONFIG_INGENIC_OST=y
 # CONFIG_IOMMU_SUPPORT is not set
 CONFIG_MEMORY=y
 CONFIG_EXT4_FS=y
-- 
2.11.0

[PATCH v9 15/27] pwm: jz4740: Allow selection of PWM channels 0 and 1

[Paul Cercueil]

The TCU channels 0 and 1 were previously reserved for system tasks, and
thus unavailable for PWM.

Signed-off-by: Paul Cercueil 
---

Notes:
 v6: New patch

 v7: No change

 v8: ingenic_tcu_[request,release]_channel are dropped. We now use
 the memory resources provided to the driver to detect whether
 or not we are allowed to use the TCU channel.

 v9: Drop previous system. Call a API function provided by the
 clocksource driver to know if we can use the channel as PWM.

 drivers/pwm/pwm-jz4740.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/pwm/pwm-jz4740.c b/drivers/pwm/pwm-jz4740.c
index dd80a2cf6528..b6e105e774bd 100644
--- a/drivers/pwm/pwm-jz4740.c
+++ b/drivers/pwm/pwm-jz4740.c
@@ -44,11 +44,7 @@ static int jz4740_pwm_request(struct pwm_chip *chip, struct 
pwm_device *pwm)
char clk_name[16];
int ret;
 
-   /*
-* Timers 0 and 1 are used for system tasks, so they are unavailable
-* for use as PWMs.
-*/
-   if (pwm->hwpwm < 2)
+   if (!ingenic_tcu_pwm_can_use_chn(pwm->hwpwm))
return -EBUSY;
 
snprintf(clk_name, sizeof(clk_name), "timer%u", pwm->hwpwm);
-- 
2.11.0

[PATCH v9 04/27] clocksource: Add a new timer-ingenic driver

[Paul Cercueil]

This driver handles the TCU (Timer Counter Unit) present on the Ingenic
JZ47xx SoCs, and provides the kernel with a system timer, and optionally
with a clocksource and a sched_clock.

It also provides clocks and interrupt handling to client drivers.

Signed-off-by: Paul Cercueil 
---

Notes:
 v2: Use SPDX identifier for the license

 v3: - Move documentation to its own patch
 - Search the devicetree for PWM clients, and use all the TCU
   channels that won't be used for PWM

 v4: - Add documentation about why we search for PWM clients
 - Verify that the PWM clients are for the TCU PWM driver

 v5: Major overhaul. Too many changes to list. Consider it's a new
 patch.

 v6: - Add two API functions ingenic_tcu_request_channel and
   ingenic_tcu_release_channel. To be used by the PWM driver to
   request the use of a TCU channel. The driver will now dynamically
   move away the system timer or clocksource to a new TCU channel.
 - The system timer now defaults to channel 0, the clocksource now
   defaults to channel 1 and is no more optional. The
   ingenic,timer-channel and ingenic,clocksource-channel devicetree
   properties are now gone.
 - Fix round_rate / set_rate not calculating the prescale divider
   the same way. This caused problems when (parent_rate / div) would
   give a non-integer result. The behaviour is correct now.
 - The clocksource clock is turned off on suspend now.

 v7: Fix section mismatch by using builtin_platform_driver_probe()

 v8: - Removed ingenic_tcu_[request,release]_channel, and the mechanism
   to dynamically change the TCU channel of the system timer or
   the clocksource.
 - The driver's devicetree node can now have two more children
   nodes, that correspond to the system timer and clocksource.
   For these two, the driver will use the TCU timer that
   correspond to the memory resource supplied in their
   respective node.

 v9: - Removed support for clocksource / timer children devicetree
   nodes. Now, we use a property "ingenic,pwm-channels-mask" to
   know which PWM channels are reserved for PWM use and should
   not be used as OS timers.

 drivers/clocksource/Kconfig |  10 +
 drivers/clocksource/Makefile|   1 +
 drivers/clocksource/ingenic-timer.c | 901 
 drivers/clocksource/ingenic-timer.h |  15 +
 include/linux/mfd/ingenic-tcu.h |   2 +
 5 files changed, 929 insertions(+)
 create mode 100644 drivers/clocksource/ingenic-timer.c
 create mode 100644 drivers/clocksource/ingenic-timer.h

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 55c77e44bb2d..4e69af15c3e7 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -638,4 +638,14 @@ config GX6605S_TIMER
help
  This option enables support for gx6605s SOC's timer.
 
+config INGENIC_TIMER
+   bool "Clocksource/timer using the TCU in Ingenic JZ SoCs"
+   depends on MIPS || COMPILE_TEST
+   depends on COMMON_CLK
+   select TIMER_OF
+   select IRQ_DOMAIN
+   select REGMAP
+   help
+ Support for the timer/counter unit of the Ingenic JZ SoCs.
+
 endmenu
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index dd9138104568..7c8f790dcf67 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -75,6 +75,7 @@ obj-$(CONFIG_ASM9260_TIMER)   += asm9260_timer.o
 obj-$(CONFIG_H8300_TMR8)   += h8300_timer8.o
 obj-$(CONFIG_H8300_TMR16)  += h8300_timer16.o
 obj-$(CONFIG_H8300_TPU)+= h8300_tpu.o
+obj-$(CONFIG_INGENIC_TIMER)+= ingenic-timer.o
 obj-$(CONFIG_CLKSRC_ST_LPC)+= clksrc_st_lpc.o
 obj-$(CONFIG_X86_NUMACHIP) += numachip.o
 obj-$(CONFIG_ATCPIT100_TIMER)  += timer-atcpit100.o
diff --git a/drivers/clocksource/ingenic-timer.c 
b/drivers/clocksource/ingenic-timer.c
new file mode 100644
index ..81faa120cfee
--- /dev/null
+++ b/drivers/clocksource/ingenic-timer.c
@@ -0,0 +1,901 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * JZ47xx SoCs TCU IRQ driver
+ * Copyright (C) 2018 Paul Cercueil 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "ingenic-timer.h"
+
+/* 8 channels max + watchdog + OST */
+#define TCU_CLK_COUNT  10
+
+enum tcu_clk_parent {
+   TCU_PARENT_PCLK,
+   TCU_PARENT_RTC,
+   TCU_PARENT_EXT,
+};
+
+struct ingenic_soc_info {
+   unsigned char num_channels;
+   bool has_ost;
+};
+
+struct ingenic_tcu_clk_info {
+   struct clk_init_data init_data;
+   u8 gate_bit;
+   u8 

[PATCH v9 27/27] MIPS: jz4740: Drop obsolete code

[Paul Cercueil]

The old clocksource/timer platform code is now obsoleted by the newly
introduced ingenic-timer and ingenic-ost drivers.

Signed-off-by: Paul Cercueil 
---

Notes:
 v5: New patch

 v6: No change

 v7: No change

 v8: No change

 v9: No change

 arch/mips/include/asm/mach-jz4740/platform.h |   1 -
 arch/mips/include/asm/mach-jz4740/timer.h| 135 
 arch/mips/jz4740/Makefile|   3 +-
 arch/mips/jz4740/platform.c  |   6 -
 arch/mips/jz4740/setup.c |   8 ++
 arch/mips/jz4740/time.c  | 176 ---
 arch/mips/jz4740/timer.c |  51 
 7 files changed, 9 insertions(+), 371 deletions(-)
 delete mode 100644 arch/mips/include/asm/mach-jz4740/timer.h
 delete mode 100644 arch/mips/jz4740/time.c
 delete mode 100644 arch/mips/jz4740/timer.c

diff --git a/arch/mips/include/asm/mach-jz4740/platform.h 
b/arch/mips/include/asm/mach-jz4740/platform.h
index c0c932ac72a7..cd464d956882 100644
--- a/arch/mips/include/asm/mach-jz4740/platform.h
+++ b/arch/mips/include/asm/mach-jz4740/platform.h
@@ -29,7 +29,6 @@ extern struct platform_device jz4740_i2s_device;
 extern struct platform_device jz4740_pcm_device;
 extern struct platform_device jz4740_codec_device;
 extern struct platform_device jz4740_adc_device;
-extern struct platform_device jz4740_pwm_device;
 extern struct platform_device jz4740_dma_device;
 
 #endif
diff --git a/arch/mips/include/asm/mach-jz4740/timer.h 
b/arch/mips/include/asm/mach-jz4740/timer.h
deleted file mode 100644
index 8750a1d04e22..
--- a/arch/mips/include/asm/mach-jz4740/timer.h
+++ /dev/null
@@ -1,135 +0,0 @@
-/*
- *  Copyright (C) 2010, Lars-Peter Clausen 
- *  JZ4740 platform timer support
- *
- *  This program is free software; you can redistribute it and/or modify it
- *  under  the terms of the GNU General Public License as published by 
the
- *  Free Software Foundation;  either version 2 of the License, or (at your
- *  option) any later version.
- *
- *  You should have received a copy of the GNU General Public License along
- *  with this program; if not, write to the Free Software Foundation, Inc.,
- *  675 Mass Ave, Cambridge, MA 02139, USA.
- *
- */
-
-#ifndef __ASM_MACH_JZ4740_TIMER
-#define __ASM_MACH_JZ4740_TIMER
-
-#define JZ_REG_TIMER_STOP  0x0C
-#define JZ_REG_TIMER_STOP_SET  0x1C
-#define JZ_REG_TIMER_STOP_CLEAR0x2C
-#define JZ_REG_TIMER_ENABLE0x00
-#define JZ_REG_TIMER_ENABLE_SET0x04
-#define JZ_REG_TIMER_ENABLE_CLEAR  0x08
-#define JZ_REG_TIMER_FLAG  0x10
-#define JZ_REG_TIMER_FLAG_SET  0x14
-#define JZ_REG_TIMER_FLAG_CLEAR0x18
-#define JZ_REG_TIMER_MASK  0x20
-#define JZ_REG_TIMER_MASK_SET  0x24
-#define JZ_REG_TIMER_MASK_CLEAR0x28
-
-#define JZ_REG_TIMER_DFR(x) (((x) * 0x10) + 0x30)
-#define JZ_REG_TIMER_DHR(x) (((x) * 0x10) + 0x34)
-#define JZ_REG_TIMER_CNT(x) (((x) * 0x10) + 0x38)
-#define JZ_REG_TIMER_CTRL(x) (((x) * 0x10) + 0x3C)
-
-#define JZ_TIMER_IRQ_HALF(x) BIT((x) + 0x10)
-#define JZ_TIMER_IRQ_FULL(x) BIT(x)
-
-#define JZ_TIMER_CTRL_PWM_ABBRUPT_SHUTDOWN BIT(9)
-#define JZ_TIMER_CTRL_PWM_ACTIVE_LOW   BIT(8)
-#define JZ_TIMER_CTRL_PWM_ENABLE   BIT(7)
-#define JZ_TIMER_CTRL_PRESCALE_MASK0x1c
-#define JZ_TIMER_CTRL_PRESCALE_OFFSET  0x3
-#define JZ_TIMER_CTRL_PRESCALE_1   (0 << 3)
-#define JZ_TIMER_CTRL_PRESCALE_4   (1 << 3)
-#define JZ_TIMER_CTRL_PRESCALE_16  (2 << 3)
-#define JZ_TIMER_CTRL_PRESCALE_64  (3 << 3)
-#define JZ_TIMER_CTRL_PRESCALE_256 (4 << 3)
-#define JZ_TIMER_CTRL_PRESCALE_1024(5 << 3)
-
-#define JZ_TIMER_CTRL_PRESCALER(x) ((x) << JZ_TIMER_CTRL_PRESCALE_OFFSET)
-
-#define JZ_TIMER_CTRL_SRC_EXT  BIT(2)
-#define JZ_TIMER_CTRL_SRC_RTC  BIT(1)
-#define JZ_TIMER_CTRL_SRC_PCLK BIT(0)
-
-extern void __iomem *jz4740_timer_base;
-void __init jz4740_timer_init(void);
-
-void jz4740_timer_enable_watchdog(void);
-void jz4740_timer_disable_watchdog(void);
-
-static inline void jz4740_timer_stop(unsigned int timer)
-{
-   writel(BIT(timer), jz4740_timer_base + JZ_REG_TIMER_STOP_SET);
-}
-
-static inline void jz4740_timer_start(unsigned int timer)
-{
-   writel(BIT(timer), jz4740_timer_base + JZ_REG_TIMER_STOP_CLEAR);
-}
-
-static inline bool jz4740_timer_is_enabled(unsigned int timer)
-{
-   return readb(jz4740_timer_base + JZ_REG_TIMER_ENABLE) & BIT(timer);
-}
-
-static inline void jz4740_timer_enable(unsigned int timer)
-{
-   writeb(BIT(timer), jz4740_timer_base + JZ_REG_TIMER_ENABLE_SET);
-}
-
-static inline void jz4740_timer_disable(unsigned int timer)
-{
-   writeb(BIT(timer), jz4740_timer_base + JZ_REG_TIMER_ENABLE_CLEAR);
-}
-
-static inline void jz4740_timer_set_period(unsigned int 

[PATCH v9 20/27] MIPS: jz4740: Add DTS nodes for the TCU drivers

[Paul Cercueil]

Add DTS nodes for the JZ4780, JZ4770 and JZ4740 devicetree files.

Signed-off-by: Paul Cercueil 
---

Notes:
 v5: New patch

 v6: Fix register lengths in watchdog/pwm nodes

 v7: No change

 v8: - Fix wrong start address for PWM node
 - Add system timer and clocksource sub-nodes

 v9: Drop timer and clocksource sub-nodes

 arch/mips/boot/dts/ingenic/jz4740.dtsi | 51 +++---
 arch/mips/boot/dts/ingenic/jz4770.dtsi | 59 ++
 arch/mips/boot/dts/ingenic/jz4780.dtsi | 67 ++
 3 files changed, 164 insertions(+), 13 deletions(-)

diff --git a/arch/mips/boot/dts/ingenic/jz4740.dtsi 
b/arch/mips/boot/dts/ingenic/jz4740.dtsi
index 6fb16fd24035..b4ccca7204e8 100644
--- a/arch/mips/boot/dts/ingenic/jz4740.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4740.dtsi
@@ -1,5 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 #include 
+#include 
 
 / {
#address-cells = <1>;
@@ -45,12 +46,52 @@
#clock-cells = <1>;
};
 
-   watchdog: watchdog@10002000 {
-   compatible = "ingenic,jz4740-watchdog";
-   reg = <0x10002000 0x10>;
+   tcu: timer@10002000 {
+   compatible = "ingenic,jz4740-tcu";
+   reg = <0x10002000 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x10002000 0x1000>;
 
-   clocks = < JZ4740_CLK_RTC>;
-   clock-names = "rtc";
+   #clock-cells = <1>;
+
+   clocks = < JZ4740_CLK_RTC
+  JZ4740_CLK_EXT
+  JZ4740_CLK_PCLK
+  JZ4740_CLK_TCU>;
+   clock-names = "rtc", "ext", "pclk", "tcu";
+
+   interrupt-controller;
+   #interrupt-cells = <1>;
+
+   interrupt-parent = <>;
+   interrupts = <23 22 21>;
+
+   watchdog: watchdog@0 {
+   compatible = "ingenic,jz4740-watchdog";
+   reg = <0x0 0xc>;
+
+   clocks = < TCU_CLK_WDT>;
+   clock-names = "wdt";
+   };
+
+   pwm: pwm@40 {
+   compatible = "ingenic,jz4740-pwm";
+   reg = <0x40 0x80>;
+
+   #pwm-cells = <3>;
+
+   clocks = < TCU_CLK_TIMER0
+  TCU_CLK_TIMER1
+  TCU_CLK_TIMER2
+  TCU_CLK_TIMER3
+  TCU_CLK_TIMER4
+  TCU_CLK_TIMER5
+  TCU_CLK_TIMER6
+  TCU_CLK_TIMER7>;
+   clock-names = "timer0", "timer1", "timer2", "timer3",
+ "timer4", "timer5", "timer6", "timer7";
+   };
};
 
rtc_dev: rtc@10003000 {
diff --git a/arch/mips/boot/dts/ingenic/jz4770.dtsi 
b/arch/mips/boot/dts/ingenic/jz4770.dtsi
index 49ede6c14ff3..89c7a4b9773c 100644
--- a/arch/mips/boot/dts/ingenic/jz4770.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4770.dtsi
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 
 #include 
+#include 
 
 / {
#address-cells = <1>;
@@ -46,6 +47,64 @@
#clock-cells = <1>;
};
 
+   tcu: timer@10002000 {
+   compatible = "ingenic,jz4770-tcu";
+   reg = <0x10002000 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x10002000 0x1000>;
+
+   #clock-cells = <1>;
+
+   clocks = < JZ4770_CLK_RTC
+  JZ4770_CLK_EXT
+  JZ4770_CLK_PCLK
+  JZ4770_CLK_EXT>;
+   clock-names = "rtc", "ext", "pclk", "tcu";
+
+   interrupt-controller;
+   #interrupt-cells = <1>;
+
+   interrupt-parent = <>;
+   interrupts = <27 26 25>;
+
+   watchdog: watchdog@0 {
+   compatible = "ingenic,jz4740-watchdog";
+   reg = <0x0 0xc>;
+
+   clocks = < TCU_CLK_WDT>;
+   clock-names = "wdt";
+   };
+
+   pwm: pwm@40 {
+   compatible = "ingenic,jz4740-pwm";
+   reg = <0x40 0x80>;
+
+   #pwm-cells = <3>;
+
+   clocks = < TCU_CLK_TIMER0
+  TCU_CLK_TIMER1
+  TCU_CLK_TIMER2
+  TCU_CLK_TIMER3
+  TCU_CLK_TIMER4
+  TCU_CLK_TIMER5
+  TCU_CLK_TIMER6
+  TCU_CLK_TIMER7>;
+   clock-names = "timer0", "timer1", 

[PATCH v9 07/27] watchdog: jz4740: Use WDT clock provided by TCU driver

[Paul Cercueil]

Instead of requesting the "ext" clock and handling the watchdog clock
divider and gating in the watchdog driver, we now request and use the
"wdt" clock that is supplied by the ingenic-timer "TCU" driver.

The major benefit is that the watchdog's clock rate and parent can now
be specified from within devicetree, instead of hardcoded in the driver.

Also, this driver won't poke anymore into the TCU registers to
enable/disable the clock, as this is now handled by the TCU driver.

On the bad side, we break the ABI with devicetree - as we now request a
different clock. In this very specific case it is still okay, as every
Ingenic JZ47xx-based board out there compile the devicetree within the
kernel; so it's still time to push breaking changes, in order to get a
clean devicetree that won't break once it musn't.

Signed-off-by: Paul Cercueil 
Reviewed-by: Guenter Roeck 
---

Notes:
 v5: New patch

 v6: - Split regmap change to new patch 09/24
 - The code now sets the WDT clock to the smallest rate possible and
   calculates the maximum timeout from that

 v7: No change

 v8: No change

 v9: No change

 drivers/watchdog/Kconfig  |  2 +
 drivers/watchdog/jz4740_wdt.c | 86 +--
 2 files changed, 36 insertions(+), 52 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 2d64333f4782..cfd7368fc3c0 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1497,7 +1497,9 @@ config INDYDOG
 config JZ4740_WDT
tristate "Ingenic jz4740 SoC hardware watchdog"
depends on MACH_JZ4740 || MACH_JZ4780
+   depends on COMMON_CLK
select WATCHDOG_CORE
+   select INGENIC_TIMER
help
  Hardware driver for the built-in watchdog timer on Ingenic jz4740 
SoCs.
 
diff --git a/drivers/watchdog/jz4740_wdt.c b/drivers/watchdog/jz4740_wdt.c
index ec4d99a830ba..1d504ecf45e1 100644
--- a/drivers/watchdog/jz4740_wdt.c
+++ b/drivers/watchdog/jz4740_wdt.c
@@ -26,25 +26,9 @@
 #include 
 #include 
 
-#include 
-
 #define JZ_REG_WDT_TIMER_DATA 0x0
 #define JZ_REG_WDT_COUNTER_ENABLE 0x4
 #define JZ_REG_WDT_TIMER_COUNTER  0x8
-#define JZ_REG_WDT_TIMER_CONTROL  0xC
-
-#define JZ_WDT_CLOCK_PCLK 0x1
-#define JZ_WDT_CLOCK_RTC  0x2
-#define JZ_WDT_CLOCK_EXT  0x4
-
-#define JZ_WDT_CLOCK_DIV_SHIFT   3
-
-#define JZ_WDT_CLOCK_DIV_1(0 << JZ_WDT_CLOCK_DIV_SHIFT)
-#define JZ_WDT_CLOCK_DIV_4(1 << JZ_WDT_CLOCK_DIV_SHIFT)
-#define JZ_WDT_CLOCK_DIV_16   (2 << JZ_WDT_CLOCK_DIV_SHIFT)
-#define JZ_WDT_CLOCK_DIV_64   (3 << JZ_WDT_CLOCK_DIV_SHIFT)
-#define JZ_WDT_CLOCK_DIV_256  (4 << JZ_WDT_CLOCK_DIV_SHIFT)
-#define JZ_WDT_CLOCK_DIV_1024 (5 << JZ_WDT_CLOCK_DIV_SHIFT)
 
 #define DEFAULT_HEARTBEAT 5
 #define MAX_HEARTBEAT 2048
@@ -65,7 +49,8 @@ MODULE_PARM_DESC(heartbeat,
 struct jz4740_wdt_drvdata {
struct watchdog_device wdt;
void __iomem *base;
-   struct clk *rtc_clk;
+   struct clk *clk;
+   unsigned long clk_rate;
 };
 
 static int jz4740_wdt_ping(struct watchdog_device *wdt_dev)
@@ -80,31 +65,12 @@ static int jz4740_wdt_set_timeout(struct watchdog_device 
*wdt_dev,
unsigned int new_timeout)
 {
struct jz4740_wdt_drvdata *drvdata = watchdog_get_drvdata(wdt_dev);
-   unsigned int rtc_clk_rate;
-   unsigned int timeout_value;
-   unsigned short clock_div = JZ_WDT_CLOCK_DIV_1;
-
-   rtc_clk_rate = clk_get_rate(drvdata->rtc_clk);
-
-   timeout_value = rtc_clk_rate * new_timeout;
-   while (timeout_value > 0x) {
-   if (clock_div == JZ_WDT_CLOCK_DIV_1024) {
-   /* Requested timeout too high;
-   * use highest possible value. */
-   timeout_value = 0x;
-   break;
-   }
-   timeout_value >>= 2;
-   clock_div += (1 << JZ_WDT_CLOCK_DIV_SHIFT);
-   }
+   u16 timeout_value = (u16)(drvdata->clk_rate * new_timeout);
 
writeb(0x0, drvdata->base + JZ_REG_WDT_COUNTER_ENABLE);
-   writew(clock_div, drvdata->base + JZ_REG_WDT_TIMER_CONTROL);
 
writew((u16)timeout_value, drvdata->base + JZ_REG_WDT_TIMER_DATA);
writew(0x0, drvdata->base + JZ_REG_WDT_TIMER_COUNTER);
-   writew(clock_div | JZ_WDT_CLOCK_RTC,
-   drvdata->base + JZ_REG_WDT_TIMER_CONTROL);
 
writeb(0x1, drvdata->base + JZ_REG_WDT_COUNTER_ENABLE);
 
@@ -114,7 +80,13 @@ static int jz4740_wdt_set_timeout(struct watchdog_device 
*wdt_dev,
 
 static int jz4740_wdt_start(struct watchdog_device *wdt_dev)
 {
-   jz4740_timer_enable_watchdog();
+   struct jz4740_wdt_drvdata *drvdata = watchdog_get_drvdata(wdt_dev);
+   int ret;
+
+   ret = clk_prepare_enable(drvdata->clk);
+   if (ret)
+   return ret;
+
jz4740_wdt_set_timeout(wdt_dev, wdt_dev->timeout);
 
return 0;
@@ -125,7 +97,7 @@ static int 

[PATCH v9 16/27] pwm: jz4740: Drop dependency on MACH_INGENIC, use COMPILE_TEST

[Paul Cercueil]

Depending on MACH_INGENIC prevent us from creating a generic kernel that
works on more than one MIPS board. Instead, we just depend on MIPS being
set.

On other architectures, this driver can still be built, thanks to
COMPILE_TEST. This is used by automated tools to find bugs, for
instance.

Signed-off-by: Paul Cercueil 
Acked-by: Thierry Reding 
---

Notes:
 v5: New patch

 v6: No change

 v7: No change

 v8: No change

 v9: No change

 drivers/pwm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 0343f0c1238e..d6f62d9cdc18 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -201,7 +201,7 @@ config PWM_IMX
 
 config PWM_JZ4740
tristate "Ingenic JZ47xx PWM support"
-   depends on MACH_INGENIC
+   depends on MIPS || COMPILE_TEST
depends on COMMON_CLK
select INGENIC_TIMER
help
-- 
2.11.0

[PATCH v9 01/27] dt-bindings: ingenic: Add DT bindings for TCU clocks

[Paul Cercueil]

This header provides clock numbers for the ingenic,tcu
DT binding.

Signed-off-by: Paul Cercueil 
Reviewed-by: Rob Herring 
Acked-by: Stephen Boyd 
---

Notes:
 v2: Use SPDX identifier for the license

 v3: No change

 v4: No change

 v5: s/JZ47*_/TCU_/ and dropped *_CLK_LAST defines

 v6: No change

 v7: No change

 v8: No change

 v9: No change

 include/dt-bindings/clock/ingenic,tcu.h | 20 
 1 file changed, 20 insertions(+)
 create mode 100644 include/dt-bindings/clock/ingenic,tcu.h

diff --git a/include/dt-bindings/clock/ingenic,tcu.h 
b/include/dt-bindings/clock/ingenic,tcu.h
new file mode 100644
index ..d569650a7945
--- /dev/null
+++ b/include/dt-bindings/clock/ingenic,tcu.h
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * This header provides clock numbers for the ingenic,tcu DT binding.
+ */
+
+#ifndef __DT_BINDINGS_CLOCK_INGENIC_TCU_H__
+#define __DT_BINDINGS_CLOCK_INGENIC_TCU_H__
+
+#define TCU_CLK_TIMER0 0
+#define TCU_CLK_TIMER1 1
+#define TCU_CLK_TIMER2 2
+#define TCU_CLK_TIMER3 3
+#define TCU_CLK_TIMER4 4
+#define TCU_CLK_TIMER5 5
+#define TCU_CLK_TIMER6 6
+#define TCU_CLK_TIMER7 7
+#define TCU_CLK_WDT8
+#define TCU_CLK_OST9
+
+#endif /* __DT_BINDINGS_CLOCK_INGENIC_TCU_H__ */
-- 
2.11.0

[PATCH v9 00/27] Ingenic TCU patchset v9

[Paul Cercueil]

Hi,

This is the v9 of my patchset to add support for the Timer/Counter Unit
present on Ingenic JZ47xx SoCs.

Changes from v8 mainly include:

- The system timer and clocksource sub-nodes of the ingenic-timer driver
  are gone. Now, the ingenic-timer will use the (optional) property
  named "ingenic,pwm-channels-mask" to know which TCU channels are
  reserved for PWM use.

- New patch [11/27] makes the PWM driver implement the .apply callback,
  which is cleaner and incidentally fixes a long-standing bug.

- The patch in V8 that converted the PWM driver to use the regmap and
  clocks provided by the ingenic-timer driver has been splitted in three
  patches, [12,13,14/27]. The algorithm in [14/27] has been slightly
  improved.

- The patch that adds support for the JZ4725B SoC to the PWM driver has
  been removed from the patchset, as it's been suggested that the core
  could use a "npwms" device property to override the number of PWMs set
  in the driver.

Thanks,
-Paul Cercueil

[PATCH v9 02/27] doc: Add doc for the Ingenic TCU hardware

[Paul Cercueil]

Add a documentation file about the Timer/Counter Unit (TCU) present in
the Ingenic JZ47xx SoCs.

The Timer/Counter Unit (TCU) in Ingenic JZ47xx SoCs is a multi-function
hardware block. It features up to to eight channels, that can be used as
counters, timers, or PWM.

- JZ4725B, JZ4750, JZ4755 only have six TCU channels. The other SoCs all
  have eight channels.

- JZ4725B introduced a separate channel, called Operating System Timer
  (OST). It is a 32-bit programmable timer. On JZ4770 and above, it is
  64-bit.

- Each one of the TCU channels has its own clock, which can be reparented
  to three different clocks (pclk, ext, rtc), gated, and reclocked, through
  their TCSR register.
  * The watchdog and OST hardware blocks also feature a TCSR register with
the same format in their register space.
  * The TCU registers used to gate/ungate can also gate/ungate the watchdog
and OST clocks.

- Each TCU channel works in one of two modes:
  * mode TCU1: channels cannot work in sleep mode, but are easier to
operate.
  * mode TCU2: channels can work in sleep mode, but the operation is a bit
more complicated than with TCU1 channels.

- The mode of each TCU channel depends on the SoC used:
  * On the oldest SoCs (up to JZ4740), all of the eight channels operate in
TCU1 mode.
  * On JZ4725B, channel 5 operates as TCU2, the others operate as TCU1.
  * On newest SoCs (JZ4750 and above), channels 1-2 operate as TCU2, the
others operate as TCU1.

- Each channel can generate an interrupt. Some channels share an interrupt
  line, some don't, and this changes between SoC versions:
  * on older SoCs (JZ4740 and below), channel 0 and channel 1 have their
own interrupt line; channels 2-7 share the last interrupt line.
  * On JZ4725B, channel 0 has its own interrupt; channels 1-5 share one
interrupt line; the OST uses the last interrupt line.
  * on newer SoCs (JZ4750 and above), channel 5 has its own interrupt;
channels 0-4 and (if eight channels) 6-7 all share one interrupt line;
the OST uses the last interrupt line.

Signed-off-by: Paul Cercueil 
---

Notes:
 v4: New patch in this series

 v5: Added information about number of channels, and improved
 documentation about channel modes

 v6: Add info about OST (can be 32-bit on older SoCs)

 v7: No change

 v8: No change

 v9: No change

 Documentation/mips/ingenic-tcu.txt | 60 ++
 1 file changed, 60 insertions(+)
 create mode 100644 Documentation/mips/ingenic-tcu.txt

diff --git a/Documentation/mips/ingenic-tcu.txt 
b/Documentation/mips/ingenic-tcu.txt
new file mode 100644
index ..0ea35b2a46da
--- /dev/null
+++ b/Documentation/mips/ingenic-tcu.txt
@@ -0,0 +1,60 @@
+Ingenic JZ47xx SoCs Timer/Counter Unit hardware
+---
+
+The Timer/Counter Unit (TCU) in Ingenic JZ47xx SoCs is a multi-function
+hardware block. It features up to to eight channels, that can be used as
+counters, timers, or PWM.
+
+- JZ4725B, JZ4750, JZ4755 only have six TCU channels. The other SoCs all
+  have eight channels.
+
+- JZ4725B introduced a separate channel, called Operating System Timer
+  (OST). It is a 32-bit programmable timer. On JZ4770 and above, it is
+  64-bit.
+
+- Each one of the TCU channels has its own clock, which can be reparented
+  to three different clocks (pclk, ext, rtc), gated, and reclocked, through
+  their TCSR register.
+  * The watchdog and OST hardware blocks also feature a TCSR register with
+the same format in their register space.
+  * The TCU registers used to gate/ungate can also gate/ungate the watchdog
+and OST clocks.
+
+- Each TCU channel works in one of two modes:
+  * mode TCU1: channels cannot work in sleep mode, but are easier to
+operate.
+  * mode TCU2: channels can work in sleep mode, but the operation is a bit
+more complicated than with TCU1 channels.
+
+- The mode of each TCU channel depends on the SoC used:
+  * On the oldest SoCs (up to JZ4740), all of the eight channels operate in
+TCU1 mode.
+  * On JZ4725B, channel 5 operates as TCU2, the others operate as TCU1.
+  * On newest SoCs (JZ4750 and above), channels 1-2 operate as TCU2, the
+others operate as TCU1.
+
+- Each channel can generate an interrupt. Some channels share an interrupt
+  line, some don't, and this changes between SoC versions:
+  * on older SoCs (JZ4740 and below), channel 0 and channel 1 have their
+own interrupt line; channels 2-7 share the last interrupt line.
+  * On JZ4725B, channel 0 has its own interrupt; channels 1-5 share one
+interrupt line; the OST uses the last interrupt line.
+  * on newer SoCs (JZ4750 and above), channel 5 has its own interrupt;
+channels 0-4 and (if eight channels) 6-7 all share one interrupt line;
+the OST uses the last interrupt line.
+
+Implementation
+--
+
+The functionalities of the TCU hardware are spread across multiple 

Re: d_off field in struct dirent and 32-on-64 emulation

[Florian Weimer]

* Adhemerval Zanella:

> Also for glibc standpoint, although reverting it back to use getdents 
> syscall for non-LFS mode might fix this issue for architectures that
> provides non-LFS getdents syscall it won't be a fix for architectures 
> that still provides off_t different than off64_t *and* only provides 
> getdents64 syscall.
>
> Currently we only have nios2 and csky (unfortunately).  But since generic 
> definition for off_t and off64_t still assumes non-LFS support, all new
> 32-bits ports potentially might carry the issue.

For csky, we could still change the type of the non-standard d_off
field to long long int.  This way, only telldir would have to fail
when truncation is necessary, as mentioned below:

>> There is another annoying aspect: The standards expose d_off through
>> the telldir function, and that returns long int on all architectures
>> (not off_t, so unchanged by _FILE_OFFSET_BITS).  That's mostly a
>> userspace issue and thus needing different steps to resolve (possibly
>> standards action).

Re: d_off field in struct dirent and 32-on-64 emulation

[Adhemerval Zanella]

On 27/12/2018 15:18, Florian Weimer wrote:
> We have a bit of an interesting problem with respect to the d_off
> field in struct dirent.
> 
> When running a 64-bit kernel on certain file systems, notably ext4,
> this field uses the full 63 bits even for small directories (strace -v
> output, wrapped here for readability):
> 
> getdents(3, [
>   {d_ino=1494304, d_off=3901177228673045825, d_reclen=40, 
> d_name="authorized_keys", d_type=DT_REG},
>   {d_ino=1494277, d_off=7491915799041650922, d_reclen=24, d_name=".", 
> d_type=DT_DIR},
>   {d_ino=1314655, d_off=9223372036854775807, d_reclen=24, d_name="..", 
> d_type=DT_DIR}
> ], 32768) = 88
> 
> When running in 32-bit compat mode, this value is somehow truncated to
> 31 bits, for both the getdents and the getdents64 (!) system call (at
> least on i386).
> 
> In an effort to simplify support for future architectures which only
> have the getdents64 system call, we changed glibc 2.28 to use the
> getdents64 system call unconditionally, and perform translation if
> necessary.  This translation is noteworthy because it includes
> overflow checking for the d_ino and d_off members of struct dirent.
> We did not initially observe a regression because the kernel performs
> consistent d_off truncation (with the ext4 file system; small
> directories do not show this issue on XFS), so the overflow check does
> not fire.
> 
> However, both qemu-user and the 9p file system can run in such a way
> that the kernel is entered from a 64-bit process, but the actual usage
> is from a 32-bit process:
> 
>   
> 
> I think diagrammatically, this looks like this:
> 
>   guest process  (32-bit)
> | getdents64, 32-bit UAPI
>   qemu-user (64-bit)
> | getdents, 64-bit UAPI
>   host kernel (64-bit)
> 
> Or:
> 
>   guest process 
> | getdents64, 32-bit UAPI
>   guest kernel (64-bit)
> | 9p over virtio (64-bit d_off in struct p9_dirent)
>   qemu
> | getdents, 64-bit UAPI
>   host kernel (64-bit)
> 
> Back when we still called getdents, in the first case, the 32-bit
> getdents system call emulation in a 64-bit qemu-user process would
> just silently truncate the d_off field as part of the translation, not
> reporting an error.  The second case is more complicated, and I have
> not figured out where the truncation happens.
> 
> This truncation has always been a bug; it breaks telldir/seekdir at
> least in some cases.  But use of telldir/seekdir is comparatively
> rare.  In contrast, now that we detect d_off overflow in glibc,
> readdir will always fail in the sketched configurations, which is bad.
> (glibc exposes the d_off field to applications, and it cannot know
> whether the application will use it or not, so there is no direct way
> to restrict the overflow error to the telldir/seekdir use case.)
> 
> We could switch glibc to call getdents again if the system call is
> available.  But that merely relies on the existence of the truncation
> bug somewhere else in the file system stack.  This is why I don't
> think it's the right solution, just the path of least resistance.
> 
> I don't want to reimplement the ext4 truncation behavior in glibc (it
> doesn't look like a straightforward truncation), and it wouldn't work
> for the second scenario where we see the 9p file system in the 32-bit
> glibc, not the ext4 file system.  So that's not a good solution.

Also for glibc standpoint, although reverting it back to use getdents 
syscall for non-LFS mode might fix this issue for architectures that
provides non-LFS getdents syscall it won't be a fix for architectures 
that still provides off_t different than off64_t *and* only provides 
getdents64 syscall.

Currently we only have nios2 and csky (unfortunately).  But since generic 
definition for off_t and off64_t still assumes non-LFS support, all new
32-bits ports potentially might carry the issue.

> 
> There is another annoying aspect: The standards expose d_off through
> the telldir function, and that returns long int on all architectures
> (not off_t, so unchanged by _FILE_OFFSET_BITS).  That's mostly a
> userspace issue and thus needing different steps to resolve (possibly
> standards action).
> 
> Any suggestions how to solve this?  Why does the kernel return
> different d_off values for 32-bit and 64-bit processes even when using
> getdents64, for the same directory?
> 

Re: d_off field in struct dirent and 32-on-64 emulation

[Florian Weimer]

* Andy Lutomirski:

>> On Dec 27, 2018, at 10:18 AM, Florian Weimer  wrote:
>> 
>> We have a bit of an interesting problem with respect to the d_off
>> field in struct dirent.
>> 
>> When running a 64-bit kernel on certain file systems, notably ext4,
>> this field uses the full 63 bits even for small directories (strace -v
>> output, wrapped here for readability):
>> 
>> getdents(3, [
>>  {d_ino=1494304, d_off=3901177228673045825, d_reclen=40,
>> d_name="authorized_keys", d_type=DT_REG},
>>  {d_ino=1494277, d_off=7491915799041650922, d_reclen=24, d_name=".",
>> d_type=DT_DIR},
>>  {d_ino=1314655, d_off=9223372036854775807, d_reclen=24,
>> d_name="..", d_type=DT_DIR}
>> ], 32768) = 88
>> 
>> When running in 32-bit compat mode, this value is somehow truncated to
>> 31 bits, for both the getdents and the getdents64 (!) system call (at
>> least on i386).
>
> I imagine you’re encountering this bug:
>
> https://lkml.org/lkml/2018/10/18/859

It's definitely in this area.  However, the original collision problem
with 32-bit hashes is also real, so I can see the desire to use more
bits.

> Presumably the right fix involves modifying the relevant VFS file
> operations to indicate the relevant ABI to the implementations.

Not sure.  How does NFS solve this problem when access happens from a
32-bit process and the rest (client kernel, transport, server kernel)
is 64-bit all the way?

> I would guess that 9p is triggering the “not really in the syscall you
> think you’re in” issue.

I think the issue is more like the networking case for 9p.  In this
scenario, the server shouldn't have to care whether the client process
is in 32-bit mode or 64-bit mode.  But maybe the only solution is to
pass through some sort of flag, as Peter Maydell has just suggested.

[PATCH v2] csky: Don't leak device tree node reference

[Yangtao Li]

of_find_node_by_type() acquires a reference to the node returned by it
and that reference needs to be dropped by its caller. setup_smp()
doesn't do that, so fix it by converting to for_each_of_cpu_node().

Signed-off-by: Yangtao Li 
---
 arch/csky/kernel/smp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/csky/kernel/smp.c b/arch/csky/kernel/smp.c
index 36ebaf9834e1..74d627300c55 100644
--- a/arch/csky/kernel/smp.c
+++ b/arch/csky/kernel/smp.c
@@ -138,7 +138,7 @@ void __init setup_smp(void)
struct device_node *node = NULL;
int cpu;
 
-   while ((node = of_find_node_by_type(node, "cpu"))) {
+   for_each_of_cpu_node(node) {
if (!of_device_is_available(node))
continue;
 
-- 
2.17.0

Re: [Qemu-devel] d_off field in struct dirent and 32-on-64 emulation

[Peter Maydell]

On Thu, 27 Dec 2018 at 17:19, Florian Weimer  wrote:
> We have a bit of an interesting problem with respect to the d_off
> field in struct dirent.
>
> When running a 64-bit kernel on certain file systems, notably ext4,
> this field uses the full 63 bits even for small directories (strace -v
> output, wrapped here for readability):
>
> getdents(3, [
>   {d_ino=1494304, d_off=3901177228673045825, d_reclen=40, 
> d_name="authorized_keys", d_type=DT_REG},
>   {d_ino=1494277, d_off=7491915799041650922, d_reclen=24, d_name=".", 
> d_type=DT_DIR},
>   {d_ino=1314655, d_off=9223372036854775807, d_reclen=24, d_name="..", 
> d_type=DT_DIR}
> ], 32768) = 88
>
> When running in 32-bit compat mode, this value is somehow truncated to
> 31 bits, for both the getdents and the getdents64 (!) system call (at
> least on i386).

Yes -- look for hash2pos() and friends in fs/ext4/dir.c.
The ext4 code in the kernel uses a 32 bit hash if (a) the kernel
is 32 bit (b) this is a compat syscall (b) some other bit of
the kernel asked it to via the FMODE_32BITHASH flag (currently only
NFS does that I think).

As you note, this causes breakage for userspace programs which
need to implement an API/ABI with 32-bit offset but which only
have access to the kernel's 64-bit offset API/ABI.

I think the best fix for this would be for the kernel to either
(a) consistently use a 32-bit hash or (b) to provide an API
so that userspace can use the FMODE_32BITHASH flag the way
that kernel-internal users already can.

I couldn't think of or find any existing way for userspace
to get the right results here, which is why
32-bit-guest-on-64-bit-host QEMU doesn't work on these filesystems
(depending on what exactly the guest's libc etc do).

> the 32-bit getdents system call emulation in a 64-bit qemu-user
> process would just silently truncate the d_off field as part of
> the translation, not reporting an error.
> [...]
> This truncation has always been a bug; it breaks telldir/seekdir
> at least in some cases.

Yes; you can't fit a quart into a pint pot, so if the guest
only handles 32-bit offsets then truncation is about all we
can do. This works fine if offsets are offsets, assuming the
directory isn't so enormous it would have broken the guest
anyway. I'm not aware of any issues with this other than the
oddball ext4 offsets-are-hashes situation -- could you expand
on the telldir/seekdir issue? (I suppose we should probably
make QEMU's syscall emulation layer return "no more entries"
rather than entries with truncated hashes.)

thanks
-- PMM

Re: [BUG]Uncalibrated TSC is not accurate enough as a time keeper

[Florian Weimer]

* Da Shi Cao:

> The cpu_khz and tsc_khz are now read directly by the cpuid
> instruction, and they are deemed to be very accurate. But this is not
> the case in our situation. The OS time lags behind about 8 seconds per
> hour. The CPU information is as follows:

Is virtualization involved?  Do you use a vendor kernel?

Note that  is more or less dead, and
your message to linux-kernel might get lost in the flood.

d_off field in struct dirent and 32-on-64 emulation

[Florian Weimer]

We have a bit of an interesting problem with respect to the d_off
field in struct dirent.

When running a 64-bit kernel on certain file systems, notably ext4,
this field uses the full 63 bits even for small directories (strace -v
output, wrapped here for readability):

getdents(3, [
  {d_ino=1494304, d_off=3901177228673045825, d_reclen=40, 
d_name="authorized_keys", d_type=DT_REG},
  {d_ino=1494277, d_off=7491915799041650922, d_reclen=24, d_name=".", 
d_type=DT_DIR},
  {d_ino=1314655, d_off=9223372036854775807, d_reclen=24, d_name="..", 
d_type=DT_DIR}
], 32768) = 88

When running in 32-bit compat mode, this value is somehow truncated to
31 bits, for both the getdents and the getdents64 (!) system call (at
least on i386).

In an effort to simplify support for future architectures which only
have the getdents64 system call, we changed glibc 2.28 to use the
getdents64 system call unconditionally, and perform translation if
necessary.  This translation is noteworthy because it includes
overflow checking for the d_ino and d_off members of struct dirent.
We did not initially observe a regression because the kernel performs
consistent d_off truncation (with the ext4 file system; small
directories do not show this issue on XFS), so the overflow check does
not fire.

However, both qemu-user and the 9p file system can run in such a way
that the kernel is entered from a 64-bit process, but the actual usage
is from a 32-bit process:

  

I think diagrammatically, this looks like this:

  guest process  (32-bit)
| getdents64, 32-bit UAPI
  qemu-user (64-bit)
| getdents, 64-bit UAPI
  host kernel (64-bit)

Or:

  guest process 
| getdents64, 32-bit UAPI
  guest kernel (64-bit)
| 9p over virtio (64-bit d_off in struct p9_dirent)
  qemu
| getdents, 64-bit UAPI
  host kernel (64-bit)

Back when we still called getdents, in the first case, the 32-bit
getdents system call emulation in a 64-bit qemu-user process would
just silently truncate the d_off field as part of the translation, not
reporting an error.  The second case is more complicated, and I have
not figured out where the truncation happens.

This truncation has always been a bug; it breaks telldir/seekdir at
least in some cases.  But use of telldir/seekdir is comparatively
rare.  In contrast, now that we detect d_off overflow in glibc,
readdir will always fail in the sketched configurations, which is bad.
(glibc exposes the d_off field to applications, and it cannot know
whether the application will use it or not, so there is no direct way
to restrict the overflow error to the telldir/seekdir use case.)

We could switch glibc to call getdents again if the system call is
available.  But that merely relies on the existence of the truncation
bug somewhere else in the file system stack.  This is why I don't
think it's the right solution, just the path of least resistance.

I don't want to reimplement the ext4 truncation behavior in glibc (it
doesn't look like a straightforward truncation), and it wouldn't work
for the second scenario where we see the 9p file system in the 32-bit
glibc, not the ext4 file system.  So that's not a good solution.

There is another annoying aspect: The standards expose d_off through
the telldir function, and that returns long int on all architectures
(not off_t, so unchanged by _FILE_OFFSET_BITS).  That's mostly a
userspace issue and thus needing different steps to resolve (possibly
standards action).

Any suggestions how to solve this?  Why does the kernel return
different d_off values for 32-bit and 64-bit processes even when using
getdents64, for the same directory?

[PATCH] Staging: emxx_udc: Switch to the gpio descriptor interface

[Nishad Kamdar]

Convert VBUS GPIO to use GPIO descriptors from 
and stop using the old GPIO API.

Signed-off-by: Nishad Kamdar 
---
 drivers/staging/emxx_udc/emxx_udc.c | 31 +++--
 drivers/staging/emxx_udc/emxx_udc.h |  2 ++
 2 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/drivers/staging/emxx_udc/emxx_udc.c 
b/drivers/staging/emxx_udc/emxx_udc.c
index 8e8f57c4f029..a913d40f0801 100644
--- a/drivers/staging/emxx_udc/emxx_udc.c
+++ b/drivers/staging/emxx_udc/emxx_udc.c
@@ -27,7 +27,7 @@
 #include 
 
 #include 
-#include 
+#include 
 
 #include "emxx_udc.h"
 
@@ -2220,7 +2220,7 @@ static inline void _nbu2ss_check_vbus(struct nbu2ss_udc 
*udc)
mdelay(VBUS_CHATTERING_MDELAY); /* wait (ms) */
 
/* VBUS ON Check*/
-   reg_dt = gpio_get_value(VBUS_VALUE);
+   reg_dt = gpiod_get_value(vbus_gpio);
if (reg_dt == 0) {
udc->linux_suspended = 0;
 
@@ -2247,7 +2247,7 @@ static inline void _nbu2ss_check_vbus(struct nbu2ss_udc 
*udc)
}
} else {
mdelay(5);  /* wait (5ms) */
-   reg_dt = gpio_get_value(VBUS_VALUE);
+   reg_dt = gpiod_get_value(vbus_gpio);
if (reg_dt == 0)
return;
 
@@ -2311,7 +2311,7 @@ static inline void _nbu2ss_int_usb_suspend(struct 
nbu2ss_udc *udc)
u32 reg_dt;
 
if (udc->usb_suspended == 0) {
-   reg_dt = gpio_get_value(VBUS_VALUE);
+   reg_dt = gpiod_get_value(vbus_gpio);
 
if (reg_dt == 0)
return;
@@ -2351,7 +2351,7 @@ static irqreturn_t _nbu2ss_udc_irq(int irq, void *_udc)
struct nbu2ss_udc   *udc = (struct nbu2ss_udc *)_udc;
struct fc_regs __iomem *preg = udc->p_regs;
 
-   if (gpio_get_value(VBUS_VALUE) == 0) {
+   if (gpiod_get_value(vbus_gpio) == 0) {
_nbu2ss_writel(>USB_INT_STA, ~USB_INT_STA_RW);
_nbu2ss_writel(>USB_INT_ENA, 0);
return IRQ_HANDLED;
@@ -2360,7 +2360,7 @@ static irqreturn_t _nbu2ss_udc_irq(int irq, void *_udc)
spin_lock(>lock);
 
for (;;) {
-   if (gpio_get_value(VBUS_VALUE) == 0) {
+   if (gpiod_get_value(vbus_gpio) == 0) {
_nbu2ss_writel(>USB_INT_STA, ~USB_INT_STA_RW);
_nbu2ss_writel(>USB_INT_ENA, 0);
status = 0;
@@ -2750,7 +2750,7 @@ static int nbu2ss_ep_fifo_status(struct usb_ep *_ep)
 
preg = udc->p_regs;
 
-   data = gpio_get_value(VBUS_VALUE);
+   data = gpiod_get_value(vbus_gpio);
if (data == 0)
return -EINVAL;
 
@@ -2790,7 +2790,7 @@ static void  nbu2ss_ep_fifo_flush(struct usb_ep *_ep)
return;
}
 
-   data = gpio_get_value(VBUS_VALUE);
+   data = gpiod_get_value(vbus_gpio);
if (data == 0)
return;
 
@@ -2832,7 +2832,7 @@ static int nbu2ss_gad_get_frame(struct usb_gadget 
*pgadget)
}
 
udc = container_of(pgadget, struct nbu2ss_udc, gadget);
-   data = gpio_get_value(VBUS_VALUE);
+   data = gpiod_get_value(vbus_gpio);
if (data == 0)
return -EINVAL;
 
@@ -2854,7 +2854,7 @@ static int nbu2ss_gad_wakeup(struct usb_gadget *pgadget)
 
udc = container_of(pgadget, struct nbu2ss_udc, gadget);
 
-   data = gpio_get_value(VBUS_VALUE);
+   data = gpiod_get_value(vbus_gpio);
if (data == 0) {
dev_warn(>dev, "VBUS LEVEL = %d\n", data);
return -EINVAL;
@@ -3119,12 +3119,13 @@ static int nbu2ss_drv_probe(struct platform_device 
*pdev)
}
 
/* VBUS Interrupt */
-   irq_set_irq_type(INT_VBUS, IRQ_TYPE_EDGE_BOTH);
-   status = request_irq(INT_VBUS,
+   vbus_irq = gpiod_to_irq(vbus_gpio);
+   irq_set_irq_type(vbus_irq, IRQ_TYPE_EDGE_BOTH);
+   status = request_irq(vbus_irq,
 _nbu2ss_vbus_irq, IRQF_SHARED, driver_name, udc);
 
if (status != 0) {
-   dev_err(udc->dev, "request_irq(INT_VBUS) failed\n");
+   dev_err(udc->dev, "request_irq(vbus_irq) failed\n");
return status;
}
 
@@ -3160,7 +3161,7 @@ static int nbu2ss_drv_remove(struct platform_device *pdev)
}
 
/* Interrupt Handler - Release */
-   free_irq(INT_VBUS, udc);
+   free_irq(vbus_irq, udc);
 
return 0;
 }
@@ -3201,7 +3202,7 @@ static int nbu2ss_drv_resume(struct platform_device *pdev)
if (!udc)
return 0;
 
-   data = gpio_get_value(VBUS_VALUE);
+   data = gpiod_get_value(vbus_gpio);
if (data) {
udc->vbus_active = 1;
udc->devstate = USB_STATE_POWERED;
diff --git a/drivers/staging/emxx_udc/emxx_udc.h 
b/drivers/staging/emxx_udc/emxx_udc.h
index e28a74da9633..b8c3dee5626c 100644
--- a/drivers/staging/emxx_udc/emxx_udc.h
+++ b/drivers/staging/emxx_udc/emxx_udc.h

[RFC PATCH 1/1] PM / Domains: Add multi PM domains support for attach_dev

[Aisheng Dong]

Currently attach_dev() in power domain infrastructure still does
not support multi domains case as the struct device *dev passed
down from genpd_dev_pm_attach_by_id() is a virtual PD device, it
does not help for parsing the real device information from device
tree, e.g. Device/Power IDs, Clocks and it's unware of which real
power domain the device should attach.

Extend the framework a bit to store the multi PM domains information
in per-device struct generic_pm_domain_data, then power domain driver
could retrieve it for necessary operations during attach_dev().

Two new APIs genpd_is_mpd_device() and dev_gpd_mpd_data() are also
introduced to ease the driver operation.

Cc: "Rafael J. Wysocki" 
Cc: Kevin Hilman 
Cc: Ulf Hansson 
Cc: Greg Kroah-Hartman 
Signed-off-by: Dong Aisheng 
---
This patch is a follow-up work of the earlier discussion with Ulf Hansson
about the multi PM domains support for the attach_dev() function [1].
After a bit more thinking, this is a less intrusive implementation with
the mininum impact on the exist function definitions and calling follows.
One known little drawback is that we have to use the device driver private
data (device.drvdata) to pass down the multi domains information in a
earlier time. However, as multi PD devices are created by domain framework,
this seems to be safe to use it in domain core code as device driver
is not likely going to use it.
Anyway, if any better ideas, please let me know.

With the two new APIs, the using can be simply as:
static int xxx_attach_dev(struct generic_pm_domain *domain,
  struct device *dev)
{
...
if (genpd_is_mpd_device(dev)) {
mpd_data = dev_gpd_mpd_data(dev);
np = mpd_data->parent->of_node;
idx = mpd_data->index;
//dts parsing
...
}
...
}

[1] https://patchwork.kernel.org/patch/10658669/
---
 drivers/base/power/domain.c | 31 +++
 include/linux/pm_domain.h   | 23 +++
 2 files changed, 54 insertions(+)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 7f38a92..1aa0918 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -1343,6 +1343,9 @@ static struct generic_pm_domain_data 
*genpd_alloc_dev_data(struct device *dev,
gpd_data->td.effective_constraint_ns = 
PM_QOS_RESUME_LATENCY_NO_CONSTRAINT_NS;
gpd_data->nb.notifier_call = genpd_dev_pm_qos_notifier;
 
+   if (genpd_is_mpd_device(dev))
+   gpd_data->mpd_data = dev_get_drvdata(dev);
+
spin_lock_irq(>power.lock);
 
if (dev->power.subsys_data->domain_data) {
@@ -2179,6 +2182,7 @@ EXPORT_SYMBOL_GPL(of_genpd_remove_last);
 
 static void genpd_release_dev(struct device *dev)
 {
+   kfree(dev->driver_data);
kfree(dev);
 }
 
@@ -2320,6 +2324,20 @@ int genpd_dev_pm_attach(struct device *dev)
 EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);
 
 /**
+ * genpd_is_mpd_device - Check if a device is associated with multi PM domains
+ * @dev: Device to check.
+ */
+
+bool genpd_is_mpd_device(struct device *dev)
+{
+   if (!dev || (dev && !dev->bus))
+   return false;
+
+   return dev->bus == _bus_type;
+};
+EXPORT_SYMBOL_GPL(genpd_is_mpd_device);
+
+/**
  * genpd_dev_pm_attach_by_id - Associate a device with one of its PM domains.
  * @dev: The device used to lookup the PM domain.
  * @index: The index of the PM domain.
@@ -2338,6 +2356,7 @@ EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);
 struct device *genpd_dev_pm_attach_by_id(struct device *dev,
 unsigned int index)
 {
+   struct pm_domain_mpd_data *mpd_data;
struct device *genpd_dev;
int num_domains;
int ret;
@@ -2366,6 +2385,18 @@ struct device *genpd_dev_pm_attach_by_id(struct device 
*dev,
return ERR_PTR(ret);
}
 
+   /* Allocate multi power domains data */
+   mpd_data = kzalloc(sizeof(*mpd_data), GFP_KERNEL);
+   if (!mpd_data) {
+   device_unregister(genpd_dev);
+   return ERR_PTR(-ENOMEM);
+   }
+
+   mpd_data->parent = dev;
+   mpd_data->index = index;
+
+   dev_set_drvdata(genpd_dev, mpd_data);
+
/* Try to attach the device to the PM domain at the specified index. */
ret = __genpd_dev_pm_attach(genpd_dev, dev->of_node, index, false);
if (ret < 1) {
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 3b5d728..106d4e7 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -144,6 +144,11 @@ struct gpd_timing_data {
bool cached_suspend_ok;
 };
 
+struct pm_domain_mpd_data {
+   struct device *parent;
+   unsigned int index;
+};
+
 struct pm_domain_data {
struct list_head list_node;
struct device *dev;
@@ -151,6 +156,7 @@ struct pm_domain_data {
 
 struct generic_pm_domain_data {
struct pm_domain_data 

Re: [PATCH v2 0/3] x86: kprobes: Show correct blaclkist in debugfs

[Andrea Righi]

On Tue, Dec 18, 2018 at 06:24:35PM +0100, Andrea Righi wrote:
> On Tue, Dec 18, 2018 at 01:50:26PM +0900, Masami Hiramatsu wrote:
> ...
> > > Side question: there are certain symbols in arch/x86/xen that should be
> > > blacklisted explicitly, because they're non-attachable.
> > > 
> > > More exactly, all functions defined in arch/x86/xen/spinlock.c,
> > > arch/x86/xen/time.c and arch/x86/xen/irq.c.
> > > 
> > > The reason is that these files are compiled without -pg to allow the
> > > usage of ftrace within a Xen domain apparently (from
> > > arch/x86/xen/Makefile):
> > > 
> > >  ifdef CONFIG_FUNCTION_TRACER
> > >  # Do not profile debug and lowlevel utilities
> > >  CFLAGS_REMOVE_spinlock.o = -pg
> > >  CFLAGS_REMOVE_time.o = -pg
> > >  CFLAGS_REMOVE_irq.o = -pg
> > >  endif
> > 
> > 
> > Actually, the reason why you can not probe those functions via
> > tracing/kprobe_events is just a side effect. You can probe it if you
> > write a kprobe module. Since the kprobe_events depends on some ftrace
> > tracing functions, it sometimes cause a recursive call problem. To avoid
> > this issue, I have introduced a CONFIG_KPROBE_EVENTS_ON_NOTRACE, see
> > commit 45408c4f9250 ("tracing: kprobes: Prohibit probing on notrace 
> > function").
> > 
> > If you set CONFIG_KPROBE_EVENTS_ON_NOTRACE=n, you can continue putting 
> > probes
> > on Xen spinlock functions too.
> 
> OK.
> 
> > 
> > > Do you see a nice and clean way to blacklist all these functions
> > > (something like arch_populate_kprobe_blacklist()), or should we just
> > > flag all of them explicitly with NOKPROBE_SYMBOL()?
> > 
> > As I pointed, you can probe it via your own kprobe module. Like systemtap,
> > you still can probe it. The blacklist is for "kprobes", not for 
> > "kprobe_events".
> > (Those are used to same, but since the above commit, those are different 
> > now)
> > 
> > I think the most sane solution is, identifying which (combination of) 
> > functions
> > in ftrace (kernel/trace/*) causes a problem, marking those 
> > NOKPROBE_SYMBOL() and
> > removing CONFIG_KPROBE_EVENTS_ON_NOTRACE.

I'm planning to spend a little bit more time on this and see if I can
identify the problematic ftrace functions and eventually drop
CONFIG_KPROBE_EVENTS_ON_NOTRACE, following the sane solution.

However, in the meantime, with the following patch I've been able to get
a more reliable kprobes blacklist and show also the notrace functions in
debugfs when CONFIG_KPROBE_EVENTS_ON_NOTRACE is off.

It's probably ugly and inefficient, because it's iterating over all
symbols in x86's arch_populate_kprobe_blacklist(), but it seems to work
for my specific use case, so I thought it shouldn't be bad to share it,
just in case (maybe someone else is also interested).

Thanks,

From: Andrea Righi 
Subject: [PATCH] x86: kprobes: automatically blacklist all non-traceable 
functions

Iterate over all symbols to detect those that are non-traceable and
blacklist them.

Signed-off-by: Andrea Righi 
---
 arch/x86/kernel/kprobes/core.c | 11 +--
 kernel/kprobes.c   | 22 --
 2 files changed, 29 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
index 4ba75afba527..8cc7191ba3f9 100644
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -1026,10 +1026,17 @@ int kprobe_fault_handler(struct pt_regs *regs, int 
trapnr)
 }
 NOKPROBE_SYMBOL(kprobe_fault_handler);
 
+static int do_kprobes_arch_blacklist(void *data, const char *name,
+struct module *mod, unsigned long addr)
+{
+   if (arch_within_kprobe_blacklist(addr))
+   kprobe_add_ksym_blacklist(addr);
+   return 0;
+}
+
 int __init arch_populate_kprobe_blacklist(void)
 {
-   return kprobe_add_area_blacklist((unsigned long)__entry_text_start,
-(unsigned long)__entry_text_end);
+   return kallsyms_on_each_symbol(do_kprobes_arch_blacklist, NULL);
 }
 
 int __init arch_init_kprobes(void)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index f4ddfdd2d07e..2e824cd536ba 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -1389,11 +1389,29 @@ static int register_aggr_kprobe(struct kprobe *orig_p, 
struct kprobe *p)
return ret;
 }
 
+#if defined(CONFIG_KPROBES_ON_FTRACE) && \
+   !defined(CONFIG_KPROBE_EVENTS_ON_NOTRACE)
+static bool within_notrace(unsigned long addr)
+{
+   unsigned long offset, size;
+
+   if (!kallsyms_lookup_size_offset(addr, , ))
+   return true;
+   return !ftrace_location_range(addr - offset, addr - offset + size);
+}
+#else
+static bool within_notrace(unsigned long addr)
+{
+   return false;
+}
+#endif
+
 bool __weak arch_within_kprobe_blacklist(unsigned long addr)
 {
/* The __kprobes marked functions and entry code must not be probed */
-   return addr >= (unsigned long)__kprobes_text_start &&
-  addr < (unsigned 

Re: [PATCH] KVM: X86: Fix scan ioapic use-before-initialization

[Linus Torvalds]

On Thu, Dec 27, 2018 at 6:28 AM Dmitry Vyukov  wrote:
>
> Lots of kernel bug reports routinely get lost on mailing lists, which is bad.

Nobody reads the kernel mailing list directly - there's just too much traffic.

And honestly, even fewer people then read the syzbot reports, because
they are so illegible and inhuman. They're better than they used to
be, but they are still basically impossible to parse without a lot of
effort.

And no, syzbot didn't really report the bug with any specificity - it
wasn't clear *which* commit it was that caused it, so reading that
syzbot report, at no point was it then obvious that the original patch
had issues.

See the problem?

So the issue seems to be that syzbot is simply not useful enough. It's
output is too rough for people to take it seriously. You see how the
report by Wei Wu then got traction, because Wei took a syzbot report
and added some human background and distilled it down to not be
"here's a big dump of random information".

So I suspect syzbot should strive to make for a much stronger
signal-to-noise ratio. For example, if syzbot had actually bisected
the bug it reported, that would have been quite a strong signal.

Compare these two emails:


https://lore.kernel.org/lkml/1542702858-4318-1-git-send-email-wanpen...@tencent.com/
https://lore.kernel.org/lkml/1c7a5c0573607...@google.com/

and note the absolutely huge difference in actual *information* (as
opposed to raw data).

Any possibility that syzbot would actually do the bisection once it
finds a problem, and write a report based on the commit that caused
the problem rather than just a problem dump?

 Linus

Re: [PATCH] csky: fix refcount leak in setup_smp()

[Guo Ren]

Hi Li,

On Thu, Dec 27, 2018 at 11:27:11AM -0500, Yangtao Li wrote:
> The of_find_node_by_type() returns a node pointer with refcount
> incremented, but there is the lack of use of the of_node_put() when
> done. Add the missing of_node_put() to release the refcount.
> 
> Signed-off-by: Yangtao Li 
> ---
>  arch/csky/kernel/smp.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/csky/kernel/smp.c b/arch/csky/kernel/smp.c
> index 36ebaf9834e1..adec56df613b 100644
> --- a/arch/csky/kernel/smp.c
> +++ b/arch/csky/kernel/smp.c
> @@ -139,11 +139,17 @@ void __init setup_smp(void)
>   int cpu;
>  
>   while ((node = of_find_node_by_type(node, "cpu"))) {
> - if (!of_device_is_available(node))
> + if (!of_device_is_available(node)) {
> + of_node_put(node);
>   continue;
> + }
>  
> - if (of_property_read_u32(node, "reg", ))
> + if (of_property_read_u32(node, "reg", )) {
> + of_node_put(node);
>   continue;
> + }
> +
> + of_node_put(node);
If success, of_node_put ?
>  
>   if (cpu >= NR_CPUS)
Here need a of_node_put()?
>   continue;

Can you use for_each_of_cpu_node() for the patch?

Thx
 Guo Ren

Re: [PATCH] sched: fix infinity loop in update_blocked_averages

[Vincent Guittot]

On Thu, 27 Dec 2018 at 17:40, Sargun Dhillon  wrote:
>
> On Thu, Dec 27, 2018 at 5:23 AM Vincent Guittot
>  wrote:
> >
> > Adding Sargun and Dimitry who faced similar problem
> > Adding Tejun
> >
> > On Thu, 27 Dec 2018 at 11:21, Vincent Guittot
> >  wrote:
> > >
> > > Le Thursday 27 Dec 2018 à 10:21:53 (+0100), Vincent Guittot a écrit :
> > > > Hi Xie,
> > > >
> > > > On Thu, 27 Dec 2018 at 03:57, Xie XiuQi  wrote:
> > > > >
> > > > > Zhepeng Xie report a bug, there is a infinity loop in
> > > > > update_blocked_averages().
> > > > >
> > > > > PID: 14233  TASK: 800b2de08fc0  CPU: 1   COMMAND: "docker"
> > > > >  #0 [2213b9d0] update_blocked_averages at 0811e4a8
> > > > >  #1 [2213ba60] pick_next_task_fair at 0812a3b4
> > > > >  #2 [2213baf0] __schedule at 08deaa88
> > > > >  #3 [2213bb70] schedule at 08deb1b8
> > > > >  #4 [2213bb80] futex_wait_queue_me at 08180754
> > > > >  #5 [2213bbd0] futex_wait at 0818192c
> > > > >  #6 [2213bd00] do_futex at 08183ee4
> > > > >  #7 [2213bde0] __arm64_sys_futex at 08184398
> > > > >  #8 [2213be60] el0_svc_common at 080979ac
> > > > >  #9 [2213bea0] el0_svc_handler at 08097a6c
> > > > >  #10 [2213bff0] el0_svc at 08084044
> > > > >
> > > > > rq->tmp_alone_branch introduced in 4.10, used to point to
> > > > > the new beg of the list. If this cfs_rq is deleted somewhere
> > > > > else, then the tmp_alone_branch will be illegal and cause
> > > > > a list_add corruption.
> > > >
> > > > shouldn't all the sequence  be protected by rq_lock ?
> > > >
> > > >
> > > > >
> > > > > (When enabled DEBUG_LIST, we fould this list_add corruption)
> > > > >
> > > > > [ 2546.741103] list_add corruption. next->prev should be prev
> > > > > (800b4d61ad40), but was 800ba434fa38. (next=800b6a95e740).
> > > > > [ 2546.741130] [ cut here ]
> > > > > [ 2546.741132] kernel BUG at lib/list_debug.c:25!
> > > > > [ 2546.741136] Internal error: Oops - BUG: 0 [#1] SMP
> > > > > [ 2546.742870] CPU: 1 PID: 29428 Comm: docker-runc Kdump: loaded 
> > > > > Tainted: G E  4.19.5-1.aarch64 #1
> > > > > [ 2546.745415] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 
> > > > > 02/06/2015
> > > > > [ 2546.747402] pstate: 4085 (nZcv daIf -PAN -UAO)
> > > > > [ 2546.749015] pc : __list_add_valid+0x50/0x90
> > > > > [ 2546.750485] lr : __list_add_valid+0x50/0x90
> > > > > [ 2546.751975] sp : 1b5eb910
> > > > > [ 2546.753286] x29: 1b5eb910 x28: 800abacf
> > > > > [ 2546.754976] x27: 1b5ebbb0 x26: 0957
> > > > > [ 2546.756665] x25: 0960d000 x24: 0250f41ca8f8
> > > > > [ 2546.758366] x23: 800b6a95e740 x22: 800b4d61ad40
> > > > > [ 2546.760066] x21: 800b4d61ad40 x20: 800ba434f080
> > > > > [ 2546.761742] x19: 800b4d61ac00 x18: 
> > > > > [ 2546.763425] x17:  x16: 
> > > > > [ 2546.765089] x15: 09570748 x14: 662073617720
> > > > > [ 2546.766755] x13: 747562202c293034 x12: 6461313664346230
> > > > > [ 2546.768429] x11: 30382820 x10: 
> > > > > [ 2546.770124] x9 : 0001 x8 : 09f34a0f
> > > > > [ 2546.771831] x7 :  x6 : 250d
> > > > > [ 2546.773525] x5 :  x4 : 
> > > > > [ 2546.775227] x3 :  x2 : 70ef7f624013ca00
> > > > > [ 2546.776929] x1 :  x0 : 0075
> > > > > [ 2546.778623] Process docker-runc (pid: 29428, stack limit = 
> > > > > 0x293494a2)
> > > > > [ 2546.780742] Call trace:
> > > > > [ 2546.781955]  __list_add_valid+0x50/0x90
> > > > > [ 2546.783469]  enqueue_entity+0x4a0/0x6e8
> > > > > [ 2546.784957]  enqueue_task_fair+0xac/0x610
> > > > > [ 2546.786502]  sched_move_task+0x134/0x178
> > > > > [ 2546.787993]  cpu_cgroup_attach+0x40/0x78
> > > > > [ 2546.789540]  cgroup_migrate_execute+0x378/0x3a8
> > > > > [ 2546.791169]  cgroup_migrate+0x6c/0x90
> > > > > [ 2546.792663]  cgroup_attach_task+0x148/0x238
> > > > > [ 2546.794211]  __cgroup1_procs_write.isra.2+0xf8/0x160
> > > > > [ 2546.795935]  cgroup1_procs_write+0x38/0x48
> > > > > [ 2546.797492]  cgroup_file_write+0xa0/0x170
> > > > > [ 2546.799010]  kernfs_fop_write+0x114/0x1e0
> > > > > [ 2546.800558]  __vfs_write+0x60/0x190
> > > > > [ 2546.801977]  vfs_write+0xac/0x1c0
> > > > > [ 2546.803341]  ksys_write+0x6c/0xd8
> > > > > [ 2546.804674]  __arm64_sys_write+0x24/0x30
> > > > > [ 2546.806146]  el0_svc_common+0x78/0x100
> > > > > [ 2546.807584]  el0_svc_handler+0x38/0x88
> > > > > [ 2546.809017]  el0_svc+0x8/0xc
> > > > >
> > > >
> > > > Have you got more details about the sequence that generates this bug ?
> > > > Is it easily reproducible ?
> > > >
> > > > > In this patch, we move rq->tmp_alone_branch point to its prev before 
> > > > > delete it

Re: [PATCH 1/1] mm/page_alloc: add a warning about high order allocations

[Michal Hocko]

On Thu 27-12-18 16:05:18, Konstantin Khorenko wrote:
> On 12/26/2018 11:40 AM, Michal Hocko wrote:
> > Appart from general comments as a reply to the cover (btw. this all
> > should be in the changelog because this is the _why_ part of the
> > justification which should be _always_ part of the changelog).
> 
> Thank you, will add in the next version of the patch alltogether
> with other changes if any.
> 
> > On Tue 25-12-18 18:39:27, Konstantin Khorenko wrote:
> > [...]
> >> +config WARN_HIGH_ORDER
> >> +  bool "Enable complains about high order memory allocations"
> >> +  depends on !LOCKDEP
> >
> > Why?
> 
> LOCKDEP makes structures big, so if we see a high order allocation warning
> on a debug kernel with lockdep, it does not give us a lot - lockdep enabled
> kernel performance is not our target.
> i can remove !LOCKDEP dependence here, but then need to adjust default
> warning level i think, or logs will be spammed.

OK, I see but this just points to how this is not really a suitable
solution for the problem you are looking for.

> >> +static __always_inline void warn_high_order(int order, gfp_t gfp_mask)
> >> +{
> >> +  static atomic_t warn_count = ATOMIC_INIT(32);
> >> +
> >> +  if (order >= warn_order && !(gfp_mask & __GFP_NOWARN))
> >> +  WARN(atomic_dec_if_positive(_count) >= 0,
> >> +   "order %d >= %d, gfp 0x%x\n",
> >> +   order, warn_order, gfp_mask);
> >> +}
> >
> > We do have ratelimit functionality, so why cannot you use it?
> 
> Well, my idea was to really shut up the warning after some number of messages
> (if a node is in production and its uptime, say, a year, i don't want to see
> many warnings in logs, first several is enough - let's fix them first).

OK, but it is quite likely that the system is perfectly healthy and
unfragmented after fresh boot when doing a large order allocations is
perfectly fine. Note that it is smaller order allocations that generate
fragmentation in general.
-- 
Michal Hocko
SUSE Labs

[PATCH] h8300: pci: Remove local declaration of pcibios_penalize_isa_irq

[Guenter Roeck]

h8300 builds fail with:

In file included from drivers/of/address.c:11:
include/linux/pci.h:1966:20: error: redefinition of 'pcibios_penalize_isa_irq'

This is because CONFIG_PCI is not enabled, and pcibios_penalize_isa_irq()
is now declared as inline static function in generic code if this is the
case. Since h8300 does not support PCI to start with, fix the problem by
removing the architecture specific pci.h.

Fixes: 5d32a66541c46 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set")
Cc: Sinan Kaya 
Cc: Bjorn Helgaas 
Signed-off-by: Guenter Roeck 
---
 arch/h8300/include/asm/Kbuild |  1 +
 arch/h8300/include/asm/pci.h  | 18 --
 2 files changed, 1 insertion(+), 18 deletions(-)
 delete mode 100644 arch/h8300/include/asm/pci.h

diff --git a/arch/h8300/include/asm/Kbuild b/arch/h8300/include/asm/Kbuild
index a5d0b2991f47..cd400d353d18 100644
--- a/arch/h8300/include/asm/Kbuild
+++ b/arch/h8300/include/asm/Kbuild
@@ -33,6 +33,7 @@ generic-y += mmu.h
 generic-y += mmu_context.h
 generic-y += module.h
 generic-y += parport.h
+generic-y += pci.h
 generic-y += percpu.h
 generic-y += pgalloc.h
 generic-y += preempt.h
diff --git a/arch/h8300/include/asm/pci.h b/arch/h8300/include/asm/pci.h
deleted file mode 100644
index d4d345a52092..
--- a/arch/h8300/include/asm/pci.h
+++ /dev/null
@@ -1,18 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef _ASM_H8300_PCI_H
-#define _ASM_H8300_PCI_H
-
-/*
- * asm-h8300/pci.h - H8/300 specific PCI declarations.
- *
- * Yoshinori Sato 
- */
-
-#define pcibios_assign_all_busses()0
-
-static inline void pcibios_penalize_isa_irq(int irq, int active)
-{
-   /* We don't do dynamic PCI IRQ allocation */
-}
-
-#endif /* _ASM_H8300_PCI_H */
-- 
2.7.4

Re: [RFC PATCH 0/1] mm: add a warning about high order allocations

[Michal Hocko]

On Thu 27-12-18 15:18:54, Konstantin Khorenko wrote:
> Hi Michal,
> 
> thank you very much for your questions, please see my notes below.
> 
> On 12/26/2018 11:35 AM, Michal Hocko wrote:
> > On Tue 25-12-18 18:39:26, Konstantin Khorenko wrote:
> >> Q: Why do we need to bother at all?
> >> A: If a node is highly loaded and its memory is significantly fragmented
> >> (unfortunately almost any node with serious load has highly fragmented 
> >> memory)
> >> then any high order memory allocation can trigger massive memory shrink and
> >> result in quite a big allocation latency. And the node becomes less 
> >> responsive
> >> and users don't like it.
> >> The ultimate solution here is to get rid of large allocations, but we need 
> >> an
> >> instrument to detect them.
> >
> > Can you point to an example of the problem you are referring here? At
> > least for costly orders we do bail out early and try to not cause
> > massive reclaim. So what is the order that you are concerned about?
> 
> Well, this is the most difficult question to answer.
> Unfortunately i don't have a reproducer for that, usually we get into 
> situation
> when someone experiences significant node slowdown, nodes most often have a 
> lot of RAM,
> we check what is going on there and see the node is busy with reclaim.
> And almost every time the reason was - fragmented memory and high order 
> allocations.
> Mostly of 2nd and 3rd (which is still considered not costly) order.
> 
> Recent related issues we faced were about FUSE dev pipe:
> d6d931adce11 ("fuse: use kvmalloc to allocate array of pipe_buffer structs.")
> 
> and about bnx driver + mtu 9000 which for each packet required page of 2nd 
> order
> (and it even failed sometimes, though it was not the root cause):
>  kswapd0: page allocation failure: order:2, mode:0x4020
>  Call Trace:
>  dump_stack+0x19/0x1b
>  warn_alloc_failed+0x110/0x180
>  __alloc_pages_nodemask+0x7bf/0xc60
>  alloc_pages_current+0x98/0x110
>  kmalloc_order+0x18/0x40
>  kmalloc_order_trace+0x26/0xa0
>  __kmalloc+0x279/0x290
>  bnx2x_frag_alloc.isra.61+0x2a/0x40 [bnx2x]
>  bnx2x_rx_int+0x227/0x17c0 [bnx2x]
>  bnx2x_poll+0x1dd/0x260 [bnx2x]
>  net_rx_action+0x179/0x390
>  __do_softirq+0x10f/0x2aa
>  call_softirq+0x1c/0x30
>  do_softirq+0x65/0xa0
>  irq_exit+0x105/0x110
>  do_IRQ+0x56/0xe0
>  common_interrupt+0x6d/0x6d
> 
> And as both places were called very often - the system latency was high.
>
> This warning can be also used to catch allocation of 4th order and higher 
> which may
> easily fail. Those places which are ready to get allocation errors and have
> fallbacks are marked with __GFP_NOWARN.

This is not true in general, though.

[...]
> But after it's done and there are no (almost) unmarked high order allocations 
> -
> why not? This will reveal new cases of high order allocations soon.

There will always be legitimate high order allocations. I believe that
for your particular use case it is much better to simply enable reclaim
and page allocator tracepoints which will give you not only the source
of the allocation but also a much better picture

> i think people who run systems with "kernel.panic_on_warn" enabled do care
> about reporting issues.

You surely do not want to put the system down just because of the high
order allocation though, right?

> >> Q: Why compile time config option?
> >> A: In order not to decrease the performance even a bit in case someone 
> >> does not
> >> want to hunt for large allocations.
> >> In an ideal life i'd prefer this check/warning is enabled by default and 
> >> may be
> >> even without a config option so it works on every node. Once we find and 
> >> rework
> >> or mark all large allocations that would be good by default. Until that 
> >> though
> >> it will be noisy.
> >
> > So who is going to enable this option?
> 
> At the beginning - people who want to debug kernel and verify their fallbacks 
> on
> memory allocations failures in the code or just speed up their code on nodes
> with fragmented memory - for 2nd and 3rd orders.
> 
> mm performance issues are tough, you know, and this is just another way to
> gain more performance. It won't avoid the necessity of digging mm for sure,
> but might decrease the pressure level.

But the warning alone will not give us useful information I am afraid.
It will only give us, there are warnings but not whether those are
actually a problem or not. So I really believe that using existing
tracepoints or add some that will fill missing gaps will be much more
better long term. And we do not have to add another config and touch the
code as a bonus.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH] mm: compaction.c: Propagate return value upstream

[Randy Dunlap]

On 12/26/18 7:50 PM, Matthew Wilcox wrote:
> On Wed, Dec 26, 2018 at 01:42:56PM -0600, Aditya Pakki wrote:
>> In sysctl_extfrag_handler(), proc_dointvec_minmax() can return an
>> error. The fix propagates the error upstream in case of failure.
> 
> Why not just ...

Yes, this change (below) makes sense to me.

> Mel, Randy?  You seem to have been the prime instigators on this.

I expect that all I did was move the location of the source code lines of
the sysctl, but that is just a guess, based on this commit message:
  [randy.dun...@oracle.com: Fix build errors when proc fs is not configured]

> diff --git a/include/linux/compaction.h b/include/linux/compaction.h
> index 68250a57aace..70d0256edd31 100644
> --- a/include/linux/compaction.h
> +++ b/include/linux/compaction.h
> @@ -88,8 +88,6 @@ extern int sysctl_compact_memory;
>  extern int sysctl_compaction_handler(struct ctl_table *table, int write,
>   void __user *buffer, size_t *length, loff_t *ppos);
>  extern int sysctl_extfrag_threshold;
> -extern int sysctl_extfrag_handler(struct ctl_table *table, int write,
> - void __user *buffer, size_t *length, loff_t *ppos);
>  extern int sysctl_compact_unevictable_allowed;
>  
>  extern int fragmentation_index(struct zone *zone, unsigned int order);
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index 5fc724e4e454..e9c69247fc29 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -1439,7 +1439,7 @@ static struct ctl_table vm_table[] = {
>   .data   = _extfrag_threshold,
>   .maxlen = sizeof(int),
>   .mode   = 0644,
> - .proc_handler   = sysctl_extfrag_handler,
> + .proc_handler   = proc_dointvec_minmax,
>   .extra1 = _extfrag_threshold,
>   .extra2 = _extfrag_threshold,
>   },
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 7c607479de4a..80b941d9b6e7 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -1876,14 +1876,6 @@ int sysctl_compaction_handler(struct ctl_table *table, 
> int write,
>   return 0;
>  }
>  
> -int sysctl_extfrag_handler(struct ctl_table *table, int write,
> - void __user *buffer, size_t *length, loff_t *ppos)
> -{
> - proc_dointvec_minmax(table, write, buffer, length, ppos);
> -
> - return 0;
> -}
> -
>  #if defined(CONFIG_SYSFS) && defined(CONFIG_NUMA)
>  static ssize_t sysfs_compact_node(struct device *dev,
>   struct device_attribute *attr,
> 


-- 
~Randy

Re: [PATCH] sched: fix infinity loop in update_blocked_averages

[Sargun Dhillon]

On Thu, Dec 27, 2018 at 5:23 AM Vincent Guittot
 wrote:
>
> Adding Sargun and Dimitry who faced similar problem
> Adding Tejun
>
> On Thu, 27 Dec 2018 at 11:21, Vincent Guittot
>  wrote:
> >
> > Le Thursday 27 Dec 2018 à 10:21:53 (+0100), Vincent Guittot a écrit :
> > > Hi Xie,
> > >
> > > On Thu, 27 Dec 2018 at 03:57, Xie XiuQi  wrote:
> > > >
> > > > Zhepeng Xie report a bug, there is a infinity loop in
> > > > update_blocked_averages().
> > > >
> > > > PID: 14233  TASK: 800b2de08fc0  CPU: 1   COMMAND: "docker"
> > > >  #0 [2213b9d0] update_blocked_averages at 0811e4a8
> > > >  #1 [2213ba60] pick_next_task_fair at 0812a3b4
> > > >  #2 [2213baf0] __schedule at 08deaa88
> > > >  #3 [2213bb70] schedule at 08deb1b8
> > > >  #4 [2213bb80] futex_wait_queue_me at 08180754
> > > >  #5 [2213bbd0] futex_wait at 0818192c
> > > >  #6 [2213bd00] do_futex at 08183ee4
> > > >  #7 [2213bde0] __arm64_sys_futex at 08184398
> > > >  #8 [2213be60] el0_svc_common at 080979ac
> > > >  #9 [2213bea0] el0_svc_handler at 08097a6c
> > > >  #10 [2213bff0] el0_svc at 08084044
> > > >
> > > > rq->tmp_alone_branch introduced in 4.10, used to point to
> > > > the new beg of the list. If this cfs_rq is deleted somewhere
> > > > else, then the tmp_alone_branch will be illegal and cause
> > > > a list_add corruption.
> > >
> > > shouldn't all the sequence  be protected by rq_lock ?
> > >
> > >
> > > >
> > > > (When enabled DEBUG_LIST, we fould this list_add corruption)
> > > >
> > > > [ 2546.741103] list_add corruption. next->prev should be prev
> > > > (800b4d61ad40), but was 800ba434fa38. (next=800b6a95e740).
> > > > [ 2546.741130] [ cut here ]
> > > > [ 2546.741132] kernel BUG at lib/list_debug.c:25!
> > > > [ 2546.741136] Internal error: Oops - BUG: 0 [#1] SMP
> > > > [ 2546.742870] CPU: 1 PID: 29428 Comm: docker-runc Kdump: loaded 
> > > > Tainted: G E  4.19.5-1.aarch64 #1
> > > > [ 2546.745415] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 
> > > > 02/06/2015
> > > > [ 2546.747402] pstate: 4085 (nZcv daIf -PAN -UAO)
> > > > [ 2546.749015] pc : __list_add_valid+0x50/0x90
> > > > [ 2546.750485] lr : __list_add_valid+0x50/0x90
> > > > [ 2546.751975] sp : 1b5eb910
> > > > [ 2546.753286] x29: 1b5eb910 x28: 800abacf
> > > > [ 2546.754976] x27: 1b5ebbb0 x26: 0957
> > > > [ 2546.756665] x25: 0960d000 x24: 0250f41ca8f8
> > > > [ 2546.758366] x23: 800b6a95e740 x22: 800b4d61ad40
> > > > [ 2546.760066] x21: 800b4d61ad40 x20: 800ba434f080
> > > > [ 2546.761742] x19: 800b4d61ac00 x18: 
> > > > [ 2546.763425] x17:  x16: 
> > > > [ 2546.765089] x15: 09570748 x14: 662073617720
> > > > [ 2546.766755] x13: 747562202c293034 x12: 6461313664346230
> > > > [ 2546.768429] x11: 30382820 x10: 
> > > > [ 2546.770124] x9 : 0001 x8 : 09f34a0f
> > > > [ 2546.771831] x7 :  x6 : 250d
> > > > [ 2546.773525] x5 :  x4 : 
> > > > [ 2546.775227] x3 :  x2 : 70ef7f624013ca00
> > > > [ 2546.776929] x1 :  x0 : 0075
> > > > [ 2546.778623] Process docker-runc (pid: 29428, stack limit = 
> > > > 0x293494a2)
> > > > [ 2546.780742] Call trace:
> > > > [ 2546.781955]  __list_add_valid+0x50/0x90
> > > > [ 2546.783469]  enqueue_entity+0x4a0/0x6e8
> > > > [ 2546.784957]  enqueue_task_fair+0xac/0x610
> > > > [ 2546.786502]  sched_move_task+0x134/0x178
> > > > [ 2546.787993]  cpu_cgroup_attach+0x40/0x78
> > > > [ 2546.789540]  cgroup_migrate_execute+0x378/0x3a8
> > > > [ 2546.791169]  cgroup_migrate+0x6c/0x90
> > > > [ 2546.792663]  cgroup_attach_task+0x148/0x238
> > > > [ 2546.794211]  __cgroup1_procs_write.isra.2+0xf8/0x160
> > > > [ 2546.795935]  cgroup1_procs_write+0x38/0x48
> > > > [ 2546.797492]  cgroup_file_write+0xa0/0x170
> > > > [ 2546.799010]  kernfs_fop_write+0x114/0x1e0
> > > > [ 2546.800558]  __vfs_write+0x60/0x190
> > > > [ 2546.801977]  vfs_write+0xac/0x1c0
> > > > [ 2546.803341]  ksys_write+0x6c/0xd8
> > > > [ 2546.804674]  __arm64_sys_write+0x24/0x30
> > > > [ 2546.806146]  el0_svc_common+0x78/0x100
> > > > [ 2546.807584]  el0_svc_handler+0x38/0x88
> > > > [ 2546.809017]  el0_svc+0x8/0xc
> > > >
> > >
> > > Have you got more details about the sequence that generates this bug ?
> > > Is it easily reproducible ?
> > >
> > > > In this patch, we move rq->tmp_alone_branch point to its prev before 
> > > > delete it
> > > > from list.
> > > >
> > > > Reported-by: Zhipeng Xie 
> > > > Cc: Bin Li 
> > > > Cc: [4.10+]
> > > > Fixes: 9c2791f936ef (sched/fair: Fix hierarchical order in 
> > > > rq->leaf_cfs_rq_list)
> > >
> > > If it only happens in 

Re: [PATCH v1 7/7] drm: remove include of drmP.h from drm_gem_cma_helper.h

[David Lechner]

On 12/26/18 3:03 PM, Sam Ravnborg wrote:

Fix fallout in various files/drivers.



What fallout is being fixed? It would be helpful if we received the full
patch series for context. It would also be nice to have a more detailed
description in this commit message.

[PATCH] csky: fix refcount leak in setup_smp()

[Yangtao Li]

The of_find_node_by_type() returns a node pointer with refcount
incremented, but there is the lack of use of the of_node_put() when
done. Add the missing of_node_put() to release the refcount.

Signed-off-by: Yangtao Li 
---
 arch/csky/kernel/smp.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/csky/kernel/smp.c b/arch/csky/kernel/smp.c
index 36ebaf9834e1..adec56df613b 100644
--- a/arch/csky/kernel/smp.c
+++ b/arch/csky/kernel/smp.c
@@ -139,11 +139,17 @@ void __init setup_smp(void)
int cpu;
 
while ((node = of_find_node_by_type(node, "cpu"))) {
-   if (!of_device_is_available(node))
+   if (!of_device_is_available(node)) {
+   of_node_put(node);
continue;
+   }
 
-   if (of_property_read_u32(node, "reg", ))
+   if (of_property_read_u32(node, "reg", )) {
+   of_node_put(node);
continue;
+   }
+
+   of_node_put(node);
 
if (cpu >= NR_CPUS)
continue;
-- 
2.17.0

[PATCH] bitmap: Add bitmap_valloc(), bitmap_vzalloc() and bitmap_vfree()

[Peng Wang]

Introduce bitmap alloc/free helpers when contiguous
memory is not necessary.

Signed-off-by: Peng Wang 
---
 include/linux/bitmap.h |  3 +++
 lib/bitmap.c   | 19 +++
 2 files changed, 22 insertions(+)

diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index f58e97446abc..aaad1b33dfd5 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -111,6 +111,9 @@
 extern unsigned long *bitmap_alloc(unsigned int nbits, gfp_t flags);
 extern unsigned long *bitmap_zalloc(unsigned int nbits, gfp_t flags);
 extern void bitmap_free(const unsigned long *bitmap);
+extern unsigned long *bitmap_valloc(unsigned int nbits, gfp_t flags);
+extern unsigned long *bitmap_vzalloc(unsigned int nbits, gfp_t flags);
+extern void bitmap_vfree(const unsigned long *bitmap);
 
 /*
  * lib/bitmap.c provides these functions:
diff --git a/lib/bitmap.c b/lib/bitmap.c
index eead55aa7170..739597e436ad 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -1139,6 +1139,25 @@ void bitmap_free(const unsigned long *bitmap)
 }
 EXPORT_SYMBOL(bitmap_free);
 
+unsigned long *bitmap_valloc(unsigned int nbits, gfp_t flags)
+{
+   return kvmalloc_array(BITS_TO_LONGS(nbits), sizeof(unsigned long),
+flags);
+}
+EXPORT_SYMBOL(bitmap_valloc);
+
+unsigned long *bitmap_vzalloc(unsigned int nbits, gfp_t flags)
+{
+   return bitmap_valloc(nbits, flags | __GFP_ZERO);
+}
+EXPORT_SYMBOL(bitmap_vzalloc);
+
+void bitmap_vfree(const unsigned long *bitmap)
+{
+   kvfree(bitmap);
+}
+EXPORT_SYMBOL(bitmap_vfree);
+
 #if BITS_PER_LONG == 64
 /**
  * bitmap_from_arr32 - copy the contents of u32 array of bits to bitmap
-- 
2.19.1

Re: [PATCH v4 05/13] firmware: ti_sci: Add helper apis to manage resources

[Nishanth Menon]

On 11:43-20181227, Lokesh Vutla wrote:
> Each resource with in the device can be uniquely identified
> by a type and subtype as defined by TISCI. Since this is generic
> across the devices, resource allocation also can be made generic
> instead of each client driver handling the resource. So add helper
> apis to manage the resource.
> 
> Signed-off-by: Lokesh Vutla 
> ---
>  drivers/firmware/ti_sci.c  | 126 +
>  include/linux/soc/ti/ti_sci_protocol.h |  48 ++
>  2 files changed, 174 insertions(+)
> 
> diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
> index c2f0815edab6..b6804c214be9 100644
> --- a/drivers/firmware/ti_sci.c
> +++ b/drivers/firmware/ti_sci.c
> @@ -2480,6 +2480,132 @@ const struct ti_sci_handle 
> *devm_ti_sci_get_by_phandle(struct device *dev,
>  }
>  EXPORT_SYMBOL_GPL(devm_ti_sci_get_by_phandle);
>  
> +/*
> + * ti_sci_get_free_resource() - Get a free resource from TISCI resource.
> + * @res: Pointer to the TISCI resource
> + *
> + * Return: resource num if all went ok else TI_SCI_RESOURCE_NULL.
> + */
> +u16 ti_sci_get_free_resource(struct ti_sci_resource *res)
> +{
> + unsigned long flags;
> + u16 set, free_bit;
> +
> + raw_spin_lock_irqsave(>lock, flags);
> + for (set = 0; set < res->sets; set++) {
> + free_bit = find_first_zero_bit(res->desc[set].res_map,
> +res->desc[set].num);
> + if (free_bit != res->desc[set].num) {
> + set_bit(free_bit, res->desc[set].res_map);
> + raw_spin_unlock_irqrestore(>lock, flags);
> + return res->desc[set].start + free_bit;
> + }
> + }
> + raw_spin_unlock_irqrestore(>lock, flags);
> +
> + return TI_SCI_RESOURCE_NULL;
> +}
> +EXPORT_SYMBOL_GPL(ti_sci_get_free_resource);
> +
> +/**
> + * ti_sci_release_resource() - Release a resource from TISCI resource.
> + * @res: Pointer to the TISCI resource
> + */
> +void ti_sci_release_resource(struct ti_sci_resource *res, u16 id)
> +{
> + unsigned long flags;
> + u16 set;
> +
> + raw_spin_lock_irqsave(>lock, flags);
> + for (set = 0; set < res->sets; set++) {
> + if (res->desc[set].start <= id &&
> + (res->desc[set].num + res->desc[set].start) > id)
> + clear_bit(id - res->desc[set].start,
> +   res->desc[set].res_map);
> + }
> + raw_spin_unlock_irqrestore(>lock, flags);
> +}
> +EXPORT_SYMBOL_GPL(ti_sci_release_resource);
> +
> +/**
> + * devm_ti_sci_get_of_resource() - Get a TISCI resource assigned to a device
> + * @handle:  TISCI handle
> + * @dev: Device pointer to which the resource is assigned
> + * @of_prop: property name by which the resource are represented
> + *
> + * Note: This function expects of_prop to be in the form of tuples
> + *   . Allocates and initializes ti_sci_resource structure
> + *   for each of_prop. Client driver can directly call
> + *   ti_sci_(get_free, release)_resource apis for handling the resource.
> + *
> + * Return: Pointer to ti_sci_resource if all went well else appropriate
> + *  error pointer.
> + */
> +struct ti_sci_resource *
> +devm_ti_sci_get_of_resource(const struct ti_sci_handle *handle,
> + struct device *dev, u32 dev_id, char *of_prop)
> +{
> + struct ti_sci_resource *res;
> + u32 resource_subtype;
> + u16 resource_type;
> + int i, ret;
> +
> + res = devm_kzalloc(dev, sizeof(*res), GFP_KERNEL);
> + if (!res)
> + return ERR_PTR(-ENOMEM);
> +
> + res->sets = of_property_count_elems_of_size(dev_of_node(dev), of_prop,
> + sizeof(u32));
> + if (res->sets < 0) {
> + dev_err(dev, "%s resource type ids not available\n", of_prop);
> + return ERR_PTR(res->sets);
> + }
> +
> + res->desc = devm_kcalloc(dev, res->sets, sizeof(*res->desc),
> +  GFP_KERNEL);
> + if (!res->desc)
> + return ERR_PTR(-ENOMEM);
> +
> + ret = ti_sci_get_resource_type(handle_to_ti_sci_info(handle), dev_id,
> +_type);
> + if (ret) {
> + dev_err(dev, "No valid resource type for %u\n", dev_id);
> + return ERR_PTR(-EINVAL);
> + }
> +
> + for (i = 0; i < res->sets; i++) {
> + ret = of_property_read_u32_index(dev_of_node

Re: [PATCH 1/1] mm/page_alloc: add a warning about high order allocations

[Konstantin Khorenko]

On 12/26/2018 11:40 AM, Michal Hocko wrote:
> Appart from general comments as a reply to the cover (btw. this all
> should be in the changelog because this is the _why_ part of the
> justification which should be _always_ part of the changelog).

Thank you, will add in the next version of the patch alltogether
with other changes if any.

> On Tue 25-12-18 18:39:27, Konstantin Khorenko wrote:
> [...]
>> +config WARN_HIGH_ORDER
>> +bool "Enable complains about high order memory allocations"
>> +depends on !LOCKDEP
>
> Why?

LOCKDEP makes structures big, so if we see a high order allocation warning
on a debug kernel with lockdep, it does not give us a lot - lockdep enabled
kernel performance is not our target.
i can remove !LOCKDEP dependence here, but then need to adjust default
warning level i think, or logs will be spammed.

>> +default n
>> +help
>> +  Enables warnings on high order memory allocations. This allows to
>> +  determine users of large memory chunks and rework them to decrease
>> +  allocation latency. Note, some debug options make kernel structures
>> +  fat.
>> +
>> +config WARN_HIGH_ORDER_LEVEL
>> +int "Define page order level considered as too high"
>> +depends on WARN_HIGH_ORDER
>> +default 3
>> +help
>> +  Defines page order starting which the system to complain about.
>> +  Default is current PAGE_ALLOC_COSTLY_ORDER.
>> +
>>  config HWPOISON_INJECT
>>  tristate "HWPoison pages injector"
>>  depends on MEMORY_FAILURE && DEBUG_KERNEL && PROC_FS
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index e95b5b7c9c3d..258892adb861 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -4341,6 +4341,30 @@ static inline void finalise_ac(gfp_t gfp_mask, struct 
>> alloc_context *ac)
>>  ac->high_zoneidx, ac->nodemask);
>>  }
>>
>> +#ifdef CONFIG_WARN_HIGH_ORDER
>> +int warn_order = CONFIG_WARN_HIGH_ORDER_LEVEL;
>> +
>> +/*
>> + * Complain if we allocate a high order page unless there is a __GFP_NOWARN
>> + * flag provided.
>> + *
>> + * Shuts up after 32 complains.
>> + */
>> +static __always_inline void warn_high_order(int order, gfp_t gfp_mask)
>> +{
>> +static atomic_t warn_count = ATOMIC_INIT(32);
>> +
>> +if (order >= warn_order && !(gfp_mask & __GFP_NOWARN))
>> +WARN(atomic_dec_if_positive(_count) >= 0,
>> + "order %d >= %d, gfp 0x%x\n",
>> + order, warn_order, gfp_mask);
>> +}
>
> We do have ratelimit functionality, so why cannot you use it?

Well, my idea was to really shut up the warning after some number of messages
(if a node is in production and its uptime, say, a year, i don't want to see
many warnings in logs, first several is enough - let's fix them first).

If i use printk_ratelimited() i could get 24 days delay at most AFAIK,
but okay, i can switch to printk_ratelimited() if you prefer.

struct ratelimit_state {
 int interval;

(gdb) p ((1LL<<31) -1)/1000/60/60/24
$11 = 24

>> +#else
>> +static __always_inline void warn_high_order(int order, gfp_t gfp_mask)
>> +{
>> +}
>> +#endif
>> +
>>  /*
>>   * This is the 'heart' of the zoned buddy allocator.
>>   */
>> @@ -4361,6 +4385,7 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int 
>> order, int preferred_nid,
>>  WARN_ON_ONCE(!(gfp_mask & __GFP_NOWARN));
>>  return NULL;
>>  }
>> +warn_high_order(order, gfp_mask);
>>
>>  gfp_mask &= gfp_allowed_mask;
>>  alloc_mask = gfp_mask;
>
> Why do you warn about all allocations in the hot path? I thought you
> want to catch expensive allocations so I would assume that you would
> stick that into a slow path after we are not able to allocate anything
> after the first round of compaction.

The idea is to catch big allocations soon and preferably during testing,
not on production nodes under high load, that's why i've chosen hot path.

And if we switch to the slow path, we'll have to run all tests under
additional serious load - to generate memory fragmentation.
Not so convenient.

> Also do you want to warn about opportunistic GFP_NOWAIT allocations that
> have a reasonable fallback?

Yes, i would like to. Sometimes allocation flags come from upper level and
it's not always evident if there is GFP_NOWAIT flag or not, so let's we
are noticed about such a case and verify if it's legal and not called often.
If yes - we'll just mark it with NO_WARN.


 > And forgot to mention other opportunistic allocations like THP of
 > course.

hugepages are allocated with NOWARN already, AFAIK.
alloc_fresh_huge_page_node(), __hugetlb_alloc_buddy_huge_page()


Thank you once again, Michal.

--
Best regards,

Konstantin Khorenko,
Virtuozzo Linux Kernel Team

[PATCH v2] i2c: bcm2835: Clear current buffer pointers and counts after a transfer

[Paul Kocialkowski]

The driver's interrupt handler checks whether a message is currently
being handled with the curr_msg pointer. When it is NULL, the interrupt
is considered to be unexpected. Similarly, the i2c_start_transfer
routine checks for the remaining number of messages to handle in
num_msgs.

However, these values are never cleared and always keep the message and
number relevant to the latest transfer (which might be done already and
the underlying message memory might have been freed).

When an unexpected interrupt hits with the DONE bit set, the isr will
then try to access the flags field of the curr_msg structure, leading
to a fatal page fault.

The msg_buf and msg_buf_remaining fields are also never cleared at the
end of the transfer, which can lead to similar pitfalls.

Fix these issues by introducing a cleanup function and always calling
it after a transfer is finished.

Fixes: e2474541032d ("i2c: bcm2835: Fix hang for writing messages larger than 
16 bytes")
Signed-off-by: Paul Kocialkowski 
---

Changes since v1:
* Added cleanup of msg_buf and msg_buf_remaining;
* Moved cleanups to a dedicated function;
* Performed cleanup on timeout as well;
* Added Fixes tag.

 drivers/i2c/busses/i2c-bcm2835.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/i2c/busses/i2c-bcm2835.c b/drivers/i2c/busses/i2c-bcm2835.c
index 44deae78913e..4d19254f78c8 100644
--- a/drivers/i2c/busses/i2c-bcm2835.c
+++ b/drivers/i2c/busses/i2c-bcm2835.c
@@ -191,6 +191,15 @@ static void bcm2835_i2c_start_transfer(struct 
bcm2835_i2c_dev *i2c_dev)
bcm2835_i2c_writel(i2c_dev, BCM2835_I2C_C, c);
 }
 
+static void bcm2835_i2c_finish_transfer(struct bcm2835_i2c_dev *i2c_dev)
+{
+   i2c_dev->curr_msg = NULL;
+   i2c_dev->num_msgs = 0;
+
+   i2c_dev->msg_buf = NULL;
+   i2c_dev->msg_buf_remaining = 0;
+}
+
 /*
  * Note about I2C_C_CLEAR on error:
  * The I2C_C_CLEAR on errors will take some time to resolve -- if you were in
@@ -291,6 +300,9 @@ static int bcm2835_i2c_xfer(struct i2c_adapter *adap, 
struct i2c_msg msgs[],
 
time_left = wait_for_completion_timeout(_dev->completion,
adap->timeout);
+
+   bcm2835_i2c_finish_transfer(i2c_dev);
+
if (!time_left) {
bcm2835_i2c_writel(i2c_dev, BCM2835_I2C_C,
   BCM2835_I2C_C_CLEAR);
-- 
2.20.1

Re: [PATCH ghak90 (was ghak32) V4 09/10] audit: NETFILTER_PKT: record each container ID associated with a netNS

[Richard Guy Briggs]

On 2018-10-31 15:30, Richard Guy Briggs wrote:
> On 2018-10-19 19:18, Paul Moore wrote:
> > On Sun, Aug 5, 2018 at 4:33 AM Richard Guy Briggs  wrote:
> > > Add audit container identifier auxiliary record(s) to NETFILTER_PKT
> > > event standalone records.  Iterate through all potential audit container
> > > identifiers associated with a network namespace.
> > >
> > > Signed-off-by: Richard Guy Briggs 
> > > ---
> > >  include/linux/audit.h|  5 +
> > >  kernel/audit.c   | 26 ++
> > >  net/netfilter/xt_AUDIT.c | 12 ++--
> > >  3 files changed, 41 insertions(+), 2 deletions(-)
> > 
> > ...
> > 
> > > diff --git a/include/linux/audit.h b/include/linux/audit.h
> > > index 9a02095..8755f4d 100644
> > > --- a/include/linux/audit.h
> > > +++ b/include/linux/audit.h
> > > @@ -169,6 +169,8 @@ extern int audit_log_contid(struct audit_context 
> > > *context,
> > >  extern void audit_netns_contid_add(struct net *net, u64 contid);
> > >  extern void audit_netns_contid_del(struct net *net, u64 contid);
> > >  extern void audit_switch_task_namespaces(struct nsproxy *ns, struct 
> > > task_struct *p);
> > > +extern void audit_log_netns_contid_list(struct net *net,
> > > +struct audit_context *context);
> > >
> > >  extern int audit_update_lsm_rules(void);
> > >
> > > @@ -228,6 +230,9 @@ static inline void audit_netns_contid_del(struct net 
> > > *net, u64 contid)
> > >  { }
> > >  static inline void audit_switch_task_namespaces(struct nsproxy *ns, 
> > > struct task_struct *p)
> > >  { }
> > > +static inline void audit_log_netns_contid_list(struct net *net,
> > > +   struct audit_context *context)
> > > +{ }
> > >
> > >  #define audit_enabled AUDIT_OFF
> > >  #endif /* CONFIG_AUDIT */
> > > diff --git a/kernel/audit.c b/kernel/audit.c
> > > index c5fed3b..b23711c 100644
> > > --- a/kernel/audit.c
> > > +++ b/kernel/audit.c
> > > @@ -392,6 +392,32 @@ void audit_switch_task_namespaces(struct nsproxy 
> > > *ns, struct task_struct *p)
> > > audit_netns_contid_add(new->net_ns, contid);
> > >  }
> > >
> > > +void audit_log_netns_contid_list(struct net *net, struct audit_context 
> > > *context)
> > > +{
> > > +   spinlock_t *lock = audit_get_netns_contid_list_lock(net);
> > > +   struct audit_buffer *ab;
> > > +   struct audit_contid *cont;
> > > +   bool first = true;
> > > +
> > > +   /* Generate AUDIT_CONTAINER record with container ID CSV list */
> > > +   ab = audit_log_start(context, GFP_ATOMIC, AUDIT_CONTAINER);
> > > +   if (!ab) {
> > > +   audit_log_lost("out of memory in 
> > > audit_log_netns_contid_list");
> > > +   return;
> > > +   }
> > > +   audit_log_format(ab, "contid=");
> > > +   spin_lock(lock);
> > > +   list_for_each_entry(cont, audit_get_netns_contid_list(net), list) 
> > > {
> > > +   if (!first)
> > > +   audit_log_format(ab, ",");
> > > +   audit_log_format(ab, "%llu", cont->id);
> > > +   first = false;
> > > +   }
> > > +   spin_unlock(lock);
> > 
> > This is looking like potentially a lot of work to be doing under a
> > spinlock, not to mention a single spinlock that is shared across CPUs.
> > Considering that I expect changes to the list to be somewhat
> > infrequent, this might be a good candidate for a RCU based locking
> > scheme.
> 
> Would something like this look reasonable?
> (This is on top of a patch to make contid list lock and unlock
> functions.)

Paul, could I please get your review on this locking approach I proposed
almost two months ago so I can be more reassured that it won't be an
issue in v5?  Thanks!

> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index be5d6eb..9428fc3 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -92,6 +92,7 @@ struct audit_contid {
>   struct list_headlist;
>   u64 id;
>   refcount_t  refcount;
> + struct rcu_head rcu;
>  };
>  
>  extern int is_audit_feature_set(int which);
> diff --git a/kernel/audit.c b/kernel/audit.c
> index d5b58163..6f84c25 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -106,7 +106,6 @@
>  struct audit_net {
>   struct sock *sk;
>   struct list_head contid_list;
> - spinlock_t contid_list_lock;
>  };
>  
>  /**
> @@ -327,26 +326,6 @@ struct list_head *audit_get_netns_contid_list(const 
> struct net *net)
>   return >contid_list;
>  }
>  
> -static int audit_netns_contid_lock(const struct net *net)
> -{
> - struct audit_net *aunet = net_generic(net, audit_net_id);
> -
> - if (!aunet)
> - return -EINVAL;
> - spin_lock(aunet->contid_list_lock);
> - return 0;
> -}
> -
> -static int audit_netns_contid_unlock(const struct net *net)
> -{
> - struct audit_net *aunet = net_generic(net, audit_net_id);
> -

Re: [PATCH -mmotm] arm64: skip kmemleak for KASAN again

[Andrey Konovalov]

On Wed, Dec 26, 2018 at 3:06 AM Qian Cai  wrote:
>
> Due to 871ac3d540f (kasan: initialize shadow to 0xff for tag-based
> mode), kmemleak is broken again with KASAN. It needs a similar fix
> from e55058c2983 (mm/memblock.c: skip kmemleak for kasan_init()).
>
> Signed-off-by: Qian Cai 

Hi Qian,

Sorry, didn't see your first kmemleak fix. I can merge this fix into
my series if I end up resending it.

In any case:

Acked-by: Andrey Konovalov 

Thanks!

> ---
>  arch/arm64/mm/kasan_init.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
> index 48d8f2fa0d14..4b55b15707a3 100644
> --- a/arch/arm64/mm/kasan_init.c
> +++ b/arch/arm64/mm/kasan_init.c
> @@ -47,8 +47,7 @@ static phys_addr_t __init kasan_alloc_raw_page(int node)
>  {
> void *p = memblock_alloc_try_nid_raw(PAGE_SIZE, PAGE_SIZE,
> __pa(MAX_DMA_ADDRESS),
> -   MEMBLOCK_ALLOC_ACCESSIBLE,
> -   node);
> +   MEMBLOCK_ALLOC_KASAN, node);
> return __pa(p);
>  }
>
> --
> 2.17.2 (Apple Git-113)
>

Re: [RFC PATCH 0/1] mm: add a warning about high order allocations

[Konstantin Khorenko]

Hi Michal,

thank you very much for your questions, please see my notes below.

On 12/26/2018 11:35 AM, Michal Hocko wrote:
> On Tue 25-12-18 18:39:26, Konstantin Khorenko wrote:
>> Q: Why do we need to bother at all?
>> A: If a node is highly loaded and its memory is significantly fragmented
>> (unfortunately almost any node with serious load has highly fragmented 
>> memory)
>> then any high order memory allocation can trigger massive memory shrink and
>> result in quite a big allocation latency. And the node becomes less 
>> responsive
>> and users don't like it.
>> The ultimate solution here is to get rid of large allocations, but we need an
>> instrument to detect them.
>
> Can you point to an example of the problem you are referring here? At
> least for costly orders we do bail out early and try to not cause
> massive reclaim. So what is the order that you are concerned about?

Well, this is the most difficult question to answer.
Unfortunately i don't have a reproducer for that, usually we get into situation
when someone experiences significant node slowdown, nodes most often have a lot 
of RAM,
we check what is going on there and see the node is busy with reclaim.
And almost every time the reason was - fragmented memory and high order 
allocations.
Mostly of 2nd and 3rd (which is still considered not costly) order.

Recent related issues we faced were about FUSE dev pipe:
d6d931adce11 ("fuse: use kvmalloc to allocate array of pipe_buffer structs.")

and about bnx driver + mtu 9000 which for each packet required page of 2nd order
(and it even failed sometimes, though it was not the root cause):
 kswapd0: page allocation failure: order:2, mode:0x4020
 Call Trace:
 dump_stack+0x19/0x1b
 warn_alloc_failed+0x110/0x180
 __alloc_pages_nodemask+0x7bf/0xc60
 alloc_pages_current+0x98/0x110
 kmalloc_order+0x18/0x40
 kmalloc_order_trace+0x26/0xa0
 __kmalloc+0x279/0x290
 bnx2x_frag_alloc.isra.61+0x2a/0x40 [bnx2x]
 bnx2x_rx_int+0x227/0x17c0 [bnx2x]
 bnx2x_poll+0x1dd/0x260 [bnx2x]
 net_rx_action+0x179/0x390
 __do_softirq+0x10f/0x2aa
 call_softirq+0x1c/0x30
 do_softirq+0x65/0xa0
 irq_exit+0x105/0x110
 do_IRQ+0x56/0xe0
 common_interrupt+0x6d/0x6d

And as both places were called very often - the system latency was high.

This warning can be also used to catch allocation of 4th order and higher which 
may
easily fail. Those places which are ready to get allocation errors and have
fallbacks are marked with __GFP_NOWARN.

>> Q: Why warning? Use tracepoints!
>> A: Well, this is a matter of magic defaults.
>> Yes, you can use tracepoints to catch large allocations, but you need to do 
>> this
>> on purpose and regularly and this is to be done by every developer which is
>> quite unreal.
>> On the other hand if you develop something and get a warning, you'll have to
>> think about the reason and either succeed with reworking the code to use
>> smaller allocation sizes (and thus decrease allocation latency!) or just use
>> kvmalloc() if you don't really need physically continuos chunk or come to the
>> conclusion you definitely need physically continuos memory and shut up the
>> warning.
>
> Well, not really. For one thing, there are systems to panic on warning
> and you really do not want to blow up just because somebody is doing a
> large order allocation.

Well, on one hand - yes, i agree with you. That's why i don't suggest to enable
the warning by default right now - until all (most) of large allocations are 
marked
properly.
But after it's done and there are no (almost) unmarked high order allocations -
why not? This will reveal new cases of high order allocations soon.
i think people who run systems with "kernel.panic_on_warn" enabled do care
about reporting issues.

>> Q: Why compile time config option?
>> A: In order not to decrease the performance even a bit in case someone does 
>> not
>> want to hunt for large allocations.
>> In an ideal life i'd prefer this check/warning is enabled by default and may 
>> be
>> even without a config option so it works on every node. Once we find and 
>> rework
>> or mark all large allocations that would be good by default. Until that 
>> though
>> it will be noisy.
>
> So who is going to enable this option?

At the beginning - people who want to debug kernel and verify their fallbacks on
memory allocations failures in the code or just speed up their code on nodes
with fragmented memory - for 2nd and 3rd orders.

mm performance issues are tough, you know, and this is just another way to
gain more performance. It won't avoid the necessity of digging mm for sure,
but might decrease the pressure level.

Later (i hope) i could be enabled by default so all big new allocations
are verified sooner and either reworked or marked with __GFP_NOWARN if the code 
is
ready.

--
Best regards,

Konstantin Khorenko,
Virtuozzo Linux Kernel Team

>> 

[PATCH 0/2] hwmon: devicetree support for hih6130

[Andreas Kemnade]

This patch set adds devicetree support for hih6130, so it can
be properly auto-probed using devicetree files

Andreas Kemnade (2):
  hwmon: (hih6130) add dtb compatibility tables
  devicetree: hwmon: Add bindings documentation for HIH6130

 Documentation/devicetree/bindings/hwmon/hih6130.txt | 12 
 drivers/hwmon/hih6130.c | 11 ++-
 2 files changed, 22 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/hwmon/hih6130.txt

-- 
2.11.0

[PATCH 2/2] devicetree: hwmon: Add bindings documentation for HIH6130

[Andreas Kemnade]

Add bindings documentation for HIH6130 driver.

Signed-off-by: Andreas Kemnade 
---
 Documentation/devicetree/bindings/hwmon/hih6130.txt | 12 
 1 file changed, 12 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/hih6130.txt

diff --git a/Documentation/devicetree/bindings/hwmon/hih6130.txt 
b/Documentation/devicetree/bindings/hwmon/hih6130.txt
new file mode 100644
index ..2c43837af4c2
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/hih6130.txt
@@ -0,0 +1,12 @@
+Honeywell Humidicon HIH-6130 humidity/temperature sensor
+
+
+Requires node properties:
+- compatible : "honeywell,hi6130"
+- reg : the I2C address of the device. This is 0x27.
+
+Example:
+   hih6130@27 {
+   compatible = "honeywell,hih6130";
+   reg = <0x27>;
+   };
-- 
2.11.0

[PATCH 1/2] hwmon: (hih6130) add dtb compatibility tables

[Andreas Kemnade]

This allows the hih6130 to be used in devicetree files and auto-probed
that way.

Signed-off-by: Andreas Kemnade 
---
 drivers/hwmon/hih6130.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/hwmon/hih6130.c b/drivers/hwmon/hih6130.c
index 0ae1ee1dbf76..de1b50ddc740 100644
--- a/drivers/hwmon/hih6130.c
+++ b/drivers/hwmon/hih6130.c
@@ -254,8 +254,17 @@ static const struct i2c_device_id hih6130_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, hih6130_id);
 
+static const struct of_device_id hih6130_of_match[] = {
+   { .compatible = "honeywell,hih6130", },
+   { }
+};
+MODULE_DEVICE_TABLE(of, hih6130_of_match);
+
 static struct i2c_driver hih6130_driver = {
-   .driver.name = "hih6130",
+   .driver = {
+   .name = "hih6130",
+   .of_match_table = of_match_ptr(hih6130_of_match),
+   },
.probe   = hih6130_probe,
.id_table= hih6130_id,
 };
-- 
2.11.0

[PATCH v4 3/3] i2c: at91: added slave mode support

[Ludovic Desroches]

From: Juergen Fitschen 

Slave mode driver is based on the concept of i2c-designware driver.

Signed-off-by: Juergen Fitschen 
[ludovic.desroc...@microchip.com: rework Kconfig]
Signed-off-by: Ludovic Desroches 
---
 drivers/i2c/busses/Kconfig  |  13 +++
 drivers/i2c/busses/Makefile |   3 +
 drivers/i2c/busses/i2c-at91-core.c  |  13 ++-
 drivers/i2c/busses/i2c-at91-slave.c | 147 
 drivers/i2c/busses/i2c-at91.h   |  30 +-
 5 files changed, 202 insertions(+), 4 deletions(-)
 create mode 100644 drivers/i2c/busses/i2c-at91-slave.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index f2c681971201..6b1f6dcdf533 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -387,6 +387,19 @@ config I2C_AT91
  the latency to fill the transmission register is too long. If you
  are facing this situation, use the i2c-gpio driver.
 
+config I2C_AT91_SLAVE_EXPERIMENTAL
+   tristate "Microchip AT91 I2C experimental slave mode"
+   depends on I2C_AT91
+   select I2C_SLAVE
+   help
+ If you say yes to this option, support for the slave mode will be
+ added. Caution: do not use it for production. This feature has not
+ been tested in a heavy way, help wanted.
+ There are known bugs:
+   - It can hang, on a SAMA5D4, after several transfers.
+   - There are some mismtaches with a SAMA5D4 as slave and a SAMA5D2 as
+   master.
+
 config I2C_AU1550
tristate "Au1550/Au1200/Au1300 SMBus interface"
depends on MIPS_ALCHEMY
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index ea75a777940e..59b22fbef90a 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -36,6 +36,9 @@ obj-$(CONFIG_I2C_ALTERA)  += i2c-altera.o
 obj-$(CONFIG_I2C_ASPEED)   += i2c-aspeed.o
 obj-$(CONFIG_I2C_AT91) += i2c-at91.o
 i2c-at91-objs  := i2c-at91-core.o i2c-at91-master.o
+ifeq ($(CONFIG_I2C_AT91_SLAVE_EXPERIMENTAL),y)
+   i2c-at91-objs   += i2c-at91-slave.o
+endif
 obj-$(CONFIG_I2C_AU1550)   += i2c-au1550.o
 obj-$(CONFIG_I2C_AXXIA)+= i2c-axxia.o
 obj-$(CONFIG_I2C_BCM2835)  += i2c-bcm2835.o
diff --git a/drivers/i2c/busses/i2c-at91-core.c 
b/drivers/i2c/busses/i2c-at91-core.c
index 5d9c6c81e6ab..c74283fa567f 100644
--- a/drivers/i2c/busses/i2c-at91-core.c
+++ b/drivers/i2c/busses/i2c-at91-core.c
@@ -60,8 +60,10 @@ void at91_init_twi_bus(struct at91_twi_dev *dev)
 {
at91_disable_twi_interrupts(dev);
at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_SWRST);
-
-   at91_init_twi_bus_master(dev);
+   if (dev->slave_detected)
+   at91_init_twi_bus_slave(dev);
+   else
+   at91_init_twi_bus_master(dev);
 }
 
 static struct at91_twi_pdata at91rm9200_config = {
@@ -243,7 +245,12 @@ static int at91_twi_probe(struct platform_device *pdev)
dev->adapter.timeout = AT91_I2C_TIMEOUT;
dev->adapter.dev.of_node = pdev->dev.of_node;
 
-   rc = at91_twi_probe_master(pdev, phy_addr, dev);
+   dev->slave_detected = i2c_detect_slave_mode(>dev);
+
+   if (dev->slave_detected)
+   rc = at91_twi_probe_slave(pdev, phy_addr, dev);
+   else
+   rc = at91_twi_probe_master(pdev, phy_addr, dev);
if (rc)
return rc;
 
diff --git a/drivers/i2c/busses/i2c-at91-slave.c 
b/drivers/i2c/busses/i2c-at91-slave.c
new file mode 100644
index ..4b4808e0c8f7
--- /dev/null
+++ b/drivers/i2c/busses/i2c-at91-slave.c
@@ -0,0 +1,147 @@
+/*
+ *  i2c slave support for Atmel's AT91 Two-Wire Interface (TWI)
+ *
+ *  Copyright (C) 2017 Juergen Fitschen 
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "i2c-at91.h"
+
+static irqreturn_t atmel_twi_interrupt_slave(int irq, void *dev_id)
+{
+   struct at91_twi_dev *dev = dev_id;
+   const unsigned status = at91_twi_read(dev, AT91_TWI_SR);
+   const unsigned irqstatus = status & at91_twi_read(dev, AT91_TWI_IMR);
+   u8 value;
+
+   if (!irqstatus)
+   return IRQ_NONE;
+
+   /* slave address has been detected on I2C bus */
+   if (irqstatus & AT91_TWI_SVACC) {
+   if (status & AT91_TWI_SVREAD) {
+   i2c_slave_event(dev->slave,
+   I2C_SLAVE_READ_REQUESTED, );
+   writeb_relaxed(value, dev->base + AT91_TWI_THR);
+   at91_twi_write(dev, AT91_TWI_IER,
+  AT91_TWI_TXRDY | AT91_TWI_EOSACC);
+   } else {
+   i2c_slave_event(dev->slave,
+

[PATCH v4 2/3] i2c: at91: split driver into core and master file

[Ludovic Desroches]

From: Juergen Fitschen 

The single file i2c-at91.c has been split into core code (i2c-at91-core.c)
and master mode specific code (i2c-at91-master.c). This should enhance
maintainability and reduce ifdeffery for slave mode related code.

The code itself hasn't been touched. Shared functions only had to be made
non-static. Furthermore, includes have been cleaned up.

Signed-off-by: Juergen Fitschen 
[ludovic.desroc...@microchip.com: fix checkpatch errors]
Signed-off-by: Ludovic Desroches 
---
 MAINTAINERS   |   3 +-
 drivers/i2c/busses/Makefile   |   1 +
 drivers/i2c/busses/i2c-at91-core.c| 373 ++
 .../busses/{i2c-at91.c => i2c-at91-master.c}  | 467 +-
 drivers/i2c/busses/i2c-at91.h | 151 ++
 5 files changed, 531 insertions(+), 464 deletions(-)
 create mode 100644 drivers/i2c/busses/i2c-at91-core.c
 rename drivers/i2c/busses/{i2c-at91.c => i2c-at91-master.c} (67%)
 create mode 100644 drivers/i2c/busses/i2c-at91.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 82dc44b09a7e..d61941db6933 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9873,7 +9873,8 @@ MICROCHIP I2C DRIVER
 M: Ludovic Desroches 
 L: linux-...@vger.kernel.org
 S: Supported
-F: drivers/i2c/busses/i2c-at91.c
+F: drivers/i2c/busses/i2c-at91.h
+F: drivers/i2c/busses/i2c-at91-*.c
 
 MICROCHIP ISC DRIVER
 M: Eugen Hristev 
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 5f0cb6915969..ea75a777940e 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_I2C_POWERMAC)+= i2c-powermac.o
 obj-$(CONFIG_I2C_ALTERA)   += i2c-altera.o
 obj-$(CONFIG_I2C_ASPEED)   += i2c-aspeed.o
 obj-$(CONFIG_I2C_AT91) += i2c-at91.o
+i2c-at91-objs  := i2c-at91-core.o i2c-at91-master.o
 obj-$(CONFIG_I2C_AU1550)   += i2c-au1550.o
 obj-$(CONFIG_I2C_AXXIA)+= i2c-axxia.o
 obj-$(CONFIG_I2C_BCM2835)  += i2c-bcm2835.o
diff --git a/drivers/i2c/busses/i2c-at91-core.c 
b/drivers/i2c/busses/i2c-at91-core.c
new file mode 100644
index ..5d9c6c81e6ab
--- /dev/null
+++ b/drivers/i2c/busses/i2c-at91-core.c
@@ -0,0 +1,373 @@
+/*
+ *  i2c Support for Atmel's AT91 Two-Wire Interface (TWI)
+ *
+ *  Copyright (C) 2011 Weinmann Medical GmbH
+ *  Author: Nikolaus Voss 
+ *
+ *  Evolved from original work by:
+ *  Copyright (C) 2004 Rick Bronson
+ *  Converted to 2.6 by Andrew Victor 
+ *
+ *  Borrowed heavily from original work by:
+ *  Copyright (C) 2000 Philip Edelbrock 
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "i2c-at91.h"
+
+unsigned at91_twi_read(struct at91_twi_dev *dev, unsigned reg)
+{
+   return readl_relaxed(dev->base + reg);
+}
+
+void at91_twi_write(struct at91_twi_dev *dev, unsigned reg, unsigned val)
+{
+   writel_relaxed(val, dev->base + reg);
+}
+
+void at91_disable_twi_interrupts(struct at91_twi_dev *dev)
+{
+   at91_twi_write(dev, AT91_TWI_IDR, AT91_TWI_INT_MASK);
+}
+
+void at91_twi_irq_save(struct at91_twi_dev *dev)
+{
+   dev->imr = at91_twi_read(dev, AT91_TWI_IMR) & AT91_TWI_INT_MASK;
+   at91_disable_twi_interrupts(dev);
+}
+
+void at91_twi_irq_restore(struct at91_twi_dev *dev)
+{
+   at91_twi_write(dev, AT91_TWI_IER, dev->imr);
+}
+
+void at91_init_twi_bus(struct at91_twi_dev *dev)
+{
+   at91_disable_twi_interrupts(dev);
+   at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_SWRST);
+
+   at91_init_twi_bus_master(dev);
+}
+
+static struct at91_twi_pdata at91rm9200_config = {
+   .clk_max_div = 5,
+   .clk_offset = 3,
+   .has_unre_flag = true,
+   .has_alt_cmd = false,
+   .has_hold_field = false,
+};
+
+static struct at91_twi_pdata at91sam9261_config = {
+   .clk_max_div = 5,
+   .clk_offset = 4,
+   .has_unre_flag = false,
+   .has_alt_cmd = false,
+   .has_hold_field = false,
+};
+
+static struct at91_twi_pdata at91sam9260_config = {
+   .clk_max_div = 7,
+   .clk_offset = 4,
+   .has_unre_flag = false,
+   .has_alt_cmd = false,
+   .has_hold_field = false,
+};
+
+static struct at91_twi_pdata at91sam9g20_config = {
+   .clk_max_div = 7,
+   .clk_offset = 4,
+   .has_unre_flag = false,
+   .has_alt_cmd = false,
+   .has_hold_field = false,
+};
+
+static struct at91_twi_pdata at91sam9g10_config = {
+   .clk_max_div = 7,
+   .clk_offset = 4,
+   .has_unre_flag = false,
+   .has_alt_cmd = false,
+   .has_hold_field = false,
+};
+
+static const struct platform_device_id at91_twi_devtypes[] = {
+   {
+   .name = 

[PATCH v4 1/3] i2c: at91: segregate master mode specific code from probe and init func

[Ludovic Desroches]

From: Juergen Fitschen 

In order to implement slave mode support for the at91 hardware we have to
segregate all master mode specific function parts from the general parts.
The upcoming slave mode patch will call its sepcific probe resp. init
function instead of the master mode functions after the shared general
code has been executed.

This concept has been influenced by the i2c-designware driver.

Signed-off-by: Juergen Fitschen 
Signed-off-by: Ludovic Desroches 
---
 drivers/i2c/busses/i2c-at91.c | 90 +--
 1 file changed, 55 insertions(+), 35 deletions(-)

diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index 3f3e8b3bf5ff..bc74184462c6 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -174,10 +174,8 @@ static void at91_twi_irq_restore(struct at91_twi_dev *dev)
at91_twi_write(dev, AT91_TWI_IER, dev->imr);
 }
 
-static void at91_init_twi_bus(struct at91_twi_dev *dev)
+static void at91_init_twi_bus_master(struct at91_twi_dev *dev)
 {
-   at91_disable_twi_interrupts(dev);
-   at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_SWRST);
/* FIFO should be enabled immediately after the software reset */
if (dev->fifo_size)
at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_FIFOEN);
@@ -186,6 +184,14 @@ static void at91_init_twi_bus(struct at91_twi_dev *dev)
at91_twi_write(dev, AT91_TWI_CWGR, dev->twi_cwgr_reg);
 }
 
+static void at91_init_twi_bus(struct at91_twi_dev *dev)
+{
+   at91_disable_twi_interrupts(dev);
+   at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_SWRST);
+
+   at91_init_twi_bus_master(dev);
+}
+
 /*
  * Calculate symmetric clock as stated in datasheet:
  * twi_clk = F_MAIN / (2 * (cdiv * (1 << ckdiv) + offset))
@@ -1046,18 +1052,56 @@ static struct at91_twi_pdata *at91_twi_get_driver_data(
return (struct at91_twi_pdata *) 
platform_get_device_id(pdev)->driver_data;
 }
 
+static int at91_twi_probe_master(struct platform_device *pdev,
+u32 phy_addr, struct at91_twi_dev *dev)
+{
+   int rc;
+   u32 bus_clk_rate;
+
+   init_completion(>cmd_complete);
+
+   rc = devm_request_irq(>dev, dev->irq, atmel_twi_interrupt, 0,
+ dev_name(dev->dev), dev);
+   if (rc) {
+   dev_err(dev->dev, "Cannot get irq %d: %d\n", dev->irq, rc);
+   return rc;
+   }
+
+   if (dev->dev->of_node) {
+   rc = at91_twi_configure_dma(dev, phy_addr);
+   if (rc == -EPROBE_DEFER)
+   return rc;
+   }
+
+   if (!of_property_read_u32(pdev->dev.of_node, "atmel,fifo-size",
+ >fifo_size)) {
+   dev_info(dev->dev, "Using FIFO (%u data)\n", dev->fifo_size);
+   }
+
+   rc = of_property_read_u32(dev->dev->of_node, "clock-frequency",
+ _clk_rate);
+   if (rc)
+   bus_clk_rate = DEFAULT_TWI_CLK_HZ;
+
+   at91_calc_twi_clock(dev, bus_clk_rate);
+
+   dev->adapter.algo = _twi_algorithm;
+   dev->adapter.quirks = _twi_quirks;
+
+   return 0;
+}
+
 static int at91_twi_probe(struct platform_device *pdev)
 {
struct at91_twi_dev *dev;
struct resource *mem;
int rc;
u32 phy_addr;
-   u32 bus_clk_rate;
 
dev = devm_kzalloc(>dev, sizeof(*dev), GFP_KERNEL);
if (!dev)
return -ENOMEM;
-   init_completion(>cmd_complete);
+
dev->dev = >dev;
 
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -1077,13 +1121,6 @@ static int at91_twi_probe(struct platform_device *pdev)
if (dev->irq < 0)
return dev->irq;
 
-   rc = devm_request_irq(>dev, dev->irq, atmel_twi_interrupt, 0,
-dev_name(dev->dev), dev);
-   if (rc) {
-   dev_err(dev->dev, "Cannot get irq %d: %d\n", dev->irq, rc);
-   return rc;
-   }
-
platform_set_drvdata(pdev, dev);
 
dev->clk = devm_clk_get(dev->dev, NULL);
@@ -1095,38 +1132,21 @@ static int at91_twi_probe(struct platform_device *pdev)
if (rc)
return rc;
 
-   if (dev->dev->of_node) {
-   rc = at91_twi_configure_dma(dev, phy_addr);
-   if (rc == -EPROBE_DEFER) {
-   clk_disable_unprepare(dev->clk);
-   return rc;
-   }
-   }
-
-   if (!of_property_read_u32(pdev->dev.of_node, "atmel,fifo-size",
- >fifo_size)) {
-   dev_info(dev->dev, "Using FIFO (%u data)\n", dev->fifo_size);
-   }
-
-   rc = of_property_read_u32(dev->dev->of_node, "clock-frequency",
-   _clk_rate);
-   if (rc)
-   bus_clk_rate = DEFAULT_TWI_CLK_HZ;
-
-   at91_calc_twi_clock(dev, bus_clk_rate);
-   at91_init_twi_bus(dev);
-
snprintf(dev->adapter.name, 

[PATCH v4 0/3] i2c: at91: slave mode support

[Ludovic Desroches]

[Ludovic Desroches: see Changes section]

Based on the discussion we had on the i2c-linux list [1], I wrote a patch for
AT91 hardware and tried to fulfill the Linux I2C slave interface description
[2] as good as possible. This enables aforementioned hardware to act as an I2C
slave that can be accessed by a remote I2C master.

I have tested this patchset successfully on an ATSAMA5D27.

 ^  3.3V   ^  3.3V
+---+| | +---+
| Slave: ATSAMA5D27 |   +-+   +-+| Master: ATSAMA5D35|
| with i2c-slave-eeprom |   | | 100k  | | 100k   | with i2cset   |
+---+-+-+   +-+   +-++-+-+---+
| |  | |   | |
| +--+-|---(SDA)---+ |
+--+---(SCL)-+

Schematic: Connection of slave and master with 100kOhm pullup resistors.

On the master the following BASH script has been used to stress the slave.

root@emblinux:~# cat ./stress.sh
#!/bin/bash
I=0
while true
do
if i2cset -y -r 1 0x64 0 $I w | grep mismatch
then
echo "$(date): Error in transmission ${I}"
fi
((I++))
if [ $I -eq 65536 ]
then
I=0
echo "$(date): Sent 65536 transmissions"
fi
done

After running the script for some time I had the following output. To me this
looks promising :)

root@emblinux:~# ./stress.sh
Thu Nov  9 13:58:45 CTE 2017: Sent 65536 transmissions
Thu Nov  9 14:35:20 CTE 2017: Sent 65536 transmissions
Thu Nov  9 15:12:11 CTE 2017: Sent 65536 transmissions
Thu Nov  9 15:49:04 CTE 2017: Sent 65536 transmissions
Thu Nov  9 16:26:00 CTE 2017: Sent 65536 transmissions
Thu Nov  9 17:03:07 UTC 2017: Sent 65536 transmissions
Thu Nov  9 17:40:15 UTC 2017: Sent 65536 transmissions

If you have some hardware with an at91-i2c interface included at hand, 
I really
would appreciate if you can run the test script on your hardware and 
test this
driver.
Thu Nov  9 17:40:15 UTC 2017: Sent 65536 transmissions

If you have some hardware with an at91-i2c interface included at hand, 
I really
would appreciate if you can run the test script on your hardware and 
test this
driver.

Best regards
  Juergen


[Ludovic Desroches]
Changes in v4:
 - rebased on next-20181224
 - update Kconfig part to state that this feature is experimental.
 - tested quickly on a single board, SAMA5D2 Xplained, i2c-gpio as master, OK.
Changes in v3:
 - rebase (cherry-pick was enough)
 - fix checkpatch errors
 - tests:
   - hangs with a SAMA5D4 (master and slave on different busses) after about
   100 transfers. It's the first time I do this test.
   - some mismatches with a SAMA5D4 as slave and a SAMA5D2 as master
   I don't know if it's a regression. I don't remember having seen this
   behavior previously.
   I think it's worth taking those patches even if there are some possible
   bugs. It'll allow to get more people using it and so to consolidate the
   slave mode support.

Changes in v2:
 - Implemented all suggestions made by Ludovic. (Thank you!)
 - Reworked the IRQ handler completely. Have a look in patch 3 fort further
   details.

[1] https://marc.info/?t=15082400481=1=1
[2] https://www.kernel.org/doc/Documentation/i2c/slave-interface



Juergen Fitschen (3):
  i2c: at91: segregate master mode specific code from probe and init
func
  i2c: at91: split driver into core and master file
  i2c: at91: added slave mode support

 MAINTAINERS   |   3 +-
 drivers/i2c/busses/Kconfig|  13 +
 drivers/i2c/busses/Makefile   |   4 +
 drivers/i2c/busses/i2c-at91-core.c| 380 +++
 .../busses/{i2c-at91.c => i2c-at91-master.c}  | 453 +-
 drivers/i2c/busses/i2c-at91-slave.c   | 147 ++
 drivers/i2c/busses/i2c-at91.h | 179 +++
 7 files changed, 732 insertions(+), 447 deletions(-)
 create mode 100644 drivers/i2c/busses/i2c-at91-core.c
 rename drivers/i2c/busses/{i2c-at91.c => i2c-at91-master.c} (67%)
 create mode 100644 drivers/i2c/busses/i2c-at91-slave.c
 create mode 100644 drivers/i2c/busses/i2c-at91.h

-- 
2.20.1

Re: [PATCH] i2c: bcm2835: Clear current message and count after a transaction

[Paul Kocialkowski]

Hi Stefan,

On Thu, 2018-12-27 at 15:05 +0100, Stefan Wahren wrote:
> Hi Paul,
> 
> > Paul Kocialkowski  hat am 24. Dezember 2018 
> > um 10:10 geschrieben:
> > 
> > 
> > Hi,
> > 
> > On Sat, 2018-12-22 at 13:19 +0100, Stefan Wahren wrote:
> > > Hi Paul,
> > > 
> > > > Paul Kocialkowski  hat am 21. Dezember 
> > > > 2018 um 13:11 geschrieben:
> > > > 
> > > > 
> > > > The driver's interrupt handler checks whether a message is currently
> > > > being handled with the curr_msg pointer. When it is NULL, the interrupt
> > > > is considered to be unexpected. Similarly, the i2c_start_transfer
> > > > routine checks for the remaining number of messages to handle in
> > > > num_msgs.
> > > > 
> > > > However, these values are never cleared and always keep the message and
> > > > number relevant to the latest transfer (which might be done already and
> > > > the underlying message memory might have been freed).
> > > > 
> > > > When an unexpected interrupt hits with the DONE bit set, the isr will
> > > > then try to access the flags field of the curr_msg structure, leading
> > > > to a fatal page fault.
> > > > 
> > > > Fix the issue by systematically clearing curr_msg and num_msgs in the
> > > > driver-wide device structure when a transfer is considered complete.
> > > > 
> > > > Signed-off-by: Paul Kocialkowski 
> > > > ---
> > > >  drivers/i2c/busses/i2c-bcm2835.c | 3 +++
> > > >  1 file changed, 3 insertions(+)
> > > > 
> > > > diff --git a/drivers/i2c/busses/i2c-bcm2835.c 
> > > > b/drivers/i2c/busses/i2c-bcm2835.c
> > > > index 44deae78913e..5486252f5f2f 100644
> > > > --- a/drivers/i2c/busses/i2c-bcm2835.c
> > > > +++ b/drivers/i2c/busses/i2c-bcm2835.c
> > > > @@ -298,6 +298,9 @@ static int bcm2835_i2c_xfer(struct i2c_adapter 
> > > > *adap, struct i2c_msg msgs[],
> > > > return -ETIMEDOUT;
> > > > }
> > > >  
> > > > +   i2c_dev->curr_msg = NULL;
> > > > +   i2c_dev->num_msgs = 0;
> > > 
> > > AFAIU this would reduce the chance of a use-after-free dramatically but 
> > > not completely.
> > 
> > Do you have a specific case of use-after-free related to these
> > variables in mind that this cleanup would not fix (except for the
> > timeout case)?
> 
> okay i was wrong about the use-after-free. But i'm not sure about this 
> scenario on the I2C bus shared with the VC4:
> 
> 1. ARM core starts I2C transfer (bcm2835_i2c_start_transfer)
> 2. VC4 triggers a BCM2835_I2C_S_DONE interrupt
> 3. ARM core catches this interrupt before the VC4

Well, I thought the VC4 has precedence over the ARM core, so if the
interrupts hits in hardware, it should be seen by the VC4 first and
forwarded to the ARM core if needed (I might be wrong though). So in
that case, perhaps the ARM core wouldn't see the interrupt and just
timeout?

Either way, I'm don't think that having both the VC4 and the ARM core
poke on the same bus is a scenario we can realisticly aim to support.
Although it should definitely not make our driver crash if that
happens.

The HDMI DDC bus is an I2C bus shared between the ARM core and VC4, but
the VC4 firmware should detect from the device-tree that Linux will
attempt to drive the bus and let the ARM core deal with it without
interference.

Thanks for your feedback!

Cheers,

Paul

> > The msg_buf element (in association with msg_buf_remaining keeping its
> > previous value) could also lead to similar problems, so I'm thinking of
> > making a bcm2835_i2c_finish_transfer function to group all the cleanups
> > and call that right after wait_for_completion_timeout.
> > 
> > > Btw: Why did you leave of the i2c transfer timeout case?
> > 
> > I should definitely have included it, actually.
> > 
> > Cheers,
> > 
> > Paul
> > 
> > > Thanks
> > > Stefan
> > > 
> > > > +
> > > > if (!i2c_dev->msg_err)
> > > > return num;
> > > >  
> > > > -- 
> > > > 2.20.1
> > > > 
> > -- 
> > Paul Kocialkowski, Bootlin (formerly Free Electrons)
> > Embedded Linux and kernel engineering
> > https://bootlin.com
> > 
-- 
Paul Kocialkowski, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com

Re: [PATCH 1/2] ARM: dump: Convert to use DEFINE_SHOW_ATTRIBUTE macro

[Donglin Peng]

On Wed, Jun 13, 2018 at 9:15 AM Peng Donglin  wrote:
>
> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
>
> Signed-off-by: Peng Donglin 
> ---
>  arch/arm/mm/ptdump_debugfs.c | 13 +
>  1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/arch/arm/mm/ptdump_debugfs.c b/arch/arm/mm/ptdump_debugfs.c
> index be8d87b..79002fe 100644
> --- a/arch/arm/mm/ptdump_debugfs.c
> +++ b/arch/arm/mm/ptdump_debugfs.c
> @@ -11,18 +11,7 @@ static int ptdump_show(struct seq_file *m, void *v)
> ptdump_walk_pgd(m, info);
> return 0;
>  }
> -
> -static int ptdump_open(struct inode *inode, struct file *file)
> -{
> -   return single_open(file, ptdump_show, inode->i_private);
> -}
> -
> -static const struct file_operations ptdump_fops = {
> -   .open   = ptdump_open,
> -   .read   = seq_read,
> -   .llseek = seq_lseek,
> -   .release= single_release,
> -};
> +DEFINE_SHOW_ATTRIBUTE(ptdump);
>
>  int ptdump_debugfs_register(struct ptdump_info *info, const char *name)
>  {
> --
> 2.7.4
>

any suggestion?

Re: + proc-commit-to-genradix.patch added to -mm tree

[Alexey Dobriyan]

On Mon, Dec 17, 2018 at 12:54:58PM -0800, a...@linux-foundation.org wrote:
> http://ozlabs.org/~akpm/mmots/broken-out/proc-commit-to-genradix.patch
> Subject: proc: commit to genradix
> 
> The new generic radix trees have a simpler API and implementation, and no
> limitations on number of elements, so all flex_array users are being
> converted

> --- a/fs/proc/base.c~proc-commit-to-genradix
> +++ a/fs/proc/base.c
> @@ -2142,11 +2142,12 @@ proc_map_files_readdir(struct file *file
>   struct task_struct *task;
>   struct mm_struct *mm;
>   unsigned long nr_files, pos, i;
> - struct flex_array *fa = NULL;
> - struct map_files_info info;
> + GENRADIX(struct map_files_info) fa;
>   struct map_files_info *p;
>   int ret;
>  
> + genradix_init();

Reviewed-by: Alexey Dobriyan 

I'll try to check performance after New Year.

Re: [PATCH 2/2] USB: storage: add quirk for SMI SM3350

[Icenowy Zheng]

在 2018-12-27四的 22:34 +0800，Icenowy Zheng写道：
> The SMI SM3350 USB-UFS bridge controller cannot handle long sense
> request
> correctly and will make the chip refuse to do read/write when
> requested
> long sense.
> 
> Add a bad sense quirk for it.
> 
> Signed-off-by: Icenowy Zheng 
> ---

I forgot to:

Cc: sta...@vger.kernel.org

>  drivers/usb/storage/unusual_devs.h | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/usb/storage/unusual_devs.h
> b/drivers/usb/storage/unusual_devs.h
> index f7f83b21dc74..ea0d27a94afe 100644
> --- a/drivers/usb/storage/unusual_devs.h
> +++ b/drivers/usb/storage/unusual_devs.h
> @@ -1265,6 +1265,18 @@ UNUSUAL_DEV( 0x090c, 0x1132, 0x, 0x,
>   USB_SC_DEVICE, USB_PR_DEVICE, NULL,
>   US_FL_FIX_CAPACITY ),
>  
> +/*
> + * Reported by Icenowy Zheng 
> + * The SMI SM3350 USB-UFS bridge controller will enter a wrong state
> + * that do not process read/write command if a long sense is
> requested,
> + * so force to use 18-byte sense.
> + */
> +UNUSUAL_DEV(  0x090c, 0x3350, 0x, 0x,
> + "SMI",
> + "SM3350 UFS-to-USB-Mass-Storage bridge",
> + USB_SC_DEVICE, USB_PR_DEVICE, NULL,
> + US_FL_BAD_SENSE ),
> +
>  /*
>   * Reported by Paul Hartman 
>   * This card reader returns "Illegal Request, Logical Block Address

Re: [PATCH 1/2] USB: storage: don't insert sane sense for SPC3+ when bad sense specified

[Icenowy Zheng]

在 2018-12-27四的 22:34 +0800，Icenowy Zheng写道：
> Currently the code will set US_FL_SANE_SENSE flag unconditionally if
> device claims SPC3+, however we should allow US_FL_BAD_SENSE flag to
> prevent this behavior, because SMI SM3350 UFS-USB bridge controller,
> which claims SPC4, will show strange behavior with 96-byte sense
> (put the chip into a wrong state that cannot read/write anything).
> 
> Check the presence of US_FL_BAD_SENSE when assuming US_FL_SANE_SENSE
> on
> SPC4+ devices.
> 
> Signed-off-by: Icenowy Zheng 
> ---

I forgot to:

Cc: sta...@vger.kernel.org

>  drivers/usb/storage/scsiglue.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/storage/scsiglue.c
> b/drivers/usb/storage/scsiglue.c
> index fde2e71a6ade..699fe9557127 100644
> --- a/drivers/usb/storage/scsiglue.c
> +++ b/drivers/usb/storage/scsiglue.c
> @@ -236,7 +236,8 @@ static int slave_configure(struct scsi_device
> *sdev)
>   sdev->try_rc_10_first = 1;
>  
>   /* assume SPC3 or latter devices support sense size >
> 18 */
> - if (sdev->scsi_level > SCSI_SPC_2)
> + if (sdev->scsi_level > SCSI_SPC_2 &&
> + !(us->fflags & US_FL_BAD_SENSE))
>   us->fflags |= US_FL_SANE_SENSE;
>  
>   /*

[PATCH 1/2] USB: storage: don't insert sane sense for SPC3+ when bad sense specified

[Icenowy Zheng]

Currently the code will set US_FL_SANE_SENSE flag unconditionally if
device claims SPC3+, however we should allow US_FL_BAD_SENSE flag to
prevent this behavior, because SMI SM3350 UFS-USB bridge controller,
which claims SPC4, will show strange behavior with 96-byte sense
(put the chip into a wrong state that cannot read/write anything).

Check the presence of US_FL_BAD_SENSE when assuming US_FL_SANE_SENSE on
SPC4+ devices.

Signed-off-by: Icenowy Zheng 
---
 drivers/usb/storage/scsiglue.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
index fde2e71a6ade..699fe9557127 100644
--- a/drivers/usb/storage/scsiglue.c
+++ b/drivers/usb/storage/scsiglue.c
@@ -236,7 +236,8 @@ static int slave_configure(struct scsi_device *sdev)
sdev->try_rc_10_first = 1;
 
/* assume SPC3 or latter devices support sense size > 18 */
-   if (sdev->scsi_level > SCSI_SPC_2)
+   if (sdev->scsi_level > SCSI_SPC_2 &&
+   !(us->fflags & US_FL_BAD_SENSE))
us->fflags |= US_FL_SANE_SENSE;
 
/*
-- 
2.18.1

[PATCH 2/2] USB: storage: add quirk for SMI SM3350

[Icenowy Zheng]

The SMI SM3350 USB-UFS bridge controller cannot handle long sense request
correctly and will make the chip refuse to do read/write when requested
long sense.

Add a bad sense quirk for it.

Signed-off-by: Icenowy Zheng 
---
 drivers/usb/storage/unusual_devs.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/usb/storage/unusual_devs.h 
b/drivers/usb/storage/unusual_devs.h
index f7f83b21dc74..ea0d27a94afe 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -1265,6 +1265,18 @@ UNUSUAL_DEV( 0x090c, 0x1132, 0x, 0x,
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_FIX_CAPACITY ),
 
+/*
+ * Reported by Icenowy Zheng 
+ * The SMI SM3350 USB-UFS bridge controller will enter a wrong state
+ * that do not process read/write command if a long sense is requested,
+ * so force to use 18-byte sense.
+ */
+UNUSUAL_DEV(  0x090c, 0x3350, 0x, 0x,
+   "SMI",
+   "SM3350 UFS-to-USB-Mass-Storage bridge",
+   USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+   US_FL_BAD_SENSE ),
+
 /*
  * Reported by Paul Hartman 
  * This card reader returns "Illegal Request, Logical Block Address
-- 
2.18.1

[PATCH 0/2] USB Storage quirk for SMI SM3350

[Icenowy Zheng]

SMI SM3350 UFS-USB bridge controller cannot handle REQUEST SENSE command
with long sense (96-bytes) well, and will even trap the controller into
a state that refuses to do read/write command.

Currently Linux uncondintionally set US_FL_SANE_SENSE for devices
claiming SPC3+, which makes simply add US_FL_BAD_SENSE for SM3350 fail
(as it claims SPC4).

Fix this conflicting quirk issue, and add the quirk for SM3350.

Icenowy Zheng (2):
  USB: storage: don't insert sane sense for SPC3+ when bad sense
specified
  USB: storage: add quirk for SMI SM3350

 drivers/usb/storage/scsiglue.c |  3 ++-
 drivers/usb/storage/unusual_devs.h | 12 
 2 files changed, 14 insertions(+), 1 deletion(-)

-- 
2.18.1

[GIT PULL] MMC updates for v4.21

[Ulf Hansson]

Hi Linus,

Here's the PR with MMC updates for v4.21. Details about the highlights are as
usual found in the signed tag. Please pull this in!

This time, the PR contains changes crossing subsystems/archs/platforms, which
is mainly because of a bigger modernization of moving from legacy GPIO to GPIO
descriptors for MMC (by Linus Walleij). Additionally, again, I am funneling
changes to drivers/misc/cardreader/* and drivers/memstick/*, through my MMC
tree, mostly due to that we lack a maintainer for these. Perhaps, I should
simply volunteer and make that the formal process, let's see.

Happy holidays!

Kind regards
Ulf Hansson


The following changes since commit e3ae3401aa19432ee4943eb0bbc2ec704d07d793:

  mmc: core: Use a minimum 1600ms timeout when enabling CACHE ctrl (2018-12-17 
08:59:42 +0100)

are available in the Git repository at:

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

for you to fetch changes up to 5215b2e952f3f94d74cac1a59494eb8ac647e216:

  mmc: mediatek: Add MMC_CAP_SDIO_IRQ support (2018-12-19 10:16:15 +0100)


MMC core:
 - Cleanup BKOPS support
 - Introduce MMC_CAP_SYNC_RUNTIME_PM
 - slot-gpio: Delete legacy slot GPIO handling

MMC host:
 - alcor: Add new mmc host driver for Alcor Micro PCI based cardreader
 - bcm2835: Several improvements to better recover from errors
 - jz4740: Rework and fixup pre|post_req support
 - mediatek: Add support for SDIO IRQs
 - meson-gx: Improve clock phase management
 - meson-gx: Stop descriptor on errors
 - mmci: Complete the sbc error path by sending a stop command
 - renesas_sdhi/tmio: Fixup reset/resume operations
 - renesas_sdhi: Add support for r8a774c0 and R7S9210
 - renesas_sdhi: Whitelist R8A77990 SDHI
 - renesas_sdhi: Fixup eMMC HS400 compatibility issues for H3 and M3-W
 - rtsx_usb_sdmmc: Re-work card detection/removal support
 - rtsx_usb_sdmmc: Re-work runtime PM support
 - sdhci: Fix timeout loops for some variant drivers
 - sdhci: Improve support for error handling due to failing commands
 - sdhci-acpi/pci: Disable LED control for Intel BYT-based controllers
 - sdhci_am654: Add new SDHCI variant driver to support TI's AM654 SOCs
 - sdhci-of-esdhc: Add support for eMMC HS400 mode
 - sdhci-omap: Fixup reset support
 - sdhci-omap: Workaround errata regarding SDR104/HS200 tuning failures
 - sdhci-msm: Fixup sporadic write transfers issues for SDR104/HS200
 - sdhci-msm: Fixup dynamical clock gating issues
 - various: Complete converting all hosts into using slot GPIO descriptors

Other:
 - Move GPIO mmc platform data for mips/sh/arm to GPIO descriptors
 - Add new Alcor Micro cardreader PCI driver
 - Support runtime power management for memstick rtsx_usb_ms driver
 - Use USB remote wakeups for card detection for rtsx_usb misc driver


A.s. Dong (1):
  dt-bindings: mmc: fsl-imx-esdhc: add imx8qxp compatible string

Adrian Hunter (10):
  mmc: sdhci: Fix data command CRC error handling
  mmc: sdhci: Rename SDHCI_ACMD12_ERR and SDHCI_INT_ACMD12ERR
  mmc: sdhci: Handle auto-command errors
  mmc: sdhci-pci: Add max-frequency device property for Intel controllers
  mmc: sdhci-of-esdhc: Fix timeout checks
  mmc: sdhci-omap: Fix timeout checks
  mmc: sdhci-xenon: Fix timeout checks
  mmc: sdhci: Add quirk to disable LED control
  mmc: sdhci-pci: Disable LED control for Intel BYT-based controllers
  mmc: sdhci-acpi: Disable LED control for Intel BYT-based controllers

Arnd Bergmann (1):
  mmc: sdhci-msm: avoid unused function warning

Biju Das (1):
  mmc: renesas_sdhi_internal_dmac: Whitelist r8a774c0

Chris Brandt (2):
  mmc: renesas_sdhi_internal_dmac: Add R7S9210 support
  dt-bindings: mmc: tmio_mmc: Document Renesas R7S9210

Chunyan Zhang (1):
  mmc: sdhci: Convert sdhci_allocate_bounce_buffer() to return void

Colin Ian King (2):
  mmc: sdhci-of-esdhc: fix spelling mistake "upsupported" -> "unsupported"
  misc: alcor_pci: fix spelling mistake "invailid" -> "invalid"

Evan Green (1):
  dt-bindings: mmc: sdhci-msm: Clarify register requirements

Ezequiel Garcia (1):
  mmc: jz4740: rework pre_req/post_req implementation

Fabrizio Castro (1):
  dt-bindings: mmc: renesas_sdhi: Add r8a774c0 support

Faiz Abbas (7):
  mmc: sdhci-omap: Add platform specific reset callback
  mmc: sdhci-omap: Remove redundant structure assignments
  dt-bindings: mmc: sdhci-am654: Document bindings for the host controllers 
on TI's AM654 SOCs
  dt-bindings: mmc: sdhci-of-arasan: Add deprecated message for AM65
  mmc: sdhci_am654: Add Initial Support for AM654 SDHCI driver
  dt-bindings: sdhci-omap: Add note for cpu_thermal
  mmc: sdhci-omap: Workaround errata regarding SDR104/HS200 tuning failures 
(i929)

Jerome Brunet (4):
  mmc: meson-gx: make sure the descriptor is stopped on errors
  mmc: meson-gx: 

Re: [PATCH v3 7/9] drm/komeda: Attach komeda_dev to DRM-KMS

[Liviu Dudau]

On Thu, Dec 27, 2018 at 07:09:07AM +, james qian wang (Arm Technology 
China) wrote:
> On Mon, Dec 24, 2018 at 08:32:14PM +0800, Liviu Dudau wrote:
> > On Fri, Dec 21, 2018 at 10:00:33AM +, james qian wang (Arm Technology 
> > China) wrote:
> > > Add komeda_kms abstracton to attach komeda_dev to DRM-KMS
> > >   CRTC: according to the komeda_pipeline
> > >   PLANE: according to komeda_layer (layer input pipeline)
> > >   PRIVATE_OBJS: komeda_pipeline/component all will be treat as 
> > > private_objs
> > > 
> > > komeda_kms is for connecting DRM-KMS and komeda_dev, like reporting the
> > > kms object properties according to the komeda_dev, and pass/convert KMS's
> > > requirement to komeda_dev.
> > > 
> > > Changes in v3:
> > > - Fixed style problem found by checkpatch.pl --strict.
> > > 
> > > Changes in v2:
> > > - Unified abbreviation of "pipeline" to "pipe".
> > > 
> > > Signed-off-by: James (Qian) Wang 
> > > ---
> > >  drivers/gpu/drm/arm/display/komeda/Makefile   |   6 +-
> > >  .../gpu/drm/arm/display/komeda/komeda_crtc.c  | 106 +++
> > >  .../gpu/drm/arm/display/komeda/komeda_drv.c   |  19 +-
> > >  .../gpu/drm/arm/display/komeda/komeda_kms.c   | 169 ++
> > >  .../gpu/drm/arm/display/komeda/komeda_kms.h   | 113 
> > >  .../drm/arm/display/komeda/komeda_pipeline.h  |   3 +
> > >  .../gpu/drm/arm/display/komeda/komeda_plane.c | 109 +++
> > >  .../arm/display/komeda/komeda_private_obj.c   |  88 +
> > >  8 files changed, 608 insertions(+), 5 deletions(-)
> > >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> > >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> > >  create mode 100644 
> > > drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c
> > > 
> > > diff --git a/drivers/gpu/drm/arm/display/komeda/Makefile 
> > > b/drivers/gpu/drm/arm/display/komeda/Makefile
> > > index 25beae900ed2..1b875e5dc0f6 100644
> > > --- a/drivers/gpu/drm/arm/display/komeda/Makefile
> > > +++ b/drivers/gpu/drm/arm/display/komeda/Makefile
> > > @@ -9,7 +9,11 @@ komeda-y := \
> > >   komeda_dev.o \
> > >   komeda_format_caps.o \
> > >   komeda_pipeline.o \
> > > - komeda_framebuffer.o
> > > + komeda_framebuffer.o \
> > > + komeda_kms.o \
> > > + komeda_crtc.o \
> > > + komeda_plane.o \
> > > + komeda_private_obj.o
> > >  
> > >  komeda-y += \
> > >   d71/d71_dev.o
> > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
> > > b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > > new file mode 100644
> > > index ..5bb5a55f6b31
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > > @@ -0,0 +1,106 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * (C) COPYRIGHT 2018 ARM Limited. All rights reserved.
> > > + * Author: James.Qian.Wang 
> > > + *
> > > + */
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include "komeda_dev.h"
> > > +#include "komeda_kms.h"
> > > +
> > > +struct drm_crtc_helper_funcs komeda_crtc_helper_funcs = {
> > > +};
> > > +
> > > +static const struct drm_crtc_funcs komeda_crtc_funcs = {
> > > +};
> > > +
> > > +int komeda_kms_setup_crtcs(struct komeda_kms_dev *kms,
> > > +struct komeda_dev *mdev)
> > > +{
> > > + struct komeda_crtc *crtc;
> > > + struct komeda_pipeline *master;
> > > + char str[16];
> > > + int i;
> > > +
> > > + kms->n_crtcs = 0;
> > > +
> > > + for (i = 0; i < mdev->n_pipelines; i++) {
> > > + crtc = >crtcs[kms->n_crtcs];
> > > + master = mdev->pipelines[i];
> > > +
> > > + crtc->master = master;
> > > + crtc->slave  = NULL;
> > > +
> > > + if (crtc->slave)
> > > + sprintf(str, "pipe-%d", crtc->slave->id);
> > > + else
> > > + sprintf(str, "None");
> > > +
> > > + DRM_INFO("crtc%d: master(pipe-%d) slave(%s) output: %s.\n",
> > > +  kms->n_crtcs, master->id, str,
> > > +  master->of_output_dev ?
> > > +  master->of_output_dev->full_name : "None");
> > > +
> > > + kms->n_crtcs++;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static struct drm_plane *
> > > +get_crtc_primary(struct komeda_kms_dev *kms, struct komeda_crtc *crtc)
> > > +{
> > > + struct komeda_plane *kplane;
> > > + struct drm_plane *plane;
> > > +
> > > + drm_for_each_plane(plane, >base) {
> > > + if (plane->type != DRM_PLANE_TYPE_PRIMARY)
> > > + continue;
> > > +
> > > + kplane = to_kplane(plane);
> > > + /* only master can be primary */
> > > + if (kplane->layer->base.pipeline == crtc->master)
> > > + return plane;
> > > + }
> > > +
> > > + return NULL;
> > > +}
> > > +
> > > +static 

Re: [PATCH] KVM: X86: Fix scan ioapic use-before-initialization

[Dmitry Vyukov]

On Sun, Nov 25, 2018 at 6:31 PM Paolo Bonzini  wrote:
>
> On 20/11/18 09:34, Wanpeng Li wrote:
> > From: Wanpeng Li 
> > ...
> > This patch fixes it by bailing out scan ioapic if ioapic is not initialized 
> > in
> > kernel.
> > Reported-by: Wei Wu 

+Linus, Greg

I want to point out that this was reported more then 3 months ago by syzbot:
https://groups.google.com/forum/#!msg/syzkaller-bugs/cPT7tmaz-gQ/SzOyhM0YBAAJ
then the report was lost on kernel mailing lists and then re-reported
by somebody else:
https://www.spinics.net/lists/kvm/msg177705.html
and only then fixed.

Lots of kernel bug reports routinely get lost on mailing lists, which is bad.

Another bug was reported by syzbot in April:
https://groups.google.com/forum/#!msg/syzkaller-bugs/-9XIT9gwq7M/sqvBXSZWBgAJ
then get lost and then re-reported in November:
https://www.spinics.net/lists/kvm/msg177704.html
and only then fixed.

Not specific for KVM, another bug in kernel/trace reported by syzbot,
lost for months, then re-reported and fixed:
https://groups.google.com/forum/#!msg/syzkaller-bugs/o_-OeMyoTwg/Ugh432hlAgAJ
https://bugzilla.kernel.org/show_bug.cgi?id=200019

And, no, it's not that people ignore just syzbot reports. It's just
that syzbot reports can be tracked so it's easier to spot such cases,
for manually reported bugs nobody usually knows anything after few
weeks. Here is an example of bug report by a human, which was even
replied but then slipped from somebody's attention set for a moment
and then complete oblivion. Months later happened to be re-reported by
syzbot and then fixed:
https://groups.google.com/forum/#!msg/syzkaller-bugs/wFUedfOK2Rw/waUrQYOxAQAJ

Re-reported a year later bugs can cause security problems and large
amounts of work to backport the fix to thousands of downstream kernel
forks. Not re-reported bugs are even worse as they are just not fixed.

This Plumbers I was approached by Doug Ledford from Redhat, who said
literally that there was a bunch of syzbot reports in rdma subsystem
but since they were reported some time ago, now nobody knows
what/where are they. So while the bugs are still presumably there, now
they are completely unactionable and kernel development process is
incapable of dealing with this. While syzbot reports have some chances
of being recovered, this equally applies to human-reported bugs and
they can't be easily recovered.

This does not looks like how things should be for the most critical
and fundamental software project in the world. Lost bugs/patches
should not be a thing. There are known working solutions for this in
the form of tooling and procedures, namely bug tracking. Any bug
tracking systems allows to answer the main question: what are the
active bugs, sorted by priority, in subsystem X/assigned to me; and
lots of other useful questions.

And, yes, I know we have bugazilla. But it's not being used as a bug
tracking system as of now. And when used, sometimes cause more trouble
because nobody expects bugs to be there:
https://lwn.net/ml/linux-kernel/20181208115629.ga3...@kroah.com/

Re: [PATCH v3 7/9] drm/komeda: Attach komeda_dev to DRM-KMS

[Liviu Dudau]

On Thu, Dec 27, 2018 at 07:09:07AM +, james qian wang (Arm Technology 
China) wrote:
> On Mon, Dec 24, 2018 at 08:32:14PM +0800, Liviu Dudau wrote:
> > On Fri, Dec 21, 2018 at 10:00:33AM +, james qian wang (Arm Technology 
> > China) wrote:
> > > Add komeda_kms abstracton to attach komeda_dev to DRM-KMS
> > >   CRTC: according to the komeda_pipeline
> > >   PLANE: according to komeda_layer (layer input pipeline)
> > >   PRIVATE_OBJS: komeda_pipeline/component all will be treat as 
> > > private_objs
> > > 
> > > komeda_kms is for connecting DRM-KMS and komeda_dev, like reporting the
> > > kms object properties according to the komeda_dev, and pass/convert KMS's
> > > requirement to komeda_dev.
> > > 
> > > Changes in v3:
> > > - Fixed style problem found by checkpatch.pl --strict.
> > > 
> > > Changes in v2:
> > > - Unified abbreviation of "pipeline" to "pipe".
> > > 
> > > Signed-off-by: James (Qian) Wang 
> > > ---
> > >  drivers/gpu/drm/arm/display/komeda/Makefile   |   6 +-
> > >  .../gpu/drm/arm/display/komeda/komeda_crtc.c  | 106 +++
> > >  .../gpu/drm/arm/display/komeda/komeda_drv.c   |  19 +-
> > >  .../gpu/drm/arm/display/komeda/komeda_kms.c   | 169 ++
> > >  .../gpu/drm/arm/display/komeda/komeda_kms.h   | 113 
> > >  .../drm/arm/display/komeda/komeda_pipeline.h  |   3 +
> > >  .../gpu/drm/arm/display/komeda/komeda_plane.c | 109 +++
> > >  .../arm/display/komeda/komeda_private_obj.c   |  88 +
> > >  8 files changed, 608 insertions(+), 5 deletions(-)
> > >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> > >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> > >  create mode 100644 
> > > drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c
> > > 
> > > diff --git a/drivers/gpu/drm/arm/display/komeda/Makefile 
> > > b/drivers/gpu/drm/arm/display/komeda/Makefile
> > > index 25beae900ed2..1b875e5dc0f6 100644
> > > --- a/drivers/gpu/drm/arm/display/komeda/Makefile
> > > +++ b/drivers/gpu/drm/arm/display/komeda/Makefile
> > > @@ -9,7 +9,11 @@ komeda-y := \
> > >   komeda_dev.o \
> > >   komeda_format_caps.o \
> > >   komeda_pipeline.o \
> > > - komeda_framebuffer.o
> > > + komeda_framebuffer.o \
> > > + komeda_kms.o \
> > > + komeda_crtc.o \
> > > + komeda_plane.o \
> > > + komeda_private_obj.o
> > >  
> > >  komeda-y += \
> > >   d71/d71_dev.o
> > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
> > > b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > > new file mode 100644
> > > index ..5bb5a55f6b31
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > > @@ -0,0 +1,106 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * (C) COPYRIGHT 2018 ARM Limited. All rights reserved.
> > > + * Author: James.Qian.Wang 
> > > + *
> > > + */
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include "komeda_dev.h"
> > > +#include "komeda_kms.h"
> > > +
> > > +struct drm_crtc_helper_funcs komeda_crtc_helper_funcs = {
> > > +};
> > > +
> > > +static const struct drm_crtc_funcs komeda_crtc_funcs = {
> > > +};
> > > +
> > > +int komeda_kms_setup_crtcs(struct komeda_kms_dev *kms,
> > > +struct komeda_dev *mdev)
> > > +{
> > > + struct komeda_crtc *crtc;
> > > + struct komeda_pipeline *master;
> > > + char str[16];
> > > + int i;
> > > +
> > > + kms->n_crtcs = 0;
> > > +
> > > + for (i = 0; i < mdev->n_pipelines; i++) {
> > > + crtc = >crtcs[kms->n_crtcs];
> > > + master = mdev->pipelines[i];
> > > +
> > > + crtc->master = master;
> > > + crtc->slave  = NULL;
> > > +
> > > + if (crtc->slave)
> > > + sprintf(str, "pipe-%d", crtc->slave->id);
> > > + else
> > > + sprintf(str, "None");
> > > +
> > > + DRM_INFO("crtc%d: master(pipe-%d) slave(%s) output: %s.\n",
> > > +  kms->n_crtcs, master->id, str,
> > > +  master->of_output_dev ?
> > > +  master->of_output_dev->full_name : "None");
> > > +
> > > + kms->n_crtcs++;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static struct drm_plane *
> > > +get_crtc_primary(struct komeda_kms_dev *kms, struct komeda_crtc *crtc)
> > > +{
> > > + struct komeda_plane *kplane;
> > > + struct drm_plane *plane;
> > > +
> > > + drm_for_each_plane(plane, >base) {
> > > + if (plane->type != DRM_PLANE_TYPE_PRIMARY)
> > > + continue;
> > > +
> > > + kplane = to_kplane(plane);
> > > + /* only master can be primary */
> > > + if (kplane->layer->base.pipeline == crtc->master)
> > > + return plane;
> > > + }
> > > +
> > > + return NULL;
> > > +}
> > > +
> > > +static 

iMX6 FEC driver Linux-fslc 4.17 - IPV6 Multicast not working when unplugging/plugging ethernet cable

[Stefano Cappa]

Hi everyone,
I already posted this in NXP forum as a comment
(https://community.nxp.com/thread/359397), in yocto mailing list
(https://lists.yoctoproject.org/pipermail/yocto/2018-December/043664.html)
and in meta-freescale mailing list
(https://lists.yoctoproject.org/pipermail/meta-freescale/2018-December/023625.html)
A user in meta-freescale's mailing list suggested to resend this
message to the emails obtained running "./scripts/get_maintainer.pl -F
drivers/net/ethernet/freescale/fec_main.c".


The problem is:

If I boot my iMX6 device with ethernet cable attached and I execute "ping6
ff02::fb" to ping the multicast address I get this response:
~# ping6 ff02::fb
PING ff02::fb (ff02::fb): 56 data bytes
64 bytes from fe80::c2f:eff:fe11:2d71: seq=0 ttl=64 time=2.057 ms
64 bytes from fe80::809:1bfb:8d4c:ae54: seq=0 ttl=64 time=73.101 ms (DUP!)
64 bytes from fe80::3e28:6dff:feed:5b97: seq=0 ttl=64 time=150.772 ms
(DUP!)


Otherwise, If I unplug and plug again ethernet cable, I cannot ping the
multicast ipv6 address anymore.
The result is:
~# ping6 ff02::fb
PING ff02::fb (ff02::fb): 56 data bytes
ping6: sendto: Network is unreachable


The original NXP discussion was about older version of Linux, however
this issue is happening with both Linux 4.9.88 and Linux 4.17.
Probably also with the latest version, but I didn't try.


Do you have any suggestions? Is this a bug? This is really a
frustrating and I'm really
surprised to see the same problem also on Linux 4.17.


PS: I'm sorry for the double email, but the previous one was in html
and it was rejected.

Thank u.

Re: [PATCH] i2c: bcm2835: Clear current message and count after a transaction

[Stefan Wahren]

Hi Paul,

> Paul Kocialkowski  hat am 24. Dezember 2018 um 
> 10:10 geschrieben:
> 
> 
> Hi,
> 
> On Sat, 2018-12-22 at 13:19 +0100, Stefan Wahren wrote:
> > Hi Paul,
> > 
> > > Paul Kocialkowski  hat am 21. Dezember 
> > > 2018 um 13:11 geschrieben:
> > > 
> > > 
> > > The driver's interrupt handler checks whether a message is currently
> > > being handled with the curr_msg pointer. When it is NULL, the interrupt
> > > is considered to be unexpected. Similarly, the i2c_start_transfer
> > > routine checks for the remaining number of messages to handle in
> > > num_msgs.
> > > 
> > > However, these values are never cleared and always keep the message and
> > > number relevant to the latest transfer (which might be done already and
> > > the underlying message memory might have been freed).
> > > 
> > > When an unexpected interrupt hits with the DONE bit set, the isr will
> > > then try to access the flags field of the curr_msg structure, leading
> > > to a fatal page fault.
> > > 
> > > Fix the issue by systematically clearing curr_msg and num_msgs in the
> > > driver-wide device structure when a transfer is considered complete.
> > > 
> > > Signed-off-by: Paul Kocialkowski 
> > > ---
> > >  drivers/i2c/busses/i2c-bcm2835.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > > 
> > > diff --git a/drivers/i2c/busses/i2c-bcm2835.c 
> > > b/drivers/i2c/busses/i2c-bcm2835.c
> > > index 44deae78913e..5486252f5f2f 100644
> > > --- a/drivers/i2c/busses/i2c-bcm2835.c
> > > +++ b/drivers/i2c/busses/i2c-bcm2835.c
> > > @@ -298,6 +298,9 @@ static int bcm2835_i2c_xfer(struct i2c_adapter *adap, 
> > > struct i2c_msg msgs[],
> > >   return -ETIMEDOUT;
> > >   }
> > >  
> > > + i2c_dev->curr_msg = NULL;
> > > + i2c_dev->num_msgs = 0;
> > 
> > AFAIU this would reduce the chance of a use-after-free dramatically but not 
> > completely.
> 
> Do you have a specific case of use-after-free related to these
> variables in mind that this cleanup would not fix (except for the
> timeout case)?

okay i was wrong about the use-after-free. But i'm not sure about this scenario 
on the I2C bus shared with the VC4:

1. ARM core starts I2C transfer (bcm2835_i2c_start_transfer)
2. VC4 triggers a BCM2835_I2C_S_DONE interrupt
3. ARM core catches this interrupt before the VC4

Stefan

> 
> The msg_buf element (in association with msg_buf_remaining keeping its
> previous value) could also lead to similar problems, so I'm thinking of
> making a bcm2835_i2c_finish_transfer function to group all the cleanups
> and call that right after wait_for_completion_timeout.
> 
> > Btw: Why did you leave of the i2c transfer timeout case?
> 
> I should definitely have included it, actually.
> 
> Cheers,
> 
> Paul
> 
> > Thanks
> > Stefan
> > 
> > > +
> > >   if (!i2c_dev->msg_err)
> > >   return num;
> > >  
> > > -- 
> > > 2.20.1
> > > 
> -- 
> Paul Kocialkowski, Bootlin (formerly Free Electrons)
> Embedded Linux and kernel engineering
> https://bootlin.com
>

Re: [PATCH 00/20] drop useless LIST_HEAD

[Dan Carpenter]

On Tue, Dec 25, 2018 at 11:12:20PM +0100, Tom Psyborg wrote:
> there was discussion about this just some days ago. CC 4-5 lists is
> more than enough
> 

I don't know who you were discussing this with...

You should CC the 0th patch to all the mailinglists.  That much is a
clear rule.

For the rest, Julia's position is the more conservative one.  I was in
a conversation in RL and they were like, "CC everyone for all the
patches".  It depends on the context, of course.  If the patches are
dependent on each other then you *have* to CC everyone for everything.

If we really have other clear rules, then it should be encoded into
get_maintainer.pl so that it's automatic.

My other question is why do the linux-arm-ker...@lists.infradead.org
people feel like they need to be CC'd about every driver???  I always
remove them from the CC list unless it's an arch/arm issue.

regards,
dan carpenter

PS:  Please, no more top posting.

RE: [PATCH v2 5/5] usb:cdns3 Add Cadence USB3 DRD Driver

[Pawel Laszczak]

HI,

>>
>> The host side of USBSS-DRD controller is compliance
>> with XHCI specification, so it works with
>> standard XHCI linux driver.
>>
>
>After adding my glue layer change (with my phy part) and make one
>change for this code,
>the xHCI can work at my platform. I list the comments from today's
>review and debug.
>The comments are at  Makefile and drd.c.
>
>> + If you choose to build this driver as module it will
>> + be dynamically linked and module will be called cdns3-pci.ko
>> +
>> +endif
>> diff --git a/drivers/usb/cdns3/Makefile b/drivers/usb/cdns3/Makefile
>> new file mode 100644
>> index ..3f63baa24294
>> --- /dev/null
>> +++ b/drivers/usb/cdns3/Makefile
>> @@ -0,0 +1,16 @@
>> +# SPDX-License-Identifier: GPL-2.0
>> +# define_trace.h needs to know how to find our header
>> +CFLAGS_trace.o := -I$(src)
>> +
>> +obj-$(CONFIG_USB_CDNS3)+= cdns3.o
>> +obj-$(CONFIG_USB_CDNS3_PCI_WRAP)   += cdns3-pci.o
>> +
>> +cdns3-y:= core.o drd.o trace.o
>> +
>> +ifneq ($(CONFIG_DEBUG_FS),)
>> +   cdns3-y += debugfs.o
>> +endif
>> +
>> +cdns3-$(CONFIG_USB_CDNS3_GADGET)   += gadget.o ep0.o
>> +cdns3-$(CONFIG_USB_CDNS3_HOST) += host.o
>> +cdns3-pci-y:= cdns3-pci-wrap.o
>
>Why do you want add two lines for pci_wrap? I change this Makefile like below:

I don't need these two lines. I will change it as you suggested. 

>
># SPDX-License-Identifier: GPL-2.0
># define_trace.h needs to know how to find our header
>CFLAGS_trace.o  := -I$(src)
>
>cdns3-y := core.o drd.o trace.o
>obj-$(CONFIG_USB_CDNS3) += cdns3.o
>ifneq ($(CONFIG_DEBUG_FS),)
>cdns3-y += debugfs.o
>endif
>
>cdns3-$(CONFIG_USB_CDNS3_GADGET)+= gadget.o ep0.o
>cdns3-$(CONFIG_USB_CDNS3_HOST)  += host.o
>obj-$(CONFIG_USB_CDNS3_PCI_WRAP)+= cdns3-pci-wrap.o
>obj-$(CONFIG_USB_CDNS3_IMX_WRAP)+= cdns3-imx.o
>
>and below is the diff:
>
>diff --git a/drivers/usb/cdns3/Makefile b/drivers/usb/cdns3/Makefile
>index 3f63baa24294..d1bca2829f57 100644
>--- a/drivers/usb/cdns3/Makefile
>+++ b/drivers/usb/cdns3/Makefile
>@@ -2,15 +2,13 @@
> # define_trace.h needs to know how to find our header
> CFLAGS_trace.o := -I$(src)
>
>-obj-$(CONFIG_USB_CDNS3)+= cdns3.o
>-obj-$(CONFIG_USB_CDNS3_PCI_WRAP)   += cdns3-pci.o
>-
> cdns3-y:= core.o drd.o trace.o
>-
>+obj-$(CONFIG_USB_CDNS3)+= cdns3.o
> ifneq ($(CONFIG_DEBUG_FS),)
>cdns3-y += debugfs.o
> endif
>
> cdns3-$(CONFIG_USB_CDNS3_GADGET)   += gadget.o ep0.o
> cdns3-$(CONFIG_USB_CDNS3_HOST) += host.o
>-cdns3-pci-y:= cdns3-pci-wrap.o
>+obj-$(CONFIG_USB_CDNS3_PCI_WRAP)   += cdns3-pci-wrap.o
>+obj-$(CONFIG_USB_CDNS3_IMX_WRAP)   += cdns3-imx.o
>
>
>> diff --git a/drivers/usb/cdns3/drd.c b/drivers/usb/cdns3/drd.c
>> new file mode 100644
>> index ..b0c32302eb0b
>> --- /dev/null
>> +++ b/drivers/usb/cdns3/drd.c
>> @@ -0,0 +1,350 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Cadence USBSS DRD Driver.
>> + *
>> + * Copyright (C) 2018 Cadence.
>> + *
>> + * Author: Pawel Laszczak > + *
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "gadget.h"
>> +#include "drd.h"
>> +#include "core.h"
>> +
>> +static int cdns3_drd_switch_gadget(struct cdns3 *cdns, int on);
>> +static int cdns3_drd_switch_host(struct cdns3 *cdns, int on);
>> +
>> +/**
>> + * cdns3_set_mode - change mode of OTG Core
>> + * @cdns: pointer to context structure
>> + * @mode: selected mode from cdns_role
>> + */
>> +void cdns3_set_mode(struct cdns3 *cdns, enum usb_dr_mode mode)
>> +{
>> +   u32 reg;
>> +
>> +   cdns->current_dr_mode = mode;
>> +
>> +   switch (mode) {
>> +   case USB_DR_MODE_PERIPHERAL:
>> +   dev_info(cdns->dev, "Set controller to Gadget mode\n");
>> +   cdns3_drd_switch_gadget(cdns, 1);
>> +   break;
>> +   case USB_DR_MODE_HOST:
>> +   dev_info(cdns->dev, "Set controller to Host mode\n");
>> +   cdns3_drd_switch_host(cdns, 1);
>> +   break;
>> +   case USB_DR_MODE_OTG:
>> +   dev_info(cdns->dev, "Set controller to OTG mode\n");
>> +   if (cdns->version == CDNS3_CONTROLLER_V1) {
>> +   reg = readl(>otg_v1_regs->override);
>> +   reg |= OVERRIDE_IDPULLUP;
>> +   writel(reg, >otg_v1_regs->override);
>> +   } else {
>> +   reg = readl(>otg_v0_regs->ctrl1);
>> +   reg |= OVERRIDE_IDPULLUP_V0;
>> +   writel(reg, >otg_v0_regs->ctrl1);
>> +   }
>> 

[PATCH 2/2] dmaengine: mediatek: Add MediaTek Command-Queue DMA controller for MT6765 SoC

[shun-chih.yu]

From: Shun-Chih Yu 

MediaTek Command-Queue DMA controller (CQDMA) on MT6765 SoC is dedicated
to memory-to-memory transfer through queue based descriptor management.

There are only 3 physical channels inside CQDMA, while the driver is
extended to support 32 virtual channels for multiple dma users to issue
dma requests onto the CQDMA simultaneously.

Change-Id: I1e8d116c5ecbbc49190ffc925cb59a0d035d886b
Signed-off-by: Shun-Chih Yu 
Reviewed-by: Vinod Koul 

---
 drivers/dma/mediatek/Kconfig |   12 +
 drivers/dma/mediatek/Makefile|1 +
 drivers/dma/mediatek/mtk-cqdma.c |  867 ++
 3 files changed, 880 insertions(+)
 create mode 100644 drivers/dma/mediatek/mtk-cqdma.c

diff --git a/drivers/dma/mediatek/Kconfig b/drivers/dma/mediatek/Kconfig
index 27bac0b..4a1582d 100644
--- a/drivers/dma/mediatek/Kconfig
+++ b/drivers/dma/mediatek/Kconfig
@@ -11,3 +11,15 @@ config MTK_HSDMA
  This controller provides the channels which is dedicated to
  memory-to-memory transfer to offload from CPU through ring-
  based descriptor management.
+
+config MTK_CQDMA
+   tristate "MediaTek Command-Queue DMA controller support"
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   select DMA_ENGINE
+   select DMA_VIRTUAL_CHANNELS
+   help
+ Enable support for Command-Queue DMA controller on MediaTek
+ SoCs.
+
+ This controller provides the channels which is dedicated to
+ memory-to-memory transfer to offload from CPU.
diff --git a/drivers/dma/mediatek/Makefile b/drivers/dma/mediatek/Makefile
index 6e778f8..41bb381 100644
--- a/drivers/dma/mediatek/Makefile
+++ b/drivers/dma/mediatek/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_MTK_HSDMA) += mtk-hsdma.o
+obj-$(CONFIG_MTK_CQDMA) += mtk-cqdma.o
diff --git a/drivers/dma/mediatek/mtk-cqdma.c b/drivers/dma/mediatek/mtk-cqdma.c
new file mode 100644
index 000..304eb0a
--- /dev/null
+++ b/drivers/dma/mediatek/mtk-cqdma.c
@@ -0,0 +1,867 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018-2019 MediaTek Inc.
+
+/*
+ * Driver for MediaTek Command-Queue DMA Controller
+ *
+ * Author: Shun-Chih Yu 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../virt-dma.h"
+
+#define MTK_CQDMA_USEC_POLL10
+#define MTK_CQDMA_TIMEOUT_POLL 1000
+#define MTK_CQDMA_DMA_BUSWIDTHSBIT(DMA_SLAVE_BUSWIDTH_4_BYTES)
+#define MTK_CQDMA_ALIGN_SIZE   1
+
+/* The default number of virtual channel */
+#define MTK_CQDMA_NR_VCHANS32
+
+/* The default number of physical channel */
+#define MTK_CQDMA_NR_PCHANS3
+
+/* Registers for underlying dma manipulation */
+#define MTK_CQDMA_INT_FLAG 0x0
+#define MTK_CQDMA_INT_EN   0x4
+#define MTK_CQDMA_EN   0x8
+#define MTK_CQDMA_RESET0xc
+#define MTK_CQDMA_FLUSH0x14
+#define MTK_CQDMA_SRC  0x1c
+#define MTK_CQDMA_DST  0x20
+#define MTK_CQDMA_LEN1 0x24
+#define MTK_CQDMA_LEN2 0x28
+#define MTK_CQDMA_SRC2 0x60
+#define MTK_CQDMA_DST2 0x64
+
+/* Registers setting */
+#define MTK_CQDMA_EN_BIT   BIT(0)
+#define MTK_CQDMA_INT_FLAG_BIT BIT(0)
+#define MTK_CQDMA_INT_EN_BIT   BIT(0)
+#define MTK_CQDMA_FLUSH_BITBIT(0)
+
+#define MTK_CQDMA_WARM_RST_BIT BIT(0)
+#define MTK_CQDMA_HARD_RST_BIT BIT(1)
+
+#define MTK_CQDMA_MAX_LEN  GENMASK(27, 0)
+#define MTK_CQDMA_ADDR_LIMIT   GENMASK(31, 0)
+#define MTK_CQDMA_ADDR2_SHFIT  (32)
+
+/**
+ * struct mtk_cqdma_vdesc - The struct holding info describing virtual
+ * descriptor (CVD)
+ * @vd:An instance for struct virt_dma_desc
+ * @len:   The total data size device wants to move
+ * @dest:  The destination address device wants to move to
+ * @src:   The source address device wants to move from
+ * @ch:The pointer to the corresponding dma channel
+ * @node:  To build linked-list for PC queue
+ */
+struct mtk_cqdma_vdesc {
+   struct virt_dma_desc vd;
+   size_t len;
+   dma_addr_t dest;
+   dma_addr_t src;
+   struct dma_chan *ch;
+
+   /* protected by pc.lock */
+   struct list_head node;
+};
+
+/**
+ * struct mtk_cqdma_pchan - The struct holding info describing physical
+ * channel (PC)
+ * @queue: Queue for the CVDs issued to this PC
+ * @base:  The mapped register I/O base of this PC
+ * @irq:   The IRQ that this PC are using
+ * @refcnt:Track how many VCs are using this PC
+ * @lock: Lock protect 

[PATCH v4] add support for Mediatek Command-Queue DMA controller on MT6765 SoC

[shun-chih.yu]

Changes since v3:
- simplify the ISR and management on descriptors by removing tasklet and 
ASYNC_TX_ENABLE_CHANNEL_SWITCH
- remove useless field in mtk_cqdma_vdesc structure
- change dev_info to dev_dbg
- fix typos

Changes since v2:
- fix build warning for kernel with DMA address in 32-bit

Changes since v1:
- remove unused macros, typos
- leverage ASYNC_TX_ENABLE_CHANNEL_SWITCH to maintain DMA descriptor list


Shun-Chih Yu (2):
  dt-bindings: dmaengine: Add MediaTek Command-Queue DMA controller
bindings
  dmaengine: mediatek: Add MediaTek Command-Queue DMA controller for
MT6765 SoC

 .../devicetree/bindings/dma/mtk-cqdma.txt |  31 +
 drivers/dma/mediatek/Kconfig  |  12 +
 drivers/dma/mediatek/Makefile |   1 +
 drivers/dma/mediatek/mtk-cqdma.c  | 867 ++
 4 files changed, 911 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/mtk-cqdma.txt
 create mode 100644 drivers/dma/mediatek/mtk-cqdma.c

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

[shun-chih.yu]

From: Shun-Chih Yu 

Document the devicetree bindings for MediaTek Command-Queue DMA controller
which could be found on MT6765 SoC or other similar Mediatek SoCs.

Change-Id: I9736c8cac9be160358feeab935fabaffc5730519
Signed-off-by: Shun-Chih Yu 
Reviewed-by: Rob Herring 
---
 .../devicetree/bindings/dma/mtk-cqdma.txt  |   31 
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/mtk-cqdma.txt

diff --git a/Documentation/devicetree/bindings/dma/mtk-cqdma.txt 
b/Documentation/devicetree/bindings/dma/mtk-cqdma.txt
new file mode 100644
index 000..fb12927
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/mtk-cqdma.txt
@@ -0,0 +1,31 @@
+MediaTek Command-Queue DMA Controller
+==
+
+Required properties:
+
+- compatible:  Must be "mediatek,mt6765-cqdma" for MT6765.
+- reg: Should contain the base address and length for each channel.
+- interrupts:  Should contain references to the interrupts for each channel.
+- clocks:  Should be the clock specifiers corresponding to the entry in
+   clock-names property.
+- clock-names: Should contain "cqdma" entries.
+- dma-channels: The number of DMA channels supported by the controller.
+- dma-requests: The number of DMA request supported by the controller.
+- #dma-cells:  The length of the DMA specifier, must be <1>. This one cell
+   in dmas property of a client device represents the channel
+   number.
+Example:
+
+cqdma: dma-controller@10212000 {
+   compatible = "mediatek,mt6765-cqdma";
+   reg = <0 0x10212000 0 0x1000>;
+   interrupts = ,
+   ;
+   clocks = < CLK_IFR_CQ_DMA>;
+   clock-names = "cqdma";
+   dma-channels = <2>;
+   dma-requests = <32>;
+   #dma-cells = <1>;
+   };
+
+DMA clients must use the format described in dma/dma.txt file.
-- 
1.7.9.5

[PATCH] media: secocec: fix ir address shift

[Ettore Chimenti]

The actual value of the RC5 System Number (address) is stored in the
IR_READ_DATA common register masked with 0x1F00 so it have to be shifted
by 8 bits.

Signed-off-by: Ettore Chimenti 
---
 drivers/media/platform/seco-cec/seco-cec.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/seco-cec/seco-cec.h 
b/drivers/media/platform/seco-cec/seco-cec.h
index e632c4a2a044..843de8c7dfd4 100644
--- a/drivers/media/platform/seco-cec/seco-cec.h
+++ b/drivers/media/platform/seco-cec/seco-cec.h
@@ -106,7 +106,7 @@
 #define SECOCEC_IR_COMMAND_MASK0x007F
 #define SECOCEC_IR_COMMAND_SHL 0
 #define SECOCEC_IR_ADDRESS_MASK0x1F00
-#define SECOCEC_IR_ADDRESS_SHL 7
+#define SECOCEC_IR_ADDRESS_SHL 8
 #define SECOCEC_IR_TOGGLE_MASK 0x8000
 #define SECOCEC_IR_TOGGLE_SHL  15
 
-- 
2.20.1

Re: [PATCH] drm/i915_request.h: Remove duplicate header

[Chris Wilson]

Quoting Brajeswar Ghosh (2018-12-25 13:23:40)
> Remove i915_scheduler.h which is included more than once
> 
> Signed-off-by: Brajeswar Ghosh 

Thanks for the patch, pushed to dinq.
-Chris

Re: [PATCH] perf python: Do not force closing original perf descriptor in evlist.get_pollfd

[Arnaldo Carvalho de Melo]

Em Thu, Dec 27, 2018 at 09:06:38AM +0100, Jiri Olsa escreveu:
> On Wed, Dec 26, 2018 at 12:21:21PM +0100, Jiri Olsa wrote:
> > Ondřej reported that when compiled with python3, the python
> > extension regress in evlist.get_pollfd function behaviour.
> > 
> > The evlist.get_pollfd creates file objects from evlist's fds
> > and returns them in the list. The python3 version also sets
> > them to 'close the original descriptor' when the object die
> > (is closed), by passing True via 'closefd' arg in PyFile_FromFd
> > call.
> > 
> > The python's closefd doc says:
> >   If closefd is False, the underlying file descriptor will be kept open
> >   when the file is closed.
> > 
> > That's why following line in python3 closes all evlist fds:
> >   evlist.get_pollfd()
> > 
> > the returned list is immediately destroyed and that takes
> > down the original events fds.
> > 
> > Passing closefd as False to PyFile_FromFd to fix this.
> > 
> > Reported-by: Ondřej Lysoněk 
> > Link: http://lkml.kernel.org/n/tip-ru9hmsaliew8p01kr0050...@git.kernel.org
> > Signed-off-by: Jiri Olsa 
> 
> oops, forgot to add.. and cc-ing Jaroslav Škarvada
> 
> Fixes: 66dfdff03d19 ("perf tools: Add Python 3 support")

Thanks, added the Fixes: and Cc: Jaroslav,

- Arnaldo

Re: [PATCH v37 0/3] Virtio-balloon: support free page reporting

[Christian Borntraeger]

On 27.12.2018 12:59, Christian Borntraeger wrote:
> On 27.12.2018 12:31, Christian Borntraeger wrote:
>> This patch triggers random crashes in the guest kernel on s390 early during 
>> boot.
>> No migration and no setting of the balloon is involved.
>>
> 
> Adding Conny and Halil,
> 
> As the QEMU provides no PAGE_HINT feature yet, this quick hack makes the
> guest boot fine again:
> 
> 
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index 728ecd1eea305..aa2e1864c5736 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -492,7 +492,7 @@ static int init_vqs(struct virtio_balloon *vb)
> callbacks[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
> }
>  
> -   err = vb->vdev->config->find_vqs(vb->vdev, VIRTIO_BALLOON_VQ_MAX,
> +   err = vb->vdev->config->find_vqs(vb->vdev, 3, //VIRTIO_BALLOON_VQ_MAX,
>  vqs, callbacks, names, NULL, NULL);
> if (err)
> return err;
> 
> 
> To me it looks like that virtio_ccw_find_vqs will abort if any of the 
> virtqueues 
> that it is been asked for does not exist (including the earlier ones).
> 

This "hack" makes the random crashes go away, but the balloon interface itself
does not work. (setting the value to anything will hang the guest). 
As patch 1 also modifies the main path, there seem to be additional issues, 
maybe
endianess

Looking at things like

+   vb->cmd_id_received = VIRTIO_BALLOON_CMD_ID_STOP;
+   vb->cmd_id_active = cpu_to_virtio32(vb->vdev,
+ VIRTIO_BALLOON_CMD_ID_STOP);
+   vb->cmd_id_stop = cpu_to_virtio32(vb->vdev,
+ VIRTIO_BALLOON_CMD_ID_STOP);


Why is cmd_id_received not using cpu_to_virtio32?

Re: [PATCH v1 3/7] drm: move drm_can_sleep() to drm_util.h

[Daniel Vetter]

On Wed, Dec 26, 2018 at 10:03:49PM +0100, Sam Ravnborg wrote:
> Move drm_can_sleep() out of drmP.h to allow users
> to get rid of the drmP.h include.
> 
> There was no header file that was a good match for this helper function.
> So add this to drm_util with the relevant includes.
> 
> Add include of drm_util.h to all users.
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: "David (ChunMing) Zhou" 
> Cc: Gerd Hoffmann 
> Cc: Rob Clark 
> Cc: Tomi Valkeinen 
> Cc: Eric Anholt 
> ---
>  drivers/gpu/drm/amd/amdgpu/atom.c   |  2 ++
>  drivers/gpu/drm/ast/ast_fb.c|  1 +
>  drivers/gpu/drm/cirrus/cirrus_fbdev.c   |  1 +
>  drivers/gpu/drm/drm_flip_work.c |  1 +
>  drivers/gpu/drm/mgag200/mgag200_fb.c|  1 +
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c|  1 +
>  drivers/gpu/drm/omapdrm/omap_fbdev.c|  1 +
>  drivers/gpu/drm/qxl/qxl_cmd.c   |  2 ++
>  drivers/gpu/drm/radeon/atom.c   |  2 ++
>  drivers/gpu/drm/radeon/radeon_legacy_encoders.c |  1 +
>  drivers/gpu/drm/vc4/vc4_drv.h   |  1 +
>  include/drm/drmP.h  |  8 
>  include/drm/drm_util.h  | 13 +
>  13 files changed, 27 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c 
> b/drivers/gpu/drm/amd/amdgpu/atom.c
> index e9934de1b9cf..dd30f4e61a8c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atom.c
> +++ b/drivers/gpu/drm/amd/amdgpu/atom.c
> @@ -27,6 +27,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  #define ATOM_DEBUG
>  
>  #include "atom.h"
> diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
> index de26df0c6044..fb56fe848e81 100644
> --- a/drivers/gpu/drm/ast/ast_fb.c
> +++ b/drivers/gpu/drm/ast/ast_fb.c
> @@ -38,6 +38,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include "ast_drv.h"
> diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c 
> b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> index 68ab1821e15b..1544fa55d1ff 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> @@ -10,6 +10,7 @@
>   */
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> diff --git a/drivers/gpu/drm/drm_flip_work.c b/drivers/gpu/drm/drm_flip_work.c
> index 12dea16f22a8..3da3bf5af405 100644
> --- a/drivers/gpu/drm/drm_flip_work.c
> +++ b/drivers/gpu/drm/drm_flip_work.c
> @@ -22,6 +22,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  
>  /**
> diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c 
> b/drivers/gpu/drm/mgag200/mgag200_fb.c
> index 30726c9fe28c..6893934b26c0 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_fb.c
> +++ b/drivers/gpu/drm/mgag200/mgag200_fb.c
> @@ -12,6 +12,7 @@
>   */
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c 
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c
> index 96c2b828dba4..fa2d1d8995ee 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c
> @@ -16,6 +16,7 @@
>   * this program.  If not, see .
>   */
>  
> +#include 
>  
>  #include "mdp5_kms.h"
>  #include "mdp5_smp.h"
> diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c 
> b/drivers/gpu/drm/omapdrm/omap_fbdev.c
> index aee99194499f..851c59f07eb1 100644
> --- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
> +++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
> @@ -16,6 +16,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  
>  #include "omap_drv.h"
> diff --git a/drivers/gpu/drm/qxl/qxl_cmd.c b/drivers/gpu/drm/qxl/qxl_cmd.c
> index 208af9f37914..d17676824377 100644
> --- a/drivers/gpu/drm/qxl/qxl_cmd.c
> +++ b/drivers/gpu/drm/qxl/qxl_cmd.c
> @@ -25,6 +25,8 @@
>  
>  /* QXL cmd/ring handling */
>  
> +#include 
> +
>  #include "qxl_drv.h"
>  #include "qxl_object.h"
>  
> diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
> index e55cbeee7a53..ac98ad561870 100644
> --- a/drivers/gpu/drm/radeon/atom.c
> +++ b/drivers/gpu/drm/radeon/atom.c
> @@ -27,6 +27,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  #define ATOM_DEBUG
>  
>  #include "atom.h"
> diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c 
> b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> index 222a1fa41d7c..7e3257e8fd56 100644
> --- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> +++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> @@ -24,6 +24,7 @@
>   *  Alex Deucher
>   */
>  #include 
> +#include 
>  #include 
>  #include 
>  #include "radeon.h"
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index bd6ef1f31822..79c6bcc4f509 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -9,6 +9,7 

Re: [PATCH v1 2/7] drm: move DRM_SWITCH_POWER defines to drm_device.h

[Daniel Vetter]

On Wed, Dec 26, 2018 at 10:03:48PM +0100, Sam Ravnborg wrote:
> Move DRM_SWITCH_POWER out of drmP.h to allow users
> to get rid of the drmP include.
> 
> DRM_SWITCH_POWER defines are used in combination
> with drm_device.switch_power_state.
> 
> Move the DRM_SWITCH_POWER defines to the file where
> drm_device.switch_power_state is defined.
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> ---
>  include/drm/drmP.h   | 5 -
>  include/drm/drm_device.h | 9 +
>  2 files changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index b6b8436b5123..2ba786820052 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -95,11 +95,6 @@ struct dma_buf_attachment;
>  struct pci_dev;
>  struct pci_controller;
>  
> -#define DRM_SWITCH_POWER_ON 0
> -#define DRM_SWITCH_POWER_OFF 1
> -#define DRM_SWITCH_POWER_CHANGING 2
> -#define DRM_SWITCH_POWER_DYNAMIC_OFF 3
> -
>  /* returns true if currently okay to sleep */
>  static inline bool drm_can_sleep(void)
>  {
> diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
> index 42411b3ea0c8..c3da194d25f9 100644
> --- a/include/drm/drm_device.h
> +++ b/include/drm/drm_device.h
> @@ -24,6 +24,13 @@ struct inode;
>  struct pci_dev;
>  struct pci_controller;
>  
> +
> +/* Used by drm_device.switch_power_state */
> +#define DRM_SWITCH_POWER_ON 0
> +#define DRM_SWITCH_POWER_OFF 1
> +#define DRM_SWITCH_POWER_CHANGING 2
> +#define DRM_SWITCH_POWER_DYNAMIC_OFF 3

Since this isn't uapi it'd be nice to change it to an enum, which we can
then properly kernel-doc and make your references links in the resulting
html. Otherwise lgtm.

Would need an include stanza for drm_device.h in drm-internals.rst, plus a
bit of kernel-doc cleanup in here I think (which iirc is why I didn't yet
do this).
-Daniel

> +
>  /**
>   * DRM device structure. This structure represent a complete card that
>   * may contain multiple heads.
> @@ -222,6 +229,8 @@ struct drm_device {
>   struct idr object_name_idr;
>   struct drm_vma_offset_manager *vma_offset_manager;
>   /*@} */
> +
> + /* See DRM_SWITCH_POWER defines */
>   int switch_power_state;
>  
>   /**
> -- 
> 2.12.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v1 1/7] drm: move DRM_IF_VERSION to drm_internal.h

[Daniel Vetter]

On Wed, Dec 26, 2018 at 10:03:47PM +0100, Sam Ravnborg wrote:
> Move DRM_IF_VERSION out of drmP.h to allow users
> to get rid of the drmP include.
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: Daniel Vetter 

Applied to drm-misc-next, thanks for your patch.
-Daniel

> ---
>  drivers/gpu/drm/drm_internal.h | 2 ++
>  include/drm/drmP.h | 2 --
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
> index 51e06defc8d8..e9374cd43610 100644
> --- a/drivers/gpu/drm/drm_internal.h
> +++ b/drivers/gpu/drm/drm_internal.h
> @@ -26,6 +26,8 @@
>  #define DRM_IF_MAJOR 1
>  #define DRM_IF_MINOR 4
>  
> +#define DRM_IF_VERSION(maj, min) (maj << 16 | min)
> +
>  struct drm_prime_file_private;
>  struct dma_buf;
>  
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 05350424a4d3..b6b8436b5123 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -95,8 +95,6 @@ struct dma_buf_attachment;
>  struct pci_dev;
>  struct pci_controller;
>  
> -#define DRM_IF_VERSION(maj, min) (maj << 16 | min)
> -
>  #define DRM_SWITCH_POWER_ON 0
>  #define DRM_SWITCH_POWER_OFF 1
>  #define DRM_SWITCH_POWER_CHANGING 2
> -- 
> 2.12.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v37 1/3] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT

[Christian Borntraeger]

On 27.08.2018 03:32, Wei Wang wrote:
>  static int init_vqs(struct virtio_balloon *vb)
>  {
> - struct virtqueue *vqs[3];
> - vq_callback_t *callbacks[] = { balloon_ack, balloon_ack, stats_request 
> };
> - static const char * const names[] = { "inflate", "deflate", "stats" };
> - int err, nvqs;
> + struct virtqueue *vqs[VIRTIO_BALLOON_VQ_MAX];
> + vq_callback_t *callbacks[VIRTIO_BALLOON_VQ_MAX];
> + const char *names[VIRTIO_BALLOON_VQ_MAX];
> + int err;
> 
>   /*
> -  * We expect two virtqueues: inflate and deflate, and
> -  * optionally stat.
> +  * Inflateq and deflateq are used unconditionally. The names[]
> +  * will be NULL if the related feature is not enabled, which will
> +  * cause no allocation for the corresponding virtqueue in find_vqs.
>*/

This might be true for virtio-pci, but it is not for virtio-ccw.

> - nvqs = virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ) ? 3 : 2;
> - err = virtio_find_vqs(vb->vdev, nvqs, vqs, callbacks, names, NULL);
> + callbacks[VIRTIO_BALLOON_VQ_INFLATE] = balloon_ack;
> + names[VIRTIO_BALLOON_VQ_INFLATE] = "inflate";
> + callbacks[VIRTIO_BALLOON_VQ_DEFLATE] = balloon_ack;
> + names[VIRTIO_BALLOON_VQ_DEFLATE] = "deflate";
> + names[VIRTIO_BALLOON_VQ_STATS] = NULL;
> + names[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
> +
> + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
> + names[VIRTIO_BALLOON_VQ_STATS] = "stats";
> + callbacks[VIRTIO_BALLOON_VQ_STATS] = stats_request;
> + }
> +
> + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT)) {
> + names[VIRTIO_BALLOON_VQ_FREE_PAGE] = "free_page_vq";
> + callbacks[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
> + }
> +
> + err = vb->vdev->config->find_vqs(vb->vdev, VIRTIO_BALLOON_VQ_MAX,
[...]

Re: [RFC PATCH 1/2] drm/fb-helper: Bring back workaround for bugs of SDL 1.2

[Daniel Vetter]

On Wed, Dec 26, 2018 at 05:11:23PM +0500, Ivan Mironov wrote:
> SDL 1.2 sets all fields related to the pixel format to zero in some
> cases[1]. Prior to commit db05c48197759 ("drm: fb-helper: Reject all
> pixel format changing requests"), there was an unintentional workaround
> for this that existed for more than a decade. First in device-specific DRM
> drivers, then here in drm_fb_helper.c.
> 
> Previous code containing this workaround just ignores pixel format fields
> from userspace code. Not a good thing either, as this way, driver may
> silently use pixel format different from what client actually requested,
> and this in turn will lead to displaying garbage on the screen. I think
> that returning EINVAL to userspace in this particular case is the right
> option, so I decided to left code from problematic commit untouched
> instead of just reverting it entirely.
> 
> [1] SDL 1.2.15 source code, src/video/fbcon/SDL_fbvideo.c,
> FB_SetVideoMode()
> 
> Reported-by: saahriktu 
> Suggested-by: saahriktu 
> Fixes: db05c48197759 ("drm: fb-helper: Reject all pixel format changing 
> requests")
> Signed-off-by: Ivan Mironov 
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 146 
>  1 file changed, 93 insertions(+), 53 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index d3af098b0922..aff576c3c4fb 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1621,6 +1621,64 @@ static bool drm_fb_pixel_format_equal(const struct 
> fb_var_screeninfo *var_1,
>  var_1->transp.msb_right == var_2->transp.msb_right;
>  }
>  
> +static void drm_fb_helper_fill_pixel_fmt(struct fb_var_screeninfo *var,
> +  u8 depth)
> +{
> + switch (depth) {
> + case 8:
> + var->red.offset = 0;
> + var->green.offset = 0;
> + var->blue.offset = 0;
> + var->red.length = 8; /* 8bit DAC */
> + var->green.length = 8;
> + var->blue.length = 8;
> + var->transp.offset = 0;
> + var->transp.length = 0;
> + break;
> + case 15:
> + var->red.offset = 10;
> + var->green.offset = 5;
> + var->blue.offset = 0;
> + var->red.length = 5;
> + var->green.length = 5;
> + var->blue.length = 5;
> + var->transp.offset = 15;
> + var->transp.length = 1;
> + break;
> + case 16:
> + var->red.offset = 11;
> + var->green.offset = 5;
> + var->blue.offset = 0;
> + var->red.length = 5;
> + var->green.length = 6;
> + var->blue.length = 5;
> + var->transp.offset = 0;
> + break;
> + case 24:
> + var->red.offset = 16;
> + var->green.offset = 8;
> + var->blue.offset = 0;
> + var->red.length = 8;
> + var->green.length = 8;
> + var->blue.length = 8;
> + var->transp.offset = 0;
> + var->transp.length = 0;
> + break;
> + case 32:
> + var->red.offset = 16;
> + var->green.offset = 8;
> + var->blue.offset = 0;
> + var->red.length = 8;
> + var->green.length = 8;
> + var->blue.length = 8;
> + var->transp.offset = 24;
> + var->transp.length = 8;
> + break;
> + default:
> + break;
> + }
> +}
> +
>  /**
>   * drm_fb_helper_check_var - implementation for _ops.fb_check_var
>   * @var: screeninfo to check
> @@ -1654,6 +1712,40 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo 
> *var,
>   return -EINVAL;
>   }
>  
> + /*
> +  * Workaround for SDL 1.2, which is known to be setting all pixel format
> +  * fields values to zero in some cases. We treat this situation as a
> +  * kind of "use some reasonable autodetected values".
> +  */
> + if (!var->red.offset && !var->green.offset&&
> + !var->blue.offset&& !var->transp.offset   &&
> + !var->red.length && !var->green.length&&
> + !var->blue.length&& !var->transp.length   &&
> + !var->red.msb_right  && !var->green.msb_right &&
> + !var->blue.msb_right && !var->transp.msb_right) {
> + u8 depth;
> +
> + /*
> +  * There is no way to guess the right value for depth when
> +  * bpp is 16 or 32. So we just restore the behaviour previously
> +  * introduced here by commit 785b93ef8c309. In fact, this was
> +  * implemented even earlier in various device drivers.
> +  */
> + switch (var->bits_per_pixel) {
> + case 16:
> + depth = 15;
> + break;
> + case 32:
> +  

Re: [PATCH v37 0/3] Virtio-balloon: support free page reporting

[Christian Borntraeger]

On 27.12.2018 12:31, Christian Borntraeger wrote:
> This patch triggers random crashes in the guest kernel on s390 early during 
> boot.
> No migration and no setting of the balloon is involved.
> 

Adding Conny and Halil,

As the QEMU provides no PAGE_HINT feature yet, this quick hack makes the
guest boot fine again:


diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 728ecd1eea305..aa2e1864c5736 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -492,7 +492,7 @@ static int init_vqs(struct virtio_balloon *vb)
callbacks[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
}
 
-   err = vb->vdev->config->find_vqs(vb->vdev, VIRTIO_BALLOON_VQ_MAX,
+   err = vb->vdev->config->find_vqs(vb->vdev, 3, //VIRTIO_BALLOON_VQ_MAX,
 vqs, callbacks, names, NULL, NULL);
if (err)
return err;


To me it looks like that virtio_ccw_find_vqs will abort if any of the 
virtqueues 
that it is been asked for does not exist (including the earlier ones).


Christian

> 
> On 27.08.2018 03:32, Wei Wang wrote:
>> The new feature, VIRTIO_BALLOON_F_FREE_PAGE_HINT, implemented by this
>> series enables the virtio-balloon driver to report hints of guest free
>> pages to host. It can be used to accelerate virtual machine (VM) live
>> migration. Here is an introduction of this usage:
>>
>> Live migration needs to transfer the VM's memory from the source machine
>> to the destination round by round. For the 1st round, all the VM's memory
>> is transferred. From the 2nd round, only the pieces of memory that were
>> written by the guest (after the 1st round) are transferred. One method
>> that is popularly used by the hypervisor to track which part of memory is
>> written is to have the hypervisor write-protect all the guest memory.
>>
>> This feature enables the optimization by skipping the transfer of guest
>> free pages during VM live migration. It is not concerned that the memory
>> pages are used after they are given to the hypervisor as a hint of the
>> free pages, because they will be tracked by the hypervisor and transferred
>> in the subsequent round if they are used and written.
>>
>> * Tests
>> 1 Test Environment
>> Host: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
>> Migration setup: migrate_set_speed 100G, migrate_set_downtime 400ms
>>
>> 2 Test Results (results are averaged over several repeated runs)
>> 2.1 Guest setup: 8G RAM, 4 vCPU
>> 2.1.1 Idle guest live migration time
>> Optimization v.s. Legacy = 620ms vs 2970ms
>> --> ~79% reduction
>> 2.1.2 Guest live migration with Linux compilation workload
>>   (i.e. make bzImage -j4) running
>>   1) Live Migration Time:
>>  Optimization v.s. Legacy = 2273ms v.s. 4502ms
>>  --> ~50% reduction
>>   2) Linux Compilation Time:
>>  Optimization v.s. Legacy = 8min42s v.s. 8min43s
>>  --> no obvious difference
>>
>> 2.2 Guest setup: 128G RAM, 4 vCPU
>> 2.2.1 Idle guest live migration time
>> Optimization v.s. Legacy = 5294ms vs 41651ms
>> --> ~87% reduction
>> 2.2.2 Guest live migration with Linux compilation workload
>>   1) Live Migration Time:
>> Optimization v.s. Legacy = 8816ms v.s. 54201ms
>> --> 84% reduction
>>   2) Linux Compilation Time:
>>  Optimization v.s. Legacy = 8min30s v.s. 8min36s
>>  --> no obvious difference
>>
>> ChangeLog:
>> v36->v37:
>> - free the reported pages to mm when receives a DONE cmd from host.
>>   Please see patch 1's commit log for reasons. Please see patch 1's
>>   commit for detailed explanations.
>>
>> For ChangeLogs from v22 to v36, please reference
>> https://lkml.org/lkml/2018/7/20/199
>>
>> For ChangeLogs before v21, please reference
>> https://lwn.net/Articles/743660/
>>
>> Wei Wang (3):
>>   virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT
>>   mm/page_poison: expose page_poisoning_enabled to kernel modules
>>   virtio-balloon: VIRTIO_BALLOON_F_PAGE_POISON
>>
>>  drivers/virtio/virtio_balloon.c | 374 
>> 
>>  include/uapi/linux/virtio_balloon.h |   8 +
>>  mm/page_poison.c|   6 +
>>  3 files changed, 355 insertions(+), 33 deletions(-)
>>

[GIT PULL] Please pull powerpc/linux.git powerpc-4.21-1 tag

[Michael Ellerman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Linus,

Please pull powerpc updates for 4.21:

The following changes since commit ccda4af0f4b92f7b4c308d3acc262f4a7e3affad:

  Linux 4.20-rc2 (2018-11-11 17:12:31 -0600)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
tags/powerpc-4.21-1

for you to fetch changes up to 12526b0d6c580df860b31e59d68e5696e16c6e5b:

  Merge branch 'next' of 
https://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux into next 
(2018-12-24 14:14:45 +1100)


There are two conflicts I'm aware of.

The first is in arch/powerpc/mm/fault.c, the resolution is to add the 0xe00 case
to the switch and use the pr_alert() version of the printk.

The other is in arch/powerpc/kernel/iommu.c, where we deleted some code that was
modified in the iommu tree to use a new accessor.

cheers

- --
powerpc updates for 4.21

Notable changes:

 - Mitigations for Spectre v2 on some Freescale (NXP) CPUs.

 - A large series adding support for pass-through of Nvidia V100 GPUs to guests
   on Power9.

 - Another large series to enable hardware assistance for TLB table walk on
   MPC8xx CPUs.

 - Some preparatory changes to our DMA code, to make way for further cleanups
   from Christoph.

 - Several fixes for our Transactional Memory handling discovered by fuzzing the
   signal return path.

 - Support for generating our system call table(s) from a text file like other
   architectures.

 - A fix to our page fault handler so that instead of generating a WARN_ON_ONCE,
   user accesses of kernel addresses instead print a ratelimited and
   appropriately scary warning.

 - A cosmetic change to make our unhandled page fault messages more similar to
   other arches and also more compact and informative.

 - Freescale updates from Scott:
   "Highlights include elimination of legacy clock bindings use from dts
files, an 83xx watchdog handler, fixes to old dts interrupt errors, and
some minor cleanup."

And many clean-ups, reworks and minor fixes etc.

Thanks to:
 Alexandre Belloni, Alexey Kardashevskiy, Andrew Donnellan, Aneesh Kumar K.V,
 Arnd Bergmann, Benjamin Herrenschmidt, Breno Leitao, Christian Lamparter,
 Christophe Leroy, Christoph Hellwig, Daniel Axtens, Darren Stevens, David
 Gibson, Diana Craciun, Dmitry V. Levin, Firoz Khan, Geert Uytterhoeven, Greg
 Kurz, Gustavo Romero, Hari Bathini, Joel Stanley, Kees Cook, Madhavan
 Srinivasan, Mahesh Salgaonkar, Markus Elfring, Mathieu Malaterre, Michal
 Suchánek, Naveen N. Rao, Nick Desaulniers, Oliver O'Halloran, Paul Mackerras,
 Ram Pai, Ravi Bangoria, Rob Herring, Russell Currey, Sabyasachi Gupta, Sam
 Bobroff, Satheesh Rajendran, Scott Wood, Segher Boessenkool, Stephen Rothwell,
 Tang Yuantian, Thiago Jung Bauermann, Yangtao Li, Yuantian Tang, Yue Haibing.

- --
Alexandre Belloni (2):
  powerpc/fsl-rio: fix spelling mistake "reserverd" -> "reserved"
  powerpc/fsl-rio: fix spelling mistake "reserverd" -> "reserved"

Alexey Kardashevskiy (26):
  powerpc/powernv/ioda: Allocate indirect TCE levels of cached userspace 
addresses on demand
  powerpc/powernv/npu: Remove unused headers and a macro.
  vfio/spapr_tce: Get rid of possible infinite loop
  powerpc/powernv/ioda1: Remove dead code for a single device PE
  powerpc/powernv/ioda: Reduce a number of hooks in pnv_phb
  powerpc/powernv/eeh/npu: Fix uninitialized variables in 
opal_pci_eeh_freeze_status
  powerpc/ioda/npu: Call skiboot's hot reset hook when disabling NPU2
  powerpc/mm/iommu/vfio_spapr_tce: Change mm_iommu_get to reference a region
  powerpc/vfio/iommu/kvm: Do not pin device memory
  powerpc/powernv: Move npu struct from pnv_phb to pci_controller
  powerpc/powernv/npu: Move OPAL calls away from context manipulation
  powerpc/pseries/iommu: Use memory@ nodes in max RAM address calculation
  powerpc/pseries/npu: Enable platform support
  powerpc/pseries: Remove IOMMU API support for non-LPAR systems
  powerpc/powernv/pseries: Rework device adding to IOMMU groups
  powerpc/iommu_api: Move IOMMU groups setup to a single place
  powerpc/powernv: Reference iommu_table while it is linked to a group
  powerpc/powernv/npu: Move single TVE handling to NPU PE
  powerpc/powernv/npu: Convert NPU IOMMU helpers to iommu_table_group_ops
  powerpc/powernv/npu: Add compound IOMMU groups
  powerpc/powernv/npu: Add release_ownership hook
  powerpc/powernv/npu: Check mmio_atsd array bounds when populating
  powerpc/powernv/npu: Fault user page into the hypervisor's pagetable
  vfio_pci: Allow mapping extra regions
  vfio_pci: Allow regions to add own capabilities
  vfio_pci: Add NVIDIA GV100GL [Tesla V100 SXM2] subdriver

Aneesh Kumar K.V (1):
  powerpc/mm/hash: Handle user access of kernel address 

Re: [PATCH 2/3] dt-bindings: gpu: samsung-rotator: Document s5pv210 support

[Paweł Chmiel]

Dnia środa, 19 grudnia 2018 17:22:51 CET Krzysztof Kozlowski pisze:
> On Wed, 19 Dec 2018 at 17:04, Paweł Chmiel
>  wrote:
> >
> > This commit documents new compatible for s5pv210 soc,
> > which will be also supported by this driver.
> >
> > Signed-off-by: Paweł Chmiel 
> > ---
> >  Documentation/devicetree/bindings/gpu/samsung-rotator.txt | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/gpu/samsung-rotator.txt 
> > b/Documentation/devicetree/bindings/gpu/samsung-rotator.txt
> > index 82cd1ed0be93..78658dec6941 100644
> > --- a/Documentation/devicetree/bindings/gpu/samsung-rotator.txt
> > +++ b/Documentation/devicetree/bindings/gpu/samsung-rotator.txt
> > @@ -5,6 +5,7 @@ Required properties:
> > (a) "samsung,exynos4210-rotator" for Rotator IP in Exynos4210
> > (b) "samsung,exynos4212-rotator" for Rotator IP in Exynos4212/4412
> > (c) "samsung,exynos5250-rotator" for Rotator IP in Exynos5250
> > +   (d) "samsung,s5pv210-rotator" for Rotator IP in S5PV210
> 
> How about putting it at beginning as the oldest chipset? This would
> require reordering the list so maybe let's remove the a/b/c list
> enumerations? They are kind of useless.
Ok, i'll send v2 of patchset with this change.
> 
> Best regards,
> Krzysztof

Re: [PATCH 2/3] drm/amd: validate user pitch alignment

[Michel Dänzer]

On 2018-12-23 10:44 p.m., Yu Zhao wrote:
> On Fri, Dec 21, 2018 at 10:07:26AM +0100, Michel Dänzer wrote:
>> On 2018-12-21 4:10 a.m., Yu Zhao wrote:
>>> Userspace may request pitch alignment that is not supported by GPU.
>>> Some requests 32, but GPU ignores it and uses default 64 when cpp is
>>> 4. If GEM object is allocated based on the smaller alignment, GPU
>>> DMA will go out of bound.
>>>
>>> For GPU that does frame buffer compression, DMA writing out of bound
>>> memory will cause memory corruption.
>>>
>>> Signed-off-by: Yu Zhao 
>>> ---
>>>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 9 +
>>>  1 file changed, 9 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
>>> index e309d26170db..755daa332f8a 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
>>> @@ -527,6 +527,15 @@ amdgpu_display_user_framebuffer_create(struct 
>>> drm_device *dev,
>>> struct drm_gem_object *obj;
>>> struct amdgpu_framebuffer *amdgpu_fb;
>>> int ret;
>>> +   struct amdgpu_device *adev = dev->dev_private;
>>> +   int cpp = drm_format_plane_cpp(mode_cmd->pixel_format, 0);
>>> +   int pitch = amdgpu_align_pitch(adev, mode_cmd->width, cpp, false);
>>
>> Also, this needs to use mode_cmd->pitches[0] instead of mode_cmd->width,
>> otherwise it'll spuriously fail for larger but well-aligned pitches.
> 
> Actually mode_cmd->pitches[0] is aligned mode_cmd->width multiplied
> by cpp. So we can't just use mode_cmd->pitches[0].

Use mode_cmd->pitches[0] / cpp then?


> And I'm not sure if the hardware works with larger alignment

It does.

> (it certainly ignores smaller alignment).

Yeah, pitch must be >= width. Maybe this patch could check that as well.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

iommu_intel or i915 regression in 4.18, 4.19.12 and drm-tip

[Eric Wong]

I just got a used Thinkpad X201 (Core i5 M 520, Intel QM57
chipset) and hit some kernel panics while trying to view
image/animation-intensive stuff in Firefox (X11) unless I use
"iommu_intel=igfx_off".

With Debian stable backport kernels, "linux-image-4.17.0-0.bpo.3-amd64"
(4.17.17-1~bpo9+1) has no problems.  But "linux-image-4.18.0-0.bpo.3-amd64"
(4.18.20-2~bpo9+1) gives a blank screen before I can login via agetty
and run startx.

Building 4.19.12 myself got me into X11 and able to start
Firefox to panic the kernel.  I also updated to the latest BIOS
(1.40), but it's an EOL laptop (but it's still the most powerful
laptop I use).  I intend to replace the BIOS with Coreboot soon...

Initially, I thought I was hitting another GPU hang from 4.18+:

https://bugs.freedesktop.org/show_bug.cgi?id=107945

But building drm-tip @ commit 28bb1fc015cedadf3b099b8bd0bb27609849f362
("drm-tip: 2018y-12m-25d-08h-12m-37s UTC integration manifest")
I was still able to reproduce the panic unless I use iommu_intel=igfx_off
"i915.reset=1" did not help matters, either.

Below is what I got from netconsole while on drm-tip:

Kernel panic - not syncing: DMAR hardware is malfunctioning
Shutting down cpus with NMI
Kernel Offset: disabled
---[ end Kernel panic - not syncing: DMAR hardware is malfunctioning ]---
[ cut here ]
sched: Unexpected reschedule of offline CPU#3!
WARNING: CPU: 0 PID: 105 at native_smp_send_reschedule+0x34/0x40
Modules linked in: netconsole ccm snd_hda_codec_hdmi snd_hda_codec_conexant 
snd_hda_codec_generic intel_powerclamp coretemp kvm_intel kvm irqbypass 
crc32_pclmul crc32c_intel ghash_clmulni_intel arc4 iwldvm aesni_intel 
aes_x86_64 crypto_simd cryptd mac80211 glue_helper intel_cstate iwlwifi 
intel_uncore i915 intel_gtt i2c_algo_bit iosf_mbi drm_kms_helper cfbfillrect 
syscopyarea intel_ips cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea 
thinkpad_acpi prime_numbers cfg80211 ledtrig_audio i2c_i801 sg snd_hda_intel 
led_class snd_hda_codec drm ac drm_panel_orientation_quirks snd_hwdep battery 
e1000e agpgart snd_hda_core snd_pcm snd_timer ptp snd soundcore pps_core 
ehci_pci ehci_hcd lpc_ich video mfd_core button acpi_cpufreq ecryptfs ip_tables 
x_tables ipv6 evdev thermal [last unloaded: netconsole]
CPU: 0 PID: 105 Comm: kworker/u8:3 Not tainted 4.20.0-rc7b1+ #1
Hardware name: LENOVO 3680FBU/3680FBU, BIOS 6QET70WW (1.40 ) 10/11/2012
Workqueue: i915 __i915_gem_free_work [i915]
RIP: 0010:native_smp_send_reschedule+0x34/0x40
Code: 05 69 c6 c9 00 73 15 48 8b 05 18 2d b3 00 be fd 00 00 00 48 8b 40 30 e9 
9a 58 7d 00 89 fe 48 c7 c7 78 73 af 81 e8 dc c2 01 00 <0f> 0b c3 66 0f 1f 84 00 
00 00 00 00 66 66 66 66 90 8b 05 0d 7d df
RSP: 0018:888075003d98 EFLAGS: 00010092
RAX: 002e RBX: 8880751a0740 RCX: 0006
RDX: 0007 RSI: 0082 RDI: 888075015440
RBP: 88806e823700 R08:  R09: 888072fc07c0
R10: 888075003d60 R11: fff5c002 R12: 8880751a0740
R13: 8880751a0740 R14:  R15: 0003
FS:  () GS:88807500() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7fdb1f53f000 CR3: 01c0a004 CR4: 000206f0
Call Trace:
 
 ? check_preempt_curr+0x4e/0x90
 ? ttwu_do_wakeup.isra.19+0x14/0xf0
 ? try_to_wake_up+0x323/0x410
 ? autoremove_wake_function+0xe/0x30
 ? __wake_up_common+0x8d/0x140
 ? __wake_up_common_lock+0x6c/0x90
 ? irq_work_run_list+0x49/0x80
 ? tick_sched_handle.isra.6+0x50/0x50
 ? update_process_times+0x3b/0x50
 ? tick_sched_handle.isra.6+0x30/0x50
 ? tick_sched_timer+0x3b/0x80
 ? __hrtimer_run_queues+0xea/0x270
 ? hrtimer_interrupt+0x101/0x240
 ? smp_apic_timer_interrupt+0x6a/0x150
 ? apic_timer_interrupt+0xf/0x20
 
 ? panic+0x1ca/0x212
 ? panic+0x1c7/0x212
 ? __iommu_flush_iotlb+0x19e/0x1c0
 ? iommu_flush_iotlb_psi+0x96/0xf0
 ? intel_unmap+0xbf/0xf0
 ? i915_gem_object_put_pages_gtt+0x36/0x220 [i915]
 ? drm_ht_remove+0x20/0x20 [drm]
 ? drm_mm_remove_node+0x1ad/0x310 [drm]
 ? __pm_runtime_resume+0x54/0x70
 ? __i915_gem_object_unset_pages+0x129/0x170 [i915]
 ? __i915_gem_object_put_pages+0x70/0xa0 [i915]
 ? __i915_gem_free_objects+0x245/0x4e0 [i915]
 ? __switch_to_asm+0x24/0x60
 ? __i915_gem_free_work+0x65/0xa0 [i915]
 ? process_one_work+0x1fd/0x410
 ? worker_thread+0x49/0x3f0
 ? kthread+0xf8/0x130
 ? process_one_work+0x410/0x410
 ? kthread_park+0x90/0x90
 ? ret_from_fork+0x35/0x40
WARNING: CPU: 0 PID: 105 at native_smp_send_reschedule+0x34/0x40
---[ end trace 7dd2184d8c86cef5 ]---
[ cut here ]
sched: Unexpected reschedule of offline CPU#2!
WARNING: CPU: 0 PID: 105 at native_smp_send_reschedule+0x34/0x40
Modules linked in: netconsole ccm snd_hda_codec_hdmi snd_hda_codec_conexant 
snd_hda_codec_generic intel_powerclamp coretemp kvm_intel kvm irqbypass 
crc32_pclmul crc32c_intel ghash_clmulni_intel arc4 iwldvm aesni_intel 
aes_x86_64 crypto_simd cryptd mac80211 

Re: [PATCH] drm/drm_drv.c: Remove duplicate header

[Daniel Vetter]

On Mon, Dec 24, 2018 at 08:06:36PM +0530, Brajeswar Ghosh wrote:
> Remove drm_crtc_internal.h which is included more than once
> 
> Signed-off-by: Brajeswar Ghosh 

Applied, thanks for your patch.
-Daniel

> ---
>  drivers/gpu/drm/drm_drv.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 4126bb6e1a4a..75f4e6bf67ca 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -41,7 +41,6 @@
>  #include "drm_crtc_internal.h"
>  #include "drm_legacy.h"
>  #include "drm_internal.h"
> -#include "drm_crtc_internal.h"
>  
>  /*
>   * drm_debug: Enable debug output.
> -- 
> 2.17.1
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

bug report: hugetlbfs: use i_mmap_rwsem for more pmd sharing, synchronization

[Colin Ian King]

Hi,

Static analysis with CoverityScan on linux-next detected a potential
null pointer dereference with the following commit:

>From d8a1051ed4ba55679ef24e838a1942c9c40f0a14 Mon Sep 17 00:00:00 2001
From: Mike Kravetz 
Date: Sat, 22 Dec 2018 10:55:57 +1100
Subject: [PATCH] hugetlbfs: use i_mmap_rwsem for more pmd sharing

The earlier check implies that "mapping" may be a null pointer:

var_compare_op: Comparing mapping to null implies that mapping might be
null.

1008if (!(flags & MF_MUST_KILL) && !PageDirty(hpage) && mapping &&
1009mapping_cap_writeback_dirty(mapping)) {

..however later "mapper" is dereferenced when it may be potentially null:

1034/*
1035 * For hugetlb pages, try_to_unmap could potentially
call
1036 * huge_pmd_unshare.  Because of this, take semaphore in
1037 * write mode here and set TTU_RMAP_LOCKED to
indicate we
1038 * have taken the lock at this higer level.
1039 */
CID 1476097 (#1 of 1): Dereference after null check (FORWARD_NULL)

var_deref_model: Passing null pointer mapping to
i_mmap_lock_write, which dereferences it.

1040i_mmap_lock_write(mapping);
1041unmap_success = try_to_unmap(hpage,
ttu|TTU_RMAP_LOCKED);
1042i_mmap_unlock_write(mapping);


Colin

Re: [PATCH v37 0/3] Virtio-balloon: support free page reporting

[Christian Borntraeger]

This patch triggers random crashes in the guest kernel on s390 early during 
boot.
No migration and no setting of the balloon is involved.




On 27.08.2018 03:32, Wei Wang wrote:
> The new feature, VIRTIO_BALLOON_F_FREE_PAGE_HINT, implemented by this
> series enables the virtio-balloon driver to report hints of guest free
> pages to host. It can be used to accelerate virtual machine (VM) live
> migration. Here is an introduction of this usage:
> 
> Live migration needs to transfer the VM's memory from the source machine
> to the destination round by round. For the 1st round, all the VM's memory
> is transferred. From the 2nd round, only the pieces of memory that were
> written by the guest (after the 1st round) are transferred. One method
> that is popularly used by the hypervisor to track which part of memory is
> written is to have the hypervisor write-protect all the guest memory.
> 
> This feature enables the optimization by skipping the transfer of guest
> free pages during VM live migration. It is not concerned that the memory
> pages are used after they are given to the hypervisor as a hint of the
> free pages, because they will be tracked by the hypervisor and transferred
> in the subsequent round if they are used and written.
> 
> * Tests
> 1 Test Environment
> Host: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
> Migration setup: migrate_set_speed 100G, migrate_set_downtime 400ms
> 
> 2 Test Results (results are averaged over several repeated runs)
> 2.1 Guest setup: 8G RAM, 4 vCPU
> 2.1.1 Idle guest live migration time
> Optimization v.s. Legacy = 620ms vs 2970ms
> --> ~79% reduction
> 2.1.2 Guest live migration with Linux compilation workload
>   (i.e. make bzImage -j4) running
>   1) Live Migration Time:
>  Optimization v.s. Legacy = 2273ms v.s. 4502ms
>  --> ~50% reduction
>   2) Linux Compilation Time:
>  Optimization v.s. Legacy = 8min42s v.s. 8min43s
>  --> no obvious difference
> 
> 2.2 Guest setup: 128G RAM, 4 vCPU
> 2.2.1 Idle guest live migration time
> Optimization v.s. Legacy = 5294ms vs 41651ms
> --> ~87% reduction
> 2.2.2 Guest live migration with Linux compilation workload
>   1) Live Migration Time:
> Optimization v.s. Legacy = 8816ms v.s. 54201ms
> --> 84% reduction
>   2) Linux Compilation Time:
>  Optimization v.s. Legacy = 8min30s v.s. 8min36s
>  --> no obvious difference
> 
> ChangeLog:
> v36->v37:
> - free the reported pages to mm when receives a DONE cmd from host.
>   Please see patch 1's commit log for reasons. Please see patch 1's
>   commit for detailed explanations.
> 
> For ChangeLogs from v22 to v36, please reference
> https://lkml.org/lkml/2018/7/20/199
> 
> For ChangeLogs before v21, please reference
> https://lwn.net/Articles/743660/
> 
> Wei Wang (3):
>   virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT
>   mm/page_poison: expose page_poisoning_enabled to kernel modules
>   virtio-balloon: VIRTIO_BALLOON_F_PAGE_POISON
> 
>  drivers/virtio/virtio_balloon.c | 374 
> 
>  include/uapi/linux/virtio_balloon.h |   8 +
>  mm/page_poison.c|   6 +
>  3 files changed, 355 insertions(+), 33 deletions(-)
>