[PATCH v2 0/3] PCI hotplug feature

[Oza Pawandeep]

These patches bring in PCI hotplug support for iproc family chipsets.

It includes DT binding documentation update and, implementation in
iproc pcie RC driver.

These patch set is made on top of following patches.
[PATCH v6 2/2] PCI: iproc: add device shutdown for PCI RC
[PATCH v6 1/2] PCI: iproc: Retry request when CRS returned from EP

Changes since v2:
Addressed Rob Herring's comments.
Made generic PCI hotplug properties 'slot-pluggable' and 'prsnt-gpios'

Oza Pawandeep (3):
  PCI: iproc: Implement PCI hotplug support
  Documentation/devicetree: Add PCIe hotplug property
  PCI: iproc: Implement optional property prsnt-gpios

 .../devicetree/bindings/pci/brcm,iproc-pcie.txt|  14 +++
 Documentation/devicetree/bindings/pci/pci.txt  |  15 +++
 drivers/pci/host/pcie-iproc-platform.c |   3 +
 drivers/pci/host/pcie-iproc.c  | 130 -
 drivers/pci/host/pcie-iproc.h  |   7 ++
 5 files changed, 163 insertions(+), 6 deletions(-)

-- 
1.9.1

[PATCH v2 3/3] PCI: iproc: Implement optional property prsnt-gpios

[Oza Pawandeep]

Add description for optional device tree property
'prsnt-gpios' for PCI hotplug feature.

Signed-off-by: Oza Pawandeep 
Reviewed-by: Ray Jui 

diff --git a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt 
b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
index b8e48b4..0c5f631 100644
--- a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
@@ -72,6 +72,20 @@ Optional properties:
 - brcm,pcie-msi-inten: Needs to be present for some older iProc platforms that
 require the interrupt enable registers to be set explicitly to enable MSI
 
+Optional properties:
+- slot-pluggable: PCI hotplug feature is supported.
+- prsnt-gpios: Array of gpios, needs to be present if Hotplug is supported.
+
+Refer to the following binding documents for more detailed description on
+the use of 'slot-pluggable' and 'prsnt-gpios'.
+  Documentation/devicetree/bindings/pci/pci.txt
+
+Example:
+prsnt-gpios: < 32 1>, < 33 1>;
+This is x4 connector: monitoring max 2 present lines.
+prsnt-gpios: < 32 1>, < 33 1>, < 34 1>;
+This is x8 connector: monitoring max 3 present lines.
+
 Example:
pcie0: pcie@18012000 {
compatible = "brcm,iproc-pcie";
-- 
1.9.1

[PATCH v2 2/3] Documentation/devicetree: Add PCIe hotplug property

[Oza Pawandeep]

Host drivers have the requirement of implementing PCI hotplug
based on the how their SOC supports PCI hotplug.

Couple of properties have been added. the one to enable
the hotplug feature itself, and the other caters to
the PCI hotplug implementation with the use of gpios.

Signed-off-by: Oza Pawandeep 

diff --git a/Documentation/devicetree/bindings/pci/pci.txt 
b/Documentation/devicetree/bindings/pci/pci.txt
index 50f9e2c..0bf25a1 100644
--- a/Documentation/devicetree/bindings/pci/pci.txt
+++ b/Documentation/devicetree/bindings/pci/pci.txt
@@ -24,3 +24,18 @@ driver implementation may support the following properties:
unsupported link speed, for instance, trying to do training for
unsupported link speed, etc.  Must be '4' for gen4, '3' for gen3, '2'
for gen2, and '1' for gen1. Any other values are invalid.
+
+- slot-pluggable:
+   PCI hotplug feature is supported.
+   PCI hotplug implementation is SOC/Board specific, and also it depends on
+   how add-in card is designed (e.g. how many present pins are implemented).
+   If the slot-pluggable property is present, the following propertey could
+   become effective.
+   - prsnt-gpios:
+  Array of gpios, could be present if hotplug is supported.
+  This property defines gpio based hotplug implementation.
+  Example:
+  If x8 card is connected, then it might be possible that all the
+  3 present pins could go low, or at least one pin goes low.
+  If x4 card is connected, then it might be possible that 2 present
+  pins go low, or at least one pin goes low.
-- 
1.9.1

[PATCH v2 0/3] PCI hotplug feature

[Oza Pawandeep]

These patches bring in PCI hotplug support for iproc family chipsets.

It includes DT binding documentation update and, implementation in
iproc pcie RC driver.

These patch set is made on top of following patches.
[PATCH v6 2/2] PCI: iproc: add device shutdown for PCI RC
[PATCH v6 1/2] PCI: iproc: Retry request when CRS returned from EP

Changes since v2:
Addressed Rob Herring's comments.
Made generic PCI hotplug properties 'slot-pluggable' and 'prsnt-gpios'

Oza Pawandeep (3):
  PCI: iproc: Implement PCI hotplug support
  Documentation/devicetree: Add PCIe hotplug property
  PCI: iproc: Implement optional property prsnt-gpios

 .../devicetree/bindings/pci/brcm,iproc-pcie.txt|  14 +++
 Documentation/devicetree/bindings/pci/pci.txt  |  15 +++
 drivers/pci/host/pcie-iproc-platform.c |   3 +
 drivers/pci/host/pcie-iproc.c  | 130 -
 drivers/pci/host/pcie-iproc.h  |   7 ++
 5 files changed, 163 insertions(+), 6 deletions(-)

-- 
1.9.1

[PATCH v2 3/3] PCI: iproc: Implement optional property prsnt-gpios

[Oza Pawandeep]

Add description for optional device tree property
'prsnt-gpios' for PCI hotplug feature.

Signed-off-by: Oza Pawandeep 
Reviewed-by: Ray Jui 

diff --git a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt 
b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
index b8e48b4..0c5f631 100644
--- a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
@@ -72,6 +72,20 @@ Optional properties:
 - brcm,pcie-msi-inten: Needs to be present for some older iProc platforms that
 require the interrupt enable registers to be set explicitly to enable MSI
 
+Optional properties:
+- slot-pluggable: PCI hotplug feature is supported.
+- prsnt-gpios: Array of gpios, needs to be present if Hotplug is supported.
+
+Refer to the following binding documents for more detailed description on
+the use of 'slot-pluggable' and 'prsnt-gpios'.
+  Documentation/devicetree/bindings/pci/pci.txt
+
+Example:
+prsnt-gpios: < 32 1>, < 33 1>;
+This is x4 connector: monitoring max 2 present lines.
+prsnt-gpios: < 32 1>, < 33 1>, < 34 1>;
+This is x8 connector: monitoring max 3 present lines.
+
 Example:
pcie0: pcie@18012000 {
compatible = "brcm,iproc-pcie";
-- 
1.9.1

[PATCH v2 2/3] Documentation/devicetree: Add PCIe hotplug property

[Oza Pawandeep]

Host drivers have the requirement of implementing PCI hotplug
based on the how their SOC supports PCI hotplug.

Couple of properties have been added. the one to enable
the hotplug feature itself, and the other caters to
the PCI hotplug implementation with the use of gpios.

Signed-off-by: Oza Pawandeep 

diff --git a/Documentation/devicetree/bindings/pci/pci.txt 
b/Documentation/devicetree/bindings/pci/pci.txt
index 50f9e2c..0bf25a1 100644
--- a/Documentation/devicetree/bindings/pci/pci.txt
+++ b/Documentation/devicetree/bindings/pci/pci.txt
@@ -24,3 +24,18 @@ driver implementation may support the following properties:
unsupported link speed, for instance, trying to do training for
unsupported link speed, etc.  Must be '4' for gen4, '3' for gen3, '2'
for gen2, and '1' for gen1. Any other values are invalid.
+
+- slot-pluggable:
+   PCI hotplug feature is supported.
+   PCI hotplug implementation is SOC/Board specific, and also it depends on
+   how add-in card is designed (e.g. how many present pins are implemented).
+   If the slot-pluggable property is present, the following propertey could
+   become effective.
+   - prsnt-gpios:
+  Array of gpios, could be present if hotplug is supported.
+  This property defines gpio based hotplug implementation.
+  Example:
+  If x8 card is connected, then it might be possible that all the
+  3 present pins could go low, or at least one pin goes low.
+  If x4 card is connected, then it might be possible that 2 present
+  pins go low, or at least one pin goes low.
-- 
1.9.1

[PATCH v5] clk: sunxi-ng: support R40 SoC

[Icenowy Zheng]

Allwinner R40 SoC have a clock controller module in the style of the
SoCs beyond sun6i, however, it's more rich and complex.

Add support for it.

Signed-off-by: Icenowy Zheng 
---
Changes in v5:
- Added TODO's for PLL constraints.
- Forced OHCI12M mux to 0.
- Changed "adda" clock to "codec" to be consistent with "bus-codec".
- Added several CLK_SET_RATE_{UNGATE,PARENT} flags.
- Added PLL_CPU gate notifier.
Changes in v4:
- Removed usb-ohci-12M mux clocks.
- Removed unused (and not in user manual) adda-4x clock.
- Implemented proper SATA PLL system.
- Renamed MP (Mixed Processor) clock names to drop the extra "DE_".
- Renamed TCONs' clock names to "tcon-lcdX" or "tcon-tvX".
- Added missing RST_DRAM.
- Several clock post/pre-dividers and constraints fixes.
Changes in v3:
- Rebased on current linux-next.
Changes in v2:
- Fixes according to the SoC's user manual.

 drivers/clk/sunxi-ng/Kconfig  |5 +
 drivers/clk/sunxi-ng/Makefile |1 +
 drivers/clk/sunxi-ng/ccu-sun8i-r40.c  | 1290 +
 drivers/clk/sunxi-ng/ccu-sun8i-r40.h  |   69 ++
 include/dt-bindings/clock/sun8i-r40-ccu.h |  187 +
 include/dt-bindings/reset/sun8i-r40-ccu.h |  130 +++
 6 files changed, 1682 insertions(+)
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-r40.c
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-r40.h
 create mode 100644 include/dt-bindings/clock/sun8i-r40-ccu.h
 create mode 100644 include/dt-bindings/reset/sun8i-r40-ccu.h

diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
index 7342928c35cd..7a360737fe3c 100644
--- a/drivers/clk/sunxi-ng/Kconfig
+++ b/drivers/clk/sunxi-ng/Kconfig
@@ -48,6 +48,11 @@ config SUN8I_V3S_CCU
 config SUN8I_DE2_CCU
bool "Support for the Allwinner SoCs DE2 CCU"
 
+config SUN8I_R40_CCU
+   bool "Support for the Allwinner R40 CCU"
+   default MACH_SUN8I
+   depends on MACH_SUN8I || COMPILE_TEST
+
 config SUN9I_A80_CCU
bool "Support for the Allwinner A80 CCU"
default MACH_SUN9I
diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
index 45a5910379a5..b1267fe68a8f 100644
--- a/drivers/clk/sunxi-ng/Makefile
+++ b/drivers/clk/sunxi-ng/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_SUN8I_H3_CCU)+= ccu-sun8i-h3.o
 obj-$(CONFIG_SUN8I_V3S_CCU)+= ccu-sun8i-v3s.o
 obj-$(CONFIG_SUN8I_DE2_CCU)+= ccu-sun8i-de2.o
 obj-$(CONFIG_SUN8I_R_CCU)  += ccu-sun8i-r.o
+obj-$(CONFIG_SUN8I_R40_CCU)+= ccu-sun8i-r40.o
 obj-$(CONFIG_SUN9I_A80_CCU)+= ccu-sun9i-a80.o
 obj-$(CONFIG_SUN9I_A80_CCU)+= ccu-sun9i-a80-de.o
 obj-$(CONFIG_SUN9I_A80_CCU)+= ccu-sun9i-a80-usb.o
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c 
b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
new file mode 100644
index ..abb4569d3886
--- /dev/null
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
@@ -0,0 +1,1290 @@
+/*
+ * Copyright (c) 2017 Icenowy Zheng 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+
+#include "ccu_common.h"
+#include "ccu_reset.h"
+
+#include "ccu_div.h"
+#include "ccu_gate.h"
+#include "ccu_mp.h"
+#include "ccu_mult.h"
+#include "ccu_nk.h"
+#include "ccu_nkm.h"
+#include "ccu_nkmp.h"
+#include "ccu_nm.h"
+#include "ccu_phase.h"
+
+#include "ccu-sun8i-r40.h"
+
+/* TODO: The result of N*K is required to be in [10, 88] range. */
+static struct ccu_nkmp pll_cpu_clk = {
+   .enable = BIT(31),
+   .lock   = BIT(28),
+   .n  = _SUNXI_CCU_MULT(8, 5),
+   .k  = _SUNXI_CCU_MULT(4, 2),
+   .m  = _SUNXI_CCU_DIV(0, 2),
+   .p  = _SUNXI_CCU_DIV_MAX(16, 2, 4),
+   .common = {
+   .reg= 0x000,
+   .hw.init= CLK_HW_INIT("pll-cpu",
+ "osc24M",
+ _nkmp_ops,
+ CLK_SET_RATE_UNGATE),
+   },
+};
+
+/*
+ * The Audio PLL is supposed to have 4 outputs: 3 fixed factors from
+ * the base (2x, 4x and 8x), and one variable divider (the one true
+ * pll audio).
+ *
+ * We don't have any need for the variable divider for now, so we just
+ * hardcode it to match with the clock names
+ */
+#define SUN8I_R40_PLL_AUDIO_REG0x008
+
+static SUNXI_CCU_NM_WITH_GATE_LOCK(pll_audio_base_clk, "pll-audio-base",
+  "osc24M", 0x008,
+  8, 7,/* N */
+  0, 5, 

[PATCH v2 1/3] PCI: iproc: Implement PCI hotplug support

[Oza Pawandeep]

This patch implements PCI hotplug support for iproc family chipsets.

iproc based SOC (e.g. Stingray) does not have hotplug controller
integrated.
Hence, standard PCI hotplug framework hooks can-not be used.
e.g. controlled power up/down of slot.

The mechanism, for e.g. Stingray has adopted for PCI hotplug is as
follows:
PCI present lines are input to GPIOs depending on the type of
connector (x2, x4, x8).

The implementation essentially takes care of following:
> Initializing hotplug irq thread.
> Detecting the endpoint device based on link state.
> Handling PERST and detecting the plugged devices.
> Ordered Hot plug-out, where User is expected
  to write 1 to /sys/bus/pci/devices//remove
> Handling spurious interrupt
> Handling multiple interrupts and makes sure that card is
  enumerated only once.

Signed-off-by: Oza Pawandeep 
Reviewed-by: Ray Jui 

diff --git a/drivers/pci/host/pcie-iproc-platform.c 
b/drivers/pci/host/pcie-iproc-platform.c
index 9512960..e1eb141 100644
--- a/drivers/pci/host/pcie-iproc-platform.c
+++ b/drivers/pci/host/pcie-iproc-platform.c
@@ -89,6 +89,9 @@ static int iproc_pcie_pltfm_probe(struct platform_device 
*pdev)
pcie->need_ob_cfg = true;
}
 
+   if (of_property_read_bool(np, "slot-pluggable"))
+   pcie->enable_hotplug = true;
+
/* PHY use is optional */
pcie->phy = devm_phy_get(dev, "pcie-phy");
if (IS_ERR(pcie->phy)) {
diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
index ee40651..eb919f7 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "pcie-iproc.h"
 
@@ -65,6 +66,17 @@
 #define PCIE_DL_ACTIVE_SHIFT 2
 #define PCIE_DL_ACTIVE   BIT(PCIE_DL_ACTIVE_SHIFT)
 
+#define CFG_RC_LTSSM 0x1cf8
+#define CFG_RC_PHY_CTL   0x1804
+#define CFG_RC_LTSSM_TIMEOUT 1000
+#define CFG_RC_LTSSM_STATE_MASK  0xff
+#define CFG_RC_LTSSM_STATE_L10x1
+
+#define CFG_RC_CLR_LTSSM_HIST_SHIFT  29
+#define CFG_RC_CLR_LTSSM_HIST_MASK   BIT(CFG_RC_CLR_LTSSM_HIST_SHIFT)
+#define CFG_RC_CLR_RECOV_HIST_SHIFT  31
+#define CFG_RC_CLR_RECOV_HIST_MASK   BIT(CFG_RC_CLR_RECOV_HIST_SHIFT)
+
 #define APB_ERR_EN_SHIFT 0
 #define APB_ERR_EN   BIT(APB_ERR_EN_SHIFT)
 
@@ -1306,12 +1318,106 @@ static int iproc_pcie_rev_init(struct iproc_pcie *pcie)
return 0;
 }
 
+static bool iproc_pci_hp_check_ltssm(struct iproc_pcie *pcie)
+{
+   struct pci_bus *bus = pcie->root_bus;
+   u32 val, timeout = CFG_RC_LTSSM_TIMEOUT;
+
+   /* Clear LTSSM history. */
+   pci_bus_read_config_dword(pcie->root_bus, 0,
+ CFG_RC_PHY_CTL, );
+   pci_bus_write_config_dword(bus, 0, CFG_RC_PHY_CTL,
+  val | CFG_RC_CLR_RECOV_HIST_MASK |
+  CFG_RC_CLR_LTSSM_HIST_MASK);
+   /* write back the origional value. */
+   pci_bus_write_config_dword(bus, 0, CFG_RC_PHY_CTL, val);
+
+   do {
+   pci_bus_read_config_dword(pcie->root_bus, 0,
+ CFG_RC_LTSSM, );
+   /* check link state to see if link moved to L1 state. */
+   if ((val & CFG_RC_LTSSM_STATE_MASK) ==
+CFG_RC_LTSSM_STATE_L1)
+   return true;
+   timeout--;
+   usleep_range(500, 1000);
+   } while (timeout);
+
+   return false;
+}
+
+static irqreturn_t iproc_pci_hotplug_thread(int irq, void *data)
+{
+   struct iproc_pcie *pcie = data;
+   struct pci_bus *bus = pcie->root_bus, *child;
+   bool link_status;
+
+   iproc_pcie_perst_ctrl(pcie, true);
+   iproc_pcie_perst_ctrl(pcie, false);
+
+   link_status = iproc_pci_hp_check_ltssm(pcie);
+
+   if (link_status &&
+   !iproc_pcie_check_link(pcie, bus) &&
+   !pcie->ep_is_present) {
+   pci_rescan_bus(bus);
+   list_for_each_entry(child, >children, node)
+   pcie_bus_configure_settings(child);
+   pcie->ep_is_present = true;
+   dev_info(pcie->dev,
+"PCI Hotplug: \n");
+   } else if (link_status && pcie->ep_is_present)
+   /*
+* ep_is_present makes sure, enumuration done only once.
+* So it can handle spurious intrrupts, and also if we
+* get multiple interrupts for all the implemented pins,
+* we handle it only once.
+*/
+   dev_info(pcie->dev,
+"PCI Hotplug: \n");
+   else {
+   iproc_pcie_perst_ctrl(pcie, true);
+   pcie->ep_is_present = false;
+   dev_info(pcie->dev,
+"PCI Hotplug: \n");
+   }
+   return IRQ_HANDLED;

[PATCH v2 1/3] PCI: iproc: Implement PCI hotplug support

[Oza Pawandeep]

This patch implements PCI hotplug support for iproc family chipsets.

iproc based SOC (e.g. Stingray) does not have hotplug controller
integrated.
Hence, standard PCI hotplug framework hooks can-not be used.
e.g. controlled power up/down of slot.

The mechanism, for e.g. Stingray has adopted for PCI hotplug is as
follows:
PCI present lines are input to GPIOs depending on the type of
connector (x2, x4, x8).

The implementation essentially takes care of following:
> Initializing hotplug irq thread.
> Detecting the endpoint device based on link state.
> Handling PERST and detecting the plugged devices.
> Ordered Hot plug-out, where User is expected
  to write 1 to /sys/bus/pci/devices//remove
> Handling spurious interrupt
> Handling multiple interrupts and makes sure that card is
  enumerated only once.

Signed-off-by: Oza Pawandeep 
Reviewed-by: Ray Jui 

diff --git a/drivers/pci/host/pcie-iproc-platform.c 
b/drivers/pci/host/pcie-iproc-platform.c
index 9512960..e1eb141 100644
--- a/drivers/pci/host/pcie-iproc-platform.c
+++ b/drivers/pci/host/pcie-iproc-platform.c
@@ -89,6 +89,9 @@ static int iproc_pcie_pltfm_probe(struct platform_device 
*pdev)
pcie->need_ob_cfg = true;
}
 
+   if (of_property_read_bool(np, "slot-pluggable"))
+   pcie->enable_hotplug = true;
+
/* PHY use is optional */
pcie->phy = devm_phy_get(dev, "pcie-phy");
if (IS_ERR(pcie->phy)) {
diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
index ee40651..eb919f7 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "pcie-iproc.h"
 
@@ -65,6 +66,17 @@
 #define PCIE_DL_ACTIVE_SHIFT 2
 #define PCIE_DL_ACTIVE   BIT(PCIE_DL_ACTIVE_SHIFT)
 
+#define CFG_RC_LTSSM 0x1cf8
+#define CFG_RC_PHY_CTL   0x1804
+#define CFG_RC_LTSSM_TIMEOUT 1000
+#define CFG_RC_LTSSM_STATE_MASK  0xff
+#define CFG_RC_LTSSM_STATE_L10x1
+
+#define CFG_RC_CLR_LTSSM_HIST_SHIFT  29
+#define CFG_RC_CLR_LTSSM_HIST_MASK   BIT(CFG_RC_CLR_LTSSM_HIST_SHIFT)
+#define CFG_RC_CLR_RECOV_HIST_SHIFT  31
+#define CFG_RC_CLR_RECOV_HIST_MASK   BIT(CFG_RC_CLR_RECOV_HIST_SHIFT)
+
 #define APB_ERR_EN_SHIFT 0
 #define APB_ERR_EN   BIT(APB_ERR_EN_SHIFT)
 
@@ -1306,12 +1318,106 @@ static int iproc_pcie_rev_init(struct iproc_pcie *pcie)
return 0;
 }
 
+static bool iproc_pci_hp_check_ltssm(struct iproc_pcie *pcie)
+{
+   struct pci_bus *bus = pcie->root_bus;
+   u32 val, timeout = CFG_RC_LTSSM_TIMEOUT;
+
+   /* Clear LTSSM history. */
+   pci_bus_read_config_dword(pcie->root_bus, 0,
+ CFG_RC_PHY_CTL, );
+   pci_bus_write_config_dword(bus, 0, CFG_RC_PHY_CTL,
+  val | CFG_RC_CLR_RECOV_HIST_MASK |
+  CFG_RC_CLR_LTSSM_HIST_MASK);
+   /* write back the origional value. */
+   pci_bus_write_config_dword(bus, 0, CFG_RC_PHY_CTL, val);
+
+   do {
+   pci_bus_read_config_dword(pcie->root_bus, 0,
+ CFG_RC_LTSSM, );
+   /* check link state to see if link moved to L1 state. */
+   if ((val & CFG_RC_LTSSM_STATE_MASK) ==
+CFG_RC_LTSSM_STATE_L1)
+   return true;
+   timeout--;
+   usleep_range(500, 1000);
+   } while (timeout);
+
+   return false;
+}
+
+static irqreturn_t iproc_pci_hotplug_thread(int irq, void *data)
+{
+   struct iproc_pcie *pcie = data;
+   struct pci_bus *bus = pcie->root_bus, *child;
+   bool link_status;
+
+   iproc_pcie_perst_ctrl(pcie, true);
+   iproc_pcie_perst_ctrl(pcie, false);
+
+   link_status = iproc_pci_hp_check_ltssm(pcie);
+
+   if (link_status &&
+   !iproc_pcie_check_link(pcie, bus) &&
+   !pcie->ep_is_present) {
+   pci_rescan_bus(bus);
+   list_for_each_entry(child, >children, node)
+   pcie_bus_configure_settings(child);
+   pcie->ep_is_present = true;
+   dev_info(pcie->dev,
+"PCI Hotplug: \n");
+   } else if (link_status && pcie->ep_is_present)
+   /*
+* ep_is_present makes sure, enumuration done only once.
+* So it can handle spurious intrrupts, and also if we
+* get multiple interrupts for all the implemented pins,
+* we handle it only once.
+*/
+   dev_info(pcie->dev,
+"PCI Hotplug: \n");
+   else {
+   iproc_pcie_perst_ctrl(pcie, true);
+   pcie->ep_is_present = false;
+   dev_info(pcie->dev,
+"PCI Hotplug: \n");
+   }
+   return IRQ_HANDLED;
+}
+
+static int 

[PATCH v5] clk: sunxi-ng: support R40 SoC

[Icenowy Zheng]

Allwinner R40 SoC have a clock controller module in the style of the
SoCs beyond sun6i, however, it's more rich and complex.

Add support for it.

Signed-off-by: Icenowy Zheng 
---
Changes in v5:
- Added TODO's for PLL constraints.
- Forced OHCI12M mux to 0.
- Changed "adda" clock to "codec" to be consistent with "bus-codec".
- Added several CLK_SET_RATE_{UNGATE,PARENT} flags.
- Added PLL_CPU gate notifier.
Changes in v4:
- Removed usb-ohci-12M mux clocks.
- Removed unused (and not in user manual) adda-4x clock.
- Implemented proper SATA PLL system.
- Renamed MP (Mixed Processor) clock names to drop the extra "DE_".
- Renamed TCONs' clock names to "tcon-lcdX" or "tcon-tvX".
- Added missing RST_DRAM.
- Several clock post/pre-dividers and constraints fixes.
Changes in v3:
- Rebased on current linux-next.
Changes in v2:
- Fixes according to the SoC's user manual.

 drivers/clk/sunxi-ng/Kconfig  |5 +
 drivers/clk/sunxi-ng/Makefile |1 +
 drivers/clk/sunxi-ng/ccu-sun8i-r40.c  | 1290 +
 drivers/clk/sunxi-ng/ccu-sun8i-r40.h  |   69 ++
 include/dt-bindings/clock/sun8i-r40-ccu.h |  187 +
 include/dt-bindings/reset/sun8i-r40-ccu.h |  130 +++
 6 files changed, 1682 insertions(+)
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-r40.c
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-r40.h
 create mode 100644 include/dt-bindings/clock/sun8i-r40-ccu.h
 create mode 100644 include/dt-bindings/reset/sun8i-r40-ccu.h

diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
index 7342928c35cd..7a360737fe3c 100644
--- a/drivers/clk/sunxi-ng/Kconfig
+++ b/drivers/clk/sunxi-ng/Kconfig
@@ -48,6 +48,11 @@ config SUN8I_V3S_CCU
 config SUN8I_DE2_CCU
bool "Support for the Allwinner SoCs DE2 CCU"
 
+config SUN8I_R40_CCU
+   bool "Support for the Allwinner R40 CCU"
+   default MACH_SUN8I
+   depends on MACH_SUN8I || COMPILE_TEST
+
 config SUN9I_A80_CCU
bool "Support for the Allwinner A80 CCU"
default MACH_SUN9I
diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
index 45a5910379a5..b1267fe68a8f 100644
--- a/drivers/clk/sunxi-ng/Makefile
+++ b/drivers/clk/sunxi-ng/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_SUN8I_H3_CCU)+= ccu-sun8i-h3.o
 obj-$(CONFIG_SUN8I_V3S_CCU)+= ccu-sun8i-v3s.o
 obj-$(CONFIG_SUN8I_DE2_CCU)+= ccu-sun8i-de2.o
 obj-$(CONFIG_SUN8I_R_CCU)  += ccu-sun8i-r.o
