[PATCH 1/1] powerpc/embedded6xx: Make reboot works on MVME5100

[Alessio Igor Bogani]

The mtmsr() function hangs during restart. Make reboot works on
MVME5100 removing that function call.
---
 arch/powerpc/platforms/embedded6xx/mvme5100.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/powerpc/platforms/embedded6xx/mvme5100.c 
b/arch/powerpc/platforms/embedded6xx/mvme5100.c
index 8f65aa3..118cc33 100644
--- a/arch/powerpc/platforms/embedded6xx/mvme5100.c
+++ b/arch/powerpc/platforms/embedded6xx/mvme5100.c
@@ -179,9 +179,7 @@ static void mvme5100_show_cpuinfo(struct seq_file *m)
 
 static void mvme5100_restart(char *cmd)
 {
-
local_irq_disable();
-   mtmsr(mfmsr() | MSR_IP);
 
out_8((u_char *) restart, 0x01);
 
-- 
2.7.2

RE: [PATCH 2/2] mfd: add documentation for ACT8945A DT bindings

[Yang, Wenyou]

Hi,

> -Original Message-
> From: kbuild test robot [mailto:l...@intel.com]
> Sent: 2016年3月8日 11:04
> To: Yang, Wenyou 
> Cc: kbuild-...@01.org; Lee Jones ; Rob Herring
> ; Pawel Moll ; Mark Rutland
> ; Ian Campbell ; Kumar
> Gala ; Ferre, Nicolas ;
> linux-kernel@vger.kernel.org; devicet...@vger.kernel.org; Yang, Wenyou
> 
> Subject: Re: [PATCH 2/2] mfd: add documentation for ACT8945A DT bindings
> 
> Hi Wenyou,
> 
> [auto build test ERROR on v4.4-rc8]
> [cannot apply to next-20160307]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improving the system]
> 
> url:https://github.com/0day-ci/linux/commits/Wenyou-Yang/mfd-act8945a-add-
> Active-semi-ACT8945A-PMIC-MFD-driver/20160108-100943

This is not the latest version, please use 
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/405258.html

> config: x86_64-allmodconfig (attached as .config)
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64
> 

It works using the commands as below.

$ make mrproper
$ export ARCH=x86_64
$ export CROSS_COMPILE=
$ make allmodconfig
$ make


> All errors (new ones prefixed by >>):
> 
>drivers/built-in.o: In function `act8945a_i2c_probe':
> >> act8945a.c:(.text+0x22bb26): undefined reference to 
> >> `__devm_regmap_init_i2c'
>drivers/built-in.o: In function `act8945a_i2c_init':
> >> act8945a.c:(.init.text+0x1a57a): undefined reference to 
> >> `i2c_register_driver'
>drivers/built-in.o: In function `act8945a_i2c_exit':
> >> act8945a.c:(.exit.text+0x68f): undefined reference to `i2c_del_driver'
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation


Best Regards,
Wenyou Yang

[PATCH v3 5/7] usb: mux: add driver for Intel drcfg controlled port mux

[Lu Baolu]

Several Intel PCHs and SOCs have an internal mux that is used to
share one USB port between device controller and host controller.
The mux is handled through the Dual Role Configuration Register.

Signed-off-by: Heikki Krogerus 
Signed-off-by: Lu Baolu 
Signed-off-by: Wu Hao 
Reviewed-by: Felipe Balbi 
---
 MAINTAINERS   |   1 +
 drivers/usb/mux/Kconfig   |   7 ++
 drivers/usb/mux/Makefile  |   1 +
 drivers/usb/mux/intel-mux-drcfg.c | 161 ++
 4 files changed, 170 insertions(+)
 create mode 100644 drivers/usb/mux/intel-mux-drcfg.c

diff --git a/MAINTAINERS b/MAINTAINERS
index ab876eb..399cefe 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11407,6 +11407,7 @@ S:  Supported
 F: drivers/usb/mux/intel-mux.c
 F: include/linux/usb/intel-mux.h
 F: drivers/usb/mux/intel-mux-gpio.c
+F: drivers/usb/mux/intel-mux-drcfg.c
 
 USB PRINTER DRIVER (usblp)
 M: Pete Zaitcev 
diff --git a/drivers/usb/mux/Kconfig b/drivers/usb/mux/Kconfig
index 060bf5c..775d5da 100644
--- a/drivers/usb/mux/Kconfig
+++ b/drivers/usb/mux/Kconfig
@@ -15,4 +15,11 @@ config INTEL_MUX_GPIO
  Say Y here to enable support for Intel dual role port mux
  controlled by GPIOs.
 
+config INTEL_MUX_DRCFG
+   tristate "Intel dual role port mux controlled by register"
+   depends on X86
+   select INTEL_USB_MUX
+   help
+ Say Y here to enable support for Intel dual role port mux
+ controlled by the Dual Role Configuration Register.
 endmenu
diff --git a/drivers/usb/mux/Makefile b/drivers/usb/mux/Makefile
index 66f765c..3179909 100644
--- a/drivers/usb/mux/Makefile
+++ b/drivers/usb/mux/Makefile
@@ -3,3 +3,4 @@
 #
 obj-$(CONFIG_INTEL_USB_MUX)+= intel-mux.o
 obj-$(CONFIG_INTEL_MUX_GPIO)   += intel-mux-gpio.o
+obj-$(CONFIG_INTEL_MUX_DRCFG)  += intel-mux-drcfg.o
diff --git a/drivers/usb/mux/intel-mux-drcfg.c 
b/drivers/usb/mux/intel-mux-drcfg.c
new file mode 100644
index 000..11db826
--- /dev/null
+++ b/drivers/usb/mux/intel-mux-drcfg.c
@@ -0,0 +1,161 @@
+/**
+ * intel-mux-drcfg.c - Driver for Intel USB mux via register
+ *
+ * Copyright (C) 2016 Intel Corporation
+ * Author: Heikki Krogerus 
+ * Author: Lu Baolu 
+ *
+ * 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 
+
+#define INTEL_MUX_CFG0 0x00
+#define INTEL_MUX_CFG1 0x04
+#define CFG0_SW_IDPIN  BIT(20)
+#define CFG0_SW_IDPIN_EN   BIT(21)
+#define CFG0_SW_VBUS_VALID BIT(24)
+#define CFG1_SW_MODE   BIT(29)
+#define CFG1_POLL_TIMEOUT  1000
+
+struct intel_usb_mux {
+   struct intel_mux_dev umdev;
+   void __iomem *regs;
+};
+
+static inline int intel_mux_drcfg_switch(struct intel_mux_dev *umdev, bool 
host)
+{
+   struct intel_usb_mux *mux;
+   unsigned long timeout;
+   u32 data;
+
+   mux = container_of(umdev, struct intel_usb_mux, umdev);
+
+   /* Check and set mux to SW controlled mode */
+   data = readl(mux->regs + INTEL_MUX_CFG0);
+   if (!(data & CFG0_SW_IDPIN_EN)) {
+   data |= CFG0_SW_IDPIN_EN;
+   writel(data, mux->regs + INTEL_MUX_CFG0);
+   }
+
+   /*
+* Configure CFG0 to switch the mux and VBUS_VALID bit is
+* required for device mode.
+*/
+   data = readl(mux->regs + INTEL_MUX_CFG0);
+   if (host)
+   data &= ~(CFG0_SW_IDPIN | CFG0_SW_VBUS_VALID);
+   else
+   data |= (CFG0_SW_IDPIN | CFG0_SW_VBUS_VALID);
+   writel(data, mux->regs + INTEL_MUX_CFG0);
+
+   /*
+* Polling CFG1 for safety, most case it takes about 600ms
+* to finish mode switching, set TIMEOUT long enough.
+*/
+   timeout = jiffies + msecs_to_jiffies(CFG1_POLL_TIMEOUT);
+
+   /* Polling on CFG1 register to confirm mode switch. */
+   while (!time_after(jiffies, timeout)) {
+   data = readl(mux->regs + INTEL_MUX_CFG1);
+   if (!(host ^ (data & CFG1_SW_MODE)))
+   return 0;
+   /* interval for polling is set to about 5ms */
+   usleep_range(5000, 5100);
+   }
+
+   return -ETIMEDOUT;
+}
+
+static int intel_mux_drcfg_cable_set(struct intel_mux_dev *umdev)
+{
+   dev_dbg(umdev->dev, "drcfg mux switch to HOST\n");
+
+   return intel_mux_drcfg_switch(umdev, true);
+}
+
+static int intel_mux_drcfg_cable_unset(struct intel_mux_dev *umdev)
+{
+   dev_dbg(umdev->dev, "drcfg mux switch to DEVICE\n");
+
+   return intel_mux_drcfg_switch(umdev, false);
+}
+
+static int intel_mux_drcfg_probe(struct platform_device *pdev)
+{
+   struct intel_usb_mux *mux;
+   struct intel_mux_dev *umdev;
+   struct device *dev = &pdev->dev;
+   u64 start, size;
+   int re

[PATCH v3 2/7] extcon: usb-gpio: add support for ACPI gpio interface

[Lu Baolu]

GPIO resource could be retrieved through APCI as well.

Signed-off-by: Lu Baolu 
Reviewed-by: Felipe Balbi 
Acked-by: Chanwoo Choi 
---
 drivers/extcon/extcon-usb-gpio.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/extcon/extcon-usb-gpio.c b/drivers/extcon/extcon-usb-gpio.c
index af9c8b0..472c431 100644
--- a/drivers/extcon/extcon-usb-gpio.c
+++ b/drivers/extcon/extcon-usb-gpio.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define USB_GPIO_DEBOUNCE_MS   20  /* ms */
 
@@ -91,7 +92,7 @@ static int usb_extcon_probe(struct platform_device *pdev)
struct usb_extcon_info *info;
int ret;
 
-   if (!np)
+   if (!np && !ACPI_HANDLE(dev))
return -EINVAL;
 
info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL);
-- 
2.1.4

[PATCH v3 1/7] extcon: usb-gpio: add device binding for platform device

[Lu Baolu]

This is needed to handle the GPIO connected USB ID pin found on
Intel Baytrail devices.

Signed-off-by: Lu Baolu 
Reviewed-by: Felipe Balbi 
Acked-by: Chanwoo Choi 
---
 drivers/extcon/extcon-usb-gpio.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/extcon/extcon-usb-gpio.c b/drivers/extcon/extcon-usb-gpio.c
index 2b2fecf..af9c8b0 100644
--- a/drivers/extcon/extcon-usb-gpio.c
+++ b/drivers/extcon/extcon-usb-gpio.c
@@ -206,6 +206,12 @@ static const struct of_device_id usb_extcon_dt_match[] = {
 };
 MODULE_DEVICE_TABLE(of, usb_extcon_dt_match);
 
+static const struct platform_device_id usb_extcon_platform_ids[] = {
+   { .name = "extcon-usb-gpio", },
+   { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(platform, usb_extcon_platform_ids);
+
 static struct platform_driver usb_extcon_driver = {
.probe  = usb_extcon_probe,
.remove = usb_extcon_remove,
@@ -214,6 +220,7 @@ static struct platform_driver usb_extcon_driver = {
.pm = &usb_extcon_pm_ops,
.of_match_table = usb_extcon_dt_match,
},
+   .id_table = usb_extcon_platform_ids,
 };
 
 module_platform_driver(usb_extcon_driver);
-- 
2.1.4

[PATCH v3 6/7] usb: pci-quirks: add Intel USB drcfg mux device

[Lu Baolu]

In some Intel platforms, a single usb port is shared between USB host
and device controllers. The shared port is under control of a switch
which is defined in the Intel vendor defined extended capability for
xHCI.

This patch adds the support to detect and create the platform device
for the port mux switch.

Signed-off-by: Lu Baolu 
Reviewed-by: Felipe Balbi 
---
 drivers/usb/host/pci-quirks.c| 47 ++--
 drivers/usb/host/xhci-ext-caps.h |  2 ++
 2 files changed, 47 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 35af362..6a737cf 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -16,10 +16,11 @@
 #include 
 #include 
 #include 
+#include 
+
 #include "pci-quirks.h"
 #include "xhci-ext-caps.h"
 
-
 #define UHCI_USBLEGSUP 0xc0/* legacy support */
 #define UHCI_USBCMD0   /* command register */
 #define UHCI_USBINTR   4   /* interrupt register */
@@ -78,6 +79,9 @@
 #define USB_INTEL_USB3_PSSEN   0xD8
 #define USB_INTEL_USB3PRM  0xDC
 
+#define DEVICE_ID_INTEL_CHERRYVIEW_XHCI0x22b5
+#define DEVICE_ID_INTEL_BROXTON_M_XHCI 0x0aa8
+
 /*
  * amd_chipset_gen values represent AMD different chipset generations
  */
@@ -956,6 +960,41 @@ void usb_disable_xhci_ports(struct pci_dev *xhci_pdev)
 }
 EXPORT_SYMBOL_GPL(usb_disable_xhci_ports);
 
+static void create_intel_usb_mux_device(struct pci_dev *xhci_pdev,
+   void __iomem *base)
+{
+   struct platform_device *plat_dev;
+   struct property_set pset;
+   int ret;
+
+   struct property_entry pentry[] = {
+   PROPERTY_ENTRY_U64("reg-start",
+   pci_resource_start(xhci_pdev, 0) + 0x80d8),
+   PROPERTY_ENTRY_U64("reg-size", 8),
+   { },
+   };
+
+   if (!xhci_find_next_ext_cap(base, 0, XHCI_EXT_CAPS_INTEL_USB_MUX))
+   return;
+
+   plat_dev = platform_device_alloc("intel-mux-drcfg",
+   PLATFORM_DEVID_AUTO);
+   if (!plat_dev)
+   return;
+
+   plat_dev->dev.parent = &xhci_pdev->dev;
+   pset.properties = pentry;
+   platform_device_add_properties(plat_dev, &pset);
+
+   ret = platform_device_add(plat_dev);
+   if (ret) {
+   dev_warn(&xhci_pdev->dev,
+   "failed to create mux device with error %d",
+   ret);
+   platform_device_put(plat_dev);
+   }
+}
+
 /**
  * PCI Quirks for xHCI.
  *
@@ -1022,8 +1061,12 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
writel(val, base + ext_cap_offset + XHCI_LEGACY_CONTROL_OFFSET);
 
 hc_init:
-   if (pdev->vendor == PCI_VENDOR_ID_INTEL)
+   if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
usb_enable_intel_xhci_ports(pdev);
+   if (pdev->device == DEVICE_ID_INTEL_CHERRYVIEW_XHCI ||
+   pdev->device == DEVICE_ID_INTEL_BROXTON_M_XHCI)
+   create_intel_usb_mux_device(pdev, base);
+   }
 
op_reg_base = base + XHCI_HC_LENGTH(readl(base));
 
diff --git a/drivers/usb/host/xhci-ext-caps.h b/drivers/usb/host/xhci-ext-caps.h
index e0244fb..e368ccb 100644
--- a/drivers/usb/host/xhci-ext-caps.h
+++ b/drivers/usb/host/xhci-ext-caps.h
@@ -51,6 +51,8 @@
 #define XHCI_EXT_CAPS_ROUTE5
 /* IDs 6-9 reserved */
 #define XHCI_EXT_CAPS_DEBUG10
+/* Vendor defined 192-255 */
+#define XHCI_EXT_CAPS_INTEL_USB_MUX192
 /* USB Legacy Support Capability - section 7.1.1 */
 #define XHCI_HC_BIOS_OWNED (1 << 16)
 #define XHCI_HC_OS_OWNED   (1 << 24)
-- 
2.1.4

Re: [PATCH v1 1/1] mfd: intel-lpss: save register context on suspend

[Lee Jones]

On Tue, 08 Mar 2016, Andy Shevchenko wrote:

> On Tue, Mar 8, 2016 at 6:48 AM, Lee Jones  wrote:
> > On Tue, 26 Jan 2016, Andy Shevchenko wrote:
> >
> >> From: Heikki Krogerus 
> >>
> >> All configurations are lost and the registers will have
> >> default values when the hardware is suspended and resumed,
> >> so saving the private register space context on suspend, and
> >> restoring it on resume.
> >>
> >> Fixes: 4b45efe85263 (mfd: Add support for Intel Sunrisepoint LPSS devices)
> >
> > I'd say this sumbission is more of a functional extention than a
> > bug-fix.  No real need for this statement.
> 
> But we would like send it later to stable@ to have this back ported.

Yes, I see.

Although, as it "fixes" a first submission, my personal preference
would be a:

  Cc: sta...@vger.kernel.org # v4.{whatever}

.. tag instead.

> >> Signed-off-by: Heikki Krogerus 
> >> Signed-off-by: Mika Westerberg 
> >
> > Did it really take 2 of you to write this patch?
> 
> It's probably my mistake, since I took this one from Mika's tree and
> kept his SoB.

No problem.

Please omit his SoB when upstreaming patches from BSP trees.

> >> Signed-off-by: Andy Shevchenko 
> >> ---
> >>  drivers/mfd/intel-lpss.c | 19 ++-
> >>  1 file changed, 18 insertions(+), 1 deletion(-)
> >
> > Code looks okay though:
> >   Acked-by: Lee Jones 
> 
> Thanks.
> 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH v3 3/7] usb: mux: add common code for Intel dual role port mux

[Lu Baolu]

Several Intel PCHs and SOCs have an internal mux that is used to
share one USB port between device controller and host controller.

A usb port mux could be abstracted as the following elements:
1) mux state: HOST or PERIPHERAL;
2) an extcon cable which triggers the change of mux state between
   HOST and PERIPHERAL;
3) The required action to do the real port switch.

This patch adds the common code to handle usb port mux. With this
common code, the individual mux driver, which always is platform
dependent, could focus on the real operation of mux switch.

Signed-off-by: Lu Baolu 
Reviewed-by: Heikki Krogerus 
Reviewed-by: Felipe Balbi 
---
 Documentation/ABI/testing/sysfs-bus-platform |  15 +++
 MAINTAINERS  |   7 ++
 drivers/usb/Kconfig  |   2 +
 drivers/usb/Makefile |   1 +
 drivers/usb/mux/Kconfig  |   9 ++
 drivers/usb/mux/Makefile |   4 +
 drivers/usb/mux/intel-mux.c  | 166 +++
 include/linux/usb/intel-mux.h|  47 
 8 files changed, 251 insertions(+)
 create mode 100644 drivers/usb/mux/Kconfig
 create mode 100644 drivers/usb/mux/Makefile
 create mode 100644 drivers/usb/mux/intel-mux.c
 create mode 100644 include/linux/usb/intel-mux.h

diff --git a/Documentation/ABI/testing/sysfs-bus-platform 
b/Documentation/ABI/testing/sysfs-bus-platform
index 5172a61..a2261cb 100644
--- a/Documentation/ABI/testing/sysfs-bus-platform
+++ b/Documentation/ABI/testing/sysfs-bus-platform
@@ -18,3 +18,18 @@ Description:
devices to opt-out of driver binding using a driver_override
name such as "none".  Only a single driver may be specified in
the override, there is no support for parsing delimiters.
+
+What:  /sys/bus/platform/devices/.../intel_mux
+Date:  Febuary 2016
+Contact:   Lu Baolu 
+Description:
+   In some platforms, a single USB port is shared between a USB 
host
+   controller and a device controller. A USB mux driver is needed 
to
+   handle the port mux. intel_mux attribute shows and stores the 
mux
+   state.
+   For read:
+   'peripheral' - mux switched to PERIPHERAL controller;
+   'host'   - mux switched to HOST controller.
+   For write:
+   'peripheral' - mux will be switched to PERIPHERAL controller;
+   'host'   - mux will be switched to HOST controller.
diff --git a/MAINTAINERS b/MAINTAINERS
index c55b37e..a93d26a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11400,6 +11400,13 @@ T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
 S: Maintained
 F: drivers/usb/phy/
 
+USB PORT MUX DRIVER
+M: Lu Baolu 
+L: linux-...@vger.kernel.org
+S: Supported
+F: drivers/usb/mux/intel-mux.c
+F: include/linux/usb/intel-mux.h
+
 USB PRINTER DRIVER (usblp)
 M: Pete Zaitcev 
 L: linux-...@vger.kernel.org
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 8ed451d..dbd6620 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -149,6 +149,8 @@ endif # USB
 
 source "drivers/usb/phy/Kconfig"
 
+source "drivers/usb/mux/Kconfig"
+
 source "drivers/usb/gadget/Kconfig"
 
 config USB_LED_TRIG
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index dca7856..9a92338 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -6,6 +6,7 @@
 
 obj-$(CONFIG_USB)  += core/
 obj-$(CONFIG_USB_SUPPORT)  += phy/
+obj-$(CONFIG_USB_SUPPORT)  += mux/
 
 obj-$(CONFIG_USB_DWC3) += dwc3/
 obj-$(CONFIG_USB_DWC2) += dwc2/
diff --git a/drivers/usb/mux/Kconfig b/drivers/usb/mux/Kconfig
new file mode 100644
index 000..8fedc4f
--- /dev/null
+++ b/drivers/usb/mux/Kconfig
@@ -0,0 +1,9 @@
+#
+# USB port mux driver configuration
+#
+menu "USB Port MUX drivers"
+config INTEL_USB_MUX
+   select EXTCON
+   def_bool n
+
+endmenu
diff --git a/drivers/usb/mux/Makefile b/drivers/usb/mux/Makefile
new file mode 100644
index 000..84f0ae8
--- /dev/null
+++ b/drivers/usb/mux/Makefile
@@ -0,0 +1,4 @@
+#
+# Makefile for USB port mux drivers
+#
+obj-$(CONFIG_INTEL_USB_MUX)+= intel-mux.o
diff --git a/drivers/usb/mux/intel-mux.c b/drivers/usb/mux/intel-mux.c
new file mode 100644
index 000..b243758
--- /dev/null
+++ b/drivers/usb/mux/intel-mux.c
@@ -0,0 +1,166 @@
+/**
+ * mux.c - USB Port Mux support
+ *
+ * Copyright (C) 2016 Intel Corporation
+ *
+ * Author: Lu Baolu 
+ *
+ * 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 
+
+struct intel_usb_mux {
+   struct intel_mux_dev*umdev;
+   struct notifier_block   nb;
+   struct extcon_sp

[PATCH v3 7/7] mfd: intel_vuport: Add Intel virtual USB port MFD Driver

[Lu Baolu]

Some Intel platforms have an USB port mux controlled by GPIOs.
There's a single ACPI platform device that provides both USB ID
extcon device and a USB port mux device. This MFD driver will
split the 2 devices for their respective drivers.

Signed-off-by: Lu Baolu 
Suggested-by: David Cohen 
Reviewed-by: Felipe Balbi 
Signed-off-by: Fengguang Wu 
---
 MAINTAINERS|  6 
 drivers/mfd/Kconfig|  8 +
 drivers/mfd/Makefile   |  1 +
 drivers/mfd/intel-vuport.c | 74 ++
 4 files changed, 89 insertions(+)
 create mode 100644 drivers/mfd/intel-vuport.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 399cefe..1486c80 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5599,6 +5599,12 @@ L:   linux...@vger.kernel.org
 S: Supported
 F: drivers/cpufreq/intel_pstate.c
 
+INTEL VIRTUAL USB PORT DRIVER
+M: Lu Baolu 
+L: linux-...@vger.kernel.org
+S: Supported
+F: drivers/mfd/intel-vuport.c
+
 INTEL FRAMEBUFFER DRIVER (excluding 810 and 815)
 M: Maik Broemme 
 L: linux-fb...@vger.kernel.org
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 9ca66de..48933d4 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1534,5 +1534,13 @@ config MFD_VEXPRESS_SYSREG
  System Registers are the platform configuration block
  on the ARM Ltd. Versatile Express board.
 
+config MFD_INTEL_VUPORT
+   tristate "Intel virtual USB port controller"
+   select MFD_CORE
+   depends on X86 && ACPI
+   help
+ Say Y here to enable support for Intel's dual role port mux
+ controlled by GPIOs.
+
 endmenu
 endif
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 0f230a6..0ccd107 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -198,3 +198,4 @@ intel-soc-pmic-objs := intel_soc_pmic_core.o 
intel_soc_pmic_crc.o
 intel-soc-pmic-$(CONFIG_INTEL_PMC_IPC) += intel_soc_pmic_bxtwc.o
 obj-$(CONFIG_INTEL_SOC_PMIC)   += intel-soc-pmic.o
 obj-$(CONFIG_MFD_MT6397)   += mt6397-core.o
+obj-$(CONFIG_MFD_INTEL_VUPORT) += intel-vuport.o
diff --git a/drivers/mfd/intel-vuport.c b/drivers/mfd/intel-vuport.c
new file mode 100644
index 000..a07920f
--- /dev/null
+++ b/drivers/mfd/intel-vuport.c
@@ -0,0 +1,74 @@
+/*
+ * MFD driver for Intel virtual USB port
+ *
+ * Copyright(c) 2016 Intel Corporation.
+ * Author: Lu Baolu 
+ *
+ * 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 
+
+/* ACPI GPIO Mappings */
+static const struct acpi_gpio_params id_gpio = { 0, 0, false };
+static const struct acpi_gpio_params vbus_gpio = { 1, 0, false };
+static const struct acpi_gpio_params mux_gpio = { 2, 0, false };
+static const struct acpi_gpio_mapping acpi_usb_gpios[] = {
+   { "id-gpios", &id_gpio, 1 },
+   { "vbus_en-gpios", &vbus_gpio, 1 },
+   { "usb_mux-gpios", &mux_gpio, 1 },
+   { },
+};
+
+static const struct mfd_cell intel_vuport_mfd_cells[] = {
+   { .name = "extcon-usb-gpio", },
+   { .name = "intel-mux-gpio", },
+};
+
+static int vuport_probe(struct platform_device *pdev)
+{
+   struct device *dev = &pdev->dev;
+   int ret;
+
+   ret = acpi_dev_add_driver_gpios(ACPI_COMPANION(dev), acpi_usb_gpios);
+   if (ret)
+   return ret;
+
+   return mfd_add_devices(&pdev->dev, 0, intel_vuport_mfd_cells,
+   ARRAY_SIZE(intel_vuport_mfd_cells), NULL, 0,
+   NULL);
+}
+
+static int vuport_remove(struct platform_device *pdev)
+{
+   mfd_remove_devices(&pdev->dev);
+   acpi_dev_remove_driver_gpios(ACPI_COMPANION(&pdev->dev));
+
+   return 0;
+}
+
+static struct acpi_device_id vuport_acpi_match[] = {
+   { "INT3496" },
+   { }
+};
+MODULE_DEVICE_TABLE(acpi, vuport_acpi_match);
+
+static struct platform_driver vuport_driver = {
+   .driver = {
+   .name = "intel-vuport",
+   .acpi_match_table = ACPI_PTR(vuport_acpi_match),
+   },
+   .probe = vuport_probe,
+   .remove = vuport_remove,
+};
+
+module_platform_driver(vuport_driver);
+
+MODULE_AUTHOR("Lu Baolu ");
+MODULE_DESCRIPTION("Intel virtual USB port");
+MODULE_LICENSE("GPL v2");
-- 
2.1.4

Re: [PATCHv3 02/13] scripts/gdb: Provide kernel list item generators

[Kieran Bingham]

On 08/03/16 10:47, Jeff Mahoney wrote:
> On 3/3/16 6:40 AM, Kieran Bingham wrote:
>> Facilitate linked-list items by providing a generator to return
>> the dereferenced, and type-cast objects from a kernel linked list
>>
>> CC: Jeff Mahoney 
>>
>> Signed-off-by: Kieran Bingham 
>> ---
>> Changes since v1:
>>  * items function removed, and replaced with Jeff Mahoney's cleaner
>>implementations of list_for_each, and list_for_each_entry
>> ---
>>  scripts/gdb/linux/lists.py | 20 
>>  1 file changed, 20 insertions(+)
>>
>> diff --git a/scripts/gdb/linux/lists.py b/scripts/gdb/linux/lists.py
>> index 3a3775bc162b..9f4503738e26 100644
>> --- a/scripts/gdb/linux/lists.py
>> +++ b/scripts/gdb/linux/lists.py
>> @@ -18,6 +18,26 @@ from linux import utils
>>  list_head = utils.CachedType("struct list_head")
>>  
>>  
>> +def list_for_each(head):
>> +if head.type == list_head.get_type().pointer():
>> +head = head.dereference()
>> +elif head.type != list_head.get_type():
>> +raise gdb.GdbError("Must be struct list_head not %s" % 
>> list_head.type)
> 
> Shouldn't this be % head.type?


Ahh yes, good spot thanks!

> 
>> +
>> +node = head['next'].dereference()
>> +while node.address != head.address:
>> +yield node.address
>> +node = node['next'].dereference()
>> +
>> +
>> +def list_for_each_entry(head, gdbtype, member):
>> +for node in list_for_each(head):
>> +if node.type != list_head.get_type().pointer():
>> +raise TypeError("Type %s found. "
>> +"Expected struct list_head *." % node.type)
> 
> Nit, but FWIW, I've adopted the kernel style of always keeping strings
> on one line so they're easily greppable.

Absolutely! good point. Looks like I was trying to make things fit for
the PEP8 tool. Not sure why I didn't pull just the arg to the next line.

Fixed up locally for the next spin.

Also I think as the rest of the kernel python code is using .format() it
probably makes sense to swap that too to match.

> 
> -Jeff
> 


Thanks for the eyes.

Regards
--
Kieran

[PATCH v3 4/7] usb: mux: add driver for Intel gpio controlled port mux

[Lu Baolu]

In some Intel platforms, a single usb port is shared between USB host
and device controller. The shared port is under control of GPIO pins.

This patch adds the support for USB GPIO controlled port mux.

Signed-off-by: David Cohen 
Signed-off-by: Lu Baolu 
Reviewed-by: Heikki Krogerus 
Reviewed-by: Felipe Balbi 
Signed-off-by: Fengguang Wu 
---
 MAINTAINERS  |   1 +
 drivers/usb/mux/Kconfig  |   9 +++
 drivers/usb/mux/Makefile |   1 +
 drivers/usb/mux/intel-mux-gpio.c | 125 +++
 4 files changed, 136 insertions(+)
 create mode 100644 drivers/usb/mux/intel-mux-gpio.c

diff --git a/MAINTAINERS b/MAINTAINERS
index a93d26a..ab876eb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11406,6 +11406,7 @@ L:  linux-...@vger.kernel.org
 S: Supported
 F: drivers/usb/mux/intel-mux.c
 F: include/linux/usb/intel-mux.h
+F: drivers/usb/mux/intel-mux-gpio.c
 
 USB PRINTER DRIVER (usblp)
 M: Pete Zaitcev 
diff --git a/drivers/usb/mux/Kconfig b/drivers/usb/mux/Kconfig
index 8fedc4f..060bf5c 100644
--- a/drivers/usb/mux/Kconfig
+++ b/drivers/usb/mux/Kconfig
@@ -6,4 +6,13 @@ config INTEL_USB_MUX
select EXTCON
def_bool n
 
+config INTEL_MUX_GPIO
+   tristate "Intel dual role port mux controlled by GPIOs"
+   depends on GPIOLIB
+   depends on X86 && ACPI
+   select INTEL_USB_MUX
+   help
+ Say Y here to enable support for Intel dual role port mux
+ controlled by GPIOs.
+
 endmenu
diff --git a/drivers/usb/mux/Makefile b/drivers/usb/mux/Makefile
index 84f0ae8..66f765c 100644
--- a/drivers/usb/mux/Makefile
+++ b/drivers/usb/mux/Makefile
@@ -2,3 +2,4 @@
 # Makefile for USB port mux drivers
 #
 obj-$(CONFIG_INTEL_USB_MUX)+= intel-mux.o
+obj-$(CONFIG_INTEL_MUX_GPIO)   += intel-mux-gpio.o
diff --git a/drivers/usb/mux/intel-mux-gpio.c b/drivers/usb/mux/intel-mux-gpio.c
new file mode 100644
index 000..adcb496
--- /dev/null
+++ b/drivers/usb/mux/intel-mux-gpio.c
@@ -0,0 +1,125 @@
+/*
+ * USB Dual Role Port Mux driver controlled by gpios
+ *
+ * Copyright (c) 2016, Intel Corporation.
+ * Author: David Cohen 
+ * Author: Lu Baolu 
+ *
+ * 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 
+
+struct vuport {
+   struct intel_mux_dev umdev;
+   struct gpio_desc *gpio_vbus_en;
+   struct gpio_desc *gpio_usb_mux;
+};
+
+/*
+ * id == 0, HOST connected, USB port should be set to peripheral
+ * id == 1, HOST disconnected, USB port should be set to host
+ *
+ * Peripheral: set USB mux to peripheral and disable VBUS
+ * Host: set USB mux to host and enable VBUS
+ */
+static inline int vuport_set_port(struct intel_mux_dev *umdev, int id)
+{
+   struct vuport *vup = container_of(umdev, struct vuport, umdev);
+
+   dev_dbg(umdev->dev, "USB PORT ID: %s\n", id ? "HOST" : "PERIPHERAL");
+
+   gpiod_set_value_cansleep(vup->gpio_usb_mux, !id);
+   gpiod_set_value_cansleep(vup->gpio_vbus_en, id);
+
+   return 0;
+}
+
+static int vuport_cable_set(struct intel_mux_dev *umdev)
+{
+   return vuport_set_port(umdev, 1);
+}
+
+static int vuport_cable_unset(struct intel_mux_dev *umdev)
+{
+   return vuport_set_port(umdev, 0);
+}
+
+static int vuport_probe(struct platform_device *pdev)
+{
+   struct intel_mux_dev *umdev;
+   struct device *dev = &pdev->dev;
+   struct vuport *vup;
+
+   vup = devm_kzalloc(dev, sizeof(*vup), GFP_KERNEL);
+   if (!vup)
+   return -ENOMEM;
+
+   /* retrieve vbus and mux gpios */
+   vup->gpio_vbus_en = devm_gpiod_get_optional(dev,
+   "vbus_en", GPIOD_ASIS);
+   if (IS_ERR(vup->gpio_vbus_en))
+   return PTR_ERR(vup->gpio_vbus_en);
+
+   vup->gpio_usb_mux = devm_gpiod_get_optional(dev,
+   "usb_mux", GPIOD_ASIS);
+   if (IS_ERR(vup->gpio_usb_mux))
+   return PTR_ERR(vup->gpio_usb_mux);
+
+   /* populate the mux generic structure */
+   umdev = &vup->umdev;
+   umdev->dev = dev;
+   umdev->cable_name = "USB-HOST";
+   umdev->cable_set_cb = vuport_cable_set;
+   umdev->cable_unset_cb = vuport_cable_unset;
+
+   return intel_usb_mux_register(umdev);
+}
+
+static int vuport_remove(struct platform_device *pdev)
+{
+   return intel_usb_mux_unregister(&pdev->dev);
+}
+
+#ifdef CONFIG_PM_SLEEP
+/*
+ * In case a micro A cable was plugged in while device was sleeping,
+ * we missed the interrupt. We need to poll usb id gpio when waking the
+ * driver to detect the missed event.
+ * We use 'complete' callback to give time to all extcon listeners to
+ * resume before we send new events.
+ */
+static const struct dev_pm_ops vuport_pm_ops = {
+   .complete = intel_usb_mux_complete,
+};
+#endif
+
+sta

