[PATCH v2,5/5] arm64: dts: mediatek: add USB3 DRD driver

[Chunfeng Yun]

USB3 DRD driver is added for MT8173-EVB, and xHCI driver
becomes its subnode

Signed-off-by: Chunfeng Yun 
---
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts |   46 +--
 arch/arm64/boot/dts/mediatek/mt8173.dtsi|   28 
 2 files changed, 65 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts 
b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index 7453a47..682dfd7 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -34,6 +34,11 @@
 
chosen { };
 
+   extcon_usb: extcon_iddig {
+   compatible = "linux,extcon-usb-gpio";
+   id-gpio = < 16 GPIO_ACTIVE_HIGH>;
+   };
+
usb_p1_vbus: regulator@0 {
compatible = "regulator-fixed";
regulator-name = "usb_vbus";
@@ -42,6 +47,16 @@
gpio = < 130 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
+
+   usb_p0_vbus: regulator@1 {
+   compatible = "regulator-fixed";
+   regulator-name = "vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = < 9 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
 };
 
  {
@@ -205,6 +220,20 @@
bias-pull-down = ;
};
};
+
+   usb_id_pins_float: usb_iddig_pull_up {
+   pins_iddig {
+   pinmux = ;
+   bias-pull-up;
+   };
+   };
+
+   usb_id_pins_ground: usb_iddig_pull_down {
+   pins_iddig {
+   pinmux = ;
+   bias-pull-down;
+   };
+   };
 };
 
  {
@@ -431,12 +460,25 @@
status = "okay";
 };
 
+ {
+   vusb33-supply = <_vusb_reg>;
+   vbus-supply = <_p0_vbus>;
+   extcon = <_usb>;
+   dr_mode = "otg";
+   mediatek,enable-wakeup;
+   pinctrl-names = "default", "id_float", "id_ground";
+   pinctrl-0 = <_id_pins_float>;
+   pinctrl-1 = <_id_pins_float>;
+   pinctrl-2 = <_id_pins_ground>;
+   status = "okay";
+};
+
  {
status = "okay";
 };
 
- {
+_host {
vusb33-supply = <_vusb_reg>;
vbus-supply = <_p1_vbus>;
-   mediatek,wakeup-src = <1>;
+   status = "okay";
 };
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 05f89c4..723ab6e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -608,11 +608,14 @@
status = "disabled";
};
 
-   usb30: usb@1127 {
-   compatible = "mediatek,mt8173-xhci";
-   reg = <0 0x1127 0 0x1000>,
+   ssusb: usb@11271000 {
+   compatible = "mediatek,mt8173-mtu3";
+   reg = <0 0x11271000 0 0x3000>,
  <0 0x11280700 0 0x0100>;
-   interrupts = ;
+   reg-names = "mac", "ippc";
+   interrupts = ;
+   phys = <_port0 PHY_TYPE_USB3>,
+  <_port1 PHY_TYPE_USB2>;
power-domains = < MT8173_POWER_DOMAIN_USB>;
clocks = < CLK_TOP_USB30_SEL>,
 < CLK_PERI_USB0>,
@@ -620,10 +623,21 @@
clock-names = "sys_ck",
  "wakeup_deb_p0",
  "wakeup_deb_p1";
-   phys = <_port0 PHY_TYPE_USB3>,
-  <_port1 PHY_TYPE_USB2>;
mediatek,syscon-wakeup = <>;
-   status = "okay";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   status = "disabled";
+
+   usb_host: xhci@1127 {
+   compatible = "mediatek,mt8173-xhci";
+   reg = <0 0x1127 0 0x1000>;
+   interrupts = ;
+   power-domains = < 
MT8173_POWER_DOMAIN_USB>;
+   clocks = < CLK_TOP_USB30_SEL>;
+   clock-names = "sys_ck";
+   status = "disabled";
+   };
};
 
u3phy: usb-phy@1129 {
-- 
1.7.9.5

[PATCH v2,5/5] arm64: dts: mediatek: add USB3 DRD driver

[Chunfeng Yun]

USB3 DRD driver is added for MT8173-EVB, and xHCI driver
becomes its subnode

Signed-off-by: Chunfeng Yun 
---
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts |   46 +--
 arch/arm64/boot/dts/mediatek/mt8173.dtsi|   28 
 2 files changed, 65 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts 
b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index 7453a47..682dfd7 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -34,6 +34,11 @@
 
chosen { };
 
+   extcon_usb: extcon_iddig {
+   compatible = "linux,extcon-usb-gpio";
+   id-gpio = < 16 GPIO_ACTIVE_HIGH>;
+   };
+
usb_p1_vbus: regulator@0 {
compatible = "regulator-fixed";
regulator-name = "usb_vbus";
@@ -42,6 +47,16 @@
gpio = < 130 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
+
+   usb_p0_vbus: regulator@1 {
+   compatible = "regulator-fixed";
+   regulator-name = "vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = < 9 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
 };
 
  {
@@ -205,6 +220,20 @@
bias-pull-down = ;
};
};
+
+   usb_id_pins_float: usb_iddig_pull_up {
+   pins_iddig {
+   pinmux = ;
+   bias-pull-up;
+   };
+   };
+
+   usb_id_pins_ground: usb_iddig_pull_down {
+   pins_iddig {
+   pinmux = ;
+   bias-pull-down;
+   };
+   };
 };
 
  {
@@ -431,12 +460,25 @@
status = "okay";
 };
 
+ {
+   vusb33-supply = <_vusb_reg>;
+   vbus-supply = <_p0_vbus>;
+   extcon = <_usb>;
+   dr_mode = "otg";
+   mediatek,enable-wakeup;
+   pinctrl-names = "default", "id_float", "id_ground";
+   pinctrl-0 = <_id_pins_float>;
+   pinctrl-1 = <_id_pins_float>;
+   pinctrl-2 = <_id_pins_ground>;
+   status = "okay";
+};
+
  {
status = "okay";
 };
 
- {
+_host {
vusb33-supply = <_vusb_reg>;
vbus-supply = <_p1_vbus>;
-   mediatek,wakeup-src = <1>;
+   status = "okay";
 };
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 05f89c4..723ab6e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -608,11 +608,14 @@
status = "disabled";
};
 
-   usb30: usb@1127 {
-   compatible = "mediatek,mt8173-xhci";
-   reg = <0 0x1127 0 0x1000>,
+   ssusb: usb@11271000 {
+   compatible = "mediatek,mt8173-mtu3";
+   reg = <0 0x11271000 0 0x3000>,
  <0 0x11280700 0 0x0100>;
-   interrupts = ;
+   reg-names = "mac", "ippc";
+   interrupts = ;
+   phys = <_port0 PHY_TYPE_USB3>,
+  <_port1 PHY_TYPE_USB2>;
power-domains = < MT8173_POWER_DOMAIN_USB>;
clocks = < CLK_TOP_USB30_SEL>,
 < CLK_PERI_USB0>,
@@ -620,10 +623,21 @@
clock-names = "sys_ck",
  "wakeup_deb_p0",
  "wakeup_deb_p1";
-   phys = <_port0 PHY_TYPE_USB3>,
-  <_port1 PHY_TYPE_USB2>;
mediatek,syscon-wakeup = <>;
-   status = "okay";
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   status = "disabled";
+
+   usb_host: xhci@1127 {
+   compatible = "mediatek,mt8173-xhci";
+   reg = <0 0x1127 0 0x1000>;
+   interrupts = ;
+   power-domains = < 
MT8173_POWER_DOMAIN_USB>;
+   clocks = < CLK_TOP_USB30_SEL>;
+   clock-names = "sys_ck";
+   status = "disabled";
+   };
};
 
u3phy: usb-phy@1129 {
-- 
1.7.9.5

Re: [PATCH perf/core v9 01/16] perf-symbol: Introduce filename__readable to check readability

[Masami Hiramatsu]

On Mon, 30 May 2016 13:04:47 -0300
Arnaldo Carvalho de Melo  wrote:

> Em Mon, May 30, 2016 at 01:03:17PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Sun, May 29, 2016 at 12:15:13AM +0900, Masami Hiramatsu escreveu:
> > > Introduce filename__readable to check readability by opening
> > > the file directly. Since the access(R_OK) just checks the
> > > readability based on real UID/GID, it is ignored that the
> > > effective UID/GID and capabilities for some special file (e.g.
> > > /proc/kcore).
> > > filename__readable() directly opens given file with O_RDONLY
> > > so that the kernel checks it by effective UID/GID and capabilities.
> > 
> > 
> > You missed the Signed-off-by line.
> 
> This this for you this time, no need to resend.

Oops, and thanks!!

> 
> - Arnaldo


-- 
Masami Hiramatsu 

[PATCH v2,2/5] usb: xhci-mtk: make IPPC register optional

[Chunfeng Yun]

Make IPPC register optional to support host side of dual-role mode,
due to it is moved into common glue layer for simplification.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/host/xhci-mtk.c |   32 +++-
 1 file changed, 27 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index 79959f1..dc86832 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -94,6 +94,9 @@ static int xhci_mtk_host_enable(struct xhci_hcd_mtk *mtk)
int ret;
int i;
 
+   if (ippc == NULL)
+   return 0;
+
/* power on host ip */
value = readl(>ip_pw_ctr1);
value &= ~CTRL1_IP_HOST_PDN;
@@ -139,6 +142,9 @@ static int xhci_mtk_host_disable(struct xhci_hcd_mtk *mtk)
int ret;
int i;
 
+   if (ippc == NULL)
+   return 0;
+
/* power down all u3 ports */
for (i = 0; i < mtk->num_u3_ports; i++) {
value = readl(>u3_ctrl_p[i]);
@@ -173,6 +179,9 @@ static int xhci_mtk_ssusb_config(struct xhci_hcd_mtk *mtk)
struct mu3c_ippc_regs __iomem *ippc = mtk->ippc_regs;
u32 value;
 
+   if (ippc == NULL)
+   return 0;
+
/* reset whole ip */
value = readl(>ip_pw_ctr0);
value |= CTRL0_IP_SW_RST;
@@ -475,6 +484,7 @@ static void xhci_mtk_quirks(struct device *dev, struct 
xhci_hcd *xhci)
 /* called during probe() after chip reset completes */
 static int xhci_mtk_setup(struct usb_hcd *hcd)
 {
+   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct xhci_hcd_mtk *mtk = hcd_to_mtk(hcd);
int ret;
 
@@ -482,12 +492,21 @@ static int xhci_mtk_setup(struct usb_hcd *hcd)
ret = xhci_mtk_ssusb_config(mtk);
if (ret)
return ret;
+   }
+
+   ret = xhci_gen_setup(hcd, xhci_mtk_quirks);
+   if (ret)
+   return ret;
+
+   if (usb_hcd_is_primary_hcd(hcd)) {
+   mtk->num_u3_ports = xhci->num_usb3_ports;
+   mtk->num_u2_ports = xhci->num_usb2_ports;
ret = xhci_mtk_sch_init(mtk);
if (ret)
return ret;
}
 
-   return xhci_gen_setup(hcd, xhci_mtk_quirks);
+   return ret;
 }
 
 static int xhci_mtk_probe(struct platform_device *pdev)
@@ -595,11 +614,14 @@ static int xhci_mtk_probe(struct platform_device *pdev)
hcd->rsrc_start = res->start;
hcd->rsrc_len = resource_size(res);
 
+   mtk->ippc_regs = NULL;
res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
-   mtk->ippc_regs = devm_ioremap_resource(dev, res);
-   if (IS_ERR(mtk->ippc_regs)) {
-   ret = PTR_ERR(mtk->ippc_regs);
-   goto put_usb2_hcd;
+   if (res) {  /* ippc register is optional */
+   mtk->ippc_regs = devm_ioremap_resource(dev, res);
+   if (IS_ERR(mtk->ippc_regs)) {
+   ret = PTR_ERR(mtk->ippc_regs);
+   goto put_usb2_hcd;
+   }
}
 
for (phy_num = 0; phy_num < mtk->num_phys; phy_num++) {
-- 
1.7.9.5

Re: [PATCH perf/core v9 01/16] perf-symbol: Introduce filename__readable to check readability

[Masami Hiramatsu]

On Mon, 30 May 2016 13:04:47 -0300
Arnaldo Carvalho de Melo  wrote:

> Em Mon, May 30, 2016 at 01:03:17PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Sun, May 29, 2016 at 12:15:13AM +0900, Masami Hiramatsu escreveu:
> > > Introduce filename__readable to check readability by opening
> > > the file directly. Since the access(R_OK) just checks the
> > > readability based on real UID/GID, it is ignored that the
> > > effective UID/GID and capabilities for some special file (e.g.
> > > /proc/kcore).
> > > filename__readable() directly opens given file with O_RDONLY
> > > so that the kernel checks it by effective UID/GID and capabilities.
> > 
> > 
> > You missed the Signed-off-by line.
> 
> This this for you this time, no need to resend.

Oops, and thanks!!

> 
> - Arnaldo


-- 
Masami Hiramatsu 

[PATCH v2,2/5] usb: xhci-mtk: make IPPC register optional

[Chunfeng Yun]

Make IPPC register optional to support host side of dual-role mode,
due to it is moved into common glue layer for simplification.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/host/xhci-mtk.c |   32 +++-
 1 file changed, 27 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index 79959f1..dc86832 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -94,6 +94,9 @@ static int xhci_mtk_host_enable(struct xhci_hcd_mtk *mtk)
int ret;
int i;
 
+   if (ippc == NULL)
+   return 0;
+
/* power on host ip */
value = readl(>ip_pw_ctr1);
value &= ~CTRL1_IP_HOST_PDN;
@@ -139,6 +142,9 @@ static int xhci_mtk_host_disable(struct xhci_hcd_mtk *mtk)
int ret;
int i;
 
+   if (ippc == NULL)
+   return 0;
+
/* power down all u3 ports */
for (i = 0; i < mtk->num_u3_ports; i++) {
value = readl(>u3_ctrl_p[i]);
@@ -173,6 +179,9 @@ static int xhci_mtk_ssusb_config(struct xhci_hcd_mtk *mtk)
struct mu3c_ippc_regs __iomem *ippc = mtk->ippc_regs;
u32 value;
 
+   if (ippc == NULL)
+   return 0;
+
/* reset whole ip */
value = readl(>ip_pw_ctr0);
value |= CTRL0_IP_SW_RST;
@@ -475,6 +484,7 @@ static void xhci_mtk_quirks(struct device *dev, struct 
xhci_hcd *xhci)
 /* called during probe() after chip reset completes */
 static int xhci_mtk_setup(struct usb_hcd *hcd)
 {
+   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct xhci_hcd_mtk *mtk = hcd_to_mtk(hcd);
int ret;
 
@@ -482,12 +492,21 @@ static int xhci_mtk_setup(struct usb_hcd *hcd)
ret = xhci_mtk_ssusb_config(mtk);
if (ret)
return ret;
+   }
+
+   ret = xhci_gen_setup(hcd, xhci_mtk_quirks);
+   if (ret)
+   return ret;
+
+   if (usb_hcd_is_primary_hcd(hcd)) {
+   mtk->num_u3_ports = xhci->num_usb3_ports;
+   mtk->num_u2_ports = xhci->num_usb2_ports;
ret = xhci_mtk_sch_init(mtk);
if (ret)
return ret;
}
 
-   return xhci_gen_setup(hcd, xhci_mtk_quirks);
+   return ret;
 }
 
 static int xhci_mtk_probe(struct platform_device *pdev)
@@ -595,11 +614,14 @@ static int xhci_mtk_probe(struct platform_device *pdev)
hcd->rsrc_start = res->start;
hcd->rsrc_len = resource_size(res);
 
+   mtk->ippc_regs = NULL;
res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
-   mtk->ippc_regs = devm_ioremap_resource(dev, res);
-   if (IS_ERR(mtk->ippc_regs)) {
-   ret = PTR_ERR(mtk->ippc_regs);
-   goto put_usb2_hcd;
+   if (res) {  /* ippc register is optional */
+   mtk->ippc_regs = devm_ioremap_resource(dev, res);
+   if (IS_ERR(mtk->ippc_regs)) {
+   ret = PTR_ERR(mtk->ippc_regs);
+   goto put_usb2_hcd;
+   }
}
 
for (phy_num = 0; phy_num < mtk->num_phys; phy_num++) {
-- 
1.7.9.5

[PATCH v2,4/5] usb: Add MediaTek USB3 DRD Driver

[Chunfeng Yun]

This patch adds support for the MediaTek USB3 controller
integrated into MT8173. It can be configured as Dual-Role
Device (DRD), Peripheral Only and Host Only (xHCI) modes.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/Kconfig|2 +
 drivers/usb/Makefile   |1 +
 drivers/usb/mtu3/Kconfig   |   47 ++
 drivers/usb/mtu3/Makefile  |   20 +
 drivers/usb/mtu3/mtu3.h|  422 +
 drivers/usb/mtu3/mtu3_core.c   |  879 
 drivers/usb/mtu3/mtu3_dr.c |  348 ++
 drivers/usb/mtu3/mtu3_dr.h |  108 +
 drivers/usb/mtu3/mtu3_gadget.c |  731 ++
 drivers/usb/mtu3/mtu3_gadget_ep0.c |  879 
 drivers/usb/mtu3/mtu3_host.c   |  294 
 drivers/usb/mtu3/mtu3_hw_regs.h|  474 +++
 drivers/usb/mtu3/mtu3_plat.c   |  490 
 drivers/usb/mtu3/mtu3_qmu.c|  599 
 drivers/usb/mtu3/mtu3_qmu.h|   43 ++
 15 files changed, 5337 insertions(+)
 create mode 100644 drivers/usb/mtu3/Kconfig
 create mode 100644 drivers/usb/mtu3/Makefile
 create mode 100644 drivers/usb/mtu3/mtu3.h
 create mode 100644 drivers/usb/mtu3/mtu3_core.c
 create mode 100644 drivers/usb/mtu3/mtu3_dr.c
 create mode 100644 drivers/usb/mtu3/mtu3_dr.h
 create mode 100644 drivers/usb/mtu3/mtu3_gadget.c
 create mode 100644 drivers/usb/mtu3/mtu3_gadget_ep0.c
 create mode 100644 drivers/usb/mtu3/mtu3_host.c
 create mode 100644 drivers/usb/mtu3/mtu3_hw_regs.h
 create mode 100644 drivers/usb/mtu3/mtu3_plat.c
 create mode 100644 drivers/usb/mtu3/mtu3_qmu.c
 create mode 100644 drivers/usb/mtu3/mtu3_qmu.h

diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 8689dcb..9ca0bf0 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -95,6 +95,8 @@ source "drivers/usb/usbip/Kconfig"
 
 endif
 
+source "drivers/usb/mtu3/Kconfig"
+
 source "drivers/usb/musb/Kconfig"
 
 source "drivers/usb/dwc3/Kconfig"
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index dca7856..7791af6 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_USB_DWC2)+= dwc2/
 obj-$(CONFIG_USB_ISP1760)  += isp1760/
 
 obj-$(CONFIG_USB_MON)  += mon/
+obj-$(CONFIG_USB_MTU3) += mtu3/
 
 obj-$(CONFIG_PCI)  += host/
 obj-$(CONFIG_USB_EHCI_HCD) += host/
diff --git a/drivers/usb/mtu3/Kconfig b/drivers/usb/mtu3/Kconfig
new file mode 100644
index 000..6850fb6
--- /dev/null
+++ b/drivers/usb/mtu3/Kconfig
@@ -0,0 +1,47 @@
+# For MTK USB3.0 IP
+
+config USB_MTU3
+   tristate "MediaTek USB3 Dual Role controller"
+   depends on (USB || USB_GADGET) && HAS_DMA
+   select USB_XHCI_MTK if USB_SUPPORT && USB_XHCI_HCD
+   help
+ Say Y or M here if your system runs on MediaTek SoCs with
+ Dual Role SuperSpeed USB controller. You can select usb
+ mode as peripheral role or host role, or both.
+
+ If you don't know what this is, please say N.
+
+ Choose M here to compile this driver as a module, and it
+ will be called mtu3.ko.
+
+
+if USB_MTU3
+choice
+   bool "MTU3 Mode Selection"
+   default USB_MTU3_DUAL_ROLE if (USB && USB_GADGET)
+   default USB_MTU3_HOST if (USB && !USB_GADGET)
+   default USB_MTU3_GADGET if (!USB && USB_GADGET)
+
+config USB_MTU3_HOST
+   bool "Host only mode"
+   depends on USB=y || USB=USB_MTU3
+   help
+ Select this when you want to use MTU3 in host mode only,
+ thereby the gadget feature will be regressed.
+
+config USB_MTU3_GADGET
+   bool "Gadget only mode"
+   depends on USB_GADGET=y || USB_GADGET=USB_MTU3
+   help
+ Select this when you want to use MTU3 in gadget mode only,
+ thereby the host feature will be regressed.
+
+config USB_MTU3_DUAL_ROLE
+   bool "Dual Role mode"
+   depends on ((USB=y || USB=USB_MTU3) && (USB_GADGET=y || 
USB_GADGET=USB_MTU3))
+   help
+ This is the default mode of working of MTU3 controller where
+ both host and gadget features are enabled.
+
+endchoice
+endif
diff --git a/drivers/usb/mtu3/Makefile b/drivers/usb/mtu3/Makefile
new file mode 100644
index 000..4a66b01
--- /dev/null
+++ b/drivers/usb/mtu3/Makefile
@@ -0,0 +1,20 @@
+
+#ifeq ($(CONFIG_USB_DEBUG),y)
+   ccflags-y   += -DDEBUG
+#endif
+
+obj-$(CONFIG_USB_MTU3) += mtu3.o
+
+mtu3-y := mtu3_plat.o
+
+ifneq ($(filter y,$(CONFIG_USB_MTU3_HOST) $(CONFIG_USB_MTU3_DUAL_ROLE)),)
+   mtu3-y  += mtu3_host.o
+endif
+
+ifneq ($(filter y,$(CONFIG_USB_MTU3_GADGET) $(CONFIG_USB_MTU3_DUAL_ROLE)),)
+   mtu3-y  += mtu3_core.o mtu3_gadget_ep0.o mtu3_gadget.o mtu3_qmu.o
+endif
+
+ifneq ($(CONFIG_USB_MTU3_DUAL_ROLE),)
+   mtu3-y  += mtu3_dr.o
+endif
\ No newline at end of file
diff --git a/drivers/usb/mtu3/mtu3.h 

[PATCH v2,4/5] usb: Add MediaTek USB3 DRD Driver

[Chunfeng Yun]

This patch adds support for the MediaTek USB3 controller
integrated into MT8173. It can be configured as Dual-Role
Device (DRD), Peripheral Only and Host Only (xHCI) modes.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/Kconfig|2 +
 drivers/usb/Makefile   |1 +
 drivers/usb/mtu3/Kconfig   |   47 ++
 drivers/usb/mtu3/Makefile  |   20 +
 drivers/usb/mtu3/mtu3.h|  422 +
 drivers/usb/mtu3/mtu3_core.c   |  879 
 drivers/usb/mtu3/mtu3_dr.c |  348 ++
 drivers/usb/mtu3/mtu3_dr.h |  108 +
 drivers/usb/mtu3/mtu3_gadget.c |  731 ++
 drivers/usb/mtu3/mtu3_gadget_ep0.c |  879 
 drivers/usb/mtu3/mtu3_host.c   |  294 
 drivers/usb/mtu3/mtu3_hw_regs.h|  474 +++
 drivers/usb/mtu3/mtu3_plat.c   |  490 
 drivers/usb/mtu3/mtu3_qmu.c|  599 
 drivers/usb/mtu3/mtu3_qmu.h|   43 ++
 15 files changed, 5337 insertions(+)
 create mode 100644 drivers/usb/mtu3/Kconfig
 create mode 100644 drivers/usb/mtu3/Makefile
 create mode 100644 drivers/usb/mtu3/mtu3.h
 create mode 100644 drivers/usb/mtu3/mtu3_core.c
 create mode 100644 drivers/usb/mtu3/mtu3_dr.c
 create mode 100644 drivers/usb/mtu3/mtu3_dr.h
 create mode 100644 drivers/usb/mtu3/mtu3_gadget.c
 create mode 100644 drivers/usb/mtu3/mtu3_gadget_ep0.c
 create mode 100644 drivers/usb/mtu3/mtu3_host.c
 create mode 100644 drivers/usb/mtu3/mtu3_hw_regs.h
 create mode 100644 drivers/usb/mtu3/mtu3_plat.c
 create mode 100644 drivers/usb/mtu3/mtu3_qmu.c
 create mode 100644 drivers/usb/mtu3/mtu3_qmu.h

diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 8689dcb..9ca0bf0 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -95,6 +95,8 @@ source "drivers/usb/usbip/Kconfig"
 
 endif
 
+source "drivers/usb/mtu3/Kconfig"
+
 source "drivers/usb/musb/Kconfig"
 
 source "drivers/usb/dwc3/Kconfig"
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index dca7856..7791af6 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_USB_DWC2)+= dwc2/
 obj-$(CONFIG_USB_ISP1760)  += isp1760/
 
 obj-$(CONFIG_USB_MON)  += mon/
+obj-$(CONFIG_USB_MTU3) += mtu3/
 
 obj-$(CONFIG_PCI)  += host/
 obj-$(CONFIG_USB_EHCI_HCD) += host/
diff --git a/drivers/usb/mtu3/Kconfig b/drivers/usb/mtu3/Kconfig
new file mode 100644
index 000..6850fb6
--- /dev/null
+++ b/drivers/usb/mtu3/Kconfig
@@ -0,0 +1,47 @@
+# For MTK USB3.0 IP
+
+config USB_MTU3
+   tristate "MediaTek USB3 Dual Role controller"
+   depends on (USB || USB_GADGET) && HAS_DMA
+   select USB_XHCI_MTK if USB_SUPPORT && USB_XHCI_HCD
+   help
+ Say Y or M here if your system runs on MediaTek SoCs with
+ Dual Role SuperSpeed USB controller. You can select usb
+ mode as peripheral role or host role, or both.
+
+ If you don't know what this is, please say N.
+
+ Choose M here to compile this driver as a module, and it
+ will be called mtu3.ko.
+
+
+if USB_MTU3
+choice
+   bool "MTU3 Mode Selection"
+   default USB_MTU3_DUAL_ROLE if (USB && USB_GADGET)
+   default USB_MTU3_HOST if (USB && !USB_GADGET)
+   default USB_MTU3_GADGET if (!USB && USB_GADGET)
+
+config USB_MTU3_HOST
+   bool "Host only mode"
+   depends on USB=y || USB=USB_MTU3
+   help
+ Select this when you want to use MTU3 in host mode only,
+ thereby the gadget feature will be regressed.
+
+config USB_MTU3_GADGET
+   bool "Gadget only mode"
+   depends on USB_GADGET=y || USB_GADGET=USB_MTU3
+   help
+ Select this when you want to use MTU3 in gadget mode only,
+ thereby the host feature will be regressed.
+
+config USB_MTU3_DUAL_ROLE
+   bool "Dual Role mode"
+   depends on ((USB=y || USB=USB_MTU3) && (USB_GADGET=y || 
USB_GADGET=USB_MTU3))
+   help
+ This is the default mode of working of MTU3 controller where
+ both host and gadget features are enabled.
+
+endchoice
+endif
diff --git a/drivers/usb/mtu3/Makefile b/drivers/usb/mtu3/Makefile
new file mode 100644
index 000..4a66b01
--- /dev/null
+++ b/drivers/usb/mtu3/Makefile
@@ -0,0 +1,20 @@
+
+#ifeq ($(CONFIG_USB_DEBUG),y)
+   ccflags-y   += -DDEBUG
+#endif
+
+obj-$(CONFIG_USB_MTU3) += mtu3.o
+
+mtu3-y := mtu3_plat.o
+
+ifneq ($(filter y,$(CONFIG_USB_MTU3_HOST) $(CONFIG_USB_MTU3_DUAL_ROLE)),)
+   mtu3-y  += mtu3_host.o
+endif
+
+ifneq ($(filter y,$(CONFIG_USB_MTU3_GADGET) $(CONFIG_USB_MTU3_DUAL_ROLE)),)
+   mtu3-y  += mtu3_core.o mtu3_gadget_ep0.o mtu3_gadget.o mtu3_qmu.o
+endif
+
+ifneq ($(CONFIG_USB_MTU3_DUAL_ROLE),)
+   mtu3-y  += mtu3_dr.o
+endif
\ No newline at end of file
diff --git a/drivers/usb/mtu3/mtu3.h b/drivers/usb/mtu3/mtu3.h
new file 

[PATCH v2,1/5] dt-bindings: mt8173-xhci: support host side of dual-role mode

[Chunfeng Yun]

Some resources, such as IPPC register etc, shared with device
driver are moved into common glue layer when xHCI driver is the
host side of dual-role mode and they should be changed as optional
properties if they are required ones before. For clarity, add
a new part of binding to support host side of dual-role mode.

Additionally add optional properties of pinctrl for host only mode

Signed-off-by: Chunfeng Yun 
---
 .../devicetree/bindings/usb/mt8173-xhci.txt|   48 
 1 file changed, 48 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt 
b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
index b3a7ffa..542e3fa 100644
--- a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
@@ -2,6 +2,14 @@ MT8173 xHCI
 
 The device node for Mediatek SOC USB3.0 host controller
 
+There are two scenarios: the first one only supports xHCI driver;
+the second one supports dual-role mode, and the host is based on xHCI
+driver. Take account of backward compatibility, we divide bindings
+into two parts.
+
+1st: only supports xHCI driver
+
+
 Required properties:
  - compatible : should contain "mediatek,mt8173-xhci"
  - reg : specifies physical base address and size of the registers,
@@ -27,6 +35,9 @@ Optional properties:
control register, it depends on "mediatek,wakeup-src".
  - vbus-supply : reference to the VBUS regulator;
  - usb3-lpm-capable : supports USB3.0 LPM
+ - pinctl-names : a pinctrl state named "default" must be defined
+ - pinctrl-0 : pin control group
+   See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
 
 Example:
 usb30: usb@1127 {
@@ -49,3 +60,40 @@ usb30: usb@1127 {
mediatek,syscon-wakeup = <>;
mediatek,wakeup-src = <1>;
 };
+
+2nd: dual-role mode with xHCI driver
+
+
+In the case, xhci is added as subnode to mtu3. An example and the DT binding
+details of mtu3 can be found in:
+Documentation/devicetree/bindings/usb/mtu3.txt
+
+Required properties:
+ - compatible : should contain "mediatek,mt8173-xhci"
+ - reg : specifies physical base address and size of the registers,
+   should be only for xHCI IP registers
+ - interrupts : interrupt used by the host controller
+ - power-domains : a phandle to USB power domain node to control USB's
+   mtcmos
+ - vusb33-supply : regulator of USB avdd3.3v
+
+ - clocks : a list of phandle + clock-specifier pairs, one for each
+   entry in clock-names
+ - clock-names : must be
+   "sys_ck": for clock of xHCI MAC
+
+Optional properties:
+ - vbus-supply : reference to the VBUS regulator;
+ - usb3-lpm-capable : supports USB3.0 LPM
+
+Example:
+usb30: usb@1127 {
+   compatible = "mediatek,mt8173-xhci";
+   reg = <0 0x1127 0 0x1000>;
+   interrupts = ;
+   power-domains = < MT8173_POWER_DOMAIN_USB>;
+   clocks = < CLK_TOP_USB30_SEL>;
+   clock-names = "sys_ck";
+   vusb33-supply = <_vusb_reg>;
+   usb3-lpm-capable;
+};
-- 
1.7.9.5

[PATCH v2,1/5] dt-bindings: mt8173-xhci: support host side of dual-role mode

[Chunfeng Yun]

Some resources, such as IPPC register etc, shared with device
driver are moved into common glue layer when xHCI driver is the
host side of dual-role mode and they should be changed as optional
properties if they are required ones before. For clarity, add
a new part of binding to support host side of dual-role mode.

Additionally add optional properties of pinctrl for host only mode

Signed-off-by: Chunfeng Yun 
---
 .../devicetree/bindings/usb/mt8173-xhci.txt|   48 
 1 file changed, 48 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt 
b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
index b3a7ffa..542e3fa 100644
--- a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
@@ -2,6 +2,14 @@ MT8173 xHCI
 
 The device node for Mediatek SOC USB3.0 host controller
 
+There are two scenarios: the first one only supports xHCI driver;
+the second one supports dual-role mode, and the host is based on xHCI
+driver. Take account of backward compatibility, we divide bindings
+into two parts.
+
+1st: only supports xHCI driver
+
+
 Required properties:
  - compatible : should contain "mediatek,mt8173-xhci"
  - reg : specifies physical base address and size of the registers,
@@ -27,6 +35,9 @@ Optional properties:
control register, it depends on "mediatek,wakeup-src".
  - vbus-supply : reference to the VBUS regulator;
  - usb3-lpm-capable : supports USB3.0 LPM
+ - pinctl-names : a pinctrl state named "default" must be defined
+ - pinctrl-0 : pin control group
+   See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
 
 Example:
 usb30: usb@1127 {
@@ -49,3 +60,40 @@ usb30: usb@1127 {
mediatek,syscon-wakeup = <>;
mediatek,wakeup-src = <1>;
 };
+
+2nd: dual-role mode with xHCI driver
+
+
+In the case, xhci is added as subnode to mtu3. An example and the DT binding
+details of mtu3 can be found in:
+Documentation/devicetree/bindings/usb/mtu3.txt
+
+Required properties:
+ - compatible : should contain "mediatek,mt8173-xhci"
+ - reg : specifies physical base address and size of the registers,
+   should be only for xHCI IP registers
+ - interrupts : interrupt used by the host controller
+ - power-domains : a phandle to USB power domain node to control USB's
+   mtcmos
+ - vusb33-supply : regulator of USB avdd3.3v
+
+ - clocks : a list of phandle + clock-specifier pairs, one for each
+   entry in clock-names
+ - clock-names : must be
+   "sys_ck": for clock of xHCI MAC
+
+Optional properties:
+ - vbus-supply : reference to the VBUS regulator;
+ - usb3-lpm-capable : supports USB3.0 LPM
+
+Example:
+usb30: usb@1127 {
+   compatible = "mediatek,mt8173-xhci";
+   reg = <0 0x1127 0 0x1000>;
+   interrupts = ;
+   power-domains = < MT8173_POWER_DOMAIN_USB>;
+   clocks = < CLK_TOP_USB30_SEL>;
+   clock-names = "sys_ck";
+   vusb33-supply = <_vusb_reg>;
+   usb3-lpm-capable;
+};
-- 
1.7.9.5

Add MediaTek USB3 DRD Driver

[Chunfeng Yun]

>From f2b6744b1ed13636db8690dd3e8d65ad7f3fb7ce Mon Sep 17 00:00:00 2001
From: Chunfeng Yun 
Date: Tue, 31 May 2016 10:52:46 +0800
Subject: [PATCH 0/5] Add MediaTek USB3 DRD Driver

These patches introduce the MediaTek USB3 dual-role controller
driver.

The driver can be configured as Dual-Role Device (DRD),
Peripheral Only and Host Only (xHCI) modes. It works well
with Mass Storage, RNDIS and g_zero on FS/HS and SS. And it is
tested on MT8173 platform which only contains USB2.0 device IP,
and on MT6290 platform which contains USB3.0 device IP.

Change in v2:
1. modify binding docs according to suggestions 
2. modify some comments and remove some dummy blank lines
3. fix memory leakage

Chunfeng Yun (5):
  dt-bindings: mt8173-xhci: support host side of dual-role mode
  usb: xhci-mtk: make IPPC register optional
  dt-bindings: mtu3: add devicetree bindings
  usb: Add MediaTek USB3 DRD Driver
  arm64: dts: mediatek: add USB3 DRD driver

 .../devicetree/bindings/usb/mt8173-xhci.txt|   48 ++
 Documentation/devicetree/bindings/usb/mtu3.txt |   85 ++
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts|   46 +-
 arch/arm64/boot/dts/mediatek/mt8173.dtsi   |   28 +-
 drivers/usb/Kconfig|2 +
 drivers/usb/Makefile   |1 +
 drivers/usb/host/xhci-mtk.c|   32 +-
 drivers/usb/mtu3/Kconfig   |   47 ++
 drivers/usb/mtu3/Makefile  |   20 +
 drivers/usb/mtu3/mtu3.h|  422 ++
 drivers/usb/mtu3/mtu3_core.c   |  879 
 drivers/usb/mtu3/mtu3_dr.c |  348 
 drivers/usb/mtu3/mtu3_dr.h |  108 +++
 drivers/usb/mtu3/mtu3_gadget.c |  731 
 drivers/usb/mtu3/mtu3_gadget_ep0.c |  879 
 drivers/usb/mtu3/mtu3_host.c   |  294 +++
 drivers/usb/mtu3/mtu3_hw_regs.h|  474 +++
 drivers/usb/mtu3/mtu3_plat.c   |  490 +++
 drivers/usb/mtu3/mtu3_qmu.c|  599 +
 drivers/usb/mtu3/mtu3_qmu.h|   43 +
 20 files changed, 5562 insertions(+), 14 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/mtu3.txt
 create mode 100644 drivers/usb/mtu3/Kconfig
 create mode 100644 drivers/usb/mtu3/Makefile
 create mode 100644 drivers/usb/mtu3/mtu3.h
 create mode 100644 drivers/usb/mtu3/mtu3_core.c
 create mode 100644 drivers/usb/mtu3/mtu3_dr.c
 create mode 100644 drivers/usb/mtu3/mtu3_dr.h
 create mode 100644 drivers/usb/mtu3/mtu3_gadget.c
 create mode 100644 drivers/usb/mtu3/mtu3_gadget_ep0.c
 create mode 100644 drivers/usb/mtu3/mtu3_host.c
 create mode 100644 drivers/usb/mtu3/mtu3_hw_regs.h
 create mode 100644 drivers/usb/mtu3/mtu3_plat.c
 create mode 100644 drivers/usb/mtu3/mtu3_qmu.c
 create mode 100644 drivers/usb/mtu3/mtu3_qmu.h

-- 
1.7.9.5

Add MediaTek USB3 DRD Driver

[Chunfeng Yun]

>From f2b6744b1ed13636db8690dd3e8d65ad7f3fb7ce Mon Sep 17 00:00:00 2001
From: Chunfeng Yun 
Date: Tue, 31 May 2016 10:52:46 +0800
Subject: [PATCH 0/5] Add MediaTek USB3 DRD Driver

These patches introduce the MediaTek USB3 dual-role controller
driver.

The driver can be configured as Dual-Role Device (DRD),
Peripheral Only and Host Only (xHCI) modes. It works well
with Mass Storage, RNDIS and g_zero on FS/HS and SS. And it is
tested on MT8173 platform which only contains USB2.0 device IP,
and on MT6290 platform which contains USB3.0 device IP.

Change in v2:
1. modify binding docs according to suggestions 
2. modify some comments and remove some dummy blank lines
3. fix memory leakage

Chunfeng Yun (5):
  dt-bindings: mt8173-xhci: support host side of dual-role mode
  usb: xhci-mtk: make IPPC register optional
  dt-bindings: mtu3: add devicetree bindings
  usb: Add MediaTek USB3 DRD Driver
  arm64: dts: mediatek: add USB3 DRD driver

 .../devicetree/bindings/usb/mt8173-xhci.txt|   48 ++
 Documentation/devicetree/bindings/usb/mtu3.txt |   85 ++
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts|   46 +-
 arch/arm64/boot/dts/mediatek/mt8173.dtsi   |   28 +-
 drivers/usb/Kconfig|2 +
 drivers/usb/Makefile   |1 +
 drivers/usb/host/xhci-mtk.c|   32 +-
 drivers/usb/mtu3/Kconfig   |   47 ++
 drivers/usb/mtu3/Makefile  |   20 +
 drivers/usb/mtu3/mtu3.h|  422 ++
 drivers/usb/mtu3/mtu3_core.c   |  879 
 drivers/usb/mtu3/mtu3_dr.c |  348 
 drivers/usb/mtu3/mtu3_dr.h |  108 +++
 drivers/usb/mtu3/mtu3_gadget.c |  731 
 drivers/usb/mtu3/mtu3_gadget_ep0.c |  879 
 drivers/usb/mtu3/mtu3_host.c   |  294 +++
 drivers/usb/mtu3/mtu3_hw_regs.h|  474 +++
 drivers/usb/mtu3/mtu3_plat.c   |  490 +++
 drivers/usb/mtu3/mtu3_qmu.c|  599 +
 drivers/usb/mtu3/mtu3_qmu.h|   43 +
 20 files changed, 5562 insertions(+), 14 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/mtu3.txt
 create mode 100644 drivers/usb/mtu3/Kconfig
 create mode 100644 drivers/usb/mtu3/Makefile
 create mode 100644 drivers/usb/mtu3/mtu3.h
 create mode 100644 drivers/usb/mtu3/mtu3_core.c
 create mode 100644 drivers/usb/mtu3/mtu3_dr.c
 create mode 100644 drivers/usb/mtu3/mtu3_dr.h
 create mode 100644 drivers/usb/mtu3/mtu3_gadget.c
 create mode 100644 drivers/usb/mtu3/mtu3_gadget_ep0.c
 create mode 100644 drivers/usb/mtu3/mtu3_host.c
 create mode 100644 drivers/usb/mtu3/mtu3_hw_regs.h
 create mode 100644 drivers/usb/mtu3/mtu3_plat.c
 create mode 100644 drivers/usb/mtu3/mtu3_qmu.c
 create mode 100644 drivers/usb/mtu3/mtu3_qmu.h

-- 
1.7.9.5

[PATCH v2,3/5] dt-bindings: mtu3: add devicetree bindings

[Chunfeng Yun]

add a DT binding doc for MediaTek USB3 DRD driver

Signed-off-by: Chunfeng Yun 
---
 Documentation/devicetree/bindings/usb/mtu3.txt |   85 
 1 file changed, 85 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/mtu3.txt

diff --git a/Documentation/devicetree/bindings/usb/mtu3.txt 
b/Documentation/devicetree/bindings/usb/mtu3.txt
new file mode 100644
index 000..571ae8b
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/mtu3.txt
@@ -0,0 +1,85 @@
+The device node for Mediatek USB3.0 DRD controller
+
+Required properties:
+ - compatible : should be "mediatek,mt8173-mtu3"
+ - reg : specifies physical base address and size of the registers
+ - reg-names: should be "mac" for device IP and "ippc" for IP port control
+ - interrupts : interrupt used by the device IP
+ - power-domains : a phandle to USB power domain node to control USB's
+   mtcmos
+ - vusb33-supply : regulator of USB avdd3.3v
+ - clocks : a list of phandle + clock-specifier pairs, one for each
+   entry in clock-names
+ - clock-names : must contain "sys_ck" for clock of controller;
+   "wakeup_deb_p0" and "wakeup_deb_p1" are optional, they are
+   depends on "mediatek,enable-wakeup"
+ - phys : a list of phandle + phy specifier pairs
+ - dr_mode : should be one of "host", "peripheral" or "otg",
+   refer to usb/generic.txt
+
+Optional properties:
+ - #address-cells, #size-cells : should be '2' if the device has sub-nodes
+   with 'reg' property
+ - ranges : allows valid 1:1 translation between child's address space and
+   parent's address space
+ - extcon : external connector for vbus and idpin changes detection, needed
+   when supports dual-role mode.
+ - vbus-supply : reference to the VBUS regulator, needed when supports
+   dual-role mode.
+ - pinctl-names : a pinctrl state named "default" must be defined,
+   "id_float" and "id_ground" are optinal which depends on
+   "mediatek,enable-manual-drd"
+ - pinctrl-0 : pin control group
+   See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+
+ - maximum-speed : valid arguments are "super-speed", "high-speed" and
+   "full-speed"; refer to usb/generic.txt
+ - enable-manual-drd : supports manual dual-role switch via sysfs; only used
+   when receptacle is TYPE-A and also wants to support dual-role mode.
+ - mediatek,enable-wakeup : supports ip sleep wakeup used by host mode
+ - mediatek,syscon-wakeup : phandle to syscon used to access USB wakeup
+   control register, it depends on "mediatek,enable-wakeup".
+
+Sub-nodes:
+The xhci should be added as subnode to mtu3 as shown in the following example
+if host mode is enabled. The DT binding details of xhci can be found in:
+Documentation/devicetree/bindings/usb/mt8173-xhci.txt
+
+Example:
+ssusb: usb@11271000 {
+   compatible = "mediatek,mt8173-mtu3";
+   reg = <0 0x11271000 0 0x3000>,
+ <0 0x11280700 0 0x0100>;
+   reg-names = "mac", "ippc";
+   interrupts = ;
+   phys = <_port0 PHY_TYPE_USB3>,
+  <_port1 PHY_TYPE_USB2>;
+   power-domains = < MT8173_POWER_DOMAIN_USB>;
+   clocks = < CLK_TOP_USB30_SEL>,
+< CLK_PERI_USB0>,
+< CLK_PERI_USB1>;
+   clock-names = "sys_ck",
+ "wakeup_deb_p0",
+ "wakeup_deb_p1";
+   vusb33-supply = <_vusb_reg>;
+   vbus-supply = <_p0_vbus>;
+   extcon = <_usb>;
+   dr_mode = "otg";
+   mediatek,enable-wakeup;
+   mediatek,syscon-wakeup = <>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   status = "disabled";
+
+   usb_host: xhci@1127 {
+   compatible = "mediatek,mt8173-xhci";
+   reg = <0 0x1127 0 0x1000>;
+   interrupts = ;
+   power-domains = < MT8173_POWER_DOMAIN_USB>;
+   clocks = < CLK_TOP_USB30_SEL>;
+   clock-names = "sys_ck";
+   vusb33-supply = <_vusb_reg>;
+   status = "disabled";
+   };
+};
-- 
1.7.9.5

[PATCH v2,3/5] dt-bindings: mtu3: add devicetree bindings

[Chunfeng Yun]

add a DT binding doc for MediaTek USB3 DRD driver

Signed-off-by: Chunfeng Yun 
---
 Documentation/devicetree/bindings/usb/mtu3.txt |   85 
 1 file changed, 85 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/mtu3.txt

diff --git a/Documentation/devicetree/bindings/usb/mtu3.txt 
b/Documentation/devicetree/bindings/usb/mtu3.txt
new file mode 100644
index 000..571ae8b
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/mtu3.txt
@@ -0,0 +1,85 @@
+The device node for Mediatek USB3.0 DRD controller
+
+Required properties:
+ - compatible : should be "mediatek,mt8173-mtu3"
+ - reg : specifies physical base address and size of the registers
+ - reg-names: should be "mac" for device IP and "ippc" for IP port control
+ - interrupts : interrupt used by the device IP
+ - power-domains : a phandle to USB power domain node to control USB's
+   mtcmos
+ - vusb33-supply : regulator of USB avdd3.3v
+ - clocks : a list of phandle + clock-specifier pairs, one for each
+   entry in clock-names
+ - clock-names : must contain "sys_ck" for clock of controller;
+   "wakeup_deb_p0" and "wakeup_deb_p1" are optional, they are
+   depends on "mediatek,enable-wakeup"
+ - phys : a list of phandle + phy specifier pairs
+ - dr_mode : should be one of "host", "peripheral" or "otg",
+   refer to usb/generic.txt
+
+Optional properties:
+ - #address-cells, #size-cells : should be '2' if the device has sub-nodes
+   with 'reg' property
+ - ranges : allows valid 1:1 translation between child's address space and
+   parent's address space
+ - extcon : external connector for vbus and idpin changes detection, needed
+   when supports dual-role mode.
+ - vbus-supply : reference to the VBUS regulator, needed when supports
+   dual-role mode.
+ - pinctl-names : a pinctrl state named "default" must be defined,
+   "id_float" and "id_ground" are optinal which depends on
+   "mediatek,enable-manual-drd"
+ - pinctrl-0 : pin control group
+   See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+
+ - maximum-speed : valid arguments are "super-speed", "high-speed" and
+   "full-speed"; refer to usb/generic.txt
+ - enable-manual-drd : supports manual dual-role switch via sysfs; only used
+   when receptacle is TYPE-A and also wants to support dual-role mode.
+ - mediatek,enable-wakeup : supports ip sleep wakeup used by host mode
+ - mediatek,syscon-wakeup : phandle to syscon used to access USB wakeup
+   control register, it depends on "mediatek,enable-wakeup".
+
+Sub-nodes:
+The xhci should be added as subnode to mtu3 as shown in the following example
+if host mode is enabled. The DT binding details of xhci can be found in:
+Documentation/devicetree/bindings/usb/mt8173-xhci.txt
+
+Example:
+ssusb: usb@11271000 {
+   compatible = "mediatek,mt8173-mtu3";
+   reg = <0 0x11271000 0 0x3000>,
+ <0 0x11280700 0 0x0100>;
+   reg-names = "mac", "ippc";
+   interrupts = ;
+   phys = <_port0 PHY_TYPE_USB3>,
+  <_port1 PHY_TYPE_USB2>;
+   power-domains = < MT8173_POWER_DOMAIN_USB>;
+   clocks = < CLK_TOP_USB30_SEL>,
+< CLK_PERI_USB0>,
+< CLK_PERI_USB1>;
+   clock-names = "sys_ck",
+ "wakeup_deb_p0",
+ "wakeup_deb_p1";
+   vusb33-supply = <_vusb_reg>;
+   vbus-supply = <_p0_vbus>;
+   extcon = <_usb>;
+   dr_mode = "otg";
+   mediatek,enable-wakeup;
+   mediatek,syscon-wakeup = <>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   status = "disabled";
+
+   usb_host: xhci@1127 {
+   compatible = "mediatek,mt8173-xhci";
+   reg = <0 0x1127 0 0x1000>;
+   interrupts = ;
+   power-domains = < MT8173_POWER_DOMAIN_USB>;
+   clocks = < CLK_TOP_USB30_SEL>;
+   clock-names = "sys_ck";
+   vusb33-supply = <_vusb_reg>;
+   status = "disabled";
+   };
+};
-- 
1.7.9.5

Re: [PATCH] mtd: Replace if and BUG with BUG_ON

[Julia Lawall]

On Mon, 30 May 2016, Ezequiel Garcia wrote:

> Hi Amitoj,
> 
> Thanks for your patch.
> 
> On 28 May 2016 at 13:41, Amitoj Kaur Chawla  wrote:
> > Replace if condition and BUG() with a BUG_ON having the conditional
> > expression of the if statement as argument.
> >
> 
> We usually want commit messages that tell us *why* you are doing the
> change: what are you fixing, or what are you improving, and what
> possible side-effects it may have.
> 
> This commit log explains what the code does, but we can clearly see
> that, so it's not useful.
> 
> > The Coccinelle semantic patch used to make this change is as follows:
> > @@ expression E,f; @@
> >
> > (
> >   if (<+... f(...) ...+>) { BUG(); }
> > |
> > - if (E) { BUG(); }
> > + BUG_ON(E);
> > )
> >
> > Signed-off-by: Amitoj Kaur Chawla 
> > ---
> >  drivers/mtd/ssfdc.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/mtd/ssfdc.c b/drivers/mtd/ssfdc.c
> > index daf82ba..41b13d1 100644
> > --- a/drivers/mtd/ssfdc.c
> > +++ b/drivers/mtd/ssfdc.c
> > @@ -380,8 +380,7 @@ static int ssfdcr_readsect(struct mtd_blktrans_dev *dev,
> > " block_addr=%d\n", logic_sect_no, sectors_per_block, 
> > offset,
> > block_address);
> >
> > -   if (block_address >= ssfdc->map_len)
> > -   BUG();
> > +   BUG_ON(block_address >= ssfdc->map_len);
> >
> 
> I don't want to be rude, but I wonder if there's any value at all in
> such a patch. It barely improves readability, it barely reduces the
> LoC, yet it consumes developer time, maintainer time, and changes git
> per-line authorship (used in git blame).

Actually, I think that this particular patch does improve readability a 
bit.  Scanning straight down the code is easier than looking under an if.
Also, git blame now has a way to go back in history (although I don't 
remember what it is), so the argument that cleaning up the code makes it 
very difficult to find why the nontrivial part of the code is as it is 
doesn't completely hold any more.

julia

Re: [PATCH] mtd: Replace if and BUG with BUG_ON

[Julia Lawall]

On Mon, 30 May 2016, Ezequiel Garcia wrote:

> Hi Amitoj,
> 
> Thanks for your patch.
> 
> On 28 May 2016 at 13:41, Amitoj Kaur Chawla  wrote:
> > Replace if condition and BUG() with a BUG_ON having the conditional
> > expression of the if statement as argument.
> >
> 
> We usually want commit messages that tell us *why* you are doing the
> change: what are you fixing, or what are you improving, and what
> possible side-effects it may have.
> 
> This commit log explains what the code does, but we can clearly see
> that, so it's not useful.
> 
> > The Coccinelle semantic patch used to make this change is as follows:
> > @@ expression E,f; @@
> >
> > (
> >   if (<+... f(...) ...+>) { BUG(); }
> > |
> > - if (E) { BUG(); }
> > + BUG_ON(E);
> > )
> >
> > Signed-off-by: Amitoj Kaur Chawla 
> > ---
> >  drivers/mtd/ssfdc.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/mtd/ssfdc.c b/drivers/mtd/ssfdc.c
> > index daf82ba..41b13d1 100644
> > --- a/drivers/mtd/ssfdc.c
> > +++ b/drivers/mtd/ssfdc.c
> > @@ -380,8 +380,7 @@ static int ssfdcr_readsect(struct mtd_blktrans_dev *dev,
> > " block_addr=%d\n", logic_sect_no, sectors_per_block, 
> > offset,
> > block_address);
> >
> > -   if (block_address >= ssfdc->map_len)
> > -   BUG();
> > +   BUG_ON(block_address >= ssfdc->map_len);
> >
> 
> I don't want to be rude, but I wonder if there's any value at all in
> such a patch. It barely improves readability, it barely reduces the
> LoC, yet it consumes developer time, maintainer time, and changes git
> per-line authorship (used in git blame).

Actually, I think that this particular patch does improve readability a 
bit.  Scanning straight down the code is easier than looking under an if.
Also, git blame now has a way to go back in history (although I don't 
remember what it is), so the argument that cleaning up the code makes it 
very difficult to find why the nontrivial part of the code is as it is 
doesn't completely hold any more.

julia

RE: [PATCH v4] Axi-usb: Add support for 64-bit addressing.

[Nava kishore Manne]

Hi Shubhrajyoti,


Thanks for the review...

> >  /**
> > + * xudc_write64 - write 64bit value to device registers
> > + * @ep: pointer to the usb device endpoint structure.
> > + * @offset: register offset
> > + * @val: data to be written
> > + **/
> > +static void xudc_write64(struct xusb_ep *ep, u32 offset, u64 val) {
> > +   struct xusb_udc *udc = ep->udc;
> > +
> > +   udc->write_fn(udc->addr, offset, lower_32_bits(val));
> > +   udc->write_fn(udc->addr, offset+0x04, upper_32_bits(val));
> 
> can we move this to a single 64 bit write?

Initially I sent the patches with writeq() ,lo_hi_writeq()  later we decided to 
replace with write_fun().
The reason for this is lo_hi_writeq() always assumes a little-endian register, 
so it's broken if anyone builds this device with big-endian registers.
So replaced the 64bit calls with write_fun() as suggested by Arnd Bergmann. 
Hope it clears your query.
Please refer to the below thread

http://lkml.iu.edu/hypermail/linux/kernel/1604.2/02046.html 


Regards,
Navakishore.

RE: [PATCH v4] Axi-usb: Add support for 64-bit addressing.

[Nava kishore Manne]

Hi Shubhrajyoti,


Thanks for the review...

> >  /**
> > + * xudc_write64 - write 64bit value to device registers
> > + * @ep: pointer to the usb device endpoint structure.
> > + * @offset: register offset
> > + * @val: data to be written
> > + **/
> > +static void xudc_write64(struct xusb_ep *ep, u32 offset, u64 val) {
> > +   struct xusb_udc *udc = ep->udc;
> > +
> > +   udc->write_fn(udc->addr, offset, lower_32_bits(val));
> > +   udc->write_fn(udc->addr, offset+0x04, upper_32_bits(val));
> 
> can we move this to a single 64 bit write?

Initially I sent the patches with writeq() ,lo_hi_writeq()  later we decided to 
replace with write_fun().
The reason for this is lo_hi_writeq() always assumes a little-endian register, 
so it's broken if anyone builds this device with big-endian registers.
So replaced the 64bit calls with write_fun() as suggested by Arnd Bergmann. 
Hope it clears your query.
Please refer to the below thread

http://lkml.iu.edu/hypermail/linux/kernel/1604.2/02046.html 


Regards,
Navakishore.

Re: [PATCH v2 1/3] cpufreq: add resolve_freq driver callback

[Viresh Kumar]

On 30-05-16, 08:31, Steve Muckle wrote:
> My goal here was to have the system operate in this case in a manner
> that is obviously not optimized (running at fmax), so the platform owner
> realizes that the cpufreq driver doesn't fully support the schedutil
> governor.
> 
> I was originally going to just return an error code but that also means
> having to check for it which would be nice to avoid if possible on this
> fast path.

Okay, I get what you are saying.

But all we are doing here is to make things fast by not sending IPIs,
etc. That should *not* lead to a behavior where the frequency stays at
MAX all the time even if the driver doesn't provide this callback or
the freq-table.

If we just return the target_freq in this case instead of UINT_MAX,
the platform may eventually have some unnecessary IPIs, wakeups, etc,
but its frequency will still be switched properly.

Wouldn't that be a better choice ?

-- 
viresh

Re: [PATCH v2 1/3] cpufreq: add resolve_freq driver callback

[Viresh Kumar]

On 30-05-16, 08:31, Steve Muckle wrote:
> My goal here was to have the system operate in this case in a manner
> that is obviously not optimized (running at fmax), so the platform owner
> realizes that the cpufreq driver doesn't fully support the schedutil
> governor.
> 
> I was originally going to just return an error code but that also means
> having to check for it which would be nice to avoid if possible on this
> fast path.

Okay, I get what you are saying.

But all we are doing here is to make things fast by not sending IPIs,
etc. That should *not* lead to a behavior where the frequency stays at
MAX all the time even if the driver doesn't provide this callback or
the freq-table.

If we just return the target_freq in this case instead of UINT_MAX,
the platform may eventually have some unnecessary IPIs, wakeups, etc,
but its frequency will still be switched properly.

Wouldn't that be a better choice ?

-- 
viresh

Re: [PATCHv3 04/48] thermal: core: use dev.groups to manage always present tz attributes

[Keerthy]

On Tuesday 31 May 2016 03:45 AM, Eduardo Valentin wrote:

Thermal zones attributes are all being created using
device_create_file(). This has the disadvantage of making the code
complicated and sometimes we may miss the cleanup of them.

This patch starts to move the thermal zone sysfs attributes to the
dev.groups, so Linux device core manage them for us. For now, this patch
only moves those attributes are always present regardless of thermal
zone condition.

This change has also the advantage of cleaning up the thermal zone
parameters sysfs entries that are left unclean after device
registration.


I bisected. This is the commit which seems to break boot when thermal 
modules are built in kernel.




Cc: Zhang Rui 
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
  drivers/thermal/thermal_core.c | 86 --
  1 file changed, 33 insertions(+), 53 deletions(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 3ce7882..926442e 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -989,42 +989,46 @@ create_s32_tzp_attr(slope);
  create_s32_tzp_attr(offset);
  #undef create_s32_tzp_attr

+/*
+ * These are thermal zone device attributes that will always be present.
+ * All the attributes created for tzp (create_s32_tzp_attr) also are always
+ * present on the sysfs interface.
+ */
  static DEVICE_ATTR(type, 0444, type_show, NULL);
  static DEVICE_ATTR(temp, 0444, temp_show, NULL);
-static DEVICE_ATTR(mode, 0644, mode_show, mode_store);
-static DEVICE_ATTR(passive, S_IRUGO | S_IWUSR, passive_show, passive_store);
  static DEVICE_ATTR(policy, S_IRUGO | S_IWUSR, policy_show, policy_store);
  static DEVICE_ATTR(available_policies, S_IRUGO, available_policies_show, 
NULL);
-static DEVICE_ATTR(emul_temp, S_IWUSR, NULL, emul_temp_store);
  static DEVICE_ATTR(sustainable_power, S_IWUSR | S_IRUGO, 
sustainable_power_show,
   sustainable_power_store);

-static struct device_attribute *dev_tzp_attrs[] = {
-   _attr_sustainable_power,
-   _attr_k_po,
-   _attr_k_pu,
-   _attr_k_i,
-   _attr_k_d,
-   _attr_integral_cutoff,
-   _attr_slope,
-   _attr_offset,
-};
-
-static int create_tzp_attrs(struct device *dev)
-{
-   int i;
+/* These thermal zone device attributes are created based on conditions */
+static DEVICE_ATTR(mode, 0644, mode_show, mode_store);
+static DEVICE_ATTR(passive, S_IRUGO | S_IWUSR, passive_show, passive_store);
+static DEVICE_ATTR(emul_temp, S_IWUSR, NULL, emul_temp_store);

-   for (i = 0; i < ARRAY_SIZE(dev_tzp_attrs); i++) {
-   int ret;
-   struct device_attribute *dev_attr = dev_tzp_attrs[i];
+static struct attribute *thermal_zone_dev_attrs[] = {
+   _attr_type.attr,
+   _attr_temp.attr,
+   _attr_policy.attr,
+   _attr_available_policies.attr,
+   _attr_sustainable_power.attr,
+   _attr_k_po.attr,
+   _attr_k_pu.attr,
+   _attr_k_i.attr,
+   _attr_k_d.attr,
+   _attr_integral_cutoff.attr,
+   _attr_slope.attr,
+   _attr_offset.attr,
+};

-   ret = device_create_file(dev, dev_attr);
-   if (ret)
-   return ret;
-   }
+static struct attribute_group thermal_zone_attribute_group = {
+   .attrs = thermal_zone_dev_attrs,
+};

-   return 0;
-}
+static const struct attribute_group *thermal_zone_attribute_groups[] = {
+   _zone_attribute_group,
+   NULL
+};

  /**
   * power_actor_get_max_power() - get the maximum power that a cdev can consume
@@ -1846,6 +1850,9 @@ struct thermal_zone_device 
*thermal_zone_device_register(const char *type,
tz->trips = trips;
tz->passive_delay = passive_delay;
tz->polling_delay = polling_delay;
+
+   /* Add nodes that are always present via .groups */
+   tz->device.groups = thermal_zone_attribute_groups;
/* A new thermal zone needs to be updated anyway. */
atomic_set(>need_update, 1);

@@ -1892,29 +1899,6 @@ struct thermal_zone_device 
*thermal_zone_device_register(const char *type,
goto unregister;
}

-   result = device_create_file(>device, _attr_type);
-   if (result)
-   goto unregister;
-
-   result = device_create_file(>device, _attr_temp);
-   if (result)
-   goto unregister;
-
-   /* Create policy attribute */
-   result = device_create_file(>device, _attr_policy);
-   if (result)
-   goto unregister;
-
-   /* Create available_policies attribute */
-   result = device_create_file(>device, _attr_available_policies);
-   if (result)
-   goto unregister;
-
-   /* Add thermal zone params */
-   result = create_tzp_attrs(>device);
-   if (result)
-   goto unregister;
-
/* Update 'this' zone's 

Re: [PATCHv3 04/48] thermal: core: use dev.groups to manage always present tz attributes

[Keerthy]

On Tuesday 31 May 2016 03:45 AM, Eduardo Valentin wrote:

Thermal zones attributes are all being created using
device_create_file(). This has the disadvantage of making the code
complicated and sometimes we may miss the cleanup of them.

This patch starts to move the thermal zone sysfs attributes to the
dev.groups, so Linux device core manage them for us. For now, this patch
only moves those attributes are always present regardless of thermal
zone condition.

This change has also the advantage of cleaning up the thermal zone
parameters sysfs entries that are left unclean after device
registration.


I bisected. This is the commit which seems to break boot when thermal 
modules are built in kernel.




Cc: Zhang Rui 
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---
  drivers/thermal/thermal_core.c | 86 --
  1 file changed, 33 insertions(+), 53 deletions(-)

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 3ce7882..926442e 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -989,42 +989,46 @@ create_s32_tzp_attr(slope);
  create_s32_tzp_attr(offset);
  #undef create_s32_tzp_attr

+/*
+ * These are thermal zone device attributes that will always be present.
+ * All the attributes created for tzp (create_s32_tzp_attr) also are always
+ * present on the sysfs interface.
+ */
  static DEVICE_ATTR(type, 0444, type_show, NULL);
  static DEVICE_ATTR(temp, 0444, temp_show, NULL);
-static DEVICE_ATTR(mode, 0644, mode_show, mode_store);
-static DEVICE_ATTR(passive, S_IRUGO | S_IWUSR, passive_show, passive_store);
  static DEVICE_ATTR(policy, S_IRUGO | S_IWUSR, policy_show, policy_store);
  static DEVICE_ATTR(available_policies, S_IRUGO, available_policies_show, 
NULL);
-static DEVICE_ATTR(emul_temp, S_IWUSR, NULL, emul_temp_store);
  static DEVICE_ATTR(sustainable_power, S_IWUSR | S_IRUGO, 
sustainable_power_show,
   sustainable_power_store);

-static struct device_attribute *dev_tzp_attrs[] = {
-   _attr_sustainable_power,
-   _attr_k_po,
-   _attr_k_pu,
-   _attr_k_i,
-   _attr_k_d,
-   _attr_integral_cutoff,
-   _attr_slope,
-   _attr_offset,
-};
-
-static int create_tzp_attrs(struct device *dev)
-{
-   int i;
+/* These thermal zone device attributes are created based on conditions */
+static DEVICE_ATTR(mode, 0644, mode_show, mode_store);
+static DEVICE_ATTR(passive, S_IRUGO | S_IWUSR, passive_show, passive_store);
+static DEVICE_ATTR(emul_temp, S_IWUSR, NULL, emul_temp_store);

-   for (i = 0; i < ARRAY_SIZE(dev_tzp_attrs); i++) {
-   int ret;
-   struct device_attribute *dev_attr = dev_tzp_attrs[i];
+static struct attribute *thermal_zone_dev_attrs[] = {
+   _attr_type.attr,
+   _attr_temp.attr,
+   _attr_policy.attr,
+   _attr_available_policies.attr,
+   _attr_sustainable_power.attr,
+   _attr_k_po.attr,
+   _attr_k_pu.attr,
+   _attr_k_i.attr,
+   _attr_k_d.attr,
+   _attr_integral_cutoff.attr,
+   _attr_slope.attr,
+   _attr_offset.attr,
+};

-   ret = device_create_file(dev, dev_attr);
-   if (ret)
-   return ret;
-   }
+static struct attribute_group thermal_zone_attribute_group = {
+   .attrs = thermal_zone_dev_attrs,
+};

-   return 0;
-}
+static const struct attribute_group *thermal_zone_attribute_groups[] = {
+   _zone_attribute_group,
+   NULL
+};

  /**
   * power_actor_get_max_power() - get the maximum power that a cdev can consume
@@ -1846,6 +1850,9 @@ struct thermal_zone_device 
*thermal_zone_device_register(const char *type,
tz->trips = trips;
tz->passive_delay = passive_delay;
tz->polling_delay = polling_delay;
+
+   /* Add nodes that are always present via .groups */
+   tz->device.groups = thermal_zone_attribute_groups;
/* A new thermal zone needs to be updated anyway. */
atomic_set(>need_update, 1);

@@ -1892,29 +1899,6 @@ struct thermal_zone_device 
*thermal_zone_device_register(const char *type,
goto unregister;
}

-   result = device_create_file(>device, _attr_type);
-   if (result)
-   goto unregister;
-
-   result = device_create_file(>device, _attr_temp);
-   if (result)
-   goto unregister;
-
-   /* Create policy attribute */
-   result = device_create_file(>device, _attr_policy);
-   if (result)
-   goto unregister;
-
-   /* Create available_policies attribute */
-   result = device_create_file(>device, _attr_available_policies);
-   if (result)
-   goto unregister;
-
-   /* Add thermal zone params */
-   result = create_tzp_attrs(>device);
-   if (result)
-   goto unregister;
-
/* Update 'this' zone's governor information */

[RFC 1/4] Documentation: hid: Intel ISH HID document

[Srinivas Pandruvada]

Document explaining ISH HID operation and implementation.

Signed-off-by: Srinivas Pandruvada 
---
 Documentation/hid/intel-ish-hid.txt | 375 
 1 file changed, 375 insertions(+)
 create mode 100644 Documentation/hid/intel-ish-hid.txt

diff --git a/Documentation/hid/intel-ish-hid.txt 
b/Documentation/hid/intel-ish-hid.txt
new file mode 100644
index 000..83a636e
--- /dev/null
+++ b/Documentation/hid/intel-ish-hid.txt
@@ -0,0 +1,375 @@
+Intel Integrated Sensor Hub (ISH)
+===
+
+A sensor hub enables the ability to offload sensor polling and algorithm
+processing to a dedicated low power co-processor. This allows the core
+processor to go into low power modes more often, resulting in the increased
+battery life.
+There are many vendors providing external sensor hubs confirming to HID
+Sensor usage tables, and used in several tablets, 2 in 1 convertible laptops
+and embedded products. Linux had this support since Linux 3.9.
+
+Intel® introduced integrated sensor hubs as a part of the SoC starting from
+Cherry Trail and now supported on multiple generations of CPU packages. There
+are many commercial devices already shipped with Integrated Sensor Hubs (ISH).
+These ISH also comply to HID sensor specification, but the  difference is the
+transport protocol used for communication. The current external sensor hubs
+mainly use HID over i2C or USB. But ISH doesn't use either i2c or USB.
+
+This document provides an overview of transport protocol and how it is
+implemented.
+
+
+ISH Implementation: Block Diagram
+
+---
+   |  User Space Applications  |
+---
+
+IIO ABI
+--
+   |  IIO Sensor Drivers |
+--
+--
+   |IIO core |
+--
+--
+   |   HID Sensor Hub MFD|
+--
+--
+   |   HID Core  |
+--
+--
+   |   HID over ISH Client   |
+--
+--
+   |   ISH Client over ISHTP |
+--
+--
+   |   ISH Transport (ISHTP) |
+--
+--
+   |  IPC Drivers|
+--
+OS
+   PCI -
+Hardware + Firmware
+
+   | ISH Hardware/Firmware(FW) |
+
+
+--
+
+High level processing in above blocks:
+
+---
+Hardware Interface
+The ISH is exposed as "Non-VGA unclassified PCI device" to the host. The PCI
+product and vendor IDs are changed from different generations of processors. So
+the source code which enumerate drivers needs to update from generation to
+generation.
+
+---
+Inter Processor Communication (IPC) driver:
+Location: drivers/hid/intel-ish-hid/ipc
+
+The IPC message used memory mapped I/O. The registers are defined in
+hw-ish-regs.h.
+
+IPC/FW message types
+There are two types of messages, one for management of link and other messages
+are to and from transport layers.
+
+TX and RX of Transport messages:
+A set of memory mapped register offers support of multi byte messages TX and
+RX (E.g.IPC_REG_ISH2HOST_MSG, IPC_REG_HOST2ISH_MSG). The messaging uses
+doorbell register to trigger processing on client and server side.
+The IPC layer maintains internal queues to sequence messages and send them in
+order to the FW. Optionally the caller can register handler to get notification
+of completion.
+
+Transport layer interface
+To abstract HW level IPC communication a set of callbacks are registered.
+The transport layer uses them to send and receive messages.
+Refer to  struct ishtp_hw_ops for callbacks.
+
+---
+ISH Transport layer
+Location: drivers/hid/intel-ish-hid/ishtp/
+
+A Generic Transport Layer
+The transport layer is a bi-directional protocol, which defines:
+- Set of commands to start, stop, connect, disconnect and flow control
+(ishtp/hbm.h) for details
+- A flow control mechanism to avoid buffer overflows
+
+This protocol resembles bus messages described in the following document:
+http://www.intel.com/content/dam/www/public/us/en/documents/technical-\
+specifications/dcmi-hi-1-0-spec.pdf
+Chater 7: Bus Message Layer
+
+DMA
+The transport layer allocate 1 MB TX and 1 MB RX buffer. This buffer is divided
+into slots of 4K buffer. This buffer is shared among all connected clients.
+So when a message is to be sent or received by a client, it finds an empty
+slot and either fill 

[RFC 4/4] hid: intel-ish-hid: ISH HID client driver

[Srinivas Pandruvada]

From: Daniel Drubin 

This driver is responsible for implementing ISH HID client, which
gets HID description and report. Once it has completely gets
report descriptors, it registers as a HID LL drivers. This implements
necessary callbacks so that it can be used by HID sensor hub driver.

Signed-off-by: Srinivas Pandruvada 
---
 drivers/hid/intel-ish-hid/Makefile   |   4 +
 drivers/hid/intel-ish-hid/ishtp-hid-client.c | 672 +++
 drivers/hid/intel-ish-hid/ishtp-hid.c| 201 
 drivers/hid/intel-ish-hid/ishtp-hid.h| 157 +++
 4 files changed, 1034 insertions(+)
 create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid-client.c
 create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid.c
 create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid.h

diff --git a/drivers/hid/intel-ish-hid/Makefile 
b/drivers/hid/intel-ish-hid/Makefile
index 2c83cb9..6727c66 100644
--- a/drivers/hid/intel-ish-hid/Makefile
+++ b/drivers/hid/intel-ish-hid/Makefile
@@ -13,4 +13,8 @@ obj-$(CONFIG_INTEL_ISH_HID_IPC) += intel-ish-ipc.o
 intel-ish-ipc-objs := ipc/ipc.o
 intel-ish-ipc-objs += ipc/pci-ish.o
 
+obj-$(CONFIG_INTEL_ISH_HID) += intel-ishtp-hid.o
+intel-ishtp-hid-objs := ishtp-hid.o
+intel-ishtp-hid-objs += ishtp-hid-client.o
+
 ccflags-y += -Idrivers/hid/intel-ish-hid/ishtp
diff --git a/drivers/hid/intel-ish-hid/ishtp-hid-client.c 
b/drivers/hid/intel-ish-hid/ishtp-hid-client.c
new file mode 100644
index 000..5d22be6
--- /dev/null
+++ b/drivers/hid/intel-ish-hid/ishtp-hid-client.c
@@ -0,0 +1,672 @@
+/*
+ * ISHTP client driver for HID (ISH)
+ *
+ * Copyright (c) 2014-2016, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#include 
+#include 
+#include "ishtp/ishtp-dev.h"
+#include "ishtp/client.h"
+#include "ishtp-hid.h"
+
+/* Rx ring buffer pool size */
+#define HID_CL_RX_RING_SIZE32
+#define HID_CL_TX_RING_SIZE16
+
+/**
+ * report_bad_packets() - Report bad packets
+ * @hid_ishtp_cl:  Client instance to get stats
+ * @recv_buf:  Raw received host interface message
+ * @cur_pos:   Current position index in payload
+ * @payload_len:   Length of payload expected
+ *
+ * Dumps error in case bad packet is received
+ */
+static void report_bad_packet(struct ishtp_cl *hid_ishtp_cl, void *recv_buf,
+ size_t cur_pos,  size_t payload_len)
+{
+   struct hostif_msg *recv_msg = recv_buf;
+   struct ishtp_cl_data *client_data = hid_ishtp_cl->client_data;
+
+   dev_err(_ishtp_cl->device->dev, "[hid-ish]: BAD packet %02X\n"
+   "total_bad=%u cur_pos=%u\n"
+   "[%02X %02X %02X %02X]\n"
+   "payload_len=%u\n"
+   "multi_packet_cnt=%u\n"
+   "is_response=%02X\n",
+   recv_msg->hdr.command, client_data->bad_recv_cnt,
+   (unsigned int)cur_pos,
+   ((unsigned char *)recv_msg)[0], ((unsigned char *)recv_msg)[1],
+   ((unsigned char *)recv_msg)[2], ((unsigned char *)recv_msg)[3],
+   (unsigned int)payload_len, client_data->multi_packet_cnt,
+   recv_msg->hdr.command & ~CMD_MASK);
+}
+
+/**
+ * process_recv() - Received and parse incoming packet
+ * @hid_ishtp_cl:  Client instance to get stats
+ * @recv_buf:  Raw received host interface message
+ * @data_len:  length of the message
+ *
+ * Parse the incoming packet. If it is a response packet then it will update
+ * per instance flags and wake up the caller waiting to for the response.
+ */
+static void process_recv(struct ishtp_cl *hid_ishtp_cl, void *recv_buf,
+size_t data_len)
+{
+   struct hostif_msg *recv_msg;
+   unsigned char *payload;
+   struct device_info *dev_info;
+   int i, j;
+   size_t  payload_len, total_len, cur_pos;
+   int report_type;
+   struct report_list *reports_list;
+   char *reports;
+   size_t report_len;
+   struct ishtp_cl_data *client_data = hid_ishtp_cl->client_data;
+
+   if (data_len < sizeof(struct hostif_msg_hdr)) {
+   dev_err(_ishtp_cl->device->dev,
+   "[hid-ish]: error, received %u which is "
+   "less than data header %u\n",
+   (unsigned int)data_len,
+   (unsigned int)sizeof(struct hostif_msg_hdr));
+   ++client_data->bad_recv_cnt;
+   ish_hw_reset(hid_ishtp_cl->dev);
+   return;
+   }
+
+   

[RFC 1/4] Documentation: hid: Intel ISH HID document

[Srinivas Pandruvada]

Document explaining ISH HID operation and implementation.

Signed-off-by: Srinivas Pandruvada 
---
 Documentation/hid/intel-ish-hid.txt | 375 
 1 file changed, 375 insertions(+)
 create mode 100644 Documentation/hid/intel-ish-hid.txt

diff --git a/Documentation/hid/intel-ish-hid.txt 
b/Documentation/hid/intel-ish-hid.txt
new file mode 100644
index 000..83a636e
--- /dev/null
+++ b/Documentation/hid/intel-ish-hid.txt
@@ -0,0 +1,375 @@
+Intel Integrated Sensor Hub (ISH)
+===
+
+A sensor hub enables the ability to offload sensor polling and algorithm
+processing to a dedicated low power co-processor. This allows the core
+processor to go into low power modes more often, resulting in the increased
+battery life.
+There are many vendors providing external sensor hubs confirming to HID
+Sensor usage tables, and used in several tablets, 2 in 1 convertible laptops
+and embedded products. Linux had this support since Linux 3.9.
+
+Intel® introduced integrated sensor hubs as a part of the SoC starting from
+Cherry Trail and now supported on multiple generations of CPU packages. There
+are many commercial devices already shipped with Integrated Sensor Hubs (ISH).
+These ISH also comply to HID sensor specification, but the  difference is the
+transport protocol used for communication. The current external sensor hubs
+mainly use HID over i2C or USB. But ISH doesn't use either i2c or USB.
+
+This document provides an overview of transport protocol and how it is
+implemented.
+
+
+ISH Implementation: Block Diagram
+
+---
+   |  User Space Applications  |
+---
+
+IIO ABI
+--
+   |  IIO Sensor Drivers |
+--
+--
+   |IIO core |
+--
+--
+   |   HID Sensor Hub MFD|
+--
+--
+   |   HID Core  |
+--
+--
+   |   HID over ISH Client   |
+--
+--
+   |   ISH Client over ISHTP |
+--
+--
+   |   ISH Transport (ISHTP) |
+--
+--
+   |  IPC Drivers|
+--
+OS
+   PCI -
+Hardware + Firmware
+
+   | ISH Hardware/Firmware(FW) |
+
+
+--
+
+High level processing in above blocks:
+
+---
+Hardware Interface
+The ISH is exposed as "Non-VGA unclassified PCI device" to the host. The PCI
+product and vendor IDs are changed from different generations of processors. So
+the source code which enumerate drivers needs to update from generation to
+generation.
+
+---
+Inter Processor Communication (IPC) driver:
+Location: drivers/hid/intel-ish-hid/ipc
+
+The IPC message used memory mapped I/O. The registers are defined in
+hw-ish-regs.h.
+
+IPC/FW message types
+There are two types of messages, one for management of link and other messages
+are to and from transport layers.
+
+TX and RX of Transport messages:
+A set of memory mapped register offers support of multi byte messages TX and
+RX (E.g.IPC_REG_ISH2HOST_MSG, IPC_REG_HOST2ISH_MSG). The messaging uses
+doorbell register to trigger processing on client and server side.
+The IPC layer maintains internal queues to sequence messages and send them in
+order to the FW. Optionally the caller can register handler to get notification
+of completion.
+
+Transport layer interface
+To abstract HW level IPC communication a set of callbacks are registered.
+The transport layer uses them to send and receive messages.
+Refer to  struct ishtp_hw_ops for callbacks.
+
+---
+ISH Transport layer
+Location: drivers/hid/intel-ish-hid/ishtp/
+
+A Generic Transport Layer
+The transport layer is a bi-directional protocol, which defines:
+- Set of commands to start, stop, connect, disconnect and flow control
+(ishtp/hbm.h) for details
+- A flow control mechanism to avoid buffer overflows
+
+This protocol resembles bus messages described in the following document:
+http://www.intel.com/content/dam/www/public/us/en/documents/technical-\
+specifications/dcmi-hi-1-0-spec.pdf
+Chater 7: Bus Message Layer
+
+DMA
+The transport layer allocate 1 MB TX and 1 MB RX buffer. This buffer is divided
+into slots of 4K buffer. This buffer is shared among all connected clients.
+So when a message is to be sent or received by a client, it finds an empty
+slot and either fill for TX or send DMA address to FW for 

[RFC 4/4] hid: intel-ish-hid: ISH HID client driver

[Srinivas Pandruvada]

From: Daniel Drubin 

This driver is responsible for implementing ISH HID client, which
gets HID description and report. Once it has completely gets
report descriptors, it registers as a HID LL drivers. This implements
necessary callbacks so that it can be used by HID sensor hub driver.

Signed-off-by: Srinivas Pandruvada 
---
 drivers/hid/intel-ish-hid/Makefile   |   4 +
 drivers/hid/intel-ish-hid/ishtp-hid-client.c | 672 +++
 drivers/hid/intel-ish-hid/ishtp-hid.c| 201 
 drivers/hid/intel-ish-hid/ishtp-hid.h| 157 +++
 4 files changed, 1034 insertions(+)
 create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid-client.c
 create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid.c
 create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid.h

diff --git a/drivers/hid/intel-ish-hid/Makefile 
b/drivers/hid/intel-ish-hid/Makefile
index 2c83cb9..6727c66 100644
--- a/drivers/hid/intel-ish-hid/Makefile
+++ b/drivers/hid/intel-ish-hid/Makefile
@@ -13,4 +13,8 @@ obj-$(CONFIG_INTEL_ISH_HID_IPC) += intel-ish-ipc.o
 intel-ish-ipc-objs := ipc/ipc.o
 intel-ish-ipc-objs += ipc/pci-ish.o
 
+obj-$(CONFIG_INTEL_ISH_HID) += intel-ishtp-hid.o
+intel-ishtp-hid-objs := ishtp-hid.o
+intel-ishtp-hid-objs += ishtp-hid-client.o
+
 ccflags-y += -Idrivers/hid/intel-ish-hid/ishtp
diff --git a/drivers/hid/intel-ish-hid/ishtp-hid-client.c 
b/drivers/hid/intel-ish-hid/ishtp-hid-client.c
new file mode 100644
index 000..5d22be6
--- /dev/null
+++ b/drivers/hid/intel-ish-hid/ishtp-hid-client.c
@@ -0,0 +1,672 @@
+/*
+ * ISHTP client driver for HID (ISH)
+ *
+ * Copyright (c) 2014-2016, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#include 
+#include 
+#include "ishtp/ishtp-dev.h"
+#include "ishtp/client.h"
+#include "ishtp-hid.h"
+
+/* Rx ring buffer pool size */
+#define HID_CL_RX_RING_SIZE32
+#define HID_CL_TX_RING_SIZE16
+
+/**
+ * report_bad_packets() - Report bad packets
+ * @hid_ishtp_cl:  Client instance to get stats
+ * @recv_buf:  Raw received host interface message
+ * @cur_pos:   Current position index in payload
+ * @payload_len:   Length of payload expected
+ *
+ * Dumps error in case bad packet is received
+ */
+static void report_bad_packet(struct ishtp_cl *hid_ishtp_cl, void *recv_buf,
+ size_t cur_pos,  size_t payload_len)
+{
+   struct hostif_msg *recv_msg = recv_buf;
+   struct ishtp_cl_data *client_data = hid_ishtp_cl->client_data;
+
+   dev_err(_ishtp_cl->device->dev, "[hid-ish]: BAD packet %02X\n"
+   "total_bad=%u cur_pos=%u\n"
+   "[%02X %02X %02X %02X]\n"
+   "payload_len=%u\n"
+   "multi_packet_cnt=%u\n"
+   "is_response=%02X\n",
+   recv_msg->hdr.command, client_data->bad_recv_cnt,
+   (unsigned int)cur_pos,
+   ((unsigned char *)recv_msg)[0], ((unsigned char *)recv_msg)[1],
+   ((unsigned char *)recv_msg)[2], ((unsigned char *)recv_msg)[3],
+   (unsigned int)payload_len, client_data->multi_packet_cnt,
+   recv_msg->hdr.command & ~CMD_MASK);
+}
+
+/**
+ * process_recv() - Received and parse incoming packet
+ * @hid_ishtp_cl:  Client instance to get stats
+ * @recv_buf:  Raw received host interface message
+ * @data_len:  length of the message
+ *
+ * Parse the incoming packet. If it is a response packet then it will update
+ * per instance flags and wake up the caller waiting to for the response.
+ */
+static void process_recv(struct ishtp_cl *hid_ishtp_cl, void *recv_buf,
+size_t data_len)
+{
+   struct hostif_msg *recv_msg;
+   unsigned char *payload;
+   struct device_info *dev_info;
+   int i, j;
+   size_t  payload_len, total_len, cur_pos;
+   int report_type;
+   struct report_list *reports_list;
+   char *reports;
+   size_t report_len;
+   struct ishtp_cl_data *client_data = hid_ishtp_cl->client_data;
+
+   if (data_len < sizeof(struct hostif_msg_hdr)) {
+   dev_err(_ishtp_cl->device->dev,
+   "[hid-ish]: error, received %u which is "
+   "less than data header %u\n",
+   (unsigned int)data_len,
+   (unsigned int)sizeof(struct hostif_msg_hdr));
+   ++client_data->bad_recv_cnt;
+   ish_hw_reset(hid_ishtp_cl->dev);
+   return;
+   }
+
+   payload = recv_buf + sizeof(struct hostif_msg_hdr);
+   

[RFC 2/4] hid: intel_ish-hid: ISH Transport layer

[Srinivas Pandruvada]

From: Daniel Drubin 

The ISH transport layer (ishtp) is a bi-directional protocol implemented
on the top of PCI based inter processor communication layer. This layer
offers:
- Connection management
- Flow control with the firmware
- Multiple client sessions
- Client message transfer
- Client message reception
- DMA for RX and TX for fast data transfer

Refer to Documentation/hid/intel-ish-hid.txt for
overview of the functionality implemented in this layer.

Signed-off-by: Srinivas Pandruvada 
---
 drivers/hid/Kconfig |2 +
 drivers/hid/Makefile|2 +
 drivers/hid/intel-ish-hid/Kconfig   |   22 +
 drivers/hid/intel-ish-hid/Makefile  |   10 +
 drivers/hid/intel-ish-hid/ishtp/bus.c   |  670 
 drivers/hid/intel-ish-hid/ishtp/bus.h   |   99 +++
 drivers/hid/intel-ish-hid/ishtp/client.c| 1131 +++
 drivers/hid/intel-ish-hid/ishtp/client.h|  196 +
 drivers/hid/intel-ish-hid/ishtp/dma-if.c|  175 +
 drivers/hid/intel-ish-hid/ishtp/hbm.c   |  911 +
 drivers/hid/intel-ish-hid/ishtp/hbm.h   |  319 
 drivers/hid/intel-ish-hid/ishtp/init.c  |   94 +++
 drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h |  276 +++
 13 files changed, 3907 insertions(+)
 create mode 100644 drivers/hid/intel-ish-hid/Kconfig
 create mode 100644 drivers/hid/intel-ish-hid/Makefile
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/bus.c
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/bus.h
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/client.c
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/client.h
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/dma-if.c
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/hbm.c
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/hbm.h
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/init.c
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h

diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 5646ca4..56e69b4 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -944,4 +944,6 @@ source "drivers/hid/usbhid/Kconfig"
 
 source "drivers/hid/i2c-hid/Kconfig"
 
+source "drivers/hid/intel-ish-hid/Kconfig"
+
 endmenu
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index a2fb562..404b288 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -112,3 +112,5 @@ obj-$(CONFIG_USB_MOUSE) += usbhid/
 obj-$(CONFIG_USB_KBD)  += usbhid/
 
 obj-$(CONFIG_I2C_HID)  += i2c-hid/
+
+obj-$(CONFIG_INTEL_ISH_HID)+= intel-ish-hid/
diff --git a/drivers/hid/intel-ish-hid/Kconfig 
b/drivers/hid/intel-ish-hid/Kconfig
new file mode 100644
index 000..8914f3b
--- /dev/null
+++ b/drivers/hid/intel-ish-hid/Kconfig
@@ -0,0 +1,22 @@
+menu "Intel ISH HID support"
+   depends on X86 && PCI
+
+config INTEL_ISH_HID_TRANSPORT
+   bool
+   default n
+
+config INTEL_ISH_HID
+   bool "Intel Integrated Sensor Hub"
+   default n
+   select INTEL_ISH_HID_TRANSPORT
+   help
+ The Integrated Sensor Hub (ISH) enables the ability to offload
+ sensor polling and algorithm processing to a dedicated low power
+ processor in the chipset. This allows the core processor to go into
+ low power modes more often, resulting in the increased battery life.
+ The current processors that support ISH are: Cherrytrail, Skylake,
+ Broxton and Kaby Lake.
+
+ Say Y here if you want to support Intel ISH. If unsure, say N.
+
+endmenu
diff --git a/drivers/hid/intel-ish-hid/Makefile 
b/drivers/hid/intel-ish-hid/Makefile
new file mode 100644
index 000..a5eaa6e
--- /dev/null
+++ b/drivers/hid/intel-ish-hid/Makefile
@@ -0,0 +1,10 @@
+#
+# Makefile - Intel ISH HID drivers
+# Copyright (c) 2014-2016, Intel Corporation.
+#
+obj-$(CONFIG_INTEL_ISH_HID_TRANSPORT) += intel-ishtp.o
+intel-ishtp-objs := ishtp/init.o
+intel-ishtp-objs += ishtp/hbm.o
+intel-ishtp-objs += ishtp/client.o
+intel-ishtp-objs += ishtp/bus.o
+intel-ishtp-objs += ishtp/dma-if.o
diff --git a/drivers/hid/intel-ish-hid/ishtp/bus.c 
b/drivers/hid/intel-ish-hid/ishtp/bus.c
new file mode 100644
index 000..59e01114
--- /dev/null
+++ b/drivers/hid/intel-ish-hid/ishtp/bus.c
@@ -0,0 +1,670 @@
+/*
+ * ISHTP bus driver
+ *
+ * Copyright (c) 2012-2016, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include "bus.h"
+#include 

[RFC 2/4] hid: intel_ish-hid: ISH Transport layer

[Srinivas Pandruvada]

From: Daniel Drubin 

The ISH transport layer (ishtp) is a bi-directional protocol implemented
on the top of PCI based inter processor communication layer. This layer
offers:
- Connection management
- Flow control with the firmware
- Multiple client sessions
- Client message transfer
- Client message reception
- DMA for RX and TX for fast data transfer

Refer to Documentation/hid/intel-ish-hid.txt for
overview of the functionality implemented in this layer.

Signed-off-by: Srinivas Pandruvada 
---
 drivers/hid/Kconfig |2 +
 drivers/hid/Makefile|2 +
 drivers/hid/intel-ish-hid/Kconfig   |   22 +
 drivers/hid/intel-ish-hid/Makefile  |   10 +
 drivers/hid/intel-ish-hid/ishtp/bus.c   |  670 
 drivers/hid/intel-ish-hid/ishtp/bus.h   |   99 +++
 drivers/hid/intel-ish-hid/ishtp/client.c| 1131 +++
 drivers/hid/intel-ish-hid/ishtp/client.h|  196 +
 drivers/hid/intel-ish-hid/ishtp/dma-if.c|  175 +
 drivers/hid/intel-ish-hid/ishtp/hbm.c   |  911 +
 drivers/hid/intel-ish-hid/ishtp/hbm.h   |  319 
 drivers/hid/intel-ish-hid/ishtp/init.c  |   94 +++
 drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h |  276 +++
 13 files changed, 3907 insertions(+)
 create mode 100644 drivers/hid/intel-ish-hid/Kconfig
 create mode 100644 drivers/hid/intel-ish-hid/Makefile
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/bus.c
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/bus.h
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/client.c
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/client.h
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/dma-if.c
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/hbm.c
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/hbm.h
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/init.c
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h

diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 5646ca4..56e69b4 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -944,4 +944,6 @@ source "drivers/hid/usbhid/Kconfig"
 
 source "drivers/hid/i2c-hid/Kconfig"
 
+source "drivers/hid/intel-ish-hid/Kconfig"
+
 endmenu
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index a2fb562..404b288 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -112,3 +112,5 @@ obj-$(CONFIG_USB_MOUSE) += usbhid/
 obj-$(CONFIG_USB_KBD)  += usbhid/
 
 obj-$(CONFIG_I2C_HID)  += i2c-hid/
+
+obj-$(CONFIG_INTEL_ISH_HID)+= intel-ish-hid/
diff --git a/drivers/hid/intel-ish-hid/Kconfig 
b/drivers/hid/intel-ish-hid/Kconfig
new file mode 100644
index 000..8914f3b
--- /dev/null
+++ b/drivers/hid/intel-ish-hid/Kconfig
@@ -0,0 +1,22 @@
+menu "Intel ISH HID support"
+   depends on X86 && PCI
+
+config INTEL_ISH_HID_TRANSPORT
+   bool
+   default n
+
+config INTEL_ISH_HID
+   bool "Intel Integrated Sensor Hub"
+   default n
+   select INTEL_ISH_HID_TRANSPORT
+   help
+ The Integrated Sensor Hub (ISH) enables the ability to offload
+ sensor polling and algorithm processing to a dedicated low power
+ processor in the chipset. This allows the core processor to go into
+ low power modes more often, resulting in the increased battery life.
+ The current processors that support ISH are: Cherrytrail, Skylake,
+ Broxton and Kaby Lake.
+
+ Say Y here if you want to support Intel ISH. If unsure, say N.
+
+endmenu
diff --git a/drivers/hid/intel-ish-hid/Makefile 
b/drivers/hid/intel-ish-hid/Makefile
new file mode 100644
index 000..a5eaa6e
--- /dev/null
+++ b/drivers/hid/intel-ish-hid/Makefile
@@ -0,0 +1,10 @@
+#
+# Makefile - Intel ISH HID drivers
+# Copyright (c) 2014-2016, Intel Corporation.
+#
+obj-$(CONFIG_INTEL_ISH_HID_TRANSPORT) += intel-ishtp.o
+intel-ishtp-objs := ishtp/init.o
+intel-ishtp-objs += ishtp/hbm.o
+intel-ishtp-objs += ishtp/client.o
+intel-ishtp-objs += ishtp/bus.o
+intel-ishtp-objs += ishtp/dma-if.o
diff --git a/drivers/hid/intel-ish-hid/ishtp/bus.c 
b/drivers/hid/intel-ish-hid/ishtp/bus.c
new file mode 100644
index 000..59e01114
--- /dev/null
+++ b/drivers/hid/intel-ish-hid/ishtp/bus.c
@@ -0,0 +1,670 @@
+/*
+ * ISHTP bus driver
+ *
+ * Copyright (c) 2012-2016, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include "bus.h"
+#include "ishtp-dev.h"
+#include "client.h"
+#include "hbm.h"
+
+#define 

[RFC 3/4] hid: intel-ish-hid: ipc layer

[Srinivas Pandruvada]

From: Daniel Drubin 

This layer is responsible for
- Enumerating over PCI bus
- Inform FW about host readiness
- Provide HW interface to transport layer for control and messages
- Interrupt handling and routing

Signed-off-by: Srinivas Pandruvada 
---
 drivers/hid/intel-ish-hid/Kconfig   |   5 +
 drivers/hid/intel-ish-hid/Makefile  |   6 +
 drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h | 220 +
 drivers/hid/intel-ish-hid/ipc/hw-ish.h  |  71 +++
 drivers/hid/intel-ish-hid/ipc/ipc.c | 710 
 drivers/hid/intel-ish-hid/ipc/pci-ish.c | 238 ++
 drivers/hid/intel-ish-hid/ipc/utils.h   |  65 +++
 include/trace/events/intel_ish.h|  30 ++
 8 files changed, 1345 insertions(+)
 create mode 100644 drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h
 create mode 100644 drivers/hid/intel-ish-hid/ipc/hw-ish.h
 create mode 100644 drivers/hid/intel-ish-hid/ipc/ipc.c
 create mode 100644 drivers/hid/intel-ish-hid/ipc/pci-ish.c
 create mode 100644 drivers/hid/intel-ish-hid/ipc/utils.h
 create mode 100644 include/trace/events/intel_ish.h

diff --git a/drivers/hid/intel-ish-hid/Kconfig 
b/drivers/hid/intel-ish-hid/Kconfig
index 8914f3b..88967a1 100644
--- a/drivers/hid/intel-ish-hid/Kconfig
+++ b/drivers/hid/intel-ish-hid/Kconfig
@@ -5,10 +5,15 @@ config INTEL_ISH_HID_TRANSPORT
bool
default n
 
+config INTEL_ISH_HID_IPC
+   bool
+   default n
+
 config INTEL_ISH_HID
bool "Intel Integrated Sensor Hub"
default n
select INTEL_ISH_HID_TRANSPORT
+   select INTEL_ISH_HID_IPC
help
  The Integrated Sensor Hub (ISH) enables the ability to offload
  sensor polling and algorithm processing to a dedicated low power
diff --git a/drivers/hid/intel-ish-hid/Makefile 
b/drivers/hid/intel-ish-hid/Makefile
index a5eaa6e..2c83cb9 100644
--- a/drivers/hid/intel-ish-hid/Makefile
+++ b/drivers/hid/intel-ish-hid/Makefile
@@ -8,3 +8,9 @@ intel-ishtp-objs += ishtp/hbm.o
 intel-ishtp-objs += ishtp/client.o
 intel-ishtp-objs += ishtp/bus.o
 intel-ishtp-objs += ishtp/dma-if.o
+
+obj-$(CONFIG_INTEL_ISH_HID_IPC) += intel-ish-ipc.o
+intel-ish-ipc-objs := ipc/ipc.o
+intel-ish-ipc-objs += ipc/pci-ish.o
+
+ccflags-y += -Idrivers/hid/intel-ish-hid/ishtp
diff --git a/drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h 
b/drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h
new file mode 100644
index 000..f6eac6d
--- /dev/null
+++ b/drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h
@@ -0,0 +1,220 @@
+/*
+ * ISH registers definitions
+ *
+ * Copyright (c) 2012-2016, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#ifndef _ISHTP_ISH_REGS_H_
+#define _ISHTP_ISH_REGS_H_
+
+
+/*** IPC PCI Offsets and sizes ***/
+/* ISH IPC Base Address */
+#define IPC_REG_BASE   0x
+/* Peripheral Interrupt Status Register */
+#define IPC_REG_PISR_CHV_AB  (IPC_REG_BASE + 0x00)
+/* Peripheral Interrupt Mask Register */
+#define IPC_REG_PIMR_CHV_AB  (IPC_REG_BASE + 0x04)
+/*BXT, CHV_K0*/
+/*Peripheral Interrupt Status Register */
+#define IPC_REG_PISR_BXT(IPC_REG_BASE + 0x0C)
+/*Peripheral Interrupt Mask Register */
+#define IPC_REG_PIMR_BXT(IPC_REG_BASE + 0x08)
+/***/
+/* ISH Host Firmware status Register */
+#define IPC_REG_ISH_HOST_FWSTS (IPC_REG_BASE + 0x34)
+/* Host Communication Register */
+#define IPC_REG_HOST_COMM  (IPC_REG_BASE + 0x38)
+/* Reset register */
+#define IPC_REG_ISH_RST(IPC_REG_BASE + 0x44)
+
+/* Inbound doorbell register Host to ISH */
+#define IPC_REG_HOST2ISH_DRBL  (IPC_REG_BASE + 0x48)
+/* Outbound doorbell register ISH to Host */
+#define IPC_REG_ISH2HOST_DRBL  (IPC_REG_BASE + 0x54)
+/* ISH to HOST message registers */
+#define IPC_REG_ISH2HOST_MSG   (IPC_REG_BASE + 0x60)
+/* HOST to ISH message registers */
+#define IPC_REG_HOST2ISH_MSG   (IPC_REG_BASE + 0xE0)
+/* REMAP2 to enable DMA (D3 RCR) */
+#defineIPC_REG_ISH_RMP2(IPC_REG_BASE + 0x368)
+
+#defineIPC_REG_MAX (IPC_REG_BASE + 0x400)
+
+/*** register bits - HISR ***/
+/* bit corresponds HOST2ISH interrupt in PISR and PIMR registers */
+#define IPC_INT_HOST2ISH_BIT(1<<0)
+/***/
+/*CHV_A0, CHV_B0*/
+/* bit corresponds ISH2HOST interrupt in PISR and PIMR registers */
+#define IPC_INT_ISH2HOST_BIT_CHV_AB(1<<3)
+/*BXT, CHV_K0*/
+/* bit corresponds ISH2HOST interrupt in PISR and PIMR registers */
+#define 

[RFC 3/4] hid: intel-ish-hid: ipc layer

[Srinivas Pandruvada]

From: Daniel Drubin 

This layer is responsible for
- Enumerating over PCI bus
- Inform FW about host readiness
- Provide HW interface to transport layer for control and messages
- Interrupt handling and routing

Signed-off-by: Srinivas Pandruvada 
---
 drivers/hid/intel-ish-hid/Kconfig   |   5 +
 drivers/hid/intel-ish-hid/Makefile  |   6 +
 drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h | 220 +
 drivers/hid/intel-ish-hid/ipc/hw-ish.h  |  71 +++
 drivers/hid/intel-ish-hid/ipc/ipc.c | 710 
 drivers/hid/intel-ish-hid/ipc/pci-ish.c | 238 ++
 drivers/hid/intel-ish-hid/ipc/utils.h   |  65 +++
 include/trace/events/intel_ish.h|  30 ++
 8 files changed, 1345 insertions(+)
 create mode 100644 drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h
 create mode 100644 drivers/hid/intel-ish-hid/ipc/hw-ish.h
 create mode 100644 drivers/hid/intel-ish-hid/ipc/ipc.c
 create mode 100644 drivers/hid/intel-ish-hid/ipc/pci-ish.c
 create mode 100644 drivers/hid/intel-ish-hid/ipc/utils.h
 create mode 100644 include/trace/events/intel_ish.h

diff --git a/drivers/hid/intel-ish-hid/Kconfig 
b/drivers/hid/intel-ish-hid/Kconfig
index 8914f3b..88967a1 100644
--- a/drivers/hid/intel-ish-hid/Kconfig
+++ b/drivers/hid/intel-ish-hid/Kconfig
@@ -5,10 +5,15 @@ config INTEL_ISH_HID_TRANSPORT
bool
default n
 
+config INTEL_ISH_HID_IPC
+   bool
+   default n
+
 config INTEL_ISH_HID
bool "Intel Integrated Sensor Hub"
default n
select INTEL_ISH_HID_TRANSPORT
+   select INTEL_ISH_HID_IPC
help
  The Integrated Sensor Hub (ISH) enables the ability to offload
  sensor polling and algorithm processing to a dedicated low power
diff --git a/drivers/hid/intel-ish-hid/Makefile 
b/drivers/hid/intel-ish-hid/Makefile
index a5eaa6e..2c83cb9 100644
--- a/drivers/hid/intel-ish-hid/Makefile
+++ b/drivers/hid/intel-ish-hid/Makefile
@@ -8,3 +8,9 @@ intel-ishtp-objs += ishtp/hbm.o
 intel-ishtp-objs += ishtp/client.o
 intel-ishtp-objs += ishtp/bus.o
 intel-ishtp-objs += ishtp/dma-if.o
+
+obj-$(CONFIG_INTEL_ISH_HID_IPC) += intel-ish-ipc.o
+intel-ish-ipc-objs := ipc/ipc.o
+intel-ish-ipc-objs += ipc/pci-ish.o
+
+ccflags-y += -Idrivers/hid/intel-ish-hid/ishtp
diff --git a/drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h 
b/drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h
new file mode 100644
index 000..f6eac6d
--- /dev/null
+++ b/drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h
@@ -0,0 +1,220 @@
+/*
+ * ISH registers definitions
+ *
+ * Copyright (c) 2012-2016, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#ifndef _ISHTP_ISH_REGS_H_
+#define _ISHTP_ISH_REGS_H_
+
+
+/*** IPC PCI Offsets and sizes ***/
+/* ISH IPC Base Address */
+#define IPC_REG_BASE   0x
+/* Peripheral Interrupt Status Register */
+#define IPC_REG_PISR_CHV_AB  (IPC_REG_BASE + 0x00)
+/* Peripheral Interrupt Mask Register */
+#define IPC_REG_PIMR_CHV_AB  (IPC_REG_BASE + 0x04)
+/*BXT, CHV_K0*/
+/*Peripheral Interrupt Status Register */
+#define IPC_REG_PISR_BXT(IPC_REG_BASE + 0x0C)
+/*Peripheral Interrupt Mask Register */
+#define IPC_REG_PIMR_BXT(IPC_REG_BASE + 0x08)
+/***/
+/* ISH Host Firmware status Register */
+#define IPC_REG_ISH_HOST_FWSTS (IPC_REG_BASE + 0x34)
+/* Host Communication Register */
+#define IPC_REG_HOST_COMM  (IPC_REG_BASE + 0x38)
+/* Reset register */
+#define IPC_REG_ISH_RST(IPC_REG_BASE + 0x44)
+
+/* Inbound doorbell register Host to ISH */
+#define IPC_REG_HOST2ISH_DRBL  (IPC_REG_BASE + 0x48)
+/* Outbound doorbell register ISH to Host */
+#define IPC_REG_ISH2HOST_DRBL  (IPC_REG_BASE + 0x54)
+/* ISH to HOST message registers */
+#define IPC_REG_ISH2HOST_MSG   (IPC_REG_BASE + 0x60)
+/* HOST to ISH message registers */
+#define IPC_REG_HOST2ISH_MSG   (IPC_REG_BASE + 0xE0)
+/* REMAP2 to enable DMA (D3 RCR) */
+#defineIPC_REG_ISH_RMP2(IPC_REG_BASE + 0x368)
+
+#defineIPC_REG_MAX (IPC_REG_BASE + 0x400)
+
+/*** register bits - HISR ***/
+/* bit corresponds HOST2ISH interrupt in PISR and PIMR registers */
+#define IPC_INT_HOST2ISH_BIT(1<<0)
+/***/
+/*CHV_A0, CHV_B0*/
+/* bit corresponds ISH2HOST interrupt in PISR and PIMR registers */
+#define IPC_INT_ISH2HOST_BIT_CHV_AB(1<<3)
+/*BXT, CHV_K0*/
+/* bit corresponds ISH2HOST interrupt in PISR and PIMR registers */
+#define IPC_INT_ISH2HOST_BIT_BXT   (1<<0)
+/***/

[RFC 0/4] Intel Integrated Sensor Hub Support (ISH)

[Srinivas Pandruvada]

Starting from Cherrytrail, multiple generation of Intel processors offers
on package sensor hub. Several recent tablets, 2-in-1 convertible laptops
are using ISH instead of external sensor hubs. This resulted in lack of
support of sensor function like device rotation and auto backlight
adjustment. In addition, depending on the OEM implementation, support of ISH
is required to support low power sleep states.

The support of ISH on Linux platforms is not new. Android platforms with
Intel SoCs had this support for a while submitted by Daniel Drubin. 
This patcheset is reusing most of those changes with  clean up and
removing Android platform specific changes.

This series is tested on:
- Lenovo Yoga 260 with Skylake processor
- HP Pavilion x2 detachable with Cherrytrail 

The user mode ABI is still same as external sensor hubs using Linux
IIO. So existing user mode software should still work without change.
This series primarily brings in new HID transport used in ISH.

This series submitted as a RFC to try on several devices. We have 
received request from Linux users who wanted this support. So I hope all
those users try and give feedback.

Daniel Drubin (3):
  hid: intel_ish-hid: ISH Transport layer
  hid: intel-ish-hid: ipc layer
  hid: intel-ish-hid: ISH HID client driver

Srinivas Pandruvada (1):
  Documentation: hid: Intel ISH HID document

 Documentation/hid/intel-ish-hid.txt  |  375 +
 drivers/hid/Kconfig  |2 +
 drivers/hid/Makefile |2 +
 drivers/hid/intel-ish-hid/Kconfig|   27 +
 drivers/hid/intel-ish-hid/Makefile   |   20 +
 drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h  |  220 +
 drivers/hid/intel-ish-hid/ipc/hw-ish.h   |   71 ++
 drivers/hid/intel-ish-hid/ipc/ipc.c  |  710 
 drivers/hid/intel-ish-hid/ipc/pci-ish.c  |  238 ++
 drivers/hid/intel-ish-hid/ipc/utils.h|   65 ++
 drivers/hid/intel-ish-hid/ishtp-hid-client.c |  672 +++
 drivers/hid/intel-ish-hid/ishtp-hid.c|  201 +
 drivers/hid/intel-ish-hid/ishtp-hid.h|  157 
 drivers/hid/intel-ish-hid/ishtp/bus.c|  670 +++
 drivers/hid/intel-ish-hid/ishtp/bus.h|   99 +++
 drivers/hid/intel-ish-hid/ishtp/client.c | 1131 ++
 drivers/hid/intel-ish-hid/ishtp/client.h |  196 +
 drivers/hid/intel-ish-hid/ishtp/dma-if.c |  175 
 drivers/hid/intel-ish-hid/ishtp/hbm.c|  911 +
 drivers/hid/intel-ish-hid/ishtp/hbm.h|  319 
 drivers/hid/intel-ish-hid/ishtp/init.c   |   94 +++
 drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h  |  276 +++
 include/trace/events/intel_ish.h |   30 +
 23 files changed, 6661 insertions(+)
 create mode 100644 Documentation/hid/intel-ish-hid.txt
 create mode 100644 drivers/hid/intel-ish-hid/Kconfig
 create mode 100644 drivers/hid/intel-ish-hid/Makefile
 create mode 100644 drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h
 create mode 100644 drivers/hid/intel-ish-hid/ipc/hw-ish.h
 create mode 100644 drivers/hid/intel-ish-hid/ipc/ipc.c
 create mode 100644 drivers/hid/intel-ish-hid/ipc/pci-ish.c
 create mode 100644 drivers/hid/intel-ish-hid/ipc/utils.h
 create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid-client.c
 create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid.c
 create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid.h
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/bus.c
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/bus.h
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/client.c
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/client.h
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/dma-if.c
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/hbm.c
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/hbm.h
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/init.c
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h
 create mode 100644 include/trace/events/intel_ish.h

-- 
1.9.1

[RFC 0/4] Intel Integrated Sensor Hub Support (ISH)

[Srinivas Pandruvada]

Starting from Cherrytrail, multiple generation of Intel processors offers
on package sensor hub. Several recent tablets, 2-in-1 convertible laptops
are using ISH instead of external sensor hubs. This resulted in lack of
support of sensor function like device rotation and auto backlight
adjustment. In addition, depending on the OEM implementation, support of ISH
is required to support low power sleep states.

The support of ISH on Linux platforms is not new. Android platforms with
Intel SoCs had this support for a while submitted by Daniel Drubin. 
This patcheset is reusing most of those changes with  clean up and
removing Android platform specific changes.

This series is tested on:
- Lenovo Yoga 260 with Skylake processor
- HP Pavilion x2 detachable with Cherrytrail 

The user mode ABI is still same as external sensor hubs using Linux
IIO. So existing user mode software should still work without change.
This series primarily brings in new HID transport used in ISH.

This series submitted as a RFC to try on several devices. We have 
received request from Linux users who wanted this support. So I hope all
those users try and give feedback.

Daniel Drubin (3):
  hid: intel_ish-hid: ISH Transport layer
  hid: intel-ish-hid: ipc layer
  hid: intel-ish-hid: ISH HID client driver

Srinivas Pandruvada (1):
  Documentation: hid: Intel ISH HID document

 Documentation/hid/intel-ish-hid.txt  |  375 +
 drivers/hid/Kconfig  |2 +
 drivers/hid/Makefile |2 +
 drivers/hid/intel-ish-hid/Kconfig|   27 +
 drivers/hid/intel-ish-hid/Makefile   |   20 +
 drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h  |  220 +
 drivers/hid/intel-ish-hid/ipc/hw-ish.h   |   71 ++
 drivers/hid/intel-ish-hid/ipc/ipc.c  |  710 
 drivers/hid/intel-ish-hid/ipc/pci-ish.c  |  238 ++
 drivers/hid/intel-ish-hid/ipc/utils.h|   65 ++
 drivers/hid/intel-ish-hid/ishtp-hid-client.c |  672 +++
 drivers/hid/intel-ish-hid/ishtp-hid.c|  201 +
 drivers/hid/intel-ish-hid/ishtp-hid.h|  157 
 drivers/hid/intel-ish-hid/ishtp/bus.c|  670 +++
 drivers/hid/intel-ish-hid/ishtp/bus.h|   99 +++
 drivers/hid/intel-ish-hid/ishtp/client.c | 1131 ++
 drivers/hid/intel-ish-hid/ishtp/client.h |  196 +
 drivers/hid/intel-ish-hid/ishtp/dma-if.c |  175 
 drivers/hid/intel-ish-hid/ishtp/hbm.c|  911 +
 drivers/hid/intel-ish-hid/ishtp/hbm.h|  319 
 drivers/hid/intel-ish-hid/ishtp/init.c   |   94 +++
 drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h  |  276 +++
 include/trace/events/intel_ish.h |   30 +
 23 files changed, 6661 insertions(+)
 create mode 100644 Documentation/hid/intel-ish-hid.txt
 create mode 100644 drivers/hid/intel-ish-hid/Kconfig
 create mode 100644 drivers/hid/intel-ish-hid/Makefile
 create mode 100644 drivers/hid/intel-ish-hid/ipc/hw-ish-regs.h
 create mode 100644 drivers/hid/intel-ish-hid/ipc/hw-ish.h
 create mode 100644 drivers/hid/intel-ish-hid/ipc/ipc.c
 create mode 100644 drivers/hid/intel-ish-hid/ipc/pci-ish.c
 create mode 100644 drivers/hid/intel-ish-hid/ipc/utils.h
 create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid-client.c
 create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid.c
 create mode 100644 drivers/hid/intel-ish-hid/ishtp-hid.h
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/bus.c
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/bus.h
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/client.c
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/client.h
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/dma-if.c
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/hbm.c
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/hbm.h
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/init.c
 create mode 100644 drivers/hid/intel-ish-hid/ishtp/ishtp-dev.h
 create mode 100644 include/trace/events/intel_ish.h

-- 
1.9.1

Re: WMI driver no longer load after switching to generic UUID library

[Kui Zhang]

Thanks guys.

keyboard functions are working now.


kui.z

On Mon, May 30, 2016 at 7:40 AM, Andy Shevchenko
 wrote:
> On Mon, 2016-05-30 at 12:52 +0200, Bjørn Mork wrote:
>> How about the untested attached patch?
>>
>
> Facepalm.jpg!
>
> Good catch!
>
> The question is how it passed in our internal tree without being
> notified (it even included a lot of ACPI code updated)!?
>
> My explanation since I have no access to archive of internal mailing
> list is that I submitted 'cleaned up' version which brought that and
> wasn't tested.
>
> Anyway I just wrote a test module and is about to submit it with your
> fix in a series.
>
> Thanks!
>
>>
>> Bjørn
>>
>
> --
> Andy Shevchenko 
> Intel Finland Oy

Re: WMI driver no longer load after switching to generic UUID library

[Kui Zhang]

Thanks guys.

keyboard functions are working now.


kui.z

On Mon, May 30, 2016 at 7:40 AM, Andy Shevchenko
 wrote:
> On Mon, 2016-05-30 at 12:52 +0200, Bjørn Mork wrote:
>> How about the untested attached patch?
>>
>
> Facepalm.jpg!
>
> Good catch!
>
> The question is how it passed in our internal tree without being
> notified (it even included a lot of ACPI code updated)!?
>
> My explanation since I have no access to archive of internal mailing
> list is that I submitted 'cleaned up' version which brought that and
> wasn't tested.
>
> Anyway I just wrote a test module and is about to submit it with your
> fix in a series.
>
> Thanks!
>
>>
>> Bjørn
>>
>
> --
> Andy Shevchenko 
> Intel Finland Oy

Re: [PATCHv3 00/48] thermal: reorganizing thermal core

[Keerthy]

Hi Eduardo,

On Tuesday 31 May 2016 03:45 AM, Eduardo Valentin wrote:

Folks,

This is V3 of a patch series to improve thermal core. The idea
here is to reorganize the code and improve the way we
handle sysfs entries.

The change in behavior is that now, thermal zones with empty
.type will not be allowed to be registered. Also, the way
we handle scanf's return code is now checking for
number of successful inputs.

After this series, thermal core is split into the following files:
- thermal_sysfs.c: contains the functions handling the sysfs nodes
- thermal_helpers.c: groups functions that do not need to touch thermal
core internal data structures, such as internal lists, and list locks.
- thermal_core.c: functions to handle the lifecycle of the subsystem,
its governors, cooling devices, thermal zone devices, and their
interactions.

I don't expect any impact on userspace.



I applied the whole 48 patch series on top of mainline kernel.

I see boot crash when i have thermal modules built in kernel for 
dra7/dra72 boards.


dra7 bootlog: http://pastebin.ubuntu.com/16859184/

Regards,
Keerthy


Please give your inputs.

V2->V3:
- Included 8 extra patches to remove style issues on
(new) thermal core.

V1->V2:
- Removed all checkpatch issues in the existing code that was
moved/changed.

Rui, it would be great if you could review these earlier. I will be
sending two extra patch series on top of this one.

BR,

Eduardo Valentin (48):
   thermal: core: prevent zones with no types to be registered
   thermal: core: group thermal_zone DEVICE_ATTR's declarations
   thermal: core: group device_create_file() calls that are always
 created
   thermal: core: use dev.groups to manage always present tz attributes
   thermal: core: move emul_temp creation to tz->device.groups
   thermal: core: move mode attribute to tz->device.groups
   thermal: core: move passive attr to tz->device.groups
   thermal: core: improve power actor documentation
   thermal: core: move power actor code out of sysfs I/F section
   thermal: core: remove useless empty line
   thermal: core: fix style on remove_trip_attrs()
   thermal: core: move the trip attrs to the tz sysfs I/F section
   thermal: core: create tz->device.groups dynamically
   thermal: core: move trips attributes to tz->device.groups
   thermal: core: remove unnecessary device_remove() calls
   thermal: core: split passive_store
   thermal: core: split policy_store
   thermal: core: split available_policies_show()
   thermal: core: move to_thermal_zone() macro to header file
   thermal: core: treat correctly the return value of *scanf calls
   thermal: core: match parenthesis on code alignment
   thermal: core: move thermal_zone sysfs to thermal_sysfs.c
   thermal: core: move to_cooling_device macro to header file
   thermal: core: move cooling device sysfs to thermal_sysfs.c
   thermal: core: remove a couple of style issues on helpers
   thermal: core: introduce thermal_helpers.c
   thermal: core: group functions related to governor handling
   thermal: core: move idr handling to device management section
   thermal: core: small style fix on __unbind() helper
   thermal: core: move __unbind() helper to where it is used
   thermal: core: move bind_cdev() to where it is used
   thermal: core: move bind_tz() to where it is used
   thermal: core: fix couple of style issues on __bind() helper
   thermal: core: move __bind() to where it is used
   thermal: core: add inline to print_bind_err_msg()
   thermal: core: move notify to the zone update section
   thermal: core: add a comment describing the main update loop
   thermal: core: add a comment describing the power actor section
   thermal: core: add a comment describing the device management section
   thermal: sysfs: remove symbols of emul_temp when config is disabled
   thermal: core: remove FSF address in the GPL notice
   thermal: core: small style fix when checking for __find_governor()
   thermal: core: standardize line breaking alignment
   thermal: core: remove void function return statements
   thermal: core: remove style warnings and checks
   thermal: core: improve kerneldoc entry of
 thermal_cooling_device_unregister
   thermal: core: use kzalloc(sizeof(*ptr),...)
   thermal: sysfs: use kcalloc() instead of kzalloc()

  drivers/thermal/Makefile  |3 +-
  drivers/thermal/thermal_core.c| 1363 +
  drivers/thermal/thermal_core.h|   26 +
  drivers/thermal/thermal_helpers.c |  144 
  drivers/thermal/thermal_sysfs.c   |  752 
  include/linux/thermal.h   |2 +
  6 files changed, 1234 insertions(+), 1056 deletions(-)
  create mode 100644 drivers/thermal/thermal_helpers.c
  create mode 100644 drivers/thermal/thermal_sysfs.c

Re: [PATCHv3 00/48] thermal: reorganizing thermal core

[Keerthy]

Hi Eduardo,

On Tuesday 31 May 2016 03:45 AM, Eduardo Valentin wrote:

Folks,

This is V3 of a patch series to improve thermal core. The idea
here is to reorganize the code and improve the way we
handle sysfs entries.

The change in behavior is that now, thermal zones with empty
.type will not be allowed to be registered. Also, the way
we handle scanf's return code is now checking for
number of successful inputs.

After this series, thermal core is split into the following files:
- thermal_sysfs.c: contains the functions handling the sysfs nodes
- thermal_helpers.c: groups functions that do not need to touch thermal
core internal data structures, such as internal lists, and list locks.
- thermal_core.c: functions to handle the lifecycle of the subsystem,
its governors, cooling devices, thermal zone devices, and their
interactions.

I don't expect any impact on userspace.



I applied the whole 48 patch series on top of mainline kernel.

I see boot crash when i have thermal modules built in kernel for 
dra7/dra72 boards.


dra7 bootlog: http://pastebin.ubuntu.com/16859184/

Regards,
Keerthy


Please give your inputs.

V2->V3:
- Included 8 extra patches to remove style issues on
(new) thermal core.

V1->V2:
- Removed all checkpatch issues in the existing code that was
moved/changed.

Rui, it would be great if you could review these earlier. I will be
sending two extra patch series on top of this one.

BR,

Eduardo Valentin (48):
   thermal: core: prevent zones with no types to be registered
   thermal: core: group thermal_zone DEVICE_ATTR's declarations
   thermal: core: group device_create_file() calls that are always
 created
   thermal: core: use dev.groups to manage always present tz attributes
   thermal: core: move emul_temp creation to tz->device.groups
   thermal: core: move mode attribute to tz->device.groups
   thermal: core: move passive attr to tz->device.groups
   thermal: core: improve power actor documentation
   thermal: core: move power actor code out of sysfs I/F section
   thermal: core: remove useless empty line
   thermal: core: fix style on remove_trip_attrs()
   thermal: core: move the trip attrs to the tz sysfs I/F section
   thermal: core: create tz->device.groups dynamically
   thermal: core: move trips attributes to tz->device.groups
   thermal: core: remove unnecessary device_remove() calls
   thermal: core: split passive_store
   thermal: core: split policy_store
   thermal: core: split available_policies_show()
   thermal: core: move to_thermal_zone() macro to header file
   thermal: core: treat correctly the return value of *scanf calls
   thermal: core: match parenthesis on code alignment
   thermal: core: move thermal_zone sysfs to thermal_sysfs.c
   thermal: core: move to_cooling_device macro to header file
   thermal: core: move cooling device sysfs to thermal_sysfs.c
   thermal: core: remove a couple of style issues on helpers
   thermal: core: introduce thermal_helpers.c
   thermal: core: group functions related to governor handling
   thermal: core: move idr handling to device management section
   thermal: core: small style fix on __unbind() helper
   thermal: core: move __unbind() helper to where it is used
   thermal: core: move bind_cdev() to where it is used
   thermal: core: move bind_tz() to where it is used
   thermal: core: fix couple of style issues on __bind() helper
   thermal: core: move __bind() to where it is used
   thermal: core: add inline to print_bind_err_msg()
   thermal: core: move notify to the zone update section
   thermal: core: add a comment describing the main update loop
   thermal: core: add a comment describing the power actor section
   thermal: core: add a comment describing the device management section
   thermal: sysfs: remove symbols of emul_temp when config is disabled
   thermal: core: remove FSF address in the GPL notice
   thermal: core: small style fix when checking for __find_governor()
   thermal: core: standardize line breaking alignment
   thermal: core: remove void function return statements
   thermal: core: remove style warnings and checks
   thermal: core: improve kerneldoc entry of
 thermal_cooling_device_unregister
   thermal: core: use kzalloc(sizeof(*ptr),...)
   thermal: sysfs: use kcalloc() instead of kzalloc()

  drivers/thermal/Makefile  |3 +-
  drivers/thermal/thermal_core.c| 1363 +
  drivers/thermal/thermal_core.h|   26 +
  drivers/thermal/thermal_helpers.c |  144 
  drivers/thermal/thermal_sysfs.c   |  752 
  include/linux/thermal.h   |2 +
  6 files changed, 1234 insertions(+), 1056 deletions(-)
  create mode 100644 drivers/thermal/thermal_helpers.c
  create mode 100644 drivers/thermal/thermal_sysfs.c

Re: shrink_active_list/try_to_release_page bug? (was Re: xfs trace in 4.4.2 / also in 4.3.3 WARNING fs/xfs/xfs_aops.c:1232 xfs_vm_releasepage)

[Minchan Kim]

On Tue, May 31, 2016 at 12:55:09PM +1000, Dave Chinner wrote:
> On Tue, May 31, 2016 at 10:07:24AM +0900, Minchan Kim wrote:
> > On Tue, May 31, 2016 at 08:36:57AM +1000, Dave Chinner wrote:
> > > [adding lkml and linux-mm to the cc list]
> > > 
> > > On Mon, May 30, 2016 at 09:23:48AM +0200, Stefan Priebe - Profihost AG 
> > > wrote:
> > > > Hi Dave,
> > > >   Hi Brian,
> > > > 
> > > > below are the results with a vanilla 4.4.11 kernel.
> > > 
> > > Thanks for persisting with the testing, Stefan.
> > > 
> > > 
> > > 
> > > > i've now used a vanilla 4.4.11 Kernel and the issue remains. After a
> > > > fresh reboot it has happened again on the root FS for a debian apt file:
> > > > 
> > > > XFS (md127p3): ino 0x41221d1 delalloc 1 unwritten 0 pgoff 0x0 size 
> > > > 0x12b990
> > > > [ cut here ]
> > > > WARNING: CPU: 1 PID: 111 at fs/xfs/xfs_aops.c:1239
> > > > xfs_vm_releasepage+0x10f/0x140()
> > > > Modules linked in: netconsole ipt_REJECT nf_reject_ipv4 xt_multiport
> > > > iptable_filter ip_tables x_tables bonding coretemp 8021q garp fuse
> > > > sb_edac edac_core i2c_i801 i40e(O) xhci_pci xhci_hcd shpchp vxlan
> > > > ip6_udp_tunnel udp_tunnel ipmi_si ipmi_msghandler button btrfs xor
> > > > raid6_pq dm_mod raid1 md_mod usbhid usb_storage ohci_hcd sg sd_mod
> > > > ehci_pci ehci_hcd usbcore usb_common igb ahci i2c_algo_bit libahci
> > > > i2c_core mpt3sas ptp pps_core raid_class scsi_transport_sas
> > > > CPU: 1 PID: 111 Comm: kswapd0 Tainted: G   O4.4.11 #1
> > > > Hardware name: Supermicro Super Server/X10SRH-CF, BIOS 1.0b 05/18/2015
> > > >   880c4dacfa88 a23c5b8f 
> > > >  a2a51ab4 880c4dacfac8 a20837a7 880c4dacfae8
> > > >  0001 ea00010c3640 8802176b49d0 ea00010c3660
> > > > Call Trace:
> > > >  [] dump_stack+0x63/0x84
> > > >  [] warn_slowpath_common+0x97/0xe0
> > > >  [] warn_slowpath_null+0x1a/0x20
> > > >  [] xfs_vm_releasepage+0x10f/0x140
> > > >  [] ? page_mkclean_one+0xd0/0xd0
> > > >  [] ? anon_vma_prepare+0x150/0x150
> > > >  [] try_to_release_page+0x32/0x50
> > > >  [] shrink_active_list+0x3ce/0x3e0
> > > >  [] shrink_lruvec+0x687/0x7d0
> > > >  [] shrink_zone+0xdc/0x2c0
> > > >  [] kswapd+0x4f9/0x970
> > > >  [] ? mem_cgroup_shrink_node_zone+0x1a0/0x1a0
> > > >  [] kthread+0xc9/0xe0
> > > >  [] ? kthread_stop+0x100/0x100
> > > >  [] ret_from_fork+0x3f/0x70
> > > >  [] ? kthread_stop+0x100/0x100
> > > > ---[ end trace c9d679f8ed4d7610 ]---
> > > > XFS (md127p3): ino 0x41221d1 delalloc 1 unwritten 0 pgoff 0x1000 size
> > > > 0x12b990
> > > > XFS (md127p3): ino 0x41221d1 delalloc 1 unwritten 0 pgoff 0x2000 size
> > > .
> > > 
> > > Ok, I suspect this may be a VM bug. I've been looking at the 4.6
> > > code (so please try to reproduce on that kernel!) but it looks to me
> > > like the only way we can get from shrink_active_list() direct to
> > > try_to_release_page() is if we are over the maximum bufferhead
> > > threshold (i.e buffer_heads_over_limit = true) and we are trying to
> > > reclaim pages direct from the active list.
> > > 
> > > Because we are called from kswapd()->balance_pgdat(), we have:
> > > 
> > > struct scan_control sc = {
> > > .gfp_mask = GFP_KERNEL,
> > > .order = order,
> > > .priority = DEF_PRIORITY,
> > > .may_writepage = !laptop_mode,
> > > .may_unmap = 1,
> > > .may_swap = 1,
> > > };
> > > 
> > > The key point here is reclaim is being run with .may_writepage =
> > > true for default configuration kernels. when we get to
> > > shrink_active_list():
> > > 
> > >   if (!sc->may_writepage)
> > >   isolate_mode |= ISOLATE_CLEAN;
> > > 
> > > But sc->may_writepage = true and this allows isolate_lru_pages() to
> > > isolate dirty pages from the active list. Normally this isn't a
> > > problem, because the isolated active list pages are rotated to the
> > > inactive list, and nothing else happens to them. *Except when
> > > buffer_heads_over_limit = true*. This special condition would
> > > explain why I have never seen apt/dpkg cause this problem on any of
> > > my (many) Debian systems that all use XFS
> > > 
> > > In that case, shrink_active_list() runs:
> > > 
> > >   if (unlikely(buffer_heads_over_limit)) {
> > >   if (page_has_private(page) && trylock_page(page)) {
> > >   if (page_has_private(page))
> > >   try_to_release_page(page, 0);
> > >   unlock_page(page);
> > >   }
> > >   }
> > > 
> > > i.e. it locks the page, and if it has buffer heads it trys to get
> > > the bufferheads freed from the page.
> > > 
> > > But this is a dirty page, which means it may have delalloc or
> > > unwritten state on it's buffers, both of which indicate that there
> > > is dirty data in teh page that hasn't been written. XFS issues a
> > > warning on 

Re: shrink_active_list/try_to_release_page bug? (was Re: xfs trace in 4.4.2 / also in 4.3.3 WARNING fs/xfs/xfs_aops.c:1232 xfs_vm_releasepage)

[Minchan Kim]

On Tue, May 31, 2016 at 12:55:09PM +1000, Dave Chinner wrote:
> On Tue, May 31, 2016 at 10:07:24AM +0900, Minchan Kim wrote:
> > On Tue, May 31, 2016 at 08:36:57AM +1000, Dave Chinner wrote:
> > > [adding lkml and linux-mm to the cc list]
> > > 
> > > On Mon, May 30, 2016 at 09:23:48AM +0200, Stefan Priebe - Profihost AG 
> > > wrote:
> > > > Hi Dave,
> > > >   Hi Brian,
> > > > 
> > > > below are the results with a vanilla 4.4.11 kernel.
> > > 
> > > Thanks for persisting with the testing, Stefan.
> > > 
> > > 
> > > 
> > > > i've now used a vanilla 4.4.11 Kernel and the issue remains. After a
> > > > fresh reboot it has happened again on the root FS for a debian apt file:
> > > > 
> > > > XFS (md127p3): ino 0x41221d1 delalloc 1 unwritten 0 pgoff 0x0 size 
> > > > 0x12b990
> > > > [ cut here ]
> > > > WARNING: CPU: 1 PID: 111 at fs/xfs/xfs_aops.c:1239
> > > > xfs_vm_releasepage+0x10f/0x140()
> > > > Modules linked in: netconsole ipt_REJECT nf_reject_ipv4 xt_multiport
> > > > iptable_filter ip_tables x_tables bonding coretemp 8021q garp fuse
> > > > sb_edac edac_core i2c_i801 i40e(O) xhci_pci xhci_hcd shpchp vxlan
> > > > ip6_udp_tunnel udp_tunnel ipmi_si ipmi_msghandler button btrfs xor
> > > > raid6_pq dm_mod raid1 md_mod usbhid usb_storage ohci_hcd sg sd_mod
> > > > ehci_pci ehci_hcd usbcore usb_common igb ahci i2c_algo_bit libahci
> > > > i2c_core mpt3sas ptp pps_core raid_class scsi_transport_sas
> > > > CPU: 1 PID: 111 Comm: kswapd0 Tainted: G   O4.4.11 #1
> > > > Hardware name: Supermicro Super Server/X10SRH-CF, BIOS 1.0b 05/18/2015
> > > >   880c4dacfa88 a23c5b8f 
> > > >  a2a51ab4 880c4dacfac8 a20837a7 880c4dacfae8
> > > >  0001 ea00010c3640 8802176b49d0 ea00010c3660
> > > > Call Trace:
> > > >  [] dump_stack+0x63/0x84
> > > >  [] warn_slowpath_common+0x97/0xe0
> > > >  [] warn_slowpath_null+0x1a/0x20
> > > >  [] xfs_vm_releasepage+0x10f/0x140
> > > >  [] ? page_mkclean_one+0xd0/0xd0
> > > >  [] ? anon_vma_prepare+0x150/0x150
> > > >  [] try_to_release_page+0x32/0x50
> > > >  [] shrink_active_list+0x3ce/0x3e0
> > > >  [] shrink_lruvec+0x687/0x7d0
> > > >  [] shrink_zone+0xdc/0x2c0
> > > >  [] kswapd+0x4f9/0x970
> > > >  [] ? mem_cgroup_shrink_node_zone+0x1a0/0x1a0
> > > >  [] kthread+0xc9/0xe0
> > > >  [] ? kthread_stop+0x100/0x100
> > > >  [] ret_from_fork+0x3f/0x70
> > > >  [] ? kthread_stop+0x100/0x100
> > > > ---[ end trace c9d679f8ed4d7610 ]---
> > > > XFS (md127p3): ino 0x41221d1 delalloc 1 unwritten 0 pgoff 0x1000 size
> > > > 0x12b990
> > > > XFS (md127p3): ino 0x41221d1 delalloc 1 unwritten 0 pgoff 0x2000 size
> > > .
> > > 
> > > Ok, I suspect this may be a VM bug. I've been looking at the 4.6
> > > code (so please try to reproduce on that kernel!) but it looks to me
> > > like the only way we can get from shrink_active_list() direct to
> > > try_to_release_page() is if we are over the maximum bufferhead
> > > threshold (i.e buffer_heads_over_limit = true) and we are trying to
> > > reclaim pages direct from the active list.
> > > 
> > > Because we are called from kswapd()->balance_pgdat(), we have:
> > > 
> > > struct scan_control sc = {
> > > .gfp_mask = GFP_KERNEL,
> > > .order = order,
> > > .priority = DEF_PRIORITY,
> > > .may_writepage = !laptop_mode,
> > > .may_unmap = 1,
> > > .may_swap = 1,
> > > };
> > > 
> > > The key point here is reclaim is being run with .may_writepage =
> > > true for default configuration kernels. when we get to
> > > shrink_active_list():
> > > 
> > >   if (!sc->may_writepage)
> > >   isolate_mode |= ISOLATE_CLEAN;
> > > 
> > > But sc->may_writepage = true and this allows isolate_lru_pages() to
> > > isolate dirty pages from the active list. Normally this isn't a
> > > problem, because the isolated active list pages are rotated to the
> > > inactive list, and nothing else happens to them. *Except when
> > > buffer_heads_over_limit = true*. This special condition would
> > > explain why I have never seen apt/dpkg cause this problem on any of
> > > my (many) Debian systems that all use XFS
> > > 
> > > In that case, shrink_active_list() runs:
> > > 
> > >   if (unlikely(buffer_heads_over_limit)) {
> > >   if (page_has_private(page) && trylock_page(page)) {
> > >   if (page_has_private(page))
> > >   try_to_release_page(page, 0);
> > >   unlock_page(page);
> > >   }
> > >   }
> > > 
> > > i.e. it locks the page, and if it has buffer heads it trys to get
> > > the bufferheads freed from the page.
> > > 
> > > But this is a dirty page, which means it may have delalloc or
> > > unwritten state on it's buffers, both of which indicate that there
> > > is dirty data in teh page that hasn't been written. XFS issues a
> > > warning on 

Re: [RFC PATCH 2/4] mm: Change the interface for __tlb_remove_page

[Hillf Danton]

> >> @@ -1202,7 +1205,12 @@ again:
> >>if (force_flush) {
> >>force_flush = 0;
> >>tlb_flush_mmu_free(tlb);
> >> -
> >> +  if (pending_page) {
> >> +  /* remove the page with new size */
> >> +  __tlb_adjust_range(tlb, tlb->addr);
> >
> > Would you please specify why tlb->addr is used here?
> >
> 
> That is needed because tlb_flush_mmu_tlbonly() does a __tlb_reset_range().
> 
If ->addr is updated in resetting, then it is a noop here to deliver tlb->addr 
to
__tlb_adjust_range().
On the other hand, if ->addr is not updated in resetting, then it is also a 
noop here.

Do you want to update ->addr here?

thanks
Hillf

Re: [RFC PATCH 2/4] mm: Change the interface for __tlb_remove_page

[Hillf Danton]

> >> @@ -1202,7 +1205,12 @@ again:
> >>if (force_flush) {
> >>force_flush = 0;
> >>tlb_flush_mmu_free(tlb);
> >> -
> >> +  if (pending_page) {
> >> +  /* remove the page with new size */
> >> +  __tlb_adjust_range(tlb, tlb->addr);
> >
> > Would you please specify why tlb->addr is used here?
> >
> 
> That is needed because tlb_flush_mmu_tlbonly() does a __tlb_reset_range().
> 
If ->addr is updated in resetting, then it is a noop here to deliver tlb->addr 
to
__tlb_adjust_range().
On the other hand, if ->addr is not updated in resetting, then it is also a 
noop here.

Do you want to update ->addr here?

thanks
Hillf

Re: [PATCH v3] sched: fix first task of a task group is attached twice

[Yuyang Du]

On Mon, May 30, 2016 at 05:52:20PM +0200, Vincent Guittot wrote:
> The cfs_rq->avg.last_update_time is initialize to 0 with the main effect
> that the 1st sched_entity that will be attached, will keep its
> last_update_time set to 0 and will attached once again during the
> enqueue.
> Initialize cfs_rq->avg.last_update_time to 1 instead.
> 
> Signed-off-by: Vincent Guittot 
> ---
> 
> v3:
> - add initialization of load_last_update_time_copy for not 64bits system
> - move init into init_cfs_rq
> 
> v2:
> - rq_clock_task(rq_of(cfs_rq)) can't be used because lock is not held
> 
>  kernel/sched/fair.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 218f8e8..86be9c1 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -8459,6 +8459,16 @@ void init_cfs_rq(struct cfs_rq *cfs_rq)
>   cfs_rq->min_vruntime_copy = cfs_rq->min_vruntime;
>  #endif
>  #ifdef CONFIG_SMP
> + /*
> +  * Set last_update_time to something different from 0 to make
> +  * sure the 1st sched_entity will not be attached twice:once
> +  * when attaching the task to the group and one more time when
> +  * enqueueing the task.
> +  */

The first time: "once when attaching the task to the group".

That attaching is purely wrong, but will not have any effect (at least
load/util wise), because the task will later be inited in
init_entity_runnable_average().

The second time: "one more time when enqueueing the task".

In enqueue_entity_load_avg(), your patch will not have any effect either,
because of the above overwriting the new task's load in
init_entity_runnable_average(), no?

Re: [PATCH v3] sched: fix first task of a task group is attached twice

[Yuyang Du]

On Mon, May 30, 2016 at 05:52:20PM +0200, Vincent Guittot wrote:
> The cfs_rq->avg.last_update_time is initialize to 0 with the main effect
> that the 1st sched_entity that will be attached, will keep its
> last_update_time set to 0 and will attached once again during the
> enqueue.
> Initialize cfs_rq->avg.last_update_time to 1 instead.
> 
> Signed-off-by: Vincent Guittot 
> ---
> 
> v3:
> - add initialization of load_last_update_time_copy for not 64bits system
> - move init into init_cfs_rq
> 
> v2:
> - rq_clock_task(rq_of(cfs_rq)) can't be used because lock is not held
> 
>  kernel/sched/fair.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 218f8e8..86be9c1 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -8459,6 +8459,16 @@ void init_cfs_rq(struct cfs_rq *cfs_rq)
>   cfs_rq->min_vruntime_copy = cfs_rq->min_vruntime;
>  #endif
>  #ifdef CONFIG_SMP
> + /*
> +  * Set last_update_time to something different from 0 to make
> +  * sure the 1st sched_entity will not be attached twice:once
> +  * when attaching the task to the group and one more time when
> +  * enqueueing the task.
> +  */

The first time: "once when attaching the task to the group".

That attaching is purely wrong, but will not have any effect (at least
load/util wise), because the task will later be inited in
init_entity_runnable_average().

The second time: "one more time when enqueueing the task".

In enqueue_entity_load_avg(), your patch will not have any effect either,
because of the above overwriting the new task's load in
init_entity_runnable_average(), no?

linux-next: Tree for May 31

[Stephen Rothwell]

Hi all,

Changes since 20160530:

My fixes tree contains:

  of: silence warnings due to max() usage

The drm-intel tree gained conflicts against Linus' tree.

Non-merge commits (relative to Linus' tree): 946
 788 files changed, 26579 insertions(+), 12133 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 236 trees (counting Linus' and 35 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 (852f42a69b93 Merge branch 'uuid' (lib/uuid fixes from 
Andy))
Merging fixes/master (b31033aacbd0 of: silence warnings due to max() usage)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (49acadff2a0c arc: Get rid of root core-frequency 
property)
Merging arm-current/fixes (ec953b70f368 ARM: 8573/1: domain: move 
{set,get}_domain under config guard)
Merging m68k-current/for-linus (9a6462763b17 m68k/mvme16x: Include generic 
)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (b4c112114aab powerpc: Fix bad inline asm 
constraint in create_zero_mask())
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (7cafc0b8bf13 sparc64: Fix return from trap window fill 
crashes.)
Merging net/master (0e6b5259824e net: l2tp: Make l2tp_ip6 namespace aware)
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (f28f20da704d Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging wireless-drivers/master (de26859dcf36 rtlwifi: Fix scheduling while 
atomic error from commit 49f86ec21c01)
Merging mac80211/master (e6436be21e77 mac80211: fix statistics leak if 
dev_alloc_name() fails)
Merging sound-current/for-linus (6fbae35a3170 ALSA: hda/realtek - Add support 
for new codecs ALC700/ALC701/ALC703)
Merging pci-current/for-linus (9a2a5a638f8e PCI: Do not treat EPROBE_DEFER as 
device attach failure)
Merging driver-core.current/driver-core-linus (1a695a905c18 Linux 4.7-rc1)
Merging tty.current/tty-linus (1a695a905c18 Linux 4.7-rc1)
Merging usb.current/usb-linus (1a695a905c18 Linux 4.7-rc1)
Merging usb-gadget-fixes/fixes (38740a5b87d5 usb: gadget: f_fs: Fix 
use-after-free)
Merging usb-serial-fixes/usb-linus (74d2a91aec97 USB: serial: option: add even 
more ZTE device ids)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (1a695a905c18 Linux 4.7-rc1)
Merging char-misc.current/char-misc-linus (1a695a905c18 Linux 4.7-rc1)
Merging input-current/for-linus (f49cf3b8b4c8 Input: pwm-beeper - fix - 
scheduling while atomic)
Merging crypto-current/master (ab6a11a7c8ef crypto: ccp - Fix AES XTS error for 
request sizes above 4096)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
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 kselftest-fixes/fixes (505ce68c6da3 selftest/seccomp: Fix the 
seccomp(2) signature)
Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: 
Handle EPROBE_DEFER whil

linux-next: Tree for May 31

[Stephen Rothwell]

Hi all,

Changes since 20160530:

My fixes tree contains:

  of: silence warnings due to max() usage

The drm-intel tree gained conflicts against Linus' tree.

Non-merge commits (relative to Linus' tree): 946
 788 files changed, 26579 insertions(+), 12133 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 236 trees (counting Linus' and 35 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 (852f42a69b93 Merge branch 'uuid' (lib/uuid fixes from 
Andy))
Merging fixes/master (b31033aacbd0 of: silence warnings due to max() usage)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (49acadff2a0c arc: Get rid of root core-frequency 
property)
Merging arm-current/fixes (ec953b70f368 ARM: 8573/1: domain: move 
{set,get}_domain under config guard)
Merging m68k-current/for-linus (9a6462763b17 m68k/mvme16x: Include generic 
)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (b4c112114aab powerpc: Fix bad inline asm 
constraint in create_zero_mask())
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (7cafc0b8bf13 sparc64: Fix return from trap window fill 
crashes.)
Merging net/master (0e6b5259824e net: l2tp: Make l2tp_ip6 namespace aware)
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (f28f20da704d Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging wireless-drivers/master (de26859dcf36 rtlwifi: Fix scheduling while 
atomic error from commit 49f86ec21c01)
Merging mac80211/master (e6436be21e77 mac80211: fix statistics leak if 
dev_alloc_name() fails)
Merging sound-current/for-linus (6fbae35a3170 ALSA: hda/realtek - Add support 
for new codecs ALC700/ALC701/ALC703)
Merging pci-current/for-linus (9a2a5a638f8e PCI: Do not treat EPROBE_DEFER as 
device attach failure)
Merging driver-core.current/driver-core-linus (1a695a905c18 Linux 4.7-rc1)
Merging tty.current/tty-linus (1a695a905c18 Linux 4.7-rc1)
Merging usb.current/usb-linus (1a695a905c18 Linux 4.7-rc1)
Merging usb-gadget-fixes/fixes (38740a5b87d5 usb: gadget: f_fs: Fix 
use-after-free)
Merging usb-serial-fixes/usb-linus (74d2a91aec97 USB: serial: option: add even 
more ZTE device ids)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (1a695a905c18 Linux 4.7-rc1)
Merging char-misc.current/char-misc-linus (1a695a905c18 Linux 4.7-rc1)
Merging input-current/for-linus (f49cf3b8b4c8 Input: pwm-beeper - fix - 
scheduling while atomic)
Merging crypto-current/master (ab6a11a7c8ef crypto: ccp - Fix AES XTS error for 
request sizes above 4096)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
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 kselftest-fixes/fixes (505ce68c6da3 selftest/seccomp: Fix the 
seccomp(2) signature)
Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: 
Handle EPROBE_DEFER whil

Re: [PATCH V2 2/2] vhost_net: conditionally enable tx polling

[Jason Wang]

On 2016年05月30日 23:55, Michael S. Tsirkin wrote:

On Mon, May 30, 2016 at 02:47:54AM -0400, Jason Wang wrote:

We always poll tx for socket, this is sub optimal since:

- it will be only used when we exceed the sndbuf of the socket.
- since we use two independent polls for tx and vq, this will slightly
   increase the waitqueue traversing time and more important, vhost
   could not benefit from commit
   9e641bdcfa4ef4d6e2fbaa59c1be0ad5d1551fd5 ("net-tun: restructure
   tun_do_read for better sleep/wakeup efficiency") even if we've
   stopped rx polling during handle_rx since tx poll were still left in
   the waitqueue.

Why is this an issue?
sock_def_write_space only wakes up when queue is half empty,
not on each packet.
 if ((atomic_read(>sk_wmem_alloc) << 1) <= sk->sk_sndbuf)

I suspect the issue is with your previous patch,
it now pokes at the spinlock on data path
where it used not to.

Is that right?


The problem is not tx wake up but still rx wake up. Patch 1 removes rx 
poll, but still left tx poll. So in sock_def_readable(), 
skwq_has_sleeper() returns true, we still need to traverse waitqueue and 
touch spinlocks. With this patch, unless a heavy tx load, tx poll were 
disabled, sock_def_readable() can return finish very soon.






Fix this by conditionally enable tx polling only when -EAGAIN were
met.

Test shows about 8% improvement on guest rx pps.

Before: ~135
After:  ~146

Signed-off-by: Jason Wang 
---
  drivers/vhost/net.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index e91603b..5a05fa0 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -378,6 +378,7 @@ static void handle_tx(struct vhost_net *net)
goto out;
  
  	vhost_disable_notify(>dev, vq);

+   vhost_net_disable_vq(net, vq);
  
  	hdr_size = nvq->vhost_hlen;

zcopy = nvq->ubufs;
@@ -459,6 +460,8 @@ static void handle_tx(struct vhost_net *net)
% UIO_MAXIOV;
}
vhost_discard_vq_desc(vq, 1);
+   if (err == -EAGAIN)
+   vhost_net_enable_vq(net, vq);
break;
}
if (err != len)
--
1.8.3.1

Re: [PATCH V2 2/2] vhost_net: conditionally enable tx polling

[Jason Wang]

On 2016年05月30日 23:55, Michael S. Tsirkin wrote:

On Mon, May 30, 2016 at 02:47:54AM -0400, Jason Wang wrote:

We always poll tx for socket, this is sub optimal since:

- it will be only used when we exceed the sndbuf of the socket.
- since we use two independent polls for tx and vq, this will slightly
   increase the waitqueue traversing time and more important, vhost
   could not benefit from commit
   9e641bdcfa4ef4d6e2fbaa59c1be0ad5d1551fd5 ("net-tun: restructure
   tun_do_read for better sleep/wakeup efficiency") even if we've
   stopped rx polling during handle_rx since tx poll were still left in
   the waitqueue.

Why is this an issue?
sock_def_write_space only wakes up when queue is half empty,
not on each packet.
 if ((atomic_read(>sk_wmem_alloc) << 1) <= sk->sk_sndbuf)

I suspect the issue is with your previous patch,
it now pokes at the spinlock on data path
where it used not to.

Is that right?


The problem is not tx wake up but still rx wake up. Patch 1 removes rx 
poll, but still left tx poll. So in sock_def_readable(), 
skwq_has_sleeper() returns true, we still need to traverse waitqueue and 
touch spinlocks. With this patch, unless a heavy tx load, tx poll were 
disabled, sock_def_readable() can return finish very soon.






Fix this by conditionally enable tx polling only when -EAGAIN were
met.

Test shows about 8% improvement on guest rx pps.

Before: ~135
After:  ~146

Signed-off-by: Jason Wang 
---
  drivers/vhost/net.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index e91603b..5a05fa0 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -378,6 +378,7 @@ static void handle_tx(struct vhost_net *net)
goto out;
  
  	vhost_disable_notify(>dev, vq);

+   vhost_net_disable_vq(net, vq);
  
  	hdr_size = nvq->vhost_hlen;

zcopy = nvq->ubufs;
@@ -459,6 +460,8 @@ static void handle_tx(struct vhost_net *net)
% UIO_MAXIOV;
}
vhost_discard_vq_desc(vq, 1);
+   if (err == -EAGAIN)
+   vhost_net_enable_vq(net, vq);
break;
}
if (err != len)
--
1.8.3.1

GRsecurity is preventing others from employing their rights under version 2 the GPL to redistribute source code

[concernedfossdev]

GRsecurity (Brad Spengler) is preventing others from employing their rights 
under version 2 the GPL to redistribute
(by threatening them with a non-renewal of a contract to recive this patch to 
the linux kernel.)
(GRsecurity is a derivative work of the linux kernel (it is a patch))

People who have dealt with them have attested to this fact:
https://www.reddit.com/r/KotakuInAction/comments/4grdtb/censorship_linux_developer_steals_page_from_
andi
"You will also lose the access to the patches in the form of grsec not renewing 
the contract. 
Also they've asked us (a Russian hosting company) for $17000+ a year for access 
their stable
patches. $17k is quite a lot for us. A question about negotiating a lower price 
was completely
ignored. Twice." -- fbt2lurker

And it is suggested to be the case here aswell:
https://www.reddit.com/r/linux/comments/4gxdlh/after_15_years_of_research_grsecuritys_rap_is_here
"Do you work for some company that pays for Grsecurity? If so then would you 
kindly excersise the
rights given to you by GPL and send me a tarball of all the latest patches and 
releases?" --
lolidaisuki
"sadly (for this case) no, i work in a human rights organization where we get 
the patches by a
friendly and richer 3rd party of the same field. we made the compromise to that 
3rd party to not
distribute the patches outside and as we deal with some critical situations i 
cannot afford to
compromise that even for the sake of gpl :/
the "dumber" version for unstable patches will make a big problem for several 
projects, i would
keep an eye on them. this situation cannot be hold for a long time" -- disturbio

Is this not tortious interference, on grsecurity's (Brad Spengler) part, with 
the quazi-contractual
relationship the sublicensee has with the original licensor?

(Also Note: the stable branch now contains features that will never make it to 
the "testing"
branch, and are not allowed to 
be redistributed, per the scheme mentioned above (which has been successful: 
not one version of the
stable branch 
has been released by anyone, even those asked to do so, since the scheme has 
been put in place
(they say they cannot
as they cannot lose access to the patch as that may cost the lives and freedom 
of activists in
latin america)))

https://twitter.com/marcan42/status/726101158561882112
@xoreipeip @grsecurity they call it a "demo" version "20:14 < spender> what's 
in the public version
is < 1/5th the size of the full version"
oreipeip @grsecurity "20:21 < spender> also it wouldn't be as fast as the 
commercial version [...]
there are missing optimization passes"

GRsecurity is preventing others from employing their rights under version 2 the GPL to redistribute source code

[concernedfossdev]

GRsecurity (Brad Spengler) is preventing others from employing their rights 
under version 2 the GPL to redistribute
(by threatening them with a non-renewal of a contract to recive this patch to 
the linux kernel.)
(GRsecurity is a derivative work of the linux kernel (it is a patch))

People who have dealt with them have attested to this fact:
https://www.reddit.com/r/KotakuInAction/comments/4grdtb/censorship_linux_developer_steals_page_from_
andi
"You will also lose the access to the patches in the form of grsec not renewing 
the contract. 
Also they've asked us (a Russian hosting company) for $17000+ a year for access 
their stable
patches. $17k is quite a lot for us. A question about negotiating a lower price 
was completely
ignored. Twice." -- fbt2lurker

And it is suggested to be the case here aswell:
https://www.reddit.com/r/linux/comments/4gxdlh/after_15_years_of_research_grsecuritys_rap_is_here
"Do you work for some company that pays for Grsecurity? If so then would you 
kindly excersise the
rights given to you by GPL and send me a tarball of all the latest patches and 
releases?" --
lolidaisuki
"sadly (for this case) no, i work in a human rights organization where we get 
the patches by a
friendly and richer 3rd party of the same field. we made the compromise to that 
3rd party to not
distribute the patches outside and as we deal with some critical situations i 
cannot afford to
compromise that even for the sake of gpl :/
the "dumber" version for unstable patches will make a big problem for several 
projects, i would
keep an eye on them. this situation cannot be hold for a long time" -- disturbio

Is this not tortious interference, on grsecurity's (Brad Spengler) part, with 
the quazi-contractual
relationship the sublicensee has with the original licensor?

(Also Note: the stable branch now contains features that will never make it to 
the "testing"
branch, and are not allowed to 
be redistributed, per the scheme mentioned above (which has been successful: 
not one version of the
stable branch 
has been released by anyone, even those asked to do so, since the scheme has 
been put in place
(they say they cannot
as they cannot lose access to the patch as that may cost the lives and freedom 
of activists in
latin america)))

https://twitter.com/marcan42/status/726101158561882112
@xoreipeip @grsecurity they call it a "demo" version "20:14 < spender> what's 
in the public version
is < 1/5th the size of the full version"
oreipeip @grsecurity "20:21 < spender> also it wouldn't be as fast as the 
commercial version [...]
there are missing optimization passes"

Re: [PATCH V2 1/2] vhost_net: stop polling socket during rx processing

[Jason Wang]

On 2016年05月30日 23:47, Michael S. Tsirkin wrote:

On Mon, May 30, 2016 at 02:47:53AM -0400, Jason Wang wrote:

We don't stop rx polling socket during rx processing, this will lead
unnecessary wakeups from under layer net devices (E.g
sock_def_readable() form tun). Rx will be slowed down in this
way. This patch avoids this by stop polling socket during rx
processing. A small drawback is that this introduces some overheads in
light load case because of the extra start/stop polling, but single
netperf TCP_RR does not notice any change. In a super heavy load case,
e.g using pktgen to inject packet to guest, we get about ~8.8%
improvement on pps:

before: ~124 pkt/s
after:  ~135 pkt/s

Signed-off-by: Jason Wang 
---
  drivers/vhost/net.c | 56 +++--
  1 file changed, 29 insertions(+), 27 deletions(-)

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 10ff494..e91603b 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -301,6 +301,32 @@ static bool vhost_can_busy_poll(struct vhost_dev *dev,
   !vhost_has_work(dev);
  }
  
+static void vhost_net_disable_vq(struct vhost_net *n,

+struct vhost_virtqueue *vq)
+{
+   struct vhost_net_virtqueue *nvq =
+   container_of(vq, struct vhost_net_virtqueue, vq);
+   struct vhost_poll *poll = n->poll + (nvq - n->vqs);
+   if (!vq->private_data)
+   return;
+   vhost_poll_stop(poll);
+}
+
+static int vhost_net_enable_vq(struct vhost_net *n,
+   struct vhost_virtqueue *vq)
+{
+   struct vhost_net_virtqueue *nvq =
+   container_of(vq, struct vhost_net_virtqueue, vq);
+   struct vhost_poll *poll = n->poll + (nvq - n->vqs);
+   struct socket *sock;
+
+   sock = vq->private_data;
+   if (!sock)
+   return 0;
+
+   return vhost_poll_start(poll, sock->file);
+}
+
  static int vhost_net_tx_get_vq_desc(struct vhost_net *net,
struct vhost_virtqueue *vq,
struct iovec iov[], unsigned int iov_size,

BTW we might want to rename these functions, name no longer
reflects function ...


Do you mean adding something reflect busy polling in the name? Then the 
name may be too long or have suggestion on the name?






@@ -627,6 +653,7 @@ static void handle_rx(struct vhost_net *net)
if (!sock)
goto out;
vhost_disable_notify(>dev, vq);
+   vhost_net_disable_vq(net, vq);
  
  	vhost_hlen = nvq->vhost_hlen;

sock_hlen = nvq->sock_hlen;
@@ -715,9 +742,10 @@ static void handle_rx(struct vhost_net *net)
total_len += vhost_len;
if (unlikely(total_len >= VHOST_NET_WEIGHT)) {
vhost_poll_queue(>poll);
-   break;
+   goto out;
}
}
+   vhost_net_enable_vq(net, vq);

OK so if sock is readable but RX VQ is empty, this will
immediately schedule another round of handle_rx and so ad
infinitum,

Looks like a bug.


Yes it is, will change the above headcount check to:

/* OK, now we need to know about added descriptors. */
if (!headcount) {
if (unlikely(vhost_enable_notify(>dev, vq))) {
/* They have slipped one in as we were
 * doing that: check again. */
vhost_disable_notify(>dev, vq);
continue;
}
/* Nothing new?  Wait for eventfd to tell us
 * they refilled. */
goto out;
}






  out:
mutex_unlock(>mutex);
  }
@@ -796,32 +824,6 @@ static int vhost_net_open(struct inode *inode, struct file 
*f)
return 0;
  }
  
-static void vhost_net_disable_vq(struct vhost_net *n,

-struct vhost_virtqueue *vq)
-{
-   struct vhost_net_virtqueue *nvq =
-   container_of(vq, struct vhost_net_virtqueue, vq);
-   struct vhost_poll *poll = n->poll + (nvq - n->vqs);
-   if (!vq->private_data)
-   return;
-   vhost_poll_stop(poll);
-}
-
-static int vhost_net_enable_vq(struct vhost_net *n,
-   struct vhost_virtqueue *vq)
-{
-   struct vhost_net_virtqueue *nvq =
-   container_of(vq, struct vhost_net_virtqueue, vq);
-   struct vhost_poll *poll = n->poll + (nvq - n->vqs);
-   struct socket *sock;
-
-   sock = vq->private_data;
-   if (!sock)
-   return 0;
-
-   return vhost_poll_start(poll, sock->file);
-}
-
  static struct socket *vhost_net_stop_vq(struct vhost_net *n,
struct vhost_virtqueue *vq)
  {
--
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to 

Re: [PATCH V2 1/2] vhost_net: stop polling socket during rx processing

[Jason Wang]

On 2016年05月30日 23:47, Michael S. Tsirkin wrote:

On Mon, May 30, 2016 at 02:47:53AM -0400, Jason Wang wrote:

We don't stop rx polling socket during rx processing, this will lead
unnecessary wakeups from under layer net devices (E.g
sock_def_readable() form tun). Rx will be slowed down in this
way. This patch avoids this by stop polling socket during rx
processing. A small drawback is that this introduces some overheads in
light load case because of the extra start/stop polling, but single
netperf TCP_RR does not notice any change. In a super heavy load case,
e.g using pktgen to inject packet to guest, we get about ~8.8%
improvement on pps:

before: ~124 pkt/s
after:  ~135 pkt/s

Signed-off-by: Jason Wang 
---
  drivers/vhost/net.c | 56 +++--
  1 file changed, 29 insertions(+), 27 deletions(-)

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 10ff494..e91603b 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -301,6 +301,32 @@ static bool vhost_can_busy_poll(struct vhost_dev *dev,
   !vhost_has_work(dev);
  }
  
+static void vhost_net_disable_vq(struct vhost_net *n,

+struct vhost_virtqueue *vq)
+{
+   struct vhost_net_virtqueue *nvq =
+   container_of(vq, struct vhost_net_virtqueue, vq);
+   struct vhost_poll *poll = n->poll + (nvq - n->vqs);
+   if (!vq->private_data)
+   return;
+   vhost_poll_stop(poll);
+}
+
+static int vhost_net_enable_vq(struct vhost_net *n,
+   struct vhost_virtqueue *vq)
+{
+   struct vhost_net_virtqueue *nvq =
+   container_of(vq, struct vhost_net_virtqueue, vq);
+   struct vhost_poll *poll = n->poll + (nvq - n->vqs);
+   struct socket *sock;
+
+   sock = vq->private_data;
+   if (!sock)
+   return 0;
+
+   return vhost_poll_start(poll, sock->file);
+}
+
  static int vhost_net_tx_get_vq_desc(struct vhost_net *net,
struct vhost_virtqueue *vq,
struct iovec iov[], unsigned int iov_size,

BTW we might want to rename these functions, name no longer
reflects function ...


Do you mean adding something reflect busy polling in the name? Then the 
name may be too long or have suggestion on the name?






@@ -627,6 +653,7 @@ static void handle_rx(struct vhost_net *net)
if (!sock)
goto out;
vhost_disable_notify(>dev, vq);
+   vhost_net_disable_vq(net, vq);
  
  	vhost_hlen = nvq->vhost_hlen;

sock_hlen = nvq->sock_hlen;
@@ -715,9 +742,10 @@ static void handle_rx(struct vhost_net *net)
total_len += vhost_len;
if (unlikely(total_len >= VHOST_NET_WEIGHT)) {
vhost_poll_queue(>poll);
-   break;
+   goto out;
}
}
+   vhost_net_enable_vq(net, vq);

OK so if sock is readable but RX VQ is empty, this will
immediately schedule another round of handle_rx and so ad
infinitum,

Looks like a bug.


Yes it is, will change the above headcount check to:

/* OK, now we need to know about added descriptors. */
if (!headcount) {
if (unlikely(vhost_enable_notify(>dev, vq))) {
/* They have slipped one in as we were
 * doing that: check again. */
vhost_disable_notify(>dev, vq);
continue;
}
/* Nothing new?  Wait for eventfd to tell us
 * they refilled. */
goto out;
}






  out:
mutex_unlock(>mutex);
  }
@@ -796,32 +824,6 @@ static int vhost_net_open(struct inode *inode, struct file 
*f)
return 0;
  }
  
-static void vhost_net_disable_vq(struct vhost_net *n,

-struct vhost_virtqueue *vq)
-{
-   struct vhost_net_virtqueue *nvq =
-   container_of(vq, struct vhost_net_virtqueue, vq);
-   struct vhost_poll *poll = n->poll + (nvq - n->vqs);
-   if (!vq->private_data)
-   return;
-   vhost_poll_stop(poll);
-}
-
-static int vhost_net_enable_vq(struct vhost_net *n,
-   struct vhost_virtqueue *vq)
-{
-   struct vhost_net_virtqueue *nvq =
-   container_of(vq, struct vhost_net_virtqueue, vq);
-   struct vhost_poll *poll = n->poll + (nvq - n->vqs);
-   struct socket *sock;
-
-   sock = vq->private_data;
-   if (!sock)
-   return 0;
-
-   return vhost_poll_start(poll, sock->file);
-}
-
  static struct socket *vhost_net_stop_vq(struct vhost_net *n,
struct vhost_virtqueue *vq)
  {
--
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org

Re: [PATCH] ARM: dts: sun7i: Add dts file for Bananapi M1 Plus board

[Chen-Yu Tsai]

Hi,

On Tue, May 31, 2016 at 3:43 AM, Maxime Ripard
 wrote:
> Hi,
>
> On Mon, May 30, 2016 at 08:30:13PM +0800, luoyi...@gmail.com wrote:
>> From: luoyi 
>>
>> Add support for the Bananapi M1 Plus A20 development board from 
>> sinovoip.com.cn .
>> This board features 1G RAM, 2 USB A receptacles, 1 micro USB receptacle for
>> OTG, 1 micro USB receptacle for power, HDMI, sata, Gbit ethernet, ir 
>> receiver,
>> 3.5 mm jack for stero sound out, on board microphone, 40 gpio pins and sdio 
>> wifi.
>
> What is the difference between the M1+ and the M1?
>
>>
>> Signed-off-by: Luo Yi 
>> ---
>>  arch/arm/boot/dts/Makefile   |   1 +
>>  arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts | 270 
>> +++
>>  2 files changed, 271 insertions(+)
>>  create mode 100644 arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index e06a5ab..fde407f 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -685,6 +685,7 @@ dtb-$(CONFIG_MACH_SUN6I) += \
>>   sun6i-a31s-yones-toptech-bs1078-v2.dtb
>>  dtb-$(CONFIG_MACH_SUN7I) += \
>>   sun7i-a20-bananapi.dtb \
>> + sun7i-a20-bananapi-m1-plus.dtb \
>>   sun7i-a20-bananapro.dtb \
>>   sun7i-a20-cubieboard2.dtb \
>>   sun7i-a20-cubietruck.dtb \
>> diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts 
>> b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
>> new file mode 100644
>> index 000..b62fc1d
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
>> @@ -0,0 +1,270 @@
>> +/*
>> + * Copyright 2016 Luo Yi 
>> + *
>> + * Thanks to the original work by Hans de Goede 
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + *  a) This file 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 file 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.
>> + *
>> + * Or, alternatively,
>> + *
>> + *  b) Permission is hereby granted, free of charge, to any person
>> + * obtaining a copy of this software and associated documentation
>> + * files (the "Software"), to deal in the Software without
>> + * restriction, including without limitation the rights to use,
>> + * copy, modify, merge, publish, distribute, sublicense, and/or
>> + * sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following
>> + * conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be
>> + * included in all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + * OTHER DEALINGS IN THE SOFTWARE.
>> + */
>> +
>> +/dts-v1/;
>> +#include "sun7i-a20.dtsi"
>> +#include "sunxi-common-regulators.dtsi"
>> +#include 
>> +#include 
>> +
>> +/ {
>> + model = "Banana Pi BPI-M1-Plus";
>> + compatible = "sinovoip,bpi-m1-plus", "allwinner,sun7i-a20";
>> +
>> + aliases {
>> + serial0 = 
>> + };
>> +
>> + chosen {
>> + stdout-path = "serial0:115200n8";
>> + };
>> +
>> + leds {
>> + compatible = "gpio-leds";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <_pins_bananapi>;
>> +
>> + red {
>> + label = "bananapi:red:usr";
>
> The first part the label is the board name, in that case that would be
> bananapi-m1-plus.
>
>> + gpios = < 7 25 GPIO_ACTIVE_HIGH>;
>> + linux,default-trigger = "default-on";
>
> So that's the power led?
>
>> + };
>> +
>> + green {
>> + label = "bananapi:green:usr";
>> + gpios = < 7 24 GPIO_ACTIVE_HIGH>;
>> + 

Re: [PATCH] ARM: dts: sun7i: Add dts file for Bananapi M1 Plus board

[Chen-Yu Tsai]

Hi,

On Tue, May 31, 2016 at 3:43 AM, Maxime Ripard
 wrote:
> Hi,
>
> On Mon, May 30, 2016 at 08:30:13PM +0800, luoyi...@gmail.com wrote:
>> From: luoyi 
>>
>> Add support for the Bananapi M1 Plus A20 development board from 
>> sinovoip.com.cn .
>> This board features 1G RAM, 2 USB A receptacles, 1 micro USB receptacle for
>> OTG, 1 micro USB receptacle for power, HDMI, sata, Gbit ethernet, ir 
>> receiver,
>> 3.5 mm jack for stero sound out, on board microphone, 40 gpio pins and sdio 
>> wifi.
>
> What is the difference between the M1+ and the M1?
>
>>
>> Signed-off-by: Luo Yi 
>> ---
>>  arch/arm/boot/dts/Makefile   |   1 +
>>  arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts | 270 
>> +++
>>  2 files changed, 271 insertions(+)
>>  create mode 100644 arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index e06a5ab..fde407f 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -685,6 +685,7 @@ dtb-$(CONFIG_MACH_SUN6I) += \
>>   sun6i-a31s-yones-toptech-bs1078-v2.dtb
>>  dtb-$(CONFIG_MACH_SUN7I) += \
>>   sun7i-a20-bananapi.dtb \
>> + sun7i-a20-bananapi-m1-plus.dtb \
>>   sun7i-a20-bananapro.dtb \
>>   sun7i-a20-cubieboard2.dtb \
>>   sun7i-a20-cubietruck.dtb \
>> diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts 
>> b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
>> new file mode 100644
>> index 000..b62fc1d
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
>> @@ -0,0 +1,270 @@
>> +/*
>> + * Copyright 2016 Luo Yi 
>> + *
>> + * Thanks to the original work by Hans de Goede 
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + *  a) This file 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 file 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.
>> + *
>> + * Or, alternatively,
>> + *
>> + *  b) Permission is hereby granted, free of charge, to any person
>> + * obtaining a copy of this software and associated documentation
>> + * files (the "Software"), to deal in the Software without
>> + * restriction, including without limitation the rights to use,
>> + * copy, modify, merge, publish, distribute, sublicense, and/or
>> + * sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following
>> + * conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be
>> + * included in all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + * OTHER DEALINGS IN THE SOFTWARE.
>> + */
>> +
>> +/dts-v1/;
>> +#include "sun7i-a20.dtsi"
>> +#include "sunxi-common-regulators.dtsi"
>> +#include 
>> +#include 
>> +
>> +/ {
>> + model = "Banana Pi BPI-M1-Plus";
>> + compatible = "sinovoip,bpi-m1-plus", "allwinner,sun7i-a20";
>> +
>> + aliases {
>> + serial0 = 
>> + };
>> +
>> + chosen {
>> + stdout-path = "serial0:115200n8";
>> + };
>> +
>> + leds {
>> + compatible = "gpio-leds";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <_pins_bananapi>;
>> +
>> + red {
>> + label = "bananapi:red:usr";
>
> The first part the label is the board name, in that case that would be
> bananapi-m1-plus.
>
>> + gpios = < 7 25 GPIO_ACTIVE_HIGH>;
>> + linux,default-trigger = "default-on";
>
> So that's the power led?
>
>> + };
>> +
>> + green {
>> + label = "bananapi:green:usr";
>> + gpios = < 7 24 GPIO_ACTIVE_HIGH>;
>> + linux,default-trigger = "heartbeat";
>
> We don't enforce any trigger by default.
>
>> +
>> + };
>> + };
>> +

[BUG] Page allocation failures with newest kernels

[Marcin Wojtas]

Hi,

After rebasing platform support of two different ARMv8 SoC's from v4.1
baseline to v4.4 it occurred that stressed systems tend to have page
allocation problems, related to creating new slabs:

http://pastebin.com/FhRW5DsF

Steps to reproduce:
- use SATA drive (on-board or over PCIe) with 2 btrfs 50G partitions
- run a couple of loops of following script:
mount /dev/sd${1}1 /mnt
mount /dev/sd${1}2 /mnt2
i=0
while [[ $i -lt ${2} ]]
do
echo -e "i = ${i}\n"
dd if=/dev/zero of=/mnt/3g bs=3M count=1024 &
dd if=/dev/zero of=/mnt/2g bs=2M count=1024 &
dd if=/dev/zero of=/mnt/1g bs=1M count=1024 &
dd if=/dev/zero of=/mnt2/2g bs=2M count=1024 &
dd if=/dev/zero of=/mnt2/1g bs=1M count=1024 &
dd if=/dev/zero of=/mnt2/3g bs=3M count=1024
let "i++"
done

The issue also reproduced on v4.6. Usually problems occur within first
iteration and then the rest is done without errors, also kernel remain
stable. I got an information, that page alloc problem were observed
also on Marvell ARMv7 platfrom (Armada38x).

About the debug itself - after adding simplest possible trace in
trace/events/kmem.h (single argument u64 for counter or whatever kind
of number), it was shown both on v4.1 and v4.4 following condition is
achieved multiple times during test:
In __alloc_pages_nodemask(), during the test kernel jumps huge amount
of times (~250k times in v4.1 and ~570k in v4.4 per one script loop)
into following 'unlikely' condition:
page = get_page_from_freelist(alloc_mask, order, alloc_flags, );
if (unlikely(!page)) {
[...]
page = __alloc_pages_slowpath(alloc_mask, order, );
}

The further difference is seen in __alloc_pages_slowpath().
warn_alloc_page() (routine responsible for printing page alloc failure
message) is reached via following condition:
if (!can_direct_reclaim) {
[...]
goto nopage;
}
In v4.1 ~5 times and in v4.4 ~40 times per one script loop.

Printing message however can be blocked by following condition in
warn_alloc_fail():
if ((gfp_mask & _GFP_NOWARN) || !_ratelimit(_rs) ||
debug_guardpage_minorder() > 0)
return;
Only first two are relevant. As ratelimit is derived directly from
CONFIG_HZ and this parameter differ between v4.1 and v4.4 (100 vs 250,
also CONFIG_SCHED_HRTICK is enabled only in v4.4) the configs were
swapped, but no change in behavior.

Also within 'faulty' revision there is a difference, depending on
filesystem used - with buildroot the dumps occur, but with same test
under ubuntu - it's impossible see the failure output (and it's not a
question of dmesg level:)). Comparing /proc/sys/vm contents didn't
show anything meaningful.

I tried to analyze changes around mm/ folder between v4.1 and v4.4
that may cause such difference, but wasn't able to find out what may
be causing the issue. Have anyone encountered such problems in recent
revisions? I would be very grateful for any hint or comment. Also if
any other data can be captured, please let know.

Best regards,
Marcin Wojtas

[BUG] Page allocation failures with newest kernels

[Marcin Wojtas]

Hi,

After rebasing platform support of two different ARMv8 SoC's from v4.1
baseline to v4.4 it occurred that stressed systems tend to have page
allocation problems, related to creating new slabs:

http://pastebin.com/FhRW5DsF

Steps to reproduce:
- use SATA drive (on-board or over PCIe) with 2 btrfs 50G partitions
- run a couple of loops of following script:
mount /dev/sd${1}1 /mnt
mount /dev/sd${1}2 /mnt2
i=0
while [[ $i -lt ${2} ]]
do
echo -e "i = ${i}\n"
dd if=/dev/zero of=/mnt/3g bs=3M count=1024 &
dd if=/dev/zero of=/mnt/2g bs=2M count=1024 &
dd if=/dev/zero of=/mnt/1g bs=1M count=1024 &
dd if=/dev/zero of=/mnt2/2g bs=2M count=1024 &
dd if=/dev/zero of=/mnt2/1g bs=1M count=1024 &
dd if=/dev/zero of=/mnt2/3g bs=3M count=1024
let "i++"
done

The issue also reproduced on v4.6. Usually problems occur within first
iteration and then the rest is done without errors, also kernel remain
stable. I got an information, that page alloc problem were observed
also on Marvell ARMv7 platfrom (Armada38x).

About the debug itself - after adding simplest possible trace in
trace/events/kmem.h (single argument u64 for counter or whatever kind
of number), it was shown both on v4.1 and v4.4 following condition is
achieved multiple times during test:
In __alloc_pages_nodemask(), during the test kernel jumps huge amount
of times (~250k times in v4.1 and ~570k in v4.4 per one script loop)
into following 'unlikely' condition:
page = get_page_from_freelist(alloc_mask, order, alloc_flags, );
if (unlikely(!page)) {
[...]
page = __alloc_pages_slowpath(alloc_mask, order, );
}

The further difference is seen in __alloc_pages_slowpath().
warn_alloc_page() (routine responsible for printing page alloc failure
message) is reached via following condition:
if (!can_direct_reclaim) {
[...]
goto nopage;
}
In v4.1 ~5 times and in v4.4 ~40 times per one script loop.

Printing message however can be blocked by following condition in
warn_alloc_fail():
if ((gfp_mask & _GFP_NOWARN) || !_ratelimit(_rs) ||
debug_guardpage_minorder() > 0)
return;
Only first two are relevant. As ratelimit is derived directly from
CONFIG_HZ and this parameter differ between v4.1 and v4.4 (100 vs 250,
also CONFIG_SCHED_HRTICK is enabled only in v4.4) the configs were
swapped, but no change in behavior.

Also within 'faulty' revision there is a difference, depending on
filesystem used - with buildroot the dumps occur, but with same test
under ubuntu - it's impossible see the failure output (and it's not a
question of dmesg level:)). Comparing /proc/sys/vm contents didn't
show anything meaningful.

I tried to analyze changes around mm/ folder between v4.1 and v4.4
that may cause such difference, but wasn't able to find out what may
be causing the issue. Have anyone encountered such problems in recent
revisions? I would be very grateful for any hint or comment. Also if
any other data can be captured, please let know.

Best regards,
Marcin Wojtas

RE: [PATCH v2 3/3] ACPI / button: Send "open" state after boot/resume

[Zheng, Lv]

Hi,

> From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com]
> Subject: Re: [PATCH v2 3/3] ACPI / button: Send "open" state after
> boot/resume
> 
> On Fri, May 27, 2016 at 9:16 AM, Lv Zheng  wrote:
> > Linux userspace (systemd-logind) keeps on rechecking lid state when the
> > lid state is closed. If it failed to update the lid state to open after
> > boot/resume, the system suspending right after the boot/resume could
> be
> > resulted.
> > Graphics drivers also uses the lid notifications to implment
> > MODESET_ON_LID_OPEN option.
> >
> > Before the situation is improved from the userspace and from the
> graphics
> > driver, simply send initial "open" lid state to avoid issues. After this is
> > improved from the userspace and from the graphics driver, Linux kernel
> > could simply revert this minimal commit.
> >
> > Link 1: https://lkml.org/2016/3/7/460
> > Link 2: https://github.com/systemd/systemd/issues/2087
> > Signed-off-by: Lv Zheng 
> > Cc: Bastien Nocera: 
> > ---
> >  drivers/acpi/button.c |3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
> > index e706e4b..6e77312 100644
> > --- a/drivers/acpi/button.c
> > +++ b/drivers/acpi/button.c
> > @@ -342,6 +342,8 @@ static int acpi_button_resume(struct device
> *dev)
> > struct acpi_button *button = acpi_driver_data(device);
> >
> > button->suspended = false;
> > +   if (button->type == ACPI_BUTTON_TYPE_LID)
> > +   return acpi_lid_notify_state(device, 1);
> 
> As Valdis replied on 0/3, I don't think this is a good solution (even
> temporary). Linux should not assume the current state of a input
> device, and sending unconditionally 1 here is wrong. If the device is
> on a docking station, you will wake up the wrong monitor and screw the
> user session (and this will be a regression).
[Lv Zheng] 
We are doing the test to see how this behaves on several different platforms.

> 
> How about we simply send the current LID state stored in the ACPI?
> something like calling acpi_lid_send_state() directly?
[Lv Zheng] 
This is what we are going to eliminate in [PATCH 01].
We have several real bugs related to sending a wrong state to the userspace.
Userspace will suspend right after resume because of the 'close' state.


> 
> [15 min later, after writing a long email]
> 
> Well, it looks like we already have that in the kernel and for a long
> time apparently.
> 
> So, I think the issue is that Microsoft does not wake up the system by
> lid opening (seen in one of the comments in the mentioned bugs and by
> looking at the behavior on the surface devices). It must be just
> querying it's state on resume or might even not care at all until it
> receives a close event.
> 
> If I read correctly, we managed to get the 3 bogus devices to a
> correct state at the ACPI level (/proc/acpi/button/lid/LID0/state),
> but we did not get the notification. Given that the LID state is
> triggered by an ACPI operation region, there is no guarantee that the
> resume of the acpi/button.c driver will be called after the region has
> been updated/called.
[Lv Zheng] 
The understanding here is incorrect.
We have 3 bogus devices.
1 of them is surface 3 which is a hardware reduced platform.
The others are all traditional platforms.

=
The facts are:

Both the platforms return cached lid state from _LID.
The cached value will be updated by lid irq (via GPIO IRQ, GPE, or EC event).
AML tables will send lid notification in the irq handler.

Some AML tables will update the cached value in _WAK (I'll describe why it is 
necessary below).
But updating the cached value in _WAK is not guaranteed by all AML tables.

For the 'close' state irq, all tables will send lid close notification.
For the 'open' state irq, it seems there are tables never sending lid open 
notification (sounds like Windows do not care about lid open).
=

Surface 3 is entirely a different case.
It is a runtime idle system and hardware reduced.
On that kind of system, lid open is handled by OS not by BIOS.
Surface 3 is exactly the platform that doesn't send lid open notification.
I guess the AML is intentionally written in this way to be compliant to the 
traditional platforms.

While on the traditional platforms:
When lid is opened, BIOS handles the lid irq and wakes the system from the FACS 
waking vector.
So it is likely that there is no lid open irq after the system is resumed.
BIOS may forget to update the cached lid value in the _WAK or some other 
control methods that could be executed after resuming.
Then if we send _LID result to the user space, the cached value could 
apparently be 'close'.

That explains why there is no "lid open" configuration in the "Windows Device 
Manager".

> 
> I propose as a workaround to enable a kthread that will monitor the
> lid state and update the correct value to userspace (5 sec of polling
> time should be 

RE: [PATCH v2 3/3] ACPI / button: Send "open" state after boot/resume

[Zheng, Lv]

Hi,

> From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com]
> Subject: Re: [PATCH v2 3/3] ACPI / button: Send "open" state after
> boot/resume
> 
> On Fri, May 27, 2016 at 9:16 AM, Lv Zheng  wrote:
> > Linux userspace (systemd-logind) keeps on rechecking lid state when the
> > lid state is closed. If it failed to update the lid state to open after
> > boot/resume, the system suspending right after the boot/resume could
> be
> > resulted.
> > Graphics drivers also uses the lid notifications to implment
> > MODESET_ON_LID_OPEN option.
> >
> > Before the situation is improved from the userspace and from the
> graphics
> > driver, simply send initial "open" lid state to avoid issues. After this is
> > improved from the userspace and from the graphics driver, Linux kernel
> > could simply revert this minimal commit.
> >
> > Link 1: https://lkml.org/2016/3/7/460
> > Link 2: https://github.com/systemd/systemd/issues/2087
> > Signed-off-by: Lv Zheng 
> > Cc: Bastien Nocera: 
> > ---
> >  drivers/acpi/button.c |3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
> > index e706e4b..6e77312 100644
> > --- a/drivers/acpi/button.c
> > +++ b/drivers/acpi/button.c
> > @@ -342,6 +342,8 @@ static int acpi_button_resume(struct device
> *dev)
> > struct acpi_button *button = acpi_driver_data(device);
> >
> > button->suspended = false;
> > +   if (button->type == ACPI_BUTTON_TYPE_LID)
> > +   return acpi_lid_notify_state(device, 1);
> 
> As Valdis replied on 0/3, I don't think this is a good solution (even
> temporary). Linux should not assume the current state of a input
> device, and sending unconditionally 1 here is wrong. If the device is
> on a docking station, you will wake up the wrong monitor and screw the
> user session (and this will be a regression).
[Lv Zheng] 
We are doing the test to see how this behaves on several different platforms.

> 
> How about we simply send the current LID state stored in the ACPI?
> something like calling acpi_lid_send_state() directly?
[Lv Zheng] 
This is what we are going to eliminate in [PATCH 01].
We have several real bugs related to sending a wrong state to the userspace.
Userspace will suspend right after resume because of the 'close' state.


> 
> [15 min later, after writing a long email]
> 
> Well, it looks like we already have that in the kernel and for a long
> time apparently.
> 
> So, I think the issue is that Microsoft does not wake up the system by
> lid opening (seen in one of the comments in the mentioned bugs and by
> looking at the behavior on the surface devices). It must be just
> querying it's state on resume or might even not care at all until it
> receives a close event.
> 
> If I read correctly, we managed to get the 3 bogus devices to a
> correct state at the ACPI level (/proc/acpi/button/lid/LID0/state),
> but we did not get the notification. Given that the LID state is
> triggered by an ACPI operation region, there is no guarantee that the
> resume of the acpi/button.c driver will be called after the region has
> been updated/called.
[Lv Zheng] 
The understanding here is incorrect.
We have 3 bogus devices.
1 of them is surface 3 which is a hardware reduced platform.
The others are all traditional platforms.

=
The facts are:

Both the platforms return cached lid state from _LID.
The cached value will be updated by lid irq (via GPIO IRQ, GPE, or EC event).
AML tables will send lid notification in the irq handler.

Some AML tables will update the cached value in _WAK (I'll describe why it is 
necessary below).
But updating the cached value in _WAK is not guaranteed by all AML tables.

For the 'close' state irq, all tables will send lid close notification.
For the 'open' state irq, it seems there are tables never sending lid open 
notification (sounds like Windows do not care about lid open).
=

Surface 3 is entirely a different case.
It is a runtime idle system and hardware reduced.
On that kind of system, lid open is handled by OS not by BIOS.
Surface 3 is exactly the platform that doesn't send lid open notification.
I guess the AML is intentionally written in this way to be compliant to the 
traditional platforms.

While on the traditional platforms:
When lid is opened, BIOS handles the lid irq and wakes the system from the FACS 
waking vector.
So it is likely that there is no lid open irq after the system is resumed.
BIOS may forget to update the cached lid value in the _WAK or some other 
control methods that could be executed after resuming.
Then if we send _LID result to the user space, the cached value could 
apparently be 'close'.

That explains why there is no "lid open" configuration in the "Windows Device 
Manager".

> 
> I propose as a workaround to enable a kthread that will monitor the
> lid state and update the correct value to userspace (5 sec of polling
> time should be enough given that systemd checks every 20 sec).
> We should 

Re: shrink_active_list/try_to_release_page bug? (was Re: xfs trace in 4.4.2 / also in 4.3.3 WARNING fs/xfs/xfs_aops.c:1232 xfs_vm_releasepage)

[Dave Chinner]

On Tue, May 31, 2016 at 10:07:24AM +0900, Minchan Kim wrote:
> On Tue, May 31, 2016 at 08:36:57AM +1000, Dave Chinner wrote:
> > [adding lkml and linux-mm to the cc list]
> > 
> > On Mon, May 30, 2016 at 09:23:48AM +0200, Stefan Priebe - Profihost AG 
> > wrote:
> > > Hi Dave,
> > >   Hi Brian,
> > > 
> > > below are the results with a vanilla 4.4.11 kernel.
> > 
> > Thanks for persisting with the testing, Stefan.
> > 
> > 
> > 
> > > i've now used a vanilla 4.4.11 Kernel and the issue remains. After a
> > > fresh reboot it has happened again on the root FS for a debian apt file:
> > > 
> > > XFS (md127p3): ino 0x41221d1 delalloc 1 unwritten 0 pgoff 0x0 size 
> > > 0x12b990
> > > [ cut here ]
> > > WARNING: CPU: 1 PID: 111 at fs/xfs/xfs_aops.c:1239
> > > xfs_vm_releasepage+0x10f/0x140()
> > > Modules linked in: netconsole ipt_REJECT nf_reject_ipv4 xt_multiport
> > > iptable_filter ip_tables x_tables bonding coretemp 8021q garp fuse
> > > sb_edac edac_core i2c_i801 i40e(O) xhci_pci xhci_hcd shpchp vxlan
> > > ip6_udp_tunnel udp_tunnel ipmi_si ipmi_msghandler button btrfs xor
> > > raid6_pq dm_mod raid1 md_mod usbhid usb_storage ohci_hcd sg sd_mod
> > > ehci_pci ehci_hcd usbcore usb_common igb ahci i2c_algo_bit libahci
> > > i2c_core mpt3sas ptp pps_core raid_class scsi_transport_sas
> > > CPU: 1 PID: 111 Comm: kswapd0 Tainted: G   O4.4.11 #1
> > > Hardware name: Supermicro Super Server/X10SRH-CF, BIOS 1.0b 05/18/2015
> > >   880c4dacfa88 a23c5b8f 
> > >  a2a51ab4 880c4dacfac8 a20837a7 880c4dacfae8
> > >  0001 ea00010c3640 8802176b49d0 ea00010c3660
> > > Call Trace:
> > >  [] dump_stack+0x63/0x84
> > >  [] warn_slowpath_common+0x97/0xe0
> > >  [] warn_slowpath_null+0x1a/0x20
> > >  [] xfs_vm_releasepage+0x10f/0x140
> > >  [] ? page_mkclean_one+0xd0/0xd0
> > >  [] ? anon_vma_prepare+0x150/0x150
> > >  [] try_to_release_page+0x32/0x50
> > >  [] shrink_active_list+0x3ce/0x3e0
> > >  [] shrink_lruvec+0x687/0x7d0
> > >  [] shrink_zone+0xdc/0x2c0
> > >  [] kswapd+0x4f9/0x970
> > >  [] ? mem_cgroup_shrink_node_zone+0x1a0/0x1a0
> > >  [] kthread+0xc9/0xe0
> > >  [] ? kthread_stop+0x100/0x100
> > >  [] ret_from_fork+0x3f/0x70
> > >  [] ? kthread_stop+0x100/0x100
> > > ---[ end trace c9d679f8ed4d7610 ]---
> > > XFS (md127p3): ino 0x41221d1 delalloc 1 unwritten 0 pgoff 0x1000 size
> > > 0x12b990
> > > XFS (md127p3): ino 0x41221d1 delalloc 1 unwritten 0 pgoff 0x2000 size
> > .
> > 
> > Ok, I suspect this may be a VM bug. I've been looking at the 4.6
> > code (so please try to reproduce on that kernel!) but it looks to me
> > like the only way we can get from shrink_active_list() direct to
> > try_to_release_page() is if we are over the maximum bufferhead
> > threshold (i.e buffer_heads_over_limit = true) and we are trying to
> > reclaim pages direct from the active list.
> > 
> > Because we are called from kswapd()->balance_pgdat(), we have:
> > 
> > struct scan_control sc = {
> > .gfp_mask = GFP_KERNEL,
> > .order = order,
> > .priority = DEF_PRIORITY,
> > .may_writepage = !laptop_mode,
> > .may_unmap = 1,
> > .may_swap = 1,
> > };
> > 
> > The key point here is reclaim is being run with .may_writepage =
> > true for default configuration kernels. when we get to
> > shrink_active_list():
> > 
> > if (!sc->may_writepage)
> > isolate_mode |= ISOLATE_CLEAN;
> > 
> > But sc->may_writepage = true and this allows isolate_lru_pages() to
> > isolate dirty pages from the active list. Normally this isn't a
> > problem, because the isolated active list pages are rotated to the
> > inactive list, and nothing else happens to them. *Except when
> > buffer_heads_over_limit = true*. This special condition would
> > explain why I have never seen apt/dpkg cause this problem on any of
> > my (many) Debian systems that all use XFS
> > 
> > In that case, shrink_active_list() runs:
> > 
> > if (unlikely(buffer_heads_over_limit)) {
> > if (page_has_private(page) && trylock_page(page)) {
> > if (page_has_private(page))
> > try_to_release_page(page, 0);
> > unlock_page(page);
> > }
> > }
> > 
> > i.e. it locks the page, and if it has buffer heads it trys to get
> > the bufferheads freed from the page.
> > 
> > But this is a dirty page, which means it may have delalloc or
> > unwritten state on it's buffers, both of which indicate that there
> > is dirty data in teh page that hasn't been written. XFS issues a
> > warning on this because neither shrink_active_list nor
> > try_to_release_page() check for whether the page is dirty or not.
> > 
> > Hence it seems to me that shrink_active_list() is calling
> > try_to_release_page() inappropriately, and XFS is just the
> > messenger. If 

Re: shrink_active_list/try_to_release_page bug? (was Re: xfs trace in 4.4.2 / also in 4.3.3 WARNING fs/xfs/xfs_aops.c:1232 xfs_vm_releasepage)

[Dave Chinner]

On Tue, May 31, 2016 at 10:07:24AM +0900, Minchan Kim wrote:
> On Tue, May 31, 2016 at 08:36:57AM +1000, Dave Chinner wrote:
> > [adding lkml and linux-mm to the cc list]
> > 
> > On Mon, May 30, 2016 at 09:23:48AM +0200, Stefan Priebe - Profihost AG 
> > wrote:
> > > Hi Dave,
> > >   Hi Brian,
> > > 
> > > below are the results with a vanilla 4.4.11 kernel.
> > 
> > Thanks for persisting with the testing, Stefan.
> > 
> > 
> > 
> > > i've now used a vanilla 4.4.11 Kernel and the issue remains. After a
> > > fresh reboot it has happened again on the root FS for a debian apt file:
> > > 
> > > XFS (md127p3): ino 0x41221d1 delalloc 1 unwritten 0 pgoff 0x0 size 
> > > 0x12b990
> > > [ cut here ]
> > > WARNING: CPU: 1 PID: 111 at fs/xfs/xfs_aops.c:1239
> > > xfs_vm_releasepage+0x10f/0x140()
> > > Modules linked in: netconsole ipt_REJECT nf_reject_ipv4 xt_multiport
> > > iptable_filter ip_tables x_tables bonding coretemp 8021q garp fuse
> > > sb_edac edac_core i2c_i801 i40e(O) xhci_pci xhci_hcd shpchp vxlan
> > > ip6_udp_tunnel udp_tunnel ipmi_si ipmi_msghandler button btrfs xor
> > > raid6_pq dm_mod raid1 md_mod usbhid usb_storage ohci_hcd sg sd_mod
> > > ehci_pci ehci_hcd usbcore usb_common igb ahci i2c_algo_bit libahci
> > > i2c_core mpt3sas ptp pps_core raid_class scsi_transport_sas
> > > CPU: 1 PID: 111 Comm: kswapd0 Tainted: G   O4.4.11 #1
> > > Hardware name: Supermicro Super Server/X10SRH-CF, BIOS 1.0b 05/18/2015
> > >   880c4dacfa88 a23c5b8f 
> > >  a2a51ab4 880c4dacfac8 a20837a7 880c4dacfae8
> > >  0001 ea00010c3640 8802176b49d0 ea00010c3660
> > > Call Trace:
> > >  [] dump_stack+0x63/0x84
> > >  [] warn_slowpath_common+0x97/0xe0
> > >  [] warn_slowpath_null+0x1a/0x20
> > >  [] xfs_vm_releasepage+0x10f/0x140
> > >  [] ? page_mkclean_one+0xd0/0xd0
> > >  [] ? anon_vma_prepare+0x150/0x150
> > >  [] try_to_release_page+0x32/0x50
> > >  [] shrink_active_list+0x3ce/0x3e0
> > >  [] shrink_lruvec+0x687/0x7d0
> > >  [] shrink_zone+0xdc/0x2c0
> > >  [] kswapd+0x4f9/0x970
> > >  [] ? mem_cgroup_shrink_node_zone+0x1a0/0x1a0
> > >  [] kthread+0xc9/0xe0
> > >  [] ? kthread_stop+0x100/0x100
> > >  [] ret_from_fork+0x3f/0x70
> > >  [] ? kthread_stop+0x100/0x100
> > > ---[ end trace c9d679f8ed4d7610 ]---
> > > XFS (md127p3): ino 0x41221d1 delalloc 1 unwritten 0 pgoff 0x1000 size
> > > 0x12b990
> > > XFS (md127p3): ino 0x41221d1 delalloc 1 unwritten 0 pgoff 0x2000 size
> > .
> > 
> > Ok, I suspect this may be a VM bug. I've been looking at the 4.6
> > code (so please try to reproduce on that kernel!) but it looks to me
> > like the only way we can get from shrink_active_list() direct to
> > try_to_release_page() is if we are over the maximum bufferhead
> > threshold (i.e buffer_heads_over_limit = true) and we are trying to
> > reclaim pages direct from the active list.
> > 
> > Because we are called from kswapd()->balance_pgdat(), we have:
> > 
> > struct scan_control sc = {
> > .gfp_mask = GFP_KERNEL,
> > .order = order,
> > .priority = DEF_PRIORITY,
> > .may_writepage = !laptop_mode,
> > .may_unmap = 1,
> > .may_swap = 1,
> > };
> > 
> > The key point here is reclaim is being run with .may_writepage =
> > true for default configuration kernels. when we get to
> > shrink_active_list():
> > 
> > if (!sc->may_writepage)
> > isolate_mode |= ISOLATE_CLEAN;
> > 
> > But sc->may_writepage = true and this allows isolate_lru_pages() to
> > isolate dirty pages from the active list. Normally this isn't a
> > problem, because the isolated active list pages are rotated to the
> > inactive list, and nothing else happens to them. *Except when
> > buffer_heads_over_limit = true*. This special condition would
> > explain why I have never seen apt/dpkg cause this problem on any of
> > my (many) Debian systems that all use XFS
> > 
> > In that case, shrink_active_list() runs:
> > 
> > if (unlikely(buffer_heads_over_limit)) {
> > if (page_has_private(page) && trylock_page(page)) {
> > if (page_has_private(page))
> > try_to_release_page(page, 0);
> > unlock_page(page);
> > }
> > }
> > 
> > i.e. it locks the page, and if it has buffer heads it trys to get
> > the bufferheads freed from the page.
> > 
> > But this is a dirty page, which means it may have delalloc or
> > unwritten state on it's buffers, both of which indicate that there
> > is dirty data in teh page that hasn't been written. XFS issues a
> > warning on this because neither shrink_active_list nor
> > try_to_release_page() check for whether the page is dirty or not.
> > 
> > Hence it seems to me that shrink_active_list() is calling
> > try_to_release_page() inappropriately, and XFS is just the
> > messenger. If 

linux-next: build warnings after merge of the rtc tree

[Stephen Rothwell]

Hi Alexandre,

After merging the rtc tree, today's linux-next build (x86_64 allmodconfig)
produced these warnings:

In file included from drivers/char/mwave/smapi.c:51:0:
drivers/char/mwave/smapi.h:52:0: warning: "TRUE" redefined
 #define TRUE 1
 ^
In file included from include/acpi/acpi.h:58:0,
 from include/linux/acpi.h:33,
 from include/linux/mc146818rtc.h:21,
 from drivers/char/mwave/smapi.c:50:
include/acpi/actypes.h:438:0: note: this is the location of the previous 
definition
 #define TRUE(1 == 1)
 ^
In file included from drivers/char/mwave/smapi.c:51:0:
drivers/char/mwave/smapi.h:53:0: warning: "FALSE" redefined
 #define FALSE 0
 ^
In file included from include/acpi/acpi.h:58:0,
 from include/linux/acpi.h:33,
 from include/linux/mc146818rtc.h:21,
 from drivers/char/mwave/smapi.c:50:
include/acpi/actypes.h:433:0: note: this is the location of the previous 
definition
 #define FALSE   (1 == 0)
 ^

Introduced by commit

  fd09cc80165c ("rtc: cmos: move mc146818rtc code out of asm-generic/rtc.h")

Why the hell do we have any definitions of TRUE and FALSE, anyway?
There are a few more (I counted 4 in header files before stopping).

Hmmm, those 2 static inline functions in include/linux/mc146818rtc.h
that reference ACPI stuff are probably to big to be inline and in a header
file anyway, right?

-- 
Cheers,
Stephen Rothwell

linux-next: build warnings after merge of the rtc tree

[Stephen Rothwell]

Hi Alexandre,

After merging the rtc tree, today's linux-next build (x86_64 allmodconfig)
produced these warnings:

In file included from drivers/char/mwave/smapi.c:51:0:
drivers/char/mwave/smapi.h:52:0: warning: "TRUE" redefined
 #define TRUE 1
 ^
In file included from include/acpi/acpi.h:58:0,
 from include/linux/acpi.h:33,
 from include/linux/mc146818rtc.h:21,
 from drivers/char/mwave/smapi.c:50:
include/acpi/actypes.h:438:0: note: this is the location of the previous 
definition
 #define TRUE(1 == 1)
 ^
In file included from drivers/char/mwave/smapi.c:51:0:
drivers/char/mwave/smapi.h:53:0: warning: "FALSE" redefined
 #define FALSE 0
 ^
In file included from include/acpi/acpi.h:58:0,
 from include/linux/acpi.h:33,
 from include/linux/mc146818rtc.h:21,
 from drivers/char/mwave/smapi.c:50:
include/acpi/actypes.h:433:0: note: this is the location of the previous 
definition
 #define FALSE   (1 == 0)
 ^

Introduced by commit

  fd09cc80165c ("rtc: cmos: move mc146818rtc code out of asm-generic/rtc.h")

Why the hell do we have any definitions of TRUE and FALSE, anyway?
There are a few more (I counted 4 in header files before stopping).

Hmmm, those 2 static inline functions in include/linux/mc146818rtc.h
that reference ACPI stuff are probably to big to be inline and in a header
file anyway, right?

-- 
Cheers,
Stephen Rothwell

Re: [gpio] 86ea8a95a4: kernel BUG at drivers/base/driver.c:153!

[William Breathitt Gray]

>
>
>FYI, raw QEMU command line is:
>
>   qemu-system-i386 -enable-kvm -cpu Haswell,+smep,+smap -kernel 
> /pkg/linux/i386-randconfig-x0-05280946/gcc-6/86ea8a95a42f752fe0aa1c7ad1bfe8ce9be5d30e/vmlinuz-4.6.0-rc4-00031-g86ea8a9
>  -append 'root=/dev/ram0 user=lkp 
> job=/lkp/scheduled/vm-vp-quantal-i386-61/bisect_boot-1-quantal-core-i386.cgz-i386-randconfig-x0-05280946-86ea8a95a42f752fe0aa1c7ad1bfe8ce9be5d30e-20160530-53474-w6nzwk-0.yaml
>  ARCH=i386 kconfig=i386-randconfig-x0-05280946 
> branch=linux-devel/devel-spot-201605280759 
> commit=86ea8a95a42f752fe0aa1c7ad1bfe8ce9be5d30e 
> BOOT_IMAGE=/pkg/linux/i386-randconfig-x0-05280946/gcc-6/86ea8a95a42f752fe0aa1c7ad1bfe8ce9be5d30e/vmlinuz-4.6.0-rc4-00031-g86ea8a9
>  max_uptime=600 
> RESULT_ROOT=/result/boot/1/vm-vp-quantal-i386/quantal-core-i386.cgz/i386-randconfig-x0-05280946/gcc-6/86ea8a95a42f752fe0aa1c7ad1bfe8ce9be5d30e/0
>  LKP_SERVER=inn 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 
> ip=vm-vp-quantal-i386-61::dhcp drbd.minor_count=8'  -initrd 
> /fs/sdd1/initrd-vm-vp-quantal-i386-61 -m 360 -smp 1 -device e1000,netdev=net0 
> -netdev user,id=net0 -boot order=nc -no-reboot -watchdog i6300esb -rtc 
> base=localtime -pidfile /dev/shm/kboot/pid-vm-vp-quantal-i386-61 -serial 
> file:/dev/shm/kboot/serial-vm-vp-quantal-i386-61 -daemonize -display none 
> -monitor null 
>
>
>
>
>
>Thanks,
>Xiaolong

Hello,

I believe this bug occurs when isa_register_driver is called before
isa_bus_init; this is possible with built-in drivers since isa_bus_init
is registered via device_initcall within the drivers/base/isa.c file.

I submitted a patch addressing this on May 11; see:
https://lkml.org/lkml/2016/5/11/857.

Let me know if this fixes the bug, or if there are any other issues.

Thank you,

William Breathitt Gray

Re: [gpio] 86ea8a95a4: kernel BUG at drivers/base/driver.c:153!

[William Breathitt Gray]

>
>
>FYI, raw QEMU command line is:
>
>   qemu-system-i386 -enable-kvm -cpu Haswell,+smep,+smap -kernel 
> /pkg/linux/i386-randconfig-x0-05280946/gcc-6/86ea8a95a42f752fe0aa1c7ad1bfe8ce9be5d30e/vmlinuz-4.6.0-rc4-00031-g86ea8a9
>  -append 'root=/dev/ram0 user=lkp 
> job=/lkp/scheduled/vm-vp-quantal-i386-61/bisect_boot-1-quantal-core-i386.cgz-i386-randconfig-x0-05280946-86ea8a95a42f752fe0aa1c7ad1bfe8ce9be5d30e-20160530-53474-w6nzwk-0.yaml
>  ARCH=i386 kconfig=i386-randconfig-x0-05280946 
> branch=linux-devel/devel-spot-201605280759 
> commit=86ea8a95a42f752fe0aa1c7ad1bfe8ce9be5d30e 
> BOOT_IMAGE=/pkg/linux/i386-randconfig-x0-05280946/gcc-6/86ea8a95a42f752fe0aa1c7ad1bfe8ce9be5d30e/vmlinuz-4.6.0-rc4-00031-g86ea8a9
>  max_uptime=600 
> RESULT_ROOT=/result/boot/1/vm-vp-quantal-i386/quantal-core-i386.cgz/i386-randconfig-x0-05280946/gcc-6/86ea8a95a42f752fe0aa1c7ad1bfe8ce9be5d30e/0
>  LKP_SERVER=inn 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 
> ip=vm-vp-quantal-i386-61::dhcp drbd.minor_count=8'  -initrd 
> /fs/sdd1/initrd-vm-vp-quantal-i386-61 -m 360 -smp 1 -device e1000,netdev=net0 
> -netdev user,id=net0 -boot order=nc -no-reboot -watchdog i6300esb -rtc 
> base=localtime -pidfile /dev/shm/kboot/pid-vm-vp-quantal-i386-61 -serial 
> file:/dev/shm/kboot/serial-vm-vp-quantal-i386-61 -daemonize -display none 
> -monitor null 
>
>
>
>
>
>Thanks,
>Xiaolong

Hello,

I believe this bug occurs when isa_register_driver is called before
isa_bus_init; this is possible with built-in drivers since isa_bus_init
is registered via device_initcall within the drivers/base/isa.c file.

I submitted a patch addressing this on May 11; see:
https://lkml.org/lkml/2016/5/11/857.

Let me know if this fixes the bug, or if there are any other issues.

Thank you,

William Breathitt Gray

Re: [PATCH v5 0/2] skb_array: array based FIFO for skbs

[Jason Wang]

On 2016年05月30日 23:37, Michael S. Tsirkin wrote:

On Mon, May 30, 2016 at 05:59:33PM +0800, Jason Wang wrote:


On 2016年05月23日 18:43, Michael S. Tsirkin wrote:

This is in response to the proposal by Jason to make tun
rx packet queue lockless using a circular buffer.
My testing seems to show that at least for the common usecase
in networking, which isn't lockless, circular buffer
with indices does not perform that well, because
each index access causes a cache line to bounce between
CPUs, and index access causes stalls due to the dependency.

I change tun to use skb array, looks like it can give about 5% more faster
than skb ring.

OK and skb ring is 9% faster than the linked list, so together
this is a 14% speedup?


Right.




And we usually don't need touch bhs during consume and produce (e.g for the
case of tun).

Thanks

Maybe I'll drop it in v6 then ...
Could you post the full tun patchset please?



Since it needs no bh versions of produce/consume, maybe you can post v6 
first, then I can post the tun patches?

Re: [PATCH v3 1/1] ovl: setxattr: don't deadlock when called from ima_fix_xattr.

[Mimi Zohar]

On Mon, 2016-05-30 at 16:10 +0200, Miklos Szeredi wrote:
> On Fri, May 20, 2016 at 11:53:18PM +0300, Krisztian Litkey wrote:
> > On Fri, May 20, 2016 at 8:00 PM, Mimi Zohar  
> > wrote:
> 
> > > We deferred __fput() back in 2012 in order for IMA to safely take the
> > > i_mutex and write security.ima.   Writing the security.ima xattr now
> > > triggers overlayfs to write the xattr, but overlayfs doesn't
> > > differentiate between callers - as a result of userspace or as described
> > > here in __fput().   All calls to ovl_setxattr() should call vfs_sexattr,
> > > except the one triggered by __fput().   Refer to the original lockdep
> > > report -
> > > http://thread.gmane.org/gmane.linux.file-systems.union/640
> 
> Looks like more fallout from 4bacc9c9234c ("overlayfs: Make f_path always 
> point
> to the overlay and f_inode to the underlay").
> 
> Not sure what we want here.  Doing everything on the underlying dentry/inode
> would be trivial (see attached patch).
> 
> Question is, can we get setxattr() on file opened for O_RDONLY?  If so, then
> that could fail on overlayfs (lower layer is read-only).

Normally only after a file has been modified is the xattr written.
However in "fix" mode, the xattr would be written for files opened
read-only (eg. bprm, mmap execute).

Mimi

Re: [PATCH v5 0/2] skb_array: array based FIFO for skbs

[Jason Wang]

On 2016年05月30日 23:37, Michael S. Tsirkin wrote:

On Mon, May 30, 2016 at 05:59:33PM +0800, Jason Wang wrote:


On 2016年05月23日 18:43, Michael S. Tsirkin wrote:

This is in response to the proposal by Jason to make tun
rx packet queue lockless using a circular buffer.
My testing seems to show that at least for the common usecase
in networking, which isn't lockless, circular buffer
with indices does not perform that well, because
each index access causes a cache line to bounce between
CPUs, and index access causes stalls due to the dependency.

I change tun to use skb array, looks like it can give about 5% more faster
than skb ring.

OK and skb ring is 9% faster than the linked list, so together
this is a 14% speedup?


Right.




And we usually don't need touch bhs during consume and produce (e.g for the
case of tun).

Thanks

Maybe I'll drop it in v6 then ...
Could you post the full tun patchset please?



Since it needs no bh versions of produce/consume, maybe you can post v6 
first, then I can post the tun patches?

Re: [PATCH v3 1/1] ovl: setxattr: don't deadlock when called from ima_fix_xattr.

[Mimi Zohar]

On Mon, 2016-05-30 at 16:10 +0200, Miklos Szeredi wrote:
> On Fri, May 20, 2016 at 11:53:18PM +0300, Krisztian Litkey wrote:
> > On Fri, May 20, 2016 at 8:00 PM, Mimi Zohar  
> > wrote:
> 
> > > We deferred __fput() back in 2012 in order for IMA to safely take the
> > > i_mutex and write security.ima.   Writing the security.ima xattr now
> > > triggers overlayfs to write the xattr, but overlayfs doesn't
> > > differentiate between callers - as a result of userspace or as described
> > > here in __fput().   All calls to ovl_setxattr() should call vfs_sexattr,
> > > except the one triggered by __fput().   Refer to the original lockdep
> > > report -
> > > http://thread.gmane.org/gmane.linux.file-systems.union/640
> 
> Looks like more fallout from 4bacc9c9234c ("overlayfs: Make f_path always 
> point
> to the overlay and f_inode to the underlay").
> 
> Not sure what we want here.  Doing everything on the underlying dentry/inode
> would be trivial (see attached patch).
> 
> Question is, can we get setxattr() on file opened for O_RDONLY?  If so, then
> that could fail on overlayfs (lower layer is read-only).

Normally only after a file has been modified is the xattr written.
However in "fix" mode, the xattr would be written for files opened
read-only (eg. bprm, mmap execute).

Mimi

Re: [PATCH v4] Axi-usb: Add support for 64-bit addressing.

[Shubhrajyoti Datta]

On Mon, May 30, 2016 at 10:16 PM, Nava kishore Manne
 wrote:
> This patch updates the driver to support 64-bit DMA addressing.
>
> Signed-off-by: Nava kishore Manne 
> ---
> Changes for v4:
> -Used boolen property insted of addrwith property in the DT
>  as suggested by Arnd Bergmann.
> -Adopt the DT relevant changes into the driver.
>
> Changes for v3:
> -Added new compatable string for 5.00 IP version as suggested 
> by
>  Arnd Bergmann.
> -Used write_fn() insted of lo_hi_writeq() as suggested by
>  Arnd Bergmann.
>
> Changes for v2:
> -Added dma-ranges property in device tree as suggested by 
> Arnd Bergmann.
> -Modified the driver code based on the xlnx,addrwidth.
>
>  .../devicetree/bindings/usb/udc-xilinx.txt |  5 ++-
>  drivers/usb/gadget/udc/udc-xilinx.c| 52 
> +-
>  2 files changed, 54 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/udc-xilinx.txt 
> b/Documentation/devicetree/bindings/usb/udc-xilinx.txt
> index 47b4e39..d08d972 100644
> --- a/Documentation/devicetree/bindings/usb/udc-xilinx.txt
> +++ b/Documentation/devicetree/bindings/usb/udc-xilinx.txt
> @@ -1,12 +1,14 @@
>  Xilinx USB2 device controller
>
>  Required properties:
> -- compatible   : Should be "xlnx,usb2-device-4.00.a"
> +- compatible   : Should be "xlnx,usb2-device-4.00.a" or
> + "xlnx,usb2-device-5.00"
>  - reg  : Physical base address and size of the USB2
>   device registers map.
>  - interrupts   : Should contain single irq line of USB2 device
>   controller
>  - xlnx,has-builtin-dma : if DMA is included
> +- xlnx,has-64bit-dma   : if DMA is included 64-bit addressing support.
>
>  Example:
> axi-usb2-device@42e0 {
> @@ -14,5 +16,6 @@ Example:
>  interrupts = <0x0 0x39 0x1>;
>  reg = <0x42e0 0x1>;
>  xlnx,has-builtin-dma;
> +   xlnx,has-64bit-dma;
>  };
>
> diff --git a/drivers/usb/gadget/udc/udc-xilinx.c 
> b/drivers/usb/gadget/udc/udc-xilinx.c
> index 1cbb0ac..6fb80c6 100644
> --- a/drivers/usb/gadget/udc/udc-xilinx.c
> +++ b/drivers/usb/gadget/udc/udc-xilinx.c
> @@ -47,6 +47,15 @@
>  #define XUSB_DMA_LENGTH_OFFSET 0x0210  /* DMA Length Register */
>  #define XUSB_DMA_STATUS_OFFSET 0x0214  /* DMA Status Register */
>
> +/* DMA source Address Reg for LSB */
> +#define XUSB_DMA_DSAR_ADDR_OFFSET_LSB   0x0308
> +/* DMA source Address Reg for MSB */
> +#define XUSB_DMA_DSAR_ADDR_OFFSET_MSB   0x030C
> +/* DMA destination Addr Reg LSB */
> +#define XUSB_DMA_DDAR_ADDR_OFFSET_LSB   0x0310
> +/* DMA destination Addr Reg MSB */
> +#define XUSB_DMA_DDAR_ADDR_OFFSET_MSB   0x0314
> +
>  /* Endpoint Configuration Space offsets */
>  #define XUSB_EP_CFGSTATUS_OFFSET   0x00/* Endpoint Config Status  */
>  #define XUSB_EP_BUF0COUNT_OFFSET   0x08/* Buffer 0 Count */
> @@ -169,6 +178,7 @@ struct xusb_ep {
>   * @setup: usb_ctrlrequest structure for control requests
>   * @req: pointer to dummy request for get status command
>   * @dev: pointer to device structure in gadget
> + * @is_extend_dma: flag indiacting whether the dma is 64-bit support or not.
>   * @usb_state: device in suspended state or not
>   * @remote_wkp: remote wakeup enabled by host
>   * @setupseqtx: tx status
> @@ -186,6 +196,7 @@ struct xusb_udc {
> struct usb_ctrlrequest setup;
> struct xusb_req *req;
> struct device *dev;
> +   bool is_extend_dma;
> u32 usb_state;
> u32 remote_wkp;
> u32 setupseqtx;
> @@ -215,6 +226,20 @@ static const struct usb_endpoint_descriptor 
> config_bulk_out_desc = {
>  };
>
>  /**
> + * xudc_write64 - write 64bit value to device registers
> + * @ep: pointer to the usb device endpoint structure.
> + * @offset: register offset
> + * @val: data to be written
> + **/
> +static void xudc_write64(struct xusb_ep *ep, u32 offset, u64 val)
> +{
> +   struct xusb_udc *udc = ep->udc;
> +
> +   udc->write_fn(udc->addr, offset, lower_32_bits(val));
> +   udc->write_fn(udc->addr, offset+0x04, upper_32_bits(val));

can we move this to a single 64 bit write?
> +}
> +
> +/**

Re: [PATCH v4] Axi-usb: Add support for 64-bit addressing.

[Shubhrajyoti Datta]

On Mon, May 30, 2016 at 10:16 PM, Nava kishore Manne
 wrote:
> This patch updates the driver to support 64-bit DMA addressing.
>
> Signed-off-by: Nava kishore Manne 
> ---
> Changes for v4:
> -Used boolen property insted of addrwith property in the DT
>  as suggested by Arnd Bergmann.
> -Adopt the DT relevant changes into the driver.
>
> Changes for v3:
> -Added new compatable string for 5.00 IP version as suggested 
> by
>  Arnd Bergmann.
> -Used write_fn() insted of lo_hi_writeq() as suggested by
>  Arnd Bergmann.
>
> Changes for v2:
> -Added dma-ranges property in device tree as suggested by 
> Arnd Bergmann.
> -Modified the driver code based on the xlnx,addrwidth.
>
>  .../devicetree/bindings/usb/udc-xilinx.txt |  5 ++-
>  drivers/usb/gadget/udc/udc-xilinx.c| 52 
> +-
>  2 files changed, 54 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/udc-xilinx.txt 
> b/Documentation/devicetree/bindings/usb/udc-xilinx.txt
> index 47b4e39..d08d972 100644
> --- a/Documentation/devicetree/bindings/usb/udc-xilinx.txt
> +++ b/Documentation/devicetree/bindings/usb/udc-xilinx.txt
> @@ -1,12 +1,14 @@
>  Xilinx USB2 device controller
>
>  Required properties:
> -- compatible   : Should be "xlnx,usb2-device-4.00.a"
> +- compatible   : Should be "xlnx,usb2-device-4.00.a" or
> + "xlnx,usb2-device-5.00"
>  - reg  : Physical base address and size of the USB2
>   device registers map.
>  - interrupts   : Should contain single irq line of USB2 device
>   controller
>  - xlnx,has-builtin-dma : if DMA is included
> +- xlnx,has-64bit-dma   : if DMA is included 64-bit addressing support.
>
>  Example:
> axi-usb2-device@42e0 {
> @@ -14,5 +16,6 @@ Example:
>  interrupts = <0x0 0x39 0x1>;
>  reg = <0x42e0 0x1>;
>  xlnx,has-builtin-dma;
> +   xlnx,has-64bit-dma;
>  };
>
> diff --git a/drivers/usb/gadget/udc/udc-xilinx.c 
> b/drivers/usb/gadget/udc/udc-xilinx.c
> index 1cbb0ac..6fb80c6 100644
> --- a/drivers/usb/gadget/udc/udc-xilinx.c
> +++ b/drivers/usb/gadget/udc/udc-xilinx.c
> @@ -47,6 +47,15 @@
>  #define XUSB_DMA_LENGTH_OFFSET 0x0210  /* DMA Length Register */
>  #define XUSB_DMA_STATUS_OFFSET 0x0214  /* DMA Status Register */
>
> +/* DMA source Address Reg for LSB */
> +#define XUSB_DMA_DSAR_ADDR_OFFSET_LSB   0x0308
> +/* DMA source Address Reg for MSB */
> +#define XUSB_DMA_DSAR_ADDR_OFFSET_MSB   0x030C
> +/* DMA destination Addr Reg LSB */
> +#define XUSB_DMA_DDAR_ADDR_OFFSET_LSB   0x0310
> +/* DMA destination Addr Reg MSB */
> +#define XUSB_DMA_DDAR_ADDR_OFFSET_MSB   0x0314
> +
>  /* Endpoint Configuration Space offsets */
>  #define XUSB_EP_CFGSTATUS_OFFSET   0x00/* Endpoint Config Status  */
>  #define XUSB_EP_BUF0COUNT_OFFSET   0x08/* Buffer 0 Count */
> @@ -169,6 +178,7 @@ struct xusb_ep {
>   * @setup: usb_ctrlrequest structure for control requests
>   * @req: pointer to dummy request for get status command
>   * @dev: pointer to device structure in gadget
> + * @is_extend_dma: flag indiacting whether the dma is 64-bit support or not.
>   * @usb_state: device in suspended state or not
>   * @remote_wkp: remote wakeup enabled by host
>   * @setupseqtx: tx status
> @@ -186,6 +196,7 @@ struct xusb_udc {
> struct usb_ctrlrequest setup;
> struct xusb_req *req;
> struct device *dev;
> +   bool is_extend_dma;
> u32 usb_state;
> u32 remote_wkp;
> u32 setupseqtx;
> @@ -215,6 +226,20 @@ static const struct usb_endpoint_descriptor 
> config_bulk_out_desc = {
>  };
>
>  /**
> + * xudc_write64 - write 64bit value to device registers
> + * @ep: pointer to the usb device endpoint structure.
> + * @offset: register offset
> + * @val: data to be written
> + **/
> +static void xudc_write64(struct xusb_ep *ep, u32 offset, u64 val)
> +{
> +   struct xusb_udc *udc = ep->udc;
> +
> +   udc->write_fn(udc->addr, offset, lower_32_bits(val));
> +   udc->write_fn(udc->addr, offset+0x04, upper_32_bits(val));

can we move this to a single 64 bit write?
> +}
> +
> +/**

[gpio] 86ea8a95a4: kernel BUG at drivers/base/driver.c:153!

[kernel test robot]

FYI, we noticed the following commit:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 86ea8a95a42f752fe0aa1c7ad1bfe8ce9be5d30e ("gpio: 104-idio-16: Utilize 
the ISA bus driver")


on test machine: vm-vp-quantal-i386: 1 threads qemu-system-i386 -enable-kvm 
-cpu Haswell,+smep,+smap with 360M memory

caused below changes:


+--+++
|  | 72bf7443ba 
| 86ea8a95a4 |
+--+++
| boot_successes   | 0  
| 0  |
| boot_failures| 12 
| 12 |
| invoked_oom-killer:gfp_mask=0x   | 12 
||
| Mem-Info | 12 
||
| Kernel_panic-not_syncing:Out_of_memory_and_no_killable_processes | 12 
||
| backtrace:btrfs_test_extent_io   | 12 
||
| backtrace:init_btrfs_fs  | 12 
||
| backtrace:kernel_init_freeable   | 12 
| 12 |
| page_allocation_failure:order:#,mode:#(GFP_KERNEL|__GFP_NORETRY) | 1  
||
| warn_alloc_failed+0x | 1  
||
| backtrace:ring_buffer_consumer_thread| 1  
||
| kernel_BUG_at_drivers/base/driver.c  | 0  
| 12 |
| invalid_opcode:#[##]SMP_DEBUG_PAGEALLOC  | 0  
| 12 |
| EIP_is_at_driver_register| 0  
| 12 |
| Kernel_panic-not_syncing:Fatal_exception | 0  
| 12 |
| backtrace:isa_register_driver| 0  
| 12 |
| backtrace:idio_16_driver_init| 0  
| 12 |
+--+++



[   10.002548] xz_dec_test: module loaded
[   10.003490] xz_dec_test: Create a device node with 'mknod xz_dec_test c 250 
0' and write .xz files to it.
[   10.005742] [ cut here ]
[   10.006773] kernel BUG at drivers/base/driver.c:153!
[   10.008042] invalid opcode:  [#1] SMP DEBUG_PAGEALLOC 
[   10.009379] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
4.6.0-rc4-00031-g86ea8a9 #1
[   10.011155] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[   10.013090] task: d3e6e000 ti: d3e78000 task.ti: d3e78000
[   10.014213] EIP: 0060:[] EFLAGS: 00010246 CPU: 0
[   10.015351] EIP is at driver_register+0x29/0xbc
[   10.016365] EAX: c1ec186c EBX: c1dea3d8 ECX:  EDX: 0001
[   10.017576] ESI:  EDI: c9fb9340 EBP: d3e79f00 ESP: d3e79ef8
[   10.018782]  DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
[   10.019897] CR0: 80050033 CR2:  CR3: 01fed000 CR4: 000406d0
[   10.021104] Stack:
[   10.021834]  c1dea3c0  d3e79f20 c15dedf7 0286  0286 
c1f23128
[   10.024194]   c9fb9340 d3e79f28 c1f2313b d3e79f84 c1ee7c5b d4d7a500 

[   10.026562]  d3e79f00 c106ee1e  c1d83ad4 00060006 c1d80bf4 0259 
d4d7a5f8
[   10.028924] Call Trace:
[   10.029702]  [] isa_register_driver+0x2b/0x11a
[   10.030806]  [] ? gpiolib_debugfs_init+0x1f/0x1f
[   10.031929]  [] idio_16_driver_init+0x13/0x15
[   10.033028]  [] do_one_initcall+0xf7/0x1a4
[   10.034092]  [] ? parse_args+0x282/0x38b
[   10.035143]  [] ? kernel_init_freeable+0x171/0x212
[   10.036287]  [] kernel_init_freeable+0x194/0x212
[   10.037418]  [] kernel_init+0xd/0xd5
[   10.038424]  [] ret_from_kernel_thread+0x21/0x38
[   10.039547]  [] ? rest_init+0x116/0x116
[   10.040576] Code: 5d c3 55 89 e5 56 53 3e 8d 74 26 00 31 d2 89 c3 8b 40 04 
8b 70 48 b8 6c 18 ec c1 85 f6 0f 94 c2 31 c9 e8 08 1c b2 ff 85 f6 75 02 <0f> 0b 
8b 43 04 83 78 24 00 74 06 83 7b 20 00 75 18 83 78 28 00
[   10.048568] EIP: [] driver_register+0x29/0xbc SS:ESP 0068:d3e79ef8
[   10.050047] ---[ end trace 7b29a3068007f652 ]---
[   10.066206] Kernel panic - not syncing: Fatal exception


FYI, raw QEMU command line is:

qemu-system-i386 -enable-kvm -cpu Haswell,+smep,+smap -kernel 
/pkg/linux/i386-randconfig-x0-05280946/gcc-6/86ea8a95a42f752fe0aa1c7ad1bfe8ce9be5d30e/vmlinuz-4.6.0-rc4-00031-g86ea8a9
 -append 'root=/dev/ram0 user=lkp 
job=/lkp/scheduled/vm-vp-quantal-i386-61/bisect_boot-1-quantal-core-i386.cgz-i386-randconfig-x0-05280946-86ea8a95a42f752fe0aa1c7ad1bfe8ce9be5d30e-20160530-53474-w6nzwk-0.yaml
 ARCH=i386 kconfig=i3

[gpio] 86ea8a95a4: kernel BUG at drivers/base/driver.c:153!

[kernel test robot]

FYI, we noticed the following commit:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 86ea8a95a42f752fe0aa1c7ad1bfe8ce9be5d30e ("gpio: 104-idio-16: Utilize 
the ISA bus driver")


on test machine: vm-vp-quantal-i386: 1 threads qemu-system-i386 -enable-kvm 
-cpu Haswell,+smep,+smap with 360M memory

caused below changes:


+--+++
|  | 72bf7443ba 
| 86ea8a95a4 |
+--+++
| boot_successes   | 0  
| 0  |
| boot_failures| 12 
| 12 |
| invoked_oom-killer:gfp_mask=0x   | 12 
||
| Mem-Info | 12 
||
| Kernel_panic-not_syncing:Out_of_memory_and_no_killable_processes | 12 
||
| backtrace:btrfs_test_extent_io   | 12 
||
| backtrace:init_btrfs_fs  | 12 
||
| backtrace:kernel_init_freeable   | 12 
| 12 |
| page_allocation_failure:order:#,mode:#(GFP_KERNEL|__GFP_NORETRY) | 1  
||
| warn_alloc_failed+0x | 1  
||
| backtrace:ring_buffer_consumer_thread| 1  
||
| kernel_BUG_at_drivers/base/driver.c  | 0  
| 12 |
| invalid_opcode:#[##]SMP_DEBUG_PAGEALLOC  | 0  
| 12 |
| EIP_is_at_driver_register| 0  
| 12 |
| Kernel_panic-not_syncing:Fatal_exception | 0  
| 12 |
| backtrace:isa_register_driver| 0  
| 12 |
| backtrace:idio_16_driver_init| 0  
| 12 |
+--+++



[   10.002548] xz_dec_test: module loaded
[   10.003490] xz_dec_test: Create a device node with 'mknod xz_dec_test c 250 
0' and write .xz files to it.
[   10.005742] [ cut here ]
[   10.006773] kernel BUG at drivers/base/driver.c:153!
[   10.008042] invalid opcode:  [#1] SMP DEBUG_PAGEALLOC 
[   10.009379] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
4.6.0-rc4-00031-g86ea8a9 #1
[   10.011155] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[   10.013090] task: d3e6e000 ti: d3e78000 task.ti: d3e78000
[   10.014213] EIP: 0060:[] EFLAGS: 00010246 CPU: 0
[   10.015351] EIP is at driver_register+0x29/0xbc
[   10.016365] EAX: c1ec186c EBX: c1dea3d8 ECX:  EDX: 0001
[   10.017576] ESI:  EDI: c9fb9340 EBP: d3e79f00 ESP: d3e79ef8
[   10.018782]  DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
[   10.019897] CR0: 80050033 CR2:  CR3: 01fed000 CR4: 000406d0
[   10.021104] Stack:
[   10.021834]  c1dea3c0  d3e79f20 c15dedf7 0286  0286 
c1f23128
[   10.024194]   c9fb9340 d3e79f28 c1f2313b d3e79f84 c1ee7c5b d4d7a500 

[   10.026562]  d3e79f00 c106ee1e  c1d83ad4 00060006 c1d80bf4 0259 
d4d7a5f8
[   10.028924] Call Trace:
[   10.029702]  [] isa_register_driver+0x2b/0x11a
[   10.030806]  [] ? gpiolib_debugfs_init+0x1f/0x1f
[   10.031929]  [] idio_16_driver_init+0x13/0x15
[   10.033028]  [] do_one_initcall+0xf7/0x1a4
[   10.034092]  [] ? parse_args+0x282/0x38b
[   10.035143]  [] ? kernel_init_freeable+0x171/0x212
[   10.036287]  [] kernel_init_freeable+0x194/0x212
[   10.037418]  [] kernel_init+0xd/0xd5
[   10.038424]  [] ret_from_kernel_thread+0x21/0x38
[   10.039547]  [] ? rest_init+0x116/0x116
[   10.040576] Code: 5d c3 55 89 e5 56 53 3e 8d 74 26 00 31 d2 89 c3 8b 40 04 
8b 70 48 b8 6c 18 ec c1 85 f6 0f 94 c2 31 c9 e8 08 1c b2 ff 85 f6 75 02 <0f> 0b 
8b 43 04 83 78 24 00 74 06 83 7b 20 00 75 18 83 78 28 00
[   10.048568] EIP: [] driver_register+0x29/0xbc SS:ESP 0068:d3e79ef8
[   10.050047] ---[ end trace 7b29a3068007f652 ]---
[   10.066206] Kernel panic - not syncing: Fatal exception


FYI, raw QEMU command line is:

qemu-system-i386 -enable-kvm -cpu Haswell,+smep,+smap -kernel 
/pkg/linux/i386-randconfig-x0-05280946/gcc-6/86ea8a95a42f752fe0aa1c7ad1bfe8ce9be5d30e/vmlinuz-4.6.0-rc4-00031-g86ea8a9
 -append 'root=/dev/ram0 user=lkp 
job=/lkp/scheduled/vm-vp-quantal-i386-61/bisect_boot-1-quantal-core-i386.cgz-i386-randconfig-x0-05280946-86ea8a95a42f752fe0aa1c7ad1bfe8ce9be5d30e-20160530-53474-w6nzwk-0.yaml
 ARCH=i386 kconfig=i3

[gpio] cc736607c8: kernel BUG at drivers/base/driver.c:153!

[kernel test robot]

FYI, we noticed the following commit:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit cc736607c86d39ea078519af0de6ee0fbf3096a6 ("gpio: ws16c48: Utilize the 
ISA bus driver")


on test machine: vm-kbuild-yocto-i386: 2 threads qemu-system-i386 -enable-kvm 
with 320M memory

caused below changes:


+---+++
|   | 86ea8a95a4 | 
cc736607c8 |
+---+++
| boot_successes| 11 | 0
  |
| boot_failures | 1  | 12   
  |
| BUG:unable_to_handle_kernel   | 1  |  
  |
| Oops  | 1  |  
  |
| EIP_is_at_perf_prepare_sample | 1  |  
  |
| Kernel_panic-not_syncing:Fatal_exception_in_interrupt | 1  |  
  |
| backtrace:vfs_fstatat | 1  |  
  |
| backtrace:SyS_fstatat64   | 1  |  
  |
| kernel_BUG_at_drivers/base/driver.c   | 0  | 12   
  |
| invalid_opcode:#[##]PREEMPT_SMP   | 0  | 12   
  |
| EIP_is_at_driver_register | 0  | 12   
  |
| Kernel_panic-not_syncing:Fatal_exception  | 0  | 12   
  |
| backtrace:ws16c48_driver_init | 0  | 12   
  |
| backtrace:kernel_init_freeable| 0  | 12   
  |
+---+++



[   25.433696] rbtree testing -> 28301 cycles
[   26.544836] augmented rbtree testing -> 42740 cycles
[   28.246337] [ cut here ]
[   28.246942] kernel BUG at drivers/base/driver.c:153!
[   28.247784] invalid opcode:  [#1] PREEMPT SMP 
[   28.248433] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
4.6.0-rc4-00032-gcc73660 #2
[   28.249361] task: c003 ti: c0032000 task.ti: c0032000
[   28.250038] EIP: 0060:[] EFLAGS: 00010246 CPU: 0
[   28.250738] EIP is at driver_register+0xa/0xe0
[   28.280022] EAX: c272a298 EBX:  ECX:  EDX: c276a800
[   28.280780] ESI: c272a280 EDI:  EBP: c0033f14 ESP: c0033eec
[   28.281620]  DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
[   28.282282] CR0: 80050033 CR2:  CR3: 02a5f000 CR4: 0690
[   28.283045] Stack:
[   28.283298]  c176aca6 000e3f00 d0d4b000 0286 d0d4b000 d3818000  
c28a143b
[   28.284428]  d0d4b308  c0033f1c c28a144e c0033f78 c2879b8e c10ab791 

[   28.285512]   c0033f38 c10d7aab c0033f48 00060006  c26e1b34 
c259e774
[   28.296719] Call Trace:
[   28.297044]  [] ? isa_register_driver+0x26/0x150
[   28.297840]  [] ? wm8994_gpio_init+0x11/0x11
[   28.298463]  [] ws16c48_driver_init+0x13/0x15
[   28.299105]  [] do_one_initcall+0xdf/0x174
[   28.299704]  [] ? parse_args+0x331/0x540
[   28.300291]  [] ? trace_hardirqs_on+0xb/0x10
[   28.300915]  [] ? kernel_init_freeable+0x169/0x208
[   28.311797]  [] kernel_init_freeable+0x182/0x208
[   28.312479]  [] kernel_init+0xb/0x120
[   28.313052]  [] ? schedule_tail+0xc/0x90
[   28.313669]  [] ret_from_kernel_thread+0x21/0x40
[   28.314359]  [] ? rest_init+0x110/0x110
[   28.314951] Code: b9 ff 8b 43 70 eb 0c 8d 76 00 8d bc 27 00 00 00 00 31 c0 
5b 5d c3 8d 74 26 00 8d bc 27 00 00 00 00 8b 50 04 8b 4a 48 85 c9 75 06 <0f> 0b 
8d 74 26 00 55 89 e5 56 53 83 ec 08 89 c3 8b 42 24 85 c0
[   28.328199] EIP: [] driver_register+0xa/0xe0 SS:ESP 0068:c0033eec
[   28.329049] ---[ end trace 4ee2a401683f9ad5 ]---
[   28.329576] Kernel panic - not syncing: Fatal exception


FYI, raw QEMU command line is:

qemu-system-i386 -enable-kvm -kernel 
/pkg/linux/i386-randconfig-b0-05261412/gcc-6/cc736607c86d39ea078519af0de6ee0fbf3096a6/vmlinuz-4.6.0-rc4-00032-gcc73660
 -append 'root=/dev/ram0 user=lkp 
job=/lkp/scheduled/vm-kbuild-yocto-i386-27/bisect_boot-1-yocto-minimal-i386.cgz-i386-randconfig-b0-05261412-cc736607c86d39ea078519af0de6ee0fbf3096a6-20160526-98636-1416dgc-0.yaml
 ARCH=i386 kconfig=i386-randconfig-b0-05261412 
branch=linux-devel/devel-spot-201605261344 
commit=cc736607c86d39ea078519af0de6ee0fbf3096a6 
BOOT_IMAGE=/pkg/linux/i386-randconfig-b0-05261412/gcc-6/cc736607c86d39ea078519af0de6ee0fbf3096a6/vmlinuz-4.6.0-rc4-00032-gcc73660
 max_uptime=600 
RESULT_ROOT=/result/boot/1/vm-kbuild-yocto-i386/yocto-minimal-i386.cgz/i386-randconfig-b0-05261412/gcc-6/cc736607c86d39ea078519af0de6ee0fbf3096a6/0
 LKP_SERVER=inn 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 

[gpio] cc736607c8: kernel BUG at drivers/base/driver.c:153!

[kernel test robot]

FYI, we noticed the following commit:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit cc736607c86d39ea078519af0de6ee0fbf3096a6 ("gpio: ws16c48: Utilize the 
ISA bus driver")


on test machine: vm-kbuild-yocto-i386: 2 threads qemu-system-i386 -enable-kvm 
with 320M memory

caused below changes:


+---+++
|   | 86ea8a95a4 | 
cc736607c8 |
+---+++
| boot_successes| 11 | 0
  |
| boot_failures | 1  | 12   
  |
| BUG:unable_to_handle_kernel   | 1  |  
  |
| Oops  | 1  |  
  |
| EIP_is_at_perf_prepare_sample | 1  |  
  |
| Kernel_panic-not_syncing:Fatal_exception_in_interrupt | 1  |  
  |
| backtrace:vfs_fstatat | 1  |  
  |
| backtrace:SyS_fstatat64   | 1  |  
  |
| kernel_BUG_at_drivers/base/driver.c   | 0  | 12   
  |
| invalid_opcode:#[##]PREEMPT_SMP   | 0  | 12   
  |
| EIP_is_at_driver_register | 0  | 12   
  |
| Kernel_panic-not_syncing:Fatal_exception  | 0  | 12   
  |
| backtrace:ws16c48_driver_init | 0  | 12   
  |
| backtrace:kernel_init_freeable| 0  | 12   
  |
+---+++



[   25.433696] rbtree testing -> 28301 cycles
[   26.544836] augmented rbtree testing -> 42740 cycles
[   28.246337] [ cut here ]
[   28.246942] kernel BUG at drivers/base/driver.c:153!
[   28.247784] invalid opcode:  [#1] PREEMPT SMP 
[   28.248433] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
4.6.0-rc4-00032-gcc73660 #2
[   28.249361] task: c003 ti: c0032000 task.ti: c0032000
[   28.250038] EIP: 0060:[] EFLAGS: 00010246 CPU: 0
[   28.250738] EIP is at driver_register+0xa/0xe0
[   28.280022] EAX: c272a298 EBX:  ECX:  EDX: c276a800
[   28.280780] ESI: c272a280 EDI:  EBP: c0033f14 ESP: c0033eec
[   28.281620]  DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
[   28.282282] CR0: 80050033 CR2:  CR3: 02a5f000 CR4: 0690
[   28.283045] Stack:
[   28.283298]  c176aca6 000e3f00 d0d4b000 0286 d0d4b000 d3818000  
c28a143b
[   28.284428]  d0d4b308  c0033f1c c28a144e c0033f78 c2879b8e c10ab791 

[   28.285512]   c0033f38 c10d7aab c0033f48 00060006  c26e1b34 
c259e774
[   28.296719] Call Trace:
[   28.297044]  [] ? isa_register_driver+0x26/0x150
[   28.297840]  [] ? wm8994_gpio_init+0x11/0x11
[   28.298463]  [] ws16c48_driver_init+0x13/0x15
[   28.299105]  [] do_one_initcall+0xdf/0x174
[   28.299704]  [] ? parse_args+0x331/0x540
[   28.300291]  [] ? trace_hardirqs_on+0xb/0x10
[   28.300915]  [] ? kernel_init_freeable+0x169/0x208
[   28.311797]  [] kernel_init_freeable+0x182/0x208
[   28.312479]  [] kernel_init+0xb/0x120
[   28.313052]  [] ? schedule_tail+0xc/0x90
[   28.313669]  [] ret_from_kernel_thread+0x21/0x40
[   28.314359]  [] ? rest_init+0x110/0x110
[   28.314951] Code: b9 ff 8b 43 70 eb 0c 8d 76 00 8d bc 27 00 00 00 00 31 c0 
5b 5d c3 8d 74 26 00 8d bc 27 00 00 00 00 8b 50 04 8b 4a 48 85 c9 75 06 <0f> 0b 
8d 74 26 00 55 89 e5 56 53 83 ec 08 89 c3 8b 42 24 85 c0
[   28.328199] EIP: [] driver_register+0xa/0xe0 SS:ESP 0068:c0033eec
[   28.329049] ---[ end trace 4ee2a401683f9ad5 ]---
[   28.329576] Kernel panic - not syncing: Fatal exception


FYI, raw QEMU command line is:

qemu-system-i386 -enable-kvm -kernel 
/pkg/linux/i386-randconfig-b0-05261412/gcc-6/cc736607c86d39ea078519af0de6ee0fbf3096a6/vmlinuz-4.6.0-rc4-00032-gcc73660
 -append 'root=/dev/ram0 user=lkp 
job=/lkp/scheduled/vm-kbuild-yocto-i386-27/bisect_boot-1-yocto-minimal-i386.cgz-i386-randconfig-b0-05261412-cc736607c86d39ea078519af0de6ee0fbf3096a6-20160526-98636-1416dgc-0.yaml
 ARCH=i386 kconfig=i386-randconfig-b0-05261412 
branch=linux-devel/devel-spot-201605261344 
commit=cc736607c86d39ea078519af0de6ee0fbf3096a6 
BOOT_IMAGE=/pkg/linux/i386-randconfig-b0-05261412/gcc-6/cc736607c86d39ea078519af0de6ee0fbf3096a6/vmlinuz-4.6.0-rc4-00032-gcc73660
 max_uptime=600 
RESULT_ROOT=/result/boot/1/vm-kbuild-yocto-i386/yocto-minimal-i386.cgz/i386-randconfig-b0-05261412/gcc-6/cc736607c86d39ea078519af0de6ee0fbf3096a6/0
 LKP_SERVER=inn 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 

[gpio] 72bf7443ba: kernel BUG at drivers/base/driver.c:153!

[kernel test robot]

FYI, we noticed the following commit:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 72bf7443ba618b9f7a3167c1f591a0dc00faeb2d ("gpio: 104-idi-48: Utilize the 
ISA bus driver")


on test machine: vm-vp-quantal-i386: 1 threads qemu-system-i386 -enable-kvm 
-cpu Haswell,+smep,+smap with 360M memory

caused below changes:


[5.268521] rbtree testing -> 27624 cycles
[6.369886] augmented rbtree testing -> 39374 cycles
[7.893834] [ cut here ]
[7.894491] kernel BUG at drivers/base/driver.c:153!
[7.895396] invalid opcode:  [#1] DEBUG_PAGEALLOC 
[7.896242] Modules linked in:
[7.896663] CPU: 0 PID: 1 Comm: swapper Not tainted 4.6.0-rc4-00030-g72bf744 
#1
[7.897640] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[7.898718] task: 8001b000 ti: 80036000 task.ti: 80036000
[7.899380] EIP: 0060:[<811cb002>] EFLAGS: 00010246 CPU: 0
[7.900175] EIP is at driver_register+0x9/0xa0
[7.900723] EAX: 815ff918 EBX: 815ff900 ECX: 0006 EDX: 8160f060
[7.901635] ESI:  EDI:  EBP: 80037f1c ESP: 80037f00
[7.902397]  DS: 007b ES: 007b FS:  GS: 00e0 SS: 0068
[7.903056] CR0: 80050033 CR2:  CR3: 016a3000 CR4: 00040690
[7.904137] Stack:
[7.904406]  811d7d6e 0286  0286 81651c82 8016af40  
80037f24
[7.905462]  81651c95 80037f84 81000493 8163743f 948dc8bc 815d3f00 80037f70 
810498fa
[7.906528]   815d3fd0 00060006 815d2bf8 00ff 948dc8bd 0200 
8157b55f
[7.907586] Call Trace:
[7.912053]  [<811d7d6e>] ? isa_register_driver+0x26/0x110
[7.912795]  [<81651c82>] ? gpiolib_debugfs_init+0x1f/0x1f
[7.913536]  [<81651c95>] idi_48_driver_init+0x13/0x15
[7.914217]  [<81000493>] do_one_initcall+0xd9/0x17b
[7.917980]  [<8163743f>] ? repair_env_string+0x12/0x54
[7.918697]  [<810498fa>] ? parse_args+0x1a2/0x275
[7.919343]  [<81637ba2>] kernel_init_freeable+0xd8/0x15b
[7.924274]  [<81387f6f>] kernel_init+0x8/0xcb
[7.924823]  [<8138cac8>] ret_from_kernel_thread+0x20/0x34
[7.925487]  [<81387f67>] ? rest_init+0x10e/0x10e
[7.926055] Code: 02 31 db 8d 45 f0 e8 93 b6 1b 00 eb 00 5a 89 d8 59 5b 5e 
5d c3 55 8b 40 3c 89 e5 e8 af 02 f3 ff 5d c3 8b 50 04 83 7a 48 00 75 02 <0f> 0b 
55 89 e5 56 53 83 7a 24 00 89 c3 74 06 83 78 20 00 75 18
[7.936637] EIP: [<811cb002>] driver_register+0x9/0xa0 SS:ESP 0068:80037f00
[7.937793] ---[ end trace 2ae6a8b9997e94af ]---
[7.942071] tsc: Refined TSC clocksource calibration: 2693.510 MHz


FYI, raw QEMU command line is:

qemu-system-i386 -enable-kvm -cpu Haswell,+smep,+smap -kernel 
/pkg/linux/i386-randconfig-sb0-05261509/gcc-6/72bf7443ba618b9f7a3167c1f591a0dc00faeb2d/vmlinuz-4.6.0-rc4-00030-g72bf744
 -append 'root=/dev/ram0 user=lkp 
job=/lkp/scheduled/vm-vp-quantal-i386-20/bisect_boot-1-quantal-core-i386.cgz-i386-randconfig-sb0-05261509-72bf7443ba618b9f7a3167c1f591a0dc00faeb2d-20160526-51173-1jydwxg-1.yaml
 ARCH=i386 kconfig=i386-randconfig-sb0-05261509 
branch=linux-devel/devel-spot-201605261432 
commit=72bf7443ba618b9f7a3167c1f591a0dc00faeb2d 
BOOT_IMAGE=/pkg/linux/i386-randconfig-sb0-05261509/gcc-6/72bf7443ba618b9f7a3167c1f591a0dc00faeb2d/vmlinuz-4.6.0-rc4-00030-g72bf744
 max_uptime=600 
RESULT_ROOT=/result/boot/1/vm-vp-quantal-i386/quantal-core-i386.cgz/i386-randconfig-sb0-05261509/gcc-6/72bf7443ba618b9f7a3167c1f591a0dc00faeb2d/0
 LKP_SERVER=inn 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 
ip=vm-vp-quantal-i386-20::dhcp drbd.minor_count=8'  -initrd 
/fs/sdd1/initrd-vm-vp-quantal-i386-20 -m 360 -smp 1 -device e1000,netdev=net0 
-netdev user,id=net0 -boot order=nc -no-reboot -watchdog i6300esb -rtc 
base=localtime -pidfile /dev/shm/kboot/pid-vm-vp-quantal-i386-20 -serial 
file:/dev/shm/kboot/serial-vm-vp-quantal-i386-20 -daemonize -display none 
-monitor null 





Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.6.0-rc4 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y

[gpio] 72bf7443ba: kernel BUG at drivers/base/driver.c:153!

[kernel test robot]

FYI, we noticed the following commit:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 72bf7443ba618b9f7a3167c1f591a0dc00faeb2d ("gpio: 104-idi-48: Utilize the 
ISA bus driver")


on test machine: vm-vp-quantal-i386: 1 threads qemu-system-i386 -enable-kvm 
-cpu Haswell,+smep,+smap with 360M memory

caused below changes:


[5.268521] rbtree testing -> 27624 cycles
[6.369886] augmented rbtree testing -> 39374 cycles
[7.893834] [ cut here ]
[7.894491] kernel BUG at drivers/base/driver.c:153!
[7.895396] invalid opcode:  [#1] DEBUG_PAGEALLOC 
[7.896242] Modules linked in:
[7.896663] CPU: 0 PID: 1 Comm: swapper Not tainted 4.6.0-rc4-00030-g72bf744 
#1
[7.897640] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[7.898718] task: 8001b000 ti: 80036000 task.ti: 80036000
[7.899380] EIP: 0060:[<811cb002>] EFLAGS: 00010246 CPU: 0
[7.900175] EIP is at driver_register+0x9/0xa0
[7.900723] EAX: 815ff918 EBX: 815ff900 ECX: 0006 EDX: 8160f060
[7.901635] ESI:  EDI:  EBP: 80037f1c ESP: 80037f00
[7.902397]  DS: 007b ES: 007b FS:  GS: 00e0 SS: 0068
[7.903056] CR0: 80050033 CR2:  CR3: 016a3000 CR4: 00040690
[7.904137] Stack:
[7.904406]  811d7d6e 0286  0286 81651c82 8016af40  
80037f24
[7.905462]  81651c95 80037f84 81000493 8163743f 948dc8bc 815d3f00 80037f70 
810498fa
[7.906528]   815d3fd0 00060006 815d2bf8 00ff 948dc8bd 0200 
8157b55f
[7.907586] Call Trace:
[7.912053]  [<811d7d6e>] ? isa_register_driver+0x26/0x110
[7.912795]  [<81651c82>] ? gpiolib_debugfs_init+0x1f/0x1f
[7.913536]  [<81651c95>] idi_48_driver_init+0x13/0x15
[7.914217]  [<81000493>] do_one_initcall+0xd9/0x17b
[7.917980]  [<8163743f>] ? repair_env_string+0x12/0x54
[7.918697]  [<810498fa>] ? parse_args+0x1a2/0x275
[7.919343]  [<81637ba2>] kernel_init_freeable+0xd8/0x15b
[7.924274]  [<81387f6f>] kernel_init+0x8/0xcb
[7.924823]  [<8138cac8>] ret_from_kernel_thread+0x20/0x34
[7.925487]  [<81387f67>] ? rest_init+0x10e/0x10e
[7.926055] Code: 02 31 db 8d 45 f0 e8 93 b6 1b 00 eb 00 5a 89 d8 59 5b 5e 
5d c3 55 8b 40 3c 89 e5 e8 af 02 f3 ff 5d c3 8b 50 04 83 7a 48 00 75 02 <0f> 0b 
55 89 e5 56 53 83 7a 24 00 89 c3 74 06 83 78 20 00 75 18
[7.936637] EIP: [<811cb002>] driver_register+0x9/0xa0 SS:ESP 0068:80037f00
[7.937793] ---[ end trace 2ae6a8b9997e94af ]---
[7.942071] tsc: Refined TSC clocksource calibration: 2693.510 MHz


FYI, raw QEMU command line is:

qemu-system-i386 -enable-kvm -cpu Haswell,+smep,+smap -kernel 
/pkg/linux/i386-randconfig-sb0-05261509/gcc-6/72bf7443ba618b9f7a3167c1f591a0dc00faeb2d/vmlinuz-4.6.0-rc4-00030-g72bf744
 -append 'root=/dev/ram0 user=lkp 
job=/lkp/scheduled/vm-vp-quantal-i386-20/bisect_boot-1-quantal-core-i386.cgz-i386-randconfig-sb0-05261509-72bf7443ba618b9f7a3167c1f591a0dc00faeb2d-20160526-51173-1jydwxg-1.yaml
 ARCH=i386 kconfig=i386-randconfig-sb0-05261509 
branch=linux-devel/devel-spot-201605261432 
commit=72bf7443ba618b9f7a3167c1f591a0dc00faeb2d 
BOOT_IMAGE=/pkg/linux/i386-randconfig-sb0-05261509/gcc-6/72bf7443ba618b9f7a3167c1f591a0dc00faeb2d/vmlinuz-4.6.0-rc4-00030-g72bf744
 max_uptime=600 
RESULT_ROOT=/result/boot/1/vm-vp-quantal-i386/quantal-core-i386.cgz/i386-randconfig-sb0-05261509/gcc-6/72bf7443ba618b9f7a3167c1f591a0dc00faeb2d/0
 LKP_SERVER=inn 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 
ip=vm-vp-quantal-i386-20::dhcp drbd.minor_count=8'  -initrd 
/fs/sdd1/initrd-vm-vp-quantal-i386-20 -m 360 -smp 1 -device e1000,netdev=net0 
-netdev user,id=net0 -boot order=nc -no-reboot -watchdog i6300esb -rtc 
base=localtime -pidfile /dev/shm/kboot/pid-vm-vp-quantal-i386-20 -serial 
file:/dev/shm/kboot/serial-vm-vp-quantal-i386-20 -daemonize -display none 
-monitor null 





Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.6.0-rc4 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y

Re: [PATCH v3 1/1] ovl: setxattr: don't deadlock when called from ima_fix_xattr.

[Mimi Zohar]

On Mon, 2016-05-30 at 17:50 +0100, Al Viro wrote:
>   Only tangentially related, but... that bug had been discussed,
> without any results: the fallback in ima_d_path() to ->d_name.name is
> completely broken.  There is no warranty whatsoever that dentry won't be
> renamed, with its earlier (too long to be embedded into dentry itself)
> ->d_name.name getting freed.  Right under your code.

Isn't i_mutex required?

> 
>   Could we please get rid of that thing?  "A message in a near-oom
> situation might be less informative than we'd like" is better than
> "this code might end up dereferencing freed memory".
> 
>   Another similar bug is in ima_collect_measurement() -
> const char *filename = file->f_path.dentry->d_name.name;
>   ...
> integrity_audit_msg(AUDIT_INTEGRITY_DATA, inode,
> filename, "collect_data", audit_cause,
> with no warranty whatsoever that you are not passing a pointer to freed
> memory.  The same goes for ima_eventname_init_common() -
> if (event_data->file) {
> cur_filename = event_data->file->f_path.dentry->d_name.name;
> cur_filename_len = strlen(cur_filename);
> } else  
> ...
> return ima_write_template_field_data(cur_filename, cur_filename_len,
>  DATA_FMT_STRING, field_data);
> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-security-module" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH v3 1/1] ovl: setxattr: don't deadlock when called from ima_fix_xattr.

[Mimi Zohar]

On Mon, 2016-05-30 at 17:50 +0100, Al Viro wrote:
>   Only tangentially related, but... that bug had been discussed,
> without any results: the fallback in ima_d_path() to ->d_name.name is
> completely broken.  There is no warranty whatsoever that dentry won't be
> renamed, with its earlier (too long to be embedded into dentry itself)
> ->d_name.name getting freed.  Right under your code.

Isn't i_mutex required?

> 
>   Could we please get rid of that thing?  "A message in a near-oom
> situation might be less informative than we'd like" is better than
> "this code might end up dereferencing freed memory".
> 
>   Another similar bug is in ima_collect_measurement() -
> const char *filename = file->f_path.dentry->d_name.name;
>   ...
> integrity_audit_msg(AUDIT_INTEGRITY_DATA, inode,
> filename, "collect_data", audit_cause,
> with no warranty whatsoever that you are not passing a pointer to freed
> memory.  The same goes for ima_eventname_init_common() -
> if (event_data->file) {
> cur_filename = event_data->file->f_path.dentry->d_name.name;
> cur_filename_len = strlen(cur_filename);
> } else  
> ...
> return ima_write_template_field_data(cur_filename, cur_filename_len,
>  DATA_FMT_STRING, field_data);
> --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-security-module" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH stable 3.16+] crypto: s5p-sss - Fix missed interrupts when working with 8 kB blocks

[Herbert Xu]

On Mon, May 30, 2016 at 12:09:28PM +0200, Krzysztof Kozlowski wrote:
> commit 79152e8d085fd64484afd473ef6830b45518acba upstream.
> 
> The tcrypt testing module on Exynos5422-based Odroid XU3/4 board failed on
> testing 8 kB size blocks:
> 
>   $ sudo modprobe tcrypt sec=1 mode=500
>   testing speed of async ecb(aes) (ecb-aes-s5p) encryption
>   test 0 (128 bit key, 16 byte blocks): 21971 operations in 1 seconds 
> (351536 bytes)
>   test 1 (128 bit key, 64 byte blocks): 21731 operations in 1 seconds 
> (1390784 bytes)
>   test 2 (128 bit key, 256 byte blocks): 21932 operations in 1 seconds 
> (5614592 bytes)
>   test 3 (128 bit key, 1024 byte blocks): 21685 operations in 1 seconds 
> (22205440 bytes)
>   test 4 (128 bit key, 8192 byte blocks):
> 
> This was caused by a race issue of missed BRDMA_DONE ("Block cipher
> Receiving DMA") interrupt. Device starts processing the data in DMA mode
> immediately after setting length of DMA block: receiving (FCBRDMAL) or
> transmitting (FCBTDMAL). The driver sets these lengths from interrupt
> handler through s5p_set_dma_indata() function (or xxx_setdata()).
> 
> However the interrupt handler was first dealing with receive buffer
> (dma-unmap old, dma-map new, set receive block length which starts the
> operation), then with transmit buffer and finally was clearing pending
> interrupts (FCINTPEND). Because of the time window between setting
> receive buffer length and clearing pending interrupts, the operation on
> receive buffer could end already and driver would miss new interrupt.
> 
> User manual for Exynos5422 confirms in example code that setting DMA
> block lengths should be the last operation.
> 
> The tcrypt hang could be also observed in following blocked-task dmesg:
> 
> INFO: task modprobe:258 blocked for more than 120 seconds.
>   Not tainted 4.6.0-rc4-next-20160419-5-g9eac8b7b7753-dirty #42
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> modprobeD c06b09d8 0   258256 0x
> [] (__schedule) from [] (schedule+0x40/0xac)
> [] (schedule) from [] (schedule_timeout+0x124/0x178)
> [] (schedule_timeout) from [] (wait_for_common+0xb8/0x144)
> [] (wait_for_common) from [] 
> (test_acipher_speed+0x49c/0x740 [tcrypt])
> [] (test_acipher_speed [tcrypt]) from [] 
> (do_test+0x2240/0x30ec [tcrypt])
> [] (do_test [tcrypt]) from [] (tcrypt_mod_init+0x48/0xa4 
> [tcrypt])
> [] (tcrypt_mod_init [tcrypt]) from [] 
> (do_one_initcall+0x3c/0x16c)
> [] (do_one_initcall) from [] (do_init_module+0x5c/0x1ac)
> [] (do_init_module) from [] (load_module+0x1a30/0x1d08)
> [] (load_module) from [] (SyS_finit_module+0x8c/0x98)
> [] (SyS_finit_module) from [] (ret_fast_syscall+0x0/0x3c)
> 
> Fixes: a49e490c7a8a ("crypto: s5p-sss - add S5PV210 advanced crypto engine 
> support")
> Cc:  # 3.16+
> Signed-off-by: Krzysztof Kozlowski 
> Tested-by: Marek Szyprowski 
> Signed-off-by: Herbert Xu 
> [k.kozlowski: Backport to v3.16]

Acked-by: Herbert Xu 
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH stable 3.16+] crypto: s5p-sss - Fix missed interrupts when working with 8 kB blocks

[Herbert Xu]

On Mon, May 30, 2016 at 12:09:28PM +0200, Krzysztof Kozlowski wrote:
> commit 79152e8d085fd64484afd473ef6830b45518acba upstream.
> 
> The tcrypt testing module on Exynos5422-based Odroid XU3/4 board failed on
> testing 8 kB size blocks:
> 
>   $ sudo modprobe tcrypt sec=1 mode=500
>   testing speed of async ecb(aes) (ecb-aes-s5p) encryption
>   test 0 (128 bit key, 16 byte blocks): 21971 operations in 1 seconds 
> (351536 bytes)
>   test 1 (128 bit key, 64 byte blocks): 21731 operations in 1 seconds 
> (1390784 bytes)
>   test 2 (128 bit key, 256 byte blocks): 21932 operations in 1 seconds 
> (5614592 bytes)
>   test 3 (128 bit key, 1024 byte blocks): 21685 operations in 1 seconds 
> (22205440 bytes)
>   test 4 (128 bit key, 8192 byte blocks):
> 
> This was caused by a race issue of missed BRDMA_DONE ("Block cipher
> Receiving DMA") interrupt. Device starts processing the data in DMA mode
> immediately after setting length of DMA block: receiving (FCBRDMAL) or
> transmitting (FCBTDMAL). The driver sets these lengths from interrupt
> handler through s5p_set_dma_indata() function (or xxx_setdata()).
> 
> However the interrupt handler was first dealing with receive buffer
> (dma-unmap old, dma-map new, set receive block length which starts the
> operation), then with transmit buffer and finally was clearing pending
> interrupts (FCINTPEND). Because of the time window between setting
> receive buffer length and clearing pending interrupts, the operation on
> receive buffer could end already and driver would miss new interrupt.
> 
> User manual for Exynos5422 confirms in example code that setting DMA
> block lengths should be the last operation.
> 
> The tcrypt hang could be also observed in following blocked-task dmesg:
> 
> INFO: task modprobe:258 blocked for more than 120 seconds.
>   Not tainted 4.6.0-rc4-next-20160419-5-g9eac8b7b7753-dirty #42
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> modprobeD c06b09d8 0   258256 0x
> [] (__schedule) from [] (schedule+0x40/0xac)
> [] (schedule) from [] (schedule_timeout+0x124/0x178)
> [] (schedule_timeout) from [] (wait_for_common+0xb8/0x144)
> [] (wait_for_common) from [] 
> (test_acipher_speed+0x49c/0x740 [tcrypt])
> [] (test_acipher_speed [tcrypt]) from [] 
> (do_test+0x2240/0x30ec [tcrypt])
> [] (do_test [tcrypt]) from [] (tcrypt_mod_init+0x48/0xa4 
> [tcrypt])
> [] (tcrypt_mod_init [tcrypt]) from [] 
> (do_one_initcall+0x3c/0x16c)
> [] (do_one_initcall) from [] (do_init_module+0x5c/0x1ac)
> [] (do_init_module) from [] (load_module+0x1a30/0x1d08)
> [] (load_module) from [] (SyS_finit_module+0x8c/0x98)
> [] (SyS_finit_module) from [] (ret_fast_syscall+0x0/0x3c)
> 
> Fixes: a49e490c7a8a ("crypto: s5p-sss - add S5PV210 advanced crypto engine 
> support")
> Cc:  # 3.16+
> Signed-off-by: Krzysztof Kozlowski 
> Tested-by: Marek Szyprowski 
> Signed-off-by: Herbert Xu 
> [k.kozlowski: Backport to v3.16]

Acked-by: Herbert Xu 
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH trivial] include/linux/memblock.h: Clean up code for several trivial details

[Chen Gang]

On 2016年05月30日 22:33, Joe Perches wrote:
> On Mon, 2016-05-30 at 22:21 +0800, Chen Gang wrote:
>> No, they are not necessary. But for me, it will be more clearer, since
>> in our kernel (at least in include/linux/), almost all Boolean functions
>> use Boolean value or expression for return (and "!!" are often used).
> 
> Opinions vary.
> 
> There seem to be fewer than 20 !! uses in bool return
> functions in include/linux/
>

  ide.h:854
  mlx4/driver.h:76
  mlx5/device.h:744
  mmzone.h:793
  mtd/mtd.h:412
  nilfs2_fs.h:568
  nilfs2_fs.h:602
  nilfs2_fs.h:667
  nilfs2_fs.h:771
  page-flags.h:711
  pagemap.h:54

For me, we can change the related functions to Boolean functions
directly.
 
> Finding the quantity of bool conversions in include/linux
> from something other than 0, 1, true, or false to 0 or 1
> is not trivial, but it is non-zero and seems rather more
> than 20.
> 

[root@localhost linux]# grep -rn "\" * | grep ' & ' | grep -v "==" | 
grep -v '||' | grep -v 'struct' | grep -v '!=' | grep -v ',' | grep -v '?' | 
grep -v '!' | grep -v '&&' | wc -l
259

After give a glance, more than 60% are not for bool functions (so I
guess about 100 area hint).

But I guess, quite a few of none Boolean functions above can be changed
to Boolean functions, too (but have to read more code).

So I guess, about 200+ matches the hint (not use "!!" for & operation in
Boolean functions) in the 1000+ Boolean functions in include/linux.


All together, for me:

The return statement is much special than normal statements:

 - It is related with function's type (non-return function, Boolean
   function, or normal function), not only related with type cast within
   the statement itself.

 - Even for normal function, the type cast in return statement is also
   better: when reading source code, return statements have much more
   chances to be read than the function return type.

 - For finding Boolean function in existing normal functions, we often
   read the return value to know about whether it is a Boolean function
   or not.

So, I still suggest to add type cast explicitly in return statement.

Welcome any ideas, suggestions, and completions.

Thanks.
-- 
Chen Gang (陈刚)

Managing Natural Environments is the Duty of Human Beings.

Re: [PATCH trivial] include/linux/memblock.h: Clean up code for several trivial details

[Chen Gang]

On 2016年05月30日 22:33, Joe Perches wrote:
> On Mon, 2016-05-30 at 22:21 +0800, Chen Gang wrote:
>> No, they are not necessary. But for me, it will be more clearer, since
>> in our kernel (at least in include/linux/), almost all Boolean functions
>> use Boolean value or expression for return (and "!!" are often used).
> 
> Opinions vary.
> 
> There seem to be fewer than 20 !! uses in bool return
> functions in include/linux/
>

  ide.h:854
  mlx4/driver.h:76
  mlx5/device.h:744
  mmzone.h:793
  mtd/mtd.h:412
  nilfs2_fs.h:568
  nilfs2_fs.h:602
  nilfs2_fs.h:667
  nilfs2_fs.h:771
  page-flags.h:711
  pagemap.h:54

For me, we can change the related functions to Boolean functions
directly.
 
> Finding the quantity of bool conversions in include/linux
> from something other than 0, 1, true, or false to 0 or 1
> is not trivial, but it is non-zero and seems rather more
> than 20.
> 

[root@localhost linux]# grep -rn "\" * | grep ' & ' | grep -v "==" | 
grep -v '||' | grep -v 'struct' | grep -v '!=' | grep -v ',' | grep -v '?' | 
grep -v '!' | grep -v '&&' | wc -l
259

After give a glance, more than 60% are not for bool functions (so I
guess about 100 area hint).

But I guess, quite a few of none Boolean functions above can be changed
to Boolean functions, too (but have to read more code).

So I guess, about 200+ matches the hint (not use "!!" for & operation in
Boolean functions) in the 1000+ Boolean functions in include/linux.


All together, for me:

The return statement is much special than normal statements:

 - It is related with function's type (non-return function, Boolean
   function, or normal function), not only related with type cast within
   the statement itself.

 - Even for normal function, the type cast in return statement is also
   better: when reading source code, return statements have much more
   chances to be read than the function return type.

 - For finding Boolean function in existing normal functions, we often
   read the return value to know about whether it is a Boolean function
   or not.

So, I still suggest to add type cast explicitly in return statement.

Welcome any ideas, suggestions, and completions.

Thanks.
-- 
Chen Gang (陈刚)

Managing Natural Environments is the Duty of Human Beings.

Re: building and using modules on arm64 hikey board

[Jisheng Zhang]

On Mon, 30 May 2016 20:54:33 +0200
Arend van Spriel  wrote:

> On 30-05-16 13:30, Ard Biesheuvel wrote:
> > This is likely caused by the fact that the Android AArch64 toolchain uses 
> > -fpic by default. Could you try adding -fno-pic to the CFLAGS?  
> 
> I did only to notice with 'make V=1 ...' that it was already used hence
> showing up in the compile command line twice. To no avail so that ain't
> working.

Per my experience, the default ld in android toolchain is gold, can you plz try
to use ld.bfd instead?

> 
> Regards,
> Arend
> 
> >> On 30 mei 2016, at 12:21, Arend Van Spriel  
> >> wrote:
> >>
> >> I got myself an arm64 HiKey board from LeMaker and build an Android AOSP
> >> image for it (see [1]). For development I would like to use
> >> CONFIG_MODULES. However, when I try to insmod the build module I get:
> >>
> >> [  287.903653] module cfg80211: overflow in relocation type 261 val
> >> ffbffc006530
> >>
> >> Looking AArch64 ELF documentation [2], section 4.6.5, it has:
> >> code|name|operation |overflow check   |
> >> 261 |R_AARCH64_PREL32|S + A - P |-2^31 <= X < 2^32|
> >>
> >> So basically the highest 32 bits should all be one and so ffbf is
> >> invalid. From what I could find searching internet it could be an issue
> >> with linker options so I build kernel and modules with V=1. Here the
> >> linker invocation for them:
> >>
> >> + aarch64-linux-android-ld -EL -p --no-undefined -X --build-id -o vmlinux \
> >> -T ./arch/arm64/kernel/vmlinux.lds arch/arm64/kernel/head.o
> >> init/built-in.o \
> >> --start-group usr/built-in.o arch/arm64/kernel/built-in.o
> >> arch/arm64/mm/built-in.o \
> >> arch/arm64/net/built-in.o arch/arm64/kvm/built-in.o
> >> arch/arm64/crypto/built-in.o \
> >> ./drivers/firmware/efi/libstub/lib.a kernel/built-in.o certs/built-in.o
> >> mm/built-in.o \
> >> fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o
> >> block/built-in.o \
> >> arch/arm64/lib/lib.a lib/lib.a arch/arm64/lib/built-in.o lib/built-in.o
> >> drivers/built-in.o \
> >> sound/built-in.o firmware/built-in.o net/built-in.o virt/built-in.o
> >> --end-group .tmp_kallsyms2.o
> >>
> >>  aarch64-linux-android-ld -EL -r  -T ./scripts/module-common.lds
> >> --build-id \
> >>  -o net/wireless/cfg80211.ko net/wireless/cfg80211.o
> >> net/wireless/cfg80211.mod.o
> >>
> >> Attached are vmlinux.lds and module-common.lds. I also tried taking
> >> upstream arch/arm64/kernel/module.lds in hikey-linaro tree. If someone
> >> can give a hint or educated guess at what to try it would be appreciated.
> >>
> >> Regards,
> >> Arend
> >>
> >> [1] https://source.android.com/source/devices.html#building-kernel
> >> [2]
> >> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056b/IHI0056B_aaelf64.pdf
> >> 
> >>   
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: building and using modules on arm64 hikey board

[Jisheng Zhang]

On Mon, 30 May 2016 20:54:33 +0200
Arend van Spriel  wrote:

> On 30-05-16 13:30, Ard Biesheuvel wrote:
> > This is likely caused by the fact that the Android AArch64 toolchain uses 
> > -fpic by default. Could you try adding -fno-pic to the CFLAGS?  
> 
> I did only to notice with 'make V=1 ...' that it was already used hence
> showing up in the compile command line twice. To no avail so that ain't
> working.

Per my experience, the default ld in android toolchain is gold, can you plz try
to use ld.bfd instead?

> 
> Regards,
> Arend
> 
> >> On 30 mei 2016, at 12:21, Arend Van Spriel  
> >> wrote:
> >>
> >> I got myself an arm64 HiKey board from LeMaker and build an Android AOSP
> >> image for it (see [1]). For development I would like to use
> >> CONFIG_MODULES. However, when I try to insmod the build module I get:
> >>
> >> [  287.903653] module cfg80211: overflow in relocation type 261 val
> >> ffbffc006530
> >>
> >> Looking AArch64 ELF documentation [2], section 4.6.5, it has:
> >> code|name|operation |overflow check   |
> >> 261 |R_AARCH64_PREL32|S + A - P |-2^31 <= X < 2^32|
> >>
> >> So basically the highest 32 bits should all be one and so ffbf is
> >> invalid. From what I could find searching internet it could be an issue
> >> with linker options so I build kernel and modules with V=1. Here the
> >> linker invocation for them:
> >>
> >> + aarch64-linux-android-ld -EL -p --no-undefined -X --build-id -o vmlinux \
> >> -T ./arch/arm64/kernel/vmlinux.lds arch/arm64/kernel/head.o
> >> init/built-in.o \
> >> --start-group usr/built-in.o arch/arm64/kernel/built-in.o
> >> arch/arm64/mm/built-in.o \
> >> arch/arm64/net/built-in.o arch/arm64/kvm/built-in.o
> >> arch/arm64/crypto/built-in.o \
> >> ./drivers/firmware/efi/libstub/lib.a kernel/built-in.o certs/built-in.o
> >> mm/built-in.o \
> >> fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o
> >> block/built-in.o \
> >> arch/arm64/lib/lib.a lib/lib.a arch/arm64/lib/built-in.o lib/built-in.o
> >> drivers/built-in.o \
> >> sound/built-in.o firmware/built-in.o net/built-in.o virt/built-in.o
> >> --end-group .tmp_kallsyms2.o
> >>
> >>  aarch64-linux-android-ld -EL -r  -T ./scripts/module-common.lds
> >> --build-id \
> >>  -o net/wireless/cfg80211.ko net/wireless/cfg80211.o
> >> net/wireless/cfg80211.mod.o
> >>
> >> Attached are vmlinux.lds and module-common.lds. I also tried taking
> >> upstream arch/arm64/kernel/module.lds in hikey-linaro tree. If someone
> >> can give a hint or educated guess at what to try it would be appreciated.
> >>
> >> Regards,
> >> Arend
> >>
> >> [1] https://source.android.com/source/devices.html#building-kernel
> >> [2]
> >> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056b/IHI0056B_aaelf64.pdf
> >> 
> >>   
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH V9 1/1] usb:serial: Add Fintek F81532/534 driver

[Ji-Ze Hong (Peter Hong)]

This driver is for Fintek F81532/F81534 USB to Serial Ports IC.

F81532 spec:
https://drive.google.com/file/d/0B8vRwwYO7aMFOTRRMmhWQVNvajQ/view?
usp=sharing

F81534 spec:
https://drive.google.com/file/d/0B8vRwwYO7aMFV29pQWJqbVBNc00/view?
usp=sharing

Features:
1. F81532 is 1-to-2 & F81534 is 1-to-4 serial ports IC
2. Support Baudrate from B50 to B115200.

Signed-off-by: Ji-Ze Hong (Peter Hong) 
---
 drivers/usb/serial/Kconfig  |   10 +
 drivers/usb/serial/Makefile |1 +
 drivers/usb/serial/f81534.c | 1528 +++
 3 files changed, 1539 insertions(+)
 create mode 100644 drivers/usb/serial/f81534.c

diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig
index 56ecb8b..0642864 100644
--- a/drivers/usb/serial/Kconfig
+++ b/drivers/usb/serial/Kconfig
@@ -255,6 +255,16 @@ config USB_SERIAL_F81232
  To compile this driver as a module, choose M here: the
  module will be called f81232.
 
+config USB_SERIAL_F8153X
+   tristate "USB Fintek F81532/534 Multi-Ports Serial Driver"
+   help
+ Say Y here if you want to use the Fintek F81532/534 Multi-Ports
+ usb to serial adapter.
+
+ To compile this driver as a module, choose M here: the
+ module will be called f81534.
+
+
 config USB_SERIAL_GARMIN
tristate "USB Garmin GPS driver"
help
diff --git a/drivers/usb/serial/Makefile b/drivers/usb/serial/Makefile
index 349d9df..9e43b7b 100644
--- a/drivers/usb/serial/Makefile
+++ b/drivers/usb/serial/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_USB_SERIAL_EDGEPORT) += io_edgeport.o
 obj-$(CONFIG_USB_SERIAL_EDGEPORT_TI)   += io_ti.o
 obj-$(CONFIG_USB_SERIAL_EMPEG) += empeg.o
 obj-$(CONFIG_USB_SERIAL_F81232)+= f81232.o
+obj-$(CONFIG_USB_SERIAL_F8153X)+= f81534.o
 obj-$(CONFIG_USB_SERIAL_FTDI_SIO)  += ftdi_sio.o
 obj-$(CONFIG_USB_SERIAL_GARMIN)+= garmin_gps.o
 obj-$(CONFIG_USB_SERIAL_IPAQ)  += ipaq.o
diff --git a/drivers/usb/serial/f81534.c b/drivers/usb/serial/f81534.c
new file mode 100644
index 000..c1cb52d
--- /dev/null
+++ b/drivers/usb/serial/f81534.c
@@ -0,0 +1,1528 @@
+/*
+ * F81532/F81534 USB to Serial Ports Bridge
+ *
+ * F81532 => 2 Serial Ports
+ * F81534 => 4 Serial Ports
+ *
+ * Copyright (C) 2016 Tom Tsai (tom_t...@fintek.com.tw)
+ *  2016 Peter Hong (peter_h...@fintek.com.tw)
+ *
+ * The F81532/F81534 had 1 control endpoint for setting, 1 endpoint bulk-out
+ * for all serial port TX and 1 endpoint bulk-in for all serial port read in
+ * (Read Data/MSR/LSR).
+ *
+ * Write URB is fixed with 512bytes, per serial port used 128Bytes.
+ * It can be described by f81534_prepare_write_buffer()
+ *
+ * Read URB is 512Bytes max, per serial port used 128Bytes.
+ * It can be described by f81534_process_read_urb() and maybe received with
+ * 128x1,2,3,4 bytes.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Serial Port register Address */
+#define SERIAL_BASE_ADDRESS0x1200
+#define DIVISOR_LATCH_LSB  (0x00 + SERIAL_BASE_ADDRESS)
+#define DIVISOR_LATCH_MSB  (0x01 + SERIAL_BASE_ADDRESS)
+#define FIFO_CONTROL_REGISTER  (0x02 + SERIAL_BASE_ADDRESS)
+#define LINE_CONTROL_REGISTER  (0x03 + SERIAL_BASE_ADDRESS)
+#define MODEM_CONTROL_REGISTER (0x04 + SERIAL_BASE_ADDRESS)
+#define MODEM_STATUS_REGISTER  (0x06 + SERIAL_BASE_ADDRESS)
+#define CONFIG1_REGISTER   (0x09 + SERIAL_BASE_ADDRESS)
+
+#define F81534_DEF_CONF_ADDRESS_START  0x3000
+#define F81534_DEF_CONF_SIZE   8
+
+#define F81534_CUSTOM_ADDRESS_START0x2f00
+#define F81534_CUSTOM_DATA_SIZE0x10
+#define F81534_CUSTOM_NO_CUSTOM_DATA   (-1)
+#define F81534_CUSTOM_VALID_TOKEN  0xf0
+#define F81534_CONF_OFFSET 1
+
+#define F81534_MAX_DATA_BLOCK  64
+#define F81534_MAX_BUS_RETRY   2000
+
+/* Default URB timeout for USB operations */
+#define F81534_USB_MAX_RETRY   10
+#define F81534_USB_TIMEOUT 1000
+#define F81534_SET_GET_REGISTER0xA0
+#define F81534_DELAY_READ_MSR  10
+
+#define F81534_NUM_PORT4
+#define F81534_UNUSED_PORT 0xff
+#define F81534_WRITE_BUFFER_SIZE   512
+
+#define IC_NAME"f81534"
+#define DRIVER_DESC"Fintek F81532/F81534"
+#define FINTEK_VENDOR_ID_1 0x1934
+#define FINTEK_VENDOR_ID_2 0x2C42
+#define FINTEK_DEVICE_ID   0x1202
+#define F81534_MAX_TX_SIZE 100
+#define F81534_RECEIVE_BLOCK_SIZE  128
+
+#define F81534_TOKEN_RECEIVE   0x01
+#define F81534_TOKEN_WRITE 0x02
+#define F81534_TOKEN_TX_EMPTY  0x03
+#define F81534_TOKEN_MSR_CHANGE0x04
+
+#define F81534_BUS_BUSY   

[PATCH V9 1/1] usb:serial: Add Fintek F81532/534 driver

[Ji-Ze Hong (Peter Hong)]

This driver is for Fintek F81532/F81534 USB to Serial Ports IC.

F81532 spec:
https://drive.google.com/file/d/0B8vRwwYO7aMFOTRRMmhWQVNvajQ/view?
usp=sharing

F81534 spec:
https://drive.google.com/file/d/0B8vRwwYO7aMFV29pQWJqbVBNc00/view?
usp=sharing

Features:
1. F81532 is 1-to-2 & F81534 is 1-to-4 serial ports IC
2. Support Baudrate from B50 to B115200.

Signed-off-by: Ji-Ze Hong (Peter Hong) 
---
 drivers/usb/serial/Kconfig  |   10 +
 drivers/usb/serial/Makefile |1 +
 drivers/usb/serial/f81534.c | 1528 +++
 3 files changed, 1539 insertions(+)
 create mode 100644 drivers/usb/serial/f81534.c

diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig
index 56ecb8b..0642864 100644
--- a/drivers/usb/serial/Kconfig
+++ b/drivers/usb/serial/Kconfig
@@ -255,6 +255,16 @@ config USB_SERIAL_F81232
  To compile this driver as a module, choose M here: the
  module will be called f81232.
 
+config USB_SERIAL_F8153X
+   tristate "USB Fintek F81532/534 Multi-Ports Serial Driver"
+   help
+ Say Y here if you want to use the Fintek F81532/534 Multi-Ports
+ usb to serial adapter.
+
+ To compile this driver as a module, choose M here: the
+ module will be called f81534.
+
+
 config USB_SERIAL_GARMIN
tristate "USB Garmin GPS driver"
help
diff --git a/drivers/usb/serial/Makefile b/drivers/usb/serial/Makefile
index 349d9df..9e43b7b 100644
--- a/drivers/usb/serial/Makefile
+++ b/drivers/usb/serial/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_USB_SERIAL_EDGEPORT) += io_edgeport.o
 obj-$(CONFIG_USB_SERIAL_EDGEPORT_TI)   += io_ti.o
 obj-$(CONFIG_USB_SERIAL_EMPEG) += empeg.o
 obj-$(CONFIG_USB_SERIAL_F81232)+= f81232.o
+obj-$(CONFIG_USB_SERIAL_F8153X)+= f81534.o
 obj-$(CONFIG_USB_SERIAL_FTDI_SIO)  += ftdi_sio.o
 obj-$(CONFIG_USB_SERIAL_GARMIN)+= garmin_gps.o
 obj-$(CONFIG_USB_SERIAL_IPAQ)  += ipaq.o
diff --git a/drivers/usb/serial/f81534.c b/drivers/usb/serial/f81534.c
new file mode 100644
index 000..c1cb52d
--- /dev/null
+++ b/drivers/usb/serial/f81534.c
@@ -0,0 +1,1528 @@
+/*
+ * F81532/F81534 USB to Serial Ports Bridge
+ *
+ * F81532 => 2 Serial Ports
+ * F81534 => 4 Serial Ports
+ *
+ * Copyright (C) 2016 Tom Tsai (tom_t...@fintek.com.tw)
+ *  2016 Peter Hong (peter_h...@fintek.com.tw)
+ *
+ * The F81532/F81534 had 1 control endpoint for setting, 1 endpoint bulk-out
+ * for all serial port TX and 1 endpoint bulk-in for all serial port read in
+ * (Read Data/MSR/LSR).
+ *
+ * Write URB is fixed with 512bytes, per serial port used 128Bytes.
+ * It can be described by f81534_prepare_write_buffer()
+ *
+ * Read URB is 512Bytes max, per serial port used 128Bytes.
+ * It can be described by f81534_process_read_urb() and maybe received with
+ * 128x1,2,3,4 bytes.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Serial Port register Address */
+#define SERIAL_BASE_ADDRESS0x1200
+#define DIVISOR_LATCH_LSB  (0x00 + SERIAL_BASE_ADDRESS)
+#define DIVISOR_LATCH_MSB  (0x01 + SERIAL_BASE_ADDRESS)
+#define FIFO_CONTROL_REGISTER  (0x02 + SERIAL_BASE_ADDRESS)
+#define LINE_CONTROL_REGISTER  (0x03 + SERIAL_BASE_ADDRESS)
+#define MODEM_CONTROL_REGISTER (0x04 + SERIAL_BASE_ADDRESS)
+#define MODEM_STATUS_REGISTER  (0x06 + SERIAL_BASE_ADDRESS)
+#define CONFIG1_REGISTER   (0x09 + SERIAL_BASE_ADDRESS)
+
+#define F81534_DEF_CONF_ADDRESS_START  0x3000
+#define F81534_DEF_CONF_SIZE   8
+
+#define F81534_CUSTOM_ADDRESS_START0x2f00
+#define F81534_CUSTOM_DATA_SIZE0x10
+#define F81534_CUSTOM_NO_CUSTOM_DATA   (-1)
+#define F81534_CUSTOM_VALID_TOKEN  0xf0
+#define F81534_CONF_OFFSET 1
+
+#define F81534_MAX_DATA_BLOCK  64
+#define F81534_MAX_BUS_RETRY   2000
+
+/* Default URB timeout for USB operations */
+#define F81534_USB_MAX_RETRY   10
+#define F81534_USB_TIMEOUT 1000
+#define F81534_SET_GET_REGISTER0xA0
+#define F81534_DELAY_READ_MSR  10
+
+#define F81534_NUM_PORT4
+#define F81534_UNUSED_PORT 0xff
+#define F81534_WRITE_BUFFER_SIZE   512
+
+#define IC_NAME"f81534"
+#define DRIVER_DESC"Fintek F81532/F81534"
+#define FINTEK_VENDOR_ID_1 0x1934
+#define FINTEK_VENDOR_ID_2 0x2C42
+#define FINTEK_DEVICE_ID   0x1202
+#define F81534_MAX_TX_SIZE 100
+#define F81534_RECEIVE_BLOCK_SIZE  128
+
+#define F81534_TOKEN_RECEIVE   0x01
+#define F81534_TOKEN_WRITE 0x02
+#define F81534_TOKEN_TX_EMPTY  0x03
+#define F81534_TOKEN_MSR_CHANGE0x04
+
+#define F81534_BUS_BUSY0x03

Re: [PATCH v2 3/3] cpufreq: schedutil: map raw required frequency to driver frequency

[Wanpeng Li]

2016-05-30 22:25 GMT+08:00 Rafael J. Wysocki :
> On Mon, May 30, 2016 at 12:18 PM, Viresh Kumar  
> wrote:
>> On 29-05-16, 02:40, Rafael J. Wysocki wrote:
>>> I can't really parse the above question, so I'm not going to try to
>>> answer it. :-)
>>
>> Sorry about that :(
>>
>> IOW, I think that we should make this change into the sched-governor (I will
>> send a patch separately if you agree to this):
>
> I don't.
>
>> diff --git a/kernel/sched/cpufreq_schedutil.c 
>> b/kernel/sched/cpufreq_schedutil.c
>> index 14c4aa25cc45..5934b14aa21c 100644
>> --- a/kernel/sched/cpufreq_schedutil.c
>> +++ b/kernel/sched/cpufreq_schedutil.c
>> @@ -66,11 +66,6 @@ static bool sugov_should_update_freq(struct sugov_policy 
>> *sg_policy, u64 time)
>>
>> if (unlikely(sg_policy->need_freq_update)) {
>> sg_policy->need_freq_update = false;
>> -   /*
>> -* This happens when limits change, so forget the previous
>> -* next_freq value and force an update.
>> -*/
>> -   sg_policy->next_freq = UINT_MAX;
>> return true;
>> }
>>
>> And here is my reasoning behind this.
>>
>> Can you show me any case, where the above code (as present in mainline
>> today) leads to a freq-change? I couldn't find any.
>>
>> Let me demonstrate.
>>
>> Following only talks about the fast-switch path, the other path is
>> same as well.
>>
>> Suppose this is the current range of frequencies supported by a
>> driver: 200, 400, 600, 800, 1000 (in MHz).
>>
>> And policy->cur = next_freq = 400 MHz.
>>
>> A.) Suppose that we change policy->min to 400 MHz from userspace.
>> -> sugov_limits()
>>This will find everything in order and simply set
>>need_freq_update, without updating the frequency.
>>
>> On next util-callback, we will forcefully return true from
>> sugov_should_update_freq() and reach sugov_update_commit().
>>
>> We calculate next_freq and that comes to 400 MHz again (that's the
>> case we are trying to target with the above code).
>>
>> With the current code, we will forcefully end up calling
>> cpufreq_driver_fast_switch().
>>
>> Because the new and current frequencies are same,
>> cpufreq_driver->fast_switch() will simply return.
>>
>> NOTE: I also think that cpufreq_driver_fast_switch() should have a
>> check like (policy->cur == target_freq). I will add that too, in
>> case you agree.
>>
>> So, forcefully updating next_freq to UINT_MAX will end up wasting
>> some cycles, but wouldn't do any useful stuff.
>
> It will, but there's no way to distinguish this case from B in the
> governor with the current min/max synchronization mechanism.  That is,
> it only knows that something has changed, but checking what exactly
> has changed would be racy.
>
>> B.) Suppose that we change policy->min to 600 MHz from userspace.
>> -> sugov_limits()
>>This will find that policy->cur is less than 600 and will set
>>that to 600 MHz by calling __cpufreq_driver_target(). We will
>>also set need_freq_update.
>>
>>Note that next_freq and policy->cur are not in sync anymore and
>>perhaps this is the most important case for the above code.
>
> It is.
>
> Moreover, please note that __cpufreq_driver_target() is only called in
> sugov_limits() when policy->fast_switch_enabled is unset.
>
>> On next util-callback, we will forcefully return true from
>> sugov_should_update_freq() and reach sugov_update_commit().
>>
>> We calculate next_freq and lets say that comes to 400 MHz again
>> (as that's the case we are trying to target with the above code).
>>
>> With the current code, we will forcefully end up calling
>> cpufreq_driver_fast_switch().
>>
>> Because next_freq() is not part of the new range, we will clamp it
>> and set it to 600 MHz eventually. Again, next and current
>> frequencies are same, cpufreq_driver->fast_switch() will simply
>> return.
>
> Not really (as per the above).
>
> And even in the !fast_switch_enabled case, if next_freq stays at 400
> MHz (which is different from policy->cur), it may lead to suboptimal
> decisions going forward (eg. if it goes to 600 MHz next time and the
> governor will think that the frequency has changed, although in fact
> it hasn't).

Does set next_freq = UNIT_MAX has same effect as next_freq stays at
400MHz since both means that frequency has changed?

Regards,
Wanpeng Li

Re: [PATCH] usb:serial: Add Fintek F81532/534 driver

[Peter Hung]

Hi,

Ji-Ze Hong (Peter Hong) 於 2016/5/31 上午 09:33 寫道:

This driver is for Fintek F81532/F81534 USB to Serial Ports IC.



Sorry, I forgot to change the mail title for "PATCH V9". I'll resend a
patch with title "PATCH V9".

Thanks
--
With Best Regards,
Peter Hung

Re: [PATCH v2 3/3] cpufreq: schedutil: map raw required frequency to driver frequency

[Wanpeng Li]

2016-05-30 22:25 GMT+08:00 Rafael J. Wysocki :
> On Mon, May 30, 2016 at 12:18 PM, Viresh Kumar  
> wrote:
>> On 29-05-16, 02:40, Rafael J. Wysocki wrote:
>>> I can't really parse the above question, so I'm not going to try to
>>> answer it. :-)
>>
>> Sorry about that :(
>>
>> IOW, I think that we should make this change into the sched-governor (I will
>> send a patch separately if you agree to this):
>
> I don't.
>
>> diff --git a/kernel/sched/cpufreq_schedutil.c 
>> b/kernel/sched/cpufreq_schedutil.c
>> index 14c4aa25cc45..5934b14aa21c 100644
>> --- a/kernel/sched/cpufreq_schedutil.c
>> +++ b/kernel/sched/cpufreq_schedutil.c
>> @@ -66,11 +66,6 @@ static bool sugov_should_update_freq(struct sugov_policy 
>> *sg_policy, u64 time)
>>
>> if (unlikely(sg_policy->need_freq_update)) {
>> sg_policy->need_freq_update = false;
>> -   /*
>> -* This happens when limits change, so forget the previous
>> -* next_freq value and force an update.
>> -*/
>> -   sg_policy->next_freq = UINT_MAX;
>> return true;
>> }
>>
>> And here is my reasoning behind this.
>>
>> Can you show me any case, where the above code (as present in mainline
>> today) leads to a freq-change? I couldn't find any.
>>
>> Let me demonstrate.
>>
>> Following only talks about the fast-switch path, the other path is
>> same as well.
>>
>> Suppose this is the current range of frequencies supported by a
>> driver: 200, 400, 600, 800, 1000 (in MHz).
>>
>> And policy->cur = next_freq = 400 MHz.
>>
>> A.) Suppose that we change policy->min to 400 MHz from userspace.
>> -> sugov_limits()
>>This will find everything in order and simply set
>>need_freq_update, without updating the frequency.
>>
>> On next util-callback, we will forcefully return true from
>> sugov_should_update_freq() and reach sugov_update_commit().
>>
>> We calculate next_freq and that comes to 400 MHz again (that's the
>> case we are trying to target with the above code).
>>
>> With the current code, we will forcefully end up calling
>> cpufreq_driver_fast_switch().
>>
>> Because the new and current frequencies are same,
>> cpufreq_driver->fast_switch() will simply return.
>>
>> NOTE: I also think that cpufreq_driver_fast_switch() should have a
>> check like (policy->cur == target_freq). I will add that too, in
>> case you agree.
>>
>> So, forcefully updating next_freq to UINT_MAX will end up wasting
>> some cycles, but wouldn't do any useful stuff.
>
> It will, but there's no way to distinguish this case from B in the
> governor with the current min/max synchronization mechanism.  That is,
> it only knows that something has changed, but checking what exactly
> has changed would be racy.
>
>> B.) Suppose that we change policy->min to 600 MHz from userspace.
>> -> sugov_limits()
>>This will find that policy->cur is less than 600 and will set
>>that to 600 MHz by calling __cpufreq_driver_target(). We will
>>also set need_freq_update.
>>
>>Note that next_freq and policy->cur are not in sync anymore and
>>perhaps this is the most important case for the above code.
>
> It is.
>
> Moreover, please note that __cpufreq_driver_target() is only called in
> sugov_limits() when policy->fast_switch_enabled is unset.
>
>> On next util-callback, we will forcefully return true from
>> sugov_should_update_freq() and reach sugov_update_commit().
>>
>> We calculate next_freq and lets say that comes to 400 MHz again
>> (as that's the case we are trying to target with the above code).
>>
>> With the current code, we will forcefully end up calling
>> cpufreq_driver_fast_switch().
>>
>> Because next_freq() is not part of the new range, we will clamp it
>> and set it to 600 MHz eventually. Again, next and current
>> frequencies are same, cpufreq_driver->fast_switch() will simply
>> return.
>
> Not really (as per the above).
>
> And even in the !fast_switch_enabled case, if next_freq stays at 400
> MHz (which is different from policy->cur), it may lead to suboptimal
> decisions going forward (eg. if it goes to 600 MHz next time and the
> governor will think that the frequency has changed, although in fact
> it hasn't).

Does set next_freq = UNIT_MAX has same effect as next_freq stays at
400MHz since both means that frequency has changed?

Regards,
Wanpeng Li

Re: [PATCH] usb:serial: Add Fintek F81532/534 driver

[Peter Hung]

Hi,

Ji-Ze Hong (Peter Hong) 於 2016/5/31 上午 09:33 寫道:

This driver is for Fintek F81532/F81534 USB to Serial Ports IC.



Sorry, I forgot to change the mail title for "PATCH V9". I'll resend a
patch with title "PATCH V9".

Thanks
--
With Best Regards,
Peter Hung

linux-next: build warnings after merge of the sound-asoc tree

[Stephen Rothwell]

Hi all,

After merging the sound-asoc tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:

sound/soc/codecs/cs47l24.c: In function 'cs47l24_adsp2_irq'
:
sound/soc/codecs/cs47l24.c:1091:13: warning: cast to pointer from integer of 
different size [-Wint-to-pointer-cast]
 (void *)i);
 ^
sound/soc/codecs/wm5110.c: In function 'wm5110_adsp2_irq':
sound/soc/codecs/wm5110.c:2246:13: warning: cast to pointer from integer of 
different size [-Wint-to-pointer-cast]
 (void *)i);
 ^

Introduced by commit

  7baa7e2490e1 ("ASoC: arizona: Add event notification on voice trigger events")

-- 
Cheers,
Stephen Rothwell

linux-next: build warnings after merge of the sound-asoc tree

[Stephen Rothwell]

Hi all,

After merging the sound-asoc tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:

sound/soc/codecs/cs47l24.c: In function 'cs47l24_adsp2_irq'
:
sound/soc/codecs/cs47l24.c:1091:13: warning: cast to pointer from integer of 
different size [-Wint-to-pointer-cast]
 (void *)i);
 ^
sound/soc/codecs/wm5110.c: In function 'wm5110_adsp2_irq':
sound/soc/codecs/wm5110.c:2246:13: warning: cast to pointer from integer of 
different size [-Wint-to-pointer-cast]
 (void *)i);
 ^

Introduced by commit

  7baa7e2490e1 ("ASoC: arizona: Add event notification on voice trigger events")

-- 
Cheers,
Stephen Rothwell

[PATCH] usb:serial: Add Fintek F81532/534 driver

[Ji-Ze Hong (Peter Hong)]

This driver is for Fintek F81532/F81534 USB to Serial Ports IC.

F81532 spec:
https://drive.google.com/file/d/0B8vRwwYO7aMFOTRRMmhWQVNvajQ/view?
usp=sharing

F81534 spec:
https://drive.google.com/file/d/0B8vRwwYO7aMFV29pQWJqbVBNc00/view?
usp=sharing

Features:
1. F81532 is 1-to-2 & F81534 is 1-to-4 serial ports IC
2. Support Baudrate from B50 to B115200.

Signed-off-by: Ji-Ze Hong (Peter Hong) 
---
Changelog:
v9
1. Remove lots of code to make more generic for F81532/534. e.g.,
   high baud rate support, RS485/422 mode switch, most of GPIO
   control and internal storage write functional.
2. Change f81534_tiocmget() MSR delay from schedule_timeout_killable()
   to wait_for_completion_killable_timeout(). This IC will delayed
   receiving MSR change when doing loop-back test e.g., BurnInTest.
   We'll reset completion "msr_done" in f81534_update_mctrl(). If we
   changed MCR, the next f81534_tiocmget() will delay for 20ms or
   continue with new MSR arrived.
3. Fix for non-zero buffer allocated in f81534_setup_ports(). It'll
   make device malfunctional with incorrect tx length for other ports.

v8
1. Remove driver mode GPIOLIB & RS485 control support, the driver will
   only load GPIO/UART Mode when driver attach() & port_probe().
2. Add more documents for 3 generation IC with f81534_calc_num_ports().
3. Simplify the GPIO register structure "f81534_pin_control".
4. Change all counter type from int to size_t.
5. Change some failed message with failed: "status code" and remove all
   exclamation mark in messages.
6. Change all save blocks to block0 due to the driver is only used 1
   block (block0) to save data.
7. Change read MSR in open() instead of port_probe().
8. use GFP_ATOMIC kmalloc mode in write().
9. Maintain old style with 1 read URBs and 4 write URBs like mxuports.c
   I had tested with submit 4 read URBs, but it'll make some port freeze
   when doing BurnInTest Port test.

v7
1. Make all gpiolib function with #ifdef CONFIG_GPIOLIB marco block.
   Due to F81532/534 could run without gpiolib, we implements
   f81534_prepare_gpio()/f81534_release_gpio() always success without
   CONFIG_GPIOLIB.
2. Fix crash when receiving MSR change on driver load/unload. It's cause
   by f81534_process_read_urb() get read URB callback data, but port
   private data is not init complete or released. We solve with 2
   modifications.

   1. add null pointer check with f81534_process_read_urb(). We'll skip
  this report when port_priv = NULL.
   2. when "one" port f81534_port_remove() is called, kill the port-0
  read URB before kfree port_priv.

v6
1. Re-implement the write()/resume() function. Due to this device cant be
   suitable with generic write(), we'll do the submit write URB when
   write()/received tx empty/set_termios()/resume()
2. Logic/Phy Port mapping rewrite in f81534_port_probe() &
   f81534_phy_to_logic_port().
3. Introduced "Port Hide" function. Some customer use F81532 reference
   design for HW layout, but really use F81534 IC. We'll check
   F81534_PORT_CONF_DISABLE_PORT flag with in uart mode field to do
   port hide with port not used. It can be avoid end-user to use not
   layouted port.
4. The 4x3 output-only open-drain pins for F81532/534 is designed for
   control outer devices (with our EVB for examples, the 4 sets of pins
   are designed to control transceiver mode). So we decide to implement
   with gpiolib interface.
5. Add device vendor id with 0x2c42

v5
1. Change f81534_port_disable/enable() from H/W mode to S/W mode
   It'll skip all rx data when port is not opened.
2. Some function modifier add with static (Thanks for Paul Bolle)
3. It's will direct return when count=0 in f81534_write() to
   reduce spin_lock usage.

v4
1. clearify f81534_process_read_urb() with
   f81534_process_per_serial_block(). (referenced from mxuport.c)
2. We limited f81534_write() max tx kfifo with 124Bytes.
   Original subsystem is designed for auto tranmiting fifo data
   if available. But we must wait for tx_empty for next tx data
   (H/W design).

   With this kfifo size limit, we can use generic subsystem api with
   f81534_write(). When usb_serial_generic_write_start() called after
   first write URB complete, the fifo will no data. The generic
   subsystem of write will go to idle state. Until we received
   TX_EMPTY and release write spinlock, the fifo will fill max
   124Bytes by following f81534_write().

v3
1. Migrate read, write and some routine from custom code to usbserial
   subsystem callback function.
2. Use more defines to replece magic numbers to make it meaningful
3. Make more comments as document in source code.

v2
1. v1 version submit to staging tree, but 

[PATCH] usb:serial: Add Fintek F81532/534 driver

[Ji-Ze Hong (Peter Hong)]

This driver is for Fintek F81532/F81534 USB to Serial Ports IC.

F81532 spec:
https://drive.google.com/file/d/0B8vRwwYO7aMFOTRRMmhWQVNvajQ/view?
usp=sharing

F81534 spec:
https://drive.google.com/file/d/0B8vRwwYO7aMFV29pQWJqbVBNc00/view?
usp=sharing

Features:
1. F81532 is 1-to-2 & F81534 is 1-to-4 serial ports IC
2. Support Baudrate from B50 to B115200.

Signed-off-by: Ji-Ze Hong (Peter Hong) 
---
Changelog:
v9
1. Remove lots of code to make more generic for F81532/534. e.g.,
   high baud rate support, RS485/422 mode switch, most of GPIO
   control and internal storage write functional.
2. Change f81534_tiocmget() MSR delay from schedule_timeout_killable()
   to wait_for_completion_killable_timeout(). This IC will delayed
   receiving MSR change when doing loop-back test e.g., BurnInTest.
   We'll reset completion "msr_done" in f81534_update_mctrl(). If we
   changed MCR, the next f81534_tiocmget() will delay for 20ms or
   continue with new MSR arrived.
3. Fix for non-zero buffer allocated in f81534_setup_ports(). It'll
   make device malfunctional with incorrect tx length for other ports.

v8
1. Remove driver mode GPIOLIB & RS485 control support, the driver will
   only load GPIO/UART Mode when driver attach() & port_probe().
2. Add more documents for 3 generation IC with f81534_calc_num_ports().
3. Simplify the GPIO register structure "f81534_pin_control".
4. Change all counter type from int to size_t.
5. Change some failed message with failed: "status code" and remove all
   exclamation mark in messages.
6. Change all save blocks to block0 due to the driver is only used 1
   block (block0) to save data.
7. Change read MSR in open() instead of port_probe().
8. use GFP_ATOMIC kmalloc mode in write().
9. Maintain old style with 1 read URBs and 4 write URBs like mxuports.c
   I had tested with submit 4 read URBs, but it'll make some port freeze
   when doing BurnInTest Port test.

v7
1. Make all gpiolib function with #ifdef CONFIG_GPIOLIB marco block.
   Due to F81532/534 could run without gpiolib, we implements
   f81534_prepare_gpio()/f81534_release_gpio() always success without
   CONFIG_GPIOLIB.
2. Fix crash when receiving MSR change on driver load/unload. It's cause
   by f81534_process_read_urb() get read URB callback data, but port
   private data is not init complete or released. We solve with 2
   modifications.

   1. add null pointer check with f81534_process_read_urb(). We'll skip
  this report when port_priv = NULL.
   2. when "one" port f81534_port_remove() is called, kill the port-0
  read URB before kfree port_priv.

v6
1. Re-implement the write()/resume() function. Due to this device cant be
   suitable with generic write(), we'll do the submit write URB when
   write()/received tx empty/set_termios()/resume()
2. Logic/Phy Port mapping rewrite in f81534_port_probe() &
   f81534_phy_to_logic_port().
3. Introduced "Port Hide" function. Some customer use F81532 reference
   design for HW layout, but really use F81534 IC. We'll check
   F81534_PORT_CONF_DISABLE_PORT flag with in uart mode field to do
   port hide with port not used. It can be avoid end-user to use not
   layouted port.
4. The 4x3 output-only open-drain pins for F81532/534 is designed for
   control outer devices (with our EVB for examples, the 4 sets of pins
   are designed to control transceiver mode). So we decide to implement
   with gpiolib interface.
5. Add device vendor id with 0x2c42

v5
1. Change f81534_port_disable/enable() from H/W mode to S/W mode
   It'll skip all rx data when port is not opened.
2. Some function modifier add with static (Thanks for Paul Bolle)
3. It's will direct return when count=0 in f81534_write() to
   reduce spin_lock usage.

v4
1. clearify f81534_process_read_urb() with
   f81534_process_per_serial_block(). (referenced from mxuport.c)
2. We limited f81534_write() max tx kfifo with 124Bytes.
   Original subsystem is designed for auto tranmiting fifo data
   if available. But we must wait for tx_empty for next tx data
   (H/W design).

   With this kfifo size limit, we can use generic subsystem api with
   f81534_write(). When usb_serial_generic_write_start() called after
   first write URB complete, the fifo will no data. The generic
   subsystem of write will go to idle state. Until we received
   TX_EMPTY and release write spinlock, the fifo will fill max
   124Bytes by following f81534_write().

v3
1. Migrate read, write and some routine from custom code to usbserial
   subsystem callback function.
2. Use more defines to replece magic numbers to make it meaningful
3. Make more comments as document in source code.

v2
1. v1 version submit to staging tree, but Greg KH advised me to
   

[PATCH v4 3/6] perf config: Use zfree() instead of free() at perf_config_set__delete()

[Taeung Song]

perf_config_set__delete() delete allocated the config set
but the global variable 'config_set' is used all around.

So purge and zfree by an address of the global variable
, i.e. 'struct perf_config_set **' type
instead of using local variable 'set' of which type
is 'struct perf_config_set *'.

Cc: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Alexander Shishkin 
Signed-off-by: Taeung Song 
---
 tools/perf/builtin-config.c |  2 +-
 tools/perf/util/config.c| 11 +++
 tools/perf/util/config.h|  2 +-
 3 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/tools/perf/builtin-config.c b/tools/perf/builtin-config.c
index b3bc01a..f23fe52 100644
--- a/tools/perf/builtin-config.c
+++ b/tools/perf/builtin-config.c
@@ -105,7 +105,7 @@ int cmd_config(int argc, const char **argv, const char 
*prefix __maybe_unused)
usage_with_options(config_usage, config_options);
}
 
-   perf_config_set__delete(config_set);
+   perf_config_set__delete(_set);
 out_err:
return ret;
 }
diff --git a/tools/perf/util/config.c b/tools/perf/util/config.c
index adf2bad..79ded23 100644
--- a/tools/perf/util/config.c
+++ b/tools/perf/util/config.c
@@ -642,7 +642,7 @@ static int collect_config(const char *var, const char 
*value,
 
 out_free:
free(key);
-   perf_config_set__delete(set);
+   perf_config_set__delete();
return -1;
 }
 
@@ -740,10 +740,13 @@ static void perf_config_set__purge(struct perf_config_set 
*set)
}
 }
 
-void perf_config_set__delete(struct perf_config_set *set)
+void perf_config_set__delete(struct perf_config_set **set)
 {
-   perf_config_set__purge(set);
-   free(set);
+   if (*set == NULL)
+   return;
+
+   perf_config_set__purge(*set);
+   zfree(set);
 }
 
 /*
diff --git a/tools/perf/util/config.h b/tools/perf/util/config.h
index ea157a4..271b429 100644
--- a/tools/perf/util/config.h
+++ b/tools/perf/util/config.h
@@ -23,6 +23,6 @@ struct perf_config_set {
 extern struct perf_config_set *config_set;
 
 struct perf_config_set *perf_config_set__new(void);
-void perf_config_set__delete(struct perf_config_set *set);
+void perf_config_set__delete(struct perf_config_set **set);
 
 #endif /* __PERF_CONFIG_H */
-- 
2.5.0

[PATCH v4 3/6] perf config: Use zfree() instead of free() at perf_config_set__delete()

[Taeung Song]

perf_config_set__delete() delete allocated the config set
but the global variable 'config_set' is used all around.

So purge and zfree by an address of the global variable
, i.e. 'struct perf_config_set **' type
instead of using local variable 'set' of which type
is 'struct perf_config_set *'.

Cc: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Alexander Shishkin 
Signed-off-by: Taeung Song 
---
 tools/perf/builtin-config.c |  2 +-
 tools/perf/util/config.c| 11 +++
 tools/perf/util/config.h|  2 +-
 3 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/tools/perf/builtin-config.c b/tools/perf/builtin-config.c
index b3bc01a..f23fe52 100644
--- a/tools/perf/builtin-config.c
+++ b/tools/perf/builtin-config.c
@@ -105,7 +105,7 @@ int cmd_config(int argc, const char **argv, const char 
*prefix __maybe_unused)
usage_with_options(config_usage, config_options);
}
 
-   perf_config_set__delete(config_set);
+   perf_config_set__delete(_set);
 out_err:
return ret;
 }
diff --git a/tools/perf/util/config.c b/tools/perf/util/config.c
index adf2bad..79ded23 100644
--- a/tools/perf/util/config.c
+++ b/tools/perf/util/config.c
@@ -642,7 +642,7 @@ static int collect_config(const char *var, const char 
*value,
 
 out_free:
free(key);
-   perf_config_set__delete(set);
+   perf_config_set__delete();
return -1;
 }
 
@@ -740,10 +740,13 @@ static void perf_config_set__purge(struct perf_config_set 
*set)
}
 }
 
-void perf_config_set__delete(struct perf_config_set *set)
+void perf_config_set__delete(struct perf_config_set **set)
 {
-   perf_config_set__purge(set);
-   free(set);
+   if (*set == NULL)
+   return;
+
+   perf_config_set__purge(*set);
+   zfree(set);
 }
 
 /*
diff --git a/tools/perf/util/config.h b/tools/perf/util/config.h
index ea157a4..271b429 100644
--- a/tools/perf/util/config.h
+++ b/tools/perf/util/config.h
@@ -23,6 +23,6 @@ struct perf_config_set {
 extern struct perf_config_set *config_set;
 
 struct perf_config_set *perf_config_set__new(void);
-void perf_config_set__delete(struct perf_config_set *set);
+void perf_config_set__delete(struct perf_config_set **set);
 
 #endif /* __PERF_CONFIG_H */
-- 
2.5.0

[PATCH v4 6/6] perf config: Reimplement show_config() using perf_config()

[Taeung Song]

Old show_config() directly use config set so
there are many duplicated code with perf_config_set__iter().

So reimplement show_config() using perf_config() that use
perf_config_set__iter() with config set that already
contains all configs.

Cc: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Alexander Shishkin 
Signed-off-by: Taeung Song 
---
 tools/perf/builtin-config.c | 29 +++--
 1 file changed, 7 insertions(+), 22 deletions(-)

diff --git a/tools/perf/builtin-config.c b/tools/perf/builtin-config.c
index 4dab41e..b6ae8ea 100644
--- a/tools/perf/builtin-config.c
+++ b/tools/perf/builtin-config.c
@@ -33,28 +33,13 @@ static struct option config_options[] = {
OPT_END()
 };
 
-static int show_config(struct perf_config_set *set)
+static int show_config(const char *key, const char *value,
+  void *cb __maybe_unused)
 {
-   struct perf_config_section *section;
-   struct perf_config_item *item;
-   struct list_head *sections;
-
-   if (set == NULL)
-   return -1;
-
-   sections = >sections;
-   if (list_empty(sections))
-   return -1;
-
-   list_for_each_entry(section, sections, node) {
-   list_for_each_entry(item, >items, node) {
-   char *value = item->value;
-
-   if (value)
-   printf("%s.%s=%s\n", section->name,
-  item->name, value);
-   }
-   }
+   if (value)
+   printf("%s=%s\n", key, value);
+   else
+   printf("%s\n", key);
 
return 0;
 }
@@ -96,7 +81,7 @@ int cmd_config(int argc, const char **argv, const char 
*prefix __maybe_unused)
pr_err("Error: takes no arguments\n");
parse_options_usage(config_usage, config_options, "l", 
1);
} else {
-   ret = show_config(config_set);
+   ret = perf_config(show_config, NULL);
if (ret < 0) {
const char * config_filename = 
config_exclusive_filename;
if (!config_exclusive_filename)
-- 
2.5.0

[PATCH v4 5/6] perf config: Reset the config set at only 'config' sub-command

[Taeung Song]

When first calling perf_config(), the config set is
initialized collecting both user and system config files
(i.e. user config ~/.perfconfig and system config
$(sysconfdir)/perfconfig) so config set contains
not only user config but also system config key-value pairs.
(User config has higher priority than system config.)

But 'config' sub-command individually use the config set
so free the existing config set (i.e. a global variable config_set)
before reinstantiating it.

And 'config' sub-command have '--user' or '--system' options.
To reinitialize with the options, the config set should be reset
at the very beginning at cmd_config()

Cc: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Alexander Shishkin 
Signed-off-by: Taeung Song 
---
 tools/perf/builtin-config.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/tools/perf/builtin-config.c b/tools/perf/builtin-config.c
index f23fe52..4dab41e 100644
--- a/tools/perf/builtin-config.c
+++ b/tools/perf/builtin-config.c
@@ -79,6 +79,11 @@ int cmd_config(int argc, const char **argv, const char 
*prefix __maybe_unused)
else if (use_user_config)
config_exclusive_filename = user_config;
 
+   /*
+* Reset the config set at only 'config' sub-command
+* because of reinitializing with options config file location.
+*/
+   perf_config_set__delete(_set);
config_set = perf_config_set__new();
if (!config_set) {
ret = -1;
-- 
2.5.0

[PATCH v4 5/6] perf config: Reset the config set at only 'config' sub-command

[Taeung Song]

When first calling perf_config(), the config set is
initialized collecting both user and system config files
(i.e. user config ~/.perfconfig and system config
$(sysconfdir)/perfconfig) so config set contains
not only user config but also system config key-value pairs.
(User config has higher priority than system config.)

But 'config' sub-command individually use the config set
so free the existing config set (i.e. a global variable config_set)
before reinstantiating it.

And 'config' sub-command have '--user' or '--system' options.
To reinitialize with the options, the config set should be reset
at the very beginning at cmd_config()

Cc: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Alexander Shishkin 
Signed-off-by: Taeung Song 
---
 tools/perf/builtin-config.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/tools/perf/builtin-config.c b/tools/perf/builtin-config.c
index f23fe52..4dab41e 100644
--- a/tools/perf/builtin-config.c
+++ b/tools/perf/builtin-config.c
@@ -79,6 +79,11 @@ int cmd_config(int argc, const char **argv, const char 
*prefix __maybe_unused)
else if (use_user_config)
config_exclusive_filename = user_config;
 
+   /*
+* Reset the config set at only 'config' sub-command
+* because of reinitializing with options config file location.
+*/
+   perf_config_set__delete(_set);
config_set = perf_config_set__new();
if (!config_set) {
ret = -1;
-- 
2.5.0

[PATCH v4 6/6] perf config: Reimplement show_config() using perf_config()

[Taeung Song]

Old show_config() directly use config set so
there are many duplicated code with perf_config_set__iter().

So reimplement show_config() using perf_config() that use
perf_config_set__iter() with config set that already
contains all configs.

Cc: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Alexander Shishkin 
Signed-off-by: Taeung Song 
---
 tools/perf/builtin-config.c | 29 +++--
 1 file changed, 7 insertions(+), 22 deletions(-)

diff --git a/tools/perf/builtin-config.c b/tools/perf/builtin-config.c
index 4dab41e..b6ae8ea 100644
--- a/tools/perf/builtin-config.c
+++ b/tools/perf/builtin-config.c
@@ -33,28 +33,13 @@ static struct option config_options[] = {
OPT_END()
 };
 
-static int show_config(struct perf_config_set *set)
+static int show_config(const char *key, const char *value,
+  void *cb __maybe_unused)
 {
-   struct perf_config_section *section;
-   struct perf_config_item *item;
-   struct list_head *sections;
-
-   if (set == NULL)
-   return -1;
-
-   sections = >sections;
-   if (list_empty(sections))
-   return -1;
-
-   list_for_each_entry(section, sections, node) {
-   list_for_each_entry(item, >items, node) {
-   char *value = item->value;
-
-   if (value)
-   printf("%s.%s=%s\n", section->name,
-  item->name, value);
-   }
-   }
+   if (value)
+   printf("%s=%s\n", key, value);
+   else
+   printf("%s\n", key);
 
return 0;
 }
@@ -96,7 +81,7 @@ int cmd_config(int argc, const char **argv, const char 
*prefix __maybe_unused)
pr_err("Error: takes no arguments\n");
parse_options_usage(config_usage, config_options, "l", 
1);
} else {
-   ret = show_config(config_set);
+   ret = perf_config(show_config, NULL);
if (ret < 0) {
const char * config_filename = 
config_exclusive_filename;
if (!config_exclusive_filename)
-- 
2.5.0

[PATCH v4 2/6] perf config: Add global variable 'config_set'

[Taeung Song]

The config set is prepared by collecting
all configs from config files (i.e. user config
~/.perfconfig and system config $(sysconfdir)/perfconfig)
so the config set contains all config key-value pairs.

We need to use it as global variable to share it.
And in near future, the variable will be handled in perf_config()
and other functions at util/config.c

Cc: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Masami Hiramatsu 
Cc: Alexander Shishkin 
Signed-off-by: Taeung Song 
---
 tools/perf/builtin-config.c | 9 -
 tools/perf/util/config.c| 1 +
 tools/perf/util/config.h| 2 ++
 3 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/tools/perf/builtin-config.c b/tools/perf/builtin-config.c
index fe1b77f..b3bc01a 100644
--- a/tools/perf/builtin-config.c
+++ b/tools/perf/builtin-config.c
@@ -62,7 +62,6 @@ static int show_config(struct perf_config_set *set)
 int cmd_config(int argc, const char **argv, const char *prefix __maybe_unused)
 {
int ret = 0;
-   struct perf_config_set *set;
char *user_config = mkpath("%s/.perfconfig", getenv("HOME"));
 
argc = parse_options(argc, argv, config_options, config_usage,
@@ -80,8 +79,8 @@ int cmd_config(int argc, const char **argv, const char 
*prefix __maybe_unused)
else if (use_user_config)
config_exclusive_filename = user_config;
 
-   set = perf_config_set__new();
-   if (!set) {
+   config_set = perf_config_set__new();
+   if (!config_set) {
ret = -1;
goto out_err;
}
@@ -92,7 +91,7 @@ int cmd_config(int argc, const char **argv, const char 
*prefix __maybe_unused)
pr_err("Error: takes no arguments\n");
parse_options_usage(config_usage, config_options, "l", 
1);
} else {
-   ret = show_config(set);
+   ret = show_config(config_set);
if (ret < 0) {
const char * config_filename = 
config_exclusive_filename;
if (!config_exclusive_filename)
@@ -106,7 +105,7 @@ int cmd_config(int argc, const char **argv, const char 
*prefix __maybe_unused)
usage_with_options(config_usage, config_options);
}
 
-   perf_config_set__delete(set);
+   perf_config_set__delete(config_set);
 out_err:
return ret;
 }
diff --git a/tools/perf/util/config.c b/tools/perf/util/config.c
index 5d01899..adf2bad 100644
--- a/tools/perf/util/config.c
+++ b/tools/perf/util/config.c
@@ -28,6 +28,7 @@ static int config_linenr;
 static int config_file_eof;
 
 const char *config_exclusive_filename;
+struct perf_config_set *config_set;
 
 static int get_next_char(void)
 {
diff --git a/tools/perf/util/config.h b/tools/perf/util/config.h
index 22ec626..ea157a4 100644
--- a/tools/perf/util/config.h
+++ b/tools/perf/util/config.h
@@ -20,6 +20,8 @@ struct perf_config_set {
struct list_head sections;
 };
 
+extern struct perf_config_set *config_set;
+
 struct perf_config_set *perf_config_set__new(void);
 void perf_config_set__delete(struct perf_config_set *set);
 
-- 
2.5.0

[PATCH v4 4/6] perf config: Reimplement perf_config() using perf_config_set__iter()

[Taeung Song]

Everytime perf_config() is called, perf_config() always read config files.
(i.e. user config '~/.perfconfig' and system config '$(sysconfdir)/perfconfig')

But we need to use the config set that already contains all config
key-value pairs to avoid this repetitive work reading the config files
in perf_config(). (the config set mean a global variable 'config_set')

In other words, if new perf_config() is called,
only first time 'config_set' is initialized collecting all configs
from the config files and it work with perf_config_set__iter().
And free the config set after sub-command work at run_builtin().

If we do, 'config_set' can be reused wherever using perf_config()
and a feature of old perf_config() is the same as new perf_config() work
without the repetitive work that read the config files.

Cc: Namhyung Kim 
Cc: Jiri Olsa 
Cc: Wang Nan 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Masami Hiramatsu 
Cc: Alexander Shishkin 
Signed-off-by: Taeung Song 
---
 tools/perf/perf.c|  1 +
 tools/perf/util/cache.h  |  1 +
 tools/perf/util/config.c | 86 +---
 3 files changed, 40 insertions(+), 48 deletions(-)

diff --git a/tools/perf/perf.c b/tools/perf/perf.c
index 15982ce..058d5dc 100644
--- a/tools/perf/perf.c
+++ b/tools/perf/perf.c
@@ -391,6 +391,7 @@ static int run_builtin(struct cmd_struct *p, int argc, 
const char **argv)
 
perf_env__set_cmdline(_env, argc, argv);
status = p->fn(argc, argv, prefix);
+   perf_config_set__delete(_set);
exit_browser(status);
perf_env__exit(_env);
bpf__clear();
diff --git a/tools/perf/util/cache.h b/tools/perf/util/cache.h
index 0d814bb..54bbd55 100644
--- a/tools/perf/util/cache.h
+++ b/tools/perf/util/cache.h
@@ -7,6 +7,7 @@
 #include 
 #include "../perf.h"
 #include "../ui/ui.h"
+#include "config.h"
 
 #include 
 
diff --git a/tools/perf/util/config.c b/tools/perf/util/config.c
index 79ded23..bf385ca 100644
--- a/tools/perf/util/config.c
+++ b/tools/perf/util/config.c
@@ -478,54 +478,6 @@ static int perf_config_global(void)
return !perf_env_bool("PERF_CONFIG_NOGLOBAL", 0);
 }
 
-int perf_config(config_fn_t fn, void *data)
-{
-   int ret = 0, found = 0;
-   const char *home = NULL;
-
-   /* Setting $PERF_CONFIG makes perf read _only_ the given config file. */
-   if (config_exclusive_filename)
-   return perf_config_from_file(fn, config_exclusive_filename, 
data);
-   if (perf_config_system() && !access(perf_etc_perfconfig(), R_OK)) {
-   ret += perf_config_from_file(fn, perf_etc_perfconfig(),
-   data);
-   found += 1;
-   }
-
-   home = getenv("HOME");
-   if (perf_config_global() && home) {
-   char *user_config = strdup(mkpath("%s/.perfconfig", home));
-   struct stat st;
-
-   if (user_config == NULL) {
-   warning("Not enough memory to process %s/.perfconfig, "
-   "ignoring it.", home);
-   goto out;
-   }
-
-   if (stat(user_config, ) < 0)
-   goto out_free;
-
-   if (st.st_uid && (st.st_uid != geteuid())) {
-   warning("File %s not owned by current user or root, "
-   "ignoring it.", user_config);
-   goto out_free;
-   }
-
-   if (!st.st_size)
-   goto out_free;
-
-   ret += perf_config_from_file(fn, user_config, data);
-   found += 1;
-out_free:
-   free(user_config);
-   }
-out:
-   if (found == 0)
-   return -1;
-   return ret;
-}
-
 static struct perf_config_section *find_section(struct list_head *sections,
const char *section_name)
 {
@@ -706,6 +658,44 @@ struct perf_config_set *perf_config_set__new(void)
return set;
 }
 
+static int perf_config_set__iter(struct perf_config_set *set, config_fn_t fn, 
void *data)
+{
+   struct perf_config_section *section;
+   struct perf_config_item *item;
+   struct list_head *sections;
+   char key[BUFSIZ];
+
+   if (set == NULL)
+   return -1;
+
+   sections = >sections;
+   if (list_empty(sections))
+   return -1;
+
+   list_for_each_entry(section, sections, node) {
+   list_for_each_entry(item, >items, node) {
+   char *value = item->value;
+
+   if (value) {
+   scnprintf(key, sizeof(key), "%s.%s",
+ section->name, item->name);
+   if (fn(key, value, data)