[char-misc 4.7] mei: me: disable driver on SPT SPS firmware

[Tomas Winkler]

Sunrise Point PCH with SPS Firmware doesn't expose working
MEI interface, we need to quirk it out.

Cc:  #4.4+
Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/pci-me.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/mei/pci-me.c b/drivers/misc/mei/pci-me.c
index 64e64da6da44..e64464c5c160 100644
--- a/drivers/misc/mei/pci-me.c
+++ b/drivers/misc/mei/pci-me.c
@@ -85,7 +85,7 @@ static const struct pci_device_id mei_me_pci_tbl[] = {
 
{MEI_PCI_DEVICE(MEI_DEV_ID_SPT, mei_me_pch8_cfg)},
{MEI_PCI_DEVICE(MEI_DEV_ID_SPT_2, mei_me_pch8_cfg)},
-   {MEI_PCI_DEVICE(MEI_DEV_ID_SPT_H, mei_me_pch8_cfg)},
+   {MEI_PCI_DEVICE(MEI_DEV_ID_SPT_H, mei_me_pch8_sps_cfg)},
{MEI_PCI_DEVICE(MEI_DEV_ID_SPT_H_2, mei_me_pch8_cfg)},
 
{MEI_PCI_DEVICE(MEI_DEV_ID_BXT_M, mei_me_pch8_cfg)},
-- 
2.5.5

Re: [tip:x86/debug] printk: Make the printk*once() variants return a value

[Borislav Petkov]

On Sat, Jul 09, 2016 at 10:56:55AM -0700, Joe Perches wrote:
> defconfigs both with and without CONFIG_PRINTK build
> properly with the proposed change to this specific patch.

Did you try latest tip/master?

> Borislav, your delightful personality always impresses.
> Never change.

What goes around comes around.

-- 
Regards/Gruss,
Boris.

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

[PATCH v2 06/10] soc: Add SoC specific driver support for nuc900

[Wan Zongshun]

This patch is to add SoC specific driver for nuc970 SoC,
it is for getting nuc970 version id and chip id.

Signed-off-by: Wan Zongshun 
---
 drivers/soc/Kconfig  |   1 +
 drivers/soc/Makefile |   1 +
 drivers/soc/nuvoton/Kconfig  |  10 
 drivers/soc/nuvoton/Makefile |   1 +
 drivers/soc/nuvoton/soc-nuc900.c | 100 +++
 5 files changed, 113 insertions(+)
 create mode 100644 drivers/soc/nuvoton/Kconfig
 create mode 100644 drivers/soc/nuvoton/Makefile
 create mode 100644 drivers/soc/nuvoton/soc-nuc900.c

diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index cb58ef0..2119733 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -4,6 +4,7 @@ source "drivers/soc/bcm/Kconfig"
 source "drivers/soc/brcmstb/Kconfig"
 source "drivers/soc/fsl/qe/Kconfig"
 source "drivers/soc/mediatek/Kconfig"
+source "drivers/soc/nuvoton/Kconfig"
 source "drivers/soc/qcom/Kconfig"
 source "drivers/soc/rockchip/Kconfig"
 source "drivers/soc/samsung/Kconfig"
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 380230f..bb1bfba 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_ARCH_DOVE) += dove/
 obj-$(CONFIG_MACH_DOVE)+= dove/
 obj-y  += fsl/
 obj-$(CONFIG_ARCH_MEDIATEK)+= mediatek/
+obj-$(CONFIG_SOC_NUC900)   += nuvoton/
 obj-$(CONFIG_ARCH_QCOM)+= qcom/
 obj-$(CONFIG_ARCH_RENESAS) += renesas/
 obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/