[PATCH v3 0/7] usb: add support for Intel dual role port mux

[Lu Baolu]

Intel SOC chips are featured with USB dual role. The host role is
provided by Intel xHCI IP, and the gadget role is provided by IP
from designware. Tablet platform designs always share a single
port for both host and gadget controllers. There is a mux to
switch the port to the right controller according to the cable
type. OS needs to provide the callback to control the mux when
a plug-in event raises. The method to control the mux is platform
dependent. At least three types of implementation can be found
across current devices. 1) GPIO pins; 2) a unit which can be
controlled by memory mapped registers; 3) ACPI ASL code.

This patch series adds supports for Intel dual role port mux.
It includes:
(1) A helper layer on top of extcon for individual mux driver.
It listens to the USB-HOST extcon cable and call the switch
call-back when the cable state changes.
(2) Drivers for GPIO controlled port mux which could be found on
Baytrail devices. A mfd driver is used to split the GPIOs into
USB gpio extcon device and a USB mux device. Driver for USB
gpio extcon device is already in upstream Linux. This patch
series includes a driver for GPIO USB mux.
(3) Drivers for USB port mux controlled through memory mapped
registers and the logic to create the mux device. This type
of dual role port mux could be found in Cherry Trail and
Broxton devices.

Lu Baolu (7):
  extcon: usb-gpio: add device binding for platform device
  extcon: usb-gpio: add support for ACPI gpio interface
  usb: mux: add common code for Intel dual role port mux
  usb: mux: add driver for Intel gpio controlled port mux
  usb: mux: add driver for Intel drcfg controlled port mux
  usb: pci-quirks: add Intel USB drcfg mux device
  mfd: intel_vuport: Add Intel virtual USB port MFD Driver

 Documentation/ABI/testing/sysfs-bus-platform |  15 +++
 MAINTAINERS  |  15 +++
 drivers/extcon/extcon-usb-gpio.c |  10 +-
 drivers/mfd/Kconfig  |   8 ++
 drivers/mfd/Makefile |   1 +
 drivers/mfd/intel-vuport.c   |  74 
 drivers/usb/Kconfig  |   2 +
 drivers/usb/Makefile |   1 +
 drivers/usb/host/pci-quirks.c|  47 +++-
 drivers/usb/host/xhci-ext-caps.h |   2 +
 drivers/usb/mux/Kconfig  |  25 
 drivers/usb/mux/Makefile |   6 +
 drivers/usb/mux/intel-mux-drcfg.c| 161 ++
 drivers/usb/mux/intel-mux-gpio.c | 125 
 drivers/usb/mux/intel-mux.c  | 166 +++
 include/linux/usb/intel-mux.h|  47 
 16 files changed, 702 insertions(+), 3 deletions(-)
 create mode 100644 drivers/mfd/intel-vuport.c
 create mode 100644 drivers/usb/mux/Kconfig
 create mode 100644 drivers/usb/mux/Makefile
 create mode 100644 drivers/usb/mux/intel-mux-drcfg.c
 create mode 100644 drivers/usb/mux/intel-mux-gpio.c
 create mode 100644 drivers/usb/mux/intel-mux.c
 create mode 100644 include/linux/usb/intel-mux.h

Change log:
v2->v3:
 - uvport mfd driver got reviewed by Lee Jones, the following
   changes were made accordingly.
 - seperate uvport driver from the mux drivers in MAINTAINERS file
 - refine the description in Kconfig
 - refine the mfd_cell structure data

v1->v2:
 - move mux driver from drivers/usb/misc to drivers/usb/mux;
 - replace debugfs with sysfs for user level mux control;
 - remove unnecessary register restore if mux registeration failed;
 - Add "Acked-by: Chanwoo Choi " to extcon changes;
 - Make the file names and exported function names more specific;
 - Remove the usb_mux_get_dev() interface;
 - Move "struct intel_usb_mux" from .h to .c file;
 - Fix various kbuild robot warnings.
-- 
2.1.4

Re: [PATCH] dma: sun4i: expose block size and wait cycle configuration to DMA users

[Maxime Ripard]

On Tue, Mar 08, 2016 at 08:25:47AM +0530, Vinod Koul wrote:
> On Mon, Mar 07, 2016 at 09:30:24PM +0100, Maxime Ripard wrote:
> > On Mon, Mar 07, 2016 at 04:08:57PM +0100, Boris Brezillon wrote:
> > > Hi Vinod,
> > > 
> > > On Mon, 7 Mar 2016 20:24:29 +0530
> > > Vinod Koul  wrote:
> > > 
> > > > On Mon, Mar 07, 2016 at 10:59:31AM +0100, Boris Brezillon wrote:
> > > > > +/* Dedicated DMA parameter register layout */
> > > > > +#define SUN4I_DDMA_PARA_DST_DATA_BLK_SIZE(n) (((n) - 1) << 24)
> > > > > +#define SUN4I_DDMA_PARA_DST_WAIT_CYCLES(n)   (((n) - 1) << 16)
> > > > > +#define SUN4I_DDMA_PARA_SRC_DATA_BLK_SIZE(n) (((n) - 1) << 8)
> > > > > +#define SUN4I_DDMA_PARA_SRC_WAIT_CYCLES(n)   (((n) - 1) << 0)
> > > > > +
> > > > > +/**
> > > > > + * struct sun4i_dma_chan_config - DMA channel config
> > > > > + *
> > > > > + * @para: contains information about block size and time before 
> > > > > checking
> > > > > + * DRQ line. This is device specific and only applicable to 
> > > > > dedicated
> > > > > + * DMA channels
> > > > 
> > > > What information, can you elobrate.. And why can't you use existing
> > > > dma_slave_config for this?
> > > 
> > > Block size is related to the device FIFO size. I guess it allows the
> > > DMA channel to launch a transfer of X bytes without having to check the
> > > DRQ line (the line telling the DMA engine it can transfer more data
> > > to/from the device). The wait cycles information is apparently related
> > > to the number of clks the engine should wait before polling/checking
> > > the DRQ line status between each block transfer. I'm not sure what it
> > > saves to put WAIT_CYCLES() to something != 1, but in their BSP,
> > > Allwinner tweak that depending on the device.
> 
> we already have block size aka src/dst_maxburst, why not use that one.

I'm not sure it's really the same thing. The DMA controller also has a
burst parameter, that is either 1 byte or 8 bytes, and ends up being
different from this one.

> Why does dmaengine need to wait? Can you explain that

We have no idea, we thought you might have one :)

It doesn't really makes sense to us, but it does have a significant
impact on the throughput.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [PATCH v2 7/7] mfd: intel_vuport: Add Intel virtual USB port MFD Driver

[Lu Baolu]

On 03/08/2016 12:40 PM, Lee Jones wrote:
> On Mon, 07 Mar 2016, Lu Baolu wrote:
>
>> Some Intel platforms have an USB port mux controlled by GPIOs.
>> There's a single ACPI platform device that provides both USB ID
>> extcon device and a USB port mux device. This MFD driver will
>> split the 2 devices for their respective drivers.
>>
>> Signed-off-by: Lu Baolu 
>> Suggested-by: David Cohen 
>> Reviewed-by: Felipe Balbi 
>> Signed-off-by: Fengguang Wu 
>> ---
>>  MAINTAINERS|  1 +
>>  drivers/mfd/Kconfig|  8 +
>>  drivers/mfd/Makefile   |  1 +
>>  drivers/mfd/intel-vuport.c | 78 
>> ++
>>  4 files changed, 88 insertions(+)
>>  create mode 100644 drivers/mfd/intel-vuport.c
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 399cefe..1671a4d 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -11408,6 +11408,7 @@ F:   drivers/usb/mux/intel-mux.c
>>  F:  include/linux/usb/intel-mux.h
>>  F:  drivers/usb/mux/intel-mux-gpio.c
>>  F:  drivers/usb/mux/intel-mux-drcfg.c
>> +F:  drivers/mfd/intel-vuport.c
> Separate patch please.

Sure.

>
>>  USB PRINTER DRIVER (usblp)
>>  M:  Pete Zaitcev 
>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>> index 9ca66de..8dd1bf3 100644
>> --- a/drivers/mfd/Kconfig
>> +++ b/drivers/mfd/Kconfig
>> @@ -1534,5 +1534,13 @@ config MFD_VEXPRESS_SYSREG
>>System Registers are the platform configuration block
>>on the ARM Ltd. Versatile Express board.
>>  
>> +config MFD_INTEL_VUPORT
>> +tristate "Intel virtual USB port controller"
>> +select MFD_CORE
>> +depends on X86 && ACPI
>> +help
>> +  Say Y here to enable support for Intel dual role port mux
> Either "Intel's" or "the Intel".

I will change it to "Intel's".

>
>> +  controlled by 3 GPIOs.
>> +
>>  endmenu
>>  endif
>> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
>> index 0f230a6..0ccd107 100644
>> --- a/drivers/mfd/Makefile
>> +++ b/drivers/mfd/Makefile
>> @@ -198,3 +198,4 @@ intel-soc-pmic-objs  := 
>> intel_soc_pmic_core.o intel_soc_pmic_crc.o
>>  intel-soc-pmic-$(CONFIG_INTEL_PMC_IPC)  += intel_soc_pmic_bxtwc.o
>>  obj-$(CONFIG_INTEL_SOC_PMIC)+= intel-soc-pmic.o
>>  obj-$(CONFIG_MFD_MT6397)+= mt6397-core.o
>> +obj-$(CONFIG_MFD_INTEL_VUPORT)  += intel-vuport.o
>> diff --git a/drivers/mfd/intel-vuport.c b/drivers/mfd/intel-vuport.c
>> new file mode 100644
>> index 000..1371099
>> --- /dev/null
>> +++ b/drivers/mfd/intel-vuport.c
>> @@ -0,0 +1,78 @@
>> +/*
>> + * MFD driver for Intel virtual USB port
>> + *
>> + * Copyright(c) 2016 Intel Corporation.
>> + * Author: Lu Baolu 
>> + *
>> + * 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 
>> +
>> +/* ACPI GPIO Mappings */
>> +static const struct acpi_gpio_params id_gpio = { 0, 0, false };
>> +static const struct acpi_gpio_params vbus_gpio = { 1, 0, false };
>> +static const struct acpi_gpio_params mux_gpio = { 2, 0, false };
>> +static const struct acpi_gpio_mapping acpi_usb_gpios[] = {
>> +{ "id-gpios", &id_gpio, 1 },
>> +{ "vbus_en-gpios", &vbus_gpio, 1 },
>> +{ "usb_mux-gpios", &mux_gpio, 1 },
>> +{ },
>> +};
>> +
>> +static const struct mfd_cell intel_vuport_mfd_cells[] = {
>> +{
>> +.name = "extcon-usb-gpio",
>> +},
>> +{
>> +.name = "intel-mux-gpio",
>> +},
>> +};
> Please place single line entries on the same line as the '{' and '}'.
>
> As you have above.

Sure.

>
>> +static int vuport_probe(struct platform_device *pdev)
>> +{
>> +struct device *dev = &pdev->dev;
>> +int ret;
>> +
>> +ret = acpi_dev_add_driver_gpios(ACPI_COMPANION(dev), acpi_usb_gpios);
>> +if (ret)
>> +return ret;
>> +
>> +return mfd_add_devices(&pdev->dev, 0, intel_vuport_mfd_cells,
>> +ARRAY_SIZE(intel_vuport_mfd_cells), NULL, 0,
>> +NULL);
>> +}
>> +
>> +static int vuport_remove(struct platform_device *pdev)
>> +{
>> +mfd_remove_devices(&pdev->dev);
>> +acpi_dev_remove_driver_gpios(ACPI_COMPANION(&pdev->dev));
>> +
>> +return 0;
>> +}
>> +
>> +static struct acpi_device_id vuport_acpi_match[] = {
>> +{ "INT3496" },
>> +{ }
>> +};
>> +MODULE_DEVICE_TABLE(acpi, vuport_acpi_match);
>> +
>> +static struct platform_driver vuport_driver = {
>> +.driver = {
>> +.name = "intel-vuport",
>> +.acpi_match_table = ACPI_PTR(vuport_acpi_match),
>> +},
>> +.probe = vuport_probe,
>> +.remove = vuport_remove,
>> +};
>> +
>> +module_platform_driver(vuport_driver);
>> +
>> +MODULE_AUTHOR("Lu Baolu ");
>> +MODULE_DESCRIPTION("Intel virtual USB port");
>> +MODULE_LICENSE("GPL v2");

Re: [PATCH 03/15] perf session: Simplify tool stubs

[Adrian Hunter]

On 07/03/16 21:44, Arnaldo Carvalho de Melo wrote:
> From: Adrian Hunter 

Very sorry, but I just noticed that this and patch 5 (perf jit: Move clockid
validation) have the wrong email address for the "From" and "Signed-off-by".
 It should be adrian.hun...@intel.com.  Please consider changing it or
dropping these patches for now.

> 
> Some of the stubs are identical so just have one function for them.
> 
> Signed-off-by: Adrian Hunter 
> Cc: Jiri Olsa 
> Cc: Stephane Eranian 
> Link: 
> http://lkml.kernel.org/r/1457005856-6143-3-git-send-email-adrian.hun...@intel.com
> Signed-off-by: Arnaldo Carvalho de Melo 

Re: Suspicious error for CMA stress test

[Joonsoo Kim]

On Mon, Mar 07, 2016 at 01:59:12PM +0100, Vlastimil Babka wrote:
> On 03/07/2016 05:34 AM, Joonsoo Kim wrote:
> >On Fri, Mar 04, 2016 at 03:35:26PM +0800, Hanjun Guo wrote:
> >>>Sad to hear that.
> >>>
> >>>Could you tell me your system's MAX_ORDER and pageblock_order?
> >>>
> >>
> >>MAX_ORDER is 11, pageblock_order is 9, thanks for your help!
> 
> I thought that CMA regions/operations (and isolation IIRC?) were
> supposed to be MAX_ORDER aligned exactly to prevent needing these
> extra checks for buddy merging. So what's wrong?

CMA isolates MAX_ORDER aligned blocks, but, during the process,
partialy isolated block exists. If MAX_ORDER is 11 and
pageblock_order is 9, two pageblocks make up MAX_ORDER
aligned block and I can think following scenario because pageblock
(un)isolation would be done one by one.

(each character means one pageblock. 'C', 'I' means MIGRATE_CMA,
MIGRATE_ISOLATE, respectively.

CC -> IC -> II (Isolation)
II -> CI -> CC (Un-isolation)

If some pages are freed at this intermediate state such as IC or CI,
that page could be merged to the other page that is resident on
different type of pageblock and it will cause wrong freepage count.

If we don't release zone lock during whole isolation process, there
would be no problem and CMA can use that implementation. But,
isolation is used by another feature and I guess it cannot use that
kind of implementation.

Thanks.

Re: [PATCH 4/5] usb: gadget: f_midi: cleanups and typos fixes

[Felipe Balbi]

Hi,

Felipe Ferreri Tonello  writes:
>>> On March 5, 2016 4:28:45 PM GMT+00:00, Michal Nazarewicz 
>>>  wrote:
>> On Wed, Mar 02 2016, Felipe F. Tonello wrote:
>>> @@ -16,7 +16,7 @@
>>>   *   Copyright (C) 2006 Thumtronics Pty Ltd.
>>>   *   Ben Williamson 
>>>   *
>>> - * Licensed under the GPL-2 or later.
>>> + * Licensed under the GPLv2.

> On March 4, 2016 7:17:31 PM GMT+00:00, Michal Nazarewicz
  wrote:
>> Any particular reason to do that?

 On Fri, Mar 04 2016, Felipe Ferreri Tonello wrote:
> Because the kernel is v2 only and not later. 

 Linux as a whole is GPLv2 only, but that doesn’t necessarily mean that
 parts of it cannot be dual licensed (or GPLv2+).  It’s safer to leave
 copyright noticed clear unless you explicitly want your contribution be
 GPLv2 only which brings the whole file GPLv2 only.

> I just tried to make this driver more consistent with the coding
 style
> used across the kernel. That's it.

 Column alignment of field names or RHS of assignment operators is quite
 inconsistent already within drivers/usb/gadget/ which is why I’m
 concerned whether this is really helping.

 Anyway, I actually don’t care much, just adding my two rappen.
>>>
>>> Right, I am ok with Balbi completely ignoring this patch. But I prefer
>>> to have at least this driver consistent than nothing. Of course I'll
>>> remove the license change I made.
>> 
>> consistent in what way ?
>
> Source-code.
>
> The goal of this patch is to update this driver coding style to promote
> consistency, readability, and maintainability based on the Linux coding
> style.
>
> If this patch does not achieving that or if that is not necessary, than
> just ignore this patch.

yeah, I don't think that's what you're doing here.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] HID: multitouch: force retrieving of Win8 signature blob

[Benjamin Tissoires]

On Mar 07 2016 or thereabouts, Jiri Kosina wrote:
> On Mon, 7 Mar 2016, Benjamin Tissoires wrote:
> 
> > The Synaptics 0x11e5 over I2C found in the Asus T100-CHI requires to
> > fetch the signature blob to actually start sending events.
> > 
> > With this patch, we should be close enough to the Windows driver which
> > checks the content of the blob at plugin to validate or not the
> > touchscreen.
> 
> I have brought the 'Link' and 'Fixes' headers into slightly better shape 
> :) and applied.

Hehe. That seems better now, indeed.

> 
> I will likely not be pushing this to Linus this week, but will make sure 
> this ends up in -stable once this lands in his tree during the upcoming 
> merge window, if you agree?

OK for me. Thanks!

Cheers,
Benjamin

Re: [PATCH 3/5] usb: gadget: gmidi: remove bus powered requirement on bmAttributes

[Felipe Balbi]

Hi,

Felipe Ferreri Tonello  writes:
>>> @@ -63,6 +63,14 @@ static unsigned int out_ports = 1;
>>>  module_param(out_ports, uint, S_IRUGO);
>>>  MODULE_PARM_DESC(out_ports, "Number of MIDI output ports");
>>>  
>>> +static unsigned int bmAttributes = USB_CONFIG_ATT_ONE;
>>> +module_param(bmAttributes, uint, S_IRUGO);
>>> +MODULE_PARM_DESC(bmAttributes, "Configuration Descriptor's
>> bmAttributes parameter");
>>> +
>>> +static unsigned int MaxPower = CONFIG_USB_GADGET_VBUS_DRAW;
>>> +module_param(MaxPower, uint, S_IRUGO);
>>> +MODULE_PARM_DESC(MaxPower, "Used to calculate Configuration
>> Descriptor's bMaxPower parameter");
>>
>> you didn't run checkpatch, did you ? Also, are you sure you will need
>> to
>> change this by simply reloading the module ? I'm not convinced.
>
> Yes I always run checkpatch :)

 do you really ? Why do you have a 98-character line, then ?

btw, you didn't reply this ^^

>>> @@ -119,8 +127,8 @@ static struct usb_configuration midi_config = {
>>> .label  = "MIDI Gadget",
>>> .bConfigurationValue = 1,
>>> /* .iConfiguration = DYNAMIC */
>>> -   .bmAttributes   = USB_CONFIG_ATT_ONE,
>>
>> nack, nackety nack nack nack :-)
>>
>> USB_CONFIG_ATT_ONE *must* always be set. With your module parameter you
>> give users the oportunity to violate USB spec.
>
> You are right. It needs to check the value before it assigns to
> bmAttributes.

 why check ? You can just unconditionally or USB_CONFIG_ATT_ONE. In any
 case, I'm not convinced this is necessary at all.
>>>
>>> Right.
>>>
>>> This is necessary because this driver is actually wrong in which is
>>> asking for the host to power itself. This is not specified on USB-MIDI
>>> specification, neither makes any sense since this configuration is
>>> device specific.
>>>
>>> What is your suggestion to make it configurable? Maybe at compile-time?
>>> I really don't know what is the best solution if this is not something
>>> you like it.
>> 
>> well, you could use our configfs-based gadget interface. You don't
>> really need to use gmidi.ko at all. In fact, we wanna do away with any
>> static modules and rely only on configfs. If configfs doesn't let you
>> change what you want/need, then we can talk about adding support for
>> those.
>> 
>> bMaxPower and bmAttributes sound like good things to have configurable
>> over configfs but beware of what the USB specification says about them,
>> we cannot let users violate the spec by passing bogus values on these
>> fields.
>
> I agree that we should move to configfs, but the truth is that these
> legacy devices are still useful. They just do one thing, mostly, but

yes, they are useful as they are. They don't need to be changed to be
useful. Plus, you can have a gadget built with configfs that does only
one thing. And you can do that with a simple shell script.

> its easy and simple to setup and use. So I think before we have some

so is configfs.

> sort of preset library of configfs-based gadget drivers, we still need
> these modules.

there is already a library called libusbg.

> Any suggestions on that?
>
> Do you want to support what I am proposing for gmidi.ko or just ignore
> it and move on to configfs?

I prefer to not touch these gadget drivers if at all necessary. If you
fixing a bug, then sure we must fix bugs. But you're not fixing a bug
and, on top of that, you're adding regressions and violating the USB
spec. This shows that you're writing these patches without knowing
(and/or even caring about) the specification at all.

Here's some enlightening presentation you probably wanna watch:

https://www.youtube.com/watch?v=fMeH7wqOwXA

TL;DR : this project is large and you need to convince me we need your
code/patch.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v1 1/1] mfd: intel-lpss: Pass I2C configuration via properties on BXT

[Mika Westerberg]

On Tue, Jan 26, 2016 at 02:17:49PM +0200, Andy Shevchenko wrote:
> From: Mika Westerberg 
> 
> I2C host controller need to be configured properly in order to meet I2C
> timings specified in the I2C protocol specification. Some Intel Broxton
> based machines do not have this information in the ACPI namespace (or the
> boot firmware does not support ACPI at all) so we use build-in device
> properties instead.
> 
> Signed-off-by: Mika Westerberg 
> Signed-off-by: Andy Shevchenko 

Hi Lee,

Any comments on this patch? If not, could you consider applying it to
the MFD tree?

Thanks.

> ---
>  drivers/mfd/intel-lpss-acpi.c | 12 
>  drivers/mfd/intel-lpss-pci.c  | 12 
>  2 files changed, 24 insertions(+)
> 
> diff --git a/drivers/mfd/intel-lpss-acpi.c b/drivers/mfd/intel-lpss-acpi.c
> index 06f00d6..5a8d9c7 100644
> --- a/drivers/mfd/intel-lpss-acpi.c
> +++ b/drivers/mfd/intel-lpss-acpi.c
> @@ -44,8 +44,20 @@ static const struct intel_lpss_platform_info bxt_info = {
>   .clk_rate = 1,
>  };
>  
> +static struct property_entry bxt_i2c_properties[] = {
> + PROPERTY_ENTRY_U32("i2c-sda-hold-time-ns", 42),
> + PROPERTY_ENTRY_U32("i2c-sda-falling-time-ns", 171),
> + PROPERTY_ENTRY_U32("i2c-scl-falling-time-ns", 208),
> + { },
> +};
> +
> +static struct property_set bxt_i2c_pset = {
> + .properties = bxt_i2c_properties,
> +};
> +
>  static const struct intel_lpss_platform_info bxt_i2c_info = {
>   .clk_rate = 13300,
> + .pset = &bxt_i2c_pset,
>  };
>  
>  static const struct acpi_device_id intel_lpss_acpi_ids[] = {
> diff --git a/drivers/mfd/intel-lpss-pci.c b/drivers/mfd/intel-lpss-pci.c
> index a7136c7..92b456f 100644
> --- a/drivers/mfd/intel-lpss-pci.c
> +++ b/drivers/mfd/intel-lpss-pci.c
> @@ -107,8 +107,20 @@ static const struct intel_lpss_platform_info 
> bxt_uart_info = {
>   .pset = &uart_pset,
>  };
>  
> +static struct property_entry bxt_i2c_properties[] = {
> + PROPERTY_ENTRY_U32("i2c-sda-hold-time-ns", 42),
> + PROPERTY_ENTRY_U32("i2c-sda-falling-time-ns", 171),
> + PROPERTY_ENTRY_U32("i2c-scl-falling-time-ns", 208),
> + { },
> +};
> +
> +static struct property_set bxt_i2c_pset = {
> + .properties = bxt_i2c_properties,
> +};
> +
>  static const struct intel_lpss_platform_info bxt_i2c_info = {
>   .clk_rate = 13300,
> + .pset = &bxt_i2c_pset,
>  };
>  
>  static const struct pci_device_id intel_lpss_pci_ids[] = {
> -- 
> 2.7.0.rc3

Re: [PATCH v5 3/9] dma-mapping: add dma_{map,unmap}_resource

[Christoph Hellwig]

Please add some documentation on where/how this should be used.  It's
not a very obvious interface.

Re: [PATCH] scripts/dtc: Update to upstream version 53bf130b1cdd

[Rob Herring]

On Mon, Mar 7, 2016 at 5:10 PM, Olof Johansson  wrote:
> Hi,
>
> On Fri, Mar 4, 2016 at 7:13 AM, Rob Herring  wrote:
>> Sync to upstream dtc commit 53bf130b1cdd ("libfdt: simplify
>> fdt_node_check_compatible()"). This adds the following commits from
>> upstream:
>>
>> 53bf130 libfdt: simplify fdt_node_check_compatible()
>> c9d9121 Warn on node name unit-address presence/absence mismatch
>> 2e53f9d Catch unsigned 32bit overflow when parsing flattened device tree 
>> offsets
>>
>> Signed-off-by: Rob Herring 
>> ---
>> As usual, this is just an automated copy of upstream dtc into the kernel
>> tree. The changeset is small enough that I have left it here.
>>
>> The main reason for this sync is to pick-up the new unit-address
>> warnings.
>
> This spews a crazy amount of warnings on a multi_v7_defconfig build.

Shocking, huh? And I've got more checks in the works. :)

> I'd prefer to see most of those warnings fixed _before_ we introduce
> it by default. Otherwise we just add a huge amount of noise that will
> hide any real valid warnings that are now brought up.

How do you propose to do that? If it is not enabled, then no one will
see them nor care. I don't intend to fix everyone's stuff myself. We
could hide the check behind COMPILE_TEST perhaps.

Rob

Re: [PATCH 2/5] usb: gadget: f_midi: added spinlock on transmit function

[Felipe Balbi]

Hi,

Felipe Ferreri Tonello  writes:
> Since f_midi_transmit is called by both ALSA and USB frameworks, it
 can
> potentially cause a race condition between both calls. This is bad
 because the
> way f_midi_transmit is implemented can't handle concurrent calls.
 This is due
> to the fact that the usb request fifo looks for the next element and
 only if
> it has data to process it enqueues the request, otherwise re-uses it.
 If both
> (ALSA and USB) frameworks calls this function at the same time, the
> kfifo_seek() will return the same usb_request, which will cause a
 race
> condition.
>
> To solve this problem a syncronization mechanism is necessary. In
 this case it
> is used a spinlock since f_midi_transmit is also called by
 usb_request->complete
> callback in interrupt context.
>
> On benchmarks realized by me, spinlocks were more efficient then
 scheduling
> the f_midi_transmit tasklet in process context and using a mutex
> to synchronize. Also it performs better then previous
> implementation
 that
> allocated a usb_request for every new transmit made.

 behaves better in what way ? Also, previous implementation would not
 suffer from this concurrency problem, right ?
>>>
>>> The spin lock is faster than allocating usb requests all the time,
>>> even if the udc uses da for it.
>> 
>> did you measure ? Is the extra speed really necessary ? How did you
>> benchmark this ?
>
> Yes I did measure and it was not that significant. This is not about
> speed. There was a bug in that approach that I already explained on

you have very confusing statements. When I mentioned that previous code
wouldn't have the need for the spinlock you replied that spinlock was
faster.

When I asked you about benchmarks you reply saying it's not about the
speed.

Make up your mind dude. What are you trying to achieve ?

> that patch, which was approved and applied BTW.

patches can be reverted if we realise we're better off without
them. Don't get cocky, please.

> Any way, this spinlock should've been there since that patch but I
> couldn't really trigger this problem without a stress test.

which tells me you sent me patches without properly testing. How much
time did it take to trigger this ? How did you trigger this situation ?

> So, this patch fixes a bug in the current implementation.

fixes a regression introduced by you, true. I'm trying to figure out if
we're better off without the original patch; to make a good decision I
need to know if the extra "speed" we get from not allocating requests on
demand are really that important.

So, how much faster did you get and is that extra "speed" really
important ?

-- 
balbi


signature.asc
Description: PGP signature

[v5][PATCH] livepatch/ppc: Enable livepatching on powerpc

[Balbir Singh]

Changelog v5:
1. Removed the mini-stack frame created for klp_return_helper.
   As a result of the mini-stack frame, function with > 8
   arguments could not be patched
2. Removed camel casing in the comments
Changelog v4:
1. Renamed klp_matchaddr() to klp_get_ftrace_location()
   and used it just to convert the function address.
2. Synced klp_write_module_reloc() with s390(); made it
   inline, no error message, return -ENOSYS
3. Added an error message when including
   powerpc/include/asm/livepatch.h without HAVE_LIVEPATCH
4. Update some comments.
Changelog v3:
1. Moved -ENOSYS to -EINVAL in klp_write_module_reloc
2. Moved klp_matchaddr to use ftrace_location_range
Changelog v2:
1. Implement review comments by Michael
2. The previous version compared _NIP from the
   wrong location to check for whether we
   are going to a patched location

This patch enables live patching for powerpc. The current patch
is applied on top of topic/mprofile-kernel at
https://git.kernel.org/cgit/linux/kernel/git/powerpc/linux.git/

This patch builds on top of ftrace with regs changes and the
-mprofile-kernel changes. It detects a change in NIP after
the klp subsystem has potentially changes the NIP as a result
of a livepatch. In that case it saves the TOC in the parents
stack and the offset of the return address from the TOC in
the reserved (CR+4) space. This hack allows us to provide the
complete frame of the calling function as is to the caller
without having to create a mini-frame

Upon return from the patched function, the TOC and correct
LR is restored.

I tested the sample in the livepatch and an additional sample
that patches int_to_scsilun. I'll post out that sample if there
is interest later. I also tested ftrace functionality on the
command line to check for breakage

Signed-off-by: Torsten Duwe 
Signed-off-by: Balbir Singh 
Signed-off-by: Petr Mladek 
---
 arch/powerpc/Kconfig |  3 ++
 arch/powerpc/include/asm/livepatch.h | 47 
 arch/powerpc/kernel/Makefile |  1 +
 arch/powerpc/kernel/entry_64.S   | 60 
 arch/powerpc/kernel/livepatch.c  | 29 +
 include/linux/ftrace.h   |  1 +
 include/linux/livepatch.h|  2 ++
 kernel/livepatch/core.c  | 28 +++--
 kernel/trace/ftrace.c| 14 -
 9 files changed, 181 insertions(+), 4 deletions(-)
 create mode 100644 arch/powerpc/include/asm/livepatch.h
 create mode 100644 arch/powerpc/kernel/livepatch.c

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 91da283..926c0ea 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -159,6 +159,7 @@ config PPC
select ARCH_HAS_DEVMEM_IS_ALLOWED
select HAVE_ARCH_SECCOMP_FILTER
select ARCH_HAS_UBSAN_SANITIZE_ALL
+   select HAVE_LIVEPATCH if HAVE_DYNAMIC_FTRACE_WITH_REGS
 
 config GENERIC_CSUM
def_bool CPU_LITTLE_ENDIAN
@@ -1110,3 +,5 @@ config PPC_LIB_RHEAP
bool
 
 source "arch/powerpc/kvm/Kconfig"
+
+source "kernel/livepatch/Kconfig"
diff --git a/arch/powerpc/include/asm/livepatch.h 
b/arch/powerpc/include/asm/livepatch.h
new file mode 100644
index 000..b9856ce
--- /dev/null
+++ b/arch/powerpc/include/asm/livepatch.h
@@ -0,0 +1,47 @@
+/*
+ * livepatch.h - powerpc-specific Kernel Live Patching Core
+ *
+ * Copyright (C) 2015 SUSE
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
+ */
+#ifndef _ASM_POWERPC64_LIVEPATCH_H
+#define _ASM_POWERPC64_LIVEPATCH_H
+
+#include 
+
+#ifdef CONFIG_LIVEPATCH
+
+static inline int klp_check_compiler_support(void)
+{
+   return 0;
+}
+
+static inline int klp_write_module_reloc(struct module *mod, unsigned long
+   type, unsigned long loc, unsigned long value)
+{
+   /* This requires infrastructure changes; we need the loadinfos. */
+   return -ENOSYS;
+}
+
+static inline void klp_arch_set_pc(struct pt_regs *regs, unsigned long ip)
+{
+   regs->nip = ip;
+}
+
+#else /* CONFIG_LIVEPATCH */
+#error Include linux/livepatch.h, not asm/livepatch.h
+#endif /* CONFIG_LIVEPATCH */
+
+#endif /* _ASM_POWERPC64_LIVEPATCH_H */
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 2da380f..

Re: [PATCH 3/3] pci: move pci_dma_* helpers to common code

[Christoph Hellwig]

On Mon, Mar 07, 2016 at 12:28:48PM -0600, Bjorn Helgaas wrote:
> I wonder if we can consolidate a little more pci_dma_*-related stuff
> in pci-dma-compat.h, e.g.,

Looks fine to me.

[PATCH] Staging: media: davinci_vpfe: Fix spelling error on a comment

[Manuel Rodriguez]

Fix spelling error on a comment, change 'wether' to 'whether'

Signed-off-by: Manuel Rodriguez 
---
 drivers/staging/media/davinci_vpfe/vpfe_video.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/davinci_vpfe/vpfe_video.c 
b/drivers/staging/media/davinci_vpfe/vpfe_video.c
index 0a65405..e4b953a 100644
--- a/drivers/staging/media/davinci_vpfe/vpfe_video.c
+++ b/drivers/staging/media/davinci_vpfe/vpfe_video.c
@@ -195,7 +195,7 @@ static int vpfe_update_pipe_state(struct vpfe_video_device 
*video)
return 0;
 }
 
-/* checks wether pipeline is ready for enabling */
+/* checks whether pipeline is ready for enabling */
 int vpfe_video_is_pipe_ready(struct vpfe_pipeline *pipe)
 {
int i;
-- 
1.9.1

Re: [PATCH V2 2/2] mailbox: Introduce TI message manager driver

[Jassi Brar]

On Tue, Mar 8, 2016 at 2:18 AM, Nishanth Menon  wrote:
> On 03/07/2016 12:31 PM, Jassi Brar wrote:
>> On Fri, Mar 4, 2016 at 8:05 PM, Nishanth Menon  wrote:

> +static int ti_msgmgr_send_data(struct mbox_chan *chan, void *data)
> +{
> +   struct device *dev = chan->mbox->dev;
> +   struct ti_msgmgr_inst *inst = dev_get_drvdata(dev);
> +   const struct ti_msgmgr_desc *desc;
> +   struct ti_queue_inst *qinst = chan->con_priv;
> +   int msg_count, num_words, trail_bytes;
> +   struct ti_msgmgr_message *message = data;
> +   void __iomem *data_reg;
> +   u32 *word_data;
> +
> +   if (WARN_ON(!inst)) {
> +   dev_err(dev, "no platform drv data??\n");
> +   return -EINVAL;
> +   }
> +   desc = inst->desc;
> +
> +   if (desc->max_message_size < message->len) {
> +   dev_err(dev, "Queue %s message length %d > max %d\n",
> +   qinst->name, message->len, 
> desc->max_message_size);
> +   return -EINVAL;
> +   }
> +
> +   /* Are we able to send this or not? */
> +   msg_count = ti_msgmgr_queue_get_num_messages(qinst);
> +   if (msg_count >= desc->max_messages) {
> +   dev_warn(dev, "Queue %s is full (%d messages)\n", 
> qinst->name,
> +msg_count);
> +   return -EBUSY;
> +   }
 This seems fishy. mailbox api always submit 1 'complete' message to be
 sent and checks for completion by last_tx_done() before calling
 send_data() again. Controller drivers are not supposed to queue
 messages - mailbox core does. So you should never be unable to send a
 message.
>>>
>>>
>>> OK-> to explain this, few reasons: (queue messages check and usage of
>>> last_tx_done are kind of intertwined answer..
>>> a) we need to remember that the message manager has a shared RAM.
>>> multiple transmitter over other queues can be sharing the same.
>>> unfortunately, we dont get a threshold kind of interrupt or status that
>>> I am able to exploit in the current incarnation of the solution. The
>>> best we can do in the full system is to constrain the number of messages
>>> that are max pending simultaneously in each of the queue from various
>>> transmitters in the SoC.
>>> b) last_tx_done() is checked if TXDONE_BY_POLL, not if TXDONE_BY_ACK
>>> right? which is how this'd work since txdone_poll is false -> that is
>>> how we want this mechanism to work once the far end is ready for next
>>> message, it acks. I do see your point about being tied to protocol - I
>>> dont like it either.. in fact, I'd prefer that client registration
>>> mention what kind of handshaking is necessary, but: a) that is not how
>>> mailbox framework is constructed at the moment(we state txdone_poll at
>>> mailbox registration, not at client usage) and b) I have no real need
>>> for multiple clients to users of message manager who actually need
>>> non-ACK usage - even for the foreseeable future (at least 1 next
>>> generation of SoC) - if such a need does arise in the future, I will
>>> have to rework framework and make this capability at the registration
>>> time of the client - allowing each client path to use different
>>> mechanisms on hardware such as these that need it.
>>> c) message manager can actually queue more than one message(depending on
>>> client capability). Even though, at this point, we are not really
>>> capable of doing it(again from what I can see for immediate future),
>>> mailbox framework by checking last_tx_done forces a single message
>>> sequencing - which is not really exploiting the capability of the
>>> hardware - in theory, we should be able to queue max num messages, hit
>>> cpuidle and snooze away while the remote entity chomp away data at it's
>>> own pace and finally give us a notification back - but again, we can
>>> argue it is indeed protocol dependent, so setting txdone_poll to false
>>> actually enables that to be done in user. Again - i have no immediate
>>> need for any queued multiple transfer needs yet.. even if i need to, in
>>> the future, it can easily be done by the client by maintaining code as
>>> is - txdone_poll is false.
>>>
>> All I suggest is that the controller does not queue more than 1
>> message at a time, which means the controller driver allows for
>> maximum possible resources taken by a message.
>> The buffering is already done by the core, and if for your 'batch
>> dispatch' thing the client could simply flush them to remote by
>> pretending it got the ack (which is no worse than simply sending all
>> messages to remote without caring if the first was successful or not).
>
> Are you suggesting to set txdone_poll is true?
No.