+obj-$(CONFIG_SUN8I_R40_CCU)+= ccu-sun8i-r40.o
 obj-$(CONFIG_SUN9I_A80_CCU)+= ccu-sun9i-a80.o
 obj-$(CONFIG_SUN9I_A80_CCU)+= ccu-sun9i-a80-de.o
 obj-$(CONFIG_SUN9I_A80_CCU)+= ccu-sun9i-a80-usb.o
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c 
b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
new file mode 100644
index ..abb4569d3886
--- /dev/null
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
@@ -0,0 +1,1290 @@
+/*
+ * Copyright (c) 2017 Icenowy Zheng 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+
+#include "ccu_common.h"
+#include "ccu_reset.h"
+
+#include "ccu_div.h"
+#include "ccu_gate.h"
+#include "ccu_mp.h"
+#include "ccu_mult.h"
+#include "ccu_nk.h"
+#include "ccu_nkm.h"
+#include "ccu_nkmp.h"
+#include "ccu_nm.h"
+#include "ccu_phase.h"
+
+#include "ccu-sun8i-r40.h"
+
+/* TODO: The result of N*K is required to be in [10, 88] range. */
+static struct ccu_nkmp pll_cpu_clk = {
+   .enable = BIT(31),
+   .lock   = BIT(28),
+   .n  = _SUNXI_CCU_MULT(8, 5),
+   .k  = _SUNXI_CCU_MULT(4, 2),
+   .m  = _SUNXI_CCU_DIV(0, 2),
+   .p  = _SUNXI_CCU_DIV_MAX(16, 2, 4),
+   .common = {
+   .reg= 0x000,
+   .hw.init= CLK_HW_INIT("pll-cpu",
+ "osc24M",
+ _nkmp_ops,
+ CLK_SET_RATE_UNGATE),
+   },
+};
+
+/*
+ * The Audio PLL is supposed to have 4 outputs: 3 fixed factors from
+ * the base (2x, 4x and 8x), and one variable divider (the one true
+ * pll audio).
+ *
+ * We don't have any need for the variable divider for now, so we just
+ * hardcode it to match with the clock names
+ */
+#define SUN8I_R40_PLL_AUDIO_REG0x008
+
+static SUNXI_CCU_NM_WITH_GATE_LOCK(pll_audio_base_clk, "pll-audio-base",
+  "osc24M", 0x008,
+  8, 7,/* N */
+  0, 5,/* M */
+  

Re: [patch] mm, oom: remove unused mmput_async

[Michal Hocko]

On Mon 14-08-17 17:34:32, David Rientjes wrote:
> After "mm: oom: let oom_reap_task and exit_mmap to run concurrently", 
> mmput_async() is no longer used.  Remove it.
> 
> Cc: Andrea Arcangeli 
> Signed-off-by: David Rientjes 

Acked-by: Michal Hocko 

Thanks!

> ---
>  include/linux/sched/mm.h |  6 --
>  kernel/fork.c| 16 
>  2 files changed, 22 deletions(-)
> 
> diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
> --- a/include/linux/sched/mm.h
> +++ b/include/linux/sched/mm.h
> @@ -84,12 +84,6 @@ static inline bool mmget_not_zero(struct mm_struct *mm)
>  
>  /* mmput gets rid of the mappings and all user-space */
>  extern void mmput(struct mm_struct *);
> -#ifdef CONFIG_MMU
> -/* same as above but performs the slow path from the async context. Can
> - * be called from the atomic context as well
> - */
> -extern void mmput_async(struct mm_struct *);
> -#endif
>  
>  /* Grab a reference to a task's mm, if it is not already going away */
>  extern struct mm_struct *get_task_mm(struct task_struct *task);
> diff --git a/kernel/fork.c b/kernel/fork.c
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -925,22 +925,6 @@ void mmput(struct mm_struct *mm)
>  }
>  EXPORT_SYMBOL_GPL(mmput);
>  
> -#ifdef CONFIG_MMU
> -static void mmput_async_fn(struct work_struct *work)
> -{
> - struct mm_struct *mm = container_of(work, struct mm_struct, 
> async_put_work);
> - __mmput(mm);
> -}
> -
> -void mmput_async(struct mm_struct *mm)
> -{
> - if (atomic_dec_and_test(>mm_users)) {
> - INIT_WORK(>async_put_work, mmput_async_fn);
> - schedule_work(>async_put_work);
> - }
> -}
> -#endif
> -
>  /**
>   * set_mm_exe_file - change a reference to the mm's executable file
>   *
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

-- 
Michal Hocko
SUSE Labs

Re: [PATCH] swap: choose swap device according to numa node

[Aaron Lu]

On Mon, Aug 14, 2017 at 04:33:37PM -0700, Andrew Morton wrote:
> On Mon, 14 Aug 2017 13:31:30 +0800 Aaron Lu  wrote:
> 
> > --- /dev/null
> > +++ b/Documentation/vm/swap_numa.txt
> > @@ -0,0 +1,18 @@
> > +If the system has more than one swap device and swap device has the node
> > +information, we can make use of this information to decide which swap
> > +device to use in get_swap_pages() to get better performance.
> > +
> > +The current code uses a priority based list, swap_avail_list, to decide
> > +which swap device to use and if multiple swap devices share the same
> > +priority, they are used round robin. This change here replaces the single
> > +global swap_avail_list with a per-numa-node list, i.e. for each numa node,
> > +it sees its own priority based list of available swap devices. Swap
> > +device's priority can be promoted on its matching node's swap_avail_list.
> > +
> > +The current swap device's priority is set as: user can set a >=0 value,
> > +or the system will pick one starting from -1 then downwards. The priority
> > +value in the swap_avail_list is the negated value of the swap device's
> > +due to plist being sorted from low to high. The new policy doesn't change
> > +the semantics for priority >=0 cases, the previous starting from -1 then
> > +downwards now becomes starting from -2 then downwards and -1 is reserved
> > +as the promoted value.
> 
> Could we please add a little "user guide" here?  Tell people how to set
> up their system to exploit this?  Sample /etc/fstab entries, perhaps?

That's a good idea.

How about this:

Automatically bind swap device to numa node
---

If the system has more than one swap device and swap device has the node
information, we can make use of this information to decide which swap
device to use in get_swap_pages() to get better performance.


How to use this feature
---

Swap device has priority and that decides the order of it to be used. To make
use of automatically binding, there is no need to manipulate priority settings
for swap devices. e.g. on a 2 node machine, assume 2 swap devices swapA and
swapB, with swapA attached to node 0 and swapB attached to node 1, are going
to be swapped on. Simply swapping them on by doing:
# swapon /dev/swapA
# swapon /dev/swapB

Then node 0 will use the two swap devices in the order of swapA then swapB and
node 1 will use the two swap devices in the order of swapB then swapA. Note
that the order of them being swapped on doesn't matter.

A more complex example on a 4 node machine. Assume 6 swap devices are going to
be swapped on: swapA and swapB are attached to node 0, swapC is attached to
node 1, swapD and swapE are attached to node 2 and swapF is attached to node3.
The way to swap them on is the same as above:
# swapon /dev/swapA
# swapon /dev/swapB
# swapon /dev/swapC
# swapon /dev/swapD
# swapon /dev/swapE
# swapon /dev/swapF

Then node 0 will use them in the order of:
swapA/swapB -> swapC -> swapD -> swapE -> swapF
swapA and swapB will be used in a round robin mode before any other swap device.

node 1 will use them in the order of:
swapC -> swapA -> swapB -> swapD -> swapE -> swapF

node 2 will use them in the order of:
swapD/swapE -> swapA -> swapB -> swapC -> swapF
Similaly, swapD and swapE will be used in a round robin mode before any
other swap devices.

node 3 will use them in the order of:
swapF -> swapA -> swapB -> swapC -> swapD -> swapE


Implementation details
--

The current code uses a priority based list, swap_avail_list, to decide
which swap device to use and if multiple swap devices share the same
priority, they are used round robin. This change here replaces the single
global swap_avail_list with a per-numa-node list, i.e. for each numa node,
it sees its own priority based list of available swap devices. Swap
device's priority can be promoted on its matching node's swap_avail_list.

The current swap device's priority is set as: user can set a >=0 value,
or the system will pick one starting from -1 then downwards. The priority
value in the swap_avail_list is the negated value of the swap device's
due to plist being sorted from low to high. The new policy doesn't change
the semantics for priority >=0 cases, the previous starting from -1 then
downwards now becomes starting from -2 then downwards and -1 is reserved
as the promoted value. So if multiple swap devices are attached to the same
node, they will all be promoted to priority -1 on that node's plist and will
be used round robin before any other swap devices.

> 
> >
> > ...
> >
> > +static int __init swapfile_init(void)
> > +{
> > +   int nid;
> > +
> > +   swap_avail_heads = kmalloc(nr_node_ids * sizeof(struct plist_head), 
> > GFP_KERNEL);
> > +   if (!swap_avail_heads)
> > +   return -ENOMEM;
> 
> Well, a kmalloc failure at __init time is generally considered "can't
> happen", but if it _does_ happen, the system will later oops, 

Re: [patch] mm, oom: remove unused mmput_async

[Michal Hocko]

On Mon 14-08-17 17:34:32, David Rientjes wrote:
> After "mm: oom: let oom_reap_task and exit_mmap to run concurrently", 
> mmput_async() is no longer used.  Remove it.
> 
> Cc: Andrea Arcangeli 
> Signed-off-by: David Rientjes 

Acked-by: Michal Hocko 

Thanks!

> ---
>  include/linux/sched/mm.h |  6 --
>  kernel/fork.c| 16 
>  2 files changed, 22 deletions(-)
> 
> diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
> --- a/include/linux/sched/mm.h
> +++ b/include/linux/sched/mm.h
> @@ -84,12 +84,6 @@ static inline bool mmget_not_zero(struct mm_struct *mm)
>  
>  /* mmput gets rid of the mappings and all user-space */
>  extern void mmput(struct mm_struct *);
> -#ifdef CONFIG_MMU
> -/* same as above but performs the slow path from the async context. Can
> - * be called from the atomic context as well
> - */
> -extern void mmput_async(struct mm_struct *);
> -#endif
>  
>  /* Grab a reference to a task's mm, if it is not already going away */
>  extern struct mm_struct *get_task_mm(struct task_struct *task);
> diff --git a/kernel/fork.c b/kernel/fork.c
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -925,22 +925,6 @@ void mmput(struct mm_struct *mm)
>  }
>  EXPORT_SYMBOL_GPL(mmput);
>  
> -#ifdef CONFIG_MMU
> -static void mmput_async_fn(struct work_struct *work)
> -{
> - struct mm_struct *mm = container_of(work, struct mm_struct, 
> async_put_work);
> - __mmput(mm);
> -}
> -
> -void mmput_async(struct mm_struct *mm)
> -{
> - if (atomic_dec_and_test(>mm_users)) {
> - INIT_WORK(>async_put_work, mmput_async_fn);
> - schedule_work(>async_put_work);
> - }
> -}
> -#endif
> -
>  /**
>   * set_mm_exe_file - change a reference to the mm's executable file
>   *
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

-- 
Michal Hocko
SUSE Labs

Re: [PATCH] swap: choose swap device according to numa node

[Aaron Lu]

On Mon, Aug 14, 2017 at 04:33:37PM -0700, Andrew Morton wrote:
> On Mon, 14 Aug 2017 13:31:30 +0800 Aaron Lu  wrote:
> 
> > --- /dev/null
> > +++ b/Documentation/vm/swap_numa.txt
> > @@ -0,0 +1,18 @@
> > +If the system has more than one swap device and swap device has the node
> > +information, we can make use of this information to decide which swap
> > +device to use in get_swap_pages() to get better performance.
> > +
> > +The current code uses a priority based list, swap_avail_list, to decide
> > +which swap device to use and if multiple swap devices share the same
> > +priority, they are used round robin. This change here replaces the single
> > +global swap_avail_list with a per-numa-node list, i.e. for each numa node,
> > +it sees its own priority based list of available swap devices. Swap
> > +device's priority can be promoted on its matching node's swap_avail_list.
> > +
> > +The current swap device's priority is set as: user can set a >=0 value,
> > +or the system will pick one starting from -1 then downwards. The priority
> > +value in the swap_avail_list is the negated value of the swap device's
> > +due to plist being sorted from low to high. The new policy doesn't change
> > +the semantics for priority >=0 cases, the previous starting from -1 then
> > +downwards now becomes starting from -2 then downwards and -1 is reserved
> > +as the promoted value.
> 
> Could we please add a little "user guide" here?  Tell people how to set
> up their system to exploit this?  Sample /etc/fstab entries, perhaps?

That's a good idea.

How about this:

Automatically bind swap device to numa node
---

If the system has more than one swap device and swap device has the node
information, we can make use of this information to decide which swap
device to use in get_swap_pages() to get better performance.


How to use this feature
---

Swap device has priority and that decides the order of it to be used. To make
use of automatically binding, there is no need to manipulate priority settings
for swap devices. e.g. on a 2 node machine, assume 2 swap devices swapA and
swapB, with swapA attached to node 0 and swapB attached to node 1, are going
to be swapped on. Simply swapping them on by doing:
# swapon /dev/swapA
# swapon /dev/swapB

Then node 0 will use the two swap devices in the order of swapA then swapB and
node 1 will use the two swap devices in the order of swapB then swapA. Note
that the order of them being swapped on doesn't matter.

A more complex example on a 4 node machine. Assume 6 swap devices are going to
be swapped on: swapA and swapB are attached to node 0, swapC is attached to
node 1, swapD and swapE are attached to node 2 and swapF is attached to node3.
The way to swap them on is the same as above:
# swapon /dev/swapA
# swapon /dev/swapB
# swapon /dev/swapC
# swapon /dev/swapD
# swapon /dev/swapE
# swapon /dev/swapF

Then node 0 will use them in the order of:
swapA/swapB -> swapC -> swapD -> swapE -> swapF
swapA and swapB will be used in a round robin mode before any other swap device.

node 1 will use them in the order of:
swapC -> swapA -> swapB -> swapD -> swapE -> swapF

node 2 will use them in the order of:
swapD/swapE -> swapA -> swapB -> swapC -> swapF
Similaly, swapD and swapE will be used in a round robin mode before any
other swap devices.

node 3 will use them in the order of:
swapF -> swapA -> swapB -> swapC -> swapD -> swapE


Implementation details
--

The current code uses a priority based list, swap_avail_list, to decide
which swap device to use and if multiple swap devices share the same
priority, they are used round robin. This change here replaces the single
global swap_avail_list with a per-numa-node list, i.e. for each numa node,
it sees its own priority based list of available swap devices. Swap
device's priority can be promoted on its matching node's swap_avail_list.

The current swap device's priority is set as: user can set a >=0 value,
or the system will pick one starting from -1 then downwards. The priority
value in the swap_avail_list is the negated value of the swap device's
due to plist being sorted from low to high. The new policy doesn't change
the semantics for priority >=0 cases, the previous starting from -1 then
downwards now becomes starting from -2 then downwards and -1 is reserved
as the promoted value. So if multiple swap devices are attached to the same
node, they will all be promoted to priority -1 on that node's plist and will
be used round robin before any other swap devices.

> 
> >
> > ...
> >
> > +static int __init swapfile_init(void)
> > +{
> > +   int nid;
> > +
> > +   swap_avail_heads = kmalloc(nr_node_ids * sizeof(struct plist_head), 
> > GFP_KERNEL);
> > +   if (!swap_avail_heads)
> > +   return -ENOMEM;
> 
> Well, a kmalloc failure at __init time is generally considered "can't
> happen", but if it _does_ happen, the system will later oops, I think. 

Agree.

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

[Benjamin Herrenschmidt]

On Mon, 2017-08-14 at 14:12 +0100, Robin Murphy wrote:
> On the other hand, if the check is not so much to mitigate malicious
> guests attacking the system as to prevent dumb guests breaking
> themselves (e.g. if some or all of the MSI-X capability is actually
> emulated), then allowing things to sometimes go wrong on the grounds of
> an irrelevant hardware feature doesn't seem correct :/

There is 0 value in trying to prevent the guest kernel from shooting
itself in the foot. There are so many other ways it can do it that I
fail the point of even attempting it here.

In addition, this actually harms performance on some devices. There
are cases where the MSI-X table shares a page with other registrers
that are used during normal device operation. This is especially
problematic on architectures such as powerpc that use 64K pages.

Those devices thus suffer a massive performance loss, for the sake of
something that never happens in practice (especially on pseries where
the MSI configuration is done by paravirt calls, thus by qemu itself).

Cheers,
Ben.

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

[Benjamin Herrenschmidt]

On Mon, 2017-08-14 at 14:12 +0100, Robin Murphy wrote:
> On the other hand, if the check is not so much to mitigate malicious
> guests attacking the system as to prevent dumb guests breaking
> themselves (e.g. if some or all of the MSI-X capability is actually
> emulated), then allowing things to sometimes go wrong on the grounds of
> an irrelevant hardware feature doesn't seem correct :/

There is 0 value in trying to prevent the guest kernel from shooting
itself in the foot. There are so many other ways it can do it that I
fail the point of even attempting it here.

In addition, this actually harms performance on some devices. There
are cases where the MSI-X table shares a page with other registrers
that are used during normal device operation. This is especially
problematic on architectures such as powerpc that use 64K pages.

Those devices thus suffer a massive performance loss, for the sake of
something that never happens in practice (especially on pseries where
the MSI configuration is done by paravirt calls, thus by qemu itself).

Cheers,
Ben.

Re: [PATCH 07/10] cpufreq: dt: Add support for some new Allwinner SoCs

[Chen-Yu Tsai]

On Mon, Jul 24, 2017 at 7:46 PM, Rafael J. Wysocki  wrote:
> On Monday, July 24, 2017 02:23:49 PM Viresh Kumar wrote:
>> On 23-07-17, 18:27, Icenowy Zheng wrote:
>> > Some new Allwinner SoCs get supported in the kernel after the
>> > compatibles are added to cpufreq-dt-platdev driver.
>> >
>> > Add their compatible strings in the cpufreq-dt-platdev driver.
>> >
>> > Cc: "Rafael J. Wysocki" 
>> > Cc: Viresh Kumar 
>> > Signed-off-by: Icenowy Zheng 
>> > ---
>> >  drivers/cpufreq/cpufreq-dt-platdev.c | 6 ++
>> >  1 file changed, 6 insertions(+)
>> >
>> > diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c 
>> > b/drivers/cpufreq/cpufreq-dt-platdev.c
>> > index 2eb40d46d357..c3851453e84a 100644
>> > --- a/drivers/cpufreq/cpufreq-dt-platdev.c
>> > +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
>> > @@ -24,7 +24,11 @@ static const struct of_device_id machines[] __initconst 
>> > = {
>> > { .compatible = "allwinner,sun8i-a23", },
>> > { .compatible = "allwinner,sun8i-a33", },
>> > { .compatible = "allwinner,sun8i-a83t", },
>> > +   { .compatible = "allwinner,sun8i-h2-plus", },
>> > { .compatible = "allwinner,sun8i-h3", },
>> > +   { .compatible = "allwinner,sun8i-v3s", },
>> > +   { .compatible = "allwinner,sun50i-a64", },
>> > +   { .compatible = "allwinner,sun50i-h5", },
>> >
>> > { .compatible = "apm,xgene-shadowcat", },
>> >
>> > @@ -43,6 +47,8 @@ static const struct of_device_id machines[] __initconst 
>> > = {
>> > { .compatible = "marvell,pxa250", },
>> > { .compatible = "marvell,pxa270", },
>> >
>> > +   { .compatible = "nextthing,gr8", },
>> > +
>> > { .compatible = "samsung,exynos3250", },
>> > { .compatible = "samsung,exynos4210", },
>> > { .compatible = "samsung,exynos4212", },
>>
>> Acked-by: Viresh Kumar 
>>
>>
>
> OK
>
> I'm assuming this will go in via arm-soc along with the rest of the series.

The rest of the series, except for the clk patches I've already taken,
doesn't seem to be going anywhere just yet. Is there a cpufreq or pm tree
this can be merged through?

Thanks
ChenYu

Re: [PATCH 07/10] cpufreq: dt: Add support for some new Allwinner SoCs

[Chen-Yu Tsai]

On Mon, Jul 24, 2017 at 7:46 PM, Rafael J. Wysocki  wrote:
> On Monday, July 24, 2017 02:23:49 PM Viresh Kumar wrote:
>> On 23-07-17, 18:27, Icenowy Zheng wrote:
>> > Some new Allwinner SoCs get supported in the kernel after the
>> > compatibles are added to cpufreq-dt-platdev driver.
>> >
>> > Add their compatible strings in the cpufreq-dt-platdev driver.
>> >
>> > Cc: "Rafael J. Wysocki" 
>> > Cc: Viresh Kumar 
>> > Signed-off-by: Icenowy Zheng 
>> > ---
>> >  drivers/cpufreq/cpufreq-dt-platdev.c | 6 ++
>> >  1 file changed, 6 insertions(+)
>> >
>> > diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c 
>> > b/drivers/cpufreq/cpufreq-dt-platdev.c
>> > index 2eb40d46d357..c3851453e84a 100644
>> > --- a/drivers/cpufreq/cpufreq-dt-platdev.c
>> > +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
>> > @@ -24,7 +24,11 @@ static const struct of_device_id machines[] __initconst 
>> > = {
>> > { .compatible = "allwinner,sun8i-a23", },
>> > { .compatible = "allwinner,sun8i-a33", },
>> > { .compatible = "allwinner,sun8i-a83t", },
>> > +   { .compatible = "allwinner,sun8i-h2-plus", },
>> > { .compatible = "allwinner,sun8i-h3", },
>> > +   { .compatible = "allwinner,sun8i-v3s", },
>> > +   { .compatible = "allwinner,sun50i-a64", },
>> > +   { .compatible = "allwinner,sun50i-h5", },
>> >
>> > { .compatible = "apm,xgene-shadowcat", },
>> >
>> > @@ -43,6 +47,8 @@ static const struct of_device_id machines[] __initconst 
>> > = {
>> > { .compatible = "marvell,pxa250", },
>> > { .compatible = "marvell,pxa270", },
>> >
>> > +   { .compatible = "nextthing,gr8", },
>> > +
>> > { .compatible = "samsung,exynos3250", },
>> > { .compatible = "samsung,exynos4210", },
>> > { .compatible = "samsung,exynos4212", },
>>
>> Acked-by: Viresh Kumar 
>>
>>
>
> OK
>
> I'm assuming this will go in via arm-soc along with the rest of the series.

The rest of the series, except for the clk patches I've already taken,
doesn't seem to be going anywhere just yet. Is there a cpufreq or pm tree
this can be merged through?

Thanks
ChenYu

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

[Benjamin Herrenschmidt]

On Tue, 2017-08-15 at 09:47 +0800, Jike Song wrote:
> On 08/15/2017 09:33 AM, Benjamin Herrenschmidt wrote:
> > On Tue, 2017-08-15 at 09:16 +0800, Jike Song wrote:
> > > > Taking a step back, though, why does vfio-pci perform this check in the
> > > > first place? If a malicious guest already has control of a device, any
> > > > kind of interrupt spoofing it could do by fiddling with the MSI-X
> > > > message address/data it could simply do with a DMA write anyway, so the
> > > > security argument doesn't stand up in general (sure, not all PCIe
> > > > devices may be capable of arbitrary DMA, but that seems like more of a
> > > > tenuous security-by-obscurity angle to me).
> > 
> > I tried to make that point for years, thanks for re-iterating it :-)
> > 
> > > Hi Robin,
> > > 
> > > DMA writes will be translated (thereby censored) by DMA Remapping 
> > > hardware,
> > > while MSI/MSI-X will not. Is this different for non-x86?
> > 
> > There is no way your DMA remapping HW can differenciate. The only
> > difference between a DMA write and an MSI is ... the address. So if I
> > can make my device DMA to the MSI address range, I've defeated your
> > security.
> 
> I don't think with IRQ remapping enabled, you can make your device DMA to
> MSI address, without being treated as an IRQ and remapped. If so, the IRQ
> remapping hardware is simply broken :)

You are mixing things here.

Robin's point is that there is no security provided by the obfuscating
of the MSI-X table by qemu because whatever qemu does to "filter" the
MSI-X targer addresses can be worked around by making the device DMA
wherever you want.

None of what you say invalidates that basic fact.

Now, as far as your remapping HW goes, either it filters interrupts or
it doesn't. If it does then yes, it can't be spoofed, and thus you
don't need the filtering of the table in qemu.

If it doesn't, then the guest can spoof any interrupt using DMAs and
whatever qemu does to filter the table is not going to fix it.

Thus the point remains that the only value in qemu filtering the table
is to enable already insecure use cases to work, without actually
making them any more secure.

Ben.

Re: [RFC PATCH v5 0/5] vfio-pci: Add support for mmapping MSI-X table

[Benjamin Herrenschmidt]

On Tue, 2017-08-15 at 09:47 +0800, Jike Song wrote:
> On 08/15/2017 09:33 AM, Benjamin Herrenschmidt wrote:
> > On Tue, 2017-08-15 at 09:16 +0800, Jike Song wrote:
> > > > Taking a step back, though, why does vfio-pci perform this check in the
> > > > first place? If a malicious guest already has control of a device, any
> > > > kind of interrupt spoofing it could do by fiddling with the MSI-X
> > > > message address/data it could simply do with a DMA write anyway, so the
> > > > security argument doesn't stand up in general (sure, not all PCIe
> > > > devices may be capable of arbitrary DMA, but that seems like more of a
> > > > tenuous security-by-obscurity angle to me).
> > 
> > I tried to make that point for years, thanks for re-iterating it :-)
> > 
> > > Hi Robin,
> > > 
> > > DMA writes will be translated (thereby censored) by DMA Remapping 
> > > hardware,
> > > while MSI/MSI-X will not. Is this different for non-x86?
> > 
> > There is no way your DMA remapping HW can differenciate. The only
> > difference between a DMA write and an MSI is ... the address. So if I
> > can make my device DMA to the MSI address range, I've defeated your
> > security.
> 
> I don't think with IRQ remapping enabled, you can make your device DMA to
> MSI address, without being treated as an IRQ and remapped. If so, the IRQ
> remapping hardware is simply broken :)

You are mixing things here.

Robin's point is that there is no security provided by the obfuscating
of the MSI-X table by qemu because whatever qemu does to "filter" the
MSI-X targer addresses can be worked around by making the device DMA
wherever you want.

None of what you say invalidates that basic fact.

Now, as far as your remapping HW goes, either it filters interrupts or
it doesn't. If it does then yes, it can't be spoofed, and thus you
don't need the filtering of the table in qemu.

If it doesn't, then the guest can spoof any interrupt using DMAs and
whatever qemu does to filter the table is not going to fix it.

Thus the point remains that the only value in qemu filtering the table
is to enable already insecure use cases to work, without actually
making them any more secure.

Ben.

[PATCH] x86/xen/64: Fix the reported SS and CS in SYSCALL

[Andy Lutomirski]

When I cleaned up the Xen SYSCALL entries, I inadvertently changed
the reported segment registers.  Before my patch, regs->ss was
__USER(32)_DS and regs->cs was __USER(32)_CS.  After the patch, they
are FLAT_USER_CS/DS(32).

This had a couple unfortunate effects.  It confused the
opportunistic fast return logic.  It also significantly increased
the risk of triggering a nasty glibc bug:

https://sourceware.org/bugzilla/show_bug.cgi?id=21269

Update the Xen entry code to change it back.

Reported-by: Brian Gerst 
Fixes: 8a9949bc71a7 ("x86/xen/64: Rearrange the SYSCALL entries")
Signed-off-by: Andy Lutomirski 
---
 arch/x86/xen/xen-asm_64.S | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/x86/xen/xen-asm_64.S b/arch/x86/xen/xen-asm_64.S
index a8a4f4c460a6..c5fee2680abc 100644
--- a/arch/x86/xen/xen-asm_64.S
+++ b/arch/x86/xen/xen-asm_64.S
@@ -88,6 +88,15 @@ RELOC(xen_sysret64, 1b+1)
 ENTRY(xen_syscall_target)
popq %rcx
popq %r11
+
+   /*
+* Neither Xen nor the kernel really knows what the old SS and
+* CS were.  The kernel expects __USER_DS and __USER_CS, so
+* report those values even though Xen will guess its own values.
+*/
+   movq $__USER_DS, 4*8(%rsp)
+   movq $__USER_CS, 1*8(%rsp)
+
jmp entry_SYSCALL_64_after_hwframe
 ENDPROC(xen_syscall_target)
 
@@ -97,6 +106,15 @@ ENDPROC(xen_syscall_target)
 ENTRY(xen_syscall32_target)
popq %rcx
popq %r11
+
+   /*
+* Neither Xen nor the kernel really knows what the old SS and
+* CS were.  The kernel expects __USER32_DS and __USER32_CS, so
+* report those values even though Xen will guess its own values.
+*/
+   movq $__USER32_DS, 4*8(%rsp)
+   movq $__USER32_CS, 1*8(%rsp)
+
jmp entry_SYSCALL_compat_after_hwframe
 ENDPROC(xen_syscall32_target)
 
-- 
2.13.3

[PATCH] x86/xen/64: Fix the reported SS and CS in SYSCALL

[Andy Lutomirski]

When I cleaned up the Xen SYSCALL entries, I inadvertently changed
the reported segment registers.  Before my patch, regs->ss was
__USER(32)_DS and regs->cs was __USER(32)_CS.  After the patch, they
are FLAT_USER_CS/DS(32).

This had a couple unfortunate effects.  It confused the
opportunistic fast return logic.  It also significantly increased
the risk of triggering a nasty glibc bug:

https://sourceware.org/bugzilla/show_bug.cgi?id=21269

Update the Xen entry code to change it back.

Reported-by: Brian Gerst 
Fixes: 8a9949bc71a7 ("x86/xen/64: Rearrange the SYSCALL entries")
Signed-off-by: Andy Lutomirski 
---
 arch/x86/xen/xen-asm_64.S | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/x86/xen/xen-asm_64.S b/arch/x86/xen/xen-asm_64.S
index a8a4f4c460a6..c5fee2680abc 100644
--- a/arch/x86/xen/xen-asm_64.S
+++ b/arch/x86/xen/xen-asm_64.S
@@ -88,6 +88,15 @@ RELOC(xen_sysret64, 1b+1)
 ENTRY(xen_syscall_target)
popq %rcx
popq %r11
+
+   /*
+* Neither Xen nor the kernel really knows what the old SS and
+* CS were.  The kernel expects __USER_DS and __USER_CS, so
+* report those values even though Xen will guess its own values.
+*/
+   movq $__USER_DS, 4*8(%rsp)
+   movq $__USER_CS, 1*8(%rsp)
+
jmp entry_SYSCALL_64_after_hwframe
 ENDPROC(xen_syscall_target)
 
@@ -97,6 +106,15 @@ ENDPROC(xen_syscall_target)
 ENTRY(xen_syscall32_target)
popq %rcx
popq %r11
+
+   /*
+* Neither Xen nor the kernel really knows what the old SS and
+* CS were.  The kernel expects __USER32_DS and __USER32_CS, so
+* report those values even though Xen will guess its own values.
+*/
+   movq $__USER32_DS, 4*8(%rsp)
+   movq $__USER32_CS, 1*8(%rsp)
+
jmp entry_SYSCALL_compat_after_hwframe
 ENDPROC(xen_syscall32_target)
 
-- 
2.13.3

[PATCH 3/3] thunderbolt: Allow clearing the key

[Bernat, Yehezkel]

If secure authentication of a devices fails, either because the device
already has another key uploaded, or there is some other error sending
challenge to the device, and the user only wants to approve the device
just once (without a new key being uploaded to the device) the current
implementation does not allow this because the key cannot be cleared
once set even if we allow it to be changed.

Make this scenario possible and allow clearing the key by writing
empty string to the key sysfs file.

Signed-off-by: Yehezkel Bernat 
---
 Documentation/ABI/testing/sysfs-bus-thunderbolt |  2 ++
 drivers/thunderbolt/switch.c| 15 +++
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-bus-thunderbolt 
b/Documentation/ABI/testing/sysfs-bus-thunderbolt
index 2a98149..392bef5 100644
--- a/Documentation/ABI/testing/sysfs-bus-thunderbolt
+++ b/Documentation/ABI/testing/sysfs-bus-thunderbolt
@@ -45,6 +45,8 @@ Contact:  thunderbolt-softw...@lists.01.org
 Description:   When a devices supports Thunderbolt secure connect it will
have this attribute. Writing 32 byte hex string changes
authorization to use the secure connection method instead.
+   Writing an empty string clears the key and regular connection
+   method can be used again.
 
 What:  /sys/bus/thunderbolt/devices/.../device
 Date:  Sep 2017
diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
index 8510abc..53f40c5 100644
--- a/drivers/thunderbolt/switch.c
+++ b/drivers/thunderbolt/switch.c
@@ -807,8 +807,11 @@ static ssize_t key_store(struct device *dev, struct 
device_attribute *attr,
struct tb_switch *sw = tb_to_switch(dev);
u8 key[TB_SWITCH_KEY_SIZE];
ssize_t ret = count;
+   bool clear = false;
 
-   if (hex2bin(key, buf, sizeof(key)))
+   if (!strcmp(buf, "\n"))
+   clear = true;
+   else if (hex2bin(key, buf, sizeof(key)))
return -EINVAL;
 
if (mutex_lock_interruptible(_lock))
@@ -818,9 +821,13 @@ static ssize_t key_store(struct device *dev, struct 
device_attribute *attr,
ret = -EBUSY;
} else {
kfree(sw->key);
-   sw->key = kmemdup(key, sizeof(key), GFP_KERNEL);
-   if (!sw->key)
-   ret = -ENOMEM;
+   if (clear) {
+   sw->key = NULL;
+   } else {
+   sw->key = kmemdup(key, sizeof(key), GFP_KERNEL);
+   if (!sw->key)
+   ret = -ENOMEM;
+   }
}
 
mutex_unlock(_lock);
-- 
2.7.4

[PATCH 3/3] thunderbolt: Allow clearing the key

[Bernat, Yehezkel]

If secure authentication of a devices fails, either because the device
already has another key uploaded, or there is some other error sending
challenge to the device, and the user only wants to approve the device
just once (without a new key being uploaded to the device) the current
implementation does not allow this because the key cannot be cleared
once set even if we allow it to be changed.

Make this scenario possible and allow clearing the key by writing
empty string to the key sysfs file.

Signed-off-by: Yehezkel Bernat 
---
 Documentation/ABI/testing/sysfs-bus-thunderbolt |  2 ++
 drivers/thunderbolt/switch.c| 15 +++
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-bus-thunderbolt 
b/Documentation/ABI/testing/sysfs-bus-thunderbolt
index 2a98149..392bef5 100644
--- a/Documentation/ABI/testing/sysfs-bus-thunderbolt
+++ b/Documentation/ABI/testing/sysfs-bus-thunderbolt
@@ -45,6 +45,8 @@ Contact:  thunderbolt-softw...@lists.01.org
 Description:   When a devices supports Thunderbolt secure connect it will
have this attribute. Writing 32 byte hex string changes
authorization to use the secure connection method instead.
+   Writing an empty string clears the key and regular connection
+   method can be used again.
 
 What:  /sys/bus/thunderbolt/devices/.../device
 Date:  Sep 2017
diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
index 8510abc..53f40c5 100644
--- a/drivers/thunderbolt/switch.c
+++ b/drivers/thunderbolt/switch.c
@@ -807,8 +807,11 @@ static ssize_t key_store(struct device *dev, struct 
device_attribute *attr,
struct tb_switch *sw = tb_to_switch(dev);
u8 key[TB_SWITCH_KEY_SIZE];
ssize_t ret = count;
+   bool clear = false;
 
-   if (hex2bin(key, buf, sizeof(key)))
+   if (!strcmp(buf, "\n"))
+   clear = true;
+   else if (hex2bin(key, buf, sizeof(key)))
return -EINVAL;
 
if (mutex_lock_interruptible(_lock))
@@ -818,9 +821,13 @@ static ssize_t key_store(struct device *dev, struct 
device_attribute *attr,
ret = -EBUSY;
} else {
kfree(sw->key);
-   sw->key = kmemdup(key, sizeof(key), GFP_KERNEL);
-   if (!sw->key)
-   ret = -ENOMEM;
+   if (clear) {
+   sw->key = NULL;
+   } else {
+   sw->key = kmemdup(key, sizeof(key), GFP_KERNEL);
+   if (!sw->key)
+   ret = -ENOMEM;
+   }
}
 
mutex_unlock(_lock);
-- 
2.7.4

[PATCH 2/3] thunderbolt: Make key root-only accessible

[Bernat, Yehezkel]

Non-root user may read the key back after root wrote it there.
This removes read access to everyone but root.

Signed-off-by: Yehezkel Bernat 
---
 drivers/thunderbolt/switch.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
index 69fde0b..8510abc 100644
--- a/drivers/thunderbolt/switch.c
+++ b/drivers/thunderbolt/switch.c
@@ -826,7 +826,7 @@ static ssize_t key_store(struct device *dev, struct 
device_attribute *attr,
mutex_unlock(_lock);
return ret;
 }
-static DEVICE_ATTR_RW(key);
+static DEVICE_ATTR(key, 0600, key_show, key_store);
 
 static ssize_t nvm_authenticate_show(struct device *dev,
struct device_attribute *attr, char *buf)
-- 
2.7.4

[PATCH 2/3] thunderbolt: Make key root-only accessible

[Bernat, Yehezkel]

Non-root user may read the key back after root wrote it there.
This removes read access to everyone but root.

Signed-off-by: Yehezkel Bernat 
---
 drivers/thunderbolt/switch.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
index 69fde0b..8510abc 100644
--- a/drivers/thunderbolt/switch.c
+++ b/drivers/thunderbolt/switch.c
@@ -826,7 +826,7 @@ static ssize_t key_store(struct device *dev, struct 
device_attribute *attr,
mutex_unlock(_lock);
return ret;
 }
-static DEVICE_ATTR_RW(key);
+static DEVICE_ATTR(key, 0600, key_show, key_store);
 
 static ssize_t nvm_authenticate_show(struct device *dev,
struct device_attribute *attr, char *buf)
-- 
2.7.4

[PATCH 1/3] thunderbolt: Remove superfluous check

[Bernat, Yehezkel]

The key size is tested by hex2bin() already (as '\0' isn't an hex digit)

Suggested-by: Andy Shevchenko 
Signed-off-by: Yehezkel Bernat 
---
 drivers/thunderbolt/switch.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
index e9391bb..69fde0b 100644
--- a/drivers/thunderbolt/switch.c
+++ b/drivers/thunderbolt/switch.c
@@ -808,9 +808,6 @@ static ssize_t key_store(struct device *dev, struct 
device_attribute *attr,
u8 key[TB_SWITCH_KEY_SIZE];
ssize_t ret = count;
 
-   if (count < 64)
-   return -EINVAL;
-
if (hex2bin(key, buf, sizeof(key)))
return -EINVAL;
 
-- 
2.7.4

[PATCH 1/3] thunderbolt: Remove superfluous check

[Bernat, Yehezkel]

The key size is tested by hex2bin() already (as '\0' isn't an hex digit)

Suggested-by: Andy Shevchenko 
Signed-off-by: Yehezkel Bernat 
---
 drivers/thunderbolt/switch.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
index e9391bb..69fde0b 100644
--- a/drivers/thunderbolt/switch.c
+++ b/drivers/thunderbolt/switch.c
@@ -808,9 +808,6 @@ static ssize_t key_store(struct device *dev, struct 
device_attribute *attr,
u8 key[TB_SWITCH_KEY_SIZE];
ssize_t ret = count;
 
-   if (count < 64)
-   return -EINVAL;
-
if (hex2bin(key, buf, sizeof(key)))
return -EINVAL;
 
-- 
2.7.4

Re: [PATCH v11 0/5] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

[David Miller]

From: Ding Tianhong 
Date: Tue, 15 Aug 2017 11:23:22 +0800

> Some devices have problems with Transaction Layer Packets with the Relaxed
> Ordering Attribute set.  This patch set adds a new PCIe Device Flag,
> PCI_DEV_FLAGS_NO_RELAXED_ORDERING, a set of PCI Quirks to catch some known
> devices with Relaxed Ordering issues, and a use of this new flag by the
> cxgb4 driver to avoid using Relaxed Ordering with problematic Root Complex
> Ports.
 ...

Series applied, thanks.

Re: [PATCH v11 0/5] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

[David Miller]

From: Ding Tianhong 
Date: Tue, 15 Aug 2017 11:23:22 +0800

> Some devices have problems with Transaction Layer Packets with the Relaxed
> Ordering Attribute set.  This patch set adds a new PCIe Device Flag,
> PCI_DEV_FLAGS_NO_RELAXED_ORDERING, a set of PCI Quirks to catch some known
> devices with Relaxed Ordering issues, and a use of this new flag by the
> cxgb4 driver to avoid using Relaxed Ordering with problematic Root Complex
> Ports.
 ...

Series applied, thanks.

Re: [PATCH v5 18/19] crypto: mediatek: move to generic async completion

[Ryder Lee]

On Mon, 2017-08-14 at 18:21 +0300, Gilad Ben-Yossef wrote:
> The mediatek driver starts several async crypto ops and waits for their
> completions. Move it over to generic code doing the same.
> 
> Signed-off-by: Gilad Ben-Yossef 
> ---

Acked-by: Ryder Lee 

>  drivers/crypto/mediatek/mtk-aes.c | 31 +--
>  1 file changed, 5 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/crypto/mediatek/mtk-aes.c 
> b/drivers/crypto/mediatek/mtk-aes.c
> index 9e845e8..e2c7c95 100644
> --- a/drivers/crypto/mediatek/mtk-aes.c
> +++ b/drivers/crypto/mediatek/mtk-aes.c
> @@ -137,11 +137,6 @@ struct mtk_aes_gcm_ctx {
>   struct crypto_skcipher *ctr;
>  };
>  
> -struct mtk_aes_gcm_setkey_result {
> - int err;
> - struct completion completion;
> -};
> -
>  struct mtk_aes_drv {
>   struct list_head dev_list;
>   /* Device list lock */
> @@ -936,17 +931,6 @@ static int mtk_aes_gcm_crypt(struct aead_request *req, 
> u64 mode)
>   >base);
>  }
>  
> -static void mtk_gcm_setkey_done(struct crypto_async_request *req, int err)
> -{
> - struct mtk_aes_gcm_setkey_result *result = req->data;
> -
> - if (err == -EINPROGRESS)
> - return;
> -
> - result->err = err;
> - complete(>completion);
> -}
> -
>  /*
>   * Because of the hardware limitation, we need to pre-calculate key(H)
>   * for the GHASH operation. The result of the encryption operation
> @@ -962,7 +946,7 @@ static int mtk_aes_gcm_setkey(struct crypto_aead *aead, 
> const u8 *key,
>   u32 hash[4];
>   u8 iv[8];
>  
> - struct mtk_aes_gcm_setkey_result result;
> + struct crypto_wait wait;
>  
>   struct scatterlist sg[1];
>   struct skcipher_request req;
> @@ -1002,22 +986,17 @@ static int mtk_aes_gcm_setkey(struct crypto_aead 
> *aead, const u8 *key,
>   if (!data)
>   return -ENOMEM;
>  
> - init_completion(>result.completion);
> + crypto_init_wait(>wait);
>   sg_init_one(data->sg, >hash, AES_BLOCK_SIZE);
>   skcipher_request_set_tfm(>req, ctr);
>   skcipher_request_set_callback(>req, CRYPTO_TFM_REQ_MAY_SLEEP |
> CRYPTO_TFM_REQ_MAY_BACKLOG,
> -   mtk_gcm_setkey_done, >result);
> +   crypto_req_done, >wait);
>   skcipher_request_set_crypt(>req, data->sg, data->sg,
>  AES_BLOCK_SIZE, data->iv);
>  
> - err = crypto_skcipher_encrypt(>req);
> - if (err == -EINPROGRESS || err == -EBUSY) {
> - err = wait_for_completion_interruptible(
> - >result.completion);
> - if (!err)
> - err = data->result.err;
> - }
> + err = crypto_wait_req(crypto_skcipher_encrypt(>req),
> +   >wait);
>   if (err)
>   goto out;
>  

Re: [PATCH v5 18/19] crypto: mediatek: move to generic async completion

[Ryder Lee]

On Mon, 2017-08-14 at 18:21 +0300, Gilad Ben-Yossef wrote:
> The mediatek driver starts several async crypto ops and waits for their
> completions. Move it over to generic code doing the same.
> 
> Signed-off-by: Gilad Ben-Yossef 
> ---

Acked-by: Ryder Lee 

>  drivers/crypto/mediatek/mtk-aes.c | 31 +--
>  1 file changed, 5 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/crypto/mediatek/mtk-aes.c 
> b/drivers/crypto/mediatek/mtk-aes.c
> index 9e845e8..e2c7c95 100644
> --- a/drivers/crypto/mediatek/mtk-aes.c
> +++ b/drivers/crypto/mediatek/mtk-aes.c
> @@ -137,11 +137,6 @@ struct mtk_aes_gcm_ctx {
>   struct crypto_skcipher *ctr;
>  };
>  
> -struct mtk_aes_gcm_setkey_result {
> - int err;
> - struct completion completion;
> -};
> -
>  struct mtk_aes_drv {
>   struct list_head dev_list;
>   /* Device list lock */
> @@ -936,17 +931,6 @@ static int mtk_aes_gcm_crypt(struct aead_request *req, 
> u64 mode)
>   >base);
>  }
>  
> -static void mtk_gcm_setkey_done(struct crypto_async_request *req, int err)
> -{
> - struct mtk_aes_gcm_setkey_result *result = req->data;
> -
> - if (err == -EINPROGRESS)
> - return;
> -
> - result->err = err;
> - complete(>completion);
> -}
> -
>  /*
>   * Because of the hardware limitation, we need to pre-calculate key(H)
>   * for the GHASH operation. The result of the encryption operation
> @@ -962,7 +946,7 @@ static int mtk_aes_gcm_setkey(struct crypto_aead *aead, 
> const u8 *key,
>   u32 hash[4];
>   u8 iv[8];
>  
> - struct mtk_aes_gcm_setkey_result result;
> + struct crypto_wait wait;
>  
>   struct scatterlist sg[1];
>   struct skcipher_request req;
> @@ -1002,22 +986,17 @@ static int mtk_aes_gcm_setkey(struct crypto_aead 
> *aead, const u8 *key,
>   if (!data)
>   return -ENOMEM;
>  
> - init_completion(>result.completion);
> + crypto_init_wait(>wait);
>   sg_init_one(data->sg, >hash, AES_BLOCK_SIZE);
>   skcipher_request_set_tfm(>req, ctr);
>   skcipher_request_set_callback(>req, CRYPTO_TFM_REQ_MAY_SLEEP |
> CRYPTO_TFM_REQ_MAY_BACKLOG,
> -   mtk_gcm_setkey_done, >result);
> +   crypto_req_done, >wait);
>   skcipher_request_set_crypt(>req, data->sg, data->sg,
>  AES_BLOCK_SIZE, data->iv);
>  
> - err = crypto_skcipher_encrypt(>req);
> - if (err == -EINPROGRESS || err == -EBUSY) {
> - err = wait_for_completion_interruptible(
> - >result.completion);
> - if (!err)
> - err = data->result.err;
> - }
> + err = crypto_wait_req(crypto_skcipher_encrypt(>req),
> +   >wait);
>   if (err)
>   goto out;
>  

Re: [PATCH] Input: ati_remote2: constify usb_device_id

[Dmitry Torokhov]

On Tue, Aug 08, 2017 at 10:24:12PM +0530, Arvind Yadav wrote:
> usb_device_id are not supposed to change at runtime. All functions
> working with usb_device_id provided by  work with
> const usb_device_id. So mark the non-const structs as const.
> 
> Signed-off-by: Arvind Yadav 

Applied, thank you.

> ---
>  drivers/input/misc/ati_remote2.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/input/misc/ati_remote2.c 
> b/drivers/input/misc/ati_remote2.c
> index 1c5914c..ebf4448 100644
> --- a/drivers/input/misc/ati_remote2.c
> +++ b/drivers/input/misc/ati_remote2.c
> @@ -110,7 +110,7 @@ static const struct kernel_param_ops param_ops_mode_mask 
> = {
>  module_param(mode_mask, mode_mask, 0644);
>  MODULE_PARM_DESC(mode_mask, "Bitmask of modes to accept 
> <4:PC><3:AUX4><2:AUX3><1:AUX2><0:AUX1>");
>  
> -static struct usb_device_id ati_remote2_id_table[] = {
> +static const struct usb_device_id ati_remote2_id_table[] = {
>   { USB_DEVICE(0x0471, 0x0602) }, /* ATI Remote Wonder II */
>   { }
>  };
> -- 
> 2.7.4
> 

-- 
Dmitry

Re: [PATCH] Input: ati_remote2: constify usb_device_id

[Dmitry Torokhov]

On Tue, Aug 08, 2017 at 10:24:12PM +0530, Arvind Yadav wrote:
> usb_device_id are not supposed to change at runtime. All functions
> working with usb_device_id provided by  work with
> const usb_device_id. So mark the non-const structs as const.
> 
> Signed-off-by: Arvind Yadav 

Applied, thank you.

> ---
>  drivers/input/misc/ati_remote2.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/input/misc/ati_remote2.c 
> b/drivers/input/misc/ati_remote2.c
> index 1c5914c..ebf4448 100644
> --- a/drivers/input/misc/ati_remote2.c
> +++ b/drivers/input/misc/ati_remote2.c
> @@ -110,7 +110,7 @@ static const struct kernel_param_ops param_ops_mode_mask 
> = {
>  module_param(mode_mask, mode_mask, 0644);
>  MODULE_PARM_DESC(mode_mask, "Bitmask of modes to accept 
> <4:PC><3:AUX4><2:AUX3><1:AUX2><0:AUX1>");
>  
> -static struct usb_device_id ati_remote2_id_table[] = {
> +static const struct usb_device_id ati_remote2_id_table[] = {
>   { USB_DEVICE(0x0471, 0x0602) }, /* ATI Remote Wonder II */
>   { }
>  };
> -- 
> 2.7.4
> 

-- 
Dmitry

Re: [PATCH 6/9 v2] Input: sun4i-ts - constify thermal_zone_of_device_ops structures

[Dmitry Torokhov]

On Tue, Aug 08, 2017 at 05:09:00PM +0200, Julia Lawall wrote:
> The thermal_zone_of_device_ops structure is only passed as the fourth
> argument to devm_thermal_zone_of_sensor_register, which is declared
> as const.  Thus the thermal_zone_of_device_ops structure itself can
> be const.
> 
> Done with the help of Coccinelle.
> 
> Signed-off-by: Julia Lawall 

Applied, thank you.

> 
> ---
> 
> v2: New patch
> 
>  drivers/input/touchscreen/sun4i-ts.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/input/touchscreen/sun4i-ts.c 
> b/drivers/input/touchscreen/sun4i-ts.c
> index d07dd29..d2e14d9 100644
> --- a/drivers/input/touchscreen/sun4i-ts.c
> +++ b/drivers/input/touchscreen/sun4i-ts.c
> @@ -206,7 +206,7 @@ static int sun4i_get_tz_temp(void *data, int *temp)
>   return sun4i_get_temp(data, temp);
>  }
>  
> -static struct thermal_zone_of_device_ops sun4i_ts_tz_ops = {
> +static const struct thermal_zone_of_device_ops sun4i_ts_tz_ops = {
>   .get_temp = sun4i_get_tz_temp,
>  };
>  
> 

-- 
Dmitry

Re: [PATCH 6/9 v2] Input: sun4i-ts - constify thermal_zone_of_device_ops structures

[Dmitry Torokhov]

On Tue, Aug 08, 2017 at 05:09:00PM +0200, Julia Lawall wrote:
> The thermal_zone_of_device_ops structure is only passed as the fourth
> argument to devm_thermal_zone_of_sensor_register, which is declared
> as const.  Thus the thermal_zone_of_device_ops structure itself can
> be const.
> 
> Done with the help of Coccinelle.
> 
> Signed-off-by: Julia Lawall 

Applied, thank you.

> 
> ---
> 
> v2: New patch
> 
>  drivers/input/touchscreen/sun4i-ts.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/input/touchscreen/sun4i-ts.c 
> b/drivers/input/touchscreen/sun4i-ts.c
> index d07dd29..d2e14d9 100644
> --- a/drivers/input/touchscreen/sun4i-ts.c
> +++ b/drivers/input/touchscreen/sun4i-ts.c
> @@ -206,7 +206,7 @@ static int sun4i_get_tz_temp(void *data, int *temp)
>   return sun4i_get_temp(data, temp);
>  }
>  
> -static struct thermal_zone_of_device_ops sun4i_ts_tz_ops = {
> +static const struct thermal_zone_of_device_ops sun4i_ts_tz_ops = {
>   .get_temp = sun4i_get_tz_temp,
>  };
>  
> 

-- 
Dmitry

Re: [PATCH net-next V2 3/3] tap: XDP support

[Jason Wang]

On 2017年08月15日 00:01, Michael S. Tsirkin wrote:

On Sat, Aug 12, 2017 at 10:48:49AM +0800, Jason Wang wrote:


On 2017年08月12日 07:12, Jakub Kicinski wrote:

On Fri, 11 Aug 2017 19:41:18 +0800, Jason Wang wrote:

This patch tries to implement XDP for tun. The implementation was
split into two parts:

- fast path: small and no gso packet. We try to do XDP at page level
before build_skb(). For XDP_TX, since creating/destroying queues
were completely under control of userspace, it was implemented
through generic XDP helper after skb has been built. This could be
optimized in the future.
- slow path: big or gso packet. We try to do it after skb was created
through generic XDP helpers.

Test were done through pktgen with small packets.

xdp1 test shows ~41.1% improvement:

Before: ~1.7Mpps
After:  ~2.3Mpps

xdp_redirect to ixgbe shows ~60% improvement:

Before: ~0.8Mpps
After:  ~1.38Mpps

Suggested-by: Michael S. Tsirkin 
Signed-off-by: Jason Wang 

Looks OK to me now :)

Out of curiosity, you say the build_skb() is for "small packets", and it
seems you are always reserving the 256B regardless of XDP being
installed.  Does this have no performance impact on non-XDP case?

Have a test, only less than 1% were noticed which I think could be ignored.

Thanks

What did you test btw?


Pktgen


  The biggest issue would be with something like
UDP with short packets.



Note that we do this only when sndbuf is INT_MAX. So this is probably 
not an issue. The only thing matter is more stress to page allocator, 
but according to the result of pktgen it was very small that could be 
ignored.


Thanks

Re: [PATCH v7 7/9] mm: Add address parameter to arch_validate_prot()

[Michael Ellerman]

Khalid Aziz  writes:

> On 08/10/2017 07:20 AM, Michael Ellerman wrote:
>> Khalid Aziz  writes:
>> 
>>> A protection flag may not be valid across entire address space and
>>> hence arch_validate_prot() might need the address a protection bit is
>>> being set on to ensure it is a valid protection flag. For example, sparc
>>> processors support memory corruption detection (as part of ADI feature)
>>> flag on memory addresses mapped on to physical RAM but not on PFN mapped
>>> pages or addresses mapped on to devices. This patch adds address to the
>>> parameters being passed to arch_validate_prot() so protection bits can
>>> be validated in the relevant context.
>>>
>>> Signed-off-by: Khalid Aziz 
>>> Cc: Khalid Aziz 
>>> ---
>>> v7:
>>> - new patch
>>>
>>>   arch/powerpc/include/asm/mman.h | 2 +-
>>>   arch/powerpc/kernel/syscalls.c  | 2 +-
>>>   include/linux/mman.h| 2 +-
>>>   mm/mprotect.c   | 2 +-
>>>   4 files changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/powerpc/include/asm/mman.h 
>>> b/arch/powerpc/include/asm/mman.h
>>> index 30922f699341..bc74074304a2 100644
>>> --- a/arch/powerpc/include/asm/mman.h
>>> +++ b/arch/powerpc/include/asm/mman.h
>>> @@ -40,7 +40,7 @@ static inline bool arch_validate_prot(unsigned long prot)
>>> return false;
>>> return true;
>>>   }
>>> -#define arch_validate_prot(prot) arch_validate_prot(prot)
>>> +#define arch_validate_prot(prot, addr) arch_validate_prot(prot)
>> 
>> This can be simpler, as just:
>> 
>> #define arch_validate_prot arch_validate_prot
>> 
>
> Hi Michael,
>
> Thanks for reviewing!
>
> My patch expands parameter list for arch_validate_prot() from one to two 
> parameters. Existing powerpc version of arch_validate_prot() is written 
> with one parameter. If I use the above #define, compilation fails with:
>
> mm/mprotect.c: In function ‘do_mprotect_pkey’:
> mm/mprotect.c:399: error: too many arguments to function 
> ‘arch_validate_prot’
>
> Another way to solve it would be to add the new addr parameter to 
> powerpc version of arch_validate_prot() but I chose the less disruptive 
> solution of tackling it through #define and expanded the existing 
> #define to include the new parameter. Make sense?

Yes, it makes sense. But it's a bit gross.

At first glance it looks like our arch_validate_prot() has an incorrect
signature.

I'd prefer you just updated it to have the correct signature, I think
you'll have to change one more line in do_mmap2(). So it's not very
intrusive.

cheers

Re: [PATCH net-next V2 3/3] tap: XDP support

[Jason Wang]

On 2017年08月15日 00:01, Michael S. Tsirkin wrote:

On Sat, Aug 12, 2017 at 10:48:49AM +0800, Jason Wang wrote:


On 2017年08月12日 07:12, Jakub Kicinski wrote:

On Fri, 11 Aug 2017 19:41:18 +0800, Jason Wang wrote:

This patch tries to implement XDP for tun. The implementation was
split into two parts:

- fast path: small and no gso packet. We try to do XDP at page level
before build_skb(). For XDP_TX, since creating/destroying queues
were completely under control of userspace, it was implemented
through generic XDP helper after skb has been built. This could be
optimized in the future.
- slow path: big or gso packet. We try to do it after skb was created
through generic XDP helpers.

Test were done through pktgen with small packets.

xdp1 test shows ~41.1% improvement:

Before: ~1.7Mpps
After:  ~2.3Mpps

xdp_redirect to ixgbe shows ~60% improvement:

Before: ~0.8Mpps
After:  ~1.38Mpps

Suggested-by: Michael S. Tsirkin 
Signed-off-by: Jason Wang 

Looks OK to me now :)

Out of curiosity, you say the build_skb() is for "small packets", and it
seems you are always reserving the 256B regardless of XDP being
installed.  Does this have no performance impact on non-XDP case?

Have a test, only less than 1% were noticed which I think could be ignored.

Thanks

What did you test btw?


Pktgen


  The biggest issue would be with something like
UDP with short packets.



Note that we do this only when sndbuf is INT_MAX. So this is probably 
not an issue. The only thing matter is more stress to page allocator, 
but according to the result of pktgen it was very small that could be 
ignored.


Thanks

Re: [PATCH v7 7/9] mm: Add address parameter to arch_validate_prot()

[Michael Ellerman]

Khalid Aziz  writes:

> On 08/10/2017 07:20 AM, Michael Ellerman wrote:
>> Khalid Aziz  writes:
>> 
>>> A protection flag may not be valid across entire address space and
>>> hence arch_validate_prot() might need the address a protection bit is
>>> being set on to ensure it is a valid protection flag. For example, sparc
>>> processors support memory corruption detection (as part of ADI feature)
>>> flag on memory addresses mapped on to physical RAM but not on PFN mapped
>>> pages or addresses mapped on to devices. This patch adds address to the
>>> parameters being passed to arch_validate_prot() so protection bits can
>>> be validated in the relevant context.
>>>
>>> Signed-off-by: Khalid Aziz 
>>> Cc: Khalid Aziz 
>>> ---
>>> v7:
>>> - new patch
>>>
>>>   arch/powerpc/include/asm/mman.h | 2 +-
>>>   arch/powerpc/kernel/syscalls.c  | 2 +-
>>>   include/linux/mman.h| 2 +-
>>>   mm/mprotect.c   | 2 +-
>>>   4 files changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/powerpc/include/asm/mman.h 
>>> b/arch/powerpc/include/asm/mman.h
>>> index 30922f699341..bc74074304a2 100644
>>> --- a/arch/powerpc/include/asm/mman.h
>>> +++ b/arch/powerpc/include/asm/mman.h
>>> @@ -40,7 +40,7 @@ static inline bool arch_validate_prot(unsigned long prot)
>>> return false;
>>> return true;
>>>   }
>>> -#define arch_validate_prot(prot) arch_validate_prot(prot)
>>> +#define arch_validate_prot(prot, addr) arch_validate_prot(prot)
>> 
>> This can be simpler, as just:
>> 
>> #define arch_validate_prot arch_validate_prot
>> 
>
> Hi Michael,
>
> Thanks for reviewing!
>
> My patch expands parameter list for arch_validate_prot() from one to two 
> parameters. Existing powerpc version of arch_validate_prot() is written 
> with one parameter. If I use the above #define, compilation fails with:
>
> mm/mprotect.c: In function ‘do_mprotect_pkey’:
> mm/mprotect.c:399: error: too many arguments to function 
> ‘arch_validate_prot’
>
> Another way to solve it would be to add the new addr parameter to 
> powerpc version of arch_validate_prot() but I chose the less disruptive 
> solution of tackling it through #define and expanded the existing 
> #define to include the new parameter. Make sense?

Yes, it makes sense. But it's a bit gross.

At first glance it looks like our arch_validate_prot() has an incorrect
signature.

I'd prefer you just updated it to have the correct signature, I think
you'll have to change one more line in do_mmap2(). So it's not very
intrusive.

cheers

[PATCH v2] gpio: add gpio_add_lookup_tables() to add several tables at once

[Dmitry Torokhov]

When converting legacy board to use gpiod API() there might be several
lookup tables in board file, let's provide a way to register them all at
once.

Reviewed-by: Andy Shevchenko 
Reviewed-by: Mika Westerberg 
Signed-off-by: Dmitry Torokhov 
---

V2:
- added the !CONFIG_GPIOLIB stub (Andy)
- changed size from unsigned int to size_t at Mika's suggestion
- added Reviewed-bys.

 drivers/gpio/gpiolib.c   | 17 +
 include/linux/gpio/machine.h |  3 +++
 2 files changed, 20 insertions(+)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index a42a1eea5714..667289ca4913 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -3010,6 +3010,23 @@ void gpiod_add_lookup_table(struct gpiod_lookup_table 
*table)
mutex_unlock(_lookup_lock);
 }
 