diff --git a/drivers/soc/nuvoton/Kconfig b/drivers/soc/nuvoton/Kconfig
new file mode 100644
index 000..53c106c
--- /dev/null
+++ b/drivers/soc/nuvoton/Kconfig
@@ -0,0 +1,10 @@
+#
+# ARM Versatile SoC drivers
+#
+config SOC_NUC900
+   bool "SoC bus device for the nuvoton NUC900 platforms"
+   depends on ARCH_W90X900
+   select SOC_BUS
+   help
+ Include support for the SoC bus on the NUC900 platforms
+ providing some sysfs information about the ASIC variant.
diff --git a/drivers/soc/nuvoton/Makefile b/drivers/soc/nuvoton/Makefile
new file mode 100644
index 000..88f9b7e
--- /dev/null
+++ b/drivers/soc/nuvoton/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_SOC_NUC900)   += soc-nuc900.o
diff --git a/drivers/soc/nuvoton/soc-nuc900.c b/drivers/soc/nuvoton/soc-nuc900.c
new file mode 100644
index 000..034ef94
--- /dev/null
+++ b/drivers/soc/nuvoton/soc-nuc900.c
@@ -0,0 +1,100 @@
+/*
+ * Copyright 2016 Wan Zongshun 
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* System ID in syscon */
+#define GCR_CHIPID 0x00
+#define GCR_CHIPID_MASK0x00ff
+
+static const struct of_device_id nuc900_soc_of_match[] = {
+   { .compatible = "nuvoton,nuc900-soc",   },
+   { }
+};
+
+static u32 nuc900_chipid;
+
+static ssize_t nuc900_get_chipid(struct device *dev,
+struct device_attribute *attr,
+char *buf)
+{
+   return sprintf(buf, "0x%x\n", nuc900_chipid & GCR_CHIPID_MASK);
+}
+
+static struct device_attribute nuc900_chipid_attr =
+   __ATTR(manufacturer,  S_IRUGO, nuc900_get_chipid,  NULL);
+
+static ssize_t nuc900_get_versionid(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+   return sprintf(buf, "0x%x\n", (nuc900_chipid >> 24) & 0xff);
+}
+
+static struct device_attribute nuc900_version_attr =
+   __ATTR(board,  S_IRUGO, nuc900_get_versionid,  NULL);
+
+static int nuc900_soc_probe(struct platform_device *pdev)
+{
+   static struct regmap *syscon_regmap;
+   struct soc_device *soc_dev;
+   struct soc_device_attribute *soc_dev_attr;
+   struct device_node *np = pdev->dev.of_node;
+   int ret;
+
+   syscon_regmap = syscon_regmap_lookup_by_phandle(np, "syscon");
+   if (IS_ERR(syscon_regmap))
+   return PTR_ERR(syscon_regmap);
+
+   soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
+   if (!soc_dev_attr)
+   return -ENOMEM;
+
+   ret = of_property_read_string(np, "compatible", _dev_attr->soc_id);
+   if (ret)
+   return -EINVAL;
+
+   soc_dev_attr->machine = "NUC900EVB";
+   soc_dev_attr->family = "NUC900";
+   soc_dev = soc_device_register(soc_dev_attr);
+   if (IS_ERR(soc_dev)) {
+   kfree(soc_dev_attr);
+   return -ENODEV;
+   }
+
+   ret = regmap_read(syscon_regmap, GCR_CHIPID, _chipid);
+   if (ret)
+   return -ENODEV;
+
+   

[PATCH v2 03/10] Clocksource: add nuc970 clocksource driver

[Wan Zongshun]

This patch is to add nuc970 clocksource driver support.

NUC970 general timer controller includes five channels, TIMER0, TIMER1,
TIMER2, TIMER3, and TIMER4, which allow user to easily implement a
counting scheme or timing control for applications.The timer possesses
features such as adjustable resolution, and programmable counting period.
The timer can generate an interrupt signal upon timeout, or provide the
current value of count during operation.

Currently, we are using TIMER0 and TIMER1 for clocksource and clockevent
device driver support.

Signed-off-by: Wan Zongshun 
---
 drivers/clocksource/Kconfig|   8 +
 drivers/clocksource/Makefile   |   1 +
 drivers/clocksource/timer-nuc900.c | 305 +
 3 files changed, 314 insertions(+)
 create mode 100644 drivers/clocksource/timer-nuc900.c

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 47352d2..441c5ee 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -427,4 +427,12 @@ config CLKSRC_ST_LPC
  Enable this option to use the Low Power controller timer
  as clocksource.
 
+config NUC900_TIMER
+bool "Clocksource timer for nuc900 platform" if COMPILE_TEST
+depends on ARM
+select CLKSRC_OF if OF
+select CLKSRC_MMIO
+help
+  Enables the clocksource for the NUC900 platform.
+
 endmenu
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 473974f..c74e252 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -67,3 +67,4 @@ obj-$(CONFIG_H8300_TMR16) += h8300_timer16.o
 obj-$(CONFIG_H8300_TPU)+= h8300_tpu.o
 obj-$(CONFIG_CLKSRC_ST_LPC)+= clksrc_st_lpc.o
 obj-$(CONFIG_X86_NUMACHIP) += numachip.o
+obj-$(CONFIG_NUC900_TIMER) += timer-nuc900.o
diff --git a/drivers/clocksource/timer-nuc900.c 
b/drivers/clocksource/timer-nuc900.c
new file mode 100644
index 000..28ccbcf
--- /dev/null
+++ b/drivers/clocksource/timer-nuc900.c
@@ -0,0 +1,305 @@
+/*
+ * Copyright 2016 Wan Zongshun 
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define TMR_TCSR0  0x00
+#define TMR_TICR0  0x04
+#define TMR_TDR0   0x08
+#define TMR_TCSR1  0x10
+#define TMR_TICR1  0x14
+#define TMR_TDR1   0x18
+#define TMR_TISR   0x60
+
+#define RESETINT   0x1f
+#define PERIODIC   (0x01 << 27)
+#define ONESHOT(0x00 << 27)
+#define COUNTEN(0x01 << 30)
+#define INTEN  (0x01 << 29)
+
+#define TICKS_PER_SEC  100
+/* Divider = prescale + 1 */
+#define PRESCALE   0x63
+
+#defineTDR_SHIFT   24
+#defineTDR_MASK((1 << TDR_SHIFT) - 1)
+#define OPMODE_MASK~(0x03 << 27)
+
+struct nuc970_clockevents {
+   struct clock_event_device clkevt;
+   unsigned int timer0_load;
+   void __iomem *base;
+};
+
+struct nuc970_clockevents *clkevt_to_nuc970(struct clock_event_device *clk)
+{
+   return container_of(clk, struct nuc970_clockevents, clkevt);
+}
+
+static int nuc970_clockevent_set(bool periodic, struct clock_event_device *clk)
+{
+   struct nuc970_clockevents *evt = clkevt_to_nuc970(clk);
+   unsigned int val;
+
+   val = readl(evt->base + TMR_TCSR0);
+   val &= OPMODE_MASK;
+
+   writel(evt->timer0_load, evt->base + TMR_TICR0);
+
+   val |= periodic ? PERIODIC:ONESHOT;
+   val |= (COUNTEN | INTEN | PRESCALE);
+
+   writel(val, evt->base + TMR_TCSR0);
+
+   return 0;
+}
+
+
+static int nuc970_clockevent_set_oneshot(struct clock_event_device *clk)
+{
+   nuc970_clockevent_set(0, clk);
+   return 0;
+}
+
+static int nuc970_clockevent_set_periodic(struct clock_event_device *clk)
+{
+   nuc970_clockevent_set(1, clk);
+   return 0;
+}
+
+static int nuc970_clockevent_setnextevent(unsigned long evtval,
+ struct clock_event_device *clk)
+{
+   struct nuc970_clockevents *evt = clkevt_to_nuc970(clk);
+   unsigned int tcsr, tdelta;
+
+   tcsr = readl(evt->base + TMR_TCSR0);
+   tdelta = readl(evt->base + TMR_TICR0) - readl(evt->base + TMR_TDR0);
+
+   writel(evtval, evt->base + TMR_TICR0);
+
+   if (!(tcsr & COUNTEN) && ((tdelta > 2) || (tdelta == 0)))
+   writel(readl(evt->base + TMR_TCSR0) | COUNTEN,
+evt->base + TMR_TCSR0);
+
+   return 0;
+}
+
+static int nuc970_clockevent_shutdown(struct clock_event_device *clk)
+{
+   

[PATCH v2 02/10] irqchip: add irqchip driver for nuc900

[Wan Zongshun]

This patch is to add irqchip driver support for nuc900 plat,
current this driver only supports nuc970 SoC.

Signed-off-by: Wan Zongshun 
---
 arch/arm/mach-w90x900/include/mach/irqs.h |   5 +
 drivers/irqchip/Makefile  |   1 +
 drivers/irqchip/irq-nuc900.c  | 150 ++
 3 files changed, 156 insertions(+)
 create mode 100644 drivers/irqchip/irq-nuc900.c

diff --git a/arch/arm/mach-w90x900/include/mach/irqs.h 
b/arch/arm/mach-w90x900/include/mach/irqs.h
index 9d5cba3..3b035c6 100644
--- a/arch/arm/mach-w90x900/include/mach/irqs.h
+++ b/arch/arm/mach-w90x900/include/mach/irqs.h
@@ -59,7 +59,12 @@
 #define IRQ_KPIW90X900_IRQ(29)
 #define IRQ_P2SGROUP   W90X900_IRQ(30)
 #define IRQ_ADCW90X900_IRQ(31)
+
+#if !defined(CONFIG_SOC_NUC900)
 #define NR_IRQS(IRQ_ADC+1)
+#else
+#define NR_IRQS62
+#endif
 
 /*for irq group*/
 
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 38853a1..9ccd5af8a 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -69,3 +69,4 @@ obj-$(CONFIG_PIC32_EVIC)  += irq-pic32-evic.o
 obj-$(CONFIG_MVEBU_ODMI)   += irq-mvebu-odmi.o
 obj-$(CONFIG_LS_SCFG_MSI)  += irq-ls-scfg-msi.o
 obj-$(CONFIG_EZNPS_GIC)+= irq-eznps.o
+obj-$(CONFIG_SOC_NUC970)   += irq-nuc900.o
diff --git a/drivers/irqchip/irq-nuc900.c b/drivers/irqchip/irq-nuc900.c
new file mode 100644
index 000..c4b2e39
--- /dev/null
+++ b/drivers/irqchip/irq-nuc900.c
@@ -0,0 +1,150 @@
+/*
+ * Copyright 2016 Wan Zongshun 
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#defineREG_AIC_SCR10x00
+#defineREG_AIC_SCR20x04
+#defineREG_AIC_SCR30x08
+#defineREG_AIC_SCR40x0C
+#defineREG_AIC_SCR50x10
+#defineREG_AIC_SCR60x14
+#defineREG_AIC_SCR70x18
+#defineREG_AIC_SCR80x1C
+#defineREG_AIC_SCR90x20
+#defineREG_AIC_SCR10   0x24
+#defineREG_AIC_SCR11   0x28
+#defineREG_AIC_SCR12   0x2C
+#defineREG_AIC_SCR13   0x30
+#defineREG_AIC_SCR14   0x34
+#defineREG_AIC_SCR15   0x38
+#defineREG_AIC_IRSR0x100
+#defineREG_AIC_IRSRH   0x104
+#defineREG_AIC_IASR0x108
+#defineREG_AIC_IASRH   0x10C
+#defineREG_AIC_ISR 0x110
+#defineREG_AIC_ISRH0x114
+#defineREG_AIC_IPER0x118
+#defineREG_AIC_ISNR0x120
+#defineREG_AIC_OISR0x124
+#defineREG_AIC_IMR 0x128
+#defineREG_AIC_IMRH0x12C
+#defineREG_AIC_MECR0x130
+#defineREG_AIC_MECRH   0x134
+#defineREG_AIC_MDCR0x138
+#defineREG_AIC_MDCRH   0x13C
+#defineREG_AIC_SSCR0x140
+#defineREG_AIC_SSCRH   0x144
+#defineREG_AIC_SCCR0x148
+#defineREG_AIC_SCCRH   0x14C
+#defineREG_AIC_EOSCR   0x150
+
+static void __iomem *aic_base;
+static struct irq_domain *aic_domain;
+
+static void nuc900_irq_mask(struct irq_data *d)
+{
+   if (d->irq < 32)
+   writel(1 << (d->irq), aic_base + REG_AIC_MDCR);
+   else
+   writel(1 << (d->irq - 32), aic_base + REG_AIC_MDCRH);
+}
+
+static void nuc900_irq_ack(struct irq_data *d)
+{
+   writel(0x01, aic_base + REG_AIC_EOSCR);
+}
+
+static void nuc900_irq_unmask(struct irq_data *d)
+{
+   if (d->irq < 32)
+   writel(1 << (d->irq), aic_base + REG_AIC_MECR);
+   else
+   writel(1 << (d->irq - 32), aic_base + REG_AIC_MECRH);
+}
+
+static struct irq_chip nuc900_irq_chip = {
+   .irq_ack= nuc900_irq_ack,
+   .irq_mask   = nuc900_irq_mask,
+   .irq_unmask = nuc900_irq_unmask,
+};
+
+void __exception_irq_entry aic_handle_irq(struct pt_regs *regs)
+{
+   u32 hwirq;
+
+   hwirq = readl(aic_base + REG_AIC_IPER);
+   hwirq = readl(aic_base + REG_AIC_ISNR);
+   if (!hwirq)
+   writel(0x01, aic_base + REG_AIC_EOSCR);
+
+   handle_IRQ((irq_find_mapping(aic_domain, hwirq)), regs);
+}
+
+static int aic_irq_domain_map(struct irq_domain *d, unsigned int virq,
+ irq_hw_number_t hw)
+{
+   irq_set_chip_and_handler(virq, _irq_chip, handle_level_irq);
+   irq_clear_status_flags(virq, IRQ_NOREQUEST);
+
+   return 0;
+}
+
+static struct irq_domain_ops aic_irq_domain_ops = {
+   .map = aic_irq_domain_map,
+   .xlate = irq_domain_xlate_onecell,
+};
+
+static int 

[PATCH v2 01/10] ARM: NUC900: Add nuc970 machine support

[Wan Zongshun]

NUC970 is a new SoC of Nuvoton nuc900 series, this patch is
to add machine file support for it.

Signed-off-by: Wan Zongshun 
---
 arch/arm/mach-w90x900/Kconfig  | 20 
 arch/arm/mach-w90x900/Makefile |  3 +++
 arch/arm/mach-w90x900/nuc900.c | 41 +
 3 files changed, 64 insertions(+)
 create mode 100644 arch/arm/mach-w90x900/nuc900.c

diff --git a/arch/arm/mach-w90x900/Kconfig b/arch/arm/mach-w90x900/Kconfig
index 69bab32..80ab00c 100644
--- a/arch/arm/mach-w90x900/Kconfig
+++ b/arch/arm/mach-w90x900/Kconfig
@@ -15,6 +15,26 @@ config CPU_NUC960
help
  Support for NUCP960 of Nuvoton NUC900 CPUs.
 
+config SOC_NUC970
+   bool "Nuvoton NUC970 SoC support"
+   select COMMON_CLK
+   select GENERIC_IRQ_CHIP
+   select HAVE_CLK_PREPARE
+   select IRQ_DOMAIN
+   select MULTI_IRQ_HANDLER
+   select MFD_SYSCON
+   select NUC900_TIMER
+   select SOC_NUC900
+   select USE_OF
+   help
+ Support for NUC970 of Nuvoton NUC900 SoCs.
+ The NUC970 series runs up to 300 MHz, with 16 KB I-cache,
+ 16 KB D-cache and MMU, 56KB embedded SRAM and 16 KB Internal
+ Boot ROM for booting from USB, NAND and SPI FLASH.
+ Detailed information please check the following link:
+ https://github.com/zswan/nuc900-document/blob/master/
+ NUC970_TechnicalReferenceManual_EN_Rev1.30.pdf
+
 menu "W90P910 Machines"
 
 config MACH_W90P910EVB
diff --git a/arch/arm/mach-w90x900/Makefile b/arch/arm/mach-w90x900/Makefile
index 828c032..d13ba5a 100644
--- a/arch/arm/mach-w90x900/Makefile
+++ b/arch/arm/mach-w90x900/Makefile
@@ -4,8 +4,10 @@
 
 # Object file lists.
 
+ifeq ($(CONFIG_SOC_NUC970),)
 obj-y  := irq.o time.o mfp.o gpio.o clock.o
 obj-y  += clksel.o dev.o cpu.o
+endif
 # W90X900 CPU support files
 
 obj-$(CONFIG_CPU_W90P910)  += nuc910.o
@@ -17,3 +19,4 @@ obj-$(CONFIG_CPU_NUC960)  += nuc960.o
 obj-$(CONFIG_MACH_W90P910EVB)  += mach-nuc910evb.o
 obj-$(CONFIG_MACH_W90P950EVB)  += mach-nuc950evb.o
 obj-$(CONFIG_MACH_W90N960EVB)  += mach-nuc960evb.o
+obj-$(CONFIG_SOC_NUC970)   += nuc900.o
diff --git a/arch/arm/mach-w90x900/nuc900.c b/arch/arm/mach-w90x900/nuc900.c
new file mode 100644
index 000..309c332
--- /dev/null
+++ b/arch/arm/mach-w90x900/nuc900.c
@@ -0,0 +1,41 @@
+/*
+ * Copyright 2016 Wan Zongshun 
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+static void __init nuc900_machine_init(void)
+{
+   of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static const char *nuc900_dt_compat[] __initconst = {
+   "nuvoton,nuc970",
+   NULL,
+};
+
+DT_MACHINE_START(nuc900_dt, "Nuvoton NUC900 (Device Tree Support)")
+   .init_machine   = nuc900_machine_init,
+   .dt_compat  = nuc900_dt_compat,
+MACHINE_END
-- 
2.7.4

[PATCH v2 05/10] power/reset: Add reset driver support for nuc900

[Wan Zongshun]

This driver is to add reset support for nuc900 series,
currently, it only supports nuc970 SoC reset.

Signed-off-by: Wan Zongshun 
---
 drivers/power/reset/Kconfig|  7 +++
 drivers/power/reset/Makefile   |  1 +
 drivers/power/reset/nuc900-reset.c | 93 ++
 3 files changed, 101 insertions(+)
 create mode 100644 drivers/power/reset/nuc900-reset.c

diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 9bb2622..8c84892 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -94,6 +94,13 @@ config POWER_RESET_MSM
help
  Power off and restart support for Qualcomm boards.
 
+config POWER_RESET_NUC900
+   bool "Nuc900 restart driver"
+   depends on ARCH_W90X900
+   help
+ Power off and restart support for Nuvoton NUC900 family of
+ reference boards.
+
 config POWER_RESET_LTC2952
bool "LTC2952 PowerPath power-off driver"
depends on OF_GPIO
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index ab7aa86..d4df889 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_POWER_RESET_GPIO_RESTART) += gpio-restart.o
 obj-$(CONFIG_POWER_RESET_HISI) += hisi-reboot.o
 obj-$(CONFIG_POWER_RESET_IMX) += imx-snvs-poweroff.o
 obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
+obj-$(CONFIG_POWER_RESET_NUC900) += nuc900-reset.o
 obj-$(CONFIG_POWER_RESET_LTC2952) += ltc2952-poweroff.o
 obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
 obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
diff --git a/drivers/power/reset/nuc900-reset.c 
b/drivers/power/reset/nuc900-reset.c
new file mode 100644
index 000..49986b7
--- /dev/null
+++ b/drivers/power/reset/nuc900-reset.c
@@ -0,0 +1,93 @@
+/*
+ * Copyright 2016 Wan Zongshun 
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define REG_WRPRTR 0x1fc
+#define REG_AHBIPRST   0x060
+
+static struct regmap *syscon;
+
+static int nuc900_restart_handler(struct notifier_block *this,
+ unsigned long mode, void *cmd)
+{
+   /*0:register protect enable*/
+   int write_protect = 0;
+
+   /*register protection disable*/
+   do {
+   regmap_read(syscon, REG_WRPRTR, _protect);
+
+   if (write_protect != 1) {
+   regmap_write(syscon, REG_WRPRTR, 0x59);
+   regmap_write(syscon, REG_WRPRTR, 0x16);
+   regmap_write(syscon, REG_WRPRTR, 0x88);
+   }
+
+   } while (write_protect != 1);
+
+   /*trigger reset*/
+   regmap_write(syscon, REG_AHBIPRST, 0x01);
+
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block nuc900_restart_nb = {
+   .notifier_call = nuc900_restart_handler,
+   .priority = 128,
+};
+
+static int nuc900_reset_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   int err;
+
+   syscon = syscon_regmap_lookup_by_phandle(dev->of_node, "syscon");
+   if (IS_ERR(syscon)) {
+   pr_err("%s: syscon lookup failed\n", dev->of_node->name);
+   return PTR_ERR(syscon);
+   }
+
+   err = register_restart_handler(_restart_nb);
+   if (err)
+   dev_err(dev, "cannot register restart handler (err=%d)\n", err);
+
+   return err;
+}
+
+static const struct of_device_id of_nuc900_reset_match[] = {
+   { .compatible = "nuvoton,nuc900-reset", },
+   {},
+};
+MODULE_DEVICE_TABLE(of, of_nuc900_reset_match);
+
+static struct platform_driver nuc900_reset_driver = {
+   .probe = nuc900_reset_probe,
+   .driver = {
+   .name = "nuc900-reset",
+   .of_match_table = of_match_ptr(of_nuc900_reset_match),
+   },
+};
+
+static int __init nuc900_reset_init(void)
+{
+   return platform_driver_register(_reset_driver);
+}
+device_initcall(nuc900_reset_init);
-- 
2.7.4

[PATCH v2 07/10] ARM: dts: Add clock header file into dt-bindings

[Wan Zongshun]

This patch is to add nuc970 clock Macros header file
into include/dt-bindings/clock.

Signed-off-by: Wan Zongshun 
---
 include/dt-bindings/clock/nuc970-clock.h | 233 +++
 1 file changed, 233 insertions(+)
 create mode 100644 include/dt-bindings/clock/nuc970-clock.h

diff --git a/include/dt-bindings/clock/nuc970-clock.h 
b/include/dt-bindings/clock/nuc970-clock.h
new file mode 100644
index 000..cbfcc77
--- /dev/null
+++ b/include/dt-bindings/clock/nuc970-clock.h
@@ -0,0 +1,233 @@
+/*
+ * Copyright 2016 Wan Zongshun 
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#ifndef __DT_BINDINGS_CLOCK_NUC970_H
+#define __DT_BINDINGS_CLOCK_NUC970_H
+
+/*SOURCE*/
+
+#defineXIN 0
+#defineAPLL1
+#defineUPLL2
+#defineXIN32K  3
+#defineXIN128_DIV  4
+
+/*ECLK*/
+
+#defineUSB_APLLDIV 5
+#defineUSB_UPLLDIV 6
+#defineUSB_ECLK_MUX7
+#defineUSB_ECLK_DIV8
+#defineUSB_ECLK_GATE   9
+#defineSD_APLLDIV  10
+#defineSD_UPLLDIV  11
+#defineSD_ECLK_MUX 12
+#defineSD_ECLK_DIV 13
+#defineSD_ECLK_GATE14
+#defineLCD_APLLDIV 15
+#defineLCD_UPLLDIV 16
+#defineLCD_ECLK_MUX17
+#defineLCD_ECLK_DIV18
+#defineLCD_ECLK_GATE   19
+#defineADC_APLLDIV 20
+#defineADC_UPLLDIV 21
+#defineADC_ECLK_MUX22
+#defineADC_ECLK_DIV23
+#defineADC_ECLK_GATE   24
+#defineAUDIO_APLLDIV   25
+#defineAUDIO_UPLLDIV   26
+#defineAUDIO_ECLK_MUX  27
+#defineAUDIO_ECLK_DIV  28
+#defineAUDIO_ECLK_GATE 29
+#defineCAP_APLLDIV 30
+#defineCAP_UPLLDIV 31
+#defineCAP_ECLK_MUX32
+#defineCAP_ECLK_DIV33
+#defineCAP_ECLK_GATE   34
+#defineSDH_APLLDIV 35
+#defineSDH_UPLLDIV 36
+#defineSDH_ECLK_MUX37
+#defineSDH_ECLK_DIV38
+#defineSDH_ECLK_GATE   39
+#defineEMMC_APLLDIV40
+#defineEMMC_UPLLDIV41
+#defineEMMC_ECLK_MUX   42
+#defineEMMC_ECLK_DIV   43
+#defineEMMC_ECLK_GATE  44
+#defineUART0_APLLDIV   45
+#defineUART0_UPLLDIV   46
+#defineUART0_ECLK_MUX  47
+#defineUART0_ECLK_DIV  48
+#defineUART0_ECLK_GATE 49
+#defineUART1_APLLDIV   50
+#defineUART1_UPLLDIV   51
+#defineUART1_ECLK_MUX  52
+#defineUART1_ECLK_DIV  53
+#defineUART1_ECLK_GATE 54
+#defineUART2_APLLDIV   55
+#defineUART2_UPLLDIV   56
+#defineUART2_ECLK_MUX  57
+#defineUART2_ECLK_DIV  58
+#defineUART2_ECLK_GATE 59
+#defineUART3_APLLDIV   60
+#defineUART3_UPLLDIV   61
+#defineUART3_ECLK_MUX  62
+#defineUART3_ECLK_DIV  63
+#defineUART3_ECLK_GATE 64
+#defineUART4_APLLDIV   65
+#defineUART4_UPLLDIV   66
+#defineUART4_ECLK_MUX  67
+#defineUART4_ECLK_DIV  68
+#defineUART4_ECLK_GATE 69
+#defineUART5_APLLDIV   70
+#defineUART5_UPLLDIV   71
+#defineUART5_ECLK_MUX  72
+#defineUART5_ECLK_DIV  73
+#defineUART5_ECLK_GATE 74
+#defineUART6_APLLDIV   75
+#defineUART6_UPLLDIV   76
+#defineUART6_ECLK_MUX  77
+#defineUART6_ECLK_DIV  78
+#defineUART6_ECLK_GATE 79
+#defineUART7_APLLDIV   80
+#defineUART7_UPLLDIV   81
+#defineUART7_ECLK_MUX  82
+#defineUART7_ECLK_DIV  83
+#defineUART7_ECLK_GATE 84
+#defineUART8_APLLDIV   85
+#defineUART8_UPLLDIV   86
+#defineUART8_ECLK_MUX  87
+#defineUART8_ECLK_DIV  88
+#defineUART8_ECLK_GATE 89
+#defineUART9_APLLDIV   90
+#defineUART9_UPLLDIV   91
+#defineUART9_ECLK_MUX  92

[PATCH v2 00/10] ARM: NUC900: Add NUC970 SoC support

[Wan Zongshun]

Hi,

This patch series added Nuvoton new SoC NUC970 development board
support, this nuc970 belongs to nuc900 series, but many features are
not compatible with old nuc900 SoCs like nuc910, nuc920.

Those patches are basing on old w90x900 codes, and are using standard
linux subsystem interface, such as dts, driver/clk, driver/clocksource
, driver/irqchip drivers.

The old w90x900 plat such as nuc910,nuc960 codes will also be changed
to new style according to nuc970 codes after those patches was accepted.

PATCH V2:
The V2 patches change some code style, re-archtect some drivers and add reset
and soc drivers, split some dts patches according to maillist's comments.

Wan Zongshun (10):
  ARM: NUC900: Add nuc970 machine support
  irqchip: add irqchip driver for nuc900
  Clocksource: add nuc970 clocksource driver
  clk: add Clock driver for nuc970
  power/reset: Add reset driver support for nuc900
  soc: Add SoC specific driver support for nuc900
  ARM: dts: Add clock header file into dt-bindings
  ARM: dts: nuc900: Add nuc970 dts files
  Documentation: devicetree: Add dts description for nuc900
  nuc900: add nuc970 platform defconfig file

 .../devicetree/bindings/arm/nuvoton/nuc970.txt |  12 +
 .../bindings/clock/nuvoton,nuc970-clk.txt  |  13 +
 .../interrupt-controller/nuvoton,nuc900-aic.txt|  15 +
 .../bindings/reset/nuvoton,nuc900-reset.txt|  12 +
 .../devicetree/bindings/serial/nuc970-uart.txt |  22 +
 .../bindings/soc/nuvoton/nuvoton,nuc900-soc.txt|  12 +
 .../bindings/timer/nuvoton,nuc970-tmr.txt  |  20 +
 arch/arm/boot/dts/Makefile |   1 +
 arch/arm/boot/dts/nuc970-evb.dts   |  34 +
 arch/arm/boot/dts/nuc970.dtsi  |  88 ++
 arch/arm/configs/nuc970_defconfig  |  76 ++
 arch/arm/mach-w90x900/Kconfig  |  20 +
 arch/arm/mach-w90x900/Makefile |   3 +
 arch/arm/mach-w90x900/include/mach/irqs.h  |   5 +
 arch/arm/mach-w90x900/nuc900.c |  41 +
 drivers/clk/Makefile   |   1 +
 drivers/clk/nuc900/Makefile|   6 +
 drivers/clk/nuc900/clk-apll.c  | 168 
 drivers/clk/nuc900/clk-ccf.h   |  53 ++
 drivers/clk/nuc900/clk-nuc970.c| 925 +
 drivers/clk/nuc900/clk-upll.c  |  83 ++
 drivers/clocksource/Kconfig|   8 +
 drivers/clocksource/Makefile   |   1 +
 drivers/clocksource/timer-nuc900.c | 305 +++
 drivers/irqchip/Makefile   |   1 +
 drivers/irqchip/irq-nuc900.c   | 150 
 drivers/power/reset/Kconfig|   7 +
 drivers/power/reset/Makefile   |   1 +
 drivers/power/reset/nuc900-reset.c |  93 +++
 drivers/soc/Kconfig|   1 +
 drivers/soc/Makefile   |   1 +
 drivers/soc/nuvoton/Kconfig|  10 +
 drivers/soc/nuvoton/Makefile   |   1 +
 drivers/soc/nuvoton/soc-nuc900.c   | 100 +++
 include/dt-bindings/clock/nuc970-clock.h   | 233 ++
 35 files changed, 2522 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/nuvoton/nuc970.txt
 create mode 100644 
Documentation/devicetree/bindings/clock/nuvoton,nuc970-clk.txt
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/nuvoton,nuc900-aic.txt
 create mode 100644 
Documentation/devicetree/bindings/reset/nuvoton,nuc900-reset.txt
 create mode 100644 Documentation/devicetree/bindings/serial/nuc970-uart.txt
 create mode 100644 
Documentation/devicetree/bindings/soc/nuvoton/nuvoton,nuc900-soc.txt
 create mode 100644 
Documentation/devicetree/bindings/timer/nuvoton,nuc970-tmr.txt
 create mode 100644 arch/arm/boot/dts/nuc970-evb.dts
 create mode 100644 arch/arm/boot/dts/nuc970.dtsi
 create mode 100644 arch/arm/configs/nuc970_defconfig
 create mode 100644 arch/arm/mach-w90x900/nuc900.c
 create mode 100644 drivers/clk/nuc900/Makefile
 create mode 100644 drivers/clk/nuc900/clk-apll.c
 create mode 100644 drivers/clk/nuc900/clk-ccf.h
 create mode 100644 drivers/clk/nuc900/clk-nuc970.c
 create mode 100644 drivers/clk/nuc900/clk-upll.c
 create mode 100644 drivers/clocksource/timer-nuc900.c
 create mode 100644 drivers/irqchip/irq-nuc900.c
 create mode 100644 drivers/power/reset/nuc900-reset.c
 create mode 100644 drivers/soc/nuvoton/Kconfig
 create mode 100644 drivers/soc/nuvoton/Makefile
 create mode 100644 drivers/soc/nuvoton/soc-nuc900.c
 create mode 100644 include/dt-bindings/clock/nuc970-clock.h

-- 
2.7.4

Re: [LEDE-DEV] DHCP via bridge in case of IPv4

[Russell Senior]

> "Alexey" == Alexey Brodkin  writes:

Alexey> Hi Aaron,
Alexey> On Sat, 2016-07-09 at 07:47 -0400, Aaron Z wrote:
>> On Sat, Jul 9, 2016 at 4:37 AM, Alexey Brodkin
>>  wrote:
>> > 
>> > Hello,
>> > 
>> > I was playing with quite simple bridged setup on different boards
>> with > very recent kernels (4.6.3 as of this writing) and found one
>> interesting > behavior that I cannot yet understand and googling
>> din't help here as well.
>> > 
>> > My setup is pretty simple: >
>> -   --   -
>> > > 
>> > > HOST  |   | "Dumb AP"  |   | Wireless
>> client   | > > with DHCP |<->(eth0) (wlan0)<->|
>> attempting to | > > server|   |\ br0
>> / |   | get settings via DHCP | >
>> -   --   -
>> > 
>> > * HOST is my laptop with DHCP server that works for sure.  > *
>> "Dumb AP" is a separate board (I tried ARM-based Wandboard and
>> ARC-based >   AXS10x boards but results are exactly the same) with
>> wired (eth0) and wireless >   (wlan0) network controllers bridged
>> together (br0). That "br0" bridge flawlessly >   gets its settings
>> from DHCP server on host.  > * Wireless client could be either a
>> smatrphone or another laptop etc but >   what's important it should
>> be configured to get network settings by DHCP as well.
>> > 
>> > So what happens "br0" always gets network settings from DHCP server
>> on HOST.  > That's fine. But wireless client only reliably gets
>> settings from DHCP server > if IPv6 is enabled on "Dumb AP" board. If
>> IPv6 is disabled I may see that > wireless client sends "DHCP
>> Discover" then server replies with "DHCP Offer" but > that offer
>> never reaches wireless client.
>> 
>> 
>> Do you have WDS enabled? If not, DHCP has issues in that scenario:
>> https://wiki.openwrt.org/doc/howto/clientmode

If the Dumb AP's wireless interface is in ap-mode, then this shouldn't
be an issue.  It's only client-mode interfaces that have trouble with bridging.

I'd suggest running tcpdump on the Dumb AP's wireless interface and the
client's wireless interface and see which of them sees the various parts
of the DHCP handshake.


-- 
Russell Senior, President
russ...@personaltelco.net

[PATCH v2 04/10] clk: add Clock driver for nuc970

[Wan Zongshun]

This patch is to add clock framework driver for nuc970.
The clock controller generates all clocks for Video, Audio,
CPU, system bus and all functionalities, nuc970 includes
two PLL modules.

Signed-off-by: Wan Zongshun 
---
 drivers/clk/Makefile|   1 +
 drivers/clk/nuc900/Makefile |   6 +
 drivers/clk/nuc900/clk-apll.c   | 168 
 drivers/clk/nuc900/clk-ccf.h|  53 +++
 drivers/clk/nuc900/clk-nuc970.c | 925 
 drivers/clk/nuc900/clk-upll.c   |  83 
 6 files changed, 1236 insertions(+)
 create mode 100644 drivers/clk/nuc900/Makefile
 create mode 100644 drivers/clk/nuc900/clk-apll.c
 create mode 100644 drivers/clk/nuc900/clk-ccf.h
 create mode 100644 drivers/clk/nuc900/clk-nuc970.c
 create mode 100644 drivers/clk/nuc900/clk-upll.c

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index dcc5e69..042377d 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -88,3 +88,4 @@ obj-$(CONFIG_ARCH_ZX) += zte/
 obj-$(CONFIG_ARCH_ZYNQ)+= zynq/
 obj-$(CONFIG_H8300)+= h8300/
 obj-$(CONFIG_ARC_PLAT_AXS10X)  += axs10x/
+obj-$(CONFIG_ARCH_W90X900) += nuc900/
diff --git a/drivers/clk/nuc900/Makefile b/drivers/clk/nuc900/Makefile
new file mode 100644
index 000..a6785ab
--- /dev/null
+++ b/drivers/clk/nuc900/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for nuvoton specific clk
+#
+
+obj-$(CONFIG_SOC_NUC970) += clk-apll.o clk-upll.o clk-nuc970.o
+
diff --git a/drivers/clk/nuc900/clk-apll.c b/drivers/clk/nuc900/clk-apll.c
new file mode 100644
index 000..a05aec7
--- /dev/null
+++ b/drivers/clk/nuc900/clk-apll.c
@@ -0,0 +1,168 @@
+/*
+ * Copyright 2016 Wan Zongshun 
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk-ccf.h"
+
+struct clk_apll {
+   struct clk_hw   hw;
+   void __iomem*base;
+};
+
+#define to_clk_apll(clk) (container_of(clk, struct clk_apll, clk))
+
+static int clk_apll_set_rate(struct clk_hw *hw, unsigned long rate,
+unsigned long parent_rate)
+{
+   struct clk_apll *pll = to_clk_apll(hw);
+   unsigned long reg;
+
+   reg = readl(pll->base) & ~0x0FFF;
+
+   switch (rate) {
+   /*usbh*/
+   case 9600:
+   reg |= 0x8027;
+   break;
+   /*i2s*/
+   case 9840:
+   reg |= 0x8028;
+   break;
+   /*i2s*/
+   case 16950:
+   reg |= 0x21f0;
+   break;
+   /*system default, 264MHz*/
+   case 26400:
+   reg |= 0x15;
+   break;
+   case 3:
+   reg |= 0x18;
+   break;
+   default:
+   reg |= 0x15;
+   break;
+   }
+
+   writel(reg, pll->base);
+
+   return 0;
+}
+
+static unsigned long clk_apll_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+   struct clk_apll *pll = to_clk_apll(hw);
+   unsigned long reg = readl(pll->base) & 0x0FFF;
+   unsigned long rate;
+
+   if (parent_rate != 1200)
+   return 0;
+
+   switch (reg) {
+   /*system default, 264MHz*/
+   case 0x15:
+   rate = 26400;
+   break;
+   case 0x18:
+   rate = 3;
+   break;
+   /*usbh*/
+   case 0x8027:
+   rate = 9600;
+   break;
+   /*i2s*/
+   case 0x8028:
+   rate = 9840;
+   break;
+   /*i2s*/
+   case 0x21f0:
+   rate = 16950;
+   break;
+   default:
+   rate = 26400;
+   break;
+   }
+
+   return rate;
+}
+
+static long clk_apll_round_rate(struct clk_hw *hw, unsigned long rate,
+   unsigned long *prate)
+{
+   return rate;
+}
+
+static int clk_apll_enable(struct clk_hw *hw)
+{
+   struct clk_apll *pll = to_clk_apll(hw);
+   unsigned long val;
+
+   val = readl(pll->base);
+   val &= ~0x1000;
+   val |= 0x4000;
+   writel(val, pll->base);
+
+   return 0;
+}
+
+static void clk_apll_disable(struct clk_hw *hw)
+{
+   struct clk_apll *pll = to_clk_apll(hw);
+   unsigned long val;
+
+   val = readl(pll->base);
+   val |= 0x1000;
+   val &= ~0x4000;
+   writel(val, pll->base);
+}
+
+static struct clk_ops clk_apll_ops = {
+   .recalc_rate = clk_apll_recalc_rate,
+   .enable = clk_apll_enable,
+   .disable = clk_apll_disable,
+   .set_rate = 

Re: [GIT PULL] ACPI fixes for v4.7-rc7

[Thorsten Leemhuis]

Hi Rafael!

On 08.07.2016 01:43, Rafael J. Wysocki wrote:
>
> Please pull from
> 
>  git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
>  acpi-4.7-rc7
> 
> to receive ACPI fixes for v4.7-rc7 with top-most commit
> […]
> All of these fix recent regressions in ACPICA, in the ACPI PCI IRQ
> management code and in the ACPI AML debugger.

FYI, it seems these changes lead to a new regression. Quoting
https://bugzilla.kernel.org/show_bug.cgi?id=121701

"""
> Kernel fails to boot with this commit. With the commit reverted,
> everything is fine. I cannot bisect any further - git is failing with
> "you are trying to use to much memory"(?!)
> 
> This is a Dell Precision 5510 with the latest (1.2.10) BIOS applied.
> 
> Let me know what additional information I can provide."""
"""

Cheers, Thorsten

[PATCH 07/10] perf python: Add struct evsel into struct pyrf_event

[Jiri Olsa]

To be able to find out event configuration info
during sample parsing.

Link: http://lkml.kernel.org/n/tip-b63rh6l44ort2t76etobv...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/util/python.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/python.c b/tools/perf/util/python.c
index 45fdd4a68721..dc7adaa3a02c 100644
--- a/tools/perf/util/python.c
+++ b/tools/perf/util/python.c
@@ -48,6 +48,7 @@ PyMODINIT_FUNC initperf(void);
 
 struct pyrf_event {
PyObject_HEAD
+   struct perf_evsel *evsel;
struct perf_sample sample;
union perf_event   event;
 };
@@ -865,11 +866,18 @@ static PyObject *pyrf_evlist__read_on_cpu(struct 
pyrf_evlist *pevlist,
if (event != NULL) {
PyObject *pyevent = pyrf_event__new(event);
struct pyrf_event *pevent = (struct pyrf_event *)pyevent;
+   struct perf_evsel *evsel;
 
if (pyevent == NULL)
return PyErr_NoMemory();
 
-   err = perf_evlist__parse_sample(evlist, event, >sample);
+   evsel = perf_evlist__event2evsel(evlist, event);
+   if (!evsel)
+   return Py_None;
+
+   pevent->evsel = evsel;
+
+   err = perf_evsel__parse_sample(evsel, event, >sample);
 
/* Consume the even only after we parsed it out. */
perf_evlist__mmap_consume(evlist, cpu);
-- 
2.4.11

[PATCH 09/10] perf python: Add tracepoint example

[Jiri Olsa]

To show how to open tracepoint and access its fields.

Reported-and-tested-by: Jiri Pirko 
Link: http://lkml.kernel.org/n/tip-7xt9nvyl45qwbg9237f46...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/python/tracepoint.py | 47 +
 1 file changed, 47 insertions(+)
 create mode 100755 tools/perf/python/tracepoint.py

diff --git a/tools/perf/python/tracepoint.py b/tools/perf/python/tracepoint.py
new file mode 100755
index ..eb4dbed57de7
--- /dev/null
+++ b/tools/perf/python/tracepoint.py
@@ -0,0 +1,47 @@
+#! /usr/bin/python
+# -*- python -*-
+# -*- coding: utf-8 -*-
+
+import perf
+
+class tracepoint(perf.evsel):
+def __init__(self, sys, name):
+config = perf.tracepoint(sys, name)
+perf.evsel.__init__(self,
+type   = perf.TYPE_TRACEPOINT,
+config = config,
+freq = 0, sample_period = 1, wakeup_events = 1,
+sample_type = perf.SAMPLE_PERIOD | perf.SAMPLE_TID 
| perf.SAMPLE_CPU | perf.SAMPLE_RAW | perf.SAMPLE_TIME)
+
+def main():
+tp  = tracepoint("sched", "sched_switch")
+cpus= perf.cpu_map()
+threads = perf.thread_map(-1)
+
+evlist = perf.evlist(cpus, threads)
+evlist.add(tp)
+evlist.open()
+evlist.mmap()
+
+while True:
+evlist.poll(timeout = -1)
+for cpu in cpus:
+event = evlist.read_on_cpu(cpu)
+if not event:
+continue
+
+if not isinstance(event, perf.sample_event):
+continue
+
+print "time %u prev_comm=%s prev_pid=%d prev_prio=%d 
prev_state=0x%x ==> next_comm=%s next_pid=%d next_prio=%d" % (
+   event.sample_time,
+   event.prev_comm,
+   event.prev_pid,
+   event.prev_prio,
+   event.prev_state,
+   event.next_comm,
+   event.next_pid,
+   event.next_prio)
+
+if __name__ == '__main__':
+main()
-- 
2.4.11

[PATCH 08/10] perf python: Add support to resolve tracepoint fields

[Jiri Olsa]

Adding tp_getattro callback for sample event. It resolves
tracepoint fields in runtime.

It's now possible to access tracepoint fields in normal
fashion like hardcoded ones (see the example in the next
patch).

Reported-and-tested-by: Jiri Pirko 
Link: http://lkml.kernel.org/n/tip-0jmugogczg6xkgyieo8sm...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/util/python.c | 92 
 1 file changed, 92 insertions(+)

diff --git a/tools/perf/util/python.c b/tools/perf/util/python.c
index dc7adaa3a02c..d32f97033718 100644
--- a/tools/perf/util/python.c
+++ b/tools/perf/util/python.c
@@ -290,6 +290,97 @@ static PyObject *pyrf_sample_event__repr(struct pyrf_event 
*pevent)
return ret;
 }
 
+static bool is_tracepoint(struct pyrf_event *pevent)
+{
+   return pevent->evsel->attr.type == PERF_TYPE_TRACEPOINT;
+}
+
+static int is_printable_array(char *p, unsigned int len)
+{
+   unsigned int i;
+
+   for (i = 0; i < len; i++) {
+   if (!isprint(p[i]) && !isspace(p[i]))
+   return 0;
+   }
+
+   return 1;
+}
+
+static PyObject*
+tracepoint_field(struct pyrf_event *pe, struct format_field *field)
+{
+   struct pevent *pevent = field->event->pevent;
+   void *data = pe->sample.raw_data;
+   PyObject *ret = NULL;
+   unsigned long long val;
+   unsigned int offset, len;
+
+   if (field->flags & FIELD_IS_ARRAY) {
+   offset = field->offset;
+   len= field->size;
+   if (field->flags & FIELD_IS_DYNAMIC) {
+   val = pevent_read_number(pevent, data + offset, 
len);
+   offset  = val;
+   len = offset >> 16;
+   offset &= 0x;
+   }
+   if (field->flags & FIELD_IS_STRING &&
+   is_printable_array(data + offset, len)) {
+   ret = PyString_FromString((char *)data + offset);
+   } else {
+   ret = PyByteArray_FromStringAndSize((const char *) data 
+ offset, len);
+   field->flags &= ~FIELD_IS_STRING;
+   }
+   } else {
+   val = pevent_read_number(pevent, data + field->offset,
+field->size);
+   if (field->flags & FIELD_IS_POINTER)
+   ret = PyLong_FromUnsignedLong((unsigned long) val);
+   else if (field->flags & FIELD_IS_SIGNED)
+   ret = PyLong_FromLong((long) val);
+   else
+   ret = PyLong_FromUnsignedLong((unsigned long) val);
+   }
+
+   return ret;
+}
+
+static PyObject*
+get_tracepoint_field(struct pyrf_event *pevent, PyObject *attr_name)
+{
+   const char *str = PyString_AsString(PyObject_Str(attr_name));
+   struct perf_evsel *evsel = pevent->evsel;
+   struct format_field *field;
+
+   if (!evsel->tp_format) {
+   struct event_format *tp_format;
+
+   tp_format = trace_event__tp_format_id(evsel->attr.config);
+   if (!tp_format)
+   return NULL;
+
+   evsel->tp_format = tp_format;
+   }
+
+   field = pevent_find_any_field(evsel->tp_format, str);
+   if (!field)
+   return NULL;
+
+   return tracepoint_field(pevent, field);
+}
+
+static PyObject*
+pyrf_sample_event__getattro(struct pyrf_event *pevent, PyObject *attr_name)
+{
+   PyObject *obj = NULL;
+
+   if (is_tracepoint(pevent))
+   obj = get_tracepoint_field(pevent, attr_name);
+
+   return obj ?: PyObject_GenericGetAttr((PyObject *) pevent, attr_name);
+}
+
 static PyTypeObject pyrf_sample_event__type = {
PyVarObject_HEAD_INIT(NULL, 0)
.tp_name= "perf.sample_event",
@@ -298,6 +389,7 @@ static PyTypeObject pyrf_sample_event__type = {
.tp_doc = pyrf_sample_event__doc,
.tp_members = pyrf_sample_event__members,
.tp_repr= (reprfunc)pyrf_sample_event__repr,
+   .tp_getattro= (getattrofunc) pyrf_sample_event__getattro,
 };
 
 static char pyrf_context_switch_event__doc[] = PyDoc_STR("perf context_switch 
event object.");
-- 
2.4.11

[PATCH 06/10] perf python: Add perf.tracepoint method

[Jiri Olsa]

To get id of the tracepoint from subsystem and
name strings. The interface is:

  id = perf.tracepoint(sys, name)

In case of error -1 is returned.

It will be used to get python tracepoint event's
config value for tracepoint event.

Link: http://lkml.kernel.org/n/tip-ssizvbkk2lds6bti2z69t...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/util/python.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/tools/perf/util/python.c b/tools/perf/util/python.c
index fc277e486d17..45fdd4a68721 100644
--- a/tools/perf/util/python.c
+++ b/tools/perf/util/python.c
@@ -2,6 +2,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "evlist.h"
 #include "evsel.h"
 #include "event.h"
@@ -1076,7 +1077,32 @@ static struct {
{ .name = NULL, },
 };
 
+static PyObject *pyrf__tracepoint(struct pyrf_evsel *pevsel,
+ PyObject *args, PyObject *kwargs)
+{
+   struct event_format *tp_format;
+   static char *kwlist[] = { "sys", "name", NULL };
+   char *sys  = NULL;
+   char *name = NULL;
+
+   if (!PyArg_ParseTupleAndKeywords(args, kwargs, "|ss", kwlist,
+, ))
+   return NULL;
+
+   tp_format = trace_event__tp_format(sys, name);
+   if (IS_ERR(tp_format))
+   return PyInt_FromLong(-1);
+
+   return PyInt_FromLong(tp_format->id);
+}
+
 static PyMethodDef perf__methods[] = {
+   {
+   .ml_name  = "tracepoint",
+   .ml_meth  = (PyCFunction) pyrf__tracepoint,
+   .ml_flags = METH_VARARGS | METH_KEYWORDS,
+   .ml_doc   = PyDoc_STR("Get tracepoint config.")
+   },
{ .ml_name = NULL, }
 };
 
-- 
2.4.11

[PATCH 01/10] perf tools: Make perf_evlist__event2evsel public

[Jiri Olsa]

It will be used outside of evlist.c object
in folowing patches.

Link: http://lkml.kernel.org/n/tip-m4jswtxn3ff3jn5qoo5h6...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/util/evlist.c | 4 ++--
 tools/perf/util/evlist.h | 3 +++
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 113507716044..3aca5c9acef1 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -651,8 +651,8 @@ static int perf_evlist__event2id(struct perf_evlist *evlist,
return 0;
 }
 
-static struct perf_evsel *perf_evlist__event2evsel(struct perf_evlist *evlist,
-  union perf_event *event)
+struct perf_evsel *perf_evlist__event2evsel(struct perf_evlist *evlist,
+   union perf_event *event)
 {
struct perf_evsel *first = perf_evlist__first(evlist);
struct hlist_head *head;
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index 872912b392c9..afd087761a47 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -323,4 +323,7 @@ void perf_event_attr__set_max_precise_ip(struct 
perf_event_attr *attr);
 
 struct perf_evsel *
 perf_evlist__find_evsel_by_str(struct perf_evlist *evlist, const char *str);
+
+struct perf_evsel *perf_evlist__event2evsel(struct perf_evlist *evlist,
+   union perf_event *event);
 #endif /* __PERF_EVLIST_H */
-- 
2.4.11

[PATCH 03/10] perf python: Init perf_event_attr::size in perf.evsel constructor

[Jiri Olsa]

Currently 0 is passed as perf_event_attr::size,
which could block usage of new features.

Link: http://lkml.kernel.org/n/tip-kyzkn52sg75mcqrhsjbfe...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/util/python.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/perf/util/python.c b/tools/perf/util/python.c
index 65c6c73d28fe..d0c1267741ee 100644
--- a/tools/perf/util/python.c
+++ b/tools/perf/util/python.c
@@ -653,6 +653,7 @@ static int pyrf_evsel__init(struct pyrf_evsel *pevsel,
attr.precise_ip = precise_ip;
attr.mmap_data  = mmap_data;
attr.sample_id_all  = sample_id_all;
+   attr.size   = sizeof(attr);
 
perf_evsel__init(>evsel, , idx);
return 0;
-- 
2.4.11

[PATCH 02/10] perf tools: Introduce trace_event__tp_format_id function

[Jiri Olsa]

To get struct event_format object from tracepoint ID.
It will be used in following patches.

Link: http://lkml.kernel.org/n/tip-0omstcxuxa8npi3otondl...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/util/trace-event.c | 9 +
 tools/perf/util/trace-event.h | 2 ++
 2 files changed, 11 insertions(+)

diff --git a/tools/perf/util/trace-event.c b/tools/perf/util/trace-event.c
index 8ae051e0ec79..883caa8941a9 100644
--- a/tools/perf/util/trace-event.c
+++ b/tools/perf/util/trace-event.c
@@ -105,3 +105,12 @@ trace_event__tp_format(const char *sys, const char *name)
 
return tp_format(sys, name);
 }
+
+struct event_format*
+trace_event__tp_format_id(int id)
+{
+   if (!tevent_initialized && trace_event__init2())
+   return ERR_PTR(-ENOMEM);
+
+   return pevent_find_event(tevent.pevent, id);
+}
diff --git a/tools/perf/util/trace-event.h b/tools/perf/util/trace-event.h
index bce5b1dac268..b0af9c81bb0d 100644
--- a/tools/perf/util/trace-event.h
+++ b/tools/perf/util/trace-event.h
@@ -23,6 +23,8 @@ int trace_event__register_resolver(struct machine *machine,
 struct event_format*
 trace_event__tp_format(const char *sys, const char *name);
 
+struct event_format *trace_event__tp_format_id(int id);
+
 int bigendian(void);
 
 void event_format__fprintf(struct event_format *event,
-- 
2.4.11

[PATCH 00/10] perf python: Add support to access tracepoint fields

[Jiri Olsa]

hi,
adding support to access tracepoint fields in python scripts.

With this patchset it's possible to access tracepoint fields
in event python object like:

  print "time %u prev_comm=%s prev_pid=%d prev_prio=%d prev_state=0x%x ==> 
next_comm=%s next_pid=%d next_prio=%d" % (
 event.sample_time,
 event.prev_comm,
 event.prev_pid,
 event.prev_prio,
 event.prev_state,
 event.next_comm,
 event.next_pid,
 event.next_prio)

Also available in:
  git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
  perf/fixes

thanks,
jirka


---
Jiri Olsa (10):
  perf tools: Make perf_evlist__event2evsel public
  perf tools: Introduce trace_event__tp_format_id function
  perf python: Init perf_event_attr::size in perf.evsel constructor
  perf python: Fix pyrf_evlist__read_on_cpu event consuming
  perf python: Put perf.event objects into dictionary
  perf python: Add perf.tracepoint method
  perf python: Add struct evsel into struct pyrf_event
  perf python: Add support to resolve tracepoint fields
  perf python: Add tracepoint example
  perf script python: Fix string vs byte array resolving

 tools/perf/python/tracepoint.py|  47 
++
 tools/perf/util/evlist.c   |   4 +-
 tools/perf/util/evlist.h   |   3 ++
 tools/perf/util/python.c   | 162 
++--
 tools/perf/util/scripting-engines/trace-event-python.c |  34 +---
 tools/perf/util/trace-event.c  |   9 +
 tools/perf/util/trace-event.h  |   2 +
 7 files changed, 250 insertions(+), 11 deletions(-)
 create mode 100755 tools/perf/python/tracepoint.py

[PATCH 04/10] perf python: Fix pyrf_evlist__read_on_cpu event consuming

[Jiri Olsa]

We can't consume the event before parsing it. Under heavy
load we could get caught by kernel writer overwriting the
event we're trying to parse.

Link: http://lkml.kernel.org/n/tip-8dbalvrufeisa4cioyd9k...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/util/python.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/python.c b/tools/perf/util/python.c
index d0c1267741ee..c68ef0319114 100644
--- a/tools/perf/util/python.c
+++ b/tools/perf/util/python.c
@@ -865,12 +865,14 @@ static PyObject *pyrf_evlist__read_on_cpu(struct 
pyrf_evlist *pevlist,
PyObject *pyevent = pyrf_event__new(event);
struct pyrf_event *pevent = (struct pyrf_event *)pyevent;
 
-   perf_evlist__mmap_consume(evlist, cpu);
-
if (pyevent == NULL)
return PyErr_NoMemory();
 
err = perf_evlist__parse_sample(evlist, event, >sample);
+
+   /* Consume the even only after we parsed it out. */
+   perf_evlist__mmap_consume(evlist, cpu);
+
if (err)
return PyErr_Format(PyExc_OSError,
"perf: can't parse sample, err=%d", 
err);
-- 
2.4.11

[PATCH 05/10] perf python: Put perf.event objects into dictionary

[Jiri Olsa]

Make perf.event object parts of the perf module
dictionary so we can address them by name.

Following objects/names are added:
  mmap_event
  lost_event
  comm_event
  task_event
  throttle_event
  task_event
  read_event
  sample_event
  switch_event

We can now use it in python script like:
  ...
  event = evlist.read_on_cpu(cpu)
  ...
  if not isinstance(event, perf.sample_event):

Link: http://lkml.kernel.org/n/tip-s8rjqtol03f9wwueghadb...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/util/python.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/tools/perf/util/python.c b/tools/perf/util/python.c
index c68ef0319114..fc277e486d17 100644
--- a/tools/perf/util/python.c
+++ b/tools/perf/util/python.c
@@ -1103,6 +1103,33 @@ PyMODINIT_FUNC initperf(void)
Py_INCREF(_evsel__type);
PyModule_AddObject(module, "evsel", (PyObject*)_evsel__type);
 
+   Py_INCREF(_mmap_event__type);
+   PyModule_AddObject(module, "mmap_event", (PyObject 
*)_mmap_event__type);
+
+   Py_INCREF(_lost_event__type);
+   PyModule_AddObject(module, "lost_event", (PyObject 
*)_lost_event__type);
+
+   Py_INCREF(_comm_event__type);
+   PyModule_AddObject(module, "comm_event", (PyObject 
*)_comm_event__type);
+
+   Py_INCREF(_task_event__type);
+   PyModule_AddObject(module, "task_event", (PyObject 
*)_task_event__type);
+
+   Py_INCREF(_throttle_event__type);
+   PyModule_AddObject(module, "throttle_event", (PyObject 
*)_throttle_event__type);
+
+   Py_INCREF(_task_event__type);
+   PyModule_AddObject(module, "task_event", (PyObject 
*)_task_event__type);
+
+   Py_INCREF(_read_event__type);
+   PyModule_AddObject(module, "read_event", (PyObject 
*)_read_event__type);
+
+   Py_INCREF(_sample_event__type);
+   PyModule_AddObject(module, "sample_event", (PyObject 
*)_sample_event__type);
+
+   Py_INCREF(_context_switch_event__type);
+   PyModule_AddObject(module, "switch_event", (PyObject 
*)_context_switch_event__type);
+
Py_INCREF(_thread_map__type);
PyModule_AddObject(module, "thread_map", 
(PyObject*)_thread_map__type);
 
-- 
2.4.11

[PATCH 10/10] perf script python: Fix string vs byte array resolving

[Jiri Olsa]

Jirka reported that python code returns all arrays as strings.
This makes impossible to get all items for byte array tracepoint
field containing 0x00 value item.

Fixing this by scanning full length of the array and returning
it as PyByteArray object in case non printable byte is found.

Cc: Steven Rostedt (Red Hat) 
Reported-and-tested-by: Jiri Pirko 
Link: http://lkml.kernel.org/n/tip-22f4vhhz5uytegkggy1on...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 .../util/scripting-engines/trace-event-python.c| 34 ++
 1 file changed, 28 insertions(+), 6 deletions(-)

diff --git a/tools/perf/util/scripting-engines/trace-event-python.c 
b/tools/perf/util/scripting-engines/trace-event-python.c
index ff134700bf30..75e9790ebb96 100644
--- a/tools/perf/util/scripting-engines/trace-event-python.c
+++ b/tools/perf/util/scripting-engines/trace-event-python.c
@@ -386,6 +386,16 @@ exit:
return pylist;
 }
 
+static int is_printable_array(char *p, unsigned int len)
+{
+   unsigned int i;
+
+   for (i = 0; i < len; i++)
+   if (!isprint(p[i]) && !isspace(p[i]))
+   return 0;
+
+   return 1;
+}
 
 static void python_process_tracepoint(struct perf_sample *sample,
  struct perf_evsel *evsel,
@@ -457,14 +467,26 @@ static void python_process_tracepoint(struct perf_sample 
*sample,
pydict_set_item_string_decref(dict, "common_callchain", 
callchain);
}
for (field = event->format.fields; field; field = field->next) {
-   if (field->flags & FIELD_IS_STRING) {
-   int offset;
+   unsigned int offset, len;
+   unsigned long long val;
+
+   if (field->flags & FIELD_IS_ARRAY) {
+   offset = field->offset;
+   len= field->size;
if (field->flags & FIELD_IS_DYNAMIC) {
-   offset = *(int *)(data + field->offset);
+   val = 
pevent_read_number(scripting_context->pevent,
+data + offset, 
len);
+   offset  = val;
+   len = offset >> 16;
offset &= 0x;
-   } else
-   offset = field->offset;
-   obj = PyString_FromString((char *)data + offset);
+   }
+   if (field->flags & FIELD_IS_STRING &&
+   is_printable_array(data + offset, len)) {
+   obj = PyString_FromString((char *) data + 
offset);
+   } else {
+   obj = PyByteArray_FromStringAndSize((const char 
*) data + offset, len);
+   field->flags &= ~FIELD_IS_STRING;
+   }
} else { /* FIELD_IS_NUMERIC */
obj = get_field_numeric_entry(event, field, data);
}
-- 
2.4.11

Re: [tip:x86/boot] x86/KASLR: Fix boot crash with certain memory configurations

[Ingo Molnar]

* Baoquan He  wrote:

> Hi Ingo,
> 
> I am sorry the previous post didn't contain formal patch log. I made a new 
> one 
> as below. The boot crash could not only happen with certain memory. Because 
> of 
> this code bug the regions which need be avoided like the zipped kernel with 
> its 
> unzipping running code, initrd, kernel command line could be corrupted if 
> mem_avoid_overlap() can't find the overlap region with the lowest address. 
> But 
> it's very lucky that Xiaolong's system which has only 300M memory can always 
> reproduce it. I checked the boog log and found on his system no any other 
> slot 
> can be chosen except for the original one. If we have a system with large 
> memory 
> it may not be easy to hit it, at least with low probability since there are 
> many 
> candidate slots.

So if it's just a better changelog that what I wrote I wouldn't rebase the 
commit: 
there's other commits on top of the fix meanwhile. Should a rebase become 
necessary at a later point I'll update it with your extended changelog.

Thanks,

Ingo

[PATCH v1] driver core: fix race between creating/querying glue dir and its cleanup

[Ming Lei]

The global mutex of 'gdp_mutex' is used to serialize creating/querying
glue dir and its cleanup. Turns out it isn't a perfect way because
part(kobj_kset_leave()) of the actual cleanup action() is done inside
the release handler of the glue dir kobject. That means gdp_mutex has
to be held before releasing the last reference count of the glue dir
kobject.

This patch moves glue dir's cleanup after kobject_del() in device_del()
for avoiding the race.

Cc: Yijing Wang 
Reported-by: Chandra Sekhar Lingutla 
Signed-off-by: Ming Lei 
---
V1:
- fix live_in_glue_dir() by Chandra
- fix get_glue_dir
- now it can pass of-unittest, in which ktest robot reported
failure before

 drivers/base/core.c | 39 +--
 1 file changed, 29 insertions(+), 10 deletions(-)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index 0a8bdad..88df65d 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -836,11 +836,29 @@ static struct kobject *get_device_parent(struct device 
*dev,
return NULL;
 }
 
+static inline bool live_in_glue_dir(struct kobject *kobj,
+   struct device *dev)
+{
+   if (!kobj || !dev->class ||
+   kobj->kset != >class->p->glue_dirs)
+   return false;
+   return true;
+}
+
+static inline struct kobject *get_glue_dir(struct device *dev)
+{
+   return dev->kobj.parent;
+}
+
+/*
+ * make sure cleaning up dir as the last step, we need to make
+ * sure .release handler of kobject is run with holding the
+ * global lock
+ */
 static void cleanup_glue_dir(struct device *dev, struct kobject *glue_dir)
 {
/* see if we live in a "glue" directory */
-   if (!glue_dir || !dev->class ||
-   glue_dir->kset != >class->p->glue_dirs)
+   if (!live_in_glue_dir(glue_dir, dev))
return;
 
mutex_lock(_mutex);
@@ -848,11 +866,6 @@ static void cleanup_glue_dir(struct device *dev, struct 
kobject *glue_dir)
mutex_unlock(_mutex);
 }
 
-static void cleanup_device_parent(struct device *dev)
-{
-   cleanup_glue_dir(dev, dev->kobj.parent);
-}
-
 static int device_add_class_symlinks(struct device *dev)
 {
struct device_node *of_node = dev_of_node(dev);
@@ -1028,6 +1041,7 @@ int device_add(struct device *dev)
struct kobject *kobj;
struct class_interface *class_intf;
int error = -EINVAL;
+   struct kobject *glue_dir = NULL;
 
dev = get_device(dev);
if (!dev)
@@ -1072,8 +1086,10 @@ int device_add(struct device *dev)
/* first, register with generic layer. */
/* we require the name to be set before, and pass NULL */
error = kobject_add(>kobj, dev->kobj.parent, NULL);
-   if (error)
+   if (error) {
+   glue_dir = get_glue_dir(dev);
goto Error;
+   }
 
/* notify platform of device entry */
if (platform_notify)
@@ -1154,9 +1170,10 @@ done:
device_remove_file(dev, _attr_uevent);
  attrError:
kobject_uevent(>kobj, KOBJ_REMOVE);
+   glue_dir = get_glue_dir(dev);
kobject_del(>kobj);
  Error:
-   cleanup_device_parent(dev);
+   cleanup_glue_dir(dev, glue_dir);
put_device(parent);
 name_error:
kfree(dev->p);
@@ -1232,6 +1249,7 @@ EXPORT_SYMBOL_GPL(put_device);
 void device_del(struct device *dev)
 {
struct device *parent = dev->parent;
+   struct kobject *glue_dir = NULL;
struct class_interface *class_intf;
 
/* Notify clients of device removal.  This call must come
@@ -1276,8 +1294,9 @@ void device_del(struct device *dev)
blocking_notifier_call_chain(>bus->p->bus_notifier,
 BUS_NOTIFY_REMOVED_DEVICE, dev);
kobject_uevent(>kobj, KOBJ_REMOVE);
-   cleanup_device_parent(dev);
+   glue_dir = get_glue_dir(dev);
kobject_del(>kobj);
+   cleanup_glue_dir(dev, glue_dir);
put_device(parent);
 }
 EXPORT_SYMBOL_GPL(device_del);
-- 
1.9.1

[tip:x86/platform] x86/platform/intel-mid: Mark regulators explicitly defined

[tip-bot for Andy Shevchenko]

Commit-ID:  a11836fa5a67ba56d8338138e37b42384af73e5e
Gitweb: http://git.kernel.org/tip/a11836fa5a67ba56d8338138e37b42384af73e5e
Author: Andy Shevchenko 
AuthorDate: Sat, 9 Jul 2016 16:45:29 +0300
Committer:  Ingo Molnar 
CommitDate: Sun, 10 Jul 2016 10:33:41 +0200

x86/platform/intel-mid: Mark regulators explicitly defined

Intel MID platforms are using explicitly defined regulators.

Let the regulator core know that we do not have any additional
regulators left. This lets it substitute unprovided regulators with
dummy ones.

Without this change when CONFIG_REGULATOR=y the USB driver fails on getting
"vbus" regulator and SDHCI can't get "vmmc" and "vqmmc" regulators either.

Signed-off-by: Andy Shevchenko 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1468071929-77383-1-git-send-email-andriy.shevche...@linux.intel.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/platform/intel-mid/intel-mid.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/x86/platform/intel-mid/intel-mid.c 
b/arch/x86/platform/intel-mid/intel-mid.c
index 90bb997..abbf49c 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -144,6 +145,15 @@ static void intel_mid_arch_setup(void)
 out:
if (intel_mid_ops->arch_setup)
intel_mid_ops->arch_setup();
+
+   /*
+* Intel MID platforms are using explicitly defined regulators.
+*
+* Let the regulator core know that we do not have any additional
+* regulators left. This lets it substitute unprovided regulators with
+* dummy ones:
+*/
+   regulator_has_full_constraints();
 }
 
 /* MID systems don't have i8042 controller */

Re: [tip:x86/asm] x86/entry: Inline enter_from_user_mode()

[Ingo Molnar]

* Borislav Petkov  wrote:

> tip-bot for Paolo Bonzini  wrote:
> 
> >Commit-ID:  eec4b1227db153ca16f8f5f285d01fefdce05438
> >Gitweb:
> >http://git.kernel.org/tip/eec4b1227db153ca16f8f5f285d01fefdce05438
> >Author: Paolo Bonzini 
> >AuthorDate: Mon, 20 Jun 2016 16:58:30 +0200
> >Committer:  Ingo Molnar 
> >CommitDate: Sat, 9 Jul 2016 10:44:02 +0200
> >
> >x86/entry: Inline enter_from_user_mode()
> >
> >This matches what is already done for prepare_exit_to_usermode(),
> >and saves about 60 clock cycles (4% speedup) with the benchmark
> >in the previous commit message.
> >
> >Signed-off-by: Paolo Bonzini 
> >Reviewed-by: Rik van Riel 
> >Reviewed-by: Andy Lutomirski 
> >Reviewed-by: Rik van Riel 
> >Reviewed-by: Andy Lutomirski 
> >Reviewed-by: Rik van Riel 
> >Reviewed-by: Andy Lutomirski 
> >Reviewed-by: Rik van Riel 
> >Reviewed-by: Andy Lutomirski 
> >Acked-by: Paolo Bonzini 
> 
> Woohaa, if that amount of review doesn't get this patch upstream I don't know 
> what will ;-)

Gah, that's a script gone bad - fixed!

Thanks,

Ingo

[tip:x86/asm] x86/entry: Inline enter_from_user_mode()

[tip-bot for Paolo Bonzini]

Commit-ID:  be8a18e2e98e04a5def5887d913b267865562448
Gitweb: http://git.kernel.org/tip/be8a18e2e98e04a5def5887d913b267865562448
Author: Paolo Bonzini 
AuthorDate: Mon, 20 Jun 2016 16:58:30 +0200
Committer:  Ingo Molnar 
CommitDate: Sun, 10 Jul 2016 13:33:02 +0200

x86/entry: Inline enter_from_user_mode()

This matches what is already done for prepare_exit_to_usermode(),
and saves about 60 clock cycles (4% speedup) with the benchmark
in the previous commit message.

Signed-off-by: Paolo Bonzini 
Reviewed-by: Rik van Riel 
Reviewed-by: Andy Lutomirski 
Acked-by: Paolo Bonzini 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: k...@vger.kernel.org
Link: 
http://lkml.kernel.org/r/1466434712-31440-3-git-send-email-pbonz...@redhat.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/entry/common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
index 618bc61..9e1e27d 100644
--- a/arch/x86/entry/common.c
+++ b/arch/x86/entry/common.c
@@ -40,7 +40,7 @@ static struct thread_info *pt_regs_to_thread_info(struct 
pt_regs *regs)
 
 #ifdef CONFIG_CONTEXT_TRACKING
 /* Called on entry from user mode with IRQs off. */
-__visible void enter_from_user_mode(void)
+__visible inline void enter_from_user_mode(void)
 {
CT_WARN_ON(ct_state() != CONTEXT_USER);
user_exit_irqoff();

[tip:x86/asm] x86/entry: Avoid interrupt flag save and restore

[tip-bot for Paolo Bonzini]

Commit-ID:  2e9d1e150abf88cb63e5d34ca286edbb95b4c53d
Gitweb: http://git.kernel.org/tip/2e9d1e150abf88cb63e5d34ca286edbb95b4c53d
Author: Paolo Bonzini 
AuthorDate: Mon, 20 Jun 2016 16:58:29 +0200
Committer:  Ingo Molnar 
CommitDate: Sun, 10 Jul 2016 13:33:02 +0200

x86/entry: Avoid interrupt flag save and restore

Thanks to all the work that was done by Andy Lutomirski and others,
enter_from_user_mode() and prepare_exit_to_usermode() are now called only with
interrupts disabled.  Let's provide them a version of user_enter()/user_exit()
that skips saving and restoring the interrupt flag.

On an AMD-based machine I tested this patch on, with force-enabled
context tracking, the speed-up in system calls was 90 clock cycles or 6%,
measured with the following simple benchmark:

#include 
#include 
#include 
#include 

unsigned long rdtsc()
{
unsigned long result;
asm volatile("rdtsc; shl $32, %%rdx; mov %%eax, %%eax\n"
 "or %%rdx, %%rax" : "=a" (result) : : "rdx");
return result;
}

int main()
{
unsigned long tsc1, tsc2;
int pid = getpid();
int i;

tsc1 = rdtsc();
for (i = 0; i < 1; i++)
kill(pid, SIGWINCH);
tsc2 = rdtsc();

printf("%ld\n", tsc2 - tsc1);
}

Signed-off-by: Paolo Bonzini 
Reviewed-by: Rik van Riel 
Reviewed-by: Andy Lutomirski 
Acked-by: Paolo Bonzini 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: k...@vger.kernel.org
Link: 
http://lkml.kernel.org/r/1466434712-31440-2-git-send-email-pbonz...@redhat.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/entry/common.c  |  4 ++--
 include/linux/context_tracking.h | 15 +++
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
index ec138e5..618bc61 100644
--- a/arch/x86/entry/common.c
+++ b/arch/x86/entry/common.c
@@ -43,7 +43,7 @@ static struct thread_info *pt_regs_to_thread_info(struct 
pt_regs *regs)
 __visible void enter_from_user_mode(void)
 {
CT_WARN_ON(ct_state() != CONTEXT_USER);
-   user_exit();
+   user_exit_irqoff();
 }
 #else
 static inline void enter_from_user_mode(void) {}
@@ -274,7 +274,7 @@ __visible inline void prepare_exit_to_usermode(struct 
pt_regs *regs)
ti->status &= ~TS_COMPAT;
 #endif
 
-   user_enter();
+   user_enter_irqoff();
 }
 
 #define SYSCALL_EXIT_WORK_FLAGS\
diff --git a/include/linux/context_tracking.h b/include/linux/context_tracking.h
index d259274..d9aef2a 100644
--- a/include/linux/context_tracking.h
+++ b/include/linux/context_tracking.h
@@ -31,6 +31,19 @@ static inline void user_exit(void)
context_tracking_exit(CONTEXT_USER);
 }
 
+/* Called with interrupts disabled.  */
+static inline void user_enter_irqoff(void)
+{
+   if (context_tracking_is_enabled())
+   __context_tracking_enter(CONTEXT_USER);
+
+}
+static inline void user_exit_irqoff(void)
+{
+   if (context_tracking_is_enabled())
+   __context_tracking_exit(CONTEXT_USER);
+}
+
 static inline enum ctx_state exception_enter(void)
 {
enum ctx_state prev_ctx;
@@ -69,6 +82,8 @@ static inline enum ctx_state ct_state(void)
 #else
 static inline void user_enter(void) { }
 static inline void user_exit(void) { }
+static inline void user_enter_irqoff(void) { }
+static inline void user_exit_irqoff(void) { }
 static inline enum ctx_state exception_enter(void) { return 0; }
 static inline void exception_exit(enum ctx_state prev_ctx) { }
 static inline enum ctx_state ct_state(void) { return CONTEXT_DISABLED; }

Re: [PATCH] iommu/amd: Fix unity mapping initialization race

[Wan Zongshun]

On 2016年07月07日 00:00, Joerg Roedel wrote:

From: Joerg Roedel 

There is a race condition in the AMD IOMMU init code that
causes requested unity mappings to be blocked by the IOMMU
for a short period of time. This results on boot failures
and IO_PAGE_FAULTs on some machines.

Fix this by making sure the unity mappings are installed
before all other DMA is blocked.

Fixes: aafd8ba0ca74 ('iommu/amd: Implement add_device and remove_device')
Cc: sta...@vger.kernel.org # v4.2+
Signed-off-by: Joerg Roedel 
---
  drivers/iommu/amd_iommu_init.c | 14 --
  1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index d091def..59741ea 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -1568,13 +1568,23 @@ static int __init amd_iommu_init_pci(void)
break;
}

+   /*
+* Order is important here to make sure any unity map requirements are
+* fulfilled. The unity mappings are created and written to the device
+* table during the amd_iommu_init_api() call.
+*
+* After that we call init_device_table_dma() to make sure any
+* uninitialized DTE will block DMA, and in the end we flush the caches
+* of all IOMMUs to make sure the changes to the device table are
+* active.
+*/


Joerg,

Do you mean we need enable the V and TV bits to DTE entry after all DTEs 
tables were initialized completely?


I checked this function 'init_device_table_dma', and find it just set
V and TV bit, to set translation info valid and DTE bits127:1 valid.

So I just think all things it should to do are to allow DMA access,
GPA-to-SPA translation should be active, why you add function comments 
below is to not allow DMA access and suppress all page faults?


/*
 * Init the device table to not allow DMA access for devices and
 * suppress all page faults
 */
static void init_device_table_dma(void)


+   ret = amd_iommu_init_api();
+
init_device_table_dma();

for_each_iommu(iommu)
iommu_flush_all_caches(iommu);

-   ret = amd_iommu_init_api();
-
if (!ret)
print_iommu_info();

Re: [PATCH 0/9] mm: Hardened usercopy

[PaX Team]

On 10 Jul 2016 at 11:16, Ingo Molnar wrote:

> * PaX Team  wrote:
> 
> > On 9 Jul 2016 at 14:27, Andy Lutomirski wrote:
> > 
> > > I like the series, but I have one minor nit to pick.  The effect of this 
> > > series is to harden usercopy, but most of the code is really about 
> > > infrastructure to validate that a pointed-to object is valid.
> > 
> > actually USERCOPY has never been about validating pointers. its sole 
> > purpose is 
> > to validate the *size* argument of copy*user calls, a very specific form of 
> > runtime bounds checking.
> 
> What this code has been about originally is largely immaterial, unless you 
> can 
> formulate it into a technical argument.

we design defense mechanisms for specific and clear purposes, starting with
a threat model, evaluating defense options based on various criteria, etc.
USERCOPY underwent this same process and taking it out of its original context
means that all you get in the end is cargo cult security (wouldn't be the first
time it has happened (ExecShield, ASLR, etc)).

that said, i actually started that discussion but for some reason you chose
not to respond to that one part of my mail so let me ask it again:

  what kind of checks are you thinking of here? and more fundamentally, against
  what kind of threats?

as far as i'm concerned, a defense mechanism is only as good as its underlying
threat model. by validating pointers (for yet to be stated security related
properties) you're presumably assuming some kind of threat and unless stated
clearly what that threat is (unintended pointer modification through memory
corruption and/or other bugs?) noone can tell whether the proposed defense
mechanism will actually be effective in preventing exploitation. it is the
worst kind of defense that doesn't actually achieve its stated goals, that
way lies false sense of security and i hope noone here is in that business.

i note that this analysis is also missing from this USERCOPY submission except
for stating what Kees assumed about USERCOPY (and apparently noone could be
bothered to read the original Kconfig help of it which clearly states that the
purpose is copy size checking, not some elaborate pointer validation, the latter
is an implementation detail only and is necessary to be able to derive the
underlying slab object's intended size).

> There are a number of cheap tests we can do and there are a number of ways 
> how a 
> 'pointer' can be validated runtime, without any 'size' information:
> 
>  - for example if a pointer points into a red zone straight away then we know 
> it's
>bogus.

it's not pointer validation but bounds checking: you already know which memory
object the pointer is supposed to point to, you only check its bounds. if it was
an attacker controlled pointer then all this would be a pointless check of 
course,
trivial for an attacker to circumvent (and this is why it's not part of the
USERCOPY design).

>  - or if a kernel pointer is points outside the valid kernel virtual memory 
> range
>we know it's bogus as well.

accesses outside of valid virtual memory will cause a page fault ('oops' in 
linux
terms), there's no need to explicitly check for that.

> So while only doing a bounds check might have been the original purpose of 
> the 
> patch set, Andy's point is that it might make sense to treat this facility as 
> a 
> more generic 'object validation' code of (pointer,size) object and not limit 
> it to 
> 'runtime bounds checking'.

FYI, 'runtime bounds checking' is a terminus technicus and it is about 
validating
both the pointer and underlying object's size. that's the reason i called 
USERCOPY
a 'very specific form' of it only since it doesn't validate each part equally 
well
(or well enough at all, even the size check is not as precise as it could be).

as for what does or doesn't make sense, first you'll have to define a threat
model and evaluate everything else based on that. since noone has solved the
general bounds checking problem with acceptable properties (mostly performance
impact, but also memory overhead, etc), i'm all ears to hear what you guys have
come up with.

> That kind of extended purpose behind a facility should be reflected in the 
> naming.
> Confusing names are often the source of misunderstandings and bugs.

definitely, but before you bikeshed on naming, you should figure out what and 
why
you want to do, whether it's even feasible, meaningful, useful, etc. answering 
the
opening question and digging into the details is the first step of any design
process, not its naming.

> The 9-patch series as submitted here is neither just 'bounds checking' nor 
> just 
> pure 'pointer checking', it's about validating that a (pointer,size) range of 
> memory passed to a (user) memory copy function is fully within a valid object 
> the 
> kernel might know about (in an fast to check fashion).
> 
> This necessary means:
> 
>  - the start of the range points to a valid object to begin 

Re: [tip:x86/debug] printk: Make the printk*once() variants return a value

[Borislav Petkov]

On Sun, Jul 10, 2016 at 01:23:51AM -0700, Joe Perches wrote:
> Assuming tip is included in linux-next as of july 8, yes.

Try one which has 
http://git.kernel.org/tip/81c2949f7fdcf8ff681326669afde24962232670

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH] nvme-loop: add configfs dependency

[Christoph Hellwig]

On Thu, Jul 07, 2016 at 08:35:17AM -0600, Jens Axboe wrote:
> Thanks Arnd, applied.

Actually I think we should replace the select with the depends.  In
fact I though I had done that a while ago, but I must have messed it up.

Btw - do you plan to grab patches directly from the list now or
do you want me to queue them up?  There are a few more pending on
the list that should go in:

http://lists.infradead.org/pipermail/linux-nvme/2016-June/005150.html
(whole series)

http://lists.infradead.org/pipermail/linux-nvme/2016-July/005290.html
(needs the attribution fixed to be from Ming)

http://lists.infradead.org/pipermail/linux-nvme/2016-July/005318.html

[PATCH 3/4] arch, x86, tsc: inform TSC deadline clockevent device about recalibration

[Nicolai Stange]

The TSC deadline clockevent devices' configuration and registration
happens before the TSC frequency calibration is refined in
tsc_refine_calibration_work().

This results in the TSC clocksource and the TSC deadline clockevent
devices being configured with slightly different frequencies: the former
gets the refined one and the latter are configured with the inaccurate
frequency detected earlier by means of the
"Fast TSC calibration using PIT".

Within the APIC code, introduce the notifier function
lapic_update_tsc_freq() which reconfigures all per-CPU TSC deadline
clockevent devices with the current tsc_khz.

Call it from the TSC code after TSC calibration refinement has happened.

Signed-off-by: Nicolai Stange 
---
 arch/x86/include/asm/apic.h |  1 +
 arch/x86/kernel/apic/apic.c | 24 
 arch/x86/kernel/tsc.c   |  4 
 3 files changed, 29 insertions(+)

diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index bc27611..971f446 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -135,6 +135,7 @@ extern void init_apic_mappings(void);
 void register_lapic_address(unsigned long address);
 extern void setup_boot_APIC_clock(void);
 extern void setup_secondary_APIC_clock(void);
+extern void lapic_update_tsc_freq(void);
 extern int APIC_init_uniprocessor(void);
 
 #ifdef CONFIG_X86_64
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 1d22c72..85238a8 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -571,6 +571,30 @@ static void setup_APIC_timer(void)
 }
 
 /*
+ * Install the updated TSC frequency from recalibration at the TSC
+ * deadline clockevent devices.
+ */
+static void __lapic_update_tsc_freq(void *info)
+{
+   struct clock_event_device *levt = this_cpu_ptr(_events);
+
+   if (!this_cpu_has(X86_FEATURE_TSC_DEADLINE_TIMER))
+   return;
+
+   clockevents_config(levt, (u32)(((u64)tsc_khz * 1000) / TSC_DIVISOR));
+}
+
+void lapic_update_tsc_freq(void)
+{
+   /*
+* The clockevent device's ->mult and ->shift can both be
+* changed. In order to avoid races, schedule the frequency
+* update code on each CPU.
+*/
+   on_each_cpu(__lapic_update_tsc_freq, NULL, 0);
+}
+
+/*
  * In this functions we calibrate APIC bus clocks to the external timer.
  *
  * We want to do the calibration only once since we want to have local timer
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 38ba6de..6ae5126 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 unsigned int __read_mostly cpu_khz;/* TSC clocks / usec, not used here */
 EXPORT_SYMBOL(cpu_khz);
@@ -1193,6 +1194,9 @@ static void tsc_refine_calibration_work(struct 
work_struct *work)
(unsigned long)tsc_khz / 1000,
(unsigned long)tsc_khz % 1000);
 
+   /* Inform the TSC deadline clockevent devices about the recalibration */
+   lapic_update_tsc_freq();
+
 out:
if (boot_cpu_has(X86_FEATURE_ART))
art_related_clocksource = _tsc;
-- 
2.9.0

[PATCH 4/4] kernel/time/clockevents: compensate for monotonic clock's dynamic frequency

[Nicolai Stange]

With NOHZ_FULL and one single well-isolated, CPU consumptive task, one
would expect approximately one clockevent interrupt per second. However, on
my Intel Haswell where the monotonic clock is the TSC monotonic clock and
the clockevent device is the TSC deadline device, it turns out that every
second, there are two such interrupts: the first one arrives always
approximately ~50us before the scheduled deadline as programmed by
tick_nohz_stop_sched_tick() through the hrtimer API. The
__hrtimer_run_queues() called in this interrupt detects that the queued
tick_sched_timer hasn't expired yet and simply does nothing except
reprogramming the clock event device to fire shortly after again.

These too early programmed deadlines are explained as follows:
clockevents_program_event() programs the clockevent device to fire
after
  f_event * delta_t_progr
clockevent device cycles where f_event is the clockevent device's hardware
frequency and delta_t_progr is the requested time interval. After that many
clockevent device cycles have elapsed, the device underlying the monotonic
clock, that is the monotonic raw clock has seen f_raw / f_event as many
cycles.
The ktime_get() called from __hrtimer_run_queues() interprets those
cycles to run at the frequency of the monotonic clock. Summarizing:
  delta_t_perc = 1/f_mono * f_raw/f_event * f_event * delta_t_progr
   = f_raw / f_mono * delta_t_progr
with f_mono being the monotonic clock's frequency and delta_t_perc being
the elapsed time interval as perceived by __hrtimer_run_queues().

Now, f_mono is not a constant, but is dynamically adjusted in
timekeeping_adjust() in order to compensate for the NTP error. With the
large values of delta_t_progr of 10^9ns with NOHZ_FULL, the error made
becomes significant and results in the double timer interrupts described
above.

Compensate for this error by multiplying delta_t_progr with f_mono / f_raw
in clockevents_program_event() before actually programming the clockevent
device.

Namely, introduce a helper, timekeeping_mono_interval_to_raw(), which
converts a given time interval from the monotonic clock's perception to
that of the raw monotonic clock by multiplying the value by f_mono / f_raw.
Call that helper from clockevents_program_event() in order to obtain a
suitable time interval to program the clockevent device with.

Signed-off-by: Nicolai Stange 
---
 kernel/time/clockevents.c |  1 +
 kernel/time/timekeeping.c | 50 +++
 kernel/time/timekeeping.h |  1 +
 3 files changed, 52 insertions(+)

diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
index a9b76a4..4bccf04 100644
--- a/kernel/time/clockevents.c
+++ b/kernel/time/clockevents.c
@@ -329,6 +329,7 @@ int clockevents_program_event(struct clock_event_device 
*dev, ktime_t expires,
return dev->set_next_ktime(expires, dev);
 
delta = ktime_to_ns(ktime_sub(expires, ktime_get()));
+   delta = timekeeping_mono_interval_to_raw(delta);
if (delta <= 0)
return force ? clockevents_program_min_delta(dev) : -ETIME;
 
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index dcd5ce6..b1e7a41 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -2133,6 +2133,56 @@ out:
 }
 
 /**
+ * timekeeper_mono_interval_to_raw - Convert mono interval to raw's perception.
+ * @interval: Time interval as measured by the mono clock.
+ *
+ * Converts the given time interval as measured by the monotonic clock to
+ * what would have been measured by the raw monotonic clock in the meanwhile.
+ * The monotonic clock's frequency gets dynamically adjusted every now and then
+ * in order to compensate for the differences to NTP. OTOH, the clockevents
+ * devices are not affected by this adjustment, i.e. they keep ticking at some
+ * fixed hardware frequency which may be assumed to have a constant ratio to
+ * the fixed raw monotonic clock's frequency. This function provides a means
+ * to convert time intervals from the dynamic frequency monotonic clock to
+ * the fixed frequency hardware world.
+ *
+ * The returned value is clamped to [0, KTIME_MAX]. In particular,
+ * KTIME_MAX is returned on overflow and zero for negative values of interval.
+ */
+s64 timekeeping_mono_interval_to_raw(s64 interval)
+{
+   struct timekeeper *tk = _core.timekeeper;
+   u32 raw_mult = tk->tkr_raw.mult, mono_mult = tk->tkr_mono.mult;
+   s64 raw;
+
+   /* The overflow checks below can't deal with negative intervals. */
+   if (interval <= 0)
+   return interval;
+
+   /*
+* Calculate
+*   raw = f_mono / f_raw * interval
+*   = (raw_mult / 2^raw_shift) / (mono_mult / 2^mono_shift)
+** interval
+* where f_mono and f_raw denote the frequencies of the monotonic
+* and raw clock respectively.
+*
+* Note that the monotonic and raw clock shifts' are 

[PATCH 1/4] arch, x86, tsc deadline clockevent dev: reduce frequency roundoff error

[Nicolai Stange]

In setup_APIC_timer(), the registered clockevent device's frequency
is calculated by first dividing tsc_khz by TSC_DIVISOR and multiplying
it with 1000 afterwards.

The multiplication with 1000 is done for converting from kHz to Hz and the
division by TSC_DIVISOR is carried out in order to make sure that the final
result fits into an u32.

However, with the order given in this calculation, the roundoff error
introduced by the division gets magnified by a factor of 1000 by the
following multiplication.

Increase the accuracy by reversing the order of the division and
multiplication. In order not to overflow during this calculation, cast
temporarily to u64.

Signed-off-by: Nicolai Stange 
---
 arch/x86/kernel/apic/apic.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 89a5bce..dce654c 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -563,7 +563,8 @@ static void setup_APIC_timer(void)
CLOCK_EVT_FEAT_DUMMY);
levt->set_next_event = lapic_next_deadline;
clockevents_config_and_register(levt,
-   (tsc_khz / TSC_DIVISOR) * 1000,
+   (u32)(((u64)tsc_khz * 1000) /
+   TSC_DIVISOR),
0xF, ~0UL);
} else
clockevents_register_device(levt);
-- 
2.9.0

[PATCH 0/4] avoid double timer interrupt with nohz and Intel TSC

[Nicolai Stange]

With a single task running on a NOHZ CPU on an Intel Haswell, I recognized
that I did not only get the one expected local_timer APIC interrupt, but
two per second at minimum.

Further tracing showed that the first one preceedes the programmed deadline
by up to ~50us and hence, it did nothing except for reprogramming the TSC
deadline clockevent device to trigger shortly thereafter again.

FYI, the trace looks like this:

  <...>-2938  [007] d.h.   420.753164: local_timer_entry: vector=239
  <...>-2938  [007] d.h.   420.753164: __hrtimer_run_queues <-hrtimer_interrupt
  <...>-2938  [007] d.h.   420.753184: local_timer_entry: vector=239
  <...>-2938  [007] d.h.   420.753184: __hrtimer_run_queues <-hrtimer_interrupt
  <...>-2938  [007] d.h.   420.753195: tick_sched_timer <-__hrtimer_run_queues
  <...>-2938  [007] d.h.   421.752170: local_timer_entry: vector=239
  <...>-2938  [007] d.h.   421.752171: __hrtimer_run_queues <-hrtimer_interrupt
  <...>-2938  [007] d.h.   421.752202: local_timer_entry: vector=239
  <...>-2938  [007] d.h.   421.752202: __hrtimer_run_queues <-hrtimer_interrupt
  <...>-2938  [007] d.h.   421.752202: tick_sched_timer <-__hrtimer_run_queues

It turns out that this too early programmed TSC deadline is caused by
inaccuracies in some frequency calculations which become significant if
the timer periods become large as it is the case for nohz with one task
(delta = 10^9ns).

The first three patches address inaccuracies entering the TSC deadline
clockevent devices' frequency.

The fourth patch is the most important one as it addresses the error
of largest relative magnitude. It is caused by the assumption in the
clockevents core that the ratio of the monotonic clock's frequency to that
of the clockevent device's is a constant. Since the monotonic clock's
frequency gets dynamically adjusted in order to compensate for NTP errors,
this is not true.

With this patchset applied, the trace looks like this:

  <...>-23609 [007] d.h.  1811.586658: local_timer_entry: vector=239
  <...>-23609 [007] d.h.  1811.586680: __hrtimer_run_queues <-hrtimer_interrupt
  <...>-23609 [007] d.h.  1811.586680: tick_sched_timer <-__hrtimer_run_queues
  <...>-23609 [007] d.h.  1812.585659: local_timer_entry: vector=239
  <...>-23609 [007] d.h.  1812.585666: __hrtimer_run_queues <-hrtimer_interrupt
  <...>-23609 [007] d.h.  1812.585666: tick_sched_timer <-__hrtimer_run_queues
  <...>-23609 [007] d.h.  1813.584661: local_timer_entry: vector=239
  <...>-23609 [007] d.h.  1813.584668: __hrtimer_run_queues <-hrtimer_interrupt
  <...>-23609 [007] d.h.  1813.584668: tick_sched_timer <-__hrtimer_run_queues

Please note that the first three TSC-patches might not be necessary to
get this result. In fact, [3/4] ("arch, x86, tsc: inform TSC deadline
clockevent device about") is somewhat counterproductive in the sense that
on my system, it usually corrects the TSC deadline device's frequency
towards lower values and thus, facilitates the too-early interrupt
behaviour initially described. However, I decided to send them along with
the fourth patch because
 - I tested the fourth patch in this setting
 - I believe that a greater accurracy of the TSC deadline device is
   worthwhile on its own

Applicable to linux-next-20160708. The individual patches don't depend on
each other.

Nicolai Stange (4):
  arch, x86, tsc deadline clockevent dev: reduce frequency roundoff
error
  arch, x86, tsc deadline clockevent dev: reduce TSC_DIVISOR to 2
  arch, x86, tsc: inform TSC deadline clockevent device about
recalibration
  kernel/time/clockevents: compensate for monotonic clock's dynamic
frequency

 arch/x86/include/asm/apic.h |  1 +
 arch/x86/kernel/apic/apic.c | 29 --
 arch/x86/kernel/tsc.c   |  4 
 kernel/time/clockevents.c   |  1 +
 kernel/time/timekeeping.c   | 50 +
 kernel/time/timekeeping.h   |  1 +
 6 files changed, 84 insertions(+), 2 deletions(-)

-- 
2.9.0

Re: [PATCH v4 2/5]nbd: fix might_sleep warning on socket shutdown

[Markus Pargmann]

Hi,

On 2016 M06 30, Thu 14:02:02 CEST Pranay Kr. Srivastava wrote:
> spinlocked ranges should be small and not contain calls into huge
> subfunctions. Fix my mistake and just get the pointer to the socket
> instead of doing everything with spinlock held.
> 
> Reported-by: Mikulas Patocka 
> Signed-off-by: Markus Pargmann 
> 
> Changelog:
> Pranay Kr. Srivastava:
> 
> 1) Use spin_lock instead of irq version for sock_shutdown.
> 
> 2) Use system work queue to actually trigger the shutdown of
> socket. This solves the issue when kernel_sendmsg is currently
> blocked while a timeout occurs.
> 
> Signed-off-by: Pranay Kr. Srivastava 
> ---
>  drivers/block/nbd.c | 57
> + 1 file changed, 36
> insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
> index 766c401..e362d44 100644
> --- a/drivers/block/nbd.c
> +++ b/drivers/block/nbd.c
> @@ -39,6 +39,7 @@
>  #include 
> 
>  #include 
> +#include 
> 
>  struct nbd_device {
>   u32 flags;
> @@ -69,6 +70,8 @@ struct nbd_device {
>  #if IS_ENABLED(CONFIG_DEBUG_FS)
>   struct dentry *dbg_dir;
>  #endif
> + /* This is specifically for calling sock_shutdown, for now. */
> + struct work_struct ws_shutdown;
>  };
> 
>  #if IS_ENABLED(CONFIG_DEBUG_FS)
> @@ -95,6 +98,8 @@ static int max_part;
>   */
>  static DEFINE_SPINLOCK(nbd_lock);
> 
> +static void nbd_ws_func_shutdown(struct work_struct *);
> +

are you reading all the comments I had?...

At least respond to my comments if you disagree. I still can't see the benefit
of a function signature here if we can avoid it.

>  static inline struct device *nbd_to_dev(struct nbd_device *nbd)
>  {
>   return disk_to_dev(nbd->disk);
> @@ -172,39 +177,36 @@ static void nbd_end_request(struct nbd_device *nbd,
> struct request *req) */
>  static void sock_shutdown(struct nbd_device *nbd)
>  {
> - spin_lock_irq(>sock_lock);
> -
> - if (!nbd->sock) {
> - spin_unlock_irq(>sock_lock);
> - return;
> - }
> + struct socket *sock;
> 
> - dev_warn(disk_to_dev(nbd->disk), "shutting down socket\n");
> - kernel_sock_shutdown(nbd->sock, SHUT_RDWR);
> - sockfd_put(nbd->sock);
> + spin_lock(>sock_lock);
> + sock = nbd->sock;
>   nbd->sock = NULL;
> - spin_unlock_irq(>sock_lock);
> + spin_unlock(>sock_lock);
> +
> + if (!sock)
> + return;
> 
>   del_timer(>timeout_timer);
> + dev_warn(disk_to_dev(nbd->disk), "shutting down socket\n");
> + kernel_sock_shutdown(sock, SHUT_RDWR);
> + sockfd_put(sock);
>  }
> 
>  static void nbd_xmit_timeout(unsigned long arg)
>  {
>   struct nbd_device *nbd = (struct nbd_device *)arg;
> - unsigned long flags;
> 
>   if (list_empty(>queue_head))
>   return;
> 
> - spin_lock_irqsave(>sock_lock, flags);
> -
>   nbd->timedout = true;
> -
> - if (nbd->sock)
> - kernel_sock_shutdown(nbd->sock, SHUT_RDWR);
> -
> - spin_unlock_irqrestore(>sock_lock, flags);
> -
> + /*
> +  * Make sure sender thread sees nbd->timedout.
> +  */
> + smp_wmb();
> + schedule_work(>ws_shutdown);
> + wake_up(>waiting_wq);
>   dev_err(nbd_to_dev(nbd), "Connection timed out, shutting down
> connection\n"); }
> 
> @@ -588,7 +590,11 @@ static int nbd_thread_send(void *data)
>   spin_unlock_irq(>queue_lock);
> 
>   /* handle request */
> - nbd_handle_req(nbd, req);
> + if (nbd->timedout) {
> + req->errors++;
> + nbd_end_request(nbd, req);
> + } else
> + nbd_handle_req(nbd, req);

I already commented on this in the last patch. This is unrelated to the patch.
If you disagree then please tell me why instead of sending the same thing
again.

Also brackets on the else part would be preferred.

Regards,

Markus

>   }
> 
>   nbd->task_send = NULL;
> @@ -663,6 +669,7 @@ static void nbd_reset(struct nbd_device *nbd)
>   set_capacity(nbd->disk, 0);
>   nbd->flags = 0;
>   nbd->xmit_timeout = 0;
> + INIT_WORK(>ws_shutdown, nbd_ws_func_shutdown);
>   queue_flag_clear_unlocked(QUEUE_FLAG_DISCARD, nbd->disk->queue);
>   del_timer_sync(>timeout_timer);
>  }
> @@ -797,11 +804,11 @@ static int __nbd_ioctl(struct block_device *bdev,
> struct nbd_device *nbd, error = nbd_thread_recv(nbd, bdev);
>   nbd_dev_dbg_close(nbd);
>   kthread_stop(thread);
> + sock_shutdown(nbd);
> 
>   mutex_lock(>tx_lock);
>   nbd->task_recv = NULL;
> 
> - sock_shutdown(nbd);
>   nbd_clear_que(nbd);
>   kill_bdev(bdev);
>   nbd_bdev_reset(bdev);
> @@ -857,6 +864,14 @@ static const struct block_device_operations nbd_fops =
> { .compat_ioctl = nbd_ioctl,
>  };
> 
> +static 

[PATCH 2/4] arch, x86, tsc deadline clockevent dev: reduce TSC_DIVISOR to 2

[Nicolai Stange]

In order to avoid overflowing an u32, the TSC deadline clockevent device's
frequency is divided by TSC_DIVISOR at registration.

The TSC_DIVISOR is currently defined as equaling 32 which allows for a
TSC frequency as high as 2^32 / 10^9ns * 32 = 137 GHz.

OTOH, larger values of TSC_DIVISOR introduce bigger roundoff errors into
the device's frequency.

A value of 2 for TSC_DIVISOR allows for a TSC frequency of
2^32 / 10^9ns * 2 = 8.5 GHz which is still way larger than anything to
expect in the next years.

Reduce the TSC deadline clockevent device's TSC_DIVISOR from 32 down to 2.

Signed-off-by: Nicolai Stange 
---
 arch/x86/kernel/apic/apic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index dce654c..1d22c72 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -311,7 +311,7 @@ int lapic_get_maxlvt(void)
 
 /* Clock divisor */
 #define APIC_DIVISOR 16
-#define TSC_DIVISOR  32
+#define TSC_DIVISOR  2
 
 /*
  * This function sets up the local APIC timer, with a timeout of
-- 
2.9.0

Re: [tip:x86/debug] printk: Make the printk*once() variants return a value

[Joe Perches]

On Sun, 2016-07-10 at 14:06 +0200, Borislav Petkov wrote:
> On Sun, Jul 10, 2016 at 01:23:51AM -0700, Joe Perches wrote:
> > 
> > Assuming tip is included in linux-next as of july 8, yes.
> Try one which has http://git.kernel.org/tip/81c2949f7fdcf8ff681326669a
> fde24962232670

That commit isn't in -next and this change to add a return
value to no_printk in _this_ patch is, as I wrote, not
required here.

It's fine that no_printk return a 0 value, but it should
be introduced in a separate patch that introduces that
requirement or at least mentioned in the changelog of
this patch _why_ it's it to be changed.  Otherwise, the
change just appears spurious.

Re: [PATCH 0/9] mm: Hardened usercopy

[Andy Lutomirski]

On Sun, Jul 10, 2016 at 5:03 AM, PaX Team  wrote:
> On 10 Jul 2016 at 11:16, Ingo Molnar wrote:
>
>> * PaX Team  wrote:
>>
>> > On 9 Jul 2016 at 14:27, Andy Lutomirski wrote:
>> >
>> > > I like the series, but I have one minor nit to pick.  The effect of this
>> > > series is to harden usercopy, but most of the code is really about
>> > > infrastructure to validate that a pointed-to object is valid.
>> >
>> > actually USERCOPY has never been about validating pointers. its sole 
>> > purpose is
>> > to validate the *size* argument of copy*user calls, a very specific form of
>> > runtime bounds checking.
>>
>> What this code has been about originally is largely immaterial, unless you 
>> can
>> formulate it into a technical argument.
>
> we design defense mechanisms for specific and clear purposes, starting with
> a threat model, evaluating defense options based on various criteria, etc.
> USERCOPY underwent this same process and taking it out of its original context
> means that all you get in the end is cargo cult security (wouldn't be the 
> first
> time it has happened (ExecShield, ASLR, etc)).
>
> that said, i actually started that discussion but for some reason you chose
> not to respond to that one part of my mail so let me ask it again:
>
>   what kind of checks are you thinking of here? and more fundamentally, 
> against
>   what kind of threats?
>
> as far as i'm concerned, a defense mechanism is only as good as its underlying
> threat model. by validating pointers (for yet to be stated security related
> properties) you're presumably assuming some kind of threat and unless stated
> clearly what that threat is (unintended pointer modification through memory
> corruption and/or other bugs?) noone can tell whether the proposed defense
> mechanism will actually be effective in preventing exploitation. it is the
> worst kind of defense that doesn't actually achieve its stated goals, that
> way lies false sense of security and i hope noone here is in that business.

I'm imaging security bugs that involve buffer length corruption but
that don't call copy_to/from_user.  Hardened usercopy shuts
expoitation down if the first use of the corrupt size is
copy_to/from_user or similar.  I bet that a bit better coverage could
be achieved by instrumenting more functions.

To be clear: I'm not objecting to calling the overall feature hardened
usercopy or similar.  I object to
CONFIG_HAVE_HARDENED_USERCOPY_ALLOCATOR.  That feature is *used* for
hardened usercopy but is not, in and of itself, a usercopy thing.
It's an object / memory range validation thing.  So we'll feel silly
down the road if we use it for something else and the config option
name has nothing to do with the feature.

>> > [...] like the renaming of .data..read_only to .data..ro_after_init which 
>> > also
>> > had nothing to do with init but everything to do with objects being 
>> > conceptually
>> > read-only...
>>
>> .data..ro_after_init objects get written to during bootup so it's 
>> conceptually
>> quite confusing to name it "read-only" without any clear qualifiers.
>>
>> That it's named consistently with its role of "read-write before init and 
>> read
>> only after init" on the other hand is not confusing at all. Not sure what 
>> your
>> problem is with the new name.
>
> the new name reflects a complete misunderstanding of the PaX feature it was 
> based
> on (typical case of cargo cult security). in particular, the __read_only 
> facility
> in PaX is part of a defense mechanism that attempts to solve a specific 
> problem
> (like everything else) and that problem has nothing whatsoever to do with what
> happens before/after the kernel init process. enforcing read-ony kernel 
> memory at
> the end of kernel initialization is an implementation detail only and wasn't 
> even
> true always (and still isn't true for kernel modules for example): in the 
> linux 2.4
> days PaX actually enforced read-only kernel memory properties in startup_32 
> already
> but i relaxed that for the 2.6+ port as the maintenance cost (finding out and
> handling new exceptional cases) wasn't worth it.
>
> also naming things after their implementation is poor taste and can result in
> even bigger problems down the line since as soon as the implementation 
> changes,
> you will have a flag day or have to keep a bad name. this is a lesson that the
> REFCOUNT submission will learn too since the kernel's atomic*_t types (an
> implementation detail) are used extensively for different purposes, instead of
> using specialized types (kref is a good example of that). for 
> .data..ro_after_init
> the lesson will happen when you try to add back the remaining pieces from PaX,
> such as module handling and not-always-const-in-the-C-sense objects and 
> associated
> accessors.

The name is related to how the thing works.  If I understand
correctly, in PaX, the idea is to make some things readonly and use
pax_open_kernel(), etc to write 

Re: [PATCHv2 3/6] x86/arch_prctl/vdso: add ARCH_MAP_VDSO_*

[Andy Lutomirski]

On Thu, Jul 7, 2016 at 4:11 AM, Dmitry Safonov  wrote:
> On 07/06/2016 05:30 PM, Andy Lutomirski wrote:
>>
>> On Wed, Jun 29, 2016 at 3:57 AM, Dmitry Safonov 
>> wrote:
>>>
>>> Add API to change vdso blob type with arch_prctl.
>>> As this is usefull only by needs of CRIU, expose
>>> this interface under CONFIG_CHECKPOINT_RESTORE.
>>
>>
>>> +#ifdef CONFIG_CHECKPOINT_RESTORE
>>> +   case ARCH_MAP_VDSO_X32:
>>> +   return do_map_vdso(VDSO_X32, addr, false);
>>> +   case ARCH_MAP_VDSO_32:
>>> +   return do_map_vdso(VDSO_32, addr, false);
>>> +   case ARCH_MAP_VDSO_64:
>>> +   return do_map_vdso(VDSO_64, addr, false);
>>> +#endif
>>> +
>>
>>
>> This will have an odd side effect: if the old mapping is still around,
>> its .fault will start behaving erratically.  I wonder if we can either
>> reliably zap the old vma (or check that it's not there any more)
>> before mapping a new one or whether we can associate the vdso image
>> with the vma (possibly by having a separate vm_special_mapping for
>> each vdso_image.  The latter is quite easy: change vdso_image to embed
>> vm_special_mapping and use container_of in vdso_fault to fish the
>> vdso_image back out.  But we'd have to embed another
>> vm_special_mapping for the vvar mapping as well for the same reason.
>>
>> I'm also a bit concerned that __install_special_mapping might not get
>> all the cgroup and rlimit stuff right.  If we ensure that any old
>> mappings are gone, then the damage is bounded, but otherwise someone
>> might call this in a loop and fill their address space with arbitrary
>> numbers of special mappings.
>
>
> Well, I have deleted code that unmaps old vdso because I didn't saw
> a reason why it's bad and wanted to reduce code. But well, now I do see
> reasons, thanks.
>
> Hmm, what do you think if I do it a little different way then embedding
> vm_special_mapping: just that old hack with vma_ops. If I add a close()
> hook there and make there context.vdso = NULL pointer, then I can test
> it on remap. This can also have nice feature as restricting partial
> munmap of vdso blob. Is this sounds sane?

I think so, as long as you do something to make sure that vvar gets
unmapped as well.

Oleg, want to sanity-check us?  Do you believe that if .mremap ensures
that only entire vma can be remapped and .close ensures that only the
whole vma can be unmapped, are we okay?  Or will we have issues with
mprotect?


-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH 3/4] arch, x86, tsc: inform TSC deadline clockevent device about recalibration

[kbuild test robot]

Hi,

[auto build test ERROR on tip/timers/core]
[also build test ERROR on v4.7-rc6 next-20160708]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Nicolai-Stange/avoid-double-timer-interrupt-with-nohz-and-Intel-TSC/20160710-202914
config: i386-tinyconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   arch/x86/kernel/tsc.c: In function 'tsc_refine_calibration_work':
>> arch/x86/kernel/tsc.c:1198:2: error: implicit declaration of function 
>> 'lapic_update_tsc_freq' [-Werror=implicit-function-declaration]
 lapic_update_tsc_freq();
 ^
   cc1: some warnings being treated as errors

vim +/lapic_update_tsc_freq +1198 arch/x86/kernel/tsc.c

  1192  tsc_khz = freq;
  1193  pr_info("Refined TSC clocksource calibration: %lu.%03lu MHz\n",
  1194  (unsigned long)tsc_khz / 1000,
  1195  (unsigned long)tsc_khz % 1000);
  1196  
  1197  /* Inform the TSC deadline clockevent devices about the 
recalibration */
> 1198  lapic_update_tsc_freq();
  1199  
  1200  out:
  1201  if (boot_cpu_has(X86_FEATURE_ART))

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


.config.gz
Description: Binary data

KASAN vs vmapped stacks

[Andy Lutomirski]

Hi all-

I found two nasty issues with virtually mapped stacks if KASAN is
enabled.  The first issue is a crash: the first non-init stack is
allocated and accessed before KASAN initializes its zero shadow
AFAICT, which means that we switch to that stack and then blow up when
we start recursively faulting on failed accesses to the shadow.

The second issue is that, even if we survive (we initialize the zero
shadow on time), KASAN will fail to protect hte stack.

For now, I just disabled use of virtually mapped stacks if KASAN is
on.  Do you have any easy ideas to fix it?

Thanks,
Andy

Re: [PATCH v4 3/5]nbd: make nbd device wait for its users

[Markus Pargmann]

On 2016 M06 30, Thu 14:02:03 CEST Pranay Kr. Srivastava wrote:
> When a timeout occurs or a recv fails, then
> instead of abruplty killing nbd block device
> wait for its users to finish.
> 
> This is more required when filesystem(s) like
> ext2 or ext3 don't expect their buffer heads to
> disappear while the filesystem is mounted.
> 
> Each open of a nbd device is refcounted, while
> the userland program [nbd-client] doing the
> NBD_DO_IT ioctl would now wait for any other users
> of this device before invalidating the nbd device.
> 
> A timedout or a disconnected device, if in use, can't
> be used until it has been resetted. The reset happens
> when all tasks having this bdev open closes this bdev.
> 
> Signed-off-by: Pranay Kr. Srivastava 
> ---
>  drivers/block/nbd.c | 106
> ++-- 1 file changed, 87
> insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
> index e362d44..fb56dd2 100644
> --- a/drivers/block/nbd.c
> +++ b/drivers/block/nbd.c
> @@ -72,6 +72,8 @@ struct nbd_device {
>  #endif
>   /* This is specifically for calling sock_shutdown, for now. */
>   struct work_struct ws_shutdown;
> + struct kref users;
> + struct completion user_completion;
>  };
> 
>  #if IS_ENABLED(CONFIG_DEBUG_FS)
> @@ -99,6 +101,8 @@ static int max_part;
>  static DEFINE_SPINLOCK(nbd_lock);
> 
>  static void nbd_ws_func_shutdown(struct work_struct *);
> +static void nbd_kref_release(struct kref *);
> +static int nbd_size_clear(struct nbd_device *, struct block_device *);

More function signatures. Why?

> 
>  static inline struct device *nbd_to_dev(struct nbd_device *nbd)
>  {
> @@ -145,11 +149,9 @@ static int nbd_size_set(struct nbd_device *nbd, struct
> block_device *bdev, int blocksize, int nr_blocks)
>  {
>   int ret;
> -
>   ret = set_blocksize(bdev, blocksize);
>   if (ret)
>   return ret;
> -

Unrelated.

>   nbd->blksize = blocksize;
>   nbd->bytesize = (loff_t)blocksize * (loff_t)nr_blocks;
> 
> @@ -197,6 +199,9 @@ static void nbd_xmit_timeout(unsigned long arg)
>  {
>   struct nbd_device *nbd = (struct nbd_device *)arg;
> 
> + if (nbd->timedout)
> + return;
> +

What does this have to do with the patch?

>   if (list_empty(>queue_head))
>   return;
> 
> @@ -472,8 +477,6 @@ static int nbd_thread_recv(struct nbd_device *nbd,
> struct block_device *bdev) nbd_end_request(nbd, req);
>   }
> 
> - nbd_size_clear(nbd, bdev);
> -
>   device_remove_file(disk_to_dev(nbd->disk), _attr_pid);
> 
>   nbd->task_recv = NULL;
> @@ -650,12 +653,13 @@ static int nbd_set_socket(struct nbd_device *nbd,
> struct socket *sock) int ret = 0;
> 
>   spin_lock(>sock_lock);
> - if (nbd->sock)
> +
> + if (nbd->sock || nbd->timedout)
>   ret = -EBUSY;

nbd->timedout is already checked in __nbd_ioctl(), no need to check it twice.

>   else
>   nbd->sock = sock;
> - spin_unlock(>sock_lock);
> 
> + spin_unlock(>sock_lock);

random modification.

>   return ret;
>  }
> 
> @@ -670,6 +674,7 @@ static void nbd_reset(struct nbd_device *nbd)
>   nbd->flags = 0;
>   nbd->xmit_timeout = 0;
>   INIT_WORK(>ws_shutdown, nbd_ws_func_shutdown);
> + init_completion(>user_completion);
>   queue_flag_clear_unlocked(QUEUE_FLAG_DISCARD, nbd->disk->queue);
>   del_timer_sync(>timeout_timer);
>  }
> @@ -704,6 +709,9 @@ static void nbd_dev_dbg_close(struct nbd_device *nbd);
>  static int __nbd_ioctl(struct block_device *bdev, struct nbd_device *nbd,
>  unsigned int cmd, unsigned long arg)
>  {
> + if (nbd->timedout || nbd->disconnect)
> + return -EBUSY;
> +
>   switch (cmd) {
>   case NBD_DISCONNECT: {
>   struct request sreq;
> @@ -733,7 +741,6 @@ static int __nbd_ioctl(struct block_device *bdev, struct
> nbd_device *nbd, nbd_clear_que(nbd);
>   BUG_ON(!list_empty(>queue_head));
>   BUG_ON(!list_empty(>waiting_queue));
> - kill_bdev(bdev);
>   return 0;
> 
>   case NBD_SET_SOCK: {
> @@ -752,7 +759,6 @@ static int __nbd_ioctl(struct block_device *bdev, struct
> nbd_device *nbd,
> 
>   case NBD_SET_BLKSIZE: {
>   loff_t bsize = div_s64(nbd->bytesize, arg);
> -

random modification.

>   return nbd_size_set(nbd, bdev, arg, bsize);
>   }
> 
> @@ -804,22 +810,29 @@ static int __nbd_ioctl(struct block_device *bdev,
> struct nbd_device *nbd, error = nbd_thread_recv(nbd, bdev);
>   nbd_dev_dbg_close(nbd);
>   kthread_stop(thread);
> - sock_shutdown(nbd);
> -
> - mutex_lock(>tx_lock);
> - nbd->task_recv = NULL;
> 
> - nbd_clear_que(nbd);
> - kill_bdev(bdev);
> - nbd_bdev_reset(bdev);
> + sock_shutdown(nbd);
> 
>   if (nbd->disconnect) /* user 

Re: How to set Current register in IIO driver from sysfs

[Pratik Prajapati]

Including more members.

On Sat, Jul 9, 2016 at 5:22 PM, Pratik Prajapati
 wrote:
> Hi,
>
> I am trying to add support of adjusting IR led current in vcnl4000
> driver (has IR led current register for doing the same).
>
> Below is what I have done till now:
>
> 1) Added Current channel in the vcnl4000_channels structure with
> separate mask IIO_CHAN_INFO_RAW
> 2) Reading the LED current register inside IIO_CURRENT case in 
> vcnl4010_read_raw
> 3) Writing to LED current register inside IIO_CURRENT case in 
> vcnl4010_write_raw
>
> Is this the correct way of setting Current register in IIO subsystem?
>
> Best Regards,
> Pratik Prajapati

Re: [PATCH 4/4] kernel/time/clockevents: compensate for monotonic clock's dynamic frequency

[kbuild test robot]

Hi,

[auto build test ERROR on tip/timers/core]
[also build test ERROR on v4.7-rc6 next-20160708]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Nicolai-Stange/avoid-double-timer-interrupt-with-nohz-and-Intel-TSC/20160710-202914
config: i386-randconfig-s1-201628 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   kernel/built-in.o: In function `timekeeping_mono_interval_to_raw':
>> (.text+0x66436): undefined reference to `__divdi3'
   kernel/built-in.o: In function `timekeeping_mono_interval_to_raw':
   (.text+0x6649c): undefined reference to `__divdi3'

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


.config.gz
Description: Binary data

Re: [PATCH] iio: temperature: mcp9808: add Microchip MCP9808 temperature sensor

[Jonathan Cameron]

On 03/07/16 22:04, Alison Schofield wrote:
> IIO driver, perhaps a reference driver, since this sensor is already
> supported in hwmon/jc42 driver.
> 
> Driver supports continuous conversion, resolution changes and
> suspend/resume power ops.
> 
> Signed-off-by: Alison Schofield 
> Cc: Daniel Baluta 
Hi Alison,

Thanks for posting this.  Given the work was done it's a useful exercise to put
it out for review.

Mostly very good little driver.  The complex corner is the multiple resolution
support.  My guess is that this is purely a bit of 'mystified' oversampling
on the chip and I'd suggest supporting it as such.

Jonathan
> ---
>  drivers/iio/temperature/Kconfig   |  10 ++
>  drivers/iio/temperature/Makefile  |   1 +
>  drivers/iio/temperature/mcp9808.c | 269 
> ++
>  3 files changed, 280 insertions(+)
>  create mode 100644 drivers/iio/temperature/mcp9808.c
> 
> diff --git a/drivers/iio/temperature/Kconfig b/drivers/iio/temperature/Kconfig
> index c4664e5..25915d2 100644
> --- a/drivers/iio/temperature/Kconfig
> +++ b/drivers/iio/temperature/Kconfig
> @@ -3,6 +3,16 @@
>  #
>  menu "Temperature sensors"
>  
> +config MCP9808
> + tristate "MCP9808 temperature sensor"
> + depends on I2C
> + help
> +   If you say yes here you get support for the Microchip
> +   MCP9808 temperature sensor connected with I2C.
> +
> +   This driver can also be built as a module. If so, the module will
> +   be called mcp9808.
> +
>  config MLX90614
>   tristate "MLX90614 contact-less infrared sensor"
>   depends on I2C
> diff --git a/drivers/iio/temperature/Makefile 
> b/drivers/iio/temperature/Makefile
> index 02bc79d..92cd1e6 100644
> --- a/drivers/iio/temperature/Makefile
> +++ b/drivers/iio/temperature/Makefile
> @@ -2,6 +2,7 @@
>  # Makefile for industrial I/O temperature drivers
>  #
>  
> +obj-$(CONFIG_MCP9808) += mcp9808.o
>  obj-$(CONFIG_MLX90614) += mlx90614.o
>  obj-$(CONFIG_TMP006) += tmp006.o
>  obj-$(CONFIG_TSYS01) += tsys01.o
> diff --git a/drivers/iio/temperature/mcp9808.c 
> b/drivers/iio/temperature/mcp9808.c
> new file mode 100644
> index 000..adab708
> --- /dev/null
> +++ b/drivers/iio/temperature/mcp9808.c
> @@ -0,0 +1,269 @@
> +/*
> + * mcp9808.c - Support for Microchip MCP9808 Digital Temperature Sensor
> + *
> + * Copyright (C) 2016 Alison Schofield 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * Datasheet: http://ww1.microchip.com/downloads/en/DeviceDoc/25095A.pdf
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#define MCP9808_REG_CONFIG   0x01
> +#define MCP9808_REG_TAMBIENT 0x05
> +#define MCP9808_REG_MANUF_ID 0x06
> +#define MCP9808_REG_DEVICE_ID0x07
> +#define MCP9808_REG_RESOLUTION   0x08
> +
> +#define MCP9808_CONFIG_DEFAULT   0x00
There's a lot of other stuff in this register.
I guess most of it is alert related and that isn't supported here though
so fair enough.  Can be introduced when it becomes relevant.

> +#define MCP9808_CONFIG_SHUTDOWN  0x0100
> +
> +#define MCP9808_RES_DEFAULT  62500
> +
> +#define MCP9808_MANUF_ID 0x54
> +#define MCP9808_DEVICE_ID0x0400
> +#define MCP9808_DEVICE_ID_MASK   0xff00
> +
> +struct mcp9808_data {
> + struct i2c_client *client;
> + struct mutex   lock;/* protect resolution changes  */
> + intres_index;   /* current resolution index*/
> +};
> +
> +/* Resolution, MCP9808_REG_RESOLUTION bits, Conversion Time ms  */
> +static const int mcp9808_res[][3] = {
> + {50, 0,  30},
> + {25, 1,  65},
> + {125000, 2, 130},
> + { 62500, 3, 250},
> +};
> +
> +static IIO_CONST_ATTR(temp_integration_time_available,
> + "0.5 0.25 0.125 0.0625");
> +
> +static struct attribute *mcp9808_attributes[] = {
> + _const_attr_temp_integration_time_available.dev_attr.attr,
> + NULL
> +};
> +
> +static struct attribute_group mcp9808_attribute_group = {
> + .attrs = mcp9808_attributes,
> +};
> +
> +static int mcp9808_set_resolution(struct mcp9808_data *data, int val2)
> +{
> + int i;
> + int ret = -EINVAL;
> + int conv_t = mcp9808_res[data->res_index][2];
> +
> + for (i = 0; i < ARRAY_SIZE(mcp9808_res); i++) {
> + if (val2 == mcp9808_res[i][0]) {
> + mutex_lock(>lock);
> + ret = i2c_smbus_write_byte_data(data->client,
> + MCP9808_REG_RESOLUTION,
> + mcp9808_res[i][1]);
> + data->res_index = i;
> + mutex_unlock(>lock);
> +
> +   

[PATCH v2 09/10] Documentation: devicetree: Add dts description for nuc900

[Wan Zongshun]

This patch is to add dts description for nuc900 platform.

Signed-off-by: Wan Zongshun 
---
 .../devicetree/bindings/arm/nuvoton/nuc970.txt | 12 
 .../bindings/clock/nuvoton,nuc970-clk.txt  | 13 +
 .../interrupt-controller/nuvoton,nuc900-aic.txt| 15 +++
 .../bindings/reset/nuvoton,nuc900-reset.txt| 12 
 .../devicetree/bindings/serial/nuc970-uart.txt | 22 ++
 .../bindings/soc/nuvoton/nuvoton,nuc900-soc.txt| 12 
 .../bindings/timer/nuvoton,nuc970-tmr.txt  | 20 
 7 files changed, 106 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/nuvoton/nuc970.txt
 create mode 100644 
Documentation/devicetree/bindings/clock/nuvoton,nuc970-clk.txt
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/nuvoton,nuc900-aic.txt
 create mode 100644 
Documentation/devicetree/bindings/reset/nuvoton,nuc900-reset.txt
 create mode 100644 Documentation/devicetree/bindings/serial/nuc970-uart.txt
 create mode 100644 
Documentation/devicetree/bindings/soc/nuvoton/nuvoton,nuc900-soc.txt
 create mode 100644 
Documentation/devicetree/bindings/timer/nuvoton,nuc970-tmr.txt

diff --git a/Documentation/devicetree/bindings/arm/nuvoton/nuc970.txt 
b/Documentation/devicetree/bindings/arm/nuvoton/nuc970.txt
new file mode 100644
index 000..0872f6f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/nuvoton/nuc970.txt
@@ -0,0 +1,12 @@
+Nuvoton NUC970 SoC platform Device Tree Bindings
+--
+
+Boards with the NUC970 SoC shall have the following properties:
+
+Root node required properties:
+- compatible: Should be "syscon" or "nuvoton,nuc970-gcr"
+
+GCR register required properties:
+- compatible: Should be "nuvoton,nuc970-gcr"
+- reg: Should contain registers location and length
+
diff --git a/Documentation/devicetree/bindings/clock/nuvoton,nuc970-clk.txt 
b/Documentation/devicetree/bindings/clock/nuvoton,nuc970-clk.txt
new file mode 100644
index 000..82fcf32
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nuvoton,nuc970-clk.txt
@@ -0,0 +1,13 @@
+NUC970 Clock Controller
+
+Clock required properties:
+- compatible: Should be "nuvoton,nuc970-clk"
+- reg: Should contain registers location and length
+
+Examples:
+
+clks: clk@b200 {
+   compatible = "nuvoton,nuc970-clk";
+   reg = <0xb200 0x200>;
+   #clock-cells = <1>;
+};
diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/nuvoton,nuc900-aic.txt 
b/Documentation/devicetree/bindings/interrupt-controller/nuvoton,nuc900-aic.txt
new file mode 100644
index 000..f265095
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/nuvoton,nuc900-aic.txt
@@ -0,0 +1,15 @@
+NUC900 interrupt Controller
+
+Interrupt-controller required properties
+- compatible: Should be "nuvoton,nuc900-aic"
+- reg: Should contain registers location and length
+- interrupt-cells: set to 1
+
+Examples:
+
+aic: interrupt-controller@b8002000 {
+   compatible = "nuvoton,nuc900-aic";
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   reg = <0xb8002000 0x1000>;
+};
diff --git a/Documentation/devicetree/bindings/reset/nuvoton,nuc900-reset.txt 
b/Documentation/devicetree/bindings/reset/nuvoton,nuc900-reset.txt
new file mode 100644
index 000..ab6056a
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/nuvoton,nuc900-reset.txt
@@ -0,0 +1,12 @@
+. Nuvoton NUC900 series, reset controller binding.
+
+Required properties:
+- compatible : Should be "nuvoton,nuc900-reset"
+- syscon : Reference to gcr controller.
+
+Example:
+
+reset {
+   compatible = "nuvoton,nuc900-reset";
+   syscon = <>;
+};
diff --git a/Documentation/devicetree/bindings/serial/nuc970-uart.txt 
b/Documentation/devicetree/bindings/serial/nuc970-uart.txt
new file mode 100644
index 000..a143a5e
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/nuc970-uart.txt
@@ -0,0 +1,22 @@
+NUC970 UART Controller
+
+Uart required properties:
+- compatible: Should be "nuvoton,nuc970-uart"
+- reg: Should contain registers location and length
+
+Examples:
+
+aliases {
+   serial0 = 
+};
+
+uart0: serial@b800 {
+   compatible = "nuvoton,nuc970-uart";
+   reg = <0xb800 0x1000>;
+   interrupts = <36>;
+   clocks = < UART0_GATE>,
+< UART0_ECLK_GATE>;
+   clock-names = "uart0", "uart0_eclk";
+   clock-frequency = <1200>;
+   status = "disabled";
+};
diff --git 
a/Documentation/devicetree/bindings/soc/nuvoton/nuvoton,nuc900-soc.txt 
b/Documentation/devicetree/bindings/soc/nuvoton/nuvoton,nuc900-soc.txt
new file mode 100644
index 000..0284edf
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/nuvoton/nuvoton,nuc900-soc.txt
@@ -0,0 +1,12 @@
+. Nuvoton NUC900 series, Soc specific driver binding.
+
+Required properties:
+- compatible : Should be 

[PATCH v2 08/10] ARM: dts: nuc900: Add nuc970 dts files

[Wan Zongshun]

This patch is to add dts support for nuc970 platform.

Signed-off-by: Wan Zongshun 
---
 arch/arm/boot/dts/Makefile   |  1 +
 arch/arm/boot/dts/nuc970-evb.dts | 34 
 arch/arm/boot/dts/nuc970.dtsi| 88 
 3 files changed, 123 insertions(+)
 create mode 100644 arch/arm/boot/dts/nuc970-evb.dts
 create mode 100644 arch/arm/boot/dts/nuc970.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 414b427..557477d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -892,6 +892,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
 dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb
 dtb-$(CONFIG_ARCH_ASPEED) += aspeed-bmc-opp-palmetto.dtb \
aspeed-ast2500-evb.dtb
+dtb-$(CONFIG_SOC_NUC970) += nuc970-evb.dtb
 endif
 
 dtstree:= $(srctree)/$(src)
diff --git a/arch/arm/boot/dts/nuc970-evb.dts b/arch/arm/boot/dts/nuc970-evb.dts
new file mode 100644
index 000..ae3fe90
--- /dev/null
+++ b/arch/arm/boot/dts/nuc970-evb.dts
@@ -0,0 +1,34 @@
+/*
+ * Copyright 2016 Wan Zongshun 
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+#include "nuc970.dtsi"
+
+/ {
+   model = "Nuvoton NUC970 Development Board";
+   compatible = "nuvoton,nuc970";
+
+   aliases {
+   serial0 = 
+   };
+
+   memory {
+   reg = <0x 0x0400>;
+   };
+
+   soc {
+   apb@b800 {
+   uart0: serial@b800 {
+   status = "okay";
+   };
+   };
+   };
+};
diff --git a/arch/arm/boot/dts/nuc970.dtsi b/arch/arm/boot/dts/nuc970.dtsi
new file mode 100644
index 000..d476abd
--- /dev/null
+++ b/arch/arm/boot/dts/nuc970.dtsi
@@ -0,0 +1,88 @@
+/*
+ * Copyright 2016 Wan Zongshun 
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include "skeleton.dtsi"
+#include 
+
+/ {
+   soc {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "simple-bus";
+   interrupt-parent = <>;
+   ranges;
+
+   ahb@b000 {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   gcr: syscon@b000 {
+   compatible = "syscon", "nuvoton,nuc970-gcr";
+   reg = <0xb000 0x200>;
+   };
+
+   soc {
+   compatible = "nuvoton,nuc900-soc";
+   syscon = <>;
+   };
+
+   reset {
+   compatible = "nuvoton,nuc900-reset";
+   syscon = <>;
+   };
+
+   clks: clk@b200 {
+   compatible = "nuvoton,nuc970-clk";
+   reg = <0xb200 0x200>;
+   #clock-cells = <1>;
+   };
+
+   };
+
+   apb@b800 {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   aic: interrupt-controller@b8002000 {
+   compatible = "nuvoton,nuc900-aic";
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   reg = <0xb8002000 0x1000>;
+   };
+
+
+   tmr@0xb8001000 {
+   compatible = "nuvoton,nuc970-tmr";
+   reg = <0xb8001000 0x1000>;
+   interrupts = <16>;
+   clocks = < TIMER0_GATE>,
+< TIMER1_GATE>;
+   clock-names = "timer0", "timer1";
+
+   };
+
+   uart0: serial@b800 {
+   compatible = "nuvoton,nuc970-uart";
+   reg = <0xb800 0x1000>;
+   interrupts = <36>;
+   clocks = < UART0_GATE>,
+   

[PATCH v2 10/10] nuc900: add nuc970 platform defconfig file

[Wan Zongshun]

Add nuc970_defconfig file support.

Signed-off-by: Wan Zongshun 
---
 arch/arm/configs/nuc970_defconfig | 76 +++
 1 file changed, 76 insertions(+)
 create mode 100644 arch/arm/configs/nuc970_defconfig

diff --git a/arch/arm/configs/nuc970_defconfig 
b/arch/arm/configs/nuc970_defconfig
new file mode 100644
index 000..b39a406
--- /dev/null
+++ b/arch/arm/configs/nuc970_defconfig
@@ -0,0 +1,76 @@
+# CONFIG_LOCALVERSION_AUTO is not set
+CONFIG_SYSVIPC=y
+# CONFIG_CROSS_MEMORY_ATTACH is not set
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_BSD_PROCESS_ACCT=y
+CONFIG_BSD_PROCESS_ACCT_V3=y
+CONFIG_CGROUPS=y
+CONFIG_CGROUP_SCHED=y
+CONFIG_RT_GROUP_SCHED=y
+CONFIG_CGROUP_FREEZER=y
+CONFIG_CPUSETS=y
+CONFIG_CGROUP_DEVICE=y
+CONFIG_CGROUP_CPUACCT=y
+CONFIG_CGROUP_PERF=y
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_INITRAMFS_SOURCE="../rootfs"
+CONFIG_PERF_EVENTS=y
+# CONFIG_COMPAT_BRK is not set
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_ARCH_W90X900=y
+CONFIG_SOC_NUC970=y
+# CONFIG_MACH_W90P910EVB is not set
+CONFIG_PREEMPT=y
+CONFIG_AEABI=y
+CONFIG_OABI_COMPAT=y
+CONFIG_ARM_APPENDED_DTB=y
+CONFIG_CMDLINE="root=/dev/ram0 console=ttyS0,115200n8 rdinit=/sbin/init 
mem=64M"
+CONFIG_KEXEC=y
+CONFIG_FPE_NWFPE=y
+# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
+# CONFIG_SUSPEND is not set
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_STANDALONE is not set
+# CONFIG_PREVENT_FIRMWARE_BUILD is not set
+# CONFIG_FIRMWARE_IN_KERNEL is not set
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_SIZE=16384
+CONFIG_SCSI=y
+# CONFIG_SCSI_PROC_FS is not set
+CONFIG_BLK_DEV_SD=y
+# CONFIG_SCSI_LOWLEVEL is not set
+# CONFIG_INPUT_MOUSEDEV is not set
+# CONFIG_INPUT_KEYBOARD is not set
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_SERIO is not set
+CONFIG_VT_HW_CONSOLE_BINDING=y
+# CONFIG_LEGACY_PTYS is not set
+CONFIG_SERIAL_NUC970=y
+CONFIG_SERIAL_NUC970_CONSOLE=y
+# CONFIG_HW_RANDOM is not set
+CONFIG_POWER_RESET=y
+CONFIG_POWER_RESET_NUC900=y
+# CONFIG_HWMON is not set
+# CONFIG_HID is not set
+# CONFIG_USB_SUPPORT is not set
+# CONFIG_IOMMU_SUPPORT is not set
+# CONFIG_DNOTIFY is not set
+# CONFIG_INOTIFY_USER is not set
+CONFIG_MSDOS_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_TMPFS=y
+CONFIG_TMPFS_POSIX_ACL=y
+CONFIG_ROMFS_FS=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_MESSAGE_LOGLEVEL_DEFAULT=7
+# CONFIG_ENABLE_WARN_DEPRECATED is not set
+# CONFIG_ENABLE_MUST_CHECK is not set
+CONFIG_DEBUG_FS=y
+CONFIG_RCU_CPU_STALL_TIMEOUT=300
+CONFIG_STRICT_DEVMEM=y
+# CONFIG_ARM_UNWIND is not set
-- 
2.7.4

Re: [tip:x86/debug] printk: Make the printk*once() variants return a value

[Joe Perches]

On Sun, 2016-07-10 at 08:49 +0200, Borislav Petkov wrote:
> On Sat, Jul 09, 2016 at 10:56:55AM -0700, Joe Perches wrote:
> > 
> > defconfigs both with and without CONFIG_PRINTK build
> > properly with the proposed change to this specific patch.
> Did you try latest tip/master?

Assuming tip is included in linux-next as of july 8, yes.

http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=a379b037c5f3bcd0475ab2743b1f8a57fa970e22
[]
+tip2c387f55aabaf88b6ee6857192a8f778bee05523

Re: [PATCH] capabilities: add capability cgroup controller

[Topi Miettinen]

On 07/08/16 09:13, Petr Mladek wrote:
> On Thu 2016-07-07 20:27:13, Topi Miettinen wrote:
>> On 07/07/16 09:16, Petr Mladek wrote:
>>> On Sun 2016-07-03 15:08:07, Topi Miettinen wrote:
 The attached patch would make any uses of capabilities generate audit
 messages. It works for simple tests as you can see from the commit
 message, but unfortunately the call to audit_cgroup_list() deadlocks the
 system when booting a full blown OS. There's no deadlock when the call
 is removed.

 I guess that in some cases, cgroup_mutex and/or css_set_lock could be
 already held earlier before entering audit_cgroup_list(). Holding the
 locks is however required by task_cgroup_from_root(). Is there any way
 to avoid this? For example, only print some kind of cgroup ID numbers
 (are there unique and stable IDs, available without locks?) for those
 cgroups where the task is registered in the audit message?
>>>
>>> I am not sure if anyone know what really happens here. I suggest to
>>> enable lockdep. It might detect possible deadlock even before it
>>> really happens, see Documentation/locking/lockdep-design.txt
>>>
>>> It can be enabled by
>>>
>>>CONFIG_PROVE_LOCKING=y
>>>
>>> It depends on
>>>
>>> CONFIG_DEBUG_KERNEL=y
>>>
>>> and maybe some more options, see lib/Kconfig.debug
>>
>> Thanks a lot! I caught this stack dump:
>>
>> starting version 230
>> [3.416647] [ cut here ]
>> [3.417310] WARNING: CPU: 0 PID: 95 at
>> /home/topi/d/linux.git/kernel/locking/lockdep.c:2871
>> lockdep_trace_alloc+0xb4/0xc0
>> [3.417605] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
>> [3.417923] Modules linked in:
>> [3.418288] CPU: 0 PID: 95 Comm: systemd-udevd Not tainted 4.7.0-rc5+ #97
>> [3.418444] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
>> BIOS Debian-1.8.2-1 04/01/2014
>> [3.418726]  0086 7970f3b0 8816fb00
>> 813c9c45
>> [3.418993]  8816fb50  8816fb40
>> 81091e9b
>> [3.419176]  0b3705e2c798 0046 0410
>> 
>> [3.419374] Call Trace:
>> [3.419511]  [] dump_stack+0x67/0x92
>> [3.419644]  [] __warn+0xcb/0xf0
>> [3.419745]  [] warn_slowpath_fmt+0x5f/0x80
>> [3.419868]  [] lockdep_trace_alloc+0xb4/0xc0
>> [3.419988]  [] kmem_cache_alloc_node+0x42/0x600
>> [3.420156]  [] ? debug_lockdep_rcu_enabled+0x1d/0x20
>> [3.420170]  [] __alloc_skb+0x5b/0x1d0
>> [3.420170]  [] audit_log_start+0x29b/0x480
>> [3.420170]  [] ? __lock_task_sighand+0x95/0x270
>> [3.420170]  [] audit_log_cap_use+0x39/0xf0
>> [3.420170]  [] ns_capable+0x45/0x70
>> [3.420170]  [] capable+0x17/0x20
>> [3.420170]  [] oom_score_adj_write+0x150/0x2f0
>> [3.420170]  [] __vfs_write+0x37/0x160
>> [3.420170]  [] ? update_fast_ctr+0x17/0x30
>> [3.420170]  [] ? percpu_down_read+0x49/0x90
>> [3.420170]  [] ? __sb_start_write+0xb7/0xf0
>> [3.420170]  [] ? __sb_start_write+0xb7/0xf0
>> [3.420170]  [] vfs_write+0xb8/0x1b0
>> [3.420170]  [] ? __fget_light+0x66/0x90
>> [3.420170]  [] SyS_write+0x58/0xc0
>> [3.420170]  [] do_syscall_64+0x5c/0x300
>> [3.420170]  [] entry_SYSCALL64_slow_path+0x25/0x25
>> [3.420170] ---[ end trace fb586899fb556a5e ]---
>> [3.447922] random: systemd-udevd urandom read with 3 bits of entropy
>> available
>> [4.014078] clocksource: Switched to clocksource tsc
>> Begin: Loading essential drivers ... done.
>>
>> This is with qemu and the boot continues normally. With real computer,
>> there's no such output and system just seems to freeze.
>>
>> Could it be possible that the deadlock happens because there's some IO
>> towards /sys/fs/cgroup, which causes a capability check and that in turn
>> causes locking problems when we try to print cgroup list?
> 
> The above warning is printed by the code from
> kernel/locking/lockdep.c:2871
> 
> static void __lockdep_trace_alloc(gfp_t gfp_mask, unsigned long flags)
> {
> [...]
>   /* We're only interested __GFP_FS allocations for now */
>   if (!(gfp_mask & __GFP_FS))
>   return;
> 
>   /*
>* Oi! Can't be having __GFP_FS allocations with IRQs disabled.
>*/
>   if (DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)))
>   return;
> 
> 
> The backtrace shows that your new audit_log_cap_use() is called
> from vfs_write(). You might try to use audit_log_start() with
> GFP_NOFS instead of GFP_KERNEL.
> 
> Note that this is rather intuitive advice. I still need to learn a lot
> about memory management and kernel in general to be more sure about
> a correct solution.
> 
> Best Regards,
> Petr
> 

With the attached patch, the system boots without deadlock. Locking
problems still remain:

[3.652221] ==
[3.652221] [ INFO: possible circular locking dependency detected ]
[

[PATCH v3 1/3] watchdog: Add Meson GXBB Watchdog Driver

[Neil Armstrong]

Add watchdog specific driver for Amlogic Meson GXBB SoC.

Signed-off-by: Neil Armstrong 
---
 drivers/watchdog/Kconfig  |  10 ++
 drivers/watchdog/Makefile |   1 +
 drivers/watchdog/meson_gxbb_wdt.c | 270 ++
 3 files changed, 281 insertions(+)
 create mode 100644 drivers/watchdog/meson_gxbb_wdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 9c41431..ad38cf5 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -609,6 +609,16 @@ config QCOM_WDT
  To compile this driver as a module, choose M here: the
  module will be called qcom_wdt.
 
+config MESON_GXBB_WATCHDOG
+   tristate "Amlogic Meson GXBB SoCs watchdog support"
+   depends on ARCH_MESON
+   select WATCHDOG_CORE
+   help
+ Say Y here to include support for the watchdog timer
+ in Amlogic Meson GXBB SoCs.
+ To compile this driver as a module, choose M here: the
+ module will be called meson_gxbb_wdt.
+
 config MESON_WATCHDOG
tristate "Amlogic Meson SoCs watchdog support"
depends on ARCH_MESON
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 9bde095..a46bf09 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_ST_LPC_WATCHDOG) += st_lpc_wdt.o
 obj-$(CONFIG_QCOM_WDT) += qcom-wdt.o
 obj-$(CONFIG_BCM_KONA_WDT) += bcm_kona_wdt.o
 obj-$(CONFIG_TEGRA_WATCHDOG) += tegra_wdt.o
+obj-$(CONFIG_MESON_GXBB_WATCHDOG) += meson_gxbb_wdt.o
 obj-$(CONFIG_MESON_WATCHDOG) += meson_wdt.o
 obj-$(CONFIG_MEDIATEK_WATCHDOG) += mtk_wdt.o
 obj-$(CONFIG_DIGICOLOR_WATCHDOG) += digicolor_wdt.o
diff --git a/drivers/watchdog/meson_gxbb_wdt.c 
b/drivers/watchdog/meson_gxbb_wdt.c
new file mode 100644
index 000..44d180a
--- /dev/null
+++ b/drivers/watchdog/meson_gxbb_wdt.c
@@ -0,0 +1,270 @@
+/*
+ * This file is provided under a dual BSD/GPLv2 license.  When using or
+ * redistributing this file, you may do so under either license.
+ *
+ * GPL LICENSE SUMMARY
+ *
+ * Copyright (c) 2016 BayLibre, SAS.
+ * Author: Neil Armstrong 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
+ * The full GNU General Public License is included in this distribution
+ * in the file called COPYING.
+ *
+ * BSD LICENSE
+ *
+ * Copyright (c) 2016 BayLibre, SAS.
+ * Author: Neil Armstrong 
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEFAULT_TIMEOUT30  /* seconds */
+
+#define GXBB_WDT_CTRL_REG  0x0
+#define GXBB_WDT_TCNT_REG  0x8
+#define GXBB_WDT_RSET_REG  0xc
+
+#define GXBB_WDT_CTRL_CLKDIV_ENBIT(25)
+#define GXBB_WDT_CTRL_CLK_EN   BIT(24)

[PATCH v3 3/3] ARM64: dts: amlogic: meson-gxbb: Add watchdog node

[Neil Armstrong]

Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 832815d..bcca82f 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -136,6 +136,12 @@
clocks = <>;
status = "disabled";
};
+
+   watchdog@98d0 {
+   compatible = "amlogic,meson-gxbb-wdt";
+   reg = <0x0 0x098d0 0x0 0x10>;
+   clocks = <>;
+   };
};
 
gic: interrupt-controller@c4301000 {
-- 
2.7.0

[PATCH v3 0/3] watchdog: Add Amlogic Meson GXBB Watchdog Timer driver

[Neil Armstrong]

Adds support for the Amlogic Meson GXBB SoC Watchdog Timer.
It differs from the meson6/meson8b HW, so need for a separate driver.
The HW provides a divider capable of having a 1ms timebase thus simplifying
the counter update.
The restart call is not provided even if the HW is capable of triggering a
system reset immediately because of the PSCI firmare having such functionnality.
The watchdog is not expected to be running at boot time since there is a 
separate
system-level watchdog running from the SCPI co-processor, but this case would be
handle in a next driver update.

Changes since v2 at 
http://lkml.kernel.org/r/1464943007-18000-1-git-send-email-narmstr...@baylibre.com
 :
- Fix set_timeout behaviour

Changes since v1 at 
http://lkml.kernel.org/r/1464614948-28247-1-git-send-email-narmstr...@baylibre.com
 :
- Update default timeout to 30sec
- Add separate CONFIG_
- Remove unused defines & functions
- Fix indentation
- Check set_timeout max value
- Reorder includes alphabetically
- Switch to human identify string
- clk_disable_unprepare on probe failure or removal

Changes since RFC version at 
http://lkml.kernel.org/r/1464249112-13658-1-git-send-email-narmstr...@baylibre.com
 :
- Remove status callback, will re-introduce it later to managed the 
already-running use case
- Fix registers defines indentation
- Fix space between operators
- Make all callbacks static functions
- Fix bindings with missing clocks attribute
- Do not stop/start watchdog on a timeout setup
- Fix probe device configuration

Neil Armstrong (3):
  watchdog: Add Meson GXBB Watchdog Driver
  dt-bindings: watchdog: Add Meson GXBB Watchdog bindings
  ARM64: dts: amlogic: meson-gxbb: Add watchdog node

 .../bindings/watchdog/meson-gxbb-wdt.txt   |  16 ++
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi|   6 +
 drivers/watchdog/Kconfig   |  10 +
 drivers/watchdog/Makefile  |   1 +
 drivers/watchdog/meson_gxbb_wdt.c  | 270 +
 5 files changed, 303 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/watchdog/meson-gxbb-wdt.txt
 create mode 100644 drivers/watchdog/meson_gxbb_wdt.c

-- 
2.7.0

[PATCH v3 2/3] dt-bindings: watchdog: Add Meson GXBB Watchdog bindings

[Neil Armstrong]

Acked-by: Rob Herring 
Signed-off-by: Neil Armstrong 
---
 .../devicetree/bindings/watchdog/meson-gxbb-wdt.txt  | 16 
 1 file changed, 16 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/watchdog/meson-gxbb-wdt.txt

diff --git a/Documentation/devicetree/bindings/watchdog/meson-gxbb-wdt.txt 
b/Documentation/devicetree/bindings/watchdog/meson-gxbb-wdt.txt
new file mode 100644
index 000..c7fe36f
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/meson-gxbb-wdt.txt
@@ -0,0 +1,16 @@
+Meson GXBB SoCs Watchdog timer
+
+Required properties:
+
+- compatible : should be "amlogic,meson-gxbb-wdt"
+- reg : Specifies base physical address and size of the registers.
+- clocks : Should be a phandle to the Watchdog clock source, for GXBB the xtal
+  is the default clock source.
+
+Example:
+
+wdt: watchdog@98d0 {
+   compatible = "amlogic,meson-gxbb-wdt";
+   reg = <0 0x98d0 0x0 0x10>;
+   clocks = <>;
+};
-- 
2.7.0

[PATCH v2 1/4] pwm: Add support for Meson PWM Controller

[Neil Armstrong]

Add support for the PWM controller found in the Amlogic SoCs.
This driver supports the Meson8b and GXBB SoCs.

Signed-off-by: Neil Armstrong 
---
 drivers/pwm/Kconfig |   9 +
 drivers/pwm/Makefile|   1 +
 drivers/pwm/pwm-meson.c | 491 
 3 files changed, 501 insertions(+)
 create mode 100644 drivers/pwm/pwm-meson.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index c182efc..cad5286 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -245,6 +245,15 @@ config PWM_LPSS_PLATFORM
  To compile this driver as a module, choose M here: the module
  will be called pwm-lpss-platform.
 
+config PWM_MESON
+   tristate "Amlogic Meson PWM driver"
+   depends on ARCH_MESON
+   help
+ The platform driver for Amlogic Meson PWM controller.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-meson.
+
 config PWM_MTK_DISP
tristate "MediaTek display PWM driver"
depends on ARCH_MEDIATEK || COMPILE_TEST
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index dd35bc1..3c8843e 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_PWM_LPC32XX) += pwm-lpc32xx.o
 obj-$(CONFIG_PWM_LPSS) += pwm-lpss.o
 obj-$(CONFIG_PWM_LPSS_PCI) += pwm-lpss-pci.o
 obj-$(CONFIG_PWM_LPSS_PLATFORM)+= pwm-lpss-platform.o
+obj-$(CONFIG_PWM_MESON)+= pwm-meson.o
 obj-$(CONFIG_PWM_MTK_DISP) += pwm-mtk-disp.o
 obj-$(CONFIG_PWM_MXS)  += pwm-mxs.o
 obj-$(CONFIG_PWM_OMAP_DMTIMER) += pwm-omap-dmtimer.o
diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c
new file mode 100644
index 000..9e7ecf5
--- /dev/null
+++ b/drivers/pwm/pwm-meson.c
@@ -0,0 +1,491 @@
+/*
+ * This file is provided under a dual BSD/GPLv2 license.  When using or
+ * redistributing this file, you may do so under either license.
+ *
+ * GPL LICENSE SUMMARY
+ *
+ * Copyright (c) 2016 BayLibre, SAS.
+ * Author: Neil Armstrong 
+ * Copyright (C) 2014 Amlogic, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
+ * The full GNU General Public License is included in this distribution
+ * in the file called COPYING.
+ *
+ * BSD LICENSE
+ *
+ * Copyright (c) 2016 BayLibre, SAS.
+ * Author: Neil Armstrong 
+ * Copyright (C) 2014 Amlogic, Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ *   * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ *   * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ *   * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define REG_PWM_A  0x0
+#define REG_PWM_B  0x4
+#define PWM_HIGH_SHIFT 16
+
+#define REG_MISC_AB0x8
+#define MISC_B_CLK_EN  BIT(23)
+#define MISC_A_CLK_EN  BIT(15)
+#define MISC_CLK_DIV_MASK  0x7f
+#define MISC_B_CLK_DIV_SHIFT   16
+#define MISC_A_CLK_DIV_SHIFT   8
+#define MISC_B_CLK_SEL_SHIFT   

[PATCH v2 2/4] dt-bindings: pwm: Add bindings for Meson PWM Controller

[Neil Armstrong]

Add bindings for the Amlogic PWM Controller in Meson8b and GXBB SoCs.

Signed-off-by: Neil Armstrong 
---
 Documentation/devicetree/bindings/pwm/pwm-meson.txt | 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-meson.txt

diff --git a/Documentation/devicetree/bindings/pwm/pwm-meson.txt 
b/Documentation/devicetree/bindings/pwm/pwm-meson.txt
new file mode 100644
index 000..e06aed0
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-meson.txt
@@ -0,0 +1,21 @@
+Amlogic Meson PWM Controller
+=
+
+Required properties:
+- compatible: Shall contain "amlogic,meson8b-pwm" or "amlogic,meson-gxbb-pwm".
+- #pwm-cells: Should be 3. See pwm.txt in this directory for a description of
+  the cells format.
+
+Optional properties:
+- clocks: Could contain one or two parents clocks phandle for each of the two 
pwm channels.
+- clock-names: Could contain at least the "clkin0" and/or "clkin1" names.
+
+Example:
+pwm_ab: pwm@8550 {
+   compatible = "amlogic,meson-gxbb-pwm";
+   reg = <0x0 0x08550 0x0 0x10>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   clocks = <>, <>;
+   clock-names = "clkin0", "clkin1";
+}
-- 
2.7.0

[no subject]

[Neil Armstrong]

Subject: [PATCH v2 0/4] pwm: Add Amlogic Meson SoC PWM Controller

Add support for the PWM controller found in Amlogic Meson SoCs.
This controller provides a dual PWM output with 4 selectable clock source
and a two level divider to achieve a better PWM range.

Currently Meson8b and GXBB SoCs are supported.

Changes since v1 at 
http://lkml.kernel.org/r/1466173784-15625-1-git-send-email-narmstr...@baylibre.com
 :
- fix meson8b dtsi

Neil Armstrong (4):
  pwm: Add support for Meson PWM Controller
  dt-bindings: pwm: Add bindings for Meson PWM Controller
  ARM64: dts: meson-gxbb: Add Meson GXBB PWM Controller nodes
  ARM: dts: meson8b: Add Meson8b PWM Controller nodes

 .../devicetree/bindings/pwm/pwm-meson.txt  |  21 +
 arch/arm/boot/dts/meson8b.dtsi |  21 +
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi|  28 ++
 drivers/pwm/Kconfig|   9 +
 drivers/pwm/Makefile   |   1 +
 drivers/pwm/pwm-meson.c| 491 +
 6 files changed, 571 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-meson.txt
 create mode 100644 drivers/pwm/pwm-meson.c

-- 
2.7.0

[PATCH v2 3/4] ARM64: dts: meson-gxbb: Add Meson GXBB PWM Controller nodes

[Neil Armstrong]

Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 28 
 1 file changed, 28 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 806b903..2eacef0 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -153,6 +153,27 @@
status = "disabled";
};
 
+   pwm_ab: pwm@8550 {
+   compatible = "amlogic,meson-gxbb-pwm";
+   reg = <0x0 0x08550 0x0 0x10>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
+
+   pwm_cd: pwm@8650 {
+   compatible = "amlogic,meson-gxbb-pwm";
+   reg = <0x0 0x08650 0x0 0x10>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
+
+   pwm_ef: pwm@86c0 {
+   compatible = "amlogic,meson-gxbb-pwm";
+   reg = <0x0 0x086c0 0x0 0x10>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
+
uart_C: serial@8700 {
compatible = "amlogic,meson-uart";
reg = <0x0 0x8700 0x0 0x14>;
@@ -212,6 +233,13 @@
clocks = <>;
status = "disabled";
};
+
+   pwm_ab_AO: pwm@550 {
+   compatible = "amlogic,meson-gxbb-pwm";
+   reg = <0x0 0x0550 0x0 0x10>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
};
 
periphs: periphs@c8834000 {
-- 
2.7.0

[PATCH v2 4/4] ARM: dts: meson8b: Add Meson8b PWM Controller nodes

[Neil Armstrong]

Signed-off-by: Neil Armstrong 
---
 arch/arm/boot/dts/meson8b.dtsi | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index fc4080d..41fd536 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -162,6 +162,27 @@
reg = <0xc1108000 0x4>, <0xc1104000 0x460>;
};
 
+   pwm_ab: pwm@8550 {
+   compatible = "amlogic,meson8b-pwm";
+   reg = <0xc1108550 0x10>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
+
+   pwm_cd: pwm@8650 {
+   compatible = "amlogic,meson8b-pwm";
+   reg = <0xc1108650 0x10>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
+
+   pwm_ef: pwm@86c0 {
+   compatible = "amlogic,meson8b-pwm";
+   reg = <0xc11086c0 0x10>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
+
pinctrl_cbus: pinctrl@c1109880 {
compatible = "amlogic,meson8b-cbus-pinctrl";
reg = <0xc1109880 0x10>;
-- 
2.7.0

Re: [RFC PATCH 0/3] doc-rst: customize HTML (RTD) theme

[Mauro Carvalho Chehab]

Em Sat, 9 Jul 2016 23:22:22 -0600
Jonathan Corbet  escreveu:

> On Tue, 5 Jul 2016 14:55:09 -0300
> Mauro Carvalho Chehab  wrote:
> 
> > I hope you don't mind. I'm merging those three patches on my tree
> > (for now, they're on an experimental tree that I can easily rebase, if
> > needed). If OK for you, my plan is to merge it on a separate branch,
> > together with the other patches for Documentation/linux_tv.  
> 
> [Slowly trying to catch back up with the real world; service will
> continue to be intermittent for a bit yet.]
> 
> So as far as I can tell, I never got part 1/3, not sure what happened
> there.

Yeah, I didn't receive either. I got them from the Markus git tree.

> In general, my only concern is that we haven't really begun the process
> of debating the proper bikeshed^Wtheme for the kernel docs.  Which is
> just fine.  At some point, we may want to think about it a bit more, but,
> for now, there is certainly no harm in making what we have work better.

Yeah, at some time we'll need to discuss the theme. The theme we're
using is fine, but still there are some things that could be improved.

Btw, if you want to take a look on how it it looks like,
you could take a look at:
https://linuxtv.org/downloads/v4l-dvb-apis-new/media/media_uapi.html

Right now (while we don't have an option to build just one book),
this is a complete build of the Sphinx documentation.

> Please feel free to include these with your stuff with my acked-by.

Ok, thanks! I actually merged it already on my main tree, on a
separate topic branch, together with the other patches that are
needed for the conversion:

https://git.linuxtv.org/media_tree.git/log/?h=docs-next

The changes there include patches for a new book part (CEC) and
for the new entities needed by the vsp1 (both are also on separate
topic branches).

My plan is to send my docs-next topic branch after Linus pick from
your tree, and, at by end of the merge window, send a patch
removing Documentation/media/DocBook.

Regards,
Mauro

[PATCH v5] wlcore: spi: add wl18xx support

[Reizer, Eyal]

Add support for using with both wl12xx and wl18xx.

- all wilink family needs special init command for entering wspi mode.
  extra clock cycles should be sent after the spi init command while the
  cs pin is high.
- Use inverted chip select for sending a dummy 4 bytes command that
  completes the init stage.

Signed-off-by: Eyal Reizer 
---
v1->v2:update device tree bindings configuration
v2->v3:revert from manual gpio manipulation. use inverted chip select instead
for sending the extra init cycle which, achieves the same hardware purpose.
update device tree bindings docucmentation accordingly
v3->v4: Remove redundant data form binding documentation and fix chip select
number mismatch in wl1271 example
v4->v5: Rebase on top of head of wireless-drivers-next

 .../bindings/net/wireless/ti,wlcore,spi.txt|  41 +--
 drivers/net/wireless/ti/wlcore/spi.c   | 123 ++---
 2 files changed, 137 insertions(+), 27 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt 
b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
index 9180724..8f9ced0 100644
--- a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
@@ -1,19 +1,30 @@
-* Texas Instruments wl1271 wireless lan controller
+* Texas Instruments wl12xx/wl18xx wireless lan controller

-The wl1271 chip can be connected via SPI or via SDIO. This
+The wl12xx/wl18xx chips can be connected via SPI or via SDIO. This
 document describes the binding for the SPI connected chip.

 Required properties:
-- compatible :  Should be "ti,wl1271"
+- compatible :  Should be one of the following:
+* "ti,wl1271"
+* "ti,wl1273"
+* "ti,wl1281"
+* "ti,wl1283"
+* "ti,wl1801"
+* "ti,wl1805"
+* "ti,wl1807"
+* "ti,wl1831"
+* "ti,wl1835"
+* "ti,wl1837"
 - reg : Chip select address of device
 - spi-max-frequency :   Maximum SPI clocking speed of device in Hz
-- ref-clock-frequency : Reference clock frequency
 - interrupt-parent, interrupts :
 Should contain parameters for 1 interrupt line.
 Interrupt parameters: parent, line number, type.
-- vwlan-supply :Point the node of the regulator that powers/enable the 
wl1271 chip
+- vwlan-supply :Point the node of the regulator that powers/enable the
+wl12xx/wl18xx chip

 Optional properties:
+- ref-clock-frequency : Reference clock frequency (should be set for wl12xx)
 - clock-xtal :  boolean, clock is generated from XTAL

 - Please consult Documentation/devicetree/bindings/spi/spi-bus.txt
@@ -21,16 +32,28 @@ Optional properties:

 Examples:

+For wl12xx family:
  {
-   wl1271@1 {
+   wlcore: wlcore@1 {
compatible = "ti,wl1271";
-
reg = <1>;
spi-max-frequency = <4800>;
-   clock-xtal;
-   ref-clock-frequency = <3840>;
interrupt-parent = <>;
interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
vwlan-supply = <_fixed>;
+   clock-xtal;
+   ref-clock-frequency = <3840>;
+   };
+};
+
+For wl18xx family:
+ {
+   wlcore: wlcore@0 {
+   compatible = "ti,wl1835";
+   reg = <0>;
+   spi-max-frequency = <4800>;
+   interrupt-parent = <>;
+   interrupts = <27 IRQ_TYPE_EDGE_RISING>;
+   vwlan-supply = <_fixed>;
};
 };
diff --git a/drivers/net/wireless/ti/wlcore/spi.c 
b/drivers/net/wireless/ti/wlcore/spi.c
index cea9443..73fbcf1 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -70,16 +70,30 @@
 #define WSPI_MAX_CHUNK_SIZE4092

 /*
- * only support SPI for 12xx - this code should be reworked when 18xx
- * support is introduced
+ * wl18xx driver aggregation buffer size is (13 * PAGE_SIZE) compared to
+ * (4 * PAGE_SIZE) for wl12xx, so use the larger buffer needed for wl18xx
  */
-#define SPI_AGGR_BUFFER_SIZE (4 * PAGE_SIZE)
+#define SPI_AGGR_BUFFER_SIZE (13 * PAGE_SIZE)

 /* Maximum number of SPI write chunks */
 #define WSPI_MAX_NUM_OF_CHUNKS \
((SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE) + 1)


+struct wilink_familiy_data {
+   char name[8];
+};
+
+const struct wilink_familiy_data *wilink_data;
+
+static const struct wilink_familiy_data wl18xx_data = {
+   .name = "wl18xx",
+};
+
+static const struct wilink_familiy_data wl12xx_data = {
+   .name = "wl12xx",
+};
+
 struct wl12xx_spi_glue {
struct device *dev;
struct platform_device *core;
@@ -119,6 +133,7 @@ static void wl12xx_spi_init(struct device *child)
struct wl12xx_spi_glue *glue = dev_get_drvdata(child->parent);
struct spi_transfer t;
struct spi_message m;
+   struct spi_device *spi = to_spi_device(glue->dev);
 

Re: Re: cgroup: Fix split bio been throttled more than once

[Ming Lei]

On Sat, Jul 9, 2016 at 10:53 PM, Tejun Heo  wrote:
> Hello, Ming.
>
> On Fri, Jul 08, 2016 at 06:35:06PM +0800, Ming Lei wrote:
>> I am wondering why REQ_THROTTLED is cleared for the original bio
>> even it has been charged and will be issued to driver, and is it allowed
>> to throttle and charge the same bio for many times?
>
> So, IIUC, the flag is just to prevent the bio from recursing while
> being issued from blk-throtl after queued there for throttling.  We
> can probably extend the flag.  I'm not sure how it'd interact with
> stacked drivers tho.  It'd definitely need to be cleared before
> traveling down to a lower level device.

I think I understand it now, in case of stacked driver, the cloned bio
will be submitted
to a new request queue belonging to lower disk, and orignal bio's
REQ_THROTTLED flag should be cleared.

But in case of bio splitting, the remainder bio is just the orignal
bio with front part
splitted out, and it need to submit to same queue again, so it should be
bypassed of throttling because it has been charged already.

So looks Jiale's patch is correct, also seems 'blkg_rwstat_add()' should be
avoided for the remainder bio too in blkcg_bio_issue_check().

thanks,
Ming Lei

Re: [tip:x86/boot] x86/KASLR: Fix boot crash with certain memory configurations

[Baoquan He]

Hi Ingo,

I am sorry the previous post didn't contain formal patch log. I made a
new one as below. The boot crash could not only happen with certain
memory. Because of this code bug the regions which need be avoided like
the zipped kernel with its unzipping running code, initrd, kernel
command line could be corrupted if mem_avoid_overlap() can't find the
overlap region with the lowest address. But it's very lucky that
Xiaolong's system which has only 300M memory can always reproduce it.
I checked the boog log and found on his system no any other slot can be
chosen except for the original one. If we have a system with large memory
it may not be easy to hit it, at least with low probability since there
are many candidate slots.



>From 8f48aa39f3e49f9c1a9bb8ee61547dda7c2c05c3 Mon Sep 17 00:00:00 2001
From: Baoquan He 
Date: Fri, 1 Jul 2016 15:34:40 +0800
Subject: [PATCH] x86/KASLR: Fix boot crash caused by wrongly chosen kernel
 physical address

System halted with the separate randomization code applied. With debug printing
we got the reason that the chosen kernel physical address randomly is overlapped
with input dada. So input data and its running space must be corrupted during
decompressing kernel, then boot crash happened.

The root cause is that in function mem_avoid_overlap() local variable 'earliest'
is not updated correctly. Function mem_avoid_overlap is used to find the overlap
region with the lowest address, and 'earliest' is used to track the lowest 
address.
Decompressing kernel could step into those regions which need be avoided if we
didn't handle these overlap region correctly. So fix the code bug now.

Signed-off-by: Baoquan He 
---
 arch/x86/boot/compressed/kaslr.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 304c5c3..8e1fdf7 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -285,6 +285,7 @@ static bool mem_avoid_overlap(struct mem_vector *img,
if (mem_overlaps(img, _avoid[i]) &&
mem_avoid[i].start < earliest) {
*overlap = mem_avoid[i];
+   earliest = overlap->start;
is_overlapping = true;
}
}
@@ -299,6 +300,7 @@ static bool mem_avoid_overlap(struct mem_vector *img,
 
if (mem_overlaps(img, ) && (avoid.start < earliest)) {
*overlap = avoid;
+   earliest = overlap->start;
is_overlapping = true;
}
 
-- 
2.5.5

Re: [RFC][PATCH 1/7] perf/x86/intel: Rework the large PEBS setup code

[Jiri Olsa]

On Sat, Jul 09, 2016 at 12:25:09AM +0200, Peter Zijlstra wrote:
> On Sat, Jul 09, 2016 at 12:00:47AM +0200, Peter Zijlstra wrote:
> > Yes, you're right. Let me try and see if I can make that better.
> 
> Something like so?

yep, seems good ;-)

jirka

> 
> ---
> --- a/arch/x86/events/intel/ds.c
> +++ b/arch/x86/events/intel/ds.c
> @@ -831,6 +831,18 @@ static inline void pebs_update_threshold
>   ds->pebs_interrupt_threshold = threshold;
>  }
>  
> +static void pebs_update_state(bool needs_cb, struct cpu_hw_events *cpuc, 
> struct pmu *pmu)
> +{
> + if (needs_cb != pebs_needs_sched_cb(cpuc)) {
> + if (!needs_cb)
> + perf_sched_cb_inc(pmu);
> + else
> + perf_sched_cb_dec(pmu);
> +
> + pebs_update_threshold(cpuc);
> + }
> +}
> +
>  static void intel_pmu_pebs_add(struct perf_event *event)
>  {
>   struct cpu_hw_events *cpuc = this_cpu_ptr(_hw_events);
> @@ -841,10 +853,7 @@ static void intel_pmu_pebs_add(struct pe
>   if (hwc->flags & PERF_X86_EVENT_FREERUNNING)
>   cpuc->n_large_pebs++;
>  
> - if (!needs_cb && pebs_needs_sched_cb(cpuc))
> - perf_sched_cb_inc(event->ctx->pmu);
> -
> - pebs_update_threshold(cpuc);
> + pebs_update_state(needs_cb, cpuc, event->ctx->pmu);
>  }
>  
>  void intel_pmu_pebs_enable(struct perf_event *event)
> @@ -884,11 +893,7 @@ static void intel_pmu_pebs_del(struct pe
>   if (hwc->flags & PERF_X86_EVENT_FREERUNNING)
>   cpuc->n_large_pebs--;
>  
> - if (needs_cb && !pebs_needs_sched_cb(cpuc))
> - perf_sched_cb_dec(event->ctx->pmu);
> -
> - if (cpuc->n_pebs)
> - pebs_update_threshold(cpuc);
> + pebs_update_state(needs_cb, cpuc, event->ctx->pmu);
>  }
>  
>  void intel_pmu_pebs_disable(struct perf_event *event)

Re: [PATCH 0/9] mm: Hardened usercopy

[Ingo Molnar]

* PaX Team  wrote:

> On 9 Jul 2016 at 14:27, Andy Lutomirski wrote:
> 
> > I like the series, but I have one minor nit to pick.  The effect of this 
> > series is to harden usercopy, but most of the code is really about 
> > infrastructure to validate that a pointed-to object is valid.
> 
> actually USERCOPY has never been about validating pointers. its sole purpose 
> is 
> to validate the *size* argument of copy*user calls, a very specific form of 
> runtime bounds checking.

What this code has been about originally is largely immaterial, unless you can 
formulate it into a technical argument.

There are a number of cheap tests we can do and there are a number of ways how 
a 
'pointer' can be validated runtime, without any 'size' information:

 - for example if a pointer points into a red zone straight away then we know 
it's
   bogus.

 - or if a kernel pointer is points outside the valid kernel virtual memory 
range
   we know it's bogus as well.

So while only doing a bounds check might have been the original purpose of the 
patch set, Andy's point is that it might make sense to treat this facility as a 
more generic 'object validation' code of (pointer,size) object and not limit it 
to 
'runtime bounds checking'. That kind of extended purpose behind a facility 
should 
be reflected in the naming.

Confusing names are often the source of misunderstandings and bugs.

The 9-patch series as submitted here is neither just 'bounds checking' nor just 
pure 'pointer checking', it's about validating that a (pointer,size) range of 
memory passed to a (user) memory copy function is fully within a valid object 
the 
kernel might know about (in an fast to check fashion).

This necessary means:

 - the start of the range points to a valid object to begin with (if known)

 - the range itself does not point beyond the end of the object (if known)

 - even if the kernel does not know anything about the pointed to object it can 
   do a pointer check (for example is it pointing inside kernel virtual memory) 
   and do a bounds check on the size.

Do you disagree with that?

> > Might it make sense to call the infrastructure part something else?
> 
> yes, more bikeshedding will surely help, [...]

Insulting and ridiculing a reviewer who explicitly qualified his comments with 
"one minor nit to pick" sure does not help upstream integration either. (Unless 
the goal is to prevent upstream integration.)

> [...] like the renaming of .data..read_only to .data..ro_after_init which 
> also 
> had nothing to do with init but everything to do with objects being 
> conceptually 
> read-only...

.data..ro_after_init objects get written to during bootup so it's conceptually 
quite confusing to name it "read-only" without any clear qualifiers.

That it's named consistently with its role of "read-write before init and read 
only after init" on the other hand is not confusing at all. Not sure what your 
problem is with the new name.

Names within submitted patches get renamed on a routine basis during review. 
It's 
often only minor improvements in naming (which you can consider bike shedding), 
but in this particular case the rename was clearly useful in not just improving 
the name but in avoiding an actively confusing name. So I disagree not just 
with 
the hostile tone of your reply but with your underlying technical point as well.

Thanks,

Ingo

Re: [PATCH] dma-buf/sync_file: only enable fence signalling during wait

[Maarten Lankhorst]

Op 08-07-16 om 17:44 schreef Gustavo Padovan:
> From: Gustavo Padovan 
>
> Signalling doesn't need to be enabled at sync_file creation, it is only
> required if userspace waiting the fence to signal through poll().
>
> Thus we delay fence_add_callback() until poll is called. It only adds the
> callback the first time poll() is called. This avoid re-adding the same
> callback multiple times.
>
> v2: rebase and update to work with new fence support for sync_file
>
> Signed-off-by: Gustavo Padovan 
> ---
> This patch applies on top of my latest sync_file changes to support
> fence_array: https://lkml.org/lkml/2016/7/4/534
>
>  drivers/dma-buf/sync_file.c | 23 ++-
>  include/linux/sync_file.h   |  2 ++
>  2 files changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
> index 61a687c..1db4a64 100644
> --- a/drivers/dma-buf/sync_file.c
> +++ b/drivers/dma-buf/sync_file.c
> @@ -86,8 +86,6 @@ struct sync_file *sync_file_create(struct fence *fence)
>fence->ops->get_timeline_name(fence), fence->context,
>fence->seqno);
>  
> - fence_add_callback(fence, _file->cb, fence_check_cb_func);
> -
>   return sync_file;
>  }
>  EXPORT_SYMBOL(sync_file_create);
> @@ -269,9 +267,6 @@ static struct sync_file *sync_file_merge(const char 
> *name, struct sync_file *a,
>   goto err;
>   }
>  
> - fence_add_callback(sync_file->fence, _file->cb,
> -fence_check_cb_func);
> -
>   strlcpy(sync_file->name, name, sizeof(sync_file->name));
>   return sync_file;
>  
> @@ -286,7 +281,6 @@ static void sync_file_free(struct kref *kref)
>   struct sync_file *sync_file = container_of(kref, struct sync_file,
>kref);
>  
> - fence_remove_callback(sync_file->fence, _file->cb);
>   fence_put(sync_file->fence);
>   kfree(sync_file);
>  }
> @@ -306,13 +300,24 @@ static unsigned int sync_file_poll(struct file *file, 
> poll_table *wait)
>  
>   poll_wait(file, _file->wq, wait);
>  
> + if (!sync_file->enabled) {
> + fence_add_callback(sync_file->fence, _file->cb,
> +fence_check_cb_func);
> + sync_file->enabled = true;
> + }
Won't this blow up completely with 2 threads polling at the same time?

~Maarten

[PATCH] kconfig: Fix menu/endmenu markers in zconfdump()

[Eugeniu Rosca]

Given a Kconfig.sample, implementing 2 empty and 2 non-empty menu
entries:

menu EMPTY_MENU
endmenu

menu NONEMPTY_MENU
config DUMMY_1
bool "desc-1"
endmenu

menuconfig EMPTY_MENUCONFIG
bool "desc-2"

menuconfig NONEMPTY_MENUCONFIG
bool "desc-3"

if NONEMPTY_MENUCONFIG
config DUMMY_2
bool "desc-4"
endif

The following can be observed (prerequisite: uncomment zconfdump()
in scripts/kconfig/conf.c):
> make KBUILD_KCONFIG=Kconfig.sample allnoconfig | grep -cw menu
> 4
> make KBUILD_KCONFIG=Kconfig.sample allnoconfig | grep -cw endmenu
> 3

It looks like zconfdump() has the following inconsistencies:
A. It prints the start marker 'menu' both for empty and non-empty menu
   entries, while printing the end marker 'endmenu' only for non-empty
   menu entries.
B. At the end of every dump, it prints the end marker of the root
   menu, while skipping its start marker, so that even if (A) is fixed,
   the number of start and end markers is still not equal.

Fix (A) and (B).

Signed-off-by: Eugeniu Rosca 
---
 scripts/kconfig/zconf.tab.c_shipped | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/scripts/kconfig/zconf.tab.c_shipped 
b/scripts/kconfig/zconf.tab.c_shipped
index 7a4d658..727b7dd 100644
--- a/scripts/kconfig/zconf.tab.c_shipped
+++ b/scripts/kconfig/zconf.tab.c_shipped
@@ -2510,6 +2510,8 @@ static void print_symbol(FILE *out, struct menu *menu)
fputs( "  menu ", out);
print_quoted_string(out, prop->text);
fputc('\n', out);
+   if (!menu->list)
+   fputs("endmenu\n", out);
break;
default:
fprintf(out, "  unknown prop %d!\n", prop->type);
@@ -2530,7 +2532,7 @@ void zconfdump(FILE *out)
struct symbol *sym;
struct menu *menu;
 
-   menu = rootmenu.list;
+   menu = 
while (menu) {
if ((sym = menu->sym))
print_symbol(out, menu);
@@ -2545,6 +2547,8 @@ void zconfdump(FILE *out)
fputs("\nmenu ", out);
print_quoted_string(out, prop->text);
fputs("\n", out);
+   if (!menu->list)
+   fputs("endmenu\n", out);
break;
default:
;
-- 
2.7.4

Re: 4.7-rc6, ext4, sparc64: Unable to handle kernel paging request at ...

[Mikael Pettersson]

Meelis Roos writes:
 > > > Just got this on bootup of my Sun T2000:
 > > >...
 > > > I have not seen it before, this includes 4.6.0 4.6.0-08907-g7639dad
 > > > 4.7.0-rc1-00094-g6b15d66 4.7.0-rc4-00014-g67016f6.
 > > >
 > > > It is not reproducible, did not appear on next reboot of the same
 > > > kernel.
 > > 
 > > mine T5120 boots ok 4.7.0-rc6, rootfs being on ext4 .
 > 
 > My T5120 and many other sparc64 machines also boot fine, most of them 
 > using ext4, others ext3 with ext4 driver.
 > 
 > However, I also got a very similar oops from T1000:
 > 
 > [   55.251101] Unable to handle kernel paging request at virtual address 
 > fe42a000
 > [   55.251348] tsk->{mm,active_mm}->context = 0083
 > [   55.251533] tsk->{mm,active_mm}->pgd = 8001f6224000
 > [   55.251719]   \|/  \|/
 >  "@'/ .. \`@"
 >  /_| \__/ |_\
 > \__U_/
 > [   55.252038] systemd-udevd(268): Oops [#1]
 > [   55.252274] CPU: 9 PID: 268 Comm: systemd-udevd Not tainted 4.7.0-rc6 #26
 > [   55.252367] task: 8001f6064380 ti: 8001f620c000 task.ti: 
 > 8001f620c000
 > [   55.252497] TSTATE: 000811001604 TPC: 00649380 TNPC: 
 > 00649384 Y: Not tainted
 > [   55.252651] TPC: <__radix_tree_lookup+0x60/0x1a0>
...

A few weeks ago I got a similar oops with 4.7.0-rc2 on a Sun Blade 2500 (dual 
USIIIi):

Jun 12 18:40:26 lauter kernel: Unable to handle kernel paging request at 
virtual address a000
Jun 12 18:40:26 lauter kernel: tsk->{mm,active_mm}->context = 17e3
Jun 12 18:40:26 lauter kernel: tsk->{mm,active_mm}->pgd = fff23edb8000
Jun 12 18:40:26 lauter kernel:   \|/  \|/
Jun 12 18:40:26 lauter kernel:   "@'/ .. \`@"
Jun 12 18:40:26 lauter kernel:   /_| \__/ |_\
Jun 12 18:40:26 lauter kernel:  \__U_/
Jun 12 18:40:26 lauter kernel: gnat1(19464): Oops [#1]
Jun 12 18:40:26 lauter kernel: CPU: 0 PID: 19464 Comm: gnat1 Not tainted 
4.7.0-rc2 #1
Jun 12 18:40:26 lauter kernel: task: fff23ebd1440 ti: fff000123c36 
task.ti: fff000123c36
Jun 12 18:40:27 lauter kernel: TSTATE: 11001604 TPC: 005db288 
TNPC: 005db28c Y: Not tainted
Jun 12 18:40:27 lauter kernel: TPC: <__radix_tree_lookup+0x44/0xd4>
Jun 12 18:40:27 lauter kernel: g0: 3000 g1: a6d9 g2: 
0001 g3: 
Jun 12 18:40:27 lauter kernel: g4: fff23ebd1440 g5: fff23ef7a000 g6: 
fff000123c36 g7: 
Jun 12 18:40:27 lauter kernel: o0: 000c o1: fff000123c363980 o2: 
fff000123c363988 o3: fff000123c363968
Jun 12 18:40:27 lauter kernel: o4: 0020 o5: fff23fffefc0 sp: 
fff000123c3630d1 ret_pc: fff232e42540
Jun 12 18:40:27 lauter kernel: RPC: <0xfff232e42540>
Jun 12 18:40:27 lauter kernel: l0: 024213ca l1:  l2: 
 l3: 
Jun 12 18:40:27 lauter kernel: l4:  l5:  l6: 
 l7: 
Jun 12 18:40:27 lauter kernel: i0: fff0001225e56900 i1: 0441 i2: 
 i3: 
Jun 12 18:40:27 lauter kernel: i4: a6d8 i5: fff232e42540 i6: 
fff000123c363191 i7: 004bf680
Jun 12 18:40:27 lauter kernel: I7: <__do_page_cache_readahead+0x78/0x200>
Jun 12 18:40:27 lauter kernel: Call Trace:
Jun 12 18:40:27 lauter kernel:  [004bf680] 
__do_page_cache_readahead+0x78/0x200
Jun 12 18:40:27 lauter kernel:  [004b5990] filemap_fault+0x164/0x4c4
Jun 12 18:40:27 lauter kernel:  [00562a84] ext4_filemap_fault+0x1c/0x38
Jun 12 18:40:27 lauter kernel:  [004d2c38] __do_fault+0x58/0xdc
Jun 12 18:40:27 lauter kernel:  [004d611c] handle_mm_fault+0x604/0xe5c
Jun 12 18:40:27 lauter kernel:  [00448288] do_sparc64_fault+0x228/0x684
Jun 12 18:40:27 lauter kernel:  [00407bcc] 
sparc64_realfault_common+0x10/0x20
Jun 12 18:40:28 lauter kernel: Disabling lock debugging due to kernel taint
Jun 12 18:40:28 lauter kernel: Caller[004bf680]: 
__do_page_cache_readahead+0x78/0x200
Jun 12 18:40:28 lauter kernel: Caller[004b5990]: 
filemap_fault+0x164/0x4c4
Jun 12 18:40:28 lauter kernel: Caller[00562a84]: 
ext4_filemap_fault+0x1c/0x38
Jun 12 18:40:28 lauter kernel: Caller[004d2c38]: __do_fault+0x58/0xdc
Jun 12 18:40:28 lauter kernel: Caller[004d611c]: 
handle_mm_fault+0x604/0xe5c
Jun 12 18:40:28 lauter kernel: Caller[00448288]: 
do_sparc64_fault+0x228/0x684
Jun 12 18:40:28 lauter kernel: Caller[00407bcc]: 
sparc64_realfault_common+0x10/0x20
Jun 12 18:40:28 lauter kernel: Caller[006ee248]: 
ip_options_compile+0x288/0x60c
Jun 12 18:40:28 lauter kernel: Instruction DUMP: 80a06001  0267fff2  b8087ffe 
 83365001  8208603f  84006004  83287003  8528b003

It's only happended that one time, so far.

Re: Missing include file in include/uapi/linux/errqueue.h?

[Willem de Bruijn]

On Sun, Jul 10, 2016 at 1:43 AM, Brooks Moses  wrote:
> On Sat, Jul 9, 2016 at 10:36 AM, Brooks Moses  wrote:
>> I've been attempting to qualify the Linux 4.5.2 user-space headers for
>> a toolchain release, and ran into what looks like a missing include
>> file in include/uapi/linux/errqueue.h.  In particular,
>> https://github.com/torvalds/linux/commit/f24b9be5957b38bb420b838115040dc2031b7d0c
>> adds the following to this file:
>>
>> +struct scm_timestamping {
>> + struct timespec ts[3];
>> +};
>>
>> However, struct timespec is defined in time.h, which isn't included
>> either in 4.5.2 or in current head.  Is this simply a missing #include
>> line,

It is. I missed that in my original patch.

> or am I misunderstanding something?
>
> As a followup: Unfortunately the obvious fix -- adding "#include
> " -- causes other problems, since linux/time.h is
> incompatible with the glibc time.h such that including both of them
> into the same compilation unit causes errors about redefined types.

If these conflicts between libc and uapi time.h can be resolved through
include/uapi/linux/libc-compat.h, then we can apply the obvious fix of
including linux/time.h in linux/errqueue.h.

> And we, at least, have some programs that want to include
> linux/errqueue.h and (glibc's) time.h.  The fix of adding "#include
> " to linux/errqueue.h seems to work for us, but I'm not sure
> that won't cause problems in the other direction for other people.

That breaks kernel compilation.

Re: [PATCH 4/4] kernel/time/clockevents: compensate for monotonic clock's dynamic frequency

[kbuild test robot]

Hi,

[auto build test ERROR on tip/timers/core]
[also build test ERROR on v4.7-rc6 next-20160708]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Nicolai-Stange/avoid-double-timer-interrupt-with-nohz-and-Intel-TSC/20160710-202914
config: sh-sh7785lcr_32bit_defconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 5.3.1-8) 5.3.1 20160205
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sh 

All errors (new ones prefixed by >>):

   kernel/built-in.o: In function `timekeeping_mono_interval_to_raw':
>> kernel/time/timekeeping.c:2164: undefined reference to `__divdi3'

vim +2164 kernel/time/timekeeping.c

  2158   * that is they cancel.
  2159   */
  2160  if (KTIME_MAX / raw_mult < interval)
  2161  return KTIME_MAX;
  2162  raw = interval * raw_mult;
  2163  
> 2164  if (KTIME_MAX - mono_mult / 2 < raw)
  2165  return KTIME_MAX;
  2166  raw += mono_mult / 2; /* round properly */
  2167  raw /= mono_mult;

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


.config.gz
Description: Binary data

[PATCH] sched/core: add doc for cookie argument

[Luis de Bethencourt]

Add documentation for the cookie argument in try_to_wake_up_local()

This caused the following warning when building documentation:
kernel/sched/core.c:2088: warning: No description found for parameter 'cookie'

Fixes: e7904a28f533 ("ilocking/lockdep, sched/core: Implement a better lock 
pinning scheme")

Signed-off-by: Luis de Bethencourt 
---
 kernel/sched/core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 8c642cc..1f35e8c 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2079,6 +2079,7 @@ out:
 /**
  * try_to_wake_up_local - try to wake up a local task with rq lock held
  * @p: the thread to be awakened
+ * @cookie: context's cookie for pinning
  *
  * Put @p on the run-queue if it's not already there. The caller must
  * ensure that this_rq() is locked, @p is bound to this_rq() and not
-- 
2.5.1

[PATCH v2] spi: spi-topcliff-pch: Remove deprecated create_singlethread_workqueue

[Bhaktipriya Shridhar]

The workqueue "wk" serves as a queue for carrying out execution
of requests. It has a single work item(_data->work) and hence doesn't
require ordering. Also, it is not being used on a memory reclaim path.
Hence, the singlethreaded workqueue has been replaced with the use of
system_wq.

System workqueues have been able to handle high level of concurrency
for a long time now and hence it's not required to have a singlethreaded
workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue
created with create_singlethread_workqueue(), system_wq allows multiple
work items to overlap executions even on the same CPU; however, a
per-cpu workqueue doesn't have any CPU locality or global ordering
guarantee unless the target CPU is explicitly specified and thus the
increase of local concurrency shouldn't make any difference.

Work item has been flushed in pch_spi_free_resources() to ensure that
there are no pending tasks while disconnecting the driver.

Also dropped the label 'err_return' since it's not being used anymore.

Signed-off-by: Bhaktipriya Shridhar 
---
 Changes in v2:
-Fixed build warning by removing unused label 'err_return'

 drivers/spi/spi-topcliff-pch.c | 26 +++---
 1 file changed, 3 insertions(+), 23 deletions(-)

diff --git a/drivers/spi/spi-topcliff-pch.c b/drivers/spi/spi-topcliff-pch.c
index 93dfcee..c54ee66 100644
--- a/drivers/spi/spi-topcliff-pch.c
+++ b/drivers/spi/spi-topcliff-pch.c
@@ -133,8 +133,6 @@ struct pch_spi_dma_ctrl {
  * @io_remap_addr: The remapped PCI base address
  * @master:Pointer to the SPI master structure
  * @work:  Reference to work queue handler
- * @wk:Workqueue for carrying out execution of 
the
- * requests
  * @wait:  Wait queue for waking up upon receiving an
  * interrupt.
  * @transfer_complete: Status of SPI Transfer
@@ -169,7 +167,6 @@ struct pch_spi_data {
unsigned long io_base_addr;
struct spi_master *master;
struct work_struct work;
-   struct workqueue_struct *wk;
wait_queue_head_t wait;
u8 transfer_complete;
u8 bcurrent_msg_processing;
@@ -517,8 +514,7 @@ static int pch_spi_transfer(struct spi_device *pspi, struct 
spi_message *pmsg)

dev_dbg(>dev, "%s - Invoked list_add_tail\n", __func__);

-   /* schedule work queue to run */
-   queue_work(data->wk, >work);
+   schedule_work(>work);
dev_dbg(>dev, "%s - Invoked queue work\n", __func__);

retval = 0;
@@ -674,7 +670,7 @@ static void pch_spi_nomore_transfer(struct pch_spi_data 
*data)
 *more messages)
 */
dev_dbg(>master->dev, "%s:Invoke queue_work\n", __func__);
-   queue_work(data->wk, >work);
+   schedule_work(>work);
} else if (data->board_dat->suspend_sts ||
   data->status == STATUS_EXITING) {
dev_dbg(>master->dev,
@@ -1266,14 +1262,7 @@ static void pch_spi_free_resources(struct 
pch_spi_board_data *board_dat,
 {
dev_dbg(_dat->pdev->dev, "%s ENTRY\n", __func__);

-   /* free workqueue */
-   if (data->wk != NULL) {
-   destroy_workqueue(data->wk);
-   data->wk = NULL;
-   dev_dbg(_dat->pdev->dev,
-   "%s destroy_workqueue invoked successfully\n",
-   __func__);
-   }
+   flush_work(>work);
 }

 static int pch_spi_get_resources(struct pch_spi_board_data *board_dat,
@@ -1283,14 +1272,6 @@ static int pch_spi_get_resources(struct 
pch_spi_board_data *board_dat,

dev_dbg(_dat->pdev->dev, "%s ENTRY\n", __func__);

-   /* create workqueue */
-   data->wk = create_singlethread_workqueue(KBUILD_MODNAME);
-   if (!data->wk) {
-   dev_err(_dat->pdev->dev,
-   "%s create_singlet hread_workqueue failed\n", __func__);
-   retval = -EBUSY;
-   goto err_return;
-   }

/* reset PCH SPI h/w */
pch_spi_reset(data->master);
@@ -1299,7 +1280,6 @@ static int pch_spi_get_resources(struct 
pch_spi_board_data *board_dat,

dev_dbg(_dat->pdev->dev, "%s data->irq_reg_sts=true\n", __func__);

-err_return:
if (retval != 0) {
dev_err(_dat->pdev->dev,
"%s FAIL:invoking pch_spi_free_resources\n", __func__);
--
2.1.4

Re: [PATCH 4/4] kernel/time/clockevents: compensate for monotonic clock's dynamic frequency

[kbuild test robot]

Hi,

[auto build test ERROR on tip/timers/core]
[also build test ERROR on v4.7-rc6 next-20160708]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Nicolai-Stange/avoid-double-timer-interrupt-with-nohz-and-Intel-TSC/20160710-202914
config: frv-defconfig (attached as .config)
compiler: frv-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=frv 

All errors (new ones prefixed by >>):

   frv-linux-ld: Warning: size of symbol `read_persistent_clock' changed from 
160 in arch/frv/kernel/built-in.o to 12 in kernel/built-in.o
   frv-linux-ld: Warning: size of symbol `sched_clock' changed from 56 in 
arch/frv/kernel/built-in.o to 40 in kernel/built-in.o
   frv-linux-ld: Warning: size of symbol `arch_cpu_idle' changed from 64 in 
arch/frv/kernel/built-in.o to 20 in kernel/built-in.o
   frv-linux-ld: Warning: size of symbol `arch_show_interrupts' changed from 84 
in arch/frv/kernel/built-in.o to 8 in kernel/built-in.o
   frv-linux-ld: Warning: size of symbol `sys_fadvise64_64' changed from 8 in 
kernel/built-in.o to 780 in mm/built-in.o
   frv-linux-ld: Warning: size of symbol `sys_munlockall' changed from 8 in 
kernel/built-in.o to 84 in mm/built-in.o
   frv-linux-ld: Warning: size of symbol `sys_swapoff' changed from 8 in 
kernel/built-in.o to 1268 in mm/built-in.o
   frv-linux-ld: Warning: size of symbol `sys_process_vm_writev' changed from 8 
in kernel/built-in.o to 36 in mm/built-in.o
   frv-linux-ld: Warning: size of symbol `sys_memfd_create' changed from 8 in 
kernel/built-in.o to 548 in mm/built-in.o
   frv-linux-ld: Warning: size of symbol `sys_mlock2' changed from 8 in 
kernel/built-in.o to 52 in mm/built-in.o
   frv-linux-ld: Warning: size of symbol `sys_remap_file_pages' changed from 8 
in kernel/built-in.o to 708 in mm/built-in.o
   frv-linux-ld: Warning: size of symbol `sys_fadvise64' changed from 8 in 
kernel/built-in.o to 28 in mm/built-in.o
   frv-linux-ld: Warning: size of symbol `sys_munlock' changed from 8 in 
kernel/built-in.o to 128 in mm/built-in.o
   frv-linux-ld: Warning: size of symbol `sys_mincore' changed from 8 in 
kernel/built-in.o to 596 in mm/built-in.o
   frv-linux-ld: Warning: size of symbol `sys_msync' changed from 8 in 
kernel/built-in.o to 588 in mm/built-in.o
   frv-linux-ld: Warning: size of symbol `sys_swapon' changed from 8 in 
kernel/built-in.o to 3720 in mm/built-in.o
   frv-linux-ld: Warning: size of symbol `sys_madvise' changed from 8 in 
kernel/built-in.o to 1880 in mm/built-in.o
   frv-linux-ld: Warning: size of symbol `sys_process_vm_readv' changed from 8 
in kernel/built-in.o to 32 in mm/built-in.o
   frv-linux-ld: Warning: size of symbol `sys_mlockall' changed from 8 in 
kernel/built-in.o to 356 in mm/built-in.o
   frv-linux-ld: Warning: size of symbol `sys_mprotect' changed from 8 in 
kernel/built-in.o to 624 in mm/built-in.o
   frv-linux-ld: Warning: size of symbol `sys_mlock' changed from 8 in 
kernel/built-in.o to 16 in mm/built-in.o
   frv-linux-ld: Warning: size of symbol `sys_mremap' changed from 8 in 
kernel/built-in.o to 1108 in mm/built-in.o
   frv-linux-ld: Warning: size of symbol `sys_execveat' changed from 8 in 
kernel/built-in.o to 124 in fs/built-in.o
   frv-linux-ld: Warning: size of symbol `sys_signalfd4' changed from 8 in 
kernel/built-in.o to 536 in fs/built-in.o
   frv-linux-ld: Warning: size of symbol `sys_io_setup' changed from 8 in 
kernel/built-in.o to 1984 in fs/built-in.o
   frv-linux-ld: Warning: size of symbol `sys_copy_file_range' changed from 8 
in kernel/built-in.o to 736 in fs/built-in.o
   frv-linux-ld: Warning: size of symbol `sys_io_cancel' changed from 8 in 
kernel/built-in.o to 352 in fs/built-in.o
   frv-linux-ld: Warning: size of symbol `sys_eventfd' changed from 8 in 
kernel/built-in.o to 16 in fs/built-in.o
   frv-linux-ld: Warning: size of symbol `sys_epoll_create' changed from 8 in 
kernel/built-in.o to 32 in fs/built-in.o
   frv-linux-ld: Warning: size of symbol `sys_epoll_pwait' changed from 8 in 
kernel/built-in.o to 400 in fs/built-in.o
   frv-linux-ld: Warning: size of symbol `sys_epoll_ctl' changed from 8 in 
kernel/built-in.o to 2616 in fs/built-in.o
   frv-linux-ld: Warning: size of symbol `sys_open_by_handle_at' changed from 8 
in kernel/built-in.o to 12 in fs/built-in.o
   frv-linux-ld: Warning: size of symbol `sys_epoll_wait' changed from 8 in 
kernel/built-in.o to 1072 in fs/built-in.o
   frv-linux-ld: Warning: size of symbol `sys_inotify_add_watch' changed from 8 
in kernel/built-in.o to 836 in fs/built-in.o
   frv-linux-ld: Warning: size of symbol `sys_sysfs' changed from 8 in 
kernel/built-in.o to 444 in fs/built-in.o
   frv-linux-ld: Warning: size of 

[PATCH v2] spi: spi-sh: Remove deprecated create_singlethread_workqueue

[Bhaktipriya Shridhar]

The workqueue has a single workitem(>ws) and hence doesn't require
ordering. Also, it is not being used on a memory reclaim path. Hence, the
singlethreaded workqueue has been replaced with the use of system_wq.

System workqueues have been able to handle high level of concurrency
for a long time now and hence it's not required to have a singlethreaded
workqueue just to gain concurrency. Unlike a dedicated per-cpu workqueue
created with create_singlethread_workqueue(), system_wq allows multiple
work items to overlap executions even on the same CPU; however, a
per-cpu workqueue doesn't have any CPU locality or global ordering
guarantee unless the target CPU is explicitly specified and thus the
increase of local concurrency shouldn't make any difference.

Work item has been flushed in spi_sh_remove() to ensure that
there are no pending tasks while disconnecting the driver.

Signed-off-by: Bhaktipriya Shridhar 
---
 Changes in v2:
-Fixed build error by correcting parameter passed to flush_work

 drivers/spi/spi-sh.c | 16 +++-
 1 file changed, 3 insertions(+), 13 deletions(-)

diff --git a/drivers/spi/spi-sh.c b/drivers/spi/spi-sh.c
index 5025011..2bf53f0 100644
--- a/drivers/spi/spi-sh.c
+++ b/drivers/spi/spi-sh.c
@@ -82,7 +82,6 @@ struct spi_sh_data {
int irq;
struct spi_master *master;
struct list_head queue;
-   struct workqueue_struct *workqueue;
struct work_struct ws;
unsigned long cr1;
wait_queue_head_t wait;
@@ -380,7 +379,7 @@ static int spi_sh_transfer(struct spi_device *spi, struct 
spi_message *mesg)
spi_sh_clear_bit(ss, SPI_SH_SSA, SPI_SH_CR1);

list_add_tail(>queue, >queue);
-   queue_work(ss->workqueue, >ws);
+   schedule_work(>ws);

spin_unlock_irqrestore(>lock, flags);

@@ -425,7 +424,7 @@ static int spi_sh_remove(struct platform_device *pdev)
struct spi_sh_data *ss = platform_get_drvdata(pdev);

spi_unregister_master(ss->master);
-   destroy_workqueue(ss->workqueue);
+   flush_work(>ws);
free_irq(ss->irq, ss);

return 0;
@@ -484,18 +483,11 @@ static int spi_sh_probe(struct platform_device *pdev)
spin_lock_init(>lock);
INIT_WORK(>ws, spi_sh_work);
init_waitqueue_head(>wait);
-   ss->workqueue = create_singlethread_workqueue(
-   dev_name(master->dev.parent));
-   if (ss->workqueue == NULL) {
-   dev_err(>dev, "create workqueue error\n");
-   ret = -EBUSY;
-   goto error1;
-   }

ret = request_irq(irq, spi_sh_irq, 0, "spi_sh", ss);
if (ret < 0) {
dev_err(>dev, "request_irq error\n");
-   goto error2;
+   goto error1;
}

master->num_chipselect = 2;
@@ -514,8 +506,6 @@ static int spi_sh_probe(struct platform_device *pdev)

  error3:
free_irq(irq, ss);
- error2:
-   destroy_workqueue(ss->workqueue);
  error1:
spi_master_put(master);

--
2.1.4

Re: How to set Current register in IIO driver from sysfs

[Jonathan Cameron]

On 10/07/16 14:11, Pratik Prajapati wrote:
> Including more members.
> 
> On Sat, Jul 9, 2016 at 5:22 PM, Pratik Prajapati
>  wrote:
>> Hi,
hi Pratik,
>>
>> I am trying to add support of adjusting IR led current in vcnl4000
>> driver (has IR led current register for doing the same).
This is always a bit of a 'rough' corner when it comes to what interface
to do it with.  Strictly speaking this is typically just a regulator that
happens to be used for this special purpose.  Sometimes they are tightly
tied together with the input and sometime (on devices with more than one)
there is no explicit linkage at all.

In this particular case we seem to actually have a high frequency modulated
LED driver so it's pretty tightly tied to this use.
>>
>> Below is what I have done till now:
>>
>> 1) Added Current channel in the vcnl4000_channels structure with
>> separate mask IIO_CHAN_INFO_RAW
>> 2) Reading the LED current register inside IIO_CURRENT case in 
>> vcnl4010_read_raw
>> 3) Writing to LED current register inside IIO_CURRENT case in 
>> vcnl4010_write_raw
>>
>> Is this the correct way of setting Current register in IIO subsystem?
That's about the best option we currently have. This is exactly how it's done
in the max44000 driver for example.
 
It's not an interface anyone is terribly happy with so you are welcome to
suggestion alternatives (easy to add them as an additional interface to
existing cases - which is why we haven't been that worried about ending up
with the current less than ideal interface)
The tight coupling in this particular case might justify something more
explicitly linked to the proximity channel but as noted above it's not
always that obvious (see the health/afe parts for example which are way
too flexible in my view!)

Jonathan


>>
>> Best Regards,
>> Pratik Prajapati
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Odd performance results

[Paul E. McKenney]

On Sun, Jul 10, 2016 at 07:17:19AM +0200, Peter Zijlstra wrote:
> 
> 
> On 10 July 2016 06:26:39 CEST, "Paul E. McKenney" 
>  wrote:
> >Hello!
> >
> >So I ran a quick benchmark which showed stair-step results.  I
> >immediately
> >thought "Ah, this is due to CPU 0 and 1, 2 and 3, 4 and 5, and 6 and 7
> >being threads in a core."  Then I thought "Wait, this is an x86!"
> >Then I dumped out cpu*/topology/thread_siblings_list, getting the
> >following:
> >
> > cpu0/topology/thread_siblings_list: 0-1
> > cpu1/topology/thread_siblings_list: 0-1
> > cpu2/topology/thread_siblings_list: 2-3
> > cpu3/topology/thread_siblings_list: 2-3
> > cpu4/topology/thread_siblings_list: 4-5
> > cpu5/topology/thread_siblings_list: 4-5
> > cpu6/topology/thread_siblings_list: 6-7
> > cpu7/topology/thread_siblings_list: 6-7
> 
> 
> I'm guessing this is an AMD bulldozer like machine?

/proc/cpuinfo thinks otherwise:

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 60
model name  : Intel(R) Core(TM) i7-4710MQ CPU @ 2.50GHz
stepping: 3
microcode   : 0x1c
cpu MHz : 800.000
cache size  : 6144 KB
physical id : 0
siblings: 8
core id : 0
cpu cores   : 4
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb 
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 
ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes 
xsave avx f16c rdrand lahf_lm abm ida arat epb xsaveopt pln pts dtherm 
tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 
erms invpcid
bogomips: 4988.59
clflush size: 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 60
model name  : Intel(R) Core(TM) i7-4710MQ CPU @ 2.50GHz
stepping: 3
microcode   : 0x1c
cpu MHz : 800.000
cache size  : 6144 KB
physical id : 0
siblings: 8
core id : 0
cpu cores   : 4
apicid  : 1
initial apicid  : 1
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb 
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 
ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes 
xsave avx f16c rdrand lahf_lm abm ida arat epb xsaveopt pln pts dtherm 
tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 
erms invpcid
bogomips: 4988.59
clflush size: 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor   : 2
vendor_id   : GenuineIntel
cpu family  : 6
model   : 60
model name  : Intel(R) Core(TM) i7-4710MQ CPU @ 2.50GHz
stepping: 3
microcode   : 0x1c
cpu MHz : 800.000
cache size  : 6144 KB
physical id : 0
siblings: 8
core id : 1
cpu cores   : 4
apicid  : 2
initial apicid  : 2
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb 
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 
ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes 
xsave avx f16c rdrand lahf_lm abm ida arat epb xsaveopt pln pts dtherm 
tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 
erms invpcid
bogomips: 4988.59
clflush size: 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor   : 3
vendor_id   : GenuineIntel
cpu family  : 6
model   : 60
model name  : Intel(R) Core(TM) i7-4710MQ CPU @ 2.50GHz
stepping: 3
microcode   : 0x1c
cpu MHz : 800.000
cache size  : 6144 KB
physical id : 0
siblings: 8
core id : 1
cpu cores   : 4
apicid  : 3
initial apicid  : 3
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm 

Re: [PATCH v2 2/2] input: add ADC resistor ladder driver

[Jonathan Cameron]

On 09/07/16 02:24, Alexandre Belloni wrote:
> A common way of multiplexing buttons on a single input in cheap devices is
> to use a resistor ladder on an ADC. This driver supports that configuration
> by polling an ADC channel provided by IIO.
> 
> Signed-off-by: Alexandre Belloni 
Acked-by: Jonathan Cameron 
> ---
> Changes in v2:
>  - removed dependency on COMPILE_TEST which is not useful anyway
>  - use new bindings
> 
>  drivers/input/keyboard/Kconfig|  15 +++
>  drivers/input/keyboard/Makefile   |   1 +
>  drivers/input/keyboard/adc-keys.c | 210 
> ++
>  3 files changed, 226 insertions(+)
>  create mode 100644 drivers/input/keyboard/adc-keys.c
> 
> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
> index 509608c95994..4cf042cc5e63 100644
> --- a/drivers/input/keyboard/Kconfig
> +++ b/drivers/input/keyboard/Kconfig
> @@ -12,6 +12,21 @@ menuconfig INPUT_KEYBOARD
>  
>  if INPUT_KEYBOARD
>  
> +config KEYBOARD_ADC
> + tristate "ADC ladder Buttons"
> + depends on IIO
> + select INPUT_POLLDEV
> + help
> +   This driver implements support for buttons connected
> +   to an ADC using a resistor ladder.
> +
> +   Say Y here if your device has such buttons connected to an ADC.  Your
> +   board-specific setup logic must also provide a configuration data
> +   saying mapping voltages to buttons.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called adc_keys.
> +
>  config KEYBOARD_ADP5520
>   tristate "Keypad Support for ADP5520 PMIC"
>   depends on PMIC_ADP5520
> diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
> index 1d416ddf84e4..d9f4cfcf3410 100644
> --- a/drivers/input/keyboard/Makefile
> +++ b/drivers/input/keyboard/Makefile
> @@ -4,6 +4,7 @@
>  
>  # Each configuration option enables a list of files.
>  
> +obj-$(CONFIG_KEYBOARD_ADC)   += adc-keys.o
>  obj-$(CONFIG_KEYBOARD_ADP5520)   += adp5520-keys.o
>  obj-$(CONFIG_KEYBOARD_ADP5588)   += adp5588-keys.o
>  obj-$(CONFIG_KEYBOARD_ADP5589)   += adp5589-keys.o
> diff --git a/drivers/input/keyboard/adc-keys.c 
> b/drivers/input/keyboard/adc-keys.c
> new file mode 100644
> index ..cf299ff517a0
> --- /dev/null
> +++ b/drivers/input/keyboard/adc-keys.c
> @@ -0,0 +1,210 @@
> +/* Input driver for resistor ladder connected on ADC
> + *
> + * Copyright (c) 2016 Alexandre Belloni
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct adc_keys_button {
> + u32 voltage;
> + u32 keycode;
> +};
> +
> +struct adc_keys_state {
> + struct iio_channel *channel;
> + u32 num_keys;
> + u32 last_key;
> + u32 keyup_voltage;
> + struct adc_keys_button *map;
> +};
> +
> +static void adc_keys_poll(struct input_polled_dev *dev)
> +{
> + struct adc_keys_state *st = dev->private;
> + int i, value, ret;
> + u32 diff, closest = 0x;
> + int keycode = 0;
> +
> + ret = iio_read_channel_processed(st->channel, );
> + if (ret < 0) {
> + if (st->last_key) {
> + input_report_key(dev->input, st->last_key, 0);
> + input_sync(dev->input);
> + st->last_key = 0;
> + }
> + return;
> + }
> +
> + for (i = 0; i < st->num_keys; i++) {
> + diff = abs(st->map[i].voltage - value);
> + if (diff < closest) {
> + closest = diff;
> + keycode = st->map[i].keycode;
> + }
> + }
> +
> + if (abs(st->keyup_voltage - value) < closest) {
> + input_report_key(dev->input, st->last_key, 0);
> + st->last_key = 0;
> + } else {
> + if (st->last_key && st->last_key != keycode)
> + input_report_key(dev->input, st->last_key, 0);
> + input_report_key(dev->input, keycode, 1);
> + st->last_key = keycode;
> + }
> +
> + input_sync(dev->input);
> +}
> +
> +static int adc_keys_load_dt_keymap(struct device *dev,
> +struct adc_keys_state *st)
> +{
> + struct device_node *pp, *np = dev->of_node;
> + int i;
> +
> + st->num_keys = of_get_child_count(np);
> + if (st->num_keys == 0) {
> + dev_err(dev, "keymap is missing\n");
> + return -EINVAL;
> + }
> +
> + st->map = devm_kmalloc_array(dev, st->num_keys, sizeof(*st->map),
> +  GFP_KERNEL);
> + if (!st->map)
> + return -ENOMEM;
> +
> +  

Re: [PATCH v2 1/2] input: adc-keys: add DT binding documentation

[Jonathan Cameron]

On 09/07/16 02:24, Alexandre Belloni wrote:
> Add documentation for ADC keys
> 
> Signed-off-by: Alexandre Belloni 
I'm seeing a few more properties in the driver.  They may be generic
input ones, but should still be listed here...

autorepeat for example.

> ---
> Changes in v2:
>  - fix title
>  - use keyup-threshold-mvolt and press-threshold-mvolt instead of
>voltage-keyup-mvolt and voltage-mvolt.
> 
>  .../devicetree/bindings/input/adc-keys.txt | 45 
> ++
>  1 file changed, 45 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/input/adc-keys.txt
> 
> diff --git a/Documentation/devicetree/bindings/input/adc-keys.txt 
> b/Documentation/devicetree/bindings/input/adc-keys.txt
> new file mode 100644
> index ..e43b8979b85a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/adc-keys.txt
> @@ -0,0 +1,45 @@
> +ADC attached resistor ladder buttons
> +
> +
> +Required properties:
> + - compatible: "adc-keys"
> + - io-channels: Phandle to an ADC channel
> + - io-channel-names = "buttons";
> + - keyup-threshold-mvolt: Voltage at which all the keys are considered up.
> +
> +Each key is represented as a sub-node of "adc-keys":
> +
> +Required subnode-properties:
> + - label: Descriptive name of the key.
> + - linux,code: Keycode to emit.
> + - press-threshold-mvolt: Voltage adc input when this key is pressed.
> +
> +Example:
> +
> +#include 
> +
> + adc-keys {
> + compatible = "adc-keys";
> + io-channels = < 0>;
> + io-channel-names = "buttons";
> + keyup-threshold-mvolt = <2000>;
> +
> + button@1500 {
> + label = "Volume Up";
> + linux,code = ;
> + press-threshold-mvolt = <1500>;
> + };
> +
> + button@1000 {
> + label = "Volume Down";
> + linux,code = ;
> + press-threshold-mvolt = <1000>;
> + };
> +
> + button@500 {
> + label = "Enter";
> + linux,code = ;
> + press-threshold-mvolt = <500>;
> + };
> + };
> +
> 

[tip:irq/core] irq/Documentation: Correct result of echnoing 5 to smp_affinity

[tip-bot for John Kacur]

Commit-ID:  99e9d958726c04cec3e36902d8583fdd8cb5b1bb
Gitweb: http://git.kernel.org/tip/99e9d958726c04cec3e36902d8583fdd8cb5b1bb
Author: John Kacur 
AuthorDate: Fri, 17 Jun 2016 15:05:15 +0200
Committer:  Ingo Molnar 
CommitDate: Sun, 10 Jul 2016 16:55:04 +0200

irq/Documentation: Correct result of echnoing 5 to smp_affinity

This command:

  echo 5 > /proc/irq/10/smp_affinity

means only the first and third (not fourth) CPUs can handle irqs
That is, CPU0 is the first CPU and CPU2 is the third cpu

Signed-off-by: John Kacur 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1466168715-8410-1-git-send-email-jka...@redhat.com
Signed-off-by: Ingo Molnar 
---
 Documentation/filesystems/proc.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/filesystems/proc.txt 
b/Documentation/filesystems/proc.txt
index e8d0075..5b61eea 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -725,7 +725,7 @@ IRQ, you can set it by doing:
   > echo 1 > /proc/irq/10/smp_affinity
 
 This means that only the first CPU will handle the IRQ, but you can also echo
-5 which means that only the first and fourth CPU can handle the IRQ.
+5 which means that only the first and third CPU can handle the IRQ.
 
 The contents of each smp_affinity file is the same by default:
 

Re: [tip:x86/boot] x86/KASLR: Fix boot crash with certain memory configurations

[Baoquan He]

On 07/10/16 at 01:24pm, Ingo Molnar wrote:
> 
> * Baoquan He  wrote:
> 
> > Hi Ingo,
> > 
> > I am sorry the previous post didn't contain formal patch log. I made a new 
> > one 
> > as below. The boot crash could not only happen with certain memory. Because 
> > of 
> > this code bug the regions which need be avoided like the zipped kernel with 
> > its 
> > unzipping running code, initrd, kernel command line could be corrupted if 
> > mem_avoid_overlap() can't find the overlap region with the lowest address. 
> > But 
> > it's very lucky that Xiaolong's system which has only 300M memory can 
> > always 
> > reproduce it. I checked the boog log and found on his system no any other 
> > slot 
> > can be chosen except for the original one. If we have a system with large 
> > memory 
> > it may not be easy to hit it, at least with low probability since there are 
> > many 
> > candidate slots.
> 
> So if it's just a better changelog that what I wrote I wouldn't rebase the 
> commit: 
> there's other commits on top of the fix meanwhile. Should a rebase become 
> necessary at a later point I'll update it with your extended changelog.

Yes, it's just a changelog update, no need to rebase it now.

Thanks
Baoquan

Linux 4.7: Reported regressions as of Sunday, 2016-07-10

[Thorsten Leemhuis]

Hi! Here is my fifth regression report for Linux 4.7. It lists 10
regressions I'm currently aware of; 2 of them are new; 1 of those 
seems to be a a side effect of a fix for another regression.

The report also mentions 3 regression that I removed from the list, as
it looks like those issues are no regressions.

Find also details on 4 regressions that were fixed since the last
report(¹)

As usual: Please let me know about any regression missing on the list  
or if it contains something which shouldn't be there.

HTH, CU, Thorsten

(¹) previous reports can be found at
http://thread.gmane.org/gmane.linux.kernel/2241805
http://thread.gmane.org/gmane.linux.kernel/2247804
http://thread.gmane.org/gmane.linux.kernel/2253623
http://thread.gmane.org/gmane.linux.kernel/2258287

== Current regressions ==

Desc: Bad flicker on skylake HQD due to code in the 4.7 merge window
Repo: 2016-05-30 http://thread.gmane.org/gmane.linux.kernel/2230377
Stat: 2016-07-08 http://thread.gmane.org/gmane.linux.kernel/2230377/focus=94140
Note: vswing issue, maybe primary a Firmware problem; a few patches improved 
situation, but did not fix the problem

Desc: 795ae7a0de: pixz.throughput -9.1% regression
Repo: 2016-06-02 http://thread.gmane.org/gmane.linux.kernel/2233056/
Stat: 2016-06-22 
http://thread.gmane.org/gmane.linux.kernel/2233056/focus=2251134
Note: hannes still can't reproduce; stalled until reporter posts results from 
more tests

Desc: System hang when plug/un-plug USB 3.1 key via thunderbolt port on Dell 
XPS 13
Repo: 2016-06-14 https://bugzilla.kernel.org/show_bug.cgi?id=120241
Stat: 2016-07-08 https://bugzilla.kernel.org/show_bug.cgi?id=120241#c7
Note: there was wip, but root cause hard to track down; responsible developer 
now afk till early August

Desc: regression in 8250 uart driver
Repo: 2016-06-14 
http://thread.gmane.org/gmane.linux.kernel/2243130/focus=2243653
Stat: 2016-07-02 
http://thread.gmane.org/gmane.linux.kernel/2243130/focus=2258232
Note: andy has it still on his todo list, but something else has a higher 
priority

Desc: Multi-thread udp 4.7 regression, bisected to 71d8c47fc653; performance 
decreased or complete failure with a test
Repo: 2016-06-27 http://thread.gmane.org/gmane.linux.network/418861/focus=418908
Stat: 2016-07-05 http://thread.gmane.org/gmane.linux.network/418861/focus=63936
Note: waiting for feedback from reporter

Desc: kmemcheck: Caught 64-bit read from uninitialized memory; 
iptables/nf_register_net_hooks
Repo: 2016-06-19 https://bugzilla.kernel.org/show_bug.cgi?id=120651
Stat: 2016-07-02 
Note: afaics stalled, after I told reporter a week ago how to contact the 
relevant developers

Desc: UBSAN splat in drivers/acpi/acpica/dsutils.c:641:16
Repo: 2016-06-15 https://bugzilla.kernel.org/show_bug.cgi?id=120351
Stat: 2016-06-22 https://bugzilla.kernel.org/show_bug.cgi?id=120411#c3
Note: wonder if this is important enough to investigate further; related, 
similar bugs: https://bugzilla.kernel.org/show_bug.cgi?id=120411 
https://bugzilla.kernel.org/show_bug.cgi?id=120391 
https://bugzilla.kernel.org/show_bug.cgi?id=120371 
https://bugzilla.kernel.org/show_bug.cgi?id=120361 Not sure which of them are 
regressions

Desc: Kernel does not boot with 7ed18e2d1b6782989eb399ef79a8cc1a1b583b3c ( 
acpi-4.7-rc7 aka All of these fix recent regressions in ACPICA, in the ACPI PCI 
IRQ management code and in the ACPI AML debugger.)
Repo: 2016-07-08 https://bugzilla.kernel.org/show_bug.cgi?id=121701
Stat: 2016-07-10 
http://thread.gmane.org/gmane.linux.kernel.pci/53279/focus=85652
Note: pointed Rafael to bugzilla on LKML

Desc: ACPI EC problems/ ACPI / EC: Fix an order issue in ec_remove_handlers()
Repo: 2016-07-06 http://thread.gmane.org/gmane.linux.kernel/2260279/
Stat: 2016-07-08 http://thread.gmane.org/gmane.linux.kernel/2260279/focus=85583
Note: patch under discussion


== Going to me removed from the list ==

Desc: RadeonSI get a huge performance dip with used with the nine state tracker
Repo: 2016-06-04 https://bugzilla.kernel.org/show_bug.cgi?id=119631
Stat: 2016-07-04 https://bugzilla.kernel.org/show_bug.cgi?id=119631#c14
Note: not a regression according to one of the AMD graphic driver developers; 
otoh it looks like one to me; yes, the real bug is in the gallium nine, wine 
side, but afaics it only showed up after a kernel change introduced a new 
feature

Desc: performance drop on SFC interface around 30 %
Repo: 2016-06-17 https://bugzilla.kernel.org/show_bug.cgi?id=120461
Stat: 2016-07-06 https://bugzilla.kernel.org/show_bug.cgi?id=120461#c20
Note: reporter and developer agree: not a regression in 4.7

Desc: Rename file corruption due to VFS-Changes?
Repo: 2016-06-16 http://thread.gmane.org/gmane.linux.kernel/2245402/
Stat: 2016-06-22 
http://thread.gmane.org/gmane.linux.kernel/2245402/focus=2250254
Note: issue likely fixed in mainline by 9f541801 + e7d6ef979; see also: 
http://thread.gmane.org/gmane.linux.kernel/2231928/focus=76124


== Fixed since last report ==

Desc: BUG: unable to handle 

Re: [PATCH 2/2] net: ethernet: bcmgenet: use phy_ethtool_{get|set}_link_ksettings

[Philippe Reynes]

Hi all,


On 05/07/16 23:40, Ben Hutchings wrote:

On Tue, 2016-07-05 at 14:15 -0700, Florian Fainelli wrote:

On 07/05/2016 02:07 PM, Philippe Reynes wrote:

Hi Florian,

On 05/07/16 06:30, Florian Fainelli wrote:

Le 04/07/2016 16:03, David Miller a écrit :

From: Philippe Reynes
Date: Sun,  3 Jul 2016 17:33:57 +0200


There are two generics functions phy_ethtool_{get|set}_link_ksettings,
so we can use them instead of defining the same code in the driver.

Signed-off-by: Philippe Reynes


Applied.



The transformation is not equivalent, we lost the checks on
netif_running() in the process, and those are here for a reason, if the
interface is down and therefore clock gated, MDIO accesses to the PHY
will simply fail outright and cause bus errors.


Oh, I see, I've missed this. Sorry for this mistake.
We should revert this path.


Well, maybe better than that, actually put the check in the generic
functions, because if the link is down, aka netif_running() returns
false, link parameters cannot be reliably queried and they are invalid.


In my understanding, if the link is down, the pointer phydev in the
struct net_device is NULL. So generic functions 
phy_ethtool_{get|set}_link_ksetting
should return -ENODEV.

If I'm wrong, and it everybody agree, I'll send a patch that add a check
on netif_running.


Either the hardware or the driver needs to remember:

- Is auto-negotiation enabled
- If so, which modes are advertised
- If not, which mode is forced

And it should still be possible to get or set that information when the
interface is down.


It could be possible to save the set_link_ksettings request if the link
is down, and apply it when the link become up.
It also could be possible to save the last state of the link before it
goes to down, and return it to a get_link_ksettings when the link is down.
But what happen if the link was never up before the first get_link_kettings ?

If everybody agree with this, I may send a patch that implement this idea.


Philippe

[PATCH] tmpfs: fix regression hang in fallocate undo

[Hugh Dickins]

The well-spotted fallocate undo fix is good in most cases, but not when
fallocate failed on the very first page.  index 0 then passes lend -1
to shmem_undo_range(), and that has two bad effects: (a) that it will
undo every fallocation throughout the file, unrestricted by the current
range; but more importantly (b) it can cause the undo to hang, because
lend -1 is treated as truncation, which makes it keep on retrying until
every page has gone, but those already fully instantiated will never go
away.  Big thank you to xfstests generic/269 which demonstrates this.

Fixes: b9b4bb26af01 ("tmpfs: don't undo fallocate past its last page")
Cc: sta...@vger.kernel.org
Signed-off-by: Hugh Dickins 
---

 mm/shmem.c |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

--- 4.7-rc6/mm/shmem.c  2016-06-26 22:02:27.543373427 -0700
+++ linux/mm/shmem.c2016-07-10 15:19:24.0 -0700
@@ -2225,9 +2225,11 @@ static long shmem_fallocate(struct file
error = shmem_getpage(inode, index, , SGP_FALLOC);
if (error) {
/* Remove the !PageUptodate pages we added */
-   shmem_undo_range(inode,
-   (loff_t)start << PAGE_SHIFT,
-   ((loff_t)index << PAGE_SHIFT) - 1, true);
+   if (index > start) {
+   shmem_undo_range(inode,
+   (loff_t)start << PAGE_SHIFT,
+   ((loff_t)index << PAGE_SHIFT) - 1, true);
+   }
goto undone;
}
 

Re: [PATCH] include: mman: Use bool instead of int for the return value of arch_validate_prot

[Dave Hansen]

On 07/09/2016 09:29 AM, cheng...@emindsoft.com.cn wrote:
> -static inline int arch_validate_prot(unsigned long prot)
> +static inline bool arch_validate_prot(unsigned long prot)
>  {
>   if (prot & ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM | PROT_SAO))
> - return 0;
> - if ((prot & PROT_SAO) && !cpu_has_feature(CPU_FTR_SAO))
> - return 0;
> - return 1;
> + return false;
> + return (prot & PROT_SAO) == 0 || cpu_has_feature(CPU_FTR_SAO);
>  }
>  #define arch_validate_prot(prot) arch_validate_prot(prot)

Please don't do things like this.  They're not obviously correct and
also have no obvious benefit.  You also don't mention why you bothered
to alter the logical structure of these checks.

Re: [PATCH 01/16] gpu: ipu-v3: Add Video Deinterlacer unit

[Paul Gortmaker]

On Thu, Jul 7, 2016 at 7:03 PM, Steve Longerbeam  wrote:
> Adds the Video Deinterlacer (VDIC) unit.
>
> Signed-off-by: Steve Longerbeam 
> ---
>  drivers/gpu/ipu-v3/Makefile |   2 +-
>  drivers/gpu/ipu-v3/ipu-common.c |  11 ++
>  drivers/gpu/ipu-v3/ipu-prv.h|   6 +
>  drivers/gpu/ipu-v3/ipu-vdi.c| 266 
> 
>  include/video/imx-ipu-v3.h  |  27 
>  5 files changed, 311 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/ipu-v3/ipu-vdi.c
>
> diff --git a/drivers/gpu/ipu-v3/Makefile b/drivers/gpu/ipu-v3/Makefile
> index 107ec23..aeba9dc 100644
> --- a/drivers/gpu/ipu-v3/Makefile
> +++ b/drivers/gpu/ipu-v3/Makefile
> @@ -1,4 +1,4 @@
>  obj-$(CONFIG_IMX_IPUV3_CORE) += imx-ipu-v3.o
>
>  imx-ipu-v3-objs := ipu-common.o ipu-cpmem.o ipu-csi.o ipu-dc.o ipu-di.o \
> -   ipu-dp.o ipu-dmfc.o ipu-ic.o ipu-smfc.o
> +   ipu-dp.o ipu-dmfc.o ipu-ic.o ipu-smfc.o ipu-vdi.o
> diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
> index 99dcacf..30dc115 100644
> --- a/drivers/gpu/ipu-v3/ipu-common.c
> +++ b/drivers/gpu/ipu-v3/ipu-common.c
> @@ -833,6 +833,14 @@ static int ipu_submodules_init(struct ipu_soc *ipu,
> goto err_ic;
> }
>
> +   ret = ipu_vdi_init(ipu, dev, ipu_base + devtype->vdi_ofs,
> +  IPU_CONF_VDI_EN | IPU_CONF_ISP_EN |
> +  IPU_CONF_IC_INPUT);
> +   if (ret) {
> +   unit = "vdi";
> +   goto err_vdi;
> +   }
> +
> ret = ipu_di_init(ipu, dev, 0, ipu_base + devtype->disp0_ofs,
>   IPU_CONF_DI0_EN, ipu_clk);
> if (ret) {
> @@ -887,6 +895,8 @@ err_dc:
>  err_di_1:
> ipu_di_exit(ipu, 0);
>  err_di_0:
> +   ipu_vdi_exit(ipu);
> +err_vdi:
> ipu_ic_exit(ipu);
>  err_ic:
> ipu_csi_exit(ipu, 1);
> @@ -971,6 +981,7 @@ static void ipu_submodules_exit(struct ipu_soc *ipu)
> ipu_dc_exit(ipu);
> ipu_di_exit(ipu, 1);
> ipu_di_exit(ipu, 0);
> +   ipu_vdi_exit(ipu);
> ipu_ic_exit(ipu);
> ipu_csi_exit(ipu, 1);
> ipu_csi_exit(ipu, 0);
> diff --git a/drivers/gpu/ipu-v3/ipu-prv.h b/drivers/gpu/ipu-v3/ipu-prv.h
> index bfb1e8a..845f64c 100644
> --- a/drivers/gpu/ipu-v3/ipu-prv.h
> +++ b/drivers/gpu/ipu-v3/ipu-prv.h
> @@ -138,6 +138,7 @@ struct ipu_dc_priv;
>  struct ipu_dmfc_priv;
>  struct ipu_di;
>  struct ipu_ic_priv;
> +struct ipu_vdi;
>  struct ipu_smfc_priv;
>
>  struct ipu_devtype;
> @@ -169,6 +170,7 @@ struct ipu_soc {
> struct ipu_di   *di_priv[2];
> struct ipu_csi  *csi_priv[2];
> struct ipu_ic_priv  *ic_priv;
> +   struct ipu_vdi  *vdi_priv;
> struct ipu_smfc_priv*smfc_priv;
>  };
>
> @@ -199,6 +201,10 @@ int ipu_ic_init(struct ipu_soc *ipu, struct device *dev,
> unsigned long base, unsigned long tpmem_base);
>  void ipu_ic_exit(struct ipu_soc *ipu);
>
> +int ipu_vdi_init(struct ipu_soc *ipu, struct device *dev,
> +unsigned long base, u32 module);
> +void ipu_vdi_exit(struct ipu_soc *ipu);
> +
>  int ipu_di_init(struct ipu_soc *ipu, struct device *dev, int id,
> unsigned long base, u32 module, struct clk *ipu_clk);
>  void ipu_di_exit(struct ipu_soc *ipu, int id);
> diff --git a/drivers/gpu/ipu-v3/ipu-vdi.c b/drivers/gpu/ipu-v3/ipu-vdi.c
> new file mode 100644
> index 000..1303bcc
> --- /dev/null
> +++ b/drivers/gpu/ipu-v3/ipu-vdi.c
> @@ -0,0 +1,266 @@
> +/*
> + * Copyright (C) 2012 Mentor Graphics Inc.
> + * Copyright (C) 2005-2009 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
> + * or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
> + * for more details.
> + */
> +#include 
> +#include 

You have a u32 field in a struct called "modules" but aside from that, I do not
see anything in this code requiring module.h -- did I miss something?

You might want export.h for EXPORT_SYMBOL though.

Paul.
--

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "ipu-prv.h"
> +

[...]

Re: [PATCH] mm: migrate: Use bool instead of int for the return value of PageMovable

[Minchan Kim]

On Sat, Jul 09, 2016 at 11:55:04PM +0800, cheng...@emindsoft.com.cn wrote:
> From: Chen Gang 
> 
> For pure bool function's return value, bool is a little better more or
> less than int.
> 
> And return boolean result directly, since 'if' statement is also for
> boolean checking, and return boolean result, too.

I just wanted to consistent with other PageXXX flags functions, PageAnon,
PageMappingFlags which returns int rather than bool. Although I agree bool
is natural, I want to be consistent with others rather than breaking at
the moment.

Maybe if you feel it's really helpful, you might be able to handle all
of places I mentioned for better readability and keeping consistency.
But I doubt it's worth.

Thanks.

> 
> Signed-off-by: Chen Gang 

> ---
>  include/linux/migrate.h | 4 ++--
>  mm/compaction.c | 9 +++--
>  2 files changed, 5 insertions(+), 8 deletions(-)
> 
> diff --git a/include/linux/migrate.h b/include/linux/migrate.h
> index ae8d475..0e366f8 100644
> --- a/include/linux/migrate.h
> +++ b/include/linux/migrate.h
> @@ -72,11 +72,11 @@ static inline int migrate_huge_page_move_mapping(struct 
> address_space *mapping,
>  #endif /* CONFIG_MIGRATION */
>  
>  #ifdef CONFIG_COMPACTION
> -extern int PageMovable(struct page *page);
> +extern bool PageMovable(struct page *page);
>  extern void __SetPageMovable(struct page *page, struct address_space 
> *mapping);
>  extern void __ClearPageMovable(struct page *page);
>  #else
> -static inline int PageMovable(struct page *page) { return 0; };
> +static inline bool PageMovable(struct page *page) { return false; };
>  static inline void __SetPageMovable(struct page *page,
>   struct address_space *mapping)
>  {
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 0bd53fb..cfcfe88 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -95,19 +95,16 @@ static inline bool migrate_async_suitable(int migratetype)
>  
>  #ifdef CONFIG_COMPACTION
>  
> -int PageMovable(struct page *page)
> +bool PageMovable(struct page *page)
>  {
>   struct address_space *mapping;
>  
>   VM_BUG_ON_PAGE(!PageLocked(page), page);
>   if (!__PageMovable(page))
> - return 0;
> + return false;
>  
>   mapping = page_mapping(page);
> - if (mapping && mapping->a_ops && mapping->a_ops->isolate_page)
> - return 1;
> -
> - return 0;
> + return mapping && mapping->a_ops && mapping->a_ops->isolate_page;
>  }
>  EXPORT_SYMBOL(PageMovable);
>  
> -- 
> 1.9.3
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

Re: [PATCH 5/7] drm/rockchip: dw-mipi: support HPD poll

[Mark yao]

On 2016年07月08日 21:52, John Keeping wrote:

On Fri,  8 Jul 2016 17:04:59 +0800, Chris Zhong wrote:


At the first time of bind, there is no any panel attach in mipi. Add a
DRM_CONNECTOR_POLL_HPD porperty to detect the panel status, when panel
probe, the dw_mipi_dsi_host_attach would be called, then mipi-dsi will
trigger a event to notify the drm framework.

Signed-off-by: Chris Zhong 

Can we do something like this instead?  We know that the panel must
always be attached and this has the advantage that the display size will
be known when the framebuffer console loads.

-- >8 --
Subject: [PATCH] drm/rockchip: dw-mipi-dsi: defer probe if panel is not loaded

This ensures that the output resolution is known before fbcon loads.

Signed-off-by: John Keeping 
---
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 11 +--
  1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 6ef5f3be8468..c0499266d116 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -1154,10 +1154,17 @@ static int dw_mipi_dsi_bind(struct device *dev, struct 
device *master,
  
  	dsi->dsi_host.ops = _mipi_dsi_host_ops;

dsi->dsi_host.dev = dev;
-   return mipi_dsi_host_register(>dsi_host);
+   ret = mipi_dsi_host_register(>dsi_host);
+   if (!ret && !dsi->panel) {
+   mipi_dsi_host_unregister(>dsi_host);
+   drm_encoder_cleanup(>encoder);
+   drm_connector_cleanup(>connector);
+   ret = -EPROBE_DEFER;


Hi John

Do you verify this patch? I do the similar change before, but found 
panel can't probe.


mipi_dsi_host_register will call device_add, I think the panel probe 
need this.


Seems that mipi panel probe request mipi_dsi_host_register, 
mipi_dsi_host_register request panel on your patch, endless loop.


Thanks.


+   }
  
  err_pllref:

-   clk_disable_unprepare(dsi->pllref_clk);
+   if (ret)
+   clk_disable_unprepare(dsi->pllref_clk);
return ret;
  }
  







--
Ｍark Yao

Re: [PATCH 00/31] Move LRU page reclaim from zones to nodes v8

[Dave Chinner]

On Fri, Jul 08, 2016 at 10:52:03AM +0100, Mel Gorman wrote:
> On Fri, Jul 08, 2016 at 09:27:13AM +1000, Dave Chinner wrote:
> > .
> > > This series is not without its hazards. There are at least three areas
> > > that I'm concerned with even though I could not reproduce any problems in
> > > that area.
> > > 
> > > 1. Reclaim/compaction is going to be affected because the amount of 
> > > reclaim is
> > >no longer targetted at a specific zone. Compaction works on a per-zone 
> > > basis
> > >so there is no guarantee that reclaiming a few THP's worth page pages 
> > > will
> > >have a positive impact on compaction success rates.
> > > 
> > > 2. The Slab/LRU reclaim ratio is affected because the frequency the 
> > > shrinkers
> > >are called is now different. This may or may not be a problem but if it
> > >is, it'll be because shrinkers are not called enough and some balancing
> > >is required.
> > 
> > Given that XFS has a much more complex set of shrinkers and has a
> > much more finely tuned balancing between LRU and shrinker reclaim,
> > I'd be interested to see if you get the same results on XFS for the
> > tests you ran on ext4. It might also be worth running some highly
> > concurrent inode cache benchmarks (e.g. the 50-million inode, 16-way
> > concurrent fsmark tests) to see what impact heavy slab cache
> > pressure has on shrinker behaviour and system balance...
> > 
> 
> I had tested XFS with earlier releases and noticed no major problems
> so later releases tested only one filesystem.  Given the changes since,
> a retest is desirable. I've posted the current version of the series but
> I'll queue the tests to run over the weekend. They are quite time consuming
> to run unfortunately.

Understood. I'm not following the patchset all that closely, so I
didn' know you'd already tested XFS.

> On the fsmark configuration, I configured the test to use 4K files
> instead of 0-sized files that normally would be used to stress inode
> creation/deletion. This is to have a mix of page cache and slab
> allocations. Shout if this does not suit your expectations.

Sounds fine. I usually limit that test to 10 million inodes - that's
my "10-4" test.

> Finally, not all the machines I'm using can store 50 million inodes
> of this size. The benchmark has been configured to use as many inodes
> as it estimates will fit in the disk. In all cases, it'll exert memory
> pressure. Unfortunately, the storage is simple so there is no guarantee
> it'll find all problems but that's standard unfortunately.

Yup. But it's really the system balance that matters, and if the
balance is maintained then XFS will optimise the IO patterns to get
decent throughput regardless of the storage (i.e. the 10-4 test
should still run at tens of MB/s on a single spinning disk).

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [PATCH 0/2 v3] Add pl031 RTC support for Hi6220

[Guodong Xu]

On 7 July 2016 at 08:58, John Stultz  wrote:
> On Wed, Jul 6, 2016 at 12:38 AM, Arnd Bergmann  wrote:
>> On Wednesday, July 6, 2016 12:20:15 AM CEST John Stultz wrote:
>>> On Wed, Jul 6, 2016 at 12:04 AM, Olof Johansson  wrote:
>>> > On Tue, Jul 5, 2016 at 11:55 PM, John Stultz  
>>> > wrote:
>>> >> On Tue, Jul 5, 2016 at 10:22 PM, Olof Johansson  wrote:
>>> >>> On Wed, Jun 29, 2016 at 05:48:43PM -0700, John Stultz wrote:
>>>  This patchset enables the pl031 RTC on the Hi6220 SoC.
>>> 
>>>  I'd like to submit it to be merged.
>>> 
>>>  Wei has acked the second patch (modulo a whitespace fix which
>>>  I've included in this v3), so it seems like both could go
>>>  through the clk tree.
>>> 
>>>  But Wei also seemed open to pulling in a clk tree branch
>>>  as it goes through arm-soc.
>>> 
>>>  Michael/Stephen: If there's no other objections, could you
>>>  queue the first patch and make it avilable via the branch for
>>>  Wei, or just take both patches?
>>> >>>
>>> >>> I happen to dread these kind of patchsets these days. There's added
>>> >>> dependencies across trees just because a defined name for the clock
>>> >>> number is added to a header file.
>>> >>>
>>> >>> I much prefer to use numerical clocks for one release, and then once
>>> >>> everything is in, switch over to the defines in the DTS.
>>> >>>
>>> >>> That way there are no dependencies, no need to setup a shared branch
>>> >>> for a simple 3-line patch, etc.
>>> >>>
>>> >>> So, mind respinning the DTS piece?
>>> >>
>>> >> Huh..
>>> >
>>> > Sorry if it appeared random, I've complained about it for a while to
>>> > submaintainers.
>>>
>>> No.. I get it, the cross-maintainer shared branch is complex enough to
>>> want to avoid. I figured it would be easier to just take a maintainer
>>> acked patch in via the clk tree, but its not my tree, so I'll leave it
>>> to you maintainers to resolve.
>>
>> The question this raises is why that clock was missed the first time
>> around. I'd suggest whoever owns the clock driver can go through the
>> documentation again and look for others that may have been missed,
>> then send a patch to the driver to add *all* the missing ones for the
>> merge window, and one release later we add the driver depending on
>> previously unknown clocks.
>
> Though this seemingly goes against the otherwise widely recommended
> approach of breaking up patches into small obvious chunks.
>
> And personally, and I don't mean to criticize, but the suggestions
> here (use numerical values, then later rename to macros; add
> everything in one go, then make dts changes a release later) all seem
> like non-optimal workarounds for the fact that adding almost any
> functionality requires cross subsystem-maintainer negotiations (or two
> release steps to get one bit of functionality merged).
>
> It seems like it might even just be clearer to make the
> two-release-steps method the widely broadcast rule (ie: no
> dependencies on in-flight patches for dts changes), so this doesn't
> confuse/dismay new developers.
>
> Anyway... In this case, I don't have the clk documentation, so I'll
> ping Zhangfei to check if there is any other clock values that should

Arnd, John

After checking documentation, I didn't see other clock values that
need to be added.

-Guodong

> be added in the future, but at least for HiKey, while there are still
> a few clk patches remaining in the tree, I don't have any more
> additions to the clk list.
>
> thanks
> -john

Re: [alsa-devel] [PATCH -next v2] ASoC: mediatek: mt2701: fix non static symbol warning

[Garlic Tseng]

On Fri, 2016-07-08 at 13:47 +, weiyj...@163.com wrote:
> From: Wei Yongjun 
> 
> Fixes the following sparse warning:
> 
> sound/soc/mediatek/mt2701/mt2701-afe-pcm.c:72:5: warning:
>  symbol 'mt2701_dai_num_to_i2s' was not declared. Should it be static?
> 
> Signed-off-by: Wei Yongjun 

Acked-by: Garlic Tseng 

> ---
>  sound/soc/mediatek/mt2701/mt2701-afe-pcm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c 
> b/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
> index 15522c0..34a6123 100644
> --- a/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
> +++ b/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
> @@ -69,7 +69,7 @@ static const struct mt2701_afe_rate mt2701_afe_i2s_rates[] 
> = {
>   { .rate = 352800, .regvalue = 24 },
>  };
>  
> -int mt2701_dai_num_to_i2s(struct mtk_base_afe *afe, int num)
> +static int mt2701_dai_num_to_i2s(struct mtk_base_afe *afe, int num)
>  {
>   int val = num - MT2701_IO_I2S;
> 
> 
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: [PATCH 1/7] hwmon: (core) New hwmon registration API

[Guenter Roeck]

Hi Jonathan,

On 07/10/2016 08:51 AM, Jonathan Cameron wrote:

On 26/06/16 04:26, Guenter Roeck wrote:

Up to now, each hwmon driver has to implement its own sysfs attributes.
This requires a lot of template code, and distracts from the driver's core
function to read and write chip registers.

To be able to reduce driver complexity, move sensor attribute handling
and thermal zone registration into hwmon core. By using the new API,
driver size is typically reduced by 20-50% depending on driver complexity
and the number of sysfs attributes supported.

With this patch, the new API only supports thermal sensors. Support for
other sensor types will be added with subsequent patches.

Signed-off-by: Guenter Roeck 

Hi Guenter.

Sorry it took me so long to get to this

Anyhow, mostly looks clean, effective and consise to me.
Various bits and pieces inline.  There are a few bits I might (when time
allows) lift over to iio as they are nicer than what we have.

My one lesson learned from IIO is always be wary of space in bitmaps.  We
haven't run out yet but are getting close.  You may end up in a similar
state here a few years down the line.


Yes, I spend a lot of time arguing with myself over u32 vs. u64. I decided
to stick with u32 for now, reasons being that there are multiple number spaces
and that the bit mask is only really used for registration (and thus relatively
easy to change).

More comments inline.


Jonathan

---
  drivers/hwmon/hwmon.c | 485 ++
  include/linux/hwmon.h | 122 +
  2 files changed, 574 insertions(+), 33 deletions(-)

diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c
index a26c385a435b..9530644ae297 100644
--- a/drivers/hwmon/hwmon.c
+++ b/drivers/hwmon/hwmon.c
@@ -12,17 +12,16 @@

  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

-#include 
+#include 
  #include 
  #include 
-#include 
-#include 
-#include 
  #include 
-#include 
-#include 
+#include 
+#include 

Some unconnected changes in this.  Arguably reordering is good and
all but should be in a precursor patch so it's obvious what has
been added or removed here.


Split into a separate patch.


  #include 
+#include 
  #include 
+#include 

  #define HWMON_ID_PREFIX "hwmon"
  #define HWMON_ID_FORMAT HWMON_ID_PREFIX "%d"
@@ -30,9 +29,33 @@
  struct hwmon_device {
const char *name;
struct device dev;
+   const struct hwmon_chip_info *chip;
+
+   struct attribute_group group;
+   const struct attribute_group **groups;
  };
  #define to_hwmon_device(d) container_of(d, struct hwmon_device, dev)

+struct hwmon_device_attribute {
+   struct device_attribute dev_attr;
+   const struct hwmon_ops *ops;
+   enum hwmon_sensor_types type;
+   u32 attr;
+   int index;
+};
+#define to_hwmon_attr(d) \
+   container_of(d, struct hwmon_device_attribute, dev_attr)
+
+/*
+ * Thermal zone information
+ * In addition to the reference to the hwmon device,
+ * also provides the sensor index.
+ */
+struct hwmon_thermal_data {
+   struct hwmon_device *hwdev; /* Reference to hwmon device */
+   int index;  /* sensor index */
+};
+
  static ssize_t
  show_name(struct device *dev, struct device_attribute *attr, char *buf)
  {
@@ -80,25 +103,280 @@ static struct class hwmon_class = {

  static DEFINE_IDA(hwmon_ida);

-/**
- * hwmon_device_register_with_groups - register w/ hwmon
- * @dev: the parent device
- * @name: hwmon name attribute
- * @drvdata: driver data to attach to created device
- * @groups: List of attribute groups to create
- *
- * hwmon_device_unregister() must be called when the device is no
- * longer needed.
- *
- * Returns the pointer to the new device.
- */
-struct device *
-hwmon_device_register_with_groups(struct device *dev, const char *name,
- void *drvdata,
- const struct attribute_group **groups)
+/* Thermal zone handling */
+
+static int hwmon_thermal_get_temp(void *data, int *temp)
+{
+   struct hwmon_thermal_data *tdata = data;
+   struct hwmon_device *hwdev = tdata->hwdev;
+   int ret;
+   long t;
+
+   ret = hwdev->chip->ops->read(>dev, hwmon_temp, hwmon_temp_input,
+tdata->index, );
+   if (ret < 0)
+   return ret;
+
+   *temp = t;
+
+   return 0;
+}
+
+static struct thermal_zone_of_device_ops hwmon_thermal_ops = {
+   .get_temp = hwmon_thermal_get_temp,
+};
+
+static int hwmon_thermal_add_sensor(struct device *dev,
+   struct hwmon_device *hwdev,
+   int index)
+{
+   struct hwmon_thermal_data *tdata;
+
+   tdata = devm_kzalloc(dev, sizeof(*tdata), GFP_KERNEL);
+   if (!tdata)
+   return -ENOMEM;
+
+   tdata->hwdev = hwdev;
+   tdata->index = index;
+
+   devm_thermal_zone_of_sensor_register(>dev, index, tdata,
+ 

Re: [PATCH] 8250/fintek: rename IRQ_MODE macro

[Ji-Ze Hong (Peter Hong)]

Hi Arnd,

Arnd Bergmann 於 2016/6/27 下午 05:21 寫道:

This renames the newly introduced 'IRQ_MODE' macro to FINTEK_IRQ_MODE.

Signed-off-by: Arnd Bergmann 
Fixes: 4da22f1418cb ("serial: 8250_fintek: fix the mismatched IRQ mode")


Acked-by: Ji-Ze Hong (Peter Hong) 

Thanks for fix the issue.
--
With Best Regards,
Peter Hung

linux-next: build failure after merge of the pm tree

[Stephen Rothwell]

Hi Rafael,

After merging the pm tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

ERROR: "configfs_unregister_subsystem" [samples/configfs/configfs_sample.ko] 
undefined!
ERROR: "configfs_register_subsystem" [samples/configfs/configfs_sample.ko] 
undefined!
ERROR: "config_group_init" [samples/configfs/configfs_sample.ko] undefined!
ERROR: "config_item_init_type_name" [samples/configfs/configfs_sample.ko] 
undefined!
ERROR: "config_group_init_type_name" [samples/configfs/configfs_sample.ko] 
undefined!
ERROR: "configfs_undepend_item" [fs/ocfs2/cluster/ocfs2_nodemanager.ko] 
undefined!
ERROR: "config_item_put" [fs/ocfs2/cluster/ocfs2_nodemanager.ko] undefined!
ERROR: "config_item_init_type_name" [fs/ocfs2/cluster/ocfs2_nodemanager.ko] 
undefined!

... and many more ...

Presumably (maybe?) caused by commit

  0bf54fcd9504 ("ACPI: add support for configfs")

though it is not obvious why this should be a problem.

I have used the version of the pm tree from next-20160708 for today.
-- 
Cheers,
Stephen Rothwell

Re: Update the maximum depth of C-state from 6 to 9

[baolex.ni]

Hi Jon,

This patch is an old one, we have corrected some minor issues on the newer one.
Please only review the newest version from my last mail with this subject
"[PATCH] ACPI: Update the maximum depth of C-state from 6 to 9".
And I also attached it to this mail.

Thanks,
Baole

On 7/11/2016 6:37 AM, Jonathan Corbet wrote:
> On Mon, 4 Jul 2016 09:55:10 +0800
> "baolex.ni"  wrote:
> 
>> Currently, CPUIDLE_STATE_MAX has been defined as 10 in the cpuidle head file,
>> and max_cstate = CPUIDLE_STATE_MAX – 1, so 9 is the right maximum depth of 
>> C-state.
>> This change is reflected in one place of the kernel-param file,
>> but not in the other place where I suggest changing.
>>
>> Signed-off-by: Chuansheng Liu 
>> Signed-off-by: Baole Ni 
> 
> So why are there two signoffs on a single-line patch?  Which one of you
> is the actual author?
> 
> Thanks,
> 
> jon
> 
From cf5f8aa6885874f6490b11507d3c0c86fa0a11f4 Mon Sep 17 00:00:00 2001
From: Chuansheng Liu 
Date: Mon, 4 Jul 2016 08:52:51 +0800
Subject: [PATCH] Update the maximum depth of C-state from 6 to 9
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Currently, CPUIDLE_STATE_MAX has been defined as 10 in the cpuidle head file,
and max_cstate = CPUIDLE_STATE_MAX – 1, so 9 is the right maximum depth of 
C-state.
This change is reflected in one place of the kernel-param file,
but not in the other place where I suggest changing.

Signed-off-by: Chuansheng Liu 
Signed-off-by: Baole Ni 
---
 Documentation/kernel-parameters.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 82b42c9..a863737 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1661,7 +1661,7 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
 
intel_idle.max_cstate=  [KNL,HW,ACPI,X86]
0   disables intel_idle and fall back on acpi_idle.
-   1 to 6  specify maximum depth of C-state.
+   1 to 9  specify maximum depth of C-state.
 
intel_pstate=  [X86]
   disable
-- 
2.8.3

Re: [PATCH v2 2/9] [media] : v4l: add Mediatek compressed video block format

[tiffany lin]

Hi Hans,

On Fri, 2016-07-08 at 12:18 +0200, Hans Verkuil wrote:
> On 05/12/2016 01:24 PM, Tiffany Lin wrote:
> > Add V4L2_PIX_FMT_MT21 format used on MT8173 driver.
> > It is compressed format and need MT8173 MDP driver to transfer to other 
> > standard format.
> > 
> > Signed-off-by: Tiffany Lin 
> > ---
> >  include/uapi/linux/videodev2.h |1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> > index 8f95191..52feea6 100644
> > --- a/include/uapi/linux/videodev2.h
> > +++ b/include/uapi/linux/videodev2.h
> > @@ -625,6 +625,7 @@ struct v4l2_pix_format {
> >  #define V4L2_PIX_FMT_Y8I  v4l2_fourcc('Y', '8', 'I', ' ') /* Greyscale 
> > 8-bit L/R interleaved */
> >  #define V4L2_PIX_FMT_Y12I v4l2_fourcc('Y', '1', '2', 'I') /* Greyscale 
> > 12-bit L/R interleaved */
> >  #define V4L2_PIX_FMT_Z16  v4l2_fourcc('Z', '1', '6', ' ') /* Depth 
> > data 16-bit */
> > +#define V4L2_PIX_FMT_MT21 v4l2_fourcc('M', 'T', '2', '1') /* Mediatek 
> > compressed block mode  */
> 
> v4l2-ioctl.c should be modified as well so the correct description string is 
> filled in.
> 
Got it. I will fix this.

best regards,
Tiffany

> Regards,
> 
>   Hans
> 
> >  
> >  /* SDR formats - used only for Software Defined Radio devices */
> >  #define V4L2_SDR_FMT_CU8  v4l2_fourcc('C', 'U', '0', '8') /* IQ u8 
> > */
> > 

linux-next: manual merge of the wireless-drivers-next tree with the net-next tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the wireless-drivers-next tree got a
conflict in:

  drivers/net/wireless/intel/iwlwifi/mvm/scan.c

between commit:

  7947d3e075cd ("mac80211: Add support for beacon report radio measurement")

from the net-next tree and commit:

  69e046423ad7 ("iwlwifi: mvm: change scan timeout to a delayed work")

from the wireless-drivers-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/wireless/intel/iwlwifi/mvm/scan.c
index 1cac10c5d818,fb25d9e41912..
--- a/drivers/net/wireless/intel/iwlwifi/mvm/scan.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/scan.c
@@@ -400,9 -396,10 +400,9 @@@ void iwl_mvm_rx_lmac_scan_complete_noti
   iwl_mvm_ebs_status_str(scan_notif->ebs_status));
  
mvm->scan_status &= ~IWL_MVM_SCAN_REGULAR;
 -  ieee80211_scan_completed(mvm->hw,
 -  scan_notif->status == IWL_SCAN_OFFLOAD_ABORTED);
 +  ieee80211_scan_completed(mvm->hw, );
iwl_mvm_unref(mvm, IWL_MVM_REF_SCAN);
-   del_timer(>scan_timer);
+   cancel_delayed_work(>scan_timeout_dwork);
} else {
IWL_ERR(mvm,
"got scan complete notification but no scan is 
running\n");
@@@ -1433,13 -1432,9 +1435,13 @@@ void iwl_mvm_rx_umac_scan_complete_noti
  
/* if the scan is already stopping, we don't need to notify mac80211 */
if (mvm->scan_uid_status[uid] == IWL_MVM_SCAN_REGULAR) {
 -  ieee80211_scan_completed(mvm->hw, aborted);
 +  struct cfg80211_scan_info info = {
 +  .aborted = aborted,
 +  };
 +
 +  ieee80211_scan_completed(mvm->hw, );
iwl_mvm_unref(mvm, IWL_MVM_REF_SCAN);
-   del_timer(>scan_timer);
+   cancel_delayed_work(>scan_timeout_dwork);
} else if (mvm->scan_uid_status[uid] == IWL_MVM_SCAN_SCHED) {
ieee80211_sched_scan_stopped(mvm->hw);
mvm->sched_scan_pass_all = SCHED_SCAN_PASS_ALL_DISABLED;
@@@ -1644,14 -1630,9 +1646,14 @@@ out
 * to release the scan reference here.
 */
iwl_mvm_unref(mvm, IWL_MVM_REF_SCAN);
-   del_timer(>scan_timer);
+   cancel_delayed_work(>scan_timeout_dwork);
 -  if (notify)
 -  ieee80211_scan_completed(mvm->hw, true);
 +  if (notify) {
 +  struct cfg80211_scan_info info = {
 +  .aborted = true,
 +  };
 +
 +  ieee80211_scan_completed(mvm->hw, );
 +  }
} else if (notify) {
ieee80211_sched_scan_stopped(mvm->hw);
mvm->sched_scan_pass_all = SCHED_SCAN_PASS_ALL_DISABLED;

Re: [PATCH v2 09/10] Documentation: devicetree: Add dts description for nuc900

[Wan Zongshun]

On 2016年07月11日 06:17, Arnd Bergmann wrote:

On Sunday, July 10, 2016 3:42:21 PM CEST Wan Zongshun wrote:

+
+Required properties:
+- compatible : Should be "nuvoton,nuc970-tmr"
+- reg : Address and length of the register set
+- clocks : Reference on the timer input clock
+- interrupts : Reference to the timer interrupt
+
+Example:
+
+tmr@0xb8001000 {


The name should be "timer", not "tmr", and the address should
not contain a leading "0x".


Ok, so all dts addresses has no need contain a leading "0x"?




+   compatible = "nuvoton,nuc970-tmr";
+   reg = <0xb8001000 0x1000>;
+   interrupts = <16>;
+   clocks = < TIMER0_GATE>,
+   < TIMER1_GATE>;
+   clock-names = "timer0", "timer1";
+};


The clocks/clock-names description does not match the example:
you only define a single clock in the required properties, but
have two separate inputs in the example. Please fix one or the
other.


Two clocks are necessary, so I only need modify this description like?

Required properties:
  clocks : Reference on the timer input clock, This list should be 2
   clocks, the order is timer0 , timer1.

Is it ok?



Arnd