> the controller is quite
> capable of queueing more than 1 message at a time. This the reason for
> letting the client choose the mode of operation - use 

Re: [PATCH 0/3] net: macb: Fix coding style issues

[Alexander Stein]

Hi,

On Monday 07 March 2016 08:17:36, Moritz Fischer wrote:
> this series deals with most of the checkpatch warnings
> generated for macb. There are two BUG_ON()'s that I didn't touch, yet,
> that were suggested by checkpatch, that I can address in a follow up
> commit if needed.

I think addressing those BUG_ON() warnings would be nice as they can affect a 
running system pretty bad.

Best regards,
Alexander

RE: [RESPIN 1/6] dt-bindings: EXYNOS: Add exynos-srom device tree binding

[Pavel Fedin]

 Hello!

>> BTW, you could just combine both patches. I guess you didn't to 
>> maintain authorship?

>OK. Will squash both of these patches, unless Pavel do not any objections.

 I don't.

Kind regards.

Re: [PATCH net-next 2/3] ipv6: per netns fib6 walkers

[Michal Kubecek]

On Mon, Mar 07, 2016 at 04:28:26PM -0800, Cong Wang wrote:
> On Mon, Mar 7, 2016 at 4:26 PM, Cong Wang  wrote:
> > On Fri, Mar 4, 2016 at 2:59 AM, Michal Kubecek  wrote:
> >>  static void ipv6_route_seq_setup_walk(struct ipv6_route_iter *iter)
> >>  {
> >> +#ifdef CONFIG_NET_NS
> >> +   struct net *net = iter->p.net;
> >> +#else
> >> +   struct net *net = &init_net;
> >> +#endif
> >> +
> >
> > You should pass the struct net pointer to ipv6_route_seq_setup_walk()
> > instead of reading it by yourself.

I considered this. While it probably wouldn't bring any extra overhead
as the function is going to be inlined anyway, it didn't look really
nice. I gues I'll use read_pnet() as David suggested; I just didn't
realize the reason it's a macro in !CONFIG_NET_NS case is to allow
passing a pointer to non-existent struct member.

> > I don't find anyone actually using iter->p, it probably can be just removed.
> 
> Er, seq_file_net() uses it... but callers already call it.

Not only seq_file_net(). The whole infrastructure assumes private data
start with an instance of struct seq_net_private and seq_open_net()
initializes it.

Michal Kubecek

[lkp] [perf] bd2afa49d1: -20.7% will-it-scale.per_thread_ops

[kernel test robot]

at:
interval: 10
  meminfo: 
  slabinfo: 
  interrupts: 
  lock_stat: 
  latency_stats: 
  softirqs: 
  bdi_dev_mapping: 
  diskstats: 
  nfsstat: 
  cpuidle: 
  cpufreq-stats: 
  turbostat: 
  pmeter: 
  sched_debug:
interval: 60
cpufreq_governor: 
default-watchdogs:
  oom-killer: 
  watchdog: 
commit: bd2afa49d194c6412c333e9fdd48bc5d06bb465d
model: Sandy Bridge-EP
memory: 64G
hdd_partitions: "/dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WCAV5F059499-part3"
swap_partitions: 
rootfs_partition: 
"/dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WCAV5F059499-part4"
category: benchmark
perf-profile:
  freq: 800
will-it-scale:
  test: lseek1
queue: bisect
testbox: lkp-sb03
tbox_group: lkp-sb03
kconfig: x86_64-rhel
enqueue_time: 2016-03-07 15:24:58.319316905 +08:00
compiler: gcc-4.9
rootfs: debian-x86_64-2015-02-07.cgz
id: 1ce184419170460ef4224167293c72561fc7ac35
user: lkp
head_commit: 75c7339113a355b83f63747e6699c3028d4bf362
base_commit: fc77dbd34c5c99bce46d40a2491937c3bcbd10af
branch: linux-devel/devel-hourly-2016030614
result_root: 
"/result/will-it-scale/lseek1/lkp-sb03/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/bd2afa49d194c6412c333e9fdd48bc5d06bb465d/0"
job_file: 
"/lkp/scheduled/lkp-sb03/bisect_will-it-scale-lseek1-debian-x86_64-2015-02-07.cgz-x86_64-rhel-bd2afa49d194c6412c333e9fdd48bc5d06bb465d-20160307-105931-ltzmsq-0.yaml"
nr_cpu: "$(nproc)"
max_uptime: 1500
initrd: "/osimage/debian/debian-x86_64-2015-02-07.cgz"
bootloader_append:
- root=/dev/ram0
- user=lkp
- 
job=/lkp/scheduled/lkp-sb03/bisect_will-it-scale-lseek1-debian-x86_64-2015-02-07.cgz-x86_64-rhel-bd2afa49d194c6412c333e9fdd48bc5d06bb465d-20160307-105931-ltzmsq-0.yaml
- ARCH=x86_64
- kconfig=x86_64-rhel
- branch=linux-devel/devel-hourly-2016030614
- commit=bd2afa49d194c6412c333e9fdd48bc5d06bb465d
- 
BOOT_IMAGE=/pkg/linux/x86_64-rhel/gcc-4.9/bd2afa49d194c6412c333e9fdd48bc5d06bb465d/vmlinuz-4.5.0-rc5-00216-gbd2afa4
- max_uptime=1500
- 
RESULT_ROOT=/result/will-it-scale/lseek1/lkp-sb03/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/bd2afa49d194c6412c333e9fdd48bc5d06bb465d/0
- LKP_SERVER=inn
- |2-


  earlyprintk=ttyS0,115200 systemd.log_level=err
  debug apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100
  panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 
prompt_ramdisk=0
  console=ttyS0,115200 console=tty0 vga=normal

  rw
lkp_initrd: "/lkp/lkp/lkp-x86_64.cgz"
modules_initrd: 
"/pkg/linux/x86_64-rhel/gcc-4.9/bd2afa49d194c6412c333e9fdd48bc5d06bb465d/modules.cgz"
bm_initrd: 
"/osimage/deps/debian-x86_64-2015-02-07.cgz/lkp.cgz,/osimage/deps/debian-x86_64-2015-02-07.cgz/run-ipconfig.cgz,/osimage/deps/debian-x86_64-2015-02-07.cgz/turbostat.cgz,/lkp/benchmarks/turbostat.cgz,/osimage/deps/debian-x86_64-2015-02-07.cgz/will-it-scale.cgz,/lkp/benchmarks/will-it-scale.cgz,/lkp/benchmarks/will-it-scale-x86_64.cgz"
linux_headers_initrd: 
"/pkg/linux/x86_64-rhel/gcc-4.9/bd2afa49d194c6412c333e9fdd48bc5d06bb465d/linux-headers.cgz"
repeat_to: 2
kernel: 
"/pkg/linux/x86_64-rhel/gcc-4.9/bd2afa49d194c6412c333e9fdd48bc5d06bb465d/vmlinuz-4.5.0-rc5-00216-gbd2afa4"
dequeue_time: 2016-03-07 15:30:15.230960736 +08:00
job_state: finished
loadavg: 28.24 12.75 4.99 2/360 9047
start_time: '1457335872'
end_time: '1457336183'
version: "/lkp/lkp/.src-20160307-130139"
2016-03-07 15:31:12 ./runtest.py lseek1 25 both 1 8 16 24 32

Re: [PATCH v1 1/1] mfd: intel-lpss: save register context on suspend

[Andy Shevchenko]

On Tue, Mar 8, 2016 at 6:48 AM, Lee Jones  wrote:
> On Tue, 26 Jan 2016, Andy Shevchenko wrote:
>
>> From: Heikki Krogerus 
>>
>> All configurations are lost and the registers will have
>> default values when the hardware is suspended and resumed,
>> so saving the private register space context on suspend, and
>> restoring it on resume.
>>
>> Fixes: 4b45efe85263 (mfd: Add support for Intel Sunrisepoint LPSS devices)
>
> I'd say this sumbission is more of a functional extention than a
> bug-fix.  No real need for this statement.

But we would like send it later to stable@ to have this back ported.

>> Signed-off-by: Heikki Krogerus 
>> Signed-off-by: Mika Westerberg 
>
> Did it really take 2 of you to write this patch?

It's probably my mistake, since I took this one from Mika's tree and
kept his SoB.

>
>> Signed-off-by: Andy Shevchenko 
>> ---
>>  drivers/mfd/intel-lpss.c | 19 ++-
>>  1 file changed, 18 insertions(+), 1 deletion(-)
>
> Code looks okay though:
>   Acked-by: Lee Jones 

Thanks.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v5 0/6] ARM: am335x/am437x/dra7: Add PWM support for DRA7

[Paul Walmsley]

Hi Franklin

On Mon, 7 Mar 2016, Franklin S Cooper Jr wrote:

> This patch series adds support for PWM for DRA7. The IP is same as that
> present in AM33XX and AM437XX.
> 
> However, before doing so remove unnecessary hwmod entries for eCAP, ePWM
> and eQEP.
> 
> This series is almost identical to v4. Only difference is the addition of
> eCAP DT nodes in the dra7.dtsi file.
> 
> This series was tested on AM335x GP, AM437x GP and X15 + LCD screen for
> PWM based backlight.
> 
> This series was also verified to be backwards compatible with old dtbs.

Looking at these to see what I can pick for v4.7, I'm curious about the 
dependencies.  Can I take patches 2 and 3 before 1 is merged, or does 1 
need to be merged first?

- Paul

Re: Nokia N900 - audio TPA6130A2 problems

[Ivaylo Dimitrov]

Hi,

On  7.03.2016 13:59, Pali Rohár wrote:


... That error occurs randomly, not
always. When I see it next time, I will try to comment that function if
it happens...



IIRC it is easier to cause it by booting to stock kernel first and then 
rebooting to mainline (without power-down in between)


Ivo

Re: [PATCH v5 4/6] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS

[Paul Walmsley]

On Mon, 7 Mar 2016, Franklin S Cooper Jr wrote:

> From: Vignesh R 
> 
> Add hwmod entries for the PWMSS on DRA7.
> 
> Set l4_root_clk_div as the main_clk of PWMSS. It is fixed-factored clock
> equal to L4PER2_L3_GICLK/2(l3_iclk_div/2).
> 
> Signed-off-by: Vignesh R 
> [fcoo...@ti.com: Do not add eQEP, ePWM and eCAP hwmod entries]
> Signed-off-by: Franklin S Cooper Jr 

Thanks, queued for v4.7.

- Paul

Re: [PATCH v2 10/10] x86/entry/32: Add and check a stack canary for the SYSENTER stack

[Borislav Petkov]

On Sat, Mar 05, 2016 at 09:52:23PM -0800, Andy Lutomirski wrote:

<--- ?

So all patches before are nice and verbose in explaining what they do.
Where did the commit message of this one disappear?

:-)

Or is it that obvious that we should have a stack canary? How about some
text *why* we need it?

> Signed-off-by: Andy Lutomirski 
> ---
>  arch/x86/include/asm/processor.h | 3 ++-
>  arch/x86/kernel/process.c| 3 +++
>  arch/x86/kernel/traps.c  | 8 
>  3 files changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/include/asm/processor.h 
> b/arch/x86/include/asm/processor.h
> index 7cd01b71b5bd..50a6dc871cc0 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -299,8 +299,9 @@ struct tss_struct {
>  
>  #ifdef CONFIG_X86_32
>   /*
> -  * Space for the temporary SYSENTER stack:
> +  * Space for the temporary SYSENTER stack.
>*/
> + unsigned long   SYSENTER_stack_canary;
>   unsigned long   SYSENTER_stack[64];
>  #endif
>  
> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> index 9f7c21c22477..ee9a9792caeb 100644
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -57,6 +57,9 @@ __visible DEFINE_PER_CPU_SHARED_ALIGNED(struct tss_struct, 
> cpu_tss) = {
> */
>   .io_bitmap  = { [0 ... IO_BITMAP_LONGS] = ~0 },
>  #endif
> +#ifdef CONFIG_X86_32
> + .SYSENTER_stack_canary  = STACK_END_MAGIC,
> +#endif
>  };
>  EXPORT_PER_CPU_SYMBOL(cpu_tss);
>  
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index 80928ea78373..590110119e6a 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -713,6 +713,14 @@ dotraplinkage void do_debug(struct pt_regs *regs, long 
> error_code)
>   debug_stack_usage_dec();
>  
>  exit:
> +#if defined(CONFIG_X86_32)
> + /*
> +  * This is the most likely code path that involves non-trivial use
> +  * of the SYSENTER stack.  Check that we haven't overrun it.
> +  */
> + WARN(this_cpu_read(cpu_tss.SYSENTER_stack_canary) != STACK_END_MAGIC,
> +  "Overran or corrupted SYSENTER stack\n");
> +#endif
>   ist_exit(regs);
>  }
>  NOKPROBE_SYMBOL(do_debug);
> -- 
> 2.5.0
> 
> 

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH v2 09/10] ARM: DRA7: hwmod: Add data for McASP1/2/4/5/6/7/8

[Paul Walmsley]

On Mon, 7 Mar 2016, Peter Ujfalusi wrote:

> Add missing data for all McASP ports for the dra7 family
> 
> Signed-off-by: Peter Ujfalusi 

Thanks, queued for v4.7.

- Paul

Re: [PATCH v2 09/10] x86/entry/32: Simplify and fix up the SYSENTER stack #DB/NMI fixup

[Borislav Petkov]

On Sat, Mar 05, 2016 at 09:52:22PM -0800, Andy Lutomirski wrote:
> Right after SYSENTER, we can get a #DB or NMI.  On x86_32, there's no IST,
> so the exception handler is invoked on the temporary SYSENTER stack.
> 
> Because the SYSENTER stack is very small, we have a fixup to switch
> off the stack quickly when this happens.  The old fixup had several issues:
> 
> 1. It checked the interrupt frame's CS and EIP.  This wasn't
>obviously correct on Xen or if vm86 mode was in use [1].
> 
> 2. In the NMI handler, it did some frightening digging into the
>stack frame.  I'm not convinced this digging was correct.
> 
> 3. The fixup didn't switch stacks and then switch back.  Instead, it
>synthesized a brand new stack frame that would redirect the IRET
>back to the SYSENTER code.  That frame was highly questionable.
>For one thing, if NMI nested inside #DB, we would effectively
>abort the #DB prologue, which was probably safe but was
>frightening.  For another, the code used PUSHFL to write the
>FLAGS portion of the frame, which was simply bogus -- by the time
>PUSHFL was called, at least TF, NT, VM, and all of the arithmetic
>flags were clobbered.
> 
> Simplify this considerably.  Instead of looking at the saved frame
> to see where we came from, check the hardware ESP register against
> the SYSENTER stack directly.  Malicious user code cannot spoof the
> kernel ESP register, and by moving the check after SAVE_ALL, we can
> use normal PER_CPU accesses to find all the relevant addresses.
> 
> With this patch applied, the improved syscall_nt_32 test finally
> passes on 32-bit kernels.
> 
> [1] It isn't obviously correct, but it is nonetheless safe from vm86
> shenanigans as far as I can tell.  A user can't point EIP at
> entry_SYSENTER_32 while in vm86 mode because entry_SYSENTER_32,
> like all kernel addresses, is greater than 0x and would thus
> violate the CS segment limit.
> 
> Signed-off-by: Andy Lutomirski 
> ---
>  arch/x86/entry/entry_32.S| 114 
> ++-
>  arch/x86/kernel/asm-offsets_32.c |   5 ++
>  2 files changed, 56 insertions(+), 63 deletions(-)
> 
> diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
> index 7700cf695d8c..ad9a85e62128 100644
> --- a/arch/x86/entry/entry_32.S
> +++ b/arch/x86/entry/entry_32.S
> @@ -987,51 +987,48 @@ error_code:
>   jmp ret_from_exception
>  END(page_fault)
>  
> -/*
> - * Debug traps and NMI can happen at the one SYSENTER instruction
> - * that sets up the real kernel stack. Check here, since we can't
> - * allow the wrong stack to be used.
> - *
> - * "TSS_sysenter_sp0+12" is because the NMI/debug handler will have
> - * already pushed 3 words if it hits on the sysenter instruction:
> - * eflags, cs and eip.
> - *
> - * We just load the right stack, and push the three (known) values
> - * by hand onto the new stack - while updating the return eip past
> - * the instruction that would have done it for sysenter.
> - */
> -.macro FIX_STACK offset ok label
> - cmpw$__KERNEL_CS, 4(%esp)
> - jne \ok
> -\label:
> - movlTSS_sysenter_sp0 + \offset(%esp), %esp
> - pushfl
> - pushl   $__KERNEL_CS
> - pushl   $sysenter_past_esp
> -.endm
> -
>  ENTRY(debug)
> + /*
> +  * #DB can happen at the first instruction of
> +  * entry_SYSENTER_32 or in Xen's SYSENTER prologue.  If this
> +  * happens, then we will be running on a very small stack.  We
> +  * need to detect this condition and switch to the thread
> +  * stack before calling any C code at all.
> +  *
> +  * If you edit this code, keep in mind that NMIs can happen in here.
> +  */

Btw, I think it is a bit more readable if this comment is over ENTRY(debug) like
the one over ENTRY(nmi) below.

>   ASM_CLAC
> - cmpl$entry_SYSENTER_32, (%esp)
> - jne debug_stack_correct
> - FIX_STACK 12, debug_stack_correct, debug_esp_fix_insn
> -debug_stack_correct:
>   pushl   $-1 # mark this as an int
>   SAVE_ALL
> - TRACE_IRQS_OFF
>   xorl%edx, %edx  # error code 0
>   movl%esp, %eax  # pt_regs pointer
> +
> + /* Are we currently on the SYSENTER stack? */
> + PER_CPU(cpu_tss + CPU_TSS_SYSENTER_stack + SIZEOF_SYSENTER_stack, %ecx)
> + subl%eax, %ecx  /* ecx = (end of SYENTER_stack) - esp */
 ^^^
Just a typo for the committer of this patch to fix: SYSENTER_stack

> + cmpl$SIZEOF_SYSENTER_stack, %ecx
> + jb  .Ldebug_from_sysenter_stack
> +
> + TRACE_IRQS_OFF
> + calldo_debug
> + jmp ret_from_exception
> +
> +.Ldebug_from_sysenter_stack:
> + /* We're on the SYSENTER stack.  Switch off. */
> + movl%esp, %ebp
> + movlPER_CPU_VAR(cpu_current_top_of_stack), %esp
> + TRACE_IRQS_OFF
> 

[RESEND PATCH V4 4/4] coresight-stm: adding driver for CoreSight STM component

[Chunyan Zhang]

From: Pratik Patel 

This driver adds support for the STM CoreSight IP block, allowing any
system compoment (HW or SW) to log and aggregate messages via a
single entity.

The CoreSight STM exposes an application defined number of channels
called stimulus port.  Configuration is done using entries in sysfs
and channels made available to userspace via configfs.

Signed-off-by: Pratik Patel 
Signed-off-by: Mathieu Poirier 
Signed-off-by: Chunyan Zhang 
---
 .../ABI/testing/sysfs-bus-coresight-devices-stm|  53 ++
 Documentation/trace/coresight.txt  |  37 +-
 drivers/hwtracing/coresight/Kconfig|  11 +
 drivers/hwtracing/coresight/Makefile   |   1 +
 drivers/hwtracing/coresight/coresight-stm.c| 890 +
 include/linux/coresight-stm.h  |   6 +
 include/uapi/linux/coresight-stm.h |  21 +
 7 files changed, 1017 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
 create mode 100644 drivers/hwtracing/coresight/coresight-stm.c
 create mode 100644 include/linux/coresight-stm.h
 create mode 100644 include/uapi/linux/coresight-stm.h

diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm 
b/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
new file mode 100644
index 000..c519056
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
@@ -0,0 +1,53 @@
+What:  /sys/bus/coresight/devices/.stm/enable_source
+Date:  February 2016
+KernelVersion: 4.5
+Contact:   Mathieu Poirier 
+Description:   (RW) Enable/disable tracing on this specific trace macrocell.
+   Enabling the trace macrocell implies it has been configured
+   properly and a sink has been identified for it.  The path
+   of coresight components linking the source to the sink is
+   configured and managed automatically by the coresight framework.
+
+What:  /sys/bus/coresight/devices/.stm/hwevent_enable
+Date:  February 2016
+KernelVersion: 4.5
+Contact:   Mathieu Poirier 
+Description:   (RW) Provides access to the HW event enable register, used in
+   conjunction with HW event bank select register.
+
+What:  /sys/bus/coresight/devices/.stm/hwevent_select
+Date:  February 2016
+KernelVersion: 4.5
+Contact:   Mathieu Poirier 
+Description:   (RW) Gives access to the HW event block select register
+   (STMHEBSR) in order to configure up to 256 channels.  Used in
+   conjunction with "hwevent_enable" register as described above.
+
+What:  /sys/bus/coresight/devices/.stm/port_enable
+Date:  February 2016
+KernelVersion: 4.5
+Contact:   Mathieu Poirier 
+Description:   (RW) Provides access to the stimulus port enable register
+   (STMSPER).  Used in conjunction with "port_select" described
+   below.
+
+What:  /sys/bus/coresight/devices/.stm/port_select
+Date:  February 2016
+KernelVersion: 4.5
+Contact:   Mathieu Poirier 
+Description:   (RW) Used to determine which bank of stimulus port bit in
+   register STMSPER (see above) apply to.
+
+What:  /sys/bus/coresight/devices/.stm/status
+Date:  February 2016
+KernelVersion: 4.5
+Contact:   Mathieu Poirier 
+Description:   (R) List various control and status registers.  The specific
+   layout and content is driver specific.
+
+What:  /sys/bus/coresight/devices/.stm/traceid
+Date:  February 2016
+KernelVersion: 4.5
+Contact:   Mathieu Poirier 
+Description:   (RW) Holds the trace ID that will appear in the trace stream
+   coming from this trace entity.
diff --git a/Documentation/trace/coresight.txt 
b/Documentation/trace/coresight.txt
index 0a5c329..a33c88c 100644
--- a/Documentation/trace/coresight.txt
+++ b/Documentation/trace/coresight.txt
@@ -190,8 +190,8 @@ expected to be accessed and controlled using those entries.
 Last but not least, "struct module *owner" is expected to be set to reflect
 the information carried in "THIS_MODULE".
 
-How to use
---
+How to use the tracer modules
+-
 
 Before trace collection can start, a coresight sink needs to be identify.
 There is no limit on the amount of sinks (nor sources) that can be enabled at
@@ -297,3 +297,36 @@ InfoTracing enabled
 Instruction 135708310x8026B584  E28DD00Cfalse   ADD
  sp,sp,#0xc
 Instruction 0   0x8026B588  E8BD8000trueLDM  
sp!,{pc}
 Timestamp   Timestamp: 17107041535
+
+How to use the STM module
+-
+
+Using the System Trace Macrocell module is the same as the tracers - the only
+difference is that clients are driving the trace capture rather
+than the program flow through the 

[RESEND PATCH V4 2/4] Documentations: Add explanations of the case for non-configurable masters

[Chunyan Zhang]

For some STM hardware (e.g. ARM CoreSight STM), the masterID associated
to a source is set at the hardware level and not user configurable.
Since the masterID information isn't available to SW, introducing
a new value of -1 to reflect this reality.

Signed-off-by: Chunyan Zhang 
---
 Documentation/trace/stm.txt | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/trace/stm.txt b/Documentation/trace/stm.txt
index ea035f9..f03bc2b 100644
--- a/Documentation/trace/stm.txt
+++ b/Documentation/trace/stm.txt
@@ -47,6 +47,12 @@ through 127 in it. Now, any producer (trace source) 
identifying itself
 with "user" identification string will be allocated a master and
 channel from within these ranges.
 
+$ cat /config/stp-policy/dummy_stm.my-policy/user/masters
+-1 -1
+
+Would indicate the masters for this rule are set in hardware and
+not configurable in user space.
+
 These rules can be nested, for example, one can define a rule "dummy"
 under "user" directory from the example above and this new rule will
 be used for trace sources with the id string of "user/dummy".
-- 
1.9.1

[RESEND PATCH V4 1/4] stm class: provision for statically assigned masterIDs

[Chunyan Zhang]

From: Mathieu Poirier 

Some architecture like ARM assign masterIDs at the HW design
phase.  Those are therefore unreachable to users, making masterID
management in the generic STM core irrelevant.

In this kind of configuration channels are shared between masters
rather than being allocated on a per master basis.

This patch adds a new 'mshared' flag to struct stm_data that tells the
core that this specific STM device doesn't need explicit masterID
management.  In the core sw_start/end of masterID are set to '1',
i.e there is only one masterID to deal with.

Also this patch depends on [1], so that the number of masterID
is '1' too.

Finally the lower and upper bound for masterIDs as presented
in ($SYSFS)/class/stm/XYZ.stm/masters and
($SYSFS)/../stp-policy/XYZ.stm.my_policy/some_device/masters
are set to '-1'.  That way users can't confuse them with
architecture where masterID management is required (where any
other value would be valid).

[1] https://lkml.org/lkml/2015/12/22/348

Signed-off-by: Mathieu Poirier 
Signed-off-by: Chunyan Zhang 
---
 drivers/hwtracing/stm/core.c   | 17 +++--
 drivers/hwtracing/stm/policy.c | 18 --
 include/linux/stm.h|  8 
 3 files changed, 39 insertions(+), 4 deletions(-)

diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
index 66cec56..0d7f1c5 100644
--- a/drivers/hwtracing/stm/core.c
+++ b/drivers/hwtracing/stm/core.c
@@ -44,9 +44,15 @@ static ssize_t masters_show(struct device *dev,
char *buf)
 {
struct stm_device *stm = to_stm_device(dev);
-   int ret;
+   int ret, sw_start, sw_end;
+
+   sw_start = stm->data->sw_start;
+   sw_end = stm->data->sw_end;
+
+   if (stm->data->mshared)
+   sw_start = sw_end = STM_SHARED_MASTERID;
 
-   ret = sprintf(buf, "%u %u\n", stm->data->sw_start, stm->data->sw_end);
+   ret = sprintf(buf, "%d %d\n", sw_start, sw_end);
 
return ret;
 }