+/**
+ * gpiod_add_lookup_tables() - register GPIO device consumers
+ * @tables: list of tables of consumers to register
+ * @n: number of tables in the list
+ */
+void gpiod_add_lookup_tables(struct gpiod_lookup_table **tables, size_t n)
+{
+   unsigned int i;
+
+   mutex_lock(_lookup_lock);
+
+   for (i = 0; i < n; i++)
+   list_add_tail([i]->list, _lookup_list);
+
+   mutex_unlock(_lookup_lock);
+}
+
 /**
  * gpiod_remove_lookup_table() - unregister GPIO device consumers
  * @table: table of consumers to unregister
diff --git a/include/linux/gpio/machine.h b/include/linux/gpio/machine.h
index f738d50cc17d..ec80fa7c0c7d 100644
--- a/include/linux/gpio/machine.h
+++ b/include/linux/gpio/machine.h
@@ -58,11 +58,14 @@ struct gpiod_lookup_table {
 
 #ifdef CONFIG_GPIOLIB
 void gpiod_add_lookup_table(struct gpiod_lookup_table *table);
+void gpiod_add_lookup_tables(struct gpiod_lookup_table **tables, size_t n);
 void gpiod_remove_lookup_table(struct gpiod_lookup_table *table);
 #else
 static inline
 void gpiod_add_lookup_table(struct gpiod_lookup_table *table) {}
 static inline
+void gpiod_add_lookup_tables(struct gpiod_lookup_table **tables, size_t n) {}
+static inline
 void gpiod_remove_lookup_table(struct gpiod_lookup_table *table) {}
 #endif
 
-- 
2.14.0.434.g98096fd7a8-goog


-- 
Dmitry

[PATCH v2] gpio: add gpio_add_lookup_tables() to add several tables at once

[Dmitry Torokhov]

When converting legacy board to use gpiod API() there might be several
lookup tables in board file, let's provide a way to register them all at
once.

Reviewed-by: Andy Shevchenko 
Reviewed-by: Mika Westerberg 
Signed-off-by: Dmitry Torokhov 
---

V2:
- added the !CONFIG_GPIOLIB stub (Andy)
- changed size from unsigned int to size_t at Mika's suggestion
- added Reviewed-bys.

 drivers/gpio/gpiolib.c   | 17 +
 include/linux/gpio/machine.h |  3 +++
 2 files changed, 20 insertions(+)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index a42a1eea5714..667289ca4913 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -3010,6 +3010,23 @@ void gpiod_add_lookup_table(struct gpiod_lookup_table 
*table)
mutex_unlock(_lookup_lock);
 }
 
+/**
+ * gpiod_add_lookup_tables() - register GPIO device consumers
+ * @tables: list of tables of consumers to register
+ * @n: number of tables in the list
+ */
+void gpiod_add_lookup_tables(struct gpiod_lookup_table **tables, size_t n)
+{
+   unsigned int i;
+
+   mutex_lock(_lookup_lock);
+
+   for (i = 0; i < n; i++)
+   list_add_tail([i]->list, _lookup_list);
+
+   mutex_unlock(_lookup_lock);
+}
+
 /**
  * gpiod_remove_lookup_table() - unregister GPIO device consumers
  * @table: table of consumers to unregister
diff --git a/include/linux/gpio/machine.h b/include/linux/gpio/machine.h
index f738d50cc17d..ec80fa7c0c7d 100644
--- a/include/linux/gpio/machine.h
+++ b/include/linux/gpio/machine.h
@@ -58,11 +58,14 @@ struct gpiod_lookup_table {
 
 #ifdef CONFIG_GPIOLIB
 void gpiod_add_lookup_table(struct gpiod_lookup_table *table);
+void gpiod_add_lookup_tables(struct gpiod_lookup_table **tables, size_t n);
 void gpiod_remove_lookup_table(struct gpiod_lookup_table *table);
 #else
 static inline
 void gpiod_add_lookup_table(struct gpiod_lookup_table *table) {}
 static inline
+void gpiod_add_lookup_tables(struct gpiod_lookup_table **tables, size_t n) {}
+static inline
 void gpiod_remove_lookup_table(struct gpiod_lookup_table *table) {}
 #endif
 
-- 
2.14.0.434.g98096fd7a8-goog


-- 
Dmitry

Re: [PATCH net-next V2 3/3] tap: XDP support

[Jason Wang]

On 2017年08月14日 16:43, Daniel Borkmann wrote:

On 08/11/2017 01:41 PM, Jason Wang wrote:

This patch tries to implement XDP for tun. The implementation was
split into two parts:

[...]
@@ -1402,6 +1521,22 @@ static ssize_t tun_get_user(struct tun_struct 
*tun, struct tun_file *tfile,

  skb_reset_network_header(skb);
  skb_probe_transport_header(skb, 0);

+if (generic_xdp) {
+struct bpf_prog *xdp_prog;
+int ret;
+
+rcu_read_lock();
+xdp_prog = rcu_dereference(tun->xdp_prog);


The name generic_xdp is a bit confusing in this context given this
is 'native' XDP, perhaps above if (generic_xdp) should have a comment
explaining semantics for tun and how it relates to actual generic xdp
that sits at dev->xdp_prog, and gets run from netif_rx_ni(). Or just
name the bool xdp_handle_gso with a comment that we let the generic
XDP infrastructure deal with non-linear skbs instead of having to
re-implement the do_xdp_generic() internals, plus a statement that
the actual generic XDP comes a bit later in the path. That would at
least make it more obvious to read, imho.


Ok, since non gso packet (e.g jumbo packet) may go this way too, 
something like "xdp_handle_skb" is better. Will send a patch.


Thanks




+if (xdp_prog) {
+ret = do_xdp_generic(xdp_prog, skb);
+if (ret != XDP_PASS) {
+rcu_read_unlock();
+return total_len;
+}
+}
+rcu_read_unlock();
+}
+
  rxhash = __skb_get_hash_symmetric(skb);
  #ifndef CONFIG_4KSTACKS
  tun_rx_batched(tun, tfile, skb, more);

Re: [PATCH net-next V2 3/3] tap: XDP support

[Jason Wang]

On 2017年08月14日 16:43, Daniel Borkmann wrote:

On 08/11/2017 01:41 PM, Jason Wang wrote:

This patch tries to implement XDP for tun. The implementation was
split into two parts:

[...]
@@ -1402,6 +1521,22 @@ static ssize_t tun_get_user(struct tun_struct 
*tun, struct tun_file *tfile,

  skb_reset_network_header(skb);
  skb_probe_transport_header(skb, 0);

+if (generic_xdp) {
+struct bpf_prog *xdp_prog;
+int ret;
+
+rcu_read_lock();
+xdp_prog = rcu_dereference(tun->xdp_prog);


The name generic_xdp is a bit confusing in this context given this
is 'native' XDP, perhaps above if (generic_xdp) should have a comment
explaining semantics for tun and how it relates to actual generic xdp
that sits at dev->xdp_prog, and gets run from netif_rx_ni(). Or just
name the bool xdp_handle_gso with a comment that we let the generic
XDP infrastructure deal with non-linear skbs instead of having to
re-implement the do_xdp_generic() internals, plus a statement that
the actual generic XDP comes a bit later in the path. That would at
least make it more obvious to read, imho.


Ok, since non gso packet (e.g jumbo packet) may go this way too, 
something like "xdp_handle_skb" is better. Will send a patch.


Thanks




+if (xdp_prog) {
+ret = do_xdp_generic(xdp_prog, skb);
+if (ret != XDP_PASS) {
+rcu_read_unlock();
+return total_len;
+}
+}
+rcu_read_unlock();
+}
+
  rxhash = __skb_get_hash_symmetric(skb);
  #ifndef CONFIG_4KSTACKS
  tun_rx_batched(tun, tfile, skb, more);

Re: [PATCH] Input: elan_i2c - add ELAN0608 to the ACPI table

[Dmitry Torokhov]

On Thu, Aug 10, 2017 at 04:53:52PM +0800, Kai-Heng Feng wrote:
> Similar to commit 722c5ac708b4f ("Input: elan_i2c - add ELAN0605 to the
> ACPI table"), ELAN0608 should be handled by elan_i2c.
> 
> This touchpad can be found in Lenovo ideapad 320-14IKB.
> 
> BugLink: https://bugs.launchpad.net/bugs/1708852
> 
> Signed-off-by: Kai-Heng Feng 

Applied, thank you.

> ---
>  drivers/input/mouse/elan_i2c_core.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/input/mouse/elan_i2c_core.c 
> b/drivers/input/mouse/elan_i2c_core.c
> index 3b616cb7c67f..9fe3908d12d5 100644
> --- a/drivers/input/mouse/elan_i2c_core.c
> +++ b/drivers/input/mouse/elan_i2c_core.c
> @@ -1248,6 +1248,7 @@ static const struct acpi_device_id elan_acpi_id[] = {
>   { "ELAN0100", 0 },
>   { "ELAN0600", 0 },
>   { "ELAN0605", 0 },
> + { "ELAN0608", 0 },
>   { "ELAN1000", 0 },
>   { }
>  };
> -- 
> 2.14.0
> 

-- 
Dmitry

Re: [PATCH] Input: elan_i2c - add ELAN0608 to the ACPI table

[Dmitry Torokhov]

On Thu, Aug 10, 2017 at 04:53:52PM +0800, Kai-Heng Feng wrote:
> Similar to commit 722c5ac708b4f ("Input: elan_i2c - add ELAN0605 to the
> ACPI table"), ELAN0608 should be handled by elan_i2c.
> 
> This touchpad can be found in Lenovo ideapad 320-14IKB.
> 
> BugLink: https://bugs.launchpad.net/bugs/1708852
> 
> Signed-off-by: Kai-Heng Feng 

Applied, thank you.

> ---
>  drivers/input/mouse/elan_i2c_core.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/input/mouse/elan_i2c_core.c 
> b/drivers/input/mouse/elan_i2c_core.c
> index 3b616cb7c67f..9fe3908d12d5 100644
> --- a/drivers/input/mouse/elan_i2c_core.c
> +++ b/drivers/input/mouse/elan_i2c_core.c
> @@ -1248,6 +1248,7 @@ static const struct acpi_device_id elan_acpi_id[] = {
>   { "ELAN0100", 0 },
>   { "ELAN0600", 0 },
>   { "ELAN0605", 0 },
> + { "ELAN0608", 0 },
>   { "ELAN1000", 0 },
>   { }
>  };
> -- 
> 2.14.0
> 

-- 
Dmitry

Re: [PATCH v2] watchdog: dw_wdt: fix overflow issue in dw_wdt_top_in_seconds

[Guenter Roeck]

On 08/14/2017 07:45 PM, Huibin Hong wrote:

If top is 15, (1 << (16 + top)) may be negative.

Signed-off-by: Huibin Hong 
---

Changes in v2:
 - Rebase mainline Linux 4.13-rc5

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

diff --git a/drivers/watchdog/dw_wdt.c b/drivers/watchdog/dw_wdt.c
index 36be987..59ed958 100644
--- a/drivers/watchdog/dw_wdt.c
+++ b/drivers/watchdog/dw_wdt.c
@@ -72,7 +72,9 @@ static inline int dw_wdt_top_in_seconds(struct dw_wdt 
*dw_wdt, unsigned top)
 * There are 16 possible timeout values in 0..15 where the number of
 * cycles is 2 ^ (16 + i) and the watchdog counts down.
 */
-   return (1U << (16 + top)) / dw_wdt->rate;
+   unsigned int cycles = 1 << (16 + top);
+
+   return (cycles / clk_get_rate(dw_wdt.clk));


Sorry I didn't catch this earlier. Why not use dw_wdt->rate ?
It has been checked against 0, and presumably the rate does not change
on its own. If it can change, you'll have to submit a separate patch
dropping the use of dw_wdt->rate entirely and explaining the reason.
You'll also have to make sure that the driver somehow catches the
rate change and adjusts its settings automatically; otherwise, timeouts
will be off target, and the system can reset unexpectedly.

Thanks,
Guenter


  }
  
  static int dw_wdt_get_top(struct dw_wdt *dw_wdt)

Re: [PATCH v2] watchdog: dw_wdt: fix overflow issue in dw_wdt_top_in_seconds

[Guenter Roeck]

On 08/14/2017 07:45 PM, Huibin Hong wrote:

If top is 15, (1 << (16 + top)) may be negative.

Signed-off-by: Huibin Hong 
---

Changes in v2:
 - Rebase mainline Linux 4.13-rc5

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

diff --git a/drivers/watchdog/dw_wdt.c b/drivers/watchdog/dw_wdt.c
index 36be987..59ed958 100644
--- a/drivers/watchdog/dw_wdt.c
+++ b/drivers/watchdog/dw_wdt.c
@@ -72,7 +72,9 @@ static inline int dw_wdt_top_in_seconds(struct dw_wdt 
*dw_wdt, unsigned top)
 * There are 16 possible timeout values in 0..15 where the number of
 * cycles is 2 ^ (16 + i) and the watchdog counts down.
 */
-   return (1U << (16 + top)) / dw_wdt->rate;
+   unsigned int cycles = 1 << (16 + top);
+
+   return (cycles / clk_get_rate(dw_wdt.clk));


Sorry I didn't catch this earlier. Why not use dw_wdt->rate ?
It has been checked against 0, and presumably the rate does not change
on its own. If it can change, you'll have to submit a separate patch
dropping the use of dw_wdt->rate entirely and explaining the reason.
You'll also have to make sure that the driver somehow catches the
rate change and adjusts its settings automatically; otherwise, timeouts
will be off target, and the system can reset unexpectedly.

Thanks,
Guenter


  }
  
  static int dw_wdt_get_top(struct dw_wdt *dw_wdt)

RE: [PATCH 0/5] cramfs refresh for embedded usage

[Nicolas Pitre]

On Mon, 14 Aug 2017, Chris Brandt wrote:

> On Monday, August 14, 2017, Nicolas Pitre wrote:
> > > However, now with your mkcramfs tool, I can no longer mount my cramfs
> > > image as the rootfs on boot. I was able to do that before (ie, 30
> > minutes
> > > ago) when using the community mkcramfs (ie, 30 minutes ago).
> > >
> > > I get this:
> > >
> > > [1.712425] cramfs: checking physical address 0x1b00 for linear
> > cramfs image
> > > [1.720531] cramfs: linear cramfs image appears to be 15744 KB in
> > size
> > > [1.728656] VFS: Mounted root (cramfs_physmem filesystem) readonly on
> > device 0:12.
> > > [1.737062] devtmpfs: mounted
> > > [1.741139] Freeing unused kernel memory: 48K
> > > [1.745545] This architecture does not have kernel memory protection.
> > > [1.760381] Starting init: /sbin/init exists but couldn't execute it
> > (error -22)
> > > [1.769685] Starting init: /bin/sh exists but couldn't execute it
> > (error -14)
> > 
> > Is /sbin/init a link to busybox?
> 
> Yes.
> 
> 
> > I suppose it just boots if you do mkcramfs without -X?
> 
> Correct. I just created another image and removed the "-X -X" when 
> creating it. Now I can boot that image as my rootfs.
>   (I'm using -X -X because I'm using a Cortex-A9 with MMU).
> 
> 
> > If so could you share your non-working cramfs image with me?
> 
> I will send it (in a separate email)

I was able to reproduce. The following patch on top should partially fix 
it.  I'm trying to figure out how to split a vma and link it properly in 
the case the vma cannot be mapped entirely. In the mean time shared libs 
won't be XIP.


diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
index 5aedbd224e..4c7f01fcd2 100644
--- a/fs/cramfs/inode.c
+++ b/fs/cramfs/inode.c
@@ -285,10 +285,10 @@ static void *cramfs_read(struct super_block *sb, unsigned 
int offset,
 
 /*
  * For a mapping to be possible, we need a range of uncompressed and
- * contiguous blocks. Return the offset for the first block if that
- * verifies, or zero otherwise.
+ * contiguous blocks. Return the offset for the first block and number of
+ * valid blocks for which that is true, or zero otherwise.
  */
-static u32 cramfs_get_block_range(struct inode *inode, u32 pgoff, u32 pages)
+static u32 cramfs_get_block_range(struct inode *inode, u32 pgoff, u32 *pages)
 {
struct super_block *sb = inode->i_sb;
struct cramfs_sb_info *sbi = CRAMFS_SB(sb);
@@ -306,11 +306,16 @@ static u32 cramfs_get_block_range(struct inode *inode, 
u32 pgoff, u32 pages)
do {
u32 expect = blockaddr + i * (PAGE_SIZE >> 2);
expect |= 
CRAMFS_BLK_FLAG_DIRECT_PTR|CRAMFS_BLK_FLAG_UNCOMPRESSED;
-   pr_debug("range: block %d/%d got %#x expects %#x\n",
-pgoff+i, pgoff+pages-1, blockptrs[i], expect);
-   if (blockptrs[i] != expect)
-   return 0;
-   } while (++i < pages);
+   if (blockptrs[i] != expect) {
+   pr_debug("range: block %d/%d got %#x expects %#x\n",
+pgoff+i, pgoff+*pages-1, blockptrs[i], expect);
+   if (i == 0)
+   return 0;
+   break;
+   }
+   } while (++i < *pages);
+
+   *pages = i;
 
/* stored "direct" block ptrs are shifted down by 2 bits */
return blockaddr << 2;
@@ -321,8 +326,8 @@ static int cramfs_physmem_mmap(struct file *file, struct 
vm_area_struct *vma)
struct inode *inode = file_inode(file);
struct super_block *sb = inode->i_sb;
struct cramfs_sb_info *sbi = CRAMFS_SB(sb);
-   unsigned int pages, max_pages, offset;
-   unsigned long length, address;
+   unsigned int pages, vma_pages, max_pages, offset;
+   unsigned long address;
char *fail_reason;
int ret;
 
@@ -332,17 +337,20 @@ static int cramfs_physmem_mmap(struct file *file, struct 
vm_area_struct *vma)
if ((vma->vm_flags & VM_SHARED) && (vma->vm_flags & VM_MAYWRITE))
return -EINVAL;
 
-   vma->vm_ops = _file_vm_ops;
+   fail_reason = "vma is writable";
if (vma->vm_flags & VM_WRITE)
-   return 0;
+   goto fail;
 
-   length = vma->vm_end - vma->vm_start;
-   pages = (length + PAGE_SIZE - 1) >> PAGE_SHIFT;
+   vma_pages = (vma->vm_end - vma->vm_start + PAGE_SIZE - 1) >> PAGE_SHIFT;
max_pages = (inode->i_size + PAGE_SIZE - 1) >> PAGE_SHIFT;
-   if (vma->vm_pgoff >= max_pages || pages > max_pages - vma->vm_pgoff)
-   return -EINVAL;
+   fail_reason = "beyond file limit";
+   if (vma->vm_pgoff >= max_pages)
+   goto fail;
+   pages = vma_pages;
+   if (pages > max_pages - vma->vm_pgoff)
+   pages = max_pages - vma->vm_pgoff;
 
-   offset = cramfs_get_block_range(inode, vma->vm_pgoff, pages);
+   offset = cramfs_get_block_range(inode, 

Re: [linux-sunxi] [PATCH v6] arm64: allwinner: a64: Add initial NanoPi A64 support

[Chen-Yu Tsai]

On Tue, Aug 15, 2017 at 11:51 AM, Jagan Teki  wrote:
> On Tue, Aug 15, 2017 at 9:14 AM, Chen-Yu Tsai  wrote:
>> On Mon, Aug 14, 2017 at 6:36 PM, Jagan Teki  wrote:

[...]

>>> +/* i2c1 connected with gpio headers like pine64, bananapi */
>>> + {
>>> +   pinctrl-names = "default";
>>> +   pinctrl-0 = <_pins>;
>>> +   status = "okay";
>>
>> So I rechecked some of the current dts files we have. We typically
>> don't enable peripherals by default if they are on some generic
>> expansion header. We do however allow listing them with an explicit
>>
>> status = "disabled";
>>
>> Users are free to enable it themselves. The listing lets them enable
>> it from U-boot with a single fdt command.

[...]

>>> +_dldo1 {
>>> +   regulator-always-on;
>>> +   regulator-min-microvolt = <330>;
>>> +   regulator-max-microvolt = <330>;
>>> +   /* Same used for vcc-dsi */
>>> +   regulator-name = "vcc-hdmi";
>>
>> We normally just tack on all the consumers to the name, so
>> "vcc-hdmi-dsi" in this case.
>>
>>> +};
>>> +
>>> +_dldo4 {
>>> +   regulator-always-on;
>>> +   regulator-min-microvolt = <300>;
>>> +   regulator-max-microvolt = <300>;
>>> +   /* Same used for vdd_wifi-io */
>>> +   regulator-name = "vcc-pg";
>>
>> And "vcc-pg-wifi-io" here.
>>
>> I can fix up these bits when applying, if you are OK with the changes.
>
> OK, please make necessary changes.
>
> thanks!

Done. Please check the results of both your patches here:

https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/log/?h=sunxi/dt64-for-4.14

ChenYu

Re: [PATCH v2] f2fs: introduce cur_reserved_blocks in sysfs

[Yunlong Song]

ping...

On 2017/8/11 19:43, Yunlong Song wrote:

In this patch, we add a new sysfs interface, we can use it to gradually achieve
the reserved_blocks finally, even when reserved_blocks is initially set over
user_block_count - total_valid_block_count. This is very useful, especially when
we upgrade kernel with new reserved_blocks value, but old disk image unluckily 
has
user_block_count - total_valid_block_count smaller than the desired 
reserved_blocks.
With this patch, f2fs can try its best to reserve space and get close to the
reserved_blocks, and the current value of achieved reserved_blocks can be shown
in real time.

To ensure there is enough space for supporting system's activation, we safely
increase cur_reserved_blocks in dev_valid_block(,node)_count to only take up the
blocks which are just obsoleted.

Signed-off-by: Yunlong Song 
---
  Documentation/ABI/testing/sysfs-fs-f2fs |  6 ++
  fs/f2fs/f2fs.h  |  9 +++--
  fs/f2fs/super.c |  3 ++-
  fs/f2fs/sysfs.c | 15 ++-
  4 files changed, 25 insertions(+), 8 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs 
b/Documentation/ABI/testing/sysfs-fs-f2fs
index 11b7f4e..bdbb9f3 100644
--- a/Documentation/ABI/testing/sysfs-fs-f2fs
+++ b/Documentation/ABI/testing/sysfs-fs-f2fs
@@ -151,3 +151,9 @@ Date:   August 2017
  Contact:  "Jaegeuk Kim" 
  Description:
 Controls sleep time of GC urgent mode
+
+What:  /sys/fs/f2fs//cur_reserved_blocks
+Date:  August 2017
+Contact:   "Yunlong Song" 
+Description:
+Shows current reserved blocks in system.
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 2f20b6b..62d7343 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1041,6 +1041,7 @@ struct f2fs_sb_info {
block_t discard_blks;   /* discard command candidats */
block_t last_valid_block_count; /* for recovery */
block_t reserved_blocks;/* configurable reserved blocks 
*/
+   block_t cur_reserved_blocks;/* current reserved blocks */
  
  	u32 s_next_generation;			/* for NFS support */
  
@@ -1515,7 +1516,7 @@ static inline int inc_valid_block_count(struct f2fs_sb_info *sbi,
  
  	spin_lock(>stat_lock);

sbi->total_valid_block_count += (block_t)(*count);
-   avail_user_block_count = sbi->user_block_count - sbi->reserved_blocks;
+   avail_user_block_count = sbi->user_block_count - 
sbi->cur_reserved_blocks;
if (unlikely(sbi->total_valid_block_count > avail_user_block_count)) {
diff = sbi->total_valid_block_count - avail_user_block_count;
*count -= diff;
@@ -1549,6 +1550,8 @@ static inline void dec_valid_block_count(struct 
f2fs_sb_info *sbi,
f2fs_bug_on(sbi, sbi->total_valid_block_count < (block_t) count);
f2fs_bug_on(sbi, inode->i_blocks < sectors);
sbi->total_valid_block_count -= (block_t)count;
+   sbi->cur_reserved_blocks = min(sbi->reserved_blocks,
+   
sbi->cur_reserved_blocks + count);
spin_unlock(>stat_lock);
f2fs_i_blocks_write(inode, count, false, true);
  }
@@ -1695,7 +1698,7 @@ static inline int inc_valid_node_count(struct 
f2fs_sb_info *sbi,
spin_lock(>stat_lock);
  
  	valid_block_count = sbi->total_valid_block_count + 1;

-   if (unlikely(valid_block_count + sbi->reserved_blocks >
+   if (unlikely(valid_block_count + sbi->cur_reserved_blocks >
sbi->user_block_count)) {
spin_unlock(>stat_lock);
goto enospc;
@@ -1738,6 +1741,8 @@ static inline void dec_valid_node_count(struct 
f2fs_sb_info *sbi,
  
  	sbi->total_valid_node_count--;

sbi->total_valid_block_count--;
+   sbi->cur_reserved_blocks = min(sbi->reserved_blocks,
+   
sbi->cur_reserved_blocks + 1);
  
  	spin_unlock(>stat_lock);
  
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c

index 4c1bdcb..16a805f 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -957,7 +957,7 @@ static int f2fs_statfs(struct dentry *dentry, struct 
kstatfs *buf)
buf->f_blocks = total_count - start_count;
buf->f_bfree = user_block_count - valid_user_blocks(sbi) + ovp_count;
buf->f_bavail = user_block_count - valid_user_blocks(sbi) -
-   sbi->reserved_blocks;
+   sbi->cur_reserved_blocks;
  
  	avail_node_count = sbi->total_node_count - F2FS_RESERVED_NODE_NUM;
  
@@ -2411,6 +2411,7 @@ static int f2fs_fill_super(struct super_block *sb, void *data, int silent)

le64_to_cpu(sbi->ckpt->valid_block_count);

RE: [PATCH 0/5] cramfs refresh for embedded usage

[Nicolas Pitre]

On Mon, 14 Aug 2017, Chris Brandt wrote:

> On Monday, August 14, 2017, Nicolas Pitre wrote:
> > > However, now with your mkcramfs tool, I can no longer mount my cramfs
> > > image as the rootfs on boot. I was able to do that before (ie, 30
> > minutes
> > > ago) when using the community mkcramfs (ie, 30 minutes ago).
> > >
> > > I get this:
> > >
> > > [1.712425] cramfs: checking physical address 0x1b00 for linear
> > cramfs image
> > > [1.720531] cramfs: linear cramfs image appears to be 15744 KB in
> > size
> > > [1.728656] VFS: Mounted root (cramfs_physmem filesystem) readonly on
> > device 0:12.
> > > [1.737062] devtmpfs: mounted
> > > [1.741139] Freeing unused kernel memory: 48K
> > > [1.745545] This architecture does not have kernel memory protection.
> > > [1.760381] Starting init: /sbin/init exists but couldn't execute it
> > (error -22)
> > > [1.769685] Starting init: /bin/sh exists but couldn't execute it
> > (error -14)
> > 
> > Is /sbin/init a link to busybox?
> 
> Yes.
> 
> 
> > I suppose it just boots if you do mkcramfs without -X?
> 
> Correct. I just created another image and removed the "-X -X" when 
> creating it. Now I can boot that image as my rootfs.
>   (I'm using -X -X because I'm using a Cortex-A9 with MMU).
> 
> 
> > If so could you share your non-working cramfs image with me?
> 
> I will send it (in a separate email)

I was able to reproduce. The following patch on top should partially fix 
it.  I'm trying to figure out how to split a vma and link it properly in 
the case the vma cannot be mapped entirely. In the mean time shared libs 
won't be XIP.


diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
index 5aedbd224e..4c7f01fcd2 100644
--- a/fs/cramfs/inode.c
+++ b/fs/cramfs/inode.c
@@ -285,10 +285,10 @@ static void *cramfs_read(struct super_block *sb, unsigned 
int offset,
 
 /*
  * For a mapping to be possible, we need a range of uncompressed and
- * contiguous blocks. Return the offset for the first block if that
- * verifies, or zero otherwise.
+ * contiguous blocks. Return the offset for the first block and number of
+ * valid blocks for which that is true, or zero otherwise.
  */
-static u32 cramfs_get_block_range(struct inode *inode, u32 pgoff, u32 pages)
+static u32 cramfs_get_block_range(struct inode *inode, u32 pgoff, u32 *pages)
 {
struct super_block *sb = inode->i_sb;
struct cramfs_sb_info *sbi = CRAMFS_SB(sb);
@@ -306,11 +306,16 @@ static u32 cramfs_get_block_range(struct inode *inode, 
u32 pgoff, u32 pages)
do {
u32 expect = blockaddr + i * (PAGE_SIZE >> 2);
expect |= 
CRAMFS_BLK_FLAG_DIRECT_PTR|CRAMFS_BLK_FLAG_UNCOMPRESSED;
-   pr_debug("range: block %d/%d got %#x expects %#x\n",
-pgoff+i, pgoff+pages-1, blockptrs[i], expect);
-   if (blockptrs[i] != expect)
-   return 0;
-   } while (++i < pages);
+   if (blockptrs[i] != expect) {
+   pr_debug("range: block %d/%d got %#x expects %#x\n",
+pgoff+i, pgoff+*pages-1, blockptrs[i], expect);
+   if (i == 0)
+   return 0;
+   break;
+   }
+   } while (++i < *pages);
+
+   *pages = i;
 
/* stored "direct" block ptrs are shifted down by 2 bits */
return blockaddr << 2;
@@ -321,8 +326,8 @@ static int cramfs_physmem_mmap(struct file *file, struct 
vm_area_struct *vma)
struct inode *inode = file_inode(file);
struct super_block *sb = inode->i_sb;
struct cramfs_sb_info *sbi = CRAMFS_SB(sb);
-   unsigned int pages, max_pages, offset;
-   unsigned long length, address;
+   unsigned int pages, vma_pages, max_pages, offset;
+   unsigned long address;
char *fail_reason;
int ret;
 
@@ -332,17 +337,20 @@ static int cramfs_physmem_mmap(struct file *file, struct 
vm_area_struct *vma)
if ((vma->vm_flags & VM_SHARED) && (vma->vm_flags & VM_MAYWRITE))
return -EINVAL;
 
-   vma->vm_ops = _file_vm_ops;
+   fail_reason = "vma is writable";
if (vma->vm_flags & VM_WRITE)
-   return 0;
+   goto fail;
 
-   length = vma->vm_end - vma->vm_start;
-   pages = (length + PAGE_SIZE - 1) >> PAGE_SHIFT;
+   vma_pages = (vma->vm_end - vma->vm_start + PAGE_SIZE - 1) >> PAGE_SHIFT;
max_pages = (inode->i_size + PAGE_SIZE - 1) >> PAGE_SHIFT;
-   if (vma->vm_pgoff >= max_pages || pages > max_pages - vma->vm_pgoff)
-   return -EINVAL;
+   fail_reason = "beyond file limit";
+   if (vma->vm_pgoff >= max_pages)
+   goto fail;
+   pages = vma_pages;
+   if (pages > max_pages - vma->vm_pgoff)
+   pages = max_pages - vma->vm_pgoff;
 
-   offset = cramfs_get_block_range(inode, vma->vm_pgoff, pages);
+   offset = cramfs_get_block_range(inode, 

Re: [linux-sunxi] [PATCH v6] arm64: allwinner: a64: Add initial NanoPi A64 support

[Chen-Yu Tsai]

On Tue, Aug 15, 2017 at 11:51 AM, Jagan Teki  wrote:
> On Tue, Aug 15, 2017 at 9:14 AM, Chen-Yu Tsai  wrote:
>> On Mon, Aug 14, 2017 at 6:36 PM, Jagan Teki  wrote:

[...]

>>> +/* i2c1 connected with gpio headers like pine64, bananapi */
>>> + {
>>> +   pinctrl-names = "default";
>>> +   pinctrl-0 = <_pins>;
>>> +   status = "okay";
>>
>> So I rechecked some of the current dts files we have. We typically
>> don't enable peripherals by default if they are on some generic
>> expansion header. We do however allow listing them with an explicit
>>
>> status = "disabled";
>>
>> Users are free to enable it themselves. The listing lets them enable
>> it from U-boot with a single fdt command.

[...]

>>> +_dldo1 {
>>> +   regulator-always-on;
>>> +   regulator-min-microvolt = <330>;
>>> +   regulator-max-microvolt = <330>;
>>> +   /* Same used for vcc-dsi */
>>> +   regulator-name = "vcc-hdmi";
>>
>> We normally just tack on all the consumers to the name, so
>> "vcc-hdmi-dsi" in this case.
>>
>>> +};
>>> +
>>> +_dldo4 {
>>> +   regulator-always-on;
>>> +   regulator-min-microvolt = <300>;
>>> +   regulator-max-microvolt = <300>;
>>> +   /* Same used for vdd_wifi-io */
>>> +   regulator-name = "vcc-pg";
>>
>> And "vcc-pg-wifi-io" here.
>>
>> I can fix up these bits when applying, if you are OK with the changes.
>
> OK, please make necessary changes.
>
> thanks!

Done. Please check the results of both your patches here:

https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/log/?h=sunxi/dt64-for-4.14

ChenYu

Re: [PATCH v2] f2fs: introduce cur_reserved_blocks in sysfs

[Yunlong Song]

ping...

On 2017/8/11 19:43, Yunlong Song wrote:

In this patch, we add a new sysfs interface, we can use it to gradually achieve
the reserved_blocks finally, even when reserved_blocks is initially set over
user_block_count - total_valid_block_count. This is very useful, especially when
we upgrade kernel with new reserved_blocks value, but old disk image unluckily 
has
user_block_count - total_valid_block_count smaller than the desired 
reserved_blocks.
With this patch, f2fs can try its best to reserve space and get close to the
reserved_blocks, and the current value of achieved reserved_blocks can be shown
in real time.

To ensure there is enough space for supporting system's activation, we safely
increase cur_reserved_blocks in dev_valid_block(,node)_count to only take up the
blocks which are just obsoleted.

Signed-off-by: Yunlong Song 
---
  Documentation/ABI/testing/sysfs-fs-f2fs |  6 ++
  fs/f2fs/f2fs.h  |  9 +++--
  fs/f2fs/super.c |  3 ++-
  fs/f2fs/sysfs.c | 15 ++-
  4 files changed, 25 insertions(+), 8 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs 
b/Documentation/ABI/testing/sysfs-fs-f2fs
index 11b7f4e..bdbb9f3 100644
--- a/Documentation/ABI/testing/sysfs-fs-f2fs
+++ b/Documentation/ABI/testing/sysfs-fs-f2fs
@@ -151,3 +151,9 @@ Date:   August 2017
  Contact:  "Jaegeuk Kim" 
  Description:
 Controls sleep time of GC urgent mode
+
+What:  /sys/fs/f2fs//cur_reserved_blocks
+Date:  August 2017
+Contact:   "Yunlong Song" 
+Description:
+Shows current reserved blocks in system.
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 2f20b6b..62d7343 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1041,6 +1041,7 @@ struct f2fs_sb_info {
block_t discard_blks;   /* discard command candidats */
block_t last_valid_block_count; /* for recovery */
block_t reserved_blocks;/* configurable reserved blocks 
*/
+   block_t cur_reserved_blocks;/* current reserved blocks */
  
  	u32 s_next_generation;			/* for NFS support */
  
@@ -1515,7 +1516,7 @@ static inline int inc_valid_block_count(struct f2fs_sb_info *sbi,
  
  	spin_lock(>stat_lock);

sbi->total_valid_block_count += (block_t)(*count);
-   avail_user_block_count = sbi->user_block_count - sbi->reserved_blocks;
+   avail_user_block_count = sbi->user_block_count - 
sbi->cur_reserved_blocks;
if (unlikely(sbi->total_valid_block_count > avail_user_block_count)) {
diff = sbi->total_valid_block_count - avail_user_block_count;
*count -= diff;
@@ -1549,6 +1550,8 @@ static inline void dec_valid_block_count(struct 
f2fs_sb_info *sbi,
f2fs_bug_on(sbi, sbi->total_valid_block_count < (block_t) count);
f2fs_bug_on(sbi, inode->i_blocks < sectors);
sbi->total_valid_block_count -= (block_t)count;
+   sbi->cur_reserved_blocks = min(sbi->reserved_blocks,
+   
sbi->cur_reserved_blocks + count);
spin_unlock(>stat_lock);
f2fs_i_blocks_write(inode, count, false, true);
  }
@@ -1695,7 +1698,7 @@ static inline int inc_valid_node_count(struct 
f2fs_sb_info *sbi,
spin_lock(>stat_lock);
  
  	valid_block_count = sbi->total_valid_block_count + 1;

-   if (unlikely(valid_block_count + sbi->reserved_blocks >
+   if (unlikely(valid_block_count + sbi->cur_reserved_blocks >
sbi->user_block_count)) {
spin_unlock(>stat_lock);
goto enospc;
@@ -1738,6 +1741,8 @@ static inline void dec_valid_node_count(struct 
f2fs_sb_info *sbi,
  
  	sbi->total_valid_node_count--;

sbi->total_valid_block_count--;
+   sbi->cur_reserved_blocks = min(sbi->reserved_blocks,
+   
sbi->cur_reserved_blocks + 1);
  
  	spin_unlock(>stat_lock);
  
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c

index 4c1bdcb..16a805f 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -957,7 +957,7 @@ static int f2fs_statfs(struct dentry *dentry, struct 
kstatfs *buf)
buf->f_blocks = total_count - start_count;
buf->f_bfree = user_block_count - valid_user_blocks(sbi) + ovp_count;
buf->f_bavail = user_block_count - valid_user_blocks(sbi) -
-   sbi->reserved_blocks;
+   sbi->cur_reserved_blocks;
  
  	avail_node_count = sbi->total_node_count - F2FS_RESERVED_NODE_NUM;
  
@@ -2411,6 +2411,7 @@ static int f2fs_fill_super(struct super_block *sb, void *data, int silent)

le64_to_cpu(sbi->ckpt->valid_block_count);
sbi->last_valid_block_count = sbi->total_valid_block_count;
sbi->reserved_blocks 

Re: [PATCH v3] arm64: allwinner: a64: Add A64-OLinuXino initial support

[Chen-Yu Tsai]

On Mon, Aug 14, 2017 at 6:46 PM, Jagan Teki  wrote:
> From: Jagan Teki 
>
> OLimex A64-OLinuXino is an open-source hardware board
> using the Allwinner A64 SOC.
>
> OLimex A64-OLinuXino has
> - A64 Quad-core Cortex-A53 64bit
> - 1GB or 2GB RAM DDR3L @ 672Mhz
> - microSD slot and 4/8/16GB eMMC
> - Debug TTL UART
> - HDMI
> - LCD
> - IR receiver
> - 5V DC power supply
>
> Signed-off-by: Jagan Teki 
> ---
> Changes for v3:
> - Droped i2c1, not found on schmatic
> - Updated vddfb-cpux regulator volt range 1.04 ~ 1.3 V
> - Removed poly-phased DCDC3 regulator node and added comment
> - Update DLDO4 regulator name as vcc-wifi-io
> - Moved uart0 below regulators
> Changes for v2:
> - Tested on board
> - Added AXP803 regulator
>
>  arch/arm64/boot/dts/allwinner/Makefile |   1 +
>  .../boot/dts/allwinner/sun50i-a64-olinuxino.dts| 199 
> +
>  2 files changed, 200 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
> b/arch/arm64/boot/dts/allwinner/Makefile
> index c997b5c..19c3fbd 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -1,5 +1,6 @@
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-bananapi-m64.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-nanopi-a64.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-olinuxino.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts 
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
> new file mode 100644
> index 000..b86ac1a
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
> @@ -0,0 +1,199 @@
> +/*
> + * Copyright (C) 2017 Jagan Teki 
> + *
> + * 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 library 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 library 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 "sun50i-a64.dtsi"
> +
> +#include 
> +
> +/ {
> +   model = "Olimex A64-Olinuxino";
> +   compatible = "olimex,a64-olinuxino", "allwinner,sun50i-a64";
> +
> +   aliases {
> +   serial0 = 
> +   };
> +
> +   chosen {
> +   stdout-path = "serial0:115200n8";
> +   };
> +};
> +
> + {
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_pins>;
> +   vmmc-supply = <_dcdc1>;
> +   cd-gpios = < 5 6 GPIO_ACTIVE_HIGH>;
> +   cd-inverted;
> +   disable-wp;
> +   bus-width = <4>;
> +   status = "okay";
> +};
> +
> +_rsb {
> +   status = "okay";
> +
> +   axp803: pmic@3a3 {
> +   compatible = "x-powers,axp803";
> +   reg = <0x3a3>;
> +   interrupt-parent = <_intc>;
> +   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> +   };
> +};
> +
> +#include 

Re: [PATCH v3] arm64: allwinner: a64: Add A64-OLinuXino initial support

[Chen-Yu Tsai]

On Mon, Aug 14, 2017 at 6:46 PM, Jagan Teki  wrote:
> From: Jagan Teki 
>
> OLimex A64-OLinuXino is an open-source hardware board
> using the Allwinner A64 SOC.
>
> OLimex A64-OLinuXino has
> - A64 Quad-core Cortex-A53 64bit
> - 1GB or 2GB RAM DDR3L @ 672Mhz
> - microSD slot and 4/8/16GB eMMC
> - Debug TTL UART
> - HDMI
> - LCD
> - IR receiver
> - 5V DC power supply
>
> Signed-off-by: Jagan Teki 
> ---
> Changes for v3:
> - Droped i2c1, not found on schmatic
> - Updated vddfb-cpux regulator volt range 1.04 ~ 1.3 V
> - Removed poly-phased DCDC3 regulator node and added comment
> - Update DLDO4 regulator name as vcc-wifi-io
> - Moved uart0 below regulators
> Changes for v2:
> - Tested on board
> - Added AXP803 regulator
>
>  arch/arm64/boot/dts/allwinner/Makefile |   1 +
>  .../boot/dts/allwinner/sun50i-a64-olinuxino.dts| 199 
> +
>  2 files changed, 200 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
> b/arch/arm64/boot/dts/allwinner/Makefile
> index c997b5c..19c3fbd 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -1,5 +1,6 @@
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-bananapi-m64.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-nanopi-a64.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-olinuxino.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts 
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
> new file mode 100644
> index 000..b86ac1a
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
> @@ -0,0 +1,199 @@
> +/*
> + * Copyright (C) 2017 Jagan Teki 
> + *
> + * 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 library 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 library 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 "sun50i-a64.dtsi"
> +
> +#include 
> +
> +/ {
> +   model = "Olimex A64-Olinuxino";
> +   compatible = "olimex,a64-olinuxino", "allwinner,sun50i-a64";
> +
> +   aliases {
> +   serial0 = 
> +   };
> +
> +   chosen {
> +   stdout-path = "serial0:115200n8";
> +   };
> +};
> +
> + {
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_pins>;
> +   vmmc-supply = <_dcdc1>;
> +   cd-gpios = < 5 6 GPIO_ACTIVE_HIGH>;
> +   cd-inverted;
> +   disable-wp;
> +   bus-width = <4>;
> +   status = "okay";
> +};
> +
> +_rsb {
> +   status = "okay";
> +
> +   axp803: pmic@3a3 {
> +   compatible = "x-powers,axp803";
> +   reg = <0x3a3>;
> +   interrupt-parent = <_intc>;
> +   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> +   };
> +};
> +
> +#include "axp803.dtsi"
> +
> +_aldo1 {
> +   regulator-always-on;
> +   regulator-min-microvolt = 

Re: [linux-sunxi] [PATCH v6] arm64: allwinner: a64: Add initial NanoPi A64 support

[Jagan Teki]

On Tue, Aug 15, 2017 at 9:14 AM, Chen-Yu Tsai  wrote:
> On Mon, Aug 14, 2017 at 6:36 PM, Jagan Teki  wrote:
>> From: Jagan Teki 
>>
>> NanoPi A64 is a new board of high performance with low cost
>> designed by FriendlyElec., using the Allwinner A64 SOC.
>>
>> Nanopi A64 features
>> - Allwinner A64, 64-bit Quad-core Cortex-A53@648MHz to 1.152GHz, DVFS
>> - 1GB DDR3 RAM
>> - MicroSD
>> - Gigabit Ethernet (RTL8211E)
>> - Wi-Fi 802.11b/g/n
>> - IR receiver
>> - Audio In/Out
>> - Video In/Out
>> - Serial Debug Port
>> - microUSB 5V 2A DC power-supply
>>
>> Signed-off-by: Jagan Teki 
>> ---
>> Changes for v6:
>> - Moved uart0 below regulators
>> - Add comment for i2c1
>> - Update vdd-cpux volt range 1.04 ~ 1.3 V
>> - ehci0 detection https://paste.ubuntu.com/25311593/
>
> Thanks. This confirms the hardware default is OK for host-only
> usage.
>
>> - Remove space before usbphy
>> - Removed unused DLD02
>> - Add comment for DLD01 regulator-name to vcc-dsi since
>>   it's connected along with vcc-hdmi
>> - Add regulator node for DLD04 for vcc-pg
>> Changes for v5:
>> - Add AXP803 PMIC regulator support.
>> Changes for v4:
>> - Rebased and droped wi-fi related nodes, since it require
>>   other changes to taken care.
>> Changes for v3:
>> - Fix to use mmc1 for SDIO instead of mmc2
>> - Replace buswidth by 4 instead of 8 mmc1
>> - Drop cap-mmc-hw-reset for mmc1
>> Changes for v2:
>> - Added ohci0, ehci0, ohic1, ehci1, usbphy.
>> - Tested on A64
>>
>>  arch/arm64/boot/dts/allwinner/Makefile |   1 +
>>  .../boot/dts/allwinner/sun50i-a64-nanopi-a64.dts   | 209 
>> +
>>  2 files changed, 210 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
>> b/arch/arm64/boot/dts/allwinner/Makefile
>> index 108f12c..c997b5c 100644
>> --- a/arch/arm64/boot/dts/allwinner/Makefile
>> +++ b/arch/arm64/boot/dts/allwinner/Makefile
>> @@ -1,4 +1,5 @@
>>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-bananapi-m64.dtb
>> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-nanopi-a64.dtb
>>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
>>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
>>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts 
>> b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>> new file mode 100644
>> index 000..c2bbc75
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>> @@ -0,0 +1,209 @@
>> +/*
>> + * Copyright (C) 2017 Jagan Teki 
>> + *
>> + * 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 library 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 library 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 "sun50i-a64.dtsi"
>> +
>> +#include 
>> +
>> +/ {
>> +   model = "FriendlyARM NanoPi A64";
>> +   

Re: [linux-sunxi] [PATCH v6] arm64: allwinner: a64: Add initial NanoPi A64 support

[Jagan Teki]

On Tue, Aug 15, 2017 at 9:14 AM, Chen-Yu Tsai  wrote:
> On Mon, Aug 14, 2017 at 6:36 PM, Jagan Teki  wrote:
>> From: Jagan Teki 
>>
>> NanoPi A64 is a new board of high performance with low cost
>> designed by FriendlyElec., using the Allwinner A64 SOC.
>>
>> Nanopi A64 features
>> - Allwinner A64, 64-bit Quad-core Cortex-A53@648MHz to 1.152GHz, DVFS
>> - 1GB DDR3 RAM
>> - MicroSD
>> - Gigabit Ethernet (RTL8211E)
>> - Wi-Fi 802.11b/g/n
>> - IR receiver
>> - Audio In/Out
>> - Video In/Out
>> - Serial Debug Port
>> - microUSB 5V 2A DC power-supply
>>
>> Signed-off-by: Jagan Teki 
>> ---
>> Changes for v6:
>> - Moved uart0 below regulators
>> - Add comment for i2c1
>> - Update vdd-cpux volt range 1.04 ~ 1.3 V
>> - ehci0 detection https://paste.ubuntu.com/25311593/
>
> Thanks. This confirms the hardware default is OK for host-only
> usage.
>
>> - Remove space before usbphy
>> - Removed unused DLD02
>> - Add comment for DLD01 regulator-name to vcc-dsi since
>>   it's connected along with vcc-hdmi
>> - Add regulator node for DLD04 for vcc-pg
>> Changes for v5:
>> - Add AXP803 PMIC regulator support.
>> Changes for v4:
>> - Rebased and droped wi-fi related nodes, since it require
>>   other changes to taken care.
>> Changes for v3:
>> - Fix to use mmc1 for SDIO instead of mmc2
>> - Replace buswidth by 4 instead of 8 mmc1
>> - Drop cap-mmc-hw-reset for mmc1
>> Changes for v2:
>> - Added ohci0, ehci0, ohic1, ehci1, usbphy.
>> - Tested on A64
>>
>>  arch/arm64/boot/dts/allwinner/Makefile |   1 +
>>  .../boot/dts/allwinner/sun50i-a64-nanopi-a64.dts   | 209 
>> +
>>  2 files changed, 210 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
>> b/arch/arm64/boot/dts/allwinner/Makefile
>> index 108f12c..c997b5c 100644
>> --- a/arch/arm64/boot/dts/allwinner/Makefile
>> +++ b/arch/arm64/boot/dts/allwinner/Makefile
>> @@ -1,4 +1,5 @@
>>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-bananapi-m64.dtb
>> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-nanopi-a64.dtb
>>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
>>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
>>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts 
>> b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>> new file mode 100644
>> index 000..c2bbc75
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>> @@ -0,0 +1,209 @@
>> +/*
>> + * Copyright (C) 2017 Jagan Teki 
>> + *
>> + * 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 library 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 library 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 "sun50i-a64.dtsi"
>> +
>> +#include 
>> +
>> +/ {
>> +   model = "FriendlyARM NanoPi A64";
>> +   compatible = "friendlyarm,nanopi-a64", "allwinner,sun50i-a64";
>> +
>> +   aliases {
>> +   serial0 = 
>> +

Re: [PATCH v5 02/10] mm, x86: Add support for eXclusive Page Frame Ownership (XPFO)

[Tycho Andersen]

On Mon, Aug 14, 2017 at 09:47:18PM -0600, Tycho Andersen wrote:
> I'll do that for the next version

Actually looking closer, I think we just need to mirror the
debug_pagealloc_enabled() checks in set_kpte() from
split_large_page(),

diff --git a/arch/x86/mm/xpfo.c b/arch/x86/mm/xpfo.c
index a1344f27406c..c962bd7f34cc 100644
--- a/arch/x86/mm/xpfo.c
+++ b/arch/x86/mm/xpfo.c
@@ -54,9 +54,11 @@ inline void set_kpte(void *kaddr, struct page *page, 
pgprot_t prot)
 
do_split = try_preserve_large_page(pte, (unsigned long)kaddr, 
);
if (do_split) {
-   spin_lock(_lock);
+   if (!debug_pagealloc_enabled())
+   spin_lock(_lock);
BUG_ON(split_large_page(, pte, (unsigned 
long)kaddr));
-   spin_unlock(_lock);
+   if (!debug_pagealloc_enabled())
+   spin_unlock(_lock);
}
 
break;


Tycho

Re: [PATCH v5 02/10] mm, x86: Add support for eXclusive Page Frame Ownership (XPFO)

[Tycho Andersen]

On Mon, Aug 14, 2017 at 09:47:18PM -0600, Tycho Andersen wrote:
> I'll do that for the next version

Actually looking closer, I think we just need to mirror the
debug_pagealloc_enabled() checks in set_kpte() from
split_large_page(),

diff --git a/arch/x86/mm/xpfo.c b/arch/x86/mm/xpfo.c
index a1344f27406c..c962bd7f34cc 100644
--- a/arch/x86/mm/xpfo.c
+++ b/arch/x86/mm/xpfo.c
@@ -54,9 +54,11 @@ inline void set_kpte(void *kaddr, struct page *page, 
pgprot_t prot)
 
do_split = try_preserve_large_page(pte, (unsigned long)kaddr, 
);
if (do_split) {
-   spin_lock(_lock);
+   if (!debug_pagealloc_enabled())
+   spin_lock(_lock);
BUG_ON(split_large_page(, pte, (unsigned 
long)kaddr));
-   spin_unlock(_lock);
+   if (!debug_pagealloc_enabled())
+   spin_unlock(_lock);
}
 
break;


Tycho

[PATCH v5 2/3] ARM: dts: Add LVDS info for rk3288

[Sandy Huang]

add LVDS info in rk3288.dtsi for LVDS driver
This based on the patches from Mark yao and Heiko Stuebner.

Signed-off-by: Sandy Huang 
Signed-off-by: Mark yao 
Signed-off-by: Heiko Stuebner 
---
 arch/arm/boot/dts/rk3288.dtsi | 52 +++
 1 file changed, 52 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 2484f11..c2e33b8 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -983,6 +983,11 @@
reg = <2>;
remote-endpoint = <_in_vopb>;
};
+
+   vopb_out_lvds: endpoint@3 {
+   reg = <3>;
+   remote-endpoint = <_in_vopb>;
+   };
};
};
 
@@ -1026,6 +1031,11 @@
reg = <2>;
remote-endpoint = <_in_vopl>;
};
+
+   vopl_out_lvds: endpoint@3 {
+   reg = <3>;
+   remote-endpoint = <_in_vopl>;
+   };
};
};
 
@@ -1099,6 +1109,39 @@
};
};
 
+   lvds: lvds@ff96c000 {
+   compatible = "rockchip,rk3288-lvds";
+   reg = <0xff96c000 0x4000>;
+   clocks = < PCLK_LVDS_PHY>;
+   clock-names = "pclk_lvds";
+   pinctrl-names = "lcdc";
+   pinctrl-0 = <_ctl>;
+   power-domains = < RK3288_PD_VIO>;
+   rockchip,grf = <>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   lvds_in: port@0 {
+   reg = <0>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   lvds_in_vopb: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_out_lvds>;
+   };
+   lvds_in_vopl: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <_out_lvds>;
+   };
+   };
+   };
+   };
+
hdmi: hdmi@ff98 {
compatible = "rockchip,rk3288-dw-hdmi";
reg = <0xff98 0x2>;
@@ -1823,5 +1866,14 @@
rockchip,pins = ;
};
};
+
+   lcdc {
+   lcdc_ctl: lcdc-ctl {
+   rockchip,pins = <1 24 RK_FUNC_1 
_pull_none>,
+   <1 25 RK_FUNC_1 
_pull_none>,
+   <1 26 RK_FUNC_1 
_pull_none>,
+   <1 27 RK_FUNC_1 
_pull_none>;
+   };
+   };
};
 };
-- 
2.7.4

[PATCH v5 2/3] ARM: dts: Add LVDS info for rk3288

[Sandy Huang]

add LVDS info in rk3288.dtsi for LVDS driver
This based on the patches from Mark yao and Heiko Stuebner.

Signed-off-by: Sandy Huang 
Signed-off-by: Mark yao 
Signed-off-by: Heiko Stuebner 
---
 arch/arm/boot/dts/rk3288.dtsi | 52 +++
 1 file changed, 52 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 2484f11..c2e33b8 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -983,6 +983,11 @@
reg = <2>;
remote-endpoint = <_in_vopb>;
};
+
+   vopb_out_lvds: endpoint@3 {
+   reg = <3>;
+   remote-endpoint = <_in_vopb>;
+   };
};
};
 
@@ -1026,6 +1031,11 @@
reg = <2>;
remote-endpoint = <_in_vopl>;
};
+
+   vopl_out_lvds: endpoint@3 {
+   reg = <3>;
+   remote-endpoint = <_in_vopl>;
+   };
};
};
 
@@ -1099,6 +1109,39 @@
};
};
 
+   lvds: lvds@ff96c000 {
+   compatible = "rockchip,rk3288-lvds";
+   reg = <0xff96c000 0x4000>;
+   clocks = < PCLK_LVDS_PHY>;
+   clock-names = "pclk_lvds";
+   pinctrl-names = "lcdc";
+   pinctrl-0 = <_ctl>;
+   power-domains = < RK3288_PD_VIO>;
+   rockchip,grf = <>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   lvds_in: port@0 {
+   reg = <0>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   lvds_in_vopb: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_out_lvds>;
+   };
+   lvds_in_vopl: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <_out_lvds>;
+   };
+   };
+   };
+   };
+
hdmi: hdmi@ff98 {
compatible = "rockchip,rk3288-dw-hdmi";
reg = <0xff98 0x2>;
@@ -1823,5 +1866,14 @@
rockchip,pins = ;
};
};
+
+   lcdc {
+   lcdc_ctl: lcdc-ctl {
+   rockchip,pins = <1 24 RK_FUNC_1 
_pull_none>,
+   <1 25 RK_FUNC_1 
_pull_none>,
+   <1 26 RK_FUNC_1 
_pull_none>,
+   <1 27 RK_FUNC_1 
_pull_none>;
+   };
+   };
};
 };
-- 
2.7.4

Re: [PATCH v4 3/3] drm/rockchip: Add support for Rockchip Soc LVDS

[Sandy Huang]

Hi mark,
Thanks for you review.

在 2017/8/15 9:53, Mark yao 写道:

Hi Sandy

On 2017年08月15日 08:56, Sandy Huang wrote:

This adds support for Rockchip soc lvds found on rk3288
Based on the patches from Mark yao and Heiko Stuebner

Signed-off-by: Sandy Huang 
Signed-off-by: Mark yao 
Signed-off-by: Heiko Stuebner 
---
  drivers/gpu/drm/rockchip/Kconfig|   9 +
  drivers/gpu/drm/rockchip/Makefile   |   1 +
  drivers/gpu/drm/rockchip/rockchip_drm_drv.c |   2 +
  drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   1 +
  drivers/gpu/drm/rockchip/rockchip_lvds.c| 652 


  drivers/gpu/drm/rockchip/rockchip_lvds.h| 109 +
  6 files changed, 774 insertions(+)
  create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.c
  create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.h

diff --git a/drivers/gpu/drm/rockchip/Kconfig 
b/drivers/gpu/drm/rockchip/Kconfig

index 50c41c0..80672f4 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -59,3 +59,12 @@ config ROCKCHIP_INNO_HDMI
This selects support for Rockchip SoC specific extensions
for the Innosilicon HDMI driver. If you want to enable
HDMI on RK3036 based SoC, you should select this option.
+
+config ROCKCHIP_LVDS
+bool "Rockchip LVDS support"
+depends on DRM_ROCKCHIP
+help
+  Choose this option to enable support for Rockchip LVDS 
controllers.

+  Rockchip rk3288 SoC has LVDS TX Controller can be used, and it
+  support LVDS, rgb, dual LVDS output mode. say Y to enable its
+  driver.
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile

index fa8dc9d..a881d2c 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -12,5 +12,6 @@ rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += 
cdn-dp-core.o cdn-dp-reg.o

  rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
  rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
  rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
+rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o
  obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c

index c41f48a..082c251 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -445,6 +445,8 @@ static int __init rockchip_drm_init(void)
  num_rockchip_sub_drivers = 0;
  ADD_ROCKCHIP_SUB_DRIVER(vop_platform_driver, CONFIG_DRM_ROCKCHIP);
+ADD_ROCKCHIP_SUB_DRIVER(rockchip_lvds_driver,
+CONFIG_ROCKCHIP_LVDS);
  ADD_ROCKCHIP_SUB_DRIVER(rockchip_dp_driver,
  CONFIG_ROCKCHIP_ANALOGIX_DP);
  ADD_ROCKCHIP_SUB_DRIVER(cdn_dp_driver, CONFIG_ROCKCHIP_CDN_DP);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h

index c7e96b8..498dfbc 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -69,5 +69,6 @@ extern struct platform_driver 
dw_hdmi_rockchip_pltfm_driver;

  extern struct platform_driver dw_mipi_dsi_driver;
  extern struct platform_driver inno_hdmi_driver;
  extern struct platform_driver rockchip_dp_driver;
+extern struct platform_driver rockchip_lvds_driver;
  extern struct platform_driver vop_platform_driver;
  #endif /* _ROCKCHIP_DRM_DRV_H_ */
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c 
b/drivers/gpu/drm/rockchip/rockchip_lvds.c

new file mode 100644
index 000..532f2b6
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -0,0 +1,652 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author:
+ *  Mark Yao 
+ *  Sandy huang 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../drm_crtc_internal.h"
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+#include "rockchip_lvds.h"
+
+#define DISPLAY_OUTPUT_RGB0
+#define DISPLAY_OUTPUT_LVDS1
+#define DISPLAY_OUTPUT_DUAL_LVDS2
+
+#define connector_to_lvds(c) \
+container_of(c, struct rockchip_lvds, connector)
+
+#define encoder_to_lvds(c) \
+container_of(c, struct rockchip_lvds, encoder)
+
+/**
+ * rockchip_lvds_soc_data - rockchip lvds Soc private data
+ * 

Re: [PATCH v4 3/3] drm/rockchip: Add support for Rockchip Soc LVDS

[Sandy Huang]

Hi mark,
Thanks for you review.

在 2017/8/15 9:53, Mark yao 写道:

Hi Sandy

On 2017年08月15日 08:56, Sandy Huang wrote:

This adds support for Rockchip soc lvds found on rk3288
Based on the patches from Mark yao and Heiko Stuebner

Signed-off-by: Sandy Huang 
Signed-off-by: Mark yao 
Signed-off-by: Heiko Stuebner 
---
  drivers/gpu/drm/rockchip/Kconfig|   9 +
  drivers/gpu/drm/rockchip/Makefile   |   1 +
  drivers/gpu/drm/rockchip/rockchip_drm_drv.c |   2 +
  drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   1 +
  drivers/gpu/drm/rockchip/rockchip_lvds.c| 652 


  drivers/gpu/drm/rockchip/rockchip_lvds.h| 109 +
  6 files changed, 774 insertions(+)
  create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.c
  create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.h

diff --git a/drivers/gpu/drm/rockchip/Kconfig 
b/drivers/gpu/drm/rockchip/Kconfig

index 50c41c0..80672f4 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -59,3 +59,12 @@ config ROCKCHIP_INNO_HDMI
This selects support for Rockchip SoC specific extensions
for the Innosilicon HDMI driver. If you want to enable
HDMI on RK3036 based SoC, you should select this option.
+
+config ROCKCHIP_LVDS
+bool "Rockchip LVDS support"
+depends on DRM_ROCKCHIP
+help
+  Choose this option to enable support for Rockchip LVDS 
controllers.

+  Rockchip rk3288 SoC has LVDS TX Controller can be used, and it
+  support LVDS, rgb, dual LVDS output mode. say Y to enable its
+  driver.
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile

index fa8dc9d..a881d2c 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -12,5 +12,6 @@ rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += 
cdn-dp-core.o cdn-dp-reg.o

  rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
  rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
  rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
+rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o
  obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c

index c41f48a..082c251 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -445,6 +445,8 @@ static int __init rockchip_drm_init(void)
  num_rockchip_sub_drivers = 0;
  ADD_ROCKCHIP_SUB_DRIVER(vop_platform_driver, CONFIG_DRM_ROCKCHIP);
+ADD_ROCKCHIP_SUB_DRIVER(rockchip_lvds_driver,
+CONFIG_ROCKCHIP_LVDS);
  ADD_ROCKCHIP_SUB_DRIVER(rockchip_dp_driver,
  CONFIG_ROCKCHIP_ANALOGIX_DP);
  ADD_ROCKCHIP_SUB_DRIVER(cdn_dp_driver, CONFIG_ROCKCHIP_CDN_DP);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h

index c7e96b8..498dfbc 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -69,5 +69,6 @@ extern struct platform_driver 
dw_hdmi_rockchip_pltfm_driver;

  extern struct platform_driver dw_mipi_dsi_driver;
  extern struct platform_driver inno_hdmi_driver;
  extern struct platform_driver rockchip_dp_driver;
+extern struct platform_driver rockchip_lvds_driver;
  extern struct platform_driver vop_platform_driver;
  #endif /* _ROCKCHIP_DRM_DRV_H_ */
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c 
b/drivers/gpu/drm/rockchip/rockchip_lvds.c

new file mode 100644
index 000..532f2b6
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -0,0 +1,652 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author:
+ *  Mark Yao 
+ *  Sandy huang 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../drm_crtc_internal.h"
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+#include "rockchip_lvds.h"
+
+#define DISPLAY_OUTPUT_RGB0
+#define DISPLAY_OUTPUT_LVDS1
+#define DISPLAY_OUTPUT_DUAL_LVDS2
+
+#define connector_to_lvds(c) \
+container_of(c, struct rockchip_lvds, connector)
+
+#define encoder_to_lvds(c) \
+container_of(c, struct rockchip_lvds, encoder)
+
+/**
+ * rockchip_lvds_soc_data - rockchip lvds Soc private data
+ * @ch1_offset: lvds channel 1 registe offset
+ * grf_soc_con6: general registe offset for LVDS contrl
+ * 

[PATCH v5 1/3] dt-bindings: display: Add Document for Rockchip Soc LVDS

[Sandy Huang]

This patch add Document for Rockchip Soc RK3288 LVDS,
This based on the patches from Mark yao and Heiko Stuebner.

Signed-off-by: Sandy Huang 
Signed-off-by: Mark yao 
Signed-off-by: Heiko Stuebner 
---
Changes according to Mark Yao reviews.

 .../bindings/display/rockchip/rockchip-lvds.txt| 105 +
 1 file changed, 105 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt 
b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
new file mode 100644
index 000..c153411
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
@@ -0,0 +1,105 @@
+Rockchip RK3288 LVDS interface
+
+
+Required properties:
+- compatible: matching the soc type, one of
+   - "rockchip,rk3288-lvds";
+
+- reg: physical base address of the controller and length
+   of memory mapped region.
+- clocks: must include clock specifiers corresponding to entries in the
+   clock-names property.
+- clock-names: must contain "pclk_lvds"
+
+- avdd1v0-supply: regulator phandle for 1.0V analog power
+- avdd1v8-supply: regulator phandle for 1.8V analog power
+- avdd3v3-supply: regulator phandle for 3.3V analog power
+
+- rockchip,grf: phandle to the general register files syscon
+
+Optional properties:
+- pinctrl-names: must contain a "lcdc" entry.
+- pinctrl-0: pin control group to be used for this controller.
+
+Required nodes:
+
+The lvds has two video ports as described by
+   Documentation/devicetree/bindings/media/video-interfaces.txt.
+Their connections are modeled using the OF graph bindings specified in
+   Documentation/devicetree/bindings/graph.txt.
+
+- video port 0 for the VOP inputs
+- video port 1 for either a panel or subsequent encoder
+
+the lvds panel described by
+   Documentation/devicetree/bindings/display/panel/simple-panel.txt
+
+Panel required properties:
+- rockchip,data-width : should be <18> or <24>;
+- rockchip,output: should be "rgb", "lvds" or "duallvds",
+   This describes the output face.
+- ports for remote LVDS output
+
+Panel optional properties:
+- rockchip,data-mapping: should be "vesa" or "jeida",
+   This describes how the color bits are laid out in the
+   serialized LVDS signal.
+Example:
+
+lvds_panel: lvds-panel {
+   status = "okay";
+   compatible = "simple-panel";
+   enable-gpios = < 21 GPIO_ACTIVE_HIGH>;
+   rockchip,data-mapping = "jeida";
+   rockchip,data-width = <24>;
+   rockchip,output = "rgb";
+
+   ports {
+   panel_in_lvds: endpoint {
+   remote-endpoint = <_out_panel>;
+   };
+   };
+};
+
+For Rockchip RK3288:
+
+   lvds: lvds@ff96c000 {
+   compatible = "rockchip,rk3288-lvds";
+   rockchip,grf = <>;
+   reg = <0xff96c000 0x4000>;
+   clocks = < PCLK_LVDS_PHY>;
+   clock-names = "pclk_lvds";
+   pinctrl-names = "lcdc";
+   pinctrl-0 = <_ctl>;
+   avdd1v0-supply = <_lcd>;
+   avdd1v8-supply = <_lcd>;
+   avdd3v3-supply = <_33>;
+   rockchip,data-mapping = "jeida";
+   rockchip,data-width = <24>;
+   rockchip,output = "rgb";
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   lvds_in: port@0 {
+   reg = <0>;
+
+   lvds_in_vopb: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_out_lvds>;
+   };
+   lvds_in_vopl: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <_out_lvds>;
+   };
+   };
+
+   lvds_out: port@1 {
+   reg = <1>;
+
+   lvds_out_panel: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
-- 
2.7.4

[PATCH v5 1/3] dt-bindings: display: Add Document for Rockchip Soc LVDS

[Sandy Huang]

This patch add Document for Rockchip Soc RK3288 LVDS,
This based on the patches from Mark yao and Heiko Stuebner.

Signed-off-by: Sandy Huang 
Signed-off-by: Mark yao 
Signed-off-by: Heiko Stuebner 
---
Changes according to Mark Yao reviews.

 .../bindings/display/rockchip/rockchip-lvds.txt| 105 +
 1 file changed, 105 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt 
b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
new file mode 100644
index 000..c153411
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
@@ -0,0 +1,105 @@
+Rockchip RK3288 LVDS interface
+
+
+Required properties:
+- compatible: matching the soc type, one of
+   - "rockchip,rk3288-lvds";
+
+- reg: physical base address of the controller and length
+   of memory mapped region.
+- clocks: must include clock specifiers corresponding to entries in the
+   clock-names property.
+- clock-names: must contain "pclk_lvds"
+
+- avdd1v0-supply: regulator phandle for 1.0V analog power
+- avdd1v8-supply: regulator phandle for 1.8V analog power
+- avdd3v3-supply: regulator phandle for 3.3V analog power
+
+- rockchip,grf: phandle to the general register files syscon
+
+Optional properties:
+- pinctrl-names: must contain a "lcdc" entry.
+- pinctrl-0: pin control group to be used for this controller.
+
+Required nodes:
+
+The lvds has two video ports as described by
+   Documentation/devicetree/bindings/media/video-interfaces.txt.
+Their connections are modeled using the OF graph bindings specified in
+   Documentation/devicetree/bindings/graph.txt.
+
+- video port 0 for the VOP inputs
+- video port 1 for either a panel or subsequent encoder
+
+the lvds panel described by
+   Documentation/devicetree/bindings/display/panel/simple-panel.txt
+
+Panel required properties:
+- rockchip,data-width : should be <18> or <24>;
+- rockchip,output: should be "rgb", "lvds" or "duallvds",
+   This describes the output face.
+- ports for remote LVDS output
+
+Panel optional properties:
+- rockchip,data-mapping: should be "vesa" or "jeida",
+   This describes how the color bits are laid out in the
+   serialized LVDS signal.
+Example:
+
+lvds_panel: lvds-panel {
+   status = "okay";
+   compatible = "simple-panel";
+   enable-gpios = < 21 GPIO_ACTIVE_HIGH>;
+   rockchip,data-mapping = "jeida";
+   rockchip,data-width = <24>;
+   rockchip,output = "rgb";
+
+   ports {
+   panel_in_lvds: endpoint {
+   remote-endpoint = <_out_panel>;
+   };
+   };
+};
+
+For Rockchip RK3288:
+
+   lvds: lvds@ff96c000 {
+   compatible = "rockchip,rk3288-lvds";
+   rockchip,grf = <>;
+   reg = <0xff96c000 0x4000>;
+   clocks = < PCLK_LVDS_PHY>;
+   clock-names = "pclk_lvds";
+   pinctrl-names = "lcdc";
+   pinctrl-0 = <_ctl>;
+   avdd1v0-supply = <_lcd>;
+   avdd1v8-supply = <_lcd>;
+   avdd3v3-supply = <_33>;
+   rockchip,data-mapping = "jeida";
+   rockchip,data-width = <24>;
+   rockchip,output = "rgb";
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   lvds_in: port@0 {
+   reg = <0>;
+
+   lvds_in_vopb: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_out_lvds>;
+   };
+   lvds_in_vopl: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <_out_lvds>;
+   };
+   };
+
+   lvds_out: port@1 {
+   reg = <1>;
+
+   lvds_out_panel: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
-- 
2.7.4

[PATCH v5 3/3] drm/rockchip: Add support for Rockchip Soc LVDS

[Sandy Huang]

This adds support for Rockchip soc lvds found on rk3288
Based on the patches from Mark yao and Heiko Stuebner

Signed-off-by: Sandy Huang 
Signed-off-by: Mark Yao 
Signed-off-by: Heiko Stuebner 
---
 drivers/gpu/drm/rockchip/Kconfig|   9 +
 drivers/gpu/drm/rockchip/Makefile   |   1 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c |   2 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   1 +
 drivers/gpu/drm/rockchip/rockchip_lvds.c| 599 
 drivers/gpu/drm/rockchip/rockchip_lvds.h| 109 +
 6 files changed, 721 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.h

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 50c41c0..80672f4 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -59,3 +59,12 @@ config ROCKCHIP_INNO_HDMI
  This selects support for Rockchip SoC specific extensions
  for the Innosilicon HDMI driver. If you want to enable
  HDMI on RK3036 based SoC, you should select this option.
+
+config ROCKCHIP_LVDS
+   bool "Rockchip LVDS support"
+   depends on DRM_ROCKCHIP
+   help
+ Choose this option to enable support for Rockchip LVDS controllers.
+ Rockchip rk3288 SoC has LVDS TX Controller can be used, and it
+ support LVDS, rgb, dual LVDS output mode. say Y to enable its
+ driver.
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index fa8dc9d..a881d2c 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -12,5 +12,6 @@ rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o 
cdn-dp-reg.o
 rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
 rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
 rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
+rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o
 
 obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index c41f48a..082c251 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -445,6 +445,8 @@ static int __init rockchip_drm_init(void)
 
num_rockchip_sub_drivers = 0;
ADD_ROCKCHIP_SUB_DRIVER(vop_platform_driver, CONFIG_DRM_ROCKCHIP);
+   ADD_ROCKCHIP_SUB_DRIVER(rockchip_lvds_driver,
+   CONFIG_ROCKCHIP_LVDS);
ADD_ROCKCHIP_SUB_DRIVER(rockchip_dp_driver,
CONFIG_ROCKCHIP_ANALOGIX_DP);
ADD_ROCKCHIP_SUB_DRIVER(cdn_dp_driver, CONFIG_ROCKCHIP_CDN_DP);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index c7e96b8..498dfbc 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -69,5 +69,6 @@ extern struct platform_driver dw_hdmi_rockchip_pltfm_driver;
 extern struct platform_driver dw_mipi_dsi_driver;
 extern struct platform_driver inno_hdmi_driver;
 extern struct platform_driver rockchip_dp_driver;
+extern struct platform_driver rockchip_lvds_driver;
 extern struct platform_driver vop_platform_driver;
 #endif /* _ROCKCHIP_DRM_DRV_H_ */
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c 
b/drivers/gpu/drm/rockchip/rockchip_lvds.c
new file mode 100644
index 000..544415f
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -0,0 +1,599 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author:
+ *  Mark Yao 
+ *  Sandy Huang 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../drm_crtc_internal.h"
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+#include "rockchip_lvds.h"
+
+#define DISPLAY_OUTPUT_RGB 0
+#define DISPLAY_OUTPUT_LVDS1
+#define DISPLAY_OUTPUT_DUAL_LVDS   2
+
+#define connector_to_lvds(c) \
+   container_of(c, struct rockchip_lvds, connector)
+
+#define encoder_to_lvds(c) \
+   container_of(c, struct rockchip_lvds, encoder)
+
+/**
+ * rockchip_lvds_soc_data - rockchip lvds Soc private data
+ * @ch1_offset: lvds channel 1 registe offset
+ * 

[PATCH v5 3/3] drm/rockchip: Add support for Rockchip Soc LVDS

[Sandy Huang]

This adds support for Rockchip soc lvds found on rk3288
Based on the patches from Mark yao and Heiko Stuebner

Signed-off-by: Sandy Huang 
Signed-off-by: Mark Yao 
Signed-off-by: Heiko Stuebner 
---
 drivers/gpu/drm/rockchip/Kconfig|   9 +
 drivers/gpu/drm/rockchip/Makefile   |   1 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c |   2 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   1 +
 drivers/gpu/drm/rockchip/rockchip_lvds.c| 599 
 drivers/gpu/drm/rockchip/rockchip_lvds.h| 109 +
 6 files changed, 721 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.h

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 50c41c0..80672f4 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -59,3 +59,12 @@ config ROCKCHIP_INNO_HDMI
  This selects support for Rockchip SoC specific extensions
  for the Innosilicon HDMI driver. If you want to enable
  HDMI on RK3036 based SoC, you should select this option.
+
+config ROCKCHIP_LVDS
+   bool "Rockchip LVDS support"
+   depends on DRM_ROCKCHIP
+   help
+ Choose this option to enable support for Rockchip LVDS controllers.
+ Rockchip rk3288 SoC has LVDS TX Controller can be used, and it
+ support LVDS, rgb, dual LVDS output mode. say Y to enable its
+ driver.
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index fa8dc9d..a881d2c 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -12,5 +12,6 @@ rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o 
cdn-dp-reg.o
 rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
 rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
 rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
+rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o
 
 obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index c41f48a..082c251 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -445,6 +445,8 @@ static int __init rockchip_drm_init(void)
 
num_rockchip_sub_drivers = 0;
ADD_ROCKCHIP_SUB_DRIVER(vop_platform_driver, CONFIG_DRM_ROCKCHIP);
+   ADD_ROCKCHIP_SUB_DRIVER(rockchip_lvds_driver,
+   CONFIG_ROCKCHIP_LVDS);
ADD_ROCKCHIP_SUB_DRIVER(rockchip_dp_driver,
CONFIG_ROCKCHIP_ANALOGIX_DP);
ADD_ROCKCHIP_SUB_DRIVER(cdn_dp_driver, CONFIG_ROCKCHIP_CDN_DP);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index c7e96b8..498dfbc 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -69,5 +69,6 @@ extern struct platform_driver dw_hdmi_rockchip_pltfm_driver;
 extern struct platform_driver dw_mipi_dsi_driver;
 extern struct platform_driver inno_hdmi_driver;
 extern struct platform_driver rockchip_dp_driver;
+extern struct platform_driver rockchip_lvds_driver;
 extern struct platform_driver vop_platform_driver;
 #endif /* _ROCKCHIP_DRM_DRV_H_ */
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c 
b/drivers/gpu/drm/rockchip/rockchip_lvds.c
new file mode 100644
index 000..544415f
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -0,0 +1,599 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author:
+ *  Mark Yao 
+ *  Sandy Huang 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../drm_crtc_internal.h"
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+#include "rockchip_lvds.h"
+
+#define DISPLAY_OUTPUT_RGB 0
+#define DISPLAY_OUTPUT_LVDS1
+#define DISPLAY_OUTPUT_DUAL_LVDS   2
+
+#define connector_to_lvds(c) \
+   container_of(c, struct rockchip_lvds, connector)
+
+#define encoder_to_lvds(c) \
+   container_of(c, struct rockchip_lvds, encoder)
+
+/**
+ * rockchip_lvds_soc_data - rockchip lvds Soc private data
+ * @ch1_offset: lvds channel 1 registe offset
+ * grf_soc_con6: general registe offset for LVDS contrl
+ * grf_soc_con7: general registe offset for LVDS contrl
+ * 

[PATCH v5 0/3] Add support Rockchip Soc LVDS

[Sandy Huang]

[0]: https://github.com/RockchipOpensourceCommunity/popmetal-kernel-3.14
  ]: http://lists.infradead.org/pipermail/linux-rockchip/2015-April/002830.html

Changes:
- Update rockchip_lvds_encoder_helper_funcs to atomic API
- Add bridge function for RGB/LVDS convert to other output type
- Fix some unreasonable define
- Adapter to the latest rockchip DRM driver framework
- Add pinctrl for RGB output type
- Reseved some define for rockchip next Soc

Sandy Huang (3):
  dt-bindings: display: Add Document for Rockchip Soc LVDS
  ARM: dts: Add LVDS info for rk3288
  drm/rockchip: Add support for Rockchip Soc LVDS

 .../bindings/display/rockchip/rockchip-lvds.txt| 105 
 arch/arm/boot/dts/rk3288.dtsi  |  52 ++
 drivers/gpu/drm/rockchip/Kconfig   |   9 +
 drivers/gpu/drm/rockchip/Makefile  |   1 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c|   2 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h|   1 +
 drivers/gpu/drm/rockchip/rockchip_lvds.c   | 599 +
 drivers/gpu/drm/rockchip/rockchip_lvds.h   | 109 
 8 files changed, 878 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.h

-- 
2.7.4

[PATCH v5 0/3] Add support Rockchip Soc LVDS

[Sandy Huang]

[0]: https://github.com/RockchipOpensourceCommunity/popmetal-kernel-3.14
  ]: http://lists.infradead.org/pipermail/linux-rockchip/2015-April/002830.html

Changes:
- Update rockchip_lvds_encoder_helper_funcs to atomic API
- Add bridge function for RGB/LVDS convert to other output type
- Fix some unreasonable define
- Adapter to the latest rockchip DRM driver framework
- Add pinctrl for RGB output type
- Reseved some define for rockchip next Soc

Sandy Huang (3):
  dt-bindings: display: Add Document for Rockchip Soc LVDS
  ARM: dts: Add LVDS info for rk3288
  drm/rockchip: Add support for Rockchip Soc LVDS

 .../bindings/display/rockchip/rockchip-lvds.txt| 105 
 arch/arm/boot/dts/rk3288.dtsi  |  52 ++
 drivers/gpu/drm/rockchip/Kconfig   |   9 +
 drivers/gpu/drm/rockchip/Makefile  |   1 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c|   2 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h|   1 +
 drivers/gpu/drm/rockchip/rockchip_lvds.c   | 599 +
 drivers/gpu/drm/rockchip/rockchip_lvds.h   | 109 
 8 files changed, 878 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.h

-- 
2.7.4

Re: [PATCH v5 02/10] mm, x86: Add support for eXclusive Page Frame Ownership (XPFO)

[Tycho Andersen]

Hi Laura,

On Mon, Aug 14, 2017 at 03:30:00PM -0700, Laura Abbott wrote:
> On 08/09/2017 01:07 PM, Tycho Andersen wrote:
> > +/* Update a single kernel page table entry */
> > +inline void set_kpte(void *kaddr, struct page *page, pgprot_t prot)
> > +{
> > +   unsigned int level;
> > +   pgprot_t msk_clr;
> > +   pte_t *pte = lookup_address((unsigned long)kaddr, );
> > +
> > +   BUG_ON(!pte);
> > +
> > +   switch (level) {
> > +   case PG_LEVEL_4K:
> > +   set_pte_atomic(pte, pfn_pte(page_to_pfn(page), 
> > canon_pgprot(prot)));
> > +   break;
> > +   case PG_LEVEL_2M:
> > +   /* We need to check if it's a 2M page or 1GB page before 
> > retrieve
> > +* pgprot info, as each one will be extracted from a different
> > +* page table levels */
> > +   msk_clr = pmd_pgprot(*(pmd_t*)pte);
> > +   case PG_LEVEL_1G: {
> > +   struct cpa_data cpa;
> > +   int do_split;
> > +
> > +   msk_clr = pud_pgprot(*(pud_t*)pte);
> > +
> > +   memset(, 0, sizeof(cpa));
> > +   cpa.vaddr = kaddr;
> > +   cpa.pages = 
> > +   cpa.mask_set = prot;
> > +   cpa.mask_clr = msk_clr;
> > +   cpa.numpages = 1;
> > +   cpa.flags = 0;
> > +   cpa.curpage = 0;
> > +   cpa.force_split = 0;
> > +
> > +
> > +   do_split = try_preserve_large_page(pte, (unsigned long)kaddr, 
> > );
> > +   if (do_split) {
> > +   spin_lock(_lock);
> > +   BUG_ON(split_large_page(, pte, (unsigned 
> > long)kaddr));
> > +   spin_unlock(_lock);
> > +   }
> 
> This doesn't work in atomic contexts:
> 
> [   28.263571] BUG: sleeping function called from invalid context at
> mm/page_alloc.c:4048
> [   28.263575] in_atomic(): 1, irqs_disabled(): 1, pid: 2433, name:
> gnome-terminal
> [   28.263576] INFO: lockdep is turned off.
> [   28.263578] irq event stamp: 0
> [   28.263580] hardirqs last  enabled at (0): [<  (null)>]
> (null)
> [   28.263584] hardirqs last disabled at (0): []
> copy_process.part.25+0x62a/0x1e90
> [   28.263587] softirqs last  enabled at (0): []
> copy_process.part.25+0x62a/0x1e90
> [   28.263588] softirqs last disabled at (0): [<  (null)>]
> (null)
> [   28.263591] CPU: 0 PID: 2433 Comm: gnome-terminal Tainted: GW
> 4.13.0-rc5-xpfo+ #86
> [   28.263592] Hardware name: LENOVO 20BTS1N700/20BTS1N700, BIOS N14ET28W
> (1.06 ) 03/12/2015
> [   28.263593] Call Trace:
> [   28.263598]  dump_stack+0x8e/0xd6
> [   28.263601]  ___might_sleep+0x164/0x250
> [   28.263604]  __might_sleep+0x4a/0x80
> [   28.263607]  __alloc_pages_nodemask+0x2b3/0x3e0
> [   28.263611]  alloc_pages_current+0x6a/0xe0
> [   28.263614]  split_large_page+0x4e/0x360
> [   28.263618]  set_kpte+0x12c/0x150
> [   28.263623]  xpfo_kunmap+0x7e/0xa0
> [   28.263627]  wp_page_copy+0x16e/0x800
> [   28.263631]  do_wp_page+0x9a/0x580
> [   28.263633]  __handle_mm_fault+0xb1c/0x1130
> [   28.263638]  handle_mm_fault+0x178/0x350
> [   28.263641]  __do_page_fault+0x26e/0x510
> [   28.263644]  do_page_fault+0x30/0x80
> [   28.263647]  page_fault+0x28/0x30
> 
> 
> split_large_page calls alloc_page with GFP_KERNEL. switching to
> use GFP_ATOMIC in this path works locally for me.

Oof, thanks. I'll do that for the next version, and also CC x86 in
case they may have better suggestions.

Cheers,

Tycho

Re: [PATCH v5 02/10] mm, x86: Add support for eXclusive Page Frame Ownership (XPFO)

[Tycho Andersen]

Hi Laura,

On Mon, Aug 14, 2017 at 03:30:00PM -0700, Laura Abbott wrote:
> On 08/09/2017 01:07 PM, Tycho Andersen wrote:
> > +/* Update a single kernel page table entry */
> > +inline void set_kpte(void *kaddr, struct page *page, pgprot_t prot)
> > +{
> > +   unsigned int level;
> > +   pgprot_t msk_clr;
> > +   pte_t *pte = lookup_address((unsigned long)kaddr, );
> > +
> > +   BUG_ON(!pte);
> > +
> > +   switch (level) {
> > +   case PG_LEVEL_4K:
> > +   set_pte_atomic(pte, pfn_pte(page_to_pfn(page), 
> > canon_pgprot(prot)));
> > +   break;
> > +   case PG_LEVEL_2M:
> > +   /* We need to check if it's a 2M page or 1GB page before 
> > retrieve
> > +* pgprot info, as each one will be extracted from a different
> > +* page table levels */
> > +   msk_clr = pmd_pgprot(*(pmd_t*)pte);
> > +   case PG_LEVEL_1G: {
> > +   struct cpa_data cpa;
> > +   int do_split;
> > +
> > +   msk_clr = pud_pgprot(*(pud_t*)pte);
> > +
> > +   memset(, 0, sizeof(cpa));
> > +   cpa.vaddr = kaddr;
> > +   cpa.pages = 
> > +   cpa.mask_set = prot;
> > +   cpa.mask_clr = msk_clr;
> > +   cpa.numpages = 1;
> > +   cpa.flags = 0;
> > +   cpa.curpage = 0;
> > +   cpa.force_split = 0;
> > +
> > +
> > +   do_split = try_preserve_large_page(pte, (unsigned long)kaddr, 
> > );
> > +   if (do_split) {
> > +   spin_lock(_lock);
> > +   BUG_ON(split_large_page(, pte, (unsigned 
> > long)kaddr));
> > +   spin_unlock(_lock);
> > +   }
> 
> This doesn't work in atomic contexts:
> 
> [   28.263571] BUG: sleeping function called from invalid context at
> mm/page_alloc.c:4048
> [   28.263575] in_atomic(): 1, irqs_disabled(): 1, pid: 2433, name:
> gnome-terminal
> [   28.263576] INFO: lockdep is turned off.
> [   28.263578] irq event stamp: 0
> [   28.263580] hardirqs last  enabled at (0): [<  (null)>]
> (null)
> [   28.263584] hardirqs last disabled at (0): []
> copy_process.part.25+0x62a/0x1e90
> [   28.263587] softirqs last  enabled at (0): []
> copy_process.part.25+0x62a/0x1e90
> [   28.263588] softirqs last disabled at (0): [<  (null)>]
> (null)
> [   28.263591] CPU: 0 PID: 2433 Comm: gnome-terminal Tainted: GW
> 4.13.0-rc5-xpfo+ #86
> [   28.263592] Hardware name: LENOVO 20BTS1N700/20BTS1N700, BIOS N14ET28W
> (1.06 ) 03/12/2015
> [   28.263593] Call Trace:
> [   28.263598]  dump_stack+0x8e/0xd6
> [   28.263601]  ___might_sleep+0x164/0x250
> [   28.263604]  __might_sleep+0x4a/0x80
> [   28.263607]  __alloc_pages_nodemask+0x2b3/0x3e0
> [   28.263611]  alloc_pages_current+0x6a/0xe0
> [   28.263614]  split_large_page+0x4e/0x360
> [   28.263618]  set_kpte+0x12c/0x150
> [   28.263623]  xpfo_kunmap+0x7e/0xa0
> [   28.263627]  wp_page_copy+0x16e/0x800
> [   28.263631]  do_wp_page+0x9a/0x580
> [   28.263633]  __handle_mm_fault+0xb1c/0x1130
> [   28.263638]  handle_mm_fault+0x178/0x350
> [   28.263641]  __do_page_fault+0x26e/0x510
> [   28.263644]  do_page_fault+0x30/0x80
> [   28.263647]  page_fault+0x28/0x30
> 
> 
> split_large_page calls alloc_page with GFP_KERNEL. switching to
> use GFP_ATOMIC in this path works locally for me.

Oof, thanks. I'll do that for the next version, and also CC x86 in
case they may have better suggestions.

Cheers,

Tycho

Re: [PATCH v4] f2fs: introduce discard_granularity sysfs entry

[Jaegeuk Kim]

On 08/07, Chao Yu wrote:
> From: Chao Yu 
> 
> Commit d618ebaf0aa8 ("f2fs: enable small discard by default") enables
> f2fs to issue 4K size discard in real-time discard mode. However, issuing
> smaller discard may cost more lifetime but releasing less free space in
> flash device. Since f2fs has ability of separating hot/cold data and
> garbage collection, we can expect that small-sized invalid region would
> expand soon with OPU, deletion or garbage collection on valid datas, so
> it's better to delay or skip issuing smaller size discards, it could help
> to reduce overmuch consumption of IO bandwidth and lifetime of flash
> storage.
> 
> This patch makes f2fs selectng 64K size as its default minimal
> granularity, and issue discard with the size which is not smaller than
> minimal granularity. Also it exposes discard granularity as sysfs entry
> for configuration in different scenario.

Hi Chao,

I'd like to change the default value to 1 in order to keep the original
behavior, since we must avoid performance fluctuation after this single
patch. Instead, you probably can change the value through sysfs.

Thanks,

> 
> Signed-off-by: Chao Yu 
> ---
> v4: minor change in commit log.
>  Documentation/ABI/testing/sysfs-fs-f2fs |  9 +
>  fs/f2fs/f2fs.h  |  4 
>  fs/f2fs/segment.c   | 23 ++-
>  fs/f2fs/sysfs.c |  7 +++
>  4 files changed, 42 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs 
> b/Documentation/ABI/testing/sysfs-fs-f2fs
> index 84c606fb3ca4..c579ce5e0ef5 100644
> --- a/Documentation/ABI/testing/sysfs-fs-f2fs
> +++ b/Documentation/ABI/testing/sysfs-fs-f2fs
> @@ -57,6 +57,15 @@ Contact:   "Jaegeuk Kim" 
>  Description:
>Controls the issue rate of small discard commands.
>  
> +What:  /sys/fs/f2fs//discard_granularity
> +Date:  July 2017
> +Contact:   "Chao Yu" 
> +Description:
> + Controls discard granularity of inner discard thread, inner 
> thread
> + will not issue discards with size that is smaller than 
> granularity.
> + The unit size is one block, now only support configuring in 
> range
> + of [1, 512].
> +
>  What:/sys/fs/f2fs//max_victim_search
>  Date:January 2014
>  Contact: "Jaegeuk Kim" 
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index 0bfdeeab..1bcaa93bfed7 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -195,6 +195,9 @@ struct discard_entry {
>   unsigned char discard_map[SIT_VBLOCK_MAP_SIZE]; /* segment discard 
> bitmap */
>  };
>  
> +/* default discard granularity of inner discard thread, unit: block count */
> +#define DEFAULT_DISCARD_GRANULARITY  16
> +
>  /* max discard pend list number */
>  #define MAX_PLIST_NUM512
>  #define plist_idx(blk_num)   ((blk_num) >= MAX_PLIST_NUM ?   \
> @@ -240,6 +243,7 @@ struct discard_cmd_control {
>   struct mutex cmd_lock;
>   unsigned int nr_discards;   /* # of discards in the list */
>   unsigned int max_discards;  /* max. discards to be issued */
> + unsigned int discard_granularity;   /* discard granularity */
>   unsigned int undiscard_blks;/* # of undiscard blocks */
>   atomic_t issued_discard;/* # of issued discard */
>   atomic_t issing_discard;/* # of issing discard */
> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> index 71c2e0ac13d7..f336f8c541f0 100644
> --- a/fs/f2fs/segment.c
> +++ b/fs/f2fs/segment.c
> @@ -1019,7 +1019,8 @@ static void __issue_discard_cmd(struct f2fs_sb_info 
> *sbi, bool issue_cond)
>   f2fs_bug_on(sbi,
>   !__check_rb_tree_consistence(sbi, >root));
>   blk_start_plug();
> - for (i = MAX_PLIST_NUM - 1; i >= 0; i--) {
> + for (i = MAX_PLIST_NUM - 1; i >= 0 &&
> + i >= dcc->discard_granularity - 1; i--) {
>   pend_list = >pend_list[i];
>   list_for_each_entry_safe(dc, tmp, pend_list, list) {
>   f2fs_bug_on(sbi, dc->state != D_PREP);
> @@ -1035,6 +1036,24 @@ static void __issue_discard_cmd(struct f2fs_sb_info 
> *sbi, bool issue_cond)
>   mutex_unlock(>cmd_lock);
>  }
>  
> +static void __drop_discard_cmd(struct f2fs_sb_info *sbi)
> +{
> + struct discard_cmd_control *dcc = SM_I(sbi)->dcc_info;
> + struct list_head *pend_list;
> + struct discard_cmd *dc, *tmp;
> + int i;
> +
> + mutex_lock(>cmd_lock);
> + for (i = MAX_PLIST_NUM - 1; i >= 0; i--) {
> + pend_list = >pend_list[i];
> + list_for_each_entry_safe(dc, tmp, pend_list, list) {
> + f2fs_bug_on(sbi, dc->state != D_PREP);
> + __remove_discard_cmd(sbi, 

Re: [PATCH v4] f2fs: introduce discard_granularity sysfs entry

[Jaegeuk Kim]

On 08/07, Chao Yu wrote:
> From: Chao Yu 
> 
> Commit d618ebaf0aa8 ("f2fs: enable small discard by default") enables
> f2fs to issue 4K size discard in real-time discard mode. However, issuing
> smaller discard may cost more lifetime but releasing less free space in
> flash device. Since f2fs has ability of separating hot/cold data and
> garbage collection, we can expect that small-sized invalid region would
> expand soon with OPU, deletion or garbage collection on valid datas, so
> it's better to delay or skip issuing smaller size discards, it could help
> to reduce overmuch consumption of IO bandwidth and lifetime of flash
> storage.
> 
> This patch makes f2fs selectng 64K size as its default minimal
> granularity, and issue discard with the size which is not smaller than
> minimal granularity. Also it exposes discard granularity as sysfs entry
> for configuration in different scenario.

Hi Chao,

I'd like to change the default value to 1 in order to keep the original
behavior, since we must avoid performance fluctuation after this single
patch. Instead, you probably can change the value through sysfs.

Thanks,

> 
> Signed-off-by: Chao Yu 
> ---
> v4: minor change in commit log.
>  Documentation/ABI/testing/sysfs-fs-f2fs |  9 +
>  fs/f2fs/f2fs.h  |  4 
>  fs/f2fs/segment.c   | 23 ++-
>  fs/f2fs/sysfs.c |  7 +++
>  4 files changed, 42 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs 
> b/Documentation/ABI/testing/sysfs-fs-f2fs
> index 84c606fb3ca4..c579ce5e0ef5 100644
> --- a/Documentation/ABI/testing/sysfs-fs-f2fs
> +++ b/Documentation/ABI/testing/sysfs-fs-f2fs
> @@ -57,6 +57,15 @@ Contact:   "Jaegeuk Kim" 
>  Description:
>Controls the issue rate of small discard commands.
>  
> +What:  /sys/fs/f2fs//discard_granularity
> +Date:  July 2017
> +Contact:   "Chao Yu" 
> +Description:
> + Controls discard granularity of inner discard thread, inner 
> thread
> + will not issue discards with size that is smaller than 
> granularity.
> + The unit size is one block, now only support configuring in 
> range
> + of [1, 512].
> +
>  What:/sys/fs/f2fs//max_victim_search
>  Date:January 2014
>  Contact: "Jaegeuk Kim" 
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index 0bfdeeab..1bcaa93bfed7 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -195,6 +195,9 @@ struct discard_entry {
>   unsigned char discard_map[SIT_VBLOCK_MAP_SIZE]; /* segment discard 
> bitmap */
>  };
>  
> +/* default discard granularity of inner discard thread, unit: block count */
> +#define DEFAULT_DISCARD_GRANULARITY  16
> +
>  /* max discard pend list number */
>  #define MAX_PLIST_NUM512
>  #define plist_idx(blk_num)   ((blk_num) >= MAX_PLIST_NUM ?   \
> @@ -240,6 +243,7 @@ struct discard_cmd_control {
>   struct mutex cmd_lock;
>   unsigned int nr_discards;   /* # of discards in the list */
>   unsigned int max_discards;  /* max. discards to be issued */
> + unsigned int discard_granularity;   /* discard granularity */
>   unsigned int undiscard_blks;/* # of undiscard blocks */
>   atomic_t issued_discard;/* # of issued discard */
>   atomic_t issing_discard;/* # of issing discard */
> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> index 71c2e0ac13d7..f336f8c541f0 100644
> --- a/fs/f2fs/segment.c
> +++ b/fs/f2fs/segment.c
> @@ -1019,7 +1019,8 @@ static void __issue_discard_cmd(struct f2fs_sb_info 
> *sbi, bool issue_cond)
>   f2fs_bug_on(sbi,
>   !__check_rb_tree_consistence(sbi, >root));
>   blk_start_plug();
> - for (i = MAX_PLIST_NUM - 1; i >= 0; i--) {
> + for (i = MAX_PLIST_NUM - 1; i >= 0 &&
> + i >= dcc->discard_granularity - 1; i--) {
>   pend_list = >pend_list[i];
>   list_for_each_entry_safe(dc, tmp, pend_list, list) {
>   f2fs_bug_on(sbi, dc->state != D_PREP);
> @@ -1035,6 +1036,24 @@ static void __issue_discard_cmd(struct f2fs_sb_info 
> *sbi, bool issue_cond)
>   mutex_unlock(>cmd_lock);
>  }
>  
> +static void __drop_discard_cmd(struct f2fs_sb_info *sbi)
> +{
> + struct discard_cmd_control *dcc = SM_I(sbi)->dcc_info;
> + struct list_head *pend_list;
> + struct discard_cmd *dc, *tmp;
> + int i;
> +
> + mutex_lock(>cmd_lock);
> + for (i = MAX_PLIST_NUM - 1; i >= 0; i--) {
> + pend_list = >pend_list[i];
> + list_for_each_entry_safe(dc, tmp, pend_list, list) {
> + f2fs_bug_on(sbi, dc->state != D_PREP);
> + __remove_discard_cmd(sbi, dc);
> + }
> + }
> + mutex_unlock(>cmd_lock);
> +}
> +
>  static void 

Re: [linux-sunxi] [PATCH v6] arm64: allwinner: a64: Add initial NanoPi A64 support

[Chen-Yu Tsai]

On Mon, Aug 14, 2017 at 6:36 PM, Jagan Teki  wrote:
> From: Jagan Teki 
>
> NanoPi A64 is a new board of high performance with low cost
> designed by FriendlyElec., using the Allwinner A64 SOC.
>
> Nanopi A64 features
> - Allwinner A64, 64-bit Quad-core Cortex-A53@648MHz to 1.152GHz, DVFS
> - 1GB DDR3 RAM
> - MicroSD
> - Gigabit Ethernet (RTL8211E)
> - Wi-Fi 802.11b/g/n
> - IR receiver
> - Audio In/Out
> - Video In/Out
> - Serial Debug Port
> - microUSB 5V 2A DC power-supply
>
> Signed-off-by: Jagan Teki 
> ---
> Changes for v6:
> - Moved uart0 below regulators
> - Add comment for i2c1
> - Update vdd-cpux volt range 1.04 ~ 1.3 V
> - ehci0 detection https://paste.ubuntu.com/25311593/

Thanks. This confirms the hardware default is OK for host-only
usage.

> - Remove space before usbphy
> - Removed unused DLD02
> - Add comment for DLD01 regulator-name to vcc-dsi since
>   it's connected along with vcc-hdmi
> - Add regulator node for DLD04 for vcc-pg
> Changes for v5:
> - Add AXP803 PMIC regulator support.
> Changes for v4:
> - Rebased and droped wi-fi related nodes, since it require
>   other changes to taken care.
> Changes for v3:
> - Fix to use mmc1 for SDIO instead of mmc2
> - Replace buswidth by 4 instead of 8 mmc1
> - Drop cap-mmc-hw-reset for mmc1
> Changes for v2:
> - Added ohci0, ehci0, ohic1, ehci1, usbphy.
> - Tested on A64
>
>  arch/arm64/boot/dts/allwinner/Makefile |   1 +
>  .../boot/dts/allwinner/sun50i-a64-nanopi-a64.dts   | 209 
> +
>  2 files changed, 210 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
> b/arch/arm64/boot/dts/allwinner/Makefile
> index 108f12c..c997b5c 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -1,4 +1,5 @@
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-bananapi-m64.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-nanopi-a64.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts 
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
> new file mode 100644
> index 000..c2bbc75
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
> @@ -0,0 +1,209 @@
> +/*
> + * Copyright (C) 2017 Jagan Teki 
> + *
> + * 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 library 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 library 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 "sun50i-a64.dtsi"
> +
> +#include 
> +
> +/ {
> +   model = "FriendlyARM NanoPi A64";
> +   compatible = "friendlyarm,nanopi-a64", "allwinner,sun50i-a64";
> +
> +   aliases {
> +   serial0 = 
> +   };
> +
> +   chosen {
> +   stdout-path = "serial0:115200n8";

Re: [linux-sunxi] [PATCH v6] arm64: allwinner: a64: Add initial NanoPi A64 support

[Chen-Yu Tsai]

On Mon, Aug 14, 2017 at 6:36 PM, Jagan Teki  wrote:
> From: Jagan Teki 
>
> NanoPi A64 is a new board of high performance with low cost
> designed by FriendlyElec., using the Allwinner A64 SOC.
>
> Nanopi A64 features
> - Allwinner A64, 64-bit Quad-core Cortex-A53@648MHz to 1.152GHz, DVFS
> - 1GB DDR3 RAM
> - MicroSD
> - Gigabit Ethernet (RTL8211E)
> - Wi-Fi 802.11b/g/n
> - IR receiver
> - Audio In/Out
> - Video In/Out
> - Serial Debug Port
> - microUSB 5V 2A DC power-supply
>
> Signed-off-by: Jagan Teki 
> ---
> Changes for v6:
> - Moved uart0 below regulators
> - Add comment for i2c1
> - Update vdd-cpux volt range 1.04 ~ 1.3 V
> - ehci0 detection https://paste.ubuntu.com/25311593/

Thanks. This confirms the hardware default is OK for host-only
usage.

> - Remove space before usbphy
> - Removed unused DLD02
> - Add comment for DLD01 regulator-name to vcc-dsi since
>   it's connected along with vcc-hdmi
> - Add regulator node for DLD04 for vcc-pg
> Changes for v5:
> - Add AXP803 PMIC regulator support.
> Changes for v4:
> - Rebased and droped wi-fi related nodes, since it require
>   other changes to taken care.
> Changes for v3:
> - Fix to use mmc1 for SDIO instead of mmc2
> - Replace buswidth by 4 instead of 8 mmc1
> - Drop cap-mmc-hw-reset for mmc1
> Changes for v2:
> - Added ohci0, ehci0, ohic1, ehci1, usbphy.
> - Tested on A64
>
>  arch/arm64/boot/dts/allwinner/Makefile |   1 +
>  .../boot/dts/allwinner/sun50i-a64-nanopi-a64.dts   | 209 
> +
>  2 files changed, 210 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
> b/arch/arm64/boot/dts/allwinner/Makefile
> index 108f12c..c997b5c 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -1,4 +1,5 @@
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-bananapi-m64.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-nanopi-a64.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
>  dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts 
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
> new file mode 100644
> index 000..c2bbc75
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
> @@ -0,0 +1,209 @@
> +/*
> + * Copyright (C) 2017 Jagan Teki 
> + *
> + * 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 library 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 library 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 "sun50i-a64.dtsi"
> +
> +#include 
> +
> +/ {
> +   model = "FriendlyARM NanoPi A64";
> +   compatible = "friendlyarm,nanopi-a64", "allwinner,sun50i-a64";
> +
> +   aliases {
> +   serial0 = 
> +   };
> +
> +   chosen {
> +   stdout-path = "serial0:115200n8";
> +   };
> +};
> +
> + {
> +   status = "okay";
> +};
> +
> + {
> +   status = "okay";
> 

Re: [PATCH] f2fs: free_user_blocks should use reserved_segments instead

[Jaegeuk Kim]

On 08/14, Yunlong Song wrote:
> The part (overprovision_segments - reserved_segments) can still be used for 
> LFS,
> so free_use_blocks should use reserved_segments instead, rather than use
> overprovision_segments.
> 
> Signed-off-by: Yunlong Song 
> ---
>  fs/f2fs/gc.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/f2fs/gc.h b/fs/f2fs/gc.h
> index 9325191..6258305 100644
> --- a/fs/f2fs/gc.h
> +++ b/fs/f2fs/gc.h
> @@ -49,10 +49,10 @@ struct gc_inode_list {
>   */
>  static inline block_t free_user_blocks(struct f2fs_sb_info *sbi)

NAK. This gives user-visible block count.

>  {
> - if (free_segments(sbi) < overprovision_segments(sbi))
> + if (free_segments(sbi) < reserved_segments(sbi))
>   return 0;
>   else
> - return (free_segments(sbi) - overprovision_segments(sbi))
> + return (free_segments(sbi) - reserved_segments(sbi))
>   << sbi->log_blocks_per_seg;
>  }
>  
> -- 
> 1.8.5.2

Re: [PATCH] f2fs: free_user_blocks should use reserved_segments instead

[Jaegeuk Kim]

On 08/14, Yunlong Song wrote:
> The part (overprovision_segments - reserved_segments) can still be used for 
> LFS,
> so free_use_blocks should use reserved_segments instead, rather than use
> overprovision_segments.
> 
> Signed-off-by: Yunlong Song 
> ---
>  fs/f2fs/gc.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/f2fs/gc.h b/fs/f2fs/gc.h
> index 9325191..6258305 100644
> --- a/fs/f2fs/gc.h
> +++ b/fs/f2fs/gc.h
> @@ -49,10 +49,10 @@ struct gc_inode_list {
>   */
>  static inline block_t free_user_blocks(struct f2fs_sb_info *sbi)

NAK. This gives user-visible block count.

>  {
> - if (free_segments(sbi) < overprovision_segments(sbi))
> + if (free_segments(sbi) < reserved_segments(sbi))
>   return 0;
>   else
> - return (free_segments(sbi) - overprovision_segments(sbi))
> + return (free_segments(sbi) - reserved_segments(sbi))
>   << sbi->log_blocks_per_seg;
>  }
>  
> -- 
> 1.8.5.2

Re: [PATCH 1/2] sched/wait: Break up long wake list walk

[Linus Torvalds]

On Mon, Aug 14, 2017 at 8:15 PM, Andi Kleen  wrote:
> But what should we do when some other (non page) wait queue runs into the
> same problem?

Hopefully the same: root-cause it.

Once you have a test-case, it should generally be fairly simple to do
with profiles, just seeing who the caller is when ttwu() (or whatever
it is that ends up being the most noticeable part of the wakeup chain)
shows up very heavily.

And I think that ends up being true whether the "break up long chains"
patch goes in or not. Even if we end up allowing interrupts in the
middle, a long wait-queue is a problem.

I think the "break up long chains" thing may be the right thing
against actual malicious attacks, but not for any actual real
benchmark or load.

I don't think we normally have cases of long wait-queues, though. At
least not the kinds that cause problems. The real (and valid)
thundering herd cases should already be using exclusive waiters that
only wake up one process at a time.

The page bit-waiting is hopefully special. As mentioned, we used to
have some _really_ special code for it for other reasons, and I
suspect you see this problem with them because we over-simplified it
from being a per-zone dynamically sized one (where the per-zone thing
caused both performance problems and actual bugs) to being that
"static small array".

So I think/hope that just re-introducing some dynamic sizing will help
sufficiently, and that this really is an odd and unusual case.

Linus

Re: [PATCH 1/2] sched/wait: Break up long wake list walk

[Linus Torvalds]

On Mon, Aug 14, 2017 at 8:15 PM, Andi Kleen  wrote:
> But what should we do when some other (non page) wait queue runs into the
> same problem?

Hopefully the same: root-cause it.

Once you have a test-case, it should generally be fairly simple to do
with profiles, just seeing who the caller is when ttwu() (or whatever
it is that ends up being the most noticeable part of the wakeup chain)
shows up very heavily.

And I think that ends up being true whether the "break up long chains"
patch goes in or not. Even if we end up allowing interrupts in the
middle, a long wait-queue is a problem.

I think the "break up long chains" thing may be the right thing
against actual malicious attacks, but not for any actual real
benchmark or load.

I don't think we normally have cases of long wait-queues, though. At
least not the kinds that cause problems. The real (and valid)
thundering herd cases should already be using exclusive waiters that
only wake up one process at a time.

The page bit-waiting is hopefully special. As mentioned, we used to
have some _really_ special code for it for other reasons, and I
suspect you see this problem with them because we over-simplified it
from being a per-zone dynamically sized one (where the per-zone thing
caused both performance problems and actual bugs) to being that
"static small array".

So I think/hope that just re-introducing some dynamic sizing will help
sufficiently, and that this really is an odd and unusual case.

Linus

[PATCH v11 5/5] net/cxgb4vf: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

[Ding Tianhong]

From: Casey Leedom 

cxgb4vf Ethernet driver now queries PCIe configuration space to
determine if it can send TLPs to it with the Relaxed Ordering
Attribute set, just like the pf did.

Signed-off-by: Casey Leedom 
Signed-off-by: Ding Tianhong 
Reviewed-by: Casey Leedom 
---
 drivers/net/ethernet/chelsio/cxgb4vf/adapter.h  |  1 +
 drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c | 18 ++
 drivers/net/ethernet/chelsio/cxgb4vf/sge.c  |  3 +++
 3 files changed, 22 insertions(+)

diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h 
b/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h
index 109bc63..08c6ddb 100644
--- a/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h
@@ -408,6 +408,7 @@ enum { /* adapter flags */
USING_MSI  = (1UL << 1),
USING_MSIX = (1UL << 2),
QUEUES_BOUND   = (1UL << 3),
+   ROOT_NO_RELAXED_ORDERING = (1UL << 4),
 };
 
 /*
diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c 
b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
index ac7a150..2b85b87 100644
--- a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
@@ -2888,6 +2888,24 @@ static int cxgb4vf_pci_probe(struct pci_dev *pdev,
 */
adapter->name = pci_name(pdev);
adapter->msg_enable = DFLT_MSG_ENABLE;
+
+   /* If possible, we use PCIe Relaxed Ordering Attribute to deliver
+* Ingress Packet Data to Free List Buffers in order to allow for
+* chipset performance optimizations between the Root Complex and
+* Memory Controllers.  (Messages to the associated Ingress Queue
+* notifying new Packet Placement in the Free Lists Buffers will be
+* send without the Relaxed Ordering Attribute thus guaranteeing that
+* all preceding PCIe Transaction Layer Packets will be processed
+* first.)  But some Root Complexes have various issues with Upstream
+* Transaction Layer Packets with the Relaxed Ordering Attribute set.
+* The PCIe devices which under the Root Complexes will be cleared the
+* Relaxed Ordering bit in the configuration space, So we check our
+* PCIe configuration space to see if it's flagged with advice against
+* using Relaxed Ordering.
+*/
+   if (!pcie_relaxed_ordering_enabled(pdev))
+   adapter->flags |= ROOT_NO_RELAXED_ORDERING;
+
err = adap_init0(adapter);
if (err)
goto err_unmap_bar;
diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/sge.c 
b/drivers/net/ethernet/chelsio/cxgb4vf/sge.c
index e37dde2..05498e7 100644
--- a/drivers/net/ethernet/chelsio/cxgb4vf/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/sge.c
@@ -2205,6 +2205,7 @@ int t4vf_sge_alloc_rxq(struct adapter *adapter, struct 
sge_rspq *rspq,
struct port_info *pi = netdev_priv(dev);
struct fw_iq_cmd cmd, rpl;
int ret, iqandst, flsz = 0;
+   int relaxed = !(adapter->flags & ROOT_NO_RELAXED_ORDERING);
 
/*
 * If we're using MSI interrupts and we're not initializing the
@@ -2300,6 +2301,8 @@ int t4vf_sge_alloc_rxq(struct adapter *adapter, struct 
sge_rspq *rspq,
cpu_to_be32(
FW_IQ_CMD_FL0HOSTFCMODE_V(SGE_HOSTFCMODE_NONE) |
FW_IQ_CMD_FL0PACKEN_F |
+   FW_IQ_CMD_FL0FETCHRO_V(relaxed) |
+   FW_IQ_CMD_FL0DATARO_V(relaxed) |
FW_IQ_CMD_FL0PADEN_F);
 
/* In T6, for egress queue type FL there is internal overhead
-- 
1.8.3.1

[PATCH v11 5/5] net/cxgb4vf: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

[Ding Tianhong]

From: Casey Leedom 

cxgb4vf Ethernet driver now queries PCIe configuration space to
determine if it can send TLPs to it with the Relaxed Ordering
Attribute set, just like the pf did.

Signed-off-by: Casey Leedom 
Signed-off-by: Ding Tianhong 
Reviewed-by: Casey Leedom 
---
 drivers/net/ethernet/chelsio/cxgb4vf/adapter.h  |  1 +
 drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c | 18 ++
 drivers/net/ethernet/chelsio/cxgb4vf/sge.c  |  3 +++
 3 files changed, 22 insertions(+)

diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h 
b/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h
index 109bc63..08c6ddb 100644
--- a/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h
@@ -408,6 +408,7 @@ enum { /* adapter flags */
USING_MSI  = (1UL << 1),
USING_MSIX = (1UL << 2),
QUEUES_BOUND   = (1UL << 3),
+   ROOT_NO_RELAXED_ORDERING = (1UL << 4),
 };
 
 /*
diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c 
b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
index ac7a150..2b85b87 100644
--- a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c
@@ -2888,6 +2888,24 @@ static int cxgb4vf_pci_probe(struct pci_dev *pdev,
 */
adapter->name = pci_name(pdev);
adapter->msg_enable = DFLT_MSG_ENABLE;
+
+   /* If possible, we use PCIe Relaxed Ordering Attribute to deliver
+* Ingress Packet Data to Free List Buffers in order to allow for
+* chipset performance optimizations between the Root Complex and
+* Memory Controllers.  (Messages to the associated Ingress Queue
+* notifying new Packet Placement in the Free Lists Buffers will be
+* send without the Relaxed Ordering Attribute thus guaranteeing that
+* all preceding PCIe Transaction Layer Packets will be processed
+* first.)  But some Root Complexes have various issues with Upstream
+* Transaction Layer Packets with the Relaxed Ordering Attribute set.
+* The PCIe devices which under the Root Complexes will be cleared the
+* Relaxed Ordering bit in the configuration space, So we check our
+* PCIe configuration space to see if it's flagged with advice against
+* using Relaxed Ordering.
+*/
+   if (!pcie_relaxed_ordering_enabled(pdev))
+   adapter->flags |= ROOT_NO_RELAXED_ORDERING;
+
err = adap_init0(adapter);
if (err)
goto err_unmap_bar;
diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/sge.c 
b/drivers/net/ethernet/chelsio/cxgb4vf/sge.c
index e37dde2..05498e7 100644
--- a/drivers/net/ethernet/chelsio/cxgb4vf/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/sge.c
@@ -2205,6 +2205,7 @@ int t4vf_sge_alloc_rxq(struct adapter *adapter, struct 
sge_rspq *rspq,
struct port_info *pi = netdev_priv(dev);
struct fw_iq_cmd cmd, rpl;
int ret, iqandst, flsz = 0;
+   int relaxed = !(adapter->flags & ROOT_NO_RELAXED_ORDERING);
 
/*
 * If we're using MSI interrupts and we're not initializing the
@@ -2300,6 +2301,8 @@ int t4vf_sge_alloc_rxq(struct adapter *adapter, struct 
sge_rspq *rspq,
cpu_to_be32(
FW_IQ_CMD_FL0HOSTFCMODE_V(SGE_HOSTFCMODE_NONE) |
FW_IQ_CMD_FL0PACKEN_F |
+   FW_IQ_CMD_FL0FETCHRO_V(relaxed) |
+   FW_IQ_CMD_FL0DATARO_V(relaxed) |
FW_IQ_CMD_FL0PADEN_F);
 
/* In T6, for egress queue type FL there is internal overhead
-- 
1.8.3.1

[PATCH v11 2/5] PCI: Disable Relaxed Ordering for some Intel processors

[Ding Tianhong]

According to the Intel spec section 3.9.1 said:

3.9.1 Optimizing PCIe Performance for Accesses Toward Coherent Memory
  and Toward MMIO Regions (P2P)

In order to maximize performance for PCIe devices in the processors
listed in Table 3-6 below, the soft- ware should determine whether the
accesses are toward coherent memory (system memory) or toward MMIO
regions (P2P access to other devices). If the access is toward MMIO
region, then software can command HW to set the RO bit in the TLP
header, as this would allow hardware to achieve maximum throughput for
these types of accesses. For accesses toward coherent memory, software
can command HW to clear the RO bit in the TLP header (no RO), as this
would allow hardware to achieve maximum throughput for these types of
accesses.

Table 3-6. Intel Processor CPU RP Device IDs for Processors Optimizing
   PCIe Performance

ProcessorCPU RP Device IDs

Intel Xeon processors based on   6F01H-6F0EH
Broadwell microarchitecture

Intel Xeon processors based on   2F01H-2F0EH
Haswell microarchitecture

It means some Intel processors has performance issue when use the Relaxed
Ordering Attribute, so disable Relaxed Ordering for these root port.

Signed-off-by: Casey Leedom 
Signed-off-by: Ding Tianhong 
Acked-by: Alexander Duyck 
Acked-by: Ashok Raj 
---
 drivers/pci/quirks.c | 62 
 1 file changed, 62 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 61b59bf..1272f7e 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4027,6 +4027,68 @@ static void quirk_relaxedordering_disable(struct pci_dev 
*dev)
 }
 
 /*
+ * Intel Xeon processors based on Broadwell/Haswell microarchitecture Root
+ * Complex has a Flow Control Credit issue which can cause performance
+ * problems with Upstream Transaction Layer Packets with Relaxed Ordering set.
+ */
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f01, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f02, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f03, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f04, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f05, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f06, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f07, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f08, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f09, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f0a, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f0b, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f0c, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f0d, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f0e, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x2f01, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x2f02, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x2f03, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x2f04, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x2f05, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 

[PATCH v11 2/5] PCI: Disable Relaxed Ordering for some Intel processors

[Ding Tianhong]

According to the Intel spec section 3.9.1 said:

3.9.1 Optimizing PCIe Performance for Accesses Toward Coherent Memory
  and Toward MMIO Regions (P2P)

In order to maximize performance for PCIe devices in the processors
listed in Table 3-6 below, the soft- ware should determine whether the
accesses are toward coherent memory (system memory) or toward MMIO
regions (P2P access to other devices). If the access is toward MMIO
region, then software can command HW to set the RO bit in the TLP
header, as this would allow hardware to achieve maximum throughput for
these types of accesses. For accesses toward coherent memory, software
can command HW to clear the RO bit in the TLP header (no RO), as this
would allow hardware to achieve maximum throughput for these types of
accesses.

Table 3-6. Intel Processor CPU RP Device IDs for Processors Optimizing
   PCIe Performance

ProcessorCPU RP Device IDs

Intel Xeon processors based on   6F01H-6F0EH
Broadwell microarchitecture

Intel Xeon processors based on   2F01H-2F0EH
Haswell microarchitecture

It means some Intel processors has performance issue when use the Relaxed
Ordering Attribute, so disable Relaxed Ordering for these root port.

Signed-off-by: Casey Leedom 
Signed-off-by: Ding Tianhong 
Acked-by: Alexander Duyck 
Acked-by: Ashok Raj 
---
 drivers/pci/quirks.c | 62 
 1 file changed, 62 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 61b59bf..1272f7e 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4027,6 +4027,68 @@ static void quirk_relaxedordering_disable(struct pci_dev 
*dev)
 }
 
 /*
+ * Intel Xeon processors based on Broadwell/Haswell microarchitecture Root
+ * Complex has a Flow Control Credit issue which can cause performance
+ * problems with Upstream Transaction Layer Packets with Relaxed Ordering set.
+ */
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f01, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f02, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f03, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f04, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f05, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f06, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f07, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f08, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f09, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f0a, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f0b, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f0c, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f0d, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f0e, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x2f01, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x2f02, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x2f03, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x2f04, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x2f05, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x2f06, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);

[PATCH v11 4/5] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

[Ding Tianhong]

From: Casey Leedom 

cxgb4 Ethernet driver now queries PCIe configuration space to determine
if it can send TLPs to it with the Relaxed Ordering Attribute set.

Remove the enable_pcie_relaxed_ordering() to avoid enable PCIe Capability
Device Control[Relaxed Ordering Enable] at probe routine, to make sure
the driver will not send the Relaxed Ordering TLPs to the Root Complex which
could not deal the Relaxed Ordering TLPs.

Signed-off-by: Casey Leedom 
Signed-off-by: Ding Tianhong 
Reviewed-by: Casey Leedom 
---
 drivers/net/ethernet/chelsio/cxgb4/cxgb4.h  |  1 +
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 23 +--
 drivers/net/ethernet/chelsio/cxgb4/sge.c|  5 +++--
 3 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h 
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index ef4be78..09ea62e 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -529,6 +529,7 @@ enum { /* adapter flags */
USING_SOFT_PARAMS  = (1 << 6),
MASTER_PF  = (1 << 7),
FW_OFLD_CONN   = (1 << 9),
+   ROOT_NO_RELAXED_ORDERING = (1 << 10),
 };
 
 enum {
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c 
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index e403fa1..33bb867 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -4654,11 +4654,6 @@ static void print_port_info(const struct net_device *dev)
dev->name, adap->params.vpd.id, adap->name, buf);
 }
 
-static void enable_pcie_relaxed_ordering(struct pci_dev *dev)
-{
-   pcie_capability_set_word(dev, PCI_EXP_DEVCTL, PCI_EXP_DEVCTL_RELAX_EN);
-}
-
 /*
  * Free the following resources:
  * - memory used for tables
@@ -4908,7 +4903,6 @@ static int init_one(struct pci_dev *pdev, const struct 
pci_device_id *ent)
}
 
pci_enable_pcie_error_reporting(pdev);
-   enable_pcie_relaxed_ordering(pdev);
pci_set_master(pdev);
pci_save_state(pdev);
 
@@ -4947,6 +4941,23 @@ static int init_one(struct pci_dev *pdev, const struct 
pci_device_id *ent)
adapter->msg_enable = DFLT_MSG_ENABLE;
memset(adapter->chan_map, 0xff, sizeof(adapter->chan_map));
 
+   /* If possible, we use PCIe Relaxed Ordering Attribute to deliver
+* Ingress Packet Data to Free List Buffers in order to allow for
+* chipset performance optimizations between the Root Complex and
+* Memory Controllers.  (Messages to the associated Ingress Queue
+* notifying new Packet Placement in the Free Lists Buffers will be
+* send without the Relaxed Ordering Attribute thus guaranteeing that
+* all preceding PCIe Transaction Layer Packets will be processed
+* first.)  But some Root Complexes have various issues with Upstream
+* Transaction Layer Packets with the Relaxed Ordering Attribute set.
+* The PCIe devices which under the Root Complexes will be cleared the
+* Relaxed Ordering bit in the configuration space, So we check our
+* PCIe configuration space to see if it's flagged with advice against
+* using Relaxed Ordering.
+*/
+   if (!pcie_relaxed_ordering_enabled(pdev))
+   adapter->flags |= ROOT_NO_RELAXED_ORDERING;
+
spin_lock_init(>stats_lock);
spin_lock_init(>tid_release_lock);
spin_lock_init(>win0_lock);
diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c 
b/drivers/net/ethernet/chelsio/cxgb4/sge.c
index ede1220..4ef68f6 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c
@@ -2719,6 +2719,7 @@ int t4_sge_alloc_rxq(struct adapter *adap, struct 
sge_rspq *iq, bool fwevtq,
struct fw_iq_cmd c;
struct sge *s = >sge;
struct port_info *pi = netdev_priv(dev);
+   int relaxed = !(adap->flags & ROOT_NO_RELAXED_ORDERING);
 
/* Size needs to be multiple of 16, including status entry. */
iq->size = roundup(iq->size, 16);
@@ -2772,8 +2773,8 @@ int t4_sge_alloc_rxq(struct adapter *adap, struct 
sge_rspq *iq, bool fwevtq,
 
flsz = fl->size / 8 + s->stat_len / sizeof(struct tx_desc);
c.iqns_to_fl0congen |= htonl(FW_IQ_CMD_FL0PACKEN_F |
-FW_IQ_CMD_FL0FETCHRO_F |
-FW_IQ_CMD_FL0DATARO_F |
+FW_IQ_CMD_FL0FETCHRO_V(relaxed) |
+FW_IQ_CMD_FL0DATARO_V(relaxed) |
 FW_IQ_CMD_FL0PADEN_F);
if (cong >= 0)
c.iqns_to_fl0congen |=
-- 
1.8.3.1

[PATCH v11 4/5] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

[Ding Tianhong]

From: Casey Leedom 

cxgb4 Ethernet driver now queries PCIe configuration space to determine
if it can send TLPs to it with the Relaxed Ordering Attribute set.

Remove the enable_pcie_relaxed_ordering() to avoid enable PCIe Capability
Device Control[Relaxed Ordering Enable] at probe routine, to make sure
the driver will not send the Relaxed Ordering TLPs to the Root Complex which
could not deal the Relaxed Ordering TLPs.

Signed-off-by: Casey Leedom 
Signed-off-by: Ding Tianhong 
Reviewed-by: Casey Leedom 
---
 drivers/net/ethernet/chelsio/cxgb4/cxgb4.h  |  1 +
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 23 +--
 drivers/net/ethernet/chelsio/cxgb4/sge.c|  5 +++--
 3 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h 
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index ef4be78..09ea62e 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -529,6 +529,7 @@ enum { /* adapter flags */
USING_SOFT_PARAMS  = (1 << 6),
MASTER_PF  = (1 << 7),
FW_OFLD_CONN   = (1 << 9),
+   ROOT_NO_RELAXED_ORDERING = (1 << 10),
 };
 
 enum {
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c 
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index e403fa1..33bb867 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -4654,11 +4654,6 @@ static void print_port_info(const struct net_device *dev)
dev->name, adap->params.vpd.id, adap->name, buf);
 }
 
-static void enable_pcie_relaxed_ordering(struct pci_dev *dev)
-{
-   pcie_capability_set_word(dev, PCI_EXP_DEVCTL, PCI_EXP_DEVCTL_RELAX_EN);
-}
-
 /*
  * Free the following resources:
  * - memory used for tables
@@ -4908,7 +4903,6 @@ static int init_one(struct pci_dev *pdev, const struct 
pci_device_id *ent)
}
 
pci_enable_pcie_error_reporting(pdev);
-   enable_pcie_relaxed_ordering(pdev);
pci_set_master(pdev);
pci_save_state(pdev);
 
@@ -4947,6 +4941,23 @@ static int init_one(struct pci_dev *pdev, const struct 
pci_device_id *ent)
adapter->msg_enable = DFLT_MSG_ENABLE;
memset(adapter->chan_map, 0xff, sizeof(adapter->chan_map));
 
+   /* If possible, we use PCIe Relaxed Ordering Attribute to deliver
+* Ingress Packet Data to Free List Buffers in order to allow for
+* chipset performance optimizations between the Root Complex and
+* Memory Controllers.  (Messages to the associated Ingress Queue
+* notifying new Packet Placement in the Free Lists Buffers will be
+* send without the Relaxed Ordering Attribute thus guaranteeing that
+* all preceding PCIe Transaction Layer Packets will be processed
+* first.)  But some Root Complexes have various issues with Upstream
+* Transaction Layer Packets with the Relaxed Ordering Attribute set.
+* The PCIe devices which under the Root Complexes will be cleared the
+* Relaxed Ordering bit in the configuration space, So we check our
+* PCIe configuration space to see if it's flagged with advice against
+* using Relaxed Ordering.
+*/
+   if (!pcie_relaxed_ordering_enabled(pdev))
+   adapter->flags |= ROOT_NO_RELAXED_ORDERING;
+
spin_lock_init(>stats_lock);
spin_lock_init(>tid_release_lock);
spin_lock_init(>win0_lock);
diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c 
b/drivers/net/ethernet/chelsio/cxgb4/sge.c
index ede1220..4ef68f6 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c
@@ -2719,6 +2719,7 @@ int t4_sge_alloc_rxq(struct adapter *adap, struct 
sge_rspq *iq, bool fwevtq,
struct fw_iq_cmd c;
struct sge *s = >sge;
struct port_info *pi = netdev_priv(dev);
+   int relaxed = !(adap->flags & ROOT_NO_RELAXED_ORDERING);
 
/* Size needs to be multiple of 16, including status entry. */
iq->size = roundup(iq->size, 16);
@@ -2772,8 +2773,8 @@ int t4_sge_alloc_rxq(struct adapter *adap, struct 
sge_rspq *iq, bool fwevtq,
 
flsz = fl->size / 8 + s->stat_len / sizeof(struct tx_desc);
c.iqns_to_fl0congen |= htonl(FW_IQ_CMD_FL0PACKEN_F |
-FW_IQ_CMD_FL0FETCHRO_F |
-FW_IQ_CMD_FL0DATARO_F |
+FW_IQ_CMD_FL0FETCHRO_V(relaxed) |
+FW_IQ_CMD_FL0DATARO_V(relaxed) |
 FW_IQ_CMD_FL0PADEN_F);
if (cong >= 0)
c.iqns_to_fl0congen |=
-- 
1.8.3.1

[PATCH v11 3/5] PCI: Disable Relaxed Ordering Attributes for AMD A1100

[Ding Tianhong]

Casey reported that the AMD ARM A1100 SoC has a bug in its PCIe
Root Port where Upstream Transaction Layer Packets with the Relaxed
Ordering Attribute clear are allowed to bypass earlier TLPs with
Relaxed Ordering set, it would cause Data Corruption, so we need
to disable Relaxed Ordering Attribute when Upstream TLPs to the
Root Port.

Reported-and-suggested-by: Casey Leedom 
Signed-off-by: Casey Leedom 
Signed-off-by: Ding Tianhong 
Acked-by: Casey Leedom 
---
 drivers/pci/quirks.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 1272f7e..1407604 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4089,6 +4089,22 @@ static void quirk_relaxedordering_disable(struct pci_dev 
*dev)
  quirk_relaxedordering_disable);
 
 /*
+ * The AMD ARM A1100 (AKA "SEATTLE") SoC has a bug in its PCIe Root Complex
+ * where Upstream Transaction Layer Packets with the Relaxed Ordering
+ * Attribute clear are allowed to bypass earlier TLPs with Relaxed Ordering
+ * set.  This is a violation of the PCIe 3.0 Transaction Ordering Rules
+ * outlined in Section 2.4.1 (PCI Express(r) Base Specification Revision 3.0
+ * November 10, 2010).  As a result, on this platform we can't use Relaxed
+ * Ordering for Upstream TLPs.
+ */
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AMD, 0x1a00, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AMD, 0x1a01, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AMD, 0x1a02, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+
+/*
  * Per PCIe r3.0, sec 2.2.9, "Completion headers must supply the same
  * values for the Attribute as were supplied in the header of the
  * corresponding Request, except as explicitly allowed when IDO is used."
-- 
1.8.3.1

[PATCH v11 3/5] PCI: Disable Relaxed Ordering Attributes for AMD A1100

[Ding Tianhong]

Casey reported that the AMD ARM A1100 SoC has a bug in its PCIe
Root Port where Upstream Transaction Layer Packets with the Relaxed
Ordering Attribute clear are allowed to bypass earlier TLPs with
Relaxed Ordering set, it would cause Data Corruption, so we need
to disable Relaxed Ordering Attribute when Upstream TLPs to the
Root Port.

Reported-and-suggested-by: Casey Leedom 
Signed-off-by: Casey Leedom 
Signed-off-by: Ding Tianhong 
Acked-by: Casey Leedom 
---
 drivers/pci/quirks.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 1272f7e..1407604 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4089,6 +4089,22 @@ static void quirk_relaxedordering_disable(struct pci_dev 
*dev)
  quirk_relaxedordering_disable);
 
 /*
+ * The AMD ARM A1100 (AKA "SEATTLE") SoC has a bug in its PCIe Root Complex
+ * where Upstream Transaction Layer Packets with the Relaxed Ordering
+ * Attribute clear are allowed to bypass earlier TLPs with Relaxed Ordering
+ * set.  This is a violation of the PCIe 3.0 Transaction Ordering Rules
+ * outlined in Section 2.4.1 (PCI Express(r) Base Specification Revision 3.0
+ * November 10, 2010).  As a result, on this platform we can't use Relaxed
+ * Ordering for Upstream TLPs.
+ */
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AMD, 0x1a00, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AMD, 0x1a01, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AMD, 0x1a02, 
PCI_CLASS_NOT_DEFINED, 8,
+ quirk_relaxedordering_disable);
+
+/*
  * Per PCIe r3.0, sec 2.2.9, "Completion headers must supply the same
  * values for the Attribute as were supplied in the header of the
  * corresponding Request, except as explicitly allowed when IDO is used."
-- 
1.8.3.1

[PATCH v11 1/5] PCI: Disable PCIe Relaxed Ordering if unsupported

[Ding Tianhong]

When bit4 is set in the PCIe Device Control register, it indicates
whether the device is permitted to use relaxed ordering.
On some platforms using relaxed ordering can have performance issues or
due to erratum can cause data-corruption. In such cases devices must avoid
using relaxed ordering.

The patch adds a new flag PCI_DEV_FLAGS_NO_RELAXED_ORDERING to indicate that
Relaxed Ordering (RO) attribute should not be used for Transaction Layer
Packets (TLP) targeted towards these affected root complexes.

This patch checks if there is any node in the hierarchy that indicates that
using relaxed ordering is not safe. In such cases the patch turns off the
relaxed ordering by clearing the capability for this device.

Signed-off-by: Casey Leedom 
Signed-off-by: Ding Tianhong 
Acked-by: Ashok Raj 
Acked-by: Alexander Duyck 
Acked-by: Casey Leedom 
---
 drivers/pci/probe.c  | 43 +++
 drivers/pci/quirks.c | 11 +++
 include/linux/pci.h  |  3 +++
 3 files changed, 57 insertions(+)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index c31310d..779e646 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1762,6 +1762,48 @@ static void pci_configure_extended_tags(struct pci_dev 
*dev)
 PCI_EXP_DEVCTL_EXT_TAG);
 }
 
+/**
+ * pcie_relaxed_ordering_enabled - Probe for PCIe relaxed ordering enable
+ * @dev: PCI device to query
+ *
+ * Returns true if the device has enabled relaxed ordering attribute.
+ */
+bool pcie_relaxed_ordering_enabled(struct pci_dev *dev)
+{
+   u16 v;
+
+   pcie_capability_read_word(dev, PCI_EXP_DEVCTL, );
+
+   return !!(v & PCI_EXP_DEVCTL_RELAX_EN);
+}
+EXPORT_SYMBOL(pcie_relaxed_ordering_enabled);
+
+static void pci_configure_relaxed_ordering(struct pci_dev *dev)
+{
+   struct pci_dev *root;
+
+   /* PCI_EXP_DEVICE_RELAX_EN is RsvdP in VFs */
+   if (dev->is_virtfn)
+   return;
+
+   if (!pcie_relaxed_ordering_enabled(dev))
+   return;
+
+   /*
+* For now, we only deal with Relaxed Ordering issues with Root
+* Ports. Peer-to-Peer DMA is another can of worms.
+*/
+   root = pci_find_pcie_root_port(dev);
+   if (!root)
+   return;
+
+   if (root->dev_flags & PCI_DEV_FLAGS_NO_RELAXED_ORDERING) {
+   pcie_capability_clear_word(dev, PCI_EXP_DEVCTL,
+  PCI_EXP_DEVCTL_RELAX_EN);
+   dev_info(>dev, "Disable Relaxed Ordering because the Root 
Port didn't support it\n");
+   }
+}
+
 static void pci_configure_device(struct pci_dev *dev)
 {
struct hotplug_params hpp;
@@ -1769,6 +1811,7 @@ static void pci_configure_device(struct pci_dev *dev)
 
pci_configure_mps(dev);
pci_configure_extended_tags(dev);
+   pci_configure_relaxed_ordering(dev);
 
memset(, 0, sizeof(hpp));
ret = pci_get_hp_params(dev, );
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 6967c6b..61b59bf 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4016,6 +4016,17 @@ static void quirk_tw686x_class(struct pci_dev *pdev)
  quirk_tw686x_class);
 
 /*
+ * Some devices have problems with Transaction Layer Packets with the Relaxed
+ * Ordering Attribute set.  Such devices should mark themselves and other
+ * Device Drivers should check before sending TLPs with RO set.
+ */
+static void quirk_relaxedordering_disable(struct pci_dev *dev)
+{
+   dev->dev_flags |= PCI_DEV_FLAGS_NO_RELAXED_ORDERING;
+   dev_info(>dev, "Disable Relaxed Ordering Attributes to avoid PCIe 
Completion erratum\n");
+}
+
+/*
  * Per PCIe r3.0, sec 2.2.9, "Completion headers must supply the same
  * values for the Attribute as were supplied in the header of the
  * corresponding Request, except as explicitly allowed when IDO is used."
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 4869e66..29606fb 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -188,6 +188,8 @@ enum pci_dev_flags {
 * the direct_complete optimization.
 */
PCI_DEV_FLAGS_NEEDS_RESUME = (__force pci_dev_flags_t) (1 << 11),
+   /* Don't use Relaxed Ordering for TLPs directed at this device */
+   PCI_DEV_FLAGS_NO_RELAXED_ORDERING = (__force pci_dev_flags_t) (1 << 12),
 };
 
 enum pci_irq_reroute_variant {
@@ -1125,6 +1127,7 @@ int pci_add_ext_cap_save_buffer(struct pci_dev *dev,
 void pci_pme_wakeup_bus(struct pci_bus *bus);
 void pci_d3cold_enable(struct pci_dev *dev);
 void pci_d3cold_disable(struct pci_dev *dev);
+bool pcie_relaxed_ordering_enabled(struct pci_dev *dev);
 
 /* PCI Virtual Channel */
 int pci_save_vc_state(struct pci_dev *dev);
-- 
1.8.3.1

[PATCH v11 1/5] PCI: Disable PCIe Relaxed Ordering if unsupported

[Ding Tianhong]

When bit4 is set in the PCIe Device Control register, it indicates
whether the device is permitted to use relaxed ordering.
On some platforms using relaxed ordering can have performance issues or
due to erratum can cause data-corruption. In such cases devices must avoid
using relaxed ordering.

The patch adds a new flag PCI_DEV_FLAGS_NO_RELAXED_ORDERING to indicate that
Relaxed Ordering (RO) attribute should not be used for Transaction Layer
Packets (TLP) targeted towards these affected root complexes.

This patch checks if there is any node in the hierarchy that indicates that
using relaxed ordering is not safe. In such cases the patch turns off the
relaxed ordering by clearing the capability for this device.

Signed-off-by: Casey Leedom 
Signed-off-by: Ding Tianhong 
Acked-by: Ashok Raj 
Acked-by: Alexander Duyck 
Acked-by: Casey Leedom 
---
 drivers/pci/probe.c  | 43 +++
 drivers/pci/quirks.c | 11 +++
 include/linux/pci.h  |  3 +++
 3 files changed, 57 insertions(+)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index c31310d..779e646 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1762,6 +1762,48 @@ static void pci_configure_extended_tags(struct pci_dev 
*dev)
 PCI_EXP_DEVCTL_EXT_TAG);
 }
 
+/**
+ * pcie_relaxed_ordering_enabled - Probe for PCIe relaxed ordering enable
+ * @dev: PCI device to query
+ *
+ * Returns true if the device has enabled relaxed ordering attribute.
+ */
+bool pcie_relaxed_ordering_enabled(struct pci_dev *dev)
+{
+   u16 v;
+
+   pcie_capability_read_word(dev, PCI_EXP_DEVCTL, );
+
+   return !!(v & PCI_EXP_DEVCTL_RELAX_EN);
+}
+EXPORT_SYMBOL(pcie_relaxed_ordering_enabled);
+
+static void pci_configure_relaxed_ordering(struct pci_dev *dev)
+{
+   struct pci_dev *root;
+
+   /* PCI_EXP_DEVICE_RELAX_EN is RsvdP in VFs */
+   if (dev->is_virtfn)
+   return;
+
+   if (!pcie_relaxed_ordering_enabled(dev))
+   return;
+
+   /*
+* For now, we only deal with Relaxed Ordering issues with Root
+* Ports. Peer-to-Peer DMA is another can of worms.
+*/
+   root = pci_find_pcie_root_port(dev);
+   if (!root)
+   return;
+
+   if (root->dev_flags & PCI_DEV_FLAGS_NO_RELAXED_ORDERING) {
+   pcie_capability_clear_word(dev, PCI_EXP_DEVCTL,
+  PCI_EXP_DEVCTL_RELAX_EN);
+   dev_info(>dev, "Disable Relaxed Ordering because the Root 
Port didn't support it\n");
+   }
+}
+
 static void pci_configure_device(struct pci_dev *dev)
 {
struct hotplug_params hpp;
@@ -1769,6 +1811,7 @@ static void pci_configure_device(struct pci_dev *dev)
 
pci_configure_mps(dev);
pci_configure_extended_tags(dev);
+   pci_configure_relaxed_ordering(dev);
 
memset(, 0, sizeof(hpp));
ret = pci_get_hp_params(dev, );
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 6967c6b..61b59bf 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4016,6 +4016,17 @@ static void quirk_tw686x_class(struct pci_dev *pdev)
  quirk_tw686x_class);
 
 /*
+ * Some devices have problems with Transaction Layer Packets with the Relaxed
+ * Ordering Attribute set.  Such devices should mark themselves and other
+ * Device Drivers should check before sending TLPs with RO set.
+ */
+static void quirk_relaxedordering_disable(struct pci_dev *dev)
+{
+   dev->dev_flags |= PCI_DEV_FLAGS_NO_RELAXED_ORDERING;
+   dev_info(>dev, "Disable Relaxed Ordering Attributes to avoid PCIe 
Completion erratum\n");
+}
+
+/*
  * Per PCIe r3.0, sec 2.2.9, "Completion headers must supply the same
  * values for the Attribute as were supplied in the header of the
  * corresponding Request, except as explicitly allowed when IDO is used."
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 4869e66..29606fb 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -188,6 +188,8 @@ enum pci_dev_flags {
 * the direct_complete optimization.
 */
PCI_DEV_FLAGS_NEEDS_RESUME = (__force pci_dev_flags_t) (1 << 11),
+   /* Don't use Relaxed Ordering for TLPs directed at this device */
+   PCI_DEV_FLAGS_NO_RELAXED_ORDERING = (__force pci_dev_flags_t) (1 << 12),
 };
 
 enum pci_irq_reroute_variant {
@@ -1125,6 +1127,7 @@ int pci_add_ext_cap_save_buffer(struct pci_dev *dev,
 void pci_pme_wakeup_bus(struct pci_bus *bus);
 void pci_d3cold_enable(struct pci_dev *dev);
 void pci_d3cold_disable(struct pci_dev *dev);
+bool pcie_relaxed_ordering_enabled(struct pci_dev *dev);
 
 /* PCI Virtual Channel */
 int pci_save_vc_state(struct pci_dev *dev);
-- 
1.8.3.1

[PATCH v11 0/5] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

[Ding Tianhong]

Some devices have problems with Transaction Layer Packets with the Relaxed
Ordering Attribute set.  This patch set adds a new PCIe Device Flag,
PCI_DEV_FLAGS_NO_RELAXED_ORDERING, a set of PCI Quirks to catch some known
devices with Relaxed Ordering issues, and a use of this new flag by the
cxgb4 driver to avoid using Relaxed Ordering with problematic Root Complex
Ports.

It's been years since I've submitted kernel.org patches, I appolgise for the
almost certain submission errors.

v2: Alexander point out that the v1 was only a part of the whole solution,
some platform which has some issues could use the new flag to indicate
that it is not safe to enable relaxed ordering attribute, then we need
to clear the relaxed ordering enable bits in the PCI configuration when
initializing the device. So add a new second patch to modify the PCI
initialization code to clear the relaxed ordering enable bit in the
event that the root complex doesn't want relaxed ordering enabled.

The third patch was base on the v1's second patch and only be changed
to query the relaxed ordering enable bit in the PCI configuration space
to allow the Chelsio NIC to send TLPs with the relaxed ordering attributes
set.

This version didn't plan to drop the defines for Intel Drivers to use the
new checking way to enable relaxed ordering because it is not the hardest
part of the moment, we could fix it in next patchset when this patches
reach the goal.

v3: Redesigned the logic for pci_configure_relaxed_ordering when configuration,
If a PCIe device didn't enable the relaxed ordering attribute default,
we should not do anything in the PCIe configuration, otherwise we
should check if any of the devices above us do not support relaxed
ordering by the PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag, then base on
the result if we get a return that indicate that the relaxed ordering
is not supported we should update our device to disable relaxed ordering
in configuration space. If the device above us doesn't exist or isn't
the PCIe device, we shouldn't do anything and skip updating relaxed ordering
because we are probably running in a guest.

v4: Rename the functions pcie_get_relaxed_ordering and 
pcie_disable_relaxed_ordering
according John's suggestion, and modify the description, use the true/false
as the return value.

We shouldn't enable relaxed ordering attribute by the setting in the root
complex configuration space for PCIe device, so fix it for cxgb4.

Fix some format issues.

v5: Removed the unnecessary code for some function which only return the bool
value, and add the check for VF device.

Make this patch set base on 4.12-rc5.

v6: Fix the logic error in the need to enable the relaxed ordering attribute 
for cxgb4.

v7: The cxgb4 drivers will enable the PCIe Capability Device Control[Relaxed
Ordering Enable] in PCI Probe() routine, this will break our current
solution for some platform which has problematic when enable the relaxed
ordering attribute. According to the latest recommendations, remove the
enable_pcie_relaxed_ordering(), although it could not cover the Peer-to-Peer
scene, but we agree to leave this problem until we really trigger it.

Make this patch set base on 4.12 release version.

v8: Change the second patch title and description to make it more reasonable,
add the acked-by from Alex and Ashok.

Add a new patch to enable the Relaxed Ordering Attribute for cxgb4vf driver.

Make this patch set base on 4.13-rc2.

v9: The document (https://software.intel.com/sites/default/files/managed/9e/
bc/64-ia-32-architectures-optimization-manual.pdf) indicate that the Xeon
processors based on Broadwell/Haswell microarchitecture has the problem
with Relaxed Ordering Attribute enabled, so add the whole list Device ID
from Intel to the patch.

v10: Significant rework based on Bjorn's feedback, reorganize the first 2 
patches,
 now the Intel and AMD erratum soc has been divided to the different 
patches,
 rename the pcie_relaxed_ordering_supported() to 
pcie_relaxed_ordering_enabled(),
 and no need to check every intervening switch except the root ports, update
 some commits.

v11: We shouldn't let the Intel engineer to acked the AMD's erratum patch, fix 
the
 funny mistake.

Casey Leedom (2):
  net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
  net/cxgb4vf: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

Ding Tianhong (3):
  PCI: Disable PCIe Relaxed Ordering if unsupported
  PCI: Disable Relaxed Ordering for some Intel processors
  PCI: Disable Relaxed Ordering Attributes for AMD A1100

 drivers/net/ethernet/chelsio/cxgb4/cxgb4.h |  1 +
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c| 23 --
 drivers/net/ethernet/chelsio/cxgb4/sge.c   |  5 +-
 drivers/net/ethernet/chelsio/cxgb4vf/adapter.h |  1 +
 

Re: [PATCH] f2fs-tools: the overprovision should be 0 as default

[Jaegeuk Kim]

On 08/11, Yunlong Song wrote:
> The usage message gives a wrong number, so fix it.
> 
> Signed-off-by: Yunlong Song 
> ---
>  mkfs/f2fs_format_main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mkfs/f2fs_format_main.c b/mkfs/f2fs_format_main.c
> index a3652a9..6712b5c 100644
> --- a/mkfs/f2fs_format_main.c
> +++ b/mkfs/f2fs_format_main.c
> @@ -41,7 +41,7 @@ static void mkfs_usage()
>   MSG(0, "  -f force overwrite the exist filesystem\n");
>   MSG(0, "  -l label\n");
>   MSG(0, "  -m support zoned block device [default:0]\n");
> - MSG(0, "  -o overprovision ratio [default:5]\n");
> + MSG(0, "  -o overprovision ratio [default:0]\n");

We need to remove [default:xx], since the default is not fixed?

>   MSG(0, "  -O [feature list] e.g. \"encrypt\"\n");
>   MSG(0, "  -q quiet mode\n");
>   MSG(0, "  -s # of segments per section [default:1]\n");
> -- 
> 1.8.5.2

[PATCH v11 0/5] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

[Ding Tianhong]

Some devices have problems with Transaction Layer Packets with the Relaxed
Ordering Attribute set.  This patch set adds a new PCIe Device Flag,
PCI_DEV_FLAGS_NO_RELAXED_ORDERING, a set of PCI Quirks to catch some known
devices with Relaxed Ordering issues, and a use of this new flag by the
cxgb4 driver to avoid using Relaxed Ordering with problematic Root Complex
Ports.

It's been years since I've submitted kernel.org patches, I appolgise for the
almost certain submission errors.

v2: Alexander point out that the v1 was only a part of the whole solution,
some platform which has some issues could use the new flag to indicate
that it is not safe to enable relaxed ordering attribute, then we need
to clear the relaxed ordering enable bits in the PCI configuration when
initializing the device. So add a new second patch to modify the PCI
initialization code to clear the relaxed ordering enable bit in the
event that the root complex doesn't want relaxed ordering enabled.

The third patch was base on the v1's second patch and only be changed
to query the relaxed ordering enable bit in the PCI configuration space
to allow the Chelsio NIC to send TLPs with the relaxed ordering attributes
set.

This version didn't plan to drop the defines for Intel Drivers to use the
new checking way to enable relaxed ordering because it is not the hardest
part of the moment, we could fix it in next patchset when this patches
reach the goal.

v3: Redesigned the logic for pci_configure_relaxed_ordering when configuration,
If a PCIe device didn't enable the relaxed ordering attribute default,
we should not do anything in the PCIe configuration, otherwise we
should check if any of the devices above us do not support relaxed
ordering by the PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag, then base on
the result if we get a return that indicate that the relaxed ordering
is not supported we should update our device to disable relaxed ordering
in configuration space. If the device above us doesn't exist or isn't
the PCIe device, we shouldn't do anything and skip updating relaxed ordering
because we are probably running in a guest.

v4: Rename the functions pcie_get_relaxed_ordering and 
pcie_disable_relaxed_ordering
according John's suggestion, and modify the description, use the true/false
as the return value.

We shouldn't enable relaxed ordering attribute by the setting in the root
complex configuration space for PCIe device, so fix it for cxgb4.

Fix some format issues.

v5: Removed the unnecessary code for some function which only return the bool
value, and add the check for VF device.

Make this patch set base on 4.12-rc5.

v6: Fix the logic error in the need to enable the relaxed ordering attribute 
for cxgb4.

v7: The cxgb4 drivers will enable the PCIe Capability Device Control[Relaxed
Ordering Enable] in PCI Probe() routine, this will break our current
solution for some platform which has problematic when enable the relaxed
ordering attribute. According to the latest recommendations, remove the
enable_pcie_relaxed_ordering(), although it could not cover the Peer-to-Peer
scene, but we agree to leave this problem until we really trigger it.

Make this patch set base on 4.12 release version.

v8: Change the second patch title and description to make it more reasonable,
add the acked-by from Alex and Ashok.

Add a new patch to enable the Relaxed Ordering Attribute for cxgb4vf driver.

Make this patch set base on 4.13-rc2.

v9: The document (https://software.intel.com/sites/default/files/managed/9e/
bc/64-ia-32-architectures-optimization-manual.pdf) indicate that the Xeon
processors based on Broadwell/Haswell microarchitecture has the problem
with Relaxed Ordering Attribute enabled, so add the whole list Device ID
from Intel to the patch.

v10: Significant rework based on Bjorn's feedback, reorganize the first 2 
patches,
 now the Intel and AMD erratum soc has been divided to the different 
patches,
 rename the pcie_relaxed_ordering_supported() to 
pcie_relaxed_ordering_enabled(),
 and no need to check every intervening switch except the root ports, update
 some commits.

v11: We shouldn't let the Intel engineer to acked the AMD's erratum patch, fix 
the
 funny mistake.

Casey Leedom (2):
  net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
  net/cxgb4vf: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

Ding Tianhong (3):
  PCI: Disable PCIe Relaxed Ordering if unsupported
  PCI: Disable Relaxed Ordering for some Intel processors
  PCI: Disable Relaxed Ordering Attributes for AMD A1100

 drivers/net/ethernet/chelsio/cxgb4/cxgb4.h |  1 +
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c| 23 --
 drivers/net/ethernet/chelsio/cxgb4/sge.c   |  5 +-
 drivers/net/ethernet/chelsio/cxgb4vf/adapter.h |  1 +
 

Re: [PATCH] f2fs-tools: the overprovision should be 0 as default

[Jaegeuk Kim]

On 08/11, Yunlong Song wrote:
> The usage message gives a wrong number, so fix it.
> 
> Signed-off-by: Yunlong Song 
> ---
>  mkfs/f2fs_format_main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mkfs/f2fs_format_main.c b/mkfs/f2fs_format_main.c
> index a3652a9..6712b5c 100644
> --- a/mkfs/f2fs_format_main.c
> +++ b/mkfs/f2fs_format_main.c
> @@ -41,7 +41,7 @@ static void mkfs_usage()
>   MSG(0, "  -f force overwrite the exist filesystem\n");
>   MSG(0, "  -l label\n");
>   MSG(0, "  -m support zoned block device [default:0]\n");
> - MSG(0, "  -o overprovision ratio [default:5]\n");
> + MSG(0, "  -o overprovision ratio [default:0]\n");

We need to remove [default:xx], since the default is not fixed?

>   MSG(0, "  -O [feature list] e.g. \"encrypt\"\n");
>   MSG(0, "  -q quiet mode\n");
>   MSG(0, "  -s # of segments per section [default:1]\n");
> -- 
> 1.8.5.2

Re: [PATCH] f2fs: let fill_super handle roll-forward errors

[Jaegeuk Kim]

On 08/15, Chao Yu wrote:
> Hi Jaegeuk,
> 
> On 2017/8/11 8:42, Jaegeuk Kim wrote:
> > If we set CP_ERROR_FLAG in roll-forward error, f2fs is no longer to proceed
> > any IOs due to f2fs_cp_error(). But, for example, if some stale data is 
> > involved
> > on roll-forward process, we're able to get -ENOENT, getting fs stuck.
> > If we get any error, let fill_super set SBI_NEED_FSCK and try to recover 
> > back
> > to stable point.
> 
> Before that, we have cleaned up all node/meta page cache, so we will get back 
> to
> last checkpoint status, means losing fsynced datas for ever.
> 
> Would it be better to just leave message reminding user to mount with
> disable_roll_forward or run fsck offline.

We can't rely on user for this, since fsck cannot recover this, resulting in
infinite mount failure. The only way is to disable roll-forward recovery, which
is same as returning error here.

Thanks,

> 
> Thanks,
> 
> > 
> > Cc: 
> > Signed-off-by: Jaegeuk Kim 
> > ---
> >  fs/f2fs/recovery.c | 2 --
> >  1 file changed, 2 deletions(-)
> > 
> > diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
> > index a3d02613934a..f707d810c87d 100644
> > --- a/fs/f2fs/recovery.c
> > +++ b/fs/f2fs/recovery.c
> > @@ -649,8 +649,6 @@ int recover_fsync_data(struct f2fs_sb_info *sbi, bool 
> > check_only)
> > }
> >  
> > clear_sbi_flag(sbi, SBI_POR_DOING);
> > -   if (err)
> > -   set_ckpt_flags(sbi, CP_ERROR_FLAG);
> > mutex_unlock(>cp_mutex);
> >  
> > /* let's drop all the directory inodes for clean checkpoint */
> > 

Re: [PATCH] f2fs: let fill_super handle roll-forward errors

[Jaegeuk Kim]

On 08/15, Chao Yu wrote:
> Hi Jaegeuk,
> 
> On 2017/8/11 8:42, Jaegeuk Kim wrote:
> > If we set CP_ERROR_FLAG in roll-forward error, f2fs is no longer to proceed
> > any IOs due to f2fs_cp_error(). But, for example, if some stale data is 
> > involved
> > on roll-forward process, we're able to get -ENOENT, getting fs stuck.
> > If we get any error, let fill_super set SBI_NEED_FSCK and try to recover 
> > back
> > to stable point.
> 
> Before that, we have cleaned up all node/meta page cache, so we will get back 
> to
> last checkpoint status, means losing fsynced datas for ever.
> 
> Would it be better to just leave message reminding user to mount with
> disable_roll_forward or run fsck offline.

We can't rely on user for this, since fsck cannot recover this, resulting in
infinite mount failure. The only way is to disable roll-forward recovery, which
is same as returning error here.

Thanks,

> 
> Thanks,
> 
> > 
> > Cc: 
> > Signed-off-by: Jaegeuk Kim 
> > ---
> >  fs/f2fs/recovery.c | 2 --
> >  1 file changed, 2 deletions(-)
> > 
> > diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
> > index a3d02613934a..f707d810c87d 100644
> > --- a/fs/f2fs/recovery.c
> > +++ b/fs/f2fs/recovery.c
> > @@ -649,8 +649,6 @@ int recover_fsync_data(struct f2fs_sb_info *sbi, bool 
> > check_only)
> > }
> >  
> > clear_sbi_flag(sbi, SBI_POR_DOING);
> > -   if (err)
> > -   set_ckpt_flags(sbi, CP_ERROR_FLAG);
> > mutex_unlock(>cp_mutex);
> >  
> > /* let's drop all the directory inodes for clean checkpoint */
> > 

Re: [PATCH] perf report: calculate the average cycles of iterations

[Andi Kleen]

On Mon, Aug 14, 2017 at 01:30:29AM +, Jin, Yao wrote:
> Hi Andi, 
> 
> Do you have any comments for this patch?

Patch looks good to me. 

Reviewed-by: Andi Kleen 

-Andi

Re: [PATCH] perf report: calculate the average cycles of iterations

[Andi Kleen]

On Mon, Aug 14, 2017 at 01:30:29AM +, Jin, Yao wrote:
> Hi Andi, 
> 
> Do you have any comments for this patch?

Patch looks good to me. 

Reviewed-by: Andi Kleen 

-Andi

Re: [PATCH] Input: elan_i2c - Add antoher Lenovo ACPI ID for upcoming Lenovo NB Add 2 ACPI IC ELAN0609, ELAN060B in the ACPI mapping table Signed-off-by: KT Liao <kt.l...@emc.com.tw>

[Dmitry Torokhov]

On Fri, Aug 11, 2017 at 03:10:04PM +0800, KT Liao wrote:

Applied, however please make sure that there is a blank line in your
commit messages between the first line (subject) and the subsequent
lines comprising the patch description: it will allow the tools work
properly and not create emails with subjects consisting of your entire
commit message.

> ---
>  drivers/input/mouse/elan_i2c_core.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/input/mouse/elan_i2c_core.c 
> b/drivers/input/mouse/elan_i2c_core.c
> index 3b616cb..0d111322 100644
> --- a/drivers/input/mouse/elan_i2c_core.c
> +++ b/drivers/input/mouse/elan_i2c_core.c
> @@ -1248,6 +1248,8 @@ static const struct acpi_device_id elan_acpi_id[] = {
>   { "ELAN0100", 0 },
>   { "ELAN0600", 0 },
>   { "ELAN0605", 0 },
> + { "ELAN0609", 0 },
> + { "ELAN060B", 0 },
>   { "ELAN1000", 0 },
>   { }
>  };
> -- 
> 2.7.4
> 

Thanks.

-- 
Dmitry

Re: [PATCH] Input: elan_i2c - Add antoher Lenovo ACPI ID for upcoming Lenovo NB Add 2 ACPI IC ELAN0609, ELAN060B in the ACPI mapping table Signed-off-by: KT Liao

[Dmitry Torokhov]

On Fri, Aug 11, 2017 at 03:10:04PM +0800, KT Liao wrote:

Applied, however please make sure that there is a blank line in your
commit messages between the first line (subject) and the subsequent
lines comprising the patch description: it will allow the tools work
properly and not create emails with subjects consisting of your entire
commit message.

> ---
>  drivers/input/mouse/elan_i2c_core.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/input/mouse/elan_i2c_core.c 
> b/drivers/input/mouse/elan_i2c_core.c
> index 3b616cb..0d111322 100644
> --- a/drivers/input/mouse/elan_i2c_core.c
> +++ b/drivers/input/mouse/elan_i2c_core.c
> @@ -1248,6 +1248,8 @@ static const struct acpi_device_id elan_acpi_id[] = {
>   { "ELAN0100", 0 },
>   { "ELAN0600", 0 },
>   { "ELAN0605", 0 },
> + { "ELAN0609", 0 },
> + { "ELAN060B", 0 },
>   { "ELAN1000", 0 },
>   { }
>  };
> -- 
> 2.7.4
> 

Thanks.

-- 
Dmitry