@@ -618,6 +624,13 @@ int stm_register_device(struct device *parent, struct 
stm_data *stm_data,
if (!stm_data->packet || !stm_data->sw_nchannels)
return -EINVAL;
 
+   /*
+* MasterIDs are assigned at HW design phase. As such the core is
+* using a single master for interaction with this device.
+*/
+   if (stm_data->mshared)
+   stm_data->sw_start = stm_data->sw_end = 1;
+
nmasters = stm_data->sw_end - stm_data->sw_start + 1;
stm = kzalloc(sizeof(*stm) + nmasters * sizeof(void *), GFP_KERNEL);
if (!stm)
diff --git a/drivers/hwtracing/stm/policy.c b/drivers/hwtracing/stm/policy.c
index 17a1416..19455db 100644
--- a/drivers/hwtracing/stm/policy.c
+++ b/drivers/hwtracing/stm/policy.c
@@ -80,10 +80,17 @@ static ssize_t
 stp_policy_node_masters_show(struct config_item *item, char *page)
 {
struct stp_policy_node *policy_node = to_stp_policy_node(item);
+   struct stm_device *stm = policy_node->policy->stm;
+   int first_master, last_master;
ssize_t count;
 
-   count = sprintf(page, "%u %u\n", policy_node->first_master,
-   policy_node->last_master);
+   first_master = policy_node->first_master;
+   last_master = policy_node->last_master;
+
+   if (stm && stm->data->mshared)
+   first_master = last_master = STM_SHARED_MASTERID;
+
+   count = sprintf(page, "%d %d\n", first_master, last_master);
 
return count;
 }
@@ -106,6 +113,13 @@ stp_policy_node_masters_store(struct config_item *item, 
const char *page,
if (!stm)
goto unlock;
 
+   /*
+* masterIDs are allocated in HW, no point in trying to
+* change their values.
+*/
+   if (stm->data->mshared)
+   goto unlock;
+
/* must be within [sw_start..sw_end], which is an inclusive range */
if (first > INT_MAX || last > INT_MAX || first > last ||
first < stm->data->sw_start ||
diff --git a/include/linux/stm.h b/include/linux/stm.h
index 9d0083d..6fac8b1 100644
--- a/include/linux/stm.h
+++ b/include/linux/stm.h
@@ -18,6 +18,11 @@
 #include 
 
 /**
+ * The masterIDs are set in hardware and can't be queried
+ */
+#define STM_SHARED_MASTERID -1
+
+/**
  * enum stp_packet_type - STP packets that an STM driver sends
  */
 enum stp_packet_type {
@@ -46,6 +51,8 @@ struct stm_device;
  * struct stm_data - STM device description and callbacks
  * @name:  device name
  * @stm:   internal structure, only used by stm class code
+ * @mshared:   true if masterIDs are assigned in HW.  If so @sw_start
+ * and @sw_end are set to '1' by the core.
  * @sw_start:  first STP master available to software
  * @sw_end:last STP master available to software
  * @sw_nchannels:  number of STP channels per master
@@ -71,6 +78,7 @@ struct stm_device;
 struct stm_data {
const char  *na

[RESEND PATCH V4 3/4] coresight-stm: Bindings for System Trace Macrocell

[Chunyan Zhang]

From: Mathieu Poirier 

The System Trace Macrocell (STM) is an IP block falling under the
CoreSight umbrella.  It's main purpose it so expose stimulus channels
to any system component for the purpose of information logging.

Bindings for this IP block adds a couple of items to the current
mandatory definition for CoreSight components.

Signed-off-by: Mathieu Poirier 
Acked-by: Rob Herring 
Signed-off-by: Chunyan Zhang 
---
 .../devicetree/bindings/arm/coresight.txt  | 28 ++
 1 file changed, 28 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/coresight.txt 
b/Documentation/devicetree/bindings/arm/coresight.txt
index 62938eb..93147c0c 100644
--- a/Documentation/devicetree/bindings/arm/coresight.txt
+++ b/Documentation/devicetree/bindings/arm/coresight.txt
@@ -19,6 +19,7 @@ its hardware characteristcs.
- "arm,coresight-etm3x", "arm,primecell";
- "arm,coresight-etm4x", "arm,primecell";
- "qcom,coresight-replicator1x", "arm,primecell";
+   - "arm,coresight-stm", "arm,primecell"; [1]
 
* reg: physical base address and length of the register
  set(s) of the component.
@@ -36,6 +37,14 @@ its hardware characteristcs.
  layout using the generic DT graph presentation found in
  "bindings/graph.txt".
 
+* Additional required properties for System Trace Macrocells (STM):
+   * reg: along with the physical base address and length of the register
+ set as described above, another entry is required to describe the
+ mapping of the extended stimulus port area.
+
+   * reg-names: the only acceptable values are "stm-base" and
+ "stm-stimulus-base", each corresponding to the areas defined in "reg".
+
 * Required properties for devices that don't show up on the AMBA bus, such as
   non-configurable replicators:
 
@@ -202,3 +211,22 @@ Example:
};
};
};
+
+4. STM
+   stm@2010 {
+   compatible = "arm,coresight-stm", "arm,primecell";
+   reg = <0 0x2010 0 0x1000>,
+ <0 0x2800 0 0x18>;
+   reg-names = "stm-base", "stm-stimulus-base";
+
+   clocks = <&soc_smc50mhz>;
+   clock-names = "apb_pclk";
+   port {
+   stm_out_port: endpoint {
+   remote-endpoint = <&main_funnel_in_port2>;
+   };
+   };
+   };
+
+[1]. There is currently two version of STM: STM32 and STM500.  Both
+have the same HW interface and as such don't need an explicit binding name.
-- 
1.9.1

[RESEND PATCH V4 0/4] Introduce CoreSight STM support

[Chunyan Zhang]

This patchset adds support for the CoreSight STM IP block.

In the fourth version, comments from various people have been
addressed.  Representing configurations where channels are shared
between multiple masterIDs has been kept unchanged from the previous
version because a viable alternative hasn't been suggested.

This RESEND PATCH 1/4 depends on the patch [3] which has been
merged into linux-next.

Changes from V3:
 - Removed ioctl get_options interface from the generic STM code and CoreSight 
STM driver.
 - Removed 'write_max' from the structure 'stm_drvdata', and changed 
'write_64bit' to 'write_bytes'.
 - Revised stm_fundamental_data_size() to return the fundamental data size 
instead of 0/1.
 - Removed stm_remove() from the driver.
 - Revised the return value of ::packet() callback function according to [2].
 - Modified stm_send() to send one STP packet at a time.
 - Added comments to invariant/guaranteed CoreSight STM transaction mode.

Changes from V2:
 - Changed to return -EFAULT if failed on the command STP_GET_OPTIONS.
 - Used Alex's patch [1] instead of the last 2/6.
 - Removed the while loop from stm_send(), since the packet size passed
   to it isn't larger than 4 bytes on 32-bit system and 8 bytes on
   64-bit system.
 - Removed stm_send_64bit(), since the process of packets on 64-bit
   CS-STM should be basically the same with on 32-bit system, except the 
   maximum length of writing STM at a time.
 - Removed the support of writing 64-bit to CoreSight STM buffer at a time
   on 32-bit ARM architecture according to an ARM engineer suggestion.  As
   he said that the STM might receive a 64-bit write, or might receive a
   pair of 32-bit writes to the two addressed words in either order.
   So 64-bit write isn't guaranteed to work on the ARM 32-bit architecture.

Changes from v1:
 - Added a definition of coresight_simple_func() in CS-STM driver to
   avoid the kbuild test robot error for the time being.  This
   modification will be removed when merging the code in which the
   coresight_simple_func() has been moved to the header file.
 - Calculate the channel number according to the channel memory space size.


Thanks,
Chunyan

[1] https://lkml.org/lkml/2016/2/4/652
[2] https://lkml.org/lkml/2016/2/12/397
[3] https://lkml.org/lkml/2015/12/22/348

Chunyan Zhang (1):
  Documentations: Add explanations of the case for non-configurable
masters

Mathieu Poirier (2):
  stm class: provision for statically assigned masterIDs
  coresight-stm: Bindings for System Trace Macrocell

Pratik Patel (1):
  coresight-stm: adding driver for CoreSight STM component

 .../ABI/testing/sysfs-bus-coresight-devices-stm|  53 ++
 .../devicetree/bindings/arm/coresight.txt  |  28 +
 Documentation/trace/coresight.txt  |  37 +-
 Documentation/trace/stm.txt|   6 +
 drivers/hwtracing/coresight/Kconfig|  11 +
 drivers/hwtracing/coresight/Makefile   |   1 +
 drivers/hwtracing/coresight/coresight-stm.c| 890 +
 drivers/hwtracing/stm/core.c   |  17 +-
 drivers/hwtracing/stm/policy.c |  18 +-
 include/linux/coresight-stm.h  |   6 +
 include/linux/stm.h|   8 +
 include/uapi/linux/coresight-stm.h |  21 +
 12 files changed, 1090 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
 create mode 100644 drivers/hwtracing/coresight/coresight-stm.c
 create mode 100644 include/linux/coresight-stm.h
 create mode 100644 include/uapi/linux/coresight-stm.h

-- 
1.9.1

Re: [PATCH] fat: add config option to set UTF-8 mount option by default

[OGAWA Hirofumi]

"Maciej S. Szmigiero"  writes:

> +#ifdef CONFIG_FAT_DEFAULT_UTF8
> + opts->utf8 = is_vfat;
> +#else
> + opts->utf8 = 0;
> +#endif
> +

Maybe, better to use IS_ENABLED(CONFIG_FAT_DEFAULT_UTF8)?

I.e.,

opts->utf8 = IS_ENABLED(CONFIG_FAT_DEFAULT_UTF8) && is_vfat;

Thanks.
-- 
OGAWA Hirofumi 

Re: Thoughts on tightening up user namespace creation

[Serge E. Hallyn]

On Mon, Mar 07, 2016 at 09:15:25PM -0800, Andy Lutomirski wrote:
> Hi all-
> 
> There are several users and distros that are nervous about user
> namespaces from an attack surface point of view.
> 
>  - RHEL and Arch have userns disabled.
> 
>  - Ubuntu requires CAP_SYS_ADMIN

No, it does not.  It has temporarily re-added a sysctl which can enable
that behavior, but it's not set by default.  The reason for providing it
is not a distrust of user namespaces in general, but because we're enabling
some bleeding edge patches which haven't been accepted upstream yet.  Once
they're accepted upstream I expect that patch to be dropped again, unless
it has gone upstream.

Debian does afaik still have a version of a patch I'd originally written
before user namespaces were upstream which defaulted unprivileged userns
cloning to off.  Did you mean Debian here?

>  - Kees periodically proposes to upstream some sysctl to control
> userns creation.
> 
> I think there are three main types of concerns.  First, there might be
> some as-yet-unknown semantic issues that would allow privilege
> escalation by users who create user namespaces and then confuse
> something else in the system.  Second, enabling user namespaces
> exposes a lot of attack surface to unprivileged users.  Third,
> allowing tasks to create user namespaces exposes the kernel to various
> resource exhaustion attacks that wouldn't be possible otherwise.
> 
> Since I doubt we'll ever fully address the attack surface issue at
> least, would it make sense to try to come up with an upstreamable way
> to limit who can create new user namespaces and/or do various
> dangerous things with them?
> 
> I'll divide the rest of the email into the "what" and the "who".
> 
> +++ What does the privilege of creating a user namespace entail? +++
> 
> This could be an all-or-nothing thing.  It would certainly be possible
> for appropriately privileged tasks to be able to unshare namespaces
> and use their facilities exactly like any task can in a current
> user-ns-enabled kernel and for other tasks to be unable to unshare
> anything.
> 
> Finer gradations are, in principle, possible.  For example, it could
> be possible for a given task to unshare its userns but to have limited
> caps inside or to be unable to unshare certain other namespaces.  For
> example, maybe a task could unshare userns and mount ns but not net
> ns.  I don't think this would be particularly useful.
> 
> It might be more interesting to allow a task to unshare all
> namespaces, hold all capabilities in them, but to still be unable to
> use certain privileged facilities.  For example, maybe denying
> administrative control over iptables, creation of exotic network
> interface types, or similar would make sense.  I don't know how we'd
> specify this type of constraint.
> 
> +++ Who can create user namespaces (possibly with restrictions)? +++
> 
> I can think of a few formulations.
> 
> A simpler approach would be to add a per-namespace setting listing
> users and/or groups that can unshare their userns.  A userns starts
> out allowing everyone to unshare userns, and anyone with CAP_SYS_ADMIN
> can change the setting.
> 
> A fancier approach would be to have an fd that represents the right to
> unshare your userns.  Some privilege broker could give out those fds
> to apps that need them and meet whatever criteria are set.  If you try
> to unshare your userns without the fd, it falls back to some simpler
> policy.
> 
> I think I prefer the simpler one.  It's simple, and I haven't come up
> with a concrete problem with it yet.
> 
> 
> 
> 
> Thoughts?
> ___
> Containers mailing list
> contain...@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers

Re: [PATCH 3/3] ARM: bcm2835: Add VC4 to the device tree.

[Stephen Warren]

On 03/04/2016 01:32 PM, Eric Anholt wrote:

VC4 is the GPU (display and 3D) present on the 283x.



diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts 
b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts



+&hdmi {
+   hpd-gpios = <&gpio 46 GPIO_ACTIVE_LOW>;
+};


Isn't that the same everywhere? If so, adding it to bcm2835-rpi.dtsi 
seems like a better idea; it'd avoid duplicating it everywhere.

[PATCH v2 net-next 02/12] bpf: introduce percpu_freelist

[Alexei Starovoitov]

Introduce simple percpu_freelist to keep single list of elements
spread across per-cpu singly linked lists.

/* push element into the list */
void pcpu_freelist_push(struct pcpu_freelist *, struct pcpu_freelist_node *);

/* pop element from the list */
struct pcpu_freelist_node *pcpu_freelist_pop(struct pcpu_freelist *);

The object is pushed to the current cpu list.
Pop first trying to get the object from the current cpu list,
if it's empty goes to the neigbour cpu list.

For bpf program usage pattern the collision rate is very low,
since programs push and pop the objects typically on the same cpu.

Signed-off-by: Alexei Starovoitov 
---
 kernel/bpf/Makefile  |   2 +-
 kernel/bpf/percpu_freelist.c | 100 +++
 kernel/bpf/percpu_freelist.h |  31 ++
 3 files changed, 132 insertions(+), 1 deletion(-)
 create mode 100644 kernel/bpf/percpu_freelist.c
 create mode 100644 kernel/bpf/percpu_freelist.h

diff --git a/kernel/bpf/Makefile b/kernel/bpf/Makefile
index 8a932d079c24..eed911d091da 100644
--- a/kernel/bpf/Makefile
+++ b/kernel/bpf/Makefile
@@ -1,7 +1,7 @@
 obj-y := core.o
 
 obj-$(CONFIG_BPF_SYSCALL) += syscall.o verifier.o inode.o helpers.o
-obj-$(CONFIG_BPF_SYSCALL) += hashtab.o arraymap.o
+obj-$(CONFIG_BPF_SYSCALL) += hashtab.o arraymap.o percpu_freelist.o
 ifeq ($(CONFIG_PERF_EVENTS),y)
 obj-$(CONFIG_BPF_SYSCALL) += stackmap.o
 endif
diff --git a/kernel/bpf/percpu_freelist.c b/kernel/bpf/percpu_freelist.c
new file mode 100644
index ..5c51d1985b51
--- /dev/null
+++ b/kernel/bpf/percpu_freelist.c
@@ -0,0 +1,100 @@
+/* Copyright (c) 2016 Facebook
+ *
+ * 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.
+ */
+#include "percpu_freelist.h"
+
+int pcpu_freelist_init(struct pcpu_freelist *s)
+{
+   int cpu;
+
+   s->freelist = alloc_percpu(struct pcpu_freelist_head);
+   if (!s->freelist)
+   return -ENOMEM;
+
+   for_each_possible_cpu(cpu) {
+   struct pcpu_freelist_head *head = per_cpu_ptr(s->freelist, cpu);
+
+   raw_spin_lock_init(&head->lock);
+   head->first = NULL;
+   }
+   return 0;
+}
+
+void pcpu_freelist_destroy(struct pcpu_freelist *s)
+{
+   free_percpu(s->freelist);
+}
+
+static inline void __pcpu_freelist_push(struct pcpu_freelist_head *head,
+   struct pcpu_freelist_node *node)
+{
+   raw_spin_lock(&head->lock);
+   node->next = head->first;
+   head->first = node;
+   raw_spin_unlock(&head->lock);
+}
+
+void pcpu_freelist_push(struct pcpu_freelist *s,
+   struct pcpu_freelist_node *node)
+{
+   struct pcpu_freelist_head *head = this_cpu_ptr(s->freelist);
+
+   __pcpu_freelist_push(head, node);
+}
+
+void pcpu_freelist_populate(struct pcpu_freelist *s, void *buf, u32 elem_size,
+   u32 nr_elems)
+{
+   struct pcpu_freelist_head *head;
+   unsigned long flags;
+   int i, cpu, pcpu_entries;
+
+   pcpu_entries = nr_elems / num_possible_cpus() + 1;
+   i = 0;
+
+   /* disable irq to workaround lockdep false positive
+* in bpf usage pcpu_freelist_populate() will never race
+* with pcpu_freelist_push()
+*/
+   local_irq_save(flags);
+   for_each_possible_cpu(cpu) {
+again:
+   head = per_cpu_ptr(s->freelist, cpu);
+   __pcpu_freelist_push(head, buf);
+   i++;
+   buf += elem_size;
+   if (i == nr_elems)
+   break;
+   if (i % pcpu_entries)
+   goto again;
+   }
+   local_irq_restore(flags);
+}
+
+struct pcpu_freelist_node *pcpu_freelist_pop(struct pcpu_freelist *s)
+{
+   struct pcpu_freelist_head *head;
+   struct pcpu_freelist_node *node;
+   int orig_cpu, cpu;
+
+   orig_cpu = cpu = raw_smp_processor_id();
+   while (1) {
+   head = per_cpu_ptr(s->freelist, cpu);
+   raw_spin_lock(&head->lock);
+   node = head->first;
+   if (node) {
+   head->first = node->next;
+   raw_spin_unlock(&head->lock);
+   return node;
+   }
+   raw_spin_unlock(&head->lock);
+   cpu = cpumask_next(cpu, cpu_possible_mask);
+   if (cpu >= nr_cpu_ids)
+   cpu = 0;
+   if (cpu == orig_cpu)
+   return NULL;
+   }
+}
diff --git a/kernel/bpf/percpu_freelist.h b/kernel/bpf/percpu_freelist.h
new file mode 100644
index ..3049aae8ea1e
--- /dev/null
+++ b/kernel/bpf/percpu_freelist.h
@@ -0,0 +1,31 @@
+/* Copyright (c) 2016 Facebook
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of ver

Re: [PATCH v1] tools/vm/page-types.c: remove memset() in walk_pfn()

[Naoya Horiguchi]

On Tue, Mar 08, 2016 at 08:12:09AM +0300, Konstantin Khlebnikov wrote:
> On Tue, Mar 8, 2016 at 4:47 AM, Naoya Horiguchi
>  wrote:
> > I found that page-types is very slow and my testing shows many timeout 
> > errors.
> > Here's an example with a simple program allocating 1000 thps.
> >
> >   $ time ./page-types -p $(pgrep -f test_alloc)
> >   ...
> >   real0m17.201s
> >   user0m16.889s
> >   sys 0m0.312s
> >
> >   $ time ./page-types.patched -p $(pgrep -f test_alloc)
> >   ...
> >   real0m0.182s
> >   user0m0.046s
> >   sys 0m0.135s
> >
> > Most of time is spent in memset(), which isn't necessary because we check
> > that the return of kpagecgroup_read() is equal to pages and uninitialized
> > memory is never used. So we can drop this memset().
> 
> These zeros are used in show_page_range() - for merging pages into ranges.

Hi Konstantin,

Thank you for the response. The below code does solve the problem, so that's 
fine.

But I don't understand how the zeros are used. show_page_range() is called
via add_page() which is called for i=0 to i=pages-1, and the buffer cgi is
already filled for the range [i, pages-1] by kpagecgroup_read(), so even if
without zero initialization, kpagecgroup_read() properly fills zeros, right?
IOW, is there any problem if we don't do this zero initialization?

Thanks,
Naoya Horiguchi

> You could add fast-path for count=1
> 
> @@ -633,7 +633,10 @@ static void walk_pfn(unsigned long voffset,
> unsigned long pages;
> unsigned long i;
> 
> -   memset(cgi, 0, sizeof cgi);
> +   if (count == 1)
> +   cgi[0] = 0;
> +   else
> +   memset(cgi, 0, sizeof cgi);
> 
> while (count) {
> batch = min_t(unsigned long, count, KPAGEFLAGS_BATCH);
> 

[PATCH v2 net-next 07/12] samples/bpf: move ksym_search() into library

[Alexei Starovoitov]

move ksym search from offwaketime into library to be reused
in other tests

Signed-off-by: Alexei Starovoitov 
---
 samples/bpf/bpf_load.c | 62 ++
 samples/bpf/bpf_load.h |  6 
 samples/bpf/offwaketime_user.c | 67 +-
 3 files changed, 69 insertions(+), 66 deletions(-)

diff --git a/samples/bpf/bpf_load.c b/samples/bpf/bpf_load.c
index 816bca5760a0..d16864293c00 100644
--- a/samples/bpf/bpf_load.c
+++ b/samples/bpf/bpf_load.c
@@ -346,3 +346,65 @@ void read_trace_pipe(void)
}
}
 }
+
+#define MAX_SYMS 30
+static struct ksym syms[MAX_SYMS];
+static int sym_cnt;
+
+static int ksym_cmp(const void *p1, const void *p2)
+{
+   return ((struct ksym *)p1)->addr - ((struct ksym *)p2)->addr;
+}
+
+int load_kallsyms(void)
+{
+   FILE *f = fopen("/proc/kallsyms", "r");
+   char func[256], buf[256];
+   char symbol;
+   void *addr;
+   int i = 0;
+
+   if (!f)
+   return -ENOENT;
+
+   while (!feof(f)) {
+   if (!fgets(buf, sizeof(buf), f))
+   break;
+   if (sscanf(buf, "%p %c %s", &addr, &symbol, func) != 3)
+   break;
+   if (!addr)
+   continue;
+   syms[i].addr = (long) addr;
+   syms[i].name = strdup(func);
+   i++;
+   }
+   sym_cnt = i;
+   qsort(syms, sym_cnt, sizeof(struct ksym), ksym_cmp);
+   return 0;
+}
+
+struct ksym *ksym_search(long key)
+{
+   int start = 0, end = sym_cnt;
+   int result;
+
+   while (start < end) {
+   size_t mid = start + (end - start) / 2;
+
+   result = key - syms[mid].addr;
+   if (result < 0)
+   end = mid;
+   else if (result > 0)
+   start = mid + 1;
+   else
+   return &syms[mid];
+   }
+
+   if (start >= 1 && syms[start - 1].addr < key &&
+   key < syms[start].addr)
+   /* valid ksym */
+   return &syms[start - 1];
+
+   /* out of range. return _stext */
+   return &syms[0];
+}
diff --git a/samples/bpf/bpf_load.h b/samples/bpf/bpf_load.h
index cbd7c2b532b9..dfa57fe65c8e 100644
--- a/samples/bpf/bpf_load.h
+++ b/samples/bpf/bpf_load.h
@@ -23,5 +23,11 @@ extern int event_fd[MAX_PROGS];
 int load_bpf_file(char *path);
 
 void read_trace_pipe(void);
+struct ksym {
+   long addr;
+   char *name;
+};
 
+int load_kallsyms(void);
+struct ksym *ksym_search(long key);
 #endif
diff --git a/samples/bpf/offwaketime_user.c b/samples/bpf/offwaketime_user.c
index 17cf3024e22c..6f002a9c24fa 100644
--- a/samples/bpf/offwaketime_user.c
+++ b/samples/bpf/offwaketime_user.c
@@ -18,80 +18,15 @@
 #include "libbpf.h"
 #include "bpf_load.h"
 
-#define MAX_SYMS 30
 #define PRINT_RAW_ADDR 0
 
-static struct ksym {
-   long addr;
-   char *name;
-} syms[MAX_SYMS];
-static int sym_cnt;
-
-static int ksym_cmp(const void *p1, const void *p2)
-{
-   return ((struct ksym *)p1)->addr - ((struct ksym *)p2)->addr;
-}
-
-static int load_kallsyms(void)
-{
-   FILE *f = fopen("/proc/kallsyms", "r");
-   char func[256], buf[256];
-   char symbol;
-   void *addr;
-   int i = 0;
-
-   if (!f)
-   return -ENOENT;
-
-   while (!feof(f)) {
-   if (!fgets(buf, sizeof(buf), f))
-   break;
-   if (sscanf(buf, "%p %c %s", &addr, &symbol, func) != 3)
-   break;
-   if (!addr)
-   continue;
-   syms[i].addr = (long) addr;
-   syms[i].name = strdup(func);
-   i++;
-   }
-   sym_cnt = i;
-   qsort(syms, sym_cnt, sizeof(struct ksym), ksym_cmp);
-   return 0;
-}
-
-static void *search(long key)
-{
-   int start = 0, end = sym_cnt;
-   int result;
-
-   while (start < end) {
-   size_t mid = start + (end - start) / 2;
-
-   result = key - syms[mid].addr;
-   if (result < 0)
-   end = mid;
-   else if (result > 0)
-   start = mid + 1;
-   else
-   return &syms[mid];
-   }
-
-   if (start >= 1 && syms[start - 1].addr < key &&
-   key < syms[start].addr)
-   /* valid ksym */
-   return &syms[start - 1];
-
-   /* out of range. return _stext */
-   return &syms[0];
-}
-
 static void print_ksym(__u64 addr)
 {
struct ksym *sym;
 
if (!addr)
return;
-   sym = search(addr);
+   sym = ksym_search(addr);
if (PRINT_RAW_ADDR)
printf("%s/%llx;", sym->name, addr);
else
-- 
2.8.0.rc1

[PATCH v2 net-next 06/12] samples/bpf: make map creation more verbose

[Alexei Starovoitov]

map creation is typically the first one to fail when rlimits are
too low, not enough memory, etc
Make this failure scenario more verbose

Signed-off-by: Alexei Starovoitov 
---
 samples/bpf/bpf_load.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/samples/bpf/bpf_load.c b/samples/bpf/bpf_load.c
index da86a8e0a95a..816bca5760a0 100644
--- a/samples/bpf/bpf_load.c
+++ b/samples/bpf/bpf_load.c
@@ -158,8 +158,11 @@ static int load_maps(struct bpf_map_def *maps, int len)
   maps[i].key_size,
   maps[i].value_size,
   maps[i].max_entries);
-   if (map_fd[i] < 0)
+   if (map_fd[i] < 0) {
+   printf("failed to create a map: %d %s\n",
+  errno, strerror(errno));
return 1;
+   }
 
if (maps[i].type == BPF_MAP_TYPE_PROG_ARRAY)
prog_array_fd = map_fd[i];
-- 
2.8.0.rc1

[PATCH v2 net-next 03/12] bpf: pre-allocate hash map elements

[Alexei Starovoitov]

If kprobe is placed on spin_unlock then calling kmalloc/kfree from
bpf programs is not safe, since the following dead lock is possible:
kfree->spin_lock(kmem_cache_node->lock)...spin_unlock->kprobe->
bpf_prog->map_update->kmalloc->spin_lock(of the same kmem_cache_node->lock)
and deadlocks.

The following solutions were considered and some implemented, but
eventually discarded
- kmem_cache_create for every map
- add recursion check to slow-path of slub
- use reserved memory in bpf_map_update for in_irq or in preempt_disabled
- kmalloc via irq_work

At the end pre-allocation of all map elements turned out to be the simplest
solution and since the user is charged upfront for all the memory, such
pre-allocation doesn't affect the user space visible behavior.

Since it's impossible to tell whether kprobe is triggered in a safe
location from kmalloc point of view, use pre-allocation by default
and introduce new BPF_F_NO_PREALLOC flag.

While testing of per-cpu hash maps it was discovered
that alloc_percpu(GFP_ATOMIC) has odd corner cases and often
fails to allocate memory even when 90% of it is free.
The pre-allocation of per-cpu hash elements solves this problem as well.

Turned out that bpf_map_update() quickly followed by
bpf_map_lookup()+bpf_map_delete() is very common pattern used
in many of iovisor/bcc/tools, so there is additional benefit of
pre-allocation, since such use cases are must faster.

Since all hash map elements are now pre-allocated we can remove
atomic increment of htab->count and save few more cycles.

Also add bpf_map_precharge_memlock() to check rlimit_memlock early to avoid
large malloc/free done by users who don't have sufficient limits.

Pre-allocation is done with vmalloc and alloc/free is done
via percpu_freelist. Here are performance numbers for different
pre-allocation algorithms that were implemented, but discarded
in favor of percpu_freelist:

1 cpu:
pcpu_ida2.1M
pcpu_ida nolock 2.3M
bt  2.4M
kmalloc 1.8M
hlist+spinlock  2.3M
pcpu_freelist   2.6M

4 cpu:
pcpu_ida1.5M
pcpu_ida nolock 1.8M
bt w/smp_align  1.7M
bt no/smp_align 1.1M
kmalloc 0.7M
hlist+spinlock  0.2M
pcpu_freelist   2.0M

8 cpu:
pcpu_ida0.7M
bt w/smp_align  0.8M
kmalloc 0.4M
pcpu_freelist   1.5M

32 cpu:
kmalloc 0.13M
pcpu_freelist   0.49M

pcpu_ida nolock is a modified percpu_ida algorithm without
percpu_ida_cpu locks and without cross-cpu tag stealing.
It's faster than existing percpu_ida, but not as fast as pcpu_freelist.

bt is a variant of block/blk-mq-tag.c simlified and customized
for bpf use case. bt w/smp_align is using cache line for every 'long'
(similar to blk-mq-tag). bt no/smp_align allocates 'long'
bitmasks continuously to save memory. It's comparable to percpu_ida
and in some cases faster, but slower than percpu_freelist

hlist+spinlock is the simplest free list with single spinlock.
As expeceted it has very bad scaling in SMP.

kmalloc is existing implementation which is still available via
BPF_F_NO_PREALLOC flag. It's significantly slower in single cpu and
in 8 cpu setup it's 3 times slower than pre-allocation with pcpu_freelist,
but saves memory, so in cases where map->max_entries can be large
and number of map update/delete per second is low, it may make
sense to use it.

Signed-off-by: Alexei Starovoitov 
---
 include/linux/bpf.h  |   2 +
 include/uapi/linux/bpf.h |   3 +
 kernel/bpf/hashtab.c | 240 +--
 kernel/bpf/syscall.c |  15 ++-
 4 files changed, 186 insertions(+), 74 deletions(-)

diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 4b070827200d..efd1d4ca95c6 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -37,6 +37,7 @@ struct bpf_map {
u32 key_size;
u32 value_size;
u32 max_entries;
+   u32 map_flags;
u32 pages;
struct user_struct *user;
const struct bpf_map_ops *ops;
@@ -178,6 +179,7 @@ struct bpf_map *__bpf_map_get(struct fd f);
 void bpf_map_inc(struct bpf_map *map, bool uref);
 void bpf_map_put_with_uref(struct bpf_map *map);
 void bpf_map_put(struct bpf_map *map);
+int bpf_map_precharge_memlock(u32 pages);
 
 extern int sysctl_unprivileged_bpf_disabled;
 
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 6496f98d3d68..7b4535e6325c 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -101,12 +101,15 @@ enum bpf_prog_type {
 #define BPF_NOEXIST1 /* create new element if it didn't exist */
 #define BPF_EXIST  2 /* update existing element */
 
+#define BPF_F_NO_PREALLOC  (1U << 0)
+
 union bpf_attr {
struct { /* anonymous struct used by BPF_MAP_CREATE command */
__u32   map_type;   /* one of enum bpf_map_type */
__u32   key_size;   /* size of key in bytes */
__u32   value_size; /* size of value in bytes */
__u32   max_entries;/* max number of entries in a ma

[PATCH v2 net-next 01/12] bpf: prevent kprobe+bpf deadlocks

[Alexei Starovoitov]

if kprobe is placed within update or delete hash map helpers
that hold bucket spin lock and triggered bpf program is trying to
grab the spinlock for the same bucket on the same cpu, it will
deadlock.
Fix it by extending existing recursion prevention mechanism.

Note, map_lookup and other tracing helpers don't have this problem,
since they don't hold any locks and don't modify global data.
bpf_trace_printk has its own recursive check and ok as well.

Signed-off-by: Alexei Starovoitov 
Acked-by: Daniel Borkmann 
---
 include/linux/bpf.h  |  3 +++
 kernel/bpf/syscall.c | 13 +
 kernel/trace/bpf_trace.c |  2 --
 3 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 51e498e5470e..4b070827200d 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct bpf_map;
 
@@ -163,6 +164,8 @@ bool bpf_prog_array_compatible(struct bpf_array *array, 
const struct bpf_prog *f
 const struct bpf_func_proto *bpf_get_trace_printk_proto(void);
 
 #ifdef CONFIG_BPF_SYSCALL
+DECLARE_PER_CPU(int, bpf_prog_active);
+
 void bpf_register_prog_type(struct bpf_prog_type_list *tl);
 void bpf_register_map_type(struct bpf_map_type_list *tl);
 
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index c95a753c2007..dc99f6a000f5 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -18,6 +18,8 @@
 #include 
 #include 
 
+DEFINE_PER_CPU(int, bpf_prog_active);
+
 int sysctl_unprivileged_bpf_disabled __read_mostly;
 
 static LIST_HEAD(bpf_map_types);
@@ -347,6 +349,11 @@ static int map_update_elem(union bpf_attr *attr)
if (copy_from_user(value, uvalue, value_size) != 0)
goto free_value;
 
+   /* must increment bpf_prog_active to avoid kprobe+bpf triggering from
+* inside bpf map update or delete otherwise deadlocks are possible
+*/
+   preempt_disable();
+   __this_cpu_inc(bpf_prog_active);
if (map->map_type == BPF_MAP_TYPE_PERCPU_HASH) {
err = bpf_percpu_hash_update(map, key, value, attr->flags);
} else if (map->map_type == BPF_MAP_TYPE_PERCPU_ARRAY) {
@@ -356,6 +363,8 @@ static int map_update_elem(union bpf_attr *attr)
err = map->ops->map_update_elem(map, key, value, attr->flags);
rcu_read_unlock();
}
+   __this_cpu_dec(bpf_prog_active);
+   preempt_enable();
 
 free_value:
kfree(value);
@@ -394,9 +403,13 @@ static int map_delete_elem(union bpf_attr *attr)
if (copy_from_user(key, ukey, map->key_size) != 0)
goto free_key;
 
+   preempt_disable();
+   __this_cpu_inc(bpf_prog_active);
rcu_read_lock();
err = map->ops->map_delete_elem(map, key);
rcu_read_unlock();
+   __this_cpu_dec(bpf_prog_active);
+   preempt_enable();
 
 free_key:
kfree(key);
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 4b8caa392b86..3e4ffb3ace5f 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -13,8 +13,6 @@
 #include 
 #include "trace.h"
 
-static DEFINE_PER_CPU(int, bpf_prog_active);
-
 /**
  * trace_call_bpf - invoke BPF program
  * @prog: BPF program
-- 
2.8.0.rc1

[PATCH v2 net-next 05/12] bpf: convert stackmap to pre-allocation

[Alexei Starovoitov]

It was observed that calling bpf_get_stackid() from a kprobe inside
slub or from spin_unlock causes similar deadlock as with hashmap,
therefore convert stackmap to use pre-allocated memory.

The call_rcu is no longer feasible mechanism, since delayed freeing
causes bpf_get_stackid() to fail unpredictably when number of actual
stacks is significantly less than user requested max_entries.
Since elements are no longer freed into slub, we can push elements into
freelist immediately and let them be recycled.
However the very unlikley race between user space map_lookup() and
program-side recycling is possible:
 cpu0  cpu1
   
user does lookup(stackidX)
starts copying ips into buffer
   delete(stackidX)
   calls bpf_get_stackid()
   which recyles the element and
   overwrites with new stack trace

To avoid user space seeing a partial stack trace consisting of two
merged stack traces, do bucket = xchg(, NULL); copy; xchg(,bucket);
to preserve consistent stack trace delivery to user space.
Now we can move memset(,0) of left-over element value from critical
path of bpf_get_stackid() into slow-path of user space lookup.
Also disallow lookup() from bpf program, since it's useless and
program shouldn't be messing with collected stack trace.

Note that similar race between user space lookup and kernel side updates
is also present in hashmap, but it's not a new race. bpf programs were
always allowed to modify hash and array map elements while user space
is copying them.

Fixes: d5a3b1f69186 ("bpf: introduce BPF_MAP_TYPE_STACK_TRACE")
Signed-off-by: Alexei Starovoitov 
---
 include/linux/bpf.h   |  1 +
 kernel/bpf/stackmap.c | 86 ---
 kernel/bpf/syscall.c  |  2 ++
 3 files changed, 71 insertions(+), 18 deletions(-)

diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index efd1d4ca95c6..21ee41b92e8a 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -195,6 +195,7 @@ int bpf_percpu_hash_update(struct bpf_map *map, void *key, 
void *value,
   u64 flags);
 int bpf_percpu_array_update(struct bpf_map *map, void *key, void *value,
u64 flags);
+int bpf_stackmap_copy(struct bpf_map *map, void *key, void *value);
 
 /* memcpy that is used with 8-byte aligned pointers, power-of-8 size and
  * forced to use 'long' read/writes to try to atomically copy long counters.
diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
index f0a02c344358..499d9e933f8e 100644
--- a/kernel/bpf/stackmap.c
+++ b/kernel/bpf/stackmap.c
@@ -10,9 +10,10 @@
 #include 
 #include 
 #include 
+#include "percpu_freelist.h"
 
 struct stack_map_bucket {
-   struct rcu_head rcu;
+   struct pcpu_freelist_node fnode;
u32 hash;
u32 nr;
u64 ip[];
@@ -20,10 +21,34 @@ struct stack_map_bucket {
 
 struct bpf_stack_map {
struct bpf_map map;
+   void *elems;
+   struct pcpu_freelist freelist;
u32 n_buckets;
-   struct stack_map_bucket __rcu *buckets[];
+   struct stack_map_bucket *buckets[];
 };
 
+static int prealloc_elems_and_freelist(struct bpf_stack_map *smap)
+{
+   u32 elem_size = sizeof(struct stack_map_bucket) + smap->map.value_size;
+   int err;
+
+   smap->elems = vzalloc(elem_size * smap->map.max_entries);
+   if (!smap->elems)
+   return -ENOMEM;
+
+   err = pcpu_freelist_init(&smap->freelist);
+   if (err)
+   goto free_elems;
+
+   pcpu_freelist_populate(&smap->freelist, smap->elems, elem_size,
+  smap->map.max_entries);
+   return 0;
+
+free_elems:
+   vfree(smap->elems);
+   return err;
+}
+
 /* Called from syscall */
 static struct bpf_map *stack_map_alloc(union bpf_attr *attr)
 {
@@ -70,12 +95,22 @@ static struct bpf_map *stack_map_alloc(union bpf_attr *attr)
smap->n_buckets = n_buckets;
smap->map.pages = round_up(cost, PAGE_SIZE) >> PAGE_SHIFT;
 
+   err = bpf_map_precharge_memlock(smap->map.pages);
+   if (err)
+   goto free_smap;
+
err = get_callchain_buffers();
if (err)
goto free_smap;
 
+   err = prealloc_elems_and_freelist(smap);
+   if (err)
+   goto put_buffers;
+
return &smap->map;
 
+put_buffers:
+   put_callchain_buffers();
 free_smap:
kvfree(smap);
return ERR_PTR(err);
@@ -121,7 +156,7 @@ static u64 bpf_get_stackid(u64 r1, u64 r2, u64 flags, u64 
r4, u64 r5)
ips = trace->ip + skip + init_nr;
hash = jhash2((u32 *)ips, trace_len / sizeof(u32), 0);
id = hash & (smap->n_buckets - 1);
-   bucket = rcu_dereference(smap->buckets[id]);
+   bucket = READ_ONCE(smap->buckets[id]);
 
if (bucket && bucket->hash == hash) {
if (flag

[PATCH v2 net-next 04/12] bpf: check for reserved flag bits in array and stack maps

[Alexei Starovoitov]

Suggested-by: Daniel Borkmann 
Signed-off-by: Alexei Starovoitov 
---
 kernel/bpf/arraymap.c | 2 +-
 kernel/bpf/stackmap.c | 3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index bd3bdf2486a7..76d5a794e426 100644
--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -53,7 +53,7 @@ static struct bpf_map *array_map_alloc(union bpf_attr *attr)
 
/* check sanity of attributes */
if (attr->max_entries == 0 || attr->key_size != 4 ||
-   attr->value_size == 0)
+   attr->value_size == 0 || attr->map_flags)
return ERR_PTR(-EINVAL);
 
if (attr->value_size >= 1 << (KMALLOC_SHIFT_MAX - 1))
diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
index 8a60ee14a977..f0a02c344358 100644
--- a/kernel/bpf/stackmap.c
+++ b/kernel/bpf/stackmap.c
@@ -35,6 +35,9 @@ static struct bpf_map *stack_map_alloc(union bpf_attr *attr)
if (!capable(CAP_SYS_ADMIN))
return ERR_PTR(-EPERM);
 
+   if (attr->map_flags)
+   return ERR_PTR(-EINVAL);
+
/* check sanity of attributes */
if (attr->max_entries == 0 || attr->key_size != 4 ||
value_size < 8 || value_size % 8 ||
-- 
2.8.0.rc1

[PATCH v2 net-next 09/12] samples/bpf: test both pre-alloc and normal maps

[Alexei Starovoitov]

extend test coveraged to include pre-allocated and run-time alloc maps

Signed-off-by: Alexei Starovoitov 
---
 samples/bpf/test_maps.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/samples/bpf/test_maps.c b/samples/bpf/test_maps.c
index 7bd9edd02d9b..47bf0858f9e4 100644
--- a/samples/bpf/test_maps.c
+++ b/samples/bpf/test_maps.c
@@ -468,7 +468,7 @@ static void test_map_parallel(void)
assert(bpf_get_next_key(map_fd, &key, &key) == -1 && errno == ENOENT);
 }
 
-int main(void)
+static void run_all_tests(void)
 {
test_hashmap_sanity(0, NULL);
test_percpu_hashmap_sanity(0, NULL);
@@ -479,6 +479,14 @@ int main(void)
test_map_large();
test_map_parallel();
test_map_stress();
+}
+
+int main(void)
+{
+   map_flags = 0;
+   run_all_tests();
+   map_flags = BPF_F_NO_PREALLOC;
+   run_all_tests();
printf("test_maps: OK\n");
return 0;
 }
-- 
2.8.0.rc1

[PATCH v2 net-next 08/12] samples/bpf: add map_flags to bpf loader

[Alexei Starovoitov]

note old loader is compatible with new kernel.
map_flags are optional

Signed-off-by: Alexei Starovoitov 
---
 samples/bpf/bpf_helpers.h   |  1 +
 samples/bpf/bpf_load.c  |  3 ++-
 samples/bpf/fds_example.c   |  2 +-
 samples/bpf/libbpf.c|  5 +++--
 samples/bpf/libbpf.h|  2 +-
 samples/bpf/sock_example.c  |  2 +-
 samples/bpf/test_maps.c | 19 ---
 samples/bpf/test_verifier.c |  4 ++--
 8 files changed, 23 insertions(+), 15 deletions(-)

diff --git a/samples/bpf/bpf_helpers.h b/samples/bpf/bpf_helpers.h
index 811bcca0f29d..9363500131a7 100644
--- a/samples/bpf/bpf_helpers.h
+++ b/samples/bpf/bpf_helpers.h
@@ -61,6 +61,7 @@ struct bpf_map_def {
unsigned int key_size;
unsigned int value_size;
unsigned int max_entries;
+   unsigned int map_flags;
 };
 
 static int (*bpf_skb_store_bytes)(void *ctx, int off, void *from, int len, int 
flags) =
diff --git a/samples/bpf/bpf_load.c b/samples/bpf/bpf_load.c
index d16864293c00..58f86bd11b3d 100644
--- a/samples/bpf/bpf_load.c
+++ b/samples/bpf/bpf_load.c
@@ -157,7 +157,8 @@ static int load_maps(struct bpf_map_def *maps, int len)
map_fd[i] = bpf_create_map(maps[i].type,
   maps[i].key_size,
   maps[i].value_size,
-  maps[i].max_entries);
+  maps[i].max_entries,
+  maps[i].map_flags);
if (map_fd[i] < 0) {
printf("failed to create a map: %d %s\n",
   errno, strerror(errno));
diff --git a/samples/bpf/fds_example.c b/samples/bpf/fds_example.c
index e2fd16c3d0f0..625e797be6ef 100644
--- a/samples/bpf/fds_example.c
+++ b/samples/bpf/fds_example.c
@@ -44,7 +44,7 @@ static void usage(void)
 static int bpf_map_create(void)
 {
return bpf_create_map(BPF_MAP_TYPE_ARRAY, sizeof(uint32_t),
- sizeof(uint32_t), 1024);
+ sizeof(uint32_t), 1024, 0);
 }
 
 static int bpf_prog_create(const char *object)
diff --git a/samples/bpf/libbpf.c b/samples/bpf/libbpf.c
index 65a8d48d2799..9969e35550c3 100644
--- a/samples/bpf/libbpf.c
+++ b/samples/bpf/libbpf.c
@@ -19,13 +19,14 @@ static __u64 ptr_to_u64(void *ptr)
 }
 
 int bpf_create_map(enum bpf_map_type map_type, int key_size, int value_size,
-  int max_entries)
+  int max_entries, int map_flags)
 {
union bpf_attr attr = {
.map_type = map_type,
.key_size = key_size,
.value_size = value_size,
-   .max_entries = max_entries
+   .max_entries = max_entries,
+   .map_flags = map_flags,
};
 
return syscall(__NR_bpf, BPF_MAP_CREATE, &attr, sizeof(attr));
diff --git a/samples/bpf/libbpf.h b/samples/bpf/libbpf.h
index 014aacf916e4..364582b77888 100644
--- a/samples/bpf/libbpf.h
+++ b/samples/bpf/libbpf.h
@@ -5,7 +5,7 @@
 struct bpf_insn;
 
 int bpf_create_map(enum bpf_map_type map_type, int key_size, int value_size,
-  int max_entries);
+  int max_entries, int map_flags);
 int bpf_update_elem(int fd, void *key, void *value, unsigned long long flags);
 int bpf_lookup_elem(int fd, void *key, void *value);
 int bpf_delete_elem(int fd, void *key);
diff --git a/samples/bpf/sock_example.c b/samples/bpf/sock_example.c
index a0ce251c5390..28b60baa9fa8 100644
--- a/samples/bpf/sock_example.c
+++ b/samples/bpf/sock_example.c
@@ -34,7 +34,7 @@ static int test_sock(void)
long long value = 0, tcp_cnt, udp_cnt, icmp_cnt;
 
map_fd = bpf_create_map(BPF_MAP_TYPE_ARRAY, sizeof(key), sizeof(value),
-   256);
+   256, 0);
if (map_fd < 0) {
printf("failed to create map '%s'\n", strerror(errno));
goto cleanup;
diff --git a/samples/bpf/test_maps.c b/samples/bpf/test_maps.c
index ad466ed33093..7bd9edd02d9b 100644
--- a/samples/bpf/test_maps.c
+++ b/samples/bpf/test_maps.c
@@ -2,6 +2,7 @@
  * Testsuite for eBPF maps
  *
  * Copyright (c) 2014 PLUMgrid, http://plumgrid.com
+ * Copyright (c) 2016 Facebook
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of version 2 of the GNU General Public
@@ -17,13 +18,16 @@
 #include 
 #include "libbpf.h"
 
+static int map_flags;
+
 /* sanity tests for map API */
 static void test_hashmap_sanity(int i, void *data)
 {
long long key, next_key, value;
int map_fd;
 
-   map_fd = bpf_create_map(BPF_MAP_TYPE_HASH, sizeof(key), sizeof(value), 
2);
+   map_fd = bpf_create_map(BPF_MAP_TYPE_HASH, sizeof(key), sizeof(value),
+   2, map_flags);
if (map_fd < 0) {
printf("failed to create hashmap '%s'\n", strerror(errno));
exit(1

[PATCH v2 net-next 0/12] bpf: map pre-alloc

[Alexei Starovoitov]

v1->v2:
. fix few issues spotted by Daniel
. converted stackmap into pre-allocation as well
. added a workaround for lockdep false positive
. added pcpu_freelist_populate to be used by hashmap and stackmap

this path set switches bpf hash map to use pre-allocation by default
and introduces BPF_F_NO_PREALLOC flag to keep old behavior for cases
where full map pre-allocation is too memory expensive.

Some time back Daniel Wagner reported crashes when bpf hash map is
used to compute time intervals between preempt_disable->preempt_enable
and recently Tom Zanussi reported a dead lock in iovisor/bcc/funccount
tool if it's used to count the number of invocations of kernel
'*spin*' functions. Both problems are due to the recursive use of
slub and can only be solved by pre-allocating all map elements.

A lot of different solutions were considered. Many implemented,
but at the end pre-allocation seems to be the only feasible answer.
As far as pre-allocation goes it also was implemented 4 different ways:
- simple free-list with single lock
- percpu_ida with optimizations
- blk-mq-tag variant customized for bpf use case
- percpu_freelist
For bpf style of alloc/free patterns percpu_freelist is the best
and implemented in this patch set.
Detailed performance numbers in patch 3.
Patch 2 introduces percpu_freelist
Patch 1 fixes simple deadlocks due to missing recursion checks
Patch 5: converts stackmap to pre-allocation
Patches 6-9: prepare test infra
Patch 10: stress test for hash map infra. It attaches to spin_lock
functions and bpf_map_update/delete are called from different contexts
Patch 11: stress for bpf_get_stackid
Patch 12: map performance test

Reported-by: Daniel Wagner 
Reported-by: Tom Zanussi 

Alexei Starovoitov (12):
  bpf: prevent kprobe+bpf deadlocks
  bpf: introduce percpu_freelist
  bpf: pre-allocate hash map elements
  bpf: check for reserved flag bits in array and stack maps
  bpf: convert stackmap to pre-allocation
  samples/bpf: make map creation more verbose
  samples/bpf: move ksym_search() into library
  samples/bpf: add map_flags to bpf loader
  samples/bpf: test both pre-alloc and normal maps
  samples/bpf: add bpf map stress test
  samples/bpf: stress test bpf_get_stackid
  samples/bpf: add map performance test

 include/linux/bpf.h  |   6 +
 include/uapi/linux/bpf.h |   3 +
 kernel/bpf/Makefile  |   2 +-
 kernel/bpf/arraymap.c|   2 +-
 kernel/bpf/hashtab.c | 240 +++
 kernel/bpf/percpu_freelist.c | 100 
 kernel/bpf/percpu_freelist.h |  31 +
 kernel/bpf/stackmap.c|  89 ---
 kernel/bpf/syscall.c |  30 -
 kernel/trace/bpf_trace.c |   2 -
 samples/bpf/Makefile |   8 ++
 samples/bpf/bpf_helpers.h|   1 +
 samples/bpf/bpf_load.c   |  70 +++-
 samples/bpf/bpf_load.h   |   6 +
 samples/bpf/fds_example.c|   2 +-
 samples/bpf/libbpf.c |   5 +-
 samples/bpf/libbpf.h |   2 +-
 samples/bpf/map_perf_test_kern.c | 100 
 samples/bpf/map_perf_test_user.c | 155 +
 samples/bpf/offwaketime_user.c   |  67 +--
 samples/bpf/sock_example.c   |   2 +-
 samples/bpf/spintest_kern.c  |  68 +++
 samples/bpf/spintest_user.c  |  50 
 samples/bpf/test_maps.c  |  29 +++--
 samples/bpf/test_verifier.c  |   4 +-
 25 files changed, 895 insertions(+), 179 deletions(-)
 create mode 100644 kernel/bpf/percpu_freelist.c
 create mode 100644 kernel/bpf/percpu_freelist.h
 create mode 100644 samples/bpf/map_perf_test_kern.c
 create mode 100644 samples/bpf/map_perf_test_user.c
 create mode 100644 samples/bpf/spintest_kern.c
 create mode 100644 samples/bpf/spintest_user.c

-- 
2.8.0.rc1

Re: linux-next: manual merge of the crypto tree with the net-next tree

[Stephen Rothwell]

Hi David,

On Mon, 07 Mar 2016 11:08:25 + David Howells  wrote:
>
> Stephen Rothwell  wrote:
> 
> > Today's linux-next merge of the crypto tree got a conflict in:
> > 
> >   net/rxrpc/rxkad.c
> > 
> > between commit:
> > 
> >   0d12f8a4027d ("rxrpc: Keep the skb private record of the Rx header in 
> > host byte order")
> > 
> > from the net-next tree and commit:
> > 
> >   1afe593b4239 ("rxrpc: Use skcipher")
> > 
> > from the crypto tree.  
> 
> What's the best way to deal with this?  Should I take Herbert's
> 
>   [PATCH 18/26] rxrpc: Use skcipher
> 
> patch into my rxrpc tree also and pass it on to Dave?

Linus can deal with it when he merges the latter of the crypto or
net-next trees.  It might be worth a mention in the respective pull
requests.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH] ARM: dts: add "simple-bus" to "arm, amba-bus" compatible nodes

[Masahiro Yamada]

Hi Rob, Mark, Jon,


Setting aside the future plan, anyway we should avoid
relying on an undocumented compatible string.
(and we should avoid its spread as Rob pointed out.)

I rephrase the git-log  (no update in the code-diff).

Could you check v2, please?
https://patchwork.kernel.org/patch/8529701/

Better?





2016-03-04 5:23 GMT+09:00 Rob Herring :
> On Thu, Mar 3, 2016 at 4:12 AM, Jon Medhurst (Tixy)  wrote:
>> On Thu, 2016-03-03 at 12:07 +0900, Masahiro Yamada wrote:
>> [...]
>>> This patch is derived from Rob Herring' comment
>>> "BTW, we should also kill off "amba-bus" which is an ambiguous term"
>>> in the following thread:
>>> http://lkml.iu.edu/hypermail/linux/kernel/1601.0/01822.html
>>>
>>>
>>> So, the plan would be like this:
>>>
>>> [1] Make device trees not depend on "arm,amba-bus"   (this commit)
>>> [2] New device trees should no longer use "arm,amba-bus" alone.
>>> [3] Go though some releases until we do not care about the backward
>>> compatibility
>>
>> Why would we stop caring about backwards compatibility? If I was a user
>> of any of the platforms in question and updated my kernel, I wouldn't
>> expect to have to debug why it was broken, then install a new dtb to fix
>> it - which may be a tricky thing to do, depending on the firmware used
>> to boot Linux.
>
> If no one notices, then there is no ABI. Things break all the time
> when nobody cares. It will be more than a few releases for sure. We
> may never get to step 3, but we should do step 1 so people stop
> copy-n-pasting this in step 2.
>
> Rob
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards
Masahiro Yamada

Re: [PATCH 2/2] ARM: bcm2835: Add devicetree for the Raspberry Pi 3.

[Stephen Warren]

On 03/04/2016 11:39 AM, Eric Anholt wrote:

For now this doesn't support the new hardware present on the Pi 3 (BT,
wifi, GPIO expander).  Since the GPIO expander isn't supported, we
also don't have the LEDs like the other board files do.


The series,
Acked-by: Stephen Warren 

... although I'd be slightly surprised if this was accepted; when 
AArch64 was first announced, I thought the mainline ARM kernel community 
decided that only 64-bit kernels would be supported on 64-bit HW? Still, 
I don't immediately see that in any commit log or in the kernel doc 
directory, so perhaps I'm misremembering. Hopefully; life is simpler 
that way:-)

[PATCH] include/net/inet_connection_sock.h: Use pr_devel() instead of pr_debug()

[Nick Wang]

When DYNAMIC_DEBUG enabled, pr_debug() depends on KBUILD_MODNAME which
also depends on the modules name in Makefile.
Refer to the information in "scripts/Makefile.lib":

 # $(modname_flags) #defines KBUILD_MODNAME as the name of the module it will
 # end up in (or would, if it gets compiled in)
 # Note: Files that end up in two or more modules are compiled without the
 #   KBUILD_MODNAME definition. The reason is that any made-up name would
 #   differ in different configs.

File "inet_connection_sock.h" is a common share header that not can 
be use for one module, so use pr_devel instead of pr_debug is OK.

In file included from include/linux/printk.h:277:0,
 from include/linux/kernel.h:13,
 from include/linux/list.h:8,
 from include/linux/kobject.h:20,
 from include/linux/device.h:17,
 from include/rdma/ib_verbs.h:43,
 from 
/usr/src/drbd-9.0/drbd/drbd-kernel-compat/tests/have_ib_cq_init_attr.c:1:
include/net/inet_connection_sock.h: In function ‘inet_csk_clear_xmit_timer’:
include/linux/dynamic_debug.h:66:14: error: ‘KBUILD_MODNAME’ undeclared (first 
use in this function)
   .modname = KBUILD_MODNAME,   \
  ^
include/linux/dynamic_debug.h:76:2: note: in expansion of macro 
‘DEFINE_DYNAMIC_DEBUG_METADATA’
  DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt);  \
  ^
include/linux/printk.h:283:2: note: in expansion of macro ‘dynamic_pr_debug’
  dynamic_pr_debug(fmt, ##__VA_ARGS__)
  ^
include/net/inet_connection_sock.h:213:3: note: in expansion of macro ‘pr_debug’
   pr_debug("%s", inet_csk_timer_bug_msg);
   ^

Signed-off-by: Nick Wang 
---
 include/net/inet_connection_sock.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/net/inet_connection_sock.h 
b/include/net/inet_connection_sock.h
index 49dcad4..b59be52 100644
--- a/include/net/inet_connection_sock.h
+++ b/include/net/inet_connection_sock.h
@@ -210,7 +210,7 @@ static inline void inet_csk_clear_xmit_timer(struct sock 
*sk, const int what)
}
 #ifdef INET_CSK_DEBUG
else {
-   pr_debug("%s", inet_csk_timer_bug_msg);
+   pr_devel("%s", inet_csk_timer_bug_msg);
}
 #endif
 }
@@ -226,7 +226,7 @@ static inline void inet_csk_reset_xmit_timer(struct sock 
*sk, const int what,
 
if (when > max_when) {
 #ifdef INET_CSK_DEBUG
-   pr_debug("reset_xmit_timer: sk=%p %d when=0x%lx, caller=%p\n",
+   pr_devel("reset_xmit_timer: sk=%p %d when=0x%lx, caller=%p\n",
 sk, what, when, current_text_addr());
 #endif
when = max_when;
@@ -244,7 +244,7 @@ static inline void inet_csk_reset_xmit_timer(struct sock 
*sk, const int what,
}
 #ifdef INET_CSK_DEBUG
else {
-   pr_debug("%s", inet_csk_timer_bug_msg);
+   pr_devel("%s", inet_csk_timer_bug_msg);
}
 #endif
 }
-- 
1.8.5.6

linux-next: Tree for Mar 8

[Stephen Rothwell]

Hi all,

Changes since 20160307:

The net-next tree gained a conflict against the net tree.

The aio tree still had a build failure so I used the version from
next-20160111.

Non-merge commits (relative to Linus' tree): 9862
 7743 files changed, 367257 insertions(+), 183996 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 241 trees (counting Linus' and 36 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (f6cede5b49e8 Linux 4.5-rc7)
Merging fixes/master (36f90b0a2ddd Linux 4.5-rc2)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (fc77dbd34c5c Linux 4.5-rc6)
Merging arm-current/fixes (f474c8c857d9 ARM: 8544/1: set_memory_xx fixes)
Merging m68k-current/for-linus (daf670bc9d36 m68k/defconfig: Update defconfigs 
for v4.5-rc1)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-fixes/fixes (37c5e942bb2e powerpc/fsl-book3e: Avoid lbarx on 
e5500)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (f983cd32cd5d Merge branch 'parisc-4.5-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux)
Merging net/master (cec05562fb1d vmxnet3: avoid calling pskb_may_pull with 
interrupts disabled)
Merging ipsec/master (3ed01df4ff79 xfrm: Reset encapsulation field of the skb 
before transformation)
Merging ipvs/master (7617a24f83b5 ipvs: correct initial offset of Call-ID 
header search in SIP persistence engine)
Merging wireless-drivers/master (10da848f67a7 ssb: host_soc depends on sprom)
Merging mac80211/master (2af8c4dc2e9c mac80211_hwsim: treat as part of mac80211 
for MAINTAINERS)
Merging sound-current/for-linus (ad09ef2cce91 Merge tag 'asoc-fix-v4.5-rc6' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (1195c103f6c9 PCI: layerscape: Fix MSG TLP drop 
setting)
Merging driver-core.current/driver-core-linus (18558cae0272 Linux 4.5-rc4)
Merging tty.current/tty-linus (18558cae0272 Linux 4.5-rc4)
Merging usb.current/usb-linus (861c3849222b Merge tag 'usb-serial-4.5-rc7' of 
git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus)
Merging usb-gadget-fixes/fixes (3b2435192fe9 MAINTAINERS: drop OMAP USB and 
MUSB maintainership)
Merging usb-serial-fixes/usb-linus (f6cede5b49e8 Linux 4.5-rc7)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (fc77dbd34c5c Linux 4.5-rc6)
Merging char-misc.current/char-misc-linus (fc77dbd34c5c Linux 4.5-rc6)
Merging input-current/for-linus (ff84dabe3c6e Input: colibri-vf50-ts - add 
missing #include )
Merging crypto-current/master (8a3978ad55fb crypto: marvell/cesa - fix test in 
mv_cesa_dev_dma_init())
Merging ide/master (e04a2bd6d8c9 drivers/ide: make ide-scan-pci.c driver 
explicitly non-modular)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (8160c4e45582 vfio: fix ioctl error handling)
Merging kselftes

[PATCH v2] ARM: dts: add "simple-bus" where "arm,amba-bus" is used alone

[Masahiro Yamada]

The compatible string "simple-bus" is well defined in ePAPR, while
I see no documentation for the "arm,amba-bus" in ePAPR or under
Documentation/devicetree/.

DT is also used by other projects than Linux kernel.  It is not a
good idea to rely on such an unofficial binding.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Rephrase the git-log

 arch/arm/boot/dts/axm55xx.dtsi | 2 +-
 arch/arm/boot/dts/exynos3250.dtsi  | 2 +-
 arch/arm/boot/dts/exynos4.dtsi | 2 +-
 arch/arm/boot/dts/exynos4415.dtsi  | 2 +-
 arch/arm/boot/dts/exynos5250.dtsi  | 2 +-
 arch/arm/boot/dts/exynos5420.dtsi  | 2 +-
 arch/arm/boot/dts/exynos5440.dtsi  | 2 +-
 arch/arm/boot/dts/hi3620.dtsi  | 2 +-
 arch/arm/boot/dts/hip01.dtsi   | 2 +-
 arch/arm/boot/dts/hisi-x5hd2.dtsi  | 2 +-
 arch/arm/boot/dts/qcom-apq8064.dtsi| 2 +-
 arch/arm/boot/dts/qcom-msm8660.dtsi| 2 +-
 arch/arm/boot/dts/qcom-msm8960.dtsi| 2 +-
 arch/arm/boot/dts/rk3036.dtsi  | 2 +-
 arch/arm/boot/dts/rk3228.dtsi  | 2 +-
 arch/arm/boot/dts/rk3288.dtsi  | 2 +-
 arch/arm/boot/dts/rk3xxx.dtsi  | 2 +-
 arch/arm/boot/dts/s5pv210.dtsi | 2 +-
 arch/arm/boot/dts/socfpga.dtsi | 2 +-
 arch/arm/boot/dts/socfpga_arria10.dtsi | 2 +-
 arch/arm/boot/dts/ste-nomadik-stn8815.dtsi | 2 +-
 arch/arm/boot/dts/ste-u300.dts | 2 +-
 arch/arm/boot/dts/versatile-ab.dts | 2 +-
 23 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/arch/arm/boot/dts/axm55xx.dtsi b/arch/arm/boot/dts/axm55xx.dtsi
index ea288f0..8da4582 100644
--- a/arch/arm/boot/dts/axm55xx.dtsi
+++ b/arch/arm/boot/dts/axm55xx.dtsi
@@ -107,7 +107,7 @@
};
 
amba {
-   compatible = "arm,amba-bus";
+   compatible = "arm,amba-bus", "simple-bus";
#address-cells = <2>;
#size-cells = <2>;
ranges;
diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
b/arch/arm/boot/dts/exynos3250.dtsi
index 18e3def..0ad4fa7 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -381,7 +381,7 @@
};
 
amba {
-   compatible = "arm,amba-bus";
+   compatible = "arm,amba-bus", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 045785c..d53fd78 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -661,7 +661,7 @@
amba {
#address-cells = <1>;
#size-cells = <1>;
-   compatible = "arm,amba-bus";
+   compatible = "arm,amba-bus", "simple-bus";
interrupt-parent = <&gic>;
ranges;
 
diff --git a/arch/arm/boot/dts/exynos4415.dtsi 
b/arch/arm/boot/dts/exynos4415.dtsi
index ad76484..35d2f99 100644
--- a/arch/arm/boot/dts/exynos4415.dtsi
+++ b/arch/arm/boot/dts/exynos4415.dtsi
@@ -380,7 +380,7 @@
};
 
amba {
-   compatible = "arm,amba-bus";
+   compatible = "arm,amba-bus", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
interrupt-parent = <&gic>;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 33e2d5f..bcaed08 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -674,7 +674,7 @@
amba {
#address-cells = <1>;
#size-cells = <1>;
-   compatible = "arm,amba-bus";
+   compatible = "arm,amba-bus", "simple-bus";
interrupt-parent = <&gic>;
ranges;
 
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 48a0a55..838bde3 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -327,7 +327,7 @@
amba {
#address-cells = <1>;
#size-cells = <1>;
-   compatible = "arm,amba-bus";
+   compatible = "arm,amba-bus", "simple-bus";
interrupt-parent = <&gic>;
ranges;
 
diff --git a/arch/arm/boot/dts/exynos5440.dtsi 
b/arch/arm/boot/dts/exynos5440.dtsi
index f18b51f..5fe5639 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -200,7 +200,7 @@
amba {
#address-cells = <1>;
#size-cells = <1>;
-   compatible = "arm,amba-bus";
+   compatible = "arm,amba-bus", "simple-bus";
interrupt-parent = <&gic>;
ranges;
};
diff --git a/arch/ar

[PATCH] tty: amba-pl011: Use 32-bit accesses for SBSA UART

[Christopher Covington]

From: Christopher Covington 

Version 2 of the Server Base System Architecture (SBSA) describes the
Generic UART registers as 32 bits wide. At least one implementation, found
of the Qualcomm Technologies QDF2432, only supports 32 bit accesses. While
other implementations may also support smaller sized accesses, simply use
32 bit accesses all the time for the SBSA UART for simple, broad,
compatibility.

Signed-off-by: Christopher Covington 
---
 drivers/tty/serial/amba-pl011.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index c0da0cc..ffb5eb8 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -121,6 +121,7 @@ static struct vendor_data vendor_arm = {
 
 static struct vendor_data vendor_sbsa = {
.reg_offset = pl011_std_offsets,
+   .access_32b = true,
.oversampling   = false,
.dma_threshold  = false,
.cts_event_workaround   = false,
-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v10 7/9] arm64: Add trampoline code for kretprobes

[David Long]

On 03/02/2016 04:20 PM, William Cohen wrote:

On 03/01/2016 01:19 PM, Marc Zyngier wrote:

On 01/03/16 02:57, David Long wrote:

From: William Cohen 

The trampoline code is used by kretprobes to capture a return from a probed
function.  This is done by saving the registers, calling the handler, and
restoring the registers. The code then returns to the original saved caller
return address. It is necessary to do this directly instead of using a
software breakpoint because the code used in processing that breakpoint
could itself be kprobe'd and cause a problematic reentry into the debug
exception handler.

Signed-off-by: William Cohen 
Signed-off-by: David A. Long 
---
  arch/arm64/include/asm/kprobes.h   |  2 +
  arch/arm64/kernel/Makefile |  1 +
  arch/arm64/kernel/asm-offsets.c| 22 +++
  arch/arm64/kernel/kprobes.c|  5 +++
  arch/arm64/kernel/kprobes_trampoline.S | 67 ++
  5 files changed, 97 insertions(+)
  create mode 100644 arch/arm64/kernel/kprobes_trampoline.S

diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
index 79c9511..61b4915 100644
--- a/arch/arm64/include/asm/kprobes.h
+++ b/arch/arm64/include/asm/kprobes.h
@@ -56,5 +56,7 @@ int kprobe_exceptions_notify(struct notifier_block *self,
 unsigned long val, void *data);
  int kprobe_breakpoint_handler(struct pt_regs *regs, unsigned int esr);
  int kprobe_single_step_handler(struct pt_regs *regs, unsigned int esr);
+void kretprobe_trampoline(void);
+void __kprobes *trampoline_probe_handler(struct pt_regs *regs);

  #endif /* _ARM_KPROBES_H */
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 08325e5..f192b7d 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -37,6 +37,7 @@ arm64-obj-$(CONFIG_CPU_IDLE)  += cpuidle.o
  arm64-obj-$(CONFIG_JUMP_LABEL)+= jump_label.o
  arm64-obj-$(CONFIG_KGDB)  += kgdb.o
  arm64-obj-$(CONFIG_KPROBES)   += kprobes.o kprobes-arm64.o
\
+  kprobes_trampoline.o 
\
   probes-simulate-insn.o
  arm64-obj-$(CONFIG_EFI)   += efi.o efi-entry.stub.o
  arm64-obj-$(CONFIG_PCI)   += pci.o
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index fffa4ac6..460b54c 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -50,6 +50,28 @@ int main(void)
DEFINE(S_X5,offsetof(struct pt_regs, regs[5]));
DEFINE(S_X6,offsetof(struct pt_regs, regs[6]));
DEFINE(S_X7,offsetof(struct pt_regs, regs[7]));
+  DEFINE(S_X8, offsetof(struct pt_regs, regs[8]));
+  DEFINE(S_X9, offsetof(struct pt_regs, regs[9]));
+  DEFINE(S_X10,offsetof(struct pt_regs, regs[10]));
+  DEFINE(S_X11,offsetof(struct pt_regs, regs[11]));
+  DEFINE(S_X12,offsetof(struct pt_regs, regs[12]));
+  DEFINE(S_X13,offsetof(struct pt_regs, regs[13]));
+  DEFINE(S_X14,offsetof(struct pt_regs, regs[14]));
+  DEFINE(S_X15,offsetof(struct pt_regs, regs[15]));
+  DEFINE(S_X16,offsetof(struct pt_regs, regs[16]));
+  DEFINE(S_X17,offsetof(struct pt_regs, regs[17]));
+  DEFINE(S_X18,offsetof(struct pt_regs, regs[18]));
+  DEFINE(S_X19,offsetof(struct pt_regs, regs[19]));
+  DEFINE(S_X20,offsetof(struct pt_regs, regs[20]));
+  DEFINE(S_X21,offsetof(struct pt_regs, regs[21]));
+  DEFINE(S_X22,offsetof(struct pt_regs, regs[22]));
+  DEFINE(S_X23,offsetof(struct pt_regs, regs[23]));
+  DEFINE(S_X24,offsetof(struct pt_regs, regs[24]));
+  DEFINE(S_X25,offsetof(struct pt_regs, regs[25]));
+  DEFINE(S_X26,offsetof(struct pt_regs, regs[26]));
+  DEFINE(S_X27,offsetof(struct pt_regs, regs[27]));
+  DEFINE(S_X28,offsetof(struct pt_regs, regs[28]));
+  DEFINE(S_X29,offsetof(struct pt_regs, regs[29]));


Do we need all of these? Specially considering that we're only using the
even ones? You may want to consider something like
arch/arm64/kvm/hyp/entry.S does.


Following what arch/arm64/kvm/hyp/entry.S does would make the patch a bit 
smaller.



I have cut the defines in half and duplicated the entry.S style using 
macros.





DEFINE(S_LR,offsetof(struct pt_regs, regs[30]));
DEFINE(S_SP,offsetof(struct pt_regs, sp));
  #ifdef CONFIG_COMPAT

Re: [PATCH v3 16/19] x86, kaslr: Randomize physical and virtual address of kernel separately

[Baoquan He]

On 03/07/16 at 03:51pm, Kees Cook wrote:
> On Fri, Mar 4, 2016 at 8:25 AM, Baoquan He  wrote:
> > On x86_64, in old kaslr implementaion only physical address of kernel
> > loading is randomized. Then calculate the delta of physical address
> > where vmlinux was linked to load and where it is finally loaded. If
> > delta is not equal to 0, namely there's a new physical address where
> > kernel is actually decompressed, relocation handling need be done. Then
> > delta is added to offset of kernel symbol relocation, this makes the
> > address of kernel text mapping move delta long.
> >
> > Here the behavior is changed. Randomize both the physical address
> > where kernel is decompressed and the virtual address where kernel text
> > is mapped. And relocation handling only depends on virtual address
> > randomization. Means if and only if virtual address is randomized to
> > a different value, we add the delta to the offset of kernel relocs.
> >
> > Note that up to now both virtual offset and physical addr randomization
> > cann't exceed CONFIG_RANDOMIZE_BASE_MAX_OFFSET, namely 1G.
> 
> It seems like CONFIG_RANDOMIZE_BASE_MAX_OFFSET should have been
> eliminated when the on-demand page table code was added. Once that was
> added, there's no physical max any more. And virtual randomization
> should have no max at all.
For physically random, yes, CONFIG_RANDOMIZE_BASE_MAX_OFFSET is not
needed anymore. But for virtually random,
CONFIG_RANDOMIZE_BASE_MAX_OFFSET is still mandatory since kernel text
mapping and kernel module mapping share the 2G virtual address space as
follows. Though kaslr increase kernel text mapping from 512M to 1G, it's
still limited, can't exceed CONFIG_RANDOMIZE_BASE_MAX_OFFSET.

[0x8000, 0x] 

But now as you suggested, I would like to change
CONFIG_RANDOMIZE_BASE_MAX_OFFSET to another name because it's only
valid for virtual randomization. A more specific name is better.

> 
> -Kees
> 
> >
> > Signed-off-by: Baoquan He 
> > ---
> >  arch/x86/boot/compressed/aslr.c | 46 
> > +
> >  arch/x86/boot/compressed/misc.c | 40 +--
> >  arch/x86/boot/compressed/misc.h | 19 +
> >  3 files changed, 59 insertions(+), 46 deletions(-)
> >
> > diff --git a/arch/x86/boot/compressed/aslr.c 
> > b/arch/x86/boot/compressed/aslr.c
> > index 3730a33..75ea931 100644
> > --- a/arch/x86/boot/compressed/aslr.c
> > +++ b/arch/x86/boot/compressed/aslr.c
> > @@ -349,7 +349,7 @@ static void process_e820_entry(struct e820entry *entry,
> > }
> >  }
> >
> > -static unsigned long find_random_addr(unsigned long minimum,
> > +static unsigned long find_random_phy_addr(unsigned long minimum,
> >   unsigned long size)
> >  {
> > int i;
> > @@ -387,23 +387,24 @@ static unsigned long find_random_virt_offset(unsigned 
> > long minimum,
> > return random * CONFIG_PHYSICAL_ALIGN + minimum;
> >  }
> >
> > -unsigned char *choose_kernel_location(unsigned char *input,
> > - unsigned long input_size,
> > - unsigned char *output,
> > - unsigned long output_size)
> > +void choose_kernel_location(unsigned char *input,
> > +   unsigned long input_size,
> > +   unsigned char **output,
> > +   unsigned long output_size,
> > +   unsigned char **virt_offset)
> >  {
> > -   unsigned long choice = (unsigned long)output;
> > unsigned long random;
> > +   *virt_offset = (unsigned char *)LOAD_PHYSICAL_ADDR;
> >
> >  #ifdef CONFIG_HIBERNATION
> > if (!cmdline_find_option_bool("kaslr")) {
> > debug_putstr("KASLR disabled by default...\n");
> > -   goto out;
> > +   return;
> > }
> >  #else
> > if (cmdline_find_option_bool("nokaslr")) {
> > debug_putstr("KASLR disabled by cmdline...\n");
> > -   goto out;
> > +   return;
> > }
> >  #endif
> >
> > @@ -411,23 +412,24 @@ unsigned char *choose_kernel_location(unsigned char 
> > *input,
> >
> > /* Record the various known unsafe memory ranges. */
> > mem_avoid_init((unsigned long)input, input_size,
> > -  (unsigned long)output);
> > +  (unsigned long)*output);
> >
> > /* Walk e820 and find a random address. */
> > -   random = find_random_addr(choice, output_size);
> > -   if (!random) {
> > +   random = find_random_phy_addr((unsigned long)*output, output_size);
> > +   if (!random)
> > debug_putstr("KASLR could not find suitable E820 
> > region...\n");
> > -   goto out;
> > +   else {
> > +   if ((unsigned long)*output != random) {
> > +   fill_pagetable(

Re: [PATCH v3 11/19] x86, boot: Add checking for memcpy

[Baoquan He]

On 03/07/16 at 03:36pm, Kees Cook wrote:
> On Fri, Mar 4, 2016 at 8:25 AM, Baoquan He  wrote:
> > From: Yinghai Lu 
> >
> > parse_elf is using local memcpy to move section to running position.
> > That memcpy actually only support no overlapping case or when dest < src.
> >
> > Add checking in memcpy to find out the wrong case for future use, at
> > that time we will need to have backward memcpy for it.
> >
> > Also add comments in parse_elf about the fact.
> 
> Seems like this would be better to just fix the memcpy to handle the overlap?

Yeah, agree. I will remove the code comment.

> 
> -Kees
> 
> >
> > Signed-off-by: Yinghai Lu 
> > ---
> > v2->v3:
> > Add a declaration for error() since its declaration is in misc.h.
> > But it's not included in compressed/string.c.
> >
> >  arch/x86/boot/compressed/misc.c   | 14 +++---
> >  arch/x86/boot/compressed/misc.h   |  2 ++
> >  arch/x86/boot/compressed/string.c | 29 +++--
> >  3 files changed, 36 insertions(+), 9 deletions(-)
> >
> > diff --git a/arch/x86/boot/compressed/misc.c 
> > b/arch/x86/boot/compressed/misc.c
> > index dd7ed8a..4b2cd0c 100644
> > --- a/arch/x86/boot/compressed/misc.c
> > +++ b/arch/x86/boot/compressed/misc.c
> > @@ -114,9 +114,6 @@
> >  #undef memset
> >  #define memzero(s, n)  memset((s), 0, (n))
> >
> > -
> > -static void error(char *m);
> > -
> >  /*
> >   * This is set up by the setup-routine at boot-time
> >   */
> > @@ -243,7 +240,7 @@ void __puthex(unsigned long value)
> > }
> >  }
> >
> > -static void error(char *x)
> > +void error(char *x)
> >  {
> > error_putstr("\n\n");
> > error_putstr(x);
> > @@ -378,9 +375,12 @@ static void parse_elf(void *output)
> >  #else
> > dest = (void *)(phdr->p_paddr);
> >  #endif
> > -   memcpy(dest,
> > -  output + phdr->p_offset,
> > -  phdr->p_filesz);
> > +   /*
> > +* simple version memcpy only can work when dest is
> > +*   smaller than src or no overlapping.
> > +* Here dest is smaller than src always.
> > +*/
> > +   memcpy(dest, output + phdr->p_offset, 
> > phdr->p_filesz);
> > break;
> > default: /* Ignore other PT_* */ break;
> > }
> > diff --git a/arch/x86/boot/compressed/misc.h 
> > b/arch/x86/boot/compressed/misc.h
> > index 11736a6..39d0e9a 100644
> > --- a/arch/x86/boot/compressed/misc.h
> > +++ b/arch/x86/boot/compressed/misc.h
> > @@ -38,6 +38,8 @@ void __puthex(unsigned long value);
> >  #define error_putstr(__x)  __putstr(__x)
> >  #define error_puthex(__x)  __puthex(__x)
> >
> > +void error(char *x);
> > +
> >  #ifdef CONFIG_X86_VERBOSE_BOOTUP
> >
> >  #define debug_putstr(__x)  __putstr(__x)
> > diff --git a/arch/x86/boot/compressed/string.c 
> > b/arch/x86/boot/compressed/string.c
> > index 00e788b..3a935d0 100644
> > --- a/arch/x86/boot/compressed/string.c
> > +++ b/arch/x86/boot/compressed/string.c
> > @@ -1,7 +1,7 @@
> >  #include "../string.c"
> >
> >  #ifdef CONFIG_X86_32
> > -void *memcpy(void *dest, const void *src, size_t n)
> > +void *__memcpy(void *dest, const void *src, size_t n)
> >  {
> > int d0, d1, d2;
> > asm volatile(
> > @@ -15,7 +15,7 @@ void *memcpy(void *dest, const void *src, size_t n)
> > return dest;
> >  }
> >  #else
> > -void *memcpy(void *dest, const void *src, size_t n)
> > +void *__memcpy(void *dest, const void *src, size_t n)
> >  {
> > long d0, d1, d2;
> > asm volatile(
> > @@ -30,6 +30,31 @@ void *memcpy(void *dest, const void *src, size_t n)
> >  }
> >  #endif
> >
> > +extern void error(char *x);
> > +void *memcpy(void *dest, const void *src, size_t n)
> > +{
> > +   unsigned long start_dest, end_dest;
> > +   unsigned long start_src, end_src;
> > +   unsigned long max_start, min_end;
> > +
> > +   if (dest < src)
> > +   return __memcpy(dest, src, n);
> > +
> > +   start_dest = (unsigned long)dest;
> > +   end_dest = (unsigned long)dest + n;
> > +   start_src = (unsigned long)src;
> > +   end_src = (unsigned long)src + n;
> > +   max_start = (start_dest > start_src) ?  start_dest : start_src;
> > +   min_end = (end_dest < end_src) ? end_dest : end_src;
> > +
> > +   if (max_start >= min_end)
> > +   return __memcpy(dest, src, n);
> > +
> > +   error("memcpy does not support overlapping with dest > src!\n");
> > +
> > +   return dest;
> > +}
> > +
> >  void *memset(void *s, int c, size_t n)
> >  {
> > int i;
> > --
> > 2.5.0
> >
> 
> 
> 
> -- 
> Kees Cook
> Chrome OS & Brillo Security

Re: [PATCH v3 10/19] x86, 64bit: Set ident_mapping for kaslr

[Baoquan He]

On 03/07/16 at 03:34pm, Kees Cook wrote:
> On Fri, Mar 4, 2016 at 8:25 AM, Baoquan He  wrote:
> > From: Yinghai Lu 
> > diff --git a/arch/x86/boot/compressed/Makefile 
> > b/arch/x86/boot/compressed/Makefile
> > index 2e7c0ce..229604d 100644
> > --- a/arch/x86/boot/compressed/Makefile
> > +++ b/arch/x86/boot/compressed/Makefile
> > @@ -59,6 +59,9 @@ vmlinux-objs-y := $(obj)/vmlinux.lds 
> > $(obj)/head_$(BITS).o $(obj)/misc.o \
> >
> >  vmlinux-objs-$(CONFIG_EARLY_PRINTK) += $(obj)/early_serial_console.o
> >  vmlinux-objs-$(CONFIG_RANDOMIZE_BASE) += $(obj)/aslr.o
> > +ifdef CONFIG_X86_64
> > +   vmlinux-objs-$(CONFIG_RANDOMIZE_BASE) += $(obj)/misc_pgt.o
> > +endif
> >
> >  $(obj)/eboot.o: KBUILD_CFLAGS += -fshort-wchar -mno-red-zone
> >
> > diff --git a/arch/x86/boot/compressed/aslr.c 
> > b/arch/x86/boot/compressed/aslr.c
> > index b93be03..35f2eac 100644
> > --- a/arch/x86/boot/compressed/aslr.c
> > +++ b/arch/x86/boot/compressed/aslr.c
> > @@ -151,6 +151,7 @@ static void mem_avoid_init(unsigned long input, 
> > unsigned long input_size,
> >  */
> > mem_avoid[0].start = input;
> > mem_avoid[0].size = (output + init_size) - input;
> > +   fill_pagetable(input, (output + init_size) - input);
> 
> These calls should juse use the .start and .size arguments instead of
> the copy/paste.

OK, will change it as follows:

fill_pagetable(mem_avoid[0].start, mem_avoid[0].size);
> 
> >
> > /* Avoid initrd. */
> > initrd_start  = (u64)real_mode->ext_ramdisk_image << 32;
> > @@ -159,6 +160,7 @@ static void mem_avoid_init(unsigned long input, 
> > unsigned long input_size,
> > initrd_size |= real_mode->hdr.ramdisk_size;
> > mem_avoid[1].start = initrd_start;
> > mem_avoid[1].size = initrd_size;
> > +   /* don't need to set mapping for initrd */
> >
> > /* Avoid kernel command line. */
> > cmd_line  = (u64)real_mode->ext_cmd_line_ptr << 32;
> > @@ -169,10 +171,19 @@ static void mem_avoid_init(unsigned long input, 
> > unsigned long input_size,
> > ;
> > mem_avoid[2].start = cmd_line;
> > mem_avoid[2].size = cmd_line_size;
> > +   fill_pagetable(cmd_line, cmd_line_size);
> >
> > /* Avoid params */
> > mem_avoid[3].start = (unsigned long)real_mode;
> > mem_avoid[3].size = sizeof(*real_mode);
> > +   fill_pagetable((unsigned long)real_mode, sizeof(*real_mode));
> > +
> > +   /* don't need to set mapping for setup_data */
> > +
> > +#ifdef CONFIG_X86_VERBOSE_BOOTUP
> > +   /* for video ram */
> > +   fill_pagetable(0, PMD_SIZE);
> > +#endif
> >  }
> >
> >  /* Does this memory vector overlap a known avoided area? */
> > @@ -330,6 +341,9 @@ unsigned char *choose_kernel_location(unsigned char 
> > *input,
> > goto out;
> >
> > choice = random;
> > +
> > +   fill_pagetable(choice, output_size);
> > +   switch_pagetable();
> >  out:
> > return (unsigned char *)choice;
> >  }
> > diff --git a/arch/x86/boot/compressed/head_64.S 
> > b/arch/x86/boot/compressed/head_64.S
> > index 3691451..075bb15 100644
> > --- a/arch/x86/boot/compressed/head_64.S
> > +++ b/arch/x86/boot/compressed/head_64.S
> > @@ -126,7 +126,7 @@ ENTRY(startup_32)
> > /* Initialize Page tables to 0 */
> > lealpgtable(%ebx), %edi
> > xorl%eax, %eax
> > -   movl$((4096*6)/4), %ecx
> > +   movl$(BOOT_INIT_PGT_SIZE/4), %ecx
> > rep stosl
> >
> > /* Build Level 4 */
> > @@ -478,4 +478,4 @@ boot_stack_end:
> > .section ".pgtable","a",@nobits
> > .balign 4096
> >  pgtable:
> > -   .fill 6*4096, 1, 0
> > +   .fill BOOT_PGT_SIZE, 1, 0
> > diff --git a/arch/x86/boot/compressed/misc.h 
> > b/arch/x86/boot/compressed/misc.h
> > index dcf01c2..11736a6 100644
> > --- a/arch/x86/boot/compressed/misc.h
> > +++ b/arch/x86/boot/compressed/misc.h
> > @@ -84,6 +84,17 @@ unsigned char *choose_kernel_location(unsigned char 
> > *input,
> >  }
> >  #endif
> >
> > +#ifdef CONFIG_X86_64
> > +void fill_pagetable(unsigned long start, unsigned long size);
> > +void switch_pagetable(void);
> > +extern unsigned char _pgtable[];
> > +#else
> > +static inline void fill_pagetable(unsigned long start, unsigned long size)
> > +{ }
> > +static inline void switch_pagetable(void)
> > +{ }
> > +#endif
> > +
> >  #ifdef CONFIG_EARLY_PRINTK
> >  /* early_serial_console.c */
> >  extern int early_serial_base;
> > diff --git a/arch/x86/boot/compressed/misc_pgt.c 
> > b/arch/x86/boot/compressed/misc_pgt.c
> > new file mode 100644
> > index 000..954811e
> > --- /dev/null
> > +++ b/arch/x86/boot/compressed/misc_pgt.c
> > @@ -0,0 +1,91 @@
> > +#define __pa(x)  ((unsigned long)(x))
> > +#define __va(x)  ((void *)((unsigned long)(x)))
> > +
> > +#include "misc.h"
> > +
> > +#include 
> > +#include 
> > +
> > +#include "../../mm/ident_map.c"
> > +#include "../string.h"
> > +
> > +struct alloc_pgt_data {
> 

Re: [PATCH v3 12/19] x86, kaslr: Fix a bug that relocation can not be handled when kernel is loaded above 2G

[Baoquan He]

On 03/07/16 at 03:30pm, Kees Cook wrote:
> On Fri, Mar 4, 2016 at 8:25 AM, Baoquan He  wrote:
> > When process 32 bit relocation tables a local variable 'extended'
> > is defined to calculate the physical address of relocs entry.
> > However its type is 'int' which is enough for i386, but not enough
> > for x86_64. That's why relocation can only be handled under 2G.
> > Otherwise a overflow will happen and cause system hang.
> >
> > Here change it to 'long' as 32 bit inverse relocation processing
> > does, and this change is safe for i386 relocation handling.
> >
> > Signed-off-by: Baoquan He 
> 
> Acked-by: Kees Cook 
> 
> This patch should probably be moved up into the start of this series
> instead of living in the middle here, since it's a clear stand-alone
> bug fix.

Of course. Will put it in the start of this series. 

Thanks.

> 
> -Kees
> 
> > ---
> >  arch/x86/boot/compressed/misc.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/boot/compressed/misc.c 
> > b/arch/x86/boot/compressed/misc.c
> > index 4b2cd0c..70445c3 100644
> > --- a/arch/x86/boot/compressed/misc.c
> > +++ b/arch/x86/boot/compressed/misc.c
> > @@ -298,7 +298,7 @@ static void handle_relocations(void *output, unsigned 
> > long output_len)
> >  * So we work backwards from the end of the decompressed image.
> >  */
> > for (reloc = output + output_len - sizeof(*reloc); *reloc; reloc--) 
> > {
> > -   int extended = *reloc;
> > +   long extended = *reloc;
> > extended += map;
> >
> > ptr = (unsigned long)extended;
> > --
> > 2.5.0
> >
> 
> 
> 
> -- 
> Kees Cook
> Chrome OS & Brillo Security

Re: [PATCH v3 08/19] x86, kaslr: Consolidate mem_avoid array filling

[Baoquan He]

On 03/07/16 at 03:28pm, Kees Cook wrote:
> On Fri, Mar 4, 2016 at 8:25 AM, Baoquan He  wrote:
> > From: Yinghai Lu 
> >
> > We are going to support kaslr with 64bit above 4G, and new random output
> > could be anywhere. Array mem_avoid is used for kaslr to search new output
> > address. Current code only track range that is after output+output_size.
> > So we need to track all ranges instead of just after output+output_size.
> >
> > Current code has first entry which is extra bytes before input+input_size,
> > and it is according to output_size. Other entries are for initrd, cmdline,
> > and heap/stack for ZO running.
> >
> > At first, let's check the first entry that should be in the mem_avoid array.
> > Now ZO sit end of the buffer always, we can find out where is text and
> > data/bss etc of ZO.
> >
> > Since init_size >= run_size, and input+input_len >= output+output_len,
> > here make several assumptions for better presentation by graph:
> >  - init_size > run_size
> >  - input+input_len > output+output_len
> >  - run_size > output_len
> 
> I would like to see each of these assumptions justified. Why is
> init_size > run_size, etc?
> choose_kernel_location's "output_size" is calculated as max(run_size,
> output_len), so run_size may not be > output_len...

Sure. I will add this case in next post. Thanks a lot.
> 
> >
> > 0   output   input input+input_len  
> > output+init_size
> > | ||   |
> >|
> > |-|---||--|||--|
> >   |   | |
> >  output+init_size-ZO_INIT_SIZEoutput+output_len
> > output+run_size
> >
> > [output, output+init_size) is the for decompressing buffer for compressed
> > kernel.
> >
> > [output, output+run_size) is for VO run size.
> > [output, output+output_len) is (VO (vmlinux after objcopy) plus relocs)
> >
> > [output+init_size-ZO_INIT_SIZE, output+init_size) is copied ZO.
> > [input, input+input_len) is copied compressed (VO (vmlinux after objcopy)
> > plus relocs), not the ZO.
> >
> > [input+input_len, output+init_size) is [_text, _end) for ZO. that could be
> > first range in mem_avoid. Now the new first entry already includes heap and
> > stack for ZO running. So no need to put them separately into mem_avoid 
> > array.
> >
> > Also [input, input+input_size) need be put in mem_avoid array. It is 
> > adjacent
> > to new first entry, so merge them.
> 
> I wonder if this diagram and description should live in a comment with the 
> code.

I think it would be very helpful for people interested in this process.
Do you think it's ok to put it where init_size is calculated in
boot/header.S?  Or other suitable places?
> 
> 
> >
> > At last we need to put boot_params into the mem_avoid too. As with 64bit
> > bootloader could put it anywhere.
> >
> > After these changes, we have all ranges which need be avoided in mem_avoid
> > array.
> >
> > Cc: Kees Cook 
> > Signed-off-by: Yinghai Lu 
> > ---
> > v2->v3:
> > Adjust the patch log.
> >
> >  arch/x86/boot/compressed/aslr.c | 29 +
> >  1 file changed, 13 insertions(+), 16 deletions(-)
> >
> > diff --git a/arch/x86/boot/compressed/aslr.c 
> > b/arch/x86/boot/compressed/aslr.c
> > index 622aa88..b93be03 100644
> > --- a/arch/x86/boot/compressed/aslr.c
> > +++ b/arch/x86/boot/compressed/aslr.c
> > @@ -109,7 +109,7 @@ struct mem_vector {
> > unsigned long size;
> >  };
> >
> > -#define MEM_AVOID_MAX 5
> > +#define MEM_AVOID_MAX 4
> >  static struct mem_vector mem_avoid[MEM_AVOID_MAX];
> >
> >  static bool mem_contains(struct mem_vector *region, struct mem_vector 
> > *item)
> > @@ -135,21 +135,22 @@ static bool mem_overlaps(struct mem_vector *one, 
> > struct mem_vector *two)
> >  }
> >
> >  static void mem_avoid_init(unsigned long input, unsigned long input_size,
> > -  unsigned long output, unsigned long output_size)
> > +  unsigned long output)
> >  {
> > +   unsigned long init_size = real_mode->hdr.init_size;
> > u64 initrd_start, initrd_size;
> > u64 cmd_line, cmd_line_size;
> > -   unsigned long unsafe, unsafe_len;
> > char *ptr;
> >
> > /*
> >  * Avoid the region that is unsafe to overlap during
> > -* decompression (see calculations at top of misc.c).
> > +* decompression.
> > +* As we already move ZO (arch/x86/boot/compressed/vmlinux)
> > +* to the end of buffer, [input+input_size, output+init_size)
> > +* has [_text, _end) for ZO.
> >  */
> > -   unsafe_len = (output_size >> 12) + 32768 + 18;
> > -   unsafe = (unsigned long)input + input_size - unsafe_len;
> > -   mem_avoid[0].start = unsafe;
> > -   mem_avoid[0].size = unsafe_len;
> > +   mem_avoid[0].start = input;
> > 

Thoughts on tightening up user namespace creation

[Andy Lutomirski]

Hi all-

There are several users and distros that are nervous about user
namespaces from an attack surface point of view.

 - RHEL and Arch have userns disabled.

 - Ubuntu requires CAP_SYS_ADMIN

 - Kees periodically proposes to upstream some sysctl to control
userns creation.

I think there are three main types of concerns.  First, there might be
some as-yet-unknown semantic issues that would allow privilege
escalation by users who create user namespaces and then confuse
something else in the system.  Second, enabling user namespaces
exposes a lot of attack surface to unprivileged users.  Third,
allowing tasks to create user namespaces exposes the kernel to various
resource exhaustion attacks that wouldn't be possible otherwise.

Since I doubt we'll ever fully address the attack surface issue at
least, would it make sense to try to come up with an upstreamable way
to limit who can create new user namespaces and/or do various
dangerous things with them?

I'll divide the rest of the email into the "what" and the "who".

+++ What does the privilege of creating a user namespace entail? +++

This could be an all-or-nothing thing.  It would certainly be possible
for appropriately privileged tasks to be able to unshare namespaces
and use their facilities exactly like any task can in a current
user-ns-enabled kernel and for other tasks to be unable to unshare
anything.

Finer gradations are, in principle, possible.  For example, it could
be possible for a given task to unshare its userns but to have limited
caps inside or to be unable to unshare certain other namespaces.  For
example, maybe a task could unshare userns and mount ns but not net
ns.  I don't think this would be particularly useful.

It might be more interesting to allow a task to unshare all
namespaces, hold all capabilities in them, but to still be unable to
use certain privileged facilities.  For example, maybe denying
administrative control over iptables, creation of exotic network
interface types, or similar would make sense.  I don't know how we'd
specify this type of constraint.

+++ Who can create user namespaces (possibly with restrictions)? +++

I can think of a few formulations.

A simpler approach would be to add a per-namespace setting listing
users and/or groups that can unshare their userns.  A userns starts
out allowing everyone to unshare userns, and anyone with CAP_SYS_ADMIN
can change the setting.

A fancier approach would be to have an fd that represents the right to
unshare your userns.  Some privilege broker could give out those fds
to apps that need them and meet whatever criteria are set.  If you try
to unshare your userns without the fd, it falls back to some simpler
policy.

I think I prefer the simpler one.  It's simple, and I haven't come up
with a concrete problem with it yet.




Thoughts?

Re: [PATCH v3 07/19] x86, kaslr: Get correct max_addr for relocs pointer

[Baoquan He]

On 03/07/16 at 03:16pm, Kees Cook wrote:
> On Fri, Mar 4, 2016 at 8:25 AM, Baoquan He  wrote:
> > From: Yinghai Lu 
> >
> > There is boundary checking for pointer in kaslr relocation handling.
> >
> > Current code is using output_len, and that is VO (vmlinux after objcopy)
> > file size plus vmlinux.relocs file size.
> >
> > That is not right, as we should use loaded address for running.
> 
> I think this needs clarification. If I'm understanding correctly, the
> max_addr check should stop at the end of VO, and not include bss, brk,
> etc. which follows. In which case, this change is correct: the bounds
> checking needed to be tightened.

Yes, exactly as you means.

> 
> 
> >
> > At that time parse_elf already move the sections according to ELF headers.
> >
> > The valid range should be VO [_text, __bss_start) loaded physical addresses.

I think it is expressed here. Maybe we can stress it in this patch log.
After all it's the main idea of this patch.

How about rewriting patch log like this: 


There is boundary checking for pointer in kaslr relocation handling.
However current code is using output_len that is VO (vmlinux after objcopy)
file size plus vmlinux.relocs file size to make the valid boundary.

That is not right since the max_addr check should stop at the end of VO
and excludes bss, brk etc, which follows. Means the valid range should
be VO [_text, __bss_start] in loaded physical address space.

In this patch, add export for __bss_start to voffset.h and use it to get
max_addr.


> >
> > In the patch, add export for __bss_start to voffset.h and use it to get
> > max_addr.
> >
> > Signed-off-by: Yinghai Lu 
> > ---
> > v2->v3:
> > Tune the patch log.
> >
> >  arch/x86/boot/compressed/Makefile | 2 +-
> >  arch/x86/boot/compressed/misc.c   | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/x86/boot/compressed/Makefile 
> > b/arch/x86/boot/compressed/Makefile
> > index fef80fa..2e7c0ce 100644
> > --- a/arch/x86/boot/compressed/Makefile
> > +++ b/arch/x86/boot/compressed/Makefile
> > @@ -41,7 +41,7 @@ LDFLAGS_vmlinux := -T
> >  hostprogs-y:= mkpiggy
> >  HOST_EXTRACFLAGS += -I$(srctree)/tools/include
> >
> > -sed-voffset := -e 's/^\([0-9a-fA-F]*\) [ABCDGRSTVW] 
> > \(_text\|_end\)$$/\#define VO_\2 _AC(0x\1,UL)/p'
> > +sed-voffset := -e 's/^\([0-9a-fA-F]*\) [ABCDGRSTVW] 
> > \(_text\|__bss_start\|_end\)$$/\#define VO_\2 _AC(0x\1,UL)/p'
> >
> >  quiet_cmd_voffset = VOFFSET $@
> >cmd_voffset = $(NM) $< | sed -n $(sed-voffset) > $@
> > diff --git a/arch/x86/boot/compressed/misc.c 
> > b/arch/x86/boot/compressed/misc.c
> > index 069120e..dd7ed8a 100644
> > --- a/arch/x86/boot/compressed/misc.c
> > +++ b/arch/x86/boot/compressed/misc.c
> > @@ -259,7 +259,7 @@ static void handle_relocations(void *output, unsigned 
> > long output_len)
> > int *reloc;
> > unsigned long delta, map, ptr;
> > unsigned long min_addr = (unsigned long)output;
> > -   unsigned long max_addr = min_addr + output_len;
> > +   unsigned long max_addr = min_addr + (VO___bss_start - VO__text);
> >
> > /*
> >  * Calculate the delta between where vmlinux was linked to load
> > --
> > 2.5.0
> >
> 
> 
> 
> -- 
> Kees Cook
> Chrome OS & Brillo Security

Re: [PATCH v1] tools/vm/page-types.c: remove memset() in walk_pfn()

[Konstantin Khlebnikov]

On Tue, Mar 8, 2016 at 4:47 AM, Naoya Horiguchi
 wrote:
> I found that page-types is very slow and my testing shows many timeout errors.
> Here's an example with a simple program allocating 1000 thps.
>
>   $ time ./page-types -p $(pgrep -f test_alloc)
>   ...
>   real0m17.201s
>   user0m16.889s
>   sys 0m0.312s
>
>   $ time ./page-types.patched -p $(pgrep -f test_alloc)
>   ...
>   real0m0.182s
>   user0m0.046s
>   sys 0m0.135s
>
> Most of time is spent in memset(), which isn't necessary because we check
> that the return of kpagecgroup_read() is equal to pages and uninitialized
> memory is never used. So we can drop this memset().

These zeros are used in show_page_range() - for merging pages into ranges.

You could add fast-path for count=1

@@ -633,7 +633,10 @@ static void walk_pfn(unsigned long voffset,
unsigned long pages;
unsigned long i;

-   memset(cgi, 0, sizeof cgi);
+   if (count == 1)
+   cgi[0] = 0;
+   else
+   memset(cgi, 0, sizeof cgi);

while (count) {
batch = min_t(unsigned long, count, KPAGEFLAGS_BATCH);


>
> Fixes: 954e95584579 ("tools/vm/page-types.c: add memory cgroup dumping and 
> filtering")
> Signed-off-by: Naoya Horiguchi 
> ---
>  tools/vm/page-types.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git v4.5-rc5-mmotm-2016-02-24-16-18/tools/vm/page-types.c 
> v4.5-rc5-mmotm-2016-02-24-16-18_patched/tools/vm/page-types.c
> index dab61c3..c192baf 100644
> --- v4.5-rc5-mmotm-2016-02-24-16-18/tools/vm/page-types.c
> +++ v4.5-rc5-mmotm-2016-02-24-16-18_patched/tools/vm/page-types.c
> @@ -633,8 +633,6 @@ static void walk_pfn(unsigned long voffset,
> unsigned long pages;
> unsigned long i;
>
> -   memset(cgi, 0, sizeof cgi);
> -
> while (count) {
> batch = min_t(unsigned long, count, KPAGEFLAGS_BATCH);
> pages = kpageflags_read(buf, index, batch);
> --
> 2.7.0
>

Re: [PATCH V14 8/9] vfio, platform: add support for ACPI while detecting the reset driver

[Sinan Kaya]

On 3/7/2016 11:46 PM, Eric Auger wrote:
>> #define module_vfio_reset_handler(compat, acpihid, reset) \
>> > MODULE_ALIAS("vfio-reset: dt: " compat); \
>> > MODULE_ALIAS("vfio-reset: acpi: " acpihid); \
> My gut feeling is we must not create a dummy alias when the mode
> (dt/acpi) is not supported/tested. It fills the modinfo section with
> spurious data, aliases are visible to modinfo, ...
> 
> So I personally foresee 2 solutions,
> 1) we create a single alias using acpihid if supported or compat if not.
> Then even in dt mode we try to load this module through the acpihid
> alias. Looks weird but should work.
> 2) We simply move the module alias declaration out of this macro (to the
> reset module itself), define 2 aliases in case both dt and acpi are
> supported & tested.
> 
> My personal preference is 2 I think.
> 
> Best Regards
> 
> Eric
> 

I agree with your assessment of #2. We are trying to be too smart. 
I'll post a patch with #2 solution.

-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

Re: [PATCH v14 2/6] Documentation, dt, numa: dt bindings for NUMA.

[Ganapatrao Kulkarni]

On Tue, Mar 8, 2016 at 1:17 AM, David Daney  wrote:
> On 03/07/2016 11:22 AM, Robert Richter wrote:
>>
>> On 03.03.16 15:55:35, David Daney wrote:
>>>
>>> From: Ganapatrao Kulkarni 
>>>
>>> Add DT bindings for numa mapping of memory, CPUs and IOs.
>>>
>>> Reviewed-by: Robert Richter 
>>> Signed-off-by: Ganapatrao Kulkarni 
>>> Signed-off-by: David Daney 
>>> ---
>>>   Documentation/devicetree/bindings/numa.txt | 272
>>> +
>>>   1 file changed, 272 insertions(+)
>>>   create mode 100644 Documentation/devicetree/bindings/numa.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/numa.txt
>>> b/Documentation/devicetree/bindings/numa.txt
>>> new file mode 100644
>>> index 000..ec5ed7c
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/numa.txt
>>
>>
>>>
>>> +==
>>> +3 - distance-map
>>>
>>> +==
>>> +
>>> +The device tree node distance-map describes the relative
>>> +distance (memory latency) between all numa nodes.
>>> +
>>> +- compatible : Should at least contain "numa-distance-map-v1".
>>> +
>>> +- distance-matrix
>>> +  This property defines a matrix to describe the relative distances
>>> +  between all numa nodes.
>>> +  It is represented as a list of node pairs and their relative distance.
>>> +
>>> +  Note:
>>> +   1. Each entry represents distance from first node to second node.
>>> +   The distances are equal in either direction.
>>> +   2. The distance from a node to self (local distance) is
>>> represented
>>> +   with value 10 and all internode distance should be represented
>>> with
>>> +   a value greater than 10.
>>> +   3. distance-matrix should have entries in lexicographical
>>> ascending
>>> +   order of nodes.
>>> +   4. There must be only one device node distance-map which must
>>> reside in the root node.
>>
>>
>> There is no note that this one is optional, but is it right? The
>> default is 10 for local and 20 for remote connections.
>>
>
> Do we need to explicitly state that it is optional?  Many node types are
> optional, and their binding specifications don't really talk about their
> being optional.
>
> If the node is present then it has the meaning specified.
>
> If the node is *not* present, then the special meaning described in the
> bindings document does not apply.
>
> In the case of NUMA, this means that all memory is equally distant (i.e. it
> is *Uniform*), and we are not talking about a *Non* *Uniform* Memory
> Architecture (NUMA) system.
>
>
>> If so, then ...
>>
>> static int __init of_numa_parse_distance_map(void)
>> {
>> int ret = -EINVAL;
>> struct device_node *np = of_find_node_by_path("/distance-map");
>>
>> if (!np)
>> return ret;
>>
>> must return 0 instead of -EINVAL here.
>
>
> No, I don't think doing that would be correct.
>
> If there is no "distance-map", then of_numa_init() returns the error code.
> This causes the code in arch/arm64/kernel/numa.c to fall back to the
> non-NUMA "dummy_numa" case.

IMO, return 0 will allow 2 node system to have distance-map optional.
by default node distance is set to 10 for local node and for remote node is 20
and this will suffice the need of 2 node system.
by returning EINVAL, we are forcing 2 node system (and even for
systems which has equal remote distances)
to define distance-map.

>
> By adding your Reviewed-by: Robert Richter  tag to
> patch 5/6, where we select between "real" and "dummy_numa", I had assumed
> that you agreed with this approach.
>
> David Daney

Ganapat
>
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 06/19] x86, kaslr: Clean up useless code related to run_size.

[Baoquan He]

On 03/07/16 at 03:12pm, Kees Cook wrote:
> > diff --git a/arch/x86/boot/compressed/misc.c 
> > b/arch/x86/boot/compressed/misc.c
> > index 42e76c2..069120e 100644
> > --- a/arch/x86/boot/compressed/misc.c
> > +++ b/arch/x86/boot/compressed/misc.c
> > @@ -393,9 +393,9 @@ asmlinkage __visible void *decompress_kernel(void 
> > *rmode, memptr heap,
> >   unsigned char *input_data,
> >   unsigned long input_len,
> >   unsigned char *output,
> > - unsigned long output_len,
> > - unsigned long run_size)
> > + unsigned long output_len)
> >  {
> > +   unsigned long run_size = VO__end - VO__text;
> 
> I think this can be "const" now, yes?

Yes, agree. No one can change it.
Will update it. 

Thanks

> 
> > unsigned char *output_orig = output;
> >
> > real_mode = rmode;
> > @@ -416,8 +416,6 @@ asmlinkage __visible void *decompress_kernel(void 
> > *rmode, memptr heap,
> > lines = real_mode->screen_info.orig_video_lines;
> > cols = real_mode->screen_info.orig_video_cols;
> >
> > -   run_size = VO__end - VO__text;
> > -
> > console_init();
> > debug_putstr("early console in decompress_kernel\n");
> >
> > diff --git a/arch/x86/boot/compressed/mkpiggy.c 
> > b/arch/x86/boot/compressed/mkpiggy.c
> > index a613c84..c5148642 100644
> > --- a/arch/x86/boot/compressed/mkpiggy.c
> > +++ b/arch/x86/boot/compressed/mkpiggy.c
> > @@ -34,13 +34,11 @@ int main(int argc, char *argv[])
> >  {
> > uint32_t olen;
> > long ilen;
> > -   unsigned long run_size;
> > FILE *f = NULL;
> > int retval = 1;
> >
> > -   if (argc < 3) {
> > -   fprintf(stderr, "Usage: %s compressed_file run_size\n",
> > -   argv[0]);
> > +   if (argc < 2) {
> > +   fprintf(stderr, "Usage: %s compressed_file\n", argv[0]);
> > goto bail;
> > }
> >
> > @@ -65,15 +63,11 @@ int main(int argc, char *argv[])
> > ilen = ftell(f);
> > olen = get_unaligned_le32(&olen);
> >
> > -   run_size = atoi(argv[2]);
> > -
> > printf(".section \".rodata..compressed\",\"a\",@progbits\n");
> > printf(".globl z_input_len\n");
> > printf("z_input_len = %lu\n", ilen);
> > printf(".globl z_output_len\n");
> > printf("z_output_len = %lu\n", (unsigned long)olen);
> > -   printf(".globl z_run_size\n");
> > -   printf("z_run_size = %lu\n", run_size);
> >
> > printf(".globl input_data, input_data_end\n");
> > printf("input_data:\n");
> > diff --git a/arch/x86/tools/calc_run_size.sh 
> > b/arch/x86/tools/calc_run_size.sh
> > deleted file mode 100644
> > index 1a4c17b..000
> > --- a/arch/x86/tools/calc_run_size.sh
> > +++ /dev/null
> > @@ -1,42 +0,0 @@
> > -#!/bin/sh
> > -#
> > -# Calculate the amount of space needed to run the kernel, including room 
> > for
> > -# the .bss and .brk sections.
> > -#
> > -# Usage:
> > -# objdump -h a.out | sh calc_run_size.sh
> > -
> > -NUM='\([0-9a-fA-F]*[ \t]*\)'
> > -OUT=$(sed -n 's/^[ \t0-9]*.b[sr][sk][ \t]*'"$NUM$NUM$NUM$NUM"'.*/\1\4/p')
> > -if [ -z "$OUT" ] ; then
> > -   echo "Never found .bss or .brk file offset" >&2
> > -   exit 1
> > -fi
> > -
> > -OUT=$(echo ${OUT# })
> > -sizeA=$(printf "%d" 0x${OUT%% *})
> > -OUT=${OUT#* }
> > -offsetA=$(printf "%d" 0x${OUT%% *})
> > -OUT=${OUT#* }
> > -sizeB=$(printf "%d" 0x${OUT%% *})
> > -OUT=${OUT#* }
> > -offsetB=$(printf "%d" 0x${OUT%% *})
> > -
> > -run_size=$(( $offsetA + $sizeA + $sizeB ))
> > -
> > -# BFD linker shows the same file offset in ELF.
> > -if [ "$offsetA" -ne "$offsetB" ] ; then
> > -   # Gold linker shows them as consecutive.
> > -   endB=$(( $offsetB + $sizeB ))
> > -   if [ "$endB" != "$run_size" ] ; then
> > -   printf "sizeA: 0x%x\n" $sizeA >&2
> > -   printf "offsetA: 0x%x\n" $offsetA >&2
> > -   printf "sizeB: 0x%x\n" $sizeB >&2
> > -   printf "offsetB: 0x%x\n" $offsetB >&2
> > -   echo ".bss and .brk are non-contiguous" >&2
> > -   exit 1
> > -   fi
> > -fi
> > -
> > -printf "%d\n" $run_size
> > -exit 0
> > --
> > 2.5.0
> >
> 
> 
> 
> -- 
> Kees Cook
> Chrome OS & Brillo Security

Re: [PATCH] devpts: Add ptmx_uid and ptmx_gid options

[Andy Lutomirski]

On Thu, May 28, 2015 at 12:42 PM, Eric W. Biederman
 wrote:
> Andy Lutomirski  writes:
>
>> On Thu, May 28, 2015 at 10:01 AM, Alexander Larsson  wrote:
>>> On Thu, 2015-05-28 at 11:44 -0500, Eric W. Biederman wrote:
 Andy Lutomirski  writes:

 > On Thu, Apr 2, 2015 at 11:27 AM, Eric W. Biederman
 >  wrote:
 > > Andy Lutomirski  writes:
 > >
 > > > On Thu, Apr 2, 2015 at 7:29 AM, Alexander Larsson <
 > > > al...@redhat.com> wrote:
 > > > > On Thu, 2015-04-02 at 07:06 -0700, Andy Lutomirski wrote:
 > > > > > On Thu, Apr 2, 2015 at 3:12 AM, James Bottomley
 > > > > >  wrote:
 > > > > > > On Tue, 2015-03-31 at 16:17 +0200, Alexander Larsson
 > > > > > > wrote:
 > > > > > > > On tis, 2015-03-31 at 17:08 +0300, James Bottomley
 > > > > > > > wrote:
 > > > > > > > > On Tue, 2015-03-31 at 06:59 -0700, Andy Lutomirski
 > > > > > > > > wrote:
 > > > > > > > > >
 > > > > > > > > > I don't think that this is correct.  That user can
 > > > > > > > > > already create a
 > > > > > > > > > nested userns and map themselves as 0 inside it.
 > > > > > > > > >  Then they can mount
 > > > > > > > > > devpts.
 > > > > > > > >
 > > > > > > > > I don't mind if they create a container and control
 > > > > > > > > the isolated ttys in
 > > > > > > > > that sub container in the VPS; that's fine.  I do
 > > > > > > > > mind if they get
 > > > > > > > > access to the ttys in the VPS.
 > > > > > > > >
 > > > > > > > > If you can convince me (and the rest of Linux) that
 > > > > > > > > the tty subsystem
 > > > > > > > > should be mountable by an unprivileged user
 > > > > > > > > generally, then what you
 > > > > > > > > propose is OK.
 > > > > > > >
 > > > > > > > That is controlled by the general rights to mount
 > > > > > > > stuff. I.e. unless you
 > > > > > > > have CAP_SYS_ADMIN in the VPS container you will not be
 > > > > > > > able to mount
 > > > > > > > devpts there. You can only do it in a subcontainer
 > > > > > > > where you got
 > > > > > > > permissions to mount via using user namespaces.
 > > > > > >
 > > > > > > OK let me try again.  Fine, if you want to speak
 > > > > > > capabilities, you've
 > > > > > > given a non-root user an unexpected capability (the
 > > > > > > capability of
 > > > > > > creating a ptmx device).  But you haven't used a
 > > > > > > capability separation
 > > > > > > to do this, you've just hard coded it via a mount
 > > > > > > parameter mechanism.
 > > > > > >
 > > > > > > If you want to do this thing, do it properly, so it's
 > > > > > > acceptable to the
 > > > > > > whole of Linux, not a special corner case for one
 > > > > > > particular type of
 > > > > > > container.
 > > > > > >
 > > > > > > Security breaches are created when people code in
 > > > > > > special, little used,
 > > > > > > corner cases because they don't get as thoroughly tested
 > > > > > > and inspected
 > > > > > > as generally applicable mechanisms.
 > > > > > >
 > > > > > > What you want is to be able to use the tty subsystem as a
 > > > > > > non root user:
 > > > > > > fine, but set that up globally, don't hide it in
 > > > > > > containers so a lot
 > > > > > > fewer people care.
 > > > > >
 > > > > > I tend to agree, and not just for the tty subsystem.  This
 > > > > > is an
 > > > > > attack surface issue.  With unprivileged user namespaces,
 > > > > > unprivileged
 > > > > > users can create mount namespaces (probably a good thing
 > > > > > for bind
 > > > > > mounts, etc), network namespaces (reasonably safe by
 > > > > > themselves),
 > > > > > network interfaces and iptables rules (scary), fresh
 > > > > > instances/superblocks of some filesystems (scariness
 > > > > > depends on the fs
 > > > > > -- tmpfs is probably fine), and more.
 > > > > >
 > > > > > I think we should have real controls for this, and this is
 > > > > > mostly
 > > > > > Eric's domain.  Eric?  A silly issue that sometimes
 > > > > > prevents devpts
 > > > > > from being mountable isn't a real control, though.
 > >
 > > I thought the controls for limiting how much of the userspace API
 > > an application could use were called seccomp and seccomp2.
 > >
 > > Do we need something like a PAM module so that we can set up
 > > these
 > > controls during login?
 > >
 > > > > I'm honestly surprised that non-root is allowed to mount
 > > > > things in
 > > > > general with user namespaces. This was long disabled use for
 > > > > non-root in
 > > > > Fedora, but it is now enabled.
 > > > >
 > > > > For instance, using loopback mounted files you could probably
 > > > > attack
 > > > > some of the less well tested filesystem impl

Re: [PATCH v3 05/19] x86, boot: Fix run_size calculation

[Baoquan He]

On 03/07/16 at 03:10pm, Kees Cook wrote:
> On Fri, Mar 4, 2016 at 8:25 AM, Baoquan He  wrote:
> > From: Yinghai Lu 
> >
> > Firstly, current run_size is calculated via shell script
> > arch/x86/tools/calc_run_size.sh. It gets file offset and mem size of section
> > .bss and .brk in vmlinux, then add them as follows:
> >
> > run_size=$(( $offsetA + $sizeA + $sizeB ))
> >
> > However this is completely wrong. The offset is the starting address of
> > section or segment in elf file. Below is a vmlinux I compiled:
> >
> > [bhe@x1 linux]$ objdump -h vmlinux
> >
> > vmlinux: file format elf64-x86-64
> >
> > Sections:
> > Idx Name  Size  VMA   LMA   File off  
> > Algn
> >  27 .bss  0017  81ec8000  01ec8000  012c8000  
> > 2**12
> >   ALLOC
> >  28 .brk  00027000  82038000  02038000  012c8000  
> > 2**0
> >   ALLOC
> >
> > Here we can get run_size is 0x145f000.
> > 0x012c8000+0x012c8000+0x00027000=0x145f000
> 
> This example calculation looks wrong to me. run_size is offset + size
> + size (not offset + offset + size):
> 
> 0x12c8000+0x17000+0x27000 = 0x1306000

Yeah, please forgive my carelessness. I copied the wrong size of .bss.
But you also typied the wrong value of .bss size, it should be 0x17.
So the result is still right.

0x12c8000+0x17+0x27000 = 0x145f000

> 
> > [bhe@x1 linux]$ readelf -l vmlinux
> >
> > Elf file type is EXEC (Executable file)
> > Entry point 0x100
> > There are 5 program headers, starting at offset 64
> >
> > Program Headers:
> >   Type   Offset VirtAddr   PhysAddr
> >  FileSizMemSiz  Flags  Align
> >   LOAD   0x0020 0x8100 0x0100
> >  0x00b5e000 0x00b5e000  R E20
> >   LOAD   0x00e0 0x81c0 0x01c0
> >  0x00145000 0x00145000  RW 20
> >   LOAD   0x0100 0x 0x01d45000
> >  0x00018158 0x00018158  RW 20
> >   LOAD   0x0115e000 0x81d5e000 0x01d5e000
> >  0x0016a000 0x00301000  RWE20
> >   NOTE   0x0099bcac 0x8179bcac 0x0179bcac
> >  0x01bc 0x01bc 4
> >
> >  Section to Segment mapping:
> >   Segment Sections...
> >00 .text .notes __ex_table .rodata __bug_table .pci_fixup .tracedata 
> > __ksymtab __ksymtab_gpl __ksymtab_strings __init_rodata __param __modver
> >01 .data .vvar
> >02 .data..percpu
> >03 .init.text .init.data .x86_cpu_dev.init .parainstructions 
> > .altinstructions .altinstr_replacement .iommu_table .apicdrivers .exit.text 
> > .smp_locks .bss .brk
> >04 .notes
> >
> > Here we can get the same value as current run_size if we add p_offset
> > and p_memsz.
> > 0x0115e000+0x00301000=0x145f000
> >
> > But is it right? Obviously not. We should calculate it using the last LOAD
> > program segment like this:
> > run_size = phdr->p_paddr + phdr->p_memsz - physical load addr of kernel
> > run_size=0x01d5e000+0x00301000-0x0100=0x105f000
> 
> Segment 03 ends at 0x81d5e000 + 0x301000 = 0x8205f000,
> which does match where .brk ends (0x82038000 + 0x27000 =
> 0x8205f000).

Ah, yes, exactly. They prove it in different way.

> 
> >
> > It's equal to VO_end-VO_text and certainly it's simpler to do.
> > _end: 0x8205f000
> > _text:0x8100
> > run_size = 0x8205f000-0x8100=0x105f000
> 
> I would agree, it would seem like the existing run_size calculation is
> 0x247000 too high in this example.

It should be 0x40 high as you mistakenly input the size of .bss ^_^.
0x145f000 - 0x105f000 = 0x40

Extra 4M is added in this example.

Thanks
Baoquan

Re: Kernel docs: muddying the waters a bit

[Russel Winder]

On Fri, 2016-03-04 at 09:46 +0200, Jani Nikula wrote:
> […]
> If we're talking about the same asciidoctor (http://asciidoctor.org/)
> it's written in ruby but you can apparently run it in JVM using
> JRuby. Calling it Java-based is misleading.

Indeed, I was somewhat imprecise. Thanks to the work mostly of Charles
Nutter, JRuby is invariably a faster platform for Ruby code than Ruby
is. So yes ASCIIDoctor is JVM-based via JRuby, not Java-based.

The real point here is that in a move from DocBook/XML as a
documentation source, ASCIIDoctor is an excellent choice.

-- 
Russel.=Dr
 Russel Winder  t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net41 
Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.ukLondon SW11 
1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: [PATCH] mfd: act8945a: fix platform_no_drv_owner.cocci warnings

[Lee Jones]

On Tue, 08 Mar 2016, Yang, Wenyou wrote:

> Hi Fengguang Wu,
> 
> Thank you for your patch.
> 
> > -Original Message-
> > From: kbuild test robot [mailto:l...@intel.com]
> > Sent: 2016年3月8日 7:54
> > To: Yang, Wenyou 
> > Cc: kbuild-...@01.org; Lee Jones ; Rob Herring
> > ; Pawel Moll ; Mark Rutland
> > ; Ian Campbell ; Kumar
> > Gala ; Ferre, Nicolas ;
> > linux-kernel@vger.kernel.org; devicet...@vger.kernel.org; Yang, Wenyou
> > 
> > Subject: [PATCH] mfd: act8945a: fix platform_no_drv_owner.cocci warnings
> > 
> > drivers/mfd/act8945a.c:100:6-11: No need to set .owner here. The core will 
> > do it.
> > 
> >  Remove .owner field if calls are used which set it automatically
> > 
> > Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
> > 
> > CC: Wenyou Yang 
> > Signed-off-by: Fengguang Wu 
> 
> Reviewed-by: Wenyou Yang 

Please fix this code up into the original patch and resubmit the set.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v3 02/19] x86, boot: Move compressed kernel to end of buffer before decompressing

[Baoquan He]

Hi Kees,

Many thanks for your review and suggestions!

On 03/07/16 at 02:35pm, Kees Cook wrote:
> > Current code uses extract_offset to decide the copied ZO position, it
> > put ZO starting from extract_offset. When INIT_SIZE is bigger than
> > VO_INIT_SIZE copied ZO occupies space from extract_offset to the end
> > of decompressing buffer, just like below.
> >
> > 0   extract_offset   init_size
> > |---|---||-|
> > |   || |
> >   VO__text  startup_32 of ZO VO__end ZO__end
> >
> > However when INIT_SIZE is euqal to VO_INIT_SIZE there's still space left
> 
> typo: "equal"

Yes, will change it in next post.

> 
> > from end of ZO to the end of decompressing buffer, like below.
> >
> > 0   extract_offset   init_size
> > |---|---||-|
> > |   || |
> >   VO__text  startup_32 of ZO ZO__end VO__end
> >
> > It's better to always put ZO right in the end of decompressing buffer.
> > Anyway, who doesn't like it to be better.
> 
> It looks to me like it's just cleaner to always have ZO__end ==
> VO__end? Is that the motivation for moving it? What problem is solved
> with this change?

As you can see there are 2 cases. The first case is depicted in the 1st
graph. In that case ZO__end is after VO__end. In the 2nd case, yes, we
move ZO__end to make that happen ZO__end == VO__end. In fact this patch
is not trying to make them equal, what it is trying to do is adjusting
the behaviour. We always put ZO just in the end by getting init_size
which is the deompressing buffer and ZO_INIT_SIZE, not like before we
just put ZO starting from extract_offset. We change a different way to
get the starting position of ZO.
> 
> -Kees
> 
> >
> > So in this patch add BP_init_size into asm-offsets.c to make it visible
> > to asm modules. And find the starting position of copied ZO by init_size
> > and ZO run size, namely (ZO__end - startup_32) when move ZO.
> >
> > Signed-off-by: Yinghai Lu 
> > ---
> > v2->v3:
> > Adjust the patch log.
> >
> >  arch/x86/boot/compressed/head_32.S | 11 +--
> >  arch/x86/boot/compressed/head_64.S |  8 ++--
> >  arch/x86/boot/compressed/mkpiggy.c |  3 ---
> >  arch/x86/boot/compressed/vmlinux.lds.S |  1 +
> >  arch/x86/kernel/asm-offsets.c  |  1 +
> >  arch/x86/kernel/vmlinux.lds.S  |  1 +
> >  6 files changed, 18 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/x86/boot/compressed/head_32.S 
> > b/arch/x86/boot/compressed/head_32.S
> > index 8ef964d..0c140f9 100644
> > --- a/arch/x86/boot/compressed/head_32.S
> > +++ b/arch/x86/boot/compressed/head_32.S
> > @@ -148,7 +148,9 @@ preferred_addr:
> >  1:
> >
> > /* Target address to relocate to for decompression */
> > -   addl$z_extract_offset, %ebx
> > +   movlBP_init_size(%esi), %eax
> > +   subl$_end, %eax
> > +   addl%eax, %ebx
> >
> > /* Set up the stack */
> > lealboot_stack_end(%ebx), %esp
> > @@ -210,8 +212,13 @@ relocated:
> > /* push arguments for decompress_kernel: */
> > pushl   $z_run_size /* size of kernel with .bss and .brk */
> > pushl   $z_output_len   /* decompressed length, end of relocs */
> > -   lealz_extract_offset_negative(%ebx), %ebp
> > +
> > +   movlBP_init_size(%esi), %eax
> > +   subl$_end, %eax
> > +   movl%ebx, %ebp
> > +   subl%eax, %ebp
> > pushl   %ebp/* output address */
> > +
> > pushl   $z_input_len/* input_len */
> > lealinput_data(%ebx), %eax
> > pushl   %eax/* input_data */
> > diff --git a/arch/x86/boot/compressed/head_64.S 
> > b/arch/x86/boot/compressed/head_64.S
> > index b0c0d16..67dd8d3 100644
> > --- a/arch/x86/boot/compressed/head_64.S
> > +++ b/arch/x86/boot/compressed/head_64.S
> > @@ -102,7 +102,9 @@ ENTRY(startup_32)
> >  1:
> >
> > /* Target address to relocate to for decompression */
> > -   addl$z_extract_offset, %ebx
> > +   movlBP_init_size(%esi), %eax
> > +   subl$_end, %eax
> > +   addl%eax, %ebx
> >
> >  /*
> >   * Prepare for entering 64 bit mode
> > @@ -330,7 +332,9 @@ preferred_addr:
> >  1:
> >
> > /* Target address to relocate to for decompression */
> > -   leaqz_extract_offset(%rbp), %rbx
> > +   movlBP_init_size(%rsi), %ebx
> > +   subl$_end, %ebx
> > +   addq%rbp, %rbx
> >
> > /* Set up the stack */
> > leaqboot_stack_end(%rbx), %rsp
> > diff --git a/arch/x86/boot/compressed/mkpiggy.c 
> > b/arch/x86/boot/compressed/mkpiggy.c
> > index d8222f2..b980046 100644
> > --- a/arch/x86/boot/compressed/mkp

Re: [PATCH v1 1/1] mfd: intel-lpss: save register context on suspend

[Lee Jones]

On Tue, 26 Jan 2016, Andy Shevchenko wrote:

> From: Heikki Krogerus 
> 
> All configurations are lost and the registers will have
> default values when the hardware is suspended and resumed,
> so saving the private register space context on suspend, and
> restoring it on resume.
> 
> Fixes: 4b45efe85263 (mfd: Add support for Intel Sunrisepoint LPSS devices)

I'd say this sumbission is more of a functional extention than a
bug-fix.  No real need for this statement.

> Signed-off-by: Heikki Krogerus 
> Signed-off-by: Mika Westerberg 

Did it really take 2 of you to write this patch?

> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/mfd/intel-lpss.c | 19 ++-
>  1 file changed, 18 insertions(+), 1 deletion(-)

Code looks okay though:
  Acked-by: Lee Jones 

> diff --git a/drivers/mfd/intel-lpss.c b/drivers/mfd/intel-lpss.c
> index 1743788..2a7c6a7 100644
> --- a/drivers/mfd/intel-lpss.c
> +++ b/drivers/mfd/intel-lpss.c
> @@ -34,6 +34,7 @@
>  #define LPSS_DEV_SIZE0x200
>  #define LPSS_PRIV_OFFSET 0x200
>  #define LPSS_PRIV_SIZE   0x100
> +#define LPSS_PRIV_REG_COUNT  (LPSS_PRIV_SIZE / 4)
>  #define LPSS_IDMA64_OFFSET   0x800
>  #define LPSS_IDMA64_SIZE 0x800
>  
> @@ -76,6 +77,7 @@ struct intel_lpss {
>   struct mfd_cell *cell;
>   struct device *dev;
>   void __iomem *priv;
> + u32 priv_ctx[LPSS_PRIV_REG_COUNT];
>   int devid;
>   u32 caps;
>   u32 active_ltr;
> @@ -492,6 +494,16 @@ EXPORT_SYMBOL_GPL(intel_lpss_prepare);
>  
>  int intel_lpss_suspend(struct device *dev)
>  {
> + struct intel_lpss *lpss = dev_get_drvdata(dev);
> + unsigned int i;
> +
> + /* Save device context */
> + for (i = 0; i < LPSS_PRIV_REG_COUNT; i++)
> + lpss->priv_ctx[i] = readl(lpss->priv + i * 4);
> +
> + /* Put the device into reset state */
> + writel(0, lpss->priv + LPSS_PRIV_RESETS);
> +
>   return 0;
>  }
>  EXPORT_SYMBOL_GPL(intel_lpss_suspend);
> @@ -499,8 +511,13 @@ EXPORT_SYMBOL_GPL(intel_lpss_suspend);
>  int intel_lpss_resume(struct device *dev)
>  {
>   struct intel_lpss *lpss = dev_get_drvdata(dev);
> + unsigned int i;
>  
> - intel_lpss_init_dev(lpss);
> + intel_lpss_deassert_reset(lpss);
> +
> + /* Restore device context */
> + for (i = 0; i < LPSS_PRIV_REG_COUNT; i++)
> + writel(lpss->priv_ctx[i], lpss->priv + i * 4);
>  
>   return 0;
>  }

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH V14 8/9] vfio, platform: add support for ACPI while detecting the reset driver

[Eric Auger]

Hi Sinan,
On 03/07/2016 04:30 PM, Sinan Kaya wrote:
> On 3/6/2016 11:09 PM, Eric Auger wrote:
>>> #define module_vfio_reset_handler(compat, acpihid, reset)   \
 MODULE_ALIAS("vfio-reset:" acpihid? acpihid: compat);  
 \

 This way, we'll create an alias with one of the provided strings.  
>> What if you want to use vfio platform driver for HiDMA in dt mode? the
>> HiDma reset module advertises both acpihid and dt compat support but an
>> alias module will be created only for acpihid. Then I think we will not
>> be able to load the reset module in dt mode with existing code.
>>
> 
> Right, it won't work. Now that we know what MODULE_ALIAS does, there is no
> harm in doing this. I think we should do this.
> 
> #define module_vfio_reset_handler(compat, acpihid, reset)  \
> MODULE_ALIAS("vfio-reset:" compat);\
> MODULE_ALIAS("vfio-reset:" acpihid);   \
> 
> If we prefer ACPI over DT, there is no guarantee that somebody can boot DT
> kernel with ACPI kernel compilation option enabled.
> 
> If one of these are null, then the module alias will be "vfio-reset:"
> 
> Of course to make things prettier, we could use "NOT SUPPORTED" as a string
> instead of NULL. then, the module alias will be vfio-reset: NOT SUPPORTED".
> 
> We could go one step further, and do.
> 
> #define module_vfio_reset_handler(compat, acpihid, reset) \
> MODULE_ALIAS("vfio-reset: dt: " compat); \
> MODULE_ALIAS("vfio-reset: acpi: " acpihid); \

My gut feeling is we must not create a dummy alias when the mode
(dt/acpi) is not supported/tested. It fills the modinfo section with
spurious data, aliases are visible to modinfo, ...

So I personally foresee 2 solutions,
1) we create a single alias using acpihid if supported or compat if not.
Then even in dt mode we try to load this module through the acpihid
alias. Looks weird but should work.
2) We simply move the module alias declaration out of this macro (to the
reset module itself), define 2 aliases in case both dt and acpi are
supported & tested.

My personal preference is 2 I think.

Best Regards

Eric

> 
> and change the code below for this too.
> 
> 
>> This could work however with some rework in vfio_platform_common.c. In
>> vfio_platform_get_reset we should try to load the module using the
>> acpihid if the module load using compat alias fails. In the look-up
>> table we can find the acpihid corresponding to the dt compat.
> 
> I was planning to submit this for the next review. Still, I don't want to 
> assume that acpihid is the only working option. Somebody can boot DT kernel.
> 
> diff --git a/drivers/vfio/platform/vfio_platform_common.c 
> b/drivers/vfio/platform/vfio_platform_common.c
> index 42d7545..ba585ad 100644
> --- a/drivers/vfio/platform/vfio_platform_common.c
> +++ b/drivers/vfio/platform/vfio_platform_common.c
> @@ -58,16 +58,30 @@ static vfio_platform_reset_fn_t 
> vfio_platform_lookup_reset(const char *compat,
>   return reset_fn;
>  }
>  
> -static void vfio_platform_get_reset(struct vfio_platform_device *vdev)
> +static int vfio_platform_get_reset(struct vfio_platform_device *vdev)
>  {
> + int rc;
> +
>   vdev->reset = vfio_platform_lookup_reset(vdev->compat, vdev->acpihid,
>&vdev->reset_module);
> - if (!vdev->reset) {
> - request_module("vfio-reset:%s", vdev->compat);
> - vdev->reset = vfio_platform_lookup_reset(vdev->compat,
> -  vdev->acpihid,
> -  &vdev->reset_module);
> - }
> + if (vdev->reset)
> + return 0;
> +
> + if (vdev->acpihid)
> + rc = request_module("vfio-reset:%s", vdev->acpihid);
> +
> + if (rc && vdev->compat)
> + rc = request_module("vfio-reset:%s", vdev->compat);
> +
> + if (rc)
> + return rc;
> +
> + vdev->reset = vfio_platform_lookup_reset(vdev->compat, vdev->acpihid,
> +  &vdev->reset_module);
> + if (vdev->reset)
> + return 0;
> +
> + return -ENODEV;
>  }
>  
>  static void vfio_platform_put_reset(struct vfio_platform_device *vdev)
> @@ -620,7 +634,11 @@ int vfio_platform_probe_common(struct 
> vfio_platform_device *vdev,
>   return ret;
>   }
>  
> - vfio_platform_get_reset(vdev);
> + ret = vfio_platform_get_reset(vdev);
> + if (ret) {
> + iommu_group_put(group);
> + return ret;
> + }
>  
>   mutex_init(&vdev->igate);
>   
> 
> Let me know what you think.
> 
> 

Re: [PATCH] gpio: xgene: Fix kconfig for standby GIPO contoller

[Quan Nguyen]

On Mon, Mar 7, 2016 at 5:47 PM, Matthias Brugger  wrote:
>
>
> On 07/03/16 08:41, Linus Walleij wrote:
>>
>> On Fri, Mar 4, 2016 at 6:42 PM, Matthias Brugger 
>> wrote:
>>
>>> The standby GPIO controller can be used as a interrupt controller.
>>> Select GPIOLIB_IRQCHIP when compiling this driver. Otherwise we get
>>> a compilation error:
>>>
>>> drivers/gpio/gpio-xgene-sb.c: In function 'xgene_gpio_sb_probe':
>>> drivers/gpio/gpio-xgene-sb.c:312:10: error: 'struct gpio_chip' has no
>>> member named 'irqdomain'
>>>priv->gc.irqdomain = priv->irq_domain;
>>>^
>>> scripts/Makefile.build:295: recipe for target
>>> 'drivers/gpio/gpio-xgene-sb.o' failed
>>> make[2]: *** [drivers/gpio/gpio-xgene-sb.o] Error 1
>>>
>>> Apart if compiled as module, we get the following modpost errors:
>>> ERROR: "irq_chip_eoi_parent" [drivers/gpio/gpio-xgene-sb.ko] undefined!
>>> ERROR: "irq_chip_unmask_parent" [drivers/gpio/gpio-xgene-sb.ko]
>>> undefined!
>>> ERROR: "irq_chip_mask_parent" [drivers/gpio/gpio-xgene-sb.ko] undefined!
>>> ERROR: "irq_domain_create_hierarchy" [drivers/gpio/gpio-xgene-sb.ko]
>>> undefined!
>>> ERROR: "gpiochip_get_data" [drivers/gpio/gpio-xgene-sb.ko] undefined!
>>> ERROR: "irq_chip_set_type_parent" [drivers/gpio/gpio-xgene-sb.ko]
>>> undefined!
>>> ERROR: "irq_domain_alloc_irqs_parent" [drivers/gpio/gpio-xgene-sb.ko]
>>> undefined!
>>> ERROR: "irq_domain_set_hwirq_and_chip" [drivers/gpio/gpio-xgene-sb.ko]
>>> undefined!
>>> ERROR: "irq_domain_reset_irq_data" [drivers/gpio/gpio-xgene-sb.ko]
>>> undefined!
>>>
>>> This patch changes the kconfig so that the gpio controller can only be
>>> build-in and selects GPIOLIB_IRQCHIP.
>>>
>>> Fixes: 1013fc41 "gpio: xgene: Enable X-Gene standby GPIO as interrupt
>>> controller"
>>> Cc: Quan Nguyen 
>>> Signed-off-by: Matthias Brugger 
>>> ---
>>>
>>> Changes for v2:
>>> - Add modprobe fix, changing tristate to bool
>>> - Add Cc tag
>>
>>
>> Quan has sent a patch exporting the offending functions, but no reply from
>> the irqchip maintainers yet.
>>
>> If they don't react we'll have to merge this and handle the module loading
>> later.
>>
>
> Thanks for the info.
>
> Just as a heads up, this patch fix two problems. Apart from the missing
> exports for the irqchip functions, it selects GPIOLIB_IRQCHIP as otherwise
> the config may be broken.
>
> Actually v1 of this patch just fixes this:
> https://patchwork.kernel.org/patch/8502401/

Hi Matthias,
I have acked your v1 as it helps fixing compile error if
CONFIG_GPIOLIB_IRQCHIP missing.
I also agreed with Linus on your v2.
Hence, I only acked the v2 patch if my patch
(https://lkml.org/lkml/2016/3/3/497) missed the merge windows as this
drivers can actually work as a module.

>
> Regards,
> Matthias

Re: [PATCH v2 7/7] mfd: intel_vuport: Add Intel virtual USB port MFD Driver

[Lee Jones]

On Mon, 07 Mar 2016, Lu Baolu wrote:

> Some Intel platforms have an USB port mux controlled by GPIOs.
> There's a single ACPI platform device that provides both USB ID
> extcon device and a USB port mux device. This MFD driver will
> split the 2 devices for their respective drivers.
> 
> Signed-off-by: Lu Baolu 
> Suggested-by: David Cohen 
> Reviewed-by: Felipe Balbi 
> Signed-off-by: Fengguang Wu 
> ---
>  MAINTAINERS|  1 +
>  drivers/mfd/Kconfig|  8 +
>  drivers/mfd/Makefile   |  1 +
>  drivers/mfd/intel-vuport.c | 78 
> ++
>  4 files changed, 88 insertions(+)
>  create mode 100644 drivers/mfd/intel-vuport.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 399cefe..1671a4d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11408,6 +11408,7 @@ F:drivers/usb/mux/intel-mux.c
>  F:   include/linux/usb/intel-mux.h
>  F:   drivers/usb/mux/intel-mux-gpio.c
>  F:   drivers/usb/mux/intel-mux-drcfg.c
> +F:   drivers/mfd/intel-vuport.c

Separate patch please.

>  USB PRINTER DRIVER (usblp)
>  M:   Pete Zaitcev 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 9ca66de..8dd1bf3 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1534,5 +1534,13 @@ config MFD_VEXPRESS_SYSREG
> System Registers are the platform configuration block
> on the ARM Ltd. Versatile Express board.
>  
> +config MFD_INTEL_VUPORT
> + tristate "Intel virtual USB port controller"
> + select MFD_CORE
> + depends on X86 && ACPI
> + help
> +   Say Y here to enable support for Intel dual role port mux

Either "Intel's" or "the Intel".

> +   controlled by 3 GPIOs.
> +
>  endmenu
>  endif
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 0f230a6..0ccd107 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -198,3 +198,4 @@ intel-soc-pmic-objs   := 
> intel_soc_pmic_core.o intel_soc_pmic_crc.o
>  intel-soc-pmic-$(CONFIG_INTEL_PMC_IPC)   += intel_soc_pmic_bxtwc.o
>  obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
>  obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
> +obj-$(CONFIG_MFD_INTEL_VUPORT)   += intel-vuport.o
> diff --git a/drivers/mfd/intel-vuport.c b/drivers/mfd/intel-vuport.c
> new file mode 100644
> index 000..1371099
> --- /dev/null
> +++ b/drivers/mfd/intel-vuport.c
> @@ -0,0 +1,78 @@
> +/*
> + * MFD driver for Intel virtual USB port
> + *
> + * Copyright(c) 2016 Intel Corporation.
> + * Author: Lu Baolu 
> + *
> + * 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 
> +
> +/* ACPI GPIO Mappings */
> +static const struct acpi_gpio_params id_gpio = { 0, 0, false };
> +static const struct acpi_gpio_params vbus_gpio = { 1, 0, false };
> +static const struct acpi_gpio_params mux_gpio = { 2, 0, false };
> +static const struct acpi_gpio_mapping acpi_usb_gpios[] = {
> + { "id-gpios", &id_gpio, 1 },
> + { "vbus_en-gpios", &vbus_gpio, 1 },
> + { "usb_mux-gpios", &mux_gpio, 1 },
> + { },
> +};
> +
> +static const struct mfd_cell intel_vuport_mfd_cells[] = {
> + {
> + .name = "extcon-usb-gpio",
> + },
> + {
> + .name = "intel-mux-gpio",
> + },
> +};

Please place single line entries on the same line as the '{' and '}'.

As you have above.

> +static int vuport_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + int ret;
> +
> + ret = acpi_dev_add_driver_gpios(ACPI_COMPANION(dev), acpi_usb_gpios);
> + if (ret)
> + return ret;
> +
> + return mfd_add_devices(&pdev->dev, 0, intel_vuport_mfd_cells,
> + ARRAY_SIZE(intel_vuport_mfd_cells), NULL, 0,
> + NULL);
> +}
> +
> +static int vuport_remove(struct platform_device *pdev)
> +{
> + mfd_remove_devices(&pdev->dev);
> + acpi_dev_remove_driver_gpios(ACPI_COMPANION(&pdev->dev));
> +
> + return 0;
> +}
> +
> +static struct acpi_device_id vuport_acpi_match[] = {
> + { "INT3496" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(acpi, vuport_acpi_match);
> +
> +static struct platform_driver vuport_driver = {
> + .driver = {
> + .name = "intel-vuport",
> + .acpi_match_table = ACPI_PTR(vuport_acpi_match),
> + },
> + .probe = vuport_probe,
> + .remove = vuport_remove,
> +};
> +
> +module_platform_driver(vuport_driver);
> +
> +MODULE_AUTHOR("Lu Baolu ");
> +MODULE_DESCRIPTION("Intel virtual USB port");
> +MODULE_LICENSE("GPL v2");

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

RE: [PATCH v4 4/7] Documentation: fsl-quadspi: Add fsl,ls2080a-dspi compatible string

[Yao Yuan]

On Tue, Mar 08, 2016 at 4:32AM, Brian Norris wrote:
> On Tue, Jan 26, 2016 at 03:23:58PM +0800, Yuan Yao wrote:
> > new compatible string: "fsl,ls2080a-qspi".
> 
> ^^ This line doesn't match the subject or the content of the patch.
> 
> > Signed-off-by: Yuan Yao 
> > Acked-by: Rob Herring 
> > ---
> > Changed in v4:
> > No changes.
> >
> > Changed in v3:
> > Add the modifier for new compatible string like:
> > "fsl,ls2080a-dspi" followed by "fsl,ls2085a-dspi"
> >
> > Changed in v2:
> > Update my email to 
> > ---
> >  Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | 5 -
> 
> ^^ What is this change doing in this series anyway? You're touching MTD stuff,
> not SPI stuff, and this string doesn't get used in any driver. Is this 
> controller
> somehow related, or is it a separate IP block that happens to be on some of 
> the
> same SoCs?
> 

Sorry for the wrong subject, this patch is used for add the SPI(DSPI) binging 
document.
It should be some mistake that I make the wrong subject and the commit message.

> Anyway, you should send this kind of stuff to the SPI list, not the MTD one.

I will resend it to SPI list, thanks for your review.

> Regards,
> Brian
> 
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> > b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> > index fa77f87..1ad0fe3 100644
> > --- a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> > +++ b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> > @@ -1,7 +1,10 @@
> >  ARM Freescale DSPI controller
> >
> >  Required properties:
> > -- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi", 
> > "fsl,ls2085a-dspi"
> > +- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi",
> > +   "fsl,ls2085a-dspi"
> > +   or
> > +   "fsl,ls2080a-dspi" followed by "fsl,ls2085a-dspi"
> >  - reg : Offset and length of the register set for the device
> >  - interrupts : Should contain SPI controller interrupt
> >  - clocks: from common clock binding: handle to dspi clock.
> > --
> > 2.1.0.27.g96db324
> >

Re: [PATCH] gpio: xgene: Fix kconfig for standby GIPO contoller

[Quan Nguyen]

On Fri, Mar 4, 2016 at 5:59 PM, Matthias Brugger  wrote:
> The standby GPIO controller can be used as a interrupt controller.
> Select GPIOLIB_IRQCHIP when compiling this driver. Otherwise we get
> a compilation error:
>
> drivers/gpio/gpio-xgene-sb.c: In function 'xgene_gpio_sb_probe':
> drivers/gpio/gpio-xgene-sb.c:312:10: error: 'struct gpio_chip' has no member 
> named 'irqdomain'
>   priv->gc.irqdomain = priv->irq_domain;
>   ^
> scripts/Makefile.build:295: recipe for target 'drivers/gpio/gpio-xgene-sb.o' 
> failed
> make[2]: *** [drivers/gpio/gpio-xgene-sb.o] Error 1
>
> Fixes: 1013fc41 "gpio: xgene: Enable X-Gene standby GPIO as interrupt 
> controller"
> Signed-off-by: Matthias Brugger 
> ---
>  drivers/gpio/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>

Acked-by: Quan Nguyen 

Re: [PATCH 05/14] mfd: ipaq-micro: use __maybe_unused to hide pm functions

[Lee Jones]

On Wed, 02 Mar 2016, Arnd Bergmann wrote:

> The ipaq-micro driver uses SET_SYSTEM_SLEEP_PM_OPS() to
> remove the reference to its resume function, but does
> not use an #ifdef around the definition, so we get
> a build warning:
> 
> drivers/mfd/ipaq-micro.c:379:12: error: 'micro_resume' defined but not used 
> [-Werror=unused-function]
> 
> This adds a __maybe_unused annotation so the compiler knows
> it can silently drop it instead of warning.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/mfd/ipaq-micro.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied, thanks.

> diff --git a/drivers/mfd/ipaq-micro.c b/drivers/mfd/ipaq-micro.c
> index a41859c55bda..df16fd1df68b 100644
> --- a/drivers/mfd/ipaq-micro.c
> +++ b/drivers/mfd/ipaq-micro.c
> @@ -376,7 +376,7 @@ static const struct mfd_cell micro_cells[] = {
>   { .name = "ipaq-micro-leds", },
>  };
>  
> -static int micro_resume(struct device *dev)
> +static int __maybe_unused micro_resume(struct device *dev)
>  {
>   struct ipaq_micro *micro = dev_get_drvdata(dev);
>  

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)

[David Miller]

From: Khalid Aziz 
Date: Mon, 7 Mar 2016 17:21:05 -0700

> Can we enable ADI support for swappable pages in a subsequent update
> after the core functionality is stable on mlock'd pages?

I already said no.

Re: [PATCH] Fix NULL ptr dereference in pci_bus_assign_domain_nr() on ARM

[Bjorn Helgaas]

On Tue, Mar 08, 2016 at 03:01:20AM +, Lorenzo Pieralisi wrote:
> On Mon, Mar 07, 2016 at 04:33:11PM -0600, Bjorn Helgaas wrote:
> > [+cc Lorenzo]
> > 
> > On Tue, Mar 01, 2016 at 07:07:18AM +0100, Krzysztof Ha??asa wrote:
> > > Many ARM platforms use a wrapper:
> > > /*
> > >  * Compatibility wrapper for older platforms that do not care about
> > >  * passing the parent device.
> > >  */
> > > static inline void pci_common_init(struct hw_pci *hw)
> > > {
> > > pci_common_init_dev(NULL, hw);
> > > }
> > > 
> > > which means that pci_bus_assign_domain_nr() can be called without
> > > a parent. This patch fixes the NULL pointer dereference.
> > > 
> > > Signed-off-by: Krzysztof Ha??asa 
> > > Cc: sta...@vger.kernel.org
> > 
> > I applied this to for-linus with changelog as below for v4.5, thanks!
> > 
> > Wow, this is terrible.  All ARM32 systems that use pci_common_init()
> > crash at boot.  That includes cns3xxx, dove, footbridge, iopl13xx,
> > ip32x, iop33x, ixp4xx, ks8695, mv78xx0, orion5x, pxa, sa1100, etc.
> > Apparently they've been crashing since v4.0, when 7c674700098c and
> > 8c7d14746abc appeared.  I can hardly believe nobody noticed until now.
> > 
> > Actually, I did find one problem report:
> > http://forum.doozan.com/read.php?2,17868,22070,quote=1 from last May,
> > but apparently it got lost in a forum and never found its way
> > upstream.
> > 
> > I reworked the changelog because this problem will affect *any* arch
> > that enables CONFIG_PCI_DOMAINS_GENERIC and supplies NULL "parent"
> > pointers -- ia64, mips, mn10300, s390, x86, etc., would be affected if
> > they enabled CONFIG_PCI_DOMAINS_GENERIC.
> > 
> > I also added a "Fixes:" tag for 7c674700098c, since that's the commit
> > that added the generic code we're fixing.  Backports of 7c674700098c
> > should also backport this change.
> 
> That's really unfortunate, when I moved code from arm64 to generic I
> did not spot this issue in the original code and carried it over, you
> summarized the reasons in the commit log so without any further ado (and
> with my apologies):
> 
> Acked-by: Lorenzo Pieralisi 

No worries, it just goes with the territory.  What surprises me is
that it took us so long to notice.  v4.0 was released almost a year
ago (April 12, 2015), so I can't figure out how nobody noticed until
now.

And I don't know what happened with the problem report in the forum.
That's a case where somebody *did* notice, but I guess they just gave
up on v4.0 and went back to v3.18.  What a shame :)  I don't know if
people just have low expectations of Linux, or they feel like it's too
hard to report bugs, or we don't make it easy enough, or we're not
approachable enough, or what.  I notice that many times somebody finds
a workaround, and people seem satisfied with that, and we don't get a
chance to fix the real problem.

Bjorn

> > commit 71babd2a89fe
> > Author: Krzysztof =?utf-8?Q?Ha=C5=82asa?= 
> > Date:   Tue Mar 1 07:07:18 2016 +0100
> > 
> > PCI: Allow a NULL "parent" pointer in pci_bus_assign_domain_nr()
> > 
> > pci_create_root_bus() passes a "parent" pointer to
> > pci_bus_assign_domain_nr().  When CONFIG_PCI_DOMAINS_GENERIC is defined,
> > pci_bus_assign_domain_nr() dereferences that pointer.  Many callers of
> > pci_create_root_bus() supply a NULL "parent" pointer, which leads to a 
> > NULL
> > pointer dereference error.
> > 
> > 7c674700098c ("PCI: Move domain assignment from arm64 to generic code")
> > moved the "parent" dereference from arm64 to generic code.  Only arm64 
> > used
> > that code (because only arm64 defined CONFIG_PCI_DOMAINS_GENERIC), and 
> > it
> > always supplied a valid "parent" pointer.  Other arches supplied NULL
> > "parent" pointers but didn't defined CONFIG_PCI_DOMAINS_GENERIC, so they
> > used a no-op version of pci_bus_assign_domain_nr().
> > 
> > 8c7d14746abc ("ARM/PCI: Move to generic PCI domains") defined
> > CONFIG_PCI_DOMAINS_GENERIC on ARM, and many ARM platforms use
> > pci_common_init(), which supplies a NULL "parent" pointer.
> > These platforms (cns3xxx, dove, footbridge, iop13xx, etc.) crash
> > with a NULL pointer dereference like this while probing PCI:
> > 
> >   Unable to handle kernel NULL pointer dereference at virtual address 
> > 00a4
> >   PC is at pci_bus_assign_domain_nr+0x10/0x84
> >   LR is at pci_create_root_bus+0x48/0x2e4
> >   Kernel panic - not syncing: Attempted to kill init!
> > 
> > [bhelgaas: changelog, add "Reported:" and "Fixes:" tags]
> > Reported: http://forum.doozan.com/read.php?2,17868,22070,quote=1
> > Fixes: 8c7d14746abc ("ARM/PCI: Move to generic PCI domains")
> > Fixes: 7c674700098c ("PCI: Move domain assignment from arm64 to generic 
> > code")
> > Signed-off-by: Krzysztof Ha??asa 
> > Signed-off-by: Bjorn Helgaas 
> > CC: sta...@vger.kernel.org  # v4.0+
> > 
> > diff --git a/drivers/pci/pci.c b/drivers/

Re: [PATCH 1/4] mfd: max77686: Add max77802 to I2C device ID table

[Lee Jones]

On Fri, 12 Feb 2016, Javier Martinez Canillas wrote:

> The max77686 MFD driver supports both the Maxim 77686 and Maxim 77802
> PMICs but only the OF device table contains entries for both devices.
> 
> The max77802 entry is missing in the I2C device ID table which isn't
> a problem currently since the driver only supports DT but it will be
> needed if the driver is changed to be built as a module since the I2C
> core always reports a I2C modalias uevent so auto-load will not work.
> 
> Signed-off-by: Javier Martinez Canillas 
> ---
> 
>  drivers/mfd/max77686.c | 1 +
>  1 file changed, 1 insertion(+)

Applied, thanks.

> diff --git a/drivers/mfd/max77686.c b/drivers/mfd/max77686.c
> index d959ebbb2194..1f30c97d6d4e 100644
> --- a/drivers/mfd/max77686.c
> +++ b/drivers/mfd/max77686.c
> @@ -345,6 +345,7 @@ static int max77686_i2c_remove(struct i2c_client *i2c)
>  
>  static const struct i2c_device_id max77686_i2c_id[] = {
>   { "max77686", TYPE_MAX77686 },
> + { "max77802", TYPE_MAX77802 },
>   { }
>  };
>  MODULE_DEVICE_TABLE(i2c, max77686_i2c_id);

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 4/4] mfd: max77686: Export OF module alias information

[Lee Jones]

On Fri, 12 Feb 2016, Javier Martinez Canillas wrote:

> When the device is registered via OF, the OF table is used to match the
> driver instead of the I2C device ID table but the entries in the latter
> are used as aliasses to load the module if the driver was not built-in.
> 
> This is because the I2C core always reports an I2C module alias instead
> of an OF one but that could change so it is better to always export it.

I do have a set which changes this behaviour.

Annoyingly it is still not applied. :(

> Signed-off-by: Javier Martinez Canillas 
> 
> ---
> 
>  drivers/mfd/max77686.c | 1 +
>  1 file changed, 1 insertion(+)

Applied, thanks.

> diff --git a/drivers/mfd/max77686.c b/drivers/mfd/max77686.c
> index 2f563d0f83cc..b1ed9ed0828c 100644
> --- a/drivers/mfd/max77686.c
> +++ b/drivers/mfd/max77686.c
> @@ -204,6 +204,7 @@ static const struct of_device_id max77686_pmic_dt_match[] 
> = {
>   },
>   { },
>  };
> +MODULE_DEVICE_TABLE(of, max77686_pmic_dt_match);
>  
>  static int max77686_i2c_probe(struct i2c_client *i2c,
> const struct i2c_device_id *id)

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [RESEND PATCH v4 0/8] i2c: Relax mandatory I2C ID table passing

[Lee Jones]

On Mon, 12 Oct 2015, Kieran Bingham wrote:

> Hi Wolfram,
> 
> On 9 October 2015 at 22:16, Wolfram Sang  wrote:
> >
> > As said to Kieran personally in Dublin, I want a verification that all
> > binding methods still work, especially runtime instantiation for drivers
> > without i2c_device_ids.
> 
> Ok, I should be able to find some time to look at that this week.
> 
> >  Also, for the last patch, a verification should
> > be done if the drivers i2c_device_id hasn't been used meanwhile.
> 
> I'll see what I can do ...
> 
> > I'd also like to see 'probe_new' instead of 'probe2' for the new function
> > name. That should be it.
> 
> Ok, obviously this is only a temporary naming so I don't mind either way,
> I'll do a rename for the next version
> 
> I've also just found a compile failure to fix up on !CONFIG_OF, this
> can make its way into the respin.

I still don't see this upstream.  What's the latest status?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: user namespace and fully visible proc and sys mounts

[Eric W. Biederman]

Andy Lutomirski  writes:

> On Mon, Mar 7, 2016 at 4:07 PM, Eric W. Biederman  
> wrote:
>> Andy Lutomirski  writes:
>>
>>> On a related note, can we *please* find a way to constrain namespace
>>> creation in a way that might satisfy the RHEL crowd?
>>
>> I am not certain to what you are referrring.
>>
>> As long as folks are willing to work with me I am happy to help design
>> and design something that makes things better for everyone.  If someone
>> pushes hard, suggestes crappy patches, and does not listen to
>> constructive feedback I will shoot their patches down (especially when I
>> am sick and tired as I have been more than I would like this development
>> cycle).
>
> I think we should add some mechanism that will allow the right to
> create various namespaces to be constrained in a useful and usable
> manner.  I'll start a new thread.

On the general principle that there is more attack surface, and attack
surface reduction is generally good I agree.  I will await your follow
on thread when you are ready.

Eric

Re: [PATCH net] sctp: fix copying more bytes than expected in sctp_add_bind_addr

[David Miller]

From: Marcelo Ricardo Leitner 
Date: Mon, 7 Mar 2016 20:27:11 -0300

> Hi,
> 
> Em 07-03-2016 20:17, kbuild test robot escreveu:
>> Hi Marcelo,
>>
>> [auto build test WARNING on net/master]
>>
>> url:
>> https://github.com/0day-ci/linux/commits/Marcelo-Ricardo-Leitner/sctp-fix-copying-more-bytes-than-expected-in-sctp_add_bind_addr/20160308-052009
>>
>>
>> coccinelle warnings: (new ones prefixed by >>)
>>
 net/sctp/bind_addr.c:458:42-48: ERROR: application of sizeof to
 pointer
>>
>> Please review and possibly fold the followup patch.
> 
> Oops, nice catch, thanks.
> 
> I can fold it if Dave prefers, no problem. I'll wait for a
> confirmation.

Please respin your patch with this folded into it, thanks.

Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)

[David Miller]

From: Rob Gardner 
Date: Mon, 7 Mar 2016 15:13:31 -0800

> You can easily read ADI tags with a simple ldxa #ASI_MCD_PRIMARY
> instruction.

Awesome!

Re: [PATCH 3/4] mfd: max77686: Allow driver to be built as a module

[Lee Jones]

On Fri, 12 Feb 2016, Javier Martinez Canillas wrote:

> The driver's Kconfig symbol is a boolean but nothing prevents the driver
> to be built as a module instead of built-in. It is true that most system
> integrators will choose the latter but the config should not restrict it.
> 
> Signed-off-by: Javier Martinez Canillas 
> ---
> 
>  drivers/mfd/Kconfig | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 6c4ebd9f4cb6..005ace26230e 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -493,8 +493,8 @@ config MFD_MAX14577
> of the device.
>  
>  config MFD_MAX77686
> - bool "Maxim Semiconductor MAX77686/802 PMIC Support"
> - depends on I2C=y
> + tristate "Maxim Semiconductor MAX77686/802 PMIC Support"
> + depends on I2C
>   depends on OF
>   select MFD_CORE
>   select REGMAP_I2C

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [RESEND RFC 2/3] nvmem: Add 'nvmem-blob' driver

[Andrey Smirnov]

>> >
>> > Patch itself looks simple. Before we review it further could you provide
>> > more details on the exact usecase or some background of this.
>>
>> The discussion on this topic originated on mailing list of Barebox
>> project(which borrows very heavily from Linux designs). Barebox
>> operates on two device tree blobs, one is used for its internal
>> initialization, whereas second one is passed to Linux kernel when
>> booting it. The problem I was trying to solve was to make possible to
>> specify in the first DT blob what data would be used for MAC address
>> fixup of the second DT blob(the one passed to Linux).
>>
>> My first approach was to implement a very limited DT code, however in
>> discussing it the consensus was that porting 'nvmem' subsystem from
>> the kernel and using for the same purpose would be a better approach.
>> First pass adoption of that subsystem revealed that there were two
>> use-cases that current design didn't allow us to handle:
>>
>> - Depending on the version i.MX SoC MAC address data stored in ROM
>> would have different layout so as a possible solution to that I
>> implemented "composite" driver(patch #3)
>>
>> - On i.MX28, part of the MAC address is hard-coded in
>> arch/arm/mach-mxs/mach-mxs.c and only a portion of it is read from
>> ROM, this patch in combination with the aforementioned one should
>> allow us to encode all needed info in DT.
>>
>> Ideally, since all of the above is as applicable to Linux as it is to
>> Barebox it would be good for BB not to invent its own custom 'nvmem'
>> flavor, so hence me trying to start a conversation about adding this
>> upstream.
>
> If the only use-case is to store the MAC address, why not using the
> local-mac-address property directly?

I don't think I understand what you mean, could you give me an example
of how I'd use local-mac-address property for that use case? AFAIK,
local-mac-address is just an array of bytes embedded into device tree,
how would it get populated with data from OTP memory of SoC?

Re: [PATCH 01/11] rxrpc: Add a common object cache

[David Miller]

From: David Howells 
Date: Mon, 07 Mar 2016 22:45:14 +

> David Miller  wrote:
> 
>> I know you put a lot of time and effort into this, but I want to strongly
>> recommend against a garbage collected hash table for anything whatsoever.
>> 
>> Especially if the given objects are in some way created/destroyed/etc. by
>> operations triggerable remotely.
>> 
>> This can be DoS'd quite trivially, and that's why we have removed the ipv4
>> routing cache which did the same.
> 
> Hmmm...  You have a point.  What would you suggest instead?  At least with the
> common object cache code I have, I might be able to just change that.

Objects that are used for correct operation have no easily recyclable
property, you must hold onto them.  There has to be a set of resources
held and consumed at both endpoints for it to work properly ("I can't
DoS you without DoS'ing myself").

Where reclaimable tables work is for stuff that is near zero cost to
reconstitute.  A good example is the TCP metrics table.  When a TCP
metrics entry is reclaimed, it's not like we have to renegotiate a
security context when we try to talk to that end-host again.

If the concept of these open-ended objects is a fundamental aspect of
the protocol that's a serious shortcoming of RXRPC.

Re: [PATCH] dmaengine: pl330: Fix some race conditions in residue calculation

[Vinod Koul]

On Wed, Feb 24, 2016 at 01:14:34PM +, Jon Medhurst (Tixy) wrote:
> The residue calculation in pl330_tx_status doesn't handle transitional
> states that occur at the time one descriptor (A) is completed and the
> next (B) is started. Specifically, both A and B can simultaneously be in
> the BUSY state and at this time the thread's 'req_running' may (or may
> not) be -1.

you are under lock so descriptor state wont be update while we are it.

Also the query for residue is for "a descriptor" not whatever is the current
running descriptor...

> 
> To cope with this situation we change the code to ensure A is treated as
> complete and B as having not yet started. Prior to the change, the code
> would calculate a transferred byte count as if both A and B had
> completed.

You query for either A or B not both!

> 
> Fixes: aee4d1fac887 ("dmaengine: pl330: improve pl330_tx_status() function")
> 
> Signed-off-by: Jon Medhurst 
> ---
> 
> I discovered this issue when trying to work out why audio stopped
> working on ARM's Juno platform and bisected it to commit aee4d1fac887.
> Whilst this patch seems to fix the problems I was seeing, I can't help
> but think there are more race conditions with this code. E.g. if the
> running descriptor changes under us, pl330_get_current_xferred_count
> can end up reading values from hardware that relate to a different
> descriptor. And if we're really unlucky, the reading of the 'val' and
> 'addr' values in pl330_get_current_xferred_count can come from different
> descriptors. I don't know if there is any locks we can use to prevent
> such races or if we need to try and detect when things have changed and
> redo/abort the residue calculation...
> 
>  drivers/dma/pl330.c | 24 
>  1 file changed, 20 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index 17ee758..55e3c5f 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -2240,6 +2240,7 @@ pl330_tx_status(struct dma_chan *chan, dma_cookie_t 
> cookie,
>   struct dma_pl330_desc *desc, *running = NULL;
>   struct dma_pl330_chan *pch = to_pchan(chan);
>   unsigned int transferred, residual = 0;
> + bool first_busy;
>  
>   ret = dma_cookie_status(chan, cookie, txstate);
>  
> @@ -2253,16 +2254,31 @@ pl330_tx_status(struct dma_chan *chan, dma_cookie_t 
> cookie,
>  
>   if (pch->thread->req_running != -1)
>   running = pch->thread->req[pch->thread->req_running].desc;
> + first_busy = true;
>  
>   /* Check in pending list */
>   list_for_each_entry(desc, &pch->work_list, node) {
>   if (desc->status == DONE)
>   transferred = desc->bytes_requested;
> - else if (running && desc == running)
> - transferred =
> - pl330_get_current_xferred_count(pch, desc);
> - else
> + else if (desc->status == BUSY && first_busy) {
> + first_busy = false;
> + if (running && desc == running) {
> + transferred =
> + pl330_get_current_xferred_count(pch, 
> desc);
> + } else {
> + /* BUSY but not running means it's just 
> completed */
> + transferred = desc->bytes_requested;
> + }
> + } else {
> + /*
> +  * Descriptor is either in PREP state queued for future
> +  * transfer or it is the second BUSY descriptor we have
> +  * seen. The latter case means it has just, or is about
> +  * to be, started, so treat it as having not yet
> +  * transferred any bytes, the same as PREP.
> +  */
>   transferred = 0;
> + }
>   residual += desc->bytes_requested - transferred;
>   if (desc->txd.cookie == cookie) {
>   switch (desc->status) {
> -- 
> 2.1.4
> 
> 

-- 
~Vinod